| Age | Commit message (Collapse) | Author |
|---|
|
This adds a config module so support for adding zypper repositories
via cloud-config.
LP: #1718675
|
|
Things done here:
- identify 'suse' as a variant in util.system_info and
also tools/render-cloudcfg.
- update systemd and cloud.cfg templates for suse specific changes.
LP: #1718640
|
|
The ubuntu-init-switch module allowed the use to launch an instance that
was booted with upstart and have it switch its init system to systemd and
then reboot itself. It was only useful for the time period when Ubuntu was
transitioning to systemd but only produced images using upstart.
Also, do not run setup with --init-system=upstart. This means that by
default, debian packages built with packages/bddeb will not have upstart
unit files included. No other removal is done here.
|
|
- Simplify the logic of 'variant' in util.system_info
much of the data from
https://github.com/hpcugent/easybuild/wiki/OS_flavor_name_version
- fix get_resource_disk_on_freebsd when running on a system without
an Azure resource disk.
- fix tools/build-on-freebsd to replace oauth with oauthlib and add
bash which is a dependency for tests.
- update a fiew places that were checking for freebsd but not using
the util.is_FreeBSD()
|
|
Here we move the config/cloud.cfg to be rendered as a template.
That allows us to maintain deltas between distros in one place.
Currently we use 'variant' variable to make decisions.
A tools/render-cloudcfg is provided to render the file.
There were changes to setup.py, MANIFEST.in to allow us to put all
files into a virtual env installation and to render the cloud-config
file in 'install' or 'bdist' targets.
We have also included some config changes that were found in the
redhat distro spec.
* include some config changes from the redhat distro spec.
The rendered cloud.cfg has some differences.
Ubuntu: white space and comment changes only.
Freebsd:
- whitespace changes and comment changes
- datasource_list definition moved to be closer to 'datasource'.
- enable modules: migrator, write_files
- move package-update-upgrade-install to final.
The initial work was done by Josh Harlow.
|
|
This patch targets to make FreeBSD 10.3 or 11 work on Azure. The
modifications abide by the rule of:
* making as less modification as possible
* delegate to the distro or datasource where possible.
The main modifications are:
1. network configuration improvements, and movement into distro path.
2. Fix setting of password.
Password setting through "pw" can only work through pipe.
3. Add 'root:wheel' to syslog_fix_perms field.
4. Support resizing default file system (ufs)
5. copy cloud.cfg for freebsd to /etc/cloud/cloud.cfg rather than
/usr/local/etc/cloud/cloud.cfg.
6. Azure specific changes:
a. When reading the azure endpoint, search in a different path
and read a different option name (option-245 vs. unknown-245).
so, the lease file path should be generated according to platform.
b. adjust the handling of ephemeral mounts for ufs filesystem and
for finding the ephemeral device.
c. fix mounting of cdrom
LP: #1636345
|
|
Instead of being dependent on the availability of syslog that
various distributions may not enable or configure correctly
or they do so via patches just use a known-to-work default
logging mechanism. If distros want to change this, that
is fine, but at least the built-in one will work reliably.
LP: #1643990
|
|
Ubuntu Core images use the `snap create-user` to add users to an
Ubuntu Core system. Add support for creating snap users by adding
a key to the users dictionary.
users:
- name: bob
snapuser: bob@bobcom.io
Or via the 'snappy' dictionary:
snappy:
email: bob@bobcom.io
Users may also create a snap user without contacting the SSO by
providing a 'system-user' assertion by importing them into snapd.
Additionally, Ubuntu Core systems have a read-only /etc/passwd such that
the normal useradd/groupadd commands do not function without an additional
flag, '--extrausers', which redirects the pwd to /var/lib/extrausers.
Move the system_is_snappy() check from cc_snappy module to util for
re-use and then update the Distro class to append '--extrausers' if
the system is Ubuntu Core.
|
|
since ntp module may try to install packages, it needs to run after
apt is configured.
LP: #1628337
|
|
The end result of all of these changes is to get mounts managed by
cloud-init to occur only after cloud-init.service is done. We need to do
that so that filesystems that are set up by cloud-init (in disk_setup)
do not get mounted by stale entries in /etc/fstab before
the setup occurs.
This can occur in 2 ways:
a.) new instance with old /etc/fstab
b.) same instance where disk needs adjusting (Azure resize will re-format
the ephemeral disk).
The list of changes here is:
- move mounts and disk_setup module to cloud-init.service rather
than config. cloud-init.service runs earlier in boot so it
can get those mount points done earlier.
- on systemd add 'x-systemd.requires=cloud-init.service' to fstab options
- cloud-init-local.service: add Before=basic.target
- cloud-init.service:
- extend After, Before, and Wants to multiple lines rather than one
long line.
- sort consistently with cloud-init-local.service
- add DefaultDependencies=no
- add Before=default.target
- add Conflicts=shutdown.target
LP: #1611074
|
|
In systemd, package installation before the system is fully booted
(systemctl is-system-running == starting) may result in the package not
being started. Upgrade (package_upgrade: true) can also cause failure if
that is done during systemd boot.
The solution here is:
a.) move config modules that do or may do package installation to
'final_modules'. That list is:
- snappy
- package-update-upgrade-install
- fan
- landscape
- lxd
- puppet
- chef
- salt-minion
- mcollective
b.) move cloud-final.service to run as 'Type=idle'
LP: #1576692, #1621336
|
|
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
|
|
|
|
|
|
|
