This content has been marked as final. Show 4 replies
Thanks for the response. This stops the port conflict but still leaves me with the problem of logging on the syslog server itself.
Because system-log is no longer running, the BSM->syslog plugin no longer functions and nothing is delivered to the third-party syslog.
I guess what I really need is either
a) system-log to run on a different port
b) another means of delivering BSM audit messages to port 514 on the local host.
Ok, you have three apps which appear to be able to listen on port 514.
1. The original syslogd that comes with Solaris by default.
3. Some third party app.
It appears that the goal is to kill off the original syslog daemon so the third party app can take over as it also listens on port 514.
The svcadm command that I gave you did this but now you're saying that the third party app can't act as a replacement?
What is the name of this third party app? Usually this is where someone says that it's an in-house app in which case you can change it in the code itself.
Thanks for your response. I'm going to be a real pain now because this is a highly secure project and I really can't post any info about the products used (it's not an in-house app though; it's a COTS product).
The third party app is not primarily a syslog server. It gathers data "for various purposes" and the gathering functionality includes an implementation of a syslog-compliant process listening on a port (hopefully 514) which accepts syslog info.
We then do something proprietary with this data (which happens to be BSM audit data converted to syslog via the plugin).
The goal is simply that this data can be accepted into port 514 on the "third party app" server from any Solaris box, including the server itself.
The problem is that, while I have successfully replaced syslog so there is no bind conflict, there is now nobody who can do the job of getting BSM data across into port 514 on the same machine. Essentially, it appears the syslog service had a dual role - firstly, to decide (via /etc/syslog.conf) what to do with log data and secondly, to listen for syslog events and put them into /var/adm.
What I was hoping was that we could leave syslog doing the bit about shovelling BSM out to whatever syslog.conf defines as the handler for audit.notice events (in this case, it just so happens that the loghost is localhost). But it seems that if syslog is running at all, it will always bind to port 514 - whether it needs to or not.
So essentially, I the problem is not really with the third party app; it's with the de-coupling of those two parts of the syslog daemon's job.