Mailing List Archive

On 4/14/02 1:07 PM, "Dana Hudes" <dhudes@hudes.org> claimed:

> I have v1.3.1 of Bricolage on RH7.2 Linux, Apache 1.3.22, Perl 5.6.1. I had to
> manually copy the lib/Bric directory to /usr/lib/perl5/site_perl (and
> lib/Bric.pm as well). Now I have set up all stuff in bricolage.conf . I have
> a problem with Apache configuration. Bricolage is trying to take over the
> whole of Apache but I don't want it to.

Muah-ha-ha-ha-ha!!! Our plot is working! Bricolage is taking control over
your server and there's nothing you can do about it! Ha-ha-he-ca-*cough*.

> Bricolage should only run on certain virtual hosts. At the moment, just one
> but if this works then there will be others.
> I tried putting the
> PerlPassEnv BRICOLAGE_ROOT
> PerlModule Bric::App::ApacheConfig
>
> statements inside a virtual host but Bricolage is off generating vhost
> commands of its own.

Yes. That's because the way in which it is configured is much too complex
for mortal httpd.conf editors. Take a look at Bric::App::ApacheConfig to see
what I mean.

> I have dispensed with bric_apachectl as less functional and useful than the
> shell script that is in /etc/rc.d/init.d
> (so just in case I symbolic linked the latter to the former).

Well, it depends on how you look at it. ;-)

> How can I make Bricolage work w/o it taking over things it has no business
> touching?

You need to get the NAME_VHOST and VHOST_SERVER_NAME directives set just
right in your bricolage.conf. Bricolage uses these directives to set the
vitual host under which it will run. You can do this yourself rather than
have Bricolage do it, but then you'll have a lot more difficulty with
upgrades that way (just as Mark Jarosky at the WHO if you don't believe
me!).

But if you get those set just right, Bricolage will take control of the
virtual host name you specify. It cannot run off a directory or location,
but must control the root of a server. So you're best off configuring it to
use bric.yourdomain.org.

I don't think you can run it on more than one virtual host at the moment,
but I could be wrong. But even if you could, it would essentially be the
same application with the same database. You cannot easily have one server
serving multiple Bricolage installations with separate databases. It can be
done, though, and I expect that Sam would chime in with details.

HTH,

David

--
David Wheeler AIM: dwTheory
david@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory@jabber.org



_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

On Sun, 14 Apr 2002, David Wheeler wrote:

> You cannot easily have one server serving multiple Bricolage
> installations with separate databases. It can be done, though, and I
> expect that Sam would chime in with details.

Right. There are two solutions, one for now and one for later.

Now: setup a separate Apache for each Bricolage installation on high ports
or private IPs. Then setup your main Apache to reverse-proxy to the
Bricolage Apaches inside each virtual host. For extra credit use Squid
instead of Apache for the front-end and benefit from fast caching of
images.

Later: use Apache 2.0 to run a separate Perl interpreter for each vhost.
This will supposedly work just great once mod_perl reaches stability on
Apache 2.0 and Bricolage is ported to it. I wouldn't expect this any
sooner than 6 months from now but I suppose some people would call that
pessimistic.

-sam



_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

On 4/14/02 2:10 PM, "Sam Tregar" <sam@tregar.com> claimed:

> I wouldn't expect this any
> sooner than 6 months from now but I suppose some people would call that
> pessimistic.

Actually, I would say that seeing Bricolage ported to mod_perl2/Apach2 in
six months is *optimistic*.

Regards,

David


--
David Wheeler AIM: dwTheory
david@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory@jabber.org



_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

On 4/14/02 4:44 PM, "Dana Hudes" <dhudes@hudes.org> claimed:

>> Muah-ha-ha-ha-ha!!! Our plot is working! Bricolage is taking control over
>> your server and there's nothing you can do about it! Ha-ha-he-ca-*cough*.
>
> Cough is right, or rather *gurgle*. I put a stake in its heart already.

Curses! Foiled again! ;-)

> Objectively. I looked over your script really carefully and saw nothing in
> there that
> the init script doesn't do and lots of important stuff it doesn't (the
> -Defines for available
> modules for example).

bric_apachectl's restart works better, and it'll use all the settings in
bricolage.conf. But there's lots of other stuff it likely doesn't do, you're
right. But you could get it to do them by having it pass the proper
arguments to apachectl.

> Hmm. I have:
> APACHE_BIN = /usr/sbin/httpd
> APACHE_CONF = /etc/httpd/conf/httpd.conf
> LISTEN_PORT = 80
> SSL_ENABLE = On
> NAME_VHOST = *
> VHOST_SERVER_NAME = bricolage.poeticmischief.com
>
Yes, that looks correct. You're not going to want to have a NameVirtualHost
directive in your httpd.conf, though, as Bric::App::ApacheConfig will create
it for you. Everything else it does will stick to the
bricolage.poeticmischief.com virtual host section.

>> But even if you could, it would essentially be the
>> same application
> Yes, that's good.
>
>> with the same database.
> That's NOT good. Smells like you're not using a container class
> to allow multiple instances.

Ding! Give the man a cigar! Bricolage was originally written to work as it's
own server. This is because it's relatively resource intensive if it's used
much. Maybe one day we'll be able to break it out to run separate instances
on separate vhosts, but it doesn't work that way now. Patches welcome.

> Please! I am very interested in offering virtual hosting to folks with
> Bricolage as part of the
> package but they each have to be in their own sandbox.

Your best bet is to try the approaches that Sam outined.

Good luck!

David

--
David Wheeler AIM: dwTheory
david@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory@jabber.org



_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

> On 4/14/02 1:07 PM, "Dana Hudes" <dhudes@hudes.org> claimed:
>
> > I have v1.3.1 of Bricolage on RH7.2 Linux, Apache 1.3.22, Perl 5.6.1. I had to
> > manually copy the lib/Bric directory to /usr/lib/perl5/site_perl (and
> > lib/Bric.pm as well). Now I have set up all stuff in bricolage.conf . I have
> > a problem with Apache configuration. Bricolage is trying to take over the
> > whole of Apache but I don't want it to.
>

I run Bric on a separate apache process on ports 81 and 444 with only
2 httpsd processes running for this "heavy" application. My regular
apache runs normally (read -> small) on ports 80, 443

The patches to do this have been submitted.
Michael
Michael@bizsystems.com

_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

Hmm. Share code space is the solution.
Perl threads would be good to help with that but they're very much in flux.

I'm missing something. There has to be a way to do this properly.
Many child processes clearly would kill the server host at 20-50Mb each.
How much of this is data and how much is really code? Data we cannot escape per-instance.
Code should be shared.

----- Original Message -----
From: "Michael" <michael@insulin-pumpers.org>
To: "Dana Hudes" <dhudes@hudes.org>
Sent: Tuesday, April 16, 2002 10:03 PM
Subject: Re: [Bricolage-General] bricolage on a virtual server


> > Thanks for the tip, but I really fail to see why there isn't simply
> > a container class for bricolage which feeds the name of a config
> > file to the current top-level routine and therefore allows multiple
> > instances within one Perl interpreter. Make the current top-level
> > merely an instance of a Bric object and shouldn't everything just
> > work? Even names of variables -- unless you've explicitly
> > referenced the global scope in some routines. Since you have
> > separate instances, no conflicts with e.g. database handles should
> > result. Concurrency might require a child process for each instance
> > but can't the instance take care of it ? Don't put your fingers into
> > Apache so much! Let the webserver invoke Bric as required by the
> > URL.
> >
>
> the Bric Apache server process sucks up 20-50 megs per instance while
> a regular mod_perl enhanced apache_ssl may use as little as 2-4 megs.
> Without separating the processes, you can easily bury your server
> with just a few users that are NOT using Bric since Bric pulls in all
> the overhead at init time. The practical solution is to not run the
> unnecessary heavy servers for a process that is expected to be used
> by only a few 'insiders'. Our server routinely runs 50 - 100 apache
> children, it would not be practical to have each instance capable of
> processing Bric requests.
>
> It is relatively simple to set up separate Bric and regular init
> scripts, it only requires starting the apache server for Bric,
> pointing to the bric init script which I keep in
> /usr/local/bricolage/conf, etc.... everything looks just like
> starting a regular apache process including our friendly
> bricabachectl located in /usr/local/bricolage/bin
>
> bye :-)
> Michael
>
> Michael@Insulin-Pumpers.org


