Etienne:
Heya. Over the last year, I pitched my company's
'echoWare' solution to a number of OEMs, including heavy-iron
OEMS, SOHO-router OEMs, and garage-mode last-mile broadband
wireless gateway startups. Everyone I've spoke with agrees
it's a strong model for the future, but faces an enormous
"adoption" problem: a Fortune-500 OEM simply *cannot* put
anything into the box unless it's an industry standard. Put
another way...even if a sh!tty, insecure, bloatware protocol
becomes an industry standard, they don't just feel compelled
to support it, they are *proud* to support it. It can be very
frustrating: talk to them about a novel, lean, SSH-based
remote-management architecture, and they ask for SNMP, UPnP,
Passport, or 802.1X.
Not that this surprises me. :) But the doubly
frustrating part is that this resistance affects my ability
to raise funds to support a development staff to actually
release some code that could, who knows, someday actually
become pervasive. Perhaps it's a Peter-principle of mass
market products: they are forced into this awful state of
standardized mediocrity.
</rant off>
Anyhow.
The idea behind echoWare is that you run an SSH
service on the machine you want to administer, and exchange
simple ascii directives to that machine to affect its
configuration. You can make these directives as machine
friendly as you want: importantly, the actual *user
interfaces* is "filtered" by a remote web-server. So, the
end user connects to this website, and that server opens an
SSH connection back to the end-user's gateway, pulling out
ascii config info, and turning it into an HTML picture. Only
takes a second or two in our demo. End-user can now point
and click to make configuration changes, which go "up" to
the server over SSL, and back "down" to the gateway over
SSH.
The primary benefit is the "cost" of the software.
The gateway only needs to run an SSH daemon (which usually
comes from free), and an ascii parser, which bash and sudo
handle well enough. Might be worthwhile to customize the
shell, too, so that only a limited set of commands is
available to the ASP server. Given this...you can load up
all the "heavy lifting" (graphics, os-specific ifdef's,
etc) on the server, which has the CPU, memory, and storage
to spare.
Anyhow, we call it echoWare here, and someday it'll
actually move beyond the demo phase: I'm hoping to attach
EchoWall 2.0 to this service. So instead of editing the
echowall.conf file by hand, you'd connect to a website, tell
it what services to enable, and it sends the sed commands
into the box, and updates the echowall.rules file if needed.
Very visual for the end-user, but very ascii for the gateway.
Anyhow...hope this helps, somehow. Got something
of a demo running if you'd like to kick the tires around.
Got another meeting this week with a major vendor to talk
about it some more. :)
cheers,
Scott
On Sun, 16 Sep 2001, Etienne Charlier wrote:
> Hi,
>
> Since last year ( when I discovered LRP), I think that there was at least
> 3 or 4 threads about a web interface to a LEAF derivative.
>
> I would like to start a brainstorming on the feasability/usefullness of
> a Web interface for the LEAF project.
>
> what people think about
>
> - usefullness
> - would it be secure enough
> - technologies to use ( scripting languages ,..)
> - is there some exsiting project that could be reused ( I've heard about
> Webmin)
> - other secrets wishes that you have about LRP/LEAF
>
> happy brainstorming
> Etienne Charlier
>
>
> ----- Original Message -----
> From: "Eric Wolzak" <[EMAIL PROTECTED]>
> To: "Etienne Charlier" <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Sent: Sunday, September 16, 2001 10:37 PM
> Subject: Re: [Leaf-user] thttpd CGI Forms for administrating Firewall
> through browser
>
>
> > Hi Etienne, Sandro and the rest of the list
> > >
> > > I'd be happy to contribute to a web interface for LEAF
> > > > If there are more people interested, we could join our efforts :=)
> > > Here are some ideas
> > >
> > > First of all, the combinaison LRP/Kernel 2.4/Shorewall is not yet very
> > > common in
> > > the LRP world and I can understand the lack of feedback Eric got about
> his
> > > web interface.
> > I think you ve got a point there.
> > >
> > > I think that allowing editing existing files through the web interface
> is a
> > > lot of work
> > > with a very small ROI, an applet java allowing ssh access could do the
> job
> > >
> > This is what i normally use myself, but I thought that there is some
> > interest to do it with a webinterface. ( a "concurrent product"
> > fli4l.de" uses a windows programm as a frontend)
> > > IMHO, What we need is a higher level interface ( Like seawall, you have
> a
> > > few
> > > simple configuration files and a lot of work done with the data in those
> > > files)
> > That was exactly what I liked about shorewall
> >
> > > I think we could design the web interface as an editor modifying a big
> file
> > > ( config.web)
> > > containing shell variables definitions and a few scripts which process
> > > configuration files
> > > templates, replacing the variables in the templates by the actual values
> > > from config.web and
> > > write actual configuration files in the right place.
> > That is kind of the way the eigerstein was setup.
> > A problem is usually the multiple different lrp packets.
> > If we could create a small yet complete interface in the packages
> > then the "central editfile could take this and return them at the
> > appropiate moment" ( sounds kind of complicated ;))
> > > example: the local interface ip address ( 192.168.1.254) is used in a
> lot
> > > of configuration
> > > files. the web interface should be able to modify this value
> "everywhere"
> > >
> > > It should be easy to add "modules" to the web interface ( a set of pages
> and
> > > a set of templates)
> > > those pages and templates could be stored in the .LRP files or in
> separate
> > > packages (with another
> > > file extension).
> > >
> > I think that is a good approach
> > > now a few questions:
> > >
> > > - Should the interface be usable with the floppy version of a LEAF-like
> > > distribution ????
> > I personally would like it that way.
> > > ( https ? to allow remote management isnt't it too big ?)
> > >
> > > - Should we try to reuse something exisitng or build from scratch ?
> > I think it is a good idea to complete the concept and after that look
> > at how much we can use from existing files and how much has to
> > be created new.
> > >
> > > - Could we build our interface so that we could derive from it a set of
> web
> > > pages or a set of scripts
> > > using the dialog command ( being usable from the text console )
> > >
> >
> > > - how to permit customizations in the templates outside of the web
> interface
> > > ( to allow
> > > modifications not ( yet ) possible from the web interface ??
> > I think about it :=)
> > >
> > > - I think that it's a big project but it should be possible
> > >
> > > PS: Maybe we could move on the leaf-devel list or elsewhere ??
> > >
> > I Think it is a good idea to move to the leaf-devel list. Perhaps
> > change the subject a bit.
> > > Regards
> > > Etienne Charlier
> > > [EMAIL PROTECTED]
> > Regards to Belgium :)
> >
> > Eric Wolzak
> > http://leaf.sourceforge.net/devel/ericw
> >
> >
> >
> > _______________________________________________
> > Leaf-user mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/leaf-user
> >
>
>
> _______________________________________________
> Leaf-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/leaf-devel
>
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
