新しいサイトを作った

今日の話題は Scala からはなれて、新しいサイトを作った話。↓ここ。

 cf. Optic Acid

JETBOY っていうレンタルサーバを借りて、WordPress で作った。ドメインも取った。

このブログはプログラミングとかサーバ管理とかの記事なので、Optic Acid のほうではもっと気ままに記事を書くつもり。いつまで続くかわからないけどね。

さて、ちょっと技術的な話もしておこう。

JETBOY っていうレンタルサーバの特徴は、ひとつには月額290円(年払い、一番安いプラン)っていう安さもあるんだけど、オール SSD と、LiteSpeed っていう Web サーバを採用しているところだろう。LiteSpeed は Apache や Nginx より3倍速いとか書いてある。

これを見て使ってみたくなったってのも、新しいサイトを作った理由のひとつだね。まぁ、そんなに速いサーバいらないって話もあるんだけどさ。

MediaWikiのバックアップ

先日、データのバックアップサーバを作ったので、MediaWiki で運用している wiki のバックアップもすることにした。

MediaWiki でバックアップが必要なのはつぎの2つ。

  • /var/www/html/wiki 以下のファイル群
  • データベース

ファイル群は単純に rsync でバックアップする。データベースは mysqldump コマンドでファイルに書きだしたあと、gzip で圧縮してから rsync でバックアップする。

こんなスクリプトにした。

mysqldump -hlocalhost -uxxxx -pyyyy wiki | gzip > wiki.sql.gz
rsync -av -e "ssh -i ~/.ssh/synckey" --delete /home/takatoh/wiki.sql.gz takatoh@nightschool:/mnt/pikaia/backup/wiki/db
rsync -azv -e "ssh -i ~/.ssh/synckey" --delete /var/www/html/wiki/ takatoh@nightschool:/mnt/pikaia/backup/wiki/wiki

xxxx はデータベースのユーザー名、yyyy はパスワード、wiki がデータベース名だ。

これで試してみたら OK だったので、cron に登録して毎日バックアップすることにした。

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

データのバックアップサーバを作った。これまでは各マシンに外付け 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 で自動化することができる。

修理に出していたPCが戻ってきた

先月末にダメになってしまった PC、修理に出していたのが戻ってきた。メモを見ると DELL のサポートに電話して修理依頼をしたのが4月9日なので、1週間かからずに戻ってきたわけだ。

故障個所は CPU ファンだった。どうやらファンを交換して修理完了したようだ。ハードディスクのデータは保証しない、といわれていたけど、起動してみたら元のまま CentOS7 が立ち上がった。データも大丈夫のようだ。

先日のエントリに書いた通り、この PC(ホスト名は nightschool)はインターネットに公開していたサーバで、web アプリを2つ動かしていた。両方とも新しいサーバ(unclemeat)に引き継いでいるので、余った形になる。

さて、何に使おうか。

Windows10+Tomcat上でGitBucketを動かす

GitBucket という GitHub のクローンを見つけた。GitHub クローンといえば GitLab が有名だけど、web の情報を見ていると構築するのが結構面倒そうで、試したことがなかった。その点、GiuBucket は war ファイルを Java で実行するだけ、という簡単さ。早速試してみよう。

前提条件

  • windows10
  • Java はインストール済み

まずは簡単に

GitBucket は たけぞうさんという方が Scala で書いた GitHub クローンだ。war ファイルで配布されているので、ダウンロードしたらすぐに実行できる。

 cf. GitBucket 4.31.0、4.31.1をリリースしました – たけぞう瀕死ブログ

4.31.1 が最新バージョンのようなので、上のページからリンク先にとんで、gitbucket.war ファイルをダウンロードする。あとは実行するだけだ。

^o^ > java -jar gitbucket.war

これだけで OK。http://localhost:8080/ にブラウザでアクセスするとアプリが動作している。

使い方も簡単

デフォルトで root ユーザーが用意されている。まずはこの root でサインイン(パスワードも root)して、右上のプルダウンメニューから System Administration を選び、ユーザーを追加する。今回は takatoh を追加した。ユーザー名とパスワード、フルネーム、メールアドレスが必須みたいだ。

あとは、作ったユーザーでサインインしなおせば、自由にリポジトリを作ったりできる。GitHub を使い慣れていれば迷うこともなさそうだ。

Tomcatをインストール

さて、うまく動いたわけだけど、いちいちコマンドラインから実行するのでは面倒で仕方がない。というわけで、Apache Tomcat の出番だ。

