Gre7g Luterman wrote:

> On Tue, 24 Jun 2003 17:45:39 -0400, Jesse Guardiani
> <[EMAIL PROTECTED]> wrote:

[...]

>> 1.) I think the whole VIRTUAL_TEST variable is a bit silly. I think this
>>     should be determined by the auth method, not a file system test.
> 
> A good idea, but not completely practical.  The problem is that it is
> possible (even if no one really does this) to have both real users and
> virtual users use the system at once.  If we did an auth method test,
> then we could only support one type of user per install.  We had to
> have a test that returned good results at login.


It _is_ possible to authenticate virtual and system users at the same time
using auth method testing. Just assign a priority to each method and go
down the list. First match wins.

The courier programs have very well designed auth modules that use this
technique.


> 
>>     After all, vpopmail has the capability to place domains ANYWHERE on
>>     the filesystem for quota restriction purposes.
> 
> If you only have virtual users, make VIRTUAL_TEST something that will
> always be true, such as ".", or even "".


Thanks. I wouldn't have thought of that.

However, I still think it can be simplified a bit.


> 
>>     However, since we provide auth services via POP3, this isn't exactly
>>     black and white. But we still have to run the stub program for
>>     virtual users, right? Perhaps we could set a session var based on
>>     whether or not we had to run a stub script...
> 
> No, because the program must run the stub before it can access a
> session file.


This can be worked around with state variables and such. It's not that big
of a deal, but it'll probably require some work.


> 
>> 2.) If we MUST keep the VIRTUAL_TEST var, please default to using a
>> one-time
>>     config variable like "vpopmail_home", and incorporate it like this:
>> 
>>     VIRTUAL_TEST = "^%(vpopmail_home)sdomains/"
> 
> That's a clever idea.  I could probably do something similar to that.
> 
>>     Same goes for Vpop and VpopBin in defaults.ini:
>> 
>>     VPop               = %(vpopmail_home)s
>>     VPopBin            = %(vpopmail_home)s/bin
> 
> Perhaps.  No promises


ok. Would the above work as-is?


> 
>> 3.) Please add a short note to:
>> 
>>     http://tmda.sourceforge.net/tmda-cgi/virtual.html
>> 
>>     Explaining that in addition to stub scripts and virtual user
>>     settings, vpopmail users should definately specify:
>> 
>>     --program-auth /home/vpopmail/bin/vchkpw
> 
> I think most systems with virtual users use POP3 to do their
> authentication.  That's how I do it, at least.
> 
> Authentication methods are discussed at
> http://tmda.sourceforge.net/tmda-cgi/auth.html and the program
> authentication section even refers to vchkpw.


OK. Fair enough. My point was simply that I didn't put two and two
together and realize that I needed to specify vchkpw as well as
a stub. I think it could use clarification, and doing so might
lessen the number of questions like mine in the future.


> 
>>     In their configure statement, or the appropriate same during
>>     interactive configure. Also, I think adding some text explaining this
>>     _during_ interactive configure mode would be excellent as well.
> 
> In interactive mode, if you select program authentication, it then
> asks you:
> 
> What is the authentication command? (full path and args)
>  * For more details, see "config --help" option -p *
> 
>> 4.) It might be nice to chown the CGI to the vpopmail user during 'make
>> install'
>>     if our mode is 'single-user'. I just include this as a separate
>>     command after 'make install' personally, but it isn't immediately
>>     obvious that this is a problem, and it generally seems like something
>>     'make install' should do to me.
> 
> "make install" does do a chmod.  Check the Makefile.


I didn't say 'chmod'. I said 'chown'.


-- 
Jesse Guardiani, Systems Administrator
WingNET Internet Services,
P.O. Box 2605 // Cleveland, TN 37320-2605
423-559-LINK (v)  423-559-5145 (f)
http://www.wingnet.net


_____________________________________________
tmda-users mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-users

Reply via email to