> it's out. i'm running it now. > > wait- rick, did you forget to announce it on this list, or is it not > for general consumption yet? i downloaded it from sourceforge and it > works fine, including the onchange stuff. > Huh - so it is. Posted 12/30/06. Maybe I misunderstood the last message about what patches would be in it, but I definitely don't remember an "official" announcement. I'll have to grab it and check it out.
>> - I'm a little busy working on a couple of >> other things, like releasing my Uber-Mega-qmail patch set (the >> patches are >> done, but documenting them takes time... :), but I'll add this to the >> queue. Since the patch isn't going into 5.4.18 anyway, there's time. > > so you've got a qmail mega-patch as well? i'm starting to wonder who > DOESN'T have one anymore... > > mine: http://qmail.jms1.net/patches/combined-details.shtml > I'm quite familiar with it - I've even used one of the small patches on your site (the date-localtime patch), although I'm not sure if you wrote it or not (there's no credit in the file itself, and I've seen it credited to 2 different people out there, neither of them you. But nevertheless qmail.org links the patch on your site, even if the link is stale these days...). We each have our own philosophies about what we want and how we implement it. I've also written about 25% of the patches I use, either from scratch or as updates to existing patches (since often updating to a new version of someone else's patch can require restarting the whole patch process...) >> Alternatively, vpopmail could just write to the pipe itself, but the >> onauth script is a cleaner method. Basically, I'd send 4 tokens to >> the >> service: user, domain, IP, timestamp. It can handle the rest. > > if you want to split user and domain apart like that, sure... my > preference would be to keep them together, as one opaque item- that > way if you have a hybrid mixed system of vpopmail and system > accounts, the API doesn't need to change to support "no such thing as > a domain"... and if you do need them separately, it's easy enough to > split the one datum on the "@" character. > I believe vchkpw already splits them, but I'm not sure. It's easy enough to pass them in whatever form vchkpw has them natively. > as for vpopmail writing the pipe directly... that was suggested for > the onchange patch as well- and shot down very quickly, by myself and > by tom. the argument is/was that most people understand how shell > scripts work, but very few people understand named pipes- and while > anybody can write a shell script, not everybody will be doing > anything complex enough to need to involve pipes. some people may do > things with unix sockets, TCP or UDP sockets, semaphores, mutices > (plural of "mutex"), or any number of other things... running a shell > script leaves people with the ability to choose their own IPC > mechanism, rather than forcing them to run a named pipe watcher > service. it's all about flexibility. > Makes sense - I was already leaning that way anyway. >> It should be able to run as vpopmail, since the tcp.smtp.cdb file >> is owned >> by vpopmail, and that's what gets used by qmail-smtpd. vchkpw runs as >> vpopmail, and it handles it all now, so I don't see a need for root >> access >> here. > > not everybody runs their entire mail system as the vpopmail user (in > fact i don't run ANY of it as the vpopmail user- for clients who use > vchkpw to handle SMTP AUTH, i have the vchkpw binary setuid/setgid to > the vpopmail user, but that's it.) > They don't need to - if they're using vpopmail's cdb file, it needs to be writable by vpopmail and just readable by whatever user(s) tcpserver is running as. And if the onchange script is called by vchkpw, it'll run as vpopmail since it's a child process. Now, you could choose to run the daemon as a different user for other reasons, and just give vpopmail write access to the pipe, but if you're duplicating the current onauth behavior for updating the tcp.smtp.cdb, theres no good reason not to run as vpopmail that I can see. > and since other programs (qmailadmin, vpopmaild, or some as-yet- > unknown program in the future) might also end up calling this > function, i think it's safer to not assume anything about what userid > will be running the "onauth" script itself. if the script is > signalling a service, obviously run the service as the userid which > makes the most sense for the situation- but the "onauth" script > itself needs to be executable by any userid on the system. > I'm not sure I see the onauth system being used as generically as the onchange one - I definitely see how onchange needs to be available for a variety of functions, but onauth probably is a niche function, albeit an important one... >> I'd appreciate the help on the daemon, although just giving me the >> sampe >> code of your daemon would probably be good enough. I have a very long >> history of looking at other peoples' code and taking just the parts >> I need >> for whatever I happen to be working on - it's how I learned C in >> the first >> place 15 years ago... :) > > it's actually written in perl, believe it or not... but it should > translate to C easily enough, if you're so inclined. > Perl is good for daemons, bad for small client processes that run and terminate. I can handle perl too :) > i can see keeping a hash in memory, the IP pointing to an expire > time, and every time an IP authenticates, the expire time is replaced > with "now plus 30 minutes"... it would periodically build a new list, > leaving out any expired IPs, and if the new list of IPs (not their > timeout values) is different from the old list, it would write out > new files and call "tcprules" as needed. part of writing out new > files would be writing a cache to the disk, so that if the service > stops, it can read the cache back into memory and know the status of > the authorized IPs. > > http://qmail.jms1.net/scripts/qmail-updater.shtml > > or maybe keep a directory full of "IP as the filename" empty files, > with the mtime of each file holding the last time they auth'd... and > a reaper process would periodically delete any files which haven't > been touched in more than 20 minutes (or whatever timeout you want to > use)... and a third script would be called whenever an IP which > didn't already exist is added, or whenever the reaper deletes > something, and that third script would rebuild the cdb files... this > is basically how my greylisting program keeps track of things, > although it uses both the "atime" and "mtime" timestamps (to hold the > "first" and "most recent" time each IP appeared.) > > http://qmail.jms1.net/scripts/jgreylist.shtml > I prefer not to do it on the FS, for performance reasons (among other things). But you have some good ideas - I'll check out your code. > now i'm really interested in seeing where you take this... again, > feel free to bounce questions or ideas off of me. > Thanks - it's a little overwhelming to get so many kudos from established players when I'm still so new here (even if I have been dabbling for a long time). Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
