mod_perl waters too deep

You may have seen my other recent questions to the list this month, the
gist of which is:

I want to setup an application for multiple clients, each of whom have
their own users.

http://www.site.com/clientA/application.pl
http://www.site.com/clientB/application.pl
http://www.site.com/clientX/application.pl

So the users of "clientA" log in to
http://www.site.com/clientA/application.pl and are authenticated with
Apache2::AuthCookieDBI

Now the directories clientA, clientB, etc. do not exist, I'm using
mod_rewrite to sort that out, and here starts my problems. First I'm
lost with authenticating since there's no "real" resource to
authenticate against, but I seem to have solved that by forcing
authentication against all *.pl files which luckily do exist ;)

It gets more complicated later because some URLs like
http://www.site.com/clientA/iCal can't use session cookies but have to
use BASIC AUTH, and other *.pl files can't have any authentication
applied against them.

I thought I could solve this by writing a MyAuthCookieDBI.pm but this
also isn't working out. For example MyAuthCookieDBI is an almost-empty
child. The parent (Apache2::AuthCookieDBI) has a function
_dbi_connect() which manages all the database connecting, but I can't
overwrite that function, even if MyAuthCookieDBI is the calling object
the function from Apache2::AuthCookieDBI always gets called rather than
the overridden function in my object.

That's kind of the tip of things, basically I'm realizing that I need
professional help with this task before I end up requiring professional
help for my nerves!

So if anyone can help with this then please contact me offlist with terms.

Thanks!

Tosh

--
McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/

Re: mod_perl waters too deep

Hi Tosh,

Have you considered using a Web framework like Catalyst? I haven't used
Catalyst, but a cursory read of your problems makes me think that a Web
framework may have already solved most of your problems.

Take care,

Kurt Hansen
khansen@charityweb.net

Tosh Cooey wrote:
> You may have seen my other recent questions to the list this month,
> the gist of which is:
>
> I want to setup an application for multiple clients, each of whom have
> their own users.
>
> http://www.site.com/clientA/application.pl
> http://www.site.com/clientB/application.pl
> http://www.site.com/clientX/application.pl
>
> So the users of "clientA" log in to
> http://www.site.com/clientA/application.pl and are authenticated with
> Apache2::AuthCookieDBI
>
> Now the directories clientA, clientB, etc. do not exist, I'm using
> mod_rewrite to sort that out, and here starts my problems. First I'm
> lost with authenticating since there's no "real" resource to
> authenticate against, but I seem to have solved that by forcing
> authentication against all *.pl files which luckily do exist ;)
>
> It gets more complicated later because some URLs like
> http://www.site.com/clientA/iCal can't use session cookies but have to
> use BASIC AUTH, and other *.pl files can't have any authentication
> applied against them.
>
> I thought I could solve this by writing a MyAuthCookieDBI.pm but this
> also isn't working out. For example MyAuthCookieDBI is an
> almost-empty child. The parent (Apache2::AuthCookieDBI) has a
> function _dbi_connect() which manages all the database connecting, but
> I can't overwrite that function, even if MyAuthCookieDBI is the
> calling object the function from Apache2::AuthCookieDBI always gets
> called rather than the overridden function in my object.
>
> That's kind of the tip of things, basically I'm realizing that I need
> professional help with this task before I end up requiring
> professional help for my nerves!
>
> So if anyone can help with this then please contact me offlist with
> terms.
>
> Thanks!
>
> Tosh
>

Re: mod_perl waters too deep

>>>>> "Tosh" == Tosh Cooey writes:

Tosh> I want to setup an application for multiple clients, each of whom have their
Tosh> own users.

Tosh> http://www.site.com/clientA/application.pl
Tosh> http://www.site.com/clientB/application.pl
Tosh> http://www.site.com/clientX/application.pl

Just an aside, but

(a) can your clients load their own code onto the server without you
intervening, and if so
(b) do all of your clients *absolutely* trust each other?

I'm saying this because I'm not sure if you realize that the trust domain for
mod_perl is the entire server. If I can upload code to the same server you're
using, I can mess up your day, pretty bad, because the Perl interpreters are
necessarily shared.

For example, I can patch the loaded CGI.pm so that if it sees your code and a
secret extra parameter, it automatically gives me complete access to your
data.

This is why there are no "shared hosting" plans for mod_perl that don't
require running completely separate clusters of apache servers. There's
nothing like "su-exec" for mod_perl - it's not even possible.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095

Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Re: mod_perl waters too deep

Hi Randal, sorry my message wasn't concise enough, perhaps I was letting
the haze of it reflect my haze of this problem...

Anyway, this is not a hosting environment. This is an application, for
example like GMail for Business is an email application that lets a
business, like mine, go to:

http://mail.google.com/a/1200group.com/

There my users can log in and check their mails.

I assume the "1200group.com" is being used as a key to identify which
database to lookup the users in, or something similar.

I want to accomplish the same:

http://www.site.com/clientA/calendar.pl

So all users of "clientA", if they go to the above link, would be
prompted to log in and my MyAuthCookieDBI would handle this on the fly.

On a side note, Matisse Enzer the author of Apache2::AuthCookieDBI just
informed me that I can override the methods in his module like this:

*Apache2::AuthCookieDBI::_dbi_connect = sub { # your code goes here };

So there seems to be some light at the end of the tunnel, but I do see a
large truck coming towards me in the form of the next problem which is I
need different authentication methods for different uses of my
application. I'm not too sure if I can change Auth methods on the fly
in MyAuthCookieDBI, or if I need to assign these different
authentication schemes to different path directives. I suspect the
small light at the end of my tunnel is in fact a bullet train...

Thanks again for letting me clarify Randal!

Tosh



Randal L. Schwartz wrote:
>>>>>> "Tosh" == Tosh Cooey writes:
>
> Tosh> I want to setup an application for multiple clients, each of whom have their
> Tosh> own users.
>
> Tosh> http://www.site.com/clientA/application.pl
> Tosh> http://www.site.com/clientB/application.pl
> Tosh> http://www.site.com/clientX/application.pl
>
> Just an aside, but
>
> (a) can your clients load their own code onto the server without you
> intervening, and if so
> (b) do all of your clients *absolutely* trust each other?
>
> I'm saying this because I'm not sure if you realize that the trust domain for
> mod_perl is the entire server. If I can upload code to the same server you're
> using, I can mess up your day, pretty bad, because the Perl interpreters are
> necessarily shared.
>
> For example, I can patch the loaded CGI.pm so that if it sees your code and a
> secret extra parameter, it automatically gives me complete access to your
> data.
>
> This is why there are no "shared hosting" plans for mod_perl that don't
> require running completely separate clusters of apache servers. There's
> nothing like "su-exec" for mod_perl - it's not even possible.
>

--
McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/

Re: mod_perl waters too deep

Tosh Cooey wrote:
> You may have seen my other recent questions to the list this month, the
> gist of which is:
>
> I want to setup an application for multiple clients, each of whom have
> their own users.
>
> http://www.site.com/clientA/application.pl
> http://www.site.com/clientB/application.pl
> http://www.site.com/clientX/application.pl
>
> So the users of "clientA" log in to
> http://www.site.com/clientA/application.pl and are authenticated with
> Apache2::AuthCookieDBI
>
> Now the directories clientA, clientB, etc. do not exist, I'm using
> mod_rewrite to sort that out, and here starts my problems. First I'm
> lost with authenticating since there's no "real" resource to
> authenticate against, but I seem to have solved that by forcing
> authentication against all *.pl files which luckily do exist ;)
>
> It gets more complicated later because some URLs like
> http://www.site.com/clientA/iCal can't use session cookies but have to
> use BASIC AUTH, and other *.pl files can't have any authentication
> applied against them.

Hi. I kind of remember your posts, and kind of remember also that I
thought that you were going about this the hard way.

I am more than willing to assist you professionally (since that's what I
do for a living), but in the meantime, what stops you from doing
something like this :


AuthType MyOwn
PerlSetVar MyAuthType "form"
PerlAuthenHandler my::module::dbi-based
...


AuthType MyOwn
PerlSetVar MyAuthType "basic"
PerlAuthenHandler my::module::dbi-based (or whatever)
...


AuthType nothing
PerlSetVar MyAuthType "auto"
PerlSetVar MyAutoId "anonymous"
PerlAuthenHandler my::module::dbi-based (or whatever)



AuthType MyOwn
PerlSetVar MyAuthType "form"
PerlAuthenHandler my::module::dbi-based
...


AuthType MyOwn
PerlSetVar MyAuthType "basic"
PerlAuthenHandler my::module::dbi-based (or whatever)
...

etc...

(You can use LocationMatch in case you need finer control)

If you really have only a few different "clientX", then that seems like
an easy enough configuration.
(If you have many, then it may be easier to do this another way, and
have your module determine which "clientX" this is and react appropriately.)


