| Age | Commit message (Collapse) | Author |
|---|
|
move the section on user and group adds into
doc/examples/cloud-config-user-groups.txt
|
|
configurations were applied. The result of this bug was that cloud-config
supplied SSH public keys would fail to apply since the configured user
may or may not exist. (LP: #1042459).
cloudinit/config/cc_ssh_import_id.py:
ssh_import_id.py now handles all user SSH import IDs.
cloudinit/distros/ubuntu.py:
Removed create_user class override as cruft, since ssh_import_id
now handles all users.
config/cloud.cfg:
Moved users_groups to run under cloud_init_modules.
doc/examples/cloud-config.txt:
Added missing documentation on user and group creation.
|
|
Added "userless" mode to cloud-init for handling the creation of the users
and the default user on Ubuntu. The end goal of this is to remove the need
for the 'ubuntu' user in the cloud images and to allow individuals to
choose the default user name.
LP: #1028503
|
|
users and the default user on Ubuntu.
cloudinit/config/cc_users_groups.py: new cloud-config module for creating
users and groups on instance initialization.
- Creates users and group
- Sets "user" directive used in ssh_import_id
cloudinit/config/cc_ssh_import_id.py: module will rely upon users_groups
for setting the default user. Removed assumption of 'ubuntu' user.
cloudinit/distros/__init__.py: Added new abstract methods for getting
and creating the default user.
cloudinit/distros/ubuntu.py: Defined abstract methods for getting and
and creating the default 'ubuntu' user on Ubuntu instances.
cloudinit/util.py: Added ability to hide command run through util.subp to
prevent the commands from showing in the logs. Used by user_groups
cloud-config module.
config/cloud.cfg: Removed "user: ubuntu" directive and replaced with new
user-less syntax.
doc/examples/cloud-config.txt: Documented the creation of users and groups.
|
|
As described in the bug, enough non-cloud users experienced issues with
cloud-init selecting a mirror due to consumer level network providers using
dns server redirection.
We're turning this off by default.
LP: #974509
|
|
This implements file writing via cloud-config. It also
* adjusts other code to have user/group parsing in util instead
of in stages.py,
* renames decomp_str to decomp_gzip since it is more meaningful when named
that (as thats all it can decompress).
LP: #1012854
|
|
Adjust the examples file to reflect this.
|
|
happens first, which will examine the incoming encoding, and decide the
neccasary decoding types needed to get the final resultant string and
then use these normalized decoding types to actually do the final decode.
Also change the name of the config key that is looked up to 'write_files'
since 'files' is pretty generic and could have clashes with other modules.
Add an example that shows how to use this in the different encoding formats
that are supported.
|
|
cloud-init expands $RELEASE in a source so it can easily be used.
|
|
|
|
|
|
Also added some comments and captured the output
|
|
What this does is provide an second DataSource that could use the
kernel command line url=. For example:
ro root=/dev/vda url=http://example.com/i-abcdefg/
http://example.com/i-abcdefg/ would contain:
datasource:
NoCloud:
# default seedfrom is None
# if found, then it should contain a url with:
# <url>/user-data and <url>/meta-data
# seedfrom: http://my.example.com/i-abcde
seedfrom: http://example.com/i-abcdefg/
Then, the NoCloudNet DataSource would find that seedfrom config
and consume data at
http://example.com/i-abcdefg/user-data
and
http://example.com/i-abcdefg/meta-data
|
|
|
|
instead of MaaS or Maas, use MAAS consistently.
The only non 'MAAS' left are all lower case.
|
|
Thanks to Ben Howard.
|
|
|
|
- Changed values to be more simplistic and intuitive
- Only allow pipelining values up to 5
- Changed to per_instance over per_always to remove need
for tracking the values
- Fixed Python style
|
|
|
|
- cloud-config option of "apt-pipelining"
- Address LP: 948461
|
|
|
|
|
|
|
|
|
|
|
|
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')
|
|
- reference cloud-init-per
- mention that INSTANCE_ID is in environment of bootcmd scripts
|
|
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
|
|
This increases the timeout for a metadata request to something that should
be easily satisfiable (50 seconds). But hopefully does so while still keeping
the case of no-metadata service in mind.
Previously, there was a small timeout and many retries (30) would be done.
Now,
- larger timeout (50 seconds) by default
- retry until a given "max_wait" is reached (120 seconds default)
The end result is that if we're hitting the timeout, there will only end up
being a couple attempts made. But if the requests are coming back quickly
then we'll still make several attempts.
There is one EC2DataSource config change, now 'retries' is not used, but rather
'max_wait' to indicate generally how long it should try to find a metadata
service.
|
|
|
|
|
|
|
|
This adds doc/examples/cloud-config.txt data for the
options that were added when pulling in Fedora support.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The primary motivation for this is so that 'nobootwait' is not hard
coded to appear in the fs_opts field.
LP: #785542
|
|
Previously, when cloud-config was ready, cloud-init would emit an
upstart event with:
initctl emit cloud-config
Now, that command is configurable via the 'cc_ready_cmd' value in
cloud.cfg or user data. The default behavior is not changed.
LP: #785551
|
|
This makes the prefix for entries added to root's authorized keys
configurable. Previously, the value was:
command="echo 'Please login as the user \"ubuntu\" rather than the user \"root\".\';echo;sleep 10\""
Now, at is configurable in cloud.cfg or user data by setting
'root_disabled_opts'.
Additionally, the default has been changed to include
'no-port-forwarding,no-agent-forwarding,no-X11-forwarding'
See LP: #798505 for more information on that.
Note, that 'no-pty' was *not* added to this list as adding it means the
user who simply does 'ssh root@host' gets a "cannot allocate pty" message
rather than seeing warning about using root.
LP: #798505
|
|
LP: #797336
|
