Hi KP at 03.01.2011 18:38, KP Kirchdoerfer wrote: > Am Sonntag, 2. Januar 2011, 21:59:15 schrieb Erich Titl: >> Hi Folks >> ...
> > We do have other packages like tools.lwp. IMHO they should be in webconf.lrp anyway They may be renamed to tools.lrp, > but then a) it's not clear that it's a file for webconf, so another naming > scheme to detect a webconf package will be required and b) loading of lwp's > needs to be fixed in webconf (it looks for lwp files and not lrp files on the > boot media). No real need for this function. All webconf needs to do at start is to look what cgi files are already installed to build it's menu. There might be other goodies keeping the framework seperate, like > special lwp's for a given package... Well, I have never heard of any, but whatever... Individual extensions are, well, individual until general. > >> We might as well write the specific cgi/function files directly into the >> .lrp files, so we don't need to worry about those files in a different >> envelope. > >> - If the webconf package is missing, the worst thing is a bit of >> overhead in the .lrp files. > And in RAM cause the cgi's are loaded as well. Yes, but for our intended machine target this is mostly irrelevant. test# du -sk /var/webconf 360 /var/webconf > > And it's so easy to get rid of the (probably unsecure) webconf framework - > just don't load webconf.lrp and no cgi files won't be loaded. You can even > remove all completly from the boot media. Except for a small number of cgi/function files this would still be true. > >> - No new mechanisms needed for provisioning these files > > Already done, can be improved - but it's a works that has to be done only > once. And as-is it "just works". Right, but redundant. > >> - the package maintainer knows best how to use them. > > I don't :)) If we make the package maintainer responsible for maintaining the web interface, the quality hopefully will improve. Right now nobody cares. > >> Le't talk about style, ergonomics, e.t.c. > > Agreed! Do we have people with graphical capabilities aboard? > >> ( And no, I don't speak LUA ) > > Ok, looks haserl can be build without lua support. > You might be also interested in (probably you already know this). > http://haserl.sourceforge.net/cgi-bin/haserl/wiki/read?page=080migration I am running haserl v.09 for a number of years already. There are only a small number of modifications needed. Actuall we have now a fully blown perl interpreter for shorewall. we might just as well use that for the web interface. It might make parsing shorewall files easier. > > I'd appreciate an update, it may finally allow some sort of "user > administration". I will port a current haserl version, this is an easy task. cheers Erich ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
