[linux-elitists] git and a sysadmin book
Karsten M. Self
Sun Jan 4 14:51:12 PST 2009
on Sun, Jan 04, 2009 at 08:37:14AM -0800, Don Marti (firstname.lastname@example.org) wrote:
> I really enjoyed the short thread about "long round-trip-delays of
> getting a patch applied" and the proposed solution, which turns out to
> be just to use a DVCS.
> It seems like there's an opportunity to apply distributed revision
> control thinking to computer books, too. A lot of Linux books seem to
> have a "on the one hand, on the other hand" approach, which makes things
> hard on the new administrator, just starting to set up a mixed
> Linux/legacy network. You always end up with an untested combination of
> stuff instead of the solid way that an experienced administrator would
> have set things up.
> What the world needs is (working title) The Opinionated Guide to Linux
> System Administration.
Screw that shit, Don. "The Linux Elistist's Book of System
Administration". Sure, "an opinionated guide" could be a subtitle. And
note that that's "Elitist's", not "Elitists'". Singular PoV gives you
unvarnished opinion, rather than consenshit by committee. Ok, even if
it's a set of elitists....
> (hey, if opinionated software is good, opinionated documentation and
> administration should be good too.) The official version would be the
> much-tested choices of a small group of co-authors, and that would get
> frozen, checked, and turned into the printed book every so often --
> but downstream users who really wanted Exim instead of Postfix or
> something would be free to fork. (In the long run, there might end up
> being many site-specific versions of the book, from which the core
> could pick changes.) Focus on a small office network to start with --
> the kind that seems to be the hardest for Linux to catch on in.
> * Opinionated. This book tells you what works for the authors, and
> doesn't waste time on describing "on the other hand" stuff that we set
> up just for the book and then blew away. (Don't like one of the
> choices? The book is in git--fork it.)
There are times when "on the one hand, on the other" is appropriate, but
these are almost always better replaced with "what is your goal".
Different goals imply different methods. Very often you find that the
goals haven't been explicitly stated or realized. Getting folks to walk
through this conciously, and, often, recognizing the constraints imposed
by existing architectures / historic choices, is very useful.
> * Linux-centric. You will almost certainly have legacy machines, but
> hang them off a network done the Linux way instead of vice versa.
> (Speak roughly to your Windows box, and re-image it if it sneezes.)
> * Simple. Any new software we add has to pull its weight. Prefer a
> package with fewer and smaller dependencies to one with more or larger
> dependencies. And nothing can depend on one person's magic touch, so
> you can take a vacation.
"Complexity is the enemy" is one of my buzzwords. Another is "Large,
low-entropy pools are inherently dangerous". They're the same side of
the same coin, and investigating the second in depth leads to some
What's a "low-entropy pool"? Anything with potential. Jerry-cans of
gasoline, 110 story skyscrapers (or two sited next to one-another), CCC
centers (command, control, & communications), server farms, active
earthquake faults, fanatical fundamentalist religio-political
ideologies, spaghetti code, ...
> * Security-minded. See "simple." This book doesn't throw a bunch of
> security products at you just for cleverness or CYA. But we do think
> about attack paths as a naughty person would, and don't leave them any
> shorter than they have to be.
Yes. See "simple".
A full exploration of what is meant by "threat model" is also
appropriate. Jim Dennis's exploration of this in his Linux Admin book
(paraphrased: security is the implementation of policy" is a start, a
seldom-stated fact, but imcomplete.
- What are you afraid of? Generally: unauthorized access, unintended
denial of access, malicious/accidental data deletion,
malicious/accidental data modification, malicious/accidental loss or
destruction of hardware.
- What can you do about it? What CAN'T you do about it?
- What steps can you take (or not) to prevent, reduce, mitigate, or
recover from the threat? At what cost? Most security discussions
fail adequately to focus on mitigation/recovery, particularly when
politics, public disclosure, and/or reputation is at stake. TSA and
post-911 security theater would be classic case studies.
- How do you know you've got a problem? Of the past several shops
I've been at, monitoring and evaluation of systems has been a
massive thorn in the side. "Solutions" range from "cries wolf"
(Nagios) to horrendously complex (Cacti) to prohibitively expensive
(Splunk). Often a major component of the problem is sorting out
what you really need to monitor. The lack of normative data
(something that more-or-less falls out of MRTG automatically, at
least in graphic format) is another PITA. Truth is it often takes a
year or so of exposure to the eb and flow of production
opeararations to get a sense of the pulse of a site or installation.
> * Top Line IT: Users can go elsewhere for information services, so we
> run the IT organization (even if it's an organization of one) like a
> service business. We get out ahead of what they want so they don't
> drag in some half-ass thing that we end up supporting.
> I think about a lot of the members of this list when I think about
> potential authors for a book like this -- but I know that you're not a
> real system administrator unless you have a severe time crunch, so
> getting a whole book from one person is asking a lot. A chapter or two,
> though? The problem of dorking around with word processor changesets to
> do a book can quickly go away, since it could all be done in LaTeX under
Karsten M. Self <email@example.com> http://linuxmafia.com/~karsten
Ceterum censeo, Caldera delenda est.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20090104/4f598bab/attachment.pgp
More information about the linux-elitists