Execute external script(s) on firstboot

[illuusio]

As in Issue #4 states: There should be way to execute external scripts. This is bit naive way to achieve that goal but should be enough for most cases.

[Vogtinator]

That's indeed a naive way, those scripts aren't run at all if firstboot is run in dry-run mode.

This addition would be a externally visible API, so IMO we should make it slightly more refined before making it available.

[illuusio]

Yes but nothing is run in dry-run? So I though that would be as it should :dancer:. Just curious what do you mean visible externally visible API? Do you meand SELinux?

[Vogtinator]

Yes but nothing is run in dry-run? So I though that would be as it should.

Not quite right - it still shows dialogs and computes the commands, even if they're not executed. That makes it possible to test it without making changes to the running system.

IMO something like this should be implemented by sourcing (instead of executing) files in the specified directories (I'd say /etc/jeos-firstboot in addition as well, for custom scripts not in official packages). That would need to be documented, along with all variables and functions the scripts can use (like run and d).

Just curious what do you mean visible externally visible API? Do you meand SELinux?

If jeos-firstboot calls external scripts, that's an API. jeos-firstboot changes in the future shouldn't break those scripts in a backwards-incompatible way.

[illuusio]

Ok this can be closed I suppose and rethinked?

[Vogtinator]

We can leave this open and discuss here as well, what do you prefer?

[illuusio]

Ok we can do that also. This is needed feature for me.

[Vogtinator]

I created a wiki page to collect ideas: https://github.com/openSUSE/jeos-firstboot/wiki/Support-for-extensions-using-custom-scripts

[illuusio]

I could be all wrong but should it be something like this (I'll draft this on wiki after this if needed):

• Source script with --dry if needed (i.e . script --dry) or have global variable for this. Because they are sources they should allow using function d, run and others.
• If script returns 0 it's success and 1 if not. Should everything be stopped after error?
• There could be need for functions like (Names can be anything): before(), execute() and after(). These could be called from master script and not just trust it will be executed or is just KISS exceute script and be happy.
• Could they return new global variables?

[Vogtinator]

Yeah, using hook functions is probably the best approach here.

I'm thinking about something like:

# Load all available modules
pushd /usr/share/jeos-firstboot
for module in *; do
    source $module && modules+=("$module")
done
popd

...
# Run all systemd_firstboot hooks
for module in "${module[@]}"; do
    [ $(type -f "${module}_systemd_firstboot") = "function" ] || continue
    "${module}_systemd_firstboot"
done

[illuusio]

Ok now we are talking about serious BASH wizarding :+1:. How do to write that in Wiki?

[Vogtinator]

I added some ideas to the page - if you have anything else, just add it.

[illuusio]

I made changes to have more advanced version of script launching. It should more like what has risen in this discussion and wiki page.

[illuusio]

Now should be reviews updated

[Vogtinator]

Looking good so far (except the broken || true now), so only actually defining and using hooks needs to be done.

I guess we should define the format arguments can be supplied to systemd firstboot as a global systemd_firstboot_args variable directly.

[illuusio]

All global variables should be available because they are run under main script? Should I turn that WIFI stuff as a script for a test so this can be evaluated to work?

[Vogtinator]

Should I turn that WIFI stuff as a script for a test so this can be evaluated to work?

Yes, that would be a good example and testcase.

[illuusio]

Ok I turned WIFI to script. I have to make RPM from this that I can test it on image.

[illuusio]

Now it does make snapper after scripts as it should be?

[illuusio]

I reverted stuff and done it (hopefully) as expected

[Vogtinator]

Can you also add some short comments on each hook implementation in the module, e.g.

# This is called by jeos-firstboot for user interaction and access to the global systemd_firstboot_args array
raspberrywifi_systemd_firstboot() {
...
}

[Vogtinator]

Almost there! Next week @gmoro is back and will have a look as well.

[illuusio]

Hopefully. This has been serious lesson of Bash-fu. I though I knew something but learning is good thing.

[illuusio]

I'll rebase if needed

[aplanas]

I like this one!

Is there a plan to provide a list of snippets that can be skipped? In that way we can refactor jeos-firstboot in pieces, living in /usr/share/jeos-firstboot, and using some env variable tailor the list of snippets that will be executed.

Another option is to have some enabled.d directory, with links to the snippets that will be executed. The initial RPM can enable a selection of them, and later via config.sh we can change the final list.

[Vogtinator]

I'd prefer if every module was split into a package with proper dependencies (e.g. WLAN configuration needs wifi tools) and only those modules actually used are installed. config.sh could remove modules it doesn't need.

Having a configuration file referenced via EnvironmentFile=-/etc/jeos-firstboot.conf would work as well, it would also allow setting some of the other exposed options.

[aplanas]

Having a configuration file referenced via EnvironmentFile=-/etc/jeos-firstboot.conf would work as well, it would also allow setting some of the other exposed options.

Even better. I agree.

[illuusio]

So should that /etc/jeos-firstboot.conf contain enviromental variables which are read on systemd startup? Would it be just like JEOS_FIRSTBOOS_SCRIPTS="script1.sh script2.sh" or something fancier?

[lnussel]

can't really spend time reviewing this atm but this clearly goes into a directory of systemd style handling of services.