Walker News » RHEL

Red Hat Enterprise Linux Swap Size Recommendation

Walker — Sun, 02 May 2010 15:22:34 +0000

Are you looking for the recommended Linux swap partition size for a server with huge amount of RAM installed? Well, I have just stumbled upon one of such recommendation from RHEL documentation while I was actually looking for reference of previous topic.

Some of you, especially the veterans, might know there is this good old formula that suggest swap space size should be at least 1.5 times (some even said 2 times) of the RAM installed.

Nowadays, most of the brand new servers easily come with few tens to hundred gigabytes of RAM installed. Apparently, the required Linux swap file system size will be darn huge if to apply this formula and you wonder is this really needed and justified.

With reference to RHEL 5.5 installation guide, the new study suggests that the amount of swap space needed by a system is much depends on the memory workload running on that system.

This sound reasonable but not practical, as it is not easy to gauge memory workload before the system is running. Thus, the RHEL engineers suggest their own recommended swap space:

Min. 2GB of swap space for system installed with 4GB of RAM or less
Min. 4GB of swap space for system installed with 4GB to 16GB of RAM
Min. 8GB of swap space for system installed with 16GB to 64GB of RAM
Min. 16GB of swap space for system installed with 64GB to 256GB of RAM
Min. 32GB of swap space for system installed with 256GB to 512GB of RAM

In addition, the swap space should be spanned across multiple disk drives for the performance’s sake.

Although the reference is made for RHEL 5.5 running on x86, AMD64, and Intel64 system, I think it is worth for reference or applied with little adjustment if you’re not working with RHEL. But for CentOS users, you probably know that this reference should works too :-)

How To Find The Lost RHEL5 Installation Number?

Walker — Sun, 02 May 2010 10:51:18 +0000

Let’s say a brand new Dell server preinstalled RHEL 5.5 with a valid subscription number (a.k.a. installation number or registration number) has just been delivered to SA team.

Then, the developers (users of that new machine) require Red Hat Enterprise Linux to be reinstalled (for whatever reasons).

You, as one of the Linux system administrator, found out that the RHEL 5 installation number is missing or misplaced at somewhere. Oh no, God knows they (the developers, and maybe your teammate) will have all fingers pointing to you.

The trick to recover the lost RHEL installation number

This trick MAY or may NOT work. Since this DELL server is known to have preinstalled RHEL 5.5 with a valid subscription number, the chance to recover RHEL installation number is high:

1) Login to the system as root

2) Change directory to /etc/sysconfig/rhn and uses cat command to display the install-num file. Alternatively, you can just cat the file as this:

cat /etc/sysconfig/rhn/install-num

According to RHEL 5 Release Notes, the installation number is saved in /etc/sysconfig/rhn/install-num, if entered during RHEL installation. This install-num file is referred by rhn_register when registering with Red Hat Network.

How To Use Putty-generated RSA Key To Login Linux OpenSSH Server?

Walker — Sun, 10 May 2009 16:28:04 +0000

In order for Windows users to remotely login Linux servers via SSH protocol, I suggest the Putty freeware (a SSH client for Windows that is also supporting legacy, insecure telnet and rlogin protocol).

For the sake of better security, most system administrators enforce SSH authentication over Public-key cryptography based on RSA algorithm.

(Sounds complicated and high-tech? No worry. You don’t have to know all these scary terms to make this trick works – engineer is applying what the scientists have found).

So, How to use Putty-based RSA public-key with OpenSSH server?

The public-key generated by Puttygen is not compatible with the one generated by OpenSSH.

However, you can manually modify the Putty-based public key before appending it to authorized_keys file:

1) Open Puttygen (Putty Key Generator), click Generate button and move the mouse cursor randomly within the key section/frame to create the key with default settings (e.g. SSH-2 RSA of 1024 bits).

2) When the key generation completes, create a strong passphrase in the text box provided.

3) Then, click save Public Key and Save Private Key button, one after another, to save the pair of key to local hard disk.

4) Transfer the Puttygen-created public key to Linux server (in my test case, it’s RHEL 5.2).

Let’s say this public key is only meant for Walker user account, save that public key in Walker’s $HOME/.ssh directory.

5) Open the Putty public key with Vi editor (any text editor of your choice):

Delete the lines initial with four dash and “Comment”.
Join the remain lines into one, single line.
Initial that single line with ssh-rsa keyword (a space at the end).

Not get it? Take a look at my “silent” screencast:

How To Fix: SCP And SSH Login Prompt Is Very Slow In Linux

Walker — Mon, 06 Apr 2009 15:48:11 +0000

Apparently, today is not a good day for me. But it’s not too bad too as I still have enough fingers to count all these bad incidents :-)

OK, back to topic. How to find out that what cause the SSH or SCP login prompt to slowdown? How could you fix this so-called slow or delayed SSH and SCP login prompt?

This is one of the “bad incident” happened on me today – as the boss was looking at me to scp program patches to a remote Linux-based application server, the SSH login prompt took more than 1 minute to appear on screen.

To be precise, the stopwatch showed that it took exactly 1 minute and 25 seconds to display SSH login prompt!

Luckily, I do not have to Google for more than a minute to find the cause and solution :-)

What causes SCP and SSH login prompt to slowdown?

For my case, the GSSAPI authentication feature was causing the delayed SSH login prompt!

You can confirm the causes of your case by using the -v option switch. For example, the following is the verbose response of SSH login process started with -v option:

dev01 [/home/devstl]$ ssh -v appssupp@10.50.100.111
......
......
......
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: Next authentication method: publickey
debug1: Trying private key: /home/devstl/.ssh/identity
debug1: Trying private key: /home/devstl/.ssh/id_rsa
debug1: Trying private key: /home/devstl/.ssh/id_dsa
debug1: Next authentication method: password
appssupp@10.50.100.111's password:

How to fix SCP and SSH delayed login prompt?

The answer for my case is apparently by disabling GSSAPI authentication, which can be done in one of these three ways:

The “fix” is tested with SSH clients installed by openssh-clients-3.9p1-8.RHEL4.15 RPM file.

1) Specify the option to disable GSSAPI authentication when using SSH or SCP command, e.g.:

ssh -o GSSAPIAuthentication=no appssupp@10.50.100.111

2) Explicitly disable GSSAPI authentication in SSH client program configuration file, i.e. edit the /etc/ssh/ssh_config and add in this configuration (if it’s not already in the config file):

GSSAPIAuthentication no

3) Create a file called config in .ssh directory of respective user home directory (or whichever user home directory that need to get rid of this show login prompt). For example, edit /home/devstl/.ssh/config (create the config file if it’s not currently exist) and add in the GSSAPIAuthentication no option.

1) /etc/ssh/ssh_config is a global SSH client configuration file that affects all system users who are using SSH client programs.

2) /home/devstl/.ssh/config is local SSH client configuration file that only affects the user account called devstl. Whatever SSH client options specified in this local file overwrite the options stated in global SSH client configuration file.

After disabling GSSAPI authentication, SSH login prompt is back to “normal” now:

dev01 [/home/devstl]$ ssh -v appssupp@10.50.100.111
......
......
......
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/devstl/.ssh/identity
debug1: Trying private key: /home/devstl/.ssh/id_rsa
debug1: Trying private key: /home/devstl/.ssh/id_dsa
debug1: Next authentication method: password
appssupp@10.50.100.111's password:

As you can see, the SSH login is not currently authenticated via public key cryptography method, which I’ve to fix it later :-(

How To Create Volume Group And File System With LVM2 In Linux?

Walker — Sat, 07 Mar 2009 09:43:32 +0000

LVM, shorts for Logical Volume Management, is available in most modern Linux distributions. If I recall correctly, the disk layout for file systems of Red Hat Enterprise Linux 4 default installation is based on Logical Volume Management.

As the name implies, LVM is a software technique to consolidate a group multiple block devices (hard disk or disk partition) and present them to OS as a single disk volume. In other words, system administrator can build or create a 500GB file system with 2 units of 250GB hard disk.

Another advantage of using LVM implementation is flexibility to perform on-the-fly resize for the file system that built on this virtual disk partition, by adding in more physical hard disks and disk partitions.

^{A visualized concept diagram of the Linux Logical Volume Manager or LVM}

How to create a new volume group (VG) and file system on Logical Volume (LV)?

Base on RHEL4 and LVM2 as the platform, here is the summary of steps to build a new volume group (VG), create a Logical Volume (LV), followed by making new file system on it.

As with most Linux commands, the LVM and file system related commands come with number of option switches to extend or overwrite the command default behaviour.

Obviously, this general guide doesn’t cover detail of all option switches. For your own good sake, just vet through the command manual page to see if any of those option switches applicable to your environment.

1) Use lvmdiskscan to find out how many block devices (hard disks or disk partitions) seen by OS are currently used for LVM:

2) With reference to lvmdiskscan output, the /dev/sda2 disk partition is not currently used for LVM. However, it might be used by Red Hat.

So, you’ve to verify or confirm which of the non-LVM block devices are not currently used by Red Hat with the df command. For example, this following df -h output clearly indicates that /dev/sda2 and /dev/sda3 are actually mounted as root and boot file system respectively:

3) Now, let say I decides to create the new Volume Group (VG) with two unused SCSI hard disks, /dev/sdh and /dev/sdi. So, let’s use the pvcreate command to initialize these two SCSI hard disks for use by LVM:

pvcreate /dev/sdh /dev/sdi

The pvcreate command creates the VGDA, shorts of Volume Group Descriptor Area, for LVM to keep track Physical Extent (PE) allocation history, among other things. The initialized hard disk is known as Physical Volume (PV).

The manual page suggests setting a DOS disk partition to Linux LVM partition type (0x8e) prior to execute pvcreate command. But, why not to keep a standard by explicitly creating or changing non-LVM partition to LVM partition type?

1) To change existing, non-LVM disk partition to LVM partition type (0x8e) by using fdisk command:

2) To use the entire hard disk for LVM, simply proceed with fdisk to create one primary partition to take up whole hard disk space and then set the partition type to 0x8e.

The pvcreate manual page, however, suggest a faster approach by destroying the existing partition table, with this dd command:
dd if=/dev/zero of=/dev/sdi bs=512 count=1

4) Now, use vgcreate command to create a new Volume Group called vg7, using the block devices (/dev/sdh and /dev/sdi) initialized by pvcreate command in previous step (you may run pvdisplay to see difference of before and after executing vgcreate command):

vgcreate -s 16M vg7 /dev/sdh /dev/sdi

A Volume Group can be thought of a container that house all the PV specified by vgcreate or vgextend command. Conceptually, you should regard Volume Group as a virtual hard disk, as you can see later that it’s possible to “partition” the Volume Group into Logical Volume (LV).

The -s option switches specify the physical extent size (PE size) of the volume group. If this is not specifying, the default PE size is 4MB, which is best for most applications.

The maximum number of PE per Logical Volume (LV) is not applicable in LVM2. However, high number of PE could affect LVM tool performance.

As such, set a bigger PE size could effectively reducing number of PE per VG and LV (if the VG is big enough).

Take note that the name of VG must not conflict with existing VG. To list existing VG in system, execute vgscan

5) Next, we proceed to partition Volume Group into Logical Volume. A file system can only be built on Logical Volume (LV) but not Volume Group (VG). Therefore, at least one LV must be created per VG. For example, this lvcreate command create a 400MB Logical Volume (virtual disk partition) called lvol3 in the Volume Group called vg7:

lvcreate -L 400M -n lvol3 vg7

Similar to VG, the name of LV must not crash with the existing LV in the same VG. Again, this can be verified by executing lvscan

To use all free Physical Extent in Volume Group for Logical Volume, you can use -l option switch to specify the number of PE to create the LV. The number of free PE in Volume Group vg7 can be checked by executing vgdisplay vg7

6) Now, with the new Logical Volume (lvol3), we can create file system on this virtual disk partition. For example, this mkfs command create the Linux EXT3 file system on Logical Volume /dev/vg7/lvol3, with -m 2 option switch to specify 2% of the file system blocks reserved for super-user.:

mkfs -t ext3 -m 2 -v /dev/vg7/lvol3

The full path of logical volume can be checked by executing lvscan command.

7) Once the mkfs successfully creates EXT3 file system, it’s ready to mount the new file system. First, create a directory as mount point, let say this:

