[courier-users] I need working nginx configuration for webadmin

[Rosario]

If anyone could point me to the working nginx configuration for courier
webadmin.

I have managed to run it over SSL connection, it complained that it is
not over SSL, due to Fast CGI in background, and I have solved that with
the file unsecure OK in ../webadmin/unsecureok

However, I get now only first page, if I click on any option I get
forbidden, it is probably due to nginx not being configured well.

If anyone has working nginx configuration for courier webadmin, let me
know.

Rosario

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
courier-users mailing list
courie...@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

[Sam Varshavchik]

Rosario writes:

> If anyone could point me to the working nginx configuration for courier
> webadmin.
>
> I have managed to run it over SSL connection, it complained that it is
> not over SSL, due to Fast CGI in background, and I have solved that with
> the file unsecure OK in ../webadmin/unsecureok
>
> However, I get now only first page, if I click on any option I get
> forbidden, it is probably due to nginx not being configured well.
>
> If anyone has working nginx configuration for courier webadmin, let me
> know.

You shouldn't need anything more than a working CGI setup.

The very first Google hit on "nginx cgi" is an nginx.com URL that comes
complete with a wrapper script.

[Rosario]

I can run courierwebadmin to see the front page, but not to see any
other like courierwebadmin/00something

I did search Google and my other CGI script works or multiple scripts
work, but they are different then webadmin script.

[Sam Varshavchik]

Rosario writes:

> I can run courierwebadmin to see the front page, but not to see any
> other like courierwebadmin/00something
>
> I did search Google and my other CGI script works or multiple scripts
> work, but they are different then webadmin script.

Did you try using the wrapper script from nginx.com, and the associated
configuration settings?

Looked to me like it will work, but I don't use nginx. Other links that came
up from a Google search also had a few other suggestions.

