切り替えてみました．httpdのサービスのうち，WordPressは大丈夫なようです．
これより後，めんどくさいのでカテゴリーは，LinuxとNetwork，Raspberry Piくらいにします．
また，あまりに詳しい作業内容については，セキュリティー上の問題もあるので書きません．
Category: gentoo
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: qtwebengine build fails
仮想化した，第2workstation (WS)の元第1OSであったGentooをup-to-dateに保つルーチンですが，qtwebengineのemerge (build)に失敗するというトラブルに見舞われ早くも頓挫していました．
“qtwebengine build fails” でネット検索すると多数ヒットします．もう，10数年前から同じトラブルに見舞われた初心者がフォーラムに質問しては，エキスパートが答えるということが，何度も繰り返されているようです．
ですが，その割にはズバッと解決って言うのは多くないようです．ヒットした検索結果を1つずつ追っかけて，4, 5件目くらいだったでしょうか，エキスパートが，「メモリー不足」と回答していました．
エラーメッセージには1つもメモリーに関したことはないのですが，そのエキスパートは，
Usaually “Killed signal terminated program cc1plus” means a out of memory error.
fedeliallalinea
と明快です．
そこで，書いてある対策や，自分で考えた対策を試行し，build (emerge)に成功しました．
あくまで，当社調べですが，-jumbo-buildは効果が確認できなかったですが，仮想マシンに割り与えるメモリーを増やした(24GB)ことと，make.confの，MAKEOPTSの-jのタスク数を減らすこととが有効だったようです．
なお，SWAPを増やすことは本件に関しては効果がないそうです．