MAAS

incorrect time on node causes failed oauth

Bug #978127 reported by Scott Moser on 2012-04-10

This bug affects 3 people

	Status	Importance	Assigned to
MAAS	Fix Released	Critical	Scott Moser
cloud-init	Fix Released	Medium	Scott Moser
cloud-init (Ubuntu)	Fix Released	High	Unassigned
Precise	Fix Released	High	Unassigned

Bug Description

=== Begin SRU Information ===
[Impact]
* For systems that have a broken or incorrectly set hardware clock,
   enlistment and commissioning into MAAS will fail. This is because
   ubuntu's system clock is initially seeded by the hardware clock, and
   OAUTH is used for authentication with the maas server. If the client
   clock differs by more than 5 minutes from the server clock,
   authentication will fail, and subsequently enlistment or commisioning
   will fail.
   This is also a problem after installation of the system as the same
   process for authentication is used.
* There is a need to backport this change in order to fully utilize 12.04
   and MAAS.
* The change in cloud-init is essentially this:
   If a request for access to the MAAS metadata service returns 401 or
   403 (unauthorized), then subsequent re-tries will modify the
   timestamp in the OAUTH request so that it matches the server.

[Test Case]
* To recreate the bug, you first need to get MAAS set up
   (http://maas.ubuntu.com/docs), and start a system for enlistment that would
   have an invalid clock. To force an invalid clock, do one of:
   * boot to a system bios and change the bios clock
   * modify the ephemeral image so that the clock is broken during boot.
     This can be accomplished by appending the following to
     /etc/init/cloud-init.conf inside an ephemeral image.
     | pre-start script
     | offset="10 minutes ago"
     | past=$(date -R --date "$offset")
     | date --set "$past" &&
     | echo ===== "set date to $past [$offset]" ===== ||
     | echo ===== "failed to set date to $past [$offset]" ====
     | end script
   This is actually more complex than that, because the ephemeral images
   already have this fix inside of them. So in order to reproduce, you have
   to downgrade the version of cloud-init inside the 12.04 ephemeral image
   to the version available in the ubuntu archive (0.6.3-0ubuntu1.1)
* After a sufficiently broken system is obtained, boot the system.
   If this fix is not present, enlistment or commissioning will fail
   to do anything as it will not have access to the metadata.
* Errors will be written to the MAAS server's /var/log/apache/error.log
* When the fix is applied, a single failure will occur, and then cloud-init
   will modify future requests.

[Regression Potential]
* Regression is limited to the MAAS datasource, which is not enabled by
default for cloud-init. Thus, only a user that is using MAAS or otherwise
takes explicit action to enable it will be affected.

[Other Info]
* This bug has essentially been fixed in maas enlistment and commissioning
   environments outside of the SRU process. The "ephemeral images" downloaded
   for MAAS have 12.10's version of cloud-init installed inside them.
   This all works reliably. We want to properly SRU the change so that
   installed systems will also be resilient to a bad hardware clock.

=== End SRU Information ===

=== original bug report ===
In this simple scenario:
a. hardware installed
b. hardware booted and enlisted
c. commissioning
d. install to hardware
e. cloud-init boot

At this point steps 'b' and 'e' do OAUTH to get user-data.

If the clock on the system is sufficiently off, then oauth will fail as shown in the attached screenshot.

it seems to make sense that 'b' would set the clock. Once the user enlists the systme to MAAS, it seems OK to start changing their hardware settings.

There is still a potential for really bad hardware clock that could forget its settings on reboot, or somehow get off between 'b' and 'c'. If we were really interested in fixing that, cloud-init could read a kernel command line parameter pointing to a system that ran an ntp server and just run that very early in boot to set the local date.

See original description

Tags:

Related branches

lp:~cloud-init-dev/cloud-init/trunk

Merged into lp:~hannes-georg-0/cloud-init/add_mkswap_force_flag

Chad Smith (community): Needs Fixing on 2017-06-06

Hannes: Pending requested 2016-05-30

Diff: 51583 lines (+11/-49380) (has conflicts)

424 files modified

.bzrignore (+0/-4)
ChangeLog (+0/-761)
HACKING.rst (+0/-48)
LICENSE (+0/-674)
MANIFEST.in (+0/-8)
Makefile (+0/-82)
README (+11/-0)
TODO.rst (+0/-43)
bin/cloud-init (+0/-673)
cloudinit/__init__.py (+0/-21)
cloudinit/cloud.py (+0/-109)
cloudinit/config/__init__.py (+0/-58)
cloudinit/config/cc_apt_configure.py (+0/-292)
cloudinit/config/cc_apt_pipelining.py (+0/-57)
cloudinit/config/cc_bootcmd.py (+0/-54)
cloudinit/config/cc_byobu.py (+0/-80)
cloudinit/config/cc_ca_certs.py (+0/-104)
cloudinit/config/cc_chef.py (+0/-342)
cloudinit/config/cc_debug.py (+0/-109)
cloudinit/config/cc_disable_ec2_metadata.py (+0/-36)
cloudinit/config/cc_emit_upstart.py (+0/-69)
cloudinit/config/cc_fan.py (+0/-101)
cloudinit/config/cc_final_message.py (+0/-73)
cloudinit/config/cc_foo.py (+0/-52)
cloudinit/config/cc_growpart.py (+0/-300)
cloudinit/config/cc_grub_dpkg.py (+0/-73)
cloudinit/config/cc_keys_to_console.py (+0/-62)
cloudinit/config/cc_landscape.py (+0/-99)
cloudinit/config/cc_locale.py (+0/-37)
cloudinit/config/cc_lxd.py (+0/-176)
cloudinit/config/cc_mcollective.py (+0/-88)
cloudinit/config/cc_migrator.py (+0/-85)
cloudinit/config/cc_mounts.py (+0/-405)
cloudinit/config/cc_package_update_upgrade_install.py (+0/-99)
cloudinit/config/cc_phone_home.py (+0/-122)
cloudinit/config/cc_power_state_change.py (+0/-223)
cloudinit/config/cc_puppet.py (+0/-118)
cloudinit/config/cc_resizefs.py (+0/-185)
cloudinit/config/cc_resolv_conf.py (+0/-116)
cloudinit/config/cc_rh_subscription.py (+0/-408)
cloudinit/config/cc_rightscale_userdata.py (+0/-102)
cloudinit/config/cc_rsyslog.py (+0/-366)
cloudinit/config/cc_runcmd.py (+0/-38)
cloudinit/config/cc_salt_minion.py (+0/-59)
cloudinit/config/cc_scripts_per_boot.py (+0/-41)
cloudinit/config/cc_scripts_per_instance.py (+0/-41)
cloudinit/config/cc_scripts_per_once.py (+0/-41)
cloudinit/config/cc_scripts_user.py (+0/-42)
cloudinit/config/cc_scripts_vendor.py (+0/-43)
cloudinit/config/cc_seed_random.py (+0/-94)
cloudinit/config/cc_set_hostname.py (+0/-37)
cloudinit/config/cc_set_passwords.py (+0/-167)
cloudinit/config/cc_snappy.py (+0/-304)
cloudinit/config/cc_ssh.py (+0/-142)
cloudinit/config/cc_ssh_authkey_fingerprints.py (+0/-105)
cloudinit/config/cc_ssh_import_id.py (+0/-99)
cloudinit/config/cc_timezone.py (+0/-39)
cloudinit/config/cc_ubuntu_init_switch.py (+0/-162)
cloudinit/config/cc_update_etc_hosts.py (+0/-60)
cloudinit/config/cc_update_hostname.py (+0/-43)
cloudinit/config/cc_users_groups.py (+0/-34)
cloudinit/config/cc_write_files.py (+0/-103)
cloudinit/config/cc_yum_add_repo.py (+0/-107)
cloudinit/cs_utils.py (+0/-105)
cloudinit/distros/__init__.py (+0/-950)
cloudinit/distros/arch.py (+0/-201)
cloudinit/distros/debian.py (+0/-227)
cloudinit/distros/fedora.py (+0/-31)
cloudinit/distros/freebsd.py (+0/-417)
cloudinit/distros/gentoo.py (+0/-160)
cloudinit/distros/net_util.py (+0/-182)
cloudinit/distros/parsers/__init__.py (+0/-28)
cloudinit/distros/parsers/hostname.py (+0/-88)
cloudinit/distros/parsers/hosts.py (+0/-92)
cloudinit/distros/parsers/resolv_conf.py (+0/-169)
cloudinit/distros/parsers/sys_conf.py (+0/-113)
cloudinit/distros/rhel.py (+0/-222)
cloudinit/distros/rhel_util.py (+0/-89)
cloudinit/distros/sles.py (+0/-179)
cloudinit/distros/ubuntu.py (+0/-31)
cloudinit/ec2_utils.py (+0/-201)
cloudinit/filters/__init__.py (+0/-21)
cloudinit/filters/launch_index.py (+0/-75)
cloudinit/handlers/__init__.py (+0/-274)
cloudinit/handlers/boot_hook.py (+0/-70)
cloudinit/handlers/cloud_config.py (+0/-163)
cloudinit/handlers/shell_script.py (+0/-55)
cloudinit/handlers/upstart_job.py (+0/-119)
cloudinit/helpers.py (+0/-458)
cloudinit/importer.py (+0/-58)
cloudinit/log.py (+0/-155)
cloudinit/mergers/__init__.py (+0/-166)
cloudinit/mergers/m_dict.py (+0/-88)
cloudinit/mergers/m_list.py (+0/-89)
cloudinit/mergers/m_str.py (+0/-46)
cloudinit/net/__init__.py (+0/-771)
cloudinit/net/network_state.py (+0/-447)
cloudinit/net/udev.py (+0/-54)
cloudinit/netinfo.py (+0/-249)
cloudinit/patcher.py (+0/-58)
cloudinit/registry.py (+0/-37)
cloudinit/reporting/__init__.py (+0/-42)
cloudinit/reporting/events.py (+0/-248)
cloudinit/reporting/handlers.py (+0/-91)
cloudinit/safeyaml.py (+0/-32)
cloudinit/settings.py (+0/-68)
cloudinit/signal_handler.py (+0/-71)
cloudinit/sources/DataSourceAltCloud.py (+0/-293)
cloudinit/sources/DataSourceAzure.py (+0/-651)
cloudinit/sources/DataSourceBigstep.py (+0/-57)
cloudinit/sources/DataSourceCloudSigma.py (+0/-141)
cloudinit/sources/DataSourceCloudStack.py (+0/-253)
cloudinit/sources/DataSourceConfigDrive.py (+0/-424)
cloudinit/sources/DataSourceDigitalOcean.py (+0/-110)
cloudinit/sources/DataSourceEc2.py (+0/-211)
cloudinit/sources/DataSourceGCE.py (+0/-167)
cloudinit/sources/DataSourceMAAS.py (+0/-353)
cloudinit/sources/DataSourceNoCloud.py (+0/-336)
cloudinit/sources/DataSourceNone.py (+0/-57)
cloudinit/sources/DataSourceOVF.py (+0/-429)
cloudinit/sources/DataSourceOpenNebula.py (+0/-455)
cloudinit/sources/DataSourceOpenStack.py (+0/-173)
cloudinit/sources/DataSourceSmartOS.py (+0/-536)
cloudinit/sources/__init__.py (+0/-337)
cloudinit/sources/helpers/__init__.py (+0/-13)
cloudinit/sources/helpers/azure.py (+0/-279)
cloudinit/sources/helpers/openstack.py (+0/-499)
cloudinit/sources/helpers/vmware/__init__.py (+0/-13)
cloudinit/sources/helpers/vmware/imc/__init__.py (+0/-13)
cloudinit/sources/helpers/vmware/imc/boot_proto.py (+0/-25)
cloudinit/sources/helpers/vmware/imc/config.py (+0/-95)
cloudinit/sources/helpers/vmware/imc/config_file.py (+0/-129)
cloudinit/sources/helpers/vmware/imc/config_namespace.py (+0/-25)
cloudinit/sources/helpers/vmware/imc/config_nic.py (+0/-247)
cloudinit/sources/helpers/vmware/imc/config_source.py (+0/-23)
cloudinit/sources/helpers/vmware/imc/guestcust_error.py (+0/-24)
cloudinit/sources/helpers/vmware/imc/guestcust_event.py (+0/-27)
cloudinit/sources/helpers/vmware/imc/guestcust_state.py (+0/-25)
cloudinit/sources/helpers/vmware/imc/guestcust_util.py (+0/-128)
cloudinit/sources/helpers/vmware/imc/ipv4_mode.py (+0/-45)
cloudinit/sources/helpers/vmware/imc/nic.py (+0/-147)
cloudinit/sources/helpers/vmware/imc/nic_base.py (+0/-154)
cloudinit/ssh_util.py (+0/-314)
cloudinit/stages.py (+0/-844)
cloudinit/templater.py (+0/-149)
cloudinit/type_utils.py (+0/-52)
cloudinit/url_helper.py (+0/-509)
cloudinit/user_data.py (+0/-352)
cloudinit/util.py (+0/-2226)
cloudinit/version.py (+0/-27)
config/cloud.cfg (+0/-115)
config/cloud.cfg-freebsd (+0/-88)
config/cloud.cfg.d/05_logging.cfg (+0/-66)
config/cloud.cfg.d/README (+0/-3)
doc/README (+0/-4)
doc/examples/cloud-config-add-apt-repos.txt (+0/-34)
doc/examples/cloud-config-archive-launch-index.txt (+0/-30)
doc/examples/cloud-config-archive.txt (+0/-16)
doc/examples/cloud-config-boot-cmds.txt (+0/-15)
doc/examples/cloud-config-ca-certs.txt (+0/-31)
doc/examples/cloud-config-chef-oneiric.txt (+0/-90)
doc/examples/cloud-config-chef.txt (+0/-95)
doc/examples/cloud-config-datasources.txt (+0/-73)
doc/examples/cloud-config-disk-setup.txt (+0/-251)
doc/examples/cloud-config-final-message.txt (+0/-7)
doc/examples/cloud-config-gluster.txt (+0/-18)
doc/examples/cloud-config-growpart.txt (+0/-31)
doc/examples/cloud-config-install-packages.txt (+0/-15)
doc/examples/cloud-config-landscape.txt (+0/-22)
doc/examples/cloud-config-launch-index.txt (+0/-23)
doc/examples/cloud-config-lxd.txt (+0/-55)
doc/examples/cloud-config-mcollective.txt (+0/-49)
doc/examples/cloud-config-mount-points.txt (+0/-46)
doc/examples/cloud-config-phone-home.txt (+0/-14)
doc/examples/cloud-config-power-state.txt (+0/-40)
doc/examples/cloud-config-puppet.txt (+0/-51)
doc/examples/cloud-config-reporting.txt (+0/-17)
doc/examples/cloud-config-resolv-conf.txt (+0/-20)
doc/examples/cloud-config-rh_subscription.txt (+0/-49)
doc/examples/cloud-config-rsyslog.txt (+0/-46)
doc/examples/cloud-config-run-cmds.txt (+0/-22)
doc/examples/cloud-config-salt-minion.txt (+0/-53)
doc/examples/cloud-config-seed-random.txt (+0/-32)
doc/examples/cloud-config-ssh-keys.txt (+0/-46)
doc/examples/cloud-config-update-apt.txt (+0/-7)
doc/examples/cloud-config-update-packages.txt (+0/-8)
doc/examples/cloud-config-user-groups.txt (+0/-109)
doc/examples/cloud-config-vendor-data.txt (+0/-16)
doc/examples/cloud-config-write-files.txt (+0/-33)
doc/examples/cloud-config-yum-repo.txt (+0/-20)
doc/examples/cloud-config.txt (+0/-645)
doc/examples/include-once.txt (+0/-7)
doc/examples/include.txt (+0/-5)
doc/examples/kernel-cmdline.txt (+0/-18)
doc/examples/part-handler-v2.txt (+0/-38)
doc/examples/part-handler.txt (+0/-23)
doc/examples/plain-ignored.txt (+0/-2)
doc/examples/seed/README (+0/-22)
doc/examples/seed/meta-data (+0/-30)
doc/examples/seed/user-data (+0/-3)
doc/examples/upstart-cloud-config.txt (+0/-12)
doc/examples/upstart-rclocal.txt (+0/-12)
doc/examples/user-script.txt (+0/-8)
doc/merging.rst (+0/-188)
doc/rtd/conf.py (+0/-77)
doc/rtd/index.rst (+0/-31)
doc/rtd/static/logo.svg (+0/-89)
doc/rtd/topics/availability.rst (+0/-20)
doc/rtd/topics/capabilities.rst (+0/-24)
doc/rtd/topics/datasources.rst (+0/-200)
doc/rtd/topics/dir_layout.rst (+0/-81)
doc/rtd/topics/examples.rst (+0/-133)
doc/rtd/topics/format.rst (+0/-159)
doc/rtd/topics/hacking.rst (+0/-1)
doc/rtd/topics/merging.rst (+0/-5)
doc/rtd/topics/modules.rst (+0/-342)
doc/rtd/topics/moreinfo.rst (+0/-12)
doc/sources/altcloud/README.rst (+0/-87)
doc/sources/azure/README.rst (+0/-134)
doc/sources/cloudsigma/README.rst (+0/-38)
doc/sources/cloudstack/README.rst (+0/-29)
doc/sources/configdrive/README.rst (+0/-123)
doc/sources/digitalocean/README.rst (+0/-21)
doc/sources/kernel-cmdline.txt (+0/-48)
doc/sources/nocloud/README.rst (+0/-71)
doc/sources/opennebula/README.rst (+0/-142)
doc/sources/openstack/README.rst (+0/-24)
doc/sources/ovf/README (+0/-83)
doc/sources/ovf/example/ovf-env.xml (+0/-46)
doc/sources/ovf/example/ubuntu-server.ovf (+0/-130)
doc/sources/ovf/make-iso (+0/-156)
doc/sources/ovf/ovf-env.xml.tmpl (+0/-28)
doc/sources/ovf/ovfdemo.pem (+0/-27)
doc/sources/ovf/user-data (+0/-7)
doc/sources/smartos/README.rst (+0/-149)
doc/status.txt (+0/-53)
doc/userdata.txt (+0/-79)
doc/var-lib-cloud.txt (+0/-63)
doc/vendordata.txt (+0/-53)
packages/bddeb (+0/-260)
packages/brpm (+0/-277)
packages/debian/changelog.in (+0/-6)
packages/debian/cloud-init.postinst (+0/-16)
packages/debian/cloud-init.preinst (+0/-20)
packages/debian/compat (+0/-1)
packages/debian/control.in (+0/-29)
packages/debian/copyright (+0/-29)
packages/debian/dirs (+0/-6)
packages/debian/rules.in (+0/-23)
packages/debian/watch (+0/-2)
packages/redhat/cloud-init.spec.in (+0/-200)
packages/suse/cloud-init.spec.in (+0/-163)
requirements.txt (+0/-36)
setup.py (+0/-215)
systemd/cloud-config.service (+0/-16)
systemd/cloud-config.target (+0/-11)
systemd/cloud-final.service (+0/-17)
systemd/cloud-init-generator (+0/-133)
systemd/cloud-init-local.service (+0/-22)
systemd/cloud-init.service (+0/-18)
systemd/cloud-init.target (+0/-6)
sysvinit/debian/cloud-config (+0/-64)
sysvinit/debian/cloud-final (+0/-66)
sysvinit/debian/cloud-init (+0/-64)
sysvinit/debian/cloud-init-local (+0/-63)
sysvinit/freebsd/cloudconfig (+0/-35)
sysvinit/freebsd/cloudfinal (+0/-35)
sysvinit/freebsd/cloudinit (+0/-35)
sysvinit/freebsd/cloudinitlocal (+0/-35)
sysvinit/gentoo/cloud-config (+0/-13)
sysvinit/gentoo/cloud-final (+0/-11)
sysvinit/gentoo/cloud-init (+0/-12)
sysvinit/gentoo/cloud-init-local (+0/-13)
sysvinit/redhat/cloud-config (+0/-121)
sysvinit/redhat/cloud-final (+0/-121)
sysvinit/redhat/cloud-init (+0/-121)
sysvinit/redhat/cloud-init-local (+0/-124)
templates/chef_client.rb.tmpl (+0/-58)
templates/hosts.debian.tmpl (+0/-26)
templates/hosts.freebsd.tmpl (+0/-24)
templates/hosts.redhat.tmpl (+0/-24)
templates/hosts.suse.tmpl (+0/-26)
templates/resolv.conf.tmpl (+0/-30)
templates/sources.list.debian.tmpl (+0/-32)
templates/sources.list.ubuntu.tmpl (+0/-58)
test-requirements.txt (+0/-17)
tests/configs/sample1.yaml (+0/-52)
tests/data/filter_cloud_multipart.yaml (+0/-30)
tests/data/filter_cloud_multipart_1.email (+0/-11)
tests/data/filter_cloud_multipart_2.email (+0/-39)
tests/data/filter_cloud_multipart_header.email (+0/-11)
tests/data/merge_sources/expected1.yaml (+0/-1)
tests/data/merge_sources/expected10.yaml (+0/-7)
tests/data/merge_sources/expected11.yaml (+0/-5)
tests/data/merge_sources/expected12.yaml (+0/-5)
tests/data/merge_sources/expected2.yaml (+0/-3)
tests/data/merge_sources/expected3.yaml (+0/-1)
tests/data/merge_sources/expected4.yaml (+0/-2)
tests/data/merge_sources/expected5.yaml (+0/-7)
tests/data/merge_sources/expected6.yaml (+0/-9)
tests/data/merge_sources/expected7.yaml (+0/-38)
tests/data/merge_sources/expected8.yaml (+0/-7)
tests/data/merge_sources/expected9.yaml (+0/-5)
tests/data/merge_sources/source1-1.yaml (+0/-3)
tests/data/merge_sources/source1-2.yaml (+0/-5)
tests/data/merge_sources/source10-1.yaml (+0/-6)
tests/data/merge_sources/source10-2.yaml (+0/-6)
tests/data/merge_sources/source11-1.yaml (+0/-5)
tests/data/merge_sources/source11-2.yaml (+0/-3)
tests/data/merge_sources/source11-3.yaml (+0/-3)
tests/data/merge_sources/source12-1.yaml (+0/-8)
tests/data/merge_sources/source12-2.yaml (+0/-5)
tests/data/merge_sources/source2-1.yaml (+0/-6)
tests/data/merge_sources/source2-2.yaml (+0/-5)
tests/data/merge_sources/source3-1.yaml (+0/-4)
tests/data/merge_sources/source3-2.yaml (+0/-4)
tests/data/merge_sources/source4-1.yaml (+0/-3)
tests/data/merge_sources/source4-2.yaml (+0/-6)
tests/data/merge_sources/source5-1.yaml (+0/-6)
tests/data/merge_sources/source5-2.yaml (+0/-8)
tests/data/merge_sources/source6-1.yaml (+0/-5)
tests/data/merge_sources/source6-2.yaml (+0/-8)
tests/data/merge_sources/source7-1.yaml (+0/-27)
tests/data/merge_sources/source7-2.yaml (+0/-17)
tests/data/merge_sources/source8-1.yaml (+0/-7)
tests/data/merge_sources/source8-2.yaml (+0/-6)
tests/data/merge_sources/source9-1.yaml (+0/-5)
tests/data/merge_sources/source9-2.yaml (+0/-6)
tests/data/mountinfo_precise_ext4.txt (+0/-24)
tests/data/mountinfo_raring_btrfs.txt (+0/-13)
tests/data/roots/simple_ubuntu/etc/networks/interfaces (+0/-3)
tests/data/user_data.1.txt (+0/-15)
tests/data/vmware/cust-dhcp-2nic.cfg (+0/-34)
tests/data/vmware/cust-static-2nic.cfg (+0/-39)
tests/unittests/helpers.py (+0/-346)
tests/unittests/test__init__.py (+0/-220)
tests/unittests/test_builtin_handlers.py (+0/-73)
tests/unittests/test_cli.py (+0/-54)
tests/unittests/test_cs_util.py (+0/-84)
tests/unittests/test_data.py (+0/-559)
tests/unittests/test_datasource/test_altcloud.py (+0/-452)
tests/unittests/test_datasource/test_azure.py (+0/-646)
tests/unittests/test_datasource/test_azure_helper.py (+0/-421)
tests/unittests/test_datasource/test_cloudsigma.py (+0/-99)
tests/unittests/test_datasource/test_cloudstack.py (+0/-87)
tests/unittests/test_datasource/test_configdrive.py (+0/-407)
tests/unittests/test_datasource/test_digitalocean.py (+0/-127)
tests/unittests/test_datasource/test_gce.py (+0/-166)
tests/unittests/test_datasource/test_maas.py (+0/-163)
tests/unittests/test_datasource/test_nocloud.py (+0/-187)
tests/unittests/test_datasource/test_opennebula.py (+0/-300)
tests/unittests/test_datasource/test_openstack.py (+0/-347)
tests/unittests/test_datasource/test_smartos.py (+0/-585)
tests/unittests/test_distros/test_generic.py (+0/-233)
tests/unittests/test_distros/test_hostname.py (+0/-38)
tests/unittests/test_distros/test_hosts.py (+0/-41)
tests/unittests/test_distros/test_netconfig.py (+0/-321)
tests/unittests/test_distros/test_resolv.py (+0/-67)
tests/unittests/test_distros/test_sysconfig.py (+0/-82)
tests/unittests/test_distros/test_user_data_normalize.py (+0/-297)
tests/unittests/test_ec2_util.py (+0/-139)
tests/unittests/test_filters/test_launch_index.py (+0/-132)
tests/unittests/test_handler/test_handler_apt_configure.py (+0/-109)
tests/unittests/test_handler/test_handler_ca_certs.py (+0/-271)
tests/unittests/test_handler/test_handler_chef.py (+0/-192)
tests/unittests/test_handler/test_handler_debug.py (+0/-81)
tests/unittests/test_handler/test_handler_disk_setup.py (+0/-30)
tests/unittests/test_handler/test_handler_growpart.py (+0/-220)
tests/unittests/test_handler/test_handler_locale.py (+0/-67)
tests/unittests/test_handler/test_handler_lxd.py (+0/-134)
tests/unittests/test_handler/test_handler_mounts.py (+0/-133)
tests/unittests/test_handler/test_handler_power_state.py (+0/-127)
tests/unittests/test_handler/test_handler_rsyslog.py (+0/-174)
tests/unittests/test_handler/test_handler_seed_random.py (+0/-227)
tests/unittests/test_handler/test_handler_set_hostname.py (+0/-72)
tests/unittests/test_handler/test_handler_snappy.py (+0/-306)
tests/unittests/test_handler/test_handler_timezone.py (+0/-76)
tests/unittests/test_handler/test_handler_write_files.py (+0/-112)
tests/unittests/test_handler/test_handler_yum_add_repo.py (+0/-68)
tests/unittests/test_helpers.py (+0/-33)
tests/unittests/test_merging.py (+0/-257)
tests/unittests/test_net.py (+0/-130)
tests/unittests/test_pathprefix2dict.py (+0/-44)
tests/unittests/test_registry.py (+0/-28)
tests/unittests/test_reporting.py (+0/-369)
tests/unittests/test_rh_subscription.py (+0/-214)
tests/unittests/test_runs/test_merge_run.py (+0/-54)
tests/unittests/test_runs/test_simple_run.py (+0/-81)
tests/unittests/test_sshutil.py (+0/-171)
tests/unittests/test_templating.py (+0/-119)
tests/unittests/test_util.py (+0/-489)
tests/unittests/test_vmware_config_file.py (+0/-103)
tools/21-cloudinit.conf (+0/-6)
tools/Z99-cloud-locale-test.sh (+0/-98)
tools/build-on-freebsd (+0/-66)
tools/ccfg-merge-debug (+0/-90)
tools/cloud-init-per (+0/-60)
tools/hacking.py (+0/-170)
tools/make-dist-tarball (+0/-21)
tools/make-mime.py (+0/-60)
tools/make-tarball (+0/-39)
tools/mock-meta.py (+0/-454)
tools/motd-hook (+0/-35)
tools/read-dependencies (+0/-29)
tools/read-version (+0/-26)
tools/run-pep8 (+0/-22)
tools/run-pyflakes (+0/-18)
tools/run-pyflakes3 (+0/-2)
tools/tox-venv (+0/-42)
tools/uncloud-init (+0/-141)
tools/validate-yaml.py (+0/-25)
tools/write-ssh-key-fingerprints (+0/-38)
tox.ini (+0/-35)
udev/66-azure-ephemeral.rules (+0/-18)
udev/79-cloud-init-net-wait.rules (+0/-10)
udev/cloud-init-wait (+0/-70)
upstart/cloud-config.conf (+0/-9)
upstart/cloud-final.conf (+0/-10)
upstart/cloud-init-blocknet.conf (+0/-83)
upstart/cloud-init-container.conf (+0/-57)
upstart/cloud-init-local.conf (+0/-16)
upstart/cloud-init-nonet.conf (+0/-66)
upstart/cloud-init.conf (+0/-9)
upstart/cloud-log-shutdown.conf (+0/-19)

Superseded for merging into lp:~d-jj/cloud-init/chef-12-updates

JJ Asghar: Pending requested 2015-03-03

Merged into lp:~jbauer/cloud-init/salt at revision 561

Scott Moser: Pending requested 2012-05-08

lp:ubuntu/quantal/cloud-init

lp:~smoser/maas/trunk.maas-signal-clockskew

Merged into lp:~maas-committers/maas/trunk at revision 1242

Robie Basak (community): Approve on 2012-10-09

lp:~smoser/ubuntu/precise/cloud-init/sru

lp:ubuntu/precise-proposed/cloud-init

Revision history for this message

Scott Moser (smoser) wrote on 2012-04-10:

screenshot of system Edit (3.4 MiB, image/jpeg)

Revision history for this message

Julian Edwards (julian-edwards) wrote on 2012-04-11:

Urgh this is nasty. We'd need to provide an NTP service on the network, right? Otherwise, can MAAS send an on the spot timestamp to the node to do a rough-and-ready initialisation of its clock? Won't be accurate but will be good enough to get past the oauth nonce check.

Changed in maas:
status:	Confirmed → Triaged
importance:	Undecided → High

Julian Edwards (julian-edwards) on 2012-04-18

tags:

added: api provisioning

Revision history for this message

Scott Moser (smoser) wrote on 2012-05-04:

so we just hit this, and it sucked.
I worked around by, in the ephemeral image, modifying /etc/init/cloud-init.conf to append:
  pre-start script
  ntpdate -p 8 10.155.32.1
  hwclock -w
  end script

Revision history for this message

Jeff Anderson-Lee (jonah-2) wrote on 2012-06-26:

This is really problematic. New nodes do not come with synchronized clocks.
And client nodes may not be on a public facing network interface (at least not at boot time).

What about changing the configuration of the MAAS master to automatically run a time service
and have the client nodes set their clocks from it (+1 for #2)?

Failing that, allow the tickets or whatever timestamped credential is being passed to be valid
for +/-24 hours? I like this less than having the clock set accurately at boot, since if you got a
batch of 100+ nodes with ill-set clocks, it would be *way* to much manual labor to set in in the bios.

This bug nearly had me willing to walk away from MAAS as DOA.

Revision history for this message

Jeff Anderson-Lee (jonah-2) wrote on 2012-06-26:

Thanks for the work around Scott. I installed ntp on the MAAS-server and tweaked the ephemeral image to use ntpdate from it:

apt-get -q -y install ntpdate
ntpdate -p 8 SOME.PUBLIC.SERVER
apt-get -q -y install ntp ntp-doc

IFACE=eth1
IPADDR=`ifconfig eth1| grep 'inet addr'| sed -e 's/.*addr://' -e 's/ .*//'`
export IPADDR
# The tweak the ephemeral image to set the clock
mount /var/lib/maas/ephemeral/precise/ephemeral/amd64/20120424/disk.img /mnt/
chroot /mnt
apt-get update
cat >> /etc/init/cloud-init.conf << END

pre-start script
ntpdate -p 8 ${IPADDR}
hwclock -w
end script
END
exit
umount /mnt

# after that, the nodes boot and configure!

Revision history for this message

Julian Edwards (julian-edwards) wrote on 2012-06-27:

Jeff, we'll address this pretty soon. It's been a pain point for a lot of people.

Revision history for this message

Gui Maluf Balzana (guimalufb) wrote on 2012-07-13:

Thanks Jeff. Your solution works great!

Revision history for this message

Julian Edwards (julian-edwards) wrote on 2012-07-16:

Via Scott:

I think a reasonable and SRU-able solution is below. Note, that in order
to deliver this, we have to deliver updated ephemeral images (which was
always expected, just pointing out that this fix comes in a ~600M
download).

The way this works right now is the following:
A. ephemeral instance is booted with a 'url=' parameter on the kernel
   command line something like this:
      url=http://maasserver/cblr/svc/op/ks/system/node-XXXX
B. as described at [1], cloud-init pulls that un-authed url, and stores it
   as local configuration. Currently the payload looks like this:
      #cloud-config
      datasource:
       MAAS:
         metadata_url: http://mass-host.localdomain/source
         consumer_key: Xh234sdkljf
         token_key: kjfhgb3n
         token_secret: 24uysdfx1w4
C. cloud-init then continues on and uses that maas datasource as if it
    were locally configured to do so. It pulls user-data from
    the derivative url, and then executes it.
D. The user-data provided is read from
    /etc/maas/commissioning-user-data [2]. cloud-init executes this code
    which makes api calls back to the configured maas server in 'B' to
    post commissioning status.

The issue that we see in bug 978127 is that the http requests done in 'C'
fail because of out of sync clock on the ephemeral node.

The solution that I suggest is:
i.) modify 'B' above to include 'time_sync_url' field under 'MAAS'
ii.) Before cloud-init does oauthed requests for user-data in 'C'
    above, it will first do an un-authed request to the value of
    'time_sync_url' which will return data like:
      Wed, 27 Jun 2012 10:13:29 -0400