Tomcat は↓ここから最新版(9.0.17)をダウンロードした。

 cf. Tomcat 9 Software Downloads – Apache Tomcat

32-bit/64-bit Windows Service Installer ってやつね。ファイル名は apache-tomcat-9.0.17.exe だった。このファイルを実行すればインストールされる。

インストール自体は、途中の Tomcat Administrator Login のユーザー名とパスワードを入力した以外はすべてデフォルトにした。ただし、最後の Run Apache Tomcat のチェック外してすぐに実行しないようにする。

GitBucketをインストール

インストールといっても、Tomcat のインストールフォルダにある webapps フォルダに gitbucket.war ファイルをコピーするだけだ。

次に、環境変数 GITBUCKET_HOME を設定する。これは データベースや各リポジトリを格納するフォルダを指定する。これを指定しておかないと、データがどこにあるのかわからない。今回は C:\GitBucket に設定した。

Tomcatを起動

スタートメニューから、Apache Tomcat 9.0 Tomcat9 → Configure Tomcat を選択。開いたウィンドウで、Startup type を Automatic にして Start ボタンをクリック。これで Tomcat が起動する。Startup type を Automatic にしたのは、Windows 起動時に自動で Tomcat も起動させるため。

GitBucketにアクセス

Tomcat はポート8080で待ち受けているので、http://localhost:8080/githubucket/ にアクセスする。コマンドラインから立ち上げたときとパスが違うので注意。だけど、これで無事アクセスできた。

さいごに

プライベートでは GitHub なり BitBucket なりに自由にアクセスできるので、わざわざ構築する必要もないのだけど、会社の PC からはアクセスできない(制限されている)ので、そういう環境では役に立つだろう。週が明けたらやってみよう。

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 にした。

webフォントを使ってみた

さくらインターネットでは、無料でモリサワのwebフォントが使える(30書体)というので、使ってみた。このブログじゃなくて、ホームページ(PanicBlanket)のほうだ。

 cf. レンタルサーバ Webフォント機能 – さくらのサポート情報

利用するには、まずサーバコントロールパネルにログインして、利用するドメインを登録する。登録できるドメインはメニューから選べばいい。今回は panicblanket.com を登録した。

次に、html ファイルに JavaScript のファイルを読み込む設定をする。なんでフォントを使うのに JavaScript が要るのかわかんないんだけど。まぁ、そういう説明になってるので素直に従う。

html といっても、ホームページは静的サイトジェネレータの Middleman で作っているので、layouts/laytout.erb ファイルにつぎの行を追加した。

    <script type="text/javascript" src="//webfonts.sakura.ne.jp/js/sakura.js"></script>

次にスタイルシートで適当にフォントを設定してやる。ここは書くのがめんどくさいので割愛。そんでもってサイトのビルド。

takatoh@apostrophe $ bundle exec middleman build

あとは、新しくなったファイルを FTP でサーバにアップしてやればOK。


さくらのVPSのサイトをHTTPS化

さくらの VPS で運用しているサイト(Railsアプリ)を Let’s Encrypt で HTTPS 化した。言っとくけどこのブログじゃないよ。

HTTPのポートを開放

まず、HTTPS のポート 443 を開放する。/etc/sysconfig/iptables ファイルを編集。

[takatoh@tk2-254-36564 ~]$ cd /etc/sysconfig
[takatoh@tk2-254-36564 sysconfig]$ sudo vim iptables

つぎの行を追加。

-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

iptables を再起動。

[takatoh@tk2-254-36564 sysconfig]$ sudo service iptables restart
iptables: Setting chains to policy ACCEPT: filter [ OK ]
iptables: Flushing firewall rules: [ OK ]
iptables: Unloading modules: [ OK ]
iptables: Applying firewall rules: [ OK ]
iptables: Loading additional modules: ip_conntrack_ftp [ OK ]

certbot-auto のセットアップと証明書の自動生成

「certbot-auto」は Let’s Encrypt が提供しているクライントツールで、SSL証明書を取得したり延長したりできる。ここでは、最新版を取得する。

[takatoh@tk2-254-36564 bin]$ sudo wget https://dl.eff.org/certbot-auto
--2019-01-13 09:41:36-- https://dl.eff.org/certbot-auto
dl.eff.org をDNSに問いあわせています… 151.101.72.201, 2a04:4e42:36::201
dl.eff.org|151.101.72.201|:443 に接続しています… 接続しました。
HTTP による接続要求を送信しました、応答を待っています… 200 OK
長さ: 63562 (62K) [application/octet-stream]
`certbot-auto' に保存中

100%[======================================>] 63,562 --.-K/s 時間 0.002s

2019-01-13 09:41:39 (24.3 MB/s) - `certbot-auto' へ保存完了 [63562/63562]

