[debian-lan-devel] Maintaining Debian LAN as a set of packages

[Andreas B. Mundt]

Hello Afif,

thanks a lot for your email and sorry for my late relply — as you
might have seen from the list, I was completely focused on getting
Debian-LAN in shape for stretch in the last days.

On Sat, Aug 06, 2016 at 12:13:24PM -0700, Afif Elghraoui wrote:
>
> I was wondering what your thoughts would be on maintaining Debian LAN as
> a set of packages, sort of like how the Debian installer is maintained.
> In the Debian LAN deployment I am helping out with at my site, I've
> slightly been customizing debian-lan-config to be this way.
>
> […]
>
> This would move many of the files and scripts out of the
> FAI configuration and into class-specific packages. We can make use of
> the debhelper plugin config-package-dev for modifying or replacing
> configuration files (while diverting the originals) provided by existing
> packages (like dhcpd.conf). A profile can be defined as a metapackage,
> which can keep machines properly configured with regular apt
> dist-upgrade/autoremove via cron.

This is a bit like the debian-edu approach, where all modification are
put in Debian packages (cf.  debian-edu-config).
Unfortunately, removing the package does not revert the changes made,
Jonas already sent some references.  The idea in Debian-LAN was to
re-implement the Debian-EDU system in a way that cuts a clear line
between policy compliant packages and all the stuff that needs to be
done to tweak the system to your needs, and do that in a maintainable
and debug-able friendly way.

> I find that a major advantage of using the package manager for
> configuration rather than the typical configuration management system is
> that it's very simple to *undo* configurations without necessarily
> having to define a reverse operation or reinstall the system.

I agree, installing and removing packages is simple and straight
forward, however, it really needs to revert all modification.  If that
is not the case, it makes developing and debuging time consuming and
boring, because the packaging comes on top of every simple
modification.

> I'm looking forward to your thoughts. I'd be happy to join the team and
> help implement this if you agree.

You are very welcome!  I am open to almost everything.  In my opinion,
it should be building on work already done as much as possible,
because development time is always scarce.  Then, it should be
flexible, because in my experience there are so many use cases and
network installations, people need to be able to modify it by simple
means.

I tried to achieve this by using FAI with its class system and the
debugging/logging features.  However, this is not how it needs to be
done.  I would like to explore ansible and its features:  You could
install a basic Debian with the Netboot PXE installer
(di-netboot-assistant, partially integrated in debian-lan for
testing/exploring) and then tune the machine into whatever you want
with ansible.  I guess this is how many systems are set up today.
Instead of relying on FAI and the nfsroot, you need to rely on the
Debian PXE images and ansible, probably a more 'mainstream' approach.

There is also Jonas' 'boxer' approach, which he better explains
himself thoroughly.

Perhaps it's also possible to use some modern techniques like union
file systems:  The 'proper' Debian is on one layer, on top all
Debian-LAN tweaks are made. To go back to the original, remove the
Debian-LAN layer.  Package upgrades are deployed in the lower layer,
configuration development happens on the top one.  Tools to detect
conflicts between the layers (a file is modified without need, because
the default changed and the like) are provided, to keep modifications
to a minimum. ("overlayroot"?).  These are just some ideas.

I suggest to continue the discussion.

So far for now, best regards,

     Andi