[Alexei Batyr']

Rosario writes:

> I can run courierwebadmin to see the front page, but not to see any
> other like courierwebadmin/00something
>
> I did search Google and my other CGI script works or multiple scripts
> work, but they are different then webadmin script.
>

I've realized that most reliable way to execute CGI scripts in nginx
environment is proxying to apache with following minimal config:
-----
LoadModule mpm_worker_module libexec/apache24/mod_mpm_worker.so
LoadModule alias_module libexec/apache24/mod_alias.so
LoadModule authz_core_module libexec/apache24/mod_authz_core.so
LoadModule cgi_module libexec/apache24/mod_cgi.so
LoadModule dir_module libexec/apache24/mod_dir.so
LoadModule remoteip_module libexec/apache24/mod_remoteip.so
LoadModule unixd_module libexec/apache24/mod_unixd.so

ServerRoot "/usr/local"
Listen 127.0.0.1:8000
User nobody
Group nobody
TimeOut 300
ServerAdmin ...
DocumentRoot "/usr/local/www"
ErrorLog syslog
LogLevel error
ScriptAlias /cgi-bin/ "/usr/local/www/cgi-bin/"
DefaultType text/plain
EnableSendfile on
RemoteIPHeader X-Real-IP

Include etc/apache24/extra/httpd-default.conf

<Directory "/usr/local/www">
AllowOverride None
</Directory>
-----
Related nginx config:
-----
location /cgi-bin {
proxy_pass http://localhost:8000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_buffering off;
}
-----
--
Alexei.

--
Alexei.

[Matus UHLAR - fantomas]

On 01.05.16 01:58, Alexei Batyr' wrote:
>I've realized that most reliable way to execute CGI scripts in nginx
>environment is proxying to apache with following minimal config:

does THIS make sense?

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"Two words: Windows survives." - Craig Mundie, Microsoft senior strategist
"So does syphillis. Good thing we have penicillin." - Matthew Alton

[Stefan Hornburg (Racke)]

On 05/01/2016 09:37 AM, Matus UHLAR - fantomas wrote:
> On 01.05.16 01:58, Alexei Batyr' wrote:
>> I've realized that most reliable way to execute CGI scripts in nginx
>> environment is proxying to apache with following minimal config:
>
> does THIS make sense?
>

Not to me ... usually you use FastCGI on Nginx.

Regards
Racke

--
Please visit our 3rd Perl Dancer Conference 2016 in Vienna: https://www.perl.dance/.

[Alexei Batyr']

Matus UHLAR - fantomas writes:

> On 01.05.16 01:58, Alexei Batyr' wrote:
>>I've realized that most reliable way to execute CGI scripts in nginx
>>environment is proxying to apache with following minimal config:
>
> does THIS make sense?
>

It wouldn't make sense if Courier web part (Sqwebmail, Webadmin) could work
as FastCGI scripts. I'm using this strange construction exclusively for
running Sqwebmail on the server with nginx frontend and PHP as FastCGI
server. Perl kludge suggested on nginx site for runnig CGI scripts as
FastCGI much worse than time-honoured apache.

--
Alexei.

[Matus UHLAR - fantomas]

>> On 01.05.16 01:58, Alexei Batyr' wrote:
>>>I've realized that most reliable way to execute CGI scripts in nginx
>>>environment is proxying to apache with following minimal config:

>> does THIS make sense?

On 01.05.16 17:10, Alexei Batyr' wrote:
>It wouldn't make sense if Courier web part (Sqwebmail, Webadmin) could work
>as FastCGI scripts. I'm using this strange construction exclusively for
>running Sqwebmail on the server with nginx frontend and PHP as FastCGI
>server. Perl kludge suggested on nginx site for runnig CGI scripts as
>FastCGI much worse than time-honoured apache.

but what's the point of proxying it from apache? Apache can run cgi (and
fastcgi, even php as module, not as fastcgi, so php should be even faster
under apache) too, you don't need nginx.

if you want nginx, what's the point of apache proxying?

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.

BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease

[Alexei Batyr']

Matus UHLAR - fantomas writes:

>>> On 01.05.16 01:58, Alexei Batyr' wrote:
>>>>I've realized that most reliable way to execute CGI scripts in nginx
>>>>environment is proxying to apache with following minimal config:
>
>>> does THIS make sense?
>
> On 01.05.16 17:10, Alexei Batyr' wrote:
>>It wouldn't make sense if Courier web part (Sqwebmail, Webadmin) could work
>>as FastCGI scripts. I'm using this strange construction exclusively for
>>running Sqwebmail on the server with nginx frontend and PHP as FastCGI
>>server. Perl kludge suggested on nginx site for runnig CGI scripts as
>>FastCGI much worse than time-honoured apache.
>
> but what's the point of proxying it from apache? Apache can run cgi (and
> fastcgi, even php as module, not as fastcgi, so php should be even faster
> under apache) too, you don't need nginx.

I'm proxying nginx to apache, not vice versa. As I said, nginx is main
frontend, apache backend is used only as CGI interface. A few years ago,
when I've configured that server, nginx+php-fastcgi was significantly
faster then apache+mod_php and even apache+php-fastcgi. For most recent
versions of apache picture probably changed, but nobody will pay me for
migrating couple dozens of production sites to apache.

--
Alexei.

[Mark Constable]

On 05/02/16 03:16, Matus UHLAR - fantomas wrote:
>> Perl kludge suggested on nginx site for runnig CGI scripts as
>> FastCGI much worse than time-honoured apache.
>
> but what's the point of proxying it from apache? Apache can run cgi
> (and fastcgi, even php as module, not as fastcgi, so php should be
> even faster under apache) too, you don't need nginx.
>

> if you want nginx, what's the point of apache proxying?

A couple of more points, apache with libapache2-mod-php requires the
slower pre-forking version of apache and because that module is always
loaded for every access it makes sense to use the much faster and
lighter nginx frontend to deliver static files and then proxy to apache
just for php. Also, a lot of web apps expect, or are easier, to use a
.htaccess file which nginx does not handle.

As for running webadmin, and perhaps sqwebmail, the simplest solution
is to use a dedicated instance of lighthttpd on another port (assuming
nginx is already in use on 80/443).

[Matus UHLAR - fantomas]

>On 05/02/16 03:16, Matus UHLAR - fantomas wrote:
>>> Perl kludge suggested on nginx site for runnig CGI scripts as
>>> FastCGI much worse than time-honoured apache.
>>
>> but what's the point of proxying it from apache? Apache can run cgi
>> (and fastcgi, even php as module, not as fastcgi, so php should be
>> even faster under apache) too, you don't need nginx.
>>
>> if you want nginx, what's the point of apache proxying?

On 02.05.16 13:27, Mark Constable wrote:
>A couple of more points, apache with libapache2-mod-php requires the
>slower pre-forking version of apache and because that module is always
>loaded for every access

is it? iiuc it's only loaded on apache reload...
(unless you tune MaxRequestsPerChild/2.2 or MaxConnectionsPerChild/2.4)

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.

One OS to rule them all, One OS to find them,
One OS to bring them all and into darkness bind them

[Mark Constable]

On 05/02/16 19:19, Matus UHLAR - fantomas wrote:
>> A couple of more points, apache with libapache2-mod-php requires
>> the slower pre-forking version of apache and because that module is
>> always loaded for every access
>
> is it? iiuc it's only loaded on apache reload... (unless you tune
> MaxRequestsPerChild/2.2 or MaxConnectionsPerChild/2.4)

I meant the entire libapache2-mod-php module is loaded into ram for
every access to every file no matter if it's a non-php static file
or a php file. Each apache process (+ mod-php) is from 20Mb to 100Mb
regardless of whether it's about to parse a PHP script or not. A nginx
instance is about ~9Mb and delivers a static file up to twice as fast
as apache with mod-php (according to ab testing I did 1/2 dozen years
ago).

