If you have to change the password for a user, and you have a need to script this, for example if you have the password for multiple users, or on several different servers, then here's an easy way to change the password for a user, without having to type the password on the command line prompt:

# echo "user:password" | chpasswd

To find out if sendmail is running:

# ps -ef | grep sendmail

# stopsrc -s sendmail
# startsrc -s sendmail -a "-bd -q30m"

# refresh -s sendmail

# cat /etc/motd |mailx -v -s"test" email@address.com

hosts=local

DETECTING MODULE
'srchevn.c'@line:'355'
FAILING MODULE
sendmail

# startsrc -s sendmail -a "-bd -q30m"

If an AIX server is backed up by Veritas NetBackup, then this is how you can enable logging of the backups on your AIX client:

First, make sure the necessary folders exist in /usr/openv/netbackup/logs, and the access is set to 777, by running:

# mkdir bp bparchive bpbackup bpbkar bpcd bpdbsbora
# mkdir bpfilter bphdb bpjava-msvc bpjava-usvc bpkeyutil
# mkdir bplist bpmount bpnbat bporaexp bporaexp64 
# mkdir bporaimp bporaimp64 bprestore db_log dbclient
# mkdir symlogs tar user_ops
# chmod 777 *

VERBOSE = 2

# egrep "bpcd" /etc/services
bpcd        13782/tcp # VERITAS NetBackup
bpcd        13782/udp # VERITAS NetBackup
# grep bpcd /etc/inetd.conf
bpcd stream tcp nowait root /usr/openv/netbackup/bin/bpcd bpcd

You can ssh as user hscroot to the HMC, and change the password this way:

hscroot@hmc> chhmcusr -u hscroot -t passwd
Enter the new password:
Retype the new password:

In order to keep the system time synchronized with other nodes in an HACMP cluster or across the enterprise, Network Time Protocol (NTP) should be implemented. In its default configuration, NTP will periodically update the system time to match a reference clock by resetting the system time on the node. If the time on the reference clock is behind the time of the system clock, the system clock will be set backwards causing the same time period to be passed twice. This can cause internal timers in HACMP and Oracle databases to wait longer periods of time under some circumstances. When these circumstances arise, HACMP may stop the node or the Oracle instance may shut itself down.

Oracle will log an ORA-29740 error when it shuts down the instance due to inconsistent timers. The hatsd daemon utilized by HACMP will log a TS_THREAD_STUCK_ER error in the system error log just before HACMP stops a node due to an expired timer.

To avoid this issue, system managers should configure the NTP daemon to increment time on the node slower until the system clock and the reference clock are in sync (this is called "slewing" the clock) instead of resetting the time in one large increment. The behavior is configured with the -x flag for the xntpd daemon.

To check the current running configuration of xntpd for the -x flag:

# ps -aef | grep xntpd | grep -v grep
    root  409632  188534   0 11:46:45      -  0:00 /usr/sbin/xntpd

# chssys -s xntpd -a "-x"
0513-077 Subsystem has been changed.
# stopsrc -s xntpd
0513-044 The /usr/sbin/xntpd Subsystem was requested to stop.
# startsrc -s xntpd
0513-059 The xntpd Subsystem has been started. Subsystem PID is 40932.
# ps -f | grep xntpd | grep -grep
    root  409632  188534   0 11:46:45      -  0:00 /usr/sbin/xntpd -x

On Linux, you can use the tmpfs to create a RAM disk:

# mkdir -p /mnt/tmp
# mount -t tmpfs -o size=20m tmpfs /mnt/tmp

The AIX mkramdisk command allows system administrators to create memory-resident file systems. The performance benefits of using RAM disk can be astonishing. The unload of a large TSM database was reduced from 40 hours on SAN disks down to 10 minutes using RAM disk.

The configuration of a RAM disk file system is very simple and takes just a few minutes. Once the file system is mounted, it can be used like any other file system. There are three steps involved: creating the RAM disk, making the file system and then mounting the file system.

First, we create the RAM disk, specifying the size we want. Let's create a RAM disk of 4 GB:

# mkramdisk 4G

# ls -l /dev/ram*
brw-------    1 root system  46, 0 Sep 22 08:01 /dev/ramdisk0

# mkfs -V jfs2 /dev/ramdisk0

# mkdir -p /ramdisk0

# mount -V jfs2 -o log=NULL /dev/ramdisk0 /ramdisk0

# mkramdisk 4G
# mkfs -V jfs /dev/ramdisk0
# mkdir /ramdisk0
# mount -V jfs -o nointegrity /dev/ramdisk0 /ramdisk0

# rmramdisk ramdisk0

