Ubuntu 20.04 LTSでUFWを使ったルーターを構築して運用していたが、OSのサポートが終了したのでアップグレードすることにした。
新たに構築するのではなくアップグレードにした理由は、
- ESXiを使っているので、スナップショットを採っておけば、もしも問題が発生しても切り戻しができる。
- イチから環境を作り込むパワーがない。
の2つで、後者が特に大きい。
構築手順はまとめてあるとはいえ、サーバーを再構築するとなると大変だから。
タイトルは24.04だけれど、実際の操作は20.04と22.04で行っている。
そして、UFWとはいっても、アップグレードでUFWに関する操作をすることはなかった。
事前準備
正直なところ、やってみないと何が起きるか分からない。
ルーターは動かしているものが少ないので、どうにかなるだろと安易な気持ちで作業を開始。
結果、思ったよりは大変だったけれど、最初から操作するよりはだいぶ楽チン、という印象。
ESXiでスナップショットを採る
スナップショットを採っておけば、駄目だったときにすぐに元に戻せるだろうと考えた。
電源が入っていても問題なくスナップショットを採ることはできるが、今回は一応電源を落としてから作成ボタンを押した。
スナップショットが取れたら電源を入れる。
SSH接続で使用する鍵を変える(やらなくても大丈夫)
TeraTermのバージョンが古いまま、かつ、ちゃんと調べていなかった…
Ubuntu 20.04から22.04にアップグレードするとRSA鍵での接続ができないと思い込んでいた。ED25519の鍵を作らなければ…と。
これは勉強不足であって、TeraTerm 4から5にアップグレードすれば、RSA鍵でも接続はできる。
最終的にはED25519鍵による接続のみを有効にしたことで安全性は高まったと思われ、やったことをメモとして残しておく。
以下のコマンドでED25519の秘密鍵と公開鍵が作成できる。
$ ssh-keygen -t ed25519 -f /home/admin/.ssh/admin@ROUTER.ROHHIE.NET -C admin@ROUTER.ROHHIE.NET
Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/rohhie/.ssh/admin@ROUTER.ROHHIE.NET
Your public key has been saved in /home/rohhie/.ssh/admin@ROUTER.ROHHIE.NET.pub
The key fingerprint is:
SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX rohhie@ROHHIE.NET
The key's randomart image is:
+--[ED25519 256]--+
| XXXXXXXX |
| XXXXXXXX |
| XXXXXXXX |
| XXXXXXXX |
| XXXXXXXX |
| XXXXXXXX |
| XXXXXXXX |
| XXXXXXXX |
| XXXXXXXX |
+----[SHA256]-----+
※ファイル名に＠が入ることが適切かどうかは分からないが、どのホストの誰のファイルなのかが分かるようにした。
※fingerprintとrandomart imageはマスクした。
作成した公開鍵(pubがついている方)をauthorized_keysに追加する。
/home/admin/.ssh/authorized_keys
ssh-ed25519 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX admin@ROUTER.ROHHIE.NET
ssh-rsa XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX...XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX== admin@router.rohhie.net
※マスクした。
SSH接続に使える鍵の種類は、以下で調べることができるようだった。
superuser / PubkeyAcceptedKeyTypes and ssh-dsa key type
$ ssh -Q PubkeyAcceptedKeyTypes
ssh-ed25519
ssh-ed25519-cert-v01@openssh.com
sk-ssh-ed25519@openssh.com
sk-ssh-ed25519-cert-v01@openssh.com
ssh-rsa
rsa-sha2-256
rsa-sha2-512
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
sk-ecdsa-sha2-nistp256@openssh.com
ssh-rsa-cert-v01@openssh.com
rsa-sha2-256-cert-v01@openssh.com
rsa-sha2-512-cert-v01@openssh.com
ssh-dss-cert-v01@openssh.com
ecdsa-sha2-nistp256-cert-v01@openssh.com
ecdsa-sha2-nistp384-cert-v01@openssh.com
ecdsa-sha2-nistp521-cert-v01@openssh.com
sk-ecdsa-sha2-nistp256-cert-v01@openssh.com
色々と試してみて、最終的には ssh-ed25519 だけにするのだけれど、ここでは、名前にED25519が含まれるものを使えるようにしてみる。
/etc/ssh/sshd_config
...
HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
PubkeyAcceptedKeyTypes=ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com
...
設定を反映。
$ sudo systemctl restart ssh
設定を反映したところ、TeraTermから従来のRSA鍵では接続できなくなった。
鍵をED25519の秘密鍵に置き換えたところ、問題なく接続ができた。
これで、OSアップグレード時にsshd_configをパッケージのものに置き換えても大丈夫そうだ。
22.04へのアップグレード
SSHが切断されても嫌なので、ESXiの画面からアップグレードのコマンドを実行する。
$ sudo poff
$ sudo do-release-upgrade
※ppp接続を止めて、v6プラス側の接続を利用した方が、ダウンロードが早いはず。
アップグレード中は、何度かキーボード入力を求められる。
以下は画面を見て手入力したメッセージなので、多少間違いがあるかもしれない。
ここでは選択と、その後の調整内容を記載している。
本当に実行しますか？
本当に実行しますか？
パッケージがいくつか削除され、いくつか新たにインストールされますが実行しますか？
これらに y と答えることで、パッケージのダウンロードが始まる。
libc6
パッケージのアップグレード時にサービスを自動再起動するか？と聞かれたので、Yesと回答しておいた。
Configuring libc6
There are services installed on your system which need to be restarted when certain libraries, such as libpam, libc, and libssl, are upgraded. Since these restarts may cause interruptions of service for the system, you wil normally be prompted on each upbrade for the list of services you wish to restart. You can choose this option to avoid being prompted; instead, all necessary restarts will be done for you automatically so you can avoid being asked questions on each library upgrade.
Restart services during package upgrades without asking?
Copilot先生による翻訳
システムには libpam、libc、libssl などのライブラリが更新された際に再起動が必要なサービスがインストールされています。これらの再起動はシステムのサービスに影響を及ぼす可能性があるため、通常は各アップグレード時に、再起動するサービスの一覧を確認するよう求められます。
このオプションを選択すると、確認のプロンプトが表示されることなく、必要な再起動が自動的に実行されます。ライブラリの更新時に毎回質問されるのを回避したい場合に便利です。
パッケージのアップグレード時にサービスを自動再起動しますか？
それでも、色々なところで問い合わせはあるので、全自動にはならない。
systemd-networkd
/etc/systemd/networkd.confをパッケージのものに置き換えるかどうかを質問された。
これには y で回答した。
アップグレード後に設定ファイルを確認したところ、[DHCP]というセクションが、[DHCPv4]と[DHCPv6]に分かれていた。
このルーター環境に入れていたのは DUIDType=link-layer という設定で、IPv6でDHCPを使って固定IPアドレスを払い出すためのものだった。
なので普通はこんなところを触ってはいないだろうから、問題になることはない。
ウチではIPv6のDHCPサーバーを立てて、宅内ではローカルのIPv6アドレスを独自に運用していた。
しかし、AndroidがIPv6のDHCPサーバーは認めないという方針なので、WindowsでしかローカルのIPv6アドレスが使えない非常に不安定な状態になってしまい、運用を断念せざるを得なかった。
以上のことから不要な設定ではあるが、こうして時々思い出して動向を探るのにいいから、設定を入れておくことにしよう。(普通はやらない、やる必要がないし、セキュリティリスクになるかもしれないので注意)
/etc/systemd/networkd.conf
[DHCPv6]
#DUIDType=vendor
DUIDType=link-layer
#DUIDRawData=
設定を反映。
$ sudo systemctl restart systemd-networkd
当面は使うことのない設定ではあるが、悪くはない設定と思う。
Cron
/etc/crontabをパッケージのものに置き換えるかどうかを質問された。
これには n で回答した。
アップグレード後に確認してみたところ、PATHの設定について説明され、コメント化されていた。
/etc/crontab
...
SHELL=/bin/sh
# You can also override PATH, but by default, newer versions inherit it from the environment
#PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
...
コメントをCopilot先生に翻訳してもらったところ、
PATH を上書きすることも可能ですが、通常、新しいバージョンは環境から継承されます。
とのことなので、この変更を反映させた。
次回実行から変更した内容が使われるので、設定反映操作のようなものはない。
Zabbix agent
Zabbixの設定ファイルを更新するかどうかの問い合わせ。
Keep the local version currently installed で回答した。
Modified configuration file
zabbix_agentd.conf: A new version (/usr/share/zabbix-agent/zabbix_agentd.conf) of configuration file /etc/zabbix/zabbix_agentd.conf is available, but the version installed currently has been locally modified.
What do you want to do about modified configuration file zabbix_agentd.conf?
Copilot先生による翻訳
zabbix_agentd.conf: /etc/zabbix/zabbix_agentd.conf にローカルで変更が加えられた状態のまま、新しいバージョン (/usr/share/zabbix-agent/zabbix_agentd.conf) の設定ファイルが利用可能になっています。
変更された設定ファイル zabbix_agentd.conf をどうしますか？
アップグレード後に確認してみたところ、2つのファイルの修正が必要だった。
開発元が提供するリポジトリからインストールしている関係で、/etc/apt/sources.list.d/zabbix.listは自動で更新されない。
手作業で修正する。
/etc/apt/sources.list.d/zabbix.list
deb http://repo.zabbix.com/zabbix/5.0/ubuntu jammy main # disabled on upgrade to jammy
deb-src http://repo.zabbix.com/zabbix/5.0/ubuntu jammy main # disabled on upgrade to jammy
※bionicをjammyに変更。bionicって…18.04で元々合ってなかったんじゃん…。
リストの更新後、アップデートするとファイルを更新するかどうか聞かれる。
更新なしでアップグレードして、後から内容を確認する。
$ sudo apt update && sudo apt -y dist-upgrade && sudo apt -y autoremove
...
Configuration file '/etc/apt/sources.list.d/zabbix.list'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** zabbix.list (Y/I/N/O/D/Z) [default=N] ?
Setting up zabbix-agent (1:5.0.46-1+ubuntu22.04) ...
Installing new version of config file /etc/init.d/zabbix-agent ...
Installing new version of config file /etc/logrotate.d/zabbix-agent ...
Configuration file '/etc/zabbix/zabbix_agentd.conf'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** zabbix_agentd.conf (Y/I/N/O/D/Z) [default=N] ?
...
/etc/apt/sources.list.d/zabbix.list の方は、パッケージに含まれているファイルが zabbix.list.dpkg-dist として保管されていた。
内容は一緒だったので、そのままにした。
/etc/zabbix/zabbix_agentd.conf の方は、パッケージに含まれているファイルが zabbix_agentd.conf.dpkg-distとして保管されていた。
こちらは、コメントが結構変わっているように思ったので、dpkg-distをベースとして設定値を組み入れる形で編集した。
設定ファイルを修正後、設定を反映させ、問題なく動作していることを確認。
$ sudo systemctl restart zabbix-agent.service
$ systemctl status zabbix-agent.service
May 03 19:49:25 r1router systemd[1]: Starting Zabbix Agent...
May 03 19:49:25 r1router systemd[1]: Started Zabbix Agent.
OpenSSH server
sshd_configを更新するかどうかの問い合わせ。
Install the package maintainer's version で回答したが、アップグレード後にSSHで接続ができなくなった。
これは都合によりSSH接続を受け付けるポートを変更していたから。
Configuring openssh-server
A new version (/tmp/tmp.Ejxd6VaTw1) of configuration file /etc/ssh/sshd_config is available, but the version installed currently has been locally modified.
What do you want to do about modified configuration file sshd_config?
Copilot先生の翻訳
sshd_config: /etc/ssh/sshd_config にローカルで変更が加えられた状態のまま、新しいバージョン (/tmp/tmp.Ejxd6VaTw1) の設定ファイルが利用可能になっています。
変更された設定ファイル sshd_config をどうしますか？
仕方がないので、ESXiの画面からログインして、設定ファイルをいくつか変更した。
/etc/ssh/sshd_config
Port nnnnn ← sshを実行するポートを指定
HostKey /etc/ssh/ssh_host_ed25519_key ← コメント化されていたので有効化
PubkeyAcceptedAlgorithms=ssh-ed25519 ← 新規に項目追加
HostKeyは指定しない場合、sshdは/etc/ssh/ssh_host_ecdsa_keyが提示されるようだ。
それでも問題はないが、決めの問題なのでED25519を利用することにした。
設定項目 PubkeyAcceptedKeyTypes は、PubkeyAcceptedAlgorithmsに名前が変わっていた。
manpageで利用可能なアルゴリズムがたくさん並んでいるけれど、ED25519を利用することに決めたので、それだけを指定している。
使わない認証方式を使えるようにしていても意味はない、という割り切り。
ルーターに接続するのは、ローカルのTeraTermと、宅内にある各種サーバー。
TeraTermは鍵をED25519に差し替えればOK。
別のUbuntuからSSH接続するにあたっては、以下を実施。
~/.ssh/config
Host routername
HostName 192.168.200.1
User admin
Port 22
IdentityFile ~/.ssh/admin@ROUTER.ROHHIE.NET
作成した鍵を ~/.ssh/admin@ROUTER.ROHHIE.NET として保管。
接続テスト。
$ ssh routername
The authenticity of host '[192.168.200.1]:22 ([192.168.200.1]:22)' can't be established.
ED25519 key fingerprint is SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
こうして必要な接続を確立しておけばOK。
Fail2Ban
/etc/fail2ban/fail2ban.confをパッケージのものに置き換えるかどうかを質問された。
これには n で回答した。
アップグレード後に確認してみたところ、loglevelのデフォルト値が ERROR から INFO に変わったようだ。
変更点はこれだけで、そもそもINFOに設定済みだったので、特に問題はなかった。
/etc/logrotate.d/ufw
ファイルをパッケージのものに置き換えるかどうかを質問された。
ログの保存期間を設定していた記憶があり、これには n で回答した。
アップグレード後にファイルを確認してみると、以下の通り設定に変更が掛かっていた。
古い設定でも動作するかもしれないが、新しくしておくことに越したことはない。
/etc/logrotate.d/ufw
/var/log/ufw.log
{
rotate 54
weekly
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
####### invoke-rc.d rsyslog rotate >/dev/null 2>&1 || true ← 古い設定、行削除
[ -x /usr/lib/rsyslog/rsyslog-rotate ] && /usr/lib/rsyslog/rsyslog-rotate || true
endscript
}
※ #を付けたのが古い設定。
次回実行から変更した内容が使われるので、設定反映操作のようなものはない。
Remove obsolete packages?
ウチの環境では78個のパッケージが削除されるようだった。
これには y で回答した。
System upgrade is complete.
再起動を求められたので、y で回答した。
System upgrade is complete.
Restart required
To finish the upgrade, a restart is required.
If you select 'y' the system will be restarted.Copilot先生による翻訳
システムのアップグレードが完了しました。
再起動が必要です
アップグレードを完了するには、システムの再起動が必要です。
y を選択すると、システムが再起動されます。
これで少し待ったらルーターは再起動して機能し始めた。
22.04起動後の調整
アップグレード中に問いかけがあったものについては、これまでに記載してきた。
ここからはそれ以外の調整について記載する。
Netplanの設定
確か設定ファイルの書き方が変わっているはずだ。
$ sudo netplan apply
** (generate:5400): WARNING **: 19:52:17.290: Permissions for /etc/netplan/00-installer-config.yaml are too open. Netplan configuration should NOT be accessible by others.
** (generate:5400): WARNING **: 19:52:17.291: `gateway4` has been deprecated, use default routes instead.
See the 'Default routes' section of the documentation for more details.
** (generate:5400): WARNING **: 19:52:17.292: `gateway6` has been deprecated, use default routes instead.
See the 'Default routes' section of the documentation for more details.
WARNING:root:Cannot call Open vSwitch: ovsdb-server.service is not running.
...
幾つも警告が出力されたけれど、1つを除いて解消することができる。
Permissions for /etc/netplan/00-installer-config.yaml are too open. Netplan configuration should NOT be accessible by others.
この警告は、アクセス権限を600に設定すると解消する。
$ sudo chmod 600 /etc/netplan/00-installer-config.yaml
`gateway4` has been deprecated, use default routes instead.
`gateway6` has been deprecated, use default routes instead.
この警告は、過去記事で解消方法を記載している。
解消できないのがこれ。
root:Cannot call Open vSwitch: ovsdb-server.service is not running.
Open vSwitchはKVMでネットワークを仮想化するときに使うモジュールだそうで、このルーターには必要がない機能なので無視する。
ということで、結果としてはこの表示になればOK。
$ sudo netplan apply
WARNING:root:Cannot call Open vSwitch: ovsdb-server.service is not running.
Online state: unknown
A start job is running for Wait for Network to be Configured で2分間待たされた。
結論からすると、netplanでens160をoptionalにしていた結果、systemd-networkd-wait-onlineがppp0がオンラインになるのを待ってしまうことが原因だった。
ppp0は起動してから動き出すようにセットしているのだから、このタイミングではオンラインにはならない。
対処としては…
- このサーバーが起動するときは必ずens160にケーブル(仮想・実物含む)が差し込まれているからOptionalにしない。
- 起動時にens160にケーブルが刺さっているかどうかは問題ではない、さっさと起動させる。
ppp0がオンラインになるのをチェックすること自体が間違っているので、それを止める。
のいずれかが考えられる。
ウチのルーターは仮想サーバーなのでどっちでも良いが、過去にこの辺りにこだわりを入れて設定をしているということは、1だと困ったり面倒になったりしたことがあったのだろう。
ということで、2を採用する。
まずは構成されていようがいまいが起動するように設定。
/etc/netplan/00-installer-config.yaml
network:
ethernets:
ens160:
addresses:
- 192.168.200.1/24
- 24nn:nnnn:nnnn:nnnn::200:1/64
routes:
- to: default
via: 192.168.200.10
nameservers:
addresses:
- 192.168.200.200
- 24nn:nnnn:nnnn:nnnn::200:200
search:
- hogeserver.hogeddns.jp
optional: true
version: 2
※IPアドレスはマスクしている。考え方がややこしいけれど、宅内のIPv4のルーターをデフォルトゲートウェイにして起動し、ppp接続が始まったらppp接続がデフォルトルートになるような設定をppp側で入れている。よって、ppp接続が確立するとデフォルトルートが代わる。宅内のサーバー達は、デフォルトルートを192.168.200.1に設定することで、ppp接続を通じてインターネット接続するようになる。これによりv6プラスの恩恵を受けられず、通信速度が全然出ない代わりに、ウェルノウンポートでサービスを公開することができている。
設定を反映。
$ sudo netplan apply
続いて、ppp0がオンラインであることのチェックをやめる。
$ sudo systemctl edit systemd-networkd-wait-online.servic
[Service]
ExecStart=
ExecStart=/lib/systemd/systemd-networkd-wait-online --ignore=ppp0
※空行も含めて書く必要があるとのこと。
これで再起動したところ、2分間も待たされるようなことはなくなった。
それでは、発生していた問題だけれども、起動中にこんな表示がされている。
[ OK ] Started Network Name Resolution.
[ OK ] Reached target Network.
[ OK ] Reached target Host and Network Name Lookups.
[** ] A start job is running for Wait for Network to be Configured ( 16s / no limit )
きっちり2分間待たされ、こんなログが出力されていた。
/var/log/syslog
May 4 11:22:45 routername systemd[1]: Started Network Name Resolution.
May 4 11:22:45 routername systemd[1]: Reached target Network.
May 4 11:22:45 routername systemd[1]: Reached target Host and Network Name Lookups.
May 4 11:22:45 routername systemd-networkd[803]: ens160: Gained IPv6LL
May 4 11:22:45 routername systemd-networkd-wait-online[899]: Timeout occurred while waiting for network connectivity.
May 4 11:42:04 routername systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
May 4 11:42:04 routername systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
May 4 11:42:04 routername systemd[1]: Failed to start Wait for Network to be Configured.
過去の投稿を見ながら、状態を確認すると、Online stateがunknownになっている。はて…？
$ networkctl status -a
...
● 2: ens160
Link File: /usr/lib/systemd/network/99-default.link
Network File: /run/systemd/network/10-netplan-ens160.network
Type: ether
State: routable (configured)
Online state: unknown
...
過去記事に従って、systemd-networkd-wait-onlineをデバッグモードにして再起動してみると、こんなログが出ていた。
/var/log/syslog
May 4 12:46:42 routername systemd[1]: Started Network Name Resolution.
May 4 12:46:42 routername systemd[1]: Reached target Network.
May 4 12:46:42 routername systemd[1]: Reached target Host and Network Name Lookups.
...
May 4 12:46:42 routername systemd-networkd-wait-online[899]: ens160: link is ignored
May 4 12:46:42 routername systemd-networkd-wait-online[899]: lo: link is ignored
May 4 12:46:42 routername systemd-networkd-wait-online[899]: ppp0: link is not managed by networkd (yet?).
...
May 4 12:46:42 routername systemd-networkd-wait-online[899]: ens160: link is ignored
May 4 12:46:42 routername systemd-networkd-wait-online[899]: lo: link is ignored
May 4 12:46:42 routername systemd-networkd-wait-online[899]: ppp0: link is not managed by networkd (yet?).
...
May 4 12:46:42 routername systemd-networkd-wait-online[899]: Timeout occurred while waiting for network connectivity.
May 4 12:46:42 routername systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
May 4 12:46:42 routername systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
May 4 12:46:42 routername systemd[1]: Failed to start Wait for Network to be Configured.
ここまできて、もしかしたらnetworkdで管理していないppp0がオンラインになるのを待っているのかな？と気付き、監視対象から外してみたら問題が解消したのだった。
スナップショットの削除
再起動して動作を確認して問題なかったので、ESXiでスナップショットを削除する。
最新の状態に統合するというイメージなのかもしれない。
これで22.04への移行が完了した。
24.04へのアップグレード
ESXiでスナップショットを採り、ESXiの画面からログインして、アップグレードを実行する。
色々ダウンロードするから、ppp接続を切ってv6プラスの接続を利用する。
$ sudo poff
$ sudo do-release-upgrade
本当に実行しますか？の問い合わせに答えて、ダウンロード開始。
ppp接続を止めたけれど、それでもかなり時間が掛かる印象。JPのリポジトリを参照しているが、本家に切り替えたらもっと速度が出るのかもしれない。
systemd-networkd
/etc/systemd/networkd.conf について、コメントが変わっているのと、[Network]セクションに設定項目が1つコメントとして追加されていた。
実際の設定値には変更がなく、コメントの変更を反映させておいた。
Cron
/etc/crontabは、PATH設定のコメントの順序が変わっていた。
daily、weekly、monthlyの実行箇所が、括弧()ではなく、中括弧{}で囲まれるようになっていた。
また、細かいところではタブコードであるべきところが空白になっていたのが修正されている。
実行時間や内容は変わっていなかったので、そのまま反映させた。
vim
/etc/vim/vimrcには、共通設定として set helplang=ja,en を入れていたけれど、それ以外はデフォルトだった。
コメントが変わっていたけれども特に設定値に変化はなかったので、全ての変更を反映させた。
OpenSSH server
/etc/ssh/sshd_configは、コメントが一部変わっていただけだった。
そのまま反映させた。
Fail2Ban
/etc/fail2ban/fail2ban.confは、設定項目が増えているようだった。
全てコメント化されていたので、全ての変更を反映させた。
PPPoE
アップグレード中の問い合わせ自体は最後だったが、致命的だったので一番最初に対処した問題。
アップグレード時に N で回答した結果、パッケージがインストールされていない状態になっていた。
~$ dpkg -l pppoe*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-================-============-=================================
un pppoe <none> <none> (no description available)
rc pppoeconf 1.21+nmu2ubuntu1 all configures PPPoE/ADSL connection
仕方がないので、インストール作業から始める。
$ sudo apt install pppoeconf
$ sudo pppoeconf
設定中に色々と問いかけがあるので、質問内容と回答をメモ。
翻訳はGoogle先生。
POPULAR OPTIONS
一般的なオプションMost people using popular dialup providers prefer the options 'noauth' and 'defaultroute' in their configuration and remove the 'nodetach' option. Should I check your configuration file and change these settings where neccessary?
一般的なダイヤルアッププロバイダーを利用するほとんどのユーザーは、設定で「noauth」と「defaultroute」オプションを使用し、「nodetach」オプションを削除することを好みます。設定ファイルを確認し、必要に応じてこれらの設定を変更したほうがよいでしょうか？→ Yes
ENTER USERNAME
ユーザー名の入力Please enter the username which you usually need for the PPP login to your provider in the input box below. If you wish to see the help screen, delete the username and press OK.
下記の入力ボックスに、プロバイダへのPPPログイン時に通常使用するユーザー名を入力してください。ヘルプ画面を表示するには、ユーザー名を削除して「OK」を押してください。→ PPPoE接続に利用するユーザー名を入力
ENTER PASSWORD
パスワードの入力Please enter the password which you usually need for the PPP login to your provider in the input box below.
NOTE: you can see the password in plain text while typing.
下記の入力ボックスに、プロバイダーへのPPPログインに通常必要なパスワードを入力してください。 注：入力中はパスワードがプレーンテキストで表示されます。→ PPPoE接続に利用するパスワードを入力
USE PEER DNS
You need at least one DNS IP address to resolve the normal host names. Normally your provider sends you addresses of useable servers when the connection is established. Would you like to add these addresses automatically to the list of nameservers in your local /etc/resolv.conf file? (recommended)
通常のホスト名を解決するには、少なくとも1つのDNS IPアドレスが必要です。通常、プロバイダは接続が確立されると、利用可能なサーバーのアドレスを送信します。これらのアドレスをローカルの/etc/resolv.confファイルのネームサーバーリストに自動的に追加しますか？（推奨）→ No ※構築当時と違う回答。LANでの名前解決は、LANに設置したDNSで実施したい。
LIMITED MSS PROBLEM
MSS限界の問題Many providers have routers that do not support TCP packets with a MSS higher than 1460. Usually, outgoing packets have this MSS when they go through one real Ethernet link with the default MTU size (1500). Unfortunately, if you are forwarding packets from other hosts (i.e. doing masquerading) the MSS may be increased depending on the packet size and the route to the client hosts, so your client machines won't be able to connect to some sites. There is a solution: the maximum MSS can be limited by pppoe. You can find more details about this issue in the pppoe documentation.
多くのプロバイダは、1460を超えるTCPパケットのMSSをサポートしないルーターを備えています。通常、送信パケットは、デフォルトのMTUサイズ（1500）を持つ1つの実イーサネットリンクを通過する際に、このMSSを持ちます。しかし、他のホストからパケットを転送する場合（つまり、マスカレードを行う場合）、パケットサイズとクライアントホストへの経路に応じてMSSが増加する可能性があり、クライアントマシンが一部のサイトに接続できなくなることがあります。この問題には解決策があります。pppoeで最大MSSを制限することができます。この問題の詳細については、pppoeのドキュメントをご覧ください。
Should pppoe clamp MSS at 1452 bytes?
pppoe は MSS を 1452 バイトでクランプする必要がありますか?
If unsure, say yes.
不明な場合は「はい」と答えてください。
(If you still get problems described above, try setting to 1412 in the dsl-provider file.)
(上記の問題が引き続き発生する場合は、dsl-provider ファイルで 1412 に設定してみてください。)→ Yes
DONE
終わりYour PPPD is configured now. Would you like to start the connection at boot time?
PPPDの設定が完了しました。起動時に接続を開始しますか？→ Yes
ESTABLISH A CONNECTION
接続を開始Now, you can make a DSL connection with "pon dsl-provider" and terminate it with "poff". Would you like to start the connection now?
これで、「pon dsl-provider」でDSL接続を確立し、「poff」で切断できるようになりました。今すぐ接続を開始しますか？→ Yes
CONNECTION INITIATED
接続開始The DSL connection has been triggered. You can use the "plog" command to see the status or "ip addr show ppp0" for general interface info.
DSL接続が開始されました。ステータスを確認するには「plog」コマンドを使用するか、「ip addr show ppp0」でインターフェースの一般情報を確認できます。→ Ok
接続ができたみたいなので、結果を確認してみる。
$ ip address show ppp0
3: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1454 qdisc fq_codel state UNKNOWN group default qlen 3
link/ppp
inet 118.1.92.196 peer 153.153.227.248/32 scope global ppp0
valid_lft forever preferred_lft forever
接続が確立できたおかげで、インターネット側からサーバーへのアクセスができるようになった。
24.04起動後の調整
アップグレード中に問いかけがあったものについては、これまでに記載してきた。
ここからはそれ以外の調整について記載する。
Zabbix agent
ソースリストの書き方が随分変わったようだ。
いまはVersion 5を利用しており、公式からdebファイルをダウンロードしてきて、インストールした。
だけど、このパッケージからインストールしたファイルは、古い形式の書き方だった。
$ wget https://repo.zabbix.com/zabbix/5.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_5.0+ubuntu24.04_all.deb
$ sudo dpkg -i zabbix-release_latest_5.0+ubuntu24.04_all.deb
$ sudo apt update
$ apt list --upgradable -a
Listing... Done
zabbix-agent/jammy 1:5.0.46-1+ubuntu24.04 amd64 [upgradable from: 1:5.0.46-1+ubuntu22.04]
zabbix-agent/now 1:5.0.46-1+ubuntu22.04 amd64 [installed,upgradable to: 1:5.0.46-1+ubuntu24.04]
$ sudo apt -y dist-upgrade
jammyのバージョンがインストールされていたけれど、nobleからダウンロードしてきてアップデートされた。
スナップショットの削除
再起動して動作を確認して問題なかったので、ESXiでスナップショットを削除する。
これで24.04へのアップグレードが完了した。
色々と変わっているものがあるかのしれないのだけれど、少なくともルーティング部分についてはそのままで動いているようだったから、一安心。
さいごに
こういうのは、長期間休めるタイミングで一気にやらないと進まない。
調べて頭に入れて、それをベースに他のことを調べて…の繰り返しなので、時間を空けると忘れてしまう。
ただ、今回だいぶ楽だったのは、翻訳や操作方法の相談をCopilotに頼めたこと。
たまにはズレもあるけれど、多くは正しく色々と教えてくれるので、調査時間をかなり短縮させられた。
なかなか良い時代になったなーと思った。
コメントはこちらから お気軽にどうぞ ～ 投稿に関するご意見・感想・他