OpenDolphin日記

環境一新に合わせて、ついでに新サーバを組もうと思って CPU を物色していたら、i5-12400F という CPU が、一体安かったので買ってしまった。マザーボードは ASUS PRIME/B660M-A/D4。この CPU はプロセッサーグラフィックスの付いていない CPU で、オンボードグラフィックは使えず、別にグラフィックボードを用意しないと画面表示ができないものだった。最初知らなくて、画面が表示されずに焦ったが、古い GeForce 7300 LE が院長室のがらくた箱で眠っていたので、それを刺して無事使えるようになった。GeForce 7300 LE も、まさか自分が再び使われる日がくるとは思ってなかっただろう。

早速、レセプト処理速度でベンチマークをしてみたら、開業以来最速と言われた 2019年の i9-9900 を上回る爆速であった。これは CPU の威力もさることながら、M.2 NVMe の進歩が大きいと思われる。

レセプト処理速度： 件/sec

自宅サーバに続いて、業務用マシンも ubuntu 20.04 の kvm 仮想マシンに移行した。そもそも、自宅サーバの ubuntu 18.04 + xen が、apt-get upgrade 後にネットワークがつながらなくなってしまったのがことの始まりであった。つまり、同じ構成で運用している業務用マシンも、次にレポジトリアップデートしたが最後、一体使えなくなるであろうということである。自宅サーバは、復活まで２週間を要しており、業務用マシンをアップデートする前に事態に気付いたのは不幸中の幸いであった。

当院の業務用サーバでは、orca サーバ、dolphin サーバ、文書を保存するファイルサーバの3台のサーバを仮想マシンで運用している。今回のインストールは完全リフレッシュしようと思って、全て新規に ubuntu 20.04 をインストールした。

1. 文書サーバ

   文書サーバは samba で共有している。samba サーバの設定は、いつもつながらなくて苦しむ印象がある。今回もつながらなくて、かなりの時間苦しんだ。原因は単純に共有の大元のディレクトリの所有権の設定ミスだった。orz。このサーバでは、dzd100.rb も動いているので、設定を忘れてはいけない。

2. orca サーバ

   orca サーバはずっと release-upgrade でつないできたので、de novo でインストールしたのはほぼ10年ぶりである。インストールマニュアルと首っ引きでインストールした。標準インストールに続いて、pusher インストール、オン資インストールと進んだ。

   orca はプリンタ設定が一体鬼門であると思う。以前インストールしていたBrother HL-5250DN Foomatic/pxlmonoはメニューに出なくなっていた。代わりにbrother-cups-wrapper-laserパッケージをインストールして、Brother HL5250DN for CUPSを選択した。さらに当院ではプリンタ関連で特殊な操作を行っていて、これも設定し直した。

   オン資関連では、almex の保険証 OCR データを横取りして修正する自作スクリプトを導入していて、その設定も必要だった。

   あと、MaxJobs 関連で rc.local を使っていたが、新規インストールの ubuntu 20.04 では rc.local はなくなっていた。ファイルを作れば呼ばれることは呼ばれるらしいが、cron の @reboot に設定を移した。OpenDolphin との連携で、orca にアクセスするために orca 側で postgresql.conf の listen_address と pg_hba.conf の設定が必要。これもすっかり忘れていて、OpenDolphin が立ち上がらなくて気付いた。

   ubuntu 20.04 の orca 5.2 は 2025年 3月までサポート。またしばらくいじらなくてすみそう。

3. dolphin サーバ

   de novo インストールで、一番楽だったのは dolphin サーバだった。wildfly は dolphin ホームディレクトリで走っているので、postgres と java をインストールして、ホームディレクトリをコピーすれば、基本的に移行完了。

ゲストマシンの作成

ゲストを作成するのには virt-install コマンドを使う。その際、--os-variant=ubuntu20.04 を指定すると、自動的に準仮想化で設定してくれる。--os-variant のパラメータは、libosinfo-bin をインストールして、osinfo-query で確認できる。

$ sudo aptitude install libosinfo-bin
$ osinfo-query os | grep -i ubuntu

