Plugin the headphones on the front panel of my box didn’t mute the output to the speakers, which nullified the purpose of having headphones.

I long thought that it was some hardware issue that I would have to sort some day by opening the box and checking the connections.

Yesterday, I decided to solve it for good and I started to google… and found out that it was a pure software issue!

The culprit sounded to be some unproper settings of the ALSA module and this Ubuntu guide just saved me.

I carefully followed the steps and it appeared that for my Gigabyte GA-790FXTA-UD5, it was necessary to this line:

add options snd-hda-intel model=3stack-hp

to

/etc/modprobe.d/alsa-base.conf

Ok, it did not go so smoothly as I picked out randomly models from the list until I find the right one (I had no idea of what was embbeded on my board). I hope this may help, as I have quite a lot of people with similar issues with all kinds of vendors.

Sadly, so far, there is even not the beginning of a replacement solution. Passwords will be there for long, so we would better use them accordingly.

Yes, I am aware of many on-line services like FisrtPass, KeePass, 1stPassword, etc. However, I don’t feel comfortable with having all my password somewhere on-line, even if they claim – and I believe they are sincere, that they use strong encryption and can’t access to it.

Instead, I use a combination of the Firefox password manager and the Pwgen add-on. I use this add-on to quickly and conveniently generate a random password when I subscribe to a web service. When Firefox prompts for it, I just choose to remember the password automatically. SSO quick and dirty.

For the other passwords that I can’t and don’t need to memorize, I store them in a local encrypted file.

To edit the file, I simply use Vim with this nice GPG plugin:

• copy gpg.vim to /home/$user/.vim/plugin
• if not done yet, generate you GPG key :

   $ gpg --gen-key

• Encrypt your password file and erase it:

  $ gpg --encrypt --recipient 'your name' passwords
  $ rm passwords

• Now, it’s done. Just edit password.gpg to decrypt and access to your passwords (you will be prompted for your passphrase):

  $ vim passwords.gpg

If you don’t like the overhead of GPG, a more straightforward solution is to use the OpenSSL extension :

• Copy the openssl.vim file to /home/$user/.vim/plugin as well.

• Now, to encrypt to file to, say, AES (note the .aes file extension which makes sense for the plugin):

  $ openssl aes-256-cbc -in passwords -out passwords.aes

• Decryption will occur as soon as you edit the file with Vim:

  $ vim passwords.aes

I believe that, if not perfect, it is pretty secure. I mean not more, not less than your system is. Anyway I don’t have any need for an on-line manager. And you, how do you manage your passwords? Let us know about your tips.

Being lazy, it happened that I did not backup my data. Yes, it is a shame, but inserting a drive and launching the commands to rsync the discs was preventing me from this best practice.

So, I decided to make it automatic. The goal was that the only thing I would have to do would be to insert the drive, and then remove it when it is done.

Thanks to the magic of Gnu/Linux, it had been very easy. I will show below how I did it, thought they are many things that could be improved (but I haven’t felt the need so far).

Udev

Udev not only allows to create /dev entries dynamically, but offers a lot of triggers to perfom all kind of actions when some hardware is inserted.

The udevinfo command will show you a lot of output concerning your drive. What we want is a unique way to differenciate the backup drive from any other drive that will be inserted in the future.

What would be better than the manufacturer serial ?

So let’s look for it :

$ udevinfo -a -p /sys/block/sdc | grep serial

*UPDATE 06/2011* It seems that on recent versions, the syntax of this command slightly changed into this :

$ udevadm info -a -p /sys/block/sdc | grep serial

Copy the serial.

Now we have to create a rule file, that will tell to udev what to do when this particular drive is inserted.

This is done in the /etc/udev/rules.d folder. Let’s create a file 30-mnt.rules or anything you like.

We edit this file so that it contains :

ACTION=="add",KERNEL=="sd*",SUBSYSTEMS=="usb", ATTRS{serial}=="57442D57584E3430394C5A38", RUN+="/home/jc/bin/backup/bckp-home.sh %k"

