カテゴリー: Linux

Ubuntu Server を18.04から22.04までアップグレードしてみた。

無料版のUbuntu Server 18.04のサポートが4月ごろに終わる可能性があるので、Ubuntu Server 20.04、Ubuntu Server 22.04 にアップグレードを試した。

do-release-upgrade を実行して、ダイアログで聞かれる内容に答えていくことで、OSバージョンのアップグレードはできた。

アップデートは、SSHからでもできるが、途中で再起動が入ることから、別ポートでSSHが立ち上がり、そこが非常用のアクセスで使われる。推奨は、されていないようなので、コンソールからやるのがよい。

アップグレード中は、途中でダイアログでいろいろと聞かれる。それを答えていくことで、アップグレードされる。インストールされているパッケージも新しくなっていく。バージョン固定のパッケージのコマンドを使っていると、アップグレード後はエラーになるので、注意は必要。

do-release-upgrade は、単純実行で１つ新しいLTSバージョンにしてくれる。18.04からは20.04になるので、22.04にするには、20.04にしてから、もう一度、実行すると、22.04にできた。

2023年2月1日
”Needs triage” って、何？

Ubuntuのセキュリティ対応状況を確認していて、状況が「Needs triage」になっているものが多数あり。「Needs triage」はどういう状況なのか忘れるので、メモ。

Needs triage　→　脆弱性があるパッケージ（やモジュールなど）が存在しているが、対応が必要かどうかは確認・選別が必要な状況

Ubuntuの場合、ステータスが、Needs triageとなっているものは、脆弱性の影響があるのかどうかわからない状態ということ。

「Released (5.15.0-53.59)」となっているものは、カッコ内のバージョンで対応されているので、それと比べればよい。

「Not vulnerable (code not present)」は、影響なし。

2022年12月30日
Windows上で処理されたrrdファイルをLinuxのRRDToolで処理しようとしたらエラーになった
Windows上で処理されたrrdファイルをLinuxのRRDToolで処理しようとしたらエラーになった。WindowsにRRD Toolをいれて、いろいろとやるのもめんどくさかったので、別のWindowsで蓄積されたRRDのファイルを、WSLのUbuntuにrrdtoolをインストールして処理しようとしていた。「rrdtool dump xxxx.rrd」を行うと下記のエラーが発生した。
```
zen@PC:~/rrd$ rrdtool dump seg-Pkts.rrd 
ERROR: reached EOF while loading header rrd->ds_def
```
Windowsの改行コードがはいっているため、LinuxのRRD Toolで処理できないというエラー。

WindowsのRRD Toolでrrdtool dump して、Linux上のRRDファイルにインポートしないといけないようだ。

つまり、WindowsのRRD Toolで作られたRRDファイルを、Linux上のRRD Toolで直接処理することはできない。

おまけ。同じRRDのファイルに対して、fetchをしても、項目はあっているのに取得できない。これも改行コードが影響しているためと思われる。
```
zen@PC:~/rrd$ rrdtool fetch seg-Pkts.rrd OutOctets 
ERROR: unknown consolidation function 'OutOctets'
```
2022年12月13日

UbuntuでVeeamのアップデートがPGPエラーになったので対処

Ubuntu （Linux）で、apt update したところ、Veeamのバックアップエージェントの更新確認でエラーになった。エラーをみると、PGPキーの有効期限が切れているというエラーだった。VeeamのPGPキーを更新したので、そのメモ。

apt updateで表示されたエラー

W: Failed to fetch http://repository.veeam.com/backup/linux/agent/dpkg/debian/public/dists/stable/InRelease  The following signatures were invalid: EXPKEYSIG 3268CF038EEC045B Veeam Software Repository key <support@veeam.com>
W: Some index files failed to download. They have been ignored, or old ones used instead.

対応方法

念のため、PGPキーのリストを表示して確認する。（やらなくても問題はない）

sudo apt-key list

Veeamの古いPGPキー（GPGキー）を削除するために、下記のコマンドを実行する。

sudo apt-key del FBF8A590

Veeamの新しいGPGキーをダウンロードするために、下記のコマンドを実行する。

sudo wget http://repository.veeam.com/keys/veeam.gpg -O /etc/apt/trusted.gpg.d/veeam.gpg

もう一度、apt Updateする。

sudo apt update

これでアップデートが成功すれば、完了。

対応したときのログ

zen@web:~$ sudo apt-key
Usage: apt-key [--keyring file] [command] [arguments]

Manage apt's list of trusted keys

  apt-key add <file>          - add the key contained in <file> ('-' for stdin)
  apt-key del <keyid>         - remove the key <keyid>
  apt-key export <keyid>      - output the key <keyid>
  apt-key exportall           - output all trusted keys
  apt-key update              - update keys using the keyring package
  apt-key net-update          - update keys using the network
  apt-key list                - list keys
  apt-key finger              - list fingerprints
  apt-key adv                 - pass advanced options to gpg (download key)

If no specific keyring file is given the command applies to all keyring files.
zen@web:~$ sudo apt-key list
/etc/apt/trusted.gpg
--------------------
pub   rsa2048 2017-02-20 [SC]
      9DD9 479D 06BA A713 2280  3AC1 6633 2B78 417E 73EA
uid           [ unknown] Hatena Co., Ltd. <admin@mackerel.io>

～～～～略～～～～～

/etc/apt/trusted.gpg.d/veeam.gpg
--------------------------------
pub   rsa4096 2016-05-06 [SC]
      EFAF F6B4 4E68 80EA DDD2  17E4 7AFD EEB8 FBF8 A590
uid           [ unknown] Veeam Software Repository key <support@veeam.com>
sub   rsa4096 2016-05-06 [E]

zen@web:~$
zen@web:~$ sudo apt-key del FBF8A590

OK
zen@web:~$
zen@web:~$ sudo wget http://repository.veeam.com/keys/veeam.gpg -O /etc/apt/trusted.gpg.d/veeam.gpg
--2022-09-08 10:19:26--  http://repository.veeam.com/keys/veeam.gpg
Resolving repository.veeam.com (repository.veeam.com)... 99.84.50.24, 99.84.50.103, 99.84.50.113, ...
Connecting to repository.veeam.com (repository.veeam.com)|99.84.50.24|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4401 (4.3K) [application/octet-stream]
Saving to: '/etc/apt/trusted.gpg.d/veeam.gpg'

/etc/apt/trusted.gp 100%[===================>]   4.30K  --.-KB/s    in 0s

2022-09-08 10:19:26 (503 MB/s) - '/etc/apt/trusted.gpg.d/veeam.gpg' saved [4401/4401]

