Lycolog

Edgeのバージョンが145.0.3800.70になったらダウンロード履歴からファイルをD&Dできなくなり、とても不便だったのでEdgeのバージョンを145.0.3800.65にロールバックして固定することにした。

その時にやったことを残しておく。

やったこと

手順を間違えるとEdgeをアンインストールする羽目になるので絶対に前後させてはいけない。もしも前後させるとEdgeの設定全部やり直しになる。

事前に拡張機能も含め、Edgeの全設定のバックアップをしておくとよいだろう。具体的にはプロファイルフォルダを丸ごとどっかにバックアップしておくとよいと思われる。

具体的には%USERPROFILE%\AppData\Local\Microsoft\Edge\User DataのDefaultとかProfile 1みたいなフォルダに設定が格納されているので、これをバックアップしてやればよい筈だが、検証はしていない。

1. Edgeのアップデートができないようにファイアーウォールを構成するで阻止する

次のコマンドを管理者権限のコマンドプロンプトに流す

netsh advfirewall firewall add rule name="Disable Edge Updates" dir=out action=block program="C:\Program Files (x86)\Microsoft\EdgeUpdate\MicrosoftEdgeUpdate.exe"

2. 古いバージョンのEdgeを入手してインストールする

1. ビジネス向け Microsoft Edge のダウンロードとデプロイの画面中ほどにある「古いバージョンの Edge をお探しですか?」から、ロールバックしたいバージョンを選択し、ダウンロードする
   

   

2. ダウンロードしたインストーラーに対し、次のコマンドを管理者権限のコマンドプロンプトに流す

   msiexec /I MicrosoftEdgeEnterpriseX64.msi ALLOWDOWNGRADE=1
   

トラブルシューティング

手順を間違えてしまいEdgeを最新化してしまった

次のコマンドを管理者権限のコマンドプロンプトに流せば再インストールできるようになるはずだが、Edgeそのものもアインインストールされてしまい設定がすべて吹き飛ぶ可能性がある。特に拡張機能の複雑な設定が吹き飛ぶと致命的なので絶対にバックアップしておこう。

msiexec /x MicrosoftEdgeEnterpriseX64.msi

あとがき

Microsoft公式のEdge の更新制御には、レジストリのHKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdateにREG_DWORD値としてUpdateDefaultを追加し、値として0を設定することでアップデートされなくなるとあったが、私の場合これは機能しなかった。

恐らくEdgeのアップデートを止める唯一の方法はアップデーターを殺すことである。

Edge の更新の流れについてを読む限り、Windows UpdateでEdgeが更新されることは基本的にないらしいので、安心できる。

当たり前だがこのまま放置していると、セキュリティ面や履歴の同期の仕様変更による機能不全などで、そのうち使えなくなる日が来そうなので、その時はまた考えたい。

2026-03-01追記

Microsoft Edge の既知の問題 | Microsoft Learnによると、ダウンロード履歴からファイルをD&Dできないのはバグらしいので、そのうち治るかも？

Value-DomainのダイナミックDNSエンドポイントは60秒以内に叩くとエラーが返ってくるので、これを回避するためのDDNSの仕組みを作った話。

やったこと

まず、Value-DomainのDNS APIに対し、既存のaレコードをバルクで差し替えるためのツールとしてvd-ddns_v4.plを作った。

そしてhotplug.dにPPPoEインターフェースのIPが変わったときに、このスクリプトを蹴る処理を書いた。

この記事の前提構成

OpenWrtにIPv4用のPPPoEインターフェースがある。

やったこと

1. 今回利用するのに必要なPerl周りをセットアップする。ストレージの空きが3.2MBほど必要
2. value-domain-dns-utilを/root配下とか適当な場所に放り込む
   • opkg install openssh-sftp-serverでSFTPを導入しておくとファイル移動に便利

3. vi /etc/hotplug.d/iface/40-pppoeとかして、OpenWrtのインターフェースが変化したときのHookを作る

    #!/bin/sh
    # デバイスが存在しなければ終了
    [ -n "$DEVICE" ] || exit 0
    # リンクアップでなければ終了
    [ "$ACTION" = ifup ] || exit 0
    # インターフェース名がPPPoEのものでなければ終了
    [ "$INTERFACE" = wanppp ] || exit 0
    # pppoe-wanpppのIPv4アドレスを取得
    pppoeaddr=$(ip -4 addr show pppoe-wanppp | head -2 | tail -1 | awk '{print $2}')
    # ログに吐く
    logger -t "DDNS - PPPoE IP" $pppoeaddr
    # DDNSもどきを叩く
    /root/vd-dns-util/vd-ddns_v4.pl 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' example.com $pppoeaddr hoge fuga piyo
    # 結果をログに吐きたいが何故か動いていない
    if [ $? -eq 0 ]; then
    logger -t "DDNS - UPDATE SUCCEED"
    else
    logger -t "DDNS - UPDATE FAIL"
    fi
   

4. PPPoEインターフェスをRestart

5. Value-Domainのコンパネで指定したドメインのaレコードが更新されていることを確認

備考

