ネットのプロバイダー変更

ラズパイ1B+のネット共有サーバー化は、少しずつ進めていますが、並行してこのブログサーバーや家の中のネットワーク環境の整備も進めなければいけません。

昔、電話回線経由のモデムで接続してパソコン通信のような使い方が主流だった頃から、@niftyを利用していました。

高速で通信が出来る環境が少しずつ地方にも行き渡り始めて、光ファイバーかメタルのADSLかで騒がれ出した頃に、満を持してADSLに申し込んだのですが、何とこの地域はNTTの庁舎から少し離れているらしく、直接メタルで繋がっていないようで実現しませんでした。

少しモヤモヤとして待つと光ファイバーが近くまで敷設されて、フレッツ光になりました。昔の事は記憶から薄れてしまいましたが、多分その頃から厚く溜まったアルバムの写真を始末したいと考え始めて、勤めていた会社の仕事からLinuxやサーバーの知識も増え、Webサーバーを立ち上げようと考え出して今に至ってます。

その後のネット環境ですが、当時のフレッツ光の時には、宅内のルーターがOKI製の物でした。世間では盛んにIPアドレスの不足が議論され、ipv6が騒がれていた時代だったようですが、何故かNTTでは ipv6 がオプションで有料でした。

サーバーを宅内に置いて、一応外部にも公開しているので、今後のことも考えれば ipv6 環境でも動作の検証が必要でした。しばらくしてプロバイダ料金も含めて光の接続料金が安くなるので、KDDI に乗り換えました。

KDDI は、ipv4 、 ipv6 共に環境は良く、ストレス無く最高の利用環境でした。時代は変わり技術が向上したから、多分どの通信業者でも問題はないだろうと考えるようになりました。後にこれが大きな間違いだと知ることになります。

会社に勤めていた頃は、会社の携帯電話を使っていたため、個人で電話を持つ必要がなかったのですが、退社して安い携帯電話としてウイルコムの PHS を使い始めました。その後ワイモバイルになり親会社がソフトバンクになったわけです。

携帯電話は、家族を含めてスマホに変わり、ソフトバンク光だとスマホとの割引が行われ、トータルの維持費が安くなると勧められて、その気になってしまったのが大きな間違いでした。

ソフトバンク光は、ほぼ二年間の利用でしたが色々な場所で最悪でした。まず最初に、家の中の稼働サーバーに合わせてルーターのプライベートアドレスを変更しようとしたら、そのセグメントアドレスは内部で使用のため変更できないとエラーになりました。仕方無くサーバーの固定アドレス全てを順次変更して落ち着くまで時間も掛かり大変でした。

その後、公開用サーバーとしても稼働させたこともある ipv4 でしか動作しない古い Linux のネット共有サーバーが、DHCP サーバー機能としても稼働していましたが、老朽化で故障しました。仕方無くソフトバンク光のルーターでDHCPサーバー機能を使うことになりましたが、DNSサーバーアドレスを設定できません。自分以外をDNSとして認めない設計です。

実にこれには困りました。故意なのか常時接続のはずなのに、できるだけ通信させない仕様のようで、DNSとしての機能を放棄してしまいます。インターネットでネームサーバーからIPアドレスが引けなかったら通信が始まりません。転送速度が早いとか遅いとかの次元の前の話です。

ソフトバンク光って、NTT光回線を借用しているので、NTTに気兼ねして通信をさせないように意図してしているのか、NTTに弄ばれているのかは判断できませんが、昔のパソコン通信以下です。スマホで検索しようとすると WiFi は、インターネットに接続していませんとなり、仕方無く 3G/4G の外部通信を使うか、ルーターをリセットして再立ち上げするかしか無く、1日に5回もリセットする日もありました。

スマホって小さくて身近にあって、思い付いて検索できたりニュースが見られ、本来非常に便利なはずなのに家の中に居て WiFi に接続できる環境なのに、有料の通信を利用させるのって詐欺じゃないでしょうか。

普段使いのノートPCや宅内に置かれた Linux サーバー類は、自分自身で DNS をサービスしているので、特に問題なくインターネットに接続できていますが、最近では一番利用頻度の高い身近なスマホが利用できないのには参りました。

