Tip: Your AIX is 32 bit or 64 bit?

Description:
# Shows whether the system is 64 bit capable and also shows
# whether the OS is running in either 32 or 64 bit mode.
#

hbit=`bootinfo -y`
rbit=`bootinfo -K`

echo;echo "Hardware: ${hbit} bits capable"
echo "Running: ${rbit} bits mode";echo
exit 0

How can you find out When a system was installed?

Enter the following command:

lslpp -h bos.rte

The output of this command will show the history of when the operating system
was installed.

Should I restart AIX system or not?

Very often my customers call me and ask that they have installed an AIX LPP or device drvers but they are not sure whether they require to reboot the system to complete the installation.

The answer is in the ".toc" file which is associated with the installp filesets. The ".toc" file contains lines like

bos.adt.libm 05.02.0000.0000 1 N U en_US ...

The "N" character means no reboot is required. On the other hand, if the line has a "b" character, a reboot is necessary. An example of such a line would be

bos.mp64 05.02.0000.0000 1 b B en_US .....

A small script to find speed of your Network cards

#!/bin/ksh

for en in `netstat -i | grep en | awk '{print $1}' | sort -u | cut -c3`
do
adapter=`echo ent${en}`
entstat -d ${adapter} | grep "Media Speed"
done

exit 0

Using Secure Rsync to Synchronize Files Between Servers

To build up the whole solution , we will start with Openssh installation on AIX.OpenSSH is a free software tool that supports SSH1 and SSH2 protocols. It's reliable and secure and is widely accepted in the IT industry to replace the r-commands, telnet, and ftp services, providing secure encrypted sessions between two hosts over the network.

OpenSSH source code is compiled on AIX 5L and shipped on the AIX 5L Expansion Pack and Web Download Pack. You can also get the installation images from OpenSSH on AIX. When you install the AIX OpenSSH image from the Bonus Pack CD or from the website, you can get support from IBM Program Services.

OpenSSH is dynamically linked with OpenSSL for use of the encryption library libcrypto.a. You can get the OpenSSL library from the AIX Toolbox for Linux Applications CD or from this website. OpenSSL is delivered in RPM format (instead of installp format). To install OpenSSL, use the command:

# rpm -i

Lets walk through the process of downloading and installing OpenSSL, OpenSSH and rsync.

1. Download the package manager:

ftp://ftp.software.ibm.com/aix/freeS...LP/ppc/rpm.rte

2. Install the package manager

# installp -qacXgd rpm.rte rpm.rte

3. Download the OpenSSL library: http://www6.software.ibm.com/dl/aixtbx/aixtbx-p

a. OpenSSL is cryptographic content so you will need to sign in with your IBM ID and password. Create one if you don’t have one.
b. The next screen is a license agreement. Agree and confirm.
c. Search the page for “openssl-0.9.7g-1.aix5.1.ppc.rpm” and click on the download button next to it.

4. Install the RPM for openSSL

# rpm –i openssl-0.9.7g-1.aix5.1.ppc.rpm

5. Download OpenSSH: https://sourceforge.net/project/show...roup_id=127997

6. Installation of Openssh: The resulting file is compressed tar file. Uncompress and untar it and follow the directions in the Customer_README file exactly as given.

7. Download the latest version of rsync: ftp://ftp.software.ibm.com/aix/freeS...RPMS/ppc/rsync

8.Install rsync:

# rpm –i rsync-2.6.2-1.aix5.1.ppc.rpm

You must complete these steps on all servers/LPARs that will be using rsync, either as a file server or a sync client. You must also set up the necessary SSH keys between servers.

For the remainder of this exercise, we are going to limit ourselves to two servers. AIXServe will be the server with the master files and AIXClient will be the server/LPAR obtaining the master files for local use.

A common usage in this scenario is user information, so we will address that particular example, but rsync can be used for any types of files or directory trees. Indeed, it can be used to keep HTML source in sync, as just one more example use.

This is an example of a script that does a “pull” from AIXServe. AIXClient transfers the latest passwd, group and security files overwriting its own files. Additionally, FileClient copies any new user directories in /home but does not update, modify or delete any existing directories.

#!/usr/bin/ksh
# Get new /etc/passwd & /etc/group files
# Overwrite existing files
rsync –goptvz -e ssh AIXServe:/etc/passwd /etc/passwd
rsync –goptvz -e ssh AIXServe:/etc/group /etc/group
# Get new files from /etc/security
# Overwrite existing files
for FILE in group limits passwd .ids environ .profile
do
rsync –goptvz -e ssh AIXServer:/etc/security/$FILE /etc/security/$FILE
done
# Grab new directories in /home
# Do not change anything that already exists
rsync -gloprtuvz -e ssh --ignore-existing AIXServ:/home /home

This solution is fine for two or three servers, but what about more than that? Besides which, if the centralized user management is being done on FileServe, doesn’t it make more sense to pull rather than push?

This script does a push from AIXServe to multiple clients:

#!/usr/bin/ksh
for CLIENTS in `cat /etc/useradm_clients.rsync`
do
echo Updating ${CLIENTS}…
# Get new /etc/passwd & /etc/group files
# Overwrite existing files
rsync –goptvz -e ssh /etc/passwd ${CLIENTS}/etc/passwd
rsync –goptvz -e ssh /etc/group ${CLIENTS}/etc/group
# Get new files from /etc/security
# Overwrite existing files
for FILE in group limits passwd .ids environ .profile
do
rsync –goptvz -e ssh /etc/security/$FILE ${CLIENTS}/etc/security/$FILE
done
# Grab new directories in /home
# Do not change anything that already exists
rsync -gloprtuvz -e ssh --ignore-existing /home ${CLIENTS}/home
echo ${CLIENTS} Complete.
done

AIX BOOT LED Hang - 581

When one of my customer called me that his AIX server hanging on AIX Boot on LED 581 , I was of the instantaneous point of view that problem is just related to Network configuration of server.

When i was driving to customer site , i was thinking that i will come back to office within 1 hour and enjoy lunch at office.But when i reached at customer site , i realized that problem seems huge as there are almost 4 VIO servers and two dedicated AIX boxes which were having almost 30 minutes hang at 581 LED during boot.There was some POWER related issue at their data center and therfore their all network equipments as well as servers faced POWER failure.

AIX servers were completing boot process , but never giving a login prompt.

VIO servers were also having successful boot , but giving some abnormal behavior.

We decided to not to start AIX client Lpars ( using VIO servers ) until we know the main reason for 581.

While searching on internet , i could not find any details about LED except that this LED code has something to do with network configuration and DNS settings.

While inuring with customer , we realized that they do have some issues with their core switch, DHCP services, DNS services and their PDC. Their windows based PDC was also crashed and was facing some problem related to network adapter driver corruption.

While wasting almost 3-4 hours at customer site , and multiple restart , i was quite sure that we have no other option except wait till their all network related issues resolve.

After 4 hours they were successful in bringing their PDC ( DHCP/DNS) up and as soon as DNS server started pinging, my all AIX Lpars, servers and VIO servers stopped hanging at 581 ( without doing any thing on AIX).

Lesson learnt:If you AIX servers are DNS clients then you are dependent on DNS server. If DNS server is down and you try to reboot AIX or VIOS then you may face issue while rebooting AIX ( LED 581).Better to put two DNS servers entry in AIX or at least put hosts=local,bind4 entry in /etc/netsvc.conf file.

AIX- TIP " How to handle can not fork condition"

PAGING SPACE LOW messages will be generated when 512 pages remain free in the pool of free pages. Processes will be terminated when only 128 pages of free memory are left.

This is a very common message in a Unix Administrator life. When it comes , in most of circumtances , administrator can not any thing ;sometimes he can not even login to system;sometimes he can login but can not execute any commands.He will get the message "Can not Fork" which is indicative of very low paging space condition on AIX.

The only way to recover from this situation is to restart the system and then monitor paging space utilization for some longer time and then analyze whether you need to optimize paging space on AIX.

As a rule of thumb , all paging spaces on AIX should be roughly of same size and split across multiple physical volumes. However hd6 can be slightly bigger than others.

AIX determines which users have the most page space allocated to them and selects those processes for termination. All real memory allocated to a process will have a backing store of equal size (for every page of real memory allocated, there will be a page of disk space from paging space allocated)

Its recommended that the first paging space (/dev/hd6) be larger, since this one is brought on sooner than the rest, resulting in being more full than the others.

Thrashing should not be confused with the problem of low paging space. Low paging space is the condition in which the amount of paging space is insufficient. Thrashing is the condition in which the amount of RAM is insufficient. Low paging space involves the consumption of disk space; thrashing involves the consumption of RAM and disk I/O.

Example:lsps -a (Display attributes of all paging spaces)or lsps -s which give a summary view

LV hd6 is the default paging space. If more than one paging LV is defined, hd6 will always have a higher percentage of utilization since this is the first paging LV turned on at boot time. Once all the other paging LVs have been swapped on, paging is allocated on a round robin basis - four pages (pagesize is 4k ) at a time.

80% (MAXPERM) of real memory is to be used by persistent storage. Persistent storage is information that is not paged to the page space (/dev/hd6) but rather is paged to the physical volume where that file resides.

Using ACLs on TCPIP ports for AIX

Discretionary Access Control: TCP Connections (DA.4)

TCP based services can be protected with ACLs as well. By specifying port, host/network,user combinations, ports can be restricted to specific hosts and/or users. For example specifying port 6000, machine colorado and user joe, only this user coming from machine colorado will be able to connect to the X server. The remote hosts use TCP AH headers to send the information about the user together with the connection request. AIX 5.2 I checks /etc/security/acl for permitted
clients.
With the DACinet Feature of AIX 5.2 I the concept of privileged ports (ports that can only be opened by the superuser,typically all ports below 1024) is extended so that any port now can be a privileged port. A bitmap of privileged ports is defined to hold information on whether a port is privileged. A system administrator can modify this bitmap.
This function contributes to satisfy the security requirement FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_SMF.1 and FMT_MSA.3.

Main command which is used for maintaining ACL control on TCPIP is dacinet command.

dacinet Command
Purpose
Administers security on TCP ports in CAPP/EAL4+ configuration.
Syntax
dacinet aclflush
dacinet aclclear Service | Port
dacinet acladd Service | [-] addr [/prefix_length] [u:user | uid | g:group | gid]
dacinet acldel Service | [-] addr [/prefix_length] [u:user | uid | g:group | gid]
dacinet aclls Service | Port
dacinet setpriv Service | Port
dacinet unsetpriv Service | Port
dacinet lspriv
Description
The dacinet command is used to administer security on TCP ports. See the Subcommands section for details of the various functions of dacinet.
Subcommands
acladd Adds ACL entries to the kernel tables holding access control lists used by DACinet. The syntax of the parameters for the acladd subcommand is:
[-]addr[/length][u:user|uid| g:group|gid]
The parameters are defined as follows:

addr
A DNS hostname or an IP v4/v6 address. A "-" before the address means that this ACL entry is used to deny access rather than to allow access.
length
Indicates that addr is to be used as a network address rather than host address, with its first length bits taken from addr.

u:user|uid
Optional user identifier. If the uid is not specified, all users on the specified host or subnet are given access to the service. If supplied, only the specified user is given access.

g:group|gid
Optional group identifier. If the gid is not specified, all users on the specified host or subnet are given access to the service. If supplied, only the specified group is given access.

aclclear Clears the ACL for specified service or port.

acldel Deletes ACL entries from the kernel tables holding access control lists used by DACinet. The dacinet acldel subcommand deletes an entry from an ACL only if it is issued with parameters that exactly match the ones that were used to add the entry to the ACL. The syntax of the parameters for the acldel subcommands is as follows:
[-]addr[/length][u:user|uid| g:group|gid]

AIX Security Issues

The purpose of this article is to give an explanation of some of the control features within the AIX operating system and how to ensure the customer is taking advantage of as many of these built in security features as possible. The security issues will be broken down by category. These categories are authentication, authorization, monitoring, handling denial of service attacks, and hardening the host.

AIX is an open operating system from IBM that is based on a version of UNIX. As delivered it has no effective security, but provides the tools for the administrator to create a secure system. It is up to the administrator to establish initial security and maintain security through administrative actions.

In its simplest form, authentication is a User ID (UID) and password. It allows the AIX operating system to confirm if the person trying to gain access to the system is actually who they say they are. This is based on a what a user knows (UID and password).

AIX identifies a user by their UID number not their user name. The user name is the name given to the user that they use to log in as (John Smith). However, this username has nothing to do with the system authentication onto the AIX system. When a new user is added to the system, they receive a UID number. This number is then attached to the username created and is used for authentication onto the system. By default in AIX, this UID number is automatically assigned by the system when a user is added. This should be changed by the system administrator so that they have to manually assign this UID number to every new user. The reason for this is UID number management. The system administrator can assign every user in the purchasing department a 500 number, every user in the accounting department a 600 number, etc. This will reduce the risk of one UID number being assigned to more than one user because the managers of each department can periodically run a list of all their UIDs and ensure the same UID is not assigned to more than one user. This can also ensure each manager that they do not have an employee assigned to a UID number that is out of their range. This type of administration of UID numbers is required because there is no application control built into AIX that will prevent the system administrator from assigning the same UID number to more than one user. If this occurs, then the two people with the same UID number will have all their accesses assigned to them, along with all the accesses assigned to the other person.

AIX allows the system administrator to deactivate any UID that does not have a password. This can be done through the pg /etc/passwd command and by verifying that the second field of each line is not a null. A time-out function can be implemented to automatically log out any UID that has been inactive in the system for a certain period of time. This can be accomplished by updating the /etc/profile file. AIX also allows the UID to be locked out of the system after a certain number of unsuccessful login attempts.

The ability of any user to log on directly to the root UID should be disabled. If a user is able to log on to root directly, then there would be no evidence of who exactly logged on and performed the activities that were performed. Therefore, disable this ability to log on directly to root using the SMIT command and setting the root UID login command as FALSE. Then give a certain person the ability to log on as the super user (SU) into the root UID and perform all the needed root activities. This shows accountability because in order to SU into root the user has to first log in with their own UID then SU into root. There is an SU log file (/var/adm/sulog) that logs which UID performed an SU into root and when.

The following accounts on AIX are dangerous because they are common to all UNIX platforms and if not used should be locked. At the very least they need to have a password assigned to them and that password should not be known to anyone besides the system administrator and his/her backup. The accounts are guest, ftp, mail, bin, adm. Also, dormant accounts need to be disabled. Dormant accounts are not regularly used and not regularly examined for signs of attempted entry. Therefore, attacks could go unnoticed. A list of all dormant accounts for a certain period should be asked for and an explanation should be given for all accounts that are on that list. A user account can be disabled in AIX by placing an * in the password files in the /etc/security/passwd file.

AIX has the capability to comply with the ITCS204 password restrictions. The system defaults for password restrictions can be setup by editing the /etc/security/user file. The actual passwords for the UIDs are stored in the /etc/security/passwd file and encrypted there using the crypy(3) algorithm. In AIX, no passwords should be stored in the /etc/passwd file. Putting the file in the /etc/security/passwd file ensures the passwords are encrypted and also provides another layer of defense against a hacker. For the hacker to crack the password file, they would have to have access to the /etc/security/passwd file, move that file to the /etc/passwd file, then run their crack.

Now that we have discussed some of the ways that AIX and the system administrator can authenticate users on the AIX system, lets turn to how they provide authorization into the AIX system. Authorization involves the permissions that a user is given within the system and it is important to ensure that no user has been assigned higher privileges (permissions) than those approved by the system owner. AIX has many options that can help prevent excessive authorizations.

In AIX, file permissions are used for authorization onto the AIX system. These file permissions can be set up into three separate areas. These areas are user, group, and others. These areas can further be broken down by type of access. The three types of accesses that can be assigned to each of these three areas are read, write, and execute.

When a user creates a file, that user is labeled the owner of that file and they have the permissions assigned to the file specified in the user area. Users are not only assigned a UID, but they are also assigned to groups, based on their file access needs. Groups are identified through a Group ID (GID) and the group’s permissions to certain files are specified in the group area. By default, there are no passwords for group. The security of these groups is dependent on the UID and user's password and the correct assignment of the group and GIDs to those users. The group can give another level of ownership to a file and is used when several users need access to the same files. You can put these files into a group and grant individuals who need these files access to this group.

Users are members of at least one group (default group is staff), but can be members of several groups. The users of the group have access (read, write, or execute based on what permissions were assigned to the group) to all files assigned to that group. The user's primary group is used for file ownership on creation. If Bob is a member of three groups (system, security, accountants) and creates a file while his primary group is set to accountants, then all members of the accountants group will have access to that file (based on file permissions for the group area). So when a user creates a file they have to beware which group is their primary group at the time of creating a file. Using the above example, if John is a member of accountant group and not system group, and Bob creates a file intended for the system group, but it was created accidentally under the accountants group because Bob forgot to change his primary group to system, then John will have unauthorized access to that file.

The other area for permissions includes all users who did not create the file or are not members of the group that have access to that file. This includes a lot of users so access permissions in this area needs to be monitored closely.

AIX allows the system administrator the option of a more granular level of authorization through access control lists (ACL). The AIX ACLs can provide a much more detailed level of access control than can be defined by file permissions (read, write, execute). For example, if Bob is a member of the accountants group and you want all accountants in that group to have read and write access to the file except Bob, then you put read and write permissions in the accountants group (including Bob at this point) and in the ACL you DENY Bob. ACLs also have a PERMIT function. If you only want Bob in the accountants group to have access to the file, you don't assign the accountant group access to it, but you do a PERMIT Bob.

Most AIX systems give the security administrator (who should not have access to root or system administrator roles) the task of resetting passwords, sending out the initial password, adding users, adding groups and users to these groups, and policies. The security administrator should not be able to perform the above functions on all UIDs, especially the system administrator’s UID. If the security administrator has the capability to reset the system administrator's password, then they could reset it and thereby have access to the system as system administrator. This is a separation of duties (SOD) conflict. The security administrator duties and system administrator duties must be separated. To ensure proper SOD, the system administrator must assign the system administration UID (and any others they feel need to be) as an ADMIN user. This prevents the security team from being able to delete or change the UID or password.

There are user role options in AIX systems versions 4.2.1 and higher. This allows non-root users to be assigned portions of root privileges. For example, you may assign just the manage passwords role to a certain person. If you assign all the roles of root to different people (remember SOD conflicts), then you may be able to eliminate the need to log in as root. These people who are assigned these root roles must be a member of the security team and they can not have access to all of root. Be very careful of the roles "manage all users" and "manage all passwords". If given to someone, they would have the ability to change or delete the root ID and password and system administration ID and password. Noone should have that role. They could have "manage users" and “manage passwords".

When a user leaves you must lock the user account (UID, not the user name) then manage all their files. The system administrator should either delete or reassign all these files. When a user is removed from the system all that is removed is the user's description. All of the data that the user owned still exists in the files. However, because the user no longer exists on the system the files are deemed to be unowned. If the system administrator creates a new user with the same UID as the removed user, this new user would then own all of those files that have not been reassigned or deleted. This could affect confidentiality. To mitigate this the UIDs should be assigned based on department. This can make managing UID numbers a lot easier and stronger.

The system /tmp directory should not be used by users to store their files in it. If allowed, users can fill up this directory and then the system could hang when it needs room in this directory. The system places files in this directory while running system programs, and/or events. The system administrator should check this directory regularly and delete those files that have not been accessed within a certain time period. No confidential information or data should be kept in this /tmp directory because it is readable to all users. Users should set up their own /tmp directory under their own file structure if they want to use a temp directory.

All device special files (printers, mouse, cdrom, keyboards) must have accurate permissions assigned to them. Insecure permissions on device files allows direct access to hardware devices and their Kernel data structures. All device files must reside in the /dev directory. Any device files residing outside the /dev directory should be investigated to determine why it resides outside this directory.

Monitoring security on the AIX server is as important as authentication and authorization. The following is a discussion of the monitoring and auditing tools available in AIX.

The Trusted Computing Base (TCB), with the tcbck command, provides very useful tools for both security and system integrity. The TCB facilities can help detect or prevent accidental system changes and help protect you from playful users. TCB must be installed during the initial install. If it is not, then you must perform another initial install. The TCB is the set of programs and files that must be correct “trusted” if the rest of the system is to have security and integrity. This includes programs such as the AIX Kernel, the login programs, and the passwd programs. There are many commands to help ensure these are trusted. The most useful function of the TCB is the checking processes (syschk.cfg, tcbck, pwdchk, etc) associated with it.

The syschk.cfg file and the tcbck command can work together to verify that attributes in various files are correct. The syschk.cfg file maintains a list of these attributes (permissions, owner, checksum, links, etc) of certain files. Then the tcbck command checks that these same files still have the same attributes. Meaning that the attributes that make up the TCB were not changed since they were created. You should run the tcbck command periodically to verify the integrity of these attributes.

AIX provides several other check commands that help increase the security of the system. These check commands (grpck, usrck, pwdck) are available for use by root or anyone in the security group. The grpck command verifies that all users listed as group members in a group are defined as users on the system, that the GID is unique in the system, and that the group name is correctly formed. This ensures that all people listed in this group are indeed a user on the system and that there are not two groups with the same GID. If the groups have the same GID, then people assigned to just one of those groups will have access to both groups. The usrck command verifies parameters of a UID. It also looks for duplicate UIDs. The pwdck command checks authorization stanzas in /etc/passwd and /etc/security/passwd. If anything is wrong between the two, the standard fix is to remove the stanza. This pwdck command does not check for specified password rules as defined.

AIX comes with a lot of auditing features. Not all activities on the system can be audited, therefore, research must be done to determine what are the areas of greatest importance to audit. The following are some areas of great importance in AIX and should be audited to some extent:
1- Changes to the TCB (attempts to change the kernel, or critical databases)
2- User authentication (a hacker trying to authenticate himself as a user)
3- Configuration changes (changing the system INIT level)
4- Initialization of the system (installing new executable programs)
5- Data transfer (obtaining or granting privileges)
6- Access to data. (reading or modifying data to which the user has no access to)

Once the determination is made on what information is to be audited, this information must be processed into a readable format. In AIX there are two ways to read audit information. They are STREAM (real time) and BIN (stored to a file for later review). In BIN mode, the audit records are written to a temporary file. After the file is filled, the data is processed by the auditbin daemon and the records are written to an audit trail for storage. This audit trail is stored in the /etc/security/audit/config file. Ensure that no one has access to change or delete this file, especially the people whose activities this file is auditing. In STREAM mode, the records are written to a buffer and can be read in real-time. This provides immediate threat monitoring capability. Use the auditstream command to provide immediate threat monitoring.

There are features built into AIX that help prevent denial of service (DOS) attacks. A denial of service attack is when something or someone tries to use up all the system resources thereby rendering the system unavailable to users.

Disk quotas is one way to prevent DOS attacks by limiting the amount of disk space that any one user can use. This will prevent the user from exceeding the allocated amount of disk space. Without this restriction, a user can create a simple script to fill up a file system on disk. This could result in the system becoming unusable when the file system is full. There are three steps to setting up disk quotas:
1-Enable the file system to be protected for quotas (with the chfs command or edit the /etc/filesystems,then mount)
2-Set up the quota limits for a user (edquota -u user name)
3-Turn on quota monitoring for the system

AIX also allows the system administrator to set limits against individuals usage of the system. This prevents a user from consuming large amounts of CPU time and possibly causing high paging activities thus slowing the system down. The limits that can be set include areas such as CPU usage time, file size, memory usage, data size, or time. This can be done by editing the /etc/security/limits file.

Locking ports after a number of failed login attempts prevents a common DOS attack known as login swapping. Login swapping is when a large amounts of login requests are initiated that require the CPU to perform authentication and eventually slow a system down. This is a common DOS attack.

There are ways a system administrator can make the AIX system more secure. AIX offers tools to help harden the host.

Most UNIX operating systems (including AIX) are configured by default in a “promiscuous” manner. That means they are configured for easy communications with other systems. This means by default, many ports are active. It is important to close all the ports that are not needed or are not being used. The netstat command is a tool to discover which ports are available to enter the system. By removing the services and closing the ports that are are not used or required, you can make the host safer. In AIX there are certain services that are known to be problematic from a security standpoint and should be disabled. They are the tftp, finger,systat, netstat, uucp,exec, login, and shell services. These services can be disabled by editing the /etc/inetd.conf file and commenting out the services that are not required.

The finger daemon (one that should be disabled as mentioned above) is the first command used by a hacker to try to break into the system. It shows users who are idle on the system. This gives the hacker information on whose account is not being used and gives them a target UID to break into. Since it is not being used, a successful break-in of the UID may go unnoticed because the user is not using it. This is why finger daemon should be disabled.

The following are examples of passwordless services: “R” commands, X Windows, TFTP, and Anonymous FTP. These services were designed passwordless on purpose to make it easier for programmers to talk to each other. However, there is a danger with these services. No authentication exists between the client and the server. This means the server is reliant on the client machine being trusted (that no spoofing occurred). If you must use these commands, do not use .rhosts or /etc/hosts.equiv files to automate their operations. These commands should stay manual commands.

No important information should be displayed on the AIX logon screen. The operating system, the version or release number or host name should not be displayed. A welcome message should never appear on the login screen. A hacker could use the presence of that welcome message in court and say “it said I was welcomed to the system”. This has held up in court. A warning message about unauthorized access should display on this screen. This display can be changed in the /etc/security/login.cfg file.

There are some TCP/IP commands that are not very secure when it comes to authentication (rcp, rlogin, rsh, and tftp). The securetcpip command disables less secure standard TCP/IP commands. It is recommended that the system administrator uses this securetcpip command on all systems in the network.

Although AIX comes as an open system with hardly any security installed, AIX has a lot of security options built into it that require the system administrator to set up. These security options include authentication, authorization, monitoring, and hardening the host features. The system administrator must find the correct balance between security, risk and cost.

what Ramadan ( Month of Fasting) means for Muslims?

Ramadan ( Month of Fasting) means a holy month for Muslims. It starts by mon sight for Month of Ramadan and ends at first day of Month of Shuwwal .Muslims celebrates Eid-ul_Fitar at the end of month of Ramadan.

We , muslims fast for whole day , starting from Fujar time ( very early in the morning , usually something between 3:30 AM to 6:30 AM). However starting time or Fujar time depends upon regional timings and vary from area to area.

Fastings end on evening time, with call for prayer at Mughrib time( end of day -evening). In most of circumstances , duration for fasting not long more than 12 hours.
During this time , three main things are not allowed for muslims including drinking, eating and sex with their partners.

Now i come to main point behind concept of fasting. In holy Quran , Allah has said "Fastings have been made mandatory for Muslims as these were mandatory for other nations in past". It means that fasting has been an integral part of every holy religion. When we look into religions like christainity and Jweism , we find concept of fasting. Both christians and jews fast and their way of fasting is almost same ;normally for whole day or two three consecutive days.

Some other religions like Hinduism and Budhism also have concept of fasting , but they differ in concept. For example , hindu only refrain themselves from eating , but not from drinking. Some casts of hindus also stop talking to each other.

