< email > home > pam
It works though a central `server' library - libpam - which reads configuration files telling it how any given application should be authenticated. Those files can be changed (taking effect with the next authentication attempt) to reflect updated site policy.
It comes in two parts: pam_tally.so is the pam module proper, pam_tally is the administrative program which interprets what pam_tally.so collects.
Oh, here's a third part: pam_tally_autoreset.pl which sits in a frequent cron (once a minute/five minutes) and resets anyone who's been blocked for a certain number of minutes. When I was using pam_tally myself, I just stuck a midnight cron in to delete /var/adm/faillog; autoreset is more elegant, I suppose.
This module comes in two parts too: the first (misnamed), checkpam should be compiled as a PAM application (get the pam distribution from here). This is the bit you tell qmail about - use it like the checkpasswd program.
The second bit is the PAM module, whose source is here, which goes with all the other PAM .so files, and should be inserted into /etc/pam.d/qmail-pop3d I believe it should preceed all other modules as auth required, because it cooperates with checkpam, but I've written to my former employer to find out. (This page is only a quick front end to things, I need to set up the pam stuff here sometime.)
My previous job was web admin, and I often had to set up a new virtual web host, with virtual email, and some virtual users (which is terribly easy with qmail), etc. This was easy enough, but involved editing about seven different files. So I wrote a script to handle that. So far so good.
NT, as I understand it, only needs something typed into a buffer, and a new server pops into life (after a suitably annoying reboot). I don't see why Linux (or Unix) should be any different, so I hatched this meta-config file, which can be told about several different virtual hosts, those hosts' virtual users, and which will then be able to rewrite the config files for things like named and httpd, then HUP them. Or maybe even someday just act as some sort of central database and unified config file for appropriate utilities which may then use a modified version of this system as an external way to read sections of their config files.
I'm sure there are better ways to do databasey things like this, but I wanted it text-editable, and fairly easy to write cgi-based admin tools. :)
Anyway, as I say, it's experimental, and at the moment, only the parse engine works. Comments are welcome though, and this is probably the most descriptive file.
< email > home > pam
|This page last changed Tue Nov 11 09:26:30 2003|