yum

RHEL7: Registering a System with the Red Hat Network Using Subscription Manager

/ Christopher Paquin / 1 Comment

howto-draw-octopuses-tutorials_html_101880e

Note that I am about to give you the simpletons version of registering a system. Expect nothing fancy below. In  this post I will do my best to keep it brief.

If you need to register newly build RHEL 7 system using Subscription Manger rather than the ‘rhn_register’ command (which is pretty much deprecated) you will need to run the command as shown below. Including the option  “–auto-attach“ is pretty much the simplest method to register with RHN, as you  do not need to keep track of any of your subscription names.

[root@rhel7 ~]#  subscription-manager register –username <username> –password <password> –auto-attach

Once auto-attached you can log into rhn.redhat.com, and use the WebUI to pick and choose any additional subscriptions that you want to attach.

Once you have attached as many subscriptions as your heart desires (or you are licensed for) ,you can then run the following command to see each and every yum repository that you have access to, even if they are disabled.

[root@rhel7 ~]# yum repolist all

Depending on the number of repos that you have access to, so you might want to narrow the list down a bit, as shown below.

[root@rhel7 ~]# yum repolist all | grep -i openstack-6

rhel-7-server-openstack-6.0-debug-rpms/7Server/x86_64                           disabled
rhel-7-server-openstack-6.0-installer-debug-rpms/7Server/x86_64             disabled
rhel-7-server-openstack-6.0-installer-rpms/7Server/x86_64                        disabled
rhel-7-server-openstack-6.0-installer-source-rpms/7Server/x86_64            disabled
rhel-7-server-openstack-6.0-rpms/7Server/x86_64                                      disabled
rhel-7-server-openstack-6.0-source-rpms/7Server/x86_64                          disabled

Now you can enable the repos that you need with the command below. Note that the enable option accepts wildcards, but also note the discrepancy in the repo names in the command output above, and in the command below. If you are not passing a wildcard option on the enable command, then you will need to modify the repo names before you can run your command with any bit of success.

[root@rhel7 ~]# subscription-manager repos –enable rhel-7-server-openstack-6.0*
Repository ‘rhel-7-server-openstack-6.0-rpms’ is enabled for this system.
Repository ‘rhel-7-server-openstack-6.0-source-rpms’ is enabled for this system.
Repository ‘rhel-7-server-openstack-6.0-debug-rpms’ is enabled for this system.
Repository ‘rhel-7-server-openstack-6.0-installer-debug-rpms’ is enabled for this system.
Repository ‘rhel-7-server-openstack-6.0-installer-source-rpms’ is enabled for this system.
Repository ‘rhel-7-server-openstack-6.0-installer-rpms’ is enabled for this system.

Yum: Under the Covers with GPG Keys

/ Christopher Paquin

Skeleton_key_1_keychain_sculpture_photo_cut_outs-r558fef9b275d4609b522ac07970a6af6_x7sa6_8byvr_324Hey look at this spooky key. Don't be frightened little one. Nothing scary is going to happen to you here. This is a safe place. As a matter of fact, if you stick around you might just learn a thing or two. A thing or two about GPG!

First off do any of us really know what GPG stands for? Well yes we do! It stands for GNU Privacy Guard. RPM Package creators use GPG to apply a digital signature to their packages. If a package was tampered with, then its GPG signature will no longer match what was placed in the original package.

First off to check what keys you have installed on your Linux server you can run the following rpm command as show in the example below.

[root@ip-172-31-22-45 ~]# rpm -qa gpg-pubkey
gpg-pubkey-0608b895-4bd22942
gpg-pubkey-fd431d51-4ae0493b
gpg-pubkey-2fa658e0-45700c69

 

Neet I have three keys installed. But lets say want to install another one. Well I can do so with the command below. In this example I have navigated to /etc/pki/rpm-gpg and am going to install the redhat beta key on my server.

[root@ip-172-31-22-45 rpm-gpg]# rpm –import RPM-GPG-KEY-redhat-beta

Hey that was fun. Now lets get our hands a bit dirtier.

Want to get more information on a specific key. Then this command is your huckleberry. Here you can see that this is the pubkey for the EPEL repo.

[root@ip-172-31-22-45 rpm-gpg]# rpm -qi gpg-pubkey-0608b895-4bd22942
Name        : gpg-pubkey                   Relocations: (not relocatable)
Version     : 0608b895                          Vendor: (none)
Release     : 4bd22942                      Build Date: Sat 14 Jun 2014 09:13:58 AM EDT
Install Date: Sat 14 Jun 2014 09:13:58 AM EDT      Build Host: localhost
Group       : Public Keys                   Source RPM: (none)
Size        : 0                                License: pubkey
Signature   : (none)
Summary     : gpg(EPEL (6) <epel@fedoraproject.org>)
Description :

 

To verify signature of a downloaded package, use the rpm command as shown below. In this example I have highlighted the key that was used to sign this package.

# rpm -vK nautilus-dropbox-1.6.0-1.fedora.i386.rpm
nautilus-dropbox-1.6.0-1.fedora.i386.rpm:
    Header V3 RSA/SHA1 Signature, key ID 5044912e: OK
    Header SHA1 digest: OK (a4d51906633f92913db075ba33946f50999c245e)
    V3 RSA/SHA1 Signature, key ID 5044912e: OK
    MD5 digest: OK (1b8ff7abc18f68bf274e24fc57fd3a87)

 

Using the bolded information in the example above, I can then use this information to track down the exact key that was used to sign the package.

[root@localhost Downloads]# rpm -qa | grep 5044912e
gpg-pubkey-5044912e-4b7489b1

 

Is this awesome, well not really, but you never know when you might need to use this information. Like on a test. Wink Wink.

Related articles

Using Yum Update to Apply Security Patches Only
How to Enable EPEL Repository on CentOs for Yum
Signing rpm packages with GPG

RPM Package Inspection for Fun and Profit

/ Christopher Paquin

6a00d8341c562c53ef01538f8abd65970b-800wi"Whats in the box" — David Mills

Lets face it, one of your users needs to have a package installed on a system, you tend to do it for them. That is, as long as the package looks safe. Sure, your not going to install an rpm that is clearly dangerous, but as long as the package name looks reasonable and you trust the user, you might actually just go ahead an install it for them without thinking much about it. Hell, I know that I have done the exact same thing from time to time. And I have done it with an unsigned package.

"Sure you need this Oracle thing installed on this database server?"

 "You got it directly from Oracle right?"

But honestly, this is a very bad practice as you have no idea what the RPM is installing, and what its pre and post scripts might be doing to your system. Using the command below, you can inspect a packages post and pre install scripts to see if they are doing anything funny. In this instance I am taking a look at the dropbox package for my little Eeepc.

[root@localhost ~]# rpm -qp –scripts /root/Downloads/nautilus-dropbox-1.6.0-1.fedora.i386.rpm

If you have already installed a package and want to see what its pre and post install scripts did. You can run the command above using the installed package name. Note that you will drop the "P" from the command. See my sendmail example below.

[root@localhost ~]#rpm -q –scripts sendmail-8.14.8-2.fc20.i686

 

In addition to checking the pre and post scripts, you also want to check to see if the rpm has any triggers. What are triggers you ask? Well they are extensions to the normal install scripts, and they may often call for the installation of another package or the execution of a command. Just look at all the triggers that fire when you install sendmail.

[root@localhost ~]# rpm -q –triggers sendmail-8.14.8-2.fc20.i686
triggerun scriptlet (using /bin/sh) — sendmail < 8.14.5-3
/usr/bin/systemd-sysv-convert –save sendmail >/dev/null 2>&1 ||:
/bin/systemctl enable sendmail.service >/dev/null 2>&1
/bin/systemctl enable sm-client.service >/dev/null 2>&1
/sbin/chkconfig –del sendmail >/dev/null 2>&1 || :
/bin/systemctl try-restart sendmail.service >/dev/null 2>&1 || :
/bin/systemctl try-restart sm-client.service >/dev/null 2>&1 || :
# workaround for systemd rhbz#738022
/bin/systemctl is-active sendmail.service >/dev/null 2>&1 && \
        ! /bin/systemctl is-active sm-client.service >/dev/null 2>&1 && \
        /bin/systemctl start sm-client.service >/dev/null 2>&1 || :

Obviously you also want to check to see what files are actually part of a package. This can be accomplished with the query and list arguments seen below. Add the "P" argument if the rpm is not already installed. In this case I have already installed sendmail, so I exclude the "P" from the command.

 

[root@localhost ~]# rpm -ql sendmail-8.14.8-2.fc20.i686
/etc/NetworkManager/dispatcher.d/10-sendmail
/etc/mail
/etc/mail/Makefile
/etc/mail/access
/etc/mail/access.db
/etc/mail/aliasesdb-stamp
/etc/mail/domaintable
/etc/mail/domaintable.db
/etc/mail/helpfile
/etc/mail/local-host-names
..truncated…

 

So whats the moral of the story here. Well its really not that hard to take a minute and look under the covers and make sure that the packages that you are installing are not harming your systems. Is definetly worth 5 minutes of your time. Might just save your behind.

 

Related articles

RHEL6 – Simple Postfix Configuration
RHEL6 – Common Postfix Server Roles
Configure sendmail as a client for SMTPs
Sendmail Server

Quick and Dirty Yum Security Plugin Overview

/ Christopher Paquin

Maneki-neko-mountain-tummy-13745890The YUM security plugin is a package that allows you to search specifically for security patches applicable to a Redhat/Centos server.  This functionality comes in very handy when having to cross reference CVEs to Redhat Security Advisories (RHSAs). If you work closely with anyone in an information security role, you already know how vital functionality is.

Before you can begin you need to make sure that you have the plugin installed.  Use the command below to install it.

