# cron + ldap + postfix != emails to root [workaround]

## newfangled

I've just set up openldap and it is running nicely as a backend for samba/courier-imap/postfix etc. It is not a virtual user setup and emails are correctly routed based on /etc/mail/aliases and then LDAP. Except for one thing..

I have a series of scripts in root's crontab and I like to see the results in my email, but they are not being delivered anymore (everything was fine before I setup LDAP) Here is my /etc/mail/aliases, I've also tried with just "adminaccount"

```
root:     adminaccount@mydomain.net

john:     sam

...

other aliases
```

Sending mail from the command line to root, john, sam or adminaccount works fine. Sam is an LDAP user..

My crontab:

```
# system staus report - 09h55 daily #

     55   9    *    *    *    /root/bin/dailystatus.sh

# test this is working - 10h05 daily #

     5    10   *    *    *    touch /root/itworks.txt

# mail sam system status report - 10h00 daily #

     0    10   *    *    *    /root/bin/dailystatus.sh | mail -s "System Status" sam

...
```

As you can see from the log output below the commands are being run and as a test to make sure the scripts were executed I added that second cronjob. The itworks.txt file was created succesfully and sam gets his copy of the status email.

```
Jul 22 09:55:01 [cron] (root) CMD (/root/bin/dailystatus.sh)

Jul 22 10:00:01 [cron] (root) CMD (/root/bin/dailystatus.sh | mail -s "System Status" sam)

Jul 22 10:05:01 [cron] (root) CMD (touch /root/itworks.txt)
```

I have a feeling this is a postfix issue so here are the pertinent parts of /etc/postfix/main.cf

```
...

local_recipient_maps = $alias_maps

alias_maps = $alias_database, ldap:ldapper

alias_database = hash:/etc/mail/aliases

ldapper_server_host = localhost

ldapper_server_port = 389

ldapper_search_base = ou=users,dc=mydomain,dc=net

ldapper_query_filter = (&(mail=%s)(objectClass=CourierMailAlias))

ldapper_result_attribute = maildrop

ldapper_bind = no

...
```

I'm really happy with how the server is working right now, this is just a snag for me at the moment and I have a decent workaround in the form of using a pipe to mail. It's more a question of understanding why this behaviour is happening. Thanks in advance for your help.Last edited by newfangled on Fri Dec 01, 2006 12:25 pm; edited 1 time in total

----------

## brfsa

check you /etc/mail/aliases

make sure you have root mapped to some user.

for example on my configuration:

# Well-known aliases -- these should be filled in!

root:		    fred

then run

/usr/bin/newaliases

----------

## newfangled

Thanks for the instructions, I included my /etc/mail/aliases above, root is mapped to an account on the machine. Albeit an LDAP account, but as I said the alias for john is successfully routed to the sam account.

I can see that the cron task was run and that the message is sitting there wanting/waiting to be delivered:

```
[root@server ~]# ps auxf

...

root  27833  0.0  0.0   6128  1672 ?  S  09:55   0:00 /usr/sbin/sendmail -FCronDaemon -odi -oem -oi -t

root  27836  0.0  0.0   6108  1648 ?  S  09:55   0:00  \_ /usr/sbin/postdrop -r

...

```

----------

## bunder

try mailq to see why its not going through.

----------

## newfangled

That's what is strange, postqueue -p and mailq both show the the queue is empty. The mail isn't even submitted yet, I just have those processes quoted above sitting there...

----------

## overkll

Does your mail log indicate what happens to the missing messages?

Your /etc/mail/aliases shows you map root to adminaccount@mydomain.net...

```
root:     adminaccount@mydomain.net

john:     sam

...

other aliases
```

AFAIK, postfix doesn't like full email addresses in the alias database.  Try removing "@mydomain.net" from adminaccount, just like the "john:    sam" entry then run newaliases or postalias <file>.

Also double check that you are pointing to the correct alias database in main.cf

If you need to map root to another destination that is NOT your local domain and need to use a FQDN, you'll need to use the virtual_aliases map mention in the postfix docs.  ( " man 5 virtual " )

----------

## newfangled

Thanks for the pointers overkll

I'll check the logs again and run a few tests, but I did set up a cron job to run while I had a tail -f /var/log/mail/current running and didn't see the messages injected into the queue. I guess that's why I still have those stale processes.

I've already tried changing my /etc/mail/aliases so it is just "adminaccount" actually that's how I had it by default.. I only tried the FQDN version when I noticed mail not getting through. It doesn't appear to make a difference one way or the other.

As for whether it's best practise or not, I'm not really sure. I've been running postfix for years on a bunch of servers and it works..  either way.   :Wink:  Though I don't think I have ever tried with root before. Anyway I really don't want to have to that. I want it delivered to a local account, I'm just not sure why the john > sam alias works but not root's.

----------

## overkll

Im pretty sure you don't want the domain part in your aliases file.  And if you didn't postalias or newalias the flie, postfix would complain about the db being older than the alias file (in the logs).

You could try adding a "-v" to the end of the smtp transport in master.cf, and restart/reload postfix.  That will enable verbose logging.

/etc/postfix/master.cf

```
# ==========================================================================

# service type  private unpriv  chroot  wakeup  maxproc command + args

#               (yes)   (yes)   (yes)   (never) (100)

# ==========================================================================

smtp      inet  n       -       n       -       -       smtpd -v
```

You may also want to emerge "pfqueue".  Its a handy little tool for viewing/managing postfix queues.

----------

## newfangled

I'm still seeing the same behaviour.. I've tried pfqueue but the messages are never actually inserted they just sit as stuck sendmail processes.

The strange thing is a little while ago, following an emerge -e system|world cron status reports actually started getting delivered to root as expected. This lasted for a while and through reboots and regular system use and maintenance but then it all went quiet again from my friend cron. My hunch is that it was a package in system but I am unable to replicate the solution and emails stopped arriving again some weeks ago.

I'm almost certain it has to do with cron, all other users (and their aliases) receive mail successfully. Portage elogs, postfix errors, legitimate mail etc.. it's just cron emails that get stuck.

If anyone has any ideas I would be most grateful.Last edited by newfangled on Fri Dec 01, 2006 12:03 pm; edited 1 time in total

----------

## slobba

I've had exactly the same problem for a while now with postfix/vixie-cron and have been following posts such as this one to find a proper solution. The only thing that has worked for me is downgrading vixie-cron to 3.0.1-r4. Any version later than this and the problems returns.

----------

## newfangled

Thanks slobba. It's a relief to know that I'm not the only one to see this kind of behaviour. Cheers for the heads up on reverting to 3.0.1-r4 I can confirm cron sends emails as intended. I would have worked my way back from the newest revision so you saved me some time there. I owe you a pint.

Now to figure out how to get the latest vixie-cron to work.

----------

## atct

Indeed downgrading also did the trick for me.

Is there already a bug posted for this?

----------

