If you wish to get rid of the SCSI disk reservation bit on SCSI, SSA and VPATH devices, there are two ways of achieving this:

Firstly, HACMP comes along with some binaries that do this job:

# /usr/es/sbin/cluster/utilities/cl_SCSIdiskreset /dev/vpathx

# lquerypr -vh /dev/vpathx

# lquerypr -ch /dev/vpathx

# lquerypr -ch /dev/vpathx
# lquerypr -rh /dev/vpathx
# lquerypr -ph /dev/vpathx

# lquerypr -V -v -c /dev/vpathXX

# pcmquerypr -V -v -c /dev/hdiskXX

If you have Emulex HBA''s and the hbanyware software installed, for example on Linux, then you can use the following commands to retrieve information about the HBA''s:

To run a GUI version:

# /usr/sbin/hbanyware/hbanyware

# /usr/sbin/hbanyware/hbacmd listhbas

# /usr/sbin/hbanyware/hbacmd listhbas 10:00:00:00:c9:6c:9f:d0

SAN storage places the physical disk outside a computer system. It is now connected to a Storage Area Network (SAN). In a Storage Area Network, storage is offered to many systems, including AIX systems. This is done via logical blocks of disk space (LUNs). In the case of an AIX system, every SAN disk is seen as a seperate hdisk, with the advantage of easily expanding the AIX system with new SAN disks, avoiding buying and installing new physical hard disks.

• Disk storage is no longer limited to the space in the computer system itself or the amount of available disk slots.
• After the initial investment in the SAN network and storage, the costs of storage per gigabyte are less than disk space within the computer systems.
• Using two different SAN networks (fabrics), you can avoid having disruptions in your storage, the same as mirroring your data on separate disks. The two SAN fabrics should not be connected to each other.
• Using two seperate, geographically dispersed storage systems (e.g. ESS), a disruption in a computer center will not cause your computer systems to go down.
• When you place to SAN network adapters (called Host Bay adapters on Fibre Channel or HBA) in every computer system, you can connect your AIX system to two different fabrics, thus increasing the availability of the storage. Also, you'll be able to load balance the disk storage over these two host bay adapters. You'll need Multipath I/O software (e.g. SDD or PowerPath) for this to work.
• By using 2 HBAs, a defect in a single HBA will not cause downtime.
• AIX systems are able to boot from SAN disks.

System Administrators can be the worst kind of users on your system

The ideal computer system is a system that doesn't have any users on it, or isn't related to any user action. Why? Well, as long as users can't access the computer system or users can't create a load on a system, the system will run smoothly. But this isn't reality. Without users, there wouldn't be any computer systems. And without users, there wouldn't be system administrators. Although users can be idiots and amaze you of all the stupid things they do, it's the collegue system administrators you'll have to really watch out for, because they have root authority and can mess up this quite badly.

The people that install a system, should be responsible for the system

If you install a system, and know you'll have to manage it yourself once it's in production, you'll make sure the system in configured correctly. I've seen it many times: the people responsible for installing the system, aren't responsible for the maintenance of the system. This creates a "throw-it-over-the-fence" effect: people installing a system really don't have a clue what kind of administration nightmares they've created and all the problems administrators run into during the most horrible hours of the day (usually Murphy preferres Sunday night, or when you're about to go to sleep). Make absolutely sure that once a system is installed, the same people have to manage it, at least during the first two months of production.

Poorly designed systems are difficult to administer

Take your time designing a system and learn about a specific application before implementing it. Rapid designs under high time-pressure usually end up causing lots of problems during production (and they give your administrator(s) a long-lasting headache). Make sure the documentation of a system is made, before going into production. And, as an administrator, perform a health check for accepting to manage the newly installed system. Also, keep the previous best-practice tip in mind: if you haven't installed the system, you have no clue what you're getting into. And finally: during the implementation phase of a project, as a system administrator, you should be involved in the project, to be able to help design, install, configure and document the system.

Don't combine different information systems on one server

Sharing one operating system image by different information systems usually leads to problems, as these different information systems conflict in tuning parameters, backup windows, downtime slots, user information, peak usage, etcetera. Systems that do different tasks should be separated from each other to avoid dependencies. A grouping of information systems can be made by use, for example put databases together on one server. Or you can group them by product, for example put a single product and its database on one box. But NEVER, EVER put software from different vendors on 1 system!

Naming conventions should be easy

When choosing names for your hosts, printers, users etcetera, keep a few simple rules in mind:

• Choose names that are easy to remember and are not too long (8 characters max).
• Choose names NOT related to any department or other part of your organisation. Departments keep changing over time; by not naming your systems after departments, it will save you lots of time.
• Choose names NOT related to any location. Locations also change frequently, when assets are moved around.
• Never EVER reuse a name. Choose new names for new assets or users. When migrating from one host to another, don't use the same hostname, choose a new one. Rather use DNS aliases when you wish to keep a hostname. Don't configure hostname aliases on a network interface to keep using the old hostname. And for users and groups, always use a new UID and GID.
• When a system has more than 1 network interface, choose hostnames related to each other: Service address: rembrandt; Boot-address: rembrandt_boot; Standby-address: rembrandt_standby; etcetera.
• Choose a standard naming convention; don't change your naming convention.
• Never use a hostname twice, even though they are in seperate networks.

• Get educated. Take time away from your boss for training. Being away from your work will make sure, you won't be disturbed all the time during your studies. Switch your mobile off and tell everybody you're not available.
• Take at least 2 courses a year with at least 40 hours of study each. An employer not wishing to pay for studies is not a good employer. IT is a fast-changing arena, so you have to keep up.
• Take courses related to your work. Don't bother taking courses, where you learn someting, you'll never use.
• Before going on a course, read about the subject. Learning is a lot more easier if you know already something about it.
• Make sure you have all the prerequisites when taking a course.
• After a course, actually use your new-gained knowledge.
• Also, get certified. Good for your career, but also good for the understanding of a subject. Certification requires you to actually use a certain product for an extended period of time thoroughly and also requires you to read books or get training on the subject.
• Don't do good-luck-certifications. Do your learning. Doing a certification 3 times on a single day, just to get certified, won't give you the needed knowledge.
• At least 2 certifications a year!
• Get a test system and try out your knowledge. Don't use production systems for testing. Also, make sure the test system isn't on the same network as your production system.
• Write down what your doing. It is always easier to look something up again instead of guessing what you did.
• Create procedures and stick to procedures. Keep procedures short!

This command will show you when a user's password was last changed, for example for user root:

# chage -l root

If you need to determine on a Linux system which network interface actually has link on it (meaning, that it is cabled correctly to the switch), then run the following command:

# mii-tool -v

If you run into an error: "passwd: Authentication token lock busy" (E.g. on a RHEL server while trying to update the root password), then probably the root file system is set to read-only mode. You can make it read-write, by doing:

# mount -o remount,rw /

If you've just installed a Red Hat (or Fedora) system and you find that even though the ssh daemon is running and you're very sure there's no firewall blocking your access, that you still are unable to ssh or telnet to the system, then you may have run into to firewall that gets installed with Red Hat (or Fedora).

A very easy way to flush all rules from that firewall can be done by running:

# iptables -F

Run to install:

# yum install pure-ftpd

# chkconfig pure-ftpd on

# /etc/init.d/pure-ftpd start

# /etc/init.d/pure-ftpd restart

Install the software:

# yum -y install mysql mysql-server php-mysql httpd php phpmyadmin

# cd /var/www/html
# ln -s /usr/share/phpMyAdmin

# chkconfig httpd on
# chkconfig --add mysqld
# chkconfig mysqld on
# service httpd start
# service mysqld start

# mysqladmin -u root password root

# mysql -u root -p
mysql> DROP DATABASE test; [removes the test database]
mysql> DELETE FROM mysql.user WHERE user = ''; [Removes anonymous access]

<?php
   phpinfo();
?>

mysql> create database testdb

<Directory "/usr/share/phpMyAdmin">
   Order allow,deny
   Allow from all
</Directory>

# service httpd restart