httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pablo Yaggi <>
Subject Re: Worker hungs ..
Date Tue, 17 Jun 2003 14:04:07 GMT
Yes, I think I have to write my own MPM... but  I didn't understand
your discrimination per-web-user /per-vhost. 
(is not  (vhost)==(webs  under the same domain)?)

I'm trying to do the following:
	1-every http request to *.somedomain to run with a userid
		(that what perchild does)
	2-every ssl request to *.somedomain to run with the same userid as an http
		connection. But they're named base domains.
		(that what perchild doesn't)
	3-every ssl request to masterdomain/ssl/*.somedomain to run with the same userid
		as an http connection to *.somedomain and user *.somedomain contents.
		(again that what perchild doesn't)

I need to do this because if not ssl connection are useless for scripting (when the
interpreters are modules), because ssl connection can't gain write access to files stored
in the vhost, and that includes session files ie in php, so really become usefull for example
for authentication porpouses.

Because perchild dispaches the connection to it's children before the ssl handshake it
can't acomplish steps 2 and 3, I know that step 2 will generate pop-up's on clients but
it is fine with me, because I have the work around of using step 3, but step 2 is usefull
for precompiled application that can't be tuned when using, for example, ssl for authentication.

So I think I need something exactly like perchild concept, one or more process per domain,
but instead of dispaching the connection at the beging, to do so after the translation, the
is, is any usefull ? or all of the performance gain cause we have mulithreading is lost doing
this ?

Maybe the best solution is to use something like prefork for this solution, but using my module
prefork has the following issues.
After doing the process prefork can't gain access to the mutex because is on a lower privileged
that the one who stablish the mutex. Can this be solved, I remember you I never work with
threads before.


On Tuesday 17 June 2003 03:53 am, William A. Rowe, Jr. wrote:
> Perchild was designed to pass off any connection, including an SSL
> connection, to another child.
> If things are working right (and they admittedly probably are not), the
> parent transfers the request and socket to the child.  In this case, we
> cannot do that effectively because the parent is performing the SSL
> negotiation.
> So we effectively need an API that can keeps the raw connection
> in the parent dispatcher, and won't pass off the socket in the case
> that the connection filters can't be 'reproduced' in the child process.
> It's still the better solution that what you were attempting to cook up,
> but someone needs to spend time living in perchild and find the bugs
> and strange SSL interactions before it is ready for prime time.
> The other option is to transfer the entire SSL state to the child, but
> that isn't generally practical.  You still are not going to be able to
> do a setuid() on a per-thread basis, so your current module design
> is absolutely restricted to prefork, or you will need to add some really
> stringent mutexes that will probably interfere with some core code.
> And I'm altogther unclear - you simply need to create a child per user,
> and the current perchild design is one uid/gid pair per vhost (ideally
> one would aggregate the vhosts that share a uid/gid into one process.)
> Perchild never changes users because each child is running as the
> appropriate user.  Now it sounds like you are writing a per-web-user
> selection rather than per-vhost.  It certainly sounds like you are trying
> to write an module but should be rolling your own auth-MPM.
> Bill
> At 10:33 PM 6/16/2003, Pablo Yaggi wrote:
> >(I know about the popups, but I have no choice if havenĀ“t got many IPs.)
> >
> >But if i use perchild for ssl connections it will never switch to the
> > right child, I mean by userid.
> >
> >Do I have to tune/write an MPM ? if it is so, is there any documentation
> >about it, or do I have to follow the source.
> >
> >Pablo
> >
> >On Monday 16 June 2003 09:07 pm, you wrote:
> >> On Mon, 16 Jun 2003, Pablo Yaggi wrote:
> >> > I know the fact is mentioned in the FAQ, but I don't want that the SSL
> >> > uses a certifcate valid for the virtual host, i just want that any
> >> > client wich contact any of the virtual hosts to stablish an SSL
> >> > connection using the default host certificate, and after that it get
> >> > the files hosted for that virtual host. That's why I wrote a module to
> >> > translates the URL's and it doesn't care on wich virtual host is the
> >> > request originated.
> >>
> >> Well, if you're going to have the name in the ssl certificate not match
> >> the hostname that was requested, you have to be willing to accept that
> >> the browsers of people visiting your sites will have security warnings
> >> pop up every time they visit those sites.  That's typically considered
> >> unacceptable.
> >>
> >> I suggest you use perchild, not worker.  Then you don't have to do any
> >> setuid() stuff yourself.  You should be able to tweak perchild so that
> >> you can do lookups from your table so that requests end up at the right
> >> worker process, and then everything should just work... all of the hard
> >> stuff has already been done for you.
> >>
> >> PS: Yes, that would have to happen /after/ the ssl handshake, since only
> >> after the handshake can the web server know which host and url were
> >> requested.  But what difference does that make?
> >>
> >> Hope this helps,
> >> Cliff

View raw message