Comment 3 for bug 435130

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package eucalyptus - 1.6~bzr854-0ubuntu7

eucalyptus (1.6~bzr854-0ubuntu7) karmic; urgency=low

  [ Dustin Kirkland ]
  * tools/ exit 0, rather than 1, in the -nc
    init script when unconfigured, related to bug LP: #430075
  * debian/, debian/ help registration
    with local sync, no rsync parameters
  * debian/eucalyptus-common.postrm: prune eucalyptus files from /etc and
    /var on package purge, essential for testing, LP: #436928

  [ Matt Zimmerman ]
  * Revert revno 573, as according to Dan Nurmi it broke registration entirely
  * Apply upstream revno 895, as according to Dan this fixes the same bug that
    revno 573 attempted to fix, but properly (without breaking registration)
  * debian/eucalyptus-cc.postinst: Guard update-rc.d remove calls so that they
    don't run on initial installation. Because -cc could be configured before
    or after -walrus/-cloud, this could cause -cc to clobber -walrus/-cloud
    init scripts on initial installation
  * tools/eucalyptus.conf: Don't try to run shell code here; it isn't (always)
    interpreted as a shell script
  * debian/eucalyptus-cc.postinst: Use euca_conf --import-conf to copy the
    network settings into eucalyptus.conf instead
  * Set the default VNET_MODE to MANAGED-NOVLAN
  * The three preceding changes close LP: #435130
  * Store the CC name in a new config file /etc/eucalyptus/eucalyptus-cc.conf
    and get rid of /etc/eucalyptus/installer-cc.conf

  [ Steve Langasek ]
  * Move eucalyptus-nc "no VT" handling for LP: #426830 to a debconf script
    instead, so that users are a bit more likely to see this.
  * Drop the dpkg-statoverride check on /var/lib/eucalyptus/keys in the
    eucalyptus-common postinst; this was ineffective anyway because we'd done
    a chown -R immediately before that, so the only part that was respecting
    statoverride were the directory perms.

 -- Dustin Kirkland <email address hidden> Sat, 26 Sep 2009 00:30:18 -0700