On Tue, 20 Sep 2011 11:14:55 +0100, Andrew <haines42 at gmail.com> wrote:
> Hi all
>
> I'm struggling to set up parallel remote kernels, and searching around
> it seems that I am not alone but I could not find a solution.
>
> In my case, both client and server are running Windows; the server is
> running CopSSH and I have successfully set up a single remote kernel
> using mathssh:
>
> java -jar "`mathssh`" user@server "math -mathlink -LinkMode Connect -
> LinkProtocol TCPIP -LinkName `linkname` -LinkHost x.x.x.x"
>
> where x.x.x.x is the client's IP. I can set a notebook to use this
> remote kernel, and executing $MachineName gives the name of the
> server, so everything is working as expected.
>
> However, I can't seem to get the same to work for parallel kernels. I
> have pretty much just copied the configuration across and tweaked the
> replacements:
>
> java -jar "C:\Program Files\Wolfram \
> Research\Mathematica\8.0\SystemFiles\Java\WolframSSH.jar" user@`1`
> "math -mathlink -LinkMode Connect -LinkProtocol TCPIP -LinkName `2` -
> LinkHost x.x.x.x -subkernel -noinit >& /dev/null &"
>
> However, when it fires up, the server kernel spits out the error
> LinkConnect::linkc:
> LinkObject[55512 at x.x.x.x,55513 at x.x.x.x, 1, 1]
>
> which "is generated by an attempt to access a MathLink connection that
> is not active".
>
> Any ideas?
>
I haven't tried this approach to running remote subkernels on Windows, so
can't offer advice on your particular situation, except for the obvious
(?) point of making sure that math.exe is in the search path on the
server. Also, the arguments "-subkernel -mathlink -LinkMode Connect `4`
-LinkName `2`" should be sufficient for math.exe to establish the
connection without the need to specify LinkProtocol or LinkHost as well;
if these options have inconsistent values it could perhaps lead to
difficulty.
If your server and client are part of the same network and able to access
each other's shared resources, I would recommend a different method not
based on ssh. For this you will need rcmd.exe and rcmdsvc.exe which were
distributed with the Windows 2000 Resource Kit, but which do still work on
more recent versions of Windows (since they use ordinary named pipes) and
can be found available for download from various places on the Internet.
Assuming that you have these installed and working correctly (i.e. service
running on the server and any necessary user accounts shared between or
duplicated on both machines), you can evaluate
SubKernels`RemoteKernels`$RemoteCommand := "runas /savedcreds \
/user:\"`3`\" /noprofile \"rcmd \\\\`1` start /b math -noinit \
-subkernel -mathlink -linkmode Connect `4` -linkname `2`\"";
and then define your remote kernels as usual via the Preferences dialog
(remembering to select "Use custom launch command" to save the above
definition for $RemoteCommand along with the other settings for each
host). The kernels should then be able to be launched in the normal
fashion, although on the first attempt you will have to enter the password
for the user account you are running them under on the server (which is
set using SubKernels`RemoteKernels`$RemoteUserName, and defaults to
$UserName -- i.e., the name of the user account under which the master
kernel is running).
Relative to ssh, this approach has the disadvantages of any Windows
network share in that the connection is not encrypted (unless you use
IPsec) and is unsuitable for use across the Internet (unless you use a
VPN). However, in my opinion it is easier to set up and more appropriate
for the typical scenario in which Windows systems are used as workstations
on a corporate network.