Mike, Stefan, Alexander, et al.,

I was watching this conversation play out before replying.

It isn't going to be fruitful to be pulled into a long discussion about the specifics of our compute environment. There are many assumptions being made in this discussion that aren't correct, and saying "don't use TCP" without knowing these specifics is ignorant. There are industry-standard commercial products that disabling TCP breaks. Our IT department cannot decide to stop supporting TCP; it is the users and our commercial suppliers who determine what IT has to support.

I think that because I used "xhost +" in my original debugging example, the assumption was immediately made that "xhost +" was my primary concern. My primary concern is that disabling TCP breaks almost every possible use model except for one narrow case (ssh). Among other things, it breaks the MIT-MAGIC-COOKIE-1 mechanism. While there are very valid concerns regarding use of TCP on the internet, we have a different hierarchy of concerns regarding what happens on our internal network.

One incorrect assumption that is being made in this discussion is that some action to initiate the display can take place on the system the user is logged into, or that the user is even involved in initiating the display.  Consider this use model:

1: User's display is system100:24
2: Automated processes, with no user involvement, launch a program on a randomly chosen system (let's say it is system204).
3: The new program running on system204 now has to connect back to the display on system100:24

Personally, the problem is solved for us for at least the moment and we can move forward with what we are trying to do. Having to edit /usr/bin/x2gostartagent every time we install or upgrade the package is inelegant and creates additional administrative overhead, but it is manageable.

This is your project, not mine, I merely came to the mailing list with a problem looking for a solution. I can tell you that our use model is extremely common in industry and that breaking it will render X2Go unusable. Of the five alternatives we are looking at, X2Go was the only one with TCP disabled. Most system administrators trying to set up an evaluation of X2Go aren't typically going to dig further than the documentation and config files in trying to fix this problem. If you make fixing it so obscure that it escapes these system administrators, then X2Go isn't going to get very far in those evaluations.

How accessible or obscure you make this setting is up to you as developers, but saying to users "your use model is wrong" doesn't show appreciation for the diversity of ways that X is used in production.

Cheers,
Nick