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などで要求アドレスによるリクエスト転送などもやってみたいなーと。
ではでは。

Planex VR500をOpenWrt(LEDE)化して弄ってみた

先日Planex社の「SAKOKU 500(VR500)」を確保したので、それにOpenWrtとLEDEを導入して色々弄りまわしてみました。

pic_vr500_wzr-900dhp

↑筐体を開けた状態のVR500(上)。カバーは家庭用ルータに多いハメ込み式ではなく、スライド式のカバーがネジ止めされているのみなので、開けやすくて嬉しいところ。下は毎度おなじみBUFFALO WZR-900DHP。

VR500のスペックは公式サイトにも掲載されていますが、内部的なものも合わせると大体以下の通り。

VR500 仕様(ざっくり)

  • CPU:MediaTek MT7621A (880MHz, 2C4T)
  • RAM:256MB
  • ROM:SPI Flash 64MB
  • WAN / LAN:10 / 100 / 1000 Mbps
  • USB:2.0 x1, 3.0 x1

VR500は、前述のとおりカバーが開けやすいほか、内部のシリアルがランドだったりスルーホールだけだったり、ではなく、きちんと最初からピンが立っています。今までWT1520などで時々ハンダ付け失敗することもあり、これも嬉しいところ。
早速、シリアルを接続してOpenWrtに書き換えていきます。

ちなみに、OpenWrtへの書き換えに関しては、ファームウェアさえ用意していれば特にシリアルを接続する必要無しに導入できてしまいます。

しかし、今回は後でオリジナルファームにも戻せるように、ということで、基板上のフラッシュメモリに格納されているデータ(mtdblock)を全て書き出し、PC上に保存しました。手順は大体以下の通り。メモは取らなかったので、若干記憶がすっぽ抜けてます。

  • ddコマンドを用いて、/dev/mtdblock0 ~ /dev/mtdblock5 を /tmp などの下にファイルで書き出す

    例:# dd if=/dev/mtdblock0 of=/tmp/vr500_mtd0.bin

  • 「1」で書き出したファイルを、VR500のWebUI提供のため動作しているlighttpdのドキュメントルートに配置する

    例:# cp /tmp/vr500_mtd0.bin /(パス忘れ)/vr500_mtd0.bin
    ドキュメントルートのパスは、psコマンドを実行してlighttpdの引数を見ると分かります。

  • ブラウザでVR500のWebUIにアクセスし、ユーザー認証後に「1」で書き出したファイル名を指定してダウンロード

    例:http://192.168.111.1/vr500_mtd0.bin
    IEだとMIMEが誤判定されることがあったため、Firefoxなど他のブラウザを推奨。

以上でオリジナルファームの保存は完了です。ただ、私は取得したファイルを使用してのオリジナルファームへの戻し方は知らないので(ぇ)、その辺りは詳しい人にお願いします。

ここまで完了したら、今度はOpenWrtファームの導入を行います。作業前に、OpenWrtの2種類のVR500用ファームウェア

  • openwrt-ramips-mt7621-vr500-initramfs-kernel.bin
  • openwrt-ramips-mt7621-vr500-squashfs-sysupgrade.bin

を自分のPC上に用意しておきます。とりあえずOpenWrtを導入してみたい、という方は、srchack氏が公開されているものを使用するのが良いと思います。

  • VR500(オリジナル)のWebUI(管理画面)から更新ページを開き、…vr500-initramfs-kernel.binを選択して更新を実行する

    …vr500-squashfs-sysupgrade.binを選択した場合は、「不正なファイル」というようなエラーが出て弾かれる模様。

  • 「1」の後再起動が行われ、OpenWrtが起動する

    OpenWrtがもういきなり起動してきますが、これはまだFlash内には書き込まれておらず、RAM上でのみ展開され動作しています。そのため、再起動すると全て消えてしまいます。次の「3」にて、Flash上に書き込まれるOpenWrtファームを導入するための、踏み台となるOpenWrtファームです。

  • ブラウザでVR500(OpenWrt)のWebUI(LuCI)にアクセスし、更新ページで …vr500-squashfs-sysupgrade.binを選択し更新を実行する

    Flash内の消去と書き込みが行われ、自動で再起動します。さよならオリジナルファーム、こんにちはOpenWrt。

以上でOpenWrtの導入は完了です。

え、起動しない?文鎮化した…ですか?やらかしました。

後日自分でビルドしたOpenWrtファームウェアを導入した際、ファーム自体に問題がありVR500がブート中にKernelPanicを起こして止まりました。
その際は、ブート中に「TFTP経由でファームウェアを取得してFlashを書き換える」、「Flashから読み込んで起動する(通常起動)」…などの選択肢が4・5秒程度表示されるので、2番のTFTPから取得し書き換えの項目を選択し、TFTPでsysupgradeのファームを送り付けて復旧しました。
ただ、Planexオリジナルのファームウェアでもこの選択肢が表示されるかはわかりません。ごめんなさい。

以上大体の書き換え方(+その他)でした。LEDE-ProjectのVR500用ファームウェアも、おおよそ同じ方法で書き換えができると思います(未検証)。OpenWrtとLEDE-Projectのファームウェアのビルドに関しては、気が向いたらまた別の記事で書きます(いつになることやら)。


ついでに、当方でビルドしたLEDE-Projectのファームウェアも置いておきます。LuCIやFS何種か(exFAT, Ext4, NTFS, vFATなど)、Samba、miniDLNA、WoL、QoS、AdBlock, Statisticsなど色々入っています。また、USB関連もUSB 2.0 / 3.0両方のポートでフラッシュメモリや外付けHDDが扱えるほか、当方で使う関係でRTL8192CUのドライバも導入済みです。とりあえず色々な機能を試してみたい方にお勧め?
ただし、あくまで当方のVR500で動作確認したのみなので、使用は自己責任で。

  • lede-ramips-mt7621-vr500-initramfs-kernel.bin

  • lede-ramips-mt7621-vr500-squashfs-sysupgrade.bin

2017/04/27追記: 掲載していたファームが古くなっていたため、上記ファームは削除しました。現在は、下記ページにてデイリービルドのファームウェアを公開しています。

大破Jenkins