[lxc-users] LXD 2.4.1 - Trouble with Cloud Init

[Neil Bowers]

Thank you so much - this has been bugging me for weeks.

I do have a question, however, in regards to the 'write_files' directive -
since this runs before users are created (and while I understand that
having it able to affect more of boot is useful, but it's not documented
like that anywhere I can find), if I were to create the file in `/etc/skel`
instead, would any created users pick it up from there?  Or is that ignored
when creating users with cloud-init ?

Essentially I'm just trying to set up a simple way to put up and tear down
containers that will have all of my defaults in place from the start.

Neil

On Thu, Jan 26, 2017 at 2:00 PM, Serge E. Hallyn <serge at hallyn.com> wrote:

> Hi,
>
> Scott Moser was kind enough to provide this reply:
>
> (http://paste.ubuntu.com/23870807/)
>
> #!/bin/sh
>
> ##
> ## This is Scott Moser in reply to
> ##   https://lists.linuxcontainers.org/pipermail/lxc-users/2017-
> January/012766.html
> ## The user-data you have has some problems, and is stopping it from
> working
> ## as you desire.  This script can be executed to launch an instance
> ## with the user-data included inside it, and will show it functioning
> ## correctly.
> ##
> ## I did not test, but assume that updating profile accordingly will get
> you
> ## the behavior you're after.
> ##
> ## Scott
>
> ## changes from your user-data
> # 'sudo' is a string, you had it as a list.
> # 'write_files':
> #    - changed path to /root/ (there is no '~' in this scenario, cloud-init
> #      could possibly interpret that as the default user, but it does not.
> #    - files are created before users are added... write files runs early
> #      that means it can affect more of boot, but means it can't write
> #      files owned by users who do not yet exist.
> #      there is a bug/feature request for this, we could add a
> #      'write_files_late' module that ran later and could then populate
> #      created users directories.
> #    - you had bad yaml in one part, the 'content' was as if it intended
> #      to be included in the previous 'path', but was a new list entry.
> #      basically that 'content' had no 'path'.
> #
> # with regard to no errors, you can see the issues with
> #  journalctl --unit=cloud-init.service
> # look for 'WARN'.  Also /run/cloud-init/result.json should report errors.
> #
> # These should get written to /var/log/cloud-init.log, but in yakkety
> # you wont see them there yet. (bug 1643990)
>
> udata=$(cat <<"EOF"
> #cloud-config
> users:
>   - name: dood
>     gecos: Mr Dood
>     ssh_authorized_keys:
>       - ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA3I
> 7VUf2l5gSn5uavROsc5HRDpZdQueUq5ozemNSj8T7enqKHOEaFoU2VoPgGEW
> C9RyzSQVeyD6s7APMcE82EtmW4skVEgEGSbDc1pvxzxtchBj78hJP6Cf5TCMFSXw+
> Fz5rF1dR23QDbN1mkHs7adr8GW4kSWqU7Q7NDwfIrJJtO7Hi42GyXtvEONHb
> iRPOe8stqUly7MvUoN+5kfjBM8Qqpfl2+FNhTYWpMfYdPUnE7u536WqzFmsaqJc
> tz3gBxH9Ex7dFtrxR4qiqEr9Qtlu3xGn7Bw07/+i1D+ey3ONkZLN+
> LQ714cgj8fRS4Hj29SCmXp5Kt5/82cD/VN3NtHw== smoser at brickies
>     sudo: 'ALL=(ALL) NOPASSWD:ALL'
>     groups: sudo
>     shell:  /bin/bash
> write_files:
>   - owner:  root:root
>     path: /root/.bash_aliases
>     content: |
>       alias dir='ls -Alph --color=auto'
> apt_proxy: "http://192.168.1.2:8000"
> EOF
> )
>
> name=$1
> rel=${2:-yakkety}
> lxc launch "ubuntu-daily:$rel" "$name" "--config=user.user-data=$udata"
>
> -serge
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20170127/7d7b7f79/attachment.html>