If they are still default, remove the comment (#) and change to true. In the configuration file look for the following entries: Kdm4 uses one configuration file, " /usr/share/kde4/config/kdm/kdmrc". If there are still X processes running then a system reboot will be required. If there are any left try killing them with this command: Run the command "ps -e | grep X" again to verify all X processes are dead. If any processes are displayed they will need to be killed by running this command (again use caution as this will pull the rug out from under anyone that may be logged into the graphic desktop on the system): Then verify there are no X server processes running with this command (note: The X is a capital letter): Services being provided by the server are generally not disrupted by restarting the graphics with the following commands: Restarting the graphics manually will kill anyone currently logged into the graphic desktop (local or remote) so use caution. A reboot will do the job but may be overkill if you are on a production server. If any changes are made to either of these files then the graphics system must be restarted to take effect. Search for the following entries and set to true:Īgain, the second entry is only needed if root will be allowed to login remotely. This is a much larger file but there are only two settins that need to be verified in this one as well. The second setting only needs to be true if the root user will be allowed to login remotely. # SuSEconfig: displaymanager:DISPLAYMANAGER_ROOT_LOGIN_REMOTE,DISPLAYMANAGER_SHUTDOWN, security:PERMISSION_SECURITY # SuSEconfig: displaymanager:DISPLAYMANAGER_REMOTE_ACCESS This is a very small file and only these two settings need to be verified and set to true: There are two configuration files that must checked for gdm, /etc/gdm/nf and /etc/gdm/gdm.schemas. If any changes are made to the file then run "SuSEconfig" after. This is important to know so that the appropriate instructions can be followed in the section below for either gdm or kdm4.ĭISPLAYMANAGER_REMOTE_ACCESS must be enabled to allow the connection.ĭISPLAYMANAGER_ROOT_LOGIN_REMOTE must be enabled to allow the root user to login remotely. GNOME/gdm is the default unless KDE4 was specifically selected as the desktop during installation. The "DISPLAYMANAGER=" setting will normally be set to either gdm (for GNOME) or kdm4 (for KDE4). In this file look for the following entries: Using your favorite editor open the following file: Both selections can be found in the"Network Services" section of YaST. If this information is not displayed then it would indicate that the "Remote Administration (VNC)" selection in YaST has not been configured or the the xinetd service has been disabled (which can also be checked in YaST). The following should be displayed (other than a different PID which is fine): Use the following command to verify that port 5901 is in a listening state and is owned by xinetd: If not, leave the firewall disabled until troubleshooting is complete. Test the VNC connection again to see if there is any change. Run the status command again to verify it is now "unused". If it is "running" then shut down the firewall with this command: This will return the status of the firewall as either "unused" or "running" (the status shows up on the very right hand side of the terminal). The instructions below will require being logged in as the root user at a command line terminal.īy default the firewall is enabled and will block the VNC communication unless the box was checked in the YaST configuration for Remote Administration to open the port.Įven if it was checked it's always a good idea to disable the firewall to rule it out. These steps are not intended for troubleshooting a VNC server that is being started outside of the YaST configuration. Troubleshooting steps for VNC connection when "Remote Administration (VNC)" has been enabled in YaST.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |