Re: stopping concurrent logins
On Fri, Apr 04, 2003 at 03:34:25PM +0200, Frank Maas wrote: > You can set a session (see Apache::Session and related modules) that > can use the uri as session-container as well (eg > http://www.example.com/9o79876a98d7fa98d7/path/to/doc). The session > part (9o79876a98d7fa98d7) can be stored in a database. > > Success. Technically, that doesn't solve the problem either. Since the session information is in the URL, there is nothing to stop the user from IM that URL to their friend, who then has total access, without a cookie, just by using the current users session. I must not fully understand the taboo against using cookies. It's rare that an online application, e-commerce related or otherwise, works without cookies. If you're doing anything more than browsing static data, you'll quickly become fustrated at the lack of support for non-cookie-enabled browers. Anytime web based authentication is used, people are going to need cookies. Maintaining state and security within a stateless medium is almost impossible without cookies, in my experience. I've heard of, but never seen, authentication using java or flash that maintains a persistent connection in the background using sockets to the web server. This basically "registers" the user's IP address with the system, and all users with that IP are considered authenticated. I'm sure more complicated solutions exist. Sorry I don't have a solution to your problem. But perhaps the problem is the requirement to not use cookies... :) Good luck, Rob > > --Frank -- Robert Landrum Systems Programmer
Re: Content-Type not working on MSIE
On Thu, Mar 20, 2003 at 02:04:55PM -0800, Andrew Ho wrote: > Hello, > > AF>As an aside, if anyone on the list knows of ways to defang this really > AF>annoying IE behavior, I would be most interested in knowing about it > > Two (and probably more) ways to do it. This is probably in a FAQ > somewhere as it is a common problem. > > (1) Fool IE by snarfing another extension in the URL. For example, instead > of requesting http://www.example.com/foo.pl, tack on a dummy parameter and > request http://www.example.com/foo.pl?filename=foo.txt. > I don't think this works with everything. > (2) Send a Content-Disposition header. This is a MIME header and not in > the HTTP spec but IE respects it: > > Content-Disposition: inline; filename=foo.txt > I know that this doesn't work for all browsers. Our solution was to do a simple path info that was basically irrelevent. http://foo.bar.com/path/to/fetchfile.pl/foobar.pdf Every browser we tested it on tried to save the file as foobar.pdf. Rob
[OT] Re: Hiding the .pl
You might want to consider downloading the 1.3.23 source for mod_speling and using diff to see if they changed something. It might be something simple that can be changed and patched. You also might be able to use the mod_speling from 1.3.23 in 1.3.27 without any problem. Given the relative simplicity of redirecting, I have to imagine that the apache API didn't change very much in that regard. Rob On Wed, Mar 19, 2003 at 02:04:31PM -0500, KIVES,BRUCE (HP-USA,ex1) wrote: > > I have recently updated from Apache 1.3.23? to 1.3.27. Things are behaving > differently, and I think the problem lies with mod_speling. Previously, if > there was only one possible choice for a misspelled URL, it would just > redirect it without asking. Now it asks every time. > > I used this feature to hide the fact that I was using a Perl program. For > example: http://url/calendar/month/042003.htm called month.pl with > PATH_INFO=/042003.htm, but to the browser it looked like there was a > directory /month with a pile of static pages. I have several file.htm.pl > that are called with file.htm and it worked fine. > > Was there a change in mod_speling, or has something else happened? I don't > think it is in the configuration. I copied over the old httpd.conf and after > one or two minor changes, restarted Apache with the same problem. > > Is there another way of hiding the fact that I'm using a Perl program? If I > rename the program from month.pl to month, it displays the program instead > of executing it. The permissions are 755. I don't want to copy everything > into /cgi-bin, because I do have some static .html in the same directory, > which it then tries to execute. > > Any other ideas on how to hide the .pl ? > > OS revision: > HP-UX 11.11 > >From the error log: > HP Apache-based Web Server/1.3.27 (Unix) ApacheJServ/1.1.1 PHP/4.2.2 > mod_perl/1.27 configured > -- resuming normal operations > > Thanks in advance, > Bruce Kives -- Robert Landrum Systems Programmer
Re: [OT] MLDBM Size Limit??
On Tue, Jan 21, 2003 at 02:37:02PM +, Ged Haywood wrote: > Hi there, > > On Tue, 21 Jan 2003, Jim Morrison [Mailinglists] wrote: > > > Sorry this is a little off topic... Is there a size limit on DBM's? (Or > > Linux files for that matter.. ) > [snip] > > Thing is I'm getting a "write error" and it seems to always happen when > > the DBM gets to 2.0Gb .. > [snip] > > Linux hope 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 unknown > Actually, I finally had to upgrade to 2.4.17 (or .19) and custom compile the kernel to get this to work. I had a similar problem with mysql files being 12GB. I forget exactly the steps, but if you hunt around in the kernel configurator I'm sure it'll show up... :) Rob
Re: OSCON ideas - missing proceedings
One of the other things I disliked about the last OSCON was the missing Perl Conference Proceedings. I still have very fond memories of reading about Damians very sick, very twisted, Coy.pm in the 1999 Perl Conference Proceedings. Did anyone else notice that they weren't made available at the last OSCON? Any chance we could convince O'Reilly to bring that back? Rob
Re: OSCON ideas
On Wed, Jan 08, 2003 at 04:14:47PM -0500, Perrin Harkins wrote: > > What do you guys think? > As an OSCON attendee for the past few years, I've found only a few talks that really were helpful. One thing that I would love to see are practical implementations of perl applications. For example, we use Mason coupled to a back end API that connects directly to postgres. The API/Mason stuff works like a MVC. It's all pretty standard, and works very well. I'm sure other people have much more interesting examples. This kind of talk would be directed at people who really grasp all the concepts of perl already, and are looking for something to spark their intrest again. Almost like the perl lightning talks, but more focused on application models. Just some thoughts... Rob
Re: Fw: OT - Santa uses PERL
On Fri, Dec 20, 2002 at 10:35:18AM -0800, Bill Moseley wrote: > That sounds a lot like Perrin's story. Didn't he save Christmas one > year? > Indeed he did... and at etoys, no less... Perhaps Perrin is an elf. :) Rob
Re: RFC: Template::YetAnother
I've said it before... :)
http://mathforum.org/epigone/modperl/zhixswahar/v04210105b76eecf6c2be@%5b192.168.1.3%5d
Rob
On Sat, Nov 16, 2002 at 10:33:44PM +0100, Thomas Klausner wrote:
> Hi!
>
> On Sat, Nov 16, 2002 at 03:31:39PM -0500, Perrin Harkins wrote:
> > >I also posted this on perlmonks:
> > >http://www.perlmonks.org/index.pl?node_id=213300
> >
> > Ovid on Perlmonks already said some of the things I would have said
> > about needing a presentation language. For a templating system to be
> > useful, it has to be able to deal with loops and conditionals. Your
> > system pushes those into the Perl code, splitting the presentation
> > control into multiple places. This fails one of my major goals: the
> > template coders should be able to change the presentation without help
> > from a Perl coder. What if they decide they don't want to loop through
> > the links, but rather just print a message saying there are some? What
> > if they only want to show the first two? What if they want to display a
> > list with commas between the elements where they didn't use a separator
> > before? A mature templating system can handle all of these issues
> > without changing the main Perl module code.
>
> That's a very good point I didn't really think about. I was thinking
> of templates as DUMB frontends that should just display
> data. Period.
>
> Thinking of them as tools that handle presentation logic (as Ovid
> pointed out) seems to make more sense.
>
> It does pay of to write RFCs before starting to code...
>
> > >Because IMO, the main reason for using templates is to seperate code
> > >from markup.
> >
> > It sounds to me like you want one of the HTML attribute ones, like Petal
> > or HTML::Seamstress. What was wrong with those?
>
> One problem I see with HTML::Seamstress is that it uses the HTML
> attributes 'class' and 'id' for templating info. But those attributes
> are used by CSS and JavaScript and might conflict somehow. I do not
> know if you can change the behaviour of HTML::Seamstress to use other
> attributes, though. But this stopped my from looking further.
>
> And I didn't look at Petal. For now.
>
> > >There is one module, CGI::FastTemplate, that does seperate code from
> > >markup completly. But the way different templates are strung together
> > >seems rather comlicated to me.
> >
> > It's not complicated, but it is somewhat confusing the first time you
> > look at it. I don't find your approach much easier though.
>
> Well, I found mine easier :-)
> (But I guess this is the reason for the Template Flood on CPAN -
> everbody finds his own solution easier...)
>
> > Isn't your fill method just doing a sort of multi-level join here? All
> > of the data is passed in already, so there is no reason to delay
> > evaluation of the templates.
>
> The main reason for doing this was to simplify testing. I planned to
> just test the plain data structures, that should be free of HTML at
> this time (before the fill). This (testing) was in fact the reason I
> started thinking about this proposal in the first place.
>
> > More importantly, your use of AUTOLOAD to treat method calls as file
> > names looks neat, but is not a good approach. It's limiting (all
> > templates in one directory!) and has potential security issues with
> > namespace clashes. These are all just the same method call with a
> > single argument changed, so why not write them that way?
>
> I planned to handle those namespace and filename issues.
>
> > ..
> > force you to use them. They are flexible modules. I think you should
> > look at them more closely before you go off on your own.
>
> That's what I'll do. Thanks for the excellent feedback.
>
> --
> #!/usr/bin/perlhttp://domm.zsi.at
> for(ref(bless[],just'another'perl'hacker)){s-:+-$"-g&&print$_.$/}
Re: how to detect a broken connection using mod_proxy
On Mon, Nov 11, 2002 at 11:51:12PM +0800, Stas Bekman wrote: > > heavy sql stm's. after each one of them i would like to check if the > > client is still there so that i will proceed to the next one or just > > return OK and forget about the request). > > As far as I know you can't do that, since mod_proxy doesn't cooperate > with the backend. > > Anybody knows of similar to mod_proxy modules that do play nicely with > the backend regarding aborted connections? > I've never used it, but wasn't mod_backhand supposed to do this? Rob -- Robert Landrum Systems Programmer
Re: Novice - How would I add a hidden form field to a LWP::UserAgent call?
On Thu, Oct 31, 2002 at 10:28:32AM -0500, Chris Pizzo wrote:
> Hi,
> I'm trying to post data to a server that requires a hidden form field.
>
> This is what I'm doing:
> my $content = "info=somedata";
> my $rec_len = length($content);
> my $send_url = new URI::URL($url);
> my $hdrsend = new HTTP::Headers('Content-length' => $rec_len);
> $hdrsend->header('Content-type' => 'text/html');
>
> my $reqest = new HTTP::Request('POST', $send_url, $hdrs, $content);
> my $uasend = new LWP::UserAgent;
>
> my $resp = $uasend-> request($reqest);
>
I always just did
$req = new HTTP::Request('POST',"http://foo.bar.com/path/";);
$req->content("info=somedata");
$ua = new LWP::UserAgent;
$res = $ua->request($req);
print $res->as_string;
Good luck,
Rob
>
> The response I get back is:
> Exception encountered.Form post has no value for key "info".
> Form values are: {}
>
> If I create an HTML doc with a form it finds the data. Is there something
> special I need to do to get a hidden form field?
>
> Thanks,
> Chris
>
>
--
Robert Landrum
Systems Programmer
Re: [OT] - Mailing List Servers/mods .. etc
I did just this. Unfortunatly, sendmail proved to be too slow, both in command line piping (i.e. open(PROG,"| sendmail ");), and via socket connection to port 25 to be a viable solution for the volume of mail we sent. Last I checked, the code I wrote interfaced with Lyris, which was performing ok. When I left the project, they were looking into alternative approaches to sending email. Note that this was all legitimate (double opt-in) bulk email. I have some code which is public. Go grab SMTP-* from http://bigrob.ath.cx/dist/. These are a little better than the currently existing Net:: modules. I do a bit more logging and error checking. At some point, those should be on CPAN if I can get the namespace approved. :) Good luck, Rob On Thu, Sep 26, 2002 at 02:44:12PM +0100, Jim Morrison [Mailinglists] wrote: > Sorry.. > This is completely off topic.. but I have a question you guys might help > me with.. > > > I'm writing then next part of a big modperl project I'm doing.. This bit > could be loosely called a mailing-list-server.. > > The listserver is going to handle out-going (only'ish) opt-in mailing > lists. The opting-in bit is all bound into the rest of the project, as > is the construction of the outgoing email, and the list management... > > I'm wondering if there is any point in looking for a piece of third > party software/module etc, that will handle the sending of the mail or > should I work directly with sendmail? (Is sendmail the best mailserver > for this kind of thing?) > > I'd be happy to write something along the line of formail.pl on my own, > so I kinda know what I'm doing, but I'm gonna have to take things like > "Return to sender" errors and such into account.. > > > > My question I guess is: > - Is it ok to send 100's or 1000's of mails to sendmail in one go, or > is there a better way of doing bulk mail? > - Are there any mods to help with dealing with returned mail etc..? > - Is there a good list of people doing this sort of thing? (Or do you > mind the thread being a little off-topic!) > > > I don't think I'm trying to reinvent the wheel.. Just that I think there > is so much of my own coding involved, I'm not sure if I'm going to be > able to get away with anything less than writing it from scratch.. > > Would be greatful for any advice, > > Kindest, > Jimbo > > > > > > Jim Morrison > _ > Technology & Development Partner > Isotope LLP > 9, 2 Laura Place > Bath, BA2 4BH > UK > +44 (0) 1225 446170 > +44 (0) 7940 937822 > www.mediaisotope.com
Re: help with a simple redirect
On Wed, Sep 18, 2002 at 07:43:43PM +0530, Sylbert L wrote:
> Hi ..
>
> I'm trying to do a simple redirect using mod_perl 2.0, Apache 2.0.40 ..
> just doesn't seem to work.
>
> This is my code, in a file called MySocket.pm
>
> package Apache::MySocket;
>
> use strict;
> use Apache::RequestRec ();
> use Apache::compat();
> use Apache::Const -compile => qw(OK REDIRECT);
>
> sub handler {
> my $r = shift;
> $r->header_out("/test.html");
I think you want
$r->header_out("Location" => "http://domain.com/test.html";);
> return Apache::REDIRECT;
> }
> 1;
>
> This is what i added to httpd.conf :
>
> -
>
> SetHandler modperl
> PerlResponseHandler Apache::MySocket
>
> -
>
> When I do this : http://localhost/ok/ok i want the web server to redirect
> to: http://localhost/test.html
>
> Where am i going wrong ? I'm not getting any errors .. even 'error_log ' is
> blank. Any clues ?
>
> Thanks
--
Robert Landrum
Systems Programmer
Re: [Newbie Q] Cleanest way to implement one logon per user?
On Thu, Aug 01, 2002 at 03:08:40PM -0400, Baljit Sethi wrote: > Hello. > > I am hoping someone can point me in the right direction. > > What I want to do is limit client logons to one logon per username ie while > a client has a session open, he/she cannot logon to the website from another > terminal. The problem isn't determining when they've logged in, but determining when they've logged out. While it may be possible to write a record to the db that contains username, password, and IP address, it does not gaurentee that the user's ip address will not change mid session. (cable modem disconnect and reconnects with new ip, transparent to the user.) The short answer is, you can't. The long answer is that you can, but it takes way more work than it's worth. The only way I've seen is to set a cookie (encrypted) on the client's machine and flag the user as logged in. If the user tries to log in again (from anywhere), it rejects it. Only if the original client connects and clicks logout (and the cookie still exists) does it actually remove the flag (and the cookie). The drawback here is that if any user ever deletes their cookies before logging out, they're screwed, and will call asking you to fix it. Good luck, Rob
Re: [Newbie Q] Running into strange 420-character POST limit.
On Thu, Aug 01, 2002 at 03:51:09AM -0400, sully wrote: > Answer: > You tell me! :) A problem with Apache? A problem with mod_perl? A problem with >IE/Mozilla? Do I need to be posting large forms such as this using >multipart/form-data with mod_perl? Please. Help. > Have you tried just regular get? It might give you some clue as to what's happening to the data. I've never had to provide a content type when submitting form, except on those forms where I upload files. Also, check that you're not reading the post content more than once. Sometimes on small requests you can read the post content twice, but on larger requests, it'll fail. I remember having this problem 5 years ago, under IIS, so it may not apply. You can also try running tcpdump or other packet sniffing software to see what's really being transmitted between client and server. Good luck, Rob
Re: PerlAccessHandler
On Fri, Jul 26, 2002 at 04:11:29PM -0700, Rasoul Hajikhani wrote:
> Folks,
> My PerlAccessHandler is being executed twice per each request. Is this a
> normal behavior for an access handler?
> Here is my .conf entry
>
> SetHandler perl-script
> # run is a wrapper for my handler
> # all common methods which many of my handlers
> # use are stored in the super class of myHandler
> # in which run is a part of.
> # Also wraps myHandler in a try {} catch { ...
> # block.
> PerlHandler myHandler->run
> PerlAccessHandler myAccess
> .
> .
> .
>
>
Hmm... Is the PerlAccessHandler directive defined anywhere else? Perhaps in
a .htaccess file in the doc root?
> The access handler's job is to check for cookies and last login time.
> There are no fancy codes there... However, on every request, the handler
> is invoked twice. Can someone make a suggestion as to why this is
> happening?
Maybe you're trying to pull some sort of image from a local path? Something
like has bitten me before. Javascript is another
one that bites me often. Mouse over code can be bad too... They are often
coded as relative paths.
Good luck,
Rob
Re: Optional HTTP Authentication ?
On Mon, Jul 01, 2002 at 10:30:36AM +0100, Jean-Michel Hiver wrote:
> > > browser sent the credentials, or leave $ENV{REMOTE_USER} undef
> > > otherwise, without sending a 401 back.
> >
> > I didn't think a browser would send authentication unless the server
> > requested it for an authentication domain. How are you going to
> > get some people to send the credentials and some not unless you
> > use different URLs so the server knows when to request them?
>
> The idea is that on a "location" which requires authentication I'll
> redirect the user to a /login.html, or maybe a /?login=1 which will do
> the following:
Umm... Perhaps I don't understand the significance of the login.html. Under
HTTP auth, if a page is protected via .htaccess then auth is immediatly
requested, and no redirect is possible.
More important is the fact that if a page does not require authentication,
the users login and password will not be sent. So a page like index.html that
is not normally authenticated will not receive the username, and no
Admin this page will be possible.
I'm not 100% sure this is possible without the use of cookies. I'm pretty sure
you could write some custom handler to handle the auth, but without a cookie
to note which users have authenticated, you might be out of luck.
Good luck,
Rob
Re: RewriteRule and AccelPass conflict
On Mon, Jun 24, 2002 at 05:37:51PM -0400, Philip Mak wrote:
> I'm trying to add a RewriteRule, but it's not working:
>
> RewriteEngine on
> RewriteCond %{HTTP_HOST} !^www.animewallpapers.com(:80)?$
> RewriteCond %{HTTP_HOST} !^64.246.28.97(:80)?$
> RewriteRule ^/(.*) http://www.animewallpapers.com/$1 [L,R]
>
> I want to make it so that if someone accesses that website via any
> hostname other than www.animewallpapers.com or 64.246.28.97, then it
> will redirect them to http://www.animewallpapers.com/. I copied those
> rules exactly from another httpd.conf where it works.
>
> However, the directives were being ignored. I realized the problem is
> probably because of this line:
>
> AccelPass / http://127.0.0.1:8010/
>
I would think that you would need something like the following.
SetHandler rewrite accel
# rewrite rules and accel rules
Or something like that... Your goal is to stack these handlers, so that
rewrite happens first and accel second.
I've never tried this, but it might work
Rob
--
Robert Landrum
Systems Programmer
Re: Preserving POST data on external redirect?
A few things to note here...
You cannot post to a remote server in this fashion. You can take a POST
request to your server and convert it to a GET request to another server,
which may not be what you want.
To take POST content and POST it to another server you must proxy the request.
By proxy, I mean using LWP to make the request to the remote server via POST,
and delivering that returned content back to the user.
That's the easy part. Now you'll have to fix all the relative URLs within that
document so that they point to the remote server rather than to your server,
which is further complicated by things like CSS and Javascript.
Look into libwww-perl (LWP) and HTML::TreeBuilder (for fixing the links). I'm
sure that there is stuff in this lists' archives which go into more detail on
both of those...
Hope that helps,
Rob
On Mon, Jun 24, 2002 at 12:03:50PM -0400, Ken Y. Clark wrote:
> On Mon, 24 Jun 2002, Kirk Bowe wrote:
>
> > Date: Mon, 24 Jun 2002 16:22:42 +0100 (BST)
> > From: Kirk Bowe <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: Preserving POST data on external redirect?
> >
> >
> >
> > Hi all, my content handler does some work with POSTed data, and at the
> > end
> > wants to redirect to a totally unrelated server, preserving the POST data
> > that the client originally sent, so that the unrelated server can do its
> > own further processing with its own mod_perl, cgi, or whatever.
> >
> > I can't get it to work, as I think I'm getting confused by some
> > pre-Apache::Request hints that I've seen for this. This is the mess I've
> > got so far (condensed):
> >
> > sub handler
> > {
> > my $r = Apache::Request->new(shift);
> >
> > ... some calls to other subs here to do work ...
> >
> > $r->method("POST");
> > $r->method_number(M_POST);
> > $r->headers_in->unset("Content-length");
> > $r->args($content);
> > $r->header_out('Location' => "http://j.random.server.com/foo.cgi";);
> > $r->status(REDIRECT);
> > $r->send_http_header;
> >
> > return REDIRECT;
> > }
> >
> > It redirects, but doesn't pass the POST data. I thought it may have been
> > due to the original post data being deleted because I use it, so I tried
> > using Request->instance instead of Request->new, but that made no
> > difference either. Is it actually possible to do it if I'm using the
> > Request object?
> >
> > Cheers
>
> I think this is what you want:
>
>
>http://theoryx5.uwinnipeg.ca/cgi-bin/guide-filter?page=snippets/Redirect_a_POST_Request_Forward.html;query=GET%20POST;match=and;where=all;stem=no
>
> ky
Re: Setting the Content-Type for displaying a gif
On Wed, Jun 05, 2002 at 04:38:26PM +0200, [EMAIL PROTECTED] wrote:
> Hello,
>
> I have a problem with setting the correct content-type under mod_perl
> with mason. I use mason with the mod_perl args_method.
> I want to get a .gif out of a database and print it
> in a window, but all i get is binary junk. I tried to set the correct
> content-type but when i look at the page source i can't see it.
>
> Here the relevant extract from my source:
>
> my $sth = $db->prepare("select attachment from table");
> $sth->execute();
> # following three lines should set content-type
> #$r->header_out('Content-Type' => 'image/gif');
> #$r->headers_out->add('Content-Type' => 'image/gif');
> $r->content_type("image/gif");
> my ($att) = $sth->fetchrow_array();
> $m->out($att);
>
You're real close here
$r->content_type("image/gif");
$r->send_http_header;
$r->print($att);
$m->abort(200);
> What am i doing wrong?
>
You actually need to bypass mason for this. It's unfortunate that mason
doesn't have some better image content type recoginition and do the right
thing (hint, hint :).
Rob
Re: Apache::File correction
At 1:44 PM -0700 4/10/02, Rasoul Hajikhani wrote:
>Folks,
>The Apache::File man pages indicate that
>
>($name,$fh) = Apache::File->tmpfile;
>
>returns a fh ready to write to. So far so good.
>
>In case of wanting to read from it, here is what I do:
>
># Is this necessary?
>$fh->close() or die "Could not close $name: $!\n";
>
>$fh->open("<$name");
>local $/= undef;
>$output = <$fh>;
>warn "$output\n";
>$fh->close() or die "Could not close $name: $!\n";
To me it appears that you have not written anything to your tmp
file... Which would explain the empty $output.
Usually temp file creators open in read/write mode.
So if you say something like
($name,$fh) = Apache::File->tmpfile;
print $fh "Hello World";
seek($fh,0,0);
my $line = <$fh>;
print $line;
It should print "Hello World";
Rob
--
When I used a Mac, they laughed because I had no command prompt. When
I used Linux, they laughed because I had no GUI.
[JOB] mod_perl/DBI programmer in Fairfax, VA
Capitol Advantage Fairfax, VA, USA Description: Online Congressional Directory publisher is looking for a lead programmer (or programmers) to maintain our existing codebase (written in mod_perl) and develop new additional components for the system. Skills Required: Perl, mod_perl, Apache, Linux, DBI. Additional Desired Skills: Oracle, Solaris, Mysql, SMTP protocol familiarity, socket programming, process management (fork), juggling. If interested, please contact: Bob Hansan [EMAIL PROTECTED] 2731-A Prosperity Ave Fairfax VA 22031 P: 703-289-4670 F: 703-289-4678
Re: PDF generation
At 3:43 PM -0500 4/3/02, Bill McCabe wrote: >Hi All > >I have a large number of mod_perl modules that connect to various >databases and >generate workflow performance reports for my organization. I give the users 3 >output options: HTML, Excel (Spreadsheet::WriteExcel), and PDF. For PDF output >I've been using PDF::Create, which has been at version .01 since 1999. It has >worked flawlessly for my purposes for a couple of years, but is very >limited. In >fine form-follows-function fashion, the end users would now like the >PDF output >gussied up with graphics, etc. Does anyone have any strong (positive or >negative) recommendations for which module(s) I should migrate to? Actually, I used PDF::API2. I've used it for graphics and others and have contributed patches to the source (which may or may not have been included, but which aren't critical for general use). The only downside is that it is poorly documented (in my opinion), but determination overruled and I've used it quite for all types of applications (including dynamic fill-out-and-download applications). The speed isn't great, but if it's a low traffic application, it shouldn't be a problem. Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: Permission conflict between mod_cgi and mod_perl
At 3:17 PM -0600 3/25/02, James G Smith wrote: > >And the sky isn't blue, but the results are the same. > >mod_perl can't run scripts. > >Scripts can be run from mod_perl. > >More than that, set-uid scripts can be run from mod_perl and offer >one of the better ways of doing things that require root privileges. Oh how I hate to interrupt a good flame war, especially one that Randal is involved in, but wouldn't it be possible to run apache (with mod perl) as set-uid but listening only on 127.0.0.1:81. They just establish a proxy connection to the backend setuid apache? Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: Be carefull with apache 1.3.24
At 11:14 AM -0500 3/25/02, John Siracusa wrote: >Does anyone know how I can put my ProxyIOBufferSize config line in a >conditional that'll keep it from blowing up if I'm using a version of apache >earlier than 1.3.24? > >-John In /path/to/apache1.3.24/bin/apachectl add a -DAPACHE_1_3_24 to the httpd command. In your httpd.conf add ProxyIOBufferSize 10 I think that should work Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: Can't open perl script " -spi.bak"
At 3:00 AM +0800 3/23/02, Stas Bekman wrote:
>On Fri, 22 Mar 2002, Pete Kelly wrote:
>
>> I am attempting to build mod_perl on NT. I
>> successfully built Apache. I have ActiveState 5.6
>> (Perl v5.6.1) installed. I also have MS Visual Studio
>> 6.0 installed.
>>
>> I downloaded mod_perl-1.26.tar.gz from
>> http://perl.apache.org/dist
>>
>> After unzipping the files I get the get the following
>> error:
>>
>> C:\mod_perl-1.26>perl Makefile.PL
>> Can't open perl script " -spi.bak ": No such file or
>> directory
>> C:\Perl\bin\perl.exe -spi.bak -e "s/sub
>> mod_perl::hooks.*/sub mod_perl::hook
>> s { qw() }/" lib/mod_perl_hooks.pm failed
>>
>> Any suggestions?
>
>That's is very weird, because this code doesn't seem to work:
>
>perl -e 'system("perl", " -e1") == 0 or die "oops"'
Actually, that's not all that weird. Most shells take care of
stripping out garbage before setting the argument list. Since
system(LIST) doesn't use the shell, it's passing perl the literal "
-e1" which perl won't recognize as a command line option (and
correctly so in my opinion).
Rob
--
When I used a Mac, they laughed because I had no command prompt. When
I used Linux, they laughed because I had no GUI.
Re: Off topic question & a little worried
At 4:58 PM -0500 3/21/02, darren chamberlain wrote: >Another alternative is to replace it with something that appears >to do the same thing, but actually logs a ton of stuff from the >requestor. Unless the entire site has already been backdoored. If that is the case, then this would serve no purpose, as the intruder could just come in via the backdoor. Any time a security breach takes place, the first action should always be to take the box offline and access the extent of the breach (multiple machines may be effected), backup the disk(s), and reformat. Finally, restore only the trusted files (and only after reviewing them for backdoors). It's the only way to be sure that you've eliminated the problem. Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: Permission conflict between mod_cgi and mod_perl
At 3:42 PM -0500 3/18/02, [EMAIL PROTECTED] wrote: >In a message dated 18-Mar-02 7:36:55 PM GMT Standard Time, >[EMAIL PROTECTED] writes: > >>You may want to look into useradd and /etc/skel on a Linux system. It >> has everything you are trying to accomplish handled automatically >> by using the standard Linux user creation techniques. No need to >> re-implement the wheel. :) >> > > >That's just it ... we didn't want to have to create whole new user >accounts for everybody. Just a small directory of files for a demo >of our web-app. > >I'd be happy if all the apps weren't apache:apache ... but I was >thinking there had to be a better solution than `chown nobody:nobody >$directory -R` (just an example !!) To change default file permissions of newly created files perldoc -f umask To change ownership of a file without a fork* perldoc -f chown To change permissions of a file without a fork* perldoc -f chmod To create directories without a fork* perldoc -f mkdir * on most *nix based systems Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: File upload example
At 9:01 AM -0800 3/12/02, David Wheeler wrote:
>On Tue, 2002-03-12 at 03:57, Rich Bowen wrote:
>
>> my $form = Your::Class::form(); # Wherever you put this function
>> if (my $file = $form->{UPLOAD}) {
>> my $filename = $file->filename; # If you need the name
>
>Actually, if you want the name, it's a really good idea to just get the
>basename, since some browsers on some platforms (e.g., IE/Mac) send the
>complete path name to the file on the browser's local file system (e.g.,
>':Mac:Foo:Bar:image.jpg'). This is trickier than it sounds, because you
>have to tell basename() what platform to assume the file is from. Here's
>how I suggest doing it.
Since when? I just wrote something that did just this (in CGI), but
it only uploaded the basename. I'm using Mac OS 9, IE 5.0. That
sounds a lot like IE 3.0.
The other way to go is
$filename = $1 if($filename =~ /[\:\/\\]([^\:\/\\]+)$/);
How many people use / : or \ in their paths? Can we shoot those
people? I especially don't want people who use those characters
uploading files that might be downloaded by someone on another
platform. Just think what would happen if I downloaded Foo:Bar.txt,
as uploaded by my windows friends.
Rob
--
When I used a Mac, they laughed because I had no command prompt. When
I used Linux, they laughed because I had no GUI.
Re: Can anyone recommend a good flavour of Cookie?
At 9:28 AM + 3/7/02, Jeff wrote:
>Please forgive a mod_perl wannabie [aka woza.PHP4.user]
>
>I have googled two differing flavoured cookies in the
>mod_perl recipe library:
> Apache::Cookie
> Apache::RequestNotes
>
>and of course, there is the 'Why not hack the HTTP_COOKIE
>env all by your lonesome?' peppermint flavour too!
>
>So which is it folks? Please vote for your favourite
>flavour of cookie for poor woza.PHP4.user
>
Actually, I always roll my own... I can't stand those Apache::Cookie
and CGI::Cookie modules... they never seem to work the way I expect
them to.
Plus, decoding cookies is easy.
my %cookies = map {
s/\%([A-F0-9]{2})/chr(hex($1))/eg; split(/=/,$_,2);
} (split(/\&/,$ENV{'HTTP_COOKIE'}));
Rob
--
When I used a Mac, they laughed because I had no command prompt. When
I used Linux, they laughed because I had no GUI.
Re: Document Caching
At 12:28 PM -0800 3/6/02, Rasoul Hajikhani wrote: >Hello People, >Need your advise on how to cache a template under mod_perl... Any ideas? >Thanks in advance >-r #startup.pl open(FILE,"); close(FILE); Provided that you never change $MY::TEMPLATE, this should work fine. -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
RE: Breaks in mod_perl, works in Perl
At 1:32 PM -0700 3/5/02, Mark Hazen wrote: >I'm sorry I didn't explain an important component. Since I am dealing with >a few hundred requests per minute (this was got me onto mod_perl to begin >with), then using DBI's ability to write to a file would vastly overwhelm my >system. I don't get it You don't mind trying to create tables a few hundred times per minute, but creating a file is too much overhead? And writing to memory is going to really bog the system. Maybe you shouldn't be asking "why doesn't my capture work", but "how can I debug some production code I have"... Just a thought, Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: Breaks in mod_perl, works in Perl
At 1:14 PM -0700 3/5/02, Mark Hazen wrote:
>I am hoping there is a someone brilliant on this list that can help me. A
>little while ago, I posted to clp.perl asking how I can capture the trace
>output from DBI into a variable. Since DBI is an external process, I
>couldn't do it just by piping STDERR. Benjamin Goldberg came up with a
>module called IO::Capture (see below). It works amazingly well in standard
>Perl. Here is a sample script:
Maybe I'm just crazy but wouldn't this be simpler?
use DBI;
$dbh = DBI->connect ("DBI:mysql:test:localhost", "username", "password", {
RaiseError => 0, PrintError => 0 });
$filename = "/tmp/dbi_".$$.time().rand(1).".trace";
DBI->trace( 1, $filename );
$sth = $dbh->prepare (qq{
CREATE TABLE IF NOT EXISTS test_table
(
a CHAR(15) NOT NULL,
b INT UNSIGNED NOT NULL
)
});
$sth->execute ();
$sth->finish ();
$dbh->disconnect ();
print qq{
Output is:
};
open(FILE,$filename);
print while();
close(FILE);
The problem with the module listed is that it does some filehandle
munging on what is already a munged filehandler. Meaning, it looks
like a filehandle, but it's really just a hook into something apache
is going to use to output stuff to the error log.
Hope that helps...
Rob
--
When I used a Mac, they laughed because I had no command prompt. When
I used Linux, they laughed because I had no GUI.
Re: [OT] Apache Config Problem
At 2:22 PM -0500 2/19/02, Stephen Reppucci wrote: >So, if you virtual host was something like: > >Listen 192.168.0.100:8080 > > ServerName www.foo.com > ServerAlias foo.com > Port 80 > ... > > >Then (assuming your bigip sends requests for foo.com to >192.168.0.100:8080) generated urls will be to >'http://www.foo.com:80/' (I think the ':80' is dropped as the >default port...) > > A very important addition to this is to make sure UseCononicalName is turned on. ;-) 30 minutes of reading about mod_rewrite, 4 minutes to recompile apache, 2 minutes of coding it, 20 minutes of testing, and a 10 second fix was all it took. Doh! Thanks everyone, Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
[OT] Apache Config Problem
I'm trying to do something really simple and trying to avoid writing an Modperl handler to do it. We have a website behind a bigip running on port 8080. When someone requests a URL that doesn't end with a slash, it's redirected to http://host:8080/path/ . I tried turning off UseCononicalName, but it didn't have any effect. Any suggestions? Thanks, Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Frontier::Responder question
I recently picked up Programming web services with XML-RPC. It mentions a module that I have yet to track down. I am unable to find Frontier::Responder. O'Reilly's site mentions that Joe Johnston wrote. Joe makes it pretty clear that he want's you to use it in place of Frontier::Daemon when writing mod_perl handlers, but never gives an address of where to find it, or how to contact him for it. The Frontier modules seem to be a little old. Are there any other "newer" versions that I should be using instead. The Frontier::RPC package was last modified in 1999. Thanks, Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: [BUG] Memory Courruption (was: RE: [Q] SIGSEGV After fork())
At 11:44 AM -0600 2/15/02, Fister, Mark wrote: > > Dear mod_perl experts: >> >> Collectively, we've been at this for more than two weeks and have searched >> various mod_perl archives, all to no avail. >> >> Symptom: >> === >> SIGSEGV after fork(). Very reproducible. Memory corruption gets moved >> around if the codebase changes. > >[ SNIP ] > >The above is the key: moved around. Therefore, I need Purify or similar >tool. I'm going to have to go this route, since nobody has any ideas. >Go go gadget purchasing! :( Are you running any XS stuff created with SWIG? I had a very similar problem some time ago (RH 5.1, I think) with SWIG creating strange XS files that corrupted memory when used under mod_perl... There was no corruption when running as a perl script or cgi. I eventually scrapped SWIG (a little too complicated for what I was doing) in favor of h2xs. Just for fun, I tried using it with mod_perl and it worked perfectly. After reviewing it with my father (who's a die hard C guy), he found a potential problem with $var = undef; call_xs_sub_to_populate($var); Which might hose undef. He suggested instead $var = "\0" x SIZE_OF_POPULATED_DATA; call_xs_sub_to_populate($var); Which I never actually tried. Since I'm not a C guy, I don't really run into too many segfaults. Unfortunatly I no longer have the code I was testing this with or I'd give it another shot... Hope that helps some... Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: [OT] Moving WYPUG
At 7:44 AM -0500 2/15/02, fliptop wrote:
>
>the version of makerpm.pl you find may not work with rpm version 4.0
>or higher, this will fix that:
>
>572c572
>< } elsif ($rpm_version =~ /rpm\s+version\s+3\.+/i) {
>---
> > } elsif ($rpm_version =~ /rpm\s+version\s+3|4\.+/i) {
Actually I don't think that really "fixes" it...
That's going to search for
rpm\s+version\s+3
or
4\.+
You want
} elsif ($rpm_version =~ /rpm\s+version\s+(?:3|4)\.+/i) {
Rob
--
When I used a Mac, they laughed because I had no command prompt. When
I used Linux, they laughed because I had no GUI.
[OT] Opera Cookies
I've recently come across some interesting behavior with Opera on linux. When I set a cookie using CGI::Cookie and Set-Cookie: headers, and then perform a JavaScript redirect to another page, the cookie IS NOT SET. That doesn't mean that the Cookie: header wasn't returned from the browser, I mean the cookie doesn't even seem to be present. Opera even says that it's going to set it (after turning on "ask about cookies" pref). Taking away the JavaScript redirect fixed the missing cookie problem, but still doesn't tell me why anything JavaScript related would have an effect on an HTTP header. The javascript looks like document.location = '$url'; Has anyone had any troubles with Opera/Cookies/mod_perl? Every other browser seems to work just fine (Konqueror, Netscape, IE, Galleon). Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: DBI handle cleared whilst still active
At 4:09 PM +0100 2/8/02, [EMAIL PROTECTED] wrote:
>Hi all,
>i have just installed DBI-1.20, ApacheDBI-0.88 and DBD-Oracle-1.12 on a
>tru64 Unix 5.1a. Also installed is Oracle 8.1.7 with Oracle supplied Apache
>1.3.12 and Oracle supplied perl 5.005_03.
>After some problems i got it work together with DBD::Oracle. The problem now
>is as follows:
>I run the following script (just select the dbname and hostname from a
>function, commented out host user and password)
>
>#!/usr/bin/perl
># Perl script start ##
>$ENV{'ORACLE_HOME'}="/u01/app/oracle/product/8.1.7";
>use DBI;
>print "Content-type: text/plain\n\n";
Try the following instead...
eval {
$dbh = DBI->connect(DSN,USERNAME,PASSWORD) || die $DBI::errstr;
};
if($@) {
print "DB Connect error: $@";
exit;
}
eval {
$sth = $dbh->prepare("select fc_get_dbname from dual");
$sth->execute;
($dbname) = $sth->fetchrow_array;
$sth->finish;
};
if($@) {
print "DB Select failure: $@");
$dbh->disconnect if(defined $dbh);
exit;
}
print $dbname."\n";
$dbh->disconnect if(defined $dbh);
Rob
>$dbh = DBI->connect("dbi:Oracle:host=host;SID=sid", "usr", "pwd") || die
>$DBI::errstr;
>$stmt = $dbh->prepare("select fc_get_dbname from dual")|| die $DBI::errstr;
>$rc = $stmt->execute() || die $DBI::errstr;
>while (($dbname) = $stmt->fetchrow()) { print "$dbname\n"; }
>warn $DBI::errstr if $DBI::err;
>die "fetch error: " . $DBI::errstr if $DBI::err;
>$stmt->finish() || die "can't close cursor";
>$dbh->disconnect() || die "cant't log off Oracle";
># Perl script End ##
>
>which puts the following message:
>
>abba02.orgdv> perl test4.pl
>Content-type: text/plain
>
>DB: ENTWICKL auf Maschine: abbaentwickel.orgdv
>DBI handle cleared whilst still active during global destruction.
>DBI Handle has 1 uncleared child handles during global destruction.
>dbih_clearcom (h 0x14012c8f0, com 0x140043880):
> FLAGS 0x211: COMSET Warn AutoCommit
> TYPE 1
> PARENT undef
> KIDS 1 (0 active)
> IMP_DATA undef in 'DBD::Oracle::dr'
> thread cond var 0x140130f30, tid 65535
>
>if i run an application in Apache and call a cgi script it puts the same
>message in the error_log from apache.
>did i forget something or is it a bug which should be posted as described in
>the manuals?
>
>MfG
>Volker Winter
>plan business AG
>NDR Projekt ABBA
>email: [EMAIL PROTECTED]
--
When I used a Mac, they laughed because I had no command prompt. When
I used Linux, they laughed because I had no GUI.
Re: Indentifying dir_config's
At 1:39 PM -0800 2/1/02, [EMAIL PROTECTED] wrote:
>I'm wondering if there is a way that I can mark or remeber that
>I've seen a particular dir_config during a previous request. The
>motivation is performance related - so that I can set up for
>particular set of "PerlSetVar" values only the once. Then
>subseqeuent requests to that child will use a previously
>determined value (instanciated object).
>
>IE: in my httpd.conf I have -
>
>PerlSetVar myvalue 100
>
>
> PerlSetVar myvalue 200
>
>
>
> PerlSetVar myvalue 300
>
>
>So - request 1 - GET /test
> I check dir_config("myvalue") and setup.
> Can I mark that I was here; sorta like the equivalent of
>
> PerlSetVar myvalue 200
> PerlSetVar signature myvalue_200
>
>
I'm not sure if I understand...
I've done something in one of my modues in the past...
package MyHandler;
our $INITED = 0;
our %CONFIG = ();
sub handler {
unless($INITED) {
%CONFIG = $self->get_config($r);
$INITED = 1;
}
}
That way I only have to get_config once per forked process... This
is very useful for static (or near static) data. In this example
get_config was pulling configuration directives from an Oracle
database.
Rob
--
When I used a Mac, they laughed because I had no command prompt. When
I used Linux, they laughed because I had no GUI.
Re: New mod_perl Logo
At 4:54 PM -0500 1/30/02, [EMAIL PROTECTED] wrote: >In a message dated 30-Jan-02 6:08:29 AM GMT Standard Time, >[EMAIL PROTECTED] writes: > >>All these American-style names are verging on the racist. >> >>This is world-wide code, not f---ing American-wide code. >> > > >Don't let the crappy AOL account fool you. Nessie is about 3 hours >from here. The Yetti I believe is indiginous to Asia isn't it? > >And as for australian beasties ... I just couldn't think of any off >the top of my head ... . Uhh... Taz? Or Tazmanian Devil. Roos? KangarooSphere v5.6.0... How about we just call it AmericanHatingAussie... ;-) Rob >-Chris >[EMAIL PROTECTED] -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: is there something wrong with my http header?
>I'm trying to print a gif image to the browser, but it's appearing as >text. Here's what the output looks like (used "lynx --mime_header"): > >HTTP/1.1 200 OK >Date: Mon, 28 Jan 2002 21:58:05 GMT >Server: Apache/1.3.20 (Unix) mod_perl/1.26 >Set-Cookie: FOO=bar; domain=foo.bar; path=/ >Pragma: no-cache >Cache-control: no-cache >Connection: close >Content-Type: image/gif >Expires: Mon, 28 Jan 2002 21:58:05 GMT > >R0lGODdhOAAWAPcAVQAAqgAA/wAkAAAkVQAkqgAk/wBJAABJVQBJqgBJ/wBtAABt >VQBt >...(more data)... > Uhh... That's not gif data. gif data should start GIF89a...(more data)... Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: slow regex [BENCHMARK]
At 4:01 PM -0800 1/23/02, Paul Mineiro wrote:
>Paul Mineiro wrote:
>
>i've cleaned up the example to tighten the case:
>
>the mod perl code snippet is:
>
>---
>
> my @cg;
> open DIL, '>', "/tmp/seqdata";
> print DIL $seq;
> close DIL;
> warn "length seq = @{[length ($seq)]}";
> my $t = timeit (1, sub {
> while ($seq =~ /CG/g)
> {
> push @cg, pos ($seq);
> }
>});
> print STDERR timestr ($t), "\n";
I just ran this on my system here... It's completely unloaded (load
average: 0.11, 0.08, 0.02)
Result:
0 wallclock secs ( 0.06 usr + 0.00 sys = 0.06 CPU) @ 16.67/s (n=1)
I ran it on a file that I created with
perl -e "print 'ABCGEFSK' x 25000" > /tmp/seqdata
Which created 25000 entires into @cg.
Your system has to be swapping horribly. I bet that the ulimit for
whoever apache is running as has the memory segment set super low.
Double check everything and if that doesn't work, recompile.
Rob
--
When I used a Mac, they laughed because I had no command prompt. When
I used Linux, they laughed because I had no GUI.
Re: mod_perl installation
At 11:35 AM -0800 1/21/02, Rasoul Hajikhani wrote: >Folks, >I get this message when running Makefile.pm: > >Your Perl is configured to link against libgdbm, > but libgdbm.so was not found. > You might need to install Perl from source Actually, I just checked... I removed perl-5.6.x/ext/*_File Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: mod_perl installation
At 11:35 AM -0800 1/21/02, Rasoul Hajikhani wrote: >Folks, >I get this message when running Makefile.pm: > >Your Perl is configured to link against libgdbm, > but libgdbm.so was not found. > You might need to install Perl from source > >I have checked the /usr/lib directory for libgdbm.so and it is not >there. >Here is the result of perl -V | grep libs: > libs=-lgdbm -lm -lc > >I use SGI IRIX 6.5 I ran into this problem too... If I remember correctly, I just removed DB_File module directory from the source tree and recompiled. Of course this means that you can't use DB_File, but if you don't need it, then this should work for you. Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: [OT] Cgi permission Questions
At 12:26 PM -0700 1/21/02, Joe Bifano wrote:
>Hi all,
>
>My first time on the list. I have been looking at the archives but am not
>able to find anything on this.
>
>I have 3 web servers, 1 development/nfs server and 2 database mysql servers
>in a cluster server farm. All sites are owned by our company so nobody will
>be on the system except for me. It is behind a firewall and a load-balancer
>so it is pretty secure.
>
>I have several domains set up on the site called test.company.com,
>demo.company.com, stage.company.com and company.com. company.com is only on
>the 3 web servers and all the rest is on the development server.
>
>I have 2 employees that will be setting up a couple of things using a cgi
>script called create.pl on test.company.com. When this script is run it has
>to create new test companies or demo companies.
>
>Here is the problem: create.pl is owned by test and group test and has file
>permissions 755. When the create.pl script is run it becomes owner apache
>and group apache and has to create new files and directories on the machine.
>All of the new files and directories then become owner apache and group
>apace. I need them to stay as owner test and group test.
This is a little bit offtopic, since it about permissions and not
really about mod_perl, but here goes:
You want to use the build-in perl function chown.
chown((getpwname('test'))[2,3],@files_to_chown);
You should not have to suexec if the files you're attempting to chown
are owned by apache/apache.
Rob
--
When I used a Mac, they laughed because I had no command prompt. When
I used Linux, they laughed because I had no GUI.
Re: Thumbnail generator
At 4:13 PM +0100 1/21/02, Gerald Richter wrote: > > I recently decided that Apache::Gallery is really nice if you want to >> sit down and start fiddling with templates, but that I needed to make a >> "quick-easy" version for myself. The design is to be extremely simple, >> and is divided into two seperate modules. The first is an on-the-fly >> thumbnail generator (currently supports only jpeg), which is just a >> spiced up implementation of Image::GD::Thumbnail. > >You may want to take a look at Apache::ImageMagick (if you not already >have). It's let's you create thumbnails very easy (just two parameters >pic.xxx/scale?geometry=100x100) and ImageMagick supports over 80 different >formats. It also handles conversion from 4 color pictures to RGB for your >thumbnails and many other things, if you need them. ImageMagick is way too slow for use in a production system. Especially if your resizing large images into thumbnails. I suggest sacrificing space for speed and pre-generating all your thumbnails. Most of the time libjpeg will do everything you need, including scaling. I suggestion GD with Jpeg support or Inline.pm/C/libjpeg for real time conversion of jpegs. There are probably other faster libs out there, and I'm just citing the ones I've heard about or used in the past. Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: [OT] Trouble with dprofpp and Devel::DProf
At 12:46 AM + 1/18/02, Ged Haywood wrote: >Hi all, > >Anyone using 5.7.0 had any trouble with dprofpp? > >Devel::DProf writes tmon.out OK but dprofpp doesn't understand it. >The whole kit came with 5.7.0 in one source tarball. > >I searched p5p with the Google and the perl.com engine and came up >with nothing. Double check that the dprofpp is the same one distributed with 5.7.0 and not 5.6.1 or earlier perl's... -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: Single login/sign-on for different web apps?
At 9:06 PM + 1/16/02, Mark Maunder wrote: >That's cool, but any ideas on how to do this with different domain names i.e. >foo.com, bar.com, baz.com and boo.com? You can't create cookies for the .com >domain, so there's no way to hand out auth cookies from foo.com (when the user >logs into foo.com) and have the browser send them to bar.com too. Also foo.com >can't hand out cookies for bar.com, so you can't implement a single sign on >using cookies for multiple domain names from the same host. > >The only way I could come up with, was to have the browser redirected to every >domain name with an encrypted uri variable to prove it is signed on >which causes >each host included in the single sign on to assign an auth cookie to the >browser. >So the browser is logged into foo.com, bar.com baz.com and boo.com by logging >into foo.com which assigns a cookie and redirects to bar.com which assigns a >cookie and redirects it to baz.com which assigns a cookie and redirects it to >boo.com which assigns a cookie and redirects it back to foo.com. It has now >collected all cookies required for signon to all domain names and is >logged into >all of them. That's not terribly efficient for the user. If I were to do this, I'd probably put some "You are now logged in" page that loads images from foo.com, bar.com, baz.com, and boo.com (transparent single pixel gifs would work). Now the user is logged in to all those servers (provided that the gifs returned were returned with Set-Cookie headers). The same thing can be done with authentication. Most browsers allow you to write urls as http://user:[EMAIL PROTECTED]/images/spacer.gif It's not pretty, and not super secure, but it does work. Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: weird problem. Lost of the POST data
At 3:11 PM +0100 1/16/02, Oscar Serrano wrote: >Here I put the beggining of the file: > >#!/usr/bin/perl -w >use CGI; >use strict; >use varcomunes; #library of my own >use lib $LIBRERIAS_AT; >use EnlacesAT; #library of my own >use Idioma; #library of my own >use DBI; >use OrdenesComunes; #library of my own >use Template; #template toolkit 2.03 >my ($rentafijapup, $rentafijapumm, $accionesp, $accionesmm); >#many other my (whatever) definitions... >my($query,$in); > >print "Content-type: text/html\nPragma: no-cache\n\n"; > >$query=new CGI; >$in=$query->Vars(); > Check to make sure that you do not have some strange version of CGI in $LIBRERIAS_AT. I've been bitten by this in the past when a developer pointed some code to his home directory and had bad/debug copied of modules in there. Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: Beginner's FixupHandler question
At 2:40 PM +0100 1/8/02, Zsolt Czinkos wrote:
>
>---
>Here's my simple script:
>
>package SetMyCookies;
>
>use Apache;
>use Apache::Constants;
>use Apache::Cookie();
Very important to use strict when writing anything in mod_perl.
>sub handler {
>
>my $r = shift;
>
> $c = $r->header_in("Cookie");
$c is going to persist across multiple connections without my().
>local(@rawCookies) = split (/; /,$c);
>local(%cookies);
Use my()... my() is more appropriate in this case.
Always reset %cookies = (); # just in case
>foreach(@rawCookies){
>($key, $val) = split (/=/,$_);
>$cookies{$key} = $val;
>}
>
be sure to my() $key and $val
>foreach $name (keys %cookies) {
>print STDERR "$name = $cookies{$name}\n";
>}
My() $name.
>my $cookie = Apache::Cookie->new($r,
>-name => 'lofos',
>-value => 'lofos13',
>-expires=> '+24M',
>-path => '/'
>);
>
>$r->header_out("Set-Cookie",$cookie->as_string);
>
>return OK;
>}
>1;
>
>---
>And here's the error_log on one request:
More importantly, check your access log. Something like a nimda in
association with the above code might produce multiple lines in your
error log like this.
>kakukk = kukka234534
>kakukk = kukka234534
>kakukk = kukka234534
>kakukk = kukka234534
Good luck,
Rob
--
When I used a Mac, they laughed because I had no command prompt. When
I used Linux, they laughed because I had no GUI.
Re: Form Reading
>Hello
>
>
>This is off topic, thanks for a direct hint to a module or an
>appropriate mailing list.
>
>I want to read an HTML form into an hash. But I don't want to use
>HTML::Tree or similar DOM Object trees. I need simply all form relevant
>information as an hash which is human readable. Example:
Write your own like me ;-)
#!/usr/bin/perl
use strict;
use Data::Dumper;
my $htmlsource = '';
while() {
$htmlsource .= $_;
}
my $formfields = {};
my @tags = split(/[\<\>]/,$htmlsource);
my $i = 0;
for ($i = 0;$i < @tags; $i++) {
my $tag = $tags[$i];
if($tag =~ /^(input|select|option|textarea)\b/i) {
my $type = lc($1);
if($type eq "input") {
my $attr = parse($tag);
push(@{$formfields->{'printorder'}},($attr->{'name'} || ''));
$formfields->{$attr->{'name'}} = {
'tag' => $type,
'attr' => $attr,
'orig' => $tag
};
} elsif($type eq "select") {
my $attr = parse($tag);
push(@{$formfields->{'printorder'}},($attr->{'name'} || ''));
my $rec = {
'tag' => $type,
'attr' => $attr,
'orig' => $tag,
'options' => [],
};
while($tags[$i] !~ /^\/select/i) {
my $opt = $tags[$i];
if($opt =~ /^option/i) {
my $tmp = parse($opt);
$tmp->{'label'} = $tags[$i+1];
push(@{$rec->{'options'}},$tmp);
$i++;
}
$i++;
}
$formfields->{$attr->{'name'}} = $rec;
} elsif($type eq "textarea") {
my $attr = parse($tag);
push(@{$formfields->{'printorder'}},($attr->{'name'} || ''));
my $rec = {
'tag' => $type,
'attr' => $attr,
'orig' => $tag,
'options' => [],
};
my $val = '';
while($tags[$i] !~ /^\/textarea/i) {
$val .= $tags[$i];
$i++;
}
$rec->{'value'} = $val;
$formfields->{$attr->{'name'}} = $rec;
}
}
}
print Dumper($formfields);
sub parse {
my $tag = shift;
$tag =~ s/^\w+//;
$tag =~ s/^\s+//;
return {} unless $tag;
my $attr = {};
my $inquote = 0;
my $pair = '';
for my $char (split(//,$tag)) {
if($char eq '"') {
$inquote = $inquote ? 0 : 1;
next;
}
if($char =~ /\s/ && !$inquote) {
if($pair) {
my ($k,$v) = split(/\=/,$pair);
$v ||= 1 if($k =~ /selected|checked/i);
$attr->{lc($k)} = $v;
}
$pair = '';
next;
}
$pair .= $char;
}
if($pair) {
my ($k,$v) = split(/\=/,$pair);
$v ||= 1 if($k =~ /selected|checked/i);
$attr->{$k} = $v;
}
return $attr;
}
Call it script.pl.
$ perl script.pl < html_page_to_parse.html
Note that it doesn't differentiate between multiple forms on a single
page. I'll leave that as an exercise to the reader.
Enjoy,
Rob
p.s. This hasn't been fully tested.
--
When I used a Mac, they laughed because I had no command prompt. When
I used Linux, they laughed because I had no GUI.
Re: transient object data
At 11:51 AM + 12/23/01, Jean-Michel Hiver wrote:
>Maybe the way to do it would be to have a Serializable class that could have
>the following methods:
>
>freeze($self) : SCALAR
>thaw ($class) : OBJECT
>clone($self) : OBJECT;
>_freeze($self): SCALAR
>_remove_transient_attributes($self);
Hmmm... Maybe instead of Subclassing directly, we should implement
some sort of wrapper which would flag transient data internally.
my $serobj = Transient::Serobj->new(
'Serializer' => 'Storable'
);
$serobj->STORE(KEY,VALUE,TRANSIENT);
my $str = $serobj->freeze;
my $deserobj = Transient::Serobj->thaw($str,{
'Serializer' => 'Storable',
'Callbacks' => {
'KEY' => [CODEREF,CBARGS],
}
});
When the thaw method is called, it reads the stored object data
($str) and where the transient data is normally stored, the callback
(if specified) would be called. Otherwise the transient data
wouldn't be defined.
For instance, If I only wanted to store the two letter US State
abbreviation, but wanted to automatically have access to the state
name, you could implement it something like
my $session = Transient::Serobj->thaw($str,{
'Serializer' => 'Storable',
'Callbacks' => {
'STATENAME' => [
sub {
$GLOBAL::STATE2STATENAME{shift->{'STATE'}}
}
],
}
});
print "I live in ",$session->FETCH('STATENAME'),"\n";
It's seems a bit longwinded here, but once it was subclassed (along
with a few modified constants or variables), it would probably be
much cleaner...
Rob
--
When I used a Mac, they laughed because I had no command prompt. When
I used Linux, they laughed because I had no GUI.
Re: mod_perl book status
At 9:58 AM + 12/18/01, Ged Haywood wrote:
>Hi all,
>
>On Mon, 17 Dec 2001, Stas Bekman wrote (privately, discussing a book review:):
>
>> Ged wrote:
>>
>> If you want to use C but you have both situations on
>> one machine, at the time of writing the only solution is to run two
>> mod_perl enabled servers, one which uses C and one
>> which does not.
>>
>> [META: Stas: Could one not simply patch Apache::DBI to
>> permit disconnects from one of the databases? -- Ged.]
>>
>> That's probably a good idea. Go ahead and suggest it to the author/list?
>
>Author/List: Is this a Good Idea?
I've not tested or tried this, but wouldn't this patch work?
--- ApacheDBI-0.88/DBI.pm Fri Jan 12 13:59:00 2001
+++ ADBI.pm Tue Dec 18 11:53:00 2001
@@ -177,6 +177,10 @@
@ISA=qw(DBI::db);
use strict;
sub disconnect {
+ my $dbh = shift;
+ if($dbh->{'DBIDisconnect'}) {
+ $dbh->DBI::db::disconnect();
+ }
my $prefix = "$$ Apache::DBI";
print STDERR "$prefix disconnect (overloaded) \n" if $Apache::DBI::DEBUG
> 1;
1;
Thus setting the DBIDisconnect flag would cause the dbh to be disconnected.
Rob
--
When I used a Mac, they laughed because I had no command prompt. When
I used Linux, they laughed because I had no GUI.
Re: mod_perl site challenge: proposal to use ASF site design
At 4:17 PM -0500 12/17/01, David Harris wrote: >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. I 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. I 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! Not me, sorry. A little too busy right now. >Lets try to keep this constructive, focused, and concrete. :-) Concrete isn't used when building websites. >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. So long as "most anything" doesn't include designs that are broken. Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: Comparison of different caching schemes
At 6:04 PM -0500 12/14/01, Perrin Harkins wrote: >That's actually a bit different. That would fail to notice updates between >processes until the in-memory cache was cleared. Still very useful for >read-only data or data that can be out of sync for some period though. The primary problem with everything mentioned thus far is that they are almost entirely based around the concept of a single server. Caching schemes that are both fast and work across multiple servers and process instances are very hard to find. After reading the eToys article, I decided that BerkeleyDB was worth a look. We discovered that it was very fast and would make a great cache for some of our commonly used database queries. The problem was that we are running on 5 different servers, load balanced by Big/IP. Again, taking my que from the eToys article, I began working on a data exchange system (using perl instead of C) which multicasts data packets to the "listening" servers. So far, our only problems have been with the deadlocking (solved with db_deadlock), and a few corrupt records. I'm considering uploading to CPAN the stuff I've written for the caching, but haven't had the time to make it generic enough. I also haven't performed any benchmarks other than the "Wow, that's a lot faster" benchmark. One limitation to the stuff I've written is that the daemons (listeners) are non threaded, non forking. That and it's all based on UDP. Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: a new modperl book: mod_perl Developer's Cookbook
At 10:56 AM -0500 12/6/01, Geoffrey Young wrote: >Stas Bekman wrote: >> >> SAMS will publish the new mod_perl Developer's Cookbook by Geoffrey >> Young, Paul Lindner and Randy Kobes in January, 2002. You can find more >> info at http://www.modperlcookbook.org/. >> >> Great work guys! > >thanks for the mention Stas - a bit ahead of schedule but appreciated >nonetheless :) > >we plan on making an official announcement when the book is released. >in the meanwhile, we're working on turning some of the more practical >book examples into official releases for CPAN. expect some RFCs >soon... Advance ordered via Amazon.com! Actually I did it awhile ago when I first found out that there was a new mod_perl. Rob -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
Re: Strange "Can't locate" errors
At 4:41 PM -0700 12/5/01, Tim Tompkins wrote: >I've seen this happen on some NFS volumes on Solaris. In this case the >problem was supported by 'ls' reporting different contents on the same >directory between two different shells. Unfortunately, I'm not an NFS wiz >and I don't recall what the resolution was (yeah, I know... really helpful >:o) Not NFS'd anyway. Someone suggested that I might have a permissions problem, since the webserver ran as user/group nobody. I checked and found that the lib with the perl-5.6.1 directory was read only for world. I'm trying to fix it now... Rob -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
Re: Apache::Session and frames
At 3:06 PM -0800 12/5/01, Michael A Nachbaur wrote: >I have been beating my head against this problem for days, to no >avail. I have tried google searches, etc., still no dice. So, I >apologize for the noise people. > >I'm using Apache::Session and cookies to perform session management. >In watching the debug messages in my error_log, I can see that the >cookie is created, the session is created, and all subsequent calls >correctly loads the session. However, part of the design for my web >application requires the use of frames, with several frames >containing mod_perl generated data. Each one of those frames relies >on using the session. I wouldn't think this would be a problem, >except that some of the frames cannot tie to the datastore, and as a >result create new sessions. > >I would think the default behavior would block until the session is >unlocked, but this doesn't seem to be the case. I was first using >Apache::Session::Flex (For easier configuration), but have also >tried Apache::Session::MySQL, ::DB_File and ::File, all exhibit the >same problem. > >This site is developed using AxKit and AxKit::XSP::Session, but the >sessions are created before AxKit is even invoked so that isn't the >issue. > >Any suggestions? I'd like to resolve this without loosing my hair. :) Cookies set in a parent frame are not immediatly accessable to a child frames. It's a fun little bug that requires a full frame reload to be detected. Another thing to watch out for are the cookie paths. I've never used Apache::Session, so I don't know what path is set for the cookies, but if the pages loading in the child frames have non matching urls, then the session cookies aren't going to come through. Good Luck, Rob -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
Strange "Can't locate" errors
Can't locate CapWiz/Home/App.pm in @INC (@INC contains: /data/ap/perl- 5.6.1/lib/5.6.1/sun4-solaris /data/ap/perl-5.6.1/lib/5.6.1 /data/ap/perl-5.6.1/l ib/site_perl/5.6.1/sun4-solaris /data/ap/perl-5.6.1/lib/site_perl/5.6.1 /data/ap /perl-5.6.1/lib/site_perl . /data/ap/capwiz-apache/ /data/ap/capwiz-apache/lib/p erl) at (eval 12) line 3. Normally this error wouldn't be a problem for me... Except.. [rlandrum@par-s01 Home]$ pwd /data/ap/perl-5.6.1/lib/site_perl/5.6.1/CapWiz/Home [rlandrum@par-s01 Home]$ ls -l total 56 -r--r--r-- 1 rlandrum content27927 Nov 30 15:27 App.pm The file exists! So it's there, and so are all it used modules. Infact, I had this working just a few hours ago with user rlandrum (on port 8083), but once it fired up under root (on port 80), I started getting these errors. And I am definitly using the same httpd binary. This is a: SunOS 5.7 Generic_111437-01 sun4u sparc SUNW,Ultra-4 perl v5.6.1 built for sun4-solaris Apache/1.3.22 (Unix) mod_perl/1.26 Any thoughts? Rob -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
Re: Hi
If this guy is going to be sending us shit all night, I suggest we deactivate his account. Rob At 5:27 PM -0500 12/4/01, Christopher Rivera wrote: >How are you ? >When I saw this screen saver, I immediately thought about you >I am in a harry, I promise you will love it! >Content-Type: application/octet-stream; > name="gone.scr" >Content-Disposition: attachment; > filename="gone.scr" > >Attachment converted: Macintosh HD:gone.scr (/) (0003DC5E) -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
Re: delayed file uploads...
At 3:29 PM -0800 12/3/01, El Capitan wrote: >i have a simple question. im not sure if there is a mod_perl directive or >module for this but id like to perform this simple task: > >two web pages run in sequence. the first page, id like a user to select >several files from his/her machine for uploading to the server using the >input type "file" tag. when the user requests the next page, i DO NOT want >the files to immediately transfer (many reasons for this, just a hard >requirement). rather, id like to store the names of the files into a cookie >or save it on the server with apache::session. this part I already have >working, and am storing the file names into a tied hash using >apache::session module. > >then the user moves onto the second web page and populates more form fields >with additional information. upon submitting this second form, the files >from the previous web page (names stored in the hash %session from >apache::session) are then sent to the server. > >im not sure whether or not this can be done, anyone have any clues? Sorry... Not possible. Once you've got the file fields, you can't force the browser to upload the file on a different page. That would be a huge security hole. Just image a input type=hidden_file name=filetoupload value=/etc/passwd One suggestion would be to popup a window with the file fields. Then let the user select the files, click submit on the parent window, then on the subsequent page, have the parent window issue a child.form.submit or something similar with javascript... Rob -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
[OT] Re: search.cpan.org
Sure... When doing searches. But it takes me about 20 seconds just to hit any page... not just the search pages. And don't misunderstand, I think search.cpan.org is awesome. I just wondered if anyone knew why it was slow all the time. Rob At 12:55 PM -0800 11/27/01, Nick Tonkin wrote: >Because it does a full text search of all the contents of the DB. > > >~~~ >Nick Tonkin > >On Tue, 27 Nov 2001, Robert Landrum wrote: > >> Does anyone know why search.cpan.org is always the s-l-o-w-e-s-t site >> on the internet? I can't believe it always busy. I've had trouble >> hitting it at 3 AM. >> >> Maybe it's just me... >> >> >> Rob >> >> -- >> "Only two things are infinite: The universe, and human stupidity. >>And I'm not >> sure about the former." --Albert Einstein >> > -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
[OT] search.cpan.org
Does anyone know why search.cpan.org is always the s-l-o-w-e-s-t site on the internet? I can't believe it always busy. I've had trouble hitting it at 3 AM. Maybe it's just me... Rob -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
Re: Seeking Legal help
At 3:21 PM -0800 11/21/01, Medi Montaseri wrote: >HiI know this is not the lawyers hang-out, but it is seasoned >contractor's hangout and as such I need some legal advice...May I? > >I did some work (about $25000 worth) for a customer and I'm having >problem collecting. > >One big problem is that I don't have a formal signed hardcopy contract >binding my customer to the work and cost. I however do have verbal, >email communications, FTP logs, Web Access logs, hardcopy business >projections, Witnesses and such showing that I'm not making this up. > >After months of promissing sweet equity, partnership, this and that, >finally customer has asked me to invoice them and charge interest for the >unpaid balance. At the same time customer is using the application >I wrote for them. I however have a feeling that they are simply buying >time and differing the problem. And they might even file chapter 11 as >their marketing projection was not so correct. But I did my part. > >What can I do? Contact a lawyer. Then tell the client that you have contacted a lawyer. Put this in writing and sign it. Be specific and let them know what it is exactly that you want, and that if they do not comply, you'll be forced to enlist the service of a lawyer and file suit. Most of the time, this will be enough to get them to pay... Nobody want's a legal battle, least of all a small business. If they fail to pay, you have two options. Bite the bullet and move on or sue them. I am not a lawyer, but this is the process that my friend went through when he did about $20,000 worth of work for a client that was more than 180 days delinquent. After court costs and lawyer fees, etc., he walked away with $8,000. Not great, but better than nothing. Rob -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
Re: PerlModule not updating %INC
> > >If that is the case, My::Special::Module won't be loaded and >compiled until the very first time that someone hits /whatever. > >Just about EVERY module we use has a 'PerlModule' call to it, >outside any enclosing blocks. Although I do have 'PerlHandler' >directives in and blocks, the modules they use >are preloaded prior to the enclosing block. We're hip to shared >memory :-) It just hit me That is why Apache::StatINC isn't working. We use Apache::StatINC on our development server, but we never preload any modules... We just use SetHandler perl-script PerlHandler My::Special::Module and Apache::StatINC works. If you preload, It's not going to put the module into %INC. Otherwise Apache::StatINC would intentionally overwrite that shared memory and destroy the purpose for using PerlModule in the first place. I could be wrong... but I think that the answer is that "It's not a bug, it's a feature", and that the behavior is actually correct. Rob -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
Re: PerlModule not updating %INC
At 2:31 PM -0800 11/20/01, David Pisoni wrote: > >We have been doing development using mod_perl, but finding that >Apache::StatINC was not working as expected (i.e., we needed to >restart the web server in order to see our module changes in >effect.) Our apache config files preload all necessary modules at >start time using the 'PerlModule' directive. When I started peeking >through Apache::Status I found that although all of our loaded >modules appear in the "Inheritance Tree" and the "ISA Tree", most of >them did not appear in the "Loaded Modules" section. (I also did a >test handler with a dump of the contents of %INC, and said modules >were missing.) The only modules of ours which DID appear were those >which were ALSO called for with 'use' calls by other modules. >> > I just reread your original post... I think I may know what the problem is (maybe). Are you using handlers? SetHandler perl-script PerlModule My::Special::Module PerlHandler My::Special::Module If that is the case, My::Special::Module won't be loaded and compiled until the very first time that someone hits /whatever. This explains the missing modules in %INC (I think), but it does not explain the problem with Apache::StatINC. > >Out of curiosity, I took our configuration file and changed all >the 'PerlModule' directives to 'use' calls (inside a block), >and lo and behold, they all appeared in %INC. >> > And did this fix your problem with Apache::StatINC too? Rob -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
RE: [DIGEST] mod_perl digest 2001/09/22
At 12:38 PM -0800 11/16/01, Geoffrey Young wrote: >I took a brief haitus. as you may or may not know, I >was working on a mod_perl book, and the time required >for that was taking away from _everything_ else in my >life. as somebody put it recently 'looks like you >fell off the internet.' yup, and that was the least >of it - no family time either, which gets you into >deep trouble. What book? Or is it top secret? :) Rob -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
Re: [challenge] new mod_perl site
At 10:44 AM -0800 11/14/01, Nick Tonkin wrote: >No one doubts your commitment to mod_perl, or your hard -- and unpaid >-- work on the guide and many other things. But if you want to be a leader >who inspires people to collaborate and work as a team under your >direction, you'd do well to work on bringing your people skills up to par >with your technical skills, IMHO. Ouch! I think you misunderstood. Stas laid out very clearly what it was he wanted and how to deliver it. I could only hope for so much from the people I work with. Stas is a popular guy, and I'm sure the only reason he asked for specific subject lines is to make submissions easier to find in the mass of email garbage I'm sure he receives. Paid or Unpaid, Stas' contributions to the mod_perl world are nothing short of remarkable. And with this challenge, he's giving other people the opportunity to prove that he isn't the only remarkable contributor to mod_perl. Rob -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
Re: [OT] dont understand mem-mapping
At 10:19 AM +0800 11/12/01, Stas Bekman wrote: > >2. apparently you have the same problem as 'too many connections' >problem, and therefore want to look at Apache::DBI for understanding >the problem and coming up with a similar solution for your problem. I had similar problems, and unforunatly couldn't use Apache::DBI (multiple databases and too many open connections), but Pools in apache/mod_perl 2.0 look like they might be the solution... even if they are a ways off... Good luck, Rob -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
Re: fork/CGI/Apache problem
At 2:30 PM +0100 11/2/01, Marco Kleefman wrote:
>Hello everybody,
>
>I am new to the list. I have a question I hope you can help me with. It is
>not a modperl question, just a normal perl question related to Apache/CGI.
>
>I have this script which forks off a process which does something. I already
>encountered the problem of my browser waiting for the child to be finished.
>I solved it by closing STDIN/OUT/ERR. But I still have another problem...
>Somehow all print statements in my script which occur before the fork-part
>of the script are printed twice! I have tried to unbuffer STDOUT, but no
>luck until now...
>
>Here's my script:
>
>#! /usr/bin/perl
>print "start: pid=$$\n"; # this line gets printed twice!
>print "Content-type: text/html\n\n"; # this line gets printed twice!
>
>if (!defined ($pid = fork))
>{
>die "Unable to fork: $!\n";
>}
>elsif (! $pid)
>{
>warn "child: pid=$$\n";
>
># this is the branch for the child process
>close(STDIN); close(STDOUT); close(STDERR);
You need to close these before you fork. Right now, you're printing
your headers out to the buffer. When you call close, it
automatically flushes the buffer, and since there are now two buffers
(you've forked at this point) it prints twice.
Rob
--
"Only two things are infinite: The universe, and human stupidity. And I'm not
sure about the former." --Albert Einstein
Re: inconsistency between CGI.pm and Apache::Request
>There is some inconsistency between CGI.pm and Apache::Request's
>param() method, especially in handling of multivalued parameter.
>
> $q = CGI->new;
> $q->param(foo => qw(a b c));
> @foo = $q->param('foo'); # ('a', 'b', 'c')
> $q->param(bar => [ qw(a b c) ]);
> @bar = $q->param('bar'); # (['a', 'b', 'c'])
>
> $r = Apache::Request->new(Apache->request);
> $r->param(foo => qw(a b c)); # die with an error
> $r->param(bar => [ qw(a b c) ]);
> @bar = $r->param('bar'); # ('a', 'b', 'c')
Doesn't this have something to do with the way your shorthanding
Apache::Request?
Try
$r->param('foo',qw(a b c));
It might work... I remember running into this several years ago, and
never mentioned it.
>Am I the only one who wants consistency between the two?
No. It's my opinion that CGI.pm is wrong. Never would an input
value come out as an arrayref. And never would you want to store an
arrayref in something that might be used to generate hidden inputs.
Lincoln can argue with me.
Rob
--
"Only two things are infinite: The universe, and human stupidity. And I'm not
sure about the former." --Albert Einstein
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
At 3:38 PM -0400 10/23/01, Stephen Adkins wrote: >Several of you have made the same good point. >And now the naming flame war has already begun... ;-) This is a discussion. Something has been proposed and it needs a name. I'd hardly call this a flame war. A name is pretty important and if it's acronym isn't easily recognized, it isn't going to gain the support of developers. J2EE is catchy, so we need something catchy. PEF isn't nearly as catchy as P2EE or P5EE or PEA (Perl Enterprise API), but maybe I'm just crazy. Rob -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
Re: Help with converting from plain CGI to mod_perl
At 1:49 PM -0700 10/17/01, Walt Knowles wrote: > > >Converting all the globals to Module variables has been a piece of cake, but >I've run into one big issue. Depending on how you log into the system, the >user will connect to different databases. When they do this, I store the >Database Handle from DBI/DBD as $main::dbh. Hmm... If you use $main::dbh everywhere (instead of $dbh = DBI->conn...), it should work, but this is considered bad form. Since $main:: is local to the Apache process, it's technically global, and that's bad. I'd suggest changing your code (as we did for our site) to pass $dbh around to each method and object. Good luck, Rob -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
Re: Programmer Wanted
At 10:43 AM -0700 10/12/01, BuildReferrals.com wrote: >Hello, > >My name is James Ventrillo, the webmaster of BuildReferrals.com and >CompanionBar.com. I am looking for a programmer to be part of my >company. We have a staff of 8 and we desperately need an additional >programmer. Over the next few weeks, we need extensive programming >performed on our websites. We will pay an hourly rate, dependent on >your experience. Is it just me, or do all these multi-level-marketers sound the same? Whether they're writing spam or job postings, it still comes out sounding cheezy... Rob -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
Re: [OT] Overridding a module's use of a function
At 5:15 PM -0500 10/11/01, George Sanderson wrote:
>I discovered that File::NCopy uses the function "glob" to expand file
>names. My problem is that I need to pass file names that have spaces in
>them and "glob" does not process them. So I did the following override (I
>do not need to expand the file names):
>
>package Apache::AAM;
>. . .
>package File::NCopy;
>use subs qw(glob);
>sub glob {@_};
>package Apache::AAM;
>. . .
*File::NCopy::glob = sub {@_}; # should do the same thing
I think _Advanced Perl Programming_ covered overriding subs with subrefs...
Rob
--
"Only two things are infinite: The universe, and human stupidity. And I'm not
sure about the former." --Albert Einstein
Re: Off-topic - Apache Config - Load crises
>I know this is a bit off topic, but I could use some immediate advise on >server config? > > >Got a server which is getting hit really bad. >Have to keep it up. I've got: > > >P Timeout 300 > ># Keepalive, better on this server... >KeepAlive On >MaxKeepAliveRequests100 >KeepAliveTimeout5 Hmm... I usually drop keep alive all together and move the images to another server... like images.yourhost.com. Keep Alive should be set high enough to avoid closing a connection before a machine has time to make the next request. 5 seconds is a pretty short interval. And with your 1 second ping times, your looking at a 2 second round trip on packets... So there'll be 2 or more seconds of delay between the time that the first request sends it's last packet and when the next request sends it's first packet. I'd suggest upping the keep alive timeout to 10 or 15 (isn't 15 the default?). Another possible solution (if you have a lot of memory and a lot of dynamic content) is to throw a squid cache on the web server. I had good luck with squid during the last election... Good luck, Rob -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
Re: [patch] overriding per directory PerlSetEnv
Couldn't you do the same thing by reversing the ordering of your
Directory entries...
>
>PerlSetEnv VAR /usr/local/apache/cgi-bin/subdir
>
>
>
>PerlSetEnv VAR /usr/local/apache/cgi-bin
>
Rob
At 1:08 AM +0900 10/5/01, YAMAMOTO Kengo wrote:
>Hi,
>
>I rescently started to use mod_perl. It works fine, but a
>strange behavior have found. I have written a patch that collect
>the behavior. Please comment this.
>
>I think that per directory PerlSetEnv variable should be
>overridden by the value that in the most specific(longest)
> section.
>
>http://localhost/cgi-bin/subdir/printenv with following config
>will generate VAR="/usr/local/apache/cgi-bin/subdir", but
>generated result is VAR="/usr/local/apache/cgi-bin".
>
>
>PerlSetEnv VAR /usr/local/apache/cgi-bin
>
>
>
>PerlSetEnv VAR /usr/local/apache/cgi-bin/subdir
>
>
>
>Following patch corrects this behavior by modify overriding
>logic. It seems work well.
>
>
>--- mod_perl-1.26/src/modules/perl/perl_config.c.orig Thu Oct 4
>09:31:00 2001
>+++ mod_perl-1.26/src/modules/perl/perl_config.c Thu Oct 4
>09:32:04 2001
>@@ -183,7 +183,8 @@
> table_entry *elts = (table_entry *)arr->elts;
>
> int i;
>- for (i = 0; i < arr->nelts; ++i) {
>+ /* iterate in reverse order to override duplicate key properly */
>+ for (i = arr->nelts - 1; 0 <= i; --i) {
> MP_TRACE_d(fprintf(stderr, "mod_perl_dir_env: %s=`%s'",
>elts[i].key, elts[i].val));
> mp_setenv(elts[i].key, elts[i].val);
>
>
>I'm not familar with mod_perl internals and community. Please
>tell me relative topics, more appropriate place to send patch,
>etc.
>
># Make my English writing correct is also welcome :-)
>
>-
>YAMAMOTO Kengo [EMAIL PROTECTED]
--
"Only two things are infinite: The universe, and human stupidity. And I'm not
sure about the former." --Albert Einstein
Re: Segmentation Fault
At 10:33 AM +0400 9/20/01, Andrei A. Voropaev wrote:
>The funny part is that in our case we also get Segmentation fault from time to
>time but there's no coredump file. I even tried to attach gdb to apache child
>and wait for Segfault. I got it but I'm not sure I could understand it. Please
>see below for examples.
>
>The only thing I can say here that after we drastically reduced usage of
>module Carp.pm the Segmentation faults almost disappeared. (I mean it. Before
>the change we had Segfaults 5-6 times every minute. Now we have it once in
>20-30 minutes). Please note that Carp::croak was used by Mason object in
>method 'abort' so we had to stop using it.
I had this very same problem on a system I setup last november for
the 2000 elections. We had three servers, all running linux, apache,
and mod_perl (probably all different versions), and this was the only
box that core dumped.
I later discovered that there was a bug in Carp under perl 5.6.0 and
that upgrading would have fixed my problem...
At 10:32 AM -0800 1/31/01, Doug MacEachern wrote:
>On Wed, 31 Jan 2001, Robert Landrum wrote:
>
>> Has anyone else had problems with the Carp module and mod_perl?
>
>there were bugs related to Carp in 5.6.0, fixed in 5.6.1-trial1,2
You can continue to use Mason by putting a line in startup.pl
*Carp::croak = sub { die };
*Carp::carp = sub { warn };
Rob
>Andrei
>
>--
>Program received signal SIGSEGV, Segmentation fault.
>0x406041ec in Perl_sv_setsv () from /etc/httpd/modules/libperl.so
>(gdb) bt
>#0 0x406041ec in Perl_sv_setsv () from /etc/httpd/modules/libperl.so
>#1 0x405fa329 in Perl_pp_sassign () from /etc/httpd/modules/libperl.so
>#2 0x405f9f0a in Perl_runops_standard () from /etc/httpd/modules/libperl.so
>#3 0x405ba456 in S_call_body () from /etc/httpd/modules/libperl.so
>#4 0x405ba028 in perl_call_sv () from /etc/httpd/modules/libperl.so
>#5 0x405ef71f in Perl_vdie () from /etc/httpd/modules/libperl.so
>#6 0x405ef859 in Perl_die () from /etc/httpd/modules/libperl.so
>#7 0x406231f6 in Perl_pp_die () from /etc/httpd/modules/libperl.so
>#8 0x405f9f0a in Perl_runops_standard () from /etc/httpd/modules/libperl.so
>#9 0x405ba456 in S_call_body () from /etc/httpd/modules/libperl.so
>#10 0x405ba231 in perl_call_sv () from /etc/httpd/modules/libperl.so
>#11 0x4059c225 in perl_call_handler () from /etc/httpd/modules/libperl.so
>#12 0x4059ba6b in perl_run_stacked_handlers () from
>/etc/httpd/modules/libperl.so
>#13 0x4059a1c8 in perl_handler () from /etc/httpd/modules/libperl.so
>#14 0x08054ead in ap_invoke_handler () at eval.c:41
>#15 0x0806704c in ap_some_auth_required () at eval.c:41
>#16 0x080670c3 in ap_process_request () at eval.c:41
>#17 0x0805f6d7 in ap_child_terminate () at eval.c:41
>#18 0x0805f919 in ap_child_terminate () at eval.c:41
>#19 0x0805fc6b in ap_child_terminate () at eval.c:41
>#20 0x080601ac in ap_child_terminate () at eval.c:41
>#21 0x080608a3 in main () at eval.c:41
>#22 0x40141177 in __libc_start_main (main=0x8060420 , argc=3,
>ubp_av=0xbb3c,
>init=0x804fa50 <_init>, fini=0x808a570 <_fini>, rtld_fini=0x4000e184
><_dl_fini>,
>stack_end=0xbb2c) at ../sysdeps/generic/libc-start.c:129
>
>(gdb) info frame
> Stack level 0, frame at 0xb418:
> eip = 0x406041ec in Perl_sv_setsv; saved eip 0x405fa329
> called by frame at 0xb448
> Arglist at 0xb418, args:
> Locals at 0xb418, Previous frame's sp is 0x0
> Saved registers:
> ebx at 0xb40c, ebp at 0xb418, esi at 0xb410, edi at 0xb414,
> eip at 0xb41c
>-
>
>(gdb) bt
>#0 0x406059be in Perl_sv_clear () from /etc/httpd/modules/libperl.so
>#1 0x40605d6f in Perl_sv_free () from /etc/httpd/modules/libperl.so
>#2 0x405f8afd in Perl_av_clear () from /etc/httpd/modules/libperl.so
>#3 0x40618ea9 in Perl_leave_scope () from /etc/httpd/modules/libperl.so
>#4 0x4061758c in Perl_pop_scope () from /etc/httpd/modules/libperl.so
>#5 0x4061c535 in Perl_die_where () from /etc/httpd/modules/libperl.so
>#6 0x405efb5a in Perl_vcroak () from /etc/httpd/modules/libperl.so
>#7 0x405efbf9 in Perl_croak () from /etc/httpd/modules/libperl.so
>#8 0x406039a5 in Perl_sv_setsv () from /etc/httpd/modules/libperl.so
>#9 0x405fbd47 in Perl_pp_aassign () from /etc/httpd/modules/libperl.so
>#10 0x405f9f0a in Perl_runops_standard () from /etc/httpd/modules/libperl.so
>#11 0x405ba456 in S_call_body () from /etc/httpd/modules/libperl.so
>#12 0x405ba028 in perl_call_sv () from /etc/httpd/modules/libperl.so
>#13 0x405ef71f in Perl_vdie () from /etc/httpd/modules/libperl.so
>#14 0x405ef859 in Perl
Re: I must be doing something dumb
U
PerlFixupHandler not PerlFixUpHandler
# ./httpd -L | grep Fix
PerlFixupHandler (mod_perl.c)
the Perl Fixup handler routine name
Rob
At 2:28 AM +0800 9/20/01, Stas Bekman wrote:
>[Michael, please always keep the threads on the list, unless you've
>been asked to take it off the list.]
>
>Michael wrote:
>
>>>Michael wrote:
>>>
apache 1.3.6, modp 1.19
When I include
SetHandler perl-script
PerlFixUpHandler Apache::MyModule
I get the error message
Invalid command 'PerlFixUpHandler', perhaps mis-spelled or defined by
a module not included in the server configuration
/usr/local/apache/bin/apachectl start: httpd could not be started
This has got to be some kind of cockpit trouble, but it is not
comming to me. Regular PerlHandler statements work just fine.
Michael
>>>You didn't enable this hook. See
>>>
>>>http://thingy.kcilink.com/modperlguide/install/Callback_Hooks.html
>>>
>>hmm it appears to me that it is enabled by EVERYTHING=1
>>
>>if($EVERYTHING) {
>> @callback_hooks{qw(PERL_STACKED_HANDLERS PERL_METHOD_HANDLERS)} =
>> (1) x 2; for(qw(ALL_HOOKS PERL_SSI PERL_SECTIONS
>> PERL_DIRECTIVE_HANDLERS
>> PERL_LOG_API PERL_URI_API PERL_UTIL_API PERL_TABLE_API
>> PERL_FILE_API)) {
>> $$_ = 1;
>> }
>>}
>>
>>Am I missing something??
>
>
>Mine is build static, I can test with:
>
>
>% strings /home/httpd/httpd_perl/bin/httpd_perl | grep -i PerlFixUpHandler
>PerlFixupHandler
>
>
>
>--
>
>
>_
>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/
--
"Only two things are infinite: The universe, and human stupidity. And I'm not
sure about the former." --Albert Einstein
Re: $r->args()
At 11:19 AM -0700 8/29/01, Rasoul Hajikhani wrote:
>Robert Landrum wrote:
>>
>> > > Which should solve your problems (I think).
>> >
>> >I am affraid it did not work. I have no problem reading the data in the
>> >current handler, but right after redirect, which is also required to
>> >read the data, I loose all the POSTED data.
>>
>> Performing a redirect causes posted data to be discarded.
>
>Did not find that in docs! maybe should pay more attention :(
I'm sure it's in the docs somewhere, but personal experience and
previous posts to this list have addressed this issue.
> > Your goal should be to convert
>
>?? You lost me there... "convert"? convert to what?
Convert as in from POST request to GET request.
sub escaped {
my $val = shift;
$val =~ s/(\W)/sprintf("%%%.2X",ord($1))/g;
return $val;
}
my $content = join('&',map{$_."=".escaped($r->param($_))}($r->param));
my $internal_url = "/some/path/to/handler?$content";
$r->internal_redirect($internal_url);
>
>>all of your posted data so that it can be passed via GET.
>
>Would it make any diference if the method, and method_number remained
>POST? Does this situation occure as a result of method conversion? (I
>will try that)...
Unlikely.
>
>-r
>
>PS: Something wrong with the mail server?
Uhh... Why?
Rob
--
"A good magician never reveals his secret; the unbelievable trick
becomes simple and obvious once it is explained. So too with UNIX."
Re: $r->args()
> > Which should solve your problems (I think). > >I am affraid it did not work. I have no problem reading the data in the >current handler, but right after redirect, which is also required to >read the data, I loose all the POSTED data. Performing a redirect causes posted data to be discarded. Your goal should be to convert all of your posted data so that it can be passed via GET. Rob -- "A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX."
Re: $r->args()
At 9:36 AM -0700 8/29/01, Rasoul Hajikhani wrote:
>Hello,
>I already have asked this question and got an answer for it, so please
>accept my forwarded apologies. However, I was trying something else and
>got stuck. I know in order to pass around query string, or form data,
>pnotes may be used. However, I am trying something else and it does not
>seem to work!
>
> $r = Apache::Request->new($r);
> # check for some condition
> if ($condition)
> {
> my $previous_uri= $r->param('previous_uri');
>
>my $content = $r->param();
>
>$r->method_number(M_GET);
>$r->method('GET');
>
>$r->headers_in->unset("Content-length");
>
>$r->args($content);
>
>$r->internal_redirect("$previous_uri");
> }
So your goal is to turn a post request into a get request using an
internal redirect.
>However, in my called handler, no Post data can be read. Can any one
>tell me why is that?
>Any comments welcomed...
param does not work like args, and $content in this example will
return the number of param keys (IIRC).
I think you want
my $content = join('&',map{$_."=".$r->param($_)}($r->param));
Which should solve your problems (I think).
Rob
--
"A good magician never reveals his secret; the unbelievable trick
becomes simple and obvious once it is explained. So too with UNIX."
Re: Installation problem...urgent
At 8:45 AM +1000 8/22/01, Robert wrote: > >> > $ make >>> > $ make install >>> > >>> >My apache configuration can`t take the option >>> >---activate-module=src/modules/perl/libperl.a > >This is because Alvaro hasn't yet installed mod_perl. > >configure apache (only) >configure and make/install mod_perl >make/install apache > Hmm... Then that would be the problem. I always go the way of the guide http://perl.apache.org/guide/install.html http://perl.apache.org/guide perl Makefile.PL DO_HTTPD=1 EVERYTHING=1 APACI_ARGS='--prefix=/usr/local/apache' is the one I always use Rob -- "A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX."
Re: Installation problem...urgent
At 6:30 PM -0400 8/21/01, Alvaro Toro Santivanez wrote: >Thanks for your help, sorry i type bad in my e-mail i only put >--activate and try the ./configure but continue marking the ERROR >The version of apache is 1.3.20 and my mod_perl is 1.26 From the SUPPORT file included with the mod_perl distribution: > > Always include this information: > > Output of C > We'll need this... > Version of mod_perl > 1.26. > Version of apache > 1.3.20 > Options given to mod_perl's Makefile.PL > Need this too > Server configuration details > Probably not relevent yet, but could you include all the options you passed to ./configure? > Relevant sections of your ErrorLog (make test's is: t/logs/error_log) > Not Applicable yet. > If 'make test' fails, the output of 'make test TEST_VERBOSE=1' Again, Not Applicable. Robert Landrum >Thanks for your help >Regards >Alvaro > > >On Tue, 21 Aug 2001, Robert Landrum wrote: > >> At 6:02 PM -0400 8/21/01, Alvaro Toro Santivanez wrote: >> >Hello i have one problem when i install in the part: >> > >> >> >> >> >> >> >> > >> > $ cd apache_x.x.x >> > $ ./configure \ >> > --prefix=/path/to/install/of/apache \ >> > --activate-module=src/modules/perl/libperl.a \ >> > [...] >> > $ make >> > $ make install >> > >> >My apache configuration can`t take the option >> >---activate-module=src/modules/perl/libperl.a >> >> Assuming that the extra '-' at the beginning of activate-module is >> not a typo, that would be your problem. Otherwise, I think we'll >> need some more information. >> >> Remember: when posting to the list, be sure to include everything >> that's requested in the SUPPORT file included with you mod_perl >> distribution. >> >> Robert Landrum >> >> >> -- >> "A good magician never reveals his secret; the unbelievable trick >> becomes simple and obvious once it is explained. So too with UNIX." >> > -- "A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX."
Re: Installation problem...urgent
At 6:02 PM -0400 8/21/01, Alvaro Toro Santivanez wrote: >Hello i have one problem when i install in the part: > > > $ cd apache_x.x.x > $ ./configure \ > --prefix=/path/to/install/of/apache \ > --activate-module=src/modules/perl/libperl.a \ > [...] > $ make > $ make install > >My apache configuration can`t take the option >---activate-module=src/modules/perl/libperl.a Assuming that the extra '-' at the beginning of activate-module is not a typo, that would be your problem. Otherwise, I think we'll need some more information. Remember: when posting to the list, be sure to include everything that's requested in the SUPPORT file included with you mod_perl distribution. Robert Landrum -- "A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX."
Re: mod_perl's ease of installation and the list (was: Re:Problems installing libapreq)
At 9:20 PM -0700 8/16/01, Nick Tonkin wrote: >On Thu, 16 Aug 2001 10:38:56 -0700 Ged Haywood wrote: > >> On Wed, 15 Aug 2001, Nick Tonkin wrote: >> >> > > Somehow they are not getting setup right. >> > >> > Yeah, no kidding, Joe. >> > > > He's only trying to help. :) > >[snip] >So what I mean to say is, firstly, that I think that it's unfortunate that >the level of complexity of getting mod_perl going is so high, and >maybe some more work could be directed in the ease-of-use area. I realize, >of course that it takes at least two to tango, and to be fair there are >many other components of a comprehensive web application platform that >also have work together with each other and mod_perl. I'm sure in my >current case it's something to do with how FreeBSD installed Perl, or some >such. But that's my whole point. I don't think it should be a prerequisite >that you be able to debug your whole system configuration in order to get >mod_perl working. It just creates a barrier, one which I've always been >determined to overcome, but which I am sure has turned many other >would-be mod_perlers away. Actually, I had an idea about this... I have no idea how mod_perl and apache 2.0 are going to work. That said, my suggestion is to make modules work a little more like an rc.d script. Basically, you download apache and untar it. Then you download mod_perl or mod_php or mod_ssl or mod_* or all of the above. For each module you run tar -zxvf mod_whatever.tar.gz cd mod_whatever ./configure make link The make link command creates a "linking" file in the apache source directory automatically. The "linking" file would basically be a makefile explaining how to copy the headers and libraries to the apache tree for compilation. This way, you wouldn't have to tell apache about everything you wanted to add. Instead, apache config would just iterate through the directory with all the "linking" files and know from those files what to include. I think this is very similar to the way its currently done, except it's much more automated and easier for the user (IMHO). I know I've had problems trying to get mod_php, mod_perl, and mod_ssl to compile together. Robert Landrum -- "A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX."
Re: modperl 2.0
> > > >Weirdly perl5.6.1 -V thinks it is perl 5.6.0 ?-S >> >> Please paste the entire output of perl5.6.1 -V so that we can see >>what's wrong. >> >> Thanks, >> > >Here it comes: > > >Script started on Thu Aug 16 16:12:49 2001 >doctor.nl2k.ab.ca//usr/libdata$ find . -name \*Config.pm\* -print >./perl5/CPAN/Config.pm~ >./perl5/CPAN/Config.pm >./perl5/i386-bsdos/Config.pm >./perl5/site_perl/Net/Config.pm >./perl5/site_perl/i386-bsdos/Tk/Config.pm >./perl5/site_perl/i386-bsdos/Apache/MyConfig.pm >./perl5/site_perl/i386-bsdos/Apache/ModuleConfig.pm >./perl5/site_perl/5.005/HTML/EP/Config.pm >./perl5/site_perl/5.005/HTML/Mason/Config.pm >./perl5/site_perl/5.005/Apache/Roaming/LiPrefs/Config.pm >./perl5/site_perl/5.005/Apache/DBILogConfig.pm >./perl5/site_perl/5.005/i386-bsdos/Net/Config.pm >./perl5/site_perl/5.005/i386-bsdos/Apache/MyConfig.pm >./perl5/site_perl/5.005/i386-bsdos/Apache/ModuleConfig.pm >./perl5/site_perl/5.6.0/i386-bsdos/Apache/MyConfig.pm >./perl5/site_perl/5.6.0/i386-bsdos/Apache/ModuleConfig.pm >./perl5/site_perl/5.6.0/Net/Config.pm >./perl5/site_perl/5.6.0/Template/Config.pm >./perl5/5.00503/i386-bsdos/Config.pm >./perl5/5.00503/CPAN/Config.pm >./perl5/5.00503/CPAN/Config.pm~ Ok... There are several installations here. My guess is that the system was installed with perl version 5.00503. Then you upgraded to perl 5.6.0. Now you've upgraded again to perl 5.6.1. Perl 5.6.1 has installed a Config.pm into ./perl5/i386-bsdos/Config.pm. >doctor.nl2k.ab.ca//usr/libdata$ perl5.6.0 -V >Perl lib version (v5.6.0) doesn't match executable version (v5.6.1) >at /usr/libdata/perl5/i386-bsdos/Config.pm line 21. >Compilation failed in require. >BEGIN failed--compilation aborted. Umm... perl5.6.0 -V is looking at the first config file it finds, which happens to be the one that was installed by perl 5.6.1. That is why the versions do not match. >doctor.nl2k.ab.ca//usr/libdata$ perl5.6.0 -V[1P[4h1[4l >Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: > Platform: >[snip] >Characteristics of this binary (from libperl): > Compile-time options: USE_LARGE_FILES > Built under bsdos > Compiled at May 9 2000 14:39:24 > @INC: >/usr/libdata/perl5/i386-bsdos >/usr/libdata/perl5 >/usr/contrib/lib/perl5/site_perl/5.6.0/i386-bsdos >/usr/contrib/lib/perl5/site_perl/5.6.0 >/usr/contrib/lib/perl5/site_perl >. >doctor.nl2k.ab.ca//usr/libdata$ exit >exit At this point, I'm going to suggest that you fully migrate to perl 5.6.1. This means that you need to stop using perl5.6.0 in your #! lines. Either that, or remove perl5.6.0 and link it to perl5.6.1. Note: YMMV. ln -s /usr/bin/perl5.6.1 /usr/bin/perl5.6.0 If this is not what you have in mind, then I suggest reinstalling a fresh copy of perl 5.6.0 from source to overwrite the existing Config.pm file and any other files perl 5.6.1 might have installed. In the future, I would suggest including as much information in your original post as neccesary as not every one is as patient or as willing to help as I am, especially when the thread starts getting long. Sincerely, Robert Landrum -- "A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX."
[OT] Re: Do virtual hosts need their own servers?
At 3:21 PM -0400 8/16/01, Robert Landrum wrote: >Sorry for the slightly OT post... > >I found something interesting when playing with virtual hosts. > >We host anesthesiasafety.net as a virtual host along with serveral >other domains and some of our users are typing ANESTHESIASAFTY.NET >and it's not matching in the "ServerAlias"es Is there a case >insensitive "ServerAlias" directive? Or do I need to account for >all possibilities of AneSthesIaSafeTy.Net? *Doh*... Another stupid coding error my part... Sorry, Rob -- "A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX."
Re: modperl 2.0
At 4:02 PM -0600 8/16/01, The Doctor wrote: >On Sun, Aug 12, 2001 at 10:17:32AM -0400, Barrie Slaymaker wrote: >> On Sat, Aug 11, 2001 at 08:58:00AM -0600, The Doctor wrote: >> >> Hopefully this will point you in the right direction. I would need more >> data to figure it all out. As a next step, can you find the locations >> of the perls in question and run a "perl5.6.0 -V", a "perl5.6.1 -V" and >> a "perl -V"? >> > >Weirdly perl5.6.1 -V thinks it is perl 5.6.0 ?-S Please paste the entire output of perl5.6.1 -V so that we can see what's wrong. Thanks, Robert Landrum -- "A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX."
[OT] Re: Do virtual hosts need their own servers?
Sorry for the slightly OT post... I found something interesting when playing with virtual hosts. We host anesthesiasafety.net as a virtual host along with serveral other domains and some of our users are typing ANESTHESIASAFTY.NET and it's not matching in the "ServerAlias"es Is there a case insensitive "ServerAlias" directive? Or do I need to account for all possibilities of AneSthesIaSafeTy.Net? Rob -- "A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX."
Re: Apache::Request
At 1:11 PM -0700 8/15/01, Rasoul Hajikhani wrote: >I get the following error on >my $i = Apache::Request->instance($r); I think you want my $i = Apache::Request->new($r); I've never used or seen instance before, but I've only been doing mod_perl for about 20 months. Rob -- "A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX."
Re: Help with cookies
At 3:50 PM -0400 8/8/01, Perrin Harkins wrote: > >It depends on what's happening in that second module. If you don't send an >actual response to the client, headers (including cookies) will not be sent >out. Umm... Is > return OK; the correct thing to return when using multiple handlers? I thought DECLINED was the correct status code. Then the last module (in this case MIS_APPS::RHS::Control::Scan) would return OK. Robert Landrum -- "A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX."
Re: Just while we are so nicely [OT]: SQL Search Results in pages
At 1:07 PM +0200 8/2/01, Joachim Zobel wrote: >Hi. > >One of the really nice features of MySQL (OK, its not a "real" >RDBMS, but who cares:) is LIMIT. > >Using Oracle I have found it a real pain to display search results >in pages (of eg 20) while using connection pooling. The problem is >that you can not be shure to repeat the same resultset on every >page. This gets a real problem if the queries get expensive and I >can't afford sorting because it destroys first row performance. You can with a result index. When your user first gets to the page, dump the rowids and rownums to a result_index table. create table result_index ( session_idnumber(10), myrowid varchar(30), myrownum number(10), mydatedate ); insert into result_index select 123456,rowid,rownum,sysdate from your_table; The date column is so that you can purge the result index after 24 hours... delete from result_index where mydate < sysdate - 1; Then, for the query... select * from result_index a, your_table b where a.session_id = ? and a.myrowid = b.rowid and a.myrownum between ? and ? I have not actually implemented this anywhere. I wrote something similar where I limited based on rownum, but rownum only numbers the result set, not the table set. Rob >Is there a generic soloution to this? Has anybody found this worth >writing a pattern? > >Thanx, >Joachim >-- >"... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden >koennen."- Bertolt Brecht - Leben des Galilei -- "A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX."
Re: Apache::DBI Oracle LOB problem
At 2:15 AM +0100 8/2/01, Tim Bunce wrote: >On Mon, Jul 30, 2001 at 04:57:09PM -0400, Steven Schmidt wrote: >> The following problem came up in porting EnsEMBL to Oracle: >> >> Level 9 DBI trace: >> OCIStmtExecute(62c0ec,6363d0,62c310,0,0,0,0,0)=SUCCESS >> OCIAttrGet(6363d0,4,ffbeebea,0,10,62c310)=SUCCESS >> dbd_st_execute SELECT returned (SUCCESS, rpc0, fn4, out0) >> <- execute= '0E0' at /usr/local/apache/perl/foo.pl line 34 >> >> fetchrow_array DISPATCH (DBI::st=HASH(0x381d1c) rc1/1 @1 g1 >> a0) at /usr/local/apache/perl/foo.pl line 35 >> -> fetchrow_array for DBD::Oracle::st >> (DBI::st=HASH(0x381d1c)~0x384ecc) >> dbd_st_fetch 4 fields... >> OCIStmtFetch(6363d0,62c310,1,2,0)=SUCCESS >> dbih_setup_fbav for 4 fields => 0x384c8c >> dbd_st_fetch 4 fields SUCCESS >> 0 (rc=0): '484' >> OCILobGetLength(62c0ec,62c310,62a4d4,ffbee9dc)=SUCCESS >> >> >>OCILobRead(62c0ec,62c310,62a4d4,ffbee9d8,1,782808,136351,0,0,0,1)=STIL >>L_EXECUTING > >That's almost certainly an Oracle bug. DBD::Oracle doesn't enable non-blocking >mode of the OCI so, as far as I know, the OCI should never return >STILL_EXECUTING. I'm sure I've seen this before... On a really old version of DBD::Oracle. One of my selects was failing on a string greater than 140k... It was under linux, RH 5.1, DBD::Oracle < 0.96, DBI < 1.00. I can't remember exactly what error I got, but upgrading DBD::Oracle seemed to fix the problem. Rob >Talk to Oracle about it. > >No need to mention DBD::Oracle... just send them the trace after >removing lines that don't match /\bOCI\w+\(/ > >:-) > >Tim. -- "A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX."
Re: dbi abstraction layer on perlmonks
At 2:32 PM -0700 8/2/01, brian moseley wrote: >for the next perl conference i'm writing a do everything >abstraction layer. it will provide a do_stuff routine that >will, out of the box, do your laundry and perform oral sex. >scalable, robust, state of the art technology for >e-businesses. Sweet... I was getting kinda tired of my Linux box "going down on me." Rob -- "A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX."
Re: What counts as a real DBMS?
At 4:27 PM -0400 8/1/01, Philip Mak wrote: >On Wed, 1 Aug 2001, Henrik Edlund wrote: > >> And while we are discussing "not cutting corners", those who still use >> MySQL should switch to a real DBMS before they even think of abstracting >> the SQL away from their Perl code. >> >> That people still use MySQL really shows how many lusers there are with >> computers that try to develop real software. I said _try_. > >What would you consider to be a real DBMS? Sybase and Oracle obviously, >but I actually am the hypothetical programmer with a 233MHz machine with >64 MB RAM (hey, it runs emacs fine :/) on a shoestring budget who is >mostly limited to using freeware tools. > >What about PostgreSQL and Interbase? Do those have the features of a >'real' DBMS? I use sequences. Therefore I need a real DBMS (either that or a rock solid way of generating UNIQUE ids). Oracle and PostgreSQL have great support for sequences. Sybase sucks from the standpoint of sequences. It's almost impossible to write a conversion script for Oracle sequences to Sybase (@@identity?) sequences without developing a tumor... Same goes for MySQL (LAST_INSERTED_ID?). There are things about Sybase and MySQL that I consider amazing. Sybase is amazingly fast, even with many thousands of connections. MySQL is blazingly fast for even large database (so long as you're not doing any inserts). Over all though, I consider Oracle and PostgreSQL the top in the Commercial and Free markets. Rob -- "A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX."
Re: [OT] Inspired by closing comments from the UBB thread.
>All, > >In his closing comments about UBB Kyle Dawkins made a statement that got me >wondering. He said "there's SQL embedded all throughout the Perl everywhere >(who does this?! oh my god, are they on crack?)". This comment got me >wondering about alternatives to embedding SQL in to the code of a program. >Alternatives I see are to use stored procedures which would limit one to >using a certain DB server (or to be proficient in many servers and write >stored procedures for all server flavors which would mean one is a very busy >Perl and SQL guru) or possibly storing the embedded SQL in some sort of >external file structure accessible via storable, XML::Simple or some other >means. I, as a crackhead, do embed my SQL into my modules. I've never liked the idea of a central SQL library... Too many dependencies. If I change one query in the library, I could end up breaking lots of modules using that query. I have, on occasion placed all the SQL into a %SQL global (since it's static). Then it get's shared by all the apache processes when the module loads. Rob -- "A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX."
Re: Apache::SimpleTemplate (don't do it!)
>hi, i'm sure many of us have had situations like this, >but that doesn't mean that everyone who wants to do >some templating is going to fall into the same trap >every time. The problem is that not every feature comes off looking like a trap. >- trivial to install and to use It's rare that I need to do anything more than 'perl Makefile.PL && make && make install' when I install modules. If I use CPAN.pm, it's even easier. Installation of any perl module trivial (under Un*x, at least). >- small disk footprint I can't remember the last time I had a "disk space" problem because of a perl module. It's not like we're talking about Megs of disk space (TT might come close). 2 gigs will hold all of RH 7.0 (including X) and any perl modules you could possibly want. >- small memory footprint At current memory prices (128 MB for $25), I consider this point very weak. I use about 300 modules within my system, and the total size of the httpd is 30 MB. On a system with 1 GB of RAM, I can run about 200 processes easily. Most people don't have 300 modules, so I suspect httpd to be much smaller. >- fast, with little overhead to begin with. You don't use a templating system because it's fast. You use it because it's faster to develop. It's the same reason people choose to use Perl instead of C. >- very basic non-syntax I'm a little confused by this one There are templating system like Mason that have their own tags ([+ +]) and systems like Text::Template that use style tags. Both are pretty easy for programmers to understand, but designers (the people using the templating system) will probably find Text::Template simpler and easier to learn and use. >- extensibility via sub-classing. This is notably where many templating systems come up short. I think TemplateToolkit provides the most flexibility in this area. Text::Template, while not sub-classable, is easily wrapped. I'm not trying to suggest that what you've written isn't "worthy." I'm only making a point about templating systems. If your goal is to write a templating system, you shouldn't just look at what already exists and strip out the stuff you feel isn't important. If you really want to help, you should consider contributing to existing templating systems to find the happy medium you're looking for. Robert Landrum -- "A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX."
Re: Apache::SimpleTemplate (don't do it!)
>Yes. Writing a templating system in Perl is trivial. Writing a >*useful* templating system in Perl is demonstratably hard. I too have written a templating system. About a year ago I wrote a simple module called dbq.pm. It performed database queries. Basically, you could mock up a simple html page, add some special dbq tags, and it would run queries against the database. I wrote it to see if I could write a simple version of ColdFusion It took 90 minutes to write on a saturday night. On monday morning, I made the mistake of showing it to my boss. He made it is personal quest to try to rewrite parts of our existing CGI system using this 90 minute version of ColdFusion. As his quest continued, he found that there were certain features that were not present. It was quickly made a "company project," and new features (such as the ability to interface with our existing widget and api modules) were added. Then we switched to using XHTML. Everything had to be compliant. We started using Expat. DBQ (now XML::DBQ) started core dumping mysteriously. We traced everything to a problems with the (then unstable) Expat libraries. So we rewrote the XML parser using native perl. Since we now had full control over the parser, we found we could add new features (like if else constructs and defines). Then we added the ability to execute internal perl functions (like substr). Our quest was still not over, and we continued to add more features. And it is now that we realize that we have written a system that is 3 times slower than CGI, 8 times slower than mod_perl, 10 times more difficult to read than perl, and is being used in about 45% of our site. The moral of this story is that using an existing templating system will save you more hours of coding, learning, debugging, upgrading, adding new features, and maintaining than you could possibly hope to account for when writing a "Simple" templating system. I hope this helps answer any questions about why you should not write your own templating system. Robert Landrum
