Re: RFC: Apache::Carp - Error Handling under mod_perl
On Fri, 1 Dec 2000, Gunther Birznieks wrote: The other thing that worries me is that even if you sneak the code back into the PageKit hierarchy you are still not doing everything Lincoln is doing to help deal with eval issues. This is a particularly thorny problem (and I suspect part of the reason why Matt wants CGI::Carp to die ... no pun intended). The reason I want it to die is that it doesn't deal with the eval issues. It may try to. But it doesn't succeed. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache User Creation
Hi, Are there any APIs available in Apache modperl which can be used to create Apache users in Perl/CGI scripts? Are there any ways (I mean through APIs) to delete these created Apache users and modify the passwords of these Apache users? We would appreciate a lot of help in this area. If this is not the right forum pertaining to this discussion, then could you send me the e-mail address of the forum where I can pose my queries? Thanks Best Regards, Manhar Goindi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing a file's UID from within an Apache module?
On Wed, 29 Nov 2000, [EMAIL PROTECTED] wrote: Any ideas about the best way to change the permissions and UID? Create an external minimum perl script with the SUID bit set and with root as it's owner. Use this script to change the file permissions. See you, -- Godoy. [EMAIL PROTECTED] Departamento de Publicações Conectiva S.A. Publishing Department Conectiva Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to use specified NIC
I have an application where incoming requests are handled by a gateway that translates the requests and sends them on to the intranet, receives the response, changes the links and sends the answer to the client. When I do the Intranet request (using LWP::UserAgent), I want to specify which network interface to use, so that the call isn't transfereed to the internet domain. Is this possible using som mod-perl magic? Jonas Nordstrom Sigma Exallon Information AB - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antwort: RFC: DBI::Prof
On Fri, Dec 01, 2000 at 02:37:47AM +0100, Stas Bekman wrote: It would be much easier for Tim to do it from the inside than any of us doing the overloading hacking, but that's up to Tim to decide when if ever this should go in :) Things are changing for the better workwise now and I hope to get back to regular DBI and DBD::Oracle (and Oracle::OCI) work early next year. Meanwhile, I'll happily guide someone who's willing and mostly able to create a patch for DBI internals. It's shouldn't be too hard. Tim. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to use specified NIC
Jonas Nordström wrote: I have an application where incoming requests are handled by a gateway that translates the requests and sends them on to the intranet, receives the response, changes the links and sends the answer to the client. When I do the Intranet request (using LWP::UserAgent), I want to specify which network interface to use, so that the call isn't transfereed to the internet domain. Is this possible using som mod-perl magic? I you're worried about where your network packets go I think this is not a modperl issue. You have already configured your routes so I don't see where is your problem here. -- - frankie - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: controling POST input with mod_perl
Hi, thank you for your help. Stas Bekman [EMAIL PROTECTED] writes: On 28 Nov 2000, Alexander Haeckel wrote: I want to control the way a CGI program works by modifying the parameters passed to it within a FixupHandler. For GET requests everything works fine. But for POST requests the parameters seem to be deleted after reading them. If the CGI program is a Perl script I get the parameters within $r-pnotes to a modified Apache::PerlRun.pm as PerlHandler to solve the problem. http://perl.apache.org/guide/snippets.html#Convert_a_POST_Request_into_a_GE http://perl.apache.org/guide/snippets.html#Redirect_a_POST_Request_Forward http://perl.apache.org/guide/snippets.html#Reading_POST_Data_then_Redirect I already knew these snippets before my posting. But I think they don't fit my problem, because some of the scripts (not written by me) I have to maintain behave differently depending if the request was GET or POST. So I can't simply transform the POST requests into GET requests. One of the requirements I've got by my boss is to avoid bigger modifications to third party scripts to do not restrict upgradability, so I can't simply change the script. Is there a way to use mod_perl to filter POST data, that has been sent to a binary program, that expects a POST request? Thanks in advance, Alexander Haeckel -- There never was a good war or a bad peace. -- B. Franklin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache + mod_perl + mod_ssl + mod_frontpage on Solaris 2.7
Hi, I'm trying to set up apache_1.3.14 with mod_frontpage-1.4.1-1.3.14, mod_perl-1.24_01, mod_ssl-2.7.1-1.3.14 on a Sun Ultra 60 with Solaris 2.7, using gcc 2.95.1, perl 5.6.0. I assemble the pieces in this order: - Frontpage Extensions - mod_ssl - mod_frontpage - mod_perl - Apache (with test certificate) Compilation seems to run without problems, but I can't get it to run afterwards: Sometimes the httpds are started, but crash with a segmentation fault when they receive a request, sometimes they crash right after they are started by apachectl, without a trace in the logfiles (at Loglevel debug!). Without mod_perl (only mod_ssl, mod_frontpage), everything was fine, that's why I'm posting to this list. Can anyone give me a hint what went wrong here? May it be a 32/ 64- Bit problem, wrong libraries, or whatever? Thanks for your support! Ciao, Joerg -- \ _)\ ( \ \ Joerg Reuter ... Rechnerbetreuung C-Lab Paderborn \ \05251-606051, [EMAIL PROTECTED], www.stachelig.de\ \ _) \( \ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache User Creation
Manhar, HTTPD-User-Manage is exactly what you're looking for. Get it from CPAN at: http://www.cpan.org/modules/by-authors/id/L/LD/LDS/HTTPD-User-Manage-1.54.tar.gz -Adi Manhar Goindi wrote: Hi, Are there any APIs available in Apache modperl which can be used to create Apache users in Perl/CGI scripts? Are there any ways (I mean through APIs) to delete these created Apache users and modify the passwords of these Apache users? We would appreciate a lot of help in this area. If this is not the right forum pertaining to this discussion, then could you send me the e-mail address of the forum where I can pose my queries? Thanks Best Regards, Manhar Goindi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache + mod_perl + mod_ssl + mod_frontpage on Solaris 2.7
Hi Joerg, I have essentially the same mix functioning for several months on Digital Unix. The assembly order was: openssl mod_ssl mod_perl frontpage apply frontpage patch to apache apache I guess the order of the patches affects the result if a 'following' patch is made after a line that was already modified by a 'previous' patch (in the list of assembly, that is). Hope it helps. Rafael Caceres Information Systems Manager Corporacion Aceros Arequipa S.A. At 03:39 PM 12/1/00 +0100, you wrote: Hi, I'm trying to set up apache_1.3.14 with mod_frontpage-1.4.1-1.3.14, mod_perl-1.24_01, mod_ssl-2.7.1-1.3.14 on a Sun Ultra 60 with Solaris 2.7, using gcc 2.95.1, perl 5.6.0. I assemble the pieces in this order: - Frontpage Extensions - mod_ssl - mod_frontpage - mod_perl - Apache (with test certificate) Compilation seems to run without problems, but I can't get it to run afterwards: Sometimes the httpds are started, but crash with a segmentation fault when they receive a request, sometimes they crash right after they are started by apachectl, without a trace in the logfiles (at Loglevel debug!). Without mod_perl (only mod_ssl, mod_frontpage), everything was fine, that's why I'm posting to this list. Can anyone give me a hint what went wrong here? May it be a 32/ 64- Bit problem, wrong libraries, or whatever? Thanks for your support! Ciao, Joerg -- \ _)\ ( \ \ Joerg Reuter ... Rechnerbetreuung C-Lab Paderborn \ \05251-606051, [EMAIL PROTECTED], www.stachelig.de\ \ _) \( \ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing a file's UID from within an Apache module?
I'd put it someplace that is only accessible to the web user if you're going to do that. - Original Message - From: "Jorge Godoy" [EMAIL PROTECTED] To: "George Sanderson" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, December 01, 2000 5:22 AM Subject: Re: Changing a file's UID from within an Apache module? On Wed, 29 Nov 2000, [EMAIL PROTECTED] wrote: Any ideas about the best way to change the permissions and UID? Create an external minimum perl script with the SUID bit set and with root as it's owner. Use this script to change the file permissions. See you, -- Godoy. [EMAIL PROTECTED] Departamento de Publicações Conectiva S.A. Publishing Department Conectiva Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antwort: RFC: DBI::Prof
On Fri, 1 Dec 2000, Tim Bunce wrote: On Fri, Dec 01, 2000 at 02:37:47AM +0100, Stas Bekman wrote: It would be much easier for Tim to do it from the inside than any of us doing the overloading hacking, but that's up to Tim to decide when if ever this should go in :) Things are changing for the better workwise now and I hope to get back to regular DBI and DBD::Oracle (and Oracle::OCI) work early next year. You said that at TPC :-) -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antwort: RFC: DBI::Prof
On Fri, Dec 01, 2000 at 09:48:34AM +, Matt Sergeant wrote: On Fri, 1 Dec 2000, Tim Bunce wrote: On Fri, Dec 01, 2000 at 02:37:47AM +0100, Stas Bekman wrote: It would be much easier for Tim to do it from the inside than any of us doing the overloading hacking, but that's up to Tim to decide when if ever this should go in :) Things are changing for the better workwise now and I hope to get back to regular DBI and DBD::Oracle (and Oracle::OCI) work early next year. You said that at TPC :-) Yeah, well... there are plans and there are plans :) I recently gave notice to the company that I've been Technical Director of for many years that I'll be leaving in March 2001. Such big changes of direction take time to work up to and work out smoothly. I am specifically rearranging things so I have time for DBI related work. Tim. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antwort: RFC: DBI::Prof
Tim Bunce wrote: On Fri, Dec 01, 2000 at 09:48:34AM +, Matt Sergeant wrote: On Fri, 1 Dec 2000, Tim Bunce wrote: On Fri, Dec 01, 2000 at 02:37:47AM +0100, Stas Bekman wrote: It would be much easier for Tim to do it from the inside than any of us doing the overloading hacking, but that's up to Tim to decide when if ever this should go in :) Things are changing for the better workwise now and I hope to get back to regular DBI and DBD::Oracle (and Oracle::OCI) work early next year. You said that at TPC :-) Yeah, well... there are plans and there are plans :) I recently gave notice to the company that I've been Technical Director of for many years that I'll be leaving in March 2001. Such big changes of direction take time to work up to and work out smoothly. I am specifically rearranging things so I have time for DBI related work. Very interesting. Although a bit OT, but I am sure everyone is interested, what changes are you planning for DBI ? Greg Tim. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antwort: RFC: DBI::Prof
On Fri, Dec 01, 2000 at 12:23:26PM +, Greg Cope wrote: Tim Bunce wrote: Although a bit OT, but I am sure everyone is interested, what changes are you planning for DBI ? There's a ToDo file in the dist. I've probably a few others rattling around in my head. Tim. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Order of Installation!!!
Hi all, I have installed on my machine the following modules: apache 1.3.12-2 mod_perl 1.21-10 DBI 1.13-1 DBD::Oracle 1.03 Apache::DBI 0.86-1 The problem is that when I run a perl script under mod_perl, the response time is almost the same than the response time of the same script being ran without the mod_perl module. And I know that mod_perl was correctly installed. Another problem is that I can not open database connections when the WWW server starts because happen an error in the child processes of the apache. I think can there is some problem in the installation or configuration of the modules. Did the order for installing of the modules do any difference? If someone help me will be very appreciated. Thanks... -- Edmar Edilton da Silva Bacharel em Ciência da Computacão - UFV Mestrando em Ciência da Computacão - UNICAMP
Re: Order of Installation!!!
It's not enough to just install the modules. Did you configure the httpd.conf with mod_perl as explained in the documentation? On Fri, Dec 01, 2000 at 03:40:45PM -0200, Edmar Edilton da Silva wrote: Hi all, I have installed on my machine the following modules: apache 1.3.12-2 mod_perl 1.21-10 DBI 1.13-1 DBD::Oracle 1.03 Apache::DBI 0.86-1 The problem is that when I run a perl script under mod_perl, the response time is almost the same than the response time of the same script being ran without the mod_perl module. And I know that mod_perl was correctly installed. Another problem is that I can not open database connections when the WWW server starts because happen an error in the child processes of the apache. I think can there is some problem in the installation or configuration of the modules. Did the order for installing of the modules do any difference? If someone help me will be very appreciated. Thanks... -- Edmar Edilton da Silva Bacharel em Ciência da Computacão - UFV Mestrando em Ciência da Computacão - UNICAMP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Order of Installation!!!
-Original Message- From: Edmar Edilton da Silva [mailto:[EMAIL PROTECTED]] Sent: Friday, December 01, 2000 12:41 PM To: [EMAIL PROTECTED] Subject: Order of Installation!!! Hi all, I have installed on my machine the following modules: apache 1.3.12-2 mod_perl 1.21-10 DBI 1.13-1 DBD::Oracle 1.03 Apache::DBI 0.86-1 looks like you are using RPMs? take a look at http://perl.apache.org/guide/install.html#A_word_on_mod_perl_RPM_packages The problem is that when I run a perl script under mod_perl, the response time is almost the same than the response time of the same script being ran without the mod_perl module. And I know that mod_perl was correctly installed. you sure about that? http://perl.apache.org/guide/install.html#How_can_I_tell_whether_mod_perl_ Another problem is that I can not open database connections when the WWW server starts because happen an error in the child processes of the apache. if you are using RedHat RPMs with Apache::DBI there was a problem with the dist from 6.0 or 6.1 (or 6.2 - call it all of 6 :) try to boil it down some - make sure that DBI works outside of apache, then read the Apache::DBI docs and look into whether it is caching your connections, then try to open connections with connect_on_init... HTH --Geoff I think can there is some problem in the installation or configuration of the modules. Did the order for installing of the modules do any difference? If someone help me will be very appreciated. Thanks... -- Edmar Edilton da Silva Bacharel em Ciência da Computacão - UFV Mestrando em Ciência da Computacão - UNICAMP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache::Dispatch directives
... do not seem to be allowed in .htaccess files. I don't see a reason for this restriction, Geoff ??? Particularly, I want to just be able to say: DispatchPrefix MyModule in a .htaccess file and have it just work. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Apache::Dispatch directives
all options are RSRC_CONF | ACCESS_CONF except DispatchPrefix, which is
ACCESS_CONF...
my thought on making DispatchPrefix local only to directories was that
Apache::Dispatch was specific to a Location tag: other options I thought
could be applied globally, but you wouldn't want My::Handler to resolve from
/foo and /bar... but maybe you would? I dunno...
anyway, I don't ordinarily use .htaccess, so I didn't test Apache::Dispatch
with them in mind...
what effect does .htaccess have on DIR_MERGE?
anyway, you can try this and see if it has hany ill effects - I can't think
of any. DispatchFilter will have to stay the way it is, though, because I
didn't feel like writing a huge if/else block to capture all the
possibilities of mixing PerlSetVar Filter On with DispatchFilter :)
Index: Makefile.PL
===
RCS file: /usr/local/CVS/Apache-Dispatch/Makefile.PL,v
retrieving revision 1.12
diff -u -r1.12 Makefile.PL
--- Makefile.PL 2000/11/06 16:30:07 1.12
+++ Makefile.PL 2000/12/01 19:22:08
@@ -14,7 +14,7 @@
{ name = 'DispatchPrefix',
errmsg = 'a class to be used as the base class',
args_how = 'TAKE1',
-req_override = 'ACCESS_CONF', },
+req_override = 'OR_AUTHCFG', },
#--
# DispatchExtras defines the extra dispatch methods to enable
@@ -22,7 +22,7 @@
{ name = 'DispatchExtras',
errmsg = 'choose any of: Pre, Post, or Error',
args_how = 'ITERATE',
-req_override = 'RSRC_CONF | ACCESS_CONF', },
+req_override = 'OR_ALL', },
#--
# DispatchStat enables module testing and subsequent reloading
@@ -30,7 +30,7 @@
{ name = 'DispatchStat',
errmsg = 'choose one of On, Off, or ISA',
args_how = 'TAKE1',
-req_override = 'RSRC_CONF | ACCESS_CONF', },
+req_override = 'OR_ALL', },
#--
# DispatchAUTOLOAD defines AutoLoader behavior
@@ -38,7 +38,7 @@
{ name = 'DispatchAUTOLOAD',
errmsg = 'choose one of On or Off',
args_how = 'TAKE1',
-req_override = 'RSRC_CONF | ACCESS_CONF', },
+req_override = 'OR_ALL', },
#--
# DispatchISA is a list of modules your module should inherit from
@@ -46,7 +46,7 @@
{ name = 'DispatchISA',
errmsg = 'a list of parent modules',
args_how = 'ITERATE',
-req_override = 'RSRC_CONF | ACCESS_CONF', },
+req_override = 'OR_ALL', },
#--
# DispatchFilter makes the dispatched handler Apache::Filter aware
-Original Message-
From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 01, 2000 1:55 PM
To: [EMAIL PROTECTED]
Subject: Apache::Dispatch directives
do not seem to be allowed in .htaccess files. I don't
see a reason for
this restriction, Geoff ???
Particularly, I want to just be able to say:
DispatchPrefix MyModule
in a .htaccess file and have it just work.
--
Matt/
/||** Director and CTO **
//||** AxKit.com Ltd ** ** XML Application Serving **
// ||** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Apache::Dispatch directives
forget that patch - it probably won't do what you want either...
I was mainly thinking about limiting the scope of DispatchPrefix for
security reasons (keeping people from being sloppy)...
if you don't think this is too much of a concern, then perhaps I'll change
everything to OR_ALL?
--Geoff
-Original Message-
From: Geoffrey Young [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 01, 2000 2:24 PM
To: 'Matt Sergeant'; [EMAIL PROTECTED]
Subject: RE: Apache::Dispatch directives
all options are RSRC_CONF | ACCESS_CONF except
DispatchPrefix, which is
ACCESS_CONF...
my thought on making DispatchPrefix local only to directories was that
Apache::Dispatch was specific to a Location tag: other
options I thought
could be applied globally, but you wouldn't want My::Handler
to resolve from
/foo and /bar... but maybe you would? I dunno...
anyway, I don't ordinarily use .htaccess, so I didn't test
Apache::Dispatch
with them in mind...
what effect does .htaccess have on DIR_MERGE?
anyway, you can try this and see if it has hany ill effects -
I can't think
of any. DispatchFilter will have to stay the way it is,
though, because I
didn't feel like writing a huge if/else block to capture all the
possibilities of mixing PerlSetVar Filter On with DispatchFilter :)
Index: Makefile.PL
===
RCS file: /usr/local/CVS/Apache-Dispatch/Makefile.PL,v
retrieving revision 1.12
diff -u -r1.12 Makefile.PL
--- Makefile.PL 2000/11/06 16:30:07 1.12
+++ Makefile.PL 2000/12/01 19:22:08
@@ -14,7 +14,7 @@
{ name = 'DispatchPrefix',
errmsg = 'a class to be used as the base class',
args_how = 'TAKE1',
-req_override = 'ACCESS_CONF', },
+req_override = 'OR_AUTHCFG', },
#--
# DispatchExtras defines the extra dispatch methods to enable
@@ -22,7 +22,7 @@
{ name = 'DispatchExtras',
errmsg = 'choose any of: Pre, Post, or Error',
args_how = 'ITERATE',
-req_override = 'RSRC_CONF | ACCESS_CONF', },
+req_override = 'OR_ALL', },
#--
# DispatchStat enables module testing and subsequent reloading
@@ -30,7 +30,7 @@
{ name = 'DispatchStat',
errmsg = 'choose one of On, Off, or ISA',
args_how = 'TAKE1',
-req_override = 'RSRC_CONF | ACCESS_CONF', },
+req_override = 'OR_ALL', },
#--
# DispatchAUTOLOAD defines AutoLoader behavior
@@ -38,7 +38,7 @@
{ name = 'DispatchAUTOLOAD',
errmsg = 'choose one of On or Off',
args_how = 'TAKE1',
-req_override = 'RSRC_CONF | ACCESS_CONF', },
+req_override = 'OR_ALL', },
#--
# DispatchISA is a list of modules your module should inherit from
@@ -46,7 +46,7 @@
{ name = 'DispatchISA',
errmsg = 'a list of parent modules',
args_how = 'ITERATE',
-req_override = 'RSRC_CONF | ACCESS_CONF', },
+req_override = 'OR_ALL', },
#--
# DispatchFilter makes the dispatched handler Apache::Filter aware
-Original Message-
From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 01, 2000 1:55 PM
To: [EMAIL PROTECTED]
Subject: Apache::Dispatch directives
do not seem to be allowed in .htaccess files. I don't
see a reason for
this restriction, Geoff ???
Particularly, I want to just be able to say:
DispatchPrefix MyModule
in a .htaccess file and have it just work.
--
Matt/
/||** Director and CTO **
//||** AxKit.com Ltd ** ** XML Application Serving **
// ||** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Easy way to access PerlSetEnv from outside apache cycle?
Hi all. I will try to be as clear as i can with a potentially vague problem. I am just starting to maintain and implement some mod_perl code written by a long gone coder. The mod perl code itself seems to be working just fine. But a command line script was written to also utilize a database module core to the mod_perl code. Inside this db module is one subroutine called 'handler' (of course). So in his command line script we see something like: use DBModule; DBModule::handler(); and the syntax of all that seems to be correct. The problem arises in the fact that handler() fills in some fairly essential blanks in the DB connect with variables set in a mod_perl conf file using PerlSetEnv's. So when run from the command line, those variables are undefined. I dont see an easy way to tell this script how to access that environmentspace, nor an easy way to stick the script into the modperl env as it takes a command line parameter which will require human intervention. Is there any easy way to let this command line script patch into the variablespace created by the PerlSetEnv's? Did the original designer see something over my head or was he/she on mod_crack? -- gedanken - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Easy way to access PerlSetEnv from outside apache cycle?
-Original Message- From: Gedanken [mailto:[EMAIL PROTECTED]] Sent: Friday, December 01, 2000 3:46 PM To: [EMAIL PROTECTED] Subject: Easy way to access PerlSetEnv from outside apache cycle? [snip] Is there any easy way to let this command line script patch into the variablespace created by the PerlSetEnv's? PerlSetEnv just sets environment variables, which you can access as normal environment variables in your handler... thus, just export what you need in your shell or tack stuff onto %ENV --Geoff Did the original designer see something over my head or was he/she on mod_crack? -- gedanken - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Order of Installation!!!
How many server processes do you have? Perhaps, you are hitting a different server process every time while testing? Try limiting (for debugging purposes) your server processes # to 1 and see if it makes a difference. Or just test it long enogh to have all the processes load the corresponding perl stuff into them. Vassili http://www.tarunz.org/~vassilii/ -Original Message- From: Edmar Edilton da Silva [mailto:[EMAIL PROTECTED]] Sent: Friday, December 01, 2000 12:41 PM To: [EMAIL PROTECTED] Subject: Order of Installation!!! The problem is that when I run a perl script under mod_perl, the response time is almost the same than the response time of the same script being ran without the mod_perl module. And I know that mod_perl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
help!
Hi, I am new to apache and new to this group. This could be a very easy question. But any help will be greatly appreciated. I compile apache 1.3.14 with mod_perl and mod_ssl, the installation process went ok, but I received this error message when I tried to start the apache server . Segmentation fault - core dumped. The server is running SPARC Solaris 8. Thanks Ming Yu ?? === Enterprise Communications Group - BIX JHU Applied Physics Laboratory Telephone: 443 778-7117 Fax: 443 778-5727 Email: [EMAIL PROTECTED] === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: setting a variable based on the server.
The solution i'm working on is something like this:
in the httpd.conf add
in the linux box
PerlSetVar NETP 0
in the solaris box
PerlSetVar NETP 1
then change the code to
if ($NETP)
{
return $netp-run();
}else{
return 0;
}
I've seen some problems with the PerlSetVar directive at my site, but
otherwise I do something quite similar. I wound up defining the
variables I need in apachectl (SYBASE=/opt/sybase; export SYBASE; etc.).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: help!
check out the perl guide at: http://perl.apache.org/guide also, you can search through the mail archives at: http://www.geocrawler.com/lists/3/web/182/0/ you might have compiled as a DSO and not used the same compiler, or compiler parameters. -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/ "Yu, Ming" wrote: Hi, I am new to apache and new to this group. This could be a very easy question. But any help will be greatly appreciated. I compile apache 1.3.14 with mod_perl and mod_ssl, the installation process went ok, but I received this error message when I tried to start the apache server . Segmentation fault - core dumped. The server is running SPARC Solaris 8. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
