放置してたら凄いことに

プライベートの写真 とか ブログ を公開しているこのサーバーですが、家に置かれた小さな機器で公開しています。
当初の設置から考えると、何度か機器は更新されていて、今現在は日本国内向けとして直接販売されなかったピンク色の PogoPlug で稼働しています。

OS の設定も当時最新だった Debian の1つ前の安定版をチョイスしたのですが、システムを入れるルートパーティションに余裕を持たせるような配慮を頭に置かずにセットアップしてしまいました。

放置しっぱなしは良くないですね

あまり稼動状態に目を向けていなくて、Logwatchで毎日メールを受取っていたにもかかわらず、ちゃんと見ていませんでした。
なんとルートパーティションの使用率が 99% を越えていました。いつからこの状態だったのか…

サイズ的には、2GBしか確保していませんでした。今時の割り振りとは思えない小ささです。しかし、サーバーを稼働したままパーティションの再配分なんてできませんので、ピンチです。

コマンド du でどの部分が占めているのかを確認すると、/usr の下に使われているようです。実際には大した量ではないのですが、割合的に大きいです。
メンテナンス操作は、byobu と screen を組合せた端末から、リモート操作している環境です。

場所を移動させたい /usr 以下をガラガラに空いている場所にコピーして、/usr 以下を消去しました。さすがにその時点でbyobuが表示する各種ステータスに異常な表示が見られました。
心配しましたがメンテナンス操作はできているようです。確信はないのですが、byobu が情報の格納に/usr 以下の領域を利用しているようです。
すかさずコピー先を /usr にソフトリンク ln で結びつけると、少しずつ異常なステータス表示は解消して、正常な状態に復帰しました。

さすがにネットに公開して稼働中のサーバーを荒療治でメンテナンスする経験は無いので、ドキドキな経験でしたが無事に対処できて良かったと思います。

/usr をルートディレクトリから排除したことで、使用率が 58% に下がりました。時間がないと思っていても、時々は管理してやらないといけませんね。かなり反省しています。

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

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

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

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

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

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

