Ubuntu 14.04 の tmux を 1.8 から 2.0 にアップデートした

tmux のプラグインを利用しようとしたら tmux のバージョンが古いと怒られた。。。
1.9 にアップデートする手順を探したが、
最新化する方法があったのでそちらで対応

手順

1. 事前準備
   sudo apt-get update
sudo apt-get install -y python-software-properties software-properties-common

2. リポジトリ追加
   sudo add-apt-repository -y ppa:pi-rho/dev

3. リポジトリ最新化
   sudo apt-get update
4. 最新版のインストール ※
   sudo apt-get install -y tmux=2.0-1~ppa1~t
5. バージョン確認
   tmux -V

※　なお 4 の手順は Ubuntu のバージョンによって以下のとおり

# ubuntu 12.04 (Precise Pangolin) 
sudo apt-get install -y tmux=1.9a-1~ppa1~p (installs tmux 1.9, no package for tmux 2.0 yet)

# ubuntu 13.10 (Saucy Salamander) 
sudo apt-get install -y tmux=1.9a-1~ppa1~s (installs tmux 1.9, no package for tmux 2.0 yet)

# ubuntu 14.10 (Utopic Unicorn) 
sudo apt-get install -y tmux=2.0-1~ppa1~u

# ubuntu 15.04 (Vivid Vervet) 
sudo apt-get install -y tmux=2.0-1~ppa1~v

実行結果確認

2.0 にアップデートされた。

$ tmux -V
tmux 2.0

---

Ubuntu Server 実践バイブル 現場で即運用に役立つサービス設定のノウハウ

AWS RDS イベント通知 の カテゴリ について

引き受けたシステムが誰も監視していないツラい状態だった。
広がる無人の荒野にイベント通知を設定した。
んで、イベント通知のカテゴリについて調べたのでまとめ。

RDS の イベント通知カテゴリ

以下のカテゴリが選択できる。

カテゴリ	内容
Availability	インスタンスのシャットダウンや再起動に関する通知
Backup	バックアップの開始、完了通知
Configuration Change	セキュリティグループ、マルチAZ、インスタンスクラス、ストレージやパラメータ等の設定変更に関する通知
Creation	DBインスタンスの作成
Deletion	DBインスタンスの削除
Failover	マルチAZでのフェイルオーバー処理に関する通知
Failure	DBインスタンスに対する異常に関する通知
Maintenance	メンテナンス処理に関する通知
Notification	情報レベルの通知
Read Replica	リードレプリカインスタンスに関する通知
Recovery	復元後の復旧処理に関する通知
Restoration	バックアップやスナップショットからの復元を行った際の通知
Security	AWS CloudHSM というハードウェアアプライアンスに関する通知
Low Storage	ストレージの空き領域がなくなった通知

マルチAZで通常運用している身としては以下辺りを設定しておけばいいかなー。

• Availability
• Configuration Change
• Failover
• Failure
• Maintenance
• Low Storage

Creation、Deletion はあれば余計なインスタンス作られたときの通知とかにいいかなとか思ったが、IAMで制御してるからあんまり必要なさそう。

ちなみに Low Storage は『少なくなったよ～』ではなく『もう無い。マヂムリ』的な通知。 CloudWatch で きちんと監視しておくべき。

ここ 見ればノッてる。

---

情シス・マネジャーのための　早わかりＡＷＳ入門

Ubuntu14.04 の ローカルタイム（timezone）を変更する

何時かな？

$ date
Tue Apr 26 05:10:25 UTC 2016

悲しみ。
サーバ無停止でlocaltimeを日本標準時間JSTに変更する によると、
dpkg-reconfigure で変更できるらしい。

やってみる

環境は Ubuntu 14.04

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.4 LTS"

$ sudo dpkg-reconfigure tzdata

# 画面が表示されるので Asia > Tokyo を選択。

Current default time zone: 'Asia/Tokyo'
Local time is now:      Tue Apr 26 14:11:35 JST 2016.
Universal Time is now:  Tue Apr 26 05:11:35 UTC 2016.

# 確認
$ date
Tue Apr 26 14:11:38 JST 2016

