[ Dustin Kirkland ]
* tools/eucalyptus-nc.in: exit 0, rather than 1, in the -nc
init script when unconfigured, related to bug LP: #430075
* debian/eucalyptus-cc.in, debian/eucalyptus-java-ws.in: 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.
This bug was fixed in the package eucalyptus - 1.6~bzr854-0ubuntu7
--------------- 0ubuntu7) karmic; urgency=low
eucalyptus (1.6~bzr854-
[ Dustin Kirkland ] s-nc.in: exit 0, rather than 1, in the -nc eucalyptus- cc.in, debian/ eucalyptus- java-ws. in: help registration eucalyptus- common. postrm: prune eucalyptus files from /etc and
* tools/eucalyptu
init script when unconfigured, related to bug LP: #430075
* debian/
with local sync, no rsync parameters
* debian/
/var on package purge, essential for testing, LP: #436928
[ Matt Zimmerman ] eucalyptus- cc.postinst: Guard update-rc.d remove calls so that they s.conf: Don't try to run shell code here; it isn't (always) eucalyptus- cc.postinst: Use euca_conf --import-conf to copy the /eucalyptus- cc.conf /installer- cc.conf
* 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/
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/eucalyptu
interpreted as a shell script
* debian/
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
and get rid of /etc/eucalyptus
[ Steve Langasek ] eucalyptus/ keys in the common postinst; this was ineffective anyway because we'd done
* 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-
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