One of the things I run (I think it was WordPress) was griping at me to update PHP to at least version 5.4. But I was on CentOS 6, which stops at 5.3 by default. But hey – there is a
php54 package in the EPEL repo, so I installed it. All good!
Except it wasn’t all good. Now my roundcube installation was borked.
I’ll spare you the finer parts of me tale of woe and give you the 4 things I did to fix it.
- Updated roundcube.
New version, supports newer stuff, etc.
- Installed the remi repo
This repo has a reputation for providing packages for PHP 5.4 that you might otherwise not find or might have to compile by hand.
yum localinstall remi-release-6.rpm
php54-php-mcrypt from the remi repo
Running PostfixAdmin 2.92 on a box with dozens of domains. An admin tried to delete mailboxes and got the error: Problems running mailbox postdeletion script!
How I fixed it
To run scripts after deleting a mailbox from the database, PFA runs the script
/usr/local/bin/postfixadmin-mailbox-postdeletion.sh. Since PFA is running as apache and the script needs to run as the postfix user, it recommends adding a line to
/etc/sudoers to allow just that. Problem is, of course, that it failed.
I could run the script as another user who had the exact same privileges in
/etc/sudoers. I could even give apache
c a shell and run the script successfully. So the script worked (well it worked after I changed some assumptions in it; see below). But it didn’t work from the web page.
To make a long story short, the fix was to remove the requirement for the apache user to have a tty. That’s as simple as specifying the sudo defaults for apache.
/etc/sudoers (by running
visudo), and added:
above the line I had added earlier:
apache ALL=(postfix) NOPASSWD: /usr/local/bin/postfixadmin-mailbox-postdeletion.sh
Shout out to http://getasysadmin.blogspot.com/2009/11/postfixadmin-errors-executing.html for the sudoers fix.
Changes in the script itself
The default in PFA (or, at least mine) is for maildirs to live in
/var/spool/postfix/virtual. The script, however, assumes that they go in
/var/spool/maildirs. Can’t blame the authors – we’re a bunch of nerdy bit-heads and we might stick our mailboxes anywhere.
Furthermore, the default names each maildir user@domain (i.e. firstname.lastname@example.org). The script assumes the maildirs the user name as a subdir, with the parent being named the same as the domain (i.e.
In full, the script assumes email@example.com has a maildir of:
Whereas the default is:
To fix this I changed this line:
This assumes that the delete command passes “firstname.lastname@example.org” as the first argument to the post deletion script.
By default, the deleted mail directory will be in a subdirectory of the domain name. If you want to change that behavior, also modify