Live data from Hacker News

Ask HN: How do I learn how to become a good sysadmin?

news.ycombinator.com

1–10 of 124 posts

Ask HN: How do I learn how to become a good sysadmin?

#1
Earlier today I read an article on the decline of proper sysadmins in the age of containers. I thought I was doing a decent job of being a sysadmin+developer at the place I work but looking at the problems containers can cause I couldn't help wonder how one should go about becoming a decent sysadmin.

Main scenario is the one where you as an individual might on your own (or with a couple of friends) start some tiny sass product, or build an open source product that you want to keep secure.

At the most basic level, when firing up a new server I follow the how to harden your server guides and install fail2ban, disable root login, enable ssh only login etc.

Things I don't fully understand, user permissions or rather, how to use permissions to ensure good security. I'm also unsure about logging. I'm essentially clueless about where to look to understand what goes into being a good sysadmin.

Any advice would be awesome. Thanks.

Re: Ask HN: How do I learn how to become a good sysadmin?

#4
To use permissions for security, follow the principle of least access. If a user or program doesn't need access to something, don't give it to them. User permissions are the first tier of this, Apparmor and Selinux are the next (and correspondingly complex) next tier.

For example, for a web stack which communicates exclusively over the network stack, run your entire stack as individual non-root user. Nginx can run as the nginx user, django/rails/node as a separate user which has no access to the nginx configs. MySQL/PostgreSQL/Mongo as yet another user, which can't access the previous two.

By default, config files should not be owned by the process reading them, they should be part of the group (if they owned them, they could be re-written by that process).

Logging, you have a few options. Syslog is simple, and re-directable, which can help increase security. Writing to normal log files is perfectly acceptable as well, just be sure to write to a program specific directory and set up a logrotate config.

Also, set up monitoring and notification on everything you possibly can. First, know when something has gone wrong before you're notified by your customers. Then figure out how to know something will go wrong before it actually goes wrong (like running out of disk space - this happens more often than you might imagine).

There are plenty of articles on hardening linux, and sysadmin best practices on the web - I've only outlined a few here. When acting in the sysadmin role, be skeptical, paranoid, and value service uptime above everything. With this attitude, you will be more prone to automate server setup, limit user access, and less inclined to just throwing things out there because they're shiny.

The real fun is when you design and develop a way to safely and securely let your fellow developers just throw code over the fence, because then they can do their job in a way that suits them, without compromising your servers.

Re: Ask HN: How do I learn how to become a good sysadmin?

#6
How to become good sysadmin? Understand how your system works and do everything to not interfere with it. This simple principle is the most important for a sysadmin, all the rest is an implication of it.

How to use logging (shipping, processing), how to install software (packaging systems), how to one can separate services in different ways, how to communicate with systems, how to work with resources, how to tell what's going on in OS (what's running, what uses what, what subsystems are under how much load) are all derivatives of "know your system and work with it instead of around/against it".

Re: Ask HN: How do I learn how to become a good sysadmin?

#7
F*cking up a lot is a good start ;)

When you don't understand things like user permissions, best is to make up some scenario's and write them down on paper. It makes these things easier to grasp, when you can strike through impossible options or for instance visualize routes or outcomes.

Visualizing on paper also works very good for debugging networking. For instance when a packet coming from the internet arrives at your gateway, how does it travel from there to it's final destination and how does it travel back? Write down at every hop the port/subnet/netmask/gateway for both the incoming and (if applicable) the outgoing interface. Works great for finding connection issues.

Document your infrastructure. Documenting in detail can show design flaws that weren't visible before. It also helps a lot to gain more insight in how everything is connected and how it works together.

Re: Ask HN: How do I learn how to become a good sysadmin?

#8
At the end of the day it's important to find a mentor or join a bigger company where you can study under a more senior sysadmin.

These days things are getting more complicated, to be a good sysadmin you also have to be a good developer. Usually as good and sometimes more than the people that write the apps that you will run, maintain and love long after they have decided they have something more shiny they could be working on.

You need to be able to dissassemble and fix programs built by other developers, diagnose issues in many runtimes, understand kernel subsystems and the various issues you can run into in kernel land.

You need indepth knowledge of C, system calls and the behaviour of hypervisors and hardware. Don't believe that running on EC2 and not programming in C gives you the luxury of glossing over these fundamentals.

You will also need networking knowledge, even if you don't intend to run your own networking equipment you will still need to understand things like the TCP handshake, what and skb is and why that's important, understand the differences between select() and epoll().

Learning to be a good sysadmin is relatively easy, learning how to be a great sysadmin takes a good 10,000 hours.

Re: Ask HN: How do I learn how to become a good sysadmin?

#10
post #4

To use permissions for security, follow the principle of least access. If a user or program doesn't need access to something, don't give it to them. User permissions are the first tier of this, Apparmor and Selinux are the next (and correspondingly complex) next tier. For example, for a web stack which communicates exclusively over the network stack, run your entire stack as individual non-root user. Nginx can run as…

> Also, set up monitoring and notification on everything you possibly can.

Notifying about everything is a very, very bad idea. You'll drown under notifications that do not matter and you will certainly miss those that do matter. There should be as little notifications as possible.

Post reply on HN