Description of problem: f I have to mention one big frustration than it would be lack of documentation on debugging satellite and the difficulty of doing so. There is a number of log files with mostly not very informative messages( maybe for developers but not for me) and very little explanation of what gets logged in what log file.
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