How to become a sysadmin ======================== - Alex Aminoff 2024-06-24 Philosophy: - with great power comes great responsibility - get satisfaction from helping others One concept is that 95% of the commands you will type are retrieving information. Those, you can be a little fast and loose as far as typos or wrong flags. If you give the wrong cmd line flags to ps, you just lose a little time while you figure out the correct flags. However, if you use the wrong flags in a find command that deletes files matching some critieron, you are going to cause real damage. Read man pages ----------------------- man man man -k man You can also google for sysadmin info, but stuff you find online, especially on stackoverflow type sites, has a modest chance of being wrong or not optimal. The unix man pages OTOH are 99.5% accurate, and the fact that they are in a standard format facilitates use as a reference. man -k or apropos looks for keywords in a database. Is our mandb database up to date? Is there a cron job that updates it? These are excercises for you. Use grep or similar tools ---------------------------------- A lot of a sysadmin's life is spent looking through large files for a small piece of information. These could be log files, but also email files, or directory trees. man grep grep stands for Gnu Regular Expression Parser, but in 90% of cases you don't need to worry about the Regular Expression functionality, just use grep as though it was grep -f ("fixed string"). But eventually you will want to be able to for example, see a file without the comments with grep -v -E -e '^#' configfile.cfg man pcrepattern Use scripting to automate ------------------------- Automation does not necessarily mean actually changing the world: as with the 95 rule earlier, you will often write scripts to gather info. You definitely need to be able to read and write shell scripts (bash more often than C shell). This is a case where man bash is probably not the best entry point. Google for a good intro to shell scripting, or perhaps there is a decent O'Reilly book I am going to say a sysadmin needs to know perl. Primarily because perl really grew out of a sysadmin's frustration with the limitations of shell scripting. You end up writing perl scripts that are basically just better shell scripts. This is not at all the same thing as using perl to build a web site or a fancy database-backed application. Often a sysadmin's perl scripts are one-liners executed with perl -e. Be aware of security implications --------------------------------- Security is everyone's responsibility. If any one staff member re-uses a password that got cracked somwhere else, or falls for a phishing scam, that is the weakest link. A sysadmin differs only in that we do a wide array of stuff all the time that might have security implications. Always have a background process evaluating whether there might be security implications of the thing you are currently working on. Create an ssh key, put it in root's authorize_keys, understand why it is a huge time saver if you are managing multiple machines. Understand the basic concept of public/private key pair based authentication. Understand 2FA and why it is great and also its limitations (lack of ability to automate). Understand the value of password keepers like bitwarden. Understand the architecture and why it is safe to keep them in the cloud, and/or the limitations thereof. Balance proactive and reactive work ----------------------------------- When a user comes to tell you that "the system is down" , do you drop everything to fix it? It depends on the user and what "the system" means. Is it just them or are they the first to report a problem that is affecting all users? Conversely, sometimes there will be minor problem that nobody reports for weeks and everyone just suffers in silence. Balancing proactive vs reactive is hard. You have to make judgement calls about the relative value of short vs long term things in a context that has emotional and personal impact. I said at the top "get satisfaction from helping others". But also understand appropriate boundaries.