以前は、
…というスクリプトを自前で書く必要がありました。
でも今は、超便利な "Intersection Observer API" というものが用意されているので、この API を呼び出すことで、前者をブラウザ任せにできます。コードも簡単、動作も軽くなる。いい事ずくめ。
以下のMDNの解説ページに詳しい解説があります。
とりあえず、簡単なサンプル。
上のサンプルは…
…という感じに作ってみたものなので、コードは…
CSS.fi{ opacity:0; /* 不透明度の初期値 0(完全透過)*/ transition : opacity 5s 0.3s; /* opacity値に変更が加えられたら0.3秒待って、5秒掛けて変更値へ遷移。*/ }JavaScript
// クラス .fi を指定した要素をリストアップし、それぞれを監視する window.addEventListener( "load", (event)=>{ let tgts = document.querySelectorAll('.fi'); // クラス .fi な要素を全て取得 let options = { // 監視オプション root : null, // Documentルートに対して位置を計測 rootMargin : '0px', // マージンなし threshold : 0.5 // 対象要素の50%が可視になったら発動させる } tgts.forEach( (tgt)=>{ // それぞれの監視要素に対してオブザーバーを登録 new IntersectionObserver( handler , options).observe(tgt); }); }, false ); // コールバック関数。 // entry.isIntersecting (閾値を超えたら true、超えていなければ false を返す)の値をチェック。 // この例では「閾値を超えたときに、対象要素の opacity を 0(透明)→1(完全不透明)にする」という操作を行っている function handler( entries ){ entries.forEach((entry)=> { if( entry.isIntersecting ){ entry.target.style.opacity = 1; } }); }
opacity の設定値を逆にすれば「見えたらフェードアウト」になります。
※ opacity を 0 にして完全透過にしても要素自体はそこに存在しつづけていて、クリックイベントなどを受信します。
それを避けたいならば「要素を完全透過にしたあと、visibility を hidden にする」と設定しておきます。
.fi{ opacity:1; /* 不透明度の初期値 1(完全不透過)*/ visibility:visible; /* 要素を表示(これはデフォルト値なので設定しなくてもよい)*/ transition : opacity 5s 0.3s, visibility 5.5s; /* opacity値に変更が加えられたら0.3秒待って、5秒掛けて変更値へ遷移。visibility値が変更されたら、5.5秒後に変更値へ遷移。*/ }
// コールバック関数。 // 閾値を超えたときに、対象要素の opacity を 1(不透明)→0(透明)にし、visibilityをhiddenにする function handler( entries ){ entries.forEach((entry)=> { if( entry.isIntersecting ){ entry.target.style.opacity = 0; entry.target.style.visibility = 'hidden'; } }); }
コールバック関数内で利用する、要素の交差状態の変化を表すプロパティは、今回の例の "isIntersecting" (交差したか、していないかを判断する)の他にも幾つか用意されています。詳しくは、以下を参照してください。
]]>「この投稿をInstagramで見る」と表示されて、画像自体はインスタに飛ばないと確認することができません。
これは、Vivaldiの「トラッカーブロッカー」が画像表示をブロックしている所為なので、インスタ画像を表示させたいならば、いちばんイージーな方法は以下。
これでインスタの埋め込み画像がページ内で表示されるようになります。
ただし当然ながら、DuckDuckGo Traker Radar がブロックしていたインスタ以外のトラッカーのブロックも無効になってしまいます。
それは問題だ! と考える人は、面倒くささを厭わなければ、
と、これで「Instagram以外のトラッカーをブロックするリスト」が Vivaidi で有効になります。
この方法はこの方法で、オリジナルのブロックリストの更新に追随できなかったりなどの問題が生じます。そして何より面倒くさい。
暇なときにでも、オリジナルを定期的に取得して、自動的に不要部分を削除して更新するスクリプトを作ってみようか。
]]>なのでここ数年、SONYのオープンイヤー型有線イヤホンSTH40Dと、そのBluetooth版SBH82Dを愛用していたのだけれど、前者は断線、後者はバッテリーの保ちが2時間を切ってしまい、そろそろ後継を考えなくてはなりません。
オープンイヤー型の良いイヤホンは無いものか。
個人的に信頼を寄せているAnkerのSoundcore Aerofitが第一候補だったのですが、店舗に行って実際に装着してみると、どうもしっくりこない。
いろいろな製品を試した結果、自分の耳の形にいちばんフィットしたのが Cleer の ARC II。
お値段は正直、少々お高い。競合製品の倍くらいの価格なのですが、耳にしっくりこないものを買っても仕方がないので、そこには目を瞑ることにして、購入。
シンプルなお洒落箱に入っています。
ケースは大きめ。ハガキの半分くらいのサイズ。耳掛け式のため、イヤホン本体がある程度の大きさなのでこれは仕方がない。テクスチャは好みではないが、まぁ良かろう。
ヒンジ部が、少しだけ稼働するように出来ています。
…と言っても、くるりと回転させられるわけではなく、多少遊びがある程度。軽いバネでドライバ部分を耳のほうに押して沿わせる感じ。この感じはかなり良い。
フック部分も良い感じ。メガネと併用しても違和感はない。
耳掛けオープンイヤー型で音質をどうこう言うのも…と思っていたけれど、これがそんなに悪くない。音楽も自然に聴こえるし、通話にも不自由しない。このタイプにしては、かなり頑張っているほうではないかな。日常使いなら、音漏れも気にならない。
スマホのアプリで5バンドのイコライザーを設定できるので、聴く音楽や周りの環境に合わせて、ちょこちょこっと弄れます。
コントロールはタッチ式。装着位置を直そうと思ってドライバ部分に指が触れると、音楽が一時停止してしまうので難儀したのですが、これはアプリでシングルタップを無効にすれば解決します。
Bluetooth接続も良好。バッテリの保ちも良い。マルチポイント接続(PCとスマホに同時接続)しつつ音楽を聴き続けても、(アプリ上で確認する限り)全く残量が減らない。3時間聴き続けて、やっと100% → 80%。残り6時間24分、と出る。カタログスペックでは「最大8時間」と書いてあるけれど、少なくともそれに偽りは無さそうです。
というわけで、まずは満足。価格の元を取るまで使い倒す。
]]>ダウンロードしてきたものを見てみると、"Xlogo.svg" というファイルがあって、それは以下のような画像。
改変の是非はひとまず置いておくとして、ウェブページのデザインによっては、これの白黒反転バージョンが欲しかったりするのだけれど、pngやjpgに変換せずに、SVG形式のまま白黒反転させるのはどうすれば良いのだろう。
SVGをSVGのまま扱えるソフトが、手元には Inkscapeしか無いので、とりあえず Inkskape で件の Xlogo.svg を開いてみる。
そして、メニューの "エクステンション" → "色" → "ネガ" 。
すると…。
一発で出来た。
いちおう確かめてみると、元画像の背景色は #1a1a1a。変換後の画像の背景色は #e5e5e5。元画像の 𝕏 の内部の色は #333333 で、変換後の色は #cccccc。ちゃんと反転していますね。
あとは、これを "ファイル" → "名前を付けて保存…" して作業完了。
ちなみに、𝕏 の文字は、𝕏 と打ってやると表示できます。
以下は球団別の試合日程カレンダーです。
カレンダーアプリやGoogleカレンダーなど、.ics ファイルを扱うことが出来るアプリやサービスに取り込んでお使いください。
つづいてリーグ別のカレンダー。こちらは「セ・リーグ日程」「パ・リーグ日程」そして「交流戦日程」と3つに分かれています。
iOS / iPadOS 17の場合は、以下の手順でカレンダーに追加できます。
ウェブ(ブラウザ)版Googleカレンダーに読み込むには…
また、.icsファイルへのリンクを直接クリックしてローカルにダウンロード → カレンダーアプリケーションにインポート … なども出来ると思いますので。ご自由にお使いください。
上記の各URLを用いてカレンダーに読み込んでいる場合は、試合結果や追加日程など、自動的に更新されるようになっています。データ自体は試合終了後、深夜0時あたりを目処に更新しますが、カレンダーへの更新反映のタイミングは各々のアプリに依存しますのでご了承ください。
それから、ウェブ版のNPB試合日程カレンダーをこちら (freefielder.jp/magic/npbcal/) で公開しています。リーグ別・チーム別に表示を絞り込むこともできますので、iCal を読み込むのが面倒な場合はこちらを参照していただければ、と。
ウェブ版のほうも、試合結果・追加日程の更新は随時行われます。
カレンダーに間違いなどがありましたら、お気軽にご連絡ください。
]]>番号無し、大吉。
お寺や神社で自ら引いたものではないので、「大吉」と言われてもあまりテンションが上がらない。
「一陽来復」。
この言葉、元々は「冬至」の別名で、冬至は最も昼が短い、いわば陰が極まった日。で、この日を境に昼の時間が長くなっていくので、すなわち冬至とは、冬から春へ、陰から陽へと転じてゆく節目なのですね。陽が戻ってくるので「一陽来復」。
転じて「悪いことが続いたあとには幸運が訪れる」ことを表すようになったとか。
なるほど。
悪いことが続いていた覚えはないけれど、幸運の訪れを楽しみに待つことにしましょ。
]]>特に設定をしなければ最も新しい 6.5.0 で自動的に立ち上がるのだけれど、このバージョン、少なくともうちの環境では Wi-Fi 周りに不具合が出るようで、不具合のない 5.15.0-91 で起動するようにしたい。
うちの場合、何も設定を弄っていない状態では、PCを起動した直後に以下のようなGrubメニューが表示されます。一番上の "Linux Mint 21.2 Cinnamon" が選択されていて、このまま放っておくと、数秒後にカーネル 6.5.0 で起動します。
上から2つ目の "Advanced options ..." を選択してエンターキーを押すと、以下の選択肢が表示されます。
上から3つ目の "... 5.15.0-91-generic" を選択してエンターキーを押せばそれが起動するのだけれど、起動時に毎回操作するのは面倒くさい。
設定してみる。
Linux Mint / Ubuntu の過去のバージョンでは Grub-Customizer というGUIユーティリティを利用できたのですが、現在では標準リポジトリからはインストールできないようになっています。
→ Grub Customizer: why you shouldn't use it - Easy Linux Tips Project
なので、手動で設定せねば。
システムを起動したらターミナルを立ち上げて、/etc/default/grub を編集。
最初のほうの GRUB_DEFAULT=0 の行を、以下のように変更。
保存したら Grub の設定をアップデート。
続いて、デフォルトで起動するカーネルを設定。
これで次回の起動から、指定したカーネルで起動する筈。
再起動後のGRUBメニューは…
うまくいったみたい。最初から、2番目の "Advanced options ..." が選択状態になっていて、このままカーネル 5.15.0-91 で立ち上がります。
/etc/default/grub で、GRUB_DEFAULT=saved の代わりに
…としてやっても大丈夫な模様。
ということで、よろしくどうぞ。
]]>ちなみに2023年が大上吉な年だったかといわれると、そうでもない。これ以上に良い年は今まで幾らでもあったし、これからもあるのではないかな。
今年は、第六十九番 中吉。
例によって、お経が引用されている。
…は、調べてみると『妙法蓮華経法師品第十』の一節で、
…というような意味だそうだ。
ふむ。なる程。
うん。
今年は、穏やかな年でありますように。
]]>北陸の大きな地震のニュースを気にしつつ、例年どおりに近所の八幡さんに初詣。引いたおみくじを見てみると…、
第十四番 末吉。
ん?
同じ神社で昨年引いたものと全く同じだ。同じ番号、同じ内容。
毎年おみくじを引き続けていると、こういうことも偶にあるのね。
去年と同じ一年は、なんとか勘弁願いたい。
つづきも勿論、昨年のものと全く同一。
新年早々、これは風邪なのだろうか、喉が激しく痛くて辛いので、
これだけ早々に叶ってほしい。
]]>あくまでも "軽いトレッキング" なので、メレルとかキャラバンとか、そこまで本格的じゃなくて良い。
かと言って、Amazonで大量に出品されている、値段は激安だけれども、メーカー名をどう読むのかさえ解らないような(おそらく)中華な製品は避けたい。
そこで、これを試しに買ってみた。
値段的には怪しい中華と有名ブランドとの間。製品情報に当たってみると、『日米共同開発』『ドイツの撥水技術』『Amazonのページには "日本の中小企業" の表示あり』『公式サイトも充実』…ということで、大失敗の買い物にはならないであろう、との判断。
箱は至ってシンプル。どうやら ladshoes004 というモデルらしい。
開けてみると、こんな感じ。タグの "BIONIC FINISH" というのが自慢の撥水機能。
重さは380グラム。まずまず。
通販サイトのレビューを見ると「サイズがデカい」という報告が目につくので、0.5センチ小さいサイズを購入してみたのですが、横幅ピッタリ・爪先余裕あり…という感じ。サイズ的にはちょっと微妙だけれど、靴紐をきっちり縛れば中で足が遊び回る程ではない。
自分的には本格トレッキング用ではないので、こんな感じで充分といえば充分。そもそも、ちゃんとトレッキングに挑もうという気概なら、靴をフィッティングなしに通販で買おうなどとは考えない。
2ヶ月ほど履いてみた感じ、撥水機能はなかなか優秀。かなりの雨でも靴下が濡れることはない。ただし、お値段高めのトレッキングシューズと違ってベロと本体が縫い付けられていないので、ここから雨漏りする可能性はありそうだな。
ソールは柔らかめ。良いのだか悪いのだか。
縫製のほつれとか接着の剥がれなどは、今のところ無し。
これで実売5千円を切っているのならば、まずまずコスパは良いほうなのではなかろうか。
ということで、街なかで試し履きを繰り返しているうちに真冬になってしまった。暖かくなり始めたら、その辺の低山にでも出掛けてみましょ。
]]>十二月も半ばだというのに、昼間の気温は連日20度に迫らんかという勢い。こうも暖かいと、なにか調子が狂う。年末の感覚とは程遠い。
そういえばこの冬は、自転車に乗るときに未だ一度も手袋をしていない。
天候はそんな感じだけれど、暦の上では今年もあと僅か。天神の街なかは、どこもかしこもクリスマスイルミネーションに彩られている。
週末からは突然、激寒になるという予報が出ている。
体がついて行けるのか、心配だ。
昼間は二十度を超えるかという気候が続いていたのに、突然寒くなった。風も冷たく強い。
その風に煽られて舗道を埋め尽くす、色づいたイチョウの葉たち。
昔よく通っていた道なのだけれど、当時の記憶の中にはイチョウ並木は全く存在していない。しばらくご無沙汰している間に、こんなにも立派に育ったようだ。ひと月ほど前は、踏み潰されたギンナンの臭いが辺りに立ち込めて大変だったとか。
今夜から明日にかけては、少々雨が降るかも、という予報。
雨で湿ったイチョウの葉は、かなりよく滑る。
帰りは気をつけて歩こう。
無音状態のときに、思い出したかのように断続的に "プツッ" "プツッ" と繰り返される。不快なこと、この上ない。
原因も解消方法もさまざまっぽいのだけれど、うちでは以下の方法で解決。この方法で解決する場合、原因は PulseAudio のオートサスペンド機能。この機能をオフにしてやると不快なクリックノイズは生じなくなりました。
PulseAudio の設定ファイルを開く。
115行目あたりに、
load-module module-suspend-on-idle
という行があるので、コメントアウト。
# load-module module-suspend-on-idle
保存したら、PulseAudioを停止 → 再起動。
以上。
当該モジュールの読み込みを止めるには、上記の「設定ファイルを編集する」方法の他に「個人用設定ファイルを作成し、当該モジュールをアンロードする」という方法もあります。
個人用設定ファイルは、自分のホームディレクトリ直下の .config/pulse/default.pa です。このファイルが無ければ作成、あれば編集。
以下を記述。
.include /etc/pulse/default.pa .nofail unload-module module-suspend-on-idle .fail
「/etc/pulse/default.pa (デフォルト設定)を読み込んで、正しく読み込めたら module-suspend-on-idle モジュールをアンロードする。読み込めなかったら何もしない」
ファイルを保存したら、PulseAudio の再起動。
不快なクリックノイズとはおさらばだ。
ターミナルで、
…と打ち込むと、PulseAudio 設定ファイルなどで使用される書式を確認できます。
スマホのNextcloudアプリから画像ファイルをアップロードしようとすると、ModSecurity にブロックされて上手くいかない。
ログ(/var/log/apache2/modsecurity_audit.log)を見てみると…
--01fac117-B--
PUT /remote.php/dav/files/<UserName>/Documents/<Dir>/<FileName>.jpg HTTP/1.1
(中略)
--01fac117-H--
Message: Warning. Match of "within %{tx.allowed_request_content_type}" against "TX:content_type" required. [file "/usr/share/modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "956"] [id "920420"] [msg "Request content type is not allowed by policy"] [data "|image/jpeg|"]
…となっていて、「image/jpeg 形式のファイルの取り扱いは許可されていない。ルール920420に抵触している」と言われています。
前回、Nextcloud を邪魔しないように ModSecurity を設定した筈なのに。
いちおう確認してみると、やはり /usr/share/modsecurity-crs/rules/REQUEST-903.9003-NEXTCLOUD-EXCLUSION-RULES.conf には以下のようなルールが存在し、これが有効になっているので、画像アップロードは問題なく行える筈。
SecRule REQUEST_FILENAME "@contains /remote.php/webdav" \
"id:9003100,\
phase:2,\
pass,\
t:none,\
nolog,\
ctl:ruleRemoveByTag=attack-injection-php,\
ctl:ruleRemoveById=941000-942999,\
ctl:ruleRemoveById=951000-951999,\
ctl:ruleRemoveById=953100-953130,\
ctl:ruleRemoveById=920420,\
ctl:ruleRemoveById=920440,\
ver:'OWASP_CRS/3.3.2'"
/remote.php/webdav〜 へのアクセスの際は、ルールID:920420(コンテンツタイプの制限)などを無効にする、という設定です。
なのに何故。う〜ん。
頭を抱えつつログとルールを暫し眺めていたら気が付いたのですが、ログの方では、
/remote.php/dav/files/<UserName>/Documents/<Dir>/<FileName>.jpg HTTP/1.1
と、アクセスする先は /remote.php/dav になっています。でもルールの方を見てみると、
SecRule REQUEST_FILENAME "@contains /remote.php/webdav" \
「/remote.php/webdav へのアクセス時はルール92040を無効にする」と定義されています。
つまり、/remote.php/webdav〜 ではコンテンツタイプ制限が無効になっているけれど、 /remote.php/dav〜 では初期設定どおり image/jpeg を制限したままなので、画像をアップロードしたときにブロックされてしまう、ということではなかろうか。
なので、以下のようなルールを作成。
SecRule REQUEST_FILENAME "@contains /remote.php/dav" \ "id:90031,\ phase:2,\ pass,\ t:none,\ nolog,\ ctl:ruleRemoveByTag=attack-injection-php,\ ctl:ruleRemoveById=941000-942999,\ ctl:ruleRemoveById=951000-951999,\ ctl:ruleRemoveById=953100-953130,\ ctl:ruleRemoveById=920420,\ ctl:ruleRemoveById=920440,\ ver:'OWASP_CRS/3.3.2'"
これを、前回作成した /etc/modsecurity/modsec_local.conf に追加してファイルを保存。
REQUEST-903.9003-NEXTCLOUD-EXCLUSION-RULES.conf 内では、上記の ルール 9003100 の他に、9003105にも、
SecRule REQUEST_FILENAME "@contains /remote.php/webdav" \
という設定があり、9003116 にも
SecRule REQUEST_FILENAME "@rx (?:/public\.php/webdav/|/remote\.php/dav/uploads/)" \
という記述があります。
このふたつのルールも、webdav → dav に変更した上で新しい ID を振って、modsec_local.conf に追記しておいたほうが良いかもしれません。
設定が完了したら、いつものように文法チェック → Apache再起動。
はい、これでどうだ。
ひとまず、無事にファイルアップロードが完了するようになりました。
ModSecurity、めんどくさい…。
]]>ModSecurity が初期設定のままだと Nextcloud の様々な動作がブロックされてしまうので、適切に動作するように設定してみました。
まずは crs-setup.conf を編集。
350行目あたりに、以下のような記述があります。
# Modify and uncomment this rule to select which application: # #SecAction \ # "id:900130,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:tx.crs_exclusions_cpanel=1,\ # setvar:tx.crs_exclusions_drupal=1,\ # setvar:tx.crs_exclusions_dokuwiki=1,\ # setvar:tx.crs_exclusions_nextcloud=1,\ # setvar:tx.crs_exclusions_wordpress=1,\ # setvar:tx.crs_exclusions_xenforo=1"
"これらのアプリケーションを利用している場合は、このルールをアンコメントして修正してね" ということなので、そうする。Nextcloud向けの例外ルールを有効にする設定です。
SecAction \ "id:900130,\ phase:1,\ nolog,\ pass,\ t:none,\ setvar:tx.crs_exclusions_nextcloud=1"
上記のように修正。これで、Nextcloud向けのルール (/usr/share/modsecurity-crs/rules/REQUEST-903.9003-NEXTCLOUD-EXCLUSION-RULES.conf) がアクティブになり、Nextcloudの各種動作がModSecurityに引っかからなくなります。
※ 同一サーバ上で Nextcloud 以外のDAVを動かしていない場合は、上記の設定を行っておけば、以下の377行目あたりからの設定は不要です。
REQUEST-903.9003-NEXTCLOUD-EXCLUSION-RULES.conf 内で
SecRule REQUEST_FILENAME "@rx /(?:remote|index|public)\.php/" \ "id:9003130,\ phase:2,\ pass,\ t:none,\ nolog,\ ver:'OWASP_CRS/3.3.5',\ setvar:'tx.allowed_methods=%{tx.allowed_methods} PUT PATCH CHECKOUT COPY DELETE LOCK MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH UNLOCK REPORT TRACE jsonp'"
…というルールが有効になるためです。このルール(PUTなどのメソッドを許可する)が効く場所を限定している分、こちらのほうが安全です。
続いて、377行目あたり。
# HTTP methods that a client is allowed to use. # Default: GET HEAD POST OPTIONS # Example: for RESTful APIs, add the following methods: PUT PATCH DELETE # Example: for WebDAV, add the following methods: CHECKOUT COPY DELETE LOCK # MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH PUT UNLOCK # Uncomment this rule to change the default. #SecAction \ # "id:900200,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:'tx.allowed_methods=GET HEAD POST OPTIONS'"
"WebDAVを利用する場合は、許可されるHTTPメソッドに CHECKOUT COPY DELETE LOCK MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH PUT UNLOCK を追加して、以下のルールをアンコメントしてください" とのことなので、そうする。
SecAction \ "id:900200,\ phase:1,\ nolog,\ pass,\ t:none,\ setvar:'tx.allowed_methods=GET HEAD POST OPTIONS CHECKOUT COPY DELETE LOCK MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH PUT UNLOCK'"
以上のように crs-setup.conf を修正して保存。
設定の文法チェックをして、問題無ければ Apache を再起動。
これで凡そ、Modsecurity が Nextcloud の動作に影響を与えなくなる筈。
この設定でしばらく運用していると、ファイルの更新などの際に、
に引っかかって、操作が完了しない事象が偶に発生しました。ファイルの内容に、たまたま不正と認識される文字列が含まれていた場合にブロックしてしまうっぽい。
なので、Nextcloudが稼働しているディレクトリで、先のルールを無効にしてみます。
/etc/modsecurity/ に modsec_local.conf※ というファイルを作成して内容を編集。
以下を記述します。
<Directory /path/to/nextcloud> SecRuleRemoveById 921110 SecRuleRemoveById 200002 </Directory>
/path/to/nextcloud は、Nextcloud がインストールされているディレクトリへの絶対パス。このディレクトリ内では、ルール 921110 と 200002 を無効にする、という設定です。
※ ファイル名は .conf で終われば何でも良い。
/etc/apache2/mods-available/security2.conf を見てみると、こう書いてある:
<IfModule security2_module>
# Default Debian dir for modsecurity's persistent data
SecDataDir /var/cache/modsecurity
# Include all the *.conf files in /etc/modsecurity.
# Keeping your local configuration in that directory
# will allow for an easy upgrade of THIS file and
# make your life easier
IncludeOptional /etc/modsecurity/*.conf
# Include OWASP ModSecurity CRS rules if installed
IncludeOptional /usr/share/modsecurity-crs/*.load
# Include local rules if exists
IncludeOptional /etc/modsec_local/*.conf
</IfModule>
この部分は、/etc/modsecurity ディレクトリ内の *.conf ファイルを全て読み込む、という設定です。ローカル設定をこのファイルに直接記述すると、このファイルがアップグレードされたときにその設定が消えてしまいかねないので、/etc/modsecurity/ に なにがし.conf という名のファイルを作成し、そこにローカル設定を記述しておいたほうが楽ちんですよ、ということですね。
変更を保存したら、いつものように設定の文法チェックを実行し、問題無ければ Apache を再起動。
ひとまずこれで落ち着いた感じ。そもそもこのクラウドサーバは自分しか利用していないので、とりあえず実運用に入って、何か不具合が起きたら都度、対処することにしましょ。
【2023.10.24 追記】
]]>