スマホを利用していて、少し間が開くと節電で画面が消えますが、また起動するとWiFi はインターネットに接続していませんと警告を表示して役に立たなくなってしまいます。自分で DHCPサーバーを立てようかと悩んでいた時に誘いがありました。正に渡りに船ですよね。

今現在は家の中に3本の光ファイバーが敷設されています。一昨日NTTの業者が工事して接続して帰りましたので、その夜から電源を入れルーターを触り始めて、昨日には載せ替えの目処がたち接続を変えました。今現在はブラスト光に接続しています。

あまりにソフトバンクの環境が酷すぎて、よく調べないでブラスト光に契約してしまいましたが、これも親会社がソフトバンクらしいですね。ちょっとネットを見たら色々書かれているようで先が心配になりますが、今の所ネットへの繋がりは良さそうです。

ルーターも最近話題の中国のファーウェイ製の高機能ルーターで、HG8045Q とかです。色々な項目が設定できるようで、設定の仕方がわからないのでネットから情報をゲットして操作しました。当然ですが、DHCPサーバーの設定ではDNSサーバーのアドレスも設定でき、スマホも快適に WiFi に接続できています。

ついでに、プロバイダが変更になるため、ipv6 のアドレスが変わるのでその修正も含めて、昨日から宅内設置のサーバー類のDNSサーバーを見直しています。今まではサーバーで個々に定義設定していたものを1箇所の master のゾーンを変更して、他の slave に自動転送する念願の設定に移行しました。

公開しているWebサーバーも特には問題なさそうに見えます。借りている DDNS も引けているようだし、ipv4 / ipv6 のアドレスも更新できているようでした。

その公開Webサーバーの話ですが、今では外部のサーバーを借りて、クラウドでシステムを立ち上げるのが主流になっています。私は古い人間なので、借りた場所に組み込んで維持するのには安心ができません。会社組織で管理して、人が脈々と受け継がれていくのなら問題ないでしょうが、個人で管理している場合は、病気や怪我で入院や死亡もあるので、自宅に置いておくのが一番だと思っています。

今公開しているWebサーバーも、何代か置き換わりながら稼働しています。ちょっと非力ではありますが、稼働している Debian Linux もセキュリティアップデートも行って維持できています。いつまで現状の PogoPlug が稼働できるのかは分かりませんが、しばらくこのままかと思います。

グーグルマップのセキュリティアップ?

ぃやぁ〜参りました。
自分の写真を以前から公開していますが、その中で撮影地点の確認と移動の経路を軌跡として描画表示するために、グーグルマップを利用させて頂いてます。
公開前の編集時点では、手元のノートパソコンを利用して、以前はそのURI サーバー名を http://localhost/ として記述して、自分自身のノートパソコン内で起動しているウェブサーバーを指定していました。
その中でグーグルマップに表示させる情報も編集していて、データの作成と確認ができてから、問題ない状態になった時点で公開サーバーに転送していました。
最近になってだろうと思うのですが、localhost ではサーバー名が不適だとして、エラーになっているようで、マップ表示が出来なくなっていて、編集や確認が出来なくて困りました。
仕方なく公開しているサーバー名の URI を含ませた名前で、適当にデバッグ用のサーバー名を考えて、apache2 の定義を少し直して、最近では触ることの無かった /etc/hosts に、自分自身のループバック 127.0.0.1 として追加して、急遽対応しました。
取敢えず対処できたので、問題はなかったのですが、一時は状況がわからずに焦りました。
セキュリティ向上の一環なのでしょうか?
そして 1日2日経過した頃に、再び手直しでもしようかと思い操作すると、今度は擬似サーバー名でもグーグルマップが利用できなくなっているようでした。これは困ったことです。
仕方なく、公開サーバー名で自分自身のウェブサーバーにアクセスするように /etc/hosts を編集して確認すると、全く問題なくグーグルマップが表示されました。セキュリティでは色々な問題があるので強化は仕方がないことですが、どのように編集して公開するか悩みます。
それと、公開サーバーは他にも問題を抱えていて、スクリプトを自分で組んで公開していますが、自分で組んだとしても作ってから年月が経ち記憶が薄れ、肉体は老朽化が進み頭の回転は遅くなり、最近は HTML5 CSS3 とかも一般化してきたようで、利用している jQueryライブラリも時代に合わせ進化しているようで、見直してどうにか手を加えようと考えているのですが、思うように進められていないのが現状です。


