Re: Copying Apache/Mod_perl/perl installation
Ged == Ged Haywood [EMAIL PROTECTED] writes: [...] If I can use RPM under SCO Open Server 5.0.6, and it gives me perl with all the modules, Apache, and mod_perl, I 'd definitely go for that. Anyone used RPM to copy installation under SCO? [...] My approach is to build perl, Apache, mod_perl, etc. in development mirroring the directory heirarchy that will exist on the deployed platform. Once this is done, I can work within its confines through unit test. Consequently I've been able to simply tar/gzip this entire tree from some common root, drop it onto the install target, undo it all at the same root and have it function as expected. I thought I'd be pushing the limits of shared library compatibility and other arch. details as I'm developing on Solaris 7 and the deployment target is Solaris 8 ... however it has not failed me yet. YMMV. Peace.
Re: XML::RPC
Ciao! As has been pointed out in the past, the VERSION of a module does not necessarily reveal the module's maturity or robustness. This is particularly true for the RPC::XML module. I am using it in two production environments, in both client and modperl-enabled server modes with excellent results. It's dependency on the XML::Parser module has been a NO-OP for my Solaris8 deployment platforms. I am pleased with its overall performance, ease of use and robustness, as well as the author's continued support. YMMV. Peace. Eric == Eric Frazier [EMAIL PROTECTED] writes: Eric Hi, Thanks, the thing that scared me about RPC::XML was the Eric 0.37 version number :) Eric I will give it a serious try before I go to something like Eric SOAP. Eric Within RPC::XML: Eric Apache::RPC::Server - A subclass of RPC::XML::Server tuned Ericfor mod_perl Eric I didn't see this until now. :) Getting warm fuzzy feeling Eric now. Thanks again,
Re: Apache::DBI
Marty == Marty J Rogers [EMAIL PROTECTED] writes: Marty I had tried that, with the same result. (does Apache::DBI Marty overload the DBI methods?) Full error is as follows. Again, Marty any help is _highly_ appreciated. You must specify the full package name to the connect_on_it sub, as in Apache::DBI-connect_on_init(...) Peace.
Apache::RPC::Server questions
Ciao! Looking at RPC::XMl::Server and subsequently the Apache::RPC::Server subclass I see that methods are implemented via passing a code ref to a named or anonymous subroutine that implements the actual method logic. Given the persistent nature of perl in an Apache/modperl environment, is there any inherient problems this might cause in a complex method, other than those caused via bad modperl coding practices? The first thing I thought about is the dangers of closures and the potential for persistent variables and data between requests. Will the avoidance of using any type of globally scoped variables within this method defining subroutine be enough to avoid these types of problems? Does this method defining subroutine ever go out of scope during the life of a modperl process, therefore freeing lexicals and other local data and data structures? Do I need to do any explicite destruction of objects prior to exiting the subroutine, for example? I may need to make database accesses from within the method. Will Apache::DBI still work within this framework? The documentation indicates it is dangerous to change package namespace within the method defining subroutine. Does this apply to the 'use' or 'require' of modules within the subroutine as well? Frankly, I'm so used to writing the actual handler subroutine and supporting modules that I'm feeling a little out of my element given the method definition paradigm the RPC::XML::Server is introducing. Thanks for any information you might be able to provide on this matter. Peace.
Re: Suggestions on an XML-RPC Service using modperl?
Ciao! I'm on the modper digest list so pardon the delayed response to your input. Aaron == Aaron E Ross [EMAIL PROTECTED] writes: Aaron I've been working with a mod_perl based XML-RPC/SOAP Aaron service for a few months now and I thought I'd share some Aaron quick thoughts. Thanks! I'll take 'um. Aaron As long as you are _sure_ that you won't be writing data, Aaron in-memory will be fast and easy to code. if you use Aaron objects you can pretty easily build an interface Aaron encouraging programmers to avoid modifying shared data. Yes, I refuse to do *any* data arbitration between the localized portions of the data (if any?) and the remote or official copies of it. Copying it to a local store is meant to remove the access latency and availability of the data, although I have not yet determined there to be latency issues. There are however availability issues surround these databases. I agree, an OO interface to it will facilitate its use and certainly simplify any data format changes that are almost certain to take place over the life of the service itself. Aaron Aim for what you may need later, 5+ will be easy as long as Aaron you have some memory. I'm lobbying for excessive memory as we speak! Good point. Aaron I have found the Cache::Cache modules really easy to use, Aaron well written, documented and supported. MLDBM::Sync Aaron provides some locking, but if you really need concurrent Aaron access I would highly recommend BerkeleyDB, Aaron http://sleepycat.com/, nb this is _not_ DB_File. Mr. Turner also mentioned the Cache::* modules for this. I'm not really interested in locking the data in any way whatsoever. It's strictly read-only so I see no reason to have to manage read locks. Therefore concurrent access to an in-memory data store between all the modperl processes should be no problem, correct? Aaron You haven't explained the cacheing logic at all.. perhaps Aaron you don't need a cache? maybe just an object that reads Aaron from the data stores on startup? This is a good idea. It would eliminate the interim step of loading the data onto the local machines prior to bringing it into memory. I'm working on data access issues this week and want to be able to describe the data better as well as gain query access to it. Then I should be able to benchmark access and availability, my two primary concerns with the data. Aaron If you do need a cacheing layer that updates on some event Aaron or expiration, remember to seperate the cacheing logic and Aaron the storage as much as possible to be able to tune and to Aaron scale up later on. I'll keep this in mind. Aaron Why not write a simple object? I try to avoid tie's, b/c Aaron they are too magical for my taste, but i don't think Aaron there is any inherent overhead. The object description of the data seems to be a good way to go. I believe this will end up being the API I present to the handler for data access. I agree. Aaron I would recommend using SOAP::Lite for both XML-RPC and Aaron SOAP. While the code is unreadable, the author is Aaron responsive and helpful, and the switch from XML-RPC to SOAP Aaron couldn't be easier. You got the unreadable part right (c: Sorry. I've had occasion to use Randy Ray's RPC-XML module in the past and it functioned very well. He describes it as a reference implementation of the XML-RPC specification and does not attest to its effeciency or speed. I'll do some comparison shopping here with SOAP::Lite and see what comes out. Aaron Hope this helps, Aaron Thanks for your insight into this matter. I really appreciate your input. Peace.
Re: Suggestions on an XML-RPC Service using modperl?
Ciao! Jon == Jon Robison [EMAIL PROTECTED] writes: Jon As far as the cacheing goes, we have had extremely good luck Jon with IPC::ShareLite used to share info across mod_perl Jon processes. Have you compared this module to the Cache::* modules? I believe the Cache::SharedMemoryCache module provides a shared memory implementation, for example. I have had a few suggestions offered surrounding the use of the Cache::* modules which is why I ask. Thanks for your thoughts. Peace.
Re: Suggestions on an XML-RPC Service using modperl?
Ciao! I'm on the digest for this list, so pardon my delay in responding to everyone's comments. Chip == Chip Turner [EMAIL PROTECTED] writes: Chip Bruce W. Hoylman [EMAIL PROTECTED] writes: Ciao! I would like some input on an intranet web service I am currently in the process of designing, the core of which will be modperl on UN*X. Chip Excellent choice. This works quite well. Of course, like Chip others on this list, I might be a bit biased. I'm sort of sneaking this in the back door. Much of the development surrounding these new objectives is centered in the J2EE architecture. I'm taking a 'don't say much' approach until it's working and cranking out the data. Then I'll be able to meet any advances on architecture choices. It's not that perl/Apache is taboo here, just not looked upon as an implementation solution of choice. However it won't be the first time I have faced these pundits. Chip How often does the data change? How is it stored on the back Chip end? You may not need to cache anything if, say, you have a Chip decent SQL database on the backend. Caching never hurts, but Chip it isn't always necessary. The Cache::* modules may be of use Chip for this, though, should you still need it. You also might Chip want to consider not sharing the data in each process; the Chip complexity gained vs the memory lost by storing it in each Chip process may be a workable tradeoff. I probably would try it Chip first with no cache, then a per-process on-demand cache, then Chip finally a shared cache, in that order. I still have to determine the dynamic characteristics of the data in question. This certainly needs to be taken into account in any cacheing or local storage of the data. The remote data is Oracle-ized in some 7.x database instances. When I speak of cacheing I'm referring to taking remote data sources and making the local for some period of time, after which they must be refreshed and localized again. I don't believe the service can withstand the cost of remote database access and still be as streamlined as the requirements specify. However I will be going through a series of benchmarks to see just which data management approach is appropriate. I also am keen to the unavailability of these external, remote data sources. They seem to be 'down' at the most inopportune moments. In summation, data throughput and availability are the two most compelling reasons for considering a localized, and I emphasize READ-ONLY capture of the remote stores (there are two). Chip Five hits/second should be absolutely no problem. If you Chip expect slow clients, a mod_proxy in front of things Chip (http://perl.apache.org/guide) can help. This is a very interesting section of the guide. I recommend it to everyone simply for the sake knowing alternative configurations that include a modperl component. Chip There are a lot of options, but really, I would hold off on Chip deciding complicated caching schemes until you know what Chip throughput you get without them. Even then, I'd avoid Chip disk-based cache systems, instead preferring Cache::* if it Chip must be shared, or just global variables if it doesn't need to Chip be. This is a good point. I'm working on securing access to the data stores this week, so I should be able to measure throughput soon. Loading the in-memory stores direct from the data sources is a good idea, if necessary. This precludes any local storage of the data which precludes any refresh to disk logic, although I still will need to flush/fill memory on a regular basis. Thus I don't want to utilize per-process data stores, but rather a common shared memory represenetation that all the modperl processes can draw from Chip Can you be more specific about what the data looks like, where Chip it resides, and how expensive loading it is? I wouldn't worry Chip about optimization yet, unless you know beyond the shadow of a Chip doubt speed will be a problem. My hunch is you can do maybe Chip 50-100 hits/second on decent Intel hardware via the Frontier Chip modules, so I don't think performance will be a problem. This Chip is unverified, though; I really need to benchmark it sometime. Chip Maybe others have pushed Frontier to its speed limits? I'll be able to provide some numbers and the actual data representation later on this week. I agree on performance numbers. I'm getting awesome throuput now acording to ApacheBench, but that's only with my skeletal handler. As it I fill it out, I plan on benchmarking each significant piece of functionality for comparison purposes. Should be fun. Chip Chip Thanks so much for your insightful comments. I appreciate the time you took to respond to my queries. Peace.
Suggestions on an XML-RPC Service using modperl?
Ciao! I would like some input on an intranet web service I am currently in the process of designing, the core of which will be modperl on UN*X. The service itself is to access a couple of back end data stores given parameters received in an XML-RPC request, then return the results in an XML-RPC formated response. The data from the back end sources will be loaded into memory at service initialization, for fast access. The data is small enough and memory plentiful enough to allow this. That's pretty much it in terms of the high level data flow. It has to be relatively fast, OTO 5+ requests/sec. as a relative volumetric. I'm going to use modperl due to the embedded perl interpreter characteristics it provides, allowing initialization overhead to be incurred at startup. I also wish to use an in-memory, read-only hash structure shared across all modperl processes for access to the cached back end data, rather than making expensive calls to these stores for each request. Again, throughput is critical. I would like your thoughts on the cache management concept of the service. I'm looking at MLDBM::Sync as the mechanism for managing the filesystem representation of the in-memory hash content. What to manage the in-memory structure itself in terms of accessing its content? Is a Tie structure too expensive? I want to end up with a single structure accessible to all of the modperl processes, loaded at service startup. This service will ultimately be registered within a UDDI/SOAP framework, FYI. However this will not be in the first incarnation of the service itself. Thoughts and comments welcome. Obviously this is an early brainstorm (more like a drizzle) but I hope to get a few stimulating comments from this most excellent resource, the list. Peace.
Re: Apache::DBI and transactions
"Stas" == Stas Bekman [EMAIL PROTECTED] writes: Stas In general it is good practice to perform an explicit commit Stas or rollback at the end of every script. In order to avoid Stas inconsistencies in the database in case CAutoCommit is Stas IOff and the script finishes without an explicit rollback, Stas the CApache::DBI module uses a CPerlCleanupHandler to Stas issue a rollback at the end of every request. I believe this paragraph spells it out, to my satisfaction anyway. If a script exits without committing (or rolling back) a transaction that is currently in progress, the database remains in the uncommitted state. Thus any data modified by the script is not actually fully modified, just ready to be modified. Subsequent requests to the database would return inconsistent views of this data, i.e. views of the data prior to the transaction, but not necessarilly what the data will look like once the transaction is committed. The reasonable thing to do then, not knowing why a transaction might still open at this point in the logic flow, is to clean up in a non-destructive fashion when a script exists. If for example transaction still is open when a script exits, it is either a result of programmer, design or logic error, or something unexpected has occurred during the course of script execution which was not properly handled. Therefore instead of committing the transaction that contains potentially unknown consequences, get rid of it and put things back the way they were. In this case the idiom appears to be "better to do nothing now than to try and later undo something that was done unexpectedly", and I guess I would agree in this case. Interesting behavior ... I did not know Apache::DBI did this! Peace.
Re: debuggers
"Dave" == Dave Rolsky [EMAIL PROTECTED] writes:
Dave On Thu, 7 Dec 2000, martin langhoff wrote:
I wonder how do those hardcore guys that develop using handlers
debug. Mhhh. They must write 'perlfect' code, I guess, and/or
understand those cryptic debuggers ...
Dave I just do a lot of debugging via warn statements and looking
Dave at the error logs.
My BEGIN block looks like this. I realize IO is rather bulky, but I
like it and the environment I'm in isn't *that* busy where it makes a
significant impact.
BEGIN {
# Wash the PATH.
$ENV{'PATH'} = '/opt/gnu/bin:/usr/local/bin:/usr/bin';
$ENV{'CDPATH'} = '';
$ENV{'ENV'} = '';
use IO::File;
use CGI::Carp qw(carpout fatalsToBrowser carp);
use Savvy::Conf qw(:WWWBasic);
my $log = 1;
my $logfile = "/www/cgi-logs/cgi-log";
if ($log) {
my $LOG = IO::File-new(" $logfile") or
Savvy::Conf::cab("Unable to open $logfile for writing: $!\n");
# Dupe STDERR. Original is SAVEERR.
carpout($LOG);
}
}
Then I 'tail -f' the $logfile, the Apache server error_log, and watch
watever comes to the broswer due to the fatalsToBrowser. Works well for
me.
The '$r-log_reason' finds a home in my code as well.
Plus, I *always* use '-w' and '-T' and get them cleanly working during
development phases, although I shut them off for actual deployment.
Peace.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: debuggers
"Stas" == Stas Bekman [EMAIL PROTECTED] writes: Plus, I *always* use '-w' and '-T' and get them cleanly working during development phases, although I shut them off for actual deployment. Stas 1. You cannot use -T under mod_perl, you should use StasPerlTaintCheck Stas instead: http://perl.apache.org/guide/porting.html#Taint_Mode This is what I was referring to actually. However, there are many modules, such as Date::Manip, for example, that just will not load with taint checking turned on. In an intranet, it's not as big a deal as it certainly is in the 'real world'. But what can I do, short of rewritting the parts of the module that don't function in with checking on Stas 2. 'PerlTaintCheck On' is a must in production!!! not Stasdevelopment: Stas * http://www.gunther.web66.com/FAQS/taintmode.html Stas * perldoc perlsec Thanks for the input. Peace. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: debuggers
"Matt" == Matt Sergeant [EMAIL PROTECTED] writes:
Matt On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:
use IO::File;
use CGI::Carp qw(carpout fatalsToBrowser carp);
Matt Bye bye exception handling.
You mean eval{} block exception handling, or something else? What are
the technical specifics around this assertion?
Thanks! Maybe I'll learn something here, which is why I posted it in
the first place.
Peace.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
This debate has really hit some hot buttons. I love reading the exchanges as there are clearly some personal philosophies at work here. Ain't it great! "Michael" == Michael Robinton [EMAIL PROTECTED] writes: Michael Give a man a dump truck full of leggos, motors and gears Michael and you can build some really interesting stuff, give man Michael an end mill or a lathe and he can build a rocket ship to Michael the moon. You figure out which one is Weblogic and which Michael one is Apache-modperl :-) Doubtful. In my experience, these so-called enterprise solutions are just that ... a huge lathe, or whatever an end mill is. Their solution to even the most minute problem is to throw huge - I mean huge - application piece parts at it, hoping to bury it in the wizard technology of the moment. There is no other solution. You get it all or you get none of it. Or if you only want a part of the bulk, you still must sift through a mountain of installed crap. "What do you mean I need 1GB of disk and 500 MB of memory just to get an internet-enabled report queue manager?" Now maybe some feel better with a large enterprise application server or whatever staring over one's shoulder, but I prefer to build my solution in a way that I get only what I need. The rest can be called upon, installed if you will, when it is deemed necessary (by me, or by the needs of the environment), but otherwise only the necessary parts are present and in play. And I can determine what is necessary and when, not the vendor supplying the solution-of-all-solutions. Apache/mod_perl has enabled my team and I to craft finely detailed modules that I can apply to specific problems in my intranet environment. I can bring to the battle one, some, or all of mod_perl's intrinsics coupled with the vast CPAN, tightly woven with modules of An enterprise-size solution is rarely a viable answer to an enterprise-size problem. JM.02W Peace. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
"Matthew" == Matthew Kennedy [EMAIL PROTECTED] writes: Matthew I don't know where you got the 1GB disk requirement from? Matthew Even Weblogic's download is only 43Mb, jBoss' is about Matthew 6Mb. The Java Platform is somewhere between that. Your Matthew compiled enterprise app might only be 300Kb (and not just a Matthew "report queue manager"). And 500Mb of memory? That's Matthew tuppence in the server world anyway. This happens to be minimum numbers for working with a particular Application Server marketed by a well-known database vendor by the name of Oracle Corp. Matthew I think it's exciting to think what an n-tier framework in Matthew Perl might look like. IMHO, it should be more than just the Matthew outgrowth of CPAN's contents. I agree, but I should be able to expand and contract this middle tier monster in a very similiar fashion. Hey, I want some functionality, get it, configure it, install use it, derive from it, whatever. On the other hand, if I don't want, I can wipe it out without horking up the entire system. A degree of independence, sort of like the model driving a light weight operating system, where the base is a skeleton framework and I can plug in services, and uplug them, as necessary. I can create said services from existing ones via extension, or scratch together my own for a particular need. So CPAN has the concept just right. Matthew Sounds almost like you're talking about "enterprise" being Matthew a "company"? I know you can't be though... right? Yeah, right. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resurrection of startup SIGSEGV with latest CVS snapshot?
Hello, Doug -- Thanks for the reply. I have already applied this patch. The backtrace I provided was producted by an httpd executable with the perl_util.c patch already applied. The perl 5.6 patch from p5p was also in effect. The combined patches worked for the earlier CVS snapshot of modper, as I mentioned. However today's snapshot ressurects the problem. So, in essence the perl_util.c patch is ineffective in this case.
Resurrection of startup SIGSEGV with latest CVS snapshot?
Ciao! With the latest modperl from CVS, all tests pass during build/test phase. However it coredumps when used with my http.conf/startup.pl files. An earlier CVS release of modperl (modperl_2911162240) functions as expected. Both modperl revisions have the perl_util.c patch applied and perl 5.6 has been patched based on information from p5p regarding cop.h and threads. These patches solved an earlier SIGSEGV problem (similiar to this one?). The particulars are included below. Thanks for any insight. modperl_20001003161843 apache-1.3_2911161201 (gdb) run -X -f /www/etc/httpd/httpd.conf -d /tmp Starting program: /www/sbin/httpd -X -f /www/etc/httpd/httpd.conf -d /tmp [New LWP 1] [New LWP 2] [New LWP 3] [New LWP 4] Program received signal SIGSEGV, Segmentation fault. 0xe0cd8 in Perl_gv_init (gv=0x22ddd0, stash=0x1f9880, name=0x185f20 "Location", len=8, multi=2) at gv.c:106 106 GvFILE(gv) = CopFILE(PL_curcop) ? CopFILE(PL_curcop) : ""; (gdb) bt #0 0xe0cd8 in Perl_gv_init (gv=0x22ddd0, stash=0x1f9880, name=0x185f20 "Location", len=8, multi=2) at gv.c:106 #1 0xe22f8 in Perl_gv_fetchpv (nambeg=0x185f20 "Location", add=2, sv_type=11) at gv.c:681 #2 0x44928 in perl_section_hash_init (name=0x185f20 "Location", dotie=0) at perl_config.c:1628 #3 0x44d48 in perl_section (parms=0xefffba78, dummy=0x1d5708, arg=0x0) at perl_config.c:1731 #4 0x44aa8 in perl_section_self_boot (parms=0xefffba78, dummy=0x1d5708, arg=0x290e58 "/www/startup.pl") at perl_config.c:1653 #5 0x41d00 in perl_cmd_require (parms=0xefffba78, dummy=0x1d5708, arg=0x290e58 "/www/startup.pl") at perl_config.c:638 #6 0xa21e8 in invoke_cmd (cmd=0x1bf600, parms=0xefffba78, mconfig=0x1d5708, args=0xefff998b "") at http_config.c:916 #7 0xa28b0 in ap_handle_command (parms=0xefffba78, config=0x1d5580, l=0xefff9970 "PerlRequire /www/startup.pl") at http_config.c:1028 #8 0xa2990 in ap_srm_command_loop (parms=0xefffba78, config=0x1d5580) at http_config.c:1042 #9 0xa3018 in ap_process_resource_config (s=0x1d4440, fname=0x1c2a30 "/www/etc/httpd/httpd.conf", p=0x1d4418, ptemp=0x1dc418) at http_config.c:1230 #10 0xa3c40 in ap_read_config (p=0x1d4418, ptemp=0x1dc418, confname=0x1c2a30 "/www/etc/httpd/httpd.conf") at http_config.c:1513 #11 0xb2bdc in main (argc=6, argv=0xefffbc4c) at http_main.c:4974 (gdb) quit Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=solaris, osvers=2.6, archname=sun4-solaris uname='sunos savvy 5.6 generic_105181-21 sun4u sparc ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='gcc', optimize='-g -O', gccversion=2.95.2 19991024 (release) cppflags='-fno-strict-aliasing -I/opt/gnu/include -I/usr/local/include' ccflags ='-fno-strict-aliasing -I/opt/gnu/include -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DDEBUGGING' stdchar='unsigned char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, usemymalloc=y, prototype=define Linker and Libraries: ld='gcc', ldflags ='-L/opt/gnu/lib -L/usr/local/lib -L/lib -L/usr/lib -L/usr/ccs/lib ' libpth=/opt/gnu/lib /usr/local/lib /lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -lgdbm -ldb -ldl -lm -lc -lcrypt -lsec libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/opt/gnu/lib -L/usr/local/lib -L/lib -L/usr/lib -L/usr/ccs/lib' Characteristics of this binary (from libperl): Compile-time options: DEBUGGING USE_LARGE_FILES Built under solaris Compiled at Sep 12 2000 16:06:55 %ENV: PERLROOT="/opt/gnu/lib/perl5/5.6.0" PERL_ORACLE_HOME="/db02/orasw/app/oracle/product/8.1.6" @INC: /opt/gnu/lib/perl5/5.6.0/sun4-solaris /opt/gnu/lib/perl5/5.6.0 /opt/gnu/lib/perl5/site_perl/5.6.0/sun4-solaris /opt/gnu/lib/perl5/site_perl/5.6.0 /opt/gnu/lib/perl5/site_perl/5.005/sun4-solaris /opt/gnu/lib/perl5/site_perl/5.005 /opt/gnu/lib/perl5/site_perl .
Re: segfaulting httpd :(
"Ben" == Ben Turner [EMAIL PROTECTED] writes: Ben this afternoon i compiled a fresh httpd (apache 1.3.12), Ben together with mod_perl 1.24. i'm on Solaris 8, running perl Ben 5.6.0. Sounds like what I happened to just go through, finding perl 5.6.0 as the (known) culprit. Go to: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-06/msg00200.html and apply the supplied patch. It fixed my SIGSEGVs immediately. HTHYO. Peace.
Re: modperl startup dumps core; trace included
"Doug" == Doug MacEachern [EMAIL PROTECTED] writes: Doug looks like one of the 5.6.0 bugs, the Perl patch has been Doug posted here (don't have it handy), here's one that has also Doug helped on the mod_perl side, does it fix the problem for you? Applying the perl_util.c patch you provided and attempting to load my module from startup.pl as before results in the same problem. However having rebuilt my perl 5.6.0 with '-DDEBUGGING', I get the following stack trace of the SIGSEGV, with much better symbol output: Starting program: /www/sbin/httpd -X [New LWP 1] [New LWP 2] [New LWP 3] [New LWP 4] Program received signal SIGSEGV, Segmentation fault. 0xdea34 in Perl_gv_init (gv=0x4f1fb0, stash=0x1e3600, name=0x183f28 "Location", len=8, multi=2) at gv.c:106 106 GvFILE(gv) = CopFILE(PL_curcop) ? CopFILE(PL_curcop) : ""; (gdb) where #0 0xdea34 in Perl_gv_init (gv=0x4f1fb0, stash=0x1e3600, name=0x183f28 "Location", len=8, multi=2) at gv.c:106 #1 0xe0054 in Perl_gv_fetchpv (nambeg=0x183f28 "Location", add=2, sv_type=11) at gv.c:681 #2 0x44720 in perl_section_hash_init (name=0x183f28 "Location", dotie=0) at perl_config.c:1598 #3 0x44b40 in perl_section (parms=0xefffbab8, dummy=0x1d0d80, arg=0xefff99b6 "") at perl_config.c:1701 #4 0xa1120 in invoke_cmd (cmd=0x1bcda0, parms=0xefffbab8, mconfig=0x1d0d80, args=0xefff99b6 "") at http_config.c:808 #5 0xa2198 in ap_handle_command (parms=0xefffbab8, config=0x1d0bf8, l=0xefff99b0 "Perl") at http_config.c:1028 #6 0xa2278 in ap_srm_command_loop (parms=0xefffbab8, config=0x1d0bf8) at http_config.c:1042 #7 0xa2900 in ap_process_resource_config (s=0x1cfab8, fname=0x1d1a38 "/www/etc/httpd/httpd.conf", p=0x1cfa90, ptemp=0x1d3ac0) at http_config.c:1230 #8 0xa3528 in ap_read_config (p=0x1cfa90, ptemp=0x1d3ac0, confname=0x1c02c0 "etc/httpd/httpd.conf") at http_config.c:1513 #9 0xb24c4 in main (argc=2, argv=0xefffbc8c) at http_main.c:4974 Any other ideas? I will next use the p5p patch you alluded to and see if it has any effect. Thanks for your help. Peace.
Re: modperl startup dumps core; trace included
Rebuilding perl 5.6.0 with the p5p patch solved the SIGSEGV problem. Thanks for the 'point'. Peace.
'make test' error with CVS modperl
Having downloaded the latest CVS snapshot of modperl, using my standard APACI config parameters to configure and compile, it compiles to completion without error. 'make test' however returns the following error when attempting to start the test httpd process: letting apache warm up...[Tue Aug 22 10:46:31 2000] [error] Can't load '/opt/gnu/lib/perl5/5.00503/sun4-solaris/auto/IO/IO.so' for module IO: ld.so.1: /www/src/apache-1.3_2817161200/src/httpd: fatal: relocation error: file /opt/gnu/lib/perl5/5.00503/sun4-solaris/auto/IO/IO.so: symbol main: referenced symbol not found at /opt/gnu/lib/perl5/5.00503/sun4-solaris/DynaLoader.pm line 169. I have IO-1.20 installed, and have had it there for a long time. Here are the particulars for perl: Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=solaris, osvers=2.6, archname=sun4-solaris uname='sunos savvy 5.6 generic_105181-15 sun4u sparc ' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='gcc', optimize='-O', gccversion=2.95.2 19991024 (release) cppflags='-I/usr/local/include -I/opt/gnu/include' ccflags ='-I/usr/local/include -I/opt/gnu/include' stdchar='unsigned char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 alignbytes=8, usemymalloc=y, prototype=define Linker and Libraries: ld='gcc -B/usr/ccs/bin/', ldflags =' -L/usr/local/lib -L/opt/gnu/lib' libpth=/usr/local/lib /opt/gnu/lib /lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -lgdbm -ldb -ldl -lm -lc -lcrypt libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib -L/opt/gnu/lib' Characteristics of this binary (from libperl): Built under solaris Compiled at Jan 26 2000 13:27:51 %ENV: PERLROOT="/opt/gnu/lib/perl5/5.00503" PERL_ORACLE_HOME="/db02/orasw/app/oracle/product/8.1.6" @INC: /opt/gnu/lib/perl5/5.00503/sun4-solaris /opt/gnu/lib/perl5/5.00503 /opt/gnu/lib/perl5/site_perl/5.005/sun4-solaris /opt/gnu/lib/perl5/site_perl/5.005 . I have done this process numerous times in the past with no problems at all. Now all of a sudden I get the relocation error with IO. I'm not sure why. Any thoughts/suggestions? Peace.
Re: canned footers
Have you looked at Apache::Sandwich from CPAN? It is easy to implement and I have used it for awhile now to add confidentiality headers and footers to pages in a small to medium site. cpan m /Apache::Sandwich/ Module id = Apache::Sandwich CPAN_USERID VKHERA (Vivek Khera [EMAIL PROTECTED]) CPAN_VERSION 2.04 CPAN_FILEV/VK/VKHERA/Apache-Sandwich-2.04.tar.gz MANPAGE Apache::Sandwich - Layered document (sandwich) maker INST_FILE/opt/gnu/lib/perl5/site_perl/5.005/Apache/Sandwich.pm INST_VERSION 2.04 It could most certainly be use as a basis for your needs and requirements. Peace.
Re: Hang in $r-print w/ POST
"heddy" == heddy Boubaker [EMAIL PROTECTED] writes:
I liked the CGI functions to generate HTML ... it seems there is no
simple way to tell CGI module not to eat POST data. HTML::StickyForms
could be an option for forms ... the others (Template, Mason) are not
for what I'm trying to do. I'm just looking for a simple but complete
html generator (instead of hard coding all html tags in my code),
does such a beast exists or have I to write my own?
From the CGI docs:
To create an empty query, initialize it from an empty string
or hash:
$empty_query = new CGI("");
-or-
$empty_query = new CGI({});
This gives you a CGI object that you can use to generate your html and
leave the query content alone.
HTHYO.
Peace.
tainted operation in Apache::Session::Lock::File
* Server Version: Apache/1.3.13-dev (Unix) mod_perl/1.24_01-dev
* perl, version 5.005_03 built for sun4-solaris
* SunOS 5.6
* Apache::Session 1.5
* Apache::Session::Lock::File 1.00
With taint checking turned on in my modperl server, as in:
PerlTaintCheck Off
PerlWarn Off
PerlFreshRestart Off
using the Apache::Session::File causes Apache::Session::Lock::File to
croak on the second access to the session file with a message in my
error_log stating:
[Thu Jun 8 21:15:03 2000] [error] access to /TS/ failed for XX.XX.XX.XX, reason:
Could not access session storage: Insecure dependency in open while running with -T
switch at /opt/gnu/lib/perl5/site_perl/5.005/Apache/Session/Lock/File.pm line 62.
The line of code in my handler that is outputing this message is:
eval {tie %$session, 'Apache::Session::File', $sesid, $SESSOPTS};
if ($@) {
$r-log_reason("Could not access session storage: $@", $r-uri);
return SERVER_ERROR;
}
and finally, the options passed to tie() are:
%SESSOPTS = {'Directory' = '/somepath/sessions',
'LockDirectory' = '/pathtolocks/sessions',
'Transaction' = 1};
permissions on these two directories are:
drwxrwx--- 2 nobody nobody 512 Jun 8 21:27 /somepath/sessions/
drwxrwx--- 2 nobody nobody 512 Jun 8 21:28 /pathtolocks/sessions/
where nobody.nobody are the user/group of the httpd processes.
The file is initially created, along with its correspond lock file, but
a second attempt to tie() to the existing session file returns the taint
error. Disabling taint checking in the server allows the session logic
to proceed without error, by the way. I would prefer not to run in this
mode, however.
Having exhausted my understanding of tainted data, I'm hoping I can get
some hints from this list.
Thanks for your attention.
Peace.
Re: CGI/mod_perl strangeness...
"Trevor" == Trevor Phillips [EMAIL PROTECTED] writes: Trevor Thing is, this is from an Apache Perl module using mod_perl, Trevor not from a CGI using CGI.pm (as this line is printed to Trevor stderr when you supposedly run a CGI from the command Trevor prompt). A code clip would help ... Otherwise, to get CGI.pm to prompt for values, you must be running in '-debug' mode. Try using the '-no_debug' pragma and see if the condition persists: use CGI qw/-no_debug/; Peace.
Re: Questions about Apache::Session
"Edgardo" == Edgardo Szulsztein [EMAIL PROTECTED] writes: Edgardo Then, I tried to use FileStore, and it worked Edgardo fine. However, it stores the sessions files in the /tmp Edgardo directory. How could I change the location of the sessions Edgardo file in the httpd.conf file? Good move. Get it working via FileStore, then get the database version of your session handling going. As for the session file storage, set the SESSION_FILE_DIRECTORY variable, and/or use a 'EMBPERL_SESSION_ARGS "Directory=/web/sessions"'. I threw both into my httpd.conf, which looks like this by the way: PerlSetEnv EMBPERL_SESSION_CLASS Embperl PerlSetEnv SESSION_FILE_DIRECTORY /web/sessions PerlSetEnv EMBPERL_SESSION_CLASSES "FileStore NullLocker" PerlSetEnv EMBPERL_SESSION_ARGS "Directory=/web/sessions" PerlSetEnv EMBPERL_COOKIE_PATH "/" FilesMatch ".*\.e(pl|html)$" PerlSetEnv EMBPERL_OPTIONS 16535 SetHandler perl-script PerlHandler HTML::Embperl Options ExecCGI PerlSendHeader Off /FilesMatch YMMV. Peace.
Re: Q: DBMS update framework for use within Apache::DBI?
"Gunther" == Gunther Birznieks [EMAIL PROTECTED] writes: Gunther This first criteria seems a tad odd to me. What business Gunther scenario is there for this? Gunther To me, when a user issues an update they expect that the Gunther record exists. In a way, if the record does NOT exist, then Gunther you are really going against your rule #2. That is, if they Gunther issue an update and the record no longer exists, then that Gunther is also a change to the record that someone did (a Gunther deletion) and you are effectively overriding someone elses Gunther deletion. The framework is to support an intranet time tracking application. The business rules of the system dictate there are no deletions of previously submitted time ... only inserts/updates. Therefore I can say without question that an existing time record will *always* exist (a modify), albeit in a potentially 'dirty' state (rule #2). Furthermore, if a particular time period has not been accounted for, i.e. no time record has been previously submitted, a default time record will be presented for modification, and subsequent submission (an insert). This is seamless to the client requesting the period. If there is no default time record available, then a 0-hour time record is presented for modification/submission (also an insert). Gunther An application which implements #2 and is accelerated when Gunther used with mod_perl (Apache::Registry) and Apache::DBI is Gunther our latest version of WebDB. You may download a copy at Gunther http://www.extropia.com/ and click on download button at Gunther the top upper right)... Thank you for the pointer. I will *gleefully* investigate its offerings. | Hope this helps, | Gunther I'll let you know ... Peace.
Q: DBMS update framework for use within Apache::DBI?
Ciao! I am searching for the makings of a framework built around or within mod_perl/Apache::DBI that supports the consistent update of a record within a database. Primarily I am wanting to ensure read/write integrity between database accesses by the web client, meaning I wish to ensure the record about to be updated meets the following criteria: 1) It exists. If it does not, perform an insert instead 2) If it exists, check that it is unchanged from the time the web client first retrieved it for update. If it has changed, throw an exception. I do not want a "last update wins" situation. This is being done in an mod_perl/embperl/Apache::DBI environment. Suggestions or pointers to additional information would be greatly appreciated. Peace.
Re: ANNOUNCE: Apache-TicketAccess 0.10
"Michael" == Michael Schout [EMAIL PROTECTED] writes: Michael Okay. I guess I am at a loss as to what this module should Michael be named then. It is heaily based on the TicketAccess Michael system in the modperl book. It is a ticket based Michael authentication system. Michael Maybe Apache::AuthTicket? Michael Does anyone have any suggestions? I was thinking AuthTicket also. That is my vote.
Re: [RareModules] new Apache::Status features (Memory Usage)
I had to add a 'Use B::TerseSize' to my startup.pl in order to get the right stuff available. Otherwise, I was getting: [Mon Feb 7 12:00:38 2000] [error] Undefined subroutine B::TerseSize::package_size called at /opt/gnu/lib/perl5/site_perl/5.005/sun4-solaris/Apache/Status.pm line 375. Excellent information though. Peace.
Ahhh! Too many Cookie modules ...
There are three CPAN modules that seem to want to compete for my Cookie module attention: Apache-Cookie-0.1: installs: site_perl/5.005/Apache/Cookie.pm site_perl/5.005/CGI/Cookie.pm unlinks: perl5/5.00503/CGI/Cookie.pm site_perl/5.005/sun4-solaris/Apache/Cookie.pm libapreq-0.31: installs: site_perl/5.005/sun4-solaris/Apache/Cookie.pm unlinks: site_perl/5.005/Apache/Cookie.pm CGI:installs: perl5/5.00503/CGI/Cookie.pm unlinks: site_perl/5.005/CGI/Cookie.pm It looks like Apache-Cookie-0.1 is the odd-man-out as the other two modules each uninstall one of its components. Or the other way around, depending on the order of install. I take it this is no longer a viable module ... or not? Just checking. Peace.
Re: Apache::Sandwich and SSI problems
"Shay" == Shay Mandel [EMAIL PROTECTED] writes:
Shay #
Shay # To use server-parsed HTML files
Shay #
Shay AddType text/html .shtml AddHandler server-parsed .shtml
Shay AddHandler server-parsed .html
Shay Files ~ "\.s{0,1}html$"
Shay SetHandler perl-script
Shay PerlHandler Apache::Sandwich
Shay # use these documents as header and footer
Shay PerlSetVar HEADER /.includes/header2.shtml PerlSetVar
Shay FOOTER /.includes/footer.shtml
Shay # parse ssi after sandwiching the page
Shay PerlSetVar SandwichHandler server-parsed
Shay # Options Includes # shayman - it doesn't seem to work
Shay /Files
Try using a different file suffix for the files to be handled by
Apache::Sandwich. Something like this works for me:
FilesMatch "\.brc$"
SetHandler perl-script
PerlHandler Apache::Sandwich
/FilesMatch
Then for various directories, I have the following:
Location /Unix
PerlSetVar HEADER /includes/brc/unix_header.shtml
PerlSetVar FOOTER /includes/brc/general_trailer.shtml
/Location
Note the 'shtml' suffix is handled as:
AddType text/x-server-parsed-html .shtml
FilesMatch ".*\.shtml$"
SetHandler perl-script
PerlSendHeader Off
Options ExecCGI
PerlHandler Apache::SSI
/FilesMatch
Everything in HEADER and FOOTER is parsed as expected. I'm opting to
use the Apache::SSI module as opposed to the mod_ssi, but it should not
make a difference.
HTHYO.
Peace.