[takatoh@tk2-254-36564 bin]$ sudo chmod 700 /usr/bin/certbot-auto

いまインストールした certbot-auto を使って、証明書を自動生成する。

[takatoh@tk2-254-36564 ~]$ sudo certbot-auto certonly --webroot -w /var/www/lathercraft/public -d www.lathercraft.net --email lathercraft@gmail.com

途中、いろんなパッケージをインストールしたりするのでy(yes)を入力する。しばらくすると利用規約が表示されるので、A(agree)を入力。最後に↓こんなメッセージが出ればOK。

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/www.lathercraft.net/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/www.lathercraft.net/privkey.pem
Your cert will expire on 2019-04-12. To obtain a new or tweaked
version of this certificate in the future, simply run certbot-auto
again. To non-interactively renew all of your certificates, run
"certbot-auto renew"
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
- If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

- We were unable to subscribe you the EFF mailing list because your
e-mail address appears to be invalid. You can try again later by
visiting https://act.eff.org.

……じゃないな、e-mail が invalid だと言ってる。あとから試せるとも言ってるので、とりあえず先に進む。この時点で証明書類はこんな感じになっている。

[takatoh@tk2-254-36564 ~]$ sudo ls -l /etc/letsencrypt/live/www.lathercraft.net/
合計 4
-rw-r--r-- 1 root root 692 1月 13 09:53 2019 README
lrwxrwxrwx 1 root root 43 1月 13 09:53 2019 cert.pem -> ../../archive/www.lathercraft.net/cert1.pem
lrwxrwxrwx 1 root root 44 1月 13 09:53 2019 chain.pem -> ../../archive/www.lathercraft.net/chain1.pem
lrwxrwxrwx 1 root root 48 1月 13 09:53 2019 fullchain.pem -> ../../archive/www.lathercraft.net/fullchain1.pem
lrwxrwxrwx 1 root root 46 1月 13 09:53 2019 privkey.pem -> ../../archive/www.lathercraft.net/privkey1.pem

Nginxの設定

SSL 対応にする。こんなふうに書き換える。

    #listen      80;
    listen      443 ssl;

    ssl_certificate      /etc/letsencrypt/live/www.lathercraft.net/cert.pem;
    ssl_certificate_key  /etc/letsencrypt/live/www.lathercraft.net/privkey.pem;

Nginx を再起動。

[takatoh@tk2-254-36564 conf.d]$ sudo service nginx restart
Stopping nginx: [ OK ]
Starting nginx: [ OK ]

これでOKのはず。まだアプリが SSL 対応していないのでバナー画像に https でアクセスしてみたら、ちゃんと表示された。なのでここまではOKのようだ。

RailsアプリのSSL対応

これは簡単。config/envronments/production.rb ファイルのつぎの箇所を修正すればいい。

# config.force_ssl = true
config.force_ssl = true

コメントアウトしてあるのを外すだけだ。そして再起動。

[takatoh@tk2-254-36564 environments]$ sudo service unicorn_lathercraft restart
reloaded OK

OK。大丈夫そうだ。

httpをhttpsにリダイレクト

最後に、http でのアクセスを https にリダイレクトする設定をする。Nginx の設定に戻ってつぎの設定を追加する。

server {
    listen       80;
    server_name  www.lathercraft.net;
    return       301 https://www.lathercraft.net;
}

Nginx を再起動して完了。

証明書の自動更新設定

Let’s Encrypt の証明書は有効期限が3ヶ月と短いので、自動更新するように設定する。更新は certbot-auto renew コマンドでできるので、これを root ユーザの cron に登録する。

[takatoh@tk2-254-36564 ~]$ sudo -s
[root@tk2-254-36564 takatoh]# crontab -l
no crontab for root
[root@tk2-254-36564 takatoh]# crontab -e
0 4 * * 0 certbot-auto renew --post-hook "service unicorn_lathercraft restart" > /dev/null 2> /dev/null

これで毎週月曜日の午前4時に更新するようになる。

[追記]

上の、Nginx のリダイレクトの設定では、http でのアクセスはどんなパスでも全て https のルートにリダイレクトされてしまう。なので、つぎのように変更した。

server {
    listen       80;
    server_name  www.lathercraft.net;

    location ~ ^/(.*)$ {
        return 301 https://www.lathercraft.net/$1;
    }
}

これで各ページも https にリダイレクトされるようになった。