Closes: #2505
Tests:
- Install app on Bookworm. Web interface works. 'Special pages' page shows
'rename user' page. That page loads.
- Dist-upgrade to Trixie. Database upgrade is performed by FreedomBox service
soon after the distribution upgrade. App still works. 'Special pages' page shows
'rename user' page. That page loads.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Closes: #2498.
- Now, as soon as service starts, it will perform force upgrade operations and
post-installation app setup operations. So, it is no loner necessary to wait for
10 minutes and trigger the one of the operations with 'apt-get update'.
- In addition, the post-installation operations are triggered more explicitly
and sooner.
Tests:
- Install MediaWiki on Bookworm. Run distribution upgrade to Trixie and it
works. Log shows that post install operations were performed and mediawiki setup
was rerun.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- When service is started, check if there are any configuration file prompts
pending and perform package updates.
- When service is started, check if there are any package version updates that
require app re-run.
- These operations are done in the same thread that does app version upgrade.
All three operations don't race against each other for apt lock. On the
downside, some operations may get delayed if previous operation fails
temporarily.
Tests:
- After service starts, after 'Setup completed' message we can see messages
'Attempting to perform post-dpkg operations', 'Completed post-dpkg operations',
'Attempting to perform upgrade', and 'Completed upgrade'.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Operations triggered by FreedomBox service itself such 'apt-get update' and
'apt-get install' don't cause the package operations (post-install and
post-update) to get triggered. This is due to recent implementation of a check
with the FREEDOMBOX_INVOKED environment variable. So, it fairly safe to attempt
these operations immediately as they would have been invoked from outside.
- In one case, when unattended-upgrades is triggered it could lead to
post-install trigger getting triggered too quickly. But this only leads the
operation detecting that apt is busy and performing the long wait immediately
after.
- In case of distribution upgrade, this could mean simpler reasoning and less
wait time.
Tests:
- When a package is installed, post-dpkg operations are triggered and completed
immediately. However, another apt process immediately takes lock, this results
in a waiting period.
- When a 'apt update' is run, update operations are triggered and completed
immediately.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
samba-ad-dc package depends on winbind, which breaks FreedomBox LDAP PAM
configuration. In Debian Trixie, AD server package is required by samba
package, but is not required to run Samba file server. See also Debian
bug report 1099755.
Relates to #2498.
Tests performed:
- In Debian Bookworm, install samba, do dist-upgrade, check that
samba-ad-dc and winbind packages are not insalled and adding new user
works.
- In Debian Trixie, uninstalling and installing samba app works and
after this, adding new user works.
Signed-off-by: Veiko Aasa <veiko17@disroot.org>
- Instead of an arbitrary time decided by when FreedomBox service as started.
Tests:
- Add a log message before return statement. Set the system clock to 02:00 and
start service in debug mode. Wait for 3 minutes. The timer is triggered but
nothings happens.
- Set the system clock to 06:10 and start service in debug mode. Wait for 3
minutes and a distribution upgrade check is performed and a message is printed.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Show a notification 60 days, 30 days, 1 week, and 1 day before distribution
upgrade. If a notification is dismissed for any of these periods don't show
again until new period starts. Override any previous notification.
- Show a notification just before the distribution upgrade showing that the
process has started. Override any previous notification.
- Show a notification after the distribution upgrade is completed that it is
done. Override any previous notification. Keep this until it is 60 days before
next distribution upgrade. If user dismisses the notification, don't show it
again.
Tests:
- Start a bookworm VM.
- Disable the auto updates. Set the date to 2025-08-01. Start the service.
Notification is not shown when distribution check is done. Enable auto updates.
- Set the date to 2025-07-01. Start the service. No notification is shown after
distribution upgrade check is run.
- Set the date to 2025-08-01. Start the service. Notification is shown when
distribution check is done. Clicking on the 'Go to Distribution Update' takes to
distribution update page.
- Set the date to 2025-08-02. Start the service. Notification is not updated
when distribution check is done. Dismiss the notification.
- Set the date to 2025-08-03. Start the service. Notification is not shown when
distribution check is done.
- Set the date to 2025-08-22. Start the service. Notification is shown when
distribution check is done. Dismiss the notification.
- Set the date to 2025-08-23. Start the service. Notification is not shown when
distribution check is done.
- Set the date to 2025-09-15. Start the service. Notification is shown when
distribution check is done.
- Set the date to 2025-09-18 18:00. Start the service. Notification is shown
when distribution check is done.
- Set the date to 2025-09-19 18:00. Start the service. Notification is shown
that distribution update has started. Distribution upgrade has started. Dismiss
this notification. Upgrade does not succeed to due timestamp miss matches with
release file.
- Once the distribution upgrade has started. Start the service. Notification is
not shown when distribution check is done.
- Rollback to a snapshot before distribution upgrade. Start the distribution
upgrade manually and notice that notification is not shown when distribution
check is done.
- Once the distribution upgrade has completed, start the service. Notification
is shown the distribution upgrade has completed when distribution check is done.
Dismiss this notification.
- Restart the service. Notification is not shown when distribution check is
done.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- This is important because only if all the command succeed, the changes to
/etc/apt/sources.list file are committed.
Tests:
- Set the time to 2025-09-20. Distribution updates are triggered. 'apt update'
fails due an mismatch with release file's timestamp. Instead of proceeding, the
distribution upgrade is halted.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- This will help identify these snapshots more easily in case a revert it
needed.
Tests:
- Start a distribution upgrade. Notice that the snapshot taken has special
description that it was taken before a distribution upgrade.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Refer to the manual and mention that users can keep their distribution for 5
years before upgrade.
Tests:
- Proofread, links work.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Closes: #2090
- Create a new page for distribution upgrade.
- If distribution upgrade is running show its status here without any other UI.
- Show various conditions for not allowing distribution upgrades.
- Automatic updates disabled
- Distribution updates disabled
- Not enough free space.
- Unknown or mixed distribution in sources.list.
- If distribution upgrade was interrupted, show that information here and allow
triggering distribution upgrade again. This is detected by noticing that
codename in base-files is higher than one detected in sources.list.
- If the user is not testing/unstable, show a message and don't allow
triggering.
- If next stable has not been released, don't auto-upgrade but allow manual
upgrade. Show special warnings.
- If next stable has been released but only recently, don't auto-upgrade but
allow manual upgrade.
- If next stable has been released and it has been 30 days, allow auto-upgrade
and manual upgrade.
- Seek confirmation before triggering manual upgrade. Provide appropriate
advice.
- Rely on hard-coded list of releases and their release dates instead of
querying the server.
Tests:
- When automatic updates or distribution updates are disabled, an alert message
is shown distribution upgrade page. If both are disabled, both messages show up
in the alert. The start distribution upgrade button is disabled. Clicking on the
button does not work.
- Reducing the available free disk space will cause alert message to show up and
start upgrade button to be disabled.
- When the distribution in /etc/apt/sources.list is mixed or unknown, an alert
message is shown. the start distribution upgrade button is disabled.
- When the distribution in /etc/apt/sources.list is testing or unstable, an
alert message is shown "You are on a rolling release distribution...". the start
distribution upgrade button is disabled. The current distribution is
'None (testing)' or 'None (unstable)'. Next stable distribution is Unknown.
- If get_current_release is hard-coded to return (None, 'trixie'). Then a
message is show in the distribution update page 'A previous run of distribution
update may have been interrupted. Please re-run the distribution update.' A
'Continue Distribution Update' button is shown in warning color. The button
takes to confirm page where the confirm button is shown in blue and is enabled.
- On a bookworm VM, visiting the page shows the message "You are on the latest
stable distribution...". Upgrade button shows in red. Clicking it takes to
confirmation page. The page shows a warning alert and red confirmation button.
- Setting the clock to '2025-08-21' shows the message "A new stable distribution
is available. Your FreedomBox will be update automatically in 4 weeks...".
Upgrade button shows in blue. Clicking it takes to confirmation page. The page
does show warning. The button is in blue.
- Setting the clock to '2025-09-30' shows the message "A new status distribution
is available. Your FreedomBox will be updated automatically soon...". Upgrade
button shows in blue. Clicking it takes to confirmation page. The page does show
warning. The button is in blue.
- Clicking the confirmation button starts the distribution upgrade process. This
distribution upgrade page is shown. The page shows spinner with a message and no
other UI. Page is refreshed every 3 seconds. When the distribution upgrade
process is completed, the page shows the current status.
- Killing the apt-get process during distribution upgrade stop the page refresh.
The page shows that process was interrupted and also continuation. Clicking on
the confirmation button resumes the distribution upgrade process.
- After distribution upgrade, the page shows the current distribution and next
distribution properly. There is not release date for the next distribution. A
message shows: "Next stable distribution is not available yet."
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- From the default 90 seconds (system-wide). This is better when systems are
slow during bootup or have really slow disk IO.
Tests:
- When running 'systemctl start plinth' add a sleep of 120 seconds in main
before notification. The service stays in 'activating' state for 2 minutes but
then succeeds and becomes active.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Run as a Type=notify service with systemd service.
- Notify systemd just before blocking in the main thread.
- This allows systemd to catch any errors with startup of the service and log
appropriately. This also allows clients depending on making DBus calls etc. to
know that service is ready to serve requests.
- This will increase the boot time slightly as systemd will wait until
FreedomBox service to become active.
Tests:
- Raise an exception in main() during startup. Run 'systemctl start plinth'. No
error is thrown without this patch. With the patch, an error is shown.
- After 'systemctl start plinth', service shows in 'active' state.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- This allows for the service to become "ready" and serving web connection sooner.
- If some operations such as obtaining certificates and domain configurations
are happening, these can be shown as operations with UI notifications.
Tests:
- Running 'freedombox-develop --setup' works. 'App initialization completed'
message is printed before 'Running setup...' message. Process exits
successfully.
- Running 'freedombox-develop --setup-no-install' works. 'App initialization
completed' message is printed before 'Running setup...' message. Process exits
successfully.
- Running 'freedombox-develop' works. 'App initialization completed' message is
printed before 'Running regular setup' and 'Setup finished'. Cherrypy starts
listening before 'App initialization completed' message.
- Running a fresh VM setup works.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- 12 hours might genuinely not enough with SD cards, slow download speeds, and
large number of packages (due to apps such as GNOME).
Tests:
- None
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Closes: #2501
Tests:
- Install radicale app.
- Install a sample package using apt. Trigger will be run and but will
not result in radicale setup rerun.
- Make newer radicale available. This can be done by enabling testing
distribution but setting its priority low. radicale priority from testing will
be set to high. When unattened-upgrades is run, it will trigger the FreedomBox
mechanism and will result in database upgrade.
- After this install a sample package using apt. Trigger will be run but will
not result in radicale setup rerun.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
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>