virt-install コマンドを入力後、vnc でアクセスしてインストールを進める。

$ sudo virt-install --name=template \
--os-variant=ubuntu20.04 --vcpu=2 --ram=2048 \
--graphics vnc,listen=0.0.0.0,port=5900,keymap=ja,password=pass \
--cdrom=/home/pinus/ubuntu-20.04.5-live-server-amd64.iso \
--network network=host-bridge --disk /dev/sda3,device=disk \
--check path_in_use=off

WARNING  グラフィックスが要求されていますが DISPLAY 変数が設定されていません。virt-viewer を起動できません 。
WARNING  ゲストのコンソールがないため、デフォルト値 --wait -1 を適用します。
インストールの開始中...
Domain installation still in progress.
Waiting for installation to complete.
--- ここで vnc でインストール作業 ---
ドメインがシャットダウンしました。続けています。
仮想マシンの作成が完了しました。
ゲストを再起動しています。

Nextcloud インストール

ずっと自宅サーバーで ownCloud を運用していたが、今回環境変更にあたって、話題の Nextcloud をインストールしてみた。snap というのを使って簡単にインストールできる。

$ sudo snap install nextcloud
nextcloud 25.0.2snap1 from Nextcloud✓ installed

インストール終了後、apache 設定しようと思ったら apache がなかった。service にないし /etc/apache2 もない。きつねに包まれたような気分になった。調べてみると、snap パッケージの場合、Nextcloud が使う専用の apache を snap 内で使っているらしい。時代は進んでいる。

nextcloud 関連ファイルの場所

/snap/nextcloud/current/conf/httpd.conf
/snap/nextcloud/current/conf/ssl.conf
/var/snap/nextcloud/common/nextcloud/data/user/files/
/var/snap/nextcloud/current/nextcloud/config/config.php

これでやっと自宅サーバが復活した。トラブル発生から復活まで2週間かかった。

1月中旬に Ubuntu 18.04 + xen + ownCloud で運用していた自宅サーバ (mac mini 2011) で、いつもどおりレポジトリの更新をインストールしたら、dom-u の owncloud のネットワークがつながらなくなった。（＊）

振り返ってみると、自宅サーバは debian squeeze で運用開始して、その後 ubuntu 11.04 に移行し、代々 release-upgrade を繰り返して環境を引き継いできたものであった。その間、インターフェースの名前は predictable に代わり、ネットワーク設定が netplan になり、自宅サーバは時代の変化に取り残された化石マシンになってしまっていた。

それが原因だろうと思い、predictable interface name にしてみたり、netplan にしてみたりしたが、結局つながらない。dom-u ではネットワークが up しており、dom-0 では vif1.0 が見えている、でもつながってないので、bridge のところで何かおきているらしい。web 検索で見つけた echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables というのも試してみたがつながらない。

数日あれこれ試行錯誤したがだめで、かなり悩んだが、そういえば ubuntu 18.04 はまもなくサポート終了だし、環境を一新するいい機会だと考えることにした。

当院開業の時、サーバを仮想環境で動かすに当たって、準仮想化の Xen と、コンテナ型の Linux-VServer、 OpenVZ を比較検討して、xen を採用したという経緯があった。

今の状況だと、検討するとしたら準仮想化の kvm かコンテナ型の docker ということになると思う。今回は kvm で構築することにした。機会があれば docker も試してみたい気はする。

kvm のインストール

1. kvm はカーネルに組み込まれているので、xen の様に hypervisor を新たにインストールする必要はない。開業当時、kvm が linux カーネルに組み込まれることが決定してニュースになっていたのを思い出す。

   $ sudo apt install qemu qemu-kvm libvirt-daemon libvirt-clients bridge-utils virt-manager
   $ lsmod | grep kvm
   kvm_intel  282624  0
   kvm        663552  1 kvm_intel
   

2. 仮想マシンの管理には xl ではなく、libvirt (コマンドは virsh) を使う

   $ sudo systemctl enable --now libvirtd
   $ systemctl status libvirtd
   ● libvirtd.service - Virtualization daemon
        Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
              ：
   

3. br_netfilter を組み込んで無効にする。これをしておかないと、仮想マシンが外に出られない。(元々 xen の dom-u がつながらなくなった件もこれが原因かと思ったのだが、この設定をしてもつながらなかった)
   /etc/modules-load.d/modules.conf

   # /etc/modules: kernel modules to load at boot time.
   #
   # This file contains the names of kernel modules that should be loaded
   # at boot time, one per line. Lines beginning with "#" are ignored.
   br_netfilter
   

   /etc/sysctl.conf

   #added
   net.bridge.bridge-nf-call-iptables = 0
   

   $ cat /proc/sys/net/bridge/bridge-nf-call-iptables
   0
   

4. netplan でブリッジ br0 を作る

   network:
     ethernets:
       enp2s0f0:
         dhcp4: no
     bridges:
       br0:
         interfaces:
           - enp2s0f0
         dhcp4: no
         addresses:
           - 192.168.1.100/24
         nameservers:
           addresses:
           - 192.168.1.1
           search: []
         routes:
           - to: default
             via: 192.168.1.1
     version: 2
   

5. その br0 を使う network を定義する br0.xml を作って、virsh で kvm 用のネットワーク設定を作る。できた kvm 用のネットワーク設定は /etc/libvirt/qemu/networks/ に入る。

   $ cat br0.xml
   <network>
     <name>host-bridge</name>
     <forward mode="bridge"/>
     <bridge name="br0"/>
   </network>
   
   $ sudo virsh net-define br0.xml
   Network host-bridge defined from br0.xml
   
   $ sudo cat /etc/libvirt/qemu/networks/host-bridge.xml
   <!--
   WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
   OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
     virsh net-edit host-bridge
   or other application using the libvirt API.
   -->
   <network>
     <name>host-bridge</name>
     <uuid>c8b61fe1-7602-3028-15f3-2954207391fa</uuid>
     <forward mode='bridge'/>
     <bridge name='br0'/>
   </network>
   
   $ sudo virsh net-list --all
    Name          State      Autostart   Persistent
   --------------------------------------------------
    default       active     yes         yes
    host-bridge   inactive   no          yes
   

6. ブリッジの起動と、自動起動の設定

   $ sudo virsh net-start host-bridge
   Network host-bridge started
   $ sudo virsh net-autostart host-bridge
   Network host-bridge marked as autostarted
   $ sudo virsh net-list --all
    Name          State    Autostart   Persistent
   ------------------------------------------------
    default       active   yes         yes
    host-bridge   active   yes         yes
   

以上で、xen の dom-0 にあたる部分の設定が完了。

• 必要な php モジュールをインストールする

  $ sudo aptitude install php7.4 php7.4-xml php7.4-intl php7.4-gd php7.4-curl php7.4-zip php7.4-mbstring
  

• apache2 再起動

  $ sudo a2dismod php7.2
  $ sudo a2enmod php7.4
  $ sudo service apache2 restart
  

xen domU で運用している自宅サーバの owncloud を ubuntu 18.04 にアップグレードした。これで全ての xenial を bionic にアップグレード完了。

1. 準備ˀ

   $ sudo aptitude update
   $ sudo aptitude upgrade
   $ sudo apt-get autoremove
   

2. postgres のデータベースをバックアップ

   $ pg_dump -Fc owncloud > owncloud.dump
   

3. owncloud を削除する

   $ sudo aptitude purge owncloud-files
   $ sudo rm -rf /var/www/owncloud/apps
   $ sudo rm -rf /var/www/owncloud/config
   $ sudo rm /etc/apt/sources.list.d/owncloud.list
   

4. postgres を削除する

   $ sudo aptitude purge postgresql-9.5 postgresql-client-9.5
   

5. do-release-upgrade

   $ sudo do-release-upgrade
   　：
   システムのアップグレードが完了しました。
   'Y' を選択すると再起動します。
   続行する[yN]
   

6. postgresql-10 のインストール

   $ sudo aptitude install postgresql
   

