update-manager update-motd scripts delays login when the network is firewalled

On further inspection, it appears that Lucid is "phoning home" to "rookery.canonical.com" every time I log in.
It's failures were being reported in my firewall log.

iptables: IN= OUT=ppp0 SRC=X.X.X.X DST=91.189.90.132 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=53213 DF PROTO=TCP SPT=44608 DPT=80 WINDOW=5808 RES=0x00 SYN URGP=0

If you're happy to let the MOTD scripts phone home, the problem can be fixed by adding an iptables rule (or the equivalent ufw command):

iptables -A OUTPUT -d rookery.canonical.com --dport 80 -j ACCEPT

This can also be mitigated by a more aggressive timeout:

Edit
/usr/lib/python2.6/dist-packages/UpdateManager/Core/MetaRelease.py

Change the timeout parameter on line 247 to 2 seconds:

            uri=urllib2.urlopen(req, timeout=2)

Thanks,
Mark

Excuse me? Why is Ubuntu phoning home now? This is serious.

/me not amused

Some (like myself and, it seems, Mr. Leggewie) do have the POV that no network traffic or connections should be initiated without intent of the user. A way for a user to intend to make the network connections would be to select to do network updates during installation.

I did not have an internet connection up during install and did not select automatic updates.

/etc/update-motd.d/91-release-upgrade is checking whether a new release is available. The goal here is to provide an experience similar to the "New release available" button when update-manager is run.

In order to keep a good experience I suggests that none of the script run by update-motd should make any network connections. The part that requires network connections should be a background task or a cron job.

Proposed fix in lp:~kirkland/update-manager/522452.

Hi Michael-

Assigning to you, as I'd like your opinion on the proposed fix before merging/uploading.

Thanks!

Aha!

I have a much better way of doing this..

No need for a cronjob.

In the update motd script:
  if upgrade-available cache file is populated, print it
  else if it's available but empty, check its timestamp, and if it's older than 1 day old, update the cache file in the background
  else if it doesn't exist, update it in the background

Profit! I'm going to go ahead and commit that version now. I'll wait for Michael to release it though.

Fix committed.

Could you take a look and release at your earliest convenience, Michael?

Thanks!

This bug was fixed in the package update-manager - 1:0.133

---------------
update-manager (1:0.133) lucid; urgency=low

  [ Michael Vogt ]
  * UpdateManager/Core/MetaRelease.py:
    - allow upgrade from unsupported version to unsupported version
  * DistUpgrade/removal_blacklist.cfg:
    - allow removal of update-manager-kde
  * check-new-release-gtk:
    - fixes in the gtk release upgrade check
  * DistUpgrade/xorg_fix_proprietary.py:
    - if /etc/X11/XF86Config-4 is found on upgrade, rename it to
      "XF86Config-4.obsolete"
    - write log to "/var/log/dist-upgrade/xorg_fixup.log"
  * do-release-upgrade, check-new-release:
    - implemented "check-releae-upgrade" as symlink to do-release-upgrade
      and automatically run with "--check-dist-upgrade-only" when called
      as c-r-u
    - add --quiet option to do-release-upgrade
  * debian/update-manager-core.links:
    - install /usr/lib/update-manager/check-new-release as symlink to
      do-release-upgrade -c

  [ Wesley Schwengle ]
  * Check for release upgrade is now also possible with do-release-upgrade
    command: do-release-upgrade -c. (LP: #415026)
  * Added --version/-V to do-release-upgrade (similar to update-manager)

  [ Dustin Kirkland ]
  * debian/91-release-upgrade, debian/update-manager-core.install,
    - some users are complaining of long login times due to the release
      check requiring network connectivity; this information clearly doesn't
      change as frequently as the user logging in, so maintain a cache file
      in /var/lib, display it if it's populated, but otherwise, update it in
      the background if its either missing or the file is older than a day
      old, LP: #522452

  [ Jonathan Riddell ]
  * Do not allow for the removal of update-manager-kde, we do want it after all
 -- Michael Vogt <email address hidden> Mon, 08 Mar 2010 20:58:44 +0100