manu(a)netbsd.org wrote:
> I committed the overlay in the contrib folder
>
As I mentioned before, you should be using a config OID from the Contrib
branch, and noting this in contrib/ConfigOIDs.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Full_Name: Maurice Smulders
Version: novell-jldap-devel-2008.03.01
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (208.230.118.253)
using
I created a LDAPBindHandler, and then called the read api as follows:
ldapEntry = ldapConnection.read(userCtx.toString(),searchConstraints);
No default constraints are set on the connection.
The referral handler never calls into my bindhandler. The workaround currently
is to set a default bind handler. Fix looks to be:
com/novell/ldap/LDAPConnection.java:3770:
private ReferralInfo getReferralConnection( String[] referrals)
throws LDAPReferralException
Change to:
private ReferralInfo getReferralConnection( String[] referrals,
LDAPConstraints cons)
throws LDAPReferralException
And down below:
change
LDAPReferralHandler rh = defSearchCons.getReferralHandler();
to:
if (cons == null)
{
cons = defSearchCons;
}
LDAPReferralHandler rh = cons.getReferralHandler();
This should then support passed in LDAPConstraints()
On Monday 05 January 2009 12:31:23 sandeep.kumbhar(a)silverarc.biz wrote:
> Full_Name: Sandeep Kumbhar
> Version: openldap-2.3.27-8.el5_1.3
> OS: CentOS 5.2
> URL:
> Submission from: (NULL) (59.181.122.24)
>
>
> 1. I am using below schema for my LDAP server
>
> include /etc/openldap/schema/core.schema
> include /etc/openldap/schema/cosine.schema
> include /etc/openldap/schema/inetorgperson.schema
> include /etc/openldap/schema/nis.schema
>
> 2. I created local user on the same server and did the following to
> generate the
>
> data for step 3.
>
> # grep 'username' /etc/passwd > /etc/openldap/passwd.username
>
> Ref:
> <http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLD
>AP_server_for_your_network#Bonus:_Exporting_LDAP_users_home_folders_with_NFS
>>
In general, I note that this documentation leaves a lot to be desired.
>
> 3. Then I used the migration perl script for converting the local users to
> LDAP users.
>
> # /usr/share/openldap/migration/migrate_passwd.pl
> /etc/openldap/passwd.username \
> /etc/openldap/username.ldif
>
> 4. Now after creation of the *.ldif I used the below command to add this
> database
> file into the LDAP server.
>
You should run migrate_base.pl before you add any other data generated by
migrationtools.
> # ldapadd -x -D "cn=Manager,dc=intra,dc=exlinuz,dc=com" -W -f
> /etc/openldap/ \
> username.ldif
>
> 5. After typing the ldapadd command I gave the LDAP password I got the
> error below
>
> adding new entry "uid=sandeepk,ou=People1,dc=intra,dc=exlinuz,dc=com"
> ldap_add: No such object (32)
> matched DN: dc=intra,dc=exlinuz,dc=com
According to the error, the deepest part of this DN that exists is
dc=intra,dc=exlinuz,dc=com, so you haven't created
ou=People1,dc=intra,dc=exlinuz,dc=com, which migrate_base.pl would have done
for you.
> 6. I have created the domain.ldif and root.ldif and added them successfully
> into the
> LDAP Server using the official Openldap documentation.
> However I could not find anything adding Unix users and therefore I used
> the
>
> above referenced link to generate Unix users database file for LDAP.
>
> Please see the ldif file output by the migration script
There is no bug here. Please consult the documentation of the tools you are
using (migrationtools) when your spoonfeeding doesn't work perfectly. The only
problem you encountered was the 'HOWTO' you used, file bugs on it instead. It
is quite evident that the author of the HOWTO has not bothered to consult the
documentation for migrationtools ... see the migration-tools.txt file shipped
with the software.
Honestly, http://www.zarb.org/~bgmilne/make_master.sh could replace about half
the HOWTO, and cover something the HOWTO doesn't (migrating groups ....).
Regards,
Buchan
On Monday 05 January 2009 12:31:23 sandeep.kumbhar(a)silverarc.biz wrote:
> Full_Name: Sandeep Kumbhar
> Version: openldap-2.3.27-8.el5_1.3
> OS: CentOS 5.2
> URL:
> Submission from: (NULL) (59.181.122.24)
>
>
> 1. I am using below schema for my LDAP server
>
> include /etc/openldap/schema/core.schema
> include /etc/openldap/schema/cosine.schema
> include /etc/openldap/schema/inetorgperson.schema
> include /etc/openldap/schema/nis.schema
>
> 2. I created local user on the same server and did the following to
> generate the
>
> data for step 3.
>
> # grep 'username' /etc/passwd > /etc/openldap/passwd.username
>
> Ref:
> <http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLD
>AP_server_for_your_network#Bonus:_Exporting_LDAP_users_home_folders_with_NFS
>>
In general, I note that this documentation leaves a lot to be desired.
>
> 3. Then I used the migration perl script for converting the local users to
> LDAP users.
>
> # /usr/share/openldap/migration/migrate_passwd.pl
> /etc/openldap/passwd.username \
> /etc/openldap/username.ldif
>
> 4. Now after creation of the *.ldif I used the below command to add this
> database
> file into the LDAP server.
>
You should run migrate_base.pl before you add any other data generated by
migrationtools.
> # ldapadd -x -D "cn=Manager,dc=intra,dc=exlinuz,dc=com" -W -f
> /etc/openldap/ \
> username.ldif
>
> 5. After typing the ldapadd command I gave the LDAP password I got the
> error below
>
> adding new entry "uid=sandeepk,ou=People1,dc=intra,dc=exlinuz,dc=com"
> ldap_add: No such object (32)
> matched DN: dc=intra,dc=exlinuz,dc=com
According to the error, the deepest part of this DN that exists is
dc=intra,dc=exlinuz,dc=com, so you haven't created
ou=People1,dc=intra,dc=exlinuz,dc=com, which migrate_base.pl would have done
for you.
> 6. I have created the domain.ldif and root.ldif and added them successfully
> into the
> LDAP Server using the official Openldap documentation.
> However I could not find anything adding Unix users and therefore I used
> the
>
> above referenced link to generate Unix users database file for LDAP.
>
> Please see the ldif file output by the migration script
There is no bug here. Please consult the documentation of the tools you are
using (migrationtools) when your spoonfeeding doesn't work perfectly. The only
problem you encountered was the 'HOWTO' you used, file bugs on it instead. It
is quite evident that the author of the HOWTO has not bothered to consult the
documentation for migrationtools ... see the migration-tools.txt file shipped
with the software.
Honestly, http://www.zarb.org/~bgmilne/make_master.sh could replace about half
the HOWTO, and cover something the HOWTO doesn't (migrating groups ....).
Regards,
Buchan
--=-SUZpECi7CptfRynVUs4v
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Fri, 2008-12-12 at 14:23 +1100, Andrew Bartlett wrote:
> On Thu, 2008-12-11 at 23:22 +0100, Pierangelo Masarati wrote:
> > Andrew Bartlett wrote:
> > > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote:
> > >> A tentative implementation is in HEAD, please test. You need to:
> > >=20
> > > Thankyou very much. I downloaded CVS HEAD and tested it out (finally=
-
> > > the Samba4 side of the implementation took far longer than I expected=
).
> > >=20
> > >> - configure as --enable-deref
> > >>
> > >> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't
> > >> work as global overlay yet, sorry).
> > >=20
> > > This is something Samba4 will need, as many of our links are
> > > cross-database. But fixing this for a single DB is a big help in any
> > > case.
> >=20
> > Apparently this was fixed during the overlay's shakedown, as it seems t=
o=20
> > work as expected when only instantiated as global. In fact, nothing wa=
s=20
> > preventing it from working this way by design, it only didn't work at=20
> > some point of its evolution. Please test.
>=20
> Indeed, it works well as a global. Thanks!
>=20
> My only issue remaining is the clarification over the ASN.1 encoding of
> the control.
While I'm still confused about the ASN.1, I've coded to match OpenLDAP's
current behaviour.
The deref overlay seems to be working well. Many thanks!
Andrew Bartlett
--=20
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
--=-SUZpECi7CptfRynVUs4v
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQBJYuLrz4A8Wyi0NrsRAgALAJ0b1YEcsKRo86mc2LCZbowtSyTo1gCeM3ws
slxgoMVr/MkEZcEk881oaLE=
=6rsz
-----END PGP SIGNATURE-----
--=-SUZpECi7CptfRynVUs4v--
ando(a)sys-net.it wrote:
> Full_Name: Pierangelo Masarati
> Version: HEAD
> OS: irrelevant
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (82.63.140.131)
> Submitted by: ando
>
>
> After updating tests/run.in from CVS (rev 1.59) and reconfiguring, executing
> test050 with SYNCMODE=ro results in a failure. The failure is not strictly
> reproducible, but it always occurred to me, either affecting one or another
> delete that is not propagated to all participants to the MMR pool. I've raised
> the sleep time, to make sure there's no chance replication did not occur yet.
>
> I wonder if refreshOnly makes any sense for a MMR pool. If it doesn't, it
> should not be allowed. If it does, deletes should be replicated correctly.
This sounds like a dup of #5843. Note that you cannot disallow MMR for
refreshOnly, since servers must be able to refresh when starting up.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/