Re: [MP2] Using Apache::AuthCookie with $r->prev when login is a redirect to https
On Tuesday 05 April 2005 00:59, Barry Hoggard wrote:
> I have Apache::AuthCookie 3.06 working fine with just http under this
> setup:
>
> httpd-2.0.53
> mod_perl-2.0.0-RC4
>
> However, when I redirect to https for the login page, $r->prev is now
> empty, so I don't have these values for my form:
>
> $r->prev->uri
> $r->prev->args
> $r->prev->subprocess_env("AuthCookieReason")
>
>
> What is the best way to do this? I would prefer for the login page
> to be in https, and not just submit to https. I'm using
> Apache::Session as well, but I don't know if there is a way to make
> sure that stuff gets into the session before I redirect to https.
If I understood you properly you are redirecting the browser from a HTTP
request to HTTPS. This involves browser interaction and is not an
internal redirect. prev() however works only with internal redirects,
e.g. $r->internal_redirect, ErrorDocument, CGI script emitting only a
"Location" header, ...
Since HTTP is a stateless protocol there is no other way of maintaining
state then transferring information from the server to the browser and
back. This is what cookies are made for.
Torsten
pgp0C5MpUai1a.pgp
Description: PGP signature
Re: Bug Report : problem with both_str_native_remove test and broken mod_perl.so
On Monday 04 April 2005 19:39, Fred Seibel wrote: > t/filter/both_str_native_remove.# Failed test 1 in > t/filter/both_str_native_remove.t at line 22 > # Failed test 2 in t/filter/both_str_native_remove.t at line 24 > t/filter/both_str_native_remove.FAILED tests 1-2 > Failed 2/8 tests, 75.00% okay > > However once I got > t/filter/both_str_native_remove.ok Maybe some background information on what the particular test does. Tests 1 and 2 check whether the DEFLATE input filter and the INCLUDES output filter are present. The remaining tests check the effect of removing these filters. Maybe there are problems with your mod_deflate, mod_include setup? However, tests 3 and 6 check whether INCLUDES and DEFLATE were present in the filter chain. Maybe you could provide the output of "make test TEST_VERBOSE=1 TEST_FILES=t/filter/both_str_native_remove.t"? Torsten pgpRWqkTvhpkV.pgp Description: PGP signature
Re: [mp1] Apache::AuthDBI segfaults under Fedora Core 1?
On Apr 4, 2005, at 7:56 PM, Stas Bekman wrote: John Callender wrote: In moving some web sites from a server running Red Hat Linux release 7.3 (Valhalla) to one running Fedora Core release 1 (Yarrow), I'm finding that attempts to authenticate under mod_perl using Apache::AuthDBI, which were working normally on the RH 7.3 server, are producing segfaults on the FC1 server. I'd suggest to cleanup your perl's lib tree first, nuking all paths with 5.8.2, 5.8.1 and 5.8.0 in it. May be you get some binary incompatible module loaded which causes the crush. That appears to have solved my problem. I needed to install DBI and DBD::mysql from source after removing the 5.8.0, 5.8.1, and 5.8.2 paths from the perl lib tree, because the FC1 distribution apparently came with those installed under 5.8.0. But having done that, Apache::AuthDBI is authenticating properly, with no segfaults. Thank you very much for your help. Your perl is thread-enabled, do you by chance spawn perl threads anywhere? Did you try building perl with -Uusethreads? As far as I'm aware, we're not using threads anywhere on the server. I haven't tried building perl with -Uusethreads, no. Thanks again. John Callender [EMAIL PROTECTED]
AW: APR::BucketType bucket types?
> -Ursprüngliche Nachricht- > Von: Stas Bekman [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 4. April 2005 18:47 > An: Dintelmann, Peter > Cc: 'modperl@perl.apache.org' > Betreff: Re: APR::BucketType bucket types? > > > Dintelmann, Peter wrote: > > I am looking for a list of the bucket types for APR::BucketType > > objects and their meanings. So far I have encountered the types > > "FLUSH", "EOC" (end of connection?) and "mod_perl SV bucket". > > > > It seems that bucket type (names) are only available as strings. > > When looking for buckets of a particular type a comparison > > to an integer constant would be more efficient. Can we have > > some constants in APR::Const for this purpose and the bucket > > type name as a dual valued scalar? > > Peter, libapr identifies buckets only by their name. How do > you suggest > that we manage their numerical values? A new bucket type can > be added any > moment and we won't have an ID for it. APR::Const only > provides a glue for > the existing libapr's C-level constants. If you want a change of this > kind, you will have to ensure that libapr provides that ID > first and mp2 > will follow. ok; I didn't think about that... So what is the most efficient way to determine the "standard" bucket types like EOS/EOC/FLUSH? How is is_eos() doing it?
setting request_time (prot. handler)
The log phase can be invoked in a protocol handler using the
run_log_transaction() method from Apache::HookRun.
use Apache::Connection;
use Apache::Const -compile => qw(OK);
use Apache::RequestRec;
use Apache::RequestUtil;
use Apache::HookRun;
sub handler
{ my $c = shift;
my $r = Apache::RequestRec->new($c);
# IO loop goes here
# finally log the request
$r->run_log_transaction();
return Apache::OK;
}
Unfortunately the request_time of the newly created request
seems to be undefined.
Is there a way to manually set the request_time (or get it
automagically set to the time of the creation of $r)?
Re: [mp1] Apache::AuthDBI segfaults under Fedora Core 1?
John Callender wrote: On Apr 4, 2005, at 7:56 PM, Stas Bekman wrote: John Callender wrote: In moving some web sites from a server running Red Hat Linux release 7.3 (Valhalla) to one running Fedora Core release 1 (Yarrow), I'm finding that attempts to authenticate under mod_perl using Apache::AuthDBI, which were working normally on the RH 7.3 server, are producing segfaults on the FC1 server. I'd suggest to cleanup your perl's lib tree first, nuking all paths with 5.8.2, 5.8.1 and 5.8.0 in it. May be you get some binary incompatible module loaded which causes the crush. That appears to have solved my problem. I needed to install DBI and DBD::mysql from source after removing the 5.8.0, 5.8.1, and 5.8.2 paths from the perl lib tree, because the FC1 distribution apparently came with those installed under 5.8.0. But having done that, Apache::AuthDBI is authenticating properly, with no segfaults. Excellent :) Thank you very much for your help. Your perl is thread-enabled, do you by chance spawn perl threads anywhere? Did you try building perl with -Uusethreads? As far as I'm aware, we're not using threads anywhere on the server. I haven't tried building perl with -Uusethreads, no. If you don't use threads and you build your own perl, you should build it with threads disabled. You will get a faster and smaller perl. -- __ 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: [MP2] Using Apache::AuthCookie with $r->prev when login is a redirect to https
On Apr 5, 2005, at 3:00 AM, Torsten Foertsch wrote: On Tuesday 05 April 2005 00:59, Barry Hoggard wrote: If I understood you properly you are redirecting the browser from a HTTP request to HTTPS. This involves browser interaction and is not an internal redirect. prev() however works only with internal redirects, e.g. $r->internal_redirect, ErrorDocument, CGI script emitting only a "Location" header, ... Since HTTP is a stateless protocol there is no other way of maintaining state then transferring information from the server to the browser and back. This is what cookies are made for. Yes, that is correct. I was assuming I should put something into my session, but I wasn't sure where in the handling phase to do it. I am using Apache::SessionManager. What is the best place in the request lifecycle to do that session update? I haven't really used anything other than Access/Authen/Authz and Response handlers. Would this be a PerlFixupHandler or a PerlTransHandler, or is something else preferred? Barry Hoggard
Re: AW: APR::BucketType bucket types?
Dintelmann, Peter wrote:
-Ursprüngliche Nachricht-
Von: Stas Bekman [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 4. April 2005 18:47
An: Dintelmann, Peter
Cc: 'modperl@perl.apache.org'
Betreff: Re: APR::BucketType bucket types?
Dintelmann, Peter wrote:
I am looking for a list of the bucket types for APR::BucketType
objects and their meanings. So far I have encountered the types
"FLUSH", "EOC" (end of connection?) and "mod_perl SV bucket".
It seems that bucket type (names) are only available as strings.
When looking for buckets of a particular type a comparison
to an integer constant would be more efficient. Can we have
some constants in APR::Const for this purpose and the bucket
type name as a dual valued scalar?
Peter, libapr identifies buckets only by their name. How do
you suggest
that we manage their numerical values? A new bucket type can
be added any
moment and we won't have an ID for it. APR::Const only
provides a glue for
the existing libapr's C-level constants. If you want a change of this
kind, you will have to ensure that libapr provides that ID
first and mp2
will follow.
ok; I didn't think about that...
So what is the most efficient way to determine the
"standard" bucket types like EOS/EOC/FLUSH?
with is_foo methods:
http://perl.apache.org/docs/2.0/api/APR/Bucket.html
though at the moment we expose just two of them. Which ones do you lack?
How is is_eos() doing it?
APU_DECLARE_DATA const apr_bucket_type_t apr_bucket_type_eos = {
"EOS", 5, APR_BUCKET_METADATA,
apr_bucket_destroy_noop,
eos_bucket_read,
apr_bucket_setaside_noop,
apr_bucket_split_notimpl,
apr_bucket_simple_copy
};
#define APR_BUCKET_IS_EOS(e) ((e)->type == &apr_bucket_type_eos)
As you can see apr_bucket_type_eos is a struct, not a numerical value. I
guess since it checks the address, it's possible to present it as a constant.
--
__
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: setting request_time (prot. handler)
Dintelmann, Peter wrote:
The log phase can be invoked in a protocol handler using the
run_log_transaction() method from Apache::HookRun.
use Apache::Connection;
use Apache::Const -compile => qw(OK);
use Apache::RequestRec;
use Apache::RequestUtil;
use Apache::HookRun;
sub handler
{ my $c = shift;
my $r = Apache::RequestRec->new($c);
# IO loop goes here
# finally log the request
$r->run_log_transaction();
return Apache::OK;
}
Unfortunately the request_time of the newly created request
seems to be undefined.
Is there a way to manually set the request_time (or get it
automagically set to the time of the creation of $r)?
This should do the trick:
Index: xs/Apache/RequestUtil/Apache__RequestUtil.h
===
--- xs/Apache/RequestUtil/Apache__RequestUtil.h (revision 159348)
+++ xs/Apache/RequestUtil/Apache__RequestUtil.h (working copy)
@@ -79,6 +79,8 @@
r->connection = c;
r->server = s;
+r->request_time = apr_time_now();
+
r->user= NULL;
r->ap_auth_type= NULL;
we could also make $r->request_time settable.
--
__
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: red hat mod_perl build problem
Thanks, Tom, for the worldly advice. But, here is my situation. I am a single individual supporting 8+ Oracle research databases at Vanderbilt University Medical center using a modperl authorization system that I developed under modperl 1 and other perl scripts that run under the Registry module which I have been waiting to upgrade to version 2 for 2 years. I am supporting Apache in this configuration on Windows 2000 and XP and Red Hat Linux. I am also the the DBA for our 2 Oracle 9.2 database systems that run on matching Sun 450's. And did I mention that I am also the system manager for all of the systems that I have just mentioned as well? The perl/modperl code that I developed for rapidly developing web-based research databases (using metadata) is also in use at the Universities of North Carolina and Pennsylvania. When I put out the message about not being able to build on the linux box, I didn't get any response for a couple of days, so I figured I was on my own; so I back peddled to the most obvious, workable solution. This is by no means a jab at the modperl support team. They do a great job considering the breadth of system types that modperl has been ported to. It's just that I did not have the luxury of waiting for support that might never have come. I realize that the support people are perhaps even busier than I am! Now that I have an idea of how to proceed, i.e. remove the old version of perl from my brand new linux box - completely - and install perl 5.8.6 then build apache 2 and modperl 2, maybe I will do it. But more likely I have lost my 'window of opportunity' because of the backlog of database change requests and new features that my clients are screaming for. Again, I am not criticizing anyone here. It was my decision to go with modperl in a production environment and I am prepared to live with the consequences. I sincerely appreciate your advice and counsel. Thanks, Tom Caldwell --On Tuesday, April 05, 2005 8:52 AM +0200 Tom Schindl <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I won't do that because when develping code on such an old code base like 1.99.09 many things have been corrected/changed beside security holes closed in apache 2, ... . And mod_perl is changing the next release will probably shift everything from Apache into the Apache2-Namespace, so don't be suprised when working on not yet released code (and there has never been a final release of mp2) it won't work in later releases. You should at least work on the latest available codebase or even better the svn/cvs-trunk of it. Things have been fixed, the docs match the real code you use, ... . Tom Tom Caldwell schrieb: | Thanks for the reply, but I did some more digging and decided | that having 2 versions of perl installed (improperly) on my | system was probably the culprit. And since red hat provides a | version of apache2 and modperl 2 with perl 5.8.0, I decided to | just go with that, even though it is 1.5 years old (1.99.09)! | | Now if I could only get the Oracle client to install I will be | back to developing more code! | | Thanks, | | Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCUjXEkVPeOFLgZFIRAk4MAKC6JJGTL7n7C6ls++xuUBJ7fDNIngCgjrza OrdgzBPm3oI8dzv/gOW9sEI= =nItK -END PGP SIGNATURE- Tom Caldwell Vanderbilt University Medical Center
use Apache2
Hi I updated my mod_perl 2.0 to the latest svn version. I had screwed with my perl intallation a bit beforehand as well... I reinstalled mod_perl 2.0 doing: perl Makefile.PL MP_APXS=/... make && make test && make install Somehow I no longer have Apache2.pm around in /usr/lib/perl5/site_perl/5.8.6/i686-linux Why didn't Apache2.pm get installed? I noticed that MP_INST_APACHE2=1 is no longer a valid Makefile.PL option. Leo
Re: use Apache2
Hi, as you should have noticed all modules live now in the Apache2::-Namespace so there is no need any more for the Apache2.pm. The trunks have been merged on monday. Tom Leo wrote: Hi I updated my mod_perl 2.0 to the latest svn version. I had screwed with my perl intallation a bit beforehand as well... I reinstalled mod_perl 2.0 doing: perl Makefile.PL MP_APXS=/... make && make test && make install Somehow I no longer have Apache2.pm around in /usr/lib/perl5/site_perl/5.8.6/i686-linux Why didn't Apache2.pm get installed? I noticed that MP_INST_APACHE2=1 is no longer a valid Makefile.PL option. Leo
Configuration for redundancy?
Greetings, We have developed a web application using mod_perl and MySQL. We chose the light Apache + mod_perl Apache + MySQL method. What we would like to be able to do is come up with a fully redundant setup of machines so that we can sell this package to company's, install it in their datacenter and thats it. We are not very hardware minded, so we are looking for suggestions on what kind of setup we should deploy. We want to keep redundancy and scalability as top priority. One of our basic ideas was to have a setup of 6 machines and a raid array. 3 machines would act as the primary machines, the remaining 3 would be backup machines. That would leave us with a primary and backup light Apache, same with mod_perl same with MySQL. We would like to separate these three entity's so that as the install gets larger and larger, all we need to do is add machines for that specific purpose and not have to re-arrange anything. The machines would each have a small harddrive connected to them, which will contain the operating system. We would then have a raid setup which the individual machines would mount (via NFS?) the raid setup would contain the database files, the core code that powers the application, and any web files to be served. Like I said, we are not big into hardware, and this may be overkill or totally wrong. Any suggestions are highly appreciated!!
RE: Configuration for redundancy?
The MySQL folks say they do clustering. There are whitepapers at this link. http://www.mysql.com/products/cluster/ MySQL Cluster MySQL Cluster combines the world's most popular open source database with a fault tolerant database clustering architecture so you can deliver mission-critical database applications with 99.999% availability. It is a high-performance main memory database that uses synchronous replication to achieve sub-second failover and ensure data is continuously available. MySQL Cluster is a cost-effective solution that runs on commodity hardware and open source software, and its "shared-nothing" architecture does not require any additional shared disk storage investment. -Original Message- From: Chris [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 05, 2005 3:25 PM To: modperl@perl.apache.org Subject: Configuration for redundancy? Greetings, We have developed a web application using mod_perl and MySQL. We chose the light Apache + mod_perl Apache + MySQL method. What we would like to be able to do is come up with a fully redundant setup of machines so that we can sell this package to company's, install it in their datacenter and thats it. We are not very hardware minded, so we are looking for suggestions on what kind of setup we should deploy. We want to keep redundancy and scalability as top priority. One of our basic ideas was to have a setup of 6 machines and a raid array. 3 machines would act as the primary machines, the remaining 3 would be backup machines. That would leave us with a primary and backup light Apache, same with mod_perl same with MySQL. We would like to separate these three entity's so that as the install gets larger and larger, all we need to do is add machines for that specific purpose and not have to re-arrange anything. The machines would each have a small harddrive connected to them, which will contain the operating system. We would then have a raid setup which the individual machines would mount (via NFS?) the raid setup would contain the database files, the core code that powers the application, and any web files to be served. Like I said, we are not big into hardware, and this may be overkill or totally wrong. Any suggestions are highly appreciated!!
RE: Configuration for redundancy?
On Tue, 2005-04-05 at 15:58 -0700, Goehring, Chuck, RCI - San Diego wrote: > > The MySQL folks say they do clustering. It's a bit different from just clustering an existing MySQL database. It involves using an entirely separate table type which is designed just for clustering. Suitable for some applications, but most of what people think of as database clustering would be easier to do using replication (which MySQL supports) and some kind of external failover. Zawodny's MySQL book covers the subject well. - Perrin
Re: Configuration for redundancy?
I'll second Zawodny's book. It's a quick read. http://www.bookpool.com/sm/0596003064 OT, A decent backup scheme mentioned in it is to run a slave on a separate machine, and then do all your backups off that (as you wont have to shut the main machine down, and it will resync up when brought back online) He explains it much better than me. On Apr 5, 2005, at 7:13 PM, Perrin Harkins wrote: It's a bit different from just clustering an existing MySQL database. It involves using an entirely separate table type which is designed just for clustering. Suitable for some applications, but most of what people think of as database clustering would be easier to do using replication (which MySQL supports) and some kind of external failover. Zawodny's MySQL book covers the subject well. - Perrin
Re: How do I catch errors with Apache::Upload
I can't seem to get that working, best as I try.
Does anyone have other suggestions?
My main problem right now, is that if I upload 'nothing', i get an
error of the sort:
can't find Content-Type header
According to the mp1 docs/examples:
$upload = $apr->upload('fieldname')
if (!$upload)
{
# no upload
}
else
{
# yay upload
}
I'm probably interpreting this wrong, but according to the MP2 docs :
$upload = $apr->upload('fieldname')
if ( (ref $upload) eq 'Apache::Upload::Error' )
{
# no upload
}
else
{
# yay upload
}
Which might work... but in the case that you have a file upload, and
click the file button -- but don't select a file, $upload seems to
stay a valid upload object -- but performing any Apache::Upload method
on it causes a 500 error
Anyone else with a suggestion? This is killing me.
On Apr 2, 2005, at 10:37 PM, Fred Moyer wrote:
I was doing something similar several months ago where I needed to
validate the incoming data. This may not be what you need but it
worked
in my case, and it's likely there is a simpler way to do it. Here's a
link to a question I posted on the apreq-dev list regarding this - hope
it helps.
http://marc.theaimsgroup.com/?l=apreq-dev&m=109150075712271&w=2
Apache::PerlRun flooding error log
Heya All,
I have an issue at the moment where if there is an error/warning in my
PerlRun script/module then the error/warning is printed as well as the
entire contents of the script being eval'ed. This only occurs when a
string is evaled and Carp stack trace is on. And this can be replicated
easily using a simple test script - like the one below:
--code--
#!/usr/bin/perl
use strict;
use warnings;
use Carp qw(confess cluck);
$SIG{__DIE__} = \&Carp::confess;
$SIG{__WARN__} = \&Carp::cluck;
my $eval = '
package test;
my $a = "b";
warn "Blah!\n";
my $b = "a";
';
eval $eval;
if (my $err = $@) {
print "Eval Failed: \'". $err. "\'\n";
exit;
}
--code--
produces:
--output--
[EMAIL PROTECTED] workspace]$ perl test_eval_dump3.pl
Blah!
eval '
package test;
my $a = "b";
warn "Blah!\\n";
my $b = "a";
;' called at test_eval_dump3.pl line 17
--output--
Now of course when your 'script' is some 60K - and you have a huge
number of hits load balanced across 4 servers - well, we are getting
roughly 10Mb of error log every hour on each server.
Now it seems obvious to either disable stack trace, or overload $SIG
{__WARN__} / $SIG{__DIE__} in something like a PerlTransHandler or
something run before the script - however, once the script runs it will
overload $SIG{__WARN__} e.t.c. with its own. There are far to many
scripts/modules for me to alter so I am wondering if anyone knows of
another sane solution to deal with this?
I mean I would love to be able to do:
ErrorLog My::ErrorLogCleanup /var/log/apache/error_log
and have My::ErrorLogCleanup clean the error message and strip the eval
out with a simple regexp. But i'm not sure how this can be achieved.
Thanks in advance,
David J Radunz
Developer,
Netspace Online Systems
This email and any files transmitted with it are confidential and intended
solely for the
use of the individual or entity to whom they are addressed. Please notify the
sender
immediately by email if you have received this email by mistake and delete this
email
from your system. Please note that any views or opinions presented in this
email are solely
those of the author and do not necessarily represent those of the
organisation.
Finally, the recipient should check this email and any attachments for the
presence of
viruses. The organisation accepts no liability for any damage caused by any
virus
transmitted by this email.
Re: Apache::PerlRun flooding error log
David J Radunz wrote:
Heya All,
I have an issue at the moment where if there is an error/warning in my
PerlRun script/module then the error/warning is printed as well as the
entire contents of the script being eval'ed. This only occurs when a
string is evaled and Carp stack trace is on.
David, why not fix errors and warnings and have nothing logged at all?
Why do you set:
$SIG{__DIE__} = \&Carp::confess;
$SIG{__WARN__} = \&Carp::cluck;
Those are used for development, not production env.
As you've figured it's how perl works, mod_perl doesn't do anything
special about it.
--
__
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: Apache::PerlRun flooding error log
Sounds great - yet obvious. I would have to do about 2 years worth of
work to fix all of the bugs. I didn't create them either, I fix them in
my own code - but we have so much code base. I wanted a mod_perl
solution to overcome this issue by filtering the error.
DJ
On Tue, 2005-04-05 at 22:06 -0400, Stas Bekman wrote:
> David J Radunz wrote:
> > Heya All,
> >
> > I have an issue at the moment where if there is an error/warning in my
> > PerlRun script/module then the error/warning is printed as well as the
> > entire contents of the script being eval'ed. This only occurs when a
> > string is evaled and Carp stack trace is on.
>
> David, why not fix errors and warnings and have nothing logged at all?
>
> Why do you set:
>
> $SIG{__DIE__} = \&Carp::confess;
> $SIG{__WARN__} = \&Carp::cluck;
>
> Those are used for development, not production env.
>
> As you've figured it's how perl works, mod_perl doesn't do anything
> special about it.
>
This email and any files transmitted with it are confidential and intended
solely for the
use of the individual or entity to whom they are addressed. Please notify the
sender
immediately by email if you have received this email by mistake and delete this
email
from your system. Please note that any views or opinions presented in this
email are solely
those of the author and do not necessarily represent those of the
organisation.
Finally, the recipient should check this email and any attachments for the
presence of
viruses. The organisation accepts no liability for any damage caused by any
virus
transmitted by this email.
Re: Configuration for redundancy?
I put the servers behind an LVS load balancer. LVS is an L4 load balancer, so all servers behind it must have identical functions and content. I use keepalive to monitor the servers and automatically takes it out of the load balancer if it goes down. When I add a new machine, just replicate it and put it in the load balancing farm. There is no idle machine in this setup. It is totally redundant and highly available. For the database server, you can have one master and slave MySQL server. You can use the load balancer to balance them too. Keepalive has a concept of emergency server so you can configure your slave MySQL server to be it. What you described is kind of similar to a project that I was going to do - with a blade server. The main data storage is on a NAS. The master blade acts as the load balancer/router/ NFS server. It boots from a flash disk with a small embedded Linux. All other blades can boot from flash or PXE which downloads the OS from the NFS server, loads and runs a small OS in memory. The application is NFS mounted read only. Logging can be done via network log so the server can take a power outage well. For redundancy of the master blade, you can dedicate another blade to monitor the master blade and takes over if the master goes down. Chris wrote: Greetings, We have developed a web application using mod_perl and MySQL. We chose the light Apache + mod_perl Apache + MySQL method. What we would like to be able to do is come up with a fully redundant setup of machines so that we can sell this package to company's, install it in their datacenter and thats it. We are not very hardware minded, so we are looking for suggestions on what kind of setup we should deploy. We want to keep redundancy and scalability as top priority. One of our basic ideas was to have a setup of 6 machines and a raid array. 3 machines would act as the primary machines, the remaining 3 would be backup machines. That would leave us with a primary and backup light Apache, same with mod_perl same with MySQL. We would like to separate these three entity's so that as the install gets larger and larger, all we need to do is add machines for that specific purpose and not have to re-arrange anything. The machines would each have a small harddrive connected to them, which will contain the operating system. We would then have a raid setup which the individual machines would mount (via NFS?) the raid setup would contain the database files, the core code that powers the application, and any web files to be served. Like I said, we are not big into hardware, and this may be overkill or totally wrong. Any suggestions are highly appreciated!!
Re: Apache::PerlRun flooding error log
David J Radunz wrote:
Sounds great - yet obvious. I would have to do about 2 years worth of
work to fix all of the bugs. I didn't create them either, I fix them in
my own code - but we have so much code base. I wanted a mod_perl
solution to overcome this issue by filtering the error.
If that's the case, why don't you adjust your %SIG wrappers to truncate
the error length? It's relatively easy:
use Carp qw(confess cluck);
$SIG{__DIE__} = sub { die substr Carp::longmess(@_), 0, TRUNCATE };
$SIG{__WARN__} = sub { warn substr Carp::longmess(@_), 0, TRUNCATE };
You don't need to touch mod_perl.
On Tue, 2005-04-05 at 22:06 -0400, Stas Bekman wrote:
David J Radunz wrote:
Heya All,
I have an issue at the moment where if there is an error/warning in my
PerlRun script/module then the error/warning is printed as well as the
entire contents of the script being eval'ed. This only occurs when a
string is evaled and Carp stack trace is on.
David, why not fix errors and warnings and have nothing logged at all?
Why do you set:
$SIG{__DIE__} = \&Carp::confess;
$SIG{__WARN__} = \&Carp::cluck;
Those are used for development, not production env.
As you've figured it's how perl works, mod_perl doesn't do anything
special about it.
--
__
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: Apache::PerlRun flooding error log
Stas Bekman wrote:
David J Radunz wrote:
Sounds great - yet obvious. I would have to do about 2 years worth of
work to fix all of the bugs. I didn't create them either, I fix them in
my own code - but we have so much code base. I wanted a mod_perl
solution to overcome this issue by filtering the error.
If that's the case, why don't you adjust your %SIG wrappers to truncate
the error length? It's relatively easy:
use Carp qw(confess cluck);
$SIG{__DIE__} = sub { die substr Carp::longmess(@_), 0, TRUNCATE };
$SIG{__WARN__} = sub { warn substr Carp::longmess(@_), 0, TRUNCATE };
Sorry, it should have been:
use constant TRUNCATE => 40;
use Carp ();
$SIG{__DIE__} = sub { die substr Carp::longmess(@_), 0, TRUNCATE };
$SIG{__WARN__} = sub { warn substr Carp::longmess(@_), 0, TRUNCATE };
--
__
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: Apache::PerlRun flooding error log
Well, all of these scripts run under PerlRun - so I either have to make
that change in every one of them, and every module they load. Like, if I
set the SIG{__WARN__} at the top of a script and a module set it,
wouldn't it then be 'reset' ?
David
On Wed, 2005-04-06 at 01:00 -0400, Stas Bekman wrote:
> Stas Bekman wrote:
> > David J Radunz wrote:
> >
> >> Sounds great - yet obvious. I would have to do about 2 years worth of
> >> work to fix all of the bugs. I didn't create them either, I fix them in
> >> my own code - but we have so much code base. I wanted a mod_perl
> >> solution to overcome this issue by filtering the error.
> >
> >
> > If that's the case, why don't you adjust your %SIG wrappers to truncate
> > the error length? It's relatively easy:
> >
> > use Carp qw(confess cluck);
> > $SIG{__DIE__} = sub { die substr Carp::longmess(@_), 0, TRUNCATE };
> > $SIG{__WARN__} = sub { warn substr Carp::longmess(@_), 0, TRUNCATE };
>
> Sorry, it should have been:
>
> use constant TRUNCATE => 40;
> use Carp ();
> $SIG{__DIE__} = sub { die substr Carp::longmess(@_), 0, TRUNCATE };
> $SIG{__WARN__} = sub { warn substr Carp::longmess(@_), 0, TRUNCATE };
>
This email and any files transmitted with it are confidential and intended
solely for the
use of the individual or entity to whom they are addressed. Please notify the
sender
immediately by email if you have received this email by mistake and delete this
email
from your system. Please note that any views or opinions presented in this
email are solely
those of the author and do not necessarily represent those of the
organisation.
Finally, the recipient should check this email and any attachments for the
presence of
viruses. The organisation accepts no liability for any damage caused by any
virus
transmitted by this email.
Re: Apache::PerlRun flooding error log
David J Radunz wrote:
Well, all of these scripts run under PerlRun - so I either have to make
that change in every one of them, and every module they load. Like, if I
set the SIG{__WARN__} at the top of a script and a module set it,
wouldn't it then be 'reset' ?
Why would any module mungle with %SIG? That's a very bad idea. It should
be set once at the startup by the user, normally for debug purposes and
never touched by the core modules.
If you still have the case where the modules you use reset %SIG, simply
modify PerlRun.pm to log the truncated error. Let me know if you need help
with that. (search for $@ and truncate it)
David
On Wed, 2005-04-06 at 01:00 -0400, Stas Bekman wrote:
Stas Bekman wrote:
David J Radunz wrote:
Sounds great - yet obvious. I would have to do about 2 years worth of
work to fix all of the bugs. I didn't create them either, I fix them in
my own code - but we have so much code base. I wanted a mod_perl
solution to overcome this issue by filtering the error.
If that's the case, why don't you adjust your %SIG wrappers to truncate
the error length? It's relatively easy:
use Carp qw(confess cluck);
$SIG{__DIE__} = sub { die substr Carp::longmess(@_), 0, TRUNCATE };
$SIG{__WARN__} = sub { warn substr Carp::longmess(@_), 0, TRUNCATE };
Sorry, it should have been:
use constant TRUNCATE => 40;
use Carp ();
$SIG{__DIE__} = sub { die substr Carp::longmess(@_), 0, TRUNCATE };
$SIG{__WARN__} = sub { warn substr Carp::longmess(@_), 0, TRUNCATE };
This email and any files transmitted with it are confidential and intended solely for the
use of the individual or entity to whom they are addressed. Please notify the sender
immediately by email if you have received this email by mistake and delete this email
from your system. Please note that any views or opinions presented in this email are solely
those of the author and do not necessarily represent those of the organisation.
Finally, the recipient should check this email and any attachments for the presence of
viruses. The organisation accepts no liability for any damage caused by any virus
transmitted by this email.
--
__
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
