Not entirely sure if I understand your question, but we use a test server
that runs the exact same software as our production web server for testing
changes to the web sites before they go live. In our application hardware
does not necessarily need to be identical on both boxes, but it is important
that the software matches as closely as possible. Make SURE your config
files match as we found out the hard way with a register_globals issue!


Justin Moore
Systems Administrator
Dacasso, Inc.
2350-B NW 71st Place.
Gainesville, FL  32606
Phone: (352) 331-4710
Fax: (352) 331-5994
-----Original Message-----
From: Jim Martinez [mailto:[log in to unmask]] 
Sent: Wednesday, March 07, 2007 4:38 PM
To: [log in to unmask]
Subject: Re: Use of uninitialized value in concatenation (.) or string at
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/Scalar/ line 30

Does anyone have experience using a staging server for QA?  Will a some
type of pre production environment that "closely" resembles the production
environment help?

I wish I had staging area, but maybe it really wouldn't help.  Having a
test suite for web applications helps.

Also I wish I had this staging area when trying to reproduce bugs.  I've
experienced the Heisenberg principle, where the act of looking for a bug
somehow influences the system.

Nice post, Shawn.


On Mar 6 Shawn McMahon wrote:

> On Sun, Mar 04, 2007 at 01:04:41PM +0200, Arthur Sherman said:
> > 
> > I wish I knew how to revert to previous module in CPAN.
> > Tried once figure it out and couldn't find anything useful.
> This doesn't help you, but for the peanut gallery:
> This is why you shouldn't bypass your packaging system.  Before updating
> anything, a better idea is:
> 1) Use "rpm -qf" to find out what package owns the file.
> 2) Download source for that package.
> 3) Download source for what you want to add.
> 4) Create a new package containing your additions.
> 5) Configure the package manager not to automatically upgrade this
> package anymore.
> 6) Expect to spend eternity manually integrating upgrades into your
> system in this manner every time a new version of the base package comes
> out.
> For the special case of perl, here's what we do:
> 1) Leave the "system" perl alone.  We don't add ANY module to it that
> doesn't have an RPM from RedHat, period, and even those rarely.
> 2) Create our own perl and perl-modules packages that install in
> "/opt/perl", and integrate all requested modules into it, updating these
> only as required to serve our development teams.  It contains a whole
> lot of modules, and any time we add a new module we do so by updating
> the perl-modules package.
> As for fixing your problem; you might need to uninstall the perl RPM(s),
> wipe the directory contents, and reinstall.  Be sure to download the
> necessary RPMs first.  If you MUST have that module, at least try to
> find an RPM for it instead of using the cpan updater.  That's a nice
> tool, but it's not suitable for every user's situation, and I'm not
> talking "I'm a power user and you're not, nyah nyah" stuff here; I'm
> really talking "package manager or not".