21 tips for new server users from a self-taught ‘sysadmin’
When it comes to servers, my story isn’t unique. I’ve never had formal training in Linux, the terminal, or anything to do with real sysadmin work. But, after 15 years of tinkering, I’d like to think I know a thing or two about developing and deploying applications on servers.
This puts me somewhere in the happy mean along the diverse spectrum of SSD Nodes users. A lot of you are far more experienced than I, both in years and breadth/depth of knowledge, but many of you are just now starting to SSH into your server for the first few times. You’re figuring out
ls, and all the other basics, and maybe you’re starting to feel a little overwhelmed by the entire process. I’m here to advocate for self-learning, because it’s probably the best long-term skill you can develop right now—the ability to learn will help you now just as much as it’ll help you 20 years from now.
These tips are directed toward the newer server users, but seasoned pros might find something of value, too—if they keep an open mind.
We already buy enough stuff that we don’t end up using—don’t add a server to that list. Terminals can be daunting, especially for beginners, and don’t necessarily invite being played around with unless you have a certain baseline of skill. Set a goal, even if it’s just learning Linux/terminal fundamentals, and then get to work.
No matter which host you chose, you bought a server for a reason. Maybe you wanted to set up a personal development blog to talk about what you’re building, or perhaps you have a business that needs a website and didn’t want to rely on shared hosting or automated WHMCS panels. Whatever the reason, it’s going to be what grounds when you’re stuck in one of the frustrating ruts of managing a server. Don’t forget what you’re building, and let that momentum guide you the process—both good and bad.
Sometimes I think of managing servers like carpentry or woodworking. You wouldn’t dive right into building an entire house, but you may start mastering the art of straight cuts on 2x4s, followed by some basic framing. You learn how to create a foundation, and you do that a bunch of times, and then you get into the tough stuff.
Try deploying a static site on a LAMP/LEMP stack. Get good at that, get it working exactly the way you want, and then move on to more complex installations, like self-hosting with Docker or segregated Linux containers.
Everyone has a different learning style, especially when it comes to complex topics like servers. Some might do best watching videos of someone coding “live,” whereas others might prefer videos. I tend to do best when I can read solid documentation and try various solutions out myself, but that might not be right for you.
The Linux and FOSS communities are remarkably generous and love to share knowledge—use that to your advantage. You shouldn’t have to fork over cash to learn about deploying services and apps on servers. Learn how to search on Google/DuckDuckGo and get to it.
You’ll come across problems you can’t figure out on your own. By finding a community, you’ll have a handful of people who have your back and can help you work through a tough problem. Great communities are almost impossible to find these days, but here are a few:
Tutorials can be confusing to follow no matter your skill level. It’s easy to get overwhelmed with all the commands to run on the terminal and all the configuration files to edit. Focus on what you can get done in a given development/deployment “session” and don’t worry about the rest.
You’re trying to build knowledge and solve problems, not just check boxes. Let’s say you have a development consultancy and are looking for better ways to connect with potential customers. The problem is that you don’t have a blog. The solution isn’t LAMP+Wordpress, or Ghost, or Hugo, or any of the individual content management systems (CMS), but rather a working, functioning CMS on which you can rely. This small tweak in perspective—from deploying a tool to instead solving your problem—can be useful in maintaining your focus if and when things don’t always go your way.
If you’re building a business, it’s also a great way to talk about your product with potential customers.
Beginner server users often get stuck on which tech “stack” to use—stick with the tried-and-tested WordPress installation, or go Ghost, or maybe a flat-file CMS? It’s a recipe for indecision. Remember that when someone recommends a given solution, they’re not doing so objectively, and their pros might end up being your cons.
Avoid hype and don’t always buy into the newest and coolest framework, toolkit, or deployment strategy. Chances are they’ll fade out of fame as quickly as they arrived, and you’ll be stuck with an abandoned stack and a shrinking community around it to help you out when things go wrong.
11. Don’t let jargon seep into the way you talk
It’s tempting to use all your new server vocabulary when talking to others, whether in person or online in one of the communities I mentioned above, but remember that our profession or our skillset do not define us—we’re people, first and foremost. If you’re having issues with and are looking for help, don’t just copy a logfile and expect someone to debug for you. Instead, state your issue and your goals in language we can all relate to, and then get into the details.
Embrace your logs—
/var/log/ should be one of the most-visited folders on your server. These warning/error messages will be difficult to understand at first, but you’ll get the hang of them with enough searching. Developers work hard to create useful log messages that you’ll be able to suss out yourself. If not, you can always copy some text from the terminal and head over to Stack Overflow.
If you’re still running into troubleshooting issues, remember that almost all of the services and applications you install on a server are open source. Not only is their code freely published online via GitHub or another version control software, but so are all their “warts,” or issues, that others have stumbled on. Be sure to search both open and closed issues for others who have already found solutions to your current problem.
Not long ago, a post on HackerNoon called “The 2018 DevOps RoadMap” went viral, at least on the DevOps/sysadmin scale. The roadmap image is wildly daunting, especially for beginners. Some boxes are so broad you might need months or years to master them.
Unless your goal in running a server is explicitly to become a DevOps engineer, don’t get too caught up in all these educational to-dos. Learn only what you need to get your project online, master those skills, and then learn whatever will push you closer to your end goal, not whatever is “next” on the list.
Server, development, and deployment technology moves fast. If your job depends on these technologies, you’ll, of course, need to stay in touch with the latest and greatest, but remain committed to solving problems, not spending time on something new just because it’s new. You shouldn’t learn Ansible just because you feel you should. You should learn it if automatically provisioning servers will streamline your server work. Same goes for any of the technologies in the roadmap featured just above.
You’ll also need to continuously learn more than technology—to succeed in any field you need excellent people skills, empathy, communication know-how, and a whole lot more. We’ll soon be publishing a comprehensive piece about “evergreen” skills for developers and server geeks. Stay tuned.
It’s okay to search for solutions, but remember that no one can teach you better than yourself. If you find yourself looking up the proper syntax and settings for a Nginx server block, for example, write up a quick document with a working solution and document it. Then you’ll have your own answer, written in your own style, precisely the way you’ll understand.
Take this a step further by building a folder full of purpose-built shell scripts that help you accomplish different repetitive tasks.
There might come times when you make a critical mistake that breaks your server or its applications. You might be tempted to spend hours researching logs and troubleshooting tips in the effort to rescue the work you’ve already put in, but often the best option is to start over. You’ll either get faster at setting up your stack, or you’ll give into configuration management. Either way, you gain in the end.
You’re backing things up, right?
There’s no better place to experiment than in software. You can always wipe the slate clean and try again. No matter how skilled you are in development and deployment, you’ll make mistakes, perhaps bad enough to take down everything you’ve built. That’s exactly why the
Reinstall button exists. In about 30 seconds, you’ll have a fresh Linux installation and can take everything you’ve learned since to make your deployment better, or at least a little more resilient to your… meddling.
Not long ago I was reminded of the fact that the most successful people tend to write down their goals. A written target is actionable and reviewable. I think the same is true of goals we’ve accomplished. By writing them down, we give ourselves essential perspective on how much we’ve learned, created, or shared.
This is why I always advocate for developers to deploy and write content for their own blogs—the journey from idea to deployed project might not sound like thrilling content, but it’s a useful way to mark your progress and prove (maybe to potential employers!) that you know how to problem solve and can write a decent sentence or two.
You spent your hard-earned money on a server with a certain amount of RAM, disk space, and transfer, and it runs Linux, the most customizable and flexible operating system out there. You might have gotten that portfolio site up, but why not try self-hosting on top of that? Perhaps one of the many strange uses for Docker would be down your alley? Or, if you’re financially motivated, figure out a way to get a positive ROI from your VPS.
That blinking terminal is a gateway—make sure you take full advantage.
We want to believe big tech companies have these precise and efficient setups that have been finely tuned by dozens of experts over the course of years. The truth is that each of these experts likely has a list, longer than we’d like to know, of issues they plan to fix, or bugs they’d love to squash, or ground-up improvements they know the CTO will never sign off. Same goes for a startup’s SaaS app, or a corporate blog, or a small personal development portfolio.
The goal isn’t perfection, but rather creation. If you have a server up and running, no matter which hosting provider you’re with, you’re well on your way. Best of luck with everything to come.