PHPのほかにNginxでもアップロードサイズ設定を
INDEX
WordPressに限らず、Drupalでも他のCMSコンテンツ・マネージメント・システム）でも必ずPHPのリソースの割り当てを設定しますよね。WordPressならだいたい250MB前後の最大ファイルアップロードサイズを要求されるはず。VirtualminだとこのあたりもGUI設定でポチポチと変更していけます。これはApacheでもNginxでも同じことだからもう体に染みついてるんだけど、Nginxの載ってるサーバーだとNginxの設定でも
client_max_body_size 100m;
こんな感じでconfファイルに加えてあげなきゃいけなかった。これ、Apache慣れしていると結構な割合で忘れてしまうんですよね。plug-inやThemeをアップロードする時にNginxに叱られて
「ああ、そうだそうだ」
とVirtualminの管理画面から追加するんです。そして必ずサービスのリロードも必要。まぁ、これはApacheも同じですが、Apacheの設定ファイルに直接何か仕掛けることって本当に少ない。広い心で何でも任せられるイメージのApacheに対してNginxはまだまだ小学生の子供のようで、
「ハンカチ持った？ お弁当は？」
といろいろ気をもんであげないといけない。そんなイメージがあるのは私だけでしょうか？
なぜNginxかという話はこちらの記事に書いてます。併せて読んでくくださいませ。
『百聞』でやりたいこと – 基本は記事を読んでいただくこと
重要な設定ははNginxのサイトにRecipeで確認できます
そう、だからというかちゃんと保護者のようにNginxにはRecipeという名目で設定ファイルへの追加記述が記されてますね。
とにかくたくさんのCMSなどのWebアプリケーション用に細かく設定が載ってます。いやはや、このリストが整然と並ぶ様を美しいと思ってしまうのよね。こういうしっかり整然と管理をするところってやっぱり信頼が増すので成長も早いんでしょう。おばさんはこれだけでうれしくなるんですよ。
我がサーバーでのNginx設定もほぼこの通りに書きました。まぁ、当然サイトのパスやsocketのルートなどはちゃんと環境に合わせて書き換えないとだめですけど。
あとはgzipを有効にしてリストを書き足したくらいかな。
これは後でまたお話ししますけどサイトの表示テストのPageSpeed Insightsで推奨されますから、
できることは一つずつやっておくのがいいと思いますね。簡単ですから。
スピードアップに効果あり！ 圧縮を可能にするgzip on; 設定のサンプル
ちなみにこれだけ付けてます。もしよかったら参考にどうぞ！
# gzip設定
gzip on;
gzip_comp_level 2;
gzip_http_version 1.0;
gzip_proxied any;
gzip_min_length 1100;
gzip_buffers 4 32k;
gzip_types
font/eot
font/otf
font/ttf
image/bmp
image/svg+xml
text/plain
text/html
text/xml
text/css
text/javascript
application/xml
application/xhtml+xml
application/rss+xml
application/atom_xml
application/javascript
application/x-javascript
application/json
application/ld+json
application/manifest+json
application/wasm
application/x-web-app-manifest+json
application/x-httpd-php;
gzip_disable "MSIE [1-6].(?!.*SV1)";
gzip_vary on;
そうそう、それから何度も言うけど書き換えたらNginxの再起動は必ずやりましょう！
この初期の設定をやっておかないとパーマリンクの変更の時などに躓くことになりますから、とても大事なことですね。
location / {
# This is cool because no php is touched for static content.
# include the "?$args" part so non-default permalinks doesn't break when using query string
try_files $uri $uri/ /index.php?$args;
}
これは書かないとパーマリンクの変更などでうまくいきません。記事だけじゃなくユーザーの表示URLも変更されて表示されないし、なにがどうなったのか、なってからきっと焦って右往左往しますよね。
実は私も失敗の記述になった…
try_files $uri $uri/ =404;
この一行…
解ったふりして勝手にやるよりやっぱりマニュアルを尊重することは重要でした。まぁ、失敗して経験になればそれもよしと言うこで、とりあえずこれで安定稼働させることができましたよ。
次回はいよいよインストール後にやったセキュリティーの話
なんと最後に予告です…
前回インストール時にデータベーステーブルの接頭辞のはなしをしました。何度も繰り返して言いますけれど、セキュリティーはガチガチに固めるのが一番。
攻撃はちゃんと甘いところをめがけて叩きに来るんです。そういうトラブルに陥ったサイトのお手伝いをしたことがあるけど、進入口も隠しますからもう追跡も難しい。なのでまずはログイン用のURLの変更をしましょう。これはもう基本の基本。どなたのWebサイトをお手伝いしたって必ずこの処置はします。
データベースのバックアップも必ずやりましょうね
そして攻撃されたときのためだけじゃなく、データベースのバックアップも当然あった方がいいんですよ。自分の間違いをリカバリしてくれますから。なのでPhpMyAdminもインストールしてアナログ管理もしましょうか。
バックアップについてはサーバーのcloneタスクでバーチャルホスト単位のまるごとバックアップも毎日の深夜にやるし、VMサーバーのスナップショットも何か設定変更するたびにこまめに取るようにしています。
そもそもスクリプトを書いてる時もこういうバージョン管理ってとても重要でしょう？ 後から背筋に汗をかかないように気をつけながら進めるのが気の小さい私の進め方なんです…
なのでテーマを選ぶよりも先にセキュリティー守りましょう！
