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!