We all get into routine habits in our jobs. But does that mean we're doing things the best way?

Over many years of administrating AIX systems, I developed some good and some not-so-good habits. I have managed to get rid of my bad habits. In this article, I will share with you from my own experience what habits I now avoid and what habits I embrace, or to put it another way, good habits to have.

The Good

Let's first look at the good habits that I recommend.

Smit

When learning AIX, I encourage you to use smit to perform your admin tasks. Why? Because smit will generate logs of the commands executed. This is good for two reasons:

• It enables you review and thus learn the syntax of the command(s) being executed is. Even if you're a seasoned AIX admin, it's good to review and keep up to date on command usage.
• It provides an audit log of commands executed via smit so you can review what commands were carried out in the past that may have had an adverse effect on a running AIX system.

Man Pages

Read those man pages if you aren't familiar with a command you're about to execute. AIX provides excellent man page content with plenty of examples. This is another good source of learning AIX.

Test, Test, Test

Before applying any change that might affect a running system, always test on a development/test machine first. If you get it wrong, learn from it and do it again. When you get it right, then do it on a production box. Implementing a change that makes AIX unusable on a production machine means end users probably won't be able to work and you're losing money for your business. It's that simple.

Bosboot Before Every Reboot

When you need to reboot your system, perhaps for a scheduled outage or after a system upgrade, always do a manual bosboot, even if an AIX upgrade does it for you during the upgrade process. You need to make sure you have a bootable kernel image you can boot up on so that if the bosboot fails, you can fix it. If you do a reboot and the boot image is corrupt, be prepared at least to re-create the image, at worst a full system recovery. Also check that your bootlist is correct for your devices prior to a reboot. Are you booting off in the correct order of devices? Use the following to check this:

bootlist -m normal -o

Check Your Space Requirements Before an Upgrade

When performing an AX upgrade, it's best to first do it in preview mode. AIX will report on estimated disk usage required. Note that this is just an estimate, so add 5% and then manually check it for yourself to make sure you have enough disk space for the upgrade. Don't rely on AIX being right all the time. If there's not enough space partway through an upgrade, the upgrade fails and can be messy to sort out.

The Bad

Let's now look at bad habits. Caution is advised with these!

Commands That Expand in the Shell

When removing files or changing ownerships on a system, especially if it is to travel down a file system tree, you can use the recursive option—that is, -R. It can sometimes be a time-savings to use the asterisk (*) command, for example:

rm -R *

chmod <owner> -R *

Hmmm. The asterisk (*) will expand when executed in the shell, and the results will not be what you expect, as it will start from the top of the file system tree you are working on. So always quote an asterisk ('*').

Crony Gone Wrong

Let's look at editing a crontab file, for example:

crontab -e

Notice the next key along on the keyboard is the r, which in the crontab work means to remove the current crontab file. Oops.

When editing, be sure to hit the e (edit) key to go into edit mode or the crontab entries. If you hit the r (remove) key on the keyboard, it will remove all your crontab entries. Ouch! In fact, why not do a backup first? All you need to do is redirect a listing on crontab to a file, like so:

crontab -l > <backup_filename>

When inserting a one-time event into crontab (such as an overnight reboot or the stopping of a service), be sure to remove it or comment it out after the event at the earliest opportunity. If you don't, it will come back to haunt you by executing the command again when the date schedule has been satisfied, like a year later!

Copy and Paste with Caution

When you have a lot of commands to run—say, to accomplish a certain task—it can be easier to copy and paste all those commands sequentially into a notepad. You then simply copy and paste these onto the command line to be executed. Now here it comes. If those commands contain a line feed/carriage return, the command will be executed as soon as you paste it. If you're not in the correct directory for these commands to be executed, you are not going to be popular. So always check that, when you a do a copy/paste, the commands do not have a hidden control character at the end of the command.

Be Good

Those are some of the good and not-so-good habits I picked up over the years. The bad habits have taught me to check, check, and check again before committing those commands.

David Tansley has over 10 years experience as a pSeries AIX administrator. When not working, he enjoys playing badminton and watching Formula 1. But his favorite social activity is touring on his GSA motorbike with his wife and fellow riders.

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails