On 15/01/07, Tzafrir Cohen <[EMAIL PROTECTED]> wrote:
Your keyword here is preseed . > > The software I'm thinking about will take all this configuration information > and build a host-specific package (or maybe a "task" in debian world?) which > the host will just apt-get (either after a PXE boot or manually upgrade with > apt-get/aptitude), causing all the changes to be deployed on it. Host-specific configuration: http://dilab.debian.net:800/~joey/d-i/preseed/ (the actual selection is done by hostname in netboot.cfg) In there you can define some extra packages to install (this one is from appendix B of the install manual): # Individual additional packages to install #d-i pkgsel/include string openssh-server build-essential You can probably automate this to: task-$hostname . Look at sample preseed configurations.
Thanks. Looks interesting but it seems to be geared towards complete re-installation of the Debian machine (which is indeed one of the scenarios I'll need to address) but not for system upgrade - unless I miss something that will be obvious after more reading about it? The current system I'm familiar with is a home-grown system built for RedHat and which can ADD stuff (users, packages, etc) but does not allow for automatic removal of packages which are no longer required on the system ( e.g. a development system which accumulates packages as developers add the bits they need or want to test but never remove once finished, or a package was installed because it was required by another package but never gets removed when the other package's dependency is gone). I'd like to be able to say "ok, this system now does NOT need package "oracle" and have package (and the users configured for it, and all the tweaks done in system files by it) to be removed/reversed if possible. However, those are all install-time settings. What happens if you
accidentally remove such a package?
First, I was told by a Debian developer today that he thinks that tasks are deprecated in favor of meta-packages and maybe tags. Secondly - how about giving this package an "essential: yes" or "priority: required" so it doesn't get removed "accidentally"? You can also define an extra apt mirror with your own packages. What I'm
trying to figure, though, is how to get past apt-secure: how to add my keys to the ones trusted by the installed system.
What I'm concerned about before that is - "how to automate and ease the creation of these host-specific meta packages?" And "how to make give thes package tools smart enough to handle upgrades rather than just install/delete?" Anyone? The closest I've seen today (first day of LCA 07 miniconfs) was a guy giving a 20 minutes talk about his team creating "user packages" to administrate client's debian boxes. Nothing earth shuttering. Puppet (mentioned by Oron) indeed seems like the closest thing to what I'm after but it seems to be: 1. Written in Ruby, which means that I'll have to learn yet another language I'm not interested in just to be able to hack it for missing/broken features. 2. Uses its own language which, while being specific for the task, seems to have too many loose ends and things done behind the user's back. 3. Doesn't seem to be geared for Debian yet (although there are packages for it in Etch) Personally I think that XML, while possibly not ideal, would be better because: 1. It's standard - so anyone who knows XML (and XML schemas) can read/write/test correct files. 2. It's standard - so you can take advantage of the thousands of existing tools to manipulate the data (e.g. write a script which can read current system cnfiguration and reverse-engineer a configuration file to mirror that current status, would be useful for the first round of introducing such a tool into an existing network). 3. It's eXtensible. I'd also prefer something written in a more common language, I'm currently digging for Python simply because I get a feeling that Perl have a tendency to gravitate system-admin types rather than programmers, and in the long run it shows (speaking after working over 15 months around a practically purely perl-based environment). I'm still somewhat hopeful about dpsyco (http://packages.debian.org/dpsyco) (maybe in combination with cfengine2? Still have to dig about these), though nobody I talk to have even heard about it yet - is anyone here familiar with it? Thanks for all the pointers and ideas... Cheers, --Amos
