現在ではFTTHも1Gbps以上となり、ルータにもそれなりの処理能力が必要とされる。
ウチにあるルータは少々古いものではあるが、比較する機会があったのでやってみた。

通信相手はインターネット経由のサーバなので、3回の計測→ルータを変更して3回の計測→ルータを変更して3回の計測→最初のルータに戻して3回の計測→………最初のルータに戻して3回の計測と、合計27回の計測を行い、ダウンロード速度の最も早いものを選んだ。

計測ごとの速度のばらつきは6%程度あった。
実験は平日の午前中、サーバや回線が比較的空いているであろうと思われる時間帯に行った。

WXR-1900DHP3

IPv6+用に最初に購入したのがWXR-1900DHP2だった。
しかし接続が不安定で、後にWXR-1900DHP3に無償交換された。
しかしそれでも回線断が度々起きる事から、現在はIPv4接続用に使っている。
IPv4であれば極めて安定して接続が出来る。

無線LANはCANONのプリンタ専用に設定している。
キヤノンのプリンタは40MHz幅では接続できない(非常に不安定)ので、20MHz幅のAPを立てなければいけない。
現在のプリンタは改善されているかも知れないが、MG5350はダメだ。
当初は20MHz幅でも接続が不安定で、まともには使えなかった。
キヤノンには散々文句を言い、サービスセンターに足を運び、同じモデルを2台買って個別不良では無い事を証明するなど、下らない手間をかけた。
それでもキャノンは不良を認めなかったが、後にファームのバージョンアップが行われて20MHz幅であれば何とか接続できるようになった。

V6+のパフォーマンスは余り良くない。
製品が古いと言う事もあるのだろうが、我慢すれば使えるかな程度のものでしかない。
v4接続の方が速度は出て、600Mbps前後まで行った。

Aterm WG2600HP3

WXR-1900DHP3に交換後も度々接続断が起きた。
これ以上メーカに言っても改善は難しいと判断し、NEC製に買い換えたのがこれである。
当初は上り・下り速度共に遅くて話にならないくらいだったが、ファームのバージョンアップによって使えるレベルになった。

V6+の接続は安定しているが、切断は皆無では無い。
ただし切断がルータに起因するものか、JPNE側がいけないのかはよく分からない。
大抵は放っておくと勝手に再接続される。
バッファロー製はハングアップ状態となり、電源を入れ直さないと復活しなかった。
それに比較すれば、待っていれば再接続されるので我慢は出来る。

これは壁に付けているのだが、ルータの背面にはヒートシンクを付けている。
ヒートシンクの下には小型のファンを付けて冷やしている。
CPUは筐体に対して放熱するような設計になっているのだが、その筐体は相当熱くなる。
筐体に貼り付けたヒートシンクも軽く40℃を超える。

スループットはそこそこの数字が出る。
これは回線速度なのか？ルーターの速度なのか？判別できない。
専用のサーバを立ててローカルでテストしない限り、正確な速度は分からない。

ただしV6+(V4のコンテナを入れるような仕組み)の制御やフィルタなどの処理が重いと思われるので、単にWAN側とLAN側でルーティングをさせるだけなら目一杯の速度が出ると思う。

数字を見て分かるようにアップロード速度は遅い。
これはファームのバージョンアップ前からそうであり、このモデルの欠点と言える。

WN-AX1167GR2

このルータは通常は使用していない。
V6+接続が可能と言う事で引っ張り出してみただけである。
なおV6+非対応のルータは他に2台あり、HUBの代わりとして使っていたりする。

WN-AX1167GR2は2016年頃に発売が開始され、2021年まで販売が続いていたものだ。
V6+対応機として需要があったのだと思う。

速度は我慢できないほど遅い。
発売時期や価格を考えれば致し方ない所ではあるが、無線区間の速度867Mbps(理論値)を誇るものとしては、少々情けなく感じる。

現時点でNEC製だとAterm WX6000HPが最新だろうか。
スループット1.6Gbpsを誇り、WAN側は10Gbpsに対応するがLAN側は1Gbpsが最大だ。
無線の理論最大速度は約4.8Gbpsとなる。
ただし実効スループットを見ると有線接続(フィルタなし)で940Mbps、無線で4040Mbps(暗号化なし・至近距離)となり、有線接続に関しては1Gbpsモデルと差はない。

バッファローはWXR-6000AX12Sが、有線ポートに2つの10GbE端子(WAN側とLAN側1つ)を持ち、無線区間の理論最大速度は約4.8Gbpsだ。
有線接続(HUBとして？)でのスループットは9.6Gbpsだと書かれている。

I・OデータはWN-DAX3600XRがWAN側とLAN側1ポートが10GbEに対応するが、無線区間の最大は約2.4Gbpsに留まる。

FTTHも速度が上がり、1Gbpsでは物足りなくなる時代がやってきている。
ただNECのWX6000HPなどは、ポートとしては10Gbpsに対応しているものの内部処理は1Gbpsモデルのままなのだろう。

にほんブログ村

これは読み物みたいなものです

従来はMovableTypeを使っていたわけだが、これはWordPressである。
WordPressのインストール経験はあったので、凄く苦労したと言う事はない。
ただし、誰にでも出来るかと言えばそう簡単ではないのも事実だ。

サーバ側で全ての準備が整っていれば、つまり必要なプログラムなどが揃った状態で、更には設定もある程度行われているならば、WordPressの言うように数十分以内に構築は完了するだろう。
しかし自前のサーバにインストールするとなれば、その必要なソフトのインストールや設定もあるので時間がかかる。

WordPressはPHPで書かれていて、ページはダイナミックに生成して送り出される。
MovableTypeはPerlで書かれていて、ページはスタティックに生成されている。
WordPressはダイナミック生成なので自由度が高く、設定変更はすぐに反映されるが、サーバの負荷は重い。
MovableTypeは設定変更に伴う再構築に(F&Fの場合、数万記事で)数時間を要したが、再構築時以外はサーバ負荷は上がらない。

MovableTypeでもWordPressでもテーマファイルを使用して外観を決める。
有料/無料の様々なテーマがあり、殆どの人はそれらの中から自分の求めるものを選び、ごく少数の人は注文によってデザインを作り上げることになる。

私はこの記事作成時点ではLION BLOGを使っている。
最初は有料版のページを、たまたま検索したらそれが出たのだが、見ていた。そうか、有料なのかと思っていたところ、無料版もあると言うことで試してみた。

デザインに大きな要求はないわけだが、元々のBlogに似た感じが良いなとは思った。新たに採用するデザインが優れていたとしても、継承というものはある程度大切だと思っている。それが良いか悪いかではなく、従来のスタイルを余り崩さないことが、これを見て頂けている人たちに対して混乱を与えない事だと思う。

勿論自分でデザイン出来れば良いのだが、残念ながらデザインセンスのかけらも持ち合わせていない。
私にデザインを考えろというのは、文系の人にQAM変調器の回路図を書けと言っていることと同じ位馬鹿げている。

WordPressのシェアは年々上昇している

2011年には13％程だったWordPressのシェアは、2019年には37%にまで上昇している。
一方で大規模サイトなどではMovableTypeのシェアが高いと、販売元であるシックス・アパート株式会社は言っている。

MovableTypeは米国のシックス・アパート社が開発したものだが、2011年の2月に日本の法人であるシックス・アパート株式会社がそれを継承した形となっており、現在のバージョンは日本製と言っても良いくらいのものである。

WordPressなどオープンソースのシェアは高いわけだが、国内企業に於いてはサポートやセキュリティに対する保証を重視する傾向から、MovableTypeが使われているとの分析もある。
個人から中小企業の膨大なページ、中堅や大企業のシステムを一緒に数えるのが正しいのかどうかは分からないが、使われている数としてWordPressがトップなのは間違いはない。

WordPressやMovableTypeの他にもCMSは多数ある。Adbeのものも使われている。各CMSはそれぞれ特徴を持っているわけだが、その解説はこちらのページを参考にして頂きたい。
なおMovableTypeも個人利用に於いては無料である。

CMSを構築するサーバの問題

F&FのページはさくらのVPSで動いている。
OSはFreeBSD12である。
今時FreeBSDで構築する人は相当少ないと思う訳で、普通はさくらVPSの標準であるCentOSを使うだろう。