一般的にDNSレコードの浸透時間は更新前に浸透していたTTLに依存し、Value DomainのAPI経由で普段から操作している場合は120秒以下にならないため、最大120秒のダウンタイムが発生するが、理論上は公式のDDNS機能と大差ないはずと思われる。

aレコードのみの対応にしているのは私の環境だとIPv6は変動しないが、v4はそれなりの頻度で変わるためだ。

運用しているMastodonのv4が変わったのに気づかないまま疎通できないインスタンスが出てくることがしばしばあり、手動で対応するのが手間なのと、毎回一日くらい気づくのに遅れるので今回自動化に踏み切った。前々からやり勝ったのだが、中々腰が重く進んでいなかった。

そもそもこの手のものは監視システムで検知できて然るべきなので、おいおい監視システムの構築もしていきたいところだ。

• 確認環境
• やり方
• 増加する容量

確認環境

OpenWrt 24.10.0

やり方

opkg install perl
opkg install perlbase-essential
opkg install perlbase-json-pp
opkg install perlbase-scalar
opkg install perlbase-xsloader
opkg install perlbase-dynaloader
opkg install perlbase-list
opkg install perlbase-bytes
opkg install perlbase-findbin
opkg install perlbase-http-tiny

# OpenWrtにはPerlのSSLモジュールがないので親切な人が作ってくれてるものを使わせていただく
# https://jw2013.github.io/openwrt-packages/
opkg install libustream-mbedtls
wget https://jw2013.github.io/openwrt-packages/public.key
opkg-key add public.key
echo 'src/gz pkgs-by-jw2013 https://jw2013.github.io/openwrt-packages/24.10/x86_64' >> /etc/opkg/customfeeds.conf
opkg update
opkg install perl-net-ssleay
opkg install perl-io-socket-ssl
rm public.key

増加する容量

キビバイトやメビバイトのバイト変換やトータルビバイトはLLMに換算させた欠化を書いているので誤りが混ざっている可能性がある。大まかには合っていると思うが…。

Matomoは標準では直帰ユーザーの滞在時間が取れないが、それをできるようにする方法。

実施前	実施後

確認環境

Matomo Version 5.7.1

やり方

トラッキングコードに_paq.push(['enableHeartBeatTimer', 10]);を追加するだけ。

公式ドキュメントを読む限り、これをすることで10秒以上閲覧した場合に滞在時間が取れるようになると思われる。なお、HeartBeatTimerという名前だが、眺めてみた感じ定期的にAPIリクエストを送ったりはしていないようだった。

取り敢えず10秒以下は0と同じでいいと思ったので10にしておくことにした。ビジット継続時間単位のビジットでも11秒以上の敷居があるので、キリもいい。11秒にしたほうがよりノイズが減り、正確かもしれないが、個人的には運用上10秒が取れても害はないので、細かいことは気にしないでおく。

なお、かつては名前の通り指定時間にポーリングしていたようだ。また5秒未満を指定しても機能しないらしい。

コードの追加例

 <!-- Matomo -->
 <script>
   var _paq = window._paq = window._paq || [];
   /* tracker methods like "setCustomDimension" should be called before    "trackPageView" */
   _paq.push(['trackPageView']);
   _paq.push(['enableLinkTracking']);
   (function() {
     var u="https://analytics.example.com/";
     _paq.push(['setTrackerUrl', u+'matomo.php']);
     _paq.push(['setSiteId', '1']);
+    _paq.push(['enableHeartBeatTimer', 10]);
     var d=document, g=d.createElement('script'), s=d.getElementsByTagName ('script') [0];
     g.async=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s);
   })();
 </script>
 <!-- End Matomo Code -->

あとがき

公式ドキュメントの説明が薄いので、具体的にどう処理されているかはソースコードを読まないとわからないが、取り敢えず直帰ユーザーの滞在時間が見れるようになったので良かった。

一律で0sだと、内容を見ているユーザーと見てないユーザーが区別できないので、ここが分かるのは便利だ。

因みにGoogle Analyticsでも直帰は0秒扱いらしいが、そもそも最近この項目自体が削除されて、別概念に置き換わったらしい。

こういったことを踏まえると、やはり私のような個人サイト運営者にとってはMatomoは非常に便利なツールだ。

常連さんのアクセスを観察するのに標準のMatomoだとダッシュボード→利用状況→訪問数別のビジットである程度は見れるのだが、ビジット回数がベースでビジターがごちゃ混ぜになっていて辛い問題があったので、ビジターとビジットIDを一覧で見れるやつを作った。

コードはMatomo_Plugin_VisitorIdReportに置いてるので、もし使いたい人がいたら持っていって欲しい。

画面イメージはこんな感じ。

苦労したこと

公式の開発リファレンスが更新されてないのか、そのままでは上手くいかなかったり、あまり親切ではなく、どちらかと言えば有料プラグイン買ってねみたいな雰囲気だったので情報がなさ過ぎて苦労した。

ただ昨今はLLMという文明の利器があるので、大まかにはClaude Opus 4.6に書かせて、バグっていたらアタリを見つけて修正させて、どうにもならないところは手で直した。

推移グラフは実装方法が不明だったのでいったん放置しているが、ひとまずビジターID単位のビジット数が見れて、セグメント化ボタンからビジットの履歴を終えるところまでは作れたので満足だ。