November 3, 2009 • 5:51 pm
I have on occasion wanted to change the name of an LVM volume group (vg) name. This is not so hard, but if the logical volumes are mounted as system filesystems (/ /var /usr etc) then it’s a bit more trouble. The following was performed on a Redhat Enterprise Linux 5.4 server, but similar steps could be followed on other systems
If the logical volumes could just be deactivated then ‘vgrename’ could be run on the live system. Since / (or /var, /usr) cannot just be unmounted the system has to be rebooted in rescue mode. The first install disk of RHEL will allow you to do this. Make sure that you tell it not to detect any installs of RHEL so that the LVM stuff is not activated. Once you get a shell prompt verify that the volume group is detected (vgscan) and that none of it’s logical volumes are active (lvscan). vgrename can now be run:
vgrename <current vg name> <new vg name>
Before rebooting a little cleanup needs to be done. Entries in /etc/fstab have to be changed to reflect the new volume group name and a new initial ramdisk has to be created. The easisest way to do this is to reboot into rescue mode and let it detect the install of your RHEL system. Once the shell comes up chroot into the mounted root (assuming the RHEL install was detected). This should be:
chroot /mnt/sysinstall
Now edit /etc/fstab. Then run:
mkinitrd –fstab=/etc/fstab <image name> <kernel version>
You should also edit your grub menu.ls to reflect the new name of the volume group that the root file systems is in.
That’s it! Now reboot and the new volume group name will be in effect.
Filed under: linux , lvm, redhat
October 14, 2009 • 9:01 pm
As a sysadmin I always recommend the use of a system’s packaging tools to install software, tools, etc. That goes for installing python packages too. Python’s setuptools can be combined with the very handy checkinstall tool to create and install python packages via your linux system’s package management suite (apt, rpm, installpkg).
It’s as easy as running the following command from within the python package’s setup directory and following the prompts to provide the package details:
checkinstall python setup.py install
Of course, this assumes the package was setup to be installed with setuptools. The man page provides some useful options.
Filed under: linux , packages, python, setuptools
I have an external USB drive that I have been putting backups of my workstation on using Rsnapshot. It’s been bugging me for a while that it would be so easy for an intruder to grab it and be off with all my data. Encryption to the rescue.
I have been using EncFS for a couple of other things and realized it would be quite easy to set up for this situation. I won’t go into the details of setting that up since it has been covered in many places.
Anyhow, I thought it would be a simple matter of setting up the Encfs file system, rsyncing the old backups to the new encrypted file system and letting the backups continue. Life is never so simple. During the rsyncing I was getting errors about failed link operations. (I chose the use the -H option to preserve hardlinks since that’s part of what makes using rsnapshot so great.)
I was quite baffled by this. Initially I thought it was a bug or a deficiency with EncFS or FUSE. A bit of digging about and I realized that going with the “pre-configured paranoia mode” enables this thing called External IV Chaining. In simple terms this ties the file contents to the file name and in turn prevents hard linking. The man page for EncFS explains this in more detail.
Solution: re-setup the encrypted file system selecting the “expert configuration mode” and disabing External IV Chaining.
Now the data on my external drive is visible only with the correct password. Go ahead, steal it!
Filed under: linux, security , backups, encryption, fuse, security
November 12, 2008 • 8:24 pm
At work I was seeing the following errors in /var/log/messages on a RHEL5 box
Nov 2 10:35:26 host kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Nov 2 10:35:26 host kernel: hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
Nov 2 10:35:26 host kernel: ide: failed opcode was: unknown
My initial thought was that this was a sign of a failing disk so I ran smartctl on it. The results of that showed that the drive was healthy. A quick google indicated that these errors indicate an issue with incorrectly set DMA parameters.
When I set this box up I failed to notice that hdc was attached to the bus with a 40-pin cable. For some reason the kernel was not seeing this limitation during boot and incorrectly set the drive to use UDMA mode 4, which as far as I know is not possible with a 40-pin cable. I manually set the drive to use UDMA mode 2 with
hdparm -X udma2 /dev/hdc
After that, the errors were no longer showing up.
I wasn’t sure if the bus that this drive was on supported higher UDMA transfer rates so I put in an 80-pin cable. The system came up and strangely enough the drive was seen as supporting only UDMA2. That indicated to me that the bus could not support the higher UDMA rates so I put the 40-pin cable back in.
Now when the system came back up it was automatically setting it at UDMA3. Now this was the same setup I had when the drive was being seen as supporting UDMA4. This time, though, there were none of the above errors in the logs, so I was happy.
Still I am not sure how UDMA3 was being supported on a 40-pin cable. I thought that an 80-pin cable was required. Need to read more on the ATA specs.
References
- AT Attachment, http://en.wikipedia.org/w/index.php?title=AT_Attachment&oldid=250645856 (last visited Nov. 13, 2008).
- man hdparm
Filed under: Hardware, Sysadmin, linux
