サーバ

2023年2月11日 (土)

サーバの CPU アップグレード

環境一新に合わせて、ついでに新サーバを組もうと思って 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

CPU データチェック レセプト作成
i7-3770@3.4G
SSD
6.2 4.7
i9-9900K@3.6G
NVMe
17.0 13.2
i5-12400F@2.5GHz
NVMe
26.7 25.3

2023年2月10日 (金)

業務用マシンを ubuntu 20.04 にアップグレード

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

当院の業務用サーバでは、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 をインストールして、ホームディレクトリをコピーすれば、基本的に移行完了。

2023年2月 8日 (水)

自宅サーバのアップデート (2)

ゲストマシンの作成

ゲストを作成するのには 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週間かかった。

2023年2月 7日 (火)

自宅サーバのアップデート (1)

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-VServerOpenVZ を比較検討して、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 にあたる部分の設定が完了。

-----
(*)2023-02-16 追記
多分これだと思われる。

2021年12月23日 (木)

OwnCloud 10.9.0 へのアップグレード

owncloud を 10.9.0 にアップグレードしたところ、php 7.2 がサポートされなくなったというメッセージがでて、アクセスできなかった。php 7.4 をインストールして、設定しなおした。
  • 必要な 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
    

2019年11月24日 (日)

domU の owncloud サーバを ubuntu 18.04 にアップグレード

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 にアップデートされた。

2019年11月21日 (木)

サーバの dom0 を ubuntu 18.04 にアップグレード

サーバの 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=xxxxRESUME=noneに 書き換えて sudo update-initramfs -u する。
    $ cat /etc/initramfs-tools/conf.d/resume
    RESUME=none
    $ sudo update-initramfs -u
    

2019年5月31日 (金)

ベンチマーク

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

CPUi9-9900@3.6
NVMe
i7-3770@3.4
SSD
C2D E4500@2.2
SSD
大量カルテ読み込み6.7秒10.5秒-
dolphin サーバのデータベースダンプ4分22秒10分36秒-
orca レセプトチェック43秒1分57秒2分53秒
orca レセプト作成1分46秒4分13秒5分21秒

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

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

Img_0555

2019年5月30日 (木)

サーバの CPU アップグレード

Img_0540 前回サーバの 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 検出のところでエラーが出て進めなくなってしまう。
    Img_0445
  • 言語選択画面でおもむろに 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 の設定

2018年1月12日 (金)

domU の owncloud サーバを ubuntu 16.04 にアップグレード

domU で運用している自宅サーバの owncloud を ubuntu 16.04 にアップグレードした。
  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 にアップデートされた。