Ubuntu20

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 (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。