SVX日記
2005-10-10(Mon) 絶対無保証サポートという仕事
オイラが転職して、3ヶ月と少し過ぎた。プログラマという絶対保証が必要な仕事から、Linuxのサポートという絶対無保証(ABSOLUTELY NO WARRANTY)なプロダクトをサポートするという仕事に移ったワケだが、意外とコナせている……少なくとも本人はそう思っている。「Linuxに関しては完全なる趣味人」であったのだが。まぁ、前回の転職の時の「IT業界に関しては完全なる趣味人」の時に比べればマシかもしれないが。
日々、お客さんからは、アレがワカらん、コレはナンだ、ソッチがオチた、コッチがカタマった……などと、怒涛の質問攻撃が押し寄せてくる。別に「そんなのどーでもいーじゃん」なんて思う質問もあるが、お金を取っている以上、回答しないというコトはありえない。必死で調べて、答える。それによって、LinuxというOSについての理解を深めていくコトることにつながるし、また、質問が来るより先に理解の曖昧な部分について積極的に理解を深めていこうという意識につながる。
プログラマはガンガンとモノを作るという仕事で、とても楽しかったが、いかんせん、作業スパンがとても長い。数ヶ月単位の時間をかけ、モノを作る。数ヶ月経って動かしてみて、動かないと地獄である。バグなんてものは、作り方が悪いと、絶対に直らない場合もある。いわゆる、作り直したほうが早いという状態である。あいにく、そういうモノを作ったことはないが、そういうモノを作り直したことはある。あれは、ハードな日々だった。必要以上にガッチリとしたプログラムを作るという経験は、非常にイイ経験にはなったが。
そういう意味では、今の仕事はとてもスポポンである。例えるなら派出所だろうか? 道案内から、殺人事件、なにしろ突拍子もない問題がどんどん降りかかってくるような状態。しかも、ありきたりな問題は事前にフィルタリングされるので、あまりこない。どれも、それなりに手応えのある事件ばかりである。ある意味、こういう「飽きにくい仕事」を求めているオイラであったから、実はかなりピッタリなのかもしれない。プログラマのように数ヶ月スパンでハマり込むことはなく、ほとんどの問題は一週間以内に解決する……というか一週間以内で解決しなければならないから、アトクサれがないのもいい。プログラマという前歴も、適度に生かすことがデキるしね。
しかし、アレだ。奇妙なのは「絶対無保証なプロダクトをサポートする」という点である。LinuxはGNUの精神が基本であるから、タダだよ、プログラムの中身も勝手に見ていいよ、バグがあったら直すけど、直すかどうかは保証しないよ、もちろん使って何かが起こっても知らない……そんなプロダクトである。だからそのサポートも、ホントに真の意味でのサポートである。面倒は診るけど、解決するかどうかは保証しないよ……てなもんである。まぁ、あまりに役に立たないサポートであれば、競争他社に淘汰されてしまうから、そうはいいつつも、スルドい回答を返すべく、日々ガンバっているのだが。
まー、そういうGNUな大原則も、一部のお客さんには理解してもらえず、まれにコジれたりするコトもあるのだが、それはまぁ、お互いに不幸であったといえよう。自身が努力して補完しない場合は、これほど「タダより高いモノはない」というコトワザが当てハマるモノもないのである。
さて、そんなこんなで、ウチのサーバである。今のDebianにリプレースしてから1年以上経つが、ひとつだけ大きな問題を抱えていた。RedHat7.2の時には実現できていた「Sambaによるプリンタ共有」が、どうしてもウマくいってなかったのである。しかし、ヒトサマのLinuxの面倒まで診るようになって3ヶ月強。いい加減に、どーにかするべきではないか。医者の不養生ではないが、我ながら少しハズかしいのである。ちゅーわけで、ひとつ取り組んでみる。
以前はSamba側に問題があると思っていたが、この数ヶ月の実戦で、そんなレベルからはスッカリとキレイに脱出できている。swatを一通りイジって「/tmp」の下にプリントデータが生成され「/var/spool/lpd/lp」の下にデータがスプーリングされることを確認。lpqの実施により、プリントキューの状態が正しいことを知る。ココまでできていれば、Samba側の問題ではない。
こーなると、問題はlpデーモンの先だ。「/etc/printcap」の中を見てプリンタの設定を確認する。ヘンなトコロはなさそうだ。じゃ、デバイスか? 「cat /var/spool/lpd/lp/xxxx > /dev/lp0」でデバイスに直接データを送ってみる……なに? 「-su: /dev/lp0: No such device or address」とな? ちゅーことは、デバイス自身がおかしーんじゃねーか。こーなれば、起動ログの確認である。「dmesg | less」して「lp」関係のログを探す……あった!! 「lp: driver loaded but no devices found」コレだ!! ドライバはロードしたけど、デバイスがないよ、だってなんてこったい!!
こういう場合に役に立つのが、ちゃんと動いている別のマシンである。クラッシュダンプを取るためにFedoraCore4をインストールしつつ、放置してあったマシンの起動ログを確認すると「parport0: PC-style at 0x378 [PCSPP(,...)]」「lp0: using parport0 (polling).」なんていうログがある。自然にlp0が有効になっている。こりゃ、BIOSの設定でもマズいのかしらん?
Debianサーバは、このSVX日記のWebサーバであるから、あまり落としたくはないので、できるだけ手早く作業し、あとでゆっくり検討できるようにデジカメを片手に、バチバチ画面を撮影しながらBIOSの設定をイジる。やはり、プリンタポートはデフォルトの正しい設定になっているようだった。最近のプリンタは双方向通信がデキるのだが、それが有効になっている。しかし、無効にしたからといって何も変化しない……ちょっと煮詰まってきた。関係するページをググる……コレか? プリンタの双方向通信ドライバのカーネルコンフィグってヤツ?
そういえば、ウチはキャプチャカードSAA7133を使うために、見ヨウ見マネでカーネルパッチを当てたりして、妙なカーネルを使っている。見ヨウ見マネで「make menuconfig」もしたので、一部のドライバの組み込みを外してしまったかもしれない。しかし、今、快調に動いているカーネルをまるごとコンパイルするのは勇気がいるなぁ……そっか、モジュールとして組み込めばいいのか? よっしゃ。
「make menuconfig」して「Parallel port support」の下に下りて「PC-style hardware」チェックを「M」にする。そうしておいて、抜く手を見せずに「make dep」「make modules」「make modules_install」「depmod -a」「modprobe parport_pc」と怒涛の攻撃である……するとなんと、その場でsyslogに「parport0: PC-style at 0x378 [PCSPP(,...)]」「lp0: using parport0 (polling).」が現れ、それと同時に、つないだプリンタが動き始めたではないか!! キューに溜まっていたプリントテストのデータが吐き出された瞬間、1年越しの解決である!!