_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

On Tue, 16 Apr 2002, Dana Hudes wrote:

> Hmm. Share code space is the solution.
> Perl threads would be good to help with that but they're very much in flux.

That's Apache 2.0 and it'll be great when it works.

> I'm missing something. There has to be a way to do this properly.

I'm pretty sure the options I layed out are the only ones that exist. It
might be possible to do some development and come up with something
better, but it's not in the box now.

-sam


_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

The question is how much development is required to make this work with existing Apache/mod_perl.

Hmm. I don't know enough about mod_perl. Certainly if you launch, cold as it were, a full Apache/mod_perl parent process you duplicate all the code. I'm also fairly sure that if you fork off a child, the child shares the code (*definitely* so for Apache, should be so for mod_perl) but the question arises as to the Perl program which caused the fork. If so, then a container class creating an instance child process works. If not, then the program has to do the cooperative multitasking thing and use non-blocking i/o etc. -- much more work.

Any attempt to shove Bricolage into a container class will find itself foiled by explicit naming of the global variables (i.e. Main::x)
All the objects under Main are fine since they just get instantiated as usual. Each instance of Bric gets a full set of object instances.

I see no reason, meanwhile, to mess with squid or other proxies.
An Apache process with mod_perl and Bric running on e.g. port 81 is simply a URL. If it is desired not to have
a static page on the site name at port 80, then the port 80 process can just have a redirect_permanent to the Bric server on port 81. Off the user goes and the port 80 process isn't bothered again by that user's session
(and if he bookmarks the redirected page he'll always go back there straight).


----- Original Message -----
From: "Sam Tregar" <sam@tregar.com>
To: "Dana Hudes" <dhudes@hudes.org>
Cc: <bricolage-general@lists.sourceforge.net>
Sent: Tuesday, April 16, 2002 10:29 PM
Subject: Re: [Bricolage-General] bricolage on a virtual server


> On Tue, 16 Apr 2002, Dana Hudes wrote:
>
> > Hmm. Share code space is the solution.
> > Perl threads would be good to help with that but they're very much in flux.
>
> That's Apache 2.0 and it'll be great when it works.
>
> > I'm missing something. There has to be a way to do this properly.
>
> I'm pretty sure the options I layed out are the only ones that exist. It
> might be possible to do some development and come up with something
> better, but it's not in the box now.
>
> -sam


_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

On Tue, 16 Apr 2002, Dana Hudes wrote:

> Hmm. Share code space is the solution.
> Perl threads would be good to help with that but they're very much in flux.
>
> I'm missing something. There has to be a way to do this properly.
> Many child processes clearly would kill the server host at 20-50Mb each.
> How much of this is data and how much is really code? Data we cannot escape per-instance.

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
21873 web 9 0 24588 24M 15320 S 0.0 4.7 0:07 httpsd
22378 web 9 0 23964 23M 15700 S 0.0 4.6 0:06 httpsd
6799 root 8 0 20676 17M 13824 S 0.0 3.4 0:00 httpsd
27742 web 9 0 4404 4404 4288 S 0.0 0.8 0:00 httpsd


The top two are Bric/apache children, the third is the parent. The last
entry is one of the regular apache kids.

Physical memory runs 15 megs for Bric and 4megs for standard
apache/mod_perl. According to David Wheeler, the 20/15 meg scenario is on
the low end of what is expected. He claims the 50meg process size.

The Bric kids are from the 'demo' 1.2x distribution with nothing much
loaded. It's pretty much the way it init's. I've not added anything to the
process or asked it to do anything at this point so nothing is loaded that
would normally be in "Autoload" sections waiting to plump up the process
size.

In any event, the only thing necessary to run the second apache (bric)
server is to make its config file. The Bric setup process does the rest
if properly configured. What the current bric does not do is allow you to
run the second server on your ports of choice for both http and https
service. I have submitted those patches to David for review. They are
pretty minor in terms of "lines" of code so hopefully they will be found
acceptable.

Michael@bizsystems.com

> Code should be shared.
>
> ----- Original Message -----
> From: "Michael" <michael@insulin-pumpers.org>
> To: "Dana Hudes" <dhudes@hudes.org>
> Sent: Tuesday, April 16, 2002 10:03 PM
> Subject: Re: [Bricolage-General] bricolage on a virtual server
>
>
> > > Thanks for the tip, but I really fail to see why there isn't simply
> > > a container class for bricolage which feeds the name of a config
> > > file to the current top-level routine and therefore allows multiple
> > > instances within one Perl interpreter. Make the current top-level
> > > merely an instance of a Bric object and shouldn't everything just
> > > work? Even names of variables -- unless you've explicitly
> > > referenced the global scope in some routines. Since you have
> > > separate instances, no conflicts with e.g. database handles should
> > > result. Concurrency might require a child process for each instance
> > > but can't the instance take care of it ? Don't put your fingers into
> > > Apache so much! Let the webserver invoke Bric as required by the
> > > URL.
> > >
> >
> > the Bric Apache server process sucks up 20-50 megs per instance while
> > a regular mod_perl enhanced apache_ssl may use as little as 2-4 megs.
> > Without separating the processes, you can easily bury your server
> > with just a few users that are NOT using Bric since Bric pulls in all
> > the overhead at init time. The practical solution is to not run the
> > unnecessary heavy servers for a process that is expected to be used
> > by only a few 'insiders'. Our server routinely runs 50 - 100 apache
> > children, it would not be practical to have each instance capable of
> > processing Bric requests.
> >
> > It is relatively simple to set up separate Bric and regular init
> > scripts, it only requires starting the apache server for Bric,
> > pointing to the bric init script which I keep in
> > /usr/local/bricolage/conf, etc.... everything looks just like
> > starting a regular apache process including our friendly
> > bricabachectl located in /usr/local/bricolage/bin
> >
> > bye :-)
> > Michael
> >
> > Michael@Insulin-Pumpers.org
>
>
> _______________________________________________
> Bricolage-General mailing list
> Bricolage-General@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bricolage-general
>



_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

On Tue, 16 Apr 2002, Dana Hudes wrote:

> The question is how much development is required to make this work with
> existing Apache/mod_perl.

My guess would be a lot. Bricolage is a huge application - over 100,000
lines of code. Even the smallest change that has to effect every module
is a big job.

> Hmm. I don't know enough about mod_perl.

That's going to make it difficult to assess Bricolage properly. I suggest
you spend some time at http://perl.apache.org getting to know mod_perl.
O'Reilly's "Writing Apache Modules with Perl and C" (the Eagle book) is
also good.

> I see no reason, meanwhile, to mess with squid or other proxies.

One reason: performance. Another: memory usage. Squid is both faster and
lighter than Apache. By front-ending a heavy application like Bricolage
with a caching reverse-proxy you can reduce the number of Bricolage
processes required to serve a given number of users.

-sam



_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

On 4/16/02 9:09 PM, "Michael Robinton" <michael@bizsystems.com> claimed:

> In any event, the only thing necessary to run the second apache (bric)
> server is to make its config file. The Bric setup process does the rest
> if properly configured. What the current bric does not do is allow you to
> run the second server on your ports of choice for both http and https
> service. I have submitted those patches to David for review. They are
> pretty minor in terms of "lines" of code so hopefully they will be found
> acceptable.

Yeah, yeah, yeah... ;-) I'm going to review a couple of patches today, and
yours is one of them.

David

--
David Wheeler AIM: dwTheory
david@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory@jabber.org



_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general