Staying Current without Going Insane
Before I talk about automatic update tools, let's talk about different kinds of systems for a moment. A bastion host connected to the Internet has a much more compelling need for the immediate application of security updates than a desktop system behind a firewall. Use common sense in deciding on which systems you're going to expend the necessary time and effort to keep strictly current, and for which systems you're willing to sustain a little risk by not being as painstaking.
Another thing to consider with regard to systems' roles is which hosts you can comfortably run an X-based update tool on such as YaST2. Bastion hosts (publicly accessible ones) shouldn't run X, generally speaking. If you really like YaST2's ease of use and overall convenience, run it in an internal system, configure it to save updates and push those updates out to your bastion hosts via scp.
Starting with Red Hat 6.2, you can use up2date to identify, download and install updated packages automatically. up2date runs in either text or X mode, so the “where may I run it?” conundrum described above doesn't really apply.
Before you can run up2date, you need to configure it. Luckily, there are two convenient and simple tools to do this. First, you need to use rhn_register to create an account on the Red Hat Network (RHN). If invoked without arguments, rhn_register runs in X mode, but you can run it in text mode by passing it the --nox flag:
bash-# rhn_register --nox
You can register one system with RHN for free, but subsequent systems registered to the same account require a fee. RHN registration is necessary for every host on which you wish to run up2date. There's nothing to stop you, however, from running up2date on one machine, saving the updated packages and pushing them to your other Red Hat systems, via scp or some other secure means, and installing them on those systems manually.
Another thing you need to know about RHN is that by default, a system registered with RHN will send RHN information about its network configuration and hardware, plus a complete list of all installed packages and their versions. This allows you to schedule automated updates to be sent from RHN to you and/or for customized e-mails to be sent to you whenever an update is available for packages installed on your system.
Those two RHN features may be very appealing to you, and if either makes the difference between your performing regular security updates, I for one won't criticize you. However, I personally am uncomfortable providing detailed lists of my system's setup to strangers without needing to. It isn't that I have any specific reason not to trust the fine professionals at Red Hat Network; it's just that I'd rather not have to trust them.
After all, it's really no big deal to me to subscribe to the Redhat-Watch-list, which Red Hat uses to announce new updates (listman.redhat.com), and to decide for myself whether it's necessary to run up2date. If it is necessary, up2date will automatically determine which updates are applicable to my system even if I haven't stored any system information at Red Hat. Therefore, my own practice (and recommendation) is to deselect the rhn_register options “Include information about hardware and network” and “Include RPM packages installed on this system in my System Profile”.
After you've registered your system with the Red Hat Network, you need to run up2date-config (Figure 1). Like rhn_register, this command supports the --nox flag if you wish to run it in text mode. up2date-config is for the most part self-explanatory, but several settings are worth mentioning.
First, if you're going to download, store and distribute updates from a central system as described above, you'll want to select the option “After installation, keep binary packages on disk”, and specify (or at least note) the default value of “Package storage directory:”. If you run rhn_register with the --nox flag, these options are instead labeled keepAfterInstall and storageDir, respectively.
Second, be sure not to deselect the option “Use GPG to verify package integrity” (it's selected by default) unless your system is very slow. One of the niftier features of the RPM package format is its support of internal GPG signatures that can be used to verify the integrity of the RPM. up2date can do this automatically for you, provided GnuPG is installed on your system. If it is, you can also verify an RPM package's GPG signature manually like this:
rpm --checksig /path/packagefilename.rpm
where, naturally, you should replace /path/packagefilename.rpm with the full path of the RPM file you wish to check.
Sooner or later somebody will crack a Red Hat mirror site and replace some essential package with a trojaned version; when that happens, those of us who routinely check for valid RPM signatures will be far less likely to be stung.
Once you've registered with RHN and run up2date-config, you can run up2date itself (Figure 2). There's not a lot to say about this; the whole point of up2date is simplicity and convenience, so you don't need me to tell you how to click its clearly labeled buttons.
I will repeat, however, my earlier advice: sign up for the Redhat-Watch-list and run up2date whenever an update is announced that is applicable to your system. By using such a slick and user-friendly tool, you have little excuse not to.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
- SourceClear Open
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide