For years I have been using the following at the top of my scripts:
use lib '/var/www/vhosts/example.com/demo.example.com/cgi-bin/library';
That works fine when the lib is within the same domain space as the calling script.
However, I want to call in from a centralised library so I will have just one place to set db credentials.
So, if I adjust that line to call in from another account on the same server, it cannot find the library.
use lib '/var/www/vhosts/example2.com/demo.example2.com/cgi-bin/library';
Running on plesk, if that may make a difference. Used to run on cPanel and I had no issue.
I would appreciate a pointer, having already read some docs and I am confused.
Only someone with access to the configuration of your web server can answer this for sure, but I'd guess that each of your vhosts is running as a different user and the users can only read files from their own web space.
This approach won't work. If you want to to have a centralised module library then either install the modules that you want in the system module library (i.e. where cpan will install them by default) or create your own new centralised library somewhere that isn't under one of the vhost directories (perhaps under /opt).
However, it's worth noting that best practices for deployment of applications are moving in completely the opposite direction. It's generally considered a good idea for each application to have its own set of dependencies installed in its own module library. Using a cpanfile to record the exact versions of the dependencies that you're using makes this simple.
Related
I am just starting to organize some stuff on the cluster and would like some advice on it. I posted a recent question How to organize Perl modules and got some good answers about what I was doing incorrectly. I was trying to install each perl module independently by setting the PREFIX for Makefile.PL each time to /path/to/lib/module-name/module-version/installation happens here.
For e.g. for a module JSON, I installed it like this:
perl Makefile.PL --PREFIX=/path/to/lib/perl5/5.22.1/JSON/2.53
make
make test
make install
For module Data-UUID, I did it like this:
perl Makefile.PL --PREFIX=/path/to/lib/perl5/5.22.1/Data-UUID/1.221
make
make test
make install
So it made a directory JSON/2.53 in /path/to/lib/perl5/5.22.1 and that's where it installed the package. But because I change the PREFIX for each individual module, I have to set the PATH in the bash_profile accordingly, which is kind of messy.
My main goal to do this was for version control. In a hypothetical scenario where different versions work for two of your teammates, say JSON/2.52 works for X and JSON/2.53 works for Y, how do you control for versions without having to ask them to install their versions locally? In another scenario, what if a version worked for you 3 months back and the updated version doesn't work for you anymore? How do you keep track of versions if you install everything in one directory?
I also have more questions on the module local::lib but I will post it as another question.
Thanks!
Maintaining concurrent versions of CPAN modules is asking for grief. I would suggest instead - don't, use docker for anything that's got any sort of deployment. That way you can have local installation of stuff + deps in an isolated container.
It's a bit like early days yet on docker, but they're a significant amount of enthusiasm and support for it from some very big names.
Personally I'm just using it to bundle up "mojolicious" perl webapps behind a reverse proxy, and maintain their dependencies as a self contained installation (which I can run/test/deploy autonomously)
I am greatly disappointed every time I am forced to retrieve a module from CPAN. In most environments I work in, internet access is severely restricted or completely denied. All compilers have been removed during the OS hardening process. And all digital storage media is scanned by a security team before entering or exiting the site. Mind you, I understand security, and all of this is OK with me, but...
What is the recommended or best practice for accessing code only CPAN modules provide.
If I only need a snippet, a function, or a single string of functionality a module gives me, how can I extract "just what I need/want" without installing an entire module? Keeping in mind that I may be literally printing out, writing down, and typing in, to transfer the data from an off-site location with internet access.
When you can't access CPAN - how you want use it? So, you can either:
when have internet access - you can install modules
if havent, you can bring an minicpan on USB stick or soo
if this is not possible because security policy, you can only use e.g. you mobile phone to show source on CPAN and retype the needed parts manually
if neither is possible - you can at home print the source code on your tshirt and retype it in the work :)
or, simply must programm all things yourself - by learning at home
or, find the better job :)
EDIT: More serious approach
First, it is strange to have an company who developing with perl, but doesn't allow use CPAN. Of course, I understand than direct access to a tons of unscanned sw is not acceptable for many companies, but in this case here should be exists some "company policies" - how to allow access.
Here are several questions:
the hardening is at technical level only (firewalls etc) - so you can bring e.g. USB stick, CD or any other medium inside, or
policy level - the policy does not allow using any external source
If it is at policy level - IMHO, you're out of luck. Simply when it is NOT ALLOWED using any external source - you can use really only the "print & retype" method.
Here is some possibilities:
establish an company-wide local CPAN repository
Create an local CPAN (minicpan) server with "trusted" modules. This repository can function as repository for locally developed modules too. In this case must exists some "auditing authority" (policies & procedures) how to get modules into the local repo. IMHO, this can be the most useful way - when the company using perl on regular basis.
Of course, mixing system-wide (default perl modules) with CPAN modules not the best idea. Therefore is possible to setup:
local::lib or build-prefix
local::lib - create and use a local lib/ for perl modules with PERL5LIB. Google for perl "local::lib" or something similar. Also read some other SQ questions:
How can I install a CPAN module into a local directory?
How can I use a new Perl module without install permissions?
How can I install CPAN modules locally without root access (DynaLoader.pm line 229 error)?
and other
Using local::lib is nice solution, because doesn't break system-wide perl modules. Of course, again - you will need some "auditing process" how to get modules inside.
perlbrew
Using your own built perl - perlbrew - is more general solution if the system hasn't installed perl. You don't need root access for building your own perl. Of course, here is still some problems (besides the auditing), e.g. the "missing compiler problem".
virtual machine
You can try setup an virtual machine for development (or isolated physical machine) with full CPAN access and develop here. When you finish the development, you can forward your work with all required modules to "auditing process".
other
If you need only extract an function or a modules from the CPAN modules, do it on external machine. Extracting a function or some part is not a technical problem (when you know perl) it is more an license problem - using a part of modules in your work - you need cite the author.
For this you need fetch all needed functions - can find interesting this discussion. Google for "perl functions dependencies" or something similar, or:
How can I determine CPAN dependencies before I deploy a Perl project?
http://metacpan.org/pod/Module::Extract::Use
http://metacpan.org/pod/Module::ScanDeps
Perl: CPAN - Module modifying and adding functionality
Maybe, you will find this discussion interesting too...
I need help: is there a way to fetch a file from the remote server using only core modules of perl 5.8.8? File::Fetch became core module only from 5.9.
This comes up all the time. Take a look at the classic yes, even you can use CPAN. If you have the ability to create and run a Perl script, then you also have the ability to put a module in your local directory and use it. The requirement to use only core modules is entirely artificial.
In your case, LWP::Simple's getstore() function will do what you want. While it is technically not core, LWP::Simple is included by default with many Perl distributions. You may well already have it.
Update: so, you want to do this on 1000 servers? No need to manually install the module on each server. Use CPAN programmatically to download and install the module(s) you need (some tweaking will be needed to get CPAN to install it locally rather than in the root module library). Also Leon Timmermans's suggestion of fatpacking the module is another option.
If you really don't want to do it this way, then basically the answer is no: there is no simple way to fetch a remote file via HTTP using neither the appropriate modules, nor a system command (I didn't consider writing your own HTTP client to be a simple method, but that's fine if it works for you).
The only other potential solution I see would be a different approach to your problem, such as:
Using a script in a single location to get the file, then distribute
it to all 1000 servers via FTP.
Or, putting the file on an FTP server, then using a simple Perl
script on each server to fetch it via FTP.
As Dan already said, yes, even you can use CPAN. One approach his link doesn't mention is writing it as a normal CPAN-using distribution, and then fatpack it. Fatpacker combines a script with all its (pure-perl) dependencies, creating a single easy to distribute file.
You could use:
my $wgetoutput = `wget "$myFileToGet"`;
Stuff in backticks (`) will be given to the default shell, so you can call whatever you want (and are allowed) there.
Caveat: $myFileToGet could have stuff like "&& rm -rf *" in it, so dont forget to sanitize!
I posted this question looking for something similar to Buildout for Perl. I think Shipwright is what I'm looking for but I'm not really sure. I've played around with it and I created a project, imported all of my source and dependencies and I've exported everything to a vessel then the documentation sort of just stopped. What do I do with a shipyard vessel? Do I do my actual development work in the vessel, or do I do my development in the Shipyard? I'm assuming that the vessel is only for deployment, but how do I actually deploy a vessel to a web server (say I'm using linux, apache and just running straight cgi).
Is Shipwright the right thing for what I'm trying to accomplish or is there something else that would be more appropriate? Ideally I could use Shipwright similar to how I use Buildout. I use Buildout to create a nice isolated environment for my development, and also I use Buildout when deploying to live servers to manage all of my application's dependencies.
EDIT: Here are the highlights of what I can do with Buildout that I would like to be able to do in Perl.
With Buildout, I have a file in my codebase that lists dependencies (which for Perl would either be CPAN modules or other source repositories). I can run a bootstrap script that will fetch all of those dependencies and drop them into a directory within my project and NOT install them at a system level. Buildout also creates utility scripts which can do anything you want (run tests, other command line tools, anything really) and those scripts explicitly add the dependencies to the path so that as my scripts are running all of my dependencies are available to be imported.
What this really does very well is that it allows me to manage my dependencies without having to ever install anything at a system level. Which makes changing from one version to another very easy. Also, it allows me to have multiple Buildout projects running on the same system using different versions of the same module. Finally, one huge benefit is that with Buildout's directory structure, I can just commit the dependencies to source control and to deploy to a new machine I just need to do a checkout and all of my dependencies are already satisfied without having to touch anything installed at a system level.
I don't think you'll find anything exactly like Buildout in Perl, but you could put together a couple of things that would do the trick.
You could use a standard Build.PL script for Module::Build for managing your dependencies and having commands to run tests, etc.
Then you could use cpanminus to do the installation of those dependencies into a local (non-system) directory.
Then you might be able to use Shipwright to do the bundling and deployment of the project with these now-local dependencies.
I need to install my Perl-based software on networked machines which aren't connected to the internet. Therefore, I would like to download specific versions and/or latest versions of the Perl modules and I would also like to know if there is an install procedure required for these modules.
Background:
The machines aren't connected to the internet for security reasons and its deemed unnecessary also.
I would place the downloaded modules on a machine that I call the 'install server' and it contains my Perl based software and would also contain the local copies of the Perl modules.
I call a machine that I want to install my Perl-based software on, the 'target machine', also not connected to the internet. There can be several target machines, each can run this software that I want to install. I log onto the target machine and run an install script which would connect to the install machine via the local network to obtain the Perl-based software and dependent Perl modules and installs them.
So I need to know:
How/Where to get specific versions of Perl modules, e.g. CGI.pm etc
How to install these Perl modules. Is it a case of just placing them in a directory somewhere, e.g. a library path and making sure that this directory path is in the #INC library path environmental variable, if it is not already?
I would prefer not to have to do anything like make install etc. as part of installing the modules. I would like to modules to be pre-compiled or prepared as necessary so it is as simple as possible to install them. I want to avoid additional dependencies like make and its configuration, and having to parse its output to check whether it was successful.
Please help me by asking the above specific questions as I am not able to change the concept of 'install machine' and 'target machine' which aren't connected to the internet - I have to provide a solution that works within this arrangement.
The usual way to solve "I want to install stuff from CPAN but without network" problems is to use a minicpan as David Dorward wrote in his answer. But since you're going one step further, saying that you'd rather not do any real installation on the client (target) machines at all, and that you want to use precompiled modules if possible, I urge you to check out PAR and specifically PAR::Repository (server) and PAR::Repository::Client.
Since this approach needs some research before you're up to speed, I wouldn't suggest it for "I just need Foo.pm" like problems. Once you're talking about a handful of dependencies and at least a handful of clients, then it becomes a more appropriate solution.
For an outline of how it works, check out the slides of my talk at YAPC::EU 2008. It also hints at solutions to the bootstrapping problem of making the PAR::Repository::Client module available on the clients (hint: PAR can generate self-contained executables).
You can create a MiniCPAN that has just the latest versions of everything from CPAN. You can insert additional, non-public modules into it with CPAN::Mini::Inject. If you need to greater control over versions (i.e. not choosing the latest versions), you might want to create a DPAN.
With any of these solutions, you can configure your CPAN client to pull from your local source. That could be a directory you know ahead of time or something that you figure out dynamically, like a CD or a thumb-drive. It's just a matter of setting up the configuration correctly.
You might be able to get away with creating operating-system packages for most of your work, but that still means you have to compile them at least the first time.
1) How/Where to get specific versions of Perl modules, e.g. CGI.pm etc
http://search.cpan.org/
If you don't want the latest version, you can get an earlier version by following the link in the breadcrumbs.
http://img.skitch.com/20091209-bu7kt3bj65374k7iijfnhrue2y.png
2) How to install these Perl modules. Is it a case of just placing them
in a directory somewhere, e.g. a library path and making sure that this
directory path is in the #INC library path environmental variable, if
it is not already?
That sometimes work, but you really should go through the perl Makefile.PL && make && make test && make install process.
Doing this would require that you manually chase all the dependencies though. You would probably be better off with something like minicpan.