cloud-init team mailing list archive

[Bean Taxi <beantaxi@xxxxxxxxx>]

Thanks for the answer(s) Ryan!

One question on the cloud-boothook suggestion. From the docs, it looks like
cloud-boothook exists to provide the earliest possible execution. Ie, it
sounds like something I'd run not just as an easy way to get once-per-boot
behavior, but because I'm pretty darn sure that I want something to happen
really early in the boot process.

I'm not an expert in the boot process, and the person I hand my boot
script(s) off to won't be either. So I'm concerned that any arbitrary
action my script takes might fail because it needs networking, or mounts,
or something else that happens to occur later in the boot process than
cloud-boothook, since cloud-boothook sounds to explicitly exist to happen
as early in the boot process as possible.

But perhaps I'm reading this wrong.

Thanks!
Bean



On Mon, Aug 31, 2020 at 10:45 AM Ryan Harper <rharper@xxxxxxxxxxx> wrote:

>
>
> On Fri, Aug 28, 2020 at 4:32 PM Bean Taxi <beantaxi@xxxxxxxxx> wrote:
>
>> I think I've found at least a partial answer to this ... not sure, but I
>> suspect the /v/l/c/scripts/per-* folders are used by the cc_script_per_*
>> modules, and the /v/l/c/iinstance/scripts folder is used by the
>> scripts-user module.
>>
>
> Yes, that's correct.
>
>
>>
>> Actually, from looking at the code, I'm 99.9% sure this is what's
>> happening. And that there won't be any conflict, they're just independent
>> modules.
>>
>
> No, the various modules will call run-parts (8) on the directory.  The are
> called on the frequency of the name.
>
>
>> On Fri, Aug 28, 2020 at 3:30 PM Bean Taxi <beantaxi@xxxxxxxxx> wrote:
>>
>>> Hello all,
>>>
>>> From the handler/shell_script.py code, and from experience & thanks to
>>> this list, MIME encoded shellscripts get copied to
>>> /var/lib/cloud/instance/scripts.
>>>
>>>     def __init__(self, paths, **_kwargs):
>>>         handlers.Handler.__init__(self, PER_ALWAYS)
>>>         self.script_dir = paths.get_ipath_cur('scripts')
>>>         if 'script_path' in _kwargs:
>>>             self.script_dir = paths.get_ipath_cur(_kwargs['script_path'])
>>>
>>> After spending quite a bit of time trying to find where the proper per-*
>>> subfolder gets created, I finally realized that it doesn't:
>>> /var/lib/cloud/instance/scripts is a flat folder.
>>>
>> That makes me wonder how cloud-init knows how often to run those scripts,
>>> but maybe that's what the scripts-user module is for, particularly the
>>> 'Always' tactic.
>>>
>>
> This handler is configured to ensure that it always writes out the script
> payload (*not*) how often the script is run.
>
> (crispyboi) cloud-init % lxc exec f4 -- ls -al
> /var/lib/cloud/instance/scripts/script.sh
> -rwx------ 1 root root 30 Aug 31 15:35
> /var/lib/cloud/instance/scripts/script.sh
> (crispyboi) cloud-init % lxc exec f4 -- rm
> /var/lib/cloud/instance/scripts/script.sh
> (crispyboi) cloud-init % lxc exec f4 -- ls -al
> /var/lib/cloud/instance/scripts/script.sh
> ls: cannot access '/var/lib/cloud/instance/scripts/script.sh': No such
> file or directory
>      ..:(╯°□°)╯彡┻━━┻
> (crispyboi) cloud-init % lxc exec f4 -- reboot
> (crispyboi) cloud-init % lxc exec f4 -- cloud-init status --wait
>
> status: done
> (crispyboi) cloud-init % lxc exec f4 -- ls -al
> /var/lib/cloud/instance/scripts/script.sh
> -rwx------ 1 root root 30 Aug 31 15:36
> /var/lib/cloud/instance/scripts/script.sh
>
> Next, for frequency of script execution, the instance shell-script runner,
> is cloudinit/config/cc_scripts_user.py which has a frequency of PER_INSTANCE
> This module will invoke run-parts on /var/lib/cloud/instance/scripts once
> per instance;  cloud-init tracks this in the /var/lib/cloud/instance/sem
> directory.
>
>
>>> I'm not sure what the relationship is between /var/lib/cloud/instance/scripts
>>> and /var/lib/cloud/scripts/per-*. I have used write_files to write
>>> scripts to the per-* folders directly from a cloud_config.yaml, as per a
>>> suggestion on #cloud-init, and that indeed works. But I'm not sure how the
>>> two script folders might conflict with each other.
>>>
>>
> There isn't a conflict in the directories, but they are used differently
> and the contents are provided from different sources typically.  The
> instance path scripts did is populated only by user-data provided to the
> instance.  If you capture your instance (save a disk snapshot) and then
> launch a new instance with different user-data, then there will be a new
> instance directory with different contents.  The
> /var/lib/cloud/scripts/per-* remain and will run at the correct frequency
> independent of the user-data provided to an instance.  So if you were to
> write script into /var/lib/cloud/scripts/per-instance;  it would run once
> per instance; and if such an instance's user-data provided a script, both
> would one once-per instance.
>
>
>>> My ultimate goal is to write a very simple custom part handler, for a
>>> type I'm calling x-shellscript-per-boot, which saves to
>>> /var/lib/cloud/scripts/per-boot. And I'd like to do this so that I can
>>> deploy a per-instance script and a per-boot script in the same MIME config.
>>> which ultimately is my requirement. And I'm a little concerned I'll be
>>> mixing methods.
>>>
>>
> You want to use a cloud-boothook, which is exactly a once-per-boot
> shell-script.
>
>
>>> Thanks!
>>> Bean
>>>
>>>
>>> --
>> Mailing list: https://launchpad.net/~cloud-init
>> Post to     : cloud-init@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~cloud-init
>> More help   : https://help.launchpad.net/ListHelp
>>
>