Re: [qmailadmin] qmailadmin and vpopmail+mysql inconsistency
On Tue, 2003-03-25 at 00:30, Michael Bowe wrote: snip Obviously a workaround to force a creation of the user's maildir after inserting them into the MySQL database, but this is not a dead simple thing to do in some circumstances (eg we are inserting records into the MySQL from an ASP scrip running on a Windows 2000 server w/IIS5). I suppose we could send them some sort of welcome email, or launch a POP3 auth via perl but such methods seem like a bit of a kludge. IMHO, manually inserting records into MySQL is a bit of a kludge. It would probably be better to create a flat file of users / passwords, and let perl loop through that and pass the data to vadduser. Just add to your ASP script a simple open port 100, and send user credentials? I think it's just USER and PASS. www# telnet localhost 110 Trying 127.0.0.1... Connected to localhost.vfemail.net. Escape character is '^]'. +OK Hello there. USER [EMAIL PROTECTED] +OK Password required. PASS mypassword +OK logged in. I'm not an ASP guy, but at worst write out a temp file of all 'new' users from that 'session', and run another script against that list when your ASP is done. I really don't what what you're doing (sign up script? why not vqregister?), so what I've said may not work for you. Heck, that's even better. Just install vqregister, and fill in the form fields with your asp. Rick
Re: [qmailadmin] qmailadmin and vpopmail+mysql inconsistency
Rick Romero wrote: IMHO, manually inserting records into MySQL is a bit of a kludge. It would probably be better to create a flat file of users / passwords, and let perl loop through that and pass the data to vadduser. Ok Rick, let me get this straight -- you think doing a single insert into the MySQL database to add a user (which makes the user active *NOW*) is a kluge, but writing the info out to a flat file and periodically have a perl program loop through it and call vadduser isn't? Personally, I think it's the other way around. Inserting them into the MySQL database directly is clean and elegant, and activates the user immedetily. Your flat file and perl method is at *best* run every minute (the min. interval of cron), possibly longer. You have to worry about file locking (don't want to copy the file out from under a current processes that's writting to it), and you've got a plain text file sitting around with passwords in them. I really think you got it backwards :) Rick Dave I will have to agree with Rick. Not using the supplied API is a kludge. The correct method would be to call the C API. I believe Rick was just offering one possible solution to using the API, however you can either use supplied programs or the C function calls, your choice. Thanks, Brian
Re: [qmailadmin] qmailadmin and vpopmail+mysql inconsistency
Brian Kolaci wrote: Brain, I'm on the list. There's no need to send me a copy and the list. Just reply to the list please. I get enough mail as is, I don't need two copies of the same message :) Rick Romero wrote: IMHO, manually inserting records into MySQL is a bit of a kludge. It would probably be better to create a flat file of users / passwords, and let perl loop through that and pass the data to vadduser. Ok Rick, let me get this straight -- you think doing a single insert into the MySQL database to add a user (which makes the user active *NOW*) is a kluge, but writing the info out to a flat file and periodically have a perl program loop through it and call vadduser isn't? Personally, I think it's the other way around. Inserting them into the MySQL database directly is clean and elegant, and activates the user immedetily. Your flat file and perl method is at *best* run every minute (the min. interval of cron), possibly longer. You have to worry about file locking (don't want to copy the file out from under a current processes that's writting to it), and you've got a plain text file sitting around with passwords in them. I really think you got it backwards :)Rick Dave I will have to agree with Rick. Not using the supplied API is a kludge. I disagree with you. I don't think it's a kludge, especially when support for just such a thing was added way back in 4.9.4. From the ChangeLog: 4.9.4 Sep 22 - modify safestring.c sstrncmp to return correct value if comparing a subset of two longer strings - vchkpw will autocreate a user directory if thier path value in the authentication structure is empty Or better yet, this entry from the ChangeLog for 4.9.3: 4.9.3 Sep 18 - fix up vclose is_open login in vmysql.c vsybase.c voracle.c - vdelivermail will auto create a users directory if thier directory value in thier authentication structure is blank. This can be used by sql based systems, or ldap systems. Users can be created and inserted into the database, and if their path value is left blank, vpopmail will use the bigdir directory layout algorythm to create a directory and update the authentication database. So, users can be created by just adding them to the database and leaving thier directory path blank. I'm sorry, inserting users directly into MySQL isn't a kludge in my book :) The correct method would be to call the C API. There is no one true way :) I believe Rick was just offering one possible solution to using the API, however you can either use supplied programs or the C function calls, your choice. Or you can use the auto creation features that were adding in 4.9.3 for just such a thing, which is what the original poster was doing. The problem is that qmailadmin isn't using the API, and calling the auto creation routines when a user tries to log in and the directory is blank in the authentication database. Thanks, Brian Dave
Re: [qmailadmin] qmailadmin and vpopmail+mysql inconsistency
Rick Romero wrote: On Tue, 2003-03-25 at 09:16, Dave Weiner wrote: Rick Romero wrote: IMHO, manually inserting records into MySQL is a bit of a kludge. It would probably be better to create a flat file of users / passwords, and let perl loop through that and pass the data to vadduser. Ok Rick, let me get this straight -- you think doing a single insert into the MySQL database to add a user (which makes the user active *NOW*) is a kluge, but writing the info out to a flat file and periodically have a perl program loop through it and call vadduser isn't? No no no.. It's all a kludge ;) The original post was written as if No it's not. The ChangeLog for 4.9.3 specifically mentions inserting directly into the database as a valid method, as specific support was added for just that. writing direct to MySQL was 'normal', while doing an automatic POP auth Inserting directly to MySQL *is* 'normal'. The technique is documented in the ChangeLog. Doing a POP auth is also 'normal' was a kludge. I was merely suggesting it wasn't any more of a kludge than already existed. IMHO, kludge ~= not using the tools given to you (for whatever reason). But the original poster *is* using the tools given to him. The problem is qmailadmin isn't using the API The first kludge isn't working 100%, hence the original post. :) Sorry, I don't think it's a kludge. And it is working. What's not working is qmailadmin. Personally, I think it's the other way around. Inserting them into the MySQL database directly is clean and elegant, and activates the user immedetily. Your flat file and perl method is at *best* run every minute (the min. interval of cron), possibly longer. You have to worry about file locking (don't want to copy the file out from under a current processes that's writting to it), and you've got a plain text file sitting around with passwords in them. I really think you got it backwards :) The flat file suggestion was based on my initial assumption that this was already done as a batch process. I don't think so -- why else insert directly into the MySQL table? Why didn't you quote the vqregister suggestion? It seems like you're thinking it's a real-time process (which I wasn't for the perl suggestion), and vqregister would fit the kludge better... Because I was only addressing you refering to inserting into MySQL as a kludge :) I don't use vqregister that way, and I don't know what the original poster is actually doing.. sooo I just gave multiple suggestions. so nya! :P Rick Dave
Re: [qmailadmin] qmailadmin and vpopmail+mysql inconsistency
Brain, I'm on the list. There's no need to send me a copy and the list. Just reply to the list please. I get enough mail as is, I don't need two copies of the same message :) When you hit reply, it sends it to you, not the list. I just added the list as a CC before. snip At any rate, the support added to auto-create was added as a fail-safe recovery method, should the directory get corrupted or deleted by mistake. It appears you're exploiting a recovery mechanism. This may be fine for your implementation, however its most likely to come back and haunt you in the future. Going behind the scenes to insert directly into the database is a kludge. For many users, the database isn't an option. The repository can be many backing stores, one of which may be MySQL. If you don't like the supplied methods to create user accounts, you're welcome to add your own. However keep in mind that other things go on in the API like validation and such, and it allows a central place to implement any other side effects that may be required at account creation time. This would most likely be the place to enforce the vlimits recently added to the vpopmail library. Bypassing the intended API is a kludge. Brian
Re: [qmailadmin] qmailadmin and vpopmail+mysql inconsistency
Brian Kolaci wrote: Brain, I'm on the list. There's no need to send me a copy and the list. Just reply to the list please. I get enough mail as is, I don't need two copies of the same message :) When you hit reply, it sends it to you, not the list. I just added the list as a CC before. That's because this list is set for reply to poster. snip At any rate, the support added to auto-create was added as a fail-safe recovery method, should the directory Did you actually read the change log entry?? How do you get fail-safe recovery method from vdelivermail will auto create a users directory if thier directory value in thier authentication structure is blank. This can be used by sql based systems, or ldap systems. Users can be created and inserted into the database, and if their path value is left blank, vpopmail will use the bigdir directory layout algorythm to create a directory and update the authentication database. So, users can be created by just adding them to the database and leaving thier directory path blank. The key part, in case you missed it, is Users can be created and inserted into the database, and if their path value is left blank, vpopmail will use the bigdir directory layout algorythm to create a directory and update the authentication database. So, users can be created by just adding them to the database and leaving thier directory path blank. That sure doesn't look like a fail-safe recovery method to me. That looks like inserting directly into the database for user creation was specifically designed in. get corrupted or deleted by mistake. It appears you're exploiting a recovery mechanism. This may be fine for Nope, read above. your implementation, however its most likely to come back and haunt you in the future. Don't think so. See above. Going behind the scenes to insert directly into the database is a kludge. For many users, the database isn't an option. The repository can be many backing stores, one of which may be MySQL. And the authors spefically put in support to do exactly that. Again, see above. If you don't like the supplied methods to create user accounts, you're welcome to add your own. However keep But I am using a supplied method. See above. in mind that other things go on in the API like validation and such, and it allows a central place to implement any other side effects that may be required at account creation time. This would most likely be the place to enforce the vlimits recently added to the vpopmail library. Bypassing the intended API is a kludge. I agree with you there. I just don't see that I'm bypassing the intended API. I'm using a method documented and suggested by the authors. Brian Dave
Re: [qmailadmin] qmailadmin and vpopmail+mysql inconsistency
QmailAdmin doesn't deliver mail, the 'backup' doesn't get called. No, but it should follow the same methods that vpopmail does. If the directory field is blank in the authentication backend, when that user is accessed via qmailadmin, it should auto create the directory. What would happen if vdelivermail didn't autocreate the directory? Would it be stuck in queue? Would it bounce? That's more serious an error than what qmailadmin does. To me, if you're replicating vadduser, you should be doing what vadduser does. I don't have a problem with vqregister or vqadmin, they does what vadduser and vadddomain, do. shrug The docs must be wrong grin Rick
Re: [qmailadmin] qmailadmin and vpopmail+mysql inconsistency
Did you actually read the change log entry?? How do you get fail-safe recovery method from vdelivermail will auto create a users directory if thier directory value in thier authentication structure is blank. This can be used by sql based systems, or ldap systems. Users can be created and inserted into the database, and if their path value is left blank, vpopmail will use the bigdir directory layout algorythm to create a directory and update the authentication database. So, users can be created by just adding them to the database and leaving thier directory path blank. The key part, in case you missed it, is Users can be created and inserted into the database, and if their path value is left blank, vpopmail will use the bigdir directory layout algorythm to create a directory and update the authentication database. So, users can be created by just adding them to the database and leaving thier directory path blank. That sure doesn't look like a fail-safe recovery method to me. That looks like inserting directly into the database for user creation was specifically designed in. Yes, however when that was done, there was never a concept of enforcing limits back then. Justin just submitted a patch to actually enforce these limits at, yes, the API level where it belongs. This *will* break if you insert into a backing store directly. I still believe: Bypassing the supplied API is a kludge. (A raw datastore is *not* an API, you lose control over validation and many other features if you don't have a single thread of control over these. I don't believe the original author understood the implications of that statement and probably didn't do a request for comments on the list prior to that). I'll agree that qmailadmin should also have some recovery code built into it, however I still disagree that anyone should ever insert directly into a datastore. Brian
Re: [qmailadmin] qmailadmin and vpopmail+mysql inconsistency
I strongly disagree, and I'm doing it for a email service I run for a non-profit. The potential user enters the username they want, I check to make sure there is no other user or alias with that name, I reserve that username for 30 min, get the credit card number from them, processes it, and if the charge goes through, I insert a record with the username, domain, crypted and clear text password and quota. The account is now available for immediate use. So explain to me exactly what validation and other features I've lost control over? THRITY minutes? An auth should only take 9 seconds including dial time, and never more than 15 seconds. See, you're just doing everything wrong ;) (j/k! I'm just being difficult :P) Rick
Re: [qmailadmin] qmailadmin and vpopmail+mysql inconsistency
Rick Romero wrote: I strongly disagree, and I'm doing it for a email service I run for a non-profit. The potential user enters the username they want, I check to make sure there is no other user or alias with that name, I reserve that username for 30 min, get the credit card number from them, processes it, and if the charge goes through, I insert a record with the username, domain, crypted and clear text password and quota. The account is now available for immediate use. So explain to me exactly what validation and other features I've lost control over? THRITY minutes? An auth should only take 9 seconds including dial time, and never more than 15 seconds. Yes, the credit card auth should only take that long. But that's only after the user clicks the submit button. I'm keeping the average user in mind. Oh, wait, my wallet is upstairs, let me go get it. Honey, while you're up here, can you give me a hand with the kids?. The next thing you know, it's 20 min. later before the click the button to do the credit card processing :) And if it's been more than 30 min. when the click the button, they get bounced back to the pick a username page. See, you're just doing everything wrong ;) (j/k! I'm just being difficult :P) :-p~~~ Rick Dave
Re: [qmailadmin] qmailadmin and vpopmail+mysql inconsistency
Brian Kolaci wrote: Yes, however when that was done, there was never a concept of enforcing limits back then. Justin just submitted Again, I think you're wrong. As early as 4.1 there was quotas of some sort. I believe the limits you're refering to those that are specified in the .qmailadmin-limits file, which are a function of qmailadmin to limit how many accounts, etc, a postmaster can create. Not anymore. This has changed with 5.3. The .qmailadmin-limits is now extended into vpopmail and is now enforced at the domain level as well as setting default quotas for users. The old method allowed you to set a single site-wide HARD_QUOTA. a patch to actually enforce these limits at, yes, the API level where it belongs. This *will* break if you insert into a backing store directly. Exactly what limits are you refering to? quotas, permissions (limiting what a user can do), etc. I still believe: Bypassing the supplied API is a kludge. (A raw datastore is *not* an API, you lose control over validation and many other features if you don't have a single thread of control over these. I don't believe the original author understood the implications of that statement and probably didn't do a request for comments on the list prior to that). Ken, as the original author, could you please enlighten us with your though process instead of us guessing? I'll agree that qmailadmin should also have some recovery code built into it, however I still disagree that anyone should ever insert directly into a datastore. I strongly disagree, and I'm doing it for a email service I run for a non-profit. The potential user enters the username they want, I check to make sure there is no other user or alias with that name, I reserve that username for 30 min, get the credit card number from them, processes it, and if the charge goes through, I insert a record with the username, domain, crypted and clear text password and quota. The account is now available for immediate use. So explain to me exactly what validation and other features I've lost control over? Brian Dave
Re: [qmailadmin] qmailadmin and vpopmail+mysql inconsistency
Brian Kolaci wrote: Brian Kolaci wrote: Yes, however when that was done, there was never a concept of enforcing limits back then. Justin just submitted Again, I think you're wrong. As early as 4.1 there was quotas of some sort. I believe the limits you're refering to those that are specified in the .qmailadmin-limits file, which are a function of qmailadmin to limit how many accounts, etc, a postmaster can create. Not anymore. This has changed with 5.3. The .qmailadmin-limits is now extended into vpopmail and is now enforced at the domain level as well as setting default quotas for users. The old method allowed you to set a single site-wide HARD_QUOTA. And how does that apply to adding a user? a patch to actually enforce these limits at, yes, the API level where it belongs. This *will* break if you insert into a backing store directly. Exactly what limits are you refering to? quotas, permissions (limiting what a user can do), etc. I set the quota, and it's very easy to limit what a user can do as well, if you understand how it works. I'm not saying you don't have to write your own logic for some of this, but inserting a record into the mysql database to add a user is not only an acceptable method, but one supported by the developer. See Ken's post to the list. Dave
Re: [qmailadmin] qmailadmin and vpopmail+mysql inconsistency
Not anymore. This has changed with 5.3. The .qmailadmin-limits is now extended into vpopmail and is now enforced at the domain level as well as setting default quotas for users. The old method allowed you to set a single site-wide HARD_QUOTA. And how does that apply to adding a user? The limits specify what the default quota should be, and what the default permissions should be. When adding the user, the domain limits should be checked to make sure they're even allowed to add another user. Note that these are just new features. I'm also confident that additional features will be added. Using a set API call to do the validation and manipulation of the backing store makes enhancements smooth and easy. a patch to actually enforce these limits at, yes, the API level where it belongs. This *will* break if you insert into a backing store directly. Exactly what limits are you refering to? quotas, permissions (limiting what a user can do), etc. I set the quota, and it's very easy to limit what a user can do as well, if you understand how it works. I'm not saying you don't have to write your own logic for some of this, but inserting a record into the mysql database to add a user is not only an acceptable method, but one supported by the developer. See Ken's post to the list. So if/when features are added to the vpopmail package you may or may not get them since you bypassed the API. So then if you think you like an added feature, you'll have to write it each time rather than just benefit from it with an upgrade. The only thing I'm trying to say (which was the same from the start), is that I believe inserting the data directly into the backing store is a kludge. I didn't say it wouldn't work. Thanks, Brian
[qmailadmin] qmailadmin and vpopmail+mysql inconsistency
When you are running a MySQL backend for vpopmail, it is possible to create users simply by adding them directly to the relevant table in MySQL The user's maildir doesn't get created, but this is not usually a problem, because as soon as a message arrives, or as soon as the user attempts to authenticate, vpopmail will run make_user_dir() and create the maildir on-the-fly. I just noticed a problem with qmailadmin though for these sorts of users who don't have a maildir : If you login to the domain as postmaster, you can see the user's entry, and you can even go in and moduser their settings. So that all works fine. However, if you login to qmailadmin as that user rather than as the postmaster, you immediately get presented an error like this : file permission error /Maildir/1048573247.qw Obviously a workaround to force a creation of the user's maildir after inserting them into the MySQL database, but this is not a dead simple thing to do in some circumstances (eg we are inserting records into the MySQL from an ASP scrip running on a Windows 2000 server w/IIS5). I suppose we could send them some sort of welcome email, or launch a POP3 auth via perl but such methods seem like a bit of a kludge. Considering that qmailadmin allows the postmaster to moduser these types of users-without-maildirs, is there any chance that the coding can be changed so that the enduser is also able to get in via qmailadmin without encountering a nasty error? Michael Bowe (B.App.Sc) Managing Director - Pipeline Internet 96 Pakington Street, Geelong West. VIC. 3218 Tel (03) 5229 7643 Fax (03) 5229 0282 Mobile 0419 242 136 http://www.pipeline.com.au/
