[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: automatic handling of newly added domains
> > If I add a new domain to my configuration (i.e., insert a new alias user),
> > qmail doesn't immediately start accepting mail for that domain because it
> > only reads the rcpthosts at start up. How does everyone handle this
> > situation? I figure I'll just cron "qmailctl hup" every hour or so. Does
> > anyone have an alternate solution?
> We have a 5 line Perl script listening on a pipe. Whenever the admin scripts
> add a domain they also write to the pipe, which causes a restart. The pipe
> mostly handles permission/ownership issues as the processes run as different
> users etc. Although crackers obtaining any shell access could maliciously
> restart qmail repeatedly - that is the least of our worries.
> We did ponder Postgres triggers - but that seemed to be a relatively new bit
> of postgres (as far as running external programs goes) - although it puts the
> logic in the "right place", most of our logic is in the admin scripts anyway
> for better or worse.
Hmm, triggers and the ability to call out to dynamically linked external
libraries have been part of Postgres for as long as I can remember, which is
version 0.95 at least. Unfortunately (perhaps what you're referring to), you
can't just say "run /path/to/program" in a trigger. Anyway, I played around a
bit yesterday with the PL/sh language handler:
It's pretty neat, it allows you to use a standard shell script as a stored
procedure. So, I created one that simply sent a HUP to qmail-send, and then
called it from a trigger:
create function hupsql() returns int as '
/usr/local/bin/svc -h /service/send
' language plsh;
create function new_domain() returns trigger as '
if new.userid = \'alias\' then
' language plpgsql;
create trigger new_domain after insert on users for each row execute procedure new_domain();
Unfortunately, I quickly discovered what you already knew -- the pgsql user
doesn't have permission to HUP qmail. :(