4 Replies Latest reply on Apr 15, 2010 11:42 AM by 807567

    Changing syslog port


      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.

      Hope this makes sense. Can anyone help?


        • 1. Re: Changing syslog port
          svcadm disable system/system-log:default

          should take care of it.

          • 2. Re: Changing syslog port
            Hi Alan

            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.

            • 3. Re: Changing syslog port
              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.

              2. Syslog-ng

              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.

              • 4. Re: Changing syslog port
                Hi Alan

                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.