![(please configure the [header_logo] section in trac.ini)](/trac/original/ideanote/chrome/site/your_project_logo.png){kind=logo}
| Version 3 (modified by , 5 years ago) ( diff ) |
|---|
さくらの VPS セットアップメモ 〜2G プラン据え置き Ubuntu16.04 入れ替え編 (パート2)〜
パート1 からの続きです…。
Web サーバー設定ふたたび (Nginx 移行)
最近は割といろんなものが Nginx で動くっぽいですね (というより大抵 FastCGI でどうにかするっぽい)。一度触ってみておきたかったというのもあるのですが、 Apache のモジュールモデルに若干疲れたというのもあり…。
で、構成を単純化するため、全般的に Nginx で動かす想定で、まずは Apache2 を削除してしまうことにしました。上の方で書いた内容が全て無駄になりますが… (((((((;/^o^)/
$ sudo su - # apt remove apache2 # apt install nginx
MySQL は代わりに mariadb をインストール済みなので不要ですね。手元 PC の HOSTS 書き換えでとりあえず Nginx がちゃんと動いているのは確認。
SSL 設定
たまたまこの時点で Let's Encrypt による mail.harapeko.jp ドメインが証明期限切れ近かったので、 certbot-auto を実行。なお Apache から Nginx に環境を換えた影響か、この時点では ./certbot-auto renew はうまく動かなかった。
# exit $ cd ~/certbot $ ./certbot-auto Requesting to rerun ./certbot-auto with root privileges... (中略... 何故か名前の設定が見つからんと言われるのでドメイン名を入力) No names were found in your configuration files. Please enter in your domain name(s) (comma and/or space separated) (Enter 'c' to cancel): mail.harapeko.jp Cert is due for renewal, auto-renewing... (中略... どうやら Apache を使う場合と Nginx を使う場合とで設定を残す場所が異なる模様) Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/default (ここからおせっかい機能が走り出す... せっかくなので HTTPS へリダイレクトする設定を施してもらった) Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2 Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/default (残りの出力は略... どうやらうまくいったようだ) $
実際 http://mail.harapeko.jp/ にアクセスすると https://mail.harapeko.jp/ にリダイレクトされるようになった。メーラーも問題なく動いている模様。
certbot による Nginx の設定の変更は /etc/nginx/sites-available/default に対して行われた模様。
メインコンテンツ
/etc/nginx/sites-available/default の設定内容によれば、メインコンテンツは /var/www/html を参照している模様。ここに配置すれば良いはず。
(以下、コメント行の類は概ね省略しています)
server {
listen 80 default_server;
listen [::]:80 default_server;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name _;
location / {
try_files $uri $uri/ =404;
}
}
既に当該ディレクトリには旧会社時代のコンテンツを置いていたものの、 PHP 駆動だったので index.html は置いておらず、 http://www.harapeko.jp/ としてアクセスすると nginx のデフォルトページが表示される状態でした。試しに index.html を配置してみたところ、それが代わりに表示されるようになりました。
と、ここで https://mail.harapeko.jp/ にアクセスしてみたら同じものが表示される状態だったので、こちらは別のファイルが表示されるよう設定を修正。
server {
root /var/www/vhosts/mail/html; # <--- ここを修正
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name mail.harapeko.jp; # managed by Certbot
location / {
try_files $uri $uri/ =404;
}
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/mail.harapeko.jp/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/mail.harapeko.jp/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
当該ディレクトリを作成し、 index.html も別途作成したところ、そちらが表示されるようになりました。
メインサイトの名前解決
サブドメイン www を新サーバーに切り替えます。ついでなのでこのタイミングでネームサーバーの切り替えも行ってしまうことにします。
まずは旧サーバー側のネームサーバーで www の IP アドレスを新サーバーに向くように変更。
# vim /var/named/chroot/var/named/harapeko.jp.zone (...設定を修正) # service named restart
$TTL 1D
@ IN SOA onaka.harapeko.jp. root.onaka.harapeko.jp. (
2019102101 ; serial
3600 ; refresh 1h
900 ; retry 15m
3600000 ; expiry 1000h
3600 ; minimum 24h
)
;
IN NS ns.harapeko.jp.
IN MX 0 mail.harapeko.jp.
mail IN MX 0 mail.harapeko.jp.
onaka IN A 49.212.128.142
ns IN A 49.212.128.142
mail IN A 153.126.157.107
www IN CNAME mail ; <--- 現状新サーバー用に使っている mail サブドメインを参照するよう変更
daiyokujo IN CNAME onaka ; for harapeko.asablo.jp/blog
blog IN CNAME onaka
developer IN CNAME onaka
svn IN CNAME onaka
test IN CNAME onaka
すぐには反映されない模様。やっぱりしばらくは待つ必要があるか…。
新サーバーの設定もやってしまうことにした。 chroot で動かすつもりだったが、うまく動かせなかったので、一旦 chroot を使わない設定を施しました。 chroot を使う設定についてはこの辺のサイトにまとまっているようなので、後ほど再チャレンジしてみることにします。
設定に際しては、この辺の記事を参考にさせていただきました…。
設定対象ファイルをまるっと編集してしまいましょう。
# cd /etc/bind # vim -p named.conf
named.conf は他の設定ファイルを include しているだけですが、そのうち、デフォルトゾーンの設定を記述した named.conf.default-zones は権威 DNS サーバーを設定するなら不要なので、コメントアウトしてしまいます。
include "/etc/bind/named.conf.options"; include "/etc/bind/named.conf.local"; //include "/etc/bind/named.conf.default-zones"; // <--- 不要
named.conf.options では notify no と recursion no を追記、 auth-nxdomain は yes に変更しました。
options {
directory "/var/cache/bind";
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
//auth-nxdomain no; # conform to RFC1035
auth-nxdomain yes; // <--- ドメインが存在しない場合の応答時に AA ビットを必ず立てる設定。いちおう。
listen-on-v6 { any; };
notify no; // <--- ゾーンデータの更新通知はデフォルトで no にしておき、個別のゾーンに対して yes に設定する。
recursion no; // <--- 自分がマスターではないゾーンについてのクエリーを、再帰的に問い合わせしない設定。権威 DNS サーバーの場合は必須。
};
named.conf.local はコメントアウトされている zones.rfc1918 を include するの ではなく 、独自に作成するファイル zones.harapeko.jp を include するようにします。
// Consider adding the 1918 zones here, if they are not used in your // organization // include "/etc/bind/zones.rfc1918"; // <--- これはこのまま include "/etc/bind/zones.harapeko.jp"; // <--- こっちを追記
そして新たに :tabe zones.harapeko.jp して、以下の内容を書いて保存。
zone "harapeko.jp" {
type master;
file "/var/cache/bind/harapeko.jp.zone";
notify yes;
};
zone "107.157.126.153.in-addr.arpa" {
type master;
file "/var/cache/bind/harapeko.jp.rev";
notify yes;
};
実際の正引き・逆引きファイルも作成します。
# cd /var/cache/bind # vim harapeko.jp.zone (...正引きファイル編集) # vim harapeko.jp.rev (...逆引きファイル編集)
正引きファイルは旧サーバーからコピったものを一部編集。
$TTL 1D
@ IN SOA onaka.harapeko.jp. root.onaka.harapeko.jp. (
2019102102 ; serial
3600 ; refresh 1h
900 ; retry 15m
3600000 ; expiry 1000h
3600 ; minimum 24h
)
;
harapeko.jp IN NS ns.harapeko.jp. ; <-- このへんちょこっと書き方を変えてみた
harapeko.jp IN MX 0 mail.harapeko.jp. ; <--
onaka IN A 49.212.128.142
ns IN A 153.126.157.107 ; <---- レジストラに登録するネームサーバーを新サーバーに切り替えた想定
mail IN A 153.126.157.107
www IN CNAME mail
daiyokujo IN CNAME onaka ; for harapeko.asablo.jp/blog
blog IN CNAME onaka
developer IN CNAME onaka
svn IN CNAME onaka
test IN CNAME onaka
逆引きファイルはまんまコピってシリアル番号だけ書き換えただけなので略。
あとは bind9 を登録、再起動すれば ok 。
# systemctl enable bind9 # service bind9 restart # nslookup ns.harapeko.jp localhost Server: localhost Address: ::1#53 Name: ns.harapeko.jp Address: 153.126.157.107 #
旧サーバーで設定した www サブドメインの参照先変更はこの時点でとっくに反映されていましたが、せっかくなので JPDirect のホスト登録も変更します。 サイトログイン後、「ドメイン名共通 > ホスト情報変更申請」を選択し、ホスト名に「NS.HARAPEKO.JP」と入力 (ドロップメニューによる選択肢ではありません)。新しい IP アドレスを入力して完了。
www の SSL を設定
ふつうに certbot を動かすだけでいいはず。これは root からではなく一般ユーザーから。
$ ./certbot-auto -d www.harapeko.jp Requesting to rerun ./certbot-auto with root privileges... (中略 ...HTTP アクセス検証) Performing the following challenges: http-01 challenge for www.harapeko.jp Waiting for verification... Cleaning up challenges Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/default (おせっかい機能のリダイレクト設定) Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2 Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/default (どうやら成功したらしい) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Congratulations! You have successfully enabled https://www.harapeko.jp You should test your configuration at: https://www.ssllabs.com/ssltest/analyze.html?d=www.harapeko.jp - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (後略...認証鍵の在り処などの情報が表示されます) murachi@ik1-314-17353:~/certbot$
certbot による HTTPS へのリダイレクト設定は、 /etc/nginx/sites-available/default にひたすら追記する形で施されるらしい。
あとで手でファイルを分けたほうが良いかもしれんね(´･_･`)
ブログの稼働と名前解決
ブログの引っ越し自体は済んでいるので、 PHP を動かせるようにして名前解決と SSL 化までやってしまいましょう。
ちなみに今更ですが、 /etc/nginx/nginx.conf を確認すると、ユーザーは apache2 の場合と同じ www-data で動いているようですね。
user www-data; worker_processes auto; pid /run/nginx.pid;
さて、 PHP を FastCGI で動かすため、 php-fpm パッケージを導入します。
# apt install php-fpm
Nginx の設定にブログドメイン用の設定を追加します。まず /etc/nginx/sites-available/blog-wp を作成。
# cd /etc/nginx/sites-available # vim blog-wp
内容は、いくつかのサイトを参考にさせていただいた結果、以下の通りになりました。この時点ではまだ SSL は考慮していません。
server {
listen 80;
server_name blog.harapeko.jp;
location / {
root /var/www/vhosts/blog/html;
index index.php;
try_files $uri $uri/ @wordpress; # パーマリンクのための設定
}
location ~* /wp-config.php {
deny all;
}
location ~ \.php$ {
root /var/www/vhosts/blog/html;
fastcgi_pass unix:/run/php/php7.0-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
# パーマリンク URI の場合、 index.php を使うようにする
location @wordpress {
root /var/www/vhosts/blog/html;
fastcgi_pass unix:/run/php/php7.0-fpm.sock;
fastcgi_index index.php;
fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
include fastcgi_params;
}
location ~ /\.ht {
deny all;
}
}
で、これのシンボリックリンクを /etc/nginx/sites-enabled の下に作ります。
# cd ../sites-enabled # ln -s ../sites-available/blog-wp
PHP の FastCGI 用の設定ファイル /etc/php/7.0/fpm/pool.d/www.conf については、 Nginx のユーザーを www-data のまま変更していないため、こちらも特に変更すべき点はありません。
(この辺、 Apache2 と併用して動かす場合なんかはユーザーを別途作って区別したほうが良いのかもしれません)
PHP-FPM をサービス登録し、 Nginx と共に再起動すれば準備完了です。
# systemctl enable php7.0-fpm Synchronizing state of php7.0-fpm.service with SysV init with /lib/systemd/systemd-sysv-install... Executing /lib/systemd/systemd-sysv-install enable php7.0-fpm # service php7.0-fpm restart # service nginx restart
ローカルマシンの /etc/hosts を書き換えてアクセスしてみたところ、ちゃんとブログが動いているのを確認できました。
名前解決は /var/cache/bind/harapeko.jp.zone を書き換えて bind9 を restart させるだけです。 blog サブドメインの CNAME 先を mail に切り替えるだけなのでこれは流石に略。
ローカルマシンからサブドメイン名で新サーバーにアクセスできることを確認後、一般ユーザーから certbot-auto を実行し、 blog サブドメインも SSL 化。これも他のサブドメインの場合とやってることは変わらないので略。なお、 https へのリダイレクト設定もやってもらったところ、ちゃんとよしなに /etc/nginx/sites-available/blog-wp に対して設定を施してくれた。ホント便利 (´･_･`)
大浴場の画像等
まだファイルを移動してなかったですね。空っぽの perl ディレクトリはおいら自身用途を覚えていないので (^_^;、とりあえずスタティックファイルだけガッと移動します。
まず新サーバー側で場所を用意。
# mkdir -p /var/www/vhosts/daiyokujo/html # chown murachi:www-data /var/www/vhosts/daiyokujo/html
新サーバーに旧サーバーへアクセスするための秘密鍵は持ってきていないので、旧サーバーから新サーバーへ rsync 。
$ cd /var/www/vhosts/daiyokujo/htdocs $ rsync -ae ssh * murachi@mail.harapeko.jp:/var/www/vhosts/daiyokujo/html/ Enter passphrase for key '/home/murachi/.ssh/id_rsa': $
新サーバー側でコピーされたファイルの所有権が murachi:murachi になっちゃっているのを murachi:www-data に修正。
$ cd /var/www/vhosts/daiyokujo/html $ sudo chown -R murachi:www-data *
/etc/nginx/sites-available/daiyokujo を作成。
$ sudo su - # cd /etc/nginx/ # vim sites-available/daiyokujo (...大浴場用ファイル置き場の設定を記述) # cd sites-enabled/ # ln -s ../sites-available/daiyokujo # service nginx restart
内容は以下の通り。
server {
listen 80;
listen [::]:80;
root /var/www/vhosts/daiyokujo/html;
index index.html index.htm;
server_name daiyokujo.harapeko.jp;
location / {
try_files $uri $uri/ =404;
}
}
後は名前解決と SSL 化。この辺は略。
Trac 設定
Trac インストールしてから大分時間が経っているので、 Python モジュール関連を一通り最新に upgrade してしまうことにします。
$ sudo su - # pip install --upgrade pip # pip list --outdated --format=freeze | perl -pe 's/^(.+?)==(.+)$/$1/' | xargs pip install --upgrade
かなり強引ですが…。
最後の最後に
OSError: [Errno 2] No such file or directory: '/usr/local/lib/python2.7/dist-packages/Trac-1.2.3-py2.7.egg'
とかいうエラーが出ちゃいましたが、その後 pip list --outdated しても何も出てこないので、まぁ良しとします。
ていうかリスト確認したら Trac が 1.4 になってる…。
# pip list (2.7系は 2020年からはサポート無くなるぜという警告メッセージは略) Package Version ----------------- ------- Babel 2.7.0 docutils 0.15.2 Genshi 0.7.3 Jinja2 2.10.3 MarkupSafe 1.1.1 MySQL-python 1.2.5 pip 19.3.1 Pygments 2.4.2 pytz 2019.3 setuptools 41.4.0 Trac 1.4 TracFootNoteMacro 1.6 virtualenv 16.7.7 wheel 0.33.6 #
いつの間に 1.4 がリリースされてたの… orz
そんなわけで ideanote を upgrade
# exit $ cd /var/Developer/trac/original/ideanote $ trac-admin . Trac [/var/Developer/trac/original/ideanote]> upgrade エラー: Unable to check for upgrade of trac.db.api.DatabaseManager: TracError: "mysql" データベースをサポートしていません Trac [/var/Developer/trac/original/ideanote]>
ひぇっ(´･_･`)
リリースノート見てみたら MySQL-python から PyMySQL に乗り換えていらっさった模様…(´･_･`)
$ sudo pip install PyMySQL (...インストール) $ trac-admin . trac-admin 1.4 へようこそ Trac 管理コンソール(対話モード)です。 Copyright (C) 2003-2019 Edgewall Software '?' コマンドか 'help' コマンドでヘルプを表示します。 Trac [/var/Developer/trac/original/ideanote]> upgrade アップグレードが失敗しました。問題を解消させてもう一度試してください。 TracError: すべてのテーブルは照合順序として utf8_bin または utf8mb4_bin で作成されている必要があります。次のテーブルがその照合順序で作成されていません: attachment, auth_cookie, cache, component, enum, milestone, node_change, permission, report, repository, revision, session, session_attribute, system, ticket, ticket_change, ticket_custom, version, wiki Trac [/var/Developer/trac/original/ideanote]>
あー、前回中断したときと同じエラーまでたどり着きました(´･_･`)
えーっと。こんな感じかな。
$ cd $ echo attachment, auth_cookie, cache, component, enum, milestone, node_change, permission, report, repository, revision, session, session_attribute, system, ticket, ticket_change, ticket_custom, version, wiki >trac_tables.txt $ perl -e '$l=<>; chomp $l; @t=split /\s*,\s*/, $l; print "alter table $_ collate utf8mb4_bin;\n" for @t' trac_tables.txt > trac_tables_mod_u8b.sql $ mysql -u trac_master -pパスワード trac_ideanote < trac_tables_mod_u8b.sql
これでどうか。
$ cd /var/Developer/trac/original/ideanote/ $ trac-admin . trac-admin 1.4 へようこそ Trac 管理コンソール(対話モード)です。 Copyright (C) 2003-2019 Edgewall Software '?' コマンドか 'help' コマンドでヘルプを表示します。 Trac [/var/Developer/trac/original/ideanote]> upgrade アップグレードが失敗しました。問題を解消させてもう一度試してください。 TracError: データベースのキャラクタセットと照合順序が 'utf8' と 'utf8_general_ci' になっています。データベースは (('utf8', 'utf8_bin'), ('utf8mb4', 'utf8mb4_bin')) の1つでなければいけません。 Trac [/var/Developer/trac/original/ideanote]>
(ﾟДﾟ)ﾊｧ?
そもそも今の DB の状態で utf8mb4 を選ぶべきではなかったかも(´･_･`)
'utf8', 'utf8_bin' の組み合わせで行きますか(´･_･`)
$ cd $ perl -e '$l=<>; chomp $l; @t=split /\s*,\s*/, $l; print "alter table $_ collate utf8_bin;\n" for @t' trac_tables.txt > trac_tables_mod_u8b.sql $ mysql -u trac_master -pパスワード trac_ideanote < trac_tables_mod_u8b.sql murachi@ik1-314-17353:~$ sudo mysql -u root [sudo] murachi のパスワード: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 6829 Server version: 10.0.38-MariaDB-0ubuntu0.16.04.1 Ubuntu 16.04 Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> alter database trac_ideanote collate utf8_bin; Query OK, 1 row affected (0.01 sec) MariaDB [(none)]> Bye $
今度こそどうだ…
$ cd /var/Developer/trac/original/ideanote/ $ trac-admin . trac-admin 1.4 へようこそ Trac 管理コンソール(対話モード)です。 Copyright (C) 2003-2019 Edgewall Software '?' コマンドか 'help' コマンドでヘルプを表示します。 Trac [/var/Developer/trac/original/ideanote]> upgrade レポート 1, 2, 3, 4, 5, 7, 8 をアップグレードできなかったため "ambiguous column name" エラーが起きないように手動で変更する必要が あるかも知れません。 詳細は https://trac.edgewall.org/wiki/1.3/TracUpgrade#enum-description-field を参照してください。 アップグレードが終了しました。 次のコマンドを実行すると Trac のドキュメントをアップグレードできます: trac-admin "/var/Developer/trac/original/ideanote" wiki upgrade Trac [/var/Developer/trac/original/ideanote]>
一部で失敗しているみたいですが、とりあえずアップグレードを完了させられました。
さて、ここまでやったところで Trac リポジトリの所有者が murachi:murachi になっちゃっていたことに気づいたので、所有者を変更。
$ cd /var/Developer/ $ sudo chown -R murachi:www-data trac $ sudo chmod g+s trac
リポジトリの準備が出来たと思うので、 uWSGI を使って動かしてみることにします。 uWSGI に関しては以下のサイトを参考にさせていただいています。
- uWSGI入門 - Python学習講座
- ちゃんと運用するときのuWSGI設定メモ
- nginx + uwsgi でアプリケーションをサブディレクトリで動かす設定
- Nginx + uwsgi で Trac環境を作った時のメモ
uWSGI をインストール。 pip で入れちゃいましょう。
$ sudo su - # pip install uWSGI Collecting uWSGI Downloading https://files.pythonhosted.org/packages/e7/1e/3dcca007f974fe4eb369bf1b8629d5e342bb3055e2001b2e5340aaefae7a/uwsgi-2.0.18.tar.gz (801kB) |████████████████████████████████| 808kB 2.1MB/s Building wheels for collected packages: uWSGI Building wheel for uWSGI (setup.py) ... done Created wheel for uWSGI: filename=uWSGI-2.0.18-cp27-cp27mu-linux_x86_64.whl size=519527 sha256=0e76554e1428e185c0ccb066bb4afaeac1c3c97da5af73c127dd86ccc531f89a Stored in directory: /root/.cache/pip/wheels/2d/0c/b0/f3ba1bbce35c3766c9dac8c3d15d5431cac57e7a8c4111c268 Successfully built uWSGI Installing collected packages: uWSGI Successfully installed uWSGI-2.0.18 #
WSGI ファイルは既にあるので、 uwsgi コマンドを使えば適当なポートで動作確認できるはず。動作確認用に穴を開けますか。
# cd # vim -p ip*tables.sh (両方とも編集...) # ./iptables.sh # ./ip6tables.sh # service netfilter-persistent save # service netfilter-persistent reload
iptables.sh と ip6tables.sh は以下の通りに穴を開けたいポート番号を追記するだけ。
#/sbin/ip6tables -A INPUT -p tcp -m state --state NEW -m multiport --dports 22,25,587,993,80,443 -j ACCEPT /sbin/ip6tables -A INPUT -p tcp -m state --state NEW -m multiport --dports 22,25,587,993,80,443,6543 -j ACCEPT
uwsgi を実行してみます。
# exit $ cd /var/Developer/trac/original $ uwsgi --http=0.0.0.0:6543 --wsgi-file=trac-original.wsgi --callable=application
http://mail.harapeko.jp:6543/ideanote にアクセスしてみたところ、それっぽい画面が表示されました。ちなみに --callable 引数に指定するのは実際の WSGI ファイルが caller として用意しているオブジェクト名 (関数名) で良いみたいです。
uWSGI の動作確認は出来たので、これを Nginx 経由で動かせるように設定していきます。まずは uwsgi のパラメータを定義するファイルを /var/Developer/trac/original/trac-original.ini に作成します。
$ vim trac-original.ini
内容としては以下の通りになりました。
[uwsgi] uid = www-data gid = www-data current_release = /var/Developer/trac/original chdir = %(current_release) #wsgi-file = %(current_release)/trac-original.wsgi mount = /trac/original=%(current_release)/trac-original.wsgi callable = application manage-script-name = true socket = /var/Developer/trac/run/uwsgi-original.sock pidfile = /var/Developer/trac/run/uwsgi-original.pid chmod-socket = 666 vacuum = true daemonize = /var/Developer/trac/log/uwsgi-original.log log-reopen = true log-maxsize = 5242880 logfile-chown = on logfile-chmod = 644 processes = 1 threads = 4 max-requests = 500 max-requests-delta = 300 master = true
軽く解説入れます。
uwsgi コマンドを実行するときのカレントディレクトリにしたいディレクトリを指定したい場合、 current_release にそのディレクトリパスを指定し、それと同じ値を chdir にも指定すれば良いようです。
wsgi-file パラメータを指定する代わりに mount パラメータを使用しています。これを使うと、実際に公開するときの URL prefix を指定できます。 Idea note は http(s)://developer.harapeko.jp/trac/original/ideanote として公開したいので、 prefix に /trac/original を指定しています。
mount パラメータは複数指定できるらしいので、同じ場所に複数アプリを置いて同時に公開するような書き方もできるっぽいです。
manage-script-name は URI prefix を uWSGI 側で管理するかどうかを決めるパラメータで、 true を指定すると、リクエストに渡された URL から mount に指定した prefix を取り除いた値を URL としてアプリに渡すようになります。例えば /trac/original/ideanote/wiki/HowTo という URL でリクエストされた場合、これを /ideanote/wiki/HowTo に置き換えた値がアプリに渡されます。これを実現するために Nginx 側の設定を工夫する方法もあるのですが (location を正規表現指定にして抜き出したい部分をキャプチャし、 SCRIPT_NAME と PATH_INFO を指定する)、今回はこの方法で書いてみました。
HTTP の公開は Nginx に任せるので、 Nginx との通信のために UNIX socket だけを公開します。それを指定するのが socket パラメータです。 pidfile パラメータはプロセス ID を書き出すファイルで、デーモン実行した uWSGI プロセスを閉じるのに必要になるものです。 vacuum = true を指定しておくと、デーモンを開く際にソケットファイルや PID ファイルが残っていても、ちゃんとクリアしてから起動してくれるようになります。
deamonize パラメータを指定すると、 uWSGI はデーモンモードで起動するようになります。パラメータには実行中のログを吐き出すファイル名を指定します。 master パラメータはマスタープロセスを持つべきか否かを指定するもので、デーモン実行する場合は通常 true を指定するものらしいです (この辺に詳しい解説がありました)。
重要そうなのはそんなところでしょうか。
Unix ソケットと PID ファイルを置くディレクトリと、ログファイルを吐き出すディレクトリを用意します。これらのディレクトリはオーナーが murachi:www-data になるので、グループに書き込み権限を与えておきます。
$ cd .. $ mkdir run $ mkdir log $ chmod g+w run log
uWSGI の準備は整ったので、とりあえず動かしておきましょう。
$ cd original/ $ uwsgi --ini trac-original.ini
デーモンモードで動くので、すぐにシェルに処理が返されます。先程作った run ディレクトリの下にソケットファイルと PID ファイルが生成されているのが確認できます (そのへんは省略)。
Nginx の設定も施しましょう。 /etc/nginx/sites-available/developer に developer.harapeko.jp サブドメイン用の設定を作成します。
$ sudo su - # cd /etc/nginx/ # vim sites-available/developer (設定を記述...) # cd sites-enabled/ # ln -s ../sites-available/developer
設定内容はとりあえず以下の通りです。(HTTPS 化は相変わらず certbot 任せ)
server {
listen 80;
listen [::]:80;
root /var/www/vhosts/developer/html;
index index.html index.htm;
server_name developer.harapeko.jp;
location /trac/original {
include uwsgi_params;
uwsgi_pass unix:/var/Developer/trac/run/uwsgi-original.sock;
}
location ~ ^/trac/original/[^/]+/login$ {
include uwsgi_params;
uwsgi_param REMOTE_USER $remote_user;
uwsgi_pass unix:/var/Developer/trac/run/uwsgi-original.sock;
auth_basic "trac authentication";
auth_basic_user_file /var/Developer/trac/original/.htpasswd;
}
location / {
try_files $uri $uri/ =404;
}
}
当面 developer サブドメインを Idea Note 以外の用途で使う予定はないのですが、一応 /trac/original 以外のところにアクセスされた場合用にドキュメントルートも設定してあります。ファイルは用意していないので単に 404 になります。
Trac 用の設定としては、基本は単に UNIX ソケットとの通信設定を施すのみです。 uwsgi_params というのを include していますが、このファイルは pip install uWSGI した時点で /etc/nginx の下によしなに作られたようで (もしくは元からそこにあった?)、 uWSGI に渡す基本的なパラメータのデフォルト値が定義されています。
Trac ではログイン処理も施す必要があるので、ログイン用の URL にアクセスした場合に REMOTE_USER パラメータに基本認証されたユーザー名を渡す設定と、基本認証自体が動くようにする設定を追加しています。なお、 Nginx には Apache2 で使えていた Digest 認証には対応していません (対応させるにはパッチを使ってソースからコンパイルしてあげる必要がある)。元々 Digest 認証用のパスワードファイルがあって、それを使っていたのですが、今見たら昔仕事で共用していたユーザーの設定がそのまま残っていて、むしろこれは捨てたほうが良いなと思ったので、基本認証に切り替えて済ませることにしました (SSL を使うつもりなので問題はないはず)。
ドキュメントルートを作っていなかったので用意します。
# mkdir -p /var/www/vhosts/developer/html # chown murachi:www-data /var/www/vhosts/developer/html
それから基本認証用のパスワードファイルも用意します。
# exit $ cd /var/Developer/trac/original/ $ htpasswd -c .htpasswd murachi New password: Re-type new password: Adding password for user murachi $
Nginx を再起動します。
$ sudo service nginx restart
ローカルマシン上の /etc/hosts を書き換えて、所定の URL で Idea Note にアクセスできることが確認できました。
もはや動作確認用のポート開放は不要なので、 iptables の設定をもとに戻しておきましょう。
$ sudo su - # vim ip*tables.sh (ポート 6543 を含まない設定に戻す) # ./iptables.sh # ./ip6tables.sh # service netfilter-presistent save # service netfilter-presistent reload
