Red Hat

While taking a Red Hat Training course the instructor showed us a Yum plugin called verify. I’ve never used any of the Yum plugins before and after a while of playing with Yum Verify, I have decided that I should share this very cool plugin and introduce others to Yum plugins.
What are Yum Plugins Yum plugins are packages that can be installed to provide extra functionality to the Yellowdog Update Manager or yum.

Recently I was working on an issue where an application was not retaining the umask setting set in the root users profile or /etc/profile. After looking into the issue a bit it seemed that the application in question only applied the umask setting that was set in /etc/bashrc and would not even accept the values being the applications own start scripts.
After doing a bit of researched I learned a little bit more about what exactly these files do, the differences between them and when they are executed.

When supporting systems you have inherited or in environments that have many different OS versions and distributions of Linux. There are times when you simply don’t know off hand what OS version or distribution the server you are logged into is.
Luckily there is a simple way to figure that out.
Ubuntu/Debian $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=13.04 DISTRIB_CODENAME=raring DISTRIB_DESCRIPTION="Ubuntu 13.04" RedHat/CentOS/Oracle Linux # cat /etc/redhat-release Red Hat Enterprise Linux Server release 5 (Tikanga) Catchall If you are looking for a quick way and don’t care what the output looks like, you can simply do this as well.

Recently while working on a system that uses EMC PowerPath, I ran into a little issue after rebooting.
The Issue fsck.ext3: No such file or directory while trying to open /dev/emcpowera1 /dev/emcpowera1: The superblock could not be read or does not describe a correct ext2 filesystem. The Cause The root cause of this issue is pretty simple when a Linux system boots it performs file system checks on file systems listed within the /etc/fstab file.

Adding static routes in Linux can be troublesome, but also absolutely necessary depending on your network configuration. I call static routes troublesome because they can often be the cause of long troubleshooting sessions wondering why one server can’t connect to another.
This is especially true when dealing with teams that may not fully understand or know the remote servers IP configuration.
The Default Route Linux, like any other OS has a routing table that determines what is the next hop for every packet.

When it comes to package management on Red Hat based systems Yum (Yellowdog Updater, Modified) is my preferred method. It’s a quick and easy way of installing desired rpm’s and their dependencies as Yum will automatically resolve dependencies before installation.
Most Red Hat base distributions include a public facing Yum repository that you can configure yum to use in order to save from having to maintain a local copy of every package on each system.

Since I’ve mostly been using Red Hat or the gui desktop of Ubuntu lately I’ve neglected to notice the transitions from the sysVinit packages to systemd. Recently I installed Fedora 16 and was a little surprised when chkconfig didn’t work anymore. I decided I would write a post that gives the systemctl version of a few common chkconfig commands.
List processes chkconfig:

chkconfig –list systemd:

systemctl list-units Enable a service chkconfig:

Cron is a time based scheduled task daemon that runs on most common Unix/Linux distributions. Because cronjobs are time based sometimes it is necessary to validate that the job ran at the scheduled time. Sometimes people will configure a cron to send the output of the script to a user via system mail or redirect the output to a file; however not all crons are setup the same and many times they may be configured to send output to /dev/null hindering any ability to validate the job ran.