[ previous ] [ next ] [ threads ]
 From:  "Mitch \(WebCob\)" <mitch at webcob dot com>
 To:  "Sascha Heller" <ripperfox at gmx dot de>, m0n0wall at lists dot m0n0 dot ch
 Subject:  RE: [m0n0wall] Re: Manuel's stance on OpenVPN
 Date:  Fri, 20 Aug 2004 15:03:17 -0700
> At the moment some nice addons are in development (openvpn, snort eg.)
> but there is no easy/secure way to install them in the base image of
> m0n0wall - the mentioned patch-scripts are a hack and for FreeBSD 4.x as
> vnconfig is obsolete :).

Not sure what you mean - FreeBSD 4.x is not obsolete until 5.x generates a
stable branch. 5.x is still cloaked in "early adopter" warnings and such -
hardly suitable - or recommended - even by the developers - as a security
device platform for unsuspecting end users.

> It's nice that some people make their customized images of m0n0wall
> available for other - but thats not the best way i can think of
> (prebuild images may be manipulated, etc.).
> Many other firewall/router systems have a addon system for custom
> modules (fli4l, ipcop) and some guidelines that have to be followed to
> make a addon "official".

Good point, but I'm not sure Manuel wants to duplicate the failings of some
other projects which suffer some security and reliability issues by spending
too much effort supporting easy addition of seldom used features.

> > It does not, in my humble opinion have to be an
> > off-the-shelf-packaged-product that someone with NO real knowlege of
> > networks or systems can push a button and install - that's what
> a $50 USD
> > linksys or other is for.
> Right. But: The work to implement nice features as mesh-routing or IPv6
> for example is way too painfull at the moment. It's about 100 times
> easier to set up a LinkSys WRT54G with a modefied OS for this use than
> to use m0n0wall.
> m0n0wall's approach to use PHP for almost everything makes it small and
> healthy. But why has adding customisations to be such a pain?

Suggest an easier way? Build a customization manager module and work with
Manuel to make it part of the standard release? This has been suggested a
few times since I worked with Manuel and others to agree on a simple (to us
anyways) low impact way to add support for additional code without requiring
actual hacking of the base image.

> I think people who HAVE the knowledge would enjoy more complex modules
> which are easy to administer, too.

Sure, but that's the responsibility of someone who can write them. If they
can write the module - where is your risk in installing their version that
you don't have when installing monowall itself?

With monowall you are trusting Manuel to give you a clean, secure image
without backdoors. If you don't know enough to validate this yourself (not
implying you specifically, but any end user of the project) then you have to
trust Manuel to do it. The same applies to module developers. You can
download the module and add it (and if you don't check all their binaries
and source files you ARE trusting them) - sorry I don't think I get it.

> Sure thing - I'm one of the "'cause we can"-fraction too. BUT I DO
> prefer "MozillaMail" over "mail" :)
> And if you're reading the list you see that there are many ppl with real
> beginner questions. Shall we send em to hell?

No, but users have to know their limitations as well.

A home user should not have a cisco connecting them to the net unless they
know IOS or have lots of money to pay a consultant. There is always a
balance of power and ease of use. We were all newbies once ;-) But as a
newbie, I didn't download a file that I didnt' understand, skip the
documentation and jump online to ask someone where to start... Nor did I
pick handrolling sendmail cf files as my first linux config task...

Power and flexibility are often balanced with ease of use, efficiency (for
power users) and always bounded by peoples resources to create code.

I for one am always amazed by people who sign on to a list and say "it isn't
good enough or as good as that one yet" without volunteering to fix
something or donate money or time or hardware or something. Consumers should
be buying something and complaining at the store - CONTRIBUTORS should be
helping build something better than any manufacturer could afford to

> So - what about some rules how to implement/manage addons?
> (Btw: I like the way Fli4L team handles this..)

Not aware of this project - share the knowlege?