Cookie が無効になっていて MediaWiki にログインできないって言われた件

結論

セッションディレクトリが書込みできませんでした。

エラーメッセージ

ログインのエラー 
example wikiではログインに Cookie を使用します。 Cookie を無効にしているようです。 Cookie を有効にしてから、もう一度試してください。

当方の環境

  • さくらのVPS
  • CentOS7.2.1511 x86_64
  • Nginx + php-fpm
  • PHP 5.4

調べたこと

  • ログにも大したこと書いてない。
  • Cookie は無効になってない。
  • シークレットモードでやってみたけど同じ。
  • Cookie 消してみたけど変わらない。
  • パスワード再発行しても同じ。
  • ブラウザ変えてみたけど同じ。

ぐぐって調べてみるとセッションのディレクトリが書き込みできませんでした、てへ♪的なスレッドが見つかった。

なるほどな。

phpinfo() 出力させてセッション格納ディレクトリを調べる。

session.save_path = /var/lib/php/session

ディレクトリのパーミッションを確認。

[root@mx1 mediawiki]# ls -l /var/lib/php/
合計 4
drwxrwx--- 2 root apache 4096  5月 12 22:49 session
[root@mx1 mediawiki]# ls -l /var/lib/php/session/
合計 64
-rw------- 1 nginx nginx 3436  3月 13 12:10 sess_29ih6fgffffffffff9ee024fa7
(snip)
-rw------- 1 nginx nginx   53  3月 19 07:57 sess_tpih6fgfffffork4bvffmff625

なんでグループが apache やねん!
そりゃ書き込めないはずだわ。
最近流行りに乗って Nginx 使ってるので Apache は使っていない。
ファイル自身は nginx 所有者で大丈夫っぽいな。
Ansible でメールサーバー構築する Playbook 開発してたからそれが原因かな。
念のため nginx と php-fpm の実行ユーザを確認する。

[root@mx1 mediawiki]# vim /etc/nginx/nginx.conf
[root@mx1 mediawiki]# vim /etc/php-fpm.d/www.conf
[root@mx1 mediawiki]# id nginx
uid=995(nginx) gid=993(nginx) groups=993(nginx)

対策実施

ディレクトリのグループを nginx に変更する。

[root@mx1 mediawiki]# chown root:nginx /var/lib/php/session
[root@mx1 mediawiki]# ls -l /var/lib/php/
合計 4
drwxrwx--- 2 root nginx 4096  5月 12 22:49 session

用が済んだら phpinfo のファイルは削除する。

[root@mx1 mediawiki]# rm -f phpinfo.php

これでちゃんとろぐいんできるようになりましたとさ。
めでたしめでたし。

参考リンク

  1. [RESOLVED] Cannot Login or Register. Enable Cookies on Project:Support desk
  2. Help:ログイン – MediaWiki

Nginx + php-fpm の CentOS 7.2.1511 をリブートしたら 502 Bad Gateway になった

更新が溜まっていたので yum -y update した。
カーネル系の更新があったのでリブートしたら 502 Bad Gateway となった。

2016-04-03_20h32_15

あまりにも初歩的なんだけど、ログを確認したら

2016/04/03 20:31:21 [crit] 1410#0: *1 connect() to unix:/var/run/php-fpm/php-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 203.0.113.12, server: pg1x.io, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm/php-fpm.sock:", host: "pg1x.io", referrer: "https://blog.pg1x.com/"

FastCGI 処理系の php-fpm と通信できていないっぽい。
つまり php-fpm のプロセスが立ち上がっていない。
なんつー初歩的。。。
自動起動設定して起動して解決。

systemctl start php-fpm
systemctl enable php-fpm

Amazon Linux(2013.09)にnginxとPHPをインストールする

一昨日あたりからnginxを始めました。

インストール

yum -y install nginx
yum -y install php-fpm
yum -y install php-mysql php-mbstring php-mcrypt

ドキュメントルートディレクトリを用意する

mkdir -p /var/www/html

/etc/nginx/nginx.conf