Apache itself will pick the "most precise" matching Location section
applying to the request URL.
Your authentication module should check on $r->dir_config('MyAuthType')
to determine what kind of authentication to use with the client
(form-based, basic or none).

Maybe it is not time for a nervous breakdown yet..
;-)

Re: mod_perl waters too deep

On Monday 14 December 2009 16:14:31 Tosh Cooey wrote:
> You may have seen my other recent questions to the list this month, the
> gist of which is:
>=20
> I want to setup an application for multiple clients, each of whom have
> their own users.
>=20
> http://www.site.com/clientA/application.pl
> http://www.site.com/clientB/application.pl
> http://www.site.com/clientX/application.pl
>=20
> So the users of "clientA" log in to
> http://www.site.com/clientA/application.pl and are authenticated with
> Apache2::AuthCookieDBI
>=20
> Now the directories clientA, clientB, etc. do not exist, I'm using
> mod_rewrite to sort that out, and here starts my problems. First I'm
> lost with authenticating since there's no "real" resource to
> authenticate against, but I seem to have solved that by forcing
> authentication against all *.pl files which luckily do exist ;)
>=20
> It gets more complicated later because some URLs like
> http://www.site.com/clientA/iCal can't use session cookies but have to
> use BASIC AUTH, and other *.pl files can't have any authentication
> applied against them.
>=20
> I thought I could solve this by writing a MyAuthCookieDBI.pm but this
> also isn't working out. For example MyAuthCookieDBI is an almost-empty
> child. The parent (Apache2::AuthCookieDBI) has a function
> _dbi_connect() which manages all the database connecting, but I can't
> overwrite that function, even if MyAuthCookieDBI is the calling object
> the function from Apache2::AuthCookieDBI always gets called rather than
> the overridden function in my object.
>=20
> That's kind of the tip of things, basically I'm realizing that I need
> professional help with this task before I end up requiring professional
> help for my nerves!
>=20
> So if anyone can help with this then please contact me offlist with terms.

=46rom reviewing what you have posted I take it the main problem is you hav=
e a=20
huge number of clients and don't want to write a .htaccess file for each on=
e,=20
right?

There are 2 ways to solve this. 1) generate the httpd.conf on startup from =
the=20
client database adding a block for each one. That means you'd ha=
ve=20
to restart apache for each new client.

The second way is to write a simple and short (3-4 lines of code) modperl-
handler that adds the right configuration directives to the request dependi=
ng=20
on the url. The trick when to do that within the request cycle.

Auth-directives are applied just after the HeaderParser phase. So, the last=
=20
chance to add authentication stuff is the header parser phase. Unfortunatel=
y=20
this phase is skipped for subrequests. So, if you want to catch subrequests=
as=20
well MapToStorage is the only way. But it also has its tweaks. So, let's=20
assume you use the HeaderParser phase for a start.

The PerlHeaderParserHandler would look like:

my %config=3D
(
clientA=3D>[
'AuthType Apache2::AuthCookieDBI',
'AuthName WhatEver',
'PerlAuthenHandler Apache2::AuthCookieDBI->authenticate',
'PerlAuthzHandler Apache2::AuthCookieDBI->authorize',
'require valid-user',
'PerlSetVar WhatEver... ...',
...
],
clientB=3D>...
...
);

sub ... {
my ($r)=3D@_;

return Apache2::Const::DECLINED unless $r->uri=3D~m!/([^/]+)!;
$r->add_config($config{$1});

return Apache2::Const::DECLINED;
}

What now happens is Apache reads in the request then just before deciding i=
f=20
authentication is needed the HeaderParser handler jumps in, looks at the UR=
I=20
and adds the needed configuration stuff.

Perhaps you have a look at my Apache2::Translation on CPAN. I think it's a=
=20
very handy module for complicated configurations. I wouldn't configure an=20
apache without it anymore and I know some other folks who wouldn't either.

Torsten

Re: mod_perl waters too deep

Tosh,
If your users are already verified or not, try using a switch statement
based on their inputs directing them to the needed function.
If they already have cookie info use that as your switch/case redirection.

Jay Scherrer

