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

January 6th, 2010 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: , , , ,

The Simplest DVD Ripper for Mac!

January 5th, 2010 No comments

My wife and I are movie fans. For as long as I can remember one of our favorite things to do is sit down together and watch a movie. Then we had kids and our movies started becoming toys. It is really frustrating to pull a DVD off the shelf and find either that it is missing or that it has baby fingerprints all over it!

I finally found a very simple solution. RipIT – The Mac DVD Ripper. This utility lets you easily rip DVDs onto your hard drive for archiving. This way I can archive my DVDs to my hard drive, and store all of the originals in a box. This way I can still watch my movies (I watch them now from my Mac) and keep the originals safely out of reach of the kids.

Installation

To install the latest version of RipIT for Mac, visit the site or use this link: Download

Drag-and-drop the RipIT icon into your Applications folder, and start things up.

The free version allows you 10 DVD rips. After that it has a very affordable registration fee to unlock unlimited rips.

Use

I’ve included some screenshots, courtesy of the main RipIT site, to give you an idea of just how incredibly simple it is to archive a DVD onto your hard drive:

It really is as easy as 1, 2, 3!

Categories: OSX Tags: , , , ,

AUR Package of the Week : Firefox-Branded

January 4th, 2010 No comments

I’m happy to present the AUR Package of the Week, and also the first package of the new year! Today I thought I would showcase the old and trusted browser, Firefox, with a slight twist from the package available in the main repositories.

Installation

The version of Firefox available in the main repositories is distribution-restricted based on the Mozilla license. You may notice that the version you install is lacking the Firefox branding and name. Again, this is due to a clause in the license. The license say that while Firefox is Open Source software, the name and the branding are not. Unless you’ve made an agreement with Mozilla, it is outside of the license to distribute the browser along with the name and logo. It is fine, however, to get the source from Mozilla and retain the logo and other branding.

With that said, to install a branded Firefox browser use the command:

yaourt -S firefox-branded

Compilation

As is the case with many other packages in the AUR, this one will require compilation. I’ve found Firefox to take a bit of time to compile, but its not nearly as bad as some other packages. Your mileage may vary.

Conclusion

Firefox has long been the flagship of the free software world. I think this is changing with the release of so many other new (WebKit) browsers, but Firefox still retains the market lead. I have found that, while I have become a fan of Chrome, that Firefox is always dependable as a fall back browser.

Categories: arch Tags: , , , ,

Configure EPEL Repository : CentOS 5.x

January 1st, 2010 3 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: , , , , , , ,

Reset Root Password : FreeBSD

December 29th, 2009 No comments

This post will outline how to reset the root password on FreeBSD. These instructions require local access to the machine and are available on FreeBSD versions 5.4 and greater.

Resetting the root password

As I mentioned above, resetting the root password and gaining administrative access to the machine requires local access to the server. Following the steps below should put you at an administrative prompt where you will be able to run the ‘passwd’ command to reset the password to a known value.

  1. Restart the server.
  2. When the “Welcome to FreeBSD” menu appears, press the [SPACEBAR] to pause the boot countdown.
  3. Select “4″ which should be: Boot FreeBSD in single user mode.

After the machine boots you should be presented with a prompt:

When prompted Enter full pathname of shell or RETURN for /bin/sh:

Press the enter key, or enter the full pathname of your preferred shell. At this point you should be at a shell prompt, as the root user. The remaining step is to reset the password to a known value.

In order to make this change you’ll need to remount the filesystem(s) in read-write. Use the following two commands to make this change:

mount -u /

mount -a

Finally, reset the root password using the passwd command:

passwd root

At this point you should be able to reboot the machine, or type ‘exit’ to continue the boot process into its normal multi-user environment.

Troubleshooting

If you have problems regarding the “passwd” command not being found, or other similar issues, you may need to ensure that you have properly mounted any additional file systems. I might suggest using:

mount /usr

