Red Hat Enterprise Linux 3 does not ship with the ALSA subsystem. In order to get audio working in Red Hat Enterprise Linux 3, contact HP for an audio driver that will work with HP's xw4400, xw6400, xw8400 or xw9400 workstations.

Follow these steps to download the ALSA Drivers:

1. Visit the website that corresponds to the model:
   http://www.hp.com/support/xw4400
   http://www.hp.com/support/xw6400
   http://www.hp.com/support/xw8400
   http://www.hp.com/support/xw9400
2. select "Download drivers and software" under the "Tasks for HP xw{4,6,8}400 Workstation".
3. Select "Red Hat Enterprise Linux 3 (AMD64/EM64T)" or "Red Hat Enterprise Linux 3 (x86 or AMD64/EM64T)" according to the architecture, the machine with the sound problem has.
4. Select "Software" and then click on "Obtain software".

Release Found: Red Hat Enterprise Linux 4 Update 4

Symptom:
After installing the postfix package

Solution:

The tls session cache database format changed in the Red Hat Enterprise Linux 4 Update 4 postfix. The new postfix 2.2.x version does not support sdbm as a database type as the previous postfix 2.1.x did. The new database format is btree.

Replace 'sdbm:' with 'btree:' for the tls session cache database entries in /etc/postfix/main.cf:

The old versions:

smtpd_tls_session_cache_database = sdbm:/etc/postfix/smtpd_scache
smtp_tls_session_cache_database = sdbm:/etc/postfix/smtp_scache

The new versions:

smtpd_tls_session_cache_database = btree:/etc/postfix/smtpd_scache
smtp_tls_session_cache_database = btree:/etc/postfix/smtp_scache

Restart postfix:

# service postfix restart

Release Found: Red Hat Enterprise Linux 4

Symptom: X Window System clients are unable to get a graphical login from the server.

Solution:

Enable the X Display Manager Control Protocol (XDMCP) in GDM (the default X display manager). Note: XDMCP is by no means a secure protocol. It also tends to be quite bandwidth intensive. Make it secure and use less bandwidth by tunneling the connection over SSH with compression enabled. This article does not address these issues. This article also assumes that there is nothing network-wise blocking XDMCP, such as a firewall.

Assuming that the default X Display Manager is being used, run gdmconfig as root:

# gdmconfig

Uncheck "Always disallow TCP coonections to X server" under the security tab, and check "Enable XDMCP" under the XDMCP tab.

Restart GDM for the changes to take effect. Assuming that the system is already in runlevel 5, make sure that the user is not logged unto a X Window System session. Go to a virtual terminal by pressing CTRL+ALT+F1. Login as root, and execute the command:

killall gdm-binary

A remote session should be established using XDMCP to the system just configured. Test the setup locally by running the following command from a virtual terminal:

X -query localhost :1

1. Open the /etc/X11/gdm/gdm.conf file in a text editor.

   
   #vi /etc/X11/gdm/gdm.conf
   

2. Change Enable from false to true under [xdmcp] section.

   
   [xdmcp]
   # Distributions: Ship with this off.  It is never a safe thing to leave
   # out on the net.  Setting up /etc/hosts.allow and /etc/hosts.deny to only
   # allow local access is another alternative but not the safest.
   # Firewalling port 177 is the safest if you wish to have xdmcp on.
   # Read the manual for more notes on the security of XDMCP.
   
   Enable=true
   

3. Edit the file /etc/sysconfig/desktop and add the line given below if it is not already there:

   #vi /etc/sysconfig/desktop
   DISPLAYMANAGER="GNOME"
   

4. Edit the file /etc/inittab and change the runlevel to 5 if it is on some other level.

   vi /etc/inittab
   id:5:initdefault:
   ...
   # Run xdm in runlevel 5
   x:5:respawn:/etc/X11/prefdm -nodaemon
   

5. Re-examine the /etc/inittab file

   # init q
   

6. Test the settings:

   # X :1 localhost -query
   

Release Found:
Red Hat Enterprise Linux 4 Update 2

Symptom:
The following errors are generated while trying to update i386 packages on the IA64 system with ia32el running:

...
error: %postun(audiofile-0.2.6-1.i386) scriptlet failed, exit status 0
error: %postun(audit-libs-1.0.3-6.EL4.i386) scriptlet failed, exit
status 0
error: %postun(bash-3.0-19.2.i386) scriptlet failed, exit status 0
error: %postun(curl-7.12.1-5.rhel4.i386) scriptlet failed, exit status 0
error: %preun(dbus-0.22-12.EL.5.i386) scriptlet failed, exit status 0
...

Solution:
The update of many of the i386 packages depends on the ia32el package. So the ia32el package should be updated before updating the whole system.

# up2date ia32el
# service ia32el restart
# up2date

Some hardware platforms, such as IBM Bladecenters, implement the ASF Remote Management and Control Protocol in their firmware. This protocol uses TCP and UDP port 623. RPC services, such as RSH, use random ports between 600 and 699 to establish communication between client and server. If the client sends out a request on port 623, which is likely to happen at some point, the reply to that request will be diverted by the ASF protocol in the hardware. The client will therefore timeout while waiting for the reply, giving the error:

do_ypcall: clnt_call: RPC: Timed

In most cases, this should not cause a significant problem. However, in some cases an application can suffer performance degradations as a result of these timeouts. If this problem is impacting an application, the appropriate work around is to implement some iptables rules that re-route packets on port 623, so the ASF protocol doesn't "steal" them.

In the following example, the packets are temporarily diverted to port 599 (a randomly selected port with no assigned services):

# /etc/sysconfig/iptables

*nat
-A PREROUTING -p udp -m udp --dport 599 -j DNAT --to-destination :623
-A PREROUTING -p tcp -m tcp --dport 599 -j DNAT --to-destination :623
-A POSTROUTING -p udp -m udp --sport 623 -j SNAT --to-source :599
-A POSTROUTING -p tcp -m tcp --sport 623 -j SNAT --to-source :599

With the above iptables rules in place, the error should no longer appear, and any performance related side-effects should no longer present themselves.

At the time of installation, if GRUB detects another Operating System, it gives an option of selecting the default Operating System. If the default Operating System needs to be changed after the installation is finished, follow these steps:

1. Open the /etc/grub.conf file in a text editor:

   #vi /etc/grub.conf
   

   Note: /etc/grub.conf is a soft link to the /boot/grub/grub.conf file.
2. Change the default parameter and put the stanza number of the new operating system required as default. Here is an example for the process:
   1. Below is an example of the grub.conf file

      # grub.conf generated by anaconda
      #
      # Note that you do not have to rerun grub after making changes to this file
      # NOTICE:  You have a /boot partition.  This means that
      #          all kernel and initrd paths are relative to /boot/, eg.
      #          root (hd0,0)
      #          kernel /vmlinuz-version ro root=/dev/VolGroup00/Root
      #          initrd /initrd-version.img
      #boot=/dev/hda
      default=0
      timeout=5
      splashimage=(hd0,0)/grub/splash.xpm.gz
      
      title Red Hat Desktop (2.6.9-42.EL)		# Label for stanza 0
              root (hd0,0)
              kernel /vmlinuz-2.6.9-42.EL ro root=/dev/VolGroup00/Root rhgb quiet
              initrd /initrd-2.6.9-42.EL.img
      title Windows XP Pro				# Label for stanza 1
      	rootnoverify (hd0,0)
      	chainloader +1
      

   2. If the Red Hat Desktop is required as a default OS at boot time put:

      default=0
      

   3. If Windows XP Pro is required as a default OS at boot time put:

      
      default=1
      

3. Save the file and exit.

Now when the system restarts, changes will take effect and the system will boot to the new default Operating System.

Release found:
Red Hat Enterprise Linux 4
Red Hat Enterprise Linux 5

Solution:
The service pam_mkhomedir relies on the program doing the authentication (su, or login for example), to have enough permissions to create the home directories. This is not the case, as most authentication applications drops the permissions to avoid security problems.

To create home directories on-the-fly, use pam_oddjob_mkhomedir instead. In this case, the directory creation will be handled by a D-Bus service running as root instead.

• Update the oddjob package:

  up2date -i oddjob
  

• Restart D-Bus, this might require to restart some services that rely on D-Bus, such as hal:

  #service messagebus restart 
  
  

• Start the oddjob service:

  #service oddjobd restart 
  

• Make sure it runs on startup:

  #chkconfig oddjobd on 
  

• Modify the PAM configuration to use pam_oddjob_mkhomedir. For example, add this line at the bottom of /etc/pam.d/system-auth:

  session required /lib/security/$ISA/pam_oddjob_mkhomedir.so skel=/etc/skel/ umask=0022
  

Now to test if it is working, try to log in as a user that does not have a home directory.