postfix とdovecot (SMTP Auth) でvirtual その4(Lets encryptをsnapdで)

Lets Encrypt証明書の更新プログラムインストール

今まではepel +certbotのインストールで済ませてきたのだけれど、snapdに置き換わったということで、インストールの記録。途中、参考サイトのとおりだとエラーが出てた部分を修正した手順にした。これが終わっていないとdovecotもpostfixも中途半端な設定のままテスト、インストール後に変更という流れになるので、一気に行うとしたらこれから始めたほうが良い。(でも、一つ一つのコンポーネントを確認しながらするなら、SSLは後のほうが良いかも)

インストール手順

# dnf install snapd
(出力省略)

# systemctl enable –now snapd.socket
Created symlink /etc/systemd/system/sockets.target.wants/snapd.socket → /usr/lib/systemd/system/snapd.socket.

snapdは常駐daemonなので、socketを作るということなんだなと思う。enableで自動起動もあると思うけど。

# ln -s /var/lib/snapd/snap /snap

このシンボリックリンクはクラシックタイプのアプリケーション用だそうで。CentOSは自動じゃないとか?

# systemctl status snapd
● snapd.service – Snap Daemon
Loaded: loaded (/usr/lib/systemd/system/snapd.service; disabled; vendor preset: disabled)
Active: inactive (dead)

起動状態を確認してみると、この時点で停止している。これは、コマンドを実行しようとするとエラーになる原因じゃないか?と考えた次第。

# systemctl start snapd
# systemctl status snapd
● snapd.service – Snap Daemon
Loaded: loaded (/usr/lib/systemd/system/snapd.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2021-05-03 21:43:44 JST; 1s ago
Main PID: 551929 (snapd)
Tasks: 8 (limit: 6082)
Memory: 46.3M
CGroup: /system.slice/snapd.service
└─551929 /usr/libexec/snapd/snapd
May 03 21:43:44 ik1-341-30827.vs.sakura.ne.jp systemd[1]: Starting Snap Daemon…
May 03 21:43:44 ik1-341-30827.vs.sakura.ne.jp snapd[551929]: AppArmor status: apparmor not enabled
May 03 21:43:44 ik1-341-30827.vs.sakura.ne.jp snapd[551929]: daemon.go:347: started snapd/2.49-2.el8 (series 16; classic; devmode) centos/>
May 03 21:43:44 ik1-341-30827.vs.sakura.ne.jp snapd[551929]: daemon.go:440: adjusting startup timeout by 30s (pessimistic estimate of 30s >
May 03 21:43:44 ik1-341-30827.vs.sakura.ne.jp snapd[551929]: helpers.go:105: error trying to compare the snap system key: system-key missi>
May 03 21:43:44 ik1-341-30827.vs.sakura.ne.jp systemd[1]: Started Snap Daemon.

# snap install core
2021-05-03T21:44:52+09:00 INFO Waiting for automatic snapd restart…
core 16-2.49.2 from Canonical✓ installed

起動してからcoreのインストールを行うと、他サイトで出力例が出ていたようなエラーが発生しない。

# snap refresh core
snap “core” has no updates available

# snap install –classic certbot
certbot 1.14.0 from Certbot Project (certbot-eff✓) installed

ここまででcertbotをインストール。最後にCentOSでは自動で張ってくれないシンボリックリンクを作る。

# ln -s /snap/bin/certbot /usr/bin/certbot

# certbot –version
certbot 1.14.0

インストールしたバージョンを確認して完了。

証明書の取得

# certbot certonly –standalone

これはDNSを変更してからしか行えなかったので、それまでは移転前のサーバで取得した証明書をコピーして適用した。

証明書の更新テスト

# certbot renew –dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/****.redalarm.jp-0001.conf


Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator standalone, Installer None
Account registered.
Simulating renewal of an existing certificate for ****.redalarm.jp
Performing the following challenges:
http-01 challenge for ****.redalarm.jp
Waiting for verification…
Challenge failed for domain ****.redalarm.jp
http-01 challenge for ****.redalarm.jp
Cleaning up challenges
(略)

既に証明書のファイルが存在している場合は-0001のように連番が降られるんだなと気づきがあったりした。

自動更新タイマーの設定

 このコマンドで自動的に定期更新するっていう記述を見たのだが…

# snap start –enable certbot.renew

# snap services
Service Startup Current Notes
certbot.renew disabled inactive timer-activated

確認用のコマンドを打つとdisabled でinactiveって出てしまう。変だなと思ったので下記のコマンドで確認。

# systemctl restart snap.certbot.renew.timer
# systemctl status snap.certbot.renew.timer
● snap.certbot.renew.timer – Timer renew for snap application certbot.renew
Loaded: loaded (/etc/systemd/system/snap.certbot.renew.timer; enabled; vendor preset: disabled)
Active: active (waiting) since Wed 2021-05-05 17:29:14 JST; 5s ago
Trigger: Wed 2021-05-05 23:19:00 JST; 5h 49min left

May 05 17:29:14 mail.redalarm.jp systemd[1]: snap.certbot.renew.timer: Succeeded.
May 05 17:29:14 mail.redalarm.jp systemd[1]: Stopped Timer renew for snap application certbot.renew.
May 05 17:29:14 mail.redalarm.jp systemd[1]: Stopping Timer renew for snap application certbot.renew.
May 05 17:29:14 mail.redalarm.jp systemd[1]: Started Timer renew for snap application certbot.renew.

これを見る限りは動くし次も取得するように見えるのだが…snap services の結果は変化がなく、disabled inactiveに。

# systemctl enable snap.certbot.renew.service
Created symlink /etc/systemd/system/multi-user.target.wants/snap.certbot.renew.service → /etc/systemd/system/snap.certbot.renew.service.

試しに上記のコマンドでenableを発行してみた。

# systemctl status snap.certbot.renew.service
● snap.certbot.renew.service – Service for snap application certbot.renew
Loaded: loaded (/etc/systemd/system/snap.certbot.renew.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Wed 2021-05-05 18:14:14 JST; 2s ago
Process: 3054 ExecStart=/usr/bin/snap run –timer=00:00~24:00/2 certbot.renew (code=exited, status=0/SUCCESS)
Main PID: 3054 (code=exited, status=0/SUCCESS)

May 05 18:14:13 mail.redalarm.jp systemd[1]: Starting Service for snap application certbot.renew…
May 05 18:14:14 mail.redalarm.jp systemd[1]: snap.certbot.renew.service: Succeeded.
May 05 18:14:14 mail.redalarm.jp systemd[1]: Started Service for snap application certbot.renew.

# snap services
Service Startup Current Notes
certbot.renew enabled inactive timer-activated

上記のようにsnap servicesも変化が起こった。つまり、CentOSの実装に寄せたやり方をしないとダメということなんだろうか?多分、更新はされるんだろうし、自動起動も行われると思うんだけれど、確認できるのがかなり先だったから安心を得るためにもこの手順で構築するのが良いかと思っている。

更新時のpostfix,dovecot再起動スクリプト

# POST_SCRIPT=”/etc/letsencrypt/renewal-hooks/post/reload.sh”
# echo -e ‘#!/bin/bash\nsystemctl reload postfix dovecot’ >${POST_SCRIPT} && chmod +x ${POST_SCRIPT}

このコマンドの発行の仕方はさくらインターネットのスクリプトから。なるほどねーって思う。

# vim /etc/letsencrypt/renewal/****.redalarm.jp-0001.conf
—-
#renew_before_expiry = 30 days
version = 1.14.0
archive_dir = /etc/letsencrypt/archive/mail.redalarm.jp-0001
cert = /etc/letsencrypt/live/mail.redalarm.jp-0001/cert.pem
privkey = /etc/letsencrypt/live/mail.redalarm.jp-0001/privkey.pem
chain = /etc/letsencrypt/live/mail.redalarm.jp-0001/chain.pem
fullchain = /etc/letsencrypt/live/mail.redalarm.jp-0001/fullchain.pem

#Options used in the renewal process
[renewalparams]
account = 97083cf83392e4930a3e8eb2a518ec48
authenticator = standalone
server = https://acme-v02.api.letsencrypt.org/directory
post_hook = /etc/letsencrypt/renewal-hooks/post/reload.sh

このころになると、コマンドで設定ファイルを…っていうポリシーにかまってられないとばかりにvimで直接ファイル変更という手順になってしまっている。反省。赤字部分を追記している。


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください