は～（°～°）？？？？？キレそーー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が保持してる設定自体を書き換えてやればいいじゃんｗという考え方もあるが、せっかくSynology様がマネージドでやってくれてるんだぜ？それは嫌だ
閑話休題
ということで（？）NAS鯖をアップデートかけました
DSMのメジャーバージョンに合わせて、パッケージ類もいくつかが更新されました。
WPパッケージが再インストールという挙動となりました。
WPの設定が一部リセットとなりました。
ここまではいい
WPの設定が本当に一部だけ引き継がれ、WPの初期セットアップは終わっていることになっているが、SQLのパスワード類が設定されていない、これによりSQLにつながらないというエラーを吐いていた。
これについては後ろで語ろう
アプデにより画像が消えた原因
Synologyはパッケージをひな形だけ管理し、個々の設定はあまり重要視していない
つまり、「WP上で設定した値」や、「WPに直接アップロードした画像」は、
WPが独自で管理している１ファイルとして存在するため、パッケージマネージャ側は認識しないのだ
そのため、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を見よう