You are viewing illiterat

James Antill - A few things you might not know about RHEL-6.1+ yum

May. 19th, 2011

02:02 pm - A few things you might not know about RHEL-6.1+ yum

Previous Entry Share Next Entry

Time to look at a few features of yum in RHEL-6.1 now that it's released

  • Search is more userfriendly

    As we maintain yum we are always looking for the "minor" changes that can make a big difference to the user, and this is probably one of the biggest minor changes. As of late RHEL-5 and RHEL-6.0 "yum search" was great for finding obscure things that you knew something about but with 6.1 we've hopefully made it useful for finding the "everyday" packages you can't remember the exact name of. We did this by excluding a lot of the "extra" hits, when you get a large search result. For instance "yum search kvm manager" is pretty useless in RHEL-6.0, but in RHEL-6.1 you should find what you want very quickly.

    Example commands:
    yum search kvm manager
    yum search python url
    
  • The updateinfo command

    The "yum-security" or "yum-plugin-security" package has been around since early RHEL-5, but the RHEL-6.1 update has introduced the "updateinfo" command to make things a little easier to use, and you can now easily view installed security errata (to more easily make sure you are secure). We've also added a few new pieces of data to the RHEL updateinfo data. Probably the most significant is that as well as errata being marked "security" or not they are now tagged with their "severity". So you can automatically apply only "critical" security updates, for example.

    Example commands:
    yum updateinfo list security all
    yum update-minimal --sec-severity=critical
    
  • The versionlock command

    As with the previous point we've had "yum-plugin-version" for a long time, but now we've made it easier to use and put all it's functions under a single "versionlock" sub-command. You can now also "exclude" specific versions you don't want, instead of locking to known good specific ones you had tested.

    Example commands:
    # Lock to the version of yum currently installed.
    yum versionlock add yum
    # Opposite, disallow versions of yum currently available:
    yum versionlock exclude yum
    
    yum versionlock list
    yum versionlock delete yum\*
    yum versionlock clear
    
    # This will show how many "excluded" packages are in each repo.
    yum repolist -x .
    
  • Manage your own .repo variables

    This is actually available in RHEL-6.0, but given that almost nobody knows about it I thought I'd share it here. You can put files in "/etc/yum/vars" and then use the names of those files are variables in any yum configuration, just like $basearch or $releasever. There is also a special $uuid variable, so you can track individual machines if you want to.

  • yum has it's own DB

    Again, this something that was there in RHEL-6.0 but has improved (and is likely to improve more over time). The most noticeable addition is that we now store the "installed_by" and "changed_by" attributes, this could be worked out from "yum history" before, but now it's easily available directly from the installed package.

    Example commands:
    yumdb
    yumdb info yum
    yumdb set installonly keep kernel-2.6.32-71.7.1.el6
    yumdb sync
    
  • Additional data in "yum history"

    Again, this something that was there in RHEL-6.0 but has improved (and is likely to improve more over time). The most noticeable additions are that we now store the command line and we store a "transaction file" that you can use on other machines.

    Example commands:
    yum history
    yum history pkgs yum
    yum history summary
    
    yum history undo last
    
    yum history addon-info 1    config-main
    yum history addon-info last saved_tx
    
  • "yum install" is now fully kickstart compatible

    As of RHEL-6.0 there was one thing you could do in a kickstart package list that you couldn't do in "yum install" and that was to "remove" packages with "-package". As of the RHEL-6.1 yum you can do that, and we also added that functionality to upgrade/downgrade/remove. Apart from anything else, this should make it very easy to turn the kickstart package list into "yum shell" files (which can even be run in kickstart's %post).

    Example commands:
     yum install 'config(postfix) >= 2.7.0'
     yum install MTA
     yum install '/usr/kerberos/sbin/*'
     yum -- install @books -javanotes
    
  • Easier to change yum configuration

    We tended to get a lot of feature requests for a plugin to add a command line option so the user could change a single yum.conf variable, and we had to evaluate those requests for general distribution based on how much we thought all users would want/need them. With the RHEL-6.1 yum we created the --setopt so that any option can be changed easily, without having to create a specific bit of code. There were also some updates to the yum-config-manager command.

    Example commands:
    yum --setopt=alwaysprompt=false upgrade yum
    
    yum-config-manager
    yum-config-manager --enable myrepo
    yum-config-manager --add-repo https://example.com/myrepo.repo
    
  • Working towards managing 10 machines easily

    yum is the best way to manage a single machine, but it isn't quite as good at managing 10 identical machines. While the RHEL-6.1 yum still isn't great at this, we've made a few improvements that should help significantly. The biggest is probably the "load-ts" command, and the infrastructure around it, which allows you to easily create a transaction on one machine, test it, and then "deploy" it to a number of other machines. This is done with checking on the yum side that the machines started from the same place (via. rpmdb versions), so that you know you are doing the same operation.

    Also worth noting is that we have added a plugin hook to the "package verify" operation, allowing things like "puppet" to hook into the verification process. A prototype of what that should allow those kinds of tools to do was written by Seth Vidal here.

    Example commands:
    # Find the current rpmdb version for this machine (available in RHEL-6.0)
    yum version nogroups
    
    # Completely re-image a machine, or dump it's "package image"
    yum-debug-dump
    yum-debug-restore 
        --install-latest
        --ignore-arch
        --filter-types=install,remove,update,downgrade
    
    # This is the easiest way to get a transaction file without modifying the rpmdb
    echo | yum update blah
    ls ${TMPDIR:-/tmp}/yum_save_tx-* | sort | tail -1
    
    # You can now load a transaction and/or see the previous transaction from the history
    yum load-ts /tmp/yum_save_tx-2011-01-17-01-00ToIFXK.yumtx
    yum -q history addon-info last saved_tx > my-yum-saved-tx.yumtx
    

