ic_mod_perl(1p) [debian man page]

IC_MOD_PERL(1p) 					User Contributed Perl Documentation					   IC_MOD_PERL(1p)

NAME

       ic_mod_perl -- Run Interchange entirely inside Apache/mod_perl

SYNOPSIS

	 # Add to Apache httpd.conf:
	 PerlRequire /usr/lib/interchange/bin/ic_mod_perl
	 PerlChildInitHandler Vend::ModPerl::child_start
	 PerlChildExitHandler Vend::ModPerl::child_end
	 <Location /ic>
	     SetHandler perl-script
	     PerlHandler Vend::ModPerl
	     PerlSendHeader Off
	     PerlSetupEnv On
	 </Location>

DESCRIPTION

   Benefits
       o   Possibly better stability, especially on non-Linux platforms where Perl signals are often buggy.

       o   Use less memory total; don't have preforked Apache and Interchange daemons. Adds about 8 MB more to a typical Apache/mod_perl child
	   process, for a total of, say, 32 MB per Apache child process. But standalone Interchange usually has 3 processes: an Interchange child
	   process (~24 MB), an httpd child (~24 MB), and a link CGI (~1 MB), so it's actually a decent savings in total memory used.

       o   Speed (ranging from slightly faster to the same on heavy pages, to 10 hits/sec. faster on empty pages).

       o   Debugging -- delve into bowels with Apache::Status.

       o   Easier coexistence with other mod_perl code and libraries.

       o   Can coexist with standalone Interchange codebase without problems.

       o   Administrative ease (for sysadmins who know Apache but not Interchange).

   Drawbacks
       o   Interchange runs as web server user, which in a standard system is usually apache or www, so you wouldn't want to share that Apache
	   installation with untrusted user CGIs, PHP, etc. as they could read any Interchange files, including DSNs, userdb, etc.

       o   Apache needs to be dedicated, or very closely watched because all mod_perl stuff runs in the same interpreter, and lots of mod_perl
	   code doesn't use Safe.

       o   How do you scale to multiple app servers in this configuration?

	   o   Hardware or software port redirector

	   o   Tux CGI front-end redirector like tlink

	   o   Separate lightweight Apache (no modules) that proxies /ic requests

   Ideal system setup
       Use Tux to serve images & static content, and a dedicated Apache for Interchange running under the 'interch' user and with no UserDir, CGI,
       PHP, etc. enabled and an empty DocRoot.

CAVEATS

       o   Watch out for differing Storable versions in sessions when switching between standalone and mod_perl runs!

BUGS

       o   Haven't yet implemented form/multipart submissions.

       o   Don't yet handle TolerateGet.

       o   Don't yet handle MiniVend 3 style GETs (mv_session_id;mv_arg;mv_pc)

       o   URIs must follow format "/ic/catalogname/page...", where /ic is customizable but must only be one "directory" deep (i.e., no slashes).

AUTHOR

       Jon Jensen <jon@icdevgroup.org>, March 2002

perl v5.14.2							    2012-01-23							   IC_MOD_PERL(1p)

Check Out this Related Man Page

DB(3pm) 						User Contributed Perl Documentation						   DB(3pm)

NAME

       Apache::DB - Run the interactive Perl debugger under mod_perl

SYNOPSIS

	<Location /perl>
	 PerlFixupHandler +Apache::DB

	 SetHandler perl-script
	 PerlHandler +Apache::Registry
	 Options +ExecCGI
	</Location>

DESCRIPTION

       Perl ships with a very useful interactive debugger, however, it does not run "out-of-the-box" in the Apache/mod_perl environment.
       Apache::DB makes a few adjustments so the two will cooperate.

FUNCTIONS

       init
	   This function initializes the Perl debugger hooks without actually starting the interactive debugger.  In order to debug a certain
	   piece of code, this function must be called before the code you wish debug is compiled.  For example, if you want to insert debugging
	   symbols into code that is compiled at server startup, but do not care to debug until request time, call this function from a
	   PerlRequire'd file:

	    #where db.pl is simply:
	    # use Apache::DB ();
	    # Apache::DB->init;
	    PerlRequire conf/db.pl

	    #where modules are loaded
	    PerlRequire conf/init.pl

	   If you are using mod_perl 2.0 you will need to use the following as your db.pl:

	     use APR::Pool ();
	     use Apache::DB ();
	     Apache::DB->init();

       handler
	   This function will start the interactive debugger.  It will invoke Apache::DB::init if needed.  Example configuration:

	    <Location /my-handler>
	     PerlFixupHandler Apache::DB
	     SetHandler perl-script
	     PerlHandler My::handler
	    </Location>

SELinux
       Security-enhanced Linux (SELinux) is a mandatory access control system many linux distrobutions are implementing.  This new security scheme
       can assist you with protecting a server, but it doesn't come without its own set of issues.  Debugging applications running on a box with
       SELinux on it takes a couple of extra steps and unfortunately the instructions that follow have only been tested on RedHat/Fedora.

       1) You need to edit/create the file "local.te" and add the following:

       if (httpd_tty_comm) {
	   allow { httpd_t } admin_tty_type:chr_file { ioctl getattr }; }

       2) Reload your security policy.

       3) Run the command "setsebool httpd_tty_comm true".

       You should be aware as you debug applications on a system with SELinux your code may very well be correct, but the system policy is denying
       your actions.

CAVEATS

       -X  The server must be started with the "-X" to use Apache::DB.

       filename/line info
	   The filename of Apache::Registry scripts is not displayed.

SEE ALSO

       perldebug(1)

AUTHOR

       Originally written by Doug MacEachern

       Currently maintained by Frank Wiles <frank@wiles.org>

LICENSE

       This module is distributed under the same terms as Perl itself.

perl v5.14.2							    2008-04-27								   DB(3pm)

Linux and UNIX Man Pages

ic_mod_perl(1p) [debian man page]

Check Out this Related Man Page