Category: KVM

Postfixを試す (3) KVMのホストが不調

Slackware64で長らく動かしてきたKVM/QEMUの仮想マシンを，Manjaroに載せ替えたのは，一昨年末だったでしょうか．ソフト的には，Slackware64からManjaroなんですが，どちらも同じデスクトップ機(WS)で動いているので，ホストのOS(distro)をSlackwareからManjaroに入れ替えたというのが正しいかもしれません．

その過程で仮想マシンを保存するディスクをSSDからHDDに替えていたのでした．SSDではスピードはシャキシャキ速くて良いのですが，しばらく動かしていると，ディスクの入出力が止まってしまうというトラブルが高頻度で発生していました．始末が悪いのは仮想マシンの仮想ディスク（ディスクイメージ）の入出力が止まるばかりでなく，ホストのディスク入出力も止まってしまうのです．

原因は，Linux kernelにあるのか，使っているCPUやメインボード固有のbugか解りませんでしたが，とりあえず仮想マシンのディスクをSSDからHDDにするとこのトラブルは起きないことが解り，ワークアラウンドとして，そういう体制にしていました．仮想ディスクのイメージがHDD上では，SSD上にあるよりも目に見えてパフォーマンスが落ちますが，仕方ないです．

で今回，そのHDDが回らない疑惑で，そのManjaroのデスクトップ機が起動しなかったり，ホストが起動しても仮想マシンが起動しなかったりのトラブルに見舞われました．

そこで無任所のSSDに仮想マシンの仮想ディスクを載せ替えて試したら，かつて起きたディスク入出力無反応に見舞われたわけです．

また，このWSではもう1台システムのバックアップ用にHDDを内蔵していますが，これも調子が悪いようで，Mac miniのバックアップ用にしているSSDと交換してみました．

現時点では本当にHDDが2機とも調子が悪かったのかも解らない状況で，新たに購入すべきなのはHDDなのかSSDなのかも解らなくなりました．

その過程で，GentooやDebianもホストとして試しましたが，総合的にManjaroが一番良いという結論でした．

Postfixを試す (2) その前にいろいろトラブル😓

一昨年末から昨年前半にかけてずいぶん仮想マシンいじりをしていたようなんですが，もうなんだかすっかりご無沙汰で，ほとんど右も左も解らない状況です😓

今回，なぜいじったのか解らないのですが，Mac miniのVMWare Fusionに残してあったDebian 10をDebian 11にupgradeしてみました．Upgrade手順についてはあちこちに書いてあるのでその通りにしてうまくいったようなのですが，どうも起動してももたもたして，とてもDebianのスピードではありません．やはり，Debian 11が出てからずいぶん時間が経ってしまい，upgradeするには適さなかったように思います．

そこで，いったんMac miniのVMWare Fusionは放置して，Manjaro x64で動いているKVMにSlackware 15.0をインストールすることにしました．ところが，Manjaroが動いているマシンが不調です．1機のSSDと2機のHDDを積んでますが，HDDのひとつがどうもへそを曲げてディスクが回転してないようです．本体から，線をつないだまま取り出して，何回か回転方向に振るとディスクが回転し出します．よくあることです😓

HDDは経験上，トラブりだしたら正常に戻ることはありませんから，振って回転しているうちに他のディスクに交換するのが良いです．

実はこの回らないHDDこそ，KVMのディスクイメージを収納しているのでした．

ということで，現在ディスクイメージを予備のというか，困った時のためにあけてあるSSDにコピー中です．この無任所のSSDは無任所にしとかないと後でまた困った時に困るので，HDDかSSDを買わんといかんです．

Postfixを試す

Slackware 15.0 (64, ARMも)では，Mail Transfer Agent (MTA)がこれまでのsendmailからPostfixに切り替えられました．

Slackware 15.0をインストールした実サーバーでは，これまで14.2で使用してきたsendmailの設定（Let’s Encryptの証明書を含む）をそのまま使いたかったので，Postfixをざっくり削除してsendmailをインストールして，問題なく従来通りの機能をするようになりました．

他の必要なデーモン類の移転も完了したので，ぼちぼちもう1台のSlackware 14.xサーバーを15.0にupgradeする作業に入ります．

こちらのサーバーではメール系は，LogWatchの吐き出すサマリーを送り出すだけで良く，sendmailに置ける設定もそれほど複雑ではないので，この際Postfixにしてしまおうと思います．

最終的な動作環境は仮想マシンなので，ManjaroのKVMで仕立てることにします．

Directory service, relational database, web server, MTA, zeroconf discovery agent, domain name system, security shell, file servers , log summarizer and etc.

サーバーをガチャンと切り替えてみました

切り替えてみました．httpdのサービスのうち，WordPressは大丈夫なようです．

これより後，めんどくさいのでカテゴリーは，LinuxとNetwork，Raspberry Piくらいにします．

また，あまりに詳しい作業内容については，セキュリティー上の問題もあるので書きません．

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実行時も．