location / {
root   /var/www/html;
index  index.php index.html index.htm;
}
location ~ \.php$ {
fastcgi_pass   unix:/var/run/php-fpm/php-fpm.sock;
fastcgi_index  index.php;
fastcgi_param  SCRIPT_FILENAME  /var/www/html$fastcgi_script_name;
include        fastcgi_params;
}

/etc/php-fpm.d/www.conf

listen = 127.0.0.1:9000
↓
listen = /var/run/php-fpm/php-fpm.sock
;listen.owner = nobody
;listen.group = nobody
;listen.mode = 0666
↓
listen.owner = nginx
listen.group = nginx
listen.mode = 0664
; RPM: apache Choosed to be able to access some dir as httpd
user = apache
; RPM: Keep a group allowed to write in log dir.
group = apache
↓
; RPM: apache Choosed to be able to access some dir as httpd
user = nginx
; RPM: Keep a group allowed to write in log dir.
group = nginx

起動

service php-fpm start
service nginx start
chkconfig php-fpm on
chkconfig nginx on

動作確認

cat <<EOF >/var/www/html/index.php
<?php
phpinfo();
EOF

蛇足

ちなみに、Amazon Linuxのバージョン確認は

[root@ip-xxx-xxx-xxx-xxx html]# cat /etc/system-release
Amazon Linux AMI release 2013.09

参考文献

AWS SDK for PHP 2を使ってEC2のインスタンスを起動してみる

Amazon Web Services ガイドブックのEC2セットアップスクリプトの内容をAWS SDK for PHP 2用に書きなおしてみました。

動くようになるまで結構大変でした。。。
ただ、APIから仮想サーバー立ち上げられるってすごいなあと改めて実感。
S3のときなどと違ってEC2は高価だから心臓に悪いですね。
こういうのいじるときはこまめにアカウントアクティビティチェックして、開放漏れのIPや無駄にインスタンス、スペックの高いインスタンスを知らずに立ち上げてしまっていないか注意しないといけないですね。

細かいセットアップについては

にゆずります。

では以下がスクリプトとなります。

