Bug 116581

Summary:	up2date silently failes if no X server available
Product:	Red Hat Enterprise Linux 3	Reporter:	Josh Kelley <joshkel>
Component:	up2date	Assignee:	Adrian Likins <alikins>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Steve Salevan <ssalevan>
Severity:	low	Docs Contact:
Priority:	medium
Version:	3.0	CC:	csnook, jjneely
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:	3U9	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-06-21 16:40:30 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	119505, 124236

Description Josh Kelley 2004-02-23 14:55:31 UTC

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:

Comment 1 Jack Neely 2004-06-09 15:19:44 UTC

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.

Comment 2 Todd Warner 2004-08-27 01:03:33 UTC

In MODIFIED state. Assuming you have fixed it and you want me to get
someone to QA it?

/me grumbles about lack of comments.

Comment 3 Jack Neely 2004-08-27 13:53:51 UTC

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?

Comment 4 Chris Snook 2005-01-27 21:11:52 UTC

This looks like it's caused by the same thing that causes bug #146371.

Comment 5 Jack Neely 2005-01-27 21:29:47 UTC

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.

Comment 6 Pradeep Kilambi 2006-09-25 19:32:32 UTC

*** Bug 146371 has been marked as a duplicate of this bug. ***

Comment 7 Steve Salevan 2007-06-21 16:40:30 UTC

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.