お知らせ
このデータ移行の後で、Samba ad dc によるユーザー管理に移行しています。
---
先日、Ubuntu18.04でKopanoをインストールして動作するまでの設定をしてみたら、思ったよりうまく動いてくれた印象。
実は一番気にしていた移行が難しそうなサービスってこれだった。後のサービスはどうにかなるだろうということで、Ubuntu16.04サーバーからUbuntu18.04への移行手順を確立する。
これまでの過程でいくつかのサービスは別のサーバーに切り出した。
- DHCP
- DNS
- NTP
- 等々(気付いたら随時更新)
いわゆる最低限のサービスを別のサーバーで実行して家庭内のサービスを安定化させ、アプリケーション的なサービスのみ移行を待っている状態。具体的には…
- Kopano
- Alfresco
- WordPress
- mailman
- Samba
- 等々(気付いたら随時更新)
である。
仮想サーバーの性能のプアーさを考え、移行については「日常使っているPCで仮想PCを作ってサーバー移行手順を確立し、1日サービスを停止、その間に全てを移行して仮想PCを置き換える」…ってやり方を考えた。多分、1日あればデータの移行は完了できるという想定。
当面の記事は「移行の手順を確立」の部分がメインとなる。
移行にあたって、構築するサーバーの名前はtemp。最終的にターゲットとなるhogeserverに置き換える。っていうシナリオ。
この記事ではKopanoを旧環境から復元することを考える。
Kopanoインストール
移行するにしても、まずはプラットフォームのインストールが必要でしょ?ということで、先日書いた記事をベースにKopanoをインストール。この段階では、ログイン画面しか見られないが、移行という大事業の中では仕方のないこと。
SSLについては、自宅という小さな組織の中で利用可能なCAを作っており、このCAに認証されたサイト temp 君は堂々と振る舞えるという前提。Let's Encryptとかで有効な証明書を取得したり、設定の間だけと割り切ってsnakeoilを利用する手もあると思う。
旧環境のデータをバックアップ
kopano-backupというコマンドでバックアップをとることができて、既にバックアップがあるなら増分だけを追加で取り出す仕様になっている模様。
それとは別にデータベースのバックアップ、添付ファイルのバックアップを全部とっておくという方法もあることがわかり、じゃあ、添付ファイルの扱いはどうなっている?と確認すると。
現環境
/etc/kopano/server.cfg
# Where to place attachments. Value can be 'database', 'files' or 's3'
attachment_storage = files
# Enable fsync as method to make sure attachments are stored on disk where
# supported and will not be buffered by OS and/or filesystem. Please note
# this setting will lower attachment write performance depending on your
# environment but enhances data safety with disaster recovery.
# Only affects 'files' attachment storage backend.
attachment_files_fsync = yes
# When attachment_storage is 'files', use this path to store the files
# When attachment_storage is 's3', use this path to set a prefix to all
# attachment data of a certain cluster, for example 'attach'
attachment_path = /var/lib/kopano/attachments
# Compression level for attachments when attachment_storage is 'files'.
# Set compression level for attachments disabled=0, max=9
attachment_compression = 6
新環境
/etc/kopano/server.cfg
# Where to place attachments. Value can be 'database', 'files' or 's3'
attachment_storage = files
# Enable fsync as method to make sure attachments are stored on disk where
# supported and will not be buffered by OS and/or filesystem. Please note
# this setting will lower attachment write performance depending on your
# environment but enhances data safety with disaster recovery.
# Only affects 'files' attachment storage backend.
attachment_files_fsync = yes
# When attachment_storage is 'files', use this path to store the files
# When attachment_storage is 's3', use this path to set a prefix to all
# attachment data of a certain cluster, for example 'attach'
attachment_path = /var/lib/kopano/attachments
# Compression level for attachments when attachment_storage is 'files'.
# Set compression level for attachments disabled=0, max=9
attachment_compression = 6
ということで、インストールをさらーっと実行すると添付ファイルはファイルで管理しているらしい。
まるごと移行したいのだから、データベースのバックアップとファイルのバックアップをとって復元すりゃいいのかな?と思うのは自分的には自然な成り行き。そのやり方についてはここに記述がある。
KC Administrator Manual / Docs » 10. Backup & Restore
現環境=移行元となる環境でバックアップするデータベースは何なのか確認。
$ mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 9013
Server version: 5.7.26-0ubuntu0.16.04.1 (Ubuntu)
Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| alfresco |
| kopano |
| mysql |
| openmeetings |
| performance_schema |
| sys |
| test |
| wordpress |
+--------------------+
9 rows in set (0.35 sec)
mysql> quit
Bye
ということで、データベース名は kopano だった。
メールはいつ飛んでくるか分からないけど、それを考えたらやっていられないからサービスを止めてしまってデータベースとファイルのバックアップをとりゃいいかなと。
$ sudo systemctl stop postfix
$ sudo systemctl stop kopano-server
$ sudo mysqldump -p --single-transaction --routines kopano > kopanoserver.dmp
$ sudo zip kopanoattachment.zip -r /var/lib/kopano/attachments
$ sudo systemctl start kopano-server ← 移行本番ではサービス起動しない
$ sudo systemctl start postfix ← 移行本番ではサービス起動しない
今回は手順の確立のためにバックアップをとりだしているので、バックアップが終わったらサービスを起動してサービスを復旧する。
移行本番では、サービスを止めておいて、移行が完了したら新環境でサービスを動かすようにする。そうしないと、移行中に着信したメールや追加したスケジュールが消失してしまうだろうから。
新環境へデータをリストア
さて、復元先=新環境のデータベースはどうなっているかというと…
$ sudo mysql -u root
[sudo] password for rohhie:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 11287
Server version: 10.1.38-MariaDB-0ubuntu0.18.04.2 Ubuntu 18.04
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| kopanoserver |
| mysql |
| performance_schema |
| wordpress |
+--------------------+
5 rows in set (0.15 sec)
MariaDB [(none)]> quit;
Bye
ということで、kopanoserverという名前だった。
バックアップファイルを新環境にどうにかして転送する。
TeraTermを使っているが「SSH SCR...」を使ってバックアップファイルを一旦作業用PCに取り出して、それを「SSH SCR...」で送り込んだ。フルパスじゃないとファイルをうまく指定できないので、/home/hogeuser/・・・的な形で指定。
ダイレクトにやりとりする方法は絶対にあるはずだけど、まぁ、いいや。
$ sudo systemctl stop kopano-server
$ sudo mysql -D kopanoserver < kopanoserver.dmp
$ sudo unzip kopanoattachment.zip -d /
$ sudo chown kopano:kopano -R /var/lib/kopano
$ sudo systemctl start kopano-server
これで新環境にログインできてデータも添付ファイルもメモもスケジュールも全てがきっちり復元できていた。
Z-Pushのカレンダー共有設定の復元
Kopano WebAppにおけるカレンダー共有設定は、データベースに保管されているらしく、しっかりと共有ができるようになっていた。
一方、Z-Pushによるカレンダー共有はZ-Pushの設定で行わなければならないので、設定を復元する必要がある。過去記事を確認してみると結果的には…
現環境
/usr/share/z-push/config.php
$additionalFolders = array(
// demo entry for the synchronization of contacts from the public folder.
// uncomment (remove '/*' '*/') and fill in the folderid
/*
array(
'store' => "SYSTEM",
'folderid' => "",
'name' => "Public Contacts",
'type' => SYNC_FOLDER_TYPE_USER_CONTACT,
),
*/
array(
'store' => "hogeuser",
…
たくさんの設定
…
);
と赤文字部分で設定していたので、これを新環境に持ってくればOK。
念のため再起動して動作を確認する。
動作確認
動作確認のために、作業用PCのhostsファイルを書き換えて、新環境tempをhogeserver.hogeddns.jpに見せかけて確認してみる。
C:\Windows\System32\drivers\etc
172.16.nnn.nnn hogeserver.hogeddns.jp
※172.16.nnn.nnnに新環境tempのIPアドレスを書く。
pingを打ってみれば、見せかけが成功しているかどうかが分かる。
この状態でWindows10のメールでアカウントを作ってメールが取れること、カレンダーを起動して共有先を含むスケジュールが閲覧できることを確認する。
確認が終わったら上記記載を削除、元に戻しておく。
さいごに
ぶっちゃけます。
過去、Ubuntu12.04からUbuntu14.04にアップグレードしたときに添付ファイルを失い(添付ファイルを復元していなかった)、Ubuntu16.04にアップグレードしたときにメモが壊れる問題(キャラクタセットが変わった!?)が発生していた。記事を書いた時点では気付いていなくて、後から「あれっ?」となっていたが後の祭りだった。
データベースを復元するやり方は「移行元と移行先が同じ環境」であることを前提にしているはずだから、バージョンアップで何かが変わればちゃんと復元できないのは道理。従って、本当はkopano-backupでデータを取り出しておいて復元するのが一番安全な気がする。
じゃあ、アップグレード手順はどうか?というと、実際にはサービスを全て止めた上でパッケージをアップグレードし、サービスを起動するだけの模様。ってことは、今回のやり方でほぼ問題ないのかな…と思われ。
コメントはこちらから お気軽にどうぞ ~ 投稿に関するご意見・感想・他