判明したように、OSXのサーバーバージョンには、ターミナルセッション（GUIとのいくつかのリモート接続）などの便利な機能が含まれていません。 一方、複数のユーザーが同時にGUIを使用できます（ユーザーの簡易切り替えを使用）。 今日、私はこのメカニズムを掘り下げ、それを最大限に活用することにしました。
少し理論的な部分。 WindowServerは、OSXのすべてのグラフィカルセッションを担当します。これは、ビデオカードと通信し、レンダリング要求を受け入れ、実際に画像を描画するメインで唯一のプロセスです。 一見、X11サーバーのように見えます。
主な違いは、特にユーザーセッションが複数のloginwindowプロセスを保持することです。 主要なものはWindowServerによって（rootユーザーから）起動され、対応するユーザーのレベルまで認証および引き下げられます。 アクティブなユーザー（セッションが物理モニターに表示されるユーザー）は、「コンソール」フラグのあるログインウィンドウを受け取ります。 ユーザーの簡易切り替えを介して別のユーザーに切り替えようとすると、WindowServerはコンソールステータスを削除し、新しいログインウィンドウを作成し、すべてが繰り返されます。 ユーザーを切り替えるとき、WindowServerはコンソールに必要なloginwindowプロセスを作成します。
だから、最初の問題。 ユーザーの簡易切り替えはVNC / RDCにとって非常に不格好であり、多くの場合GUIをまったく無効にします。
バグは Apple に送信され、重複としてクローズされました。 私が見つけた最初の回避策は
killall -9 WindowServer
、これは問題の解決を保証し、同時にすべてのグラフィカルセッションを
killall -9 WindowServer
ました。これは絶対に受け入れられませんでしたが、少なくともGUIの制御を取り戻しました。 2番目の回避策-コンソールloginwindowセッションを強制終了-ははるかに効率的であることが判明しました。 次回の再起動時に、バグは予期せず消えました（ただし、ユーザーの簡易切り替えを最初に使用する前）。
したがって、サーバー上のGUIを任意の数のユーザーがリモートで使用できるようになりましたが、一度に1人のユーザーしか使用できませんでした。 悪くはないが、面白くない。 もちろん、これによりiPhoneアプリケーションの単体テストなどのいくつかの問題が解決しました（ibtoolは基本的にアクティブなユーザーGUIセッションがないと機能しないため、xibをコンパイルできません）。
Appleが実装したVNCとRDCはどちらも同じように機能します。 面白くなりましたが、舞台裏に残っている「バックグラウンド」ログインウィンドウで何が起こるのでしょうか？ この質問に対する答えは、 OSX用の独立したVNCサーバーであるOSX VNCによって助けられました。 異なるユーザーから2つのセッションを開始し、それぞれにVNCサーバーを作成しました。 判明したように、WindowServerはバックグラウンドセッションも完全にレンダリングするため、特定のユーザーをVNCサーバーに接続すると、GUIセッションで完全に作業できます。
今、この潜在的な蜂蜜の樽にタールを混ぜます。 VNCサーバーが機能するには、ユーザーがloginwindowでセッションを作成する必要があります。 これはメインVNC / RDCサーバー（およびログインウィンドウへの権限の制限）を介して実行できますが、メインサーバーでは現在のコンソールセッションを制御することができ、セキュリティ違反になる可能性があります。 VNCサーバーのユーザーはポートごとに「ハードコード」されているため、端末番号を知り、パスワードを手動で設定する必要があります（LDAPの一般的な認証ベースは忘れてください）。 このスキームは、多数のGUIセッションおよび厳しいセキュリティ条件での展開には適していませんが、100％で設定したタスクを解決します。
おそらく、時間を見つけてVNCサーバーのアグリゲーターを作成し、LDAP承認によってユーザーが最終的なVNCサーバーにアクセスできるようにするサーバールーターが1つになるようにします。 しかし、Appleがより早くターミナルセッションサポートを実装することを願っています。