system administration help

IBM Licence Metric Tools agent Instalation Automation for AIX and Linux

2013-05-22T05:32:00.001+05:30

Hello Guys

Below script installs and verifys the IBM Licence Metric Tools on Linux and AIX

Prequsits for this script

1) Password less authentication / Password authentication for the destination server where you want to install the Agent
2) yum repo configured for Linux clients

Hear is the script

#!/bin/ksh

#

# This script was designed to install Tivoli agent

#

# Written Sreekar Peddi 5/6/13

Filepath="/local/home/speddi02"

FileName="ILMT-TAD4D-agent-7.5.0-shell-all.tar.gz"

Installcmd="ksh"

datef=`date '+%d-%m'`

datefile="ILMT$datef"

if [ "$1" == "" ]; then

echo " Please provide the File contains list of servers \n"

exit

fi

lppcmd="lslpp -L ILMT-TAD4D-agent
grep ILMT-TAD4D-agent"

agentbin="ILMT-TAD4D-agent-7.5-aix-ppc.bin"

serverName="$1"

# Server Name Check

if [ $serverName = " " ] ; then

printf " Please Provide the server name \n"

exit

fi

cmd="ssh -qn $serverName"

OS=$( $cmd "uname" )

if [ "$OS" == "AIX" ] ; then

lppcmd="lslpp -L ILMT-TAD4D-agent
grep ILMT-TAD4D-agent"

agentbin="ILMT-TAD4D-agent-7.5-aix-ppc.bin"

fi

if [ "$OS" == "Linux" ] ; then

#Need to check arch if it is linux

arc=$($cmd "/usr/bin/lscpu
egrep 'Architecture'" )

arc1=$(echo $arc
awk '{print $2}'
cut -d'_' -f1)

#echo "Archi $arc1"

agentbin="ILMT-TAD4D-agent-7.5-linux-$arc1.bin"

lppcmd="rpm -qa
grep -i ilmt"

fi

# check if the ITLM agent is already installed on the server

checkAgent()

{

lppres=$($cmd $lppcmd 2>&1)

if [ "$OS" == "AIX" ] ; then

tst=$(echo $lppres
egrep 'not installed' )

if [ "$tst" == "" ] ; then

#echo " The file set is Installed on the server $serverName "

echo "yes"

else

#echo " The file set is Not installed"

echo "not"

fi

else

tst=$(echo $lppres)

if [ "$tst" == "" ] ; then

#echo " The file set is Installed on the server $serverName "

echo "not"

else

#echo " The file set is Not installed"

echo "yes"

fi

fi

}

agent=$(checkAgent)

#echo " Test Result : $agent"

if [ "$agent" == "yes" ] ; then

echo " The Agent is installed on the server $serverName"

else

echo " The file set is not installed $serverName"

echo " Now I am coping the File required to the $serverName to install the agent ........... "

echo " Please wait .."

ssh -qn $serverName "mkdir /tmp/$datefile"

scp $Filepath/$FileName $serverName:/tmp/$datefile > /dev/null 2>$1

if [ $? -eq 0 ] ; then

echo " File copied to $serverName now I am Installing......."

echo " Extracting the tar files ......."

ssh -qn $serverName "cd /tmp/$datefile;gunzip < /tmp/$datefile/$FileName
tar xvf - "

if [ $? -eq 0 ] ; then

echo " Files Exttracted ......"

echo " Installing Agent ......"

ssh -qn $serverName "ksh /tmp/$datefile/$agentbin -install"

if [ $? -eq 0 ] ; then

echo " Verifing agent Instalation please Wait......"

agve=$(checkAgent)

#echo " agve val : $agve"

if [ "$agve" == "yes" ] ; then

echo " The agent is Installed successfully..."

else

echo " The agent is not isntalled , please login server $serverName and verify"

fi

else

echo " The agent is not isntalled , please login server $serverName and verify"

fi

else

echo " Files NOT Extracted there is some problem .."

fi

else

echo " There is some problem in coping the file, exiting....."

exit

fi

fi

AIX error reporting

2011-07-05T10:12:00.001+05:30

This article will focus on one of those tools: the error logging facility. I'll show you how the AIX error logging facility works
The Error Logging Subsystem
On most UNIX systems, information and errors from system events and processes are managed by the syslog daemon (syslogd); depending on settings in the configuration file /etc/syslog.conf, messages are passed from the operating system, daemons, and applications to the console, to log files, or to nowhere at all. AIX includes the syslog daemon, and it is used in the same way that other UNIX-based operating systems use it. In addition to syslog, though, AIX also contains another facility for the management of hardware, operating system, and application messages and errors. This facility, while simple in its operation, provides unique and valuable insight into the health and happiness of an RS/6000 system.
The AIX error logging facility components are part of the bos.rte and the bos.sysmgt.serv_aid packages, both of which are automatically placed on the system as part of the base operating system installation. Some of these components are shown in Table 1.
1) errorsave , errlast kernel services
errorlog subroutine   - Kernel and application interface for passing error information to the /dev/error special file
2) /dev/error - Special dive file that receive error messages from kernel and application interfaces
3) /usr/lib/errdemon - Demon that starts at system initialization and monitors the /dev/error and controls error logging process.
4) /var/adm/ras/errlog - The default error log file
5) /usr/bin/errpt - Command used to generate error report from error log
6) /var/adm/ras/errtmplt - File contains error template repository
7) /usr/bin/errclear - Command used to clear the errors from error log

Unlike the syslog daemon, which performs no logging at all in its default configuration as shipped, the error logging facility requires no configuration before it can provide useful information about the system. The errdemon is started during system initialization and continuously monitors the special file /dev/error for new entries sent by either the kernel or by applications. The label of each new entry is checked against the contents of the Error Record Template Repository, and if a match is found, additional information about the system environment or hardware status is added, before the entry is posted to the error log.
The actual file in which error entries are stored is configurable; the default is /var/adm/ras/errlog. That file is in a binary format and so should never be truncated or zeroed out manually. The errlog file is a circular log, storing as many entries as can fit within its defined size. A memory buffer is set by the errdemon process, and newly arrived entries are put into the buffer before they are written to the log to minimize the possibility of a lost entry. The name and size of the error log file and the size of the memory buffer may be viewed with the errdemon command:

     [aixhost:root:/] # /usr/lib/errdemon -l
     Error Log Attributes
     --------------------------------------------
     Log File                 /var/adm/ras/errlog
     Log Size                 1048576 bytes
     Memory Buffer Size       8192 bytes

The parameters displayed may be changed by running the errdemon command with other flags, documented in the errdemon man page. The default sizes and values have always been sufficient on our systems, so I've never had reason to change them.
Due to use of a circular log file, it is not necessary (or even possible) to rotate the error log. Without intervention, errors will remain in the log indefinitely, or until the log fills up with new entries. As shipped, however, the crontab for the root user contains two entries that are executed daily, removing hardware errors that are older than 90 days, and all other errors that are older than 30 days.
     0 11 * * * /usr/bin/errclear -d S,O 30
     0 12 * * * /usr/bin/errclear -d H 90
These entries are commented out on my systems, as I prefer that older errors are removed "naturally", when they are replaced by newer entries.
Viewing Errors
Although a record of system errors is a good thing (as most sys admins would agree), logs are useless without a way to read them. Because the error log is stored in binary format, it can't be viewed as logs from syslog and other applications are. Fortunately, AIX provides the errpt command for reading the log.
The errpt command supports a number of optional flags and arguments, each designed to narrow the output to the desired amount. The man page for the errpt command provides detailed usage; Table 2 provides a short summary of the most useful arguments. (Note that all date/time specifications used with the errpt command are in the format of mmddHHMMyy, meaning "month", "day", "hour", "minute", "year"; seconds are not recorded in the error log, and are not specified with any command.)
-a    Generates a detailed report of entries in the error log
-d ERRORCLASS    To specify the calass of the error ,H – Hardware, S – Software, O– operator notice , U – undetermined
-e TimeStamp    To specify the time only before which the error are displayed
-s Timestamp    To specify the time only after which the error are displayed
-j IDENTIFIER    To specify only entries with the identifiers
-k IDENTIFIER    TO specify the exclude identifier list
-c    View error log concurrently
-t     Generate a report from the error template repository.

Each entry in the AIX error log can be classified in a number of ways; the actual values are determined by the entry in the Error Record Template Repository that corresponds with the entry label as passed to the errdemon from the operating system or an application process. This classification system provides a more fine-grained method of prioritizing the severity of entries than does the syslog method of using a facility and priority code. Output from the errpt command may be confined to the types of entries desired by using a combination of the flags in Table 2.

Dissecting an Error Log Entry
Entries in the error log are formatted in a standard layout, defined by their corresponding template. While different types of errors will provide different information, all error log entries follow a basic format.

Here are several examples of error log entry summaries:

     IDENTIFIER TIMESTAMP T C RESOURCE_NAME DESCRIPTION
     D1A1AE6F   0223070601 I H rmt3           TAPE SIM/MIM RECORD
     5DFED6F1   0220054301 I O SYSPFS         UNABLE TO ALLOCATE SPACE
                                              IN FILE SYSTEM
     1581762B   0219162801 T H hdisk98        DISK OPERATION ERROR

And here is the full entry of the second error summary above:

     LABEL:            JFS_FS_FRAGMENTED
     IDENTIFIER:       5DFED6F1
     Date/Time:        Tue Feb 20 05:43:35
     Sequence Number: 146643
     Machine Id:       00018294A400
     Node Id:          rescue
     Class:            O
     Type:             INFO
     Resource Name:    SYSPFS
     Description
     UNABLE TO ALLOCATE SPACE IN FILE SYSTEM
     Probable Causes
     FILE SYSTEM FREE SPACE FRAGMENTED
     Recommended Actions
           CONSOLIDATE FREE SPACE USING DEFRAGFS UTILITY
     Detail Data
     MAJOR/MINOR DEVICE NUMBER
     000A 0006
     FILE SYSTEM DEVICE AND MOUNT POINT
     /dev/hd9var, /var

Monitoring with errreporter
Most, if not all systems administrators have had to deal with an "overload" of information. Multiple log files and process outputs must be monitored constantly for signs of trouble or required intervention. This problem is compounded when the administrator is responsible for a number of systems. Various solutions exist, including those built into the logging application (i.e., the use of a loghost for syslog messages), and free third-party solutions to monitor log files and send alerts when something interesting appears. One such tool that we rely on is "swatch", developed and maintained by Todd Atkins. Swatch excels at monitoring log files for lines that match specific regular expressions, and taking action for each matched entry, such as sending an email or running a command.
For all of the power of swatch, though, I was unable to set up the configuration to perform a specific task: monitoring entries in the AIX error log, ignoring certain specified identifiers, and emailing the full version of the entry to a specified address, with an informative subject line. So, I wrote my own simple program that performs the task I desired. errreporter (Listing 1) is a Perl script runs the errpt command in concurrent mode, checks new entries against a list of identifiers to be ignored, crafts a subject line based upon several fields in the entry, and emails the entire entry to a specified address.
errreporter can be run from the command line, though I have chosen to have it run automatically at system startup, with the following entry in /etc/inittab (all on a single line, but broken here, for convenience):

     errrptr:2:respawn:/usr/sec/bin/errreporter -f /usr/sec/etc/errreporter.conf/dev/console 2&1

Of course, if you choose to use this script, be sure to set the proper locations in your inittab entry. The system must have Perl installed; Perl is included with AIX as of version 4.3.3, and is available in source and compiled forms from numerous Web sites. It relies only on modules that are included with the base Perl distribution (see Listing 2 for errreporter.conf file).
Although this script perfectly suits my current needs, there are many areas in which it could be expanded upon or improved. For instance, it may be useful to have entries mailed to different addresses, based upon the entry's identifier. Another useful feature would be to incorporate "loghost"-like functionality, so that a program running on a single server can receive error log entries sent by other systems, communicating via sockets à la the syslog "@loghost" method.
Summary
The AIX Error Logging Facility can provide insight into the workings of your system that are not available on other UNIX platforms. I find it to be just one of the many advantages of AIX in a production environment, and I hope that I have helped to explain this simple yet powerful tool.
In this article, I have touched on some of the more commonly used aspects of the Error Logging Facility in AIX. There are numerous other features and capabilities of this subsystem, including the use of the "diag" command for error log analysis and problem determination, the addition of custom error templates, the redirection of error log entries to and from the syslog daemon, and the use of error notification routines in user-developed code to provide notice and error logging to this subsystem. For more information on those topics, and more detail on the items discussed above, please see the documents listed in the References section below.

System Boot process in AIX

2011-05-31T08:13:00.000+05:30

System Boot process in AIX

Most users perform a hard disk boot when starting the system for general operations. The system finds all information necessary to the boot process on its disk drive.

When the system is started by turning on the power switch (a cold boot) or restarted with the reboot or shutdown commands (a warm boot), a number of events must occur before the system is ready for use. These events can be divided into the following phases:

• ROS kernel init phase

The ROS kernel resides in firmware.

Its initialization phase involves the following steps:

1. The firmware checks to see if there are any problems with the system board. Control is passed to ROS, which performs a power-on self-test (POST).

2. The ROS initial program load (IPL) checks the user boot list, a list of available boot devices. This boot list can be altered to suit your requirements using the bootlist command. If the user boot list in non-volatile random access memory (NVRAM) is not valid or if a valid boot device is not found, the default boot list is then checked. In either case, the first valid boot device found in the boot list is used for system startup. If a valid user boot list exists in NVRAM, the devices in the list are checked in order. If no user boot list exists, all adapters and devices on the bus are checked. In either case, devices are checked in a continuous loop until a valid boot device is found for system startup.

Note: The system maintains a default boot list that is stored in NVRAM for normal mode boot. A separate service mode boot list is also stored in NVRAM, and you should refer to the specific hardware instructions for your model to learn how to access the service mode boot list.

3. When a valid boot device is found, the first record or program sector number (PSN) is checked. If it is a valid boot record, it is read into memory and is added to the IPL control block in memory. Included in the key boot record data are the starting location of the boot image on the boot device, the length of the boot image, and instructions on where to load the boot image in memory.

4. The boot image is read sequentially from the boot device into memory starting at the location specified in NVRAM. The disk boot image consists of the kernel, a RAM file system, and base customized device information.

5. Control is passed to the kernel, which begins system initialization.

6. The kernel runs init, which runs phase 1 of the rc.boot script.

When the kernel initialization phase is completed, base device configuration begins.

• Base device configuration phase

The init process starts the rc.boot script. Phase 1 of the rc.boot script performs the base device configuration.

Phase 1 of the rc.boot script includes the following steps:

1. The boot script calls the restbase program to build the customized Object Data Manager (ODM) database in the RAM file system from the compressed customized data.

2. The boot script starts the configuration manager, which accesses phase 1 ODM configuration rules to configure the base devices.

3. The configuration manager starts the sys, bus, disk, SCSI, and the Logical Volume Manager (LVM) and rootvg volume group configuration methods.

4. The configuration methods load the device drivers, create special files, and update the customized data in the ODM database.

• Booting the system

Use these steps to complete the system boot phase.

1. The init process starts phase 2 running of the rc.boot script. Phase 2 of rc.boot includes the following steps:

a. Call the ipl_varyon program to vary on the rootvg volume group.

b. Mount the hard disk file systems onto their normal mount points.

c. Run the swapon program to start paging.

d. Copy the customized data from the ODM database in the RAM file system to the ODM database in the hard disk file system.

e. Exit the rc.boot script.

After phase 2 of rc.boot, the boot process switches from the RAM file system to the hard disk root file system.

Continuous system-performance monitoring with commands in AIX

2011-05-30T07:18:00.002+05:30

Continuous system-performance monitoring with commands in AIX

The vmstat, iostat, netstat, and sar commands provide the basic foundation upon which you can construct a performance-monitoring mechanism.
You can write shell scripts to perform data reduction on the command output, warn of performance problems, or record data on the status of a system when a problem is occurring. For example, a shell script can test the CPU idle percentage for zero, a saturated condition, and execute another shell script for when the CPU-saturated condition occurred. The following script records the 15 active processes that consumed the most CPU time other than the processes owned by the user of the script:

# ps -ef | egrep -v "STIME|$LOGNAME" | sort +3 -r | head -n 15

•    Continuous performance monitoring with the vmstat command

The vmstat command is useful for obtaining an overall picture of CPU, paging, and memory usage.
The following is a sample report produced by the vmstat command:
# vmstat 5 2
kthr     memory             page              faults        cpu
----- ----------- ------------------------ ------------ -----------
r b   avm   fre re pi po fr   sr cy in   sy cs us sy id wa
1 1 197167 477552   0   0   0   7   21   0 106 1114 451 0 0 99 0
0 0 197178 477541   0   0   0   0    0   0 443 1123 442 0 0 99 0
Remember that the first report from the vmstat command displays cumulative activity since the last system boot. The second report shows activity for the first 5-second interval.

•    Continuous performance monitoring with the iostat command

The iostat command is useful for determining disk and CPU usage.
The following is a sample report produced by the iostat command:
# iostat 5 2

tty:      tin         tout   avg-cpu: % user    % sys     % idle    % iowait
          0.1        102.3               0.5      0.2       99.3       0.1
                " Disk history since boot not available. "

tty:      tin         tout   avg-cpu: % user    % sys     % idle    % iowait
          0.2        79594.4               0.6      6.6       73.7      19.2

Disks:        % tm_act     Kbps      tps    Kb_read   Kb_wrtn
hdisk1           0.0       0.0       0.0          0         0
hdisk0          78.2     1129.6     282.4       5648         0
cd1              0.0       0.0       0.0          0         0
Remember that the first report from the iostat command shows cumulative activity since the last system boot. The second report shows activity for the first 5-second interval.
The system maintains a history of disk activity. In the example above, you can see that the history is disabled by the appearance of the following message:
Disk history since boot not available.
To disable or enable disk I/O history with smitty, type the following at the command line:
# smitty chgsys

Continuously maintain DISK I/O history [value]
and set the value to either false to disable disk I/O history or true to enable disk I/O history. The interval disk I/O statistics are unaffected by this setting.

•    Continuous performance monitoring with the netstat command

The netstat command is useful in determining the number of sent and received packets.
The netstat command is useful in determining the number of sent and received packets.
The following is a sample report produced by the netstat command:
# netstat -I en0 5
    input    (en0)     output           input   (Total)    output
packets errs packets errs colls packets errs packets errs colls
8305067     0 7784711     0     0 20731867     0 20211853     0     0
       3     0        1     0     0        7     0        5     0     0
      24     0      127     0     0       28     0      131     0     0
CTRL C
Remember that the first report from the netstat command shows cumulative activity since the last system boot. The second report shows activity for the first 5-second interval.

•    Continuous performance monitoring with the sar command

The sar command is useful in determining CPU usage.
The sar command is useful in determining CPU usage.
The following is a sample report produced by the sar command:
# sar -P ALL 5 2

AIX aixhost 2 5 00040B0F4C00    01/29/04

10:23:15 cpu    %usr    %sys    %wio   %idle
10:23:20 0        0       0       1      99
          1        0       0       0     100
          2        0       1       0      99
          3        0       0       0     100
          -        0       0       0      99
10:23:25 0        4       0       0      96
          1        0       0       0     100
          2        0       0       0     100
          3        3       0       0      97
          -        2       0       0      98

Average   0        2       0       0      98
          1        0       0       0     100
          2        0       0       0      99
          3        1       0       0      99
          -        1       0       0      99
The sar command does not report the cumulative activity since the last system boot

Etherchannel configuration on LINUX

2011-05-27T05:29:00.000+05:30

Creating Ether channel on LINUX

Creating an EtherChannel between a Red Hat Enterprise 5 server, and a Cisco Catalyst 3750 Switch. This is actually far simpler then it sounds, and can be completed in about ten minutes.

We’ll begin with configuring the IEEE 802.3ad Dynamic link aggregation (AKA EtherChannel) on the Red Hat Enterprise Linux server. Begin by logging in via SSH, Telnet or directly on the console itself. I do recommend having access to the console directly, so should anything go wrong and you lose network connectivity you’ll be able to easily change things back.

Once logged into the server, switch user to "root" if you’re not already logged in as root. Change directory to "/etc" and modify the "modprobe.conf" file using your favorite text editor such as "vi". I personally like using "nano". Add the lines in bold from the example "modprobe.conf" below to your file. Then save your changes and return to the bash prompt.

Sample /etc/modprobe.conf

alias scsi_hostadapter megaraid_sas
alias scsi_hostadapter1 usb-storage
alias eth0 bnx2
alias eth1 bnx2
alias bond0 bonding
options bond0 miimon=100 mode=4 lacp_rate=1

Next we need to create a network script for the "bond0" interface that we defined above in the "modprobe.conf" file. This will be used to configure the network properties for the virtual adapter. Once again, use your favorite text editor to create a new file called "ifcfg-bond0" in the "/etc/sysconfig/network-scripts" directory. In this file you will define the device name used above"bond0", IP address, gateway, network mask etc for the virtual adapter. Below is an example.

Sample /etc/sysconfig/network-scripts/ifcfg-bond0

DEVICE=bond0
BOOTPROTO=none
ONBOOT=yes
NETWORK=192.168.0.0
NETMASK=255.255.255.0
IPADDR=192.168.0.25
USERCTL=no
GATEWAY=192.168.0.1
TYPE=Ethernet
IPV6INIT=no
PEERDNS=yes

When you’re done configuring the properties of the virtual adapter, save your changes and exit the editor.

The next step is to modify the network script for each adapter that will be added to the EtherChannel. The adapters that we’ll be using in this server are eth0 and eth1. Please note your interfaces may be different, so check before continuing.

Start by modifying "ifcfg-" using your text editor, where is the interface name. In this case my file name is "ifcfg-eth0". Add the proper references to the virtual adapter created above "bond0" and remove any IP information such as IP address, gateway, netmask etc since that information will be handled by the virtual adapter. Below is an example of the "ifcfg-eth0" file. Note the bold items are required for the EtherChannel to function properly.

Sample /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0
BOOTPROTO=none
HWADDR=00:11:22:33:44:55
ONBOOT=yes
MASTER=bond0
SLAVE=yes
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=yes

Repeat the steps above for each additional interface you add to the Etherchannel.

Sample /etc/sysconfig/network-scripts/ifcfg-eth1

DEVICE=eth1
HWADDR=66:77:88:99:aa:bb
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none
TYPE=Ethernet
USERCTL=no

Now that each physical adapter has been associated to the virtual adapter,

Not able to FTP or copy a file with more than 2 GB

2011-02-18T12:11:00.000+05:30

Copy error when trying to copy a file from your pc to server where file size is more than 2GB.

Error : cp: Requested a write of 4096 bytes, but wrote only 3584

How to to get out of this error

Scenario :

I was trying to copy 2.5 GB file from my local system to AIX system through WinScp but after copying 1 GB file coping of file get stopped.

Then I tried with FTP still the same issue.

Then I tried to copy that file from one Linux machine through NFS (after successfully uploaded to LINUX system) to AIX still the same issue.

Getting error : " cp: Requested a write of 4096 bytes, but wrote only 3584. "

Then I remember the USer options .

ULIMIT is the one which we need to check

so I changed the ulimit to unlimited for temporary and able to copy the file.

#ulimit -f unlimited
#ulimit -d unlimited

So How to use Ulimit

User limits - limit the use of system-wide resources.

Syntax
      ulimit [-acdfHlmnpsStuv] [limit]

Options

   -S   Change and report the soft limit associated with a resource.
   -H   Change and report the hard limit associated with a resource.

   -a   All current limits are reported.
   -c   The maximum size of core files created.
   -d   The maximum size of a process's data segment.
   -f   The maximum size of files created by the shell(default option)
   -l   The maximum size that may be locked into memory.
   -m   The maximum resident set size.
   -n   The maximum number of open file descriptors.
   -p   The pipe buffer size.
   -s   The maximum stack size.
   -t   The maximum amount of cpu time in seconds.
   -u   The maximum number of processes available to a single user.
   -v   The maximum amount of virtual memory available to the process.

ulimit provides control over the resources available to the shell and to processes started by it, on systems that allow such control.

The soft limit is the value that the kernel enforces for the corresponding resource. The hard limit acts as a ceiling for the soft limit.

An unprivileged process may only set its soft limit to a value in the range from 0 up to the hard limit, and (irreversibly) lower its hard limit. A privileged process may make arbitrary changes to either limit value.

If limit is given, it is the new value of the specified resource. Otherwise, the current value of the soft limit for the specified resource is printed, unless the `-H' option is supplied.
When setting new limits, if neither `-H' nor `-S' is supplied, both the hard and soft limits are set.
Restricting per user processes ( -u) can be useful for limiting the potential effects of a fork bomb.

Values are in 1024-byte increments, except for `-t', which is in seconds, `-p', which is in units of 512-byte blocks, and `-n' and `-u', which are unscaled values.
The return status is zero unless an invalid option is supplied, a non-numeric argument other than unlimited is supplied as a limit, or an error occurs while setting a new limit.
ulimit is a bash built in command.

Configuring MPIO for Virtual AIX client

2011-01-20T16:02:00.000+05:30

Configuring MPIO for the virtual AIX client
This document describes the procedure to set up Multi-Path I/O on the AIX clients of
the virtual I/O server.

Procedure:
This procedure assumes that the disks are already allocated to both the VIO servers
involved in this configuration.

· Creating Virtual Server and Client SCSI Adapters
First of all, via HMC create SCSI server adapters on the two VIO servers and
then two virtual client SCSI adapters on the newly created client partition, each
mapping to one of the VIO servers´ server SCSI adapter.
An example:
Here is an example of configuring and exporting an ESS LUN from both the
VIO servers to a client partition:

· Selecting the disk to export
You can check for the ESS LUN that you are going to use for MPIO by
running the following command on the VIO servers.
On the first VIO server:
$ lsdev -type disk
name status description
..
hdisk3 Available MPIO Other FC SCSI Disk Drive
hdisk4 Available MPIO Other FC SCSI Disk Drive
hdisk5 Available MPIO Other FC SCSI Disk Drive
..
$lspv
..
hdisk3 00c3e35c99c0a332 None
hdisk4 00c3e35c99c0a51c None
hdisk5 00c3e35ca560f919 None
..
In this case hdisk5 is the ESS disk that we are going to use for MPIO.
Then run the following command to list the attributes of the disk that you choose for MPIO:
$lsdev -dev hdisk5 -attr
..
algorithm fail_over Algorithm True
..
lun_id 0x5463000000000000 Logical Unit Number ID False
..
..
pvid 00c3e35ca560f9190000000000000000 Physical volume identifier
False
..
reserve_policy single_path Reserve Policy True
Note down the lun_id, pvid and the reserve_policy of the hdisk4.

· Command to change reservation policy on the disk
You see that the reserve policy is set to single_path.
Change this to no_reserve by running the following command:
$ chdev -dev hdisk5 -attr reserve_policy=no_reserve
hdisk4 changed
On the second VIO server:
On the second VIO server too, find the hdisk# that has the same pvid, it could
be a different one than the one on the first VIO server, but the pvid should the
same.
$ lspv
..
hdisk7 00c3e35ca560f919 None
..
The pvid of the hdisk7 is the same as the hdisk5 on the first VIO server.
$ lsdev -type disk
name status description
..
hdisk7 Available MPIO Other FC SCSI Disk Drive
..
$lsdev -dev hdisk7 -attr
..
algorithm fail_over Algorithm True
..
lun_id 0x5463000000000000 Logical Unit Number ID False
..
pvid 00c3e35ca560f9190000000000000000 Physical volume identifier
False
..
reserve_policy single_path Reserve Policy True
You will note that the lun_id, pvid of the hdisk7 on this server are the same as
the hdisk4 on the first VIO server.
$ chdev -dev hdisk7 -attr reserve_policy=no_reserve
hdisk6 changed

· Creating the Virtual Target Device
Now on both the VIO servers run the mkvdev command using the appropriate
hdisk#s respectively.
$ mkvdev -vdev hdisk# -vadapter vhost# -dev vhdisk#
The above command might have failed when run on the second VIO server, if
the reserve_policy was not set to no_reserve on the hdisk.
After the above command runs succesfully on both the servers, we have
same LUN exported to the client with mkvdev command on both servers.

· Check for correct mapping between the server and the client
Double check the client via the HMC that the correct slot numbers match the
respective slot numbers on the servers.
In the example, the slot number 4 for the client virtual scsi adapter maps to
slot number 5 of the VIO server VIO1_nimtb158.
And the slot number 5 for the client virtual SCSI adapter maps to the slot
number 5 of the VIO server VIO1_nimtb159.

· On the client partition
Now you are ready to install the client. You can install the client using any of
the following methods described in the red book on virtualization at
http://www.redbooks.ibm.com/redpieces/abstracts/sg247940.html:
1. NIM installation
2. Alternate disk installation
3. using the CD media
Once you install the client, run the following commands to check for MPIO:
# lsdev -Cc disk
hdisk0 Available Virtual SCSI Disk Drive
# lspv
hdisk0 00c3e35ca560f919 rootvg active
# lspath
Enabled hdisk0 vscsi0
Enabled hdisk0 vscsi1

· Dual Path
When one of the VIO servers goes down, the path coming from that server
shows as failed with the lspath command.
# lspath
Failed hdisk0 vscsi0
Enabled hdisk0 vscsi1

· Path Failure Detection
The path shows up in the "failed" mode, even after the VIO server is up
again. We need to either change the status with the “chpath” command to
“enabled” state or set the the attributes “hcheck_interval” and “hcheck_mode” to
“60” and “nonactive” respectively for a path failure to be detected automatically.

· Setting the related attributes
Here is the command to be run as padmin for setting the above attributes:
$ chdev -l hdisk# -a hcheck_interval=60 -P
The VIO AIX client needs to be rebooted for hcheck_interval attribute to take
effect.

· EMC for Storage
In case of using EMC device as the storage device attached to VIO server,
then make sure of the following:
1. Powerpath version 4.4. is installed on the VIO servers.
2. Create hdiskpower devices which are shared between both the VIO
servers.

· Additional Information
Another thing to take note of is that you cannot have the same name for
Virtual SCSI Server Adapter and Virtual Target Device. The mkvdev command
will error out if the same name for both is used.
$ mkvdev -vdev hdiskpower0 -vadapter vhost0 -dev hdiskpower0
Method error (/usr/lib/methods/define -g -d):
0514-013 Logical name is required.
The reserve attribute is named differently for an EMC device than the attribute
for ESS or FasTt storage device. It is “reserve_lock”.
Run the following command as padmin for checking the value of the
attribute.
$ lsdev -dev hdiskpower# -attr reserve_lock
Run the following command as padmin for changing the value of the attribute.
$ chdev -dev hdiskpower# -attr reserve_lock=no

· Commands to change the Fibre Channel Adapter attributes
And also change the following attributes of the fscsi#, fc_err_recov to “fast_fail”
and dyntrk to “yes”
$ chdev -dev fscsi# -attr fc_err_recov=fast_fail -attr dyntrk=yes –perm
The reason for changing the fc_err_recov to “fast_fail” is that if the Fibre
Channel adapter driver detects a link event such as a lost link between a storage
device and a switch, then any new I/O or future retries of the failed I/Os will be
failed immediately by the adapter until the adapter driver detects that the device
has rejoined the fabric. The default setting for this attribute is 'delayed_fail’.
Setting the dyntrk attribute to “yes” makes AIX tolerate cabling changes in the
SAN.
The VIOS needs to be rebooted for fscsi# attributes to take effect.

fork() failed: Resource temporarily unavailabl

2010-09-17T14:58:00.000+05:30

Resource temporarily unavailable

If the installation fails with the following error message on the console:

fork() failed: Resource temporarily unavailable

The value of maximum number of processes allowed per user may not be large enough. This kernel attribute is a tunable and can be changed on any node of the cluster.

To determine the current value of "Maximum number of PROCESSES allowed per user", enter:

# lsattr -H -E -l sys0 -a maxuproc

To see the default value of this tunable and its valid range of values, enter:

# odmget -q "attribute=maxuproc" PdAt

If necessary, you can change the value of the tunable using the smitty interface:

# smitty chgsys

You can also directly change the CuAt class using the following command:

# chdev -l sys0 -a maxuproc=600

Increasing the value of the parameter takes effect immediately; otherwise the change takes effect after a reboot.

See the smitty and chdev manual pages.

UNIX Basics , Genral unix must know

2010-08-03T17:33:00.000+05:30

UNIX Introduction

What is UNIX?

UNIX is an operating system which was first developed in the 1960s, and has been under constant development ever since. By operating system, we mean the suite of programs which make the computer work. It is a stable, multi-user, multi-tasking system for servers, desktops and laptops.

UNIX systems also have a graphical user interface (GUI) similar to Microsoft Windows which provides an easy to use environment. However, knowledge of UNIX is required for operations which aren't covered by a graphical program, or for when there is no windows interface available, for example, in a telnet session.

Types of UNIX

There are many different versions of UNIX, although they share common similarities. The most popular varieties of UNIX are Sun Solaris, GNU/Linux, and MacOS X.

Here in the School, we use Solaris on our servers and workstations, and Fedora Linux on the servers and desktop PCs.

The UNIX operating system

The UNIX operating system is made up of three parts; the kernel, the shell and the programs.

The kernel

The kernel of UNIX is the hub of the operating system: it allocates time and memory to programs and handles the filestore and communications in response to system calls.

As an illustration of the way that the shell and the kernel work together, suppose a user types rm myfile (which has the effect of removing the file myfile). The shell searches the filestore for the file containing the program rm, and then requests the kernel, through system calls, to execute the program rm on myfile. When the process rm myfile has finished running, the shell then returns the UNIX prompt % to the user, indicating that it is waiting for further commands.

The shell

The shell acts as an interface between the user and the kernel. When a user logs in, the login program checks the username and password, and then starts another program called the shell. The shell is a command line interpreter (CLI). It interprets the commands the user types in and arranges for them to be carried out. The commands are themselves programs: when they terminate, the shell gives the user another prompt (% on our systems).

The adept user can customise his/her own shell, and users can use different shells on the same machine. Staff and students in the school have the tcsh shell by default.

The tcsh shell has certain features to help the user inputting commands.

Filename Completion - By typing part of the name of a command, filename or directory and pressing the [Tab] key, the tcsh shell will complete the rest of the name automatically. If the shell finds more than one name beginning with those letters you have typed, it will beep, prompting you to type a few more letters before pressing the tab key again.

History - The shell keeps a list of the commands you have typed in. If you need to repeat a command, use the cursor keys to scroll up and down the list or type history for a list of previous commands.

Files and processes

Everything in UNIX is either a file or a process.

A process is an executing program identified by a unique PID (process identifier).

A file is a collection of data. They are created by users using text editors, running compilers etc.

Examples of files:

· a document (report, essay etc.)

· the text of a program written in some high-level programming language

· instructions comprehensible directly to the machine and incomprehensible to a casual user, for example, a collection of binary digits (an executable or binary file);

· a directory, containing information about its contents, which may be a mixture of other directories (subdirectories) and ordinary files.

The Directory Structure

All the files are grouped together in the directory structure. The file-system is arranged in a hierarchical structure, like an inverted tree. The top of the hierarchy is traditionally called root (written as a slash / )

In the diagram above, we see that the home directory of the undergraduate student "ee51vn" contains two sub-directories (docs and pics) and a file called report.doc.

The full path to the file report.doc is "/home/its/ug1/ee51vn/report.doc"

Starting an UNIX terminal

To open an UNIX terminal window, click on the "Terminal" icon from Applications/Accessories menus.

An UNIX Terminal window will then appear with a % prompt, waiting for you to start entering commands.

1.1 Listing files and directories

ls (list)

When you first login, your current working directory is your home directory. Your home directory has the same name as your user-name, for example, ee91ab, and it is where your personal files and subdirectories are saved.

To find out what is in your home directory, type

% ls

The ls command ( lowercase L and lowercase S ) lists the contents of your current working directory.

There may be no files visible in your home directory, in which case, the UNIX prompt will be returned. Alternatively, there may already be some files inserted by the System Administrator when your account was created.

ls does not, in fact, cause all the files in your home directory to be listed, but only those ones whose name does not begin with a dot (.) Files beginning with a dot (.) are known as hidden files and usually contain important program configuration information. They are hidden because you should not change them unless you are very familiar with UNIX!!!

To list all files in your home directory including those whose names begin with a dot, type

% ls -a

As you can see, ls -a lists files that are normally hidden.

ls is an example of a command which can take options: -a is an example of an option. The options change the behaviour of the command. There are online manual pages that tell you which options a particular command can take, and how each option modifies the behaviour of the command. (See later in this tutorial)

1.2 Making Directories

mkdir (make directory)

We will now make a subdirectory in your home directory to hold the files you will be creating and using in the course of this tutorial. To make a subdirectory called unixstuff in your current working directory type

% mkdir unixstuff

To see the directory you have just created, type

% ls

1.3 Changing to a different directory

cd (change directory)

The command cd directory means change the current working directory to 'directory'. The current working directory may be thought of as the directory you are in, i.e. your current position in the file-system tree.

To change to the directory you have just made, type

% cd unixstuff

Type ls to see the contents (which should be empty)

Exercise 1a

Make another directory inside the unixstuff directory called backups

1.4 The directories . and ..

Still in the unixstuff directory, type

% ls -a

As you can see, in the unixstuff directory (and in all other directories), there are two special directories called (.) and (..)

The current directory (.)

In UNIX, (.) means the current directory, so typing

% cd .

NOTE: there is a space between cd and the dot

means stay where you are (the unixstuff directory).

This may not seem very useful at first, but using (.) as the name of the current directory will save a lot of typing, as we shall see later in the tutorial.

The parent directory (..)

(..) means the parent of the current directory, so typing

% cd ..

will take you one directory up the hierarchy (back to your home directory). Try it now.

Note: typing cd with no argument always returns you to your home directory. This is very useful if you are lost in the file system.

1.5 Pathnames

pwd (print working directory)

Pathnames enable you to work out where you are in relation to the whole file-system. For example, to find out the absolute pathname of your home-directory, type cd to get back to your home-directory and then type

% pwd

The full pathname will look something like this -

/home/its/ug1/ee51vn

which means that ee51vn (your home directory) is in the sub-directory ug1 (the group directory),which in turn is located in the its sub-directory, which is in the home sub-directory, which is in the top-level root directory called " / " .

Exercise 1b

Use the commands cd, ls and pwd to explore the file system.

(Remember, if you get lost, type cd by itself to return to your home-directory)

1.6 More about home directories and pathnames

Understanding pathnames

First type cd to get back to your home-directory, then type

% ls unixstuff

to list the conents of your unixstuff directory.

Now type

% ls backups

You will get a message like this -

backups: No such file or directory

The reason is, backups is not in your current working directory. To use a command on a file (or directory) not in the current working directory (the directory you are currently in), you must either cd to the correct directory, or specify its full pathname. To list the contents of your backups directory, you must type

% ls unixstuff/backups

~ (your home directory)

Home directories can also be referred to by the tilde ~ character. It can be used to specify paths starting at your home directory. So typing

% ls ~/unixstuff

will list the contents of your unixstuff directory, no matter where you currently are in the file system.

What do you think

% ls ~

would list?

What do you think

% ls ~/..

would list?

Summary

Command	Meaning
ls	list files and directories
ls -a	list all files and directories
mkdir	make a directory
cd directory	change to named directory
cd	change to home-directory
cd ~	change to home-directory
cd ..	change to parent directory
pwd	display the path of the current directory

2.1 Copying Files

cp (copy)

cp file1 file2 is the command which makes a copy of file1 in the current working directory and calls it file2

What we are going to do now, is to take a file stored in an open access area of the file system, and use the cp command to copy it to your unixstuff directory.

First, cd to your unixstuff directory.

% cd ~/unixstuff

Then at the UNIX prompt, type,

% cp /vol/examples/tutorial/science.txt .

Note: Don't forget the dot . at the end. Remember, in UNIX, the dot means the current directory.

The above command means copy the file science.txt to the current directory, keeping the name the same.

(Note: The directory /vol/examples/tutorial/ is an area to which everyone in the school has read and copy access. If you are from outside the University, you can grab a copy of the file here. Use 'File/Save As..' from the menu bar to save it into your unixstuff directory.)

Exercise 2a

Create a backup of your science.txt file by copying it to a file called science.bak

2.2 Moving files

mv (move)

mv file1 file2 moves (or renames) file1 to file2

To move a file from one place to another, use the mv command. This has the effect of moving rather than copying the file, so you end up with only one file rather than two.

It can also be used to rename a file, by moving the file to the same directory, but giving it a different name.

We are now going to move the file science.bak to your backup directory.

First, change directories to your unixstuff directory (can you remember how?). Then, inside the unixstuff directory, type

% mv science.bak backups/.

Type ls and ls backups to see if it has worked.

2.3 Removing files and directories

rm (remove), rmdir (remove directory)

To delete (remove) a file, use the rm command. As an example, we are going to create a copy of the science.txt file then delete it.

Inside your unixstuff directory, type

% cp science.txt tempfile.txt
% ls
% rm tempfile.txt
% ls

You can use the rmdir command to remove a directory (make sure it is empty first). Try to remove the backups directory. You will not be able to since UNIX will not let you remove a non-empty directory.

Exercise 2b

Create a directory called tempstuff using mkdir , then remove it using the rmdir command.

2.4 Displaying the contents of a file on the screen

clear (clear screen)

Before you start the next section, you may like to clear the terminal window of the previous commands so the output of the following commands can be clearly understood.

At the prompt, type

% clear

This will clear all text and leave you with the % prompt at the top of the window.

cat (concatenate)

The command cat can be used to display the contents of a file on the screen. Type:

% cat science.txt

As you can see, the file is longer than than the size of the window, so it scrolls past making it unreadable.

less

The command less writes the contents of a file onto the screen a page at a time. Type

% less science.txt

Press the [space-bar] if you want to see another page, and type [q] if you want to quit reading. As you can see, less is used in preference to cat for long files.

head

The head command writes the first ten lines of a file to the screen.

First clear the screen then type

% head science.txt

Then type

% head -5 science.txt

What difference did the -5 do to the head command?

tail

The tail command writes the last ten lines of a file to the screen.

Clear the screen and type

% tail science.txt

Q. How can you view the last 15 lines of the file?

2.5 Searching the contents of a file

Simple searching using less

Using less, you can search though a text file for a keyword (pattern). For example, to search through science.txt for the word 'science', type

% less science.txt

then, still in less, type a forward slash [/] followed by the word to search

/science

As you can see, less finds and highlights the keyword. Type [n] to search for the next occurrence of the word.

grep (don't ask why it is called grep)

grep is one of many standard UNIX utilities. It searches files for specified words or patterns. First clear the screen, then type

% grep science science.txt

As you can see, grep has printed out each line containg the word science.

Or has it ????

Try typing

% grep Science science.txt

The grep command is case sensitive; it distinguishes between Science and science.

To ignore upper/lower case distinctions, use the -i option, i.e. type

% grep -i science science.txt

To search for a phrase or pattern, you must enclose it in single quotes (the apostrophe symbol). For example to search for spinning top, type

% grep -i 'spinning top' science.txt

Some of the other options of grep are:

-v display those lines that do NOT match
-n precede each matching line with the line number
-c print only the total count of matched lines

Try some of them and see the different results. Don't forget, you can use more than one option at a time. For example, the number of lines without the words science or Science is

% grep -ivc science science.txt

wc (word count)

A handy little utility is the wc command, short for word count. To do a word count on science.txt, type

% wc -w science.txt

To find out how many lines the file has, type

% wc -l science.txt

Summary

Command	Meaning
cp file1 file2	copy file1 and call it file2
mv file1 file2	move or rename file1 to file2
rm file	remove a file
rmdir directory	remove a directory
cat file	display a file
less file	display a file a page at a time
head file	display the first few lines of a file
tail file	display the last few lines of a file
grep 'keyword' file	search a file for keywords
wc file	count number of lines/words/characters in file

3.1 Redirection

Most processes initiated by UNIX commands write to the standard output (that is, they write to the terminal screen), and many take their input from the standard input (that is, they read it from the keyboard). There is also the standard error, where processes write their error messages, by default, to the terminal screen.

We have already seen one use of the cat command to write the contents of a file to the screen.

Now type cat without specifing a file to read

% cat

Then type a few words on the keyboard and press the [Return] key.

Finally hold the [Ctrl] key down and press [d] (written as ^D for short) to end the input.

What has happened?

If you run the cat command without specifing a file to read, it reads the standard input (the keyboard), and on receiving the 'end of file' (^D), copies it to the standard output (the screen).

In UNIX, we can redirect both the input and the output of commands.

3.2 Redirecting the Output

We use the > symbol to redirect the output of a command. For example, to create a file called list1 containing a list of fruit, type

% cat > list1

Then type in the names of some fruit. Press [Return] after each one.

pear
banana
apple
^D {this means press [Ctrl] and [d] to stop}

What happens is the cat command reads the standard input (the keyboard) and the > redirects the output, which normally goes to the screen, into a file called list1

To read the contents of the file, type

% cat list1

Exercise 3a

Using the above method, create another file called list2 containing the following fruit: orange, plum, mango, grapefruit. Read the contents of list2

3.2.1 Appending to a file

The form >> appends standard output to a file. So to add more items to the file list1, type

% cat >> list1

Then type in the names of more fruit

peach
grape
orange
^D (Control D to stop)

To read the contents of the file, type

% cat list1

You should now have two files. One contains six fruit, the other contains four fruit.

We will now use the cat command to join (concatenate) list1 and list2 into a new file called biglist. Type

% cat list1 list2 > biglist

What this is doing is reading the contents of list1 and list2 in turn, then outputing the text to the file biglist

To read the contents of the new file, type

% cat biglist

3.3 Redirecting the Input

We use the < symbol to redirect the input of a command.

The command sort alphabetically or numerically sorts a list. Type

% sort

Then type in the names of some animals. Press [Return] after each one.

dog
cat
bird
ape
^D (control d to stop)

The output will be

ape
bird
cat
dog

Using < you can redirect the input to come from a file rather than the keyboard. For example, to sort the list of fruit, type

% sort < biglist

and the sorted list will be output to the screen.

To output the sorted list to a file, type,

% sort < biglist > slist

Use cat to read the contents of the file slist

3.4 Pipes

To see who is on the system with you, type

% who

One method to get a sorted list of names is to type,

% who > names.txt
% sort < names.txt

This is a bit slow and you have to remember to remove the temporary file called names when you have finished. What you really want to do is connect the output of the who command directly to the input of the sort command. This is exactly what pipes do. The symbol for a pipe is the vertical bar |

For example, typing

% who | sort

will give the same result as above, but quicker and cleaner.

To find out how many users are logged on, type

% who | wc -l

Exercise 3b

Using pipes, display all lines of list1 and list2 containing the letter 'p', and sort the result.

Answer available here

Summary

Command	Meaning
command > file	redirect standard output to a file
command >> file	append standard output to a file
command < file	redirect standard input from a file
command1 \| command2	pipe the output of command1 to the input of command2
cat file1 file2 > file0	concatenate file1 and file2 to file0
sort	sort data
who	list users currently logged in

4.1 Wildcards

The * wildcard

The character * is called a wildcard, and will match against none or more character(s) in a file (or directory) name. For example, in your unixstuff directory, type

% ls list*

This will list all files in the current directory starting with list....

Try typing

% ls *list

This will list all files in the current directory ending with ....list

The ? wildcard

The character ? will match exactly one character.
So ?ouse will match files like house and mouse, but not grouse.
Try typing

% ls ?list

4.2 Filename conventions

We should note here that a directory is merely a special type of file. So the rules and conventions for naming files apply also to directories.

In naming files, characters with special meanings such as / * & % , should be avoided. Also, avoid using spaces within names. The safest way to name a file is to use only alphanumeric characters, that is, letters and numbers, together with _ (underscore) and . (dot).

Good filenames	Bad filenames
project.txt	project
my_big_program.c	my big program.c
fred_dave.doc	fred & dave.doc

File names conventionally start with a lower-case letter, and may end with a dot followed by a group of letters indicating the contents of the file. For example, all files consisting of C code may be named with the ending .c, for example, prog1.c . Then in order to list all files containing C code in your home directory, you need only type ls *.c in that directory.

4.3 Getting Help

On-line Manuals

There are on-line manuals which gives information about most commands. The manual pages tell you which options a particular command can take, and how each option modifies the behaviour of the command. Type man command to read the manual page for a particular command.

For example, to find out more about the wc (word count) command, type

% man wc

Alternatively

% whatis wc

gives a one-line description of the command, but omits any information about options etc.

Apropos

When you are not sure of the exact name of a command,

% apropos keyword

will give you the commands with keyword in their manual page header. For example, try typing

% apropos copy

Summary

Command	Meaning
*	match any number of characters
?	match one character
man command	read the online manual page for a command
whatis command	brief description of a command
apropos keyword	match commands with keyword in their man pages

5.1 File system security (access rights)

In your unixstuff directory, type

% ls -l (l for long listing!)

You will see that you now get lots of details about the contents of your directory, similar to the example below.

Each file (and directory) has associated access rights, which may be found by typing ls -l. Also, ls -lg gives additional information as to which group owns the file (beng95 in the following example):

-rwxrw-r-- 1 ee51ab beng95 2450 Sept29 11:52 file1

In the left-hand column is a 10 symbol string consisting of the symbols d, r, w, x, -, and, occasionally, s or S. If d is present, it will be at the left hand end of the string, and indicates a directory: otherwise - will be the starting symbol of the string.

The 9 remaining symbols indicate the permissions, or access rights, and are taken as three groups of 3.

· The left group of 3 gives the file permissions for the user that owns the file (or directory) (ee51ab in the above example);

· the middle group gives the permissions for the group of people to whom the file (or directory) belongs (eebeng95 in the above example);

· the rightmost group gives the permissions for all others.

The symbols r, w, etc., have slightly different meanings depending on whether they refer to a simple file or to a directory.

Access rights on files.

· r (or -), indicates read permission (or otherwise), that is, the presence or absence of permission to read and copy the file

· w (or -), indicates write permission (or otherwise), that is, the permission (or otherwise) to change a file

· x (or -), indicates execution permission (or otherwise), that is, the permission to execute a file, where appropriate

Access rights on directories.

· r allows users to list files in the directory;

· w means that users may delete files from the directory or move files into it;

· x means the right to access files in the directory. This implies that you may read files in the directory provided you have read permission on the individual files.

So, in order to read a file, you must have execute permission on the directory containing that file, and hence on any directory containing that directory as a subdirectory, and so on, up the tree.

Some examples

-rwxrwxrwx	a file that everyone can read, write and execute (and delete).
-rw-------	a file that only the owner can read and write - no-one else can read or write and no-one has execution rights (e.g. your mailbox file).

5.2 Changing access rights

chmod (changing a file mode)

Only the owner of a file can use chmod to change the permissions of a file. The options of chmod are as follows

Symbol	Meaning
u	user
g	group
o	other
a	all
r	read
w	write (and delete)
x	execute (and access directory)
+	add permission
-	take away permission

For example, to remove read write and execute permissions on the file biglist for the group and others, type

% chmod go-rwx biglist

This will leave the other permissions unaffected.

To give read and write permissions on the file biglist to all,

% chmod a+rw biglist

Exercise 5a

Try changing access permissions on the file science.txt and on the directory backups

Use ls -l to check that the permissions have changed.

5.3 Processes and Jobs

A process is an executing program identified by a unique PID (process identifier). To see information about your processes, with their associated PID and status, type

% ps

A process may be in the foreground, in the background, or be suspended. In general the shell does not return the UNIX prompt until the current process has finished executing.

Some processes take a long time to run and hold up the terminal. Backgrounding a long process has the effect that the UNIX prompt is returned immediately, and other tasks can be carried out while the original process continues executing.

Running background processes

To background a process, type an & at the end of the command line. For example, the command sleep waits a given number of seconds before continuing. Type

% sleep 10

This will wait 10 seconds before returning the command prompt %. Until the command prompt is returned, you can do nothing except wait.

To run sleep in the background, type

% sleep 10 &

[1] 6259

The & runs the job in the background and returns the prompt straight away, allowing you do run other programs while waiting for that one to finish.

The first line in the above example is typed in by the user; the next line, indicating job number and PID, is returned by the machine. The user is be notified of a job number (numbered from 1) enclosed in square brackets, together with a PID and is notified when a background process is finished. Backgrounding is useful for jobs which will take a long time to complete.

Backgrounding a current foreground process

At the prompt, type

% sleep 1000

You can suspend the process running in the foreground by typing ^Z, i.e.hold down the [Ctrl] key and type [z]. Then to put it in the background, type

% bg

Note: do not background programs that require user interaction e.g. vi

5.4 Listing suspended and background processes

When a process is running, backgrounded or suspended, it will be entered onto a list along with a job number. To examine this list, type

% jobs

An example of a job list could be

[1] Suspended sleep 1000
[2] Running netscape
[3] Running matlab

To restart (foreground) a suspended processes, type

% fg %jobnumber

For example, to restart sleep 1000, type

% fg %1

Typing fg with no job number foregrounds the last suspended process.

5.5 Killing a process

kill (terminate or signal a process)

It is sometimes necessary to kill a process (for example, when an executing program is in an infinite loop)

To kill a job running in the foreground, type ^C (control c). For example, run

% sleep 100
^C

To kill a suspended or background process, type

% kill %jobnumber

For example, run

% sleep 100 &
% jobs

If it is job number 4, type

% kill %4

To check whether this has worked, examine the job list again to see if the process has been removed.

ps (process status)

Alternatively, processes can be killed by finding their process numbers (PIDs) and using kill PID_number

% sleep 1000 &
% ps

PID TT S TIME COMMAND
20077 pts/5 S 0:05 sleep 1000
21563 pts/5 T 0:00 netscape
21873 pts/5 S 0:25 nedit

To kill off the process sleep 1000, type

% kill 20077

and then type ps again to see if it has been removed from the list.

If a process refuses to be killed, uses the -9 option, i.e. type

% kill -9 20077

Note: It is not possible to kill off other users' processes !!!

Summary

Command	Meaning
ls -lag	list access rights for all files
chmod [options] file	change access rights for named file
command &	run command in background
^C	kill the job running in the foreground
^Z	suspend the job running in the foreground
bg	background the suspended job
jobs	list current jobs
fg %1	foreground job number 1
kill %1	kill job number 1
ps	list current processes
kill 26152	kill process number 26152

Other useful UNIX commands

quota

All students are allocated a certain amount of disk space on the file system for their personal files, usually about 100Mb. If you go over your quota, you are given 7 days to remove excess files.

To check your current quota and how much of it you have used, type

% quota -v

df

The df command reports on the space left on the file system. For example, to find out how much space is left on the fileserver, type

% df .

du

The du command outputs the number of kilobyes used by each subdirectory. Useful if you have gone over quota and you want to find out which directory has the most files. In your home-directory, type

% du -s *

The -s flag will display only a summary (total size) and the * means all files and directories.

gzip

This reduces the size of a file, thus freeing valuable disk space. For example, type

% ls -l science.txt

and note the size of the file using ls -l . Then to compress science.txt, type

% gzip science.txt

This will compress the file and place it in a file called science.txt.gz

To see the change in size, type ls -l again.

To expand the file, use the gunzip command.

% gunzip science.txt.gz

zcat

zcat will read gzipped files without needing to uncompress them first.

% zcat science.txt.gz

If the text scrolls too fast for you, pipe the output though less .

% zcat science.txt.gz | less

file

file classifies the named files according to the type of data they contain, for example ascii (text), pictures, compressed data, etc.. To report on all files in your home directory, type

% file *

diff

This command compares the contents of two files and displays the differences. Suppose you have a file called file1 and you edit some part of it and save it as file2. To see the differences type

% diff file1 file2

Lines beginning with a < denotes file1, while lines beginning with a > denotes file2.

find

This searches through the directories for files and directories with a given name, date, size, or any other attribute you care to specify. It is a simple command but with many options - you can read the manual by typing man find.

To search for all fies with the extention .txt, starting at the current directory (.) and working through all sub-directories, then printing the name of the file to the screen, type

% find . -name "*.txt" -print

To find files over 1Mb in size, and display the result as a long listing, type

% find . -size +1M -ls

history

The C shell keeps an ordered list of all the commands that you have entered. Each command is given a number according to the order it was entered.

% history (show command history list)

If you are using the C shell, you can use the exclamation character (!) to recall commands easily.

% !! (recall last command)

% !-3 (recall third most recent command)

% !5 (recall 5th command in list)

% !grep (recall last command starting with grep)

You can increase the size of the history buffer by typing

% set history=100

7.1 Compiling UNIX software packages

We have many public domain and commercial software packages installed on our systems, which are available to all users. However, students are allowed to download and install small software packages in their own home directory, software usually only useful to them personally.

There are a number of steps needed to install the software.

· Locate and download the source code (which is usually compressed)

· Unpack the source code

· Compile the code

· Install the resulting executable

· Set paths to the installation directory

Of the above steps, probably the most difficult is the compilation stage.

Compiling Source Code

All high-level language code must be converted into a form the computer understands. For example, C language source code is converted into a lower-level language called assembly language. The assembly language code made by the previous stage is then converted into object code which are fragments of code which the computer understands directly. The final stage in compiling a program involves linking the object code to code libraries which contain certain built-in functions. This final stage produces an executable program.

To do all these steps by hand is complicated and beyond the capability of the ordinary user. A number of utilities and tools have been developed for programmers and end-users to simplify these steps.

make and the Makefile

The make command allows programmers to manage large programs or groups of programs. It aids in developing large programs by keeping track of which portions of the entire program have been changed, compiling only those parts of the program which have changed since the last compile.

The make program gets its set of compile rules from a text file called Makefile which resides in the same directory as the source files. It contains information on how to compile the software, e.g. the optimisation level, whether to include debugging info in the executable. It also contains information on where to install the finished compiled binaries (executables), manual pages, data files, dependent library files, configuration files, etc.

Some packages require you to edit the Makefile by hand to set the final installation directory and any other parameters. However, many packages are now being distributed with the GNU configure utility.

configure

As the number of UNIX variants increased, it became harder to write programs which could run on all variants. Developers frequently did not have access to every system, and the characteristics of some systems changed from version to version. The GNU configure and build system simplifies the building of programs distributed as source code. All programs are built using a simple, standardised, two step process. The program builder need not install any special tools in order to build the program.

The configure shell script attempts to guess correct values for various system-dependent variables used during compilation. It uses those values to create a Makefile in each directory of the package.

The simplest way to compile a package is:

1. cd to the directory containing the package's source code.

2. Type ./configure to configure the package for your system.

3. Type make to compile the package.

4. Optionally, type make check to run any self-tests that come with the package.

5. Type make install to install the programs and any data files and documentation.

6. Optionally, type make clean to remove the program binaries and object files from the source code directory

The configure utility supports a wide variety of options. You can usually use the --help option to get a list of interesting options for a particular configure script.

The only generic options you are likely to use are the --prefix and --exec-prefix options. These options are used to specify the installation directories.

The directory named by the --prefix option will hold machine independent files such as documentation, data and configuration files.

The directory named by the --exec-prefix option, (which is normally a subdirectory of the --prefix directory), will hold machine dependent files such as executables.

7.2 Downloading source code

For this example, we will download a piece of free software that converts between different units of measurements.

First create a download directory

% mkdir download

Download the software here and save it to your new download directory.

7.3 Extracting the source code

Go into your download directory and list the contents.

% cd download
% ls -l

As you can see, the filename ends in tar.gz. The tar command turns several files and directories into one single tar file. This is then compressed using the gzip command (to create a tar.gz file).

First unzip the file using the gunzip command. This will create a .tar file.

% gunzip units-1.74.tar.gz

Then extract the contents of the tar file.

% tar -xvf units-1.74.tar

Again, list the contents of the download directory, then go to the units-1.74 sub-directory.

% cd units-1.74

7.4 Configuring and creating the Makefile

The first thing to do is carefully read the README and INSTALL text files (use the less command). These contain important information on how to compile and run the software.

The units package uses the GNU configure system to compile the source code. We will need to specify the installation directory, since the default will be the main system area which you will not have write permissions for. We need to create an install directory in your home directory.

% mkdir ~/units174

Then run the configure utility setting the installation path to this.

% ./configure --prefix=$HOME/units174

NOTE: The $HOME variable is an example of an environment variable. The value of $HOME is the path to your home directory. Just type

% echo $HOME

to show the contents of this variable. We will learn more about environment variables in a later chapter.

If configure has run correctly, it will have created a Makefile with all necessary options. You can view the Makefile if you wish (use the less command), but do not edit the contents of this.

7.5 Building the package

Now you can go ahead and build the package by running the make command.

% make

After a minute or two (depending on the speed of the computer), the executables will be created. You can check to see everything compiled successfully by typing

% make check

If everything is okay, you can now install the package.

% make install

This will install the files into the ~/units174 directory you created earlier.

7.6 Running the software

You are now ready to run the software (assuming everything worked).

% cd ~/units174

If you list the contents of the units directory, you will see a number of subdirectories.

bin	The binary executables
info	GNU info formatted documentation
man	Man pages
share	Shared data files

To run the program, change to the bin directory and type

% ./units

As an example, convert 6 feet to metres.

You have: 6 feet
You want: metres

* 1.8288

If you get the answer 1.8288, congratulations, it worked.

To view what units it can convert between, view the data file in the share directory (the list is quite comprehensive).

To read the full documentation, change into the info directory and type

% info --file=units.info

7.7 Stripping unnecessary code

When a piece of software is being developed, it is useful for the programmer to include debugging information into the resulting executable. This way, if there are problems encountered when running the executable, the programmer can load the executable into a debugging software package and track down any software bugs.

This is useful for the programmer, but unnecessary for the user. We can assume that the package, once finished and available for download has already been tested and debugged. However, when we compiled the software above, debugging information was still compiled into the final executable. Since it is unlikey that we are going to need this debugging information, we can strip it out of the final executable. One of the advantages of this is a much smaller executable, which should run slightly faster.

What we are going to do is look at the before and after size of the binary file. First change into the bin directory of the units installation directory.

% cd ~/units174/bin
% ls -l

As you can see, the file is over 100 kbytes in size. You can get more information on the type of file by using the file command.

% file units

units: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped

To strip all the debug and line numbering information out of the binary file, use the strip command

% strip units
% ls -l

As you can see, the file is now 36 kbytes - a third of its original size. Two thirds of the binary file was debug code!!!

Check the file information again.

% file units

units: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), stripped

Sometimes you can use the make command to install pre-stripped copies of all the binary files when you install the package. Instead of typing make install, simply type make install-strip

8.1 UNIX Variables

Variables are a way of passing information from the shell to programs when you run them. Programs look "in the environment" for particular variables and if they are found will use the values stored. Some are set by the system, others by you, yet others by the shell, or any program that loads another program.

Standard UNIX variables are split into two categories, environment variables and shell variables. In broad terms, shell variables apply only to the current instance of the shell and are used to set short-term working conditions; environment variables have a farther reaching significance, and those set at login are valid for the duration of the session. By convention, environment variables have UPPER CASE and shell variables have lower case names.

8.2 Environment Variables

An example of an environment variable is the OSTYPE variable. The value of this is the current operating system you are using. Type

% echo $OSTYPE

More examples of environment variables are

· USER (your login name)

· HOME (the path name of your home directory)

· HOST (the name of the computer you are using)

· ARCH (the architecture of the computers processor)

· DISPLAY (the name of the computer screen to display X windows)

· PRINTER (the default printer to send print jobs)

· PATH (the directories the shell should search to find a command)

Finding out the current values of these variables.

ENVIRONMENT variables are set using the setenv command, displayed using the printenv or env commands, and unset using the unsetenv command.

To show all values of these variables, type

% printenv | less

8.3 Shell Variables

An example of a shell variable is the history variable. The value of this is how many shell commands to save, allow the user to scroll back through all the commands they have previously entered. Type

% echo $history

More examples of shell variables are

· cwd (your current working directory)

· home (the path name of your home directory)

· path (the directories the shell should search to find a command)

· prompt (the text string used to prompt for interactive commands shell your login shell)

Finding out the current values of these variables.

SHELL variables are both set and displayed using the set command. They can be unset by using the unset command.

To show all values of these variables, type

% set | less

So what is the difference between PATH and path ?

In general, environment and shell variables that have the same name (apart from the case) are distinct and independent, except for possibly having the same initial values. There are, however, exceptions.

Each time the shell variables home, user and term are changed, the corresponding environment variables HOME, USER and TERM receive the same values. However, altering the environment variables has no effect on the corresponding shell variables.

PATH and path specify directories to search for commands and programs. Both variables always represent the same directory list, and altering either automatically causes the other to be changed.

8.4 Using and setting variables

Each time you login to a UNIX host, the system looks in your home directory for initialisation files. Information in these files is used to set up your working environment. The C and TC shells uses two files called .login and .cshrc (note that both file names begin with a dot).

At login the C shell first reads .cshrc followed by .login

.login is to set conditions which will apply to the whole session and to perform actions that are relevant only at login.

.cshrc is used to set conditions and perform actions specific to the shell and to each invocation of it.

The guidelines are to set ENVIRONMENT variables in the .login file and SHELL variables in the .cshrc file.

WARNING: NEVER put commands that run graphical displays (e.g. a web browser) in your .cshrc or .login file.

8.5 Setting shell variables in the .cshrc file

For example, to change the number of shell commands saved in the history list, you need to set the shell variable history. It is set to 100 by default, but you can increase this if you wish.

% set history = 200

Check this has worked by typing

% echo $history

However, this has only set the variable for the lifetime of the current shell. If you open a new xterm window, it will only have the default history value set. To PERMANENTLY set the value of history, you will need to add the set command to the .cshrc file.

First open the .cshrc file in a text editor. An easy, user-friendly editor to use is nedit.

% nedit ~/.cshrc

Add the following line AFTER the list of other commands.

set history = 200

Save the file and force the shell to reread its .cshrc file buy using the shell source command.

% source .cshrc

Check this has worked by typing

% echo $history

8.6 Setting the path

When you type a command, your path (or PATH) variable defines in which directories the shell will look to find the command you typed. If the system returns a message saying "command: Command not found", this indicates that either the command doesn't exist at all on the system or it is simply not in your path.

For example, to run units, you either need to directly specify the units path (~/units174/bin/units), or you need to have the directory ~/units174/bin in your path.

You can add it to the end of your existing path (the $path represents this) by issuing the command:

% set path = ($path ~/units174/bin)

Test that this worked by trying to run units in any directory other that where units is actually located.

% cd
% units

To add this path PERMANENTLY, add the following line to your .cshrc AFTER the list of other commands.

set path = ($path ~/units174/bin)

Script to copy the files under directory and subdirectories

2010-04-14T14:50:00.003+05:30

Here is a script to copy the files from source path directory's and sub directory's to specified destination directory.

#!/usr/bin/perl -w
my $srcpath='';
my $destpath='';

system("chmod 755 $destpath");
system("chmod 755 $srcpath");

copydir($srcpath);

sub copydir
{
my $Path = shift(@_);

print "\n My Path : $Path";
my @arry1=`ls $Path`;
foreach $a ( @arry1 )
{
    chomp($a);
   print "\n My File : $a";
     if(-d "$Path/$a")
     {
       $Path1="$Path/$a";
      print "\nFrom IF : $Path1";
       copydir( $Path1 );
     }

     else
     {
      print "\n IT IS A FILE";
      system("cp -p $Path/$a $destpath");
     }
}
}
Number of Hits :

Virtualization and dynamic infrastructure

2010-03-30T20:59:00.009+05:30

Virtualization and dynamic infrastructure

-----Most demanding technology

CONTENTS

Abstract ………………………………………….……………………………………………………….3

Introduction ..………………………………….……………………………………………………….4

Popular virtualization products ……….….……………………………………………………..5

Virtualization Advantages …..………….………………………………………………………….5

Important terminology ………..……….……………………………………………………………5

When to use Virtualization ………………………………………………………………………..7

What are the cost benefits of virtualization ….……………………………………………….8

Virtualization for a dynamic infrastructure …………………………………………………9

Dynamic Infrastructure: The Cloud …………….…………………………………………...11

Conclusion ……………………………………………………..………………………………………….15

References ……………………………………………………….………………………………………..16

Abstract

Virtualization is a method of running multiple independent virtual operating systems on a single physical computer. It is a way of maximizing physical resources to minimize the investment in hardware. Virtualization refers to technologies designed to provide a layer of abstraction between computer hardware systems and the software running on them. By providing a logical view of computing resources, rather than a physical view, virtualization solutions make it possible to do a couple of very useful things: They can allow you, essentially, to trick your operating systems into thinking that a group of servers is a single pool of computing resources. And they can allow you to run multiple operating systems simultaneously on a single machine. By making the infrastructure much more flexible, virtualization can enable IT resources to be allocated faster, more cost effectively and more dynamically – and help you respond to the challenges of changing demand levels and new business requirements. Virtualization is the perfect solution for applications that are meant for small- to medium-scale usage. Virtualization should not be used for high-performance applications where one or more servers need to be clustered together to meet performance requirements of a single application because the added overhead and complexity would only reduce performance.

Your Ad Here

Introduction

What is Virtualization?

Virtualization is software technology which uses a physical resource such as a server and divides it up into virtual resources called virtual machines (VM's). Virtualization allows users to consolidate physical resources, simplify deployment and administration, and reduce power and cooling requirements. While virtualization technology is most popular in the server world, virtualization technology is also being used in data storage such as Storage Area Networks, and inside of operating systems such as Windows Server 2008 with Hyper-V.

Virtualization is a method of running multiple independent virtual operating systems on a single physical computer. It is a way of maximizing physical resources to minimize the investment in hardware. Since Moore's law has accurately predicted the exponential growth of computing power and hardware requirements for the most part have not changed to accomplish the same computing tasks, it is now feasible to turn a very inexpensive 1U dual-socket dual-core commodity server into eight or even 16 virtual servers that run 16 virtual operating systems. Virtualization technology is a way of achieving higher server density. However, it does not actually increase total computing power; it decreases it slightly because of overhead. But since a modern $3,000 2-socket 4-core server is more powerful than a $30,000 8-socket 8-core server was four years ago, we can exploit this newly found hardware power by increasing the number of logical operating systems it hosts. This slashes the majority of hardware acquisition and maintenance costs that can result in significant savings for any company or organization.

Virtualization refers to technologies designed to provide a layer of abstraction between computer hardware systems and the software running on them. By providing a logical view of computing resources, rather than a physical view, virtualization solutions make it possible to do a couple of very useful things: They can allow you, essentially, to trick your operating systems into thinking that a group of servers is a single pool of computing resources. And they can allow you to run multiple operating systems simultaneously on a single machine.
Virtualization has its roots in partitioning, which divides a single physical server into multiple logical servers. Once the physical server is divided, each logical server can run an operating system and applications independently. In the 1990s, virtualization was used primarily to re-create end-user environments on a single piece of mainframe hardware. If you were an IT administrator and you wanted to roll out new software, but you wanted see how it would work on a Windows NT or a Linux machine, you used virtualization technologies to create the various user environments.
But with the advent of the x86 architecture and inexpensive PCs, virtualization faded and seemed to be little more than a fad of the mainframe era. It's fair to credit the recent rebirth of virtualization on x86 to the founders of the current market leader, VMware. VMware developed the first hypervisor for the x86 architecture in the 1990s, planting the seeds for the current virtualization boom.

Popular virtualization products include:

VMware
IBM HMC, LPARS ,VIOS,DLPARS
Microsoft Hyper-V
Virtual Iron
Xen

Virtualization Advantages:

Server consolidation
Reduced power and cooling
Green computing
Ease of deployment and administration
High availability and disaster recovery

Important terminology

What is a hypervisor?
The hypervisor is the most basic virtualization component. It's the software that decouples the operating system and applications from their physical resources. A hypervisor has its own kernel and it's installed directly on the hardware, or "bare metal." It is, almost literally, inserted between the hardware and the OS.
What is a virtual machine?
A virtual machine (VM) is a self-contained operating environment—software that works with, but is independent of, a host operating system. In other words, it's a platform-independent software implementation of a CPU that runs compiled code. A Java virtual machine, for example, will run any Java-based program (more or less). The VMs must be written specifically for the OSes on which they run. Virtualization technologies are sometimes called dynamic virtual machine software.
What is paravirtualization?
Paravirtualization is a type of virtualization in which the entire OS runs on top of the hypervisor and communicates with it directly, typically resulting in better performance. The kernels of both the OS and the hypervisor must be modified, however, to accommodate this close interaction. A paravirtualized Linux operating system, for example, is specifically optimized to run in a virtual environment. Full virtualization, in contrast, presents an abstract layer that intercepts all calls to physical resources.
Paravirtualization relies on a virtualized subset of the x86 architecture. Recent chip enhancement developments by both Intel and AMD are helping to support virtualization schemes that do not require modified operating systems. Intel's "Vanderpool" chip-level virtualization technology was one of the first of these innovations. AMD's "Pacifica" extension provides additional virtualization support. Both are designed to allow simpler virtualization code, and the potential for better performance of fully virtualized environments.
What is application virtualization?
Virtualization in the application layer isolates software programs from the hardware and the OS, essentially encapsulating them as independent, moveable objects that can be relocated without disturbing other systems. Application virtualization technologies minimize app-related alterations to the OS, and mitigate compatibility challenges with other programs.
What is a virtual appliance?
A virtual appliance (VA) is not, as its name suggests, a piece of hardware. It is, rather, a prebuilt, preconfigured application bundled with an operating system inside a virtual machine. The VA is a software distribution vehicle, touted by VMware and others, as a better way of installing and configuring software. The VA targets the virtualization layer, so it needs a destination with a hypervisor. VMware and others are touting the VA as a better way to package software demonstrations, proof-of-concept projects and evaluations.
What is Xen?
The Xen Project has developed and continues to evolve a free, open-source hypervisor for x86. Available since 2003 under the GNU General Public License, Xen runs on a host operating system, and so is considered paravirtualization technology. The project originated as a research project at the University of Cambridge led by Ian Pratt, who later left the school to found XenSource, the first company to implement a commercial version of the Xen hypervisor. A number of large enterprise companies now support Xen, including Microsoft, Novell and IBM. XenSource (not surprisingly) and SAP-based startup Virtual Iron offer Xen-based virtualization solutions.

When to use Virtualization

Virtualization is the perfect solution for applications that are meant for small- to medium-scale usage. Virtualization should not be used for high-performance applications where one or more servers need to be clustered together to meet performance requirements of a single application because the added overhead and complexity would only reduce performance. We're essentially taking a 12 GHz server (four cores times three GHz) and chopping it up into 16 750 MHz servers. But if eight of those servers are in off-peak or idle mode, the remaining eight servers will have nearly 1.5 GHz available to them.

While some in the virtualization industry like to tout high CPU utilization numbers as an indication of optimum hardware usage, this advice should not be taken to the extreme where application responsiveness gets excessive. A simple rule of thumb is to never let a server exceed 50% CPU utilization during peak loads; and more importantly, never let the application response times exceed a reasonable SLA (Service Level Agreement). Most modern servers being used for in-house server duties are utilized from 1 to 5% CPU. Running eight operating systems on a single physical server would elevate the peak CPU utilization to around 50%, but it would average much lower since the peaks and valleys of the virtual operating systems will tend to cancel each other out more or less.

While CPU overhead in most of the virtualization solutions available today are minimal, I/O (Input/Output) overhead for storage and networking throughput is another story. For servers with extremely high storage or hardware I/O requirements, it would be wise to run them on bare metal even if their CPU requirements can be met inside a Virtual environment. Both Xen source and Virtual Iron (which will soon be Xen Hypervisor based) promise to minimize I/O overhead, yet they're both in beta at this point, so there haven't been any major independent benchmarks to verify this.

Server consolidation is definitely the sweet spot in this market. Virtualization has become the cornerstone of every enterprise's favorite money-saving initiative. Industry analysts report that between 60 percent and 80 percent of IT departments are pursuing server consolidation projects. It's easy to see why: By reducing the numbers and types of servers that support their business applications, companies are looking at significant cost savings.
Less power consumption, both from the servers themselves and the facilities' cooling systems, and fuller use of existing, underutilized computing resources translate into a longer life for the data center and a fatter bottom line. And a smaller server footprint is simpler to manage.
However, industry watchers report that most companies begin their exploration of virtualization through application testing and development. Virtualization has quickly evolved from a neat trick for running extra operating systems into a mainstream tool for software developers. Rarely are applications created today for a single operating system; virtualization allows developers working on a single workstation to write code that runs in many different environments, and perhaps more importantly, to test that code. This is a noncritical environment, generally speaking, and so it's an ideal place to kick the tires.
Once application development is happy, and the server farm is turned into a seamless pool of computing resources, storage and network consolidation start to move up the to-do list. Other virtualization-enabled features and capabilities worth considering: high availability, disaster recovery and workload balancing.

What are the cost benefits of virtualization?

IT departments everywhere are being asked to do more with less, and the name of the game today is resource utilization. Virtualization technologies offer a direct and readily quantifiable means of achieving that mandate by collecting disparate computing resources into shareable pools.
For example, analysts estimate that the average enterprise utilizes somewhere between 5 percent and 25 percent of its server capacity. In those companies, most of the power consumed by their hardware is just heating the room in idle cycles. Employing virtualization technology to consolidate underutilized x86 servers in the data center yields both an immediate, one-time cost saving and potentially significant ongoing savings.
The most obvious immediate impact here comes from a reduction in the number of servers in the data center. Fewer machines means less daily power consumption, both from the servers themselves and the cooling systems that companies must operate and maintain to keep them from overheating.
Turning a swarm of servers into a seamless computing pool can also lessen the scope of future hardware expenditures, while putting the economies of things like utility pricing models and pay-per-use plans on the table. Moreover, a server virtualization strategy can open up valuable rack space, giving a company room to grow.
From a human resources standpoint, a sleeker server farm makes it possible to improve the deployment of administrators.

Virtualization for a dynamic infrastructure

Virtualization is a key building block of a dynamic infrastructure.

By making the infrastructure much more flexible, virtualization can enable IT resources to be allocated faster, more cost effectively and more dynamically – and help you respond to the challenges of changing demand levels and new business requirements.

To achieve the best outcome, organizations are virtualizing at all layers of the architecture, from servers to desktops, storage, networks, and applications – while also adopting new methods of automation and service management -- to help reduce cost, improve service and manage risk.

An increasing number of enterprises are turning to a dynamic infrastructure, which is designed to be service-oriented and focused on supporting and enabling end users in a highly responsive way. The transformation can't happen overnight, but a number of technologies can come together to make it possible.
In almost every case, the transformation to a dynamic infrastructure will involve virtualization. Many IT professionals think of virtualization specifically in terms of servers. Dynamic infrastructure has a broader perspective, in which virtualization is seen as a general approach to decouple logical resources from physical elements, so those resources can be allocated faster, more cost effectively, and more dynamically—wherever the business requires them in real time to ideally meet changing demand levels or business requirements.
Virtualization helps to make the infrastructure dynamic. By moving to virtualized solutions, an organization can expect substantial benefits for both IT and the business.
On the IT side, costs will fall; this commonly occurs via enhanced resource utilization, recaptured floor space in data centers, and improved energy efficiency. Service levels will climb; the performance and scalability of existing services will both be boosted, and new services can be developed and rolled out much more quickly. Risks, too, will be mitigated, because the uptime and availability of mission-critical and revenue-generating systems, applications, and services will generally improve with virtualization.
On the business side, virtualization can create a foundation for growth. When new strategies are suggested by changing market conditions, they will be easier to create and deploy via a virtualized, dynamic infrastructure. Actionable business intelligence is acquired faster through real-time processing, helping to quantify the extent of any given strategy's success (or failure). With the appropriate management operations and systems control are consolidated, spurring time-to-solution, and should there be redundancy within the infrastructure or staffing, it is more easily identified and resolved as a result. Finally, employee productivity will typically climb with the improved management infrastructure.
Virtual servers are the best-known example of virtual solutions. They translate into many powerful business benefits, including reduced server sprawl through consolidation, reduced energy consumption, dramatically higher hardware utilization, greater flexibility in assigning processing power to IT services when they require it, and higher service availability.
However, that virtualization as a key element of the dynamic infrastructure can and should involve many other virtualized elements in addition to servers; in fact, best results will often come as additional areas of the infrastructure are virtualized
Virtual storage allows the organization to approach storage not as a fixed element tied to specific hardware, but as a fluid resource that can be allocated to any application or service that requires it, in real time. Databases in which new records are continually being created can grow in proportion to the business need without regard for the size of the hard drives on the systems hosting them. Data can be moved seamlessly to and from various tiers of storage to better align data's value with its cost.
When applications, systems, and services continually have access to the storage they require, overall IT availability, productivity, and service levels will climb, helping to maximize the return on investment of all the elements that use storage. Virtual storage also enables centralized management of storage resources from a single point of control, reducing management costs.
Virtual clients can directly address the problem of desktop sprawl. Desktops with a complete operating system and application stack translate into a substantial and expensive burden on IT teams. In particular, mass rollouts such as new applications or operating system versions can require months to finish, creating a substantial business impact.
Virtual ("thin") clients represent an attractive alternative. Thin clients are essentially identical from unit to unit; end user data and applications are migrated to shared servers and then accessed by users over the network using the thin clients. End user resources can be centrally managed by IT in an elegant, accelerated fashion, substantially reducing both desktop sprawl and all of its associated costs.
A virtual application infrastructure can also deliver powerful benefits. Imagine an organization in which many key services are supported by core Java applications operating on server clusters. Now imagine that an unexpected spike in demand requires higher performance from one of those applications, while the others remain comparatively idle. By virtualizing the application infrastructure, application workloads can be dynamically assigned across clusters, ensuring that such spikes are quickly and effectively addressed via more processing power whenever and wherever it's required.
Virtual networks can also play a major role in helping an infrastructure to become more dynamic. A single physical network node can be virtualized into several virtual nodes in order to increase network capacity. Multiple physical switches can be logically consolidated into one virtual switch in order to reduce complexity and ease management costs. Virtual private networks deliver similar security and performance to remote users as private physical networks would, yet at a far lower cost. Even network adapters can be virtualized, helping to decrease the number of physical assets in play throughout the infrastructure.
Not able to FTP as Root

Dynamic Infrastructure: The Cloud

Cloud computing is a general term for anything that involves delivering hosted services over the Internet. About cloud computing as a utility -- much like electrical & water utility services where you pay only for the computing and storage that you use, as opposed to paying the overhead of creating & maintaining your own data center.

As learned from past events, computing in its purest form, has changed hands multiple times. First from near the beginning when mainframes were predicted to be the future of computing. Indeed mainframes and large scale machines were built and used, and in some circumstances are used similarly today. The trend, however, turned from bigger and more expensive, to smaller and more affordable commodity PCs and servers.
Most of our data is stored on local networks with servers that may be clustered and sharing storage. This approach has had time to be developed into stable architecture, and provide decent redundancy when deployed right. A newer emerging technology, cloud computing, has shown up demanding attention and quickly is changing the direction of the technology landscape. Whether it is Google’s unique and scalable Google File System, or Amazon’s robust Amazon S3 cloud storage model, it is clear that cloud computing has arrived with much to be gleaned from.
In dealing with the abstract term, “the cloud”, it is easy to misunderstand what makes up the structure and function. The basic function is what comes from “the cloud”. This is primarily output, however, not only. Input is what makes the cloud tick.
Do not confuse cloud computing with the term data center, as it typically sits on top of the latter. Viewing the cloud as logical rather than a physical

These services are broadly divided into

SaaS: Software as a Service
PaaS: Platform as a Service
DaaS: Data as a Service
HaaS: Hardware as a Service
IaaS: Infrastructure as a Service
XaaS: X as a Service, for whatever X

Everyone has an opinion on what is cloud computing. It can be the ability to rent a server or a thousand servers and run a geophysical modeling application on the most powerful systems available anywhere. It can be the ability to rent a virtual server, load software on it, turn it on and off at will, or clone it ten times to meet a sudden workload demand. It can be storing and securing immense amounts of data that is accessible only by authorized applications and users. It can be supported by a cloud provider that sets up a platform that includes the OS, Apache, a MySQL™ database,Perl, Python, and PHP with the ability to scale automatically in response to changing workloads. Cloud computing can be the ability to use applications on the Internet that store and protect data while providing a service — anything including email,sales force automation and tax preparation. It can be using a storage cloud to hold application, business, and personal data. And it can be the ability to use a handful ofWeb services to integrate photos, maps, and GPS information to create a mashup in customer Web browsers.

The biggest challenge in cloud computing may be the fact that there's no standard or single architectural method. In fact, there are few definitions of the cloud computing concept that are fully accepted. Therefore, it's best to view cloud architectures as a set of approaches, each with its own examples and capabilities.

A cloud computing system is a set of IT resources designed to be allocated ad hoc to run applications, rather than be assigned a static set of applications as is the case in client/server computing. In a cloud computing environment, a user (via a virtual desktop, for example) requests information from an application. The cloud computing environment must then broker resources to run that application.

Virtualization is the key element in any form of application or resource brokering. To understand why, look at the process from the virtual desktop perspective:

What’s hidden in the cloud?

Inside the “cloud within the cloud” there are a great number of pieces of infrastructure working together. Obviously there are the core networking components: routers, switches, DNS, and DHCP, without which connectivity would be impossible.

Moving up the stack we find load balancing and application delivery infrastructure; the core application networking components that enable the dynamism promised by virtualized environments to be achieved. Without a layer of infrastructure bridging the gap between the network and the applications, virtualized or not, it is difficult to achieve the kind of elasticity and dynamism necessary for the cloud to “just work” for end users.
It is the application networking layer that is responsible for ensuring availability, proper routing of requests, and applying application level policies such as security and acceleration. This layer must be dynamic, because the actual virtualized layers of web and application servers are themselves dynamic. Application instances may move from IP to IP across hours or days, and it is necessary for the application networking layer to be able to adapt to that change without requiring manual intervention in the form of configuration modification.
Storage virtualization, too, resides in this layer of the infrastructure. Storage virtualization provides enables a dynamic infrastructure by presenting a unified view of storage to the applications and internal infrastructure, ensuring that the application need not be modified in order to access file-based resources. Storage virtualization can further be the means through which cloud control mechanisms manage the myriad virtual images required to support a cloud computing infrastructure.
The role of the application networking layer is to mediate, or broker, between clients and the actual applications to ensure a seamless access experience regardless of where the actual application instance might be running at any given time. It is the application networking layer that provides network and server virtualization such that the actual implementation of the cloud is hidden from external constituents. Much like storage virtualization, application networking layers present a “virtual” view of the applications and resources requiring external access.
This is why dynamism is such an integral component of a cloud computing infrastructure: the application networking layer must, necessarily, keep tabs on application instances and be able to associate them with the appropriate “virtual” application it presents to external users. Classic load balancing solutions are incapable of such dynamic, near real-time reconfiguration and discovery and almost always require manual intervention.
Dynamic application networking infrastructure is not only capable but excels at this type of autonomous function, integrating with the systems necessary to enable awareness of changes within the application infrastructure and act upon them.
The “cloud within the cloud” need only be visible to implementers; but as we move forward and more organizations attempt to act on a localized cloud computing strategy it becomes necessary to peer inside the cloud and understand how the disparate pieces of technology combine. This visibility is a requirement if organizations are to achieve the goals desired through the implementation of a cloud computing-based architecture: efficiency and scalability.

Conclusion

Virtualization enables a more agile infrastructure by decoupling the application stack from the underlying hardware and operating system. This much-adopted architecture enables IT leaders to drive efficient task automation within and across "IT silos" and drive tighter process standardization across teams. Virtualization provides encapsulated automation opportunities that IT must take advantage of to drive higher ROI and more effective and efficient delivery of IT services. Increasingly, IT organizations that virtualize a higher percentage of their application workloads must

utilize automation capabilities as the demand for higher-quality services outpaces hiring practices. To accelerate automation’s impact on increasing staff utilization, IT should adopt process standardization. By using automation along with virtualization, IT has an incredible opportunity to provide highly cost-effective service delivery while gaining flexibility in the ability to meet ongoing business needs.

References

- www-03.ibm.com/

- www.redbooks.ibm.com

- www.vmware.com/

- www.sun.com/solutions/virtualization/

Number of Hits :

AIX Network Installation Manager ( NIM ) - PART1

2010-03-24T09:54:00.002+05:30

NIM installation Filesets

You will need Volume 1 of your Base AIX Installation media CD. If you have a directory where you’ve used the bffcreate utility to copy down the contents of the media to disk, that is fine as well. What we’re looking for basically is the base level versions of the NIM filesets.
There are 3 filesets we will need to deliver the NIM software to our future NIM master.

1. bos.sysmgt.nim.master

2. bos.sysmgt.nim.client

3. bos.sysmgt.nim.spot

Put Volume 1 of your media in the drive and from and command line you can run the following command :
# installp -acgXd /dev/cd0 bos.sysmgt.nim.master bos.sysmgt.nim.client bos.sysmgt.nim.spot

Using smitty :
# smitty install_all
* INPUT device / directory for software /dev/cd0
* SOFTWARE to install
PREVIEW only? (install operation will NOT occur) no
COMMIT software updates? yes
SAVE replaced files? no
AUTOMATICALLY install requisite software? yes
EXTEND file systems if space needed? yes
OVERWRITE same or newer versions? no
VERIFY install and check file sizes? no
DETAILED output? no
Process multiple volumes? yes
ACCEPT new license agreements? no
Preview new LICENSE agreements? no

NIM Key Components

If you are unfamiliar with NIM I highly recommend reading through this section and also use it as a reference while reading through this guide. If you’re figuring, “eh he’ll explain all this later so I’ll just skip this part,” you’re going to be flipping back to this part all mad later thinking, “ok fine so I should have read through this before....”.

So this is sort of like a “reverse-glossary”. I have it before any of the “How to” portions of the guide because it is important to know what it is we are talking about. I’ll give the best and easiest to understand description of these terms so that you’ll hopefully have a much easier time understanding any new concepts you’re unfamiliar with. In all cases - actually using the files/keywords are handled in greater detail in their corresponding “How To...” sections.

Important Files and Directories:

- /etc/bootptab :
This file will exist on the NIM master. In a quiet NIM environment with no operations that require a client to boot, this file will be empty (except for the pre-existing commented section). This file gets updated automatically by the NIM master when a NIM operation is executed that requires the client machine to boot from a NIM SPOT. If this file contains incorrect information about either the master or the client, the boot operation will fail. While this file “can” be edited manually to fix a bootp issue - it should not be, as you are only applying a “band-aid” fix to an existing issue in your NIM environment....but, sometimes it’s 5pm on a Friday and you’re ready to go home, right ?
(Also note related entry ‘bootp’)

- /etc/exports :
This is not a “NIM specific” file, it is a NIM critical file. Any sort of installation, boot, mksysb, savevg....etc operation requires the use of NFS. This file will be updated with which locations are NFS exported from the master to the client and the permissions associated with those exports. If these entries are incorrect or incomplete you will run into boot failures, permission problems, and other errors commonly associated with NFS. This is a text file and also “can” be edited manually to sometimes “band-aid” a problem, but should only be done so with care in knowing exactly what you’re doing. The good thing is, if we mess up this file we can remove it and recycle NFS. The file can be recreated.

- /etc/hosts :
While not a “NIM specific” file, it is also a NIM critical file. This file is sort of like a phone book. It gives a relationship between a system’s hostname and an ip address. Much like a telephone, if you dial the wrong number you get the wrong person. In NIM, if your ip address does not match up to the correct hostname, your install fails. This is a text file and can be edited manually. There should also only be 1 entry per ip/hostname. I personally prefer to make sure my NIM master has all entries in the /etc/hosts file and are of the following format :

If the client machine is up and running, it should also have a good entry in there for the NIM master as well.
- /etc/niminfo:
This file should always exist on the NIM master and sometimes will exist on a NIM client.
On the Master : This file is built when you first initialize the NIM environment. This is simply a text file so feel free to ‘cat’ or ‘more’ the file and look at the entries included in there. You do not want to manually edit this file if there is a mistake in the definition of the master. In this case you will want to redefine the master, or use the feature in NIM to change the master’s attributes (hostname, gateway....etc).
On the Client : This file is “optional” depending on what sort of operations you are performing on the client. If the NIM client is up and running, and you intend to perform operations on the client (like take backups, or install maintenance) you will want to make sure this file exists. This file contains not only hostname information for the client, but tells the client who its master is.
This also should not be edited manually. If there is incorrect information in the file, it should be removed and recreated.

- /tftpboot :
This directory should always exist on the NIM master. The main purpose of this directory is to hold the boot images that are created by NIM when a boot or installation is initiated. This directory also holds informational files about the clients that are having a boot or installation operation performed. The file names that are generated in both cases are very descriptive file names For example :
The boot image created might be named : 53_spot.chrp.mp.ent.
The format of the file name is ...
The client info files are aptly named : .info
The NIM master will create the file and link it to the boot image. This boot image is what is sent over to the NIM client during a boot/installation operation.

NIM key words

Base Operating System Installation :
Also commonly called (and referred to from here on out) as a bos_inst operation. This simply refers to the fact that you are initiating a boot and installation to a client machine. There are other installation types that do NOT require a boot. A bos_inst operation always means a boot of the client machine is involved.

Bootp :
This is the initial communication made between the NIM master and client during a boot or bosinst operation. In order for this to be successful several factors must be met :

1. - bootpd must be running on the NIM master

2. - the NIM client and master must have correct ip information about each other

3. - the /etc/bootptab must be populated correctly

4. - If the master and client systems are on separate networks, the router must be set to forward bootp packets.

There are other causes of failure, but checking/verifying those 4 will solve most bootp issues.

Tftp (Trivial File Transfer Protocol):
When the NIM client has been rebooted for a boot or bos_inst operation you don’t have access to normal TCP communication. Once bootp connection has successfully been achieved, the NIM master uses tftp to transfer over the .info file and the boot image to the client.

if1= : Or interface 1
This is known as the ‘nim network’. Every machine, even the master, is placed on a defined NIM network. A machine who has multiple adapters defined to NIM will have “if2=” and “if3=”....etc attributes. Not all adapters on a client need to be defined in NIM, only the ones that you wish to use with NIM. When your NIM master is generated, you will create a network name for the master and every client on the same subnet as the master. If you name this network “master_net” for example, then all clients on the same subnet as the master will have their “if1=” line set to “master_net”. If you add additional clients that are on separate subnets, then you will need to create new network names. You can see the “if1=” information from an :
# lsnim -l master |more
-or-
# lsnim -l

You can get further information about the network name by running an ‘lsnim -l ’.
Having incorrect networking information is probably the leading cause of NIM installation failures. This attribute and the information used when creating networks is extremely important to make sure you have correct.

Client (nim client) :
Any standalone machine or lpar in a NIM environment other than the NIM master. Clients use resources that reside on the NIM master to perform various software maintenance, backup, or other utility functions.
*Note that NIM resources do not always have to reside on the NIM master, but for our purposes they all will.

Groups (machine groups) :
In the spirit of convenience you can create a machine group which consists of a number of NIM clients. All NIM operations initiated from the master to that machine group subsequently are performed to all machines that are part of that group. For example, you can define a machine group and call it “Group1”. Group1 has ClientA, ClientB, ClientC, and ClientD in it. You can initiate a bos_inst operation to each individual client, or if all clients are being installed with the same image, you can initiate the bosinst operation to Group1. All client systems will be installed at the same time. The downside to this however, is that you sacrifice performance for convenience. It is best if you decide to use machine groups to test out what sort of load your network and NIM master can hold before seeing diminishing returns.

Master (nim master) :
The one and only one machine in a NIM environment that has permission to run commands remotely on NIM clients. A client can only have one master, and a master can not be a client of any other master. The NIM master must also be at an equal or higher OS/TL/SP level than any client in the NIM environment. The NIM master also can not create SPOT resources at a higher level than it is currently installed at. Finally, the NIM master can not install any clients with an OS/TL/SP higher than his own. Long story short, for all intents and purposes, for any NIM operation, make sure you master is at an equal or higher level.
The NIM master also will hold all of our NIM resources. Due to this we’ll want to make sure the NIM master has plenty of space available to it. Ideally, having a separate volume group (nimvg) is beneficial, so the rootvg does not get out of control in size.
Resource (nim resources) :
This can be a single file or up to a whole filesystem that is used to provide some sort of information to, or perform an operation on a NIM client. Resources are allocated to NIM clients using NFS and can be allocated to multiple clients at the same time. Various resource types will be explained below. I’ve decided to order them in a logical order of description rather than alphabetical order. It should make more sense to read through them in this manner.

Resource (nim resources) lpp_source:
When running an installation of a system outside of NIM, you use an installation CD. NIM uses resources. Two of the most important resources are made using the installation CD. First of all let’s understand what exactly is on an installation CD that allows us to install a system. There are 4 parts :
- The filesets that get installed.
- The .toc file so the system knows what filesets are on the media.
- The boot images so the CD can boot the system initially
- A /usr filesystem to run the commands needed to install the system.

The lpp_source is created from an AIX installation CD and is responsible for holding :
- The filesets that get installed.
- The .toc file so NIM knows what is available in the lpp_source to be installed to the client.

In short, the lpp_source is simply a depot. It’s just a directory that holds all of the filesets and the .toc file.

Resource (nim resources) SPOT:
The SPOT resource (stands for Shared Product Object Tree in case you were wondering) is responsible for the following :
- Creating a boot image to send to the client machine over the network.
- Running the commands needed to install the NIM client.

Essentially the SPOT is a /usr filesystem just like the one on your NIM master. You can think of it as having multiple “mini-systems” on your NIM master, because each SPOT is its own /usr filesystem. You can upgrade it, add fixes to it, use it to boot a client system....etc. Just like your NIM master’s /usr filesystem, going in there manually and messing around with files can easily corrupt it. The good thing about a SPOT however, is that it is easily rebuilt.
You can also create a SPOT from a NIM mksysb resource. This SPOT however is not as versatile as one created from an lpp_source and can not be upgraded with any fixes and can only be used with the mksysb resource it was created from.

Resource (nim resources) mksysb:
This is simply a mksysb image of a machine. The mksysb image can be of the NIM master, a NIM client, or a machine outside of the NIM environment. This resource can be defined in one of two ways.
- From an existing mksysb taken to file that resides on the NIM master.
- Creating a new mksysb image of a currently existing NIM client.
At this time there is no supported way to use a mksysb tape or mksysb on CD/DVD, as an input device to define a mksysb resource in NIM.

Resource (nim resources) bosinst_data:
When booting from installation media to install or upgrade a system you boot to what are known as the “BOS Menus” or Base Operating System Installation Menus. Here you select your console, what language to use, what disks to install to.....and many other options. In NIM we can create a “bosinst_data” resource that will answer these questions for us. By doing this we can perform a “non-prompted” installation. So if you have a NIM client in another building, down the road, or half way across the country, you can create this type of NIM resource which will provide the answers to those questions, so once you kick off the install from the NIM master no further interaction is required. The system should (ideally) install and reboot itself afterward.

A mksysb (as discussed above) has a “built in” bosinst.data file. If the option in that file
(PROMPT =) is set to yes, this file really does nothing as the choices you make in the BOS menus will override the options in the file. However, if the mksysb was created to have that option set to no, then we can create a new bosinst_data resource which will trump the one that is part of the mksysb.

Resource (nim resources) image_data:
Outside of NIM this file is responsible for knowing how your rootvg is built. It contains information like the partition size of rootvg, the disks belonging to rootvg, all of the filesystems (and their sizes) that belong to rootvg, whether the rootvg is mirrored, and other information. As with the bosinst_data file, a mksysb also has one of these “built in”. If this built in file needs to be altered in any way, we can accomplish this by creating and allocating an image_data resource.

NIM Master Installation

Procedure to install and configure the nim master

Command line :
# nimconfig -a pif_name=en0 -a master_port=1058 -a netname=master_net -a cable_type=bnc

pif_name = This is your primary interface for your NIM master
netname = Name your master’s network. With NIM you want to give objects names that are easy and descriptive. If I see “master_net” I know for that is my NIM master’s network. Using a name like “NetworkA” doesn’t really tell you anything just by the name itself.
The rest of the options are default options.

smit :
# smitty nimconfig
-or-
# smitty nim
=> Configure the NIM environment => Advanced configuration => Initialize the NIM master only

* Network Name [master_net]
* Primary Network Install Interface [en0]
Allow Machines to Register Themselves as Clients? [yes]
Alternate Port Numbers for Network Communications
(reserved values will be used if left blank)
Client Registration []
Client Communications []

Once this is complete you have a functioning NIM master.
Take a look at the following output and you’ll see information about your master :
# lsnim -l master

Look at this next output and you’ll see that by defining the NIM master you have some resources that have been pre-generated for you.
# lsnim -l |more

The “boot” resource created a /tftpboot directory to hold all of your boot images.

There’s also a “nim_scripts” resource. That belongs to the master. Do not go into the /export/nim/scripts and mess with any files that get generated during an install.

Finally, there’s a “master_net” which represents the NIM network we created earlier. All NIM clients that are on the same subnet as this master will be assigned to the “master_net” network.
If you add any NIM clients that are on a different network, then you will need to generate a new network name for that network. More on that a little later. Now we’ll go into defining your lpp_source and SPOT resources.
Setting up your first lpp_source resource :

Before we get your lpp_source and SPOT defined we’ll need to decide on a place to put them. One of the best things you can do in NIM is be neat. An organized NIM environment is a happy NIM environment. I recommend having separate filesystems for separate resource types. In other words I’ll have a filesystem to hold my lpp_sources, one to hold my SPOT resources, one for my mksysb images......etc. The “norm” is to use “/export/nim” filesystems.
For my lpp_sources I’ll create a filesystem called /export/nim/lpp_source. A good rule on space is a little more than a ½ gig per volume you want to copy down to your lpp_source. I will be using all 8 volumes of my 5300-05 base AIX media.

# crfs -v jfs2 -g nimvg -m /export/nim/lpp_source -a size=5G

This will create a jfs2 filesystem in nimvg with a size of 5gig and have a mountpoint of /export/nim/lpp_source. Again, this is just an example. Feel free to use rootvg or another volume group. If this command does not fit your environment you can go into :

# smitty crfs
...and create your own filesystem using whatever parameters you need.

We then mount up the filesystem :
# mount /export/nim/lpp_source

The lpp_source is now ready to be created. We’ll need Volume 1 of your base media in the drive. The minimum you’ll use is V1 of the media. You can put 1, 2, 3, or all volumes in the lpp_source. You’re looking at a trade off of space and convenience. I recommend at least having volumes 1-3 if you’re concerned about space. Ideally, and in this example environment, you want to create the lpp_source using all volumes of media.

From command line :
# nim -o define -t lpp_source -a location=/export/nim/lpp_source/53_05 -a server=master -a comments='5300-05 lpp_source' -a multi_volume=yes -a source=/dev/cd0 -a packages=all 5305_lpp

Yes, that would be 1 command. That is one of the reasons many NIM operations are done from SMIT. It’s really easy to mistype something, especially if communicating over the phone with someone in a noisy server room. Now, to break down the command :
The only 2 required fields are the “location” (where we want it to be created) and “server” (which machine will hold this resource). You can hold resources on other NIM clients but for our purposes we will always hold resources on the NIM master. The rest of the “-a” flags are optional. You may think - ‘wait a minute....the source has to be required, otherwise, where do you get the filesets from ?’ You can “pre-generate” the lpp_source. If you’ve already copied the filesets down into a directory and want to use that as your lpp_source, then you have no “source”, you just have a “location”. At the end of the command, I named the resource “5305_lpp”. This is what NIM uses to reference this resource. Next we’ll use smit to do the same thing.
From SMIT :
# smitty nim_mkres
-or-
# smitty nim
=> Perform NIM Administration Tasks => Manage Resources => Define a Resource

Next you select “lpp_source” as the resource type.

* Resource Name [5305_lpp]
* Resource Type lpp_source
* Server of Resource [master]
* Location of Resource [/export/nim/lpp_source/5305]
Architecture of Resource []
Source of Install Images [/dev/cd0]
Names of Option Packages [all]
Show Progress [yes]
Comments [5300-05 lpp_source]

Notice there isn’t an option for multiple volumes. For the most part smit and command line are the same, but occasionally there are differences. Doing it this way will only create the lpp_source from V1 of the media. If you wish to add other volumes you can do one of the following :
A) bffcreate the volumes into the lpp_source
B) use NIM to add the volumes

# smitty nim_res_op
-or-
# smitty nim
=> Perform NIM Administration Tasks => Manage Resources => Perform Operations on Resources

Select your lpp_source
Select “update”

TARGET lpp_source 5305_lpp
SOURCE of Software to Add /dev/cd0
SOFTWARE Packages to Add [all]
-OR-
INSTALLP BUNDLE containing packages to add []
gencopy Flags
DIRECTORY for temporary storage during copying [/tmp]
EXTEND filesystems if space needed? Yes
Process multiple volumes? Yes

Either way, you will get the same result.
How to we take a look at the lpp_source ? We use the ‘lsnim’ command.

# lsnim -l 5305_lpp
5305_lpp:
class = resources
type = lpp_source
comments = 5300-05 lpp_source
arch = power
Rstate = ready for use
prev_state = unavailable for use
location = /export/nim/lpp_source/53_05
simages = yes
alloc_count = 0
server = master

Important lines :
Rstate = if this is not set to “ready for use” then you can not use this resource. Sometimes running a check on the lpp_source will allow you to clear this up.
# nim -o check

simages = This means that this lpp_source has the proper system images in order to properly build a SPOT resource. If any required system image filesets are missing from the lpp_source they will typically be listed at the bottom of the output.

Why wouldn’t you want all lppsources have the “simages” attribute to be “yes” ?
A lpp_source can have pretty much anything you want in it. It doesn’t have to be built from base installation media, nor does it have to be used to only build a SPOT. Let’s say you have your 5300-05 lpp_source, build a SPOT from it, and build some systems.
You then order some service pack updates (5300-05-01) for example. You can update your current lpp_source, but if you do that all of your future installs using this will be at 5300-05-01. If you do not want this to be the case, you can create another lpp_source that only holds these updates. It is more of a preference issue than anything else.

Next, we move on to creating a SPOT resource.

Setting up your first SPOT resource :

Now we will create a filesystem for our SPOT. This does not have nearly the space requirement that an lpp_source does. 500meg should be plenty of space for your initial SPOT. If you recall, the SPOT is just like a /usr filesystem. When you install your system from CD-ROM not every single fileset gets installed to the system right - only what is necessary to run the system. The same applies for the SPOT.

# crfs -v jfs2 -g nimvg -m /export/nim/spot -a size=1G

We then mount up the filesystem :
# mount /export/nim/spot

From command line :

# nim -o define -t spot -a server=master -a source=5305_lpp -a location=/export/nim/spot -a auto_expand=yes -a comments='5300-05 spot' 5305_spot

Here you minimally have 3 required fields. You need to let the NIM master know who will be holding the resource (again, you can use a NIM client as a resource server, but that is rare, and for our purposes, it will always be the NIM master), you need to give it an lpp_source that contains the “simages=yes” attribute, and you need to give it a location to build the resource.

The “auto_expand=yes” is recommended because this allows the system to automatically expand the size of the filesystem if necessary (instead of failing the operation).

From SMIT:

# smitty nim_mkres
-or-
# smitty nim
=> Perform NIM Administration Tasks => Manage Resources => Define a Resource
Next you select “SPOT” as the resource type.

* Resource Name [5305_spot]
* Resource Type spot
* Server of Resource [master]
* Source of Install Images [5305_lpp]
* Location of Resource [/export/nim/spot]
Expand file systems if space needed? Yes
Comments [5300-05 spot]

This will take a while to create as it is typically installs 300+ filesets into the SPOT resource. Once this completes you can check the output of the lsnim command to see information about the SPOT.

# lsnim -l 5305_spot
5305_spot:
class = resources
type = spot
comments = 5300-05 spot
plat_defined = chrp
arch = power
bos_license = yes
Rstate = ready for use
prev_state = verification is being performed
location = /export/nim/spot/5305_spot/usr
version = 5
release = 3
mod = 0
oslevel_r = 5300-05
alloc_count = 0
server = master
Rstate_result = success
mk_netboot = yes

Important lines :
Rstate = if this is not set to “ready for use” then you can not use this resource. The first thing you’ll want to do is run a force check against the SPOT. This forces the rebuild of the boot images and should return the “unavailable for use” back to “ready for use”.
# nim -Fo check

oslevel_r = this works just like the ‘oslevel -r’ if you ran that from an AIX command line. Knowing the level of the SPOT resource is extremely important in NIM operations we will go into later.

Your NIM master has officially been initialized and setup. The next 2 sections go into alternate (theoretically “easier”, but we’ll call it “less interactive”) ways of setting up the NIM master.

Feel free to review those and/or move on to defining NIM clients.

Number of Hits :

Script to Get information from hmc

2010-03-24T07:00:00.001+05:30

Perl Script to collect information from HMC

Without login to hmc we can collect the information about the servers that are configured in a hmc
with perl script

please find the below perl script will do above task for us and will keep the information in CSV file

collect - > store in .csv file

#!/usr/bin/perl

my @systems;
my @lpar;
my @memory,$memo;
my @cpu,$cu;
my $Hostname;
my $UID;

print "\n Enter the HMC Host Name :";
$Hostname = <>;
chomp($Hostname);
print "\n Enter the HMC USER ID :";
$UID = <>;
chomp($UID);

@systems = `ssh $UID\@$Hostname lssyscfg -r sys -F name`;
print "$pass";
print "\n one sone";
open(DATA, "> $Hostname");

print DATA "SERVER NAME:SERIAL NUMBER:VIRTUAL COUNT:MEMORY:CPU COUNT:LPARNAMES \n";
print "\n The number of systems in HMC : @systems \n";
foreach $system1 ( @systems )
{
chomp( $system1);
$cmd = 'ssh '.$UID.'@'.$Hostname.' lssyscfg -r lpar -m \\\''.$system1.'\\\' -F name';

print " $cmd \n";

@lpar = `$cmd`;

$cmd = 'ssh '.$UID.'@'.$Hostname.' lssyscfg -r sys -m \\\''.$system1.'\\\' -F serial_num';
$serialnum = `$cmd`;
chomp($serialnum);
print " Serial number : $serialnum \n";

$cmd = 'ssh '.$UID.'@'.$Hostname.' lshwres -m \\\''.$system1.'\\\' -r proc --level sys | cut -d , -f 4';

print " $cmd \n";
$memo = `$cmd`;
chomp( $memo);
@memory = split('=',$memo);

$cmd = 'ssh '.$UID.'@'.$Hostname.' lshwres -m \\\''.$system1.'\\\' -r mem --level sys | cut -d , -f 4';

print " $cmd \n";
$cu = `$cmd`;
@cpu = split( '=',$cu);
chomp($cpu[1]);
chomp($memory[1]);
print " \n The number of LPARS in system $system1: @lpar \n ";
print " The number of CPU's : chomp($cpu[1]) \n";
print " The Memory in the system is :chomp($memory[1]) \n";

$outline="$system1:$serialnum:$#lpar:$cpu[1]:$memory[1]\n";
$str="";
$count=$#lpar;
while ($count>0)
{
chomp($lpar[$count-1]);
$str = $str."$lpar[$count-1],";
$count=$count-1;
}
print DATA "$system1:$serialnum:$#lpar:$cpu[1]:$memory[1]:$str \n";
}
Number of Hits :

AIX Basic commands

2010-03-19T12:08:00.003+05:30

Introduction

As you know, AIX® has a vast array of commands that enable you to do a multitude of tasks. Depending on what you need to accomplish, you use only a certain subset of these commands. These subsets differ from user to user and from need to need. However, there are a few core commands that you commonly use. You need these commands either to answer your own questions or to provide answers to the queries of the support professionals.

In this article, I'll discuss some of these core commands. The intent is to provide a list that you can use as a ready reference. While the behavior of these commands should be identical in all releases of AIX, they have been only tested under AIX 5.3.

Note:

The bootinfo command discussed in the following paragraphs is NOT a user-level command and is NOT supported in AIX 4.2 or later.

Commands

Kernel

How would I know if I am running a 32-bit kernel or 64-bit kernel?

To display if the kernel is 32-bit enabled or 64-bit enabled, type:

bootinfo -K

Not able to FTP as Root

How do I know if I am running a uniprocessor kernel or a multiprocessor kernel?

/unix is a symbolic link to the booted kernel. To find out what kernel mode is running, enter ls -l /unix and see what file /unix it links to. The following are the three possible outputs from the ls -l /unix command and their corresponding kernels:

/unix -> /usr/lib/boot/unix_up # 32 bit uniprocessor kernel

/unix -> /usr/lib/boot/unix_mp # 32 bit multiprocessor kernel

/unix -> /usr/lib/boot/unix_64 # 64 bit multiprocessor kernel

Note:

AIX 5L Version 5.3 does not support a uniprocessor kernel.

How can I change from one kernel mode to another?

During the installation process, one of the kernels, appropriate for the AIX version and the hardware in operation, is enabled by default. Let us use the method from the previous question and assume the 32-bit kernel is enabled. Let us also assume that you want to boot it up in the 64-bit kernel mode. This can be done by executing the following commands in sequence:

ln -sf /usr/lib/boot/unix_64 /unix

ln -sf /usr/lib/boot/unix_64 /usr/lib/boot/unix

bosboot -ad /dev/hdiskxx

shutdown -r

The /dev/hdiskxx directory is where the boot logical volume /dev/hd5 is located. To find out what xx is in hdiskxx, run the following command:

lslv -m hd5

Note:

In AIX 5.2, the 32-bit kernel is installed by default. In AIX 5.3, the 64-bit kernel is installed on 64-bit hardware and the 32-bit kernel is installed on 32-bit hardware by default.

Hardware

How would I know if my machine is capable of running AIX 5L Version 5.3?

AIX 5L Version 5.3 runs on all currently supported CHRP (Common Hardware Reference Platform)-based POWER hardware.

How would I know if my machine is CHRP-based?

Run the prtconf command. If it's a CHRP machine, the string chrp appears on the Model Architecture line.

How would I know if my System p machine (hardware) is 32-bit or 64-bit?

To display if the hardware is 32-bit or 64-bit, type:

bootinfo -y

How much real memory does my machine have?

To display real memory in kilobytes (KB), type one of the following:

bootinfo -r

lsattr -El sys0 -a realmem

Can my machine run the 64-bit kernel?

64-bit hardware is required to run the 64-bit kernel.

What are the values of attributes for devices in my system?

To list the current values of the attributes for the tape device, rmt0, type:

lsattr -l rmt0 -E

To list the default values of the attributes for the tape device, rmt0, type:

lsattr -l rmt0 -D

To list the possible values of the login attribute for the TTY device, tty0, type:

lsattr -l tty0 -a login -R

To display system level attributes, type:

lsattr -E -l sys0

How many processors does my system have?

To display the number of processors on your system, type:

lscfg | grep proc

How many hard disks does my system have and which ones are in use?

To display the number of hard disks on your system, type:

lspv

How do I list information about a specific physical volume?

To find details about hdisk1, for example, run the following command:

lspv hdisk1

How do I get a detailed configuration of my system?

Type the following:

lscfg

The following options provide specific information:

-p Displays platform-specific device information. The flag is applicable to AIX 4.2.1 or later.

-v Displays the VPD (Vital Product Database) found in the customized VPD object class.

For example, to display details about the tape drive, rmt0, type:

lscfg -vl rmt0

You can obtain very similar information by running the prtconf command.

How do I find out the chip type, system name, node name, model number, and so forth?

The uname command provides details about your system.

uname -p Displays the chip type of the system. For example, PowerPC.

uname -r Displays the release number of the operating system.

uname -s Displays the system name. For example, AIX.

uname -n Displays the name of the node.

uname -a Displays the system name, nodename, version, machine ID.

uname -M Displays the system model name. For example, IBM, 9114-275.

uname -v Displays the operating system version.

uname -m Displays the machine ID number of the hardware running the system.

uname -u Displays the system ID number.

What version, release, and maintenance level of AIX is running on my system?

Type one of the following:

oslevel -r

lslpp -h bos.rte

How can I determine which fileset updates are missing from a particular AIX level?

To determine which fileset updates are missing from 5300-04, for example, run the following command:

oslevel -rl 5300-04

What SP (Service Pack) is installed on my system?

To see which SP is currently installed on the system, run the oslevel -s command. Sample output for an AIX 5L Version 5.3 system, with TL4, and SP2 installed would be:

oslevel â€“s

5300-04-02

Is a CSP (Concluding Service Pack) installed on my system?

To see if a CSP is currently installed on the system, run the oslevel -s command. Sample output for an AIX 5L Version 5.3 system, with TL3, and CSP installed would be:

oslevel -r

5300-03-CSP

How do I create a file system?

The following command will create, within volume group testvg, a jfs file system of 10MB with mounting point /fs1:

crfs -v jfs -g testvg -a size=10M -m /fs1

The following command will create, within volume group testvg, a jfs2 file system of 10MB with mounting point /fs2 and having read only permissions:

crfs -v jfs2 -g testvg -a size=10M -p ro -m /fs2

How do I change the size of a file system?

To increase the /usr file system size by 1000000 512-byte blocks, type:

chfs -a size=+1000000 /usr

Note:

In AIX 5.3, the size of a JFS2 file system can be shrunk as well.

How do I mount a CD?

Type the following:

mount -V cdrfs -o ro /dev/cd0 /cdrom

How do I mount a file system?

The following command will mount file system /dev/fslv02 on the /test directory:

mount /dev/fslv02 /test

How do I mount all default file systems (all standard file systems in the /etc/filesystems file marked by the mount=true attribute)?

The following command will mount all such file systems:

mount {-a|all}

How do I unmount a file system?

Type the following command to unmount /test file system:

umount /test

How do I display mounted file systems?

Type the following command to display information about all currently mounted file systems:

mount

How do I remove a file system?

Type the following command to remove the /test file system:

rmfs /test

How can I defragment a file system?

The defragfs command can be used to improve or report the status of contiguous space within a file system. For example, to defragment the file system /home, use the following command:

defragfs /home

Which fileset contains a particular binary?

To show bos.acct contains /usr/bin/vmstat, type:

lslpp -w /usr/bin/vmstat

Or to show bos.perf.tools contains /usr/bin/svmon, type:

which_fileset svmon

How do I display information about installed filesets on my system?

Type the following:

lslpp -l

How do I determine if all filesets of maintenance levels are installed on my system?

Type the following:

instfix -i | grep ML

How do I determine if a fix is installed on my system?

To determine if IY24043 is installed, type:

instfix -ik IY24043

How do I install an individual fix by APAR?

To install APAR IY73748 from /dev/cd0, for example, enter the command:

instfix -k IY73748 -d /dev/cd0

How do I verify if filesets have required prerequisites and are completely installed?

To show which filesets need to be installed or corrected, type:

lppchk -v

How do I get a dump of the header of the loader section and the symbol entries in symbolic representation?

Type the following:

dump -Htv

How do I determine the amount of paging space allocated and in use?

Type the following:

lsps -a

How do I increase a paging space?

You can use the chps -s command to dynamically increase the size of a paging space. For example, if you want to increase the size of hd6 with 3 logical partitions, you issue the following command:

chps -s 3 hd6

How do I reduce a paging space?

You can use the chps -d command to dynamically reduce the size of a paging space. For example, if you want to decrease the size of hd6 with four logical partitions, you issue the following command:

chps -d 4 hd6

How would I know if my system is capable of using Simultaneous Multi-threading (SMT)?

Your system is capable of SMT if it's a POWER5-based system running AIX 5L Version 5.3.

How would I know if SMT is enabled for my system?

If you run the smtctl command without any options, it tells you if it's enabled or not.

Is SMT supported for the 32-bit kernel?

Yes, SMT is supported for both 32-bit and 64-bit kernel.

How do I enable or disable SMT?

You can enable or disable SMT by running the smtctl command. The following is the syntax:

smtctl [ -m off | on [ -w boot | now]]

The following options are available:

-m off Sets SMT mode to disabled.

-m on Sets SMT mode to enabled.

-w boot Makes the SMT mode change effective on next and subsequent reboots if you run the bosboot command before the next system reboot.

-w now Makes the SMT mode change immediately but will not persist across reboot.

If neither the -w boot or the -w now options are specified, then the mode change is made immediately. It persists across subsequent reboots if you run the bosboot command before the next system reboot.

How do I get partition-specific information and statistics?

The lparstat command provides a report of partition information and utilization statistics. This command also provides a display of Hypervisor information.

Volume groups and logical volumes

How do I know if my volume group is normal, big, or scalable?

Run the lsvg command on the volume group and look at the value for MAX PVs. The value is 32 for normal, 128 for big, and 1024 for scalable volume group.

How to create a volume group?

Use the following command, where spartition_size sets the number of megabytes (MB) in each physical partition where the partition_size is expressed in units of MB from 1 through 1024. (It's 1 through 131072 for AIX 5.3.) The partition_size variable must be equal to a power of 2 (for example: 1, 2, 4, 8). The default value for standard and big volume groups is the lowest value to remain within the limitation of 1016 physical partitions per physical volume. The default value for scalable volume groups is the lowest value to accommodate 2040 physical partitions per physical volume.

mkvg -y name_of_volume_group -s partition_size list_of_hard_disks

How can I change the characteristics of a volume group?

You use the following command to change the characteristics of a volume group:

chvg

How do I create a logical volume?

Type the following:

mklv -y name_of_logical_volume name_of_volume_group number_of_partition

How do I increase the size of a logical volume?

To increase the size of the logical volume represented by the lv05 directory by three logical partitions, for example, type:

extendlv lv05 3

How do I display all logical volumes that are part of a volume group (for example, rootvg)?

You can display all logical volumes that are part of rootvg by typing the following command:

lsvg -l rootvg

How do I list information about logical volumes?

Run the following command to display information about the logical volume lv1:

lslv lv1

How do I remove a logical volume?

You can remove the logical volume lv7 by running the following command:

rmlv lv7

The rmlv command removes only the logical volume, but does not remove other entities, such as file systems or paging spaces that were using the logical volume.

How do I mirror a logical volume?

1. mklvcopy LogicalVolumeName Numberofcopies

2. syncvg VolumeGroupName

How do I remove a copy of a logical volume?

You can use the rmlvcopy command to remove copies of logical partitions of a logical volume. To reduce the number of copies of each logical partition belonging to logical volume testlv, enter:

rmlvcopy testlv 2

Each logical partition in the logical volume now has at most two physical partitions.

Queries about volume groups

To show volume groups in the system, type:

lsvg

To show all the characteristics of rootvg, type:

lsvg rootvg

To show disks used by rootvg, type:

lsvg -p rootvg

How to add a disk to a volume group?

Type the following:

extendvg VolumeGroupName hdisk0 hdisk1 ... hdiskn

How do I find out what the maximum supported logical track group (LTG) size of my hard disk?

You can use the lquerypv command with the -M flag. The output gives the LTG size in KB. For instance, the LTG size for hdisk0 in the following example is 256 KB.

/usr/sbin/lquerypv -M hdisk0

256

You can also run the lspv command on the hard disk and look at the value for MAX REQUEST.

What does syncvg command do?

The syncvg command is used to synchronize stale physical partitions. It accepts names of logical volumes, physical volumes, or volume groups as parameters.

For example, to synchronize the physical partitions located on physical volumes hdisk6 and hdisk7, use:

syncvg -p hdisk4 hdisk5

To synchronize all physical partitions from volume group testvg, use:

syncvg -v testvg

How do I replace a disk?

1. extendvg VolumeGroupName hdisk_new

2. migratepv hdisk_bad hdisk_new

3. reducevg -d VolumeGroupName hdisk_bad

How can I clone (make a copy of ) the rootvg?

You can run the alt_disk_copy command to copy the current rootvg to an alternate disk. The following example shows how to clone the rootvg to hdisk1.

alt_disk_copy -d hdisk1

Network

How can I display or set values for network parameters?

The no command sets or displays current or next boot values for network tuning parameters.

How do I get the IP address of my machine?

Type one of the following:

ifconfig -a

host Fully_Qualified_Host_Name

For example, type host cyclop.austin.ibm.com.

How do I identify the network interfaces on my server?

Either of the following two commands will display the network interfaces:

lsdev -Cc if

ifconfig -a

To get information about one specific network interface, for example, tr0, run the command:

ifconfig tr0

How do I activate a network interface?

To activate the network interface tr0, run the command:

ifconfig tr0 up

How do I deactivate a network interface?

For example, to deactivate the network interface tr0, run the command:

ifconfig tr0 down

Number of Hits :

enabling ssh login to AIX server

2009-11-17T17:48:00.000+05:30

Enabling SSH Login

Enabling SSH Login to root

Go the /etc/ssh directory where you find sshd_conf ig file
vi sshd_config
there you will find the " PermitRootLogin no " make this to

PermitRootLogin yes

Then root will be able to login

How to find out the problem with your sshd

just type /usr/sbin/sshd -d on your command prompt it will debug your sshd

then you can see the problem

# /usr/sbin/sshd -d
debug1: sshd version OpenSSH_5.0p1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on ::.
Bind to port 22 on :: failed: Address already in use.
Cannot bind any address.

How to resolve the problem Bind to port 22 on :: failed: Address already in use.

Go the /etc/ssh directory where you find sshd_conf ig file
vi sshd_config

then you will find the below lines

#Port 22
AddressFamily IPV6
#ListenAddress 0.0.0.0
#ListenAddress ::

then comment all the lines

then the stop and start the sshd

stopsrc -g ssh
startsrc -g ssh

then the problem will be solved you will be able to connect to the server by SSH.

Number of Hits :

Changing the time Zone in Linux and AIX

2009-10-14T16:44:00.000+05:30

Changing the Time Zone in Linux.

Logged in as root, check which timezone your machine is currently using by executing `date`. You'll see something like Mon 17 Jan 2005 12:15:08 PM PST, PST in this case is the current timezone.
Change to the directory /usr/share/zoneinfo here you will find a list of time zone regions. Choose the most appropriate region, if you live in Canada or the US this directory is the "America" directory.
If you wish, backup the previous timezone configuration by copying it to a different location. Such as
```
mv /etc/localtime  /etc/localtime-old
```
Create a symbolic link from the appropiate timezone to /etc/localtime. Example:
```
ln -sf /usr/share/zoneinfo/Europe/Amsterdam /etc/localtime
```
If you have the utility rdate, update the current system time by executing
```
/usr/bin/rdate -s time-a.nist.gov
```
Set the ZONE entry in the file /etc/sysconfig/clock file (e.g. "America/Los_Angeles")
Set the hardware clock by executing:
```
/sbin/hwclock --systohc
```

Tips

The time server parameter for rdate can be any public server that supports the RFC-868 time protocol. A list of public RFC-868 servers can be found at [2]. Note: As of April 2007, NIST announced it would phase out support for RFC-868 (scroll to the bottom of [3] to see the announcement). This has not happened as of April 2009).
On some versions of RedHat Linux, Slackware, Gentoo, SuSE, Debian, Ubuntu, and anything else that is "normal", the command to display and change the time is 'date', not 'clock'
On RedHat Linux there is a utility called "Setup" that allows one to select the timezone from a list, but you must have installed the 'redhat-config-date' package. <>
On mobile phones and other small devices that run Linux, the time zone is stored differently. It is written in /etc/TZ, in the format that is described, for instance, in [4]. Edit this file manually or use echo (for instance, echo GMT0BST > /etc/TZ to set the the timezone of the United Kingdom).
To setup UTC :
vi /etc/sysconfig/clock and change the UTC line to: "UTC=true"
On systems that use dpkg (for example Debian and Ubuntu/Kubuntu), you should try "sudo dpkg-reconfigure tzdata". This will set up everything correctly in very few, simple steps.

Warnings

Some applications (such as PHP) have separate timezone settings from the system timezone.

On some systems, there is a system utility provided that will prompt for the correct timezone and make the proper changes to the system configuration. For example, Debian provides the "tzsetup" or "tzconfig" utility.

Changing the Time

To change the time use date followed by the month, day, hour, minute, and year all numeric and no spaces. So, to set the date and time to November 2nd, 2003 12:57

Changing the Time zone in AIX

TO change the Time zone in AIX

1) smitty
2) selce the system environment
3) select the change time
4) select the change the time zone using user defined
6) enter the the time zone and valu Like IST , _5:30

Than you are done with the time zone.
But AIX needs the Reboot .
Number of Hits :

Using Crontab in UNIX

2009-09-10T12:30:00.000+05:30

1. Controls on Using the crontab Command

The /var/adm/cron/cron.allow and /var/adm/cron/cron.deny files control which users can use the crontab command A root user can create, edit, or delete these files.

Entries in these files are user login names with one name to a line. If your login ID is associated with more than one login name, the crontab command uses the first

login name that is in the /etc/passwd file, regardless of which login name you might actually be using. Also, to allow users to start cron jobs, the daemon attribute in

the /etc/security/user file should be set to TRUE , using the chuser command.

The following is an example of an cron.allow file:

root

nick

dee

sarah

If the cron.allow file exists, only users whose login names appear in it can use the crontab command. The root user's log name must appear in the cron.allow file if the

file exists. A system administrator can explicitly stop a user from using the crontab command by listing the user's login name in the cron.deny file. If only the

cron.deny file exists, any user whose name does not appear in the file can use the crontab command.

A user cannot use the crontab command if one of the following is true:

* The cron.allow file and the cron.deny file do not exist (allows root user only).

* The cron.allow file exists but the user's login name is not listed in it.

* The cron.deny file exists and the user's login name is listed in it.

If neither the cron.allow nor the cron.deny file exists, only someone with root user authority can submit a job with the crontab command.

2. Crontab Commands

export EDITOR=vi ;to specify a editor to open crontab file.

c -e UserName

Edits a copy of the user's crontab file or creates an empty file to edit if the crontab file does not exist for a valid UserName. When editing is complete, the

file is copied into the crontab directory as the user's crontab file.

-l UserName

Lists the user's crontab file.

-r UserName

Removes the user's crontab file from the crontab directory.

-v UserName

Lists the status of the user's cron jobs.

3. Crontab file

Crontab syntax :-

A crontab file has five fields for specifying day , date and time followed by the command to be run at that interval.

* * * * * command to be executed

- - - - -

| | | | |

| | | | +----- day of week (0 - 6) (Sunday=0)

| | | +------- month (1 - 12)

| | +--------- day of month (1 - 31)

| +----------- hour (0 - 23)

+------------- min (0 - 59)

* in the value field above means all legal values as in braces for that column.

The value column can have a * or a list of elements separated by commas. An element is either a number in the ranges shown above or two numbers in the range separated by a hyphen (meaning an inclusive range).

Note: The specification of days can be made in two fields: month day and weekday. If both are specified in an entry, they are cumulative meaning both of the entries will get executed .

4. Crontab Example

2 To write the time to the console every hour on the hour, enter:

0 * * * * echo The hour is `date` .

>/dev/console

3 To run the calendar command at 6:30 a.m. every Monday, Wednesday, and Friday, enter:

30 6 * * 1,3,5 /usr/bin/calendar

4 To run the calendar command every day of the year at 6:30, enter the following:

30 6 * * * /usr/bin/calendar

5 To run a script called maintenance every day at midnight in August, enter the following:

0 0 * 8 * /u/harry/bin/maintenance

6 To define text for the standard input to a command, enter:

0 16 * 12 5 /usr/sbin/wall%HAPPY HOLIDAY!%Remember to

turn in your time card.

The text following the % (percent sign) defines the standard input to the wall command as:

HAPPY HOLIDAY!

Remember to turn in your time card.

5. Crontab Environment

cron invokes the command from the user's HOME directory with the shell, (/usr/bin/sh).

cron supplies a default environment for every shell, defining:

HOME=user's-home-directory

LOGNAME=user's-login-id

PATH=/usr/bin:/usr/sbin:.

SHELL=/usr/bin/sh

Users who desire to have their .profile executed must explicitly do so in the crontab entry or in a script called by the entry.

6. Disable Email

By default cron jobs sends a email to the user account executing the cronjob. If this is not needed put the following command At the end of the cron job line .

>/dev/null 2>&1

7. Generate log file

collect the cron execution execution log in a file :
30 18 * * * rm /home/someuser/tmp/* > /home/someuser/cronlogs/clean_tmp_dir.log

Number of Hits :

Not able to FTP as root in AIX

2009-08-20T14:05:00.000+05:30

Not able to FTP as Root

This is the problem many number of the system admins face.

1) First check the /etc/ftpusers file

if that file exist then edit that file and remove the root entry there in that file

2) check for the ports that are active for the FTP or not.

3)If you are using ip adresses, make sure the servers can ping each other by ip adress. If you are using hostnames, then make sure the two servers can resolve each other's hostname.

4) Check the /etc/inetd.conf file

where the /usr/sbin/ftpd ftpd must not be commented.
if comented please remove the comment ( #)

5) check for the /etc/services

in this file check for the FTP services they must not be commented.
Check for the FTP/TCP and FTP/UDP and all services related to FTP.
they must not be comented.

6) Finally and most importent thing is

The shell of the root also important , if the root's default shell is 'bash' then you will not be able to FTP to that server by root.
Please chanag the root default shell to ksh.

Number of Hits :

AIX boot Process

2009-08-07T17:16:00.000+05:30

AIX Boot process .

1)you power on the AIX server
2)The POST ( Power On Self Test ) will be done .

It varifies the basic hardware, Check is it is in functional state or not.
The memory,keyboard, communication and audio devices are also initialized
we can see the icons on the the screen
3)This is the correct step where you can select the boot list by pressing function key
4)The LED values displayed during this phase are model specific.
5)The system read only Storage is specific to the system type. It is the one which is used to boot the system ,but it will not contain any data structure.
This ROS contain only the location to the bootstrap .
It will load the the Bootstrap .
ROS contains generic boot information and is operating system independent.
6)The bootstrap also called as software ROS.
This bootstrap contains IPL ( Initial Program loader )
Which is used to build AIX specific boot information.
Software RS is AIX 5L information created based on machine type and is responsible for completing machine preparation to enable it to start AIX 5L kernel.
7)A special file system will be created in memory called RAMFS ,
8)Bootstrap locates and loads the BLV in to memory and gives control to BLV
9)BLV ( boot Logical volume )
The complete list of files that are there in BLV can be found in /usr/lib/boot.
The AIX 5L kernel
The boot command called during the booting process like cfgmgr, bootinfo
The reduced version of ODM ( object Data Manager ),
The hd4 contains all the device spcific methods info , but before loading we need
some devices like keyboard more . So the BLV contains methods to load those
devices .
The rc.boot program

10)Then BLV loads complete AIX kernel,and gives control. LED 0299.
11)All Previous LED values are hardware specific.
12)Complete the boot process by lading all the devices.
13) LED codes displayed during this stage will be generic AIX 5L specific
14)Now Init process will be started
15)Till now the rootvg is not mounted.
16)Till now the rc.boot script called 3 tiles with 1, 2, 3 arguments.
We call this as the 3 phases of initialization .
17)rc.boot 1 -----> Boot phase 1.
a) The init process started from RAMFS executes the boot script rc.boot 1
b) If init process fails the LED code will be c06.
c) restbase will be called in this phase to copy the partial copy of the ODM from BLV to RMFS.
d) IF successful then shows 510 , if fails 548 on LED.
e) After this, the cfgmgr -f command reads the Config_Rules class from the reduced ODM

f) devices with the attribute phase=1 are considered base devices. Base devices are all
devices that are necessary to access rootvg.
g) Like all the devices that are there to acced rootvg from mothere board to Hard disk
will be activated.
h) The bootinfo -b will be called to determine the last boot device .

18)rc.boot 2 -----------> Boot Phase 2.

a) The rootvg volume group is varied on with the special version of the varyonvg
ipl_varyon command
b) If this command is successful the LED value will be 517.
c) If failed LED value will be 552, 554, 556 and the boot process is halted.
d) Root file system hd4 is checked using the fsck -f command. This will verify
whether the lass shutdown was clean .
e) if command fails system will show 555
f) The root file system (/dev/hd4) is mounted on a temporary mount point /mnt in
RMFS
g) If this fails, 557 will appear in the LED display.
h)The /usr file system is verified using the fsck -f command and then mounted.
i) If fails then LED value will be 518.
j) The /var file system is verified using the fsck -f command and then mounted.
k) Then copycore command will check for dumps if exist then copy form the
default dump device /dev/hd6 to default directory /var/adm/ras.
l) After this /var is unmounted
m) The primary paging space from rootvg, /dev/hd6, will be activated.
n) The mergedev process is called and all /dev files from the RAM file system
copied on to disk.
o) All customized ODM files from the RAM file system are copied to disk.
p) Both ODM versions from hd4 and hd5 are now synchronized.
q) Finally, the root file system from rootvg (disk) is mounted over the root
filesystem from the RMFS.
r) The mount points for the rootvg file system is available now.
s) then /var /usr are mounted again on normal mount points.
t) There is no console available at this stage.so all the messages are copied to alog.
u) alog is program that maintain all the logs.

19) rc.boot 3 -----------> Boot Phase 3.

a) /etc/init program starts and reades the /etc/inittab callas rc.boot with 3.
b) The /tmp file system is mounted.
c) The rootvg is synchronized by calling the syncvg command and launching it as
as a background process.
d) As a result all stale partitions from rootvg are the LEC value is 553.
e) At this stage, the cfgmgr command is called: if the system is booted in normal
mode with the option -p2.
if it booted in service mode the cfgmgr is called with -p3 option.
f) The cfgmgr command reads the Config_rules file from oDM and calls all
methods corresponding to either phase=2 or phase=3.
g) All the devices that are not basic devices are initialized.
h) The console is configured by calling the cfgcon command , Now boot
messages are sent to console .
i) if there is any problem in console the messages are stored in
/var/adm/ras/conslog.

20)Finally the syncronization of ODM done from BLV with /root filesystem is done. Savebase command.
21)he syncd daemon and errdemon are started.
22)LED display went off.
23)If the file /etc/nologin exists, it will be removed.
24)If there are devices marked as missing in CuDv a message is displayed on the console
25)The message System initialization completed is sent to the console.
The execution of rc.boot is has completed the process init will continue the next command from /etc/inittab .

Number of Hits :

Boot Problem in AIX corrupted BLV

2009-07-30T11:02:00.000+05:30

Booting Problem in AIX

Here is the Procedure to Fix a Corrupted BLV (boot logical volume).

AIX Server stop booting if the your BLV is corrupted .By showing the LED value 557.

To fix this Problem , you must boot your machine in maintenance mode, from a CD or tape. If NIM has been set up for a machine, you can also boot the machine from a NIM master in maintenance mode.

We can set the boot list by “ bootlist” Command , or by SMS program.

Some machines support a normal and service boot list. If your model supports this, you will use a function key during bootup to select the appropriate list.
Normally, pressing F5 when you hear the first tones during bootup, will force the machine to check for a bootable CD.

Press the F5 continually ..................

Your Ad Here

After booting from CD, tape or NIM an Installation and Maintenance Menu is shown and you can startup the maintenance mode.

Access the rootvg,

Then you can repair the boot logical volume with the bosboot command.
Please specify the disk device, for example hdisk0:

Command : -- # bosboot -ad /dev/hdisk0

It is important that you do a proper shutdown. All changes need to be written from memory to disk.

The bosboot command requires that the boot logical volume hd5 exists.

If the BLV not existing ( deleted mistakenly ) you can create it from the scratch.
Please follow the below steps.

1. Boot your machine in maintenance mode (from CD or tape).
2. Create a new hd5 logical volume: one physical partition in size, must be in rootvg. Specify boot as logical volume type.
3. Run the bosboot command as described.
4. Reboot the server run command

# shutdown -Fr

Procedure of re-creating boot logical volume (BLV)

1. Boot your machine in maintenance mode (from CD, tape, or NIM).

2. Create a new hd5 logical volume: one physical partition in size, must be in rootvg. Specify boot as logical volume type. if needed, remove hd5 using # rmlv -f hd5

# mklv -y hd5 -t boot -a e rootvg 1

3. Run the bosboot command as described below.

# bosboot -ad /dev/hdisk0

4. Shutdown -Fr.

Device management in AIX

2009-06-21T14:48:00.000+05:30

TO lists all installed devices in AIX
lscfg
lscfg -v
lscfg -vl

TO Know last device the system booted from
bootinfo -b
bootinfo -k ----> keyswitch position
1=secure, 2=service, 3=normal

To know the amount of memory in 1024

bootinfo -r
bootinfo -s command to know the size of disk drive
bootinfo -T type of machine ie rspc

lsattr -El sys0 -a realmem ---- > comad to know the usable memory.

mknod c Creates a /dev/ device file.
mknod /dev/null1 c 2 3

To displays customized devices ie installed
lsdev -C displays customized devices ie installed

To pre-defined devices ie supported

lsdev -P
lsdev -(C or P) -c (class) -t (type) -s (subtype)

How to Change a device attribute
chdev -l (device) -a (attribute)=(new value)
chdev -l sys0 -a maxuproc=80

lsattr -EH -l (device) -D Lists the defaults in the pre-defined db
lsattr -EH -l sys0 -a modelname

TO change the device state from defined state to available state.
rmdev -l (device)
rmdev -l (device) -d Delete the device
rmdev -l (device) -SR S stops device, R unconfigures child devices

TO Displays bus resource attributes of a device.
lsresource -l (device)

Restoring the files from the MKSYSB image backup

2009-06-10T22:23:00.000+05:30

How do I restore specific files from a mksysb tape

To recover specific files from a backup made with mksysb
$ tctl -f /dev/rmt1 rewind
$ tar xvf /dev/rmt0.1 ./your/file/name

$ tctl -f /dev/rmt1 rewind
$ restore -xvf /dev/rmt0.1 ./your/file/name

Restore the file: restore -x -d -q -s4 -f /dev/rmt0.1
-s4 indicated that we are restoring 4th image on the tape,

Use rmt0.1, means no rewind on close and no retension on open.

If the backup was taken with -i flag, you can use the following command:
restore -x -d -v -q -f /dev/rmt0

If the mksysb backup was taken with file system backup, you can use the following command:
restore -x -v -q -f /dev/rmt0

Restoring A Directory File From mksysb Image
If you want to restore a full directory from the mksysb archive on /dev/rmt0. Here you have to specify the directory name instead of a single file:
Rewind The tape: tctl -f /dev/rmt1 rewind

Restore the file: restore -x -d -s4 -f /dev/rmt0.1

if the backup was taken with -i option then it will be:
restore -x -d -v -q -f /dev/rmt0

If the backup was taken with filesystem backup option then it will be:
restore -x -v -q -f /dev/rmt0

Number of Hits :

Creating Image of AIX by using MKSYSB

2009-06-09T18:10:00.000+05:30

We can create the image of the running AIX OS in to tape or in to a file by using MKSYSB command in AIX or in other words Creating an installable image of the root volume group either in a file or onto a bootable tape.

It is use full when the server crashes or when the server is down with some ODM problem or if system admin executed rm –R on root .

For the production servers it is recommended that every 1 month image of the running OS should be maintain in a secure place.

Helps in Provisioning the AIX OS

We can create a good image of running AIX OS with all the requisites for our environment and it will help us in provisioning the same image to all the P series machines in a same project so that all the machines will be of same configuration and at same level because mksysb creates backup of the running OS .

Creating a image on Tape

By the following command we can create the image on tape .

1) mksysb –i /dev/rmt0
It create the backup of the running OS on the tape , which will be bootable .

2) mksysb –m /dev/rmt0
Create the image with map files

3) mksysb –i
Create the backup on a file

Excluding the file in the backup

We can exclude the files that which we don’t want to backup , many reasons we don’t want to backup some files , the size of the file is one the major thing.

We need to follow below procedure to exclude the file from backup

1) Create the file name with /etc/exclude.rootvg
2) Write the file name that you want to exclude in the exclude.rootvg
3) Execute the command mksysb –ei /dev/rmt0

Notes:
1. The image the mksysb command creates does not include data on raw devices or in user-defined paging spaces.
2. If you are using a system with a remote-mounted /usr file system, you cannot reinstall your system from a backup image.
3. The mksysb command may not restore all device configurations for special features, such as /dev/netbios and some device drivers not shipped with the product.
4. Some rspc systems for AIX 5.1 and earlier do not support booting from tape. When you make a bootable mksysb image on an rspc system for AIX 5.1 and earlier that does not support booting from tape, the mksysb command issues a warning indicating that the tape will not be bootable. You can install a mksysb image from a system that does not support booting from tape by booting from a CD and entering maintenance mode. In maintenance mode you will be able to install the system backup from tape.
5. The mksysb command uses the backup command to create its archive image. The mksysb command will also save the EA format for any JFS2 filesystems being backed up. It uses the /usr/bin/mkvgdata shell script to save this information.

number of Hits :

How to create the user same privileges as root in UNIX

2009-05-12T15:07:00.000+05:30

Tech INFO

You can create a user with the same privileges as root

Steps:

1) create the user

smitty user ->add user
2)edit the etc/filesystem

modified your user row same as root user row.

this will allow the user with all the operations a root can do.

But It is not good paractice . please give the user with sudo access.

Note: If you want to change the password of the new user ID. first change the UID to some thing else than 0, and then change the password and again change the UID to 0.

If not you will be prompted to change the root password to change it when you login as root.

Number of hits :

IBM Director Installation Prerequisites

2009-05-11T22:09:00.000+05:30

IBM Director Installation Prerequisites.

Hardware requirements for running IBM Systems Director Server

IBM® Systems Director Server has certain hardware requirements. These requirements can vary depending on the size of your IBM Systems Director systems-management environment.

Recommended hardware requirements for IBM Systems Director Server running on Linux on x86-compatible systems

IBM® Systems Director Server has certain hardware requirements to run on x86-compatible systems running Linux®. These requirements can vary depending on the size of your IBM Systems Director systems-management environment.
The following recommendations are for three types of IBM Systems Director systems-management environments:

Small configuration

A systems-management environment that includes less than 500 Common-Agent managed systems. The database software is Apache Derby.

Medium configuration

A systems-management environment that includes between 500 and 1000 Common-Agent managed systems. The database software is IBM DB2®.

Large configuration

A systems-management environment that includes between 1000 and 5000 Common-Agent managed systems. The database software is IBM DB2.
When reviewing these recommendations, consider the following information:
• Installation and startup times improve with faster disk access times. SCSI adapters and 10 K RPM drives provide the best performance.
• Disk sizes are arbitrary and indicative of disk requirements.
• System performance depends on the nature of your requirements and system workload.
• The IBM DB2 database software sizing should be comparable for Oracle and Microsoft® SQL Server. The sizing presumes that DB2 is running on the same server as IBM Systems Director Server.
The following recommendations are based on a 32–bit version of SUSE Linux Enterprise Server 10 for x86. The recommendations are comparable for Red Hat Enterprise Linux on x86-compatible systems.
Table 1. IBM Systems Director Server recommended hardware requirements for different-sized Linux environments
Configuration Recommended hardware requirements
Processor Memory Disk storage
Small 1 processor, 3 GHz Intel® Xeon® 1 1 GB 4 GB
Medium 2 processors, 3 GHz Intel Xeon 1 2 GB 6 GB
Large 4 processors, 3 GHz Intel Xeon 1 4 GB 8 GB
1 The processor (CPU) sizing is based on the Intel Xeon processor, but is comparable for equivalent Intel® and AMD processors.
Attention: If you use DVD media to install IBM Systems Director Server, ensure that you allot an additional 1.2 GB of available space on the system to contain the agent packages that are copied from the DVD at the end of the server installation. The packages are copied to /opt/ibm/director/packaging/agent on the server.

Recommended hardware requirements for IBM Systems Director Server running on AIX

IBM® Systems Director Server has certain hardware requirements to run on IBM Power systems running AIX®, including JS21 and JS22 blade servers. These requirements can vary depending on the size of your IBM Systems Director systems-management environment.
The following recommendations are for three types of IBM Systems Director systems-management environments:
Small configuration
A systems-management environment that includes less than 500 Common-Agent managed systems. The database software is Apache Derby.
Medium configuration
A systems-management environment that includes between 500 and 1000 Common-Agent managed systems. The database software is IBM DB2®.
Large configuration
A systems-management environment that includes between 1000 and 5000 Common-Agent managed systems. The database software is IBM DB2.
When reviewing these recommendations, consider the following information:
• Installation and startup times improve with faster disk access times. SCSI adapters and 10 K RPM drives provide the best performance.
• Disk sizes are arbitrary and indicative of disk requirements.
• System performance depends on the nature of your requirements and system workload.
• The IBM DB2 database software sizing should be comparable for Oracle and Microsoft® SQL Server. The sizing presumes that DB2 is running on the same server as IBM Systems Director Server.
The following recommendations are based on a 32–bit Java™ Virtual Machine (JVM) running on a 64–bit version of AIX.

Note: Common Agent is always installed with IBM Systems Director Server, so ensure that you factor in the Common Agent requirements whenever considering IBM Systems Director Server requirements.

Table 1. IBM Systems Director Server recommended hardware requirements for different-sized AIX environments
Configuration Recommended hardware requirements
Processor Memory Disk storage2
Small 1 processor, POWER5™ or POWER6™1 2.5 - 3 GB 4 GB
Medium 2 processors,POWER5 or POWER61 4 GB 6 GB
Large 4 processors, POWER5 or POWER61 10 GB 8 GB
• 1 The processor (CPU) sizing is based on the IBM® POWER5 processor, but is comparable for equivalent IBM® POWER6 processors.
• 2 Disk storage requirements are for running IBM Systems Director Server.
Paging space should equal or exceed the physical memory size. Ensuring this is particularly critical if the physical memory is close to the 2.5 GB minimum requirement.
The following table provides information about disk storage requirements for installing IBM Systems Director Server. These requirements include Common Agent and Platform Agent, which are installed with IBM Systems Director Server.

Table 2. Disk storage requirements for installing IBM Systems Director Server
File system Disk space required
/ 10 MB
/usr 110 MB
/var 170 MB
/tmp 12 MB
Note: During the installation, /tmp must have 1 GB in free space. This space is only required during the installation and is freed after the installation is complete.
/opt 3 GB
Attention: If you use DVD media to install IBM Systems Director Server, ensure that you allot an additional 1.2 GB of available space in the /opt file system to contain the agent packages that are copied from the DVD at the end of the server installation. The packages are copied to /opt/ibm/director/packaging/agent on the server.

Recommended hardware requirements for IBM Systems Director Server running on Linux on Power Systems
IBM® Systems Director Server has certain hardware requirements to run on IBM Power systems running Linux®, including JS21 blade servers. These requirements can vary depending on the size of your IBM Systems Director systems-management environment.
The following recommendations are for three types of IBM Systems Director systems-management environments:
Small configuration
A systems-management environment that includes less than 500 Common-Agent managed systems. The database software is Apache Derby.
Medium configuration
A systems-management environment that includes between 500 and 1000 Common-Agent managed systems. The database software is IBM DB2®.
Large configuration
A systems-management environment that includes between 1000 and 5000 Common-Agent managed systems. The database software is IBM DB2.
When reviewing these recommendations, consider the following information:
• Installation and startup times improve with faster disk access times. SCSI adapters and 10 K RPM drives provide the best performance.
• Disk sizes are arbitrary and indicative of disk requirements.
• System performance depends on the nature of your requirements and system workload.
• The IBM DB2 database software sizing should be comparable for Oracle and Microsoft® SQL Server. The sizing presumes that DB2 is running on the same server as IBM Systems Director Server.
The following recommendations are based on a 32–bit Java™ Virtual Machine (JVM) running on a 64–bit version of SUSE Linux Enterprise Server 10 on IBM Power Systems™. The recommendations are comparable for Red Hat Enterprise Linux on IBM Power systems.

Table 1. IBM Systems Director Server recommended hardware requirements for different-sized Linux on Power Systems environments
Configuration Recommended hardware requirements
Processor Memory Disk storage 2
Small 1 processor, POWER5™ or POWER6™1 2.5 GB 4 GB
Medium 2 processors,POWER5 or POWER61 4 GB 6 GB
Large 4 processors, POWER5 or POWER61 10 GB 8 GB
• 1 The processor (CPU) sizing is based on the IBM® POWER5 processor, but is comparable for equivalent IBM® POWER6 processors.
• 2 Disk storage requirements are for running IBM Systems Director Server. For installing IBM Systems Director Server, 2.1 GB disk space is required. This requirement includes Common Agent and Platform Agent which are installed with IBM Systems Director Server. Also, during the installation, /tmp must have 1.7 GB in free space. This space is only required during the installation and is freed after the installation is complete.
Attention: If you use DVD media to install IBM Systems Director Server, ensure that you allot an additional 1.2 GB of available space on the system to contain the agent packages that are copied from the DVD at the end of the server installation. The packages are copied to /opt/ibm/director/packaging/agent on the server.

Recommended hardware requirements for IBM Systems Director Server running on IBM® System z servers

IBM® Systems Director Server has certain hardware requirements to run on IBM® System z systems running Linux®. These requirements can vary depending on the size of your IBM Systems Director systems-management environment.
The following recommendations are for three types of IBM Systems Director systems-management environments:

Small configuration
A systems-management environment that includes less than 500 Common-Agent managed systems. The database software is Apache Derby.
Medium configuration
A systems-management environment that includes between 500 and 1000 Common-Agent managed systems. The database software is IBM DB2® Universal Database™.
Large configuration
A systems-management environment that includes between 1000 and 2500 Common-Agent managed systems.
Note: The maximum number of managed systems supported by IBM® System z systems running Linux is smaller than the maximum supported by Linux on other platforms because of the limitation imposed by the 31-bit Java Virtual Machine (JVM).
The database software is IBM DB2 Universal Database.
When reviewing these recommendations, consider the following information:
• Disk sizes are arbitrary and indicative of disk requirements.
• System performance depends on the nature of your requirements and system workload.
• The IBM DB2 Universal Database software sizing should be comparable for Oracle® Database and Microsoft® SQL Server. The sizing presumes that IBM DB2 Universal Database is running on the same server as IBM Systems Director Server.
The following recommendations are based on a 31–bit JVM running on a 64–bit version of SUSE Linux Enterprise Server 10 on IBM® System z systems. The recommendations are comparable for Red Hat Enterprise Linux on IBM® System z systems.

Table 1. IBM Systems Director Server recommended hardware requirements for different Linux configuration sizes on System z systems environments
Configuration Recommended hardware requirements
Processor Memory Disk storage2
Small 1 processor, IBM® System z9 or above1 2 GB 3.5 GB (in /opt)
1.0 GB (in /tmp)
Medium 2 processors, IBM® System z9 or above1 4 GB 4.5 GB (in /opt)
1.0 GB (in /tmp)
Large 4 processors, IBM® System z9 or above1 8 GB 6.5 GB (in /opt)
1.0 GB (in /tmp)
1. The processor sizing is based on the IBM® System z9 EC processor, but is comparable for equivalent System z processors. The processor usage by IBM Systems Director Server is high during certain tasks. It is recommended that, if processors are shared, the partition that is used to run IBM Systems Director Server be given a lower partition weight than production partitions.
2. Disk storage requirements are for running IBM Systems Director Server. For installing IBM Systems Director Server, space is required in /opt. This requirement includes Common Agent and Platform Agent, which are installed with IBM Systems Director Server. Also, during the installation, /tmp must have free space as specified. This space is only required during the installation and is freed after the installation is complete.
Attention: If you use DVD media to install IBM Systems Director Server, ensure that you allot an additional 1.2 GB of available space on the system to contain the agent packages that are copied from the DVD at the end of the server installation. The packages are copied to /opt/ibm/director/packaging/agent on the server.

Hardware requirements for systems running Common Agent or Platform Agent (client )

Common Agent and Platform Agent have minimum processor speed, random access memory (RAM), and disk space requirements.
Note: The disk space listed is the minimum requirement for an installation using the default selections.
x86-compatible systems
Notes:
• The systems on which you install Common Agent must meet the Wired for Management (WfM), version 2.0, specifications.
• System Management BIOS (SMBIOS) 2.1 or later is required for all systems in an IBM® Systems Director environment.
Table 1. x86-compatible systems: Minimum hardware requirements
Requirements Platform Agent Common Agent
Processor speed Pentium 1.5 Ghz or equivalent Pentium 1.5 Ghz or equivalent
Memory (RAM) 512 MB 512 MB
Disk space 40 MB (for Windows®)
100 MB (for Linux®) 110 MB (for Windows)
170 MB (for Linux)
IBM Power systems running IBM i
Table 2. IBM Power systems running IBM i: Minimum hardware requirements
Requirements Common Agent
Relative system performance 150 commercial processing workload (CPW)
Storage pool size 350 MB
Disk space 300 MB

IBM Power systems running AIX®

Note: On systems that do not provide display capability, such as JS21 and JS22 blade servers, you must export IBM Systems Director Web interface using either the xhost command or SSH tunneling. The IBM Systems Director Web interface requirements apply to the receiving system.
Table 3. Servers running AIX: Minimum hardware requirements
Requirements Common Agent
Processor speed POWER5™ or POWER6™
Memory (RAM) 512 MB (minimum)
The following table provides information about disk storage requirements for installing Common Agent.

Table 4. Disk storage requirements for installing Common Agent
File system Disk space required
/ 10 MB
/usr 110 MB
/var 170 MB
/tmp 12 MB
/opt 190 MB
Note: During the installation, /tmp must have 280 MB in free space. This space is only required during the installation and is freed after the installation is complete.
If you are installing the Common Agent using the Agent Installation Wizard, the following disk space is required, in addition to the required installation disk space stated above:
• 210 MB for the dir6.1.0.0_commonagent_aix.sh file
• 210 MB for the extracted installation file sets
IBM Power systems running Linux
Note:

On systems that do not provide display capability, such as JS21, QS21, and QS22 blade servers, you must export the IBM Systems Director Web interface using either the xhost command or SSH. The IBM Systems Director Web interface requirements apply to the receiving system.
Table 5. Servers running Linux on Power Systems™: Minimum hardware requirements
Requirements Platform Agent Common Agent
Processor speed POWER5 or POWER6 POWER5 or POWER6
Memory (RAM) 128 MB (minimum) 512 MB (minimum)
Disk space for installing the agent 145 MB
210 MB for the temporary space 370 MB 1
490 MB for the temporary space
Additional disk space required when installing the agent using the Agent Installation Wizard 120 MB 420 MB
1 This requirement includes Platform Agent which is installed with Common Agent.
System z servers
Table 6. System z servers: Minimum hardware requirements
Requirement Platform Agent Common Agent Common Agent with CIM instrumentation for z/VM® manageability access point
Processor speed Processor speeds provided by IBM® System z and zSeries® servers are sufficient for IBM Systems Director agents. These models are:
• IBM® System z (System z10™ Enterprise Class, System z9® Enterprise Class, and System z9 Business Class)
• IBM® zSeries (IBM® zSeries 990, 900, 890 and 800)
Memory 512 MB 512 MB 512 MB
Disk space 200 MB 500 MB 200 MB

PORTS:

Important port considerations

When preparing your ports for an IBM® Systems Director environment, there are some important considerations to remember or some IBM Systems Director functions might not work.
Review the following considerations:
• Depending on the system configuration, one of the following port pairings must be open in order to install IBM Systems Director:
• (For Microsoft® Windows® and Red Hat Enterprise Linux®) 5988 and 5989
• (For SUSE Linux Enterprise Server) 15988 and 15989
Some firewalls might attempt to block these ports. Make sure that the IBM Systems Director software components can use these ports. If custom alternative ports are chosen for the CIM Server, then those ports must be opened.
• (Windows only) For any CIM-related function of the Common Agent to work, the HTTP port must be turned on for the Pegasus CIMOM, regardless of whether HTTPS is turned on (SSL is enabled).
• If the CIMOM ports for a Platform-Agent managed system are changed after IBM Systems Director Server discovers the system, the system will change to an Agentless-managed system in IBM Systems Director. To correct this change, you must complete the following steps:
1. Delete the system in IBM Systems Director.
2. Shut down and restart the system.
3. Discover the system in IBM Systems Director.
• Windows firewall can interfere with discovery of managed systems running Windows 2003, Windows 2008, Windows XP, and Windows Vista.
• If a proxy server is required to access the Internet from the management server, make sure that the management server is configured to use the proxy.
• Update manager cannot use Digest or NTLM authentication to access update packages from IBM®. If a proxy server is required, it must be configured to use Basic authentication.
• IBM Systems Director Server can access the Internet through ports 80 (HTTP) and 443 (HTTPS). The firewall and proxy server must permit bi-directional communication through these ports.
• By default, IBM Systems Director uses a random source port for SLP communication through a firewall to a Remote Supervisor Adapter. The random port causes problems when discovering the Remote Supervisor Adapter through a firewall because the Remote Supervisor Adapter responds using that random port. To resolve this problem, open any unused or private port. Then, edit the slp.prop file to use your selected port. The following example uses port 49150:
• # Up to 10 parallel ports can be open at a time
• # when opening firewall ports, configure the source port and open
• # that port and the next 9 consecutive ports
• # default: 0 - random port used
source.port=49150
• Neither z/VM® nor the MAP Agent add any additional ports to those already provided by IBM Systems Director for standard communication. Instead of TCP/IP, z/VM communication APIs are used to communicate with the servers that provide information to IBM Systems Director and to enact any changes to z/VM servers. The communication is by means of sockets and the AF_IUCV address family.
• For the TCP ports listed, the initiator opens a random port in the 1024-65535 range and then connects to the listener on the port listed. The listener responds by connecting to the original random port opened by the initiator.
• For the getfru command to run successfully, the managed system must have firewall access through a standard FTP port.
• The Remote Control, Update Install, and the Agent Installation wizard tasks use session support to increase data transmission. Session support within TCP/IP causes data to flow through a nonreserved port that is different from the one that IBM Systems Director typically uses for communication. Most firewalls will not transmit the data through this other port.

Ports for IBM Systems Director Server

IBM® Systems Director processes require access to a number of ports on the management server. If these ports are blocked by a firewall or used by another process, some IBM Systems Director functions might not work.
Table 1. Ports used by IBM Systems Director Server for communication
Port TCP or UDP Direction Communication description
20 TCP Inbound FTP data communication with BladeCenter® I/O modules (switches and bridges)
21 TCP Inbound FTP communication with BladeCenter I/O modules (switches and bridges)
22 TCP Outbound SSH communication with:
• Advanced management module and management module
• BladeCenter I/O modules
• Platform Agent installed on systems running Linux®, including systems managed by HMC and IVM
• SSH used by IBM Power systems to communicate with HMC/IVM
• Non-Windows Agentless-managed systems
23 TCP, UDP Outbound Telnet communication with:
• Advanced management module, management module, Remote Supervisor Adapter, and Remote Supervisor Adapter II
• BladeCenter I/O modules
• Updates
69 TCP Inbound TFTP communication with BladeCenter I/O modules (switches and bridges)
80 TCP Outbound HTTP communication with:
• IBM Systems Director Web interface
• Advanced management module, management module, Remote Supervisor Adapter, and Remote Supervisor Adapter II
• BladeCenter I/O modules
• IVM interface
• Update manager
81 TCP Outbound HTTPS communication with BladeCenter I/O modules (switches and bridges)
135 TCP, UDP Outbound (Windows® only) Software installation and remote access communication with Platform Agent
137 TCP, UDP Outbound (Windows only) Communication with Agentless-managed systems using Microsoft® Windows DCOM
138 TCP, UDP Outbound (Windows only) Communication with Agentless-managed systems using Windows DCOM
139 TCP, UDP Outbound (Windows only) Communication with Agentless-managed systems using Windows Server Message Block (SMB)
161 UDP Outbound SNMP agent communication with:
• Advanced management module, management module, Remote Supervisor Adapter, and Remote Supervisor Adapter II
• BladeCenter I/O modules
• Platform Agent
Note: This port is used when the SNMP agent for the operating system is configured.
• Agentless-managed systems
Note: This port is used when the SNMP agent for the operating system is configured.
162 TCP, UDP Outbound (TCP, UDP)
Inbound (UDP) Simple Network Management Protocol (SNMP) trap communication with SNMP devices, including TCP for Tivoli® NetView® events. Examples of SNMP devices are advanced management module, management module, Remote Supervisor Adapter, and Remote Supervisor Adapter II.
427 TCP, UDP Outbound and Inbound SLP communication with:
• Advanced management module, management module, Remote Supervisor Adapter, and Remote Supervisor Adapter II
• Common Agent
• Platform Agent
• IBM Director Agent 5.20
• Service Location Protocol (SLP) service agent or SLP directory agent
443 TCP Outbound HTTPS communication with:
• IBM Systems Director Web interface
• Advanced management module and management module
• HMC Web interface
• Updates
445 TCP, UDP Outbound (Windows only) Open on Agentless and Platform-Agent managed systems for the following features:
• Software installation
• Remote access communication
• (Agentless-managed systems only) Inventory collection
446 TCP Outbound Non-SSL communication with the IBM i DRDA/DDM server job
448 TCP Outbound SSL communication with the IBM i DRDA/DDM server job
449 TCP Outbound SSL communication with the IBM i server port mapper
623 UDP Outbound Remote Management and Control Protocol (RMCP) unsecure communication with IPMI baseboard management controller (BMC) service processors
664 UDP Outbound Remote Management and Control Protocol (RMCP) secure communication with IPMI BMC service processors
Random port in the 1024-65535 range TCP Inbound • Random port range for communication between IBM Systems Director Server with Intelligent Platform Management Interface (IPMI) service processors
Note: You can specify a fixed port by modifying the asmDefinitions.properties file in the data directory.
• For the TCP ports listed, the initiator opens a random port in the 1024-65535 range and then connects to the listener on the port listed. The listener responds by connecting to the original random port opened by the initiator.
1433 TCP Outbound and Inbound Microsoft SQL Server databases
1521 TCP Outbound and Inbound Oracle® Database databases
1527 TCP Outbound and Inbound Apache Derby databases
2033 TCP Inbound Communication with the IBM Systems Director Launched Tasks program using IBM Systems Director interprocess communication (IPC)
2044 TCP Outbound and Inbound smcli command-line interface
Note: This port number can be changed. See "Port configuration for smcli."
3389 TCP Outbound and Inbound Remote Desktop Protocol, Remote Desktop Connection, or Remote Accessor for full screen access to systems running Windows
4066 TCP Inbound Communication with the IBM Systems Director Launched Tasks program using IBM Systems Director interprocess communication (IPC) over SSL
5901 TCP Outbound and Inbound Virtual Network Computing (VNC), used by Remote Access
5988 TCP Inbound (Windows and Red Hat Enterprise Linux) CIM Server unsecure port
5989 TCP Inbound • (Windows and Red Hat Enterprise Linux) CIM Server secure port
• HMC/IVM CIMOM
6641 TCP Inbound SAS switches
6988 TCP Inbound CIM listener
6989 TCP Inbound CIM listener
6090 TCP Outbound TCP Command Mode communication between IBM Systems Director Server and advanced management module, management module, Remote Supervisor Adapter, and Remote Supervisor Adapter II
8421 TCP Inbound • (All operating system platforms) HTTP communication between IBM Systems Director Server and the IBM Systems Director Web interface
• HTTP used by IBM Power systems to communicate with CIM
8422 TCP Inbound • (All operating system platforms) HTTPS communication between IBM Systems Director Server and the IBM Systems Director Web interface
• HTTPS used by IBM Power systems to communicate with CIM
8470 TCP Outbound Non-SSL communication with the IBM i central server job
8471 TCP Outbound Non-SSL communication with the IBM i database server job
8472 TCP Outbound Non-SSL communication with the IBM i data queue server job
8473 TCP Outbound Non-SSL communication with the IBM i file server job
8474 TCP Outbound Non-SSL communication with the IBM i network print server job
8475 TCP Outbound Non-SSL communication with the IBM i remote command and distributed program call server job
8476 TCP Outbound Non-SSL communication with the IBM i signon server job
9000–9100 TCP Communication Platform-Agent managed system running Xen
9470 TCP Outbound SSL communication with the IBM i central server job
9471 TCP Outbound SSL communication with the IBM i database server job
9472 TCP Outbound SSL communication with the IBM i data queue server job
9473 TCP Outbound SSL communication with the IBM i file server job
9474 TCP Outbound SSL communication with the IBM i network print server job
9475 TCP Outbound SSL communication with the IBM i remote command and distributed program call server job
9476 TCP Outbound SSL communication with the IBM i signon server job
9510 TCP Inbound, Outbound Communication with Common Agent and CAS Web services
9511–9513 TCP Inbound Agent manager
9514–9515 TCP Nonstop ports that are used to make sure Common Agent is restarted automatically if it fails.
Note: Ports must be available, but not firewall accessible.
10000 Events from storage devices
13991 UDP Inbound Receives events sent by advanced management module, management module, Remote Supervisor Adapter, and Remote Supervisor Adapter II
14247 UDP Inbound IBM Systems Director interprocess communication (IPC) with IBM Director Agent 5.20
14248 UDP Outbound IBM Systems Director interprocess communication (IPC) with IBM Director Agent 5.20
14251 UDP Inbound IBM Systems Director Server interprocess communication (IPC) support
20000 TCP Inbound • CAS events
• Communication with VMware
Note: If you plan to manage systems running VMware VirtualCenter, or VMware ESX Server, see the VMware documentation to make sure port requirements are met: www.vmware.com/support/pubs/

50000 TCP Both IBM DB2® Universal Database™ databases

Ports for managed systems (Client )
IBM® Systems Director processes require access to a number of ports on managed systems. Managed systems include Common-Agent managed systems, Platform-Agent managed systems, and Agentless-managed systems.
Table 1. Ports on managed systems
Port TCP or UDP Direction Communication description
22 TCP Inbound SSH communication with:
• Advanced management module and management module
• BladeCenter® I/O modules
• Platform Agent installed on systems running Linux®, including systems managed by HMC and IVM
• SSH used by IBM Power systems to communicate with HMC/IVM
• Non-Windows Agentless-managed systems
135 TCP, UDP Inbound (Windows® only) Software installation and remote access communication with Platform Agent
137 TCP, UDP Inbound (Windows only) Communication with Agentless-managed systems using Microsoft® Windows DCOM
138 TCP, UDP Inbound (Windows only) Communication with Agentless-managed systems using Windows DCOM
139 TCP, UDP Inbound (Windows only) Communication with Agentless-managed systems using Windows Server Message Block (SMB)
161 UDP Inbound SNMP agent communication with:
• Advanced management module, management module, Remote Supervisor Adapter, and Remote Supervisor Adapter II
• BladeCenter I/O modules
• Platform Agent
Note: This port is used when the SNMP agent for the operating system is configured.
• Agentless-managed systems
Note: This port is used when the SNMP agent for the operating system is configured.
427 TCP, UDP Outbound and Inbound SLP communication with:
• Advanced management module, management module, Remote Supervisor Adapter, and Remote Supervisor Adapter II
• Common Agent
• Platform Agent
• IBM Director Agent 5.20
• Service Location Protocol (SLP) service agent or SLP directory agent
445 TCP, UDP Inbound (UDP) (Windows only) Open on Agentless and Platform-Agent managed systems for the following features:
• Software installation
• Remote access communication
• (Agentless-managed systems only) Inventory collection
5988 TCP Inbound (Windows and Red Hat Enterprise Linux) CIM Server unsecure port
5989 TCP Inbound • (Windows and Red Hat Enterprise Linux) CIM Server secure port
• HMC/IVM CIMOM
6988 TCP Inbound CIM listener
6989 TCP Outbound CIM listener
9510 TCP Inbound Communication with Common Agent and CAS Web services
14247 UDP Inbound IBM Systems Director interprocess communication (IPC) with IBM Director Agent 5.20
14248 UDP Outbound IBM Systems Director interprocess communication (IPC) with IBM Director Agent 5.20
15988 TCP Inbound • (For SUSE Linux Enterprise Server) CIM Server (alternative secure port) communication with Platform-Agent managed system
• Service processor communication with SUSE Linux Enterprise Server 10.
• CIM Server (alternative unsecure port) communication with Platform-Agent managed system
15989 TCP Inbound (For SUSE Linux Enterprise Server) CIM Server (alternative secure port) communication with Platform-Agent managed system
20000 TCP Outbound • CAS events
• Communication with VMware
Note: If you plan to manage systems running VMware VirtualCenter, or VMware ESX Server, see the VMware documentation to make sure port requirements are met: www.vmware.com/support/pubs/

Network requirements

IBM® Systems Director requires certain ports to be available and certain network protocols to be installed in order to enable communication among IBM Systems Director components and between the management server and managed systems. In addition, network connectivity must exist between the management server and managed systems, and between the management server and the IBM Systems Director Web interface browser system.
Nameserver (DNS) requirements

Ensure that the nameserver is configured correctly. If the nameserver is not configured correctly, you will encounter problems and potential failure during IBM Systems Director installation.
The following conditions indicate that the nameserver is configured correctly:
• The nameserver address or addresses are correct for your network environment.
• You are able to connect to valid hosts on the network and validate that the connection occurs within a reasonable amount of time.
• All available ports
IBM Systems Director processes require access to a number of ports in the installation and systems-management environment. If these ports are blocked by a firewall or used by another process, some IBM Systems Director functions might not work.

Security requirements
IBM® Systems Director Server supports several products to house the registry used for system security.
User registry products and types
One of the following locations must contain the registry that IBM Systems Director uses for user authentication:
Operating system
The local operating system user registry is the default registry used by IBM Systems Director security.
LDAP
IBM Systems Director includes Lightweight Directory Access Protocol (LDAP) authentication support. LDAP support is disabled by default. The following LDAP servers are supported:
• IBM® Tivoli® Directory Server
• Microsoft® Active Directory
Active directory
The active directory, which is the same as the Microsoft Active Directory, acts as an LDAP server or domain controller. It supports the following types of users and groups:
• Global
• Domain
• Local
• Trusted
Ensure that the IBM Systems Director server is a member of the active directory domain.

IBM Systems Director task support by operating system and agent levels

Some IBM® Systems Director tasks are supported on certain operating systems or only on Platform-Agent managed systems or Common-Agent managed systems. For tasks whose support is not affected in this way, see "IBM Systems Director task support not affected by operating systems."
Support for IBM Systems Director tasks can vary depending on the following items:
• The system or hardware device model (the resource)
• The operating system that is installed on a resource
• The service processor installed in the managed system
• The level of the device drivers that are installed on the managed system
Attention: The device drivers that are available for a managed system depend on the service processor and operating system that are installed on the managed system.
• The level of IBM Systems Director support installed on the system or device. In Table 1, the following symbols are used:
• IBM Systems Director Server indicates the task is supported by IBM Systems Director Server.
• Level 0 indicates the task support is provided by the operating system.
• Level 1 indicates the task is supported for managed resources with Platform Agent installed.
• Level 2 indicates the task is supported for managed resources with Common Agent installed.
Note: Typically, if a task is supported by Common Agent, it is also supported by IBM Director Agent version 5.20. However, support can vary for tasks that update systems or provide cross-platform support:
• IBM i support is provided by IBM Director Agent 5.20 only.
• The Agent Installation Wizard can be used to install subagents only on Common-Agent managed system.
• (Configuration manager) Only operating system configuration plug-ins are supported by Common Agent and IBM Director Agent version 5.20.
• (Update manager) Updates on System x and IBM BladeCenter® systems and the IBM i operating system are supported by Common Agent and IBM Director Agent version 5.20. All other types of updates are supported by Common Agent only.
• (Update manager) Updates on AIX®, Linux® on Power Systems™, and Linux for System z are available only with Common Agent. The ability to distribute Linux updates is only available for Common Agent on Linux.
• (Virtualization manager) IBM Director Agent version 5.20 requires a separate download and installation of the Virtualization Manager extension.
Table 1. IBM Systems Director task support across operating systems
Task Operating systems
AIX IBM i Linux Microsoft® Virtual Server VMware Windows®
Event Log IBM Systems Director Server, Level 2 Levels 1, 2 IBM Systems Director Server, Levels 1, 2 Levels 1, 2 Levels 01, 1, 2
IBM Systems Director Server, Levels 1, 2
File Transfer IBM Systems Director Server, Level 2 Level 2 IBM Systems Director Server, Level 2 Level 2 Level 22
IBM Systems Director Server, Level 2
Inventory (hardware)3
IBM Systems Director Server, Level 2 Levels 1, 2 IBM Systems Director Server, Levels 0, 1, 24
Levels 0, 1, 2 Levels 01, 1, 2
IBM Systems Director Server, Levels 0, 1, 24

Inventory (software) IBM Systems Director Server, Levels 0, 2 Levels 0, 1, 25
IBM Systems Director Server, Levels 0, 1, 2 Levels 0, 1, 2 Levels 0, 1, 2 IBM Systems Director Server, Levels 0, 1, 2
Problems (formerly Hardware Status)6
Level 2 Level 2 7
Levels 1, 2 8, 7
Levels 1, 2 9
Levels 1, 2 10
Levels 1, 2
Process Management IBM Systems Director Server, Level 2 Level 2 IBM Systems Director Server, Level 2 Level 2 11
Level 2 11
IBM Systems Director Server, Level 2
Remote Control IBM Systems Director Server, Levels 0, 2 IBM Systems Director Server, Levels 0, 1, 2 Level 2 Levels 0, 1, 212
IBM Systems Director Server, Levels 0, 1, 2
Remote Command Line IBM Systems Director Server, Levels 0, 2 Levels 0, 1, 2 IBM Systems Director Server, Levels 013, 113, 2 Level 2 Levels 0, 1, 2 IBM Systems Director Server, Level 2
Resource Monitors IBM Systems Director Server, Level 2 Levels 1, 2 IBM Systems Director Server, Levels 1, 2 Console only 14
Console only 14
IBM Systems Director Server, Levels 1, 2
Storage Configuration Manager IBM Systems Director Server IBM Systems Director Server, Levels 1, 28, 15
Levels 1, 2 Levels 1, 2 IBM Systems Director Server, Levels 1, 2 16

Update Manager IBM Systems Director Server, Levels 217
Levels 1, 218
IBM Systems Director Server, Levels 0, 1, 217
Levels 1, 2 19
Levels 1, 219
IBM Systems Director Server, Levels 0, 1, 2 17

tes:
1. Agentless-managed system support is available for VMware ESX Server 3i only.
2. File systems that are displayed for the guest operating system are limited to file systems within its virtual disk.
3. Inventory data provided can vary among Agentless, Platform-Agent, and Common-Agent managed systems.
4. Hardware-platform-specific data is not available for hardware inventory.
5. Software Catalog Signatures not supported
6. Unless otherwise indicated, this task is supported (although the support might be limited) by:
• Out-of-band notifications generated by the service processor
• CIM indications generated by Platform Agent or Common Agent
7. IBM BladeCenter JS21 and JS22 only: Out-of-band notifications generated by a service processor only.
8. Not supported on System z systems.
9. Limited support only.
10. VMware support for the Problems task has the following limitations:
• No support for Platform Agent or Common Agent on VMware ESX Server 3i (Embedded and Installable Editions) although enhanced Agentless support includes Problems support.
• Support is limited for guest operating systems.
• Support for console is limited to out-of-band notifications generated by a service processor or in-band events generated by CIM (CIM support is system specific).
11. Supported on guest operating systems only.
12. Supported on Windows guest operating systems only.
13. Supported for Linux on Power Systems only.
14. Limited support provided by virtualization manager.
15. Not supported for Linux on Power Systems.
16. The IBM BladeCenter SAS RAID Controller Module function is not supported on Windows Server 2008.
17. For detailed information about hardware and operating system support provided by update manager, see "Supported updates."
18. On IBM i 5.4 or later, update manager support is provided for IBM Director Agent 5.20.
19. On guest operating systems, support is provided for Linux updates and IBM Systems Director agent updates only.

Preparing the management server

Before installing IBM® Systems Director Server, make sure that the requirements that are applicable to your system have been met.

Preparing firewalls and proxies for IBM Systems Director

If you have firewalls in your network, or if the management server must use a proxy server to access the internet, you must configure the firewalls and proxy server to enable installation and operation of IBM® Systems Director.
IBM Systems Director must be able to access all the managed objects in the network, and if you will be using a remote management console, the management console and management server must have access to each other. In addition, some functions of IBM Systems Director require access to the internet.
To enable this access, you must configure firewalls and proxies in your network to allow access by IBM Systems Director components.
Complete the following steps to configure firewalls and proxies in your network:
1. Identify the ports that you will use in your systems-management environment and ensure that those ports are open before you start installation. For example, you must ensure that the listener ports for IBM Systems Director Server and Common Agent are open. See "All available ports" for a complete list of the ports that IBM Systems Director components can use.
2. Ensure that internet connections exist to the following internet addresses as they are required by IBM Systems Director and various plug-ins.
Note: IP addresses are subject to change, so the use of DNS names is strongly recommended.
Table 1. Required internet connections
DNS name IP address Port(s) Protocol(s)
Update manager
www.ibm.com 129.42.56.216, 129.42.58.216, 129.42.60.216 443 or 80 https or http
www-03.ibm.com 204.146.30.17 443 or 80 https or http
download2.boulder.ibm.com 207.25.253.8 80 http
download3.boulder.ibm.com 207.25.253.76 80 http
Service and Support Manager
eccgw01.boulder.ibm.com 207.25.252.197 443 https
eccgw02.rochester.ibm.com 129.42.160.51 443 https
www-945.ibm.com 129.42.26.224, 129.42.34.224, 129.42.42.224 443 https
www6.software.ibm.com 207.25.253.41 443 https
www.ecurep.ibm.com 192.109.81.20 443 https
3. If a proxy server is required to access the Internet from the management server, complete the following steps to configure the management server to use the proxy when accessing the Internet.
a. Configure the proxy server to use basic authentication if it is configured for digest or NTLM authentication. The update manager task supports only basic authentication with the proxy server. If digest or NTLM authentication are required, update manager will be unable to access update packages from IBM®.
b. Configure the management server to use the proxy server, if a proxy is required to access the Internet. IBM Systems Director requires Internet access for some functions, including update manager.
Parent topic: Preparing the management server
Previous topic: Preparing the database application
Next topic: Installing firmware and device drivers

Installing firmware and device drivers
Before installing IBM® Systems Director on Red Hat Enterprise Linux®, SUSE Linux, VMware ESX Server, Windows® Server 2003, or Windows Server 2008, you need to install the latest firmware and device drivers for IBM service processors and ServeRAID controllers. To accomplish this, you can either use the IBM UpdateXpress System Pack Installer (UXSPi) or you can install the files manually.
Decide the level of agent management that is required for your system. See "Choosing the management level for managed systems" for information.
RSA II notes for installing on Linux:
• The RSA II daemon requires the libusb and libusb-devel packages, which are typically installed by default. If your distribution or installation does not include or install these packages, you must install them prior to installing the RSA II daemon.
• If you are running Linux, the RSA II daemon requires that you configure RSA II for “Linux OS” prior to installation. Change this setting through the RSA II Web management interface or through a setting found in the system BIOS setup utility.
To install the latest firmware and device drivers for IBM service processors and ServeRAID controllers and ServeRAID Manager plug-ins, it is recommended to use the IBM UpdateXpress System Pack Installer (UXSPi). The UXSPi will automatically install the latest BIOS, IPMI baseboard management controller (BMC), Remote Supervisor Adapter II (RSA II), ServeRAID, and other firmware as required for your server. It will also automatically install the required IPMI device drivers for the BMC and the RSA Server Software for the RSA II. See the IBM Systems support Web site at http://www.ibm.com/systems/support/ and select the appropriate UpdateXpress System Pack Library to download the recommended firmware and drivers for your system.
If you choose to not use the UpdateXpress System Pack Installer, perform the following steps to download and install the latest firmware and device driver files for your Red Hat Enterprise Linux, SUSE Linux, or VMware ESX Server system.
Notes:
• These steps apply to only Red Hat Enterprise Linux, SUSE Linux, or VMware ESX Server systems, though the steps that are required for Windows systems are similar.
• See "Preparing to manage service processors with IBM Director" for more information about service processors.
• If your system contains an Integrated systems management processor (ISMP), you need to instead install LM78 and SMBus drivers. See "Installing the IBM LM78 or SMBus device driver" for information.
1. Install the latest firmware for BMC service processors.
a. Download into a temporary directory the ibm_fw_bmc_XXXXXXX_linux_i386.sh BMC firmware file from http://www.ibm.com/systems/support/. This file is available for all supported Red Hat Enterprise Linux, SUSE Linux, and VMware ESX operating systems, so download the version that applies to your system.
b. Navigate to the temporary directory into which you downloaded the file.
c. Use a console prompt from the temporary directory to run the following command:
./ibm_fw_bmc_XXXXXXX_linux_i386.sh -s -a -s
2. Install the latest daemon for the RSA II service processors.
a. Download into a temporary directory the ibm_svc_rsa2_XXXXXXX_linux_32-64.tgz RSA II daemon file from http://www.ibm.com/systems/support/. This file is available for all supported Red Hat Enterprise Linux, SUSE Linux, and VMware ESX operating systems, so download the version that applies to your system.
b. Navigate to the temporary directory into which you downloaded the file.
c. Use a console prompt from the temporary directory to run the following commands:
d. tar xzf ibm_svc_rsa2_XXXXXXX_linux_32-64.tgz
export PATH=$PATH:/usr/local/bin;./install.sh --update
3. Install the latest firmware for the RSA II service processors.
a. Download into a temporary directory the ibm_fw_rsa2_XXXXXXX_linux_i386.sh RSA II firmware file from http://www.ibm.com/systems/support/. This file is available for all supported Red Hat Enterprise Linux, SUSE Linux, and VMware ESX operating systems, so download the version that applies to your system.
b. Navigate to the temporary directory into which you downloaded the file.
c. Use a console prompt from the temporary directory to run the following commands:
d. tar xzf ibm_fw_rsa2_XXXXXXX_linux_i386.sh
export PATH=$PATH:/usr/local/bin;./install.sh --update -force-if-overridden
4. Install the latest firmware and device drivers for ServeRAID controllers.
a. Download into a temporary directory the following individual files that are required for your servers from http://www.ibm.com/systems/support/.
Note: The firmware packages apply to all Linux and VMware ESX distributions, but you must download the appropriate device driver for your particular distribution.
Table 1. Required ServeRAID controller firmware and device driver files
Item Files RHEL AS 4 U6 32-bit RHEL AS 4 U6 64-bit RHEL AS 5 U1 32-bit RHEL AS 5 U1 64-bit SLES 9 32-bit SLES 9 64-bit SLES 10 32-bit SLES 10 64-bit VMware ESX
ServeRAID MR 10 Device driver (systems with ServeRAID 10 hardware) ibm_dd_sraidmr_XXXXXXXX_rhel4_32-64.tgz X X
ibm_dd_sraidmr_XXXXXXXX_rhel5_32-64.tgz X X
ibm_dd_sraidmr_XXXXXXXX_sles9_32-64.tgz X X
ibm_dd_sraidmr_XXXXXXXX_sles10_32-64.tgz X X
ServeRAID MR 10 Firmware (systems with ServeRAID 10 hardware) ibm_fw_sraidmr_XXXXXXXXXXX_linux_32-64.bin X X X X X X X X X
ServeRAID 8 Device driver (systems with ServeRAID 8 hardware) ibm_dd_aacraid_XXXXXXXXXXX_rhel4_32-64.tgz X X
ibm_dd_aacraid_XXXXXXXXXXX_rhel5_32-64.tgz X X
ibm_dd_aacraid_XXXXXXXXXXX_sles9_32-64.tgz X X
ibm_dd_aacraid_XXXXXXXXXXX_sles10_32-64.tgz X X
ServeRAID 8 Firmware (systems with ServeRAID 8 hardware) ibm_fw_aacraid_8k-8kl-X.X.X-XXXXX_linux_32-64.bin X X X X X X X X X
b. Navigate to the temporary directory into which you downloaded the files.
c. Use a console prompt from the temporary directory to run the installation command for each of the downloaded files. Use the following installation command examples as guides:
Example: ServeRAID8 on RHEL5
tar xzf ibm_dd_aacraid_1.1.5.2434_sles10_32-64.tgz
export PATH=/usr/local/bin:$PATH ; ./install.sh --update
./ibm_XX_aacraid_XXXXXXXXXXX_XXXX_XXX.bin -s
Example: ServeRAID10 on RHEL5
tar xzf ibm_dd_sraidmr_XXXXXXXX_rhel5_32-64.tgz
export PATH=/usr/local/bin:$PATH ; ./install.sh --update
./ibm_fw_sraidmr_XXXXXXXXXXX_linux_32-64.bin -s
Preparing to install IBM Systems Director Server on AIX
Before installing IBM® Systems Director Server on AIX®, make sure that your management server meets the applicable requirements.
Complete the following preparatory steps before installing IBM Systems Director Server on AIX:
1. Ensure that your system meets the hardware and software requirements (including those for databases, security, and networking) for installation, as described in "Hardware and software requirements." To verify the AIX operating system level, run the following command:
oslevel -s
The command should return a value such as 5300-06-04-nnn, where nnn is irrelevant.
2. Optional: Download updates for your system, if necessary. Download AIX operating system updates from the "IBM® Fix Central" Web site.
Note: Select "Power" or "System p®" for the Product family and "AIX" for the Product.
3. Ensure that the following required openssl and openssh versions are installed:
• openssl.base 0.9.8.4 or higher
• if installed, openssh.base.server 4.5.0.5301 or higher
There is a dependency between openssl and openssh versions. If openssl is not installed, it is installed as part of the server installation. However, if this would create an inconsistency with the openssh version on the system, openssl is not installed and the server installation fails.
Note: If you want to run the Agent Installation Wizard from the server, openssh is required. However, the server installation does not enforce openssh installation.
4. Note the following list of required RPM files that are installed as part of the IBM Systems Director Server installation:
• bash-3.2-1
• expect-5.42.1-1
• tcl-8.4.7-1
• tk-8.4.7-1
Note: The tk rpm requires that the X11.base.lib file set is also installed. You can find X11.base.lib, along with its X11 installation requisites, on the AIX base installation media.
5. Ensure that the following file sets that are required for and installed with Common Agent on AIX will not conflict with any other applications that are installed on your system:
• sysmgt.cim.providers 1.2.7.35
• sysmgt.cim.smisproviders 1.2.0.35
• sysmgt.cimserver.pegasus 2.6.1.35
• ICU4C.rte 5.3.0.60 (only AIX 5.3 systems)
• xlC.aix50 9.0.0.0 (only AIX 5.3 systems)
• xlC.rte 9.0.0.0 (only AIX 5.3 systems)
6. Ensure that the installation is set to use ports that are not already in use. By default, Common Agent requires ports 9510, 9514, and 9515 during installation and at runtime. If these ports are already in use when you install the agent, the installation will fail. A situation where these ports will be already in use is if you have a different version of the CAS agent installed, for example as part of the Tivoli® Provisioning Manager agent.
Complete the following steps to check for port use and, if any are in use, modify the Common Agent configuration to use different ports:
a. Check if the ports are in use by running the following command:
netstat -an | grep LISTEN | egrep "951(0|4|5)"
b. On the agent system, modify the configuration to use different ports by running the following command:
c. /var/opt/tivoli/ep/runtime/agent/toolkit/bin/configure.sh -unmanaged -port
not_9510 -jport not_9514 -nport not_9515 -force
where not_951x is any open port other than 951x.
d. Rerun the installation script or install the Common Agent file set manually.
7. Optional: If you want to use the FSP Proxy extension, which is necessary for the Power Management tasks for standalone and IVM-managed hosts, ensure that the following necessary file sets are installed.
Note: IBM Systems Director Server no longer automatically installs these file sets to prevent possible installation inconsistencies with CSM.
csm.hc_utils 1.7.0.0 or 1.7.0.10, and csm.hc_utils 1.7.0.13 or higher along with its CSM install requisites
The CSM file set versions 1.7.0.0 and 1.7.0.10 are included on the AIX operating system media. Download the csm_hc.utils 1.7.0.13 file set, which is included in CSM 1.7.0.16, as part of the CSM package from the IBM Cluster Systems Management Web site at http://www14.software.ibm.com/webapp/set2/sas/f/csm/download/home.html. Install each file set with SMIT or the following command:
installp -acgXYd fileset_location fileset_name
where fileset_location is the location of the downloaded file sets and fileset_name is the name of the file set that you are installing.
Director.Server.ext.FSPProxy.rte
Obtain this file set from the IBM Systems Director DVD or the SysDir6_1_Server_AIX.tar.gz and SysDir6_1_Agent_Server_Installp_AIX.tar.gz files. Install the file set with SMIT or the following command:
installp -acgXYd fileset_location Director.Server.ext.FSPProxy.rte
where fileset_location is the location of the downloaded file set.

Preparing to install IBM Systems Director Server on Linux on Power Systems
Before installing IBM® Systems Director Server on Linux® on Power Systems™, make sure that your platform meets the applicable requirements.
Review the following information and complete the necessary steps to prepare your system for installation:
• Ensure that your system meets the hardware and software requirements (including those for databases, security, and networking) for installation, as described in "Hardware and software requirements."
• SUSE Linux Enterprise Server 9 on IBM Power Systems and SUSE Linux Enterprise Server 10 on IBM Power Systems only: Disable the Service Location Protocol daemon (SLPD) before installing Platform Agent. IBM Systems Director Server does not discover a managed system with Platform Agent installed when the managed system is running SLPD.
• Ensure that the required RPM files (or later versions) are installed. To check for the fileset, type the following command and press Enter:
rpm -qa | grep
where is the value in the "Required RPMs" column but without the ppc.rpm or ppc64.rpm extension.
Table 1. Required RPMs for Linux on Power Systems
Installation scenario Required RPMs
Red Hat Enterprise Linux AS, version 4.0 for IBM Power compat-libstdc++-.ppc.rpm1
diagela-2.2.2-0.ppc64.rpm2
librtas-1.3.3-0.ppc64.rpm2
lsvpd-0.15.1-1.ppc.rpm2, 3
powerpc-utils-papr-1.0.3-1.ppc64.rpm2
servicelog-0.2.9-0.ppc64.rpm2
expect-5.42*.rpm
Red Hat Enterprise Linux AS, version 5.0 on IBM Power systems compat-libstdc++-.ppc.rpm1
diagela-2.2.2-0.ppc64.rpm2
librtas-1.3.3-0.ppc64.rpm2
lsvpd-0.15.1-1.ppc.rpm2, 3
ppc64-utils-.ppc64.rpm1
servicelog-0.2.9-0.ppc64.rpm2
expect-5.42*.rpm
SUSE Linux Enterprise Server 9 on IBM Power Systems and SUSE Linux Enterprise Server 10 on IBM Power Systems compat-libstdc++-.ppc.rpm1
diagela-2.2.2-0.ppc64.rpm2
librtas-1.3.3-0.ppc64.rpm2
lsvpd-0.15.1-1.ppc.rpm2, 3
powerpc-utils-.ppc64.rpm1
servicelog-0.2.9-0.ppc64.rpm2
expect-5.42*.rpm
• 1 Obtain this RPM from the operating system distribution media.
• 2 Obtain this RPM from the IBM® Service and productivity tools for Linux on Power Systems Web site at www14.software.ibm.com/webapp/set2/sas/f/lopdiags/home.html. Select the appropriate tab for your Linux distribution and follow any special instructions for each RPM.
• 3 If the lsvpd RPM installed on the managed system is at level lsvpd-0.15.1-1, some inventory tables might not show inventory data. To resolve this issue, install lsvpd-1.3 or higher.
Note: Obtain the lsvpd RPM level lsvpd-1.3 or higher from the "SourceForge.net" Web site.
• Obtain the SUSE/Novell Expect RPM from the SUSE/Novell updates Web site at https://ftp3.linux.ibm.com/suse_updates.html. Obtain the Red Hat Enterprise Linux Expect RPM from the Red Hat Enterprise Linux Updates Web site at https://ftp3.linux.ibm.com/redhat_updates.html.
• If you plan to run the Agent Installation Wizard from the server, ensure that openssh is installed.
Note: The server installation does not enforce openssh installation.
• Ensure that SELinux is not set to enforce security policies prior to installing IBM Systems Director.
If your server runs Red Hat Enterprise Linux version 4 or 5, SELinux might be enabled and enforcing security policies on your system. IBM Systems Director Common Agent might have trouble if SELINUX is set to enforcing. Therefore, before you install IBM Systems Director Common Agent, you must set the SELinux policy to permissive.
SELinux runs in any of the following states:
Disabled
SELinux is disabled. You can tell that SELinux is in the disabled state by determining if any of the following conditions are true:
• No files exist in the /selinux/ directory.
• The SELINUX variable in /etc/selinux/config is set to disabled.
Permissive (enabled)
SELinux is enabled but not enforcing any security policies. You can tell that SELinux is in the permissive state by determining if any of the following conditions are true:
• The SELINUX variable in /etc/selinux/config is set to permissive.
• When you run the cat /selinux/enforce; echo command, it outputs a 0.
Note: The echo after the cat command is required so you can read what is printed out by /selinux/enforce.
Enforcing (enabled)
SELinux is enabled and enforcing security policies. You can tell that SELinux is in the enforcing state by determining if any of the following conditions are true:
• The SELINUX variable in /etc/selinux/config is set to enforcing.
• When you run the cat /selinux/enforce; echo command, it outputs a 1.
Note: The echo after the cat command is required so you can read what is printed out by /selinux/enforce.
To set SELinux to permissive, run the following command before you install IBM Systems Director Common Agent:
/usr/sbin/setenforce Permissive
• Optional: If you want to use the FSP Proxy extension, which is necessary for the Power Management tasks for standalone and IVM-managed hosts, ensure that the following necessary file sets are installed.
Note: IBM Systems Director Server no longer automatically installs these file sets to prevent possible installation inconsistencies with CSM.
csm.hc_utils-1.7.0.16-nnn.rpm or higher
Download this file set as part of the CSM package from the IBM Cluster Systems Management Web site at http://www14.software.ibm.com/webapp/set2/sas/f/csm/download/home.html. Install the file set with the following command:
rpm -Uvh csm.hc_utils-1.7.0.16-nnn.rpm
where nnn represents the build number.
src-1.3.0.4-08nnn.ppc.rpm
Download this file set as part of the CSM package from the IBM Cluster Systems Management Web site at http://www14.software.ibm.com/webapp/set2/sas/f/csm/download/home.html. Install the file set with the following command:
rpm -Uvh src-1.3.0.4-08nnn.ppc.rpm
where nnn represents the build number.
FSPProxyServerExt-5.20.3-1_platform.rpm
Obtain this file set from the IBM Systems Director DVD or the SysDir6_1_Server_Linux_Power.tar.gz file. Install the file set with the following command:
rpm -Uvh FSPProxyServerExt-5.20.3-1_platform.rpm
where platform represents the platform.

Operating systems supported by IBM Systems Director 6.1.0

IBM® Systems Director 6.1.0 provides support for many operating systems. However, support varies depending on the selected hardware and IBM Systems Director component.
Purpose

This little command copies things.

DITA

Starting in version 6.1, IBM Systems Director provides a Web interface for use with IBM Systems Director Server. IBM Director Console is no longer required. However, some tasks in the Web interface require the IBM Systems Director Launched Tasks program. For information about the IBM Systems Director Launched Tasks program and the tasks that require it, see "Launched tasks and the IBM Systems Director Launched Tasks program." For operating-system support, see "Operating systems supported by the IBM Systems Director Launched Tasks program."
When preparing to install IBM Systems Director, consider the following information:
• Platform Agent, version 6.1.0 and IBM Director Core Services version 5.20.3 are the same agent.
• Unless stated otherwise, IBM Systems Director provides agentless support for all operating systems listed in this topic.
Table 1. Windows versions supported by IBM Systems Director on System x systems; IBM® and third-party x86-based systems
Operating system IBM Systems Director Server Common Agent Platform Agent
Editions of Windows® for 32-bit systems:
Windows Server 2003 Datacenter Edition, Release 2 X X
Windows Server 2003, Enterprise and Standard Editions, Release 2 X X X
Windows Server 2003 Datacenter Edition (supports Service Pack 2) X X
Windows Server 2003, Enterprise and Standard Editions (supports Service Pack 2) X X X
Windows Server 2008 Datacenter Edition (supports Service Pack 1) X X
Windows Server 2008, Enterprise and Standard Editions (supports Service Pack 1) X X X
Windows Vista, Business, Enterprise, and Ultimate Editions X X
Windows XP Professional Edition (supports Service Packs 1 and 2) X X
Editions of Windows for 64-bit systems:
Windows Server 2003 Datacenter x64 Edition, Release 2 (supports Service Pack 2) X X
Windows Server 2003, Enterprise and Standard x64 Editions, Release 2 (supports Service Pack 2) X X X
Windows Server 2003 Datacenter x64 Edition (supports Service Pack 2) X X
Windows Server 2003, Enterprise and Standard x64 Editions (supports Service Pack 2) X X X
Windows Server 2008 Datacenter x64 Edition (supports Service Pack 1) X X
Windows Server 2008, Enterprise and Standard x64 Editions (supports Service Pack 1) X X X
Windows Vista, Business, Enterprise, and Ultimate x64 Editions X X
Windows XP Professional x64 Edition (supports Service Packs 1 and 2) X X
Other editions of Windows operating systems:
Microsoft® Virtual Server (guest operating system) (Release 2 required, supports Service Pack 1)
Note: Supported guest operating systems are those that are supported by both IBM Systems Director and the specified version of Microsoft. See the Microsoft product documentation for a list of supported operating systems. X X
Table 2. Linux versions supported by IBM Systems Director on System x systems; IBM® and third-party x86-based systems
Operating system IBM Systems Director Server Common Agent Platform Agent
Versions of Linux® for 32-bit systems:
Red Hat Enterprise Linux AS, version 4.0 (supports Updates 5, 6, and 7) X X X
Red Hat Enterprise Linux ES and WS, version 4.0 (supports Updates 5, 6, and 7) X X
Red Hat Enterprise Linux AS, version 5.0 (supports Updates 1 and 2) X X X
Red Hat Enterprise Linux ES and WS, version 5.0 (supports Updates 1 and 2) X X
Red Hat Enterprise Linux AS, ES, and WS, version 5.0, with Xen Kernel (supports Updates 1 and 2) X
SUSE Linux Enterprise Server 9 for x86 (supports Service Packs 3 and 4) X X X
SUSE Linux Enterprise Server 10 for x86 (supports Service Packs 1 and 2) X X X
SUSE Linux Enterprise Server 10, with Xen Kernel (supports Service Packs 1 and 2) X
VMware ESX Server, versions 3.0, 3.0.1, 3.0.2, 3.5, 3.5.1, and 3.5.2, Console X X
VMware ESX Server, versions 3.0, 3.0.1, 3.0.2, 3.5, 3.5.1, and 3.5.2, guest operating systems
Notes:
1. Supported guest operating systems are those that are supported by both IBM Systems Director and the specified version of VMware. See the VMware product documentation for a list of supported operating systems.
2. IBM Systems Director Server is supported on VMware ESX Server if IBM Systems Director Server is supported on the selected guest operating system. X X X
Versions of Linux for 64-bit systems:
Red Hat Enterprise Linux AS, version 4.0, for AMD64 and EM64T (supports Updates 5, 6, and 7) X X X
Red Hat Enterprise Linux ES and WS, version 4.0, for AMD64 and EM64T (supports Updates 5, 6, and 7) X X
Red Hat Enterprise Linux AS, version 5.0, for AMD64 and EM64T (supports Updates 1 and 2) X X X
Red Hat Enterprise Linux ES and WS, version 5.0, for AMD64 and EM64T (supports Updates 1 and 2) X X
Red Hat Enterprise Linux AS, ES, and WS, version 5.0, for AMD64 and EM64T, with Xen Kernel (supports Updates 1 and 2) X
SUSE Linux Enterprise Server 9 for AMD64 and EM64T (supports Service Packs 3 and 4) X X X
SUSE Linux Enterprise Server 10 for AMD64 and EM64T (supports Service Packs 1 and 2) X X X
SUSE Linux Enterprise Server 10, for AMD64 and EM64T, with Xen Kernel (supports Service Packs 1 and 2) X
Table 3. AIX versions supported by IBM Systems Director on IBM Power systems
Operating system IBM Systems Director Server Common Agent Platform Agent
IBM AIX® Version 5.3 (supports TL06 Service Pack 4 or later)
Note: Agentless support includes only discovery, limited remote access, a limited subset of the Agent Installation Wizard task, and the ability to launch the AIX Management Console for IBM AIX Version 6.1 agents. X X
IBM AIX Version 6.1 (supports TL01 Service Pack 1, or later)
Note: Agentless support includes only discovery, limited remote access, a limited subset of the Agent Installation Wizard task, and the ability to launch the AIX Management Console for IBM AIX Version 6.1 agents. X X
Table 4. IBM i versions supported by IBM Systems Director on IBM Power systems
Operating system IBM Systems Director Server Common Agent Platform Agent
IBM i 6.1 (formerly i5/OS®, Version 6 Release 1)
Notes:
1. Platform-Agent managed system support is not provided by the Platform Agent but by the 5722UME product.
2. Agentless support includes only Discovery, Remote Session and a limited subset of the Agent Installation Wizard task.
3. The richer set of features and subagent tasks provided by Common Agent is supported with the IBM Director Agent 5.20 for IBM i that is currently available. X
IBM i 5.4 (formerly i5/OS, Version 5 Release 4)
Notes:
1. Platform-Agent managed system support is not provided by the Platform Agent but by the 5722UME product.
2. Agentless support includes only Discovery, Remote Session and a limited subset of the Agent Installation Wizard task.
3. The richer set of features and subagent tasks provided by Common Agent is supported with the IBM Director Agent 5.20 for IBM i that is currently available. X
Unless otherwise stated, the following table includes IBM Power systems and IBM Power Blade Servers, but excludes Cell Blade Servers.
Table 5. Linux versions supported by IBM Systems Director on IBM Power systems
Operating system IBM Systems Director Server Common Agent Platform Agent
Red Hat Enterprise Linux AS, versions 4.6 and 4.7, on IBM Power Systems™ X X X
Red Hat Enterprise Linux AS, versions 5.1 and 5.2, on IBM Power Systems X X X
Red Hat Enterprise Linux AS, version 5.2, on IBM Power systems (on IBM BladeCenter® QS21 and QS22 Blade Servers) X X
SUSE Linux Enterprise Server 9 on IBM Power Systems (supports Service Packs 3 and 4) X X X
SUSE Linux Enterprise Server 10 on IBM Power Systems (supports Service Packs 1 and 2) X X X
Table 6. Linux versions supported by IBM Systems Director on System z systems
Operating system IBM Systems Director Server Common Agent Platform Agent IBM® z/VM® MAP Agent1
Versions for 31-bit systems:
Red Hat Enterprise Linux AS, version 4.0, for IBM System z (supports Update 7 and earlier) X X
SUSE Linux Enterprise Server 9 for IBM System z (supports Service Pack 4 and earlier) X X
Versions for 64-bit2 systems:
Red Hat Enterprise Linux AS, version 4.0, for IBM System z (64-bit Edition) (supports Update 7 and earlier) X X X
Red Hat Enterprise Linux AS, version 5.0, for IBM System z (64-bit Edition) (supports Update 2 and earlier) X X X X3
SUSE Linux Enterprise Server 9 for IBM System z (64-bit Edition) (supports Service Pack 4 and earlier) X X X X4
SUSE Linux Enterprise Server 10 for IBM System z (64-bit Edition) (supports Service Pack 2 and earlier) X X X X5
• 1 The IBM z/VM Manageability Access Point Agent (MAP Agent) is used by IBM Systems Director 6.1.0 to monitor the virtual machines and associated resources known as a z/VM system. The agent must be running in a virtual machine within the IBM® z/VM, version 5.4 system that is to be monitored.
• 2 64-bit support is by way of 31-bit compatibility mode only.
• 3 IBM z/VM Manageability Access Point Agent requires Red Hat Enterprise Linux AS, version 5.0, for IBM System z (64-bit Edition), Update 2.
• 4 IBM z/VM Manageability Access Point Agent requires SUSE Linux Enterprise Server 9 for IBM System z (64-bit Edition), Service Pack 4.
• 5 IBM z/VM Manageability Access Point Agent requires SUSE Linux Enterprise Server 10 for IBM System z (64-bit Edition), Service Pack 2.

Installing IBM Systems Director on the management server

After preparing your system, use the IBM® Systems Director Server installation procedure for the operating system on which you plan install IBM Systems Director Server.
Prerequisites

Installing IBM Systems Director Server on AIX

After preparing your system, you can install IBM® Systems Director Server on AIX® by downloading the AIX installation file or using the IBM Systems Director for AIX, V6.1.0 DVD. You can perform a standard installation, install using installp or NIM, or you can use a response file to customize the features that are installed.
Important:
• Installation of IBM Systems Director installs IBM Systems Director Server, Common Agent (when applicable), and Platform Agent all together. Therefore, it is not necessary to separately install Common Agent or Platform Agent on the management server after installing IBM Systems Director Server. In most cases, any IBM Systems Director tasks requiring Common Agent or Platform Agent will be performed for systems with IBM Systems Director Server installed.
• Before installing IBM Systems Director Server on a system that has IBM Storage Configuration Manager installed, you must first uninstall IBM Storage Configuration Manager. After installing IBM Systems Director Server, you can re-install IBM Storage Configuration Manager.
• IBM Systems Director Server is not supported to run on a system with workload partitions (WPARs) enabled.
Prerequisites

Preparing to install IBM Systems Director Server on AIX
You can install IBM Systems Director Server on AIX from either installation media or from a downloaded installation package.
Important: The IBM Systems Director Server and Common Agent installation packages for AIX are provided in English only.
Table 1. Installation options for IBM Systems Director Server on AIX
Installation method Title or file name
DVD media IBM Systems Director for AIX, V6.1.0 DVD
Note: To obtain an image of the IBM Systems Director for AIX, V6.1.0 DVD, download the SysDir6_1_DVD_AIX.iso file.
Attention: If you use DVD media to install IBM Systems Director Server, ensure that you allot an additional 1.2 GB of available space in the /opt file system to contain the agent packages that are copied from the DVD at the end of the server installation. The packages are copied to /opt/ibm/director/packaging/agent on the server.
Downloaded installation package • SysDir6_1_Server_AIX.tar.gz (for script installation, as described here)
• SysDir6_1_Server_Agent_Installp_AIX.tar.gz (for installp or NIM installation)
Note: For more information about using installp or NIM to install IBM Systems Director Server, see the IBM Systems Director Best Practices Redwiki. Installing with installp or NIM does not allow the use of a response file.
At the end of the installation process, you can configure a database to use with IBM Systems Director and change security settings.
Note: If you plan to use the default Apache Derby database, you can choose either the basic installation path, which configures Apache Derby by default, or the custom installation path.
To install IBM Systems Director Server, log in as the root user and complete the following steps:
1. Start the installation from the installation source:
Downloaded installation files: To start the installation from a Web download, complete the following steps:
a. Download the installation package from the IBM Systems Director Downloads Web Site at www.ibm.com/systems/management/director/downloads/.
Note: When you download the IBM Systems Director Server installation package from the Web, the agent packages are not included. You need to download and install them separately as described in "Installing agents".
b. To unzip and extract the contents of the installation package, type the following command:
gzip -cd | tar -xvf -
where is the file name of the download package.
c. Change to the directory in which the installation script is located. Type the following command and press Enter:
cd /install_files/
where install_files is the path to the extracted installation files.
DVD media: To start the installation from the DVD, complete the following steps:
d. Insert the DVD into the DVD-ROM drive.
e. If the DVD does not automount, type the following command and press Enter:
mount -v cdrfs -o ro /dev /mnt
where dev is the specific device file for the block device and mnt is the mount point of the drive.
f. To change to the directory in which IBM Systems Director Server is located, type the following command and press Enter:
cd /mnt/server
where mnt is the mount point of the drive.
2. Optional: To customize the installation, for example to select a nondefault database, copy the response file (dirserver.rsp) to a local directory and modify the installation settings in your local copy.
a. Type the following command and press Enter:
cp dirserv.rsp /directory/
where directory is a local directory.
b. Open an ASCII text editor and modify the installation settings in the copy of the dirserver.rsp file. This file is fully commented.
You can specify the following items in the server response file:
• Specify the log file options
• Specify the Web console port numbers
• Specify the TPM hostname and IP address
• Enable or disable the nonstop service, which keeps the server continuously running
Note: In the response file, "1" indicates that an item is to be installed and "0" indicates that an item is not to be installed.
c. Save the modified response file with a new name.
Note: For more information about the dirserver.rsp file, see the IBM Systems Director Best Practices Redwiki.
Tip: After installation, keep the response file for future use and reference.
3. To install IBM Systems Director Server, type one of the following commands and press Enter:
• To accept the default settings:
server/dirinstall.server
• To use the response file:
server/dirinstall.server -r /directory/response.rsp
4. where directory is the local directory to which you copied the response file, and response.rsp is the name of the response file.
5. Optional: Configure IBM Systems Director for use with a database application other than that which is supplied by default. For more information, see "Configuring the database application after IBM Systems Director installation".
Important: You can configure IBM Systems Director for use with your database application at any point after the installation of IBM Systems Director Server, but you must not start the management server until it is completed. Starting the management server before configuring IBM Systems Director to use a database application might result in a loss of function.
6. Complete the following steps to start IBM Systems Director Server:
. Type the following command and press Enter:
/opt/ibm/director/bin/configAgtMgr.sh
a. Use the following information to respond to the configAgtMgr.sh script prompts:
Enter the Resource Manager user ID that you would like to set for your Agent Manager
If you want to register with an existing agent manager, enter the same resource manager user ID as that of the agent manager. If you want to create a new agent manager, enter in any user ID that will then be defined as the resource manager user ID for that new agent manager.
Note: The resource manager user ID is an identifier that is used by IBM Systems Director or other resource managers to communicate with the agent manager; it is not a user ID on the operating system or an LDAP server.
Enter the Resource Manager password to set for your Agent Manager
If you want to register with an existing agent manager, enter the same resource manager password as that of the agent manager. If you want to create a new agent manager, enter in any password that will then be defined as the resource manager password for that new agent manager.
Verify the Resource Manager password to set for your Agent Manager
Reenter the password you entered for Enter the Resource Manager password to set for your Agent Manager.
Enter the Agent Registration password to set for your Agent Manager
If you want to register with an existing agent manager, enter the same agent registration password as that of the agent manager. If you want to create a new agent manager, enter in any password that will then be defined as the agent registration password for that new agent manager.
Verify the Agent Registration password to set for your Agent Manager
Reenter the password you entered for Enter the Agent Registration password to set for your Agent Manager.
Would you like to use an existing Agent Manager (yes or no)?
If you answer yes, ensure that the user ID and passwords that you previously entered match the user ID and passwords of the existing agent manager.
If you answer no, you are done and the configuration will start.
Enter the IP address for the existing Agent Manager
If you answered yes to Would you like to use an existing Agent Manager (yes or no)?, you must provide the IP address of the existing agent manager.
Enter the port number for the existing Agent Manager
If you answered yes to Would you like to use an existing Agent Manager (yes or no)?, you must provide the port number of the existing agent manager. The port number must be a valid number between 0 and 65535.
After you have provided all the requested information, the agent manager configuration script runs and displays a series of status messages.
b. Start IBM Systems Director processes on the management servers by running the smstart command:
/opt/ibm/director/bin/smstart
See the "smstart command" topic for instructions.
c. Type the following command and press Enter:
install_root/bin/smstatus -r
When this command returns a value of Active, the server is started.
7. If you used the DVD for installation, complete the following steps to unmount the drive and remove the DVD:
. Type cd / and press Enter.
a. Type the following command and press Enter:
umount /mnt
where mnt is the mount point of the drive.
b. Remove the DVD from the drive.
The following files and directories remain in the /tmp directory after installation completes:
• /tmp/47 directory
• /tmp/temp.con file
• /tmp/.oslevel.datafiles directory
The following CAS agent runtime files are created by cimserver during runtime:
• /tmp/cimserver_start.conf
Note: This file is deleted when cimserver shuts down. This does not affect cimserver.
• /tmp/cimlistener_start.conf
Note: This file is deleted when cimlistener shuts down. This does not affect cimlistener.
• /tmp/elasocket_cimv2
• /tmp/dpi_socket

Number of hits :
alt="Hit Counter by Digits" border="0" />