Category: Debian

Debian実マシンをぶっ壊す

昨夜，なんにもしてないのにDebianの実マシンを壊してしまいました．

Debianの新しい安定リリースbookwormが6月にリリースされていたのに今頃気が付き，まずは仮想マシンからupgradeしてみました．Debianの仮想マシンはAMD64版とx86 32bit版の2つを飼っていて，特になんにも考えず，/etc/apt/sources.list内のbullseyeをbookwormに書き換えて，apt update; apt upgrade; apt full-upgradeや，apt autoclean; apt autoremoveをしたらbookwormになりました．

楽勝だったので実マシンもupgradeすることにしましたが，かけがえのない実マシンなのでより慎重にとsources.listを書き換える前にapt update; apt upgrade; apt autoclean; apt autoremoveをしてから，sources.listを書き換え，仮想マシンと同じ手順を施しましたが，ぶっ壊れて再起動しなくなりました．updateの過程でファイル関係のエラーメッセージが出ていたようですが，気にせずやったのが良くなかったようで，Manjaroを起動して，Debianのrootパーティションをfsckすると，修復不能と出ました😓

これはいったんパーティションをフォーマットし直すしかないので，バックアップを確認すると，ちょうど一年前の7月のものが最新でした😓 それでも動かないのではしょうがないので，パーティションをフォーマットしてからrsyncで1年前のバックアップをコピーバックしました．

しかし，grubの設定の仕方をすっかり忘れてしまい，昨夜のうちには起動できませんでした．

自分の記録を見ると，インストール用DVDイメージからレスキューモードでgrubの設定をするようです．一年前のDVDイメージを探すのも面倒なので，bookwormにupgradeできた仮想マシンのディスクイメージをDebianのパーティションにコピーして， 最新のDVDイメージからrescueすることにします．この仮想マシンはもともと実マシンから移転したものです．

まあバックアップの意味もあって仮想マシンを飼っているわけです．ただし，仮想マシンの仮想ディスクからコピーバックするのはかなり時間がかかります．今回実マシンの復元に成功したら，今後はまめにバックアップを取ることにします．

なんにもしてないのに壊れるわけはなく，厳密に言えば，「何も悪いことはしてないのに…」です．世の中に蔓延する「何もしてないのに壊れた」も，責任逃れのいいわけです．
一年前のバックアップがその時点でup-to-dateな保証もないし😓

Mojoってなんだ

一昨日でしたか，スペインのアマチュア無線家（ハム）からEMailが来ました．「動かしているDX Spiderにセキュリティーの問題があるからMOJO版にupgradeしてください」という内容でした．

そう，公開しているポートはありませんが，DX Spiderを2ノード，かなり昔から動かしています．たぶん，DX Spiderに関しては日本で動かしはじめた最初の数人に入っていると思います．

ついでにいえば，その前に動かしていたDX Netに関しても同様に最初の数人だと思います．もっともDX Netは日本で動かした人が数人であったように思いますが😓

さて本題に戻りますが，MOJOといわれても何のことやらさっぱり解りません．ネットで調べてもなんか解りません．しばらくうろうろしていると，Mojolicious.pmのことらしいとなんとなく解りました．

いつものように事前調査は早々に打ち切って実行あるのみです．

2つのDX Spiderノードのうち外界とつながっていなくて，もう一つのノードとだけつながっているプライベートなほうを先に試してみることしました．大事な方を先に試して，途方に暮れることがよくある筆者としては賢明な判断だったと思います😓

しかし，スペインのハムが示してくれたupgrade用のスクリプトを動かしても，「Slackware 15.0 ARMは対象外だよ」といわれてしまいました．ARM版どころか，そもそもSlackware自体対象になっていません．

しょうがないので，x86_64なDebianで動かしていて，海外複数ノードとつながっている大事な方のDX Spiderのupgradeを試みました．結局こうなるんですよね😓

スクリプトはなんか無反応なまま終わってしまいました．

しょうがないので，gitのbranchを覗いてみることにしました．なんと，gitがないので，しょうがないからgitのインストールからはじめました．

Debianなので楽勝で，インストール後に，

git branch -a

を実行すると，remotes/origin/mojo なるブランチがあります．これかと思って，

git  checkout  mojo

としてcluster.plを実行したら，Mojolicious.pmがないといいます．これまでこのモジュールを要求されたことがないので，ブランチの切り替えは成功のようです．そこでDebianのパッケージサーチで当該のモジュールを探したらすぐ見つかりました．

インストールしてcluster.plを起動してもその後も「ない」というパッケージが表示されたのでその都度インストールといういつもの手順を3回ほどくりかえして，無事起動するようになりました．

起動したときのメッセージに “Mojo/何たら”との表示が出るので大丈夫でしょう．

Slackware 15.0 ARM版に関しては，

git branch -a

でmojoの表示が出ないので，引き続き苦闘中です．

“Mojolicious”とは，どういう経緯か「もじゃもじゃ」と出てきましたが再現できません（当社調べ）．
というか，そもそもMojolicious.pmがないと起動しないから大丈夫でしょう．

使ってもいないDebian上のmysqldを動くようにした

とあるDebianのサーバーで，mysqldというか実態はMariaDBのデーモンですが，それがなかなか動いてくれなかったのを動くようにしました．

問題は，/runからもはや/var/runへsymlinkが張られていなくて，それぞれ実体のあるディレクトリーとなっているのに，mariadb.service内では，/var/run/mysqldを使い，/etc/mysql/mariadb.cnfでは/run/mysqldを参照しているためのようです．

他のDebianのマシンでは，/var/runは/runからのsymlinkなので，何かの手違いで，/var/runと/runを独立させてしまったようです．

システムが活きたまま，/var/runを/runからのsymlinkに修正するのはちょっと危険ですね😓

と，いいつつ，やってしまいました．

cd /var/run
cp -Rdvp * /run
cd ..
mv run run-save
ln -s /run

今のところ問題ないみたいです．

Debianのhttpdの設定ってなんであんなに複雑化したんだろう

タイトルのまんまですが，/etc/apache2/sites-available/ 内に設定を書いて，

a2ensite そのファイル名

で， /etc/apache2/sites-enabed/ 内にsymlinkを張って， 

systemctl restart apache2

でhttpdを再起動して新しい設定を有効化する，なんて手順が必要なのは，どういう発想からそうなったのか，全く理解できません．

もう一つ挙げると，デフォルトで，公開しているディレクトリーのサブディレクトリー内を閲覧できてしまうのもどうかと思います．

その他の利便性が，これらの不便さを今のところ補ってあまりあるので，Debianで行くという方針は変更しません．

一時的にWebサーバー止まります

当Webサーバーを入れているケースのクーリングファンが止まってしまいました．他のケースと入れ替えるので，7月30日のいずれかの時間帯に30分程度停止します．

追記: 作業は既に完了

見込みの30分を少々超過しましたが，作業は既に完了しています．

2022年7月30日(土) 18:55 記

よくあるベアリングの不良と思われます．