I'm running Solaris 10 on SPARC and I'm using the BSM syslog plugin to divert BSM info to syslog.
I want to then use a central loghost to aggregate all logs from multiple Sol 10 boxes.
The problem I'm having is on the box acting as loghost. I'm not using syslog or syslog-ng to listen for connections; I'm using a third-party app which listens on the syslog port and "does something" with the data. However, it fails to bind to port 514 because inet already has it open.
Even though I've switched off the ability for syslogd to accept incoming connections, it still binds to 514. I presume this is simply the implementation for syslogd on the local host - i.e. when an event occurs it is sent to syslog on the local host via port 514.
The only workaround I have at present is to start my third-party app on a different port. This means all machines using it will also have to log to that port.
Is there any way of stopping syslogd listening on 514? I guess what I want it to do is to connect to 514 to deliver its log information but not to listen on it itself. Can I change the port it listens on? I've tried changing /etc/services but to no avail.
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.