Centos OS version:
Perl Install 5.10.1
I have a Centos 7 server with PERL 5.10.1 that is needed for my application.
When I run the install.sh,
It installs another version of perl and crashes on Phase 3.
Can’t locate File/Path.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/share/perl5/vendor_perl/Virtualmin/Config/Plugin/ProFTPd.pm line 56.
BEGIN failed–compilation aborted at /usr/share/perl5/vendor_perl/Virtualmin/Config/Plugin/ProFTPd.pm line 56.
Compilation failed in require at /usr/share/perl5/vendor_perl/Module/Load.pm line 27.
Can’t locate Virtualmin/Config/Plugin/ProFTPd in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/share/perl5/vendor_perl/Module/Load.pm line 27.
▣▣▣ Cleaning up
[WARNING] The following errors occurred during installation:
◉ Postinstall configuration returned an error.
it has installed another version of Perl in: /usr/bin/perl5.16.3
My original Perl version 5.10.1 is installed in:
Is it possible to make the installer work with the Perl 5.10.1 as the base system?
You’re missing a dependency, but you absolutely cannot pre-install a different Perl (or MySQL/MariaDB, or Apache, or nginx, or postfix, or anything else) before running the Virtualmin installation. You must install Virtualmin before any other third party packages or whatever else. After Virtualmin is installed, then you can (with care) add other stuff, change versions, etc. We will only ever support installation on a freshly installed OS, and this is documented on the download page and in the extended install docs. It’s wildly complicated enough to make all these pieces work together without trying to hit moving targets that y’all are throwing at us, too.
We targeted 5.10.1 as our lowest supported Perl version until CentOS 6 reached end of life. Now our lowest supported Perl version is the Perl 5.16 version found in CentOS 7. But, it probably still works on 5.10.1, as we don’t rush out to use new features…they just come as we find them useful and they can improve the readability or reliability of the code.
But, you shouldn’t make your whole system use a custom Perl. Add your custom Perl to the path just for the users with apps that need it (this may be all of your Virtualmin domain users, whichever ones need to run your app that needs a very old Perl, but it should not be Virtualmin itself). There is no reason to force everything to use an ancient Perl, and we can’t commit to supporting Perl 5.10.1…it probably works today, but probably won’t for very long. Two (or thirty) Perl versions can happily exist together on one system. I recommend perlbrew or plenv for providing custom Perl environments for every user (but, again, if all of your users have to have the same old Perl environment, you do need a system-wide local install…but keep it out of the path for Webmin/Virtualmin, and you may need to do a little bit of hackery to make the virtualmin and webmin commands work for the root user, since I assume you want the old Perl to be the default for root).
But, also be aware that the Perl developers themselves haven’t supported Perl 5.10.1 for like a decade. The last people doing any work on it were Red Hat with their maintained RPM fork for RHEL 6 (which also appeared in CentOS 6). You’re absolutely on your own using a Perl version that old.
Last night I just added the missing module (because your installer for some reason), even though it installed the perl 5.16 in its custom paths, could not fine the Module/Load.pm , even though it was there. ie: /usr/libexec/webmin/authentic-theme/lib/File/Path.pm
So, I just after the first failure I manually installed it, in the 5.10 directory by doing
/bin/yum -y install perl-File-Path
That worked and the installer was able to complete
It added the module in: /usr/local/src/perl-5.10.1/lib/File/Path.pm
As I stated, I love the Virtualmin, but I am trying and testing many ways to solve the suexec cgi issue of the Apache build you install. First I am working on duplicating the PERL version and Modules installed on our current production system, and also need to test if the perl solves it. But I am not having success yet, but am writing a script to duplicate all the current Perl modules on our Production system into the Perl 5.10.1.
Then I have other issues regarding now learning how to build a custom version of apache, and to get safe mysqld running so it makes the mysq.sock that I need to talk to mysql.
I will write another forum post for each unique issue as you discussed. But this one of finish installing is done.
You can see the install log from virtualmin here.:
Yes Joe, I have been on my own with PERL since 1995 when I started netstores, and have gone through all the PERL version since perl 4, but now it is time to try to move away from Cpanel, since they have priced us out of the market, and I want to maintain our 25 source code for QBPOS nad Quickbooks.
I might fail, but like all things, I am relentless. I am very impressed with virtualmin, but I just need to fix these issues of the PERL application to run on 5.16 (first do 5.10.1 and see if I get it working).
You may have noticed I have part of the code working on CENTOS 7 and Perl 5.16, but I have come up with a major snag and can not figure it out (the logs don’t give me enough detail yet to find the issue)
I may have to hire a Perl expert to track it down, but you can see part of the cart work (in a user directory) @