Gregory S. Stark <firstname.lastname@example.org> wrote:
> I think there's a lot of promise here, but it'll be some work to integrate it
> into Debian. What I'm most worried about is the direction it's headed in of
> having one package with modules to control everything under the sun. It is
> modular, and it looks well-designed. But many of the modules span multiple
> systems (like editting /etc/hosts and bind configuration at the same time).
> For Debian I think what we need is to have each module correspond to a
> specific package. Sort of like what we do with menus or for that matter, man
> pages. He has different ideas. One nice implication of his ideas is a user
> could go into linuxconf see "DHCP setup" and when he goes to turn it on
> linuxconf would inform automatically offer to fetch and install the required
> packages. This is sort of the way Win95 works, it has the nice effect of
> making the package maintenance system a lot less obtrusive.
We also need a distinction between package-specific module support
and system-specific configuration information. A related issue is
that a large system may involve many computers.
> 1) Linuxconf depends on X
> No it doesn't. It's client-server, there are a number of clients including a
> tty client and an httpd client. The modules are written independently of the
> client used. Writing one module immediately defines the X as well as the tty
> and http interfaces.
> This is sort of true, but sort of not true. It takes advantage of sysvinit
> style scripts to start and stop the daemons. It does expect to be in control
> of the system startup and shutdown, but RedHat immasculated that section of
> code precisely because they thought it would be too surprising. He added
> features specifically so it could use the existing sysvinit setup for RedHat.
RedHat made a very good move, here. It's important to maintain an
abstraction layer between the configuration tool and the underlying
system. [at least in my opinion.]
> One of the design goals is that it be "vi-compatible". With the
> exception of sendmail.cf he parses every configuration file and
> retains all comments and whitespace.
The author of linuxconf made a very good move, here.
I think it would be very interesting if linuxconf could be made to work
with cfengine. I'm not sure how nice the result would be, but it seems
like a big step in the right direction.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org