1度サーバーをガチャンと切り替えてみます (2) 準備に手間取ってます

4月8日頃にガチャンと切り替える予定

2022年4月6日(水)の午前中に,ガチャンと切り替えようかと思いましたが,肝心なBIND (named)の設定がまだと気がつき,着手しましたが,難航しています.

もともとBINDのことはあんまり理解してないまま使ってきてました.解ってないのにいろいろ過去の複雑な事情が設定に盛りこまれています.

BINDもセキュリティーの事情からバージョンが上がる度にそういう曖昧さが許されなくなってきているようで,Slackware 14.xで動いていた設定をそのままコピーしても,エラーが出て動いてくれませんでした.

ということで,1, 2日かけて,BINDの設定をチューニングしてから,いよいよガチャンと切り替えます.

追記: とりあえずBIND動きました

BIND (named)の設定のエラーは,メッセージを見ながら,理解していないなりに😓 直して,エラーが出なくなりました.

しかし,システムを起動しても,namedもntpdも動いていない.前のシステムの起動手順などを見てみても,特に変わらないのですが.

なんとなく勘で,システムの時間が設定されていないとnamedが動かず,namedが動いていないから,ntpdがサーバーのipアドレスを取得できなくて動かないのではないか,と当たりを付けました.

一番の問題は,Raspberry Pi Model Bシリーズが,バッテリーにより駆動されるhardware clockを持っていないことです.起動時に何もしないと,1970年1月1日から始まってしまいます.

もともとの起動順は,rc.Mから呼ばれたrc.inet2によって,rc.bindがスタートして,そのあと,rc.Mの少し後でrc.ntpdが起動されます.これでしばらくするとclockが同期しますが,少し時間がかかるので,ntpd起動の前に,

/usr/sbin/ntpdate 0.pool.ntp.org

を実行するように,rc.ntpdに追加してあります.

SlackwareARM 14.xではこれで問題ありませんでした.つまり,システムの時間が1970年1月1日でもnamedは起動して,その後に起動するntpdのサーバー名を解決してくれます.しかし,SlackwareARM 15.0付属のBIND 9.16.xでは,システムの時間がめちゃくちゃだと,namedが居座らずに異常終了してしまいます.

そして,ntpdが時間サーバーのipアドレスを解決できずにやはり異常終了してしまう.

「ニワトリが先かたまごが先か」問題です.

仕方がないので,0.pool.ntp.orgでたまたま表示される1つのipアドレス(仮にnn.nn.nn.nn)を使い,rc.Mの中のrc.inet2起動の前に,

/usr/sbin/ntpdate  nn.nn.nn.nn

を書いて,解決しました.poolなのに,固定的に使うのは趣旨に反すると思いますが,起動時の一回だけだから勘弁しもらいましょう.

動けばいいのだ™
ntpdate実行時も.

1度サーバーをガチャンと切り替えてみます

LAN内で,新しいサーバーの準備をしています.デフォルトのmail transfer agent (MTA)がsendmailからPostfixに変わったとか,httpdはたぶん動くだろうとか解りましたが,実際に外からアクセスできるようにしてみないと,動くかどうか解りません.

2022年4月6日(水)の午前中に切り替えを予定しています.あんまりひどかったら元に戻します.

以後しばらくは当サイトの運用が不安定になるかもしれませんので,ご承知ください.

安定しましたら,またお知らせします.

Gentooのメンテあきらめ

もとは同じだと思うのですが,2つのGentooの仮想マシンがあります.一つは多分メインのWSとしての可能性を調べるために実マシンにインストールして,その後メインとしてもサブとしてもWSとしては使えないという判断をしたものの,いつか実マシンに復帰させる可能性を残して,仮想マシンに移行させたイメージです.

もう一つは,もともとあった古いGentooの仮想マシンをup to dateにするのは不可能と判断して,前述のWSとしての実用性をテストしている実マシンから,VMWare Fusionの仮想マシンに移行して,さらにLinuxのKVMにコンバートして,元々あった古い仮想マシンの後釜に据えたものです.

Gentooのメンテは実マシン・仮想マシンにかかわらず,基本的に週にそれぞれ数回パッケージのデータベースを配布元にシンクロして,その後updateコマンドをかけるのですが,基本はソースからbuildするのでものすごく時間がかかります.時間がかかるだけなら,放っておけばいいのですが,ときどき,なんか警告が出て,よくわからない注意書きを読まされ,設定の変更を要求されます.これがただ残しておくだけが目的の仮想マシンに行うのはめんどくさいです.たぶん,してはいけないほうの判断を時々したと思います.

そんなわけで,いろいろ重荷なのに,仮想マシンで動かしても,「動く」という以外全く意義がないので,update作業はやめることにしました.

ディスクイメージはとっておくことにしますが,まあ,将来的に使うこともないでしょう

あるいは,仮想マシンでインストールを開始して途中で実マシンに移行したかもしれないけれど,もはや思い出せません.
可能かもしれないけれどものすごい調査と手間と試行錯誤が必要.
Gentooは,update作業をさぼると,up to dateにするのが非常に困難になります.

Gentoo VMを飼い続けるのはきびしいかも

実マシンの第2OSとしてGentooを維持するという当初のプランでは,システムをup to dateにするためには,第2OSであるGentooで起動させて,長い時間emerge (Gentooの自動buildシステム)を動かしておく必要があるので,第1OSを使いたいときに使える状況ではなくなりました.

Gentooを第1OSにしたとしても,updateで平気で一晩かかるとかあるので,システムのON/OFF/Rebootの自由度がなくなり扱いづらいです.

それと,当初期待したほど〝守備範囲〟が広くなくて,第1OSとしては厳しいんです😓

そこで,Gentoo以外の扱いやすく守備範囲の広いdistroを第1OSとして(ManjaroかDebian),Gentooをその仮想マシンとすることで,update中は第1OSの電源断やリブートはできませんが,第1OSにマシンパワーをある程度リザーブできますし,普通の作業(ってなんだ😓)は可能です.

しかし,それでも平気で何時間もかかるようなupdateはありますので(しかも,実マシンの時よりも何割か余計に時間がかかる),飼っている第1OSの自由度は制限されます.

といって,Gentooを放置すると,並みやたいていの方法では二度とup-to-dateにできなくなります😓

ということで,持て余しているというか,振り回されているのが現状です.

仮想マシンであるGentoo AMD64が,qtwebengineを激しくemergeしている様子

元実マシンのGentoo VMへそを曲げる

実マシン(第2Workstation=第2WS)の第1OSだったGentooを仮想マシン化して,新たに第1OSに就任したManjaro AMD64の元で動かして維持していこうとしましたが,先程updateのために起動しようとしたら,仮想ディスクがパーティションマップがなくなるほどの致命的な破損を受けていて,起動はおろか,インストールディスクイメージによる修復さえもできませんでした.

大幅な降格でへそを曲げたようです.気持ちはわかります😥

仕方がないので,保存してある実Gentooからクローニングしたときのイメージを上書きすることにします.また仮想化のための多少の手続きが必要になります.今度は仮想マシンとして起動した時点で,そのイメージをバックアップしておきます.