Hello Chad, Matt Lynn and list chad you wrote : > On Fri, 2003-02-07 at 14:15, Matt Schalit wrote: > > > > Lynn Avants wrote: > > > On Friday 07 February 2003 07:23 am, Chad Carr wrote: > > > > >>The api makes the hierarchy "feel" like name=value pairs. The output > > >>from the api _is_ name value pairs; the input is sequential arguments > > >>that mimic name=value pairs. See the following transcript from my CVS > > >>code: > > >> > > >>[ccarr@ginger leaf-cdb]$ ./leaf-cdb get tree interfs > > >>default='eth0' > > >>eth0_ipaddr='172.24.8.24' > > >>eth0_netmask='255.255.252.0' > > >>eth0_gateway='172.24.8.1' > > > > Very nice structure and output, Chad. Thanks for taking the > > time to work on this. > > No problem. This is truly the next phase of leaf. I am glad to be a > part.
first of all my compliments for the programm ( much cleaner as what I did ;) ) two small comments 1) to set a variable it should be set like this leaf-cdb set eth1/ipaddress 192.168.1.254 but the syntax leaf-cdb get eth1 returns eth1_ipaddress=192.168.1.254 isn't it more intuitive to set leaf-cdb set eth1_ipaddresss 192.168.1.254 ? filename="$1"; contents="$2" to -> filename=`echo $1|tr "/" "/"`; contents="$2" 2) if a tree exists eth1/ip/mask then it is impossible to create a eth1/active > > >>The interaction between the config-db and the trigger/templating system > > >>is a pure abstraction. The name=value pairs on the output of the api > > >>become the input (and symbol table) for the template. With a properly > > >>designed templating system _any_ type or number of files can be > > >>generated, data can be morphed or manipulated after it leaves the > > >>config-db (i.e. netmask could be transformed to netbits or vice-versa). > > >>The work flow is: > > > > So all the complex coding is in the template that comes > > customized with a package? Is that system that has to > > know all the different brg commands for bridge.lrp for instance, > > so that it can make the correct bridge.conf type of files and > > issue the correct "ip route ..." commands and the like? > > > > > > You touched on the reason why this is so important > > to figure out in advance, down below.... > Even the init script for a package may be templatized, if it relies > heavily on command line parameters and conditional setup behavior. > _Any_ file on the system that is required for functionality of the > package may be customized. what I did was create a tree dependant which a structure varname/dependanttmplate1 varname/dependanttmplate2 etc. The trigger to any action is the change of a variable allthough it shouldn't be trigger each time a var is changed but first after the complete change is ready So my idea was set flag I am changeing. rm filestochange #put the changed templatenames in a file while changeing do change_a_var for i in changedvarname/* do echo $i >> filestochange done done for files in `echo $filestochange |sort |uniq ` do fill_templates $files done Release changeing flag > > >>Your example of shorewall is very apropos. Shorewall will need to know > > >>about nearly every networking change on the box, as well as changes to > > >>it's own configuration. If a new interface is added, it must regenerate > > >>its interfaces file and restart. If someone adds a rule, it must > > >>regenerate its rules or policy files. > > this is a more complicated issue with shorewall, there should for example be some var like open_port_ssh included in the ssh package. But no package could know if you want to remote controll the box with ssh or only from the inside. > > So it regenerates it's interface file, but what default rules or > > policies does it apply to that interface? Does it NAT it? How > > does it know you're not intending to bridge or traffic shape? > > The complexity of this is staggering. > > This is a different problem. It is up to the package maintainer to > decide what people can and cannot configure via the web interface (and > when I say web interface, I really mean non-editor interface, since > other types of interfaces including SNMP may easily be built on top of > this system). This is just like his decision to grant editor access to > certain files through the lrcfg menu, just a little more advanced. Agreed. My I idea is to put the issues that can be edited as variables in the template combined with some logic. The options that are not free to edit for the Joe Average are hardcoded. Pete Poweruser could then edit the template to change things. > > >>It is up to the package itself (or the folks who are trying to integrate > > >>it with the web interface, I suppose) to interpret the event and make > > >>the necessary changes to the configuration files. > > >> > > >>The reason this must be is that if a web interface knows the results of > > >>its actions, it must necessarily be bound to the implementation, > > >>_inextricably_. Then if someone comes along and creates a fancy new way > > >>to configure interfaces at boot time or a new, even tinier dhcp server, > > >>the web interface would have to know about it to get it configured. > > >>This is bad. I think. > > > > Bingo. I was thrashing around this problem myself. > > If I were making a GUI front-end configuration/admin program, > > I'd have to hard code in every variable that a package uses > > and make the drop-down list of possible choices and all that > > in advance. If a package changes, I have to change the front-end. > > Yikes. We could have a configuration-template for example /etc/hosts has etc_hosts.tpl $host_ip $hostname ---------------------------- and a define etc_hosts.def which 1) lists the used variables and the type type means here string value one out of optionx|optiony|optionz optional value and a default value. varname type optionstochose default "helpfull name" eth1_ip N - 192.168.1.254 "IP Address" a (web) interface could easily pick this up and almost automaticaly create a webpage. to edit this var. 2) Aktion to take after the script is updated ----------- eventuall an package own database. this is included in the real database, but if values in the database exists they are not replaced . If you don't need new values, then you could extract the data also from the "define script" but The central database wins. This is the way to implement vars that are not there yet ( for example after an update, or a change to a new package or a change by Pete Poweruser to his templates. ----------------------------------------- > > Yes. Bingo. > > > So how can we make a front-end that reads a package and creates > > all the variable fields and choices dynamically? > > Again, a different problem. It is possible to create a _very_ dynamic > web interface using a drop-in methodology and templating similar to what > I am proposing, but we really need the infrastructure first. The same > tools could be used. see above > > Does every package need a manifest of all possible variables > > and commands? Is that possible? > > Yes. For _complete_ configuration yes. Is it possible: not for > shorewall ;-). But not really required for a web interface. Our > competition on this front is linksys, dlink, microsoft, netgear, > toshiba?, cobalt? > > You don't have to expose all the beautiful workings to the world. Just > the most common. Advanced configuration has been and always will be by > hand. When competing against cisco you need cli and snmp; for the rest > you need web. > > If it's not possible, where do we draw the line and say > > that any more advanced config has to be done by hand? > > The package maintainer does this. He is the only one who can say what > should be configurable in any interface. yes > > > Ok, so now we're suggesting making the packages smarter. This follows > > > the logic since only the package can assume its use. It's a big step moving > > > responsibility from the front-end, back-end, and db-system to individual > > > packages. Logical or not, is this what we want to propose???? > > > > > > I'm not sure we could put the responsibility anywhere *but* into the > > package, Lynn. >> Regards Eric Wolzak member of the bering Crew ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
