今天早上忽然發現librenms的管理介面變成一片空白打不開

直接 ./validate.php 

PHP Fatal error:  Uncaught ReflectionException: Class "librenms-config" does not exist in /opt/librenms/vendor/laravel/framework/src/Illuminate/Container/Container.php:1122

Stack trace:

#0 /opt/librenms/vendor/laravel/framework/src/Illuminate/Container/Container.php(1122): ReflectionClass->__construct()

#1 /opt/librenms/vendor/laravel/framework/src/Illuminate/Container/Container.php(933): Illuminate\Container\Container->build()

#2 /opt/librenms/vendor/laravel/framework/src/Illuminate/Container/Container.php(864): Illuminate\Container\Container->resolve()

#3 /opt/librenms/vendor/laravel/framework/src/Illuminate/Foundation/helpers.php(138): Illuminate\Container\Container->make()

#4 /opt/librenms/LibreNMS/Util/Version.php(51): app()

#5 /opt/librenms/validate.php(160): LibreNMS\Util\Version::get()

#6 /opt/librenms/validate.php(83): print_header()

#7 [internal function]: {closure:/opt/librenms/validate.php:75}()

#8 {main}

Next Illuminate\Contracts\Container\BindingResolutionException: Target class [librenms-config] does not exist. in /opt/librenms/vendor/laravel/framework/src/Illuminate/Container/Container.php:1124

Stack trace:

#0 /opt/librenms/vendor/laravel/framework/src/Illuminate/Container/Container.php(933): Illuminate\Container\Container->build()

#1 /opt/librenms/vendor/laravel/framework/src/Illuminate/Container/Container.php(864): Illuminate\Container\Container->resolve()

#2 /opt/librenms/vendor/laravel/framework/src/Illuminate/Foundation/helpers.php(138): Illuminate\Container\Container->make()

#3 /opt/librenms/LibreNMS/Util/Version.php(51): app()

#4 /opt/librenms/validate.php(160): LibreNMS\Util\Version::get()

#5 /opt/librenms/validate.php(83): print_header()

#6 [internal function]: {closure:/opt/librenms/validate.php:75}()

#7 {main}

  thrown in /opt/librenms/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 1124

Fatal error: Uncaught ReflectionException: Class "librenms-config" does not exist in /opt/librenms/vendor/laravel/framework/src/Illuminate/Container/Container.php:1122

Stack trace:

#0 /opt/librenms/vendor/laravel/framework/src/Illuminate/Container/Container.php(1122): ReflectionClass->__construct()

#1 /opt/librenms/vendor/laravel/framework/src/Illuminate/Container/Container.php(933): Illuminate\Container\Container->build()

#2 /opt/librenms/vendor/laravel/framework/src/Illuminate/Container/Container.php(864): Illuminate\Container\Container->resolve()

#3 /opt/librenms/vendor/laravel/framework/src/Illuminate/Foundation/helpers.php(138): Illuminate\Container\Container->make()

#4 /opt/librenms/LibreNMS/Util/Version.php(51): app()

#5 /opt/librenms/validate.php(160): LibreNMS\Util\Version::get()

#6 /opt/librenms/validate.php(83): print_header()

#7 [internal function]: {closure:/opt/librenms/validate.php:75}()

#8 {main}

Next Illuminate\Contracts\Container\BindingResolutionException: Target class [librenms-config] does not exist. in /opt/librenms/vendor/laravel/framework/src/Illuminate/Container/Container.php:1124

Stack trace:

#0 /opt/librenms/vendor/laravel/framework/src/Illuminate/Container/Container.php(933): Illuminate\Container\Container->build()

#1 /opt/librenms/vendor/laravel/framework/src/Illuminate/Container/Container.php(864): Illuminate\Container\Container->resolve()

#2 /opt/librenms/vendor/laravel/framework/src/Illuminate/Foundation/helpers.php(138): Illuminate\Container\Container->make()

#3 /opt/librenms/LibreNMS/Util/Version.php(51): app()

#4 /opt/librenms/validate.php(160): LibreNMS\Util\Version::get()

#5 /opt/librenms/validate.php(83): print_header()

#6 [internal function]: {closure:/opt/librenms/validate.php:75}()

