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