4年ぶり更新です。60余齢でいまだにこんな鯖缶をやっている自分を褒めたい。（還暦を過ぎたのでサブタイトルを変更しました。）

先日、管理している複数のCentOS7サーバで、こんなエラーを吐き出した。

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
An unexpected error occurred:
SSLError: (“bad handshake: Error([(‘SSL routines’, ‘ssl3_get_server_certificate’, ‘certificate verify failed’)],)”,)
Please see the logfiles in /var/log/letsencrypt for more details.

どうやらLet’s Encrypt の更新エラーらしい。いくつかのSSLサイトで警告画面が出る。

困った。エラーは心臓に悪い。

こういうときのgoogle先生で、原因はLet’s Encrypt のルート証明書の仕様が変わったためで、「DST Root X3」が certbot で更新できなくなったとのこと。
「Let’s EncryptのルートCA証明書期限切れ、多数のサイトで問題発生」
　https://japan.zdnet.com/article/35177496/
「2021年にLet’s Encryptのルート証明書が変更！影響や備えておくべきこととは？」
　https://ssl.sakura.ad.jp/column/letsencrypt-root-certificate/

原因がわかれば対応方法があるはず。

いままでパッケージ管理yumでcertbotを更新していたが、このyumの標準パッケージが仕様変更に対応していない、ということがわかったので以下のようにパッケージ管理snapで対応した。

１．まずは既存のcertbotを削除する。
　　# yum remove certbot

２．EPEL経由でsnapをインストール、起動、シンボリックリンク作成
　　# yum install snapd
       # systemctl enable –now snapd.socket
　　# ln -s /var/lib/snapd/snap /snap

３．snap経由でcoreをインストール、リフレッシュ
　　# snap install core
　　# snap refresh core

４．snap経由でcertbotをインストール、シンボリックリンク作成
　　# snap install –classic certbot
　　# ln -s /snap/bin/certbot /usr/bin/certbot

５．apache設定（virtualhostにconf.dを作成）←不要かも
　　# certbot –apache

６．certbotを手動で更新（インストール時に自動更新cronがつくられる）←不要かも
　　# certbot renew –dry-run

これでサーバを再起動したら、Let’s Encrypt の更新エラーを吐き出さなくなった。

安堵した。これで心拍数も下がるだろう。


ちなみに、virtualhostを何度か作りかえると、個々のvirtualhostでは問題ないが、cronで一括certbot renewの自動更新ができない場合がある。これは、以下ディレクトリに不要ファイルが残っているためで、実行途中でエラーを吐き出し以降の実行がキャンセルされてしまう。それら不要ファイルを削除すると問題なく自動更新ができる。当初これがわからず半日沼にはまった。
　　/etc/letsencrypt/renewal/

１週間程前から、sakuraサーバからの送信メール（独自ドメイン）が、gmailで迷惑フォルダに振り分けられるようになった。（焦）

そのメールヘッダをみると、

spf=softfail (google.com: domain of transitioning xxxx@hogehoge.com does not designate xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx as permitted sender)

と、spfでip6を確認できないのが原因らしい。

確かにsakuraサーバはip6設定が有効になっているが、最近になってgmail側でこれをチェックするようになったのだろうと推測される。

そこで、当該ドメインのDNSレコードのspf情報を以下の通り書き換えてみた。

v=spf1 +a:hogehoge.com +mx  ~all

↓

v=spf1 +ip4:xxx.xxx.xxx.xxx +ip6:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx +mx +include:_spf.google.com ~all

テストメールを送ったところ、無事受信フォルダに入り一安心。

災害は忘れた頃にやってくる。

まさにその通りで、今まで問題く動いていたサーバが、必要に迫られたリブート操作で、突如起動しなくなった。

コンソールを見たら、
UNEXPECTED INCONSISTENCY
エラーが発生していた。

冷静になって以下で対応。

Give root password for maintenance
(or type Control-D to continue):　←rootのパスワードを入力

# mount
/dev/sda1 on / type ext4  ←/dev/sda1が修復対象のパーティション

# fsck -t ext4 /dev/sda1　←修復を実行

（省略）
  Clear<y>? 　←［Enter］キーを押す
（省略）
  Fix<y>? 　←［Enter］キーを押す
（省略）

***** FILE SYSTEM WAS MODIFIED *****
***** REBOOT LINUX *****
# exit　←シェルを終了

ちょっとした設定で可能だったのに、いままでそのちょっとした設定が面倒であとまわしにしていた、ftpサーバのパッシブモード設定。

ファイヤーウォールを解放すれば、vsftpdの標準インストールのままパッシブモードは可能だったのだが、さすがに開放には勇気がいる。一方で、標準がパッシブ設定で、アクティブ設定ができないftpクライアントがある（いる）。そういった状況に追い込まれて、とうとう設定することになった。

方法は以下の通り。

vsftpddの設定ファイル/etc/vsftpd/vsftpd.conffに下記の行を追記するだけでよい。

#passive mode
pasv_enable=yes
pasv_min_port=10100
pasv_max_port=10150

１行目コメント
２行目はパッシブモードを使える様にする設定
３行目はパッシブモードで利用する最小ポート番号　ここでは10100とした。
４行目はパッシブモードで利用する最大ポート番号　ここでは10150とした。

最小ポート番号と最大ポート番号は他のポートとバッティングしない任意でOK。設定後はvstpdの再起動を忘れずに。
それから、ファイヤーウォールで、10100から10150ポートに穴を開ければ、パッシブモードでのftp通信が可能となる。

設定時間わずか５分。この作業が面倒で、３年間ほったらかしにしていた。

PHPとjavaを使ったサイトで、FirefpxやChromeでは何ら問題ないのに、InternetExplorer11(IE11)でうまく表示できない現象が生じた。

スクリプト側の問題とは思ったが、サーバ側で何とかならないものかとあれこれググったところ、以下の方法でうまくいったので備忘録として残しておく。

apacheの/etc/httpd/httpd.confに、以下の内容を追記する。要はIE11を強制的にIE10モードにしている。

LoadModule headers_module modules/mod_headers.so
<IfModule headers_module>
Header set X-UA-Compatible: IE=10
</IfModule>

久々（1年2か月ぶり）の投稿。

gmailからメーリングリストに投稿しても自分に配信されないのは有名な話で、そのためにわざわざメーリングリスト用アドレスをgmail以外で取得する必要があった。使い勝手のいいgmailだけに、すこぶる残念な思いを長年続けてきた。

何とか方法がないかと暇な折あれこれ調べていたが、やっと解決策が見つかった。メールヘッダのmassage-idを強制的に書き変えてやればいい。

具体的には、mailmanのmm_cfg.pyに、

USE_MAILMAN_MESSAGE_ID = Yes

を追加して、再起動をかければいい。

先日、メーリングリストサーバを移転したことに伴い早速この処理を施したところ、gmail経由でも無事配信された。WEBメールからでもOKであった。自分でmailmanサーバを立ち上げた場合の対処法だが、長年の課題が解決して肩の荷が1つ降りた。

WordPressがバージョン3になったことに伴い、マルチサイト設定がができるようになった。１ドメインで複数サイトを作る場合、サイト毎にシステムをインストールする必要がなく、手間が省けるだけでなくサーバ容量の軽減にもつながりすこたま便利な機能である。

今日現在のバージョンは3.2.1であるが、新規にこのマルチ設定をしたところ、マニュアルに書いてある「特権管理者」メニューがでてこない。設定が間違っているのかあれこれ見なおしたがシステムは問題なく動いているようだ。

なぜなんだ、、としばらく悩んでからググッてみると、3.2.1からダッシュボードの仕様がどうやらかわったらしい。詳しく説明してくれているサイトがあったので、備忘録として記しておく。

http://blog.junkword.net/2011/09/wordpress-321.php