> I'd like to let this run. I'd like to see if it makes sense
> to audit in addition to build the history. The down side being
> an additional required privilege.
The zpool command is in the ZFS Storage Management Rights Profile
and the zfs command is in the ZFS
On Wed, May 10, 2006 at 08:15:15AM -0700, Gary Winiger wrote:
> > >> The Solaris audit facility will record a command execution as soon as
>
> > Yes, that's a special case of my reason #3 - (sufficient) auditing may
> > not be enabled.
>
> I'd like to let this run. I'd like to see if it
Gary Winiger wrote:
The Solaris audit facility will record a command execution as soon as
Yes, that's a special case of my reason #3 - (sufficient) auditing may
not be enabled.
I'd like to let this run. I'd like to see if it makes sense
to audit in addition to build the hist
> >> The Solaris audit facility will record a command execution as soon as
> Yes, that's a special case of my reason #3 - (sufficient) auditing may
> not be enabled.
I'd like to let this run. I'd like to see if it makes sense
to audit in addition to build the history. The down
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 aud
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 c
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 so
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 <[EMA
Nicolas Williams wrote:
On Thu, May 04, 2006 at 12:39:59AM -0700, Jeff Bonwick wrote:
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 h
On Thu, May 04, 2006 at 12:39:59AM -0700, Jeff Bonwick wrote:
> > 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 m
> 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 i
Ed Gould wrote:
On May 3, 2006, at 15:21, eric kustarz wrote:
There's basically two writes that need to happen: one for time and
one for the subcommand string. The kernel just needs to make sure if
a write completes, the data is parseable (has a delimiter). Its then
up to the userland pars
On Wed, May 03, 2006 at 03:34:56PM -0700, Ed Gould wrote:
> I think this might be a case where a structured record (like the
> compact XML suggestion made earlier) would help. At least having
> distinguished "start" and "end" markers (whether they be one byte each,
> or XML constructs) for a re
On May 3, 2006, at 15:21, eric kustarz wrote:
There's basically two writes that need to happen: one for time and one
for the subcommand string. The kernel just needs to make sure if a
write completes, the data is parseable (has a delimiter). Its then up
to the userland parser (zpool history)
14 matches
Mail list logo
