[ Re-sending due to earlier failure. ]
On Mon, Feb 10, 2003 at 06:03:07PM -0800, Julian Elischer wrote:
>
> Our client wants the following 'features'
> and we'd LIKE to be able to at least say "yes we can do that", even if
> we can also say "but we don't think it's a good idea".
>
>
> 1/ Comm
On Tue, Feb 11, 2003 at 04:43:46PM -0800, Julian Elischer wrote:
+> > Did we somehow break acct(2), or is that somehow inadequate to the task? It
+> > should be ideal for what Julian's customer wants, I would think. See also
+> > acct(5), sa(8) and accton(8).
+>
+> Acct doesn't give the argume
On Tue, 11 Feb 2003, Wesley Peters wrote:
> On Monday 10 February 2003 23:59, Dag-Erling Smorgrav wrote:
>
> Did we somehow break acct(2), or is that somehow inadequate to the task? It
> should be ideal for what Julian's customer wants, I would think. See also
> acct(5), sa(8) and accton(8)
On Tue, Feb 11, 2003 at 03:32:28PM -0800, Wesley Peters wrote:
> On Monday 10 February 2003 23:59, Dag-Erling Smorgrav wrote:
> > Julian Elischer <[EMAIL PROTECTED]> writes:
> > > 1/ Command logging. We're thinking that a hacked version of the shell
> > > that logs commands may do what they want, b
On Monday 10 February 2003 23:59, Dag-Erling Smorgrav wrote:
> Julian Elischer <[EMAIL PROTECTED]> writes:
> > 1/ Command logging. We're thinking that a hacked version of the shell
> > that logs commands may do what they want, but personally I
> > think that if you are going to log things then you
Thus spake Dan Nelson <[EMAIL PROTECTED]>:
> In the last episode (Feb 11), David Schultz said:
> > Thus spake Julian Elischer <[EMAIL PROTECTED]>:
> > > Our client wants the following 'features' and we'd LIKE to be able
> > > to at least say "yes we can do that", even if we can also say "but
> > >
In the last episode (Feb 11), David Schultz said:
> Thus spake Julian Elischer <[EMAIL PROTECTED]>:
> > Our client wants the following 'features' and we'd LIKE to be able
> > to at least say "yes we can do that", even if we can also say "but
> > we don't think it's a good idea".
> >
> > 2/ they wa
Thus spake Julian Elischer <[EMAIL PROTECTED]>:
>
> Our client wants the following 'features'
> and we'd LIKE to be able to at least say "yes we can do that", even if
> we can also say "but we don't think it's a good idea".
>
>
> 1/ Command logging. We're thinking that a hacked version of the s
On Mon, 10 Feb 2003, Julian Elischer wrote:
> 1/ Command logging. We're thinking that a hacked version of the shell
> that logs commands may do what they want, but personally I
> think that if you are going to log things then you really want to
> PROPERLY do it, and log the EXEC commands along w
Julian Elischer <[EMAIL PROTECTED]> writes:
> 1/ Command logging. We're thinking that a hacked version of the shell
> that logs commands may do what they want, but personally I
> think that if you are going to log things then you really want to
> PROPERLY do it, and log the EXEC commands along with
> #2 sounds like a great DOS to me..
> operator
>
> operator
>
> operator
>
put a two (ten???) second delay after each failed login?
as for the commands, you could hack sys/kern_acct.c to include
command arguments and acct.h for struct acct and all the dependent
utilities and libraries and re
On Tue, Feb 11, 2003 at 03:40:28AM +0100, Pawel Jakub Dawidek wrote:
+> +> Anyoone have any modules to REALLY log execs?
+>
+> Yes, we got:
+>
+> http://cerber.sourceforge.net
+>
+> If You want only execve() logging You can try rexec.
Or wait on cerb-ng first release. There is defined such
On Mon, Feb 10, 2003 at 06:03:07PM -0800, Julian Elischer wrote:
+> Anyoone have any modules to REALLY log execs?
Yes, we got:
http://cerber.sourceforge.net
If You want only execve() logging You can try rexec.
--
Pawel Jakub Dawidek
UNIX Systems Administrator
http://garage.freebsd.pl
A
13 matches
Mail list logo
