On 08/29/2011 03:14 PM, Cliff Perry wrote:
One of the main design decisions I would consider for behaviour is...
If the logging daemon is down, do all actions fail - or do you still
allow successful actions, knowing that it cannot log the event.
- Or do you have a fall-back temporary on-disk cache to be played back
into the logger once it is running again.
In short, my personal preference is not to become a toaster if audit
logging has crashed (including out of space to write).
Cliff
We had a discussion about this as well and we decided that if it can't
be logged then it shouldn't happen at all. We want the admin to always
know what modifications have been done on the client systems. It is not
acceptable for some actions to complete and the admin to not be able to
see them in the logs (or see them later - there is no way to guarantee
that the on-disk cache will be played back into the logger, but the
action will still have been completed).
So if the auditlogging server is down, then the XMLRPC API is down. The
whole point of audit logging is to not let anything "important" pass
through without having a record of it. You can of course turn the
logging off from the server.
-Ionuț
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel