毎度、ググっても出てこない小ネタを取り扱っております。
本記事は個人的な見解であり、筆者の所属するいかなる団体にも関係ございません。
0. はじめに
Nextcloudをインストールする方法はいくつかありますが、一番簡単なのがsnap でインストールする方法です。
どれぐらい簡単かというと、snapがインストールされていれば、以下のコマンド1行でNextcloudが動きます。
snap install nextcloud
このコマンドで、apache,nextcloud,mysqlがインストールされて利用できるようになります。
2018年6月から2年ぐらい会社の本番環境で運用してみたので、snap のNextcloudのメリットとデメリット(Pros , Cons)をまとめてみたいと思います。
1. メリット(Pros)
1-1. アップデートが楽
一番のメリットは、アップデートが楽ということでしょうか。
アップデートを勝手にやってくれます。メジャーバージョンアップも含むので、いつの間にかUIが変わっていたりしますが、まあ、そこは常に新しいバージョンを使えるメリットでもありますし、ご愛敬です。
アップデートが自動的に適用されるので、セキュリティー脆弱性の心配を減らせます。
PHPもsnapに同梱されているのでPHPもいつの間にかバージョンアップされていて結局運用中1回もコンソールでアップデート作業をすることはありませんでした。
大きな障害もなく、普通に利用することができました。
利用上でも、通常のサーバーにNextcloudをインストールしたのと同じ使い勝手で、プラグインも入れられますし、データが破損することもありませんでした。
AWS上で動かしていたのですが、t2.largeで快適に利用できました。
2. デメリット(Cons)
上記のメリットのように基本的に問題はなかったのですが、会社として利用する場合にはいくつかの課題がありました。それをあげていきたいと思います。
2-1. ログファイルの保存場所
企業で使う時には、ファイルの操作履歴の保存はとても重要な課題です。
特に外部に出ているサービスであれば、ファイルの漏えいやファイルのダウンロードで、誰がどこからダウンロードしたかとか、履歴を保存しておくのは重要なことです。
通常のNextcloudであれば、ログファイルの場所を変更するコマンドは、以下のようにすればよく、パーミッションがあればどこにでも保存可能です。
occ log:file --file=/var/log/nextcloud/nextcloud.log
残念ながら、snapではこれができませんでした。
snapは、独自のファイル境界設定で通常のファイル操作権限とは分離されており、snapで動いているアプリはどこにでも書き込むということはできないようです。
また、Apacheのログファイルも同様で、/snap/nextcloud/current/conf/httpd.confに設定が書いてあるのですが、この設定は読み取り専用(変更しても新しいバージョンで上書きされる)で変更ができませんでした。
ErrorLog "${SNAP_DATA}/logs/apache_errors.log"
CustomLog "${SNAP_DATA}/logs/apache_access.log" combined
上記ファイルは、snapのデフォルトでは、/var/snap/nextcloud/current/logs/に保存されます。
2-2. Snapによる独自コマンド体系
もう一つ困ったことは、snap独特のコマンド体系です。
アプリケーションの再起動では、以下のようなコマンドを利用します。
sudo systemctl restart snap.nextcloud.php-fpm.service
sudo systemctl restart snap.nextcloud.apache.service
これはsnap配下で管理されているので当然と言えば当然で、これをもってsnapが悪いというつもりは毛頭ありませんが、時々操作をしようとすると「えーと、なんだっけ？」となることもあり、頻繁に使うのであれば慣れてくるのだと思いますが、ほとんどメンテナンスが不要なこともあり慣れる時間がありませんでした。
その他以下のようなサービスコマンドがあります。
snap.nextcloud.apache.service
snap.nextcloud.logrotate.service
snap.nextcloud.logrotate.timer
snap.nextcloud.mdns-publisher.service
snap.nextcloud.mysql.service
snap.nextcloud.nextcloud-cron.service
snap.nextcloud.nextcloud-fixer.service
snap.nextcloud.php-fpm.service
snap.nextcloud.redis-server.service
snap.nextcloud.renew-certs.service
2-3. Nextcloudのデータディレクトリの場所が限定される
ログのところでsnapは独自の権限分離を行っていると書きましたが、これはNextcloudデータディレクトリでも同様です。
Nextcloudはオンラインストレージですので、それぞれのユーザーからアップロードされたファイルを格納する場所があります。これをNextcloudのdatadirectoryという項目で設定しますが、/media/配下にしか指定することができません。
/mediaにブロックデバイスをマウントすれば良いだけの話なので、大きな問題ではありませんが、要注意ポイントです。
2-4. 独自ディレクトリ構造
こちらも、snapならではという感じですので、snapが悪いというよりも慣れてないということになるかと思います。
snapのディレクトリは、以下の3つに分かれます。
| ディレクトリ名 | 詳細 | バージョンによって書き換わるか |
|---|---|---|
| /snap/nextcloud | Nextcloud本体とconfig、各種ユーティリティ | 書き換わる |
| /var/snap/nextcloud/current/ | Nextcloudに関連する変更があるデータや設定ファイルやログファイル | 維持される |
| /var/snap/nextcloud/common/ | Nextcloudのユーザーファイルとappdataやテーマ、プレビューやサムネールファイル | 書き換わらない |
これも、慣れてしまえばそういうものなのでどうということもないのだと思いますが...。
3. まとめ
機能面に不満はなかったのですが、便利であるがゆえに色々と手を加えようとした時に対応方法が限られるという面と慣れが必要だったという点で、通常のインストールベースのNextcloudへ戻しました。
ほとんどSnapによるNextcloudの問題ではない部分が大きいので、個人で使われる方は問題ない事かと思います。
特にセキュリティーの脆弱性の良く見つかるPHP等のアップデートを勝手にやってもらえる事はセキュリティーの面では非常に大きなメリットですので、Snapを使ったNextcloudは個人的には今後もおすすめいたします。