There is a way to mount a share from a windows system as an NFS filesystem in AIX:

1. Install the CIFS software on the AIX server (this is part of AIX itself: bos.cifs_fs).
2. Create a folder on the windows machine, e.g. D:\share.
3. Create a local user, e.g. "share" (user IDs from Active Directory can not be used): Settings -> Control Panel -> User Accounts -> Advanced tab -> Advanced button -> Select Users -> Right click in right window and select "New User" -> Enter User-name, password twice, deselect "User must change password at next logon" and click on create and close and ok.
4. Make sure the folder on the D: drive (in this case "share") is shared and give the share a name (we'll use "share" again as name in this example) and give "full control" permissions to "Everyone".
5. Create a mountpoint on the AIX machine to mount the windows share on, e.g. /mnt/share.
6. Type on the AIX server as user root:

   # mount -v cifs -n hostname/share/password -o uid=201,fmode=750 /share /mnt/share

7. You're done!

Permanently change hostname for inet0 device in the ODM by choosing one of the following:

Command line method:

# chdev -l inet0 -a hostname=[newhostname]

# smitty hostname

# uname -S [newhostname]

# /etc/rc.net

# hostname [newhostname]

It may happen that a virtual terminal (vterm) from an HMC GUI only showes a black screen, even though the Lpar is running perfectly. Here's a solution to this problem:

• Login to the HMC using ssh as hscroot.
• Run lssscfg -R sys to determine the machine name of your lpar on the HMC.
• Run mkvterm -m [machine-name] -p [partition-name].
• You can end this session by typing "~." or "~~." (don't overlook the "dot" here!).
• Now go back to your HMC gui via WebBased System Manager and start-up a new vterm. It works again!

A very easy way to see what was installed recently on your system:

# lslpp -h

It is very easy to clone your rootvg to another disk, for example for testing purposes. For example: If you wish to install a piece of software, without modifying the current rootvg, you can clone a rootvg disk to a new disk; start your system from that disk and do the installation there. If it succeeds, you can keep using this new rootvg disk; If it doesn't, you can revert back to the old rootvg disk, like nothing ever happened.

First, make sure every logical volume in the rootvg has a name that consists of 11 characters or less (if not, the alt_disk_copy command will fail).

To create a copy on hdisk1, type:

alt_disk_copy -d hdisk1

# alt_rootvg_op -X old_rootvg

# alt_disk_copy -d "hdisk4 hdisk5"

The AIX kernel has an "enter_dbg" variable in it that can be set at the beginning of the boot processing which will cause all boot process output to be sent to the system console. In some cases, this data can be useful in debugging boot issues. The procedure for setting the boot debugger is as follows:

First: Preparing the system.

Set up KDB to present an initial debugger screen

# bosboot -ad /dev/ipldevice -I

# shutdown -Fr

************* Welcome to KDB *************
    Call gimmeabreak...
    Static breakpoint:
    .gimmeabreak+000000     tweq     r8,r8    r8=0000000A
    .gimmeabreak+000004      blr
<.kdb_init+0002C0> r3=0
    KDB(0)> mw enter_dbg
    enter_dbg+000000:  00000000  = 42
    xmdbg+000000:  00000000  = .
    KDB(0)> g

************* Welcome to KDB *************
    Call gimmeabreak...
    Static breakpoint:
    .gimmeabreak+000000     tweq     r8,r8    r8=0000000A
    .gimmeabreak+000004      blr
<.kdb_init+0002C0> r3=0
    KDB(0)> mw enter_dbg
    enter_dbg+000000:  00000042  = 0
    xmdbg+000000:  00000000  = .
    KDB(0)> g

# bosdebug -o
# bosboot -ad /dev/ipldevice

When you encounter an issue where ssh through a firewall works perfectly, but when doing scp of large files (for example mksysb images) the scp connection stalls, then there's a solution to this problem: Add "-l 8192" to the scp command.

The reason for scp to stall, is because scp greedily grabs as much bandwith of the network as possible when it transfers files, any delay caused by the network switch of the firewall can easily make the TCP connection stalled.

Adding the option "-l 8192" limits the scp session bandwith up to 8192 Kbit/second, which seems to work safe and fast enough (up to 1 MB/second):

# scp -l 8192 SOURCE DESTINATION

Let's say you want to know what process is tying up port 25000:

# netstat -aAn | grep 25000
f100060020cf1398  tcp4  0  0  *.25000  *.*  LISTEN
f10006000d490c08  stream  0  0  f1df487f8  0  0  0  /tmp/.sapicm25000

# rmsock f100060020cf1398 tcpcb
The socket 0x20cf1008 is being held by proccess 1806748 (icman).

# lsof -i :[PORT]

# lsof -i :5710
COMMAND     PID   USER   FD   TYPE     DEVICE  SIZE/OFF NODE NAME
oracle  2638066 oracle   18u  IPv4 0xf1b3f398 0t1716253  TCP host:5710

If your AIX server level is below 5.3 TL06, the easiest way is just to upgrade your current OS to TL 06 at minimum (take note it will depend of configurations for Power6 processors) then clone your server and install it on the new p6.

But if you want to avoid an outage on your account, you can do the next using a NIM server (this is not official procedure for IBM, so they do not support this):

• Create your mksysb resource and do not create a spot from mksysb.
• Create an lppsource and spot with minimum TL required (I used TL08).
• Once you do nim_bosinst, choose the mksysb, and the created spot. It will send a warning message about spot is not at same level as mksysb, just ignore it.
• Do all necessary to boot from NIM.
• Once restoring the mksysb, there's some point where it is not able to create the bootlist because it detects the OS level is not supported on p6. So It will ask to continue and fix it later via SMS or fix it right now.
• Choose to fix it right now (it will open a shell). You will notice oslevel is as the same as mksysb.
• Create a NFS from NIM server or another server where you have the necessary TL and mount it on the p6.
• Proceed to do an upgrade, change the bootlist, exit the shell. Server will boot with new TL over the p6.

Sudo is an excellent way to provide root access to commands to other non-root users, without giving them too much access to the system.

A very simple command to show you what a specific user is allowed to do:

# su - [username] -c sudo -l
User [username] may run the following commands on this host:
    (root) NOPASSWD: /usr/local/sbin/reset.ksh
    (root) NOPASSWD: /usr/local/bin/mkpasswd
    (root) NOPASSWD: !/usr/local/bin/mkpasswd root