A script for supporting multiple Ubuntu releases in a PPA

Something I find time consuming is uploading to a PPA when you want to support multiple Ubuntu releases. For my projects I generally want to support the most recent LTS release, the current stable release and the current development release (precise, quantal and raring when this was written).

I have my program in a branch and release that with make distcheck and lp-project-upload. The packaging is stored in another branch.

For each release I update the packaging with dch -i and add a new entry, e.g.

myproject (0.1.5-0ubuntu1) precise; urgency=low

  * New upstream release:
    - New exciting stuff

 -- Me <me@canonical.com>  Thu, 27 Dec 2012 16:52:22 +1300

I then run release.sh and this generates three source packages and uploads them to the PPA:

NAME=myproject
PPA=ppa:myteam/myproject
RELEASES="raring quantal precise"

VERSION=`head -1 debian/changelog | grep -o '[0-9.]*' | head -1`
ORIG_RELEASE=`head -1 debian/changelog | sed 's/.*) \(.*\);.*/\1/'`
for RELEASE in $RELEASES ;
do
  cp debian/changelog debian/changelog.backup
  sed -i "s/${ORIG_RELEASE}/${RELEASE}/;s/0ubuntu1/0ubuntu1~${RELEASE}1/" debian/changelog
  bzr-buildpackage -S -- -sa
  dput ${PPA} ../${NAME}_${VERSION}-0ubuntu1~${RELEASE}1_source.changes
  mv debian/changelog.backup debian/changelog
done

Hope this is useful for someone!

Note I don't use source recipes as I want just a single package uploaded for each release.

Testing Kerberos in Ubuntu

In fixing a LightDM bug recently I needed to set up Kerberos authentication for testing. Now, Kerberos comes with quite a reputation for complexity so this was not a task I was looking forward to. And googling around to get some simple Ubuntu instructions only ended up confirming my expectations. But in the end, I was able to get it to work [1] and here is what I did. You should probably not rely on this information for an actual Kerberos implementation.

I start with two machines running Ubuntu, one as the Kerberos server [2] and one as a client. The client is already installed with a user account called test.

Server configuration

Edit /etc/krb5.conf to set the default realm [3]:

 

[libdefaults]

default_realm = TEST

Install the Kerberos server:

$ sudo apt-get install krb5-kdc krb5-admin-server

Create the realm. You will be prompted for a master password for the realm:

$ sudo krb5_newrealm

Add a new user (called a principal in Kerberos language) into the realm with the same username as on the client. You will be prompted for a password for this user [4]:

$ sudo kadmin.local
kadmin.local:  add_principal test

And now the server should be running. You can check things are working by watching the log:

$ tail -f /var/log/auth.log

Client configuration

The client is a lot easier, as the packages do most of the work for you:

$ sudo apt-get install krb5-user

You will be prompted for the following information:

• Set "Default Kerberos version 5 realm" to TEST
• Set "Kerberos server for your realm" to address / hostname of your server
• Set "Administrative server for your Kerberos realm" to address / hostname of your server

Now you can test by getting a ticket [5] from the server. You will be prompted for the password you set when running kadmin.local on the server:

$ kinit
$ kdestroy

If that worked then you're ready to go. Have a look at the auth.log on the sever if it didn't work (the error messages are a bit cryptic though).

The next step is to setup PAM [6] to allow authentication with Kerberos. There's no configuration required, just install it:

$ sudo apt-get install libpam-krb5

Now you can log into your client machine (e.g. from LightDM/Unity Greeter) using the Kerberos password you setup on the server. Remember if something went wrong you can still use the local password to get in [7].

The reason I set all this up was to test Kerberos accounts which need password changes. You can control this feature from the server using the following:

$ sudo kadmin.local
kadmin.local:  modify_principal +needchange test


[1] on Ubuntu 13.04 (server) and 12.04 (client). I don't know which other combinations will work.
[2] Called a Key Distribution Centre in Kerberos jargon.
[3] Kerberos calls different authentication domains realms. I've used the realm TEST though in proper usage this would be a domain name e.g. EXAMPLE.COM to avoid name collision.
[4] You will already have a password set for this user on the client machine. Pick a different password as this allows you log in with either Kerberos or local passwords - both passwords will work.
[5] A ticket is the name for an authentication token provided by the server. In a real implementation this ticket will allow you to access services without re-entering your password.
[6] PAM is the library that does authentication when logging into Ubuntu.
[7] The PAM configuration that the packages setup first tries your password with the Kerberos server, then the local passwords (/etc/shadow) if that fails.

So You Want to Write a LightDM Greeter…

Matt Fischer wrote a great post about writing a greeter for LightDM.  Runs through an example of a Python greeter and how it works.