山梨県大月市扇山山頂

山梨県大月市扇山山頂(JCC#1706, SOTA# JA/YN-059)

きょうは9月に行った佐渡の金北山縦走以来の山行となりました。 昨年5月に「百蔵山」との縦走で歩いた山ですが、ちょうど「扇山」で少し雨が降り始めた時だったので、その時は50MHzで少し出たくらいで、あまり長時間の運用はできませんでした。 この「扇山」はとにかく電波が飛ぶことで有名です。 関東一円を守備範囲にすることができます。 大体丹沢や奥多摩あたりだと、別の山の影になるところもあるのですが、関東全域が見通せる場所としてはとても珍しい場所です。

朝6時に東京駅から中央線で山梨方面に向かいました。 5時半に家を出たときはまだ真っ暗でしたが、昨日までの雨もあがり、今日はすっきり晴れそうです。

7時半頃にJR「鳥沢駅」に到着。 少し離れたコンビニまで行って昼飯と飲み物を買い、鳥沢駅から再出発。

正面に見えるのが「扇山、1138m」です。 左から2番目の影になった谷を登ります。 それほど高くもない山に見えますが、電波の飛びは抜群です。 「扇山」の登山口の一つである「梨ノ木平」まではバスもあるようですが、本数も少なく、歩いて1時間ほどで「梨ノ木平」まで行くことができるので歩いていくことにしました。 駅前をそのまま、まっすぐに行く感じで「梨ノ木平」の登山口の方向に歩いていくことができます。

途中できれいな紅葉を見ることができました。

「梨ノ木平」はゴルフ場の大月カントリークラブの入り口の正面にありました。

ここから山道です。

谷の中を登るルートで単調な登山道が続きます。

「梨ノ木平」から、1時間ほどで「奥宮祠」という小さな祠があり、ここを少し登ったところから富士山がとてもきれいに見えていました。

さらに登るとようやく尾根に到達。

ここから扇山の山頂まではもうすぐです。

こんな広い山道を10分ほど上り、「扇山」の山頂、標高1138mに到着。 今日はいい天気でこの後とても多くの登山客が山頂に溢れました。

富士山方向です。 写真を撮った時は雲に隠れていました。

こちらは東京方向です。

早速、HFのアンテナを張って14MHzから運用開始。

10時40分ころから、FT-817NDで運用しました。

本日の成果

  • 14MHz CW : 6 QSO
  • 18MHz CW : 7 QSO(うち4局がオーストラリア)
  • 21MHz CW : 4 QSO(うち2局がオーストラリア)
  • 144MHz SSB : 71 QSO
  • 430MHz FM : 18 QSO

合計 106 QSOです。 山での運用では相当大きな数字です。 今日は泉州サバイバルコンテストが144MHz SSBで行われていたこともあると思いますが、やはり「扇山」の威力は絶大です。

14時半まで運用し、下山開始。 今日は昨年の5月に来た時にはJR「四方津駅」のほうに下山して駅まで大変な距離を歩いたので、今回はピストンで来た道をそのまま戻りました。

今日のルートマップです。

そして高度、本日は12kmの山行距離でした。

久しぶりの山行で少し疲れましたが、本日もたくさんの方に呼んでいただき楽しい一日でした。 ありがとうございました。

 

FBニュースにてSOTAの紹介

今年の7月に大阪で開催された関西ハムフェスティバルにてFBニュース様からの提案を頂き、SOTAを紹介することになりました。 まだ暑い7月に11月からの連載ということで遠い先だと思っていましたが、あっという間に11月になってしまいました。

今月から6回に渡ってSOTAを楽しむメンバーの方たちの楽しみ方を紹介して行きたいと思います。

FBニュースSOTA紹介のページへのリンク

 

自宅サーバーの不調

最近どうも自宅サーバーの調子が悪い時があります。 今週の日曜日にもLinuxがカーネルパニックを起こして月曜の朝までメールサーバーが落ちていたようです。

すぐに立ち上げ直したのですが、何となくおかしい。 いろいろと調べてみると次のように複雑な問題が絡んでいることがわかりました。 今後の自分の記録および他の同じことで悩んでいる方のために対処方法を書いておきます。

まず月曜にサーバーを立ち上げ直してみたのですがWebサーバーとしては動作しているのですが、SOTAや新潟のクラブのために立ち上げているメーリングリストで、メールの転送が自分には来ているのですが、他の人に行っていないことが判明しました。 試しに自分の外部で持っているメールアカウントにメールを送りますが届きません。 自分のサーバー内のメール配信はできるが、外部への転送ができていないことがわかりました。

mailqコマンドで調べてみるとメールサーバーのQueueの中に今回試験のために送ったメール以外に大量にメールがたまっていることがわかりました。 このQueueをpostqueue -f コマンドでFlushしてみますがNG。 大量のメールが溜まったままです。

困りました。 何がおかしいのか?

maillogを調べてみると、こんなログがありました。(一部伏字)

> Nov  1 XX:XX:XX xxx postfix/smtp[8214]: B
> BD6E68BB0002:
> to=<xxx@gmail.com>, relay=auth.gate-on.net[2
> [XX.XX.XX.XX]:587, delay=0.22,
> delays=0.06/0.01/0.04/0.12, dsn=5.7.1, status=bounced (
> (host
> auth.gate-on.net[XX.XX.XX.XX] said: 554 5.7.1
> <xxx.xxx.mesh.ad.jp[xxx.xxx.xxx.xxx]>: C
> Client host rejected: Access
> denied (in reply to RCPT TO command))
この内容は、xxx@gmail.comにメールを送ろうとしているが、メール転送サーバーのauth.gate-on.net から拒否されているというものです。

このauth.gate-on.net を転送サーバーとして使っている理由はここをご参照ください。

最近、社会問題になっているスパムメール対策の「アウトバウンドポート25ブロッキング(OP25B)」のため、浮動IPアドレスを使う自宅サーバーからの外部へのメール配信のためには、メール転送サーバーが別途必要となるためです。

上記のLogはこの転送サーバーから転送を拒否されているというものです。

理由がわかりました。

私は自宅メールサーバーで、すべてのメールアカウントを統合しています。 例えばBiglobeのメールアカウントに届いたメールを自動で自宅サーバーに転送するシステムをfetchmailで組んであります。 Biglobeのメールアカウントでは有償のスパムフィルター、ウィルスフィルターを自宅サーバーで一元的に、しかも無料で管理できるためです。

さらに、自宅のメールサーバーにメールが届いたときに、procmailで携帯に通知するシステムを作っていたのですが、メールサーバーが落ち、この結果fetchmailでBiglobeなどからfetchしてくるプロセスで出た大量のエラーがすべて携帯に配信されていたのです。

この様子はまさにスパム送信をしているとしか取れず、この挙動のためにメール転送サーバーで一時的にすべてのメール受け取りを拒否されていたのでした。

さて、対策ですが、自宅サーバーのIPアドレスを変更してみましたがNG。 こんな単純には騙されないぞ、メールを拒否というわけです。

このためMydnsの管理者の方にメールで事情を説明し、拒否を解除していただきました。 ある程度の時間が経てば自動で解除してくれるようですが、我が家のサーバーもMLを運用するミッションクリティカル。 早急に対応が必要でお願いして対応していただきました。

恒久的にはprocmailで携帯に通知するメールからfetchmailのエラーメールは除外することにします。

MLのユーザーさんにはご迷惑をおかけしました。 また、特にMydnsの管理者様には大変なご迷惑をおかけしましたが、快く対応いただき誠にありがとうございました。