EC2 で新しいインスタンスを立ち上げたが root でログインできない

EC2 で、Community Instance を使い、新しいSecurity Group と Key Pair を作って起動したのだが、秘密鍵を指定して root でログインしようとすると、まずは root 以外でログインしてください、というメッセージが出てログインできませんでした。

いろいろと調べた結果、作成した秘密鍵で ec2-user というユーザ名でログインできました。

ログイン後に
sudo su
とすれば root になれるので、そこで root のパスワード設定など必要な処理を行いました。

ec2-user というユーザ名は AMI によって違うかもしれませんが、迷ったので備忘録として書きました。

 

MySQLで月別にユニークユーザ数を出すSQL

MySQL のデータの中から月別に○○の数を出す、という集計は良くあるのですが、いつも書き方を忘れてしまうので、例を挙げておきます。

例えば販売データが purchase というテーブルに入っていて、購入者の ID が user_id カラムに、購入日が created_at カラムに格納されているとすると、月別の購入者数は

SELECT DATE_FORMAT(created_at, ‘%Y-%m’) as reg_time,COUNT(DISTINCT user_id) FROM purchase GROUP BY reg_time ;

というSQLで集計できます。

これを使えば、アクセスしたマンスリーユニークユーザ数などを集計することができます。

日別への応用は簡単です、DATE_FORMAT の部分を以下のようにすれば日別になります。

SELECT DATE_FORMAT(created_at, ‘%Y-%m-%d’) as reg_time,COUNT(DISTINCT user_id) FROM purchase GROUP BY reg_time ;

 

414 Request-URI too large が出るようになった

iOS アプリからパラメタ付き GET で WEB サーバにリクエストを投げていたら以下のエラーが出るようになった。

414 Request-URI too large

 

どうやらパラメタが長すぎて URI の長さ制限にひっかかってしまったようです。

デフォルトの長さ制限は 8190 バイトのようですので、これ以上長いと414 エラーとなってしまうようです。

まぁ、そんなに長いパラメタを GET で送るなよ、ということだとは思いますが、アプリを修正するのは時間がかかるので、とりあえず長さ制限の値を変更すれば、アプリを修正するまでの期間はしのげます。

制限の修正は Apache の conf ファイルに以下の行を追加(すでにLimitRequestLine の行がある場合は修正)することで行います。

LimitRequestLine 65536

行を追加したら Apache を再起動して完了です。

上記の例の場合は、65536 バイトに設定していますが、大きすぎないように必要なバイト数だけ指定するのが良いと思います。

そしてそもそもですが、リクエストを GET ではなく POST で送るように修正して、この値はデフォルトに戻せるようにしたほうが、「本来の姿」であると思いますので、まずはリクエストを POST にできないか検討してみたほうが良いと思います。

 

GIMP で画像を回転すると枠からはみ出してしまう場合の対処

GIMP を使って画像を回転させると枠からはみ出してしまう場合があります。

そんなときに回転した画像がすべて見えるようにする対処法を紹介します。

 

gimp002

まずは回転作業です。縦長の画像を45度ぐらい回転させてみます。

 

gimp003

回転後はこんな感じで一部しか見えなくなってしまいます。

 

gimp004

そんなときは、メニューの [画像]-[キャンバスをレイヤーに合わせる] を選択してみます。

 

gimp005

無事に回転した画像がすべて見られるようになりました。

 

Google Analytics で複数のサブドメインのアクセスを集計する

Google Analytics はウェブサイトのアクセスを解析するためには無くてはならないツールです。

ベースとしてはドメイン毎にアカウントを作成して集計するような形ですが、サブドメインもまとめて集計できる機能もあります。

例えば example.com というドメインと blog.example.com , news.example.com などをまとめて解析するということもできます。

以下はその方法です。

サブドメインの設定手順

サブドメインを設定する場合は、Google Analytics の管理画面で取得したトラッキング コード(HTMLに書き込むアクセス解析用のコード)を編集してからHTMLに書き込みます。

取得したトラッキングコードに以下のような二行があると思います。

ga(‘create’, ‘UA-XXXXXXXX-1′, ‘auto’);
ga(‘send’, ‘pageview’);

これを以下のように変更します。

