phaq

Installing VMware Server 2.0 on Debian

February 29th, 2008

Enabling ReiserFS, XFS, JFS on RedHat Enterprise Linux

February 4th, 2008

Despite the Linux kernel having support for so many file systems, not all of them are enabled in RedHat Enterprise Linux by default. This might be well as some of them might not yet classify as “enterprise grade” in the eyes of RedHat, who knows… Luckily, support for missing file systems such as ReiserFS, XFS and JFS can be added easily as outlined below. For this howto I assume you are running the stock RedHat kernel.

Get an RPM repository

First of all, you need access to an RPM repository. Usually this is your setup cd-rom or a network-accessible (FTP, HTTP or even NFS) directory. I assume you have this setup already, so let’s proceed to the next step.

Install requireds packages

You’ll need the toolchain, rpm-build, the glibc and kernel headers as well as the kernel source RPM from redhat. Issue this to see what kernel header version is required for you:

# uname -a
Linux localhost 2.6.18-53.el5 #1 SMP Wed Oct 10 16:34:19 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux

Install them as required using yum:

#yum install rpm-build.x86_64 ncurses-devel.x86_64 gcc.x86_64 redhat-rpm-config unifdef
[ ... output omitted ... ]
=============================================================================
 Package                 Arch       Version          Repository        Size
=============================================================================
Installing:
 gcc                     x86_64     4.1.2-14.el5     base              5.3 M
 ncurses-devel           x86_64     5.5-24.20060715  base              1.7 M
 redhat-rpm-config       noarch     8.0.45-22.el5    base               53 k
 unifdef                 x86_64     1.171-5.fc6      base               15 k
Installing for dependencies:
 cpp                     x86_64     4.1.2-14.el5     base              2.9 M
 glibc-devel             x86_64     2.5-18           base              2.4 M
 glibc-headers           x86_64     2.5-18           base              598 k
 kernel-headers          x86_64     2.6.18-53.el5    base              814 k
 libgomp                 x86_64     4.1.2-14.el5     base               77 k

Transaction Summary
=============================================================================
Install      9 Package(s)
Update       0 Package(s)
Remove       0 Package(s)         

Total download size: 14 M
Is this ok [y/N]:

This will install everything you need to get going in the first place. Now go and get the kernel source RPM, which you’ll find at the RedHat FTP Site. Save it to a temporary directory and install it accordingly:

# mkdir /usr/src/sources && cd /usr/src/sources
# wget ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/kernel-2.6.18-53.1.6.el5.src.rpm
# rpm -ivh kernel-2.6.18-53.1.6.el5.src.rpm

This will throw some messages at you about a user/group named “brewbuilder” not being there. That means no harm, however you may prefer to create it first. Now everything needed should exist inside your /usr/src/redhat directory. Then run rpmbuild from the redhat tree.

# cd /usr/src/redhat
# rpmbuild -bp SPECS/kernel-2.6.spec
[ ... output omitted ... ]

Enable the file systems

Now you need to initialize the kernel build environment like this from the kernel source tree. You will also need to copy the original kernel config from your current RedHat kernel.

# cd /usr/src/redhat/BUILD/kernel-2.6.18/linux-2.6.18.x86_64
# cp /boot/config-`uname -r` .config
# make menuconfig

From “menuconfig” navigate to “File systems”, where you enable the missing modules. In my case I select “Reiserfs support”, “JFS” and “XFS” to be included as module (”M” marking). This is especially required if you just want to build the module and copy it over to your locally installed kernel modules directory. I’d recommend to create an RPM for proper upgrade management anyway, however in this case it actually doesn’t matter (except in terms of overhead and performance of course) it you’re using a module or compile it into the kernel. Afterwards I exit from “menuconfig”, not without saving the changes of course.

Compiling and installing the modules the lazy way

Now this is what I call the lazy way… For easy upgrades and package management, I’d strongly recommend you create a fullblown RPM (see next section). However, if you just want to get going, you can compile the modules manually like this:

# cd /usr/src/redhat/BUILD/kernel-2.6.18/linux-2.6.18.x86_64
# mkdir .tmp_versions
# make fs/xfs/xfs.ko
# make fs/jfs/jfs.ko
# make fs/reiserfs/reiserfs.ko

Then add the modules made to your current module directory like this:

# mkdir /lib/modules/`uname -r`/kernel/fs/reiserfs
# mkdir /lib/modules/`uname -r`/kernel/fs/xfs
# mkdir /lib/modules/`uname -r`/kernel/fs/jfs
# cp ./fs/reiserfs/reiserfs.ko /lib/modules/`uname -r`/kernel/fs/reiserfs
# cp ./fs/xfs/xfs.ko /lib/modules/`uname -r`/kernel/fs/xfs
# cp ./fs/jfs/jfs.ko /lib/modules/`uname -r`/kernel/fs/jfs
# depmod -a

This will leave you with modules suiting your kernel. However, whenever you’re upgrading the kernel package, they may get overwritten, so it’s best to create a kernel rpm and install it as a regurlar package.

Building a full-featured RPM

Before you create your RPM package, it’s recommended you edit the Makefile and replace the EXTRAVERSION header by something meaningful which makes the difference clear.

# cd /usr/src/redhat/BUILD/kernel-2.6.18/linux-2.6.18.x86_64
# vi Makefile

In this case, I’ve set EXTRAVERSION = -jfsxfsreiserfs_2.6.18_53_1.6. Then simply run this command to create the RPM package:

# cd /usr/src/redhat/BUILD/kernel-2.6.18/linux-2.6.18.x86_64
# make rpm

Like this you’ll end up with both a new RPM package and a source RPM inside your /usr/src/redhat/RPMS and /usr/src/redhat/SRPMS directories, which can then be installed via rpm or, if integrated with a local yum repository, from yum itself.

Getting the tools

Of course, the modules themselves serve no practical purpose if you lack the userspace tools to create and maintain the file systems. Get them accordingly from ftp://oss.sgi.com/projects/xfs/ (XFS), http://jfs.sourceforge.net/ (JFS) and http://chichkin_i.zelnet.ru/namesys/ (ReiserFS). Again, it’s recommended to create an RPM from the sources, but this is beyond the scope of this article.

Posted in RHEL | 7 Comments »

Killing a Windows Terminal Session from remote

January 25th, 2008

Darn it!
Imagine what happens when a Windows box, which is configured for remote administrative terminal mode only, is left with two zombie terminal sessions.

Maybe you are lucky, and Terminal Services Manager does the job for you. In theory, one might connect another host for management purposes.
In case your administrative credentials are different from the ones on the destination host, Terminal Services Manager might throw an insufficient permissions error at you.

So it was in my case, which I worked around like this:

First I opened up a command shell (Start - Run - cmd + OK), from which I ran this command:

C:\Documents and Settings\Administrator>net use o: \\192.168.13.205\c$ /user:Administrator

The password or user name is invalid for \\192.168.13.205c$.

Enter the password for 'Administrator' to connect to '192.168.13.205':

The command completed successfully.

This asked me for the credential of the remote system’s Administrator
and connected it’s shared C: drive to my system.
In fact, connecting the share isn’t required, everything else works too, as long as you’re prompted to enter the credentials for the remote systems.
In my experience, connecting a share proved to work out properly in most cases.

So afterwards, I ran this command to list the remote server’s terminal sessions:

C:\Documents and Settings\Administrator>qwinsta /server:192.168.13.205
 SESSIONNAME       USERNAME                 ID  STATE   TYPE        DEVICE
 console                                     0  Conn    wdcon
 rdp-tcp                                 65536  Listen  rdpwd
 rdp-tcp#10        Administrator             2  Active  rdpwd
 rdp-tcp#16        Administrator             3  Active  rdpwd

So, to kill any or all of these sessions, run this command:

C:\Documents and Settings\Administrator>rwinsta rdp-tcp#10 /server:192.168.13.205

It’s also possible to kill a session by it’s ID, which works like this:

C:\Documents and Settings\Administrator>rwinsta 3 /server:192.168.13.205

Let’s check out if our zombie sessions are gone now:

C:\Documents and Settings\Administrator>qwinsta /server:192.168.13.205
 SESSIONNAME       USERNAME                 ID  STATE   TYPE        DEVICE
 console                                     0  Conn    wdcon
 rdp-tcp                                 65536  Listen  rdpwd

So it looks good after all, the sessions are gone and I can reconnect the server using rdpclient as usual.

So let’s disconnect the share now, as in fact it wasn’t used for anything except to store the credential.

C:\Documents and Settings\Administrator>net use o: /delete
o: was deleted successfully.

By the way, if you don’t want to encounter these hassles over and over again, terminal server can be configured to automatically terminatate stale/inactive sessions.
Find more about this in the Microsoft Knowledge Base.

Posted in Windows | No Comments »

An AutoFS executable map to automount device nodes

January 24th, 2008

For my company’s hard disk-based backup system I needed the ability to automount disk drives by their device name into a standard directory structure.

One possible approach would be to add some lines like these to fstab:

/dev/sda1       /mnt/sda1       ext3    defaults,noauto 0       0

This may be good enough in some cases, though it wasn’t sufficient for me, when there were dozens of device nodes which could get mounted eventually.

So I basically wanted something that would allow me to just access a directory, while the underlying disk was mounted automatically, then having it unmounted automatically if not in use, but still being dynamic in it’s nature so it would auto-adjust.

Now there’s a simple trick using an AutoFS feature called “executable maps”, which would allow me to achive this all.

The idea is, that all devices (let’s say /dev/sda1, /dev/sda2, /dev/sdb1, /dev/sdc1 as an example) will get mounted to /mnt/disks/[devicename].

First make sure, that AutoFS is installed. On Debian for example, it is installed like this:

apt-get install autofs

Then create a file called /etc/auto.disks with the following lines therein:

#!/bin/bash

# $1 is passed-over from automount
# key refers to the mount point we are looking for
key="$1"

# default mount options
opts="-fstype=ext3,rw"

# if a block device exists at /dev/[key]
# pass it back to automount
[ -b /dev/${key} ] && { echo "$opts \"; echo -e "t:/dev/${key}"; }

Don’t forget to chmod 755 /etc/auto.disks.

This script will create an automounter map dynamically as soon as it passed
a device node. It it finds it (e.g. while looking up /dev/sda1, which exists), it’ll
return the map to automount, which will cause the device node to be mounted.

In my case, the script didn’t need to be very sophisticated as I only have ext3-formatted disks, but it’s easy to script it for automatic file system recognition.

Btw, the script can be tested like this to see if it’s actually working:

satyr:~# bash /etc/auto.disks sda1
-fstype=ext3,rw
        :/dev/sda1
satyr:~# bash /etc/auto.disks sdx1

The first command returns the map for an existing device node /dev/sda1, while the second command returns nothing as /dev/sdx1 doesn’t exist on the system.

Now set AutoFS to use the executable map for /mnt/disks directory. Add this line to /etc/auto.master:

/mnt/disks  /etc/auto.disks --timeout=360

This will cause AutoFS to examine the executable map on all requested sub directories beneath /mnt/disks. So if you’re going to access /mnt/disks/sda1, /mnt/disks/sda2, /mnt/disks/sdb1, /mnt/disks/sdc1, the block devices corresponding to the directories are mounted automatically — as long as the devices exist of course.

The timeout value designates after how much time (of inactivity) an automounted file system expires and get’s unmounted.

Posted in Operating Systems, Utilities | No Comments »

Apple’s Safari violates RFC2616

January 23rd, 2008

Today I faced an issue, where HTTP redirections didn’t work out as expected on Apple’s Safari browser.

This came up while I was coding up some sort of web-based login redirector, which is stacked up in three layers:

html login form
login preprocessor (server side scripting)
login processor (server side scripting)

This solution was required to implement a generic way to create branded login forms, which will send their login requests to a unique, centralized login preprocessor, which will - after doing some internal magic - redirect to the final login processor.

Now, the login preprocessor was set to do redirects to the final login processor using HTTP/1.1 temporary redirects (http reply code 307) to preserve already existing POST data.
While this was working out properly on most browser, I stumbled accross Safari, which will silently discard all POST data.

Checking out the access logs revealed some interesting facts.
The first excerpt shows the access as performed by Firefox:

192.168.0.2 - - [23/Jan/2008:16:32:02 +0100] "POST / HTTP/1.1" 307 20 "https://xyz/" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"
192.168.0.2 - - [23/Jan/2008:16:32:05 +0100] "POST /some_other_location HTTP/1.1" 200 7934 "https://xyz/" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"

As required by the 307 temporary redirect Firefox will resubmit to the new location using a POST request (preserving existing POST data).
The first request actually refers to stage 2 (login preprocessor), the second request reflects the resubmission to the final login processor (step 3).

Now this is was Safarie does:

192.168.0.3 - - [23/Jan/2008:16:31:26 +0100] "POST / HTTP/1.1" 307 20 "https://xyz" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE) AppleWebKit/523.15 (KHTML, like Gecko) Version/3.0 Safari/523.15"
192.168.0.3 - - [23/Jan/2008:16:31:26 +0100] "GET /some_other_location HTTP/1.1" 200 7931 "https://xyz" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE) AppleWebKit/523.15 (KHTML, like Gecko) Version/3.0 Safari/523.15"

As we can see, it also receives a 307 temporary redirect from the server and follows it (which is correct as of RFC2616) in the first request (again step 2 as outlined before).
However, the second request is resubmitted using GET, which means that all previously existing POST data is lost (this is step 3 as outlined before).

In this case, Safari clearly violates RFC2616, which states in Chapter 10.3.3 302 Found:

RFC 1945 and RFC 2068 specify that the client is not allowed
to change the method on the redirected request. However, most
existing user agent implementations treat 302 as if it were a 303
response, performing a GET on the Location field-value regardless
of the original request method. The status codes 303 and 307 have
been added for servers that wish to make unambiguously clear which
kind of reaction is expected of the client.

As a side note to this excerpt from the RFC I shall note, that status code 302 Found as referred-to by RFC2616 used to be
302 Moved Temporarily (as of RFC2068), which has been redefined to 307 Temporary Redirect.

As such, while status code 303 See Other clearly states, that GET should be used upon redirect, statements made in
RFC2616’s Chapter 10.3.3 302 Found also apply to 307 Temporary Redirect.

In this case it means, that Safari violates the standard when it changes the access request method to GET.

Posted in Programming | 1 Comment »

phaqphaq

Installing VMware Server 2.0 on Debian

Enabling ReiserFS, XFS, JFS on RedHat Enterprise Linux

Get an RPM repository

Install requireds packages

Enable the file systems

Compiling and installing the modules the lazy way

Building a full-featured RPM

Getting the tools

Killing a Windows Terminal Session from remote

An AutoFS executable map to automount device nodes

Apple’s Safari violates RFC2616

Pages

Archives

Categories

Blogroll

Menu

Meta