ランチバッグを新調したことで弁当箱もサイズアップしましたが……
「やはり鞄の中でずれてしまい傾く」リスクがあったので、

この、丸い縦型に戻りました。ややサイズダウンは否めませんが、ここのところ体重も増えてきたのでちょうどいいサイズと見ます。
今回の副菜は、いつものポテサラよりも大きく簡便化。

- 中華クラゲ
- 切り落としのサラダチキン
- カニカマ
- 刻みネギ
以上。ネギ以外の全てに味がついているので

単に混ぜるだけというのもお気に入りです。
ランチバッグを新調したことで弁当箱もサイズアップしましたが……
「やはり鞄の中でずれてしまい傾く」リスクがあったので、

この、丸い縦型に戻りました。ややサイズダウンは否めませんが、ここのところ体重も増えてきたのでちょうどいいサイズと見ます。
今回の副菜は、いつものポテサラよりも大きく簡便化。

以上。ネギ以外の全てに味がついているので

単に混ぜるだけというのもお気に入りです。
平日の休みで軽い花見と昼食。
今回、試したレンズは頂き物の

汎用ズームレンズとキャップレンズのフィッシュアイです。

いつものレンズと勝手が違ったという印象。これはもう少し精進が必要です。


おなじみのフィッシュカクテル。季節に合わせて桜のソーダと甘み、クラゲの水まんじゅうをチョイス。
それで650円という絶妙なチョイスにより、ここの隠れた人気メニューまで見えます。

なお、フィッシュアイでの水槽が取れたので満足でした。
を乗り越え、無事に移行も完了。次のフェイズに関する簡単なメモです。
さすがにUbuntu 20.04が動き続けるというのは忍びないので、これもHWを変えたいです。昨今、ミニPCも高くなってきているのでその辺は様子を見ながら。
それこそ転がっているノートPCあたりをベースにするのも視野に入れています。
2015年に購入したNASですが、メインのストレージではなく、先のサーバ環境の外部ディスクとして用いるには十分。(さすがにこの際はディスクを変えないとですが)
いずれにしても、これまでのデータを複数取り込むことができたのはありがたい限り。
膨大な写真データのなから、コーンウォールを訪れた際のこういう写真を発掘できたのは割と収穫です。

2026年3月31日に発覚したaxiosのサプライチェーン攻撃。
内容を聞くだけでゾッとする話だったので、調べつつ筆者がインターネット上に設置しているgrowiサーバでの影響を調べました。
まずは、動いている環境のaxiosバージョンを特定することが最優先。筆者はこのライブラリを恥ずかしながら聞くまで知らなかったのですが 、JavaScriptのデファクトスタンダード的なHTTPクライアントライブラリ と聞いたので「絶対に入っているだろう」の断定で動きました。
cd /path/to/growi
自分の環境に合わせます(筆者環境/home/www-data/growi)
npm ls axios
または
cat pnpm-lock.yaml |grep axios
axios@1.11.0
axios@0.26.1
axios@0.21.4
影響を受けるバージョンは
そのため、攻撃対象となったaxiosを利用していない(つまり、攻撃コードは混入していない)ものとなっています。
ほぼないとは思いますが「npm updateを実行してしまったかも」の場合は、今回のケースで攻撃者が埋め込んだマルウェアが生成するディレクトリの有無を調べます。
find node_modules -name "plain-crypto-js"
結果、何もなければ物理的にもクリーンです。
また、筆者は該当vpsでBookStackやsnipe-itなどのLaravelライブラリを動かしていますが
cd /path/to/BookStack && pwd
npm ls axios
BookStack@ /home/www-data/BookStack
└── (empty)
と、いずれも(PHPメインであるためか)動いていない状態が分かりました。
開発者が信頼している公式ツールをそのまま使っただけで感染する状態であった点にあります。供給者のツールに攻撃ツールを仕込んでいたということで「サプライチェーン攻撃」だそうで。(発覚後、npm が悪性 axios バージョンを削除)
これをmermaid.jsにまとめたのがこちら。
たまたまGrowiのアップデートタイミングとずれていた、そして、 pnpm-lock.yamlがあるおかげで、意図しない汚染版の混入を防ぐことができました。
なお、今回のケースで「黒」だった場合は、該当axiosの除去に留まりません。
VPS乗の全ての認証情報
などが漏洩されたものとして作り直す必要があります。
以上、4月1日に公開すべき内容ではないものでした。
NASセットアップ中に起きたHDD初期不良。
これに対してどのようなサポートをし、復旧させたかのメモです。
これが一番大切です。そもそも、メーカーにしても代理店にしても「故障した」って連絡はまず受け取りたくないもの。
は必須です。特に、大手代理店やメーカーは、「これは確実にうちのメーカーの正当なものである」というデータベースを持っていますから、その紐付けのためにも上記二つは持っておきましょう。
また、機器の外箱や梱包材なども持っておいたことが今回のスムーズな解決につながります。購入したらすぐ捨てるという断捨離精神は「機器の移行」では命取りになりやすいです。
上記、準備ができたらメールなり問い合わせフォームなどで確認。
買ったばかりの製品がいきなり故障。そら、感情的になります。「高い金払わせておいて」の気持ちが先に来るのは当然です。
しかし、前項で示した「バスタブ曲線」であるように、初期不良はつきものです。実際に秋葉原などのパーツ屋で「初期不良は○日以内」ということを聞いた方もいるでしょう。
が、結果的に最速の復旧となります。
これは、筆者の祖母が生前によく言っていたことですが;
「丸い卵も切り様で四角。言葉も言い様で角が立つ」
「聞き間違いは言い手の責任。言い間違いは聞き手の責任」
は、今の大炎上時代を見越したとしか思えない言葉。
は必要です。
筆者はこんな感じでサポートに聞きました。
ご担当者様
お世話になっております。
○月X日、購入店(または購入サイト名)にて
- 購入したもの1
- 購入したもの2
- 購入したもの3...
を、注文番号:xxxxxxxx で購入いたしましたところ、以下の不良が発生しましたので対応をお願いしたいです。
【不良が起きた製品】
HDD (シリアルナンバー)
【状況概略】
セットアップ中、ディスク読み取りエラーとなって認識されない状況となっております。
【具体的なメッセージ】
TS-216Gの管理画面で
「1つ以上の回復不能な読み取り/書き込みエラーが検出されました。ディスクを交換することを検討してください
のエラーが発生しています。(添付をご参照ください)
QNAP本体もDisk2が赤く点灯しておりました。
〔QNAP本体のエラー〕
以下を確認しております。
エラー 2026-03-27 01:02:40 --- --- localhost --- Storage & Snapshots Disk [Storage & Snapshots] Disk "Host: 3.5" SATA HDD 2" failed. Volume: HOLD, Storage pool: 1.
【事象発生時の操作】
以下を行いました。
1. HDD装填
2. ディスクの認識
3. RAID構築
4. ボリューム作成
5. ボリューム作成後に上記エラーを発見。
【事象発生後に実施したこと】
1. QNAP本体の再起動 → 変化無し
2. ディスクのさし直し → 変化無し
【推定される事象と依頼】
初期不良と思われます。同品交換をお願いできますでしょうか。
または、そうでないならば、対応方法をご教示ください
「いつ、どの様な操作で、何が起きたか」は確実に伝えましょう。
これが「サポート埒外の操作をしていた」「ブチ切れて機器を床にたたき落とした」等は話を聞いてもらえないでしょう。
何をやっていたかは正常に伝えましょう。
相手は何百、何千と問い合わせに対応しています。その対応の是非をトリアージしています。なので「これは早急に対処が必要だ」という書き方のためにも
の3点の順番で伝えると、担当者は「これはすぐに動かねば」となります。
驚くほど迅速でした。
旨を伝えられたので、それを連絡。
そして、すぐに到着。もちろん、それに備えて
に入れて、その中に
を添えて、担当者が分かりやすい様にしておきます。
新しいHDDが到着して、ディスクをQNAPのベイに入れたところ無事認識!

RAIDの構築も正常に行えたので本当に良かったです。

