in reply to Secure deployment of binary perl modules

I've solved this issue a couple of different ways on a number of different platforms. Let me talk about two of those:

One environment I worked in I created a Solaris pkg file of a standardized Perl distrobution that I engineered. We took a development machine, put together a tree under a directory called /usr/local/software/perl-{VERSION} and installed all the CPAN modules we felt we needed to standardize on there. Once that was done we used the normal Sun packaging tools along with some cleanup scripts to do things like link the Perl executable into /usr/bin/perl the library tree to the right place, etc.

In one other environment ("a major financial compnay") AFS was the standard way of "distributing", for a lack of better word for it, software packages. Again, development and test machines were employed to put the dietributions together and put them on the AFS cells. In that environment we had many platforms to support so some automounter tricks were used to make sure that the right version of the Perl trees were mounted on the machines accordingly. AFS was laid out to accomodate the architecture differences between the platforms and the automounter maps for them configured accordingly.

Peter L. Berghold -- Unix Professional
Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg
  • Comment on Re: Secure deployment of binary perl modules

Replies are listed 'Best First'.
Re^2: Secure deployment of binary perl modules
by djp (Hermit) on Mar 20, 2007 at 01:55 UTC

      to do things like link the Perl executable into /usr/bin/perl

    Bad advice. You shouldn't mess with the base OS, who knows what that might break. Install your own Perl somewhere else, for example /usr/local/bin/perl or /opt/local/bin/perl.

[reply]
          You shouldn't mess with the base OS,

      Huh? /usr/bin/perl is an installed application like any other and is not the OS. So, what you are telling me is that it is better to leave a broken Perl in place than replace it with one that works?

      Let me give a really good example of why I'll put my own copy of /usr/bin/perl in place of one that is there already. Solaris 10 comes with a version of Perl. Unfortunately it is compiled with Sun's own liscenced compiler. If I just want to accept the list of CPAN modules that Sun has so graciously supplied then that's ok.

      However, in this case our environment, which stores all user account information in LDAP needs to have Net::LDAP and friends installed on all the servers for some of our user administration tools to work. Since our LDAP servers are connected to via LDAPS and not clear text LDAP we need the whole family of SSL related modules compiled in as well.

      None of those will work correctly if you try and compile them with a compiler other than Sun's compiler assuming we leave Sun's version of Perl in place.

      Contractual and financial realities being what they are on that account we are not going to be having access to a Sun compiler anytime soon, so we use GCC.

          who knows what that might break.

      That's where proper engineering practices come into play. Anything we do in our production environment has already been done on test boxes. While we don't have the luxury of an official Sun compiler, we do have test boxes we can do things to before impacting production.

      So, your argument of "don't mess with it" in this case doesn't hold much water. I would agree with your assesment if proper engineering wasn't done ahead of time and without a good understanding of the systems and applications involved.

      Peter L. Berghold -- Unix Professional
      Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg
[reply]
        I’ll throw my $.02 into the ring….

        Solaris 8 on up ship with a /usr/bin/perl. Therefore by definition if you replace it you are “messing with the OS”.

        Just because it does not meet your needs does not mean it is broken. It is the Perl that the OS vendor and those who develop for that platform expect to be there and that is what is important to keep in mind and that is why it should not be replaced.

        Do you know what parts of the OS use the vendor supplied Perl? Do you know what additional applications use it? Do you know what will use it in the future? Catching one of these problems in test is good but it doesn’t change that you would have to do some re-engineering.

        Do you make sure that SUNWpl5u (and the supporting packages) are uninstalled (or never installed)? Or do you leave the packages out there and just overwrite the files? If you leave the packages there then what do you do regarding patches? What do you do when upgrading the OS? What if the new OS has dependencies on /usr/bin/perl that the previous version did not?

        Let’s talk about your test environment. Do you have a list of every script on your system that uses /usr/bin/perl? Do you specifically test these for compatibility as part of your testing process? Do you update your list? From your post it sounds like the answer to all of these is a negative. Wouldn’t proper engineering be to document everything that relies on /usr/bin/perl, keep that list up to date, and test everything that actively uses it?

        Looking at a couple systems here it looks like /usr/bin/perl is used by Gnome, fibre monitoring tools such as SUNWstade, and some Internationalization tools. And here’s a big one -- SUN’s JES Directory Server, which is now included with Solaris (starting with one of the later Hardware Releases for Solaris 9 I believe). And that’s just from a quick look.

        Anyway, I hope you get the idea (if nothing else that your decision can have unforeseen future ramifications).

[reply]

In Section Seekers of Perl Wisdom