Randall, I've got all the patches applied, but now for the questions.
1. When attaching to another server, must both servers have this codebase? Is it possible that comp1 has the new code, comp2 doesn't, but comp1 can still connect to comp2 via a new remote login (ssh)? If so, I can't get this to work on Linux. It dies around the select() function.
2. Do you have time to complete this patch for the remote rsh macro code in DXChild and conn.c? It would be really nice for some people who wish to use ssh to connect to remote servers from a local UI and it would be nice if this worked consistently across the entire system.
3. I would suggest using the environment variable DXRSH and DXRSH_NOENV since this is more similar to the existing environment variables.
Let me know what I can do to help. David
Here's a patch to 3/2/01 CVS which beefs up Distributed DX a bit. These were made to get our IBM SP nodes crunching DX from our SGIs using Execution Groups. By default, DX makes these assumptions for Execution Groups: - rsh is used for passwordless remote login (/usr/bin/rsh) - the machines are in the same domain (or gethostname() returns a full path -- not common) - the username on the remote system is the same as on the local system - the directory structure (DXROOT, macros, MDF files, etc.) installed locally are all installed and installed in the same location on the other end With the patch, the default behavior is the same, but can be modified as follows: - The default command "rsh" has been left in place, but a user-specified remote shell command can be specified via the $DX_RSH environment variable, - FQDNs (full host paths) are used under the hood when avaialble when creating the remote "invoke dxexec" script and connecting back to the master exec,- Users can now enter host names of the form "[EMAIL PROTECTED]" in theExecute Group Assignment... dialog, and - setting $DX_RSH_NOENV in the local environment prevents the remote "invoke dxexec" script from being written with a full carbon copy of the local environment (only $DISPLAY is set) Under the hood, I dumped pcreateve on SGI in favor of vfork/fork and exec for kicking off rsh. pcreateve is just too picky about compilation options and environment, but vfork/exec seems to work well with everything I've tried. Also, I noticed that the platform-specific boiler-plate RSH macro code is in DXChild.C and conn.c -- I copied it into remote.c. We may want to make a general header for it or generalize this into the configure script someday. Randy -- Randall Hopper (mailto:[EMAIL PROTECTED]) Lockheed Martin Operation Support EPA Scientific Visualization Center US EPA MD/24 ERC-1A; RTP, NC 27711Attachment converted: DataDrive:ibm-sp-exec-groups.patch.gz (TEXT/R*ch) (00003C93)
-- ............................................................................. David L. Thompson The University of Montana mailto:[EMAIL PROTECTED] Computer Science Department http://www.cs.umt.edu/u/dthompsn Missoula, MT 59812 Work Phone : (406)257-8530
