provide a way to run raw shell commands post install.

[steverweber]

validate_postnonchroot_template is limiting what can run to only script files that can be found on the filesystem. this is painful when trying to performing some custom commands after a pxe boot install. I'm
forced to change the initrd to hack in some script.. would be much cleaner and direct if the shell commands could be included in the ister.json.

it would be helpful if validate_postnonchroot_template did no checks at all or another option like PostNonChrootRaw was added.

running raw commands would be nice.

"PostNonChroot": ["bash -c 'mkdir -p $0/usr/local/maintenance; cd $0/usr/local/maintenance; curl https://xxxxxx.com/linux/postinstall.tar.gz | tar -xz'"]

[steverweber]

even with validate_postnonchroot_template disabled i'll git issues with how the command is split on space.

So I think it would be best to add a new option: PostChrootBashCmds

and have code like:

PostChrootBashCmds = ['echo hello', 'curl http://ascript | sh']
with ChrootOpen(target_dir) as _:
    for cmd in PostChrootBashCmds:
        subprocess.call(['/bin/bash', '-c', cmd])

[bryteise]

So do you want a non-chroot and chroot version of this post install shell command runner?

Also giving the shell commands the chroot location in an environment variable seems like the best way to go in the non-chroot case, is that fitting with your use case?

[steverweber]

I think the chroot version is more helpfull but having the none chroot version would be a nice extra.

agree passing in the chroot path as an env var is the way to go.

If you do go to add these. Perhaps also add a PreBashCmds. This would allow some way to shim in support for odd things like perhaps raid drivers.

[bryteise]

I have code working for the both chroot and non-chroot post handlers. I'm curious when exactly you'd like the pre handlers to be run though. I'd guess you'd get the most flexability from having them run directly after template validation but that could be too early. From my perspective having commands run after validation and before any actual processing would be enough to support raid. Any more details for your use case would be handy here.

[steverweber]

I didn't have a true use case for the pre command.

debian has something like this d-i preseed/early_command it runes before the partitioner, so after validation should be a good place.

[bryteise]

@steverweber #105 created in response to this issue.