I have a core i3 laptop (toshiba 2010) with 6gb of ram, I have somewhat set it up just for training to become a linux administrator. I installed mx linux 25 xcfe as host, have virtualbox with 4 vms.
Rocky linux 9,7 (app server)
alpine linux (lightweight tester)
rocky linux 8 (load balancer/network)
debian 13 (server)
Is this appropriate to learn to be the best of Linux administrators / be the most proficient in Linux where it matters.
i have read the post of 12 years ago, which i think is very helpful, I am still new so don’t know my way around too much to reference it.
Your setup is perfectly reasonable for someone starting out in Linux administration.
The hardware is not what determines whether you become a good administrator. What matters is whether you are using the lab to solve real administrative problems.
Right now, I would worry less about adding more distributions and more about giving each VM a purpose. For example:
Run a web application on Rocky 9.
Configure Nginx or HAProxy on Rocky 8 as a reverse proxy/load balancer.
Use Debian for DNS, monitoring, backups, or automation.
Keep Alpine as a lightweight test environment.
Once you have services communicating with each other, start breaking things intentionally and learn how to troubleshoot them. That is where most real administration skills are developed.
Also spend time learning:
Networking fundamentals
Systemd
SSH
Logging and log analysis
Backups and recovery
Bash scripting
Ansible
Containers (Docker/Podman)
Basic virtualization concepts
A lot of new administrators focus on installing operating systems. Experienced administrators spend most of their time maintaining, troubleshooting, automating, and documenting systems.
If your current laptop can comfortably run those VMs, then it is more than sufficient for learning. Many excellent administrators started with far less.
Keep building services, keep breaking them, and keep fixing them. That experience is worth far more than adding another VM to the lab.
@MarcelStevano that is excellent advice! Some general things that I would try very hard to do (and I’ve been a systems administrator, a coder, a code maintainer, an occasional architect/designer, and most certainly a tester): make absolutely certain that you understand as many components of what you’re responsible for as an admin. On one hand, you can’t possibly know or do everything; just make sure you have a solid idea of what to do, and when you can’t do it yourself, make sure you identify at least one, maybe several others, who are subject matter experts who can either advise you or actually step in and solve some of the problems with you.
If your systems stay up most of the time and they get fixed or improved promptly when there are problems, you will be well respected, and possibly rewarded for your efforts. If that’s NOT the case, look for work where you have the desire to know and understand how to make a difference AND that work makes you happy and satisfied. If you find such a place, treat it well and it ought to treat you well too!
Can you edit your original post to include the URL to that post?
My own advice is more generic rather than technology-specific.
Technology-awareness skills are just one set of skills. Technology-management skills are equally, and possibly more, important.
If you don’t understand it, don’t mess with it!
(In other words, know the “battlegrounds” before “venturing into the breach”.)
If you are the sole responsible for any service/hardware, don’t let anyone override your recommendations/decisions until after you have their directive to do so in writing! … and be sure you spelled out, also in writing, why your original stance should not be countermanded!
(Basic CYA. They can’t say you didn’t tell them, and they can’t avoid the responsibility.)
Always build in your own “checkpoints” to confirm that things are progressing the way you “believe” they are going. Without those checkpoints, you may never discover how far off the tracks you went … until it is too late!
(Keep you finger on the “pulse”.)
Don’t walk “blindly” into a minefield. Always plan the sequence of tasks for a complex function/task. Feel intuitively that your plan is sound.Never move forward using elements which leave you uncomfortable. Regardless of complexity, if a process is multi-step, build the workflow in such a manner that each step is completed clean, with tests to confirm successful completion, along with mechanisms recording when that step is already performed, thereby allowing restart of process such that it re-uses outputs from successful steps to re-attempt those steps that are problematic or failed.
(Divide and conquer! Small tasks are easier to understand/perform and require fewer simultaneous resources to complete.)
However tempting it is to perform admin tasks that manipulate data at command line, discipline yourself to always use a script and testing it piecemeal, meaning building up the pieces one step at a time.
(It is safer to restrict command line input to the enabling/starting/probing of services or hardware.)
Periodically review your accumulated “toolchest” (a.k.a. scripts) with a view to expanding embedded documentation for maintainability, optimizing logic using lessons learned, “normalizing” script styling to again facilitate maintainability.
(“Clean” code reflects professionalism, and lends itself more easily to re-tasking, if the logic is “modular”.)
(If you are not yet in the work force …) Be aware that there is a chasm between the perspectives used for sysadmin in a small enterprise vs sysadmin in a multinational corporation. Get a feel for those differences by getting summer jobs in each environment between school years, so that you can develop a sense for the difference in expectations from both.