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

[<ok...@ya...>]

 --- kris m <kr...@ev...> wrote:
> By rebirth, I had meant with a *clean* code base - the old code still
> exists, but starting over (for the most part).

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.
Is the work going to be 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.

> At the bottom of this message is the "spec" - I'm literally working
> on it 
> right now, so...

Ill have a look.

> Client/server architecture; the reasoning behind this is the intent
> to 
> make it simple make massive, network wide changes - i.e. if all the 
> computers in your business are running the daemon, you can connect to
> a 
> master daemon, issue a command to switch over to DHCP issued IP's,
> and 
> *poof*. 

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.

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.

> 	- client/server/master architecture as described in unct
> 	- modules provide specific functionality (i.e. user manager, etc)

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.

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

> 	- do we want to keep the cron type stuff?

This is why I'd put the config file altering in a separate command - it
could be invoked directly from cron.

> 	- installation routine shall confirm to the LSB standards
> 	- UnCT core is in C; clients can use any language; mod_api will have
> 	  multiple interfaces
> 	- previously, i don't believe we were thinking about handling files 
> 	  ~/. (i wasn't, anyway. :grin: )
> 	  i think we should handle them. :-) (ie. ~/.gaimrc, ~/.gnome/...)

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.

> 	  part of mod_api to indiscriminatly determine version numbers. 
> 	  (let me clarify that - from installed, binary programs; we can't
> 	   do much without that. basically just parse appname --version, 

it would be better to keep interface modules part of the same package,
at least initially so that versioning isn't an issue.

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

Oliver





__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com