Raspberry pi は、Linuxシステムが壊れてしまう不安定なシステムとの認識を発売当初から持っています。最近では一般にSDとの相性問題と言われているような、SDに問題が有りそうだとのメーカー名と製品をリストにした情報が公開されています。
当初は問題を切り分けできる情報も少なく、ある程度実用になる設定を施した頃になると、必ず水を挿すようにシステム障害になっていて、再びやり直しとなって時間ばっかり掛かるだけで使えませんでした。
そんなわけで、Raspberry pi は、ブートの初期には必ず SD や microSD を必要とするので、その後にマウントされるルートシステム以降の処理をUSBハードディスクに移行する方法で安定したシステムとして稼働させていました。
ルートシステムをハードディスクに移行してからは、Raspberry pi 1 B+ や Rasberry pi 2 B を純粋なサーバーとして利用していましたが、特に問題なく稼働していて、時々手動でシステムの update を実行していました。
でも何故か壊れる Raspberry pi 3 B です。こちらはデスクトップ環境で構築していて、特には利用していませんでしたが、付属として3.5インチLCDディスプレイとタッチパネルが装着されています。そして家屋内の共有ディスクとして利用して、データのバックアップシステムとしても利用していた重要なシステムでした。
問題のシステムが動作不能になったのは、ハードディスク障害等の明確なものを除くと、設置から今までの１年足らずで大きく数えて ２回あります。２回共に自動でシステム更新されたらしく、sshでネットログインが出来ず、再起動しても期待した立上げが行われませんでした。
ただし、１度目は大きく変更されていたわけではないようで、ルートファイルシステムとしてのUSBディスクが無効に変更されていたのが 原因で、ほぼその修正だけで立上げが行えました。ただし、デスクトップ画面は別物として一新して見た目は大きく変わっていました。
２度目の今回は、システムが勝手に大きく更新されているようで、前回のように簡単に修復が出来ませんでした。Raspberry pi は、頻繁にシステム構成が変わっているようなので、安定稼働を期待するサーバーの運用には向いていないのかと思ってしまいます。
何故か時々壊れる(壊される?) Raspberry pi 3 ですが、正常に運用していたシステムが動作不能になると、今までに色々とインストールしているモジュールやら設定が問題になります。
微かな期待として、何とかリカバリして上手く復旧が出来て、そのまま利用の継続ができればベストなのですが、今回はping での反応はしていたものの ssh 接続は出来ず、共有ディスクとしてのサービスも機能してなくて、ログ情報を定期的にメールとして送る機能も動作していませんでした。
電源OFF/ONによる再起動を試みたのですが、正常に立上がらないようで、仕方なくモニタ用にテレビをHDMI接続し、キーボードとマウスを繋いでの復旧を試みたのですが、見慣れない画面が出るだけで、Linuxで一般的な立上げバナーも皆無です。システムが大きく変更になったようでした。
ここまでの状況からは、システムの再インストールが必要な状況のようですが、そこで同じ程度の環境に戻すには、色々なモジュールのインストールや設定を再び施す必要があります。システムが正常に動作しているなら、dpkg -l のコマンドでインストールされたモジュールのリストが出るようです。しかし、再インストールしたら以前の情報は消去してしまいます。
立上げ不能のルートシステムを、別に立上げできる正常なシステムを利用して、そこに繋いで残された情報から調べる以外に無く、操作方法をネットの情報から調べ、 apt-get で操作した場合に残されるログから、インストール時に記録された情報を抽出することにします。
記録ファイルは、/var/log/dpkg…. で始まるファイル名で残されているようです。過去のものは圧縮されているようです。
/var/log/dpkg.log
/var/log/dpkg.log.1
/var/log/dpkg.log.xx.gz … xx 部分が数字の圧縮ファイル
ざっとログ内容を見てみると、インストールしたモジュール名の抽出には、 grep -e ‘ install ‘ が有効と思われます。指定する文字列は、 ‘install’ の両端を半角の空白で挟んで指定します。
再インストールと修復では、地道に稼働していた状態の最後の dpkg.log から突き合わせて元の状態に近づけようと考えてます。
まずは、ラズパイ3 の再インストールから作業を始めます。なんと１年前にも同様の書き込みがありました。
カテゴリー: Linux全般
Linux関連のメモ書き
sudo にハマってしまいました
最近の Linux で定番となったディストリビューションの Ubuntu ですが、一般ユーザーで作業している時に root 権限で作業する場面は時々発生しますよね。その時に 1コマンドだけを実行するには sudo コマンドを使用するわけです。使う場面としては、例えば一時的にパーティションをマウントしたり、マウントを解除したり、新しいディレクトリを生成したりと、一般的な作業で日常的に発生する頻度の高い作業です。
sudo コマンドを実行するときに、一般的にはログインしている一般ユーザーのパスワードで認証するのですが、パスワードを省略して作業したい場合もあります。問題としてはデスクトップを放置している場合に他人が操作するセキュリティですが、それよりも深刻なのはシェルの連続動作中に root 権限を必要とするコマンドを利用しなければならないケースです。この場合はパスワードの入力を求められて、対応できなくて異常終了してしまう等の結果になることが多く救いようがなくなります。
sudo コマンドの動作の振る舞いを定義するのは、/etc/sudoers ファイルですが、これを直接編集して問題を起こすと取り返しのつかない問題になるらしく、冒頭のコメントに ‘# This file MUST be edited with the ‘visudo’ command as root.’ と書かれています。
実は昔から私は一般ユーザー(自分のユーザー権限)の作業中に決まったルーチンで、ネットワークで接続しているサーバーに、データを転送したりバックアップするようなことを行っていました。この場合に mount コマンドで一時的に接続したり、umount コマンドで開放したりを動的に実行していました。場合によっては rsync コマンドでデータ転送も行っていましたが、ここで出てくるのが sudo コマンドです。ところが Ubuntu 14.04LTS から Ubuntu 16.04LTS にバージョンアップしてからパスワードを要求されるようになりました。
原因がわからずにしばらく悩む結果となりました。 sudo のセキュリティがアップされて、認証の仕様が変わったのだと思い込んでいました。今までは、NOPASSWD: のキーワードを付けて、パスワード無しで実行できていました。今でも同様の構文が記述されているにもかかわらず何故かパスワードを求められます。/etc/sudoers ファイルに記述された構文や構成要素の意味がわからず手探りでマニュアルを探していました。
ついに日本語のマニュアルを見付けました。もっともそのマニュアルを見ても表現が今ひとつ理解しづらいのですが、でも構文の使用例が多めに載せてあって何となく言おうとすることが理解できるような気になってしまいます。その内容の中に 『複数のエントリがマ ッチする場合は、順番に適用される。矛盾する値がある場合は、マッチする行の最後の値が効果を持つ。』 と書かれていました。これって同じ構文でも順序が大きく影響すると書いてますよね。 …そうでした。構成要素の最後に NOPASSWD: の定義がある構文を移動したらパスワードを求められなくなりました。
知らない、理解していない…って何をするかわからないですよね。改めて自分の知識の無さに情けなさを感じるというか、ある意味怖いですよね。何となく /etc/sudoers ファイルの構文の意味やファイルの構成順に関して少し理解できるようになりました。
最近になって解決したばっかりの問題で、無駄な時間を潰してしまった失敗談です。
USB無線LANアダプタ GW-450S
私は普段常用しているノートPCが、Linux系なのですが、最近は簡単そうなネットワーク接続で苦労しています。さすがにケーブル接続のイーサネットで問題が起こることはありません。しかしそれ以外では、接続できなくなることも時々発生しています。(もっとも世の中に利用者が多くて一般的な有償のWindows系で問題発生はありませんが。)
本題に入る前に、少し話が長くなりますが、そこに至る流れから始めます。
数年前に中古品で、かなり疲れの出ている Windows XP を搭載したノートPCを安価な価格で手に入れて常用していました。手元に来た時から発色性が悪く黄ばんだ色合いの画面でしたが、最近はさらに老朽化に磨きがかかったようになってきました。(今でも現役で活躍していますが…)
私が常用していた OS は、Linux の Ubuntu 12.04LTS でした。今年の春に 16.04LTS がリリースしたので、ざっと四年前のシステムです。さすがに新しいアダプタやソフトも対象外となっていて、手順通りにドライバ等のモジュールをメークしても機能しないことがしばしばです。
ハード的にも内蔵バッテリーは完全にイカれていて、ACアダプターが必需品の状態です。発熱もひどくて冷却ファンは常時唸りを上げているような状態です。でも、北海道などに長期に出掛けているような状況では、いつもお伴してくれるとても頼もしいやつです。もっとも内臓ディスクは購入後に1.5TBに入れ替えているので、ドライブレコーダの動画等の比較的容量のかさばる物も一時的に取り込んで保存しておくこともできます。
古い機種なので搭載部品は枯れていて、内蔵Wi-Fiのドライバは問題なく認識して動作するので、メインのメールを見たり返信したりには欠かせません。そして、公開している写真の縮小などの整理やWebデータの作成、最終的なアップロードには必需品となっています。とは言っても、購入時のOSが保守対象外となったWindows XP をベースにしているので、移動経路を収集するGPSロガーのデータ取り込みにも支障が出る状況でした。
そこで後継として、安価な新品として入手したのが、Windows 8.1 with … と、マイクロソフトが異例の代金無償で配布したWindowsを搭載したエプソンダイレクトの Endeavor NY40S です。当然現在は Windows 10 になっているわけですが…
購入してから日が立っているのですが、ほとんど活用できないまま置かれていました。何故かというと理由は、その時点の最新の Ubuntu をセットアップしても内蔵のWi-Fiが全く機能しないからです。
dmesg や立ち上げのログを確認すると、内蔵しているチップセット自体を認識しているようで、Web検索すると海外の情報にヒットするのですが、カーネルのバージョンアップに伴い扱いが変化して取り残されたバグだとか書かれているようで、時間が解決するだろうとしばらく様子見で待っていました。
今年春には待望の Ubuntu 16.04LTSがリリースしました。さすがにこれ以上放置したまま待つこともできずに重い腰を上げたわけです。残念ながら最新のUbuntuでも内蔵のWi-Fiは機能しないままのリリースでした。しかし、最近の日経Linuxには高速でWi-Fiを利用するルータやUSBアダプタの記事も多く載せられているので、これに挑戦してみようとネットワーク機器を購入した次第です。
選考基準は価格が安価な機器です。
この独り言を書き始めて(7月２日)から途中まで書いて、非公開のまま放置されていたことを最近思い出しました。すでに Wi-Fi 対応機器は利用していて、カーネルが更新されると通信できなくなってしまいますが、手動で make して probeコマンドで組み込めば接続できるようになるので特に問題はありません。本来はカーネルのアップデートに伴い自動で更新できればと思い、DKMS を調べたのですが、結局２か月の期間があったのに解決できませんでした。
PLANEX 無線LAN子機 (USBアダプター型) 極小モデル 11ac/n/a 433Mbps 5GHz専用 MacOS X10.10対応 GW-450S 手裏剣 ￥ 2,070
BUFFALO 【iPhone6対応】 11ac/n/a/g/b 無線LAN親機(Wi-Fiルーター) エアステーション QRsetup ハイパワー ビームフォーミン ￥ 5,590
BUFFALO 【iPhone6対応】 11ac/n/a/g/b 無線LAN親機(Wi-Fiルーター) エアステーション QRsetup ハイパワー ビームフォーミン ￥ 5,590
未だ内蔵の Wi-Fi は機能していませんが、購入した USB ドングルで接続できるので不便は特にありません。処理が遅くて非力ですが、ブラウザでネット検索したりブログの書き込み程度の利用ならこの程度のノートＰＣで十分な気がします。
Ubuntu 16.04LTS に変えてから Konqueror の操作性や機能が変わってしまい日本語も表示できないようになって不便を感じていましたが、ネットで対処法を見つけて解決できました。なんと、母体となる KDE の日本語化パッケージがキーになっているなんて想像もしていませんでした。
システム障害発生(2016-08-25 15:45頃)
本日(2016-08-25 15:45頃)、公開サーバーが障害でサービスに支障が出ていたので、再起動を行いました。
未だに原因は分かっていません。ssh のリモートログインも出来なくなっているので、動作状況も残されたシステムログ程度しか無いのが現状です。しばらくは再起動後の様子を見ているだけで、有効な対策が打てそうにありません。
いつでも交換ができるように、代替機を考えて、現在はラズパイ3を設定している最中ですが、できるだけ急いで仕上げておく以外に方法が無さそうです。
今後もシステム停止が頻繁に発生しそうです。
ご迷惑をお掛けしますが、宜しくお願いします。
久しぶりにラズパイとLCDで遊んでます
今回はラズパイについてです。
ラズパイは当初の想像を超えた大きなブレイクが起こり、今ではネットに多くの情報が溢れ、本屋さんにも書籍が溢れるようになって、関連する周辺機器やオプションも日増しに開発されるようになったのが Raspberry Pi です。 そして、私もご多分に漏れず最初に国内販売された黎明期の入手難な時期から触れているのですが、未だ有用な実用製品として活用もできないまま役立っていません。
それには私の力量不足に多くの問題があるのですが、ただ発売初期の頃のスペックではクロックも低く、非力なシングルプロセッサでメモリも少なく、あまりにも非力過ぎて何をさせるにも役不足の印象でした。
それが時間に追われたままの生活でしばらく離れていると、なんとマルチプロセッサとなり処理能力が改善された Raspberry Pi 2 が公開されて、さらにはWiFiやBluetoothを搭載して性能を上げた Raspberry Pi 3 なる製品も出荷されました。
小さのものから大きなものまでディスプレイ等の周辺機器も次々に開発されています。２年近く前に日経Linuxの記事で紹介されていたaitendoの安価で小さなLCD(液晶ディスプレイ) 2.2インチ液晶モジュール（240×320/SPI）[M-TM022-SPI] を購入して、セットアップしてみて表示ができることを確認しました。 ただ、システムのメインのディスプレイ装置としての利用を考えた場合には、頻繁に提供されているセキュリティアップデート等の実施でカーネルのバージョンやレビジョンのアップが発生した時点で、そのままではその後の表示ができなくなくなります。
今回は、Raspberry Pi 3 の購入と併せて、保護ケースと3.5インチディスプレイとタッチパネル等がセットになっている製品を amazonで購入しました。 ちなみにそのキットに書かれた情報を記述しておきます。『Kuman 3.5インチ ディスプレイ タッチパネル Raspberry Pi 3B 2B/B+/A+ /A/B/Zero に適用 320*480 解析度 保護ケース ヒート ￥ 3,200』
組み立てた製品イメージは、透明な箱の蓋の部分にLCDモニタが収まっているような形状です。ただし、箱とLCDは一方向に寄ったコネクタで結合しているだけで、コネクタの反対側は空中に浮いたような不安定な構造です。何らかの方法でコネクタの反対を固定する必要があります。
製品群の中には添付のCDが入っていて、その中にたぶんマニアルや専用OSのLCDドライバが組み込まれた Raspbian が micro SDのイメージで入っています。これを使うとシステムが簡単に立ち上がり、そのままデスクトップイメージを表示できます。ただし、実用的に使うためにはセキュリティアップデートや新しいソフトの追加が必要ですが、そこで表示をしなくなります。それに日本語表示の追加等も必要ですよね。でも新しくなったカーネルに何をすれば表示できるようになるのかがわかりませんし、CD内を端からチェックするような時間の余裕もありません。
そこでネットを検索してみました。すると運良く同じLCDを扱った記事が見つかりました。さらに記事の中には最新のドライバのリンクもあり、利用する手順も書かれています。http://www.waveshare.com/wiki/3.5inch_RPi_LCD_(A)
LCD-show-160811.tar.gz をダウンロードして解凍し古いものと入れ替えました。内容について見比べると大きく更新されているようでした。ここに書かれた手順に従って実行すると再び表示できるようになりました。
./LCD35-show
hdmi コネクタに接続したテレビをモニタにするように戻すのも簡単なようです。
./LCD-hdmi
説明によるとモニタを90度づつ回転させることもできるようです。
システム障害発生、頻度が高いですね
公開しているサーバーで、本日(2016.07.05)の午前中にシステム障害が発生しました。システムの最立ち上げで復旧しています。
過去の発生も含めて、原因の特定には至っておりません。Webに訪れていただいている皆様には大変ご迷惑をお掛けしています。
自分でリモート操作中に理解できない不穏な動きを確認して、状況を調べていましたが、Webサーバーとしての機能停止やSSH接続ができない状況でした。
当初は判断がつかずに、勘違いかなと考えていて復旧が遅れたことをお詫びいたします。携帯メールを確認すると以前に仕掛けた障害検出メールが多数送られてきていました。
原因もわからず障害頻度も高くて心配ですが、様子見で経過を見守りたいと思います。
以上
公開サーバーの監視とエラーメール
公開サーバー(Pogoplug E02)の停止を監視する別のサーバーとして、ARMのサーバー３台にスクリプトを組み込み監視させてみました。監視間隔を5分として常時監視させる方法です。
実際に公開サーバーが障害になった時に、問題無くエラーメールが届くのかは起こってみないとわかりませんが、確認テストとしてはLANケーブルを抜いて確かめてみました。メール先にしていた携帯メールには期待したメールが届くのを確認できました。
一応、エラーメールを送信させることは可能のようです。ただ少し気になるのは、サーバーが 3台で監視スクリプトが各2種なので、計6メールが届くことを期待したのに 5メールだけ届きました。
何故か届かなかった一件のメールは、Webのhttpリクエスト確認エラーメールでした。一応監視側サーバーのメールログを確認するとエラーメールは作成されて転送されているようでした。
複数サーバーで監視させているので、１つ２つ届かなくても特に大きな問題でもないですね、あまり気にしないことにします。
それより監視方法を１種類増やし、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 の２種類で試作してみました。
(1) は、一般的な ICMP パケットを ５回送信し、相手からの応答を要求してロスがなければスルーして、ロスがあればメールを送信する方法です。
#!/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の電源までは考慮していないので片手落ちですね。