[Userops] Freedombox/UserOps cross post

[Olivier Mehani]

Hi,

This is my first real post to both the UserOps
<address@hidden>, and the FreedomBox
<address@hidden> MLs. Going against all
etiquette, this is a cross post. Apologies for that.

The reason I did it is that I think both projects have a very
complementary overlap. In my view, the UserOps effort looks at making
self-hosted applications easily manageable to the not-so-techie, while
the FreedomBox project aims at providing a standard (Debian) base for
self-hosting (I see this as an appliance).

The overlap is, pretty obviously, on installation and management of
third-party-ish applications. I strongly suggest that you, like me,
follow both discussions (:

Now for some opinions. In both lists, I have seen an effort towards
packaging everything cleanly using the distribution's native packaging
tools. While I whole-heartedly agree as a sysadmin who kinda knows what
I am doing, I'm not certain this is the best way from an appliance
perspective for a userop.

The reason is that there is too much co-dependency between the base OS,
and the applications: upgrading the base OS might force incompatible
upgrades, or applications updates might require an undesirable (for some
reason) OS upgrade.

As such I wonder if a lightweight container approach wouldn't be a
better way to get the best of both worlds. I would separate the base OS
(immutable) from the applications (mutable list of immutable code and
dependencies), and add a layer of configuration storage (mutable data)
[add to this some actual data storage somewhere else, but I'll skip on
that for now].  I have in mind the OpenELEC project, which provides
self-updating images of the base OS, but retains (or migrates)
configurations across upgrades.  Freedombox could be the OS and provide
the configuration layer. So we're left with having to find a practical
way to package the applications.

Had Debian gone the way of ArchLinux (that I know of), I guess we could
have decoupled the system in / from the userop-installed applications in
/usr. That not being the case, I think that perhaps something like
extracting a vanilla package to an alternate root (on a separate, non
upgradable partition), and the stow(1)ing it into the system might be a
functional approach (the list of these packages would be tracked
separately, and they would have to be restowed on each OS image
upgrade).

What is an application? I am torn between the package itself, or the
package and all its dependencies. I'd rather avoid duplicating copies of
the same dependency-version.  I like the practicality of Docker images,
but I don't think their opacity to the base OS is a good thing in this
case (or at all; i.e., I don't think 10 Docker images with 10
shellshocked bashes is a good situation to be in; I hear Sandstorm.io's
approach might be better, but I haven't played with that yet), but there
is a need to pin dependencies to a known working version (or at least a
range of known versions). This is likely to lead to having to install
multiple versions in parallel.  This might cause issues when stowing
them into the system (maybe update-alternatives can help there).

In the best case scenario, we would just install one binary package per
needed versions, regardless of how many applications need it (à la Ruby
Gem or maybe Guix). Maybe chroots with could be created for each
applications, with their dependencies stowed in (though we would need
hard links), to offer more separation of concerns.

All this to say, I think it is important to have a separation between
the base self-hosting OS image and---dare I say it?---the apps (and
dependencies) running on top, and potentially managed separately (e.g.,
not necessarily packaged and provided by the same people as the OS). At
the end of the day, I think the key question is

    Where does the base OS finish, and where do the applications and
    dependencies start?

I am not certain yet. I'd say not much more than a Debian minbase plus
network configuration, as well as the container and configuration store
logics for the base OS---but I might revise my judgement. As for the
applications, vanilla Debian packaging seems just too inflexible there,
but there might be ways to work around it without reimplementing the
wheel.

Comments? Questions?

Thanks for your time in reading my rants (:

-- 
Olivier Mehani <address@hidden>
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE  F5F9 F012 A6E2 98C6 6655
Confidentiality cannot be guaranteed on emails sent or received unencrypted.

pgpSDidcHeYtr.pgp
Description: PGP signature