On Saturday 26 January 2002 23:55, Jack Coates wrote:
> Well, this is a good start, especially with the modules; there used
> to be (like LRP version 2.9.4 or something) a web-based configger
> that would give end-users a custom kernel and modules.lrp; this looks
> like the basis for another one of those.
Well, that is the ultimate plan here. Something in the way of a CGI
roll-your-own custom image. As you address below, how much to
strip out is a big question. I left pretty much everything exactly the
same to eliminate the inevitable troubleshooting, advanced config
problems that would pop up.
> The network configger doesn't address the thing that was bugging me
> though, which is:
> a] network.conf is confusing
> b] network.conf contains code in addition to data (not sure if it's
> possible to break this up).
Not w/o a major re-write to /etc/init.d/network. The easy way to look
at it default is "everything that is commented that you will not need
can be removed." This being said (assummed), as soon as these are
stripped everyone and their dog will want to use them, then we're in
the opposite fire.
> Having EXTERN_DHCP and EXTERN_DYNADDR both in there just confuses
> things. There should just be two options, dynamic or static. Of
> course since I don't use PPPoE there might be something I don't know
> about causing this; still that should be clearly commented. If the
> external interface isn't dynamic, then EXTERN_IP should auto-set to
> \$"$EXTERN_IF"_IPADDR.
Yes, this clears the fact that the eth0 is a dummy ip & the real one is
ppp*, a label like "EXTERN_PPPADDR" would be a lot clearer. This
being said, I used some pretty cryptic variables to keep from
accidentally re-using a global.
> The Internal Interface section should be pulled up below External
> Interface and above SILENT_DENY. Once $INTERN_IF is set, INTERN_NET
> and INTERN_IP should be auto-set again.
That would be clearer for an exact setup, but more confusing for _any_
setup... in any case the scripts clear that problem up with what items
are addressed. Something like SILENT_DENY doesn't have a practical
place in the install scripts when you think about the fact that you'll
likely only set this after the router is in operation. That would lead
to wanting to set the option as a file of it's own. Once you start that
you'll end up trying to source many files into /etc/init.d/network and
have the same mess that network.conf is trying to get away from.
The only real solution is a full set of config scripts
(modular/functions) that will be too big for use on a floppy, and
probably even more cryptic. Reality ~~> only a well planned set
of scripts via CGI, Java, whatever will make a huge difference
in the long run IMHO.
> It's difficult to ascertain which sections of the opened ports and
> portforwards are relevant. New headers would do it:
>
> #####################################################
> # Ports to open -- these must be opened for services
> # that are hosted on or behind the firewall.
> #####################################################
> SILENT_DENY
> EXTERN_ICMP/UDP/TCP/GENERIC
>
> #####################################################
> # Port-forward an aliased or bridged IP here
> #####################################################
> INTERN_SERVERS="tcp_${EXTERN_IP}_ftp_192.168.1.1_ftp"
>
> #####################################################
> # Port-forward the primary external IP here
> #####################################################
> INTERN_FTP_SERVER=192.168.1.1 # Internal FTP server
True again, but as we're seeing more people ptfw'ing internally _and_ to
a DMZ, you're looking a doubling the variables in different places for
the sake of clarity. This may not end up a good thing once something
like "INTERN_SERVER0" gets labled in two sections or winds up useless
with breaking up "INTERN_SERVERS" in 2-3 different sections.
I think, if anything should be broken up, maybe there should be a file
for the base config (ip's, routing, connection type) and a different
file for additional config (forwarding, filtering, etc...). This way
any config done after the initial setup can be done w/o wading through
anything you won't need to mess with. As things are now, it would likely
be too much work with DCD to do it now, the next release would be the
place to do it with since everything is likely to be much different
anyway.
It could be done with DCD, but a lot of functions are going to have to
be put in place for variable doubling breaking compatibility
with the present file. I'm not sure how prepared we are to supporting
this at the present time.
Thoughts?
--
~Lynn Avants
aka Guitarlynn
guitarlynn at users.sourceforge.net
http://leaf.sourceforge.net
If linux isn't the answer, you've probably got the wrong question!
_______________________________________________
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
