壊れたportsの適当な直し方

portsは、慣れないうちにリポジトリ操作のミス、更新手順の不備、手順前後、勝手な削除、継ぎ足しなどで、徐々に壊れて更新がままなくなることがある。　

一番多いのは、依存関係に矛盾が生じる削除。　pkgdb -F で、似たようなパッケージがあればそれに依存関係を接続しなおす作業が必要になる。

たとえば、あるパッケージが なんちゃらのm4が必要だとしよう。 でもこのm4は、自分の使いたいm4と違って文法エラーが出まくって、みなみ最近…イライラする（笑）・・・　というような時には、間違ってなんちゃらのm4をぶっ飛ばしてしまうかもしれない(訳注：pkg_deinstall なんちゃらのm4) ので、こういう時には、別のm4で接ぎ穂を足されなくてはならない。そうでもしないと単にportsdbを眺めるだけのportsversionすら追跡できない。

autotool辺りはこのバージョン違いが激しく存在し、autoconf-2.13から、autoconf-2.62までのすべてのバージョンを持っているシステムというのも、現時点では存在する可能性がある。
そして、それぞれのバージョンコンパチビリティが低いので、相互補完できず、こいつのwrapperがキチンと入るまで相当に混乱していた。　　3年位前まではそんなこんなで、荒馬のportsを乗りこなすのには、狭いパッケージ選択を余儀なくされていたが、wrapperの出現で管理はしやすくなったといえよう。　だが、未だにwrapperもなく、バージョンコンパチの無いシステムがおおい。

あと、ソースレベルから駄目なものの例として、OpenLDAP、bdbがあるだろうか。　bdbはバージョン4の中ならば、それほど違いが無いのだが、やはりデータベースのフォーマットが異なってるために、入れ替えれば、再構築がつき物である。　もちろん bdbは、単なるdbmに過ぎないから、物理的にむき出しになったファイルを管理する傾向が強く、やはり何かの管理・操作ミスで破壊されやすいことが良く知られているためか、練れたアプリケーション側には修復ツールが必ず付いてきて、データベースを自動的に直すようになっているので、めったに酷い目にはあわないのだが、やっぱりその自動修復には時間がかかり、最近イライラする！　という傾向にある。　また、OpenLDAPに至っては、2.1～2.4までインストール作業を行ってきて、そのたんびに ldifに落として入れなおす。　バイナリはもちろん、扱うデータ形式も変わってしまうのだから注意が必要だ。


こんなパッケージの状態に加えて重要なのが、portsそのものの健全性だったりする。
昔からあるのは、portsカテゴリの移動で、これに追跡が追いつかず、自動的なupgradeが頓挫するのを良く見たもんだ。

一般に、portsは放置していると腐ってしまい依存関係を無視してもコンパイルが出来なくなる。

であるから、まず一番重要なのは



１．新鮮なものを手に入れること。

　　2008年に2006年頃のportsイメージを広げても、その根拠になるhttp/ftpでアクセス可能なソース配布元が消滅している可能性がある。古いのは駄目だ。


２．OSバージョンとの絡み

　　バージョンが違えばportsの対象も異なる。 6.xがメインストリームになってから、4.xで動かないものは多々作られ、8.xがメインストリームになる頃には、6.xで動かない物だらけだろう。 6.xは幸い6.4で終わるので良い（4.x台が 11まで行ったのが異常）が。

３．OSマイナーバージョンで、portsの作法が変更されること。

　おそらく 6.xだけに起きた事ではないだろう。 6.2というここ5年の間ではかなり安定したバージョンのFreeBSDをインストールしたマシンでは、現行の6.4を想定したものが動かなくなりつつある。 インクルードファイルが追加されているので、 6.4に順次移行していく必要がある。


という具合である。　Xやphp 関連の話をすると、portsをキチンと管理しないと、Windowsのソフトウェア管理にも似た酷い状況があって、削除の嵐やら、強制アップデートなどという蛮行をしないと、もはやどうにもならないがこれについては別徒書くことにする。

ports install for server the newbies

新規FreeBSDサーバに ports 関連をきっちり入れていく手順について：

まず、要点から箇条書き。

・cvsup はもう要らない。

　どこかで、ezm3なんかが突っ込まれている場合は注意。
　FreeBSDソースツリーを取得するのには必要なcvsupだが、Modula-3の実装を
　必要とはしない。 csupがあるので、それを使うこと。


・csup も portsツリーの維持には不必要可欠。

portsnapも、不安定な回線にとってはあまりうれしくない場合がある。 Webキャッシュの誓で取れないケースがある。　とはいえ、csupを使うよりも手軽。 portsnapのミラーは、Googleとはいわないまでも、FreeBSDマシン1000台ベースの管理をするようになるまでは不要。

という点を踏まえてまずすべきは。

0. portsnap fetch
0a. portsnap extract

これには場合によっては30分くらいかかる。どちらも最初に長い時間を要する。
手近にcvsup-mirrorがたってれば、csup -L2 なんちゃら　で、手近なports-cvsupツリーを
拾ってくるのもあり。


1. /usr/ports/database/db4x の導入。

