Hi ERich; Am Donnerstag, 16. Juni 2011, 00:43:06 schrieb Erich Titl: > Hi KP > > on 15.06.2011 19:51, KP Kirchdoerfer wrote: > > Am Mittwoch, 15. Juni 2011, 00:21:12 schrieb Erich Titl: > >> Hi Folks > >> > >> testing some of the webconf enabled tools I found that some paths have > >> changed, particularly traceroute, which used to be a package on it's > >> own, now it appears to be a busybox applet. It used to be at /usr/sbin, > >> now it is at /usr/bin. Of course this is a challenge for the webconf > >> package. > > > > Erich; I'm afraid you've worked with an outdated source. The path has > > been fixed in lwp-1.tar.gz in January. > > Looks like it, whooo I did not expect a lwp package in the repository.
Yes, you asked to move webconf stuff to a "real" buildtool setup and I started to do that in January with lwp, which contains the "additional" stuff, which belongs not to the core of webconf and not to a special package. Sorry, if the commit messages to cvs hasn't be clear enough. I stopped halfway, and webconf core is still the old tar.gz without a buidltool setup. I see you have again included some cgi, which are in in der lwp directory in webconf.tar.gz. Can you please look into it and update your webconf commit? > >> I intend to provide this to openswan in the form of generating an > >> additional package which can be loaded at the user's discretion, > >> something like > >> > >> either > >> > >> ipsec.lrp, which is the standard package we are used to. > >> ipsec-wc.lrp, which is the standard package with included web gui. > >> > >> webconf-1.2 shows how this can be crufted together without pain. > >> > >> I am of the opinion, the .lwp files should be gotten rid of (Scipio > >> would have loved this construct :-) ) > > > > My opinion hasn't changed since then :) > > Not that I expected it, but let me try to reason > > > Esp. seperation of the GUI stuff from the base package and the > > autoloading feature ow lwp's is a plus IMHO. > > Exactly, autoloading is what does not happen now IMHO. The lrp vs. lwp > scheme is not universal. If you refer to autoloading a xx.lwp package > because the default of webconf is to look for one if there is a xx.lrp, > where is the benefit? It gets loaded automagically if it is there and if > webconf is installed. > > > I believe the webGUI can always be a source of security issues, so it's > > an advantage to just delete all lwp files and webconf.lrp to get rid of > > it. > > Right, just delete webconf.lrp and you are done. Even better, remove > mini_http(s) too. Even better still, disable access using shorewall, > that is what it is meant for. > > > If I follow your proposal, we will have an initrd-wc.lrp (in fact four > > for every flavour we support i486, geode, etc) including the GUI stuff > > related to busybox (traceroute, ping etc), which needs to be replaced. > > And so on and on - I guess this becomes confusing in a short time. > > Right, just that I would make the GUI the standard. Above you can see > how to disable it completely. > > > Where to put pages that shows entries from more than one package, like > > the one who presents the logfiles? > > Where it is now, in webconf.lrp, that has not changed. > > And where does a user or developer has to look to > > > the files that needed to be patched, if shorewall logfiles changes? > > I could argue that the filters are real syntactic sugar. I agree to this > argument, but the current situation is none the better. The filters are > still in webconf.lrp. > > > As you probably know, I do not use the webgui, and I'd like to have it as > > an extra layer on top, so it won't interfer with the development of the > > base packages and keep the documentation work as small as possible. It's > > to explain the user which ipsec package he needs if wants a GUI for > > ipsec in webconf, but it's huge task to explain users what they need to > > do for all packages and that they have to reinstall from scratch if they > > don't like a GUI (and all the useless and probably dangerous stuff lying > > around). > > I understand the argument about the dangers of an apparently simple > system, I am around Windows mongrels all day long. > > > And what should be the default to install - the ones with or without the > > GUI stuff? > > The GUI, don't look at me, I am not the _normal_ end user. But I live > around a lot of end users, actually I introduced leaf a few years ago to > the company I work for. None of our IT professionals has ever ventured > to touch it. The reasoning always was the same > > - I don't want to use the CLI > - I dont want to learn vi > - I don't have time to learn all that stupid command syntax > - All this stuff is much too complicated > - If anything goes wrong, where is the factory reset button. > > You can imagine why, for example, M0n0wall is real successful. Two > things pop up immediately > > - it has a slick GUI > - all configuration follows the same scheme, it is XML, which I > personally don''t like, but nevertheless... > > - If you want to compare to a Linux based tool look at OpenWRT, has a > GUI.... > > - Look at the commercial products, they have a GUI, most of the time > they also have a menu system, sometimes they have CLI. > - They have a way for the end user to upgrade the firmware without the > intervention of an IT expert, through the GUI of course. > - They have a way to save the firmware along with the user settings > without intervention of an expert, through a GUI, of course. > - They have methods to downgrade to a previous version of the firmware > while still keeping the user settings. > > I understand very well that supporting such a big hardware and software > zoo makes life difficult. Please understand that the typical end user is > not prepared to tackle what you and I call a simple and easy user > interface. > > I also understand that introducing another attack vector may affect > overall security, but here we still have an open field for improvement, > signing packages for example, which is not done at all, and even if it > was, there is no mechanism in the package loader which would check this > anyway. And this is what I would call a weak point. > > Let's look at the task of building a reasonable firewall, not just your > SOHO does nothing at all thingie but something more complicated. For > example how do we protect against a ssh scan right now? Some of this > loathed GUI driven products have just a tick mark and the firewall > automagically blacklists those addresses (and reenables them after a > certain elapsed time). I wrote a little piece of code some time back > which does the same, but it is crufty and certainly not fit for everyone. > > I like shorewall, still I prefer my GUI driven fwbuilder for the big > task, because I have to manage a dozen interfaces and roughly a hundred > subnets on the outside firewall. I have roughly 40 VPN tunnels, each > with at least two connections on the outer firewall. Then I have a > second firewall sitting behind the DMZ with another ten or so interfaces > with another few dozens of subnets wich partially overlap. Some services > have to be natted, other not. Some have to be natted if and only if they > come from a specific subnet. Try to manage that with shorewall, it is > possible, but very difficult. And contrary to my 'simple' firewalls, I > do find people interested in managing the complicated but 'colourful' > stuff whereas with the CLI... zilch. > > So me, which always uses a plain old terminal emulator, has been made a > GUI entusiast? No, but I live very close to people that would not touch > leaf with a ten foot pole, just because it does not have a GUI (and no > reset button). :) I do not question that user like to have GUI and improving it, will attract more users. I just make my point about how it's implemented. Having it in another layer (lwp) on top of the packages that can be configured via lrcfg, allowed us to improve packages and update to 4.0 in a shorter time. It also allows to separate GUI developers from package developers. Which I consider a big plus, given that the current active developers like to concentrate on updates, documentation, introduction of new packages. And I think that's not related, if we add the GUI stuff to the base packages or as seperate lwp's - it's the "itch factor". > And please could someone look at the bloody devel mail list, it still > does not accept SMIME signed mail :-( Another point you've made are the signed packages, which is really an important addition IMHO. kp ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
