PfSense 3.0 Inquiry to Gonzo : will rsyslogd replace syslogd?
-
Will rsyslogd replace syslogd in pfSense 3.0? I currently need a two-way TLS secure channel to export detailed pfSense firewall events to cloud-based analytics in a single Netgate SOHO appliance, as opposed to current strategies of deploying a second box on premise to host a rsyslogd collector and therein do the secure TLS channel there up to the analytics cloud.
No question there are GUI challenges for the multi-step complication of rsyslogd, in terms of configuring certificates, cipher selection, fallbacks, etc – all of which is not as turnkey easy as the present pfSense GUI syslogd entry of IP:PORT -- I get that. On the other hand, I don't want a site's firewall events to be locked into a single "cloud" analytics for the ease of configuring the setup of rsyslogd.
-
It's ridiculous that the old shitlog (I mean, syslog) daemon is still in this thing.
The built in POS doesn't even allow you to use TCP, and the messages don't contain the system name, so when you pipe it into a log management system you have yet another issue. There are drop-in replacements that are lightyears ahead, so why this old 1980's esque trash?
It should be replaced in 2.4, not 3. Ideally, 2.0 but it's harder to go back in time.
-
Convince FreeBSD to include a different syslog distribution in the base system, then we'll talk. We use what they use. :-)
You can use the syslog-ng package if you want so you are not limited to what's in the base system.
It's too late for such a change in 2.4, maybe 2.5, not sure what will be in that role for 3.0 but it's still early there.
We've already been talking about dropping clog in favor of sensible log rotation and retention since space constraints are not what they used to be in the past, even with RAM disks since most systems have more RAM available. Once we remove the clog-style log requirement then it frees up a lot of options like using syslog-ng in base.
