[Ubuntu 20.04 LTS to 22.04 LTS] アップデートの事前準備と実施の記録

# はじめに
　2022年8月下旬、ubuntu 22.04 LTS が出てしばらくが過ぎ情報が揃ってきたと思われるのでアップデート準備～アップデートした。そのときの記録。

# 必要な事前準備の調査の結論
　暗号化関連で危殆化したものが無効化される。証明書関係で影響がありそうだった。web、メールをTLS 1.3に対応させておく。
　sshの証明書による認証にRSA鍵を使っているようなら、ED25519に切り替える。ターミナルソフトもED25519に対応している必要がある。

# 22.04LTSで変わるもの

　公式は以下。

https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes/24668

## OpenSSL
 3.0になる。SHA1とMD5はデフォルトで無効化される。TLS1.2以下(TLS1.2を含む)は無効化される。libssl1.1に依存しているパッケージはリビルドが必要になる。

## OpenSSH
　ssh-rsaは無効化される。ネットでTeratermで接続できないとの記事を見た。クライアントの対応状況もあるらしい。

　RSAを有効化する設定にするか、Ed25519に変更する。なんか覚えにくい新しいのどんどん出てくるな・・・。

https://www.mulong.me/tech/linux/ubuntu-mac-ssh-login-public-key/

https://linuxfan.info/ssh-ed25519

　結論として、Ed25519の256bitを採用した。ターミナルソフトはteratermを使っていたが未対応らしいのでrloginへ変更。rloginもEd25519は256bitのみ対応らしい。普通にkeygenコマンド叩くと256bitでペアが作られる。

```bash
ssh-keygen -t ed25519
```

　うっかり注意として、keygenするときはログインするユーザーで作り、ログインするユーザーのauthorized_keysに追記する。rootじゃないよ！

　できあがった公開鍵をauthorized_keysへ追記する。

```bash
cat id_25519.pub >> /home/***user***/.ssh/authorized_keys
```

　別の端末にid_25519（秘密鍵）を持っていくときは、chmod 777しないと切取とかできない。移動したあとの端末で適切なアクセス権を設定する。

　auth.logにED25519で認証したログが出てればOK。

```:/var/log/auth.log
mydomain sshd[xxxxxx]: Accepted publickey for user_name from 192.168.x.x port xxxx ssh2: ED25519 SHA256:************************************
```

## カーネル
　5.15? ubuntu 20.04 LTSの最新版より古いカーネルになるっぽい。

## 言語系
Gcc 11.2.0になる。binutils 2.38、glibc 2.35。影響は・・・たぶん無い！
Python 5.34.0 になる。影響なし。
Perl 5.34.0 でメジャーバージョン変わらず。影響なし。
LLVM, golang も変わるらしいけど使ってないのでよくわからない。
Ruby 3.0になる。影響なし。
PHP 8.1.2になる。既にPHP8使っていたので影響なし。

## Apache
　2.4.52になる。同じ2.4系なので設定はそのままでいけそう。

## Postgresql
　14.2になる。複雑なDBを組んでないので細かい影響はわからない。基本SELECT、INSERT、UPDATE、DELETEができれば良いのでほぼ影響ないと判断。

## Samba
　4.15.5になる。smb.confの内容で変更される項目が多いらしい。

https://www.samba.org/samba/history/samba-4.15.0.html


# アップデート実行、簡単な確認

　覚悟を決めたらいざ実行！

```bash
do-release-update -d
```

　対話式になるので適宜yとか既存の設定を引き継ぐとかを選択して進める。何をインストールしているかで変わる。怖かったのは「1022番ポートでssh接続できるように開けるよ、何かあったらそこから繋いでね」と言われた事。アップデート終了後、普段のポートで繋いでファイヤーウォール確認したら、ちゃんと閉じてました。

　ウェブサイトが見れて、メールの送受信を確認したら、とりあえずは一安心。アプデは30分ほどで終了した。

## atの再？インストール
　なぜかatが使えなくなったのでインストールした。

```bash
apt install at
```

## clamav-unofficial-sigs
　以前の設定ファイルが上書きされ、`secureriteinfo`と`malwarepatrol`が有効化されcronからメールが来た。

```
～一部略～
curl: (6) Could not resolve host: clamav.securiteinfo.com
curl: (6) Could not resolve host: clamav.securiteinfo.com Clamscan reports MalwarePatrol mbl.ndb database integrity tested BAD - SKIPPING
```

2つを再度無効化。手順は過去の自分の記事を参考にした。

## Postfix
　3.6.4へ。campatibilityは2.0のまま以前の設定を引き継いだ。
行政団体のメール（go.jp）がrejectされるようになった。`Helo command rejected: Host not found`との事なので`reject_invalid_hostname`か`reject_unknown_hostname`か。そのルールより前に`go.jp`をOKとするフィルタを記載しても同様のログでrejectされる。おそらく`smtpd_client_restrictions`に記載されている`reject_unknown_hostname`が動作している。gmailはじめ他の企業とかは問題なく送受信できる。もう行政関係のメールサーバーの管理業者どうなっとるんや・・・これで日本としてIT推してくとか本当に大丈夫なのか？

`smtpd_client_restrictions`の項目中、`reject_unknown_hostname`を削除した。`reject_unknown_hostname`を記載するときはパスするフィルターとセットで運用した方が良さそう。

```:/etc/postfix/main.cf
smtpd_helo_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        check_helo_access hash:/etc/postfix/permit_helo_apple,       #この中に行政関係ドメイン許可設定を記載した
        check_helo_access regexp:/etc/postfix/permit_helo_clients,
        reject_invalid_hostname,
        reject_unknown_hostname, 
        permit

　～　中略　～

smtpd_client_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        check_client_access regexp:/etc/postfix/permit_clients,
        sleep 1,
        check_client_access cidr:/etc/postfix/krfilter,
        check_client_access regexp:/etc/postfix/permit_mildlist,
        check_client_access hash:/etc/postfix/permit_ip_mildlist,
        sleep 1,
        check_client_access hash:/etc/postfix/reject_client,
        check_client_access cidr:/etc/postfix/cidr_reject_client,
        # check_helo_access hash:/etc/postfix/permit_helo_apple,
        # check_helo_access regexp:/etc/postfix/permit_helo_clients,
        # reject_unknown_hostname,
        reject_rbl_client bl.spamcop.net,
        permit
```

　1週間ほど様子を見てcampatibilityを3.6へ変更。設定そのままで問題なく動作している。設定2のままだと、`mail.log`にカンパチが低いよ！ってログが出てうっとうしいので・・・。

```:/etc/postfix/main.cf
# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
# compatibility_level = 2
compatibility_level = 3.6
```

## Samba
　変更が多いとの事前情報だったが、設定を引き継いでそのまま以前と変わらず使用できている。