Re: OpenBSD or FreeBSD for a Perl web app Production platform?

[graff]

I don't have any experience on OpenBSD, so I have no clue how it might differ from FreeBSD. Based on my experience with Perl on FreeBSD, I'd have to say there are things that can go wrong too easily.

What heppened to us on more than one occasion was that there would be a "normal, routine" update or patch or release upgrade of the OS, and suddenly a lot of perl scripts would stop working, because the version of /usr/bin/perl had suddenly changed (unannounced to the perl programmers), this somehow involved a change of "standard" paths in @INC (because /usr/lib/perl5 is organized by version, even inside site_perl), and a lot of non-core modules were suddenly not being found.

When these "transitions" happened, there would be momentary panic, then all manner of diverse, inconsistent corrective measures (TMTOWTDI showing its dark, monstrous side), and an enduring sense that the perl environment as a whole was dreadfully fragile.

(Problems were sometimes amplified when various hosts on the local network -- servers and workstations sharing the same nfs volumes where someone might run the same script in a shell on any machine -- would somehow end up with different perl versions and different module inventories. But that's more a matter of sysadmin behavior, not anything intrinsic to the choice of OS.)

Maybe it was just pilot error on the part of the guys who were playing sysadmins when the troubles happened, or maybe our group as a whole was just missing a something fundamental about managing Perl in a non-simple FreeBSD network, or maybe it really is something that's hard to get right. I wish I knew.

It's also entirely possible (maybe even likely) that none of this would be relevant or at all likely in your situation.

[samizdat]

I agree with you, graff, that this does happen.

I am always p-o'd by things that are in site_perl/5.8.6/blah instead of site_perl/blah, but that's an application of the philosophy of upgrading that does its best NOT to overwrite configurations. That has been The Berkeley Way from Day 1, but is it only FreeBSD ports that do this? The same philosophy applies to unpacking directories when porting, so that apache-1.3.36 is not overwritten by 1.3.37, for example. One could argue that modules are runtimes and therefore should be in common directories, but they're also source, and thus -- by the philosophy -- should not.

Yes, you do have to sweep the module directories up to the generic before going into production or do a manual port upgrade of each module, and, no, that's not mentioned except in The manpage of Hard Knocks. I'd rate the power of the ports collection and portupgrade system as far and away better than any other installation system on any *NIX, but it doesn't pretend to protect admins against the need to understand what's happening with each and every package used in production.

Of course, that's why the new boxes I mentioned get upgrades and testing before they go live. We never upgrade production boxes on the fly; some of ours are still running 4.10. I can't say we have never been bitten, and certainly I'm waaaay far short of the all-knowing guru I've made it sound like I am/we have, but that's why you build and test off-line.

FreeBSD is not meant to be the idiot's way to riches, but it sure _is_ the poor geek's toolbox for Internet success.

[sth]

This is why I install my own perl in /usr/local/perl-x.x.x. I have code that I use here at work to use CPAN and install all the modules we need. Then I have a link /usr/local/perl which points to the production version. I like this setup since I can install a new version of perl and modules, have users test using the self contained install. When testing is done, I point /usr/local/perl to the new version directory. I let the ports that need perl install it and let portupgrade handle the updates.

[graff]

Heheh... Yeah, playing with "#!/usr/bin/perl" vs. "#!/usr/local/bin/perl" is something we've done in the past as well -- but that was a case of maintaining both a really ancient "system default" installation for solaris (that was /usr/local/bin/perl -> perl4) along side a not-too-ancient perl5 (/usr/bin/perl -> perl5.3).

It makes life tolerable, but there are still traps for the unwary -- e.g. when scripts are copied in from other places that don't happen to share this subtle distinction in perl paths. Just another of those gritty details that users of perl scripts need to stumble over now and then...

We could also opt for "#!/usr/bin/env perl" as the shebag line, and control the relative ordering of /usr/local/bin and /usr/bin in PATH. But that's not exactly a comfortable solution either; it just passes the discomfort to the user's shell environment instead of the script maintainer's choice for the shebang line, which is probably a really bad idea.