7. postgresql の設定

   $ sudo vi /etc/postgresql/10/main/postgresql.conf
   listen_addresses = '*'
   
   $ sudo vi /etc/postgresql/10/main/pg_hba.conf
   # IPv4 local connections:
   host    all             all             127.0.0.1/32            trust
   # IPv6 local connections:
   host    all             all             ::1/128                 trust
   

8. 古いまま残っている php モジュールを探して 7.2 にバージョンアップ

   $ aptitude search php | grep -e '^i'
   $ sudo aptitude install php-pgsql php-curl php-readline
   

9. php を a2enmod

   $ sudo a2enmod php7.2
   $ sudo systemctl reload apache2
   

10. データベースを dump から戻す

    $ sudo -i
    # su - postgres
    $ psql 
    postgres=# CREATE USER a_user WITH PASSWORD 'a_passwd';
    postgres=# CREATE DATABASE owncloud TEMPLATE template0 ENCODING 'UNICODE';
    postgres=# ALTER DATABASE owncloud OWNER TO a_user;
    postgres=# GRANT ALL PRIVILEGES ON DATABASE owncloud TO a_user;
    postgres=# \q
    $ pg_restore -Fc -d owncloud owncloud.dump
    

11. owncloud のレポジトリを設定する

    $ curl https://download.owncloud.org/download/repositories/production/Ubuntu_18.04/Release.key | sudo apt-key add -
    $ sudo sh -c "echo 'deb http://download.owncloud.org/download/repositories/production/Ubuntu_18.04/ /' > /etc/apt/sources.list.d/owncloud.list"
    

12. owncloud のインストール

    $ sudo aptitude update
    $ sudo aptitude install owncloud-files
    $ sudo systemctrl reload apache2
    

13. config.php に memcache.local の設定

    'memcache.local' => '\OC\Memcache\APCu',
    

14. cron の設定

    $ sudo -u www-data sh -c "echo '7,22,37,52 * * * * php occ system:cron > /dev/null 2>&1' | crontab"
    

15. あとは，ブラウザからアクセスして，「アップデートを開始」をクリック。無事 ubuntu 18.04 + owncloud 10.3.1 にアップデートされた。

サーバの xen dom0 を ubuntu 18.04 にアップグレードした。16.04 の時と同じように do-release-upgrade した。

1. 準備と do-release-upgrade

   $ sudo aptitude update ; sudo aptitude upgrade
   $ sudo apt-get autoremove
   $ sudo do-release-upgrade
   　：
   アップグレードを開始しますか？
   3 個のインストール済みパッケージは Canonical によってサポートされなくなりました。ただしコミュニティからのサポートは受けることができます。
   6 個のパッケージが削除されます。 204 個の新規パッケージがインストールされます。 518 個のパッケージがアップグレードされます。
   合計 384 M をダウンロードする必要があります。 このダウンロードは約 3 分 かかります。
   アップグレードをインストールするのに数時間かかることがあります。ダウンロードが完了してしまうと、処理はキャンセルできません。
   続行する[yN]  詳細 [d]y
   　：
   アップグレードを完了するには再起動が必要です。
   'Y' を選択すると再起動します。
   続行する[yN] y
   

2. 再起動後に uname でカーネルを確認

   $ uname -r
   4.15.0-70-generic
   

   /etc/default/grub.d/xen.cfg を見ると，XEN_OVERRIDE_GRUB_DEFAULT=1 を設定しなくても xen でブートされるようになっていた

3. 起動時に Running /scripts/local-premount で 30秒間固まってしまう /etc/initramfs-tools/conf.d/resume のバグの workaround
   RESUME=UUID=xxxx を RESUME=noneに 書き換えて sudo update-initramfs -u する。

   $ cat /etc/initramfs-tools/conf.d/resume
   RESUME=none
   $ sudo update-initramfs -u
   

新しいサーバで速度比較してみた。新サーバ爆速。

新サーバが速いのは NVMe の力がかなり大きいと思われる。技術の進歩に驚かされる。

左:HDD (3.5" - 320G)，右上:SSD (2.5" - 500G)，右下:NVMe (m.2 - 500G)

