La FoneraのDD-WRTファームウエア更新

以前に書いたLa Fonera再利用 DD-WRTルーター Wi-Fi APのあと、1年半以上放置してたけど、久しぶりにDD-WRTのウェブサイトをみたらメジャーバージョンが変わっていた。
現状で特に不満があるわけではないが、せっかくなので更新することに。前回と同じくLa Foneraの蓋を開けて何かしなきゃならないわけではないので簡単。特に今回は家庭用ルーターの更新レベル。

DD-WRT 1
前回同様に http://www.dd-wrt.com/site/support/router-database でLa Fonera用のイメージファイルを検索する。La Fonera用を探すなら検索窓に「fon」を入力。 検索結果のリストから所有するLa Foneraの機種の行をクリック。上の画像ではRevisionが2200の行 (La Fonera 2200用)をクリック。(手持ちのLa Foneraの機種番に読み替えて)
前回はDD-WRTが入っていない状態からPCのアプリを使ってファームウエアをLa Foneraに書き込んだが、今回は簡単に更新したいということで、ウェブ更新を使う。(ご家庭向けルーターと同じようなの)
と、いうことで、ウェブ更新用のfonera-firmware.binをダウンロードする。ちなみにLa Fonera 2200用の最新版はファイルサイズ6.1MBしかない。このサイズで高機能だから凄い。ウェブ更新用でない方もほぼ同じサイズ。

DD-WRT 2
管理画面のステータス。
1年半前に導入したまま。右上のバージョンを見るとv24-sp2(2013年3月25日版)ということになっている。つまりVer.2.4ね。