ある程度の知識があればOSのインストールからソフトのインストールや設定まで出来るが、全くunixを触ったことがない人が始めるのは容易ではない。viの使い方然り、コマンド然り、全てを覚えていかなければいけないからだ。
しかし、それは誰しも同じ事である。
俺は幼稚園の頃からunix使いだったぜ、なんて人は滅多に居ない。
どこかで覚える必要があり、覚える気であればおそらく誰にでも覚えられる。

VPSなどに自分でサーバを構築していくのは、もっとも自由度が高いが難易度も高い。

いわゆるレンタルサーバがある。
さくらにもあるが、BlogのシステムやWordpressがインストールされた状態になっている。
レンタルサーバなのである程度自由度もあるが、大きな変更は出来ない。
これは既に準備が整った状態でレンタルする事が出来るので、デザインや使用上の設定などを行うだけですぐに運用が開始出来る。
さくらのレンタルサーバは、もっとも安価なもので月額換算131円である。

131円のプランではWordPressは使えず、さくらのBlogのみになる。
さくらのBlogはSeeSaaに似ているが、機能や自由度は多少劣る。
WordPressやEC-CUBEのインストール出来るものは月額524円が必要だ。

さくらのレンタルサーバのOSはunix系ではないかと思うが、Windowsサーバを使ったレンタルサーバ屋もある。
unix系になれているとWindows系はちょっと面倒な感じが私はするが、それでも以前にWindows系のサーバでEC-CUBE(ショッピングバスケット)のシステムを構築したことがあった。
まあ、やってみれば似たようなもの、とまでは言えないが、全く異質なものでもない。ただサーバの安定度が悪く、ダウン時間が多かった。

レンタルサーバよりも自由度が少ないが、すぐに始められるものがBlogサイト運営会社を使う事だ。
F&FでもSeeSaaを使っているが、そういうことである。

SeeSaaやAmebaでも無料版では広告が入る。
広告を取り除くためには有料契約が必要になるが、その料金はレンタルサーバ代より高い事もある。
従って、中・長期運用を、広告無しで考えるならばレンタルサーバの方がお得ではないかと思う。

もちろんBlog運営会社のメリットもあり、それはシステムのセキュリティやバージョンアップを全て運営会社がやってくれると言うことだ。

セキュリティが重要

WordPressはページ送出プログラムが動いているわけだから、何の実行も伴わないHTMLファイルが並べてあるだけのサーバよりもずっと攻撃に弱い。

F&Fサーバのログを見ても、WordPressディレクトリの様々なファイルにアクセスしようとする様子が分かる。
WordPressをインストールするとそのディレクトリ構造やファイル名が既知であるが故に、真っ暗な部屋に入った泥棒的ではなく、そこに何があるか分かって盗みに来る悪人の様相を呈する。
更にセキュリティホールがあればそこを突いてくるわけで、そうしたアタックから身を守る仕組みが必要になる。

dos攻撃にも弱く、これはページの送出にCPUパワーが食われるからだ。

F&Fではfail2banを使って監視＆ブロックしている。
Port25/587へのアタックに比較すればマシではあるが、それでも毎日いくつかのIPアドレスを遮断している。

WordPress本体のみではなく、プラグインにもセキュリティホールは存在する。
或いは悪意を持ったプラグインもある。
厄介なのは、どのプラグインが危険かが分からないことだ。
被害を受けて始めて分かるみたいな事も少なくは無い。

サーバへの侵入を許せば何でも出来てしまう。
プラグインからindex.phpを書き換え、そこを突破口として好き勝手に中をイジられる。

にほんブログ村

記事の内容に対する広告であれば固定の広告を貼ればいいわけだが、広告を余り意識していないサイトなどでは、いくつかの広告をローテーション表示させたいことがある。

また広告の配信が停止した場合の処理なども含め、プログラムで管理したいところだ。以前使っていたMovableTypeでは、静的ページ構成だったのでHTMLの中でPerlを実行させるコードを書き、広告のローテーションや入れ替えは、そのPerlプログラム内で管理していた。

しかしWordPressでは動的なページ生成になるためPerlが上手く動作せず、今回はプラグインを使って解決することにした。

使用するプラグインはAds by datafeedr.comである。

基本設定

管理画面左メニューの[設定]→[Ads]から行う。
Adsのメニューは設定項下とダッシュボード直下にある。

