Postfixを試す (4) Manjaroの手動upgrade

全てはPostfixに乗り換えるためなのですが,かなり脇道にそれてます.

KVMのホストマシンは2機のHDDのうちのどちらか(または両方)が不調なので両方ともあいているSSDと交換しました.500GBのルート(もとから使用中),1TBのバックアップ用,2TBのKVMディスクイメージ用の体制です.

バックアップは,hardlinkを使用して,実質的に差分backupを取るようにしています.このもとのHDDからSSDにrsyncでコピーする際,hardlinkの指定をしなかったため,同じ1TBに収まらず難儀しました.そのhardlinkの件が解ったけれどまだコピー元よりコピー先のファイルサイズが少し大きいです.いくつかディスクイメージ(qcow2)があるのだろうと当たりを付け,findコマンドでコピー先の “.qcow2” を見つけて削除した上で,rsyncに “-S” オプションを追加してコピーして,同じファイル容量になり,めでたしめでたしです.

次はしばらくKVMを動かして,SSD上に仮想ディスクのイメージを置いたKVMの安定性について様子を見ます.

その一環で,最近いじってない旧い仮想マシンを1つずつ動かしはじめました.Debianは仮想マシンとして仕立てたものと,実マシンから仮想化したものの2つがありますが,前者はgreeterが出ません.

GRUB2の起動コマンドの末尾に “3” を追加して,コンソールからのログインにして,ユーザーとパスワードを入力した直後に一瞬なんかメッセージが出ますが,またログイン待ちになります.たぶん,大幅なupgradeの途中で失敗したかなんかで,システムがぶっ壊れているものと思います.この仮想マシンは消すしかなさそうです.

もう一つのDebianは無事up-to-dateにできました.

次はManjaroの仮想マシンに取りかかっています. “Manjaro-ex-real” という名前が付いていますから,実マシンから仮想化したものと思います.となると,ホストと元は一緒です.

それはどうでもいいのですが,GUIのupdaterで,updateを試みますが, “Checking available disk space…” というメッセージが出て先に進みません.昨夜その状態で就寝しましたが,朝起きてもそのままでした.

update/upgradeするシステムは,リリースされてからうんと後にupgradeをかけるとトラブルを起こすことが多いです.特にローリングリリースは😓 その点,クリーンインストールしてから旧いシステムのデータと設定を移すのが基本のSlackwareは盤石です.

こういうときは,CUIが頼りになります.そこで,

Manjaro commandline update

等で検索すると,

pacman -Syu

で良いとすぐに解ります.pacmanは当然,ゲームのパックマン(Packman)を意識しているでしょうね.

なお,Slackwareがメインの人間として, “sudo” 連発は嫌なので,システム管理はroot権限で実行しています(以下も同様です).

上記コマンドを実行すると,ロックファイルが何たらかんたらというエラーメッセージが出て,updateを実行できません.そりゃ,GUIでupdaterが立ち上がるんですから,自動updateの仕組みがある訳です.GUIのupdaterの正体は,これまたネット検索ですぐに,pamacとわかります.pacmanのアナグラム,ではないですね😓 何が動いているか,

ps aufx | grep pamac

とすると,pamac-daemonというのがあるので,たぶんこれを止めれば良いでしょう.どう止めるか,Manjaroはsystemdなので,

systemctl stop pamac-daemon

としてから,

pacman -Syu

を実行したら動きました.正解でした.

900あまりのパッケージのupdateとなったので,放置して朝食にします.

結局ダメ

朝食から戻ると,906個のファイルのダウンロードは終わっていました.何人かの著者のPGP keyをダウンロードするかの “[Y/n]” にリターンで答えて,そのあと,integrityの検査に入りますが,26個のファイルがエラーとなります.で,ひとつもupdateしてくれません.

もう一度同じ手順を繰り返したところ,ダウンロードは26個のファイルのみでしたが,やはりエラーが出て906個のうちのひとつもupdateしてくれません.

この仮想マシンも消すしかなさそうです.もとはホストの実マシンなので,これをまた仮想化すればいいのですが,面倒くさいのでやめときます.

rsyncに “-H” オプションを追加.
表示時間が短かすぎて読めません.
Manjaroはローリングリリースとかで,バージョンという概念がありませんので,upgradeはなくて,永遠にupdateでしょう😓
って普通はみんなそう😓
もちろん先に別のディスクに保存しておきます.
何か考えながらコマンドを実行する時間違える可能性があります.

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を買わんといかんです.

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

切り替えてみました.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実行時も.