|Do you know where your variables are?|
How to run a legacy perl version smoothly from perlbrew & Cartonby chrestomanci (Priest)
|on Dec 17, 2020 at 13:11 UTC||Need Help??|
chrestomanci has asked for the wisdom of the Perl Monks concerning the following question:
Greetings wise brothers, I seek your advice on how to concurrently access the old and the new.
I am working on a legacy Perl system that makes heavy use of Storable objects (in a database, traversing the network etc), so it has to run Perl 5.10.1 and no other version. Up until now, it has been run on Ubuntu 10.04 Lucid, which means running a 10 year old Linux distro (with no support) on 10 year old hardware also with no support that could die at any moment.
I would like to migrate the system to a modern OS (Ubuntu 20.04 Focal) and hardware, while using perlbrew to run the application using the correct Perl version. I have successfully built and installed Perl 5.10.1 and all the necessary libraries using Carton, but I have two problems with this setup that I would like to solve.
Firstly, to run a Perl script with the correct libraries, I need to put “carton exec” on the front of each script invocation. If you don’t do that then the correct Perl binary runs, but it fails because it cannot find the modules that carton installed.
How can I arrange things so that just running perl from a shell will do the right thing? (Run Perl 5.10.0 with the carton installed modules available), Perhaps by tweaking PERL5LIB for bash shells, or putting a wrapper script into the path? (note that I don't need to worry about multi user accounts here, all users login as root!)
Secondly, there are about 200 CGI scripts mostly in Perl, and each with a #!/usr/bin/perl shebang line. How should I configure Apache to call my perlbrew installed version of perl, again with the carton installed modules, preferably without re-writing the shebang line on every script, though if I must do that, then the change needs to be backwards compatible with the old setup.
Note that this is plain old CGI, not modperl FastCGI or anything like that. I would not object to using an FCGI wrapper if it can be dropped in painlessly, but not if it would require modifications to the scripts, or could be a source of bugs or incompatibilities.
And before you say it, Yes I am well aware that it would be better to migrate away from Perl Storable. I have seen Elizabeth Mattijsen’s talks on how Booking.com did so at various Perl events. I also know that plain old CGI is no longer considered best practice. My problem is that this is a legacy system, and there is not much time or money available for major system changes, and there is no appetite for anything that could introduce hard to find bugs.