[ale] Where to Start?

[Michael B. Trausch]

On Fri, 2010-06-18 at 00:52 -0400, m-aaron-r wrote:
> Not to be contrary, since I believe the majority of enterprise
> operations are still Redhat centric, but I was surprised
> by the number of admin pros at tonight's meeting noting a
> strong preference for Ubuntu Server.  The leanings
> mostly come out of the strengths of apt-get / dpkg
> over yum / rpm and the reliability of update installations
> that apt-get provides. 

There are a whole host of other reasons, IMHO, to use something like
Debian or Ubuntu's server distribution over the seemingly "standard"
RPM-based distributions, but I'll hold my tongue this one time, since I
think I have already said it all in at some point in the past.

The most important piece, I think, for learning how to work with systems
built around Linux professionally is to really have an idea of how the
system is assembled together and is works.  If you can tell the
difference between a system that is _actually_ a GNU/Linux distribution
and one that is not, then you're off to a pretty good start.  Some
people would have you believe that every single distribution that has
the Linux kernel also has the rest of the UNIX-like stack provided by
GNU, but that is not always the case.

Further, you should be familiar with the components that make up
(almost) every system I am aware of that is in some form of production
use today.  You probably don't have to get all historical and learn
about a.out and the ELF transition and truly ancient things like
managing shared libraries before ELF came along and make it a relative
breeze to do, but you should know how things on the system really work
so that you can take advantage of them.  You should know what the
dynamic linker is and does, for example.  You should know what the
standard C library is and does, and you should have a general idea of
what libraries are typically offered to provide certain types of
functionality.

If you're going to be administering desktops in addition to servers, you
should also know a thing or two about how the desktop environment that
is in use works and communicates with the system that sits underneath
it.  You should be familiar not only with popular standard things like
ISC BIND and ISC DHCP dæmon, but you should really be familiar with what
DNS and DHCP are and be able to quickly figure out how to use any
relatively sane piece of software that implements the service.  You
should be able to understand (maybe not immediately, but at least know
where to look to figure it out) why processes are dying unexpectedly
when you have some dæmon sitting somewhere on the system that has run
away and is chewing up all the resources.

It'd help to know about virtualization and containerization and all of
that, as well, simply because that's an activity that isn't going
anywhere any time soon, and unless something significant has changed in
the last six months or so while I wasn't looking, most of that is still
done on Linux because the BSD family and other systems really haven't
caught up yet in terms of the sheer amount of flexibility (Linux-based
systems can be hosts for Xen paravirtualized systems, for fully
virtualized systems running under KVM, or for containers using one of a
number of different containerization systems such as LXC or OpenVZ).

The overall point, though, is this:  Know how the software is supposed
to work.  Know how it actually works.  Build from source when you need
to, and when you don't need to, use the package manager.  But if you
know the system that is being managed by the package manager, learning
how to use the package manager---and in the case of certain package
managers, all of the black magic involved in keeping them running
efficiently (or at all!) without imitating Fido and chasing its tail
infinitely---is a relatively simple task.

Of course, I may be nuts here.  I know that if I said "know thy system
well" on a Windows administration mailing list I would be told that I
was nuts.  :-)  But I pretty much expect that someone who wants to
administer or program Linux systems professionally really does have to
know the nitty gritty.  You don't if you're just running it on the
desktop, for the most part, even if it can be helpful.

	--- Mike