つっこみ大歓迎

nginx

[雑記] nginx の proxy_set_header の扱い

proxy_set_header の動きがちょっとおかしいなと思ったのでメモ。 * バージョン * nginx 1.2.6 リバースプロキシを使う際、下記のような感じで、お決まりの proxy_set_header を http コンテキストで設定しておくと思います。 http { proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Real-IP
1 min read
Network

NSD 4.0.0b1 のゾーンの動的追加・削除を試す

NSD 3 系で悩みだったのが、ゾーンの追加・削除の際に、デーモンをリスタートしないといけない事でした。 僕の会社のコンテンツサーバは、結構な頻度でゾーンの追加・削除があるので、NSD に乗り換え候補にあげつつも、ちょっとなーなんて思っていた所、、、 NSD 4.0.0b1 がリリースされました。 [nsd-users] NSD 4.0.0b1 beta The zone handling allows to addition and removal of zones on the fly. との通り、ゾーンの追加・削除が動的にできるようになったとの事で、さっそく試して見ました。 * 環境 * CentOS 6.2 x86_64 インストールから起動まで NSD3 系と同じ手順でインストールできました。 ビルド・
2 min read
Diary

トラブル☆しゅーたーず 03 に参加してきた #トラしゅ

8/4 に、トラブル☆しゅーたーず #03 にお邪魔してきました。 いつもと同じく 5-6 名のチームに別れ、障害対応・報告書作成を行いました。 障害の内容は、 * オークションサイトに表示される画像と内容がずれている。 * レンスポンスが遅い。 というものでした。 #01、#02 ともに参加させていただいていたので、ある程度段取りとか時間の感覚が分かっている面もあるのですが、原因の究明に悩んでいると、あっという間に時間がすぎるものですね…。 トラブル☆しゅーたーず＃０３読本 - Google Docs 僕はチーム 1 でした。 チーム 1 の報告書はこちら。 トラしゅ#3 チーム1　障害報告書 - Google Docs 僕達のチームの良かった点 * 役割分担ができた。 * みんなを仕切ってくれる方がいた。 僕達のチームの悪かった点 * 中間報告・最終報告ともに期限の時間より遅れてしまった。 自分的に良かった点 * 重要な作業の時刻の記録ができた。 * 前回までに学んだ、
2 min read
Ruby

[Ruby] スレッド数固定で処理を行う

お仕事で、数百台のサーバに対して、多少時間のかかる処理をする必要があった。 1 つずつ実行していては、さすがに日が暮れてしまう。 そうなるとスレッドで並列実行したいが、対象のサーバの分、数百個スレッドを生成すると逆に重くなってしまう。 というわけで、スレッド数に上限を設けて実行した、という話。 雛形はこんな感じ。 #!/usr/bin/ruby -Ku # -*- coding: utf-8 -*- # # 20120619 # thread template # require 'thread' def job(arg) sleep rand(0) print "#{arg}\n" end def main # スレッド数上限 thread_max = 3 # キュー jobqueue
1 min read
Diary

#qpstudy 2012.05 に参加してきた

05/19 に、qpstudy 2012.05 [http://www.zusaar.com/event/272009] に参加してきました。 内容は、「エンジニアのためのハードウェア徹底入門」というものでした。 一週間たってしまいましたが、ブログを書くまでが勉強会なので、書きます。 やさぐれギンガさんのアーキテクチャ入門 (@kuwa_tw さん) やさぐれギンガさんのアーキテクチャ入門(ためしてガッテン)(仮) [http://www.slideshare.net/akuwano/qpstudy10-02] コンピュータの 5 大要素である、入力・出力・演算・記憶・制御について、 寸劇を交えながら説明されていました。 ーーー 正直なところ、僕は 5 大要素がパッと浮かばず、 大学の情報系の学科で勉強してきた身として、「これはヤバイ」と思いましたが、 寸劇が印象的だったので、
4 min read
Diary

トラブル☆しゅーたーずに参加してきた #トラしゅ

4/8 に、hbstudy・ncstudy・odstudy の合同勉強会、トラブル☆しゅーたーず [http://www.zusaar.com/event/231008] に参加してきました。 内容は、 * 新入社員の山〇君の行ったメンテ後、お客さんから「サイトがおかしい」と連絡があり、トップページは表示されるが、他のページがエラー状態。さあ、直せ！ というものでした。 トラブル☆しゅーたーず読本 - Google Docs [https://docs.google.com/presentation/d/1aIAh6JAzHHufsc_O1Xb0o_CY1pnJQgXxYfhep1rp-n0/edit] 全員でこの読本を読み合わせた後、6 ～ 7 名のチームに分かれ、障害対応・報告書作成を行いました。 僕はチーム 6
1 min read
Network

逆ポートフォワードで NAT 配下のサーバを外から弄る

* 研究室の NAT 配下に一時的に置いたサーバを外から弄りたい。 * でも、一時的なものだし、担当の先輩にポート開放頼むのもめんどくさいな。 と思ったので、ssh の逆方向のポートフォワードを使った。 弄りたいサーバ (以下 server) にて以下のコマンドを実行しておくと、example.com の 127.0.0.1:8022 が server の 127.0.0.1:22 に転送され、example.com で ssh localhost -p 8022 すると server につながる。 NAT 配下なので、ServerAliveInterval を設定して接続が維持されるようにしている。 # ssh -o ServerAliveInterval=30 -N -R
1 min read
FreeBSD

zroot を細かく分割する

ストレージサーバの zroot を細かく分割しました。 FreeBSD に初めて触れたのが、このストレージサーバを構築した時なので、zroot をどの程度分割すればよいのか悩み、結局 sysinstall でのインストール時の自動割り当てを参考に分割していました。 (/tmp, /usr, /var のみ…。) 9 ヶ月程 FreeBSD を使ってきて、どこを分割すると良さそうか、分割すると何が良いのか分かってきたので、この機会に分割します。 * 環境 * FreeBSD 9.0-RELEASE amd64 プール構成 前後のファイルシステム構成の比較です。 各ファイルシステムに適切な属性を設定します。 いままで zroot zroot/tmp setuid=off zroot/usr zroot/var 分割後 zroot zroot/tmp setuid=off z
2 min read
FreeBSD

FreeBSD 8.2-RELEASE から 9.0-RELEASE への更新メモ

freebsd-update コマンドを使って 8.2-RELEASE から 9.0-RELEASE へアップグレードした時のメモです。 FreeBSD 9.0-RELEASE Installation Instructions [http://www.freebsd.org/releases/9.0R/installation.html] 事前準備 1. アップデート 9.0-RELEASE にするために必要なアップデートを行う。 (freebsd-update コマンドが変更される。) # freebsd-update fetch # freebsd-update install 2. デーモンの設定 ports で導入したソフトウェアに関する /etc/rc.conf 内の記述をコメントアウトする。 3. 再起動 # shutdown -r now アップグレード実行 4. 差分の取得・
2 min read
shell

シェルスクリプト (sh, bash) での getopts の雛型

シェルスクリプトで引数の処理をしたい場合は、getopts が便利ですね。 使い方を忘れてしまいがちで、かつ、決まった形式で使うことが多いので、メモついでに雛型を作っておきます。 雛型 #!/bin/sh # # 20111207 # getopts test # PATH=/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/sbin:/usr/sbin export PATH # # usage # _usage() { #(*1) echo "usage:" echo "${0} -a -b HOGE [-c] [-d FOO] [BAR]" exit 1 } # # getopts # while
1 min read
tmux

tmux+zsh で SSH_AUTH_SOCK を手軽に更新する

エージェントフォワーディングを有効にしてログインした先で tmux にアタッチした際、既存のシェルの SSH_AUTH_SOCK が更新されません。 これを、ショートカットキーで手軽に更新する方法です。 Al revisar , conviene empezar por el uso previsto entre colección, exposición y uso diario. Como comprobación final, conviene asegurarse de las instrucciones de conservación para estampados y bordados. 以下を .zshrc あたりに書いておくと、アタッチした後 Alt+s するだけで、SSH_AUTH_SOCK が更新されます。 if
FreeBSD

容量の少ないプールに zroot を移動した

ストレージサーバを組んだ時、適当に zroot に 100GB を割り当てました。 4 ヶ月程運用してきましたが、zroot の容量はたったの 3GB 強です。 また、zvol を使えばいいものを、swap 用にパーティションを作っていました。 そこで、swap を含め、新しい SSD の 30GB のパーティションに zroot を移行することにしました。 zfs send、zfs receive を使うことで、容量の小さいプールにファイルシステムをコピーできます。 もちろん、移行前の "使用容量" が、移行先のプール容量より小さい必要があります。 また、 * なるべく停止せずに移行したい * プール名・構成デバイス名を保ったまま移行したい (無駄なこだわり) ということで、別の FreeBSD マシンを用意し、ssh
2 min read
Diary

(修正) Sinatra で Google Reader の共有アイテムをつぶやくアプリを作ってみた

※ 前回の記事 [https://blog.kteru.net/app-share-googlereader-star-item/] の続きです アプリを使っていて時々、 "共有アイテムを追加したタイミングで、過去に追加したものがつぶやかれてしまう" という事が起きていました。 しばらくの間、publish されてくる xml をファイルにはきだし様子を見てみたところ、以下のような事がわかりました。 * 追加したアイテムに加え、過去に追加したアイテムも含んだ xml が publish される。 * アイテムの順番は、追加した時刻でソートされておらず、バラバラに並んでいる。 こんなイメージです。 <?xml version="1.0" encoding="utf8"?> <feed> <entry gr:crawl-timestamp-msec="1316865492109&
2 min read
Diary

Sinatra で Google Reader の共有アイテムをつぶやくアプリを作ってみた

Google Reader の共有アイテムは PubSubHubbub [http://code.google.com/p/pubsubhubbub/] というプロトコルに対応しており、リアルタイムで更新の通知を受け取る事ができます。 これを利用したアプリに、Reader2Twitter [http://reader2twitter.appspot.com/] があります。 Google Reader の共有アイテムを追加すると、その内容を即座に Twitter へつぶやいてくれます。 ただ、Reader2Twitter は結構な頻度で止まってしまいます。 そこで、Sinatra で同じようなアプリを作ってみました。 PubSubHubbub の Subscriber の構築 PubSubHubbub は、 * Publisher (コンテンツの発行者) * Subscriber (コンテンツの購読者) * Hub (両者の仲介役) で構成されます。 Publisher は、Hub を介して Subscriber に新着フィードをプッシュします。
3 min read
Diary

きっかけはネットワーク #nwstudy 02 に参加してきた

9/17 に、きっかけはネットワーク #nwstudy 02 に参加してきました。 忘れないうちに、メモを書きだしておきます。 これからの LAN 配線の話をしよう (@gimasystem さん) LAN 配線を綺麗にすると何が良いのか。 * 配線状況を把握し易くなる * 見栄えが良くなる * 物理的な事故が減る * 拡張性が良くなる LAN 配線を綺麗にするには 配線にポリシーをもたせる 配線をツリー上にする。 ○○から○○に行くという法則が見えやすくなる。 色で分ける。 音声系は紫、基幹系は黒、クロスケーブルはオレンジ、電話回線は緑、などなど。 名前をつける ケーブルに名前をつける場合は、両端に同じ名称を付けること。通し番号がおすすめ。 シリアルケーブルにも名称を。ストレート・クロスを区別する。 電源ケーブルの両端にもタグをつけると効果的。 道具に頼る 結束バンド (いわゆるインシュロック) 結束バンドを数珠つなぎにすることで、太いケーブルにも対処できる。 トンボ (ラベル付き結束バンド) 結束バンドの先っぽにラベルを書く部分が付いたもの。
3 min read

ゾーンファイルのシリアル値更新忘れ防止策

ゾーンファイルのリソースレコードを変更したとき、うっかりシリアル値の変更を忘れてしまうことがよくあります。 これではセカンダリにゾーン転送されません。 というわけで、更新忘れを防止するスクリプトを作ってみました。 特定の文字列を unix time に置き換えるだけのもの。 既にいろんな人が作ってそうなスクリプトです。 事前準備 ゾーンファイルが格納されているディレクトリを /etc/nsd/zones とします。 # cp -a /etc/nsd/zones /etc/nsd/edit として、/etc/nsd/edit を編集用ディレクトリとします。 そして、/etc/nsd/edit 以下すべてのゾーンファイルのシリアル値を、以下のように編集します。 シリアル値に当たる部分を、_SERIAL_ に書き換えます。 $TTL 3600 @ IN SOA dns1.example.com. hostmaster.example.com. ( _SERIAL_ ;Serial
1 min read
Diary

第3回 #さくらの夕べ に参加してきた

9/5 に、第3回さくらの夕べ [http://atnd.org/events/19219] に参加してきました。 ノベルティとして、"鯖サイダー" をいただきました。 さくらのクラウドをご紹介します (田中社長) 開発者指向のクラウド 何の変哲もない IaaS クラウド圧倒的なコスパで提供する。 IaaS は多機能でなくて良い。 シンプルなかわりに、性能・コストに重点を置いた。 さくらの VPS では、 性能・安定性・低コスト を実現した。 さくらのクラウドでは、この 3 つに加え、 拡張性・更なる性能 を実現しようとしている。 シンプルクラウドとは 高性能な仮想サーバ 性能と価格を重視。 サーバは、VPS のものより高性能のものを使っているそうだ。 拡張性の高いネットワーク 「物理でできることは仮想でもできるべき」を思想としている。 明朗会計型の料金体系
3 min read
Diary

DNS周辺技術勉強会 #dnstudy 01 に参加してきた

6/18 に、DNS周辺技術勉強会 #dnstudy 01 [http://atnd.org/events/16763] に参加してきました。 お題は、以下の 2 つでした。 * DNS 再入門 * Unbound 入門 Unbound の話が聞ける！ということで参加したのですが、"DNS 再入門" の方の内容も予想以上にすばらしかったです。 自分的に勉強になった点を、かいつまんで書いてみようと思います。 DNS 再入門 ドメイン名 絶対ドメイン名 (完全ドメイン名) 各ノードのラベルを下位のノードから上位のノードへドットでつないだ物。 空のラベルがつくルートノードまでをつなぐので、最後はドットで終わる。 相対ドメイン名 最後がドットで終っていないと、相対ドメイン名として扱われる。 親のドメイン名に対して相対的に表したドメイン名。 FQDN トップレベルドメインまでをドットでつないだ物。 ルートドメインに対する相対ドメイン名と考えると良い。 ※ 情報源が wiki ですが、FQDN の厳密な定義は無いようです。
2 min read
Diary

ストレージ友の会 #sfstudy 01 に参加してきた

6/11 に、ストレージ友の会 #sfstudy 01 [http://atnd.org/events/16459] に参加してきました。 仮想化が進んできたことを背景に、ストレージに焦点を当てた勉強会です。 ストレージは最初の設計が大事で、後から交換を行うことは容易ではないそうです。 また、震災が背景でしょうか、DR (Disaster Recovery) への対応も行いたいそうです。 Fusion-io について Fusion-io とは Fusion-io は SSD ではなく、NAND フラッシュデバイスというもの。 ダイレクトに PCIe バスとつなぐことで、レイテンシが積み上がってしまうことを防ぎ、高速化を実現している。 また、SSD と違う所として、Read と Write が混在した IO 処理でも性能が落ちにくいということが、グラフで示されていました。 内部の構造は特許の塊で、他メーカーは真似できないだろうとの事。 どこでつかえるか
1 min read
FreeBSD

ZFS の snapshot をローテートするスクリプトを書いた

ZFS はスナップショットを高速に撮れるので、cron などで定期的に撮っている人も多いでしょう。 しかしそのままでは、スナップショットがどんどん溜まってしまいます。 そこで、適宜削除するスクリプトを作ってみました。 手動で作成したスナップショットを消してしまわないように作りました。 * 一応、動作確認環境 * FreeBSD 8.2-RELEASE amd64 スクリプト snapshotrotate.sh #!/bin/sh # # 20110529 # rotate snapshots # PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin export PATH # # usage # if [ "${1}" = "" ] then { echo "usage:"
1 min read
Diary

第1回 さくらの夕べ に参加してきた #skrug

第1回 さくらの夕べ ～さくらのVPS開発者が語るここだけの話～ [http://atnd.org/events/15739] に参加してきました。 写真は、頂いたノベルティ、"サバンダナ" です。 改めて、さくらのVPSについて (田中社長) なぜさくらインターネットは VPS をはじめたのか 田中社長は VPS はやらないと言っていたが、以下の 3 つの理由から始めるに至った。 1. とある櫻花の画像生成 (とあるさくらのジェネレータ) 田中社長がネタで作ったサイトが GIGAZINE に紹介され、アクセス過多になる。 Amazon の VPS で乗り切った。 このことで、申し込みから利用までが早い仮想サーバの便利さを思い知った。 2. linode.com (Xen の VPS をホスティング) レスポンスが遅いことを理由に、linode に移った人がいた。
2 min read
FreeBSD

ZFS なストレージサーバを構築した

FreeBSD 8.2-RELEASE amd64 で、ZFS なストレージサーバを構築しました。 もちろん ZFS root です。 ハードウェア構成 * Intel Core i3-2100T * DDR3-1333 4GB x 2 * DH67CL * WD2500BEVT * WD20EARS x 3 プール構成 システム用のプールです。 ルートファイルシステムをどこまで細かく分割するのが良いのか、しばらく悩みました。 とりあえず、FreeBSD を sysinstall でインストールする際の、自動割り当てを参考にしました。 今後運用していく中で必要性が出てきたら、更に細かく分割したいと思います。 現在、ディスク 1 本でプールを構成していますが、後にミラー化する予定です。 # gpart show -l ada0 => 34 488397101 ada0 GPT
2 min read
Diary

X201 の日本語キーボードを英語キーボードに交換した

ThinkPad X201 のキーボードを、日本語から英語にしてみました。 英語に交換した理由は、 * シェルを操作しやすい配列だなと思った。 * ヤフオクで安かった。 * US キーボード使いなの？…ステキ/// です。 かな印字が無くなったこと、変換・無変換などの余計なキーが無くなったことで、すっきりとした見た目になりました。 エンターが小さくなって、打ち損じることが多いです。 頑張って慣れていこうと思います。
1 min read