ACTION==”add” will tell udev that this action must be triggered when the drive is inserted.
SUBSYSTEMS could be changed according to the drive you are using (scsi, usb, …).
ATTRS{serial} must contain the serial you just grabbed.
RUN+=”/path/to/bin/backup.sh %k” tells udev to launch the backup script. %k, which contains the device name, sdc, is passed as an argument.

Optionally, it is quite convenient, you may want to make a symlink to the /dev/sd? device, with :

KERNEL=="sd*",SUBSYSTEMS=="scsi", ATTRS{model}=="GJ0250EAGSQ     ", SYMLINK+="ultrabay%n"

The shell script

Now, the script itself :

#!/bin/sh
LOGFILE=/PATH/TO/bckp.log
echo "--- BCKP - INFO : \$1=_${1}_" >> $LOGFILE
[[ $1 ]] || { echo "ERROR : missing parameter">>$LOGFILE; exit 1; }

# give time for the user, if needed to kill the process
sleep 6
MOUNT_PATH=$(grep $(echo $1) /etc/mtab | awk '{print $2}')
[[ $MOUNT_PATH ]] || {
  echo "ERROR fretching mount point">>$LOGFILE;
  exit 1;
}
echo " Synchronizing $MOUNT_PATH)">>$LOG

# add here all you rsync commands
rsync -av --delete /PATH/TO/DATA $MOUNT_PATH/backup/
...
exit 0

Testing it

Now, let’s reload udev :

$ sudo udevadm control --reload-rules

To test if it works :

$ sudo udevadm trigger

or maybe :

$ /etc/init.d/boot.udev restart

Plug off/in your drive, and the script should be executed as expected.

Optional : setting more options with Hal

It is not necessary at all for the backup script to work, but it would be very practical to have  a fixed mount point for a drive.
For instance, I use a second drive (in the untrabay slot of my thinkpad) that contains all my virtual machines.

The benefice is to prevent a performance drain of the system when many virtual machines are doing I/O like swapping or anything else.

Create a file like /etc/hal/fdi/policy/15-static-mount.fdi, containing :

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
    <match key="volume.uuid" string="aa0019ef-86e0-4011-b996-31ef3e7174c8">
      <merge key="volume.policy.should_mount" type="bool">true</merge>
      <merge key="volume.fstype" type="string">ext4</merge>
      <merge key="volume.policy.desired_mount_point" type="string">ultrabay</merge>
      <merge key="volume.label" type="string">Fuji</merge>
      <merge key="volume.policy.mount_option.noatime" type="bool">true</merge>
      <merge key="volume.policy.mount_option.acl" type="bool">true</merge>
    </match>
  </device>
</deviceinfo>

The drive is matched by it uuid. You can get the uuid of your disk with :

$ ls -la /dev/disk/by-uuid/

You can, if you want, set the volume label and specify several options of the file system.

However, the most interesting option is the “desired_mount_point” one which allow you to fix the mount point. In the example, the disk will always be mounted in /media/ultrabay, and not the system disk, or disk_1, etc.

Coming next !

That’s all for today folks. Let me know if there are some things not clear or that can be optimized.

Next time, we will see how to run the same script from Hal instead. We will also use Zenity to get a nice GUI prompt when the disk is inserted.

Very easy to set up :

$ zypper install mpg123

and it should work immediatly.

Cannot create link /etc/mtab~
Perhaps there is a stale lock file?

As a result, some of the partitions were not mounted and the system was pretty much broken.

But, no need to panic, just erase all the lock files (be careful not to erase the mtab file itself !) :

$ rm /etc/mtab~*

Now test mounting your partitions to check that you don’t get this message anymore :

$ mount -a

If it is alright, reboot and it should be fine.

This distribution is, by far, the best Linux environment for a desktop PC : very stable, up to date, polished, professional…

I also appreciate the huges improvements made on Yast and the package management system. Despite being an advanced user that like to use the command line, I reallly appreciate sometimes to have a nice graphical frontend that just do what I want easely and quickly.

openSUSE 11.1 deserves its increasing popularity. Really, give it a try !