| Age | Commit message (Collapse) | Author |
|---|
|
instead of spaces)
From: Juerg Haefliger <juerg.haefliger@hp.com>
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
|
|
the cloud-init programs are never intended to run interactively.
Some programs were being run via subprocess, and would notice that their
input was attached to a terminal (/dev/console). As a result, they
they would try to prompt the user for input (apt-add-repository)
This change simply re-opens standard input as /dev/null so any
subprocesses will not end up blocking on input.
|
|
|
|
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
|
|
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
|
|
Per bug 857926, on some systems, run-parts will exit failure
if the directory is empty. On debian/ubuntu, at least of recent vintage,
it exits success. Its reasonable to just not run it.
LP: #857926
|
|
|
|
read_seeded also takes a 'file_retry' which defaults to zero.
This is so that if the seed path is a file, retries are not done.
read_optional_seed is not passing 'retries=0' here, but
all the users of read_optional_seed are using it from file.
|
|
This fixes (LP: #850206). See bug for more info.
LP: #850206
|
|
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
|
|
|
|
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.
|
|
In the case where a seedfrom value was given on the command line or in the
config file, we were timing out in 2 seconds on the connection. That timeout
was put in place to support "probing" for sources, but seedfrom is explictly
given.
So, in that case, do a urllib.open without a timeout value. Looking at source
code, default timeout is 'socket._GLOBAL_DEFAULT_TIMEOUT', but rather than
importing that and using it, I will call without a timeout value.
LP: #812646
|
|
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
|
|
If user input is a consumed as a user-script, a boothook, or a upstart
job and appears to be dos-formated, then change it to unix formated
LP: #744965
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
LP: #668400
|
|
This moves what was done as cloud-run-user-script.conf to 'cloud-final'
and makes that re-use the cloud-init-cfg code, but simply with a different
set of default configs.
Also, adds keys_to_console and final_message cloud-config modules
LP: #653271
|
|
add caching of the parsed config, this will allow re-use in cloudinit
so that we don't have to load the default config more than once in
a program.
|
|
LP: #704509
|
|
sources can use $MIRROR and $RELEASE and they will be replaced
with the local mirror for this cloud, and the running release
this:
- source: deb $MIRROR $RELEASE multiverse
would possibly be turned into:
- source: deb http://us-east-1.ec2.archive.ubuntu.com/ubuntu natty multiverse
LP: #693292
|
|
|
|
This allows the user to specify portions of the cloud-config
system config on the kernel command line. values found on the
kernel command line have preference over those in system config.
The format is:
cc:[ ]<yaml content here> [end_cc]
Where:
'cc:' indicates the beginning of cloud config syntax
[ ] optionally followed by whitespace (which will be trimmed)
<yaml content here> :
this content is passed untouched to yaml
end_cc:
this is optional. If no 'end_cc' tag is found, all data from
the begin tag to the end of the command line is consumed
Multiple occurences of the cc:<data>end_cc will be joined with
carriage return before passing to yaml.
Any litteral '\n' (backslash followed by lower case 'n') are converted
to a carriage return.
The following are examples:
cc: ssh_import_id: [smoser, kirkland]
cc: ssh_import_id: [smoser, bob]\\nruncmd: [ [ ls, -l ], echo hi ] end_cc
cc:ssh_import_id: [smoser] end_cc cc:runcmd: [ [ ls, -l ] ] end_cc
|
|
This set of changes makes '/etc/cloud/cloud.cfg' support "#include"
and "#opt_include". The idea is to then provide a base configuration
and allow distro or local changes that would override that.
|
|
Previously,
apt_sources:
- source: source1
- source: source2
resulted in source1 being written to
/etc/apt/sources.list.d/cloud_config_sources.list , and then
that being overwritten by source2.
This definitely is not expected.
Instead, in all cases now, (including 'filename:' cases), just append.
LP: #627597
|
|
|
|
if 'base' input to reed_seeded contains a "%s", then substitute
'user-data' and 'meta-data' at that location rather than at the end.
Ie:
- base="http://foo.bar/"
userdata_url = http://foo.bar/user-data
metadata_url = http://foo.bar/meta-data
- base="http://foo.bar/%s?user=smoser"
userdata_url = http://foo.bar/user-data&user=smoser"
metadata_url = http://foo.bar/meta-data&user=smoser"
|
|
read_optional_seed should return true or false based on whether or not
the seed existed. It is useful to easily say read this if its there,
but it might not be.
|
|
The new classes 'DataSourceNoCloud' and 'DataSourceNoCloudNet'
implement a way to get data from the filesystem, or (very minimal)
data from the kernel command line. This allows the user to seed data to
these sources.
There are now 2 "cloud-init" jobs, cloud-init-local that runs on
mounted MOUNTPOINT=/
and 'cloud-init' that runs on
start on (mounted MOUNTPOINT=/ and net-device-up IFACE=eth0 and
stopped cloud-init-local )
The idea is that cloud-init-local can actually function without network.
The last thing in this commit is "uncloud-init".
This tool can be invoked as 'init=/usr/lib/cloud-init/uncloud-init'
It will "uncloudify" things in the image, generally making it easier
to use for a simpler environment, and then it will exec /sbin/init.
|
|
This is useful for getting a config option that is either string or a
list as a list
|
|
use get_base_cfg from CloudInit:read_cfg
|
|
This logging infrastructure in cloudinit:
- uses python logging
- allows user supplied config of logging.config.fileConfig format to be
supplied in /etc/cloud/cloud.cfg or in cloud_config by user data.
- by default, tries to use syslog, if that is not available, writes directly to
/var/log/cloud-init.log (syslog will not be available yet when cloud-init
runs)
- when using syslog, the doc/21-cloudinit.conf file provides a rsyslogd
file to be placed in /etc/rsyslog.d/ that will file [CLOUDINIT] messages
to /var/log/cloud-init.log
|
|
|
|
LP: 507709
LP: #507709
|
|
|
|
|
