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

このサーバーのパーティションは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の管理も外部にまかせてユーザーを登録する作業をお願いしてしまいたいところだが、その部分だけ権限委譲できるかどうかはちょっと要調査。

今度はMailmanのメーリングリストをお引越しする。まずはmailmanのサービスの停止。

service mailman stop

まずはlistユーザーにsuしてnewlistを使って旧サーバーと同じ名前で新サーバーで空のメーリングリストを作成しておく。最初はアーカイブが公開になっているので、非公開のメーリングリストはarichives/publicにあるシンボリックリンクを削除しておく。

旧サーバーでmailmanフォルダ内のlistsとarchives/privateをtarで固める。このとき、tar pzcfの様にpオプションを付けてパーミッションが保存されるようにしておく。このtarファイルを新サーバーにコピーする。

念の為、listsとarchives/privateをリネームして保存しておいてから、tarファイルをこれまたtar pzxfの様にpオプションを付けてパーミッション付きで展開する。その後、listsフォルダ内の全ファイルをlists:lists所有に、archives/private内の全ファイルをlists:www-data所有にchown -Rで変更する。

これで新サーバーでも旧サーバーと全く同じメーリングリストが設定される。後はmailmanを再起動すれば元通り。

service mailman start

本来ならデータベースをダンプして、それを新サーバーに取り込むのがお作法なのだろうけど、それは面倒なので、エクスポート＆インポートで再現することにする。

WordPress Importプラグインは最初はインストールされていないので、インストールしてネットワークで有効化しておく。

旧サーバーと同様に新サーバー上にユーザーとブログを作成したら、旧サーバーの各ブログのダッシュボードから全コンテンツをエクスポート。そのファイルを今度は新サーバーのブログのダッシュボードからインポートする。これでカテゴリーやらエントリーやらコメントやらはすべて元通りになる。

後は見栄えのカスタマイズを手でコネコネと再現するだけ。