Ubuntu

ASRock H97 Pro4にXeon E3-1265L v3を載せたHaswellをUbuntu 22.04 LTS “Jammy Jellyfish"にアップデート。

sshログインでエラーになって慌てたが、/var/log/auth.logを確認したところ、ubuntu 22.04 ssh 公開鍵認証 失敗すると同じく

2022-11-16T02:40:57.691761+09:00 haswell sshd[418213]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

というエラーだ。「OpenSSH 8.8」リリースにあるとおり、

「OpenSSH 8.8」では、SHA-1ハッシュ（“ssh-rsa”）を使用したRSAキーによるデジタル署名を使用する機能がデフォルトで無効になった。SHA-512およびSHA-2（rsa-sha256-512 / 7.2）ハッシュを使用したRSA署名は従来通り利用できる。

という事だが、RSA鍵を捨てて新しいed25519鍵にスイッチ。

肝心のmacvlanの設定もそのまま機能していたのでOK。

…と思ったのだが、インタフェースはできているもののIPアドレスを振っても通信できないような。さて？

【追記】11月19日、対処済。

参照

Canonical Blog https://canonical.com/blog

• Canonical Ubuntu 22.04 LTS is released 2022年4月21日
• Upgrade your desktop: Ubuntu 22.04.1 LTS is now available 2022年8月11日

gihyo.jp https://gihyo.jp/

• 2022年4月22日号　Ubuntu 22.04 LTS “Jammy Jellyfish”のリリース 2022年4月22日
• Ubuntu 22.04.1のリリースに向けた作業 2022年8月5日
• Ubuntuにおける.NETのネイティブサポートと「Chisel」、StarFive VisionFiveボードへの対応。Ubuntu 22.04.1 LTSのリリース 2022年8月19日

kledgeb https://kledgeb.blogspot.com/

ASRock H97 Pro4にXeon E3-1265L v3を載せたHaswellにKVM環境を構築。

他のPCからLAN経由でアクセスできるようにしたいので、仮想NICの設定を物理NICの"Bridge"モードにしたところ

In most configurations, macvtap does not work for host to guest network communication.

という警告が表示された。

確かにLAN内の別マシンと仮想マシンとのpingは通るものの、ホストとゲストHaswellに閉じた世界では、どちらからもpingが疎通しない。そう言えば以前も悩んだような…と記憶を辿ってみたところ、物理NICをmacvlanでブリッジして、macvlanの方にIPを付与すればいい、という対処法を思い出した。

具体的には

$ ip addr del 192.168.199.2/24 dev enp0s25
$ ip link add dev macvlan0 link enp0s25 type macvlan mode bridge
$ sudo ip addr add 192.168.199.2/24 dev macvlan0
$ sudo ip link set macvlan0 up
$ ip route add default via 192.168.199.254 dev macvlan0

という手順でIPアドレスをenp0s25からmacvlan0に移設すればよい。

先週日曜、Webサーバーから

E: Package 'python-virtualenv' has no installation candidate

というエラーメール着弾。どうやらUbuntu 20.04 (Focal Fossa)にアップデートした余波でLet’s Encryptの自動更新がエラーになったようだ。

Ubuntu 20.04 上の certbot-auto でエラーが出る場合に倣ってpythonをpython3に書き換えてみたがダメ。手動でpython3-virtualenvをinstallしてみたものの、結局python2.7を見に行ってpipが古いと怒られる始末。

そもそも古いのは5年前に導入した自動更新スクリプトなんじゃね？と思い、git pullしなおしてみたものの、今度は

Skipping bootstrap because certbot-auto is deprecated on this system.
/opt/letsencrypt/letsencrypt-auto has insecure permissions!
To learn how to fix them, visit https://community.letsencrypt.org/t/certbot-auto-deployment-best-practices/91979/
**Your system is not supported** by certbot-auto anymore.
Certbot cannot be installed.
Please visit https://certbot.eff.org/ to check for other alternatives.

という結果に。

