STUNNEL start-up problem

[Jansen_8]

Hi,

Today I was trying to get STUNNEL working on my Alpha boxes running VMS8.3 and TCP/IP V5.6 - ECO 2.
I did run into problems running the startup-scripts (stunnel_startup_client.com & stunnel_startup_server.com). In both cases the stunnel process crashes when it tries to read the "PEM pass phrase" (from SYS$INPUT ???).

It seems that the "run/detach/input=sys$syste:loginout.exe" is the bottleneck in this case, since when I replace this by a "spawn/nowait" stunnel starts and works as expected.

The read of the "PEM pass phrase" occurs somewhere in the (Open)SSL library. Why does this fail in detached mode?

As is obvious, I prefer to run stunnel in detach-mode.

Jouk

[Hein van den Heuvel]

>> run/detach/input=sys$syste:loginout.exe

That command line is broken.
Is that a cut & paste or a bad retype?

probably needs to be something like:
run/detach/input=some.file sys$systeM:loginout.exe

Cheers,
Hein.

[Galen Tackett]

Jouk,

I had the same problem about the PEM pass phrase.

The stunnel startup scripts creates another temporary script file with a name like STUNNEL_DETACHED.COM, containing the actual stunnel command that will be executed.

This temporary script needs to have the PEM pass phrase, when one is necessary (e.g. encrypted private keys?), immediately after the stunnel command.

Take a look at both stunnel_client_startup.com and stunnel_startup_server.com. You'll see these two commands right near the bottom:

$ write run_stunnel_file stunnel_command
$ close run_stunnel_file

Between these insert a line like this:

$ write run_stunnel_file -
"Insert your actual PEM passphrase here, between the double quotes"

Then right after the close statement:

$ set file/prot=(s,o:red,g,w)/erase_on_delete stunnel_detached.com


It's too bad the pass phrase has to be imbedded like this, so we protect it against everybody else and set it to be erased when deleted.

Hope this helps.

Galen


I'll be out until Monday morning, but let me know how it goes.

[Hein van den Heuvel]

You can tighten the window some by having the script delete itself.
You can not have it do a $DELET/ERASE, that is to say that will give an acces conflict warning, be a regulare delete is fine.

If interested check out this example:

----------------- test_delete_while_used.com ----
$create tmp.tmp
$DECK/DOLLAR
$ tmp_file = f$environment ("procedure")
$ dir/date 'tmp_file ! Proof it is there
$ delete/log 'tmp_file ! Show it go
$ type sys$input
$EOD
$OPEN/APPEN tmp tmp.tmp
$write tmp "Doing secret stuff here"
$write tmp "$ exit
$close tmp
$SET FILE/ERASE_ON_DELETE tmp.tmp
$@tmp.tmp
$dir tmp.tmp ! Proof it is gone


Hein.

[Jansen_8]

Galen : the problem is also occuring when starting the server and in this case the command procedure already looks like

$ STUNNEL :== $SYS$DISK:[]stunnel_alpha.exe
$ STUNNEL SYS$DISK:[]STUNNEL_SERVER.conf


Hein of course I did some cutting/pasting.
The actual not working command with the above command procedurte is:

$ run /detach sys$system:loginout /input=SYS$DISK:[]stunnel_detached.com -
/process_name='stunnel_proc_name' -
/output=nl:

If I use the following command it works like a charm

$ spaw/nowait/proc='stunnel_proc_name' @SYS$DISK:[]stunnel_detached.com

The problem with the /detach is the reading of the password.

[Wim Van den Wyngaert]

I know nothing but try putting
$ def/us sys$command sys$input
just before the startup of stunnel.

Wim

[Jansen_8]

Wim,

This results in an even "worse" error:

Error opening primary input file SYS$INPUT
File not found

Jouk

[Hein van den Heuvel]

Jouk,

>> Hein of course I did some cutting/pasting.
The actual not working command with the above command procedurte is...

Yeah, well, that seems likely. But you failed to give a good command, and failed to give a good error message "the stunnel process crashes" so why trust you? :-)
What does 'crash' really mean? ACCVIO
use process dump to analyze?

>> (from SYS$INPUT ???).

That may well be critical.
Maybe it erroneouls reads from "TT:" and you have that defined?

Just to be sure I tested the basic sequence with a tivial command file:

$ create tmp.com
$ typ tmp.com
$ copy sys$input tmp.tmp
aap noot mies
$ open/appen tmp tmp.tmp
$ write tmp f$mode()
$ close tmp
$
$ @tmp.com
$ spawn tmp.com
$ run/detac sys$system:loginout /input=SYS$DISK:[]tmp.com /out=nl:
... it all works.

The differenence (of course) is that the detached example puts 'OTHER' in the file, the others 'INTERACTIVE'.

Does yout (sy)login.com create a different environment for process mode OTHER which is not acceptable for STUNNEL?
How about testing with a similar silly command file which just does a
$DEFINE SYS$OUTPUT tmp.tmp
$SHOW SYMB*
$SHOW LOG *

Now $DIFF the output files...

Groetjes,
Hein.

[Galen Tackett]

Jouk,

Try changing the /OUT=NL: to something like /OUT=SYS$MANAGER:STUNNEL_SERVER_RUN.LOG

You may learn a little more about this or other problems by catching this output rather than trash-canning it.

I was not impressed with the quality of the startup and shutdown command scripts. The shutdown scripts were flat out broken, but it's not hard to combine their functions into one file. Unfortunately it's too long to type here (does that sound like a famous marginal note by Fermat? :-) and my VMS systems are on a classified network so I can't just copy it over.

[Jansen_8]

Hein,

You probably gave a clue to the source of the problem, however I have no idea how to solve it.

With your command-procedure slightly modified:

$ create tmp.com
$ typ tmp.com
$ copy sys$input tmp.tmp
wim zus jet
$ open/appen tmp tmp.tmp
$ write tmp f$mode()
$ close tmp
$
$ @tmp.com
$ spawn @tmp.com
$ run/detac sys$system:loginout /input=SYS$DISK:[]tmp.com /out=nl:

I get always INTERACTIVE as last line of tmp.tmp. I used the system account which does defines nothing in its login.com to produce this. The syslogin.com is the system default (it dates 6-Oct-1995, which is even older than the first installation on the machine)

So probably because of the f$mode=INTERACTIVE in the detached mode Stunnel tries to read from the wrong source.

Jouk