Ads Asnib Panelと書かれた、ここでの設定は以下の2カ所にチェックを入れるか否かのみだ。
Enable shortcodes in Text Widgets:
テキストウィジェットでショートコードを利用するか？
Enable ad impression count for admin(s)
管理者によるアクセスでも広告表示カウンタをインクリメントするか？

この2点のみを決めて[変更を保存]をクリックする。
なお下のShortcode / PHP Template Code Generatorは、単なるコードゼネレータなので設定には関係しない(後述)。

グループ設定

ここからはダッシュボード下のAdsボタンをクリックして行う。
Ads→Groups
1つのページにいくつかの広告を貼りたい場合がある。
例えば記事の上には468×60の横長バナーを、例えば記事の横には300×250の広告を、と言う具合だ。

こうした異なる広告を使う場合に、グループ分けをする。
グループ名称は任意で、ページに表示されることは無いと思う。
各広告そのもののコードを作成する画面でグループ設定を行う。
また、広告コード作成時点でのグループ追加も可能だ。

広告コード設定

Ads→Add New Ad
この画面で実際の広告コードを貼り付ける。
貼り付け画面はテキストエディタ画面だ。

タイトルは自分が分かれば良い。
右側にGroup設定があるので、ここでグループを選択する。
私の場合は広告サイズでグループを決めているが、例えば記事のカテゴリなどによって、より細分化させる必要があるかも知れない。
新しいグループを作る場合は、Add New Groupをクリックする。

広告によっては開始日と終了日が規定されているものがある。
広告終了日以降にはその広告が表示されなくなったり、配信社のロゴに入れ替わったりする。
こうした広告の場合は、StartDateとEndDateを設定することが出来る。
何も設定しなければ、即時開始、非終了となる。
広告コードの入力が完成したら[公開]をクリックして終了だ。

広告コードの取得

ウィジェットを使って広告を表示されるのだが、そのウィジェットに貼るための広告コードを取得する必要がある。
ここでShortcode / PHP Template Code Generatorが必要になる。
(ある程度分かってくれば、自分でコードを書ける)

設定→Ads

ウイジェットにコードを貼る場合にはShortcodeにチェックを入れる。
Groups→表示させたいグループ
number of Ads→表示させる広告の数(単体表示なら1)
Order By→ランダム表示や表示数順などが選べる
他の設定はデフォルトで(通常は)良い。

これはあくまでもコードゼネレータであり、設定を変化させるものではない。
各設定項を変化させて生成されるコードを見れば、これを使わずにコードを作ることが出来る。

ページへの広告表示

外観→ウィジェット

広告コードを取得したら、それをウィジェットに貼る。
コード(修飾文字列ではない)なので、テキスト入力画面に切り替える。

画面はテーマやスキンによって異なると思うが、フリーテキストの入力が出来る画面で、取得した広告のコードを貼る。
広告コードの一例は下記

これで広告が表示されているはずだ。
(実際のコードを貼るとここに広告が表示されるので、画像としている)

広告が表示されない場合

広告が表示されない場合は、以下2点をまずチェックする。

1．広告コードは誤っていないか？
2．ウィジェットへの貼り付けは”テキスト”で行ったか？

広告コードに関しては、それがWordPress上で表示可能であるか否かの判断になり、難しい。
ただし(あくまでも経験談)、通常のウイジェットに貼り付けても動作しない広告でも、Ads by datafeedr.comでは動作したことがある。
簡単なHTMLコード或いはPHPのコードを書き、広告配信会社で指定された広告コードそのものをテストする必要があるかも知れない。
なおAdsenseに関しては、掲載媒体を変更すると一時的に広告配信が行われなくなる場合があり、数十分から数時間後にチェックした方が良いかもしれない。

ウィジェットへの貼り付けを”ビジュアル”で行ってしまうと、プラグインはそれを命令コードとして理解出来ない。
“ビジュアル”で行うと、ページにその文字列が表示されるだけである。

にほんブログ村

ipfwもblacklistdもインストールは不要なので、/etc/rc.comfに起動設定を行う。

firewall_enable="YES"
firewall_type="open"
firewall_logging="YES"

sshd_enable="YES"
sshd_flags="-o UseBlacklist=yes"

blacklistd_enable="YES"
blacklistd_flags="-f"
#blacklistd_flags="-r"

