I, newbie » FreeBSDのportを書こう
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 -
I, newbie ? PerlでTCP 3way-handshake
3wayを生ソケットでやるのは基礎？ 「TCPの3wayを生ソケットでやるのは、セキュリティエンジニアの基礎である」という結論に至りました（ホントか？（笑））。ちなみに「tcp 3way raw socket」でググってみたのですが、日本語サイトは数えるほどしかヒットしませんでした（基礎なのに…）。まぁ基礎かどうかはおいといても、SYN floodというようなTCPの3wayを突く攻撃などもあるので、一度くらいはやってみても損はないかも…。 でも、raw IP socketってL4より上のレイヤしかいじれない。FreeBSDのip(4)によると”Outgoing packets automatically have an IP header prepended to them (based on the destination address and the protocol number
I, newbie » FreeBSD 7.0-BETA1から6.2-STABLEへダウングレード
ふつー、STABLEは次のRELEASEになるものなので、STABLEを使っていればBETA、RC、そしてRELEASEに自然に移行できるわけなんですが、major versionがからむ場合、そうはいきません。6-STABLEは7-RELEASEにはならんのです。また、7-BETAを試してみて問題があったら戻せばいいか、というのも通用しません。major versionのダウングレードはまったく無保証自己責任の世界です。CURRENTにもまだ入っていないパッチを当てつづけてしのいでいるデバイスドライバがある、という状況では簡単に移行してはダメ。まぁ、それでもヒトバシラーのさだめで、果敢に挑戦して残念な結果に終わるのもよくあること。 7ではgccが4.2で、6はgcc 3.4、つまり4.2では3.4でコンパイルできたソースもコンパイルが通らない。lang/gcc34を入れてmake.con
I, newbie » AsiaBSDConレポート速報
ちょっと酔いがさめるまで、まともな感想を書くのは控えることにする。メモはしっかりとっておいたので、あとで書く。 それでもやはりOpenBSDの勢いが止まらない。すげーよ、あのひとたち。 もし、明日参加する人がいるなら、気軽に声をかけてください。って、どの人かわからないかもしれませんが。日本人同士で固まっていない変な人がそうです。つーか、関東近辺に住んでいて、BSDに興味があって、参加を見合わせた人は、相当損したと思います。 P3: Support for Radio Clocks in OpenBSD OpenBSDのGPSアプライアンスを製品化しているMarc氏による無線クロックの実装ネタ。かなりコアなお話でついていけませんでした。ただ、単にデバイスをサポートするだけの話と思っていた自分の無知さ加減はよーくわかりました。地味にすごいひとだ。 P5: An ISP Perspective
I, newbie » ネットワーク管理者のためのPerl
またPerlの力を借りる必要が出てきた。自分はプログラマじゃないっつーの。プログラマと名乗るなら、はなくそほじりながら10分くらいで書いてよ。設立当初から培ってきた技術力とノウハウが泣くよ。つーことで、ネットワーク管理者のありがちな仕事をPerlで解決するシリーズ(になるはず)。 管理者の基本。subnetを切って、default gatewayを決める。簡単ですね。「10.10.1.0/24なら10.10.1.254でも使っとく?OK、じゃ、subnetの最後のIP addressということで統一しましょうか。CIDRの一覧ちょうだい。default gatewayの一覧作成しとくから」 > cat cidr.txt 10.10.0.0/23 10.10.2.0/24 10.10.3.0/24 > cat example1.pl #!/usr/bin/perl use strict;
I, newbie » サーバのテストって自動化してますか
設定を変えるたびに、意図した動作をするかどうか確認するのはよくある作業ですが、つまんない作業だし、手作業である限りほんとにテストをパスしたかは作業者に依存してしまう。Webアプリの世界ではそこそこ自動化されているようだけど、サーバ管理一般となると、あまり普及していないように見える。実際、自分も新しいサーバを作るたびに、手作業であれやこれや各種の確認作業をやっていた。でも、いいかげん21世紀なのだから自動化でしょ、とテストのスクリプトによる自動化をちょっと前から考えていた。 特定用途に特化したサーバの面倒だけなら、expectあたりでhackすればいいのかもしれない。けど、やりたいのはもっとgenericで、開発->テスト->本番環境で常にテストを実行できて、変更履歴も残せて、作業者の変更は上級作業者の承認を経ない限り本番環境に反映できないようなプロセス。stagingとauditはcfen
I, newbie » 大量にメールがキューにたまってしまったら
なんらかの理由で数万通単位でキューにメッセージがつまってしまった場合どうするか。 まずなにより最初にすべきことは、メールサーバの停止。原因がなんであれ、万単位でキューにたまっているなら、いったん止めなければ復旧作業もままならない。おそらくキューから大量のメッセージを削除することになるだろうし、Postfixはメッセージの状態に応じて、ファイルをあちこちのディレクトリに移動させるため、その際には激しいディスクアクセスをともなう。ゆえに、mailq1つ実行するのにもディスクに足を取られて、作業にならない。同じサーバでvirus scannerなんぞが動いていたら目も当てられないくらい動作に影響がでているはず。もちろん、相応のディスクを持っていてそんなの平気なら、止めずに作業ができるかもしれない。でもふつーは無理だと思った方がいい。サービスの停止に躊躇するかもしれないけれど、いずれにせよ大幅なメ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
I, newbie » IS_SRVROLEMEMBER(0x730079007300610064006D0069006E00)