Bug 495217 - satellite-debug - additional data: usage, sudoers/user/group info, and database optimizer settings
Summary: satellite-debug - additional data: usage, sudoers/user/group info, and databa...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: sos
Version: 5.6
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Keith Robertson
QA Contact: BaseOS QE
URL:
Whiteboard:
Depends On: 486526
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-04-10 13:28 UTC by Miroslav Suchý
Modified: 2016-07-04 01:33 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 486526
Environment:
Last Closed: 2011-06-05 18:54:57 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Miroslav Suchý 2009-04-10 13:28:04 UTC
Can you please add this information to report produced by rhn plugin of sos? Thx.

+++ This bug was initially created as a clone of Bug #486526 +++

Description of problem:

Listed below would 3 useful additions to satellite-debug - I can break them out into separate bugs, if needed.

1. Usage information:

This is very useful information and frequently requested especially in cases of large deployments and/or performance problems.  The results from the following queries gives a general picture of the deployment size and usage of the Satellite, including the number of servers, packages, channels, etc.. -

select count(*) from rhnpackagename;
select count(*) from rhnpackage;
select count(*) from rhnchannelpackage;
select count(*) from rhnchannel;
select count(*) from rhnserverchannel;
select count(*) from rhnserver;
select count(*) from rhnservergroup;
select count(*) from rhnservergroupmembers;
select count(*) from rhnUserManagedServerGroups;
select count(*) from rhnUserDefaultSystemGroups; 

Additionally, in the case of users who for some reason cannot or prefer not to give this information to be queried, a "--no-usage" option can be added to not run these queries and include results in the satellite-debug tar.

2. The sudoers file and tomcat, apache, and oracle user/group information

There're a significant number and types of problems that are caused by incorrect/missing configuration in /etc/sudoers and/or user/group setup in the /etc/passwd and /etc/group files.  Including /etc/sudoers file, and the output of grepping for tomcat, apache, and oracle in /etc/passwd and /etc/group would be very useful.

3. Oracle configuration

Starting with Satellite 5.2.0, the supported/embedded oracle database version is 10g (from 9i), this in addition to some performance issues that are currently under investigation have resulted in some workaround being applied, to avoid future confusion, it would be very useful to query these configurations in the database for Satellites 5.2.0 and above:

select dbms_stats.get_param('METHOD_OPT') from dual;
select value from v$parameter where name='optimizer_mode';
select value from v$parameter where name='optimizer_index_cost_adj';
SELECT X.KSPPINM NAME, DECODE(BITAND(KSPPIFLG/256, 1), 1, 'TRUE', 'FALSE') SESMOD, DECODE( BITAND(KSPPIFLG/65536, 3), 1, 'IMMEDIATE', 2, 'DEFERRED', 3, 'IMMEDIATE', 'FALSE' ) SYSMOD, KSPPDESC DESCRIPTION FROM SYS.X_$KSPPI X WHERE X.INST_ID = USERENV('INSTANCE') AND X.KSPPINM = '_optimizer_cost_based_transformation' ; 

Version-Release number of selected component (if applicable):
All.

How reproducible:
See above.

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

--- Additional comment from cperry on 2009-02-20 11:56:33 EDT ---

Milan - I recently sent Jan an email similar to this. Would be great if you two could work together to review what makes sense above and anything missing. I noted as a concern we needed a way to capture and look for those customers running say role based vs cost and never change to the correct long term resolution. 

Thanks,
Cliff

--- Additional comment from mzazrivec on 2009-03-26 09:09:40 EDT ---

spacewlak.git master:
bf56c0495d6cfe4f59b7bc0ec15b9acb13148486
1766b8bb663b179c2ced25bb6b0dc19e9c852374
b8db0d49f6add0b6449243ecd56b4ef0ccb84f37

Additional data included into spacewalk-debug archive:
* /etc/sudoers
* apache, oracle, tomcat, nocpulse entries from /etc/{passwd,group}
* database: row counts for all rhnsat tables
* database: select dbms_stats.get_param('METHOD_OPT') from dual;
* database: show parameter

All database statistics are put into db-stats/db-stats.log

--- Additional comment from jpazdziora on 2009-04-06 06:33:39 EDT ---

Added 78bf864796b0612fb3e848138714ae2266622ce7 for db-stats/ to database/ rename, and 9067493f14e8c1505bf00b875fa2ef27677b7331 for alert.log backup.

--- Additional comment from mzazrivec on 2009-04-10 08:56:17 EDT ---

Created an attachment (id=339087)
example of schema upgrades history output

Commits dac2399e8a258e5122d781b054a29739f32c749c in spacewalk.git master
and 75fbc57c370d51bec64698515b4559b94fd4cd1c in spacewalk.git VADER
added history of schema upgrades to the debug output.

Comment 2 Miroslav Suchý 2009-06-10 07:31:41 UTC
I have no patch for sos. You may extract it from our patches, but it will require some work to bend it to sos needs.
I will be no problem if it will go to 5.5.

Comment 3 Adam Stokes 2009-09-08 15:17:00 UTC
Can I get these queries from pipe from stdin?

Thanks
Adam

Comment 4 Jan Pazdziora 2009-09-14 11:49:12 UTC
(In reply to comment #3)
> Can I get these queries from pipe from stdin?

Yes, you can pipe the queries to stdin of sqlplus.

Comment 8 Bryn M. Reeves 2011-01-14 15:57:13 UTC
Rather than add new code to sos to capture the same information as satellite-debug couldn't we just run sat-debug and include the data in the sosreport?

Comment 9 Miroslav Suchý 2011-01-17 08:04:04 UTC
Satellite-debug is in different channel, so you will have to take care about that.
But yeah, everything is possible.

But some time ago (ehm several years) was the idea that sos will replace satellite-debug one day. But if it did not happened now, it will probably not happen in future.

Comment 10 Bryn M. Reeves 2011-04-06 14:00:46 UTC
So.. sos has been through a few different owners in the last year so I'm sorry if this is something that was agreed to previously (I haven't found any documentation of that..).

Generally our approach now in sos is never to re-invent wheels. If a project usptream or vendor has a preferred tool to get data we call that from sos and avoid creating new formats for other tools to have to parse.

We do not do anything to do with package installation in sos itself - we'd expect that satellite-debug would already be installed on systems that could use it.

Is that assumption safe?

Comment 11 Miroslav Suchý 2011-04-06 14:09:06 UTC
Yes satellite-debug will be always installed. It is in package satellite-branding and it is one of the essentials.

Comment 12 RHEL Program Management 2011-06-05 18:54:57 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.


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