Re: debconf and cluster management
>> Matthew Palmer <mjp16@ieee.uow.edu.au> writes:
> Joey said he's only got local file (etc) DBs done.
Oh, I misremembered indeed then.
> I got the impression that no work has been done on remote databases,
> because I've volunteered to write them (at least the LDAP one at this
> stage - SQL when I can think up a reasonably sane table structure).
I would hazard guessing that one database, one table per package should
do it. Or better said, one table per configuration group/entity. I
really don't remember the specification, but I *think* this would allow
for a nice trick: store the configuration with an id an have a
"snapshot" table, in other words, all the configurations with a given
id are time-coherent. Then you could *theoretically* roll back the
configuration. It's just an idea and I made it up on the spot, but
sounds neat if it could be implemented.
> > That'd be the non-interactive front-end.
>
> I think you misunderstood what I was after. I know the non-interactive
> front-end, and it's what gets used at present. What I wanted was some way
> to say 'OK, ask me the questions from these packages and then give me the
> debconf data (stored in some remote database, preferably) to use on other
> machines - but without screwing with the config the local machine.'
I see. Yes, that'd be something for debconf-utils. And yes, it'd be
useful.
> This is what I want, but without needing to configure an actual,
> live, running machine. Basically, I want a way to get asked all the
> questions and store the answers somewhere without touching the
> machine the program is running on.
Well, that'd work for the pre-installation phase, but there are
postinst scripts using debconf in a sort of interactive way (those that
stop in the middle of an install run and pop a debconf dialog up).
Those make questions based on the current configuration of the machine,
so I'm not sure how that would work.
--
Marcelo
Reply to: