えーと、うちのマシンはMac⇔FreeBSD⇔Winみたいな感じになっていて、WinかMacでナニかあっても、マシン間でデータのやりとりをしていれば、必ずFreeBSDサーバに残るようにして、バックアップのかわりにしてたりします。
で、FreeBSD⇔Mac間のファイル共有プロトコルをFreeBSDでフォローしてるのがnetatalkというやつなんでですが……。これが、ちょっと前から変なログを吐いてるんですよ。netatalkのログには何も残ってないんですが──と、いうかシステムログ側に「ログファイルが開けんかったよ」みたいな事が残ってるので、netatalkで何らかのトラブルが発生→netatalkのログに記録しようとするがファイルが開かない→システムのログに「afpd.c(****):netatalk.log:can't open log file」みたいな一文が残る、と。
これだけなら、今は忙しいので放置プレイ決定なんですが、ついに第2段階として、アクセスが異様に重くなりはじめたんですね。しかも、win側からsambaでアクセスしてるのまで、巻き添え食って重くなり出す始末。
心当たりは2つ。先日、メモリの換装したこと。もう1つは、その共有フォルダ自体が殆ど空き容量が残ってないということ。
(今更、メモリは戻したくないので)メンテナンス方針としては、共有フォルダの整理が第1段階、それでも解消しない場合は、netatalkのアンインストール、portsツリーを更新、最新版にリプレースという第2段階。
第1段階、効果無し。ディレクトリ構造をスキャンする時間自体は短くなった気もするが、それでも以前に比べると段違いに遅い。まるで、シリアルケーブルでP2P転送てるかのように遅い(笑)
ちょっと、腹をくくって第2段階へ突入。OpenSLPがないとかDESライブラリのリンクが切れてるとか、何度かコンパイルで弾かれるも、何とかインストール完了。
……が、PowerMacG4からAppleTalkでログインできない。つまり、netatalkが認証を受け付けない(T-T)
今までのVer.1.5.x系列の設定ファイルのままで1.6.x系にリプレースしたのが、どっかでひっかかっているのか、何か認証関連のファイルのパーミッションがダメよんという随分とまあ抽象的なエラーログしか残ってない。エラーログレベルを弄ってみたり、OpenSSLやらケルベロスやらnetatalkやら、システム全体のチェックを試みている時間はない。
なおちゃんが線画を待っている以上、早急に解決する必要があったので、計画は最悪の事態に備えて思い付いていた第3段階へ移行する。
……計画は単純だ。MacOS Xには、そのUnix上でNetBEUI を実装するSambaが標準でくっついている。従ってAppleTalkプロトコルをやめてSambaを使えば、MacからWinもFreeBSDもアクセスできる。
そこそこ安定しているマシンの設定はいじらない、というのがウチのガイドラインなので、Winの方の設定は現状を維持して、アクセス不能になっているMac⇔FreeBSD間の通信を復旧させるため、
Sambaの設定を、1か所かえる(MacのIPアドレスのアクセスを許可するようにしただけ)
で……
あっさり、とまあ、動きましたよ……。っちゅうか、netatalkイラナイじゃんか(泣