Topics: AIX, Monitoring, System Admin

"Bootpd: Received short packet" messages on console

If you're receiving messages like these on your console:

Mar 9 11:47:29 daemon:notice bootpd[192990]: received short packet
Mar 9 11:47:31 daemon:notice bootpd[192990]: received short packet
Mar 9 11:47:38 daemon:notice bootpd[192990]: hardware address not found: E41F132E3D6C
Then it means that you have the bootpd enabled on your server. There's nothing wrong with that. In fact, a NIM server for example requires you to have this enabled. However; these messages on the console can be annoying. There are systems on your network that are sending bootp requests (broadcast). Your system is listening to these requests and trying to answer. It is looking in the bootptab configuration (file /etc/bootptab) to see if their mac-addresses are defined. When they aren't, you are getting these messages.

To solve this, either disable the bootpd daemon, or change the syslog configuration. If you don't need the bootpd daemon, then edit the /etc/inetd.conf file and comment the entry for bootps. Then run:
# refresh -s inetd
If you do have a requirement for bootpd, then update the /etc/syslog.conf file and look for the entry that starts with daemon.notice:
#daemon.notice /dev/console
daemon.notice /nsr/logs/messages
By commenting the daemon.notice entry to /dev/console, and instead adding an entry that logs to a file, you can avoid seeing these messages on the console. Now all you have to do is refresh the syslogd daemon:
# refresh -s syslogd

Topics: AIX, Backup & restore, Monitoring, Red Hat / Linux, Spectrum Protect

Report the end result of a TSM backup

A very easy way of getting a report from a backup is by using the POSTSchedulecmd entry in the dsm.sys file. Add the following entry to your dsm.sys file (which is usually located in /usr/tivoli/tsm/client/ba/bin or /opt/tivoli/tsm/client/ba/bin):

POSTSchedulecmd "/usr/local/bin/RunTsmReport"
This entry tells the TSM client to run script /usr/local/bin/RunTSMReport, as soon as it has completed its scheduled command. Now all you need is a script that creates a report from the dsmsched.log file, the file that is written to by the TSM scheduler:
#!/bin/bash
TSMLOG=/tmp/dsmsched.log
WRKDIR=/tmp
echo "TSM Report from `hostname`" >> ${WRKDIR}/tsmc
tail -100 ${TSMLOG} > ${WRKDIR}/tsma
grep -n "Elapsed processing time:" ${WRKDIR}/tsma > ${WRKDIR}/tsmb
CT2=`cat ${WRKDIR}/tsmb | awk -F":" '{print $1}'`
((CT3 = $CT2 - 14))
((CT5 = $CT2 + 1 ))
CT4=1
while read Line1 ; do
   if [ ${CT3} -gt ${CT4} ] ; then
      ((CT4 = ${CT4} + 1 ))
   else
      echo "${Line1}" >> ${WRKDIR}/tsmc
      ((CT4 = ${CT4} + 1 ))
      if [ ${CT4} -gt ${CT5} ] ; then
         break
      fi
   fi
done < ${WRKDIR}/tsma
mail -s "`hostname` Backup" email@address.com < ${WRKDIR}/tsmc
rm ${WRKDIR}/tsma ${WRKDIR}/tsmb ${WRKDIR}/tsmc

Topics: Monitoring, PowerHA / HACMP, Security

HACMP 5.4: How to change SNMP community name from default "public" and keep clstat working

HACMP 5.4 supports changing the default community name from "public" to something else. SNMP is used for clstatES communications. Using the "public" SNMP community name, can be a security vulnerability. So changing it is advisable.

First, find out what version of SNMP you are using:

# ls -l /usr/sbin/snmpd
lrwxrwxrwx 1 root system 9 Sep 08 2008 /usr/sbin/snmpd -> snmpdv3ne
(In this case, it is using version 3).

Make a copy of your configuration file. It is located on /etc.
/etc/snmpd.conf <- Version 1
/etc/snmpdv3.conf <- Version 3
Edit the file and replace wherever public is mentioned for your new community name. Make sure to use not more that 8 characters for the new community name.

Change subsystems and restart them:
# chssys -s snmpmibd -a "-c new"
# chssys -s hostmibd -a "-c new"
# chssys -s aixmibd -a "-c new"
# stopsrc -s snmpd
# stopsrc -s aixmibd
# stopsrc -s snmpmibd
# stopsrc -s hostmibd
# startsrc -s snmpd
# startsrc -s hostmibd
# startsrc -s snmpmibd
# startsrc -s aixmibd
Test using your locahost:
# snmpinfo -m dump -v -h localhost -c new -o /usr/es/sbin/cluster/hacmp.defs nodeTable
If the command hangs, something is wrong. Check the changes you made.

If everything works fine, perform the same change in the other node and test again. Now you can test from one server to the other using the snmpinfo command above.

If you need to backout, replace with the original configuration file and restart subsystems. Note in this case we use double-quotes. There is no space.
# chssys -s snmpmibd -a ""
# chssys -s hostmibd -a ""
# chssys -s aixmibd -a ""
# stopsrc -s snmpd
# stopsrc -s aixmibd
# stopsrc -s snmpmibd
# stopsrc -s hostmibd
# startsrc -s snmpd
# startsrc -s hostmibd
# startsrc -s snmpmibd
# startsrc -s aixmibd
Okay, now make the change to clinfoES and restart and both nodes:
# chssys -s clinfoES -a "-c new"
# stopsrc -s clinfoES
# startsrc -s clinfoES
Wait a few minutes and you should be able to use clstat again with the new community name.

Disclaimer: If you have any other application other than clinfoES that uses snmpd with the default community name, you should make changes to it as well. Check with your application team or software vendor.

Topics: AIX, Monitoring

Removing error report entries forever

There's a way to avoid certain entries appearing in the error report indefinitely. You can use this for example for tape cleaning messages:

The following command shows you the entries that are written to the error log, but not reported on:

# errpt -t -F Report=0
Let's say you don't want any reports on errors with ID D1A1AE6F:
# errupdate [Enter]
=D1A1AE6F: [Enter]
Report=False [Enter]
[Ctrl-D]
[Ctrl-D]
With "Report=False", errors are still logged in your logfile (usually /var/adm/ras/errlog). If you don't want them to be logged to the error log, for example when you have an errnotify (which still starts an action, also for error ID's with "Report=False"), you can change "Report=False" to "Log=False".

More info on this subject can be found here.

Topics: AIX, Hardware, Monitoring

Temperature monitoring

Older pSeries systems (Power4) are equipped with environmental sensors. You can read the sensor values using:

# /usr/lpp/diagnostics/bin/uesensor -l
You can use these sensors to monitor your systems and your computer rooms. It isn't very difficult to create a script to monitor these environmental sensors regularly and to display it on a webpage, updating it automatically. Newer systems (LPAR based) are not equipped with these environmental sensors. For PC systems several products exist, which attach to either a RJ45 or a parallel port and which can be used to monitor temperatures.

Number of results found for topic Monitoring: 15.
Displaying results: 11 - 15.