Re^3: Secure deployment of binary perl modules

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

Comment on Re^3: Secure deployment of binary perl modules

Replies are listed 'Best First'.
(OT) Re^4: Secure deployment of binary perl modules by Argel (Prior) on Mar 21, 2007 at 01:00 UTC
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]
Re^5: Secure deployment of binary perl modules by blue_cowdawg (Monsignor) on Mar 21, 2007 at 14:29 UTC
Just because it does not meet your needs does not mean it is broken. I'm sorry... but that smacks of "we know what's best for you." I beg to differ. If sometihng that is shipped with an OS doesn't meet my needs it is IMHO by definition broken. I have a table saw in my workshop. Its table is only two feet wide. I regularly cut four foot by eight foot sheets of plywood on it. So I have feed extensions that I've added to the mix to help with that. Further, that table saw came with a rip blade that is not suited to cutting plywood. Do I leave the rip blade in there assuming the saw manufacturer knows what's best for me and deal with the mess or do I buy a blade more suited to cutting plywood and install it? Geez.. by your definition I'm messing with the design of the table saw. I won't even get into the modifications I've made to the saw itself including the much improved blade guide I added. (Thank you Workbench magazine!) Do you make sure that SUNWpl5u (and the supporting packages) are uninstalled (or never installed)? As a matter of fact the latter. SUNWpl5u is specifically left out of our builds because of the issues I've already outlined. 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? What part of my comments made you think that things aren't tracked? You mention Sun's JES Directory server. Not used in my shop since we used OpenLDAP for the same thing. One of the reasons I've already mentioned for doing what I do. Fiber monitoring tools? Again. Not an issue in our shop. However it was in a previous shop that I worked for and our version of Perl that we packaged worked fine. Do you have a list of every script on your system that uses /usr/bin/perl? Considering that my shop is the only one doing scripting in Perl? That's a safe assumption. Since 2001 when I joined this shop we have yet to run into an issue like you are describing. Our testing is rather thorough so we must be doing something right. Anyway, I hope you get the idea (if nothing else that your decision can have unforeseen future ramifications). Which is why we test. And test again. In fact we have one system in particular dedicated to that end. It is rebuilt every week automatically and the latest patches (along with the latest versions of our internal packages) applied to it. This is how we detect bad patches (something Sun has excelled at producing lately for Solaris 10) before they are applied to our production environment. Peter L. Berghold -- Unix Professional Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg	[reply]
Re^6: Secure deployment of binary perl modules by djp (Hermit) on Mar 22, 2007 at 02:41 UTC
Regardless of how well you control it, your practice is not good. /usr/bin is for the manufacturer, /usr/local or similar is for you. 'man filesystem' for details. Your advice to others to blithely poke stuff into /usr/bin is worse, as it does not even mention the detailed controls you practise yourself.	[reply]
(OT) Re^6: Secure deployment of binary perl modules by Argel (Prior) on Mar 21, 2007 at 17:21 UTC
Ever heard of the phrase "the exception that proves the rule"? Looks like you are on top of things but most places will not be and recommending a solution that is more likely to fail for others or create a lot of extra overhead is irresponsible. You still did not really address future ramifications. With XML in Solaris 10 I expect to see more use of Perl. And I already pointed out that SUN's directory server uses it in places. What if you need to install something that does require SUN's perl? What if you do find a compatibility issue? Keep in mind that catching these in test makes you aware of the problem in a safe environment but you would still have to resolve the problem before you could move to production. The examples I mentioned were just to point out that the vendor supplied perl is used. You may not be using it but again, if you give advice to others you should be considering that they might be. I still say the vendor supplied version is not broken. Did it occur to you that it may be included for the vendor to make use of in other parts of the OS? Or that it is there for additional applications that they or other vendors provide (or may provide in the future). And if one of those breaks that you can call in and get support for it? If nothing else it seems like a huge waste of time and resources. Why not just install all of your stuff to e.g. /opt/mycompany/. Then there is no need to worry about tracking what uses SUN’s perl, patches that specifically break things, future compatibility issues, and upgrade issues. Granted, what you are doing seems to work for you and you have already invested the time to set the environment up. But it’s not something I would recommend to others except in very rare instances. As for Solaris patches, I one million per cent completely agree with you.	[reply]