There are 2 kind of perl modules:

1. plain text modules (*.pm) like Data::Dumper, etc, that can be deployed in your library path (either the system library path like /usr/local/ActivePerl-5.6/lib/5.6.1, or your own library path which you must include in your script like:

   BEGIN {
     @INC = ();
     unshift @INC, '.', '/home/user/perl/lib', "/home/user/perl/lib/sun4-
   +solaris"
                   if ($^O =~ /solaris/);
   }
   [download]

   )
2. modules that depends on binary files to properly working like DBI, etc, which you need to deploy along with binary files. These can be compiled on a development machine with the same OS as the target machine (Solaris?), then you can copy them via a script, a tar archive or any other means on the target machine as long as you keep the path structure and include the librariy paths into your scripts.

BEGIN {
  @INC = ();
  ...
[download]

...might not be a good idea to clear the @INC array first, because in this case the standard modules will no longer be found (unless you copy all of them into one of the directories specified).

$ perl -e 'BEGIN{ @INC=(); unshift @INC, ".", "/home/user/perl/lib"} u
+se File::Find'
Can't locate File/Find.pm in @INC (@INC contains: . /home/user/perl/li
+b) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
[download]

In the typical case, you just want to BEGIN{ unshift @INC, ... }, or use lib ... to prepend additional search paths to the system paths that @INC already consists of...

You're right. I've posted in a hurry :D.

(Update: I spotted a hidden but reasonable assumption that deployment takes place in chain from some other environment where compilers and interpreters are freely allowed).

But it is worth pointing out that for these purposes, the perl executable is not a compiler but a scripting interpreter. Assuming there is no webserver running, if it were me, I'd demand that they be consistent about it, i.e. remove /bin/ksh and /bin/sh (the erm "predecessors" of Perl :)) or they allow /usr/bin/perl - there is then zero difference from a security point of view between one scripting language and another. Of course, they can't remove ksh and sh because that would break the system so badly it would descend into a coma never to return or reboot, requiring reinstallation of the operating system.

If the system is indeed connected to the internet, a more reasonable and far more competent security precaution would be nevertheless to restrict the execute permission of /usr/bin/perl to 750, chown it to the group where applications run and to run the webserver in a separate group.

The real incompetence is usually running webservers as root and it is ridiculous to blame Perl for the security consequences of that - i.e. it is like rearranging the deckchairs on the Titanic.

I think that the OP was simply stating that they're not allowed to have C/C++ compilers on production machines, hence they cannot install modules the usual way because they cannot deal with XS.

Update: d'oh, I see that this was already raised up further in the thread.

Flavio
perl -ple'$_=reverse' <<<ti.xittelop@oivalf

Don't fool yourself.

My sense of the original post, though it was unclear, was that the OP wanted a way to install pre-compiled modules for use with an existing perl interpreter.

In any case the PAR tools should do the trick. The OP can use PAR to create application bundles and run straight from the PAR, or he can use PAR-Dist to install them. If a general purpose perl interpreter is forbidden, as you said, he can use pp to bundle an interpreter.


TGI says moo

Due to security policy it is not possible to have compilers on our platforms in the live environment.

I've solved this issue a couple of different ways on a number of different platforms. Let me talk about two of those:

One environment I worked in I created a Solaris pkg file of a standardized Perl distrobution that I engineered. We took a development machine, put together a tree under a directory called /usr/local/software/perl-{VERSION} and installed all the CPAN modules we felt we needed to standardize on there. Once that was done we used the normal Sun packaging tools along with some cleanup scripts to do things like link the Perl executable into /usr/bin/perl the library tree to the right place, etc.

In one other environment ("a major financial compnay") AFS was the standard way of "distributing", for a lack of better word for it, software packages. Again, development and test machines were employed to put the dietributions together and put them on the AFS cells. In that environment we had many platforms to support so some automounter tricks were used to make sure that the right version of the Perl trees were mounted on the machines accordingly. AFS was laid out to accomodate the architecture differences between the platforms and the automounter maps for them configured accordingly.

to do things like link the Perl executable into /usr/bin/perl

Bad advice. You shouldn't mess with the base OS, who knows what that might break. Install your own Perl somewhere else, for example /usr/local/bin/perl or /opt/local/bin/perl.

You shouldn't mess with the base OS,

Huh? /usr/bin/perl is an installed application like any other and is not the OS. So, what you are telling me is that it is better to leave a broken Perl in place than replace it with one that works?

Let me give a really good example of why I'll put my own copy of /usr/bin/perl in place of one that is there already. Solaris 10 comes with a version of Perl. Unfortunately it is compiled with Sun's own liscenced compiler. If I just want to accept the list of CPAN modules that Sun has so graciously supplied then that's ok.

However, in this case our environment, which stores all user account information in LDAP needs to have Net::LDAP and friends installed on all the servers for some of our user administration tools to work. Since our LDAP servers are connected to via LDAPS and not clear text LDAP we need the whole family of SSL related modules compiled in as well.

None of those will work correctly if you try and compile them with a compiler other than Sun's compiler assuming we leave Sun's version of Perl in place.

Contractual and financial realities being what they are on that account we are not going to be having access to a Sun compiler anytime soon, so we use GCC.

who knows what that might break.

That's where proper engineering practices come into play. Anything we do in our production environment has already been done on test boxes. While we don't have the luxury of an official Sun compiler, we do have test boxes we can do things to before impacting production.

So, your argument of "don't mess with it" in this case doesn't hold much water. I would agree with your assesment if proper engineering wasn't done ahead of time and without a good understanding of the systems and applications involved.

---

Peter L. Berghold -- Unix Professional
Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg

RPM is source-compatible with Solaris, but it might require a major jehad for OP to get that implemented on the production Solaris system he is talking about. However, .rpm's can be converted to Solaris packages if that is more easily acceptable to OPs production system watchdogs.

But you really raise a Linux to Solaris porting issue - I would not expect the OP necessarily to be faced with that additional challenge.

-M

Free your mind

I understood the OP to be implying that whoever is enforcing the security policy thinks the perl binary is a compiler or is categorising it as such for security purposes.

-M

Free your mind

You've probably misunderstood then. It's a somewhat common practice to remove (or not install initially) the C compiler on machines that are exposed to the wild (e.g. on the Internet directly or in a DMZ). In this case you're in the same boat as most Wintendo users in that you don't have a compiler available to install Perl modules with a C component (then again attackers don't have a ready means to compile exploit code on the box either). Granted it's a minor speed bump (especially if you're talking a common platform), but it can be worked around (unfortunately just as easily by both the white and black hats).

It'd be a little tough to run any perl code then.

Or make use of any perl modules.



--chargrill

---

s**lil*;  $*=join'',sort split q**;  s;.*;grr; &&s+(.(.)).+$2$1+; $; =
qq-$_-;s,.*,ahc,;$,.=chop for split q,,,reverse;print for($,,$;,$*,$/)
[download]

Hmmm ... maybe we should publicise this. Perl is finally a compiled language! :-)

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

One way to handle this is to build on one machine and then use either rdist or rsync to update the others.

update: I should have said --- use the OS's preferred package mechanism to update the build machine (rpm, pkgadd, cpan, whatever ...) and then use rdist/rsync to update the others.

And you you should have replaced rysnc/rdist with something more secure like scp/sftp.

Upate:

Ooops! I was thinking "rcp" when I read "rsync". I agree that it can be made secure. In fact Using Rsync and SSH disccuses how to use it with SSH.

I see from the rdist homepage that it has also come a long way. However as they point out many operating systems ship with a much older, insecure version. So I guess Linux users are more familair with the newer version while those of us used to e.g. Solaris are used to the older version. Looks like it is one of those things that one needs to be careful of recommending given the wide audience.

I will point out that it looks like both rsync and rdist make use of SSH for better security. So I think my original comment still has validity.

No, I shouldn't have -- rsync and rdist are capable of secure transport.

-derby