Well the slow dialog isn't the problem so much. I have disabled selinux just to remove one variable from the problem! Here are a list of applications and if they prompt for the root password correctly: "Add/Remove Software" - Application start fine, but when I click apply I get "Authorization Failed" dialog box. "Authentication" - Works great! "Firewall" - I get an org.fedoraproject.slip.dbus.service.PolKit.NotAuthroized.org.fedoraproject.config.firewall.auth error dialog box on start. "Services" - Application starts fine, but it never prompts for root password and none of the buttons (enable, disable, start, stop, restart) seem to do anything "Software Update" - Application starts fine but "Install Updates" doesn't do anything. "Users and Groups" - Works great! So it is strange that "Authentication" and "Users and Groups" work great, but the other fail one way or another. Different authentication mechanisms? I am really quite lost. Sam On Mon, Mar 17, 2014 at 10:57 AM, Les Mikesell <lesmikesell at gmail.com>wrote: > On Mon, Mar 17, 2014 at 8:50 AM, Samuel Winchenbach <swinchen at gmail.com> > wrote: > > > > The "several minutes" to open a window is not a rendering issue. The > user > > experience overall is _very_ good. As I use it more and more I can not > > seem to recreate the delayed root prompt. > > > > We have used freenx in the past, but with the change of licensing in the > > newest release and several difficulties (mostly involving Max OSX > clients) > > we have decided to go with RDP. > > Note that x2go does approximately the same as freenx/NX, using some of > the same supporting libraries. However, it is all open source, > including the cross-platform clients. I had some problems with > earlier versions, but the current version seems pretty good and might > be worth another look. It is somewhat nicer than the old NX client on > windows because it allows resizing the window after startup - and > resizes the remote desktop to match. It also claims to connect audio > and client disk shares, but I haven't used those features. > > A couple of things that can cause long delays that seem kind of random > are the first of your DNS servers failing with a timeout before the > retry to the good one, or something that does an IDENT query to log > the remote socket user hitting a firewall that silently drops the > packet instead of rejecting with an ICMP. > > -- > Les Mikesell > lesmikesell at gmail.com > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >