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
> -
>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
>>
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
>
>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
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
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
>> 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
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,
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
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
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
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
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.
Rosario
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
14 matches
Mail list logo