Re: [unct-devel] Re: unct & unix configuration ;-)

[kris m <kr...@ev...>]

On Mon, 18 Feb 2002, Oliver Kiddle wrote:

> Can I suggest using autoproject to start the new code base. That way
> you get a skeleton for the command-line parsing and a GNU style layout.
Suuuuuuure. :-) I'll read up on it and try to do it over my lunch break. 

> Is the work going to be GPL?
Yes, we already agreed on the GPL.

> Can I suggest that we e-mail everyone who wrote an
> intelligent/enthusiastic comment on freshmeat or slashdot and try to
> bring all the discussion to one single place - whether or not that is
> here.
I like how you specify intelligent and/or enthusiastic. :-) That sure 
sounds like a good idea to me, although we should perhaps organize that 
somehow(?). Anyway, .. yeah, let's do it. 

> I'd still have my reservations about this. Minimising valunerability to
> security problems being a biggy. I'd suggest that the network server
> just be an interface module that by default you wouldn't use. It could
> then securely use sockets internally for communication between
> interface and the main program.
So, you mean "just use the loopback interface" by default? Make the user 
actually have to *turn on* the ability to be controlled by an outside IP? 
What?! That might make the system secure!! :grin: Of course, I'm not 
entirely sure what you mean by "interface module" - I think you mean in 
the same fashion that what we're calling the "console client" is an 
interface module. Is that what you mean? I have absolutely no problem with 
making it difficult for the user to hurt themselves, as long as we don't 
lose functionality originally decided upon. :-) (eg - the example of a 
network wide change was one of the original reasons for starting the 
project.)

> At the very least the Linuxconf error of keeping it's own record of
> configuration must not be repeated. Where possible, we should use
> existing commands such as useradd, chkconfig etc instead of changing
> config files. It should be possible to see the list of commands being
> run  like in AIX's smitty. I'd be tempted to wrap up the config file
> changing into a separate command which can be invoked from the command
> like.
Absolutely. Positively. I totally agree. AFAIC (care), the daemon doesn't 
need to give a rats ass about the system config, and could easily shell to 
another executable to make the actual changes. (Yet Another Layer Of 
Security... Yay! :-)

> I'm not sure about that. I'd use separate XML files to describe
> different areas to configure. The XML would describe enough to do the
> configuration. I'd embed m4 preprocessed shell code for as many of the
> actions as possible and for getting lists of possible options. This way
> people can see what the program is doing rather than Linuxconf style
> hiding.
Hrm, I'm not sure I quite understand what you mean by "different areas." 
Can you give a small example of the XML file you're envisioning? 

> People should be able to get the program to configure their application
> by merely installing an XML file in the appropriate place assuming
> their config file is generic enough or they have a command which can do
> the configuration. This means that people will not have to navigate
> menus full of configuration for components they don't have. I'd use the
> directory structure to create a hierarchy of menu options (which the
> GUI interface may represent as a collapsible tree).
This is similar to what we were intending with the modules. The client 
would only report the modules installed on the daemon. (And because you 
connected to the daemon via sockets, you could (assuming authentication) 
very easily configure a remote machine.) Of course, .. X kind of moots 
this issue, as does any kind of connection to the remote machine.

> This is why I'd put the config file altering in a separate command - it
> could be invoked directly from cron.
Cool idea, but not what I meant - Bill made a version of cron inside the 
daemon (err, a scheduler, simply runs command at time.)

> If everything is described in XML files, we could have a CONFIGPATH
> variable defaulting to ~/share/config:$prefix/share/config. It would
> search for the XML descriptions in these directories.
I think our "shared vision" is a bit skewered. What's contained in those 
directories? Similar to /etc, or?

> it would be better to keep interface modules part of the same package,
> at least initially so that versioning isn't an issue.
I had meant to determine version numbers of the application that they're 
trying to configure; but if we shy away from the modules approach, .. this 
doesn't matter. 

> I'd suggest using libxml2. It looks good and the author was very
> responsive when I e-mailed him a year ago.
We already do. :-)

--Kris