サーバ管理

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

サイト管理でvirtualminを使っているが、バージョンアップを重ねているうちにいつのバージョンからか、install scriptsサービスが追加されていることに気付いた。（現在のバージョンはvirtualmin3.86）

この中でsquirrelmail1.4.21（現段階では最新バージョン）がワンクリックでpublic_html下にインストールできるようになった。加えて、設定ファイルやユーザー、アドレス帳をDB（mysql）で管理することもでき、すこぶる便利になった。

ただ、標準でen_USロケールしかインストールされないため、メニュー等を日本語で利用するにはja_JPロケールを別途インストールする必要がある。

そのファイルは、http://squirrelmail.org/download.phpから

all_locales-1.4.18-20090526.zip

をダウンロードして、解凍後にhelpとlocaleフォルダにそれぞれja_JPを放り込んでおくだけでよい。ロケールファイルのバージョンは違うが特に問題はなかった。

あとは、squirrelmailを起動させ、オプションでjapaneseに設定を変えリフレッシュするだけで日本語モードに切り替わる。

ただ、これだけでは添付ファイルのアップロード、ダウンロード時に文字化けが発生する。
そこで、
squirrelmail/functions/i18n.php
を以下のとおり変更したところ文字化けが解消された。
————-
682行目以降の内容を変更
変更前：
case ‘downloadfilename’:
$useragent = func_get_arg(2);
if (strstr($useragent, ‘Windows’) !== false ||
strstr($useragent, ‘Mac_’) !== false) {
$ret = mb_convert_encoding($ret, ‘SJIS’, ‘AUTO’);
} else {
$ret = mb_convert_encoding($ret, ‘EUC-JP’, ‘AUTO’);
}
break;

変更後：
case ‘downloadfilename’:
$useragent = func_get_arg(2);
if (strstr($useragent, ‘Windows’) !== false ||
strstr($useragent, ‘Mac_’) !== false) {
$ret = mb_convert_encoding($ret, ‘UTF-8’, ‘AUTO’);
} else {
$ret = mb_convert_encoding($ret, ‘EUC-JP’, ‘AUTO’);
}
break;
——–

なお、squirrelmailスクリプトはpublic_html下にあるので、ファイルの受け渡しはftpで容易に可能である。

ps
従来からcentos5標準のsquirrelmail1.4.8-5をインストールし使っていたが、今回共存させても特に問題は発生していない。

サーバ管理をしていて意外と面倒なのがssl認証設定だ。

慣れればsshで決まった操作をすればそう難しくはないのだが、日頃Webminを愛用しているため、sshを使う機会は少なくなった。というよりも、常時はsshサーバを止めている。

Webminのアドインに複数サイトを管理してくれるVirtualminという便利なアプリがある。いまやVirtualmin抜きではサイト管理がおぼつかない。

このVirtualminにSSLサイトを簡単に設置してくれるモジュールがあり、今日初めて使ってみた。

いやいやいや、便利の一言に尽きる。Apache設定はもちろんのこと、プライベートキーの発行から、CSRの発行、それに認証局からの証明書が届くとそれをコピペするだけで、あとはサーバ上のSSL設定をすべてVirtuaiminがやってくれる。

最近は認証局からの証明書発行もネットですぐにできるため、このVirtuaiminを使うとSSLサイト設定がものの５分で済んでしまう。

あまり便利すぎると基本（原理）を忘れてしまいそうで少しばかり不安はあるが、ま、いいか。

「韓国の特定の知人からのメールが遅配するが原因はわからないか？」と１か月ほど前に友人から質問を受けた。

たぶんそれは先方のメールサーバが原因だろうと安易に答えてそのままにしていたが、先日同じ状況に自分が見舞われた。

共通して言えることは、どちらも受信側でniftyメールを使っている。

エラーログを調べてみると、
refused to talk to me: 421 REJECTED
という表示が出ている。
これでググってみると、原因はどうやらDNS逆引き設定にあるようだ。

自サーバの存在をあまり表に出したくなかったため先日DNS逆引き設定をはずしておいた。niftyに対するメール遅配は確かにこの頃から始まっている。メールキューに配信できずにいるメールがたまったままだ。

早速DNS逆引きを再設定したところ、メールキューが空になった。

大手プロバイダでは、spamメール防止を理由の１つとして、DNS逆引きができないサーバからのメールを受け付けない設定をしているようである。