How can allow for non root users to use Perl modules that are installed by root?

Question

I am using centos7 cluster, and I use root to install all required perl modules, but when I check on the installed perl modules form normal user account there is no modules listed as root user.

How can allow for non root users to use Perl modules that are installed by root?

This is directories where is Perl install

[root@mu ~]#  perl -e 'print join "\n", @INC'
/root/perl5/lib/perl5/x86_64-linux-thread-multi
/root/perl5/lib/perl5
/usr/local/lib64/perl5
/usr/local/share/perl5
/usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl
/usr/lib64/perl5
/usr/share/perl5

For root user

[root@mu ~]# which perl
/usr/bin/perl

For non root users

[bio@mu ~]$ which perl
/bin/perl

perl version for all users is

[root@mu ~]# perl -v

This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi

For root user: echo $PATH and $PERL5LIB

[root@mu ~]# echo $PATH
/opt/software/edirect:/opt/software/BEASTv1.10.1/bin:/opt/software/genometools-1.5.9/bin:/opt/software/ncbi-blast-2.7.1+/bin:/opt/software/bedtools2/bin:/opt/intel//impi/5.0.2.044/intel64/bin:/opt/intel/composer_xe_2015.1.133/bin/intel64:/opt/intel/composer_xe_2015.1.133/debugger/gdb/intel64_mic/bin:/usr/java/jre1.8.0_151/bin:/usr/java/jre1.8.0_151/bin:/opt/tsce/maui/sbin:/opt/tsce/maui/bin:/opt/tsce/torque6/bin:/opt/tsce/torque6/sbin:/usr/local/bin:/usr/lib64/qt-3.3/bin:/root/perl5/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/opt/ibutils/bin:.:/lustre/shared/software/maker/bin:/root/bin
[root@mu ~]#  
[root@mu ~]# echo $PERL5LIB
/root/perl5/lib/perl5:
[root@mu ~]# 

For non root user: echo $PATH and $PERL5LIB

[bio@mu ~]$ echo $PATH
/opt/software/edirect:/opt/software/BEASTv1.10.1/bin:/opt/software/genometools-1.5.9/bin:/opt/software/ncbi-blast-2.7.1+/bin:/opt/software/bedtools2/bin:/opt/intel//impi/5.0.2.044/intel64/bin:/opt/intel/composer_xe_2015.1.133/bin/intel64:/opt/intel/composer_xe_2015.1.133/debugger/gdb/intel64_mic/bin:/usr/java/jre1.8.0_151/bin:/usr/java/jre1.8.0_151/bin:/opt/tsce/maui/sbin:/opt/tsce/maui/bin:/opt/tsce/torque6/bin:/opt/tsce/torque6/sbin:/usr/local/bin:/usr/lib64/qt-3.3/bin:/lustre/bio/perl5/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/opt/ibutils/bin:.:/lustre/shared/software/maker/bin
[bio@mu ~]$ 
[bio@mu ~]$ echo $PERL5LIB
/lustre/bio/perl5/lib/perl5:
[bio@mu ~]$ 

Answer 1

I think you're slightly confused. @INC contains a list of directories where Perl will search for modules. You won't see the names of individual modules when printing the contents of @INC . The actual modules will have been installed under the directories listed in your output.

If you want to see where a module has been installed, you can use perldoc -lm .

$ perldoc -lm Template
/usr/lib64/perl5/vendor_perl/Template.pm
$ perldoc -lm Time::Piece
/usr/lib64/perl5/Time/Piece.pm

Update: You can get a complete list of the modules that are installed in the various @INC directories by running a command like this:

$ perl -MFile::Find -E'find sub { say $File::Find::name if -f and /\.pm$/ }, @INC'

Update: Changed perldoc -l to (better) perldoc -lm .

Update: If there are differences between the lists of modules that users and root are seeing, then the most obvious problem is that the two types of user are running different versions of Perl. Try running which perl as both types of user and add the output to your question.

Another Update: Ok, looking at the paths that you have added to the question, it looks like there are several versions of Perl installed. There's the system Perl in /usr/bin/ , there's another Perl in /bin/ and it looks like there's at least one more in /lustre/bio/perl5/bin . There may well be more.

Each installation of Perl will have its own module library. And it's really not a good idea to use one Perl installation's module library with a different Perl installation. Even if they are the same version of Perl, then they could have been built with different compiler flags which would affect how well compiled modules would work.

When you install a Perl module from CPAN, it installs it in the module library associated with the Perl installation that you are currently using. So it looks like your root user has been installing modules into the library directories associated with the system Perl.

So you need to pick a Perl installation that you want to use. It seems likely that you want to use the system Perl as that's the one that the root user is using and it appears to be the one with the most modules installed. But someone who knows more about why there are multiple installations on that machine may be able to give you better advice on why you should choose between the various Perl installations on the machine.

Once you've picked a Perl installation, you need to ensure that your $APTH variable is set so that your shell finds that Perl executable first. And you need to set your $PERL5LIB variable so that it finds the correct module library for that installation (although it's worth pointing out that all Perl installations have a default module search path "burnt into" them as they are built and unless you're doing something clever, it's likely that you don't actually need $PERL5LIB to be set at all.

All in all, it seems that your server has been configured by various people over the years and they've all installed their own version of Perl for reasons that I can only guess at. The best option is almost certainly to talk to people who have more knowledge of the history of that server.

Answer 2

The problem is that the perl-homedir RPM sets up a local::lib for all users, including root, so any modules installed as root get installed to its local::lib instead of the global sitelib as expected. You can either remove perl-homedir, or exclude the root user as detailed at https://bugzilla.redhat.com/show_bug.cgi?id=1709491 .

Since installing to sitelib can cause issues by changing what the package manager expects to be globally installed, and modules in either the sitelib or any local::lib will be broken when the package manager updates to a new major version of Perl, my preferred solution is instead to either install to a custom local::lib (easily done with cpanm ) and then add that directory to the PERL5LIB for all users that wish to use it:

cpanm -l /opt/perllib Foo::Bar
export PERL5LIB=/opt/perllib/lib/perl5:$PERL5LIB
# or to activate it in the current environment so any modules get installed there
eval "$(perl -I/opt/perllib/lib/perl5 -Mlocal::lib=/opt/perllib)"

Or, install an entirely separate Perl and add this Perl's bin directory to the path for any users that wish to use it - this Perl's sitelib can then be customized without affecting the system. This is easily done with perl-build .

perl-build 5.30.1 /opt/perl-5.30.1
export PATH=/opt/perl-5.30.1/bin:$PATH