On Linux, you sometimes may run into an issue where you can't change permissions of a file, even though you're root, and you have access. For example:

# ls -asl authorized_keys
8 -rw------- 1 root root 6325 Sep 17 02:48 authorized_keys
# chmod 700 authorized_keys
chmod: changing permissions of `authorized_keys': Operation not 
permitted
# whoami
root

This is usually caused by the Extendef File System Attributes, especially if package e2fsprogs is installed. Two commands that will come in handy here are /usr/bin/chattr and /usr/bin/lsattr.

The most common attributes are:

• A - When the file is accessed the atime record is not modified. This avoids a certain amount of disk I/O.
• a - When this file is opened, it is opened in append only mode for writing.
• i - This file cannot be modified, renamed or deleted.

For example:

# lsattr authorized_keys
----i-------- authorized_keys

This shows that the immutable flag (i) is in place on the file, and thus the reason why the file can't be modified. To remove it, use chattr:

# chattr -i authorized_keys
# lsattr authorized_keys
------------- authorized_keys

Now any commands to modify the file, will work:

# chmod 700 authorized_keys

Virtual clients running on a IVM (Integrated Virtualization Manager) do not have a direct atached serial console nor a virtual window which can be opened via an HMC. So how do you access the console?

You can log on as the padmin user on the VIOS which is serving the client you want to logon to its console. Just log on to the VIOS, switch to user padmin:

# su - padmin

Then run the lssyscfg command to list the available LPARs and their IDs on this VIOS:

# lssyscfg -r lpar -F name,lpar_id

Alternatively you can log on to the IVM using a web browser and click on "View/Modify Partitions" which will also show LPAR names and their IDs.

Use the ID of the LPAR you wish to access:

# mkvt -id [lparid]

This should open a console to the LPAR. If you receive a message "Virtual terminal is already connected", then the session is already in use. If you are sure no one else is using it, you can use the rmvt command to force the session to close.

# rmvt -id [lparid]

After that you can try the mkvt command again.

When finished log off and type "~." (tilde dot) to end the session. Sometimes this will also close the session to the VIOS itself and you may need to logon to the VIOS again.

Not very much known is the machstat command in AIX that can be used to display the status of the Power Status Register, and thus can be helpful to identify any issues with either Power or Cooling.

# machstat -f
0 0 0

If it returns all zeroes, everything is fine. Anything else is not good. The first digit (the so-called EPOW Event) indicates the type of problem:

EPOW Event	Description
0	normal operation
1	non-critical cooling problem
2	non-critical power problem
3	severe power problem - halt system
4	severe problems - halt immediately
5	unhandled issue
7	unhandled issue

Another way to determine if the system may have a power or cooling issue, is by looking at a crontab entry in the root user's crontab:

# crontab -l root | grep -i powerfail
0 00,12 * * * wall%rc.powerfail:2::WARNING!!! The system is now operating with a power problem. This message will be walled every 12 hours. Remove this crontab entry after the problem is resolved.

If a powerfail message is present in the crontab of user root, this may indicate that there is an issue to be looked into. Contact your IBM representative to check the system out. Afterwards, make sure to remove the powerfail entry from the root user's crontab.

Want to know which LVM commands were run on a system? Simply run the following command, and get a list of the LVM command history:

# alog -o -t lvmcfg

To filter out only the actual commands:

# alog -o -t lvmcfg | grep -v -E "workdir|exited|tellclvmd"
[S 06/11/13-16:52:02:236 lvmstat.c 468] lvmstat -v testvg
[S 06/11/13-16:52:02:637 lvmstat.c 468] lvmstat -v rootvg
[S 07/20/13-15:02:15:076 extendlv.sh 789] extendlv testlv 400
[S 07/20/13-15:02:33:199 chlv.sh 527] chlv -x 4096 testlv
[S 08/22/13-12:29:16:807 chlv.sh 527] chlv -e x testlv
[S 08/22/13-12:29:26:150 chlv.sh 527] chlv -e x fslv00
[S 08/22/13-12:29:46:009 chlv.sh 527] chlv -e x loglv00
[S 08/22/13-12:30:55:843 reorgvg.sh 590] reorgvg

The information for this LVM command history is stored in /var/adm/ras/lvmcfg.log. You can check the location for a circular log, by running:

# alog -t lvmcfg -L
#file:size:verbosity
/var/adm/ras/lvmcfg.log:51200:3

More detail can also be found in the lvmt log, by running:

# alog -t lvmt -o

You may be familiar with suspending a process that is running in the foreground by pressing CTRL-Z. It will suspend the process, until you type "fg", and the process will resume again.

# sleep 400

After pressing CTRL-Z, you'll see:

[1] + Stopped (SIGTSTP)        sleep 400

Then type "fg" to resume the process:

# fg
sleep 400

But what if you wish to suspend a process that is not attached to a terminal, and is running in the background? This is where the kill command is useful. Using signal 17, you can suspend a process, and using signal 19 you can resume a process.

This is how it works: First look up the process ID you wish to suspend:

# sleep 400 &
[1]     8913102
# ps -ef | grep sleep
    root  8913102 10092788   0 07:10:30  pts/1  0:00 sleep 400
    root 14680240 10092788   0 07:10:34  pts/1  0:00 grep sleep

Then suspend the process with signal 17:

# kill -17 8913102
[1] + Stopped (SIGSTOP)        sleep 400 &

To resume it again, send signal 19:

# kill -19 8913102

The use of $RANDOM in Korn Shell can be very useful. Korn shell built-in $RANDOM can generate random numbers in the range 0:32767. At every call a new random value is generated:

# echo $RANDOM
19962
# echo $RANDOM
19360

The $RANDOM Korn shell built-in can also be used to generate numbers within a certain range, for example, if you want to run the sleep command for a random number of seconds.

To sleep between 1 and 600 seconds (up to 10 minutes):

# sleep $(print $((RANDOM%600+1)))

To know quickly how many virtual processors are active, run:

# echo vpm | kdb

For example:

# echo vpm | kdb
...
VSD Thread State.
 CPU VP_STATE   SLEEP_STATE  PROD_TIME: SECS   NSECS     CEDE_LAT

   0  ACTIVE    AWAKE        0000000000000000  00000000  00
   1  ACTIVE    AWAKE        0000000000000000  00000000  00
   2  ACTIVE    AWAKE        0000000000000000  00000000  00
   3  ACTIVE    AWAKE        0000000000000000  00000000  00
   4  DISABLED  AWAKE        00000000503536C7  261137E1  00
   5  DISABLED  SLEEPING     0000000051609EAF  036D61DC  02
   6  DISABLED  SLEEPING     0000000051609E64  036D6299  02
   7  DISABLED  SLEEPING     0000000051609E73  036D6224  02

There are 2 ways for reading the Diagnostics log file, located in /var/adm/ras/diag:

The first option uses the diag tool. Run:

# diag

Then hit ENTER and select "Task Selection", followed by "Display Previous Diagnostic Results" and "Display Previous Results".

The second option is to use diagrpt. Run:

# /usr/lpp/diagnostics/bin/diagrpt -s 010101

To display only the last entry, run:

# /usr/lpp/diagnostics/bin/diagrpt -o

To create a system backup of a Virtual I/O Server (VIOS), run the following commands (as user root):

# /usr/ios/cli/ioscli viosbr -backup -file vios_config_bkup
-frequency daily -numfiles 10
# /usr/ios/cli/ioscli backupios -nomedialib -file /mksysb/$(hostname).mksysb -mksysb

The first command (viosbr) will create a backup of the configuration information to /home/padmin/cfgbackups. It will also schedule the command to run every day, and keep up to 10 files in /home/padmin/cfgbackups.

The second command is the mksysb equivalent for a Virtual I/O Server: backupios. This command will create the mksysb image in the /mksysb folder, and exclude any ISO repositiory in rootvg, and anything else excluded in /etc/exclude.rootvg.

It is useful to run the following commands before you create your (at least) weekly mksysb image:

# lsvg -o | xargs -i mkvgdata {}
# tar -cvf /sysadm/vgdata.tar /tmp/vgdata

Add these commands to your mksysb script, just before running the mksysb command. What this does is to run the mkvgdata command for each online volume group. This will generate output for a volume group in /tmp/vgdata. The resulting output is then tar'd and stored in the /sysadm folder or file system. This allows information regarding your volume groups, logical volumes, and file systems to be included in your mksysb image.

To recreate the volume groups, logical volumes and file systems:

• Run:

  # tar -xvf /sysadm/vgdata.tar

• Now edit /tmp/vgdata/{volume group name}/{volume group name}.data file and look for the line with "VG_SOURCE_DISK_LIST=". Change the line to have the hdisks, vpaths or hdiskpowers as needed.
• Run:

  # restvg -r -d /tmp/vgdata/{volume group name}/{volume group name}.data

Make sure to remove file systems with the rmfs command before running restvg, or it will not run correctly. Or, you can just run it once, run the exportvg command for the same volume group, and run the restvg command again. There is also a "-s" flag for restvg that lets you shrink the file system to its minimum size needed, but depending on when the vgdata was created, you could run out of space, when restoring the contents of the file system. Just something to keep in mind.