Age | Commit message (Collapse) | Author |
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
|
|
LP: #915282
|
|
|
|
on EC2, you can:
stop instance
resize root volume
start instance
Currently, the partition would get grown correctly in the initramfs, but
the root filesystem will not get automatically resized in that case as it
only runs per_instance.
This should not be harmfull in any case, as resizefs will just report
nothing to do:
$ sudo resize2fs /dev/sda5
resize2fs 1.42-WIP (16-Oct-2011)
The filesystem is already 25600278 blocks long. Nothing to do!
|
|
|
|
This adds the ability to configure landscape client code from
cloud-config. The fields available are those that were populated to
/etc/landscape/client.conf when I ran landscape-config on precise
('11.07.1.1-0ubuntu2')
|
|
|
|
Currently cloud-init writes something like this to console output:
ec2: #############################################################
ec2: -----BEGIN SSH HOST KEY FINGERPRINTS-----
ec2: 2048 78:ae:f3:91:04:6f:8d:ee:ef:e1:2d:72:83:6a:d0:82 root@h (RSA)
ec2: 1024 d3:b6:32:64:22:d4:43:05:f9:25:b4:f3:65:4e:e2:51 root@h (DSA)
ec2: -----END SSH HOST KEY FINGERPRINTS-----
ec2: #############################################################
the key fingerprints are useful for humans to read, but not so useful
for machines, as you cannot populate a KnownHostsFile (~/.ssh/known_hosts)
from the data there.
This change adds output like:
-----BEGIN SSH HOST KEY KEYS-----
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdH......STI= root@h
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDYRIQe6m......tWF3 root@h
-----END SSH HOST KEY KEYS-----
Those lines can easily be grabbed and appended to a known_hosts file.
|
|
The default management of /etc/hosts in 0.6.2 (Ubuntu 11.10)
was problematic for a couple different uses, and represented a change
in what was present in previous releases.
This changes the default behavior back to the way it was in 11.04/0.6.1.
It makes 'manage_etc_hosts' in cloud-config more than just a boolean.
It can now have 3 values:
* False (default): do not update /etc/hosts ever
* "localhost": manage /etc/hosts' 127.0.1.1 entry (the way it was done
in 11.10/0.6.2)
* True (or "template"): manage /etc/hosts via template file
This addresses bugs
* LP: #890501
* LP: #871966
|
|
|
|
|
|
instead of only searching ubuntu.localdomain, search
<distro>-mirror.localdomain
|
|
if apt_mirror was set to "" or False in the config,
we would have used that.
|
|
|
|
|
|
|
|
input like:
mounts:
- [ ephemeral0, /opt , auto, "defaults,noexec" ]
- [ swap, null ]
would get interpreted as string "None" rather than "None" and
an entry for swap would be written to fstab.
LP: #898365
|
|
Fedora's ssh service name is named 'sshd', Ubuntu's
is 'ssh'. This makes that configurable.
TODO: document ssh_svcname.
taken from
git://pkgs.fedoraproject.org/cloud-init.git
commit 87f33190f43d2b26cced4597e7298835024466c2
Author: Garrett Holmstrom <gholms@fedoraproject.org>
Patch11: cloud-init-0.6.2-sshsvc.patch
|
|
Garret's patch cloud-init-0.6.2-sshsvc.patch did 2 separate
things. This hunk makes deletion of keys configurable, and
then makes generation of the keys only done if the key
does not exist.
TODO: document ssh_genkeytypes.
taken from
git://pkgs.fedoraproject.org/cloud-init.git
commit 87f33190f43d2b26cced4597e7298835024466c2
Author: Garrett Holmstrom <gholms@fedoraproject.org>
Patch11: cloud-init-0.6.2-sshsvc.patch
|
|
Notes:
* This also makes cc_ssh.py *not* write ssh keys to the console.
That means that if keys-to-console is configured off, nothing will
write the keys to the console.
* I removed Garret's use of xargs, replacing with a shell for loop
in write-ssh-key-fingerprints.
taken from
git://pkgs.fedoraproject.org/cloud-init.git
commit 87f33190f43d2b26cced4597e7298835024466c2
Author: Garrett Holmstrom <gholms@fedoraproject.org>
Patch8: cloud-init-0.6.2-sshkeytypes.patch
|
|
|
|
configure puppet service to start on fedora based on one of:
* presence of /etc/default/puppet (Ubuntu)
* /bin/systemctl
* /sbin/chkconfig
taken from
git://pkgs.fedoraproject.org/cloud-init.git
commit 87f33190f43d2b26cced4597e7298835024466c2
Author: Garrett Holmstrom <gholms@fedoraproject.org>
Patch7: cloud-init-0.6.2-puppetenable.patch
|
|
If the file /etc/sysconfig/clock exists, assume fedora style
timezone config and write 'ZONE="%s' to that file.
taken from
git://pkgs.fedoraproject.org/cloud-init.git
commit 87f33190f43d2b26cced4597e7298835024466c2
Author: Garrett Holmstrom <gholms@fedoraproject.org>
Patch5: cloud-init-0.6.2-tzsysconfig.patch
|
|
fedora's analog to /etc/default/locale is /etc/sysconfig/i18n .
This makes locale_configfile configurable and chooses between
/usr/sbin/locale-gen (ubuntu/debian) and
/usr/sbin/update-localeo (fedora)
based on availability to generate locales.
taken from
git://pkgs.fedoraproject.org/cloud-init.git
commit 87f33190f43d2b26cced4597e7298835024466c2
Author: Garrett Holmstrom <gholms@fedoraproject.org>
Patch4: cloud-init-0.6.2-localefile.patch
|
|
This adds a restorecon_if_possible method which uses selinux
python module, and uses that for files modified in /etc.
taken from
git://pkgs.fedoraproject.org/cloud-init.git
commit 87f33190f43d2b26cced4597e7298835024466c2
Author: Garrett Holmstrom <gholms@fedoraproject.org>
Patch3: cloud-init-0.6.2-filecontext.patch
|
|
Previously, there was a 'ruby_packages' dictionary that mapped the
ruby version (1.8, 1.9, 1.9.1) to a list of packages that would need
to be installed to get a functional gems.
This replaces that with a method that is more likely to support future
versions without requiring updates to cloud-init.
It is not identical output as before. The changes are:
* do not include 'ruby' in the case of 1.8, but rather 'ruby1.8'
This is because the default could change, and 'ruby' would depend
on a different default version.
* do not explicitly list 'libruby-<version>' as that is a dependenency
of 'ruby<version>'
* End result is for any 'version' != 1.8, you'll get the following installed
ruby<version>
ruby<version>-dev
LP: #848932
|
|
lp:~avishai-ish-shalom/cloud-init/chef
Bringing in 'initial_properties' support from lp:~avishai-ish-shalom/cloud-init/chef
|
|
Support both 'validation_cert' and 'validation_key' for backwards compatibility
Cleaned up line length
|
|
Added support for 'node_name' and 'environment' properties.
Renamed 'validation_cert' to 'validation_key' to match Chef's nomenclature.
|
|
|
|
|
|
LP: #845161
|
|
validation cert name
|
|
LP: #832175
|
|
These changes update the .ssh/authorized_keys rather than simply appending
This is preferable as ssh daemon picks the first key that is present.
This fixes 2 issues where something had edited a .ssh/authorized_keys
prior to cloud-init getting at it.
a.) LP: #434076 a user prior to re-bundling
b.) LP: #833499 the hypervisor
If you want to enable ssh access for root user, the proper way to do it is
with 'disable_root: False' in cloud-config.
LP: #434076, #833499
|
|
Fix issue where 'isatty' would return true for apt-add-repository.
It would get stdin which was attached to a terminal (/dev/console) and would
thus hang when running during boot.
This was done by changing all users of util.subp to have None input unless
input was given. In that case, the input will be the string passed in.
LP: #831505
|
|
|
|
add-apt-repository (LP #831505)
|
|
|
|
For better or worse, 'manage_etc_hosts' means
"write /etc/hosts from the template"
The default setting is 'False', which was not to update
/etc/hosts at all. Now, we're updating /etc/hosts, claiming
the 127.0.1.1 entry as owned by cloud-init if manage_etc_hosts is
false.
|
|
|
|
This adds a method 'get_hostname_fqdn' to cloudinit.util, and then
uses this method for getting the hostname and fqdn in places that get
hostname.
The single place for getting it right will help.
|
|
This fixes a couple issues with the updating of /etc/hosts
by the update-etc-hosts cloud-config module.
* if hostname changed in the life of the instance, an additional
"header" line would be added.
* any comment lines like '#mycomment' would be deleted because
they did not have 2 fields
|
|
consume_userdata should really run always, rather than once per instance.
The documentation says that boothooks were on their own for per-instance
but since this routine was only being called once, they would only get
called once.
This modifies the behavior to be:
user_script: per_always
cloud_config : per_always
upstart_job : per_instance
cloud_boothook: per_always
In order to not break part handlers that are existing, and expect to only be
called once per instance, this adds a 'handler_version' item in a handler
that can indicate the version (currently 1 or 2). If it is 2, then the
hander will be passed the frequency (per-instance or per-always) that this
is being run. That way the handler can differenciate between them.
This also makes 'bootcmd' run every boot. That should be changable in
cloud-config though, so users who dont like the behavior can modify it.
LP: #819507
|
|
|
|
|
|
|
|
|
|
Thanks to Adam Gandalman and Marc Cluet for this fix.
LP: #812539
|
|
it is expected / understood that mknod would fail inside an lxc container.
So, if thats the case, just log a debug message saying so.
LP: #800856
|