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.
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ 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
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
