UbuntuのNode.jsを最新にする

ここのところ JavaScript を書く機会があって、最近の書き方なんかを調べたりしてるんだけど、そういえば Ubuntu にインストールした Node.js はどうなってるんだっけかな、と思って確かめてみたら:

takatoh@apostrophe $ node -v
v4.2.6

もはや、いつインストールしたのかもわからない古いバージョンだった。公式サイトによると、最新版が13.6.0、推奨版が12.14.1 LTS だ。

で、さて、バージョンアップはどうやったらいいのか。ググってみたら、n package というのを使うといいらしい。

 cf. Ubuntuに最新のNode.jsを難なくインストールする – Qiita

さっそくこの通りにやってみる。まずは npm で n package をインストール。

takatoh@apostrophe $ sudo npm install n -g

その n package (nコマンド)を使って Node.js をインストール。

takatoh@apostrophe $ sudo n stable

もとから入っていた古い Node.js を削除。

takatoh@apostrophe $ sudo apt purge -y nodejs npm

そしてシェルを読みなおす。

takatoh@apostrophe $ exec $SHELL -l

これで完了。最新になっているか、確かめてみよう。

takatoh@apostrophe $ node -v
v12.14.1
takatoh@apostrophe $ npm -v
6.13.4

Qiita の記事によると、複数バージョンの管理なんかもできるらしい。

使わなくなった外付けHDDのデータを消去する

年末にサーバを1台止めたので、そこに繋いでいた外付け HDD を使わなくなった。1TB の HDD で、もう使いみちもなさそうだから処分しようと思う。というわけで、中のデータを完全消去することにした。

Ubuntu (というか Linux?)には、shred というコマンドがある。ファイルやディスクにランダムデータやゼロを書き込んで、データを消去、復元できなくするコマンドだ。

処分予定の HDD を Ubuntu マシンに繋いでみると、つぎのようになった。

takatoh@apostrophe $ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 931.5G  0 disk 
├─sda1   8:1    0   512M  0 part /boot/efi
├─sda2   8:2    0 927.1G  0 part /
└─sda3   8:3    0   3.9G  0 part [SWAP]
sdb      8:16   0 931.5G  0 disk 
└─sdb1   8:17   0 931.5G  0 part /media/takatoh/805ec9ee-d5ae-4894-95b2-cea22ab0
sr0     11:0    1  1024M  0 rom

sdb が対象の HDD だ。このディスクのデータを消去するにはつぎのようにする。

takatoh@apostrophe $ sudo shred -uvz /dev/sdb

デフォルトでは、ランダムデータを書き込むことを3回繰り返す。指定したオプションの意味はつぎの通り。

  • -u 上書き後にファイルを消去
  • -v コマンド実行中の詳細(進捗)を表示
  • -z ランダムデータ書き込み後にゼロを書き込む

というわけで、今回のケースでは都合4回書き込むことになるんだけど、昨日の夜に始めて約12時間くらいが経過した今朝の段階でやっと2回目の書き込みが始まったところ。予想以上に時間がかかりそうだなぁ。

Samba がこわれた

ローカルネットワーク上に作った Samba サーバがこわれた。先週の土曜日の話で、細かいことは覚えてないのでおおまかに書く。

最初に書いておくと、この Samba サーバは、ホスト名を wplj といい、OS は Ubuntu 16.04。

事の発端は Samba サーバにユーザを限定した共有フォルダを作ろうとしたことだ。下のページあたりを参考に /etc/samba/smb.conf ファイルに追記して samba サービスをリスタートしたところ、エラーになった。

 cf. アクセス権付の共有フォルダ作成 – Server World

追記した部分を削除してリスタートしてもエラーになる。仕方がないので Samba 自体をいったん削除してインストールしなおしても同じだった。再インストール後は最低限の設定だけで、共有フォルダを作らなくてもエラーになるんだから訳がわからない。設定自体は、さっきまで動いていた設定ファイル(バックアップしておいた)からコピペしたんだから間違ってないはずだ。どういうわけさ。

Samba サーバは Windows マシンのデータバックアップ用で、データ自体は残っているので大丈夫といえば大丈夫なんだけど、Windows からアクセスできなくなったのは不便だ。どうしようか。