以下は、後から追加 2017-09-16
今現在は、 http://localhost/ でのアクセスでも、グーグルマップが起動されて正常に利用できているようです。数日前のゴタゴタは何だったのでしょうか。
グーグルでの単なるミスだったのでしょうか、ミスはどこでも起きますから、私なんて時々ミスしてリカバリーに追われることがあります。グーグルマップの利用では、過去にも利用できなくて、それに吊られるように他の機能も利用できなくなって、仕方なくグーグルマップ機能を切り離すオプションを追加したこともありました。
その時には、数日待ってから確認すると、特に問題もなく利用できていましたので、今回もあり得ることだとは思っていたのですが、セキュリティのポリシーが変更になったのかと考えたのと、早めに公開写真の編集を終わらせたかったので仕方なく対応していました。

システム障害発生(2016-08-25 15:45頃)

本日(2016-08-25 15:45頃)、公開サーバーが障害でサービスに支障が出ていたので、再起動を行いました。

未だに原因は分かっていません。ssh のリモートログインも出来なくなっているので、動作状況も残されたシステムログ程度しか無いのが現状です。しばらくは再起動後の様子を見ているだけで、有効な対策が打てそうにありません。
いつでも交換ができるように、代替機を考えて、現在はラズパイ3を設定している最中ですが、できるだけ急いで仕上げておく以外に方法が無さそうです。
今後もシステム停止が頻繁に発生しそうです。
ご迷惑をお掛けしますが、宜しくお願いします。
 

システム障害発生、頻度が高いですね

公開しているサーバーで、本日(2016.07.05)の午前中にシステム障害が発生しました。システムの最立ち上げで復旧しています。
過去の発生も含めて、原因の特定には至っておりません。Webに訪れていただいている皆様には大変ご迷惑をお掛けしています。
自分でリモート操作中に理解できない不穏な動きを確認して、状況を調べていましたが、Webサーバーとしての機能停止やSSH接続ができない状況でした。
当初は判断がつかずに、勘違いかなと考えていて復旧が遅れたことをお詫びいたします。携帯メールを確認すると以前に仕掛けた障害検出メールが多数送られてきていました。
原因もわからず障害頻度も高くて心配ですが、様子見で経過を見守りたいと思います。
以上

群馬の高崎駅前でOSC開催

オープンソースカンファレンス(OSC)って知ってますか、私は日頃無料で利用させていただいているDDNSである MyDNS.JPシステムから送られてくるメールで、時々OSC の開催記事を目にしていたので、全国各地で開催されているのを知っていました。
近い所では、東京で過去に何度か開催されています。以前は東京まで通勤していたのですが、今の私には旅費も距離も東京は遠い存在になってしまいました。 そんな訳で、まだ一度もOSCを訪れたことがありません。
そして今回、オープンソースカンファレンス2016 Gunma が高崎駅前のヤマダ電機で開催されることになったようです。過去のことを把握しているわけではありませんが、たぶん群馬では初の開催だろうと思います。
OSCは、オープンソースに色々な立場から関わっている人達の集いだろうと理解しています。何の貢献も出来ずに一方的にお世話になっているだけの私ですが、近い高崎で開催されるので動員数を1人増やすだけでも微かな貢献かなと思い参加することにしました。

日程:2016年5月14日(土) 10:20-17:40(展示は10:30~17:00)
会場LABI1 高崎 4F イベントホール  (JR高崎駅 徒歩1分) 
    [アクセスマップ]
費用:無料
内容:オープンソースに関する最新情報の提供
   ・展示 - オープンソースコミュニティ、企業・団体による展示
   ・セミナー - オープンソースの最新情報を提供
主催:オープンソースカンファレンス実行委員会
後援上毛新聞社
   株式会社エフエム群馬
   株式会社ラジオ高崎
   群馬テレビ
   まえばしCITYエフエム
