September 28, 2006

Tips & tricks

Red Hat's customer service and support teams receive technical support questions from users all over the world. Red Hat technicians add the questions and answers to Red Hat Knowledgebase on a daily basis. Access to Red Hat Knowledgebase is free. Every month, Red Hat Magazine offers a preview into the Red Hat Knowledgebase by highlighting some of the most recent entries.

Tips from RHCEs

Using proc

In /proc, there are subdirectories for each process running on the system, named based on the PID number of the process. In each of these directories, there is a fd/ subdirectory that contains files which represent the file descriptors the process currently has open. These files are actually symlinks which point to the actual device, socket, or other file the process currently has open and mapped to that file descriptor.

If you have a program which can read input from a file but not from standard input, or which can write to a file but not to standard output, you may be able to cheat by taking advantage of these special files:

/proc/self/fd/0 is standard input of the current process
/proc/self/fd/1 is standard output of the current process
/proc/self/fd/2 is standard error of the current process

For example if 'myfilter' can only read from a file, which it takes as its first argument, you can make it read from standard input instead with:

'myfilter /proc/self/fd/0'

Another example: 'cat filename > /proc/self/fd/2' sends the contents of filename out standard error instead of standard output.

Whether these tricks will behave in a sane manner will depend on how the process actually handles the file it opens.

I am getting traceback emails with message 'ORA-01654: unable to extend index RHNSAT.RHN_PACKAGE_FILE_CID_PID_IDX by 16 in tablespace DATA_TBS', how do I resolve this?

This problem arises if the tablespace within the Embedded Oracle database has become 100% full. Verify that it is 100% full by running the command:

su -l oracle -c 'db-control report'

NOTE: Due to a bug in db-control for earlier RHN Satellites, if the output of this command does not contain a row for DATA_TBS tablespace, then assume that the tablespace is full.

If the output of this command shows that the DATA_TBS is 100% then proceed to add more space using command below.

There is currently no supported method to automate the extension of tablespaces; however, the following command will effect the extension:

su -l oracle -c 'db-control extend DATA_TBS'
Each usage of the 'extend' option to the db-control command will add another 512MB of space to the database on the tablespace specified. Re-run db-control with the report option to verify the new current space usage.

How can I configure the Apache httpd server to use SSL to communicate with an LDAP server when authenticating HTTP clients?

Release Found: Red Hat Enterprise Linux 3 and 4

The Apache webserver supports various methods of requiring HTTP clients to authenticate before being able to access protected areas, including using an LDAP directory containing users and their passwords.

While the mod_authz_ldap Apache LDAP authentication module is available as an optional RPM that is capable of non-SSL-enabled LDAP authentication or certificate-based client authentication, mod_authz_ldap does not support use of SSL or TLS to encrypt its communications with LDAP servers. The standard mod_ldap.so and mod_auth_ldap.so LDAP and LDAP Authentication modules which are provided in the base httpd server daemon package in Red Hat Enterprise Linux versions 3 and 4 support using SSL to communicate with the LDAP server. Therefore it is not necessary to have the mod_authz_ldap RPM installed to achieve this configuration goal.

The following are excerpts from an example Apache /etc/httpd/conf/httpd.conf configuration file which show the configuration statements needed to enable Apache to communicate with the LDAP server using SSL. The example below will cause the entire /var/www/html directory structure to be protected by requiring connecting clients to authenticate:

First, make sure httpd.conf still contains the two lines which instruct httpd to load the needed LDAP modules:


LoadModule ldap_module modules/mod_ldap.so
LoadModule auth_ldap_module modules/mod_auth_ldap.so

NOTE: The two lines above already exist in the default httpd.conf configuration file provided with the httpd package and should not need to be added unless they are missing.

The following two Apache configuration file statements can only be defined once per server and therefore must be located in the main section of httpd.conf, not inside a <Directory> or <VirtualHost> container or .htaccess file:

# Path to the Certificate Authority (CA) certificate used to sign the LDAP
# server's certificate.  The file must be readable by user httpd runs as
# (normally user apache):
LDAPTrustedCA /etc/openldap/cacerts/my-ca.crt

# The format of the file defined above.  BASE64_FILE should be correct
# in most cases:
LDAPTrustedCAType BASE64_FILE

The following statements can be used in a <Directory> container as shown in the example below. Other possibilities exist, such as placing the same configuration statements in an .htaccess file to protect a particular directory underneath the DocumentRoot, or within a <VirtualHost> container to protect the entire virtual host. Note that in the case of using an .htaccess file to configure per-directory authentication, the configuration of the immediate parent container must include AuthConfig among the AllowOverride options.

<Directory "/var/www/html">

Options Indexes FollowSymLinks

AllowOverride None

Order allow,deny

Allow from all

AuthLDAPAuthoritative on

AuthLDAPEnabled on

AuthType Basic

AuthName "Restricted Area"
# The following two lines are an example of providing a username
# and password of a user with read access to the LDAP directory
# in case the server is configured to not allow anonymous binds,
# and may be necessary for some environments:
#AuthLDAPBindDN "uid=ldapauthuser,ou=People,dc=example,dc=com"
#AuthLDAPBindPassword "secretpassword"

# The AuthLDAPUrl statement below defines the LDAP server to use as
# myldapserver.example.com, sets the search base to start searching
# for users at to ou=People,dc=example,dc=com, defines the attribute
# to match the username provided by the user as uid, and defines a
# subtree-type search to be used to locate the user's entry in the
# LDAP directory:
AuthLDAPUrl "ldaps://myldapserver.example.com:636/ou=People,dc=example,dc=com?uid?sub"

# This tells HTTP to only allow access if they can authenticate:
require valid-user

</Directory>

For further information on Apache configuration syntax, refer to the Apache documentation.

Why does updating my Red Hat Enterprise Linux 4 system to the latest packages for Update 4 fail with unresolved dependencies with an error indicating that the kernel-ib package is required?

Release Found:Red Hat Enterprise Linux 4 on i386, ia64, and x86_64

Symptom:
Attempting to update my system to the latest Red Hat Enterprise Linux 4 packages, up2date fails to resolve dependencies. The error message indicates that the kernel-ib package is required. A sample error message will look like below (also see attached screenshot for sample error message):

  There was a package dependency problem. The message was:
        
        Unresolvable chain of dependencies:
        libibcommon  1.0-1                       requires kernel-ib
        libibumad  1.0-1                         requires kernel-ib
        libibverbs  1.0.3-1                      requires kernel-ib
        libibverbs-utils  1.0.3-1                requires kernel-ib
        libmthca  1.0.2-1                        requires kernel-ib
        libsdp  0.9.0-1                          requires kernel-ib
        opensm  1.2.0-1                          requires kernel-ib
        opensm-libs  1.2.0-1                     requires kernel-ib
      

Solution:
Starting with Red Hat Enterprise Linux 4 Update 4, OpenIB Infiniband support was separated into multiple packages. One of these packages is called "kernel-ib".

The default configuration for the up2date client will exclude any packages matching the glob "kernel*". To confirm if the settings exclude packages matching the glob "kernel*", run the command:

        # echo | up2date --configure --nox | grep pkgSkipList
        20. pkgSkipList        ['kernel*']

If using a similar configuration as noted above, and would like to install the kernel-ib package, modify the pkgSkipList configuration.

Remove the string "kernel*" from the pkgSkipList by running the command:

        
        # up2date --configure 

Now, run up2date again to upgrade the packages to the latest available packages on RHN.

NOTE: If you would like the up2date client to skip kernel packages in the future, yet continue to update the kernel-ib OpenIB Infiniband package, consider setting the pkgSkipList to the following:

        
        # echo | up2date --configure --nox | grep pkgSkipList
        20. pkgSkipList        ['kernel', 'kernel-smp', 'kernel-hugemem', 'kernel-largesmp']

Can I use LVM to do host-based mirroring?

Yes. Create a new logical volume that is mirrored by adding a '-m1' parameter to the creation command. For example:

lvcreate -m1 -L 1G -n my_new_lv my_vg

The '-m1' means "add 1 copy to the logical volume". It is also possible to convert an existing linear volume to a mirrored volume.

lvconvert -m1 my_vg/my_existing_lv

There are limitations when using LVM mirroring:

  1. Creating mirrors of striped logical volumes or snapshot logical volumes should not be done. Similarly, creating snapshots or striped logical volumes of mirrored logical volumes should not be done. This is not supported, and may not provide the intended redundancy.
  2. Add 'vgchange --monitor y' to /etc/rc.local file. Failure to do so will result in the LVM not removing failed devices from the volume group.
  3. Three devices are needed to create a two-way (-m1) mirror - two devices for the mirrors and one for the log device.

The information provided in this article is for your information only. The origin of this information may be internal or external to Red Hat. While Red Hat attempts to verify the validity of this information before it is posted, Red Hat makes no express or implied claims to its validity.

This article is protected by the Open Publication License, V1.0 or later. Copyright © 2006 by Red Hat, Inc.