#7 {main}

  thrown in /opt/librenms/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 1124

直接 gemini 後 開始修

cd /opt/librenms/scripts

./composer-wrapper.php install --no-dev

修完後再跑 ./validate.php 

來來回回好几次 然後根据回應處理後

再跑一次 ./daily.sh

確認沒問題後再重開一次

目前正常了

這几天有人問我有沒有碰過pve備分時會把sql server搞死的問題

用這麼久真的沒碰過

不過因為他們是從vmware轉到 pve

查了好几天

真的是vmware的問題

vmware把vss元件reg檔某個值改過了

所以linux發起fsfreeze-freeze的時候沒有權限可以執行

導致vss會報錯

然後出現timeout

但vss雖然有報錯但是有凍結db

也不知道怎麼搞得sql的tempdb就毀了

導致sql服務起不來

解決方法

磁碟檢查修正磁碟

然後把tempdb重建

vss權限加回network service

醬就正常了

librenms的php 官方建議要升到8.4以上了

比照之前記錄一下流程

列出之前 hold住的 package

apt-mark showhold

php-cli     php-curl  php-gd   php-json      php-mysql  php-snmp  php-zip php-common  php-fpm   php-gmp  php-mbstring  php-pear   php-xml

apt-mark unold php-cli     php-curl  php-gd   php-json      php-mysql  php-snmp  php-zip php-common  php-fpm   php-gmp  php-mbstring  php-pear   php-xml

移除先前版本

apt remove php8.3-zip php8.3-xml php8.3-snmp php8.3-readline php8.3-opcache php8.3-mysql php8.3-mbstring php8.3-gmp php8.3-common php8.3-curl php8.3-gd php8.3

安裝新版本

apt install php-cli     php-curl  php-gd   php-json      php-mysql  php-snmp  php-zip php-common  php-fpm   php-gmp  php-mbstring  php-pear   php-xml

設定timezone

/etc/php/8.4/cli/php.ini

date.timezone = Asia/Taipei

複制 /etc/php/8.3/fpm/pool.d/librenms.conf 到 /etc/php/8.4/fpm/pool.d

apt-mark hold

php-cli

php-common

php-curl

php-fpm

php-gd

php-gmp

php-json

php-mbstring

php-mysql

php-pear

php-snmp

php-xml

php-zip

php

重跑validate

出現

找了全部的檔案都沒找到這行

目前安裝的版本是 rrdtoold 1,7,2

最後找到是放在db裡

 select * from config where config_value like "%1.4.8%";

+-----------+-----------------+--------------+

| config_id | config_name     | config_value |

+-----------+-----------------+--------------+

|       820 | rrdtool_version | "1.4.8"      |

+-----------+-----------------+--------------+

1 row in set (0.001 sec)

直接update

MariaDB [librenms]>update config set config_value = '"1.5.5"' where config_id=820;

Query OK, 1 row affected (0.000 sec)

Rows matched: 1  Changed: 1  Warnings: 0

MariaDB [librenms]>

MariaDB [librenms]>

MariaDB [librenms]> select * from config where config_id=820;

+-----------+-----------------+--------------+

| config_id | config_name     | config_value |

+-----------+-----------------+--------------+

|       820 | rrdtool_version | "1.5.5"      |

+-----------+-----------------+--------------+

1 row in set (0.000 sec)

再跑validate就沒出現了

grafana升到 13.1.1 時出現以下問題

dpkg -i grafana-enterprise_13.1.1_29761037902_linux_amd64.deb

(Reading database ... 42034 files and directories currently installed.)

Preparing to unpack grafana-enterprise_13.1.1_29761037902_linux_amd64.deb ...

Unpacking grafana-enterprise (13.1.1) over (13.1.0) ...

Setting up grafana-enterprise (13.1.1) ...

mv: cannot overwrite '/var/lib/grafana/plugins-bundled': Directory not empty

dpkg: error processing package grafana-enterprise (--install):

 installed grafana-enterprise package post-installation script subprocess returned error exit status 1

Errors were encountered while processing:

 grafana-enterprise

解決方法

systemctl stop grafana-server

cd /var/lib/grafana/

mv plugins-bundled plugins-bundled_20260804

dpkg --configure -a

今天早上來看到昨天的PVE備份沒成功

備分到 192.168 段nas的都沒成功

因為我的几器也是 192.168

一樣ping不到pbs

但跟host在同一段的ip使用都沒問題

第一次碰到這種

可能的原因應該是上週 kernel 升到 7.0.14-5

但在某些 host 又沒問題

先把guest移到沒問題的host

再把有問題host先開回舊kernel試看看

使用 proxmox-boot-tool

列出目前 kernel

proxmox-boot-tool kernel list

pin 回舊kernel

proxmox-boot-tool kernel pin 7.0.14-4-pve
proxmox-boot-tool refresh
reboot

之後要解除使用 unpin
proxmox-boot-tool kernel unpin
proxmox-boot-tool refresh


反覆試了几次 看起來也不是kernel的問題
目前只剩一台guest有問題 只能跑在固定的host
先醬 再觀察看看吧

最後查到是arp的問題
到網路設備 clear arp 

今天把vector 升到 v0.57.0 後

執行時出現以下 error

/root/vector-x86_64-unknown-linux-gnu/bin/vector -c /root/vector_data/vector.yaml

2026-07-14T23:42:39.795601Z  INFO vector::app: Log level is enabled. level="info"

2026-07-14T23:42:39.796124Z  INFO vector::app: Loading configs. paths=["/root/vector_data/vector.yaml"]

2026-07-14T23:42:39.824845Z ERROR vector::topology::builder: Configuration error. error=Sink "loki_output": template references event fields (["host"]) but has no literal string prefix to derive a confinement base from. Add a static prefix to your template, or set `dangerously_allow_unconfined_template_resolution: true` to opt out. internal_log_rate_limit=false

這次改版後出錯的主因，是 Vector 為了安全性預設會檢查模板（Template Syntax, 即 {{ ... }}）。當它看到 host: "{{ host }}" 時，因為前面沒有任何固定的字串字頭（Prefix），Vector 擔心會造成不安全的動態解析，所以主動擋了下來。

改一下yaml 

在 endpoint 跟 encoding 中間加上 dangerously_allow_unconfined_template_resolution

endpoint: "http://10.0.0.1:3100"

    # 加上此設定以允許無固定 Prefix 的動態 Template 解析

    dangerously_allow_unconfined_template_resolution: true

encoding:

大約講一下 zap docker 的版本及如何使用

版本有三種

Stable 

每個月第一週的週一更新

Weekly 

每週的週一更新

Nightly

每日更新

掃描方式有三種

Baseline Scan 

基本掃描

Full Scan 

完整掃描

API Scan 

API 掃描

如果想要使用每日更新版做完整掃描

docker run --cpus="18" --memory 32000MB --rm -v /tmp:/zap/wrk/:rw -t zaproxy/zap-nightly zap-full-scan.py -t https://aaa.com -r aaa.com.html

https://www.zaproxy.org/docs/docker/about/

昨天碰到的 ntopng 的問題

升到以下版本就解決了

ntopng 更新又出包

早上 6:01 更新後就死了

2026-07-12T06:01:49+0800 INFO ================================================================================

 Package             Architecture  Version                    Repository   Size

================================================================================

Upgrading:

 nprobe              x86_64        11.0.260711-8713           ntop        4.8 M

 ntop-license        x86_64        1.0-724                    ntop        668 k

 ntopng              x86_64        6.6.260711-28602           ntop         13 M

雖然 8:08有再出了一版更新 但還是沒用

2026-07-12T08:08:23+0800 INFO ===============================================================================

 Package           Arch        Version                  Repository        Size

===============================================================================

Upgrading:

 cento             x86_64      2.4.260712-1173          ntop             1.6 M

 n2disk            x86_64      3.8.260712-5580          ntop             1.7 M

 nprobe            x86_64      11.0.260712-8715         ntop             4.9 M

 ntap              x86_64      1.2.260712-131           ntop             644 k

 ntop-license      x86_64      1.0-728                  ntop             668 k

 ntopng            x86_64      6.6.260712-28602         ntop              13 M

 ntopng-data       noarch      6.6.260712-28602         ntop-noarch       60 M

這次的問題是daemon 活著

但 3000 沒 listen

先倒回備分 再等几天看看吧