You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Amlan Otta <am...@gmail.com> on 2018/04/24 09:13:06 UTC
[users@httpd] Re: users Digest 24 Apr 2018 08:36:39 -0000 Issue 5637
On Tue 24 Apr, 2018, 2:06 PM , <us...@httpd.apache.org> wrote:
>
> users Digest 24 Apr 2018 08:36:39 -0000 Issue 5637
>
> Topics (messages 117311 through 117313)
>
> Re: mod_ratelimit working by steps ?
> 117311 by: nerbrume.free.fr
>
> Re: mod_suexec with mod_userdir and fcgid (webapps in subdirs with
> separated user context)
> 117312 by: Jonas Meurer
> 117313 by: Luca Toscano
>
> Administrivia:
>
> ---------------------------------------------------------------------
> To post to the list, e-mail: users@httpd.apache.org
> To unsubscribe, e-mail: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-digest-help@httpd.apache.org
>
> ----------------------------------------------------------------------
>
>
>
>
> ---------- Forwarded message ----------
> From: nerbrume@free.fr
> To: users@httpd.apache.org
> Cc: Luca Toscano <to...@gmail.com>
> Bcc:
> Date: Sun, 22 Apr 2018 21:15:42 +0200
> Subject: Re: [users@httpd] mod_ratelimit working by steps ?
> Hi,
>
> > I created a 4MB file and rate limited its directory container in the
> > httpd's conf, and tested 8/20/30/etc.. settings as you suggested with
> > curl:
> >
> > curl http://localhost/test.txt > /dev/null (in this way I drop the
> > returned response but keep the curl's connection metadata summary).
> >
> > In every case I get the expected result (average Dload speed).
>
> Thanks a bunch for testing this, and confirming that something is wrong
> on my side.
> After more test, I'm pretty sure the problem come from a bad interaction
> between mod_ratelimit and mod_proxy.
> (sorry, I forgot to mention that the path I was trying to rate-limit is
> indeed a tomcat app behind mod_proxy).
>
> > Did you execute your performance tests in localhost? And also, did you
> > use another tool other than Firefox? I'd be curious to know your
> > results with curl executed in localhost.
>
> I've tried the following (Excerpts from my config at the end of this
> mail):
>
> 0) rate-limit on tomcat app proxified throught mod_proxy (previous mail)
> => rate-limit works by step, and does not limit anything if
> rate-limit > 40
> (tried on local with wget)
> 1) rate-limit on a true folder, served by apache :
> => rate-limit is working as expected
> 2) rate-limit on file served through python's SimpleHttpServer,
> proxified by mod_proxy
> => rate-limit works by step.
>
> In conclusion, tomcat is not at fault, since python's SimpleHttpServer
> also have a problem, and the trouble come from my reverse-proxy.
> In the case af a reverse proxy, I'm not sure which part of the
> connection get rate-limited ?
> Is that an known problem ?
> Or am I trying to do something totally bogus here ?
> Any ideas to achieve my goal ? (that is, limiting the bandwith used by
> the tomcat app)
>
> Thanks!
>
> N
>
> PS : for what it's worth, I've tried 1) with curl, and got the following
> error, wich seems to be related to the use of http2:
> curl: (56) Unexpected EOF
> wget is fine, though.
>
> PS2 : Excerpts from my config
> <Proxy *>
> Order deny,allow
> Allow from all
> </Proxy>
> SSLProxyEngine On
> SSLProxyCheckPeerCN Off
> SSLProxyCheckPeerName Off
> <Location /airsonic> # the tomcat app
> ProxyPreserveHost On
> ProxyPass http://127.0.0.1:12345/airsonic
> ProxyPassReverse http://127.0.0.1:12345/airsonic
> SetOutputFilter RATE_LIMIT
> SetEnv rate-limit 35
> </Location>
> <Location /test> # a true folder, served by apache
> SetOutputFilter RATE_LIMIT
> SetEnv rate-limit 50
> </Location>
> <Location /test2> # a python SimpleHttpServer
> ProxyPreserveHost On
> ProxyPass http://127.0.0.1:8000
> ProxyPassReverse http://127.0.0.1:8000
> SetOutputFilter RATE_LIMIT
> SetEnv
> </Location>
>
> > Thanks!
> >
> > Luca
> >
> > Links:
> > ------
> > [1]
> >
> https://webmasters.stackexchange.com/questions/101988/strange-behaviour-with-apache-mod-ratelimit
>
>
>
>
> ---------- Forwarded message ----------
> From: Jonas Meurer <jo...@freesources.org>
> To: users@httpd.apache.org
> Cc:
> Bcc:
> Date: Mon, 23 Apr 2018 15:40:30 +0200
> Subject: Re: mod_suexec with mod_userdir and fcgid (webapps in subdirs
> with separated user context)
> Hello again,
>
> maybe my previous mail was to verbose, or maybe simply nobody has an
> idea. Still I'd like to give it a second try:
>
> Do you have a good idea why php-cgi7.0 throws the following error when
> used with mod_fcgid, mod_usermod and mod_suexec?
>
> uid: (1002/webapp1) gid: (1002/webapp1) cmd: php-fcgi-starter cannot get
> docroot information (/var/www/webapp1)
>
> $ ls -al /var/www/webapp1
> drwxr-xr-x 9 root root 4096 Jun 29 2014 .
> drwxr-x--- 2 webapp1 webapp1 4096 Nov 7 15:14 php-fcgi
> drwxr-x--- 2 webapp1 webapp1 4096 Apr 11 2015 www
> [...]
>
> The same setup works perfectly fine without mod_usermod (i.e. when the
> whole VHost has a dedicated suexec user). Only with mod_usermod, we get
> this strange error.
>
> Cheers,
> jonas
>
> Am 15.04.2018 um 12:26 schrieb Jonas Meurer:
> > Hello list,
> >
> > I try to make web applications available in subfolders of one
> > VirtualHost, but each one in an isolated user context. All web apps are
> > PHP applications and I use mod_fcgid to run them.
> >
> > Unfortunately, SuexecUserGroup is not not allowed in Directory context,
> > which would be by far the simples solution.
> >
> > So to achieve my goal, I tried (and failed with) two different
> approaches:
> >
> > 1. Using mod_userdir together with mod_suexec
> > 2. ProxyPass to separate localhost vhosts for each app
> >
> > Since the first approach seems much cleaner and more straight forward to
> > me, I'd prefer that one.
> >
> > Maybe you have other suggestions on how to achieve my goal?
> >
> > ---
> >
> > Now to the problem I ran into with my first approach:
> >
> > I have UserDir enabled for system user 'webapp1' and the UserDir path
> > set to '/var/www/*/www' (see the VirtualHost config below). This works
> > as expected, I can access static content from within the UserDir.
> >
> > Additionally, I have fcgid configured for the UserDir and apparently the
> > php scripts are executed using suexec and php-cgi7.0. A suexec process
> > is spawned by user 'webapp1' when requesting a php file, but it
> > immediately turns into 'suexec <defunct>' (a zombie process).
> >
> > In the apache2 error log shows:
> >
> > uid: (1002/webapp1) gid: (1002/webapp1) cmd: php-fcgi-starter
> > cannot get docroot information (/var/www/webapp1)
> >
> > And the apache2 suexec log:
> >
> > [fcgid:warn] [pid 30884:tid 140484201527040] (104)Connection reset by
> > peer: [client 192.168.0.1:31937] mod_fcgid: error reading data from
> > FastCGI server
> > [core:error] [pid 30884:tid 140484201527040] [client 192.168.0.1:31937]
> > End of script output before headers: index.php
> >
> >
> > I double checked that all files under /var/www/webapp1 belong to
> > user+group 'webapp1' and that they're accessible. I even recursively set
> > world-readable permissions on the directory, which didn't change
> anything.
> >
> > Do you have a good idea on why running php-cgi7.0 through fcgi with
> > suexec and userdir results in this suexec error 'cannot get docroot
> > information'?
> >
> > Any hints and suggestions would be highly appreciated :)
> >
> > The VirtualHost config (my current take) is as follows:
> >
> > <VirtualHost *:443>
> > [...]
> > Userdir disabled
> > Userdir enabled webapp1
> > UserDir /var/www/*/www
> >
> > <IfModule fcgid_module>
> > <Directory /var/www/webapp1/www>
> > AddHandler fcgid-script .php
> > FCGIWrapper /var/www/webapp1/php-fcgi/php-fcgi-starter .php
> > Options +ExecCGI
> > </Directory>
> >
> > IPCConnectTimeout 20
> > IPCCommTimeout 60
> > FcgidBusyTimeout 60
> > MaxRequestLen 10485760
> > </IfModule>
> > </VirtualHost>
> >
> >
> > Looking forward to your responses.
> >
> > Kind regards,
> > jonas
> >
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Luca Toscano <to...@gmail.com>
> To: users@httpd.apache.org
> Cc:
> Bcc:
> Date: Tue, 24 Apr 2018 10:36:32 +0200
> Subject: Re: [users@httpd] Re: mod_suexec with mod_userdir and fcgid
> (webapps in subdirs with separated user context)
> Hi Jonas,
>
> 2018-04-23 15:40 GMT+02:00 Jonas Meurer <jo...@freesources.org>:
>
>> Hello again,
>>
>> maybe my previous mail was to verbose, or maybe simply nobody has an
>> idea. Still I'd like to give it a second try:
>>
>> Do you have a good idea why php-cgi7.0 throws the following error when
>> used with mod_fcgid, mod_usermod and mod_suexec?
>>
>> uid: (1002/webapp1) gid: (1002/webapp1) cmd: php-fcgi-starter cannot get
>> docroot information (/var/www/webapp1)
>>
>> $ ls -al /var/www/webapp1
>> drwxr-xr-x 9 root root 4096 Jun 29 2014 .
>> drwxr-x--- 2 webapp1 webapp1 4096 Nov 7 15:14 php-fcgi
>> drwxr-x--- 2 webapp1 webapp1 4096 Apr 11 2015 www
>> [...]
>>
>> The same setup works perfectly fine without mod_usermod (i.e. when the
>> whole VHost has a dedicated suexec user). Only with mod_usermod, we get
>> this strange error.
>
>
> Premise: I am super ignorant about suexec & C, but this snippet of code in
> suexec.c seems to be the one returning the error:
>
> if (getcwd(cwd, AP_MAXPATH) == NULL) {
> log_err("cannot get current working directory\n");
> exit(111);
> }
>
> if (userdir) {
> if (((chdir(target_homedir)) != 0) ||
> ((chdir(AP_USERDIR_SUFFIX)) != 0) ||
> ((getcwd(dwd, AP_MAXPATH)) == NULL) ||
> ((chdir(cwd)) != 0)) {
> log_err("cannot get docroot information (%s)\n",
> target_homedir);
> exit(112);
> }
> }
>
> As far as I can see, this is what it tries to do:
>
> - save the current working dir to 'cwd'
> - change dir to "target_homedir", that should be in this
> case /var/www/webapp1
> - change dir to AP_USERDIR_SUFFIX, that if not re-defined should be
> "public_html" (#define AP_USERDIR_SUFFIX "public_html" in suexec.h)
> - set the variable 'dwd' (docroot working directory) to the above
> - change dir back to cwd (current working directory)
>
> So I'd try to add a public_html directory and see how it goes.
>
> Hope that helps!
>
> Luca
>