会社のファイル共有にNextcloudを採用しました。
その際にハマってしまったところのメモ。
ちなみに環境はConohaWINGで、Webinstallerで構築したケースであれば同じ症状が出て同じ方法で解決できるのではないかと思います。
なお、バージョンはNC20です。
※(2022/09/28追記) 現時点でConohaWINGのMySQLのバージョンは5.7なのでNC21以降の運用は出来ないのでNextcloudを使うのには向かないと思います。
トラブル
クライアントから最初にアクセスする際にアクセス許可で止まる
原因はプロトコルがhttpではなくhttpsだったことだったようです。
config/config.phpの
'overwriteprotocol' => 'HTTP',を'HTTPS'に書き換えることで解決。
消せないフォルダが発生してしまった
ファイルロックの解除がうまくいかなかった事によるトラブルのようです。
https://piano2nd.smb.net/PukiWiki/index.php?nextcloud%20file%20unlock
こちらを参考にConohaの管理画面からphpMyAdminで直接DBをいじって対応。
oc_file_locksのレコード全削除で問題のフォルダの削除に成功。
バージョンアップ作業中メンテナンスモードが終わらない
ブラウザでバージョンアップの作業を行っている際うっかりメンテナンスモードを終えるか？の選択を間違えて抜けられなくなった。
config/config.phpの
'maintenance' => true,をfalseに書き換えて手動でメンテナンスモードを終了。
安易にHSHTを有効にするとサイトが死ぬ
"Strict-Transport-Security" HTTPヘッダが最低でも "15552000" 秒に設定されていません。セキュリティを強化するには、キュリティTips ↗で解説しているHSTSを有効にすることを推奨します。
これに対処しようとして下手にincludeSubDomainsオプションを含めてHSHTを有効にするとhttpsに対応していないサブドメインまで強制的にhttpsにリダイレクトされてサイトが事実上死にます。
別のサーバで運用してるサブドメインのサイトで影響が出たので原因が掴めずに詰むところだったかも。
きちんとオプションを確認した上で.htaccessを設定すれば間違いないかと思います。
ついでなんで全サイトhttps対応しましたが。
Header always set Strict-Transport-Security "max-age=15552000;"
WebDAVインターフェースが動作していないようです。Webサーバーは、ファイルの同期を許可するよう適切に設定されていません。
運用7か月目にして突如として発生したエラー。
ConohaのWAFに弾かれてました。
Conohaの管理画面からサイト管理>サイトセキュリティ>WAFで
攻撃内容:WebDAVなどで利用するメソッドの拒否（PUT、COPY、MOVE、...）
とあるのを除外することで解決。
※2021/02/28 追記
DBのインデックスの追加と変換
データベースにいくつかのインデックスがありません。 大きなテーブルにインデックスを追加すると、自動的に追加されないまでに時間がかかる可能性があるためです。 "occ db：add-missing-indices"を実行することによって、インスタンスが実行し続けている間にそれらの欠けているインデックスを手動で追加することができます。 インデックスが追加されると、それらのテーブルへのクエリは通常はるかに速くなります。
テーブル "oc_cards"のインデックス "cards_abiduri"が見つかりません。
データベース内のいくつかの列で、big intへの変換が行われていません。 大きなテーブルでカラムタイプを変更すると時間がかかることがあるため、自動的には変更されませんでした。 'occ db：convert-filecache-bigint'を実行することによって、それらの保留中の変更は手動で適用できます。 この操作は、インスタンスがオフラインの間に行う必要があります。 詳細についてはこれに関するドキュメントページを読んでください。
federated_reshares.share_id
share_external.id
share_external.parent
こんな2つの警告が出現。
放置しても害はなさそうではありますが気になるのでSSHで接続して下記のコマンドを実行。
後者はメンテナンスモードで実行しろとのことなのでconfig.phpをいじってそのようにする。
この状態ならコマンド打った方がスマートかな。終わったら--offで。
php occ maintenance:mode --on
当然人によってフォルダの構造は違うので自分と同レベルの人向きに書いておくとlsとcdでoccのあるフォルダまで掘って実行するのが手堅いと思う。
php occ db:add-missing-indices
php occ db:convert-filecache-bigint
尚、Conoha WingにSSH接続する際にはこちらのサイトが大変参考になりました。
※2021/02/08追記
反省
最初からAWS S3使わないと利便性が死ぬ
最初は余ってるレンタルサーバの容量を使って足りなくなったら外部ストレージでS3使えばいいや。そんな風に考えていた時期が私にもありました。
ところが外部ストレージの利便性の低さよ。個別に共有設定などができません。
結果プライマリストレージをS3に切り替える大工事になります。
運用期間が短かったこともあり想定外の面倒を避けるため最初から作り直しました。
これが一番致命的だった。
レンタルサーバの方を外部ストレージとして使った方が良さそう。
フォルダ名はデフォルトのnextcloudを避ける
初期値でクローリングしてる人らはいると思うので。
何かしらの脆弱性が見つかった時に即攻撃候補にされるよりはマシかなと。
Group foldersプラグインはやめといた方が
一目で誰が共有してるのか共有フォルダより分かりづらいので。
同期も妙に遅くなります。
それにファイルをグループフォルダ間で移動するとインデックス書き換えではなく普通にコピーしてるようでやたらと時間がかかります。
管理者か共有フォルダ担当アカウントが普通に共有フォルダ作った方が良いかと。
2年運用しての反省
長く使わないとわからない事もある。
というか長く使ってる間に起きた事なのでどうしようもない話でもある。
