カテゴリー: サーバー管理

起動したらまずは固定IPに設定しなおす。

/etc/network/interfacesにeth2の項目がある。DS47は内蔵の8111G二つがeth0,eth1で認識されるのでLUA3-U2-AGTはeth2になる。これがインストール時にはdhcpに設定されているので、このdhcpをstaticに書き換えた後、その下に固定IPの設定を記入する。

address xxx.xxx.xxx.xxx

netmask xxx.xxx.xxx.xxx

gateway xxx.xxx.xxx.xxx

この時点で一度shutdown -hP nowで電源を切り、ヘッドレス・手足レスにした上で再起動する。別の端末からsshでログイン出来ることを確認して、以後はsshでリモートで設定する。

次に、/etc/apt/sources.listを開き、それぞれのリポジトリにcontrib non-freeを追加して非GPLなパッケージもインストール対象にする。ついでにapt-get updateでリポジトリキャッシュを更新。

まずは余計なサービスを止めるためにapt-get install sysv-rc-confでsysv-rc-confをインストール。起動して、exim4,dovecot(POP3,IMAPサーバー),rpcbind,nfs-commonあたりをすべてチェックアウトしておく。これで余計なサービスは起動しなくなる。

 

さて、OSはどうしようかと思ったのだが、今回のサーバーはできる限りメンテナンスの手間を減らして長期にわたり運用したいということで、いつものFreeBSDで構築する代わりにバイナリアップデートでメンテナンスできるLinuxをインストールすることにする。

本来ならUbuntu Server 12.04 LTSにして2017年までサポートしてもらうというのが理想だが、なぜかUbuntu ServerのインストーラーはLUA3-U2-AGTを認識しなかったので、代わりにDebianのStable版の最新であるWheezy(7.1)をインストールすることにする。

Windows上でDebian 7.1のNetinstall Amd64 ISOイメージをダウンロードし、UNetbootinを使ってこのISOイメージからFAT32フォーマットしたUSBメモリにブート可能なシステムを書き込む。あとはUSBメモリをDS47に刺してUSBメモリから起動した後、Debianのインストーラーに従ってお任せでインストール。途中、ホスト名を聞かれるので、この時点でいずれ置き換えるべきこのサーバーの名前をFQDNで入力しておく。

最後にtaskselでインストールするパッケージの選択を要求されるので、Webサーバー、メールサーバー、SSHサーバーと標準ユーティリティーを選んでおく。インストール完了したらBIOSから内蔵mSATAをブート領域に選んで再起動。

中古PCに以前のサーバーのHDDをそのまま移植して無理やり立てた自宅サーバーもそろそろ１年半が過ぎて、いくら何でも正式に構築した信頼性の高いサーバーに更新した方がいいだろうということで、思い立ったが吉日、サーバーの再構築へ向けての準備作業に入る。

今回のサーバー構築にあたっての要件は、ファンレス・スピンドルレスで長期間ハードウェア的にメンテナンス不要であること。というわけで、そういう構成が可能なものを見繕って、ShuttleのDS47というベアボーンを選択。こいつの特徴は、Celeron 847搭載で64bit OSが使えること、内蔵mSATAスロットがあるのでmSATA SSDが使えること。心配点はEthernetインターフェースがRealtek 8111GでこれがまだどのPC-UNIXでもサポートされていないことぐらい。

というわけで購入時についでにTOSHIBAのmSATA SSD 60GBを購入し、MacBook Proのメモリ増設で余っていた2GB x 2のメモリを転用、ハードウェア的な準備はあっさり完了。

Ethernetインターフェースは予想通り認識されなかったので、USB2.0-Gigabit EthenetアダプターであるBuffalo LUA3-U2-AGTを購入して接続。幸いにもDebianとFreeBSDは素直に認識する模様。

ディスプレイはHDMI接続、キーボードはPS3につないでいたものをとりあえずUSB接続。どうせこれらはインストールが終了したら外してしまいヘッドレス、手足レスで運用するので、適当にごまかす。

sendmail-sasl2のportのバージョンが上がっていたのでportupgradeでバージョンアップしたら、いつの間にかメール中継が出来なくなっていた。

ログを確認するとメール送信時のSMTP AUTH認証が出来なくなっているらしい。このサーバーは送信メールをとあるISPのSMTPサーバーにすべて丸投げする設定になっているので、このSMTP AUTHが通らないとすべてのメールがロストするんだよね。困った。

で、原因を調べてみると、どうやらこれまで-sasl2や-tlsなどのサブportに分かれていたsendmailのportがすべてmail/sendmailに統合されてオプション指定で選択する様に変更されたらしい。ところがportupgrade時にsendmail-sasl2からsendmailにアップグレードしておきながらSASLのオプションはデフォルトで外れているというなんという盲点。SASLが追加されてないとSMTP AUTHに必要なライブラリがないので認証できていなかっただけというオチ。

で、make configでオプション画面を再び呼び出してSASLとSASLAUTHDをチェックしてmakeしようとしたら、エラーでストップ。どうやらデフォルトでTLSをチェックした状態でインストールされたものはsendmail+tlsのパッケージとして登録される様になっており、SASLがチェックされると別パッケージ名になるのでコンフリクトだとおっしゃる。しょうがないので、sendmail+tlsをデリートしてから、デフォルトにSASLとSASLAUTHDを追加(TLSもデフォルト通りついたまま)してmake install。どうやら無事にsendmail+sasl2+tlsとしてインストールされた様だ。その後、メール中継が無事に動いていることを確認。maillogを見ても中継出来てなかった間に特にメールは来てなかったみたいなのでとりあえず一安心。

ていうか、こんな大事な事、ちゃんと/usr/ports/UPDATINGに書いとけよ。

どうやらWordPressの管理者ユーザーとして一般的に最初に作成されるadminを決め打ちで狙った辞書攻撃が多発しているらしい。

このサイトのadminユーザーのパスワードはパスワードジェネレーターで生成したランダム文字列にしてあるので辞書攻撃に屈するとは思えないが、それでも普段使わないユーザーに攻撃を受ける可能性があるというのは気持ち悪いのでadminユーザーは削除することにする。

まずは自分のアカウントを特権管理者に昇格。次にadminユーザーの所有にしてあるトップサイトのユーザーに自分を追加。最後にadminユーザーを削除すればOKかと思いきや、adminユーザーはサイト管理者のメールアドレスを持っているので削除できないとかぬかしおる。

ちょっと調べてみると新しいユーザーを作成してから削除しろとか書いてあるんだが、サイト管理者のメールアドレスを持った別のユーザーを作成しようとすると、同じメールアドレスを持ったユーザーが既にいると言って登録拒否。なんじゃこれ。しょうがないので、adminユーザーのメールアドレスを適当に変更する。これはできるのね。

待てよ？adminユーザーのメールアドレスが変更できるのなら、これでサイト管理者のアドレスとは違う様になったのだから、先のサイト管理者のメールアドレスを持ったユーザーは削除できないという制限には引っかからないのではないか？と思い削除を試みたら、案の定、削除できるじゃないの。つまり、WordPressはサイト管理者として登録されたメールアドレスを持つユーザーを削除できない特別ユーザーとして扱うくせに、このアドレスを持つユーザーが存在しなくてもまったく気にしないということか。意味が分からんが、まあ結果的に攻撃を受けやすいユーザーがいなくなったので良しとしよう。

 

FreeBSDのportsから入れたja-wordpressがアップデートされた。(3.4.2->3.5.1)

既にWordPressはWordPress本体から直接アップデートする方式にして最新の3.5.1に更新してあるので、この状態で間違ってportupgradeをかけてしまうといろいろ上書きされるかもしれない。今後のことを考えると実際にはファイルを削除せずにja-wordpressをインストールしたという登録情報だけを削除しておきたい。

具体的には/var/db/pkgにインストールしたパッケージの情報がベタに書き込まれているので、この中のja-wordpressディレクトリを削除(安全のために実際は移動)する。

この状態でportversionを実行すると正しくportsのインストール情報が更新されて無事にアップデートが必要なインストール済みportsのリストからja-wordpressが消えた。

 

これまでCGI掲示板にはT-Note Ver.4.05を使っていたが、あまりにもスパム書込がひどいので、簡易CAPTCHAがついた掲示板に移行しようと決意する。

見つけたのがC-Board Moyuku。とりあえずマニュアル通りに設置。

c-board.cgiが改行コードがおかしいのでnkfを通して改行コードをUNIX仕様に変更する。

id指定でマルチ掲示板にできるし、とりあえず満足。しかし、簡易CAPTCHAがちゃんとスパムをブロックするかどうかは今のところ不明。かなり簡易なのでその気になったら画像認証で簡単に破れそうだけど。

スパムの抑制のためにCAPTCHA認証を導入することにする。以下のプラグインを導入。

SI CAPTCHA Anti-Spam

これでコメントを書く時にCAPTCHAが必要になるのでスパムが減るだろう。ダメだったら、Akismetの導入も考えよう。

バックアップには以下のプラグインを導入。

BackWPUp

週に一度、過去4週に遡って/usr/local/www/wordpress/wp-content/backups/にバックアップが作成されるようにする。適宜ここの中のファイルをバックアップすることで簡易バックアップとする。

 

マルチサイト化するために、/usr/local/www/wordpress/wp-config.phpの認証用ユニークキーの直前に

define(‘WP_ALLOW_MULTISITE’, true);

を記入する。

ついでに/usr/local/www/wordpress内のすべてのファイルをwww:wwwに所有権を移し、

define(‘FS_METHOD’, ‘direct’);

をwp-config.phpに追記しておく。これでWordPress内からプラグインのインストールや更新が可能になる。

以上を済ませたら、再びWordPressにアクセスするとマルチサイト化の手順が表示される。今回はサブディレクトリタイプで構築する。指示に従って、blogs.dirの作成、wp-config.php、.htaccessの修正を済ませると、サブディレクトリにブログを作る事が出来るようになる。

まずはWordPressにアクセス出来るようにApacheにディレクティブを書く

/usr/local/etc/apache22/Inculde/wordpress.conf

—

AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps

Alias /wordpress/ “/usr/local/www/wordpress/”

<Directory “/usr/local/www/wordpress/”>
AllowOverride All
Options Indexes FollowSymLinks
Order Allow,Deny
Allow from all
DirectoryIndex index.php
</Directory>

—

これで外部からWordPressにhttp://bam-system.ddo.jp/wordpressでアクセス出来るようになる。大事なのは、うちの様にプライベートLAN内にサーバーをおいてルーターのport forwardingでサーバーを公開してる場合、内部からはプライベートアドレスでIP直打ちでアクセスしなければならないが、WordPressは最初に初期設定した時のサイト名で全URLをハードコーディングしてデータベースに書き込んでしまうので、プライベートからしかアクセスできなくなってしまう。なので、初期設定はかならず外部に公開しているサーバー名でアクセスできる環境から行うこと。

というわけで、iPhoneでテザリングして外部からWordPressにアクセスする。内部からアクセスしていろいろやりたい場合はVirtualBox上のUbuntuでhostsに記入してやることにしよう。

最初にアクセスするとインタラクティブにwp-config.phpを作成するモードになる。ここでMySQLでデータベースを作成した時の情報が必要になる。データベースへの接続が終わると初期ブログのセットアップになる。後でマルチサイト化するが、ここで作成する初期ブログのユーザーがサイト管理者になるので、adminユーザーとして作成しておく。