To ensure that your /usr partition is mounted (assuming it is on a separate partition).

Categories: freebsd Tags: , ,

AUR Package of the Week : Google-Chrome-Beta

December 28th, 2009 No comments

This week, as we get ready to start a new year, I want to present Google-Chrome-Beta as the AUR package of the week. This is Google’s official Beta release of their browser.

Installing Google-Chrome-Beta

To install the Google Chrome Beta browser from AUR, use the following command from your favorite terminal:

yaourt -S google-chrome-beta

This will download and install the Google Chrome browser and create a menu entry.

Configuration

Configuring this browse, if you’ve never used Chrome before, is done by selecting “Options” from the configuration menu once the browser has launched. This is the icon furthest to the right, just beneath the address bar.

There isn’t a lot to configure, but there are enough options to let you personalize the browser. From cookie and password management, to themes and extensions, you should be able to find it all within that menu.

Troubleshooting & Comparison

I have been using this browser for months now and I haven’t had any issues, but if you do experience any you have a few options. You can, of course, fallback to another browser until an update is available. (This solution was more common previous to this browser becoming Beta quality.) You may also be interested in comparing the configuration differences in the Chrome Beta and Chromium browsers. Have a look at this link for those details.

Categories: arch Tags: , , , ,

Configure Logwatch Log Monitoring Tool on Debian 5.x (Stable)

December 25th, 2009 1 comment

Despite the fact that I am a Red Hat Certified Engineer, and manage Red Hat and CentOS for a living, I prefer running Debian 5.x (Stable) on my personal servers.  The one thing that I end up needing to add to my Debian servers however is Logwatch (which is default on Red Hat). This post will outline how to install, configure and verify Logwatch on your Debian 5.x (Stable) server.

From the Logwatch home page:

Logwatch is a customizable log analysis system. Logwatch parses through your system’s logs for a given period of time and creates a report analyzing areas that you specify, in as much detail as you require. Logwatch is easy to use and will work right out of the package on most systems.

Installing Logwatch

To install the Logwatch Log Monitoring tool, you’ll need to install the required package. This package should be available in the main repository and simply requires Perl and a Mail Transport Agent. Perl is something you’ll likely already have, and Exim should be installed by default (although I prefer Postfix).

Use the following command to install Logwatch:

sudo aptitude install logwatch

Configure Logwatch

Logwatch runs via cron each day and, assuming you want to receive these reports, you’ll likely want to configure it to send these reports via email. You’ll need to update the configuration to output to mail as well as define the address you’d like it to send to. This is done in the following file:

/usr/share/logwatch/default.conf/logwatch.conf

The two changes you’ll want to make are as follows:

  1. You should find, around line 35, a setting for Output. You’ll want to change this to mail.
  2. Find, around line 44, the setting for MailTo. You’ll want to change this to the email address you’d like the reports sent.

You can verify the functionality by simply running the logwatch command and checking the email account you configured.

Troubleshooting

If you find that you don’t receive an email as expected, it is likely an issue with your Mail Transport Agent (Exim, Postfix, Sendmail, etc..) Take a look at /var/log/mail.log and see if that gives you any hints.

I have run into machines where Exim, the default Mail Transport Agent, was not configured properly to be able to send email outside of the machine. You can try to reconfigure Exim by reconfiguring the package installation:

sudo dpkg-reconfigure exim4

You can also try installing something you might be more familiar with. Perhaps Postfix or Sendmail. If you install Postfix, select the “Local Only” option during installation and it should work as expected.

Categories: Debian Tags: ,

Hello World!

December 25th, 2009 No comments

Welcome to Enhanced Linux! This blog aims to enhance your Linux and UNIX experience by publishing tips and tricks on all aspects of Linux life. Whether it be Desktop users on Ubuntu or Server Admins on FreeBSD, we’ll publish tips to try and make your life easier. Enhancing the user experience is our goal!

Categories: freebsd, Ubuntu Tags: , , , ,