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 <se...@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@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 >
_______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
