Thursday 30 October 2008

Montreal Intepid Ibex release party + Ubuntu OpenWeek

Wow. Great stuff. I'm at the release party in Montreal, and there's a lot of people... Okay, by the standards of other places, we're probably just a handful at 40 people, but at least we're filling the room :) Fortunately, we've got the great talents of some support people from Canonical, as well as the guys from FACIL making CDs for people to install Intrepid on their systems. Beer is flowing too, so that's always good news :)

So, thanks to MagicFab, Drago, Etienne, Saïd, Yannick... am I forgetting anyone? For throwing this great party!

Also, thanks to Oguz Yarimtepe (I've noticed his post on Ubuntuweblogs.org) for bringing this to my attention. There's a LOT of really interesting subjects that will be discussed for openweek, and thankfully, in my timezone, all of them are at a time I can easily follow and take part in the discussions -- So I really intend to follow as many as possible of the classrooms, especially what touches to Bazaar and packaging, since those are definitely very interesting subjects to me.

Tuesday 28 October 2008

Intrepid Ibex release parties

With the release of Intrepid Ibex in just two days (at the time of this writing), come the inevitable release parties.

If you're from Montreal, or the province of Quebec in general (or even if you live elsewhere and feel like meeting the people here!), feel free to show up at the Montreal Intrepid release party, which will be held on October 30th, 2008; at Bar St-Sulpice in Montreal, starting at 18h00. You'll be able to meet the people who make the Quebec (and Canada) Teams work. We can all have a beer and celebrate the truly outstanding work that's being done to bring to an unsuspecting world another great release!

And if you're from Quebec city, you should know that there is also a party there, same date and time, at Bistro Zonorange.

While you're at it, if you're from Quebec why not join the Quebec Team on Launchpad? Moreover, if you would be interested in finding a way to get.. maybe a plugin for the SRC (Radio-Canada) much like the Totem plugin for the BBC, or some other way of getting easily accessible information and broadcasting on Linux, don't hesitate to subscribe to the Ubuntu-QC mailing list.

Also, the global Ubuntu community always needs new people to help with bugs, answer questions, or document stuff.

Wednesday 22 October 2008

call for testing: network-manager-vpnc update

I've been working on a patch to network-manager-vpnc to better support one-time-passwords (OTP), as suggested by Dan Williams on the NetworkManager discussion list:

http://mail.gnome.org/archives/networkmanager-list/2008-October/msg00094.html

If anyone is a little familiar with NetworkManager, and more specifically connecting to VPNs (using the VPNC plugin), then I'd really appreciate if you could test the two updated packages I've built for Intrepid; network-manager-gnome and network-manager-vpnc. Using OTPs to connect to the VPN is a plus.

Some of the major changes are in the vpn connection configuration dialog, where you can setup the type of password to use for the user password and for the group password. The options in both cases are either "Default", for the standard behavior, or static passwords that can be saved to the gnome keyring; "OTP", for one-time-passwords which will be prompted for at every connection (technically saved in the keyring if you choose to do so, but ignored and reprompted every time), or "Unused", for a password that's not actually being used in a particular connection type (I may have missed something there, this is also a case I'd like to test more thoroughly).

Along with the changes above, the authentication dialog only shows the passwords that are OTP or not in keyring, unless it is a "reprompt", in which case even known passwords are shown again, to get a chance to fix spelling mistakes.

The packages are found on my PPA, can be retrieved by using the following lines in /etc/apt/sources.list:

deb http://ppa.launchpad.net/mathieu-tl/ubuntu intrepid main
deb-src http://ppa.launchpad.net/mathieu-tl/ubuntu intrepid main
And can be downloaded separately:

network-manager-applet
- 0.7~~svn20081020t000444-0ubuntu2~ppaintrepid1 (i386)
network-manager-vpnc - 0.7~~svn20081015t024626-0ubuntu2~ppaintrepid1 (i386)

If you'd prefer to apply the patches yourself, I also have them available on Launchpad, in my bzr code branch shortly: lp:~mathieu-tl/+junk/patches. I'll check it again later, bazaar is still giving me trouble.

Thanks to anyone who comments and gives me constructive criticism... :)

Tuesday 7 October 2008

network-manager-vpnc regression

I may or may not have blogged about this in the past, but given the nature of my work I use network-manager, vpnc, and network-manager-vpnc a lot. I noticed recently that there was no longer an option to save the group password only in network-manager-vpnc's authentication dialog, something I had already worked on to some extent.

So I looked at it again.

This time, it's been a little more complicated. Given that the current version of network-manager-vpnc comes out of SVN, there has been major changes from 0.6.x which have forced me to revise quite a few parts of the initial patches I had found on FC8. After about 3 and a half hours of work, I can finally say that it works -- and I'm happy about it too, because I see it as a pretty nice accomplishment given that I'm a novice at tackling bugs, far from used to the way code works in Gnome, and much less in a system as complex as NetworkManager.

For those who are actually interested in the results, my patch is up on the gnome bug #363918, and also on the relevant Launchpad bug #262191.

A working (based on the tests I did, anyway) package is up on my PPA, too.

How-to fix SVN's bug 160004: corrupted file system.

My notes on the subject... The idea is generally to revert to the last sucessful commit, then work from there. It's less than ideal, but at least it's relatively safe to do, and easy.

First, find the commit that broke things:

svnlook youngest /path/to/repository
Next, check whether the commit was successful, and proceed on backwards in revision numbers until you find one that works:

svnadmin dump /path/to/repository -r rev_number_from_svnlook --incremental > /home/mtrudel/rev_dump.svndump
If it works, you're stuck. If it fails, and it should, continue on to the previous build (current_build - 1), if it succeeds, you can do the following:

  • Edit /path/to/repository/db/current, change the first item (revision number) to the revision that works.
  • Try to checkout -- things should work.
  • Try to checkin changes -- things should work.
You should obviously do this with exclusive access to the SVN repository you're trying to fix, *just in case*, so shutdown Apache, svnserve or whatever else may be publishing the repository.

Other details:
  • svnadmin verify is a bad idea on repos with a large number of commits, if resolution time is critical and the information in the last commit is not too important.
  • Take backups of any files you modify.

Friday 3 October 2008

Automatic mounting of Samba shares

Here's a nice complement to using Likewise, which is in the Ubuntu repositories, to handle among other things, the mounting of Samba shares on logon: pam_mount. This article assumes that you've already done everything necessary to make Likewise work properly in your environment.

Sadly, there was a lot of documentation about earlier versions of pam_mount, and very few (or few that I could find) about this newer version packaged in Ubuntu. Hopefully this will help people who have been struggling with making it work properly on their installs.

Pam_mount is easy to install:
sudo apt-get install libpam-mount
Once installed, you will want to edit /etc/security/pam_mount.conf.xml to uncomment a line:

<luserconf name=".pam_mount.conf.xml" />
And perhaps the debug line just above it if you need to troubleshoot potential issues.

Then, create a file in your home directory: .pam_mount.conf.xml. Here is mine, for example:


<pam_mount>
<volume user="*" fstype="cifs" server="fileserver1" path="share34" mountpoint="~/share34" options="iocharset=utf8,file_mode=0700,dir_mode=0700,nodev,nosuid" />
<volume user="*" fstype="cifs" server="fileserver1" path="share35" mountpoint="~/share35" options="iocharset=utf8,file_mode=0700,dir_mode=0700,nodev,nosuid" />
</pam_mount>


Once you've enabled pam_mount by adding it in common-session and common-auth with the following line, this file will allow mounting on login \\fileserver1\share34 and \\fileserver2\share35 in ~/share34 and ~/share35 respectively, without having the enter your password if you were already using Likewise as an authentication mechanism. One interesting detail is precisely the tilde in the mountpoint path, since in the case of full paths and the pam_mount $(USER) variable for example, you may be catching other issues, such as how to transform a DOMAIN\user name in a /home/DOMAIN/user path. The good old '~' takes care of that issue. At the same time, 'user="*"' seems to resolve to the currently logged in user, so if you were deploying multiple systems from a kickstart or cloning; or keeping a generic .pam_mount.conf.xml in /etc/skel for mounting public shares, you can keep only one file that works for everyone. Keeping the generic volume tags in the main /etc/security/pam_mount.conf.xml can also be a good idea.

So far, the tests we've been doing at work seem to indicate that these lines needs to be added in common-session and common-auth, though maybe it's possible to do it with fewer changes, or a slightly different line:

For common-session, around the top, I guess:
session optional pam_mount.so nullok try_first_pass
For common-auth, around the end, so that it's evaluated at the very least after pam_lwidentity.so:
auth optional pam_mount.so nullok try_first_pass
I'm fairly confident that "nullok" could be omitted on both lines, since empty passwords are probably not allowed in your Windows domain.

Also, pam_mount can also handle mounting different types of filesystems, such as truecrypt filesystems :)