Comments:

[User Picture]
From:thargol
Date:May 19th, 2011 08:59 pm (UTC)
(Link)
It would be nice if you could restore "yum provides" to its previous working state. If I say "yum provides foo", it's because I want to know which package provides file foo. If there happens to be a feature called foo, then by all means show packages that provide that as well. But don't force me to do "yum provides */foo" just because I happen to know I'm looking for a file. I suppose I really should log that as a bug. But then again, 99% of my bug reports are ignored anyway, so I'm losing faith in that approach somewhat.
[User Picture]
From:illiterat
Date:May 20th, 2011 07:18 pm (UTC)

provides == fileprovides?

(Link)
If I say "yum provides foo", it's because I want to know which package provides file foo.

The problem is twofold: 1) From what I've seen that is the (much) less common usage. 2) If you assume people want to check for files by default, you need to load the "filelists" data from all repos. ... which means that everybody who doesn't want to do that (Eg. most people) will then shout at me for wasting their time/bandwidth/etc.

I'd thought about doing some "primary-file-lookup" type command, mainly for command lookup (where you don't need filelists) but that could be extended ... what files do you lookup frequently?

[User Picture]
From:thargol
Date:May 23rd, 2011 11:07 am (UTC)

Re: provides == fileprovides?

(Link)
From what I've seen that is the (much) less common usage

I guess we're just exposed to different demographics then, because I've never seen anyone use it for anything else, myself included.

what files do you lookup frequently?

So a typical example would be pulling a repo for a new project at work. To give a real life example from last week, trying to run the app in question gave the following python error:
ImportError: No module named matplotlib
So I ran yum provides "*/matplotlib" to find out which package I need to install. But in general, any app that fails to find a file for any particular reason tends to push me in the direction of yum provides, whether it's a missing shared object or a config or similar file that something looks for at run time. Is it something I use every day? No, not even close, but I'd say once every few weeks, which makes the */foo an annoyance when foo used to work just fine. I'd be happier with yum fileprovides than the current wildcard hack as a means to tell yum that I really am looking for a file, so it needs to load filelists.
[User Picture]
From:illiterat
Date:May 24th, 2011 05:05 pm (UTC)

Re: provides == fileprovides?

(Link)
I guess we're just exposed to different demographics then, because I've never seen anyone use it for anything else, myself included.
Fair enough.
So I ran yum provides "*/matplotlib" to find out which package I need to install. But in general, any app that fails to find a file for any particular reason tends to push me in the direction of yum provides, whether it's a missing shared object or a config or similar file that something looks for at run time.
So I just added: http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=6756b86f33f5173a035671ae748f61a1192eef1a ...which looks for "commands" and python modules, if the "normal" provides lookup fails. This is fast enough, I doubt anyone will care (although it might trigger filelists downloads). Adding more sources is possible (Eg. /etc), if you have a need for them (and we can do it easily -- adding "perl"/"ruby"/etc. might be useful, but I'm not sure how easy it would be). Worst case we could even have a configurable list of directories.
From:(Anonymous)
Date:June 8th, 2011 10:48 pm (UTC)

Re: provides == fileprovides?

(Link)
A two-fold search is definitely the cleanest way to go!

Great job!
Looking forward to it!

[User Picture]
From:niqdanger
Date:May 20th, 2011 01:29 pm (UTC)
(Link)
Great work, looking forward to updating everything to the 6x series.
From:(Anonymous)
Date:December 19th, 2011 06:37 pm (UTC)

Thanks for the work on yum

(Link)
Is yum perfect? Obviously not; nothing is. But doggone it, it sure has made sysadmin of RPM-based boxes a lot easier than before we had yum (or yup, its predecessor). Thanks to yum, I made a little bash/Expect script that logs into all my boxes and does the updates, all automagically, and reboots the box if necessary, i. e. if there's a kernel or glibc update.

Thanks for your continued work on this tool.