_ うーん、--with-included-apr がないと configure でコケる。なんでだろ。インストール済みの古いバージョンの APR を参照しちゃってるのかな。めんどくさいので、深くは追求しない。
_ とりあえず make まで。入れ替えは後で。
_ ちょとまて。太田純監修ってどういうことだ。rogue 風味じゃなくて、ほんまもんの rogue を PS2 で出すのか? 正気か? てゆーか最近 fj 見てないんだけど太田さんは今なにやってんの。
_ とりあえず1ヶ所だけツッコミ入れたい。
ローグは80年代にコンピューターのキー操作の習得用ソフトとして開発され、ちげーよ!_ ひさしぶりにインストールしてみた。もちろん太田さんの移植した日本語版。なつかしすぎ。地下7階でケンタウロスと戦いて死す。
_ (1/28 追記) キー操作うんぬんのくだりは修正されたようです。そりゃあんまりだ、とツッコミメールを送った:-)という方に教えていただきました。てゆーか、rogue をやると vi で yubn で斜め移動したくなっちゃうからキー操作習得用には使えないんだよ。
_ 覚えなきゃいかんのは、何よりもまず先に C-h t(と、そこに書いてあること)だろう……。最低限これだけ覚えれば、とりあえず基本的なことはできるようになるはずだし、そんな基本的なことを誰かのページを参照しなくても済むはずなんだけどなぁ。最近の入門書って C-h t について触れてないのかしらん。
_ と、vi 使いは吠えるのでありました。そろそろ jvim3 を捨てて本格的に vim7 に移行せんとなぁ。
_ ちなみに、emacs -nw で起動したときにメニューにアクセスするには M-` ね。
_ そういえば、apache 2.2.4 に入れ替え完了してます。とくにトラブルもなく。つまらん。
_ 今朝の 朝日社説。あしたの朝には消えるので冒頭部を引用。
「たかが7円」だろうか。この後もぐだぐだ続くけど、これ以上のことは言ってない。同じようにユニバーサルサービス制度の負担金を利用者に転嫁しないで企業努力で吸収しろ、という意見は朝日の記事を取りあげる必要もなくこれまでほかにもいっぱい見てるので今さらなんだけど、まあいい機会なので。
全国に張り巡らされた固定電話網の赤字の一部を埋めるため、一つの電話番号ごとにかかる新たな負担だ。電話会社はその全額を利用者に払ってもらおうとしているが、それはおかしい。まず経営努力で吸収するのが筋だ。_ わしの意見はまったく逆。利用者に転嫁して何が悪いの?
_ もちろん経営努力で無駄なコストを削減して利用料金を下げるようにしてもらわなくちゃいかんのは間違いのない事実だ。でも、そうだとしてもその努力で下げるのは通常の利用に対する料金の方であるべきで、ユニバーサルサービス維持のための負担金の方はそれとは別勘定であるべきなんじゃないか。自分が使った電話料金と僻地の誰かのためのユニバーサルサービス負担金はまったく性質の異なるものであって、それをドンブリ勘定で区別なく一括請求される方がずっとおかしい。負担金7円を上乗せ請求します、そのかわり基本料金を7円値下げします、というのが最上であり、そういう方針を取らなかったことを批判するのならば異論はないのだが、この朝日社説はそう言ってないし、利用者転嫁に反対するほかの意見でも見たことはない。
_ 僻地の電話網維持のために赤字が出るのはしかたないけど、赤字を補填する制度があると、NTT 東西はそれに甘えて赤字幅を圧縮する努力を放棄して基金に頼ってしまうのではないか、という懸念は大いにある。
これを利用者から別に取り立てると、効率を良くして赤字を吸収しようという緊張感が失われる。各社はもっと経営努力をすべきだ。朝日はこういうけど、利用者に転嫁されずに請求されるより、転嫁されて毎月7円を払っていると目に見えている方が、利用者自身が制度に自覚的になるだろうから、監視の目が厳しくなってむしろ緊張感が増すんじゃないかと思うんだがどうか。つーか、「効率を良くして赤字を吸収しよう」と一文で書いてるけど、効率をよくするのは負担金を払う通信会社(含 NTT)であり、赤字を吸収するのは負担金から補填を受ける NTT で、両者の主語が異なるはずなんだけど、なんかごっちゃになってないか。_ ユニバーサルサービスの提供義務を NTT 東西にだけ押しつけていいのかとか、固定電話だけで携帯その他はこれからもユニバーサルサービスの範囲外でいいのかとか、考えなきゃならんことはまだまだある。そんなとき、利用者が自分で払ってるという自覚のある方が今後の議論のためにはきっと有益だと思う。
_ \
_ FreeBSD の ports を root 以外のユーザで管理する方法。ports のしくみ自体は平ユーザで使うことをちゃんと考慮してるのに、実際の方法はあまり知られていないみたい。
_ 以下箇条書きにて。
- ports の管理は su または sudo を実行できる(wheel グループに所属している、もしくは sudoers で指定されている)平ユーザでコンパイルからインストールまで可能。
- sudo chown -R hoge /usr/ports/ して、ports ツリー全体が hoge ユーザの所有にする。あるいは ports ツリー自体を ~hoge/ports/ あたりに置いて /etc/make.conf で PORTSDIR を設定すればいい(はず。やったことない)。
- 基本的にはこれだけ。平ユーザのまま make install すると、勝手に root パスワードを聞いてきて、root としてインストールを実行する。そのほか、make config でオプションを /var/db/ports/ 以下に保存するときや、make deinstall なんかも自動的に su してくれる。
- デフォルトでは su が使われ毎回パスワードを聞かれるが、/etc/make.conf に SU_CMD=/usr/local/bin/sudo /bin/sh -c と書いておくと、sudo を使うようになる。
- /etc/make.conf 自体は root の所有なので、平ユーザはいじれない。以下を make.conf に書いておくと、ports のコンパイルのときだけ /usr/ports/Mk/local.conf を読んでくれるので、ports の設定はこっちに書くと平ユーザでも安心。
.if ${.CURDIR:M/usr/ports/*/*} != "" && exists(/usr/ports/Mk/local.conf) .include "/usr/ports/Mk/local.conf" .endif- csup (cvsup)、portsnap のいずれを使う場合でも、平ユーザで ports ツリーの更新は問題なくおこなえる。もちろん、/var/db/portsnap などの権限は開けておく必要あり。
- portupgrade を使う場合は引数に -s を加えておくと、${SU_CMD} をいじらなくてもインストールや古いパッケージの削除の際に sudo してくれる。
- portmaster は root で実行することしか考慮していない。portmaster でも make install や make config は ports 自体の機能として平ユーザで実行できるが、旧バージョンの pkg_delete や依存情報の更新ができずにコケる。ということで、 パッチ。
- ほとんどの ports でこれでうまくいくが、一部のお行儀の悪い ports ではうまくいかないものもある。必要に応じて root 権限を得るしくみがある以上、個々の port の作りが悪いと言ってしまっていいと思う。
- 必要に応じて自動で root になってくれるが、make install 直前のインストール準備処理のときには root にならない。そのため make pre-install で root 権限が必要な作業をする ports はコケる。専用ユーザ/グループを追加する ports に多い。ユーザは追加しないけど lang/ruby18 もこれでコケる。make install で自動で root になってくれる機能に頼らず、sudo make pre-install すればうまくいく。
- インストールに cp -p を使っているものがある。平ユーザでコンパイルした場合、cp -p したらインストール後も平ユーザの権限のままになってしまう。コケないけど、hoge 所有のままのファイルがインストールされてキモい。net/samba3 とか。セキュリティ的によろしくないけどたいていの場合は動作に不都合はない。
_ わしはこの方法でもう数年使ってるけど、ほとんど問題は出ていない。というわけで、いらん root は使うな。
_ APNIC しっかりしろよ。最近のコケた記録。
- 2007/01/18 2406:8000::/32
- 2006/12/14 2001:07fa:0007::/48
- 2006/08/10 203.191.234.0/24
- 2006/08/08 203.90.19.0/24
- 2006/06/01 IPv6 たくさん
- 2006/05/17 121.2.0.0/16
- 2005/10/23 IPv4 たくさん
_ 上位 DNS からの委譲関係が消えちゃうと、自分では DNS をちゃんと設定していても外部から解決できなくなる。どうしても必要な理由があるわけでもないのに DNS に頼っていると、DNS がコケたときの影響範囲が大きくなってしまう。けっして逆引きにかぎったことではないのだが、たいていの場合正引きはどうしても必要なので頼らざるをえないのに対し、逆引きはとくに必須ではないことが多い。逆引きに頼らずに済ませることが可能ならばそうした方が障害に対して頑健になる。
_ 逆引きをやめろ、といってるわけじゃないので念のため。逆引きがコケるとうまく動かないような運用をしちゃいかん、ということ。