[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freenx-knx
Subject:    [FreeNX-kNX] [PATCH] nxproxy-stdin as replacement for nxssh
From:       "Fabian Franz" <FabianFranz () gmx ! de>
Date:       2007-07-24 17:26:49
Message-ID: 20070724172649.195440 () gmx ! net
[Download RAW message or body]

Hello, to all client developers.

Today I have got pretty good news: We no longer "need" to use 'nxssh' to 
tunnel a nxproxy connection easily over SSH.

This means: One fork less.

One the downside we loose the ability to set options on the SSH sockets.

The two options we need for "interactive" sessions are only activated (in
openssh) if either a tty is used or X11 forwarding is activated.

On the upside those options had never been activated for the server either
and a more general solution needs to be found.

Preferably in communication with the openssh people.

As a workaround one could enable the "-X" option with a fake set DISPLAY like:

DISPLAY="xyz" ssh -X nx@host or
DISPLAY="xyz" ssh -X user@host

but there would also be changes needed on the server for that.

Anyway, here is the very small patch to nxproxy and should work already with NX \
2.1.0.

Client spawning of nxproxy instead of nxssh is then done like (in pseudo code):

if (!ssl)
    options += "connect=host:port,";

// create options file here

setenv("NX_DISPLAY", "nx/nx,options=</path/to/options/file/>:<display>");

if (ssl)
{
     dup2(ssh_fd, 0); // dup fd used to communicate with SSH to fd #0
     send(0, "bye"); // send bye command to have remote end switch
                     // to nxagent
     wait_num(0, 999);
     exec("nxproxy -stdin"); // Let nxproxy use fd #0 to communicate with ssh.
}
else
{
     send(ssh_fd, "quit"); 
     wait_num(ssh_fd, 999);
     exec("nxproxy -S");
}

So instead of sending the switch command after the "bye" we spawn nxproxy instead.

The -stdin is new and must not be used together with accept=, listen= or connect= \
options.

Alternatives to above pseudo code are to fork() off first and wait for both children \
(nxproxy and ssh), because in above pseudo code ssh is made a child of nxproxy (at \
least theoretically) ...

Or you could run a loop feeding from ssh to nxproxy and vice versa ... (via a \
socketpair)

There are endless possibilities for implementation, but the basic idea is:

Have "nxproxy -stdin" talk directly to the fd used to communicate with ssh.

This should make client development a little bit easier as most clients support \
unencrypted, but not encrypted connections.

cu

Fabian


["nxproxy-stdin.diff" (text/x-diff)]

--- Main.c.old	2007-07-18 17:39:13.000000000 +0200
+++ Main.c	2007-07-24 17:53:32.000000000 +0200
@@ -36,28 +36,47 @@
   int result = -1;
 
   char *options = NULL;
-
+  
   options = getenv("NX_DISPLAY");
 
-  if (NXTransParseCommandLine(argc, argv) < 0)
+  if (argc > 1 && strncmp(argv[1], "-stdin", 6) == 0)
   {
-    NXTransCleanup();
-  }
+	if (argc > 2)
+		fprintf(stderr, "\nMain: Warning: If -stdin is given further options need to be \
given via environment variable NX_DISPLAY and not via command line. Like \
NX_DISPLAY=\"nx/nx,options=</full/path/to/file>:<display>\"\n\n");  
-  if (NXTransParseEnvironment(options, 0) < 0)
-  {
-    NXTransCleanup();
+	if (result)
+		result = NXTransCreate(0, NX_MODE_SERVER, options);
+ 
+	// go into endless loop
+
+	if (result)
+	{
+		while (NXTransRunning(NX_FD_ANY))
+			result = NXTransContinue(NULL);
+	}
   }
+  else
+  {
+    if (NXTransParseCommandLine(argc, argv) < 0)
+    {
+      NXTransCleanup();
+    }
+
+    if (NXTransParseEnvironment(options, 0) < 0)
+    {
+      NXTransCleanup();
+    }
+
+   /*
+    * This should not return...
+    */
+
+    #ifdef TEST
+    fprintf(stderr, "Main: Yielding control to NX entry point.\n");
+    #endif
 
-  /*
-   * This should not return...
-   */
-
-  #ifdef TEST
-  fprintf(stderr, "Main: Yielding control to NX entry point.\n");
-  #endif
-
-  result = NXTransProxy(NX_FD_ANY, NX_MODE_ANY, NX_DISPLAY_ANY);
+    result = NXTransProxy(NX_FD_ANY, NX_MODE_ANY, NX_DISPLAY_ANY);
+  }
 
   /*
    * ...So these should not be called.



________________________________________________________________
     Were you helped on this list with your FreeNX problem?
    Then please write up the solution in the FreeNX Wiki/FAQ:
  http://openfacts.berlios.de/index-en.phtml?title=FreeNX_FAQ
         Don't forget to check the NX Knowledge Base:
                 http://www.nomachine.com/kb/ 

________________________________________________________________
       FreeNX-kNX mailing list --- FreeNX-kNX@kde.org
      https://mail.kde.org/mailman/listinfo/freenx-knx
________________________________________________________________

[prev in list] [next in list] [prev in thread] [next in thread]