If you have a boss that you send your journal to, spellcheck your journal.
The journal isn't just for your boss, it's for you.
It's your own FAQ.
It's your own collection of HOWTOs to help you and others reproduce work in the future on other systems.
When you make an entry in your journal, ask yourself, “Is this enough information to allow me and maybe others to reproduce this work that I just spent hours on?
It can get huge over time, which is why there may be a need for a better system of self-documentation than a flat text file.
Possibly something blog-like where you can add tags to each journal entry.
The journal has to be backed up and accessible from anywhere, at your fingertips.
This is why some admins keep logs in notebooks (paper notebooks), though this has several drawbacks.
If your journal is on a company server or your office workstation, and the network is down, and you're at home 30 miles away, and you need some vital information that's in the journal…now what?
Use comments in /etc/config files to document your changes.
Sign and date your comments for your future reference and for other admins.
In general, be well-organized.
whether that's the directory structure under your home directory or your written journal
Use technology in documentation.
Set up a web page or FAQ.
Use video or digital photography.
Sometimes, a picture is literally worth a thousand words.
The hard stuff (security and backups)
Take care of the hard stuff first.
The worst feelings for a SysAdmin (makes you fear getting fired):
The system got hacked.
Something important got deleted, and there's no backup.
Backups, security hardening, disaster recovery plan
How good is the backup?
Do you have a system and plan for doing bare-metal recovery?
Check if you can actually restore from the backup.
Run a file system integrity (FSI) checker.
Is your FSI database and configuration file on a read-only medium?
From read-only medium or NFS mount
Run a root kit scanner.
From a read-only medium or NFS mount
Be aware of recently discovered security problems and exploits and incidents.
Do you subscribe to newsgroups and mailing lists that might give you this information?
Before installing, think about the possibility of uninstalling.
Compile and install to /usr/local means files scattered to /usr/local/bin, /usr/local/lib, /usr/local/share, /usr/local/etc, /usr/local/sbin.
Does software's Makefile have a working uninstall target?
Users
Will rarely describe their problems with a level of detail that is needed to solve their problems.
Asking for their password so that you can login as them to diagnose their problems, should be avoided.
If you must, then they must change their password afterward.
Can use su - userid or some other method to start a process as another user.
Ask for a screenshot.
Sometimes as easy as hitting the <Print Screen> key
Or using their cell phones
“Eat your own dog food.”
Use the same environment as the users, the same machines on the same networks as the users, so that you can catch problems they may come to you with.
Be a user. Use user tools.
Can't be a UNIX admin w/o first being a UNIX user (Also applies to Windows)
Do concern yourself with the usability of the OS environment for your users.
This will have the added benefit of reducing your support headaches.
Use sensible settings in default shell profiles in /etc/skel
without compromising security
no ”.“ in $PATH, umask=077
an informative shell prompt
Will the default user interface (window manager or desktop) be familiar and intuitive enough for CS 175 students and also minimize complaints from professors?
No drive letters and easy access to USB flash drives could frustrate many users, whether they are Linux newbies or not.
Systems such as autofs work for removable media, though setting them up are usually not easy tasks.
Balance against ease of administration.
Simple window managers like IceWM: faster startup, smaller memory footprint, easy to configure (for the admin), familiar-looking interface
Desktop environments like Gnome/KDE: slower startup, bigger memory footprint, easy to configure (for the user)
User training
A support web page with FAQs?
Occasional “UNIX for Dummies” seminars?
Don't assume that the users aren't smart enough or that they are not aware of published security exploits.
The “would never happen here” mentality
Standardization vs. Diversity
Standardize on one distro of Linux or use multiple distros?
If standardize, choose your standard distro wisely.
Consider the projected continuity of a distro.
Debian's continuity seems like a good bet.
less so with many Debian derivatives
Multiple distros also a good idea
redhat still the most widely used distro, and rpm the most widely used package format
Good to be familiar with rpm-based distros and redhat-like distros.
Multiple UNIX versions also a good idea
What if, by some miracle, SCO wins and Linux is lost?
FreeBSD waiting in the wings
Solaris x86? (future looks bleak)
AIX? (not free; bleh)
Mac OS X (see AIX)
Advocacy
Should a UNIX admin advocate the use of UNIX?
Up to a point
An admin should advocate the right tool for the job ..
.. and learn the right tool for the job, even if that happens to be Windows.
Learning Administration
Learn administration by doing administration.
More likely to learn if something goes wrong.
Keeping up with the Joneses
What technologies are being used “out there,” and are we behind the times?
LDAP instead of NIS
cfengine instead of my own scripts
systemimager instead of my own scripts
Ethics and Licenses
A professor wants to use their single-user license for a language interpretor for an entire class of students ..
.. and wants you to install the interpretor on the server.
A student has 2 GB worth of mp3s in his home directory.
A student has 2 GB worth of legitimate research output in his home directory.