Revision as of 01:55, 11 February 2010 (view source) Jdhutchin@ugcs.caltech.edu (Talk | contribs) (→Implementation) ← Older edit		Latest revision as of 06:45, 12 September 2011 (view source) Jdhutchin@ugcs.caltech.edu (Talk | contribs)
Line 1:		Line 1:
		+	WARNING: This page served as a design doc and reading it won't help you understand the current system.  It might get updated eventually to reflect our current system.  Sorry.
		+
		+
	=Problem Definition=		=Problem Definition=
	==Problems to solve==		==Problems to solve==

---

Latest revision as of 06:45, 12 September 2011

WARNING: This page served as a design doc and reading it won't help you understand the current system. It might get updated eventually to reflect our current system. Sorry.

Contents 1 Problem Definition 1.1 Problems to solve 1.2 Constraints 1.3 Desired outcomes 2 Implementation 2.1 FastCGI docs 2.2 Details 2.3 Why it only works for PHP 2.4 Things to make it work for normal users 2.5 Todo

Problem Definition

Problems to solve

• PHP performance is really bad- it takes 0.3s to load the simple test pages we have
• Since php is run as a cgi every time, it cannot do opcode caching

Constraints

• Stuff must be run through our wrapper scripts
• We have finite resources on posiedon and can't exhaust them by leaving one or two processes open for every user

Desired outcomes

• Something that lets php keep running so it doesn't have to re-initialize every time

Implementation

• Need to use a the version from Sid so we get the newer version of fcgid.

FastCGI docs

http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html

Details

• Works on a server-wide level
• We want a dynamic application so that the fastcgi server can start/stop things as needed
• Each virtual server will also have a set up that points to the vhost wrapper script
• Each vhost will also need an environment variable set that tells the script what user to run as
• php-cgi needs to be told to not run its own process manager so fcgi can start/stop it as necessary

Why it only works for PHP

• The dyanmic service (through a wrapper) will start the php-cgi which runs as a fastcgi service.
• Since php-cgi will be running as the application (and it gets passed filename requests), it can't do normal cgi
• This isn't really a problem because normal cgi stuff will continue to work as normal cgi
• This solves our biggest problem anyways which is php initialization/parsing time

Things to make it work for normal users

• Set up a fcgi dynamic instance at ~username/.wrapper/php-wrapper
• Use a FastCGIWrapper that knows how to parse the uri for username
• Use mod_rewrite to rewrite requests for ~username/*.php to the user's own wrapper
• Need to add a check that the URI's going to the wrapper are for that user, otherwise you could run a different user's script under that user by calling the right url
  • This needs to be investigate and completely solved otherwise we make it lots worse by introducing a huge security hole in exchange for some performance

Todo

• Install it on dionysus
• Set up a test vhost
• Add User/Group to each vhost definition
• Modify the wrapper scripts
  • Still needs to be suid since we are using mod_fastcgi which runs under apache's uid/gid
  • Remove the pagsh since we will have k5start make a new one
  • Use user/group from command line instead of parsing the URL
  • Change uid before getting tokens
  • Set the environment for php-cgi so it does the right things with fcgi
  • Set it up so that we have k5start ... -t -- php-cgi