I find php-fpm usually runs at 3Mb to 30Mb but sometimes up to 100Mb
for Wordpress with massively complex themes and plugins. So nginx +
php-fpm generally uses less ram than apache + mod-php for PHP scripts
but up to 10 times less ram for static files (css, js, images) and
static files (until cached) far outnumber PHP script access.

[Matus UHLAR - fantomas]

>On 05/02/16 19:19, Matus UHLAR - fantomas wrote:
>>> A couple of more points, apache with libapache2-mod-php requires
>>> the slower pre-forking version of apache and because that module is
>>> always loaded for every access

>> is it? iiuc it's only loaded on apache reload... (unless you tune
>> MaxRequestsPerChild/2.2 or MaxConnectionsPerChild/2.4)

On 02.05.16 19:57, Mark Constable wrote:
>I meant the entire libapache2-mod-php module is loaded into ram for
>every access to every file no matter if it's a non-php static file
>or a php file.

and I mean, apache process loads all modules at startup time, which means
that mod-php is loaded only at the start or reconfigure time, and all child
processes are created by forking only when servers are spawned at:
- startup
- increating number of server processes
- restarting after MaxRequestsPerChild or MaxConnectionsPerChild hit.

(note that forking is quite cheap operation on linux, don't know other OSes)
This is quite different than what you are saying.

> Each apache process (+ mod-php) is from 20Mb to 100Mb
>regardless of whether it's about to parse a PHP script or not. A nginx
>instance is about ~9Mb and delivers a static file up to twice as fast
>as apache with mod-php (according to ab testing I did 1/2 dozen years
>ago).
>
>I find php-fpm usually runs at 3Mb to 30Mb but sometimes up to 100Mb
>for Wordpress with massively complex themes and plugins. So nginx +
>php-fpm generally uses less ram than apache + mod-php for PHP scripts
>but up to 10 times less ram for static files (css, js, images) and
>static files (until cached) far outnumber PHP script access.

I'm not telling that your claims about speed are wrong, just that your
claims about how mod_php works apparently are...

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.

- Have you got anything without Spam in it?
- Well, there's Spam egg sausage and Spam, that's not got much Spam in it.

[Mark Constable]

On 05/02/16 20:14, Matus UHLAR - fantomas wrote:
> and I mean, apache process loads all modules at startup time, which
> means that mod-php is loaded only at the start or reconfigure time,
> and all child processes are created by forking only when servers are
> spawned at:
> - startup
> - increating number of server processes
> - restarting after MaxRequestsPerChild or MaxConnectionsPerChild hit.

And my point is that every apache process includes the full mod-php
interpreter regardless of whether that process is about to handle a
PHP script or a static file. It's not the startup time that is the
issue (for me) but that a PHP interpreter is included within each
process even if it is not going to be used to interpret a PHP script
(in the case of delivering a non-php static resource).

[davyweb...@gmail.com]

Op zaterdag 30 april 2016 11:33:04 UTC schreef Rosario:

> If anyone could point me to the working nginx configuration for courier
> webadmin.

Use a config like this:

location /cgi-bin/courierwebadmin {
include fastcgi_params;
fastcgi_split_path_info ^(/cgi-bin/courierwebadmin)(.*)$;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param SCRIPT_FILENAME /usr/lib/courier/courier/webmail/webadmin;
fastcgi_pass unix:/var/run/fcgiwrap.socket;
}

[Paul Vixie]

On Friday, April 17, 2020 at 8:37:42 AM UTC-7, davyweb...@gmail.com wrote:
> Op zaterdag 30 april 2016 11:33:04 UTC schreef Rosario:
> > If anyone could point me to the working nginx configuration for courier
> > webadmin.
> Use a config like this:

> ...
> fastcgi_pass unix:/var/run/fcgiwrap.socket;
> }

i was not able to get fcgiwrap to work for this, it blacklists several environment variables (PATH_INFO, etc) which sqwebmail needs. i'd love to see sqwebmail able to act as its own fastcgi listener, or even better, to act as a microservice so that proxy_pass would work. has anybody done additional work on this since 2016?

[Jan H.]

> i was not able to get fcgiwrap to work for this, it blacklists several environment variables (PATH_INFO, etc) which sqwebmail needs.

The blacklist only applies to variables fcgiwrap inherits from its environment. It doesn't mess with variables passed through the fastcgi socket. Try running this minimal example program through fcgiwrap:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
if (getenv("PATH_INFO"))
printf("Content-Type: text/plain\n\nPATH_INFO is %s\n", getenv("PATH_INFO"));
else
puts("Content-Type: text/plain\nStatus: 500 Internal Server Error\n\nUh-oh");

return 0;
}