Before AIX 5L Version 5.1, a core file was always stored in a file named core. If the same or another application generated another core file before you renamed the previous one, the original content was lost.

Beginning with AIX 5L Version 5.1, you can enable a unique naming of core files, but be aware that the default behavior is to name the files core. You apply the new enhancement by setting the environment variable CORE_NAMING to a non-NULL value, for example:

CORE_NAMING=yes

export CORE_NAMING=

• pid: Process ID
• dd: Day of the month
• hh: Hours
• mm: Minutes
• ss: Seconds

# ls -l core*
-rw-r--r--   1 user group   8179 Jan 28 2010  core.30480.28232347
-rw-r--r--   1 user group   8179 Jan 28 2010  core.30482.28232349

Sudosh is designed specifically to be used in conjunction with sudo or by itself as a login shell. Sudosh allows the execution of a root or user shell with logging. Every command the user types within the root shell is logged as well as the output.

This is different from "sudo -s" or "sudo /bin/sh", because when you use one of these instead of sudosh to start a new shell, then this new shell does not log commands typed in the new shell to syslog; only the fact that a new shell started is logged.

If this newly started shell supports commandline history, then you can still find the commands called in the shell in a file such as .sh_history, but if you use a shell such as csh that does not support command-line logging you are out of luck.

Sudosh fills this gap. No matter what shell you use, all of the command lines are logged to syslog (including vi keystrokes). In fact, sudosh uses the script command to log all key strokes and output.

Setting up sudosh is fairly easy. For a Linux system, first download the RPM of sudosh, for example from rpm.pbone.net. Then install it on your Linux server:

# rpm -ihv sudosh-1.8.2-1.2.el4.rf.i386.rpm
Preparing...  ########################################### [100%]
   1:sudosh   ########################################### [100%]

# sudosh -i
[info]: chmod 0733 directory /var/log/sudosh

username ALL=PASSWD:/usr/bin/sudosh

$ sudo sudosh
Password:
# whoami
root

# sudosh-replay
Date       Duration From To   ID
====       ======== ==== ==   ==
09/16/2010 6s       root root root-root-1284653707-GCw26NSq

Usage: sudosh-replay ID [MULTIPLIER] [MAXWAIT]
See 'sudosh-replay -h' for more help.
Example: sudosh-replay root-root-1284653707-GCw26NSq 1 2

# sudosh-replay root-root-1284653707-GCw26NSq 1 5

Always watch out for files with the SUID bit set; especially if these are files that are not on the AIX system by default. Before any vendor or application team installs additional software on the AIX system, it may be worth file to run the following command, to discover any files with the SUID bit set:

# find / \( -perm -2000 -o -perm -4000 \) -type f -ls

#include <stdio.h>
#include <time.h>

char *getlogin();

#define LOG_FILE "/tmp/sushilog"

main(argc, argv)
int argc;
char **argv;
{
  char buf[1024], *p=buf;
  int i, t;
  FILE *log;
  char msg[BUFSIZ], *ct, *name;

  *p='\0';
  for (i=1; i<argc; ++i)
  {
    strcpy(p, argv[i]);
    p += strlen(argv[i]);
    if (i < argc-1)
    {
      *p = ' ';
      ++p;
      *p = '\0';
    }
  }

  time(&t);
        ct = ctime(&t);
        name = getlogin();

  setuid(0);

  log = fopen(LOG_FILE, "a");
  if (!log)
    printf("Couldn't open log file!\n");
  else
    {
      sprintf(msg, "SUSHI: %s  %s  %s\n", name, buf, ct);
      fputs(msg, log);
      fclose(log);
      system(buf);
    }
}

################################################
# Make rules                                   #
################################################

all:    sushi

sushi: sushi.o
        $(CC) -o $@ sushi.o

clean:
        rm -f *.o sushi

install:
        cp -p sushi /bin
        chown root  /bin/sushi
        chmod a+rx  /bin/sushi
        chmod u+s   /bin/sushi

################################################
# Source/object rules                          #
################################################

sushi.o: sushi.c
        gcc -c $*.c

# ls -als /bin/sushi
8 -rwsr-xr-x  1 root root 6215 Sep  9 09:21 /bin/sushi

$ /bin/sushi ksh
# whoami
root

/exports/install:
        dev             = "/exports/install"
        vfs             = nfs
        nodename        = fileserver.company.com
        mount           = true
        options         = ro,bg,hard,intr,nodev,nosuid,sec=sys
        account         = false

# mount -o nosuid server:/filesystem /mountpoint

# mount | grep nfs
server   /filesystem   /mountpoint    nfs3   Sep 09 09:30 nosuid