mkdir /NewVGMnt

8) Then execute the mount command to mount the new file system to /NewVGMnt:

mount -t ext3 /dev/vg7/lvol3 /mnt/NewVGMnt

To verify the mount point, just type df -h command to confirm it’s done successfully. To enable Linux automatically mount the new file system during boot-up, include this new file system to /etc/fstab system file.

How To Add Raw Device Mapping In Red Hat Enterprise Linux 5?

Walker — Sun, 08 Feb 2009 17:15:03 +0000

Although I can’t remember the detail of steps to create raw device in SCO UNIX for Informix DBMS, I do remember it was a scary process for me as junior administrator.

Then, we moved on to Red Hat Linux 8 Professional. With Red Hat Linux, the process of creating raw device for DB2 database system was pleasant.

However, there was a little change on how to properly and persistently define raw device permission mode, as the database application moved to RHEL4 platform.

Now, Red Hat Enterprise Linux 5 is again introduces different steps to create raw device, as I just came across this in an email subscription related to RHEL5.

On top of the configuration changes, there is even a short note to remind all raw device fans AGAIN that the rawio is deprecated and this interface is scheduled for removal from future releases.

The legacy applications (majority are DBMS) that rely on rawio for performance sake should have code changes to support opening block device with O_DIRECT flag.

How to create raw device mapping in RHEL 5?

According to Red Hat Magazine article, here is the simplified step for my reference when our infrastructure team decides to go ahead with the upgrade of RHEL 4 to RHEL 5.

First, edit /etc/udev/rules.d/60-raw.rules to bind the hard disk to raw device, one line per record of mapping. (Consult Linux man page for udev related information).

There are two ways to define such mapping, but I prefer the easier way. For example, this line defines a mapping of first SCSI hard disk (/dev/sda) to first raw device (/dev/raw/raw1):

ACTION=="add", KERNEL=="sda", RUN+="/bin/raw /dev/raw/raw1 %N"

Next, add another line to define a persistent raw device permission mode (if the default permission mode is not suitable for my case):

ACTION=="add", KERNEL=="raw*", OWNER=="root", GROUP=="disk", MODE=="0660"

Lastly, to create the raw devices by executing /sbin/start_udev shell script. To check if the raw devices are created, execute raw -qa

Using IBM DB2 Monitoring Tool db2pd To Document Database Server Profile

Walker — Sun, 08 Feb 2009 08:52:21 +0000

One of the jobs of system administrator is to profile each server. This could be a simple job, but sometime it’s not as simple as it seems to be, especially for junior administrator.

Strictly speaking, db2pd is a monitoring tool, not a special utility to generate database server profile.

However, this IBM DB2 utility retrieves information from database system memory sets which some of the information are useful for documenting server profile.

For example, db2pd -osinfo reports the number of physical CPU and related information (single core or multiple core, CPU core speed, CPU load, etc), free and used memory, IPC resource (shared memory, semaphore, and message queue), etc. (See “How to detect a single or multi-core CPU is installed in Linux“).

Similar to db2level, db2pd -V or db2pd -version reports the DB2 version and FixPak level related information.

The db2pd -inst output the detail of DB2 instance level information, such as database uptime, database manager configuration, etc.

To view most information in single output, db2pd -everything tells you all information found on all database partitions.

If you only interested in a particular database called sample, first establish a connection to the target database, e.g. db2 connect to sample in this example. Then, proceed to db2pd command, such as:

To view buffer pools setup and related information (In DB2 version 9.1, db2pd also provides bufferpool statistics, such as hit ratio):

db2pd -db sample -bufferpools

To view table spaces type (SMS or DMS) and associated table space containers statistics (total useable pages, used pages, free pages). The db2pd command output seems to be easier for me to write a shell script to automatic recording table space utilization statistics :-)

db2pd -db sample -tablespaces

For more db2pd related information, refer to IBM DB2 Information Center Home of respective version. For example:

db2pd of DB2 version 8.2 for Linux, UNIX, and Windows operating systems (LUW).
db2pd of DB2 version 9.1 for Linux, UNIX, and Windows operating systems (LUW).
db2pd of DB2 version 9.5 for Linux, UNIX, and Windows operating systems (LUW).