Hey everyone,
I’m preparing for Linux SysAdmin role and want to ask questions. What is the most important thing in Linux know as Admin, If i don’t it will create trouble at my work.
Honestly the biggest one: never run a destructive command without knowing exactly what it touches. Stuff like rm -rf, dd, mkfs, or anything with a wildcard. Double check the path before you hit enter, and if you’re not sure, don’t run it on prod first.
Related reading:
In addition to that, always, always, have backups and should be tested backups. A backup you’ve never restored from is just a hope, not a backup. 
Don’t make config changes without saving the original first, don’t edit a service config and restart blindly without checking the syntax, and never work directly as root when you can use sudo. Working as root all day is how a typo turns into a disaster.
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.$(date +%F)
That gives you something like nginx.conf.2026-05-22. If you want the timestamp, then:
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.$(date +%F_%H%M%S)
And when you do change something on a remote box this is firewall or SSH config related, keep a second SSH session open or have console/alternate access. Locking yourself out of a server you can’t physically reach is not fun!
11 Likes
I absolutely agree with @hydn
More than that, IMO, sysadmin should not take risks. Every potentially unsafe operation must be tried and checked within test environment first, not on production servers. Yes, even periodical security updates.
6 Likes
[1] Avoid shooting yourself in the foot
The proverbial
- rm -rf
command is the most dangerous one and should, preferrably never be used when at “/” directory, under any circumstance.
Instead, if required, ALWAYS do
cd /${some_specific_non-system_dir}
# confirm you are in that directory, and only then
rm -rf . # action to purge defunct repository
Yes, that kills your $(pwd), but it is the only really safe way, if there is any to be used.
[2] Use only proven code
As Eugene pointed out, NEVER even think you got it down pat, and enter a command manually, if it is something you’ve never tried before.
Some may consider overkill, but I consider it CYA or just simply discipline:
- build any command sequence as a script, line by line, testing each run of the growing script within a well controlled test environment (separate disposable copies far away from critical master copies)
Verifying each individual processing step of a script separately will avoid the surprise discovery of a change in a built-in library function having changed their API without you knowing about it, or without such changes being explicitly published in change notices!
For that reason, after any software updates, before using any tools on critical data systems, you should always perform a “re-certification” test for every custom tool.
Which is also why it is good to keep a collection of “test data sets” for each such tool and data grouping!
[3] Disable ALL auto-update routines
For the reasons stated above, you can never afford to have things change on you without your knowing about it.
Security updates should be done automatically, but even then, I hedge on the side of caution, and prefer to do those manually, at a time of my own choosing.
[4] ONLY perform updates AFTER critical deadlines fulfilled
Too many times, we are told things should go smoothly, or you think they will go well because you think you are aware of everything, when in fact you are not!
For that reason, if there are any scheduled system processing events, which are critical to the smooth-running or the actual success of the business, as perceived by the Client Organization, not yourself, never perform any system tweaks, or hardware changes, or software changes, or network rewiring, or firewall rule changes, etc., before those processing runs are completed and verified as completed successfully! Only then, should you consider “improving” (management considers it “tampering”) with the “well-oiled machine”!
8 Likes
When running an rm -rf command, one could also omit the -rf options until the command is complete and verified. Or better yet, also enable interactive mode (-i) while you’re still working on the command in case you accidentally press enter.
3 Likes
Login under your personal account and only use root when it’s needed. Don’t get in the habit of being root - for most stuff you can use sudo commands. It’s tempting to just jump to root but eventually it will bite you.
6 Likes
When using disks or parted/gparted triple check you’re in the right partition you want to alter/change!
8 Likes
Been there, done that, still have the t-shirt! Even a simple update to .profile/.bash_profile can be really painful if you can’t start a session. Always have a second session so you can quickly and easily revert.
3 Likes
Depending on what I am about to do with those, as well as with installs, I prefer to unplug the SATA cable from my primary drive, then use the Live USB, if I don’t have a working system on my secondary internal disk (old 500GB OS test bed).
2 Likes
at commands and at jobs have saved my life on remote boxes countless times. If you are making any type of change that requires a restart of a critical service or network component on a remote machine, set up an at job to run 5 minutes in the future.
If your change works fine, you can easily cancel it. If it doesn’t, you know you’re back in five minutes to try again.
5 Likes
Ahh! Thanks for this. Like a deadman’s switch. 
Will do! Such a flexible and useful command.
2 Likes
That’s a new one for me! Now in my tool box!
3 Likes
Benjamin, that is a fantastic example of CYA strategies! I did use at for many things, but that is one that never came to mind!
I regret to say that I never thought of using it during my career … but I am also fortunate that I did not encounter situations where I would have needed it! I guess I dodged that bullet! 
3 Likes
I spent a couple years in DevOps for a software product that required a “black box” to be installed physically on the customer’s network. Usually this was some kind of virtual appliance but we did ship physical machines too.
Now, the product itself that ran in our cloud was fairly stable, but the boxes living on the customer’s networks were not. Not always because of our product, but when you have something installed IN someone else’s environment, you can only account for so much.
We would often then push patches and product updates or the machine would need to get some kind of maintenance applied, and we just could not rely on the customer being around to “push to reset button” for us (that would also look bad).
So we learned pretty quickly that, even if we tested and expect a change to have no impact, we would always need a way to get back in and fix things without customer intervention.
at jobs are* absolutely the best tool for this. I did have two situations where this saved me big time, so it definitely is CYA. I now use this on my own home lab because the workflow is just so useful.
4 Likes
This is such a good piece of advice, if you can unplug it, do it—I used to do this with my SATA drives, but it’s not as easy unfortunately with NVMe drives 
2 Likes
When you’re logged into several remote hosts with ssh sessions in tabs, always double check which host you’re on before typing “init 6” or “shutdown” or “reboot”
Been there, done that.
6 Likes
However formal that may seem, an admin should never do his work without written instructions, local regulations, and/or by-laws. Admin must know beforehand which servers he controls, what and when should be done to them, who may give him orders, etc. Without regulations or not by following them admin can be accused of anything and everything.
More than that: instructions, local regulations, and/or by-laws should be read and understood. There well may be catches within them. E.g. admin should never agree to ensure uninterrupted and/or secure functioning of servers, applications, business processes, etc. That is impossible by definition. Actually, admin can take approved and regulated measures intended to provide uninterrupted and secure work. Do you see the difference?
5 Likes
I hate when that happens! I went the route of setting up every system with a different color scheme when I ssh to it. Having the name in the title just was too easy for me to miss.
5 Likes
Haha. Guilty of this one also. On Remmina and Termius. Messed up terribly that way about 3 years ago using split screen. I’ve since disabled “Focus on mouse hover” so that I have to use arrow keys or a click. lol
Some of these things, once you learn the hardway you become a bit paranoid afterward. At least I still am. 
6 Likes
Hey, IronRod, have you considered using different colouring of your BASH prompting, rather than complete theme changes?
I discuss and give examples in the following:
4 Likes