Category: Tips

SSD 1TB故障

先日の落雷が原因と思われる停電の後，Raspberry Pi 4 Model B RAM 8GBが不調になりました．その後色々調べていたら，ROOTドライブにしていたBUFFALOの1TB SSD (USB3)がNGのようです．

SSDはたいていドライブとケースを別に買って適当に入れていますが，この個体に限っては，BAFFALOのSSD組み込み済みの “USB-3外付けSSDドライブ” を買ったようです．

組み込み済みと言ってもケースを開けると，SATA-USB変換基板(以下 “IF” )にSSDがつながっているので，別々に買うものと何ら違いはありません．

いろいろ試してわかったのは，連続して書き込むと反応がなくなることです．その際SSDはSATAコネクターに近い部分がかなり発熱しています．

今日は少し時間をかけてSSDとIFを別々に正常と思われる他のものと組み合わせて数十GBのデータの連続書き込みをしてみました．

結果として，SSD本体は書き込みが止まる事態が再現できます．一方IFは正常と思われる他のSSDに繋いで書き込みをしてもエラーにならず，高速に書き込めます．

ということで，BUFFALOの1TBのSSDの故障と断定しました．

このトラブルは停電に伴うディスク交換作業で発覚したものの，実は以前から起きていたのではないかと推測しています．

少なくとも筆者の使用環境では，実用運転で数十GBのデータを連続して書き込むようなことは日常的には起こりません．

ということで，BUFFALOブランドのSSDが内蔵されているドライブは今後買わないことにします．

もしくは “Device I/O error” を起こす．
IFについてその後もテストを続けていますが，どうも連続書き込みをすると書き込みが止まります．エラーにはならず昔のSSDの “プチフリーズ” のようです．
読み出すようなことも😅

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

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

追記: 作業は既に完了

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

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

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

sshdのパスワード認証を不可にする

これは，OpenSSHのdaemonを使っている場合，通常は /etc/ssh/sshd_config 内で，

PasswordAuthentication  no

とすることで可能です．しかし，Slackware (64, ARMも)では，PAMの認証を使用していて，上記のオプションだけではパスワード認証をしてしまいます．

パスワード認証を不可にする場合は，

ChallengeResponseAuthentication no

を追記する必要があります．

参考ページ

このオプションについては，Slackware (64, ARMも) 15.0のデフォルトの sshd_config では一切触れられていない．

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

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