Is there any ‘current’ information on how to setup remote administration on opensuse (best I can find is from about V11.x - sax2 no longer used??)
The option is in Yast for this, but ****ed if I can find any info on it… Obviously you would need a password or something??
Have tried to set this up before, but gave up and just installed FreeNX or similar. Surely there is a more ‘native’ way to connect…
Thanks.
I usually ssh into remote system and do administration tasks. So please describe what you are trying to achieve - “remote administration” is way too broad.
Sorry…
There is a “remote Administration” option in YAST, which I believe, is supposed to enable “something”, which I thought was VNC - could be wrong! (Yast=>Network Services=>Remote Administration (VNC)) - appears to do nothing?!
So, I thought I would just install VNC, that should be simple! But, no, even the obvious choices - RealVNC, TightVNC etc that I have used in a Windows environment for years, and all have Linux equivalents, there is NO information that I can find, that is CURRENT, for configuring these and getting thjem working in linux - specifically Opensuse.
Yes, I use ssh also for remote admin, but was thinking that it would be nice to be able to use a graphical environment on occasions.
Sorry if I appear a bit peeved, but thought that this would be simple.
Thanks.
Am Mon, 25 Jul 2016 06:36:01 GMT
schrieb hornetster <hornetster@no-mx.forums.microfocus.com>:
> Yes, I use ssh also for remote admin, but was thinking that it would be
> nice to be able to use a graphical environment on occasions.
SSH + X-Forwarding (+XServer on Win Client, i.e. Xming)
–
Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)
I’ve reviewed the following, and highly recommend
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.vnc.html
If you follow the steps described and still have questions, post here again.
TSU
Yes, installing only a VNC package won’t result in a successful VNC server nowadays on openSUSE (and many other distros).
If you use the YAST “Remote Administration” tool to install VNC, you’ll notice that an xserver is also installed separately.
AFAIK it’s only because of some relatively recent Linux architectural changes that an xserver isn’t necessarily installed, but it’s required to run vnc server. With this inconsistency between distros, I don’t know that an xserver can be considered a dependency yet upstream.
TSU
If you need graphic only on occasions - I simply log in using ssh and start vncviewer on remote system and either tunnel port over ssh or connect directly. Just did it on two remote systems 
Sure fixing YaST would be good but if you need job done, this is the most easy and simple way.
It should have been vncserver of course. Sorry.
Thanks for the replies, still struggling…
Remote administration allowed in Yast, but… whenenver I go in to the setting, and select ok (changes or not), I get dropped back to a text interface (ie the graphical UI quits) and I have to reboot to get back into a KDE session. (Only running a standard i5 chip + graphics).
Surely there is some other config that needs to happen for VNC - doesn’t it need a password?
If I try and access from another PC: from Ubuntu:gvncviewer 192.168.0.50:1
Connected to server
Disconnected from server
or from Win10/RealVNCViewer:RFB protocol error: reading version failed: not an RFB server?
This is after following: https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.vnc.html (as much as possible…?)
Thanks.
Step-by-step instructions would sure be nice for novices reading this thread.
And still struggling…
Have tried disabling/re-enabling the Remote Admin option. Have tried force installing the required packages, as per the other (current) thread.
If I run vncserver, I get a display on :2. If I kill that server (ie :2), and do a vncserver -list, there is nothing running, but if I try and start a server on :1, I am informed that there is already a server running on :1, but there is nothing in processes etc, that is running.
If I try and connect remotely to :1 from another machine (Ubuntu), I get :Connected to server
Disconnected from server
in very quick succession. But If I run vncserver, and get a display on :2, I can connect fine to it…
If I look in Yast>Services, there are 2 VNC services:
vncserver-virtuald Disabled Inactive
vncserver-x11-serviced Enabled Inactive
Enabling these makes no difference…
Where (and how can I fix…) is :1??
I was having the exact same problem and thinking the same thoughts about needing a recipe to get VNC going.
Here is what worked for me
NOTES:
I got the info for the above requirement to run vncserver from this forum; topic “Hot To Activate VNC Server in OpenSUSE 12.3”.
Recommend reading this post.
It explains how to kill the vncserver process.
It also shows example of setting up so vncserver starts on boot. (using personal cron job)
SuSE 13_2 uses tigervnc now (they are the spawn of tightvnc)
Their website is www.tigervnc.org
Go there. Not a lot of setup info but it will give you an overview of what is provided by tigervnc.
The clipboard feature and the remote control stuff (instead of a separate remote session interest me)
I could not remote in using tightvnc client from Windows version 2.7.10
I downloaded and installed the tigervnc client from their website and success.
I am not sure if the prior statement is true about tightvnc not working because now I can remote in with tightvnc
So either establishing a session with tigervnc fixed tightvnc or I made an error
Anyway I can’t go back in time and undo the tigervnc session so I will never know.
Anyway download tigervnc package anyway. It looks slicker probably a much better client anyway.
I logged out when in my remote session thinking I would get a login screen
When I tried to reestablish I got a black screen (with the clipboard utility showing but no desktop or login screen)
To fix: I killed the session “vncserver -kill :2” then ran “vncserver” again (could have rebooted and rerun vncserver instead).
sidebar:there is an autkill option in vncserver that looks promising to kill the process when you log out
I have not tried this out and don’t know if it restarts the vncserver so a new remote session can be established
The downside to the fix presented is you have to login as the user and start vncserver from command line.
So to make this practical look into creating a personal cron job mentioned above.
For other users.
sidebar: forgot your password: type “vncpasswd” at command line to recreate the password as vncserver won’t prompt to create a password after the first time it is run and there is no command line option in vncserver to prompt again.
just another comment
I think you get session 2 when first creating a vncserver because the vnsserver for 1 (port 5901) was established on boot in Network Services xinetd. This happened when you ran YaST to enable Remote Services. You can mess around with that and make it so you can establish a vncserver at boot (user not root, home files have to exist for user chosen). Beyond my ability and I am happy with the personal cron job method mentioned prior.
Sorry if not the answer you are seeking but only ankle deep in Linux knowledge.
Providing for all who want a perhaps simpler, explanatory “cookbook” for setting up VNC “Remote Administration” on openSUSE (all current supported versions).
Setting up the Server
By definition, the “Server” is the machine you’re remoting into which has the resources the Client wants to access.
The “Client” (section below) is the machine connecting to Server.
On any currently supported openSUSE,
Open YAST > Network Services > Remote Administration(VNC)
Click the radio button “Allow Remote Administration”
If in the future you want to disable VNC access, you can re-run this applet and select the “Do not allow…” radio button.
Click on the radio button to open the appropriate firewall ports.
Click on the “OK” button to start the installation. You will probably also be prompted to authorize installation of an x11 server, do so.
Reboot.
At this point, this machine should be set up to accept VNC connections.
The VNC Server service is actually called “xinetd.service” which will be configured to start automatically on boot. You can verify it’s running with the following command
systemctl status xinetd..service
Besides re-running the YAST Remote Administration applet, you can also control VNC server behavior with standard sytemd commands,
If you don’t want the VNC Server to be started on boot, you can run the following so that the VNC Server needs to be started manually(You can re-enable start on boot with “enable” instead of “disable”)
systemctl disable xinetd.service
If you want to start/stop/restart the VNC Server, you can use these standard systemd commands
systemctl start|stop|restart xinetd.service
Inspecting and configuring VNC displays
A VNC Server installed using the YAST applet automatically sets a default configuration for vncserver client apps and another for java applets (typically running in a web browser) so it’s not absolutely necessary to look at this when first installed and testing but you may want to look at this as soon as you want something different than default. Additional displays are available but are disabled. You can also create additional custom displays by simply adding your own stanzas to the configuration file.
The vnc displays configuration file
/etc/xinetd.d/vnc
You are recommended to open this file in your favorite text editor (requires elevated permissions if you wish to edit).
You will notice that each display not only specifies a display number (This is how the client specifies the configuration), but also the resolution and color depth. Mix and match or create to suit your specific need.
You can enable any of the disabled configurations by simply changing the line “disabled=yes” to “disabled=no”
If you make changes to this configuration file (/etc/xinetd.d/vnc) then you will need to reload the service. Instead of the command in the official documentation I recommend the following command which reloads all services on the system.
Don’t forget, the following is required if you change configuration files (actually applies to any and all systemd services)
systemctl daemon-reload
The VNC Client
Nearly every default openSUSE automatically includes the VNC client, you can test by running a command like the following
vncviewer --help
if for some odd reason the above command fails, then you can install the tigervnc package
zypper in tigervnc
By default, no password is required when connecting to a remote VNC server.
The following should launch the vnc client, and by not specifying a display number will use the default (display 1)
Substitute “remote_machine” with an IP address or a resolvable name
vncviewer* remote_machine*
The VNC Java Applet viewer
The java applet is typically used in a web browser, of course this means that Iced Tea or some other Java plugin must be installed and enabled in the web browser. Depending on the security restrictions, nowadays, you may be prompted a number of times to authorize access before you will be successfully connected.
To use the Java applet in a web browser, you will need to specify a port number that corresponds with an enabled VNC Server java configuration (see above “Inspecting and configuring VNC displays”).
The following should immediately work without special configuration connecting to an openSUSE VNC server by specifying port 5801. You can access other enabled displays by specifying a different port (eg 5802, 5803, etc). Substitute “server_machine” with an IP address or resolvable name.
https://*server_machine*:5801
OK, I think that pretty much covers the basics for anyone setting up VNC and Remote Administration for the first time.
I don’t think I’ve described anything differently than what is in the openSUSE docs, only differently with some slight modifications replacing sytemd commands in place of SysVinit commands.
If people think that anything in this might improve what is in the original docs, you can let the openSUSE docs people know, they seem to be OK with feedback.
Based largely on the original community openSUSE documentation on VNC and Remote Administration at
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.vnc.html
Any questions or need for clarity, just post.
HTH,
TSU
Regarding the above posts about the mysterious requirement to connect on display :2,
I’m pretty sure that would be because you already have vncserver installed and running, which would already be using port :1. And, if you were looking for processes called “vnc” or “vnc server” of course you wouldn’t see anything because the server service is called “xinetd.”
See my above post about the VNC configuration file, by default the first display id for both vncviewer and the java applet are enabled, all others are disabled.
When you ran vncserver manually, you’re probably creating a new vncserver process, you can do this and specify display properties available in the command line instead of referencing a config file (which is what a default openSUSE install does when installed using YAST).
TSU
Hi Tsu,
Thanks for the explanations, certainly helps to put things in the correct place, but have a few queries…
My understanding of the xinetd service, is that it controls several, or many, services, not just vnc.
For example, when I run the status of xinetd on my machine, I get:
Jul 28 14:59:15 boss xinetd[1014]: Reading included configuration file: /etc/xinetd.d/services [file=/etc/xinetd.d/services] [line=14]
Jul 28 14:59:15 boss xinetd[1014]: Reading included configuration file: /etc/xinetd.d/svnserve [file=/etc/xinetd.d/svnserve] [line=14]
Jul 28 14:59:15 boss xinetd[1014]: Reading included configuration file: /etc/xinetd.d/systat [file=/etc/xinetd.d/systat] [line=15]
Jul 28 14:59:15 boss xinetd[1014]: Reading included configuration file: /etc/xinetd.d/tftp [file=/etc/xinetd.d/tftp] [line=17]
Jul 28 14:59:15 boss xinetd[1014]: Reading included configuration file: /etc/xinetd.d/time [file=/etc/xinetd.d/time] [line=20]
Jul 28 14:59:15 boss xinetd[1014]: Reading included configuration file: /etc/xinetd.d/time-udp [file=/etc/xinetd.d/time-udp] [line=15]
Jul 28 14:59:15 boss xinetd[1014]: Reading included configuration file: /etc/xinetd.d/vnc [file=/etc/xinetd.d/vnc] [line=15]
Jul 28 14:59:15 boss xinetd[1014]: Reading included configuration file: /etc/xinetd.d/vsftpd [file=/etc/xinetd.d/vsftpd] [line=88]
Jul 28 14:59:15 boss xinetd[1014]: xinetd Version 2.3.15 started with libwrap loadavg options compiled in.
Jul 28 14:59:15 boss xinetd[1014]: Started working: 2 available services
which contains a number of services (admittedly, most are disabled), so if you disable xinetd, you are also disabling the other services, not just vnc.
Also, the issue with the display number (mysterious requirement to connect on display :2,
**I’m pretty sure that would be because you already have vncserver installed and running, which would already be using port :1. And, if you were…)
I think you are correct as to the reason that running vncserver chooses :2 as the port, but the issue is that the daemon running on :1 does not work… If you try and connect to it, you cannot get a successful connection, while running a new service as :2 DOES work.
Playing around a bit, have found that by changing ‘some’ settings in the xinetd/vnc file (certificate issues??), can actually get a connection, but with a black screen…
Have seen references to this elsewhere.
Thanks.
Thank you for the great response and link to the documentation
Just some comment based on my experience (which sounded very similar to the original poster’s experience)
At this point, this machine should be set up to accept VNC connections.
The VNC Server service is actually called “xinetd.service” which will be configured to start automatically on boot. You can verify it’s running with the following command
The service is running but will not accept connections.
Tightvnc client reports “Error in tightvnc viewer. Unsupported protocol: /usr/bin/vnc”. I tried a few protocols including RAW.
Tigervnc client reports “reading version failed: not an RFB server?”
Code:
systemctl status xinetd…service
Besides re-running the YAST Remote Administration applet, you can also control VNC server behavior with standard sytemd commands,
If you don’t want the VNC Server to be started on boot, you can run the following so that the VNC Server needs to be started manually(You can re-enable start on boot with “enable” instead of “disable”)
Code:
systemctl disable xinetd.service
If you want to start/stop/restart the VNC Server, you can use these standard systemd commands
Code:
systemctl start|stop|restart xinetd.service
Inspecting and configuring VNC displays
A VNC Server installed using the YAST applet automatically sets a default configuration for vncserver client apps and another for java applets (typically running in a web browser) so it’s not absolutely necessary to look at this when first installed and testing but you may want to look at this as soon as you want something different than default. Additional displays are available but are disabled. You can also create additional custom displays by simply adding your own stanzas to the configuration file.
The vnc displays configuration file
Code:
/etc/xinetd.d/vnc
You are recommended to open this file in your favorite text editor (requires elevated permissions if you wish to edit).
You will notice that each display not only specifies a display number (This is how the client specifies the configuration), but also the resolution and color depth. Mix and match or create to suit your specific need.
You can enable any of the disabled configurations by simply changing the line “disabled=yes” to “disabled=no”
If you make changes to this configuration file (/etc/xinetd.d/vnc) then you will need to reload the service. Instead of the command in the official documentation I recommend the following command which reloads all services on the system.
Don’t forget, the following is required if you change configuration files (actually applies to any and all systemd services)
Code:
systemctl daemon-reload
**Xinetd can be configured more easily by less knowledgeable users from YaST.
You can enable and disable automatic start, you can manually start/stop services.
And as another poster responded; Xientd controls many/any services in addition to vnc.
A lot of those service control features have been moved to other boot start methods though.
The VNC Client**
Nearly every default openSUSE automatically includes the VNC client, you can test by running a command like the following
Code:
vncviewer --help
if for some odd reason the above command fails, then you can install the tigervnc package
Still recommend grabbing tigervnc client from web portal to get the most current set of features and bug fixes.
Since SuSE installs the tigervnc server by default it sounded to me like the best way to maximum compatibility also.
tigervnc client gives you clipboard and a remote control service (shared desktop) as opposed to a separate remote session. Might get all this with the client that comes with SuSE but just not the route I took.
Code:
zypper in tigervnc
By default, no password is required when connecting to a remote VNC server.
The following should launch the vnc client, and by not specifying a display number will use the default (display 1)
Substitute “remote_machine” with an IP address or a resolvable name
Code:
vncviewer* remote_machine*
**When I run the above command from my Linux server I get the same error I mentioned above when using tigervnc client from a windows pc; “reading version failed: not an RFB server?”
The VNC Java Applet viewer**
The java applet is typically used in a web browser, of course this means that Iced Tea or some other Java plugin must be installed and enabled in the web browser. Depending on the security restrictions, nowadays, you may be prompted a number of times to authorize access before you will be successfully connected.
To use the Java applet in a web browser, you will need to specify a port number that corresponds with an enabled VNC Server java configuration (see above “Inspecting and configuring VNC displays”).
The following should immediately work without special configuration connecting to an openSUSE VNC server by specifying port 5801. You can access other enabled displays by specifying a different port (eg 5802, 5803, etc). Substitute “server_machine” with an IP address or resolvable name.
Code:
https://server_machine:5801
OK, I think that pretty much covers the basics for anyone setting up VNC and Remote Administration for the first time.
I don’t think I’ve described anything differently than what is in the openSUSE docs, only differently with some slight modifications replacing sytemd commands in place of SysVinit commands.
If people think that anything in this might improve what is in the original docs, you can let the openSUSE docs people know, they seem to be OK with feedback.
Based largely on the original community openSUSE documentation on VNC and Remote Administration at
https://doc.opensuse.org/documentati…e/cha.vnc.html
additional comment:
I feel the install of vnc has been complicated since SuSe 12 at least.
It used to be you just enabled it in YaST and you could start a client that started with a login screen that allowed the user to login in as any SuSE server user.
Then they can tweak it from there (setting up separate controls and display properties for different logins, etc)
I think to get the login prompt for a vnc client that is enabled on boot you have to mess with the xinetd settings.
I do not work by default for me.
If memory serves you need to mess with the user the service starts with (no root, use nobody ?) and possibly other settings. I never did get vnc working the way I like using xinetd. In the past, using xinetd, I was able to mimic the scenario where the user I was remoting in as had to be logged in. I am sure it was my lack of knowledge.
When I reread the original post it looks to me like the poster was successful at establishing a vnc session. Poster was confused why could not use session #1 (the one created by xinetd) Not sure why poster cared what session number was being used. I was not sure where the poster was headed as far as the type of vnc server he wanted to setup. (ie. using xinetd or a server manually started by a Linux user with vncserver at a command line, or a shared desktop session). Also not sure if the way the user was killing the service was proper. It may have been. I just don’t know. I do know that if I kill the vnc session using the command posted earlier I can restart the server and everything works fine (vncserver -kill :2) (substitute your session number for the 2).
You’re right,
Strictly speaking the xinetd service is actually an optional for some, and mandatory for others “Master Service” which can provide supplemental or required security and monitoring features.
So, although it seems to be required for vnc, as you describe it <can> affect other services.
The “systemctl status” log snippet you quote only indicates that those configuration files for those other services are read, they don’t indicate whether those services will actually be affected by xinetd.service. To determine whether and which other services would be affected, the following
Based on the SUSE documentation at
You will find the command which lists services xinetd.service is managing
chkconfig --list | awk '/xinetd based services/,/""/'
As long as the results of this command lists only vnc as “on” then only that is affected, otherwise you’re correct… modifying xinetd.service can affect other apps.
Note that most of not all of the apps in the list can be run “standalone” without the features xinetd.service can provide, so even installing and running other apps in the list won’t necessarily mean that they would be affected by xinetd.service.
TSU
For anyone who followed what I posted exactly (The steps are few, but any variance can have unexpected consequences) and are still having big problems that don’t look like a simple mis-configuration, it then might be important to know
The openSUSE version, and whether “zypper up” was run prior to attempting to run the YAST applet.
Reason: Particularly if a brand new install, “zypper up” is critical to starting with a fully featured and patched machine. Omitting “zypper up” <will> mean a high likelihood of problems.
The GPU, both hardware and whether you are using the kernel driver provided by the installed kernel or something else. I personally haven’t seen a black screen for a very long time using VNC, but it used to not be uncommon. Sometimes you had to disable (or sometimes enable) GPU features like acceleration, color depth, assigned memory, etc. Since I have not seen this recently, I don’t know if those old problems still exist or would be fixed the same way.
If network traffic can be an issue. If possible, set up a dedicated or low traffic network connection for testing. If you are running virtualized instances, run Guests on the same machine to eliminate putting traffic on a physical wire.
Everyone should try using vncviewer first. If it doesn’t work, then you should try using the java applet. If the java applet works, then it might reveal clues why the vncviewer doesn’t.
If your Server install is brand new, consider wiping clean and starting over, I don’t know of a lot of people who are confident un-installing their mistakes completely. If you’re running LEAP, I’ve found a new install is well less than an hour plus additional time to download and install updates (running “zypper up” unless you did a network install), which is an easy cost/benefit decision (It’s easy to spend more than an hour trying to fix something that’s hard to fix).
TSU
For anyone who followed what I posted exactly (The steps are few, but any variance can have unexpected consequences) and are still having big problems that don’t look like a simple mis-configuration, it then might be important to know
The openSUSE version, and whether “zypper up” was run prior to attempting to run the YAST applet.
Reason: Particularly if a brand new install, “zypper up” is critical to starting with a fully featured and patched machine. Omitting “zypper up” <will> mean a high likelihood of problems.
The GPU, both hardware and whether you are using the kernel driver provided by the installed kernel or something else. I personally haven’t seen a black screen for a very long time using VNC, but it used to not be uncommon. Sometimes you had to disable (or sometimes enable) GPU features like acceleration, color depth, assigned memory, etc. Since I have not seen this recently, I don’t know if those old problems still exist or would be fixed the same way.
Black screen was only because I logged out to see what would happen.
It’s not a black screen like a hung screen.
If you close this session and try to reestablish you get the same black screen with only the clipboard feature from tigervnc.
This is 100% repeatable.
This is consistent with the way vnc works since at least SuSE 12
If you are not using xinetd then logging out munches the connection\session (“vncserver -kill :2” and “vncserver” brings it back)
There may be settings to fix this but they aren’t set by default.
If network traffic can be an issue. If possible, set up a dedicated or low traffic network connection for testing. If you are running virtualized instances, run Guests on the same machine to eliminate putting traffic on a physical wire.
not network traffic for me
brand new server not put into the wild yet
get the same error whether I connect from another pc or run vncviewer straight from the server
Everyone should try using vncviewer first. If it doesn’t work, then you should try using the java applet. If the java applet works, then it might reveal clues why the vncviewer doesn’t.
definitely agree
the java access opens a whole other can of worms (possibly)
If your Server install is brand new, consider wiping clean and starting over, I don’t know of a lot of people who are confident un-installing their mistakes completely. If you’re running LEAP, I’ve found a new install is well less than an hour plus additional time to download and install updates (running “zypper up” unless you did a network install), which is an easy cost/benefit decision (It’s easy to spend more than an hour trying to fix something that’s hard to fix).
don’t believe I made a mistake
brand new install
don’t think reinstall will help anything
zyppered up Saturday
zypper up currently nothing to zypper up
first attempt at vnc Monday
did not mess with any settings other than to install Remote Service form YaST
I hold firm (and the OP seems to have the same issue) that vncserver as a xinetd service does not work without adjusting some mystery setting(s).
vncserver run manually works fine but must be run by one user so you don’t have the flexibility to choose who you login as
have not heard anyone say they were able to get a remote vnc session started just by enabling Remote Services from YaST