ITSec-Chile / Waf2Py

Waf2Py is a nice and easy to use web interface for modsecurity v3 with nginx connector. Waf2Py is free and powered by Web2Py that controls modsecurity and nginx configuration in an easy way, allowing you to configure protection for any web application in just minutes.
Other
47 stars 16 forks source link

Syntax errors in generated logrotate conf #4

Closed troffasky closed 3 years ago

troffasky commented 4 years ago

Looks like site logs are not being rotated so I have tried running /home/www-data/waf2py_community/applications/Waf2Py/scripts/logrotate manually.

root@waf2py-demo:/home/www-data/waf2py_community/applications/Waf2Py/scripts# /bin/bash logrotate
reading config file /home/www-data/waf2py_community/applications/Waf2Py/logrotation.d/Application_name.conf
error: /home/www-data/waf2py_community/applications/Waf2Py/logrotation.d/Application_name.conf:13 unexpected log filename
error: found error in /opt/waf/nginx/var/log/Application_name/*.log , skipping
Reading state from file: /var/lib/logrotate/status
Allocating hash table for state file, size 64 entries
Creating new state
...repeated many times...
Creating new state

Handling 1 logs

rotating pattern: /opt/waf/nginx/var/log/Application_name/*.log  after 1 days (10 rotations)
empty log files are not rotated, old logs are removed
considering log /opt/waf/nginx/var/log/Application_name/Application_name_access.log
  Now: 2020-08-27 11:19
  Last rotated at 2020-08-27 00:00
  log does not need rotating (log has been rotated at 2020-8-27 0:0, that is not day ago yet)
considering log /opt/waf/nginx/var/log/Application_name/Application_name_audit.log
  Now: 2020-08-27 11:19
  Last rotated at 2020-08-27 00:00
  log does not need rotating (log has been rotated at 2020-8-27 0:0, that is not day ago yet)
considering log /opt/waf/nginx/var/log/Application_name/Application_name_debug.log
  Now: 2020-08-27 11:19
  Last rotated at 2020-08-27 00:00
  log does not need rotating (log has been rotated at 2020-8-27 0:0, that is not day ago yet)
considering log /opt/waf/nginx/var/log/Application_name/Application_name_error.log
  Now: 2020-08-27 11:19
  Last rotated at 2020-08-27 00:00
  log does not need rotating (log has been rotated at 2020-8-27 0:0, that is not day ago yet)

Generated logrotate conf:

/opt/waf/nginx/var/log/Application_name/*.log {
        create 0644 www-data www-data
        daily
        rotate 10
        missingok
        notifempty
        compress
        sharedscripts
        copytruncate
        #postrotate
        #/bin/kill -USR1 `cat /opt/waf/nginx/var/run/nginx.pid 2>/dev/null` 2>/dev/null || true
        #endscript
        /bin/chown -R www-data.www-data /opt/waf/nginx/var/log/Application_name/ || true
        }

Line 13 is /bin/chown which I think causes an error because "endscript" is commented out. I am not a logrotate expert, so I cannot explain why logrotate says it's skipping Application_name/*.log but then carries on and tries to rotate the logs. It says "log has been rotated", but it hasn't, there is only one of each log file. I am going to uncomment line 12 and see what happens overnight.

ch-rigu commented 4 years ago

It's ok, I'm not sure why it says syntax error, but it gets executed anyway. If you want manually do a logrotation, you need to add the "--force" switch inside /home/www-data/waf2py_community/applications/Waf2Py/scripts/logrotate

I am going to uncomment line 12 and see what happens overnight.

if you uncomment the "postrotate" block you may break the logs files. They will be rotated but will remains in blank even with a restart of nginx. This was happening because a bug in modsecurity or nginx... I don't remember now.... I had to switch to the option "copytruncate" to solve this. I think is already fixed in those days. I haven't tried yet. Tell me if works!

Here is how it looks like a successfully log rotation:

root@debian:/opt/waf/nginx/var/log/www.climbersoul.com# /bin/bash /home/www-data/waf2py_community/applications/Waf2Py/scripts/logrotate reading config file /home/www-data/waf2py_community/applications/Waf2Py/logrotation.d/www.climbersoul.com.conf error: /home/www-data/waf2py_community/applications/Waf2Py/logrotation.d/www.climbersoul.com.conf:13 unexpected log filename error: found error in /opt/waf/nginx/var/log/www.climbersoul.com/*.log , skipping** Reading state from file: /var/lib/logrotate/status Allocating hash table for state file, size 64 entries Creating new state Creating new state Creating new state `***** SNIPPED ***** considering log /opt/waf/nginx/var/log/www.climbersoul.com/www.climbersoul.com_debug.log Now: 2020-08-27 18:48 Last rotated at 2020-08-27 18:00 log does not need rotating (log is empty) considering log /opt/waf/nginx/var/log/www.climbersoul.com/www.climbersoul.com_error.log Now: 2020-08-27 18:48 Last rotated at 2020-08-27 18:00 log needs rotating rotating log /opt/waf/nginx/var/log/www.climbersoul.com/www.climbersoul.com_access.log, log->rotateCount is 10 dateext suffix '-20200827' glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]' /opt/waf/nginx/var/log/www.climbersoul.com/www.climbersoul.com_audit.log.1 truncating /opt/waf/nginx/var/log/www.climbersoul.com/www.climbersoul.com_audit.log copying /opt/waf/nginx/var/log/www.climbersoul.com/www.climbersoul.com_error.log to /opt/waf/nginx/var/log/www.climbersoul.com/www.climbersoul.com_error.log.1 truncating /opt/waf/nginx/var/log/www.climbersoul.com/www.climbersoul.com_error.log compressing log with: /bin/gzip compressing log with: /bin/gzip compressing log with: /bin/gzip`

Cheers.

troffasky commented 4 years ago

OK, rotation worked with lines 10,11,12 uncommented, but there is something slightly odd about access.log - it seems to lag the other log files, then catch up again later... [local time here is 1435]:

root@waf2py-demo:~# ls -al /opt/waf/nginx/var/log/Application_name/ -tr
total 536
drwxr-xr-x 4 www-data www-data   4096 Aug 26 15:06 ..
-rwxr-xr-x 1 www-data www-data      0 Aug 26 15:09 Application_name_debug.log
drwxr-xr-x 2 www-data www-data   4096 Aug 26 15:09 tmp
-rwxr-xr-x 1 www-data www-data  19501 Aug 27 10:01 Application_name_access.log.2.gz
-rwxr-xr-x 1 www-data www-data  20581 Aug 27 11:43 Application_name_error.log.2.gz
-rwxr-xr-x 1 www-data www-data  21183 Aug 27 11:43 Application_name_audit.log.2.gz
-rwxr-xr-x 1 www-data www-data  11679 Aug 27 20:36 Application_name_access.log.1.gz
-rwxr-xr-x 1 www-data www-data   6524 Aug 27 23:33 Application_name_error.log.1.gz
-rwxr-xr-x 1 www-data www-data   9311 Aug 27 23:33 Application_name_audit.log.1.gz
drwxr-xr-x 3 www-data www-data   4096 Aug 28 00:01 .
-rwxr-xr-x 1 www-data www-data 164658 Aug 28 12:52 Application_name_access.log
-rwxr-xr-x 1 www-data www-data 134843 Aug 28 14:28 Application_name_error.log
-rwxr-xr-x 1 www-data www-data 122378 Aug 28 14:28 Application_name_audit.log

Is this the "may break" you were referring to? To be clear, there definitely should be entries in access.log more recent than 12:52 - the real target webserver shows accesses and the error.log/audit.log refers to those accesses.

I am going to comment 10,11,12,13 and see how it runs over the weekend.

ch-rigu commented 4 years ago

it seems to lag the other log files, then catch up again later...

As far as I know, access logs of nginx works like that, first fill the buffer and then write the log file to disk.