zen@web:~$ sudo apt update
Hit:1 http://jp.archive.ubuntu.com/ubuntu bionic InRelease
Hit:2 http://apt.mackerel.io/v2 mackerel InRelease
Hit:3 http://jp.archive.ubuntu.com/ubuntu bionic-updates InRelease
Hit:4 http://jp.archive.ubuntu.com/ubuntu bionic-backports InRelease
Get:5 http://repository.veeam.com/backup/linux/agent/dpkg/debian/public stable InRelease [7,549 B]
Get:6 http://repository.veeam.com/backup/linux/agent/dpkg/debian/public stable/veeam amd64 Packages [6,448 B]
Hit:8 http://security.ubuntu.com/ubuntu bionic-security InRelease
Hit:10 http://ppa.launchpad.net/brightbox/ruby-ng/ubuntu bionic InRelease
Hit:7 https://downloads.mariadb.com/MariaDB/mariadb-10.3/repo/ubuntu bionic InRelease
Hit:9 https://downloads.mariadb.com/MaxScale/2.4/ubuntu bionic InRelease
Hit:11 https://downloads.mariadb.com/Tools/ubuntu bionic InRelease
Fetched 14.0 kB in 2s (6,034 B/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
3 packages can be upgraded. Run 'apt list --upgradable' to see them.
N: Skipping acquire of configured file 'main/binary-i386/Packages' as repository 'http://downloads.mariadb.com/MariaDB/mariadb-10.3/repo/ubuntu bionic InRelease' doesn't support architecture 'i386'
zen@web:~$

参考

https://helpcenter.veeam.com/docs/veeampn/userguide/veeampn_update_troubleshooting.html?ver=21

2022年10月16日

「Dirty Cred」の対応をUbuntuでやったログ

「Dirty Cred（CVE-2022-2588）」についてのUbuntuのページ。修正されたカーネルのバージョンを調べて、アップデート後にそれよりも新しくなっていればよい。

https://ubuntu.com/security/CVE-2022-2588

修正パッチは出ているので、”apt update” “apt upgrade” でできるはずなので、試した。カーネルのバージョンが変わっていることが確認できたので、apt upgradeで問題なし。

Ubuntu 18.04 LTS のとき

作業前

zen@LABO:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.6 LTS
Release:        18.04
Codename:       bionic
zen@LABO:~$ uname -a
Linux LABO 4.15.0-166-generic #174-Ubuntu SMP Wed Dec 8 19:07:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
zen@LABO:~$

作業後

zen@LABO:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.6 LTS
Release:        18.04
Codename:       bionic
zen@LABO:~$ uname -a
Linux LABO 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
zen@LABO:~$

Ubuntu 20.04 LTS のとき

作業前

zen@TEST:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.4 LTS
Release:        20.04
Codename:       focal
zen@TEST:~$ uname -a
Linux TEST 5.4.0-109-generic #123-Ubuntu SMP Fri Apr 8 09:10:54 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
zen@TEST:~$

作業後

zen@TEST:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.4 LTS
Release:        20.04
Codename:       focal
zen@TEST:~$ uname -a
Linux TEST 5.4.0-125-generic #141-Ubuntu SMP Wed Aug 10 13:42:03 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
zen@TEST:~$

2022年8月26日

新しくインストールしたUbuntuでNginxが起動しない

新しくUbuntuをインストールして、NginxやPHPをインストールした。Nginxを起動させようとしたところ、エラーで起動せず。

zen@dev:/etc/nginx/sites-available$ sudo service nginx start
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xe" for details.
zen@dev:/etc/nginx/sites-available$
zen@dev:/etc/nginx/sites-available$ sudo systemctl status nginx.service
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset:>
     Active: failed (Result: exit-code) since Wed 2021-11-17 16:13:11 JST; 2min>
       Docs: man:nginx(8)
    Process: 294747 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_pro>
    Process: 294758 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; >
Nov 17 16:13:08 dev systemd[1]: Starting A high performance web serve>
Nov 17 16:13:08 dev nginx[294758]: nginx: [emerg] bind() to 0.0.0.0:8>
Nov 17 16:13:09 dev nginx[294758]: nginx: [emerg] bind() to 0.0.0.0:8>
Nov 17 16:13:09 dev nginx[294758]: nginx: [emerg] bind() to 0.0.0.0:8>
Nov 17 16:13:10 dev nginx[294758]: nginx: [emerg] bind() to 0.0.0.0:8>
Nov 17 16:13:10 dev nginx[294758]: nginx: [emerg] bind() to 0.0.0.0:8>
Nov 17 16:13:11 dev nginx[294758]: nginx: [emerg] still could not bin>
Nov 17 16:13:11 dev systemd[1]: nginx.service: Control process exited>
Nov 17 16:13:11 dev systemd[1]: nginx.service: Failed with result 'ex>
Nov 17 16:13:11 dev systemd[1]: Failed to start A high performance we>
zen@dev:/etc/nginx/sites-available$

エラーを見ると、ポートのバインドに失敗している。もしやと思って調べると、Apacheがいて、ポート80で起動していた。Apacheを終了させると、無事にNginxを起動させることができた。

aptでいろいろとインストールしていると、いつのまにかapache がいて邪魔をする。初歩的なミスだけど、よくやらかす。

2021年12月14日

GitLab14.3.2-ceへのアップデートでエラーになった

apt upgrade を行ったところ、Gitlabの更新で下記のエラーになった。バージョンは「Gitlab14.2.3-ce」から「Gitlab14.3.2-ce」への更新だ。

Malformed configuration JSON file found at /opt/gitlab/embedded/nodes/LABO.json.
This usually happens when your last run of `gitlab-ctl reconfigure` didn't complete successfully.
This file is used to check if any of the unsupported configurations are enabled,
and hence require a working reconfigure before upgrading.
Please run `sudo gitlab-ctl reconfigure` to fix it and try again.
dpkg: アーカイブ /var/cache/apt/archives/gitlab-ce_14.3.2-ce.0_amd64.deb の処理中にエラーが発生しました (--unpack):
 new gitlab-ce package pre-installation script subprocess returned error exit status 1
処理中にエラーが発生しました:
 /var/cache/apt/archives/gitlab-ce_14.3.2-ce.0_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

エラーに書いてあるように、gitlab-ctl reconfigure のコマンドを実行した。

~$ sudo gitlab-ctl reconfigure

結構時間がかかった。５～10分くらい。終わった後に、もう一度、”apt update” して “apt upgrade”した。今度は成功した。

2021年10月11日

Nginxでファイルアップロードで「413 Request Entity Too Large」が表示される
Nginx上で、Wordpressを動作させるために、PHP-FPMやMariaDBを設定して「動作した」と思ったら、アップロードで、下記のエラーが表示された。
```
413 Request Entity Too Large
```
アップロードしたファイルは1MBちょっとのファイルなのだが。これを調べていくと、PHP側のアップロードサイズとポストサイズは問題なかった。Nginx側は、サイズ指定されていないようなので、デフォルトのサイズだった。このNginxのデフォルトサイズが問題で、デフォルトだと、1mしかない。これが原因なので、Nginxのパラメータを書き換える。

https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size

`/etc/nginx/sites-available/default` を編集し、「server {}」のところに、「client_max_body_size 30m;」を追加し、最大サイズを30mにした。
```
# Default server configuration 
# 
server { 
        #listen 80 default_server; 
        #listen [::]:80 default_server; 
        listen 443 ssl default_server; 
        listen [::]:443 ssl default_server; 
        #listen 443 ssl; 
        ssl_certificate /etc/nginx/conf.d/server.crt; 
        ssl_certificate_key /etc/nginx/conf.d/server.key; 
        client_max_body_size 30m;
```
あとは、Nginxを再起動するか、Nginxでコンフィグをリロードする。

`sudo service nginx reload` でコンフィグのリロードか、` sudo service nginx restart` で再起動する。これでエラーがでなければOK。
2021年8月15日
Linuxでディレクトリ内のファイル一覧をJSONっぽく出力する
ファイルのリストを、JSON形式で書きだす必要があり、ファイル名をダブルクォーテーションで囲み、カンマ区切りで改行するように出力するだけ。これで、頭と最後を加工して、JSONにした。
```
ls | sed "s/\$/\",/" | sed "s/^/\ \ \"/"
```
需要があるような気はしないが、メモとして残す。たぶん、自分が忘れるので。
2021年3月4日
Bitnami Redmineで3.4.6から4.1.1にアップグレード
Bitnami Redmineで、Redmineの3.4.6を使っている。3.4系が古いので、Redmineの4.1.1にアップグレードにアップグレードしたときの作業を残す。基本的には、Bitnamiのドキュメントの流れでインストールはできた。インストーラーを普通に走らせるとパスなどは変わるので、そこらへんはアレンジしてる。

■参考
https://docs.bitnami.com/general/apps/redmine/administration/upgrade/

■やったこと

アップデート前の環境のDBのユーザ名とパスワードをファイルから抜く。対象のファイルは、下記。
```
/opt/redmine-3.4.6-1/apps/redmine/htdocs/config/database.yml
```
接続の確認をする
```
/opt/redmine-3.4.6-1/mysql/bin/mysql -u bitnami -p
```
データを保存するフォルダを作る
```
mkdir data
cd data
```
mysqldumpでデータベースのデータを保存する
```
/opt/redmine-3.4.6-1/mysql/bin/mysqldump bitnami -p --databases bitnami_redmine --add-drop-database < bitnami_redmine.sql
```
Redmineのファイルを保存する
```
 tar czf redmine_files.tar.gz -C /opt/redmine-3.4.6-1/apps/redmine/htdocs/files .
```
プラグインのファイルを保存する
```
tar czf redmine_plugins.tar.gz -C /opt/redmine-3.4.6-1/apps/redmine/htdocs/plugins .
```
現在の環境のbitnami redmineを停止する
```
sudo /opt/redmine-3.4.6-1/ctlscript.sh stop
```
新しいバージョンのbitnami redmineのインストーラを実行する。ウィザード形式なので、ウィザードにしたがって設定をする。
```
sudo ./bitnami-redmine-4.1.1-5-linux-x64-installer.run
```
インストールができたら、新しいRedmineが起動しているので、アクセスして、アクセスできることを確認する。

アクセスができ（＝インストールされている）ていれば、次にApacheを停止する
```
sudo /opt/redmine-4.1.1-5/ctlscript.sh stop apache
```
新しいデータベースの接続情報を確認する。下記のファイルに記載されている。
```
/opt/redmine-4.1.1-5/apps/redmine/htdocs/config/database.yml
```
旧環境のデータを保存したディレクトリに移動し、下記のコマンドで、データベースのデータを入れる。
```
/opt/redmine-4.1.1-5/mysql/bin/mysql -u bitnami -p < ./bitnami_redmine.sql
```
次に、データを展開する。プラグインを使っているようであれば、プラグインも同じように展開する。
```
sudo tar xzf ./redmine_files.tar.gz -C /opt/redmine-4.1.1-5/apps/redmine/htdocs/files
```
Productionログのパーミッションを一時的に変更する（後から戻す）。
```
sudo chmod 666 /opt/redmine-4.1.1-5/apps/redmine/htdocs/log/production.log
```
新しい環境のRedmineの実行環境のディレクトリに移動する
```
cd /opt/redmine-4.1.1-5/apps/redmine/htdocs/
```
次にDBのマイグレーションを実行する。
```
sudo /opt/redmine-4.1.1-5/ruby/bin/ruby bin/rake db:migrate RAILS_ENV=production
```
キャッシュをクリーンナップする
```
sudo /opt/redmine-4.1.1-5/ruby/bin/ruby bin/rake tmp:clear
```
Productionログの権限を元に戻す
```
sudo chmod 644 /opt/redmine-4.1.1-5/apps/redmine/htdocs/log/production.log
```
Apacheを起動する
```
sudo /opt/redmine-4.1.1-5/ctlscript.sh start apache
```
設定ファイルなどの変更が必要な場合には変更する。
2020年10月25日