Hi, 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? Jim "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@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 1.2.3.4 -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 1.2.3.4 ipset add linux 1.2.3.5 ...
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.
HTH