I would suggest including some descriptive text/links in the distributed. Comment lines marked by # as well as blank lines are permitted. Remote sessions fall into the "any" bucket.) (Incidentally, for those who need it, the meaning of the three permissions is documented in the pklocalauthority(8) man page. # /etc/polkit-1/localauthority/50-local.d/colord-zap-auth.pklaĪction=-device -profile -device -profile -device -profile "Authentication is required to refresh the system repositories" dialog still pops up "Authentication is required to create a color managed device" dialog still pops up unless aforementioned workaround is used "Authentication is required to access the PC/SC daemon" dialog still pops up unless the workaround from #52 is used "Authentication is required to refresh the system repositories" dialog still pops up (Where possible, all platforms were updated to the latest patches available as of today.) O/S The color management dialog no longer pops up on RHEL 8, Ubuntu 18, or Fedora. Problems still persist on some platforms, but the situation is at least improved. I modified our server code so that the X RANDR output devices are named "VNC-*". Since these issues also exist with TigerVNC, the flavor of VNC that ships with Fedora, my opinion is that it should be incumbent upon the Fedora/Red Hat developers to fix them, not Thanks for the tip. If someone comes up with a solution to the new dialog, feel free to post it here. The best I can say about it vis-a-vis TurboVNC is: "It works, but I don't recommend it." GNOME 3 has performance issues in a remote display environment as well. I strongly recommend using MATE instead, or any other non-compositing window manager. I have done everything I can do to support it, but there are limits to what I can do. Works fine for me, but in Fedora, there is an additional dialog that you have to squelch:Īnd I notice that, specifically, in FC29, there is a new dialog: "Authentication is required to refresh the system repositories." I'm not sure how to squelch that one, but I'm imagining that the process would be similar to the others.įolks, I cannot emphasize this enough: these are hackish workarounds necessitated by the fact that GNOME 3 simply doesn't provide proper support for running in a user-level X server such as Xvnc. On Fedora 24, an additional dialog pops up ("Authentication is required to access to PC/SC daemon.") Refer to #52 for the workaround to that issue. This issue is known to exist in current versions of RHEL 7, SLES 12, Fedora 22, and Fedora 24 as of this writing. I've personally verified that the issue exists with TurboVNC 2.1 beta and TigerVNC 1.6 (both the "el5" flavor, which is based on the same X.org 7.7/xorg-xserver 1.12 code as TurboVNC, and the "el6" flavor, which is based on xorg-xserver 1.15.) Verified that the workaround listed at the above link solves the problem, but since that workaround requires specifying a group to which to grant colord permissions, it isn't exactly a generic solution. This seems to be a problem endemic to all X proxies running on recent Linux distros that use GNOME 3 (yet another reason to use MATE instead, at least with TurboVNC.)įor further information, as well as a workaround. When launching GNOME 3 (including Classic) in TurboVNC or resizing the remote desktop under GNOME 3, a dialog pops up ("Authentication is required to create a color managed device"), and it cannot be dismissed without authenticating using the root password.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |