すんなりいく予定がいくつか躓きました。
○bashとyacc
ハンドブック通りに進めていってカーネルの作成後、grubをインストールして再起動までは問題なかったのですが、emerge –syncして足りないパッケージを入れたり最新状態にしていく途中でエラーが。emerge自体も動かなくなってかなり焦りました。
最初は何が問題かよくわからなかったのでやり直し、再度パッケージを最新にするとエラーが出始めるとわかりました。日本語ページを検索しても事例が出なく、英語ページで何とか同じ事例を発見しました。
原因はbashとyacc絡みでした。問題自体はyaccで、デフォルトでインストールされているdev-util/yacc-1.9.1-r4（もしかするともっと前からかも）とapp-shells/bash-4.2_p37（これももう少し前のバージョンからだと思います）の組み合わせが問題との事でした。
再度インストールCDから起動しなおし、インストールCD内のbashをコピーしたら問題なく動くことがわかりました。詳細の原因はかかれてませんが、問題なのはyacc側らしいので、代わりにbisonをインストールし、bashをインストールしなおしたら問題なく動きました。てか、何で最初からbisonじゃないんだろって思った。
○cracklibのコンパイルエラー
emerge -uDN world（俗称でうどんわーるどとも言われている)でパッケージを最新にしてるとcracklibのコンパイルでエラーとなりました。これはどうやらpython-updaterが実行されないと発生するらしいです。つか、新規インストールしたら必ず引っかかるのでは？とか思った。python関係は2,7系と3.x系が混在してインストールされる関係で引き起こされてるのか？とか思ったり。パッケージ管理ツールが2.7じゃないと動かないので引きずってるらしい。
まあ、一度動かせば難なく動くので、リブートしてパッケージ情報を最新にしたときにやっておくといいかもね。
あとはデフォルトのUSEフラグを調べて余計なパッケージが入らないようにしないと駄目か。既にcupsとか入っているのが何とも。Apache関係もこれから入れるので何かありそうな予感も。

久々にサーバにしてるGentoo Linuxを更新した。
今回はカーネルの更新があったのでリブートまで行いました。
毎回リブートは恐怖です。サーバは特に電源を落とすことも少ないので、HDDが再起動により故障するケースがあるのでディスクを認識してブートが始まるまでが特に。
うちのサーバはXを使用するグラフィカル環境はすべて消したので更新自体はそれほど大変ではありません。ソフト的に怖いのはスタティック・ダイナミックライブラリなどが更新された場合ですかね。コンパイル後にrevdep-rebuildでチェックをしてますけど、それでも何か問題があるのかとひやひや物です。今回、JPEG関係が置き換わっていて、eselect newsにも書かれていた。
Gentooは、使う環境やソフト次第ではハマってしましますけど、ローリングリリースタイプのディストリは魅力的に思います。

エラーの原因がわかった。接続とか送受信でエラーと思ってたら、レスポンスを解析して成功してないと判断してのエラーだったみたい。更新処理でwgetコマンドを動かして応答をpopenかけてそこから読み込んで戻されるHTMLを会席してます。応答で返されるのは、captcha認証ページが戻されており、2.1.9のクライアントソースでは強制更新が対応されてないという結論になりました。
検索すると自動更新の問題で悩んでる人も居まして、そこに書いてあるシェルスクリプトをいただくことにしました。これをcronで動かしておけば問題ないですし。

OpenRCのログが取れることを今更知った。
起動中にメッセージが出るのを何とか覚えて対処してたり、当該デーモンを単一で動かしてメッセージを確認してましたが、/etc/rc.confの設定でログを記録できる事がわかった。やはり/etc内の設定は全部確認しておかないと駄目ですね。

先日noip_updaterのソースを見て、強制的にIPアドレスを更新させる処理が動くようにしたバージョンのプログラムを動かしておきましたが、syslogを見てみるとどうも更新処理が失敗してるみたいです。
Can’t activate host xxxx.no-ip.com
こんな感じのエラーが出てました。
これだけではよくわからんので、デバッガを使って調べてみたいと思います。
まあ、動くのは一日一回なので動くまで待つしかないですが。

