Re: [qmailtoaster] http service survey
+1 Nginx does have a minor drawback: Monitoring it with stock modules included in most setups is horrid. You have no upstream status information (which nodes failed, why did they fail, how long etc) nor any serious graphable information. It's been an issue at work for is for a while and has led us to run a custom nginx package with additional modules to get at least some rudimentary monitoring included. I would like to see a clean separation of frontend and backend code. Something that allows me to install a QMT host without any dependencies to front end packages (and vice versa where possible). I am a fan of clean roles assigned to machines and this may be a good step in the right direction. Cheers, Sebastian On 28.05.2014, at 05:07, Eric Shubert e...@shubes.net wrote: For everyone, how do you feel about changing QMT's apache dependencies to nginx? (Long term - this isn't going to happen over night) Note, http related .qt. packages are not part of the 'core' (operational) QMT components. A QMT host can function fine without any of these packages (e.g. qmailadmin, vqadmin, isoqlog, etc.). I'm not suggesting we drop http functionality. Far from it. I'm merely suggesting that nginx might be (is likely to be) more suitable in the future as a http server component for QMT than apache is. nginx is very efficient, and much easier to configure. The ease of configuration may likely (imo) pay dividends down the road. I already run SquirrelMail on its own (virtual) PHP server, augmented by an nginx (virtual) (reverse-proxy) web server. It works quite nicely, and separates the webmail component entirely from the base mail server. I'm under the impression that fastcgi can run qmailadmin and vqadmin (C stuff) as well as PHP code. If that's indeed the case, other QMT components could be adapted in a similar manner. Of course, separate hosts wouldn't be required. It would just be an option which allows separation (and scaling in a big way). So what are your thoughts? Thanks. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
RE: [qmailtoaster] http service survey
Personally I would prefer to stick with Apache or (ideally) to make the package work with both depending on which one is available. Nginx is great, but most shops I work with use Apache and know it well. It works and they don't want to switch. -Erik From: Eric Shubert e...@shubes.net Sent: Wednesday, May 28, 2014 5:07 AM To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] http service survey For everyone, how do you feel about changing QMT's apache dependencies to nginx? (Long term - this isn't going to happen over night) Note, http related .qt. packages are not part of the 'core' (operational) QMT components. A QMT host can function fine without any of these packages (e.g. qmailadmin, vqadmin, isoqlog, etc.). I'm not suggesting we drop http functionality. Far from it. I'm merely suggesting that nginx might be (is likely to be) more suitable in the future as a http server component for QMT than apache is. nginx is very efficient, and much easier to configure. The ease of configuration may likely (imo) pay dividends down the road. I already run SquirrelMail on its own (virtual) PHP server, augmented by an nginx (virtual) (reverse-proxy) web server. It works quite nicely, and separates the webmail component entirely from the base mail server. I'm under the impression that fastcgi can run qmailadmin and vqadmin (C stuff) as well as PHP code. If that's indeed the case, other QMT components could be adapted in a similar manner. Of course, separate hosts wouldn't be required. It would just be an option which allows separation (and scaling in a big way). So what are your thoughts? Thanks. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] http service survey
On May 28, 2014, at 3:17 AM, Erik Wramner erik.wram...@codemint.com wrote: Personally I would prefer to stick with Apache or (ideally) to make the package work with both depending on which one is available. Nginx is great, but most shops I work with use Apache and know it well. It works and they don't want to switch. +1 to this. For (reasons) I need to run Apache on my mail server. It would be awkward for me if nginx was also on there and contending for ownership of port 80. I guess this is a roundabout way of saying that if we switch to nginx, can the setup be arranged so that nginx can easily/optionally be run on an alternate port where it can coexist rather than conflict with Apache? One other, peripherally related thing: I am following with interest the development of Mailpile (https://www.mailpile.is/) which I think may become a popular option. It's in early alpha currently, so it's perhaps too soon to make any decisions based on what it might or might not do. But I hope that any decisions made about the future of qmailtoaster won't rule out the possibility of a Mailpile install. Angus
