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.
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.
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.
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'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.
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.
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!!
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.
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 :/
`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.:
`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.