I am interested in your thoughts; opinions; and your personal experience. I would be very grateful. Any suggestions; like tutorials:, books;, or online courses.
I am not sure what you are defining/thinking of when you say Linux system administration, to be honest. VLANs, bonding and firewalls are really more in the realm of network design and administration, and some things, like writing BASH scripts, are really more like coding than anything. Can you give a better idea of what you are comparing? I am guessing here, but it sounds like maybe what you are really asking is how to set up a home lab?
I tend to learn by doing, so by doing more I learn more. In order to do more, you need some hardware, this can be real or virtual, you just need a place (often called a home lab) to play/practice. It also helps to have a goal (or a whole mess of them) to focus your mental energy on. Once you have zeroed in on a specific goal, start researching, installing, configuring and testing the software that goal depends upon. You might try the top three software titles in that arena to compare and contrast and to see which you prefer. To do this properly will require lots of reading and it is a good idea to make notes to start building your own personal knowledge base as you work to achieve these goals.
Jay has a lot of great videos on lots of topics, but rather than just watching them try to follow along. Pay extra attention for nuggets of wisdom (best practices) that he has learned the hard way. You might also consider getting his book (Mastering Ubuntu Server) and try each exercise as you read through the book. The things that you will learn by practicing what Jay teaches can help fill your “toolbox” and will come in handy down the road when you have a problem to solve.
Jay isn’t the only author or teacher out there, you might also check out Network Chuck, Christian Lempa, Veronica Explains, Chris Titus, Apalrd or any of the numerous other Tubers Teaching Tech. Just pick a tutorial that appeals to you (or solves a problem you have) and try it at home.
At the end of the day, each of us is really just using software to solve problems. So get out there and try to do something, when things don’t work the way you expect hit the man page or wiki or download the documentation. If you can’t find your way out of the wilderness or you conquered something cool, come back here and tell us about it.
I am fond of telling people that if you are serious about IT, you need a homelab.
Also, try to find a local LUG (Linux User Group). If you can’t find one, there are several that meet online. The next step is to attend a Linux Fest, such as the South East Linux Fest coming up in a couple of weeks. https://southeastlinuxfest.org/
This one might not be near your location, but there are many others. The one I posted above is not your typical IT conference with a bunch of vendors, this one is much more community focused, which is what makes it so special. I learn more at these community conferences than anywhere else, except, you guessed it, my homelab.
If you like to learn from books, then find one of Mark Sobell’s “A practical Guide to” books. I have “A Practical Guide to Linux” and his “A Practice Guide to RedHat Linux” both are very good, but different books. The first one covers commands, editors, and shell programming. But, both serve as reference books for me to look up things. These topics can be found on the internet as well, but often you will find that the book author will provide more of the why to do something in a specific way. Whereas the internet usually just provides the how to do something.
I wish you luck in your journey, and remember, it’s all about the journey, not the destination.
Don’t be “the guy”. If everything hinges on you, your life will be terrible and ultimately, that project, team, department, etc. is going to be doomed. Even if you did all the right things, they’ll remember you poorly because they can’t operate things without you. Always make sure there’s someone else on your team that can do the things you do.
Don’t do the fastest thing, do the most maintainable thing (within reason for the project or situation). Choose languages with broad adoption, use industry accepted practices. I once wrote an application over a weekend to solve my own problem. It ended up being picked up by my employer as a world-wide solution. They built business practices, procedures, additional apps on top of the data collected and managed by this slap-dash application. After 17 years they decided to replace my code and it took 6 months and a team of 5 developers. Over that 17 year period, I’d periodically be asked to update, fix, etc. this code even though I hadn’t worked in that department for a decade. I should have chosen Python but because I was in a hurry and it was just for me (right?), I went with Perl and lived to regret it.
Build a culture of improvement. Many times people will want a thing to be made, then they don’t want to devote any more time or energy to it because “It’s done”. But if your organization is dependent on that thing, it should be constantly getting maintained and improved. If you’re updating and maintaining it, things like hardware changes or operating system updates are far less impactful. So many times, I’ll go somewhere that they have had an app running for 8 or 10 years and no one knows what it does, how it works, what it’s written with, but they know they can’t possibly touch or change it because they can’t afford for it to break. That’s a poor way of managing your things.
There is always more than one way of doing things, even if it may not be your way of doing things. There will be a time where something is being evaluated, but at some point a decision is made, do your best to support that decision, even if it’s not one you like.
Open Source (like Linux) isn’t free, people work on it. Realize if you’re a user and not paying the developers/owners, you get less of a say in how it works. Know who works on it, how decisions are made, and keep track of the project your thing depends on. Know what motivates the people working on the project. That way, you don’t get surprised if things change.
