On Wed, 8 Sep 2004, Jesse Guardiani wrote: > On Wednesday 08 September 2004 11:19 am, Chris Ess wrote: [behold, the power of mail scissors! snip snip]
> > Have you considered.... > > > > 1. A VPN between the two? > > solves encryption, but not persistence. Also, that's a rather heavy-weight > solution. I didn't say it was a clean or nice solution, did I? ^_^ This was to deal with connecting the two servers in my mind. I realized afterwards that this wouldn't be necessary. It's been a long week already (and I had Monday off too). > > 2. Using an on-demand connection method rather than a persistent method? > > Trying to avoid it. Our CSRs see the billing server pause while the hook > executes to provision a service. I want to keep that pause time to a minimum. That depends on if a scripted SSH connection or whatever you use takes a long time to execute. When I used it, the Net::SSH perl module is pretty fast and added negligible time. > > 3. Just connecting to a dedicated socket or service rather than SSH? > > Not secure, and how would that work? I thought vpopmail's only manipulation > system is either SQL or command line based... It would work however you want it to. This suggestion would require building your own methods (or finding something someone else has done). You could make it as secure or as insecure as you like. You might also want to look at the vpopmail daemon in development. (Which reminds me that I need to subscribe to that list.) > > 4. The security issues inherent in connecting your billing server to your > > mailserver? > > Sure. People do it all the time, right? It's not my favorite idea and not one I would implement myself if I had a choice -- but, then again, I'm very used to the idea of the accounting and technical departments being separate and us techs not getting access to the accounting systems or data. > > To keep this topic vaguely vpopmail-related, have you considered keeping > > all of the necessary vpopmail information (or at least most of it) in a > > MySQL database or some other separate data repository and having something > > on your billing server update that? > > It's been suggested. I'm not happy with that solution though. I'd rather keep > it command line based. Okay. Then you're pretty much chained to the SSH solution unless you want to craft another one. > > (Or, alternatively, why not run the > > MySQL database on your billing server if you go that route? > > Kills scalability. Bad solution. I suggested this because this would create the illusion of persistence. I'd much rather run it on a different server altogether. I don't know if I'd say it kills scalability though. You can run a qmail/vpopmail server cluster based around a MySQL database without too much of a problem. Sincerely, Chris Ess System Administrator / CDTT (Certified Duct Tape Technician)
