• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2225
  • Last Modified:

installing crypt and blowfish perl modules

Hi, I want to install the latest Crypt::CBC and Crypt::Blowfish modules on a Linux computer.

First I installed the RPM Forge repo and downloaded and installed both Crypt::CBC and Crypt::Blowfish

After installation I ran the perldoc perllocal command and received the following:

Tue May 19 05:09:46 2009: "Module" Crypt::CBC
¿· "installed into: /usr/lib/perl5/site_perl/5.8.8"
¿· "VERSION: 2.30"

Tue May 19 06:07:57 2009: "Module" Crypt::Blowfish
¿· "installed into: /usr/lib/perl5/site_perl/5.8.8"
¿· "VERSION: 2.10"

The version numbers haven't changed since pre-installation and the date reflects 2009 instead of 2001. Could the modules have been installed somewhere else? How do I locate them?

Furthermore the paths where I located these modules are longer than those displayed with the perllocal command.



Finally the file details show 2008 and 2005, instead of the 2009 shown by perllocal. Would the above permissions and root ownership allow these modules to run?

-r--r--r-- 1 root root 5033 Dec 2 2005 Blowfish.pm

-r--r--r-- 1 root root 37288 Sep 30 2008 CBC.pm

Thanks for your help!

  • 7
  • 4
  • 4
2 Solutions
As root
perl -MCPAN -e 'install Crypt::CBC'
There is a way to tell it to overwrite the existing module "uninstall=1" has to be added to the line , but I do not recall the exact format.
If you run and the install fails because of the overwrite restriction, it will tell you how to include the uninstall=1 option and you would need to rerun the process.
Check what the date time stamp on the folder is
ls -l /usr/lib/perl5/site_perl/5.8.8/ | grep Crypt
nociSoftware EngineerCommented:

are the directories that belong with one perl instance.
the raw directory mostly are the with the  product installed modules (can contain modules deemed essential for perl functioning by distro owner).
the vendor_perl ... subtree is the installable packages for the distro maintainer (mostly add ons per distro)
the site_perl subtree is what you install personally  (CPAN installed modules).

