[mp1] strange build problem with request_rec structure breaks API
Hi, I have a most interesting problem. It seems as though mod_perl breaks API compatibility for apache by modifying the layout of the request_rec structure. Let me explain I maintain my own Red-Hat-based distribution of linux for my own internal use -- I take packages from Red Hat and modify them to my specifications. RPM makes deployment to multiple servers so much easier. I've modified the Red Hat apache RPM to build two copies of apache: one with mod_perl statically linked (apache-mod_perl) and the other without mod_perl (apache-vanilla). Both builds have EAPI from mod_ssl patched in. (However mod_ssl is built separately; see below.) These two apache builds start with the same source tree. I copy this source tree and then run configure and make separately in both trees. The only build difference between apache-vanilla and apache-mod_perl is two arguments on the configure script: "--activate-module=src/modules/perl/libperl.a" \ "--libexecdir=/usr/lib/apache/modperl" \ And, of course, before I run configure, I let mod_perl hack away at the apache tree as follows: CFLAGS="$RPM_OPT_FLAGS" \ perl Makefile.PL \ PREFIX=$RPM_BUILD_ROOT/usr INSTALLDIRS=vendor \ APACHE_SRC=`pwd`/../src \ DO_HTTPD=1 \ USE_APACI=1 \ PREP_HTTPD=1 \ EVERYTHING=1 Everything else is *exactly* the same. After I have built apache-vanilla and apache-mod_perl, I rebuild the Red Hat mod_ssl RPM. Mod_ssl builds using apxs installed by the apache-vanilla RPM -- this apxs came from the build of apache-vanilla and NOT apache-mod_perl. The apxs from the apache-mod_perl build is never installed or used anywhere. Now here is the important part... I then use this one mod_ssl module (built with apxs from apache-vanilla) with BOTH apache-vanilla AND apache-mod_perl installations: even though it technically isn't fully matched with apache-mod_perl (because it was built using the apxs from apache-vanilla). This has worked great in the past. The abstraction caused by the API has made everything work perfectly. This worked great with: mod_perl-1.26 apache-1.3.22 (from RH 7.2 distribution) mod_ssl-2.8.5 (from RH 7.2 distribution) perl-5.6.0 (from RH 7.2 distribution) Now, I've upgraded to: mod_perl-1.27 apache-1.3.27 (from RH 7.3 distribution; rebuilt in 7.2) mod_ssl-2.8.12 (from RH 7.3 distribution; rebuilt in 7.2) perl-5.8.0 (from RH 8.0 distribution; rebuilt in 7.2) And this breaks! When I use apache-mod_perl and mod_ssl together I get a SEGFAULT. Apache-mod_perl runs fine without mod_ssl. And mod_ssl works fine with apache-vanilla. (The upgrade of apache and mod_ssl did not cause this problem. I first had problems with the older apache and mod_ssl and the newer perl and mod_perl versions. I upgraded to the latest apache and mod_ssl to try and fix things before sending this problem report.) I've used GDB and tracked down why this happens. The problem is that apache-mod_perl and mod_ssl have different ideas of the offset of r->ctx inside the request_rec structure. (r is, of course, a pointer to a request_rec structure). In GDB I've proved this to myself by evaluating "((void*)&(r->ctx)) - ((void*)r)": evaluates to 348 in apache-vanilla evaluates to 356 in apache-mod_perl evaluates to 348 in mod_ssl I've tracked the difference down as to where it is in the structure: all elements before and including "finfo" (type: struct stat) are in sync, and all elements after and including "parsed_uri" (type: uri_components) are 8 bytes off (extra 8 bytes in apache-mod_perl). Either "finfo" is eight bytes longer in apache-mod_perl, or apache-mod_perl has slipped some other element between "finfo" and "parsed_uri". Somehow apache-mod_perl and apache-vanilla have a different ideas of the request_rec structure. Because I compile mod_ssl using apxs from apache-vanilla it works with apace-vanilla but not apache-mod_perl. I suppose you could say that I *should* build mod_ssl using the apxs from apache-mod_perl if I'm going to use it with apache-mod_perl. I thought that mod_perl didn't patch the internals of apache to the point of changing the API. If this is expected behavior and mod_perl totally breaks the API by redefining the structures, I would suggest that the MODULE_MAGIC_NUMBER be updated by mod_perl, so that incompatible modules are not linked together. If this is not normal, please help me fix this. I'd love to not have to maintain two builds of every other module I want to use. Any other information I can provide, please let me know! Thanks! David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/
[JOB-SEEKER] mod_perl consultant; can travel to you
Hello, I'm looking for consulting software development work in the Perl/mod_perl/DBI/Oracle/MySQL/Linux/Web area. Anything Open Source is a plus! I'm based in Maryland Baltimore/D.C. area. I'm flexible and willing to travel to your location for a period of time, if needed. More info about me here: http://www.davideous.com/statement_of_capabilities.txt Thanks! David
RE: [OT] Question about Work Wanted ads
[EMAIL PROTECTED] wrote: > However, this is perfectly legal if you *billed* for your work, were *paid*, > and then "voluntarily" cut a check to the charity making an actual cash > *donation*. As long as they are bona-fide separate, independent transactions, > you can claim the deduction. You can arrange to only "donate" a portion of your > time/money this way. Even if you do what you describe, you get no tax benefit. To your taxable income you have to (a) ADD the income/revenue that you gained, and (b) SUBTRACT the deduction that you gained. They cancel out. Net effect is zero. David
[OT] RE: Question about Work Wanted ads
Marc Spitzer [mailto:[EMAIL PROTECTED]] wrote: > 3: you maybe able to deduct your volunteer work from your > taxes( I have no idea about AU's laws though). You can not claim donated services as a tax deduction in the US. (Probably not other places too, I'd guess.) The theory is this: you'd have to book both a revenue for the work you did and a deduction for the donation. These would cancel out. David
RE: [OT-ish] Session refresh philosophy
Drew Taylor [mailto:[EMAIL PROTECTED]] wrote: > I just looked at CGI::EncryptForm and David's module. The thing I like > right off the bat about C:EF is that you pass a href to encrypt() and get > back a href from decypt(). Perhaps I missed something, but FormContainer > takes a string, not a data structure. I prefer the simplicity of just > worrying about a structure, and not having to worry about converting it to > a string. My module, FormContainer, takes arbitrary data structures like hash references too. You probably didn't see this because I used my own serializer module called FreezeThawLite instead of Storable. The lack of documentation of my module may have also been a problem. :-) I mentioned that a trivial rewrite to use Storable would be required when I attached the code. Simply replace FreezeThawLight::freeze with Storable::freeze and FreezeThawLight::thaw with Storable::thaw. :-) I agree with you that having to manually serialize session data to a string would be a real pain! > That said, I like the approach that the two modules use. One just goes an > extra step to guarantee data security. While looking for full-time > employment, I've been doing some freelance work, which basically is small > CGI apps. C:EF looks like it would make my life much easier by ensuring > consistent state w/ small effort on my part, and take care of any security > precautions as well. Combine that w/ CGI::Application (after I add TT2 > support :-) ), and my life as a freelance CGI guy just got a whole lot easier. See my last message about the security comparisons. > Thank you to everyone who contributed to this thread. I've gotten all kinds > of neat ideas I'll use in future projects! Good stuff. David
RE: [OT-ish] Session refresh philosophy
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] wrote: > I can see how your approach adds functionality by performing as expected if > the user uses the Back button or opens the app. in more than one browser > window. The usual objection I've heard to using form fields is the security > risk of people changing hidden fields in ways unforseen before submitting > the form back, or of other people finding confidential data hidden in form > fields if the user walks away and leaves their browser open, or the web > page info gets hijacked somehow. Does your module address this, or is this > yet another tradeoff between security and functionality/convenience? My module addresses the first concern of an attacker changing the data in the hidden fields. On encoding, I hash together the encoded data and a secret to get a security hash. On decoding, I perform the same hashing and make sure it matches. Without the secret data no one can generate a security hash for modified data. My module does not address encryption. It would be trivial to add. It wasn't a concern with my application. By note of comparison, it looks like CGI::EncryptForm addresses both the encryption and non-user-modifiable concerns for the hidden data. David
RE: [OT-ish] Session refresh philosophy
Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote: > Okay, I only looked at it briefly and thought it stored the data on the > client. Your module is actually more like CGI::EncryptForm I think, but > yours may make things a bit more transparent. Maybe you should polish it up > for CPAN. I looked at CGI::EncryptForm. It is used to store data on the client. The main difference between it and my module is that: (a) it encrypts the data, while I only prevent users from modifying the data, and (b) it stores the data in one field, while I store in multiple fields to make double sure that I don't hit any length restrictions. > I'm well aware of the page-state vs. browser-state problem. I was recently > bitten by it again when some consultants built a web app for my company that > puts the search results in a session keyed on a cookie. As soon as the user > opens two windows, it's absolute mayhem. I wasn't exactly what to call it and if people would recognize it by name, so I started writing a short description which just grew. :-) David
RE: [OT-ish] Session refresh philosophy
Hans Juergen von Lengerke [mailto:[EMAIL PROTECTED]] wrote: > David Harris <[EMAIL PROTECTED]> on Feb 19, 2002: > > The encoded information is [...] split into reasonable length hidden > > fields. > > Why not put everything in one field? Are there restrictions? Does it > make a difference when using POST? The POST encoding dose not have a limit on data length. Heck, people use tags with huge amounts of content all the time. However, I didn't feel comfortable assuming that the HTML parser used by the browser could easily parse a potentially 20kb attribute. Basically, I didn't want to make my production application a stress-test for my user's browsers. :-) It was easy to break the data up into multiple hidden fields, because Base64 encoding breaks the data into multiple lines by default. I simply encoded each line in one hidden field. I would *NOT* use my module with a GET form if you expect any size of data. I've seen the query string get truncated at some arbitrary size limit. David
RE: [OT-ish] Session refresh philosophy
Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote: > > I built and use a module that encodes a session hash into a > > number of hidden fields with a security MD5 sum. > > Sounds a lot like CGI::SecureState. Have you ever looked at it? I just installed and played with CGI::SecureState (using the example in the POD) and it is totally different than my module. When I used CGI::SecureState it gave the client a non-versioning (more on that later) key and stored the state information in the filesystem. My module doesn't need to store any information in a database or in the filesystem. The entire state is given to the client in hidden form fields, and is passed back to the server on the next request. In addition, CGI::SecureState does not tie the state information to the *page*. With my module (or any method that stores the *data* in a hidden form field, not just a non-versioning key), state information is tied to the page. Let me explain: Imagine a multi-step order process where the user works through pages A, B, C, and D, (which contain forms) then uses the back button to go back to page B, changes the form values, and submits the form. With CGI::SecureState, page C will receive the state information stored by page D (that was intended for use by page E, we presume), instead of the state originally stored by page B (that was intended for page C). This is because all the pages share the same key, and old "versions" of the state are overwritten by the new "versions" and no longer available. When the back button is hit, a newer version of state may be used where an older version was intended. With my module, page C always gets the state information stored for it by page B, since the state is stored in hidden form fields in page B. The browser is actually storing the state and will always submit that same state to page C. (I have mentioned that CGI::SecureState uses a non-versioning key a few times. A way to make CGI::SecureState tie the state information to the actual page would be to change the key whenever the state changed, thus creating a versioning key. The key could be a hash of the state itself. This potentially means that a huge number of versions of the state would have to be stored on disk. I think this method would only be helpful if the state is large and it's not acceptable to pass it back and forth between the client.) In addition, CGI::SecureState gets fuddled if the user opens a new window (something I do often) and then starts performing different operations in each window using the same state key! It has no way of knowing a new windows exists and generating a new key. If you just store a customer id, customer name, and other rarely changing information in the state, these concerns may not matter to you. If you break a long form or order process into multiple pages, gathering new information on each page and storing it in the state so that you can process the order at the end, then this is a likely problem. David
RE: [OT-ish] Session refresh philosophy
David Harris [[EMAIL PROTECTED]] wrote:
[snip]
> I've attached some code. To use the code, you'll have to replace the
> module FreezeThawLite with Storable. Also, beware the \r\n newlines.
> (I pulled this out of CVS on my windows desktop.)
I forgot to actually attach the code
David
package Fusion::FormContainer;
use strict;
use Digest::MD5 ();
use MIME::Base64 ();
use FreezeThawLight ();
use Compress::Zlib ();
use Carp;
# this respresents a securty hole if we open-source this module.. the securtiy string
# needs to be passed as confguration at that point somehow.
sub _create_security_string
{
my $string = shift;
my $secret = <new;
$ctx->add($string);
$ctx->add($secret);
return $ctx->hexdigest;
}
sub encode
{
my $info = shift;
my $prefix = shift;
my $string =
MIME::Base64::encode(Compress::Zlib::compress(FreezeThawLight::freeze($info)));
$string =~ s/\n$//;
my @array;
push @array, ("${prefix}_fc_security", _create_security_string($string));
my $part_number = 0;
foreach my $part ( split "\n", $string ) {
my $part_number_string = sprintf("%.3d", $part_number);
push @array, ("${prefix}_fc_part$part_number_string", $part);
$part_number++;
}
if ( wantarray ) {
return @array;
} else {
my $html;
while ( @array ) {
my $name = shift(@array);
my $value = shift(@array);
$html .= <
EOT
}
return $html;
}
}
sub decode
{
my $apr = shift;
my $prefix = shift;
my $security = $apr->param("${prefix}_fc_security");
my @string_parts;
my $part_number = 0;
while ( 1 ) {
my $part_number_string = sprintf("%.3d", $part_number);
my $part = $apr->param("${prefix}_fc_part$part_number_string");
last if ( $part eq "" );
push @string_parts, $part;
$part_number++;
}
my $string = join "\n", @string_parts;
croak "tampered or malformed FormContainer: securty string and string don't
match"
if ( _create_security_string($string) ne $security );
return
FreezeThawLight::thaw(Compress::Zlib::uncompress(MIME::Base64::decode($string)));
}
1;
RE: [OT-ish] Session refresh philosophy
Drew Taylor [mailto:[EMAIL PROTECTED]]: > And that is what I am doing for a small project I'm working on now. In my > case, I'm not sure about the capabilities of the remote server, and I know > for sure that I don't have a database available, so session information is > saved via hidden form fields. It's primitive, but was actually a bit of a > challenge to make sure a (unused) hidden field and a visible form element > don't appear in the same . Not my first choice, but it definitely works. I built and use a module that encodes a session hash into a number of hidden fields with a security MD5 sum. The encoded information is serialized, gzipped, Base64 encoded, and then split into reasonable length hidden fields. It looks like this: This way, you don't have to worry about creating hidden form fields in your templates for every variable you need to encode. In your perl, simply call the session encode and decode methods. You are also assured that nobody messed with the data. You can easily "pass" arbitrarily complex session information from one page to another without using a database, and the session info is truly tied to the *page*. Use of the back button, therefore, doesn't break anything. I've attached some code. To use the code, you'll have to replace the module FreezeThawLite with Storable. Also, beware the \r\n newlines. (I pulled this out of CVS on my windows desktop.) HTH. David
mod_perl site challenge: proposal to use ASF site design
Hi, I've been watching the mod_perl site issue as it has progressed. Just last week Stas mentioned that voting at the online booth has been poor. (Low turnout.) I think I know why voting has been poor. And in my off-list conversation with Stas he's mentioned that other people have had the same opinions. I also think I have some constructive ideas. So, without further introduction, lets get into the thick of things. :-) I almost didn't vote for a site design. I went and looked at the three options: Allan Juul's design has navigation that doesn't help very much: it doesn't give "top level" links from every page and doesn't let you know where you are inside the site. The leaf pages don't even mention mod_perl anywhere, which is really weird and somewhat broken IMO. Carlos Ramirez's design is broken: broken navigation and pages that don't even exist. The page look is somewhat nice, but I can't really evaluate the navigation because it's so broken. Thomas Klausner's isn't broken in anyway and acceptable, but I don't really *like* the page look very much. So, because I liked none of the options and felt straight-jacketed with only one choice that was minimally functional, I almost didn't vote at all! In the end I voted for Klausner's in a simple defensive move to prevent a broken design from winning. I wish I had the time to create my own site and enter it into the competition. I'm think that others probably feel this way. However, the cause is not lost. We are not *required* as a community to pick one of these three proposed designs. This competition is just a tool to get a working site design. The mod_perl site needs a new design because: (a) it looks crummy and we are probably loosing users, (b) Stas is in the process of integrating the documentation into the site and therefore needs a new site design (and he's not a web designer). We can really do whatever we want. OK, now for the CONSTRUCTIVE PROPOSAL. :-) I propose that we simply use a site design that is the uniform "psudo-standard" for the Apache Software Foundation. A number of ASF projects are using this site design: http://www.apache.org/ http://httpd.apache.org/ http://jakarta.apache.org/ http://www.apache.org/foundation/ I used to think that this site design used by the ASF looked really dumb and plain. Now I think it rocks compared to these other three sites. It's simple and effective. Best of all, most of the design choices have already been made for us! Stas has pointed out the ASF site design uses different navigational features than the boilerplate site that he published back on 11/13/2001. This is true, but I think that we have some flexibility in changing the navigation. (I have some issues with the navigation in Stas' boilerplate, anyway.) I also suspect that one of the reasons that we've only had three sites contributed (and a couple of them broken) is because of the learning curve for learning Yet Another Publishing Tool (DocSet) that Stas is using. Additionally, we are a list mainly of programmers, not graphic designers. Perhaps having the graphic design issues solved by using the ASF site design, more people will be willing to volunteer to solve the programming issues of merging the existing DocSet boilerplate and the ASF design. OK. Now what to do with this? First what NOT to do: Please DO NOT respond and say "Oh, well, that's nice but please integrate some of the ideas from some other website that I like." This causes endless discussion that GOES NOWHERE. We need concrete proposals. This e-mail is not intended to cause a general discussion of what people would like to see in a website. This has happened before and resulted in no forward progress. (So you ask: why is David allowed to propose a new idea? What I'm proposing is that we just wholesale copy an existing site design -- one that already exists, is related to us through Apache, and we can copy without any shame. So, in effect, what I'm proposing is as concrete as the example sites already posted for voting.) The purpose of this e-mail is as follows: (a) See if others also think that the three alternatives for a mod_perl site are not very desirable. If you agree, please speak up and say that you agree. (b) See if others also think that using the ASF generic site design (even though it's not "cool and distinctive") would be a good idea. If you agree, please speak up and say that you agree. (c) Perhaps elicit a volunteer to design an example site that includes Stas' content and the ASF generic design. If enough people agree with the first two points, someone may be willing to volunteer to do this.. perhaps even one of the existing contributors who have already figured out DocSet. Perhaps even Stas! Lets try to keep this constructive, focused, and concrete. :-) Also, lets keep in mind something that Stas pointed out to me: most anything is a step up from our existing site design. So, if we go with one of the three existing options it's still a step up. David
RE: [OT] Re: Seeking Legal help
Sorry for continuing the OT thread. I just thought this might be useful... Gunther Birznieks [mailto:[EMAIL PROTECTED]] wrote: > By the way, if you are really working for a bank and cashflow is an issue > for you in 60 days you can also ask the bank what business banking services > they offer. One popular service with small businesses who have large > companies working for them is invoice factoring which allows you to sell > your invoice (if your company passes a credit check) to the bank for > something like 80% of the face value of the account and then when the bank > collects the invoice you get the rest minus interest and commissions. Factoring invoices can be a wonderful thing. May I recommend this company: http://www.facteon.com/ You need: (a) to pass a UCC search clean, (b) a credit worthy customer, (c) a contract with your customer, (d) and your customer to agree that the invoice is valid. Then you can get a good chunk of the money up front and more on payment of the invoice by the customer. Your fee depends on how long it takes your customer to pay. If they never pay, you keep the up-front payment and they book it as a loss. > It's unlikely that they would grant the same credit with a 1-man company > though. And I think they don't like dealing with service businesses. It's > usually more for dealing with suppliers with real inventory where the main > thing that can go wrong with an invoice is a pricing dispute over a line > item of widgets I suspect. >From what I know, Factelon works with one man companies and service industries. It's more important that your customer be creditworthy than you, since your customer must agree that the invoice is valid for it to be factored. David
RE: name-based virtual host ->suexec: command not in docroot
> I need to run a cgi from one of the virtual hosts, but I get the following > errors: > suexec.log - command not in docroot (/path/to/cgi) > error.log - Premature end of script headers: /path/to/cgi Suexec is compiled with a built in path which all requests must fall underneath as part of the security model. This isn't related to name based hosting, but rather to the document root path you are using. Read more about the suexec security model here: http://httpd.apache.org/docs/suexec.html#model David
RE: setting httpd cookie domains
David Harris <[EMAIL PROTECTED]> wrote: > These two should answer your question. You may also need to read section 4.3.4, "Sending Cookies to the Origin Server," to determine what cookies will be sent to what servers. The criteria you are probably looking for is this: }} The origin server's fully-qualified host name must }} domain-match the Domain attribute of the cookie. David
RE: setting httpd cookie domains
will trillich <[EMAIL PROTECTED]> wrote: > Pointers welcome, of course, to which FM i should R: > > In setting cookies via cgi or whatever, there's rules on > having to include at least two portions of your domain in the > cookie, such as for hyperarchive.lcs.mit.edu the minimum > domain allowable would be mit.edu, right? But you still have to > put the two dots in, as for example, ".mit.edu". > > Would this allow cookies from "smith.mit.edu" and "www.mit.edu" > AND "mit.edu" to be set properly? Or would they go into the bit > bucket, for greenpeace-friendly recycling? http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2109.html Here is how to compare domains from section two in the document: }} Hosts names can be specified either as an IP address or a FQHN }} string. Sometimes we compare one host name with another. Host }} A's name domain-matches host B's if }} }}* both host names are IP addresses and their host }} name strings match exactly; or }} }}* both host names are FQDN strings and their host }} name strings match exactly; or }} }}* A is a FQDN string and has the form NB, where N }} is a non-empty namestring, B has the form .B', and }} B' is a FQDN string. (So, x.y.com domain-matches }} .y.com but not y.com.) }} }} Note that domain-match is not a commutative operation: }} a.b.c.com domain-matches .c.com, but not the reverse. Here is section 4.3.2 which specifies under what criteria a user agent should reject a cookie: }}* The value for the Domain attribute contains }} no embedded dots or does not start with a dot. }} }}* The value for the request-host does not }} domain-match the Domain attribute. These two should answer your question. David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/
RE: Defining $PERL_CC
Bunck, Peter [mailto:[EMAIL PROTECTED]] wrote:
> Thanks, but I've already tried that one.
> I am using the ibm c(c)-compiler for aix cxx. When looking for solutions
for
> this problem, I saw some
> references to that problem. So I completly recompiled and reinstalled
perl.
> There is only one c-compiler
> available, so some weird mixup is also not possible.
> As for the resulting error, when the string where should stand "cc" is
> empty, you get error message of
> the type:
> -I -I../../os/unix -I../../include -DAIX=43 -U__STR__
> -DAIX_BIND_PROCESSOR -qnogenpcomp -qnouse
> pcomp -I/usr/local/sources/php/php-4.0.4pl1
> -I/usr/local/sources/php/php-4.0.4pl1/main -I/usr/local/sources/php
> /php-4.0.1pl2/main -I/usr/local/sources/php/php-4.0.4pl1/Zend
> -I/usr/local/sources/php/php-4.0.4pl1/Zend -I/usr
> /local/sources/php/php-4.0.4pl1 -DUSE_EXPAT -I../../lib/expat-lite
> -DNO_DL_NEEDED `../../apaci` -c mod_perl.c
> /bin/sh: -I: not found.
I just ran into this problem as well.
Your problem is that the PERL_CC variable in the Makefiles is blank because
of an error in the configuration scripts.
Try this patch:
begin patch ==
--- mod_perl-1.25.old/apaci/mod_perl.config.sh Thu Jun 7 08:15:28 2001
+++ mod_perl-1.25.new/apaci/mod_perl.config.sh Thu Jun 7 08:15:34 2001
@@ -107,8 +107,8 @@
# determine build tools and flags
#
-config_pm='-MApache::ExtUtils=%Config'
-#config_pm='-MConfig'
+#config_pm='-MApache::ExtUtils=%Config'
+config_pm='-MConfig'
perl_cc="`$perl_interp $config_pm -e 'print $Config{cc}'`"
perl_ccflags="`$perl_interp $config_pm -e 'print $Config{ccflags}'`"
perl_optimize="`$perl_interp $config_pm -e 'print $Config{optimize}'`"
end patch ==
This undoes the following change:
http://www.apache.org/websrc/viewcvs.cgi/modperl/apaci/mod_perl.config.sh.di
ff?r1=1.20&r2=1.21
On this file:
http://www.apache.org/websrc/viewcvs.cgi/modperl/apaci/mod_perl.config.sh
An interesting interaction happens if you have a previous copy of mod_perl
installed (specifically the mod_perl package in Red Hat 7.1) when you try to
build. If mod_perl is already installed then the existing libperl.a is
brought from there instead of being compiled anew. No errors are shows an
the build fails. If you remove the existing mod_perl installation then these
errors stop the build process.
Doug, perhaps you could look into this and see why it broke and why it
sometimes builds successfully even with these errors?
David
RE: Real Widgets and Template Languages [resend]
uck to one specific display
look constrained me. So I told the widgets how to print their labels with
"c_blank" and "c_table" parameters and inlined HTML code.
This really calls for the widgets to be embedded directly in the HTML
template which contains the formatting a la that
Gunther proposed.
This above code actually sits in a subroutine that returns a list of the
definitional information. This list is then simply included other places so
I can write stuff like this:
[
[qq[
Enter your billing information and credit card.
]],
[qq[ Billing information ]],
[{ default_by_name => CUST::DbAccess::Cust::default_by_name("custs") }],
CUST::InterfaceUtil::opensrs_contact_fields($country_select_box, "bill",
"Billing"),
undef,
[qq[ Credit card information ]],
[{ default_by_name => CUST::DbAccess::Ccard::default_by_name("ccards") }],
CUST::InterfaceUtil::credit_card_fields(),
undef,
]
It's great for reuse.
The default_by_name does something interesting: it imports all the defaults
for the fields (_looks_like and _required and _size) information from the
database table. If I change the size of a text field in a table all the
forms which use that text field are automatically updated. (However, I
should change the default_by_name system so that it doesn't need to be
specified when I'm including default confirmation. Like I said, this system
is straining under the evolution.)
I can contribute this library if it would help. I'll warn you that there's
not too much documentation. I can also contribute some examples of my code
that use the library.
David Harris
President, DRH Internet Inc.
[EMAIL PROTECTED]
http://www.drh.net/
RE: Real Widgets and Template Languages
ters and inlined HTML code.
This really calls for the widgets to be embedded directly in the HTML
template which contains the formatting a la that
Gunther proposed.
This above code actually sits in a subroutine that returns a list of the
definitional information. This list is then simply included other places so
I can write stuff like this:
[
[qq[
Enter your billing information and credit card.
]],
[qq[ Billing information ]],
[{ default_by_name => CUST::DbAccess::Cust::default_by_name("custs") }],
CUST::InterfaceUtil::opensrs_contact_fields($country_select_box, "bill",
"Billing"),
undef,
[qq[ Credit card information ]],
[{ default_by_name => CUST::DbAccess::Ccard::default_by_name("ccards") }],
CUST::InterfaceUtil::credit_card_fields(),
undef,
]
It's great for reuse.
The default_by_name does something interesting: it imports all the defaults
for the fields (_looks_like and _required and _size) information from the
database table. If I change the size of a text field in a table all the
forms which use that text field are automatically updated. (However, I
should change the default_by_name system so that it doesn't need to be
specified when I'm including default confirmation. Like I said, this system
is straining under the evolution.)
I can contribute this library if it would help. I'll warn you that there's
not too much documentation. I can also contribute some examples of my code
that use the library.
David Harris
President, DRH Internet Inc.
[EMAIL PROTECTED]
http://www.drh.net/
RE: DB_File::Lock and the STOP button
Hi, If a script using DB_File::Lock is interrupted by the STOP button, the file will be appropriately unlocked. When using DB_File::Lock, there really is no "critical section" for making sure that the lock will be released appropriately. If a fatal exception happens while the database is open, the lock will be released when the perl garbage collector removes the tied variable. When this variable is cleaned up and "untied", DB_File::Lock catches the untie call and removes the lock while also closing the database in the correct order. This is why DB_File::Lock exists: to catch this case. If the locking was done like this: Gain_lock() Open_database() Use database Close_database() Loose_lock() Then there would be a "critical" section where if the code was interrupted by the STOP button or a die() exception, the user wouldn't be guaranteed that the database and/or lock would be closed and what order that would happen. If you are using DB_File::Lock, the code running while the database is open is still "critical" in another sense: other processes are prevented from getting locks they may desire. So, it's important to make sure that your code doesn't do any unnecessary time-consuming processing while the database is open. David -Original Message- From: Dave Edsall - The Tauminator [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 16, 2001 3:47 PM To: [EMAIL PROTECTED] Subject: DB_File::Lock and the STOP button I have a question about DB_File::Lock with a database and users hitting the STOP button. We have recently converted a database from an ASCII flat file to db file. The ASCII flat file used flock() to lock the files. Now that we have switched to DB_File, we have adopted DB_File::Lock as our locking mechanism What we have essentially is: my($strDBFilename) = "msglist.db"; my($locking)="write"; tie(%msglistdb, 'DB_File::Lock', $strDBFilename,O_CREAT|O_RDWR, 0644,$DB_HASH,$locking) [...critical stuff...] untie(%msglistdb); If everything goes normally, this will provide a locked fence file that will be unlocked when the file is closed during the untie. If I have read the mod_perl guide correctly, when a user hits the STOP button on a browser while the "critical stuff" is being processed, the script will abort and the files will be closed and the fence file unlocked because we magically go out of scope at the point of the abort. Is this a correct reading? Will the lock be removed when the user hits the STOP button? If so, for my own erudition, can someone explain to me why we go out of scope in this case and why/how the files are closed when we go out of scope? Thanks in advance, Dave
RE: [OT] 128 bit encryption and IE
Geoffrey Young [mailto:[EMAIL PROTECTED]] wrote: > Hi all... > > sorry for the OT, but has anyone figured out how to tell whether a browser > supports 56 or 128 bit encryption? Apparently, users of IE with 56 bit, > when entering a 128 bit page, get the standard Cannot Find Server error page > with little in the way directions to help the EU know to upgrade. > > has anyone battled this and come up with an elegant solution? > > thanks > > --Geoff If you are getting a "Cannot Find Server" error in 56-bit browsers it is because the server and browser are not able to negotiate a cipher to use. Normally, the SSL server will simply downgrade the key size and talk appropriately with 56 bit browsers. However, in configuring your SSL server you can limit what ciphers and key sizes will be considered acceptable. Consider allowing your server to use non 128-bit ciphers. Under mod_ssl configure the SSLCipherSuite configuration directive appropriately. (Also look at the SSLRequire directive if this does not solve things.) Docs here: http://www.modssl.org/docs/2.8/ssl_reference.html#ToC9 To determine the cipher currently being used, look at the environment under mod_ssl. My server shows me this for a sample connection: SSL_CIPHER=RC4-MD5 SSL_CIPHER_ALGKEYSIZE=128 SSL_CIPHER_EXPORT=false SSL_CIPHER_USEKEYSIZE=128 Docs here: http://www.modssl.org/docs/2.8/ssl_reference.html#ToC25 I'm sure you can build whatever system you need on top of this. David
RE: [OT] 128 bit encryption and IE
Gunther Birznieks [mailto:[EMAIL PROTECTED]] wrote: > Now, with strong encryption walls having been broken down in the US, maybe > global certs no longer qualify you to have to be a bank? Thawte calls these "SuperCerts" and you don't have to be a bank: }} Who can get a SuperCert? }} The new US encryption export regulations took effect on }} 14 January 2000. In terms of the new regulations, Thawte }} may now export SuperCerts to any non-government entity }} and to any commercial government-owned entity (except }} those that produce munitions), in any country except }} Afghanistan (Taliban-controlled areas), Cuba, Iran, Iraq, }} Libya, North Korea, Serbia (except Kosovo), Sudan and }} Syria. See: http://www.thawte.com/certs/server/128bit/contents.html David
RE: Long waits on SQL Stored Procs. Should I use chained content handlers?
One could handle this all in one request with an HTML layer controlled by JavaScript that performs counting for the user. This is better that multiple requests because you don't have to try starting processing in one HTTP request and giving the result to another HTTP request. Run everything in one request and life is simpler. For an example of something I have working go to http://www.drh.net/site/domain/new.shtml and then search for a domain. The box that pops up before the page has fully loaded is a layer. View the source to see the JavaScript code controlling the layer. Replace my machinery to perform a count in the layer with a simple animated gif if you like. I don't have any public examples that show how it works when the page takes a while to load. Those are all on the internal website. Here is the code: http://www.davideous.com/misc/Fusion-Countdown.pm This code not supported. This is the basic idea: take it and run. David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, April 02, 2001 10:07 AM To: [EMAIL PROTECTED] Subject: Long waits on SQL Stored Procs. Should I use chained content handlers? I need to run some stored procedures that take upwards of a minute to generate result sets. Ok, thats grand but I dont want the browser to sit there and twiddle. I'd like to display an animated gif. Simple. Right? I hope. I'm looking into chained handlers in my mod_perl code, but I'm not sure if this is what I need. 0) Request page and report. 1) Push 'Waiting...' animated gif 2) Process report, Perl waits for result set 3) Perl pushes the report html to the browser as if it opened in a target = _blank window. IE: That same window... Stumped (or rather -> RTFMing), Any ideas? I cant, for the life of me, figure out how this would work with http redirects, and thought there might be something with mod_perl that would help this. Fork() maybe. I'm trying a few ideas. Thanks a bunch. If this is slightly OT, I apologize. Tom Sullivan, [EMAIL PROTECTED] - This message was sent using Endymion MailMan. http://www.endymion.com/products/mailman/
RE: dbm locking info in the guide
(I apologize in advance for the horrible line wrapping my mailer will do.) Stas Bekman [mailto:[EMAIL PROTECTED]] wrote: > > Now you have a concern with upgrading locks from shared to exclusive: > > > > > David, please consider this scenario: > > > > > > ... At some point in time, processes A and B both read from the dbm via SH > > > lock. > > > > > > 1. A completes its reading and unlocks the DBM, while still having the > > > first 4k cached. (A still has the dbm tie()'d. > > > > > > 2. B wants to write, so it requests an EX lock and gets it granted. > > > > This will not happen. When B requests the EX lock it will block until all of > > the other shared locks have been released. Process A has to release the SH > > lock somehow for B to get the EX lock. Either A simply finishes and releases > > the lock, or A requests an upgrade, is denied, and handles this by releasing > > the lock. > > That's if you code it that way. Nothing prevents you from unlocking A, and > then asking for some lock later. You always want to make the critical > section as short as possible. So if you need to access the dbm file twice > through the request. You may go through this scenario: > > A: flock SH > B: flock SH > A: flock UN > B: flock EX > B: flock SH > A: flock SH > > 'A' still have the data cached and possibly invalid. > > Your proposed system is clean only in this case: > > You can never explicitly unlock dbm and then relock it without calling > untie(). You can safely upgrade the lock from SH to EX and downgrade from > EX to SH though, without using UN (sort of semi-atomically). Perhaps we have a misunderstanding here. I would NEVER flock(UN) without having just previously untie()d the database. And I would ALWAYS acquire a lock immediately before tie()ing the database. I would never drop the lock while keeping the database open (but not writing to it) and then reacquire a lock at a later date and start reading or writing the database. Perhaps this _could_ be done in some cases (even though it seems it invalidate the whole idea of a lock on a resource IMHO), however, since sync() does not re-read data from disk it can't be done in this case. When I said: }} Process A has to release the SH }} lock somehow for B to get the EX lock. Either A simply finishes and releases }} the lock, or A requests an upgrade, is denied, and handles this by releasing }} the lock. I assumed that the if A releases the SH lock, it has closed the database. Releasing the lock is a guarantee that A no longer has the database open. If A at some future time reacquires a lock, it then just reopen the database. > > When the EX lock is granted (whether from an upgrade or not), by definition > > no other processes can have a SH lock and be reading the database. No other > > processes can have a first 4k cached because no other processes can have the > > file open. > > They can, if there weren't untie()d per my above explanation. Just don't unlock without untie()ing first and you are fine. Like I said, this was my assumption, just never stated. Sorry for not being clear. David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/
RE: dbm locking info in the guide
Stas, Sounds like you agree with me that downgrading locks from exclusive to shared is not a problem with the method I described in the last e-mail. Now you have a concern with upgrading locks from shared to exclusive: > David, please consider this scenario: > > ... At some point in time, processes A and B both read from the dbm via SH > lock. > > 1. A completes its reading and unlocks the DBM, while still having the > first 4k cached. (A still has the dbm tie()'d. > > 2. B wants to write, so it requests an EX lock and gets it granted. This will not happen. When B requests the EX lock it will block until all of the other shared locks have been released. Process A has to release the SH lock somehow for B to get the EX lock. Either A simply finishes and releases the lock, or A requests an upgrade, is denied, and handles this by releasing the lock. When the EX lock is granted (whether from an upgrade or not), by definition no other processes can have a SH lock and be reading the database. No other processes can have a first 4k cached because no other processes can have the file open. >From the flock manpage: "A single file may not simultaneously have both shared and exclusive locks." > 3. B modifies the data in the first 4k, syncs it and releases the lock. > > 4. A asks for SH or EX lock, gets it, but its cache is invalid. > > => we have a data corruption (especially in the case A does writing into > the first 4k) David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/ -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 22, 2001 10:22 PM To: David Harris Cc: mod_perl list Subject: RE: dbm locking info in the guide On Thu, 22 Mar 2001, David Harris wrote: > Two points about switching from exclusive mode to shared mode: > > (1) When downgrading from EX to SH, no other processes need to have cached > data invalidated because no one else can have the database open. There is no > cache in other processes, therefore none to be invalidated. > > Explanation: Lets say the method for downgrading a lock from EX to SH is > like this: write data, sync(), flock(FLOCK_SH), read data. Until the > flock(FLOCK_SH) nobody else can have the database open because of the > exclusive lock. Therefore, there will not be any other processes with the > database open and the first 4k cached in memory when the sync() happens. David, please consider this scenario: ... At some point in time, processes A and B both read from the dbm via SH lock. 1. A completes its reading and unlocks the DBM, while still having the first 4k cached. (A still has the dbm tie()'d. 2. B wants to write, so it requests an EX lock and gets it granted. 3. B modifies the data in the first 4k, syncs it and releases the lock. 4. A asks for SH or EX lock, gets it, but its cache is invalid. => we have a data corruption (especially in the case A does writing into the first 4k) > (2) When downgrading from EX to SH, our processes does not need to > invalidate cached data because its cached data is correct at the sync() and > the data on disk will not be changed until the database is closed. > > Explanation: Again we downgrade form EX to SH by doing this: write data, > sync(), flock(FLOCK_SH), read data. Our cache remains valid the entire time > here. With the sync(), data in our cache is written to disk, so at that > point we are good. Then after the flock(FLOCK_SH) we are still good because > the shared lock prevents anyone else from writing to the database and > changing the data on disk. There is no need to do a re-tie(). That's correct. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: dbm locking info in the guide
Stas Bekman [mailto:[EMAIL PROTECTED]] wrote: > On Thu, 22 Mar 2001, David Harris wrote: > > If you want to downgrade a lock from exclusive to shared, sync the database > > and change the lock status. This will allow other readers access to a > > fully-written database. No one else will be allowed to write the database > > (requiring your process to have invalidated any cached data) until you have > > released the shared lock. No problem there. > > Are you sure? Doesn't it contradict with the fact that other readers have > already cached the first 4k of data? And you have modified the database > and possibly the first 4k during the write, so if this is the case, now > readers have the wrong 4k in their cache. > > Or do you mean that when a process that switches from EX to SH, doesn't > need to re-tie(), since it has *its* cache valid. Other process do need to > re-tie when acquiring any kind of lock, if they don't have none yet. Two points about switching from exclusive mode to shared mode: (1) When downgrading from EX to SH, no other processes need to have cached data invalidated because no one else can have the database open. There is no cache in other processes, therefore none to be invalidated. Explanation: Lets say the method for downgrading a lock from EX to SH is like this: write data, sync(), flock(FLOCK_SH), read data. Until the flock(FLOCK_SH) nobody else can have the database open because of the exclusive lock. Therefore, there will not be any other processes with the database open and the first 4k cached in memory when the sync() happens. (2) When downgrading from EX to SH, our processes does not need to invalidate cached data because its cached data is correct at the sync() and the data on disk will not be changed until the database is closed. Explanation: Again we downgrade form EX to SH by doing this: write data, sync(), flock(FLOCK_SH), read data. Our cache remains valid the entire time here. With the sync(), data in our cache is written to disk, so at that point we are good. Then after the flock(FLOCK_SH) we are still good because the shared lock prevents anyone else from writing to the database and changing the data on disk. There is no need to do a re-tie(). David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/
RE: dbm locking info in the guide
Stas Bekman [mailto:[EMAIL PROTECTED]] wrote: > As the person who has discovered this bad flaw in DB_File docs and made > sure that the right thing will be done, may be David will have a time to > go further and check up on this issue. I would definitely do it myself, > but there so many things I've to do, I just cannot do it now :( > > Or anybody else who wants to contribute to the community by a little > effort? Just grab the tgz which represents the problem, from the url > posted a few days ago by David and see if you can tackle this issue of the > correctness of using sync and the actual benchmarking to check whether > it's faster to do tie/untie or using sync and locking... > > Thanks a bunch! I have done some investigation of the sync method in DB_File and this is what I have determined: the sync method only writes cached information out to disk. Information already cached in the process is not invalidated causing a re-read from the disk. My example program and the annotated strace can be found here for anyone that wants to see the details: http://www.davideous.com/misc/dblockflaw-1.2-checksync/synctest.pl http://www.davideous.com/misc/dblockflaw-1.2-checksync/synctest.strace01 Here is what I think this means for locking: If you want to downgrade a lock from exclusive to shared, sync the database and change the lock status. This will allow other readers access to a fully-written database. No one else will be allowed to write the database (requiring your process to have invalidated any cached data) until you have released the shared lock. No problem there. If you want to upgrade a lock from shared to exclusive, simply request this upgrade from the locking subsystem and write to the database once an exclusive lock has been acquired. Since the database has been in a shared lock since it was opened no one has written to it. Therefore, no invalidation of cached data is required since the database on disk has not changed. Beware when upgrading shared locks to exclusive locks that: (a) you don't get a deadlock with two shared locks trying to upgrade at the same time, and (b) if your locking layer resolves this deadlock by denying one of the upgrade requests, make sure your program handles that appropriately. I imagine one would handle a lock upgrade failure by closing the database and then requesting an exclusive lock. Perhaps one would want to rollback changes made to the database or otherwise prepare for this transition. I'd rather just grab an exclusive lock at the beginning if I know there's a chance of needing to write the database later on. Or just close and re-open the database instead of trying the upgrade at all. Everyone may have their own particular application that needs something special. However, I'd rather just use a RDMS if I'm running into this level of locking details. Then again, none of that is related to sync as it is not required for a lock upgrade. :-) OK, summary: (1) Seems to me that sync should only be used for downgrading exclusive locks to shared, and that sync is well suited for this task. (2) You can upgrade locks from shared to exclusive without sync, but you might want to avoid needing to upgrade locks because of deadlock problems. Hope this helps. (Thanks for the break from the Windows2k nightmare. Why does Oracle Enterprise Manager only run on w2k?! Well, back to work :-) David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/
RE: dbm locking info in the guide
Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote: > I think you'll still have problems with this technique, unless you > tie/untie every time. I'm looking at the perldoc for DB_File version > 1.76, at the section titled "Locking: the trouble with fd". At the very > least, you'd have to call sync after acquiring a write lock but before > writing anything. Here is more information from the original discovery of the bug. This contains the test cases that actually show the database corruption. Also some documentation on the details such as systraces that show reading happens before the flock system call. http://www.davideous.com/misc/dblockflaw-1.2.tar.gz http://www.davideous.com/misc/dblockflaw-1.2/ Sync may or may not work, depending on how the low level buffering is implemented. If it re-reads all information from disk I don't think you have any advantage over simply closing the DB_File and opening it again. It's also worthwhile to use an external lock file because that properly locks for database creation. David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/
RE: [OT] ApacheCon BOF
Geoffrey Young [mailto:[EMAIL PROTECTED]] wrote: > o unfortunately, we can't get into the biz of selling any. the logistics > of that is just too much. What about using a service like www.cafepress.com where you upload the artwork and they take care of all the logistics: order taking, payment, manufacturing, shipping, and customer service. You can increase your price over their "base" and donate the money to perl somehow, or just sell at the base price. It would also be easy enough to upload the artwork from last year. David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/
RE: Antwort: Repost: Anyone using "virtual server" for mod_perl hosts?
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] wrote: > Hi, > > I'm using a similar service at services.superb.net since last Friday (thanx > Martin :-), USD79/month, Linux. > > They already had a Apache 1.3.9 with mod_perl 1.21 and Perl 5.005_03 + > mod_frontpage + mod_php + mod_ssl. That all seemed to work, but I quickly > uninstalled it and compiled my own perl/mod_perl/apache - Apache Toolbox is > great... :-) > > I'm happy with this virtual box and had no problems. > > Michael, http://j-e-b.net Superb is using Ensim's ServerXchange product. http://services.superb.net/sps/spslite.shtml http://www.ensim.com/Products/serverxchange.htm The Superb page mentions that you get 1/30th of a Intel P3 750mhz, so it's not running on Big Iorn. Perhaps Ensim is using vmware GSX or ESX server: http://www.vmware.com/products/ Does anyone have any insight to the particular solution Ensim is using? Back on topic this really does seem like the right way to run reasonable mod_perl hosting. Having root, you are able to truly administrate your box. And the virtual-server-partitioning-software (like vmware) sets up real Quality of Service commitments for RAM and disk space and even bandwidth. Another user's out-of-control mod_perl server can't affect yours. David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/
RE: [RFC] mod_perl Digest path...
> Looks like I can get a lot closer with Pod::Text, the sad thing is that > Pod::Text can't read from anything but a file. *sigh* That's what /proc/self/fd/0 in Linux is for. :-) $ ps | cat /proc/self/fd/0 PID TTY TIME CMD 16085 pts/600:00:00 bash 18434 pts/600:00:00 ps 18435 pts/600:00:00 cat This works as long as the reader does not need to seek in the file, which I doubt will be a problem if a perl module is doing the reading. You'll probably need to have Tod::Text run in a different process, but at least you can now have it as part of a pipe. David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/
RE: problem connecting to oracle with DBD-Oracle-1.06/DBI-1.14 with Perl version v5.6.0 for Apache/1.3.12 (Unix) mod_perl/1.24 mod_ssl/2.6.6 OpenSSL/0.9.5a
HotMail: Bill [mailto:[EMAIL PROTECTED]] wrote:
> I've got a system running the following:
>
> Perl version v5.6.0 for Apache/1.3.12 (Unix) mod_perl/1.24 mod_ssl/2.6.6
> OpenSSL/0.9.5a
>
> If I run the cgi scripts from command line they connect to the oracle
> database just fine.
>
> If I run them under the webserver (apache::registry), the cannot connect to
> the database.
> ORA-12054 error.
>
> Has anyone seen this before or have an idea on how to track down the
> problem?
> All help will be very appreciated.
>
> Thanks,
> Bill
Do you have the environment setup correctly? To connect from mod_perl I do the
following in my modules:
sub get_database_handle
{
my ($db_user, $db_pass, $ora_home, $ora_sid) = get_userpass();
$ENV{ORACLE_HOME} = $ora_home;
$ENV{ORACLE_SID} = $ora_sid;
my $dbh = DBI->connect("dbi:Oracle:", $db_user, $db_pass,
{ RaiseError => 1, AutoCommit => 0, PrintError => 0 } )
or die "unable to connect: $DBI::errstr";
return $dbh;
}
I looked up ORA-12054 (for my server version) and got:
ORA-12054 cannot set the ON COMMIT refresh attribute for the materialized view
Cause: The materialized view does not satisfy conditions for refresh at commit
time.
Action: Specify only legal options.
which does not make much sense to me.
David Harris
President, DRH Internet Inc.
[EMAIL PROTECTED]
http://www.drh.net/
RE: [OT] Will a cookie traverse ports in the same domain?
Blue Lang [mailto:[EMAIL PROTECTED]] wrote: > On Thu, 19 Oct 2000, martin langhoff wrote: > > > hi, > > > > this HTTP protocol (definition and actual implementation) question is > > making me mad. Will (and should) a cookie be valid withing the same > > host/domain/subdirectory when changing PORT numbers? > > well.. by my reading of the RFC, and I might be wrong, but it looks like > port should be ignored in cases where the hostname is used in the uri. > > http://www.cis.ohio-state.edu/htbin/rfc/rfc2109.html Netscape has/had a bug where a cookie sent to http://www.server.com/ would not be returned when visiting http://www.server.com:80/. David
[Available for a Job] mod_perl/Oracle/linux/web guru
I'm looking for a mod_perl consulting job anywhere from two weeks to a month long. I'm available starting at the beginning of next week, and I can work remotely or fly out to your location. I am a mod_perl, Oracle, web database, and Linux guru. I've contributed to mod_ssl, mod_perl, Apache, and RedHat projects as well as being a CPAN author. Also started a number of small open source projects of my own at www.davideous.com. Find more information on what I can do for you at: http://www.davideous.com/statement_of_capabilities.txt (Stas gave a thumbs-up for posting job availability on this list back on 8/10/2000, so I figured I'd let the list know.) David
RE: open(FH,'|qmail-inject') fails
Stas wrote: > On Fri, 8 Sep 2000, Perrin Harkins wrote: > > Nevertheless, in benchmarks we ran we found forking qmail-inject to be > > quite a bit faster than Net::SMTP. I'd say that at least from a > > command-line script qmail-inject is a more scalable approach. > > Quite possible, I was talking about the fat sendmail binaries :) Yes, quite possible. Using SMTP and qmail-inject both have the overhead of a fork, because the SMTP tcpserver will fork off a copy of qmail-smtpd to handle the request. Additionally, the SMTP tcpserver is probably doing a reverse DNS lookup and probably an ident lookup which would probably cause another fork for identd. (Both reverse DNS and ident lookup are enabled by default in ucspi-tcp-0.84.) This network activity and possibly another fork will cause delay. The overhead of forking directly off from mod_perl does not seem so bad when you look at copy-on-write memory managers. The fork: (a) does not cause copying of the big mod_perl process at fork thanks to copy-on-write, and (b) there will be virtually no dirtying of pages and copying because a exec() will be immediately done. A possible problem is qmail-inject inheriting a bunch of filehandles from mod_perl, but they should all be marked close-on-exec. David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/
[ANNOUNCE] DB_File-Lock-0.04.tar.gz (bugfix release)
Hi, The URL http://www.davideous.com/dbfilelock/DB_File-Lock-0.04.tar.gz has entered CPAN as file: $CPAN/authors/id/D/DH/DHARRIS/DB_File-Lock-0.04.tar.gz size: 6488 bytes md5: a948d5213826eef0b335617531330387 This module was originally developed to provide proper locking for DB_File for use with mod_perl. For more info about DB_File locking see: http://perl.apache.org/guide/dbm.html#Flawed_Locking_Methods_Which_Mus >From the Changes file: 0.04 Fri Aug 11 09:08:48 EDT 2000 - Three good fixes from Robert Mathews <[EMAIL PROTECTED]>. (Thanks to him for submitting a patch!) In his own words: (1) The first one is nothing big: test 16 fails with BerkeleyDB v1.85 on solaris 5.6. This seems to be due to the fact that we're creating a database (and therefore writing to it), but it's only read-locked. (2) The second is that TIEHASH assumes that SUPER::TIEHASH will succeed. If it doesn't, the lockfile gets left open, and DESTROY is never called to close it. (3) I ran into one other issue: umask isn't restored if sysopen on the lockfile fails. Fixed that too. David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/
RE: weird print bug?
T.J. Mather [mailto:[EMAIL PROTECTED]] wrote: > However it doesn't work if you apply a non-greedy substitution operator on > the scalar. You mean "global", not "greedy" Two snippets from the perl documentation: s/PATTERN/REPLACEMENT/egimosx Options are: e Evaluate the right side as an expression. g Replace globally, i.e., all occurrences. i Do case-insensitive pattern matching. -- and -- By default, a quantified subpattern is ``greedy'', that is, it will match as many times as possible (given a particular starting location) while still allowing the rest of the pattern to match. If you want it to match the minimum number of times possible, follow the quantifier with a ``?''. Note that the meanings don't change, just the ``greediness'': *? Match 0 or more times +? Match 1 or more times David
RE: Using handler for index
Drew Taylor wrote: > Chris Winters wroe: > > > > This always worked for me: > > > > > > SetHandler perl-script > > PerlHandler ModuleName > > > Well, seems like I tried that, and then it ALWAYS used that handler. I > also have other handlers, and I _think_ the setup above overrode the > others. I'll give it a try again now. OK, I just tried it, and it > overrode everything else. :-( I use this: SetHandler perl-script PerlHandler $MATCH::method_objs::provider_project_selector->handler It does not override everything else, and you get the right handler called. The problem is that matches any URI that BEGINS with that substring. LocationMatch is a regular expression driven thing, so you can make it just match that one specific URI. David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/
RE: [admin] no HTML posts please
This list is hosted on a qmail ezmlm combination at the apache boxen, no? Well, we could setup the list to strip the HTML section out of multipart/alternative messages and bounce those messages which are only HTML. Some of the code already exists at http://www.qmail.org/no-alternative but it should be extended a bit. I also have a procmail filter setup so I hardly ever actually see the HTML messages. I don't have to time to set this up now (blame consulting jobs that drag on), but I thought I'd suggest it. - David Harris Principal Engineer, DRH Internet Inc. -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 18, 2000 8:26 AM To: mod_perl list Subject:[admin] no HTML posts please "When thou enter a city, abide by its customs" -- Talmud Please, please refrain *posting* in *HTML*! If you want to get help, take another second to *think* what are you doing *before* you send the email... Say 'Yes' to the plain text, 'No' to HTML! Thank you! [[[snip]]]
PerlDispatchHandler for error handling?
Hey, Does anybody know how to use PerlDispatchHandler to somehow trap errors in perl? I think I remember somebody mentioning that... I've been looking around and I can't find too much of any documentation about what PerlDispatchHandler actually does. (Already checked the archives and www.modperl.com.) Anybody know what actually PerlDispatchHandler does? :-) - David Harris Principal Engineer, DRH Internet Services
RE: [Embperl] Packages and shared code.
Martin A. Langhoff wrote:
> Now I'm trying to go one step further and make the code ready to be
> implemented in a few more sites. The problem is that both the code and
> static varibles remain there in memory-space in a 'shared package'. And
> this 'shared package' model blocks me from having many sites with
> a] different 'configuration related' static variables
> b] different code versions
(a) keep from putting your 'configuration related' static variables in the
code. Either user a PerlSetVar configuraton or a package with just
configuration information, I'd say.
(b) for the different code versions, don't set the package using an eval.
Perhaps do something like setting up a hash with values which are references to
subs
perhaps $MyCalendar::handlers->{$code_version}{$functions_name} could be how
you reference all of your functions for all of your code versions. Each code
version is in a package like MyCalendar::vTwo and it's smart enough to setup
it's own $MyCalendar::vTwo->{$function_name} hash and create a reference to it
in $MyCalendar->{$code_version}. You can then pass the $code_version to your
front end embperl code as a string in a PerlSetVar config.
If you pass which code version in a PerlSetVar, you can probably have the same
embperl code referenced from different virtual hosts with different
configuration values
Now, this is not the only way to do it.. and it's probably not the best. I'm
sure the OO people will say, "setup a hash of constructors for all your code
versions." But it's just here to give you some ideas.
- David Harris
Principal Engineer, DRH Internet Services
RE: $r->notes()...
Sean Chittenden wrote:
> If I use $r->notes in a mod_perl handler, is it accessible via the
> core apache request object in other non-perl modules?
>
> $r->notes('foo','bar');
>
> Is the value of notes stored in the core apache process and if so,
> is it accessible by other modules by their similar r->notes methods (ie,
> mod_java or some custom C module)? If not, why not? I wouldn't expect to
> be able to store hashes, etc (use a global var, such as
> $sitename::globalvar for that), but strings?
>
> My question being stemmed from the possibility of having to use
> mod_java and mod_perl on the same server and getting the two to talk to
> each other in a friendly manner. Anyone have any experience w/ this or
> tips w/ regards to the best way of going about this kind of a setup?
I've got this working. I'm passing notes between mod_pop3 and mod_perl, and
it's really handy.
First, I've got a mod_perl fixup handler that tosses some info in the
environment which is later read by mod_pop3. (I could have done this with
notes, but I chose env.) Then, the PHP application sometimes calls the
mod_perl app, by marking up a bunch of notes in its own request and then
issuing a sub-request to a mod_perl page. The mod_perl request handler that
gets this internal sub-request reads those notes and writes its replies in
the same place.
I read setup this request with:
if (isset($user) && substr($user,0,1) == "+") {
apache_note("imp_euser", substr($user,1));
virtual("/internal/getquota");
$quota = apache_note("imp_quota");
$quota_pp = apache_note("imp_quota_pp");
$usage_pp = apache_note("imp_usage_pp");
$percent_pp = apache_note("imp_percent_pp");
if ($quota)
$message .= " | Using $percent_pp% of $quota_pp limit";
}
and then read and write the notes with $r->main->notes from mod_perl.
- David Harris
Principal Engineer, DRH Internet Services
RE: oracle : The lowdown
David Harris wrote: > What about PostgreSQL (www.postgresql.org)? It looks like it has transaction > management (commit, rollback) with the whole concurrency control thing. I > don't know if has views. I've got a small project that I am figuring on > using PostgreSQL for, so I'm curious to hear what people might have to say > about it. This link was just posted to the IMP list a couple min ago: "Low-Cost Unix Database Differences" http://www.toodarkpark.org/computers/dbs.html Stas, this might be a good link to drop somewhere in the guide. - David Harris Principal Engineer, DRH Internet Services
RE: oracle : The lowdown
Jeff Warner wrote: > We were a mySQL shop. We replaced mySQL with Oracle8i/mod_perl and > and Apache::DBI. Works great, once it is all setup. Our overall > processing is faster with Oracle too. The lack of transactions and > views put an immediate end of mySQL once we got into the details of my > project. > > Oracle is overkill for smaller task but you don't have to worry about > outgrowing it. What about PostgreSQL (www.postgresql.org)? It looks like it has transaction management (commit, rollback) with the whole concurrency control thing. I don't know if has views. I've got a small project that I am figuring on using PostgreSQL for, so I'm curious to hear what people might have to say about it. Another option to look at is Solid (www.solidtech.com). They just quoted me their Solid Embedded Server (their name for a database server) for $2,000 per CPU. I used their database server a few years ago and it was very nice. Back then it cost only $200, too... :-) - David Harris Principal Engineer, DRH Internet Services
Summary of DB_File locking wrappers
There are three locking wrappers for DB_File in CPAN right now. Each one implements locking differently and has different goals in mind. It is therefore worth knowing the difference, so that you can pick the right one for your application. NOTE: It is imperative that if you are going to use DB_File with mod_perl that you use some kind of locking wrapper -- just placing a flock before the tie, like in regular CGI, does not cut it. For more information about why you must do this, see the mod_perl guide: http://perl.apache.org/guide/dbm.html#mod_perl_and_dbm Here are the three locking wrappers: Tie::DB_Lock -- DB_File wrapper which creates copies of the database file for read access, so that you have kind of a multiversioning concurrent read system. However, updates are still serial. Use for databases where reads may be lengthy and consistency problems may occur. Tie::DB_LockFile -- DB_File wrapper that has the ability to lock and unlock the database while it is being used. Avoids the tie-before-flock problem by simply re-tie-ing the database when you get or drop a lock. Because of the flexibility in dropping an re-acquiring the lock in the middle of a session, this can be massaged into a system that will work with long updates and/or reads if the application follows the hints in the POD documentation. DB_File::Lock-- extremely lightweight DB_File wrapper that simply flocks a lockfile before tie-ing the database and drops the lock after the untie. Allows one to use the same lockfile for multiple databases to avoid deadlock problems, if desired. Use for databases where updates are reads are quick and simple flock locking semantics are enough. This posted for reference by request of Stas. :-) - David Harris Principal Engineer, DRH Internet Services
[JOB] ground-floor opportunity with ownership stake
We have an outstanding ground-floor opportunity for the right person. Must have strong technical skills in mod_perl application development and some or all of the following: database development, c language, linux/unix system administration. Must also have the desire and ability to invest substantial "sweat equity" in exchange for a good ownership stake in a fast-growing web-hosting business. If you are the right person, you will become a partner in our business, and will end up owning a share which, according to our projections, will be worth $1.5 million within three years. The price of this ownership stake is working full time without pay for the first five months. You need to be prepared to make that investment. After the first five months a competitive compensation package will kick in. Technical skills we are seeking are: - mod_perl development - database development - c language patching of open source programs - in depth troubleshooting of complicated systems - linux/unix system administration - good grasp on unix fundamentals - good grasp on unix security precautions Responsibilities would include: - continuing mod_perl development on web control panel - helping create accounting database and integrating it into existing instant account setup system - administration of existing servers - limited, simple end user customer support If you wish to explore this opportunity in confidence, contact David Harris at [EMAIL PROTECTED] - David Harris Principal Engineer, DRH Internet Services
RE: mod_perl Programmers demand is going up...
Jason Bodnar wrote: > Unfortunately, another big part of the problem is that many so-called 'forward > thinking' companies aren't willing to hire tele-commuters, even for contract > positions. I'm interested in doing some moonlight consultant work but there > isn't alot of mod_perl activity going on in Austin, Texas. Do other people agree with this? I'm going to be putting my resume out in a week possibly looking for a short term (few weeks to a month or so) consulting jig. How open will people be to having me consult on a tele-commuting basis? (Or I could commute to DC/Nortern-VA/MD.) And how much short-term contract work is there available? - David Harris Principal Engineer, DRH Internet Services
RE: mod_perl rpm ready for testing
> > I'm probably going to make a version for myself that has EAPI integrated, so > > that it will mesh properly with my apache-mod_perl RPM that I've got. I doubt > > that I'll end up distributing that version because of crypto hook export > > problems. > > Maybe we could look at the .spec file? The source RPM is available from the same directory, so you can just download that and install it on your system. It's particularly insightful if you do a diff against my apache-modperl.spec file and the red hat apache.spec file. If you don't want to install the source RPM, just run a "rpm2cpio whatever.src.rpm | cpio -i " to get at the archived files. - David Harris Principal Engineer, DRH Internet Services
RE: mod_perl rpm ready for testing
Miguel A.L. Paraz wrote: > On Wed, Oct 13, 1999 at 04:24:55PM -0400, David Harris wrote: > Thanks a lot for solving my long-standing problem of building a static > mod_perl system that allows loading of modules and is compatible with the > Red Hat RPM. I initially didn't bump into problems when doing simple > stuff and HTML::EmbPerl but when I started working with the WING web e-mail > system I had all sorts of problems. Does this mean that you've gotten my RPM to work for you in places where the Red Hat mod_perl RPM did not? If so, good, and I'll continue with releasing this stuff up on the web. Expect it to be done sometime later today. > Sometime in the future I would need Apache-SSL with mod_perl, so I guess > I could use your work as a starting point. I'm probably going to make a version for myself that has EAPI integrated, so that it will mesh properly with my apache-mod_perl RPM that I've got. I doubt that I'll end up distributing that version because of crypto hook export problems. - David Harris Principal Engineer, DRH Internet Services
mod_perl rpm ready for testing
Hi, I've just completed the first copy of the mod_perl RPM that I said I was going to create about a week ago. Sorry this took so long, I had a whole bunch of things that needed to be done first. The files are up at: http://www.davideous.com/modperlrpm/distrib/ Features of this RPM: - installs mod_perl as an "add in" to the red hat apache package, but does not install mod_perl as a DSO and all the problems that brings (more details in the appended README.RPM file) - includes the four header files required for building libapreq (libapreq package will follow shortly) - distributes plain text forms of the pod documentation files that come with mod_perl - checks the module magic number on the existing apache package to see if things are compatible I've appended a copy of the README.RPM file distributed with this package which explains how I went about packing this stuff to make it work like a "add in" but not make it a DSO. I'd appreciate it if some people could give this package a whirl using some of the advanced mod_perl features that don't work in the DSO. This would really help my confidence that this approach really works. Also, if somebody (perhaps Geoffrey S Young who was researching this, I think) has a listing of the features that are broken in the DSO form, please send to the list - I'd like to include it in the package documentation, and some people might be able to test that stuff. I know that this is not the latest copy of mod_perl or Apache. I just tossed this out. When I get some positive feedback, I'll look at creating an Apache 1.3.9 version (for the red hat 6.1 folks) and try to get the latest mod_perl version running for Apache 1.3.6. - David Harris Principal Engineer, DRH Internet Services = README.RPM notes on this un-conventional RPM packaging of mod_perl by David Harris <[EMAIL PROTECTED]> on Oct 13, 1999 This package will install the mod_perl library files on your machine along with the following two Apache files: /usr/lib/apache/mod_include_modperl.so /usr/sbin/httpd_modperl This package does not install a complete apache subtree built with mod_perl, but rather just the two above files that are different for mod_perl. This conceptually thinks of mod_perl as a kind of an "add on" that we would like to add to the regular apache tree. However, we are prevented from distributing mod_perl as an actual DSO, because it is not recommended by the mod_perl developers and various features must be turned off. So, instead, we distribute a httpd binary with mod_perl statically linked (httpd_modperl) and the special modified mod_include.so required for this binary (mod_include_modperl.so). You can use the exact same configuration files and other DSO modules, but you just "enable" the mod_perl "add on" by following the below directions. To enable mod_perl, do the following: (1) Configure /etc/rc.d/init.d/httpd to run httpd_modperl instead of httpd by chaning the "daemon" command line. (2) Replace mod_include.so with mod_include_modperl.so in the module loading section of /etc/httpd/conf/httpd.conf (3) Uncomment the "AddModule mod_perl.c" line in /etc/httpd/conf/httpd.conf Or run the following command: (and the other version to disable mod_perl) /usr/sbin/modperl-enable on /usr/sbin/modperl-enable off
RE: ignored
Miguel A.L. Paraz wrote: > I'm working with the WING web e-mail system, and have it running on two > systems. Now I'm working on it on a third system with the same configuration > (Apache/1.3.9 mod_perl/1.21), but this bit of config stopped working: > > PerlModule Wing::Balance > > > SetHandler perl-script > PerlHandler Wing::Balance > > > This is inside a VirtualHost. Instead of calling the Module when accessing /, > the DocumentRoot is loaded. > > Any clues on how to find out why this is happening? Try placing a "deny from all" directive in that ... section to see if the problem is that the location is not matching or that mod_perl is not picking up the request. If it's the location section that does not match, try changing it to just to see what happens. Also, posting your full configuration files somewhere on the web and then linking to them would help. - David Harris Principal Engineer, DRH Internet Services
mod_perl package... what apache version
Okay, this mod_perl package that I'm putting together is going to require that the user have a stock RedHat layout Apache package already installed. My package will then just install its own statically linked Apacke+mod_perl binary and the mod_perl Perl libraries while sharing most of the Apache files such as DSO's and documentation. Do you think I need to support Apache 1.3.9 or 1.3.6 more badly? The question is really do I require 1.3.6 which most people probably have or 1.3.9 which is in RedHat 6.1 and people should be able to easily upgrade to. If both really need supporting I could produce packages for both. I can't produce one version that works with both 1.3.9 and 1.3.6 because the Module Magic Number changed and DSO compatibility was broken between the releases. Anyway, I should get to working on this sometime later today. - David Harris Principal Engineer, DRH Internet Services
RE: New mod_perl RPM really needed? (was: sourcegarden plug)
Stephen Peters [mailto:[EMAIL PROTECTED]] wrote: > I found one, actually. On my RH6.0 box at home, I installed an > apache+mod_perl SRPM that seemed to work fine. Mod_perl was > statically linked in, so I don't have the chaining difficulties. > Unfortunately, I had to compile from the SRPM version, since the RPM > was compiled for RH5.2, and was therefore looking under the wrong Perl > version number for Perl modules. > > If you look on any RedHat mirror which has the contrib directory, you > should be able to find an apache_mod-perl RPM and SRPM. Found it... Summary at: http://www.rpmfind.net/linux/RPM/contrib/libc6/i386/apache_modperl-1.3.6-1.19-1 .i386.html (S)RPMs: ftp://rufus.w3.org/linux/contrib/libc6/SRPMS/apache_modperl-1.3.6-1.19-1.src.rp m ftp://rufus.w3.org/linux/contrib/libc6/i386/apache_modperl-1.3.6-1.19-1.i386.rp m ftp://rufus.w3.org/linux/contrib/libc6/i386/apache_modperl-devel-1.3.6-1.19-1.i 386.rpm This looks good except for the fact that it is actually a replacement for the apache package. I want something that will install alongside the apache package and use the same DSO's and docs files, so that I can run multiple mod_perl and non-mod_perl servers on the same machine. Anyway, this package looks like a good starting point for making my own RPM. I'll keep you all updated - David Harris Principal Engineer, DRH Internet Services
RE: New mod_perl RPM really needed? (was: sourcegarden plug)
Stas Bekman wrote: > When you install gcc*.rpm, do you complain about it? mostly not. Why? > because it's something that use without special needs. It's easy to make a > mod_perl RPM to handle some basic stuff. But if you are a real user of > mod_perl you want to discover many of its not so strightforward features, > then RPM doesn't fit you and you have to roll you own build > > RedHat makes RPMs the way it find correct. If it doesn't fit your needs > make your own RPM and contribute it to both RH and us, so others will be > able to use it. It's so simple. What I really need is something that I can just install on each server and have a copy of mod_perl which will work out of the box.. I'm not going to be hacking around with the mod_perl source in the production servers. If I'm going to do that, it will be on my development box. I'm just afraid that because people have been talking about so many problems with the Red Hat RPM and it's using mod_perl as an Apache DSO which is not recommended, I'm going to run into stupid problems somewhere. > Even better give us a SRPM, the user will have to build it himself, but > once he build ot from sources, it's promised that everything would work. > All it takes is: > > rpm --rebuild somepackage.src.rpm This produces a RPM built on the user's machine in /usr/src/redhat/RPMS and the whole build tree in /usr/src/redhat/BUILD, but when using a BuildRoot (which every package I've seen does) these /usr/src/redhat/BUILD files are going to be setup to install into the buildroot of /tmp/whatever, not where you actually want them. Perhaps instruct the user to do this, if they want to run their own build of mod_perl using the RPM as a starting point: rpm -i somepackage.src.rpm edit /usr/src/redhat/SPECS/somepackage.spec to remove BuildRoot line rpm -bi /usr/src/redhat/SPECS/somepackage.spec This way the user does not get an RPM built on their system, but the build tree in /usr/src/redhat/BUILD is setup to install into their live system (and just did). > I think it would help. If you succeed to build a good SRPM for a general > purpose usage, we ether can ask RH to put it in, or can put it on > sourcegarden or perl.apache.org - it's not an issue. Thanks! How about this way of thinking about creating an RPM: We think of mod_perl as a special DSO that we are not really allowed to use as a DSO, so we really want to just provide another Apache binary that has mod_perl built in.. So, when you want to enable mod_perl instead if inserting a "LoadModule" line in httpd.conf, you just change from "httpd" to "httpd-perl" in the apachectl script. The advantage is that this one binary can share the existing Apache documentation and DSO's from the RedHat Apache RPM. We just need to install what's different for the mod_perl binary, such as all of the Perl modules and the mod_perl specific documentation. Of course, if I distribute the RPM, the SRPM will come along too. - David Harris Principal Engineer, DRH Internet Services
New mod_perl RPM really needed? (was: sourcegarden plug)
Young, Geoffrey S wrote: > Thus, it might be worth mentioning that RPMs are a _bad_ idea for > those just getting into mod_perl. That is, unless others have been more > successful that I... I've got mod_perl running just fine with my own Apache package and RedHat's mod_perl RPM. I understand that this keeps me from being able to use some stuff like request chaining, but I've not had a need for it. I've also stayed away from any mod_perl development environments (Embperl, Mason, whatver) and just wrote the handlers all myself. I'm going to package all of my work up today into RPMS and publish them out to the production servers, so I'm wondering if I should make my own mod_perl and Apache RPM or stick with what I have working. I keep hearing that RPM's and mod_perl are evil, but personally everything installed and worked without a hitch. Oh, I remember that I had some trouble compiling libapreq, but copying a few mod_perl header files into the system solved that without too much pain. A while ago in his "sourcegarden plug" thread Stas wrote: > Jim, one of the "services" we _want_ to provide at mod_perl Source Garden > (modperl.sourcegarden.org) is prebuilded mod_perl RPMs in its various > configurations and for mainly used platforms. Taken that we are only a few > folks who actually contributing to this project, this item is not on the > top of our priorities. > > I wonder if you or someone else may want to step in, and to start creating > correctly prebuilded SRPMs and RPMs, and if later feel that it's not > challenging (which I've found quite challenging, YMMV), someone else will > pick the falling flag. But it's definitely a good way to learn creating > RPMs which are very usefull, contributing back to our community, (and > fighting our mutual enemy :) I'm basically saying that I could do this and put together some mod_perl+Apache and libapreq RPM's today.. but I'm just wondering if it's really needed. - David Harris Principal Engineer, DRH Internet Services
relative redirect (was RE: Chaining and redirection)
Dirk Lutzebaeck wrote:
> ie.
>
>
> Options ExecCGI
> SetHandler perl-script
> PerlHandler Apache::OutputChain Apache::GzipChain Apache::Registry
>
>
> and /PERL/x.pl
>
> use Apache;
> use Apache::Constants qw(REDIRECT);
> $r = Apache->request;
> $r->header_out("Location" => "/y.html");
> $r->status(REDIRECT);
>
> this works.
Is it legal to issue a redirect header relative to the server base? I didn't
think you were allowed to do that, so I was using this function to get a
reference back to the specific ipaddr/port on the server:
use Socket qw();
sub self_referential_host
{
my $r = shift;
my $host = $r->header_in("Host");
if ( not defined $host ) {
my ($port, $ipaddr_bin) = Socket::unpack_sockaddr_in
$r->connection->local_addr;
my $ipaddr = Socket::inet_ntoa $ipaddr_bin;
$host = "$ipaddr" . ( $port == 80 ? "" : ":$port" );
}
return $host;
}
Can I really just do a "Location: /auth/" and have it work?
- David Harris
Principal Engineer, DRH Internet Services
