When running any program that requires root authorisation, nothing happens after typing in the password into kdesu. There is a delay, then kdesu disappears, then nothing.
Typing kdesu yast2 into a konsole produces this output:
kdesu(6298)/kdesu (kdelibs) KDESu::KDESuPrivate::KCookie::getXCookie: No X authentication info set for display ":0"
QProcess: Destroyed while process is still running.
kdesu(6298)/kdesu (kdelibs) KDESu::KDESuPrivate::KCookie::getXCookie: No X authentication info set for display ":0"
QProcess: Destroyed while process is still running.
Typing yast2 as root from konsole gives me:
No protocol specified
y2controlcenter: cannot connect to X server :0
(It’s a laptop with a monitor attached)
The machine authenticates normal users by LDAP and uses NFS home dirs, which all work fine. Logging into a root session from kdm allows me to run yast and other programs
I can use yast from the commandline (the curses version), but it’s not quite as practical
Any help?
Forgot to say, its an openSUSE 12.3 machine, installed from a full DVD
On 05/08/2013 08:46 PM, captain alge wrote:
> Logging into a root session from kdm allows me to
> run yast and other programs
should never do that! and having done so (even once) may be the cause
for your current problems.
always log into KDE as a simple user…then just click on the YaST
icon to launch it…and, it will ask you for the root password…
or, if you prefer you can launch a user terminal and issue
kdesu yast2
which will ask for the root pass and then launch the GUI version of
YaST…
if you have logged into KDE as root, or launched a user terminal and
then issued any version of su or sudo prior to the kdesu then you
have not followed the correct procedure, and should expect failure.
I don’t think so, especially if you’re just running “xauth -b”.
OK, I forgot to add that you should then enter ‘q’ to quit it again.
From xauth’s man page:
-b This option indicates that xauth should attempt to break any
authority file locks before proceeding. Use this option only
to **clean up stale locks**.
I often had this problem in 11.3 or 11.4, I don’t know what caused it, but “xauth -b” fixed it for me each time. It cleans up locks that are left over by (buggy?) applications, in my understanding.
To be honest, I don’t really know what its implications are. But if you do, please explain why you think it’s a security issue…
I would be interested to know, honestly.
I just created a local user, using passwd authentication and a local home dir, kdesu worked fine
However, I also have another laptop running openSUSE 12.3, which uses kdesu fine and is set up identically. This one was installed from the KDE 32bit live cd though…
That one does have XAUTHLOCALHOSTNAME
Not sure if it’s my understanding that’s wrong, but setting domain name in yast appends it to the hostname, rather than setting the domainname
So in yast,
Hostname: oli-top
Domainname: leenet
But hostname at a terminal outputs
oli-top.leenet
And domainname outputs
(none)
Not sure if that’s relevant…
I’ll try using a NFS3 mount instead, see if that works…
I guess that leaves it still a puzzle that you were having problems.
Interesting.
That happens here, too, though I had never noticed. It does not seem to cause problems.
I think domainname is supposed to be for the NIS domain, and doesn’t really matter if you are not running NIS (I am not). And, technically, the NIS domainname does not have to be the same as the Internet domain name. So Yast might actually be getting it right, and maybe Sun was getting it wrong.
kdesu(6298)/kdesu (kdelibs) KDESu::KDESuPrivate::KCookie::getXCookie: No X authentication info set for display ":0"
QProcess: Destroyed while process is still running.
kdesu(6298)/kdesu (kdelibs) KDESu::KDESuPrivate::KCookie::getXCookie: No X authentication info set for display ":0"
QProcess: Destroyed while procoss is still running.
