SSH経由でのロケール転送のワナ

admin linux

何を切り口に書いたらいいのか悩むところですが、system-config-firewall-tuiが起動できないというトラブルを巡るメモです。野暮用でEC2以外のLinux環境が必要になり、さくらのVPSを契約したのですが、軽くロックダウンしようとしてiptablesを設定しようとしたら、思わぬところで時間をとられてしまいました。


Mac OSからSSHでログインしてsystem-config-firewall-tuiを起動すると

# system-config-firewall-tui
Traceback (most recent call last):
  File "/usr/bin/system-config-firewall-tui", line 28, in <module>
    import fw_config
  File "/usr/share/system-config-firewall/fw_config.py", line 22, in <module>
    locale.setlocale(locale.LC_ALL, "")
  File "/usr/lib64/python2.6/locale.py", line 513, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

というエラーで起動できない。試しにVNCコンソールから試してみると問題ない・・・。


SSH経由のセッションとVNC経由とで環境変数を比較すると、

LC_CTYPE=UTF-8

となっていて、SSHだけLC_CTYPEがセットされている。ためしに"UTF-8"をクリアするとSSH経由でもsystem-config-tuiを起動できる。


このLC_CTYPEは、SSH経由でローカルから渡されてしまっているので、ssh_configの中で該当する行をコメントアウトするとSSH経由でもLC_CTYPEがリモートに渡らなくなり、system-config-tuiの起動も問題なくなった。（自分としては、日本語でトラブルになるよりは、リモートがデフォルトで英語にフォールバックするのは、むしろ好ましいかも。）

% vim /etc/ssh_config
（略）
Host *
#SendEnv LANG LC_*
（略）


ちなみに、iTermで文字コードを"Unicode (UTF-8)"ではなく"Japanese (Max OS)"に設定すると、LC_CTYPEはセットされない。Terminal.appでは、"Unicode (UTF-8)"でも"Japanese (Max OS)"でも、LC_CTYPEがセットされる。このあたりの設定情報は解決すべきトラブルがないと調査する気力が湧かない。

任意のHTTPステータスコードを任意の時間で返す

admin web

ロードバランサーなどの実験をしていると、バックエンドのweb/appサーバーから任意の時間で任意のステータスコードを返したくなることがあります。Apcheの挙動との一致を気にしたりしないという前提で、Sinatraで書くと非常にシンプルです。

プログラム

#web_test.rb
require 'sinatra'
get '/:code/:timeout' do
  status params[:code]
  sleep params[:timeout].to_f
  body "Status #{params[:code]}\n Timeout #{params[:timeout]}"
end

設置〜実行方法