最新LTSのUbuntu 20がnot supportedてどういう事！？と思ったのだが、2021年版Let’s EncryptでのSSL証明書の発行方法/SSL化の方法によると

これまでcertbot-autoで証明書の発行ができたと思いますが、2020年12月のリリース1.10.0からDebian系で非対応になり、2021年1月のリリース1.11.0では全てのOSで非対応となりました。

という事で驚いたのだが、Certbot-auto no longer works on Debian based systemsによると

お仕事方面のサーバー構築でUbuntu 20.04をインストールしたところ、通常30分以内で終わる初期導入が1時間以上かかる問題に直面。

パッケージ導入時のプログレスバーも半分くらいまではいい感じで進むものの、後半のワーク領域の削除とか普段は目にも留まらぬ文字列が余裕で読てしまうほど遅々として進まず。

ストレージ構成は8TBのST8000DM004シングル構成なので、以前書いた「シングル磁気記録(SMR)方式」の方式ゆえに一定量を超える（削除を含む）書き込みが続くと性能低下が避けられないという宿命は解っていたものの、データドライブとしてXFS形式で使っている分にはそこまで気にならなかったのだが、ext4ファイルシステムでは性能低下が深刻なレベルで、ブートドライブとするのは大変厳しいという事のようだ。

取り敢えず、起動用に512GBなSSDを調達して運用開始したが、結局XFSのデータドライブでもVMやコンテナの動作に支障を来す事がわかったので、ちょっと割高だが4TBのCMRなHDDを用意する羽目に。

コスパはいいのだが、ファイルシステムを選ぶというのはちょっと厄介だな。

参照

Seagate 日本 https://www.seagate.com/jp/ja/

• 内蔵ハードディスク・ドライブ
• CMRおよびSMRハードディスク・ドライブ

PC Watch https://pc.watch.impress.co.jp/

• 【福田昭のセミコン業界最前線】10TBの大容量HDDを実現した「SMR技術」登場の背景 2015年9月30日
• ネットの論客にファイナルアンサー!? ～「もしかして……SMR!?」。最新2TBプラッタHDDをとことんイジメる 2018年12月3日

AKIBA PC Hotline! https://akiba-pc.watch.impress.co.jp/

• 最安の8TB HDD「ST8000AS0002」をテスト、SMR技術を再確認 2016年2月29日

GIGAZINE https://gigazine.net/

• WDのNAS向けHDD「WD Red」の記録方式が「RAIDに不向き」な仕様にこっそり変更されていたことが判明 2020年4月16日
• NAS向けHDD「WD Red」の記録方式をこっそり変更した件についてWDが釈明 2020年4月22日
• WDがNAS向けシリーズ「WD Red」で起こした問題は「沈黙し続ける企業文化そのもの」が原因との指摘 2020年6月16日
• Western Digital製の一部HDDの回転数が公称スペックと異なることが判明 2020年9月8日

＠IT https://www.atmarkit.co.jp/

• Linux Kernel Watch
• Linux Storage Filesystem/MM Summit 2014からの便り 2014年4月23日

Western Digital Corporate Blog https://blog.westerndigital.com/

• Zonefs File-System Will Land with Linux® 5.6 2020年2月24日
• Device-Managed Shingled Magnetic Recording (DMSMR) 2020年4月28日

Wikipedia https://ja.wikipedia.org/wiki/

• ハードディスクドライブ
• シングル磁気記録方式
• ファイルシステム
• ext4
• XFS

Ubuntu 20.04 (Focal Fossa)アップデートの残課題、「CGIでも使えるPNG式画像カウンタ」(pngcntr)が動かない問題にようやく立ち向かうことに。

まずはコマンドライン実行でもどこでコケているのかわかるように $err を X-PNGCNT-Error: で出力するようにしてみたところ、エラー -1を返すポイントが3箇所あった…orz

**yano@vps:/usr/lib/cgi-bin/pngcnt$ diff -bc ct_20161115.cgi ct_20210206.cgi**
*** ct_20161115.cgi     2016-11-15 10:53:50.382253440 +0900
--- ct_20210206.cgi     2021-02-06 11:01:00.000000000 +0900
***************
*** 233,238 ****
--- 233,239 ----
  {
        my($err) = @_;
+       print "X-PNGCNT-Error: $err \n";
        $err = 4 if($err >= 100);
        print "Content-Type: image/png\n\n";
***************
*** 558,569 ****
                        }
                        else
                        {
!                               return &Error(-1);
                        }
                }
                else
                {
!                       return &Error(-1);
                }
        }
        else    # ログファイルが読み込めず。
--- 559,570 ----
                        }
                        else
                        {
!                               return &Error(-3);
                        }
                }
                else
                {
!                       return &Error(-2);
                }
        }
        else    # ログファイルが読み込めず。
**yano@vps:/usr/lib/cgi-bin/pngcnt$ ./ct_20210206.cgi**
Set-Cookie: =1; expires=Sat, 06 Feb 2021 02:10:12 GMT;
X-PNGCNT-Error: **-1**
Content-Type: image/png
        PNG
～～
**yano@vps:/usr/lib/cgi-bin/pngcnt$**

というわけで、エラー**-1**を返すポイントが require の部分と判明。

2014年6月にUbuntu 14.04 (Trusty)にアップデートしたbravotouring.comのサーバ。

Hugo乗り換えを大義名分に先送りにしていたアップデートを、気の迷いで1月13日未明にうっかり実施。大胆にもdo-release-upgradeを3回繰り返し、LTS最新版のUbuntu 20.04 （Focal Fossa）という荒業にチャレンジしたメモ。

まず、spamassassinが起動に失敗。うん、CPANが追いついてないので無理だよね、というわけでひとまずuninstallして首絞め。

続いて、DKIMとNSDも起動に失敗していて、メールが送受信できない事に気づいて軽く慌てはじめる。/var/log/syslogの

Jan 13 03:59:56 vps nsd[2349728]: Error in SSL_CTX use_certificate_file 
    crypto error:140AB18F:SSL routines:SSL_CTX_use_certificate:**ee key too small**

というエラーに気づいた。ググってみるとOpenSSL 1.1.1/changelog[28 May 2019]で

Change the default RSA, DSA and DH size to 2048 bit instead of 1024. This changes the size when using the genpkey command when no size is given. It fixes an omission in earlier changes that changed all RSA, DSA and DH generation commands to use 2048 bits by default.

ASRock H97 Pro4にXeon E3-1265L v3を載せたHaswellでQSVなハードウェアエンコードをお試し。

2017年に通った道だが、まずは最新版のUbuntu 20.04(FocalFossa) Serverを導入。

続いて「Intel® Media SDK」を入れればいいのかぁな…と思ったのだが、2013年生まれのHaswellは古すぎるので、Video Acceleration API(VAAPI)を使えということらしい。

root@haswell:~# apt install -y build-essential libva2 vainfo i965-va-driver

で導入し、

root@haswell:~# vainfo
error: XDG_RUNTIME_DIR not set in the environment.
error: can't connect to X server!
libva info: VA-API version 1.7.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: va_openDriver() returns -1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_6
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.7 (libva 2.6.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Haswell Server - 2.4.0
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Simple            : VAEntrypointEncSlice
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileH264MultiviewHigh      : VAEntrypointVLD
      VAProfileH264MultiviewHigh      : VAEntrypointEncSlice
      VAProfileH264StereoHigh         : VAEntrypointVLD
      VAProfileH264StereoHigh         : VAEntrypointEncSlice
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc
      VAProfileJPEGBaseline           : VAEntrypointVLD
root@haswell:~# ll /dev/dri/
total 0
drwxr-xr-x   3 root root        100 Dec 09 16:43 ./
drwxr-xr-x  19 root root       4380 Dec 09 09:45 ../
drwxr-xr-x   2 root root         80 Dec 09 16:43 by-path/
crw-rw----+  1 root video  226,   0 Dec 09 16:43 card0
crw-rw----+  1 root render 226, 128 Dec 09 16:43 renderD128
root@haswell:~#

となればVideo Acceleration API(VAAPI)の準備OK。

ASRock H97 Pro4にXeon E3-1265L v3を載せたHaswell。

先月Ubuntu 20.04 Serverに入替えたのだが、時間がずれている？事に気づいたらタイムゾーンがJSTになっていなかった。

GUIならばいざしらず、CUIだとどうすんだ？というわけで、ググるとtimedatectlだとあっさりわかり、万事解決。

root@haswell:~# ll
total 44
drwx------  4 root root  4096 Oct  1 07:59 ./
drwxr-xr-x 20 root root  4096 Sep 24 02:08 ../
-rw-------  1 root root   630 Sep 24 06:48 .bash_history
-rw-r--r--  1 root root  3106 Dec  5  2019 .bashrc
-rw-r--r--  1 root root   161 Dec  5  2019 .profile
drwxr-xr-x  3 root root  4096 Sep 24 02:18 snap/
drwx------  2 root root  4096 Sep 24 02:17 .ssh/
-rw-------  1 root root 13436 **Oct  1 07:59** .viminfo
root@haswell:~# date
Thu 01 Oct 2020 08:20:21 AM UTC
root@haswell:~# `timedatectl`
               Local time: Thu 2020-10-01 08:20:32 UTC
           Universal time: Thu 2020-10-01 08:20:32 UTC
                 RTC time: Thu 2020-10-01 08:20:32
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
root@haswell:~#
root@haswell:~# `timedatectl set-timezone Asia/Tokyo`
root@haswell:~# `timedatectl`
               Local time: Thu 2020-10-01 17:20:46 JST
           Universal time: Thu 2020-10-01 08:20:46 UTC
                 RTC time: Thu 2020-10-01 08:20:46
                Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
root@haswell:~# date
Thu 01 Oct 2020 05:20:51 PM JST
root@haswell:~#

参照

Server World https://www.server-world.info/

gt110bもそろそろアレなので…、と言いつつXeon E3-1265L v3の調達以降なかなか進まなかった代替機の準備。

Windows 10を動かしていた高速なNVMe M.2 SSDを常時稼動サーバーの起動ディスクに使うのはさすがに勿体なくて、相応の入れ物を模索していたのだがCFDの2.5インチSSD「CG3VX」が3,000円ちょいという手頃な価格になってきたのでポチッとな。

というわけでAIF-06＋ZEUS KMPX3280と選手交代する形で、S6B240CG3VXをATAポートに接続。Ubuntu 18.04 LTS “Bionic Beaver”のServer版をインストール。

固定IPの設定をしようとして/etc/network/interfacesを開くとハズレ。Bionic以降はネットワーク設定のお作法が/etc/netplan/50-cloud-init.yamlを編集して、netplan applyを実行する手順となったようだ。

root@haswell:~# cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    ethernets:
        enp0s25:
            addresses:
            - 192.168.199.2/24
            - 240f:ca:5fb8:1:192:168:199:2/64
            gateway4: 192.168.199.254
            gateway6: 240f:ca:5fb8:1:192:168:199:254
            nameservers:
                addresses: [192.168.199.1, 8.8.8.8]
            dhcp4: no
            dhcp6: no
    version: 2
root@haswell:~#

参照

ASCII.jp － 自作PC https://ascii.jp/pc/

Ubuntu Weekly Topics 2017年4月7日号で朗報。

「Ubuntu 18.04 LTSのデフォルトデスクトップ環境」はGNOMEとなるそうだ。

画面左端に幅を取るUnityが大嫌いで、Ubuntu desktopをインストールする都度、真っ先にGNOME パネルに切り替えていたのだが、ようやく不毛な一手間が不要になる事を素直に喜びたい。

参照

gihyo.jp … 技術評論社 http://gihyo.jp/

• Ubuntu Weekly Topics
• 2017年4月7日号　Ubuntuの大きな方針変更／Unity 8の終了・linux-awsリリース 2017年4月7日

Wikipedia https://ja.wikipedia.org/wiki/

• Ubuntu
• GNOME
• Unity (ユーザインタフェース)