From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 Description of problem: When I SSH to a remote machine (with X forwarding enabled), with no X server on my local machine, and run "up2date perl-CGI" to install the perl-CGI package, up2date silently fails. Version-Release number of selected component (if applicable): up2date-4.2.5-1 How reproducible: Always Steps to Reproduce: 1. SSH to a remote machine, with X forwarding enabled, and without an X server on the local machine. 2. Run "up2date perl-CGI" (or another uninstalled package). Actual Results: up2date exits with no output and apparently without doing anything. Expected Results: Error message regarding the lack of an X server, or automatically fall back to --nox mode. Additional info:
I'm having similar issues with up2date in RHEL 3. (up2date-4.2.16-1) At NCSU we use the kerberos tool ksu quite heavily which doesn't affect the DISPLAY variable but you do get different xauth information. If I try to use the --nox option up2date still complains about bad X authentication and will not run in any mode. [root@rk-build jjneely]# up2date --nox subversion X11 connection rejected because of wrong authentication. [root@rk-build jjneely]# echo $DISPLAY localhost:10.0 I get the same error even after unsetting DISPLAY and removing all the ~/.xauth files.
In MODIFIED state. Assuming you have fixed it and you want me to get someone to QA it? /me grumbles about lack of comments.
Nope, with 4.2.33-1 it still tries to contact the X server even with the --nox option. Appears to be harder to reproduce but 'ksu' still does it. pams% ksu WARNING: Your password may be exposed if you enter it here and are logged in remotely using an unsecure (non-encrypted) channel. Kerberos password for jjneely/root.EDU: Authenticated jjneely/root.EDU Account root: authorization for jjneely/root.EDU successful Changing uid to root (0) [root@rk-build jjneely]# up2date --nox X11 connection rejected because of wrong authentication. What information do you need?
This looks like it's caused by the same thing that causes bug #146371.
Yes, they are duplicates. The problem is the consolehelper application. It ignores any arguments to up2date (obviously) and tries to pop up the X dialog for you to get root authentication. If I use /usr/sbin/up2date which doesn't run me through the consolehelper I get the proper behavior.
*** Bug 146371 has been marked as a duplicate of this bug. ***
I ssh -Xed from machines with no available X server to the boxes where I was testing this issue and ran the up2date command, looking for a package I didn't yet have installed. up2date failed back to the nox mode and proceeded with the operation. As this bug looks airtight now on 3U9 and 4U5, I'm moving this issue to CURRENTRELEASE.