ga(‘create’, ‘UA-XXXXXXXX-1′, ‘auto’, {‘allowLinker': true});
ga(‘require’, ‘linker’);
ga(‘linker:autoLink’, [‘example.com’] );
ga(‘send’, ‘pageview’);

*XXXXXXXX と example.com の部分は自分のIDとドメインを入れてください。

変更したコード(<script>から</script>まで)をサイトのHTML内の</head>の上に貼り付ければ、取得設定は完了です。

 

ビューの設定

サブドメインもまとめてアクセス集計する設定にすると、Google Analytics 上ではひとつの場所にアクセス集計されます。

そうすると、例えば http://news.example.com/ のアクセスも http://blog.example.com/ のアクセスも同じ / として記録されます。

つまり、http://news.example.com/ に一回、http://blog.example.com/ に一回アクセスした場合、Google Analytics 上では / に二回アクセスがあった、という具合に表示されます。

これでは都合が悪い場合があるので、サブドメインごとにアクセスが表示されるようにビューの追加を以下の手順で行います。

  1. アナリティクス設定のビューのプルダウンメニューの[新しいビューの作成] を選択します
  2. レポート ビュー名を入力します(例:blog.example.com)
  3. [ビューを作成] をクリックします
  4. [フィルタ] をクリックします
  5. [新しいフィルタ]をクリックします
  6. フィルタ名を入力します(例:blog.example.com)
  7. フィルタの種類の欄で[右のみを含む][ホスト名へのトラフィック][等しい]を選択し、ホスト名の欄にサブドメイン名を入力します
  8. [保存]をクリックします

以上で指定したサブドメインのアクセスだけを集計できるビューが表示できるようになります。

 

WordPress に W3 Total Cache プラグインを入れたら http ログにエラーが出るようになった

サブドメインでマルチサイトを運用するという環境で W3 Total Cache プラグインをインストールして実行したところ以下のようなエラーが httpd のエラーログに出力されるようになりました。

[error] WordPress データベースエラー: Table ‘xxxxxx.wp_2_w3tc_cdn_queue’ doesn’t exist for query SELECT remote_path FROM wp_2_w3tc_cdn_queue WHERE remote_path = ‘wp-includes/js/jquery/jquery-migrate.min.js’ made by shutdown_action_hook, do_action(‘shutdown’), call_user_func_array, wp_ob_end_flush_all, ob_end_flush, W3_Plugin_TotalCache->ob_callback, w3tc_do_ob_callbacks, call_user_func, W3_Plugin_Cdn->ob_callback, preg_replace_callback, W3_Plugin_Cdn->link_replace_callback, W3_Plugin_Cdn->_link_replace_callback_checks

読んで字のごとく、DB に wp_2_w3tc_cdn_queue というテーブルが無いことが原因のようです。
このテーブルはサブドメインごと(サイトごと)に作成される想定のようで、二番目のサイトだと wp_2_w3tc_cdn_queue 、三番目のサイトだと wp_3_w3tc_cdn_queue と数字が変わっていくようです。

DB のテーブルを見てみると数字無しの wp_w3tc_cdn_queue というテーブルは作成されていましたが、数字のついた各サイト用のテーブルが作成されていないようでした。

とりあえず、wp_w3tc_cdn_queue テーブルと同じ内容で各サイト用のテーブルを DB に作成して実行してみたところ、エラーは発生しなくなりました。
動作もとりあえず今のところは問題ありません。

しかし、この対策で良いのかどうかは不明です。。。


AWS EBSボリュームの容量が実容量よりも小さく表示される

EC2でマーケットプレイスにあるインスタンスイメージを起動するときにEBSのサイズを10GB から 20GB に変更して起動したのだが、起動した後に df コマンドで見てみるとサイズが10GB のままになっていました。

でも EBSの設定をみると 20GB になっているので料金は 20GB 分取られているわけです。

そんなときは、df コマンドで確認したデバイス名に対して以下のコマンドを実行して、容量がフルに使えるようにします。

# resize2fs /dev/xvda1

* /dev/xvda1 の部分は自分の環境に合わせた名前にしてください。

# df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/xvda1      20642428 1335708  18258272   7% /
none              302208       0    302208   0% /dev/shm

以上で無事 20GB が使えるようになりました。

 

AWS EC2 インスタンスタイプの変更手順

EC2で運用しているサーバの負荷が減ってきたのでインスタンスタイプを変更してコスト削減を図ることにしました。

以下の手順はEBSインスタンスの場合の手順です。

EBSインスタンスかどうかを知るにはAWSマネジメントコンソールでEC2のインスタンスを選択し、Description のところのRoot device type が ebs になっているかどうかを見ます。

EBSであれば以下の手順でインスタンスタイプを変更できます。

  1. AWSマネジメントコンソールで対象となるEC2のインスタンスを選択
  2. Actions -> Stop を選択し、インスタンスを停止
  3. Instance State が Stopped の状態になったら Actions -> Change Instance Type を選択し、変更したいInstance Type を選んで Apply をクリック
  4. Actions -> Start を選択し、インスタンスを起動
  5. Instance State が Running の状態になったら、Elastic IP をインスタンスに関連付ける(Elastic IPを使用している場合のみ)