Remote Administration help

I am going round and round with the “Remote Administration” option in Yast. The only options are to turn it on or off.

How do I configure it?

I’ve tried searching the wiki and forums, but all I see are frustrated users trying to kind of do the same thing.
Can someone explain how to use that feature?

Thank you
Tas

Yes, that’s how it’s designed.
It enables Remote Administration, i.e. it configures the display manager to accept remote connections via VNC and XDCMP.

If you enable it and reboot, you should be able to connect with a VNC (port 5901) or XDMCP client and will get a login screen there.
You can also connect via HTTP to port 5801 and will get a Java VNC client in your webbrowser…

How do I configure it?

What exactly do you want to configure?

Sorry for the latent reply. I’m trying to setup remote access on the system and looking at all the tools available. I’ve afraid I gave up on the Remote Administration feature, because it doesn’t work. I’ve rebooted, burned incesnse and sprinkled water to no avail.

Using NoMachine for now.

Tas

I recommend tigervnc, then run the x0vncserver, which will give you direct access to the desktop running on your server, via vncviewer [IP]:0.

In setting up, run vncpasswd, which will create a password in the file ~/.vnc/passwd and x0vncserver must be started with the password file command “x0vncserver -PasswordFile ~/.vnc/passwd”.

I tried the “Remote Administration” in Yast a long time ago and could not make it work. However, I think the default install is TightVNC used by Remote Administration and TigerVNC is much better.

(It’s also possible the problem you are having relates to not having a passwd file – I think this is necessary for authentication with most VNC setups, although a program called “Winswitch” is interesting because it creates its own temporary passwd file so the authentication issue is transparent.)

If you want access to the server, but not necessarily via the running desktop, you can run an instance of “vncserver”. With no parameters, it will use the ~/.vnc/passwd file and it will create a server instance on the next available port – eg., since the server desktop is 5900, the next in order will be 5901, so “vncviewer [IP]:1”. The first run will create ~/.vnc/xstartup, which on my system meant that when I logged into 5901, I got a new instance of my default desktop, KDE 4.14. (I don’t like to do this, because the remote version is likely to be resized and that will mess up the panels, etc. on the server desktop because the same set of configuration files are used.) The xstartup file can be modified to run a different desktop. (Also, my impression is that KDE is a slower remote desktop than icewm, lxde or xfce.) I don’t worry about the size of the vncserver display, since the default will be small enough to run on whichever remote I use and I can then re-size the window on the client to whatever seems useful to me.

I generally run x0vncserver in case I want to access the running server desktop, but mostly utilize an xfce remote on 5901 for my remote sessions. Tigervnc allows hand-off of the remote session from computer to computer, which is nice because then whatever I left running on the remote desktop is accessible right where I left off on the next computer I log into (via vncviewer).

It does work.
The question is just whether it does what you want or expect it to do. Since you didn’t tell…

Again, that feature offers a separate X session/login screen via VNC and XDMCP.
If you want to share an existing session (a logged in user), this is not for you.

@daltrey: current openSUSE versions (13.2, Tumbleweed) do include/use tigervnc instead of tightvnc.

There is a large thread here on this subject: https://forums.opensuse.org/showthread.php/506746-remote-desktop-please-suggestions?highlight=x11vnc

Other than to open the appropriate ports in one’s firewall, IMHO one does not need YaST to configure this. One does need to install the correct apps. I’ve been remotely administering my +89-year old mother’s PC for many years (her PC is over 7,000 km away), using vnc to take over her desktop to administer her PC, and this works very good in openSUSE.

Sorry to read you are had problems initially. Glad to read nomachine works for you.

This is how I do it:

  • Go to YAST2
  • go to network services ‘Remote Administration’ and change status to ‘Allow Remote Administration’ and ‘open Port in Firewall’
  • open Network Services (Xinetd) → install ‘xinetd’ if not present
  • ‘enable’ service on the top
  • scroll down in the services list and select ‘VNC1’
  • than click the button ‘Toggle Status’ so that in front of the VNC1 service you see status ‘On’
  • Click ‘Finish’
  • you should now be able to connect with a VNC client <ip address:1> (example: 192.168.0.10:1, or port number – 192.168.0.10:5901)

P.S.: VNC1 service has resolution 1024x768, VNC2 has resolution 1280x1024 and VNC3 has resolution 1600x1200
You can also connect from a webbrowser with: <ip address:5801> if a vnchttp1 service is ‘On’

