お知らせ(新しい記事を投稿しています)
ここで行った移行でメモが破壊される問題が発生していました。後から気付いたので元に戻せないままに今に至っています。
本来は新しい環境にKopanoをインストールし、ZarafaのデータをバックアップしてKopanoで復元する、というのが正しいやり方のように思います。
移行にあたりKopanoのデーターとはどんなものなのかを理解しておくことは大変重要です。少し趣旨は違いますが、ユーザー管理をSamba ad dc内蔵のLDAPで行う記事でhook-storeによるデータの付け替えやexternIDの書き換えを行っており、お役に立つことがあるかもしれません。
Zarafaをずっと使い続けることはできない。Ubuntu16に対応していないので、Ubuntu14をアップグレードするためにはKopanoへの移行が必要なのだ。分かっていたものの、後回しにしていたのだった。
Zarafa Community Hub にこんな記事が投稿された。
Zarafa End of Life -> Kopano(リンク切れのためアーカイブへ)
終焉…と。
良い機会だし、移行するか…
移行先となるKopanoを調べると、How to get Kopano というページがあり、
・KopanoにもCommunity Editionがあって、すべての機能を利用可能。
・顧客はFinalを含むリポジトリにアクセスができ、そこから入手できる。
・コミュニティは https://download.kopano.io/community から最新の開発中バージョンが入手できる。
となっている。
コミュニティはFinal版を使えないので多少のバグには覚悟する必要があるが、家族・親戚だけで運用しているシステムだから、まぁ問題ないだろう。
※今回はUbuntu14をUbuntu16へとアップグレードし、ZarafaパッケージをKopanoパッケージに置き換える。やることは多いし、失敗はしたくないし、でメモ記事は猛烈に長くなった。
作戦。
- 運用中のシステムをバックアップ。システムを停止しておけばvCenter Converter Standaloneでローカルにバックアップを取ることができる。システムを停止しなければならないのは痛いが、仕方がない。
- バックアップした運用中のシステムを、VMware Workstationで起動し、Kopanoへの移行を試して手順を確立する。
- 運用中のシステムをKopanoに移行する。
となる。家族・親戚だけで使うシステム、GW中はむしろ利用頻度が上がる方向なので、システムを止めっぱなしにはしにくいので、慎重に進める。
■運用中のシステムをバックアップ。
システムを停止して、vCenter Converter Standaloneでバックアップを取る。
難しくないので割愛。
事前に未使用領域に 0 を書き込んでおいた。
※バックアップのサイズが小さくなることを狙ったものだが、効果については別途検証が必要。
参照元 ESXi5でシンプロビジョニングされた仮想ディスクを圧縮する
$ dd if=/dev/zero of=./zerofile bs=32M; rm -f ./zerofile
これには猛烈な時間がかかる。
200GBのシステム、実際に使用しているのは30GB程、vCenter Converter Standaloneの作業予想時間は2時間半。この間、システムは停止するが、我慢我慢。
→ 結果としては、25分でバックアップ完了。仮想ディスクのサイズは18GBとなった。
■バックアップをVMware Workstationで起動。
いつも通りNICが差し替わってしまうので、ネットワーク設定を見直す。
・DHCPDが動いていると、VMwareより先にIPを取得してしまうので、止める。$ sudo sysv-rc-conf でOK。
・自分へのアクセスが稼働中のサーバーに飛んでしまわないように、dnsに登録している自分のホスト名を/etc/hostsに登録してしまう。
これでバックアップの動作設定完了。
接続先を間違えないように、念のために以下を追加して目視できるようにする。
/etc/update-motd.d/99-header2
#!/bin/sh # echo "☆☆☆☆☆ バックアップ環境です ☆☆☆☆☆"
※参考 Ubuntu 14.04でSSHログイン時のメッセージをカスタマイズ
なお、99-header_originalというファイル名にしたら動作しない。長すぎるからか、ファイル名に _ が入っているからかは分からないが、注意。
接続2回目から表示されるようになる。→なんでいつも「次の起動時」に表示されるのかわからないが、現状そうなっている。
起動も確認したし、バックアップのバックアップを取って、アップグレード手順の確立に向かう。
■アップグレード手順の確立(Ubuntu14 to Ubuntu16編)
Ubuntu14 から Ubuntu16 へのアップグレード、Zarafa削除、Kopanoインストール、という手順を考えている。Kopanoを見てみたら、やっぱりUbuntu14用とUbuntu16用が別れているので、一番手間が少なそうな方向はこれかな…と。
Ubuntuのアップグレードはログインの度に表示されていたコマンドを打ち込むのみ。
$ sudo do-release-upgrade 新しい Ubuntu のリリースをチェックしています 0% [作業中] 0% [jp.archive.ubuntu.com へ接続しています] 0% [jp.archive.ubuntu.com (160.26.2.187) へ接続しています] 0% [ヘッダの待機中です] 取得:1 ツールの署名のアップグレード [836 B] 99% [作業中] 99% [ヘッダの待機中です] 取得:2 ツールのアップグレード [1,265 kB] 100% [作業中] 1,266 kバイト/0秒 を取得しました (0 B/秒) 「xenial.tar.gz.gpg」を用いて「xenial.tar.gz」の認証を行ないます 'xenial.tar.gz' の展開中 キャッシュを読み込み中 パッケージマネージャーをチェック中です SSH経由で実行していますが、続けますか？ このセッションはSSH上で実行されているようです。アップグレードをSSH越しに行うことは推奨されません。アップグレードに失敗した時の復元が困難になるからです。 続行する場合、追加のSSHデーモンをポート '1022' で起動します。 本当に作業を進めてよろしいですか？ 続行する[yN] y 予備のsshdを開始します 障害が起こったときに復旧しやすくするため、ポート '1022' でもう一つの sshd を開始します。現在実行中のsshにおかしなことが起きても、もう一方のポートに接続することができます。 ファイアウォールを実行している場合、このポートを一時的に開く必要があります。この操作は、潜在的な危険があるため自動的には行われません。以下の例のようにしてポートを開けます: 'iptables -I INPUT -p tcp --dport 1022 -j ACCEPT' 続けるには [ENTER] キーを押してください [Enter] ・ ・ ・ パッケージリストを読み込んでいます... 完了 依存関係ツリーを作成しています 状態情報を読み取っています... 完了 データ構造を構築しています... 完了 リポジトリ情報のアップデート サードパーティが提供するリポジトリを使わない設定にしました sources.list にあるサードパーティが提供するリポジトリを使わない設定にしました。アップグレード完了後、'ソフトウェアソース' ツールもしくはパッケージマネージャーを使って再び利用可能な設定にすることができます。 続けるには [ENTER] キーを押してください [Enter] ・ ・ ・ パッケージマネージャーをチェック中です パッケージリストを読み込んでいます... 完了 依存関係ツリーを作成しています 状態情報を読み取っています... 完了 データ構造を構築しています... 完了 変更点を確認中 変更点を確認中 アップグレードを開始しますか？ 154 個のインストール済みパッケージは Canonical によってサポートされなくなりました。ただしコミュニティからのサポートは受けることができます。 65 個のパッケージが削除されます。 531 個の新規パッケージがインストールされます。 1668 個のパッケージがアップグレードされます。 合計 1,214 M をダウンロードする必要があります。 このダウンロードは約 4 分 かかります。 アップグレードをインストールするのに数時間かかることがあります。ダウンロードが完了してしまうと、処理はキャンセルできません。 続行する[yN] 詳細 [d]y ・ ・ ・
しばらくしたら
Restart services during package upgrades without asking?
と聞かれるので、はい、と回答。
インストール中、設定ファイルが変わったけど、どうする？という問い合わせが何度かあるので、席を離れられない。ジリジリ…
システムのアップグレードが完了しました。
再起動が必要です
アップグレードを完了するには再起動が必要です。
'Y' を選択すると再起動します。
続行する[yN] y
ここまで1時間弱。
この後、念のためパッケージのアップデートを行う。
$ sudo apt update; sudo apt dist-upgrade
アップデートするものもなく、完了。
ここで再起動したところ、ネットワークが上手く動かない。
Ubuntu16をクリーンインストールすると、eth0がenNNNみたいなのに変わったりしているのだが、これが影響しているのか？どうやってもネットワークに接続できない。ifconfigでは設定できているように見えているのに、自分以外にpingが通らないなど、かなり衝撃的な動作。
仕方がないので、NetworkManagerを削除して対応した。
$ sudo apt remove network-manager
その後、/etc/network/interfecesを編集。
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.NNN.NNN
netmask 255.255.255.0
gateway 192.168.NNN.1
dns-nameservers 127.0.0.1
auto eth0:1
iface eth0:1 inet static
address 192.168.NNN.NN2
netmask 255.255.255.0
これで、どうにかまともな接続ができるようになった(4時間の格闘)。
■アップグレード手順の確立(Zarafa 7.2.5 to Kopano 8.4.0編)
ようやく、Kopanoへのアップグレード。
Drop-in Migration from Zarafaを参考にして、実行していく。
コミュニティエディションの場合、スクリプトが実行するリポジトリの登録ができないので、手作業で実行するしかない状況。
作業は以下の手順で進める。
・Zarafa設定のバックアップ
・Zarafaのアンインストール
・Kopanoのインストール
・Kopanoの設定
・Postfixの設定修正
・動作確認
・ゴミ掃除
色々ありそうなので、結構な作業をrootで実行した(行頭が$でなく#のところ)。
(1) Zarafa設定のバックアップ
# cp -R /etc/zarafa /etc/zarafa.bak
(2) Zarafaのアンインストール
# dpkg -l | egrep '(mapi|gsoap|libical|vmime|zarafa)' | awk '{ print $2 }' | xargs apt-get remove
えぇ、上手く行きませんでしたとも。
| xargs apt-get remove
を除いて実行、結果を半角スペースでつなげてremoveしたよ…。ウチの環境だとこれ。
$ apt remove libgsoap-zarafa-2-8 libgsoap-zarafa-dbg libical-zarafa-dbg libical-zarafa-dev libical-zarafa1 libical1 libical1a:amd64 libicalmapi1 libinetmapi1 libmapi1 libvmime-zarafa7-0 libvmime-zarafa7-dev libzarafa-archiver-core0 libzarafa-archiver0 libzarafa-server0 libzarafa-soapclient0 libzarafa-soapserver0 libzarafasync0 libzcp-common-mapi0 php5-mapi python-mapi python-zarafa zarafa-backup-plus zarafa-bash-completion zarafa-client zarafa-common zarafa-contacts zarafa-dagent zarafa-dbg zarafa-dev zarafa-gateway zarafa-gsoap zarafa-gsoap-doc zarafa-ical zarafa-lang zarafa-libarchiver zarafa-libgoogle-perftools-dev zarafa-libgoogle-perftools4 zarafa-libgsoap-dev zarafa-libgsoap5 zarafa-libical-dev zarafa-libical1 zarafa-libmapi zarafa-libvmime-dev zarafa-libvmime0 zarafa-monitor zarafa-presence zarafa-search-plus zarafa-server zarafa-spooler zarafa-utils zarafa-webaccess zarafa-webapp zarafa-webapp-browsercompatibility zarafa-webapp-clockwidget zarafa-webapp-contactfax zarafa-webapp-desktopnotifications zarafa-webapp-extbox zarafa-webapp-files zarafa-webapp-folderwidgets zarafa-webapp-gmaps zarafa-webapp-oauthlib zarafa-webapp-pdfbox zarafa-webapp-pimfolder zarafa-webapp-plugins-delayeddelivery zarafa-webapp-plugins-filepreviewer zarafa-webapp-plugins-spell zarafa-webapp-plugins-spell-de-at zarafa-webapp-plugins-spell-de-ch zarafa-webapp-plugins-spell-de-de zarafa-webapp-plugins-spell-en zarafa-webapp-plugins-spell-en-gb zarafa-webapp-plugins-spell-es zarafa-webapp-plugins-spell-fr zarafa-webapp-plugins-spell-nl zarafa-webapp-quickitems zarafa-webapp-titlecounter zarafa-webapp-webappmanual zarafa-webapp-xmpp zarafa-webapp-zdeveloper
ここで再起動してみる。どうやら、問題なさそう。
(3) Kopanoのインストール
その前に、パッケージが何者なのかを調べないと、何をインストールすべきなのかわからないよ。コミュニティエディションだから仕方がないんですね、きっと。
アルファベット順
| adextension | よくわからない。ソースだけ提供されている |
| core | Kopano全体の基盤 |
| deskapp | ブラウザだけでは実現できない便利さの提供(既定のメール等) |
| files | ファイル共有ができるようになる |
| mdm | モバイルでアクセスができるようになる |
| olextension | MicrosoftOutlookと連携できるようになる |
| smime | 電子メールのセキュリティを向上する暗号化、電子署名 |
| webapp | ブラウザでアクセスするユーザー向け画面 |
| webmeetings | ビデオ会議ができるようになる |
多分、こんな感じ。
core, webapp をインストールすることにした。
mdm, files, webmeeting には興味があるが、まずは、従来の機能を優先する。
余談だが、UbuntuではD-pushというパッケージがある。これは、Zarafaで利用してきたZ-pushをDebian用にrebrandしたものらしい。もしかしたらこれでも行けるのかもだが、今回はZ-pushを踏襲。
パッケージのダウンロード。
https://download.kopano.io/community/
に各パッケージが格納されている。
※毎日パッケージングされているようなので、その日によってダウンロードできるファイルが変わる。
この日のバージョンだと、以下だった。
$ wget https://download.kopano.io/community/core:/core-8.4.0~383_89.1-Ubuntu_16.04-amd64.tar.gz $ wget https://download.kopano.io/community/webapp:/webapp-3.3.0.620_439-Ubuntu_16.04-all.tar.gz
※後から色々なものを追加しようとした時、バージョン問題を起こすのも面倒なので、全てのパッケージを落としておくと良いかもしれない。
それぞれ展開。
$ tar -zxvf core-8.4.0~383_89.1-Ubuntu_16.04-amd64.tar.gz $ tar -zxvf webapp-3.3.0.620_439-Ubuntu_16.04-all.tar.gz
やり過ぎの可能性はあるが、以下を実行。Zarafaの最後もこうしたし、いいかー、と。
core展開後のdir$ sudo dpkg -i *.deb
結果、依存関係の問題でインストールはできなかった。
不足分を補うには、以下を実行。
$ sudo apt install libical1a libicu-dev xapian-tools icu-devtools libjs-backbone libjs-underscore libjs-sphinxdoc libunicode-string-perl libreadonly-perl libio-tee-perl libmail-imapclient-perl libparse-recdescent-perl python-flask python-sleekxmpp mktemp xsltproc catdoc python-dateutil python-itsdangerous python-jinja2 python-werkzeug python-markupsafe
先程失敗したインストールができた。
次。
webapp展開後のdir$ sudo dpkg -i *.deb
これも依存関係で失敗。
不足分を補うには、以下を実行。
sudo apt install php-gettext php-zip php7.0-zip libzip4
念には念を入れて。
$ sudo apt update; sudo apt dist-upgrade
何か残っていたらしく、これでスッキリ。
(4) Kopanoの設定
設定はZarafaからコピーして、実行ユーザーをKopanoに変えればOKよ、って書かれているのだが、ただ移行するだけじゃなく、その後、OSが変わったらパッケージ入れ直しなんだろうなーとか考えると、ここできれいにしておくのがイイんじゃないかと思ったりして。
過去、Zarafaをインストールした際に作ったユーザーとかデーターベースとかを整理すると…
■Ubuntu ユーザー vmail を作り、postfix, mysql, www-data が作られる。 ■mysql ユーザー postmaster を作る。 データベース zarafa が作られる。
ってな具合。
ユーザとグループを調べてみる。
$ getent passwd … zarafa:x:999:999:Zarafa Groupware Suite:/dev/null:/bin/false … kopano:x:998:998:Kopano Groupware Suite:/dev/null:/bin/false $ getent group … zarafa:x:999: … kopano:x:998:
ってな具合。
データベースを調べてみる。
> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | openmeetings | | performance_schema | | sys | | test | | wordpress | | zarafa | +--------------------+ 8 rows in set (0.02 sec) > select host, user from mysql.user; +-----------+------------------+ | host | user | +-----------+------------------+ | 127.0.0.1 | root | | ::1 | root | | localhost | | | localhost | debian-sys-maint | | localhost | mysql.sys | | localhost | openmeetings | | localhost | postmaster | | localhost | root | | localhost | wordpress | | hogeserve | | | hogeserve | root | +-----------+------------------+ 11 rows in set (0.00 sec)
いろんなものが同居してるわー。
で、恐らくユーザーvmailはzarafaに置き換えなければならなかったんだと思う。Ubuntu12時点でに参考にしたサイトでvmailを作って使いまわすことを教えてくれていて、その後にUbuntu14にあげたときにzarafaユーザーが追加されたのに、若干色々適当にしていた結果が今と思われる。
ということで、
■Ubuntu ユーザー vmail,zarafaを削除してkopanoに移行。 ユーザー postfix, mysql, www-dataはそのまま流用。 → kopano, postfix, mysql, www-dataの構成。 ■mysql ユーザー postmaster はそのまま流用 データベース zarafaはkopanoに移行。 → リネームはできないらしいので、dumpしてkopanoにデータを流し込む。
を方針として進める。
さて、インストール後のファイルのうち、以下を修正しておく。
/etc/kopano/ical.cfg
#server_timezone = Europe/Amsterdam server_timezone = Asia/Tokyo
/etc/kopano/server.cfg
#system_email_address = postmaster@localhost system_email_address = webmasnter@hogeserver.hogeddns.jp #mysql_user = root mysql_user = postmaster #mysql_password = mysql_password = ********** ←postmasterのパスワード
移行資料によると、添付ファイルは
mv /var/lib/zarafa/attachments/* /var/lib/kopano/attachments/
とのことなので、このディレクトリについては移動してオーナをkopanoに変更する。
$ sudo mv /var/lib/zarafa/attachments/* /var/lib/kopano/attachments/ $ sudo chown -R kopano:kopano /var/lib/kopano/attachments
としておけば良さそう。
データベースをzarafaからkopanoに変える。これは、バックアップにもなるので良い！
参考 データベース名を変更するには
$ mysqldump -u postmaster -p zarafa > zarafa.sql Enter password:[postmasterのパスワード][Enter]
これで、データベースのバックアップが取れた。
後は、kopanoのデータベースを作って、データを流し込む。
$ mysql -u root -p Enter password:[rootのパスワード][Enter] Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 31 Server version: 5.7.18-0ubuntu0.16.04.1 (Ubuntu) Copyright (c) 2000, 2017, 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> create database kopano default character set 'utf8'; Query OK, 1 row affected (0.00 sec) mysql> grant all privileges on kopano.* to postmaster@localhost identified by '[postmasterのパスワード]' with grant option; Query OK, 0 rows affected, 1 warning (0.00 sec) mysql> quit Bye $ mysql -u postmaster -p kopano < zarafa.sql Enter password:[postmasterのパスワード][Enter]
で、MAPIにzarafa設定が残っているので、一旦退避(後で削除)。
$ sudo mv /etc/mapi/zarafa.inf /etc/mapi/zarafa.inf.bak
(5) Z-pushの設定
Z-pushの設定を更新する。今までの設定でも、とりあえずZ-pushは動き始めるのだが、kopano backendが上手く動作しない…と思ったら中身がない。
よくよく見ると、リポジトリが無効化されていた…追加。
/etc/apt/sources.list
# deb http://repo.z-hub.io/z-push:/final/Ubuntu_14.04/ / # xenialへのアップグレード時に無効化されました
# deb-src http://repo.z-hub.io/z-push:/final/Ubuntu_14.04 trusty main
deb http://repo.z-hub.io/z-push:/final/Ubuntu_16.04/ /
追加したら、データベース？をアップデートし、Z-pushをアップグレードする。
$ sudo apt update ・ ・ ・ アップグレードできるパッケージが 4 個あります。表示するには 'apt list --upgradable' を実行してください。 $ apt list --upgradable 一覧表示... 完了 login/xenial-updates,xenial-security 1:4.2-3.1ubuntu5.2 amd64 [1:4.2-3.1ubuntu5 からアップグレード可] passwd/xenial-updates,xenial-security 1:4.2-3.1ubuntu5.2 amd64 [1:4.2-3.1ubuntu5 からアップグレード可] z-push-common/stable 2.3.6+0 all [2.3.6+0 からアップグレード可] z-push-config-apache/stable 2.3.6+0 all [2.3.6+0 からアップグレード可] $ sudo apt dist-upgrade ・ ・ ・ z-push-common (2.3.6+0) を設定しています ... PHP Notice: Constant MAPI_SERVER already defined in /etc/z-push/z-push.conf.php on line 27 PHP Notice: Constant MAPI_SERVER already defined in /etc/z-push/z-push.conf.php on line 28 Validating and fixing states (this can take some time): Checking username casings: FatalMisconfigurationException: No Backend provider can be found. Check your installation and/or configuration! -e When upgrading from an earlier version you need to run 'z-push-admin -a fixstates'. It seems the execution on setup has failed (see error above). Please fix the issue and run the command manually. More information at https://wiki.z-hub.io/x/R4Ea ・ ・
ってことで、アップグレードできた。
あとはバックエンドをインストール。
$ sudo apt install z-push-backend-kopano
$ sudo apt install z-push-ipc-sharedmemory ←2017/9/18追記(物凄くエラーが出るのを回避)
これで動き出した。
(6) Postfixの設定修正
メールをやり取りするのでpostfixの設定も修正する必要がある。
/etc/postfix/main.cf
# # for Zarafa Settings. # #virtual_alias_maps = mysql:/etc/postfix/mysql-aliases.cf #mailbox_transport = zarafa: zarafa_destination_recipient_limit = 1 #mailbox_command = /usr/sbin/zarafa-dagent "$USER" #debugger_command = # PATH=/bin:/usr/bin:/usr/local/bin:/usr/bin/X11 # ddd $daemon_directory/$process_name $process_id & sleep 5 … # # for Kopano Settings. # virtual_alias_maps = mysql:/etc/postfix/mysql-aliases.cf mailbox_transport = kopano: kopano_destination_recipient_limit = 1 mailbox_command = /usr/sbin/kopano-dagent "$USER" debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/bin/X11 ddd $daemon_directory/$process_name $process_id & sleep 5 …
/etc/postfix/master.cf
… # # for Zarafa Settings # #zarafa unix - n n - 10 pipe # flags=DRhu user=vmail argv=/usr/sbin/zarafa-dagent -R ${recipient} # # for Kopano Settings # kopano unix - n n - 10 pipe flags=DRhu user=kopano argv=/usr/sbin/kopano-dagent -R ${recipient} …
/etc/postfix/mysql-aliases.cf
# The user name and password to log into the mysql server. user = postmaster password = [postmasterのパスワード] hosts = 127.0.0.1 #dbname = zarafa dbname = kopano …
(7) 再起動して動作確認
ここで再起動してみて、動作を確認してみる。
問題なくWebappでアクセスでき、メールの送受信ができて、ActiveSyncでもエラー表示なし。
OK！
(8) ゴミ掃除
全部じゃないけど、影響しそうなファイルは削除。
$ sudo rm /etc/init.d/zarafa-* $ sudo rm /etc/rc0.d/*zarafa* $ sudo rm /etc/rc1.d/*zarafa* $ sudo rm /etc/rc2.d/*zarafa* $ sudo rm /etc/rc3.d/*zarafa* $ sudo rm /etc/rc4.d/*zarafa* $ sudo rm /etc/rc5.d/*zarafa* $ sudo rm /etc/rc6.d/*zarafa* #$ sudo rm /etc/rcS.d/*zarafa* ← ここにはなかった。 $ sudo rm -rf /etc/zarafa $ sudo rm -rf /etc/zarafa.bak $ sudo rm /etc/mapi/zarafa* $ sudo rm /etc/default/zarafa* $ sudo rm /etc/apache2/sites-available/zarafa-* $ sudo rm -rf //usr/share/zarafa-webapp $ sudo rm -rf /var/lib/zarafa* $ sudo rm -rf /var/log/zarafa
こんなもんでよろしいかと。
使わなくなったユーザーも削除。
$ sudo userdel vmail $ sudo userdel zarafa #$ sudo groupdel zarafa ← ユーザーを消した時点で消えていた
データベースを削除。
$ mysql -u root -p Enter password:[rootのパスワード][Enter] Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 26 Server version: 5.7.18-0ubuntu0.16.04.1 (Ubuntu) Copyright (c) 2000, 2017, 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> drop database zarafa; Query OK, 26 rows affected (0.34 sec) mysql> quit Bye
この後再起動して各機能を動かしてみて、問題がなければOK。
ありそうな問題としては、
・webappにアクセスできない
・メールが送れない
・メールが届かない
・メールにファイルが添付できない
・メールのプッシュ通知がされない
・スケジュールのプッシュ通知がされない
なので、これらをテストすればOKかと思う。
以上で設定ができた。手順は確立できた。
余談だが、GUIでログインする度に「エラーが発生」「エラーが発生」とダイアログが出ていたのだが、これらのゴミ掃除を行った結果、全く表示がされなくなった。
ゴミが残っているために発生しているエラーについてレポートしてたら迷惑をかけてたなーと思い、気軽にレポートしなくて良かったと思ったのだった。
■本番環境への適用
・システムが止まることの通知する。
・スナップショットを取る。
・確立した手順で作業を実施する→オリジナリティ不要、全く同じ環境でやったんだから。
・テストする。
・システムが復旧したことを通知する。
・スナップショットを統合する。
アップグレード後に発生している問題。
- WordPressのテーマ・プラグインの更新がダッシュボードからできない
- NetworkManagerが使えない。
- sudo service samba restart ができない。
(1) WordPressのテーマ・プラグインの更新がダッシュボードからできない
※パーミッションだけを変えて解決しようとすると、プラグインやテーマの更新でそれらが消える問題が発生するので、注意深く作業する必要がある。
テーマ・プラグインが更新できないだけでなく、WordPress自体のバージョンアップもできない。
最初にインストールしたとき、Ubuntuパッケージからのインストールを選んだわけだが、恐らくそれが影響してパッケージ更新がなされたものと思われる。
パッケージ管理から離脱し、WordPressの自動更新に委ねてみよう。
まずは、サービスを止めて必要ファイルのバックアップ。
$ sudo service apache2 stop $ sudo cp -a /usr/share/wordpress/wp-config.php /usr/share/wordpress/wp-config.php.org
このファイルはなければ作られるのだが、色々な仕掛け、例えば、MySQLユーザー・パスワードは/etc/wordpress配下のファイルを参照するように作られているのでとっておきたい。セキュリティ的に安全なのかどうかは今後の確認。
パッケージの削除。
$ sudo apt remove wordpress wordpress-theme-twentysixteen $ sudo apt autoremove
バージョンは4.4.2だったので、4.4.2をダウンロードする。
ダウンロード先はここ。
$ wget https://wordpress.org/wordpress-4.4.2.tar.gz
ファイルを展開して、今まで入っていた場所に収め、持ち主を変える。
$ tar -zxvf wordpress-4.4.2.tar.gz $ sudo cp -ar wordpress /usr/share/ $ sudo chown -R www-data:www-data /usr/share/wordpress/
設定ファイルを戻す。
$ sudo mv /usr/share/wordpress/wp-config.php.org /usr/share/wordpress/wp-config.php $ sudo ln -s /etc/wordpress/htaccess /usr/share/wordpress/.htaccess
投稿したデータ達を移動する。
sudo mv /var/lib/wordpress/wp-content/blogs.dir /usr/share/wordpress/wp-content
さらに、ちょっと設定を変える。
/etc/wordpress/config-hogeserver.hogeddns.jp.php ← サイト用config
#This will disable the update notification. #define('WP_CORE_UPDATE', false); ←コメントアウト define('DONT_SET_WP_CONTENT_DIR', true); ←追加 define('WPLANG', 'ja'); ←追加
アップデート表示が無効化されているのを止めて、Ubuntu用に変更設定されるディレクトリ設定を止める。オリジナリティを消す感じ。
※この設定を漏らした結果、サイトが全て英語になる事態に遭遇。その場合は、/var/lib/wordpress/wp-content配下のblogs.dir以外をコピーする感じだと思う。今回はHDDイメージのバックアップを戻して対応したので、詳細は不明。
今までの作業で削除されたmysql extentionをインストール。
$ sudo apt install php7.0-mysql
サービスを開始して、ブログにアクセスしてみる。
$ sudo service apache2 start
(2) NetworkManagerが使えない。
これは、色々とやってみたけど、結果的に起動順序の問題？なのか、各種サービスがエラーを起こしまくるので諦めた。
(3) sudo service samba restart ができない。
$ sudo service samba restart Faild to restart samba.service: Unit samba.service is masked.
となる。
Ubuntuは6.10からUpstartというinitデーモンを採用、起動時間が大幅に高速化した。ただ、DebianがSystemdというデーモンの採用を決定したので、15.04から移行を開始した模様。
処理単位をUpstartではjob、Systemdではunitと呼ぶそうな。
※参考:第358回 Upstart Jobをsystemd Unitに変換する
今までのとおりに使えたら…と思ったけど、手間がかかりそうなので、以下でどうにか。
$ sudo service smbd restart $ sudo service nmbd restart
■やったことメモ1 ESXi上のシンプロビジョニングディスクのサイズは小さくできない
フルサイズのバックアップには物凄く時間がかかるので、サイズを小さくしてからやりたい。
そう思って、ディスクをシンプロビジョニングタイプに変更したが、結局サイズは小さくならなかった…。
まず、ディスクをシック→シンに変換。シックプロビジョニングで作成したvmdkを変換する に手順がきっちり書かれているので、これを実行。
(1)ESXiのSSHを有効化。
(2)運用中のシステム停止。
・vmkfstools でシック→シン変換。
・運用中のシステムのディスク差し替え。
・元ディスクの削除。
(3)運用中のシステム起動。
・新ディスクの空き領域に0書き込み→削除。
(4)運用中のシステム停止。
・ディスク縮小
を行う。(1)～(2)は以下。
参照元 雑木林
# vmkfstools -i 変換元VMDKファイル.vmdk -d thin 変換先VMDKファイル.vmdk
変換元のvmdkは-flat.vmdkファイルではなく、.vmdkファイルを指定する点に注意。
これで、シンプロビジョニングに変換ができた。
起動して問題なくシステムが稼働したことを確認したら、元のディスクを削除する。データストアブラウザだと上手く消せないみたいなので、ESXiにsshで接続して削除する。
(3)は以下。
起動したシステムにsshで接続し、不要領域に0を書き込んでシステムを停止。
参照元 ESXi5でシンプロビジョニングされた仮想ディスクを圧縮する
$ dd if=/dev/zero of=./zerofile bs=4k; rm -f ./zerofile
これは容量が大きければ大きいほど時間がかかる…。
最後にディスク領域を圧縮すれば、最低限のサイズに圧縮ができる。
ESXiにsshで接続して以下を実行。
※参照 同
# vmkfstools -K 変換先VMDKファイル.vmdk
結論としては、これらの操作を行っても、見た目のサイズは小さくならなかったので、vCenter Converter Standalone を使ってバックアップを取った。
■やったことメモ2 hostsとか使わないで同居させようとしたけど無理だった
基本的には、そのまま叩くだけでいいのだけれど、IPアドレスを変えたくない。
ということで、以下を参考にVMwareの設定変更に挑戦。
VMware Player上のLinux (NAT + 固定IPアドレス)
VMware Workstationをインストールすると、ネットワークアダプタ2つが見える。
・VMware Network Adapter VMnet1 ← 変更不要
・VMware Network Adapter VMnet8 ← これを変更
片方だけを修正すれば良かったのだが、2つとも手を入れてちょっとトラブった。
結果として、設定自体は上手く行って動作した。
これで Ubuntu14 から Ubuntu16 へのバージョンアップはできた。
できたにはできたんだが、Ubuntu16を起動した後、上手く動かなくなった。どうやらNAT配下に同じネットワークを作ると、パケットの戻し先がわからなくなるみたい。
同居は諦めて hosts で解決することにした。
ここにも詳しい情報があった。
ソフトウェアエンジニアリング 調査 #52
※後から色々やってみて、NetworkManagerが悪さをしていた可能性あり。VMware Workstationの設定を変えたい場合のメモとして利用する程度とする。
■やったことメモ3 UbuntuのWordPressパッケージを活かしつつ、は無理っぽい。
WordPressを最初にインストールしたときにUbuntuのパッケージを利用したが、これが今回のOSバージョンアップに影響したようだ。
以前、パーミッションを全部変えればなんとかなる、的ないい加減な作業を実施してしまった。目先の更新はできるようになったが、セキュリティ的には問題があったのかもしれない。
locateコマンドで調べてみたところ、大きくは以下にファイルがあった。
所有者は過去に変更した記憶がある。特に、/usr/share/wordpress。
/etc/wordpress
htaccess, wp-config.php(link), config-hogeserver.hogeddns.jp.phpがあった。
基本はrootの持ち物で、一部www-dataにアクセス権がある。直接は関係なさそう。
/usr/share/wordpress
メインのディレクトリで、全てwww-dataの持ち物になっていた。
/var/lib/wordpress
wp-contentがあり、配下にblogs.dir, languages, plugins, themes, uploadsがあった。
www-dataの持ち物。
blogs.dirにはメディアファイルが入っている。
languagesには/usr/share/wordpress/wp-content/languagesへのリンクが入っていた。
pluginsには/usr/share/wordpress/wp-content/pluginsへのリンクが入っていた。
themesには/usr/share/wordpress/wp-content/themesへのリンクが入っていた。
uploadsは空っぽだった。
また、導入されたパッケージは以下の通りだった。
wordpress
/usr/share/wordpress配下にメインでファイルを入れている。
/var/lib/wordpress配下にもファイルを入れている。
wordpress-l10n
/usr/share/wordpress/wp-content/languages配下にファイルを入れている。
wordpress-theme-twentyfourteen
wordpress-theme-twentytwelve
/usr/share/wordpress/wp-content/themes配下にテーマを入れている。
ということで、記憶に沿ってディレクトリとファイルの持ち主を変えてみることに。
$ sudo chown -R www-data:www-data wordpress
これで試してみたけれど…
更新プロセスを開始しています。サーバーによっては少し時間がかかるかもしれません。しばらくお待ちください。
メンテナンスモードを有効にします…
プラグインの更新: Akismet (1/1)
https://downloads.wordpress.org/plugin/akismet.3.3.1.zip から更新をダウンロードしています…
更新を展開しています…
最新のバージョンをインストールしています…
プラグインの古いバージョンを削除しています…
プラグインの更新に失敗しました。
An error occurred while updating Akismet: 古いプラグインを削除できませんでした。
メンテナンスモードを無効にします…
すべての更新が完了しました。
これの酷いのは、更新したプラグインやテーマのファイルが全て消えてしまい、リストにも表示されなくなること。これじゃダメだ、ということで上に書いた方法にて対応したのだった。
WordPressは情報発信するツールだからか情報はたくさん出ているけれども、今回のようなイレギュラーなことをやろうと思ったら、中身をしっかり見ないとダメ。
■やったことメモ4 ServerでNetworkManagerを使うのはダメかも
いままでずっとNetworkManagerを使ってきたのだけれども、どうやら起動順序？の問題なのか、色々な問題を引き起こす。クライアントとして使うなら良いが、サーバーとして使うならNetworkManagerを使うのはダメっぽい。
やったことは以下。
設定を完全に削除してみる。
$ sudo apt purge network-manager $ sudo rm -rf /etc/NetworkManager
その上で、もう一度インストールをしてみる。
$ sudo apt install network-manager
途中でこんなメッセージが。
The following network interfaces were found in /etc/network/interfaces which means they are currently configured by ifupdown: - eth0 - eth0:1 If you want to manage those interfaces with NetworkManager instead remove their configuration from /etc/network/interfaces.
言われたとおり、eth0とeth0:1をコメントアウトして潰す。
# interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback #auto eth0 #iface eth0 inet static #address 192.168.NNN.NNN #netmask 255.255.255.0 #gateway 192.168.NNN.1 #dns-nameservers 127.0.0.1 #auto eth0:1 #iface eth0:1 inet static #address 192.168.NNN.NN2 #netmask 255.255.255.0
再起動。
$ sudo reboot
これでGUIログインすると、DHCPからアドレスが割り振られる。
固定IPにしたいので、GUIから固定のIPアドレスを設定。
GUIでネットワークを無効→有効と切り替えて接続を確認する。
一瞬上手く行ったような気がしたが、結局、各種サービスがエラーを起こしたりするし、bind9が働くなったりと問題起きまくり。
実際の格闘時間は8時間+4時間=12時間である。
こんな目に合うくらいなら、使わないほうが良い。
所感
ZarafaからKopanoへの移行をするだけでも調べることはいっぱいあった。
それなのに、一緒にUbuntu14までUbuntu16までアップグレードしてしまった。
ゴールデンウィークだし、時間あるし、と思い切り頑張ってみた結果、ゴールデンウィークを使い果たしてしまった。
しかし得られたものも大きい。
- ようやくUbuntu16にアップグレードができた。
- Kopanoへの移行ができた。気になっていたWeb会議も試せそう。
- WordPressでよくわからなかった諸々が分かった(気がする)。
- パッケージの扱いが少しわかった気がする。
- sudo service samba restartが使えなくなった背景がわかった。
前回書いた「会社で作る認証局」の記事とこれらのノウハウで、当面は社内のサーバーを運用できそうだ。
コメントはこちらから お気軽にどうぞ ～ 投稿に関するご意見・感想・他