こいつが何故いるかというと、portsupgrade パッケージを入れるためだが、適当にやると枯れきったdb41辺りから入れてくるので要注意。　Berkeley DBは 長年使われたことと、私企業の製品(BSDライセンスによる使用を許すものだが）に転化したということもあって、配布場所の変遷著しいし、古いものは、メンテナンスされなくなるのではないかという危惧があって db46位にしている。

もちろん、最新のdb47もあるのだが、これは、OpenLDAPのportsで使っておらず、db46/db47が相乗りになって、管理がややこしくなるから入れない。

2. portsupgrade の導入

こいつがないと、 portversionなどの aquisitionが出来ないし、アップグレードもわずらわしい。 難点は、ruby/bdbの絡みがあるので、こいつらが更新されるときに死ぬこと。　もちろん自分自身（portsupgrade自体がportsで提供される)の更新もこける。　ので、最近では、portsmasterも入れて、相互補完する。

管理上、portsupgrade は、portsinstall/portsversion/portsupgrade の主要三形態を利用する。　んで、pkg_deinstallなんかを掛けた時に、矛盾が生じたら pkgdb -Fで修復である。

3. 後は好きなものを入れて行く。

私の好みから言うと、 smartmontools/jed/zsh/sudo/ipmitoolまたはmbmon は欠かせない。　これらはサーバの管理作業に必要な情報、操作手順を用意する。 zshを使うのはいろいろ便利な機能があるからで、csh由来のtcshが嫌いなのもちょっとある。　

portaudit また壊れた？

auditfile.tbz 100% of 51 kB 9185 kBps

portaudit: Database too old.

portaudit: Download failed.


おかしい。　何かがおかしい。

ぐーぐるに訊いてみる

　→　portaudit broken again

？？
　

Access200x と ワークグループ機能が如何に駄目かという

駄目だ。

こいつはもう駄目だ。

マイクロソフトの暗黒面は、Office20ｘｘに永遠に残されるのであろうか。

まかりまちがって、パスワードなんかつけてしまったり、ワークグループ設定をしてしまうと最後である。
理解しないで設定して、開けなくなる。　わなである。これは罠だ。　MCPを取れと言うのかっ！


・・・・・sigh

shell の文法

時々忘れて恥をかく。

Shellの文法を忘れて、酷い目にあう。


if [ ?? ] then

fi

なぜ覚えないか？　awkでやってしまうからだ。

FreeBSD portsの整理作業

FreeBSDを管理するのに、portsは避けることが難しい。

もちろん、無視して管理することは十分に出来る。　だが、portsを使ったほうが多くの関連を持つミドルウェア類を適切に管理していくコストが低くなることが多い。

これが、セキュアであるかはかなり微妙である。だが現実に多くのサーバ機材で稼動させるシステムを世代交代させていく過程では、徐々にバージョンアップしていく作業を続けていく方が、機材が壊れるたびに新しいパッケージを入れていくよりも、問題が少ないように思われる。　理由として、すでに発見された別の問題点が、ほかで影響が出たために解決されていないための回避策パッチなどが、長年、放置されることによって、”孤児”と化してしまうからである。　常に更新され続ければ、孤児はもちろんだが、セキュリティフィックスやOS更新に伴う挙動の変化を常に追い続けることも出来る。　OSが更新されたら、portsも新しくしないと構築すら出来なくなってしまう。

たとえば、6.2p9辺りで稼動していたシステムのportsを更新していて、最近、リリースOSバージョンが6.4に至った日以降、portsの更新でいくつかエラーが出るようになった。　bsd.options.mk など、includeファイル関連が変更されてきたからだが、こういう絡みがあるのもportsの問題でもあり、OS更新が先立って行われないと、portsに問題が出ることがようやく分かってきた。

squid+php+javascript+IE6.xで発生する怪現象

不思議な現象に出会った。

私が、某所でphpで作っているイントラネットのシステムである。ターゲット･クライアントがIEを想定しているのだが、こんな場合に問題がおきることが分かった。

1. squid を経由する
2. フレーム使っている。
3. メニューの枠からjavascriptで .phpなどのURLを読んで、中央フレームに表示する
4. IEである

この条件が揃ったとき、とある種類のPHPで作ったものが、中央フレームでレンダリングされず
ダウンロードされてしまう。　orz.

この現象に出くわしたとき、何がなんだか分からなかった。　cookieの関係でもないし、ポップアップブロックは解除されている。イントラネット設定なら、特に問題が無いはずだ。　Firefox内で、IE-TABを利用してIEのレンダリングエンジンを利用した場合や、IE直接でレンダリングした場合でも、必ずコンテンツがダウンロードされている。

この動作は、次のような条件を課することで、回避することが出来た。

• PHPファイル名を短め（８．３形式）に抑える。

最後の "/" から10文字程度のPHPスクリプトを、直接レンダリングすることは可能だが、
Javascriptで、URL指定し、ｓquidを経由した場合に、どうも上手く、対象URIからファイルの
情報受け取れなくなっている模様。　

もう少し調べてみないと、原因が分からない。　あまりにも発生する条件が狭すぎ、
原因となる場所が多すぎるからだ。　少なくとも squidを経由しなければ、発生しない。
squidを経由すると、なにやら情報が削られてしまうという感じはぬぐえない。

Webキャッシュは止めようかな～という気になる。