2017/08/31

最近在玩librenms
介面看起來真的滿潮的
而且只要她可以辨認的mib
會把所有相關的資料都顯示出來
連USHA的資料都完全出現
包括電壓 負載 溫度....等
這方面比cacti好用很多
不過目前碰到的問題是還無法餵值來畫圖
另外就是一定要使用snmp來偵測裝置

在測的過程中出現一個狀況
就是alert有出現
email通知的設定也沒錯
但device如果down
在畫面上有看到alert
但就是沒收到mail
之後經過了8小時
才開始發mail








試了半天
還是一樣
後來想說去forum 問問
就在要發問時
系統說要先執行validate.php把結果一起po上去
那就先執行看看

./validate.php
====================================
Component | Version
--------- | -------
LibreNMS  | 1.31.02-3-g4683736
DB Schema | 205
PHP       | 7.0.22
MySQL     | 5.5.52-MariaDB
RRDTool   | 1.4.8
SNMP      | NET-SNMP 5.7.2
====================================

[FAIL]  We have found some files that are owned by a different user than librenms, this will stop you updating automatically and / or rrd files being updated causing graphs to fail.
        [FIX] chown -R librenms:librenms /opt/librenms
/opt/librenms/html/plugins/Weathermap/configs
/opt/librenms/html/plugins/Weathermap/configs/testing.conf
[OK]    Database connection successful
[OK]    Database schema correct
[WARN]  Your install is over 24 hours out of date, last update: Tue, 29 Aug 2017 18:53:05 +0000
[FAIL]  You have a different system timezone (CST) specified to the php configured timezone (UTC), please correct this.

果然有几個問題
一個是權限問題
我在想我是用官方提供的ova
為什麼會有這個問題
再來是時區
因為我有去改os的timezone
但php.ini沒改
難怪會晚了8小時才收到信
這個也改了
再來就是說我版本太舊
不是說每天會固定更新??
算了
手動跑一下daily.sh
目前alert發信看來正常了
再觀察看看

後記
權限改完後
刪除裝置時還是會出現














要嗎就再把rrd改成777
不然就用root去刪
算了
反正刪設備的機會也不多
碰到再用root刪吧
使用rsyslog 收資料時
預設會去反解來源的ip
可以修改以下參數停用
加上 -Q -x

範例

SYSLOGD_OPTIONS=”-c3 -Q -x”

https://ssorc.tw/1194

2017/08/25

今天收到了一個zip檔
但user說忘記密碼了
XD
找到fcrackzip這個有趣的東西
ubuntu安裝很簡單
sudo apt install fcrackzip

接下來下個指令 先試10個字範圍內

fcrackzip -b -c 'aA1!' -l 1-10 -u crack_file.zip

再來就是等了

http://topspeedsnail.com/fcrackzip-crack-zip-password/

2017/08/24

今天要登入awacs(網管軟体)時
出現無法連接的訊息
登入主机發現mariadb的daemon不見了
systemctl restart mariadb也起不來
看了一下 /var/log/mariadb/mariadb.log 發現以下的記錄

170824 19:02:01  InnoDB: Page checksum 2583736692 (32bit_calc: 3902863637), prior-to-4.0.14-form checksum 2992650943
InnoDB: stored checksum 218772529, prior-to-4.0.14-form stored checksum 775370784
InnoDB: Page lsn 825440558 909582385, low 4 bytes of lsn at page end 825373998
InnoDB: Page number (if stored to page already) 775303712,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 775041840
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 7.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.

按照說明
在/etc/my.cnf 加上

[mysqld]
innodb_force_recovery = 1

重啟mariadb

再查一下log

170824 19:02:01  InnoDB: Error: space id and page n:o stored in the page
InnoDB: read in are 1553519:2, should be 1553541:2!
170824 19:02:01  InnoDB: Error: space id and page n:o stored in the page
InnoDB: read in are 1553519:3, should be 1553541:3!

InnoDB: Apply batch completed
InnoDB: Starting in background the rollback of uncommitted transactions
170824 19:02:01  InnoDB: Rolling back trx with id 127203F, 451 rows to undo
170824 19:02:01  InnoDB: Waiting for the background threads to start

InnoDB: Rolling back of trx id 127203F completed
170824 19:02:01  InnoDB: Rollback of non-prepared transactions completed
170824 19:02:02 Percona XtraDB (http://www.percona.com) 5.5.40-MariaDB-36.1 started; log sequence number 653240202086
170824 19:02:02 InnoDB: !!! innodb_force_recovery is set to 1 !!!
170824 19:02:02 [Note] Plugin 'FEEDBACK' is disabled.
170824 19:02:02 [Note] Server socket created on IP: '0.0.0.0'.
170824 19:02:02 [Note] Event Scheduler: Loaded 0 events
170824 19:02:02 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.41-MariaDB'  socket: '/home/Alopex/mysql/mysql.sock'  port: 3306  MariaDB Server
InnoDB: A new raw disk partition was initialized or
InnoDB: innodb_force_recovery is on: we do not allow
InnoDB: database modifications by the user. Shut down
InnoDB: mysqld and edit my.cnf so that newraw is replaced
InnoDB: with raw, and innodb_force_... is removed.
InnoDB: A new raw disk partition was initialized or
InnoDB: innodb_force_recovery is on: we do not allow
InnoDB: database modifications by the user. Shut down
InnoDB: mysqld and edit my.cnf so that newraw is replaced
InnoDB: with raw, and innodb_force_... is removed.

看來是修好了
不過user還是不能用

InnoDB: innodb_force_recovery is on: we do not allow
InnoDB: database modifications by the user. Shut down
InnoDB: mysqld and edit my.cnf so that newraw is replaced
InnoDB: with raw, and innodb_force_... is removed.

要再把

[mysqld]
innodb_force_recovery = 1

mark掉再重開

目前看來是正常了
再觀察看看


https://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html

2017/08/23

今天早上使用proxmox裡的guest測了一下io

host

ProLiant DL380p Gen8

raid card














guest os

linux mint 直接使用cd boot 後執行 gnome-disks 跑benchmark


datastore 使用 xfs























datastore 使用 zfs (zfs是使用由raid card做raid 5 出來之後再用 raidz0)




















是不是要為了 remote replication 而浪費這些效能
就自己決定囉

補充硬碟資料


















每台host 上共有12個如上的hd
1個hot spare 另外11個做raid 5

另外再補充在pc上測試的結果

pc上的hd資料如下
3個500G SATA 直接接在主机板上



下圖為測試結果






2017/08/10

zfs 更換disk 流程如下

若disk已損壞
zpool status 會出現損壞disk的id
插上新disk後
執行
zpool replace fail_disk_id /dev/sdx

畫面如下

















若disk尚未損壞但已經有問題必須下線

則必需手動offline

zpool offline aaa /dev/sdb
插入新disk後
執行
zpool replace aaa /dev/sdb /dev/sdx

畫面如下


在ubuntu 16.04上建立zfs的流程如下

sudo zpool create mypool raidz /dev/sdb /dev/sdc /dev/sdd

以上指令為建立一個raidz (raid 5)的pool

pool type請參考以下連結

https://wiki.ubuntu.com/ZFS/ZPool

但碰到一個問題 就是每次開机不會自動把zpool mount進來

目前的解決方法是在 /etc/rc.local 加上以下二行

zpool import mypool

zfs mount -a

2017/08/08

如果graylog是直接使用ova
那heap space預設只有 1.4 G
效能不好
所以當os加完ram後要再調整

vi /etc/graylog/graylog-settings.json

修改以下參數

"custom_attributes": {
     "graylog-server": {
       "memory": "2000m"
     },
     "elasticsearch": {
       "memory": "2000m"
     }
   }

改好後

cp /opt/graylog/conf/graylog.conf /opt/graylog/conf/graylog.conf_bck

sudo graylog-ctl reconfigure

mv /opt/graylog/conf/graylog.conf_bck /opt/graylog/conf/graylog.conf

sudo graylog-ctl restart

http://docs.graylog.org/en/2.3/pages/configuration/graylog_ctl.html#graylog-ctl-advanced

2017/12/21 後記

在reconfigure之前記得要先把 /opt/graylog/conf/graylog.conf 先備分
因為reconfigure會把graylog.conf恢復成原始值
記得把備份檔還原後再 graylog-ctl restart

2017/08/04

proxmox升到5版後開始使用zfs
但碰到了二個問題
一個是效能感覺上跟之前使用ext4或xfs差很多
另外就是zfs會一直吃ram 直到把ram全吃完
查了很多資料
都是建議加SSD來當zfs的cache
但目前沒有多餘的預算
後來找到一份官方文件

https://pve.proxmox.com/wiki/ZFS_on_Linux

依照說明
先把zfs的ram使用量限制為10G (文件為8G)
另外限制swap的使用量

vi /etc/modprobe.d/zfs.conf

options zfs zfs_arc_max=10737418240

update-initramfs -u

vi /etc/sysctl.conf

vm.swappiness = 10

改完後記得要reboot

目前看來好多了
再觀察看看
升到proxmox 5後搭配zfs提供了一個很好的功能
guest replication
但發現一個問題
偶爾會出現sync fail的狀況
而且一但發生
就再也沒辦法再sync成功









查了一下 forum
目前的解決方法就是把在遠端的replication 資料砍了
然後再重新sync一次

zfs destroy rpool/data/vm-112-disk-1

注意千萬不要砍錯了