I am attempting to set up an automatically starting, one shot vnc config according to wiki portal on vnc. Using the sysconfig editor in Yast, I changed the default display manager to kdm and enabled xdmcp support, and then changed the remote administration option to allow vnc without session management. It’s when I try to exit the remote administration setup program in Yast, that my woes begin with a truly irritating warning message that I need to restart the display manager for my changes to take effect. I have restarted the DM repeatedly, but whenever I go back to Yast and the remote administration set up utility, the same thing happens. I tried lightdm as well with similar results. I even tried changing window managers thinking that since the DM and WM are so closely linked, one might effect the other. My end goal, forced on my by my wife, is to securely enable desktop sharing with the mother-in-law’s computer. I figured I could do this by running vnc on an encrypted TCP tunnel using ssh port forwarding. Step one seemed to be to set up the MIW’s box first and then configure the vnc-viewer on my machine. If this doesn’t seem like the sane way of approaching this, well…
Note: I just bought the MIW a new laptop and put Gecko-rolling on it with the Plasma 5 DE, the same arrangement I use.
First,
I don’t remember if kdm supports remote administration properly.
The general recommendation is to use lightdm.
Next,
I’d caution against deploying Tumbleweed in a situation where you can’t support the machine locally. Because TW is a rolling release which sometimes introduces unstable updates (which then need to be fixed and re-issued), you won’t have an OS that is biased heavily towards reliability. And, I’m going to guess your mother in law won’t really care about the latest this and that from a rolling release, she’ll want a machine that’s reliable and won’t cause problems. So, you should install LEAP, not TW.
The last question I’d ask is why you find yourself re-running the YaST Remote Administration module more than once. It’s only to be used for initial setup and then maybe to reconfigure the options set by the module… Otherwise you shouldn’t want to run it again.
Well, okay then, I guess I made several mistakes along the way. Re-running the remote administration module so that it exited without the display mae nager restart warning instead of leaving it be, choosing a rolling distro to avoid an eventual re-installation in the misguided belief that even the testing version of OpenSuse was so stable it didn’t matter, and, then I suppose, asking for help in the first place after being able to glean so little from the available Suse documentation. Foolish me for think that install Arch and BSD from the command line prepared me for this kind of grief…
A lot of times marketing doesn’t describe the cons to go with the pros, but some of this is pretty common now…
AFAIK all the major distros have followed the openSUSE lead making their Development versions their rolling version. So, for instance the Kali pen-testing suite I use is based on the Debian “rolling release” Development distro. Seems to me that Arch is also moving towards or is already implementing a similar rolling release, don’t know about BSD.
AFAIK a reboot is necessary only if changes are made to the Display Manager, and perhaps to start services(particularly the xorg x-server) automatically (but services can be started manually, instead).
Linux (or for that matter *NIX) is always going to be a little bit of an adventure, but ask in these forums and generally your problems will be addressed.
Tried awhile back to start up VNC with Plasma on 42.1, did not succeed, similar results as you. It was not crucial, just playing around at the time, and left it to look at another time when I am in the mood.
However, I have recently installed 42.2 on a couple of my other machines and I am having no problems with VNC to and from them, but note that I installed Xfce as the desktop on those machines, using lightdm.
First, on each machine, set up VNC with Session Management. This will allow you to physically show your MIL how to do some things, as she will be able to watch along.
When you do so, of course, you will need to restart – I personally prefer to reboot the machine or shut down and restart it – the Display Manager.
You only need to do that once. It should open the necessary channels and install required components.
Then, use the Software installer to make sure you have x11vnc installed on both ends.
Once that is done, you make sure the router (if your MIL has one) has the appropriate 5900+ ports mapped to her computer, so the router firewall lets you through.
Running VNC:
This first example requires that your MIL (or whoever) must be logged in to the desktop.
You will use two terminals at your end. In terminal one, issue:
You will be asked for her password.
Of course, replace “herusername” with her actual user name, and the xxx’s with the proper IP address (or, if using a dynamic DNS service and a host name, you can use the username @ whatever.dyndns suffix you have created).
Back at your end, you would then issue:
vncviewer localhost:0
You then use F8 for a popup to control the session. When done, use that F8 popup to quit.
If the machine is on, but she is NOT logged in, you would ssh to her username on that machine and issue:
vncserver
It will come back with a prompt:
You will require a password to access your desktops.
Give a password to use, does not have to be the same as her password for this action.
Make note of the display number on the resulting output.
Would not hurt you to keep a note about the other information in the output, could come in handy sometime.
Note that I changed 5900 to 5902 in both places, to match the port for display 2, and of course at the end of the line changed the display from 0 to 2.
In terminal 2, you then issue:
Have here some 13.2 and TW machines running headless without problems for more than a year now.
On a fresh installed system of TW with KDE run in a user console:
vncserver :1
(install the missing dependency for tigervnc, after that you will be asked for the new password for the vncserver, up and running, allow the vncserver in the local firewall of TW, if necessary).
Create a file named /etc/systemd/system/vncserver@.service
[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target
[Service]
Type=forking
User=USERNAME OF YOUR USER
PAMName=login
PIDFile=/home/USERNAME OF YOUR USER/.vnc/%H:%i.pid
ExecStartPre=-/usr/bin/vncserver -kill :%i > /dev/null 2>&1
ExecStart=/usr/bin/vncserver -depth 24 -geometry 1280x800 :%i
ExecStop=/usr/bin/vncserver -kill :%i
[Install]
WantedBy=multi-user.target
