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

[Andreas B. Mundt]

Hi Afif,

On Fri, Aug 12, 2016 at 11:23:21PM -0700, Afif Elghraoui wrote:
> على الجمعـة 12 آب 2016 ‫04:22، كتب Andreas B. Mundt:

[…]

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

OK, sounds good.

[…]

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

But that means, even for a minimal modification or a test, the package
needs to be built again, right?

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

This morning, I read a bit about the 'history' of the problem, starting
with some links Jonas' provided, and I had a quick look at Debathena
and the config-package-dev package.  I am currently not sure how to
continue best, and as I am in the process of moving to another
country, time is limited on my side.  My focus for the next months
will lie on fixing the current Debian-LAN for stretch.  However, I
appreciate your ideas very much.  Please keep us up to date with
thoughts and results you encounter during the proof-of-concept.

Best regards,

     Andi