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.
Makes sense. Would make it a whole lot easier to parse the names coming at you, and no need to allocate more memory for sorting and then outputting it, output as it comes along.
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.
That is what i meant, not everyone is able to have a special server just for mail, and thus running Apache as vpopmail:vchkpw is not an option. If you created some sort of deamon that allows you with public and privatekey's to communicate. Then you can run apache as www:www and not have to worry about users being able to alter vpopmail stuff cause of the mail server running under vpopmail:vchkpw.
Well, what i meant is that having one binary that can do everything in one, is easier than having to run several different commands each time to add or remove domains, and having to parse different output each time.
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.
I personally might start on this, if i get the chance, as it would be a lot better than running apache as the mail user, when other there are other websites on it.
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.
Not everyone has the ability to have one server just for mail, which is why i suggest some sort of deamon, or a program that is setuid, to execute and talk with..
Thanks for responding... Rick