389-devel August 2006

389-devel@lists.fedoraproject.org

9 participants
11 discussions

[Fedora-directory-devel] Please review: [Bug 204566] Adjustment for new LDAP C SDK
by Noriko Hosoi 29 Aug '06

29 Aug '06

Summary: Adjustment for new LDAP C SDK https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204566 Summary: Adjustment for new LDAP C SDK Product: Fedora Directory Server Version: 1.0.2 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Directory Server AssignedTo: nhosoi(a)redhat.com ReportedBy: nhosoi(a)redhat.com QAContact: ohegarty(a)redhat.com CC: ohegarty(a)redhat.com Estimated Hours: 0.0 Description of problem: LDAP C SDK function -- ber_get_next_buffer_ext's API has been changed since the Sun code merge. (See also https://bugzilla.mozilla.org/show_bug.cgi?id=347933) We need to update the connection code to adjust. ber_get_next_buffer_ext in mozilla/directory/c-sdk/ldap/libraries/liblber/io.c Original: /* * Returns the tag of the message or LBER_DEFAULT if an error occurs. There * are two cases where LBER_DEFAULT is returned: * * 1) There was not enough data in the buffer to complete the message; this * is a "soft" error. In this case, *Bytes_Scanned is set to a positive * number. * * 2) A "fatal" error occurs. In this case, *Bytes_Scanned is set to zero. * To check for specific errors, the system error number (errno) must * be consulted. These errno values are explicitly set by this * function; other errno values may be set by underlying OS functions: * * EINVAL - LBER_SOCKBUF_OPT_VALID_TAG option set but tag does not match. * EMSGSIZE - length was not represented as <= sizeof(long) bytes or the * LBER_SOCKBUF_OPT_MAX_INCOMING_SIZE option was set and the * message is longer than the maximum. *len will be set in * the latter situation. */ New: /* * Returns the tag of the message or LBER_ return code if an error occurs. * * If there was not enough data in the buffer to complete the message this * is a "soft" error. In this case, *Bytes_Scanned is set to a positive * number and return code is set to LBER_DEFAULT. * * On overflow condition when the length is either bigger than ber_uint_t * type or the value preset via LBER_SOCKBUF_OPT_MAX_INCOMING_SIZE option, * *Bytes_Scanned is set to zero and return code is set to LBER_OVERFLOW. * * For backward compatibility errno is also set on these error conditions: * * EINVAL - LBER_SOCKBUF_OPT_VALID_TAG option set but tag doesnt match. * EMSGSIZE - an overflow condition as described above for LBER_OVERFLOW. */ ------- Additional Comments From nhosoi(a)redhat.com 2006-08-29 21:26 EST ------- Created an attachment (id=135178) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=135178&action=view) cvs diff ldapserver/ldap/servers/slapd/connection.c File: ldapserver/ldap/servers/slapd/connection.c Changes: 1) When ber_get_next_buffer_ext fails, not just LBER_DEFAULT but LBER_OVERFLOW can be set to the ber tag. Thus, LBER_OVERFLOW is also checked in the error check now. 2) The too large length error used be checked as "errno == EMSGSIZE", which is replaced with "tag == LBER_OVERFLOW" 3) When the too large length error occurs, the following error was logged in the errors log, which was not appropriate since increasing nsslapd-maxbersize did not solve the problem. connection - conn=7 fd=65 Incoming BER Element was too long, max allowable is 2097152 bytes. Change the nsslapd-maxbersize attribute in cn=config to increase. Removed the error logging. 4) When the error occurs, B2 (== SLAPD_DISCONNECT_BER_TOO_BIG) is added at the end of the closed error in the access log. Error code EMSGSIZE and its description has been added: conn=7 op=-1 fd=65 closed error 90 (Message too long) - B2

1 0

[Fedora-directory-devel] Please Review: (204517) Server needs to use new ber types
by Nathan Kinder 29 Aug '06

29 Aug '06

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204517 Bug(s) fixed: 204517 Bug Description: In order to use the latest Mozilla LDAP C SDK in the directory server, we need to start using the new ber types (ber_tag_t, ber_len_t, ber_int_t, etc.). Reviewed by: ??? Files: See diffs Branch: HEAD Fix Description: These diffs are from scanning the compiler output for warnings related to the new ber types. This mainly caught places where we need to use ber_tag_t and ber_len_t. I also fixed the usage of ber_scanf() in nearby code. This fix is a first pass. We will still have to do a manual scan to check the usage of the ber_printf(), ber_scanf() and ber_get_*() functions. Platforms tested: RHEL4 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=135159

1 0

[Fedora-directory-devel] Please Review: (204355) Winsync code should be removed from ldapserver tree
by Nathan Kinder 28 Aug '06

28 Aug '06

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204355 Bug(s) fixed: 204355 Bug Description: The Windows Sync code (for both ntds.msi and passsync.msi) should be removed from the ldapserver top-level directory in the source tree. This code was moved to it's own top-level winsync directory some time ago. Reviewed by: ??? Files: See diffs Branch: HEAD Fix Description: We can safely remove the ldapserver/ldap/synctools and ldapserver/ldap/servers/ntds directories from the ldapserver tree. Some Makefile changes are also necessary to not build these pieces and to not pull some of the components needed to build them. Platforms tested: RHEL4 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=135064

3 4

Re: [Fedora-directory-devel] Samba4 onto Fedora DS
by Howard Chu 23 Aug '06

23 Aug '06

> Date: Wed, 23 Aug 2006 11:11:17 +1000 > From: Andrew Bartlett <abartlet(a)samba.org> > > Yeah, at the moment I'm looking at DS as a replicating (transactional?) > LDAP-speaking backend, which clients will never talk to. All clients > will use the Samba lens (as you so very well put it). > > Currently, the lens (written for OpenLDAP) maps entryUUID <-> > objectClass, canoncalises objectSid and objectCategory and maps some > timestamps. > I think you meant entryUUID <-> objectGUID. We've done some mapping to allow OpenLDAP to replicate to AD; it's quite convoluted. There are a variety of attributes that AD doesn't allow us to write (like objectGUID) so we retrieve them instead, and stuff them into the OpenLDAP side. -- -- 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/

1 0

[Fedora-directory-devel] Samba4 onto Fedora DS
by Andrew Bartlett 23 Aug '06

23 Aug '06

Many moons ago (November last year), I raised the idea that Samba4 might some day back onto Fedora DS. In the past few months, things have moved on, and I've done some work to back Samba4 onto OpenLDAP (which now works for a simple demo). Now I'm trying the same trick with Fedora DS. Now, I've managed to start the Fedora Directory server, and use the web (but not Java, for the J word is evil) interface. I'm happy with (and in fact prefer) command line management at this point. However, I'm now trying to load a schema into Fedora DS. I'm using the same schema that I've used with OpenLDAP, run though the od-schema-migrate.pl script. (Actually, I can also create the file directly, but they are the same, except for the dividing lines). Anyway, this is the error I get with the attached schema: [abartlet@piglett source]$ sudo /opt/fedora-ds/slapd-piglett/start-slapd Password: [22/Aug/2006:21:03:47 +1000] dse - The entry cn=schema in file /opt/fedora-ds/slapd-piglett/config/schema/01samba4.ldif is invalid, error code 20 (Type or value exists) - attribute type streetAddress: Does not match the OID "1.2.840.113556.1.2.256". Another attribute type is already using the name or OID. [22/Aug/2006:21:03:47 +1000] dse - Please edit the file to correct the reported problems and then restart the server. I can find no other reference (in the schema ldif files) to streetAddress, or that OID. Is there a list of builtin OIDs that I need to avoid conflicts with? (I had this trouble with OpenLDAP). Currently I'm adding the schema to the directory, but I expect I'll need to remove much of the Fedora DS schema. What is safe/unsafe to remove? Aside from things like the org chart not working, what else is likely to break? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com

4 13

[Fedora-directory-devel] Re: Samba4 onto Fedora DS
by Howard Chu 22 Aug '06

22 Aug '06

> Date: Tue, 22 Aug 2006 17:54:05 -0700 From: Pete Rowley > <prowley(a)redhat.com> Andrew Bartlett wrote: On Tue, 2006-08-22 at > 15:35 -0700, Pete Rowley wrote: >>> >>Why not deal with the specific problems that arise when /adding/ the AD >>> >>schema? I'm guessing that would be a shorter list? >> > >> >Because the AD schema is a whole schema, not just some extra >> >attributes/objectClasses, I need to be able to replace 'person', and >> >many other classes that Microsoft has modified. >> > >> >Once I start replacing classes, I need to know the list of 'if I replace >> >this, bad things happen'. > The problem is the list of broken things is open ended. Perhaps we > should drill down on a specific example (like the "person" objectclass > and associated attributes) and look at what is different. At least that > will make sure we are all talking about the same thing and the folks on > the list might have more targetted suggestions. > > Though, I thought the plan was to make the DS look like AD through > Sambas lens? Are we just talking about an interim development situation > until you add the "lens"? If so, I say break what you like. Otherwise I > would have big concerns about integration with existing DS deployments. Ultimately, if you need to make a clone of AD in order to satisfy Windows clients, you are going to have to break the existing LDAP standards the same way Microsoft did. You pretty much need bug-for-bug compatibility, otherwise some random MS app will come along later and break. This means doing such ugly things as requiring "cn" to be single- valued, etc. etc. Consider that Microsoft redefines the "top" objectclass to contain a plethora of attributes; it all goes downhill from there. Andrew, I certainly don't envy you the job ahead of you. Eventually, when you finish your work, you'll have another server that is just as broken and non-compliant as Microsoft's. I don't see you having a lot of choice in the matter, you just have to do what you have to do. The MS schema just doesn't coexist with real LDAP... -- -- 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/

2 1

[Fedora-directory-devel] Please Review: (203043) Password modify extended operation should generate new passwords
by Nathan Kinder 18 Aug '06

18 Aug '06

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203043 Bug(s) fixed: 203043 Bug Description: When using the password modify extended operation, if a new password is not supplied, the server should generate a new random password and return it to the user in en extended response. Reviewed by: ??? Files: passwd_extop.c Branch: HEAD Fix Description: If a user doesn't supply a new password in the password modify extop request, we will generate a random 8 character password, store it as the users password, and return it to the user in the password modify extop response. I also removed a block of code that was setting the extop return OID in the pb to the password modify OID. RFC3062 explicitly states that the password modify response should have the responseName field absent. Platforms tested: RHEL4 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=134486

1 0

[Fedora-directory-devel] Please Review: (203043) Password modify extended operation should return better errors
by Nathan Kinder 17 Aug '06

17 Aug '06

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203043 Bug(s) fixed: 203043 Bug Description: When using the password modify extended operation, the password modify request is allowed to have all three of it's fields (userIdentity, oldPassword, newPassword) empty. When this happens, our server returns LDAP_PROTOCOL_ERROR along with an error message of "ber_scanf failed". Reviewed by: ??? Files: passwd_extop.c Branch: HEAD Fix Description: Even though all three of the password modify request fields are optional, our server requires a new password to be supplied since we don't support server-side password generation. Because of this, we can safely return an error message stating that the user must supply a new password. Platforms tested: RHEL4 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=134417

1 0

[Fedora-directory-devel] Please Review: (202872) Allow the password modify extended op when using SASL privacy layer
by Nathan Kinder 16 Aug '06

16 Aug '06

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202872 Bug(s) fixed: 202872 Bug Description: The current behavior of the Directory Server is to only allow the password modify extended operation when the connection is using SSL or TLS. If you attempt to use a connection that is not using SSL or TLS, the server returns LDAP_CONFIDENTIALITY_REQUIRED. We should allow the password modify extended operation if the connection is using a SASL security layer that has privacy. Reviewed by: ??? Files: See diffs Branch: HEAD Fix Description: I added a new internal function "int ids_sasl_privacy_enabled(Connection *conn)" that will check if a SASL security layer supporting privacy has been negotiated for a particular connection. This function uses the sasl_getprop() function to check the SSF (security strength factor) to see if privacy has been negotiated. This function allows us to have the password modify extop code check if privacy is enabled so it can allow the operation to be processed. The new server behavior is to allow the password modify extended operation if using SSL, TLS, or a SASL privacy layer. All other attempts will return LDAP_CONFIDENTIALITY_REQUIRED. Platforms tested: RHEL4 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=134347

1 0

[Fedora-directory-devel] Commmit: (200988) mod_admserv: use setresuid() in lieu of seteuid() on HP-UX
by Rob Crittenden 08 Aug '06

08 Aug '06

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200988 Bug(s) fixed: 200988 Bug Description: mod_admserv: use setresuid() in lieu of seteuid() on HP/ux Reviewed by: Rich and Ulf Files: See diff Branch: HEAD Fix Description: Per Ulf's suggestion, use SETEUID macro. apxs will define -DHPUX11 on an HP/ux machine causing this code to be executed. I also included a generic HPUX and HPUX10 for completeness. Platforms tested: FC4, HPUX11 Flag Day: no Doc impact: no QA impact: no

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-devel August 2006