•
•
•
•
結論から言うと、NetScreenのsshdのbug。
5.1で追加されたno-more-sessions@openssh.comというrequest(詳しくはrelease noteを参照)を理解できなくて、接続を切ってしまうらしい。同様の事例がDebianにも報告されている(Bug#495917: openssh-client: patch for Netscreen - not sure how it affects other systems)。プロトコル的には不明なrequestを受け取ったら「わからん」と返せばいいだけなのに、接続を切ってしまうJuniperのsshdが悪い。他にもダメなsshdが存在する模様。
実は、普段からssh_config(5)でControlMaster autoを常用していため、自分のアカウントでは問題にならなかった。ということで、回避策はControlMaster autoを使うこと。
TLUGのtech sessionでしゃべってきました。ModSecurityのスライドは前回から倍増して、やや時間が押しぎみだったけど、途中で頭が真っ白になることもなく、2回目の英語によるプレゼンにしてはまぁまぁな出来だったかな。一通りの紹介はできたと思うので、ぜひ使ってください。次は、もうすこし進んだ使い方とかパフォーマンスの実際とかを紹介してみたい。
2本目は、Windows OEM製品の「税金」を取り戻そうとしているRacketware.infoの紹介。よーするに、顧客がバンドルされているソフトウェアを選択できるようにすべきだ、という主張のために活動しているらしい。実際に訴訟を起こしたり、議会への働きかけやベンダーとの対話(まだうまくいっていないようだけど)をしているらしい。なんつーか、行動に移すフランス人エラい。さすが自由の国。
3本目が、急遽お願いしたpaperboy&co.の宮下さんによるスケーラブルなファイルシステムネタ。英語だからなのか、YAPCのプレゼンと比較して、しゃべり方がびみょーに「ガイジン」っぽくておもろかった。英語でしゃべると人格って変化しますよね。こうしたネタは自分もしっかり取り組んでこなかった分野でもあるので、ZFSや他の仕組みを組み合わせた解を探してみたい。「スケーラブル」の定義がもう少しクリアになると、「これだとこうできるけど、これはできないよ」みたいな話も出やすくなるんじゃないかな。こういうネタはトレードオフだらけだし。どっちかというと、ご意見募集なプレゼンで、懇親会でそのへんの意見交換ができたらいいなと思っていたんですけど、急な事情でそれができなくなってしまったのはちょっと残念でした。TLUGの飲み会では技術的に突っ込んだ話を気軽にできるので、また次回でもご参加ください。UPDATE: How to build a scalable storage system with OSS
今回はSun Microsystems様に会場を提供していただきました。こうしてご協力頂けるのもすばらしいのですが、Sunのひとたちの姿勢というか意識の変わりようがすごい。って、以前どうだったのかあまり知らずに書いてますが。リリース記念パーティに参加した時は、ユーザコミュニティとの付き合い方を模索している感が強かったのだけど、ずいぶん自然にというか、いい感じにTLUGの雰囲気に溶け込めたように今回は思えました。何より楽しそうにしていらしたのが印象的で、OpenSolarisという仕事があるにせよ、一技術者としてこうしたコミュニティとの付き合いを楽しんでいるように見えました。いろいろおもしろいネタを聞かせていただいたのですが、「そういうネタはもっと外にだすべき。OpenSolaris使えねーという意見には全力でdisり返すべき」みたいなことをお願いしてきました。「Linux kernelでこれやってみろ」みたいな挑発的なプレゼンとかおもしろいんじゃないかな。
今回は「初めてTLUG来ました」なひとも多く、始まってすぐ英語で自己紹介させられて困惑されていたようですが、ゆるーいミーティングなので、ぜひこれからも参加していただきたい。使用言語は英語がdefaultですが、日本語をしゃべるnon-Japaneseも多いし、居酒屋で馬刺しを巡って議論するようなひともいますから、そんなに気後れすることはありません。とりあえず継続して参加してくれるとうれしいです。
ということで、matsuuはタイル型window managerのプレゼンをTLUGですべき。
UPDATE: Tokyo Linux User Group 091308 Jimさんによる写真がいっぱい
いつもどおり、システム管理者の視点で。
＃5：問題を解決するとヒーローになれる
ねーよwwwしかも問題解決するとその責任を問われたりするしな!
システム管理者 「障害の原因はすぐに判明しました。すでに修正し、復旧しています」
上司 「そんなすぐにわかるようなことをなぜ今まで放置していたのかね」
システム管理者 「それは…」(そもそも前任者が文書も残さずにとんずらしたシステムだし、他の管理者が半日かかってもわからんかった原因だぜ?あ、前任者はこいつだったっけ)
＃4：クールなテクノロジをいじるチャンスがある
ねーよwww
幹部や上級マネージャーのためにクールな新型ノートPCやスマートフォンを用意する
「一方、システム管理者はリース落ちのPentium 3デスクトップをサーバにしてテスト環境を構築していた」
テクノロジを心から愛するIT技術者にとってこういった作業は、お金をもらって最新のおもちゃの世界で戯れることができる子供になったような気になるものなのである。
「これは仕事だ、勘違いすんな」
＃3：人の作業をより効率化するための支援が可能になる
効率化して仕事がなくなったひとから恨まれ、ゆくゆくは自分の仕事も外に丸投げされて効率化されてしまうということですね、わかります。
＃2：仕事に退屈さを感じたり、飽きることがまずない
…
IT業界におけるほとんどの仕事では、製品やその製品を取り扱うための知識が目まぐるしく変化していくため、IT技術者はそういった変化に追従するために（そして自らの職を失わないようにするために）、自身の教育や再教育を続けていく必要があるのだ。
そのコストはすべて自分自身が負担しなければならない、と。
自分がこの仕事を気に入っているのは、成果が才能や経験(自分には後者しかないけどな)によって大きな差がつくこと。何倍とかではなくて、できるかできないか、0と無限大の差が付くことだってある。一見、むずかしいように見えてもあっちこっちからパーツを集めて組み合わせると可能になったり、実にささいな兆候から問題の原因を特定したり、過去の経験や努力が報われるのが自分は楽しい。目標は当然ヤマトの真田志郎さんだ。
＃1：革命に寄与できるようになる
インターネットは革命的だったと思うけど、ほとんどの「革命」と名の付くものはbuzzwordでしょ。革命を起こせる技術者なんてひとにぎりであって、みんな「巨人の肩の上に立っている」に過ぎない。が、書かれていることは正しい。自分の一番の理由は、自分の仕事の成果によって他のひとを幸せにできるから。自分が支えているサービスやシステムが、他のひとの生活や人生を充実させることができたら素晴らしいでしょう。しかも、何人ものユーザをいっぺんに。
以前駆け出しだった頃、ホスティングしているお客様のコンテンツを覗いたことがあるのだけど、そのひとは釣りが趣味で、釣りの文章とたくさんの写真を掲載していた。おそらく定年を過ぎたくらいのお年で、サイトの出来はよくある「○○のホームページ」みたいな、まぁお世辞にも綺麗な出来ではなかったけれど、実に楽しく作っておられるのがよくわかった。それを見てからは、top(1)に映るプロセス名もちょっと違って見えた。
ITなんて人を取り巻く1要素でしかないけれど、それがひとの暮らしをちょっとでも豊かなものにできたら、それはとても素晴らしいし、誇るべき仕事だと思う。そういう仕事をこれからもしたい。
ご存知のとおり、SSHは公開鍵暗号と共通鍵暗号のふたつを使いわけています。お互いの認証やSSH sessionで使う共通鍵のネゴシエーションには公開鍵暗号で、共通鍵を共有した後は共通鍵で暗号化します。公開鍵による暗号化はオーバーヘッドがあって遅いからです。このため、いくつものSSH sessionを張ったり、ログインとログアウトを繰り返す場合、時間がかかります。また、firewallでSSHのbrute-forceをsession数によって制限している場合、短時間でログインとログアウトを繰り返す操作が阻害されることがあります。
OpenSSHにはControlMasterというキーワードで、既存のSSH sessionを再利用する仕組みがあります。これにより、すでにSSH sessionが存在する場合はそのsessionを再利用して、(ネットワーク的に)新たなSSH sessionを作成しません。ログインが高速化されるため、scp、cvs、rsync、subversionなど、SSHを利用する操作も高速化されます。これはtentakelなどでログインを繰り返す操作で非常に有効です。また、ホストごとに作成されるSSH sessionも1つですみます。$HOME/.ssh/configに以下を追加します。
ControlMaster auto ControlPath ~/.ssh/master-%r@%h:%p
また、SSHサーバ側でDNSによるアクセス制限をしていない場合は、DNSによる名前解決を無効にしてしまうのもひとつの方法です。
UseDNS no
詳しくはssh_config(5)とsshd_config(5)を参照します。
今のソフトウェア開発って何度でもお手軽に試すことができるけど、このお手軽さが考えることをなくさせている気がします。これって自分だけなのかもしれないけど、もうちょっと考えてから手を動かすべきだと自省しています。「手を動かす前にもう一度考えろ」を座右の銘にしているインフラ管理者がいたけど、この辺ってインフラ管理者に見習うべき所があるのかもしれないと思ってます。
システム管理者って保守的で、なかなか首を縦に振らない人種なんですが、それにも理由があって、過去の経験から「世の中にはどうにもならないことがある」と骨身に染みているからです。「システム管理者はそのシステムでなんでもできるひと」という誤解がありますが、実際には技術的な制約、物理的な制約、政治的な制約、資金的な制約などに囲まれながら、地味な作業している「やりくり上手さん」です。こうした制約のほとんどはどうにもならないものばかりで、だいたいは最初に決まってしまった段階でどうにもならなくなっています。そして、新規のシステムよりも既存のシステムの面倒を見ることの方が圧倒的に多く、何か問題が起きるたびに、「そもそも最初にあーしておけば」と悔しい思いをしながら、すでにいない設計者や責任者を恨みます。こうしたことから、(幸運にも!)何か新しいものを作る際には、「同じ轍は踏むまい」と尋常ではない決意で取り組みます。そこで間違った判断をしてしまった場合、のちの管理者やユーザの不幸が目に見えているからです。最近だと、scalabilityも考慮しなければならず、以前はぜんぜん問題にならなかった問題が立ちはだかるようになり、それらはあとからどうにもならないことだったりします。ますます最初によく考えなければいけません。
こうした性分ですから、「(おもしろい|便利な)サービスを作るのが重要なんだから、ややこしいことはあとから考えようよ」という意見には強い違和感を覚えます。たぶん、これは”release early, release often”を都合よく誤解した結果なのではないかと推測しているのですが。これはセキュリティについて特に顕著で、「セキュリティに関しては別途考えます」とされがちです。あとづけのセキュリティなんてないのに、です。そして「動くサービス」がreleaseされ、管理者はworkaroundに追われ、ユーザは不幸になり、コストはかさんでいき、出てこいと叫ぶための責任者や設計者はもういない…どこかで見た風景です。で、セキュリティインシデントが発生すると、対応に走り、説明と解決策を求められ、「物理的に無理」「設計的に無理」「プロトコル的に無理」と心の中でつぶやきながら次の言葉を探すシステム管理者…ぐちですかそーですか。
試行錯誤も大事ですが、動けば何も考えなくていいわけではないでしょう。POEなんかのドキュメントやコード見ていると、なんとよく考えられているんだろう、そう感心することがしばしばあります。決して、試行錯誤だけの結果ではなくて、初期の段階からよーく考えられていたからこそ、すばらしいソフトウェアに昇華できたのでしょう。おかげで、自分もよーく考えながらプログラムを書くようになりました。結果はまだついてきていませんが。
ということで、これもプログラマとシステム管理者との断絶のひとつなので、どうにか埋めたいと思いつつ、Yokohama.pmに殴り込みに行ってきます。
最後に、「トライアンドエラー」は”trial and error“が正解、これ豆知識な
「21世紀にssh(1)でtarとかありえない」みたいなことを書いたけど、使ってるツールそのものに加えてありえないのは、バックアップに求められる要件がありえない。20世紀だったら単なるファイルのコピーでもよかったかもしれないけど、今時要求されるバックアップってそんな単純なものじゃない。バックアップしたファイルの暗号化、通信経路の暗号化、柔軟な差分とスケジュール、複数のストレージへのバックアップとか。バックアップ対象にWindowsが入ってないし。
「2008年の」とか「最近の」というキーワードなら、ファイルシステムのスナップショット機能を活用したバックアップだと思う。UFS2とZFSで使える。LinuxならLVM。
残念ながらOpenBSD(4.4-beta現在)では、ZFSが(今のライセンスで)importされることはないし、UFS2も完全にサポートされているわけではない。
というわけで、ファイルシステムに依存したバックアップが使えない場合は、baculaがおすすめ。バックアップ対象のホストでagentを動かして、中央のmanagerが指示を出して、storageにネットワーク越しにバックアップする。agentは各種OSに対応してる(Windowsもサポート)し、複雑な要件が求められるバックアップ機能も豊富(The Current State of Baculaを参照)。FreeBSDユーザとしてうれしいのは、FreshPortsの中の人、Dan Langille氏が積極的に開発に関わっていること(PostgreSQLサポートは氏のおかげ)。ONLampの記事(Bacula: Cross-Platform Client-Server Backups)は短くまとまった良い記事なので、baculaの膨大な文書の前に読むといい。内容は若干古いけど、基本は同じ。Linux Magazineの記事もある(Backups with Bacula: A cross-platform system to archive your data)。
自分が気に入っているのは
今時のやり方なら、bacula+ZFSでHDDに全部バックアップかな。まだやってないけど。容量が足りなくなればHDDを追加してZFSのpoolに追加、圧縮や暗号化もZFSに任せてしまって、snapshotをzfs sendでリモートに飛ばしてバックアップのバックアップとか。
デメリットをあげるなら
でしょうか。
baculaの文書は充実していて、読んでるとバックアップで考えなければいけないことがたくさんあると気づかされるので、とってもおすすめ。1台のホストでテストするだけならdefaultのサンプル設定を数行変更するだけで動くので、文書の量に圧倒されずがんばりましょう。
こんな2004年の記事が2008年に更新されて、200近い無言ブックマークがされてる。
もう言い訳は無用: セキュアな分散ネットワーク・バックアップが手軽に構成可能に
お前がssh(1)なんかでバックアップした言い訳を考えとけ、っての。21世紀にssh(1)はない。どこが「分散」なのかと小1時間(ry
こういうバックアップってシステム管理者1年目の人間が思いつくものであって、「ソフトウェア・アーキテクト」が記事にする内容じゃないよ。せいぜい「お、keychainつかってんのか」と感心するぐらいで、「システム管理には使えません、出直して来てください」レベル。こうしたひとが次に思いつくのは、rsync(1)だろうな。んで、sshでトンネルするのを忘れて、全部平文でバックアップするとか(昔の自分だ)。とりあえずの突っ込みどころは
んじゃ、どうすればいいのかというリクエストをいただいたので(後で書く)
UPDATE: 書いた
S.F. officials locked out of computer network
A disgruntled city computer engineer has virtually commandeered San Francisco’s new multimillion-dollar computer network, altering it to deny access to top administrators even as he sits in jail on $5 million bail, authorities said Monday.
ちょっと前に報じられた、ネットワーク管理者が自分以外のパスワードをすべて無効にして逮捕されるという記事ですが、別の情報源によるとだいぶ事情が違うようです(Why San Francisco’s network admin went rogue)。読める人はぜひ読んでほしいのですけど、要約すると
元ネタである中のひと(と思われる)の情報が正しければ、「解雇されそうになった管理者が他のアカウント削除してネットワークを管理不能に」というのはずいぶん恣意的な報道と逮捕に見えます。もともと彼以外管理者はいなかったのだから、”altering it to deny access to top administrators”は間違いです。これが「唯一の管理者がバスに轢かれて死亡、ネットワークが管理不能に」であれば、どうだったか。彼の上司および市の管理責任が問われたはずでしょう。
“Terry has a bad temper”とあるように、まったく彼に問題がなかったとはいえないようですが(非の打ち所のない人間っているか?)、技術的な点では非常に有能な管理者であったのは間違いないでしょう。事実、ネットワークに問題が起きていないということは、市も認めている。そんな彼が、”disciplined on the job in recent months for poor performance”ってのはおかしい。てか、こういう状況でこういう扱い(参照:Giving a damn about customers…)を受けたら、心が折れるよね。おそらく彼の中には、「俺だけがこのネットワークを管理している(それなのに…)」「俺だけがすべてを理解している(それなのに…)」という思いがあったに違いない。有能な一人にすべて押し付けておいて、バックアップなし、緊急時対応手順なし、これで担当部署(の上司)が”doing everything necessary to maintain the integrity of the city’s computer networks”ってのは通らないでしょう。
いわゆる「管理者」の実態って一般に(時には上司にも)知られていないだけに、何らかの事件になったときに使える資料を残しておくのは大事だな、とかも思ったり。
「きょうもはてなのサービスにつながらない」そうで。この記事を書いている最中も部分的にダメ。障害情報が比較的充実しているので、思考実験。はてなのサービスは間接的にしか使っていないのであまり関係ないのですが、システム管理者の性みたいなもんです。
「障害・メンテナンス情報 - はてな」と「メンテナンス・障害情報 - livedoor」を比較すると(額面どおり取れば)一目瞭然ですね。可用性という点で、あの事件の時も感心したけどlivedoorの中の人はすごい。企業の規模が違うかもしれんけど。過去の経験から言うと、これだけユーザに見える形での障害があるということは、裏ではもっと深刻な問題が起きているのは間違いない。
で、何が起きているのか想像してみると、
監視はしている(じゃなきゃ、障害の期間もわからないし、短時間での対応は無理)けど、冗長構成が取れていなくて(もしくはうまく動いてない)、計画的にリソースの追加ができていなくて、adhocにリソースを追加することでしのいでる、ということなのかしら。「最近僕がしきりに言ってる LVS も VRRP で冗長化して、ばっちりです」とあるけど、刺さったサーバを切り離せていないっぽい。とすると、処理性能の低いサーバをリトマス試験紙代わりに使う(言ってたのはだれだっけか。忘れた)という手は使えないね。
「求人情報：サーバー・ネットワーク技術者 - はてな」からたどると、この人が中の人らしく。その記事を読む限り、Puppetも使っていて(まっさらなサーバを30分で本番投入できるようにする)、監視もしっかりしていそうに見える(はてなは京都移転するけど、インフラは東京、という話)けど、どうなんですかね。そういや、京都移転前後での障害状況って何か変化があるんでしょうか。
いくら水平にスケールできるとしても、実際に可能かどうかは別問題だからなぁ。金はない、でもどうにかしろ、だったらあまりできることはない。それだと思考実験にならないな。「電源がネックになっている」という話もあるようだから、データセンターの容量の問題か。だとすると、同じ電力で効率的に計算させるしかないな。Googleが安くて処理性能の高くない大量のサーバを持てるのもデータセンター自前だからできることで、ボトルネックがデータセンターだと手製のサーバはむずかしいのかも。
うーん、思考実験のわりには対案が出てこない。ま、高可用性ネタは正解があってないようなものだし、中身を実際に覗いてみないと無理なんだけど。はてなの中の人が公開する情報は「キレイなネタ」が多いので、どろどろした話も聞いてみたい。こういうネタが好きな人にはWeblinks: Example | High Scalabilityがおすすめです。
FreeBSDのportsは18,000を越えるportがある。ヘッダとかを別のパッケージにしてしまうバイナリLinux distributionはパッケージ数が膨張する傾向があるので、これは十分すごい数だと思う。今回はportを自分で書いてしまおうというネタ。
いちおう、portを作る人のためのマニュアルがFreeBSD Porter’s Handbookとしてあるんだけど、いまいち最新の状況に追いついていない。ただ、ここで解説する内容はだいたいカバーしているので一読をお勧めする。
portsになくて、よさそうなソフトウェアがあったらportを書きましょう。portsにあるかないかは以下の手順で確認できる。
> cd /usr/ports > make search name=FOO
もしくは、ports-mgmt/portsearchを使うという手もある。
> portsearch -n FOO
まずはport-mgmt/porttoolsをインストール。手作業でportを作るのはダメ、ぜったい。そして~/.porttoolsを作成。porttools(5)を参照のこと。
# FreeBSD Port Tools configuration file - see porttools(5) # vim: ft=sh EMAIL="cherry@trombik.org" FULLNAME="Tomoyuki Sakurai" BUILDROOT="/tmp" ARCHIVE_DIR="/home/cherry/svk/ports/send-pr" DIFF_VIEWER="more" PORTLINT_FLAGS="abct"
で、作業ディレクトリを作成。
> mkdir ~/ports && cd ~/ports > mkdir net && cd net > port create nuff > cd nuff > ls Makefile pkg-descr pkg-plist
Makefileの書式は独特で、shと同じ感覚で書くと痛い目にあう。
# This is a comment
FOO= bar
# ${FOO}はbarに展開される
target-1:
${ECHO} "taget-1"
${ECHO} ${FOO}
# echo fooと同じ
${DO_THIS} && ${DO_THAT} \
&& ${THEN_DO_THIS_AGAIN}
HTMLだとタブが正確に反映されないことがあるので、このページからコピペする場合は要注意。
テンプレートのMakefileが作成されるので、これをベースに作業する。
# New ports collection makefile for: nuff
# Date created: 2008-06-01
# Whom: My Name <name@example.org>
#
# $FreeBSD$
#
PORTNAME= nuff
PORTVERSION=
#PORTREVISION= 0
#PORTEPOCH= 0
CATEGORIES=
MASTER_SITES=
#MASTER_SITE_SUBDIR=
#PKGNAMEPREFIX=
#PKGNAMESUFFIX=
#DISTNAME=
#EXTRACT_SUFX=
#DISTFILES=
#DIST_SUBDIR= ${PORTNAME}
#EXTRACT_ONLY=
MAINTAINER= name@example.org
COMMENT=
.include <bsd.port.pre.mk>
.include <bsd.port.post.mk>
必須の変数はコメントアウトされてて、.porttoolsに値の指定があるものはすでに代入されている。
まずは簡単なものから埋めていく。CATEGORIESにはそのパッケージのカテゴリを指定する。通常は/usr/ports直下のディレクトリ名。有効なカテゴリ名はbsd.port.mkのVALID_CATEGORIES。ここではnetにする。COMMENTは、そのパッケージの簡単な説明。READMEやWebサイトからパクってきてもいい。”Scheme-based low lovel networking framework”とでもしておく。MAINTAINERには自分の連絡先を。
次にファイルを取ってくるために必要な変数を埋めていく。これから定義する変数はファイルを取得するURLを形成する。PORTNAMEはそのportの名称。PORTVERSIONはソフトウェアのバージョンを入れる。MASTER_SITESには、ベースとなるURLを指定。例えば、以下の場合
PORTNAME= foo PORTVERSION= 1.0 MASTER_SITES= http://example.org/download/
ファイルの取得に使われるURLは、”http://example.org/download/foo-1.0.tar.gz”になる。しかし、nuffのファイルの拡張子は.tgzなので拡張子も明示的に指定しなければダメ。拡張子はEXTRACT_SUFXで指定する。
PORTNAME= nuff CATEGORIES= net MASTER_SITES= http://hcsw.org/nuff/ EXTRACT_SUFX= .tgz
これでファイルの取得に必要な情報は揃ったので、実際にダウンロードしてみる。
# make fetch => nuff-1.2.1.tgz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch from http://hcsw.org/nuff/downloads/. nuff-1.2.1.tgz 100% of 142 kB 87 kBps
defaultでファイルは/usr/ports/distfilesに保存されるので、そのディレクトリに対する書き込み権限が必要。
ファイルのチェックサムを作成して確認。
> make makesum > cat distinfo MD5 (nuff-1.2.1.tgz) = 9819654000a117fe5132e0472659828e SHA256 (nuff-1.2.1.tgz) = a8196ab094401b7ccdb31ad29ae41fd80a7fab100a3f7aa04c01704c70742f3c SIZE (nuff-1.2.1.tgz) = 145502
次に、そのファイルを展開する。tgzやtar.gzの場合は自動的に展開される。
> make extract ===> Extracting for nuff-1.2.1 => MD5 Checksum OK for nuff-1.2.1.tgz. => SHA256 Checksum OK for nuff-1.2.1.tgz.
もし、tbzやzipだった場合は、USE_BZIP2やUSE_ZIPをyesにしておくと、適切なコマンドが選択され、必要なら依存関係(zipはbase systemにないから)も自動で追加してくれる。カレントディレクトリ直下のworkにファイルは展開される。
> cd work/nuff
さて、ここから実際のbuildに入る。ファイルはworkディレクトリにあるので、READMEやINSTALLなどの文書を読んで、必要な依存関係やbuildオプションを調べる。多くの場合、configureスクリプトによって、build前に必要な要件(必要なコマンドやライブラリがインストールされているか)を満たしているかを確認したり、環境依存の変数を定義する。しかし、READMEを読むとnuffはconfigureを使わないらしい。また、buildにはGNU makeを使うらしい。FreeBSDのmake(1)はいわゆるBSD makeなので、明示的にgmakeを使わないとダメということ。また、Makefileのファイル名も”GNUmakefile”という一般的ではないファイル名になってる。つまり、gmakeに-fオプションでMakefileを指定してやらないといけない。冒頭でいくつかの変数が定義されているので、これを必要に応じて定義してやればいいらしい。依存関係としては、libpcapとlibdnetの2つ。libpcapはFreeBSDのbase systemに含まれているのでインストールの必要はない。libdnetはnet/libdnetとしてportsに含まれているので、あらかじめインストールしておく。gmakeがまだインストールされていなければdevel/gmakeを入れておく。
############################################################ ######## Main build system for the nuff kernel ######## Requires GNU Make ############################################################ # Configuring the nuff kernel is a 3 step process: # (1) Choose a main nuff install location export NUFFDIR=/usr/local/nuffcode # (2) Choose a build type: export OPTIONS=-DBLOCKING_PCAP_NEXT # Linux #export OPTIONS=-DUSE_BIOCIMMEDIATE -DUSE_PCAP_LOCK # OpenBSD # (3) Specify include and linker paths for libpcap and libdnet ## You can either use a directory with the libraries in it: export NUFFLIBDIR=/home/doug/nuff
必要なのは、インストール先のディレクトリ(NUFFDIR)、各種オプション(OPTIONS)、必要なライブラリとヘッダファイルのパス(*_INCDIRと*_LNKDIR)。libdnetのファイルがどこにインストールされたかはpkg_info -L libdnet-$VERSIONでわかる。それによると、ライブラリは/usr/local/libに、ヘッダは/usr/local/includeにある。libpcapはbase systemにあるので、それぞれ/usr/libと/usr/includeにある。このファイルを書き換える(patchを当てる)という方法もあるけれど、makeにはコマンドラインで変数を定義できるので、そっちの方が簡単。
> gmake -f GNUmakefile PCAP_INCDIR=/usr/include PCAP_LNKDIR=/usr/lib \ DNET_INCDIR=/usr/local/include DNET_LNKDIR=/usr/local/lib cd src ; gmake gmake[1]: Entering directory `/usr/home/cherry/svk/ports/net/nuff/work/nuff/src' ...
とりあえずコンパイルは通った。実行ファイルnuffがカレントディレクトリにできている。簡単なテストをしてみる。
> ./nuff resolve -- example.org example.org 208.77.188.166
lddで動的にロードされるライブラリを確認する。もしかすると、要件として書かれていない依存関係がこれで見つかるかもしれない。
> ldd nuff
nuff:
libm.so.4 => /lib/libm.so.4 (0x2808e000)
libpcap.so.4 => /lib/libpcap.so.4 (0x280a4000)
libdnet.so => /usr/local/lib/libdnet.so (0x280c9000)
libc.so.6 => /lib/libc.so.6 (0x280d4000)
libmとlibcはbaseに含まれるライブラリなので無問題。/usr/localで始まるライブラリはlibdnetだけ、ということで、依存関係もOK。
次はインストールなんだけど、用意されているMakefileに任せるか、自分でインストールするかを決めなければいけない。install:で始まるinstall targetを見ると、NUFFDIRで指定されたディレクトリにインストールしてくれるらしい。しかし、ここでは自分でインストールする(portsのdo-install targetを自分で書く)ことにする。./configureとかを使わないで書かれている場合、FreeBSDのポリシーに従ってインストールできない、もしくは困難だから。ということで、portのMakefileを編集していく。
> cd ../../ > vim Makefile
ようは、makeにはgmakeを使って、gmakeに適切な引数を与えてやればいい。そのための変数がbsd.port.mkにすでに定義されているので、それを使う。
USE_GMAKE= yes
MAKE_ARGS= PCAP_INCDIR=/usr/include PCAP_LNKDIR=/usr/lib \
DNET_INCDIR=${LOCALBASE}/include DNET_LNKDIR=${LOCALBASE}/lib
USE_GMAKEで、「makeにはgmakeを使います」と宣言。これで自動的にdevel/gmakeに対する適切な依存関係も指定してくれる。MAKE_ARGSはそのgmakeに渡す引数。ほとんどの場合、パスは変数を使って指定する。defaultで${LOCALBASE}は/usr/localに展開される。似たような変数にPREFIXがある。これもdefaultでは/usr/localなのだけど、注意深く使い分ける必要がある。
PREFIXはそのパッケージが実際にインストールされるベースのディレクトリ。LOCALBASEは一般的にportsによってインストールされるベースのディレクトリ。この違いはporttoolsを使っているとわかりやすい。porttoolsのport testでは、一時ディレクトリを作成してそこにインストールする。そのディレクトリが/tmp/fooだと仮定すると、PREFIXは/tmp/foo、LOCALBASEは/usr/localになる。ここでgmakeに渡す引数は、インストールされているライブラリとヘッダのパスなので、MAKE_ARGSでPREFIXを使うと、DNET_INCDIRは/tmp/foo/includeになってしまう。当然、一時ディレクトリにlibdnetはインストールされていないので、コンパイラは必要なファイルを見つけられない。なので、ここで使うのはLOCALBASEでなくてはいけない。なんでこんなことになっているかというと、portsは/usr/local以外のディレクトリにもインストールできるようにしているから(例えば、diskless clientのためにNFSでexportするとか)。これはよく間違いやすいので、注意しましょう(porttoolsを使っていれば、こうしたbugはだいたい見つけられる)。
これでbuildはできるはず。
> port test ===> Validating port with portlint WARN: Makefile: only one MASTER_SITE configured. Consider adding additional mirrors. 0 fatal errors and 1 warning found. ===> flags: PREFIX=/tmp/nuff-1.2.1 NO_DEPENDS=yes PKG_DBDIR=/tmp/pkg_db.AsuvZDmw ===> Cleaning workspace before port test ===> Cleaning for nuff-1.2.1 ===> Extracting for nuff-1.2.1 => MD5 Checksum OK for nuff-1.2.1.tgz. => SHA256 Checksum OK for nuff-1.2.1.tgz. ===> Patching for nuff-1.2.1 ===> Configuring for nuff-1.2.1 ===> Building for nuff-1.2.1 cd: can't cd to /usr/home/cherry/svk/ports/net/nuff/work/nuff-1.2.1 *** Error code 2
おっと、エラーが出てます。cdできないと言っているので確認してみると、展開したディレクトリ名(nuff)がportsの期待するディレクトリ名(nuff-1.2.1)と異なっているのが原因。
> ls work nuff
このパスはWRKSRCとしてbsd.port.mkで定義されている。defaultは${WRKDIR}/${DISTNAME}。これを上書きしてしまえばよい。
WRKSRC= ${WRKDIR}/${PORTNAME}
この例のように、とにかく変数を使うこと。hard-codeしてしまうとアップデートのときや修正のときに書き換える場所が増えてしまう。
再度挑戦。
> make clean && make ===> Cleaning for nuff-1.2.1 ===> Extracting for nuff-1.2.1 => MD5 Checksum OK for nuff-1.2.1.tgz. => SHA256 Checksum OK for nuff-1.2.1.tgz. ===> Patching for nuff-1.2.1 ===> nuff-1.2.1 depends on executable: gmake - found ===> Configuring for nuff-1.2.1 ===> Building for nuff-1.2.1 gmake: Makefile: No such file or directory gmake: *** No rule to make target `Makefile'. Stop. *** Error code 2
まだダメ。Makefileが見つからないと言ってる。そうそう、MakefileではなくてGNUmakefileだったっけ。実行するMakfileのファイル名はMAKEFILEで定義されている。defaultは当然Makefile。これも上書きする。
MAKEFILE= GNUmakefile
3度目の正直。
> make clean && make ===> Cleaning for nuff-1.2.1 ===> Extracting for nuff-1.2.1 ... mv src/nuff .
はい、makeが通りました。次に、do-install targetをGNUmakefileを参考にしながら自分で書く。よーするに、いくつかのディレクトリを作成して、ファイルをそこにコピーしているだけ(なぜかnuffバイナリはコピーされてない)。が、このインストールにも注意が必要。どこに何をインストールするかがそのdistributionのポリシーと大きく関わってくるから。まずはhier(7)を読んで、ディレクトリ構造とそれぞれの意味について理解する。/usr/local以下については書かれていないけれど、よく読むと/usr以下に準拠すると書いてある。なので、bin/sbin/etc/share/docs/examplesに何をインストールすればよいのか理解すること。ここで関わってるのは、shareとdocs。ffunとcodeは${PREFIX}/share/${PORTNAME}に、docs以下は${PREFIX}/docs/${PORTNAME}以下にインストールすればいい。このパスも、DATADIR、DOCSDIR変数として定義されている。で、インストールにはcp(1)を使ってはいけない。cpはファイルのパーミッションやuid/gidをそのままコピーしてしまうので、もしupstreamが適当なパーミッションやuid/gidを使っている場合、それがそのまま使われてしまう。なので、必ずinstall(1)を使うこと。で、このinstall(1)も変数が定義されている。バイナリ実行ファイルにはINSTALL_PROGRAM、スクリプトにはINSTALL_SCRIPT、通常のデータにはINSTALL_DATA、manにはINSTALL_MANなど。で、この変数を使ってインストールすればいい。
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/nuff ${PREFIX}/bin/
これで実行ファイルはインストールできる。次に各種データファイルと文書。しかし、以下の例はうまく動作しない。*によるファイル名の展開が行われないのが原因。リテラルな${WRKSRC}/ffun/*がinstall(1)に渡されてしまう。
${INSTALL_DATA} ${WRKSRC}/ffun/* ${DATADIR}/
どうするかというと、make(1)のforを使う。
NUFF_SCM= compiler.scm describe.scm dispatcher.scm dns.scm
format.scm hashtables.scm init.scm layers.scm \
mapasync.scm nuff.scm nuffopen.scm queue.scm \
sched.scm tlists.scm unixopts.scm
do-install:
.for F in ${NUFF_SCM}
${INSTALL_DATA} ${WRKSRC}/ffun/${F} ${DATADIR}/
.endfor
しかし、もっと便利な変数がbsd.port.mkにはある。それがCOPYTREE_*。これを使えば、あるディレクトリ以下をまとめてインストールできる。注意すべきなのは、COPYTREE_*が呼ばれるカレントディレクトリによって、インストール先のディレクトリ名も変わること。また、Makefileの中では、カレントディレクトリを変更できるのは、1つのコマンドでのみ。そのコマンドの実行後にはもとのディレクトリに戻る。なので、1つのshellでディレクトリの移動とコマンドの実行を行う必要がある。つまり、(cd ${DIR} && command …)とする必要がある。
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/nuff ${PREFIX}/bin/
( cd ${WRKSRC} && ${COPYTREE_SHARE} ffun ${DATADIR}/ )
( cd ${WRKSRC} && ${COPYTREE_SHARE} code ${DATADIR}/ )
( cd ${WRKSRC}/docs && ${COPYTREE_SHARE} . ${DOCSDIR}/ )
> port test ===> Validating port with portlint WARN: Makefile: only one MASTER_SITE configured. Consider adding additional mirrors. 0 fatal errors and 1 warning found. ===> flags: PREFIX=/tmp/nuff-1.2.1 NO_DEPENDS=yes PKG_DBDIR=/tmp/pkg_db.0TzmDUrq ===> Cleaning workspace before port test ===> Cleaning for nuff-1.2.1 ... ===> Checking pkg_info nuff-1.2.1 Scheme-based low lovel networking framework ===> Checking shared library dependencies ===> Deinstalling for net/nuff ===> Deinstalling nuff-1.2.1 ===> Extra files and directories check bin/nuff share/doc/nuff/C_API share/doc/nuff/LICENSE share/doc/nuff/TS_BUILDING ...
“Extra files and directories check”以下の出力が一時ディレクトリにインストールされたファイル名。これをそのままpkg-plist(インストールされるファイルの一覧)に書く。
> head pkg-plist @comment $FreeBSD$ bin/nuff share/doc/nuff/C_API share/doc/nuff/LICENSE share/doc/nuff/TS_BUILDING share/doc/nuff/TS_CHANGES share/doc/nuff/TS_COPYING share/doc/nuff/TS_HACKING share/doc/nuff/TS_MANUAL share/doc/nuff/TS_TRIBUTE
これでうまくいくはずなのだけど、port testの前にportlintを実行してみる。
> portlint -abt WARN: /usr/home/cherry/svk/ports/net/nuff/pkg-plist: [3]: If and only if your port is DOCSDIR-safe (that is, a user can override DOCSDIR when building this port and the port will still work correctly) consider using DOCSDIR macro; if you are unsure if this this port is DOCSDIR-safe, then ignore this warning
なんか大量に警告が出てます。ようするに、pkg-plistでも変数使え、ということ。Makefileの中で${FOO}として使えた変数は、%%FOO%%になる。これをさっそく修正。vimなら以下のコマンドで一発置換できる。
:%s#share/doc/nuff#%%DOCSDIR%%# :%s#share/nuff#%%DATADIR%%#
再度挑戦。
> portlint -abt WARN: /usr/home/cherry/svk/ports/net/nuff/pkg-plist: Both ``%%PORTDOCS%%@dirrm %%DOCSDIR%%'' and ``%%PORTDOCS%%@unexec %D/%%DOCSDIR%% 2>/dev/null || true'' are missing. At least one should be used. WARN: Makefile: use ".if !defined(NOPORTDOCS)" to wrap installation of files into /usr/local/share/doc. WARN: Makefile: only one MASTER_SITE configured. Consider adding additional mirrors. 0 fatal errors and 3 warnings found.
まだ文句言われています。1番目はDOCSDIRの適切な削除方法、2番目はNOPORTDOCSが定義されているときは関連文書をインストールしないようにしなさい、3番目はファイルの配布サイトが1つしか指定されてない、という警告。最後はともかく、2つは修正しましょう。
まずは%%DOCSDIR%%で始まる行を%%PORTDOCS%%%%DOCSDIR%%に置換。vimなら以下のコマンド。
:%s#^%%DOCSDIR%%/#%%PORTDOCS%%%%DOCSDIR%%/#
同様にdirrmにも%%PORTDOCS%%を追加。
%%PORTDOCS%%@dirrm %%DOCSDIR%%
で、Makefileの文書のインストール箇所に条件を指定。
.if !defined(NOPORTDOCS)
( cd ${WRKSRC}/docs && ${COPYTREE_SHARE} . ${DOCSDIR}/ )
.endif
これで、ユーザがNOPORTDOCS=yesしている場合は、文書はインストールされない。なぜこういうオプションがあるかというと、組み込みなどのディスクスペースに余裕がない場合は、実行に不要なファイルはインストールしない、という選択肢をユーザに与えるため。
> port test ===> Validating port with portlint WARN: Makefile: only one MASTER_SITE configured. Consider adding additional mirrors. 0 fatal errors and 1 warning found. ... ===> Checking pkg_info nuff-1.2.1 Scheme-based low lovel networking framework ===> Checking shared library dependencies /lib/libc.so.6 /lib/libm.so.4 /lib/libpcap.so.4 /usr/local/lib/libdnet.so ===> Deinstalling for net/nuff ===> Deinstalling nuff-1.2.1 ===> Extra files and directories check ===> Cleaning up after port test ===> Cleaning for nuff-1.2.1 ===> Removing existing /tmp/nuff-1.2.1 dir ===> Done.
“Checking shared library dependencies”でlddの結果も出ている(ここではすでに確認したけど)。余分なファイルが残っていなかったら、これでOK、ではなくて、依存関係がまだ足りない。port testでは依存関係のテストが省かれているので、自分で依存関係の指定と確認をする必要がある。
依存関係にはいくつかあるけれど、多用するのはBUILD_DEPENDS(コンパイル時に依存)、RUN_DEPENDS(実行時に依存)、LIB_DEPENDS(ライブラリの依存関係)。ここで依存しているのはlibdnet。書式は”$NAME:$DIRECTORY”。$NAMEにはPOSIXの正規表現が使える。以下をCOMMENTの後ろに追加。
LIB_DEPENDS= dnet:${PORTSDIR}/net/libdnet
正確にはgmakeにもBUILD_DEPENDしているけれど、これはUSE_GMAKEがよきに計らってくれる。実際に依存関係でlibdnetがインストールされるかを確認。
# pkg_deinstall -f libnet-1.11_1 ... # make
実際にインストール。
# make install package clean
正常にインストールできれば成功。で、実際に実行できるのかテスト。
> nuff FATAL: Unable to locate NUFFDIR
おーっと。コンパイル時にNUFFDIRを定義しておかないといけないんだった。インストールしたのは${DATADIR}だから、これをMAKE_ARGSに追加すればいい。
MAKE_ARGS= PCAP_INCDIR=/usr/include PCAP_LNKDIR=/usr/lib \
DNET_INCDIR=${LOCALBASE}/include DNET_LNKDIR=${LOCALBASE}/lib \
NUFFDIR=${DATADIR}
もう一度インストールし直して、実行。
# make deinstall && make clean && make install ... > nuff nuff - the Network Universal Frame Forge - by Doug Hoyte [nuff kernel v1.2.1] [nuffdir /usr/local/share/nuff] ^D > nuff resolve -- example.org example.org 208.77.188.166
成功。
おっと、まだpkg-descrが空っぽだ。pkg-descrはそのportの簡単な説明。COMMENTより長くてもいい。72行程度で改行すること。vimならVで範囲指定して!fmt -w 72。WWWにはサイトのURLを。
> cat pkg-descr Nuff is the Network Universal Frame Forge. Nuff bundles together a scheme interpreter, low-level bindings to unix networking interfaces, and powerful scheme functions and macros for dealing with network packets. WWW: http://hcsw.org/nuff/
最後にMakefileのコメントを削除する。最終的なMakefileはこうなる。
# New ports collection makefile for: nuff
# Date created: 2008-06-01
# Whom: Tomoyuki Sakurai <cherry@trombik.org>
#
# $FreeBSD$
#
PORTNAME= nuff
PORTVERSION= 1.2.1
CATEGORIES= net
MASTER_SITES= http://hcsw.org/nuff/downloads/
EXTRACT_SUFX= .tgz
MAINTAINER= cherry@trombik.org
COMMENT= Scheme-based low lovel networking framework
LIB_DEPENDS= dnet:${PORTSDIR}/net/libdnet
USE_GMAKE= yes
MAKE_ARGS= PCAP_INCDIR=/usr/include PCAP_LNKDIR=/usr/lib \
DNET_INCDIR=${LOCALBASE}/include DNET_LNKDIR=${LOCALBASE}/lib \
NUFFDIR=${DATADIR}
WRKSRC= ${WRKDIR}/${PORTNAME}
MAKEFILE= GNUmakefile
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/nuff ${PREFIX}/bin/
( cd ${WRKSRC} && ${COPYTREE_SHARE} ffun ${DATADIR}/ )
( cd ${WRKSRC} && ${COPYTREE_SHARE} code ${DATADIR}/ )
.if !defined(NOPORTDOCS)
( cd ${WRKSRC}/docs && ${COPYTREE_SHARE} . ${DOCSDIR}/ )
.endif
.include <bsd.port.pre.mk>
.include <bsd.port.post.mk>
ここまでできたらsend-pr(1)。といっても、porttoolsにはsubmitというサブコマンドがあって、そいつがtemplateまで作ってくれる。新しいportをsubmitするなら、ほとんどすることはないといってもいい(既存のportに対するpatchの場合は、問題点を説明したり、適切なSynopsis:を書く必要がある)。Description:はpkg-descrからコピーしてくれるし、shar(1)ファイルも自動的に生成してくれる。
> port submit
エディタを終了すれば、PRが送信される。あとは、GNUTS(FreeBSDで使われているbug tracking system)からの連絡を待つのみ。そのうちcommiterが不具合の指摘やcommitをしてくれる。commitされたら、あなたがmaintainerです。upstreamのリリースやbug reportに目を通して、アップデートやpatchの適用をします。
最後に、これでOKかというとまだ改善点はある。CFLAGSが反映されていないとか、インストール後にユーザになんらかのメッセージを表示するなど。このportはsimpleだったけど、それでもそれなりに手がかかります。慣れればどうってことないんですが、それでもややこしいパッケージはいろいろある。それから、bsd.port.mkをはじめとする/usr/ports/Mk以下のMakefileがマニュアルみたいなものなので、これを読んで勉強しましょう。ということで、がんばってsend-prしてみてください。そうすれば、使ってくれた人がbugを報告してくれるかもしれないし、portを書いた人がいなくなっても誰かが面倒見てくれる*かも*しれない。send-prしないにしても、site localなパッケージをportにしておくことには意味がある。どのようにbuildしたのか文書化できるし、VMSにつっこめば履歴も管理できる。そして、puppetで管理することもできる、といいことたくさん。野良buildは20世紀のバッドノウハウです。
Happy porting!
Puppet Module Dojoをやります。
使いまわしのできるmoduleは、管理を効率化するだけでなく、他のひともそのmoduleの恩恵に預かることができます。moduleを書いたり、持ち寄ったmoduleやclassのpeer reviewを行います。可能であれば、reviewしたmoduleを公開(予定)のrepositoryで共有していただけると幸いです。Dojoですが、一方通行で「教える」「教わる」形式ではなく、お互いの知識を共有するのが目的です。とはいえ、Puppetを使っているひとなら誰でも参加可能ですのでお気軽に。Puppetの基礎は触れませんので、ある程度Puppetを使っているひとが対象になります。事前に、Module Organisationに目を通しておいてください。
場所は渋谷の「びぎねっと様 9Fセミナールーム」で、日時は4月29日(火) 15:00です。
参加するにはコメント、IRC、メールその他でご連絡ください。定員は10名程度ですのでお早めにどうぞ。いつもどおり、終了後の懇親会もあります。
近いうちにPuppet Module Dojoなるものをやろうかと考えてます。4月の中旬から下旬あたり。内容は、各自が持ち寄ったmoduleをpeer reviewしたり、すでにあるclassをmoduleに変更してみんなで幸せになったり、moduleがサポートするOSやdistributionを増やしたりする。Dojoといっても講義形式ではなくて、どっちかというと相互扶助のpico-hackathon。
できれば軽く飲食ができるような場所で、コンセントが使えて、会議室っぽい部屋。みなとみらいのBLENZ GENTO YOKOHAMA店には貸切にできるそんな部屋があるんだけど。「こんな場所あるよ」とかあれば教えてください。各自のlaptopは必須、Puppetが動作するlocalもしくはremoteの環境も必要。インターネット環境はあれば可。なくても有線もしくは無線LANのAPを持ち込んでなんとかします。時間は2時間くらいで、10人くらい集まると仮定して予算はひとり1000円程度で10,000円かな。テキストとかはなし。参加資格は特にないけど、Puppetの基礎は押さえておいてほしい。使っているdistributionをある程度使いこなしていて、そのパッケージ管理システムについて理解しているのが望ましい。
参加してみたいひといますか?
apacheは生きてたけど、backendのDBが死んでました。Nagiosとかもそのホストで動いていたのでアラートも上がらず。帰宅後にコンソールを見てみると、bootの途中で使っていないRAIDコントローラが「RAID arrayが未設定だよ!」とprompt出して止まってました。あー、もう。
syslogに何も出てないし、監視用のRRDとかもそのホストで動いてたので、死んだそもそもの原因も不明。きっと愛情が足りないのが原因だ。
冗長化するにも電源がそろそろ限界だし、これ以上常時起動しているホストは増やしたくないし。困った。
512bytesを越えるDNS queryもしくはreply messageはTCPにfallbackするんだけど、UDP 53をallowしてTCP 53をdenyしてると、当然名前解決ができない。そもそもTCPはoverheadがでかいので、message sizeは512bytesに納めるのが鉄則(yahoo.comのMXを引くと、authority sectionを入れても511bytes)。
じゃ、512bytes以内なら大丈夫かというと、落とし穴が。最近はMTAでTXT RRを参照することが多いからか、MXだけでなく他のRRも一緒に引こうとしてなのか、よくわからないけどANYでqueryを投げる実装がある