[syslog-ng] Regex Solaris from Linux hosts in Syslog-ng config file

Jim Hendrick jrhendri at roadrunner.com
Sun Nov 1 14:47:39 CET 2015


   Going out on a limb here

Could this have something to do with the actual facility/priority bits 
in the syslog message?

I recall that Solaris does it differently that (well, pretty much anyone 
actually) linux.

If you look at the syslog.h file (/usr/inc/ude/sys/syslog.h in some 
systems) it shows the definition used by *that* system.

This makes things a little wonky when the syslog server uses a different 
set of bits from the syslog client.

At one point I did use something similar to re-map the name of syslog 
files on a linux server so that the facility.priority in the log file 
name matched the sending client.

Or am I too far out here?


"Come in from the limb, there is no limb..." <Gru>

On 11/01/2015 05:57 AM, Jakub Jankowski wrote:
> On 30.10.2015 16:15, PÁSZTOR György wrote:
>> Hello vijay,
>> "Evan Rempel" <erempel at uvic.ca> írta 2015-10-29 17:54-kor:
>>> Before I get too deep into how this is done, can I ask why you want to
>>> separate your logs for solaris and linux?
>>> On 10/29/2015 01:06 PM, vijay amruth wrote:
>>>> Thank you Evan.
>>>> Right now, we add a solaris server everytime we spin one,
>>>> its like this,
>>>> filter f_solaris {
>>>>          host('x.x.x.x') or host('x.x.x.2') or
>>>>          host('x.x.x.3') or host('x.x.x.4') or
>>>>          host('hostname1) or (hostname2)
>>>>          }
>>>> So everytime we spin a server we just go and add it manually to the
>>>> config file, either with its host name or the ip.
>>>> I want to be able to automate with filter functions and or regex so
>>>> that I don't have to add manually to the config file on the server
>>>> everytime.
>>>> There is a similar config for linux hosts too
>>>> Hope I am clear. Appreciate you taking your time out for this.
>> [... snip ...]
>> I can not imagine a solution, why should linux and solaris clients have the
>> same config.
>> But if we assume this ridiculous idea, and the only distinction you have
>> the IP address list, you still have an option to handle this situation
>> well:
>> If the receiving machine is a linuxbox, then you can create an iptables
>> rule, and match for linux clients, and DNAT the logs, which would come to
>> this imaginary 1001 port, and redirect them to port 1002.
>> and do another dnat rule, which would match for solaris client and would
>> redirect trafic which would come to port 1001 to reach port 1003.
>> A simple example:
>> iptables -t nat -I PREROUTING -s -m tcp -p tcp --dport 1001 -j REDIRECT --to-port 1002
>> A better solution, if you do not match the linux clients based on this kind
>> of single IP address. Use an ipset match rule instead of this.
>> In that case you need only two iptables rule, and some ipset maintenance.
>> eg. the mentioned iptables rule would be this:
>> iptables -t nat -I PREROUTIGN -m set --match-set linux src -m tcp -p tcp --dport 1001 -j REDIRECT --to-port 1002
>> And the set creation:
>> ipset create linux hash:ip
>> ipset add linux
>> ipset add linux
>> ...
>> Once you are done with that you can save the rules, and restore them on
>> boot time.
>> Saving:
>> ipset save >/etc/myipset
>> Restoring:
>> ipset restore </etc/myipset
>> Some thing, you need to care about:
>> Do first the restore, and then to load the iptables rule!
>> The iptables rule need the ipset to be already created. It does not matter
>> if you did not load any entry into it. But it will not allow your iptables
>> rule regarding a set, until the set not exists.
> Well, how is this any better than specifying client's IP
> addresses/hostnames in syslog-ng.conf?
>> I hope you have enough lego blocks in your hand now to solve the problem in
>> an effective way! ;-)
>> Kind regards,
>> Gyu
> Let me suggest another idea: if Vijay has control over client's
> hostname, you could devise a simple host naming scheme, where you encode
> some metadata in client's hostname, for example: you could name all
> Solaris client's with a hostname that starts with "s", and all Linux
> clients with a hostname that starts with "l", then it's dead easy to
> match that in syslog-ng configuration. Downside is that it is painful to
> introduce. But you could use a mixed approach, where all the existing
> clients keep their hostnames (and you put them explicitly in the
> filter), and all the new ones get named with this naming scheme.

More information about the syslog-ng mailing list