へー。
インタラクティブにやりたくない時は以下で対応できるらしい。
ごちそうさまです。

$ echo "Asia/Tokyo" | sudo tee /etc/timezone
Asia/Tokyo
$ sudo dpkg-reconfigure --frontend noninteractive tzdata

Current default time zone: 'Asia/Tokyo'
Local time is now:      Mon Nov  3 12:46:27 JST 2014.
Universal Time is now:  Mon Nov  3 03:46:27 UTC 2014.

---

小さな会社の新米サーバー/インフラ担当者のためのLinuxの常識

Amazon RDS（MySQL） の error.log や slowquery.log について

Aurora を使いたいのだが、まだまだ MySQL にもお世話になっている。
ログについて確認したのでまとめ。

概要

RDS（MySQL）では以下のログを出力可能。

1. error.log
2. general.log
3. slowquery.log

デフォルトでテーブルに記録されるが ParamaterGroup で設定すればログファイルに記録される。
また、1はデフォルトで出力されており、2,3については ParamaterGroup で設定が必要。

保管場所

• テーブルでもファイルでもRDS のストレージ内

• どちらでも勝手にローテートされる

  • ファイルの場合
    • 1時間ごとにファイルが切り替わる
    • 24時間でローテートされる
    • 容量がストレージの2%を超えている場合、ローテート時に2%以下に収まるように削除されるので注意
  • テーブルの場合
    • ストレージの使用容量によってローテートタイミングが決まる
      • 使用容量 < 90%
        • ログ容量がストレージの 20% を超えた、もしくは ログ容量が10GBを超えたとき
          • 24時間毎にローテート
        • それまでは
          • 蓄積
      • 使用容量 > 90%
        • ログ容量がストレージの 10% を超えた、もしくは ログの合計が5GBを超えたとき
          • 24時間毎にローテート
        • それまでは
          • 蓄積

• あれ？TABLE の方がいいんじゃない？

  • Console、API、CLI からアクセスするにはFILEに出力する必要がある。お好みで。

出力設定

パラメータグループにて以下のパラメータを適宜設定する

パラメータ	設定	デフォルト	説明
slow_query_log	1 or 0	0	slowquery ログを出力する場合、1に設定
general_log	1 or 0	0	general ログを出力する場合、1に設定
long_query_time	0～ （秒数）	10	slowqueryログに出力させる時間を設定
log_queries_not_using_indexes	1 or 0	0	インデックスを使用しないすべてのクエリをスロークエリログに記録する場合、1に設定
log_output	FILE/TABLE/NONE	TABLE	ログの出力先設定

確認方法（ファイルに出力した場合）

1. Amazon RDS Console
2. AWS Cli
3. API、SDK等

AWS RDS Console で確認する

こちらの手順を参照

AWS Cli で確認する

RDS の以下のサブコマンドを利用する

• describe-db-log-files
• download-db-log-file-portion

なお download-db-log-file-portion では 一度に10,000行までしか取得できないので注意。

# まず LogFileName を確認
$ aws rds describe-db-log-files --db-instance-identifier HOGE

#　次に LogFile を表示（1文字づつ出るらしいので jq で加工する）
$ aws rds download-db-log-file-portion --db-instance-identifier HOGE --log-file-name FUGA/PIYO.log | jq -r ".LogFileData | add"

API、SDK

こちらは カッツ…アイ！

ログの閲覧権限

• IAMポリシーで制御可能
  • DescribeDBLogFiles
  • DownloadDBLogFilePortion
  • DownloadCompleteDBLogFile

※ DownloadCompleteDBLogFile がないとダウンロードに失敗した。

---

Amazon Web Services パターン別構築・運用ガイド

RDS の slowquery.log のダウンロードに失敗する（アクセスできません）ので IAM 設定を見なおした

表題の通り。
AWS Management Console から RDS の slowquery.log をダウンロードしようとしたら失敗した。

前提

AWS の RDS で出力させている slowquery.log を取得できるようにIAM アカウントに権限設定を行っていた。

ちなみに設定していたポリシーは以下。

AllowAccessRDSLogFile

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1461207776000",
            "Effect": "Allow",
            "Action": [
                "rds:DescribeDBLogFiles",
                "rds:DownloadDBLogFilePortion"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

なぜだ。
AWS系でよく見るあのブログ会社の記事でも、DescribeDBLogFiles と DownloadDBLogFilePortion を設定してね♡
とかあるんだけどなー

　事象

動作確認してみるとログファイルの表示はできるのだが、ダウンロードに失敗する。。。
リンクは表示されるが取得すると『アクセスできません』と表示されダウンロードに失敗する。

対応

ポリシーに以下を追加したらダウンロードできるようになった。

• DownloadCompleteDBLogFile

AllowAccessRDSLogFile（修正版）

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1461207776000",
            "Effect": "Allow",
            "Action": [
                "rds:DescribeDBLogFiles",
                "rds:DownloadDBLogFilePortion",
                "rds:DownloadCompleteDBLogFile"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

ログファイルがでかすぎるのが問題なのかなー？

---

Amazon Web Services パターン別構築・運用ガイド

AWS の利用料金のカード決済に失敗していた

リザーブドを大量に一括購入したら限度額超えていたらしく。
決済失敗のメールがとどいた。

Problems with your AWS Account - Please read urgently

Dear Amazon Web Services Customer,

There was a problem with your account xxxxxxxx. 
We were unable to charge your credit card for the amount of $xxxx.xx for your use of AWS services during the month of xxx-20xx. 
We will attempt to collect this amount again. 
Unless we are successful in collecting the balance of $xxxx.xx in full by xx/xx/20xx, your Amazon Web Services account may be suspended or terminated.

会社カードを限度額高いものに変えてもらったが、your Amazon Web Services account may be suspended or terminated. とか言われるとやらかしたらコワイ。 再支払いがどうなるか気になったので確認した。

Q. クレジットカードの支払（決済）に失敗した場合、どうしたら良いですか？

自動で再決済が行わるらしい。 ただ注意書きがあった。

※リザーブドインスタンスの前払い金など一部お客様にて再決済を実施いただけないものもあります。

( Д ) ﾟ ﾟ

※リザーブドインスタンスの前払い金など一部お客様にて再決済を実施いただけないものもあります。！！！

支払履歴画面から再決済をお願いした。
ご迷惑おかけしました。

なお2016年4月現在の情報です。参考にする場合はお気をつけ下さい。

Ubuntu14.04 に mysql 5.6 を再インストールした

ふとしたことから mysql を破壊してしまったので再インストールした。 今更ではあるが 5.6 をインストールしたかったので、その記録

OS

環境は以下

$ cat /etc/os-release
NAME="Ubuntu"
VERSION="14.04.3 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.3 LTS"
VERSION_ID="14.04"
（略）

アンインストール

プロセスが上がっていないことを確認
（上がってこなくなっていたのでそもそもないんだけど(´Д⊂ｸﾞｽﾝ）

$ ps auxf | grep mysql

あがっていれば止める。パッケージを削除

sudo apt-get remove --purge mysql-server* mysql-common
sudo apt-get autoremove --purge

/var/lib/mysql が残るとか /etc/mysql が残るという記事をよく見かけたが
purge 効果か、自分の場合どちらのディレクトリも削除されていた。
削除後、一応再起動させた。

再インストール

APT リポジトリ設定用のパッケージ取得

MySQL のサイトの APT Repository 画面 から APT リポジトリ設定用のパッケージを取得してくる。
（2016年4月時点で最新は mysql-apt-config_0.6.0-1_all.deb ）

$ wget http://dev.mysql.com/get/mysql-apt-config_0.6.0-1_all.deb

パッケージインストール

$ sudo dpkg -i mysql-apt-config_0.6.0-1_all.deb

設定画面が表示される。
MySQL Server（mysql-5.7） => mysql-5.6 => Apply => OK と選択

リポジトリを更新

$ sudo apt-get update

インストール

$ sudo apt-get install mysql-server

バージョン確認

$ mysql --version
mysql  Ver 14.14 Distrib 5.6.29, for Linux (x86_64) using  EditLine wrapper

綺麗になってスッキリポン！

MySQL全機能バイブル ~現場で役立つAtoZ~