Re: [mp2] APR::Socket::recv set read timeout ?
Michael wrote: Hi all. As suggested by Geoff and Stas, I am trying out modperl2.. Now I have some questions: i) with Apache::CommandServer (can be found at http://perl.apache.org/docs/2.0/user/overview/overview.html#toc_Protocol_Mod ules_with_mod_perl_2_0), I setup everything according to the guide..but telnet localhost 8084 Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. Login: foo Password: foo ^] I must hit return once before the 'Login' prompt appears, and after a few tests I found that $socket-send() do not send the buffer to the client right away. Is this related to some configurable directives in httpd.conf or I did something wrong.. or just a feature? I'm trying to bring the overview and design notes docs up-to-date, Doug wrote them long time ago and things have changed a bit since then. The almost up-to-date version of the overview is here: http://perl.apache.org/docs/2.0/user/intro/overview.html How did you get to the old URL? Via google? I think I found that link somewhere in the user guide, but I am not sure anyway. ii) is there any way to perform a select(2) or like on the $socket? I would like to implement some sort of 'timeout' in the read loop..say, after 5 secs if nothing is recv'd from the client then the connection will be closed. I have tried alarm/die pair but it was a failure. Any idea? You have the APR::Socket object, so it should be possible. Though I see that apr_poll_ API is not glued. !MODULE=APR::Poll apr_poll_socket_add apr_poll_socket_clear apr_poll_data_get apr_poll_revents_get apr_poll_socket_mask apr_poll apr_poll_socket_remove apr_poll_data_set apr_poll_setup The ! mark in xs/maps/apr_functions.map disables the glueing of this API subset at the build time. sorry but I would like to ask how do I glue that? I tried the util/xs_check.pl in the modperl2 src dir, and it reports.. unable to glue 27 mapped functions: ap_allow_standard_methods ap_register_input_filter ap_register_output_filter apr_brigade_printf apr_brigade_puts apr_brigade_write apr_getnameinfo apr_parse_addr_port apr_poll apr_poll_revents_get apr_poll_setup apr_poll_socket_add apr_poll_socket_clear apr_poll_socket_mask apr_poll_socket_remove apr_pool_child_cleanup_set apr_pool_cleanup_kill apr_pool_cleanup_run apr_pool_get_abort apr_pool_note_subprocess apr_pool_userdata_get apr_pool_userdata_set apr_shutdown apr_socket_addr_get apr_socket_data_get apr_socket_data_set apr_socket_from_file Finally, as I've mention before, I would like to put this non http thing together with other http things on the same port 80. Is this possible? say, when this handler sees GET|POST|HEAD it forgets the request and let the Apache HTTP module process it in the normal way?
Why is my mod_perl's @INC different?
When I use perl from the command line, my @INC is this:
$ perl -eprint join(':', @INC)
/usr/lib/perl5/5.6.1/i386-linux:/usr/lib/perl5/5.6.1:/usr/lib/perl5/site_perl/5.6.1/i386-linux:/usr/lib/perl5/site_perl/5.6.1:/usr/lib/perl5/site_perl/5.6.0:/usr/lib/perl5/site_perl:.
When I print @INC from a mod_perl script, it is this:
/home/mirror/global:/usr/lib/perl5/5.6.1/i686-linux:/usr/lib/perl5/5.6.1:/usr/lib/perl5/site_perl/5.6.1/i686-linux:/usr/lib/perl5/site_perl/5.6.1:/usr/lib/perl5/site_perl:.:/home/mirror/httpd/:/home/mirror/httpd/lib/perl
How did this happen? Why does my command line perl use i386-linux,
while my mod_perl uses i686-linux?
My problem is, any modules I install go into i386-linux. They're not
accessible to mod_perl. I need to install a new module for my site but
I can't access it in mod_perl.
I've tried adding use lib qw(/usr/lib/perl5/5.6.1/i386-linux); in
startup.pl, but then it makes Apache not start at all:
/usr/local/perlhttpd/bin/httpd: relocation error:
/usr/lib/perl5/5.6.1/i386-linux/auto/Data/Dumper/Dumper.so: undefined symbol:
perl_get_sv
/home/mirror/bin/apachectl start: httpd could not be started
Any idea what's going on here?
Re: Why is my mod_perl's @INC different?
How did this happen? Why does my command line perl use i386-linux, while my mod_perl uses i686-linux? Simple: they are compiled to use different installations of Perl. If you want to unify them, you can find out what mod_perl is using and put it first in your path (so that perl will run it) or you can replace one or the other with a new compile. - Perrin
Apache::Session::MySQL
Is this the correct list for help with Apache::Session::MySQL? Thanks, Richard.
Re: Apache::Session::MySQL
Is this the correct list for help with Apache::Session::MySQL? This is a good list for it if you are using mod_perl. If you're using CGI, try one of the CGI resources instead, or stick with perlmonks.org. I just replied to your post there a few minutes ago. - Perrin
Re: Apache::Session::MySQL
Ah. ok. I don't use Mod_Perl, I hear it is a big security risk, since it runs as root. Is this true? I love how much faster it is, it's not that much faster, but enough to make me upgrade all my boxes if it is not a security risk. What do you think? Thanks, Richard. (I'll go see your reply in a min. Thank you!) - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, December 28, 2002 11:49 AM Subject: Re: Apache::Session::MySQL Is this the correct list for help with Apache::Session::MySQL? This is a good list for it if you are using mod_perl. If you're using CGI, try one of the CGI resources instead, or stick with perlmonks.org. I just replied to your post there a few minutes ago. - Perrin
Re: Apache::Session::MySQL
Ah. ok. I don't use Mod_Perl, I hear it is a big security risk, since it runs as root. Is this true? It's not true. The parent process runs as root in order to open port 80, but that's the same for CGI as well. The child processes that actually handle requests runs as whatever user you specify in httpd.conf (typically nobody). I love how much faster it is, it's not that much faster, but enough to make me upgrade all my boxes if it is not a security risk. If you have clean code (use strict and -w) that will run under mod_perl, you should definitely take advantage of the speed increase. Depending on what you're doing, it can make a really huge difference in performance. I do recommend that you fix your current Apache::Session problem first, before thinking about converting to mod_perl. - Perrin
Re: Apache::Session::MySQL
So by user nobody, you mean in the httpd.conf file in the virtualhost tags the user and group? I have it set to user username and group username for each account, since all of our boxes use SuExec. So mod_perl is safe Ok. one other question. If I do upgrade to Mod_Perl, can I still run regular Perl scripts, without using Mod_Perl, or do I have to use one or the other, only. Thank you, Richard. PS I just replied to the PerlMonks reply you did. Thank you. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, December 28, 2002 12:08 PM Subject: Re: Apache::Session::MySQL Ah. ok. I don't use Mod_Perl, I hear it is a big security risk, since it runs as root. Is this true? It's not true. The parent process runs as root in order to open port 80, but that's the same for CGI as well. The child processes that actually handle requests runs as whatever user you specify in httpd.conf (typically nobody). I love how much faster it is, it's not that much faster, but enough to make me upgrade all my boxes if it is not a security risk. If you have clean code (use strict and -w) that will run under mod_perl, you should definitely take advantage of the speed increase. Depending on what you're doing, it can make a really huge difference in performance. I do recommend that you fix your current Apache::Session problem first, before thinking about converting to mod_perl. - Perrin
Re: Apache::Session::MySQL
At 01:25 PM 12/28/2002 -0600, Richard wrote: So mod_perl is safe Ok. one other question. If I do upgrade to Mod_Perl, can I still run regular Perl scripts, without using Mod_Perl, or do I have to use one or the other, only. Richard, Yes,you can still run regular cgi, as with MP you have to explicitly tell (via directives in httpd.conf) which files to process using MP handlers. My guess is if you are going to convert cgi scripts to run under MP, you are going to be iinterested in Apache::Registry. There is probably a ton of good info on apache.org and elsewhere about how to do this exactly. GV
Re: Apache::Session::MySQL
So by user nobody, you mean in the httpd.conf file in the virtualhost tags the user and group? I have it set to user username and group username for each account, since all of our boxes use SuExec. Okay, that may be an issue because SuExec does not work with mod_perl. Each apache daemon can only run mod_perl processes as a single user, but that user can be any user you choose. You would never set them to run as root, because that would be a security problem. So mod_perl is safe Ok. one other question. If I do upgrade to Mod_Perl, can I still run regular Perl scripts Yes, and you should still be able to run them with SuExec. As George said, there is quite a bit documentation on the perl.apache.org site that may help you. - Perrin
Re: Apache::Session::MySQL
Great, thank you guys! I am trying to first fix my Apache::Session problem before I open a whole new bag of candy :o) Thank you very much for your input, I am grateful! Richard. - Original Message - From: Perrin Harkins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, December 28, 2002 2:32 PM Subject: Re: Apache::Session::MySQL So by user nobody, you mean in the httpd.conf file in the virtualhost tags the user and group? I have it set to user username and group username for each account, since all of our boxes use SuExec. Okay, that may be an issue because SuExec does not work with mod_perl. Each apache daemon can only run mod_perl processes as a single user, but that user can be any user you choose. You would never set them to run as root, because that would be a security problem. So mod_perl is safe Ok. one other question. If I do upgrade to Mod_Perl, can I still run regular Perl scripts Yes, and you should still be able to run them with SuExec. As George said, there is quite a bit documentation on the perl.apache.org site that may help you. - Perrin