会場協力:株式会社ヤマダ電機
企画運営:株式会社びぎねっと

当日は、セミナー展示ブースがあるようです。各セミナーは 10分程度の時間なので内容の触りだけだろうと思いますが、いくつかのテーマは私にも興味が湧くようなもので、とても楽しみです。

公開サーバーの監視とエラーメール

公開サーバー(Pogoplug E02)の停止を監視する別のサーバーとして、ARMのサーバー3台にスクリプトを組み込み監視させてみました。監視間隔を5分として常時監視させる方法です。
実際に公開サーバーが障害になった時に、問題無くエラーメールが届くのかは起こってみないとわかりませんが、確認テストとしてはLANケーブルを抜いて確かめてみました。メール先にしていた携帯メールには期待したメールが届くのを確認できました。
一応、エラーメールを送信させることは可能のようです。ただ少し気になるのは、サーバーが 3台で監視スクリプトが各2種なので、計6メールが届くことを期待したのに 5メールだけ届きました。
何故か届かなかった一件のメールは、Webのhttpリクエスト確認エラーメールでした。一応監視側サーバーのメールログを確認するとエラーメールは作成されて転送されているようでした。
複数サーバーで監視させているので、1つ2つ届かなくても特に大きな問題でもないですね、あまり気にしないことにします。
それより監視方法を1種類増やし、sshログインの確認チェックを追加することにしました。方法は単純に接続して、簡単なコマンドを実行して終了するだけのもので、正常に接続できれば含まれるメッセージの文字列で成否を判定することにします。
実行するsshのスクリプトは次のようなものを作成しました。

#!/bin/bash
To='sunao_mita@.....'   # To: メール転送先
 T='sunao-mita.pgw.jp'
 test -z "$1" || T="$1"   # T: 監視するサーバー
 Su="## SSH Error <$T> ##"
rt=`
 ssh -4 -t -t "$T" <<EOF 2>&1
 pwd
 exit
 EOF
 `
ck=`echo "$rt" | grep -e "Connection .* closed\."`
 test -z "$ck" && ( echo "SSH Error <$T>." | mail -s "$Su" "$To" )
 exit 0

先に示した他の方法(ping/wget)と同じようなスクリプトで、sshのリモートログイン後に、pwdコマンド、そしてexit しています。簡単な短いコマンド列なのでヒアドキュメントで与えました。sshコマンドの標準エラー出力は、標準出力にまとめて( 2>&1 )取出して、接続後のメッセージの判定に利用しています。
監視を組み込んだのでしばらく様子見ですね。

サーバーからメール送信の難しさ

このWeb公開サーバー(Pogoplug E02)が、原因不明で時々クラッシュするようです。気付いて再起動すれば復旧しているのですが、それを知ることが出来なくて、ずっとわからないまま長期間の動作不能状態になってしまいます。
対策としては、動作を監視していて検知したらメールを飛ばすことで対応できると考えました。方法としては単純なので対策が簡単に出来ると思っていたのですが、やってみるとなかなか大変で、途中にハードルが沢山隠れています。
検知方法は、(1) ping 、 (2) wget の2種類で試作してみました。
(1) は、一般的な ICMP パケットを 5回送信し、相手からの応答を要求してロスがなければスルーして、ロスがあればメールを送信する方法です。

#!/bin/bash
To='sunao_mita@.....'  # To: メール転送先
 T='sunao-mita.pgw.jp'
 test -z "$1" || T="$1"  # T: 監視するサーバー
 Su="## Ping Error <$T> ##"
ck=`ping -c 5 $T | grep ' 0% packet loss'`
 test -z "$ck" && ( echo "Ping Error <$T>." | mail -s "$Su" "$To" )
 exit 0

(2) は、単純にwgetコマンドで、httpリクエストを要求して取り出せれば正常と判断し、取り出せなければメールを送信する方法です。キャシュに残るデータで正常と判断されて検出できないことが有りそうで少し心配です。

#!/bin/bash
To='sunao_mita@.....'
 T='sunao-mita.pgw.jp'
 test -z "$1" || T="$1"
 Su="## HTTP Error http://$T/ ##"
`wget -q -O- http://$T/ >/dev/null`
 test "$?" -ne 0 && ( echo "HTTP Error http://$T/" | mail -s "$Su" "$To" )
 exit 0

実際にテストしてみるとメールが届かない、なぜ…
監視しているサーバーの postfix が、単純に監視される公開サーバーへエラーメールをリレーしているので、監視されるサーバーが異常となって、エラーメールが生成されてもリレーの機能も異常なわけで、メールが転送できずに届かないといった問題がありました。
昔は単純に@niftyのメールサーバーに転送すれば機能したのですが、スパムメールを大量に送りつける悪い人が多くなりいつの頃からかパスワードでの認証が必要になってしまいました。
正常にメールを送信できる公開サーバーの設定 /etc/postfix/main.cf を参考にして、監視サーバーからも生成したエラーメールを直接 @niftyにリレーできるように設定しました。
公開サーバーのLANケーブルを抜いてテストしてみます。

Web公開サーバーの障害

Web公開サーバー(現在はPogoplug E02)が、異常でアクセスできない状況になっていました。詳細はまだわかりませんが、4/13 の10:54頃からはアクセスログの記録がなかったので、この頃からは完全にアクセス不能だったものと思われます。
再び子供から指摘されました。頻繁にシステム障害になるようなら、常時サーバーを監視する機能を組み込まないといけないですね。
今回も強制的に電源のOFF/ONで、システム再起動を行いました。  ⇒ 2016-04-13 / 20:10
様子見で継続稼働させておきます。
確認すると前回のダウンが 3/2 のようです。約40日で再発生ですね。ちょっと頻度が高いでね。 1月経っても何の対策もできていないわけで、情けないですね。
早めにラズパイ 2 を手に入れて、システム全体を載せ替えないといけないですね。
ここに立ち寄ってくれている皆様、申し訳ございませんでした。これからも時々起こると思われますが、少し時間を作って異常になっていることを短時間で知る方法を整備し、復旧を早くできるように対策しようと思います。

公開サーバーがダウン

久し振りになるblogの更新です。
日常の家事に追われてバックログが蓄積の一途に、時間が欲しい。
そんなこんなで公開サーバー(このblogや写真の蓄積用)の相手をしないで掘ったら貸したまま放置してたのですが、サーバーに仕事を放棄されてしまいました。
再立ち上げしてログをざっと見たのですが、原因は分かりませんでした。システムログは3月2日の朝11時頃が最後で、気が付いたのが3日の夜11時頃なので、丸1日半停止していたようです。時々訪れてくれる貴重な方々にはご迷惑をお掛けしました。
停止した原因も解明出来ていませんが、SSHのリモートでのログインの操作も出来ず、一番原始的な電源コードを抜いて、再度差し込む基本的な方法で復旧しました。
昔のUNIXを知る身には、電源コードが抜けてファイルシステムの復旧に半日や1日掛かった記憶が嘘のようで、なんと軽快に復旧してしまうのだろうと思い一安心しました。
外から保守出来るように、何の細工もなく標準の22番ポートは開けてあり、何時ものようにアタックしているログは記録されていますが、パスワード認証はさせてないのでそこに問題は無さそうですが、さて何が悪いのでしょう。
昨年の夏の前にセットアップして、ざっと半年は稼働していた訳なので、まずは良しとしましょう。ただ、不具合をもっと早く発見できる何らかの対策が必要だと痛感しました。
サーバーに問題が発生した頃に、実は子供からWi-Fiで利用しているゲーム機?の動作が何か繋がりにくいけど、ネットワーク機器を変えたのかと聞かれてました。
何でそんな分かりやすいサインを見落としていたのかと、確かにDHCPサーバーも屋内のDNSサーバーもそこに集約させていました。そういった管理的な仕事をしていた会社を去ってから早5年、今の頭は完全に錆びきっていますね。
時間を作って、別のサーバーから定期的に主要なポートの稼働チェックとping死活チェック、不具合検出時の自動報告メール機能を組み込まないと駄目ですね。
しばらく様子を見るしかなさそうです。このblogのサーバーでもありますので…