Tosh Cooey wrote:
> You may have seen my other recent questions to the list this month, the
> gist of which is:
>
> I want to setup an application for multiple clients, each of whom have
> their own users.
>
> http://www.site.com/clientA/application.pl
> http://www.site.com/clientB/application.pl
> http://www.site.com/clientX/application.pl
>
> So the users of "clientA" log in to
> http://www.site.com/clientA/application.pl and are authenticated with
> Apache2::AuthCookieDBI
>
> Now the directories clientA, clientB, etc. do not exist, I'm using
> mod_rewrite to sort that out, and here starts my problems. First I'm
> lost with authenticating since there's no "real" resource to
> authenticate against, but I seem to have solved that by forcing
> authentication against all *.pl files which luckily do exist ;)
>
> It gets more complicated later because some URLs like
> http://www.site.com/clientA/iCal can't use session cookies but have to
> use BASIC AUTH, and other *.pl files can't have any authentication
> applied against them.
>
> I thought I could solve this by writing a MyAuthCookieDBI.pm but this
> also isn't working out. For example MyAuthCookieDBI is an almost-empty
> child. The parent (Apache2::AuthCookieDBI) has a function
> _dbi_connect() which manages all the database connecting, but I can't
> overwrite that function, even if MyAuthCookieDBI is the calling object
> the function from Apache2::AuthCookieDBI always gets called rather than
> the overridden function in my object.
>
> That's kind of the tip of things, basically I'm realizing that I need
> professional help with this task before I end up requiring professional
> help for my nerves!
>
> So if anyone can help with this then please contact me offlist with terms.
>
> Thanks!
>
> Tosh
>

--
Register for your free "Debt reduction Calculator"


Update your WILL with
Heritage Living Trusts


=====
THE INFORMATION CONTAINED IN THIS ELECTRONIC MAIL MESSAGE IS PRIVILEGED
AND CONFIDENTIAL. THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE
PERSON OR ENTITY TO WHOM IT IS ADDRESSED ABOVE. If the reader of this
message is not the intended recipient, you are hereby notified that any
dissemination, distribution or copying of this communication is
prohibited. If you have received this communication in error, please
notify me immediately by reply email, permanently delete the original
and any copy of this email from your system and destroy any printout
thereof.
=====

Re: mod_perl waters too deep

This is one of my options, but it's down at the bottom of my desired
outcomes. The CGI::Session modules have been getting a lot of reading
lately ;)

Thanks Jay!

Tosh


Jay Scherrer wrote:
> Tosh,
> If your users are already verified or not, try using a switch statement
> based on their inputs directing them to the needed function.
> If they already have cookie info use that as your switch/case redirection.
>
> Jay Scherrer
>
> Tosh Cooey wrote:
>> You may have seen my other recent questions to the list this month,
>> the gist of which is:
>>
>> I want to setup an application for multiple clients, each of whom have
>> their own users.
>>
>> http://www.site.com/clientA/application.pl
>> http://www.site.com/clientB/application.pl
>> http://www.site.com/clientX/application.pl
>>
>> So the users of "clientA" log in to
>> http://www.site.com/clientA/application.pl and are authenticated with
>> Apache2::AuthCookieDBI
>>
>> Now the directories clientA, clientB, etc. do not exist, I'm using
>> mod_rewrite to sort that out, and here starts my problems. First I'm
>> lost with authenticating since there's no "real" resource to
>> authenticate against, but I seem to have solved that by forcing
>> authentication against all *.pl files which luckily do exist ;)
>>
>> It gets more complicated later because some URLs like
>> http://www.site.com/clientA/iCal can't use session cookies but have to
>> use BASIC AUTH, and other *.pl files can't have any authentication
>> applied against them.
>>
>> I thought I could solve this by writing a MyAuthCookieDBI.pm but this
>> also isn't working out. For example MyAuthCookieDBI is an
>> almost-empty child. The parent (Apache2::AuthCookieDBI) has a
>> function _dbi_connect() which manages all the database connecting, but
>> I can't overwrite that function, even if MyAuthCookieDBI is the
>> calling object the function from Apache2::AuthCookieDBI always gets
>> called rather than the overridden function in my object.
>>
>> That's kind of the tip of things, basically I'm realizing that I need
>> professional help with this task before I end up requiring
>> professional help for my nerves!
>>
>> So if anyone can help with this then please contact me offlist with
>> terms.
>>
>> Thanks!
>>
>> Tosh
>>
>

--
McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/

Re: mod_perl waters too deep

The PerlHeaderParserHandler would look like:

