X-Istence wrote:
Rick Widmer wrote (At least in part):
Kinda like C++'s std::vector things, allowing you to walk thru an "array" of aliased domain names.I am adding the following functions to vpopmail: valias_select_names, valias_select_names_next, valias_select_names_end
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... Rick
