[CentOS] How protect bash history file, do audit alike in server

[m.roth at 5-cent.us]

Les Mikesell wrote:
> On Wed, Aug 8, 2012 at 4:03 PM,  <m.roth at 5-cent.us> wrote:
>> >>
>>> Errr, what?  No sensible VCS forces you to wait for someone else to
>>> finish their portion of the work.
>>
>> You're wrong. I've worked in small and large teams, and *ALWAYS* we
>> checked out with locks. If two people need to work on one file, then
>> either they need to work together on one copy, and check it back in
>> together, or the file needs to be split into more than one, so that one
>> person can work on each.
>
> If you want to force your team to wait for your change, fine - and
> sometimes it is even a good idea, but the tool should not make that
> decision for you.

Yes, I do want to force them to wait for what one person's working on -
it's not like everyone else isn't working on *other* things. And each
should be independent - changing an interface; that is, the parameters a
function (sorry, "messages that a method) is expecting is always a big
deal.
>
>> I have vehemently been against the fad of the last half a dozen or so
>> years, with multiple people checking out and working on the same file.
>> I've seen hours or days of a developer's work wiped out, when a team
>> lead hacked some quick fixes, then merged the file back in.
>
> You can't do that without knowing it.  If the user ignores the other
> changes in a conflict or doesn't resolve them correctly, blame the
> user just like you would if he typed that in as part of his own
> changes.

Yes... and one of the main points of a correctly configured VCS is
explicitly to prevent one person from screwing up others' work.
>
>>> That part is true enough, although it is not so much who does the
>>> work, it is following the procedure.   If you are going to be picky
>>> about who does what, there should really be a QA person involved that
>>> makes the actual decision about what version should be running in
>>> production in between the developers making changes and the operators
>>> doing the installs.
>>
>> I haven't had q/a move to prod; that was always the prod admin's job,
>> after q/a was done, and had promoted it to prod.
>
> OK, both QA and operations should agree - QA as to whether a version
> can be released and operations as to when it happens.

Absolutely, though in a small shop, that tends to be developers and admin.
Not that many places, unfortunately, have one or more folks who are only
q/a.

       mark