DD-WRT 3
上部の2段タブから(上段)[Administration]→[Firmware Upgrade](下段)を選択。
既存の設定をそのまま使うなら[Don't reset](初期値)
「ファイルを選択」ボタンを押して先にダウンロードしたファイルを選択する。
下の[Upgrade]ボタンを押して更新開始。

DD-WRT 4
ファイルサイズは小さいが処理にかかる時間はかなり。処理が終わるまでの予想残り秒数が表示されるが、それが1100秒程度からカウントされる。ただし、最後の100〜200秒のカウントが終わるまでに突然更新完了になる。実際の時間は15分ていどと思われる。
あと、更新が終わると白い画面になる。ブラウザに表示されるURLは更新途中から変わらず。
更新表示が終わったブラウザを1度閉じて、改めてブラウザでこれまで管理画面にログインするためのURLで開く。要するにブラウザのURL欄にはDD-WRTのIPアドレスだけ入力して開く。今回は設定リセットしないを選択しているのでこれまで使ってきた設定やIPアドレスは維持されている。

DD-WRT 5
なんか見た目は全然変わらない。バージョンはv3.0-r37305(2018年10月10日版)になっている。

DD-WRT 6
システムの状態を見る。
今見ると凄くショボイスペック。いや、入手した頃からショボかったっけ。2100だか2200だか憶えてないけど、2007年頃に無料や500円とかで配布されてたようなハードだからねぇ。自分が持ってるのも貰い物だし。
逆にこのスペックにDD-WRTの多機能が詰まって軽く動作するんだから凄い。

管理画面の見た目と設定項目は眺めた限りではv2.4から変わってなさげ。バージョンの数字だけ書き換えましたと言われたら信じるレベルで何も変わってないように思う。

まぁ、2017年にインストールしたときに最新版が2013年3月25日版だったので、La Fonere 2100/2200用のDD-WRTは開発終了になっているものだとばかり思ってた。それが、まだ更新されるんだからバージョンの数字が変わっただけでも良しという感じ。実際に何が変わったのか調べたくてChange Logのようなものを探したが見つけられず全く不明。

SSHは管理画面のメニュー上では利用可能になってるが、実際にはポートが閉じているようなので諦めてtelnetで接続してみた。

$ telnet 192.168.6.3  ←DD-WRTのIPアドレスを指定
DD-WRT v3.0-r37305 std (c) 2018 NewMedia-NET GmbH
Release: 10/10/18

DD-WRT login: root ←ウェブ管理画面のIDではなくroot固定
Password:  ウェブ管理画面のパスワード
==========================================================
 
     ___  ___     _      _____  ______       ____  ___ 
    / _ \/ _ \___| | /| / / _ \/_  __/ _  __|_  / / _ \
   / // / // /___/ |/ |/ / , _/ / /   | |/ //_ <_/ // /
  /____/____/    |__/|__/_/|_| /_/    |___/____(_)___/ 
                                                     
                       DD-WRT v3.0
                   http://www.dd-wrt.com
 
==========================================================


BusyBox v1.29.3 (2018-10-10 10:31:23 CEST) built-in shell (ash)

root@DD-WRT:~# ifconfig -a
ath0      Link encap:Ethernet  HWaddr 00:18:84:**:**:**  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:1312 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

br0       Link encap:Ethernet  HWaddr 00:18:84:**:**:**  
          inet addr:192.168.6.3  Bcast:192.168.6.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:17146 errors:0 dropped:1137 overruns:0 frame:0
          TX packets:14406 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2289843 (2.1 MiB)  TX bytes:6917309 (6.5 MiB)

eth0      Link encap:Ethernet  HWaddr 00:18:84:**:**:**  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:17372 errors:0 dropped:210 overruns:0 frame:0
          TX packets:14406 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2599090 (2.4 MiB)  TX bytes:6917309 (6.5 MiB)
          Interrupt:4 Base address:0x1000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING MULTICAST  MTU:16436  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:576 (576.0 B)  TX bytes:576 (576.0 B)

wifi0     Link encap:UNSPEC  HWaddr 00-18-84-82-7C-09-00-00-00-00-00-00-00-00-00-00  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4941 errors:0 dropped:0 overruns:0 frame:357
          TX packets:3076 errors:249 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:295 
          RX bytes:628880 (614.1 KiB)  TX bytes:239700 (234.0 KiB)
          Interrupt:3 Memory:b0000000-b000ffff 

root@DD-WRT:~# lsmod
Module                  Size  Used by
shortcut_fe            84464  0 
nf_nat_h323             4224  0 
nf_conntrack_h323      32960  1 nf_nat_h323
ath_ahb               254608  0 
ath_hal               121760  2 ath_ahb
root@DD-WRT:~# dmesg
<5>[    0.000000] Linux version 3.2.102 (root@linux) (gcc version 8.2.0 (OpenWrt GCC 8.2.0 r7577-d14647dd59) ) #44536 Wed Oct 10 10:32:30 CEST 2018
<6>[    0.000000] bootconsole [early0] enabled
<6>[    0.000000] CPU revision is: 00019064 (MIPS 4KEc)
<6>[    0.000000] Determined physical RAM map:
<6>[    0.000000]  memory: 01000000 @ 00000000 (usable)
<4>[    0.000000] Zone PFN ranges:
<4>[    0.000000]   Normal   0x00000000 -> 0x00001000
<4>[    0.000000] Movable zone start PFN for each node
<4>[    0.000000] early_node_map[1] active PFN ranges
<4>[    0.000000]     0: 0x00000000 -> 0x00001000
<7>[    0.000000] On node 0 totalpages: 4096
<7>[    0.000000] free_area_init_node: node 0, pgdat 8026bc70, node_mem_map 802c2000
<7>[    0.000000]   Normal zone: 32 pages used for memmap
<7>[    0.000000]   Normal zone: 0 pages reserved
<7>[    0.000000]   Normal zone: 4064 pages, LIFO batch:0
<7>[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
<7>[    0.000000] pcpu-alloc: [0] 0 
<4>[    0.000000] Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 4064
<5>[    0.000000] Kernel command line: console=ttyS0,115200 root=1f02 rootfstype=squashfs noinitrd  init=/sbin/init
<6>[    0.000000] PID hash table entries: 64 (order: -4, 256 bytes)
<6>[    0.000000] Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
<6>[    0.000000] Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
<4>[    0.000000] Primary instruction cache 16kB, VIPT, 4-way, linesize 16 bytes.
<4>[    0.000000] Primary data cache 16kB, 4-way, VIPT, no aliases, linesize 16 bytes
<6>[    0.000000] Memory: 13376k/16384k available (1974k kernel code, 3008k reserved, 309k data, 144k init, 0k highmem)
(大量なので最初の部分だけ)

関連記事:

KDE neonの更新

KDE neonの更新 1

KDE neonは非常に良くできたLinuxのディストリビューション。
簡単なのでPCのド素人にもお薦めできるし見た目もショボくない。
と、思って昨年より愛用してたんだけど、昨年末頃から標準のソフトウエア管理ツールのDiscoverの更新機能が正常に機能しなくなっていた。WindowsでいえばWindows Updateが機能しないようなもの。

すぐに修正されるかなと思っていたが待てども解決されず。もちろん、公式サイトから今年に入ってリリースされた最新版のイメージファイルをダウンロードしたクリーンインストールしたものも同様。
更新するべきソフトウエアの件数だけは通知されるがGUIだけではどうにもできず。

KDE neonの更新 2
標準のソフトウエア管理アプリのDiscoverで更新の確認を行うと更新対象のパッケージがリストアップされて、上の画像の右上の赤い四角の部分が本来であれば[Update All]などの押せる状態のボタンに変わる筈だが、更新確認完了にならず、灰色表示のままで押せるボタンの状態にならない。もちろんリストアップされた更新対象のパッケージも更新できない。

KDE neonの更新 3
KDE neonのFAQページには上のように書かれている。ところが、これは書かれたまま実行しても延々といつまで経っても終わらない更新作業になる。おそらく普通の人は途中で諦めるかと。そして、昨日まではターミナルでコマンドを打って更新してもDiscoverで更新できる状態にはならなかった。

% sudo -s
[sudo] foobar のパスワード: ************************
# pkcon refresh -y
# pkcon update -y

sudo -sで管理者に昇格せずsudo pkcon 〜の方がLinuxの流儀かも。
どちらにしても -yを付けて実行する。これで自動進行する。

KDE neonの更新 4
昨日の更新でDiscoverの更新機能が一部or全部正しく機能するようになったみたい。少なくとも更新確認は完了するようになった。
手動で更新し終わったばかりなので新しい更新ファイルが無くて正常に更新が出来ることは確認できていない。

ただ、昨日の更新をしたら一部アプリ見た目との挙動が変になった気が・・・

同日追記:
と、思ったら、すぐに新しい更新が来たので早速Discoverで更新してみた。

KDE neonの更新 5
更新するべきパッケージのリストが表示されて、それを更新するためのボタンが押せるようになっている。このボタンが押せないという異常がおよそ3ヶ月ほど続いたのよねぇ。

KDE neonの更新 6
画像では判らないだろうが、正常に更新が完了した。そして右上の の更新するべきパッケージがあるか確認するボタンが押せて、その確認が正常に完了する。つまり更新周りの異常は無くなり正常になった。

WordPressのGoogle XML Sitemapsプラグインとサイトマップ

WordPressのGoogle XML Sitemaps (XML Sitemap Generator for WordPress)プラグイン。今回は何かとトラブルと誤解の多いこのプラグインについて。

この記事では2019年2月12日現在で最新のGoogle XML SitemapsプラグインのVer.4.1.0について書く。
バージョンついでで書くと、このプラグインもバージョンを重ねていろいろ変わっている。ここ数年の特に大きな変更はVer.4.0でサブサイトマップを出力するようになったこと。機能改善以外では、最近では2018年の1月(と12月)に脆弱性がが見つかって話題になった。少なくとも4.1.0(現在の最新版)以外の古いバージョンは使ってはいけない。
インターネットの情報を見ると何故か古いVer3.X.Xをにダウングレードして使うというバッドプラクティスがオススメ情報みたいな形で広まっているようだけど、ダメよ。おそらく元の情報が4系の初期のころに書かれたとかサブサイトマップの表示に必要なURLリライトの一手間を知らないまたはURLリライトができない環境向けなんだと思うけど、URLリライトが出来ない環境を除いてはv3系などは使わず最新版を使って下さい。URLリライトができない環境ならGoogle XML Sitemaps以外のURLリライト不要なプラグインを使うべき。

サイトマップはただのURLリスト

Google XML Sitemapsの仕事は基本的にはサイトマップを出力するだけ。最近は検索エンジンに通知する機能なども追加されてるみたいだけど、メインはあくまでサイトマップ。
サイトマップというのはウェブサイトによっては人間の閲覧者向けに記事一覧とかウェブサイトの構成を表示してくれるところもあるようだけど、今回のは主に検索エンジン向けのサイトマップで、XML(他形式もあり)で書かれたウェブサイト内のページのURL一覧のようなもの。XML形式ではそれぞれのページの最終更新時間や更新頻度や重要度も合わせて記載されるが、ぶっちゃけただのURLリスト。特にXML以外の例えばテキスト形式のサイトマップではURLしか書かない超単純リストだし。それがサイトマップ。全く謎技術じゃない。

そんな単純なリストを出力するだけ(ちょっと付加機能あり)のプラグインがGoogle XML Sitemaps。
それが正しく動かないという場合は、よくあるのは他のSEO系のプラグインにサイトマップ出力機能があってコンフリクトしてるとか、WordPressが最低限動く程度しかメモリが割り当てられてないのに他のたくさんのプラグインと共に動かしてメモリ不足だったりとか。他にもいろいろありそうなので「Google XML Sitemapsではトラブルは起きません」とは言わない。でも多くは利用する側の間違いか勘違いか無茶。

ページ数の膨大なウェブサイトのサイトマップを1つのリストに記載すると検索エンジンが膨大なURLの途中までしか読んでくれないかもしれないし、巨大なサイトマップの作成にはメモリが多く必要になるのでサイトマップを分割して出力することには意味がある。一応決まりとしては1つのサイトマップあたりの上限は5万URLでファイルサイズ50MBということになってるけど、大量に書かれていても何処まで読むかは検索エンジン次第。超巨大ウェブサイトでなくても基本分けろ。Google XML Sitemapsのv4系では投稿記事と固定記事(と他フォーマットも)をそれぞれ月別で分割するみたい。メインのサイトマップにはサブサイトマップの在り処を書かなくてはならないけど、他にはどのようにサイトマップを分けるかという決まりは無いので月別にしなければならないというわけではないがGoogle XML Sitemapsではそうやってるというだけ。

Google XML Sitemapsプラグインの設定

Google XML Sitemapsプラグインのインストールは省略。
Google XML Sitemapsの設定はWordPressの管理画面のメニューから[設定]→[XML Sitemap]にある。

Google XML Sitemaps 1
XML Sitemapsの画面。
XML Sitemapsv4系では上の画像の赤枠のところにURLリライト設定の追加が必要な旨が書かれている。英語と意味不明な文字が並んでるようにしか見えない人は意味が解らなくて読み飛ばすみたいだけどダメよ。
これを無視するとメインのsitemap.xmlは出力されるがサブサイトマップは(出力はしていても)表示されないことになる。 そうすると当然検索エンジンがサブサイトマップを見ることができないので、サイトマップを使ってクロールされる筈の分がインデックスされないことになる。これはGoogleのSearch Consoleを使ってたら(そのうち)警告が来るので判ると思うけど。

赤枠の部分に書かれているコードはApache用なので多くのレンタルサーバではそのまま使える筈。WordPressのトップディレクトリと同じ階層にある.htaccessファイルに追記するだけ。無ければファイルを作成。WordPressをサブディレクトリに置いてる場合は書かれていることをよく見て必要に応じて適切に変更。

Apache用の例 (プラグイン設定画面に書かれてるまま)
1
2
3
4
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^sitemap(-+([a-zA-Z0-9_-]+))?\.xml(\.gz)?$ /sitemap$1.xml$2 [L]
</IfModule>
(上のコードがそのまま使えるとは限りません。)
使っているHTTPサーバがApache以外ならそれ用に書き換える。現在は稼働中のウェブサーバに応じたコードが表示されるのでそのまま使えることが多い。Nginx用の例 (次)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.example.com;

    #WordPressホスト用の設定 ホゲホゲ (省略)

    #Google XML Sitemaps用設定 (4行挿入)
    rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml$ "/index.php?xml_sitemap=params=$2" last;
    rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml\.gz$ "/index.php?xml_sitemap=params=$2;zip=true" last;
    rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html$ "/index.php?xml_sitemap=params=$2;html=true" last;
    rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html.gz$ "/index.php?xml_sitemap=params=$2;html=true;zip=true" last;
}
(上のコードがそのまま使えるとは限りません。)

Apacheの.htaccessなら書き込めばその設定がすぐ有効だがApacheの.htaccessではない設定ファイルに書いたとか上のNginxの設定を書いたという場合はHTTPサーバの再起動か設定再読込が必要。

Google XML Sitemaps 2
Google XML Sitemapsの設定画面に戻り下にスクロールする。
画像中にメモを書いたが、画像に見えている部分の設定は「変更する必要無し」と言いたかった。
「基本的な設定」の部分は環境に合わせて、または自分の好みで変更。
設定を変更したなら一番下までスクロールして[設定を更新]ボタンを押す。

サイトマップを表示する

Google XML Sitemaps 3
サイトマップは基本的にはウェブサイトのトップディレクトリに置くことになっている。サブディレクトリに置いた場合はそのサイトマップには別のディレクトリのページのURLは含めてはいけないということになっている。含めてもクロールはしてくれないらしいのでインデックスに登録されないということになる。(ここまで数行は手動設置の場合)
Google XML Sitemapsではウェブサイトのトップディレクトリにsitemap.xmlが置かれて(仮想だけど)、そのメインサイトマップにサブサイトマップのURLが書かれる形となる。自動で行われるのであまり気にしない。
つまり、http://example.com/sitemap.xmlをブラウザで開けば(メインの)サイトマップが表示される。 なんか綺麗に見えるリストだが、最近のブラウザでは右クリックでそのページのソースを表示できる筈なのでソース(XML)を表示して見て欲しい。(次)

Google XML Sitemaps 4
これがXMLで書かれたサイトマップ。
で、上の画像の赤枠の部分を確認して欲しい。正しくGoogle XML Sitemapsが出力したサイトマップであれば赤枠部分のように、Google XML Sitemapsプラグインの作者のウェブサイトのURLである http://www.arnebrachhold.de と、プラグインのバージョン (上の画像では4.1.0)がある筈。さらにサイトマップの出力日時も何日も何週間も何ヶ月も前でないこと。今日プラグインを初めてインストールしたなら今日付け。
これはメインのサイトマッブなので<sitemap>〜</sitemap>という形式でサブサイトマップの在り処が書かれている。

Google XML Sitemaps 5
そのメインのサイトマップを一番下までスクロールする。上の画像の赤枠の緑字の部分(表示するブラウザによっては緑とは限らない)に出力のための処理時間や使用したメモリの量が表示されていて警告だとかエラーが発生していなければ、メインのサイトマップは正しく出力されていると思って良い。

Google XML Sitemaps 6
ソースを閉じて綺麗なリストの方から月別のサブサイトマップの1つ(1行)をクリックする。
これがサブサイトマップの例。一見メインのサイトマップとそんなに変わらない。さきほどと同様に右クリックしてソースを表示する。
ここで、サブサイトマップが表示されずにerror404になるとかWordPressの(トップ)ページ等が表示される場合はURLリライトの設定が間違っているかURLリライトが機能していない。とにかく要対応。

Google XML Sitemaps 7
サブサイトマップのXML。先程と同様にプラグインの作者のウェブサイトのURLがあってバージョンが正しいこと。さらに一番下に(スクロールして)出力処理時間などが表示されていてエラーが無いことを確認する。
このサイトマップに書かれているのは記事のURLなので<url>〜</url>という形式になっている。

ここまで問題無いようであれば、GoogleのSearch Consoleに登録する。

Google XML Sitemaps 8
Search Consoleの新しい方
左列のメニューで[サイトマップ]を選択し、右列で「新しいサイトマップの登録」を行う。基本的にはsitemap.xmlと入力して[送信]を押すだけ。
サイトマップの送信はすぐに出来ている筈だが、数日置いてから確認する。ステータスが「成功しました」になること。上の画像には表示されていないがステータス表示の右の方に検出されたURLの件数(サイトマップからGoogleに認識されたURLの数)も出る。
これだけ。

Google XML Sitemaps 9
Search Consoleの古い方(旧ウェブマスターツール)
すでに新しいSearch Consoleを使っているならこちらを使う必要はない。ただ、今も使えるというだけ。
左列のメニューで[クロール]、[サイトマップ]を選ぶ。
右列の[サイトマップ追加テスト]ボタンを押して sitemap.xml を入力して登録する。
登録はすぐに行われる筈だが、確認は後日。確認するのは「送信」されたURL数。ここがいつまで経ってもサイトマップに含まれるURL数に遠く及ばないなら「嫌だね」レベル。サイトマップに何か問題があれば下の方に何かの警告が出る。警告が無いならまだ全て処理されていないと思われる。
「インデックスに登録済」の数をやたら気にする人がいるが、こちらはサイトマップで通知されたURLをさらに後日に全然別処理のクローラーがページ取得に来て、それが検索のインデックスに登録されてはじめて数に入るもの。数日で全て登録されればラッキーで、(全て|殆ど)が登録されるまで数週間とかもザラ。また、サイトマップの送信数とインデックス登録数は必ずイコールになるわけではない。

Google XML Sitemaps 10
警告がある場合。
「警告数」をクリックすると上の画像のように警告の内容が表示される。
この画像の場合だと、「サイトマップエラー」で「URLにアクセスできません」となっているが、実際にはサイトマップ(サブサイトマップ)にアクセスできないというのではなく、サイトマップ(サブサイトマップ)に記載されているURLの1つまたは複数にアクセスしようとしたら失敗したというもの。この画像の例では2015年4月のサブサイトマップに書かれているURLの1つにアクセスできなかったというもの。で、このアクセス失敗は自分のサーバー側が正常であってもときどき発生する。クローラー側の問題であったり通信経路の問題であったり本当にたまたまであったり。なのでアクセス失敗の1つ2つなら全然心配する必要無し。

Search Consoleを使うならこれだけはおぼえる

Googleはすぐにやってくれない