6 Replies Latest reply on Apr 20, 2006 3:53 PM by Michael Mraz

    Reporting on all changes via BL

      Question: Can anyone think of a good way to report on all changes made through BladeLogic against a server? This is beyond using snapshots and audits, but rather generating a report that shows all changes. The best strategy I can think of is to parse a server's agent Transactions directory and parse the bldeploy.xml logs or undo files. And it's been pointed out that this will only track BLDeploy-based changes. The agent log must store the other info.


      Does anyone have any other ideas?

        • 1. Re: Reporting on all changes via BL
          Bill Robinson

          What about the "Log Details" report of type "Server Usage" ?

          • 2. Re: Reporting on all changes via BL

            Log details does not capture the specific transactions that take place in a BLDeploy. Since BLDeploy is the most complex and safest way to push changes, I would most likely suggest that all deployments go through there. And I don't believe those specific transactions are recorded in the rscd.log but are recorded only in the Transactions logs, so we'd need to parse through there.


            This would also involve turning off authorizations for ad hoc file administration, pure file deploy jobs, and possibly NSH script jobs to push all changes through BLDeploy. Otherwise transaction reporting would have to include multiple sources (bldeploy.log and rscd.log).

            • 3. Re: Reporting on all changes via BL
              Bill Robinson

              This would mean no nsh commands could be run, what about browsing the filesystem, hotfixes, etc - that's all in the rscd log too - or are you only concerned w/ write access?


              so it looks like we'd need:

              1-parser for the transaction logs? - maybe the rscd.log parsing would work...

              2-include the transaction log in the collect_agent_log scripts (collect_agent_log.nsh and load_agent_logs.[bat|sh])

              • 4. Re: Reporting on all changes via BL

                Right. But again, I think transaction logs are more important, as all changes that are approved and effected by a change management process should come through the system that way. I would judge RSCD.log entries to be secondary in importance.


                It's tempting to use the well-formed undo logs in the Transactions directory, but given that an Undo will eradicate those logs, that seems like a suboptimal solution.

                • 5. Re: Reporting on all changes via BL
                  Bill Robinson

                  well, the rscd.log should capture someone doing an "rm -rf /foo" or "useradd badguy" - all the adhoc actions anyway.


                  hmm - what about raising the level of the rscd logs? will that capture anything else? those transactions are being passed through the agent, so it should be able to capture something, in theory.


                  look in the rsc\log4crc.txt:

                  category name="bldeploy" priority="debug"

                  category name="bldeployConsole" priority="debug" appender="stdout"

                  category name="bldeployAppserver" priority="error" appender="blbasic"


                  maybe the bldeploy needs to have an "appender" option added to it?

                  so make the appender like the rscd category (putting it into the rscd.log file)...

                  • 6. Reliability of activity logs

                    nexec -e "vi rscd.log"

                    ...or a zillion other ways to modify the file and erase your tracks.


                    Unless and until a collect agent logs job has been run the information is only local to the host and ripe for subversion. I still think the rscd should have an option to log activity remotely (via syslog or some other manner with a handshake or validation) which would prevent local deletion. Signing the message with the host's license certificate as a crypto key should prevent denial of service against the logging server to prevent logging of malicious activity as well.


                    Of course, there is always the ability to escape to a sub-shell in an interactive command and do whatever you want as the user the role maps to without it being logged. This means some type of keystroke logging is necessary to get a record of what was done. That or very regular system wide audit jobs. Both of those solutions have problems of their own such as logging passwords or the large disk I/O thrash a filesystem wide audit job would cause.


                    This has been a pet issue of mine for quite a while. Our staff wants to "nexec -e ksh" or "nexec -e 'su -'" and not have to deal with NSH CLI and all the non-standard behavior, configuration, environment and performance its use entails. We have to tell them "No, you can't do that" because all activity needs to be logged. That makes me the badguy and many users unhappy. So, I feel your pain.