With the HMC 2.14 level, all FTP (and FTPS/SFTP) operations that originate in the SE really proxy thru an HMC. The HMC must have the SE defined into it and it. This means that uou need to make sure that at least one HMC can get to the FTP server that the SE wants to access. These are the only two things needed from an SE/HMC standpoint. The SE will automatically look at all HMCs defined into it and try to find one that can get to the remote server. No special configuration is needed for FTP. However, if you want to use SFTP then you will have to set up the SSH keys on the HMC that will be needed for the HMC to be able to communicate to the SFTP server. Likewise, if you want to use FTPS, then the certificates have to be set up on the HMC to allow the HMC to communicate to the server. For redundancy, it is recommended that you have at least 2 HMCs that can get to the remote servers.
The other thing you might have to do is to work with your networking people as the HMC(s) now need to be able to get to the FTP/SFTP/FTPS server(s). Since you said that you tried FTP and based upon the "host unreachable" message, I think you need to check to make sure that you have at least one HMC that can get to the FTP server and that has this specific SE defined into it. If the host you are trying to reach is a symbolic name, then you might also want to review the DNS setups. You then asked what happens if you have an SE userid of SYSPRG2 and an HMC userid of SYSPRG2. These are really separate. They can have different passwords. If you walk up to the HMC, you are using the SYSPRG2 userid on the HMC, so you use that password. If you walk up to the SE, you are using the SE's SYSPRG2 userid and therefore you would use that password. Now if you are on the HMC as SYSPRG2 and use Single Object Operations, then the HMC manages the logon to the SE and effectively you will log into the SE as the SE's SYSPRG2 userid. Now if you don't have a userid on the SE with the same name as the SE (in your next example, the one that is the sum of ACSADMIN and SYSPROG), then the Single Object Operations code will wind up using an ID based upon the permissions of the made-up id. In this case, you are reporting that it chose SooAcsadmin. That is basically the ACSADMIN and as you know, its tasks are different that SYSPROG. Unfortunately because the SE and HMC have separate userid databases, there is no simple solution. You could create an SE-based ID with the same name as the permissions you want, but the drawback is the work you would have to do. Alternatively, you could create and use different HMC userids; one for SYSPROG and one for ACSADMIN and use the appropriate userid when you want to access the SE via Single Object Operations. Finally, regarding your hostile HMC topic. If this is a concern, then you should set up Domain security (now the hostile HMC would have to know settings) and/or prevent a hostile HMC from accessing your SEs via the network. This could be via your network router (most current network routers have the ability to restrict who can physically access a network), firewalls, etc.., or even ensuring physical security to the network in your server room (and no way to access the SEs from outside of the secure area) or some combination of all of the above. So, as an example, maybe in your case your networking people can set up your network to only allow devices with specific mac addresses (i.e. your SEs and HMCs) and you can set up domain security. Then the only way a hostile HMC could get access would be if the network was updated to allow it to be on the network and if the hostile HMC knew the correct security information Tom ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