You can get the search order using perl -V
(default is current version site_perl first, then vendor_perl, then all previous versions of site_perl, then all previous version of vendor_perl and finaly the raw directory of the current version.   (/usr/local/lib/... may have a cameo role, a the end).
netplus21Author Commented:
The date stamp is drwxr-xr-x  2 root root 4096 May 19  2009 Crypt

Arnold: I installed both Crypt::CBC and Crypt::Blowfish using the command you gave me and both installations were successful.

How can I be sure that they are in the correct folders? The script which I want to use has the following reference:

      use Crypt::CBC;

Do I need to change any permissions or ownerships?
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

nociSoftware EngineerCommented:
You can try to use perl interactive...

$ perl
use Crypt::CBC ;

And in an other windows/terminal you can use lsof -n | grep perl
to see if sharable object get loaded (.so) files,

perl -V will give you the search path in the order it uses it.
So if it is in the first directories it will use those paths.
you can run
find /usr/lib/perl5 -name "CBC.pm" and the same for Blowfish.pm to see where they are and whether you have more than one instance.

Usually the Makefile.PL directs the module into the correct location.

The permissions should be correctly set by the install process which is part of the perl -MCPAN install directive.
netplus21Author Commented:
Noci:  not quite sure what you meant with that code.

Here are some results, after typing perl -V


find /usr/lib/perl5 -name "CBC.pm"

Here is the instance of CBC at the first address: /usr/lib/perl5/site_perl/5.8.8/Crypt/CBC.pm
-r--r--r--  1 root root 37288 Sep 30  2008 CBC.pm

Here is the instance of CBC at the second address: /usr/lib/perl5/vendor_perl/5.8.5/Crypt/CBC.pm
-r--r--r--  1 root root 37288 Sep 30  2008 CBC.pm

find /usr/lib/perl5 -name "Blowfish.pm"

Here is the instance of Blowfish at the first address: /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/Crypt/Blowfish.pm

-r--r--r--  1 root root 4769 Mar  4  2010 Blowfish.pm

Here is the instance of Blowfish at the second address: /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/Crypt/Blowfish.pm

-r--r--r--  1 root root  5033 Dec  2  2005 Blowfish.pm

How does it look? Can I make sure that I have the Makefile.PL file and that it is successfully directing the script to look for the most current CBC and Blowfish modules?
you may have two versions of perl installed or you had 5.8.5 and you've updated to 5.8.8.

perl -v will tell you the version and by extension which files will be used.

ls -li /usr/lib/perl5/site_perl/5.8.8/Crypt/CBC.pm /usr/lib/perl5/vendor_perl/5.8.5/Crypt/CBC.pm
To see whether they are the same using the inode references..

The list you see following Noci's directive is the search path.
I.e. CBC.pm in the 5.8.8 will be found before the 5.8.5.

Which linux distro are you using?
nociSoftware EngineerCommented:
Appearantly there are 6 versions installed over time... 5.8.3 - 5.8.8
The vendor_perl & site_perl still have modules left in them (no problem for .pm modules, might be a problem for .so
shared objects / libraries).
Modules are searched in the order specified (top->down).


There is only ONE active perl 5.8.8:

So any live module should be in 5.8.8 and those are found first, the site_perl  is used first (any version) then vendor_perl any version. So your site should at least use the site_perl/5.8.8 before vendor_perl/5.8.7
nociSoftware EngineerCommented:
Now there code answer:
if you run perl interactive:

$ perl

end then type

use Crypt::Blowfish ;

Dont close the session just leave it.
On an other terminal window/session/terminal you can use lsof (list open files)
to see which shared object is used. (Most encryption stuff is done in libraries which are bridged using a .pm (perm part of the interface) and an .so (which access the library).
Here an example of lsof -n | grep from my machine: (I am using DES as an example)

perl      16934       test  cwd       DIR              254,8      4096    1884664 /home/test
perl      16934       test  rtd        DIR              254,6      4096          2 /
perl      16934       test  txt       REG              254,6     10264    1238286 /usr/bin/perl5.12.4
perl      16934       test  mem       REG              254,6     22624    1270123 /usr/lib64/perl5/vendor_perl/5.12.4/x86_64-linux-thread-multi/auto/Crypt/DES/DES.so
perl      16934       test  mem       REG              254,6    135467     796910 /lib64/libpthread-2.12.2.so
perl      16934       test  mem       REG              254,6     34920     797127 /lib64/libcrypt-2.12.2.so
perl      16934       test  mem       REG              254,6    526464     797139 /lib64/libm-2.12.2.so
perl      16934       test  mem       REG              254,6     14512     797016 /lib64/libdl-2.12.2.so
perl      16934       test  mem       REG              254,6   1465552     797120 /lib64/libc-2.12.2.so
perl      16934       test  mem       REG              254,6   1540624    1238540 /usr/lib64/libperl.so.5.12.4
perl      16934       test  mem       REG              254,6    128464     797034 /lib64/ld-2.12.2.so
perl      16934       test    0u      CHR              136,3       0t0          6 /dev/pts/3
perl      16934       test    1u      CHR              136,3       0t0          6 /dev/pts/3
perl      16934       test    2u      CHR              136,3       0t0          6 /dev/pts/3

I highlighted the actual perl version & the DES shared object. In your case DES should be replaced with Blowfish or CBC
netplus21Author Commented:

I typed $ perl and received the message
 -bash: $: command not found

I then just typed perl and nothing happened apart from the screen going down one line and a green box showing up.

I then tried to exit and received the message, stopped jobs. I typed jobs and found a perl job running. I exited again after that. Do i need to restart perl?
([1]+  Stopped                 perl  (wd: ~))


From your first message, can you tell me the command to uninstall the previous installations? I have the results of perl -v listed above.

Typing ls -li /usr/lib/perl5/site_perl/5.8.8/Crypt/CBC.pm /usr/lib/perl5/vendor_perl/5.8.5/Crypt/CBC.pm
produces the same references as listed previously.

Linux version: Linux 2.6.9-101.ELsmp

My basic question is whether I have managed to install the latest versions of CBC and blowfish. Is a script which is calling these programs accessing the latest versions or the old ones?
nociSoftware EngineerCommented:
if you just type perl then (without the $) the interpreter will start reading from the terminal (i.e. YOU are the script..) (The $ wat cut/paste copied from the screen.)

Closing the interpreter can be done with either ^C (abort) or ^D (end of input).

The vendor_* stuff is installed using rpm's you can try to install fresher ones...
using yast, rpm ... that SHOULD clear out the old entries.
The site_* stuff is installed using CPAN or private install commands.
If you lookup what modules are mentioned there (say Crypt::CBC) that translate to the file Crypt/CBC and back of course..
Reinstall the new ones and then just delete the directories from the old tree.
if all modules are reinstalled then the old tree should be empty and can be deleted.
nociSoftware EngineerCommented:
And ^Z is jobmanagement on linux and means push the foreground job to the background.
Using the fg command it can be pulled to the terminal.
The ls li should have an inode number as the first entry which is not part of the output you posted.
inode#    Permiss  links owner group size date filename/directory
1083660 -rw-r--r-- 1 root root 66 Nov 26  2010 test

Do not recall whether the order in which the option uninstall=1 has to be provided and if that was an option you would have received the error saying unable to install an existing version install run the perl -MCPAN -e 'install package; UNINSTALL=1;' or something like that.

There is a significant difference between perl -V and perl -v -v returns the version.
look in /usr/bin/perl* you should have here perl5.8.5 perl5.8.6 perl5.8.7 and perl5.8.8 to which perl is pointing.
You could delete the /usr/lib/perl5/Versions_different_from_your_installed_perl.  Note that if you have extraneous modules on which your system relies, you would have to reinstall them.
netplus21Author Commented:
noci: I tried the method listed above with the two terminals.

These are the instances of 'crypt' or 'cbc' that came up with 'use Crypt::CBC;'

perl       9520     root  mem       REG        8,4    41956    8863802 /lib/libcrypt-2.3.4.so

These are the instances of 'crypt' or 'blowfish' that came up with 'use Crypt::Blowfish;'

perl       9148     root  mem       REG        8,4    51808    4227085 /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Crypt/Blowfish/Blowfish.so

perl       9148     root  mem       REG        8,4    41956    8863802 /lib/libcrypt-2.3.4.so

perl -MCPAN -e shell
m module_name

Using the above command I received the following installation paths for CBC and Blowfish

INST_FILE    /usr/lib/perl5/site_perl/5.8.8/Crypt/CBC.pm
INST_FILE    /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/Crypt/Blowfish.pm

Since CBC.pm  didn't show up with $perl and the ''use Crypt::CBC' command, does this mean that a script which calls it will not be able to find it either?
nociSoftware EngineerCommented:
THe .pm will not be shown (it is opende, read, compiled & closed) before use.
The .so that are loaded will be seen.

The CBC modules uses the standard OS libraries for encryption.
From the blowfish version you can see it uses the 5.8.8 shared object ==> 5.8.8 modules installed.
 the blowfish library as well as the CBC modules use the /lib/libcrypt as a shared object.

For the files you should trust the search order as shown previously with perl -V.
The use of 5.8.8 shared object (.so) (which is visible)  should be seen as proof of this concept/.

When you are severly in doubt you can always remove the OLDER versions of a module (or sabotage them to provoke an error message).

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 7
  • 4
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now