Strange wedging
by Edward Z. Yang
Hey all,
I'm too tired right now to write up a proper report, but would
the following behavior be something y'all be'd interested in
debugging?
* Outgoing incremental GSSAP-authed MMR replications wedge
indefinitely, in Kerberos code.
* It's impossible to do a full update without disabling all
incoming and outgoing replication agreements, because as
soon as another replication goes and gets stuck, everything
else fails.
Basically, dirsrv+GSSAPI can get into some sort of wedged
state persistent across restarts that means:
* You can't restart the server without kill -9'ing it
* You can't do a full update
And the only way to fix it is to reinitialize all replication
agreements.
Edward
13 years, 6 months
The case of a rather odd byte sequence (nsslapd-referral)
by Edward Z. Yang
Hello all,
I've been using OpenLDAP to talk to Fedora DS, and my bindings
weren't working! This was quite vexing, so I did some investigation.
I finally pinpointed the error to ldap_get_values_len() returning
a NULL pointer for nsslapd-referral, with no error code.
Sounds sort of like a bug in OpenLDAP, no? Yes it does, but it's a bug
that's only tickled in very strange circumstances. If you use ldapvi,
well, that links to OpenLDAP, but it ignores NULLs so that's why you
never see a nsslapd-referral in your cn=config entry.
I made a dump of the buffer that OpenLDAP was parsing values out
of (I think this was what was transmitted over the network.)
Exhibit A (byte sequence containing nsslapd-referral):
0<14><04><10>nsslapd-referral1<00>0<19><04><12>
Exhibit B (byte sequence containing nsslapd-localhost):
0,<04><11>nsslapd-localhost1<17><04><15>cats-whiskers.mit.edu0#<04><16>
As you can see, the byte sequence for nsslapd-referral appears to have
no textual data associated with it. What's up with that?
Edward
13 years, 6 months
Replication from 1.2.5 to 1.2.6 failed
by Edward Z. Yang
I've got a failure, and I'm able to gdb it. However, I don't
know what to look for. What kind of tracing would you like to
see? I was going to wireshark but decrypting the Kerberos would
be annoying.
[16/Oct/2010:14:17:16 -0400] NSMMReplicationPlugin - agmt="cn=GSSAPI Replication to busy-beaver.mit.edu" (busy-beaver:389): Unable to parse the response to the startReplication extended operation. Replication is aborting.
Edward
13 years, 6 months
replication between 1.2.2 and 1.2.6.1
by Robert Viduya
Can we expect replication between 1.2.2 and 1.2.6.1 to work? I'm trying to set up MMR between two servers running the two different versions and the 1.2.6.1 master is failing with the following message in it's errors log:
[14/Oct/2010:16:26:19 -0400] NSMMReplicationPlugin - agmt="cn=people moulin stefan" (stefan:636): Unable to parse the response to the startReplication extended operation. Replication is aborting.
[14/Oct/2010:16:26:19 -0400] NSMMReplicationPlugin - agmt="cn=people moulin stefan" (stefan:636): Incremental update failed and requires administrator action
The corresponding messages in the 1.2.2 master's access file show:
[14/Oct/2010:16:26:19 -0400] conn=139 fd=65 slot=65 SSL connection from 130.207.183.16 to 130.207.183.14
[14/Oct/2010:16:26:19 -0400] conn=139 op=0 BIND dn="cn=Replication Manager,cn=config" method=128 version=3
[14/Oct/2010:16:26:19 -0400] conn=139 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=replication manager,cn=config"
[14/Oct/2010:16:26:19 -0400] conn=139 op=1 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension"
[14/Oct/2010:16:26:19 -0400] conn=139 op=1 RESULT err=0 tag=101 nentries=1 etime=0
[14/Oct/2010:16:26:19 -0400] conn=139 op=2 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension"
[14/Oct/2010:16:26:19 -0400] conn=139 op=2 RESULT err=0 tag=101 nentries=1 etime=0
[14/Oct/2010:16:26:19 -0400] conn=139 op=3 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension"
[14/Oct/2010:16:26:19 -0400] conn=139 op=3 RESULT err=0 tag=101 nentries=1 etime=0
[14/Oct/2010:16:26:19 -0400] conn=139 op=4 EXT oid="2.16.840.1.113730.3.5.12"
[14/Oct/2010:16:26:19 -0400] conn=139 op=4 RESULT err=2 tag=120 nentries=0 etime=0
[14/Oct/2010:16:27:19 -0400] conn=139 op=5 UNBIND
[14/Oct/2010:16:27:19 -0400] conn=139 op=5 fd=65 closed - U1
I looked up oid 2.16.840.1.113730.3.5.12 and it's apparently new for hooking plugins into the replication process. I just skimmed the 1.2.6.1 source code and it appears that there's logic to detect if the remote server supports it. Is that the intent and it's bugged or is replication between the two version just not supposed to work?
13 years, 6 months
Debian packaging
by Michele Baldessari
Hi everyone,
I am the person behind the current FDS Packaging efforts for Debian.
Roberto mentioned to me some threads [1] related to Debian packaging,
so I thought I share the status of my work. Hopefully interested people
can chime in and lend a hand or report bugs.
The svn repo where I commit the debian/ dir can be found on alioth [2]
I've setup a repository which is usable for debian Sid (i386 and amd64).
Just add the following line to your sources.list:
deb http://acksyn.org/debian sid main
To install the 389 DS:
apt-get install dirsrv
The Directory Server 1.2.6.1 package is in a fairly decent shape (modulo ipv6:
you have to disable the bindv6only proc entry)
The rest of the stack is mostly packaged but needs a lot more fixing and
polishing than the server.
Right now I am working on the Admin Server and the Console. My goal is
provide a foundation for FreeIPA in Debian. [3]
The Wiki page for this packagin effort can be found here [4]
If you have any questions, bug reports or suggestions feel free to drop
me a line per mail.
hth,
Michele
[1] http://lists.fedoraproject.org/pipermail/389-users/2010-October/012253.html
[2] http://svn.debian.org/viewsvn/pkg-fedora-ds/
[3] http://www.freeipa.org
[4] http://wiki.debian.org/Teams/DebianFDSPackaging
--
Michele Baldessari <michele(a)acksyn.org>
C2A5 9DA3 9961 4FFB E01B D0BC DDD4 DCCB 7515 5C6D
13 years, 6 months
Re: [389-users] sub-suffix creation
by Angel Bosch Mora
----- Missatge original -----
> Hi
> I a bit confused... have you successfully created the entry using the
> console and am looking for a ldif example? Or did the creation failed
> in the console. I can give you examples of how we create our tree and
> sub suffixes if that will help, they are all in ldif format.
>
i've found some additional info here:
http://docs.sun.com/source/816-6698-10/suffixes.html#16762
i was a little bit lost but i've finally managed to create an entry trhough console. all examples i found were using ldif and command line for entry creation, but is really easy with console. just be carefull with using the exact same name as in the suffix database creation.
thanks for your time, anyway.
abosch
13 years, 6 months
incorrect DNs sometimes returned on searches: 1.2.6 and 1.2.6.1
by Eric Torgersen
Hello,
We recently started using the 389 Directory Server and are seeing an odd
problem where searches start returning the wrong DN for a small number of
entries in our directory. For example, our users are in
ou=People,dc=acs,dc=albany,dc=edu but for a few user entries the server
starts returning the DN as "uid=(username),dc=acs,dc=albany,dc=edu,"
"uid=(username),ou=Group,dc=acs,dc=albany,dc=edu," or sometimes even
something like "uid=(username),=albany,,dc=acs,dc=albany,dc=edu." The
problem seems to be in memory, as restarting the directory server fixes
the problem temporarily but then it will start happening again with a
different set of entries. A db2ldif extract made while the server is in
this state does not contain any of the bad DNs.
I tried upgrading to 1.2.6.1-2. Since the upgrade, this has not happened
for any user entries, but has happened for group entries.
Has anyone else run into this problem? We are running 389 Directory
Server on Oracle Linux 5.5 and using the x86_64 389 DS packages from EPEL.
We have about 125,000 entries in our directory, most of which are in
ou=People. We recently migrated from the Sun Directory Server 5.2.
Thanks,
Eric
Eric Torgersen
Assistant Director
ITS Systems Management & Operations
518-437-3665
13 years, 6 months
ldap_add: Already exists (68)
by Chun Tat David Chu
Hi All,
After upgrading 389 Directory Server, I am getting a "ldap_add: Already
exists (68)" error message when importing a used to be working LDIF via the
ldapmodify command.
Can someone help me to confirm that they are seeing the same thing? Adding
the entry itself is fine but the problem occurs when I try to add members to
my entry. Particularly it doesn't like the white space in between the
numbers.
Here's my LDIF.
dn: cn=mytest,dc=example,dc=com
changetype: add
objectClass: groupOfNames
objectClass: top
cn: mytest
dn: cn=mytest,dc=example,dc=com
changetype: modify
add: member
member: 111-222-3333
member: 333 222 111
member: 111 333 444
Thanks,
David
13 years, 6 months
Magic required for subtree password policy?
by Gerrard Geldenhuis
Hi
The admin guide says that one should use ns-newpwpolicy.pl script to set subtree password policies on the command line. Can we also set this using ldifs or is there some magic that this script perform that can't be achieved by using ldifs?
Regards
________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
13 years, 6 months