[追記]

とりあえず、データバックアップ用サーバの nightschool にデータを移動して、Samba サーバを立てた。nightschool は CentOS 7.7 だけど、すんなりといった。何が違うんだ。

とにかく、データに Windows からもアクセスできるようにはなったので良しとする。上に書いたように Samba は Windows マシンのデータバックアップ用途だったので、そういう意味では nightschool にまとまってよかったのかも。

ユーザを限定した共有フォルダを作る件についてはまた今度。

Ubuntu 16.04 に Dropbox をインストール

メインマシンの apostrophe (OS は Ubuntu 16.04 LTS)に Dropbox をインストールする。

まずはこのページから .deb ファイルをダウンロード。で、インストールする。.deb ファイルのインストールは dpkg コマンド。apt じゃないんだな。

takatoh@apostrophe $ cd Downloads
takatoh@apostrophe $ ls
dropbox_2019.02.14_amd64.deb
takatoh@apostrophe $ sudo dpkg -i dropbox_2019.02.14_amd64.deb
[sudo] takatoh のパスワード: 
以前に未選択のパッケージ dropbox を選択しています。
(データベースを読み込んでいます … 現在 239399 個のファイルとディレクトリがインストールされています。)
dropbox_2019.02.14_amd64.deb を展開する準備をしています …
dropbox (2019.02.14) を展開しています…
dpkg: 依存関係の問題により dropbox の設定ができません:
 dropbox は以下に依存 (depends) します: libpango1.0-0 (>= 1.36.3) …しかし:
  パッケージ libpango1.0-0 はまだインストールされていません。

dpkg: パッケージ dropbox の処理中にエラーが発生しました (--install):
 依存関係の問題 - 設定を見送ります
man-db (2.7.5-1) のトリガを処理しています …
desktop-file-utils (0.22-1ubuntu5.2) のトリガを処理しています …
bamfdaemon (0.5.3~bzr0+16.04.20180209-0ubuntu1) のトリガを処理しています …
Rebuilding /usr/share/applications/bamf-2.index…
gnome-menus (3.13.3-6ubuntu3.1) のトリガを処理しています …
mime-support (3.59ubuntu1) のトリガを処理しています …
hicolor-icon-theme (0.15-0ubuntu1.1) のトリガを処理しています …
処理中にエラーが発生しました:
 dropbox

あれ、エラーが発生した。libpango1.0-0 っていうパッケージがインストールされてないみたいだ。インストールする。こんどは apt で。

takatoh@apostrophe $ sudo apt install libpango1.0-0

もういちど Dropbox のインストール。

takatoh@apostrophe $ sudo dpkg -i dropbox_2019.02.14_amd64.deb
(データベースを読み込んでいます … 現在 239431 個のファイルとディレクトリがインストールされています。)
dropbox_2019.02.14_amd64.deb を展開する準備をしています …
dropbox (2019.02.14) で (2019.02.14 に) 上書き展開しています …
dropbox (2019.02.14) を設定しています …
Please restart all running instances of Nautilus, or you will experience problems. i.e. nautilus --quit
Dropbox installation successfully completed! You can start Dropbox from your applications menu.
man-db (2.7.5-1) のトリガを処理しています …
desktop-file-utils (0.22-1ubuntu5.2) のトリガを処理しています …
bamfdaemon (0.5.3~bzr0+16.04.20180209-0ubuntu1) のトリガを処理しています …
Rebuilding /usr/share/applications/bamf-2.index…
gnome-menus (3.13.3-6ubuntu3.1) のトリガを処理しています …
mime-support (3.59ubuntu1) のトリガを処理しています …
hicolor-icon-theme (0.15-0ubuntu1.1) のトリガを処理しています …

こんどは大丈夫のようだ。しばらく待つと、Dropbox のウィンドウが立ち上がるので、指示に従って Dropbox をスタート。あとはアカウントの設定をすれば、ファイルの同期が始まる。

データバックアップサーバ

