summaryrefslogtreecommitdiff
path: root/systemd
AgeCommit message (Collapse)Author
2021-12-07Add miraclelinux support (#1128)Haruki TSURUMOTO
2021-10-26remove unnecessary EOF string in ↵Emanuele Giuseppe Esposito
disable-sshd-keygen-if-cloud-init-active.conf (#1075) Running 'systemd-analyze verify cloud-init-local.service' triggers the following warning: disable-sshhd-keygen-if-cloud-init-active.conf:8: Missing '=', ignoring line. The string "EOF" is probably a typo, so remove it. Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
2021-10-12Inhibit sshd-keygen@.service if cloud-init is active (#1028)Ryan Harper
In some cloud-init enabled images the sshd-keygen@.service may race with cloud-init and prevent ssh host keys from being generated or generating host keys twice slowing boot and consuming additional entropy during boot. This drop-in unit adds a condition to the sshd-keygen@.service which prevents running if cloud-init is active.
2021-09-13Support openEuler OS (#1012)zhuzaifangxuele
openEuler Homepage: https://www.openeuler.org/en/
2021-09-01Add CloudLinux OS support (#1003)Alexandr Kravchenko
https://www.cloudlinux.com/
2021-08-05Add support for EuroLinux 7 && EuroLinux 8 (#957)Aleksander Baranowski
2021-07-21Add VZLinux support (#951)eb3095
Virtuozzo Linux is a distro based off of CentOS 8, similar to Alma Linux and Rocky Linux.
2021-07-19Initial hotplug support (#936)James Falcon
Adds a udev script which will invoke a hotplug hook script on all net add events. The script will write some udev arguments to a systemd FIFO socket (to ensure we have only instance of cloud-init running at a time), which is then read by a new service that calls a new 'cloud-init devel hotplug-hook' command to handle the new event. This hotplug-hook command will: - Fetch the pickled datsource - Verify that the hotplug event is supported/enabled - Update the metadata for the datasource - Ensure the hotplugged device exists within the datasource - Apply the config change on the datasource metadata - Bring up the new interface (or apply global network configuration) - Save the updated metadata back to the pickle cache Also scattered in some unrelated typing where helpful
2021-06-18Add support for VMware PhotonOS (#909)sshedi
Also added a new (currently experimental) systemd-networkd renderer, and includes a small refactor to cc_resolv_conf.py to support the resolved.conf used by systemd-resolved.
2021-05-25Add Rocky Linux support to cloud-init (#906)Louis Abel
Rocky Linux is a RHEL-compatible distribution so all changes that have been made should be trivial.
2021-05-07Add AlmaLinux OS support (#872)Andrew Lukoshko
AlmaLinux OS is RHEL-compatible so all the changes needed are trivial.
2020-08-31Run cloud-init-local.service after the hv_kvp_daemon (#505)Robert Schweikert
This ensures that KVP data can be correctly reported to Azure.
2020-08-27systemd: add Before=shutdown.target when Conflicts=shutdown.target is used ↵Paride Legovini
(#546) Lintian spotted the following issue: The specified systemd .service file contains both DefaultDependencies=no and Conflicts=shutdown.target directives without Before=shutdown.target. This can lead to problems during shutdown because the service may linger until the very end of shutdown sequence as nothing requests to stop it before (due to DefaultDependencies=no). There is race condition between stopping units and systemd getting a request to exit the main loop, so it may proceed with shutdown before all pending stop jobs have been processed. Please add Before=shutdown.target. [1] https://lintian.debian.org/tags/systemd-service-file-shutdown-problems.html Co-authored-by: Rick Harding <rharding@mitechie.com>
2020-06-23cloud-init.service.tmpl: use "rhel" instead of "redhat" (#452)Daniel Watkins
We use "rhel" consistently everywhere else.
2020-06-23Change from redhat to rhel in systemd generator tmpl (#450)Eduardo Otubo
The name `redhat' is not used but rather `rhel' to identify the distro. Signed-off-by: Eduardo Otubo <otubo@redhat.com>
2019-10-31cloud-init.service: on centos/fedora/redhat wait on NetworkManager.serviceRyan Harper
In Centos/RHEL 8, NetworkManager is installed as the networking service. cloud-init.service needs to run After this service to allow the OS to bring networking up first. LP: #1843334
2019-09-26systemd/cloud-init.service.tmpl: start after wicked.serviceRobert Schweikert
Change the startup order. On SUSE distros cloud-init.service should start after wicked.service. This reflects the same start up order other distributions utilize.
2019-06-19cloud-init-generator: use libexec path to ds-identify on redhat systemsRyan Harper
Update the template to use libexec prefix path to ds-identify on redhat systems. LP: #1833264
2019-01-28systemd: Render generator from template to account for system differences.Robert Schweikert
The systemd generator used had a hard coded path for the location target file to create. This path does not apply to all distributions. Make the generator and template to have the path set during build time.
2018-10-24systemd: On SUSE ensure cloud-init.service runs before wickedRobert Schweikert
With db50bc0d9 the sysconfig renderer was enabled for openSUSE and SUSE Linux Enterprise. This requires that cloud-init.service starts before wicked. LP: #1799709
2018-05-14cloud-config.service: run After snap.seeded.service.Scott Moser
This makes cloud-config.service (and as a result cloud-final.service) run After snap.seeded.service. This is required to ensure that pre-seeded snaps can be used by cloud-init or user-data input. The snap.seeded.service was added to snapd at:   https://github.com/snapcore/snapd/pull/5124 Note that the following would be a workaround:  snap:   commands:    00: snap wait system seed.loaded LP: #1767131
2017-12-11SUSE: remove delta in systemd local template for SUSERobert Schweikert
On openSUSE and SLES systemd is allowed to pull the default dependencies, thus setting "Before=basic.target" is incorrect and creates a cycle leading to the deletion of the cloud-init-local.service
2017-10-03systemd: remove limit on tasks created by cloud-init-final.service.Robert Schweikert
Depending on distribution the default number of tasks (threads) maybe unexpectedly low or it may be the default systemd setting (512). Setting TasksMax to "infinity" in cloud-init-final.service removes the restriction on tasks created. LP: #1717969
2017-10-02systemd: only mention Before=apt-daily.service on debian based distros.Robert Schweikert
Ordering on apt service should only be set up on Debian based distributions. This changes is really a net-zero in runtime result. But, mentioning apt on a rpm based distro could be confusing.
2017-09-21suse: updates to templates to support openSUSE and SLES.Robert Schweikert
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
2017-09-15Do not provide systemd-fsck drop-in which could cause ordering cycles.Balint Reczey
Revert "centos: do not package systemd-fsck drop-in." Revert "systemd: make systemd-fsck run after cloud-init.service" The systemd-fsck drop-in caused regressions by introducing ordering The change reverts the original commit that added systemd-fsck drop-in and another commit that had removed that from the centos packaging: 1f5489c258a26f4e26261c40786537951d67df1e 8a5296c41db45be3a172862f324ad44e732a2250 The result is to no longer provide the systemd-fsck drop-in. LP: #1717477
2017-07-25systemd: make systemd-fsck run after cloud-init.serviceScott Moser
cloud-init.service may write filesystems (fs_setup) or re-partition (disk_setup) disks. If systemd-fsck is running on a device while that is occuring then the partitioning or mkfs might fail due to the device being busy. Alternatively, the fsck might fail and cause subsequent mount to fail. LP: #1691489
2017-07-19Templatize systemd unit files for cross distro deltas.Ryan Harper
Under el7, cloud-init systemd files need some unit tweaks to ensure they run at the right time. Pull in current el7 downstream systemd unit changes.
2017-06-13systemd: make cloud-final.service run before apt daily services.Scott Moser
This changes all cloud-init systemd units to run 'Before' the apt processes that run daily and may cause a lock on the apt database. apt-daily-upgrade.service contains 'After=apt-daily.service'. Thus following order is enforced, so we can just be 'Before' the first. apt-daily.service apt-daily-upgrade.service Note that this means only that apt-daily* will not run until cloud-init has entirely finished. Any other processes running apt-get operations are still affected by the global lock. LP: #1693361
2017-06-05systemd: Fix typo in comment in cloud-init.target.Chen-Han Hsiao
Simply fix a typo in a comment. No functional change.
2017-03-20cloudinit.net: add network config v2 parsing and renderingRyan Harper
Network configuration version 2 format is implemented in a package called netplan (nplan)[1] which allows consolidated network config for multiple network controllers. - Add a new netplan renderer - Update default policy, placing eni and sysconfig first This requires explicit policy to enable netplan over eni on systems which have both (Yakkety, Zesty, UC16) - Allow any network state (parsed from any format cloud-init supports) to render to v2 if system supports netplan. - Move eni's _subnet_is_ipv6 to common code for use by other renderers - Make sysconfig renderer always emit /etc/syconfig/network configuration - Update cloud-init.service systemd unit to also wait on systemd-networkd-wait-online.service 1. https://lists.ubuntu.com/archives/ubuntu-devel/2016-July/039464.html
2017-02-03Add tools/ds-identify to identify datasources available.Scott Moser
ds-identify is run here from the generator. If ds-identify does not see any datasources, it can completely disable cloud-init. The big value in this is that if there is no datasource, no python will ever be loaded, and cloud-init will be disabled.o The default policy being added here is: search,found=all,maybe=all,notfound=disabled That means: - enable (in 'datasource_list') all sources that are found. - if none are found, enable all 'maybe'. - if no maybe are found, then disable cloud-init. On platforms without DMI (everything except for aarch64 and x86), the default 'notfound' setting is 'enabled'. This is because many of the detection mechanisms rely on dmi data, which is present only on x86 and aarch64.
2016-11-15systemd: cloud-init-local use RequiresMountsFor=/var/lib/cloudScott Moser
While cloud-init writes its data to /var/lib/cloud, we previously lazily added RequiresMountsFor=/var/lib . It is more correct to list the more complete path. LP: #1642062
2016-11-15systemd: cloud-init remove After=systemd-networkd-wait-onlineScott Moser
cloud-init.service cannot currently run After=systemd-networkd-wait-online.service as systemd-networkd.service is After dbus.service, but cloud-init.service is: Before=sysinit.target and sysinit.target is before dbus.service. The result is that we are temporarily preferring for cases where there is systemd-networkd in place to have cloud-init.service run without networking properly configured. See bug 1636912 for more information.
2016-11-15systemd: cloud-init-local change Before basic to sysinitScott Moser
sysinit.target happens earlier in boot than basic.target. cloud-init-local.service had: Before=basic.target but cloud-init.service had: After=cloud-init-local.service Before=sysinit.target The result was that cloud-init-local.service was indirectly Before sysinit.target anyway, so this change is just to more specifically state that.
2016-11-10systemd: drop both Wants and After local-fs.targetScott Moser
Drop mention of local-fs.target from both cloud-init-local.service and cloud-init.service. This could actually could cause a loop in ordering due to cc_mounts writing mount points with: x-systemd.requires=cloud-init.service Rather, we specifically list /var/lib/ and systemd-remount-fs.service in cloud-init-local.service. cloud-init.service will run after cloud-init-local and thus will have these satisfied.
2016-11-10systemd: networking service adjustments.Scott Moser
Here we drop the Requires=networking.service but keep the After=networking.service. The change there is that we no longer force networking.service to run, as the system may not have it or be configured to use it. Second, we add After=systemd-networkd-wait-online.service. That causes us to run after systemd-networkd has brought networking up. The end result is that we now run after both ifupdown or systemd-networkd (if they were going to run) but do not force either to run. One other change is that by dropping Requires=networking.service cloud-init will now run even if networking failed to come up. LP: #1636912
2016-11-10systemd: replace Before=basic.target, dbus.target with sysinit.targetScott Moser
Per discussion on bug 1636912 and subsequent feedback on bug 1629797, using: Before=sysinit.target is a simpler solution than what we had implemented: Before=basic.target Before=dbus.target LP: #1629797
2016-10-07systemd: Run cloud-init.service Before dbus.socket not dbus.targetDaniel Watkins
The change reported to fix bug 1629797 was incorrect. It added: Before=dbus.target and its commit message referenced dbus.service. dbus.target does not exist, and dbus.service would not solve the problem. The change did not fix the problem nor actually make any difference. The fix here is just to use Before=dbus.socket. LP: #1629797
2016-10-04systemd: run cloud-init.service Before dbus.serviceScott Moser
This is the best work around we have for an issue seen when dns is used during cloud-init.service on a system that is configured in nsswitch to use systemd-resolved. The problem is that cloud-init.service was blocking basic.target, and dbus would not be available until after cloud-init.service finished. LP: #1629797
2016-09-21systemd: Ensure that cloud-init-local happens before NetworkManagerJoshua Harlow
2016-09-20Adjust mounts and disk configuration for systemd.Scott Moser
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
2016-09-15systemd: put cloud-init.target After multi-user.targetScott Moser
When we moved cloud-final.service to run After multi-user.target it caused a dependency loop (as cloud-init.target was still implied to be Before multi-user.target). journalctl would either show: cloud-init.target: Breaking ordering cycle by deleting job cloud-final.service/start or multi-user.target: Breaking ordering cycle by deleting job cloud-init.target/start The fix here is to clearly state that cloud-init.target is also After multi-user.target LP: #1623868
2016-09-09systemd: Better support package and upgrade.Scott Moser
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
2016-08-22azure dhclient-hook cleanupsScott Moser
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.
2016-05-27remove blocking udev functionalityScott Moser
This didn't really work. See bug for more info. LP: #1577844
2016-04-04systemd: do not specify After of obsolete syslog.target (LP: #1536964)Scott Moser
syslog.target is obsolete in debian, this fixes a lintian warning. LP: #1536964
2016-03-21cloud-init-local needs to want network-pre or it isnt guaranteed to startScott Moser
2016-03-20fix creation of network-config-ready and dont bother waiting on loScott Moser
2016-03-18cloud-init-local.service: touch file that cloud-init-wait will wait forScott Moser
this might work. And if it does means we could generally test this as the file that the cloud-init-wait will wait for will actually get created.