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@gmail.comwrote:
On Mon, Mar 17, 2014 at 8:50 AM, Samuel Winchenbach swinchen@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@gmail.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos