mackerel-agentをOpenWrt/LEDE-Projectのパッケージ化してみる

今月9日と10日に明星大学で開催された、「OpenSourceConference (OSC) 2017 Tokyo/Fall」に参加してきました。

今年は東海道らぐのしまださんから “もしよければLTどうですか?” とお誘いいただいていたので、8日に急いでスライドを作って9日の東海道らぐLT枠で発表させていただきました。
ただ、LTに慣れていないために量が多すぎるスライドを作ってしまい、結果持ち時間の5分を大幅に過ぎてしまいました。反省。
1日目はルータを持っていこうと考えていたものの忘れてしまい、2日目持ってきて東海道らぐブースに展示させていただきました。

さて、そのLTの中で最後のほうに少し触れましたが、OpenWrt/LEDE-Projectにおけるmackerel-agentについてです。
スライド自体でもざっくりしたものだったうえに、時間が無かったためにかなり簡単に流してしまいました。

流れ

MackerelをOpenWrt/LEDEでゴリゴリやるまでのざっくりな流れです。

  • TwitterでOpenWrt/LEDE-ProjectにてMackerelを動かす記事を見かける
  • Mackerelについて調べる
  • 自分でもやってみよう、どうせならOpenWrt/LEDEの .ipkパッケージ化してみよう
  • パッケージ化はできたけど、ルータによって動作したりしなかったり
  • 正常終了時にpoweroffが通知されない

大体こんな感じ。OSCまでにはおおよそ解決したかったものの、上手くいかず若干問題を抱えたまま2日目東海道らぐブースにて展示しました。

Mackerel とは

“株式会社はてな” が提供する、サーバー監視ソリューション。”マカレル”。
Goで書かれたmackerel-agentをサーバ等で動作させ、収集したデータをエージェントが定期的にMackerel.io側に送信する。詳細については公式サイトで。

OpenWrt/LEDE-Projectの .ipk パッケージ

OpenWrt/LEDE-Projectがパッケージ管理として採用する “opkg” のパッケージ形式。今回Twitterで見つけてかなり参考にさせていただいた mackerel-agentをLinux/MIPS32環境で動かしてみた – Qiitaでは単体で直接ビルドしルータ上へもってきているものの、ファームへの組み込みや配布等を考慮するとパッケージ化するほうが良さそう、ということに。
必然的に、OpenWrtやLEDE-ProjectのBuildrootを利用したビルドになる。

ビルド用カスタムフィード

OpenWrt/LEDE-Project パッケージとしてビルドするにあたり、Buildrootに読み込ませるためのカスタムフィード(公式提供外のフィード)を、試行錯誤した末になんとか作成。
mackerel – taiha/taiha-pkgs
OpenWrt/LEDE-Project Buildrootのfeeds.conf.defaultをfeeds.confとしてコピーし、

src-git taiha https://github.com/taiha/taiha-pkgs.git

を追記したうえで “./scripts/feeds update -a” “./scripts/feeds install -a” を走らせると、menuconfig のAdministrationに “mackerel-agent” が現れます。

Endianでコケた(?

エンディアン周りはいまいち正確に理解できていないものの、どうにもGoはMIPS用バイナリのビルドにおいては正しいエンディアンを選択してビルドする必要がある模様(GOARCH=mips or mipsle)。ビルドしたmackerel-agentバイナリがBIG EndianなAtheros AR7242を搭載するRouterBoard 750GLでは動作するものの、LITTLE EndianなMediaTek MT7621では同一のバイナリが動作しないということが起きた。この辺については、雑記ブログのほうに多少まとめてあります。

なお、現状 taiha/taiha-pkgs のmackerel-agentはMIPSルータのみ対応。ARMはMakefileでGOARCHを指定するように記述しているものの、未だテストできていないのでビルドの可否と動作は不明。
2017/10/04 追記: LEDE-ProjectのBuildrootからARCHを取得し、targetのArchitectureに合わせてGOARCH, GOARM/GOMIPSを指定するよう変更しました。これにより、MIPS(LITTLE/BIG Endianness)とARM、x86/x86_64に対応しました。
(注: 検証済み環境 -> WZR-900DHP (ARM, bcm53xx), VR500 (MIPSLE, ramips), RB750GL (MIPSBE, ar71xx))

mackerel-agent終了時の問題

mackerel-agentには、プロセスが正常終了された場合Mackerel.io側にStatusの変更を通知して監視を停止、あるいは監視は続行するが障害の通知は行わないというような設定が可能。
弄り始めた当初この機能が効いてた記憶があるものの、何故か途中から機能せずプロセスを停止する度に障害メールが飛んでくる事態に。
色々弄ってみても解決しないため、mackerel-agentに “start” “stop” コマンドを追加し、プロセスの起動/停止とは関係なくMackerel.ioへの通知を個別で行えるようにし、強引に解決。

ただし、initスクリプトでMackerel.ioへの通知の成功/失敗を取っていないため、現状では場合によりStatus変更通知に失敗してもMackerel.io側がpoweroffのままエージェントが起動する、あるいはworkingのままでもエージェントが停止するということが起こり得ます。

2017/10/04 追記: mackerel-agent.confでの設定ミスが原因だった模様。現在は上記の変更は破棄し、feedでの使用リポジトリは公式リポジトリへ戻しました。現状、ビルド時のLDFLAGSのみfeed付属のpatchで追加しています。

スクリーンショットなど


↑ RouterBoard 750GL で動作させたときの様子。搭載SoCのAtheros AR7242やRAM容量などもしっかり表示された。各種グラフもOK。

課題 / やりたいこと

  • initスクリプトの強化(成功 / 失敗による処理など)
  • mackerel-agent のバイナリ圧縮(現状4.5MBほどあるのでUPX使用して)
  • ARM機種での動作確認 / 対応(手持ちのWZR-900DHP)Done(2017/10/04 追記)
  • (気分とか進捗によって増えるやも)
広告

WHR-G300NとLEDE-Project

少し前に雑記ブログのほうでOpenWrt / LEDE-ProjectにおけるWHR-G300Nに関しての記事(BUFFALO WHR-G300NとOpenWrt/LEDE-Project)を書きましたが、この中で触れたパーティションの問題について、LEDE-Projectではつい最近修正が入りました(OpenWrtは修正されるのか不明)。

ramips: add missing partitions – lede-project/source

The partitions were lost during migration to device tree.

コミットメッセージを読むに、OpenWrt 10.xx backfire 辺りまで各デバイス毎の構成情報がCで記述されていたものを OpenWrt 12.xx Atitude Adjustment 辺りから Device Tree Source (dts) に書き換えるにあたって、パーティション定義が抜け落ちてしまった模様。
BUFFALO WHR-G300N のほかに Upvel UR-336UN も同様に抜け落ちていたものの、そちらも今回のコミットでパーティション定義が追加されました。

lede-project/source からのフォークである musashino-build/lede-source では古いコードから引っ張った情報でWHR-G300N のdtsにパーティション定義の追加を行い、正常動作するようにしていましたが、今回の公式のコミットにより独自に追加したものを使う理由は無くなったので、WHR-G300N.dts を公式のものに差し替えました。

この状態で独自にビルドし、実機上で問題なく起動・動作することも確認できました。

Mastodon with IIS (Mastodon編)

というわけでやりました、Mastodon インスタンス構築。”サーバを自分で建てられる” と聞いてやらないわけがない性格なので仕方ないね。
今回はMastodon 本体の構築。と言っても、ほとんど公式ドキュメント (Production guide)に準拠します。

下記手順については、記事執筆時点の公式ドキュメントに従ったものです。公式ドキュメントは頻繁に更新されるため、最新の手順に従ってください。

注意事項など

  • サーバの構築などは学習目的で行っています。間違いや改善すべき点等含んでいる前提でご覧ください。
  • クレジットカードが無い(作るのも現状不可)などの理由で、クラウドの利用はそもそも選択肢にありません。
  • 今回は非Docker環境で構築します。そもそもDocker についての知識が乏しいことなどが理由です。
  • 構築先の環境等の詳細については、構築済みインスタンス “どんぶり大破” の about/more ページに記載しています。

必要パッケージのインストール

Production guide の “General dependencies” “Redis” “Postgres” に従ってインストールしていきます。

General dependencies

Nginx は apt-get install の中にありませんが、OSに入ってないのでここで入れてしまいました。

sudo apt install imagemagick ffmpeg libpq-dev libxml2-dev libxslt1-dev nodejs file git curl nginx
curl -sL https://deb.nodesource.com/setup_4.x | sudo bash -

sudo apt install nodejs

sudo npm install -g yarn

Redis

そのまんまインストール

sudo apt install redis-server redis-tools

Postgres

インストール

sudo apt install postgresql postgresql-contrib

Mastodon 用ユーザーの作成

ユーザーを Postgresql によって作成済みのユーザー “postgres” に切り替えて Postgresql のコンソールへログインし、データベース管理の新規ユーザー “mastodon” を作成する。

sudo su - postgres
psql

# ↓新規ユーザー "mastodon" をデータベース作成権限を与えて作成
CREATE USER mastodon CREATEDB;

# ↓Postgresql のコンソールを終了
\q

その他

上記の “\q” の下に “Under Ubuntu 16.04, …” と書かれているが、Ubuntu 16.04 未満の場合必要な操作なので、Ubuntu Server 16.04 を用いている今回は関係無し。

新規 Linux ユーザーの作成

Mastodon は専用のユーザーアカウントで実行する関係で、新規のユーザー “mastodon” を作成する。参考

sudo adduser mastodon
# パスワード入力後、色々聞かれるが何も入力せず4回ほどEnter。最後 "これで良いか" という問いは "y" と入力しEnter でユーザーの作成を完了する。
gpasswd -a mastodon sudo

ユーザーの作成と sudo 権限の付与が完了後、sudo su – mastodon で作成したアカウントに切り替える。
これ以降の作業は、このアカウントで行う。

Rbenv

Ruby のインストール / 管理を行う rbenv の準備
“Production guide” にある通り、rbenv の公式ドキュメントにある方法でインストールを行う。GCC などが必要になるので、”まあいいや” とか言いつつ apt install build-essential をしてしまった。
rbenv のインストールが完了後、

rbenv install 2.4.1
rbenv global 2.4.1

で Ruby ver.2.4.1 のインストールとグローバルバージョンの設定を行った。
Ruby のインストールの際、必要なパッケージが不足していてビルドがコケたりもした。コンソール上のエラーメッセージ内に不足しているパッケージが表示される(libreadline-devなど)ので、それに従い追加でインストールする。

Mastodon 本体の引き込みと追加インストール

Git を利用してMastodon 本体をサーバー上に引き込み、必要パッケージの追加インストールを行う。

引き込み

git clone で、そのまま引き込む。場所は特に変える理由もなかったので、公式ドキュメントに従った。

cd ~     # /home/mastodon
git clone https://github.com/tootsuite/mastodon.git live     # /home/mastodon/live/ 以下に clone
cd live

# master(開発版)はバグが入り込みやすく不安定なため、安定版のバージョンのコードを引き込む
git checkout $(git tag | tail -n 1)

追加パッケージのインストール

ここで “gem コマンドがインストールされていない” などのエラーが出る場合、Ruby のインストールに失敗している可能性があるので rbenv からやり直し。

gem install bundler
bundle install --deployment --without development test
yarn install --pure-lockfile

Mastodon の設定

Mastodon の全体的な設定を行う。

設定ファイルの作成

既存の .env.production.sample ファイルを .env.production としてコピー。

cp .env.production.sample .env.production

設定

デフォルトの設定からの変更のみ列挙、未変更の箇所は未記載。DBのパスワードは、公式ドキュメントにある通り空欄のままにする。

REDIS_HOST=localhost
DB_HOST=/var/run/postgresql
DB_USER=mastodon
DB_NAME=mastodon_production

# Mastodonで利用するドメイン名
LOCAL_DOMAIN=mstdn.taiha.net

# ~/live/ 以下で rake secret コマンドを1回ずつ実行して、生成された乱数を入れる。なので計3回実行することになる。
PAPERCLIP_SECRET=(乱数)
SECRET_KEY_BASE=(乱数)
OTP_SECRET=(乱数)

# Mastodon サイトアクセス時に、既定で表示に使われる言語
DEFAULT_LOCALE=ja

# アカウントの確認用に送信するE-Mail設定。
# 今回は Mailgunを試したものの無料アカウントの制限が厳しかったため、新規に取得した Gmail のアカウントを利用することにした。
SMTP_SERVER=smtp.gmail.com
SMTP_PORT=587
SMTP_LOGIN=(Gmail アカウントのメールアドレス 例: hogehoge@gmail.com)
SMTP_PASSWORD=(Gmail アカウントのパスワード)

その他

ユーザーのアイコンやヘッダー、アップロードされる画像や動画の保存先も変更したかったので “PAPERCLIP_ROOT_PATH” も設定してみたものの、メディアが保存はされるのにそこから読み出せないというトラブルが発生したため、デフォルトの保存先である “~/live/public/system” に対して、マウントしたドライブからシンボリックリンクを設置した。ドライブの当該フォルダの所有者は “mastodon” ユーザーに変更済み。

cd ~/live/public
mv ./system ./system.bak     # 一旦名前を変える
ln -s /mnt/mstdn_media/system system

Mastodon のセットアップ

データベースとCSSやJavaScriptの準備。

データベースの作成

データベース及びテーブルの作成。

RAILS_ENV=production bundle exec rails db:setup

CSS と JavaScript の precompile

RAILS_ENV=production bundle exec rails assets:precompile

Systemd サービスの作成

Mastodon の各プロセスを、systemd のサービスとして登録する。

  • /etc/systemd/system/mastodon-web.service
  • /etc/systemd/system/mastodon-sidekiq.service
  • /etc/systemd/system/mastodon-streaming.service

上記の3つを、Production guide からそれぞれそのままコピーして設置。
そのうえで、OS起動時の自動開始有効化と手動での開始を行う。

# 3つのサービスの自動開始有効化
sudo systemctl enable /etc/systemd/system/mastodon-*.service

# 手動開始
sudo systemctl start mastodon-web.service mastodon-sidekiq.service mastodon-streaming.service

Nginx の設定

今までに設定した Mastodon にアクセスできるように、Nginx のプロキシ等の設定を行う。
今回 Mastodon インスタンスのサーバー上で一緒に Nginx が動作するが、その上位でさらに別のサーバー上にある IIS を経由してクライアントからのアクセスを行えるようにするため、Producion guide にあるNginx の設定例から以下の部分を変更した。
Let’s Encrypt を利用した暗号化 (HTTPS) は上位の IIS で行うため、関連する設定は全て無効化。
server_name には、Mastodonで使用するドメイン名を設定する。

#server {
#  listen 80;
#  listen [::]:80;
#  server_name example.com;
#  # Useful for Let's Encrypt
#  location /.well-known/acme-challenge/ { allow all; }
#  location / { return 301 https://$host$request_uri; }
#}

server {
#  listen 443 ssl;
#  listen [::]:443 ssl;
  listen 80;
  listen [::]:80;
  server_name mstdn.taiha.net;

#  ssl_protocols TLSv1.2;
#  ssl_ciphers EECDH+AESGCM:EECDH+AES;
#  ssl_ecdh_curve prime256v1;
#  ssl_prefer_server_ciphers on;
#  ssl_session_cache shared:SSL:10m;

#  ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
#  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
#  ssl_dhparam         /etc/ssl/certs/dhparam.pem;

  keepalive_timeout    70;
  sendfile             on;
  client_max_body_size 0;

  root /home/mastodon/live/public;

  gzip on;
  gzip_disable "msie6";
  gzip_vary on;
  gzip_proxied any;
  gzip_comp_level 6;
  gzip_buffers 16 8k;
  gzip_http_version 1.1;
  gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

  add_header Strict-Transport-Security "max-age=31536000";

  location / {
    try_files $uri @proxy;
  }

  location /assets {
    add_header Cache-Control "public, max-age=31536000, immutable";
  }

  location @proxy {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Proxy "";
    proxy_pass_header Server;

    proxy_pass http://127.0.0.1:3000;
    proxy_buffering off;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    tcp_nodelay on;
  }

  location /api/v1/streaming {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Proxy "";

    proxy_pass http://localhost:4000;
    proxy_buffering off;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    tcp_nodelay on;
  }

  error_page 500 501 502 503 504 /500.html;
}

設定を記述し終わったら、/etc/nginx/sites-available/mastodon として保存し、/etc/nginx/sites-enabled/default を削除の上 /etc/nginx/sites-enabled/mastodon としてシンボリックリンクを作成する。

cd /etc/nginx/sites-enabled
sudo ln -s /etc/nginx/sites-available/mastodon mastodon

その後、Nginx サービスを再起動する。

sudo service nginx restart

以上で Mastodon 側の設定は終了。あとは IIS 側の設定に続きますが、疲れたので後で書きます…

2017/04/26追記: 書きました ==> Mastodon with IIS (IIS編)

Jenkins with IIS (URL Rewrite)

かなりの今更感ですが、書いておかないとたぶん(というか絶対)忘れるので、備忘録として書いておくことに。

2017/04/19追記: 備忘録として書いたはずが、既に1個完全に忘れてました。Application Request Routing (ARR)も必要です。

IISとJenkinsを連動させる、というか特定のURL以下をJenkinsに飛ばすやり方です。

環境とか

  • WebサーバOS: Windows Server 2012
    クライアントからのアクセスを最初に受けるWebサーバ。Hyper-V内で動作し、長らく “大破.net” をホストしているこいつを使用しました。
  • Webサーバソフト: Microsoft IIS 8.0
    Windows Server 2012に含まれる、Microsoft製でおなじみInternet Information Serviceのバージョン8.0。既にWindows Server 2016が登場し、IISもバージョンが上がっていっているものの、8.0もまだまだ使えます。
  • Jenkins側OS: Xubuntu 16.04
    Debian系のUbuntuファミリーの一つ、Xubuntuを使用。完全なCUIはまだまだ自分のスキル的に厳しい。
    Jenkins自体はWindowsにも導入できますが、今回はOpenWrt / LEDE-Projectのビルドに使用したかったため、Linux系OSを選択。
  • Jenkins Ver: 2.30
    前述の通り、実際に導入してからだいぶ経っているので導入時のバージョンは忘れかけてますが、たぶんこの辺り。2017年1月7日現在最新の2.39でもできるはずです。
  • URL Rewrite Ver: 2.0
    今回重要となる、IISのURL Rewrite(URL書き換え)。Apacheにおける “mod_rewrite” と同等の機能を提供します。たぶん(筆者自身はApacheまともに触れたことが無い)。
    URLのリダイレクト、書き換え、その他色々。
  • Microsoft Application Request Routing 3.0
    上記のURL Rewriteと連携し、受信したリクエストを指定されたホストへ転送します。こっちも何気に重要です。

Jenkinsをインストール

まず、何も考えずJenkinsをインストールします。手順については詳しく書かれているサイトが沢山あるので、ここでは割愛。
今回はUbuntuファミリーのXubuntuにインストールするので、私は以下を参考にしました。
[Jenkins][Ubuntu] UbuntuにJenkinsをインストール – Qiita

インストールが完了すると、もうローカルの8080ポートでJenkinsが動作しているはず。

Jenkinsを構成

IISへのアクセスをJenkinsに飛ばす下準備です。
まず、Jenkins稼働マシン上で

/etc/default/jenkins

を編集して、ポートやプレフィクスを任意のものに変更しておきます。Windowsでは、Jenkinsのインストール先フォルダにある “jenkins.xml” がその設定ファイルに該当する模様。
今回、設定は以下の通りにしました。

ポート: 8080    #競合するものが無かったのでそのまま
prefix: /jenkins     #なんとなく

ちなみに、URLについてはJenkinsのシステム設定にそれっぽい設定がありますが、これはあくまでビルド通知などに載せるために使用されるだけのURLであって、Jenkinsのシステム自体に関わるものでは無いんだそう。
設定ファイルを編集して保存したら、Jenkinsのサービスを再起動します。

$ service jenkins restart

すると、設定した通りのURLでJenkinsが動作するはずです。今回の場合、

http://localhost:8080/jenkins

になります。

続いて、セキュリティ絡みの設定。Jenkinsでは、不正なアクセスを防ぐため、乱数っぽいものを付加している模様。IISからURL Rewriteを使用してJenkinsに飛ばす場合、これに引っ掛かってしまい、多くのページでCrumbなんちゃらとエラーを吐かれて何もできなくなります。
これを回避するため、Jenkinsの管理ページにある “グローバルセキュリティの設定” で、下のほうの “CSRF対策” 内の “プロキシーとの互換性を有効化” にチェックを入れ、適用、もしくは保存して有効にします。

↓下の画像で赤線の部分

jenkins-crumbs

これでJenkins側の下準備は大体完了。

IISの設定

次はIIS側を設定します。Application Request Routing と URL Rewrite は、予めWebPIを利用してインストールしておきます。
とりあえず、Webサイトを適当に1個作ります。
IIS Manager でサーバーのホーム画面を表示して “Application Request Routing Cache” に入り、さらに右側のペインから “Server Proxy Settings” を選択して入ります。
画面一番上に “Enable Proxy” のチェックボックスがあるので、チェックを入れて右側のペインで適用します。
次に、作成したWebサイトのホーム画面へ移り、 “URL Rewrite” または “URL 書き換え” があるので、そこに入ります。
iis8-taiha-net_url-rewrite

そして右側の “操作” ペインから、”規則の追加…” を開き “空の規則” を選択してOKを押下、規則の編集に入ります。
今回は、

http://taiha.net/jenkins

というURLの “/jenkins” 以下を、Jenkinsが動作しているサーバ(IPアドレス: 192.168.88.254, ポート: 8080 )に飛ばします。

規則の名前は “url-rewrite_to_jenkins” とか適当に付けました。
その他の設定は以下の通り。

  • URLの一致
    • 要求されたURL: パターンに一致する
    • 使用: 正規表現
    • パターン: ^jenkins(.*)$
    • 大文字と小文字を区別しない: 未チェック
  • アクション
    • アクションの種類: 書き換え
    • URLの書き換え: http://192.168.88.254:8080/jenkins{R:1}
    • クエリ文字列の追加: チェック
    • 書き換えられたURLを記録する: 未チェック
    • 後続の規則の処理を停止する: チェック

iis8-taiha-net_url-rewrite_rule

とりあえずはこんな感じ。これで、

http://taiha.net/jenkins

以下がJenkins鯖に飛ばされ、アクセスできるようになりました。

ちなみに、大破.net(taiha.net含む)ではLet’s Encryptの証明書をIISが稼働しているWindows Server上で取得してHTTPSを有効にしていますが、この場合インターネット側とIIS間はHTTPS、IISとJenkins間はHTTPで接続されます。
この状態で上記の様なURL RewriteによってJenkinsに飛ばされるURLにアクセスした場合、大破.netのHTTPS接続が維持されます。

↓例。JenkinsもIIS側の証明書によってHTTPS扱いに。

jenkins-https

また、IISは外部へのポート開放は必要なものの、Jenkins側は完全にIISを経由してのアクセスとなるため、こちらは外部へのポート開放の必要は無さそう(未検証)。

ちなみに、この記事の方法でJenkinsに飛ばした場合、Jenkinsでワークスペース内のファイル横に表示される “参照” リンクは、IISのアプリケーションエラーが表示されてしまい機能しません。教えてえろい詳しい人。

というわけで、何かと忘れる自分のための備忘録でした。

WZR-900DHP 3台目

BUFFALO WZR-900DHPの3台目を確保、というかメルカリで注文しました。

そもそも何で

理由としては、現在ルータがそこそこ増えてきているものの、弄る用途のモノだけしか無くてWebサーバなどとしてある程度固定で運用できない為です。
あとは、100Base-TXが多く1000Base-T対応機種が少ないこと、MZK-W300NHがコンデンサ妊娠のためお役御免になったことなども理由だったりします。

ちなみにMZK-W300NHの妊娠したコンデンサは1000μF, 6.3V, 105℃のモノで、前にG31マザーのCPU電源回路のコンデンサを交換したときの余りが残っていましたが、USB Type-A搭載機種では無いこと、100Base-TX機種なことなどから結局処分することにしました。
それと、今ある2台のWZR-900DHPは、片方が純正ファームで所謂イーサネットコンバータとして使用、もう片方がLEDE-Projectを導入してWordPress動かしたりEjectしたり弄り倒してます。

何故WZR-900DHPなのか

ハードにそこそこの性能があって、中古価格が安く出回るからです。
参考にWZR-900DHPのスペックを再掲。

WZR-900DHP 仕様

  • SoC: Broadcom BCM47081A0 (ARM, 800MHz, 1C1T)
  • Flash: Zentel A5U1GA31ATS-BC (128MB)
  • RAM : Samsung K4B2G1646E-BCK0 (256MB)
  • WAN / LAN Speed : 10/100/1000 Mbps
  • WLAN : IEEE802.11 a/b/g/n
  • USB : USB 3.0 Type-A x1

SoCのクロックが高めである程度ゴリゴリ動かせること、RAM容量が多くPHPなどに多めに振れること、Flash容量が多いのでExtRootなどしなくても、Webサーバ系やSambaなどのオプション的なパッケージが大体収まってしまうので、個人的に安定な機種です。

↓WordPressを動かしてた時のメモリ使用状況

ただし、無線はBCM4331を2つ(2.4GHz帯、5GHz帯それぞれで利用)搭載しているのでOpenWrt (LEDE-Project) ではまともに使用できません。まあ、日本国内は電波法の関係でどのみち使えないので問題ないですね。
そして、前述のとおり中古価格が安価で、付属品などの状態にもよるものの最安2,000円台~3,000円台程度で出回ります。

そんな感じで、「同じものいくつもあってもなー」とか思ったものの、結局WZR-900DHPに落ち着きました。
ちなみに、WZR-600DHP2とは無線チップとUSB 2.0か3.0かの違いだけだったりします(600DHP2、2.0なのに端子青くしてるのね…)。今回WZR-900DHPのほうが安かった。なお、WZR-600DHPとWZR-600DHP2は中身別物なので注意。WZR-900DHPとWZR-900DHP2の違いは分かりません。

着弾したらやること

  • 筐体開けてシリアルにピン立てて引き出す
    重要。シリアル直接叩ける安心感。USB – シリアル変換アダプタは、いつも通り秋月で600円の変換基板を使います。
    直立させたときに下に来る面に穴が多数空いているので、そこから適当に外に引き出す予定。
  • 純正ファームバックアップ
    WZR-900DHPは、純正ファームへ戻す方法がバックアップしておくしかない模様なので、抜き出す予定。
    今までは特に戻す必要は無かったものの、無線欲しいときありそうなので。
  • LEDE-Project化
    純正ファームをバックアップしたら、さっくりLEDEを突っ込んでしまいます。CFEのWebページにsysupgradeファームを投げつければOK。
  • Ejectサイト構築
    「除夜のEject」サイトを構築予定。現状WT3020でどこまでやれるか試す予定ではあるものの、SoCとRAMからして厳しそうなのでその場合の代替として。
    Planex VR500でEjectするのもいいんだけど、アレはどちらかというと”逸般の誤家庭”向けルータ…

大体こんな感じのことをやる予定です。
年が明けたら、WordPressか何かで真面目に個人的なサイトを組むか、もしくはnginxなどで要求アドレスによるリクエスト転送などもやってみたいなーと。
ではでは。