Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Just started working with a small group of front-end web developers who all login to the dedicated WHM/Apache production server with root to modify client web sites. They claim they do not want to have to log into each of the individual site accounts because there are so many.

I'm not an experienced sysadmin but I know this is wrong.

What is the best way to create logins for these developers and assign permissions to have full rwx privileges to all client assets in the /home/ directories?

Additional Information: * When I say developers I mean CSS/HTML front-end designers. Our developers use git as a CVS and do not work on the server until we push new versions of the CMS.

share|improve this question
add comment

6 Answers

I'm not an experienced sysadmin but I know this is wrong.

Actually, what's really wrong is that there are developers on your production machines. :-/ (Your life will be better when you have another machine for them to test their changes on and a scripted way to get those changes to the production setup. Your life will really get better when they're checking their code into a central source code repository (svn or the like) and deploying it to a staging environment for testing, and only then to to production.)

Unfortunately, I'm not sure I can provide much constructive advice without knowing more details about your situation, but here are a few things that may help:

  • Set up sudo to allow your developers to do things as the individual clients
  • Use group-writable modes on the directories in question
share|improve this answer
3  
A lot of the answers here are good, and I rally like the idea of using sudo or group write. But the larger issue is that no one should have root outside of the SA group. That's just begging for trouble you don't want. So, whatever you do, take back root. I've never seen an instance where root was needed (outside of software installs on occasion) by anyone other than the SA. –  Milner May 27 '09 at 14:45
    
@Milner Very true. If you give non-admins root access, it will go wrong someday. When I started at a small webdev company, a developer managed to 'chmod 777 /' the server. He had a permissions problem in the current dir, and was wondering if . or / meant current working dir. He picked wrong, and I spent a day rebuilding the server. –  Martijn Heemels Jun 10 '09 at 20:37
add comment

Create a developer group, and chown all the files as that group. Then give g=rwx to all the files.

Also, having developers edit the sites I would think is a sign of bad work flow. My recommendation of a simple release management would be:

Have the websites checked into a code repository using something like subversion. Then have them create tags with deployment instructions. Then the admin can deploy using those tags and deploy instructions and ideally automate that process. Also, the admin can make sure there is a strategy to revert back.

share|improve this answer
add comment

From a security standpoint, I would recommend putting the individual sites in a different directory structure entirely, and linking to them via vhosts. I.e. /var/www/client1, /var/www/client2. From there create a new group called webdev (or whatever), and give that group write permissions to the /var/www/client* trees.

That being said, I would also recommend putting up a test and/or Q/A environment to make the changes, then once verified have them rolled out to the production server. Ideally, the webdevs would not have access to the production system, and a separate web admin, or webmaster would be the one to roll out the new pages. Whether your culture could support that kind of separation of duties is another matter entirely.

share|improve this answer
add comment

Personally I believe a developer shouldn't have any rights on production box but that's because I came from a very rigid background where we used Rational Unified Process as law. Dev was theirs to do what they wanted with, Acceptance they had limited rights but changes went through me (sysadmin) and Production they had no rights to and any/all changes went through me on a scheduled day unless the change was emergency. What it really comes down to is what your management policy is on the issue. If its only a small shop then obviously what I just outlined is massive overkill but still good practice to think about. Best thing is to go with least privilege mindset and only give them what they need. All else fails just make sure you're getting good backups to rollback whatever changes may screw things up (fyi snapshots with VM's are a godsend for these sorts of changes just don't let the snapshots live more than 48 hours or they bloat).

share|improve this answer
add comment

Because of the way cPanel needs to have certain permission on certain folders/files some of the above won't work (in other areas yes, with cPanel/WHM, no).

I would do one or both of the following:

1) Create a reseller in WHM that has access to the accounts so the devs can get into WHM as needed but you can customize the priviledges the reseller has in terms of server modifications. This way the devs can do cPanel related things for customers but not screw up the server as a whole.

2) Use ssh keys to let them in AS THE USER that owns the files. Since you are using cPanel the ssh keys would go in /home/username/.ssh/authorized_keys You could keep a "master" authorized_keys file and distribute it as needed to the /home/username directories.

With this method, if a dev leaves you can just pull his key from the "master" authorized_keys file and dist out a new one minus the old key.

I also agree with Luke's answer above.

share|improve this answer
add comment
mkdir /var/www
chown root:www-data /var/www
chmod 2775 /var/www

Put the users in the www-data group.

share|improve this answer
    
This answer could do with some explanation. –  Martijn Heemels Jun 10 '09 at 20:39
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.