OSX Terminal Server

As it turned out, the server version of OSX does not contain such a useful function as terminal sessions (several remote connections with the GUI). On the other hand, several users can use the GUI simultaneously (via Fast User Switching). Today I decided to pick it up and squeeze the maximum possible out of it.


')
A little theoretical part. WindowServer is responsible for all graphical sessions in OSX - the main and only process that communicates with a video card, accepts requests for rendering and, in fact, draws a picture. With some stretch, it looks like an X11 server.

The main difference is that user sessions specifically hold several loginwindow processes. The primary is started by the WindowServer (from the root user), performs authorization and lowers itself to the level of the corresponding user. The active user (the one whose session is drawn on the physical monitor) gets the loginwindow with the “console” flag. As soon as he tries to switch to another user through Fast User Switching, WindowServer will take away from him the status of the console, create a new loginwindow, and everything will be repeated. When switching users, WindowServer simply makes the loginwindow process necessary for the console.

So, the first problem. Fast User Switching works very loosely on VNC / RDC, often killing the GUI in general.



The bug was sent to Apple and closed as a duplicate. The first workaround I found was killall -9 WindowServer , which guaranteedly solved the problem, at the same time killing all graphical sessions, which was absolutely unacceptable, but at least returned control over the GUI. The second workshop - killing the console loginwindow session - turned out to be much more efficient. Upon a subsequent restart, the bug suddenly disappeared (however, before the first use of Fast User Switching).

Thus, it became possible to use the GUI on the server remotely by any number of users, but only by one user at a time. Not bad, but not interesting. Of course, this solved several problems, such as unit-testing iPhone applications (ibtool basically does not work without an active GUI session of the user, so you cannot compile xibs).

Both VNC and RDC, implemented by Apple, work in the same way. It became interesting, but what happens in those "background" loginwindow, which remain behind the scenes? The answer to this question helped me give OSX VNC , an independent VNC server for OSX. I started two sessions from different users and raised a VNC server on each one. As it turned out, WindowServer completely renders background sessions as well, so when you connect to a specific user with a VNC server, you can work in a GUI session absolutely fully .



Now in this potential barrel of honey, I mix the tar. For the VNC server to work, the user must create a session on the loginwindow. This can be done through the primary VNC / RDC server (and the restriction of rights to the Login Window), but the primary server allows you to control the current console session and, potentially, is a security issue. The VNC server of users is “hard” clogged by ports, you need to know your terminal number, and set passwords manually (and forget about the common authorization base in LDAP). This scheme is not suitable for a large number of GUI-sessions and deployment in strict security conditions, but the tasks that I set for it, it solves 100%.

Perhaps, I will find time and make an aggregator of VNC-servers so that there is one server-router, which by LDAP-authorization would allow access to the final VNC-servers of users. But I hope that Apple implements support for terminal sessions earlier.