Siemens PLM Software HEEDS MDO 2018.04 Setting up a Windows-to- Linux Compute Resource www.redcedartech.com.
Contents Introduction 1 On Remote Machine B 2 Installing the SSH Server 2 Configuring the SSH Server 2 Starting the SSH Server 2 On Local Machine A 3 Installing PuTTY 3 Testing the Connection between Machines 4 Creating Passwordless Entry to Remote Machine B using RSA Keys 5 Create Private and Public Keys on Local Machine A 6 Copy Public Key to Remote Machine B 8 Enable and Test Passwordless Access with Pageant on Local Machine A: 9 Setting up Remote Execution in HEEDS 10 Creating a Remote Profile 10 Using Direct Submission for a Compute Resource 11 Using a Scheduled Cluster with PBS Professional for a Compute Resource 13 Using a Scheduled Cluster with LSF for a Compute Resource 15 Notes 17 Troubleshooting 18 SSH Doesn t Connect to Remote Machine 18 Passwordless Connection is Unsuccessful 18 Errors Writing Files on Remote Machine 19 Errors Executing Commands on Remote Machine 19 Example Study 21
Introduction Introduction This document provides a step-by-step guide to establishing communication between HEEDS MDO and two computers, the first running the Windows operating system and the second running some version of the Linux operating system. Once this communication has been established, HEEDS can then operate on the Windows workstation while submitting jobs to the remote Linux workstation (or cluster), as illustrated in the figure below. Some of the steps defined in this document require administrative privileges on each machine. Before proceeding, please ensure that you have sufficient privileges to complete the required tasks. Local Machine A Remote Machine B Software Needed Windows 7 HEEDS PuTTY Analysis tools (optional) Software Needed Linux SSH Server Analysis tools Queuing tool (optional) A network protocol is required to allow remote login and other network services to operate securely over an unsecured network. The Secure SHell, or SSH, cryptographic network protocol is employed in a client-server architecture for the communications described in this document. Red Cedar Technology strongly recommends utilizing the free, open-source, network file transfer application called PuTTY as the SSH client on Local Machine A and using the SSH server on Remote Machine B to set up a Windows-to-Linux compute resource. Most flavors of Linux come with an SSH server already installed. While other configurations may be possible, they are not recommended or supported by Red Cedar Technology. 1
Setting up a Windows-to-Linux Compute Resource On Remote Machine B Most Linux operating systems already come with an SSH Server installed and running. Prior to proceeding with the steps below, you should check with your IT department to confirm. Odds are these steps will not be required on your Linux system. They are provided here in case your system is not already configured with SSH. Remote Machine B Installing the SSH Server The most common SSH Server for Linux is OpenSSH. To install it, use the command: sudo apt-get install openssh-server Configuring the SSH Server Configuring the SSH server is a balance between ease-of-use and security. For the purposes of using it with HEEDS where it will be operating within an internal network between company machines, the default settings are adequate. For more information regarding configuring an SSH server see here or here. Starting the SSH Server 1. Once the installation and configuration is complete, you can start the SSH process with the command: sudo service sshstart 2. To ensure the process is running, use the command: ps -A grep sshd Which should produce a line yielding the process ID. 2
On Local Machine A On Local Machine A Local Machine A Installing PuTTY PuTTY is the recommended file transfer application by Red Cedar Technology, serving as the SSH client on Local Machine A. 3. To download PuTTY, navigate here and choose the Windows installer as shown below. 4. Run the downloaded installer with all of the default settings. 3
Setting up a Windows-to-Linux Compute Resource Testing the Connection between Machines Having installed PuTTY on Local Machine A and started the SSH Server on Remote Machine B, we should now be able to communicate between the two machines. 1. On local Machine A, launch PuTTY by navigating to Start->All Programs->PuTTY->PuTTY. 2. If you have successfully started a privileged server on Remote Machine B, you should now be able to establish an SSH connection to that machine via PuTTY. In the Host Name (or IP address) field, enter either the host name or the IP address of Remote Machine B, and click Open. If the host name does not work, use the IP address. 3. Login in using the user name and password needed to log in to Remote Machine B. Now that you have created a communication link between the two machines, it is necessary to establish a method of passwordless authentication entry so that a login prompt doesn t appear every time that you want to access the remote Windows workstation. The steps required to support this passwordless entry are described next. 4
Creating Passwordless Entry to Remote Machine B using RSA Keys Creating Passwordless Entry to Remote Machine B using RSA Keys PuTTY also serves the purpose of securely passing data to Remote Machine B via RSA keys (passwordless login). In order for HEEDS to exchange data with Remote Machine B, it is required that HEEDS not get prompted for a password, which PuTTY facilitates. Machine A Communications Enabled Machine B Contains contents of Machine A public key Machine A private key (id_rsa) Authorized Keys File (authorized_keys) Machine A public key (id_rsa.pub) Known Hosts file (known_hosts) Contains entries for machines B and C Machine C Contains contents of Machine A public key Authorized Keys File (authorized_keys) Figure 1: Public and Private Key File Setup Figure 1 shows the standard names and locations of folders and files generated during this process. In the example shown, a user would be able to login with a password from Machine A to Machine B and from Machine A to Machine C. The important points to know are: The private key for Machine A never leaves Machine A The public key for Machine A will need to be included in the authorized_key file for any machine it will be connecting to The first time a connection is made, the user is prompted to accept the authenticity of the host machine. If accepted, this creates an entry in the known_hosts file on Machine A. This must be done for each host machine and manually before trying to connect using HEEDS. 5
Setting up a Windows-to-Linux Compute Resource Create Private and Public Keys on Local Machine A Local Machine A 1. On local Machine A, go to Start->All Programs->PuTTY->PuTTYgen. 2. In PuTTYgen, click Generate and follow the instructions by moving your mouse around the blank area to produce an encrypted key. 3. Once the key is created, click Save private key and save it to a known location that you will access later. Optionally, provide a password to save with the key. The private key will be the enabler on the local machine to get access to the remote machine. 4. Copy all of the contents in the Public key field by first clicking and dragging to highlight the contents of the window and then press Ctrl+C (or right-click and Copy). We will place it on Remote Machine B such that when Local Machine A tries to gain access to Remote Machine B, it is granted without being prompted for a password. 6
Creating Passwordless Entry to Remote Machine B using RSA Keys 7
Setting up a Windows-to-Linux Compute Resource Copy Public Key to Remote Machine B Remote Machine B 1. If the remote session established in step 3 in Testing the Connection between Machines is still up, continue to the next step. If not, please follow all of the steps in Testing the Connection between Machines to establish a remote session on remote Machine B. 2. Using the text editor vi, create a temporary file to store your public key by using the command: vipubkey 3. Enter the interactive mode in vi using the i key. Right-click in the window. This should copy the contents of the clipboard (the public key) into the vi window. The editor should look similar to the window below: 4. Exit interactive mode by pressing the Esc key. 5. Save and quit vi by typing: :wq 6. Append the contents of the temporary file to your authorized keys file and remove the temporary file by using the commands: catpubkey>>.ssh/authorized_keys rm f pubkey 7. Close the PuTTY session by issuing the command: exit 8. Close the PuTTYKey Generator. 8
Creating Passwordless Entry to Remote Machine B using RSA Keys Enable and Test Passwordless Access with Pageant on Local Machine A: Local Machine A 1. On Local Machine A, open Pageant (Start->All Programs->PuTTY->Pageant). Pageant is a PuTTY SSH authentication agent. Pageant becomes active in the Windows Notification Area in the bottom right-hand corner of your screen. Right-click and choose Add Key. Pageant Icon 2. Navigate to the private key that you saved in PuTTYgen (step 3in Create Private and Public Keys on Local Machine A)and click Open. 3. On Local Machine A, close and reopen PuTTY and log in to Remote Machine B as before. You will be prompted to enter a username but you should be able to log in without the need for a password. If successful, this indicates that the SSH Server-Client relationship is established and the RSA keys are working as intended. If unsuccessful, then passwordless entry will not work and you should review the steps above.heeds will not be able to communicate effectively with Remote Machine B if unsuccessful. 9
Setting up a Windows-to-Linux Compute Resource Setting up Remote Execution in HEEDS Up to this point, you have created a communication protocol between a Windows workstation and a Linux machine and allowed proper passwordless authentication. Now, you need to instruct HEEDS how to make use of this information via a compute resource to perform design studies. Local Machine A Creating a Remote Profile A remote profile provides HEEDS the information it needs to connect to a remote machine. In defining a Remote Profile you will provide HEEDS with the necessary information for data transfer to Remote Machine B. 1. Open HEEDS on Local Machine A and navigate to File->Options->Remote Profiles. Click the +button to add a new Remote Profile. Change the name of the profile to something relevant (using your username and the machine name of Remote Machine B is a good practice). Remote profiles 2. Next, fill in the relevant information for the newly created Remote Profile as described below: a. In the remote host name and remote user name fields, you should fill in the information used to login to Remote Machine B. b. Choose Specify remote location to store study data. This is where HEEDS will copy the study data in order to execute analyses on the remote machine. If you have a shared drive between the two machines, choose Uses shared drive resource to access local study data. c. Next, you will define the SSH command field. This field will be populated with a utility that comes with the HEEDS 2015.11 and newer installers. In the image below, %HEEDSVersion% would be replaced with your HEEDS version (i.e., Ver2015.11) and %PLATFORM% with version of Windows (i.e. Win64). Alternatively, you can navigate to the appropriate location and select the plink.bat file provided. d. Lastly, you should fill in the proper SCP command, which points to the pscp.exe file found in the install location of PuTTY. 10
Setting up Remote Execution in HEEDS This completes the definition of the Remote Profile so that HEEDS can access Remote Machine B, copy relevant files, execute analysis tools, and copy results back to Local Machine A, making use of PuTTY and Pageant on Local Machine A and an SSH server on Remote Machine B. The last step is to tell HEEDS how jobs should be executed on Remote Machine B (the Linux machine). If Remote Machine B is a workstation, HEEDS can execute processes directly. If the machine is a cluster, HEEDS can integrate with various queuing systems to submit jobs to a queue, monitor their progress, and check for their completion. The next section is broken into three parts based on the execution method. Using Direct Submission for a Compute Resource Direct submission should be used if the compute resource does not have or require a scheduler (queuing system). This scenario treats Remote Machine B as a secondary Linux workstation 1. Create a compute resource for Remote Machine B. In HEEDS, navigate to File->Options->Compute Resources. Click + and add a Direct Cluster compute resource. Name the compute resource using the machine name and method as shown below: 2. Check the box for Remote Execution and select the remote profile created in the previous section. That completes the setup of the compute resource for Remote Machine B. The next portion describes how to use the compute resource for an analysis in a HEEDS process. 3. In the Analysis details, select the Compute resource from the list as shown: 11
Setting up a Windows-to-Linux Compute Resource 4. Enter the execution command keeping in mind that it will be executed in the Linux environment and should use Linux path separators (forward slashes) and Linux commands and syntax. The example shown previously uses the cp command to copy the input file to the output file. Note: The example shown will operate serially, but can easily be extended to run in parallel by increasing the Num. designs to execute simultaneously value. 5. A completion check must be defined for remote execution processes. For the example execution command, the completion check is successful if the output file exists: Once the study is started, HEEDS will use PuTTY and its utilities to move the input files to the remote machine, execute the process, check completion, and copy the output files back to Local Machine A. 12
Setting up Remote Execution in HEEDS Using a Scheduled Cluster with PBS Professional for a Compute Resource If your queuing system is PBS Pro, then the steps below should be utilized to integrate HEEDS MDO with your scheduler via a compute resource. 1. Create a compute resource for Remote Machine B. In HEEDS, navigate to File->Options->Compute Resources. Click + and add a Scheduled Cluster compute resource. Name the compute resource using the machine name and method as shown below: 2. Fill in the relevant information for the compute resource as described below. There are two main ways to check completion of a job using a queuing system. The first is to check for the job ID in the list of queued and running jobs. The second is to check the existence of an output file. As the second method is nonunique to scheduled clusters, it will not be described here. a. Check the box for remote execution and select the remote profile created above. b. Enter the job submit command (for PBS, this is qsub) and the command flag to set the job name (for PBS, this is N). Alternatively, you can select PBS Commands Only from the Pre-Defined Commands menu to use the most common options. c. Enter a prefix to use in the job name. This should be a short set of characters that can be used to easily identify jobs submitted by HEEDS. d. If using the queue status to check for job completion, check the box for Read Job ID. Enter any string that prepend or append the job ID that is returned upon job submission, so that HEEDS can store them and extract the job ID using qstat. In the example below, when a job is submitted to the queueing software the return value is ID.I96. For example, if the ID was 1234 what would be returned is 1234.I96. e. If using the queue status to check for job completion, define the Default Finished Condition using the command qstat for PBS and select Job ID for how the job is found. 13
Setting up a Windows-to-Linux Compute Resource That completes the setup of the compute resource for Remote Machine B. The next portion describes how to use the compute resource for an analysis in a HEEDS process. 3. In the Analysis details, select the Compute Resource from the list as shown: 4. Enter the command that will be executed by the queuing system. Typically this is a script that sets up the run environment, chooses the compute nodes to run on, and executes the analysis process. Ensure that this script is chosen as an input file so that it is copied to the remote machine. Many times this script will call a script generated by HEEDS to update the analysis with new parameter values and extract the appropriate responses. For example, STAR-CCM+ analyses will typically use the updatestarccmmodel.java file as shown below: 5. Define a completion check for the analysis. If using the queue status as a completion check, it will default to the command specified in the Compute Resource defined previously. 6. Note that the maximum execution time set in the advanced section shown above will include both queued time and run time. Once the study is started, HEEDS will use PuTTY and its utilities to move the input files to the remote machine, submit the job to the queue, check completion, and copy the output files back to Local Machine A. 14
Setting up Remote Execution in HEEDS Using a Scheduled Cluster with LSF for a Compute Resource If your queuing system is LSF, then the steps below should be utilized to integrate HEEDS MDO with your scheduler via a compute resource. 1. Create a compute resource for Remote Machine B. In HEEDS, navigate to File->Options->Compute Resources. Click + and add a Scheduled Cluster compute resource. Name the compute resource using the machine name and method as shown below: 2. Fill in the relevant information for the compute resource as described and shown below. There are two main ways to check completion of a job using a queuing system. The first is to check for the job ID in the list of queued and running jobs. The second is to check the existence of an output file. As the second method is non-unique to scheduled clusters, it will not be described here. a. Check the box for remote execution and select the remote profile created above. b. Enter the job submit command (for LSF, this is bsub) and the command flag to set the job name (for LSF, this is J). Alternatively, you can select LSF Commands Only from the Pre-Defined Commands menu to use the most common options. c. Enter a prefix to use in the job name. This should be a short set of characters that can be used to easily identify jobs submitted by HEEDS. d. If using the queue status to check for job completion, check the box for Read Job ID. Enter any string that prepend or append the job ID that is returned upon job submission, so that HEEDS can store them and extract the job ID using bjobs. In the example below, when a job is submitted to the queueing software the return value is ID.I96. So for example if the ID was 1234 what would be returned is 1234.I96. e. If using the queue status to check for job completion, define the Default Finished Condition using the command bjobs -w for LSF and select Job ID for how the job is found. 15
Setting up a Windows-to-Linux Compute Resource That completes the setup of the compute resource for Remote Machine B. The next portion describes how to use the compute resource for an analysis in a HEEDS process. 3. In the Analysis details, select the Compute resource from the list as shown: 4. Enter the command that will be executed by the queuing system. Typically this is a script that sets up the run environment, chooses the compute nodes to run on, and executes the analysis process. Ensure that this script is chosen as an input file so that it is copied to the remote machine. Many times this script will call a script generated by HEEDS to update the analysis with new parameter values and extract the appropriate responses. 5. Define a completion check for the analysis. If using the queue status as a completion check, it will default to the command specified in the Compute Resource defined previously. 6. Note that the maximum execution time set in the advanced section shown above will include both queued time and run time. Once the study is started, HEEDS will use PuTTY and its utilities to move the input files to the remote machine, submit the job to the queue, check completion, and copy the output files back to Local Machine A. 16
Notes Notes While this process only needs to be setup one time, you will need to re-host the private key in Pageant if the Local Machine A is restarted. It is good practice to ensure the key is being hosted before beginning a study. If the key is not hosted and Pageant is not running, HEEDS will not be able to establish a password less connection to the remote machine. 17
Setting up a Windows-to-Linux Compute Resource Troubleshooting SSH Doesn t Connect to Remote Machine This section is applicable if you are not able to login to your remote machine. 1. Ensure that you are using the fully qualified domain name. For example, if the hostname is machinea, trying using machinea.city.company.com (using your company s format as appropriate). The command ping is useful for diagnosing this as shown below for a success ping of Red Cedar Technology s external website: 2. If you are still unable to connect, try temporarily disabling the firewall on both machines. If connections are possible without the firewall, this means the inbound and outbound exceptions for ssh were setup incorrectly. Passwordless Connection is Unsuccessful Read this section if you have followed the instructions in the sections above and you are still being prompted for a password when trying to ssh to the remote machine. The issue is most likely in the setup of the authorized_keys file. 1. If using PuTTY and Pageant, ensure that the RSA key was copied and uploaded to the authorized_keys file successfully. Do this by ensuring the RSA key is written on a single line by itself, that it begins with ssh-rsa and that it matches the values found in PuTTY when creating the key. 2. Once this is verified, the next step is to ensure that you are the owner of this file. First log in to the Remote Machine B using PuTTY and your password Navigate to the.ssh folder with the command cd ~/.ssh Enter the command ls l to view the permissions and the ownership information (the l in the command is a lowercase L) 3. Finally, ensure that the file permissions are set to read and write for the owner only. On the same window you used for Step 2, enter the command ls l (the l here is a lowercase L) to view permissions and ownership. The above screenshot shows the files in the current folder. The filenames are found in the last column. The file, authorized_keys, is the first row. The first column of data corresponds to the permissions of the file and 18
Troubleshooting the second its ownership. The current permissions are set to none, as denoted by the ----------. The correct permissions are -rw-------. To update the permissions, enter the command chmod 600 authorized_keys. The above screenshot shows permissions changed to both read and write, denoted by the -rw-------. Next, column 2 shows that current ownership of the file belongs to Administrators. This ownership needs to match the username defined in HEEDS to access Remote Machine B. In this instance, the username is Tester. To change ownership, enter the command chown %username% authorized_keys. Where %username% corresponds to the username, in this instance Tester. Now column 2 shows correct ownership and permissions to access the authorized_keys file. Ensure these steps are done on.ssh folder as well. The user should now be able to log back in through PuTTY without using their password. Errors Writing Files on Remote Machine This section is applicable when files are not successfully copied to the remote machine. 1. Ensure the drive selections in the remote profile are correctly defined. If a project is one a shared drive and the profile definition specifies a remote drive, HEEDS will write the updated files but they will be empty. This will cause the analysis to fail with empty input files. 2. If using a remote drive, ensure the host location path exists, is correct, and does not end with a / if using Linux. 3. Ensure permissions are appropriate on the remote directory to allow files and directories to be created. Errors Executing Commands on Remote Machine This section is applicable when files are able to be copied to the remote machine, but errors occur when executing the analysis commands successfully. When this occurs, the Tool Output message will contain only output from HEEDS and not any output from the analysis tool. 19
Setting up a Windows-to-Linux Compute Resource 1. Try disabling Capture output from utilities which is located in the Run Options. If this solves the issue, but the user would like this output to be captured, the default login shell for the remote machine should be changed using the chsh command to bash or csh. 2. Occasionally the environment that HEEDS sees can be different from that seen when logged in manually to the remote machine. The main results of this can be a lack of properly defined environment variables. To remedy this, modify the execution command to set the variables needed before the execution command. For example, in bash, the following could be used: export SGE_ROOT="/opt/sge"; echo $SGE_ROOT; /submit.sh where the missing environment variable is SGE_ROOT which is needed by a command within the submit.sh script. 20
Example Study Example Study In the above example, both NX CAD (from Siemens PLM) and GT-Power (from Gamma Technologies, Inc.) are executed on Local Machine A. ANSYS Mechanical (from Ansys Inc.), Abaqus (from DassaultSimulia), STAR-CCM+ (from CD-adapco), and JMAG (from JSOL) are all solved remotely on Remote Machine B. This is denoted by the image seen in the top right hand corner of an analysis. This icon depicts the use of a direct cluster. Note that scheduled clusters could be substituted for this example. The execution order is broken down further in the table below. HEEDS Example Study Execution Execution Order Analysis Tool Compute Resource 1 NX CAD Local Machine A 2 ANSYS Remote Machine B 3 Abaqus Remote Machine B 4 STAR-CCM+ Remote Machine B 5 JMAG Remote Machine B 6 GT-Power Local Machine A 21
Setting up a Windows-to-Linux Compute Resource This software and related documentation are proprietary to Siemens Product Lifecycle Management Software Inc. 2018 Siemens Product Lifecycle Management Software Inc. Siemens and the Siemens logo are registered trademarks of Siemens AG. NX, Solid Edge, and Teamcenter are trademarks or registered trademarks of Siemens Product Lifecycle Management Software Inc. or their subsidiaries in the United States and in other countries. All other trademarks, registered trademarks, or service marks belong to their respective holders. 22