I’m not really sure about it, but there seems to be a bug in the current BIOS revision which has a rather annoying consequence: if you only activate ONE NIC in the BIOS, the OS can’t see it. As soon as you activate 2+ NICs, the OS sees all of them. And by “see” I mean that they even don’t show up in an “lspci”… Odd. This probably also happens on RHEL 5.3, which is an officially supported OS by HP on this machine.

Here are the culprits:

02:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)
02:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)

If you simply launch a “yum install gsynaptics” and try to launch it, you get an error message:

GSynaptics couldn’t initialize.
You have to set ‘SHMConfig’ ‘true’ in xorg.conf or XF86Config to use GSynaptics

As I previously told you, since Fedora 10 the xorg.conf doesn’t exist anymore. The whole peripheral detection and configuration is now done by HAL (Hardware Abstraction Layer). A good article explaining HAL can be found in Red Hat Magazine #3.

The most important thing you learn from there is that the devices are configured trough several different information sources, one of them being “Device Information Files” located in /usr/share/hal/fdi/. These files are standard XML files approximately matching the sections we had in the xorg.conf file (for what’s concerning us).

I started poking around the Internet to know how to add this SHMConfig option to HAL and quickly came across Pingou’s post.  It’s a quick little howto but it doesn’t tell me how things work behind the scenes, and I like to know such things

Let’s get started in our configuration…

Step 1: what do you see, HAL?

First of all, we need to know what HAL is seeing. For that, we have the handy “lshal” command, which behaves like lspci or lsusb. A quick search in the results shows us our TouchPad:

udi = ‘/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port_logicaldev_input_0′
access_control.file = ‘/dev/input/event7′  (string)
access_control.type = ‘mouse’  (string)
info.callouts.add = {‘hal-acl-tool –add-device’, ‘hal-probe-vmmouse’} (string list)
info.callouts.remove = {‘hal-acl-tool –remove-device’} (string list)
info.capabilities = {‘input’, ‘input.mouse’, ‘input.touchpad’, ‘access_control’} (string list)
info.category = ‘input’  (string)
info.parent = ‘/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port’  (string)
info.product = ‘AlpsPS/2 ALPS DualPoint TouchPad’  (string)
info.subsystem = ‘input’  (string)
info.udi = ‘/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port_logicaldev_input_0′  (string)
input.device = ‘/dev/input/event7′  (string)
input.originating_device = ‘/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port’  (string)
input.product = ‘AlpsPS/2 ALPS DualPoint TouchPad’  (string)
input.x11_driver = ‘synaptics’  (string)
linux.device_file = ‘/dev/input/event7′  (string)
linux.hotplug_type = 2  (0×2)  (int)
linux.subsystem = ‘input’  (string)
linux.sysfs_path = ‘/sys/devices/platform/i8042/serio1/input/input7/event7′  (string)

We can clearly see that the used driver is synaptics and the precise hardware is an ALPS TouchPad.

Step 2: configuring the synaptics driver

Now that we are sure the synaptics driver is used, we have to look in /usr/share/hal/fdi/ if there is a corresponding “Device Information File”.

A “find” later, we can see /usr/share/hal/fdi/policy/20thirdparty/10-synaptics.fdi which sounds like a good start. This file contains a section which perfectly matches the “lshal” output for my TouchPad:

<match key=”info.product” contains=”AlpsPS/2 ALPS”>
<merge key=”input.x11_driver” type=”string”>synaptics</merge>
</match>

In theory, we could add our configuration right here by replacing the previous lines with:

<match key=”info.product” contains=”AlpsPS/2 ALPS”>
<merge key=”input.x11_driver” type=”string”>synaptics</merge>
<merge key=”input.x11_options.SHMConfig” type=”string”>On</merge>
</match>

This works perfectly if you reboot your system, but it’s a bit ugly to edit these files directly. There is a much more elegant solution: add the configuration change to a file in the /etc/hal/fdi/policy/ directory. The files in this directory are automatically read each time you restart HAL.

So, I created a file called “touchpad.fdi” in this directory with the desired modifications:

<match key=”info.product” contains=”AlpsPS/2 ALPS”>
<merge key=”input.x11_options.SHMConfig” type=”string”>On</merge>
</match>

At the next reboot, HAL will read this file + the file in /usr/share/hal/fdi/policy and merge te contents of the AlpsPS/2 ALPS tags.

Done, GSynaptics starts and we begin to understand how HAL works . If we look at the “lashal” output again, we can see that the modification is effective:

udi = ‘/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port_logicaldev_input_0′
access_control.file = ‘/dev/input/event7′  (string)
access_control.type = ‘mouse’  (string)
info.callouts.add = {‘hal-acl-tool –add-device’, ‘hal-probe-vmmouse’} (string list)
info.callouts.remove = {‘hal-acl-tool –remove-device’} (string list)
info.capabilities = {‘input’, ‘input.mouse’, ‘input.touchpad’, ‘access_control’} (string list)
info.category = ‘input’  (string)
info.parent = ‘/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port’  (string)
info.product = ‘AlpsPS/2 ALPS DualPoint TouchPad’  (string)
info.subsystem = ‘input’  (string)
info.udi = ‘/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port_logicaldev_input_0′  (string)
input.device = ‘/dev/input/event7′  (string)
input.originating_device = ‘/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port’  (string)
input.product = ‘AlpsPS/2 ALPS DualPoint TouchPad’  (string)
input.x11_driver = ‘synaptics’  (string)
input.x11_options.SHMConfig = ‘On’  (string)
linux.device_file = ‘/dev/input/event7′  (string)
linux.hotplug_type = 2  (0×2)  (int)
linux.subsystem = ‘input’  (string)
linux.sysfs_path = ‘/sys/devices/platform/i8042/serio1/input/input7/event7′  (string)

I’m not a HAL expert at all, this is my first look at it, so let me know if I said something stupid.

I had a closer look at my .evolution folder and figured out that there was a huge “cache” directory for each mail account. This folder seems to contain ALL the messages I ever sent/received since the account’s creation.

I can’t see why there should be any cache for POP accounts (seems to be an IMAP feature), and why that cache is still there after emptying the trash…a Google search later, this seems to be a known bug.

I manually deleted the content of the cache folders and everything seems to work fine, no consequence on my inbox content.

So, if you are using Evolution with a POP account and you wonder where your disk space has gone, have a look at this…

Today, we are going to learn how to configure your computer and a server to allow automatic SSH authentications using your public RSA key. Less work = More fun!

Configuration on your computer:

As your normal user, open a terminal and type ssh-keygen

It will ask you some questions, you can simply press enter to acknowledge the default choices. You don’t need to enter a password here if you don’t want to be asked for it at each login on the server, it’s not a security flaw. The output should be something like that:

[Steven@HP6710 ~]$ ssh-keygen

Generating public/private rsa key pair.

Enter file in which to save the key (/home/Steven/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/Steven/.ssh/id_rsa.

Your public key has been saved in /home/Steven/.ssh/id_rsa.pub.

The important thing is that you have 2 new files in your user/.ssh directory.

• id_rsa is your private key, you should NEVER give it away.
• id_rsa.pub on the other side is your public key, the one that you can give away.

Configuration on the server:

As the user you wish to be logged in (let’s say root), also run the ssh-keygen command to create the /root/.ssh directory. Now go to your /root/.ssh directory and create a text file named authorized_keys2. Copy the content of your computer’s public key file (id_rsa.pub on HP6710) to this file and save it.

Job done, now you can run ssh root@server from your computer and it will log you in automagically