Hello Tom, Ray- that is exactly the problem I found by working on this system. To create a UI for a limited set is good possible, and by giving people the change to only select limited possibilities reduces errors ( masks , Broadcast and so on) It is also possible to simply forward certain ports for servers ( like gaming and peer2peer networks) . If you want to use your UI for the more complex system you are complicating the settings for the average user. The overall complexity is enormeous. So what I would like is to use the database for those settings that are common to all kind of packages (local IP, Hostname and so on), This will limit the number of things people has to do to start. So you could use a webconfig for the level of a advanced home router. If you want to go beyond that, you will have to have knowledge of routing and so on anyway, and then it would be better to keep to the more universal solutions.( which means a much larger base of possible literature and helping hands
regards Eric wolzak From: Tom Eastep <[EMAIL PROTECTED]> To: Ray Olszewski <[EMAIL PROTECTED]> Copies to: [EMAIL PROTECTED] Subject: Re: [leaf-devel] Source: config Date sent: Mon, 5 Jul 2004 14:15:39 -0700 (Pacific Daylight Time) > On Mon, 5 Jul 2004, Ray Olszewski wrote: > > > > > The really really hard parts -- e.g., the structure of the Shorewall > > subsection -- are not yet done. Or at least I hope not ... this area lacks > > very basic details, such as a way to specify port forwarding/DNAT. > > > > Here are some random thoughts. > > I don't understand what requirements the solution that you are designing > is supposed to meet. If it is to make things simple for newbies then you > may end up with two very different ways to configure a Bering box -- using > the config files directly and using the configDB/UI. My experience with > Shorewall was that this approach works badly because when people outgrow > the 'newbie solution' then they have a big learning curve to be able to > configure 'the real way'. Through the UI, you will have established an > unrealistic level of expectation. > > If you intend the configDB/UI to be *the* way to configure the box then > the database and UI should reflect a similar abstraction and I have a > difficult time understanding why it would be desirable for the Shorewall > UI to present a different firewall model from the text-file database that > Shorewall currently uses. If the UI does not mirror the Shorewall > configuration files (in a manner similar to the Webmin Shorewall > Interface) then users can't make use of the Shorewall documentation to > configure Shorewall through the UI. Furthermore, if the interface is > significantly different from the Shorewall documentation then people who > use Shorewall on a platform other than LEAF can't help those who only know > how to use the LEAF UI (and if some folks participating in this discussion > have their way, there would be no way to reload the database from the > Shorewall config files). > > 10 years ago or so, I worked on a project to create a centralized > configuration database and UI for Tandem NonStop (tm) systems; that > project was eventually abandoned. Some of the issues were: > > a) what are the product/database synchronization rules? > b) Who is responsible for updating the DB/UI when the product changes? > c) How does product upgrade/downgrade interact with the database/UI? > d) How are Database-UI/product version differences accommodated? > e) How do I install/uninstall a product. > > In our case, the intractable problems were more organizational than > technical. > > I would like to participate further in these discussions but my schedule > is very full these days; nevertheless, I'll try to follow the discussion. > > -Tom > -- > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > Shoreline, \ http://shorewall.net > Washington USA \ [EMAIL PROTECTED] > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > > _______________________________________________ > leaf-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/leaf-devel ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
