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

自宅にメンテナンスの簡単なサーバーを新たに構築しようと思ったが、いまさらPCサーバーを新しく構築するというのも面白くないので、Raspberry Pi 2を使うことにした。

買ったのはRaspberry Pi 2と専用ケース。Class 10 32GBのmicroSDはTranscend製が安かったので買ったのだが、これは失敗だった。これについては後述。後日、Sandisk Ultraに買い替えた。

運用は、1.5A供給のUSBチャージャーからmicroUSBで給電、短小イーサネットケーブルでルーターの空いてるポートに有線直結。あとはディスプレイもキーボードも全く繋がない状態でセットアップから運用までやってしまおう。

さて、最初にセットアップに必要なイメージをmicroSDに書き込む必要がある。一般的なセットアップではNOOBを選ぶのだが、これはデスクトップとして設定するためのもの。ここは最初からRaspbian Jessie LITEのイメージをダウンロードする。unzipしてimgファイルを取り出しておく。

さて、イメージを焼くのにOS Xを使うので、OS X用のイメージ焼きツールをダウンロード(https://alltheware.wordpress.com/2012/12/11/easiest-way-sd-card-setup/)する。ddでもいいんだけど、面倒なのでね。Safariでアクセスするとなぜかダウンロードできないので、ChromeでアクセスしてRPi-sd card builderをダウンロードして準備。

さて、ここでSDカードをカードリーダーに挿入。ディスクユーティリティーからMBRパーティション、MS-DOS(FAT)フォーマットで初期化する。初期化が完了したらRPi-sd card builderでRaspbian Jessie LITEのイメージを指定してSDカードに書き込む。完了したらSDカードをRaspberry Pi 2のmicroSDカードスロットに差し込む。SDカードの表面がRaspberry Pi 2の底面側になるので注意。

これで準備完了。microUSB給電して起動。Raspberry Pi 2には電源スイッチはないので、給電したら即起動する。しかし、この時点ではヘッドレスなので何が起きてるかは分からない。とほほ。これがサーバー運営の醍醐味って奴かな。

 

さすがに、カーネルのアップデートが出る度にいちいち旧カーネルを先にパージなんてことをしていたらいつ起動不能になるかわかったものではないので、なんとか / パーティションを拡張する方法はないかと考えていたら、実は / パーティションはLVMで管理されていることに気がついた。 🙂

sudo /sbin/lvscan

ACTIVE ‘/dev/bam-system/root’ [332.00 MiB] inherit
ACTIVE ‘/dev/bam-system/usr’ [8.38 GiB] inherit
ACTIVE ‘/dev/bam-system/var’ [2.79 GiB] inherit
ACTIVE ‘/dev/bam-system/swap_1’ [5.52 GiB] inherit
ACTIVE ‘/dev/bam-system/tmp’ [380.00 MiB] inherit
ACTIVE ‘/dev/bam-system/home’ [38.27 GiB] inherit

しかもext4フォーマットだからオンラインで拡張処理が出来る。ということは、どこかのパーティションを減らせば、それを拡張に割り当てることが出来るというわけだ。

ただ、縮小処理はアンマウントしないといけないので、ありあまってる /home から取るのはちょっとリモート操作では躊躇われる。なので、ここはぐっと我慢してswapを少し減らしてそれを / に回すことにしよう。

ますは、swapをオフラインにする。

sudo swapoff -a

次に swap パーティションを300MBほど減らす。

sudo /sbin/lvreduce -L -300M /dev/bam-system/swap_1

lvscanで無事にサイズが減ってることを確認したら再びswapをオンにするために、新しいswapを作成する。

sudo /sbin/mkswap /dev/bam-system/swap_1

sudo swapon /dev/bam-system/swap_1

さて、pvscanを使って、LVMに空きが300MB出来てることを確認しよう。

sudo /sbin/pvscan

PV /dev/sda5 VG bam-system lvm2 [55.66 GiB / 300.00 MiB free]
Total: 1 [55.66 GiB] / in use: 1 [55.66 GiB] / in no VG: 0 [0 ]

よしよし。空きを300MB確保出来た。次はext4のオンライン拡張だが、これはまずボリューム割当を増やし、そしてファイルシステムを拡張するという二段階を踏む必要がある。

sudo /sbin/lvextend -L +300M /dev/bam-system/root

減らした300MB分だけ / パーティションを増やす。念のため、容量をlvscanで確認。

sudo /sbin/lvscan

ACTIVE ‘/dev/bam-system/root’ [632.00 MiB] inherit
ACTIVE ‘/dev/bam-system/usr’ [8.38 GiB] inherit
ACTIVE ‘/dev/bam-system/var’ [2.79 GiB] inherit
ACTIVE ‘/dev/bam-system/swap_1’ [5.22 GiB] inherit
ACTIVE ‘/dev/bam-system/tmp’ [380.00 MiB] inherit
ACTIVE ‘/dev/bam-system/home’ [38.27 GiB] inherit

というわけで、計632MBに増えていることが確認出来た。linux-imageのサイズがだいたい170MBぐらいなので、この分だと3カーネルは保持出来る。十分だ。

ここで、祈れるものには何でも祈りながら、ext4のオンライン拡張を実行する。

sudo /sbin/resize2fs /dev/bam-system/root 632M

無事に完了したらファイルシステムが実際に増えていることを確認しよう。

df -h

なんとか延命完了。

 

このサーバーのパーティションはDebianのインストーラーのデフォルトのままにしてあるのだが、wheezyからjessieへのアップグレードで問題発生。

なんと、肥大化したlinuxのmoduleが/libを圧迫して、/の容量の半分を超えるまでになってしまったのだ。

結果、linux-imageにアップデートがあっても容量不足でインストールできないという事態に。さすがにこれはまずいが、現状、サーバーを構築し直す余裕はないので、危険を承知で一旦linux-imageをパージしてから再インストールするという手段をとらざるをえない。

以下、手順。

screen (セッション中断に備える)

sudo apt-get dist-upgrade (アップデートに失敗するが、パッケージのダウンロードは完了させる)

sudo dpkg -l | grep linux-image (インストールされてるパッケージのバージョンナンバーを確認)

sudo apt-get purge linux-image-3.16.*-*-amd64 (*はバージョンナンバーを指定してパッケージのパージ。警告が出るが強行する)

sudo apt-get install linux-image-amd64 (即座に再インストール。ダウンロード済みのパッケージが使われる。grubが正しく新しいカーネルを利用してることを確認する)

sudo apt-get dist-upgrade (アップデートし残しがないか確認)

exit (screenから抜ける)

sudo shutdown -r now (運を天に祈る)

 

 

ある日突然、研究用のMac(El Capitan)からMac App Storeに接続出来なくなってしまった。App Storeアプリを起動しても、接続中を示すバルーンがぐるぐる回ってるだけでいつまでたっても何も表示されない。結果、購入済みアプリのアップデート等も一切出来ない状態。アカウントのサインインは出来るし、新しく作ったユーザーからApp Storeを起動するとちゃんと接続出来るので、ハードウェアやOSの根幹部分の障害ではないことは明らかなんだが、対処できないままだとアプリやOSのアップデートがかけられないのでセキュリティ的にちょっとまずい。だからといってアップデート専用のアカウントを登録するのは不便でしょうがない。似たような症状の人はUSのAppleのサポートコミュニティでもよく見かけるが、決め手になるような対処法はなし。

で、解決のために参考にしたのはここ。

サポートコミュニティにばらばらにある対処法をまとめてくれてあるのだが、この中で対処に効いたのは証明書のキャッシュの削除。

/var/db/crls/crlcache.dbと/var/db/crls/ocspcache.dbをゴミ箱に捨てて再起動。これでようやくApp Storeに正しくアクセス出来るようになった。しばらくこの状態で苦しんでた間に出てたアップデートをかけて問題解決。

Onyxを使ってシステムキャッシュのリセットをやってダメだったので、キャッシュの削除は盲点だった。Onyxのキャッシュリセットはシステムキャッシュだけにしてあるので、証明書のキャッシュはシステムキャッシュリセットでは削除されないキャッシュだったのだろう。だからといって、Onyxのキャッシュリセットをシステムキャッシュ以外もめったやたらと全部リセットする設定にするのは気が引ける。だが、次回、Onyxでアプリの動作の問題が解決しなかった時にシステムキャッシュ以外のキャッシュのクリーニングもオンにする必要があるかもしれないことは気に留めておこう。

bbPressプラグインをインストールしただけではどうやらテーマに互換性がないので、BuddyPressのグループ内フォーラム機能は有効になるものの、bbPressの機能であるSiteWideフォーラムの機能は追加できないらしい。

で、テーマに互換性を持たせるには以下のページの指示に従って手動でインストール済みテーマにbbPressのテンプレートを追加する必要がある。

http://codex.bbpress.org/theme-compatibility/

そこで、まずはインストールしたいテーマのディレクトリに移動。今回はtwentyfourteenを選ぶ。

cd /var/www/wordpress/wp-content/themes/twentyfourteen

で、そこでまず、bbpressフォルダにSymbolic Linkを貼る。

ln -s ../../plugins/bbpress/templates/default/bbpress .

で、次にデフォルトのbbPress設置用テンプレートをテーマのトップ内にどばっとばらまく。

ln -s ../../plugins/bbpress/templates/default/extras/*.php .

以上でbbPress用のフォーラムテンプレートが有効になる。

BuddyPressのユーザーの追加をサイト管理者に委譲する方法について判明したので覚書。

まず、ネットワーク管理者のダッシュボードの設定から、新規ユーザーの追加をチェックして、各サイト管理者がユーザーを追加できるように設定する。

BuddyPress側ではアクティベーションを受け付けるページが必要になるので、設定→BuddyPressから固定ページでActivationページを作製しておく。これで、サイト管理者が新規ユーザー登録を行うとユーザーがActivationページに案内されてメールで送られてきたキーを入力することでユーザー登録が完了する。

どうやらパスワードは一度ログイン画面にいって「パスワードを忘れた」を選んでパスワードリセットを行わないと設定されないっぽい。

あと、サイトそのものが非公開になっているとユーザーがアクティベーションしようとしてもそのページが表示できないのでアクティベーションされない。サイトの設定で公開にチェックを入れておくことを忘れないように。

一応、非公開グループを作製することで非公開ディスカッションが可能ではあるけれど、トピック単位でフォーラムを立てて非公開議論できた方が楽かもしれないので、フォーラム機能追加プラグインであるbbPressをインストール。管理ユーザーにフォーラム管理者の権限を付与しておく。

BuddyPressの日本語化もプラグインで可能。

新規プラグインでBuddyPress Translationsを検索し、インストールする。最近のWordPressではテストされていないと警告が出るが、これは単に翻訳ファイルをリポジトリから取ってくるだけのプラグインなので警告は無視する。

このプラグインはネットワーク全体で有効化しておく。これだけでブログの言語が日本語に設定されていればBuddyPressのインターフェースも自動的に日本語になるみたい。

BuddyPressのインストールは簡単。WordPressにサイトネットワーク管理者でログインしてプラグインの新規追加でBuddyPressを検索してインストールする。

ここで注意しないといけないのは、初期のBuddyPressではサイトネットワークのトップであるID=1のブログにしかSNSがぶら下げられないこと。そこで、すべてのサイトで必要ならBuddyPressを有効にできるように以下の様にWordPressをカスタマイズする。

/var/www/wordpress/wp-config.php

define(‘BP_ENABLE_MULTIBLOG’, true);

この一行を以前にマルチサイトの設定を記述したところの下に追加する。これによってBuddyPressがID=1以外のブログでも付け加えることができるようになる。

プラグインをネットワークで有効化してしまうとすべてのブログに強制的にBuddyPressによるSNS機能が付与されてしまうので、プラグインそのものはネットワークでは無効化しておく。そうすることで、各ブログのダッシュボードから個別にプラグインを有効化できるようになる。

某所よりプライベートなSNSを構築して欲しいという要請を受けて、現在のサーバーであるDebianで構築できそうなオープンソースのSNSプラットフォームをいろいろと検討してみた。ほとんどのメジャーなプラットフォームはPHP+MySQLという環境で構築できるので現在のDebianサーバーでも動かせることは動かせるのだが、どれもパッケージ化されていないので、バージョンアップ等のメンテナンスがすべて手動になってしまう。そのため、管理者の不注意によってはセキュリティが危うくなったりするかもしれないので、できればそういう無駄な労力は増やしたくないところ。

で、もっと自動で管理できて手間のかからない方法はないかということで辿り着いたのがWordPress上でSNSまがいなものが構築できるBuddyPress。これならWordPressプラグインなので、バージョンアップ時の更新はWordPressが自動的に行ってくれるはずだ。

というわけで、最終的にここに落ち着くことにしたので、BuddyPressによるSNSを構築する。唯一の気掛かりはBuddyPressだとユーザーが全部WordPressサーバーのユーザーとしてぶら下がることになるので、ユーザーがばかばか増えると管理が面倒だななということ。まあ、ユーザーにブログサイトを作らせると面倒だけど、SNSの投稿しかさせないことにすればユーザー管理の手間も最小限にできるだろう。できれば、BuddyPressの管理も外部にまかせてユーザーを登録する作業をお願いしてしまいたいところだが、その部分だけ権限委譲できるかどうかはちょっと要調査。