phaqphaq

Well, well, I just feel like 14 years ago, playing around with my rather aged SGI O2, which I didnt touch for years, doing a fresh reinstall of IRIX and some apps.

While flipping through my CDs I stumbled accross SoftWindows95 for IRIX. I just couldn’t resist and put the flipper in, having the software installed just minutes later, only to see that I didn’t have the license any more

After some searching I found a Usenet article with a valid license of SoftWindows95. Well, I think it’s fair enough to republish this, as for one, Insignia has sold-off SoftWindows about 10 years ago, and the successor company FWB Software stopped development in 2001, furthermore that company doesn’t exist anymore as it has been sold-off, too. Well, not even SGI is able to provide a license key for a software, which is 14 years old … hm…. Well, I _think_ it’s ok, otherwise let me know …

To activate SoftWindows95 just place this text into /usr/lib/SoftWindows95/FLEXlm/license.dat:

FEATURE Insignia_SoftWindows95 insignia 4.000 01-jan-0 0 \
ECE41259D5BE4700DC27 VENDOR_STRING=”5100 0100 0000 0001″ \
HOSTID=ANY vendor_info=SOFTWINDOWS95 ISSUER=”Silicon Graphics, \
Inc.”

The license won’t show up from the GUI _but_ SoftWindows95 will work.

Considering the age of the O2 and it’s dated 200 MHz MIPS CPU the emulation speed isnt’t too bad.
I remembered it being worse than thaz, but maybe that’s just the “geekness” of having gotten something very old to work again

Yesterday I started digging around for a solution to create per-user or per-database statistics on MySQL, one of the more important peaces I was missing from it for a long time.

Luckily enough, some guys over there had already done some work on this topic, so I wouldn’t have to start over from scratch

It took me only little time to port over the patch from MySQL 5.0.51 to the more current 5.0.83 release within the FreeBSD ports tree, however not soon after starting a build I would encounter this error message:

[root@bld-bsd-224-221 /usr/ports/databases/mysql50-server]# make build
[ - some output omitted - ]
/bin/sh ../ylwrap sql_yacc.yy y.tab.c sql_yacc.cc y.tab.h sql_yacc.h y.output sql_yacc.output --  -d -d --debug --verbose
-d: not found
*** Error code 1

At first I thought the port was corrupted so I refetched the package and reapplied the patch, to no avail.
So I tried again using the original port without having the patch applied, which worked flawlessly.

At second glance I checked for the file list from above command and noticed that it included the file named sql_yacc.yy, one of which had been altered by the previously applied patch.
My conclusion was that the file had been wrongly patched, containing a syntax error or such alike.
I then extracted the unpatched package once more to do a clean rebuild without patches.
I checked the compilation output for the above command line, only to note that it wasn’t actually there!

The question was: Why would the command line “/bin/sh ../ylwrap sql_yacc.yy ….” not get invoked when doing a build on a clean, unpatched package?
I double-checked my patches to see if the command was introduced by itself, which was not the case. That single command actually belongs to the stock MySQL Makefile.

At that stage I decided to just add a single whitespace to the file sql_yacc.yy and run the command manually:

[root@bld-bsd-224-221 /usr/ports/databases/mysql50-server/work/mysql-5.0.83/sql]# make
/bin/sh ../ylwrap sql_yacc.yy y.tab.c sql_yacc.cc y.tab.h sql_yacc.h y.output sql_yacc.output --  -d -d --debug --verbose
-d: not found
*** Error code 1

Interestingly enough that command actually only seems to get involved when the contents of the sql_yacc.yy file is altered.
As such the error was indeed not caused by the patch itself.

So I digged deeper in analyzing the “ylwrap” script file, which is included with the MySQL package. Oh well, at that time I really felt like an idiot!
When I realized that this seemed to by a wrapper script for YACC I also noticed the double-hyphen, which is really an indicator for subsequent command line arguments to be passed on to a sub-process.
Having said that I supposed there was actually missing something in between here: “– {HERE} -d -d”
Could it be that it’s missing the command name of the YACC sub-processor?

Well, do I have YACC installed?

bld-bsd-224-221.genotec.ch:/usr/ports/databases/mysql50-server# which yacc
/usr/bin/yacc

Well, I do … the only catch is: MySQL depends on bison, not on YACC.
To make things worse, neither the FreeBSD port Makefile nor the MySQL configure script check on that dependency, most likely as it is *usually* not required.

Good catch, after having installed bison from the ports tree MySQL compiled like a charm even with all my patches applied

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.

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.

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.