Zelut’s Blog

I setup a new Desktop at work today and I thought I’d try out Arch again.  I’ve had it running on my work Laptop for a few months now, but there were some things I wanted to figure out and learn, “The Arch Way”.  One of the little tips that I found in my continued reading and setting up was the use of the rankmirrors tool.  Rankmirrors will find and configure your system to use the fastest repository mirrors for your connection.

Getting Started

Let’s assume you’re on a fresh installation.  If not, the steps are really the same, you just likely don’t have to worry about resolving the dependencies.  So, on that note, the only dependency for the tool is python.  If you don’t have python installed (which is likely only the case if you’re on a fresh installation), you’ll need to install it:

pacman -S python


Running Rankmirrors

Rankmirrors will read a copy of the mirrorlist file and output an updated, ranked mirrorlist file.  To do this cleanly, in the fewest steps, well move the original file which is what we’ll read from and then output to the file we’ll end up using.

mv /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.orig
rankmirrors -n3 /etc/pacman.d/mirrorlist.orig > /etc/pacman.d/mirrorlist


This will take a little time to run through the list and compare the results, but when it is finished you’ll have a mirrorlist file that is optimized for your connection.  You’ll also notice that I used the “-n3″ option, which tells it to output the three fastest repository mirrors.  You can change this number based on your needs.

Also, anytime you update or change your repository mirror you’ll want to make sure pacman is updated accordingly.  Run the following command anytime you make changes to your mirror:

pacman -Syy


This afternoon I was doing a little reading about the best method for installing Arch Linux on LVM.  The process is easy if you’re familiar with LVM–if you’ve setup LVM manually.  If you don’t understand how LVM works or if you’ve only ever done automated or graphical LVM creation it’ll be more work.  It has to be done manually and outside of the main setup utility.  In any event, an explanation of LVM is for another post.  During the reading I did learn a little tip about how to force your logical volumes to use contiguous partitions/disks/extents.

In situations where disk performance is critical, forcing your logical volumes to use contiguous extents (or not span multiple physical drives, in the case) can be beneficial.  To force your logical volume to use contiguous extents at creation you need to use the -C option.  Example:

lvcreate -C y -L 10G VolGroup -n swap


I’ll break down this command for those that aren’t familiar.

lvcreate is the command used to create a logical volume from a volume group. In this case the group is called “VolGroup” and we’re giving the new volume the name (-n) “swap”. We’ve given it 10G worth of space, and the -C y tells it to use contiguous extents, yes.

Remember, this command and this option are for initial creation of logical volumes.  I’m not familiar with any method of tuning existing logical volumes to the same end.  If anyone is familiar with such an option I’d be very interested.

Perhaps I’ll do a post regarding how to manually create some basic logical volumes for use with an Arch installation.  Until then, I’m back to my reading.

I ran into this little tip today on Command-Line-Fu.  It automagically finds and deletes all non-english language sets installed on your machine.  This is, of course, a Mac OS X tip so you wont get very far running it on your Linux machine.  I have two OS X desktops at home so I found it applicable.  I know there are quite a few of you closet OS X users out there as well.  We’ll just let this one be our little secret.

sudo find / -iname "*.lproj" -and ! -iname "en*" -print0 | tee /dev/stderr | xargs -0 rm -rfv


Can anyone suggest making this command any more efficient?  Just looking at it (without testing) I may have tried something like this:

sudo find / -iname "*.lproj" -and ! -iname "en*" -exec rm -rf {} \;

I have a domain that I use to hold my notes, personal wiki, html versions of books and magazines, and other assorted resources.  Much of this I want to remain private so I’ve implemented Lighttpd access restrictions at the root of those directories.  I had a little bit of trouble this evening adding additional directories to my restriction list, so I thought I would make a note of it here.  Hopefully it’ll help anyone else running into similar trouble.


$HTTP["host"] =~ "domain.tld" {
auth.require = (
"/secret/" => (
"method"    => "basic",
"realm"     => "Password Protected Area",
"require"   => "valid-user",
),
"/private/" => (
"method"    => "basic",
"realm"     => "Password Protected Area",
"require"   => "valid-user",
)
)
}

The cause of my problem was the missing comma between the directory names. If you’re going to limit access to multiple directories in a list like this it needs to be a comma separated list.

One of my first assignments when I signed on with my new job was to rebuild and improve the internal repository server.  When I started it was quite a mess!  It only mirrored the last two revisions of Red Hat Enterprise, and didn’t have a whole lot of functionality.  Now that I’m done it supports Red Hat 3-5, both i386 and x86_64 as well as the respective CentOS releases.  It mirrors Ubuntu, Fedora, openSUSE and I added a few little tricks to the PXE server which allows us to build or destroy machines without needing to burn a CD.  One of the features that I really like is the addition of DBAN to the PXE setup, allowing us to securely wipe drives on multiple machines without the need for any CDs or other boot media.  Here is how I went about it:

Create Required Directories

mkdir /tftpboot/dban/

Download Latest Dban

wget -c http://prdownloads.sourceforge.net/dban/dban-1.0.7_i386.iso

Extract Dban Kernel and Initrd

mount -o loop dban-1.0.7_i386.iso /mnt/
cp /mnt/dban_1_0_7_i386.ima ~
mount -o loop ~/dban_1_0_7_i386.ima /mnt/
cp /mnt/{initrd.gz,kernel.bzi} /tftpboot/dban/
umount /mnt/ && umount /mnt/

These instructions don’t outline how to actually setup the PXE functionality, but simply go over how to extract the required kernel and ramdisk image which will allow for network booting. It would be nice if the DBAN site would offer something like this directly, but until then its not much more work.  I’ll do another post soon on how to setup the actual PXE server and configure it to use this newly extracted kernel and ramdisk.

I spent Saturday at the office finalizing some of the network functionality in our two offices.  One of the main things we needed to implement was a DHCP server at the sattelite office, because our DHCP needs go beyond what the Cisco router we use can offer.  Primarily the limitation is in regards to requiring multiple domains in our search path for the DHCP clients.  In any case, we decided to simply install a Linux server (Debian 5.0 in this case) and run DHCP from there.

Installing and configuring DHCP is nothing new for me, and it was configured fairly quickly for the three subnets we use in that office.  The difficult part, and the part I had to spend some time on Google looking up, was in regards to our Cisco Phones.  Because we would be disabling the Cisco router DHCP functionality it all had to be replaced on the Linux server.  I had never needed to deal with DHCP in regards to Cisco phones before, but it is actually a fairly simple fix.  Here is an example:

authoritative;
ddns-update-style none;
option voip-tftp-server code 150 = ip-address;
option voip-tftp-server 192.168.134.192;

By adding the two “option” lines in my global configuration I was able to support the Cisco phones requirement for DHCP.  Note: I did try to put this within the subnet declaration for the phones specifically, but this is an option that cannot be nested.  In other words, it has to go in the global conf or it’ll complain and not start.

This should likely work for you as well, just make sure you replace the IP for “voip-tftp-server” with the address to your core phone server.  Hopefully the next time someone hits google looking for “option code 150 cisco phone” the clear answer isn’t so hard to find.

Not so long ago I wrote about how you can configure FreeBSD to email you regarding available updates on a weekly basis.  This is something that I have had in place for a while now, and I really enjoy the ability to keep things on the patched (read: bleeding) edge.  Recently I found a small issue with the setup I had been using.  I wanted to share the fix with anyone that may have been doing the same thing.

First of all, let me tell you about the issue I came across.

When I would recieve an email regarding available updates I would connect to the FreeBSD Jail and use portmaster -a -d to apply all available updates.  I noticed that the number of updates applied did not match the number of updates listed in the email.  Odd.  Well, after thinking about it for a bit I realized what the problem was.

The cron job (as seen in the previous post) was running at the same time on the FreeBSD host as well as the FreeBSD Jail.  Why is that a problem, you ask?  Remember the slight variation in the host cronjob verses the jail.  The host system is pulling down the updated ports tree before it compares and emails any available updates.  The problem is introduced because the jails start doing their comparison and email reporting right away, while the host system is fetching and applying the updated tree.  Oops!  The ports tree update isn’t finished fast enough for the jails to actually have the new information.

The solution I came up with is a very simple one.  Simply update the cron daily run time on the host to give it an adequate headstart from the jails.  On my systems the /etc/crontab files now look like this:

HOST:
# Perform daily/weekly/monthly maintenance.
1   2   *   *   *   root    periodic daily
15  4   *   *   6   root    periodic weekly
30  5   1   *   *   root    periodic monthly


JAIL:
# Perform daily/weekly/monthly maintenance.
1   3   *   *   *   root    periodic daily
15  4   *   *   6   root    periodic weekly
30  5   1   *   *   root    periodic monthly

If you didn’t notice the change look closer. It’s a very small fix. The “periodic daily” row on the host is now set to run at 2:00am while the same field is set to 3:00am on the jail. I’m sure that is more than enough time for the host to update the ports tree before the jails start to do their reporting.

In conclusion, if you’re using a similar reporting system you’ll likely want to apply this small change as well.  Giving the host system enough time to update the ports tree will be critical in getting updated, accurate information within the jail systems.

Just the other day we were auditing some of the packages on our production application servers and found a few that we were surprised about.  None of us remember installing them, so we set out to try and find out who might have done it, and when it might have happened.  The other two admins started grepping through the history files and looking at old, archived log data.  I used the information within the RPM database and simply asked the machine when it was installed:


[root@repo ~]# rpm -qi htop
Name        : htop                         Relocations: (not relocatable)
Version     : 0.7                               Vendor: Dag Apt Repository, http://dag.wieers.com/apt/
Release     : 1.el5.rf                      Build Date: Sat 24 Nov 2007 07:24:19 AM MST
Install Date: Tue 04 Nov 2008 04:02:40 PM MST      Build Host: lisse.leuven.wieers.com
Group       : Applications/System           Source RPM: htop-0.7-1.el5.rf.src.rpm
Size        : 148330                           License: GPL
Signature   : DSA/SHA1, Sat 24 Nov 2007 07:29:40 AM MST, Key ID a20e52146b8d79e6
Packager    : Dag Wieers <dag@wieers.com>
URL         : http://htop.sourceforge.net/
Summary     : Interactive process viewer
Description :
htop is an interactive process viewer for Linux.

As you can see in the example above, the RPM database provides information on “Install Date”, including the time. With this information I was able to report to the other admins that the htop package was installed on Tue 04 Nov 2008 at 4:02:40 PM MST. That is more specific than anything they’d find looking through old log data!