write_files runs before users/groups, renders "owner" useless
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Fix Released
|
Medium
|
Unassigned |
Bug Description
When the following cloud-init script is run the expectation is that a group called ssl-cert-client is created, and this group is applied to the file that is written via the "owner" tag.
groups:
- ssl-cert-server
- ssl-cert-client
write_files:
- encoding: gzip
content: !!binary |
$(echo ${rsa_client_
owner: root:ssl-
path: /etc/ssl/
permissions: '0640'
What happens instead is that the writing of the file is attempted before the creation of the group, and this file write fails because the group ssl-cert-server does not yet exist.
The two tasks need to be swapped round before they are practically useful.
summary: |
- write-files runs before users/groups, renders "owner" useless + write_files runs before users/groups, renders "owner" useless |
Changed in cloud-init: | |
status: | Confirmed → Triaged |
importance: | High → Medium |
Thank you for taking the time to report this bug. In an effort to keep
an up-to-date and valid list of bugs to work on, I have reviewed this
report verifying it still requires effort and occurs on a supported
version of Ubuntu.
I do agree that the situation you spell out occurs. Consider the
following simplier example:
userdata.yaml:
#cloud-config
groups:
- testgroup
write_files:
- encoding: file
content: test data
owner: root:testgroup
path: /root/testfile
permissions: '0640'
This should write a file to /root/testfile with the permissions
set to root:testgroup.
$ lxc init ubuntu-daily:x x
$ lxc config set x user.user-data - < userdata.yaml
$ lxc start x
$ lxc exec x2 -- ls -l /root/testfile
-rw-r----- 1 root root 9 Jul 27 21:42 /root/testfile