X-Istence wrote:

Rick Widmer wrote (At least in part):

I am adding the following functions to vpopmail:
valias_select_names, valias_select_names_next, valias_select_names_end

Kinda like C++'s std::vector things, allowing you to walk thru an "array" of aliased domain names.

I don't know about std::vector, this is stolen from valias_select_all() and valias_select_all_next(). I wanted just the alias names, preferably sorted. Since it is so easy from any of the database front ends, I decided to sort the names for cdb and say "vpopmail always returns them sorted." That is very handy for QmailAdmin... it does't have to sort them.

Submit a patch on sourceforge is what tom would say :P

Already done... :P [ 895348 ] Ordered Alias Names for cdb

I am testing the extension running PHP as an Apache module, with Apache running as vpopmail:vchkpw. I think it should also run from CGI as long as it is run as the vpopmail user. I don't see any way to get around running as the mail system user, and considering how easy it is to setup a separate instance of Apache I don't see any reason to worry about anything else. If you don't agree, now is the time to show me a better way.

How about a public private key sort of thing like SSH?

For what? As I see it the vpopmail extension for PHP is for web servers that are running on the mail server, like QmailAdmin or sqWebmail are run now. Since everything is done by one process I don't see any need for fancy communications in the extension.

Using named pipes as a means to "talk" to each other. This would require a deamon.

If I had that daemon, I wouldn't bother with an extension. It would be much easier to code a library in PHP to accesses the daemon.

Hitting something like this via a SSH tunnel would be very cool! You
could manage a mail server from many web servers.  It is serious
overkill for what I want.  This little project is about using PHP for
prototyping the user interface for QmailAdmin 1.3.

Or even, just exec, and having a binary setuid vpopmail:vchkpw and talk over stdin, and stdout.

A binary that handled a few information retrieval functions is probably all that would be needed. I think there would be about 4-6 functions it should be able to return data from. I actually considered writing it before I decided to attack the PHP extension.

For the rest we may as well exec the existing progtrams and not
re-invent existing functionality.  I've already got a PHP program that
manages mail domains that way, but it reads the ~vpopmail/domains/
directory to get all its information.

This would be better than running apache as vpopmail:vchkpw.i prefer
not to run two different apache's side by side, just one, running as
www:www :)

I don't run two web servers side by side either... the ONLY things Apache does on my mail server are mail related. There are NO web sites and very few people who login to it directly. I see it as an extension of the mail system, not a web server, so running as the vpopmail user is natural.

So far the only things I don't know how to handle from running apache as
vpopmail is adding and removing domains.  Specificly altering the
/var/qmail/users/* and signaling qmail.  I will take the easy way out
and just exec the vpopmail programs.  The real goal here is working the
bugs out of the user interface for the next generation of QmailAdmin
before I commit the code to C.  The updated vpopmail module is just a
side effect.  :)

Since I haven't heard from anyone actually using the extension, I think
I am going to just rip out the code that checks for ancient versions of
vpopmail, add a note that says it "Requires vpopmail 5.4.2 or newer" and
call it good.  If someone actually needs to use an older version, some
of the code can be #ifdef'ed out later.

Thanks for responding...

Reply via email to