CentOS8のサポートが切れたのでCentOS Stream 8に移行する

話は知っていたが無対策だった。期限の2021年12月を過ぎたらdnfアップデートもできなくなった。他のディストリビューションに移る話もあったが、とりあえず単体webサーバーぐらいにしか使っていないのでCentOS Stream 8へ移行する。

/etc/yum.repos.d/の CentOS-Base.repoとCentOS-AppStream.repoで
mirrorlistをコメントアウト、baseurlをvaultに指定
baseurl=http://vault.centos.org/$contentdir/$releasever/BaseOS/$basearch/os/
baseurl=http://vault.centos.org/$contentdir/$releasever/AppStream/$basearch/os/

dnf install centos-release-stream
dnf swap centos-linux-repos centos-stream-repos
dnf distro-sync

これで /etc/centos-release を見てみると CentOS Stream release 8 になっている。
vaultが生きてるうちにやっておかねばならぬ。
(先日見たらCentOS5向けのvalutはしっかり閉じてた)
だからこれは2022年3月版ということで。

phpMyAdmin置いたら真っ白

CentOS8からCentOS Stream 8への移行作業を行って、必要になりphpMyAdminを設置。
しかし動かない、真っ白…

エラーログには
PHP message: PHP Fatal error: Uncaught Error: Call to a member function getCookie() on null in /path-to-pma/libraries/classes/Url.php:220

そんなみんな使ってるバージョンなのに動かないなんてことはないよねーと追いかけたらスタックトレースにしっかり「warnMissingExtension(‘json’,true)」とか「book.json.php」とか出ている。

php-jsonパッケージをインストールしたら動きました。

サポートの切れたCentOS5でyum update

最新のものに入れ替えるにしても入替元もバージョンアップしておきたい。
yum updateしてもサポートが切れてるのでリポジトリ参照先を変える。

baseurl=http://archive.kernel.org/centos-vault/5.10/os/$basearch/
サポート切れの CentOS5 で yum を使えるようにする – Qiita

yum clean all してから yum update で使えるようになりました。

足りないソフトはソースからインストールしないといけないけどね…

CentOS6でcertbotを使い続ける

2021年10月からLet’s Encryptの使っているルート証明書が切れた(変更になった)関係で、古いシステムでは使えない話が出てきていましたが、それはクライアントの話。CentOS6のサーバーではcertbot(-auto)を継続利用できないのでさて困ったねと。
あともう1つオマケでfullchain.pemとiOSでの問題も最後に。

元々certbot-autoを使ってLet’s Encryptの証明書を更新していましたが、使えなくなりました。
1つはyumの問題。CentOS6はサポートが切れたのでアップデートを提供してくれてたリポジトリも閉じてしまいました。このへんは各リポジトリに使われていた mirrorlist.centos.org を vault.centos.orgに変えてやれば一応使えます。
そしてcertbot-autoが「Your system is not supported by certbot-auto anymore.」と言ってきて終わります。

続きを読む

特定サーバーからメールが届かなくなった(TLSv1.1廃止の影響)

CentOS7,8あたりでpostfixによるメールサーバーを運用中。
最近いくつかのサーバーからメールが届かなくなったということで調査したら、TLSv1.1以前が廃止された影響だったようです。

受信サーバーのpostfixは smtpd_tls_security_level = mayとしているので、STARTTLSしなければ平文のSMTPでメールが受信できます。

問題は送信元がSTARTTLSしてしまうけれどもTLSv1.1以下だった場合。バージョンアップされていないメールサーバー(今回は某レンタルサーバーのqmail)がSSL3で通信しようとしてきて、STARTTLS→失敗・切断という流れだったようです。

相手からreturn mailが来たと連絡をもらったときの内容は以下↓

TLS connect failed: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version; connected to XXX.XXX.XXX.XXX.
I'm not going to try again; this message has been in the queue too long.

受信側postfixをsmtpd_tls_log_level = 2 にして様子見したときのログ↓

connect from mxXXX.example.com[XXX.XXX.XXX.XXX]
setting up TLS connection from mxXXX.example.com[XXX.X.XXX.XXX]
mxXXX.example.com[XXX.XXX.XXX.XXX]: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH"
SSL_accept:before SSL initialization
SSL_accept:before SSL initialization
SSL3 alert write:fatal:protocol version
SSL_accept:error in error
SSL_accept error from mxXXX.example.com[XXX.XXX.XXX.XXX]: -1
warning: TLS library problem: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol:ssl/statem/statem_srvr.c:1661:
lost connection after STARTTLS from mxXXX.example.com[XXX.XXX.XXX.XXX]
disconnect from mxXXX.example.com[XXX.XXX.XXX.XXX] ehlo=1 starttls=0/1 commands=1/2

SSL3 alert writeって出てますね。

解決策としては、先方のバージョンアップをお願いするか、手元のサーバーで半端にTLSさせないように、そもそもSTARTTLS非対応にしてしまうか。
今回はレンタルサーバーということで先方が即時に対応できないため、postfixで smtpd_tls_security_level = none としました。
master.cfでsubmissionポートの場合はTLSになるようにしておいたし、不正リレーもないことをあらためて確認。
受信メールサーバーだからある程度は開いておかないといけないということで may だったのですが、このパターンは今後結構出てきそう…