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:
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)
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.
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
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?
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
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.
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.
Do you require any more / specific information with this issue ?
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.
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.
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.
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.
No problem, everyone is tied up at times, I'm looking through up stream now.
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
Still not been able to work on a HOWTO for this; bumping to Fedora 10.
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
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.