<?php
error_reporting(E_ALL);
// Composer
require_once('vendor/autoload.php');
use Aws\Ec2\Ec2Client;
// AWSアクセストークン
$config = array(
'key'    => 'AKIAIOSFODNN7EXAMPLE',
'secret' => 'wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY'
// 東京リージョン指定
'region' => \Aws\Common\Enum\Region::AP_NORTHEAST_1,
);
$ec2 = Ec2Client::factory($config);
try {
$options = array(
// Amazon LinuxのAMIを使う
'ImageId' => 'ami-b1fe9bb0',
// インスタンス1個
'MinCount' => 1,
'MaxCount' => 1,
// キーを指定
'KeyName' => 'securekey',
// セキュリティグループを指定
'SecurityGroups' => array(
'webserver' // sg-134678
),
// インスタンスタイプはマイクロインスタンスを立ち上げる
'InstanceType' => 't1.micro',
);
$result = $ec2->RunInstances($options);
} catch (Exception $ex) {
exit("Instance Launch failed.: " . $ex->getMessage() . "\n");
}
// インスタンス情報を取得
$instance = $result['Instances'][0];
$instanceId = $instance['InstanceId'];
$availabilityZone = $instance['Placement']['AvailabilityZone'];
echo "Instance ID: $instanceId\n";
echo "Availability Zone: $availabilityZone\n";
// EC2インスタンスの準備ができるのを待つ
do {
$result = $ec2->describeInstances(array(
'InstanceIds' => array(
$instanceId
)
));
$status = $result['Reservations'][0]['Instances'][0]['State']['Name'];
$runnning = ($status == 'running');
if (!$runnning) {
echo "instance is currently in $status, waiting 10 seconds.\n";
sleep(10);
}
} while(!$runnning);
try {
// ElasticIPを割り当て
$result = $ec2->allocateAddress();
$publicIp = $result['PublicIp'];
echo "allocate IP Address: $publicIp\n";
} catch (Exception $ex) {
exit("Allocate IP Address failed. " . $ex->getMessage() . "\n");
}
try {
// ElasticIPをインスタンスにアタッチ
$ec2->associateAddress(array(
'InstanceId' => $instanceId,
'PublicIp' => $publicIp,
));
echo "Associated IP address : ${publicIp} to ${instanceId}\n";
} catch (Exception $ex) {
exit("IP Address Association failed. " . $ex->getMessage() . "\n");
}
try {
// 先ほど得られたアベイラビリティゾーンに1GiBのボリュームを2つ作成
$res1 = $ec2->createVolume(array(
'Size' => 1,
'AvailabilityZone' => $availabilityZone,
));
$res2 = $ec2->createVolume(array(
'Size' => 1,
'AvailabilityZone' => $availabilityZone,
));
$volumeId1 = $res1['VolumeId'];
$volumeId2 = $res2['VolumeId'];
echo "EBS Volume: $volumeId1, $volumeId2 created.\n";
} catch (Exception $ex) {
exit("EBS Volume create failed. " . $ex->getMessage() . "\n");
}
// ボリュームが使えるようになるまで待つ
do {
$result = $ec2->describeVolumes(array(
'VolumeIds' => array(
$volumeId1, $volumeId2
)
));
$status1 = $result['Volumes'][0]['State'];
$status2 = $result['Volumes'][1]['State'];
$volumeReady = ($status1 == 'available' && $status2 == 'available');
if (!$volumeReady) {
echo "volumes are currently in ($status1, $status2), waiting 10 seconds.\n";
sleep(10);
}
} while(!$volumeReady);
try {
// ボリュームをインスタンスにアタッチ
$res1 = $ec2->attachVolume(array(
'VolumeId' => $volumeId1,
'InstanceId' => $instanceId,
'Device' => '/dev/sdf',
));
$res2 = $ec2->attachVolume(array(
'VolumeId' => $volumeId2,
'InstanceId' => $instanceId,
'Device' => '/dev/sdg',
));
echo "Volume $volumeId1, $volumeId2 has been attached successfully.\n";
} catch (Exception $ex) {
exit("EBS Attache failed. " . $ex->getMessage() . "\n");
}
echo "Finished!!\n";

で、出力は以下のようになります。

$ php ec2_setup.php
Instance ID: i-11223344
Availability Zone: ap-northeast-1c
instance is currently in pending, waiting 10 seconds.
instance is currently in pending, waiting 10 seconds.
allocate IP Address: 54.111.95.222
Associated IP address : 54.111.95.222 to i-11223344
EBS Volume: vol-12345ba, vol-653ac created.
volumes are currently in (creating, creating), waiting 10 seconds.
Volume vol-12345ba, vol-653ac has been attached successfully.
Finished!!

AWS Management Consoleで確認したらちゃんとインスタンスが立ち上がってElasticIPがアタッチ、ボリュームもきちんとアタッチされていました。いいこいいこ。

参考文献

A conflicting conditional operation is currently in progress against this resource.

以前間違ってオレゴン州に作成してしまったバケットを削除して、AWS API経由で同じ名前で東京リージョンに新たにバケットを作成しようとしたらエラーになって怒られました。

PHP Fatal error:  Uncaught Aws\S3\Exception\OperationAbortedException: AWS Error Code: OperationAborted, Status Code: 409, AWS Request ID: XXXXXXXXXXXXXXXX, AWS Error Type: client, AWS Error Message: A conflicting conditional operation is currently in progress against this resource. Please try again., User-Agent: aws-sdk-php2/2.4.11 Guzzle/3.7.4 curl/7.19.7 PHP/5.3.3
thrown in /vagrant/src/s3/vendor/aws/aws-sdk-php/src/Aws/Common/Exception/Name

イマイチよくわからなくていろいろ調べたところ

というエントリがひっかかりました。
どうもすぐにバケットを作りなおそうとしたのが原因ぽいです。
削除のオペレーションをやってもすぐにはバックエンドのトランザクションは完了されないみたいで、数時間置いてからもう一回やり直してくれとのことでした。

なのでその日は寝て、次の日にやったらうまくできました。