2 Problems down... 1 to go...

Hello again...

	The snapshot from the other day definitely seems to have nuked
the "wrong arguement count" problem.  I would count that problem as shot.

	Now, I've figured out two other problems that have been plaguing
me and I can report the "fixes" (or at least the work-arounds).

	In my original message about the first problem, I illuded to another
problem with up2date on the client side.  What had happened was that I
had updated several RedHat 7.2 systems and each and every one of them
would then fail to rerun up2date.  They would all get "SSL_connect error"
shortly after running.  This was really strange, since I could connect
to the SSL port manually, just fine.  I discovered what THAT was, almost
by accident.

	Part of the updates to RedHat 7.2 include an updated up2date
package.  That package includes /usr/share/rhn/RHNS-CA-CERT.  Since it's
not considered to be a configuration file, that cert gets overwritten
unconditionally by the update rpm.  Result is that the configuration
files point at the "current" server but the CERT file is for RedHat
once again.  The connection is rejected due to an invalid cert and gets
reported at an SSL Connect Error.  That error message is BOGUS and should
report a certificate error, instead, but that's a RedHat bogosity.

	So, problem #2 is fixed and I have a recommendation.  Please add
a warning to the documentation about the RHNS-CA-CERT stating that it
can get overwritten by any update to the up2date rpm.  A backup cert
should be saved somewhere on the system for the case when this occurs.
Also add a note that if you see the error "SSL_connect error" that the
problem may be the server certificate on the client has been overwritten.
It's certainly not obvious from that error.

	While the documention and FAQ mention the importance of that
certificate and checking that certificate when there is a communications
error, they should emphasize that it WILL be overwritten by some
updates without warning and without backup.  You may THINK you have
set it correctly and it may have worked in the past, but it will fall
over and drop dead after a update.

	Problem #3 is one I experienced on one other system before getting
these other two problems resolved.  Then I began experiencing it on several
systems.  On the affected systems, "up2date -l" runs until just after
"Removing packages marked to skip from list...".  After the hash marks
print, there is a delay of a period of time and then I get this error:

] Removing packages marked to skip from list...
] ########################################
] 
] Getting headers for available packages...
] Traceback (innermost last):
]   File "/usr/sbin/up2date", line 996, in ?
]     main()
]   File "/usr/sbin/up2date", line 342, in main
]     sys.exit(batchRun(argObj.getLong("list"), pkgNames, fullUpdate))
]   File "/usr/sbin/up2date", line 879, in batchRun
]     printCallback, percentCallback)
]   File "/usr/sbin/up2date", line 792, in runInteractive
]     progressCallback = percentCallback)
]   File "/usr/share/rhn/up2date_client/up2date.py", line 1539, in getUpdatedPackageList
]     refreshCallback)
]   File "/usr/share/rhn/up2date_client/up2date.py", line 796, in getHeaders
]     hdr, sourcetype = doCall(headerSource.getHeader, pkg)
]   File "/usr/share/rhn/up2date_client/up2date.py", line 302, in doCall
]     (errCode, errMsg ) = rhnHTTPlib.reportError(e.headers)
]   File "/usr/share/rhn/up2date_client/rhnHTTPlib.py", line 314, in reportError
]     if headers.has_key(s):
] AttributeError: 'None' object has no attribute 'has_key'

	The relevant segment from the current log seems to be this:

Feb 02 08:27:58 /usr/share/current/packagedb.py:getCompatibleChannels({'client_arch': 'i686', 'client_release': '7.2'})
Feb 02 08:27:58 /usr/share/current/packagedb.py:_getCannonArch({'arch': 'i686'})
Feb 02 08:27:58 Result was normal
Feb 02 08:27:58 sendClientResult() finished
Feb 02 08:27:58 requesthandler.log_error(): code 400, message Bad request syntax ("GET https://plover.wittsend.com:8081/XMLRPC/$RHN/{'X-RHN-Auth-Channels': [['redhat-linux-i386-7.2', '20020216143056']], 'X-RHN-Server-Id': 'plover.wittsend.com', 'X-RHN-Auth-Expiration': '1013956078', 'X-RHN-Auth': '532d455b9fc033dff0c508628f86d62e8b9940f5', 'X-RHN-Auth-User-Id': 'Michael H. Warfield'}/set_headers HTTP/1.0")

	When I looked at the up2date logs on the client side, I noticed
something REAL interesting.  The time stamps for the corresponding events
on the client side were almost 1-1/2 hours higher.  Opppsss...  I forgot
to set up ntp on these two systems and the "current" server was 1 hour
slow and the up2date client (my laptop) was a half an hour fast.  I figured
I should sync them up and rerun the test so that the logs would correlate.
After syncing BOTH systems to my stratum 2 ntp server, I discovered that
the problem went away!

	The above traceback and error is apparently being caused by
clock skew.  The system clock on each client system which failed
with the above error was advanced of the system clock on the "current"
server by more than an hour.  By playing with the time on one system and
rerunning up2date (after removing EVERYTHING in /var/spool/up2date)
it seems that the magic number is the client system one hour advanced
of the server system (client time minus server time greater than plus one
hour).  The client time can be retarded from the server time with no
apparent problem (I tried as much as several hours retarded, even a
full day behind the server system).

	I'm not sure if that's a bug or part of the spec or what.  It
needs to be documented, at the very least, if it's not a "fixable" bug.
Anyone else experiencing the above traceback, should check their
system clocks and time synchronization.

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  [email protected]
  /\/\|=mhw=|\/\/       |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!