最近、EC2+Amazon Linuxしか使っておらず、「あとはchef-soloコマンドを叩くだけ」みたいな状態のAMIを作っておけばめちゃくちゃ便利じゃないかと思い、chef-soloのレシピを書き始めた。今shellでやっているセットアップ作業を全部移すつもりなのでとりあえず入門として以下を試してみる。
サーバーの準備
ssh関連の設定をしつつ、以下を実行。
# パッケージ準備
sudo yum -y update
sudo yum -y groupinstall "Development tools"
sudo yum install -y gcc-c++ patch readline readline-devel zlib zlib-devel libyaml-devel libffi-devel openssl-devel git rubygems
# rubyインストール
sudo git clone git://github.com/sstephenson/ruby-build.git /usr/local/src/ruby-build
cd /usr/local/src/ruby-build/
sudo ./install.sh
sudo /usr/local/bin/ruby-build 1.9.3-p125 /opt/rubies/1.9.3-p125
# chefインストール
sudo /opt/rubies/1.9.3-p125/bin/gem install chef --no-ri --no-rdoc
以下の作業を楽にするため、一時的にPATHを通しておく。
export PATH=/opt/rubies/1.9.3-p125/bin:$PATH
リポジトリの準備
chefリポジトリのひな形を準備
git clone git://github.com/opscode/chef-repo.git
cd chef-repo
mkdir .chef
chef-solo用の設定ファイル
# .chef/solo.rb
file_cache_path "/tmp/chef-solo"
cookbook_path "./cookbooks"
実行するレシピを定義
.chef/chef.json
{
"run_list": [ "recipe[init]" ]
}
とりあえず、screenとzshをインストールするレシピを作ってみる。
レシピの作成はknifeコマンドで。
knife cookbook create init
出来上がったレシピに作業を書き加えてゆく。
# cookbooks/init/recipes/default.rb
%w(screen zsh).each do |name|
package name do
action :install
end
end
実行してみる。
sudo chef-solo -c .chef/solo.rb -j .chef/chef.json
すると、めでたくscreenとzshがインストールされた。
昨今のクラウドなサーバーインスタンスを使ってると、物理サーバーがどんなスペックなのか興味本位で知りたくなることがある。また、例えばNginxのworkerの数をコア数に合わせたい時などにはこのコマンドが重宝する。
cat /proc/cpuinfo
出力はこんな感じ。
processor : 0 # 物理プロセッサ番号
vendor_id : GenuineIntel # ベンダー
cpu family : 6 # ファミリー番号
model : 23 # モデル番号
model name : Intel(R) Xeon(R) CPU E3110 @ 3.00GHz # モデル名
stepping : 10 # 生産ロット番号のようなもの
cpu MHz : 2000.000 # 動作周波数
cache size : 6144 KB # キャッシュサイズ
physical id : 0 # 物理プロセッサID
siblings : 2 # プロセッサあたり物理コア数
core id : 0 # コアID
cpu cores : 2 # コア数
apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
bogomips : 5985.14
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU E3110 @ 3.00GHz
stepping : 10
cpu MHz : 2000.000
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
bogomips : 5984.20
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
この場合、2コアの物理プロセッサが1個刺さってることになる。
コア数は2つなので、Nginxのworkerも2つか3つで十分。
EC2の各regionで使えるofficialなUbuntu AMIのインスタンスでは、デフォルトでは日本時間に設定されていない。当然だけど。
us-westなら西海岸、us-eastなら東海岸とregionの物理的な位置に合わせてtimezoneが設定されているかどうかは未確認だけど、これは単純にTimezoneの設定の問題なので、下記のようにすればよい。
$ sudo dpkg-reconfigure tzdata
こうするとTimezoneの設定画面が出てくるので、Asia/Tokyoの順に選択してあげればよい。
同じ問題におけるRHEL系の解決方法として
$ cp /usr/share/zoneinfo/Japan /etc/localtime
っていうのが紹介されてるけど、Ubuntuの場合これをやっても再起動すると元に戻ってしまうのでやっぱり上記の方法の方がいいです。
Linux向けアンチウィルスソフトの定番であるClamAVを使ってると起こる問題について、簡単な対策をメモ。
大した負荷がかかるはずのないサーバーからload averageに関するalertが来て、topコマンドでチェックしてみたら大量のclamscanで埋め尽くされていたことはありませんか？
ClamAVでウィルススキャンを行うコマンドclamscanを、cron.dailyなどの比較的短いスパンでバッチ処理している場合、前回のclamscanが完了する前に新しいclamscanが実行されてしまうことがあります。
特に、ルートディレクトリ以下の全てを検索対象にしていたりすると、スキャンの時間は限りなく長くなるので要注意です。
この現象が発生すると、雪だるま式にclamscanのプロセスが増えていきサーバーリソースを圧迫し、load averageのalertを打ちまくってくるのです。
対策としては、
- スキャン対象のディレクトリを絞り込む
- cronの実行スパンを長くとる
を組み合わせていけばいいと思います。
スキャン対象のディレクトリを絞り込む
clamscanには—excludeというオプションがあるので、それを直接設定することができます。
アンチウィルスソフト導入(Clam AntiVirus) - CentOSで自宅サーバー構築で解説されているような定期実行スクリプトを作っておくと使いまわしも出来て便利なのでお勧めです。
cronの実行スパンを長くとる
これは、単純にcron.dailyからcron.weeklyに移したり、crontabコマンドで実行スパンを設定しなおすなどの方法があります。
cronの設定ガイド
終わり
Linuxを狙ったウィルスは、windowsと比べるとはるかに数が少なく、ウィルス対策なんて必要ないと思われるかもしれません。
ただ、未知の脆弱性を突いてウィルスが入り込む可能性は決してゼロではないので、アンチウィルスソフトを完全に切ってしまうのは少々不安が残ります。
特に、ClamAVはpostfixと連携したメールのウィルスチェックなど色々なことが出来るので、load averageのalertにウンザリして切ってしまう前にいろいろと試してみるのもアリかと思います。
簡単なのにすぐ忘れるランキング上位に君臨するスニペットだと思う。
#!/bin/sh
DATE=`date +%Y%m%d`
echo "test" > test_$DATE.txt
今日は以下のように間違えた。
DATE=`date +%Y%m%d` # 正解
DATE=`date %Y%m%d` # 間違い
