On 15/01/07, Tzafrir Cohen <[EMAIL PROTECTED]> wrote:
Actually you just need to provide a set of packages for each host. That
nicely fits into data that is handled by gmake (space-separated lists)
and thus debian/rules can handle it well. You do need to automate the
generation of debian/control, which is a policy violation, but I figure
you'll live with that one.
Thanks.
What about configuration AFTER the packages get installed? e.g. setting up
/etc/network/interfaces, syncing it with the central configuration when an
interface is added/changed/removed, adding extra users, adding ssh keys for
users, REMOVING these users and their ssh keys when they are no longer
configured to access the system, configuring postfix etc. - is preseed the
way to go?
Use svn-buildpackage to build from a loca svn repo.
Yes I forgot about it. Thanks for reminding me.
I had something similar working nicely (building requirements list using
substvars, though with a fixed set of packages). Generally the basic set
of requirements was in a simple packages lists file. debian/rules
pre-processed it.
And how did you get the host-specific configuration in?
Right now I envision that I'll need a set of scripts to be available to
postinst/.preinst etc. files to use to tweak files, some of them can use
existing Debian tools (debconf? update-rc.d?) and some will have to complete
the holes where it's not available to do that from command line (e.g. change
/etc/inittab).
The center of these scripts might be some xml-diff algorithm (google found
tons of them) that will compare the "existing" system config with the new
one from the new host-specific meta-package version and modify the system to
bring it into line with the new config.
For instance:
<host id="mail24">
<network>
<interface id="eth0">
<ip4-addr>1.2.3.4</ip4-addr>
...
</interface>
<interface id="eth0:1">
...
</interface>
</network>
</host>
Imagine that after the system was updated to the one above, the <interface
id="eth0:1"> part was removed - the next update will notice that THERE WAS
such an interface configured before (because it's mentioned in the old
configuration file which is still available on host "mail24") but it was
removed, and will take the actions necessary to remove it from
/etc/network/interfaces. Same if it finds that one of the interface's
parameters were changed.
See where I'm going?
Cheers,
--Amos
