Tales From The Geek Side

If you use pam_ldap to authenticate against Active Directory you may have a problem you never thought of. You may be allowing disabled accounts access to your system. Use the following filter to exclude disabled accounts. The filter looks at the userAccountControl field which is a bit field. It checks the single bit that determines if an account is enabled or disabled. This snippet belongs in /etc/pam_ldap.conf.

pam_filter &(objectclass=User)(!(userAccountControl:1.2.840.113556.1.4.803:=2))

On second thought this might not be desirable. This will filter out disabled accounts making them appear as though they do not exist which is different than being disabled.

Sometimes you want to have logs of who created files and deleted files and even those who opened files.  Samba makes this possible but not where you’d expect.  You’d probably expect to see this if you increased the log level option to a verbose enough number.  It turns out that there is a vfs module that does exactly this.  It logs auditing information to syslog. But remember, this information goes to syslog, not to your normal samba log files. Also note that there is a vfs module named audit and one called full_audit.

Example share definition using the auditing facility.

[web-sites]
comment = "Web Sites"
# turn on auditing to see what the heck is going on
vfs objects = full_audit
writeable = yes
locking = no
create mask = 0775
directory mask = 0775
force create mode = 0664
force directory mode = 0775
force user = www-data
force group = www-data
path = /var/www-sites/
valid users = @www-data

I recently setup a new subversion server at work.  While testing it out users had problems checking out large projects.  Tortoise gave an error about a secure connection truncation (or something like that).  On the server end there were some uninformative error messages in the logs.  The problem was intermittent but was pretty easily reproducible.

I finally tracked the problem down to mod_deflate.  After disabling mod_deflate the problem completely disappeared.

I recently learned about Grubs configfile option. At first it doesn’t seem very interesting but it solves an interesting problem. Suppose you have multiple installations of Linux on your system all on different partitions. Ideally they would all work together seamlessly and update one grub menu.lst file. But if you have them on different partitions that won’t happen. There are a lot of reasons why something like that is difficult. Enter configfile to save the day.

To solve this problem you could make one partition exclusively for grub. You would install grub to the master boot record and install the stage 1.5 files to this tiny grub partition. In that tiny partition you would have a menu.lst file that would call out all of your other installs. It’s similar to using chainloading but it’s not quite the same. You’d only have to edit this master menu.lst whenever you added a new OS. Here’s a contrived example:

title Debian Lenny
configfile (hd0,1)/boot/grub/menu.lst

title Ubuntu
configfile (hd0,2)/boot/grub/menu.lst

You could do something similar using a chainloading approach and installing grub as the local boot record in each of your OSes but this way you have just one installation of grub to deal with.

I recently attempted to install Debian 5 using the latest net install iso image using Virtual Box (the commercial/non-open source version). The installs kept failing. I finally tracked it down to not having enough RAM available. 256MB was not enough but bumping the virtual machine setting to 512MB did the trick.

(This tip provided by John Ghidiu)
Sometimes evolution will be out of sync with the exchange server. As I write this it’s a known problem. The workaround is to force evolution to shutdown and then force it to rebuild the local folder cache.

It seems that Evolution getting out of sync with Exchange is an old, old bug. If you run:

evolution –force-shutdown
rm -rf ~/.evolution/exchange//folders.db (this is the cache, I think)

and then start Evolution again, things work again.

My file server appeared to have some filesystem issues. I wanted to check and repair the filesystem but I couldn’t find my system rescue CD on a USB stick. I considered rebooting the machine 30 times to force a check but that didn’t seem like a fun way to spend my time. The filesystem is the root filesystem and it is xfs which meant that I couldn’t use `tune2fs` to set the property to force a fsck.

Today I learned of a very easy way to force a file system check. That is to create a file /forcefsck. The startup scripts in the initial ramdisk will check the filesystem and remove the file.

It seems that every time I setup a diskless Linux machine I run into the same problem — nfs mounts hang. I’m not talking about the root filesystem. That mounts fine but other mount points result in mount hanging. Then I track the problem down to rpc.statd and portmap hanging. I also end up coming back to my blog to search for the answer to this problem and get frustrated when I can’t find the answer that to a problem that I’ve solved over and over. So, once and for all, I present the solution to the problem that I know I’ll encounter again.

The problem is that the localhost interface is not defined in /etc/network/interfaces and this causes problems (I do not know why) with the nfs/rpc tools. When I setup diskless machines I use debootstrap to create a root file system. Debootstrap correctly leaves a few things unconfigured. The localhost interface is one of them. And so I say to my future self, “self, just add this to /etc/network/interfaces and all will be well. And calm down this isn’t a big deal!” :

All too frequently I need to convert text files with DOS line endings to UNIX line endings.  It’s easy to do using tr but I can never remember the syntax.   The following strips the carriage returns (\r) and end-of-file characters (^z) from the file:

$ tr -d '\15\32' < dosfile.txt > unixfile.txt

I’m a somewhat casual user and administrator of the Mantis bug tracker.  Mantis is an issue tracking system written in PHP that includes a SOAP interface.  You don’t have to use the SOAP interface as it comes with a suitable HTML user interface.

Lately I’ve been loaded with more responsibility at work.   To keep track of the projects that I’m working and what other people are helping me with I’ve started using Mantis much more heavily.  One thing that started to frustrate me is that I wouldn’t know when people submitted new issues unless they were assigned to me.

There’s a GUI for managing email notifications that you can use at the global level or override on a per-project basis.  I enabled email notifications for new issues for “developers, managers, and administrators.”  Then I created a dummy issue as a test.  I was shocked to see that Mantis sent emails to ALL developers, managers, and administrators in my entire company!  I expected these messages to be sent to just the developers, managers, and administrators assigned to the project.

After much googling I finally found the answer.  If a project is public it will send those emails to everyone because everyone has visibility into those issues.  I had set all projects to public because I leave things open by default.  I prefer to promote communication in my company.  This also explains the (at the time) perplexing user interface for managing a project that listed everyone as a member of the project but only those that were truly project members had “remove” buttons.

So if you want to send out notifications of new issues to all members of a project make sure your project is private.