Michael Krieger wrote: > It is indeed possible to use wrappers as you do, but this adds overhead > to every invocation of [insert progran here] which I'd rather avoid. > > How much overhead do you think executing a shell script and an internal > call to test implements? How often do you think IMAP connections are > made? Think of all the calls that already wrap around shells. Think of > how many exec calls (or their variiants in this case) are made to run > tcpserver, authentication programs, bincimap-up, and bincimapd? Why not > modify bincimap or bincimap-up to do the same thing on invocation and > provide the patch to the bincimap folks instead- a likely better way to > do things. > > Just don't get caught up in the hype as to how much faster c programs > are- when the shell is probably kept in memory, and the stat calls used > by test are cached, this isn't a huge performance hit- especially for a > connection like imap that is more persistant. > > I run about 10K+ users on bincimap through this linkwrapper and > generally see almost no load... I know that's vague, but I've never > benchmarked the use with or without a simple shell script.
All valid points, and I do take the point that the actual "real-world" hit might not be too bad. However, I see that doing "stuff" when you create users logically belongs with the program that creates users - vpopmail in this case. So to my "perfectionist" mind, I'd rather make vpopmail do this once when the user is added than checking for it every time the account is accessed for the lifetime of the account. > It's incredibly easy to add or modify functionality to qpsmtpd > because of the plugin hooks that are built-in. > > I'd suggest that: > 1. qpsmtpd lacks many plugins and doesn't seem to have a lot of support > in the community, along with the various plugin methods to qmail-smtp > d. I'm sure there's a good chunk of overhead in there as well, not to > mention difficulties like plugin ordering, etc. qpsmtpd functionality is almost all implemented as plugins. If you've not checked it out it's really worth a look. > 2. vpopmail manages qmail users and delivers mail. I'm weary of making > it even more of a kitchen sink to start adding plugins and management > functions that would likely be used by a small number. It's still > changing considerably between major releases. I agree with your sentiment, but vpopmail already creates the directory into which the mail is delivered. All I'm suggesting is that there is some degree of flexibility in the structure of that mail directory. > Anyway, I've solved the IMAPdir issue a different way (see separate > post). > > Saw it- thumbs up. Glad you solved your issue. Yeah, should have done it this way in the first place but I went looking for a (generic|perfect|correct ) solution. All working nicely now though. R.
