Manjaro ARM でサーバー (1) 当面の方針

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にクローニングして,そちらで試すことにします.

目標達成のための当面の手順は次のようになります.

  1. MariaDBのインストールと初期設定.
  2. MariaDBにメインサーバーのバイナリーデータをコピーして正常動作するか試す.
  3. うまく行けば,5へ.
  4. うまく行かない場合は,データベースごとにexport / importを繰り返してデータの移転をする
  5. Postfixをインストール(MySQLを使うオプション)
  6. 最低限の初期設定を行う.
  7. Dovecotをインストールして設定(Dovecotはいくつかのマシンにインストール&設定して使えているので問題はないと思う)
  8. Postfixのチューニング

ここまでうまく行ったら,Manjaro ARMの方で同じような設定を行うことにします.

Slackware ARMはあきらめて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の移転がうまく行くかどうかです.これがうまく行けばほかは楽勝だと思います.

気力がみなぎっているときに,試してみたいと思います.

SSDの寿命に落とし穴

当サイトでもときどき触れていますが,今売られているSSDの寿命は普通に使う限り,人の寿命を大きく上回ります.

で,めでたしめでたしかと思っていたら,4万時間でだめになるSSDが市中に出回っていることが判明したようです.

日本語では,「使用時間」ですが,GIGAZINEの記事にあるSmartmontoolsのsmartctlで見てみると, “Power_on_hours” とありますので,通電時間のようです.もしそうなら,24時間連続使用した場合,4万時間は約4年半ですので,普通に使っていれば遅かれ早かれ,いや4年半で必ず来る時間です.

Smartmontoolsは,Manjaro(AMD64, ARM64とも)やSlackware ARMに標準でインストールされていました.Manjaro AMD64 (x86_64)で動いているサブworkstation(WS)の3機のSSDを見てみました.いずれも普通にSATA接続されています.ルート権限で,いろいろごちゃごちゃ出てくるので,

smartctl -a /dev/sda | grep -i hours

としました.

それぞれ,26,622時間,1,021時間,12時間です.12時間のものは先日仮想マシンがぶっ壊れたので新調した2TB SSDです.

他にRaspberry PiにつないでいるSSDが2機ありますが,USB接続なので,上記の方法ではNGでした.

smartctl -d sat -a /dev/sda | grep -i hours

でいけました.某サーバーのルートが13,835時間,サブサブWSのルートが353時間でした.

感じとしては,単純な通電時間ではなさそうで,パソコン自体の通電時間よりは少なそうです.

いずれのSSDも使い回しのため,PCの年齢とも関連性がありません😓 まあ,とりあえず4万時間が近いものはないので安心しました.暇を見て,26,622時間になっているサブWSのルートSSDを暇な部署に左遷して,若いSSDをどこからかまわしてくればより安心かと思います.

USB接続でも,-d satが要らないこともあります.

Manjaro ARMのAvahi解決 おまけ

firewalldを動かして,Avahi (mdns)を機能させる方法については,ネット検索するとすぐ見つかったので,firewalldを動かしたままにすることにします.

上記ページからの引用:

firewall-cmd --add-service=mdns --permanent
firewall-cmd --reload

元記事は,CentOSのケースですが,Manjaro ARMでも同じでいけました.BLOG主さん,ありがとうございます.

Manjaro ARMのAvahi解決

Avahiなんて,Zeroconfなんですから,インストールして何の設定もしないでも機能するはずですが,Manjaro ARMだけどうしても機能してくれませんでした.

昨日の段階で,

systemctl restart avahi-deamon

としてから,ほんの短い間だけ,他のAvahi / Zeroconf / Bonjourが機能しているマシンからssh xxxx.localで,接続できましたが,時間が経つと,

ssh: Could not resolve hostname xxxx.local: Name or service not known

になってしまう,というところまでわかりました.

この結果を元に,いろいろネット検索しましたが,解決に結びつく情報を見つけることができませんでした.

先程,ふと思いついて,Avahiが問題なく機能しているManjaro x86_64と,問題のManjaro ARMとで,

systemctl status

を実行して,動いているデーモン類を比較したところ,Avahiが機能しないManjaro ARMの方だけ,firewalldなるデーモンが動いていました.

適切に,設定してやればいいのでしょうが,x86_64では動いていないので,「不要」と判断して,

systemctl stop firewalld
systemctl disable firewalld

を実行したところ,めでたくAvahiが機能するようになりました.

2022年7月10日
たぶん,1〜2分間.