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:
173echo" Starting Yum with command"174echo" /usr/bin/yum -c $TEMPCONFIGFILE -e 0 -d 1 -y update"175fi176/usr/bin/yum -c$TEMPCONFIGFILE-e0-d1-y update >$TEMPFILE2>&1177if[-s$TEMPFILE] ; then
Adjust the update commands to look like this:
173echo" Starting Yum with command"174echo" /usr/bin/yum -c $TEMPCONFIGFILE -e 0 -d 1 -y check-update"175fi176/usr/bin/yum -c$TEMPCONFIGFILE-e0-d1-y check-update >$TEMPFILE2>&1177if[-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.
is a post from: Major Hayden's blog.
Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.
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
is a post from: Major Hayden's blog.
Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.
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 (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 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: . 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 usegrub2 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: .
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.
is a post from: Major Hayden's blog.
Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.
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 .
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:
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 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 as well as .
is a post from: Major Hayden's blog.
Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.
Some might call me paranoid, but I get nervous when my package manager automatically removes a kernel. I logged into my Fedora 15 VM this morning and found this:
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
kernel x86_64 2.6.35.13-92.fc14 updates 22 M
Removing:
kernel x86_64 2.6.35.11-83.fc14 @updates 104 M
Transaction Summary
================================================================================
Install 1 Package(s)
Remove 1 Package(s)
Fedora 15's default behavior is to keep three kernels: the latest one and the two previous versions. However, this behavior may be counter-productive if you compile your own modules, or if you have compatibility issues with subsequent kernel versions.
You can change how yum handles kernel packages with some simple changes to your /etc/yum.conf. The installonly_limit option controls how many old packages are kept:
installonly_limit Number of packages listed in installonlypkgs to keep installed at the same time. Setting to 0 disables this feature. Default is '0'.
I disabled the functionality altogether by setting installonly_limit to 0:
#installonly_limit=3
installonly_limit=0
It's important to keep in mind that you will need to purge these packages from your system yourself now. Kernel packages can occupy a fair amount of disk space, so make a note to go back and clean them up when you no longer need them.
is a post from: Major Hayden's blog.
Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.
I have just written a small plugin for to ask the running agent to send an inventory when a yum operation finish.
RPM is available in the remi repository for fedora >= 12 and Enterprise Linux >= 4.
This feature is registered on upstream project : Feature #530
Installation
yum --enablerepo=remi install fusioninventory-agent-yum-pluginThis feature requires that the service run with the --rpc-trust-localhost option. An inventory will be ask after each yum transaction (install, remove, ...), See, in the /etc/sysconfig/fusioninventory-agent file...
It's not easy remembering which RPM packages contain certain files. If I asked you which files you'd find in packages like postfix-2.7.1-1.fc14 and bash-4.1.7-3.fc14, you would be able to name some obvious executables. However, would you be able to do the same if I mentioned a package like util-linux-ng-2.18-4.6.fc14? If the RPM is already installed, you can quickly use rpm -ql to list the files within it.
However, what if the RPM isn't installed already? How do you figure out which one to install?
Fedora has well over 20,000 packages in the standard repositories without adding additional repositories like RPM Fusion. Narrowing that list down to find the package you want can be daunting, but you can use yum to help.
Consider this: you're following a guide online and the author says you need to run deallocvt:
# deallocvt
-bash: deallocvt: command not found
Perhaps it's in a package with deallocvt in the name:
# yum search deallocvt
Warning: No matches found for: deallocvt
No Matches found
This is where yum's whatprovides (provides works in recent yum versions) command works really well:
# yum whatprovides */deallocvt
kbd-1.15-11.fc14.x86_64 : Tools for configuring the console
Repo : fedora
Matched from:
Filename : /usr/bin/deallocvt
From there, you can install the kbd RPM package via yum and you'll be on your way.
Author's note: Regular readers will probably think this is pretty basic, but I often find people who don't know this functionality exists in yum.
UPDATE: I forgot to include another handy command in this article (thanks to Jason Gill for reminding me). If you have file on your system already, but you need to know which RPM package it came from, you can do this very quickly:
One of the most interesting topics I've seen so far during my training at this week is . In short, SystemTap allows you to dig out a bunch of details about your running system relatively easily. It takes scripts, converts them to C, builds a kernel module, and then runs the code within your script.
HOLD IT: The steps below are definitely not meant for those who are new to Linux. Utilizing SystemTap on a production system is a bad idea — it can chew up significant resources while it runs and it can also cause a running system to kernel panic if you're not careful with the packages you install.
These instructions will work well with Fedora, CentOS and Red Hat Enterprise Linux. Luckily, the SystemTap folks put together some instructions for and as well.
Before you can start working with SystemTap on your RPM-based distribution, you'll need to get some prerequisites together:
WHOA THERE: Ensure that the kernel-devel and kernel-debuginfo* packages that you install via yum match up with your running kernel. If there's a newer kernel available from your yum repo, yum will pull that one. If it's been a while since you updated, you'll either need to upgrade your current kernel to the latest and reboot or you'll need to hunt down the corresponding kernel-devel and kernel-debuginfo* packages from a repository. Installing the wrong package version can lead to kernel panics. Also, bear in mind that the debuginfo packages are quite large: almost 200MB in Red Hat/CentOS and almost 300MB in Fedora.
You can't write the script in just any language. SystemTap uses an odd syntax to get things going:
The iotime.stp script dumps out the reads and writes occurring on the system in real time. After starting the script above, I accessed my cacti instance on the server and immediately started seeing some reads as apache began picking up PHP files to parse.
Consider a situation in which you need to decrease interrupts on a Linux machine. This is vital for laptops and systems that need to remain in low power states. Some might suggest powertop
On this particular system, it's pretty obvious that the ethernet interface is causing a lot of interrupts.
If you want more examples, keep hunting around in the systemtap-testsuite package (remember rpm -ql systemtap-testsuite) or review the on SystemTap's site.
Thanks again to Phil Hopkins at Rackspace for giving us a detailed explanation of system profiling during training.
If you need to replace old sysklogd with recent rsyslog on centos, `rpm -e --nodeps sysklogd` is rather kludgy as yum will remove initscripts, upon which most of the system is dependent on. However, it is possible to install and remove via the yum shell in one go, which resolves the dependency issues.