my %config=
(
clientA=>[

....

The problem is this creates a LARGE config file for 10,000+ clients, and
I'm still naive enough to dream big :)

Like I noted in a post to Randal, actually overriding the "_dbi_connect"
sub in the parent was proving to be the problem.

Matisse Enzer, the author of Apache2::AuthCookieDBI told me today that I
could do so using globs, a voodoo I have never explored before...

*Apache2::AuthCookieDBI::_dbi_connect = sub { my stuff... };

This lets me configure the DBI variables on the fly per request which is
a nicer way.

The problem now will be to figure out what problems remain.

Tosh



Torsten Förtsch wrote:
> On Monday 14 December 2009 16:14:31 Tosh Cooey wrote:
>> You may have seen my other recent questions to the list this month, the
>> gist of which is:
>>
>> I want to setup an application for multiple clients, each of whom have
>> their own users.
>>
>> http://www.site.com/clientA/application.pl
>> http://www.site.com/clientB/application.pl
>> http://www.site.com/clientX/application.pl
>>
>> So the users of "clientA" log in to
>> http://www.site.com/clientA/application.pl and are authenticated with
>> Apache2::AuthCookieDBI
>>
>> Now the directories clientA, clientB, etc. do not exist, I'm using
>> mod_rewrite to sort that out, and here starts my problems. First I'm
>> lost with authenticating since there's no "real" resource to
>> authenticate against, but I seem to have solved that by forcing
>> authentication against all *.pl files which luckily do exist ;)
>>
>> It gets more complicated later because some URLs like
>> http://www.site.com/clientA/iCal can't use session cookies but have to
>> use BASIC AUTH, and other *.pl files can't have any authentication
>> applied against them.
>>
>> I thought I could solve this by writing a MyAuthCookieDBI.pm but this
>> also isn't working out. For example MyAuthCookieDBI is an almost-empty
>> child. The parent (Apache2::AuthCookieDBI) has a function
>> _dbi_connect() which manages all the database connecting, but I can't
>> overwrite that function, even if MyAuthCookieDBI is the calling object
>> the function from Apache2::AuthCookieDBI always gets called rather than
>> the overridden function in my object.
>>
>> That's kind of the tip of things, basically I'm realizing that I need
>> professional help with this task before I end up requiring professional
>> help for my nerves!
>>
>> So if anyone can help with this then please contact me offlist with terms.
>
> From reviewing what you have posted I take it the main problem is you have a
> huge number of clients and don't want to write a .htaccess file for each one,
> right?
>
> There are 2 ways to solve this. 1) generate the httpd.conf on startup from the
> client database adding a block for each one. That means you'd have
> to restart apache for each new client.
>
> The second way is to write a simple and short (3-4 lines of code) modperl-
> handler that adds the right configuration directives to the request depending
> on the url. The trick when to do that within the request cycle.
>
> Auth-directives are applied just after the HeaderParser phase. So, the last
> chance to add authentication stuff is the header parser phase. Unfortunately
> this phase is skipped for subrequests. So, if you want to catch subrequests as
> well MapToStorage is the only way. But it also has its tweaks. So, let's
> assume you use the HeaderParser phase for a start.
>
> The PerlHeaderParserHandler would look like:
>
> my %config=
> (
> clientA=>[
> 'AuthType Apache2::AuthCookieDBI',
> 'AuthName WhatEver',
> 'PerlAuthenHandler Apache2::AuthCookieDBI->authenticate',
> 'PerlAuthzHandler Apache2::AuthCookieDBI->authorize',
> 'require valid-user',
> 'PerlSetVar WhatEver... ...',
> ...
> ],
> clientB=>...
> ...
> );
>
> sub ... {
> my ($r)=@_;
>
> return Apache2::Const::DECLINED unless $r->uri=~m!/([^/]+)!;
> $r->add_config($config{$1});
>
> return Apache2::Const::DECLINED;
> }
>
> What now happens is Apache reads in the request then just before deciding if
> authentication is needed the HeaderParser handler jumps in, looks at the URI
> and adds the needed configuration stuff.
>
> Perhaps you have a look at my Apache2::Translation on CPAN. I think it's a
> very handy module for complicated configurations. I wouldn't configure an
> apache without it anymore and I know some other folks who wouldn't either.
>
> Torsten
>

--
McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/

Re: mod_perl waters too deep

On Monday 14 December 2009 18:45:01 Tosh Cooey wrote:
> my %config=
> (
> clientA=>[
>
> ...
>
> The problem is this creates a LARGE config file for 10,000+ clients, and
> I'm still naive enough to dream big :)
>
That %config hash was meant as an example. In the real world you would fetch
it from a database or something similar. Somewhere you have to store the
configuration.

Torsten

modperl / apache13 memory footprints on 32 adn 64 bit servers

Hello,

I'm in process of moving a mod_perl/apache1.3 application from
32bit to 64bit architectures. I am not a sysadmin, but rather the app
programmer.

But I'm surprised by the dramatic leap in httpd process sizes. Here are
"typical" SIZE/RES figures:

32bit: SIZE=45M RES=32M
64bit: SIZE=95M RES=45M

Do these look reasonable? Should I worry?

Thanks to all who answer - your experience and expertise make mod_perl
a vital force.

Joe Niederberger

Re: modperl / apache13 memory footprints on 32 adn 64 bit servers

On 12/20/2009 09:40 AM, Joe Niederberger wrote:

> 32bit: SIZE=45M RES=32M
> 64bit: SIZE=95M RES=45M
>
> Do these look reasonable? Should I worry?

Good question. While I haven't made the jump to 64bit for my web
machines there are lots of memory related things that double in size
when you do so. I wouldn't expect it to be a full 2X jump, so something
else might be amiss. Besides the 32v64bit change is all the other
software the same?

--
Michael Peters
Plus Three, LP

Re: modperl / apache13 memory footprints on 32 adn 64 bit servers

Well, some poking aronud by the sysadmins and they found teh perl
was compiled with

> MYMALLOC PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT USE_FAST_STDIO
> USE_LARGE_FILES USE_PERLIO

So it was using 64 bit variables for INT and maybe some other uneeded
things.
So that might be a big part of it.

Joe N.




> On 12/20/2009 09:40 AM, Joe Niederberger wrote:
>
> > 32bit: SIZE=45M RES=32M
> > 64bit: SIZE=95M RES=45M
> >
> > Do these look reasonable? Should I worry?
>
> Good question. While I haven't made the jump to 64bit for my web
> machines there are lots of memory related things that double in size
> when you do so. I wouldn't expect it to be a full 2X jump, so something
> else might be amiss. Besides the 32v64bit change is all the other
> software the same?
>
> --
> Michael Peters
> Plus Three, LP

Re: modperl / apache13 memory footprints on 32 adn 64 bit servers

Does anyone know if one can have 64bit perl use 64 bit addressing (to make
use of >4GB RAM) but still use 32-bit INTs etc (to keep footprint from
getting
large)?

Thanks,
Joe N.

Re: modperl / apache13 memory footprints on 32 adn 64 bit servers

I should add - if anyone can answer this question - would it be a good idea
to do
so even if possible?

Thanks,
Joe Niederberger



> Does anyone know if one can have 64bit perl use 64 bit addressing (to make
> use of >4GB RAM) but still use 32-bit INTs etc (to keep footprint from
> getting
> large)?
>
> Thanks,
> Joe N.
>

Re: modperl / apache13 memory footprints on 32 adn 64 bit servers

Joe Niederberger wrote:
> Does anyone know if one can have 64bit perl use 64 bit addressing (to make
> use of >4GB RAM) but still use 32-bit INTs etc (to keep footprint from
> getting
> large)?

This is the default on windows x64.

Mod-Perl techincal support - looking for consultant

Hello,

I apologize if this is not the right forum for this - but we need
to find an hourly consultant with mod_perl and apache expertise,
and hopefully some FreeBSD experience as well.

I would be most grateful for any good leads.

Thanks,
Joe Niederberger

Re: Mod-Perl techincal support - looking for consultant

Some details:

Business based in New Jersey (not so relevant)
Hoster: Datapipe
OS: FreeBSD 7.2 release p4
Arch - amd64-freebsd
Perl 5.8.9
Apache/mod-perl 1.3

Basic problem is Datapipe support has little experience with mod_perl.


----- Original Message -----
From: "Joe Niederberger"
To:
Sent: Monday, December 28, 2009 1:13 AM
Subject: Mod-Perl techincal support - looking for consultant


> Hello,
>
> I apologize if this is not the right forum for this - but we need
> to find an hourly consultant with mod_perl and apache expertise,
> and hopefully some FreeBSD experience as well.
>
> I would be most grateful for any good leads.
>
> Thanks,
> Joe Niederberger

Re: Mod-Perl techincal support - looking for consultant

>> I apologize if this is not the right forum for this - but we need
>> to find an hourly consultant with mod_perl and apache expertise,
>> and hopefully some FreeBSD experience as well.

What exactly are you looking for I should be able to help.

--
------------------------------------------------------------ ------------
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354
VP Apache Infrastructure; Member, Apache Software Foundation
Committer, FreeBSD Foundation
Consultant, P6M7G8 Inc.
Sr. System Admin, Ridecharge Inc.

Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.