-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Execute external script(s) on firstboot #44
Conversation
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. |
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
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. |
Ok this can be closed I suppose and rethinked? |
We can leave this open and discuss here as well, what do you prefer? |
Ok we can do that also. This is needed feature for me. |
I created a wiki page to collect ideas: https://github.com/openSUSE/jeos-firstboot/wiki/Support-for-extensions-using-custom-scripts |
I could be all wrong but should it be something like this (I'll draft this on wiki after this if needed):
|
Yeah, using hook functions is probably the best approach here. I'm thinking about something like:
|
Ok now we are talking about serious BASH wizarding 👍. How do to write that in Wiki? |
I added some ideas to the page - if you have anything else, just add it. |
I made changes to have more advanced version of script launching. It should more like what has risen in this discussion and wiki page. |
…tion code to fit with review
…ocal and correctly handle functions errornous exit
Now should be reviews updated |
Looking good so far (except the broken I guess we should define the format arguments can be supplied to systemd firstboot as a global |
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? |
Yes, that would be a good example and testcase. |
Ok I turned WIFI to script. I have to make RPM from this that I can test it on image. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good so far, just some cleanups in the first module missing.
It would work fine already, but as the first user of this functionality will serve as an example, it should be a good one IMO.
config_wireless=true | ||
fi | ||
fi | ||
if [ "$config_wireless" = "true" ]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The whole "if" can be moved one layer up, like this:
if foo; then
bar;
fi
to
foo || return
bar
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that it's working as expected. Should there be some == or something to make sure it's working before ||
Can you also add some short comments on each hook implementation in the module, e.g.
|
run mv -f $config_file /etc/sysconfig/network/ifcfg-$wlan_device | ||
} | ||
|
||
# This is called by jeos-firstboot for user |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope for comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup - the comment for _post
should be different than the one for _systemd_firstboot
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok now there is very cryptic comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment doesn't make much sense. What about
# This is called after the configuration steps finished successfully
Almost there! Next week @gmoro is back and will have a look as well. |
Hopefully. This has been serious lesson of Bash-fu. I though I knew something but learning is good thing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, except for the comment.
Just a heads up: #46 would cause a conflict with this PR as it makes the raspberrywifi_post
function unnecessary. So depending in which order the PRs are merged, it might need a rebase.
run mv -f $config_file /etc/sysconfig/network/ifcfg-$wlan_device | ||
} | ||
|
||
# This is called by jeos-firstboot for user |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment doesn't make much sense. What about
# This is called after the configuration steps finished successfully
I'll rebase if needed |
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. |
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 |
Even better. I agree. |
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? |
can't really spend time reviewing this atm but this clearly goes into a directory of systemd style handling of services. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
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.