On 8/3/2017 11:21 AM, Oliver Freyermuth wrote:
Dear condor experts, I have a set of two issues using condor_ssh_to_job in our htcondor 8.6.5 setup on CentOS 7. Our workers are in a private network, the central manager is "outside" of that in a public net, same for the submittor / schedd node. 1) It seems condor_ssh_to_job chooses some random port on the startd machine when making the reverse connection (from startd to schedd as negotiated via the CCB). This prevents firewalling - up to now, we have used shared_port successfully, but it seems condor_ssh_to_job ignores that completely. Is there any way to limit the number of ports condor_ssh_to_job will listen on on the schedd side, or make it use the shared_port_daemon? If not: How to configure a firewall on the schedd side? Is it possible at all when condor_ssh_to_job should be usable?
Hi Oliver,Yes, you can use shared_port on your submit (schedd) machine, setup your firewall to only allow port 9618, and still have condor_ssh_to_job work with CCB. To make it all work together this way requires that you change the permissions on the directory used by shared_port like so:
chmod 1777 /var/lock/condor/daemon_sock(/var/lock/condor is the default, you may need to do "condor_config_val LOCK" to get the actual path HTCondor lock directory).
To understand why this is needed and why it works, read the wisdom for knob DAEMON_SOCKET_DIR in the HTCondor Manual, available at URL http://bit.ly/2u4Jt1F
2) SELinux policies prevent running ssh-keygen on the startd machine. SELinux denies permission to write the generated keys to /pool/condor/dir_<PID>/.condor_ssh_to_job_1/ . Is this already fixed in a new version of HTCondor? This breaks on CentOS 7 out of the box.
Ugh. Thank you for investigating and reporting this. We will make a ticket on the wiki.htcondor.org to address this for the next release, and include a work-around in the ticket until the new version is released. Tim T will post the ticket URL here shortly.
thanks and regards, Todd