Friday, February 6, 2009

Setting up a VNC remote desktop in Enterprise Linux 4, 5, and 6

This is something that is terribly useful, and there are lots of how-to articles running around. Unfortunately, I've not found one that was quite complete, especially for someone who is only just getting familiar with Linux (which is precisely when you most need a GUI!). So this is a step-by-step instruction list on getting a remote X Windows session set up on enterprise linux 4, 5, and 6 (RHEL and CENTOS) that can be accessed with VNC viewer software (do a quick search on VNC if you're not familiar with it). In some set-ups, people create a VNCSERVER process that runs all the time. This does allow for persistent sessions (sessions that survive a disconnect), but it's not really what most of us need most of the time. What we're doing here is using xinetd, which will spin up Xvnc on an as-needed basis. Much cooler. Please note: vnc is not a secure protocol. What this means is that any traffic that VNC sends over the wire is *not* encrypted. Do make sure that your use of this doesn't put you at risk for having sensitive data (passwords, for instance) compromised.

Change the RunLevel

Change the runlevel to 3. This will stop GDM (which is what we're using in this example), or whatever your GUI front-end is.
init 3

Enable XDMCP

Since we want to use Gnome, we'll make sure it's the default desktop manager. Edit /etc/sysconfig/desktop and make sure it includes the following line:
DESKTOP="GNOME"
DISPLAYMANAGER=GNOME
Now activate xdmcp: edit the /etc/gdm/custom.conf file and find the following lines (NOTE: in RHEL 4 and CentOS 4, this is in /etc/X11/gdm/gdm.conf).
[xdmcp]
# Distributions: Ship with this off. It is never a safe thing to leave
# out on the net. Alternatively you can set up /etc/hosts.allow and
# /etc/hosts.deny to only allow say local access.
Enable=false
# Honour indirect queries, we run a chooser for these, and then redirect
# the user to the chosen host. Otherwise we just log the user in locally.
change it to Enable=true

Install VNC

If you're running a stock EL 5 system, you most likely already have vncserver installed. If you are running EL6, however, you'll need to install it:
yum install tigervnc-server

Create Xinetd startup file

Make sure xinetd is installed. The easiest way is to install it:
yum install xinetd
Create a file called vncserver in /etc/xinetd.d/ with the following content. This will tell xinetd to listen on 5908 and 5910 for a desktop of 800x600 and 1024x768 respectively (I like to have the option of using a lower resolution if necessary).
Note that the service names aren't important; feel free to change them. Likewise the resolution ("geometry") can be changed to fit your needs. The server_args line is what gets passed to the Xvnc application.
 Change 'localhost' to the fully qualified domain name of your system.
 If you would like a descriptive title on the title bar of the viewer, put that text after the -desktop= piece. Heads-up: the spaces around the equals signs are important. Xinetd won't read this if you omit them.
service vnc10 {
protocol = tcp
socket_type = stream
wait = no
user = nobody
server = usr/bin/Xvnc
server_args = -inetd -query localhost -once -geometry 1024x768 -depth 16 SecurityTypes=None –desktop=<Window_Name_Here>
port = 5910
type = unlisted
}

service vnc8 {
protocol = tcp
socket_type = stream
wait = no
user = nobody
server = /usr/bin/Xvnc
server_args = -inetd -query localhost -once -geometry 800x600 -depth 16 SecurityTypes=None –desktop=<Window_Name_Here>
port = 5908
type = unlisted }
Reload the xinetd settings with service xinetd restart

Enable the service

Set up the service to start on boot Turn on xinetd
chkconfig xinetd on

Set X Permissions

You have to allow X to display for various users on the ports you've allowed. The best way to do this is to use the Xn.hosts file, where n is the display number you're using. In our case, we're using 8 and 10, so we'll create two files: /etc/X8.hosts and /etc/X10.hosts. They'll contain just one line, that is the fully qualified domain name of the server.

Go back to runlevel 5

init 5

Configure your firewall

We have to allow traffic to come in to your computer on the two ports we configured in the vncserver xinetd file. In our example, we're using TCP ports 5908 and 5910, so we'll add lines to our iptables file to allow that incoming traffic:
vim /etc/sysconfig/iptables
Having opened the firewall file, we'll add the appropriate lines:
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5908 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5910 -j ACCEPT
These two lines tell the firewall to accept TCP traffic from any source to the ports 5908 and 5910. Save your changes to the file, and then restart the firewall to pick up the additional ports:
service iptables restart
We now should be able to connect to the server using 5908 and 5910. Use the stand-alone vncviewer application to connect. VNC works by specifying ports at the end of the computer domain name (e.g., hostname:10, to connect on port 5910). Once you are connected you should have the usual graphical login screen from gnome.

Set up clipboard functionality

Xvnc doesn’t do copy/paste to the client by default; it needs a helper app to do that. This is called vncconfig.
  1. To set it up so that it runs at login, first log in (this must be done for each user who would use the system).
  2. Click on Applications (SYSTEM in CentOS and RHEL v5) and select Preferences -> More preferences -> Sessions.
  3. Click on the Startup Programs tab and click the Add button.
  4. Type /usr/bin/vncconfig -nowin in the startup command field.
The next time that user logs in, copy and paste will be supported.

Troubleshooting

Connection Closed Unexpectedly or a Black Screen

If, after doing the above, you get a “the connection closed unexpectedly” error when trying to connect, try changing the -query localhost to -query in the file in the /etc/xinetd.d dir. The safest thing, if you run into this problem (or a black screen) is to replace ‘localhost’ with the output of hostname –f on the server. It could also indicate a typo in the vncserver file in /etc/xinetd.d, so check that file closely.

Client is not authorized to connect error

If you see something like the error below, it indicates that you need to create the Xn.hosts file as referenced above. Create the file with the number indicated in the display: piece of the error. In the case below, it'd be X0.hosts file that needs to be created. You'll have to log out and back in for this change to take place (or do an init 3, init 5).
Xlib: connection to ":0.0" refused by serverXlib: server.example.com is not authorized to connect to serverError: can't open display: :0

Blank Screen after Login

If you run into a blank (usually background-colored) screen after entering your username and password, this indicates some Gnome (XWindows) session data has gotten corrupted. The easiest way to test this is to try logging in as another user. If you can do so without getting this error, here's how to fix it:
  1. Delete all files and directories beloning to the affected user in /tmp. You can focus that a little more by first deleting any file/directories that appear with the name "gnome" or "X" in them. After doing this, try logging in again. It probably will work.
  2. If #1 doesn't get things going, you may also have to delete the following files and directories from the user's home directory (typically /home/username):
.esd_auth .gconfd .gnome2_private .nautilus
.dmrc .gconf .gnome-desktop .metacity
.fonts.cache* .gnome .gnome2
.ICEauthority .gtkrc*

Gray screen only

A gray screen with no login prompt probably means you forgot to edit the desktop file at the top. It also could be an error in the gdm.conf file. Take a look at the gdm.conf (or custom.conf) file that you edited at the top and make sure the remote (or xdmcp) greeter in the [daemon] section is blank or commented out.

DBus Problems - DROM Access Denied

If you receive a message stating something like this:
A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface “org.freedesktop.Hal.Device.Volume” member “Mount” error name “(unset)” destination “org.freedesktop.Hal”)
Then you've run into this problem. The problem is corrected by adding the following lines to the end of /etc/dbus-1/system.d/hal.conf:
<policy group=" users=">
<allow send_interface="org.freedesktop.Hal.Device.SystemPowerManagement" />
<allow send_interface="org.freedesktop.Hal.Device.VideoAdapterPM" />
<allow send_interface="org.freedesktop.Hal.Device.LaptopPanel" />
<allow send_interface="org.freedesktop.Hal.Device.Volume" />
<allow send_interface="org.freedesktop.Hal.Device.Volume.Crypto" />
</policy>

