追記
9/20 1:24現在、DNSサーバによってはまだ更新されていないようです。
Softbankの4Gネットワークだともう直ってるのですが、家のWiFiではNGでした。
明日には直ってると思います。どうもすみません。

追記2
9/20 13:18現在、DNSの更新を確認しております。

先日からTwit Delayの投稿遅延が発生しているようで、Twitter経由で何件かお問い合わせを頂きました。まずはお詫び申し上げます。

原因ですが、140字以上のツイートを投稿した際にエラーが発生し、そのエラーを再投稿しようとしたものが溜まっていたためでした。Twit Delayを作ってからもうだいぶ経ちますのでだいぶうろ覚えなのですが、Twitter API 1.0のころは問題無かったように思いますので何か仕様が変わったような気もします（がうろ覚えなのでなんともw）。

対応としまして、とりあえずTwitterから140字以上で投稿失敗した旨のエラーが返ってきた際はリトライ日時を2099/12/31に変更するようにしています。メイン画面でリトライ日時が2099年になっているのがあれば文字数を減らして再投稿もしくは削除願います。

現在溜まっているツイートを投稿している最中ですので、すぐに全てのツイート予約の滞留が解消される訳ではないのですが、じきに正常に戻ると思います。

なお、GAEがPython2.7になるらしく、今年中にシステムを載せ変えないといけないみたいなのでまたTwit Delay関係のご連絡があると思います。

P.S.
書くの忘れてました。
凍結ユーザーの予約ツイートエラーも少し溜まっていたようですが、こちらは消すように変えてます。

Postfix は SMTP サーバでメールを送る部分の担当、Dovecot は POP3/IMAP サーバでクライアントからメールを見る部分の担当です。完結したメールサーバとして動かすには両方必要になります。

設定方針は以下の3点です。

1. バーチャルメールボックスの設定を行い Unix ユーザーを作らなくてもメールを受信できるように設定します。
2. なるたけセキュリティ的に硬めにしたかったので、自サーバ宛のメールの配送と、サブミッションポート経由で SSL + SMTP AUTH で認証されたクライアントからの外部へのリレーのみを許可します。
3. バーチャルメールボックスのパスワード管理は Dovecot で一元管理します。（Postfix での SMTP AUTH の認証時のアカウント管理に Dovecot を使うという意味です。Postfix と Dovecot で別々にパスワード管理する方法もありますがぶっちゃけ面倒くさいので。）

さくらVPSっつーか CentOS 上で Postfix と Dovecot を設定する例はググったら沢山でてきますので、違う方法の設定が必要な場合は適当にお調べください。つーことで本題に突入。

パッケージのインストール

yum から postfix と dovecot をインスコします。cyrus-sasl-md5 は SMTP 認証等で CRAM-MD5 による認証を有効にする場合に必要です。

sendmail とか他のメールサーバを外向けの設定で運用していない場合はいきなり postfix を有効にして問題ありませんので、その前提で話を進めます。

CentOS をインストールした状態では sendmail が動いていますので落とします。以下のように chkconfig で確認して on になっていたら、

sendmail を止めてから postfix を起動します。ついでに chkconfig でサーバリブート時に postfix が起動するようにします。

続けて alternatives で（サーバからのメール送信に使われる） sendmail コマンドを postfix に変更します。

現代的な Unix 系のシステムでは sendmail というメールサーバと sendmail というコマンドは別物として扱われており（元々は sendmail メールサーバに sendmail コマンドが付いていたのですが、sendmail コマンドを呼び出しているアプリケーションプログラムが多々存在するためメールサーバを変更する際に都合が悪いので、コマンドを分けた形です）。

CentOS ではメールを送信するために使う sendmail コマンドは alternatives で指定されたコマンドへのシンボリックリンクとなっています。

以下のように alternatives を実行すると、sendmail コマンドを実行した際に sendmail.postfix （Postfix の sendmail コマンド）が実行されるようになります。

以上が終わったらローカル配送できてるかテストしてみます。（別にしなくても良いですけど早めに問題見つけといた方が楽ですし…）

てことで適当なユーザー（以下の例では root）でログインして適当なユーザーにメールを送ってみます。（シェルから sendmail コマンドを実行すればメールを送れます。sendmail コマンドを実行する際、”.” だけの行を入力するとメールが送信されます。）

送ったメールは（宛先のユーザーでログインして）mail コマンドで見れます。

メールが届いてなかったら /var/log/maillog を見て問題を探してください。（上記の設定内容でローカル配送のメールが届くのが遅れたりすることは基本的にありませんので「届いてなかった＝問題がある」と判断してもらって結構です。）

Postfix と Dovecot の設定

パスワード管理を共有する関係上、両方とも動いてから動作確認する方が速いと思いますので、一気に Postfix と Dovecot の設定を行います。

例示のため、バーチャルメールボックスに使用するドメインを example.com、バーチャルメールボックスに追加するメールアドレスを test@example.com として記述しています。実際の環境に合わせて読み替えてください。

バーチャルメールボックス管理ユーザーの作成

最初にバーチャルメールボックスを読み書きするための Unix ユーザーを作ります。（以下の例では vmail ユーザーを使います。）

UID/GID は 10000 以外でも構いませんが、Postfix/Dovecot を設定する際に ID を指定する必要があるので UID/GID の番号を覚えておいてください。

SSL 自己証明書と秘密鍵の作成

Postfix/Dovecot ともに SSL を有効にするため、自己証明書と秘密鍵を作成します。（Dovecot に example.com の自己証明書と秘密鍵が付いてるのですが一応自サーバ用に作ります。）

/etc/pki/tls/certs ディレクトリの Makefile で秘密鍵を含む自己証明書を簡単に作れるのですが、後述する DER 形式ファイルを作成するため openssl コマンドを直接実行して作成します。

コマンドを実行すると証明書のパラメータを質問されますが、Common Name に VPS サーバのサーバ名（以下の例では www9999u.sakura.ne.jp）を入力し、それ以外の項目はデフォルトで構いません（ちゃんと入力しても良いですけど）。

mail.crt が証明書ファイル、mail.key が秘密鍵ファイルです。証明書の有効期限は365日となっています。もっと長くしたい場合は -days オプションで増やしてください。

Outlook Express や Entourage、AppleMail などのクライアントを使っている場合、証明書をクライアントにインストールしないと警告が表示されるらしいので、インストール用の DER 形式の証明書を作成します。以下のコマンドで作成される mail.der をインストールしたら良いらしいです。（が、この辺は試してないのでうまくいかなかったら証明書のインポート – メール(Postfix) – 自宅サーバーの構築 – 自宅サーバーでやってみよう！！等を参考にしてください。）

Dovecot の設定

Dovecot 側でパスワードを一元管理する関係上、こちらの設定を先に行います。Dovecot の設定ファイル /etc/dovecot.conf を編集し、アカウント管理用の /etc/dovecot-passwd ファイルを作成します。

まず Dovecot の設定ファイル /etc/dovecot.conf を編集します。ssl_cert_file と ssl_key_file は先ほど作った自己証明書と秘密鍵ファイルです。その他の設定は auth default セクション中に足します。

実際の dovecot.conf にはコメントが大量に入ってて修正箇所を探すのが面倒かもしれませんが、ssl_cert_file、ssl_key_file、mechanisms は元からありますので書き換え、その他は auth default セクションの最後の方に足してもらうのが速いと思います。

設定ファイルの詳細については Dovecot Wiki をご覧ください。

dovecot.conf の編集が終わったら /etc/dovecot-passwd ファイルを作成します。Dovecot をインストールした状態ではこのファイルは存在しませんので新規作成します。

dovecot-passwd ファイルには、ユーザー名と暗号化されたパスワードを “:” で区切って記述します。「ユーザー名＝メールアドレス」にした方がメールクライアントの設定が楽なのでそうしてますが、ユーザー名部分はメールアドレスでないとダメって訳ではありません。

暗号化されたパスワードは dovecotpw コマンドで取得できますのでコピペします。

dovecot-passwd ファイルにはユーザーIDやホームディレクトリなど passwd ファイルと似たような項目を指定することもできるのですが、Postfix と連携するだけなら userdb static で指定した方が速いと思いますので省略します。詳しくは AuthDatabase/PasswdFile – Dovecot Wiki をご覧ください。

設定が終わったら dovecot サーバを起動します。ついでに chkconfig でサーバリブート時に dovecot が起動するように設定しておきます。

Postfix の設定

Postfix の設定では、Postfix 全体の設定ファイル /etc/postfix/main.cf とサブプロセス別の設定ファイル /etc/postfix/master.cf を編集し、バーチャルメールボックス管理用ファイル /etc/postfix/vmailbox を作成します。

まず /etc/postfix/main.cf を修正します。

inet_interfaces は main.cf に元から設定が存在するので書き換えてください。他の項目は存在しないと思いますので、適当な場所に追加してください。

#smtpd_sasl_auth_enable = yes の行はコメントアウトしたままにしておいてください。後ほど master.cf を編集する際に、サブミッションポートからの接続時のみ smtpd_sasl_auth_enable = yes になるように設定します。設定ファイルを見たとき分かりにくいと思いますので、あえてコメントアウトで残しておいてもらった方が良いと思います。（まあコメントアウトせずに何も書かなくても結構ですけど。）

古い Outlook を使っている場合は、broken_sasl_auth_clients = yes を有効にする必要があります。SMTP AUTH に関するバグがあるそうです。うちでは Outlook は使ってないのでコメントアウトしてます。

バーチャルメールボックスのメールアドレスに使用するドメインは virtual_mailbox_domains に指定します。上の例では example.com になっていますので、実際に使用するドメインを記述してください。カンマ区切りで複数指定することもできます。

virtual_mailbox_domains に指定するドメインは mydestination と重複しないようにしてください。デフォルトで mydestination は $myhostname, localhost.$mydomain, localhost になっており、さくら VPS の場合 myhostname は www9999u.sakura.ne.jp とかになります。

myhostname を example.com にして mydestination を空にすることもできますが、cron 等システム内部からのメールはバーチャルメールボックスではなくローカル配送にした方が良いと思いますので、mydestination や myhostname はデフォルトのままの方が良いと思います。それとメールサーバの DNS の逆引き設定を行っていないと受信を拒否するサーバもあり、sakura.ne.jp のホストは逆引き可能ですので、その辺のトラブルを避けるためにもこの設定の方が楽だと思います。まあこの辺に色々うんちくのある方はご自由にどうぞ、っつーかそういう人はこんなブログ見ながら設定してはいけませんw

virtual_mailbox_base を別の場所に変えてもオッケーですが、あらかじめディレクトリが存在している必要があり、virtual_uid_maps で指定されるユーザーから制御可能である必要があります。この辺の設定は先ほど vmail ユーザーを作った際に行っていますが、変更する際は Postfix の要求を満たすよう適宜設定を行ってください。

smtpd_tls_key_file と smtpd_tls_cert_file には先ほど作った自己証明書と秘密鍵ファイルを指定します。

main.cf の設定が終わったら /etc/postfix/master.cf を編集します。

以下の submission ポートの設定がコメントアウトされてると思いますので、有効にします。

最後に /etc/postfix/vmailbox を編集して Postfix の設定は終わりです。Postfix をインストールした状態ではこのファイルは存在しませんので新規作成します。

vmailbox ファイルにはバーチャルメールボックスのメールアドレスとメールボックスのパスを空白（タブ）区切りで記述していきます。

メールボックスのパスは virtual_mailbox_base からの相対パスを指定します。上の例ですと、test@example.com 宛てのメールは /var/spool/vmail/example.com/test/Maildir/ に Maildir 形式で保存されます。

Postfix はメールボックスのパスの末尾を / で終えると Maildir 形式、/ 無しで終えると mbox 形式で保存します。何言ってるか分からない人はとりあえず Maildir 形式でえーと思います。

編集が終わったら postmap コマンドでデータベースに変換します。これを実行しないと Postfix が起動しません。virtual ファイルは転送設定用のファイルで、こちらもデータベースが必要ですので一緒に postmap します。

設定が終わったら postfix をリブートします。

DNS

メールサーバを運用する際は、DNS に MX レコードを用意しておいた方が良いです。

A レコードだけでも運用できますが、DNS の二度引きが発生したりするので、バーチャルメールアドレスでの送受信に使用する MX レコードを作成します。

ドメインの登録を Value Domain で行っている場合は、以下のように設定してください。ドメインが example.com、サーバの IP アドレスが 192.0.2.1、メール送信用のホストが mail.example.com、の場合の設定例です。mail.example.com ではなく example.com を MX に指定しても良いのですが、メールサーバだけ移転とかする際にこの方が楽なので別ホスト扱いにしておいた方が良いと思います。

なお、新規にメールサーバを立てる（誰にもメールアドレスを教えていない状態の）場合は、メールサーバの設定より先に DNS の設定を行っておいても構いません。

クライアントからの送信

以上でメールサーバの設定は完了です。あとはクライアントの設定をして終わりです。

クライアントの設定ですが、以下のような感じになります。（メールサーバを mail.example.com、メールアドレスを test@example.com にした場合。）

SMTP

ホスト	mail.example.com
ポート	587
SMTP AUTH ユーザー	test@example.com
SMTP AUTH パスワード	dovecot-passwd のパスワード
その他	STARTLS を使用して SSL を有効にする必要あり

POP3

ホスト	mail.example.com
ポート	110 （POP3S を使用する場合は 995）
ユーザー	test@example.com
パスワード	dovecot-passwd のパスワード

IMAP

ホスト	mail.example.com
ポート	143 （IMAPS を使用する場合は 993）
ユーザー	test@example.com
パスワード	dovecot-passwd のパスワード

クライアント別の設定例はちょっと書ききれませんので、サブミッション・ポートを利用してメールを送信する － ＠IT や メールの送受信でSSLを利用して暗号化する－ ＠IT を参考にお試しください。

実運用に際して

ほったらかしの運用だとじきにクラックされる可能性もありますので、実際に運用する際はログ監視ぐらいは最低限行っておいた方が良いと思います。

今日のネタはメールサーバの設定っつーことですのでログ監視ツールの使い方は説明しませんが、swatch とか使ったら良いと思います。

んでわ

普段は放置してるのですがちょっと真剣に対応してみることにしました。
（この手の情報欲しい人はある程度 Python 詳しい人だと思いますし）グダグダ説明するような話でも無いので細かい説明は抜きで解決方法だけ書こうと思います。

1. 以下のファイルを safe_terminal.py に保存。
   import sys
   import codecs
   
   def find_encoding(fh):
       if fh.encoding:
           return fh.encoding
       else:
           return 'utf-8'
   
   #error = 'ignore'
   error = 'backslashreplace'
   sys.stdout = codecs.getwriter(find_encoding(sys.stdout))(sys.stdout, error)
   sys.stderr = codecs.getwriter(find_encoding(sys.stderr))(sys.stderr, error)
2. print 等を使うプログラムで safe_terminal.py を import する。
   >>> import safe_terminal
   >>> print u'\uffff'
   \uffff

こんな感じで stdout / stderr に対する print や write 時に変換できない文字をバックスラッシュでエスケープするのが便利かと思います。Python に含まれるライブラリ自体を書き換える方法もありますが、サーバ何台も扱ってると面倒なのでパスって感じです。

変換できない文字を非表示にしたい場合は error = ‘ignore’ に変えてください。

参考にしたページ

PythonのUnicodeEncodeErrorを知る – HDEラボ
Python でUTF-8, shift_jis, euc_jpなど日本語を使う方法

あじゃじゃしたーw

document.createElement(‘iframe’) で作った DOM 要素に onload をセットする場合以下のようなコードを使います。

コメントにも書いてますが、IE8 以下の場合 onreadystatechange を使う必要があります。

参考サイト

• Iframes, onload, and document.domain | NCZOnline

あまり参考にならなかったサイト

• PRB: OnReadyStateChange および IFrame を起動しない OnLoad イベント – support.microsoft.com

Apache から VPS の nginx へ WordPress を移転したいと考えている人もいるかなーと思いましたので、さくら VPS で nginx リバースプロクシを使った WordPress ブログの構築する方法をがっつり書いていきたいと思います。

結構長文になってしまいましたので、先に索引を載せときます。

1. nginx とは
2. nginx が速い理由
3. リバースプロクシ
4. さくら VPS にインストールするシステム構成
5. EPEL パッケージリポジトリのインストール
6. MySQL のインストール
7. PHP のインストール
8. nginx のインストール
9. nginx と PHP FastCGI の設定
10. WordPress のインストール
11. Nginx Proxy Cache Purge WordPress プラグインのインストール
12. ベンチマーク
13. 参考サイト

nginx が速い速いとだけ言われてもいまいち腑に落ちない方もいらっしゃるかと思いましたので、最初の方の章は nginx 自体の説明にしました。前置きは置いといてとりあえずインストール方法を知りたい方は、『さくら VPS にインストールするシステム構成』あたりからどうぞ。ちなみにさくら VPS は CentOS ですので、他のレン鯖でも OS が同じなら同じ手順でインスコできると思います。

サンプルのファイルをまとめた zip を nginx-examples.zip に置いてますので、とりあえずファイルだけ欲しいって人はこちらをどうぞ。

あと、なんとなくあった方が良いかなーと思いまして Apache と nginx のベンチマークもしてみました。結果の方は最後の方に載せてますが、結論だけ言えば nginx は多い日も安心のロリエセーフティロング高性能です。

nginx とは

まず最初に nginx の wiki から引用します。

Nginxはその高いパフォーマンスと安定性、豊富な機能、設定の容易さ、消費リソースの低さで知られています。

NginxはC10K問題に取り組むべく開発された一握りのサーバのうちの一つです。従来のサーバとは異なり、Nginxはリクエストの処理をスレッドに依存していません。その代わりにもっとスケーラブルな（非同期の）イベント駆動アーキテクチャを使用しています。このアーキテクチャはメモリ使用量が少ないだけでなく、最も重要な事として、稼働時のメモリ使用量が予測可能であるということです。

http://wiki.nginx.org/NginxJa

C10K問題とは、ハードウェアは安くなって大量のクライアントを同時処理できるようになったけど、OS やサーバプログラムの実装がボトルネックになってて1万（=10K）クライアント以上は処理できない(*´・ω・)(・ω・｀*)ﾈｰ、という問題です。（Web2.0の先にあるC10K問題 － ＠IT の説明が分かりやすいと思いますので詳しく知りたい方はどうぞ。）

上の概要に書いてますが、nginx はC10K問題を解決すべく作られた新しいウェブサーバですので、Apache 等の従来からあるウェブサーバと比べて本質的にスケーラブルなシステムとなっています。

nginx が速い理由

開発されてる方でしたら、nginx が速いと言う話をどこかで聞いた事があるかと思います。

実際のところ nginx が速いと言うよりも、nginx は Apache などの従来のサーバと比べ少ないリソースで複数の HTTP リクエストを処理できるように設計されているため、サーバが負荷の高い状態になっても性能が劣化しにくい、と言うのがより正確だと思います。

ということで、nginx が高負荷状態に強い仕組みについて簡単に説明しようと思います。

nginx では外部からのネットワークコネクションを受け付けるプロセスをマスタープロセス、HTTP リクエストに対するレスポンスを返すプロセスをワーカープロセスと呼びます。マスタープロセスはコネクションを受け取ると稼働中のワーカープロセスのいずれかに HTTP レスポンスを返す処理を行うよう指示します。（マスター／ワーカープロセス構成自体は TCP/IP ベースの Unix daemon の一般的な構成ですので速い理由と関係ありません。）

nginx のワーカープロセスは（kqueue (FreeBSD 4.1以降)／epoll (Linux 2.6以降) などのカーネルによって異なる）非同期 I/O 通知メソッドを使い、複数のリクエスト／レスポンスを一つのプロセスで平行して同時に処理します。

一方、Apache などの従来のウェブサーバでは、リクエストを応答するプロセスは同期 I/O を使います。同期 I/O を使うと一つのワーカープロセスは複数の HTTP リクエストを同時に処理することができません。複数の HTTP リクエストを処理する場合は、先行するリクエストが完了するのを待って順次処理していきます。

Apache の場合、サーバにアクセスが集中し応答すべきリクエストが増えてきて、既に起動しているワーカープロセスだけでは処理が追いつかなくなると、新しいワーカープロセスを起動したり／新しいワーカープロセスを起動できない場合応答中のレスポンスの完了を待ってからリクエスト処理を開始することになります。

ワーカープロセスはそれぞれある程度のメモリを使用しますので、システムリソースから決まる同時応答可能な上限を越えると（スラッシングが発生するなどの原因で）ウェブサーバ全体の性能が急激に悪化します。（MPM worker を使って Apache をマルチスレッドで動かす場合も、1スレッドに対してそれなりのシステムリソースが必要となりますので、高負荷状態においてこの問題はそれほど改善しないです。）

それに対して nginx の場合、非同期 I/O を使って一つ（設定により増やせますがあくまで少数）のワーカープロセスですべてのリクエストを処理するよう設計されいます。必要なシステムリソースが少ないので、Apache では性能が悪化する局面でも極端に性能が悪化しません。なので nginx は速い、ということになります。

ちなみにワーカープロセスが行うレスポンス処理については Apache と nginx で特に性能に差がある訳ではありませんので、1リクエスト当たりの実処理時間はだいたい同じです。（一部のベンチマークではレスポンス自体は nginx の方が遅いという数字が出ていますが、自分のサイトで測った限りでは意味のある差はでませんでした。いずれにしても今時のサーバだと、ワーカープロセスの性能の優劣は特に気にする必要はないと思います。）

リバースプロクシ

リバースプロクシとは、ざっくり言いますとウェブサーバをまるごとキャッシュする機能です。

WordPress などを動かす場合、アプリケーションを実行する部分がウェブサーバのボトルネックとなります。このボトルネックを解消するために、WP Super Cache などのアプリケーションレベルでのキャッシュや mod_cache などのウェブサーバレベルでのキャッシュがありますがウェブサーバと別にリバースプロクシサーバを用意しプロクシサーバがキャッシュを行うという解決方法もあります。

リバースプロクシを加えたウェブサーバの処理は下図のようになります。

リバースプロクシサーバがフロントエンドとなり、80 番ポートで外部からの HTTP リクエストを受け取ります。
リクエストされた URL がキャッシュされていれば、プロクシサーバはキャッシュ済みのレスポンスを返します。
キャッシュされていなければウェブサーバへリクエストを転送し、レスポンスをキャッシュして返します。

プロクシサーバには PHP スクリプトを実行する機能などは不要ですので、通常ウェブサーバよりも高速に動くよう実装されています。システム構成にリバースプロクシを加えることで全体での処理能力が高くなります。

nginx をリバースプロクシにする場合、リバースプロクシの設定が簡単なので（一つの設定ファイルにフロントエンドのプロクシサーバとバックエンドのウェブサーバの設定を記述できます）、とりあえずリバースプロクシも立てとけって感じです。

ちなみに、nginx をリバースプロクシに、バックエンドのウェブサーバは元から動いていた Apache そのまま、といった構成も可能です。VPS（特にさくら VPS 512）ではメモリサイズ的にこの構成は少し厳しいと思いますが、リソースにある程度余裕がある状況では費用対効果の高い性能改善策になると思います。

さくら VPS にインストールするシステム構成

ということで、nginx 自体の説明はこの辺にして、さくら VPS で nginx リバースプロクシを有効にした WordPress ブログのインストール方法について説明していきたいと思います。

まずさくら VPS のデフォルト OS は CentOS でして、OS はそのまま使う設定で話を進めます（VPS に Debian 入れたりする人は nginx の How To 記事なんか見なくても自分で設定できると思いますし）。CentOS ならさくら VPS 以外のサーバでもだいたい同じような手順でインスコできると思います（プレインストールされている yum パッケージの構成やバージョンが違う場合、一部異なる手順になるかもしれませんが）。

インストールするシステム構成はこんな感じです。リバースプロクシ／ウェブサーバともに nginx を使います。nginx には PHP を実行する機能がありませんので、FastCGI サーバとして PHP を実行します。

• nginx 1.0.6 + Cache Purge plugin
• PHP 5.3.3 + FastCGI + eAccelerator
• MySQL 5.0.77
• WordPress 3.2.1-ja

MySQL は yum のパッケージから普通にインスコします。

PHP は最近 yum に追加されたっぽい php53 パッケージを使います。eAccelerator があった方が良いのですが、php53 系列には eAccelerator のパッケージが無いのでこれだけソースからインスコします。

nginx はソースからビルドしてインスコします。nginx のパッケージが EPEL リポジトリにあるのですが、WordPress を動かす場合パッケージ版の nginx には含まれていない Cache Purge プラグインが欲しいので、パッケージは使いません。（nginx にプラグインを追加する場合はビルド時に組み込む必要があります。）

以下、EPEL のインスコ、MySQL インスコ／起動、PHP インスコ、nginx インスコ、nginx / PHP FastCGI の設定、WordPress インスコ…みたいな順番で書いてます。知ってるところは適当に読み飛ばしてください。

特に明記しない場合すべて root で作業を行う前提で書いています。まずサーバにログインして su するか sudo してください。

EPEL パッケージリポジトリのインストール

最初に EPEL パッケージをインスコします。EPEL の公式サイト から epel-release-5-4.noarch.rpm をダウンロードして rpm コマンドでインスコします。（EPEL 6 系列は CentOS にはインストールできませんので epel-release-5-4.noarch.rpm もしくはバージョン 5 系列の最新版をインストールしてください。）

EPEL パッケージのインスコ方法も含めて、yum 関係で VPS を借りたら最初にしといた方が良い作業が ウェブ開発者のための、1時間でできるLAMP環境構築術（CentOS編） – さくらインターネット創業日記に書かれてますので、よく分からない人はまずはこちらをご覧ください。

MySQL のインストール

MySQL は yum パッケージをインスコします。

インスコしたらサーバを起動し、chkconfig でリブート時に MySQL サーバが立ち上がるように設定します。

PHP のインストール

yum から php53 パッケージをインスコし、eAccellaretor だけソースからビルドします。

php53-xml は要らないような気もしますが検証するの忘れてましたのでとりあえずインストールするということで。

PHP をインスコできたら、eAccellaretor のソースコードを SourceForge からダウンロードして展開します。（eAccellaretor のビルド作業については、make install 以外は一般ユーザーで作業しても問題ないです。）

ビルドしてインスコします。

make install で /usr/lib64/php/modules に eaccelerator.so がコピーされますので、/etc/php.ini の extension に eaccelerator.so を追加します。

デフォルトでは eaccelerator.cache_dir が /tmp/eaccelerator になっていますが個人的に /var/tmp 以下にしたいので、php.ini の末尾に以下の設定を加えます。デフォルトで問題ない場合はそのままでどうぞ。

eaccelerator.cache_dir を作ります。パーミッションはサーバによって適当に変えてください。

nginx のインストール

nginx をソースからビルドするため、ビルドと実行に必要な yum パッケージをインスコします。

スクラッチからビルドすると init.d のスクリプト等を用意しないといけないので、nginx のソースパッケージ (SRPM) をダウンロードしてから、最新版の nginx を Cache Purge Plugin 付きでビルドするように nginx.spec を書き換えます。

まず EPEL 配布サイトから nginx の SRPM nginx-0.8.54-1.el5.src.rpm をダウンロードします。

SRPM は rpm コマンドでインスコします。/usr/src/redhat/SPEC に nginx.conf が、/usr/src/redhat/SOURCES に SRPM に含まれるファイルが展開されます。

rpm -ivh を実行する際に mockbuild ユーザーが存在しないためワーニングが出ますが無視して問題ないです。

SRPM をインスコできたら、/usr/src/redhat/SOURCES に最新版の nginx と Cache Purge plugin をダウンロードします。

nginx-1.0.6 で Cache Purge を有効にした nginx.spec を nginx.spec に置いてますので /usr/src/redhat/SPECS ディレクトリにダウンロードしてからビルドします。

ビルドが終われば /usr/src/redhat/RPMS/x86_64 に nginx-1.0.6-1.x86_64.rpm が作成されますので rpm コマンドでインスコします。

nginx と PHP FastCGI の設定

必要なものがインスコできたら nginx の設定をしていきます。

PHP FastCGI サーバ起動用スクリプトの作成

FastCGI サーバとして PHP を起動するためのスクリプトを php-fastcgi に置いていますので、ダウンロードしてから /etc/init.d に置きます。

PHP FastCGI サーバの実行ユーザー等を変更する場合は、php-fastcgi スクリプトの以下の箇所を変更してください。なお、以下の説明では 9000 番ポート上で PHP FastCGI サーバを起動する設定で例示しています。また、FastCGI サーバとの通信に TCP/IP ではなく Unix ドメインソケットを使用したい場合は php-fastcgi の spawn-fcgi の起動方法を変更してください（変更方法は各自で調べてください）。

pidfile を作成するディレクトリは、PHP FastCGI サーバの実行ユーザー（変更しなければ nginx）から書き込める必要がありますので、php-fastcgi スクリプトをデフォルトのまま使う場合は予め /var/run/nginx ディレクトリを作成する必要があります。

以上の作業が終われば、とりあえず php-fastcgi を起動してみます。

エラーが出る場合は設定を確認してください。

nginx.conf の修正

/etc/nginx/nginx.conf にリバースプロクシとバックエンドウェブサーバと PHP FastCGI サーバの設定を追加します。ちょっと長いですが全部貼ります。サーバにファイルを置いてますのでコピペして使いたい方は nginx.conf をどうぞ。

この設定ファイルは以下のサーバ環境用に設定しています。サーバ環境に応じて適宜修正してください。

• サーバの IP アドレス: 192.0.2.1
• ホスト名: example.com
• HTML ドキュメントルート: /var/www/html
• リバースプロクシのポート: 80
• バックエンドウェブサーバのポート: 8080
• PHP FastCGI サーバのポート: 9000

ドキュメントルートに対して nginx ユーザーから読み込み権限が必要になります。WordPress を使用する場合ウェブディレクトリに対して書き込み権限も必要ですので、ドキュメントルートのオーナーを nginx ユーザー（FastCGI の実行ユーザー）に変更しておく方が良いかもしれません。

リバースプロクシのキャッシュを PC と携帯とスマートフォンで切り替える設定を入れています。不要な方は location / の設定を以下のように変更してください。Ktai Style や WPTouch を使う場合はそのままで。

設定ファイルを自分の環境用に書き換えたら nginx を動かします。

この状態でブラウザからホストにアクセスすると 403 Forbidden が表示されると思います。

ドキュメントルートに空のファイルを作成し、ブラウザでアクセスできるか確認します。

同じく phpinfo を実行するスクリプトを作成し、ブラウザでアクセスできるか確認します。

動作が確認できたら index.html と phpinfo.php を削除し（残してても良いですけど）、chkconfig を実行してリブート時に nginx と PHP FastCGI サーバが起動するように設定します。

WordPress のインストール

PHP の動作が確認できれば、WordPress のインストール自体は Apache の場合とそれほど違いません。

まず VPS ですので mysql コマンドでデータベースを作ります。

ja.wordpress.org から最新版の WordPress をダウンロードして /var/www/nginx に展開します。

wordpress ディレクトリの wp-config-sample.php を wp-config.php にコピーし、

wp-config.php にデータベース設定と FS_METHOD を追加します。FS_METHOD を direct にすると、WordPress プラグインなどのダウンロード時に ftp を使用せず PHP スクリプトから直接ダウンロードするようになります。必須ではありませんが、VPS で ftp の設定をわざわざするのも面倒なので付けてます。

WordPress の設定が終わったら、ブラウザでアクセスする前に、/wordpress/wp-admin へのアクセスをキャッシュしないよう nginx.conf のリバースプロクシの設定を変更します。（この修正を入れた nginx.conf を nginx-wordpress.conf に置いています。）

nginx.conf を修正したらリブートします。

これでブラウザから http://example.com/wordpress/ などのインストールした URL にアクセスすると WordPress のインストーラが立ち上がります。

パーマリンクの変更

パーマリンクを /wordpress/archives/1 等の形式に変更する場合、WordPress の設定を変える前に nginx.conf のバックエンドサーバの設定を変更する必要があります。

WordPress のインストール先が /wordpress/ で、/wordpress/ 以下のみを WordPress として運用する場合（トップページを WordPress に割り当てない）は、以下のように nginx.conf の location / に if (!-f $request_filename) { } を加え、location /wordpress を加えます。

設定を変更したら nginx をリブートします。

nginx をリブートしたら WordPress のパーマリンク設定を変更します。

パーマリンクの変更（WordPress ディレクトリとは別のディレクトリにサイトのホームページを設定する場合）

なにを言ってるかよく分からないかもしれませんが、WordPress の一般設定で以下のキャプチャのように WordPress のアドレス (URL) とサイトのアドレス (URL) を変えた場合に、パーマリンクの変更を行うための設定方法です。

この設定を行う場合、まず wordpress/index.php をコピーして HTML ドキュメントルートに index.php を作ります。

コピーした index.php の require 部分を以下のように書き換えます。

nginx.conf のバックエンドサーバの設定を書き換えてから、nginx をリブートします。

nginx をリブートが完了したら WordPress のパーマリンク設定を変更してください。

Nginx Proxy Cache Purge WordPress プラグインのインストール

WordPress のインスコが終わったら Nginx Proxy Cache Purge WordPress プラグインを入れます。普通に WordPress のダッシュボードからインスコしてください。

このプラグインを入れると、記事を更新した際に nginx のキャッシュがパルスのファルシのルシがパージされるようになります。このプラグインを入れないと nginx のキャッシュタイムアウトまでの間（上の設定だと10分）古い内容で表示されることになりますので、nginx でリバースプロクシ立てたサイトで WordPress を動かすときは一緒にインスコしておいた方が良いです。

ちなみにこのプラグイン、パージ URL が /purge/* 固定（上の nginx の設定はこれに合わせています）でソースコード中にハードコーディングされていますので、パージ URLを変更したい場合はプラグインのソースを書き換える必要があります。上の nginx の設定例ではパージ URL を /purge にしてますので書き換えなくても問題ありませんが、変更したい場合はちょっと不便かもです。

nginx purge とかで WordPress プラグインを検索すると、他にも nginx のキャッシュをパージするためのエナがチャンガしてるプラグインが何個かありますので、他に良さげなのがあればそちらをどうぞ。

ちなみに、リバースプロクシでキャッシュしている場合は WP Super Cache 等のキャッシュプラグインは要りませんので、他のサイトから移行してきた場合キャッシュ関係のプラグインは無効または削除した方が良いと思います。

ベンチマーク

画竜点睛を欠くふいんき（なぜかry）でしたので、さくら VPS 512 上で httperf でWordPress のベンチマークを取ってみました。ついでにさくらスタンダードの WordPress に対してもベンチマークを取っていますが、こちらはサーバ環境が違いすぎるのであくまでも参考値ということで。

VPS の Apache はほぼデフォルトの設定／VPS の nginx はリバースプロクシありの設定ですので、ぶっちゃけフェアな比較ではありませんがまあこんなもんだと思います。（Apache の mod_cache を有効にするとか性能的な対策が可能ですが、別の VPS 鯖で mod_cache 入れたら過負荷になったときにサーバが落ちた（入れる前は過負荷でも落ちなかった）のでピーク時性能についてはどっちもどっちだと思います。まあ細かいことを言い出したらキリが無いので別の条件でベンチ取りたい人はよろしく〜(^o^)／）

まず最初のグラフは1秒あたりのサーバが返したレスポンス数です。

グラフのY軸がレスポンス数／秒、X軸が1秒あたりにクライアントから同時に発生したリクエスト数です。

nginx が nginx の WordPress トップページに対するベンチマーク、apache(VPS) が VPS 上で動かした Apache の WordPress トップページに対するベンチマーク、apache(STD) がさくらスタンダード上（の Apache）で動かした WordPress トップページに対するベンチマークの値です。

一個だけ見てもよく分からない部分が多々ありますので先にグラフを全部貼ります。

次のグラフは正常に完了したリクエストのレスポンスタイム(ミリ秒）です。

同時リクエスト数 70 〜 80 の間で Apache (VPS) のレスポンスタイムが 0 になっているのは、次のグラフのとおりサーバが落ちていたためです。

最後のグラフはエラーが返された数です。

Apache (VPS) では、リクエスト数（X軸）が70と80の時にエラーが70と80返されています。ベンチマークのリクエストが50を越えたあたりからサーバが処理しきれなくなって、70 〜 80 の間完全に落ちた状態となり、（このベンチマークは連続して行いましたので）90ぐらいから先に送ったリクエストが（タイムアウトなどで）終了し始め、100リクエストのころにはちょっと回復していた感じになっています。

Apache (STD) が微妙にエラーを出してるのは、アクセス制御用のモジュールを入れているからだと思いますが、自分で設定したサーバでは無いので詳細は不明です。

以上から、

• nginx: 25 〜 44 リクエスト／秒のスループットで、同時リクエスト数が 60 を越えたあたりからレスポンスタイムが悪化（最高値 720.2 ms)、同時リクエスト数が 90 を越えたあたりからエラーが出始める。
• Apache (VPS): 13 〜 24 リクエスト／秒のスループットで、同時リクエスト数が 20 を越えたあたりからレスポンスタイムが悪化（最高値 3643.2 ms)、同時リクエスト数が 50 を越えたあたりからエラーが出始め、一時完全に落ちた。
• Apache (STD): 18 〜 30 リクエスト／秒のスループットで、レスポンスタイムは線形に悪化していないので詳細不明、割とすぐにエラーを返し始める。共有サーバだし詳細もよく分からんのでご勘弁を。

みたいな感じだと思います。

とりあえず VPS で WordPress を動かすなら nginx 使う方が良い(*´・ω・)(・ω・｀*)ﾈｰ、って結果でした。

VPS についてはベンチマーク中に Load Average も計ってたんですが、nginx の最高値が 0.14、Apache の最高値が 132.56 でした。お話にならんって感じです。

VPS サーバで一番メモリを使ってるのは MySQL サーバですので、ここをチューニングするとさらに速くできるかも、です。
nginx のキャッシュに memcached を使ったりもできるのですが、さくら VPS 512 にデータベースやらなんやら全部置いててメモリ的に厳しいので今のところパスしてます。

こちらの記事によると別の VPS に DB サーバを立てたりしてもおkみたいですので、チューニングの余地は結構ある感じです。
さくらクラウドで動かすのもいいかもしれませんねー。

てことで、WordPress が重い重い言ってる人は nginx に乗り換えチャイナYOU！

参考サイト

最後に sakuratan.biz を nginx に移行する際に参考にしたページのリンクを貼っときます。この記事のとおり作業してみたけど何かうまくいかないって時は以下のサイトに解決方法があると思います。

• wiki.nginx.org
• apache のかわりにnginxを使ってみる(11) nginxのproxyでキャッシュを削除する方法 | レンタルサーバー・自宅サーバー設定・構築のヒント
• WordPress サイトに nginx を導入する : dogmap.jp
• Nginx and PHP-FastCGI on CentOS 5 – Linode Library
• [PHP] PHP5.3.0でのアクセラレータ導入 – ありんく tech-log
• ウェブ開発者のための、1時間でできるLAMP環境構築術（CentOS編） – さくらインターネット創業日記
• Na-ga.net » Blog Archive » httperf man (OUTPUT) – Linux を中心とした忘却メモ

the_content を the_excerpt に変えたら個別ページも抜粋表示になったでござるorzの巻

とりあえず WordPress テーマの中の index.php で the_content を呼び出してる箇所を the_excerpt に変えたらいーんだろ？とか思って適当にいじくってみたら、個別ページ（ブログとかページとか）も含めて WordPress 全部が抜粋表示になっちゃいました、テヘ☆

the_excerpt が適当に記事の内容判断して抜粋に切り替えてくれるのかと思ったんですが、この関数は単に抜粋表示するだけのもので、どのページを抜粋にするかは自分で制御しないといけないみたいです。

twentyeleven テーマとかだと元から the_excerpt が入ってて適当にやってくれるみたいなんですが、今 sakuratan.biz で使ってる barecity テーマの場合はそういう処理が入ってないので自分で設定しないといけないっぽいです。

で、色々試行錯誤したあげく↓みたいな感じでテーマの index.php を修正しました。

is_singular() は個別ページの時に真になります。

the_content の引数 __(‘(more…)’) は前に more を使って抜粋していたときの名残りですのであんま気にしないでください。

twentyeleven とかですとこの辺は↓みたいな感じになってます。

is_search() は検索結果表示の時だけ真になりますので、twentyeleven ですと検索時以外は全文表示してます。

WordPress の is_ 関数は wp-includes/query.php で定義されていますので、色々試してみたい方はソース見てください。

excerpt_length フィルタを設定しても抜粋表示文字数が変わらないでござるorzの巻

一覧に表示する抜粋の長さは、excerpt_length フィルタで制御できるみたいなんで、テーマの functions.php を↓みたいに変えて400文字に設定しようとしたら全然表示数が変わりませんでした。

ソース grep して調べた結果、WP Multibyte Patch に excerpt_mblength フィルタというのがあって、excerpt_length > excerpt_mblength になると excerpt_mblength のデフォルト値で切り捨てられているため、設定したフィルタが有効になっていない感じでした。

ちなみに WP Multibyte Patch をインスコした状態の excerpt_length とexcerpt_mblength のデフォルト値は 55 と 110 です。

で、最終的に functions.php は↓のようにしました。

なお WP Multibyte Patch は独自の設定ファイルがあり、wp-content/plugins/wp-multibyte-patch/wpmp-config-sample.php を wp-contents/wpmp-config.php にコピーして設定を書き込むとそれがデフォルトになるみたいです。

なんか面倒くさそうなので functions.php で直しましたが、そういう方法もあるってことで。

ちなみに今回 the_excerpt に変えたかった理由は、抜粋表示してたときの方が Google からのアクセスが多かったからです。( ﾟ∀ﾟ)o彡ﾟSEO！SEO！

実際のところ関係あるのか無いのかよく分かりませんが、5月中頃と比べて10倍ぐらい検索エンジンからの流入が落ちてまして、その対応でサーバ移転したりブログの設定変えたりしてます。3ヵ月後ぐらいには結果が分かると思いますので、その頃にそれっぽい記事書くかもしんないす。

原因は MySQL の InnoDB が使用する ibdata ファイルがディスクを食いつぶしてディスクフルになってたためでした。

ibdata はテーブルスペースを保存するファイルで、CentOS ですとデフォルトで /var/lib/mysql/ibdata1 に作成されます。MySQL のデフォルトでは ibdata が自動で拡張されていく設定になっていますので、放っておくとどんどんファイルサイズがでかくなって、さくらの VPS とかですと結構あっさりディスクフルになりました。

とりあえず復旧できたんで手順とか残しときます。同じようにトラブった方は参考程度にどうぞ。

まず ibdata1 がディスクを食いつぶしているので、復旧するにはこれを消すとかファイルを小さく必要があります。

ファイルサイズを小さくする方法は調べたらいっぱいでてきますので（13.5.7 InnoDB データとログ ファイルの追加と削除 とか ibdata1 のサイズを減らす手順 とか ibdata1のサイズを減らす方法とか）、概要だけ引用しますと、

1. 全ての InnoDB テーブルをダンプする為に mysqldump を利用してください。
2. サーバを停止してください。
3. 全ての存在するテーブルスペース ファイルを削除してください。
4. 新しいテーブルスペースを設定してください。
5. サーバを再起動してください。
6. ダンプ ファイルをインポートしてください。

MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.7 InnoDB データとログ ファイルの追加と削除

という感じだったりします。要はバックアップ取ってテーブルスペースを作り直せということのようです。

ただまあディスクフルしてるんでサーバ上に mysqldump のダンプファイルなんか置けないので、ssh 経由で mysqldump を実行することにしました。↓のように ssh を起動することで、ネットワーク越しにコマンドを実行して mysqldump の出力をローカルに直接保存できます。

それとコマンドを実行する前にサーバ上のサービスをできるだけ止めてある程度作業用のメモリの確保して、ついでに不要なファイルをできるだけ削除しておいた方が良いと思います。メモリかスワップか何が原因か調べてる暇も無かったので詳細は不明ですが、リソースが足らないと mysqldump がテーブル構造を読み込む際にエラーを出します。

今回はリストアする必要が無いテーブルが何個かありましたのでダンプする対象をテーブル単位で指定していますが、全部リストアする場合はデータベース単位で指定してもらえばよろしいかと思います。運用形態によっては mysqldump に –single-transaction オプションを指定してもらった方が良いかもしれません（とりあえずウチんとこでは不要だったので指定してませんが）。

ダンプできたら mysql を止めてから ibdata1 と ib_logfile0 と ib_logfile1 を消します。他のサイトだとリネームした方が良いとか書いてますがそんな余裕無いのでいきなりマジ削除しました。最悪データ全部豚でもいーや、の覚悟でどうぞw

/etc/my.cnf に ibdata1 のサイズ制限と innodb_file_per_table を加えてからmysqld を再起動して回復しましたよ、という感じです。

innodb_file_per_table を指定すると、各テーブルの中身は共有テーブルスペースでは無く個別のファイルに保存されるようになるのですが、こっちのファイルも放置しておくと大きくなっていきますので、定期的に ALTER TABLE を実行してデフラグする必要があります。（詳しくは 13.5.14.3 テーブルのデフラグメント化 とか 拡張され続ける InnoDB のデータファイルのサイズを小さくする方法 とかをご覧ください。）

個別に ALTER TABLE 実行するのも面倒なので、全ての InnoDB テーブルに対して ALTER TABLE を実行するスクリプトも書いてみました。よろしければどうぞ。

MySQL にパスワード無しで root ログインできる前提でスクリプト書いてますので、その辺の設定変えている方は適当に改造して使ってください。

さて HTML5 界隈が騒がしい今日このごろですが、data- 属性というものを皆さんご存知でしょうか？

Twitter のツイートボタン作成ページで作った HTML に入ってる data-via とかのことです。最近色んなところでよく目にしますが、これを使うと任意の DOM 要素に任意の値をセットできるみたいです。

で、この data- 属性なんですが HTML5 の仕様の一部だったみたいです。恥ずかしながらちゃんとした仕様だということを最近知ったのですが、個人的には canvas とか video とかをブッちぎって一番重要な HTML4 からの変更点じゃないかと思います。

てことで本日は、努力家だけど恥ずかしがり屋さんの data- 属性さん(46歳)が実はいぶし銀のスーパースターだということをプロバガンダをしようと思います。

data- 属性は HTML5 の規格の一部

まず超基本的なことですが、data- 属性は HTML5 の規格の一部です。

W3C の HTML5 draft の 3.2.3.8 Embedding custom non-visible data with the data-* attributes に定義されています。

Custom data attributes are intended to store custom data private to the page or application, for which there are no more appropriate attributes or elements.
3.2.3.8 Embedding custom non-visible data with the data-* attributes

W3C では data- 属性のことを Custom data attributes と呼んでいるようです。日本語では独自データ属性と表記しているサイトが多いと思います（独自データ属性 – グローバル属性 – HTML5 タグリファレンス – HTML5.JP とか）。

重要なのは↓の部分。（英語の仕様を貼っててもアレなんで HTML5.JP さんから引用）

すべての HTML 要素に対して、独自データ属性をいくつでも、どんな値でも指定することができます。
独自データ属性 – グローバル属性 – HTML5 タグリファレンス – HTML5.JP

どの要素に何個でも付けれるらしいです(´・ω・`)便利だねー

てことで HTML5 の独自データ属性を使うと、meta タグとか（Twitter がやってた）、type=”hidden” の input タグとか（form の下位要素じゃないと HTML 的にまずいような）、display:none にした span とか div とか（なんだかねーって感じ）、id や class 属性とか（属性値に制限あり）に、無理やりセットしてたデータをスマートにコーディングできるようになります。

使い方

まず HTML は以下のように書きます。data- に続けてアルファベットと – で任意のキー名を指定します。

DOM を使って JavaScript から値を参照する場合は以下のようにコーディングします。

上のコードでは dataset プロパティが存在するかチェックして dataset に対応していないブラウザをフォールバックしています。手元の Firefox4 が dataset プロパティに対応していないようでしたので、実際にコーディングする際は getAttribute だけで良いような気もします。

dataset プロパティを使用する場合は、キーに – が含まれている場合は Camel にします。（data-ship-id → dataset.shipId）

値をセットする場合は dataset プロパティに代入するか setAttribute を使います。jQuery を使った方が便利ですのでこの辺の例は省略、ってことで興味ある方はご自分でお調べください。

jQuery の場合

jQuery には $.data() と .data() という似たような名前の関数がありまして、HTML5 の独自データ属性と対応するのは .data() の方なのでご注意ください。$.data() も .data() もプレースホルダを提供する関数なのですが、$.data() の方は完全に jQuery 独自の実装となっています。

で、.data() の方は大方の読者の予想の通り↓のようにコーディングできます。

値をセットする場合はこんな感じ。

ちなみに、.data() で値をセットしても data- 属性には書き込まず $.cache に値がセットされます。data- 属性に書き込みたい場合は .attr() を使ってください。なんかややこい挙動ですが、なんか理由があってこーなってる気がします。（jQuery のサイトでなんで HTML5 の data- に書き込まないの？って感じのコメントしてる人がいますが華麗にスルーされてますし。）

また、.data() の引数を省略するとデータをオブジェクトで返します。

値にはオブジェクトも指定できます。

ぶっちゃけ大して難しいところは無いと思いますので説明はこの辺で。

ということで、いぶし銀 JavaScripter を目指す皆様におかれましては data- 属性で千本バント練習に打ち込むのがよろしいかと思います。

ビープ音の文字コードは 0×7

まず基本的なこととして、ASCII コードの 0×7 は BEL となっており、（デバイス的に）適当なベル音を鳴らす文字コードとなっています。

つまり 0×7 を出力したらビープ音が鳴るってことです。

シェルから鳴らす

シェルから鳴らす場合、echo コマンドを使います。コマンドラインから 0×7 を指定するにはコントロールシーケンス ^G を入力します。

一般的なターミナルでは [CTRL]+v [CTRL]+g を連続して入力するとコントロールシーケンス ^G が入力できます。文字列 “^G” を入力しても鳴りませんので注意してください。

printf コマンドがインストールされている環境では、以下のようにビープ音を鳴らすこともできます。

プログラミング言語から鳴らす

0×07 が出力できれば良いので、基本的にどのプログラミング言語からでもビープ音を鳴らすことができます。

代表的な LL 言語で鳴らす方法は以下のようになります。

全部いっしょとか言わないのw

んでわ。