# yum -y install yum-plugin-security

 

Then you can use the plugin to get a overview of the security updates availible for your system.

# yum updateinfo
    
Updates Information Summary: available
3 Security notice(s)
         1 Important Security notice(s)
         2 Moderate Security notice(s)
12 Bugfix notice(s)
1 Enhancement notice(s)

 

You can get a specific list of updates, sorted by security advisories, bug fixes, and enhancement advisories.

# yum updateinfo list

 

To get more specific information on a RHSA and the CVEs that it applies to, you can search by RHSA as seen below.

# yum updateinfo RHSA-2014:0771

 

Need to see what patches are required to address a certain CVE, then this next command is for you. Trust me this one is useful as it gives you a list of all required packages that address that CVE.

# yum updateinfo list –cve=CVE-2013-6378
Loaded plugins: amazon-id, rhui-lb, security
RHSA-2014:0771 Important/Sec. kernel-2.6.32-431.20.3.el6.x86_64
RHSA-2014:0771 Important/Sec. kernel-firmware-2.6.32-431.20.3.el6.noarch
RHSA-2014:0771 Important/Sec. kernel-headers-2.6.32-431.20.3.el6.x86_64
RHSA-2014:0771 Important/Sec. perf-2.6.32-431.20.3.el6.x86_64

 

Want to see a list of all fixes by severity. Then you can use the command below. Note that I am using important as my severity as there are no critical updates that are applicable to my test system at this time.

yum updateinfo list –sec-severity=Important
RHSA-2014:0771 Important/Sec. kernel-2.6.32-431.20.3.el6.x86_64
RHSA-2014:0771 Important/Sec. kernel-firmware-2.6.32-431.20.3.el6.noarch
RHSA-2014:0771 Important/Sec. kernel-headers-2.6.32-431.20.3.el6.x86_64
RHSA-2014:0771 Important/Sec. perf-2.6.32-431.20.3.el6.x86_64

 

You can also search for security fixes by package name as shown below.

# yum updateinfo list kernel
RHSA-2014:0771 Important/Sec. kernel-2.6.32-431.20.3.el6.x86_64

 

You can also use YUM to apply only security related updates. See below. This is useful if you are in a pinch and need to quickly apply all security updates to make your Infosec Team happy.

# yum –security update

Related articles

Using Yum Update to Apply Security Patches Only
SCAP CVE Audit
YFD plugin updated

RHEL6 – RTFM Apache Web Server

/ Christopher Paquin / Leave a comment

King-James-BibleThere is a lot to know and remember about configuring Apache as you may or may not have seen from the numerous posts I have written on the subject, and the reality is that no one is going to be able to memorize each and every settings, configuration, and directive. Sure you can bing it or google it , you can even alta-vista it, but only if you have internet access at the time, however there is always a chance that you might get some bad information. So why not refer to the official httpd documentation. You know RTFM and what not.

By and large the best bet for HTTP documentation is the http-manual package that can be installed via yum. It installs to /var/www/manual

# yum -y install httpd-manual

Now one bit of information to note. The documentation installed via the httpd-manual package are in html format, so it not advised that you try to view it with an editor like vim or emacs.  You are going to need an text based web browser like lynx or elinks. I prefer lynx in this situtation, so lets install it.

# yum -y install lynx

Now you can peruse the documentation  as you see fit using lynx.

# lynx /var/www/manual/howto/auth.html

Below are some of the better and more often useful docs that I think that could be found useful in a crunch. Note our base directory is /var/www/manual

  • vhosts/named-based.html – which outlines configuring named-based virtual hosts
  • ssl/ssl_howto.html – which outlines has a nice section on HTTP Basic Authentication.
  • howto/cgi.html – which nicely documents creating a custom cgi directory
  • howt0/auth.html – more on HTTP Auth using htpasswd

Yup thats a lot of very good documentation right there, and its actually written by the people who wrote apache, not some 13 year old kid taking his first shot running apache on Ubuntu.

Installing Spotify on Fedora

/ Christopher Paquin / 4 Comments

Spotify-logo So Spotify is finally available in the US, which is good news for those who are getting tired of Pandora. Hell, Pandora played Celine Dion on my Hardcore Punk Radio Station the other day…wtf.

So anyway, I decided to sign up and was disappointed to find that they did not have an official linux client, However they do publicize an Ubuntu client here, however, since I run Fedora this is not much interest to me.

Thankfully the Europeans have already figured out how to get Spotify running on other linuxes natively, and google found this link on installing the Debian packages on Fedora 13. I am glad to report that these instructions also work on Fedora 12. So far so good on Fedora 12.

However i decided to explore their repo a bit and found that in fact they do have rpm packages. Check out the link below. Sneaky.

http://repository.spotify.com/fedora/

I bit more googling found me this link which contains instructions on installing via the apparently secret rpms.

Btw, if you are a jackass and want to run Spotify under Wine for some reason, click here for instructions.