Adventures In Tech

Icon

A technology blog by Ross Macduff

November 3, 2009 • 5:51 pm 2

Changing LVM volume group name on RHEL 5.4

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 , ,

October 14, 2009 • 9:01 pm 0

Quick and dirty python packaging

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 , , ,

October 8, 2009 • 1:08 pm 0

Gnome notifier for Request Tracker (RT)

I’ve got a little plugin going for the Gnome Notification Area that shows tickets for Best Practical’s Request Tracker.   You can get it here: http://github.com/rmacduff/rt-notify

It’s still very immature right now so I will be updating it a bit over the next little while.

Filed under: opensource , , , ,

June 17, 2009 • 11:46 am 0

Include a time stamp with pings

It might be useful to include an absolute time stamp when pinging multiple hosts so as to be able to make a correspondance later on.  This is what I put together in a hurry that does the trick.

while test 0; do  DATE=$( date | tr -d '\n' ); \
PING=$( ping -c 1 192.168.1.100 | grep from ); \
( echo $DATE $PING; sleep 1 ) | tee -a /path/to/log ; done

Got a better way to do this? Post a comment.

Filed under: network , , ,

June 9, 2009 • 10:24 pm 0

Problem downloading src rpms from RHN

I mentioed in a previous post how cool it was that you can download src rpms with yumdownloader.   I didn’t realize until a couple of days ago that it is not able to grab src rpms from the Redhat Network – at least the way my RHEL 5.3 yum config is setup.

Following the suggestion here I added a repo config file specifying the location to grab the src rpms, but that was unsuccessful.

I decided to take a look at the code behind the tool (/usr/bin/yumdownloader) and this is what I found:

# Ok, we have src and bin repos. What we want to do here is:
#
# 1. _enable_ source repos for which the bin repos are enabled.
# 2. _disable_ the _other_ src repos.

(this is from the version of yumdownloader that comes with yum-utils-1.1.16-13.el5.noarch)

So only source repos must be paired up with “bin” repos. That explains why the previous attempt to solve this problem didn’t work as it was a standalone repository.

So why not add a source repo section to the config for the Redhat Network repo? Well, the Redhat Network repo settings come as a part of a plugin (rhnplugin) that does not have repo config files that you would see in /etc/yum.repos.d. From inspecting the /usr/lib/yum-plugins/rhnplugin.py I also didn’t see anything related to src rpms (though I did only a cursory inspection).

The solution I put in place was to setup a dummy (empty) yum repository to pair up with the src repo. This just requires running ‘createrepo .’ in an empty web accessible directory. With that in place the following config worked:

[rheld]
name=Red Hat Dummy
baseurl=http://your.domain.com/yum/dummy/
failovermethod=priority
enabled=1
gpgcheck=0

[rheld-source]
name=Red Hat Enterprise Linux $releasever - $basearch - Source
baseurl=ftp://ftp.redhat.com/pub/redhat/linux/enterprise/$releasever/en/os/SRPMS/
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

Filed under: Sysadmin , , , ,

May 29, 2009 • 1:20 pm 0

Keychain’s –clear option

I find it hard to live without Keychain on my workstations.  It makes adding and managing keys for ssh-agent a no-brainer.  But along with that ease of use comes a risk: as long as the key(s) have been decrypted then anyone that gains access to your account can access the same systems you can with your keys.

When I remembered, I would use ’ssh-add -x’ to lock the agent if I knew I would be away for while, but that has obvious problems for someone with a memory such as mine, it also doesn’t protect from an intruder accessing the system unbeknownst even while you are using it.

This is exactly what the ‘–clear’ option for Keychain solves.  It adds a bit of an inconveniece to the user as he or she now needs to enter the password for the key(s) every time a new session is started, but it will prevent any unauthorized guests from accessing your unencrypted private keys.

Filed under: security , , ,

May 28, 2009 • 2:19 am 0

Rsnapshot with EncFS

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 , , , ,

March 12, 2009 • 3:50 pm 1

Problem upgrading rpm package

Found a couple of new tools for Redhat boxes.  Here’s the story about how I came across them.

dbus-devel needed to be updated on a RHEL 5 box but when I tried to do a yum update things would bail out towards the end of the process with:

Error unpacking rpm package dbus-devel-1.1.2-12.el5.i386
error: unpacking of archive failed: cpio: lstat

Googling for similar unpacking/cpio errors showed that this was not uncommon.  In most cases it is because of  some funkiness with a directory that needs to be written to during unpacking. I initially tried to debug the issue with strace, but thought there must be an easier way.

The next thing I did was remove the offending package and try to re-install it with:

rpm -e --nodeps dbus-devel
yum install dbus-devel

This got me nowhere.  Knowing that there might be some messed up folder that needed to be unpacked to I wanted to see what files and folders dbus-devel created.   The command for this is

rpm -qpl <package.rpm>

But of course I didn’t have the rpm sitting around and I didn’t feel like going to the RedHat Network to fetch it. This is where the yum plugin yum-downloadonly comes in handy. This can be installed with

yum install yum-downloadonly

This gives the added options to yum:

--downloadonly
--downloaddir==/path/to/pkg

Now you can download the rpm without installing it. With this I could check out what files and directories dbus-devel wanted to add. I went through these one-by-one checking them out and removing them (making sure the directories were not referenced by another package: rpm -qf /path/to/dir). I did find the culprit: the directory /usr/share/devhelp had become corrupted so dbus-devel could not unpack there. I removed that directory and dbus-devel installed perfectly after that.

Afterwards I found another set of tool that allows one to download rpms from a repository: yumdownloader. It’s a part of the yum-utils package (yum install yum-utils). This nice thing about this one is that it allows you to download src.rpms too.

References:

1. http://www.cyberciti.biz/faq/yum-downloadonly-plugin/

Update 2009-03-13: To retrieve a pacakge (that has been installed) another option is to configure yum to cache headers and packages.  In yum.conf set keepcache=1, then look in /var/cache/yum for the package.

Filed under: Sysadmin, redhat, rpm, yum

November 12, 2008 • 8:24 pm 0

DMA disk kernel errors

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

  1. AT Attachment, http://en.wikipedia.org/w/index.php?title=AT_Attachment&oldid=250645856 (last visited Nov. 13, 2008).
  2. man hdparm

Filed under: Hardware, Sysadmin, linux

Meta

Blogroll