Bug 280403

I can't tell you anything about the intention of the patches either. And it does not make sense to add broken patches to our FreeNX package. BTW, I'm wondering that NX/FreeNX works for you at all on openSUSE 10.2. I finally 
gave up. :-(

OK, for the record.... it wasn't easy. I abandoned the nomachine.com rpms, (in case the follwoing does not work, they are installed but not used explicitly, so try installing them, then repeating the steps below, if the following fails)
I now have something kind of working (remaining issues seem to relate to KDE, see Bug #280789, Bug #280954, Bug 280901):

A) I'm not sure if this is required... but I had completed the following (excluding the pam_ssh component):
http://en.opensuse.org/Using_ssh-agent_globally_for_X_session

1) Install FreeNX and Knx (accept any dependencies).
2) Open port 22:tcp in suse firewall (you can use another port but first get the vanilla set-up working... then try find your way around the bizarre config file locations... hint to SuSE)
3) edit the nxsetup script:
   - search for 'suse', around line 179 (depending on versions?).  Make the following one line change (I don't know about luseradd... ?):

		# Is it a SuSE?
		elif [ -f /etc/SuSE-release ]
		then
			USERADD_OPTIONS="-r $USERADD_OPTIONS"
		fi
		
		if [ "$SETUP_LOCAL_USER" = "yes" ]
		then
			! nx_group_exists && lgroupadd $GROUPADD_OPTIONS nx 
			luseradd $USERADD_OPTIONS nx
		else
			! nx_group_exists && groupadd $GROUPADD_OPTIONS nx
			useradd $USERADD_OPTIONS nx
++++                    passwd -d nx
		fi

In /etc/nxserver/node.conf, set:
    NX_LOG_LEVEL=7
    NX_LOGFILE=/var/log/nxserver.log
    SESSION_LOG_CLEAN=0
    AGENT_EXTRA_OPTIONS_X="-fp /usr/share/fonts/misc:unscaled,/usr/share/fonts/Speedo,/usr/share/fonts/Type1,/usr/share/fonts/75dpi:unscaled,/usr/share/fonts/100dpi:unscaled"

(you may or may not need the AGENT_EXTRA_OPTIONS_X setting.  To find out try without and then, irrespective of successful connection or not, look in:
    /home/<your_uname>/.nx/<C,S,F-C,T-S>-<some>-<other>-<data>/session

This will show you what was going on from the X side of things - a problem with X _can_ lead to a NX/KNX dialog suggesting network problems - so make your first connection to you local `hostname` :)

4) For a 'un-secure' but automated setup run:

   nxsetup --install --setup-nomachine-key --clean --purge

Once this is good you can try to get your own keys:
   nxsetup --install --setup-nomachine-key --clean --purge

5) The install tests should pass or give hints about what you need to do to configure sshd correctly.  Hint place nx in AllowUsers (if you employ that restriction)

6) In the KNX client you should be able to make a connection to <your-local-hostname>

HTH

Another two hints, I don't know if you could put this down as a bug....?

Hint 1:
=======
If you move on from just making local connections on the same machine then you will need to open up port 5000:tcp.  More for more connections.

Not great, but maybe you can  use the knockd daemon and knock client to open ports - would be good to add the knock client facility into the KNX connection parameters, may be secured with some  pass word/passphrase/private key?  anyway back to the topic.....

What happens if one of the '5000+' range of ports is currently occupied? I don't know.

Hint 2:
=======
If you want to connect to more than one remote machine you should just add the remote host's private key to the client machines authorized_keys2 file:

You'll need to look in the remote hosts & clients nxsetup script or nxloadconfig file to work out where these are.... it seems to differ between distributions and even arch.... but they are consistently bizarre locations  - to my mind at least :)

So you don't use the openSUSE NX/FreeNX RPMs at all? 

It's the nomachine client I gave up using, and since that is what the url refers to this thread should probably be closed - up to you.
the FreeNX/KNX combination don't seem to allow you to leave a session running.
Close the report if you like.

I'll let this bugreport open if you can reproduce this issue with the openSUSE FreeNX/NX RPMs.

http://software.opensuse.org/download/NX/openSUSE_10.2/i586/

I can reproduce this issue with the openSUSE FreeNX/NX RPMs.

So besides from resume session times out the openSUSE NX/FreeNX RPMs work for you.

Should have been a question ...

So long as you don't use the nomachine client - which I discovered later.....

Can you still reproduce this issue with the current NX/FreeNX packages from our buildservice (project NX) and the nomachine client? knx is not longer supported and qtnx works for me only sometimes for some users at the moment.
I've done radical changes in our NX/FreeNX packages to get it work again.

Hmmm, is that !M client v3.0 or 2.0? I'll assume v3 unless I hear otherwise, let me know if your targeting v2.

Installation sources:
ftp.iinet.com.au//pub/suse/Suse/update/10.2
software.opensuse.org/download/NX/openSUSE_Factory/

Selecting update NX and FreeNX resulted in a unresolvable conflict for NX - file attached.

Created attachment 150158 [details]
openSUSE_Factory NX update conflict

- !M client v3.0
- use the 10.2 RPMs from buildservice to prevent the conflict

Fanatastic! resume session seems to work. 

Incase it helps... the setup:
Laptop (i5/686) LT
Frontend server (x86_64) FE
Compute node 0 (x86_64) C-0
Compute node 1 (x86_64) C-1

LT -> FE -> C-0
         -> C-1

I'm also able to start a connection from FE -> C-0 and then, while this connection is 'alive', 'resume' a session on C-0, but from C-1.  The FE -> C-0 connection is killed and the connection to C-0 from C-1 is 'resumed'.  So it all seems to work quite well!

On all machines:
  rpm --query FreeNX
    FreeNX-0.7.0-3.1
  rpm --query NX
    NX-2.1.0-126.1
  rpm --query nxclient
    nxclient-3.0.0-68

So this bug can be closed, unless there is something else you think needs to be done and checked?

Thanks for all your work Stefan.

Good to hear this. Thanks for testing.