Bug 431537 - smbldap-tools not compatible with Fedora 8 Perl packages/modules
Summary: smbldap-tools not compatible with Fedora 8 Perl packages/modules
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: smbldap-tools
Version: 10
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Paul Howarth
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-02-05 11:41 UTC by Matt Darcy
Modified: 2009-12-18 06:03 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-12-18 06:03:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Matt Darcy 2008-02-05 11:41:53 UTC
Description of problem:
using the redhat packaged version of smbldap-tools with a fully up to date 
Fedora 8 server, none of the smbldap-commands (smbldap-useradd, smbldap-
groupadd etc etc) work. They present a complaint agains the perl modules user 
by fedora 8's perl 5.8.8 install.

[quote]
[root@alesi ~]# smbldap-groupadd test
Error looking for next uid in cn=NextFreeUnixId,dc=no-dns,dc=co,dc=uk:No such 
object at /usr/lib/perl5/vendor_perl/5.8.8/smbldap_tools.pm line 1071
[/quote]




Version-Release number of selected component (if applicable):
Fedora 8
Linux Kernel 2.6.23.14-107.fc8
smbldap-tools-0.9.4-1.fc8
perl-LDAP-0.34-3.fc7
perl-5.8.8-32.fc8

How reproducible:
Everytime


Steps to Reproduce:
1. Install Fedora 8 - updated Fedora 8 to lastest including Perl and smbldap-
tools
2. configure samba/ldap so there is an ldap directory running
3. attempt to add a user using the smbldap-useradd command
  
Actual results:
Error looking for next uid in cn=NextFreeUnixId,dc=no-dns,dc=co,dc=uk:No such 
object at /usr/lib/perl5/vendor_perl/5.8.8/smbldap_tools.pm line 1071.

Expected results:
user to be added to the ldap directory


Additional info:

Comment 1 Paul Howarth 2008-02-06 14:48:55 UTC
Did you forget to do the steps:

# smbldap-populate
(set up smbldap directory in LDAP)

# smbpasswd -w secret
(set up the ldap admin password in secrets.tdb)


Comment 2 Matt Darcy 2008-02-06 18:26:37 UTC
I didn't think I did - I've just re-run them to make sure and they ran fan, I 
ran a smbldap-useradd after I've re-commited those steps and still get the same 
error.


Comment 3 Matt Darcy 2008-02-07 13:10:07 UTC
sorry, I should have been clear "I don't think I did miss out that step" 
however as indicated above I have re-run it with the same failure

Comment 4 Paul Howarth 2008-02-07 13:55:53 UTC
Can you browse your LDAP directory and see if the
cn=NextFreeUnixId,dc=no-dns,dc=co,dc=uk node exists?

Are you sure that /etc/smbldap-tools/smbldap_bind.conf includes appropriate
credentials for write access to your LDAP directory?

Comment 5 Matt Darcy 2008-02-07 20:47:13 UTC
looks good to me 

ldapsearch -x -b "dc=no-dns,dc=co,dc=uk" "cn=NextFreeUnixId"
# extended LDIF
#
# LDAPv3
# base <dc=no-dns,dc=co,dc=uk> with scope subtree
# filter: cn=NextFreeUnixId
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1


Comment 6 Paul Howarth 2008-02-08 00:20:35 UTC
That's not returned any matches. We don't use the cn=NextFreeUnixId format here
but it should work the same, and the equivalent lookup is:

$ ldapsearch -x -b "dc=virtensys,dc=com" "sambaDomainName=VIRTENSYS"
# extended LDIF
#
# LDAPv3
# base <dc=virtensys,dc=com> with scope sub
# filter: sambaDomainName=VIRTENSYS
# requesting: ALL
#

# VIRTENSYS, virtensys.com
dn: sambaDomainName=VIRTENSYS,dc=virtensys,dc=com
objectClass: top
objectClass: sambaDomain
objectClass: sambaUnixIdPool
sambaDomainName: VIRTENSYS
sambaSID: S-1-5-21-...blah...
gidNumber: 5001
uidNumber: 5100
sambaNextRid: 1027

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


Check that /etc/smbldap-tools/smbldap_bind.conf includes the appropriate
credentials for writing to your LDAP directory, and also that the samba.schema
from the samba package is included in your LDAP configuration.


Comment 7 Matt Darcy 2008-02-08 08:34:12 UTC
ahhh I see, 

I thought that response that it was returning zero results, as in the entry was 
there but unpopulated, like an SQL select statment returning no results, the 
field is there but its empty. 


