On Wed, Aug 8, 2012 at 1:13 PM, Heng Su <ste.suheng at gmail.com> wrote: > >> No, it is not a common situation. Normally you should not let anyone >> you don't trust become root. For fairly obvious reasons... > Let said if you want get low price to set up multiple application > servers and outsource different server set up thing to different person > on internet. > You have to give the root rights to them, maybe you even don't know > which command limitation should be given as you are not a master. > so just give all permission to them. > I think this scenario happens in small company have no enough man power > to do it. Yes, outsourcing happens, but what is your role in this picture? If someone else is managing the machine let them do their job and take the blame if it breaks. If someone else is managing an application, normally that application should run as a non-root user and should not need root access for most configuration/update tasks. If you need to be able to fix it regardless of what happens, take frequent backups. > previous scenario also applicable, different developer do code updating > in server due to above reason. If the production server matters, developers should be working on a test/staging server with some sort of automated updates pushed to production. > you can not limit such as do not let them user 'cp' or other common > commands as I want to know which guy overwrite wrong file. Even two > user, I also need to know which one do wrong things. In that sort of environment I would try to split the services onto separate VMs or smaller servers, each managed by one person or team that is responsible for fixing it if anything breaks. Knowing who did something wrong really isn't going to be that much help in making things work again, especially for the parts managed by someone else that just happen to be on a shared server. -- Les Mikesell lesmikesell at gmail.com