Re: Consesus on Linuxconf?
At 03:54 PM 6/3/98 +0200, Andreas Degert wrote:
>Shaya Potter <spotter@kby.netmedia.net.il> writes:
>
>> I was wondering if we have reached some sort of consesus on Linuxconf.
>>
>> The points that I see are
>>
>> *Linuxconf can't lose any info.
>> --This might mean that Linuxconf will error out if it can't parse the file,
>> if you've made private changes to it. That's the tradeoff, you take a risk
>> that you won't be able to use linuxconf if you privately edit the file. We
>> will work to improve the parser though to minimize that risk.
>
>This will be the case with any interactive config-program build on top
>of existing configuration languages (even the samba configuration
>"language" is complex enough for this to be true).
I wouldn't say that, last year when I was playing with linuxconf, I took my
debian sendmail setup, and the first time I ran linuxconf, linuxconf parsed
it perfectly. I didn't have a complex setup, so it doesn't prove much, cept
that linuxconf can parse things that it hasn't created.
>
>[...]
>> *Linuxconf isn't only way to configure system? (is this a point of
contention?)
>> --We should continue to provide similiar tools to what we have now to be
>> able to configure the system.
>> ---If we do the above, should it be interchangably b/w linuxconf
>> configuration system and old configuration system for the same package (i.e.
>> on one computer, I can switch easily b/w sendmailconfig and linuxconf
>> sendmail configuation). I think that might be too difficult to pull
>> off.
>> We should say that you can choose for each packages b/w the old method or
>> Linuxconf's, but shouldn't switch b/w the 2 methods for one package, at
>> least not expecting the data to be fully transalatable.
>
>It should be possible to disable the linuxconf module, and perhaps
>tell linuxconf to start sendmailconfig instead, or warn the user when
>switching configuration methods.
Maybe some method of alternatives would work.
>
>> files are, i.e. are they free flowing (i.e. don't have a set form and can be
>> on any length), or are they a simple form with plug in variables, or are
>> they a combination of the two. writing a module for the first case will be
>> more difficult, while writing a module for the second case should be very
>> easy, and we can provide an example module to show how it's done. The
>> thirds case will probably be slightly difficult as well, though I'm
>> not sure.
>
>most configuration files can be complex; take a look at the files in
>your /etc. How many simple and how many potentially complex files did
>you find?
well, I don't have a debian system running right now here in .il, <blush> as
I only came for the year, though as I'm returning to the states in a week,
I'll have my debian box[s] up and running soon after, especially with those
nice multiple OC-3s at work. <big smile>
>
>Additional points I would consider important:
>
>- how difficult is it to write a module for linuxconf for some
> package; can some scripting language be used?
Writing simple modules shouldn't be too difficult right now, if you know
C++, I want to convince linuxconf's maintainer to support a scripting
language like python and/or perl as well. This is the only area where I can
see Linuxconf lagging behind COAS.
>
>- how well does linuxconf scale (what if i have 50 configuration
> modules?)
hehe, I don't think their have been any tests, as there aren't that many
modules yet, so I can't answer, if we come to that point, it shouldn't be
too difficult to subdivide the modules, though even without it, you'd
probably just have to scroll threw a longer list to find what you want to
configure.
>
>- how clean/flexible/modular are the concepts? Will the framework
> break down 3 year from now because there are so much new
> requirements that can't be integrated?
>
>- on which platforms could it run or made to work? (administrating a
> bunch of machines with the same tool would be a plus; i think it's
> one goal of coas)
What do you mean? right now linuxconf includes some of the "modules" in the
linuxconf core code, and not as modules, the author is working on seperating
them all out, I hope to get just a linuxconf-base. with linuxconf-[modules].
It seems to be pretty flexible, has remote managment, remote control from
one linuxconf "server" to multiple clients....
>
>These are general questions relating to any such program. Perhaps it
>would be a good idea to discuss the interfaces to packages. If one
>could standardize that (how to put additional information into
>sysv-initscripts, and which information, or the module api, etc.),
>perhaps we could get less dependent on a specific program like
>linuxconf.
Well, for Linuxconf it's pretty standard right now, there's a document on
Linuxconf's web site, that was written up for Red Hat, though it confused me
a little as their were no examples.
>
>I'd like someone to package linuxconf for debian (an experimental
>release), so it's easier for everyone to take a look at it. Last time
>I looked at it (I think it was november 1997), I wasn't very convinced
>of it's concepts. My impression was it's a monolith (though there is a
>clean interface for front ends), and I didn't like the module api very
>much (I experimented with a python interface module, which lets you
>load modules defined by python scripts, but the overall architecture
>wasn't very convincing). Is everything prodived by modules by now,
>e.g. adding users, and how much (e.g. path names) is still hardcoded
>and buried somewhere?
The author has modulised most of it, but not all, though that is a goal, and
in his words shouldn't be too difficult. I'll package linuxconf up soon
after I get back to the states. For script-modules, I don't know.
Shaya
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: