cloud-init team mailing list archive
-
cloud-init team
-
Mailing list archive
-
Message #00158
Re: cloud-init run command executed on every boot
My previous response inadvertently dropped the mailing list. I've added
back here.
On Thu, May 17, 2018 at 12:23 PM, Konstantinos Papadopoulos <
kostis.g.papadopoulos@xxxxxxxxx> wrote:
> Hello Scott, I will try option b when instantiating the image in our
> openstack platform
> However what I tried not successfully was to place the file
> my-server-config.conf under the path /etc/cloud/cloud.cfg.d/my
> -server-config.conf.
> The content of the my-server-config.conf. file was
>
> # run commands
> # default: none
> # runcmd contains a list of either lists or a string
> # each item will be executed in order at rc.local like level with
> # output to the console
> # - runcmd only runs during the first boot
> # - if the item is a list, the items will be properly executed as if
> # passed to execve(3) (with the first arg as the command).
> # - if the item is a string, it will be simply written to the file and
> # will be interpreted by 'sh'
> #
> # Note, that the list has to be proper yaml, so you have to quote
> # any characters yaml would eat (':' can be problematic)
> bootcmd:
> - [ ls, -l, / ]
> - [ sh, -xc, "echo $(date) ': hello world!'" ]
> - [ sh, -c, echo "=========hello world'=========" ]
> - ls -l /root
> - [ wget, "http://slashdot.org", -O, /tmp/index.html ]
>
> for which I was expecting to find the index.html file under /tmp folder.
> However this did not happen. I guess I still miss something.
>
I just tested with your bootcmd in
/etc/cloud/cloud.cfg.d/my-server-config.cfg
(note .cfg extension, not .conf. sorry for that).
that works as expected.
Also, note though that usage of /tmp is not really safe. that is because
systemd or some other thing may clean /tmp during boot.
I tried also to fill the content of my conf file with the what you attached
> under http://paste.ubuntu.com/p/w8QQjN4dPC/ but without success.
> Is the path at l.7 correct?
>
> echo "$(date -R): Ran per-boot at ${up}s" | tee -a /run/my-per-boot.log
>
> Should it be
>
> echo "$(date -R): Ran per-boot at ${up}s" | tee -a /root/my-per-boot.log
>
> If this is the case should I expect to find the my-per-boot.log under /root?
>
>
In the example there, I chose /run as /run (on most linux) is a tmpfs so it
is guaranteed to be cleaned every boot. I used /root on the per-once
messages so that you'd see that reboot did not cause that to get re-written
or appended to.
As a demonstration of how to test this and to show how really nice lxd is
for testing cloud-init:
$ lxc init ubuntu-daily:xenial mytest1
# my.cfg has content from http://paste.ubuntu.com/p/w8QQjN4dPC/
$ lxc file push my.cfg mytest1/etc/cloud/cloud.cfg.d/my.cfg
$ lxc start mytest1
$ sleep 5
$ lxc exec mytest1 cat /run/my-per-boot.log
Thu, 17 May 2018 17:10:53 +0000: Ran per-boot at 8.00s
$ lxc exec mytest1 cat /root/my-per-once.log
Thu, 17 May 2018 17:10:53 +0000: Ran per-once up 8.00s
$ lxc restart mytest1
$ sleep 5
$ lxc exec mytest1 cat /run/my-per-boot.log
Thu, 17 May 2018 17:12:19 +0000: Ran per-boot at 4.00s
$ lxc exec mytest1 cat /root/my-per-once.log
Thu, 17 May 2018 17:10:53 +0000: Ran per-once up 8.00s
Thanks in advance
>
> Br
>
> Konstantinos
>
>
>
>
> On Tue, May 15, 2018 at 5:08 PM, Scott Moser <smoser@xxxxxxxxxx> wrote:
>
>>
>> On Tue, May 15, 2018 at 9:53 AM, Konstantinos Papadopoulos <
>> kostis.g.papadopoulos@xxxxxxxxx> wrote:
>>
>>> Hello Scott and thank you for the reply,
>>> the second option "put scripts into /var/lib/cloud/scripts/per-boot/"
>>> worked as expected. So I put a script under /var/lib/cloud/scripts/per-
>>> boot/ and it worked.
>>> My question now is where am I going to store under /var/lib/cloud the
>>> "my-write-files" you attached which is in yml form so that I have these two
>>> log files written in the directories specified within the my-write-files.
>>> Does the file need to have a my-write-files need to have a suffix .yml?
>>> Thanks in advance
>>>
>>
>> You have 2 options:
>> a.) a file in the system in /etc/cloud/cloud.cfg.d/your-stuff.conf
>> b.) provide it as user-data when you launch an instance
>>
>
I was wrong in 'a' above. your-stuff.cfg (.cfg, not .conf).
>
>> 'b' is infinitely more flexible.
>>
>>
Follow ups
References