Changing the Volume Group Name

One of the problems with cloning a system is that it has the same volume group names as the server it was cloned from.  Not a huge problem but it can limit your ability to leverage the volume group.  The fix appears easy but there is a gotcha.

RedHat provides a nice utility: vgrename

If you use that command and think you are done, you will be sorely mistaken if your root file system is on a volume group!  I’m speaking from experience there, so listen up!

If you issue the vgrename command:

# vgrename OldVG_Name NewVG_Name

it works like a charm.  If you happen to reboot your system at this point you are in big trouble… The system will Kernel Panic.

If you updated/changed the name of the VG that contains the root file system you need to modify the following two files to reflect the NewVG_Name.

  1. In /etc/fstab.   This one is obvious and I usually remember.
  2. In /etc/grub.conf.  Otherwise the kernel tries to mount the root file-system using the old volume group name.

The change is easy using ‘vi’.  Open the file in vi, then use sed from within vi; for example:

vi /etc/fstab

Don’t forget to save the changes.

Increasing the size of a filesystem


fdisk -l
fdisk /dev/sdc

In fdisk

p  (print the partition table to make sure the disk is not in use)
n (new partition)
p (primary partition)
1 (give it a number 1-4, then set start and end sectors)
w (write table to disk and exit)

Now create a physical volume, add it to the VG, extend the LV and then the file system.

pvcreate /dev/sdc1
vgextend VG_NAME /dev/sdc1
lvextend -L+5G LV_PATH (i.e.: /dev/VG_NAME/LV_NAME)
resize2fs LV_PATH
(OR if using xfs: xfs_grow LV_PATH)


Other useful commands when working with disks include:

# lsblk
NAME                             MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sr0                               11:0    1  1024M  0 rom  
sda                                8:0    0 501.1M  0 disk 
└─sda1                             8:1    0   500M  0 part /boot
sdb                                8:16   0  29.5G  0 disk 
└─sdb1                             8:17   0  29.5G  0 part 
  ├─vg_name-lv_root (dm-0) 253:0    0  40.6G  0 lvm  /
  └─vg_name-lv_swap (dm-1) 253:1    0   3.7G  0 lvm  [SWAP]
sdc                                8:32   0    20G  0 disk

The lsblk will list all block devices.  Above it is an easy way to see disks, disk usage and LVM affiliations.  Of course if you just want the block device names this will work too:

ls /sys/block/* | grep block | grep sd


Extended ACLs

To remove permanently ACL from a file:

# setfacl -bn file.txt

To remove permanently ACL from an entire directory:

# setfacl -b --remove-all

To overwrite permissions, setting them to rw for files and rwx for dirs

$ find . ( -type f -exec setfacl -m g:mygroup:rw '{}' ';' ) 
      -o ( -type d -exec setfacl -m g:mygroup:rwx '{}' ';' )

To set mygroup ACL permissions based on existing group permissions

$ find . ( -perm -g+x -exec setfacl -m g:mygroup:rw '{}' ';' ) 
      -o ( -exec setfacl -m g:mygroup:rwx '{}' ';' )

You’ll probably want to check that the group mask provides effective permissions. If not you can do it the old school way and run this too:

$ find . -type d -exec chmod g+rwX '{}' ';'


Fixing Authentication refused: bad ownership or modes for directory

When this error:

Authentication refused: bad ownership or modes for directory

Shows up in /var/log/messages

When trying to setup public key authenticated automatic logins, the problem is a permissions one.

You’ll need to perform the following commands on the user account you are trying to setup:

chmod go-w ~/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

X11 error on login to RedHat Servers

I noticed that since the last set of patches many of my redhat 6 systems are reporting an X11 forwarding error after login:

X11 forwarding request failed on channel 0

To correct this problem you need to install the following package

yum install xorg-x11-xauth

I have not had the time to investigate why this is suddenly a problem.  When I have time I’ll report back the why.

External Mapping of LDAP attributes in CAS

One of the features that is attractive about CAS is it’s ability to pass LDAP attributes to a specified application via SAML. This functionality is starting to become more heavily used by our web developers, creating demand for more and more attributes to mapped. An issue arose from this; CAS must be rebuilt every time a new attribute is to be mapped. The solution was to externalize the resultAttributeMapping property to a configuration file. This can be achieved through the use of the util schema.

Add the schema to deployerConfigContext.xml:


Append the following to schemaLocation:

The resultAttributeMapping property (in deployerConfigContext) will look like this:

<property name="resultAttributeMapping">
<util:properties id="attr" location="file:/etc/cas/ldap.attributes" />

Your attributes file cannot contain other property configurations, due to how the file is referenced.  It is a collection that follows the form: key=value, with each entry placed on its own line.  Here is an example ldap.attributes property file: