SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I have scoured the LQ threads and read the HOWTOs for a solution to this vexing problem and have hit a wall. I use REALVNC viewer on a Windows box to remotely access a Slackware 9.1 KDE workstation. This is inside a secure network. Using the Desktop Sharing module in KDE, I am able to login to a users up and running KDE 3.1 DESKTOP (they have already logged in), and help them with whatever problem they have, close on the viewer end (me) and they go on there merry business. This works beautifully and is a boon to administrators! My problem is this: if I need to login into that same workstation, where there in no one logged in (the KDE login screen is sitting there waiting for a username and password) I cannot remotely access (vnc) this session login. Only after the user has logged in. Can someone point me in the right direction?
Not sure what your alluding to. From the VNC viewer (remote computer), I wish to log into a KDE session (the KDE login window where a user would type in his username and password. The VNC viewer cannot connect or "see" this view. I get a "cannot connect to server error 10061" on the viewer end......a catchall error message when a VNC viewer cannot be authorized to login and connect to. But, once a user on the remote end logs into KDE and gets his desktop GUI, THEN, I can connect (a VNC login screen appears on the viewer end, I supply the password, and VNC connects me to that users desktop. I am allowed to do this because the Desktop Sharing module for this user was configured by me (administrator) to allow an "uninvited" connection, as long as I authenticate with a password (no username). This works like a champ.
The reason I want to login BEFORE a user logs in to a KDE session, is to remotely do some administrative thing, to add software, updates, modify this users desktop, etc. without someone actually having to be there, logged in already. I have the capacity to wake the computer(s) up from a powered off condition (Wake on Lan) and have LILO bring them up to a KDE login screen. I just can't "see" this screen with the VNC viewer at this time so I can't login as this particular user.
I believe it is some permissions thing with the KDE session startup. I would assume that Slack and/or KDE would be locked down to anyone from being able to log in remotely without a local user already logged in and authentication already setup. I bumbled around changing permissions with the KDE files but with no joy. I loaded the Linux version of REALVNC on the remote computer but I still cannot "see" the KDE login screen.
I'm going to test telneting to this remote machine to see if I can bring up Xwindows and get the KDE login screen this way by using a terminal window and "startx". I will report back on this. The cleaner, more secure way and elegant way is thru VNC I believe....if anyone has a suggestion please post. I have seen many similar posts on this forum for just this situation but no real solutions.
i have used the KDE remote desktop module before, and i understand your problem with the kde session having to be logged in. your solution involves using a proper VNC daemon. i think im using tightvnc: http://www.tightvnc.com/
unfortunately, what you're seeking to do is difficult. or at least ive tried to do it, and found no easy answers. ive read up about people messing around with xinetd, the VNC daemon, and some special switches. but it all seemed too complicated for my liking.
the easiest option is to look at XDMCP, which is created for exactly what you want to do. it is not difficult to setup. i have documentation about it on my site, located here: http://www.partydome.us/?slackware
here's an extract of the section:
"To enable XDMCP, comment out the last line in /etc/X11/xdm/xdm-config and add a host/ip in /etc/X11/xdm/Xaccess
If using kernel 2.4.29, XDMCP will not work unless you run 'insmod ipv6' first."
i think you just run "xdm" then to start a login session manager. XDMCP is accessible through an X windows client. for windows, there are several commercial options, but im sure the cygwin port of x.org should suffice.
if you're still keen on getting a similar solution working through VNC, then i think you'll have to turn to some DOS ".bat" scripting. you could setup a script to execute a command on the remote box, through ssh (using putty), that runs Xvnc (X server displays to a VNC connection), and then runs "startkde" to display on the X server. such a setup could be done to require a username and password, in order to start the VNC session with your KDE desktop.
not a very elegant way of doing things, but thats it as far as i know. id be interested if anyone else knows a better way :>
x11vnc allows one to remotely view and interact with real X displays (i.e. a display corresponding to a physical monitor, keyboard, and mouse) with any VNC viewer. In this way it plays the role for Unix/X11 that WinVNC plays for Windows.
sometimes one wants to connect to a real X11 display (i.e. one attached to a physical monitor, keyboard, and mouse: a Workstation or a SunRay session) from far away. Maybe you want to close down an application cleanly rather than using kill, or want to work a bit in an already running application, or would like to help a distant colleague solve a problem with their desktop. This is where x11vnc is useful.
You won't be using the KDE desktop sharing anymore, although I suspect it's similar to above. Basically you can run x11vnc as a daemon to allow X connections to desktop:0. Since I have a secure network also and don't much care who views my mediabox at this time, I haven't looked into any kind of security - although presumably you could have it password protected.
I assume that since your KDE workstations (the boxes you want to remotely administer) are booting into run level 4 (graphical login), then x11vnc will allow connections to KDM or whatever GUI login you've got arranged.
You'll have to use a VNC client like realvnc or tightvnc to connect to the workstations, but otherwise, you're working practice will be the same =)
The mediabox uses GDM and autologin, so I can't honestly say I've tried it.
I've not written anything up on using this, but I'd be happy to rummage around my cluttered mind if you need any more help =)
Thanks for responding slackwh0re and piete. I tried your suggestions with XDMCP; commented out the last line in the xdm-config, added a host IP to the Xaccess script, still can't get any type of connection. I had looked at this before and it seemed promising.
Piete's x11vnc link is quite documented. My problem though is not that I can't get to a real display, I can do that (the KDE user desktop just not the initial KDE login screen). The x11vnc doc brings up some good points to ponder: X11 permissions may be one component thats preventing a vncviewer from connecting to a gui login screen. I'm clueless on where and how this environment variable becomes involved. The other thing is the port thats made available to a vncviewer, I've seen port 5900 thrown around. I would think that any port could be used, it just needs to be defined. If you look at /etc/services, there is no port defined or allocated for vnc. Do we need to look at services, ports, permissions? I think Slack has all the components already we just got to turn them on in the environment we want them to run.
did you run "xdm" after making thos changes to the conf files? you should then be able to pickup the server through a XDMCP broadcast. i got it working by using starnet's X-Win32 X server. its trialware, so give it a go at least. if you get it working, you can then try to get it working on a free alternative such as the cygwin port.
X11 permissions may be one component thats preventing a vncviewer from connecting to a gui login screen. I'm clueless on where and how this environment variable becomes involved.
X is a complex beast, and learning to understand it's client/server architecture and how permissions work will pay some serious dividends in the future. I wish I could explain X in all it's gory detail, but I'm still working off of a sort of "intuition", (Bolshivsm, some have called it) but the general gist is something like:
* You run an X-server (xinit ...)
* Using the .Xauthority file like /etc/passwd the server knows who to allow/disallow connection rights.
* On top of the server, the X-client is run (this is *not* kde/gnome/xdm/etc/etc). The client connection may be made on the same machine, or on a different one. Most of us have it on the same machine as the server.
* Running on the client is the window/login-manager
The other thing is the port thats made available to a vncviewer, I've seen port 5900 thrown around. I would think that any port could be used, it just needs to be defined.
Port 5900 is just the traditional VNC port. Some older VNC viewers didn't (/don't) give you the option to connect to a server running at any other port than 5900. The short answer: yes, any port can be used. It's just a sort of standard thing, like running HTTP over port 80: in theory, you could run it over any port. But I digress ...
If you look at /etc/services, there is no port defined or allocated for vnc.
There is no port defined or allocated for VNC in /etc/services because Slackware doesn't automatically add VNC to your list of running services. Let me try again, that statement was terribly flakey.
* inetd is a background-service deamon that runs early on.
* It kickstarts a bunch of processes; some of which are network-based (like samba-server, for example) and others are stand-alone (the cron job scheduler - i think).
* For standalone services, they just run. No ifs no buts. They just run.
* For network services: when a connection is made (the port of which is defined in /etc/services) inetd runs the service for you.
So when you connect to my FTP server, through port 21 using your FTP client, my inetd recognises that an FTP connection is being attempted on port 21 and runs the appropriate service. You try to connect to my FTP using port 80, or 5900, and the service started won't be my FTP server, it'll be apache (80) or VNC (5900) and your poor FTP client is going to get a few messages back that don't make much sense to it!
Ok, so, if any of that is useful: excellent. If not ... sorry
sorry about the feedback delay- I tried the X-win32 Client on the Windows box and was able to access a KDE login session and subsequently login via the XDMCP query from this program. This was easy to do. I have not been able to do this up until now which is great. This proves it can be done but there is a cost to this program, over 100 dollars. Thanks to Piete for this suggestion.
You can tell me if I'm wrong but this indirectly indicates that the problem or should I say capability is on the remote or view end accessing the right Xserver component (XDMCP in this case).
I think I will try the other approach with Xvnc now. I'll post my findings when I do. Thanks to all for your time!
I have now been able to both login to a KDE session AND into a users KDE session from a remote machine using REALVNC (free). Combined with both a Wake On Lan capable machine and AMD's Magic Packet utility (free), I am now able to remotely wakeup and access a Slackware 9.1 machine running REALVNC's vncserver from a Windows box (XP or Win2k) running REALVNC's viewer. This gives me the capability of starting a distant machine that is shutoff, login to a KDE session, do my admin thing and then shut it down lets say in off hours OR access a users already running KDE desktop and help them with some problem and then logoff without disrupting their session. This is all done with free software and Slackware 9.1's KDE builtin desktop sharing.
In the end this was a very uncomplicated setup and straight forward once I got the right components in place and XF86Config modifications right (simple additions to Module and Screen sections.
Keep in mind that this was within a "secure" network and only using REALVNC's authentication password facility. The security of this setup will be my next step.
As I have not seen any threads addressing this exact senario and using only what came with Slackware 9.1 and w/o complicated and convoluted workarounds I will put the steps I used in a new thread.