Xserver で Nextcloud – いくつかの警告に対処

NextCloud icon

Nextcloud を Xserver にインストールして使っていますがセキュリティ&セットアップ警告というものが消えません。いくつか消しました。

Nextcloud をレンタルサーバーの Xserver にインストールして使っています。たまに不調もありつつ、まあまあ快適に使えています。

ただ、そこいらのクラウドサービスと違って自分でインストールした責任上、自分で面倒を見ないといけません。クライアントアプリを更新したり、たまにはサイトに接続してNextcloud をアップデートする必要があります。

忘れたころにWebに接続すると、アップデートがてんこ盛りにありまして、自動更新にも対応できないほどになっていました💦

仕方なく繰り返しアップデート作業を行い、やっとのことで最新版に更新できました。

レンタルサーバーで Nextcloud

Nextcloud について検索を行うと、ほぼすべて自分でサーバー管理を行っている人の情報しかヒットしません。警告やエラーの対処も、いきなり意味不明のコードが書かれていたりします。

そんで、そのコードをどこに書くのさ。と、謎ながらも、そもそも命令文の最初に大抵「sudo」が付いています。sudo というのは管理者権限で行う命令ですから、コードをどこにどう書くか以前に、レンタルサーバーで使用できるわけがありません。

ということで、大抵の謎は解けぬままですから、Nextcloud が吐いてくる警告に対処することを放棄しておりました。

でも極めて希にレンタルサーバーにインストールした人の情報もあります。そうした人を師と仰ぎ、参考にすることでいくつかには対処できました。

メンテナンスが終わらない

さて、Nextcloud 本体の更新作業中に注意することは、途中で出てくる選択肢です。メンテナンスモードにするかしないかを訊かれます。

うっかりメンテナンスモードを選んでしまうと、更新が終わっても解除されず、NexCloudにアクセスできなくなり大層焦ることになります。

まじどうにもならないので、FTPで Nextcloud フォルダにアクセスして、config フォルダ内の config.php を開き、メンテナンスモードを即刻辞めるよう指示を行います。

 'maintenance' => true,

多分こうなったままなので

 'maintenance' => false,

false に書き換えて保存します。

更新作業中にメンテナンスモードにして、更新が終わっても絶対に解除しないという強気の Nextcloud には、このように立ち向かいましょう。

セキュリティ&セットアップ警告

NextCoud のWeb版にログインして訳のわからない画面から多彩な選択を駆使して管理概要を見つけてクリックすると、何やらくるくるとテストを行い、

その後、警告をだーっと出します。

あまりにも多くの警告が出ますが、何のことか判らないので無視していました。でも気持ち悪いのでいくつかは手動で対処しました。対処できたものの記録を取ってないのでここに書けず、その続きですが、それでもまだ警告が山盛りあります。どんだけ警告好きやねん。

big intへの変換

警告「データベース内のいくつかの列で、big intへの変換が行われていません」

「データベース内のいくつかの列で、big intへの変換が行われていません」というこの警告はデータベース絡みです。MySQLデータベースの phpMyAdmin にログインして対処します。phpMyAdminをブックマークしておらずURLもわからない場合はレンタルサーバーの管理パネルから行けます。

Xserver phpMyAdmin
xserverならここ

Xserver では MySQLが現時点で5.7です。Nextcloudのページによりますと、

Nextcloud 21 はMySQL バージョン “5.7.29”をサポートしなくなりました。MySQL 8 もしくはそれ以上のバージョンのものを使用してください。

とのことで、Xserver が今後5.7以上にアップしてくれるのかどうか気になりますが Nextcloud 20.0.8 ではまだ使えます。

「big int への変換」の警告以外に、以前はテーブルかテーブル内の何かがないという警告が沢山ありました。その警告は意味がわかりやすかったので phpMyAdmin から指定通り一個ずつ作成することで対処することが出来ました。

そのとき「big int への変換」警告は意味不明なので放置していましたが、よくよく落ち着いて見るとなんとなく何を言っているのかわかってきました。

上図の例で最初の行に書かれた「federated_reshares.share_id」があります。これ何ですか?さあ何でしょう。多分テーブルではないでしょうか。

oc_federated_reshares
oc_federated_reshares

テーブルを選んでタブから「構造」を選んで表示させると、share_id が見つかります。きっとこれを指していると思います。

share_id
share_id

警告文では「データベース内のいくつかの列で、big intへの変換が行われていません」と書かれていました。big int へ変換したいけどしていないんですって。

share_id の列を見れば右のほうに「変更」ボタンがあります。変換したいんだから変更でしょうよ、ということで何も考えず変更ボタンをクリックすると

変更が選べました。警告文が「big int」と言うのは「BIGINT」のことに相違ない。INT だったものを BIGINT に変更しました。多分でっかくなったんですね。

こんな調子で、警告からテーブルを見つけて該当の列をINTからBIGINTに変更していきます。ほんとにこれで合ってるんだろうか。

Nextcloudのページから再度「概要」を選び直すとまたくるくるとテストを行い、「big int への変換」警告が消えました。合ってました。

リバースプロキシヘッダーの設定

「リバースプロキシヘッダーの設定が正しくないか、信頼できるプロキシからNextcloudにアクセスしています。そうでない場合、これはセキュリティの問題であり、攻撃者はNextcloudに見えるように自分のIPアドレスを偽装することができます」

リバースプロキシヘッダーとやらの設定が正しくないか、あるいは信頼できるアクセスのようです。信頼できるならええやんかと思いますが、国語的に正しくないこの警告を消すにはリバースプロキシヘッダーの設定を正しく行えばいいのだそうです。でもそれどうやんの。

検索して見つけた先生によりますと、config を書けばいいそうです。これならできそうです。コマンドはわかりませんがFTPでフォルダにアクスすれば config フォルダ内に config.php がありますから書き換えます。と、思ったら書き換えるんじゃなくて、書き足します。

‘trusted_proxies’ という項目を作り、サーバーのIPアドレスを入力します。サーバーのIPアドレスを調べ、もしそれが「183.181.82.92」ならこう書きます。

'trusted_proxies' => '183.181.82.92',

これでリバースプロキシの警告は消えました。先生のおっしゃるとおりでした。

先生:https://yoshimemo.com/post-569/

 HTTPヘッダ15552000秒

警告「"Strict-Transport-Security"HTTPヘッダが最低でも"15552000"秒に設定されていません」

オレンジ色の警告は「”Strict-Transport-Security”HTTPヘッダが最低でも”15552000″秒に設定されていません」と告げています。またもや気持ち悪い日本語にイラつきながらも、これも何とか対処できそうなので調べます。だいたいこの手のは php.ini とか .htaccsess とかの絡みであると想像できます。

しかし想像だけでは結局どうにもならず、検索してまわると役に立たない情報砂漠の中にひとつのありがたい解答を発見。あっ。また同じ先生やないか。

先生:https://yoshimemo.com/post-648/

この先生は Xserver に Nextcloud をインストールされている貴重な存在です。

ということで先生の言うとおり .htaccess に以下を追加します。

Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"

バックグラウンドジョブ

エラー「最後のバックグラウンドジョブの実行は1時間前でした。何かが間違っているようです」

警告ではなくて赤いバッテンのエラーです。バックグラウンドジョブが1時間前で何かが間違っていると。この図はわざと作ったもので1時間で済んでいますが最初に見たときは100時間越えていたように思います。

このエラーの対処として「バックグラウンドジョブの設定を確認する」がありますので確認してみます。

設定「Cron」
設定「Cron」

「大規模なインスタンスでは、’Cron’がお薦めの設定です」と書かれているので、「大規模なインスタンス」を見逃した粗忽者が、そうか Cron がオススメなのか。と、Cron を選んでいたようです。エラーが出てるのでこれを AJAXに変更してみましょう。

設定「AJAX」
設定「AJAX」

エラーはなくなりました。

いくつかのプライマリーキーがありません

まだ警告は残っていて、例えば「Keyがないよ」警告です。

警告「The database is missing somu primary keys.」
「primary key がないよ」と言ってるようです

Nextcloudのバージョンが上がって、プライマリーキーの警告も日本語で表示されるようになりました。

「データベースにいくつかのプライマリーキーがありません」警告
データベースにいくつかのプライマリーキーがありません

テーブルも判るしキーがないのも判るんですが、かといってプラマリキーって何なのか判らないし、何を作っていいのかわからないので放置します。いつか判れば作ればいいですね。

— 時が流れて —

と、思っていたんですがプライマリーキーってのが何かというと、固有のレコードを判別するキーのことらしいです。IDとかそういうやつですよね。完全ユニークなやつです。それが判ればしめたもの。MySQLサーバを覗くと検討が付くかもしれません。

実は先日Nextcloudのアップデート途中で処理が止まってしまい、壊滅しました。それですべて新しく作り直したので「もう間違っても失敗してもどうなってもいいの」という気持ちで挑んだのです。

で、テーブルの名前は示されているので「構造」を見ます。プライマリーキーが何者なのか判った今は「id」とついたものが怪しいと検討を付けられるのです。

テーブル構造
テーブルの構造を見ると 「id」がいくつかあります

いくつか「id」があって、この中でどれかが、レコードを特定するための完全ユニークなidであるはずです。

適当に当たりを付けます。たとえば「user_id」でないことは確かでしょう。user_idがレコードごとのユニークなIDであるはずがありません。collection_id か resource_id のどちらかだと思われます。当てずっぽうに行きましょう。

で、プライマリーキーを設定するというメニューは見当たりませんが、よく見ると下方に「チェックしたものを:」に「主」というものがありました。

「チェックしたものを」メニュー

プライマリーキー、それは「主」であると想像できます。「主」にしちゃえ。ぷちっ。

正解なら名前の横に「主」アイコンが付きます。見事、プライマリーキーを設定できました。

不正解ならエラーが出ます。「複数同じのがあるから主にできないよ」みたいなエラーだと思います。ハズレなら主をセットできないという安心印の設計に胸をなで下ろしますね。

こうして、テーブルの構造を見て、完全ユニークであろうキーの当たりを付けて「主」にすることで、プライマリーキーの警告は消えました。

他の警告はとりあえず放置

まだ警告は残っていますが、見るも無残に溢れかえっていたエラーもかなり少なくなりました。他の警告は放置して、またいずれ答えがわかったら対処していきます。

 

NextCloud icon Nextcloud