公開サーバー(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 を手に入れて、システム全体を載せ替えないといけないですね。
ここに立ち寄ってくれている皆様、申し訳ございませんでした。これからも時々起こると思われますが、少し時間を作って異常になっていることを短時間で知る方法を整備し、復旧を早くできるように対策しようと思います。

ラズパイの利用について

最近は、色々な記事や書籍が溢れている Raspberry  pi ですが、皆さん利用していますか、と言うか遊んでいますか。
私も国内で最初に紹介され販売された頃に、初期の B  や B+ を購入し、家屋内の共有サーバーにでもしてみようかと 触り始めたのですが、一部はバックアップサーバーとして動作しています。
Raspberry pi (以降ラズパイ)も大ブレークしたようで、高性能なラズパイ 2 や 3 が販売されたようです。オプション的な周辺機器の追加なしで、無線LANやブルートゥースの利用ができるなんて想像していませんでした。
最近では周辺機器やアクセサリー類も多種多様な物が多数出ていて圧倒されてしまいます。選んで組み合わせるだけで色々な物を作れそうな気がします。
私は早くから手を出していた割には思うように利用できていませんね。全く情けない限りです。使い始めた頃の初期版は処理能力にちょっと非力な感じがして、共有サーバーとか夜間に細々と自動でコピーするようなバックアップサーバーが適当かと考えていました。
数年前からネットに公開している このWebサーバーですが、最初のものは、IOデータのLANTANKと呼ばれるものでした。自作NASキットのような位置付けで、ミラーディスクで運用できる製品でした。(wikiによれば、10年ほど前の製品です)
その後、古くなったLinuxカーネルを最新に近づけたいのと、小型化及び、ディスク容量の増加を狙って機種の変更を行いました。それが、通称 Link Station mini と呼ばれていた製品で、裏面のシールには BUFFALO LS-WS1.0TGL/R1 と表記されています。 この時点で内蔵ディスクが、 3.5インチの大きな物から 2.5インチの小型HDDのミラー構成になっています。
今となっては、その後SSDが普及したこともあって昔のイメージを拭えませんね。さすがにLinuxカーネルのバージョンも古くなって来ているので、公開サーバーからは引退していますが、家屋内の共有サーバーとしては現役のまま稼動しています。それと、ipv6に対応できていなかったのも引退の理由です。
そこで Linuxカーネルのバージョンを順調に上げながらDebianの派生Raspbianとしてサポートしているラズパイなので、セキュリティ対策も申し分なさそうです。そんな訳で公開するWebサーバーにしようと目星を付けたのですが、明らかに公開していたminiよりも動作が遅い、ディスクのインターフェースもUSB2.0だし、LANも100Mbpsだし、これでディスクミラー化はいくら何でも無理がありありだと思い留まりました。
そして代替の一時しのぎに駆り出されたのが、PogoPlug E02です。調べるとハードに対応する armel は、 Debian 最新のJessieがリリースされていて、カーネルは、3.18.5 と 4.x 代の物が選択できるようでした。説明が当然のこと日本語で入手できないので、安心できそうな古い 3.18.5 の物を選択してセットアップしました。丁度一年前くらいに作業していて、2015年7月下旬に Link Station mini から PogoPlug E02 にバトンタッチしました。
ここに立ち寄っている人は、遅いサーバーだと思っていることでしょう。自分でも思いますが、実際に遅いです。そして乗り換えついでに このblogの追加も行いました。
今年度の目標ですが、Web公開サーバーを Raspberry Pi 2 に置き換えての運用を目指します。当初の移行を躊躇した遅い初期版のラズパイは、ラズパイ2 を入手して入れ替える予定です。サーバーとして稼働させて、利用するクライアントのブラウザから体感的に感じるほどの成果があるのでしょうか、とても楽しみですね。
実は、目指すラズパイ2 を利用したWeb公開サーバーですが、家屋内の共有サーバーとしても利用するつもりで考えていて、手作りUPSもどきを組込んでいます。実際にはAC電源の供給を検知して、一定時間経過後に必要なデータやデータベースを安全に終了する必要がありますが、その辺りが何も出来ていません。
充放電の核になる充電池は、単三型のニッケル水素充電池を8本使っているので、容量的には贅沢な構成になっています。
目指す新筐体は、現状でもサーバー稼働中に、AC電源を引き抜いても継続して動作することは確認できていますが、ホームネットワークのゲートウェイや光ファイバの終端装置、それと家屋内のHUBの電源までは考慮していないので片手落ちですね。
 
 

公開サーバーがダウン

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

syslogに残るCRON 認証失敗

何とかセットアップしながらですが、今月からインターネットに公開を始めたPogoPlugで、syslog にCRONの認証失敗が多数記録されています。 この状態だと実行も行われていないようです。

Aug 4 08:58:01 DebianPogo CRON[4789]: 認証失敗
Aug 4 09:00:01 DebianPogo CRON[6354]: 認証失敗
Aug 4 09:03:01 DebianPogo CRON[8696]: 認証失敗
Aug 4 09:08:01 DebianPogo CRON[12609]: 認証失敗

この原因がわからないので、色々と調べました。 /etc/crontab には、実行するユーザーを指定しているので、そのメール環境に原因があるのかと思い、postfixの配送先を見直しましたが、特別な関係は無いようです。

root@DebianPogo:~# nano /etc/aliases
root@DebianPogo:~# newaliases

そこで、実行ユーザーを root に変更して、標準出力やエラー出力の情報を /dev/null に捨てるのを止めると、正常に動作していると思われる結果をメールで受け取ることが出来ました。

There doesn&#039;t seem to be any new mail.<br />Retrieval completed.<br />

syslog を確認するとメールの配送処理が行われているのが記録されていました。
そこで、実行させるユーザーでのログインを試して見ました。すると、syslog に記録されているのと同様に認証失敗の文字列が吐き出されて、ユーザーに対応するシェルが起動しませんでした。

root@DebianPogo:~# su - www-data
su: 認証失敗
(無視)
This account is currently not available.
root@DebianPogo:~# su - nobody
su: 認証失敗
(無視)
ディレクトリがありません。HOME=/ としてログインします
This account is currently not available.
root@DebianPogo:~# su - pogo
pogo:~$ ログアウト

この場合は、ユーザー名の root と pogo だけが認証失敗にならずに実行できるようです。 /etc/crontab で実行させるユーザーを pogo に変更して経過を見ると、この件に関しての認証失敗の記録は無くなりました。