これに尽きます。移行時のミスだったので切り戻し、手戻りは容易です。
バスタブ曲線の最初の段階で起きたので迅速な対応ができました。
そもそも、15年以上も前のデータや父のデジタル遺産を引き継いだ背景もあり「製品の信頼性」が第一でした。
そのため、「どこで買うか」というのは「どのメーカーのもので買うか」以上に重要です。
今回、QNAP/WDという信頼と実績あるメーカーを、信頼できる店舗(TSUKUMO)で買ったのは、販売実績とサポートが厚いという2点によるところが大きいです。
この言葉が叫ばれて久しいですが、筆者は「コストとやらの本質を見失っていないか」という疑問があります。
というのも、「近所のスーパーより10円安いから」といって卵を隣町のスーパーで
をかけて手に入れるという行為は、「10円の価値があるのか?」です。特に人間というやつ、かかったコストは計算できてもかかった時間は無頓着になりがちです。
例えばこれが出所が怪しい店舗で、連絡手段がよくわからない店で買っていたら障害発生後の即交換は望めなかったでしょう。
購入して10年超というNASの移行はなかなかのドラマがありましたが:
新たなデータストレージの引き継ぎがなんとか解決に向かって一安心でした。
次の10年も無事に持つかどうか、それこそ、大切に適切に扱っていきたいです。
TS-216Gセットアップ中、まさかの事象が起き、それを解決しようとしたときのメモです。
と、一番大事な写真データを新しいNASに移行し、目処が立ったところでNAS本体を確認すると「LEDが一つ赤点灯」。
「赤?」思いながらNASの管理画面を見ると
2026-03-27 01:02:40 --- --- localhost --- Storage & Snapshots Disk [Storage & Snapshots] Disk "Host: 3.5" SATA HDD 2" failed. Volume: vol01, Storage pool: 1.
と、マウントしていない旨の連絡。更に、ディスクの状況でも
「ディスクS.M.A.R.T情報を読み取ることができません。全てのディスクが公式互換性リストに登録されていることを確認してください。
ディスクアクセス履歴:エラー
ディスクS.M.A.R.T情報:エラー

また、ストレージプールを見ても「メンバーではない」という状況です。

導入して1週間も経っていないので、対応を行います。
この手のハードウェア初期構築時の基本です。
しかしNG。
幸い、RAID1で組んだディスクは「ホットスワップ」可能です。つまり、1本ダメでももう1本が正常であれば機器の通電中だろうとディスクの取り外しと交換が可能です。
しかしこちらもNG。
バルク品だろうとリテール品だろうと発生する「初期不良」にとっ捕まりました。いわゆる「バスタブ曲線」の最初の高い位置にあるところです。
以下、Geminiによる解説。
この、「初期故障機」に捕まりました。
嘆いていっても事態が変わるわけでもなし。やれることをやっていきます。
『未来戦隊タイムレンジャー』の
未来は変えられなくたって、自分達の明日ぐらい変えようぜ!
の精神。それに、「初期対応が可能な帰還。それも移行中」にこの不良が見つかったのはむしろ幸いと言えます。正当な権利として購入店に対応を依頼できるのですから。
というわけで、次のエントリーではこの対応のメモを記します。
筆者はUbuntu環境のApache設定で
というセキュリティ対策を取っています。(詳細)
しかし、これは相手もその辺りの呼吸をわきまえていて、
パターンが割とあります。今回、それを検知した時のお話。
例によってURLとIPアドレスはダミーですが、以下のような奇妙なログを見つけました。
192.0.2.10 - - [27/Mar/2026:10:28:03 +0900] "GET /images/?1770681132 HTTP/1.1" 404 5506 "-" "Mozilla/5.0 (Linux; Android 5.0; SM-G900P Build/LRX21T) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.4601.1280 Mobile Safari/537.36"
一見、ただの404エラーではありますが、強烈な違和感を覚えました。
Android 5.0は、2018年頃に公式セキュリティサポート終了。GooglePlay開発者サービスも2024年7月には終わっています。
同じくChrome60。これも2017年と古いバージョンです。
そんな古いAndroidが筆者のサイトにアクセスできるということはまず、あり得ません。種を明かしてしまうと、筆者のWebサイトは
#SSL対応
SSLEngine on
Protocols h2 http/1.1
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
として、TLS1.3未満のアクセスができないようになっています。 この暗号化形式をサポートするようになったのはAndroid10以降。
古いAndroidが新しいSSL暗号が施されたサイトには、そもそもアクセス不可能です。リクエストの段階でハンドシェイクが拒否されるため、404エラーどころかWebサイトそのものが見られません。
しかし、上記のアクセスログは「古いAndroidのバージョンからTLS1.3のSSLログが残る」。つまり、残る結論はほぼ「エージェントを偽装してくるクローラー」に限られます。
アプリ開発者が Conscrypt(Google製のセキュリティライブラリ)などをアプリに同梱している場合は、Android 4.4以降の古い端末でもアプリ単位でTLS 1.3通信を行える場合がありますが、そんな回りくどい方法はないでしょう
筆者の「厄介なエージェントを拒否する」仕組みがこちら。
(省略)
# botのアクセスリストを外部ファイルから読み込む
Include /etc/apache2/conf-enabled/bad-bot-list.conf
(省略)
<RequireAll>
# bad_bot変数がセットされていたらアクセスを拒否
Require not env bad_bot
# それ以外は許可
Require all granted
</RequireAll>
SetEnvIfNoCase User-Agent "facebookexternalhit/1\.1" bad_bot dontlog
SetEnvIfNoCase User-Agent "SemrushBot/7~bl" bad_bot dontlog
SetEnvIfNoCase User-Agent "AhrefsBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "MJ12bot" bad_bot dontlog
SetEnvIfNoCase User-Agent "DotBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "Baiduspider" bad_bot dontlog
SetEnvIfNoCase User-Agent "YandexBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "Sogou web spider" bad_bot dontlog
等。この、SetEnvIfNoCase User-Agentの箇所に、以下を加えます。
# Android 10.0未満 を排除する
SetEnvIfNoCase User-Agent "Android [1-9]\." bad_bot dontlog
# 10年以上前の古いOS(Windows XP/Vista等)を装うボットも排除
SetEnvIfNoCase User-Agent "Windows NT [3-5]\." bad_bot dontlog
# その他、不自然な挙動を示すUA群
SetEnvIfNoCase User-Agent "^$" bad_bot dontlog
後は
sudo apache2ctl configtest
sudo systemctl reload apache2.service
で、上記、不自然なログのアクセスはピタリと止まりました。
不正アクセスにはユーザーのみならず
はもとより、OSやエージェントを偽装してくる輩も多いので。
だが…………
マヌケは見つかったようだな
ぐらいの勢いでアクセスログを観察していきましょうというお話でした。
昨日からの作業ログです。
※先日からのステータス
ボリューム、ドライブ作成
設定後、構築・フォーマット完了、「準備完了」を確認。
最新状態へのアップデートおよび再起動を実施。
\\NASのドメイン へのアクセスおよび Public/work フォルダの視認を確認。

本体を開封したのがこちら。重さはずっしり。
RAID同期(リシンク)実行中。8TBのディスクの同期なので、これは待ちの状況。新しい機器のセットアップは面倒ですが子心躍ります。

