kk的blog

2020/02/27

收到librenms 更新錯誤的訊息

Updating to latest codebase FAIL
error: Your local changes to the following files would be overwritten by merge:
html/js/lang/de.js
html/js/lang/en.js
html/js/lang/fr.js
html/js/lang/ru.js
html/js/lang/uk.js
html/js/lang/zh-TW.js
Please, commit your changes or stash them before you can merge.
Aborting

解決方法如下

/opt/librenms/scripts/github-remove -d

再重跑一次 daily.sh

2020/02/24

最近想拿raspberry pi 來當thin client
本來是想用spice
但mouse 一直有 lag的問題
改用rdp

raspberry用的是raspbian

碰到了開机要叫起rdesktop的問題
查了很多方法都不成功
最後記一下可行的方法

在
/etc/xdg/lxsession/LXDE-pi/autostart
最後一行加上
@lxterminal

在 /home/pi/.bashrc 最後一行加上

rdesktop -u user 10.0.0.1 -f -r sound:local -p1234

方法二

vi /home/pi/rdp.sh

rdesktop -u user 10.0.0.1 -f -r sound:local -p1234

cp /etc/xdg/lxsession/LXDE-pi/autostart /home/pi/.config/lxsession/LXDE-pi/autostart

vi /home/pi/.config/lxsession/LXDE-pi/autostart
在最後加上

@lxterminal -e '/home/pi/rdp.sh'

若win10的使用者未設定密碼
需要更改原則才能連線
而且開啟連線未登入
15秒就會自動斷線
所以建議user要設定密碼

持續測試發現一個問題
如果我把vm關掉
rdesktop會整個畫面卡住不會自己關掉

於是使用xfreerdp

xfreerdp /v:10.0.0.1 /u:user /p:1234 /cert-ignore /f

xfreerdp /v:10.0.0.1 /u:user /p:1234 /cert-ignore /f /sound

再看看有什麼問題

2020/01/08

目前在suricata設定白名單的做法

在/etc/suricata/rules新增 pass.rules
內容如下

pass ip 10.0.0.1 any -> any any (msg:"pass all traffic from 10.0.0.1"; sid:9999999;)
pass ip 10.0.0.2 any -> any any (msg:"pass all traffic from 10.0.0.2"; sid:9999998;)

修改紅字部分
注意 sid 不可重複

在 /etc/suricata/suricata.yaml 把上面的rules引用進來

systemctl restart suricata

最近几次cacti的更新都一直有問題
所以都要倒回之前的備份
手動修改後
再做一次
這次是要把
/usr/share/cacti/install/upgrades/1_2_8.php
內的這行刪掉
db_install_execute('ALTER TABLE host_snmp_cache MODIFY COLUMN snmp_index VARCHAR(255) NOT NULL default ""');

查了一下好像目前的mariadb的版本沒辦法醬操作要升版

今天先把mariadb升級
先保留php-5.4.16-46.1.el7_7.x86_64
下次cacti升級再看看有什麼問題
再來處理

新增以下檔案

/etc/yum.repos.d/mariadb.repo

內容如下

[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.4/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

改好後直接 yum -y update

mariadb就會直接升了

再來要 mv /etc/my.cnf /etc/my.cnf_old 不然db會起不來

接下來照文件改

Add variables in the [mysqld] section.

collation-server = utf8mb4_unicode_ci
character-set-server=utf8mb4
max_heap_table_size = 64M
tmp_table_size = 64M
join_buffer_size = 64M
innodb_file_format = Barracuda
innodb_large_prefix = 1
innodb_flush_log_at_timeout = 3
innodb_buffer_pool_size = 1GB
innodb_buffer_pool_instances = 10
# Based on what type for storage you use. The below values are for SSD drives.
# Change it if Cacti reports issues during the installation
innodb_read_io_threads = 32
innodb_write_io_threads = 16
innodb_io_capacity = 5000
innodb_io_capacity_max = 10000

db重啟就好了

再把這個補上去

ALTER TABLE host_snmp_cache MODIFY COLUMN snmp_index VARCHAR(255) NOT NULL default ""

https://www.itzgeek.com/how-tos/linux/centos-how-tos/monitor-network-using-cacti-with-centos-7-rhel-7.html

snort suricata
gryalog 的 extractor

suricata

%{WORD:source} %{WORD:UNWANTED}\[%{DATA:UNWANTED}\]: \[%{DATA:suricata_sig_id}\] %{DATA:suricata_msg} \[Classification\: %{DATA:suricata_classification}\] \[Priority\: %{DATA:suricata_priority}\] \{%{DATA:protocol}\} %{IPV4:src_ip}\:%{DATA:srcport} \-\> %{IPV4:dst_ip}\:%{DATA:dstport}$

snort

\[%{DATA:snort_sig_id}\] %{DATA:snort_msg} \[Classification\: %{DATA:snort_classification}\] \[Priority\: %{DATA:snort_priority}\] \{%{DATA:protocol}\} %{IPV4:src_ip}\:%{DATA:srcport} \-\> %{IPV4:dst_ip}\:%{DATA:dstport}$

2020/01/04

目前手边還有一台 graylog2 的 ova
因為是 ubuntu 14.04的版本
而且 elasticsearch 也EOL
之前就一直想upgrade
只是一直沒動作

因為有10T的資料
不太可能花時間去搬
目前想保留然後再架一台新的graylog3 ova

graylog2改ip要重跑 graylog-ctl reconfigure

但跑了二次跑完後就掛了

所以改用另一個方式
在graylog2上起一個output output 把資料送到 graylog3
同時保留二份
然後graylog2再慢慢砍資料
最後把graylog2 關几
把graylog3改成graylog2的ip
graylog3改ip只要重開几就好
不用再其他設定很方便

找出最舊index並刪除的 shell 如下

#!/bin/bash

i=`/usr/bin/curl -u admin:passwd 'http://10.0.0.1:9200/_cat/indices/graylog*?v'|grep close|awk '{print $2}'|sort -rn -t_ -k 2|tail -n 1`
echo $i
/usr/bin/curl -XDELETE "http://10.0.0.1:9200/$i/"

另外 graylog3 ova 使用的是 ubuntu 18.04
預設的網路設定方式是 netplan
用的實在不順
如果要改回 /etc/network/interfaces
要先安裝 ifupdown

sudo apt install ifupdown

設定好 /etc/network/interfaces

再 rm -rf /etc/netplan/*

重開几即可

2020/01/03

proxmox 預設使用 mtu 1500
在10G的環境要改為 9000
在以下檔案加上紅色的那行

/etc/network/interfaces

auto vmbr0
iface vmbr0 inet static
address 10.0.0.1
netmask 255.0.0.0
gateway 10.0.0.254
bridge_ports enp11s0
bridge_stp off
bridge_fd 0
mtu 9000

如果是在 1G 10G 混用的環境下要注意
目前發現調完後會出現無法掛載某些nfs的情況

2019/12/28

又到了半年一度的弱掃時間
使用的是kali linux 2019.4 的版本
本來是想裝完後直接 apt install openvas
可是用 Kali Linux Light 64-Bit 這個iso裝完後
竟然找不到 openvas
算了
只好再繼續用virtualbox的image
安裝執行都OK

這次的問題是出現了不少FP
所以必須在管理介面上調整

首先點進 scan - report
再點進要調整的report
就會看到所有的細項報告
接下來點撃該細項報告最右方的圖示

就可以調整new severity

2019/12/05

今天偶然發現librenms好像好久沒更新了
一看果然從6月後都沒更新
查了一下官網
最新版本是11月
馬上下指令
daili.sh
也沒有更新的訊息
再去communuty看了一下
現在要醬下指令更新了

su - librenms
git pull
./daily.sh

之前只要更新大多有問題
這次做完還好
再觀察看看

https://community.librenms.org/

2019/11/28

這几天在玩MHN

感覺還不錯
不過有些地方要注意
試了好久

首先裝server
依照官網的說明沒什麼問題
我是用 ubuntu 18.04

再來是佈署 sensor

網頁介面上有提供deploy的script

官網上有提到有些sensor可以裝在centos
不過網頁介面上的都是for ubuntu跟 respberry pi
有很多sensor可以選擇
不同sensor有不同的功能
不過不是每個都可以用
這地方試了好久

最後我選了 Dionaea
官網上是說只能裝在 Ubuntu 14.04/Centos 7
其他版本有問題
不過我裝在ubuntu 18.04是ok的
只是安裝過程中碰到以下的問題

E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/universe/libe/libemu/libemu2_0.2.0+git20120122-1.2build1_amd64.deb 403 Forbidden [IP: 91.189.88.173 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

最後解決的方法是直接下載這個檔然後 dpkg -i
之後就沒問題了
介面還可以接受
資料是放在mongodb裡
也提供 rest可以撈
不過沒找到完整文件
另外就是直接使用mongoexport把資料撈出來
要注意的是mongodb時間是ISODate
如果用bash shell要記得轉換時間

date -u -Ins

每十分鐘從mongodb撈出資料

#!/bin/bash

date -d '10 mins ago' -u -Ins |cut -d ',' -f 1 > /tmp/time
echo "DBQuery.shellBatchSize = 3000000" > /tmp/get10min.js
echo "use mnemosyne" >> /tmp/get10min.js
echo 'db.session.find({"timestamp":{$gt:ISODate("'`cat /tmp/time`'")}})' >> /tmp/get10min.js

mongo < /tmp/get10min.js > /tmp/mhn_10min_data

https://github.com/pwnlandia/mhn

https://github.com/pwnlandia/mhn/wiki/List-of-Supported-Sensors

https://github.com/pwnlandia/mhn/wiki/MHN-REST-APIs

https://github.com/pwnlandia/mhn/wiki/Exporting-Honeypot-Data-from-MHN

https://www.itread01.com/content/1545640216.html

2019/11/22

今天在下grep 指令時出現以下的訊息

Binary file /tmp/test matches

查了一下說是因為檔案是binary file 無法執行grep 指令
明明就是text file
解決方式是強制指定為txt
指令

grep -a abc /tmp/test

2019/11/21

目前有三台ES

在graylog上設定

shards = 3

replicas = 1

在index set看到每天的量大約 100G左右

對應到每一台ES的空間大約是 70G

所以算法就是

100G * 2 = 200 G

然後再分配到3台

200G / 3 就大約等於 70G 因為還要加上 index 所以會大一些

2019/11/13

今天在使用mutt時一直出現以下的錯誤
找了半天還是沒有答案

mutt -s 'test' abc@de.com -a /tmp/test < test

SMTP session failed: 500 5.5.2 Error: bad UTF-8 syntax
Could not send the message.

改用

/usr/bin/mail -a /tmp/test1 -a /tmp/test2 -S smtp="10.0.0.1:25" -r "from@dde.com" -s 'test' to@de.com < test

https://www.binarytides.com/linux-mailx-command/

2019/11/06

剛剛在設定.muttrc從hinet寄信的時候

設ip不能寄
set smtp_url = "smtp://168.95.4.10:25/"

要設fqdn才能寄

set smtp_url = "smtp://msa.hinet.net:25/"

什麼怪事都有

http://nengfang.blogspot.com/2014/07/hinet-isp-smtp-server.html

2019/11/01

今天模擬在一台graylog server 三個ES node的環境

然後當有一台ES fail時要怎麼處理

首先我們先看一下目前ES的狀況

有三個node

status也是green

curl -XGET http://192.168.12.201:9200/_cluster/health?pretty

{

"cluster_name" : "graylog",

"status" : "green",

"timed_out" : false,

"number_of_nodes" : 3,

"number_of_data_nodes" : 3,

"active_primary_shards" : 11,

"active_shards" : 14,

"relocating_shards" : 0,

"initializing_shards" : 0,

"unassigned_shards" : 0,

"delayed_unassigned_shards" : 0,

"number_of_pending_tasks" : 0,

"number_of_in_flight_fetch" : 0,

"task_max_waiting_in_queue_millis" : 0,

"active_shards_percent_as_number" : 100.0

}

再來看一下目前所有shards的狀況

curl -XGET 192.168.12.203:9200/_cat/shards

gl-events_0 3 p STARTED 0 230b 192.168.12.202 es-node-02

gl-events_0 2 p STARTED 0 230b 192.168.12.201 es-node-1

gl-events_0 1 p STARTED 0 230b 192.168.12.203 es-node-03

gl-events_0 0 p STARTED 0 230b 192.168.12.202 es-node-02

graylog_3 2 r STARTED 1 7kb 192.168.12.203 es-node-03

graylog_3 2 p STARTED 1 7kb 192.168.12.201 es-node-1

graylog_3 1 r STARTED 1 7kb 192.168.12.202 es-node-02

graylog_3 1 p STARTED 1 7kb 192.168.12.201 es-node-1

graylog_3 0 p STARTED 1 7kb 192.168.12.202 es-node-02

graylog_3 0 r STARTED 1 7kb 192.168.12.203 es-node-03

gl-system-events_0 3 p STARTED 0 230b 192.168.12.203 es-node-03

gl-system-events_0 2 p STARTED 0 230b 192.168.12.202 es-node-02

gl-system-events_0 1 p STARTED 0 230b 192.168.12.201 es-node-1

gl-system-events_0 0 p STARTED 0 230b 192.168.12.203 es-node-03

我們關掉其中一個ES node 192.168.12.202 模擬故障

查看整個cluster狀況

nodes變成2

status也變為red

curl -XGET http://192.168.12.201:9200/_cluster/health?pretty

{

"cluster_name" : "graylog",

"status" : "red",

"timed_out" : false,

"number_of_nodes" : 2,

"number_of_data_nodes" : 2,

"active_primary_shards" : 8,

"active_shards" : 9,

"relocating_shards" : 0,

"initializing_shards" : 0,

"unassigned_shards" : 5,

"delayed_unassigned_shards" : 5,

"number_of_pending_tasks" : 0,

"number_of_in_flight_fetch" : 0,

"task_max_waiting_in_queue_millis" : 0,

"active_shards_percent_as_number" : 64.28571428571429

}

再來看一下shards的狀況

192.168.12.202這個node己經不見了

而且上面的shards 變成 UNASSIGNED

curl -XGET 192.168.12.203:9200/_cat/shards

gl-system-events_0 3 p STARTED 0 261b 192.168.12.203 es-node-03

gl-system-events_0 2 p UNASSIGNED

gl-system-events_0 1 p STARTED 0 261b 192.168.12.201 es-node-1

gl-system-events_0 0 p STARTED 0 261b 192.168.12.203 es-node-03

graylog_3 2 r STARTED 1 7kb 192.168.12.203 es-node-03

graylog_3 2 p STARTED 1 7kb 192.168.12.201 es-node-1

graylog_3 1 r STARTED 1 7kb 192.168.12.203 es-node-03

graylog_3 1 p STARTED 1 7kb 192.168.12.201 es-node-1

graylog_3 0 p STARTED 1 7kb 192.168.12.203 es-node-03

graylog_3 0 r STARTED 1 7kb 192.168.12.201 es-node-1

gl-events_0 3 p UNASSIGNED

gl-events_0 2 p STARTED 0 261b 192.168.12.201 es-node-1

gl-events_0 1 p STARTED 0 261b 192.168.12.203 es-node-03

gl-events_0 0 p UNASSIGNED

找一台机器重裝ES後並重新加入cluster

先看一下狀況

nodes己經回來變成3了

可是status還是red

curl -XGET http://192.168.12.201:9200/_cluster/health?pretty

{

"cluster_name" : "graylog",

"status" : "red",

"timed_out" : false,

"number_of_nodes" : 3,

"number_of_data_nodes" : 3,

"active_primary_shards" : 8,

"active_shards" : 11,

"relocating_shards" : 0,

"initializing_shards" : 0,

"unassigned_shards" : 3,

"delayed_unassigned_shards" : 0,

"number_of_pending_tasks" : 0,

"number_of_in_flight_fetch" : 0,

"task_max_waiting_in_queue_millis" : 0,

"active_shards_percent_as_number" : 78.57142857142857

}

再來看shards的狀況

還是 UNASSIGNED 並沒有復原

curl -XGET 192.168.12.203:9200/_cat/shards

gl-system-events_0 3 p STARTED 0 261b 192.168.12.203 es-node-03

gl-system-events_0 2 p UNASSIGNED

gl-system-events_0 1 p STARTED 0 261b 192.168.12.201 es-node-1

gl-system-events_0 0 p STARTED 0 261b 192.168.12.203 es-node-03

graylog_3 2 r STARTED 1 7kb 192.168.12.203 es-node-03

graylog_3 2 p STARTED 1 7kb 192.168.12.201 es-node-1

graylog_3 1 r STARTED 1 7kb 192.168.12.203 es-node-03

graylog_3 1 p STARTED 1 7kb 192.168.12.201 es-node-1

graylog_3 0 p STARTED 1 7kb 192.168.12.203 es-node-03

graylog_3 0 r STARTED 1 7kb 192.168.12.201 es-node-1

gl-events_0 3 p UNASSIGNED

gl-events_0 2 p STARTED 0 261b 192.168.12.201 es-node-1

gl-events_0 1 p STARTED 0 261b 192.168.12.203 es-node-03

gl-events_0 0 p UNASSIGNED

查了資料說可以 reroute share

但實作上有問題無法執行

http://www.wklken.me/posts/2015/05/23/elasticsearch-issues.html

https://toutiao.io/posts/na8zgp/preview

目前試出來的做法是先關掉graylog server

systemctl stop graylog-server.service

接下來把所有的 UNASSIGNED 砍了

curl -XDELETE '192.168.12.201:9200/gl-system-events_0/'

curl -XDELETE '192.168.12.201:9200/gl-events_0'

砍完後再去看shards

curl -XGET 192.168.12.203:9200/_cat/shards

graylog_3 2 r STARTED 1 7kb 192.168.12.203 es-node-03

graylog_3 2 p STARTED 1 7kb 192.168.12.201 es-node-1

graylog_3 1 r STARTED 1 7kb 192.168.12.202 es-node-02

graylog_3 1 p STARTED 1 7kb 192.168.12.201 es-node-1

graylog_3 0 r STARTED 1 7kb 192.168.12.202 es-node-02

graylog_3 0 p STARTED 1 7kb 192.168.12.203 es-node-03

這個是原本的資料檔

而且有設定 Index replicas

重啟graylog server

graylog會把剛剛砍掉的 gl-system-events_0 gl-events_0 建回來

收集的資料是放在 graylog_* 所以不會有影響

再看一次shards

全部都正常了

curl -XGET 192.168.12.203:9200/_cat/shards

gl-system-events_0 3 p STARTED 0 230b 192.168.12.203 es-node-03

gl-system-events_0 2 p STARTED 0 230b 192.168.12.202 es-node-02

gl-system-events_0 1 p STARTED 0 230b 192.168.12.201 es-node-1

gl-system-events_0 0 p STARTED 0 230b 192.168.12.203 es-node-03

graylog_3 2 r STARTED 1 7kb 192.168.12.203 es-node-03

graylog_3 2 p STARTED 1 7kb 192.168.12.201 es-node-1

graylog_3 1 r STARTED 1 7kb 192.168.12.202 es-node-02

graylog_3 1 p STARTED 1 7kb 192.168.12.201 es-node-1

graylog_3 0 r STARTED 1 7kb 192.168.12.202 es-node-02

graylog_3 0 p STARTED 1 7kb 192.168.12.203 es-node-03

gl-events_0 3 p STARTED 0 230b 192.168.12.202 es-node-02

gl-events_0 2 p STARTED 0 230b 192.168.12.201 es-node-1

gl-events_0 1 p STARTED 0 230b 192.168.12.203 es-node-03

gl-events_0 0 p STARTED 0 230b 192.168.12.202 es-node-02

所以記得 Configure Index Set 要設定Index replicas 至少為1

Index shards的數量就根据你ES node的數量來設定

如果ES node 有三個就設定為3

2019/10/26

Load Balancing in NGINX

今天有人問graylog的三個node怎麼做load balance
想到之前玩過haproxy
可是查了一下資料
haproxy不支援UDP的load balance
nginx目前已經有支援了
設定方法如下

udp loadbalance

# Load balance UDP‑based DNS traffic across two servers
stream {
    upstream dns_upstreams {
        server 192.168.1.1:53;
        server 192.168.1.2:53;
    }

    server {
        listen 53 udp;
        proxy_pass dns_upstreams;
        proxy_timeout 1s;
        proxy_responses 1;
        error_log logs/dns.log;
    }
}

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

tcp load balance


upstream mytest {

server 192.168.2.1 weight=3;

server 192.168.2.2 weight=2;

}



server {

listen       443 ssl;

server_name  my.test.tw;



access_log /var/log/nginx/my.test.tw.access.log main;

error_log /var/log/nginx/my.test.tw.error.log warn;



ssl_certificate my.test.tw.crt;

ssl_certificate_key my.test.tw.key;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;



location / {

proxy_pass http://mytest;

proxy_set_header   Host    $host;

proxy_set_header   X-Real-IP   $remote_addr;

proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;

}

}

https://blog.dtask.idv.tw/Nginx/2018-07-31/

https://www.nginx.com/blog/announcing-udp-load-balancing/

proxmox mail gateway 的 clamav-daemon
時不時就會出現fail的狀況
因為pmg本來就有自我檢查機制
所以想說不管他
可是今天看到後
手動去重啟
又馬上fail
覺得很怪
查了一下log

Oct 26 06:39:53 mg kernel: [765738.983038] Memory cgroup stats for /lxc/124/ns/system.slice/clamav-freshclam.service: cache:1696KB rss:1100KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:528KB writeback:1056KB swap:660KB inactive_anon:720KB active_anon:356KB inactive_file:4KB active_file:4KB unevictable:0KB
Oct 26 06:39:53 mg kernel: [765738.983052] Memory cgroup stats for /lxc/124/ns/system.slice/clamav-daemon.service: cache:1508KB rss:1760KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:0KB writeback:660KB swap:0KB inactive_anon:0KB active_anon:0KB inactive_file:0KB active_file:0KB unevictable:0KB
Oct 26 06:39:53 mg kernel: [765738.983088] Memory cgroup stats for /lxc/124/ns/system.slice/clamav-daemon.service: cache:68KB rss:44KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:396KB writeback:0KB swap:0KB inactive_anon:0KB active_anon:0KB inactive_file:0KB active_file:0KB unevictable:0KB
Oct 26 06:39:53 mg kernel: [765738.983097] Memory cgroup stats for /lxc/124/ns/system.slice/clamav-daemon.service: cache:0KB rss:92KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:396KB writeback:0KB swap:132KB inactive_anon:0KB active_anon:0KB inactive_file:0KB active_file:0KB unevictable:0KB
Oct 26 06:39:53 mg kernel: [765739.020710] oom_reaper: reaped process 4167 (clamd), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Oct 26 06:39:53 mg systemd[1]: clamav-daemon.service: Main process exited, code=killed, status=9/KILL

找了相關文章
都說是ram不夠的問題
目前是2G
先加到4G看看吧

2019/10/25

graylog上的三個node 總有一個會時出現時不出現

查了一下log

發現一直出現以下的訊息

Did not find meta info of this node. Re-registering.

搜尋了一下

几乎講的都是因為server沒有對時的關係

所以如果有建cluster環境的

切記要注意對時

但是在vmware的環境中
設完chrony對時
還是一直會出現秒差
只能去修改參數

stable_master_timeout = 60000

預設值為2000 就是 2秒
目前先改為60秒再觀察看看
重啟graylog

後來想起來 vmware一直有時間不準的問題
想不到到現在還沒改善

https://community.graylog.org/t/graylog-2-2-cluster-issue/697

2019/10/22

使用LXC的proxmox mail gateway 發生不能logratate的解法

options features 裡的 nesting要打開

https://forum.proxmox.com/threads/logrotate-issue-in-buster-lxc.56726/

今天整理graylog的時候發現一件事

目前我在index set的設定是留180天
超過的delete
不過我會手動去close index
只留約一個月的資料查詢效率比較好
可是今天發現index超過了180天但系統並沒有去delete
我不確定是不是因為我手動去close的關係
如果真的是如此的話那政策就要改成定時close
然後再手動去delete了
手動砍的shell如下
每天找出最舊的index再砍掉

#!/bin/bash

del_idx=`/usr/bin/curl -u admin:password 'http://127.0.0.1:9200/_cat/indices/graylog*?v'|grep close|awk '{print $2}'|sort -rn -t_ -k 2|tail -n 1`

/usr/bin/curl -XDELETE "http://localhost:9200/$del_idx/"

用crontab 來做吧

訂閱：文章 (Atom)