Category: Raspberry Pi

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

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

追記: 作業は既に完了

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

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

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

仮想マシンのIPv6現状 〜6年前と同じ😓〜

今日は暑いけど，死ぬほどは暑くなかったので，懸案の畑の除草耕耘をしました．1時間ちょっと運転して，ローターから草を取るためエンジンを止めたら，2度とかからなくなりました．想定の範囲内ではありますが，明日に回す領域が多く残ってしまったので，もうちょっと耕したかったです．

さて，一番進めたい，監視カメラのモニターをRaspberry Pi 3 Model B(+)でしようというプロジェクトですが，中国の通販サイトに手頃なヒートシンク付きケースを注文したのに発送されません．5日延期しましたが，だめみたいで返金になる見込みです．

で，まあかなりどうでもいい部類の仮想マシンのIPv6化プロジェクトに取り組んでいますが，これも壁に当たっています．

自分のBLOGを調べたら，6年前に同じことをやって同じところで頓挫していたことが解りました．

さてどうしたもんでしょう．

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が要らないこともあります．