Re: WEb hosting..

[David Emery]

On 2003.Mar.4, at 08:36 Asia/Tokyo, Stas Bekman wrote:

Fco. Valladolid wrote:
http://www.upnix.com
David Emery wrote:
> http://www.mediatemple.net
mediatemple.net is located in Los Angeles


please specify where the companies are based, since our list is sorted 
by country. Thanks.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: WEb hosting..

[Fco. Valladolid]

Stas Bekman wrote:
Fco. Valladolid wrote:

http://www.upnix.com


David Emery wrote:
 > http://www.mediatemple.net
please specify where the companies are based, since our list is sorted 
by country. Thanks.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


http://www.upnix.com  is located in Calgary, Alberta Canada.

Regards.

--
Fco. Valladolid Hdez.
---
Consultante
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: WEb hosting..

[Stas Bekman]

Fco. Valladolid wrote:
http://www.upnix.com
David Emery wrote:
> http://www.mediatemple.net
please specify where the companies are based, since our list is sorted by 
country. Thanks.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: WEb hosting..

[Stas Bekman]

Fco. Valladolid wrote:

I'am introductory o newbie user of mod_perl.. so what book or tutorial 
recommend for me..
Please always reply to the list!

Online docs:
http://perl.apache.org/docs/index.html
Books:
http://perl.apache.org/docs/offsite/books.html
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: WEb hosting..

[Fco. Valladolid]

Stas Bekman wrote:
Thank you! I've committed the isps you have submitted so far.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com




http://www.upnix.com

Can setup mod_perl for you choice in Premium web hosting services, the 
guys is using my favorite OS in your servers.. OpenBSD 3.2

--
Fco. Valladolid Hdez.
---
Consultante
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: WEb hosting..

[David Emery]

YAMPHISP

http://www.mediatemple.net

They're popping up faster than the green spots on that Christmas cake 
in the back of my fridge...

On 2003.Mar.3, at 08:00 Asia/Tokyo, Stas Bekman wrote:

Thank you! I've committed the isps you have submitted so far.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: WEb hosting..

[Stas Bekman]

Thank you! I've committed the isps you have submitted so far.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: WEb hosting..

[Charlie Garrison]

Good afternoon,

On 28/2/03 at 5:26 PM, Stas Bekman <[EMAIL PROTECTED]> wrote:

>http://perl.apache.org/help/isps.html
>
>As usual, if you know of ISPs that aren't listed there (or listed, but not 
>providing modperl support any longer), please let us know.

Make-Tracks (based in Australia) offers hosting for mod_perl sites. For more 
information see  or for specific hosting details
see .

Charlie
-- 
   Charlie Garrison[EMAIL PROTECTED]
   PO Box 141, Windsor, NSW 2756, Australia 

Re: WEb hosting..

[The Doctor]

On Fri, Feb 28, 2003 at 12:18:38AM -0600, Fco. Valladolid wrote:
> Fco. Valladolid wrote:
> 
> > Hi.
> >
> > Some know web hosting providers with mod_perl support...
> >
> > Regards..
> >
> >
> >
> >
> >
> >
> >
> 
> 
> 


Please look up http://www.nk.ca 

-- 
Member - Liberal International  On 11 Sept 2001 the WORLD was violated.
This is [EMAIL PROTECTED]   Ici [EMAIL PROTECTED]
Society MUST be saved! Extremists must dissolve.  
Forward on to Victory The GRAND TEAM Arsenal

Re: [mod_perl] Re: WEb hosting..

[Jonathan M. Hollin]

Some know web hosting providers with mod_perl support...
http://perl.apache.org/help/isps.html

As usual, if you know of ISPs that aren't listed there (or listed, but not 
providing modperl support any longer), please let us know.
In the UK, http://www.firstserv.com/ provide an excellent package of 
services and fully support mod_perl and LAMP platforms. Customer support 
is exceptional - when you call you talk to a human immediately (remember 
those days guys?)

--
Jonathan M. Hollin
Digital-Word Ltd. (http://digital-word.com/)

Re: WEb hosting..

[Oleg Shaikhatarov]

Hi, 

http://www.usonyx.com (USA)
http://www.usonyx.net (Singapore)
http://www.rusonyx.ru (Russa)

They are HSPs selling VPS based on Virtuozzo(tm) VPS technology and
HSPcomplete hosting automation solution:
http://www.sw-soft.com/products/virtuozzo/
http://www.sw-soft.com/products/hspcomplete/

And they all allow customers to install mod_perl into their VPS.

You can find more HSPs with mod_perl support if you will search for
hosting providers which uses Virtuozzo and HSPcomplete.

Regards,
Oleg Shaikhatarov

From: Stas Bekman <[EMAIL PROTECTED]>
To: Fco. Valladolid <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: WEb hosting..
Date: 28 Feb 2003 17:26:33 +1100

> Fco. Valladolid wrote:
> > Hi.
> > 
> > Some know web hosting providers with mod_perl support...
> 
> http://perl.apache.org/help/isps.html
> 
> As usual, if you know of ISPs that aren't listed there (or listed, but not 
> providing modperl support any longer), please let us know.
> 
> __
> Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org   http://ticketmaster.com
> 
> 

Re: WEb hosting..

[Stas Bekman]

Fco. Valladolid wrote:
Hi.

Some know web hosting providers with mod_perl support...
http://perl.apache.org/help/isps.html

As usual, if you know of ISPs that aren't listed there (or listed, but not 
providing modperl support any longer), please let us know.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: WEb hosting..

[Fco. Valladolid]

Fco. Valladolid wrote:

Hi.

Some know web hosting providers with mod_perl support...

Regards..

WEb hosting..

[Fco. Valladolid]

Hi.

Some know web hosting providers with mod_perl support...

Regards..

Re: mod_perl virtual web hosting

[Gunther Birznieks]

While I understand that it might be an "advantage" to allow the customer's 
their own mix of modules, it can also be a bit of a support headache as 
different customers will be loading different DSOs presumably even in 
different orders. There may be subtle bugs with module interaction that 
providing a standard set of one or two Apache binaries would solve for the ISP.

However, I do agree that you should not compile in mod_perl and other 
modules like it by default for the front-end servers The reason is 
security. Core Apache is complicated enough without adding to the potential 
for buffer overflows.  The more lines of code you add, the greater the 
likelihood of bugs, some of those bugs have a likelihood of being security 
bugs.

By only having a subset of users using a DSO, or making a back-end server 
use this stuff, you could limit the possibility that the main web server 
itself is subject to the overflow (although this is still a risky scenario, 
it is less risky than compiling everything in one monolithic apache) since 
the front-end could be designed to have very little in it except for an 
Intrusion Detection system (which I am under the impression that someone is 
writing?).

Anyway, I guess it all boils down to balance and the risks (either support 
or security) you are willing to take as an ISP. Adding mod_perl certainly 
is a risk in itself! But one that I think many of us definatley would not 
mind paying extra for as a dedicated server solution is extremely expensive 
as it is.

Later,
Gunther

At 04:26 PM 4/12/00 +, Jesse Wolfe wrote:
>At 02:54 PM 4/12/00 -0700, Tom Brown wrote:
> >On Wed, 12 Apr 2000, Jesse Wolfe wrote:
> >
> >> I am working with www.superb.net to get their mod_perl up and working
> >> again. They have great infrastrucure, lots of great tools, and an amazing
> >> price.
> >> They had apache/mod_perl for awhile, and upgrades broke it.  I expect they
> >> will have it in a week or two, if we can use all these dynamic/shared
> >> modules as planned.
> >
> >strikes me (as an owner of a web hosting service) that DSO is the wrong
> >answer. What does DSO buy you? NOTHING except a complete waste of
> >memory...
>
>well, it would let each customer add their own combo of modules to their
>apache server without requiring either two installs (one with, one without
>mod_perl) or making everyone's server run mod_perl even if they aren't
>using it.
>
>But it is a good question... I found it kind of unusual to request that
>EVERY Apache module be dso, including mod_perl, mod_ssl, PHP3, and libdav.
>I'm not even sure that it's possible that it will run well. Any advise
>anyone has here would be most appreciated.
>
>I'm actually kind of surprised I got mod_perl DSO 'make test' to pass at all.
>
> >
> >I'm reading between the lines here, but it sounds like you are trying to
> >have _one_ parent apache daemon that services _everything_ on the machine
> >(likely _more_ than one website), which would imply that you are going to
> >have an _extremely_ low hit ratio on your mod_perl scripts.
>
>nahh, that's not where we were going with it. I am pretty sure it's just a
>"maximum flexibility" feature they want to have on hand to minimize tech
>support, etc.  Why does DSO waste so much memory? I thought DSO would mean
>all processes share the resident copy of the perl library?
>
> >
> >it strikes me that you _want_ a frontend proxy to feed your requests to
> >the smallest number of backend daemons which are most likely to already
> >have compiled your scripts. This saves memory and CPU, while simplifying
> >the configuration, and of course, for a dedicated backend daemon, DSO buys
> >nothing... even if that daemon uses access handlers, it still always needs
> >mod_perl
>
>remember we're talking an entire ISP, not just a website. I think it might
>be a mighty pain to have everyone running or sharing some backend mod_perl
>server. Logs and all that.
>
> >
> >That said, we bought modperl-space.com back when domains suddenly got
> >cheap, but haven't put together a mod_perl package because we really don't
> >know what folks want/are using it for.
>
>seems like most folks with enough ?? to be using mod_perl are either
>working corporate or have their own hosts and don't have to deal with ISP's
>on the mod_perl issue.  With all this talk about mod_perl programmers being
>needed, I'm surprised to find so few ISP's offering it.  Bottom line it
>seems you need to be able to keep a mod_perl guru on hand just to keep it
>going... the compilation, etc. of it is so complex. I actually need to
>leave my original mod_perl isp because they just don't have the staff to
>make the right mods to their system, even if I figure it out for them.
>Their mod_perl person got up and left and they can't seem to hire a
>replacement. Anyone in Boston area would like to work with a pretty decent
>ISP?
>
>Regards,
>
>Jesse
>
>

Re: mod_perl virtual web hosting

[Mike Lambert]

Yes, I am an Infoboard customer. However, we aren't really involved in just
small sites. Our site has over 100 cgi scripts, with two dozen modules being
used by them (yeah, we'll be moving to Apache::Registry in the next version
:). I've never had the need for SSI or anything else besides "simple"
mod_perl, since it does all that we want. But I can see now that since they
have a single apache build, that you can't get custom stuff in, and can't do
extra stuff like you want with mod_ssi. I dunno why you have to run a proxy
with them, tho. You're limited to what can be changed in a httpd.conf file.
Oh well.

Mike Lambert

- Original Message -
From: "Jesse Wolfe" <[EMAIL PROTECTED]>
To: "Mike Lambert" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, April 13, 2000 2:57 PM
Subject: Re: mod_perl virtual web hosting


> At 10:21 PM 4/12/00 -0400, Mike Lambert wrote:
> >This is my first post on the list, hopefully it's helpful. ;)
> >
> >We've had great success with InfoBoard. We have four mod_perl accounts
set
> >up with them, and we are currently moving to a colocated server that they
> >are hosting for us. They have good experience with mod_perl, and can
easily
> >get you up and running with your own apache server. They have a toll
phone
> >support until 6 or 7 est, but are not open on weekends. When they are
there
> >however, they have a very good response time and user support. (And an
> >extra-cost option for paging them in emergencies, which we've used a few
> >times ;) They run an independant server for each client, so you won't
have
> >any interference with any other mod_perl clients.
> >
> >http://www.infoboard.com/
> >
> >Mike Lambert
>
> Mike,
>
> Very interesting. I am also an infoboard customer, but have not had such
> luck as you describe.  I had a pretty decent setup, then they changed
their
> configuration unannounced, broke my site, then set me up in such a way
that
> I *have* to run proxy... their standard mod_perl/apache setup doesn't
> handle SSI's but they don't have any staff to look at the problem, or so
> the owner tells me.
>
> I suppose if you have just a few scripts to run mod_perl their setup may
be
> adequate... but if you are working on a larger project such as I am you
may
> find yourself without a lot of support.
>
> good luck...
>
> Jesse
>
>
> >
> >- Original Message -
> >From: "Gagan Prakash" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Wednesday, April 12, 2000 1:26 PM
> >Subject: mod_perl virtual web hosting
> >
> >
> >> Hello,
> >>
> >> I have been looking for mod_perl virtual web hosting companies who have
> >fast
> >> servers and good infrastructure but the two I have found so far have
> >either
> >> had problems with their mod_perl setups (they installed the module, did
> >not
> >> change apache configs or changed them incorrectly) or have been very
slow.
> >> These two are www.123hostme.com or www.olm.net.
> >>
> >> I would greatly appreciate if somebody could point me in a better
> >direction.
> >>
> >> Thanks
> >> Gagan
> >>
> >>
> >> ** Web App Development  Needs? ***
> >>   Contact OSATech today! http://www.OSATech.com
> >> ***
> >>
> >> - Original Message -
> >> From: "Jason Murphy" <[EMAIL PROTECTED]>
> >> To: "Doug MacEachern" <[EMAIL PROTECTED]>
> >> Cc: <[EMAIL PROTECTED]>
> >> Sent: Wednesday, April 12, 2000 1:09 PM
> >> Subject: Re: $r->args troubles...
> >>
> >>
> >> >
> >> > You would have guessed right. However, the problem was two fold in my
> >> case.
> >> >
> >> > First, I was not calling Apache::Request correctly. The proper method
to
> >> > call Apache was told to me by Doug Kyle (Giving credit where due!).
> >Below
> >> is
> >> > how it is done.
> >> >
> >> > <--- Begin Example
> >> >
> >> > my $r = Apache->request;
> >> > my $apr = Apache::Request->new($r);
> >> >
> >> > my %params = $apr->args;
> >> >
> >> > print $params{"Player"};
> >> >
> >> > < End Example
> >> >
> >> > The 'print $params{"Player"}' would be 

Re: mod_perl virtual web hosting

[Jesse Wolfe]

At 10:21 PM 4/12/00 -0400, Mike Lambert wrote:
>This is my first post on the list, hopefully it's helpful. ;)
>
>We've had great success with InfoBoard. We have four mod_perl accounts set
>up with them, and we are currently moving to a colocated server that they
>are hosting for us. They have good experience with mod_perl, and can easily
>get you up and running with your own apache server. They have a toll phone
>support until 6 or 7 est, but are not open on weekends. When they are there
>however, they have a very good response time and user support. (And an
>extra-cost option for paging them in emergencies, which we've used a few
>times ;) They run an independant server for each client, so you won't have
>any interference with any other mod_perl clients.
>
>http://www.infoboard.com/
>
>Mike Lambert

Mike,

Very interesting. I am also an infoboard customer, but have not had such
luck as you describe.  I had a pretty decent setup, then they changed their
configuration unannounced, broke my site, then set me up in such a way that
I *have* to run proxy... their standard mod_perl/apache setup doesn't
handle SSI's but they don't have any staff to look at the problem, or so
the owner tells me. 

I suppose if you have just a few scripts to run mod_perl their setup may be
adequate... but if you are working on a larger project such as I am you may
find yourself without a lot of support.

good luck...

Jesse


>
>- Original Message -
>From: "Gagan Prakash" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Wednesday, April 12, 2000 1:26 PM
>Subject: mod_perl virtual web hosting
>
>
>> Hello,
>>
>> I have been looking for mod_perl virtual web hosting companies who have
>fast
>> servers and good infrastructure but the two I have found so far have
>either
>> had problems with their mod_perl setups (they installed the module, did
>not
>> change apache configs or changed them incorrectly) or have been very slow.
>> These two are www.123hostme.com or www.olm.net.
>>
>> I would greatly appreciate if somebody could point me in a better
>direction.
>>
>> Thanks
>> Gagan
>>
>>
>> ** Web App Development  Needs? ***
>>   Contact OSATech today! http://www.OSATech.com
>> ***
>>
>> - Original Message -
>> From: "Jason Murphy" <[EMAIL PROTECTED]>
>> To: "Doug MacEachern" <[EMAIL PROTECTED]>
>> Cc: <[EMAIL PROTECTED]>
>> Sent: Wednesday, April 12, 2000 1:09 PM
>> Subject: Re: $r->args troubles...
>>
>>
>> >
>> > You would have guessed right. However, the problem was two fold in my
>> case.
>> >
>> > First, I was not calling Apache::Request correctly. The proper method to
>> > call Apache was told to me by Doug Kyle (Giving credit where due!).
>Below
>> is
>> > how it is done.
>> >
>> > <--- Begin Example
>> >
>> > my $r = Apache->request;
>> > my $apr = Apache::Request->new($r);
>> >
>> > my %params = $apr->args;
>> >
>> > print $params{"Player"};
>> >
>> > < End Example
>> >
>> > The 'print $params{"Player"}' would be used to get and print something
>> like
>> > the parameters from the URL of a GET like
>> > "www.example.com/find_player.pl?Player=Mullen" (Not a real site, dont
>> > click!).
>> >
>> > Second part of my problem was that I had an error in my Apache::Registry
>> > setup in Apache.conf or perl.conf (Can't remember where I put it). The
>> > script I was running was not being picked up by Apache::Registry and
>thus
>> > not working.
>> >
>> >  Thanks for everyone's help.
>> >
>> > PS. The only reason I say this on the mailing list is to get it in to
>the
>> > mailing list archives because I could not my solution there when I
>looked.
>> >
>> >
>> > From: "Doug MacEachern" <[EMAIL PROTECTED]>
>> > To: "Jason Murphy" <[EMAIL PROTECTED]>
>> > Cc: <[EMAIL PROTECTED]>
>> > Sent: Tuesday, April 11, 2000 8:52 PM
>> > Subject: Re: $r->args troubles...
>> >
>> > > On Fri, 7 Apr 2000, Jason Murphy wrote:
>> > > > Can't locate object method "new" via package "Apache::Request" at
>> > > > ./find_player.pl line 10.
>> > >
>> > > that would normally indicate your script is running under mod_cgi, not
>> > > mod_perl.
>> > >
>> > > > my $r = new Apache::Request;  <---Where the error appears
>> > >
>> > > in any case, you need to change that to:
>> > >
>> > > my $r = Apache::Request->new(shift);
>> > > or
>> > > my $r = Apache::Request->new(Apache->request);
>> > >
>> > >
>> >
>> > --
>> >  Jason Murphy
>> >  System Administrator
>> >  Lawinfo.com
>> >  1-800-397-3743 ex: 133
>> >
>> >
>> >
>>
>
>

Jesse Wolfe, ICQ #19734806
AllHeal, a Global Healing Village
"Healing our World, One Life at a Time."
http://www.allheal.com
Want to pay less for long distance? - http://ld.net?claritycom
 

Re: mod_perl virtual web hosting

[Stas Bekman]

On Wed, 12 Apr 2000, Gagan Prakash wrote:

> Thanks everyone. I did check the listing at
> perl.apache.org but many fo the organization appear to
> be resellers. I have the unique situation of setting
> up a site for India and thus need the host to be as
> close as possible to a central internet node.
> 
> I will check out iserver and use them if it works
> otherwise I will wait for superb.net.
> 
> It has been a nightmare dealing with various webhosts.
> In some cases the sales and techn support people
> indicate that they have mod_perl. Some companies make
> that claim on their homepage. When it comes down to
> it, they either don't have it, dont want it, or dont
> want to understand it.

Well, my attempt to describe possible solutions to this problem is
described at http://perl.apache.org/guide/multiuser.html .

This chapter should help ISPs to learn how to setup a mod_perl service,
what are the pros and cons, feasibility concerns and provide you as a
client enough hints to help persuade the ISP to give you this service.

As usual comments and additions are welcome.

__
Stas Bekman | JAm_pH--Just Another mod_perl Hacker
http://stason.org/  | mod_perl Guide http://perl.apache.org/guide/ 
mailto:[EMAIL PROTECTED]  | http://perl.orghttp://stason.org/TULARC/
http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org
--

Re: mod_perl virtual web hosting

[Mike Lambert]

This is my first post on the list, hopefully it's helpful. ;)

We've had great success with InfoBoard. We have four mod_perl accounts set
up with them, and we are currently moving to a colocated server that they
are hosting for us. They have good experience with mod_perl, and can easily
get you up and running with your own apache server. They have a toll phone
support until 6 or 7 est, but are not open on weekends. When they are there
however, they have a very good response time and user support. (And an
extra-cost option for paging them in emergencies, which we've used a few
times ;) They run an independant server for each client, so you won't have
any interference with any other mod_perl clients.

http://www.infoboard.com/

Mike Lambert

- Original Message -
From: "Gagan Prakash" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 12, 2000 1:26 PM
Subject: mod_perl virtual web hosting


> Hello,
>
> I have been looking for mod_perl virtual web hosting companies who have
fast
> servers and good infrastructure but the two I have found so far have
either
> had problems with their mod_perl setups (they installed the module, did
not
> change apache configs or changed them incorrectly) or have been very slow.
> These two are www.123hostme.com or www.olm.net.
>
> I would greatly appreciate if somebody could point me in a better
direction.
>
> Thanks
> Gagan
>
>
> ** Web App Development  Needs? ***
>   Contact OSATech today! http://www.OSATech.com
> ***
>
> - Original Message -
> From: "Jason Murphy" <[EMAIL PROTECTED]>
> To: "Doug MacEachern" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Wednesday, April 12, 2000 1:09 PM
> Subject: Re: $r->args troubles...
>
>
> >
> > You would have guessed right. However, the problem was two fold in my
> case.
> >
> > First, I was not calling Apache::Request correctly. The proper method to
> > call Apache was told to me by Doug Kyle (Giving credit where due!).
Below
> is
> > how it is done.
> >
> > <--- Begin Example
> >
> > my $r = Apache->request;
> > my $apr = Apache::Request->new($r);
> >
> > my %params = $apr->args;
> >
> > print $params{"Player"};
> >
> > < End Example
> >
> > The 'print $params{"Player"}' would be used to get and print something
> like
> > the parameters from the URL of a GET like
> > "www.example.com/find_player.pl?Player=Mullen" (Not a real site, dont
> > click!).
> >
> > Second part of my problem was that I had an error in my Apache::Registry
> > setup in Apache.conf or perl.conf (Can't remember where I put it). The
> > script I was running was not being picked up by Apache::Registry and
thus
> > not working.
> >
> >  Thanks for everyone's help.
> >
> > PS. The only reason I say this on the mailing list is to get it in to
the
> > mailing list archives because I could not my solution there when I
looked.
> >
> >
> > From: "Doug MacEachern" <[EMAIL PROTECTED]>
> > To: "Jason Murphy" <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Tuesday, April 11, 2000 8:52 PM
> > Subject: Re: $r->args troubles...
> >
> > > On Fri, 7 Apr 2000, Jason Murphy wrote:
> > > > Can't locate object method "new" via package "Apache::Request" at
> > > > ./find_player.pl line 10.
> > >
> > > that would normally indicate your script is running under mod_cgi, not
> > > mod_perl.
> > >
> > > > my $r = new Apache::Request;  <---Where the error appears
> > >
> > > in any case, you need to change that to:
> > >
> > > my $r = Apache::Request->new(shift);
> > > or
> > > my $r = Apache::Request->new(Apache->request);
> > >
> > >
> >
> > --
> >  Jason Murphy
> >  System Administrator
> >  Lawinfo.com
> >  1-800-397-3743 ex: 133
> >
> >
> >
>

Re: mod_perl virtual web hosting

[Tom Brown]

> >
> >I'm reading between the lines here, but it sounds like you are trying to
> >have _one_ parent apache daemon that services _everything_ on the machine
> >(likely _more_ than one website), which would imply that you are going to
> >have an _extremely_ low hit ratio on your mod_perl scripts.
> 
> nahh, that's not where we were going with it. I am pretty sure it's just a
> "maximum flexibility" feature they want to have on hand to minimize tech
> support, etc.  Why does DSO waste so much memory? I thought DSO would mean
> all processes share the resident copy of the perl library?

I'm speaking through my hat for a couple of reasons.
a) I've never used DSO
b) I don't know that much about your configuration.

1) if mod_perl isn't loaded by the parent apache process, then every time
it gets loaded by a child process, the memory consumed by mod_perl itself
is _not_ shared. (it's possible the actual code [text segment] might be
shared, but any data structures etc will not be -- dynamic linking is
not my cup of tea).

2) if you had (and it sounds like I was wrong,) one parent daemon handling
the requests for 100 virtual servers, then on average you'd have 100 times
as many child processes as needed for 'just' the mod_perl site. That also
means that your scripts are compiled and cached in 100 times more daemons
than needed, and conversely (same issue, different angle), you are 100
times _less_ likely to find that your script has already been compiled
when you hit a given page.

Hopefully someone on the list can provide the definative answers, lord
knows this is one list that still has a high Guru/beginner ratio ;-) And
the debian fellow debugging the DSO trouble sounded Knowledgable :-)

> >it strikes me that you _want_ a frontend proxy to feed your requests to
> >the smallest number of backend daemons which are most likely to already
> >have compiled your scripts. This saves memory and CPU, while simplifying
> >the configuration, and of course, for a dedicated backend daemon, DSO buys
> >nothing... even if that daemon uses access handlers, it still always needs
> >mod_perl
> 
> remember we're talking an entire ISP, not just a website. I think it might
> be a mighty pain to have everyone running or sharing some backend mod_perl
> server. Logs and all that.

Huh? The same techniques used to separate the logs for the frontend
server(s) can be used to split the backend logs, if you even use any log
info other than the error_log from the backend (they would just repeat the
frontend logs).

> >That said, we bought modperl-space.com back when domains suddenly got
> >cheap, but haven't put together a mod_perl package because we really don't
> >know what folks want/are using it for.
> 
> seems like most folks with enough ?? to be using mod_perl are either
> working corporate or have their own hosts and don't have to deal with ISP's
> on the mod_perl issue.  

