Looking into this old thread which compares YunoHost with FreedomBox, and this new thread which asks for support for Sandstorm within FreedomBox got me thinking on what this project could do to offer what users expect from it.
I think a big point of pain in the FreedomBox project is that it overvalues the Debian packaging on projects where it’s not needed for stability of the system. While YunoHost and Sandstorm work mostly as “easy web-based applications installers” FreedomBox historically has shined more on services that are not web-based, precisely because of the requirement of packaging… web services usually are manually installed (not packaged) on top of the Debian system. Being a FreedomBox user for a couple years, I’ve always found frustrating that there’s no way to easily install web applications that really don’t require a package for its installation. I’d love to be able to easily install Mastodon, PeerTube or other alternatives to “cloud services” on my FreedomBox, which I think is the whole (or at least a big) point of the project.
I’d love to see an initiative on FreedomBox that allows for easy installation of such services, specially if those don’t require much more than an interpreter (such as PHP, Python, Ruby or Node) and other packages already available on Debian. I could contribute with code for such project if you are interested.
We have discussed the possibility of allowing users to install containerized web apps by providing a generic feature in FreedomBox. This could, for example, take the form of a new app in FreedomBox that would manage docker containers. Such feature can be provided as-is without any promises for security updates, privacy, etc. There are some disadvantages with this approach though:
Security updates will need to come from upstream of the container. This does not always happen (especially for bundled libraries, etc.).
User may inadvertently install a privacy violating app. These is just too common now a days. For example, a web page can include code from third-party servers allowing those servers to spy on all the visitors to a FreedomBox app.
User could inadvertently install proprietary software (or free software bundled with proprietary libraries/data).
Many times, these containers come with their own database server, web server, lets encrypt setup etc. At best these are a poor use of limited resources on SBCs and at worst conflicting with functions of FreedomBox.
Features that FreedomBox usually tries to provide on its apps such as backup/restore, single sign-on, shared user accounts, etc. may be harder to implement (especially if the implementation has to be generic over all apps).
Despite these limitations, I believe, there might be interesting apps that might make sense with this approach. Having a tight focus on a set of apps for which this feature will be useful allows us to have a better conversation around it. For example, we discussed (and somewhat explored?) it for NextCloud.
We can take the next steps by: identifying an app (or apps), picking on a technology (docker, snap, etc.) and doing some experimentation.
I need to dedicate some time to suggest a proper approach, but I’ll try to address your concerns.
Regarding security updates, we could fix versions to specific commits and make easy for users to keep an eye on projects codebases, so they can report updates. Deprecate packages not properly maintained.
Don’t provide installation for known privacy/freedom violating applications. Respect DFSG.
Don’t use pre-baked containers, instead use an approach specifically designed for FreedomBox/Debian. Use the same database/letsencrypt/webserver for everything.
IDK if the best approach for this scenario (focus on SBC) would be to use something as heavy as Docker, probably an approach like the one of Firejail would be a better suit but I don’t use Firejail so I would need to investigate. Even not using os-level isolation could be fine if we use different users for each application (I’d like that you debate me on this though).
Great to see you are open to this kind of suggestions! I’ll be back with more within a week or so.
In my understanding, packaging is what makes the installation of software easy. Saying that an application “does not require a package” is a rather strange way to say that no one made the work for packaging.
If by “web-based application” you mean webpages that will tell one’s web browser to dynamically download and execute code, bypassing the way that executable code is normally installed and updated on one’s computer, this is rather what I would avoid.
But of course, if it works with Javascript disabled in the web browser, or if it can be accessed with a software client that is packaged, then it is fine.
Yes, some form of “packaging” (or automated setup) is needed, but usually this kind of applications are not a good candidate for packaging on Debian because web-based applications setups involve a ton of decisions based on how your specific server architecture is. A package would end up being too opinionated, and not useful as a general-use package. For instance, what should u use, Nginx, Apache or Caddy? should you support a domain or subdomain, if so, how to handle DNS? which database backend to use? How should we handle repetitve tasks, crontab or systemd? how should we isolate applications? Apart from the fact that a ton of web applications update frequently and that doesn’t help with the idea of packaging for Debian neither. All of this results in not having a lot of packages for web applications on Debian.
I’ve seen FreedomBox uses backports for some things, so probably that’s the way to go.
I’d really like to see the following projects available on FreedomBox:
Pi-hole
PeerTube
Mastodon
And probably alternative backends for equivalent “cloud” spyware: CloudTube and Nitter.
I’m preparing a course on communitary infrastructures, so I’m willing to work on that, but I’m not sure if the efforts will end up on improving FreedomBox for everyone. Which steps should I take to make this happen?
My understanding is that the Freedombox project is first aimed at individual users rather than communities. For example, the Pioneer box resources are very limited.
Did you try YunoHost? (I did not, I feel more comfortable with the Debian-style things).
We have had some success with deploying with Pioneer like hardware for villages in India. Apps like mumble perform quite well even on limited hardware. I suppose that all the self-hosting projects will perform more-or-less similarly when the hardware is the same. One can always choose more capable hardware like RockPro64, Raspberry Pi 4 or even x86 desktop/servers if the need arises for communities.
The current arrangement for Debian and FreedomBox work nicely. Debian packages are not opinionated. They provide configuration file for Apache and Nginx (or some or none of them) but don’t enable the configuration automatically. They configure database using dbconfig framework and usually work with the all the databases supported by upstream package.
Then FreedomBox makes the opinionated decisions by making assumptions about the type of deployment, namely, home server. Apache for web server, LE for certs, etc. are chosen. Configuration and glue is provided here.
I am very glad to hear this. Not sure if you have already started some work, but I wanted to provide some advice on how to go about this. Pick a path:
Create a proper Debian package. This has many advantages and is more suitable for long term sustainability. This involves more work though. Our team can help you with
Explore ways to deploy using containers. In this approach, just reuse (or create) container package created by the upstream software. Most of the packaging effort is eliminated. However, you need work on the pain points of how LetsEncrypt, Apache, database, backups, etc. work with the container.