Fixes: #2119
Tests:
- Install mediawiki app.
- Install a sample package using apt. Trigger will be run and but will
not result in Mediawiki setup rerun.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Closes: #1447
Find and rerun setup for apps after a dpkg operation is completed.
This is needed in a couple of situations:
1) Some Debian packages don't manage the database used by the package. When
these packages are updated, their database schema is left at an older version
and service might become unavailable. FreedomBox can perform the database schema
upgrade. However, FreedomBox needs to know when a package has been updated so
that database schema can be upgraded.
2) A package is installed but FreedomBox has not modified its configuration.
Newer version of package becomes available with a new configuration file. Since
the original configuration file has not changed at all, the new configuration
file overwrites the old one and unattended-upgrades deals with this case. Now,
say, the configuration file modifies some defaults that FreedomBox expects
things might break. In this case, FreedomBox can apply the require configuration
changes but it needs to notified as soon as the package has been updated.
When apt runs dpkg, after the operation is completed it triggers commands listed
under the configuration 'Dpkg::Post-Invoke'. This in turn calls this class via a
DBus notification. Here, we iterate through all the apps. If an app is currently
installed and interested in rerunning setup after dpkg operations, then its
setup is rerun. Interest is expressed using the 'rerun_setup_on_upgrade' flag on
the Package() component. If all packages of the app have not be upgraded since
the last check, we skip the operation.
Tests:
- When an app is installed from FreedomBox, the trigger is not run.
- When a package is installed from command line with apt, the trigger is run. It
does nothing.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- We have a hook that triggers when 'apt update' is successfully run. This hook
handles the force upgrading mechanism. It's intended purpose is to handle
packages with configuration file prompts that unattended-upgrades does not
touch. 'apt update' is run on behalf of unattended-upgrades every day on a
schedule. This is the primary time the hook is intended to run. However, the
hook also run every time FreedomBox runs 'apt update' before installing an app.
Also no operations are performed, there is a race to see of apt is available for
the operation.
- Avoid these unnecessary runs by setting an environmental variable and by
checking it before running the trigger.
- There is one place where we want to genuinely run the trigger. That is after a
distribution upgrade. Handle this case.
Tests:
- When apt update is run on the command line, the hook is triggered.
- When installing an app, however, the hook is not triggered.
- During a dist-upgrade, the hook is triggered at the end.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Although there are no issues with kiwix like for calibre, it is the right way to
do this.
Tests:
- Without patch, restore the app on testing from a backup on stable machine and
notice that the data folder is owned by nobody:nogroup but files inside are
owned by a kiwix-server-freedombox user and group. This is not ideal.
- With patch, restore again notice that the library is accessible and all the
files are owned by nobody:nogroup.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Fixes: #2500.
systemd 257 has introduced in which DynamicUser= services will use id-mapped
mounts[1] instead of performing chown on the entire data directory. On Debian
stable release, calibre service will contain data folders with a dynamic user
ownership while on testing release, calibre service will contain data folders
with nobody:nogroup ownership.
When a backup from stable release is restored on testing release, the two
directories are merged. The top level directory will be still owned by
nobody:nogroup while the files instead will be owned by dynamic user and group.
In this case, systemd will not recursively update the ownership. Calibre will
fail to access the library files.
The fix is to completely wipe the existing data folder before a restore. When
systemd notices that the directory ownership is not properly it will recursively
change the ownership before starting the service.
Links:
1) https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#RuntimeDirectory=
Tests:
- Without patch, restore the app on testing from a backup on stable machine and
notice that the data folder is owned by nobody:nogroup but files inside are
owned by a calibre-server-freedombox user and group. This leads to failure when
accessing the library.
- With patch, restore again notice that the library is accessible and all the
files are owned by nobody:nogroup.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Many times, merging old and new data folders is not ideal and could lead to
unexpected outcomes. Perhaps removing all the backup folders and files before
restore is ideal. However, this patch tries to introduce that approach slowly on
an experimental basis.
Tests:
- Unit tests work.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
