What you need to know to be a sysadmin

Kickstart your sysadmin career by gaining these minimum competencies.
175 readers like this
175 readers like this
Avoiding data disasters with Sanoid


The system administrator of yesteryear jockeyed users and wrangled servers all day, in between mornings and evenings spent running hundreds of meters of hundreds of cables. This is still true today, with the added complexity of cloud computing, containers, and virtual machines.

Looking in from the outside, it can be difficult to pinpoint what exactly a sysadmin does, because they play at least a small role in so many places. Nobody goes into a career already knowing everything they need for a job, but everyone needs a strong foundation. If you're looking to start down the path of system administration, here's what you should be concentrating on in your personal or formal training.


When you learn the Bash shell, you don't just learn the Bash shell. You learn a common interface to Linux systems, BSD, MacOS, and even Windows (under the right conditions). You learn the importance of syntax, so you can quickly adapt to systems like Cisco routers' command line or Microsoft's PowerShell, and eventually, you can even learn more powerful languages like Python or Go. And you also begin to think procedurally so you can analyze complex problems and break them down into individual components, which is key because that's how systems, like the internet, or an organization's intranet, or a web server, or a backup solution, are designed.

But wait. There's more.

Knowing the Bash shell has become particularly important because of the recent trend toward DevOps and containers. Your career as a sysadmin may lead you into a world where infrastructure is treated like code, which usually means you'll have to know the basics of scripting, the structure of YAML-based configuration, and how to interact with containers (tiny Linux systems running inside a sandboxed file). Knowing Bash is the gateway to efficient management of the most exciting open source technology, so go get Bourne Again.


There are many ways to get practice in the Bash shell.

Try a portable Linux distribution. You don't have to install Linux to use Linux, so grab a spare thumb drive and spend your evenings or weekends getting comfortable with a text-based interface.

There are several excellent Bash articles available here on opensource.com as well as on Enable SysAdmin.

The problem with telling someone to practice with Bash is that to practice, you must have something to do. And until you know how to use Bash, you probably won't be able to think of anything to do. If that's your situation, go to Over The Wire and play Bandit. It's a game aimed at absolute beginners, with 34 levels of interactive basic hacking to get you comfortable with the Linux shell.

Web server setup

Once you're comfortable with Bash, you should try setting up a web server. Not all sysadmins go around setting up web servers or even maintain web servers, but the skills you acquire while installing and starting the HTTP daemon, configuring Apache or Nginx, setting up the correct permissions, and configuring a firewall, are the same skills you need on a daily basis. After a little bit of effort, you may start to notice certain patterns in your labor. There are concepts you probably took for granted before trying to administer production-ready software and hardware, and you're no longer shielded from them in your fledgling role as an administrator. It might be frustrating at first because everyone likes to be good at everything they do, but that's actually a good thing. Let yourself be bad at new skills. That's how you learn.

And besides, the more you struggle through your first steps, the sweeter it is when you finally see that triumphant "it works!" default index.html.


David Both wrote an excellent article on Apache web server configuration. For extra credit, step through his follow-up article on how to host multiple sites on one machine.


The Dynamic Host Configuration Protocol (DHCP) is the system that assigns IP addresses to devices on a network. At home, the modem or router your ISP (internet service provider) supports probably has an embedded DHCP server in it, so it's likely out of your purview. If you've ever logged into your home router to adjust the IP address range or set up a static address for some of your network devices, then you're at least somewhat familiar with the concept. You may understand that devices on a network are assigned the equivalent of phone numbers in the form of IP addresses, and you may realize that computers communicate with one another by broadcasting messages addressed to a specific IP address. Message headers are read by routers along the path, each of which works to direct the message to the next most logical router along the path toward its ultimate goal.

Even if you understand these concepts, the inevitable escalation of basic familiarity with DHCP is to set up a DHCP server. Installing and configuring your own DHCP server provides you the opportunity to introduce DHCP collisions on your home network (try to avoid that, if you can, as it will definitely kill your network until it's resolved), control the distribution of addresses, create subnets, and monitor connections and lease times.

More importantly, setting up DHCP and experimenting with different configurations helps you understand inter-networking. You understand how networks represent "partitions" in data transference and what steps you have to take to pass information from one to the other. That's vital for a sysadmin to know because the network is easily one of the most important aspects of the job.


Before running your own DHCP server, ensure that the DHCP server in your home router (if you have one) is inactive. Once you have it up and running, read Archit Modi's guide to network commands for tips on how to explore your network.

Network cables

It might sound mundane, but getting familiar with how network cables work not only makes for a really fun weekend but also gives you a whole new understanding of how data gets across the wires. The best way to learn is to go to your local hobby shop and purchase a Cat 5 cutter and crimper and a few Cat 5 terminators. Then head home, grab a spare Ethernet cable, and cut the terminators off. Spend whatever amount of time it takes to get that cable back in commission.

Once you have solved that puzzle, do it again, this time creating a working crossover cable.

You should also start obsessing now about cable management. If you're not naturally inclined to run cables neatly along the floor molding or the edges of a desk or to bind cables together to keep them orderly, then make it a goal to permanently condition yourself with a phobia of messy cables. You won't understand why this is necessary at first, but the first time you walk into a server room, you will immediately know.


Ansible is configuration management software, and it's a bit of a bridge between sysadmin and DevOps. Sysadmins use Ansible to configure fresh installs of an operating system and to maintain specific states on machines. DevOps uses Ansible to reduce time and effort spent on tooling so that more time and effort gets spent on developing. You should learn Ansible as part of your sysadmin training, with an eye toward the practices of DevOps, because most of what DevOps is pioneering now will end up as part of your workflow in the system administration of the future.

The good thing about Ansible is that you can start using it now. It's cross-platform, and it scales both up and down. Ansible may be overkill for a single-user computer, but then again, Ansible could change the way you spin up virtual machines, or it could help you synchronize the states of all the computers in your home or home lab.


Read "How to manage your workstation configuration with Ansible" by Jay LaCroix for the quintessential introduction to get started with Ansible on a casual basis.

Break stuff

Problems arise on computers because of user error, buggy software, administrator (that's you!) error, and any number of other factors. There's no way to predict what's going to fail or why, so part of your personal sysadmin training regime should be to poke at the systems you set up until they fail. The worse you are to your own lab infrastructure, the more likely you are to find weak points. And the more often you repair those weak spots, the more confident you become in your problem-solving skills.

Aside from the rigors of setting up all the usual software and hardware, your primary job as a sysadmin is to find solutions. There will be times when you encounter a problem outside your job description, and it may not even be possible for you to fix it, but it'll be up to you to find a workaround.

The more you break stuff now and work to fix it, the better prepared you will be to work as a sysadmin.

Are you a working sysadmin? Are there tasks you wish you'd prepared better for? Add them in the comments below!

Seth Kenlon
Seth Kenlon is a UNIX geek, free culture advocate, independent multimedia artist, and D&D nerd. He has worked in the film and computing industry, often at the same time.


Good list to start… I may suggest to add the Vim editor to the list :)

Of all tips, I really enjoyed the "break stuff" because this empirical method takes you to the state of confidence over the knowledge that is basic for problem-solving skills.

I quite agree with both Marco & Kim; I would add LVM to the list as well, and probably the concepts, at least, of DNS and Virtualisation.

Those are GREAT additions. As you can imagine, this article could have been A LOT longer, so it was hard to choose what to focus on.

In reply to by Dave Harding (not verified)

I agree as well ... In addition to LVM, adding in how to recognize newly added drives (with hot-swap, fibre channel, or virtual attach) can be crucial to keeping systems running without disruption when disk space runs low.

In reply to by Dave Harding (not verified)

I would add "man pages". It is really beneficial to refer to the man page for a given command.

Don't tell to my clients, but some important things that I know, I learned by experimenting with their computers and servers (sometimes I fix it and sometimes I worse it) ;-)

Just replying here on the Ansible part:
>> Ansible may be overkill for a single-user computer

I would strongly encourage sysadmins not to skip learning something because the effort for 1 machine is too high. That is the kind of behavior that keeps us locked into lots of low-impact manual tasks we need to remember to do over and over.

I would encourage people to start learning Ansible for their 1 or 2 machines, and using those to practice your skills. Ansible's wonderfully easy playbook syntax automatically creates great documentation for you on what you did, and eventually leads to shaving significant time off otherwise menial and mundane tasks ... not to mention that whatever tasks you develop for 1 machine can usually be easily reused on other machine.

I love it! An regret all the time I put learning it off because the issue at hand was "too simple".

> I would strongly encourage sysadmins not to skip learning something because the effort
> for 1 machine is too high. That is the kind of behavior that keeps us locked into lots of
> low-impact manual tasks we need to remember to do over and over.

What a great point. Thanks!

In reply to by James Farrell

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.