[techtalk] system administration responsibilities question

Magni Onsoien magnio+lc-techtalk at pvv.ntnu.no
Thu Jun 7 10:08:31 EST 2001


Yvonne:

> Hi, all. I'm unlurking here... Here is a question for anyone who deals
> with the web in some way in their system administration job...
> actually, for any sysadmin...  If you are the system administrator over
> a (web) server, do you administer
> all the services on that box? Including databases? We have maybe 16-20
> Linux (mostly) and SCO servers running
> various services. My boss wants me to let him know what services are
> running on our two web servers including apache, samba,
> mysql, etc. and he is thinking of delegating responsibilities across the
> servers to four of us... a "web admin", Unix admin,
> NT admin, and network support person--his words were, he wants the
> services divided into "discrete parts to be allocated
> to individuals."  Is this the way it's done in the "real world?" Or does
> it vary, according to the size of the company?

In my former job (system administration at uni while being a student
there) the webservers were maintained by us (the sysadmins), while the
contents of all the services was maintained by Somebody Else (actually
the name of one of them is Else :)). In principle this would work: the
sysadmins make sure the OS and all software, including webservers, are
working, while Somebody Else make sure the services contain something,
develop new web applications etc. Officially those people didn't have
the root password (or sudo), but in practice they had it. However, we
used every opprtunity to yell at them when they dared to use it, since
we a) monitored the use of it (sulog w/ username, rootlogin not allowed)
and b) they often broke something.

The problem with this was mainly lack of communication. The sysadmins
upgraded something, a database stopped working and everybody became rude
because nobody was informed. Or the admins planned an upgrade in June,
while the application people expected the upgrade in February, since
they started development of something new then. Or the admins closed
down the msql database because nobody seemed to use it - two months
later somebody suddenly wants to use it and it's down.

The routines are getting better there now, but it's important to know
that such things often happen. I don't say it's a bad idea to split the
responsibilities for a server between several people, but I'd say it
would be best to have one person (or group, in larger organizations) 
responsible for the OS and basic software (like C-compiler, sh-utils 
and other stuff that everybody needs) and  one person (group)
responsible for application software and maintenance of that - i.e.
apache, mysql, logrotate, analog and other software closely related to
the services running on the server. If the server is a webserver and a
mailserver, there can easily be two persons (groups) responsible: web
and mail. However, since mysql often is closely connected to the
webserver, the same person/group should be responsible for both of them.

As for samba on the webserver, this should probably be the webpersons
responsibility IF the userdatabase of samba is somewhat dynamic and
varies/increases as more people need access to the files on the
webserver server. If samba is just a service like NFS and it's pretty
static, i.e. no users coming "hey, I need a virtual server here and I
need access to it from my PC, you fix that?" (and you then make this
single person a samba-account), it should belong to the OS-person/group.

(At my uni samba for students is default, so no extra student sambausers
are made. But for the employees a sambauser is made as they ask for it,
so that's quite a lot of administrationn. Today's solution of "ok, Else
will fix a db for you, the sysadmins a webserver and Somebody will fix
samba access" is NOT good :))

So, my conclusion is that splitting up responsibilities is not at all a
bad idea, but it must be done with care, making sure ONE person is
responsible for one group of stuff - it shouldn't require two persons to
upgrade php because a new version of mysql is needed.

Centralized OS-administration (OS+basic software) is probably also smart,
to ensure the servers are uptodate with security patches and to make
sure they are similar enough to increase redundancy (i.e. possible to
move services between them without too much reconfiguration/compiling).

> I was hired on as the administrator of two NT web servers, then we
> switched to Linux, the guy who hired me left, the new
> boss thought I was only doing the web part of administration, and gave
> the system administration over to the Unix admin. I'm
> left with very little system administration, really, none to speak
> of...Now my boss is looking for some other service to turn over
> to me, rather than one box.  It's a little frustrating, since I want to
> do system administration, and I'm not getting the experience...

If you are unsatisfied with your duties, do something about it :) Tell
your boss about it and propose you all share the work between you. Keep
in mind that sharing the responsibility so that ONE single person is
responsible for all instances of a service is often an effective way of
running things, so try to share the work according to that: mailserver
services, webserver services, Linux OS, SCO OS, database services
(excluding webserver databases), NT OS, backup, centralized software
repository (if you have that) etc. Most important: DON'T TALK ONLY TO
YOUR BOSS!! Also talk to your work mates. The boss can hardly (without
pissing you all off) force all of you to work in a way none of you want,
so if you talk with the others about how to share stuff and what you
want to do and in what areas you want to develop it's probably easier to
talk to your boss too.

Anyway it's very stupid to have ONE person as a single point of failure,
so even if you won't be THE responsible for ssytem administration, it
would be very smart of your company to let you learn it so you can do
the tasks if the main sysadmin is on vacation, sick, travel etc.


Magni :)
-- 
sash is very good for you.




More information about the Techtalk mailing list