True.

--
[EMAIL PROTECTED]   | Drive thy business, or it will drive thee.
http://BareMetal.com/  | - Benjamin Franklin
web hosting since '95  | 

Re: mod_perl virtual web hosting

[Gunther Birznieks]

Yeah, this was officially announced at iserver 3-4 weeks ago. It's been in beta
testing for months.

I would say that the only weird thing about it is that they only give you one
server config so a lot of the lightweight front-end, heavyweight-perl back-end
stuff in the guide is a bit useless for iserver.

I don't know if the same issues exist for other "generic" mod_perl virtual server
hosting packages. But it is something to watch for if the intent is superfast
performance of your website (as opposed to just fast).

However, it definately does speed things up. And they have an interesting virtual
server model with a lot of value-added features (eg browsable backups you can
restore yourself) that you have to email a sysadmin at most small ISPs to help
you with manually.

Later,
   Gunther

Ron Pero wrote:

> I haven't used it, but a friend mentioned that iserver has virtual servers
> on which you can configure mod_perl. http://www.iserver.com/
>
> At 01:26 PM 04/12/00 -0400, Gagan Prakash wrote:
> >Hello,
> >
> >I have been looking for mod_perl virtual web hosting companies who have fast
> >servers and good infrastructure but the two I have found so far have either
> >had problems with their mod_perl setups (they installed the module, did not
> >change apache configs or changed them incorrectly) or have been very slow.
> >These two are www.123hostme.com or www.olm.net.
> >
> >I would greatly appreciate if somebody could point me in a better direction.
> >
> >Thanks
> >Gagan
> >
> >
> >** Web App Development  Needs? ***
> >  Contact OSATech today! http://www.OSATech.com
> >***
> >
> >- Original Message -
> >From: "Jason Murphy" <[EMAIL PROTECTED]>
> >To: "Doug MacEachern" <[EMAIL PROTECTED]>
> >Cc: <[EMAIL PROTECTED]>
> >Sent: Wednesday, April 12, 2000 1:09 PM
> >Subject: Re: $r->args troubles...
> >
> >
> >>
> >> You would have guessed right. However, the problem was two fold in my
> >case.
> >>
> >> First, I was not calling Apache::Request correctly. The proper method to
> >> call Apache was told to me by Doug Kyle (Giving credit where due!). Below
> >is
> >> how it is done.
> >>
> >> <--- Begin Example
> >>
> >> my $r = Apache->request;
> >> my $apr = Apache::Request->new($r);
> >>
> >> my %params = $apr->args;
> >>
> >> print $params{"Player"};
> >>
> >> < End Example
> >>
> >> The 'print $params{"Player"}' would be used to get and print something
> >like
> >> the parameters from the URL of a GET like
> >> "www.example.com/find_player.pl?Player=Mullen" (Not a real site, dont
> >> click!).
> >>
> >> Second part of my problem was that I had an error in my Apache::Registry
> >> setup in Apache.conf or perl.conf (Can't remember where I put it). The
> >> script I was running was not being picked up by Apache::Registry and thus
> >> not working.
> >>
> >>  Thanks for everyone's help.
> >>
> >> PS. The only reason I say this on the mailing list is to get it in to the
> >> mailing list archives because I could not my solution there when I looked.
> >>
> >>
> >> From: "Doug MacEachern" <[EMAIL PROTECTED]>
> >> To: "Jason Murphy" <[EMAIL PROTECTED]>
> >> Cc: <[EMAIL PROTECTED]>
> >> Sent: Tuesday, April 11, 2000 8:52 PM
> >> Subject: Re: $r->args troubles...
> >>
> >> > On Fri, 7 Apr 2000, Jason Murphy wrote:
> >> > > Can't locate object method "new" via package "Apache::Request" at
> >> > > ./find_player.pl line 10.
> >> >
> >> > that would normally indicate your script is running under mod_cgi, not
> >> > mod_perl.
> >> >
> >> > > my $r = new Apache::Request;  <---Where the error appears
> >> >
> >> > in any case, you need to change that to:
> >> >
> >> > my $r = Apache::Request->new(shift);
> >> > or
> >> > my $r = Apache::Request->new(Apache->request);
> >> >
> >> >
> >>
> >> --
> >>  Jason Murphy
> >>  System Administrator
> >>  Lawinfo.com
> >>  1-800-397-3743 ex: 133
> >>
> >>
> >>
> >
> >

Re: mod_perl virtual web hosting

[Gagan Prakash]

Thanks everyone. I did check the listing at
perl.apache.org but many fo the organization appear to
be resellers. I have the unique situation of setting
up a site for India and thus need the host to be as
close as possible to a central internet node.

I will check out iserver and use them if it works
otherwise I will wait for superb.net.

It has been a nightmare dealing with various webhosts.
In some cases the sales and techn support people
indicate that they have mod_perl. Some companies make
that claim on their homepage. When it comes down to
it, they either don't have it, dont want it, or dont
want to understand it.

I have wasted atleast 3 hours trying to explain it to
olm.net...the customer support people just dont get
it. I would not recommend them to anyone.

Thanks
Gagan
--- Jesse Wolfe <[EMAIL PROTECTED]> wrote:
> I am working with www.superb.net to get their
> mod_perl up and working
> again. They have great infrastrucure, lots of great
> tools, and an amazing
> price.
> They had apache/mod_perl for awhile, and upgrades
> broke it.  I expect they
> will have it in a week or two, if we can use all
> these dynamic/shared
> modules as planned. 
> 
> I'm moving my mod-perl project there once I get it
> going. Have you checked
> out the list on perl.apache.org's documentation?
> 
> Jesse
> 
> 
> At 01:26 PM 4/12/00 -0400, Gagan Prakash wrote:
> >Hello,
> >
> >I have been looking for mod_perl virtual web
> hosting companies who have fast
> >servers and good infrastructure but the two I have
> found so far have either
> >had problems with their mod_perl setups (they
> installed the module, did not
> >change apache configs or changed them incorrectly)
> or have been very slow.
> >These two are www.123hostme.com or www.olm.net.
> >
> >I would greatly appreciate if somebody could point
> me in a better direction.
> >
> >Thanks
> >Gagan
> >
> >
> >** Web App Development  Needs?
> ***
> >  Contact OSATech today!
> http://www.OSATech.com
> >***
> >
> >- Original Message -
> >From: "Jason Murphy" <[EMAIL PROTECTED]>
> >To: "Doug MacEachern" <[EMAIL PROTECTED]>
> >Cc: <[EMAIL PROTECTED]>
> >Sent: Wednesday, April 12, 2000 1:09 PM
> >Subject: Re: $r->args troubles...
> >
> >
> >>
> >> You would have guessed right. However, the
> problem was two fold in my
> >case.
> >>
> >> First, I was not calling Apache::Request
> correctly. The proper method to
> >> call Apache was told to me by Doug Kyle (Giving
> credit where due!). Below
> >is
> >> how it is done.
> >>
> >> <--- Begin Example
> >>
> >> my $r = Apache->request;
> >> my $apr = Apache::Request->new($r);
> >>
> >> my %params = $apr->args;
> >>
> >> print $params{"Player"};
> >>
> >> < End Example
> >>
> >> The 'print $params{"Player"}' would be used to
> get and print something
> >like
> >> the parameters from the URL of a GET like
> >> "www.example.com/find_player.pl?Player=Mullen"
> (Not a real site, dont
> >> click!).
> >>
> >> Second part of my problem was that I had an error
> in my Apache::Registry
> >> setup in Apache.conf or perl.conf (Can't remember
> where I put it). The
> >> script I was running was not being picked up by
> Apache::Registry and thus
> >> not working.
> >>
> >>  Thanks for everyone's help.
> >>
> >> PS. The only reason I say this on the mailing
> list is to get it in to the
> >> mailing list archives because I could not my
> solution there when I looked.
> >>
> >>
> >> From: "Doug MacEachern" <[EMAIL PROTECTED]>
> >> To: "Jason Murphy" <[EMAIL PROTECTED]>
> >> Cc: <[EMAIL PROTECTED]>
> >> Sent: Tuesday, April 11, 2000 8:52 PM
> >> Subject: Re: $r->args troubles...
> >>
> >> > On Fri, 7 Apr 2000, Jason Murphy wrote:
> >> > > Can't locate object method "new" via package
> "Apache::Request" at
> >> > > ./find_player.pl line 10.
> >> >
> >> > that would normally indicate your script is
> running under mod_cgi, not
> >> > mod_perl.
> >> >
> >> > > my $r = new Apache::Request;  <---Where the
> error appears
> >> >
> >> > in any case, you need to change that to:
> >> >
> >> > my $r = Apache::Request->new(shift);
> >> > or
> >> > my $r = Apache::Request->new(Apache->request);
> >> >
> >> >
> >>
> >> --
> >>  Jason Murphy
> >>  System Administrator
> >>  Lawinfo.com
> >>  1-800-397-3743 ex: 133
> >>
> >>
> >>
> >
> >
> 
> Jesse Wolfe, ICQ #19734806
> AllHeal, a Global Healing Village
> "Healing our World, One Life at a Time."
> http://www.allheal.com
> Want to pay less for long distance? -
> http://ld.net?claritycom
>  
> 
> 

__
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

Re: mod_perl virtual web hosting

[Leslie Mikesell]

According to Tom Brown:
> 
> strikes me (as an owner of a web hosting service) that DSO is the wrong
> answer. What does DSO buy you? NOTHING except a complete waste of
> memory... 

It doesn't really hurt anything but you still want a proxy.

> it strikes me that you _want_ a frontend proxy to feed your requests to
> the smallest number of backend daemons which are most likely to already
> have compiled your scripts. This saves memory and CPU, while simplifying
> the configuration, and of course, for a dedicated backend daemon, DSO buys
> nothing... even if that daemon uses access handlers, it still always needs
> mod_perl

If someone is ambitious enough to write some C code, what you really
need is a way for mod_proxy to actually start a new backend if
none are already running for a particular vhost.  Then the
backend processes should extend the concept of killing off
excess children to the point of completely exiting after a
certain length of inactivity.  The same approach could also
work for running scripts under different userids.  I think
sometime in the distant past I have seen programs started
by inetd that would continue to listen in standalone mode
for a while to make subsequent connections faster but I
don't recall how it worked.

  Les Mikesell
[EMAIL PROTECTED]

Re: mod_perl virtual web hosting

[Jesse Wolfe]

At 02:54 PM 4/12/00 -0700, Tom Brown wrote:
>On Wed, 12 Apr 2000, Jesse Wolfe wrote:
>
>> I am working with www.superb.net to get their mod_perl up and working
>> again. They have great infrastrucure, lots of great tools, and an amazing
>> price.
>> They had apache/mod_perl for awhile, and upgrades broke it.  I expect they
>> will have it in a week or two, if we can use all these dynamic/shared
>> modules as planned. 
>
>strikes me (as an owner of a web hosting service) that DSO is the wrong
>answer. What does DSO buy you? NOTHING except a complete waste of
>memory... 

well, it would let each customer add their own combo of modules to their
apache server without requiring either two installs (one with, one without
mod_perl) or making everyone's server run mod_perl even if they aren't
using it.

But it is a good question... I found it kind of unusual to request that
EVERY Apache module be dso, including mod_perl, mod_ssl, PHP3, and libdav.
I'm not even sure that it's possible that it will run well. Any advise
anyone has here would be most appreciated.

I'm actually kind of surprised I got mod_perl DSO 'make test' to pass at all.

>
>I'm reading between the lines here, but it sounds like you are trying to
>have _one_ parent apache daemon that services _everything_ on the machine
>(likely _more_ than one website), which would imply that you are going to
>have an _extremely_ low hit ratio on your mod_perl scripts.

nahh, that's not where we were going with it. I am pretty sure it's just a
"maximum flexibility" feature they want to have on hand to minimize tech
support, etc.  Why does DSO waste so much memory? I thought DSO would mean
all processes share the resident copy of the perl library?

>
>it strikes me that you _want_ a frontend proxy to feed your requests to
>the smallest number of backend daemons which are most likely to already
>have compiled your scripts. This saves memory and CPU, while simplifying
>the configuration, and of course, for a dedicated backend daemon, DSO buys
>nothing... even if that daemon uses access handlers, it still always needs
>mod_perl

remember we're talking an entire ISP, not just a website. I think it might
be a mighty pain to have everyone running or sharing some backend mod_perl
server. Logs and all that.

>
>That said, we bought modperl-space.com back when domains suddenly got
>cheap, but haven't put together a mod_perl package because we really don't
>know what folks want/are using it for.

seems like most folks with enough ?? to be using mod_perl are either
working corporate or have their own hosts and don't have to deal with ISP's
on the mod_perl issue.  With all this talk about mod_perl programmers being
needed, I'm surprised to find so few ISP's offering it.  Bottom line it
seems you need to be able to keep a mod_perl guru on hand just to keep it
going... the compilation, etc. of it is so complex. I actually need to
leave my original mod_perl isp because they just don't have the staff to
make the right mods to their system, even if I figure it out for them.
Their mod_perl person got up and left and they can't seem to hire a
replacement. Anyone in Boston area would like to work with a pretty decent
ISP?

Regards,

Jesse

Re: mod_perl virtual web hosting

[Tom Brown]

On Wed, 12 Apr 2000, Jesse Wolfe wrote:

> I am working with www.superb.net to get their mod_perl up and working
> again. They have great infrastrucure, lots of great tools, and an amazing
> price.
> They had apache/mod_perl for awhile, and upgrades broke it.  I expect they
> will have it in a week or two, if we can use all these dynamic/shared
> modules as planned. 

strikes me (as an owner of a web hosting service) that DSO is the wrong
answer. What does DSO buy you? NOTHING except a complete waste of
memory... 

I'm reading between the lines here, but it sounds like you are trying to
have _one_ parent apache daemon that services _everything_ on the machine
(likely _more_ than one website), which would imply that you are going to
have an _extremely_ low hit ratio on your mod_perl scripts.

it strikes me that you _want_ a frontend proxy to feed your requests to
the smallest number of backend daemons which are most likely to already
have compiled your scripts. This saves memory and CPU, while simplifying
the configuration, and of course, for a dedicated backend daemon, DSO buys
nothing... even if that daemon uses access handlers, it still always needs
mod_perl

That said, we bought modperl-space.com back when domains suddenly got
cheap, but haven't put together a mod_perl package because we really don't
know what folks want/are using it for.

> 
> I'm moving my mod-perl project there once I get it going. Have you checked
> out the list on perl.apache.org's documentation?
> 
> Jesse
> 
> 
> At 01:26 PM 4/12/00 -0400, Gagan Prakash wrote:
> >Hello,
> >
> >I have been looking for mod_perl virtual web hosting companies who have fast
> >servers and good infrastructure but the two I have found so far have either
> >had problems with their mod_perl setups (they installed the module, did not
> >change apache configs or changed them incorrectly) or have been very slow.
> >These two are www.123hostme.com or www.olm.net.

last I heard, olm.net treated their resellers well, but their
tech support to direct clients was supposed to be pretty poor.

> >
> >I would greatly appreciate if somebody could point me in a better direction.
> >
> >Thanks
> >Gagan

----------
[EMAIL PROTECTED]   | Drive thy business, or it will drive thee.
http://BareMetal.com/  | - Benjamin Franklin
web hosting since '95  | 

Re: mod_perl virtual web hosting

[Peter J. Schoenster]

On 12 Apr 2000, at 13:26, Gagan Prakash wrote:

> I have been looking for mod_perl virtual web hosting companies
> who have fast servers and good infrastructure but the two I have
> found so far have either had problems with their mod_perl setups
> (they installed the module, did not change apache configs or
> changed them incorrectly) or have been very slow. These two are
> www.123hostme.com or www.olm.net.

I have used iserver.com for the last 4 years.  There were 
iserver before Verio bought them.   I just installed mod_perl on 
a server where I used it for some database work. The response 
time is excellent.

But .. but if you want instructions on how to install modules on 
their virtual server, use the instructions here (don't use cpan 
or vcpan .. but use their install of base mod_perl):

http://www.iserver.com/support/addonhelp/proglang/perl/modules.ht
ml

Notice this on that page:

> Installing Perl5 Modules Yourself 
> The content on this page is adapted from Answers to Some Perl/CGI
> Questions, by Bekman Stas. 

I would highly recommend iserver (I don't know about verio).

Peter



---
"Reality is that which, when you stop believing in it, doesn't go
away".
-- Philip K. Dick

Re: mod_perl virtual web hosting

[Jesse Wolfe]

I am working with www.superb.net to get their mod_perl up and working
again. They have great infrastrucure, lots of great tools, and an amazing
price.
They had apache/mod_perl for awhile, and upgrades broke it.  I expect they
will have it in a week or two, if we can use all these dynamic/shared
modules as planned. 

I'm moving my mod-perl project there once I get it going. Have you checked
out the list on perl.apache.org's documentation?

Jesse


At 01:26 PM 4/12/00 -0400, Gagan Prakash wrote:
>Hello,
>
>I have been looking for mod_perl virtual web hosting companies who have fast
>servers and good infrastructure but the two I have found so far have either
>had problems with their mod_perl setups (they installed the module, did not
>change apache configs or changed them incorrectly) or have been very slow.
>These two are www.123hostme.com or www.olm.net.
>
>I would greatly appreciate if somebody could point me in a better direction.
>
>Thanks
>Gagan
>
>
>** Web App Development  Needs? ***
>  Contact OSATech today! http://www.OSATech.com
>***
>
>- Original Message -
>From: "Jason Murphy" <[EMAIL PROTECTED]>
>To: "Doug MacEachern" <[EMAIL PROTECTED]>
>Cc: <[EMAIL PROTECTED]>
>Sent: Wednesday, April 12, 2000 1:09 PM
>Subject: Re: $r->args troubles...
>
>
>>
>> You would have guessed right. However, the problem was two fold in my
>case.
>>
>> First, I was not calling Apache::Request correctly. The proper method to
>> call Apache was told to me by Doug Kyle (Giving credit where due!). Below
>is
>> how it is done.
>>
>> <--- Begin Example
>>
>> my $r = Apache->request;
>> my $apr = Apache::Request->new($r);
>>
>> my %params = $apr->args;
>>
>> print $params{"Player"};
>>
>> < End Example
>>
>> The 'print $params{"Player"}' would be used to get and print something
>like
>> the parameters from the URL of a GET like
>> "www.example.com/find_player.pl?Player=Mullen" (Not a real site, dont
>> click!).
>>
>> Second part of my problem was that I had an error in my Apache::Registry
>> setup in Apache.conf or perl.conf (Can't remember where I put it). The
>> script I was running was not being picked up by Apache::Registry and thus
>> not working.
>>
>>  Thanks for everyone's help.
>>
>> PS. The only reason I say this on the mailing list is to get it in to the
>> mailing list archives because I could not my solution there when I looked.
>>
>>
>> From: "Doug MacEachern" <[EMAIL PROTECTED]>
>> To: "Jason Murphy" <[EMAIL PROTECTED]>
>> Cc: <[EMAIL PROTECTED]>
>> Sent: Tuesday, April 11, 2000 8:52 PM
>> Subject: Re: $r->args troubles...
>>
>> > On Fri, 7 Apr 2000, Jason Murphy wrote:
>> > > Can't locate object method "new" via package "Apache::Request" at
>> > > ./find_player.pl line 10.
>> >
>> > that would normally indicate your script is running under mod_cgi, not
>> > mod_perl.
>> >
>> > > my $r = new Apache::Request;  <---Where the error appears
>> >
>> > in any case, you need to change that to:
>> >
>> > my $r = Apache::Request->new(shift);
>> > or
>> > my $r = Apache::Request->new(Apache->request);
>> >
>> >
>>
>> --
>>  Jason Murphy
>>  System Administrator
>>  Lawinfo.com
>>  1-800-397-3743 ex: 133
>>
>>
>>
>
>

Jesse Wolfe, ICQ #19734806
AllHeal, a Global Healing Village
"Healing our World, One Life at a Time."
http://www.allheal.com
Want to pay less for long distance? - http://ld.net?claritycom
 

Re: mod_perl virtual web hosting

[Ron Pero]

I haven't used it, but a friend mentioned that iserver has virtual servers
on which you can configure mod_perl. http://www.iserver.com/

At 01:26 PM 04/12/00 -0400, Gagan Prakash wrote:
>Hello,
>
>I have been looking for mod_perl virtual web hosting companies who have fast
>servers and good infrastructure but the two I have found so far have either
>had problems with their mod_perl setups (they installed the module, did not
>change apache configs or changed them incorrectly) or have been very slow.
>These two are www.123hostme.com or www.olm.net.
>
>I would greatly appreciate if somebody could point me in a better direction.
>
>Thanks
>Gagan
>
>
>** Web App Development  Needs? ***
>  Contact OSATech today! http://www.OSATech.com
>***
>
>- Original Message -
>From: "Jason Murphy" <[EMAIL PROTECTED]>
>To: "Doug MacEachern" <[EMAIL PROTECTED]>
>Cc: <[EMAIL PROTECTED]>
>Sent: Wednesday, April 12, 2000 1:09 PM
>Subject: Re: $r->args troubles...
>
>
>>
>> You would have guessed right. However, the problem was two fold in my
>case.
>>
>> First, I was not calling Apache::Request correctly. The proper method to
>> call Apache was told to me by Doug Kyle (Giving credit where due!). Below
>is
>> how it is done.
>>
>> <--- Begin Example
>>
>> my $r = Apache->request;
>> my $apr = Apache::Request->new($r);
>>
>> my %params = $apr->args;
>>
>> print $params{"Player"};
>>
>> < End Example
>>
>> The 'print $params{"Player"}' would be used to get and print something
>like
>> the parameters from the URL of a GET like
>> "www.example.com/find_player.pl?Player=Mullen" (Not a real site, dont
>> click!).
>>
>> Second part of my problem was that I had an error in my Apache::Registry
>> setup in Apache.conf or perl.conf (Can't remember where I put it). The
>> script I was running was not being picked up by Apache::Registry and thus
>> not working.
>>
>>  Thanks for everyone's help.
>>
>> PS. The only reason I say this on the mailing list is to get it in to the
>> mailing list archives because I could not my solution there when I looked.
>>
>>
>> From: "Doug MacEachern" <[EMAIL PROTECTED]>
>> To: "Jason Murphy" <[EMAIL PROTECTED]>
>> Cc: <[EMAIL PROTECTED]>
>> Sent: Tuesday, April 11, 2000 8:52 PM
>> Subject: Re: $r->args troubles...
>>
>> > On Fri, 7 Apr 2000, Jason Murphy wrote:
>> > > Can't locate object method "new" via package "Apache::Request" at
>> > > ./find_player.pl line 10.
>> >
>> > that would normally indicate your script is running under mod_cgi, not
>> > mod_perl.
>> >
>> > > my $r = new Apache::Request;  <---Where the error appears
>> >
>> > in any case, you need to change that to:
>> >
>> > my $r = Apache::Request->new(shift);
>> > or
>> > my $r = Apache::Request->new(Apache->request);
>> >
>> >
>>
>> --
>>  Jason Murphy
>>  System Administrator
>>  Lawinfo.com
>>  1-800-397-3743 ex: 133
>>
>>
>>
>
>

mod_perl virtual web hosting

[Gagan Prakash]

Hello,

I have been looking for mod_perl virtual web hosting companies who have fast
servers and good infrastructure but the two I have found so far have either
had problems with their mod_perl setups (they installed the module, did not
change apache configs or changed them incorrectly) or have been very slow.
These two are www.123hostme.com or www.olm.net.

I would greatly appreciate if somebody could point me in a better direction.

Thanks
Gagan


** Web App Development  Needs? ***
  Contact OSATech today! http://www.OSATech.com
***

- Original Message -
From: "Jason Murphy" <[EMAIL PROTECTED]>
To: "Doug MacEachern" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, April 12, 2000 1:09 PM
Subject: Re: $r->args troubles...


>
> You would have guessed right. However, the problem was two fold in my
case.
>
> First, I was not calling Apache::Request correctly. The proper method to
> call Apache was told to me by Doug Kyle (Giving credit where due!). Below
is
> how it is done.
>
> <--- Begin Example
>
> my $r = Apache->request;
> my $apr = Apache::Request->new($r);
>
> my %params = $apr->args;
>
> print $params{"Player"};
>
> < End Example
>
> The 'print $params{"Player"}' would be used to get and print something
like
> the parameters from the URL of a GET like
> "www.example.com/find_player.pl?Player=Mullen" (Not a real site, dont
> click!).
>
> Second part of my problem was that I had an error in my Apache::Registry
> setup in Apache.conf or perl.conf (Can't remember where I put it). The
> script I was running was not being picked up by Apache::Registry and thus
> not working.
>
>  Thanks for everyone's help.
>
> PS. The only reason I say this on the mailing list is to get it in to the
> mailing list archives because I could not my solution there when I looked.
>
>
> From: "Doug MacEachern" <[EMAIL PROTECTED]>
> To: "Jason Murphy" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Tuesday, April 11, 2000 8:52 PM
> Subject: Re: $r->args troubles...
>
> > On Fri, 7 Apr 2000, Jason Murphy wrote:
> > > Can't locate object method "new" via package "Apache::Request" at
> > > ./find_player.pl line 10.
> >
> > that would normally indicate your script is running under mod_cgi, not
> > mod_perl.
> >
> > > my $r = new Apache::Request;  <---Where the error appears
> >
> > in any case, you need to change that to:
> >
> > my $r = Apache::Request->new(shift);
> > or
> > my $r = Apache::Request->new(Apache->request);
> >
> >
>
> --
>  Jason Murphy
>  System Administrator
>  Lawinfo.com
>  1-800-397-3743 ex: 133
>
>
>