Introduction
Landing in a new startup company has its cons and pros.
The pros being:
- You can do almost whatever you want
The cons:
- You have to do it from scracth!
The Developers
Linux developers are not dumb. They can’t be. If they were dumb, they couldn’t have developed anything on Linux. They might have been called developers on some other platforms.
I was opted quite early about the question of:
“Am I, as a SysAdmin, going to give those Linux developers root access on their machines?”
Why not:
- They can cause a mess and break their system in a second.
A fellow developer (the chowner) who ran:# chown -R his_username:his_group *
He came to me saying “My Linux workstation stopped working well!!!”
Later on I also discovered he was at /, when performing this command! ๐
For his defence he added: “But I stopped the command quickly! after I saw the mistake!” - And there’s no 2, I think this is the only main reason, given that these are actually people I generally trust.
Why yes:
- They’ll bother me less with small things such as mounting/umounting media.
- If they need to perform any other administrative action – they’ll learn from it.
- Heck, it’s their own workstation, if they really want, they’ll get root access, so who am I to play god with them?
Choosing the former and letting the developers rejoice with their root access on their machines, I had to perform some proactive actions in order to avoid unwanted situations I might encounter.
Installation
Your flavor of installation should be idempotent, in terms of letting the user destroy his workstation, but still be able to reinstall and get to the same position.
Let’s take for example the chowner developer. His workstation was ruined. I never even thought of starting to change back permissions to their originals. It would cause much more trouble in the long run than any good.
We reinstalled his workstation and after 15 minutes he was happy again to continue development.
Automatic network installations are too easy to implement today on Linux. If you don’t have one, you must be living in the medieval times or so.
I can give you one suggestion though about partitioning – make sure your developers have a /home on a different partition. It’ll be easier when reinstalling to preserve /home and remove all the rest.
Consolidating software
I consider installing non-packaged software on Linux a very dirty action.
The reasons for that are:
- You can’t uninstall it using standard ways
- You can’t upgrade it using standard ways
- You can’t keep track of it
In addition to installing packaged software, you must also have all your workstations and server synchronize against the same software repositories.
If user A installs software from repository A and user B from repository B, they might run into different behavior on their software.
Have you ever heard: “How come it works on my computer and doesn’t work on yours??”
As a SysAdmin, you must eliminate the possibilities of this to happen to a zero.
How do you do it?
Well, using CentOS – use a YUM repository and cache whatever packages you need from the various internet repositories out there.
Debian? – just the same – just with apt.
Remember – if you have any software on workstations that is not well packaged or not well controlled – you’ll run into awkward situations very soon.
Today
Up until today Linux developers in my company still posses their root access, but they barely use it. To be honest I don’t think they even really need it. However, they have it. It is also about educating the developers that they are given the root access because they are being trusted. If they blew it, it’s mostly their fault, not yours.
I’ll continue to let them be root when needed. They have proved worthy so far.
And I’ll ask you another question – do you really think that someone who can’t handle his own workstation be a good developer? – think again!
Bashing Linux 
Interesting article…
I think it is all about understanding. 5-10 years ago, most “professional” Unix developers worked only as root. Even today most sys-admins login to system as root.
Why? They are not users… Once they become familiar with “using” their
system they just would not work as root any more.
Yes… To be honest, I would like to give away all administration tasks. Unfortunately I’m forced to do them. I prefer spending my time rather on programming then administrating the system.
I know brilliant programmers that do not really know how to administrate their Linux stations. Why? because they are very new
Linux Desktop users.
They will never be able to perform all of the administrative tasks. But are they able to try and carry any?
Obviously if you are a good SysAdmin – they will never need to perform any!
The question is – do you allow them to have the possibility of performing a certain administrative task? – or do you collectively revoke their root access?
Or perhaps it is something in between, where only a few are allowed to r00t their workstation.
I still believe that a new Linux user, who was a brilliant developer on a different platform will adapt very quickly. I even saw it happening twice!
A. Good post about an ongoing debate..!
B. Users need root to mount? they can use pmount!
C. /home on another partition – brilliant for quick reinstallations. indeed.
D. Your used a MEM SOFIT in the first sentence of the consolidating software!
E. Not exactly related, but recently I’ve heard about people keeping their homedir files (except some exceptions) in git. This is really great in terms of change tracking / backup on remotes.
Instead of explicit root, why not sudo? It’ll allow you to track what they do, so if they did break something, and you want to know what they did to break it, you have an audit of what they did.
I’ve had windows users’ swear up and down they didn’t do something, but courtesy of our increased level of logging, I tracked down exactly what they did.
To be honest, I’ve already created aliases to allow them to transparently run commands as root, without even knowing, for instance ‘yum install XXX’ will automatically run with sudo. It is about creating the conveniences the developers need, so they never really need to run commands explicitly as root.
Sudo and logging is indeed a good idea but I want to mention 2 more things:
1. It is highly proficient developers I’m dealing with and if they are not trustworthy, what am I doing with them at the first place?
2. In addition to that, as I mentioned in the post – it is also about building a good and trustworthy relationship with the developers, letting them do mistakes, admit the mistakes and let them learn from the mistakes. If a developer will be afraid of admitting something he did, it is not a technical problem, it’s a much deeper social problem we as SysAdmins must strive to resolve.
Oh, and share with us what did they do, or link us!
It is always funny to hear ๐