The system administrator of yesteryear jockeyed users and wrangled
servers all day, 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 sys
admin 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 learn how 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 with the recent
trend toward DevOps and
[containers](https://opensource.com/article/19/6/kubernetes-dump-truck).
Your career as a sys admin 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](https://www.redhat.com/sysadmin/yaml-tips) configuration,
and how to
[interact](https://opensource.com/article/19/6/how-ssh-running-container)
with
[containers](https://opensource.com/resources/what-are-linux-containers)
(tiny Linux systems running inside of a [sandboxed
file](https://opensource.com/article/18/11/behind-scenes-linux-containers).
Knowing Bash is the gateway to efficient management of the most exciting
open source technology, so go get [Bourne
Again](https://opensource.com/article/18/7/admin-guide-bash).

Resources
=========

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

Try a [portable Linux
distribution](https://opensource.com/article/19/6/linux-distros-to-try).
You don't have to install Linux to use Linux, so grab a spare thumbdrive
and spend your evenings or weekends getting comfortable with a
text-based interface.

There are several excellent Bash articles available here on
[opensource.com](https://opensource.com/tags/bash) as well as [Enable
SysAdmin](https://www.redhat.com/sysadmin/managing-files-linux-terminal)

The problem with telling someone to practise with Bash is that in order
to practise, 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
[overthewire.org/wargames/bandit](http://overthewire.org/wargames/bandit)
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.

Set up a web server
===================

Once you're comfortable with Bash, you should try setting up a web
server. Not all sys admins 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](https://opensource.com/article/19/6/understanding-linux-permissions),
and [configuring a
firewall](https://www.redhat.com/sysadmin/secure-linux-network-firewall-cmd),
are the same skills you need on a daily basis. After a little bit of
effort, you may start to notice certain patters in your labour. There
are concepts you have probably taken 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 it'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**.

Resources
---------

David Both wrote an excellent article on [Apache web
server](https://opensource.com/article/18/2/how-configure-apache-web-server)
configuration. For extra credit, step through his follow-up article on
how to [host multiple
sites](https://opensource.com/article/18/3/configuring-multiple-web-sites-apache)
on one machine.

DHCP
====

The Dynamic Host Configuration Protocol (DHCP) is the system that
assigns IP addresses to devices on a network. At home, the modem or
router that 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 to 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 understand 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
familiarity with DHCP is to set up a DHCP server of your own. Installing
and configuring your own DHCP server provides you with 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 resolved),
control the distribution of addresses, create subnets, 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 understand, because the network is easily one of the most
important aspects of the job.

Resources
---------

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](https://opensource.com/article/18/7/sysadmin-guide-networking-commands)
article for tips on how to explore your network.

Network cables
==============

It might sound mundane, but getting familiar with how network cables
work makes for not only a really fun weekend but also gives you a whole
new understanding of how data gets across the wires. The very best way
to learn is to go to your local hobby shop and purchase a cat-5 cutter
and crimper, along with a few cat-5 terminators. Then head home, grab a
spare ethernet cable, and cut the existing 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 floor molding or along
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
understand.

Ansible
=======

Ansible is a 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 are
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 arguably 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](https://opensource.com/article/19/6/create-centos-homelab-hour).

Resources
---------

Read [How to manage your workstation configuration with
Ansible](https://opensource.com/article/18/3/manage-workstation-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 in your own
problem-solving skills you become.

Aside from the rigours 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 for work as a sysadmin.

Sysadmin feedback
===================

Are you a working sysadmin? Do you have tasks that you wish you'd prepared for? Add them in the comments below!

You are viewing proxied material from sdf.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.