横断歩道での一時停止は善意ではなく義務 (Powered by WordPress)
今日は暑いけど，死ぬほどは暑くなかったので，懸案の畑の除草耕耘をしました．1時間ちょっと運転して，ローターから草を取るためエンジンを止めたら，2度とかからなくなりました．想定の範囲内ではありますが，明日に回す領域が多く残ってしまったので，もうちょっと耕したかったです．
さて，一番進めたい，監視カメラのモニターをRaspberry Pi 3 Model B(+)でしようというプロジェクトですが，中国の通販サイトに手頃なヒートシンク付きケースを注文したのに発送されません．5日延期しましたが，だめみたいで返金になる見込みです．
で，まあかなりどうでもいい部類の仮想マシンのIPv6化プロジェクトに取り組んでいますが，これも壁に当たっています．
自分のBLOGを調べたら，6年前に同じことをやって同じところで頓挫していたことが解りました．
さてどうしたもんでしょう．
そう，仮想マシンでIPv6が使えないというのは，３年前までのIPv6環境でも認識していました．
昨日1日，いろいろやってみましたが，その中で過去もこういうことをやってうまくいかなかったと思い出しました．しかし，BLOGや内部文書にも一切記述がありませんから，今回のようにまる1日かそれ以上費やしていろいろやったけど，成果が何も無いから記録も残さなかったようです．今回は，次回のため😓に，自分用の記録（データベースの1データ）として書いときます．
参考にしたのは，
です．この記事も見覚えがあるので，たぶん前回も参照したようです．
他も都度都度検索しましたが，やりたいことに直接結びつく情報はありませんでした．
それで，1日取り組んだ結果として，上記の記事を元に，IPv6のDHCP設定をすれば，仮想マシンがglobalなIPv6アドレスを取得して，LAN内のグローバルなサーバーにIPv6接続できるが，LANの外にはIPv6接続できない，という状況までたどり着きました．
外に出られない原因は推測ですが，
のいずれか，または複合した問題と考えられます．もちろん，いずれのケースでも筆者がIPv6を理解していないための設定の不具合の可能性があります．
上記のGentoo Wikiの記事どおりにしても，DHCPを使わないとIPv6のグローバルなアドレスが降ってこないあたりに，libvirtの問題があるようにも思います．
夜，そろそろ終わりにしようかと思ったら，KVM / QEMU / libvirtを動かしている仮想マシンのホストが飛びました．キーボードの操作に無反応ですが，GUIはそのままで，しばらくするとシステムをモニターしていたgkrellmの表示が止まり，時計も動かなくなりました．
やむなくリセットボタンを押しましたが，UEFIが認識されず，このサブworkstation(WS)のメインOSであるManjaroがブートできなくなりました．
バックアップ用ディスクにメインのディスク(SSD)の別パーティションにインストールしてあるDebian (サブWSのサブOS)がブートできるようにしてあり，そちらからはブートできましたので，メインのSSDがハード的に故障したのではなさそうです．
また，Debianから飛んだManjaroのパーティションをfsckすると，エラーなしです😓
これも思い出しましたが，以前も仮想マシンいじりをしていたら，ディスクコントローラーがおかしなことになり，ソフト的にディスクを破壊したことがありました．
今日は，メインOSの復旧に費やしそうです．
LinuxのKVM/QEMUはよくできた仮想マシン環境だと思います．仮想マシン（Manjaro AMD64のlibvirt / KVM / QEMUの環境）でiNoniusのスピードテストをすると，この結果です．ゲスト（仮想マシン）は，Ubuntu x86_64です．
一方，macOSのVMWare Fusionではこのスピードです．こちらもゲストはUbuntu X86_64です．
問題としては，どちらもIPv6に対応してない点です．これは，3年前までのIPv6環境でも認識していて，多少調べたり試したりしましたが，全く力及ばずでした．
Slackware ARMはあきらめてManjaro ARMに移行する方針を定めましたが，その方針にそって，Manjaro ARMでサーバーを動かすためには，まずMariaDBをインストールというか，Slackware ARMで動かしている内容をクローニングしなければなりません．
しかし，Raspberry Pi (RPi)でいろいろやるのはスピードが遅いので大変ですから，ここは，Manjaro AMD64 (x86_64)でいろいろ試して，最善手・最短経路を見出してから，RPiへの移行を実践するのが良さそうです．
手順としては，システムやWordPressが送り出すeMailの配信関係の整備が必要なのでDovecotとPostfixをインストールして，最低限の設定をするのから着手しようかと思いましたが，Postfixはデータベースと連携するようなので，MariaDBが先のようです．
せっかくいい感じのworkstation (WS)に仕上げてきた，Manjaro AMD64をグシャグシャにするのも嫌なので，空いているSSDにクローニングして，そちらで試すことにします．
目標達成のための当面の手順は次のようになります．
ここまでうまく行ったら，Manjaro ARMの方で同じような設定を行うことにします．
Slackware ARM 15.0にupgradeした某サーバーですが，色々細かい不満があるので，Manjaroにしようかと考えています．
不満のひとつめは32bit OSであることです．かつての当社調べによると，同じハードウエアで同じOSの32bit版と64bit版を比較した場合，アプリのパフォーマンスの比は1:1〜2であり，平均すると1:1.3〜1.4です．この差を大きいと見るか小さいと見るかですが，体感速度が明確に向上する程ではないです．
それで，これまでそんなに64bit化にはこだわって来ませんでしたが，3割方パフォーマンスが抑えられているということをいつも認識しながら使うのは，細かい不満の一つにはなります．
2つ目はGUIが使い物にならない点です．ときどき，slackpkg update / upgrade-allをして，最新のパッチレベルにしていますが，Konquerorでは相変わらずwebの閲覧ができません．他にwebを閲覧する手立てがなくそのことはGUIが必須のworkstation (WS)としては致命傷です．とはいえ本来的にはGUIはいらないサーバーなので，これもひとつの細かい不満です．
64bit OSでGUIが使えるとなると，Raspberry Pi OSか，Manjaro ARMということになります．どちらがいいかとなれば，個人的にはKDE Plasma Desktopの使えるManjaro ARMとなります．
サーバーのSlackware ARMからManjaro ARMへの移転に関して，鍵になるのは，MariaDBの移転がうまく行くかどうかです．これがうまく行けばほかは楽勝だと思います．
気力がみなぎっているときに，試してみたいと思います．