Oct 112012

Have you ever had your root hard drive fail and found that your shell prompt has forgotten every command? It isn’t fun. What you first notice is that whatever you type, it’s the same answer.

bash: /bin/vi: Input/output error


Or a similar effect has been witnessed after the famous “rm -rf *” got executed under the /usr directory. This kind of thing would happen:

  # ls 
bash: ls: command not found

This is because most of the commands you use at the shell command line are binary files residing under /usr/sbin, /usr/bin, /sbin or /bin, depending on your distribution. Once they’re gone, you’re dead in the water.

So if all you have is a CLI shell prompt, but no commands work, what can you actually do?

If the problem is due to a corrupted disk, you may be able to resolve the issue by rebooting into single user mode and running an fsck on the root filesystem. In the case of missing binary directories you’d probably need to rebuild your host completely. But before you do restore from your backups (you’ve got backups, right?), you may need to make a few tweaks or check a few file contents in order to get things back up and running again.
Continue reading »

Matt Parsons is a freelance Linux specialist who has designed, built and supported Unix and Linux systems in the finance, telecommunications and media industries.

He lives and works in London.

Oct 082012

It’s one of the dumbest things you can ever get called out in the middle of the night for – because a filesystem has filled up because of a log file. Dumb, because it’s preventable and because you shouldn’t be the one doing housework. It’s a computer – its whole purpose is to do the work for you.

The logrotate script was created to monitor, archive and delete log files so you don’t have to. It is an absolutely vital utility with which, in theory, a Linux host could run literally forever without maintenance. It’s installed in the base bundle on all major versions of Linux.

The key things you need to know is that the logrotate process is called by the cron daemon, with the wrapper script located at:


And each logfile (or set of logfiles) which is to be monitored and archived has its own logrotate configuration file under:


Every time the logrotate program is executed by cron, it checks every monitored logfile against the conditions in the logrotate.d configuration, and then copies it aside, with a number added as an extension, while resetting the original logfile size to zero.
Continue reading »

Matt Parsons is a freelance Linux specialist who has designed, built and supported Unix and Linux systems in the finance, telecommunications and media industries.

He lives and works in London.

Feb 062011

An authentication naming service is one of those things you tend to put off until you really need it – until your user population hits critical mass. It may seem like a big job at first, but it doesn’t need to be, and the results are worth it.

In selecting an authentication service, I’ve gone with LDAP. It’s big and extensible and can handle any kind of data. So LDAP it is. I’m going to put it everywhere and get everything to use it – Cisco, SSH, TRAC, SVN. I’ll be using 389 Directory Server, formerly known as Fedora Directory Server.

Before I start with any new system, I like to know where all the parts of the machine are.  Things rarely work the first time, and I feel better knowing where to debug.

The moving parts of LDAP 389 Directory Server


These are found in the Fedora extras repository.


      # yum install centos-ds

which will install the dependencies:




Configuration Files

The key configuration files that will be created by the installation process, and edited later, are:




These configuration files are relevant on clients which authenticate against our LDAP server.


Database files


(You probably don’t need to ever be in here)

Log files



  • LDAP: 389
  • LDAPS: 636
  • LDAP Admin GUI: 9830


  • dirsrv
  • dirsrv-admin

Installation & Setup

The installation procedure is all here – http://directory.fedoraproject.org/wiki/FDS_Setup – but my abbreviated experience follows.

Install packages and dependencies:

     # yum install centos-ds

With all dependencies, my installation downloaded about 75 MB. There are a few prerequisite kernel parameters that are nice-to-have, and the setup script later will mention it so:

     # echo 300 > /proc/sys/net/ipv4/tcp_keepalive_time
     # ulimit -n 8192
     # echo "* soft nofile 8192" >> /etc/security/limits.conf
     # echo "* hard nofile 8192" >> /etc/security/limits.conf
     # echo "ulimit -n 8192" >> /etc/profile

Next, the setup script. There are lot of options you can run it with, but since you’re probably only doing this once, run it interactively – with no arguments:

     # setup-ds-admin.pl

Most of the answers are “yes”, then select “2” for a Typical installation.

When prompted for the server name, ensure you type the fully qualified domain name. If you’re going to secure LDAP later with certificates, this is especially important, but frankly, it’s just a little sloppy not to.

The next few questions are just regarding system user accounts, and passwords, “nobody” is fine and pick a tough password for the admin password.

The other questions are fairly straightforward. The Directory Server Identifier is probably best set to the FQDN, to make things less confusing.

When prompted to enter the Suffix, the suggestions revolve around using the server domain, which is for the most part fine, but I find it easier to make it as simple as that, even if your domain isn’t. So if your server was 2ldap.internal.example.net”, I’d still set the Suffix to “dc=example,dc=com”. That way, you fit in with everybody else.

Set a good Directory Manager password, because you’ll be using this a lot, accept the defaults for the next question, and kick of the script setup with a “yes”.

It’s nice to have a single setup script. I’m getting too old and lazy to mess about with configuration files and too many man pages. If the script completes without errors, you’re done.


So if you bollocks it up completely, it’s nice to roll back to square one and start again.  If you can’t revert to a snapshot or backup, then you can freshen things up like so:

     # service dirsrv stop
     # service dirsrv-admin stop
     # yum remove centos-ds*
     # rm -rf /var/lib/dirsrv/slapd- /etc/disrv/slapd-instance

Then, you should be OK to reinstall the packages and start again.

Initial Testing

Once the setup script is completed, if you’re a novice to LDAP, the first question seems to be, “What now?” The query syntax takes some getting used to, and there’s a lot to absorb. The next post will explore how to set things up, and how to query the LDAP database. For now, the following command is a simple way to check things are working:

     # ldapsearch -x -h  -p 389 -s base -b "" "objectclass=*"

Matt Parsons is a freelance Linux specialist who has designed, built and supported Unix and Linux systems in the finance, telecommunications and media industries.

He lives and works in London.