mkinitrd --with=ehci-hcd --with=uhci-hcd  /boot/newinitrd-`uname -r`.img
`uname -r`

By default, the USB device is mounted as a vfat filesystem rather than ext3. The vfat filesystem has a maximum filesize limit of 4GB (minus 1 byte). Most filesystems are formatted to vfat because it works on multiple operating systems. However to copy a file larger than 4GB, it has to be changed to the ext3 filetype. The following steps will change the file system to ext3:

1. Backup all the data from the USB device.
2. Format the drive to be ext3 by running the following command:

   mkfs.ext3 /dev/[device_name]
   

   where [device_name] can be sdX

3. Remount it and then copy the file to the usb drive

Note: The Windows operating system will not read ext3 filesystems without third party applications.

One possible cause for this error is an incorrectly referenced rndc key. The rndc symmetric encryption key is contained in the /etc/rndc.key. This file is included into the /etc/named.conf bind nameserver and /etc/rndc.conf rndc utility configuration files. Bind and rndc use the rndc key to encrypt their communications.

By default, named.conf references the rndckey within the rndc.key file, as can be seen in this named.conf statement:

controls {
        inet 127.0.0.1 allow { localhost; } keys { rndckey; };
}

If named cannot find the rndckey in /etc/rndc.key, it will report the error 'rndc: connection to remote host closed'.

When using rndc-confgen -a to create a new rndc key, the new key will be called rndc-key by default. Therefore, the /etc/rndc.key file will need to be edited and the key name changed to rndckey for the sake of named. Likewise the command:

rndc-confgen -a -k rndckey

will give the key the correct name as referenced in named.conf.

Here are some points to keep in mind when setting up named and rndc:

• Ensure that the name of the rndc key referenced in named.conf is the same as the name of the key in /etc/rndc.key. This should berndckey.
• If using a chroot environment, make sure /etc/rndc.key is a soft link to /var/named/chroot/etc/rndc.key.
• Check the permissions and ownership of the rndc.key file. Permissions should be 640 with owner:group of root:named.

Enable the option "Run command as login shell" for gnome-terminal and LD_LIBRARY_PATH will be set in gnome-terminal. To enable the option follow the below procedure according to the requirnment:

• To set the login_shell to true on a per user basis, use the command below:

  $ gconftool-2 --set --type boolean /apps/gnome-terminal/profiles/Default/login_shell true
  

• To modify the settings as a default option on a system-wide basis, use the command below (all on one line):

  $ gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.defaults 
  	--set --type boolean /apps/gnome-terminal/profiles/Default/login_shell true
  

• To modify the settings as a mandatory option on a system-wide basis, use the command below (all on one line):

  
  $ gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory 
  	--set --type boolean /apps/gnome-terminal/profiles/Default/login_shell true
  

Note: gconftool-2 is a utility supplied in the GConf2 package.

A GFS filesystem can be mounted on one machine without the need to start the cluster services. The trick is to use the "lock_nolock" locking protocol.

There are a number of ways to do this:

1. Via gfs_tool
   1. Make sure that the GFS module is loaded:

      modprobe gfs
      

   2. To prepare GFS for the actual mount command, execute:

      gfs_tool margs lockproto=lock_nolock
      

   3. Mount the GFS filesystem, like so:

      mount -t gfs /dev/VolGroup00/LogVol01 /mount/point
      

      The gfs_tool command has to be performed for each GFS filesystem to be mounted. For example:

      gfs_tool margs lockproto=lock_nolock
      mount -t gfs /dev/VolGroup00/LogVol02 /mount/data
      gfs_tool margs lockproto=lock_nolock
      mount -t gfs /dev/VolGroup00/LogVol03 /mount/shared
      

2. Directly mounting

   Another way to achieve the same result is to pass the lockproto option during mounting. The example above can be accomplished with the following commands:

   mount -t gfs /dev/VolGroup00/LogVol02 /mount/data -o lockproto=lock_nolock
   mount -t gfs /dev/VolGroup00/LogVol03 /mount/shared -o lockproto=lock_nolock
   

   Again, make sure that the gfs module is loaded before mounting.

Note: This proves useful for situations where the cluster is down and data needs to be accessed from GFS or for back-up purposes. Another machine with an attached tape device can also mount the gfs and back it up.

Warning: Although the gfs mount will be accessible to other machines, do not mount with the lock_nolock option on multiple machines at the same time or the data will be corrupted.

The Sockets Direct Protocol (SDP) is a protocol that maps standard socket operations onto native InfiniBand Remote Direct Memory Access (RDMA) operations. This allows socket applications to run unchanged and still receive most of the performance benefits of Infiniband.

As of Open Fabrics Enterprise Distribution (OFED) version 1.0 (which will be available on Red Hat Enterprise Linux 4.5 and Red Hat Enterprise Linux 5), the SDP kernel code can only support approximately 800 simultaneous connections being open. If more connections are needed, SDP should not be used. Either IP over InfiniBand (IPoIB) or direct RDMA via one of the various other methods should be chosen as an alternative. This limitation has been removed in the upstream OFED 1.1 release, and will be removed from Red Hat products when the OFED 1.1 code is released as part of a regular update to Red Hat Enterprise Linux 4 and Red Hat Eneterprise Linux 5.

Release Found: Red Hat Enterprise Linux 4

Assumption:

This article assumes that there is a correctly configured LDAP server.

On the LDAP server:

1. Define three users, two users will be in a netgroup called "myadmins" which will have access to specified system and the 3rd which will not have access to system for testing purposes.
2. Create an Organizational Unit "netgroup". For example:

   dn: ou=netgroup,dc=example,dc=com
   objectClass: organizationalUnit
   ou: netgroup
   

3. Define the netgroup entry containing the nisNetgroupTriple which is in the format of (host,user,NIS-domain). This example focuses on the user only:

   dn: cn=myadmins,ou=netgroup,dc=example,dc=com
   objectClass: nisNetgroup
   objectClass: top
   cn: myadmins
   nisNetgroupTriple: (-,user1,-)
   nisNetgroupTriple: (-,user2,-)
   

On the Client:

1. Modify /etc/ssh/sshd_config to use PAM for authentication:

   UsePAM yes
   

2. Modify /etc/ldap.conf to provide the correct search suffix for the netgroup:

   nss_base_netgroup ou=netgroup,dc=example,dc=com?one
   

3. Modify /etc/nsswitch.conf to query the LDAP server for netgroup information:

   netgroup: ldap
   

4. Modify /etc/security/access.conf to allow only local logins and "myadmins" netgroup access:

   +:ALL:LOCAL
   +:@myadmins:ALL
   -:ALL:ALL
   

5. Modify /etc/pam.d/system-auth to require the pam_access.so module. The account stack should reflect something like this:

   account required /lib/security/$ISA/pam_unix.so
   account [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] /lib/security/$ISA/pam_ldap.so
   account require /lib/security/$ISA/pam_access.so
   

6. Test the setup by logging in via a ssh client with "user1","user2", and the user not in the netgroup "myadmins".