Linux Sysops Handbook | Hacker News Reader

Linux Sysops Handbook

abarrak.gitbook.io

284 pointsabarrak27 comments

I really don't mind the brevity, but the quality and correctness from that guide seems rather lacking, a few examples:

`apt update` refreshes the package index, but does no upgrade; so `apt update <package>` just fails with a usage error. Use `apt upgrade` for upgrading, or to allow dependency resolution to remove installed packages, which is relevant for upgrades between major releases, use `apt full-upgrade`.

`apt list` lists all pacakages known to apt, not only local ones; if you want locally installed ones use `apt list --installed`, e.g.:

   $ apt list | wc -l
   59316
   $ apt list --installed | wc
   426

`ip show link` just isn't a thing and will only get you `Object "show" is unknown, try "ip help".`.

Rather I'd recommend adding `alias ip="ip -c"` to your `.bashrc` or `.zshrc` to always get color output, that makes things much easier to read and then either use `ip a` or for a brief output that's very easy to read quickly `ip -br a`. If you want all details and statistics about bytes send/received and packets accepted/dropped use `ip -s -s a` (`a` is short for `addr` or `address`).

Mixes rsyslog and journald.

The "Shell Tips and Tricks" section could really do with a short sentence or a few keywords besides the tools.

It seems to be an open book, so maybe I can contribute some fixes; but with that many errors in such a short text I'd not share that guide currently to anyone.

This is definitely a quick reference, definitely short, and definitely missing a ton of things.

And it's awesome. This is just the thing a new Linux user needs to start understanding the ecosystem.

My first impression as well. You could take some IT grad and give them this handbook and then they would be dangerous, but not very effective.

Back in the day, when I was first exposed to Unix (on Sun3), one of the sysadmins pointed me to the 'man' feature. After a while I figured out that I could do a man -k - to get a list of all the man pages (because the summary for each page includes a '-'). So I did that and printed out the result (lp/lpr). At that time, the total number of man page entries fit on something like half a dozen pages. I spent a few days (part time) reading each one. It was a great way to learn.

My current Linux desktop (Mint) gives the following for man -k - | wc: 2943 26748 200002

That list would fit on 50 printed pages, which is about 10x what it was 37 years ago.

So if you have the patience to read almost 3k man pages, you too can become a Linux expert.

Ha, I never knew about man -k - until now, and I've been doing this for 20 years! Thanks for the tip! (whatis is also a synonym for man -f, and apropos a synonym for man -k, apparently)

It amazes me sometimes how much of a dying breed systems engineers are. When I was coming up as a SWE I worked for a series of systems engineers, so I learned software from a systems engineering perspective and it's been invaluable as distributed systems have gotten bigger and more OS-like.

If you're wanting to dive a little deeper than this guide touches check out:

- https://man7.org/tlpi/ - Really good for understanding how to build applications within a Linux ecosystem.

- https://www.amazon.com/Linux-Kernel-Development-Robert-Love/... - Really good for understanding why Linux is the way it is. The Kernel this book was written on is awful old, but the principles shine through.

We're just calling ourselves SREs now. It pays better.

I'm a bit conflicted with that title. I consider myself a SWE with an emphasis on systems, but more specifically Linux. From what I've seen a lot of the SRE market is (mostly) the same old Ops scene with new badges.

There's a ton of that, just like Devops was a "hot market" for a while and then was diluted. We'll have a new name in a few years, or we'll find some other way of distinguising ourselves... I am not one to promote unions, but at some point we do need a systems Engineering, ENGINEERING, Iron Ring, because our tools are increasingly infrastructural in the same way bridges are.

Links in the table of contents don't work, they're missing the '.' period character in the URLs.

From the ToC:

> https://abarrak.gitbook.io/linux-sysops-handbook/#1-processe...

The working link is:

> https://abarrak.gitbook.io/linux-sysops-handbook/#1.-process...

There's also "UNIX and Linux System Administration Handbook" (https://www.oreilly.com/library/view/unix-and-linux/97801342...)

For more such resources, I have a list here: https://learnbyexample.github.io/curated_resources/linux_cli...

I have also written CLI one-liner books for grep/sed/awk, currently free for Twosday: https://learnbyexample.gumroad.com/l/oneliners/Twosday

Evi Nemeth was Godmother to a couple generations of Unix Sysadmins. The UNIX and Linux System Administration Handbook is practical, usefully opinionated, playful, and brilliant, much like its lead author/editor. I've used it as the core text for classes I have taught and it's a great interview study guide for systems folk.

If you really want a trip down memory lane, dig up some earlier editions and learn how to deal with the quirks of the SGI, DEC, SUN, IBM, & HP menagerie.

I'd definitely start with this one.

I've also started writing something like this a while ago, but then ran out of time again. It's something I'll probably work on again when my workweeks get a bit shorter again.

https://linuxsysadminbook.sigio.nl/

The best "linux sysops handbook" is the manual. Every one of these tools has a lengthy manual; read them in their entirety. Try out the options.

Not sure what commands there are or what they do? Try this out:

  zcat -f /usr/{,share/}man/man[18]/*.[18].gz | grep -A2 "\.SH NAME" | grep -v "^\.\|^$\|^--" | sed 's/\\//g' | sort -u | less

Then read the manual for those tools that interest you. (learn how man, info, less and more work)

The source code is also free. Many of these tools come as part of a package of other tools and libraries. Find out what package the tools come from, find the source code, download it, peruse through it (even if you don't know the language). I guarantee you will find out new things you didn't know about how the system works.

You can also use debugging tools like strace, ltrace, gdb, lsof, etc to find out more about what these tools are doing. The more you understand what it's actually doing, the deeper your knowledge, and the less you need a handbook to tell you what to do.

Another way to play around with commands is to just run a Docker container like docker run --rm -it ubuntu:18.04 and try anything you want in the container. On exit it will be destroyed. To play around with systemd tools, install Vagrant and spin up a mini Linux VM.

There is no replacing the Unix and Linux System Administration Handbook.

No doubt, meant to be self study notebook originally. Listed in the end couple of whole interesting reads.

https://debian-handbook.info/browse/stable/

Isn't this missing about 10,000 pages?

Historically handbooks are smaller, shorter reference guides. Something that's portable and easy to carry with you.

Something 10k+ pages in length doesn't fit that description.

This is amazingly useful to a person learning Linux in a corporate environment where they've just been thrown to the wolves to figure it out. Thank you!!

As somebody who's in this exact same position(well not really corporate), I feel the same way about this guide.

Thanks so much the author!

The Linux Command Line and Adventures with the Linux Command Line, both by William Shotts, are a nice read for beginner linux administartion http://www.linuxcommand.org/tlcl.php/

Very nice! I would add a section on "How to get help on terminal" and discuss manpages, the -h / -help flags, info / pinfo pages and the /usr/share/doc location.

Source: https://github.com/abarrak/linux-sysops-handbook

I was really shocked to see kali Linux, a penetration testing distribution, mentioned on this. I wouldn’t normally include it in handbooks like this as it can be dangerous to encourage daily-driving a distro like that if they don’t fully understand the risks. Maybe I’d recommend ParrotOS instead :/

I love this, have a friend interviewing for a SysOps role and this is so timely.

While this is very Debian centric, this is a really good reference.

Also see `tldr` tool. Often very handy when you don't have patience to read man pages.

Reply on news.ycombinator.com