Background: Many routers/AP/firewalls allow logging to remote IPs. Slackware's sysklogd also allows this via @host actions. A centralized log server which receives and processes log messages from multiple sources can be of great value to a systems admin.

Limitation: Linux sysklogd, which Slackware ships, does not allow filtering rules by originating host. In other words, if sysklogd is configured to accept remote messages (via -r switch), all messages get lumped together and acted on according to a single set of facility/priority selectors without regard to origin.

Unclean work-arounds like using local0-local7 priorities is not always possible, is limited to 8 remotes, and obscures the message's original facility. Port creativity is hackish.

Note: to enable reception of remote messages in Slackware edit syslogd_start() in /etc/rc.d/rc.syslog as below and restart the logging daemons with sh /etc/rc.d/rc.syslog restart.

Solution: Inspired by plisken's question, I set out to patch Slackware's sysklogd with Berkeley code logic (which sysklogd forked to begin with) to permit originating-host filtering capability.

Other slackers might find this feature enhancement as useful as I did. That is why I am making it available to the community via one of two patches (depending on your version):

1. sysklogd-1.4.1-host.diff
2. sysklogd-1.5-host.diff

Usage: The syntax for host directives in /etc/syslog.conf:

+<host/IP> matches when the originating host is the one specified
-<host/IP> matches when the originating host is not the one specified
+% matches when the originating host is the local machine
-% matches when the originating host is not the local machine

Note: host directives remain active until another host directive is specified (top to bottom).

--mancha

PS Comments from users of these patches are welcome.

=====

Below is a sample /etc/syslog.conf for a Slackware box which receives messages from 192.168.1.1 and 192.168.1.10 and sends them to /var/log/router.log and /var/log/slackbox2-{kern,mail}.log. Locally generated messages get logged as usual per Slackware defaults.

This would seem to be better if the host was active until the file was specified. What if you had 1000s of hosts, that would suck. At the very least you should do something like include a syslog.conf dir /etc/syslog.conf.d/{local,default,host1,host2,...}. that would be WAY cleaner. Also why not make the host definition in the dest file?

What would be REALLY cool is if you could add subnets and hosts. I don't think either rsyslog or syslog-ng can do this.

So any logs from 192.168.0.0/24 went to /var/log/${GROUP[x]}/${HOST}.log and 192.168.10.0/24 went to /var/log/${GROUP[y]}/${HOST}.log

The subnets would have to be defined. But this isn't near as bad as per host. Maybe then have a default location for hosts in unknown subnets. If the subnets moved it could be pain. Like if a /24 got broke into /28s or something, but a little command line work would fix that easy enough.

/var/log/remote/192.168.0.0_24/host{1,2,3,4}.log
/var/log/remote/192.168.10.0_24/host{1,2,3,4}.log
/var/log/remote/unknown/host{1,2,3,4}.log

Having to define hosts specifically in a log config is a MAJOR pain. And inevitably someone will forget and then the logs get mashed into the local log file. The problem here is the unknown. I see how you could do the -% but then you wind up with 1 log for all unknown hosts. still fixable but then you spend all your time looking for logs and straightening them out instead of diagnosing a problem.

Out of curiosity, why not just use Syslog-NG?
http://en.wikipedia.org/wiki/Syslog-ng
http://slackbuilds.org/repository/13...tem/syslog-ng/

It's available for Slackware, and can even log to SQL databases. You can even get as granular as logging errors to one file, warnings to another, info to a third, for each system, and have each in their own directories. I have never tried to break things down by subnet, since most machines I have are on one or two subnets, but I am easily able to break them down by IP address.

Thanks for the comments.

Linux's sysklogd has Berkeley lineage so the conventions and syntax I adopted in this patch were specifically chosen to be as
consistent as possible with that codebase. This includes specifying hostnames in the config file.

The motivation of this alpha was not to create alternatives to more feature-rich implementations like syslog-ng and rsyslog
but to add basic origin-based filtering capability to sysklogd which Slackware ships by default. (I hope that answers TB0ne's "why
are you doing this?" question).

One thing Berkeley's implementation allows is comma-delimited host name specifications which I might put into a beta of this
patch if I decide to do any further work on this. Also, I don't recall offhand if that specification permits wildcards in the hostnames
(a-la-tcpd) but that would be one way to approximate the netmask functionality suggested.

--mancha

if i had to choose i think i would go with rsyslog. it can do pretty much anything syslog-ng can do plus it has md5sums. and i like the log parsing better (chocalate/vanilla)

also adding "A" feature/change wouldn't make syslogd as feature rich as more featureful syslog deamons like syslog-ng and rsyslog. Crawl, Walk then Run. It would just be a really nice feature to have in any syslog daemon. Also there is nothing in the BSD specification that says you cant put files in directories.

I took a quick look at the code, and think there are a few issues with how the hostname is handled.

The allocation of host is "MAXHOSTNAMELEN+1" which is good... unfortunately, most of the usage of the host is in the structure filed, which only has the pointer... with dynamically allocated strings assigned.

I would have thought it better to make the structure member f_host an array (f_host[MAXHOSTNAMELEN+1]) instead of a pointer... Then you eliminate all the dynamic manipulations, and possible future problems with strcpy (why not useuse strncpy?).

Other than that, it is a very good idea.

Personally I would use rsyslog, because it's based on syslogd and intended as drop-in replacement. And I simply don't like syslog-ng configuration syntax (syslogd looks much cleaner). But to be honest, I didn't know rsyslog exist to this day, so thank for this thread!
On the other hand I'd also like the remote log filtering feature in syslogd. Although I'm afraid that you might have to fork your own syslog to have that feature (see why does the world need another syslogd? (aka rsyslog vs. syslog-ng). Or maybe not, we'll see.

Either way I like your effort and I'm glad to see someone simply hack things to change something instead of giving up and moving on.

It is also better than the thing being foisted off on Fedora (journald). It has some nice features.. but is also known to hang the system, eat disk space, and cause cascading logging failures.