kk的blog

2026/08/29

ntopng又發生更新後無法執行的情況

2026/08/28

maltrail 3.2版開始正式把 sensor.py拿掉了

改用 rust 寫的 mailtrail-sensor

以下是操作流程

# 1. 安裝必要套件（以 Ubuntu/Debian 為例）

sudo apt-get update

sudo apt-get install build-essential libpcap-dev cargo

# 2. 編譯 Rust 版 Sensor

cd maltrail

cargo build --release --manifest-path sensor/Cargo.toml

# 3. 授予原生的網路抓包權限（避免直接以 root 長期執行）

sudo setcap cap_net_raw,cap_net_admin=eip sensor/target/release/maltrail-sensor

#4, 設定監聽介面

sed -i 's/^MONITOR_INTERFACE[[:space:]]\+any$/MONITOR_INTERFACE eth1/' /path/mailtrail.conf

#5. 設定syslog

echo "SYSLOG_SERVER 10.0.0.1:514" >> maltrail.conf

# 6. 執行 Sensor

./sensor/target/release/maltrail-sensor

https://github.com/stamparm/maltrail/releases

2026/08/13

今天早上忽然發現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

找了一下資料後開始修

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

醬就正常了

2026/08/09

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]> 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就沒出現了

2026/08/04

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

2026/07/20

今天早上來看到昨天的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

2026/07/15

今天把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:

訂閱：文章 (Atom)