Description of problem: After updating to Fedora 12 my nx server is no longer functioning. I have uninstalled, reinstalled, purged, and used prayers and magic charms, to no avail. Something looks wrong with the session files to me - why does it make the file with "STDIN" in the name? Version-Release number of selected component (if applicable): freenx-server-0.7.3-15.fc12.x86_64 How reproducible: Always Steps to Reproduce: 1.Connect to freenx-server Actual results: "Connection error" Expected results: Opens new session Additional info: Here is a session output snippet: NX> 208 Using auth method: publickey HELLO NXSERVER - Version 3.2.0-74-SVN OS (GPL, using backend: 3.3.0) NX> 105 hello NXCLIENT - Version 3.2.0 NX> 134 Accepted protocol: 3.2.0 NX> 105 SET SHELL_MODE SHELL NX> 105 SET AUTH_MODE PASSWORD NX> 105 login NX> 101 User: blueh2o NX> 102 Password: NX> 103 Welcome to: xxxxxxxxxxxxxxx user: xxxxxx NX> 105 listsession --user="xxxxxx" --status="suspended,running" --geometry="1280x1024x32+render" --type="unix-gnome" NX> 127 Sessions list of user 'xxxxxx' for reconnect: Display Type Session ID Options Depth Screen Status Session Name ------- ---------------- -------------------------------- -------- ----- -------------- ----------- ------------------------------ NX> 148 Server capacity: not reached for user: xxxxxx NX> 105 startsession --link="wan" --backingstore="1" --encryption="1" --cache="16M" --images="64M" --shmem="1" --shpix="1" --strict="0" --composite="1" --media="0" --session="Arturo" --type="unix-gnome" --geometry="1024x768" --client="winnt" --keyboard="pc102/en_US" --screeninfo="1024x768x32+render" cat: /var/lib/nxserver/db/running/sessionId{(STDIN)}: No such file or directory This system is for the use of authorized users only. Individuals using this computer system without authority, or in excess of their authority, are subject to having all of their activities on this system monitored and recorded by system personnel. In the course of monitoring individuals improperly using this system, or in the course of system maintenance, the activities of authorized users may also be monitored. Anyone using this system expressly consents to such monitoring and is advised that if such monitoring reveals possible evidence of criminal activity, system personnel may provide the evidence of such monitoring to law enforcement officials. NX> 280 Exiting on signal: 15
Well so much for editing out the user info... :-(
Hey bro, I know this is gay, but try changing /etc/nx/node.conf line that reads COMMAND_MD5SUM="openssl md5" to COMMAND_MD5SUM="md5sum" and then uncommenting it if it is commented out. That seemed to do it for me. I don't know why the freenx packages appear to be so poorly maintained. This looks like a simple oversight to me.
(In reply to comment #2) > Hey bro, I know this is gay, Really? In bugzilla? Come on.
(In reply to comment #2) > try changing /etc/nx/node.conf line that reads > COMMAND_MD5SUM="openssl md5" to COMMAND_MD5SUM="md5sum" and then uncommenting > it if it is commented out. That seemed to do it for me. I don't know why the > freenx packages appear to be so poorly maintained. This looks like a simple > oversight to me. This prevented me from authenticating at all.
I'm able to get authenticated the way things are but as you can see, the server goes looking for session files with (STDIN) in the name instead of the long string I used to see.. Then it blows up and kicks me off.. It looks to me like that is where the problem is...
Looks much the same as: http://bugs.centos.org/view.php?id=1923 http://www.linuxforums.org/forum/linux-newbie/66210-freenx-session-wont-start.html
Has anyone tested the packages that were waiting for +- karma points in testing? This bug is supposed to have already been fixed there (a duplicate of bug #521090). I would like to push the packages out as is, so they will land in stable, but currently the updates system is not properly pushing packages (I think it is under maintenance). *** This bug has been marked as a duplicate of bug 521090 ***
(In reply to comment #3) > (In reply to comment #2) > > Hey bro, I know this is gay, > > Really? In bugzilla? Come on. Sorry, won't happen again.
(In reply to comment #7) > Has anyone tested the packages that were waiting for +- karma points in > testing? This bug is supposed to have already been fixed there (a duplicate of > bug #521090). > > I would like to push the packages out as is, so they will land in stable, but > currently the updates system is not properly pushing packages (I think it is > under maintenance). > > *** This bug has been marked as a duplicate of 521090 *** I can test them for you on a clean F12 i686 system possibly tonight, will that help?
(In reply to comment #8) > (In reply to comment #3) > > (In reply to comment #2) > > > Hey bro, I know this is gay, > > > > Really? In bugzilla? Come on. > > Sorry, won't happen again. That would be appreciated. Decorum aside, you'll get more bugs fixed with honey than with vinegar. :)
(In reply to comment #4) > (In reply to comment #2) > > try changing /etc/nx/node.conf line that reads > > COMMAND_MD5SUM="openssl md5" to COMMAND_MD5SUM="md5sum" and then uncommenting > > it if it is commented out. That seemed to do it for me. I don't know why the > > freenx packages appear to be so poorly maintained. This looks like a simple > > oversight to me. > > This prevented me from authenticating at all. I don't understand why this would have prevented you from authenticating, since it fixed my previously (in x86_64 F11) functioning freenx. I took the advice from a linux forum and it worked for me. In my case, I saw I was getting past the authentication part and dying on that STDIN thing. The explanation I saw was rather clear, stating the issue was a change in the "openssl md5" command's output that the freenx server scripts no longer could parse correctly. This should in theory have no effect on the authentication phase, is it not possible you might not have some other problem with your config causing this compound effect?
(In reply to comment #11) > I don't understand why this would have prevented you from authenticating, since > it fixed my previously (in x86_64 F11) functioning freenx. I believe it was a separate issue. After I removed the user account and re-created it, I was able to get in. Still doesn't fix all the gnome errors behind the scenes but I don't even want to touch that. I can get to my desktop and it's mostly functional so that's all I'm concerned with.
(In reply to comment #12) > (In reply to comment #11) > > I don't understand why this would have prevented you from authenticating, since > > it fixed my previously (in x86_64 F11) functioning freenx. > > I believe it was a separate issue. After I removed the user account and > re-created it, I was able to get in. Still doesn't fix all the gnome errors > behind the scenes but I don't even want to touch that. I can get to my desktop > and it's mostly functional so that's all I'm concerned with. Ok cool...I use KDE with my systems (except for one) and have never noticed any gnome errors, but that's probably because the one I run gnome on via freenx is not used for much.
(In reply to comment #7) > Has anyone tested the packages that were waiting for +- karma points in > testing? This bug is supposed to have already been fixed there (a duplicate of > bug #521090). > > I would like to push the packages out as is, so they will land in stable, but > currently the updates system is not properly pushing packages (I think it is > under maintenance). > > *** This bug has been marked as a duplicate of 521090 *** Well I just did a clean install of the freenx* with --enable-repo=updates-testing and all I had to do was the nxsetup --clean --install and the manual nx user unlock and voila, it worked for me. Plus I am able to suspend and resume a session without loosing the ability to launch new processes. This is a beautiful thing. The packages in testing get my thumbs up :) (except for that old time bug about the nx user being locked and not forcing an unlock, which I think the scripts should do to save unsuspecting users some trouble).