| Age | Commit message (Collapse) | Author |
|---|
|
This adds some function to the generator to maintain the presense of a
flag file '/run/cloud-init/enabled' indicating that cloud-init is enabled.
Then, only run the dhclient hooks if on Azure and cloud-init is enabled.
The test for is_azure currently only checks to see that the board vendor
is Microsoft, not actually that we are on azure. Running should not be
harmful anywhere, other than slowing down dhclient.
The value of this additional code is that then dhclient having run
does not task the system with the load of cloud-init.
Additionally, some changes to config are done here.
* rename 'dhclient_leases' to 'dhclient_lease_file'
* move that to the datasource config (datasource/Azure/dhclient_lease_file)
Also, it removes the config in config/cloud.cfg that set agent_command
to __builtin__. This means that by default cloud-init still needs
the agent installed. The suggested follow-on improvement is to
use __builtin__ if there is no walinux-agent installed.
|
|
It is more efficient and cross-distribution safe to use the hooks function
from dhclient to obtain the Azure endpoint server (DHCP option 245).
This is done by providing shell scritps that are called by the hooks
infrastructure of both dhclient and NetworkManager. The hooks then
invoke 'cloud-init dhclient-hook' that maintains json data
with the dhclient options in
/run/cloud-init/dhclient.hooks/<interface>.json .
The azure helper then pulls the value from
/run/cloud-init/dhclient.hooks/<interface>.json file(s). If that file does
not exist or the value is not present, it will then fall back to the
original method of scraping the dhcp client lease file.
|
|
Add support for installing and configuring ntp service, exposing the
minimum config of servers or pools to be added. If none are defined
then fallback on generating a list of pools by distro hosted at
pool.ntp.org (which matches what's found in the default ntp.conf
shipped in the respective distro).
|
|
|
|
LP: #1539317
|
|
If lxd key is present in cfg, then run 'lxd init' with values from the 'init'
entry in lxd configuration as flags.
|
|
#cloud-config
fan:
config: |
# fan 240
10.0.0.0/8 eth0/16 dhcp
10.0.0.0/8 eth1/16 dhcp off
# fan 241
241.0.0.0/8 eth0/16 dhcp
config_path: /etc/network/fan
LP: #1504604
|
|
Also implement DataSource.region for EC2 and GCE data sources.
|
|
|
|
- Implement set_passwd
- Implement set_timezone
- Use /bin/tcsh as default user shell (FreeBSD default)
- Change default username to freebsd
- Enable set-passwords, package-update-upgrade-install and timezone modules
- Remove trailing whitespace
|
|
|
|
|
|
get copied per default. Packaging will take care of installing this
configfile on the BSD platform.
|
|
|
|
tested or supported yet.
|
|
|
|
This doesn't differ much from the regular (linux) config, but currently
it helps while testing and setting up fbsd cloud instances.
|
|
|
|
I don't see a real need for these. The intent of the 'per-boot' or
'per-instance' or 'per-once' config modules is to handle running
scripts that were already inserted into the instance.
If the vendor is doing that, then there is value in vendor-data.
Ie, they'd already modified the image, they might as well have just
put the stuff in that they wanted.
|
|
|
|
|
|
This has been "best practice" for quite some time, and its a common
request of "where is the output of my user-data programs".
http://askubuntu.com/questions/345344/where-are-the-logs-for-my-user-data-script-cloud-init
|
|
vendordata.
Vendordata is a datasource provided userdata-like blob that is parsed
similiarly to userdata, execept at the user's pleasure.
cloudinit/config/cc_scripts_vendor.py: added vendor script cloud config
cloudinit/config/cc_vendor_scripts_per_boot.py: added vendor per boot
cloud config
cloudinit/config/cc_vendor_scripts_per_instance.py: added vendor per
instance vendor cloud config
cloudinit/config/cc_vendor_scripts_per_once.py: added per once vendor
cloud config script
doc/examples/cloud-config-vendor-data.txt: documentation of vendor-data
examples
doc/vendordata.txt: documentation of vendordata for vendors
(RENAMED) tests/unittests/test_userdata.py => tests/unittests/test_userdata.py
TO: tests/unittests/test_userdata.py => tests/unittests/test_data.py:
userdata test cases are not expanded to confirm superiority over vendor
data.
bin/cloud-init: change instances of 'consume_userdata' to 'consume_data'
cloudinit/handlers/cloud_config.py: Added vendor script handling to default
cloud-config modules
cloudinit/handlers/shell_script.py: Added ability to change the path key to
support vendor provided 'vendor-scripts'. Defaults to 'script'.
cloudinit/helpers.py:
- Changed ConfigMerger to include handling of vendordata.
- Changed helpers to include paths for vendordata.
cloudinit/sources/__init__.py: Added functions for helping vendordata
- get_vendordata_raw(): returns vendordata unprocessed
- get_vendordata(): returns vendordata through userdata processor
- has_vendordata(): indicator if vendordata is present
- consume_vendordata(): datasource directive for indicating explict
user approval of vendordata consumption. Defaults to 'false'
cloudinit/stages.py: Re-jiggered for handling of vendordata
- _initial_subdirs(): added vendor script definition
- update(): added self._store_vendordata()
- [ADDED] _store_vendordata(): store vendordata
- _get_default_handlers(): modified to allow for filtering
which handlers will run against vendordata
- [ADDED] _do_handlers(): moved logic from consume_userdata
to _do_handlers(). This allows _consume_vendordata() and
_consume_userdata() to use the same code path.
- [RENAMED] consume_userdata() to _consume_userdata()
- [ADDED] _consume_vendordata() for handling vendordata
- run after userdata to get user cloud-config
- uses ConfigMerger to get the configuration from the
instance perspective about whether or not to use
vendordata
- [ADDED] consume_data() to call _consume_{user,vendor}data
cloudinit/util.py:
- [ADDED] get_nested_option_as_list() used by cc_vendor* for
getting a nested value from a dict and returned as a list
- runparts(): added 'exe_prefix' for running exe with a prefix,
used by cc_vendor*
config/cloud.cfg: Added vendor script execution as default
tests/unittests/test_runs/test_merge_run.py: changed consume_userdata() to
consume_data()
tests/unittests/test_runs/test_simple_run.py: changed consume_userdata() to
consume_data()
|
|
Ubuntu images in 12.04 added the user to the 'admin' group.
The admin group was deprecated/replaced with the 'sudo' group in 12.10.
d-i adds its first-user to the 'sudo' group, so it makes sense to mimic
that behavior for the default user created by cloud-init. That was the
original reason behind the presense in the 'admin' group.
Also, here I sorted alphabetically the group list.
LP: #1228228
|
|
|
|
Changed cc_disk_setup to handle the file systems as a label, no longer
passing "log" around.
Tidied up the documentation to reflect the changes and made grammer,
spelling and improved the content a little.
Added disk_setup to the default modules list.
|
|
|
|
|
|
LP: #1136936
|
|
LP: #1080717
|
|
|
|
this adds 'power-state-change' config module that allows the user to
specify in cloud-config syntax that a system reboot or shutdown should occur
after cloud-init is done.
|
|
if 'name' for the user had something other than all lower case, then
pwd.getpwname would fail.
|
|
|
|
This allows the user to easily run stuff even after cloud-init-final
has finished. The initial reason for it is to be able to run
/sbin/poweroff and not have cloud-init complain loudly that it is
being killed.
LP: #1064665
|
|
that can be used to aid in the moving
of older versions of cloud-inits data
to newer versions of cloud-inits data.
1. Move the semaphores for the current instance
to there canonicalized names and use the
canonicalized in the file 'locking' code
|
|
|
|
|
|
|
|
Remove the need to have 'default_user' and 'default_user_groups' groups be
hard coded into the distro class, instead let that set of configuration be
located in the config file where it should be specified instead.
|
|
'default_user_groups' groups be hard coded
into the distro class, instead let that set
of configuration be located in the config
file where it should be specified instead.
|
|
|
|
on Ubuntu systems via cloud-config (LP: #1041384).
- Fixed bug with user creation on Ubuntu where the default user groups are
not set properly (LP: #1044044).
- Fixed documentation for user creation (LP: #1044508).
|
|
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.
|
|
|
|
There are several changes here.
* Datasource now has a 'availability_zone' getter.
* get_package_mirror_info
* Datasource convenience 'get_package_mirror_info' that calls
the configured distro, and passes it the availability-zone
* distro has a get_package_mirror_info method
* get_package_mirror_info returns a dict that of name:mirror
this is to facilitate use of 'security' and 'primary' archive.
* this supports searching based on templates. Any template
that references undefined values is skipped. These templates
can contain 'availability_zone' (LP: #1037727)
* distro's mirrors can be arch specific (LP: #1028501)
* rename_apt_lists supports the "mirror_info" rather than single mirror
* generate_sources_list supports mirror_info, and as a result, the
ubuntu mirrors reference '$security' rather than security (LP: #1006963)
* remove the DataSourceEc2 specific mirror selection, but instead
rely on the above filtering, and the fact that 'ec2_region' is only
defined if the availability_zone looks like a ec2 az.
|
|
|
|
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.
|
|
Example output:
ci-info: +---------+-------------------------+---------+-----------------+
ci-info: | Keytype | Fingerprint (md5) | Options | Comment |
ci-info: +---------+-------------------------+---------+-----------------+
ci-info: | ssh-rsa | e3:..:84:81:72:38:..:6a | - | smoser@brickies |
ci-info: | ssh-rsa | 21:..:32:8a:da:98:..:42 | - | smoser@bart |
ci-info: | ssh-rsa | 7b:..:ac:a7:17:51:..:b2 | - | smoser@kaypeah |
ci-info: +---------+-------------------------+---------+-----------------+
|
|
no args are provided. Adjust the config file to use this
older method so that older changes aren't needed. Also
when calling 'initctl' emit fails log the exception message
so that some useful warning information can be produced.
|
