[FreeNX-kNX] ssh problems gone, now real freenx problems
John Logsdon
j.logsdon at quantex-research.com
Tue Aug 9 19:36:15 UTC 2005
Remove the client-side .nx directory in (conventionally) /home/user/ ie
rm -rf /home/clay/.nx
Then type nxclient and it will force the wizard to
re-install everything. Unless there is anything particularly useful in
all the cache files you haven't lost anything and your backup routine is
saved some work...
Sorry I wasn't clearer!
\J
John Logsdon "Try to make things as simple
Quantex Research Ltd, Manchester UK as possible but not simpler"
j.logsdon at quantex-research.com a.einstein at relativity.org
+44(0)161 445 4951/G:+44(0)7717758675 www.quantex-research.com
On Tue, 9 Aug 2005 freenx at claymccoy.com wrote:
> Okay, which nx directory? The one on the client side in the users hoem
> directory?
> Thanks,
> Clay
>
> > I have only just got round to subscribing to this list since Gian Fillipo
> > had to stop the original NX list which I understand but is still a pity.
> >
> > Similar ssh problems come up with native NX as well, which is what I am
> > running (1.5.0).
> >
> > It happens for example when you reinstall or upgrade the server or do
> > anything that regenerates the key pair. The easiest way that I have found
> > to get round this is to remove the .nx directory completely (ie rm -rf
> > .nx).
> >
> > The next time you initiate the client, the wizard is invoked and this
> > forces a new copy of the public key to be taken.
> >
> > HTH
> >
> > John
> >
> > John Logsdon "Try to make things as simple
> > Quantex Research Ltd, Manchester UK as possible but not simpler"
> > j.logsdon at quantex-research.com a.einstein at relativity.org
> > +44(0)161 445 4951/G:+44(0)7717758675 www.quantex-research.com
> >
> >
> > On Mon, 8 Aug 2005, Clay McCoy wrote:
> >
> > > Thanks for all the help. Somehow ssh started working. I noticed there
> > > was a new rpm, so I completely removed the old one, installed then new
> > > one, and I noticed that the key was different. So I moved this new key
> > > generated from the new rpm over and now I can ssh with a key as nx.
> > > Thanks for all the great explanations, I learned a lot.
> > >
> > > But FreeNX still does not work. It seems brittle in the sense that
> > > something different happens every time, without me changing anything. I
> > > got a lot of one time errors that never repeated themselves. One told
> > > me to look in the sshlog file in a "temp" folder in the users directory
> > > on my client machine.
> > >
> > > I got this a lot:
> > >
> > > ----------------------------------------------------------------------------
> ------------
> > > NXPROXY - Version 1.5.0
> > >
> > > Copyright (C) 2001, 2005 NoMachine.
> > > See http://www.nomachine.com/ for more information.
> > >
> > > Info: Proxy running in client mode with pid '178'.
> > > Error: Failed to set TCP_NODELAY flag on FD#19 to 1. Error is 102
> > > 'Operation not supported on socket'.
> > > Info: Aborting the procedure due to signal '15', 'SIGTERM'.
> > > ----------------------------------------------------------------------------
> ------------
> > >
> > > It doesn't seem to matter if I "disable no-delay on TCP connection" or
> > > not. So I left it unchecked.
> > >
> > > Then I left "Enable SSL encryption of all traffic" unchecked, and I got
> > > this:
> > >
> > > ----------------------------------------------------------------------------
> ------------
> > > NXPROXY - Version 1.5.0
> > >
> > > Copyright (C) 2001, 2005 NoMachine.
> > > See http://www.nomachine.com/ for more information.
> > >
> > > Info: Proxy running in client mode with pid '192'.
> > > Info: Connecting to remote host '192.168.0.3:5000'.
> > > Info: Connection to remote proxy '192.168.0.3:5000' established.
> > > Info: Synchronizing local and remote caches.
> > > Info: Handshaking with remote proxy completed.
> > > Info: Using cache parameters 4/262144/8192KB/8192KB.
> > > Info: Using image cache parameters 1/1/32768KB.
> > > Info: Using wan link parameters 16384/8/4/20.
> > > Info: Using pack method '16m-jpeg-9' with session 'unix-kde'.
> > > Info: Using ZLIB data compression level 1.
> > > Info: Using ZLIB data threshold set to 32.
> > > Info: Not using ZLIB stream compression.
> > > Info: Using remote ZLIB data compression level 1.
> > > Info: Not using remote ZLIB stream compression.
> > > Info: No suitable cache file found.
> > > Info: Using remote server '192.168.0.3:5000'.
> > > Info: Starting X protocol compression.
> > > Error: Failed to set TCP_NODELAY flag on FD#25 to 1. Error is 102
> > > 'Operation not supported on socket'.
> > > Info: Established X server connection.
> > > Info: Using shared memory support in X server.
> > > Info: End of session requested by signal '15' 'SIGTERM'.
> > > Warning: Parent process appears to be dead. Exiting watchdog.
> > > ----------------------------------------------------------------------------
> ------------
> > >
> > > And if I logon again right after that without changing anything the
> > > window of the application actually comes up! But when I resume the one
> > > session in the list, it times out.
> > > "Timeout encountered in communication with the NX server."
> > >
> > > I have followed the directions on:
> > > http://fedoranews.org/contributors/rick_stout/freenx/
> > > I am using fedora core 4 and the mac os X nomachine client.
> > >
> > > Any help is appreciated,
> > > Thanks,
> > > Clay
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > FreeNX-kNX mailing list
> > > FreeNX-kNX at kde.org
> > > https://mail.kde.org/mailman/listinfo/freenx-knx
> > >
> >
> > _______________________________________________
> > FreeNX-kNX mailing list
> > FreeNX-kNX at kde.org
> > https://mail.kde.org/mailman/listinfo/freenx-knx
> >
More information about the FreeNX-kNX
mailing list