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

[Curt Sampson <cjs@example.com>]

On 2009-09-28 21:19 +0900 (Mon), Bruno Raoult wrote:

> You misunderstand me for sure: We discussed this point also in my
> team, and don't think this request is good at all... But I have no
> reason to do more (than requested) on this subject, because this would
> just take us more time for *nothing*... I just consider this as an
> "administrative" request.

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.

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.

> 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!

> 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.

> > Right. That in no way precludes using revision control.
> 
> If time is an issue, yes it is: Check-in, check-out, then sudo to the
> production account on 3-4 machines to get the new version is just
> loosing these 3 minutes... Better change first on prod machines, and
> later make things updated on revision system (what we do)...

You don't have to "lose..3 minutes" doing this; that you have decided
you must have a system where it costs you this is your decision, not a
law of nature.

In my world, I update and test the change on a staging system commit
it, and then roll it out on the production machines (where, by the way,
if you use CSSH it takes no longer to do it on thirty machines than it
does on one). It takes a few seconds more than your method, and what do
I get for those few seconds? I get to test changes without interfering
with and possibly taking down the production server, I greatly reduce
the chance of human error causing a production configuration to be
different from intended, I've got the ability to easily roll back to any
previous configuration, and I've got much better and cleaner audit logs
of everything, all basically for free.

Just because in your particular system at the moment you can't just
check a file into revision control and have everything get a whole lot
easier and better does not mean that it's not possible to design such a
system.

> 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).

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
           Functional programming in all senses of the word:
                   http://www.starling-software.com