昨日の続き。
HTTP ObservatoryでRedmineサイトをB-→B+に改善しましたが、
筆者環境の
環境のHTTP診断もそのぐらいであろうと思ったらまさかのF判定を食らいました。
最初の診断結果では、以下の項目で派手に減点を食らっていました。
特に謎だったのが、「Apache側でHeader設定を入れているはずなのに、認識されない(Failed)」という点でした。
原因を調査するため、curl -I コマンドで生のレスポンスヘッダーを確認しました。
curl -I https://growi-site
Strict-Transport-Security: max-age=63072000
Strict-Transport-Security: max-age=15552000; includeSubDomains # <-- 2重に出ている
X-Content-Type-Options: nosniff
X-Content-Type-Options: nosniff # <-- 2重に出ている
Set-Cookie: connect.sid=...; Path=/; HttpOnly # <-- Secure属性がない
リバースプロキシ構成では、「バックエンド(アプリ側)が吐き出すヘッダー」と「Apacheが追加しようとするヘッダー」が両方ブラウザに届いてしまい、重複が発生。
診断ツール側が「どの設定を信頼すべきか判断できない」としてエラーになっていたのです。
これを回避するための手段が以下の通りです。
sudo cp -pi /etc/apache2/sites-available/growi-site.conf /path/to/backup/growi-site.conf.$(date +%Y%m%d)
.confの名前やバックアップディレクトリは自分の環境に合わせます。
diff -u /path/to/backup/growi-site.conf.$(date +%Y%m%d) /etc/apache2/sites-available/growi-site.conf
エラーがないことを確認します。
/etc/apache2/sites-available/growi-site.confを以下のように修正していきます。(要管理者権限)
Header always set Strict-Transport-Security "max-age=63072000"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-XSS-Protection "1; mode=block"
# 重複を防ぐため、通常のレスポンスとProxyレスポンスの両方から一旦削除
Header unset Strict-Transport-Security
Header always unset Strict-Transport-Security
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Header unset X-Content-Type-Options
Header always unset X-Content-Type-Options
Header always set X-Content-Type-Options "nosniff"
Header unset X-Frame-Options
Header always unset X-Frame-Options
Header always set X-Frame-Options "SAMEORIGIN"
# 足りなかった重要ヘッダーを新規追加
Header always set Referrer-Policy "strict-origin-when-cross-origin"
# CSP: アプリの動作を維持しつつ、安全性を高める(object-src 'none' を追加)
Header always unset Content-Security-Policy
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self' ws: wss:; object-src 'none';"
# CookieのSecure属性をApache側で強制付与
Header edit Set-Cookie ^(.-)$ "$1; Secure; SameSite=Lax"
この「2重出力」を解消し、かつアプリ側で足りない属性を付与するために、Apacheの設定を「既存ヘッダーの完全掃除 + 強制セット」という戦略に変更しました。
diff -u /path/to/backup/growi-site.conf.$(date +%Y%m%d) /etc/apache2/sites-available/growi-site.conf
以下のような差分を確認します。
- Header always set X-Content-Type-Options "nosniff"
- Header always set X-Frame-Options "SAMEORIGIN"
- Header always set X-XSS-Protection "1; mode=block"
+ # 重複を防ぐため、通常のレスポンスとProxyレスポンスの両方から一旦削除
+ Header unset Strict-Transport-Security
+ Header always unset Strict-Transport-Security
+ Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
+
+ Header unset X-Content-Type-Options
+ Header always unset X-Content-Type-Options
+ Header always set X-Content-Type-Options "nosniff"
+
+ Header unset X-Frame-Options
+ Header always unset X-Frame-Options
+ Header always set X-Frame-Options "SAMEORIGIN"
+
+ # 足りなかった重要ヘッダーを新規追加
+ Header always set Referrer-Policy "strict-origin-when-cross-origin"
+
+ # CSP: アプリの動作を維持しつつ、安全性を高める(object-src 'none' を追加)
+ Header always unset Content-Security-Policy
+ Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self' ws: wss:; object-src 'none';"
+
+ # CookieのSecure属性をApache側で強制付与
+ Header edit Set-Cookie ^(.-)$ "$1; Secure; SameSite=Lax"
sudo apache2ctl configtest
Syntax OKを確認します。
sudo systemctl restart apache2.service
systemctl status apache2.service
active (running)を確認します。
curl -I https://growi-site
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Referrer-Policy: strict-origin-when-cross-origin
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self' ws: wss:; object-src 'none';
など、ヘッダーのダブりがないことを確認します。
HTTP Observe に再度アクセスし、セキュリティ診断を行いました。
再スキャンの結果、主要な項目はすべて Passed となり、無事に B+ を獲得。
CSPにおける 'unsafe-inline' や 'unsafe-eval' が「安全ではない」として減点対象になっています。しかし、これらを外すとモダンなWebアプリ(Wikiのエディタなど)は動かなくなることが多いため、利便性とのトレードオフとして 「B+」は現実的な落とし所と言えます。
curl -I で重複を疑う。Header always unset してから set することで、バックエンドとの競合を確実に排除できる。Header edit で一発解決。Powered by WordPress & Theme by Anders Norén