As Hugh mentioned Univa GridEngine has the port_range option and it works for both builtin and sshd configuration.
Regards, Bill. (notice: I work for Univa) > On Oct 26, 2017, at 5:43 PM, MacMullan IV, Hugh <hugh...@wharton.upenn.edu> > wrote: > > You can turn on system firewalls, and allow all inbound port TCP traffic from > all cluster nodes, only. And then open ssh ports to on-site, or some other > restricted set of subnets. Perhaps that will satisfy your InfoSec team. > > If you use Univa GridEngine, you can specify the ‘port_range’ option for the > daemons in the global configuration. > > -Hugh > > On Oct 26, 2017, at 18:42, Christopher Heiny <che...@synaptics.com > <mailto:che...@synaptics.com>> wrote: > >> On Thu, 2017-10-26 at 23:49 +0200, Reuti wrote: >>> Hi, >>> >>> Am 26.10.2017 um 23:31 schrieb Christopher Heiny: >>> >>>> >>>> Hi folks, >>>> >>>> We're using OGS 2011.11p1. qrsh has been configured to use ssh for >>>> connections. This worked fine when we were running with no >>>> firewall, >>>> but the InfoSec team recently specified that all unused ports must >>>> be >>>> firewalled (actually, a rather sensible thing to do). >>> >>> This depends on the cluster setup. The headnode which is connected to >>> the outside world needs a firewall on this interface for sure. But >>> inside the cluster, either in this interface of the headnode or the >>> nodes themselves, there is usually no need for a firewall. MPI would >>> have a similar problem (while there you can define a range of used >>> ports for some implementations). >>> >>> Are you issuing `qrsh` on the headnode of the cluster? As a direct >>> connection from the node to the machine where the command was issued >>> is necessary, often it's not a local machine outside of the cluster. >> >> Our setup consists of 10 general-use nodes that users can log into >> directly or can access via qsub (and we'd like qrsh), 50 worker nodes >> that can only be accessed via qsub (and maybe qrsh), one master node >> and one shadow master (which share some cores as worker nodes). The IT >> department didn't want the workers on private network, so all the nodes >> are on the same subnet. According to InfoSec, that means we need >> firewalls. >> >> >>> Unfortunately, it looks like qrsh chooses the ssh port at random. >>> >>> Yes. >> >> Grumble. I sure was hoping I was wrong. Perhaps the SSH tunneling >> solution some people have mentioned on the intertubes will do the >> trick. >> >> Thanks, >> Chris >> >>> >>> -- Reuti >>> >>> >>>> >>>> While InfoSec will allow a range of ports to be opened for qrsh, >>>> opening 1024..65535 definitely won't fly. Is there a way to tell >>>> GridEngine to use a certain range of ports for qrsh connections? I >>>> suspect not, but perhaps I've missed something. >>>> >>>> Thanks, >>>> Chris >>>> _______________________________________________ >>>> users mailing list >>>> users@gridengine.org <mailto:users@gridengine.org> >>>> https://gridengine.org/mailman/listinfo/users >>>> <https://gridengine.org/mailman/listinfo/users> >>>> >>> >> >> _______________________________________________ >> users mailing list >> users@gridengine.org <mailto:users@gridengine.org> >> https://gridengine.org/mailman/listinfo/users >> <https://gridengine.org/mailman/listinfo/users> > _______________________________________________ > users mailing list > users@gridengine.org > https://gridengine.org/mailman/listinfo/users William Bryce | VP Products Univa Corporation, Toronto E: bbr...@univa.com | D: 647-9742841 | Toll-Free (800) 370-5320 W: Univa.com <http://univa.com/> | FB: facebook.com/univa.corporation <http://facebook.com/univa.corporation> | T: twitter.com/Grid_Engine <http://twitter.com/Grid_Engine>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