firewall_系がipfwの設定で、firewall_type=”open”は全解放状態で起動させる命令だ。
全解放でスタートさせないと、外部からログインが出来ない。
blacklistd_flagsは-fで再起動時に初期化、-rを付けると再起動時にもブロック情報を保持する。

blacklistdで監視が出来るのはSSH/FTP/SMTPである。
これらとipfwをインタフェースするためのソケットを作る。

# touch /etc/ipfw-blacklist.rc

SSHに関しての設定は、rc.confにsshd_flags=”-o UseBlacklist=yes“を追加すれば良い。
FTPは/etc/inetd.confに-Bオプションを付ける。

ftp stream tcp nowait root /usr/libexec/ftpd  ftpd -l -B

これで設定は完了である。
inetdをリスタートすればblacklistdの監視が開始される。

# service inetd restart

postfixはFreeBSD本体のソフトではないので、連携させる作業が必要になる。

portsから入れている場合は、make confでBLACKLISTDのオプションをEnableにする。
make deinstall → make install として入れ替える。

動作確認は、ブロックされても影響のないIPアドレス(スマートフォンなど)からFTPあるいはSSHへの不正アクセスを繰り返せば良い。
なお25番および587番ポートへの攻撃が非常に多い。

02025 86563   5149178 deny tcp from table(port25) to any 25
02587 793096 47582654 deny tcp from table(port587) to any 587

ipfw -a list で上記リストが、ipfw table
ipfw table all list でテーブル内のIPアドレスがダンプ出来る。

kernel: pid 49651 (httpd), jid 0, uid 80: exited on signal 10
kernel: pid 49649 (httpd), jid 0, uid 80: exited on signal 10
kernel: pid 49610 (httpd), jid 0, uid 80: exited on signal 10
kernel: pid 49626 (httpd), jid 0, uid 80: exited on signal 10
kernel: pid 49760 (httpd), jid 0, uid 80: exited on signal 10

/var/log/httpd-eror.logを見ると以下のようになっていた。

[access_compat:error] [pid 36957] [client 157.55.39.62:5907] AH01797: client denied by server configuration:
[Sun Jul 19 07:28:37.757401 2020] [core:notice] [pid 6262] AH00052: child pid 37508 exit signal Bus error (10)
[Sun Jul 19 07:30:46.052387 2020] [core:notice] [pid 6262] AH00052: child pid 37554 exit signal Bus error (10)
[Sun Jul 19 07:33:32.102367 2020] [core:notice] [pid 6262] AH00052: child pid 37606 exit signal Bus error (10)
[Sun Jul 19 07:35:05.879909 2020] [access_compat:error] [pid 37711] [client 207.46.13.209:20594] AH01797: client denied

AH1797はserver configuration Errorとなっている。
Apache2.2までとApache2.4ではアクセス制限の書式が異なり、原因は当該ディレクトリに設置した.htaccessファイルだと思われる。

httpd.confは以前のものを流用せずに、apache2.4のものを編集したので以下のような記述は存在しない。

<Directory />
    Order deny,allow
    Deny from all
    Satisfy all
</Directory>

しかし.htaccessは従来のままであり、アクセス制限の書式が異なっていた。
そこでApache2.4の書式に合わせて以下のように書き直した。

Require all denied
Require host .jp

しかしエラーは消えなかった。
アクセス制限は他のディレクトリでも行っているのだが、それはエラーが出ない。
しかし.htaccessの書式程度のことでコアダンプに至るのだろうか？
理由は不明なるも、対策を急ぎたかったので.htaccessを削除した。
これによってコアダンプは発生しなくなった。

もう一つコアダンプを発生させている原因が見つかった。
PHPのプログラムである。
これは関数自体が無応答になるので、.htaccessの時よりも”それっぽい”感じがする。
鹿も再現が容易なので、ログを見ながら関数をコールすれば良い。

原因が掴めない時にはApacheのhttpd-confから以下の行をコメントアウトする。

LoadModule php7_module libexec/apache24/libphp7.so

これでコアダンプがなくなればPHP系に原因がある可能性が高い。

エラーの状況でserver configurationとexit signal Bus error (10)が出ていたのだが、.htaccessの削除で双方共に発生しなくなった。
なお.htaccessの制限機能自体は、コアダンプ発生時にも正常に動作していた。