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

[Afif Elghraoui]

Hi, Andi,

على الجمعـة 12 آب 2016 ‫04:22، كتب 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.

No problem.

> 
> 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. 

I haven't looked into debian-edu, but I've found it rather
straightforward to make packages to easily undo the configuration
changes they make upon removal. I imagine problems could come up if
someone edits a diverted configuration file, but I think manually
editing configurations on a production system is a bad idea regardless.

> 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.

Of course. That is part of the reason we're having this conversation.
Otherwise, I would have gone off and started a fork already. :)

>  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.

Agreed. I thought with a set of packages, the default configuration is
provided as a set of packages implementing the configuration you have
now. Anyone intending to change a certain aspect can change the package
source (without needing to make a new one). If new functionality is
desired, they could make a new package, but configuration packages are
very simple and development overhead would be reduced with good templates.

> 
> 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.
> 

While it is more mainstream, it always seemed to me that the popular
configuration management systems are reinventing package management, but
for configuration. I'm not aware of any simple undo capability for them
either (one that doesn't involve manually defining a reverse operation
for every forward operation).

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

I've read a bit about this previously, but I don't think it fit in with
an FAI-based approach (which the package framework I'm proposing could
still use).

> 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 think this is somewhat similar to installing/uninstalling packages,
but if there were more granular layers rather than one for the entire
Debian LAN configuration. I'm also not sure we should need extra tools
to the job of VCS.

> I suggest to continue the discussion.
> 

I've previously explored some different options, including most of the
ones you named. Only the unionfs idea was admittedly new to me, but I
still think that using the package manager to distribute files and
configurations is the most natural approach.

I'm planning to make a proof-of-concept set of configuration packages
implementing a subset of current Debian LAN functionality.

Many thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name