Currently the Engineering NT Labs include an icon for XWin32 that hits a feel servers using XDMCP to “get a full session back.”
This was originally done because certain disciplines in the College still had a strong need for one or two Solaris only applications, so they were geographically shuffled to a nearby “workstation on steriods” for shared access to the machine.
Well, as part of the whole push for “remote access” and in order to get SSH and Xforwarding from a security perspective and to limit superflous things like the someone’s “Hello Kitty” background from getting pushed in a session, when the whole focus was really to connect to the “remote acces” machine for an application – we are pushing the PuTTY + XWin32 setup fromhttp://www.eos.ncsu.edu/remoteaccess (really nice user docs forthcoming) and we turned off XDMCP and telnet on the new remote access servers. We still left the old ones up because we didn’t want to change the user experience in the middle of the semester – but we did block XDMCP access to the “old hostnames” in order to limit XDMCP to the labs and added some of the labs we knew needed to access the machines. PS117 probably wasn’t included because it’s not an Eos Lab – at any rate it’s been broken since January – Tim/Wade I don’t know if you need that access in PS117 or not, or want to wait until the end of the semester.
What’s going to happen at the end of the semester is that the lab setup will be changed to a SSH+Xforwarding setup in the same vein as what we are “supporting” outside the labs.
I have no idea what ITD or other organizations plan for the Unity “login.ncsu.edu” setup or their XWin32 configuration.
Clear as mud? (I haven’t described much about XDMCP or X-Forwarding here for those that might be unfamiliar with the protocols there, that’s easier to show than to describe though). (And Yes, I know that there’s likely a CPU impact with the SSH and X-Forwarding compression and such, but I can go into why that might actually be a benefit).