データのバックアップサーバを作った。これまでは各マシンに外付け HDD をつけてそこにバックアップしてたけど、バックアップサーバに一元化することにした。バックアップサーバには新しく買った 6TB の外付け HDD を取り付けた。

バックアップの方法はこれまで通り rsync を使うんだけど、ネットワーク越しにバックアップサーバにバックアップすることになる。

具体的な手順は過去記事に譲ろう。

順次バックアップ設定を変えていって、バックアップサーバに集約する。

とすると、さて、外付け HDD が4つ余ることになるんだけど、どうしようか……。

rsyncで別のマシンにファイルをバックアップする

ファイルのバックアップというと、今までは同じマシンの外付けハードディスクに rsync でコピーしていた。こんな感じ。

rsync -av --delete /home/takatoh/sulaiman/ /media/opabinia/backup/sulaiman

これをスクリプトにして cron で自動的にバックアップしていたわけだ。

さて、先日、PC が1台余ったってことを書いた。何に使おうか考えていたんだけどファイルのバックアップサーバにしようと思う。

そこで今日はその前段階として、コピー元のマシン(wplj)から別のマシン(apostrophe)に rsync でファイルをバックアップすることを試してみる。↓このページが参考になった。

 cf. いますぐ実践! Linux システム管理 / Vol.009

前提条件

  • バックアップ元マシン:wplj、ユーザ:takatoh、ディレクトリ:~/sulaiman
  • バックアップ先マシン:apostrophe、ユーザ:sulaiman、ディレクトリ:~/backup/sulaiman

バックアップの方法

別のマシンにバックアップをするのは難しいかと思ったけど、大したことはない。ユーザ名とホスト名を指定してやればいいだけだ。

takatoh@wplj $ rsync -azv -e ssh --delete ~/sulaiman/ sulaiman@apostrophe:~/backup/sulaiman

-z は転送時にファイルを圧縮するオプション。-e ssh は ssh を利用するオプションだ。これで無事にバックアップできる。

ただし、このままでは実行するたびにパスワードを入力しなきゃならない。cron を使って自動でバックアップするには使えない。

sshの鍵を利用

パスワードを入力しないで済むようにするには、あらかじめ両方のマシンに ssh の鍵を仕込んでおけばいい。今回は新たにバップアップ用の鍵を作ることにしよう。

takatoh@wplj $ ssh-keygen -f ~/.ssh/synckey -N ""

これで ~/.ssh ディレクトリに synckey と synckey.pub というファイルができる。前者が秘密鍵、後者が公開鍵だ。この公開鍵をバックアップ先のマシン(apostrophe)にコピーする。

takatoh@wplj $ scp ~/.ssh/synckey.pub sulaiman@apostrophe:~/.ssh/

そして、バップアップ先のマシンで、コピーされた公開鍵(~/.ssh/synckey.pub)を ~/.ssh/authorized_key ファイルに追加する。

sulaiman@apostrophe:~$ cd .ssh
sulaiman@apostrophe:~/.ssh$ cat synckey.pub >> authorized_keys
sulaiman@apostrophe:~/.ssh$ chmod 600 authorized_keys
sulaiman@apostrophe:~/.ssh$ rm synckey.pub

これでパスワードなしでバックアップできるようになったはずだ。つぎのようにする。

takatoh@wplj $ rsync -azv -e "ssh -i ~/.ssh/synckey" --delete ~/sulaiman/ sulaiman@apostrophe:~/backup/sulaiman

OK、うまくいった。これをスクリプトにしてやれば cron で自動化することができる。

DELL製PCにCentOS7をインストールしてもブートできない

昨日の話。サーバにしていた PC がダメになった。しばらく前から異音がしていて、これはもうヤバげだな、という感じではあったんだけど、昨日リブートしてみようと思い立ってそうしてみたら、ダメになった。余計なことはするもんじゃない。

もう少し正確に言うと、OS (CentOS7だ)は起動する。Nginx も起動する。けど、肝心の web アプリが起動しない、という状態。リブートしただけなので、何も変わっていないはずなんだけど、起動しないものは起動しない。そもそも上に書いたとおりハード的にもヤバそうだったので、早々に諦めて、新しいPCに移行することにした。実は、しばらく前から異音が発生していたので新しい PC を買ってあったのだ。

新しい PC は、DELL 製の OptiPlex 3060 Micro という機種。これに CentOS7 をインストールしようというわけだ。BIOS (というか最近のは UEFI というらしい)の設定を変更して外付け DVD ドライブからブートするようにしてインストール。インストール自体は特につまづくこともなく終了(過去記事を見てほしい)。

ところが、DVD を抜いてリブートしてもできない。ブータブルなメディアが見つからない、とかなんとかそんなことを言われる。そんなこと言われても、インストールできたんだからなんとかなるだろう、と思って UEFI の設定を変更しようと試みるも、UEFI というのは Windows 向けの設定になっているし(変更しようにもファイルシステムが見つからないと言われる)、レガシーな BIOS (インストール時にはこちらに設定した)には内部のハードディスクからブートするという選択肢がない。ように見える。

BIOS に内部ハートディスクからブートする機能がないとすると、UEFI を使うしか無いんだけど、どうもググった限りで分かったのは CentOS7 は UEFI に対応していないらしいということと、Ubuntu は対応しているらしい、ということ。

そこで、Ubuntu (18.04 の日本語REMIX版)をインストールしてみた。結果、今度はちゃんとブートするようになった。まだ OS をインストールしただけで、web アプリの構築とかしてないんだけど、今のところ大丈夫そうだ。

というところまでが、昨日の話。今日は web アプリを構築して早くサーバとして復帰させたい……んだけど、今日は時間がないんだよなぁ。

[追記]

何とか、最低限の復旧は果たした。

あと、ホスト名は unclemeat にした。

UbuntuにRMagickをインストール

環境

takatoh@apostrophe $ cat /etc/os-release
NAME="Ubuntu"
VERSION="16.04.5 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.5 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial
takatoh@apostrophe $ ruby -v
ruby 2.3.1p112 (2016-04-26) [x86_64-linux-gnu]

↓このページによると、ImageMagick がバージョン7以降だと RMagick は使えないらしい。

 cf. RMagickのインストールで奈落に落ちた – Qiita

takatoh@apostrophe $ convert -version
Version: ImageMagick 6.8.9-9 Q16 x86_64 2018-09-28 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2014 ImageMagick Studio LLC
Features: DPC Modules OpenMP
Delegates: bzlib cairo djvu fftw fontconfig freetype jbig jng jpeg lcms lqr ltdl lzma openexr pangocairo png rsvg tiff wmf x xml zlib

6.8.9 だ、ラッキー。

依存パッケージとRMagickのインストール

まずは依存パッケージから。

takatoh@apostrophe $ sudo apt install libmagickcore-dev libmagickwand-dev

そして、RMagick。

takatoh@apostrophe $ sudo gem install rmagick
Building native extensions. This could take a while…
Successfully installed rmagick-2.16.0
Parsing documentation for rmagick-2.16.0
Installing ri documentation for rmagick-2.16.0
Done installing documentation for rmagick after 4 seconds
1 gem installed

完了。

Gem in a Boxでオレオレgemサーバをたてる

自分でしか使わない、外部には公開できないような gem がいくつかあるので、gem サーバをたてることにした。Gem in a Box (geminabox)は、プライベートな gem サーバだ。gem コマンドでインストールして、ちょっと設定ファイルを書くだけで使えるようになる。

じゃ、いってみよう。

環境

  • Ubuntu 16.04 LTS
  • Ruby 2.3.1p112

インストールと設定

前述したように gem コマンドでインストールできる。

takatoh@wplj $ sudo gem install geminabox

~/geminabox ディレクトリを作って、設定ファイルを書く。

takatoh@wplj $ mkdir ~/geminabox
takatoh@wplj $ cd ~/geminabox
takatoh@wplj $ vim config.ru

設定ファイルはこんな感じ、っていうかこれだけ。

require "geminabox"

Geminabox.data = "/home/takatoh/geminabox/data"
run Geminabox::Server

gem ファイルが格納される data ディレクトリを作る。

takatoh@wplj $ mkdir data

これで Gem in a Box 自体のインストールと設定は完了。

Supervisord で管理

さて、これをデーモンにする必要があるんだけど、昨日 Supvervisord を試したので今日も同じようにしてみる。設定ファイル /etc/supervisord.d/geminabox.ini をつぎのように書いた。

[program:geminabox]
command=/usr/local/bin/rackup -p 9999
process_name=geminabox
user=takatoh
directory=/home/takatoh/geminabox
autostart=true
autorestart=true
stdout_logfile=/home/takatoh/geminabox/geminabox.log
stdout_logfile_maxbytes=1M
stdout_logfile_backups=7
stdout_capture_maxbytes=1M
redirect_stderr=true

これで OK のはず。動かしてみよう。

takatoh@wplj $ supervisorctl reload
Restarted supervisord
takatoh@wplj $ supervisorctl status
geminabox RUNNING pid 26835, uptime 0:00:08
sulaiman RUNNING pid 26836, uptime 0:00:08

ちゃんと動いてるようだ。

Nginxのバーチャルホスト設定

gembox というホスト名でアクセスできるように Nginx を設定する。/etc/nginx/sites-available/gembox が設定ファイルだ。

upstream geminabox {
    server 127.0.0.1:9999;
}

server {
    # port
    listen      80;

    # server name
    server_name gembox;

    # document root
    root        /home/takatoh/geminabox;

    # index
    #index       index.php index.html index.htm;

    # log files
    access_log /var/log/nginx/gembox/access.log combined;
    error_log  /var/log/nginx/gembox/error.log  warn;

    keepalive_timeout     60;
    proxy_connect_timeout 60;
    proxy_read_timeout    60;
    proxy_send_timeout    60;

 
    location / {
        proxy_set_header Host $http_host;
        proxy_pass http://geminabox;
    }
}

/etc/nginx/sites-enabled/gembox にリンクをはる。

takatoh@wplj $ sudo ln -s /etc/nginx/sites-available/gembox sites-enabled/gembox

ログファイル用のディレクトリを作成。

takatoh@wplj $ sudo mkdir /var/log/nginx/gembox

そして、Ngixn をリロード。

takatoh@wplj $ sudo systemctl reload nginx

これで完了。ほかのマシンからブラウザで http://gembox/ にアクセスすると、期待どおり Gem in a Box のページにアクセスできた。

[追記]

アクセスはできたけど、試しに gem ファイルを1つアップロードしてみたら「uninitialized constant Gem::Util」というエラーが出てしまった。なんだこりゃ?

[追記2]

解決編。rubygems 自体が古いのが原因だったようだ。

takatoh@wplj $ sudo gem update --system
takatoh@wplj $ gem -v
3.0.1

念のため、データ置き場を作りなおす。

takatoh@wplj $ cd ~/geminabox
takatoh@wplj $ rm -rf data
takatoh@wplj $ mkdir data

リスタート。

takatoh@wplj $ supervisorctl restart geminabox
geminabox: stopped
geminabox: started

これで無事、オレオレgemをアップロードできるようになった。

Supervisorで自作プログラムをデーモン化

自作のプログラムやスクリプトをデーモン化したい場合がある。でも、デーモンとして動作するようには作っていない……そういう時には Supervisor の出番だ。

Supervisor は Python 製のツールで、デーモンとして動作するように作られていないプログラムでもデーモン化できる。Supervisor 自体は root 権限でデーモンとして動かす必要があるけど、その下にぶら下がるプログラムはユーザー権限で管理できるのがいい点だ。

今日は、Ubuntu マシンの wplj に Supervisor をインストールして、以前 Go で作った画像アップローダを動かしてみる。

環境

  • Ubuntu 16.04 LTS
  • Python 2.7.12

Supervisorのインストールといろいろ下準備

Supervisor 自体は pip でインストールできる。

takatoh@wplj $ sudo pip install supervisor

/etc/supervisord.conf にデフォルトの設定ファイルを生成。

takatoh@wplj $ sudo echo_supervisord_conf > /etc/supervisord.conf
-bash: /etc/supervisord.conf: 許可がありません

あれ、sudo つけてるのになんでだ?よくわからないけど sudo -s してからやってみよう。

takatoh@wplj $ sudo -s
root@wplj # echo_supervisord_conf > /etc/supervisord.conf

今度はできた。つぎ、include 設定ファイル用のディレクトリを作成。

root@wplj # mkdir /etc/supervisord.d

supervisord 自体のはくログ周りの設定。デフォルトでは /tmp/supervisord.log に吐き出すことになっているので、設定ファイル /etc/supervisord.conf を修正して /var/log/supervisord.log に吐くようにする。

[supervisord]
;logfile=/tmp/supervisord.log ; main log file; default $CWD/supervisord.log
logfile=/var/log/supervisord.log

PID ファイルの設定。/var/run 以下に置くように変更。

;pidfile=/tmp/supervisord.pid ; supervisord pidfile; default supervisord.pid
pidfile=/var/run/supervisord.pid

/etc/supervisord.d 以下のファイルを include するように変更。これで設定ファイルの修正は終了。

[include]
files = supervisord.d/*.ini

supervisord自体のサービス登録

/etc/systemd/system/supervisord.service ファイルを作成する。

[Unit]
Description=Supervisor process control system for UNIX
Documentation=http://supervisord.org/
After=network.target

[Service]
ExecStart=/usr/local/bin/supervisord -n -c /etc/supervisord.conf
ExecStop=/usr/local/bin/supervisorctl $OPTIONS shutdown
ExecReload=/usr/local/bin/supervisorctl $OPTIONS reload
KillMode=process
Restart=on-failure
RestartSec=50s

[Install]
WantedBy=multi-user.target

起動と自動起動の登録

root@wplj # systemctl start supervisord
root@wplj # systemctl enable supervisord.service
Created symlink from /etc/systemd/system/multi-user.target.wants/supervisord.service to /etc/systemd/system/supervisord.service.

自作プログラムの配置

Go で作った画像アップローダ sulaiman を配置する。こんなふうにした。

takatoh@wplj $ tree ~/sulaiman
/home/takatoh/sulaiman
├── config.json
├── photos
│   ├── img
│   └── thumb
├── static
│   ├── css
│   │   └── style.css
│   ├── html
│   │   └── index.html
│   └── js
│   └── sulaiman.js
└── sulaiman

試しに動かしてみる。

takatoh@wplj $ ./sulaiman
_ _ / // /
/ // / \/ _ \
//__////_/ v3.3.5
High performance, minimalist Go web framework
https://echo.labstack.com
_________________________________O/_

O\
⇨ http server started on [::]:9099

大丈夫そうだ。

プロセス管理登録と起動確認

配置したプログラムを supervisord の管理下に登録する。/etc/supervisord.d 以下に設定ファイル sulaiman.ini を作る。

[program:sulaiman]
command=/home/takatoh/sulaiman/sulaiman
process_name=sulaiman
user=takatoh
directory=/home/takatoh/sulaiman
autostart=true
autorestart=true
stdout_logfile=/home/takatoh/sulaiman/sulaiman.log
stdout_logfile_maxbytes=1MB
stdout_logfile_backups=7
stdout_capture_maxbytes=1MB
redirect_stderr=true

これで OK のはずだ。確認してみよう。

takatoh@wplj $ supervisorctl start sulaiman
error: , [Errno 13] Permission denied: file: /usr/lib/python2.7/socket.py line: 228

はぁ?どういうこと?

問題解決

ソケット周りでエラーが出てるようだ。権限がないとかいってる。supervisord の設定ファイルを眺めてみると、ソケットファイルのモードを設定する項目が見つかった。これを変更してみよう。

[unix_http_server]<br>file=/tmp/supervisor.sock   ; the path to the socket file<br>;chmod=0700                 ; socket file mode (default 0700)<br>chmod=0777

supervisord をリロード。

takatoh@wplj $ sudo systemctl reload supervisord

確認。

takatoh@wplj $ supervisorctl status sulaiman
sulaiman RUNNING pid 19356, uptime 0:00:22

こんどは OK。

これで、プログラムやスクリプトを簡単にデーモン化できるようになった。

参考ページ

 cf. Supervisorで簡単にデーモン化 – Qiita