How to tell the OS version on a given client?
I need to be able to quickly and easily see what the OS version of all of the client servers associated with the Satellite. Which page has, or can be configured to have, that data readily available?
Note: I need to see ALL of the clients at once, not click through to each individual page. Surely there must be some way to do this.
Responses
Guru
6863 points
Hey Cory,
The following would provide you what you need:
spacecmd report_kernels > /tmp/spacecmd-report_kernels.out
grep el5 /tmp/spacecmd-report_kernels.out
grep el6 /tmp/spacecmd-report_kernels.out
which will output
hostname kernel
prdmas02.company.com 2.6.32-279.el6.x86_64
If you don't want to install spacecmd, the API call client.system.getRunningKernel() would likely work.
If you need to do this from the UI, the only way I can think of
click on Channels and on the right should be the count of the systems in each base channel. Click on that and click Download CSV.
EDIT: spacecmd is part of the EPEL repository. That said, I, personally, would not leave EPEL active on my own Satellite as I try to keep my Satellite as "vanilla" as possible.
Otherwise, I believe rpmfind.net is reputable
http://www.rpmfind.net/linux/rpm2html/search.php?query=spacecmd
Guru
6222 points
Hi James,
Where to find the spacecmd rpm? Is it provided by Red Hat customer portal, or is it an EPEL product?
Kind regards,
Jan Gerrit
It's an interesting point you make re: tracking which OS version is being used in the environment.
In my experience across multiple sites, I haven't yet come across one that pays much attention to the Red Hat minor/point release numbers, only the major 4.x,5.x,6.x... so in essence the major versions are treated as rolling releases.
Generally the way this is managed is to clone the base channel at a specific date and that becomes the organisations own 'point release' and servers are subscribed to that point so each host has the same package versions and errata. When updates are to be pushed to these servers, a new clone/point is made off the base channel and the channel subscriptions for the servers to be updated are changed to the new point and updated.
To determine which server is at each point you just look at the channel subscriptions.
Interested to know how you manage your servers. Do you build to the latest Red Hat minor version release and then update/patch when the next minor version is released?. Is there specific reasons (third party vendor support?) you keep to certain minor versions?
I agree you should be able to get the info you want easily from Satellite, but also interested how you use Satellite.
Guru
6827 points
Sometimes our management or security folks are interested in a list of servers with the specific version with the minor point release. A command to produce this helps to generate the report they request periodically.
Thanks for mentioning spacecmd from EPEL.
Here's a small rough query using spacecmd from EPEL. Shows the systems and their versions:
#!/bin/bash
fqdn=acme.com
/usr/bin/spacecmd package_listinstalledsystems redhat-release | egrep -v '^\#|^\-' | uniq
I experimented and pushed this script below as a scheduled query to my system group called "everything"
[notroot@myrhnserver ~]# cat /path/to/my/scripts/queryrhelver.sh
#!/bin/bash
echo -n `hostname -s` ": " `cat /etc/redhat-release`
echo
Then run the script to my system group named "everything"
First enter the spacecmd command UI
[notroot@workstation1 ~]# spacecmd -s SATSERVERNAME@FQDN
spacecmd {SSM:0}> system_runscript -f /path/to/my/scripts/queryrhelver.sh group:everything
User: root
Group: root
Timeout: 600 seconds
Start Time: 20140216T22:21:35
Script Contents
---------------
#!/bin/bash
echo -n `hostname -s` ": " `rpm -q redhat-release`
echo
Systems
-------
webdev1.myfqdn.com
server2.myfqdn.com
---truncated output---
Is this ok [y/N]: y
INFO: Action ID: 1134
INFO: Scheduled: XX system(s)
Get the ID that the script ran from the use of spacecmd above (it is above too):
[notroot@workstation1 ~]# spacecmd schedule_listcompleted | grep arbitrary
INFO: Connected to https://myrhnserver/rpc/api as youknowwho
1134 20140216T16:51:18 XX 0 0 Run an arbitrary script
--truncated list---
Wait for the cron to pick up the 'rhn_check' command, then view completed scheduled script:
[notroot@workstation1 ~]# spacecmd schedule_listcompleted
INFO: Connected to https://myrhnserver/rpc/api as youknowwho
ID Date C F P Action
-- ---- --- --- --- ------
1134 20140216T16:51:18 XX 0 0 Run an arbitrary script
Then view the output:
[notroot@workstation1 ~]# fqdn=acme.com
[notroot@workstation1 ~]# spacecmd schedule_getoutput 1134 | egrep '$fqdn|release'
INFO: Connected to https://myrhnserver/rpc/api as youknowwho
webdev1 : Red Hat Enterprise Linux Server release 6.5 (Santiago)
four0four : Red Hat Enterprise Linux Server release 6.5 (Santiago)
---truncated---
Remmele - this is good stuff! I had actually posed a question previously to the forum about this very topic (how to get the output of running scheduled job without having to use the UI). You have opened up quite a few possibilities for how I manage my environment. The ONLY thing left for me to figure out is how to create the job from the satellite server by passing in the bash script (rather than creating it, pushing it out, then calling it - which is awesome too). Seriously thanks!
Please feel free to update my other thread (so that you get points)
https://access.redhat.com/site/discussions/470813
From a security standpoint the version information from /etc/redhat-release is essentially useless.
The package that provides the file is redhat-release-server, this package has no dependencies, so this package being installed and at a specific version provides no information about the actual security posture of the server.
eg. You can have a server at version '6.3' with 200 outstanding errata, upgrade the single package redhat-release-server which will result in the server reporting as '6.5' in /etc/redhat-release and still have the same 200 errata outstanding.
An alternative method for getting the information from /etc/redhat-release if that's all you want (without using satellite),
Setup SSH keys for a standard user, put the server list into a text file and run:
for i in $(cat list.of.hosts); do echo "$i:"; ssh $i cat /etc/redhat-release;done
Guru
6863 points
PixelDrift - you are absolutely correct (in particular in stating that the release has ABSOLUTELY nothing to do with the security/errata of the host) - however... most of us have to comply with the most bizarre and categorically useless request from our security teams or auditors. Things like "please take screen shot of the password file" not "please list all users who have access by running a command that is easily repeatable and makes technical sense" (I'm sure you note my sarcasm ;-)
The for loop is a great option, but in our environment we have a number of hosts which are accessible from a single host and then for security reasons we have other hosts which need different separate bastian-hosts to go through.
Guru
6827 points
PixelDrift - just as James said, you are 100% correct. We are seeking this to quicken the response to those in managment above us who ask for it, while reminding them that it does not infer a security posture.
And I have done the exact thing you describe above with numerous queries using ssh already for a number of queries that can be ran as non-root - and mostly it works.
- However, when you have hundreds of systems, if one or a few are offline (and hangs the script), it sure is nice to at least run something from the Satellite server to get "it's take" on the query.
- nad James said it well with " - however... most of us have to comply with the ... request[s] from our security teams or auditors."
My other interest in this is the research and development people who periodically/persistently ask what version of tomcat/postgresql/apache, etc is installed on various servers. (or any other rpm someone may want and then pass it as a argument to the API script.)
I've been looking other places and found at least one API script/query that show outstanding errata, etc... per system.
I'm currently really close to a working perl script that will do this as an API.
And speaking of security - I'm wondering what others think of the perl module one can write so that the userid/password is not in any given script (refuse to input that into any script). I kinda do not want any file with userid/passwords on the server.
Guru
6827 points
duplicate post, whoops.
I have answered many external security audits requiring all manner of 'treasure hunts' and appreciate the inanity of many of the requests.
My post was suggesting a method as a potential alternative for the OP who did not detail any constraints on the environment, only the information that needed to be extracted.
Guru
6827 points
James - glad this bit helped. I will check out the other thread you speak of - thanks!
By the way, you can install/run spacecmd on a system that is not your Satellite server.
I tested it on a different system and it worked!
The only difference, is when you enter the spacecmd command UI from a system that is not your Satellite server, do this:
(However, change "yoursatserver@fqdn.com" to your fully qualified hostname & domain).
[notrootuser@workstation2 ~]# spacecmd -s yoursatserver@fqdn.com
The benefit is that you can then run scripts from your local system (protect them from others and make completely sure there is no chance they can be edited by anyone else but you (be careful, take extra measures).
Then in the spacecmd command UI, you can site the path/file with the '-f' bit, and not have to publish the scripts to the satellite server first.
I too would like a method where you could pass the script using spacecmd. I think it would really be through a perl API script (I'm working on those now, nearly there with a working template for some of the things I wish to do).
Guru
6863 points
I actually do install spacecmd on my local machine and run it from there, as well.
I have the rpm installed on the Satellite Server itself for the folks that can run some simple python/API/spacecmd stuff that aren't really that interested in Satellite (which.. I don't understand how they would not be excited about Satellite). I put some of the Pro-Tip foo on our Wiki for them to go execute.
Thanks for the tip though! I believe David Powell is going to alerting us all about a meetup for the Forum members at this year's Summit in San Francisco. If you are going, it would be cool to meet in person. Forum members can get a price-break (search in the forum announcements).
Guru
6827 points
Here's the perl version for searching the rpm 'redhat-release'
(Python is a fine scripting language, just have barely used it)
I do not plan on having the userid/pass permenantly on my system in a bare file, just can not do that...
I borrowed a portion of this script from Peter Gervase at Red Hat from another thread, but incorporated "RHNSession" perl module instead of having the userid/password within the script
#!/usr/bin/perl
use strict;
use warnings;
use Frontier::Client;
#use Data::Dumper;
### NOTE: Because of RHNSession, no userid/pass/hostname is in the script.
## tested only, actual userid/pass associated with RHNSession is removed after the brief test.
#
use RHNSession;
# NOTE: RHNSession requires a hand-built perl module
# see https://fedorahosted.org/spacewalk/wiki/SpacewalkApiPerlGuide
# You can place the RHNSesson.pm file in any place the script complains
# when you run it, such as /usr/share/perl5/vendor_perl/RHNSession.pm
# # MAKE sure to fix the SELinux context of the RHNSession.pm file
# method list_packages
# https://access.redhat.com/site/documentation/en-US/Red_Hat_Satellite/5.6/html-single/API_Overview/index.html#sect-errata-listPackages
#
use constant MAX_TRIES => 10;
my ($client, $session) = RHNSession::Session;
my $systems = $client->call('system.list_user_systems', $session);
## I am not a big fan of the overuse of "$_" as shown below. It can betray you later
## I combined a few scripts to make this and plan on re-writing it again
for (@{$systems}) {
my $systemid = $_->{'id'};
## package test
my $packages = $client->call('system.list_packages', $session, $systemid);
for my $package (@$packages) {
## the next line limits to the exact rpm you wish or else you get everything
next unless $package->{'name'} ~~ /redhat-release/;
my $systemname=$_->{'name'} . " ";
chomp $systemname;
print $systemname . " " ;
print $package->{'name'} . "-";
print $package->{'version'} . "-";
print $package->{'release'};
print "\n";
}
}
And this is the same script, just searches for the rpm httpd.
I'm more used to perl than I am python. I'm sure python is just fine since Red Hat uses it extensively (and they use perl too)
I borrowed a portion of this script from Peter Gervase at Red Hat from another thread, but incorporated "RHNSession" perl module instead of having the userid/password within the script
#!/usr/bin/perl
use strict;
use warnings;
use Frontier::Client;
#use Data::Dumper;
### NOTE: Because of RHNSession, no userid/pass/hostname is in the script.
### the config file with this is removed after the test, I can not take the idea of having
### the userid/pass anywhere in a bare file!
#
use RHNSession;
# NOTE: RHNSession requires a hand-built perl module
# see https://fedorahosted.org/spacewalk/wiki/SpacewalkApiPerlGuide
# You can place the RHNSesson.pm file in any place the script complains
# when you run it, such as /usr/share/perl5/vendor_perl/RHNSession.pm
# MAKE sure to fix the SELinux context of the RHNSession.pm file
# method list_packages
# https://access.redhat.com/site/documentation/en-US/Red_Hat_Satellite/5.6/html-single/API_Overview/index.html#sect-errata-listPackages
#
use constant MAX_TRIES => 10;
my ($client, $session) = RHNSession::Session;
my $systems = $client->call('system.list_user_systems', $session);
## I am not a big fan of the overuse of "$_" as shown below. It can betray you later
## I combined a few scripts to make this and plan on re-writing it again
for (@{$systems}) {
my $systemid = $_->{'id'};
## package test
my $packages = $client->call('system.list_packages', $session, $systemid);
for my $package (@$packages) {
## the next line limits to the exact rpm you wish or else you get everything
next unless $package->{'name'} ~~ /httpd/;
my $systemname=$_->{'name'} . " ";
chomp $systemname;
print $systemname . " " ;
print $package->{'name'} . "-";
print $package->{'version'} . "-";
print $package->{'release'};
print "\n";
}
}
And here's the output for that perl script I posted earlier, ran on a different system (not my satellite server)
(hostnames are changed, and on the left column below)
[root@sozo2 ~]# /root/scripts/queryhttpd.pl
four0four.isolated.com httpd-2.2.15-29.el6_4
four0four.isolated.com httpd-manual-2.2.15-29.el6_4
four0four.isolated.com httpd-tools-2.2.15-29.el6_4
three0one.isolated.com httpd-2.2.15-29.el6_4
three0one.isolated.com httpd-tools-2.2.15-29.el6_4
three0one.isolated.com rhn-org-httpd-ssl-key-pair-rhn1-1.0-1
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.