On Sun, 2010-09-12 at 07:17 -0700, Tom Eastep wrote: >
> Not going to happen.
>
> - I came up with the scheme in the Multi-ISP Doc primarily because the
> init script which comes with LSM doesn''t work on Debian. People
running
> RedHat-related distros typically have init start LSM. I know of at least
> one user that has LSM start Shorewall at boot.
Ahh. So the started and restored scripts on the Multi-ISP doc are
simply because of a lack of initscript for LSM on Debian? I had
wondered why you were "preferring" (as I thought at the time of
reading)
to have shorewall fiddle with starting LSM. I thought it was just you
using a belt and suspenders.
Since I am the one packaging LSM for OpenWRT, I guess I can eliminate
that from my config then and just have LSM start with an initscript
(which it already does -- so I guess the started and restored scripts
are my suspenders to go along with my belt).
> - The sample generates the entire stanza for each interface,
Indeed.
> but
> ''checkip'' is the only parameter that can reasonably be
guessed by
> Shorewall.
Really? I could easily see name and device coming from providers also.
With so much information in providers already, adding a single
_optional_ (afterall, it can be detectable for "default" cases)
checkip
value doesn''t seem so onerous to me. But I''m not the
maintainer, so I
respect your position.
> And it''s not the compiler that has to do the guessing -- in
> most cases, the compiler doesn''t have a clue about the interface
so this
> guessing has to be done at runtime.
Indeed. I guess I didn''t mean literally cobbling up the lib.private
file at compile time, but rather having the runtime process create the
"/etc/lsm/shorewall.conf" (although I call it more generically
"connections.conf" here since the concept of including the connections
in the main lsm configuration file seems like a rather nice and generic
solution for lsm).
And also install fw->net rules to allow the ICMP since one could have a
restrictive outbound policy such as I do.
> - There are some parameters, ''ttl'' for example, that
can''t be guessed
> without a lot of time-consuming probing. When I ran LSM, I had one
> interface where the default gateway was proxy arp''ed and I had to
use
> ttl = 2!
I''m not entirely sure I understand the purpose of the ttl parameter.
Certainly (I think) I know what it does, but what''s the purpose of
limiting the ttl on the ICMP probes?
> - Even ''checkip'' isn''t totally foolproof;
Indeed, hence the _optional_ entry for it in providers.
> suppose you want to use an
> address other than the default gateway?
Sure. A non-reasonable-default case.
> Soon I would have the entire LSM
> configuration embedded in the Shorewall;s config so that
Shorewall''s
> guesses could be overridden.
I guess I just don''t think 1 additional _optional_ field/value to
automate the entire of LSM automation seems overly onerous. But I''m
also not the one maintaining it, so I respect your position on that.
> - If I automate the entire Shorewall interaction with LSM, then *I* get
> to do all LSM support on Shorewall systems. I''m not signing up to
do that.
Also fair enough, and again, I respect your position about it.
Just thought I would throw it out there in case it was an opportunity
that was just not being seized.
Cheers,
b.
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev