Archive for June, 2009

Changing package dependency info in Ubuntu

Posted in Uncategorized on June 22, 2009 by voline

Below I describe a general technique for modifying dependency info of a package to fool the package manager into allowing the package to be installed. I describe this technique using the specific example of installing firefox-3.5 from a third-party repository which contained the dependency problem I needed to resolve.


Recently I wanted to test out the new firefox-3.5 on my Ubuntu 8.10 (Intrepid) and I didn’t want to upgrade (I don’t think its in jaunty anyway) due to a previous upgrade disaster to jaunty. Googling around I found Ubuntu Mozilla Daily Build Team, which has an ubuntu repository of the latest firefox builds, among other mozilla related stuff.

So I did the whole “add foreign repository” process, adding the repository and verification key. Then I did did an update and tried to install the firefox-3.5 package through the synaptics gui. It complained about not being able to satisfy dependencies and wouldn’t let me mark it for installation.

Upon further investigation, I concluded that the issue was that firefox-3.5 had a dependency for xulrunner-1.9.1 (>= 1.9.1~rc2). But the only version of xulrunner that the repository had was version 1.9.1~hg20090620r26001+nobinonly-0ubuntu1~umd1~intrepid. Since the firefox-3.5 package was version 3.5~hg20090620r26001+nobinonly-0ubuntu1~umd1~intrepid, I assumed that was the correct version of the xulrunner-1.9.1. I haven’t looked into it, but it must be that debian/ubuntu’s version comparison routine thinks that 1.9.1~rc2 > 1.9.1~hg20090620r26001+nobinonly-0ubuntu1~umd1~intrepid, but the package maintainers actually thought that should be false. Thus, I concluded that it should be safe to force the installation of the packages, even if I had to fool the package manager.

Fooling the package manager

Here’s what I did and I know there are other ways of achieving the same thing. Since synaptics wouldn’t even let me mark the package for upgrade, I didn’t have the firefox-3.5 deb package in the package cache. So to get synaptics to retrieve the deb, I first had to fool it into thinking the dependency could be met. I did this by modifying the cached repository list for the packages, which in my cases was /var/lib/apt/lists/ppa.launchpad.net_ubuntu-mozilla-daily_ppa_ubuntu_dists_intrepid_main_binary-i386_Packages. I searched for the line “Package: firefox-3.5”, which will get you to the section on that package. In that section, there is dependency information about the package and I modified “xulrunner-1.9.1 (>= 1.9.1~rc2)” to “xulrunner-1.9.1 (>= 1.9.0)”, which I figured was sure to pass the version test.

I restarted synaptics and was able to mark the packages fro upgrade. However, when I tried to then install the packages, they were downloaded but failed on installation. This was the debian package management system, which ubuntu is built on, has dependency information in the packages as well. That makes sense, because one might want to install a package that didn’t come from a repository, but causes more work for me.

So I needed to now modify the dependency information inside the deb package file. I went to the package cache directory, /var/cache/apt/archives, where the downloaded deb packages are stored. The firefox-3.5 package was extracted with dpkg-deb -x <deb file> <extracted archive dir> and dpkg-deb -e <deb file> <extracted archive dir>/DEBIAN, the latter being needed to extract the dependency file. The contents of <extracted archive dir>/DEBIAN/control look very similar to the firefox-3.5 section of the cached package listing file we modified earlier. I changed the dependency to match the change in the cached package listing file and rebuilt the deb package with dpkg-deb -b.

Now, at this point I thought I would be good to go. It turns out that now your package won’t match file verification values in the package listing (noticed the MD5sum and SHA1 lines?). So I modified the size, md5, and sha1 values in the package listing. Upon reinstalling firefox-3.5 from synaptics, everything installed with out a hitch and I now have a functioning firefox 3.5 to play with.

NOTE: Make sure that in the last step of reinstalling firefox-3.5 from synaptics that you aren’t downloading any files. If you are, then your size, md5, and/or sha1 values are probably not correct. It definitely won’t work if you are downloading data because your modified package in the package cache will get overwritten with the original.


Spit user accounts for one domain between google and other hosts using postfix

Posted in Uncategorized with tags , on June 1, 2009 by voline

Here’s the situation. You own your own domain and have a postfix smtp server to configure. You’d like to host some of the email users for your domain on gmail because its easy to maintain and provides most of the features your average user wants. However you have some users that require some advanced features which google does not provide, so you want to have those email accounts hosted on a server you control. How do you do setup postfix to send some accounts to gmail and some to your other email server?

Conceptual Overview

Suppose you have email address, which you want to have email sent to it end up on google’s gmail servers, and, which will go to your own servers. All mail will be configured to route through your postfix server, which will be configured to send the mail to the appropriate places depending on the address.


Configuring google apps account

First of all, hosting your email on gmail, such that you are using your domain, wouldn’t be possible without google’s relatively new google apps hosting feature. You need to first get an apps account, if yo don’t already have one. I’ll assume you can figure out how to setup the google account. Its pretty straight forward and nothing tricky about it, just follow the instructions. Make sure you verify your domain, but don’t follow the instructions for activating email for the account. Also make sure you create a user for each email account you want hosted on gmail.

Configuring DNS

Modify the instructions given by google in the process of activating email for your apps account such that instead of using your domain as instructed for configuring your MX records, use a subdomain of your domain. For the purposes of this article, I will be using So for instance, your dns should be setup such that MX record for with priority 10 points to Have the MX records for the domain ( point to your postfix server. Also, gmail servers will not allow relaying, that is your smtp server sending email to it, unless the reverse DNS mapping for the IP of the smtp server corresponds to the domain given by postfix client to gmail smtp servers, which is controlled by the myhostname configuration parameter in So as far as I can tell, if you don’t control the reverse DNS record for your smtp server’s IP, this probably won’t work.

Configuring Postfix

I will not go into configuring your postfix server for delivering mail, since this is really specific to your setup and not the point of this article. Assume that by default you already have postfix setup to deliver email to to some other default destination. To tell postfix to route to gmail’s servers, use the following config snippets:


virtual_alias_maps = hash:/etc/postfix/virtual
smtp_generic_maps = hash:/etc/postfix/generic



Of course, depending on your setup, the absolute paths here and how you store your virtual table may change. When receives mail, she will not have a To header as Also when sending email, one should not send email to, as this mail will be rejected by gmail’s servers.


Using this setup you need to add a virtual alias for every user you want to have forwarded to gmail. You can setup postfix to forward all accounts by default to gmail and selective route others to other destinations by modifying these instructions to by default send mail to gmail and change the subdomain MX records to point to the other destination (or if the destination is the local box only postfix need be modified). This is left as an exercise to the reader.

If you are using sasl authentication, you should make sure, if you desire, that the authentication coincides with the gmail account. Usually, when authing with gmail’s smtp servers to send outgoing mail, the username and password are the same for logging into the account via the web interface or imap. If you already have an auth mechanism setup for the default delivery point, it won’t know about the gmail user credentials and so won’t be able to auth them. You probably don’t want to just set your email clients outgoing smtp server to google’s because, then when you send an email to google thinks it should be the owner of that domain and see that that user does not exist and bounce your mail. So to effectively send mail across the two delivery points, the mail must go through the postfix server. Just make sure your auth mechanism knows about your gmail users and auths the correctly.