evebox - pre and post upgrade scripts #1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The idea here is to do the best thing for the user. With EveBox,
if the user choosed to install the maintainers configuration files,
it will be wide open on port 5636. This is not what we want with
SELKS, instead we want to lock it down to localhost so we get
the authentication provided by SELKS/Scirius.
So instead, include a copy of the desired /etc/default/evebox
file in this package and make sure it gets installed after
EveBox is upgraded. EveBox is also upgraded in its own step
with options to prevent any prompting about configuration files.
Additonally, use this as an opportunity to replace the EveBox
repo with that of the stable version, which I believe has hit
a state where it might make more sense to use, rather than the
one built directly from git master on each commit.
I'd like to think the idea here can be extended to other packages to take less decision making away from the end user.
There is however a chicken and egg problem - how do you introduce new logic into an upgrade. One solution is the double upgrade. The first upgrade might get a new version of this package. Running it again applies new logic. The second is break out the "post" logic into a second script that is run after the upgrade is complete?