Very well, then.
My instincts are confirmed.
I shall proceed as I would with any local-hosting arrangement, “even though I own the box,” because I always want to be sure that no unforseen “yummy thing” will torpedo something down the line ... and that what I may do likewise will not torpedo any important system tool. “Just keep ’em in separate oceans.”
For the curious (and for comments, please, by anyone), the procedure by which I do this is summarized as follows:
- As root, set up a non-privileged userid and associated group, “for the purpose of Perl maintenance.” This user is not one that is ever used by any Apache CGI-session, nor by any other regular software on the system.
Create a suitable directory in /usr/local and use chown to this user and group, giving the directory full-access only to that user; read-execute to everyone else. Let's say it's called /usr/local/share/perl ...
Log on as that user and run cpan. Do not accept the “convenient” initial offer to set up everything for you. Even so, you can accept most of the options, except for these:
You will observe that I consciously set INSTALL_BASE= not PREFIX=.
mbuild_install_arg [--site-prefix /usr/local/share/perl]
mbuildpl_arg [--install-base /usr/local/share/perl]
From any user(s) which will be running Perl code e.g. for testing purposes, put the following statement in your .bashrc file, which is executed at startup:
Create a setup-perl file in your local home (non-executable) containing:
When you log on, you can say source ./setup-perl to arrange for Perl to automatically look in this location when you run things.
I have had problems in the past using .bashrc files for this purpose, although this was in shared-host setups which ran CGI scripts under my userid.
So, do what works best for you.
struck out code above was incorrect: it caused a symptom whereby “when I updated Perl modules (including CPAN), the updates never became visible.” Furthermore, the export clause must be used so that the environment-variable setting is visible. (Whups!!) You can confirm that all is well by examining the output of perl -V, noting the upper-case “V.”
When you write programs, e.g. for the web-site, you'll need to include a use lib statement that expressly points to /usr/local/share/perl. Good web code should be run in “taint mode” and should never rely upon environment variables to cause it to “do the right thing.”
The idea is to make sure that these apps always look in just the right places, and that nothing you can do, oh 733T H4X00R, can make it do otherwise.
Are you posting in the right place? Check out Where do I post X? to know for sure.
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
Want more info? How to link
or How to display code and escape characters
are good places to start.