Tim - the other archlinux user

My Way of Keeping Arch Linux Updated

2009-06-15T20:33:42Z

One of the things that Arch Linux does _not_ try to do is administer your system for you. One area where this bothers me is in a system upgrade procedure which goes roughly like this:

$ pacman -Syu
The above command will refresh the local cache of packages made available by any configured archlinux repositories, then proceed to upgrade any installed packages to the newest available version.
The (pac)kage (man)agement tool "pacman" does not provide the capability of merging new and exisiting configuration files. This is an intentional decision meant to assure that system settings won't be clobbered. As a result, you must manually scan through your filesystem after an update, looking for files with the *.pacsave or *.pacnew extensions, merge in any changes you would like, then (optionally) delete the *.pac{save,new} files. A tool called pacdiffviewer is provided by the yaourt package which can automate the previous procedure.

Another thing that pacman is not capable of is updating packages installed via the (A)rch (U)ser (R)epository, AUR (http://aur.archlinux.org/). One tool which is capable of (un)installing/updating/querying/etc. packages located in AUR is yaourt.

$ yaourt -Syu --aur --devel
The above command will update all packages on the entire system whether installed from pacman repositories or from the AUR.

A tool that I recently started using to manage my /etc/ directory is called etckeeper. Etckeeper can be configured to use one of several revision control systems (git, bzr, cvs, etc.) and creates and manages all of the revisions that /etc/* files go through. I've really enjoyed not having to manually make backups of config files when I experiment with new settings and it's good to know that I can easily roll-back or merge changes of files in the future if I decide that I liked things better the way they were before.

To put all of the previous things together and save my fingers some typing each day, I created the following alias in ~/.bashrc :
alias update='yaourt -Syu --aur --devel && sudo pacdiffviewer && cd /etc/ && sudo etckeeper commit; cd -'

My system upgrading is now done by simply typing "sysupgrade" as a normal user and interactively managing the rest of the process.

"Get to the Chopper!"

2009-03-06T18:54:34Z

One of the traditions amongst students who attend Guru Labs classes is come up with a putty creations using the "enlightenment putty" they receive during class.
Sometime around the beginning of my career here, I taught a Linux Fundamentals class which had a particularly fun group of guys in it. I wish I had more pictures of their creations, but I did have one student forward me this picture he took with his phone. It depicts Arnold Schwarzenegger in a scene from the "The Predator" yelling "Get to the Chopper!"

Swap file versus swap partition

2008-12-17T20:29:37Z

Which is faster, a swap file or a swap partition?

This is a question that comes up on a fairly regular basis on IRC chatrooms, mailing lists, etc. which has widely varying answers depending on the source.

While updating our courseware a few days back, I decided to start digging into the issue and found a couple of very interesting reads.

The most common claim is that a swap partition is faster than a swap
file because in older versions of the Linux kernel experienced some filesystem overhead when accessing the swap file.

Ever since the release of 2.5.23 of the Linux kernel, however, this is no longer the case.
http://www.kernel.org/pub/linux/kernel/v2.5/ChangeLog-2.5.23
(search for the line: "[PATCH] direct-to-BIO I/O for swapcache pages")

In case the highly-technical explanation of how swap files are now handled is less-than-enlightening, perhaps a description from number two Linux kernel developer himself (Andrew Morton) can help clear the muddy waters:
http://lkml.org/lkml/2005/7/7/326

I still haven't had time to come up with and perform any decent performance comparison, so for now I'll take Andrew Morton's word for it...

Thinkfinger stops working with hal 0.5.11

2008-12-16T04:59:00Z

In case anyone is wondering why their fingerprint reader isn't working under Linux after a recent upgrade, I may have an answer for a portion of you.
_If_ you happen to use the thinkfinger PAM module to authenticate and you've upgraded hal to version 0.5.11, a carriage return is now necessary *after* scanning your finger. The reason, as described in the bug report is that: 'When creating a uinput device with only one key, hal incorrectly assigns it as a "button" rather than a "keyboard".'
They're still working on a solution, but a temporary workaround (and perhaps the final solution) is to apply this patch and rebuild/reinstall hal:

diff -ur hal-0.5.11.old/hald/linux/device.c hal-0.5.11.new/hald/linux/device.c
--- hal-0.5.11.old/hald/linux/device.c	2008-05-07 19:23:42.000000000 -0400
+++ hal-0.5.11.new/hald/linux/device.c	2008-11-05 18:26:33.000000000 -0500
@@ -175,7 +175,7 @@
 {
 	char *s;
 	long bitmask[NBITS(KEY_MAX)];
-	int num_bits;
+	int num_bits, bus_type;
 
 	s = hal_util_get_string_from_file (sysfs_path, "capabilities/key");
 	if (s == NULL)
@@ -183,11 +183,11 @@
 
 	num_bits = input_str_to_bitmask (s, bitmask, sizeof (bitmask));
 
-	if (num_bits == 1) {
-		/* this is for input devices originating from the ACPI layer et. al. */
-
-		/* TODO: potentially test for BUS_HOST */
+	if (!hal_util_get_int_from_file (sysfs_path, "id/bustype", &bus_type, 16))
+		goto out;
 
+	if (num_bits == 1 && bus_type == BUS_HOST) {
+		/* this is for input devices originating from the ACPI layer et. al. */
 		hal_device_add_capability (d, "button");
 		hal_device_property_set_bool (d, "button.has_state", FALSE);
 		if (test_bit (KEY_POWER, bitmask)) {

Hello and chroot

2008-11-06T21:48:00Z

Up till now, I've only used blogging as a way to keep in touch with friends and family members. One thing that I have noticed while doing so is that contrary to what I've felt in the past, not all of my acquaintances are interested in Linux or even in technology. Any tech-based blog entries I've created in my family's blog have gone largely ignored and I've even been asked (nicely) _not_ to pollute the blog with my Linux fanaticism. :) Consequently, I've decided to jump on the Guru Labs bandwagon and move all technospeak to this blog.

Without further stalling, let the blogging commence...

CHROOT

During my adventures with Linux, I've often seen some pretty powerful uses
for the "chroot" command. Being new to Linux/Unix, I had no idea what it
accomplished, but like many users, ran it blindly trusting that it would help
me accomplish whatever a particular tutorial was outlining.
Since coming to work at Guru Labs, I've had several chances to explore
chroot a bit more and have made some (hopefully) useful observations:

1. chroot can be used as a security mechanism
2. chroot can be used to troubleshoot a broken Linux installation
3. chroot can be used to make major modifications to a Linux installation that
couldn't otherwise be made
4. chroot can be used for testing in an isolated environment
5. chroot can be used to run 32-bit apps inside of a 64-bit Linux environment
6. chroot can be used in many other ways that I haven't currently seen

Before exploring any of the aforementioned areas where chroot is useful, a short
explanation of chroot is necessary.

As chroot(2) (the Linux man page viewed by running "man 2 chroot") points out,
"chroot() changes the root directory of the calling process to that specified in
path. This directory will be used for pathnames beginning with /. The root direc‐
tory is inherited by all children of the calling process."

Now, the following example could prove useful if the above description wasn't obvious.
Personally, what chroot accomplished or why I should care wasn't apparent to me until I had
experimented with chroot a few times.

Let's assume that I've got a filesystem that looks like this:
tgelter ~ $ tree -L 1 /
/
|-- bin
|-- boot
|-- dev
|-- etc
|-- home
|-- lib
|-- lib64
|-- media
|-- mnt
|-- oldroot <--specifically notice this one
|-- opt
|-- proc
|-- root
|-- sbin
|-- srv
|-- sys
|-- tmp
|-- usr
`-- var

Now, excluding a lengthy conversation about Linux having a singly-rooted inverted-tree
filesystem structure, let it suffice to say that several individual filesystems are
currently "mounted" and grafted together as we can see from running the "mount" command:
tgelter ~ $ mount
/dev/sda2 on / type jfs (rw)
none on /dev type ramfs (rw)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw)
none on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext3 (rw)
/dev/mapper/storage on /storage type xfs (rw,noatime)
/dev/mapper/oldroot on /oldroot type ext3 (rw,noatime)

Specifically, I have a filesystem on device "/dev/mapper/oldroot" mounted to the directory
called "/oldroot". This filesystem happens to be an older installation of Linux which I'm
no longer using but keeping around in case I happen to need to copy over an old config file
or, in the worst case scenario, I can boot to it if my current installation were badly broken.

Looking at the directory listing of "/oldroot", we see that it has many of the same
directories of my currently running system:
tgelter ~ $ ls /oldroot/
backup boot etc lib lost+found mnt proc sbin storage tmp var
bin dev home lib64 media opt root srv sys usr

Now let us consider the scenario where I'm attempting to fix "/oldroot". After some research,
I've determined that I just need to issue a system upgrade in order to fix networking. If I
were to boot into "/oldroot" to fix the issue, networking would be broken and there would be
no way to perform the system upgrade in order to fix networking. (Yeah, I _could_ download the
needed packages and install them offline, but let's pretend that's not possible :) )

In order to perform the upgrade, the following steps could be taken:

1. Bind mount virtual filesystems that will be needed by the new chroot environment (a "bind mount" takes a directory that is already mounted and mounts it somewhere else at the same time):
root ~ # mount --bind /proc /oldroot/proc
root ~ # mount --bind /dev /oldroot/dev
root ~ # mount --bind /sys /oldroot/sys
(more may be needed depending on your configuration)
*note - these need to be mounted prior to entering the chroot so that your
new working environment will be able to obtain information about hardware,
running processes, etc.

2. Chroot into the new environment:
root ~ # chroot /oldroot/
When I issue this command, the shell (in this case, bash) as well as any
processes created by it, see the "/dev/mapper/oldroot" filesystem which we saw
mounted to "/oldroot" as the new "/"

root / # tree -L 1 /
/
|-- backup
|-- bin
|-- boot
|-- dev
|-- etc
|-- home
|-- lib
|-- lib64
|-- lost+found
|-- media
|-- mnt
|-- opt
|-- proc
|-- root
|-- sbin
|-- srv
|-- storage
|-- sys
|-- tmp
|-- usr
`-- var

You may notice that "/oldroot" no longer appears as it is now referred to as "/".
Before chrooting, each of these directories was located under "/oldroot/". To help
visualize,
/oldroot/etc --> /etc
/oldroot/home --> /home
/oldroot/backup --> /backup
etc.

3. Fix networking as necessary:
(in my case, I just need to overwrite my /etc/resolv.conf to properly
resolv hostnames. _DON'T RUN THIS UNLESS YOU KNOW WHAT YOU'RE DOING_)
root / # cp /etc/resolv.conf /etc/resolv.conf.bak && echo "nameserver 4.2.2.2" > /etc/resolv.conf

4. Perform the upgrade (I'm using ArchLinux):
root / # pacman -Syu
:: Synchronizing package databases...
testing is up to date
core is up to date
extra is up to date
community is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...

Targets (9): e2fsprogs-1.41.3-2 expat-2.0.1-2 git-1.6.0.3-1 gvfs-1.0.2-1 kismet-2008_05_R1-1
libdrm-2.4.0-1 openoffice-base-3.0.0-2 kernel26-2.6.27.1-1

Total Download Size: 154.91 MB
Total Installed Size: 367.04 MB

Proceed with installation? [Y/n] y

I happen to use Arch Linux on my laptop, so the system upgrade procedure on your own
machine will almost certainly differ from what I did above (perhaps "yum upgrade" for
Fedora/RHEL, "aptitude dist-upgrade" for debian/ubuntu, etc.).

5. Exit the chroot:
root / # exit

6. Unmount the virtual filesystems:
root ~ # umount /oldroot/{dev,proc,sys}

Assuming that I had a bad kernel which has now been updated, I could now reboot into the
old installation using the new kernel to test if my fix worked.

Now, I mentioned several reasons to use chroot: 1. A security mechanism, 2. To troubleshoot
a broken Linux installation, 3. To make major modifications to a Linux installation that
couldn't otherwise be made, 4. For testing an isolated environment, 5. Used to run 32-bit apps
inside of a 64-bit Linux environment, 6. Used in many other ways that I haven't currently seen

The example I went over is a fairly common example of reason #2 mentioned above. Most Linux
rescue media uses a similar procedure for rescuing a broken system. I won't go into detailing
any of the other reasons, but see the included URL for reading related to each reason as
numbered above:

1. http://fedoraproject.org/wiki/Docs/Drafts/AdministrationGuide/Servers/DNSBIND/BINDChroot
3. http://www.howtoforge.com/install-ubuntu-with-software-raid-10
4. https://help.ubuntu.com/6.10/ubuntu/installation-guide/amd64/linux-upgrade.html
5. http://wiki.archlinux.org/index.php/Arch64_Install_bundled_32bit_system

One last note about item #1, placing a process inside of a chroot "jail" as a security
mechanism is often criticized as we see here: http://kerneltrap.org/Linux/Abusing_chroot
from man chroot(2):
"In particular, the superuser can escape from a "chroot jail" by doing:
mkdir foo; chroot foo; cd .."

The thing to keep in mind is that chroot is _not_ as powerful as freebsd's jail(). This doesn't
mean that there is no value in placing a process, especially a network service, into a chroot.
Like all security, multiple layers means more protection.
If you've read this far and still have interest in researching security through chroot, I'd
recommend you look into a couple of better solutions which are available:
-linux vserver (attempt at improving the chroot jail idea)
-virtual machines (kvm/xen/etc.)

Tim - the *other* archlinux user

My Way of Keeping Arch Linux Updated

"Get to the Chopper!"

Swap file versus swap partition

Thinkfinger stops working with hal 0.5.11

Hello and chroot

Tim - the other archlinux user