On 22/4/07 10:51, "Alan Madill" <[EMAIL PROTECTED]> wrote:
> smbldap-tools in a working environment suddenly unable to add or modify
> users.
>
> smbldap-useradd kenh
> Use of uninitialized value in die at
> /usr/lib/perl5/vendor_perl/5.8.6/Convert/ASN1/_decode.pm line 111.
>
> Perl debug trace
> [EMAIL PROTECTED] ~]# perl -d /usr/sbin/smbldap-useradd jimh
>
> Loading DB routines from perl5db.pl version 1.28
> Editor support available.
>
> Enter h or `h h' for help, or `man perldebug' for more help.
>
> main::(/usr/sbin/smbldap-useradd:38):
> 38: my %Options;
> DB<1> r
> Use of uninitialized value in die at
> /usr/lib/perl5/vendor_perl/5.8.6/Convert/ASN1/_decode.pm line 111.
> at /usr/lib/perl5/vendor_perl/5.8.6/Convert/ASN1/_decode.pm line 111
> Convert::ASN1::_decode('HASH(0x94305e0)', 'ARRAY(0x9432170)',
> 'SCALAR(0x931c228)', 0, 5, 'undef', 'ARRAY(0x9911cbc)',
> '\x{16}\x{3}\x{1}\x{0}\x{c4}') called at
If that's a bit of BER, it is describing an IA5String (UNIVERSAL 22) with
illegal characters. If you can do a bit of protocol sniffing, see what's
actually in the BindResponse packet.
> /usr/lib/perl5/vendor_perl/5.8.6/Convert/ASN1.pm line 252
> eval {...} called at
> /usr/lib/perl5/vendor_perl/5.8.6/Convert/ASN1.pm line 247
> Convert::ASN1::decode('Convert::ASN1=HASH(0x9422a44)',
> '\x{16}\x{3}\x{1}\x{0}\x{c4}') called at
> /usr/lib/perl5/vendor_perl/5.8.6/Net/LDAP.pm line 774
> Net::LDAP::_recvresp('Net::LDAP=HASH(0x94caaf4)', 2) called at
> /usr/lib/perl5/vendor_perl/5.8.6/Net/LDAP.pm line 696
> Net::LDAP::sync('Net::LDAP=HASH(0x94caaf4)', 2) called at
> /usr/lib/perl5/vendor_perl/5.8.6/Net/LDAP.pm line 740
> Net::LDAP::_sendmesg('Net::LDAP=HASH(0x94caaf4)',
> 'Net::LDAP::Bind=HASH(0x98d43d8)') called at
> /usr/lib/perl5/vendor_perl/5.8.6/Net/LDAP.pm line 363
> Net::LDAP::bind('dn',
> 'cn=smbldap-tools,ou=DSA,dc=BIDCONST,dc=COM', 'password', 'secret')
> called at /usr/lib/perl5/vendor_perl/5.8.6/smbldap_tools.pm line 298
> smbldap_tools::connect_ldap_master() called at
> /usr/sbin/smbldap-useradd line 76
>
> This is on a stable system where it has been working. Any ideas as to what is
> going on?
The LDAP server's been reconfigured to send something broken back?
Cheers,
Chris
