Login | Register
My pages Projects Community openCollabNet
Project highlights: Stable Version: 1.6.1, Development Version: 1.7.6

Current Frequently Asked Questions

These are some common questions or problems I get with new admins using Current. If you feel something should go in here, please email me.


General Questions

What versions of the up2date client API are supported?

The 2.7 - 4.3 versions of the API are fully supported with the exception of server-pushed actions. The 2.5 version is no longer supported.

Does the server name need to be the real name of the server (so reverse name lookup works) or can it be a CNAME?

SSL requires that the hostname in the SSL cert matches the A record. So, yes, your server name needs to match the A record, at least as far as config files and SSL certificates go. Your hostname can be whatever.

Why can't you run cadmin when apache is running?

Version: 1.3 - 1.4.x

Because shelve (the python datastore used in 1.4) doesn't have any locking or other advanced "hey, look! the data's changed/changing!" features. Therefore, if you use cadmin while apache/current is running, you run the risk of data corruption, screwed up clients, current not noticing your changes, etc.

Version: 1.5+

This is no longer an issue, as we now use a postgres backend, which has all that database yumminess.

What ports does the server need to have open? I have a firewall

You need to have port 443 (https) and probably 80 (http) open. Or whatever you tell your clients, but as you're going to have to open 2 ports anyway, you may as well just use the standard ones.

I want to have a Current server that supports all versions of Red Hat Linux. How can I populate my servers with all the necessary RPMs?

There are many public mirrors of the Red Hat RPMs you can use. Once you have a server, you can mirror using:

  • wget
  • rsync
  • others

Troubleshooting

I can't get the clients to talk to the server - it never does anything, just gives me some ugly looking traceback on the client

Version: All

If you get SSL errors, very carefully check that your RHNS-CA-CERT file is correct. Current is now over a year old (yay!) and my test cert just quit working - look to make sure your CA cert or server cert hasn't expired.

Version: 1.0.x (critical), 1.3+ (almost unneeded)

Note the port numbers in your client and server configuration files. Two numbers are needed (one for encrypted traffic, one for unencrypted traffic), and while you can use any numbers you like, you have to use the same numbers on the clients and the server, and you have to make sure you get the ssl/non-ssl bit sorted out correctly.

The error messages for goofing this up are not very clear, and not something I can easily fix. If things don't work for you, make sure

  1. your /usr/share/rhn/RHNS-CA-CERT file is correct
  2. your client port numbers match your server port numbers
  3. you have ssl->ssl and nonssl->nonssl correct. (8080 is non-ssl, 8081 is ssl, by default)

The above 3 things account for about 70% of the complaints I get about current not working for people.

Version: 1.0.x only (1.3+ doesn't use stunnel)

One admin has noticed that recent versions of stunnel are built with libwrap/tcpwrappers support. Make certain that either you have configured tcpwrappers AND portblocking / firewalling rules correctly to allow your client machines to connect.

The best way to test this is to also have your server configured to be able to run up2date/rhn_register itself. If you can run rhn_register from your server, and it seems to work, but no other machine can, its a firewall/security/networking issue.

I'm trying to test current, and it seems to work the first time, but after that the clients aren't using the correct data from the server anymore

Watch out for client side caching - I lost a full days development time trying to figure out why the client never seemed to do more than one GET to the server, yet still knew the "wrong" answer. It caches darn near everything - which is a good, desirable feature, as long as you know its there!. Delete everything in /var/spool/up2date to get fresh hits against the database.

This also explained why they bothered having database "versions" or last_modified values - the client will know to pull down fresh data if the database changes. Yes, I felt bloody stupid.

Some of my clients work, but some don't. I get the traceback...

This is typically caused by the clocks of the client and server being skewed. (The root cause is a client bug). To prevent this, use rdate or ntp to sync the clocks together. The clocks don't have to be super accurate - ±5 minutes is fine.

This is also fixed in versions of up2date after 2.7.11 (I'm not exactly sure of when that fix went in) - using 2.7.63 or later is what I recommend.

When I add packages to an existing channel, or add a new channel, Current doesn't seem to see them right away.

Version: < 1.0.1

Please, PLEASE, never run cadmin at the same time Current is running. The correct way to deal with server updates is to shutdown Current, make your changes with cadmin, and then restart Current. 'service current stop|start' should work well for this. This was fixed in 1.0.1.

Version: 1.3 - 1.4.x

This is still a concern in 1.3+ - you must stop apache, use cadmin, and then start apache - there are no exceptions.

Version: 1.5+

This should no longer be a problem with the database backend. If you find any bugs, let us know!

When I run cadmin/up2date, I get a traceback ending with "xml.parsers.expat.ExpatError: no element found: line 1, column 0"

Version: < 1.4.4 and 1.5 - 1.5.5

This is bug #20. If you're using the 1.4.x branch, upgrade to at least 1.4.4. If you're using 1.5.x, upgrade to at least 1.5.5.

Even with the latest version, you're not going to see the problem on the client side--what's happening is that the server thread crashed (an exception was raised) and is sending a Fault (XML-RPC exception) to the client.

You need to look at the server-side logs and see what actually happened. That traceback is the one we need to figure out what went wrong. You may have to increase the log level to get useful output.

When I run cadmin, I get a traceback ending with "xmlrpclib.Fault: <Fault -1: "While running 'cadmin.createChannel': caught\nserver.apacheRequest.UnknownXML : Invalid request received (class xmlrpc.cadmin is not defined (function = createChannel)).\n">"

Version: 1.5+

This looks as if your server (the machine you're running cadmin create on) is pointed at RHN's servers in the /etc/sysconfig/rhn/* config files. For cadmin to work, the machine you run it on must be pointed at the Current server because it now uses those config files to determine where to send its requests.

I'm running Red Hat Linux 8.0 and I recently updated/installed apache and [now] Current won't work

Are your logs in /var/log/httpd? If so, the permissions probably got changed back to the default for apache packages in Red Hat Linux 8.0 and up. Because apache drops root permissions before Current starts running and only root can read the directory, Current can't get to its log file. Either change the permissions back or move the log file to somewhere the apache user can reach it. (Like /var/log)

I'm running Fedora Core 2 or Fedora Core 3 using a PostgreSQL database and I keep getting "Operational error in 'INIT'" in my current.log file. No cadmin command work. What's wrong?

In Fedora Core 2 and Fedora Core 3 some of the postgresql-python are very broken. So broken, in fact, that they will not execute any SQL commands. Upgrade to the latest PostgreSQL packages and the problem should be fixed.

I'm running Fedora Core 3, Red Hat Enterprise Linux 4, or greater OS and Current wont work at all. The current.log file says nothing is wrong. Up2date and cadmin always get "Internal Server Error" every time the talk to the Current server. What's wrong?

You need to disable SELinux. The Current source code and, most likely, your RPMS that would want Current to server are in directories where SELinux does not allow Apache to read. Edit the /etc/sysconfig/selinux file to disable SELinux and then reboot.