OPNsense Forum
Archive => 15.7 Legacy Series => Topic started by: Solaris17 on August 30, 2015, 04:52:40 pm
-
First Id like to start with my build data
OPNsense 15.7_824-amd64
FreeBSD 10.2-RELEASE-p1
LibreSSL 2.2.2
My issue however also happened on 10.1 and the vanilla 15.7.X build. though since iv upgraded I have forgotten my sub version number.
My issue is that the IDS rules do not auto update. Attached is the configuration I would like to use. A standard check once a day. However when going into my IDS today I noticed they have not been updated since the 27th. before my upgrade to both 10.2 and _824. I then went and modified the schedule to update in 1 minute intervals for testing. After about 5 the rules still had not updated. I am hoping this is some kind of configuration issue. Does anyone have any insight?
-
Does the manual update work from the ids ui page?
If it does, can you check if log contains attempts to perform an auto update, using this command:
clog /var/log/system.log | grep "update IDS rules"
and can you check the contents of the crontab using :
cat /var/cron/tabs/root
And one last question, just to be sure, your not using a nano version or have memory disk enabled (this could currently destroy your cron settings after reboot).
-
Hi! Thank you for the response!
When I run
clog /var/log/system.log | grep "update IDS rules"
I get no response from the terminal.
When I run
cat /var/cron/tabs/root
I get the output of the current settings in the IDS schedule page. They seem correct.
The manual updating of the IDS definitions works perfectly and immediately.
I am not running NANO and im not using memory disk. The system runs on a dedicated 32GB SSD.
I took a chance to experiment more and I changed the update time to every 2min for testing. Before it had been set for 10-12 hours for testing. To break it down.
set for 23 hours. no update for several days.
change to 10-12 hours updates apply after 10 hours.
more than 12 hours go by no update.
Switch to 2min updates apply 2min later.
5min go by no update.
It seems like its not resetting after the updates apply?
BUT The logs say this
Aug 31 22:13:36 configd.py: [e0bdcf55-61af-4d6a-87e2-f763fa23091a] get suricata daemon status
Aug 31 22:13:36 configd.py: [7ed96fa6-b30b-45f0-8365-32f90e886b57] request installable rules
Aug 31 22:12:35 configd.py: [de0f384a-5e35-4087-bfbd-a5bedce859ff] get suricata daemon status
Aug 31 22:12:35 configd.py: [6440d91a-dd80-4eaf-a7eb-87f5bd48da42] request installable rules
Aug 31 22:11:03 configd.py: [5da71fad-9fea-4297-94d6-4895c632dd62] get suricata daemon status
Aug 31 22:11:03 configd.py: [c09d7ee2-8ece-4a1b-a492-7e8cc4b940f6] request installable rules
Aug 31 22:09:36 configd.py: [e4478128-8b7c-4894-a25e-6b0879c137cc] get suricata daemon status
Aug 31 22:09:36 configd.py: [4393efa3-7de5-4339-ba4c-9a60b50ac96b] request installable rules
Aug 31 22:06:53 configd.py: [3a81d941-cab0-4692-b8bb-974a9189834a] get suricata daemon status
Aug 31 22:06:53 configd.py: [bca87310-06f5-49a6-bf5a-1fce0b1f8a89] request installable rules
Aug 31 22:06:50 configd.py: [03359858-4864-4b89-9144-09cc22e49b33] get suricata daemon status
Aug 31 22:06:50 configd.py: [41778be4-0bea-4886-854b-602b5f9ae100] request installable rules
Aug 31 22:06:47 configd.py: [9e6b7f72-b3f2-44fa-ae0d-0b299f931cc2] restarting cron
Maybe the IDS page itself simply has a lag time between when the rules get updated and when teh time stamp changes on teh status page?
I hope any of this provides help. If I am being a stupid user though please just lmk. The thought did cross my mind that perhaps the windows for updates was too short (sub 10min intervals) and that maybe the rules hadn't finished propagating when the next request was called thus stopping the update?
-
Sorry, I put the wrong log text in the grep command.
Can you try this?
clog /var/log/system.log | grep "update and reload suricata rules"
And then check what the cron daemon itself finds of it, by running this:
crontab -l
It should look like the contents of the cron file with some lines above it.
Maybe one other thing to check are the timestamps from the last downloaded files, using:
ls -asl /usr/local/etc/suricata/rules
Our own system is scheduled for daily update at 0:10, which seems to work just fine, it's probably something small.
-
in short it seems its only updating 1st time after the apply button is hit.
Nothing after that.
-
Sorry, I put the wrong log text in the grep command.
Can you try this?
clog /var/log/system.log | grep "update and reload suricata rules"
And then check what the cron daemon itself finds of it, by running this:
crontab -l
It should look like the contents of the cron file with some lines above it.
Maybe one other thing to check are the timestamps from the last downloaded files, using:
ls -asl /usr/local/etc/suricata/rules
Our own system is scheduled for daily update at 0:10, which seems to work just fine, it's probably something small.
No problem!
for testing I have done the above and these are my parameters I set IDS rules to update in 1min intervals.
They did not update.
Last Sync time was manual at 2015/08/31 23:59 Local
At the time of this posting it is Sept 1 10:34 PM
I set the 1min update rules on Sept 1 10:30 PM 4 min ago.
my read outs are as follows.
root@Chronos:~ # clog /var/log/system.log | grep "update and reload suricata rules"
root@Chronos:~ # crontab -l
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
# Order of crontab fields
# minute hour mday month wday command
# Origin/Description: IDS/ids rule updates
1 * * * * /usr/local/sbin/configctl ids update
root@Chronos:~ # ls -asl /usr/local/etc/suricata/rules
total 4484
4 drwxr-xr-x 2 root wheel 2048 Sep 1 00:22 .
4 drwxr-xr-x 4 root wheel 512 Aug 14 23:04 ..
4 -rw-r--r-- 1 root wheel 1498 Jul 2 08:21 dns-events.rules
4 -rw-r----- 1 root wheel 2513 Aug 31 23:59 dshield.rules
24 -rw-r----- 1 root wheel 24415 Aug 31 23:59 emerging-dns.rules
48 -rw-r----- 1 root wheel 47839 Aug 31 23:59 emerging-dos.rules
180 -rw-r----- 1 root wheel 183410 Aug 31 23:59 emerging-exploit.rules
40 -rw-r----- 1 root wheel 38891 Aug 31 23:59 emerging-ftp.rules
448 -rw-r----- 1 root wheel 412990 Aug 31 23:59 emerging-malware.rules
64 -rw-r----- 1 root wheel 63762 Aug 31 23:59 emerging-mobile_malware.rules
180 -rw-r----- 1 root wheel 181762 Aug 31 23:59 emerging-sql.rules
8 -rw-r----- 1 root wheel 4205 Aug 31 23:59 emerging-telnet.rules
8 -rw-r----- 1 root wheel 6444 Aug 31 23:59 emerging-tftp.rules
1760 -rw-r----- 1 root wheel 1756339 Aug 31 23:59 emerging-trojan.rules
12 -rw-r----- 1 root wheel 9392 Aug 31 23:59 emerging-worm.rules
4 -rw-r--r-- 1 root wheel 3118 Aug 31 23:59 files.rules
8 -rw-r--r-- 1 root wheel 6780 Aug 31 23:59 http-events.rules
4 -rw-r----- 1 root wheel 1963 Aug 31 23:59 rbn-malvertisers.rules
1376 -rw-r----- 1 root wheel 1367040 Sep 1 00:22 rules.sqlite
4 -rw-r--r-- 1 root wheel 2509 Aug 31 23:59 smtp-events.rules
300 -rw-r----- 1 root wheel 305506 Aug 31 23:59 tor.rules
root@Chronos:~ # time
0.019u 0.041s 6:50.56 0.0% 483+470k 1+0io 0pf+0w
-
Ok, still odd..
All seems fine so far, let's check if cron is running:
ps fax | grep cron
And trigger the job manually to be sure.
/usr/local/sbin/configctl ids update
Then grep the log again:
clog /var/log/system.log | grep "update and reload suricata rules"
Hopefully we will see some errors now, the last action should now show at least one line (because we triggered it manually).
-
everything seems fine?
root@Chronos:~ # /usr/local/sbin/configctl ids update
OK
root@Chronos:~ # ps fax | grep cron
18217 - Is 0:00.09 /usr/sbin/cron -s
43622 - Is 0:00.00 minicron 240 /var/run/ping_hosts.pid /usr/local/sbin
43870 - I 0:00.11 minicron: helper /usr/local/sbin/ping_hosts.sh (min
44117 - Is 0:00.00 minicron 3600 /var/run/expire_accounts.pid /usr/loca
44430 - I 0:00.01 minicron: helper /usr/local/etc/rc.expireaccounts (
44631 - Is 0:00.00 minicron 86400 /var/run/update_alias_url_data.pid /u
44659 - I 0:00.00 minicron: helper /usr/local/etc/rc.update_alias_url_
76995 0 S+ 0:00.00 grep cron
root@Chronos:~ # clog /var/log/system.log | grep "update and reload suricata rules"
configd.py: [1d24c587-2c36-4e54-bb77-d3f1d01c16b6] update and reload suricata rules
Sep 1 23:38:00 Chronos configd.py: [96d4d0e4-11c0-4e14-a596-daa3a997b550] update and reload suricata rules
Sep 1 23:39:00 Chronos configd.py: [82cf8d9c-7ce3-4986-82d2-a305f5c3a332] update and reload suricata rules
Sep 1 23:40:00 Chronos configd.py: [4cc1bc7b-af2a-4ae3-94a1-4f7f0725afdb] update and reload suricata rules
Sep 1 23:41:00 Chronos configd.py: [e791f7f2-fbf8-4991-88ec-b6d0bd80a097] update and reload suricata rules
Sep 1 23:42:00 Chronos configd.py: [9683c12c-d147-4fb0-bb42-cfb6fb050229] update and reload suricata rules
Sep 1 23:43:00 Chronos configd.py: [dbd07124-dcc4-4a7e-90c2-7ac64eb66bf2] update and reload suricata rules
Sep 1 23:44:00 Chronos configd.py: [bb188c35-f056-4a2a-bbdb-6d67726a9f4f] update and reload suricata rules
Sep 1 23:45:00 Chronos configd.py: [a71986c8-30c6-432f-a68a-1091e5f86f3b] update and reload suricata rules
Sep 1 23:46:00 Chronos configd.py: [4e25760b-fc1f-45f3-b6fd-1fe521958564] update and reload suricata rules
Sep 1 23:47:00 Chronos configd.py: [5ebb532d-a4a1-4653-ac86-178ad1f179d8] update and reload suricata rules
Sep 1 23:48:00 Chronos configd.py: [211758d3-2284-406d-bebe-c575ea44af91] update and reload suricata rules
Sep 1 23:49:00 Chronos configd.py: [bd0438c4-6a61-46f5-a364-a295b974829b] update and reload suricata rules
Sep 1 23:50:00 Chronos configd.py: [0b1e36c3-e6f6-4d22-a1fe-d509fb727f45] update and reload suricata rules
Sep 1 23:51:00 Chronos configd.py: [69ba4022-4a5e-49bb-8f38-5847006b5ee2] update and reload suricata rules
Sep 1 23:52:00 Chronos configd.py: [f436477d-6665-4224-9895-80bc0941063e] update and reload suricata rules
Sep 1 23:53:00 Chronos configd.py: [2aa043e2-20db-4a85-b1ae-d01c5b614942] update and reload suricata rules
Sep 1 23:54:00 Chronos configd.py: [15848dcb-8ec9-49fa-92ce-0e141be22ef8] update and reload suricata rules
Sep 1 23:55:00 Chronos configd.py: [a65d389b-3565-4d16-88b5-c7a37f04c8f0] update and reload suricata rules
Sep 1 23:56:00 Chronos configd.py: [66802e6d-9d52-4a40-8076-a53d62424e2c] update and reload suricata rules
Sep 1 23:57:00 Chronos configd.py: [269a1f1c-7fe4-436a-8bc3-89177b6a5e49] update and reload suricata rules
Sep 1 23:58:00 Chronos configd.py: [2dd816e5-b39d-4419-acf0-01acc53e3975] update and reload suricata rules
Sep 1 23:59:00 Chronos configd.py: [af3b374a-cda4-4f08-b7d5-9813849c4cdd] update and reload suricata rules
Sep 2 00:06:33 Chronos configd.py: [15c63148-608f-40f2-80ab-5b088b4bc086] update and reload suricata rules
Sep 2 10:07:14 Chronos configd.py: [280d5070-5aad-4ca6-a723-30ed13a69def] update and reload suricata rules
Sep 2 10:09:46 Chronos configd.py: [a765243f-23eb-4875-9241-42b03cf747d9] update and reload suricata rules
root@Chronos:~ #
-
It does, but the strange this is that now it looks like it worked yesterday (the entry every minute in your log, which wasn't in your earlier report).
How is your cron job configured now? The last entry from yesterday seems to be at 00:06:33
-
Since I haven't quite figured it out and this particular router is still in testing I switched it back to 23 hours when im not testing so that if it did work while I was away I wouldn't have to worry about 1 min intervals doing something unforeseen to the machine.
-
Can you leave it this way and check the log again tomorrow? I think it should work, because all the settings look quite normal and apparently it did work for a brief moment with 1 min intervals.
-
No problem! I'll report back when its time thanks for all the help thus far!
-
Crazy things seem to be happening now.
root@Chronos:~ # ls -asl /usr/local/etc/suricata/rules
total 4492
4 drwxr-xr-x 2 root wheel 2048 Sep 2 17:28 .
4 drwxr-xr-x 4 root wheel 512 Aug 14 23:04 ..
4 -rw-r--r-- 1 root wheel 1498 Jul 2 08:21 dns-events.rules
4 -rw-r----- 1 root wheel 2511 Sep 2 23:54 dshield.rules
24 -rw-r----- 1 root wheel 24415 Sep 2 23:54 emerging-dns.rules
48 -rw-r----- 1 root wheel 47839 Sep 2 23:54 emerging-dos.rules
180 -rw-r----- 1 root wheel 183410 Sep 2 23:54 emerging-exploit.rules
40 -rw-r----- 1 root wheel 38891 Sep 2 23:54 emerging-ftp.rules
448 -rw-r----- 1 root wheel 412990 Sep 2 23:54 emerging-malware.rules
64 -rw-r----- 1 root wheel 63762 Sep 2 23:54 emerging-mobile_malware.rules
180 -rw-r----- 1 root wheel 181762 Sep 2 23:54 emerging-sql.rules
8 -rw-r----- 1 root wheel 4205 Sep 2 23:54 emerging-telnet.rules
8 -rw-r----- 1 root wheel 6444 Sep 2 23:54 emerging-tftp.rules
1760 -rw-r----- 1 root wheel 1756368 Sep 2 23:54 emerging-trojan.rules
12 -rw-r----- 1 root wheel 9392 Sep 2 23:54 emerging-worm.rules
4 -rw-r--r-- 1 root wheel 3118 Sep 2 23:54 files.rules
8 -rw-r--r-- 1 root wheel 6780 Sep 2 23:54 http-events.rules
4 -rw-r----- 1 root wheel 1963 Sep 2 23:54 rbn-malvertisers.rules
1376 -rw-r----- 1 root wheel 1367040 Sep 2 17:28 rules.sqlite
4 -rw-r--r-- 1 root wheel 2509 Sep 2 23:54 smtp-events.rules
308 -rw-r----- 1 root wheel 312379 Sep 2 23:54 tor.rules
root@Chronos:~ # crontab -l
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
# Order of crontab fields
# minute hour mday month wday command
# Origin/Description: IDS/ids rule updates
* 23 * * * /usr/local/sbin/configctl ids update
root@Chronos:~ #
my schedule is set to 23 hours. which I have just hit. but now I am updating every minute!
# Origin/Description: IDS/ids rule updates
* 23 * * * /usr/local/sbin/configctl ids update
root@Chronos:~ #
root@Chronos:~ # ls -asl /usr/local/etc/suricata/rules
total 4492
4 drwxr-xr-x 2 root wheel 2048 Sep 2 17:28 .
4 drwxr-xr-x 4 root wheel 512 Aug 14 23:04 ..
4 -rw-r--r-- 1 root wheel 1498 Jul 2 08:21 dns-events.rules
4 -rw-r----- 1 root wheel 2511 Sep 2 23:56 dshield.rules
24 -rw-r----- 1 root wheel 24415 Sep 2 23:56 emerging-dns.rules
48 -rw-r----- 1 root wheel 47839 Sep 2 23:56 emerging-dos.rules
180 -rw-r----- 1 root wheel 183410 Sep 2 23:56 emerging-exploit.rules
40 -rw-r----- 1 root wheel 38891 Sep 2 23:56 emerging-ftp.rules
448 -rw-r----- 1 root wheel 412990 Sep 2 23:56 emerging-malware.rules
64 -rw-r----- 1 root wheel 63762 Sep 2 23:56 emerging-mobile_malware.rules
180 -rw-r----- 1 root wheel 181762 Sep 2 23:56 emerging-sql.rules
8 -rw-r----- 1 root wheel 4205 Sep 2 23:56 emerging-telnet.rules
8 -rw-r----- 1 root wheel 6444 Sep 2 23:56 emerging-tftp.rules
1760 -rw-r----- 1 root wheel 1756368 Sep 2 23:56 emerging-trojan.rules
12 -rw-r----- 1 root wheel 9392 Sep 2 23:56 emerging-worm.rules
4 -rw-r--r-- 1 root wheel 3118 Sep 2 23:56 files.rules
8 -rw-r--r-- 1 root wheel 6780 Sep 2 23:56 http-events.rules
4 -rw-r----- 1 root wheel 1963 Sep 2 23:56 rbn-malvertisers.rules
1376 -rw-r----- 1 root wheel 1367040 Sep 2 17:28 rules.sqlite
4 -rw-r--r-- 1 root wheel 2509 Sep 2 23:56 smtp-events.rules
308 -rw-r----- 1 root wheel 312379 Sep 2 23:56 tor.rules
root@Chronos:~ #
root@Chronos:~ # ls -asl /usr/local/etc/suricata/rules
total 4492
4 drwxr-xr-x 2 root wheel 2048 Sep 2 17:28 .
4 drwxr-xr-x 4 root wheel 512 Aug 14 23:04 ..
4 -rw-r--r-- 1 root wheel 1498 Jul 2 08:21 dns-events.rules
4 -rw-r----- 1 root wheel 2511 Sep 2 23:57 dshield.rules
24 -rw-r----- 1 root wheel 24415 Sep 2 23:57 emerging-dns.rules
48 -rw-r----- 1 root wheel 47839 Sep 2 23:57 emerging-dos.rules
180 -rw-r----- 1 root wheel 183410 Sep 2 23:57 emerging-exploit.rules
40 -rw-r----- 1 root wheel 38891 Sep 2 23:57 emerging-ftp.rules
448 -rw-r----- 1 root wheel 412990 Sep 2 23:57 emerging-malware.rules
64 -rw-r----- 1 root wheel 63762 Sep 2 23:57 emerging-mobile_malware.rules
180 -rw-r----- 1 root wheel 181762 Sep 2 23:57 emerging-sql.rules
8 -rw-r----- 1 root wheel 4205 Sep 2 23:57 emerging-telnet.rules
8 -rw-r----- 1 root wheel 6444 Sep 2 23:57 emerging-tftp.rules
1760 -rw-r----- 1 root wheel 1756368 Sep 2 23:57 emerging-trojan.rules
12 -rw-r----- 1 root wheel 9392 Sep 2 23:57 emerging-worm.rules
4 -rw-r--r-- 1 root wheel 3118 Sep 2 23:57 files.rules
8 -rw-r--r-- 1 root wheel 6780 Sep 2 23:57 http-events.rules
4 -rw-r----- 1 root wheel 1963 Sep 2 23:57 rbn-malvertisers.rules
1376 -rw-r----- 1 root wheel 1367040 Sep 2 17:28 rules.sqlite
4 -rw-r--r-- 1 root wheel 2509 Sep 2 23:57 smtp-events.rules
308 -rw-r----- 1 root wheel 312379 Sep 2 23:57 tor.rules
root@Chronos:~ #
and is not stopping.
this is my activity dump
last pid: 58367; load averages: 0.17, 0.15, 0.09 up 4+14:37:42 23:58:37
119 processes: 3 running, 98 sleeping, 18 waiting
Mem: 26M Active, 877M Inact, 517M Wired, 405M Buf, 6405M Free
Swap:
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND
11 root 155 ki31 0K 32K CPU0 0 105.6H 98.88% [idle{idle: cpu0}]
11 root 155 ki31 0K 32K RUN 1 106.0H 96.19% [idle{idle: cpu1}]
35390 root 52 0 126M 31464K piperd 1 0:04 3.27% /usr/local/bin/php-cgi
6751 root 20 0 913M 770M uwait 0 62:12 0.49% /usr/local/bin/suricata -D -i re0 -i re1
12 root -92 - 0K 288K WAIT 0 23:53 0.39% [intr{irq268: re1}]
6751 root 20 0 913M 770M nanslp 0 18:16 0.29% /usr/local/bin/suricata -D -i re0 -i re1
12 root -92 - 0K 288K WAIT 0 16:44 0.10% [intr{irq267: re0}]
6751 root 27 0 913M 770M umtxn 1 63:03 0.00% /usr/local/bin/suricata -D -i re0 -i re1
6751 root 20 0 913M 770M uwait 0 54:26 0.00% /usr/local/bin/suricata -D -i re0 -i re1
6751 root 20 0 913M 770M uwait 0 34:05 0.00% /usr/local/bin/suricata -D -i re0 -i re1
6751 root 20 0 913M 770M umtxn 0 11:20 0.00% /usr/local/bin/suricata -D -i re0 -i re1
6751 root 20 0 913M 770M umtxn 1 11:18 0.00% /usr/local/bin/suricata -D -i re0 -i re1
12 root -60 - 0K 288K WAIT 0 4:36 0.00% [intr{swi4: clock}]
15 root -16 - 0K 16K - 0 4:35 0.00% [rand_harvestq]
6751 root 20 0 913M 770M nanslp 0 4:29 0.00% /usr/local/bin/suricata -D -i re0 -i re1
5 root -16 - 0K 16K pftm 1 1:37 0.00% [pf purge]
0 root -16 0 0K 160K swapin 1 0:28 0.00% [kernel{swapper}]
49927 root 20 0 14392K 1952K select 1 0:28 0.00% /usr/sbin/powerd -b adp -a adp -n hadp
also if I scroll all the way down to the bottom of the IDS page I can no longer click on left hand panel.
I seem to have got it to stop when I manually applied patches. The stop was exactly at midnight EST USA. so logs show 0:00 system activity still shows the following.
last pid: 39414; load averages: 0.11, 0.11, 0.08 up 4+14:48:37 00:09:32
118 processes: 3 running, 97 sleeping, 18 waiting
Mem: 180M Active, 138M Inact, 512M Wired, 430M Buf, 6995M Free
Swap:
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND
11 root 155 ki31 0K 32K RUN 0 105.7H 98.58% [idle{idle: cpu0}]
11 root 155 ki31 0K 32K CPU1 1 106.1H 98.39% [idle{idle: cpu1}]
35390 root 52 0 126M 31572K piperd 0 0:17 2.69% /usr/local/bin/php-cgi
6795 root 20 0 257M 181M uwait 0 0:02 0.49% /usr/local/bin/suricata -D -i re0 -i re1
6795 root 20 0 257M 181M uwait 0 0:04 0.20% /usr/local/bin/suricata -D -i re0 -i re1
6795 root 20 0 257M 181M uwait 1 0:02 0.20% /usr/local/bin/suricata -D -i re0 -i re1
12 root -92 - 0K 288K WAIT 0 23:57 0.00% [intr{irq268: re1}]
12 root -92 - 0K 288K WAIT 1 16:47 0.00% [intr{irq267: re0}]
12 root -60 - 0K 288K WAIT 1 4:36 0.00% [intr{swi4: clock}]
15 root -16 - 0K 16K - 0 4:36 0.00% [rand_harvestq]
5 root -16 - 0K 16K pftm 1 1:37 0.00% [pf purge]
0 root -16 0 0K 160K swapin 0 0:28 0.00% [kernel{swapper}]
49927 root 20 0 14392K 1952K select 1 0:28 0.00% /usr/sbin/powerd -b adp -a adp -n hadp
36650 root 20 0 16660K 2496K bpf 1 0:25 0.00% /usr/local/sbin/filterlog -i pflog0 -p /
74133 root 22 0 126M 31496K accept 1 0:22 0.00% /usr/local/bin/php-cgi
56721 root 20 0 58824K 7440K kqread 1 0:20 0.00% /usr/local/sbin/lighttpd -f /var/etc/lig
12 root -88 - 0K 288K WAIT 1 0:17 0.00% [intr{irq265: xhci0}]
23 root 16 - 0K 16K syncer 0 0:14 0.00% [syncer]
but it is now 0:10 and the IDS page shows no definition updates. time stamps still read 0:00
-
My mistake, It's doing exactly what it should do now, but I over read the * (every) in the minute section of your config.
Just update it to 0 and you should be fine.
-
My mistake, It's doing exactly what it should do now, but I over read the * (every) in the minute section of your config.
Just update it to 0 and you should be fine.
I see! thank you! I will make the change immediately! I was under the impression this simply meant "any" minute as long as it met another variable like 23 hours. Does this mean I should put a 0 in the other fields? Would it freak out at like the one month mark for example if I left it *? Would it break them if I changed them all too 0?
Thank you very much for the assistance.
-
You can leave the others like they where, because you do want "any day".
Cron is a bit confusing sometimes :)
-
You can leave the others like they where, because you do want "any day".
Cron is a bit confusing sometimes :)
Thanks for that. Sorry to take so much of your time on something so trivial, I appreciate the help!