Amazon Linux (Redhat Enterprise Linux, CentOS互換）の場合です。

#yum install rubygems
#gem install sinatra
#vim webtest.rb
#ruby -rubygems web_test.rb
[2012-04-25 06:08:02] INFO  WEBrick 1.3.1
[2012-04-25 06:08:02] INFO  ruby 1.8.7 (2011-12-28) [x86_64-linux]
== Sinatra/1.3.2 has taken the stage on 4567 for development with backup from WEBrick
[2012-04-25 06:08:02] INFO  WEBrick::HTTPServer#start: pid=1906 port=4567

デフォルトではポート番号4567が使用されるので、80番などを使いたい場合は、

#ruby -rubygems web_test.rb -p 80

などとしてください。

使用例

5秒後に400 Bad Requestを返す。
$ time wget localhost:4567/400/5
--2012-04-25 05:53:28--  http://localhost:4567/400/5
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:4567... connected.
HTTP request sent, awaiting response... 400 Bad Request
2012-04-25 05:53:33 ERROR 400: Bad Request.

real	0m5.011s
user	0m0.002s
sys	0m0.005s
1.35秒後に500 Internal Server Errorを返す。
$ time wget localhost:4567/500/1.35 
--2012-04-25 06:05:29--  http://localhost:4567/500/1.35
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:4567... connected.
HTTP request sent, awaiting response... 500 Internal Server Error
2012-04-25 06:05:30 ERROR 500: Internal Server Error.

real	0m1.361s
user	0m0.003s
sys	0m0.003s

小数点2桁目ぐらいからは怪しいですが、数秒の精度であれば任意のステータスコードを任意の時間が経過した時刻で返すことができます。

これぞ3分クッキング・・・。

Amazon Linuxのリリースノート

admin AWS

小咄をひとつ。

野暮用でEC2インスタンス上で最新Amazon Linux（2012.03）のリリースノートを見ようと思って、記憶を頼りに/usr/share/doc/system-release/を見てもGPLライセンスの文書しか入っていませんでした。

起動時のバナーにリリースノートの置き場が書いてあったことを思い出してmotdを見ると、web上のURLが書かれていました。記憶違いかと思って古いインスタンス上でmotdを見てみると、ローカル・ファイルシステムのpathが書いてある。調べて見ると、直近にyum updateをかけたタイミングでmotdファイルが書き換わっていました。

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

See /usr/share/doc/system-release/ for latest release notes.

　↓　↓　↓

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2012.03-release-notes/

この変更について少し理由を考えてみて、ふと、これは不要データを削減する取り組みなのかもしれないと思い至りました。

EC2の規模については、「全世界でxxx万台」などなど、web上でも様々な憶測が流れていますが、とにかくEC2は「莫大な数」のインスタンスを日々走らせています。リリースノート1ファイル単独ではわずかであっても、Amazonが標準で提供するAMIのデータ量を削り込むことで、AWS全体で消費されるストレージや帯域を減らすことができそうです。

たしか、id:naoya氏の「大規模サービス技術入門（asin:4774143073）」という書籍だったか、1000台程度までの大規模サービスと、100万台以上の規模の「超」大規模サービスとでは、インフラに関する考え方もノウハウも異なってくるということが書いてあって、なるほどと思った記憶があります。リリースノートをローカルから削除したことは「今時はwebに掲載していれば十分なはず」という程度の理由かもしれませんが、ひょっとすると、こういったレベルでAMIをシェイプアップしていくというのは超大規模だからこそ意味のあることなのかもしれないと感じた次第です。（EC2チームの真意を確認したわけではありません。）

ちなみにmotdはsetupパッケージに含まれています。

# rpm -qif /etc/motd
Name        : setup                        Relocations: (not relocatable)
Version     : 2.8.14                            Vendor: Amazon.com
Release     : 13.9.amzn1                    Build Date: Fri Jan  6 09:41:43 2012
Install Date: Sat Mar 24 16:57:48 2012         Build Host: build-31003.build
Group       : System Environment/Base       Source RPM: setup-2.8.14-13.9.amzn1.src.rpm
Size        : 665338                           License: Public Domain
Signature   : RSA/8, Fri Feb 17 18:17:51 2012, Key ID bcb4a85b21c0f39f
Packager    : Amazon.com, Inc. <http://aws.amazon.com>
URL         : https://fedorahosted.org/setup/
Summary     : A set of system configuration and setup files
Description :
The setup package contains a set of important system configuration and
setup files, such as passwd, group, and profile.

[Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ)

[Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ)

5年後

life

学生時代に研究室のwebmasterをやっていたとき、「一大事業」として力を入れたのが、イントラ・サイトのwiki化でした。HTMLファイルがバラバラに配置されていて、更新するだけでも一苦労という仕組みになっていたイントラ・サイトを、pukiwikiを骨組みとした動的なサイトに作り替えて、情報を見つけやすく、更新するのも楽なサイトに作り変えました。

設計と移行手順を考えるのにも一苦労でしたが、コンテンツの移動に至っては、ひたすらコピペと整形を繰り返すだけの地味な移行作業でしたが、実際に移行が完了したあとも周囲の反応がよくわからず、正直なところ自分として正しいことをしたのかどうか自信がありませんでした。大切な時期に時間を無駄にしてしまったとすら思っていました。

それが、先日、ちょっとした機会に研究室の仲間と集まって酒を飲む機会があったときに、お前がやったwiki化は英断であったと言ってくれるメンバーがいたのです。5年も前の作業について自分が担当したことを覚えていてもらえているのも不思議でしたし、所詮は酒の席での話とはいえ、肯定的に評価してもらえるなど思ってもいなかったので、不意を突かれてつい嬉しくなってしまいました。

もっとも、褒められて嬉しかったというだけだったら、その場でニヤニヤして終わりという話に過ぎないのですが、わざわざblogにしたためているのは、リップサービスであっても、そんなことを口に出して言ってくれる人間が身近にいたのに、当の本人は自分の行動を半ば否定的に捉えていたという構図が、実におもしろく思えたからです。（きっと逆パターンもありうるでしょうが、そちらは「知らぬが仏」で済ませたい。）


先日、同僚（と呼ぶには身分が違いすぎるのだが）のAさんのblogのくつろいだ雰囲気を見て、つい自分も久々にblogという形で何かを書きたくなりました。これはこれで、久々に感じる不思議な気持ちをおもしろく思いました。


話は変わって、今日は仕事帰りに散髪に行きました。今の業務は24時間待機の仕事なので、バックアップ・スタッフの少ない週末に行く替りに、思い切って平日に行ってしまうことにしました。店は空いていて、その上平日特別料金で切ってもらえるし、色々と悪くなかったので、これからも髪を切るのは平日にしようと思いました。

日本語Windows AMI非公式イメージキャラクター まどか（案）

AWS

秋のお楽しみ企画第二弾。「りな○ん」の次は日本語Windows AMIをイメージした「まどか」です。

AWSは英語ばかりと思われがちですが、日本語環境で使うこともできます！

前作よりも画風が若干変わりましたね・・・。

まどか
まどか


まどか（下書き）
下書き


重要なお知らせ：本ブログの著者が描いたものではありません。

Amazon Linux非公式イメージキャラクター（案）りな○ん

AWS

本邦初公開、Amazon Linuxの非公式イメージキャラクター「りな○ん」です。

若干ゆがんでますが、素人が描いてるのでお許し下さい。

りな○ん
りな○ん


りな○ん（下書き）
下書き


重要なお知らせ：本ブログの著者が描いたものではありません。

Elastic Beanstalk本を読んだ

admin AWS

8月にO'ReillyからAWS Elastic Beanstalkの解説本（英語）が出版されていたので読んでみました。まだまだ誰もが知る製品とはいえないBeanstalkですが、すでに紙の本が出版されて本屋に並んでいるあたりに、米国においてAWSが完全な市民権を得ている雰囲気を感じます。

Elastic Beanstalkは、ごくごく簡単に言えば、アプリケーションをAWSの様々なリソース上に素早くdeployするためのプロダクトです。現在はコンテナとして用意されているのはTomcatのみですが、今後はJava以外の言語も含めて、複数の環境がサポートされていくようです。詳しくは、AWS公式ブログの記事が参考になると思います：

Elastic Beanstalk - O'Reilly

Elastic Beanstalk: Simple Cloud Scaling for Java Developers

Elastic Beanstalk: Simple Cloud Scaling for Java Developers

著者はProgramming Amazon EC2: Survive your Successと同じJurg van Vliet氏と Flavia Paganelli氏を含めた4名の方で、AWS Solution Providerの9apps（オランダ）のエンジニアの皆さんです。

この本は50ページしかないのですが、Elastic Beanstalkの解説に加えて、実際にURL短縮ツールをBeanstalkを使ってAWS上にdeployする例が紹介されてます。Beanstalkでは、Auto Scalingによって自動的にEC2インスタンスが起動・停止されるので、ローカルにデータを保存するというアプローチは取れないわけですが、そのためにどのようなアーキテクチャをとるべきかといった点も簡単に説明されています。Hudsonを使ってCIの環境を構築している点など、実務的な視点が貫かれているのが特徴だと感じました。

AWS tips

AWSのwebサイトなどに明示的に書かれていない内容で、執筆陣が経験的に学んだAWS利用上のtip（コツ）的な内容も有意義だと感じました。アベイラビリティ・ゾーンを複数利用することが可用性向上に極めて重要であり、EC2障害時に有効に機能する方策であることなどもしっかり書かれています（p.19）。

Beanstalk固有の話題ばかりではないですが、3箇所ほど印象的な部分を引用すると・・・

There is an EBS volume and ephemeral storage. Both are unreliable for storage that needs to be persisted. (p.4)

参考訳：EBSとephemeral storageがあるが、どちらもストレージとして十分な信頼性があるわけではないので（S3にスナップショットをとったり、DBに記録するなどの方法で）永続化する必要がある。

EBSのスナップショットはS3に保存されるので、スナップショットまでとっておけば、相当安心できますねー。

Elastic Beanstalk is not a PaaS. You can forget about servers for a while, but if you are not happy with them, you can take control. (p.17)

参考訳：BeanstalkはPaaSではない。しばらくは個別のサーバーについて考えなくて済むが、もし都合が悪いことがあれば細かく制御することができる。

AWS公式ブログにも書かれていますが、必要に応じてサーバー単位でトラブルシュートを行ったり、ロードバランサーの設定を変更したりといったことが可能であったり、Elastic Beanstalkは、いわゆるPaaSとは毛色の違うサービスなのですが、案外メッセージが伝え切れていないのかな、と思うこともあります。

It is important to realize that the command-line tools always implement 100% of the available features. The Console does not. (p.20)

参考訳：コマンドラインツールは100%の機能を常に網羅している一方で、マネージメント・コンソールは必ずしもそうではない。

スクリプトで自動化したりする上で、実際にはコマンドラインツールが有用な局面も多いのですが、一部の操作についてはコマンドラインツールを使わないと行けないという現実があります。GUIで100%の機能が網羅されているとさらに良いですね。

Hacking Elastic Beanstalk

本書の第4章は"Hacking Elastic Beanstalk"と題されていて、Beanstalkの応用的な話題として、Apache httpdをNginxに置き換えたり、OpenJDKをSun JDKに置き換えたりといった内容が触れられてます。

まとめ

ページ数の割に少々値段が張りますが、Beanstalkの解説として記念碑的な本ですし、EC2などについても学べる内容が大ですので、Beanstalkに興味があれば読んでみて損はないと感じました。

この記事のリンクはAmazon.co.jpのアフィリエイトになってますが、Amazon.com（米国）だと$9.99でKindle版を購入できます。円高のおかげで、今なら800円未満です。また、O'Reillyのオンラインサイトからは、$16.99ですが、DRMフリーなePub, Mobi, PDFの電子ファイル形式で購入することも可能です。