Re: (ITS#4814) Tree Archiving
by wells_robert_frank＠yahoo.com
--0-2146048140-1169674999=:43135
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Apologies -
This did in fact work. I had not been aware of the backend DB functionality.
Regards,
RFW
Quanah Gibson-Mount <quanah(a)stanford.edu> wrote:
--On Wednesday, January 24, 2007 6:55 PM +0000 wells_robert_frank(a)yahoo.com
wrote:
> Full_Name: Bob Wells
> Version: 2.3.33
> OS: Linux RH 4
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (63.81.96.200)
Isn't this just the modrdn operation? It is supported when using the
back-hdb database.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
--0-2146048140-1169674999=:43135
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Apologies -<br><br>This did in fact work. I had not been aware of the backend DB functionality.<br><br>Regards,<br><br>RFW<br><br><b><i>Quanah Gibson-Mount <quanah(a)stanford.edu></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> <br><br>--On Wednesday, January 24, 2007 6:55 PM +0000 wells_robert_frank(a)yahoo.com <br>wrote:<br><br>> Full_Name: Bob Wells<br>> Version: 2.3.33<br>> OS: Linux RH 4<br>> URL: ftp://ftp.openldap.org/incoming/<br>> Submission from: (NULL) (63.81.96.200)<br><br>Isn't this just the modrdn operation? It is supported when using the <br>back-hdb database.<br><br>--Quanah<br><br><br>--<br>Quanah Gibson-Mount<br>Principal Software Developer<br>ITS/Shared Application Services<br>Stanford University<br>GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html<br></blockquote><br>
--0-2146048140-1169674999=:43135--
15 years, 4 months
Re: (ITS#4813) glue/syncrepl
by hyc＠symas.com
aej(a)wpi.edu wrote:
> Full_Name: Allan E. Johannesen
> Version: 2.3.33
> OS: Linux EL 4
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (130.215.24.208)
>
>
> I have two synrepl slaves and entries in both of them seem to degrade, over
> time, into "objectClass: glue" entities.
>
> These entries are not updated, so this degradation appears to be autonomous in
> the slaves. The slaves have identical problems, the master retains the
> structure of the entries.
>
> I see IS#4626 which has this same sort of problem, and perhaps I should have
> followed on to that, but I can say that this problem must be much worse in
> 2.3.33 than previously, since this has only happened to me since upgrading to
> this release.
>
> My ou people is reduced to glue as is the ou access. The simplesecurity object
> is gone entirely from the slaves' database. This is only the beginning of the
> display of differences in the data.
>
> These entries were not modified since the database creation, and the
> disintegration only occurs in the slaves.
>
> Let me know if more info is needed.
Since you mention that this occurs more often in 2.3.33 than in "previous
releases" - what previous version are you comparing to?
Please provide the relevant section of your slave slapd.conf - the database
clause and its syncrepl statement at least. Are there any ACLs on the
provider that would prevent the slave from seeing parts of the affected entries?
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
15 years, 4 months
Re: (ITS#4814) Tree Archiving
by quanah＠stanford.edu
--On Wednesday, January 24, 2007 6:55 PM +0000 wells_robert_frank(a)yahoo.com
wrote:
> Full_Name: Bob Wells
> Version: 2.3.33
> OS: Linux RH 4
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (63.81.96.200)
Isn't this just the modrdn operation? It is supported when using the
back-hdb database.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
15 years, 4 months
(ITS#4814) Tree Archiving
by wells_robert_frank＠yahoo.com
Full_Name: Bob Wells
Version: 2.3.33
OS: Linux RH 4
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (63.81.96.200)
REQUEST FEATURE:
Need capability to move an entire entry beneath another branch in the tree.
Example:
uid=jdoe,ou=customers,dc=acme,dc=com (Customer exists)
uid=jdoe,ou=archive,ou=customers,dc=acme,dc=com (Customer account deleted from
within application and moved to archive tree branch)
Currently, we do not believe openLDAP supports this capability. We have used
rebind and rename. We are unable to find a way to do what we need it to do.
Therefore, we request this type of feature in the product.
Thanks in advance,
Bob Wells-070124
15 years, 4 months
Crypt invalide credential
by Arrouan
Hi,
I'm using OpenLDAP under Linux/Gentoo (with crypt enabled).
I can bind user with SSHA password, but i can't bind user with CRYPT
password.
OpenLDAP is link with Postfix/Courier and need CRYPT password. I check the
ACL and it seem the issue isn't there.
Anyone know how to fix this issue ?
I have other postfix+openldap server and they all work without any problem.
Thanks
15 years, 4 months
Re:(ITS#4810) syncprov follows referrals
by dieter＠dkluenter.de
Hi,
this is my test setup
##provider###
slapd.conf
pidfile /tmp/run/slapd1.pid
argsfile /tmp/run/slapd1.args
loglevel sync
modulepath /usr/local/libexec/openldap
moduleload syncprov.la
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
suffix "dc=my-domain,dc=com"
rootdn "cn=Manager,dc=my-domain,dc=com"
rootpw secret
directory /tmp/slapd1/
index objectClass eq
overlay syncprov
--------------------
initial.ldif
dn: dc=my-domain,dc=com
objectclass: domain
dc: my-domain
dn: ou=organisation 1,dc=my-domain,dc=com
objectclass: organizationalUnit
ou: organisation 1
dn: ou=organisation 2,dc=my-domain,dc=com
objectclass: organizationalUnit
ou: organisation 2
dn: cn=Foo Bar,ou=organisation 1,dc=my-domain,dc=com
objectclass: inetorgperson
cn: Foo Bar
sn: Bar
mail: foobar(a)my-domain.com
telephoneNumber: +49.40.2997714
dn: cn=Bar Foo,ou=organisation 2,dc=my-domain,dc=com
objectclass: alias
objectclass: extensibleObject
aliasedObjectName: cn=Foo Bar,ou=organisation 1,dc=my-domain,dc=com
cn: Bar Foo
sn: Foo
---------------
## Consumer ####
slapd.conf
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
pidfile /tmp/run/slapd2.pid
argsfile /tmp/run/slapd2.args
loglevel sync
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
database bdb
suffix "dc=my-domain,dc=com"
rootdn "cn=Manager,dc=my-domain,dc=com"
rootpw secret
directory /tmp/slapd2/
index objectClass eq
syncrepl rid=02
provider=ldap://localhost:9001
binddn=cn=Manager,dc=my-domain,dc=com
bindmethod=simple
credentials=secret
searchbase="dc=my-domain,dc=com"
scope=sub
type=refreshAndPersist
retry="5 5 300 5"
--------------------
After starting the comsumer, the initial dataset gets replicated.
If adding the following entries (using web2ldap) to the provider
dn: cn=Mike Miller,ou=organisation 1,dc=my-domain,dc=com
sn: Miller
cn: Mike Miller
mail: mmiller(a)my-domain.com
telephoneNumber: +49.40.4450003
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
dn: cn=Miller Mike,ou=organisation 2,dc=my-domain,dc=com
aliasedObjectName: cn=Mike Miller,ou=organisation 1,dc=my-domain,dc=com
cn: Miller Mike
objectClass: alias
objectClass: extensibleObject
dn: cn=Joe Smith,ou=organisation 1,dc=my-domain,dc=com
sn: Smith
cn: Joe Smith
mail: jsmith(a)my-domain.com
telephoneNumber: +49.40.4450004
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
dn: cn=Smith Joe,ou=organisation 2,dc=my-domain,dc=com
aliasedObjectName: cn=Joe Smith,ou=organisation 1,dc=my-domain,dc=com
cn: Smith Joe
objectClass: alias
objectClass: extensibleObject
the alias objects are not replicated, only after a consumer restart.
-Dieter
--
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6
15 years, 4 months
Re: (ITS#4810) syncprov follows referrals
by dieter＠dkluenter.de
Am Montag, 22. Januar 2007 22:28 schrieb Pierangelo Masarati:
> dieter(a)dkluenter.de wrote:
> > Full_Name: Dieter Kluenter
> > Version: 2.4.2alpha
> > OS: linux
> > URL: ftp://ftp.openldap.org/incoming/
> > Submission from: (NULL) (84.142.177.66)
> >
> >
> > When adding a alias abject to the provider, syncprov fowllows the
> > referral and is not updating the alias object to the consumer,
>
> Dieter,
>
> are you talking about aliases or referrals?
Hi Ando,
In this particular case I am talking about aliases.
-Dieter
--
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6
15 years, 4 months
(ITS#4813) glue/syncrepl
by aej＠wpi.edu
Full_Name: Allan E. Johannesen
Version: 2.3.33
OS: Linux EL 4
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (130.215.24.208)
I have two synrepl slaves and entries in both of them seem to degrade, over
time, into "objectClass: glue" entities.
These entries are not updated, so this degradation appears to be autonomous in
the slaves. The slaves have identical problems, the master retains the
structure of the entries.
I see IS#4626 which has this same sort of problem, and perhaps I should have
followed on to that, but I can say that this problem must be much worse in
2.3.33 than previously, since this has only happened to me since upgrading to
this release.
My ou people is reduced to glue as is the ou access. The simplesecurity object
is gone entirely from the slaves' database. This is only the beginning of the
display of differences in the data.
These entries were not modified since the database creation, and the
disintegration only occurs in the slaves.
Let me know if more info is needed.
Thanks.
*** users.ldapv2.2007.01.23.ldif.pure Tue Jan 23 09:10:50 2007
--- users.ldapv2back.2007.01.23.ldif.pure Tue Jan 23 09:10:53 2007
***************
*** 10,18 ****
dn: ou=People,dc=WPI,dc=EDU
objectClass: top
! objectClass: organizationalUnit
! ou: People
! structuralObjectClass: organizationalUnit
dn: wpieduPersonUUID=62081c7c52ec30c556d6c558896983ee,ou=People,dc=WPI,dc=EDU
objectClass: top
--- 10,17 ----
dn: ou=People,dc=WPI,dc=EDU
objectClass: top
! objectClass: glue
! structuralObjectClass: glue
dn: wpieduPersonUUID=62081c7c52ec30c556d6c558896983ee,ou=People,dc=WPI,dc=EDU
objectClass: top
***************
*** 1498,1514 ****
dn: ou=Access,dc=WPI,dc=EDU
objectClass: top
! objectClass: organizationalUnit
! ou: Access
! structuralObjectClass: organizationalUnit
!
! dn: cn=retiresql,ou=Access,dc=WPI,dc=EDU
! objectClass: top
! objectClass: simpleSecurityObject
! objectClass: applicationProcess
! cn: retiresql
! userPassword:: e1NTSEF9Qno0NllDM2pwRWZSZGh6OFdRY2RWNWpjdklaWHM0ekU=
! structuralObjectClass: applicationProcess
dn: wpieduPersonUUID=d9e775ae9449c616c6952d860e634ad6,ou=People,dc=WPI,dc=EDU
objectClass: top
--- 1497,1504 ----
dn: ou=Access,dc=WPI,dc=EDU
objectClass: top
! objectClass: glue
! structuralObjectClass: glue
dn: wpieduPersonUUID=d9e775ae9449c616c6952d860e634ad6,ou=People,dc=WPI,dc=EDU
objectClass: top
15 years, 4 months
(ITS#4812) ldapmodify doesn't report error when the server closed the connection
by rhafer＠suse.de
Full_Name: Ralf Haferkamp
Version: 2.3, HEAD
OS: Any
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (89.166.166.107)
ldapmodify doesn't report errors from a failed ldap_result() call. This can be
reproduce by using ldapmodify via stdin and connecting to a server with a very
short idletimeout. If the MODIFY operation is sent after the connection is
closed no error message is shown to the user. The only indication of a failure
is the EXIT code of ldapmodify.
This is fixed in HEAD now.
15 years, 4 months
Re: (ITS#4809) Replication of operational attributes when performing modrdn operation
by hyc＠symas.com
Thomas.Fritz(a)bam.de wrote:
> Full_Name: Thomas Fritz
> Version: 2.3.33
> OS: Debian Gnu/Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (141.63.61.111)
>
>
> We are using OpenLDAP 2.3.33 in a master/slave setup with slurpd and hdb
> backend.
>
> When performing the modrdn operation against the master, no update directives
> for the attributes 'modifiersName', 'modifyTimestamp', and 'entryCSN' are
> written to the replog file. Hence, the databases of master and slave differ by
> the values of these attributes after replication.
>
> This bug can be reproduced using e.g. the ldapmodrdn tool. OpenLDAP versions
> back to (at least) 2.3.24 are affected.
This is not a bug, it is a consequence of the design of slurpd. slurpd uses
LDIF (RFC2849) for its replog format, and simply propagates LDAP operations
as recorded there. In LDIF a modrdn record can only specify newrdn,
deleteoldrdn, and newsuperior parameters. Likewise, these are the only
parameters that can be specified in an LDAP modrdn operation. This design
limitation is one of many reasons why slurpd has been deprecated.
If you want to perform replication and preserve these attributes, you can use
syncrepl instead.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
15 years, 4 months
