PHPのテクメモ

実はよくわかっていなかった、create tableの時の書き方。

• id INT PRIMARY KEY
  idは主キーだけれど、自動で連番にはならない。
• id INTEGER PRIMARY KEY
  idが主キーで、自動で連番になる。しかしシーケンスは作成されず、例えばtable内のデータを全削除すると再度1からになる。
• id INTEGER PRIMARY KEY AUTOINCREMENT
  idが主キーで、自動連番。シーケンスが作成されて、値は再利用されない。145データを投入して、全削除したら、次のid値は146。初期化するにはシーケンスを0でupdateしてやる。

一つ賢くなった。

「–」で始まれば1行のコメント、「/*」と「*/」で囲めば複数行コメントだと思っていた。

しかし1行のコメントで、「–」で始まれば、という前提は間違いであることに今更気がついた。

正確には「– 」。ハイフン2つの後ろに更に半角スペースが1つ必要。

Gmailにメールが送れない理由がようやく分かった。

色々調べると、どうもメールを送信しているサーバがGmailのサーバとIPV6で通信していて、そこで逆引きがどうとかなんとかかんとか・・・、メールが届かないらしい。正しく送信できていた時と比較して、サーバの設定を変更していないから、ConoHa側の何かが変更になったか、Gmail側の設定が変更されたのか（こちらの確率が高そう）、どうやらそれが原因らしい。

postfixの設定（main.cf）で、「inet_protocols = all」の記述を「inet_protocols = ipv4」に書き換えて、postfix再起動で見事メールが送れるようになった。

参考にしたページはこちら。

http://www.jitaku-svr.info/index.php?postfix_トラブルシューティング

上記のページにあった以下のメールサーバのログの記述は、こちらのサーバには見つからなかった。

warning: inet_protocols:
IPv6 support is disabled:
Address family not supported by protocol
warning: inet_protocols:
configuring for IPv4 support only

諦めかけていただけれど、よかった。他のサーバも設定変更しておこう。

設定した当初は大丈夫だったはずなのに、今日試したらConoHa VPSからGmailへメールが送信できなくなっていた。他のVPSからは正常に送信できている。しばらく放置していたのだけれど、スパム対策はしてあるので、Gmailへスパムを送信していたとは考えにくい。

こんな具合にエラーが吐かれている模様。

Our system has detected 550-5.7.1 that this message is likely unsolicited mail. To reduce the amount of 550-5.7.1 spam sent to Gmail, this message has been blocked.

今まで特に設定していなかったのだけれど、以下のページに習って対策をすることにした。

http://server-setting.info/blog/gmail-spam-check-list.html

まずはSPFから。

ConoHaのVPSで設定してあるドメインはムームーDNSで管理している。ここに記述を追加した。

サブドメイン欄：空白
種別：TXT
内容：「v=spf1 a mx ~all」

「v=spf1」の部分は「バージョンはSPF1を使う」という意味らしい。

「a mx」の部分は「aレコードとmxレコードに登録されたアドレスが有効」ということらしい。

「~all」の部分はいろいろ説明を読んでみたけど、よく理解できない。でもどこのページでもだいたい「~（チルダ）」になっているので、これで設定した。

すぐに反映されるかどうかもわからないけど、DNS関連の設定ならキャッシュの問題とかもあるので、明日以降再度チェックしてみることにする。

今、借りているVPSの一つ、ConoHaが停止させられた。メールの文面を見ると、支払いができていないらしい（プログラムで送信されたメールのようだが変数が正しく置換されていなくて少し戸惑ったが）。諸般の事情でクレジットカード払いから口座引き落としに変更してもらったのだが、トラブっているのかもしれないと思って「支払うから方法を教えて」とメールしてみた。折り返しのメールで、「入金は確認していて手違いでした」の連絡が来た。改めて引き落とし口座を確認したら、きちんと引き落としされていた。低姿勢で「お金払います」といったが、引き落としをちゃんと確認していればもっと強気で言えたのに。

サーバは停止されていたが、すぐに復旧された。もともと開発用に借りていたサーバで、数ヶ月くらい寝かしたままだったので問題はなかったのだが、止まっていたMySQLの起動ができなくて困ってしまった。

Another MySQL daemon already running with the same unix socket.

んー。どうもVPSは強制停止させられた状態っぽい。強制終了されたので、sockファイルが削除されずに残ってしまっている感じ。確認したらやっぱりファイルがあったので、削除した。

rm /var/lib/mysql/mysql.sock

これで起動できた。

調べてみたら、あと連絡が3日ほど遅かったら、VPSが削除されるような感じだった。もし、この状態で本当に削除されていたら、当然データの復旧は難しいと思うのだが（バックアップはあるだろうけど）、どういう責任をとったんだろうと、ふと不思議に思った。

今回は実害がなかったのでクレームは入れない（開発を再開するきっかけになったから）。でも、厳重注意だね。