This is kind of like “I’d like to read about the theory of driving a car.” There might be a book on it, but I don’t know of one. It might make you a bit better of a driver, but if you’re trading off time behind the wheel for reading about driving it’ll make you a worse driver. There’s basics and in-depth details that are covered by the docs for any common service you’ll run, and from there you gotta get behind the wheel, have a clear goal, start small, get advice from a community that’s familiar with the services you’re running, and be as risk-averse as you can.
I’m not a professional sysadmin, I’ve only done it as part of jobs when we ran our own boxes, for lab setup for dealing with that hell, and for fun. There are best practices, and important considerations, which the docs for services will cover and you’ll pick up if you’re doing it, but they aren’t grounded in a theoretical framework, AFAICT, and there are no universal axioms that apply to each component that are worth taking the time to learn. There are too many ways to do too many things for a universal theory to apply well. You could study computer science, theories of computation, understand the hardware architecture, learn operating systems in depth, and be better grounded in principles, and that can help for depth, but it’s not that important to most tasks unless you’re doing something really cutting edge or esoteric, and it’s a life-long slog. If you want a high-level work that gives you a nice theoretical framework of the big picture from logic gates down to the OS, Petzold’s “Code: The Hidden Language of Computer Hardware and Software” is good (and fun), but reading it won’t make you any better as a sysadmin.
Thank you! I love Charles Petzold’s book on Code and have even dipped into Annotated Turing. I almost mentioned Code as an example.
And, as in studying law, he, Martin Davis and similar writers have been helpful to me at least as often as the compilations of rules and recipes in the “programming” shelves in places like Barnes & Noble.
I don’t know of a book akin to Martin Davis’s Engines of Logic re: systems administration. You’re dealing with what amounts to configuring a collection of diverse pieces of software on what could be a diversity of platforms that haven’t necessarily got much in common, to accomplish a goal that can often be accomplished in many ways (depending), and aren’t unified by much other than how you choose to set it up. There’s no unifying principles that could make sense that I can think of, other than OS/service-specific ones.
There are some things like knowing the UNIX philosophy, though, assuming you’re just interested in UNIX. Kernaghan and Pike’s The UNIX Programming Environment is old and often out of date but goes into that. There’s ESR’s writings, which are not bad when he’s stealing things from other people, though usually bad when he’s not. You can mostly sum it up without a book, but with a one page pamphlet, though: write/use programs that do one thing well, work together, and handle text streams which are the universal interface for UNIX.
Double thank yous for helping me. I will look around for Kernaghan and Pike’s The UNIX Programming Environment. It sounds like you’re drawn to it for its readability and interest.
I want to say again that of course you’re right that a book is not a substitute for practice. We can’t learn to cook an egg, ride a bike or hit a baseball from a book. Sometimes love for doing those things can be discovered in a book, and that’s not the same as practicing to do those things well.
At one point, @tropo used vocabulary like low level network protocol. That sounded like the part of the layer cake I was hoping to . . . erm . . . eat, I guess. I read Tim Berners-Lee’s book Weaving the Web and thought it was interesting. I’m hoping to learn more in the server-ish zones without resorting to a lot of man pages.
And I get the idea I should know the answer but . . . ESR?
Thank you again for responding patiently and kindly.
man pages are written in a kind of formal structure, but they’re often pretty detailed and will usually be telling you what you should know, even if it’s not what you think you want to know.
Maybe you’re more interested in networking/systems things than administration of a server per se? That’s its own ball of wax, and alas, while IP networking and network communication protocols are valuable to understand in as much detail as you can manage, I have no resources since I learned it piecemeal over years. That is another life-learning exercise, since it goes very deep.
Eric. S Raymond. I retract that. You’re probably better off just ignoring him if you aren’t familiar. He collected/stole a lot of bits and pieces from the MIT people, Kernighan/Ritchie/Pike/etc. that are otherwise scattered all over - but it’s not cohesive, and it’s so polluted with his own horrible injections that I’d prefer not to be a person suggesting it.
Ah! I should’ve guessed by the initials. I read about him in a fun book by Glyn Moody called Rebel Code: Linux and the Open Source Revolution and I have opened Cathedral and the Bazaar without getting into it though I’m very interested in ideas I associate with the metaphor.
And I see that you and @codinghorror both think that ESR isn’t the right way to go. The commentary I’ve skimmed in the tutorial that @codinghorror posted looks good. (Thank you!) I’ve actually learned a fairsmall amount of CLI syntax over the years which I tend to mostly forget almost as soon as I learn it since it does not plug into a regular professional daily practice for me — mostly.
I guess I’m conceding your (everyone’s?) point again about a project-based approach and practice.
DON’T buy a parrot figuring that it will be a fun surprise for me. To acquire a parrot is a major decision: it is likely to outlive you. If you don’t know how to treat the parrot, it could be emotionally scarred and spend many decades feeling frightened and unhappy. If you buy a captured wild parrot, you will promote a cruel and devastating practice, and the parrot will be emotionally scarred before you get it. Meeting that sad animal is not an agreeable surprise.
Doing is the only way any of the technical stuff will stick for any duration. If you go that route, you will be spending a good deal of time with man pages.
Be happy they’re not RFCs. If you get down to a low enough level with network protocols, at some point you’ll find yourself reading RFCs and cursing vendors for their (sometimes loose) interpretation of them.
Like @nemomen, my sysadmin experience came out of necessity, and I never really spent any time with books on the subject.
Most of the books I can recommend in networking are “nuts and bolts” sort of works. TCP/IP Illustrated (Vol 1-3) are excellent. It is networking at a deep level though, and I hesitate to recommend them unless you find yourself seriously dealing with the topic. The inside front cover of vol I has (among other things) this handy diagram of the structure of a TCP packet, which you will find yourself repeatedly referencing as you work through the chapters.:
Many pages consist entirely of networking sequence diagrams, like this:
I suppose this speaks to the way I’ve approached learning about computer related topics over the years. I rarely buy a book unless I’m really down in the weeds on a given topic and / or am considering purchasing a reference I will continually revisit.
I guess it really depends on what your goal is. Do you just want to have a high level understanding of what a sysadmin does? Or are you looking to actually do sysadmin work?
My experience has been that getting to a conceptual understanding of servers, operating systems and applications takes a lot of doing menial tasks until, hopefully, you start putting the pieces together for yourself.
For most sysadmin’s I know, their career path starts out in the trenches of the helpdesk, doing boring repetitive tasks that no one wants really wants to do.Hopefully you learn the basics of maintaining the health of an OS, the actual server part, and if you’re good, you develop a proper understanding of troubleshooting. Then and only then are you ready to move on to the next level, which is likely going to be maintaining a service or an application which seems to be where you’re headed.
Start by doing.
Move on to learning about administrating whatever application you’re interested in and slowly build your knowledge from there. I don’t know about a single source that can give you an overview like what you’re looking for but I do know that you can learn a lot if you narrow your focus to reaching a specific goal like setting up your own webserver.