Archive

Posts Tagged ‘CentOS’

Finding Files and Binaries on Linux and UNIX

January 8th, 2010 Christer 1 comment

I manage a number of different types of systems. I have an Arch Linux laptop, a Macbook installed with OS X, CentOS and RHEL machines at work, as well as Debian servers both at work and home. As if that weren’t enough I also maintain a few FreeBSD servers. Between all of these different Operating Systems and variants I find that certain files and commands aren’t always where I might expect them to be. For today’s article I’ve outlined different methods for finding files and binaries on Linux and UNIX systems.

Locate

The first tool I’ll share is the locate command. This command searches through an index, built-daily, of all files and folders on your machine. Locate should be available on all standard UNIX systems, and is generally a very fast way to search for files.

  • Positives: fast
  • Negatives: not very specific, index updated daily

If you need to re-build your index to include recently added files, you can run the command:

updatedb

Find

The find command is much, much more granular than the locate command but it can also be more complicated to use. Explaining all of its options would warrant a post of its own, so I’ll just outline a few basic uses.

  • Positives: very, very granular search parameters
  • Negatives: slower than other methods

To use the find command, refer to one of these examples:

find / -type f -iname "httpd.conf"
find . -type f -name ".bashrc"
find /etc/ -type f -name "hosts.*"
find /usr/local/ -type d -iname "www"

These examples are all very similar, with only slight variations, to give you an idea of some of the power of find. Again, find can do much more than this, but this is enough to get you started.

  • The first command searches from the root directory for any files (-type f) for the case-insensitive string of “httpd.conf”.
  • The second command searches the current working directory for any files with the case-sensitive name of “.bashrc”.
  • The third command searches within the /etc/ directory (and subdirectories) for any files matching the name “hosts.*”
  • The last command searches within the /usr/local/ directory for any directories (-type d) with the case-insensitive name of “www”.

As you can see, find can be very flexible and this only touches on the advanced search patterns it can define. I highly suggest you have a look at the find man page for more information!

Which

The which command searches for binary files within your PATH. For example, let’s say you need to know the full path to the wget command. You could use:

which wget

You should see something along the lines of:

/usr/bin/wget

Binaries may be stored in different places on different systems, which is again why it is important to know how to find them. I use which frequently within my scripting in an attempt to make scripts portable. Let me give you an example:

#!/bin/bash
if [ -x $(which wget) ]; then
$(which wget) http://example.com/file.txt
fi

This very simply script doesn’t make any assumptions about the availability or the location of the wget tool. It does a simple check to see if the binary, as defined by its full path, is executable and if so use it to download a file. If wget does not exist the script will do nothing, and if it does exist it will be sure to execute it by its full path.

This tool has been helpful when moving between operating systems and variants. It helps me ensure I know exactly where files are, and not make any assumptions.

Whereis

The whereis tool is similar to the locate tool in that it is not as granular as find, and it is also similar to the which tool in that it searches only a predefined PATH for files. I use whereis constantly on my FreeBSD systems to search for ports within the ports tree. An example:

whereis portmaster

This would give me the output (assuming it is installed), of:

portmaster: /usr/local/sbin/portmaster /usr/local/man/man8/portmaster.8.gz /usr/ports/ports-mgmt/portmaster

This searches the standard binary, manual page, and source directories. As you can see from the above output, I have a result from each. This tells me where the binary is in its full path, where the man page(s) is stored as well as within the ports tree. If I didn’t have it installed, the only result I would be given would be the ports tree entry. This would help me find the path, allowing me to install it.

Conclusion

All of these tools are standard UNIX binaries that you should find on any system. Each tool has its own strengths and weaknesses, and none of them will always do the job the right way. I find myself using each of these on a regular basis, each for its own strengths. I would invite you to start using these commands in your day-to-day as needed, and read more about them.

How to solve cron error: “ERROR: failed to open PAM security session: Success”

January 6th, 2010 Christer No comments

Today I ran into a problem at work that I thought would be worth sharing. It is one of those odd only-happens-once-in-a-blue-moon errors, so writing it down and putting it out there on the internet may help those lucky few who run into it.

The Situation

I had a report from a user that the system account he and his team share was unable to run cron jobs. My initial checklist of things to verify were:

  • Verify the syntax of the cronjob(s) by viewing the crontab: crontab -u <username> -l
  • Verify user was listed in /etc/cron.allow, or *not* listed in /etc/cron.deny.
  • Check the /var/log/cron for informational messages.

The cron syntax looked fine–I didn’t see any errors. I also verified that they were listed in the cron.allow file. (Our systems implement a cron.allow policy, for security.). From the crontab man page:

If the cron.allow file exists, then you must be listed therein in order to be allowed to use this command. If the cron.allow file exists, then you must be listed therein in order to be allowed to use this command.

It was the third entry, the system log, that alerted me to the problem.

Jan 5 10:26:01 hostname crond[21536]: User account has expired
Jan 5 10:26:01 hostname crond[21536]: CRON (username) ERROR: failed to open PAM security session: Success
Jan 5 10:26:01 hostname crond[21536]: CRON (username) ERROR: cannot set security context

The key piece of information here is “User account has expired.” While the shared system account was still usable–it doesn’t require a password–it had technically expired which meant cron would restrict its jobs. Remember, 99% of the time the system log tells you exactly what the problem is. The key is reading!

[ad#Google Adsense]

The Solution

The solution was to unexpire the system account. To do so you can use the chage command or the passwd command. In this situation, because this is a shared system account that does not need to expire, I set it to never expire:

passwd -x -1 username

From the passwd man page:

This will set the maximum password lifetime,  in  days,  if  the user’s  account  supports password lifetimes.  Available to root only. This will set the maximum password lifetime,  in  days,  if  the user’s  account  supports password lifetimes.  Available to root only.

As you might guess, -1 sets an infinite value meaning it will never expire.

Categories: CentOS Tags: , , , ,

Configure EPEL Repository : CentOS 5.x

January 1st, 2010 Christer No comments

This article will outline how to install the EPEL (Extra Packages for Enterprise Linux) repository for your CentOS 5.x server or desktop. This is one of the few third-party repositories that I trust, and provides a great number of newer and otherwise unavailable packages to your CentOS installation.

Installation

To install and activate the EPEL repository on your system, run the following command with administrator privileges:

rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm

After this command is successful you’ll find that you have two new files in your yum configuration directory, /etc/yum.repos.d/.

  • epel.repo
  • epel-testing.repo

The testing repository is disabled by default, but the core epel repository should be active.

Installing Packages

I include EPEL on all of my CentOS installations and use it to install a number of otherwise unavailable packages. Some of my preferred EPEL packages are:

  • htop
  • lighttpd
  • bzr
  • git
  • puppet
  • cobbler

To install these, or any other EPEL package, simply use yum as you normally would. For example:

yum install htop

Conclusion

EPEL has been a great addition to the core CentOS repositories, providing trusted packages to the available list of software. Where others may revert to using community (un)maintained repositories, EPEL packages are often maintained by Red Hat employees and are extensively tested to comply with RHEL, CentOS and Fedora systems.

Categories: CentOS Tags: , , , , , , ,