Re: Perl block handler problems
I don't mean to be a pest but I'd like to further explore using handlers for Perl sections. Does anyone have any info on this or can point me in another direction? I guess I can just put my dynamic configs in a perl module that's not called as a handler and just 'use' it in the apache config, right? I know I can put it in a Perl section using the default handler but I'd like to have my perl code in a separate module and not the apache config. On Tue, Oct 6, 2009 at 9:23 AM, Kevin Bosak wrote: > Hi all, > I was trying to set up some perl code to configure my apache server > dynamically and came across this: > http://perl.apache.org/docs/2.0/api/Apache2/PerlSections.html#Advanced_API. > Upon trying it out however, I could not get it working correctly. It > seems that the Perl code in the block is getting executed fine, but > there are problems when trying to parse the "handler=xxx" portion of the > opening tag. > > For example, if I have it will complain that "Foo" > can not be found in @INC. However, if I leave the quotes off of the module, > , it seems to work fine. Also, the example in the docs > shows the handler method being defined as "sub My::Handler::handler : > handler " which for me gives an error. Though using the ": method" > attribute works. > > So, is the handler feature of Perl blocks just not yet working right? Has > anyone else had luck with it? Are the docs incorrect? > > > mod_perl 2.0.4 > apache 2.2.13 > perl 5.10.1 > > Thanks, > Kevin >
Re: Configuring virtual hosts on the fly
On Sun, Oct 11, 2009 at 11:54 AM, Scott Gifford wrote: > Hello, > > I'm working on an Apache configuration for a cluster of machines > serving a variety of virtual hosts. I would not try to unify disparate configs into one unless each server is actually going to service all the virtual hosts your pulling in. You would unnecessarily couple configs together that don't need to be. > It seems much cleaner to me to let Apache look up the information for > a virtual host as it is needed. Conceptually, when each request comes > in, I would like Apache to look at the Host: header, build a temporary > virtual host entry from that, and use it to service the request. I > will use caching to make it reasonably fast. Then the provisioning > script just writes to the database table and is done, and I can handle > any errors on a per-request basis without Apache failing to start. Sounds like you might be pushing the envelope on what Apache can actually do. If you cannot solve the problem in Apache you could consider relying on Apache default vhost as a way to funnel all requests into a Perl "dynamic vhost" implementation. You get exactly what your looking for, but you tradeoff the speed and maturity of Apache vhost code for yours. -wjt
Re: Configuring virtual hosts on the fly
Thanks William, comments inline... William T writes: > On Sun, Oct 11, 2009 at 11:54 AM, Scott Gifford > wrote: >> Hello, >> >> I'm working on an Apache configuration for a cluster of machines >> serving a variety of virtual hosts. > > I would not try to unify disparate configs into one unless each server > is actually going to service all the virtual hosts your pulling in. > You would unnecessarily couple configs together that don't need to > be. Each server will actually service all of the virtual hosts, so there won't be anything unnecessary there. [...] > Sounds like you might be pushing the envelope on what Apache can > actually do. If you cannot solve the problem in Apache you could > consider relying on Apache default vhost as a way to funnel all > requests into a Perl "dynamic vhost" implementation. You get exactly > what your looking for, but you tradeoff the speed and maturity of > Apache vhost code for yours. Thanks, I will definitely take a look! Do you have any recommended reading on this, or just what Google turns up for "dynamic vhost"? Thanks again! ---Scott.
Re: Configuring virtual hosts on the fly
On Tue, Oct 13, 2009 at 8:08 AM, Scott Gifford wrote: >> Sounds like you might be pushing the envelope on what Apache can >> actually do. If you cannot solve the problem in Apache you could >> consider relying on Apache default vhost as a way to funnel all >> requests into a Perl "dynamic vhost" implementation. You get exactly >> what your looking for, but you tradeoff the speed and maturity of >> Apache vhost code for yours. > > Thanks, I will definitely take a look! Do you have any recommended > reading on this, or just what Google turns up for "dynamic vhost"? I don't know of anything that specifically does this, then again I havn't looked. I was mainly thinking about pushing the problem into a different layer since I wasn't sure the Apache layer would work. If it were me I would probably start by looking for through "Mass Dynamic Virtual Hosting" and make sure you can't solve your problem in the Apache layer, or with a ModPerl Apache module to extend Apache (either one already written, or one you write yourself). Then move on to Perl code that does webserving. -wjt
RE: Configuring virtual hosts on the fly
What about mod_vhost_alias? ( http://httpd.apache.org/docs/2.0/mod/mod_vhost_alias.html ) Summary This module creates dynamically configured virtual hosts, by allowing the IP address and/or the Host: header of the HTTP request to be used as part of the pathname to determine what files to serve. This allows for easy use of a huge number of virtual hosts with similar configurations. -Original Message- From: Scott Gifford [mailto:sgiff...@suspectclass.com] Sent: Tuesday, October 13, 2009 11:09 AM To: William T Cc: modperl@perl.apache.org Subject: Re: Configuring virtual hosts on the fly Thanks William, comments inline... William T writes: > On Sun, Oct 11, 2009 at 11:54 AM, Scott Gifford > wrote: >> Hello, >> >> I'm working on an Apache configuration for a cluster of machines >> serving a variety of virtual hosts. > > I would not try to unify disparate configs into one unless each server > is actually going to service all the virtual hosts your pulling in. > You would unnecessarily couple configs together that don't need to > be. Each server will actually service all of the virtual hosts, so there won't be anything unnecessary there. [...] > Sounds like you might be pushing the envelope on what Apache can > actually do. If you cannot solve the problem in Apache you could > consider relying on Apache default vhost as a way to funnel all > requests into a Perl "dynamic vhost" implementation. You get exactly > what your looking for, but you tradeoff the speed and maturity of > Apache vhost code for yours. Thanks, I will definitely take a look! Do you have any recommended reading on this, or just what Google turns up for "dynamic vhost"? Thanks again! ---Scott.
Re: Configuring virtual hosts on the fly
Looking at this from a different perspective, have you tried writing a monitoring program that looks for updates to the database and then would restart the appropriate apache servers on the various machines. It would do them one at a time (taking them out of rotation from your load balancer). It wouldn't be immediate response, could definitely be done in under a minute. -- Michael Peters Plus Three, LP
Re: Configuring virtual hosts on the fly
Michael Peters writes: > Looking at this from a different perspective, have you tried writing a > monitoring program that looks for updates to the database and then > would restart the appropriate apache servers on the various > machines. It would do them one at a time (taking them out of rotation > from your load balancer). It wouldn't be immediate response, could > definitely be done in under a minute. Thanks Michael, I thought about that. It is probably what I will do if I can't get something a little cleaner. I have had mixed experiences in the past with automatically restarting Apache after a configuration change. It is very easy to end up with something unexpected in the configuration, which causes the configuration to fail, which causes apache to stop. And with a cluster, that would happen on all hosts. Now, ideally, I wouldn't make any errors in my configuration code and this would never be an issue. But I have learned the hard way that making things as foolproof as possible is the best way to protect myself from my own foolishness. :-) When I have done this in the past, I have done it with generating configuration files, so of course one misplaced newline or angle-bracket will kill the server. Maybe generating the configuration directly from a section is more robust? Maybe there are ways to catch configuration errors in that layer and handle them cleanly without preventing Apache from starting? Any suggestions in this area would be appreciated. Thanks again! -Scott.
Re: Configuring virtual hosts on the fly
"Ryan Yagatich" writes: > What about mod_vhost_alias? ( > http://httpd.apache.org/docs/2.0/mod/mod_vhost_alias.html ) > > > Summary > > This module creates dynamically configured virtual hosts, by allowing the IP > address and/or the Host: header of the HTTP request to be used as part of > the pathname to determine what files to serve. This allows for easy use of a > huge number of virtual hosts with similar configurations. > Thanks! That looks very close to what I want. I wonder if there is a way to do a database lookup and substitute that?... Scott.
Re: Configuring virtual hosts on the fly
I thought I'd weigh in on two items of note On Oct 13, 2009, at 12:17 PM, Scott Gifford wrote: When I have done this in the past, I have done it with generating configuration files, so of course one misplaced newline or angle-bracket will kill the server. Maybe generating the configuration directly from a section is more robust? Maybe there are ways to catch configuration errors in that layer and handle them cleanly without preventing Apache from starting? Any suggestions in this area would be appreciated. It seems to me that you are assuming that your script must apply the new configuration to the live apache server. Why not have your script simply apply a potential new configuration to a "test" apache installation (separate from all others), have it restart apache there, hit a few critical URLs to test functionality and then report to you if there's an error. If it's successful, it can then apply that config to the live cluster, keeping fingers crossed, of course. (and making sure your monitoring software is going to pull the fire alarm if the cluster goes down.) If there's an error, you have some time to gracefully solve it and your system continues to run in the meantime. Of course, this means that the new configuration wasn't applied, but in the grand scheme of things, a missing update to a config is far, far better than taking down an entire cluster because your automatic configurator has a screw loose. On another note, regarding mod_vhost_alias and a database lookup to dynamically do something... "Ryan Yagatich" writes: What about mod_vhost_alias? ( http://httpd.apache.org/docs/2.0/mod/mod_vhost_alias.html ) Summary This module creates dynamically configured virtual hosts, by allowing the IP address and/or the Host: header of the HTTP request to be used as part of the pathname to determine what files to serve. This allows for easy use of a huge number of virtual hosts with similar configurations. Thanks! That looks very close to what I want. I wonder if there is a way to do a database lookup and substitute that?... In my experience, you really want to minimize the hits on your database and placing a lookup of any kind for -every- connection to apache would be murderous regardless of which database you're using. --Joel
Re: Configuring virtual hosts on the fly
On 10/13/2009 12:17 PM, Scott Gifford wrote: I have had mixed experiences in the past with automatically restarting Apache after a configuration change. It is very easy to end up with something unexpected in the configuration, which causes the configuration to fail, which causes apache to stop. And with a cluster, that would happen on all hosts. If you run apache with a -t option it will check that the configuration is sane. I'm assuming that your configuration is auto-generated by this monitor somehow, then you can create a new config file and test it with httpd -t -f /path/to/new/file Then if it's ok, you can move it to the real location and do the restart. When I have done this in the past, I have done it with generating configuration files, so of course one misplaced newline or angle-bracket will kill the server. I generally prefer generated config files, especially if you have multiple sites with basically the same config. I also use templated config files so that the template I'm working on looks a lot like the finished product. It's easier to prevent typos this way, IMO. -- Michael Peters Plus Three, LP
Re: Configuring virtual hosts on the fly
Joel Richard writes: > I thought I'd weigh in on two items of note > > On Oct 13, 2009, at 12:17 PM, Scott Gifford wrote: > >> When I have done this in the past, I have done it with generating >> configuration files, so of course one misplaced newline or >> angle-bracket will kill the server. Maybe generating the >> configuration directly from a section is more robust? Maybe >> there are ways to catch configuration errors in that layer and handle >> them cleanly without preventing Apache from starting? Any suggestions >> in this area would be appreciated. >> > > > It seems to me that you are assuming that your script must apply the > new configuration to the live apache server. > > Why not have your script simply apply a potential new configuration to > a "test" apache installation (separate from all others), have it > restart apache there, hit a few critical URLs to test functionality > and then report to you if there's an error. If it's successful, it can > then apply that config to the live cluster, keeping fingers crossed, > of course. (and making sure your monitoring software is going to pull > the fire alarm if the cluster goes down.) That's a good idea, though a bit involved to implement. > If there's an error, you have some time to gracefully solve it and Yeah, good point, thanks. [...] >> Thanks! That looks very close to what I want. I wonder if there is a >> way to do a database lookup and substitute that?... >> > > In my experience, you really want to minimize the hits on your > database and placing a lookup of any kind for -every- connection to > apache would be murderous regardless of which database you're using. Right, absolutely the result would have to be cached. Then I think it would be no problem. Scott.
