Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tlug] comand-line recording...



On Mon, Sep 28, 2009 at 22:38, Curt Sampson <cjs@example.com> wrote:
> Well, that's a very sensible approach if you feel that your department
> is in competition with the audit department, and you don't care if the
> audit guys can do their job correctly. That attitude, in general, tends
> to be detrimental to the overall business, though.

I don't understand where you want to push this discussion, sorry...
I may have my thoughts, but with limited resources, I prefer to answer
real business needs instead of challenging non-business units...

> Generally, in the agile world, it's one of the main responsibilities of
> the IT guys to educate the business side on what can be done, and inform
> the business guys when they're asking for what appears to be the wrong
> thing. That's just basic professional responsibility, in my opinion.

This is what I do with "business" people.

>> Of course, we do not share any authentication information! this is why
>> we use application specific accounts (what you call "role account", what
>> I call "application account"). Not accessible with ssh, etc, etc...
>> ...
>> "role account". This is exactly what I am speaking about.
>> "sudo -u role-account" is exactly what I call using a "generic account".
>
> Then you have logs of this stuff already, assuming you set things up well!

Well... This was my initial question. I need to "su/sudo" to some
account, and have a record
of what I do... "sudo" is painful for every command. And again, it
will fail to record everything,
as we discussed previously.

>> Again, how do you practically manage apache (or equivalent) config files?
>> They are in CVS or so, apparently. But how do you make the *real*
>> change?
>
> I roll it out, the same as I deploy the "real" change from a C file. It
> takes but a moment. If it takes you signficantly longer, the problem is
> your rollout procedure, not how you might modify the script command.
>
> Keep in mind that those configuration files are code just as much as C
> code is. If you change them, they change the behaviour of your system.
> If you break them, they break your system.

I meant: not only the config file, but the "kill/restart" procedure,
that I want also
to monitor.
We are no more in my initial question.

>> I was thinking about "greping" on prompt rather than commands, just to
>> get rid of the commands output (this was my first issue with "script",
>> if you remember).
>
> Which will work fine until someone changes the prompt (as I usually do).

This will not be an issue, as we can figure out which is your own prompt...
"script" will be enough for me then, as nothing better has been proposed...

Thanks for your time, anyway.

br.

-- 
2 + 2 = 5, for very large values of 2.


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links