Boot from CD - a winner again

Didn't expect to write anything whilst on holidays in Sydney. But couldn't resist sharing my joy of Knoppix saving me from a big row with the hotel staff.

Hotel I'm in is using a third party company to provide telecomms and broadband services. It's awfully expensive, but convenient, so I have subscribed.

So, to get online, you tune into channel 8 on your telly, choose the deal (9.95 for an hour, 44.95 for 3 days), then enter your room number - and bingo, a password is created for you. You connect your laptop and off you go. Except that the socket in our room was faulty. A very friendly manager allowed us to use another room (to test my laptop), using a password he provided for me. It worked (I never doubted my laptop). So, we move rooms altogether. Once moved, tried to connect and the fun started.

Tried the password I had generated before - error message saying - cannot activate: already active. Although the manager's password has expired, I could still connect to the Internet, and use exactly the same sites I did as part of the test, but no others. Tried clearing the browser's cache, reboot, clear the cache again for good measure, same behaviour over and over.

MAC address tied it in? Don't know, but booted from the Knoppix CD, connected the cable, punched in the password - straight in! On the same laptop, with the same hardware.

So, if not a browser's cache, not an interface number, what was it that tied my laptop to the servers information? Am I missing something? Or is the comms provider being naughty and captures more information that I would comfortably want to surrender? I left the question with the manager. Somehow, I don't expect to get any answers before we leave in three days time...

Moral of the story - Knoppix came up trupms again!

Allowing remote X sessions

A couple of posts before, I have described how to use gdmsetup to enable (in conjunction with xhost + command) remote X applications on your machine.

I've been working with our engineers (OK, here goes the mention - Dave Williams, who is fast becoming a Linux expert, and Martin Pain - who, similarly is becoming Oracle and SQL ex if not expert), to update our various course setup documents. The fix for gdmsetup needed to be scripted. A simple trick allowed me to identify the configuration line that needed to be changed:

First save the current setting in a different file:

# cp /etc/X11/gdm/gdm.conf /tmp/x.$$

Then change the setting; run:

# gdmsetup

Select Security tab, and modify the setting for the "Always disallow TCP connections...".

Once done, just compare the two files:

# diff /etc/X11/gdm/gdm.conf /tmp/x.$$
191c191
< disallowtcp="true
---
> DisallowTCP=false

Bobs your uncle. A single line (or two):

sed '/DisallowTCP/s/false/true/' /etc/X11/gdm/gdm.conf > /tmp/x$$
mv /tmp/x$$ /etc/X11/gdm/gdm.conf

placed in an appropriate script, and X applications will now be accepted.

RPM package verification

This post doesn't solve any problems, but is more of a record of the investigation to solve one.

I'm having problems with Fedora Core 4 GUI. Rather unpredictible X behaviour, with not being able to restart it, inability to start just some of the applications, such as xterm or firefox...

Handling X has always been my achilles heal. I resisted windows, of any description ;-), for as long as I could, initially regarding it first as pure waste, then unnecessary nicety. It's only relatively recently that I kind of resigned to the fact that resources are now robust enough to cope, and there exist applications that could not live without GUI.

Anyway, still don't really know what the problem is, but done some googling, and can see that I'm not the only one struggling with this strange GUI behaviour. Somebody suggested verifying X server packages - good idea. Run the rpm --verify on all packages to do with xorg, and got some result:

# rpm -V $(rpm -qa | grep xorg)
. . ? . . . . . c /etc/security/console.apps/xserver
S . 5 . . . . T /usr/X11R6/lib/modules/libvgahw.a

So why post this? Well, mostly to document the result, and to make a record of the file attribute characters.

The eight characters mean differences in:
S - size
M - file type or permissions (mode)
5 - MD5 checksum
D - major/minor device number
L - access path (read-link)
U - user (owner)
G - group
T - mtime stamp (modification time)

Between attribute characters and the file name, the file's type (as in "purpose") may be listed. In my output I got 'c' - a configuration file.


All I know now, that the checksum on the xserver file cannot be verified and that the module archive file has a different size, mtime and checksum (considering what type of file it is - hardly surprising).

So, have I learned anything - not really, but it gave me a chance to experiment with verifying packages ;-)