This is just a request for elaboration/education. I find reason #1 compelling ehough to accept your answer, but I really don''t understand reason #2. Why wouldn''t the Solaris audit facility be correct here? (I suspect I''m about to have a Homer Simpson moment.) - jek3> From: Jeff Bonwick <bonwick at zion.eng.sun.com>...> > Why not use the Solaris audit facility? > > Several reasons: > > (1) We want the history to follow the data, not the host. If you > export the pool from one host and import it on another, we want > the command history to move with the pool. That won''t happen > if the history file is somewhere in /etc or /var. > > (2) For correctness, we want the record of the command to be written > in the same transaction group as the action it causes. That way > there''s no ambiguity about whether a given command did or did not > complete before something bad happened. > > Jeff >
Joseph Kowalski wrote:> This is just a request for elaboration/education. I find reason #1 > compelling ehough to accept your answer, but I really don''t understand > reason #2. Why wouldn''t the Solaris audit facility be correct here?The Solaris audit facility will record a command execution as soon as the program terminates. If some of the ZFS commands of interest cause asynchronous actions, you don''t know if the action really completed or not.>>From: Jeff Bonwick <bonwick at zion.eng.sun.com> > > ... > >>>Why not use the Solaris audit facility? >> >>Several reasons: >> >>(1) We want the history to follow the data, not the host. If you >> export the pool from one host and import it on another, we want >> the command history to move with the pool. That won''t happen >> if the history file is somewhere in /etc or /var. >> >>(2) For correctness, we want the record of the command to be written >> in the same transaction group as the action it causes. That way >> there''s no ambiguity about whether a given command did or did not >> complete before something bad happened.I''m surprised no one mentioned (3) Not everyone has Solaris auditing enabled. Scott
Scott Rotondo wrote:> Joseph Kowalski wrote: >> This is just a request for elaboration/education. I find reason #1 >> compelling ehough to accept your answer, but I really don''t understand >> reason #2. Why wouldn''t the Solaris audit facility be correct here? > > The Solaris audit facility will record a command execution as soon as > the program terminates. If some of the ZFS commands of interest cause > asynchronous actions, you don''t know if the action really completed or not.Or maybe not at all depending on the audit mask of the process. Which depends on how and when it was started and the contents of /etc/security/audit_control and the audit_user(4) database from the nameservice. It also by default doesn''t have the arguments logged which means that you won''t know which pool was impacted (yes you can turn that on and IMO it should be the default but it isn''t). -- Darren J Moffat
Darren J Moffat wrote:> Scott Rotondo wrote: > >> Joseph Kowalski wrote: >> >>> This is just a request for elaboration/education. I find reason #1 >>> compelling ehough to accept your answer, but I really don''t understand >>> reason #2. Why wouldn''t the Solaris audit facility be correct here? >> >> >> The Solaris audit facility will record a command execution as soon as >> the program terminates. If some of the ZFS commands of interest cause >> asynchronous actions, you don''t know if the action really completed or >> not. > > > Or maybe not at all depending on the audit mask of the process. Which > depends on how and when it was started and the contents of > /etc/security/audit_control and the audit_user(4) database from the > nameservice. It also by default doesn''t have the arguments logged which > means that you won''t know which pool was impacted (yes you can turn that > on and IMO it should be the default but it isn''t). >Yes, that''s a special case of my reason #3 - (sufficient) auditing may not be enabled. Scott