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

ぃやぁ〜参りました。

自分の写真を以前から公開していますが、その中で撮影地点の確認と移動の経路を軌跡として描画表示するために、グーグルマップを利用させて頂いてます。
公開前の編集時点では、手元のノートパソコンを利用して、以前はその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のサーバーでもありますので…