This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 438364 - Debug guide for Satellite
Debug guide for Satellite
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Documentation (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Clifford Perry
: Documentation
Depends On:
Blocks: 462714
  Show dependency treegraph
Reported: 2008-03-20 12:00 EDT by Máirín Duffy
Modified: 2012-07-02 22:14 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-07-02 22:14:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Máirín Duffy 2008-03-20 12:00:16 EDT
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.
Comment 2 Máirín Duffy 2008-03-20 12:04:47 EDT
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?
Comment 3 Gerhardus Geldenhuis 2008-03-25 06:28:42 EDT
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.
Comment 4 Clifford Perry 2008-09-18 11:20:37 EDT
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. 

Comment 8 Lana Brindley 2012-07-02 22:14:10 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.