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

[Les Mikesell]

On Wed, Aug 8, 2012 at 2:07 PM, Heng Su <ste.suheng at gmail.com> 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.

A small team that is supposed to know what they are doing is a
somewhat different picture than I had before.

> 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'?

Still, your first thought should be about how to prevent the problem
instead of how to blame the right person.   You basically need to
ensure that the only way to get the jar file into place is copy it
from a known/tested version using a predictable deployment script
where the script tests usability and has a way to back out the change.
  For a couple of jar files this might be as simple as a script
wrapping rsync with ssh keys set up for each potential user (from
their staging/text box), or you might commit to a subversion
repository and update production from there.  For anything more
complicated you probably want a jenkins CI server testing things
(trivial to set up) and one of its deployment plugins.

-- 
   Les Mikesell
      lesmikesell at gmail.com