My output to match yours.


[root@alesi ~]# ldapsearch -x -b "dc=no-
dns,dc=co,dc=uk" "sambaDomainName=EQUINOX"
# extended LDIF
#
# LDAPv3
# base <dc=no-dns,dc=co,dc=uk> with scope subtree
# filter: sambaDomainName=EQUINOX
# requesting: ALL
#

# EQUINOX, no-dns.co.uk
dn: sambaDomainName=EQUINOX,dc=no-dns,dc=co,dc=uk
sambaDomainName: EQUINOX
sambaSID: S-1-5-21-blah....blah
sambaAlgorithmicRidBase: 1000
objectClass: sambaDomain
sambaNextUserRid: 1000

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1




Looking at the smbldap_bind.conf all looks good
slaveDN="cn=Manager,dc=no-dns,dc=co,dc=uk"
slavePw="clear_text_password"
masterDN="cn=Manager,dc=no-dns,dc=co,dc=uk"
masterPw="clear_text_password"


My Ldap config includes the samba schema

include  /etc/openldap/schema/core.schema
include  /etc/openldap/schema/cosine.schema
include  /etc/openldap/schema/inetorgperson.schema
include  /etc/openldap/schema/nis.schema
include  /etc/openldap/schema/samba.schema


I've just tried using the smbldap-installer version 3.1.1 to check an automated 
process, which ran %100 fine.

I still get the same error.

Thanks for the input so far.





Comment 8 Matt Darcy 2008-02-14 08:10:40 UTC
Do you require any more / specific information with this issue ?

Comment 9 Paul Howarth 2008-02-14 16:33:54 UTC
I'm wondering why smbldap-useradd is looking for
cn=NextFreeUnixId,dc=no-dns,dc=co,dc=uk when you appear to be using
sambaDomainName=EQUINOX,dc=no-dns,dc=co,dc=uk for sambaUnixIdPooldn.

I trust you have
sambaUnixIdPooldn="ambaDomainName=EQUINOX,dc=no-dns,dc=co,dc=uk" in
/etc/smbldap-tools/smbldap.conf and that this file is world-readable?

Sorry for the slow responses but I'm snowed under at work at the moment.

Comment 10 Matt Darcy 2008-02-15 10:50:19 UTC
Hi,

no need to apologise for being slow to respond - I appriciate your time, more 
so as this could be user error, rather than a legitmate bug.


ok, your last comment makes sense. 

The line WAS

# Where to store next uidNumber and gidNumber available
sambaUnixIdPooldn="cn=NextFreeUnixId,dc=no-dns,dc=co,dc=uk"

Which I've now changed to 

sambaUnixIdPooldn="sambaDomainName=EQUINOX,dc=no-dns,dc=co,dc=uk"

as you've suggested (I see what your doing but I don't understand why the 
cn=NextFreeUnixId has been dropped, the change you've made doesn't seem to call 
out a CN in the Domainname EQUINOX to use - but thats just my lack of 
understanding.

Now when I try to add a test user with the line, I see 

Could not find base dn, to get next uidNumber 
at /usr/lib/perl5/vendor_perl/5.8.8/smbldap_tools.pm line 1073

Which suggests to me it can't find the no-dns.co.uk base, but the querys in the 
above posts made suggest that it is present and fine.




Comment 11 Matt Darcy 2008-03-12 11:49:25 UTC
Anything I can provide on this to move forward.

I'm leaning more to think this is user error / issue with the smbldap-installer 
script.

I am strugglging to find the maintainer of the smbldap-installer script / 
documentation so I can't be certain at this point.

Comment 12 Paul Howarth 2008-03-12 11:57:31 UTC
Upstream is at https://gna.org/projects/smbldap-tools/ - there's a bug tracker
there that might be worth looking at.

I'm planning to try replicating my work (RHEL4) setup on a Fedora 8 box and
documenting how I did it for a README file in the package and probably a page on
fedoraproject.org too; I just can't find any free time to do this at the moment
I'm afraid.

Comment 13 Matt Darcy 2008-03-18 16:30:22 UTC
No problem, everyone is tied up at times, I'm looking through up stream now.

Comment 14 Bug Zapper 2008-11-26 09:41:53 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 15 Paul Howarth 2008-11-27 10:17:03 UTC
Still not been able to work on a HOWTO for this; bumping to Fedora 10.

Comment 16 Bug Zapper 2009-11-18 09:33:30 UTC
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 17 Bug Zapper 2009-12-18 06:03:36 UTC
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.