[09:25] <IanTPrice> I'm having an issue with the `write_files` module in cloud-init
[09:26] <IanTPrice> For the .yaml file I'm using:
[09:26] <IanTPrice> `#cloud-configwrite_files:  - encoding: ""    path: /home/ubuntu/test.sh    owner: ubuntu:ubuntu    permissions: '0755'    append: true    content: |      #!/usr/bin/env bash      ls -lsa /home/ubuntu`
[09:27] <IanTPrice> and I'm running that using
[09:27] <IanTPrice> `multipass launch --name k5 -c 1 -d 3G -m 1G --cloud-init cloud-init/k3s-master.yaml daily:20.04`
[09:29] <IanTPrice> However, the code wipes out all files in the `/home/ubuntu`  directory with the exception of the `.ssh` directory
[09:30] <IanTPrice> In addition the `owner: ubuntu:ubuntu` line has never worked
[09:30] <IanTPrice> Anyone got any ideas or links to show where I'm going wrong?
[09:31] <Saviq> IanTPrice: it's very difficult to see what your YAML actually is, can you please https://pastebin.ubuntu.com/ it ?
[09:32] <IanTPrice> I've tried many, many combinations of the `.yaml` file (BTW, multipass does a yaml validation check so I know it's not incorrect yaml
[09:32] <Saviq> IanTPrice: it doesn't have to be incorrect YAML for cloud-init to do something that you didn't expect
[09:32] <IanTPrice> saviq: will do - anyone know know how to paste multiline code in IRC?
[09:33] <Saviq> IanTPrice: your client would split it into multiple messages
[09:33] <Saviq> would/should
[09:33] <IanTPrice> #cloud-configwrite_files:  - encoding: ""    path: /home/ubuntu/test.sh    owner: ubuntu:ubuntu    permissions: '0755'    append: true    content: |      #!/usr/bin/env bash      ls -lsa /home/ubuntu
[09:34] <Saviq> nope
[09:37] <IanTPrice> https://pastebin.ubuntu.com/p/rWM2ntXdKR/plain/
[09:40] <IanTPrice> link including the run command: https://pastebin.ubuntu.com/p/m3mW7RcCx2/
[13:41] <Odd_Bloke> LongLiveCHIEF: o/ Are you still having your Pi problem?
[13:46] <Odd_Bloke> IanTPrice: I've just tested that user-data (though not in multipass) and AFAICT it's working as expected (an executable test.sh is present in /home/ubuntu, with the specified contents) with the exception of setting the owner (which I will find a bug for in a moment).  Why would you expect there to be any files in /home/ubuntu other than .ssh?
[13:49] <Odd_Bloke> IanTPrice: As for the owner issue, you're running into https://bugs.launchpad.net/cloud-init/+bug/1486113.  write_files runs before cloud-init creates users/groups (so that the written files can affect how users/groups are created), which causes problems in your case.  The easiest workaround is to add a runcmd which sets the permissions/ownership as you would like (as runcmd happens after both write_files
[13:49] <Odd_Bloke> and users/groups).
[15:37] <IanTPrice> Odd_Bloke Thanks thanks for the bug report - hadn't come across that but should be able to code around it
[15:38] <Odd_Bloke> Yeah, it's an annoying one, for sure, but the workarounds are pretty simple once you know about it.
[15:38] <Odd_Bloke> Happy I could help. :)
[15:39] <IanTPrice> Odd_Bloke If I don't write the file, or if I write it to /test.sh then there are the standard files in the users home directory, namely ~/.bashrc among others
[15:40] <IanTPrice> all those files disappear if I write the file to /home/ubuntu/test.sh with the exception of the .ssh directory... ???
[15:41] <IanTPrice> Just tried it on AWS EC2 user data - it does the same thing  that helps with some elimination - it's not multipass or linux distro
[15:42] <Saviq> IanTPrice, Odd_Bloke, won't that actually be a result of the same problem?
[15:42] <Saviq> write_files creates /home/ubuntu, so adduser then doesn't copy the skeleton?
[15:54] <Odd_Bloke> Yeah, that probably is the problem, I see what you mean now.
[15:54] <Odd_Bloke> That's not the bug I linked though, that's specifically to do with `owner` not working as expected.
[15:56] <Odd_Bloke> And a search ("write_files skel") doesn't turn up any existing bugs for it.
[15:56] <IanTPrice> but you're right - it is a timing issue - I created the file in /home/newuser/test.sh and `write_files` creates the directory structure automatically
[15:58] <IanTPrice> so, as you say, `adduser` is not adding the skeleton becuase the user directory has already been created
[15:59] <IanTPrice> I could see the wood for the trees there.  many thanks for giving me the right steer - pair programming works wonders!
[16:00] <IanTPrice> *could* *couldN'T*
[16:05] <IanTPrice> The smoking gun `The home directory `/home/newuser' already exists.  Not copying from '/etc/skel'`
[16:11] <IanTPrice> Priceless: `This was first reported in 2013 in bug #1231541` =$
[16:32] <Odd_Bloke> Yeah, it's been open for a long time because changing the behaviour is backwards-incompatible.  (The trivial case to consider: a write_files to /etc/skel to ensure that all created users have the same .wibblerc in their home directories.)
[16:33] <Odd_Bloke> s/behaviour/the ordering of the modules/
[16:50] <Odd_Bloke> blackboxsw: We didn't assign PRs in stand-up: I'll take the older one, and I'll assign you to the newer one.
[17:21] <Odd_Bloke> blackboxsw: I don't know why CI on your PR didn't catch this, but it looks like your schema changes introduced a pylint error: https://github.com/canonical/cloud-init/pull/332
[17:22] <blackboxsw> thanks Odd_Bloke just out of mtgs. will grab it.
[17:24] <blackboxsw> Odd_Bloke: typo in the comment and +1 on https://github.com/canonical/cloud-init/pull/332/files
[17:25] <IanTPrice> Odd_Bloke The suggestion of adding a `write_files_late` seems eminently suitable and should not break backwards compatability