mod_fcgid - cannot get authorizer process to be started
The mod_fcgid page says to ask on dev I assume that this is the right place to ask. I'm using mod_fcgid from svn with HTTPD 2.2. I want to use a fast CGI authorizer to allow me to control access based on my rules. The authorizer needs to be a long running process - never exits. I know that the fcgid code is noticing the directive because I can change the filename and see the error message from the sources. But I'm at a lose as to the required to get this configuration to actually call my code. mod_fcgid is not starting up the authorizer process. I have the following fcgid specific lines in my httpd.conf file: httpd.conf ... LoadModule fcgid_module modules/mod_fcgid.so ... Listen *:9000 Order allow,deny Allow from all AuthType Digest AuthName "Manager System" Require valid-user AuthGroupFile /home/bscott/Work/httpd-fcgid-test/auth/http.group AuthUserFile /home/bscott/Work/httpd-fcgid-test/auth/http.passwd FastCgiAuthorizer /home/bscott/wc/svn/NTB-Next/onelan/DSM/Sources/WebUserInterface/bin/Authorizer #+ HTTP auth file Order allow,deny Allow from all AuthType Digest AuthName "Manager System" Require valid-user AuthGroupFile /home/bscott/Work/httpd-fcgid-test/auth/http.group AuthUserFile /home/bscott/Work/httpd-fcgid-test/auth/http.passwd #- HTTP auth file #FCGID --- Barry - The official User-To-User support forum of the Apache HTTP Server Project. See http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org " from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: mod_fcgid - cannot get authorizer process to be started
Jeff Trawick wrote: On Tue, Sep 29, 2009 at 8:18 AM, Barry Scott <mailto:barry.sc...@onelan.co.uk>> wrote: The mod_fcgid page says to ask on dev I assume that this is the right place to ask. I'm using mod_fcgid from svn with HTTPD 2.2. I want to use a fast CGI authorizer to allow me to control access based on my rules. The authorizer needs to be a long running process - never exits. I know that the fcgid code is noticing the directive because I can change the filename and see the error message from the sources. But I'm at a lose as to the required to get this configuration to actually call my code. mod_fcgid is not starting up the authorizer process. I have the following fcgid specific lines in my httpd.conf file: httpd.conf ... LoadModule fcgid_module modules/mod_fcgid.so ... Listen *:9000 Order allow,deny Allow from all AuthType Digest Did you really mean Digest authentication instead of Basic authentication? mod_fcgid only supports Basic, AFAICT. /* Get the user password */ if ((res = ap_get_basic_auth_pw(r, &password)) != OK) return res; I don't want to be an authenticator, I want to be a authorizer. Authorizer has no need of passwords right. Barry
Re: mod_fcgid - cannot get authorizer process to be started
Jeff Trawick wrote: On Tue, Sep 29, 2009 at 11:26 AM, Barry Scott mailto:barry.sc...@onelan.co.uk>> wrote: Jeff Trawick wrote: On Tue, Sep 29, 2009 at 8:18 AM, Barry Scott mailto:barry.sc...@onelan.co.uk> <mailto:barry.sc...@onelan.co.uk <mailto:barry.sc...@onelan.co.uk>>> wrote: The mod_fcgid page says to ask on dev I assume that this is the right place to ask. I'm using mod_fcgid from svn with HTTPD 2.2. I want to use a fast CGI authorizer to allow me to control access based on my rules. The authorizer needs to be a long running process - never exits. I know that the fcgid code is noticing the directive because I can change the filename and see the error message from the sources. But I'm at a lose as to the required to get this configuration to actually call my code. mod_fcgid is not starting up the authorizer process. I have the following fcgid specific lines in my httpd.conf file: httpd.conf ... LoadModule fcgid_module modules/mod_fcgid.so ... Listen *:9000 Order allow,deny Allow from all AuthType Digest Did you really mean Digest authentication instead of Basic authentication? mod_fcgid only supports Basic, AFAICT. /* Get the user password */ if ((res = ap_get_basic_auth_pw(r, &password)) != OK) return res; I don't want to be an authenticator, I want to be a authorizer. Authorizer has no need of passwords right. whoops :( yes your "require valid-user" implies that you don't need authorization; try "require valid-group" instead I want the users password checked and to only proceed if it is valid. I also want to run the fcgi Authorizer to check that the URL being access is allowed according to the logic in my Authorizer code. To that end I have the following: Order allow,deny Allow from all # Use digest auth to check the username/password pair AuthType Digest AuthName "Manager System" # no one gets in without a valid username/password pair Require valid-user # Use these files to find the passwd and group information AuthGroupFile /home/bscott/Work/httpd-fcgid-test/auth/http.group AuthUserFile /home/bscott/Work/httpd-fcgid-test/auth/http.passwd # Run the Authorizer.sh to veto URL based on the username FastCgiAuthorizer /home/bscott/wc/svn/NTB-Next/onelan/DSM/Sources/WebUserInterface/bin/Authorizer.sh What triggers HTTPD to call the Authorizer.sh code? Surely not the commands that control authentication checks? I cannot find Require valid-group defined in the 2.2 docs. Do you mean I need to add: Require group nosuchgroup And that will cause the mod_authn_user (or what ever module) to try and match nosuchgroup. When it fails my Authenicator will be run to see if it can handle that directive? Isn't this module crying out for a directive like: Require fcgid-authenticater-user-is-valid Barry
Re: mod_fcgid - cannot get authorizer process to be started
Barry Scott wrote: Jeff Trawick wrote: On Tue, Sep 29, 2009 at 11:26 AM, Barry Scott mailto:barry.sc...@onelan.co.uk>> wrote: Jeff Trawick wrote: On Tue, Sep 29, 2009 at 8:18 AM, Barry Scott mailto:barry.sc...@onelan.co.uk> <mailto:barry.sc...@onelan.co.uk <mailto:barry.sc...@onelan.co.uk>>> wrote: The mod_fcgid page says to ask on dev I assume that this is the right place to ask. I'm using mod_fcgid from svn with HTTPD 2.2. I want to use a fast CGI authorizer to allow me to control access based on my rules. The authorizer needs to be a long running process - never exits. I know that the fcgid code is noticing the directive because I can change the filename and see the error message from the sources. But I'm at a lose as to the required to get this configuration to actually call my code. mod_fcgid is not starting up the authorizer process. I have the following fcgid specific lines in my httpd.conf file: httpd.conf ... LoadModule fcgid_module modules/mod_fcgid.so ... Listen *:9000 Order allow,deny Allow from all AuthType Digest Did you really mean Digest authentication instead of Basic authentication? mod_fcgid only supports Basic, AFAICT. /* Get the user password */ if ((res = ap_get_basic_auth_pw(r, &password)) != OK) return res; I don't want to be an authenticator, I want to be a authorizer. Authorizer has no need of passwords right. whoops :( yes your "require valid-user" implies that you don't need authorization; try "require valid-group" instead I want the users password checked and to only proceed if it is valid. I also want to run the fcgi Authorizer to check that the URL being access is allowed according to the logic in my Authorizer code. To that end I have the following: Order allow,deny Allow from all # Use digest auth to check the username/password pair AuthType Digest AuthName "Manager System" # no one gets in without a valid username/password pair Require valid-user # Use these files to find the passwd and group information AuthGroupFile /home/bscott/Work/httpd-fcgid-test/auth/http.group AuthUserFile /home/bscott/Work/httpd-fcgid-test/auth/http.passwd # Run the Authorizer.sh to veto URL based on the username FastCgiAuthorizer /home/bscott/wc/svn/NTB-Next/onelan/DSM/Sources/WebUserInterface/bin/Authorizer.sh What triggers HTTPD to call the Authorizer.sh code? Surely not the commands that control authentication checks? I cannot find Require valid-group defined in the 2.2 docs. Do you mean I need to add: Require group nosuchgroup This does not work... And that will cause the mod_authn_user (or what ever module) to try and match nosuchgroup. When it fails my Authenicator will be run to see if it can handle that directive? Isn't this module crying out for a directive like: Require fcgid-authenticater-user-is-valid Barry Barry
Re: mod_fcgid - cannot get authorizer process to be started
At this point let me ask this: Is it possible with the current code to ever have the fcgid Authorizer called? If it is not possible I'm willing to try and code the missing pieces, with a little help being pointed in the right direction. Barry
Re: [mod_fcgid] Cleaning up configuration directive names
Jeff Trawick wrote: I borrowed a few ideas from my friends and botched the rest personally: (omitting FCGID prefix) leave alone AccessChecker AccessCheckerAuthoritative Authenticator AuthenticatorAuthoritative Authorizer AuthorizerAuthoritative Wrapper MaxRequestsPerProcess PassHeader It may just be me but I keep up mis-speaking Authorizer for Authenticator. The Authorizer I would have called the AccessChecker if that was not already used for another phase of checking. Maybe PreAuthAccessCheck and PostAuthAccessCheck. Barry
Re: mod_fcgid - cannot get authorizer process to be started
Jeff Trawick wrote: On Wed, Sep 30, 2009 at 11:37 AM, Barry Scott mailto:barry.sc...@onelan.co.uk>> wrote: At this point let me ask this: Is it possible with the current code to ever have the fcgid Authorizer called? yes thanks for the confirmation and the example. I now have my Authorizer code and have the authentication happening. Listen *:9000 Order allow,deny Allow from all AuthType Digest AuthName "Manager System" AuthUserFile /home/bscott/Work/httpd-fcgid-test/auth/http.passwd Require onelan magic FastCgiAuthorizer /home/bscott/wc/svn/NTB-Next/onelan/DSM/Sources/WebUserInterface/bin/Authorizer.sh What I have learned about the code is this: * If any Require directive is present a 401 is returned if no credentials are sent * If any Require directive is present and credentials are present they are checked and the username is set in r. * If any Require directive is present and its not processed by any other authorizer the FastCgiAuthorizer is run It would be nice to reserve a Require entity name for use by fast CGI. The code as written today does not care if a Require entity name is processed by any module. Use of valid-group that sound officialbut is simply a Require entity name that no module supports. Barry
mod_fcgid - how to limit max processes per fcgi image
With mod_fastcgi I can to the following: FastCgiServer /usr/local/onelan/html/dsm.fcgi -processes 1 -idle-timeout 200 FastCgiServer /usr/local/onelan/html/dsmxml.fcgi -processes 1 -idle-timeout 30 Which creates two servers running waiting for request with only once instance of each. I cannot see how to achieve the same result with mod_fcgid. The promising MaxProcessCount seems to apply to all processes which is not what I want. I assume that if I set MaxProcessCount to 2 then I might get two dsm.fcgi processor of one of each. Is there a way to limit max processes per image? Barry
Re: mod_fcgid - how to limit max processes per fcgi image
Jeff Trawick wrote: On Thu, Oct 1, 2009 at 11:28 AM, Barry Scott <mailto:barry.sc...@onelan.co.uk>> wrote: With mod_fastcgi I can to the following: FastCgiServer /usr/local/onelan/html/dsm.fcgi -processes 1 -idle-timeout 200 FastCgiServer /usr/local/onelan/html/dsmxml.fcgi -processes 1 -idle-timeout 30 Which creates two servers running waiting for request with only once instance of each. I cannot see how to achieve the same result with mod_fcgid. The promising MaxProcessCount seems to apply to all processes which is not what I want. I assume that if I set MaxProcessCount to 2 then I might get two dsm.fcgi processor of one of each. Is there a way to limit max processes per image? close (and probably close enough) See http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgiddefaultmaxclassprocesscount That works for me. Thanks. I must say that I prefer the flexibility of mod_fastcgi in setting up the process limits / image. Barry
Re: [mod_fcgid proposal] defining processing options for particular commands
Jeff Trawick wrote: (instead of based on uri or vhost) FCGIDCommand /path/to/command IdleTimeout n MaxProcessLifetime n MinProcesses n MaxProcesses n MaxRequestsPerProcess n InitialEnv var[=val] ... (the names of these options follow my proposal for the names of existing directives ;) ) When a command is to be started by mod_fcgid, any options specified for the command on this directive override those defined for the uri, vhost, global, or the defaults. When a wrapper is used, it is that wrapper which must be specified on this directive. This directive is not required unless one or more options must be customized for a command. Initially this would be allowed only in global sections. InitialEnv can be repeated. Regarding *class*: Something is needed to disable or alter existing management of applications based on their class. Currently a class is limited to the processes started by the same command within the same vhost (except when ServerName isn't specified) with the same identity. One possibility is to provide an option to ignore the vhost name when managing the class (IgnoreVHost or ClassIsGlobal). Another possibility is to set the name of the class to be used in lieu of the virtual host (ClassName foo), which could be used to the same effect but might be more useful in the future when the process manager can see per-server configs (for existing directives as well as FCGIDCommand). None of this would affect the identity checks. (Processes with different uid/gid would never be considered to be in the same class.) This seems to offer all the features of mod_fastcgi process configuration and then go usefully beyond what mod_fastcgi does. Is it possible to also ask for the fcgi process to be started before any request arrive? Barry
Re: [mod_fcgid proposal] defining processing options for particular commands
Jeff Trawick wrote: On Fri, Oct 2, 2009 at 5:15 AM, Barry Scott <mailto:barry.sc...@onelan.co.uk>> wrote: Jeff Trawick wrote: (instead of based on uri or vhost) FCGIDCommand /path/to/command IdleTimeout n MaxProcessLifetime n MinProcesses n MaxProcesses n MaxRequestsPerProcess n InitialEnv var[=val] ... (the names of these options follow my proposal for the names of existing directives ;) ) When a command is to be started by mod_fcgid, any options specified for the command on this directive override those defined for the uri, vhost, global, or the defaults. When a wrapper is used, it is that wrapper which must be specified on this directive. This directive is not required unless one or more options must be customized for a command. Initially this would be allowed only in global sections. InitialEnv can be repeated. Regarding *class*: Something is needed to disable or alter existing management of applications based on their class. Currently a class is limited to the processes started by the same command within the same vhost (except when ServerName isn't specified) with the same identity. One possibility is to provide an option to ignore the vhost name when managing the class (IgnoreVHost or ClassIsGlobal). Another possibility is to set the name of the class to be used in lieu of the virtual host (ClassName foo), which could be used to the same effect but might be more useful in the future when the process manager can see per-server configs (for existing directives as well as FCGIDCommand). None of this would affect the identity checks. (Processes with different uid/gid would never be considered to be in the same class.) This seems to offer all the features of mod_fastcgi process configuration and then go usefully beyond what mod_fastcgi does. Thanks for looking. Does anyone else care to comment? Is it possible to also ask for the fcgi process to be started before any request arrive? Sure. I guess there could be some "InitialProcesses n" option on this directive. (If this appears to be forgotten, open a bug at https://issues.apache.org/bugzilla/ and set the severity to "enhancement." Product = Apache httpd-2, component = mod_fcgid.) BTW, do you need to pre-spawn just on general principle (don't want any initial delay), or is the on-demand spawning not aggressive enough, such that it takes too long to create an adequate number of application processes? We have a setup that can be CPU time and memory limited. Using Static servers allows the start up overhead to be suffer once at boot time. Our fast CGI servers are python processes that run very fast but can be slow to start, a few seconds, which is bad for response times. We have also had data collection going on in the fast CGI process, but we are moving away from that for a number of reasons. Barry
Re: [mod_fcgid proposal] defining processing options for particular commands
Ricardo Cantu wrote: On Friday 02 October 2009 11:10:25 am Barry Scott wrote: Jeff Trawick wrote: On Fri, Oct 2, 2009 at 5:15 AM, Barry Scott mailto:barry.sc...@onelan.co.uk>> wrote: Jeff Trawick wrote: (instead of based on uri or vhost) FCGIDCommand /path/to/command IdleTimeout n MaxProcessLifetime n MinProcesses n MaxProcesses n MaxRequestsPerProcess n InitialEnv var[=val] ... (the names of these options follow my proposal for the names of existing directives ;) ) When a command is to be started by mod_fcgid, any options specified for the command on this directive override those defined for the uri, vhost, global, or the defaults. When a wrapper is used, it is that wrapper which must be specified on this directive. This directive is not required unless one or more options must be customized for a command. Initially this would be allowed only in global sections. InitialEnv can be repeated. Regarding *class*: Something is needed to disable or alter existing management of applications based on their class. Currently a class is limited to the processes started by the same command within the same vhost (except when ServerName isn't specified) with the same identity. One possibility is to provide an option to ignore the vhost name when managing the class (IgnoreVHost or ClassIsGlobal). Another possibility is to set the name of the class to be used in lieu of the virtual host (ClassName foo), which could be used to the same effect but might be more useful in the future when the process manager can see per-server configs (for existing directives as well as FCGIDCommand). None of this would affect the identity checks. (Processes with different uid/gid would never be considered to be in the same class.) This seems to offer all the features of mod_fastcgi process configuration and then go usefully beyond what mod_fastcgi does. Thanks for looking. Does anyone else care to comment? Is it possible to also ask for the fcgi process to be started before any request arrive? Sure. I guess there could be some "InitialProcesses n" option on this directive. (If this appears to be forgotten, open a bug at https://issues.apache.org/bugzilla/ and set the severity to "enhancement." Product = Apache httpd-2, component = mod_fcgid.) BTW, do you need to pre-spawn just on general principle (don't want any initial delay), or is the on-demand spawning not aggressive enough, such that it takes too long to create an adequate number of application processes? We have a setup that can be CPU time and memory limited. Using Static servers allows the start up overhead to be suffer once at boot time. Our fast CGI servers are python processes that run very fast but can be slow to start, a few seconds, which is bad for response times. So do you want a fixed number of these python processes to be pre-spawned and for the pm to stay out of the way? (never start any more or terminate any that were pre-spawned) Fixed number pre-spawned, never terminated. If any die then restart them. Barry
Re: [VOTE] release httpd mod_fcgid-2.3.4
William A. Rowe, Jr. wrote: Thanks to Jeff's catch, we scuttled 2.3.3. We have yet another candidate for your consideration. Please fetch up the newly minted mod_fcgid-2.3.4.tar.gz (or .tar.bz2) or the win32/netware suitable package mod_fcgid-2.3.3-crlf.zip from: http://httpd.apache.org/dev/dist/mod_fcgid/ review, take it for a spin, and cast your choice [ ] -1 for any release of 2.3.4 (regressed from 2.3.1?) [ ] +1 to release as 2.3.4-beta [ ] +1 to release as 2.3.4-GA For getting started, http://svn.apache.org/repos/asf/httpd/mod_fcgid/tags/2.3.4/README-FCGID FYI if I had a vote: +1 Authorizer and normal page serving works in our application with 2.3.4. Barry
Re: [VOTE] release httpd mod_fcgid-2.3.4
William A. Rowe, Jr. wrote: > Thanks to Jeff's catch, we scuttled 2.3.3. We have yet another candidate > for your consideration. Please fetch up the newly minted mod_fcgid-2.3.4.tar.gz > (or .tar.bz2) or the win32/netware suitable package mod_fcgid-2.3.3-crlf.zip from: > > http://httpd.apache.org/dev/dist/mod_fcgid/ > > review, take it for a spin, and cast your choice > > [ ] -1 for any release of 2.3.4 (regressed from 2.3.1?) > [ ] +1 to release as 2.3.4-beta > [ ] +1 to release as 2.3.4-GA > > For getting started, > > http://svn.apache.org/repos/asf/httpd/mod_fcgid/tags/2.3.4/README-FCGID > > Further testing of our application has shown up a problem. With the following configuration we are seeing the request body of POST messages get stripped out if FcgidAuthorizer is used for Location /player. If we comment out the "Require onelan magic" the POSTs work. Have I misconfigured or is this a bug in mod_fcgid? Barry ... LoadModule fcgid_module modules/mod_fcgid.so FcgidCmdOptions /usr/local/onelan/html/dsmauthorizer.fcgi MaxProcesses 1 FcgidCmdOptions /usr/local/onelan/html/dsm.fcgi MaxProcesses 1 FcgidCmdOptions /usr/local/onelan/html/dsmxml.fcgi MaxProcesses 1 #+ Rewrite Web API Rules RewriteEngine on # security - deny TRACE and TRACK requests RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) RewriteRule .* - [F] #- Rewrite Web API Rules #+ Rewrite Web API Rules # make the URLs hide the use of dsm.fcgi RewriteRule ^/$ /dsm.fcgi [L] RewriteRule ^/(status|options|organisation|tools|setup|help)($|.*$) /dsm.fcgi/$1$2 [L] #- Rewrite Web API Rules #+ Rewrite XML API Rules # make the URLs hide the use of dsmxml.fcgi RewriteRule ^/(XML)($|.*$) /dsmxml.fcgi/$1$2 [L] #- Rewrite XML API Rules #+ Rewrite VPN ReWriteMap ntb_ip_address prg:/usr/local/onelan/dsm/bin/vpn_lookup_ip_address RewriteRule ^/player/(\d+)\.(.*) http://${ntb_ip_address:$1}:8080/player/$1.$2 [P] #- Rewrite VPN #+ Locations Web VPN API #+ HTTP auth file Order allow,deny Allow from all AuthType Digest AuthName "Manager System" AuthGroupFile /etc/onelan/common/http.group AuthUserFile /etc/onelan/common/http.passwd Require onelan magic #- HTTP auth file FcgidAuthorizer /usr/local/onelan/html/dsmauthorizer.fcgi
Re: [VOTE] release httpd mod_fcgid-2.3.4
Barry Scott wrote: William A. Rowe, Jr. wrote: > Thanks to Jeff's catch, we scuttled 2.3.3. We have yet another candidate > for your consideration. Please fetch up the newly minted mod_fcgid-2.3.4.tar.gz > (or .tar.bz2) or the win32/netware suitable package mod_fcgid-2.3.3-crlf.zip from: > > http://httpd.apache.org/dev/dist/mod_fcgid/ > > review, take it for a spin, and cast your choice > > [ ] -1 for any release of 2.3.4 (regressed from 2.3.1?) > [ ] +1 to release as 2.3.4-beta > [ ] +1 to release as 2.3.4-GA > > For getting started, > > http://svn.apache.org/repos/asf/httpd/mod_fcgid/tags/2.3.4/README-FCGID > > Further testing of our application has shown up a problem. With the following configuration we are seeing the request body of POST messages get stripped out if FcgidAuthorizer is used for Location /player. If we comment out the "Require onelan magic" the POSTs work. Have I misconfigured or is this a bug in mod_fcgid? Barry ... LoadModule fcgid_module modules/mod_fcgid.so FcgidCmdOptions /usr/local/onelan/html/dsmauthorizer.fcgi MaxProcesses 1 FcgidCmdOptions /usr/local/onelan/html/dsm.fcgi MaxProcesses 1 FcgidCmdOptions /usr/local/onelan/html/dsmxml.fcgi MaxProcesses 1 #+ Rewrite Web API Rules RewriteEngine on # security - deny TRACE and TRACK requests RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) RewriteRule .* - [F] #- Rewrite Web API Rules #+ Rewrite Web API Rules # make the URLs hide the use of dsm.fcgi RewriteRule ^/$ /dsm.fcgi [L] RewriteRule ^/(status|options|organisation|tools|setup|help)($|.*$) /dsm.fcgi/$1$2 [L] #- Rewrite Web API Rules #+ Rewrite XML API Rules # make the URLs hide the use of dsmxml.fcgi RewriteRule ^/(XML)($|.*$) /dsmxml.fcgi/$1$2 [L] #- Rewrite XML API Rules #+ Rewrite VPN ReWriteMap ntb_ip_address prg:/usr/local/onelan/dsm/bin/vpn_lookup_ip_address RewriteRule ^/player/(\d+)\.(.*) http://${ntb_ip_address:$1}:8080/player/$1.$2 [P] #- Rewrite VPN #+ Locations Web VPN API #+ HTTP auth file Order allow,deny Allow from all AuthType Digest AuthName "Manager System" AuthGroupFile /etc/onelan/common/http.group AuthUserFile /etc/onelan/common/http.passwd Require onelan magic #- HTTP auth file FcgidAuthorizer /usr/local/onelan/html/dsmauthorizer.fcgi Looking at bridge_request we see the code is reading the input buckets and feeding then to the Authorizer. It seems to us that: Either this must not happen if the fcgid is an authorizer or the buckets must be put back for whatever handles the POST to process. Barry
mod_fcgid POST broken if FcgiAuthorizer is run
This has been filed as issue https://issues.apache.org/bugzilla/show_bug.cgi?id=47973 Further testing of our application has shown up a problem using mod_fcgid 2.3.4. With the following configuration we are seeing the request body of POST messages get stripped out if FcgidAuthorizer is used for Location /player. If we comment out the "Require onelan magic" the POSTs work. Looking at bridge_request we see the code is reading the input buckets and feeding then to the Authorizer. It seems to us that: Either this must not happen if the fcgid is an authorizer or the buckets must be put back for whatever handles the POST to process. Barry ... LoadModule fcgid_module modules/mod_fcgid.so FcgidCmdOptions /usr/local/onelan/html/dsmauthorizer.fcgi MaxProcesses 1 FcgidCmdOptions /usr/local/onelan/html/dsm.fcgi MaxProcesses 1 FcgidCmdOptions /usr/local/onelan/html/dsmxml.fcgi MaxProcesses 1 #+ Rewrite Web API Rules RewriteEngine on # security - deny TRACE and TRACK requests RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) RewriteRule .* - [F] #- Rewrite Web API Rules #+ Rewrite Web API Rules # make the URLs hide the use of dsm.fcgi RewriteRule ^/$ /dsm.fcgi [L] RewriteRule ^/(status|options|organisation|tools|setup|help)($|.*$) /dsm.fcgi/$1$2 [L] #- Rewrite Web API Rules #+ Rewrite XML API Rules # make the URLs hide the use of dsmxml.fcgi RewriteRule ^/(XML)($|.*$) /dsmxml.fcgi/$1$2 [L] #- Rewrite XML API Rules #+ Rewrite VPN ReWriteMap ntb_ip_address prg:/usr/local/onelan/dsm/bin/vpn_lookup_ip_address RewriteRule ^/player/(\d+)\.(.*) http://${ntb_ip_address:$1}:8080/player/$1.$2 [P] #- Rewrite VPN #+ Locations Web VPN API #+ HTTP auth file Order allow,deny Allow from all AuthType Digest AuthName "Manager System" AuthGroupFile /etc/onelan/common/http.group AuthUserFile /etc/onelan/common/http.passwd Require onelan magic #- HTTP auth file FcgidAuthorizer /usr/local/onelan/html/dsmauthorizer.fcgi
Re: [VOTE] release httpd mod_fcgid-2.3.4
Jeff Trawick wrote: On Fri, Oct 9, 2009 at 11:00 AM, Barry Scott wrote: Barry Scott wrote: William A. Rowe, Jr. wrote: Thanks to Jeff's catch, we scuttled 2.3.3. We have yet another candidate for your consideration. Please fetch up the newly minted mod_fcgid-2.3.4.tar.gz (or .tar.bz2) or the win32/netware suitable package mod_fcgid-2.3.3-crlf.zip from: http://httpd.apache.org/dev/dist/mod_fcgid/ review, take it for a spin, and cast your choice [ ] -1 for any release of 2.3.4 (regressed from 2.3.1?) [ ] +1 to release as 2.3.4-beta [ ] +1 to release as 2.3.4-GA For getting started, http://svn.apache.org/repos/asf/httpd/mod_fcgid/tags/2.3.4/README-FCGID Further testing of our application has shown up a problem. With the following configuration we are seeing the request body of POST messages get stripped out if FcgidAuthorizer is used for Location /player. If we comment out the "Require onelan magic" the POSTs work. Have I misconfigured or is this a bug in mod_fcgid? Barry ... LoadModule fcgid_module modules/mod_fcgid.so FcgidCmdOptions /usr/local/onelan/html/dsmauthorizer.fcgi MaxProcesses 1 FcgidCmdOptions /usr/local/onelan/html/dsm.fcgi MaxProcesses 1 FcgidCmdOptions /usr/local/onelan/html/dsmxml.fcgi MaxProcesses 1 #+ Rewrite Web API Rules RewriteEngine on # security - deny TRACE and TRACK requests RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) RewriteRule .* - [F] #- Rewrite Web API Rules #+ Rewrite Web API Rules # make the URLs hide the use of dsm.fcgi RewriteRule ^/$ /dsm.fcgi [L] RewriteRule ^/(status|options|organisation|tools|setup|help)($|.*$) /dsm.fcgi/$1$2 [L] #- Rewrite Web API Rules #+ Rewrite XML API Rules # make the URLs hide the use of dsmxml.fcgi RewriteRule ^/(XML)($|.*$) /dsmxml.fcgi/$1$2 [L] #- Rewrite XML API Rules #+ Rewrite VPN ReWriteMap ntb_ip_address prg:/usr/local/onelan/dsm/bin/vpn_lookup_ip_address RewriteRule ^/player/(\d+)\.(.*) http://${ntb_ip_address:$1}:8080/player/$1.$2 [P] #- Rewrite VPN #+ Locations Web VPN API #+ HTTP auth file Order allow,deny Allow from all AuthType Digest AuthName "Manager System" AuthGroupFile /etc/onelan/common/http.group AuthUserFile /etc/onelan/common/http.passwd Require onelan magic #- HTTP auth file FcgidAuthorizer /usr/local/onelan/html/dsmauthorizer.fcgi Looking at bridge_request we see the code is reading the input buckets and feeding then to the Authorizer. It seems to us that: Either this must not happen if the fcgid is an authorizer or the buckets must be put back for whatever handles the POST to process. yeah; looks like bridge_request() doesn't look at role (FCGI_RESPONDER vs. FCGID_AUTHORIZER) (unless you think this is a regression, start a new thread and/or open a Bugzilla entry) 2.3.1 is broken the same way - I guess its a day one bug. Bug report and new thread started. Barry
Re: mod_fcgid POST broken if FcgiAuthorizer is run
Jeff Trawick wrote: On Fri, Oct 9, 2009 at 12:04 PM, Barry Scott wrote: This has been filed as issue https://issues.apache.org/bugzilla/show_bug.cgi?id=47973 Further testing of our application has shown up a problem using mod_fcgid 2.3.4. With the following configuration we are seeing the request body of POST messages get stripped out if FcgidAuthorizer is used for Location /player. If we comment out the "Require onelan magic" the POSTs work. Looking at bridge_request we see the code is reading the input buckets and feeding then to the Authorizer. It seems to us that: Either this must not happen if the fcgid is an authorizer right or the buckets must be put back for whatever handles the POST to process. Barry See patch attached to the PR. Thanks! No joy I get internal server error. But the patch below works for my case. Note: I don't understand the details of HTTPD to know if this patch is going to cause problems in other use cases, or indeed is only working by luck. One test that needs doing is to have a Responder and an Authorizer running for the same request. I'll see if I can do that test for you next week with the pieces I have. Index: modules/fcgid/fcgid_bridge.c === --- modules/fcgid/fcgid_bridge.c(revision 823573) +++ modules/fcgid/fcgid_bridge.c(working copy) @@ -470,6 +470,8 @@ return HTTP_INTERNAL_SERVER_ERROR; } +if (role == FCGI_RESPONDER) { + /* Stdin header and body */ /* XXX HACK: I have to read all the request into memory before sending it to fastcgi application server, this prevents slow clients from @@ -624,6 +626,7 @@ apr_brigade_destroy(input_brigade); } while (!seen_eos); +} /* end handling request body for responders */ /* Append an empty body stdin header */ stdin_request_header = apr_bucket_alloc(sizeof(FCGI_Header),
Re: mod_fcgid POST broken if FcgiAuthorizer is run
Jeff Trawick wrote: Variation number three: As with your patch, it remembers to add the eos bucket to the brigade of data sent to the app. As with my earlier patch, it doesn't send the trailing FCGI_STDIN record. In the spec (http://www.fastcgi.com/devkit/doc/fcgi-spec.html#S6.3), there's no mention of FCGI_STDIN for an FCGI_AUTHORIZER. I double-checked that mod_fcgid.c strips any CONTENT_LENGTH when calling the authorizer, which the spec does call for. I won't be shocked if it still fails for you; in that case I think we need to try to understand exactly why the trailing FCGI_STDIN record is needed. Our fastcgi code was expecting FCGI_STDIN. As you point out the spec does not need or allow FCGI_STDIN for an authorizer. I have fixed this bug in our fastcgi code. Now your original patch works for me now. Barry
Re: mod_fcgid POST broken if FcgiAuthorizer is run
Jeff Trawick wrote: On Fri, Oct 9, 2009 at 3:30 PM, Jeff Trawick wrote: ... Silly me. Chris's patch at http://people.apache.org/~chrisd/patches/mod_fcgid_auth/mod_fcgid-1auth-trunk.patch handles this, and it does send a trailing FCGI_STDIN record to an authorizer. Chris, AYT I wonder if other fastcgi implementation made the same bad assumption about FCGI_STDIN always being sent as ours did. FYI: The other change I made to our fastcgi was to parse out multiple values from FCGI_PARAMS records. mod_fastcgi sends one name-value pair in a FCGI_PARAMS record and sends as many FCGI_PARAMS records as it needs to to send the environment. Where as mod_fcgid sends multiple name-value pairs in asingle FCGI_PARAMS record. Barry
Re: mod_fcgid POST broken if FcgiAuthorizer is run
Jeff Trawick wrote: On Fri, Oct 9, 2009 at 1:26 PM, Barry Scott wrote: One test that needs doing is to have a Responder and an Authorizer running for the same request. I'll see if I can do that test for you next week with the pieces I have. Chris Darroch has a patch for that, which is a small part of http://people.apache.org/~chrisd/patches/mod_fcgid_auth/mod_fcgid-1auth-trunk.patch which applies to the old mod_fcgid 2.2 but which he has submitted here for inclusion. If you get stuck, look in there at some of the checks for role == responder, one or more of which are for the responder+authorizer-on-same-request issue. I'll hold off on testing this until Chris' patches are available in trunk. (I don't need this to work today, but I will need it later in the year expect) Barry
Re: [mod_fcgid] how about spin lock on share memory
pqf wrote: > Hi, all > I am Ryan Pan, who wrote the first version of mod_fcgid. > While I uesd mod_fastcgi(not mod_fcgid), one issue that bother me is: while > a fastcgi process(created by mod_fastcgi's process manager process)in a dead > loop, no one is respond to kick it out. So from time to time, some fastcgi > processes would eat up the system cpu resource. > So while I wrote mod_fcgid, I create a block of share memory to store the > fastcgi process pipe path and pid, then httpd can search this share memory to > get the an idle fastcgi process, and once the communication timout(which > usually mean the fastcgi process deadly running), httpd will kick out this > "corrupt" process. > However there is a new problem now, every time httpd search this share > memory, it will have to get a global mutex, which is a combination of process > lock an thread lock, is it(a mutex lock for search a free node in a node > list) too heavy? Maybe spin lock on share memory is a good idea in this case? > But spin lock is system dependented, and apr library doesn't have this > interface. > I thought about this idea since I wrote mod_fcgid, but I am not sure > whether it is a good idea, so any advice from you guys will be highly > appreciated. > I'd suggest use a mutex until the point that a problem is seen in practice. I doubt that the mutex will show up in any profiling of a request using mod_fcgid. Barry
mod_fcgid creates 1 more process then allowed
I have configure with a limit of 16 processes but have 17 running and logs claiming 16 running. Barry httpd.conf fcgid config lines: FcgidCmdOptions /usr/local/onelan/html/dsmauthorizer.fcgi MaxProcesses 16 IOTimeout 200 FcgidCmdOptions /usr/local/onelan/html/dsm.fcgi MaxProcesses 16 IOTimeout 200 FcgidCmdOptions /usr/local/onelan/html/dsmxml.fcgi MaxProcesses 16 IOTimeout 200 error_log has these messages repeating: [Wed Oct 21 11:50:28 2009] [notice] mod_fcgid: too many /usr/local/onelan/html/dsmxml.fcgi processes (current:16, max:16), skip the spawn request [Wed Oct 21 11:50:28 2009] [notice] mod_fcgid: too many /usr/local/onelan/html/dsmxml.fcgi processes (current:16, max:16), skip the spawn request "ps afx" show that there are 17 dsmxml.fcgi processes: 17935 ?Ss 0:00 /usr/sbin/httpd.worker 17937 ?S 0:00 \_ /usr/local/onelan/dsm/bin/vpn_lookup_ip_address 17938 ?S 0:00 \_ /usr/local/onelan/dsm/bin/vpn_lookup_ip_address 17939 ?S 0:01 \_ /usr/sbin/httpd.worker 18043 ?Sl 1:55 | \_ /usr/local/onelan/html/dsmxml.fcgi 18052 ?Sl 0:03 | \_ /usr/local/onelan/html/dsmxml.fcgi 18053 ?Sl 0:37 | \_ /usr/local/onelan/html/dsm.fcgi 18054 ?Sl 2:02 | \_ /usr/local/onelan/html/dsmxml.fcgi 18062 ?Sl 0:34 | \_ /usr/local/onelan/html/dsm.fcgi 18075 ?S 0:00 | \_ /usr/local/onelan/html/dsmauthorizer.fcgi 18076 ?S 0:00 | \_ /usr/local/onelan/html/dsmauthorizer.fcgi 18077 ?S 0:00 | \_ /usr/local/onelan/html/dsmauthorizer.fcgi 18084 ?Sl 1:00 | \_ /usr/local/onelan/html/dsmxml.fcgi 18085 ?Sl 0:53 | \_ /usr/local/onelan/html/dsmxml.fcgi 18090 ?Sl 1:04 | \_ /usr/local/onelan/html/dsmxml.fcgi 18091 ?Sl 1:07 | \_ /usr/local/onelan/html/dsmxml.fcgi 18096 ?Sl 1:07 | \_ /usr/local/onelan/html/dsmxml.fcgi 18098 ?Sl 0:57 | \_ /usr/local/onelan/html/dsmxml.fcgi 18099 ?Sl 1:05 | \_ /usr/local/onelan/html/dsmxml.fcgi 18153 ?Sl 0:31 | \_ /usr/local/onelan/html/dsmxml.fcgi 18156 ?Sl 0:32 | \_ /usr/local/onelan/html/dsmxml.fcgi 18170 ?Sl 0:25 | \_ /usr/local/onelan/html/dsmxml.fcgi 18178 ?Sl 0:22 | \_ /usr/local/onelan/html/dsmxml.fcgi 18186 ?Sl 0:19 | \_ /usr/local/onelan/html/dsmxml.fcgi 18187 ?Sl 0:20 | \_ /usr/local/onelan/html/dsmxml.fcgi 18192 ?Sl 0:18 | \_ /usr/local/onelan/html/dsmxml.fcgi 17940 ?Sl 0:20 \_ /usr/sbin/httpd.worker
Re: mod_fcgid creates 1 more process then allowed
Jeff Trawick wrote: On Wed, Oct 21, 2009 at 6:53 AM, Barry Scott wrote: I have configure with a limit of 16 processes but have 17 running and logs claiming 16 running. You should probably open a bug report for this. That's not to say that others haven't started thinking about it, but I haven't seen any activity. I wonder if a process is stuck in the error list or somewhere else... I think that it would be very cool to have a status handler to get the PM to report the contents of the several lists, and format appropriately ;) Filed: https://issues.apache.org/bugzilla/show_bug.cgi?id=48057 Barry
Re: [mod_fcgid] Feedback / Suggestions
Jeff Trawick wrote: On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank wrote: In the interim, is mod_fastcgi really that bad? mod_fastcgi is fine for handling GET/POST requests, but it fails to implement Authorization or Authenication. So yes mod_fastcgi is really bad. mod_fcgid is a very welcome as a supported httpd module. Barry
Re: [mod_fcgid] Feedback / Suggestions
Eric Covener wrote: On Thu, Dec 3, 2009 at 5:57 AM, Barry Scott wrote: Jeff Trawick wrote: On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank wrote: In the interim, is mod_fastcgi really that bad? mod_fastcgi is fine for handling GET/POST requests, but it fails to implement Authorization or Authenication. So yes mod_fastcgi is really bad. mod_fastcgi has supported this for many years: http://www.fastcgi.com/drupal/node/25#FastCgiAuthorizer http://www.fastcgi.com/drupal/node/25#FastCgiAuthenticator It does not work or I'd have used it. And I tried to make it work. There is a lot of missing code, compare to mod_fcgid implementation of the same. Barry
Re: [mod_fcgid] Feedback / Suggestions
Eric Covener wrote: On 12/4/09, Barry Scott wrote: Eric Covener wrote: On Thu, Dec 3, 2009 at 5:57 AM, Barry Scott wrote: Jeff Trawick wrote: On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank wrote: In the interim, is mod_fastcgi really that bad? mod_fastcgi is fine for handling GET/POST requests, but it fails to implement Authorization or Authenication. So yes mod_fastcgi is really bad. mod_fastcgi has supported this for many years: http://www.fastcgi.com/drupal/node/25#FastCgiAuthorizer http://www.fastcgi.com/drupal/node/25#FastCgiAuthenticator It does not work or I'd have used it. And I tried to make it work. There is a lot of missing code, compare to mod_fcgid implementation of the same. Simple tests work for me. Hmm, Then I must have got something wrong when I tried to get this working, or you have patches I don't. When I looked at the sources and compared to mod_fcgid it looked like there was code missing. It's too long ago now for me to recall the details to discuss. Barry
Re: svn commit: r910673 - /httpd/httpd/trunk/server/config.c
On 16/02/10 20:30, Jeff Trawick wrote: On Tue, Feb 16, 2010 at 3:24 PM, wrote: Author: poirier Date: Tue Feb 16 20:24:33 2010 New Revision: 910673 URL: http://svn.apache.org/viewvc?rev=910673&view=rev Log: Fix compile warning (discarding constness of fname) Modified: httpd/httpd/trunk/server/config.c Modified: httpd/httpd/trunk/server/config.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/server/config.c?rev=910673&r1=910672&r2=910673&view=diff == --- httpd/httpd/trunk/server/config.c (original) +++ httpd/httpd/trunk/server/config.c Tue Feb 16 20:24:33 2010 @@ -1670,7 +1670,7 @@ int current; /* find the first part of the filename */ -rest = ap_strchr(fname, '/'); +rest = ap_strchr((char*)fname, '/'); Casting isn't the right fix, which I guess is to make rest const char * and then use ap_strchr_c() instead of ap_strchr() (hopefully that doesn't snowball). This is a common problem that the C RTL solves using the idiom of accepting a const char * as input and returning a char * as output: char *strchr(const char *s, int c); You may wish to fix the ap_strchr signature to follow the C standard solution rather then invite snow balling. [This came up in discussing a const ading patch I proposed to the Python sources on python dev mailing list.] Barry Barry
HTTPD 2.2.17 issue on Fedora 15 with listening on IPv4
If this is the wrong list to ask for help on this please redirect me. We are porting our application to Fedora 15 and to systemd from SysV init. The httpd configuraturation we are using work without problem on earlier Fedora 13 systems. We are hitting an odd problem with httpd handling requests on localhost:80 over IPv4. The configuration allows access without authenication but we get a 401 error. However repeat the request using IPv6 and it it works. If we restart httpd (systemctl restart httpd.service) the problem goes away. We have a set of identical hardware running identical software with identical config and not all systems show this problem. Leading me to expect its a race condition during startup. Here is a fragment of the httpd.conf file: ... rewrite rules ... #+ localhost auth file Order allow,deny Allow from 127.0.0.1 Allow from ::1 Satisfy Any #- localhost auth file ... I test this with: curl -4 http://localhost:80/XML/ curl -6 http://localhost:80/XML/ I'm willing to debug and patch the code to get to the bottom of the problem but would like to know if this is a known problem. Any pointers on where to start looking in the code would be welcome as well. Barry