AIX Down Under
AnthonyEnglish 270000RKFN Marcações:  english virtualisation vio aix anthony aussie australia down under 6.176 Visualizações
AIX has so many features and exciting developments, that it's a delight to blog about. In this blog I hope to provide something for absolute beginners as well as for those with a lot of exposure to AIX. I've been working on AIX since version 3.1 was released and I'm learning all the time.
I look forward to sharing ideas and learning new and better ways of doing things on AIX.
I'm an independent contractor working on IBM Power Systems in Sydney. Being Australian may explain the spelling (virtualisation, data centre) but hopefully you won't find my Aussie accent too hard to follow.
- Anthony English
AnthonyEnglish 270000RKFN Marcações:  systems list aix awk paste cut volumes lvm lsvgfs putty logical edit lv file 1 Comentário 60.928 Visualizações
If you've ever needed to list the file systems in a volume group, you've probably done something like this:
You would then need to strip out the header line and any logical volumes not associated with a file system, such as jfslogs, system dumps and the boot logical volume. Well, there's a simpler way: the lsvgfs command.
The syntax is very simple, as the man page for lsvgfs explains:
Putty box selection
There's another way of listing mounted file systems. If you use Putty and want to cut and paste a box or a single column from your window, you can use the Alt key as you make your selection with your mouse. You might use this, for example, when doing a list of files using or when you want to grab a column of output from the df command. This handy little feature allows you to cut a rectangle from your Putty window without having to use or some other method.
AnthonyEnglish 270000RKFN Marcações:  long login names user max_logname find cut aix permission login_name_max paste truncate chown putty tar who 3 Comentários 43.015 Visualizações
User names on AIX used to be restricted to eight characters. That's still the default setting but since AIX 5.3 you can increase the length up to an amazing 256 characters, if users really want to spend the morning logging in.
You can view the current maximum login name using:
lsattr –El sys0 | grep max_logname
Update: I incorrectly had listed the parameter as max_login. The correct parameter is max_logname. Thanks to jabber44 for the correction.
or via smit
System Environments -> Change / Show Characteristics of Operating System
then arrow down to the next page to see:
Maximum login name length at boot time  +#
You can change this setting here, or using the chdev command on the command line:
chdev -l sys0 -a max_logname=N
(Corrected here as well).
Whichever way you change it, it will only take effect from next time you reboot the OS.
Note from a kind reader: the value returned by max_logname appears to be an "x+1", so to allow 9 character usernames. set value to 10 or greater (and reboot).
The long and the short of user names
Why would you do this? Primarily to have user names consistent with network logins, such as when you use Kerberos to authenticate against Active Directory.
When you list files using the command ls -l, by default you only see the first eight characters of the owner's user name.
-rw------- 1 a_long_u system 0 May 13 09:53 file1
This can be misleading.
If you try to change ownership of a file via chown using that truncated name, you'll get a message that the user doesn't exist. So the ls command needs to be able to display the full name, which you can do using the -X flag:
-rw------- 1 a_long_username system 0 May 13 09:53 file1
There are other commands which require special options to display user names longer than 8 characters, such as
find (use -long)
tar which uses -E (-X is already used for something else)
who (-X again, just like the ls command)
Extravagance and inelegance
A couple of warnings. If you decide to revert to short names again, you may lock out users who had more extravagant login names before the reboot. It would not be an easy task to identify all the files which were owned by users with long names.
The other point to note is that long lists of files may result in the jagged-edge effect, which is exactly the reason those of us with a sense of symmetry keep logical volume names under 9 characters. If that's not reason enough, it can also make it hard to use that selection of a rectangle in Putty which I mentioned at the end of my blog entry on how to list file systems in a volume group.
AnthonyEnglish 270000RKFN Marcações:  command regular crontab one-off at schedule script jobs cron aix 2 Comentários 30.897 Visualizações
While you're in the middle of testing a new script, you may be tempted to add it to the cron to see how it goes. That involves:
After reworking the script a few times, looking up the crontab command which tells you that the week starts with 0 for Sunday, and minutes come before hours, and not putting in an extra asterisk which will run all files in the home directory for the user (which may be root), you end up with a very cluttered crontab file which hopefully doesn't have a surprise test job running every morning for evermore.
There is a much simpler way of running a one-off job: the at command. It's surprisingly easy to use and yet even administrators with long years of experience often say they have never used it. Here are some simple examples adapted from the man page for the at command.
Run command at now
In its simplest form, you could run your test script right now, using:
The time we're setting the command to run is "now". You may be more comfortable with setting the time before you specify the script to run:
Give me 5
The at command gives a lot of flexibility as to how you specify the time to start. You could start a job in exactly five minutes from now:
or maybe at a fixed time on a certain day. Here are five ways of setting a script to run at a given date and time:
Be careful with that last one. If you ran that at command some time on Friday, but after 3pm had passed, it wouldn't run until Friday of next week. It will run the next time Friday 3pm comes around.
crontab or at
crontab is for regular job schedules. The at command is for one-off jobs.
You could set a job to run again 5 minutes from the end of the current run by adding this into the script:
The cron doesn't give you that flexibility, as it only allows you to separate the start time of jobs, which means a second job may start off while the first one is still running.
Listing, cancelling and restricting at jobs
You can list jobs that are scheduled to run using at -l and you can remove them using at -r. The at man page explains how to control who can run the at command using /var/adm/cron/at.allow and /var/adm/cron/at.deny and some information about the environment. But in its simplest form, using will prevent your crontab file from being filled with mysterious test jobs and save you unnecessary surprises at unpredictable times.
AnthonyEnglish 270000RKFN Marcações:  typo line aix command bash ctrl-c escape edit prompt hash control-c pound comment korn shell esc vi 11.719 Visualizações
Recycle your typos
Do you use control-c a lot? What about the backspace key? I have to admit that on the command line I'm a pretty
Why is that so helpful? First of all, it turns your mistyped line into a comment. More importantly, it saves the line into your shell history, so you can recall it later.
A comment on your mistakes
You might not have thought of putting comments on the command line. Many people don't put them into their scripts. But if you turn your typing mistakes into comments, they won't get run. That's the idea of hitting control-c, but the escape-hash (or escape-pound) combination has a big advantage: it saves your mistakes for you to revisit them and fix them. (I'm sure there's a moral in that somewhere).
Recalling your mistakes
Esc # allows you to come back to a command you've half entered. If you use the Korn shell, you can use Esc k to revise your recent commands. If you prefer bash, use the up arrow. Once you've recalled the previous command (or, really, the previous comment), you can just hit Esc # to take out the comment symbol (#), edit the line if necessary and turn it into a real command.
You might like to use the great escape # when you start a command and think of another one you have to run first. I often use it when I cd to a long directory path but remember I need to check something first.
The great escape #
You may be surprised that a simple combination of key strokes can be so helpful. It allows you to recycle your unwanted commands. It's certainly easier than investing in learning to type.
AnthonyEnglish 270000RKFN Marcações:  hmc access centre remote management upgrade power system firmware ftp server managed update data 12.420 Visualizações
Updating the HMC in comfort ...
It's important to keep your Hardware Management Console firmware reasonably up to date. The HMC looks after the server hardware management. It also allows you to manage LPARs - create them, start and stop them, access the console and even assign resources dynamically. The HMC interacts closely with the hypervisors of the IBM POWER™ Systems so the HMC needs to be at a level which is compatible with the firmware of the managed system itself. Check your firmware compatibility on the IBM Systems Support web site.
With physical access to data centres getting more secure, it's good to know you can update your HMC remotely. Version 7 of the HMC introduced a web browser which allows you to manage LPARs from your yacht on Sydney Harbour instead of inside a data centre wearing your winter woollies.
(not the managed system)
Using the HMC you can also update system firmware, that is the firmware of the Managed System, (such as the Power6 570). But what we're talking about in this post is updating (and upgrading) HMC firmware - the version of the HMC itself.
... and in broad daylight
You don't usually need to schedule HMC updates at 2 o'clock on a Sunday morning. As the Hardware Management Console V7 Handbook explains:
The HMC is completely independent from the server. The server and all partitions can remain active while maintenance is performed on the HMC, allowing you to easily keep your HMC at the latest maintenance level. The HMC software level has to be maintained same as managed system firmware.If you're logged into the HMC, you can see your current version. In the Navigation area, click Updates. (This may be different on older versions of the HMC). Or by logging in using ssh to the restricted shell, run
Here's the output of that command from an HMC I recently updated to V7R7.1.0:
Update or upgrade?
If you're staying at the same Version of the HMC, and installing a new release, this is called an update. This can be done using an ftp server as outlined in the document how to update the HMC. You would use this, for example, if you are updating the HMC from V7R3.3.0 to V7R7.1.0. You can download the HMC updates to your own FTP server instead of connecting from the HMC directly to IBM.
If you're migrating to a new version, this is an HMC upgrade. Upgrading your HMC to a new version (e.g. from V6 to V7) can also be done remotely. The documentation accompanying the official instructions on how to upgrade the HMC give instructions on upgrading from media, but it can be done via FTP from a remote host. A remote host could even be an LPAR on a managed system which the HMC itself manages, but if that LPAR went down during the HMC upgrade, it could get ugly.
Let your fingers do the walking
IBM does have a technote on upgrading the HMC remotely, and I have done it by putting the downloads onto a local FTP server. It involves the HMC command line rather than the GUI, but it does work. Once you've upgraded the version of your HMC, you can use the update instructions via the HMC GUI to install any updates and service packs.
It's worthwhile having the HMC up to date with the latest features and fixes. It's quite straightforward, especially if you can do it from the comfort of your living room ... or while sailing past the Opera House. Don't forget the sunscreen.
AnthonyEnglish 270000RKFN Marcações:  recovery dr mkdvd mkcd devices virtual vmlibrary mksysb vio mkvdev file-backed disaster nim mkrep loadopt media aix 18 Comentários 72.147 Visualizações
Updated 28 January 2011
loopmount -i cdrom.iso -o "-V cdrfs -o ro" -m /mnt
AnthonyEnglish 270000RKFN Marcações:  page_up pconsole fastpath wiki_movie smit.log aix websm shortcut page_down system_management smit smitty smit.script 17.590 Visualizações
New users don't always realise that to exit SMIT you don't have to back out through each menu using F3 (or Esc-3). You can just use F10 (or Esc-0) to return to the shell after you're finished in SMIT.
F9 - The shell pit stop
One of my favourite SMIT shortcuts is the escape to shell using F9 (or Esc-9). That allows you to drop out of SMIT temporarily to run a shell command, and then type exit to return to exactly where you were in SMIT.
The SMIT fastpath allows you to make a quick entry into a SMIT screen without having to drill down through all the parent menus. Here are some examples of this:
Once you're inside SMIT you can view the fastpath using F8
(or Esc-8). The only drawback is that you have to exit
at the point you entered - you can't return to one of the parent
menus of the entry point.
AnthonyEnglish 270000RKFN Marcações:  environment image gold iso soe configuration virtualisation lpar aix operating standard vio install nim 2 Comentários 14.814 Visualizações
A Standard Operating Environment LPAR
It is so easy to build an AIX LPAR these days, that we can end up with lots of them very quickly. When this happens, or even before it does, it may be worth building one more : a Standard Operating Environment or SOE. This can provide consistency in your organisation's configuration and make it even faster to build new LPARs without starting from scratch.
What is an SOE for AIX?
The NIM from A to Z in AIX 5L Redbook has a valuable section on building an SOE. Although it's for NIM on AIX 5, it raises some important issues. The Best Practices section explains that an SOE for AIX systems is "a set of best practices, procedures, documents, standards, conventions, tools, and utilities with which you install and administer an AIX server." The server doesn't need to be physical - an LPAR is also a server. It's a logical server, so it doesn't need to have its own dedicated hardware.
Virtually ready for an SOE
A virtualised environment makes it easy to build new LPARs very quickly. You no longer need dedicated hardware: disk, network, CPU, memory can all be allocated without hardware investments or even stepping into a data centre. As we've seen before on AIX Down Under, it's easy to load ISO images via the VIO server. That makes it straightforward to build a new SOE and then to clone it to create other LPARs. If you prefer to use NIM, you can refer to the Redbook mentioned above as well as online documentation for NIM.
Detonate, don't renovate
Plenty of green field AIX sites start out with a single LPAR which is meant to serve as the "golden image" from which all new LPARs will be built. If it's the first LPAR then it ends up having all sorts of software installed for testing. Standards are broken quicker than they are created and what was the golden image soon looks a little more like it's made of lead. It's probably time to start again.
Carrying the sins of the past
In other situations, a previous "legacy" version of AIX is in place. It has many mysterious hacks, features, links, installations and settings which no one really understands and everyone is afraid to touch. Although you could clone this system, with its workarounds (that word should always send a shiver up your spine), you will probably find that it's worth making a completely fresh start with a New and Complete Overwrite of AIX. You can always review the old system's configuration, but at least the changes you make to the new image will be understood and documented, rather than remaining in the secret realm of IT whizzes from generations before us.
Laying the foundations
So how do you build a Standard Operating Environment (SOE) LPAR from scratch? First, as we saw in an earlier post, you can install a base AIX using the VIO server virtual media library. Every organisation is different and it's impossible to outline a standard which will fit everyone, but here are some ideas which will help:
Global or local?
Some configurations are likely to be universal across all AIX LPARs. The software and configuration settings which ought to apply to every LPAR, ought to be in the SOE. Other changes will only apply to certain LPARs. Is every LPAR going to be a TSM client, or a DB2 or Oracle client? Does Apache get installed? What about monitoring agents, standard scripts, tuning parameters? Every change from a vanilla install is going to be either global (on the SOE) or local - restricted to a limited number of LPARs. Once you understand which changes belong to which category, you're a long way towards building your SOE LPAR. The more localised software might be sitting in a common file system, perhaps on a NIM server or in a management LPAR.
Learning to SOE
There are many more factors in building a SOE LPAR - it's impossible to cover them all here. But if you have a good grasp of the steps involved, you could have a new SOE LPAR built by this afternoon (except that I'm writing this late at night, Sydney time, but you get the point).
* I'm not sure if "unrelocatable" is a real word, but my surname is English, so I reserve the right to invent my own dictionary.
AnthonyEnglish 270000RKFN Marcações:  os original_state dvd soppy_greeting_card crontab camel_trainer mkcd varyonvg volume_groups mksysb delete rm recover mkdvd disaster rootvg install 1 Comentário 13.382 Visualizações
"Clean up the system"
You have suddenly been appointed as AIX administrator after the previous admin disappeared in mysterious circumstances. You've logged onto the AIX system once before.
rm -rf *rm commandWikipedia entry for "rm"crontab -e
Maybe you will restore mksysb from tape or restore from a DVD-RAM. You could use mkdvd to convert a mksysb file to ISO. If the mksysb was created in ISO format, you could install the ISO image via the VIO server.
Time to exhale
Soon enough you'll have a rootvg restored, a login prompt and a system ready to configure network communications if you need to. There'll be files which didn't get restored in the mksysb, such as those that are excluded via the -e flag in your mksysb / mkcd / mkdvd. You might have some data volume groups to resurrect using importvg and varyonvg, and then some files and databases to restore. But all in all, you've replaced a nice "clean" system with one that's going to work again.
You have learned that prevention is better than cure.