iii.) cloud-init will then set the system clock (not the hardware clock)
    to the given date. The subsequent oauth requests will succeed as
    they'll have a reasonable system clock at that point.
iv.) if possible make cloud-init log the failure in 'C' above more
      obviously on the console. I believe this is less than
      straightforward unfortunately due to the console switching around
      that is done on boot.

Note, I skipping the 'time_sync_url' by simply directly providing a
'time_sync' like:
time_sync: Wed, 27 Jun 2012 10:13:29 -0400
If that is seen as desirable it could probably be accommodated. The thing
that I do not like about it is that it writes that data to a local config
file, and obviously the current time stamp very quickly becomes incorrect.
Hiding it behind a url that has dynamic and correct content removes that.

Via Scott:

I think a reasonable and SRU-able solution is below.  Note, that in order
to deliver this, we have to deliver updated ephemeral images (which was
always expected, just pointing out that this fix comes in a ~600M
download).

The way this works right now is the following:
 A. ephemeral instance is booted with a 'url=' parameter on the kernel
   command line something like this:
      url=http://maasserver/cblr/svc/op/ks/system/node-XXXX
 B. as described at [1], cloud-init pulls that un-authed url, and stores it
   as local configuration.  Currently the payload looks like this:
      #cloud-config
      datasource:
       MAAS:
         metadata_url: http://mass-host.localdomain/source
         consumer_key: Xh234sdkljf
         token_key: kjfhgb3n
         token_secret: 24uysdfx1w4
 C. cloud-init then continues on and uses that maas datasource as if it
    were locally configured to do so.  It pulls user-data from
    the derivative url, and then executes it.
 D. The user-data provided is read from
    /etc/maas/commissioning-user-data [2].  cloud-init executes this code
    which makes api calls back to the configured maas server in 'B' to
    post commissioning status.

The issue that we see in bug 978127 is that the http requests done in 'C'
fail because of out of sync clock on the ephemeral node.

The solution that I suggest is:
 i.) modify 'B' above to include 'time_sync_url' field under 'MAAS'
 ii.) Before cloud-init does oauthed requests for user-data in 'C'
    above, it will first do an un-authed request to the value of
    'time_sync_url' which will return data like:
      Wed, 27 Jun 2012 10:13:29 -0400
 iii.) cloud-init will then set the system clock (not the hardware clock)
    to the given date. The subsequent oauth requests will succeed as
    they'll have a reasonable system clock at that point.
 iv.) if possible make cloud-init log the failure in 'C' above more
      obviously on the console.  I believe this is less than
      straightforward unfortunately due to the console switching around
      that is done on boot.

Note, I skipping the 'time_sync_url' by simply directly providing a
'time_sync' like:
  time_sync: Wed, 27 Jun 2012 10:13:29 -0400
If that is seen as desirable it could probably be accommodated.  The thing
that I do not like about it is that it writes that data to a local config
file, and obviously the current time stamp very quickly becomes incorrect.
Hiding it behind a url that has dynamic and correct content removes that.

Revision history for this message

Julian Edwards (julian-edwards) wrote on 2012-07-16:

I see a couple of potential problems with the first approach:

* There may not be a time-sync url (ntp service) available
* Unless you're talking about adding an API call to MAAS? This obviously adds more complexity to the SRU.

The key thing is that the node clocks need to be "near enough" to the MAAS server's clock for oauth to work. We could just put the time right in the config payload but I guess that depends on whether having a more accurate clock time available for other purposes is desirable or not? If not, we can just make the config payload item be called "oauth_time_sync" instead so it's a bit more obvious what it's used for (and would discourage other use).

Revision history for this message

Scott Moser (smoser) wrote on 2012-07-17:

#10

I was suggesting the "api" call to maas. That makes sense to me, as the maas clock is actually the "right" clock (if maas server was out of date, syncing against anything else is just going to cause other confusion).

I dont' like putting the 'oauth_time_sync' in the config payload as that is stored locally in cloud-init as regular config. In the ephemeral image, every boot is "first boot" (as there is no way of storing a already-booted). Having a hard coded static time in a config file seems broken. I'd rather it point to a reference where a dynamic time can be obtained.

The api call in maas can be as simple as:
print time.time()

If this is the right solution, then its the right path to SRU. Cobbling a solution that is different than what is done in trunk so it is more appropriate for SRU doesn't seem like a good idea. We should focus first on fixing trunk the right way.

Revision history for this message

Julian Edwards (julian-edwards) wrote on 2012-07-18:

#11

I have no intention of doing a different fix in trunk vs 1.0, don't worry. This discussion is about the pros and cons of each approach. I think we've settled on a reasonable one now, so I'll get this API call in place ready for when the change is added to cloud-init.

Revision history for this message

Scott Moser (smoser) wrote on 2012-07-31:

#12

I did some more thinking on this, and I think the easiest solution is to set the hardware clock during enlistment.
The good thing about this is that we're already executing arbitrary code (via early_command) during enlistment and preseed for enlistment is not oauth protected.

There is still the possibility for failure in one of the following cases:
a.) really bad hardware clock or dead bios battery. Ie, the clock loses minutes in a day or completely loses time across reboot/power cycle. This means that between enlistment and commissioning, the system could get a bad clock and fail oauth for commissioning.
b.) virtual machine. I think that setting the hwclock is basically a no-op in a virtual machine, and is not likely persistent across shutdown/startup. For virtual machine's the host clock is just going to have to be relied upon across shutdown.

Note, however, that the suggestion given above (setting prior to use of the api during commissioning) could also fail in either of the above cases between commissioning and installation. The only complete fix would then be to have each stage somehow be provided via unauthed access a good timestamp and set the system clock via that.

At very least, I think we should take this path now, as it really should be really easy, and generally cut out issues with incorrectly set "real hardware" clocks.

Revision history for this message

Andrew Glen-Young (aglenyoung) wrote on 2012-07-31:

#13

The HTTP/1.1 RFC dictates that an origin server MUST include a valid Date field for it's responses¹. Could this field not be used?

Example HTTP/1.1 request/response (truncated for brevity):

GET /maas/+bug/978127 HTTP/1.1
Host: bugs.launchpad.net

HTTP/1.1 200 Ok
Date: Tue, 31 Jul 2012 15:48:51 GMT

[1]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.18

dann frazier (dannf) on 2012-08-16

Changed in lomond:
status:	New → Triaged

Revision history for this message

Robie Basak (racb) wrote on 2012-08-20:

#14

Some further discussion here: https://lists.launchpad.net/maas-devel/msg00335.html

Robie Basak (racb) on 2012-09-17

tags:

added: arm

Scott Moser (smoser) on 2012-09-24

Changed in cloud-init:
status:	New → In Progress
importance:	Undecided → Medium
assignee:	nobody → Scott Moser (smoser)

Revision history for this message

Scott Moser (smoser) wrote on 2012-09-24:

#15

I just committed a fix to trunk that I believe should address this.
Its based on the suggestion in comment 13.

Basically, if we fail by 403 unauthorized, we set a "skew" (skew = local_current_time - server_response_time) and future requests will have the oauth header time adjusted by that skew.

Scott Moser (smoser) on 2012-09-24

Changed in cloud-init (Ubuntu):
status:	New → Triaged
importance:	Undecided → High

Revision history for this message

Launchpad Janitor (janitor) wrote on 2012-10-01:

#16

This bug was fixed in the package cloud-init - 0.7.0~bzr677-0ubuntu1

---------------
cloud-init (0.7.0~bzr677-0ubuntu1) quantal; urgency=low

  * add CloudStack to DataSources listed by dpkg-reconfigure (LP: #1002155)
  * New upstream snapshot.
    * 0440 permissions on /etc/sudoers.d files rather than 0644
    * get host ssh keys to the console (LP: #1055688)
    * MAAS DataSource adjust timestamp in oauth header to one based on the
      timestamp in the response of a 403. This accounts for a bad local
      clock. (LP: #978127)
    * re-start the salt daemon rather than start to ensure config changes
      are taken.
    * allow for python unicode types in yaml that is loaded.
    * cleanup in how config modules get at users and groups.
-- Scott Moser <email address hidden> Sun, 30 Sep 2012 14:29:04 -0400

Changed in cloud-init (Ubuntu):
status:	Triaged → Fix Released

Scott Moser (smoser) on 2012-10-01

Changed in cloud-init:
status:	In Progress → Fix Released

mahmoh (mahmoh) on 2012-10-01

Changed in lomond:
status:	Triaged → Fix Released

Francis J. Lacoste (flacoste) on 2012-10-04

Changed in maas:
status:	Triaged → Fix Committed

Julian Edwards (julian-edwards) on 2012-10-05

Changed in maas:
status:	Fix Committed → Fix Released

Scott Moser (smoser) on 2012-10-05

Changed in cloud-init (Ubuntu Precise):
status:	New → Triaged
importance:	Undecided → High

Revision history for this message

Robie Basak (racb) wrote on 2012-10-09:

#17

This seems to be fixed in cloud-init based on the latest daily ephemeral image. However, it seems that maas-signal (embedded in etc/maas/commissioning-user-data) also has the same problem. Bumping this to Critical, as it means that it is very difficult for highbank users to deploy at all, since they don't necessarily know how to set their hardware clock.

Changed in maas:
status:	Fix Released → Triaged
importance:	High → Critical
assignee:	nobody → Scott Moser (smoser)

Francis J. Lacoste (flacoste) on 2012-10-09

Changed in maas:
status:	Triaged → In Progress
tags:	added: missing-in-quantal

Francis J. Lacoste (flacoste) on 2012-10-09

no longer affects:	maas (Ubuntu)
no longer affects:	maas (Ubuntu Precise)

MAAS Lander (maas-lander) on 2012-10-09

Changed in maas:
status:	In Progress → Fix Committed

Francis J. Lacoste (flacoste) on 2012-10-10

Changed in maas:
status:	Fix Committed → Fix Released

Revision history for this message

Ryan Finnie (fo0bar) wrote on 2012-10-17:

#18

I just encountered this in precise MAAS, on brand new metal nodes which had dates sometime in 2011. Adding the NTP hack to the ephemeral image helped get around it. (Thanks for the recipe, Jeff! FYI, a public NTP server can work just as well, ntp.ubuntu.com in my case.)

Scott Moser: "Basically, if we fail by 403 unauthorized, we set a "skew" (skew = local_current_time - server_response_time) and future requests will have the oauth header time adjusted by that skew."

Here's the problem though. From what I saw, the MAAS server was returning 401 because of the skewed oauth, not 403. I can provide tcpdump captures if desired.

Revision history for this message

Scott Moser (smoser) wrote on 2012-10-17:

#19

There are 2 pieces to this fix, both of which are fixed in 12.10.
a.) cloud-init portion. This fix is in the latest set of precise "released" ephemeral images. They include cloud-init from 12.10. It accounts for 401 or 403 return.
b.) "maas-signal" portion. maas-signal is used during commissioning, and it reports commissioning results back. maas-signal is part of maas (/etc/maas/commissioning-user-data). This was fixed in revision 1242 [1].

The behavior that I would expect in 12.04 with broken hardware clocks at this point is for enlistment to work, commissioning to get user-data, but then to failto report home as done. I think for 12.04 I would recommend the modification of the ephemeral image to include the running of 'ntp-date' as described in comment 5.

--
[1] http://bazaar.launchpad.net/~maas-maintainers/maas/trunk/revision/1242

Scott Moser (smoser) on 2012-11-08

tags:

removed: missing-in-quantal

Scott Moser (smoser) on 2012-11-08

description:

updated

Revision history for this message

Steve Langasek (vorlon) wrote on 2012-12-10: Please test proposed package

#20

Hello Scott, or anyone else affected,

Accepted cloud-init into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/cloud-init/0.6.3-0ubuntu1.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in cloud-init (Ubuntu Precise):
status:	Triaged → Fix Committed
tags:	added: verification-needed

Revision history for this message

Scott Moser (smoser) wrote on 2012-12-12:

#21

modify-ephemeral image script Edit (571 bytes, text/plain)

I've verified this by setting up maas, then:

bzr branch lp:~smoser/+junk/backdoor-image
cd backdoor-image
img=/var/lib/maas/ephemeral/precise/ephemeral/amd64/20121008/disk.img
sudo ./mount-callback-umount --system-resolvconf -v $img -- \
sh -c 'chroot "$1" /bin/sh' -- < ~/bin/modify-image

sudo ./backdoor-image --password=ubuntu $

where modify-image is attached patch.

Then started a machine (kvm) and watched it boot. It successfully enlisted. This is actually normal.
Then, accept the node, and boot again

The node successfully commissions, and shows:
2012-12-12 20:36:35,682 - util.py[WARNING]: 'http://10.55.60.142/MAAS/metadata//2012-03-01/meta-data/instance-id' failed [0/120s]: http error [401]
2012-12-12 20:36:35,690 - DataSourceMAAS.py[WARNING]: set oauth clockskew to 602

in the /var/log/cloud-init.log, indicating that the fix was applied.

tags:

added: verification-done
removed: verification-needed

Revision history for this message

Clint Byrum (clint-fewbar) wrote on 2013-01-08:

#22

Hello Scott, or anyone else affected,

Accepted cloud-init into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/cloud-init/0.6.3-0ubuntu1.3 in a few hours, and then in the -proposed repository.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

tags:	removed: verification-done
tags:	added: verification-needed

Scott Moser (smoser) on 2013-01-08

tags:

added: verification-done
removed: verification-needed

Revision history for this message

Colin Watson (cjwatson) wrote on 2013-01-16: Update Released

#23

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2013-01-16:

#24

This bug was fixed in the package cloud-init - 0.6.3-0ubuntu1.3

---------------
cloud-init (0.6.3-0ubuntu1.3) precise-proposed; urgency=low

  * debian/patches/lp-1070345-landscape-restart-after-change.patch,
    debian/patches/lp-1066115-landscape-install-fix-perms.patch:
    fix missing or incorrect imports (LP: #1070345, LP: #1066115).

cloud-init (0.6.3-0ubuntu1.2) precise-proposed; urgency=low

  * debian/patches/lp-978127-maas-oauth-fix-bad-clock.patch: fix usage of
    oauth in maas data source if local system has a bad clock (LP: #978127)
  * debian/cloud-init.preinst: fix bug where user data scripts re-ran on
    upgrade from 10.04 versions (LP: #1049146)
  * debian/patches/lp-974509-detect-dns-server-redirection.patch: detect dns
    server redirection and disable searching dns for a mirror named
    'ubuntu-mirror' (LP: #974509)
  * debian/patches/lp-1018554-shutdown-message-to-console.patch: write a
    message to the console on system shutdown. (LP: #1018554)
  * debian/patches/lp-1066115-landscape-install-fix-perms.patch: install
    landscape package if needed which will ensure proper permissions on config
    file (LP: #1066115).
  * debian/patches/lp-1070345-landscape-restart-after-change.patch: restart
    landscape after modifying config (LP: #1070345)
  * debian/patches/lp-1073077-zsh-workaround-for-locale_warn.patch: avoid
    warning when user's shell is zsh (LP: #1073077)
  * debian/patches/rework-mirror-selection.patch: improve mirror selection by:
    * allowing region/availability-zone to be part of mirror (LP: #1037727)
    * making mirror selection arch aware (LP: #1028501)
    * allow specification of a security mirror (LP: #1006963)
-- Scott Moser <email address hidden> Thu, 13 Dec 2012 12:16:56 -0500