Tag Archives: yum

Sep 21 2012
6 Comments
Blog Posts

Automatic package updates in CentOS 6

Automating package updates in CentOS 6 is a quick process and it ensures that your system receives the latest available security patches, bugfixes and enhancements. Although it’s easy and available right from yum on a normal CentOS 6 system, I still find that many people aren’t aware of it.

Before you enable automatic updates, you’ll want to ensure that you’re excluding certain packages which may be integral to your system. You can either make a list of those packages now or configure the automated updates so that you’re emailed a report of what needs to be installed rather than having those packages installed automatically.

To get started, install yum-cron:

yum -y install <code>yum-cron</code>

By default, it’s configured to download all of the available updates and apply them immediately after downloading. Reports will be emailed to the root user on the system. To change these settings, just open /etc/sysconfig/yum-cron in your favorite text editor and adjust these lines:

# Default - check for updates, download, and apply
CHECK_ONLY=no
DOWNLOAD_ONLY=no
 
# Download the updates and email a report
CHECK_ONLY=no
DOWNLOAD_ONLY=yes
 
# Don't download the updates, just email a report
CHECK_ONLY=yes
DOWNLOAD_ONLY=no

As mentioned earlier, if you want to exclude certain packages from these updates, just edit your /etc/yum.conf and add:

exclude=kernel* mysql*

The cron jobs from the yum-cron package are active immediately after installing the package and there’s no extra configuration necessary. The job will be run when your normal daily cron jobs are set to run.

Tagged , , ,
Feb 04 2012
Leave a comment
Blog Posts

Get notifications instead of automatic updates in Scientific Linux

Scientific Linux installations have a package called yum-autoupdate by default and the package contains two files:

# rpm -ql yum-autoupdate
/etc/cron.daily/yum-autoupdate
/etc/sysconfig/yum-autoupdate

The cron job contains the entire script to run automatic updates once a day and the configuration file controls its behavior. However, you can’t get the same functionality as Fedora’s yum-updatesd package where you can receive notifications for updates rather than automatically updating the packages.

To get those notifications in Scientific Linux, just make two small edits to this portion of /etc/cron.daily/yum-autoupdate:

173           echo "    Starting Yum with command"
174           echo "     /usr/bin/yum -c $TEMPCONFIGFILE -e 0 -d 1 -y update"         
175   fi
176   /usr/bin/yum -c $TEMPCONFIGFILE -e 0 -d 1 -y update > $TEMPFILE 2>&1
177   if [ -s $TEMPFILE ] ; then

Adjust the update commands to look like this:

173           echo "    Starting Yum with command"
174           echo "     /usr/bin/yum -c $TEMPCONFIGFILE -e 0 -d 1 -y check-update"         
175   fi
176   /usr/bin/yum -c $TEMPCONFIGFILE -e 0 -d 1 -y check-update > $TEMPFILE 2>&1
177   if [ -s $TEMPFILE ] ; then

Since you won’t be auto-updating with this script any longer, you may want to comment out the EXCLUDE= line in /etc/sysconfig/yum-autoupdate so that you’ll receive notifications for all packages with updates. Also, to avoid having your changes updated with a newer yum-autoupdate package later, add the package to your list of excluded packages in /etc/yum.conf.

Tagged , , ,
Nov 23 2011
1 Comment
Blog Posts

Automatically upgrading to new point releases of Scientific Linux

When you install Scientific Linux, it will keep you on the same point release that you installed. For example, if you install it from a 6.0 DVD, you’ll stay on 6.0 and get security releases for that point release only.

Getting it to behave like Red Hat Enterprise Linux and CentOS is a painless process. Just install the sl6x repository with yum:

yum install yum-conf-sl6x

Check to ensure that you’re getting updates from the new repository:

# yum repolist
repo id            repo name                                              status
sl                 Scientific Linux 6.1 - x86_64                          6,251
sl-security        Scientific Linux 6.1 - x86_64 - security updates         548
sl6x               Scientific Linux 6x - x86_64                           6,251
sl6x-security      Scientific Linux 6x - x86_64 - security updates          548
repolist: 13,598
Tagged , , , ,
Nov 14 2011
1 Comment
Blog Posts

Live upgrade Fedora 15 to Fedora 16 using yum

Before we get started, I really ought to drop this here:

Upgrading Fedora via yum is not the recommended method. Your first choice for upgrading Fedora should be to use preupgrade. Seriously.

This begs the question: When should you use another method to upgrade Fedora? What other methods are there?

You have a few other methods to get the upgrade done:

  • Toss in a CD or DVD: You can upgrade via the anaconda installer provided on the CD, DVD or netinstall media. My experiences with this method for Fedora (as well as CentOS, Scientific Linux, and Red Hat) haven’t been too positive, but your results may vary.
  • Download the newer release’s fedora-release RPM, install it with rpm, and yum upgrade: This is the really old way of doing things. Don’t try this (read the next bullet).
  • Use yum‘s distro-sync functionality: If you can’t go the preupgrade route, I’d recommend giving this a try. However, leave plenty of time to fix small glitches after it’s done (and after your first reboot).

Personal anecdote time (Keep scrolling for the meat and potatoes)
I have a dedicated server at Joe’s Datacenter (love those folks) with IPMI and KVM-over-LAN access. The preupgrade method won’t work for me because my /boot partition is on a software RAID volume. There’s a rat’s nest of a Bugzilla ticket over on Red Hat’s site about this problem. I’m really only left with a live upgrade using yum.

Live yum upgrade process
Before even beginning the upgrade, I double-checked that I’d applied all of the available updates for my server. Once that was done, I realized I was one kernel revision behind and I rebooted to ensure I was in the latest Fedora 15 kernel.

A good practice here is to run package-cleanup --orphans (it’s in the yum-utils package) to find any packages which don’t exist on any Fedora mirrors. In my case, I had two old kernels and a JungleDisk package. I removed the two old kernels (probably wasn’t necessary) and left JungleDisk alone (it worked fine after the upgrade). If you have any external repositories, such as Livna or RPMForge, you may want to disable those until the upgrade is done. Should the initial upgrade checks bomb out, try adding as few repositories back in as possible to see if it clears up the problem.

Once you make it this far, just follow the instructions available in Fedora’s documentation: Upgrading Fedora using yum. I set SELinux to permissive mode during the upgrade just in case it caused problems.

I’d recommend skipping the grub2-install portion since your original grub installation will still be present after the upgrade. If your server has EFI (not BIOS), don’t use grub2 yet. Keep an eye on the previously mentioned documentation page to see if the problems get ironed out between grub2 and EFI.

Before you reboot, be sure to get a list of your active processes and daemons. After your reboot, some old SysVinit scripts will be converted into Systemd service scripts. They might not start automatically and you might need to enable and/or start some services.

New to Systemd? This will be an extremely handy resource: SysVinit to Systemd Cheatsheet.

I haven’t seen too many issues after cleaning up some daemons that didn’t start properly. There is a problem between asterisk and SELinux that I haven’t nailed down yet but it’s not a showstopper.

Good luck during your upgrades. Keep in mind that Fedora 15 could be EOL’d as early as May or June 20102 when Fedora 17 is released.

Tagged , , , , , , , , ,
Sep 15 2011
3 Comments
Blog Posts

Receive e-mail reports for SELinux AVC denials

SELinux isn’t a technology that’s easy to tackle for newcomers. However, there’s been a lot of work to smooth out the rough edges while still keeping a tight grip on what applications and users are allowed to do on a Linux system. One of the biggest efforts has been around setroubleshoot.

The purpose behind setroubleshoot is to let users know when access has been denied, help them resolve it if necessary, and to reduce overall frustration while working through tight security restrictions in the default SELinux policies. The GUI frontend for setroubleshoot is great for users who run Linux desktops or those who run servers with a display attached. Don’t worry, you can configure setroubleshoot on remote servers to send alerts elsewhere when a GUI alert isn’t an option.

Install a few packages to get started:

yum install setroubleshoot{-server,-plugins,-doc}

Open /etc/setroubleshoot/setroubleshoot.conf in your favorite text editor and adjust the [email] section to fit your server:

recipients_filepath = /var/lib/setroubleshoot/email_alert_recipients
smtp_port = 25
smtp_host = localhost
from_address = selinux@myserver.com
subject = [MyServer] SELinux AVC Alert

You could probably see it coming, but you need to put the e-mail addresses for your recipients into /var/lib/setroubleshoot/email_alert_recipients:

echo "selinux@mycompany.com" >> /var/lib/setroubleshoot/email_alert_recipients

You’ll notice that setroubleshoot doesn’t have an init script and it doesn’t exist in systemd in Fedora 15. It runs through the dbus-daemon and a quick bounce of the messagebus via its init script brings in the necessary components to run setroubleshoot:

service messagebus restart

A really easy (and safe) test is to ask sshd to bind to a non-standard port. Simply define an additional port on in your /etc/ssh/sshd_config like this:

Port 22
Port 222

When you restart sshd, it will bind to port 22 with success, but it won’t be allowed to bind to port 222 (since that’s blocked by SELinux as a non-standard port for the ssh_port_t port type). DON’T WORRY! Your sshd server will still be listening on port 22. If you wait a moment, you’ll get an e-mail (perhaps two) that not only notify you of the denial, but they make suggestions for how to fix it:

SELinux is preventing /usr/sbin/sshd from name_bind access on the tcp_socket port 222.
 
*****  Plugin bind_ports (99.5 confidence) suggests  *************************
 
If you want to allow /usr/sbin/sshd to bind to network port 222
Then you need to modify the port type.
Do
# semanage port -a -t PORT_TYPE -p tcp 222
   where PORT_TYPE is one of the following: ...

For this particular example, the quick fix would be to run:

semanage port -a -t ssh_port_t -p tcp 222

Much of this post’s information was gathered from the detailed documentation on Fedora’s setroubleshoot User’s FAQ as well as Dan Walsh’s setroubleshoot blog post.

Tagged , , , , , , , , , , , ,
← Older posts