結構面倒くさそうなので、手順を組み立てよう。
php5.4に変更
$ sudo add-apt-repository ppa:ondrej/php5
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
これをやるとapache2が2.2から2.4に変更され、設定ファイルの書式変更で動かなくなるので、/etc/apache2/sites-alivalの中身を書き直す。
<directory /home/wwww/white-room>
# Options の+は省略できない
# order allow, deny
# allow from all
Require all granted <--
</directory>
<files ~ "^\.">
# Deny from all
Require all denied <--
</files>
## allow from, deny fromじゃなくて、Require all (granted|denied)
##モジュールがコメントアウトされてるのに気をつける。mods-enabledを見ろ
##conf.d内の*.confかそうでないかで分けるんじゃなくて、conf-alivalをconf-enabledにシンボリックリンクする。
##コマンドは a2enconf [conf名]
けっこうな大変更だから、2.4より3.xにしてくれた方がビビって良かったかも。
vimbadmin3xのインストール
composerをインストール
デフォルト設定だとメモリ不足で止まるので
$ sudo echo 'memory_limit = "512M"' >> /etc/php5/conf.d/oresama.conf
※ubuntuのphpは守護神パッチ付きなので
$ sudo echo 'suhosin.executor.include.whitelist = phar' >> /etc/php5/conf.d/oresama.conf
composerを/home/oresama/に
$ cd curl -sS https://getcomposer.org/installer | php
あとはhttps://github.com/opensolutions/ViMbAdmin/wiki/Installationに従ってインストール。
現行のDBをdumpする。
現行のDBをdropする。
インポート用のDBを作って、dumpしたDBを読み込む。
新しいDBを作って、vimbadminのインストールパスに入り ./bin/doctrine2-cli.php orm:schema-tool:create
あとはhttps://github.com/opensolutions/ViMbAdmin/wiki/Migrate-from-ViMbAdmin2に従って、完璧に移行する。
インポート用のDBをドロップする。
更に、んぎなんとかさんが入ってるから、そっちも何とかする。
つまり、セキュリティフィックスが提供される限り何もしないのが得策。
vimbadminうpデートメモ はコメントを受け付けていません
メールボックスの管理にvimbadminを使っているのですが、3になってからけっこう経つのでそろそろうpでーとと思ってマニュアルを見たら……。
移行ツール的なものはなく、完全手動…。
- 1,古いDBをエクスポートする
- 2,新しい構造のDBを作る
- 3,もうひとつインポート用のDBを作る
- 4,インポート用のDBに書きだしたDBをインポート
- 5,インポート用のDBから新しいDBに構造に合わせてインポートする
- 6,インポート用のDBをドロップ
この手順で行くと2〜5が終わるまでの間、メールの送受信ができないことになるので、稼働中のサーバでは無理。
予告してやらないと面倒なことになります。
どちらにしても、失敗したらえらいことなので、他の機械で練習してからにしよう……。
しかも3xはPHP5.4以上。うぶんちゅ1204のphpは5.3。ここからか…。
vimbadminには移行ツールがない はコメントを受け付けていません
待ちになったので、ubuntu studio12.04を14.04にうpグレードしてみようとしたらコケました。
うpグレードでは1勝1負になりました。
LTSはお盆では早すぎ。やはり、正月にクリーンインストールが無難なようです。
pythonを設定しています
で止まって、perlのなんたらのline207がどうたらいうメッセージが出たままで停止。
いくら待ってもそこから進みません。
再起動しようとしたら、当然ですが起動しません。
もちろん、フルバックアップを取ってから始めましたから、クリーンインストールして、設定し直しします。
うpぐれーどは博打みたいなところがありますから、こんなもんかも
upgradeコケた…… はコメントを受け付けていません
会社のafp over tcpが遅いということで、試しにyamahaのRTX810の性的マスカレードの設定にUDP548も入れてみたら、5〜10倍程度速くなった。
意味が分らないよ?
切り分けとして、とりあえず再起動と配線から。
iptablesの設定がおかしいのでは? と思って全開にしても変わらず。
試しに性的マスカレードのudpも追加してみたら速くなった。
netstat -n しても、iptables -nxvLしても、udp548が使われている形跡はないし。
だから、サーバー側のiptablesのudp548はDROPに戻しても同じ。なぜか速い。
速くなったので、同じyamahaということで、うちのも同じ設定にしてみたら、こっちも速くなった。
訳が分らないけど、速くなったので当面この設定で。
それと自分のルータの設定を見直していたら、53のTCPを性的NATに入れるのを忘れてて、買い替えてからこっちセカンダリにゾーン転送が出来てなかった……。
理屈が分らない はコメントを受け付けていません
キャッシュは全消しでいい気がしてきた。
wordpressに新規投稿すると、pagedで区切られた投稿表示ページが全部ズレる。
だから、index.php/\?*のキャッシュを消すのは必須で、それと投稿ページのpermalinkだけ消すのが正しい道。
面倒なのは、添付した画像。
こっちは、wordpress上で消したとしても、キャッシュの有効期限までは残ってしまう。
これもプラグインで特定して個別に消した方がキャッシュの効率はいい。
更新頻度が高く、アクセス数も膨大なら個別に消すほうがいいんでしょうが、ノーマルのnginxで投稿時にキャッシュを消すなら、単純なプラグインで全消しも悪くないかな。
<?php
/*
Plugin Name: Nginx Proxy Cache remove
Plugin URI:
Description: remove Nginx Proxy Cache.
Version: 0.0.1
Author: yoshiaki nanba
Author URI: http://www.white-room.jp
*/
function wpremove_nxcache($post_id) {
/* $post_idはキャッシュ特定の日が来るまで飾り */
$cmd = 'rm -rf /var/cache/nginx/whiteroom/*'; /* 俺環超決め打ち */
exec($cmd, $arr, $res);
/* 以下、投稿時に成功、失敗をダッシュボードに返す日が来るまで飾り */
if ($res === 0) {
return true;
} else {
return false;
}
}
add_action('publish_post', 'wpremove_nxcache'); /* 投稿を公開 */
add_action('publish_page', 'wpremove_nxcache'); /* 固定ページを公開 */
add_action('publish_to_draft','wpremove_nxcache'); /* 公開していたものを下書きに戻す */
add_action('edit_comment','wpremove_nxcache'); /* コメントが追加削除変更された */
?>
んぎなんとかでreverse proxy 3 はコメントを受け付けていません