Overall Impressions
List of things you liked
- The project’s goals
-
apt install freedomboxand it’s working! - Backups
- Neat UI
List of things you disliked
- Would love to see backups for SAMBA [1]
- Without
DEBIAN_FRONTEND=noninteractive, it was not clear to me the implications of several questions during the installation. - I found some issues after installation on a fresh Bullseye RC3. I’m describing them below. Let me know if you want me to fill in a bug report elsewhere.
Incorrect btrfs option in fstab caused the boot sequence to halt
Summary
The automatic FreedomBox installer used subvol=.snapshot to identify the subvolume, but that didn’t work.
Description
UUID=44539a99-4cf0-456b-b4ec-5e94139e8f63 /.snapshots btrfs subvol=.snapshots 0 1
Proposed Solution
Using the subvolid seemed to work:
UUID=44539a99-4cf0-456b-b4ec-5e94139e8f63 /.snapshots btrfs subvolid=260 0 1
Cockpit origins not properly configured
Summary
After installation, access to Cockpit was forbidden…
Description
Proposed Solution
Add more origins to /etc/cockpit/cockpit.conf:
Origins=https://freedombox https://freedombox.ewlan.es https://freedombox.local https://localhost https://localhost:4430
Change of external SSH backup server fingerprint made any backup configuration involving that server to fail
Summary
If an external SSH backup server changes its fingerprint, any attempt to configure backups targeting that host fails. The UI shows an error message (don’t remember which, possibly it was a warning about the fingerprint mismatch) and a success message stating that the fingerprint was correctly stored. Both messages at the same time.
Trying to modify, or create new backup targets involving that host failed with an error and success message.
This is a very exceptional situation, since servers should not change fingerprints frequently. But if it happens, it doesn’t seem possible to update the known host from the UI.
Description
Sequence:
- I configured a backup target in FreedomBox.
- The SSH server changes fingerprint.
- It is no longer possible to configure backups targeting that server from FreedomBox UI.
Proposed Solution
I had to manually remove the host from plinth’s known_hosts file.
Either the backup application or plinth logic should be reviewed in order to cover this situation.
Corrupted datagrams during Borgbackup transfer
Summary
This is probably more a problem in my hardware than a FreedomBox issue. However, it might be interesting if FreedomBox could detect this kind of issues or even set a “safe” default for network interfaces.
During a Borgbackup data transfer, the SSH connection was dropped by the server because of integrity issues.
Description
SSH connection at client side stalled (forever).
Logs at SSH server shown the following message:
ssh_dispatch_run_fatal: Connection from user <U> port <P>: message authentication code incorrect
Proposed Solution
Switching off hardware offloading solved the issue:
ethtool -K enp1s0 rx off tx off