前回サーバの CPU を i7-3770K に更新してから既に6年以上経っていたことに気付いてしまい，気付いた以上仕方がないので 6年ぶりに CPU をアップグレードすることにした。今回 CPU は大分安くなってきた i9-9900K@3.6GHz，マザーボードは ASRock Z390M Pro4 (安心な日本語説明入り) を買ってきた。そして，前回と同じくそのままではネットワークが使えないことが判明した。orz

マザーボードの ether チップ (I219-V) が ubuntu 16.04 の e1000e ドライバ 3.2.6 だと対応していないのが原因で，最新の 3.4.2.1 に更新すると使えるようになる。前回の時もドライバ更新して対応はできたのだが，カーネルのアップグレードの度にドライバをコンパイルして更新するという面倒くさいことになってしまったため，on board LAN をあきらめてネットワークカードを買ってきたという経緯があった。

しかし，今回 web 検索で DKMS (Dynamic Kernel Module Support) なる機能を発見した。これを使うと，カーネルのアップグレードの際に自動的にドライバをコンパイルして更新してくれるようになる。

• I219-V のドライバのソースをダウンロード。
• 動いている ubunbu マシンで，インストーラのカーネルバージョンに合わせて make し，e1000e.ko を作る。

  $ LANG=C BUILD_KERNEL=4.4.0-142-generic make
  

• インストーラでインストール開始。なお，UNetbootin だと CD-ROM 検出のところでエラーが出て進めなくなってしまう。
  
• 言語選択画面でおもむろに option-F2 を押してコンソールに入る。
• e1000e.ko を入れた USB をマウントしてドライバをロードする。ptp が依存しているので先に modprobe する必要あり。(modinfo e1000e.ko | grep ^depends で確認)

  # modprobe ptp
  # insmod /mnt/e1000e-3.4.2.1/src/e1000e.ko
  # umount /mnt
  

• option-F1 でインストーラに戻ってインストールを続ける。

インストール完了後，恒常的に e1000e ドライバが読み込まれるように設定する。

• ドライバを home directory に持ってくる。
• build-essential が必要なので，とりあえずつながるようにしてからインストールする。

  $ sudo modprobe ptp
  $ sudo insmod ~/e1000e-3.4.2.1/src/e1000e.ko
  $ sudo apt-get build-essential
  

• インストール完了したらさっきのは削除。

  $ sudo rmmod e1000e
  

• ドライバをインストールする。

  $ cd ~/e1000e-3.4.2.1/src
  $ make
  $ sudo make install
  

• インストールされたので，modprobe でドライバが有効になる。

  $ sudo modprobe e1000e
  

• バージョン確認。

  $ sudo modinfo e1000e
  filename:       /lib/modules/4.4.0-142-generic/updates/drivers/net/ethernet/intel/e1000e/e1000e.ko
  version:        3.4.2.1-NAPI
  　：
  

dkms でカーネルアップグレード後に自動的にドライバがインストールされるようにする。

• dkms をインストール，/usr/src にドライバのソースをコピーする。

  $ sudo apt-get install dkms
  $ sudo cp -r ~/e1000e-3.4.2.1 /usr/src/
  

• /usr/src/e1000e3.4.2.1/dkms.conf の作成。/lib/modules/${kernelver}/updates/dkms/ にドライバがセットされる。

  PACKAGE_NAME="e1000e"
  PACKAGE_VERSION="3.4.2.1"
  BUILT_MODULE_LOCATION=src
  BUILT_MODULE_NAME[0]="e1000e"
  DEST_MODULE_LOCATION[0]="/updates"
  AUTOINSTALL="yes"
  MAKE[0]="BUILD_KERNEL=${kernelver} make -C src CFLAGS_EXTRA=-DDISABLE_PM"
  CLEAN[0]="make -C src clean"
  REMAKE_INITRD=yes
  

• ドライバを dkms に登録，ビルド，インストールする手順。

  $ sudo dkms -m e1000e -v 3.4.2.1 add 
  $ sudo dkms -m e1000e -v 3.4.2.1 build 
  $ sudo dkms -m e1000e -v 3.4.2.1 install 
  

