ProductsDesktop Server For Scientific Computing For IBM POWER For IBM System z For SAP Business Applications Red Hat Network Satellite ManagementExtended Update Support High Availability High Performance Network Load Balancer Resilient Storage Scalable File System Smart Management Extended Lifecycle SupportWeb Server Developer Studio Portfolio Edition JBoss Operations Network FuseSource Integration Products Web Framework Kit Application Platform Data Grid Portal Platform SOA Platform Business Rules Management System (BRMS) Data Services Platform Messaging JBoss Community or JBoss enterprise
SolutionsApplication development Business process management Enterprise application integration Interoperability Operational efficiency Security VirtualizationMigrate to Red Hat Enterprise Linux Systems management Upgrading to Red Hat Enterprise Linux JBoss Enterprise Middleware IBM AIX to Red Hat Enterprise Linux HP-UX to Red Hat Enterprise Linux Solaris to Red Hat Enterprise Linux UNIX to Red Hat Enterprise Linux Start a conversation with Red Hat Migration services
TrainingPopular and new courses JBoss Middleware Administration curriculum Core System Administration curriculum JBoss Middleware Development curriculum Advanced System Administration curriculum Linux Development curriculum Cloud Computing and Virtualization curriculum
ConsultingStandard Operating Environment (SOE) Strategic Migration Planning Service-oriented architecture (SOA) Enterprise Data Solutions Business Process Management
Issue #2 December 2004
- Better Living Through RPM, Part 2
- How Red Hat Got Its Name
- Red Hat Summit: Bringing the Heat to the Big Easy
- Imagine Choice
- Improving Usability: Principles and Steps for Better Software
- Geek Giving Guide
- From Source to Binary: The Inner Workings of GCC
- Configuring Devices with udev
- Tux Paint: Mousing Your Way to a Masterpiece
- Unlimited Anytime Minutes: GnomeMeeting, the Softphone
From the Inside
In each Issue
- Editor's Blog
- Red Hat Speaks
- Ask Shadowman
- Tips & Tricks
- Fedora Status Report
- Magazine Archive
Tips & Tricks
Red Hat's customer service team receives technical support questions from users all over the world. As they are received, Red Hat technicians add the questions and answers to the Red Hat Knowledgebase on a daily basis. Individuals with a redhat.com login are granted limited access. Red Hat Enterprise Linux subscribers are granted full access — with expanded categories and advanced search capabilities. Every month, Red Hat Magazine offers a preview into the Red Hat Knowledgebase by highlighting some of the most recent entries.
What is an initscript service and how do I start and stop it?
by Gavin Romig-Koch
Linux has several methods for running programs automatically, without direct input from the user. One of these methods is the SysV initscripts. Programs started by these initscripts are called initscript services or simply services. Every initscript service has a name associated with it. You can get a list of the services installed on a system using the
An initscript service can be setup to run, or not run, automatically when the system is booted:
chkconfig <service-name> on
causes the service to start when the system is booted, and
chkconfig <service-name> off
causes the service to not be started when the system is booted. The
chkconfig command does not immediately start or stop a service, it only changes what happens to the service at the next reboot. To immediately start, stop, or check the current status of a service, use the
service <service-name> start service <service-name> stop service <service-name> status
For more information on the
chkconfig command, refer to the
chkconfig man page. For more information on SYSV initscripts in general, refer to the documentation included in the
How do I set the MTU for my network interface?
by Michael Kearey
The MTU can be set by editing the configuration file for the device. To see the devices you have use the
ifconfig -a command. The output should look similar to the following:
eth0 Link encap:Ethernet HWaddr 00:0D:61:93:55:3E inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:386423 errors:0 dropped:0 overruns:0 frame:0 TX packets:6490 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:203556104 (194.1 MiB) TX bytes:787293 (768.8 KiB) Interrupt:209 Memory:fb000000-0 eth1 Link encap:Ethernet HWaddr 00:40:F4:98:8E:43 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:185 Base address:0xa000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:36036 errors:0 dropped:0 overruns:0 frame:0 TX packets:36036 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:20683798 (19.7 MiB) TX bytes:20683798 (19.7 MiB)
Alternatively, you can use the
list command with the following output:
1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0d:61:93:55:3e brd ff:ff:ff:ff:ff:ff 3: eth1: mtu 1500 qdisc noop qlen 1000 link/ether 00:40:f4:98:8e:43 brd ff:ff:ff:ff:ff:ff
The interface eth0 has an MTU set to 1500 bytes. To change the setting temporarily (to 1200 in this example) issue the following command as root:
ip link set dev eth0 mtu 1200
To make the setting permanent for eth0, edit the configuration file
/etc/sysconfig/network-scripts/ifcfg-eth0 and add the line
MTU=1200 as shown below:
DEVICE=eth0 MTU=1200 BOOTPROTO=dhcp ONBOOT=yes TYPE=Ethernet
Then, restart the interface (as root):
service network restart eth0
The output of netstat -nr shows the value 0 for the MSS. What is the meaning of this value?
by Michael Kearey
The output of the
netstat -nr command
usually shows something like this:
Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 192.168.0.254 0.0.0.0 UG 0 0 0 eth0
The Maximum Segment Size (MSS) value of 0 shown from the
netstat command is intentionally wrong for any
type of network and is ignored by the kernel when a network connection
When the route MSS is zero, the MSS is determined by the kernel by looking at the MTU of the interface the packet is leaving on.
To view the settings for an interface use the
ifconfig eth0 command:
eth0 Link encap:Ethernet HWaddr 00:0D:61:93:55:3E inet addr:192.168.0.22 Bcast:188.8.131.52 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ...
The MSS value is calculated based on the formula
MSS = MTU - 40 bytes. So if a network interface has a MTU of 1500 bytes, the MSS will be calculated by the kernel as 1460 bytes. This is the advertised MSS value for the TCP connection and is used to tell the other end of the connection the preferred MSS we would like to receive. When a TCP connection is established, the MSS value is sent to the host we are connecting to in a SYN packet.
The route MSS (as shown in the
netstat -rn command) can be used to override the advertised MSS value calculated by the kernel. For example, if I wanted to force the MSS to 1200 bytes for all connections to the network 192.168.1.0/24 I could use the
ip route add 192.168.1.0/24 dev eth0 advmss 1200
I can also set the MSS value for particular hosts:
ip route add 192.168.0.212 dev eth0 advmss 1200
Note that this only affects the packets received, not the packets transmitted — the MSS value is an advertised value used to inform the other end of the connection what the system is able to receive.
The packets we transmit may have their MSS negotiated in a similar fashion, although this is not always the case, as the advertised MSS is optional. While Red Hat Enterprise Linux does add the MSS value to SYN and SYN-ACK packets, other TCP/IP implementations may not.
In general, if there is no advisory MSS value received, then it defaults to the minimum value of 536 (MTU 576 - 40 bytes = 536).
Also note that in addition to the MTU and route MSS values, Red Hat Enterprise Linux implements path MTU discovery, a simple protocol that tries to automatically determine the ideal MTU for a TCP connection.
There is rarely any need to alter the interface MTU or the route MSS value if path MTU discovery is working correctly.
How can I lookup package updates by relevant Common Vulnerabilities and Exposures (CVE) numbers?
by Chris Evich
If you are aware of specific CVE or CAN designations and need to search for packages affected by them, you can lookup this information from Red Hat Network (RHN). After logging in, replace the URL with one in the following format:
Where <CVE> is the designation you would like to find, followed by
Note: You can not lookup CAN designations in this manner as they are only candidates and have not actually been verified. If or when a CAN designation turns into a CVE designation, then you will be able to look it up in this manner. You can also search for these designations on the CVE website. If you would like more information related to security and Red Hat Enterprise Linux please visit our security site.
What is LD_ASSUME_KERNEL and what does it affect?
by Eric Paris
Here are a few details which should enable everybody to understand and investigate the issue of LD_ASSUME_KERNEL more closely.
- First, LD_ASSUME_KERNEL is handled by the dynamic linker.
- The behavior of a specific value of LD_ASSUME_KERNEL is not hardcoded in the dynamic linker.
- Every DSO (Dynamic Shared Object, aka shared library) can tell the dynamic linker in glibc which minimum OS ABI version is needed. Dynamic linkers other than glibc's do not have this feature. The information about the minimum OS ABI version is encoded in a ELF note section usually named .note.ABI-tag. This note section must be referenced by a PT_NOTE entry in the DSO's program header.
- The specific ABI version requirements on Red Hat Linux 9 and Fedora Core 1 and 2 system are as follows (this implies IA-32 is the architecture):
- DSOs in
/lib/tlsneed ABI version 2.4.20.
- DSOs in
/lib/i686need ABI version 2.4.1.
- DSOs in
/libneed ABI version 2.2.5.
Thus, a LD_ASSUME_KERNEL setting requesting versions earlier than 2.2.5 will not work at all. Versions 2.2.5 to 2.4.0 will use the DSOs in
/lib, versions from 2.4.1 to 2.4.19 will use the DSOs in
/lib/i686, and versions 2.4.20 and younger will use the DSOs in
For the Red Hat releases, this layout was chosen to provide the maximum amount of backward compatibility for broken applications (correctly written applications have no problems anyway). The code in
/libconsists of the very early LinuxThreads code which had fixed size threads which could not be placed by the application. The version in
/lib/i686is the LinuxThreads code which does away with this limitation (aka floating stacks). The code in
/lib/tlsis the new NPTL POSIX thread library.
- DSOs in
- The fact that a DSO has a more stringent version requirement does not mean it is automatically chosen. The dynamic only rejects loading DSOs based on the version information. It does not look for the best fit. The above description is true because the dynamic linker always looks in the directories
/libin this order. Why this is the case is complicated and not explained here. Read the dynamic linker source code.
- For architectures other than IA-32 the situation is similar, but less complicated. In Red Hat Enterprise Linux version 3 only two versions of glibc are needed, one using LinuxThreads and one using NPTL. The very old LinuxThreads code is not needed.
To examine the content of a DSO's note section use the
readelf program from
elfutils (the version from
binutils is not capable enough). On a Red Hat system the binary is called
eu-readelf. Using it on a Fedora Core 2 system shows the following:
eu-readelf -n /lib/tls/libc-2.3.3.so Note segment of 32 bytes at offset 0x174: Owner Data size Type GNU 16 VERSION OS: Linux, ABI: 2.4.20
This means the
/lib/tls/libc-2.3.3.so DSO requires at least OS ABI version 2.4.20.
How do I add ethtool settings to a network device permanently?
by Michael Kearey
ethtool can be used to set options for many types of Ethernet devices. The
/etc/sysconfig/network-scripts/ifcfg-ethX files can have the
ethtool settings added to them so that the settings are saved and used every time the device is activated.
For example, the command:
ethtool speed 100 duplex full autoneg off
sets the eth0 device to 100Mbs, full duplex, with auto negotiation off. To have the initialization scripts set this every time the eth0 device is activated, add a line to the
ETHTOOL_OPTS="speed 100 duplex full autoneg off"
How can I quickly tell what file systems my current kernel can handle?
by Kent Baxley
The kernel provides a list of file system types it is able to mount via the
/proc file system. To view the list, run the command
cat /proc/filesystems. The output will look something like:
nodev proc ext3 ext2 vfat iso9660 nodev nfs nodev smbfs
In this output, the entry vfat means you can mount FAT/VFAT (Microsoft Windows) partitions. The entries ending with smbfs and nfs mean you can interact with file servers that use SMBFS (Microsoft's Server Message Block File System, accessed via Samba) or NFS (Sun's Network File System). The iso9660 indicates that you can mount standard CD-ROM file systems, and ext3 and ext2 indicate that you can mount those kinds of Linux file systems.
In the first column, nodev indicates that the file system is not associated with a physical device, like the
/proc file system itself, which has information about state of the running kernel.
I downloaded an RPM to a Windows machine using Internet Explorer then transferred it to my Linux machine. When I try to install it with the RPM command, I immediately get a prompt back and it does not install. How can I fix this?
by Bradford Hinson
When downloading a file, Internet Explorer sometimes places square brackets in the resulting filename. When the
rpm command is run on a file with square brackets, it fails with no error message and does not install the package. The square brackets are a part of the Linux bash shell and are reserved for a technique called file globbing.
To fix this, rename the RPM with the
mv command. When specifying the filename of the RPM at a shell prompt, type the first few letters, then use the Tab key to autocomplete the name. This ensures that the brackets in the filename are properly delimited. Rename the file to so that it does not contain square brackets. For example:
mv kernel-2\[1\].4.21-20.EL.i686.rpm kernel-2.4.21-20.EL.i686.rpm
Alternatively, you can enclose the file in single quotes, like so:
mv 'kernel-2.4.21-20.EL.i686.rpm' kernel-2.4.21-20.EL.i686.rpm
After renaming the file, the
rpm command can be used to install the package successfully.
This article is protected by the Open Publication License, V1.0 or later. Copyright © 2004 by Red Hat, Inc.