サイトの https 化

今時 http なサイトは流行らないのでとりあえず親サービスの SSL を有効化することにした。以下、その手順のメモ。

参考: Let’s EncryptのSSL証明書で、安全なウェブサイトを公開

apache だったので SSL のモジュールを導入
yum install -y mod_ssl

ファイヤーウォールで https を通すように設定
firewall-cmd --add-service=https --permanent
firewall-cmd --reload

証明書の取得をするスクリプトを取ってくる
curl https://dl.eff.org/certbot-auto -o /usr/bin/certbot-auto
chmod 700 /usr/bin/certbot-auto

証明書を取得する
certbot-auto certonly --webroot -w /var/www/html -d <ドメイン名> --email <メール>@<アドレス>
(ドキュメントルートにファイルを置いてアクセスすることで存在確認を取っている)

/etc/letsencrypt/live/<ドメイン名> に証明書ファイルが取得される。これを apache の設定に書き込む。(プロトコル指定は許可リストで指定…参考)

SSLProtocol -All +TLSv1 +TLSv1.1 +TLSv1.2
SSLCertificateFile /etc/letsencrypt/live/<ドメイン名>/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/<ドメイン名>/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/<ドメイン名>/chain.pem

SSL 用の VirtualHost 設定を追加

<VirtualHost *:443>

        ServerName <ドメイン名>
        DocumentRoot /var/www/html

        SSLEngine on
        SSLCertificateFile /etc/letsencrypt/live/<ドメイン名>/cert.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/<ドメイン名>/privkey.pem

        <Directory "/home/lbi/www/html">
                AllowOverride FileInfo AuthConfig Limit Indexes
                Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
                Require method GET POST OPTIONS
        
        CustomLog logs/ssl-access_log combined env=!no_log
</VirtualHost>

XOOPS Cube Legacy を使っていたので設定をSSL対応に修正

 define('XOOPS_URL', (isset($_SERVER['HTTPS'])?'https://':'http://').$_SERVER['HTTP_HOST']);

最後に apache の再起動
systemctl restart httpd

ブラウザで https にアクセスしてみて確認する。

Let’s Encrypt の証明は有効期間が短いので更新を自動で行うように /etc/crontab を設定しておく。

15 3 * * 0 root /usr/bin/certbot-auto renew --post-hook "systemctl restart httpd" 1 > /dev/null 2 > /dev/null

Chuwi Hi8 の Windows 10 update1511 wifi problem

Chuwi Hi8 と言う Windows 10/Android 4.4 な中華パッドが安い割にスペックが高いのでつい買ってしまった。

一通り設定している間に Windows 10 のアップデートの 1511 が出ていたので更新したら Wifi が動かなくなった。ググると同様の障害があちこちで起きているようなのだが、なかなか回復できない。

結局は、Windows に含まれる Broadcom の新しいドライバがハードウェア適合していないのが原因のようで、古いドライバを選ぶことで動作する。

Broadcom 802.11n Wireless SDIO Adapter バージョン: 1.278.1.0 [2014/10/31]
ここが、以下のものになっていたら動作しない。
Broadcom 802.11n Wireless SDIO Adapter バージョン: 1.496.0.0 [2015/08/23]

デバイスマネージャから、ネットワークの上記ドライバを選んで、ドライバの更新で、適合するドライバの中から手動で古いドライバを指定する。

Double Driver ユーティリティでバックアップから復旧と説明して記事があるけど、アップデートしても古いドライバは削除されず残ってはずで、ドライバの更新でそれを選べばよいだけと思う。

perl 書きな日々

perl を使ったコードを書いている。perl は長年使ってるけど、もともとアレな処理系で日々進化もしているので、知らなかった書き方とか結構あったり、使い方は知っていても、深く理解してなかったりと面白い発見ががたまにあるので、そういうのをいくつか書いてみる。

構造体の直値

連想配列や、配列にポインタを入れれば構造体が作れる。でも、直値の書き方、というのを最近まで知らなかった。

my $hoge = { 'a'=>[1,2,3], 'b'=>4 };

などと、連想配列 {} や配列 [] で直値を記述できる。

map で連想配列を返す

連想名 (ハッシュのキー) の配列で、連想配列を初期化する、なんてコードを書くのに、

my %a;
map { $a{$_} = 1; } @keys;

なんてコードを書いていた。しかし、次のように書けばもっとスマートだ。

my %a = map { $_ => 1; } @keys;

これは連想配列の初期化で、配列を代入しているのを考えれば分かりやすい。連想配列に配列を入れる場合、キーと値を交互に渡せばいいだけだ。

専用サーバ vs VPS

Virtual Private Server(VPS) は、基本的な使い方やスペックは専用サーバと変わらず値段が数分の1から 1/10 程度と非常に魅力的だ。とはいえ、相応の違いがあるから、値段が安いわけで、その違いが許容できるかどうかが問題だ。

以前、某 VPS を使ったときの経験では、導入直後は非常に快適で値段の割に性能も高く感心したのだが、それはベストエフォートの顧客が付く前の状況での感想であり、後に性能低下に悩まされることとなった。

実際の VPS のシステム構成を考えれば、大規模な物理サーバの資源を効率よく切り売りするものだ。サーバの絶対性能は大きな能力であるが、詰め込まれる VPS の総量はそれ以上に大きくなる。平均的な利用状況で性能がバランスする見積もり配分したとしてもピーク時にはかなり悲惨なことになるわけだ。

それでも、CPU リソースやメモリは公平に分配しやすいから良い。問題は、ハードディスクの性能(帯域)分配である。もともと (CPU などと比べて) アンバランスな性能の上、RAID などで高性能化しても高が知れている。分離された VPS のインスタンス間で平行にリクエストが発生すれば、性能は悪化する方向で作用する(それぞれ別の領域にアクセするためキャッシュが働き難い)。多くのインスタンスで同時に daily cron の実行が始まったタイミングでエラい目に会う訳だ。

あるミーティングで、VPS を提供する会社の人に直接この辺を質問してみたことがある。
答えとしては、今のところ決め手がなく、インスタンスの再配置でバランスを取る程度と言った話であった。

まあ、結論は、値段相応だよな、と言うところで。

XOOPS なう (2.4RC)

XOOPS 2.4RC が出てたので、ちょいと試してみた。

2.3 はリリースの間が私にとって悪かったので、全然試してなかった。xoops_lib / xoops_data が xoops_trust_path に相当するわけだな。パッケージングが良くないどの批判はあるが、まあインストーラでケアしてある (DocumentRoot 外に出せと表示される)。

インストーラにいろいろ改良の跡がみえる。

  • バージョンや  PHP の拡張チェックがある
  • モジュールの初期導入ステップが分離していない
  • 設定した管理者でログインした状態になる (ログインし直す手間がない)
  • メッセージが多い部分は スクロール領域にして高さを抑制
    (進行ボタンが下のみなのでスクロールする手間が減る)

管理画面が ImpressCMS に似た変更が行われている。まあ、これは見た目は派手だが、個人的には好きじゃない。jQuery が標準に搭載され、様々な部分のインタフェースに使われている。恰好はよい。

とりあえず、自分のモジュールを動作確認。eguide と ccenter は問題なく動くようだ。おっと、ccenter のリソース名のタイポが見つかった。orz

セキュリティ対策ソフトを駆逐する

スラッシュドットなどを見ていると、セキュリティ対策ソフトを導入しないのが決定的な誤りのように言われることが多い。はたして、これは正しいことなのだろうか。

Linux など、Windows 以外の OS ではそもそもセキュリティ対策ソフト(クライアント向けのもの) は存在しない (Mac は多少あるか)。しかし、対策ソフトがないため特に危険だ、と言うわけではない。むしろ、総合的には対策ソフトがある Windows よりも安全であろう。

では、Windows 以外の OS ではどのようにセキュリティを確保しているのか。基本的には次の 2つであろう。

  1. 特権の分離 — 利用者と管理者権限を分ける
  2. セキュリティ修正 (ソフトウェアの更新)

特権を分離することで、システム管理を要する操作 (ソフトの導入や設定変更) を禁止し意図しないものを仕込まれるのを防ぎ、特権取得など、抜け穴を使った攻撃は 2で対応する、と言う訳だ。

もちろん、これをかいくぐった攻撃もあるわけだが、それは対策ソフトでも防げない攻撃があることと本質的には変わらない。つまり、これらの対応で、多くのケースで対策が可能と言うことだ。

さて、こうして見ると、Windows でも、NT 以降同様の運用が可能なのだが、標準状態では特権を分離した設定にはなってない。むしろ通常使うユーザに管理権限を持たせるのが普通の運用になってしまっている。Vista では、UAC 導入で改善されているのだが、各地でこれを抑制する記事が出る始末だ。

まあ、一般的な環境は別として、Windows でもきちんと特権分離を行えば対策ソフトを使わなくてもそんなに危ない状態にはならないと思う。

そんなことで、私の回りの Windows は、管理者権限を持たない利用ユーザを使うことで、セキュリティ対策ソフトをアンインストールして使っている。

WordPress セキュリティ更新リリース

何気にニュースサイトを見てたら、wordpress のセキュリティ更新リリース 2.8.4 のニュースが目に入った。つい先日、2.8.3 を見つけてパッケージを作ったばかりなのになぁ。

修正内容を見ると何かヤバげなので、一応パッケージを作成してサービスに登録した。データベースイメージの更新は保留で、新規導入時に更新要求がでるがまあ問題ないだろう。

パッケージ導入メニューで更新が失敗したのだが、これの原因調査と対応をやらないといけない。orz

MySite の更新問題

サイト構築の仕組みでしばしば問題になるのは、更新の問題だ。

ソフトウェアパッケージの更新は比較的簡単である。基本的には、新しいファイルの置換するだけで済むからだ(厳密にはカスタマイズ部分の扱い問題がある)。問題は、コンテンツであるデータベースの中身の更新だ。これには決まった手順がないので、ソフトウェア毎に異なる手順を踏む必要がある。たとえば、

  • XOOPS — モジュール毎に管理画面からアップデート
  • WordPress — 管理画面でアップデート状態を確認
  • MediaWiki — シェルで maintenance/update.php を実行する

のようにさまざまである。

さらに、初期状態 (新規構築時) のデータベースイメージを最新に保つのも大変 (作業が面倒) なので同期がとれないこともしばしば。メンテをルーチン化したり、自動化すれば良いのだがそこまでコストを掛けられない。悩ましいところだ。