xen のインストール

• xen-hypervisor-amd64 のインストールで bridge-utils，xen-utils もインストールされる。

  $ sudo aptitude install xen-hypervisor-amd64
  

• balooning の設定。

1. autoremove

   $ sudo apt-get autoremove
   

2. postgres のデータベースをバックアップ

   $ pg_dump -Fc owncloud > owncloud.dump
   

3. owncloud を削除する

   $ sudo aptitude purge owncloud
   $ sudo rm /etc/apt/sources.list.d/owncloud.list
   

4. do-release-upgrade

   $ sudo do-release-upgrade
   　：
   設定ファイル '/etc/apache2/sites-available/default-ssl.conf'
    ==> これはインストールしてから (あなたかスクリプトによって) 変更されています。
    ==> パッケージ配布元が更新版を提供しています。どうしますか? 
   → N
   　：
   廃止されたメジャーバージョン 9.3
   既存のクラスタがアップグレードされた後に、postgresql-9.3 および postgresql-client-9.3 パッケージを削除する必要があります。
   → <了解>
   　：
   設定ファイル /etc/postgresql-common/createcluster.conf の新しいバージョン(/tmp/postgresql-common.4RBMXy) が利用可能ですが、現在インストールされているバージョンは、ローカルで変更されています。変更された設定ファイル createcluster.conf について何を行いたいですか? 
   → パッケージメンテナのバージョンをインストール
   　：
   システムのアップグレードが完了しました。
   'Y' を選択すると再起動します。
   続行する[yN]
   

5. postgresql-9.3 の削除と 9.5 のインストール

   $ sudo purge postgresql-9.3 postgresql-client-9.3
   $ sudo aptitude install postgresql
   

6. postgresql の設定

   $ sudo vi /etc/postgresql/9.5/main/postgresql.conf
   listen_addresses = '*'　←コメントを解除し、''内を * に修正
   
   $ sudo vi /etc/postgresql/9.5/main/pg_hba.conf
   # IPv4 local connections:
   host    all             all             127.0.0.1/32            trust
   # IPv6 local connections:
   host    all             all             ::1/128                 trust
   

7. カーネルアップグレード，再起動

   $ sudo apt-get install linux-generic
   

8. データベースを dump から戻す

   $ sudo -i
   # su - postgres
   $ psql 
   postgres=# CREATE USER a_user WITH PASSWORD 'a_passwd';
   postgres=# CREATE DATABASE owncloud TEMPLATE template0 ENCODING 'UNICODE';
   postgres=# ALTER DATABASE owncloud OWNER TO a_user;
   postgres=# GRANT ALL PRIVILEGES ON DATABASE owncloud TO a_user;
   postgres=# \q
   $ pg_restore -d owncloud owncloud.dump
   

9. owncloud のレポジトリを設定する

   $ curl https://download.owncloud.org/download/repositories/stable/Ubuntu_16.04/Release.key | sudo apt-key add -
   # echo 'deb http://download.owncloud.org/download/repositories/stable/Ubuntu_16.04/ /' > /etc/apt/sources.list.d/owncloud.list
   

10. owncloud のインストール

    $ sud aptitude update
    $ sudo aptitude install owncloud-files
    

11. maintenance モードに設定

    $ sudo vi /var/www/owncloud/config/config.php
     'maintenance' => true,
    

12. php のインストール

    $ sudo aptitude install php php7.0-pgsql php-bz2 php-curl php-gd php-imagick php-intl php-mbstring php-xml php-zip libapache2-mod-php
    

13. owncloud.conf の有効化と apache2 のリロード

    $ sudo a2enconf owncloud
    $ sudo service apache2 reload
    

14. maintenance モードを解除

    $ sudo vi /var/www/owncloud/config/config.php
     'maintenance' => false,
    

15. あとは，ブラウザからアクセスして，「アップデートを開始」をクリック。無事 ubuntu 16.04 + owncloud 10.0.4 にアップデートされた。