Staying Current with Your Distribution's Security Updates
One of the key elements of making and keeping Linux a prime-time player in your desktop or server environment is ensuring that it is current with security patches. You take measures to address security at the network and hardware levels, but it takes only one security hole to compromise your entire environment. All users, whether they are commercial, nonprofit or home users, must know how to update their systems and applications, and they must do so regularly.
Two steps are key to keeping your system clean: knowing when to update and actually performing the updates. The first can be solved by monitoring security bulletin mailing lists for your specific distribution. The second can be solved in numerous ways through graphical and command-line tools. Some distributions also include auto-upgrading software utilities that can help you monitor your system.
I admit that I use the terms update and upgrade interchangeably when referring to moving from one version of a software package to another. These essentially mean the same thing. You also want to be careful when updating software so you do not install a version of a package you did not intend to. Development versions of packages usually carry a different version series. If the version differs by too much, check for a different update.
This article investigates both command-line and GUI tools for keeping your Linux system up to date. We specifically look at Debian 3.0 (Woody), Mandrake 10.0, SuSE 9.1 and Fedora Core 2.
So how do you know when you should update? One good method is to subscribe to the security bulletins that your distribution provides. The on-line Resources provide URLs for the distributions covered in this article here and their respective security mailing lists. These usually are low-traffic mailing lists to alert you of security-related patches or updates. They also usually provide direct links for downloading the updated packages and MD5 sums to ensure you have a clean package. You manually can install a package this way. You also might need to grab any dependencies, if necessary.
Another method for knowing when to update is to use a script or application that polls for any updates. SuSE 9.1 and Fedora Core 2 include easy methods for automatically updating your current software with GUI tools. Debian and Mandrake also both have easy GUI tools and can be scripted to download packages in the middle of the night, letting you upgrade later.
I must offer a word of caution on upgrading software when no one is present to monitor the process. For instance, I heavily configure the Apache Web server. When I upgrade, it always asks me if I want to replace my config files. I usually run diff to see what the changes will do, but I rarely let them overwrite my config file. Make sure you note any changes in the software versions that are upgrading if you have any critical applications. Always back up your critical application config files.
The RPM command-line tool is a manual and dependable method for upgrading your RPM security update. The rpm command has a lot of switches for various options, but for upgrading packages, you should run:
# rpm -Uv package.rpm
For the RPM file, you can specify a local filename, or even an FTP or HTTP location. If your security mailing list includes direct URLs for package updates, command-line updating is very simple. For more information on the rpm command-line tool, check out the RPM Web site or the man page.
Debian and other Debian-based distributions use dpkg as their package management system. It used to stand for Debian GNU/Linux package manager. The dpkg FAQ page states that it no longer stands for anything, because it is used in non-Debian and non-Linux environments. This package manager does the mid-level work for APT, the Advanced Packaging Tool, and GUI tools such as Synaptic. Much like RPM, dpkg includes a plethora of command-line switches, but we focus on the simple upgrade switch:
# dpkg -i package.deb
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!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space