かなりハマって悔しかったので備忘録。
LaravelのAuth周りを使ってログイン機能を実装中、ログイン失敗時のフラッシュメッセージとして動かす予定だった withErrors が正常に動かない現象が起こりました。
具体的には AuthenticatesUsers クラスにある sendFailedLoginResponse メソッドがコールされたとき、ログイン失敗を示すメッセージがリダイレクト後のページで取得できず、
$errors 変数にはデータバッグは存在するものの、値が空の状態になりました。
先に結論を書くと、webミドルウェアが二重適用していたことが原因でした。
php artisan route:list を実行すると定義されているルーティング一覧を確認できますが、
そのミドルウェア欄には web,web,auth のように web が二度呼ばれていることが分かりました。
Read More »
以前書いた「nginx + php7 + Lumen な開発環境をVagrantでつくる」をAmazon Linuxに持って行くときの補填記事です。
AmazonLinuxはCentOS 6系ライクだから、EC2に持って行くことを前提とするならVagrantの開発環境も6系で作った方が良かった気がしている。。
ベースは上の記事内で紹介している通りだから、ここではAmazon Linuxで構築するときのコマンドを差分として備忘録に。
違いとしては、Amazonのリポジトリがデフォルトで提供してくれているから、nginxのリポジトリをインストールする必要がなくなった。ちょっぴり楽に。
|
1 2 3 |
# sudo yum install -y nginx # nginx -v nginx version: nginx/1.8.1 |
趣味のプロジェクトで、APIサーバーとしてLaravel製の軽量PHPフレームワーク、Lumenを採用することにしました。
ここではVagrantを使ったローカルの開発環境を作るための手順を残します。
今回は開発用なので、Lumenは /vagrant の中に配置し、
パーミッションの問題を避けるために、nginxもvagrantユーザーで起動することにします。
（関連記事: Let’s Encryptをnginxで使ってみる）
ウソです忘れてました。忘れてたところ、こんなメールが先週届いていました。
これはありがたい・・・本当にエラーになってから思い出すところでした。
3ヶ月ぶりなので、まずはLet’s Encrypt本体をアップデートしておきます。
|
1 2 3 |
$ sudo su - # cd ~/letsencrypt/ # git pull |
タイトル長くてすみません。
最近TypeScriptの勉強をしていて、様々な文章を読ませていただいています。
その一つが次のものなのですが、納得できなかったところがあったので自分なりにまとめてみます。
“TypeScript早わかりチートシート【1.5.3対応】 (2015/08/03）”
http://www.buildinsider.net/language/quicktypescript/01
上の解説では、TypeScript 1.5の文法解説などが分かりやすく書かれており、とても参考にさせていただきました。
インターフェースの宣言には、通常のクラスではないことを示すために、接頭辞に”I”を追加することが多々あります。例えば、”User”クラスはインターフェースとして”IUser”インターフェースを実装している、といったようにです。
先に挙げたページの、インターフェースについての解説で著者は次のように述べています。
命名規則として、先頭にIを付けていた時期もありましたが、現在ではマイクロソフトのガイドライン上で、Iは付けないこと、と改められています。
これを読んだとき、どうしても納得できませんでした。
「Iをつけること」ならまだしも「つけないこと」をガイドラインで明文化されているというのは、自分の中で全くもって同意できなかったからです。
最近趣味の開発範疇でフロント側の勉強をしています。
ビルドツールにWebPackを採用したのですが、ちょっとハマったことがあったので備忘録です。
AWS ELBに証明書を登録しようとしたときにエラーになったので、その回避策をメモ。
AWS ELBではHTTPSで行われた通信をELBデコードして、バックエンドのサーバーとはHTTPで通信することができます。
こうしておくと証明書更新などで複数台のEC2を直接手を入れることなく、またウェブサーバー側のSSL通信に関わるオーバーヘッドも無くなるため、AWS内で構築する場合には採用することが多いかと思います。
この構成を取る場合、証明書、証明書の秘密鍵をELBにアップロードする必要があります。
以前から挑戦したかったAWSの課題のひとつを解決してみようと思います。
AWS EC2やRDSなどのステータスを監視してアラームを上げてくれる、大変便利なCloudWatchですが、管理コンソール以外からアラームを確認する方法としては、SNSトピックに通知した後に自分でSNS連携のアプリケーションを作るなどして対応する必要がありました。
今回はこのアラームを、Slackの任意のチャンネルにポストすることをゴールにしてみます。
たいそうなタイトルだけど実際そんなことない。思ったより長くなってしまったのでお時間のあるときにどうぞ。
今までWordPressのデプロイにはrsyncを使って同期させていたんですが、WordPress専用のRuby製デプロイツール、WordMoveを使ってみようと思い立ちこちらの記事を参考にしながら準備しました。
WordMoveはSSHやFTPでログインしてファイルを置き換えるために、ログインユーザーがドキュメントルート以下への書き込み権限を持っていないとデプロイできません。
前述の参考記事ではドキュメントルート以下の所有者と、ウェブサーバーの実行ユーザーをec2-userに変更する荒技で解決しています。ここが自分の中でめちゃくちゃ引っかかったので、セキュリティ的により良いと考える権限管理ついて書いてみます。
（後から調べたことですが、Red Hatが共有ディレクトリのベストプラクティスとして提案していたようです。）
今回のゴール
デプロイ元の環境で鍵ペアを作る
今回はVCCWを使ったVagrant内のWordMoveを使います。特にWordMoveはrootになって使う必要もないので、今回はvagrantユーザーで鍵を作ります。
|
1 |
$ vagrant ssh |
|
1 2 |
$ ssh-keygen $ less ~/.ssh/id_rsa.pub |
秘密鍵のパスフレーズは必要に応じて設定してください。
ssh-keygenコマンドで鍵ペアが生成されますが、触れていいのは ~/.ssh/id_rsa.pub のように最後にpubが付いたものだけです。これがWordMoveの公開鍵になるので控えておきます。なお、当然ですが ~/.ssh/id_rsa は秘密鍵です。これを漏らしてしまうとデプロイ対象のドキュメントルート以下を丸々書き換えることができてしまうので、十分に気をつけてください。
デプロイ用のユーザーを準備する
ここでは deployer という名前で作成します。
|
1 2 3 4 5 |
sudo useradd deployer # ユーザー追加 sudo -u deployer mkdir -p /home/deployer/.ssh # ディレクトリ作って sudo -u deployer vim /home/deployer/.ssh/authorized_keys # WordMoveの公開鍵を登録 sudo -u deployer chmod 600 /home/deployer/.ssh/authorized_keys # authorized_keysを保護 |
デプロイユーザーが対象のディレクトリに書き込めるようにする
今回のデプロイ対象はウェブサーバーの実行ユーザーが所有しているドキュメントルートです。
今回はnginxを使っており、所有権はnginx:nginxです。戦略としては、nginxのグループにdeployerユーザーを追加し、ドキュメントルート以下のディレクトリに対してグループ内からの書き込み権限を付与します。
|
1 2 3 |
sudo usermod -G nginx deployer # nginxグループにdeployerユーザーを追加 sudo chown nginx:nginx -R /usr/share/nginx # ドキュメントルート以下を再帰的にnginx:nginxに所有権変更 sudo chmod g+w -R /usr/share/nginx # グループに書き込み権限を与える |
これで終わり…なら簡単で、記事にすることもないんですが、2つ問題があります。
deployerでファイルの編集をしてみます。問題なくできます。
|
1 |
sudo -u deployer vim /usr/share/nginx/html/index.php |
次はデプロイ先にないファイルをデプロイしてファイルを作成することを想定してtouchしてみます。
|
1 |
sudo -u deployer touch /usr/share/nginx/html/index-new.php |
次にパーミッションをチェックします。
|
1 2 3 |
$ ls -l /usr/share/nginx/html | grep index -rw-rw-r-- 1 nginx nginx 5 12月 24 04:26 index.php -rw-r--r-- 1 deployer deployer 5 12月 24 04:26 index-new.php |
1つめの問題です。このように、新規でファイルを作成してしまうと所有権は deployer:deployer になってしまいます。deployerグループにnginxを追加してしまう方法もありますが、一貫性が無くなってしまう上に、何かグループに対して権限を付与する際にも複数のグループを気にすることとなり運用コストが高まります。
これを解決する方法として特殊なパーミッションビット、setgidを使います。
setgidを理解する
setgidというのは、setuid, setgid, sticky bit と並んで紹介されることの多いLinux系ファイルシステムにおける特殊なパーミッションビットのことです。今回はsetuidとsticky bitは使わないので省略します。
setgidはset group idの略で、このパーミッションを有効にしたディレクトリ内でファイルやサブディレクトリを作成すると、setgidを付与したディレクトリと同じグループが所有グループとなります。グループを継承することができるということです。
setgidはchmodコマンドで g+s を指定することで設定できます。
|
1 |
sudo chmod g+ws -R /usr/share/nginx # setgidビットフラグを起てる |
|
1 |
sudo -u deployer touch /usr/share/nginx/html/index-new2.php |
チェックしてみます。
|
1 2 3 4 |
$ ls -l /usr/share/nginx/html | grep index -rw-rwSr-- 1 nginx nginx 5 12月 24 04:26 index.php -rw-rwSr-- 1 deployer deployer 5 12月 24 04:26 index-new.php -rw-r--r-- 1 deployer nginx 3 12月 24 09:23 index-new2.php |
デフォルトでグループがnginxに割り当てられています。
今度こそ終わり… と思ったら、新しく作られたファイルのグループはnginxになっていますが、よく見るとグループへの書き込み権限がありません。2つめの問題です。
デフォルトパーミッションを変更する
ここまでで、ファイルやディレクトリを作成したときに所有グループを継承できるようになりました。最後は、デフォルトのパーミッションでグループに書き込み権限を付与することです。これにはumaskを使います。
umaskは許可*しない*ビットを指定する方法なのでかなり柔軟に設定できます。デフォルトではumask 022（＝新規ファイルは644、自分だけ書き込み可）になっていますので、今回はumask 002（＝664、自分とグループの人が書き込み可）に変更したいわけです。
今回はdeployerユーザーにumask 002を付与したいので、deployerユーザーの .bash_profile を利用します。
|
1 |
sudo vim /home/deployer/.bash_profile |
|
1 2 |
# .bash_profile +umask 002 |
テストしてみます。ただし、sudo -u deployerを使うとrootのログインシェルに入ってしまいumask 022が適用されてしまいますので、su – を使います。
|
1 2 |
sudo su - deployer touch /usr/share/nginx/html/index-new3.php |
|
1 2 3 4 5 |
$ ls -l /usr/share/nginx/html | grep index -rw-rwSr-- 1 nginx nginx 5 12月 24 04:26 index.php -rw-rwSr-- 1 deployer deployer 5 12月 24 04:26 index-new.php -rw-r--r-- 1 deployer nginx 3 12月 24 09:23 index-new2.php -rw-rw-r-- 1 deployer nginx 3 12月 24 09:39 index-new3.php |
新規ファイルも664のパーミッションで、グループを継承できました！念のためにサブディレクトリを作って、その中でファイルを作っても同様の結果になることを確認しておきましょう。テストが済んだらテスト用ファイルはすべて消しておきます。
WordMoveでデプロイしてみる
今回はWordMoveを使っていますがWordMoveの紹介ではないので簡単に。実際にdeployerユーザーを使ってデプロイしてみます。
|
1 2 3 |
vagrant ssh cd /vagrant wordmove pull --all |
Pulling Databaseで、サーバー側でmysqldumpが効かなくて一度コケましたがmysqlをyumで入れて解決しました。
|
1 |
wordmove push --themes |
ちゃんとプッシュできていることを確認して終わりです。お疲れ様でした。
雑感
ここまで書いておいて何ですが、本当はこのように役割ごとにユーザーを切り分けるべきだと信じています。ただめちゃくちゃ面倒くさくて、最後デプロイツールでも一工夫必要なことを考えると、同一ユーザーでやってしまいたくなるのもとても分かります。難しいですね。
このエントリを書いているうちにクリスマスイブになりましたね。いよいよ年末ムードですが、今年は年の瀬ギリギリまでお仕事です。クリスマスなんて無かった
前回のエントリの最後でHTTP/2, SPDYやりたいって書いたので有言実行ということで。この記事は既にstable(1.8)なnginxでSSLサイトを構築している環境が前提になります。
一昔前にGoogleが開発した次世代WebプロトコルのSPDYが流行っていましたが、SPDYを受け継いだHTTP/2の出現から、新たにSPDYを導入することはほとんどないようです。
Google自身もHTTP/2へ移行したようですので、今回はSPDYではなくHTTP/2を使ってみようと思います。cssやjs、画像などを多くロードしているページでは、表示速度がかなり向上するようですよ。
nginxでhttp/2を導入する場合は、–with-http_v2_module というパラメータをつけてビルドしないといけません。ただ、nginx公式のリポジトリから落とせるバイナリはこのパラメータ付きでビルドされているようですので、今回はこれを使う方針で進めます。（ちなみにSPDYは古いnginxで利用できていましたが、HTTP/2に載せ替えられる形で使えなくなりました。）
古いnginxの削除
まずは今インストールされているバージョンを確認します。
|
1 2 |
$ nginx -v nginx version: nginx/1.8.0 |
執筆時点のAmazon Linuxで標準のリポジトリからyumでインストールすると、上の通りstableな1.8がインストールされます。nginxは今年の9月末にリリースされたv1.9.5でHTTP/2をサポートするようになったので、1.8.0のnginxは削除します。
|
1 |
$ sudo yum remove nginx |
メインラインnginxをインストール
前述の通り標準のリポジトリからインストールすると1.8が落ちてきてしまいます。メインラインのnginxをインストールするには、公式のドキュメントを参考にnginxのリポジトリを参照するように変更します。
|
1 2 |
$ sudo rpm -ivh http://nginx.org/packages/centos/6/noarch/RPMS/nginx-release-centos-6-0.el6.ngx.noarch.rpm $ sudo vim /etc/yum.repos.d/nginx.repo |
|
1 2 3 4 5 6 7 8 9 |
# nginx.repo [nginx] name=nginx repo -baseurl=http://nginx.org/packages/centos/6/$basearch/ +baseurl=http://nginx.org/packages/mainline/centos/6/$basearch/ gpgcheck=0 enabled=1 +priority=1 |
正しくメインラインのnginxが取得できるか確認し、問題なければインストールします。今回はnginx.repoにpriority=1を追記したので、Amazon標準リポジトリよりnginxリポジトリが優先して参照されます。このほかyumのコマンドに –disablerepo=amzn-main を記述することでもインストール可能ですが、yum updateなどで問題になることがあるので特に理由がなければ優先度を変更しましょう。
|
1 2 3 |
$ sudo yum install nginx $ nginx -v nginx version: nginx/1.9.9 |
すんなりインストールできました。念のために自動起動の設定を確認しておきましょう。
http2の設定
次は1.9.9のnginxでhttp2を使えるようにします。
今回は1.8系のnginxからの乗り換えなので、古いnginxをremoveした時に残っている設定ファイルをベースに書き換えていきます。
|
1 2 |
$ sudo mv /etc/nginx/nginx.conf.rpmsave /etc/nginx/nginx.conf $ sudo vim /etc/nginx/nginx.conf |
|
1 2 3 4 |
server { - listen 443 ssl; + listen 443 ssl http2; } |
SSLは前回設定していますので、書き換えるのはここだけですね。本当に簡単です。
なお、http2はSSLなしでも利用できる仕様ですが、事実上SSL対応しないと使えませんので、SSLに対応していない場合は過去のエントリ「Let’s Encryptをnginxで使ってみる」などをご参考ください。
動作確認する
ちゃんとHTTP/2で通信してくれているかどうかは、Chromeの場合デバッグ機能のnet-internalsを開くことで確認できます。新しいタブで、
chrome://net-internals/#http2
を開いてみてください。
HTTP/2 sessionsのテーブルに、今回対応したドメインが表示されていればうまく動いています。
また、Chrome Extensionの「HTTP/2 and SPDY indicator」もオススメです。これをインストールしておくと、ブラウズしているページがHTTP/2またはSPDYに対応しているかどうかをURLバー右側の雷アイコンで視覚的に表示してくれます。
表示されている雷アイコンが青色であればHTTP/2、緑色であればSPDY、灰色であればこれらのプロトコルに対応していないことを表します。正常に動いているようですね。
雑感
数年前にSPDYで賑わったことは比較的記憶に新しいのですが、暫くその動向を追っていない間にHTTP/2が策定され移行が進んでいるようです。Web技術の変革スピードの早さを再認識しました。時代に取り残されないよう、新しい技術も積極的にキャッチアップしていきたいですね。