I can give it a try, but I need to investigate how to set it up successfully. If I fail, I will return the article to the queue again.

@lruzicka Hope your new year is off to a good start.

I'm checking with you to see if you have a status update on this article.

Thanks

@rlengland Hello, thank you for asking. I hope the same for you.

So, I have investigated various sources on VNC and I could set up several scenarios on Fedora 35:

• Sharing the current session over VNC using TigerVNC and x0vncserver. (xorg only)
• Sharing the current session over VNC using Gnome settings. (xorg and wayland)
• Creating an independent VNC (TigerVNC) session that allows two independent connections, local and remote for the same user (xorg only)
• Running TigerVNC as a system service that enables remote connection to the machine but disables local connections of the same user, however this could be overriden when starting the service via SSH first before the remote connection should be made.

It seems that sharing one session and access this session independently from two different machines is quite impossible. Because whenever this is shared, then the remote computer is open and accessible from the outside (for example, if I would like to have one open session at work and access it from my home, working in it would open the session at work, too, which is totally stupid.)

Which of the above should the article be about? What do you think?

@lruzicka Hi.

I guess my initial reaction would be to suggest the most likely option that people would encounter "out of the box". In other words, GNOME on xorg and wayland. This, I suspect, would require less installation of additional software than using TigerVNC. It would also not be exclusive to xorg systems.

It would probably be good to mention other options like TigerVNC and perhaps NoMachine but indicate the aim of the article is a single technique.

Perhaps @glb has some input on this. I've been a NoMachine user for a long time and have used TigerVNC, but only on my home network so I'm not a real good person to discuss the security issues that may exist.

We should probably try to stick with FOSS where possible for Fedora Magazine.

As for accessing a single session from separate machines, I think that can be done as long as the two machines are both remote (i.e. you need at least three systems -- a "server" and two or more clients).

If it doesn't work the way you want, it is probably better to hold off on writing the article until the desired feature is available rather than promoting something that is less impressive. We can put this back in the ideas bin if you are no longer interested in it. Just let us know so that others know they can take it up if they want.

Just my 2¢. Thanks.

@glb is right. I wasn't thinking with my Fedora Linux hat on. FOSS would eliminate both TigerVNC and NoMachine.

@glb is right. I wasn't thinking with my Fedora Linux hat on. FOSS would eliminate both TigerVNC and NoMachine.

(This comment has been edited)
@glb and @rlengland

I spent some more time investigating various options of how to do things and I was able to:

1. Share the screen in Gnome using Gnome screen sharing functions, enabling:
   * one user is logged on a machine that runs the session (a.k.a. server).
   * he/she shares the screen
   * another user can connect to it, however as soon as the server session is terminated, or simply locked, the connection is lost immediately. According to Gnome people this is by design to protect the remote machine. However, there is a Gnome extension that enables to share even a locked screen, so the screen can be unlocked from the remote connection. Unfortunately, if this happens, the local session will be unlocked too, so it is not suitable when the server machine could be compromised easily (like when it it placed in the office with people sharing the space).
2. Use TigerVNC and have a connection started by a service. This connection will run on the server and could be connected any time. When left open (even on disconnect), it stays there and can be accessed again with all work preserved until the user logs out. Logging out stops the service and it needs to be restarted again, before any other connections are made. This enables to work remotely, without any effect on the server machine, which does not show anything except the login screen. If there is a user VNC session active, the user cannot log in locally (on the server) without terminating the session first.
3. Set up TigerVNC to be able to communicate with GDM (Gnome Display Manager) and let the user make a login on the server. The good thing about this is that no sessions need to be running prior to the login attempt. This works for a true headless setup. However, out of the box, this reliably works with Gnome Classic (which should be fine, as Gnome Classic could still be chosen when logging in). With Gnome Classic, the same user cannot create a local (on server) and remote (on client) sessions. I suspect that some system variables are locked so the instance cannot be properly opened.
4. The same scenario as 3 but replacing Gnome Classic with something simple, like Fluxbox, enables to spawn session locally and remotely without any obstacles, so the user can be logged in locally, go home and log on remotely into a parallel session. I could imagine that some applications would lock the opened files, so there could not be accessed from the other session anyway, but it is possible.
5. Anything what is not a Gnome solution will only run through Xorg and not Wayland.
6. The VNC connection in 3 and 4 can be tunnelled through SSH to get security.

I feel that because this topic has not been addressed since Fedora 31 (over 2 years), the solution might not be that straightforward and simple as it may seem, and this is as far as I could get by studying the VNC mechanisms. There might be some secret Gnome tweaks that would allow to use Gnome Session over the Gnome Classic or to have multiple instances of Gnome running in parallel, but I do not know them so far and I have no idea where I would look.

My suggestion is that we might split this into two articles:

• How to share the screen in Gnome where we could also reveal the secret extension and enable to unlock the session remotely. That could be enough for some of the users.
• How to create a remote server that accepts connections over VNC with TigerVNC and Fluxbox (or Gnome Classic) that would show a real way to use a remote system.

What do you think? Is it enough knowledge, or shall we move it back to the pool and wait if someone else knows more?

We should probably try to stick with FOSS where possible for Fedora Magazine.

As for accessing a single session from separate machines, I think that can be done as long as the two machines are both remote (i.e. you need at least three systems -- a "server" and two or more clients).

If the session is "Shared" then a session can be controlled from both the server and clients (but it leaves the session open on the server and could be interfered with any time. If the session runs headlessly, then it can only be controlled remotely by one of more clients. Using a control and a view only passwords can, for example, be used to stream the content from one session onto several computers where it only can be watched.

If it doesn't work the way you want, it is probably better to hold off on writing the article until the desired feature is available rather than promoting something that is less impressive. We can put this back in the ideas bin if you are no longer interested in it. Just let us know so that others know they can take it up if they want.

Just my 2¢. Thanks.

@lruzicka It looks like you've done a lot of good research. Please do go ahead and write it up as multiple articles if you think you have enough content for that. Thanks!

@rlengland and @glb ,

Hello, so I have finished the draft of the first article that describes how to set up VNC sharing using Gnome. The preview is here: https://fedoramagazine.org/?p=35875&preview=1&_ppp=769e7b745c

How, shall I proceed now?

Thanks for letting me know.

Just letting us know that your article is ready for review is sufficient for now. I've moved this card to the "review" status/column and an editor will review your article sometime in the next few days to assess whether it is ready for publication or needs more work.

Thanks!

@lruzicka are there any firewall settings for vnc_server etc. that need to be called out in the setup process ? I seem to be able to use remmina to connect via ssh but not vnc. It says "Unable to connect to server"
Is there a service that needs to be enabled and started, perhaps?

@lruzicka are there any firewall settings for vnc_server etc. that need to be called out in the setup process ? I seem to be able to use remmina to connect via ssh but not vnc. It says "Unable to connect to server"
Is there a service that needs to be enabled and started, perhaps?

I have not set up any VNC server, nor firewall. When Fedora Workstation is freshly installed, the port range 1025 upto 65535 is opened by default.

I am running Gnome shared Fedora in a virtual machine and its IP address is 192.168.122.205. All libvirt VMs are placed on the 192.168.122.* subnet. I can normally connect from both another VM (where Remmina is installed) and from the host computer (which runs the VMs and where another Remmina instance is installed).

But your settings might be different and maybe your ports are closed. On Fedora, you could check with sudo firewall-cmd --list-all and you will see what services or ports are opened. Check that you can ping the server from the client. Also, if you are running a standalone VNC server, the workflow might not work, because the VNC server may be blocking the 5900 port and listening on some other port, such as 5901 or 5902. The safest bet for the described workflow is when there isn't another screen sharing running - so that might be worth mentioning in the article.

I wonder what the problem is with your set up. Please, let me know.

@lruzicka

Okay. I've figured out what is going on. There appears to be, in fact, a service of some type running on the server end because you need to have Remmina installed on BOTH machines that comprise the server/client pair.

That part, the need to have Remmina install on both machines. is missing from your description. Can you add that requirement in your article in a somewhat prominent way, please?

Other than that it is a well written article.

@lruzicka Would you like me to amend your article to add the requirement that Remmina be installed on both the server and client?

It is odd that it should need to be installed on the server since it says it is just a client.

Name         : remmina
Version      : 1.4.21
Release      : 1.fc34
Architecture : x86_64
Size         : 940 k
Source       : remmina-1.4.21-1.fc34.src.rpm
Repository   : updates
Summary      : Remote Desktop Client
URL          : http://remmina.org
License      : GPLv2+ and MIT
Description  : Remmina is a remote desktop client written in GTK+, aiming to be useful for
             : system administrators and travelers, who need to work with lots of remote
             : computers in front of either large monitors or tiny net-books.
             : 
             : Remmina supports multiple network protocols in an integrated and consistent
             : user interface. Currently RDP, VNC, XDMCP and SSH are supported.
             : 
             : Please don't forget to install the plugins for the protocols you want to use.

I wonder if installing the client is causing a side-effect that just happens to make it work? Maybe installing the client adds a firewall rule, for example? Or maybe just the remmina-plugins-vnc package needs to be installed on the server side? I don't know anything about it. But it doesn't seem like it should be necessary to add a VNC client to the server.

@glb Until I installed Remmina on both virtual machines (both the client and server) I could not make a connection. It's possible that the installation set the firewall or service daemon but I couldn't track down the cause (but I'm not an expert on comm. issues)

@glb @lruzicka My apologies for the noise. I have found the issue that was thwarting my attempts to duplicate the Remmina connection. There was an issue with my home router.

I've successfully duplicated the steps in the article.

@glb @lruzicka My apologies for the noise. I have found the issue that was thwarting my attempts to duplicate the Remmina connection. There was an issue with my home router.

I've successfully duplicated the steps in the article.

That's great news. I also retested the steps several times yesterday and I did not need Remmina on the server, so I am happy that there is no hidden trap in the described process. :)

@rlengland I wonder if we should start making it a practice to enable public preview after we've edited and scheduled articles in WordPress and then post the link on the Discourse Meeting and Publication Schedule? My thinking is that it might give the Fedora Community a chance to provide feedback on the articles before they go live to a wider audience. I've done this as an example here.

Also, since Zinebot failed to update the forum automatically during the last meeting, you can create a new post on the Meeting and Publication Schedule thread with the following two lines to add an entry to the calendar.

[date=2022-01-28 time=08:00 timezone=UTC]
Sharing the computer screen in Gnome

If you want to add the public preview link to the above, just append a blank line and then the link (verbatim) to the post (Discourse will generate the preview with the excerpt).