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.

How to work with IBM IVM ?

Fortunately enough i got a recent opportunity to work with IBM IVM, but offcourse in a very difficult customer situation.

And when on a very short notice , i had to Logically partition a Pseries P550 server into two AIX and Linux partition , initially i thought it would infact going to be a very difficult task as customer have no HMC at all and IVM documentation are very small in number and not clear though.

So here are basic steps to implement IVM on IBM Pseries server and partition it with the help of IVM.

1. First make sure that your Pseries server have standard virtualization license with it. If yes , there is possibility that it is not enabled. Here comes the concept of ASMI.

2. ASMI is web based tool which comes by default with IBM Power systems. Intel guys can comapre it with HP LILO function as you can do a large number of tasks on hardware level ( or Firmware level). You can even restart pseries server or configure speed of serial ports through ASMI.

If you want to make sure about virtualization capabilities of your pSeries server , access it with ASMI . There are two HMC related ports ( HMC1 and HMC2) which have default IP addresses ( 169.254.2.147 and 169.254.3.147) , so you have to just IP addresses of same subnet on your laptop and use a straight ethernet cable to connect to HMC1 or HMC2. You have to use admin user and admin password to login into ASMI for first time. Please note that until you change default password of admin user, ASMI will not allow you to do any other task.

To access ASMI, use your PC browser ( netscape, IE or Mozilla) to point to https://169.254.2.147

3. Once you login to ASMI, check about virtualization license on IBM pseries. It would be a great idea, if you shutdown the server and reset it to factory default setting.

4. Now you have to boot the server into SMS mode and put the VIO Server CD and start installation of VIO. It should be noted down that IVM is nothing , but VIO server itself. I used one of the internal disk to install VIO server.

5. Once installation is done , you have to accept the license on VIO , set the date on VIO and if required , configure virtual Ethernet as well.Finally give the IP address to VIO server using mktcpip command.

6. Now you can access IVM through browser , by using http://.

7. Using IVM web based interface, you can create new Lpars with different settings of processing units and memory. You can assign HEA ports to these Lpars for tcpip access. If present , you can assign dedicated FC and Ethernet adapters to these Lpars as well.

8. Finally , if you have SEA adapters on VIO server , you can enable virtual Ethernet bridging and use these virtual Ethernet adapters on client Lpars.

9. For disks , IVM allows you to create storage pools as well. Once IVM is installed , default rootvg pool is created on one of the internal disk. It would be a nice idea if you have another internal disk and you can mirror the VIO OS disk.

10. Now for client Lpars , you can use either internal disks or SAN disks. If going for SAN disks through dedicated adapters, there is no need to create virtual disks on VIO level. On the other hand , if you want to use internal disks ( as in my case) you have to create another disk pool on one of the internal disk and then create virtual disks on that disk pool and assign them to client lpars. These client lpars will access these virtual disks through virtual scsi adapters.

11. You can finally assign CD to client lpars and boot them into SMS mode , one by one and install OS of your choice on these Lpars.

My own observations about IVM that there are many limitations as compared to HMC, however it is still not a bad tool. As based on Websphere and Java , performance is slightly slow. Sometimes, it is time out and sometime it crashes. Another thing is that an experienced HMC user still have to adjust his HMC knowledge according to IVM functionalities and interface . This generally require some time , so dont panic at all when you see IVM interface for the first time. Be patient and spend some time using IVM and soon you will be able to handle it , even with more comfort as you handle HMC.

How to extend dynamically VIOS based rootvg !

POWER6 LPAR:
• Unmirror your rootvg and remove hdisk0 from the rootvg volume group. If there are any swap or dump devices on this disk you may need to remove them first before you can remove hdisk1 from the rootvg volume group.
• Once the disk has been removed from the rootvg, remove it from the LPAR by executing the following:
rmdev -l hdisk0 - d
• Now you execute the bosboot command and update your bootlist now that hdisk0 has been removed and is no longer part of the system:
bosboot - a - d /dev/hdisk1
bootlist -o -m normal hdisk1
VIO Server (where hdisk0 was created):
• Remove the device from the VIO server using the rmdev command
rmdev -dev < bckcnim_hdisk0 >
• Next you will need to access the AIX OS part of the VIO server by executing:
oem_setup_env
• Now you have two options: you can extend the existing logical volume or a create a new one if there is more than enough disk space left. In this example I will be using bckcnim_lv.
smitty extendlv and add additonal LP's or smitty mklv
• Exit it out of oem_setup_env by just typing exit at the OS prompt.
• Now that you are back within the restricted shell of the VIO Server, execute the following command. You can use whatever device name you wish. I used bckcnim_hdisk1 just for example purposes:
mkvdev -vdev bckcnim_lv -vadapter < vhost# > -dev bckcnim_hdisk0
POWER6 LPAR:
• Execute cfgmgr to add the new hdisk0 back to LPAR.
• Add hdisk0 back to the rootvg volume group using the extendvg or smitty extendvg.
• Mirror rootvg using the mirrorvg command or smitty mirrorvg
• Sync the mirroring process to the background and wait to complete.
• Now you must execute bosboot again and update the bootlist again:
bosboot -a
bootlist -o -m normal hdisk0 hdisk1

Should we consider using SSDs or not?

Until the costs drop even further, performance-boosting solid-state drives (SSDs) won't make economic sense for every type of application, so it's important to follow best practices to ensure they are working for your storage shop. Here are 10 SSD best practices to follow:
1. Identify I/O-intensive applications that will benefit from faster data storage.
Types of applications that may be well suited to SSD technology include databases, data mining, data warehousing, analytics, trading, high-performance computing, server virtualization, Web serving and email systems.
A check of how many enterprise-grade 15,000 rpm and 10,000 rpm hard disk drives are in use and how much money has been spent on DRAM for performance will help to determine if SSDs will be worth the investment.
Study application workloads and assess hot vs. warm vs. cold data sets. Active data can be directed to the flash solid-state drives, and the less frequently accessed data can go on Fibre Channel (FC) drives or SATA drives.
"If you have a good understanding of that, then you can understand how much solid-state storage you're likely to need to be able to optimize the performance of your system," said Jim Handy, an analyst who focuses on memory chips and SSDs at Objective Analysis.
2. Ensure that applications, especially those that are custom-written, can handle the faster solid-state drives.
"For most applications, this should not really be a problem, but depending on coding and timings, you can have the chance to have things done too quickly which can throw off timing a bit, as well as the processors actually jumping due to it not having to wait for the disk anymore," said Jon-Carlos Mayes, IT director at CCP hf, a Reykjavik, Iceland-based online game producer. CCP uses both DRAM and NAND flash SSD technology from Texas Memory Systems Inc.
3. When evaluating solid-state drive technology, concentrate on cost per IOPS, not cost per gigabyte.
"Focus on what would be the lowest overall system cost to get the throughput that you require," Handy said. "If you focus on cost per gigabyte, then a solid-state drive will always look bad because it ranges from 20 times [more than] the cost per gigabyte of a hard disk drive."
4. Make sure the performance and reliability of a vendor's SSDs can be measured in terms of random reads and writes across small blocks and pages.
"Vendors will quote you whatever they can do the best in the lab, and that may not be what you're actually running," said Joseph Unsworth, a research director at Gartner Inc. Once you determine which supplier can deliver the results you need, he added, have the vendor do a proof of concept and make sure your service-level agreement is tailored specifically to your application needs.
5. Determine which type of solid-state drive will be the best fit.
The chief SSD choice confronting users today is NAND flash or DRAM. DRAM SSDs are significantly faster and perform reads and writes equally well, but they're also considerably more expensive and consume more power. NAND flash SSDs -- whether single-level cell (SLC) or multilevel cell (MLC) – perform better on reads than writes, and they wear out over time.
"Are you just accessing data? Or are you doing a lot of programming of data? That will determine whether or not you can go with a cheaper but less robust multilevel cell-based SSD, or you need to go with single-level cell," Unsworth said. "If you're doing a mix of both [reads and writes], then you're going to want to make sure that you're using the single-level cell technology over the multilevel cell."
The more expensive SLC solid-state drives are better suited to the enterprise because the wear life is longer for continuous writing than it is with MLC-based drives.
NAND Flash SSDs can be especially helpful for a read-intensive database table, for example, whereas DRAM SSDs -- whether in an appliance, in cache or in DRAM combined with flash -- would be a better option for transaction logs or journal files, where you're recording a copy of what's changing, said Greg Schulz, founder and analyst at StorageIO Group.
"I tell folks if they're going to need to have super transaction rate capability because they're running some data mining application, then one of the high-performance boxes like Violin or Texas Memory Systems has could be a pretty economical way to go," said Gene Ruth, a senior storage analyst at Burton Group. "The alternative would be to build out a huge hard disk drive-based system with all the power and space and maintenance and failure rates that go along with having lots of hard disks."
6. Consider NAND flash solid-state drives for caching purposes as a way to augment application performance.
Write caching is typically done at the storage device with DRAM cache that persists the writes to back-end storage. When that approach isn't fast enough, DRAM solid-state drives have been used to accelerate write-intensive applications. Now that lower cost flash is available, SLC SSDs will increasingly become the preferred option for write caching, especially when budgets are tight.
The effectiveness of any read caching layer depends on the size of the data set being accessed, the frequency with which the data is read and the performance of the cache. If the data set is small and being read on a frequent basis, server RAM usually suffices. But if the data set is large and the reads are random, flash SSD can work well. Although SLC and the less expensive MLC are both options, the more durable SLC is generally favored.
7. Consider solid-state drive over short-stroking.
Formatting a hard disk drive so that data is written only to the outer sector of the disk's platter can increase performance in high I/O environments, since it reduces the time the drive actuator needs to locate the data. But that practice, known as short-stroking, leaves a substantial percentage of the disk drive's capacity unused.
"You're deliberately not using what you bought. Because we're so used to it, people think that's how it has to be," said Mark Peters, an analyst at Enterprise Strategy Group. Even though SSD technology is nascent, he said, it already makes financial sense in scenarios where users now short-stroke. "Everyone says, 'I don't want to buy solid state because it's 10 times the cost [of hard disk drives],'" Peters said. "But you could take that 5 GB from 20 [hard disk] drives and put it on one solid-state [drive]."
8. Determine how much power your data center is consuming.
According to Peters, "You're either in parts of the country or a data center where you have oodles of power, or you're in parts of the country or a data center where actually you don't have much power left and you're going to hit the wall at some point. If you don't know how much [power] you're using, how can you know when that's going to happen?"
Because SSD technology is more energy efficient than hard disk drives, it can help to extend the life of a data center with power constraints. But, Peters said, many IT organizations have no clue what their electric usage is.
9. Experiment with solid-state drive technology in the lab.
"They definitely want to bring in, if not the individual disk devices, possibly a subsystem that's based on SSDs," Burton Group's Ruth said, possibly to target a particular application for test purposes. Even using SSDs in a laptop can help to illustrate the potential advantages, he added. "People are familiar with hard disks. They get that. They need to develop that comfort level with solid-state disks as well."
10. Make sure long-term planning takes into account a potential solid-state storage tier.
Solid-state drives will be integrated into storage systems as standard fare going forward, so IT organizations shouldn't lock themselves into a hard disk drive-only strategy. Instead, they need to entertain the possibility of an SSD tier, or tier 0, for their most I/O-intensive servers.