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

[m.roth at 5-cent.us]

Heng Su wrote:
> On 08/09/2012 02:46 AM, Les Mikesell wrote:
>> On Wed, Aug 8, 2012 at 1:23 PM, Heng Su <ste.suheng at gmail.com> wrote:
>>> Normal flow is get codes from SCMs repository or do CI server, however,
>>> you know some small company got such thing messy (my current company,
>>> lol ^_^). Sometime you have to update only one file of the project.
>> Why does it need root permissions to update this file?   It doesn't
>> cost anything to add a user to own your application's resources.
> OK, assuming there is an jboss application server  running under user
> 'jboss' in PRD server, and we have 4 developers want to update the jar
> file in that server.
> they always login use same user 'jboss' to do updating file in server,
> how can I tell which guy doing what things cause the server down as they
> use same user account 'jboss'?
>
> So I don't know how should I do as I am a shoddy server admin, so I use
> root to maintain the application server. then create 4 account in server
> for individual developer. So if they want copy, move or other operations
> on those deploy folder or files. Let them use sudo. Now I got all
> commands they did in /var/log/secure, ^_^

Now I have a picture of your problem.

<flame, but not to you, Heng Su>
VCS's that let multiple people check the same object out at the same
time.... You're *exactly* back where you were before people were using
VCSs.
</flame>
It sounds like the use of the VCS is no different than saving them in a
backup directory, which is *not* how it should be used.

Set up a real version control system.
Configure it so that they *must* check out with a lock, so no one else can
edit it.
Extract to test, and test the damn thing. Then label it.
Then, when they agree it's ok, you, the admin, get to install it, NOT THE
DEVELOPERS!!!!! AND you extract it by label (or whatever the VCS calls it)
to production directly from the VCS. You're guaranteed that the wrong file
won't be moved to production.

Doing it that way, it's *very* easy to roll back (another thing VCSs are
for).

And don't let them do *anything* with production: that's your job. Right
now, start logging every time something wrong goes into production. If
what what I read between the lines that you're suggesting is the case, it
should take a week or so to have a number of problems; then dump it on
your manager, and tell them this is a problem, here's the evidence of the
problem, and here's the answer (as above, with you as admin, as the
gatekeeper to production).

        mark, many years as developer, 7 years with PVCS as config mgr,
                and plenty of years as sysadmin