Bug 438364

We could expand on the maintenance section of the reference guide or even write
up a whitepaper. Do we have any internal debugging tip documents that we could
clean up and release? 

Some ideas:

* list out every log file Satellite touches and per file explain what kinds of
information gets logged.

* explain all of the pieces of the satellite-debug file we ask customers to send
in for troubleshooting?

I think the suggestions made already will go a long way in helping to more
easily debug Satellite. Debugging information should be part of of the standard
documentation as that is naturally where you would look first rather than a
seperate article/whitepaper.

It would be great to be able to know how to test functionalitly of various
components. For example knowing how to send a test jabber message to test
whether there are firewall problems.

Not necesarily debugging but a detailed section in help explanining exactly how
communications happen between the Satellite server and clients and time frames.
For example the client will only check in every x hours by default and will then
check a b and c, or if you use osad agent communication will happen in the
following way and when I scedule "z" it will take approximately n time to be
pushed out to the client.

Some commands like rhnpush can be more verbal when failing. We had a scenario
where a package was already uploaded and an engineer was trying to upload the
package again not knowing that it was already uploaded. The error message which
eludes me know was completely unreleated to the actual problem. Also using a
--test flag in that specific case worked but the actual upload failed. Using -v
flag did not improve verbosity to usable level.

This is not a documentation issue but thus help in doing debugging. It would
probably make more sense to new users to look for log files in
/var/log/satellite rather than /var/log/rhn. I know this is a minor thing but
your first expectation is to look for log files in a directory similar to the
deamon name.

I agree that making this information is a good thing. I do not think it should go into a static document provided by our docs team. We already have sections within the Satellite Guide on basic troubleshooting. All log files of interest for the product are captured by the satellite-debug command, so this gives a good starting point of any Satellite Admin to know easily, since it is what GSS asks for. 

I feel that we can provide supporting user debugging information in a public wiki, such as spacewalk, which can be used for both Satellite and Spacewalk administrators, since it is in essence the same code/files/locations/configs. 

I have assigned this bug to myself to complete that task. This will also allow for a central location where anyone internal or external to Red Hat and Satellite/Spacewalk can make continues edits and contributions, based on their own experience and knowledge. 

Regards,
Cliff.

We're going to handle this as part of the existing FAQs in the Install and User Guides.

Closing WORKSFORME, as it's being handled elsewhere.

LKB