Login process creation

login_processes_count and login_max_processes_count setting control how new login processes are created. login_processes_count specifies the number of login processes that are tried to be kept listening for new connections. However when a lot of connections arrive at the same
time this number will increase automatically as described below.

I was migrating my mail server to a new machine the other day and in the process, I sorted out my smtp/sasl logic.

I'm using virtual domains/mailboxes/aliases with Postfix, PostfixAdmin and Postgresql on Debian servers, works like a charm, but my sasl config was such that it wasn't using the same postfix database for password lookups and I was having to use saslpasswd2 to add accounts so that I could send mail using this server for SMTP as it was using its own sasldb or whatever.

Madness.

This time I've implemented Dovecot's SASL mechanism, it reduced double-up and means the authentication is done via the database in the same way that logging in to *retrieve* mail was being performed (as far as I understand it anyway. I'm not a mailserver guru).

All I changed was in /etc/dovecot/dovecot.conf

# It's possible to export the authentication interface to other programs:
 
socket listen {
    client {
        path = /var/spool/postfix/private/auth-client
        mode = 0660 user = postfix group = postfix
     }
}

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth-client
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, 
reject_unauth_destination

Be wary when you upgrade Debian Lenny server to 5.0.1 and you use Postfix & Dovecot with a PostgreSQL backend and PostgreSQL-8.3 gets upgraded and restarts itself. My Dovecot stopped being able to connect to the database to authenticate my login requests from Thunderbird all
of a sudden with the error 'you have enabled secure authentication and this server does not support it'.

I knew I hadn't changed any Dovecot settings on how I authenticate my IMAP session so assumed it was the PostgreSQL upgrade, though PostgreSQL was running fine.

This in the dovecot logs

dovecot: 2009-04-13 10:38:15 Error: auth(default): sql(<a href="mailto:example@some--address.com">example@some--address.com</a>),): Password query failed: FATAL: terminating connection due to administrator command
dovecot: 2009-04-13 10:38:15 Error: auth(default): io_loop_handle_remove: epoll_ctl(2, 9): Bad file descriptor

I restarted Dovecot, and Postfix just to be sure :) and all is back to normal. I'm assuming it was Dovecot holding a stale connection open to PostgreSQL, and not the MTA, as it wasn't a problem with delivering mail (though it might've posed a problem for Postfix too, but didn't let it hang around long enough to find out)

I wonder, I know that some packages like openssl and whatnot, are able to check what other services are running that depend on it when it's upgraded, and offer a postinst (I assume) ncurses notification telling the user that some services should be restarted. PostgreSQL should have a similar check to see if it's being used for a vhost mail setup.