43 comments:

  1. Hi,
    I've followed your instructions here, combined with the vnc setup instructions from CentOS (5.x), but when I try to connect all I get from RealVNC is 'connection refused.'

    There's not much help out there for this type of scenario, so do you have any idea what could be missing?

    ReplyDelete
  2. Michael,
    I think that VNC gives the "connection refused" error not when the system times out, but when it gets a response it's not expecting. That should rule out the firewall, but you might double-check that by making sure you can telnet to port 5910 (or whichever port you're using, specified in /etc/xinetd.d/vncserver):
    telnet hostname 5910
    Note that there's a space between the host name and the port number.

    Assuming the telnet command connects, try changing the -query localhost piece in that file to -query hostname
    where hostname is the full name of the server.
    You'll need to restart xinetd once you've made that change.

    Let us know if that made any difference. If not, I'm pretty confident we can get you going one way or another.

    ReplyDelete
  3. Michael, I also notice that I wasn't terribly clear on how to specify the port when using vncviewer.
    try this in the server field: hostname:10

    VNC will give a connection refused error when the wrong port is specified, so that could be the problem.

    ReplyDelete
  4. Greetings:

    I'm having the same issue as Michael, and I cannot telnet to my port as you suggested. However, I've got the firewall, iptables, stopped/disabled. Any other suggestions?

    Thanks!

    ReplyDelete
  5. Hi, Neil,

    That suggests, then, that xinetd isn't listening on the appropriate port, either because it's not running, or something in the configuration isn't correct.

    You can double-check xinetd by typing:
    service xinetd status

    If it's running (you should get something like "xinetd (pid 3678) is running..." back), double-check your vncserver file in /etc/xinetd.d. A typo or error there will keep it from working.

    You also can use netstat to see if xinetd is listening on the vnc ports:
    netstat -ap |grep 59

    should give you something like this:
    tcp 0 0 *:5908 *:* LISTEN 3678/xinetd
    tcp 0 0 *:5910 *:* LISTEN 3678/xinetd

    If it doesn't, then it's for sure a problem with xinetd.

    Give those a shot, and we can see where the problem is. I'll bet you're close.

    Thanks! -Lane

    ReplyDelete
  6. Greetings:

    Results are - nada

    [root@crystal xinetd.d]# service xinetd status
    xinetd (pid 16745) is running...

    my vncserver file looks like -
    service vnc
    {
    protocol = tcp
    socket_type = stream
    wait = no
    user = nobody
    server = /usr/bin/Xvnc
    server_args = -inetd -query localhost -once -geometry 1280x1024 -depth 24 -SecurityTypes=None -desktop=VNC port = 5950 type = unlisted
    }

    all looks good so far as I can tell. However.....
    [root@crystal xinetd.d]# netstat -ap|grep 59
    unix 2 [ ACC ] STREAM LISTENING 5989 2219/xfs /tmp/.font-unix/fs7100
    unix 2 [ ACC ] STREAM LISTENING 59894 17236/gdm-binary /tmp/.gdm_socket
    unix 2 [ ACC ] STREAM LISTENING 59967 17287/Xorg /tmp/.X11-unix/X0
    unix 2 [ ACC ] STREAM LISTENING 5929 2181/gpm /dev/gpmctl
    unix 3 [ ] STREAM CONNECTED 59999 2219/xfs /tmp/.font-unix/fs7100
    unix 3 [ ] STREAM CONNECTED 59998 17287/Xorg
    unix 3 [ ] STREAM CONNECTED 59975 17284/gdm-binary
    unix 3 [ ] STREAM CONNECTED 59970 2041/acpid /var/run/acpid.socket
    unix 3 [ ] STREAM CONNECTED 59969 17287/Xorg
    unix 3 [ ] STREAM CONNECTED 59909 2031/pcscd /var/run/pcscd.comm
    unix 3 [ ] STREAM CONNECTED 59908 17272/gdm-rh-securi
    unix 2 [ ] DGRAM 59906 17272/gdm-rh-securi
    unix 2 [ ] DGRAM 5932 2190/crond
    unix 2 [ ] DGRAM 5906 2181/gpm
    unix 2 [ ] DGRAM 5596 2085/automount
    [root@crystal xinetd.d]#

    nothing for port 5950! sorry to be a bother, but this kinda sucks. what am I overlooking?

    Thanks!

    ReplyDelete
  7. OK, so it looks like xinetd, for whatever reason, isn't getting the VNC settings. I'll look more closely at your vncserver, but you might run:
    grep xinetd /var/log/messages

    That's because by default xinetd logs to the default syslog. You can also tail that file after restarting xinetd; any errors should be right there at the bottom.

    I hope that helps!

    ReplyDelete
  8. Ack. Neil, I apologize:
    When I changed over to this new Blogger template, it appears that it munged the vncserver file contents.
    Specifically, the port= piece is supposed to be on a separate line, not a part of the server args line.

    So if you change this:
    server_args = -inetd -query localhost -once -geometry 1280x1024 -depth 24 -SecurityTypes=None -desktop=VNC port = 5950 type = unlisted

    To this:
    server_args = -inetd -query localhost -once -geometry 1280x1024 -depth 24 -SecurityTypes=None -desktop=VNC
    port = 5950
    type = unlisted

    You should be in good shape.
    Note that you might need to change the -query localhost to -query servername.

    Then restart xinetd and I'll bet it'll work correctly.

    I'm correcting the post above now.

    ReplyDelete
  9. BEAUTIFUL!!!!!!!!!!!!!!!!!!!!!

    Now you just need to get this blog better searched on the web as it was extremely difficult to find.

    I've been trying to get this to work off and on for several months.

    Thank you!
    Thank you!
    Thank you!

    ReplyDelete
  10. I'm glad it's working!
    As for search engines, link away, my friend! :)

    Thanks for giving me a reason to go back and check this out; I'm sure I'd never have noticed the problem had you not posted the problem.

    ReplyDelete
  11. CAN YOU PLEASE ADD THAT YOU SHOULDN'T GO TO RUNLEVEL 3 IF YOU ARE DOING THIS REMOTELY!! I HAVE TO DRIVE FAR NOW TO GO AND FIX!!

    ReplyDelete
  12. You should still be able to telnet/ssh to the machine and change it back to runlevel 5. That should save you a trip.

    ReplyDelete
  13. Neil is correct: you should be able to ssh in to the system (text-only) and finish the process that way, including setting it back to 5.

    I'm curious: how were you accessing the remote system, if not through SSH?

    ReplyDelete
  14. Great help. Was looking for a possibility to cut and paste through vnc and with your help it is now working.


    THANKS. Will bookmark your page right away...

    ReplyDelete
  15. Greetings:

    I haven't posted here in a while, so now that I have a question, I'm back!

    I've been asked why the VNC session running on the 'host' doesn't run as a process belonging to the actual user signing on. My response has been that when working via xinetd, as configured, the process is owned by the 'nobody' user. So at least it's not running as a 'root' process. Also, when xinetd receives the request to start the vnc session, it doesn't yet know the user logging in so it has to start the process as somebody, so why not 'nobody'?

    Any thoughts on a way to have the vnc process actually be owned by the user logging in? It's like putting the proverbial cart before the horse. I don't personally believe it's possible, but...

    Thanks!

    Neil

    ReplyDelete
  16. Hi, Neil, good to hear from you again!

    You're essentially right: if you want VNC to run as a daemon process (like with xinetd), it has to be running as someone besides the user, because the VNC process helps with the user negotiation (login screen is presented by VNC).

    You might have another option, though, depending on your environment. If the goal is simply to get VNC to run as the user, you could use SSVNC (is the one I'm familiar with; there may be others) to automate a SSL login, VNCServer launch (within that session), and then open a SSH tunnel over which VNC will run.

    I'm pretty sure this will have VNC running under the user context. SSH, of course, is not, and the user is connected via SSH.

    So the connecting daemon still isn't running under the user's context (you're right: it can't be), but VNC will be; if that's the only requirement, then I think this might work for you.

    ReplyDelete
  17. I intended to post a link to SSVNC. It's here: http://www.karlrunge.com/x11vnc/ssvnc.html

    ReplyDelete
  18. Thanks!

    Yes, I think that might work. I was simply looking for an answer to a question. In my environments, I'm already deep behind firewalls, etc, so I'm not really too concerned about VNC running as a daemon via inetd/xinetd. I'd just as soon leave it as 'nobody' and not have to go through all of the extra steps (lazy, I guess). Of course, if I was sending packets across an open network or the internet, different story.

    Thanks for the idea, though, it's sure to fit someone's situation and is a good idea to keep in your pocket.

    Neil

    ReplyDelete
  19. Hi Lane,

    Hope you can help me solve my problem on VNC. I was able to successfully enable VNC to my RHEL6 server, but the problem is, it gave me a new session (root). What I need is that the current user that is log on the server (real time - just like in windows). I'm kinda new in linux. If you have any step by step guide to make it possible, appreciate very much if you can share it with me.
    Thanks in advance.

    OB

    ReplyDelete
  20. Hi, OB,
    it sounds like you're looking for a way to have a remote VNC connection to an existing session that is open on the server; is that right?

    If so, then the process is pretty simple (but limited). When you're logged in to your Linux server, open a terminal window (right-click on the background and select terminal). Then, type 'vncserver' (minus the single quotes) and the partial port number (eg., :09 for 5909) followed by an ampersand to tell the OS to run it in the background. It'd look like this:
    vncserver :09 &

    This will allow you to connect from a remote system to the current user's session, even if that user has disconnected.

    Note that this requires that the user run vncserver manually. If you want that to be run when you log in, you could add the command to the .bashrc file in the user directory (cd ~).

    To be clear: this will only allow a remote connection to an existing session.

    Does that help?

    ReplyDelete
  21. Hi Lane,

    Thank you very much for your quick response. I will give it a try, and let you know for the result. :)

    OB

    ReplyDelete
  22. Hi Lane,

    Still cannot connect with the view of the current user who is log. It still giving different session as root.

    Please help. Thanks.

    OB

    ReplyDelete
  23. Hi, OB,
    I used to have a quick how-to on setting up a non-persistent VNC connection; I appear to have overwritten that information. :(

    However, it's a pretty straightforward thing (easier than the process above), and, depending on what you're needing, I think we can get you up and running pretty quickly.

    Basically, you want VNC to be running as the current user, rather than as nobody. To do this, first log in to create the session you want to connect to. Then run
    vncserver
    from a terminal window.

    VNC will ask you for a passwor that will be required for you to connect to the session. You'll also need to make sure that the corresponding port is open in your firewall. The default first port is 5901.

    You can specify the port number when you run vncserver, but you don't use the full port number; you use a "display number". The display number corresponds to the final digit(s) in the TCP port, so display number 1 is 5901 and number 11 is port 5911.

    Once you've got VNC running and have made sure the port is open on the firewall, you should be able to connect from another computer (or even another session on the same computer).

    Run vncviewer, and you'll be asked for a password (without a username). When you connect, you should be logged in as the user you started vncserver with.

    Let me know if that doesn't make sense, or if you run into trouble with it.

    ReplyDelete
  24. Hi Lane,

    I define port 5902 (or 2) as suggested. But I get an error "Unable to connect to host : Connection refused (10061). But I can connect thru :1 (but view is not the current user log - root instead).

    I have it checked with our network admin at our firewall, it is open and "accepted".

    Please advise where to check. As for your ref., here's the procedure i used to enable vnc. Thanks. - OB

    ####RPM for VNC Server####
    These two packages for vnc server.
    I.tigervnc-server....
    II.tigervnc....

    Now start follow this step.......

    1. [root@localhost ~]# yum install tigervnc*

    Configuration:
    Configuration file is /etc/sysconfig/vncserver. edite this file

    2. [root@localhost ~]# vim /etc/sysconfig/vncservers

    VNCSERVERS="2:myusername"
    VNCSERVERARGS[2]="-geometry 800x600 -nolisten tcp -localhost"

    Change “myusername” to to the user id of user who has to login.

    Example:

    VNCSERVER="1:user1 2:user2"

    You can add more user like this.

    In the second line, mention the resolution in pixels.
    Create vnc password for the users.

    Switch to user1

    3. [user1@localhost ~]$ vncpasswd

    Now service restart

    4. [root@localhost ~]# service vncserver restart

    5. [root@localhost ~]# chkconfig vncserver on
    Now connect to any server vnc viewer from windows/linux machines as server address "server-ip-address:1" for vnc user.
    Give the password set in "vncpasswd username".

    Now remote desktop will be opened. .
    ****Enjoy the magic***

    ReplyDelete
  25. Hi Lane,

    I define port 5902 (or 2) as suggested. But I get an error "Unable to connect to host : Connection refused (10061). But I can connect thru :1 (but view is not the current user log - root instead).

    I have it checked with our network admin at our firewall, it is open and "accepted".

    Please advise where to check. As for your ref., here's the procedure i used to enable vnc. Thanks. - OB

    ####RPM for VNC Server####
    These two packages for vnc server.
    I.tigervnc-server....
    II.tigervnc....

    Now start follow this step.......

    1. [root@localhost ~]# yum install tigervnc*

    Configuration:
    Configuration file is /etc/sysconfig/vncserver. edite this file

    2. [root@localhost ~]# vim /etc/sysconfig/vncservers

    VNCSERVERS="2:myusername"
    VNCSERVERARGS[2]="-geometry 800x600 -nolisten tcp -localhost"

    Change “myusername” to to the user id of user who has to login.

    Example:

    VNCSERVER="1:user1 2:user2"

    You can add more user like this.

    In the second line, mention the resolution in pixels.
    Create vnc password for the users.

    Switch to user1

    3. [user1@localhost ~]$ vncpasswd

    Now service restart

    4. [root@localhost ~]# service vncserver restart

    5. [root@localhost ~]# chkconfig vncserver on
    Now connect to any server vnc viewer from windows/linux machines as server address "server-ip-address:1" for vnc user.
    Give the password set in "vncpasswd username".

    Now remote desktop will be opened. .
    ****Enjoy the magic***

    ReplyDelete
  26. Hi, OB,
    So it sounds like the way you're running VNC might be keeping you from getting the results you want.

    Is it important that VNC be run as a service? If so, I'd suggest running through the steps in this post, as that will give you VNC at service startup as well as the ability to connect as any User.

    If, on the other hand, your goal is to be able to connect to an existing session, I don't think you want VNC running as a service.

    Try this, if you will:

    1. Log in as the non-root User you want to connect as.

    2. Stop VNC
    sudo service vncserver stop

    3. Run VNC as your non-root User
    vncservser :2

    Now try to log in via VNC. You should be able to connect to the non-priviledged session, since VNC is running under that context.

    ReplyDelete
  27. Hi Lane,

    I was able to connect with the current user who is log, but, I cannot see the actual view (or the current session)on my vncviewer.

    My goal is that, when I connect using vncviewer, I need to see the actual/current desktop of the one who is log on the server. Like a real view where it's like you are in front of the server and seeing the actual view.

    Are you suggesting to go through with the steps in this post, so I can attain my goal?

    Please advise. Thank you very much.

    Happy New Year !!! =)

    OB

    ReplyDelete
  28. Hi, OB, I think something like this will get you going on an ad hoc basis; does this do what you want it to?

    x0vncserver -alwaysshared -passwordfile $HOME/.vnc/password

    That'll listen on port 5900 and it'll use the password file created (in the default location) by vncpasswd.

    ReplyDelete
  29. Note, BTW, that the above assumes you're connected to the console (display 0).

    ReplyDelete
  30. Hi Lane,

    After I run this :
    x0vncserver -alwaysshared -passwordfile $HOME/.vnc/password

    to the console. Still I cannot connect thru my vncviewer. It gave me error like this: "The connection closed unexpectedly."

    We checked at FW, it passes thru port 5900. I know it's been too long resolving this, but I'm keeping my fingers cross that we could resolve this. Please advise.

    Thank you very much for all your help.

    OB

    ReplyDelete
  31. No problem, OB, I think we'll get you going. Can you post the output of the x0vncserver command? There might be some hints there.

    ReplyDelete
  32. Hi Lane,

    Sorry I forgot to include this result for the command x0vncserver in my last post. Please see result for the command below.

    Geometry: Desktop geometryis set to 1024x768+0+0
    Main: Xtest extension present - version 2.2
    Main: Unable to bind listening socket: Address already in use (98)

    Hope we could get something from this. Will wait for your advise.

    Thanks.

    OB

    ReplyDelete
  33. Hi Lane,

    Sorry I forgot to include this result for the command x0vncserver in my last post. Please see result for the command below.

    Geometry: Desktop geometryis set to 1024x768+0+0
    Main: Xtest extension present - version 2.2
    Main: Unable to bind listening socket: Address already in use (98)

    Hope we could get something from this. Will wait for your advise.

    Thanks.

    OB

    ReplyDelete
  34. Aha: it would appear VNC already is running, so we'll have to stop the earlier encarnation of it before we can run x0vncserver.

    You can just undo the steps you initially did to set it up. Depending on how it's run, you could try just running
    vncserver -kill :0

    If that reports having killed a process, you should be able to proceed with the x0vncserver command.

    Let us know how that goes! -Lane

    ReplyDelete
  35. Hi Lane,

    After command > vncserver -kill :0

    I got the message below:

    Can't find /root/.vnc/pdbkastletst:0.pid
    You'll have to kill the Xvnc process manually.

    Then I tried to stop vnc by issuing command : service vncserver stop

    Then same error on :x0vncserver command

    What do you think is the next step? Thanks again.

    OB

    ReplyDelete
  36. Hi, OB,
    The thing we've got to do at this point is to stop the running vncserver process.

    Ultimately, you'll want to un-do the steps you took to set it up; in the meantime, you can kill the process manually.

    I note, as an aside, that you're running the vncserver -kill command as root; I'm assuming you started vncserver as a non-root user. You might try the vncserver -kill command as that user, rather than as root.

    If you run (as root)
    ps -A |grep vnc
    you should see something along these lines:

    2187 pts/0 00:01:37 Xvnc
    2193 pts/0 00:01:25 vncconfig

    the Xvnc process is the one that was started by vncserver; if you issue this command:
    kill 2187

    where 2187 (which will be different on your system) is the process ID of the Xvnc process, you'll have stopped vnc.

    If you have vnc set to start each time the server boots, you'll want to undo those settings so that it's not running to block the x0vncserver process.

    You can have x0vncserver start at login (but not at server boot: there's no console to control at that point) by adding the x0vncserver command to one of the startup files (like .bashrc) in the user's home directory.

    Let us know where that gets you!

    ReplyDelete
  37. Hi Lane,

    I was able to kill process manually.

    When I command service vncserver status, result is:
    Xvnc dead but subsys locked

    Then try to run x0vncserver....But still gets the same error:
    Geometry: Desktop geometryis set to 1024x768+0+0
    Main: Xtest extension present - version 2.2
    Main: Unable to bind listening socket: Address already in use (98)

    Please advise. Thanks.--OB

    ReplyDelete
  38. Hi, OB,
    Since we've got a service set up, we should have a pretty easy time getting vnc off. Try this:
    chkconfig vncserver off

    Then reboot, and you should find service vncserver status shows is not running.

    Likewise, you should find that netstat -a |grep 5900 shows no processes listening on port 5900.

    Then we should be able to start x0vncserver without further ado (fingers crossed!).

    -Lane

    ReplyDelete
  39. Hey, me again!

    I've got a pesky problem with OEL 5 or OEL 6 linux not wanting to display the gnome desktop when executing like this, from xinetd. All I get is a black screen with a whitish X for a mouse pointer.

    I've modified the two files you list up top for specifying the gnome desktop and restarted the xinetd service.

    Any ideas/suggestions?

    Thanks!

    Neil

    ReplyDelete
  40. Super site! I am Loving it!! Will return once more, Im taking your food likewise, Thanks. private rdp

    ReplyDelete
  41. At the point when you do a quest for Computer repair in Huntsville AL, you will discover the absolute best repair shops. desktop repair services

    ReplyDelete
  42. The greater peril anyway is when designers don't comprehend the lifetime cost of explicit framework models. It is considerably more agonizing to all partners including enterprise planners when enterprise projects are cut short because of speculations not producing anticipated outcomes or to place it in right language, no profit from venture (ROI). Resume Builder App

    ReplyDelete
  43. By terminating those employees, the business draws in better talented laborers who help your business in working on the primary concern.
    targonca szállítás Debrecen Europa-Road Kft.

    ReplyDelete

Thanks for leaving a comment!