[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 311
  • Last Modified:

Package used to work, no change to code but new environment, fails w/ "Can't locate object method" error

I have a Perl package created more than a year ago, which ran just fine on Solaris 9 under Perl v5.8.5 as the Perl Backend to an OpenLDAP server, v2.3.18.

Now trying to move the code to a Solaris 10 server in a zone.   Have made NO changes to the package code.  Have installed Perl, v5.8.8 this time, and the same OpenLDAP.    When I try to run the slapd server, its debugging output reports the following;  what am I missing?

# cat /pmdf/log/slapd-0JPC003011L89U
@(#) $OpenLDAP: slapd 2.3.18 (Sep 21 2007 14:47:52) $
        jlw@drpmdf:/opt/pmdf/local/openldap-2.3.18/servers/slapd
daemon_init: listen on ldap://pmdf.dlt.psu.edu:7634
daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldap://pmdf.dlt.psu.edu:7634)
daemon: listener initialized ldap://pmdf.dlt.psu.edu:7634
daemon_init: 1 listeners opened
pmdf-slapd init: initiated server.
slap_sasl_init: initialized!
perl backend open
perl backend db init
>>> dnPrettyNormal: <dc=psu,dc=edu>
<<< dnPrettyNormal: <dc=psu,dc=edu>, <dc=psu,dc=edu>
>>> dnPrettyNormal: <uid=jlw12,dc=psu,dc=edu>
<<< dnPrettyNormal: <uid=jlw12,dc=psu,dc=edu>, <uid=jlw12,dc=psu,dc=edu>
Can't locate object method "new" via package "MSGStore".
0
jlw011597
Asked:
jlw011597
  • 9
  • 4
  • 2
1 Solution
 
mjcoyneCommented:
Did you load the MSGStore module first with "use MSGStore;" or "require MSGStore"?

Has the path to this package changed?

Are the permissions on this package set correctly?
0
 
jlw011597Author Commented:
"You" don't provide a "use" or "require" statement.    Presumably the perl backend implements/emulates that action.    You simply supply a configuration file which specifies the package name and file path to it to slapd:

slapd.conf :

#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include     /usr/local/etc/openldap/schema/core.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral   ldap://root.openldap.org

pidfile     /tmp/slapd.pid
argsfile    /tmp/slapd.args

#######################################################################
# perl database definitions
#######################################################################

database        perl
suffix      "dc=xxx,dc=yyy"
rootdn      "uid=jlw12,dc=xxx,dc=yyy"
rootpw      ZZZ$www

perlModulePath /work/local/scripts/MSGStore.pm
perlModule MSGStore


/work/local/scripts/MSGStore.pm:

package MSGStore;

require v5.8.5;

use Tie::File::AsHash;
    $debug = 3;

sub bind
{
      ...
}
sub modify
{
    return 0;
}

sub add
{
    return 0;
}

sub delete
{
    return 0;
}

sub init
{
    return 0;
}

sub modrdn
{
    return 0;
}

sub search
{
    ...
}

sub compare
{
     return 0;
}

sub new
{
    my $class = shift;
    my $this = {};
    bless $this, $class;
   return $this;
}

sub config
{
    my $this = shift;
    my ( @args ) = @_;
        local $, = " - ";
        print STDERR @args;
        print STDERR "\n";
        return 0;
}

1;

0
 
jlw011597Author Commented:
As for path and permissions, there's been no change to these, no.  
0
Industry Leaders: 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!

 
Adam314Commented:
I'm not sure, but I would guess the perlModulePath should only contain the path for perl modules, not the actual name.  Give a try like so:
    perlModulePath /work/local/scripts
    perlModule MSGStore
or with a trailing slash on the path:
    perlModulePath /work/local/scripts/
    perlModule MSGStore
0
 
jlw011597Author Commented:
In the working version specifies the full path to the file containing the package.   But I'll try it anyway.  Maybe some difference between the Perl's in use (v5.8.5 [working] vs v5.8.8 [failing])

Nope.   No change, same results.    
0
 
Adam314Commented:
Looking through some documentation... It does look like the perlModulePath should contain the path for all of the included perl modules - which means I think you need to include all @INC paths in the perlModulePath.  You can get those with:
    perl -e 'print join(" ", @INC);'
Include the output from the above on the perlModulePath line in addition to the /work/local/scripts directory.
0
 
jlw011597Author Commented:
Aha.    Environmental issue; there's a "use" statement in my Package source file that is causing the Perl compliation to fail.   Apparently there is some issue when the line reading "use Tie::File::AsHash;" is encountered; comment it out (and the code which subsequently uses it) and the failure to find the object method "new" (defined later in the Package source file, of course) ceases.

Unfortunately, I REALLY NEED the code supplied by that Tie::File::AsHash package.   Gotta figure out what's going wrong with that, now.
0
 
jlw011597Author Commented:
What's the proper procedure now?   The problem has the same lead-in components, but it's a different problem now.   Should I delete this question and start a new one?  Or leave this one going with a new focus?
0
 
Adam314Commented:
I think my previous post addresses that... all perl module paths need to be in the perlModulePath line.  
0
 
jlw011597Author Commented:
RE: Adam314:   perl -e 'print join(" ", @INC);'
                          Include the output from the above on the perlModulePath line in addition to the
                          /work/local/scripts directory.

Changed my perlModulePath to include this, no change.

Maybe I'm not getting the correct Perl even though the default is considerably lower than the REQUIRED version, so it isn't seeing the library where Tie::File::AsHash has been installed from CPAN?
0
 
jlw011597Author Commented:
OK, took the SampleLDAP.pm that comes with the OpenLDAP code, changed its internal package name so it's the one my configuration is expecting, and replaced my Package source file with that changed version.
Then added to its init code the line "print STDERR join(':',@INC);" and tried running my LDAP server again.

Sure enough, the path printed back bears little resemblence to the one that I get when I run things outside of the OpenLDAP server -- looks like the included path for the Perl v5.8.4 that is the default version on the Zone, not the one I installed to get it up to at least v5.8.5.   Amazing that the "require v5.8.5" statement isn't triggering.    Anyway, time to look at something w/ the paths so we get the right perl interpreter, I guess.
0
 
Adam314Commented:
The @INC is not the path to the perl binary used to interpret your perl code.  To view that, use $^X.  
What is the output from this, when run both on the command line, and from within your LDAP server:

#!/usr/bin/perl
print "Binary=$^X\n";
$"=" ";
print "\@INC=@INC\n";
0
 
jlw011597Author Commented:
I know that @INC wasn't the path to the Perl executable, but the results that were there were clearly those for the wrong version of Perl, the default version before my installation from Blastwave.   There were several references to directories tied to v5.8.4.

Anyway, and I don't know how this affects things, but I created a symbol PERL=<path to my perl> and
exported this symbol; then REBUILT from the ./configure command the OpenLDAP server.   NOW the
resultant string looks to be right.   So somehow, even though the Blastwave one wasn't there when the
slapd server was built, and the PATH pointed to it for Perl, it took this force feeding to push things thru.
Still some issues, not quite right, but a modicum of progress.
0
 
jlw011597Author Commented:
While the "accepted solution" wasn't what was really the problem, it was the hint that identified the problem sufficiently to resolve it.  

For some reason, the build of OpenLDAP was not using the perl intended, resulting in not finding the intended associated CPAN libraries, resulting in a compilation error on the Package and the absence of
a required method when OpenLDAP tried to use the Perl backend code.
0
 
mjcoyneCommented:
In other words, the  path had changed...
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

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