Lynn Avants wrote:
My line of thought to modifying the existing packages would be
to add two text files: 1) A file that includes all variable names used
with the package _except_ base variables that should already
exist (ip addresses and the like) 2) A file that listed depedancies
for the pac
On Saturday 01 February 2003 12:15 pm, you wrote:
> Sounds like a decent solution to me. It might also tie in nicely with a
> more advanced packaging system. I was looking at using text-based
> flat-file databases to keep track of package information...the same
> database "routines" (mostly in s
On Sunday 02 February 2003 01:48 pm, you wrote:
> Greg Morgan wrote:
> > One of the things I had not designed but thought about was variables. So
> > here's a possible definition in XML.
>
> XML. That's where I remember this whole idea coming to
> a halt a year or so ago, when somebody suggesting
Hi Folks
too many posts and too many good ideas to reply to.
Bear with me if I throw in my $ 0.02
I belive any fat configuration system which we'd introduce here will change
the lean and mean machine aspect all LEAF variants have in common. IMHO
this rules out Perl, Java and SAX (sorry :-(
The config-db is only itself. The templating system is used to
transform the "abstract" values in the config-db to the format of each
package.
Ok thanks for explaining how the template system is
used here. Now why is that more useful than just
modifying each packages conf files to use stan
Greg Morgan wrote:
One of the things I had not designed but thought about was variables. So
here's a possible definition in XML.
XML. That's where I remember this whole idea coming to
a halt a year or so ago, when somebody suggesting using
this and I and a couple of other people said, "yikes
Mike Noyes wrote:
On Sat, 2003-02-01 at 10:54, Charles Steinkuehler wrote:
To avoid re-inventing the wheel, I would suggest an RDB format database
system, which is built out of plain ascii text files, and manipulated
with small programs via shell scripts. Something like rdb (perl) or
nosql (s
One of the things I had not designed but thought about was variables. So
here's a possible definition in XML.
Whereas GMLEAF would define specifics to a distr
On Sat, 01 Feb 2003 14:46:10 -0800
"Matt Schalit" <[EMAIL PROTECTED]> wrote:
>
>
> Chad Carr wrote:
> > On Sat, 1 Feb 2003 12:16:10 +0100
>
>
> > 1) a centralized configuration "database" and "api" for adding and
> > removing system configuration parameters,
>
>
> When using a centralized c
Back in March 18, 2002 I looked at a different approach from the weblet
configuration. The date reflects the date of a Visio diagram I drew of
my concept. (It was version four of Visio before Microsoft bought them
and I wasn't dual booting into Linux at home at the time.) Anyhow, the
concept
Chad Carr wrote:
On Sat, 1 Feb 2003 12:16:10 +0100
1) a centralized configuration "database" and "api" for adding and
removing system configuration parameters,
When using a centralized config-db (a good idea), how do we deal with
a new release of a program, let's say ntpdate?
a. Do we
Lynn Avants wrote:
>
> I see either this concept can be embraced or ridiculed, but if you don't
> see it as necessary in the future you plainly haven't followed the desires
> on list for the last year or two. Packetfilter, apkg (Oxygen), LINCE,
> Mosquito, and individual systems are proof that
Jaime Nebrera Herrera wrote:
...
but in such case you would need to add some editor capable of uncompressing
on the fly
JEdit
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
ht
On Sat, 1 Feb 2003 12:16:10 +0100
"Jaime Nebrera Herrera" <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I have been following the discussion about the need for a
> "graphical" system to configure LEAF systems. As it has been already
> commented, one of the daunting tasks is to be able to work
Well,
I see this discussion going exactly the way it previously was
>6 months ago when we ended up in agreement of the situation.
These are still interesting arguements, but still re-hash. IIRC, I
believe Charles and I (at a minimum) are still following the same
line of thought. It might make it
Hi Eric and List,
> How large is the E-Smith (scripts Suite) and what does it need (perl ? )
I dont know how big E-Smith suite is as there are many other things
involved. Their system is more complex than described (the files are build
gluing toguether files in a directoy and other stuff).
On Sat, 2003-02-01 at 10:54, Charles Steinkuehler wrote:
> To avoid re-inventing the wheel, I would suggest an RDB format database
> system, which is built out of plain ascii text files, and manipulated
> with small programs via shell scripts. Something like rdb (perl) or
> nosql (shell & awk):
Lynn Avants wrote:
This is exactly what I have had in mind. I'm still working on the
database/variable file for my own testing. The only problem with this
idea is that it modifies existing packages (substution variables), but it
nullifies the need to generate all the needed conf files saving t
Hi Lynn and others:
> This is exactly what I have had in mind. I'm still working on the
> database/variable file for my own testing. The only problem with this
> idea is that it modifies existing packages (substution variables),
No it doesnt. Standard config files can be kept as they are
Hello Jaime , List
> Hi all,
>
> I have been following the discussion about the need for a "graphical" system
> to configure LEAF systems. As it has been already commented, one of the
> daunting tasks is to be able to work through the easy system and keep the
> power of direct editing.
A
Forgot to reply-all... :-/
Original Message
Subject: Re: [leaf-devel] Template system [was Webconfiguration]
Date: Sat, 01 Feb 2003 09:15:15 -0600
From: Charles Steinkuehler <[EMAIL PROTECTED]>
To: Jaime Nebrera Herrera <[EMAIL PROTECTED]>
References: <[EMAIL PRO
On Saturday 01 February 2003 05:16 am, you wrote:
> Hi all,
>
> I have been following the discussion about the need for a "graphical"
> system to configure LEAF systems. As it has been already commented, one of
> the daunting tasks is to be able to work through the easy system and keep
> the po
Hi all,
I have been following the discussion about the need for a "graphical" system
to configure LEAF systems. As it has been already commented, one of the
daunting tasks is to be able to work through the easy system and keep the
power of direct editing.
We faced that question some time
23 matches
Mail list logo