Shouldn’t be necessary, that’s actually part of what enabling “Allow Remote Administration” in YaST does. It enables xinetd itself, the vnc1 service in xinetd, and the vnchttpd1 service.

If you want the other ones (vnc2 and so on, with different resolution), you have to enable them manually in “Network Services (Xinetd)” though.

I’ve loaded up opensuse 12.3 and every time I try and vnc into the machine, I’m asked for a VNC password. I never make it to a remote screen on either a browser or using a vnc client. I set a vnc password to no avail. Is there something I’m missing here?

Thanks

If you just enabled “Allow Remote Administration” in YaST, you should not be asked for a VNC password. You should be able to connect to port 5901 via VNC, or 5801 via HTTP, and get a normal login screen.

If that doesn’t work, have a look at the server options for vnc or vnchttpd1 in YaST->Network Services-> Network Services (Xinetd).
But it should work like that (without a root password) with the defaults shipped in openSUSE, even on 12.3 (which is out of support since January btw).

I set a vnc password to no avail.

Where/how did you do that?

Is there something I’m missing here?

Well, you didn’t really tell what you actually did…

PS: in particular you should have the option “-securitytypes none” on the server command line, if you want to connect without a password.
But as mentioned, that should be there by default in /etc/xinetd.d/vnc. I just checked and 12.3 shipped with this:

service vnc1
{
    type        = UNLISTED
    port        = 5901
    socket_type    = stream
    protocol    = tcp
    wait        = no
    user        = nobody
    server        = /usr/bin/Xvnc
    server_args    = -noreset -inetd -once -query localhost -geometry 1024x768 -depth 16 -securitytypes none
}

If you have something different, change it accordingly, either in /etc/xinetd.d/vnc directly, or via YaST->Network Services->Network Services (Xinetd) as mentioned.

If that doesn’t help, you should probably tell how you are actually starting the VNC server for further help.

Sorry, just enabled the service in yast like the documentation tells you to do and as you mention above.

Not sure what else to try on this except I’ve read a few posts stating that 12.2 worked fine until upgrade to 12.3.

That is what the conf file looked like with the exception of -securitytypes none was not entered. I entered that myself and I got further in the process, to the gnome gui screen where I can login. It doesn’t matter if I choose and existing user or not listed, either browser based or tightvnc, I never get a password prompt. I had the setting set to -securitytypes=none (with the = sign)!

Well, that’s a config file.
If you (or some program, including YaST) modified it earlier, it will not be updated, and the options might not be ok for the current version.

It doesn’t matter if I choose and existing user or not listed, either browser based or tightvnc, I never get a password prompt. I had the setting set to -securitytypes=none (with the = sign)!

Ok. So you get the login screen now, but login itself doesn’t work?
Just to make sure: you cannot login with a user that’s already logged in. Maybe that’s the problem now?

This was a fresh install of 12.3. I org. enabled vnc via yast. Yes I do get to the gui login. There are no other users logged in when I connect. I have used both root and another user that’s on this box. I never get a login prompt on either user when attempting. I’ve seen others on the forum with the same issue with this version. Never had an issue with ver. 11. Tried 13.2 which didn’t seem to work. Hardware is an HP desktop 6000. I can’t imagine it’s hw related. About the only thing is from the netwok standpoint, It’s on a vlan segment that’s routed to the main segment where the ws I’m using to vnc from is located. All ports are open from one segment to the other. Going to try the 12.2 version. The other posts referred to .2 working fine.

Should be I never get a password prompt on either user when attempting

Just got done installing 12.2, patched it up and VNC works fine by just enabling it during the install. So what ever changes they did in 12.3, for some reason for some of us, it does not function correctly.

???
Of course you don’t get a password prompt after you logged in.
Or do you not even get a password prompt on the login screen?

What display manager are you even using? Sounds like GDM.
You might try something different, but the login screen is working now, right?

Well, “they” didn’t change anything regarding this AFAIK.
But of course 12.2 and 12.3 ship with different software versions (not only VNC but also Xorg and so on).

Why don’t you just stay with 12.2 if it is working there? 12.3 is old and out of support already too as mentioned, so I don’t really see a point in using that instead.

And try to login to a different desktop session (IceWM should be installed by default).
I know for a fact that KDE (and other Qt4 based applications) can have problems via VNC.
Also if one of the involved hosts has some proprietary driver installed, this can lead to problems as well, as that breaks Mesa and the software 3D renderer (would definitely break GNOME I suppose, but can lead to problems with KDE as well).

Your problem might be that the DE crashes, not directly something wrong with VNC itself.