Re: linux-ipsec: Pluto command line

Henry Spencer enscribed thusly:
> On Sun, 9 Aug 1998, Hugh Redelmeier wrote:

> I don't see any need for this.

        OTOH... I do... I ran into a TERRIBLE experience with edssl which would do one thing (fork) if in normal mode and another (no fork) if in debug mode. If you made the mistake of building it one way and setting up your rc files to start him up, THEN built a debugging version to test with... Guess what happens... Your system no longer boots. It hangs at that rc script because the program is no longer forking to the background.

        Yes, yes, I know... This can be prevented by sending the program to the background at start up in the script. The point is that the behavior of the program could be dependent on the way it was built and could have a significant impact on the way the system behaves. We should ALWAYS have options to make the programs behave in a deterministic maner. If I had a --fork arguement (or a --nofork arguement) that guarenteed the program would behave in a predictable maner, this is a GOOD THING! The best thing would be to make the fork/nofork not to depend on DEBUG at all. Provide the options (config or command line) to fork or not to fork independent of the debugging state. That keeps the two states orthogonal and keeps the random acts of terrorism to a minimum.

        These ARE applications which we would hope to be permanent parts of operating systems, one day. To that end, we should take consideration of how they would be started in production systems without conflicts from debugging operations.

        If I had some other operating system utility (say mountd or nfsd) that pulled that trick when in debug mode I would be mightly pissed if my system refused to boot just because I compiled a debugging version and forgot to update the startup scripts (I have debugged those programs too - so it's NOT a hypothetical situation).

        My two cents... Worth what you paid for it... :-)

> > - The locking code does not do the dance required to work with NFS.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

> I think not. This ought to be strictly local anyway (as Hugh suggests).

        Snicker.... But wait! Isn't the idea that IPSEC should ultimately be ubiquitous. If it's going to be on all systems and not just firewalls and security perimeters, then it should "do the right thing" no matter where it's running.

> > - The "daemon fork" code closes all file descriptors. I've changed it

> I don't think so; normally that's going to be going to a file anyway.

        Sounds about right... Any time I'm running it in debug it goes in the background anyways with stdout and stderr redirected to files.

> Henry Spencer
> henry@spsystems.net

        Mike

-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (770) 925-8248   |  
http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!