ブログの画像が消えました

は~(°~°)?????キレそーーwwwwwwwwwwww

SynologyNAS上で動作させているブログ記事が、SynologyNASのアップデートにより画像が消えました。
報告+対処などなどの備忘録

※このブログでは、ブログ作成に有名なWxxxPxxxxを利用しています。が、検索避けにWPという略称を利用しています。適宜読み替えてください。

ことの発端は、SynologyNAS鯖(DSM)のメジャーバージョンアップデート

SynologyのOS、DSMが6系から7系にメジャーバージョンのアップデートがありました。
6系は使えなくなるよってことでアップデートしました。
ブログデータの一部が消えました。
あなたさあ…

Synologyは擬似的なコンテナというか、puppetというか、なんというか、直接いじられた設定は基本的に保存されないしない、雛形とそれに対するマネージドな変更点の管理だけを行っている
SynologyのWebUIのような間接的なUIを通しての設定変更は維持されるが、
sshして、vim hoge.confして、ってやったものは基本消える

最たる例はnginx.conf
WebStationにてnginx.conf周りをすべて管理されており、結構ややこしい作りになっている
いや、紐解けば、Let’s Encrypt用の鍵であったり、SynologyのWebUI自体をnginxで受け取ってたり、その上でWebStationようにlistenしてる文があって、homeディレクトリのwwwフォルダをWebStationで見れるようになってたり云々カンヌン
やってることは単純

前に少し話したが、(Let’s Encrypt でSSLワイルドカード証明書を導入する)
ホスト名で分けて、あるWebアクセスは全部Synology鯖で受け取ろう。じゃあallow,denyなどのチューニングが必要だな、
proxy_passやらで親子関係を簡単にしよう、
WebStationの設定画面からではそこまでnginxの設定がいじれないようだぞっと、
じゃあnginx.confをsshで入って編集追記してやろうっと、

こうやってせっかく編集したconfファイル、容赦なく消える
サーバの再起動のタイミングでも、SynologyNASのWebUIからちょっと設定をいじっただけでも……
調べただけでも、結構な不満?やら、特有のテクの紹介が出ている。使いやすいんだが曲者だ。悪くない。

しかし、今はクソ面倒なやつだなあ

WebStation自体の設定が読み込まれ、nginx.conf自体がもとに戻ってしまう
いや、WebStationが保持してる設定自体を書き換えてやればいいじゃんwという考え方もあるが、せっかくSynology様がマネージドでやってくれてるんだぜ?それは嫌だ

閑話休題

ということで(?)NAS鯖をアップデートかけました
DSMのメジャーバージョンに合わせて、パッケージ類もいくつかが更新されました。
WPパッケージが再インストールという挙動となりました。
WPの設定が一部リセットとなりました。

ここまではいい
WPの設定が本当に一部だけ引き継がれ、WPの初期セットアップは終わっていることになっているが、SQLのパスワード類が設定されていない、これによりSQLにつながらないというエラーを吐いていた。
これについては後ろで語ろう

アプデにより画像が消えた原因

Synologyはパッケージをひな形だけ管理し、個々の設定はあまり重要視していない

つまり、「WP上で設定した値」や、「WPに直接アップロードした画像」は、
WPが独自で管理している1ファイルとして存在するため、パッケージマネージャ側は認識しないのだ

そのため、DSM自体のアプデによりWPのパッケージが再インストール。
パッケージマネージャが認識しているファイルのみ移行され、見事、直アップロードした画像が消えてしまったとさ

いや、「WP上で設定した値(SQLのパスワードとか)」もそうだけど、そういうのも管理してくれるっていうのがパッケージマネージャじゃないのかよ
公式提供のパッケージなのに

なんのために他の鯖にWPを、それこそコンテナとか使わずに、
NAS上にWPを立てて利用しているのかがわからなくなっちゃった

対策として外部ディレクトリを作成

泣いても戻らないので、対策
2(3)通りの方法があるかなと

  • WPのディレクトリを変えてしまい、WPのパッケージ雛形への依存度を下げる
    具体的に言うと、シンボリックリンクを貼って、画像ファイルを外に出す
  • 画像保存先を変えて、WP管理をやめる
    • CDNみたいな管理方法にする(データ配信する鯖がNASとは別という意味)
    • NASの外部公開機能を利用する

WPに他のストレージのシンボリックリンクを貼って、そこへ直アップロードできるようにする

最初はこれが一番手っ取り早い上に、WPの直アップロードを気にせず使える
そう思ったので、やった
結論としてはACLの手間の問題でできなかった

※検索避けにWPという略語にしてます

WPのフォルダへ
$ cd /var/service/web_packages/WP/
$ pushd wp-content/uploads
$ ls
2021   wp-statistics
→ここにアップロードされた画像やらが詰め込まれている
→例:2021/08/{日付}-{画像サイズ}.jpg とかとか
$ mkdir web
$ ls
2021   web   wp-statistics
$ pushd /
HDD1にある共有フォルダ「Share」にシンボリックリンクを貼る
$ cd /volume1/Share
$ ln -s /var/service/web_packages/WP/wp-content/uploads/web web
$ ls -l
lrwxr-xr-x 1 root root 9 Aug 26 12:00 web -> /var/service/web_packages/WP/wp-content/uploads/web

ここまでは至っていつもどおりのシンボリックリンク作成手順
この後がSynology特有のもので、ACLをいじらないと通常の共有フォルダ上からアクセスできなかった
1時間いじってだめだったので諦めた
ちなみに、SynologyのACLはsynoacltoolというコマンドを利用する

$ type synoacltool
synoacltool is hashed (/usr/syno/bin/synoacltool)
$ synoacltool -get web
(synoacltool.c, 489)It's Linux mode
'→Linuxの権限になっているので、付与していく必要があるっぽい
$ synoacltool -set-owner web ruth
他の共有できているファイルをsynoacltool -getで取得して、必要そうなものをどんどん追加していく
$ synoacltool -add web group:administrators:allow:rwxpdDaARWc--:fd--

という感じで、ACLを設定

が、Windowsなど、他のマシンからこのシンボリックリンクは利用できませんでした。
ディレクトリがあるということは見えるんだが、それ以上ができませんでした

1時間調べてだめだったって書いた気がするけど、もっと多い時間を使ったような気がする
Synology特有のACLの問題だったので、もっとこだわればできたかもしれないけど、考えうるフラグ立てや、設定を試したが、お手上げ
他の方法に切り替えていく
こうなるともうDocker管理でええやんって思う思った

画像保存先を変えて、WP管理をやめる

結局こうなった

CDN形式(NASとは別の場所にデータがあるという意味で言ってます)はやりたくない
ただ、一応、GCPのPCAを持ってる関係上、これが最もコスパが良い方法だ。それだけは言える
自宅鯖マンを除いて

WPをRasPiやらWin鯖やらでやらせない理由が、SQLを動かすコストと、その管理がひどく大変だからだ
初めて初代RasPiを手に入れ、これを使ってWeb鯖を構築していた時、MySQLのプロセスが重く、SQL以外まともにRasPiが使えないなんてことがあった。
それから、WPもそうだが、MediaWikiを標的にした、Botによる過剰アクセスがやってきた。
それがRasPiのSDカードを直撃
大学生が使うような安価なSDカードは一週間のうちに焼け焦げて、使い物にならなくなった

そんな経験もあり、「CPU負荷を切り離すことができて、HDDへ書き込めるもの」そんな要件ができた。SynologyNASが最適だったのだ。
再び僕の家にQueryの権威が振るわれることとなったのだ

閑話休題

結局、NAS上のWebStation管理のフォルダにblog用画像保存フォルダを作成し、LBみたいになってる親機のnginxへproxy_passを放り込む。

ただそれだけ…

ちなみに、
PhotoStationというSynologyのマネージド画像ビュアーがあったはずなんだが、DSM7になってなくなったようだ。
FileStationで手に入る共有URLはgofile.me経由になってしまい、直接画像を受け取りが行えない(共有URLへ飛んで直接そこから見ないと見れないので、imageタグで表示ができない)

崩れるだろうけど、AAで言うとこんな感じになってしまった
[Nginx@RasPi] — location /blog/ proxy_pass —> [WebStation(Nginx)@NAS] package:WP(Apache)へのalias:blog
        └– location /blog_images/ proxy_pass —> [WebStation(Nginx)@NAS] /web/images
ポップ数が多い…

さあ、これで外から見える位置に画像を置けるようになった
(URL作成や埋め込みが非情に面倒くさいのだが)
なくなった画像を探しながら、もう一度取得しながら埋めて回りましょう


WPのSQL類の設定(SynologyNASにおけるwp-config.phpの場所)

最初、これで結構時間を取られた
結論としては、SynologyのWebStationを使うようなパッケージは以下の位置にすべて放り込まれている

※検索避けにWPという略語にしてます

$ ls /var/services/web_packages/
@eaDir   phpMyAdmin WP

なので、Synology Packageで入れたもののwp-config.phpはここ

$ find /var/services/web_packages/ -name wp-config.php -type f 
/var/services/web_packages/WP/wp-config.php

自分がやったような、DSMのアップデートを行って、
 error establishing a database connection
というエラー文が表示されてしまった場合、WPのwp-config.phpがおかしくなっているであろう
そのため、php→MySQL(or MariaDB)の認証に失敗しているだけなのだ
落ち着いて、mysqlコマンドからqueryを叩くと、ちゃんとDBに保管されていた記事などのデータは残っていることが確認できる(怖くなってphpMyAdminでも確認した)

sshして、wp-config.phpを見よう

コメントを残す

メールアドレスが公開されることはありません。

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)