Red Hat Enterprise Linux 5 ships yum as a replacement for the utility 'up2date' which was used in previous versions of Red Hat Enterprise Linux.
Note: The http proxy must support byte-range addressing for successful use
In order to use yum through an http proxy please follow these steps:
1. Open /etc/sysconfig/rhn/up2date for editing
2. Change the following:
enableProxy=0
To the following:
enableProxy=1
3. Enter the user's password for the http proxy where it states the following:
proxyPassword=
4. Enter the user's username for the http proxy where it states the following:
proxyUser=
5. Enter the URL for the proxy server, in host:port format, in the following line:
httpProxy=
6. Save the file.
Thursday, March 12, 2009
Wednesday, March 11, 2009
How do I check the software integrity on my RHEL5
There is an integrity checking software called AIDE shipped by Red Hat Enterprise Linux 5. AIDE provides some general strategy for implementing integrity checking to detect the intrusions when they have occurred.
To install AIDE, using following command:
# yum install aide
To configure AIDE, customize the /etc/aide.conf to meet the requirements of the system. For more detailed information about the AIDE configuration file, please refer the man page of aide.conf.
To generate a new database and install it on AIDE system:
# aide --init
# cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
By default, the program will create a new file aide.db.new.gz in the /var/lib/aide/ directory. This must be installed on the system manually by using the copy command. Typically, system administrator should create an AIDE database on a new system before the system is connected to any network.
To check the inconsistencies between the current system and the AIDE database, running following command:
# aide --check
or
# aide
If the check produces any unexpected output, investigate and fix it as soon as possible.
The aide command can also be run as a crontab job to do periodic integrity checking.
To install AIDE, using following command:
# yum install aide
To configure AIDE, customize the /etc/aide.conf to meet the requirements of the system. For more detailed information about the AIDE configuration file, please refer the man page of aide.conf.
To generate a new database and install it on AIDE system:
# aide --init
# cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
By default, the program will create a new file aide.db.new.gz in the /var/lib/aide/ directory. This must be installed on the system manually by using the copy command. Typically, system administrator should create an AIDE database on a new system before the system is connected to any network.
To check the inconsistencies between the current system and the AIDE database, running following command:
# aide --check
or
# aide
If the check produces any unexpected output, investigate and fix it as soon as possible.
The aide command can also be run as a crontab job to do periodic integrity checking.
Saturday, March 7, 2009
How do I improve mouse tracking in a virtual machine?
The mouse cursor in virtual machines under Red Hat Enterprise Linux 5 does not track well with the actual mouse movements. This is because mouse drivers expect relative motion deltas. For example, the mouse moved up and right one centimeter, but the virtual machine console sends absolute coordinates. The conversion from absolute coordinates to relative deltas is an approximation. As errors in the approximations accumulate, the virtual cursor drifts farther and farther from the host cursor.
One solution to this problem is to switch from a virtual mouse to a virtual tablet. A tablet sends absolute coordinates instead of relative motion deltas, so no conversion is necessary. See the instructions below to enable a virtual tablet.
Another solution is to switch from a VNC console to an SDL console, however, the SDL console has its own set of problems: it does not work with the Virtual Machine Manager (virt-manager), and if you close the SDL console, it immediately kills the virtual machine, possibly resulting in data loss.
Enabling a Virtual Tablet
1. Launch the Virtual Machine Manager (virt-manager).
2. If the virtual machine is running, turn it off.
3. Select the virtual machine, then click Details. In the Hardware tab, click Add. For Hardware type, choose Input Device and click Forward. For Type, select the "EvTouch USB Graphics Tablet", click Forward, and click Finish. Alternately, on the host (dom0) system, open the /etc/xen/virtual-machine-name file with your favorite text editor and add the following line at the bottom of the file:
usbdevice = 'tablet'
4. Turn on the virtual machine.
5. If necessary, switch to a text console: using the Virtual Machine Manager console, go to the Send Key menu and click CTRL-ALT-F1.
6. Log in to the virtual machine as root.
7. Switch to run level 3 (to disable X Windows) by running init 3:
[root@hostname ~]# init 3
8. Run the following command to find the name of the event for the tablet:
[root@hostname ~]# egrep 'Name|Handlers' /proc/bus/input/devices | grep -i -A 1 tablet
N: Name="QEMU 0.8.2 QEMU USB Tablet"
H: Handlers=mouse1 event2 js0
9 . Open /etc/X11/xorg.conf with your favorite text editor. If necessary, add the following InputDevice line to the ServerLayout section:
Section "ServerLayout"
...
...
InputDevice "Mouse0" "CorePointer"
EndSection
Then, create a new InputDevice section:
Section "InputDevice"
Identifier "Mouse0"
Driver "evdev"
Option "Device" "/dev/input/event2"
Option "Name" "QEMU 0.8.2 QEMU USB Tablet"
Option "Mode" "Absolute"
EndSection
For the Device and Name values, use the eventX value ("event2" in this case) and name found in the previous step.
10. Restart X Windows and exit the root shell by running
[root@hostname ~]# init 5; exit
The mouse tracking should be much more accurate now.
One solution to this problem is to switch from a virtual mouse to a virtual tablet. A tablet sends absolute coordinates instead of relative motion deltas, so no conversion is necessary. See the instructions below to enable a virtual tablet.
Another solution is to switch from a VNC console to an SDL console, however, the SDL console has its own set of problems: it does not work with the Virtual Machine Manager (virt-manager), and if you close the SDL console, it immediately kills the virtual machine, possibly resulting in data loss.
Enabling a Virtual Tablet
1. Launch the Virtual Machine Manager (virt-manager).
2. If the virtual machine is running, turn it off.
3. Select the virtual machine, then click Details. In the Hardware tab, click Add. For Hardware type, choose Input Device and click Forward. For Type, select the "EvTouch USB Graphics Tablet", click Forward, and click Finish. Alternately, on the host (dom0) system, open the /etc/xen/virtual-machine-name file with your favorite text editor and add the following line at the bottom of the file:
usbdevice = 'tablet'
4. Turn on the virtual machine.
5. If necessary, switch to a text console: using the Virtual Machine Manager console, go to the Send Key menu and click CTRL-ALT-F1.
6. Log in to the virtual machine as root.
7. Switch to run level 3 (to disable X Windows) by running init 3:
[root@hostname ~]# init 3
8. Run the following command to find the name of the event for the tablet:
[root@hostname ~]# egrep 'Name|Handlers' /proc/bus/input/devices | grep -i -A 1 tablet
N: Name="QEMU 0.8.2 QEMU USB Tablet"
H: Handlers=mouse1 event2 js0
9 . Open /etc/X11/xorg.conf with your favorite text editor. If necessary, add the following InputDevice line to the ServerLayout section:
Section "ServerLayout"
...
...
InputDevice "Mouse0" "CorePointer"
EndSection
Then, create a new InputDevice section:
Section "InputDevice"
Identifier "Mouse0"
Driver "evdev"
Option "Device" "/dev/input/event2"
Option "Name" "QEMU 0.8.2 QEMU USB Tablet"
Option "Mode" "Absolute"
EndSection
For the Device and Name values, use the eventX value ("event2" in this case) and name found in the previous step.
10. Restart X Windows and exit the root shell by running
[root@hostname ~]# init 5; exit
The mouse tracking should be much more accurate now.
How can I find information on the maximum amount of memory my system can handle?
The dmidecode command can be used to display information from the systems' BIOS that includes the maximum memory that the BIOS will support. This information is displayed by dmidecode as type 16 (Physical Memory Array) which can be filtered with the command dmidecode -t 16.
For instance, the following output shows a system that can support a maximum of 16GB of RAM.
Handle 0x0032, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 16 GB
Error Information Handle: Not Provided
Number Of Devices: 4
For instance, the following output shows a system that can support a maximum of 16GB of RAM.
Handle 0x0032, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 16 GB
Error Information Handle: Not Provided
Number Of Devices: 4
Does Red Hat Enterprise Linux properly handle leap seconds?
Background
"Leap seconds" are extra seconds that are added or removed to keep Civil Time, which is based on Universal Coordinated Time (UTC), within 0.9 seconds of the Earth's rotational time (UT1). The last leap second was added at 2008-12-31 23:59:59 UTC. At that time, clocks keeping track of time based on UTC should have counted as follows:
2008-12-31 23:59:59 UTC
2008-12-31 23:59:60 UTC
2009-01-01 00:00:00 UTC
Note that the leap second corrections are made at midnight UTC, which is at different local times around the world. For example, the most recent leap second was added at 3:59:60 pm in the US Pacific time zone (2008-12-31 15:59:60 PST).
Red Hat Enterprise Linux using NTP
Systems running any version of Red Hat Enterprise Linux should automatically account for leap second corrections if they are using the NTP daemon to synchronize their local timekeeping with an NTP server. During the last day before a leap second correction, NTP servers should notify their clients that a leap second will occur, and at 23:59:59 UTC, the Linux kernel should add or remove an extra second by making the 60th second twice as long or removing it entirely. Thus, Red Hat Enterprise Linux systems running an NTP client during the last leap second correction should have counted time as follows:
2008-12-31 23:59:59 UTC
2008-12-31 23:59:59 UTC
2009-01-01 00:00:00 UTC
Red Hat Enterprise Linux not using NTP
By default, Linux systems not using NTP to synchronize their timekeeping will not correct leap seconds, and the time reported by these systems will have a one-second difference relative to UTC after the leap second correction. You should reset the clock manually after leap seconds occur.
You can also configure non-NTP systems to report time corrected for leap seconds by copying the appropriate file from the /usr/share/zoneinfo/right directory hierarchy to /etc/localtime and resetting the clock to the correct local time. The files in /usr/share/zoneinfo/right contain local time information corrected for all leap seconds that have occurred since the beginning of the Epoch on 1970-01-01 00:00:00 UTC. The other time zone files in /usr/share/zoneinfo do not have leap second corrections added. After the 2008 leap second, there have been 24 leap seconds added since the Epoch.
As an example, if a system is in the America/Los_Angeles (US Pacific) time zone, you can reconfigure the system to report leap-second-corrected time by running the following and resetting the clock to Pacific Time:
cp /usr/share/zoneinfo/right/America/Los_Angeles /etc/localtime
Once this is done, the system will report time corrected for leap seconds.
To ensure that the most recent leap second is accounted for properly, you should make sure you have the latest version of the tzdata installed in their Red Hat Enterprise Linux system. The leap second added at the end of 2008 should have been handled properly by the following versions of tzdata:
Red Hat Enterprise Linux Version tzdata version
==================================================
Red Hat Enterprise Linux 2.1 tzdata-2008e-1.el2_1
Red Hat Enterprise Linux 3 tzdata-2008e-1.el3
Red Hat Enterprise Linux 4 tzdata-2008e-1.el4
Red Hat Enterprise Linux 5 tzdata-2008e-1.el5
Additional Information
Additional information on leap seconds and how they are handled in Linux and by NTP can be found at the following links:
Leap Seconds
The NTP Timescale and Leap Seconds
NTP in real Life: What happens during a Leap Second?
"Leap seconds" are extra seconds that are added or removed to keep Civil Time, which is based on Universal Coordinated Time (UTC), within 0.9 seconds of the Earth's rotational time (UT1). The last leap second was added at 2008-12-31 23:59:59 UTC. At that time, clocks keeping track of time based on UTC should have counted as follows:
2008-12-31 23:59:59 UTC
2008-12-31 23:59:60 UTC
2009-01-01 00:00:00 UTC
Note that the leap second corrections are made at midnight UTC, which is at different local times around the world. For example, the most recent leap second was added at 3:59:60 pm in the US Pacific time zone (2008-12-31 15:59:60 PST).
Red Hat Enterprise Linux using NTP
Systems running any version of Red Hat Enterprise Linux should automatically account for leap second corrections if they are using the NTP daemon to synchronize their local timekeeping with an NTP server. During the last day before a leap second correction, NTP servers should notify their clients that a leap second will occur, and at 23:59:59 UTC, the Linux kernel should add or remove an extra second by making the 60th second twice as long or removing it entirely. Thus, Red Hat Enterprise Linux systems running an NTP client during the last leap second correction should have counted time as follows:
2008-12-31 23:59:59 UTC
2008-12-31 23:59:59 UTC
2009-01-01 00:00:00 UTC
Red Hat Enterprise Linux not using NTP
By default, Linux systems not using NTP to synchronize their timekeeping will not correct leap seconds, and the time reported by these systems will have a one-second difference relative to UTC after the leap second correction. You should reset the clock manually after leap seconds occur.
You can also configure non-NTP systems to report time corrected for leap seconds by copying the appropriate file from the /usr/share/zoneinfo/right directory hierarchy to /etc/localtime and resetting the clock to the correct local time. The files in /usr/share/zoneinfo/right contain local time information corrected for all leap seconds that have occurred since the beginning of the Epoch on 1970-01-01 00:00:00 UTC. The other time zone files in /usr/share/zoneinfo do not have leap second corrections added. After the 2008 leap second, there have been 24 leap seconds added since the Epoch.
As an example, if a system is in the America/Los_Angeles (US Pacific) time zone, you can reconfigure the system to report leap-second-corrected time by running the following and resetting the clock to Pacific Time:
cp /usr/share/zoneinfo/right/America/Los_Angeles /etc/localtime
Once this is done, the system will report time corrected for leap seconds.
To ensure that the most recent leap second is accounted for properly, you should make sure you have the latest version of the tzdata installed in their Red Hat Enterprise Linux system. The leap second added at the end of 2008 should have been handled properly by the following versions of tzdata:
Red Hat Enterprise Linux Version tzdata version
==================================================
Red Hat Enterprise Linux 2.1 tzdata-2008e-1.el2_1
Red Hat Enterprise Linux 3 tzdata-2008e-1.el3
Red Hat Enterprise Linux 4 tzdata-2008e-1.el4
Red Hat Enterprise Linux 5 tzdata-2008e-1.el5
Additional Information
Additional information on leap seconds and how they are handled in Linux and by NTP can be found at the following links:
Leap Seconds
The NTP Timescale and Leap Seconds
NTP in real Life: What happens during a Leap Second?
Can a system run multiple virtualization technologies simultaneously?
Can one system, for example, run both Red Hat Virtualization and VMware virtual machines at the same time?
No.
Virtualization software needs exclusive control over certain hardware resources. The host system may crash or reboot if multiple virtualization systems are active and try to use the same hardware resources. Be sure to install and use only one virtualization technology on a system.
To check if Red Hat Virtualization (Xen in Red Hat Enterprise Linux 5) is active, look for "xen" in the uname output, for example:
$ uname -r | grep xen
2.6.18-8.el5xen
To disable Xen, disable the xend and xendomains services, then reboot and choose another kernel at the GRUB screen, or use grubby to change the default kernel and reboot. For example:
# chkconfig xend off
# chkconfig xendomains off
# grubby --set-default=/boot/vmlinuz-2.6.18-8.el5
# reboot
No.
Virtualization software needs exclusive control over certain hardware resources. The host system may crash or reboot if multiple virtualization systems are active and try to use the same hardware resources. Be sure to install and use only one virtualization technology on a system.
To check if Red Hat Virtualization (Xen in Red Hat Enterprise Linux 5) is active, look for "xen" in the uname output, for example:
$ uname -r | grep xen
2.6.18-8.el5xen
To disable Xen, disable the xend and xendomains services, then reboot and choose another kernel at the GRUB screen, or use grubby to change the default kernel and reboot. For example:
# chkconfig xend off
# chkconfig xendomains off
# grubby --set-default=/boot/vmlinuz-2.6.18-8.el5
# reboot
How do I find which RPM contains a specific file?
The rpm -qf command will provide the name of the RPM package that contains a specific file. For example, to see which rpm contains the file /usr/lib/libdb.so.2, run the following:
# rpm -qf /usr/lib/libdb.so.2
gnome-libs-1.4.1.2.90-34.1
If you are trying to install an RPM package and you are getting an error message saying that a file is missing, RPM may not be able to tell you which package that file is in. Depending on which version of Red Hat Enterprise Linux you are running you can identify the necessary package using either 'yum whatprovides' for Red Hat Enterprise Linux 5 or 'up2date --whatprovides=' for Red Hat Enterprise Linux 4.
# up2date --whatprovides=libdb.so.2
compat-db-4.1.25-9.i386
or
# yum whatprovides */libdb.so
Loaded plugins: rhnplugin
db4-devel-4.3.29-9.fc6.x86_64 : Development files for the Berkeley DB
: (version 4) library.
In the case that you do not have your installations registered to the Red Hat Network and you have no others available, there is a third party web site http://www.rpmfind.net which is a good resource. This website allows you to search by file, and then prints out the name of the package that file is in.
Once you know which package you need to install, you can use up2date in Red Hat Enterprise Linux 4 and older, or yum in Red Hat Enterprise Linux 5 and newer, to install the package from RHN. Packages can also be downloaded from the RHN website at http://rhn.redhat.com.
# rpm -qf /usr/lib/libdb.so.2
gnome-libs-1.4.1.2.90-34.1
If you are trying to install an RPM package and you are getting an error message saying that a file is missing, RPM may not be able to tell you which package that file is in. Depending on which version of Red Hat Enterprise Linux you are running you can identify the necessary package using either 'yum whatprovides' for Red Hat Enterprise Linux 5 or 'up2date --whatprovides=' for Red Hat Enterprise Linux 4.
# up2date --whatprovides=libdb.so.2
compat-db-4.1.25-9.i386
or
# yum whatprovides */libdb.so
Loaded plugins: rhnplugin
db4-devel-4.3.29-9.fc6.x86_64 : Development files for the Berkeley DB
: (version 4) library.
In the case that you do not have your installations registered to the Red Hat Network and you have no others available, there is a third party web site http://www.rpmfind.net which is a good resource. This website allows you to search by file, and then prints out the name of the package that file is in.
Once you know which package you need to install, you can use up2date in Red Hat Enterprise Linux 4 and older, or yum in Red Hat Enterprise Linux 5 and newer, to install the package from RHN. Packages can also be downloaded from the RHN website at http://rhn.redhat.com.
Saturday, February 28, 2009
Kernel Services, Part 3
The /boot Partition
The Linux kernel is stored in the partition with the /boot directory. New kernels must also be transferred to this directory. By default, RHEL configures a partition of about 100MB for this directory. This provides enough room for your current kernel plus several additional upgraded kernels.
The /proc Filesystem
The /proc directory is based on a virtual filesystem; in other words, it does not include any files that are stored on the hard drive. But it is a window into what the kernel sees of your computer. It’s a good idea to study the files and directories in /proc, as it can help you diagnose a wide range of problems.
Example 1. A Red Hat Enterprise Linux /proc directory
$ \ls /proc/
1 24 3120 3357 3640 crypto keys swaps
10 2415 3124 3388 3643 devices key-users sys
13871 2438 3147 3409 3655 diskstats kmsg sysrq-trigger
14238 259 3155 3445 3657 dma loadavg sysvipc
15843 262 3187 3446 3667 driver locks tty
17 292 3206 3457 4 execdomains mdstat uptime
18 2921 3222 3458 5 fb meminfo version
18263 2964 3248 3534 6 filesystems misc vmcore
18266 2966 3253 3539 7 fs modules vmstat
18267 2989 326 3543 85 ide mounts xen
18303 2993 3279 3546 86 interrupts net zoneinfo
19031 3 3291 3547 9 iomem partitions
196 3025 3305 3557 buddyinfo ioports schedstat
2 3054 3326 3558 bus irq self
22 3090 3334 3559 cmdline kallsyms slabinfo
233 3109 3345 3638 cpuinfo kcore stat
The numbered items are based on process IDs. For example, the process ID of init is 1. The files in this directory include the memory segments that make up the active process. The contents of each of these files include the active memory for that process.
The other items in the listing are files and directories that correspond to configuration information for components such as DMA channels or whole subsystems such as memory information.
Take a look at some of these files. For example, the /proc/meminfo file provides excellent information as to the state of memory on the local computer, as shown in Example 2. It can help you determine whether RHEL is having trouble detecting all of the memory on your computer.
Example 2. Detected memory information
$ \cat /proc/meminfo
MemTotal: 1048752 kB
MemFree: 46908 kB
Buffers: 160712 kB
Cached: 735564 kB
SwapCached: 0 kB
Active: 438248 kB
Inactive: 494976 kB
HighTotal: 311304 kB
HighFree: 14696 kB
LowTotal: 737448 kB
LowFree: 32212 kB
SwapTotal: 2031608 kB
SwapFree: 2031608 kB
Dirty: 48 kB
Writeback: 0 kB
AnonPages: 36800 kB
Mapped: 21612 kB
Slab: 43268 kB
PageTables: 2076 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 2555984 kB
Committed_AS: 113892 kB
VmallocTotal: 114680 kB
VmallocUsed: 4624 kB
VmallocChunk: 109876 kB
It can also help you measure the current memory state of your system. For example, if your system is overloaded, you’ll probably find very little free swap space. The HugePages settings are associated with over 4GB of RAM.
Now you can examine how Linux look at your CPU in the /proc/cpuinfo file, as shown in Example 3. In this particular case, the CPU family information is important; the CPU family value of 6 in this example corresponds to a 686 CPU. If you have a dual-core CPU (and both cores are detected), you will see two entries, even if you have only one physical CPU.
Example 3. Detected CPU information
$ \cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5345 @ 2.33GHz
stepping : 11
cpu MHz : 2327.504
cache size : 4096 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc up pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips : 5820.56
Many programs are available that simply look at the information stored in /proc and interpret it in a more readable format. The top utility is a perfect example. It reads the process table, queries RAM and swap usage and the level of CPU use, and presents it all on one screen.
IP Forwarding
More importantly, there are kernel variables that can be altered to change the way the kernel behaves while it’s running. Sometimes it’s appropriate to configure a Linux as a router between networks. By default, it does not forward TCP/IP information. You can confirm this with the following command:
# cat /proc/sys/net/ipv4/ip_forward
0
If your computer has two or more network cards, you may want to activate IP forwarding with the following command:
# echo 1 >> /proc/sys/net/ipv4/ip_forward
# cat /proc/sys/net/ipv4/ip_forward
1
Naturally, you will want to make sure the setting is confirmed the next time you boot by activating the net.ipv4.ip_forward directive in the /etc/sysctl.conf file.
The Linux kernel is stored in the partition with the /boot directory. New kernels must also be transferred to this directory. By default, RHEL configures a partition of about 100MB for this directory. This provides enough room for your current kernel plus several additional upgraded kernels.
The /proc Filesystem
The /proc directory is based on a virtual filesystem; in other words, it does not include any files that are stored on the hard drive. But it is a window into what the kernel sees of your computer. It’s a good idea to study the files and directories in /proc, as it can help you diagnose a wide range of problems.
Example 1. A Red Hat Enterprise Linux /proc directory
$ \ls /proc/
1 24 3120 3357 3640 crypto keys swaps
10 2415 3124 3388 3643 devices key-users sys
13871 2438 3147 3409 3655 diskstats kmsg sysrq-trigger
14238 259 3155 3445 3657 dma loadavg sysvipc
15843 262 3187 3446 3667 driver locks tty
17 292 3206 3457 4 execdomains mdstat uptime
18 2921 3222 3458 5 fb meminfo version
18263 2964 3248 3534 6 filesystems misc vmcore
18266 2966 3253 3539 7 fs modules vmstat
18267 2989 326 3543 85 ide mounts xen
18303 2993 3279 3546 86 interrupts net zoneinfo
19031 3 3291 3547 9 iomem partitions
196 3025 3305 3557 buddyinfo ioports schedstat
2 3054 3326 3558 bus irq self
22 3090 3334 3559 cmdline kallsyms slabinfo
233 3109 3345 3638 cpuinfo kcore stat
The numbered items are based on process IDs. For example, the process ID of init is 1. The files in this directory include the memory segments that make up the active process. The contents of each of these files include the active memory for that process.
The other items in the listing are files and directories that correspond to configuration information for components such as DMA channels or whole subsystems such as memory information.
Take a look at some of these files. For example, the /proc/meminfo file provides excellent information as to the state of memory on the local computer, as shown in Example 2. It can help you determine whether RHEL is having trouble detecting all of the memory on your computer.
Example 2. Detected memory information
$ \cat /proc/meminfo
MemTotal: 1048752 kB
MemFree: 46908 kB
Buffers: 160712 kB
Cached: 735564 kB
SwapCached: 0 kB
Active: 438248 kB
Inactive: 494976 kB
HighTotal: 311304 kB
HighFree: 14696 kB
LowTotal: 737448 kB
LowFree: 32212 kB
SwapTotal: 2031608 kB
SwapFree: 2031608 kB
Dirty: 48 kB
Writeback: 0 kB
AnonPages: 36800 kB
Mapped: 21612 kB
Slab: 43268 kB
PageTables: 2076 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 2555984 kB
Committed_AS: 113892 kB
VmallocTotal: 114680 kB
VmallocUsed: 4624 kB
VmallocChunk: 109876 kB
It can also help you measure the current memory state of your system. For example, if your system is overloaded, you’ll probably find very little free swap space. The HugePages settings are associated with over 4GB of RAM.
Now you can examine how Linux look at your CPU in the /proc/cpuinfo file, as shown in Example 3. In this particular case, the CPU family information is important; the CPU family value of 6 in this example corresponds to a 686 CPU. If you have a dual-core CPU (and both cores are detected), you will see two entries, even if you have only one physical CPU.
Example 3. Detected CPU information
$ \cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5345 @ 2.33GHz
stepping : 11
cpu MHz : 2327.504
cache size : 4096 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc up pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips : 5820.56
Many programs are available that simply look at the information stored in /proc and interpret it in a more readable format. The top utility is a perfect example. It reads the process table, queries RAM and swap usage and the level of CPU use, and presents it all on one screen.
IP Forwarding
More importantly, there are kernel variables that can be altered to change the way the kernel behaves while it’s running. Sometimes it’s appropriate to configure a Linux as a router between networks. By default, it does not forward TCP/IP information. You can confirm this with the following command:
# cat /proc/sys/net/ipv4/ip_forward
0
If your computer has two or more network cards, you may want to activate IP forwarding with the following command:
# echo 1 >> /proc/sys/net/ipv4/ip_forward
# cat /proc/sys/net/ipv4/ip_forward
1
Naturally, you will want to make sure the setting is confirmed the next time you boot by activating the net.ipv4.ip_forward directive in the /etc/sysctl.conf file.
Saturday, February 21, 2009
Kernel Services, Part 2
Best Practices
You should compile your kernel with only the elements you need. The more that is left out, the faster the whole system will run. For example, if there is no sound card, sound card support can be removed from the kernel. By removing unneeded devices, you will:
Generally, it is a good idea to have device drivers compiled as modules for any equipment that you may add in the near future. For example, if you may use your Linux computer as a router, you will need a second network card, and you can add support for that card to your kernel. For example, if you have a 3Com 3c595 network card installed but you also have some 3Com 3c905 cards in storage, it may be a good idea to include the 3c905 module. That way, you can simply swap in the new card and let the module load, causing minimum downtime.
Modules are kernel extensions. They are not compiled directly into the kernel but can be plugged in and removed as needed. When configured as a module, a hardware failure such as that of a network card will not cause the whole system to fail.
Kernel Concepts
You will need to understand some basic kernel concepts before you can compile your own kernel. Kernels can be organized as one big unit or as a lot of interconnected pieces. Kernels are called up by boot loaders when you start your system.
Monolithic Versus Modular
A monolithic kernel is a kernel in which all the device modules are built directly into the kernel. Modular kernels have many of their devices built as separate loadable modules. Monolithic kernels can communicate with devices faster, since the kernels can talk to the hardware only indirectly through a module table. Unfortunately, the typical monolithic kernel is huge, which reduces available RAM. In addition, some systems just can’t boot a kernel that’s too large.
Linux once had problems loading modular kernels for some hardware. What a monolithic kernel, the drivers are already there and are often more appropriate for certain components such as embedded hardware.
A modular kernel has greater flexibility. You can compile almost all drivers as modules, and then each module can be inserted into the kernel whenever you need it. Modules keep the initial kernel size low, which decreases the boot time and improves overall performance. If Linux has trouble loading a kernel module, you can use the modprobe or insmod command to load modules as needed, and add those options to the /etc/modprobe.conf file.
Updating the Kernel
Updating the kernel is not as difficult as it looks. You should never overwrite or upgrade an existing kernel, as mistakes happen. New kernels are handled by installing the newly built kernel in /boot and then adding another boot option to your boot loader configuration file (/boot/grub/grub.conf) for the new kernel.
If you install the new directly from a Red Hat configured RPM, it updates the boot loader automatically.
If you do make a drastic mistake and the kernel does not boot, you can simply reboot the system and select the old kernel from the GRUB menu. You should also save existing kernel configuration files so that you have a template for newer kernels. This is discussed in more detail later in future posts.
Other RHEL Kernels
There are a number of different kernels included with the RHEL installation files. You can and should install the kernel best suited to your system. Available RHEL 5 kernels are briefly discussed below. For the real versionnum, run the uname -r command. To verify your arch, or architecture (such as i686), run the uname -m command. As described in the table, there are different versions of kernel devel, kernel PAE, kernel xen, and kernel headers packages for each supported architecture.
The list provides just a short list of kernel packages available for RHEL 5. It does not include Xen-related kernels. For more information on RHEL kernels available for multi CPU or higher-end CPUs, refer to the RHEL documentation available online from www.redhat.com/docs/manuals/enterprise/.
You should compile your kernel with only the elements you need. The more that is left out, the faster the whole system will run. For example, if there is no sound card, sound card support can be removed from the kernel. By removing unneeded devices, you will:
- Decrease the size of the kernel.
- Provide a modest increase in speed for the devices that are present.
- Make more hardware resources available for other hardware such as network cards, disk controllers, and so on.
- Reduce the risk of hardware limits, such as those that may be based on the size of the compressed kernel.
Generally, it is a good idea to have device drivers compiled as modules for any equipment that you may add in the near future. For example, if you may use your Linux computer as a router, you will need a second network card, and you can add support for that card to your kernel. For example, if you have a 3Com 3c595 network card installed but you also have some 3Com 3c905 cards in storage, it may be a good idea to include the 3c905 module. That way, you can simply swap in the new card and let the module load, causing minimum downtime.
Modules are kernel extensions. They are not compiled directly into the kernel but can be plugged in and removed as needed. When configured as a module, a hardware failure such as that of a network card will not cause the whole system to fail.
Kernel Concepts
You will need to understand some basic kernel concepts before you can compile your own kernel. Kernels can be organized as one big unit or as a lot of interconnected pieces. Kernels are called up by boot loaders when you start your system.
Monolithic Versus Modular
A monolithic kernel is a kernel in which all the device modules are built directly into the kernel. Modular kernels have many of their devices built as separate loadable modules. Monolithic kernels can communicate with devices faster, since the kernels can talk to the hardware only indirectly through a module table. Unfortunately, the typical monolithic kernel is huge, which reduces available RAM. In addition, some systems just can’t boot a kernel that’s too large.
Linux once had problems loading modular kernels for some hardware. What a monolithic kernel, the drivers are already there and are often more appropriate for certain components such as embedded hardware.
A modular kernel has greater flexibility. You can compile almost all drivers as modules, and then each module can be inserted into the kernel whenever you need it. Modules keep the initial kernel size low, which decreases the boot time and improves overall performance. If Linux has trouble loading a kernel module, you can use the modprobe or insmod command to load modules as needed, and add those options to the /etc/modprobe.conf file.
Updating the Kernel
Updating the kernel is not as difficult as it looks. You should never overwrite or upgrade an existing kernel, as mistakes happen. New kernels are handled by installing the newly built kernel in /boot and then adding another boot option to your boot loader configuration file (/boot/grub/grub.conf) for the new kernel.
If you install the new directly from a Red Hat configured RPM, it updates the boot loader automatically.
If you do make a drastic mistake and the kernel does not boot, you can simply reboot the system and select the old kernel from the GRUB menu. You should also save existing kernel configuration files so that you have a template for newer kernels. This is discussed in more detail later in future posts.
Other RHEL Kernels
There are a number of different kernels included with the RHEL installation files. You can and should install the kernel best suited to your system. Available RHEL 5 kernels are briefly discussed below. For the real versionnum, run the uname -r command. To verify your arch, or architecture (such as i686), run the uname -m command. As described in the table, there are different versions of kernel devel, kernel PAE, kernel xen, and kernel headers packages for each supported architecture.
- kernel-versionnum.i686 - Designed for PCs with a single Intel/AMD CPU; also works with dual-core systems.
- kernel-versionnum.ia64 - Designed for Itanium2 systems.
- kernel-devel-versionnum - Installs drivers and other information to help compile third-party drivers.
- kernel-PAE-versionnum - If you have more than 4GB of RAM, install the PAE kernel associated with your CPU architecture.
- kernel-PAE-devel-versionnum - If you have more than 4GB of RAM, install the PAE kernel associated with your CPU architecture.
- kernel-headers-versionnum - Includes kernel headers; often sufficient for drivers.
- kernel-versionnum.src.rpm - Includes the source code for the RHEL kernel.
The list provides just a short list of kernel packages available for RHEL 5. It does not include Xen-related kernels. For more information on RHEL kernels available for multi CPU or higher-end CPUs, refer to the RHEL documentation available online from www.redhat.com/docs/manuals/enterprise/.
Sunday, February 15, 2009
Kernel Services, Part 1
I'm starting a new post on Kernel Services, in which you will learn how to upgrade standard kernels as well as configure, compile, and install your own custom kernels. You will see several different ways to customize and optimize your kernel configuration for size and functionality. Finally, you will examine recommended techniques for configuring and installing the kernel.
You will also discover how to manage and modify special partitions associated with RAID arrays and LVM filesystems. While it’s most efficient to configure these partitions during the installation process, you may have to modify them during your exam.
In several places in this Kernel Services, I embed a command such as `uname -r` in the name of a directory or file. This command substitutes itself in the name of directory or file. If unsure, run it in your own system.
The Basics of the Kernel
The kernel is the heart of the operating system. It manages communication with hardware, decides which processes to run, and provides each process with an isolated, virtual address space in which to run. The kernel is what the GRUB boot loader loads into memory. The kernel loads device driver modules. It also allocates hardware resources such as IRQ ports, I/O addresses, and DMA channels. A recompiled kernel can lead to:
Xen is based on a specially customized Linux kernel for virtual machines. The files associated with the Xen-based kernel are different from regular kernels.
In the Kernel Services, Part 2 we will discuss Best Practices and Kernel Concepts.
You will also discover how to manage and modify special partitions associated with RAID arrays and LVM filesystems. While it’s most efficient to configure these partitions during the installation process, you may have to modify them during your exam.
In several places in this Kernel Services, I embed a command such as `uname -r` in the name of a directory or file. This command substitutes itself in the name of directory or file. If unsure, run it in your own system.
The Basics of the Kernel
The kernel is the heart of the operating system. It manages communication with hardware, decides which processes to run, and provides each process with an isolated, virtual address space in which to run. The kernel is what the GRUB boot loader loads into memory. The kernel loads device driver modules. It also allocates hardware resources such as IRQ ports, I/O addresses, and DMA channels. A recompiled kernel can lead to:
- Greatly improved speed at which kernel services operate.
- Direct support for commonly used drivers.
- Dynamic loading of appropriate drivers as modules.
- Lower memory consumption by removing unneeded components.
- Support for high-end hardware, such as memory above 4GB, hardware array controllers, symmetric multiprocessing (multiple CPU) support, and more.
Xen is based on a specially customized Linux kernel for virtual machines. The files associated with the Xen-based kernel are different from regular kernels.
In the Kernel Services, Part 2 we will discuss Best Practices and Kernel Concepts.
Subscribe to:
Posts (Atom)
