write_files runs before users/groups, renders "owner" useless

Bug #1486113 reported by Graham Leggett on 2015-08-18
50
This bug affects 13 people
Affects Status Importance Assigned to Milestone
cloud-init
High
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_private_key} | gzip - | openssl base64 | sed -e "s/^/ /")
  owner: root:ssl-cert-client
  path: /etc/ssl/certs/${resourcegroup}-${machine}.${domain}-client.key
  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.

Joshua Powers (powersj) wrote :

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

Changed in cloud-init:
status: New → Confirmed
importance: Undecided → High
Scott Moser (smoser) on 2018-07-13
summary: - write-files runs before users/groups, renders "owner" useless
+ write_files runs before users/groups, renders "owner" useless
Scott Moser (smoser) wrote :

To be fair, this isn't completely useless.
If we simply moved the writing of files to after users were created, then less of the boot could be affected by your written files.

As a (possibly contrived) example, as it is right now you can use write_files to replace 'adduser' and then cloud-init would call the replaced version of adduser when adding users. If write_files happened later you could not do that.

I would like to get this to work though.
2 options:
a.) add 'write_files_late' that runs after users are created (or write_files_early and write_files) basically 2 different points in boot.
b.) magically determine if 'owner' isn't around that we should re-try this after the usergroups are created.
c.) extend format of write_files to include 'early' or 'late' that would indicate to cloud-init explicitly that it should happen after users or before users creation.

I accept your reasoning. And following it, I would add the write_files_late for “my” purpose ;-) and leave the current write_files as is. Either this, or include a new sub item in users, like users - <user> - write_files to write files of a specific user...

Don’t know how you feel about this alternative. But it seems logical and would be backwards-compatible

Best, /PA

Enviado desde mi iPad

> El 13 jul 2018, a las 18:17, Scott Moser <email address hidden> escribió:
>
> To be fair, this isn't completely useless.
> If we simply moved the writing of files to after users were created, then less of the boot could be affected by your written files.
>
> As a (possibly contrived) example, as it is right now you can use
> write_files to replace 'adduser' and then cloud-init would call the
> replaced version of adduser when adding users. If write_files happened
> later you could not do that.
>
> I would like to get this to work though.
> 2 options:
> a.) add 'write_files_late' that runs after users are created (or write_files_early and write_files) basically 2 different points in boot.
> b.) magically determine if 'owner' isn't around that we should re-try this after the usergroups are created.
> c.) extend format of write_files to include 'early' or 'late' that would indicate to cloud-init explicitly that it should happen after users or before users creation.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1781549).
> https://bugs.launchpad.net/bugs/1486113
>
> Title:
> write_files runs before users/groups, renders "owner" useless
>
> Status in cloud-init:
> Confirmed
>
> 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_private_key} | gzip - | openssl base64 | sed -e "s/^/ /")
> owner: root:ssl-cert-client
> path: /etc/ssl/certs/${resourcegroup}-${machine}.${domain}-client.key
> 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.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cloud-init/+bug/1486113/+subscriptions

Adam Spiers (adam.spiers) wrote :

This was first reported in 2013 in bug #1231541 and I still see the issue :-/ Is there any reason not to simply just swap the order? Why would it ever be a problem to run write_files after users_groups?

Scott Moser (smoser) wrote :

On Thu, Jan 10, 2019, 1:30 PM Adam Spiers <<email address hidden> wrote:

> This was first reported in 2013 in bug #1231541 and I still see the
> issue :-/

I understand the frustration.

Is there any reason not to simply just swap the order?

Backwards compatibility

  Why
> would it ever be a problem to run write_files after users_groups?
>

The simple example of writing a file to /etc/skel that you wanted to have
copied into created users' do.

>

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers