On 16:10 26 Apr 2002, Pieter De Wit <[EMAIL PROTECTED]> wrote:
| On 08:30 26 Apr 2002, Pieter De Wit <[EMAIL PROTECTED]> wrote:
| | How well does sendmail handle a *big* alias file (around 20000 entries) ?
| | Is there another way to handle such big alias requirements ?
| Keeps it in a dbm file. We have over 40000 aliases at work; works just fine.
| If I may ask, what hardware do you run to support this ?
Nothing very powerful. The NIS servers are Sun Ultrasparcs. They aren't
very stressed; usually nearly idle. Our mail hub (which has the identical
mail file locally as a plain dbm file to make it not dependent on the
NIS servers) is a moderately specced Intel BSD box.
The alias file is actually computed from a set of MySQL tables (and
some historical flat text files) at update time. We keep out core user
records and group records (as hierachical, date-ranged structures)
in these tables and unpack them for the aliases table, and the UNIX
group table, in this way having a UNIX group to hand for every need,
with names exactly matching the mail aliases (to reduce confusion).
Example:
There's a group called "technic" for the sysadmins (of which I am one)
looking like this (some stuff elided because our management have been
getting more ana^H^H^Hcareful recently):
[~]zapff*> dbgroup technic
Group names: technic sysadmin
Account code: ****
Title (Long Name): IT Services
Flags: GROUPUSED
Internal PROJ_ID: 84
Membership:
{leader => [***],
manager => [*****],
pc => [/technic-staff-pc],
staff => {misc => [oliverw],
pc => [robs,
desmolej,
clg,
jerome],
unix => [cameron,
raphael,
kirsty]}}
>From this come the following mail aliases and UNIX groups:
technic
technic-leader
technic-manager
technic-pc
technic-staff
technic-staff-misc
technic-staff-pc
technic-staff-unix
with the obvious memberships. (For historical reasons this group is
also known as "sysadmin" as shown in the top line of the dbgroup output,
and there are matching aliases "sysadmin-pc" etc in consequence.)
Now, we also support delivery of mail to personal workstations for the
UNIX users because many UNIX mail readers make use of local files and
don't speak pop or imap, and for convenience if the central mail host
goes down. The Windows and Mac users use the central pop/imap server.
So each user has a delivery location too.
My own user data look like this:
[~]zapff*> dbuser cameron
Internal id #56
Login cameron
Emp_Status TEMPORARY
Ilk SUPPORT SW
{ALTNAMES => [],
DATES => [{EMP_STATUS => TEMPORARY,
END_DATE => 2000-05-26,
START_DATE => 1997-01-01},
{EMP_STATUS => TEMPORARY,
END_DATE => "",
START_DATE => 2000-05-27}],
DESK => L6-019,
DIALBACKS => [],
DIVCODE => 13,
EMAIL_HOW => HOST,
EMAIL_PGPKEY => "",
EMAIL_PUBLISHED => "",
EMAIL_WHAT => zapff,
EXCLUDEGROUPS => [],
EXFWD => [EMAIL PROTECTED],
EXT => 2983,
FAX => [],
FIN_STATUS => S,
FLAGS => [],
FULLNAME => "Cameron Simpson",
HOME => [],
HOMEDIR => /home/zapff/cameron,
LOGIN => cameron,
MANAGER => ***,
MOBILE => [],
OTHER_EMAIL => "",
PREFGROUPS => [geeks,
web-int,
technic,
maillist],
TITLE => "UNIX Systems Admin, Standard"}
For example:
[~]zapff*> expalias technic-staff-unix
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
For purposes of this discussion, the EMAIL_HOW and EMAIL_WHAT fields
say that my email is delivered to a host (as opposed to, say, being
forwarded to an external address or suchlike) and that the host is
"zapff", my workstation.
You can see we keep desks and phone numbers. We track a bunch of info
from that. For example we keep our wiring database's per-host records USER
fields computed by backtracking user desks to host locations. Conversely,
user phone extensions are computed by tracking from the phone wiring
(to a desk) and correlating with the user's desk.
So, if we make a change to these tables which affects the alias table we
recompute the mail alias table with a perl script. The _entire_ alias
table is computed from the database tables. In this way we don't have
to wade through a huge text file making manual changes.
The editing interface for users is a small perl script which transcribes
the user data to a result like the one above, invokes your editor, and
transcribes any changes back into the databases. Very easy. The group
editor is much the same:
http://www.zip.com.au/~cs/scripts/dbuser
http://www.zip.com.au/~cs/scripts/dbgroup
Given a -e option they do the edit mode.
Making the aliases table is a big perl script:
http://www.zip.com.au/~cs/scripts/updaliases
Aside from expanding the group structures, it also takes care of
tedious trivia like making "firstname.lastname" aliases for every
user in several permutations, aliases to map phone extensions to users
(we used to use that for an ugly voicemail system) and several other
convenience aliases. For example, we have a whole "app" group which
has a vendor/app subtree hierachy for contact addresses. And so we never
hand out personal addresses to vendor maintenance agreements, we hand out
"app-vendor-app-contact" and/or "app-vendor-app-users" and maintain the
actual membership at our end. Empty aliases get forwarded to "postmaster",
so if the last contact leaves things don't fall though the cracks.
The UNIX group table is make by a somewhat simpler script:
http://www.zip.com.au/~cs/scripts/updgroup
with some different problems: due to NFS limitations users can only be
in at most 15 groups at once, so some pruning is done (some managers
and sysadmin fall into many groups, and the subgroups help explode the
numbers too). To this end groups are rated for importance, and a group
may have the "GROUPUSED" flag (as the "technic" one above does) to say
it's genuinely used for permissions so rate it highly. Further, individual
users may have specific groups rated essential with their PREFGROUPS field
(eg see my user record above). These two hints, sparingly used, let us
control what UNIX groups people are handed in a pretty painless fashion.
Also, we still have some historic groups in the group table which aren't
moved into our db, and the script tries to not obliterate them.
So you can see that with a flexible db structure and some coding you
can drive these tables quite easily without teaching your mail systems
anything special.
Cheers,
--
Cameron Simpson, DoD#743 [EMAIL PROTECTED] http://www.zip.com.au/~cs/
"It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
