当Webサーバーを入れているケースのクーリングファンが止まってしまいました．他のケースと入れ替えるので，7月30日のいずれかの時間帯に30分程度停止します．
追記: 作業は既に完了
見込みの30分を少々超過しましたが，作業は既に完了しています．
2022年7月30日(土) 18:55 記
よくあるベアリングの不良と思われます．
Category: アマチュア無線
困ったDXpedition
数日前から，フィジー共和国の保護領であるロツマ島からDXpeditonチームがオンエアしてます．
日本からはほどよい距離であるし，ここのところの好コンディションもあってほとんど常時18〜28MHzで強力に入感しています．
最初からFT8で複数のバンドに出てきましたので，多くの日本やアメリカやヨーロッパの局に呼ばれています．運用はMSHVと呼ばれるFox & Hound (F/H)に似たモードです．しかし，DXPeditiont局がF/Hをやる時に出てくる，メインの周波数から少し外れた周波数ではなく，メインの周波数に出ています．
どうも，彼らの使っているソフトがバグっているんじゃないかと思います．呼ぶとシグナルレポートを返してきますから，こちらもR-xxを返しますが，RR73が返ってこない．で，何回かシグナルレポートを送って来てRR73をくれないまま，他の局のシグナルレポートを送りはじめるか，CQを出します．
それでもたま〜に，RR73が返ってくることがあります．シグナルレポートを送ってくる時，1波でなく複数波で送信してきた時，こちらのR-xxに対してまた複数波で返ってくる時です．
ただ，複数波で2度目に送ってくる時は，送信が途絶えてまたCQが出ることがあります．このときは失敗です😓
それから，1度シグナルレポートを返され，RR73がもらえず交信が途絶えた場合，再び最初から呼びはじめてもなかなかレポートが返ってきません．
この画像が，24MHz (24.915MHz)におけるやりとりの一例です．3, 4回シグナルレポートを送ってきて，RR73を送らないまま別の局にレポートを送りはじめるか，CQに移行してます（黄色は懲りずに当局が呼んだ跡です😓）．
この間，相手にかなり良いレポートを送っていますから，R-xxが一度も受信できないはずはないです．
どのバンドでも同じ振る舞いなので，同じコンピューター，OS，ソフトを使っているものと推測しています．
そんなこんなでコンディションがいいから世界中から呼ばれるのに交信の効率が悪いからFT8のメインの周波数はここ数日混乱状態です．
別の周波数で普通にWSJT-XのF/Hモードでやってくれると良いんですが．
個人的感想ですが，ソフトがちゃんと動いたとしても，この局に限らずFT8のメインの周波数でMSHVでの運用は効率が悪いと思います．
追記: MSHVでなくF/H
てなことを書いていたら，DXpedition局から，
FOX ONLY
というメッセージが送られてきました．てことは，メインの周波数に出ていながら，MSHVでなく，F/Hモードでやっているようです．
そして，このアナウンスのあと，それまで1波のみの送信でしたが，突然5波で送信し出しました．それでも最初のうちは相変わらずシグナルレポートを5局に送り，3回送って別の局をやってましたが，途中からちゃんとRR73を送りはじめました．
5波出し始めたところで呼び始めたら少しして交信できました．ちゃんとF/Hモードです．
何か解らないですが，設定が悪かったんでしょうね．
しばらく眺めてますが，RR73は以前に比べ格段に出ますが，それでももらえない局も多数いるようです．
追記にあるように，MSHVではなくF/Hでした．
この間，3D2なんとか局は，1派のみの送信なのでこれがこの間の全送信の記録です．
そんな中でもなんとか18, 21, 28MHzでRR73もらいました😓
もとがほとんどゼロでしたから😓
アマチュア無線脚光を浴びる
サーバーをガチャンと切り替えてみました
切り替えてみました．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実行時も．