it's the law (2 of 2)

ritter's second law of network administration: if you give a user something to click, they'll click it.

for all the complaints we make about them, users can be a resourceful lot. they seem to find all kinds of ways to get themselves into trouble, from making their desktop fonts so large that windows no longer fit on the screen to sticking a usb drive into the ethernet port on the side of a laptop and griping that the computer doesn't "see" the thumb drive anymore. it's this cleverness for getting themselves into a situation and their unwillingness to extricate themselves from it that leads me to my second law.

the problem is endemic: humans are attracted to something new and different. i have a ball-point pen that has a little blinking blue light on one end. i have no idea what purpose the cool blinking light serves, except that it made me buy the thing. users, too, will succumb to new icons, buttons, or anything that looks extraordinary, and they often end up sticking their mouse pointer where it doesn't belong.

the simple administrative solution is to hide things you don't want users to see. both windows and linux have policy tools that allow an administrator to remove features from the user's desktop, reducing the probability that they'll click the wrong thing. this is not a substitute for security: permissions and rights should still be configured to prevent a user from doing anything to the computer that's not in their job description. but if we can save just one harried help-desk employee the horror of a single clueless call, our work will have been worth the effort.

corollary to ritter's second law: all users lie.

as admins, we have all heard, "i didn't do anything. it just started acting like this." this is the silliest game we are forced to play. they know they're lying, and they know that you know they're lying. even though you're there to help them solve a problem they won't come clean and give you the information you need to fix it. while they wanly try to save face, you have to dig for the data that leads to a solution. the more they try to stroke their self-esteem to come across as "not dumb," the dumber they look. and the higher the position they hold in the company, the more indignant they become with you for giving them a "broken" system and not fixing it faster.

unfortunately, there is little we can do about this one. you can try the honest approach: let them know that you're there to help, that you know they're not stupid, that you just need to know what they've been doing on the computer to get it into its current state. you can even tell them that you'll find out eventually, so it would be better to just let it come out now. you may even add threats, like "if you can't tell me what you did to the computer, once i find out i'll have to discuss this with your superior to make sure it doesn't happen again." that might scare the pr0n right off of their hard drive.

or, just do your job, then go to the server room, lock the door and content yourself with fantasizing about doing unkind things to your users.

it's the law (1 of 2)

ritter's first law of network administration: an administrator at rest tends to stay at rest.

an administrator's day could easily be consumed with all the little, mundane tasks that are necessary to keep things running smoothly. backing up servers, reading log files, preparing reports on resource utilization, playing world of warcraft—it all really eats into one's time. that's why i formulated my first law of network administration. i noted that, as a network admin, when things could pretty much take care of themselves, i could relax and better savor the more fulfilling moments of my job, like reducing a user's disk quota or reading a user's more provocative email messages. here is a short alliterative list of tips to help you achieve network nirvana:

• aggregate: duplicating work increases the likelihood that you'll introduce errors and inconsistencies into your network's security, which is a bad idea no matter how you slice it. instead...
  
  
  1. locate shared resources that have common security requirements in the same directory structure on your file server. set access permissions only once on the highest-level directory that these files have in common. use permission inheritance to ensure consistent security on all the files in the hierarchy.
  
  
  2. don't assign permissions directly to users. add users to appropriate groups and assign permissions to the groups. that way you need only add a user to a group to ensure that all the access they require is properly configured.


• automate: do nothing by hand if possible, because hands can be so mistake-prone sometimes. learn a scripting language and write (or download and customize) scripts to perform common, repetitive tasks like reading log files and collecting report data. if you administer a windows network, you must learn powershell. it's available for windows versions from xp onward, and is the "wave of the future." if you administer a linux network, you must learn bash. if you manage a mixed environment, i strongly recommend that you learn python—it's sufficiently platform-independent and very mature, with a smörgåsbord of cool features built in.


• alert: let your network tell you when there are problems. install a network monitor system that's capable of notifying you when your file and email servers run low on disk space, or when your web server stops responding. when you can address a problem before your users even know it's there, they'll come to respect your precognitive powers and revere you for the system superhero you really are.

well, that last one, not really, because they won't know there was a problem in the first place, right? but hey, we're geeks: we're good at fantasy. now roll a d20 to see whether your invisibility-from-lumbergh spell worked before he asks for those tps reports. again.