Make it possible to use ULOG instead of LOG

[Andrew Pollock]

Binary package hint: ufw

This is related to bug #244232 I guess.

I dislike using the LOG target, as it pollutes the dmesg output and kern.log. I prefer to use ULOG, as this causes the logged messages to go to /var/log/ulog/syslogemu.log by default.

Please add a configuration option or configuration file option to generate the Netfilter rules with the ULOG target instead of the LOG target.

[Jamie Strandboge (jdstrand)]

ULOG would be nice, though I might point out ufw 0.30 in Ubuntu 10.04 ships with an rsyslog file for separating this out and it automatically logs to /var/log/ufw.log. rsyslog is the default syslog daemon in 10.04. For backwards compatibility, ufw continues to log to kern, but this can be changed in /etc/rsyslog.d/20-ufw.conf:

# Log kernel generated UFW log messages to file
:msg,contains,"[UFW " /var/log/ufw.log

# Uncomment the following to stop logging anything that matches the last rule.
# Doing this will stop logging kernel generated UFW log messages to the file
# normally containing kern.* messages (eg, /var/log/kern.log)
#& ~

[Andrew Pollock (apollock)]

Jamie, it's true that I'm currently using syslog-ng, but is that going to make a difference to what appears in dmesg? I'm most interested in not having dmesg output polluted with firewall logging.

[Jamie Strandboge (jdstrand)]

No it don't think it would affect dmesg, which is why I marked it as 'Triaged' and 'Wishlist', so that support can be added in the future.

[Andrew Pollock (apollock)]

Great, thanks.

[MM (mmme)]

Yes please allow ULOG! :)

There is no rsyslog file listed in the https://launchpad.net/ubuntu/lucid/+source/ufw/0.30pre1-0ubuntu2/+files/ufw_0.30pre1.orig.tar.gz

If it is I don't see it, why isn't this packed with the source to use?

THANKS

[MM (mmme)]

Actually I use Slackware which uses syslogd so anyway to change that 20-ufw.conf for me over to what Slackware uses so I can get ugw to log to it's own file?

THANKS

[Jamie Strandboge (jdstrand)]

@SAR,

The rsyslog file is in doc/rsyslog.example.

[MM (mmme)]

@ Jamie Slackware uses syslogd so this isn't going to help and I don't want to change loggers.

Please add support for ULOG...

After all this is suppose to be a script that the end-user Admin/root should be able to change and edit and simply change the logging section in user.rules from -j LOG to -j ULOG

[MM (mmme)]

I just found this Ubuntu Documentation for Firewalls shows under the 'Logs' section towards the bottom that ulogd can be used which makes it look like they are not just talking about other firewalls but ufw, since towards the top of this section ufw is the one being mentioned.

https://help.ubuntu.com/8.04/serverguide/C/firewall.html

So why is this docs saying this, is this a typo, or the later versions of ufw have a bug, or this has been disabled?

[Jamie Strandboge (jdstrand)]

@ SAR,

Yes, support for ulogd is planned. I also accept patches. :) Regarding the server guide, it is just not organized particularly well. In general, it talks about ufw first and iptables second but in the logging section it isn't as clear as it could be which is which. Feel free to file a bug against the ubuntu-docs package to make this more clear.

[MM (mmme)]

THANKS Jamie, how far off are we from getting ulogd support?

[MM (mmme)]

@Jamie any word yet on ulog?

THANKS

[Jamie Strandboge (jdstrand)]

No progress has been made, but support is still planned. Patches are welcome. :)

[MM (mmme)]

How long would it really take to implement this?

I would of seriously thought, even for one individual developer, working on this as their own personal project that this wouldn't even take a few days.

As big as the development team is at Ubuntu I don't get why someone can't jump on this, after all does UFW really need any other work done on it, it seems fine like it is...

THANKS

[Jamie Strandboge (jdstrand)]

This was never fixed because ipv6 ULOG support was removed from netfilter and thus making ULOG a non-starter for ufw.

[Christian Kujau (christiank)]

I guess bug #1475676 would be the logical consequence here.