What about the "Log Details" report of type "Server Usage" ?
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).
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])
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.
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)...
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.