no-ip.comからツールが提供されてるので、特に問題はないのですが、光回線となるとIPアドレスもそれほど変わることがありません。ツールはIPアドレスの変更がないと更新しません。no-ip.comは一定期間更新が無いと、そろそろ消すぞメールを送ってきます。これまた面倒なのでこれを回避したくて模索してました。

方針としては、IPアドレスが変わってなくても一定期間で更新を行えばいいのですが、提供ツールでは駄目っぽかった・・・と思ったら、#defineの指定で強制更新が可能なことがわかりました。
Webを調べてると大抵の人はシェルスクリプトを作ったりしてそれをcronで実行してるという事例が多くてそれに従うしかないのか？と思ってたのですが、ソースを調べてみたら機能があったという。最悪、共有メモリを持ってるので、それを何とかすればと思いましたが、共有メモリはIPアドレスの変更には参照してないので駄目だった。

で、何を指定したら強制更新が出来るかというと、FORCE_UPDATEを指定すれば可能となります。コンパイル時に-DFORCE_UPDATE=1とすれば機能が動きます。デフォルトは30日後です・・・って長いよね。そこで、-DFORCE_INTERVAL=タイマ値（分単位で指定。1440で一日です）を指定すれば、この時間がExpireすると強制更新するというわけです。念の為、gdbで当該機能がちゃんと有効になってるか確認したら問題なさそうでした。また、当然IPアドレスが変われば更新されるので、万事解決となりました。めでたしめでたし。

・・・のはずでしたが、うちのサーバはGentooなのでこれまた悩むことに。
ツールはemergeで追加できるのですが、コンパイルオプションの指定は全く出来ません。なので、自前のebuildを作成してアップデートする必要がありました。まあ、自分でバイナリを作って上書きしてしまうのが楽なのですけど、万が一パッケージが更新された場合にアップデートしたのを忘れてると思うので、正攻法でいきました。
自分用のebuildを作成し、コンパイルオプション指定と思われるところに上記の指定を行い、emergeしてインストール完了です。

noip-updaterの細かい#defineの指定が出来ないので、野良ebuildを作ってインストールしてみました。
まず、ebuildのファイルを置くディレクトリの大本を決定します。うちは/usr/local/portageにしました。これを/etc/make.confへPORTDIR_OVERLAY=/usr/local/portageの設定を書き加えます。
Gentooはportage配下にカテゴリのディレクトリとパッケージ名のディレクトリを持ちますので、上記ディレクトリにnet-dns/noip-updaterのサブディレクトリを作成します。そこへ.ebuildファイルをコピーして編集します。
.ebuildファイルは同じバージョンだと駄目なので、うちは-r1を加えたものを作成し、ファイルの編集を行います。
ソースはファイル名のバージョンを取得してダウンロードするので、直接オリジナルのバージョンを含むファイル名に変更しました。コンパイルっぽい箇所へ#defineの指定を加えてファイルを書き込み終了。
次にebuildコマンドで「ebuild ebuildファイル digest」でダイジェストを作成します。これで関連ファイルのダイジェストも作られるので準備OKです。
あとはemergeでアップデートを行えば問題ありません。コンパイルエラーなどが出たらebuildファイルを見直し、ダイジェストを作成、emergeを行えばいいわけです。
ebuildファイルの書き方を覚えれば対応してないパッケージも追加が出来ます。

グラフィカルログインを行う場合、ベースはXorgを使用したXDMを使い、GNOMEやKDEをベースとしたX環境を使うと思います。何世代か前のマシンだと、肥大化したGNOMEなどは重くていろいろと不便だったりします。サーバにしているマシンはXすら要らない状態だったり。
こんな状況だと、フレームバッファを使ってるケースが多いのかなと思われます。うちでは直接コンソールからログインなどせず、telnet経由で保守することがメインです。GentooのLiveCDを起動すると、背景がついたコンソールが使われてますが、それを設定してみよう！ってのが今回のお話。

やり方は、http://en.gentoo-wiki.com/wiki/Fbsplash ここが詳しくかいてありました。検索すればいろいろとやり方が出てくると思うので、難なくできると思います。
以前、起動時にグラフィカルなプログレスが出てくるsplashを設定したことがありましたが、それとほとんど同じでした。

うちは、フレームバッファは設定をしていて、1024×768でコンソールが使える状態にはしてました。カーネルの設定は特に問題ない状態でした。initrdの作成はgenkernelに任せられるので、–splash=テーマ、–splash-res=解像度の設定を加えて作り直せばOKです。
いきなり設定してリブートもいいのですが、フレームバッファが使えるならsplash_managerコマンドで差し替えたり、設定ができます。これでテーマを確認しておくのも手です。すべてのテーマを入れて選んでもいいのですが、これで使うテーマを確認して、使わないテーマは消してしまうのもアリかな。
あとはブートオプションを設定し、fbcondecorをrc-updateで追加して再起動すればOK。splashも設定しましたので、プログレスバー付の起動画面と背景が拝領になりました。

フレームバッファ上で日本語表示を行うにはjfbtermをemergeする必要があります。日本語フォントはintlfontsが入りますが、/etc/jfbterm.confのフォントパスを合わせないと表示されません。jfbterm 2>log などと実行して、logに含まれるエラーを解消すれば正常に動作すると思います。jfbtermの背景が真っ黒になるので、飾れるかは後日調査予定。

グラフィカルログインを行う場合、ベースはXorgを使用したXDMを使い、GNOMEやKDEをベースとしたX環境を使うと思います。何世代か前のマシンだと、肥大化したGNOMEなどは重くていろいろと不便だったりします。サーバにしているマシンはXすら要らない状態だったり。
こんな状況だと、フレームバッファを使ってるケースが多いのかなと思われます。うちでは直接コンソールからログインなどせず、telnet経由で保守することがメインです。GentooのLiveCDを起動すると、背景がついたコンソールが使われてますが、それを設定してみよう！ってのが今回のお話。
やり方は、http://en.gentoo-wiki.com/wiki/Fbsplash ここが詳しくかいてありました。検索すればいろいろとやり方が出てくると思うので、難なくできると思います。
以前、起動時にグラフィカルなプログレスが出てくるsplashを設定したことがありましたが、それとほとんど同じでした。
うちは、フレームバッファは設定をしていて、1024×768でコンソールが使える状態にはしてました。カーネルの設定は特に問題ない状態でした。initrdの作成はgenkernelに任せられるので、–splash=テーマ、–splash-res=解像度の設定を加えて作り直せばOKです。
いきなり設定してリブートもいいのですが、フレームバッファが使えるならsplash_managerコマンドで差し替えたり、設定ができます。これでテーマを確認しておくのも手です。すべてのテーマを入れて選んでもいいのですが、これで使うテーマを確認して、使わないテーマは消してしまうのもアリかな。
あとはブートオプションを設定し、fbcondecorをrc-updateで追加して再起動すればOK。splashも設定しましたので、プログレスバー付の起動画面と背景が拝領になりました。
フレームバッファ上で日本語表示を行うにはjfbtermをemergeする必要があります。日本語フォントはintlfontsが入りますが、/etc/jfbterm.confのフォントパスを合わせないと表示されません。jfbterm 2>log などと実行して、logに含まれるエラーを解消すれば正常に動作すると思います。jfbtermの背景が真っ黒になるので、飾れるかは後日調査予定。

gentoo-sourcesが3.1.10-r1のアップデートが来たのでいつも通りgenkernelでカーネルを作った。（makeでやらないの？とか宗教論争なので突っ込まないように）
警告にルートのファイルシステムを明記したほうがいいみたいなメッセージが出たので、grub.confを書き換えるときに指定しておきました。そしてリブートしてみると、ルートが見つからないって感じのエラーが出てプロンプトが出る状態に。

うちのマシンはE-IDEのHDDにシステム、S-ATA経由とRAIDコントローラ経由でディスクを接続してます。E-IDEは/dev/hdXになり、それ以外は/dev/sdXになってました。しかし、/dev/hdaが無いみたいなエラーメッセージ。shellに入ってデバイスを見てみると、/dev/hdXが存在しませんでした。以前からカーネルオプションを設定してるときに、IDEドライバ辺りが消えるかもって事で警告があったが気になってました。少なくとも、全HDDは/dev/sdXで認識してるみたいだったので、前のカーネルで起動しなおし、grub.confと/etc/fstabを書き直して再起動したら問題なく起動しましたとさ。めでたし、めでたし。