Now we come to spirit of concept of fasting in Islam. Islam , being religion of truth , does not put extra load or burden on its followers. It simply says that Month of Ramadan is month of practice for muslims; practice for not stoping eating & drinking only but for refraining from sins & bad deeds ( which mean all deeds which have been declared "Haram" by Allah. Now according to islam , if you stop only eating & drinking and doing sex, but continue to do bad deeds for example like telling lies and cheating others , then Allah has said " Allah has no concern , if you stop eating and drinking".

Now you can imagine that even an average muslim , during fasting , can not imagine of drinking a single drop of water ; no matter how thristy he is. This is bacause of only one reason that he knows that Almighty Allah is watching him ( even when he is alone). Now by obeying Allah's orders , muslims actually reach the hieght of Allah's obedience. When order comes ( Saher), they stopped eating/drinking and when the order comes ( Iftar) , they resume eating and drinking. By the way, this is again symbolic way of obedience;actual obedience is preventing our souls from sins and bad deeds.

May Allah enable all of us with power, for strictly following his ORDERS and refrain ourselves from deeds of Satin.

Tuning your Apache Web server on AIX

Tuning Your Apache Web Server

Setting up and configuring your Web server is a reasonably simple process for which most installations provide scripts. Optimization involves tweaking your server to achieve maximum performance. This is not well documented and is anything but automated. This article provides some simple tactics you can employ to improve your Web server's performance, and where appropriate it points to tools and information sources that will help you achieve even greater performance gains.
Most of this article's suggestions revolve around tweaking configuration settings, called "directives" in Apache configuration files. These settings let you control much of your server without the need to resort to "rebuilding" the Apache binaries or modifying source code to achieve improvements. Where is your config file? That depends upon your installation. Search for httpd.conf or apache.conf if you are unsure. Usually, it will be in /etc/httpd/conf/httpd.conf.
A Note About Hardware
All of the suggested optimizations have hardware implications. To avoid getting frustrated, ensure your hardware is sufficient to handle the volume of connections you are setting up.
Number and Behavior of Servers
There are several settings in Apache that allow you to control the number of copies handling requests that are available at any given time. Some of these settings also control how the servers act when not busy. In many cases, modifying these directives in your apache.conf file is all you need to do in terms of performance tuning. Unfortunately, there is no "magic number" that will ensure your system's performance is up to snuff. For your installation, the best way to gauge performance gains is to observe your server after making changes to these directives.
All of these directives are in the Server Instance Config section at the top of your config file:
KeepAlive - The default for this setting is "on." Make sure "on" is selected if it is not already. There are two good reasons for using this setting:
The other "number of servers" settings do not work when KeepAlive is set to "off" -- they are no longer optimizations and will probably slow your execution.
Building the connection with each mouse click is time-consuming. This option alleviates that pressure from your server, and the server assumes you'll ask for more data.
TypeOfServer - If you are performance-tuning your server, make sure it is set to "Standalone." This is the current default, but double-check just to be sure. When running in inetd mode, Apache uses inetd (or xinetd) to make its connections, which is much slower.

KeepAliveTimeOut - The values used here are in seconds. Set the value so it does not keep connections lingering too long after the user has disconnected, but long enough that connections in use don't have to be rebuilt frequently. If all your customers are on 1200-baud dial-up, the default of 15 seconds is probably too low, but if you're serving on an intranet, it might be too high. As long as this connection is "live," one of your connections is being used and is not available. When visitors click away from your site, you'll be holding on to a dead connection for as long as this value is set, so don't turn it up arbitrarily.
MaxKeepAliveRequests - This setting controls how many requests a single connection will stay alive for. In a situation where your server is overtaxed, reducing this number will cause more users to have slower access. The default is high -- 100 or 300, depending upon the operating system (or distribution) you're running. It should be high. Use the KeepAliveTimeOut value to clean up most connections, and give it a high number so that any long-running resource issues are cleaned up once in a while. If you don't want your connections to time out, set this value to "0." However, be aware that your server will be kept alive to listen to the connections.


StartServers - This is the number of child processes to start up when Apache is run. This number can be a problem only in heavily loaded servers. Since there are other settings to control the maximum number of servers when the system is stressed, the StartServers setting only applies at start-up. If you restart your Web server a lot, it is a good idea to set this number reasonably high, so that your users can get back in quickly. If you do not reboot often, the default (normally 5 for a server installation) should be enough.

MaxSpareServers - This is the number of servers that are hanging around, waiting for a connection. If you are well tuned, you'll have a few of these, but not many. The servers are there to handle spikes in service, but they're not wasting your resources when you don't need them. Leave this setting at the default unless your site is "busy" (for example, you get suddenly swamped at certain times of the day). Don't set it too low, because starting servers up takes quite a chunk of CPU time.

MinSpareServers - This value indicates when Apache should run more copies of child servers to hang about waiting for connections. The default is 5 on most server installations. This means when you only have 4 idle servers, Apache should start a new one. Playing with this value can have wild results, depending upon the CPU speed, load, and memory of your server. If you use settings you're comfortable with, and your performance degrades, use "top" or an equivalent program to look at CPU and memory usage. You may need to upgrade your hardware.


MaxClients - So you changed all the previous settings, and nothing happened? Well, this setting is the "overlord" of child processes. It controls the maximum number of children that can be running at any one time. Do not drop this number too low because the server will reject connections when this number of connections is reached. The default is 150. Consider raising it if you have problems with connection rejections. According to the httpd.conf documentation, this setting's purpose is to keep the Web server from dragging the entire system down if the server goes wild. So make sure this value is not so high that you cannot log in if it is ever reached. Keep the default unless you know that "connection denied" is something your customers are seeing occasionally.

MaxRequestsPerChild - This setting determines the number of separate requests the server handles before it becomes obsolete. It should be set to a reasonably high number. Like MaxKeepAliveRequests, this setting is useful because it keeps your system from running out of resources if there is a problem with the server or a shared object the server uses. Starting with the default of 150 is a good idea, but the higher this number, the fewer times Apache will kill a child process than create a new one to replace it.

Other Useful Settings and Hints
These settings are useful but not as easy or general as the previous ones. Use them at your discretion:
Options Multiviews - This setting is set in the Directory sections of your httpd.conf file. It defaults to "off" in most installations. If you are not serving multiple languages, leave it off. To determine language, there is a negotiation between the browser and the server that uses time, and if not necessary, slows the "apparent" responsiveness of your Web server. This negotiation is a series of requests and responses between the browser and the Web server to determine what the browser can handle and what the server can offer.

FancyIndexing - There are several places you can turn this directive to "on" in the config file. Avoid using it. Your site design should be such that customers never see a directory listing anyway, and FancyIndexing has a ton of options that can slow the server if overused.

TimeOut - This is the maximum amount of time the server will allow for a request to complete, or for servicing of the request to be completed, before canceling it. The default is 300 seconds. This is not the total connection timeout. It is the value to wait for a single TCP ACK (time for your server to send the packet and the receiver to send an acknowledgment) or a complete GET http request. What does this mean? It means the default is probably too high in normal use. If you're waiting 300 seconds for a single TCP ACK, then the connection is too slow. Even if you have a super-deep tree with CGI parameters tacked on the end, if it takes 300 seconds to deliver a single get request, your user is probably gone. Try halving the setting. Then halve it again if all is well. The idea here is to find the "magic number" so your users do not get "connection reset by peer" errors, and you do not wait for a transfer that the other end is no longer sending.

SSI (Server Side Includes) - These commands must be turned on with a directive. If every page has several SSI in it, then you are slowing the server down. SSI are great when used to include common features to make your Web site have a cohesive look-and-feel, but too much use of them degrades performance. Try to remember that, and use them judiciously.

ExpiresActive - This directive tells Apache to let the browser know how soon a page expires. You can't use it alone -- it just enables the ExpiresDefault and ExpiresByType directives. With these two directives you can control the amount of time before a given page expires. Set the ExpiresDefault globally, but be aware that every server will have different needs. The ExpiresDefault directive should have a large amount of time associated with it -- say one month, or more if you only get casual traffic. The ExpiresByType directive allows you to set expiration for a particular MIME type to a different value than the default. With a page that is constantly changing, you can set that type (preferably in the Directory directive so that you're not affecting all files) to a much shorter amount of time. If your site is relatively static, leave ExpiresActive off -- don't send an expiration header to the browser if you do not intend to use it.

How to find IP address ON HMC ports - ASMI Tip

Putting the physical control panel in manual operating mode

There are many instances , where you want to use ASMI interface to login to Hypervisor on IBM POWER systems. ASMI is a web based interface , which can be accessed through browsers like netscape or Mozilla.

The default IP address for these HMC ports are ( POWER-6):

1. 192.168.2.147 (Port-1)
2. 192.168.3.147 (Port-2)

Now the question is that if the interfaces are not originally configured with static IP addresses , then when you use "restore to factory default" option on ASMI, you will loose the connection to hypervisor. I had the same problem and no way i could connect to ASMI again.

However i soon realized that "Restore to Factory Default" option was not the problem , but it was changed IP address on HMC ports which create the problem.

Now question is how new IP addresses on HMC ports can be found? After long research i found the following tip which is to "How to find IP address on HMC ports on POWER systems".


TIP: HOW TO FIND IP ADDRESS ON HMC PORTS

You must first put the physical control panel in manual operating mode before you can select or activate certain functions.
To put the physical control panel in manual operating mode, do the following:
1. Use the Increment button to scroll to function 02.

2. 0 2 _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

3. Press Enter to start function 02.

4. Press Enter again to move to the second character on the function 02 menu. The current system operating mode is displayed with a pointer, as shown in the following example:
5. 0 2 _ _ B _ _ N < _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ P _ _ _

6. Use the Increment button to scroll through the system operating modes, and select M for manual, as shown in the following example:

7. 0 2 _ _ B _ _ M < _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ P _ _ _
8. Press Enter to select the system operating mode.

9. Press Enter again to exit function 02.
The control panel is in manual operating mode.



Function 30: Service processor IP address and port location

This function displays the service processor IP address and port location. This function is available only in the manual operating mode and from power on standby.
Note: If IPv6 is displayed on the control panel, then the service processor's network ports are configured with IPv6 IP addresses. There are not enough characters on the control panel to display the entire address.

So to get to this function , you have to use increment Key to reach 30 and then press enter key to enter the function 30 and reach 00 to get IP address on HMC1 port and 01 to get IP address on HMC2 port.