From rmeggins at redhat.com Thu Mar 1 02:13:34 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Wed, 28 Feb 2007 19:13:34 -0700 Subject: [Fedora-directory-devel] Please review: Bug 230498: allow ds_newinst with ldapi and no serverport Message-ID: <45E636CE.8030509@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230498 Resolves: bug 230498 Bug Description: allow ds_newinst with ldapi and no serverport Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Two new fields have been added to the ds_newinst .inf files: ldapifilepath - the full path and file name of the server ldapi file start_server - if present and has a value of 0, this tells ds_newinst not to start the server - default is 1 The ds_newinst code has been changed to allow an empty or "0" value servport if an ldapifilepath is given (and ENABLE_LDAPI is defined). Either a valid server port or an ldapifilepath must be provided, or both. In addition, I changed ds_newinst.pl to accept a .inf file given on stdin. Platforms tested: RHEL4, FC6 Flag Day: no Doc impact: We will have to document ldapi support on the wiki. https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148983&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From prowley at redhat.com Thu Mar 1 03:43:11 2007 From: prowley at redhat.com (Pete Rowley) Date: Wed, 28 Feb 2007 19:43:11 -0800 Subject: [Fedora-directory-devel] Please review: Bug 230498: allow ds_newinst with ldapi and no serverport In-Reply-To: <45E636CE.8030509@redhat.com> References: <45E636CE.8030509@redhat.com> Message-ID: <45E64BCF.8090005@redhat.com> Looks good Richard Megginson wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230498 > Resolves: bug 230498 > Bug Description: allow ds_newinst with ldapi and no serverport > Reviewed by: ??? > Files: see diff > Branch: HEAD > Fix Description: Two new fields have been added to the ds_newinst .inf > files: > ldapifilepath - the full path and file name of the server ldapi file > start_server - if present and has a value of 0, this tells ds_newinst > not to start the server - default is 1 > The ds_newinst code has been changed to allow an empty or "0" value > servport if an ldapifilepath is given (and ENABLE_LDAPI is defined). > Either a valid server port or an ldapifilepath must be provided, or both. > In addition, I changed ds_newinst.pl to accept a .inf file given on > stdin. > Platforms tested: RHEL4, FC6 > Flag Day: no > Doc impact: We will have to document ldapi support on the wiki. > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148983&action=diff > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -- Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Fri Mar 2 04:16:38 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 02 Mar 2007 15:16:38 +1100 Subject: [Fedora-directory-devel] Starting Fedora DS without shell scripts? Message-ID: <1172808998.21804.72.camel@localhost.localdomain> On a Linux system, would it be possible to build Fedora DS without setting LD_LIBRARY_PATH? I thought I saw this being discussed at some point, and I wondered if I could suggest it again. It could remove some of the shell-script wrapper stuff, which kind of looks funny... BTW, how is this packaged? I think the '-bin' versions of the commands should be in libexec, if they are not to be directly executed... Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From abartlet at samba.org Fri Mar 2 04:56:10 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 02 Mar 2007 15:56:10 +1100 Subject: [Fedora-directory-devel] Starting Fedora DS without shell scripts? In-Reply-To: <1172808998.21804.72.camel@localhost.localdomain> References: <1172808998.21804.72.camel@localhost.localdomain> Message-ID: <1172811370.21804.78.camel@localhost.localdomain> On Fri, 2007-03-02 at 15:16 +1100, Andrew Bartlett wrote: > On a Linux system, would it be possible to build Fedora DS without > setting LD_LIBRARY_PATH? As a followup, it seems to me that we don't need it (I was about to start patching makefiles): linux-gate.so.1 => (0xb7fc7000) libslapd.so.0 => /scratch/fedora-ds/prefix/lib/fedora-ds/libslapd.so.0 (0xb7f14000) libssldap60.so => /usr/lib/libssldap60.so (0xb7ef3000) libprldap60.so => /usr/lib/libprldap60.so (0xb7eed000) And my ns-slapd binary starts perfectly well without any LD_LIBRARY_PATH foo. > I thought I saw this being discussed at some point, and I wondered if I > could suggest it again. It could remove some of the shell-script > wrapper stuff, which kind of looks funny... > > BTW, how is this packaged? I think the '-bin' versions of the commands > should be in libexec, if they are not to be directly executed... Unless I'm missing something drastic, we shouldn't need these scripts at all. None of the binaries I had showed any undefined libraries... Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sparkins at redhat.com Fri Mar 2 05:52:18 2007 From: sparkins at redhat.com (Steve Parkinson) Date: Thu, 01 Mar 2007 21:52:18 -0800 Subject: [Fedora-directory-devel] Starting Fedora DS without shell scripts? In-Reply-To: <1172811370.21804.78.camel@localhost.localdomain> References: <1172808998.21804.72.camel@localhost.localdomain> <1172811370.21804.78.camel@localhost.localdomain> Message-ID: <45E7BB92.6030302@redhat.com> In all currently released versions, libraries were installed into an application-specific directory (e.g. /opt/fedora-ds). It's only recently that the libraries are put into /usr/lib. So, I guess the scripts are a relic which made it so you didn't have to add those directories to LD_LIBRARY_PATH yourself. Steve Andrew Bartlett wrote: > On Fri, 2007-03-02 at 15:16 +1100, Andrew Bartlett wrote: > >> On a Linux system, would it be possible to build Fedora DS without >> setting LD_LIBRARY_PATH? >> > > As a followup, it seems to me that we don't need it (I was about to > start patching makefiles): > > linux-gate.so.1 => (0xb7fc7000) > libslapd.so.0 > => /scratch/fedora-ds/prefix/lib/fedora-ds/libslapd.so.0 (0xb7f14000) > libssldap60.so => /usr/lib/libssldap60.so (0xb7ef3000) > libprldap60.so => /usr/lib/libprldap60.so (0xb7eed000) > > And my ns-slapd binary starts perfectly well without any LD_LIBRARY_PATH > foo. > > >> I thought I saw this being discussed at some point, and I wondered if I >> could suggest it again. It could remove some of the shell-script >> wrapper stuff, which kind of looks funny... >> >> BTW, how is this packaged? I think the '-bin' versions of the commands >> should be in libexec, if they are not to be directly executed... >> > > Unless I'm missing something drastic, we shouldn't need these scripts at > all. None of the binaries I had showed any undefined libraries... > > Andrew Bartlett > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Fri Mar 2 08:17:30 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 02 Mar 2007 19:17:30 +1100 Subject: [Fedora-directory-devel] Starting Fedora DS without shell scripts? In-Reply-To: <45E7BB92.6030302@redhat.com> References: <1172808998.21804.72.camel@localhost.localdomain> <1172811370.21804.78.camel@localhost.localdomain> <45E7BB92.6030302@redhat.com> Message-ID: <1172823450.21804.116.camel@localhost.localdomain> On Thu, 2007-03-01 at 21:52 -0800, Steve Parkinson wrote: > In all currently released versions, libraries were installed into an > application-specific directory (e.g. /opt/fedora-ds). It's only recently > that the libraries are put into /usr/lib. I'm compiling into /scratch/fedora-ds/prefix, so this isn't what is happening. I don't think libslapd belongs in /usr/lib in any case... > So, I guess the scripts are a relic which made it so you didn't have to > add those directories to LD_LIBRARY_PATH yourself. I agree it's a relic, I'm just asking that they be removed, at least on Linux. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From abartlet at samba.org Fri Mar 2 08:47:39 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 02 Mar 2007 19:47:39 +1100 Subject: [Fedora-directory-devel] [PATCH] split schema for minimal DS startup (samba4) Message-ID: <1172825260.21804.122.camel@localhost.localdomain> I've split the 00core schema, into what we really require to start Fedora DS, and rest. It is based on the work Satish earlier last year. The server starts, but without a 'make check' target, I can't verify what I've broken. It does work for loading the Samba4 schema, and we now successfully provision into the resultant directory. (it fails the tests miserably however). Also, can someone let me know where to register the schema file into the build and install system? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- --- /dev/null 2007-02-20 17:13:51.591965360 +1100 +++ ldap/schema/01notsocore.ldif 2007-03-02 17:41:33.000000000 +1100 @@ -0,0 +1,294 @@ +# +# BEGIN COPYRIGHT BLOCK +# This Program is free software; you can redistribute it and/or modify it under +# the terms of the GNU General Public License as published by the Free Software +# Foundation; version 2 of the License. +# +# This Program is distributed in the hope that it will be useful, but WITHOUT +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS +# FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License along with +# this Program; if not, write to the Free Software Foundation, Inc., 59 Temple +# Place, Suite 330, Boston, MA 02111-1307 USA. +# +# In addition, as a special exception, Red Hat, Inc. gives You the additional +# right to link the code of this Program with code not covered under the GNU +# General Public License ("Non-GPL Code") and to distribute linked combinations +# including the two, subject to the limitations in this paragraph. Non-GPL Code +# permitted under this exception must only link to the code of this Program +# through those well defined interfaces identified in the file named EXCEPTION +# found in the source code files (the "Approved Interfaces"). The files of +# Non-GPL Code may instantiate templates or use macros or inline functions from +# the Approved Interfaces without causing the resulting work to be covered by +# the GNU General Public License. Only Red Hat, Inc. may make changes or +# additions to the list of Approved Interfaces. You must obey the GNU General +# Public License in all respects for all of the Program code and other code used +# in conjunction with the Program except the Non-GPL Code covered by this +# exception. If you modify this file, you may extend this exception to your +# version of the file, but you are not obligated to do so. If you do not wish to +# provide this exception without modification, you must delete this exception +# statement from your version and license this file solely under the GPL without +# exception. +# +# +# Copyright (C) 2001 Sun Microsystems, Inc. Used by permission. +# Copyright (C) 2005 Red Hat, Inc. +# All rights reserved. +# END COPYRIGHT BLOCK +# +# +# Core schema, highly recommended but not required to start the Directory Server itself. +# +dn: cn=schema +# +# attribute types: +# +attributeTypes: ( 2.5.4.0 NAME 'objectClass' DESC 'Standard LDAP attribute type' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.1 NAME 'aliasedObjectName' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.2 NAME 'knowledgeInformation' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.4 NAME ( 'sn' 'surName' ) DESC 'Standard LDAP attribute type' SUP name X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.5 NAME 'serialNumber' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.6 NAME ( 'c' 'countryName' ) DESC 'Standard LDAP attribute type' SUP name SINGLE-VALUE X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.7 NAME ( 'l' 'locality' 'localityname' ) DESC 'Standard LDAP attribute type' SUP name X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.8 NAME ( 'st' 'stateOrProvinceName' ) DESC 'Standard LDAP attribute type' SUP name X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.9 NAME ( 'street' 'streetaddress' ) DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.10 NAME ( 'o' 'organizationname' ) DESC 'Standard LDAP attribute type' SUP name X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' ) DESC 'Standard LDAP attribute type' SUP name X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.12 NAME 'title' DESC 'Standard LDAP attribute type' SUP name X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.14 NAME 'searchGuide' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.15 NAME 'businessCategory' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.16 NAME 'postalAddress' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.17 NAME 'postalCode' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.18 NAME 'postOfficeBox' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.19 NAME 'physicalDeliveryOfficeName' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.20 NAME 'telephoneNumber' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.21 NAME 'telexNumber' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.22 NAME 'teletexTerminalIdentifier' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.23 NAME ( 'facsimileTelephoneNumber' 'fax' ) DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.24 NAME 'x121Address' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.25 NAME 'internationaliSDNNumber' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.26 NAME 'registeredAddress' DESC 'Standard LDAP attribute type' SUP postalAddress X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.27 NAME 'destinationIndicator' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.28 NAME 'preferredDeliveryMethod' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.29 NAME 'presentationAddress' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.30 NAME 'supportedApplicationContext' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.31 NAME 'member' DESC 'Standard LDAP attribute type' SUP distinguishedName X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.32 NAME 'owner' DESC 'Standard LDAP attribute type' SUP distinguishedName X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.33 NAME 'roleOccupant' DESC 'Standard LDAP attribute type' SUP distinguishedName X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.36 NAME 'userCertificate' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.37 NAME 'cACertificate' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.38 NAME 'authorityRevocationList' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.39 NAME 'certificateRevocationList' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.40 NAME 'crossCertificatePair' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.42 NAME 'givenName' DESC 'Standard LDAP attribute type' SUP name X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.43 NAME 'initials' DESC 'Standard LDAP attribute type' SUP name X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.44 NAME 'generationQualifier' DESC 'Standard LDAP attribute type' SUP name X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.45 NAME 'x500UniqueIdentifier' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.46 NAME 'dnQualifier' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.47 NAME 'enhancedSearchGuide' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.48 NAME 'protocolInformation' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.50 NAME 'uniqueMember' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.51 NAME 'houseIdentifier' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.52 NAME 'supportedAlgorithms' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.53 NAME 'deltaRevocationList' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 2.5.4.54 NAME 'dmdName' SUP name X-ORIGIN 'RFC 2256' ) +attributeTypes: ( 0.9.2342.19200300.100.1.1 NAME ( 'uid' 'userid' ) DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 1274' ) +attributeTypes: ( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822mailbox' ) DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 1274' ) +attributeTypes: ( 0.9.2342.19200300.100.1.6 NAME 'roomNumber' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 1274' ) +attributeTypes: ( 0.9.2342.19200300.100.1.10 NAME 'manager' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'RFC 1274' ) +attributeTypes: ( 0.9.2342.19200300.100.1.20 NAME 'homePhone' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 X-ORIGIN 'RFC 1274' ) +attributeTypes: ( 0.9.2342.19200300.100.1.21 NAME 'secretary' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'RFC 1274' ) +attributeTypes: ( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 1274' ) +attributeTypes: ( 0.9.2342.19200300.100.1.41 NAME ( 'mobile' 'mobileTelephoneNumber' ) DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 X-ORIGIN 'RFC 1274' ) +attributeTypes: ( 0.9.2342.19200300.100.1.42 NAME ( 'pager' 'pagerTelephoneNumber' ) DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 X-ORIGIN 'RFC 1274' ) +attributeTypes: ( 0.9.2342.19200300.100.1.43 NAME ( 'co' 'friendlycountryname' ) DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 1274' ) +attributeTypes: ( 0.9.2342.19200300.100.1.55 NAME 'audio' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 X-ORIGIN 'RFC 1274' ) +attributeTypes: ( 0.9.2342.19200300.100.1.60 NAME 'jpegPhoto' DESC 'inetOrgPerson attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 X-ORIGIN 'RFC 2798' ) +attributeTypes: ( 1.3.6.1.4.1.250.1.57 NAME ( 'labeledUri' 'labeledurl' ) DESC 'Uniform Resource Identifier with optional label' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'RFC 2079' ) +attributeTypes: ( 2.16.840.1.113730.3.1.1 NAME 'carLicense' DESC 'inetOrgPerson attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2798' ) +attributeTypes: ( 2.16.840.1.113730.3.1.2 NAME 'departmentNumber' DESC 'inetOrgPerson attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2798' ) +attributeTypes: ( 2.16.840.1.113730.3.1.3 NAME 'employeeNumber' DESC 'inetOrgPerson attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'RFC 2798' ) +attributeTypes: ( 2.16.840.1.113730.3.1.4 NAME 'employeeType' DESC 'inetOrgPerson attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2798' ) +attributeTypes: ( 2.16.840.1.113730.3.1.5 NAME 'changeNumber' DESC 'Changelog attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'Changelog Internet Draft' ) +attributeTypes: ( 2.16.840.1.113730.3.1.6 NAME 'targetDn' DESC 'Changelog attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'Changelog Internet Draft' ) +attributeTypes: ( 2.16.840.1.113730.3.1.7 NAME 'changeType' DESC 'Changelog attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Changelog Internet Draft' ) +attributeTypes: ( 2.16.840.1.113730.3.1.8 NAME 'changes' DESC 'Changelog attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 X-ORIGIN 'Changelog Internet Draft' ) +attributeTypes: ( 2.16.840.1.113730.3.1.9 NAME 'newRdn' DESC 'Changelog attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'Changelog Internet Draft' ) +attributeTypes: ( 2.16.840.1.113730.3.1.10 NAME 'deleteOldRdn' DESC 'Changelog attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 X-ORIGIN 'Changelog Internet Draft' ) +attributeTypes: ( 2.16.840.1.113730.3.1.11 NAME 'newSuperior' DESC 'Changelog attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'Changelog Internet Draft' ) +attributeTypes: ( 2.16.840.1.113730.3.1.34 NAME 'ref' DESC 'LDAP referrals attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'LDAPv3 referrals Internet Draft' ) +attributeTypes: ( 2.5.18.10 NAME 'subschemaSubentry' DESC 'Standard LDAP attribute type' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation X-ORIGIN 'RFC 2252' ) +attributeTypes: ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation X-ORIGIN 'RFC 2252' ) +attributeTypes: ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE dSAOperation X-ORIGIN 'RFC 2252' ) +attributeTypes: ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation X-ORIGIN 'RFC 2252' ) +attributeTypes: ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation X-ORIGIN 'RFC 2252' ) +attributeTypes: ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE dSAOperation X-ORIGIN 'RFC 2252' ) +attributeTypes: ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 USAGE dSAOperation X-ORIGIN 'RFC 2252' ) +attributeTypes: ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE directoryOperation X-ORIGIN 'RFC 2252' ) +attributeTypes: ( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures' DESC 'features supported by the server' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation ) +attributeTypes: ( 2.16.840.1.113730.3.1.36 NAME 'nsLicensedFor' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Netscape Administration Services' ) +attributeTypes: ( 2.16.840.1.113730.3.1.37 NAME 'nsLicenseStartTime' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Netscape Administration Services' ) +attributeTypes: ( 2.16.840.1.113730.3.1.38 NAME 'nsLicenseEndTime' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Netscape Administration Services' ) +attributeTypes: ( 2.16.840.1.113730.3.1.39 NAME 'preferredLanguage' DESC 'inetOrgPerson attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'RFC 2798' ) +attributeTypes: ( 2.16.840.1.113730.3.1.40 NAME 'userSMIMECertificate' DESC 'inetOrgPerson attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 X-ORIGIN 'RFC 2798' ) +attributeTypes: ( 2.16.840.1.113730.3.1.70 NAME 'serverRoot' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Netscape Administration Services' ) +attributeTypes: ( 2.16.840.1.113730.3.1.71 NAME 'serverProductName' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Netscape Administration Services' ) +attributeTypes: ( 2.16.840.1.113730.3.1.72 NAME 'serverVersionNumber' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Netscape Administration Services' ) +attributeTypes: ( 2.16.840.1.113730.3.1.73 NAME 'installationTimeStamp' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Netscape Administration Services' ) +attributeTypes: ( 2.16.840.1.113730.3.1.74 NAME 'administratorContactInfo' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Netscape Administration Services' ) +attributeTypes: ( 2.16.840.1.113730.3.1.75 NAME 'adminUrl' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'Netscape Administration Services' ) +attributeTypes: ( 2.16.840.1.113730.3.1.76 NAME 'serverHostName' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Netscape Administration Services' ) +attributeTypes: ( 2.16.840.1.113730.3.1.77 NAME 'changeTime' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.91 NAME 'passwordExpirationTime' DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.92 NAME ( 'passwordExpWarned' 'pwdExpirationWarned' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.93 NAME 'passwordRetryCount' DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.94 NAME 'retryCountResetTime' DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.95 NAME 'accountUnlockTime' DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.96 NAME ( 'passwordHistory' 'pwdHistory' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.97 NAME ( 'passwordMaxAge' 'pwdMaxAge' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.98 NAME 'passwordExp' DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.99 NAME ( 'passwordMinLength' 'pwdMinLength' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.100 NAME 'passwordKeepHistory' DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.101 NAME ( 'passwordInHistory' 'pwdInHistory' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.102 NAME ( 'passwordChange' 'pwdAllowUserChange' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.103 NAME ( 'passwordCheckSyntax' 'pwdCheckSyntax' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.104 NAME ( 'passwordWarning' 'pwdExpireWarning' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.105 NAME ( 'passwordLockout' 'pwdLockOut' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.106 NAME ( 'passwordMaxFailure' 'pwdMaxFailure' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.107 NAME 'passwordResetDuration' DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.108 NAME 'passwordUnlock' DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.109 NAME ( 'passwordLockoutDuration' 'pwdLockoutDuration' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.997 NAME 'pwdpolicysubentry' DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.998 NAME ( 'passwordGraceUserTime' 'pwdGraceUserTime' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.999 NAME ( 'passwordGraceLimit' 'pwdGraceLoginLimit' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.2075 NAME ( 'passwordMinDigits' 'pwdMinDigits' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.2076 NAME ( 'passwordMinAlphas' 'pwdMinAlphas' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.2077 NAME ( 'passwordMinUppers' 'pwdMinUppers' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.2078 NAME ( 'passwordMinLowers' 'pwdMinLowers' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.2079 NAME ( 'passwordMinSpecials' 'pwdMinSpecials' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.2080 NAME ( 'passwordMin8bit' 'pwdMin8bit' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.2081 NAME ( 'passwordMaxRepeats' 'pwdMaxRepeats' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.2082 NAME ( 'passwordMinCategories' 'pwdMinCategories' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.2083 NAME ( 'passwordMinTokenLength' 'pwdMinTokenLength' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.198 NAME 'memberURL' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.199 NAME 'memberCertificateDescription' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.207 NAME 'vlvBase' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.208 NAME 'vlvScope' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.209 NAME 'vlvFilter' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.210 NAME 'vlvSort' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.213 NAME 'vlvEnabled' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.214 NAME 'passwordAllowChangeTime' DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.216 NAME 'userPKCS12' DESC 'inetOrgPerson attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 X-ORIGIN 'RFC 2798' ) +attributeTypes: ( 2.16.840.1.113730.3.1.219 NAME 'vlvUses' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.220 NAME ( 'passwordMustChange' 'pwdMustChange' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.221 NAME 'passwordStorageScheme' DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.222 NAME ( 'passwordMinAge' 'pwdMinAge' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.223 NAME ( 'passwordResetFailureCount' 'pwdFailureCountInterval' ) DESC 'Netscape defined password policy attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.241 NAME 'displayName' DESC 'inetOrgPerson attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'RFC 2798' ) +attributeTypes: ( 2.16.840.1.113730.3.1.550 NAME 'cosAttribute' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.551 NAME 'cosspecifier' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.552 NAME 'costargettree' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.553 NAME 'costemplatedn' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.35 NAME 'changeLog' DESC 'the distinguished name of the entry which contains the set of entries comprising this servers changelog' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'Changelog Internet Draft' ) +attributeTypes: ( 2.16.840.1.113730.3.1.200 NAME 'changeLogMaximumAge' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.201 NAME 'changeLogMaximumSize' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.205 NAME 'changeLogMaximumConcurrentWrites' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 1.3.6.1.4.1.250.1.60 NAME ( 'ttl' 'timeToLive' ) DESC 'time to live in seconds for cached objects' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'LDAP Caching Internet Draft' ) +attributeTypes: ( 0.9.2342.19200300.100.1.7 NAME 'photo' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 X-ORIGIN 'RFC 1274' ) +attributeTypes: ( 2.16.840.1.113730.3.1.612 NAME 'generation' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 1.3.1.1.4.1.453.16.2.103 NAME 'numSubordinates' DESC 'count of immediate subordinates' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation X-ORIGIN 'numSubordinates Internet Draft' ) +attributeTypes: ( 2.5.18.9 NAME 'hasSubordinates' DESC 'if TRUE, subordinate entries may exist' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation X-ORIGIN 'numSubordinates Internet Draft' ) +attributeTypes: ( 2.16.840.1.113730.3.1.569 NAME 'cosPriority' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.570 NAME 'nsLookThroughLimit' DESC 'Binder-based search operation look through limit (candidate entries)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.571 NAME 'nsSizeLimit' DESC 'Binder-based search operation size limit (entries)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.572 NAME 'nsTimeLimit' DESC 'Binder-based search operation time limit (seconds)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.573 NAME 'nsIdleTimeout' DESC 'Binder-based connection idle timeout (seconds)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.574 NAME 'nsRole' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.575 NAME 'nsRoleDN' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.576 NAME 'nsRoleFilter' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.577 NAME 'cosIndirectSpecifier' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.610 NAME 'nsAccountLock' DESC 'Operational attribute for Account Inactivation' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.613 NAME 'copiedFrom' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.614 NAME 'copyingFrom' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.803 NAME 'nsBackendSuffix' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.973 NAME 'nsds5ReplConflict' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.1000 NAME 'nsds7WindowsReplicaSubtree' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.1001 NAME 'nsds7DirectoryReplicaSubtree' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.1002 NAME 'nsds7NewWinUserSyncEnabled' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.1003 NAME 'nsds7NewWinGroupSyncEnabled' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.1004 NAME 'nsds7WindowsDomain' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.1005 NAME 'nsds7DirsyncCookie' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 1.3.6.1.1.4 NAME 'vendorName' EQUALITY 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation X-ORIGIN 'RFC 3045' ) +attributeTypes: ( 1.3.6.1.1.5 NAME 'vendorVersion' EQUALITY 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation X-ORIGIN 'RFC 3045' ) +attributeTypes: ( 2.16.840.1.113730.3.1.3023 NAME 'nsViewFilter' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.2063 NAME 'nsEncryptionAlgorithm' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.2064 NAME 'nsSaslMapRegexString' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.2065 NAME 'nsSaslMapBaseDNTemplate' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +attributeTypes: ( 2.16.840.1.113730.3.1.2066 NAME 'nsSaslMapFilterTemplate' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' ) +# +# objectclasses: +# +objectClasses: ( 2.5.6.1 NAME 'alias' DESC 'Standard LDAP objectclass' SUP top ABSTRACT MUST ( aliasedObjectName ) X-ORIGIN 'RFC 2256' ) +objectClasses: ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' DESC 'LDAPv3 extensible object' SUP top AUXILIARY X-ORIGIN 'RFC 2252' ) +objectClasses: ( 2.5.6.2 NAME 'country' DESC 'Standard LDAP objectclass' SUP top MUST ( c ) MAY ( searchGuide $ description ) X-ORIGIN 'RFC 2256' ) +objectClasses: ( 2.5.6.3 NAME 'locality' DESC 'Standard LDAP attribute type' SUP top MAY ( description $ l $ searchGuide $ seeAlso $ st $ street ) X-ORIGIN 'RFC 2256' ) +objectClasses: ( 2.5.6.4 NAME 'organization' DESC 'Standard LDAP objectclass' SUP top MUST ( o ) MAY ( businessCategory $ description $ destinationIndicator $ facsimileTelephoneNumber $ internationaliSDNNumber $ l $ physicalDeliveryOfficeName $ postOfficeBox $ postalAddress $ postalCode $ preferredDeliveryMethod $ registeredAddress $ searchGuide $ seeAlso $ st $ street $ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ userPassword $ x121Address ) X-ORIGIN 'RFC 2256' ) +objectClasses: ( 2.5.6.5 NAME 'organizationalUnit' DESC 'Standard LDAP objectclass' SUP top MUST ( ou ) MAY ( businessCategory $ description $ destinationIndicator $ facsimileTelephoneNumber $ internationaliSDNNumber $ l $ physicalDeliveryOfficeName $ postOfficeBox $ postalAddress $ postalCode $ preferredDeliveryMethod $ registeredAddress $ searchGuide $ seeAlso $ st $ street $ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ userPassword $ x121Address ) X-ORIGIN 'RFC 2256' ) +objectClasses: ( 2.5.6.6 NAME 'person' DESC 'Standard LDAP objectclass' SUP top MUST ( sn $ cn ) MAY ( description $ seeAlso $ telephoneNumber $ userPassword ) X-ORIGIN 'RFC 2256' ) +objectClasses: ( 2.5.6.7 NAME 'organizationalPerson' DESC 'Standard LDAP objectclass' SUP person MAY ( destinationIndicator $ facsimileTelephoneNumber $ internationaliSDNNumber $ l $ ou $ physicalDeliveryOfficeName $ postOfficeBox $ postalAddress $ postalCode $ preferredDeliveryMethod $ registeredAddress $ st $ street $ teletexTerminalIdentifier $ telexNumber $ title $ x121Address ) X-ORIGIN 'RFC 2256' ) +objectClasses: ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' DESC 'Internet extended organizational person objectclass' SUP organizationalPerson MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ displayName $ employeeType $ employeeNumber $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ manager $ mobile $ pager $ photo $ preferredLanguage $ mail $ o $ roomNumber $ secretary $ uid $ x500uniqueIdentifier $ userCertificate $ userSMimeCertificate $ userPKCS12 ) X-ORIGIN 'RFC 2798' ) +objectClasses: ( 2.5.6.8 NAME 'organizationalRole' DESC 'Standard LDAP objectclass' SUP top MUST ( cn ) MAY ( description $ destinationIndicator $ facsimileTelephoneNumber $ internationaliSDNNumber $ l $ ou $ physicalDeliveryOfficeName $ postOfficeBox $ postalAddress $ postalCode $ preferredDeliveryMethod $ registeredAddress $ roleOccupant $ seeAlso $ st $ street $ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ x121Address ) X-ORIGIN 'RFC 2256' ) +objectClasses: ( 2.5.6.9 NAME 'groupOfNames' DESC 'Standard LDAP objectclass' SUP top MUST ( cn ) MAY ( member $ businessCategory $ description $ o $ ou $ owner $ seeAlso ) X-ORIGIN 'RFC 2256' ) +objectClasses: ( 2.5.6.17 NAME 'groupOfUniqueNames' DESC 'Standard LDAP objectclass' SUP top MUST ( cn ) MAY ( uniqueMember $ businessCategory $ description $ o $ ou $ owner $ seeAlso ) X-ORIGIN 'RFC 2256' ) +objectClasses: ( 2.16.840.1.113730.3.2.31 NAME 'groupOfCertificates' DESC 'Netscape defined objectclass' SUP top MUST ( cn ) MAY ( memberCertificateDescription $ businessCategory $ description $ o $ ou $ owner $ seeAlso ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.33 NAME 'groupOfURLs' DESC 'Netscape defined objectclass' SUP top MUST ( cn ) MAY ( memberURL $ businessCategory $ description $ o $ ou $ owner $ seeAlso ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.5.6.10 NAME 'residentialPerson' DESC 'Standard LDAP objectclass' SUP person MUST ( l ) MAY ( businessCategory $ destinationIndicator $ facsimileTelephoneNumber $ internationaliSDNNumber $ physicalDeliveryOfficeName $ postOfficeBox $ postalAddress $ postalCode $ preferredDeliveryMethod $ registeredAddress $ st $ street $ teletexTerminalIdentifier $ telexNumber $ x121Address ) X-ORIGIN 'RFC 2256' ) +objectClasses: ( 2.5.6.11 NAME 'applicationProcess' DESC 'Standard LDAP objectclass' SUP top MUST ( cn ) MAY ( description $ l $ ou $ seeAlso ) X-ORIGIN 'RFC 2256' ) +objectClasses: ( 2.16.840.1.113730.3.2.35 NAME 'LDAPServer' DESC 'Netscape defined objectclass' SUP top MUST ( cn ) MAY ( description $ l $ ou $ seeAlso $ generation $ changeLogMaximumAge $ changeLogMaximumSize ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.5.6.12 NAME 'applicationEntity' DESC 'Standard LDAP objectclass' SUP top MUST ( presentationAddress $ cn ) MAY ( description $ l $ o $ ou $ seeAlso $ supportedApplicationContext ) X-ORIGIN 'RFC 2256' ) +objectClasses: ( 2.5.6.13 NAME 'dSA' DESC 'Standard LDAP objectclass' SUP applicationEntity MAY ( knowledgeInformation ) X-ORIGIN 'RFC 2256' ) +objectClasses: ( 2.5.6.14 NAME 'device' DESC 'Standard LDAP objectclass' SUP top MUST ( cn ) MAY ( description $ l $ o $ ou $ owner $ seeAlso $ serialNumber ) X-ORIGIN 'RFC 2256' ) +objectClasses: ( 2.5.6.15 NAME 'strongAuthenticationUser' DESC 'Standard LDAP objectclass' SUP top AUXILIARY MUST ( userCertificate ) X-ORIGIN 'RFC 2256' ) +objectClasses: ( 2.5.6.16 NAME 'certificationAuthority' DESC 'Standard LDAP objectclass' SUP top AUXILIARY MUST ( authorityRevocationList $ certificateRevocationList $ cACertificate ) MAY crossCertificatePair X-ORIGIN 'RFC 2256' ) +objectClasses: ( 2.5.6.16.2 NAME 'certificationAuthority-V2' DESC 'Standard LDAP objectclass' SUP certificationAuthority MAY deltaRevocationList X-ORIGIN 'RFC 2256' ) +objectClasses: ( 2.5.6.18 NAME 'userSecurityInformation' SUP top AUXILIARY MAY ( supportedAlgorithms ) X-ORIGIN 'RFC 2256' ) +objectClasses: ( 2.5.6.19 NAME 'cRLDistributionPoint' SUP top STRUCTURAL MUST ( cn ) MAY ( certificateRevocationList $ authorityRevocationList $ deltaRevocationList ) X-ORIGIN 'RFC 2256' ) +objectClasses: ( 2.5.6.20 NAME 'dmd' SUP top STRUCTURAL MUST ( dmdName ) MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) X-ORIGIN 'RFC 2256' ) +objectClasses: ( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject' DESC 'object that contains the URI attribute type' SUP top AUXILIARY MAY ( labeledURI ) X-ORIGIN 'RFC 2079' ) +objectClasses: ( 1.3.6.1.4.1.250.3.18 NAME 'cacheObject' DESC 'object that contains the TTL (time to live) attribute type' SUP top MAY ( ttl ) X-ORIGIN 'LDAP Caching Internet Draft' ) +objectClasses: ( 2.16.840.1.113730.3.2.10 NAME 'netscapeServer' DESC 'Netscape defined objectclass' SUP top MUST ( cn ) MAY ( description $ serverRoot $ serverProductName $ serverVersionNumber $ installationTimeStamp $ administratorContactInfo $ userpassword $ adminURL $ serverHostName ) X-ORIGIN 'Netscape Administration Services' ) +objectClasses: ( 2.16.840.1.113730.3.2.7 NAME 'nsLicenseUser' DESC 'Netscape defined objectclass' SUP top MAY ( nsLicensedFor $ nsLicenseStartTime $ nsLicenseEndTime ) X-ORIGIN 'Netscape Administration Services' ) +objectClasses: ( 2.16.840.1.113730.3.2.1 NAME 'changeLogEntry' DESC 'LDAP changelog objectclass' SUP top MUST ( targetdn $ changeTime $ changenumber $ changeType ) MAY ( changes $ newrdn $ deleteoldrdn $ newsuperior ) X-ORIGIN 'Changelog Internet Draft' ) +objectClasses: ( 2.16.840.1.113730.3.2.6 NAME 'referral' DESC 'LDAP referrals objectclass' SUP top MAY ( ref ) X-ORIGIN 'LDAPv3 referrals Internet Draft' ) +objectClasses: ( 2.16.840.1.113730.3.2.12 NAME 'passwordObject' DESC 'Netscape defined password policy objectclass' SUP top MAY ( pwdpolicysubentry $ passwordExpirationTime $ passwordExpWarned $ passwordRetryCount $ retryCountResetTime $ accountUnlockTime $ passwordHistory $ passwordAllowChangeTime $ passwordGraceUserTime ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.13 NAME 'passwordPolicy' DESC 'Netscape defined password policy objectclass' SUP top MAY ( passwordMaxAge $ passwordExp $ passwordMinLength $ passwordKeepHistory $ passwordInHistory $ passwordChange $ passwordWarning $ passwordLockout $ passwordMaxFailure $ passwordResetDuration $ passwordUnlock $ passwordLockoutDuration $ passwordCheckSyntax $ passwordMustChange $ passwordStorageScheme $ passwordMinAge $ passwordResetFailureCount $ passwordGraceLimit $ passwordMinDigits $ passwordMinAlphas $ passwordMinUppers $ passwordMinLowers $ passwordMinSpecials $ passwordMin8bit $ passwordMaxRepeats $ passwordMinCategories $ passwordMinTokenLength ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.30 NAME 'glue' DESC 'Netscape defined objectclass' SUP top X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.32 NAME 'netscapeMachineData' DESC 'Netscape defined objectclass' SUP top X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.38 NAME 'vlvSearch' DESC 'Netscape defined objectclass' SUP top MUST ( cn $ vlvBase $ vlvScope $ vlvFilter ) MAY ( multiLineDescription ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.39 NAME 'nsslapdConfig' DESC 'Netscape defined objectclass' SUP top MAY ( cn ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113719.2.142.6.1.1 NAME 'ldapSubEntry' DESC 'LDAP Subentry class, version 1' SUP top STRUCTURAL MAY ( cn ) X-ORIGIN 'LDAP Subentry Internet Draft' ) +objectClasses: ( 2.16.840.1.113730.3.2.39 NAME 'nsslapdConfig' DESC 'Netscape defined objectclass' SUP top MAY ( cn ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.42 NAME 'vlvIndex' DESC 'Netscape defined objectclass' SUP top MUST ( cn $ vlvSort ) MAY ( vlvEnabled $ vlvUses ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.43 NAME 'nsSNMP' DESC 'Netscape defined objectclass' SUP top MUST ( cn $ nsSNMPEnabled ) MAY ( nsSNMPOrganization $ nsSNMPLocation $ nsSNMPContact $ nsSNMPDescription $ nsSNMPName $ nsSNMPMasterHost $ nsSNMPMasterPort ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.84 NAME 'cosDefinition' DESC 'Netscape defined objectclass' SUP top MAY ( costargettree $ costemplatedn $ cosspecifier $ cosattribute $ aci $ cn $ uid ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113719.2.142.6.1.1 NAME 'ldapSubEntry' DESC 'LDAP Subentry class, version 1' SUP top STRUCTURAL MAY ( cn ) X-ORIGIN 'LDAP Subentry Internet Draft' ) +objectClasses: ( 2.16.840.1.113730.3.2.93 NAME 'nsRoleDefinition' DESC 'Netscape defined objectclass' SUP ldapSubEntry MAY ( description ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.94 NAME 'nsSimpleRoleDefinition' DESC 'Netscape defined objectclass' SUP nsRoleDefinition X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.95 NAME 'nsComplexRoleDefinition' DESC 'Netscape defined objectclass' SUP nsRoleDefinition X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.96 NAME 'nsManagedRoleDefinition' DESC 'Netscape defined objectclass' SUP nsSimpleRoleDefinition X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.97 NAME 'nsFilteredRoleDefinition' DESC 'Netscape defined objectclass' SUP nsComplexRoleDefinition MUST ( nsRoleFilter ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.98 NAME 'nsNestedRoleDefinition' DESC 'Netscape defined objectclass' SUP nsComplexRoleDefinition MUST ( nsRoleDN ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.99 NAME 'cosSuperDefinition' DESC 'Netscape defined objectclass' SUP ldapSubEntry MUST (cosattribute) MAY ( description ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.100 NAME 'cosClassicDefinition' DESC 'Netscape defined objectclass' SUP cosSuperDefinition MAY ( cosTemplateDn $ cosspecifier ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.101 NAME 'cosPointerDefinition' DESC 'Netscape defined objectclass' SUP cosSuperDefinition MAY ( cosTemplateDn ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.102 NAME 'cosIndirectDefinition' DESC 'Netscape defined objectclass' SUP cosSuperDefinition MAY ( cosIndirectSpecifier ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.103 NAME 'nsDS5ReplicationAgreement' DESC 'Netscape defined objectclass' SUP top MUST ( cn ) MAY ( nsDS5ReplicaHost $ nsDS5ReplicaPort $ nsDS5ReplicaTransportInfo $ nsDS5ReplicaBindDN $ nsDS5ReplicaCredentials $ nsDS5ReplicaBindMethod $ nsDS5ReplicaRoot $ nsDS5ReplicatedAttributeList $ nsDS5ReplicaUpdateSchedule $ nsds5BeginReplicaRefresh $ description $ nsds50ruv $ nsruvReplicaLastModified $ nsds5ReplicaTimeout $ nsds5replicaChangesSentSinceStartup $ nsds5replicaLastUpdateEnd $ nsds5replicaLastUpdateStart $ nsds5replicaLastUpdateStatus $ nsds5replicaUpdateInProgress $ nsds5replicaLastInitEnd $ nsds5replicaLastInitStart $ nsds5replicaLastInitStatus $ nsds5debugreplicatimeout $ nsds5replicaBusyWaitTime $ nsds5replicaSessionPauseTime ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.503 NAME 'nsDSWindowsReplicationAgreement' DESC 'Netscape defined objectclass' SUP top MUST ( cn ) MAY ( nsDS5ReplicaHost $ nsDS5ReplicaPort $ nsDS5ReplicaTransportInfo $ nsDS5ReplicaBindDN $ nsDS5ReplicaCredentials $ nsDS5ReplicaBindMethod $ nsDS5ReplicaRoot $ nsDS5ReplicatedAttributeList $ nsDS5ReplicaUpdateSchedule $ nsds5BeginReplicaRefresh $ description $ nsds50ruv $ nsruvReplicaLastModified $ nsds5ReplicaTimeout $ nsds5replicaChangesSentSinceStartup $ nsds5replicaLastUpdateEnd $ nsds5replicaLastUpdateStart $ nsds5replicaLastUpdateStatus $ nsds5replicaUpdateInProgress $ nsds5replicaLastInitEnd $ nsds5replicaLastInitStart $ nsds5replicaLastInitStatus $ nsds5debugreplicatimeout $ nsds5replicaBusyWaitTime $ nsds5replicaSessionPauseTime $ nsds7WindowsReplicaSubtree $ nsds7DirectoryReplicaSubtree $ nsds7NewWinUserSyncEnabled $ nsds7NewWinGroupSyncEnabled $ nsds7WindowsDomain $ nsds7DirsyncCookie) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.104 NAME 'nsContainer' DESC 'Netscape defined objectclass' SUP top MUST ( CN ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.108 NAME 'nsDS5Replica' DESC 'Netscape defined objectclass' SUP top MUST ( nsDS5ReplicaRoot $ nsDS5ReplicaId ) MAY (cn $ nsDS5ReplicaType $ nsDS5ReplicaBindDN $ nsState $ nsDS5ReplicaName $ nsDS5Flags $ nsDS5Task $ nsDS5ReplicaReferral $ nsDS5ReplicaAutoReferral $ nsds5ReplicaPurgeDelay $ nsds5ReplicaTombstonePurgeInterval $ nsds5ReplicaChangeCount $ nsds5ReplicaLegacyConsumer) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.113 NAME 'nsTombstone' DESC 'Netscape defined objectclass' SUP top MAY ( nsParentUniqueId $ nscpEntryDN ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.128 NAME 'costemplate' DESC 'Netscape defined objectclass' SUP top MAY ( cn $ cospriority ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.304 NAME 'nsView' DESC 'Netscape defined objectclass' SUP top AUXILIARY MAY ( nsViewFilter $ description ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.316 NAME 'nsAttributeEncryption' DESC 'Netscape defined objectclass' SUP top MUST ( cn $ nsEncryptionAlgorithm ) X-ORIGIN 'Netscape Directory Server' ) +objectClasses: ( 2.16.840.1.113730.3.2.317 NAME 'nsSaslMapping' DESC 'Netscape defined objectclass' SUP top MUST ( cn $ nsSaslMapRegexString $ nsSaslMapBaseDNTemplate $ nsSaslMapFilterTemplate ) X-ORIGIN 'Netscape Directory Server' ) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From abartlet at samba.org Fri Mar 2 11:25:02 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 02 Mar 2007 22:25:02 +1100 Subject: [Fedora-directory-devel] Samba4 integration status Message-ID: <1172834702.21804.151.camel@localhost.localdomain> I've now got Samba4 to provision to a Fedora DS server. It is very easy to do, provided you have current CVS, and the patch I included in my last mail to fedora-directory-devel. To test Samba4 and Fedora DS, compile Fedora DS and Samba4 as usual, from their respective version control systems. Install Fedora DS, and note the prefix chosen. In Samba's source/ dir, run: TEST_LDAP=yes FEDORA_DS_PREFIX=/fedora-ds/prefix make quicktest If you have OpenLDAP's slapd on the system, you can also try it for comparison, by omitting the FEDORA_DS_PREFIX setting. It should pass most of the tests (I know of a timeout on the RPC-LSA test). Once we get 'make quicktest' passing, we can aim for the full 'make test'. Currently, it looks like there is a lot of work to do. This is surprising, as OpenLDAP does better, and the two servers are not *that* different... To re-run any tests in the test environment, run: TEST_LDAP=yes FEDORA_DS_PREFIX=/fedora-ds/prefix make testenv This will set everything up, but instead of running tests, it will launch an xterm, ready for manual testing/probing/debugging. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rmeggins at redhat.com Fri Mar 2 15:34:06 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 02 Mar 2007 08:34:06 -0700 Subject: [Fedora-directory-devel] Starting Fedora DS without shell scripts? In-Reply-To: <1172823450.21804.116.camel@localhost.localdomain> References: <1172808998.21804.72.camel@localhost.localdomain> <1172811370.21804.78.camel@localhost.localdomain> <45E7BB92.6030302@redhat.com> <1172823450.21804.116.camel@localhost.localdomain> Message-ID: <45E843EE.9010104@redhat.com> Andrew Bartlett wrote: > On Thu, 2007-03-01 at 21:52 -0800, Steve Parkinson wrote: > >> In all currently released versions, libraries were installed into an >> application-specific directory (e.g. /opt/fedora-ds). It's only recently >> that the libraries are put into /usr/lib. >> > > I'm compiling into /scratch/fedora-ds/prefix, so this isn't what is > happening. I don't think libslapd belongs in /usr/lib in any case... > Where should libslapd.so go? The reason it works is because libtool links ns-slapd against libslapd.so using rpath. I'm not sure why, and the Fedora folks generally frown upon the use of rpath. So if someone makes us take out the rpath, we'll either 1) have to move libslapd.so to one of the system lib paths 2) continue to use a script that sets LD_LIBRARY_PATH 3) use ldconfig to add $_libdir/fedora-ds to the default ld.so path The other nice thing about having a script is that it gives us the ability to insulate ourselves from incompatible changes on the operating system. Let's say that for some reason the system is upgraded to a version of libdb4 that we know has problems with DS, but must be used for other applications on the system. If we use the shell script, this gives us the ability to drop in our own private version of libdb into $libdir/fedora-ds without either interfering with the system directory or adding $libdir/fedora-ds to the ld.so default path, both of which could interfere with the other applications on the system that cannot use our private libdb. > >> So, I guess the scripts are a relic which made it so you didn't have to >> add those directories to LD_LIBRARY_PATH yourself. >> > > I agree it's a relic, I'm just asking that they be removed, at least on > Linux. > We still need the scripts on RHEL4, Solaris, and HPUX, unless we do some tricks with rpath. > Andrew Bartlett > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Fri Mar 2 18:08:35 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 02 Mar 2007 11:08:35 -0700 Subject: [Fedora-directory-devel] [PATCH] split schema for minimal DS startup (samba4) In-Reply-To: <1172825260.21804.122.camel@localhost.localdomain> References: <1172825260.21804.122.camel@localhost.localdomain> Message-ID: <45E86823.20005@redhat.com> Andrew Bartlett wrote: > I've split the 00core schema, into what we really require to start > Fedora DS, and rest. It is based on the work Satish earlier last year. > > The server starts, but without a 'make check' target, I can't verify > what I've broken. > > It does work for loading the Samba4 schema, and we now successfully > provision into the resultant directory. (it fails the tests miserably > however). > > Also, can someone let me know where to register the schema file into the > build and install system? > > Thanks, > > Andrew Bartlett > > ------------------------------------------------------------------------ > > --- /dev/null 2007-02-20 17:13:51.591965360 +1100 > +++ ldap/schema/01notsocore.ldif 2007-03-02 17:41:33.000000000 +1100 > @@ -0,0 +1,294 @@ > +# > +# BEGIN COPYRIGHT BLOCK > +# This Program is free software; you can redistribute it and/or modify it under > +# the terms of the GNU General Public License as published by the Free Software > +# Foundation; version 2 of the License. > +# > +# This Program is distributed in the hope that it will be useful, but WITHOUT > +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS > +# FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License along with > +# this Program; if not, write to the Free Software Foundation, Inc., 59 Temple > +# Place, Suite 330, Boston, MA 02111-1307 USA. > +# > +# In addition, as a special exception, Red Hat, Inc. gives You the additional > +# right to link the code of this Program with code not covered under the GNU > +# General Public License ("Non-GPL Code") and to distribute linked combinations > +# including the two, subject to the limitations in this paragraph. Non-GPL Code > +# permitted under this exception must only link to the code of this Program > +# through those well defined interfaces identified in the file named EXCEPTION > +# found in the source code files (the "Approved Interfaces"). The files of > +# Non-GPL Code may instantiate templates or use macros or inline functions from > +# the Approved Interfaces without causing the resulting work to be covered by > +# the GNU General Public License. Only Red Hat, Inc. may make changes or > +# additions to the list of Approved Interfaces. You must obey the GNU General > +# Public License in all respects for all of the Program code and other code used > +# in conjunction with the Program except the Non-GPL Code covered by this > +# exception. If you modify this file, you may extend this exception to your > +# version of the file, but you are not obligated to do so. If you do not wish to > +# provide this exception without modification, you must delete this exception > +# statement from your version and license this file solely under the GPL without > +# exception. > +# > +# > +# Copyright (C) 2001 Sun Microsystems, Inc. Used by permission. > +# Copyright (C) 2005 Red Hat, Inc. > +# All rights reserved. > +# END COPYRIGHT BLOCK > +# > +# > +# Core schema, highly recommended but not required to start the Directory Server itself. > +# > +dn: cn=schema > +# > +# attribute types: > +# > +attributeTypes: ( 2.5.4.0 NAME 'objectClass' DESC 'Standard LDAP attribute type' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 X-ORIGIN 'RFC 2256' ) > Really? I guess because we have some hardcoded stuff about objectClass in the directory server, since it is core to almost everything. Would you object if I moved this into the 00core.ldif, or do you need to replace the definition of objectClass? So what I will do is move all of these out of 00core.ldif (except for objectClass, above) and put them in 01othercore.ldif (or 01base or something like that). -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Fri Mar 2 20:44:09 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Sat, 03 Mar 2007 07:44:09 +1100 Subject: [Fedora-directory-devel] [PATCH] split schema for minimal DS startup (samba4) In-Reply-To: <45E86823.20005@redhat.com> References: <1172825260.21804.122.camel@localhost.localdomain> <45E86823.20005@redhat.com> Message-ID: <1172868249.21804.165.camel@localhost.localdomain> On Fri, 2007-03-02 at 11:08 -0700, Richard Megginson wrote: > > Andrew Bartlett wrote: > > I've split the 00core schema, into what we really require to start > > Fedora DS, and rest. It is based on the work Satish earlier last year. > > > > The server starts, but without a 'make check' target, I can't verify > > what I've broken. > > > > It does work for loading the Samba4 schema, and we now successfully > > provision into the resultant directory. (it fails the tests miserably > > however). > > > > Also, can someone let me know where to register the schema file into the > > build and install system? > > > > Thanks, > > > > Andrew Bartlett > > > > ------------------------------------------------------------------------ > > > > --- /dev/null 2007-02-20 17:13:51.591965360 +1100 > > +++ ldap/schema/01notsocore.ldif 2007-03-02 17:41:33.000000000 +1100 > > @@ -0,0 +1,294 @@ > > +# > > +# BEGIN COPYRIGHT BLOCK > > +# This Program is free software; you can redistribute it and/or modify it under > > +# the terms of the GNU General Public License as published by the Free Software > > +# Foundation; version 2 of the License. > > +# > > +# This Program is distributed in the hope that it will be useful, but WITHOUT > > +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS > > +# FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. > > +# > > +# You should have received a copy of the GNU General Public License along with > > +# this Program; if not, write to the Free Software Foundation, Inc., 59 Temple > > +# Place, Suite 330, Boston, MA 02111-1307 USA. > > +# > > +# In addition, as a special exception, Red Hat, Inc. gives You the additional > > +# right to link the code of this Program with code not covered under the GNU > > +# General Public License ("Non-GPL Code") and to distribute linked combinations > > +# including the two, subject to the limitations in this paragraph. Non-GPL Code > > +# permitted under this exception must only link to the code of this Program > > +# through those well defined interfaces identified in the file named EXCEPTION > > +# found in the source code files (the "Approved Interfaces"). The files of > > +# Non-GPL Code may instantiate templates or use macros or inline functions from > > +# the Approved Interfaces without causing the resulting work to be covered by > > +# the GNU General Public License. Only Red Hat, Inc. may make changes or > > +# additions to the list of Approved Interfaces. You must obey the GNU General > > +# Public License in all respects for all of the Program code and other code used > > +# in conjunction with the Program except the Non-GPL Code covered by this > > +# exception. If you modify this file, you may extend this exception to your > > +# version of the file, but you are not obligated to do so. If you do not wish to > > +# provide this exception without modification, you must delete this exception > > +# statement from your version and license this file solely under the GPL without > > +# exception. > > +# > > +# > > +# Copyright (C) 2001 Sun Microsystems, Inc. Used by permission. > > +# Copyright (C) 2005 Red Hat, Inc. > > +# All rights reserved. > > +# END COPYRIGHT BLOCK > > +# > > +# > > +# Core schema, highly recommended but not required to start the Directory Server itself. > > +# > > +dn: cn=schema > > +# > > +# attribute types: > > +# > > +attributeTypes: ( 2.5.4.0 NAME 'objectClass' DESC 'Standard LDAP attribute type' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 X-ORIGIN 'RFC 2256' ) > > > Really? I guess because we have some hardcoded stuff about objectClass > in the directory server, since it is core to almost everything. Would > you object if I moved this into the 00core.ldif, or do you need to > replace the definition of objectClass? Yeah, that shouldn't be a problem... > So what I will do is move all of these out of 00core.ldif (except for > objectClass, above) and put them in 01othercore.ldif (or 01base or > something like that). Yeah, that's what that patch should do. Thanks! Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nhosoi at redhat.com Fri Mar 2 21:56:06 2007 From: nhosoi at redhat.com (Noriko Hosoi) Date: Fri, 02 Mar 2007 13:56:06 -0800 Subject: [Fedora-directory-devel] Please review: [Bug 230673] LDAPI: referral mode needs LDAPI socket? In-Reply-To: <200703022138.l22Lc3Sp023250@bugzilla.redhat.com> References: <200703022138.l22Lc3Sp023250@bugzilla.redhat.com> Message-ID: <45E89D76.6030809@redhat.com> Summary: LDAPI: referral mode needs LDAPI socket? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230673 This changes make LDAPI turned "off" if ldapifilepath is not set in the install inf file. Sorry, I should have done the discussion on bugzilla from the beginning. It's going to be a repeat, but for the record, if you could review the changes and comment on the bug, I'd appreciate it. --noriko nhosoi at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- devel_whiteboard| |review.comment#3? Record of the email discussion: ------- Additional Comments From nhosoi at redhat.com 2007-03-02 16:38 EST ------- (In reply to comment #0) > > Description of problem: > > [error #2] > > [...] > > Also, to work around this problem, is it okay to add this code to > create the > > directory to put the ldapi unix socket if it does not exist? Richard Megginson wrote: I don't think we should create the directory if it does not exist. That doesn't seem right to me. I think we should just warn. Pete Rowley wrote: > > You know, given our server installs with newinst.pl in regular cases > and all this has > > default config set up for directories we already write to, perhaps > the right thing to do > > is to have default off for ldapi. That would have minimum impact on > tests that don't > > care about it (and are set up other ways) and wouldn't effect server > installs through > > regular means. Richard Megginson wrote: Then ds_newinst could set it to "on" if the user specified an ldapifilepath. I think that would appease Andrew as well. Based upon the suggestions from Pete and Rich, if setting "ldapifilepath=/path/to/ldapifile/slapd-ID.socket" in the install inf file is used as a trigger to set ldapi to "on". Otherwise, set to "off". The function ds_gen_confs in create_instance.c switches between on and off depending upon the existence of ldapifilepath value. Also, the ldapi default setting in libglobs.c is changed to "off". ------- Additional Comments From nhosoi at redhat.com 2007-03-02 16:43 EST ------- Created an attachment (id=149157) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=149157&action=view) cvs diffs (admin/src/create_instance.c, servers/slapd/libglobs.c) Changes: create_instance.c: if ldapifilepath is not passed, LDAPI is disabled in the newly created instance. libglobs.c: LDAPI is disabled in the initial configuration parameter setting. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From prowley at redhat.com Fri Mar 2 23:36:14 2007 From: prowley at redhat.com (Pete Rowley) Date: Fri, 02 Mar 2007 15:36:14 -0800 Subject: [Fedora-directory-devel] Please review: [Bug 230673] LDAPI: referral mode needs LDAPI socket? In-Reply-To: <45E89D76.6030809@redhat.com> References: <200703022138.l22Lc3Sp023250@bugzilla.redhat.com> <45E89D76.6030809@redhat.com> Message-ID: <45E8B4EE.30100@redhat.com> Looks good. Noriko Hosoi wrote: > Summary: LDAPI: referral mode needs LDAPI socket? > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230673 > > This changes make LDAPI turned "off" if ldapifilepath is not set in > the install inf file. > > Sorry, I should have done the discussion on bugzilla from the > beginning. It's going to be a repeat, but for the record, if you > could review the changes and comment on the bug, I'd appreciate it. > --noriko > > nhosoi at redhat.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > > devel_whiteboard| |review.comment#3? > > Record of the email discussion: > ------- Additional Comments From nhosoi at redhat.com 2007-03-02 16:38 > EST ------- > (In reply to comment #0) >> > Description of problem: >> > [error #2] >> > [...] >> > Also, to work around this problem, is it okay to add this code to >> create the >> > directory to put the ldapi unix socket if it does not exist? > Richard Megginson wrote: > I don't think we should create the directory if it does not exist. > That doesn't seem right to me. I think we should just warn. > > Pete Rowley wrote: >> > You know, given our server installs with newinst.pl in regular >> cases and all this has >> > default config set up for directories we already write to, perhaps >> the right thing to do >> > is to have default off for ldapi. That would have minimum impact on >> tests that don't >> > care about it (and are set up other ways) and wouldn't effect >> server installs through >> > regular means. > Richard Megginson wrote: > Then ds_newinst could set it to "on" if the user specified an > ldapifilepath. I think that would appease Andrew as well. > > Based upon the suggestions from Pete and Rich, if setting > "ldapifilepath=/path/to/ldapifile/slapd-ID.socket" in the install inf > file is used as a trigger to set ldapi to "on". Otherwise, set to > "off". The function ds_gen_confs in create_instance.c switches between > on and off depending upon the existence of ldapifilepath value. Also, > the ldapi default setting in libglobs.c is changed to "off". > > ------- Additional Comments From nhosoi at redhat.com 2007-03-02 16:43 > EST ------- > Created an attachment (id=149157) > --> > (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=149157&action=view) > > cvs diffs (admin/src/create_instance.c, servers/slapd/libglobs.c) > > Changes: > create_instance.c: if ldapifilepath is not passed, LDAPI is disabled > in the > newly created instance. > libglobs.c: LDAPI is disabled in the initial configuration parameter > setting. > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -- Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Fri Mar 2 23:57:17 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 02 Mar 2007 16:57:17 -0700 Subject: [Fedora-directory-devel] Please review: Bug 230808: Split core schema Message-ID: <45E8B9DD.5070404@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230808 Resolves: bug 230808 Bug Description: Split core schema Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Moved all schema not required to start the server from 00core.ldif into a new file called 01common.ldif. Andrew and Satish already did the work to determine which schema are required to start the server, which is the schema needed to be in 00core.ldif. Platforms tested: RHEL4 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=149163&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Sat Mar 3 00:06:02 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 02 Mar 2007 17:06:02 -0700 Subject: [Fedora-directory-devel] Redux: Please review: Bug 230808: Split core schema Message-ID: <45E8BBEA.504@redhat.com> Sorry, wrong diffs on last message. New diffs below. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230808 Resolves: bug 230808 Bug Description: Split core schema Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: Moved all schema not required to start the server from 00core.ldif into a new file called 01common.ldif. Andrew and Satish already did the work to determine which schema are required to start the server, which is the schema needed to be in 00core.ldif. Platforms tested: RHEL4 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=149164&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From prowley at redhat.com Sat Mar 3 00:12:58 2007 From: prowley at redhat.com (Pete Rowley) Date: Fri, 02 Mar 2007 16:12:58 -0800 Subject: [Fedora-directory-devel] Redux: Please review: Bug 230808: Split core schema In-Reply-To: <45E8BBEA.504@redhat.com> References: <45E8BBEA.504@redhat.com> Message-ID: <45E8BD8A.1070807@redhat.com> ok Richard Megginson wrote: > Sorry, wrong diffs on last message. New diffs below. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230808 > Resolves: bug 230808 > Bug Description: Split core schema > Reviewed by: ??? > Files: see diff > Branch: HEAD > Fix Description: Moved all schema not required to start the server from > 00core.ldif into a new file called 01common.ldif. Andrew and Satish > already did the work to determine which schema are required to start the > server, which is the schema needed to be in 00core.ldif. > Platforms tested: RHEL4 > Flag Day: no > Doc impact: no > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=149164&action=diff > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -- Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From eswars at huawei.com Mon Mar 5 11:54:17 2007 From: eswars at huawei.com (Eswar S) Date: Mon, 05 Mar 2007 17:24:17 +0530 Subject: [Fedora-directory-devel] How to configure new Backend database In-Reply-To: <20070303170024.8167F73270@hormel.redhat.com> Message-ID: <000001c75f1d$018210e0$0c12120a@china.huawei.com> Hi I have configured my fedora LDAP with LDBM (as Default Installation) on Red Hat machine. If I wanted to change my backed database. How can I change? Means how can I change to msSql /oracle/BDB.......... I observed that we need to add an entry under config tree of Fedora-ds with plug-in xxxx.so file with initialize function name. But for other database what is that xxxxxxx.so file and corresponding Function name?? I am posting same second time ...... Please help me to configure fedora-ds 7.1 ldap. Regards, Eswar S **************************************************************************** **************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! From rmeggins at redhat.com Mon Mar 5 15:39:45 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 05 Mar 2007 08:39:45 -0700 Subject: [Fedora-directory-devel] How to configure new Backend database In-Reply-To: <000001c75f1d$018210e0$0c12120a@china.huawei.com> References: <000001c75f1d$018210e0$0c12120a@china.huawei.com> Message-ID: <45EC39C1.2050306@redhat.com> Eswar S wrote: > Hi > I have configured my fedora LDAP with LDBM (as Default Installation) on Red > Hat machine. If I wanted to change my backed database. How can I change? > Means how can I change to msSql /oracle/BDB.......... > http://directory.fedora.redhat.com/wiki/FAQ#Can_I_replace_Sleepycat_with_Oracle.2C_or_Postgres.2C_etc..3F > I observed that we need to add an entry under config tree of Fedora-ds > with plug-in xxxx.so file with initialize function name. > But for other database what is that xxxxxxx.so file and corresponding > Function name?? > > I am posting same second time ...... > Please help me to configure fedora-ds 7.1 ldap. > > Regards, > Eswar S > > > **************************************************************************** > **************************** > This e-mail and attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed > above. Any use of the information contained herein in any way (including, > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please notify the sender by > phone or email immediately and delete it! > > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Tue Mar 6 02:49:46 2007 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 05 Mar 2007 18:49:46 -0800 Subject: [Fedora-directory-devel] Please review: [Bug 231093] db2bak: crash bug In-Reply-To: <200703060245.l262jH9O015796@bugzilla.redhat.com> References: <200703060245.l262jH9O015796@bugzilla.redhat.com> Message-ID: <45ECD6CA.1090909@redhat.com> Summary: db2bak: crash bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231093 Description of problem: db2bak crashed in one of the failed test cases. Caused by the initial configuration error: errors:[...] - Db home directory is not set. Possibly nsslapd-directory (optinally nsslapd-db-home-directory) is missing in the config file. Still, the server should not crash. [stacktrace] #0 0xb6edd2c7 in dblayer_get_full_inst_dir (li=0x8127350, inst=0x8187f00, buf=0xbfffc480 "", buflen=4096) at ldap/servers/slapd/back-ldbm/dblayer.c:1209 #1 0xb6ee4d42 in dblayer_in_import (inst=0x8187f00) at ldap/servers/slapd/back-ldbm/dblayer.c:5623 #2 0xb6ed8bd0 in ldbm_back_ldbm2archive (pb=0xbfffd570) at ldap/servers/slapd/back-ldbm/archive.c:353 #3 0x0805d59e in slapd_exemode_db2archive () at ldap/servers/slapd/main.c:2457 #4 0x0805e5e7 in main (argc=6, argv=0xbfffdca4) at ldap/servers/slapd/main.c:947 ------- Additional Comments From nhosoi at redhat.com 2007-03-05 21:45 EST ------- Created an attachment (id=149315) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=149315&action=view) cvs diff dblayer.c File: ldap/servers/slapd/back-ldbm/dblayer.c Problem description: The server instance home directory in the dblayer private structure (li->li_dblayer_private) is empty. Either of these fields is supposed to be set: dblayer_home_directory = 0x0 dblayer_dbhome_directory = 0x8125ba0 "" Fix descrption: if the fields are not set, issues an error message and returns. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From eswars at huawei.com Wed Mar 7 09:02:28 2007 From: eswars at huawei.com (Eswar S) Date: Wed, 07 Mar 2007 14:32:28 +0530 Subject: [Fedora-directory-devel] How to configure new Backend In-Reply-To: <20070305170027.70B1F73358@hormel.redhat.com> Message-ID: <002501c76097$559ded90$0c12120a@china.huawei.com> Thank you for Replay. As per FAQ I need to write my own plug-in for storing ldap entries into mssql/oracle database. I have seen slapi to write Server plug-in and examples provided at /opt/fedora-ds/plugins/slapd/slapi/examples. But I am not finding sample code for writing plug-in for Backend databases. Is there any sample code for writing plug-in for backend database? I am referring this link to write plug-in. http://www.redhat.com/docs/manuals/dir-server/plugin/7.1/pluginTOC.html Thank you Eswar S **************************************************************************** **************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! Date: Mon, 05 Mar 2007 08:39:45 -0700 From: Richard Megginson Subject: Re: [Fedora-directory-devel] How to configure new Backend database To: "Fedora Directory server developer discussion." Message-ID: <45EC39C1.2050306 at redhat.com> Content-Type: text/plain; charset="iso-8859-1" Eswar S wrote: > Hi > I have configured my fedora LDAP with LDBM (as Default Installation) on Red > Hat machine. If I wanted to change my backed database. How can I change? > Means how can I change to msSql /oracle/BDB.......... > http://directory.fedora.redhat.com/wiki/FAQ#Can_I_replace_Sleepycat_with_Ora cle.2C_or_Postgres.2C_etc..3F > I observed that we need to add an entry under config tree of Fedora-ds > with plug-in xxxx.so file with initialize function name. > But for other database what is that xxxxxxx.so file and corresponding > Function name?? > > I am posting same second time ...... > Please help me to configure fedora-ds 7.1 ldap. > > Regards, > Eswar S > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature Url : https://www.redhat.com/archives/fedora-directory-devel/attachments/20070305/ 15a75bc4/smime.bin ------------------------------ -- Fedora-directory-devel mailing list Fedora-directory-devel at redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-devel End of Fedora-directory-devel Digest, Vol 21, Issue 5 ***************************************************** From rmeggins at redhat.com Wed Mar 7 14:53:19 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Wed, 07 Mar 2007 07:53:19 -0700 Subject: [Fedora-directory-devel] How to configure new Backend In-Reply-To: <002501c76097$559ded90$0c12120a@china.huawei.com> References: <002501c76097$559ded90$0c12120a@china.huawei.com> Message-ID: <45EED1DF.6030307@redhat.com> Eswar S wrote: > Thank you for Replay. As per FAQ I need to write my own plug-in for storing > ldap entries into mssql/oracle database. > I have seen slapi to write Server plug-in and examples provided at > /opt/fedora-ds/plugins/slapd/slapi/examples. But I am not finding sample > code for writing plug-in for Backend databases. > Is there any sample code for writing plug-in for backend database? > I would suggest starting here - http://directory.fedora.redhat.com/wiki/Plugins For a pure backend database plugin, your best bet would be to start with the source code for the chaining database (which is an LDAP backend). http://cvs.fedora.redhat.com/viewcvs/ldapserver/ldap/servers/plugins/chainingdb/?root=dirsec However, for your purposes, you might find it easier to write a data interoperability plugin. We had a Netscape customer who did this very same thing - write a data interop plugin which put an LDAP frontend on their Oracle backend database (really just a simple LDAP<->SQL converter) - and, in case you were wondering, no, the code is proprietary to that particular customer (this was a few years ago). There are some examples for data interop here - http://cvs.fedora.redhat.com/viewcvs/ldapserver/ldap/servers/slapd/test-plugins/?root=dirsec > I am referring this link to write plug-in. > http://www.redhat.com/docs/manuals/dir-server/plugin/7.1/pluginTOC.html > > Thank you > Eswar S > **************************************************************************** > **************************** > This e-mail and attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed > above. Any use of the information contained herein in any way (including, > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please notify the sender by > phone or email immediately and delete it! > > Date: Mon, 05 Mar 2007 08:39:45 -0700 > From: Richard Megginson > Subject: Re: [Fedora-directory-devel] How to configure new Backend > database > To: "Fedora Directory server developer discussion." > > Message-ID: <45EC39C1.2050306 at redhat.com> > Content-Type: text/plain; charset="iso-8859-1" > > Eswar S wrote: > >> Hi >> I have configured my fedora LDAP with LDBM (as Default Installation) on >> > Red > >> Hat machine. If I wanted to change my backed database. How can I change? >> Means how can I change to msSql /oracle/BDB.......... >> >> > http://directory.fedora.redhat.com/wiki/FAQ#Can_I_replace_Sleepycat_with_Ora > cle.2C_or_Postgres.2C_etc..3F > >> I observed that we need to add an entry under config tree of Fedora-ds >> with plug-in xxxx.so file with initialize function name. >> But for other database what is that xxxxxxx.so file and corresponding >> Function name?? >> >> I am posting same second time ...... >> Please help me to configure fedora-ds 7.1 ldap. >> >> Regards, >> Eswar S >> -- >> Fedora-directory-devel mailing list >> Fedora-directory-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> >> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/x-pkcs7-signature > Size: 3245 bytes > Desc: S/MIME Cryptographic Signature > Url : > https://www.redhat.com/archives/fedora-directory-devel/attachments/20070305/ > 15a75bc4/smime.bin > > ------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > > > End of Fedora-directory-devel Digest, Vol 21, Issue 5 > ***************************************************** > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From hyc at symas.com Wed Mar 7 17:20:41 2007 From: hyc at symas.com (Howard Chu) Date: Wed, 07 Mar 2007 09:20:41 -0800 Subject: [Fedora-directory-devel] How to configure new Backend In-Reply-To: <20070307170028.4993A738AC@hormel.redhat.com> References: <20070307170028.4993A738AC@hormel.redhat.com> Message-ID: <45EEF469.2030305@symas.com> > Date: Wed, 07 Mar 2007 14:32:28 +0530 > From: Eswar S > Thank you for Replay. As per FAQ I need to write my own plug-in for storing > ldap entries into mssql/oracle database. > I have seen slapi to write Server plug-in and examples provided at > /opt/fedora-ds/plugins/slapd/slapi/examples. But I am not finding sample > code for writing plug-in for Backend databases. > Is there any sample code for writing plug-in for backend database? > > I am referring this link to write plug-in. > http://www.redhat.com/docs/manuals/dir-server/plugin/7.1/pluginTOC.html > > Thank you > Eswar S You could just use OpenLDAP, which already provides a back-sql backend... In any case, using SQL as a backing store for LDAP is a couple orders of magnitude slower than using the native LDAP databases. Taking this approach is OK when you need access to existing SQL data and have no other choice. If you're just creating a new database, it's best to avoid SQL entirely. In the case of OpenLDAP, using the proxycache overlay in combination with the back-sql backend will improve search performance. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/ From abartlet at samba.org Sat Mar 10 09:36:41 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Sat, 10 Mar 2007 20:36:41 +1100 Subject: [Fedora-directory-devel] Support for bitwise operations? Message-ID: <1173519402.3506.102.camel@localhost.localdomain> It seems to me that Fedora DS does not support Microsoft's extended match bitwise operations. I chatted with Pete about it on IRC, but thought to document it here for discussion. While it would be technically possible for me to filter these on the client side, it becomes silly fast. I need the LDAP backend side to handle these. This is the kind of search Fedora DS needs to accept, for Samba4 to use it as a backend: (|(&(!(groupType:1.2.840.113556.1.4.803:=1))(groupType:1.2.840.113556.1.4.803:=2147483648)(groupType:1.2.840.113556.1.4.804:=10)) Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From abartlet at samba.org Sun Mar 11 00:14:43 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Sun, 11 Mar 2007 11:14:43 +1100 Subject: [Fedora-directory-devel] Re: RPATH status In-Reply-To: <45F1CE12.1000708@redhat.com> References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> Message-ID: <1173572083.3506.111.camel@localhost.localdomain> On Fri, 2007-03-09 at 13:13 -0800, Ulrich Drepper wrote: > Christopher Aillon wrote: > >> 3 /usr/lib64/firefox-2.0.0.2 > > > > Some of them are intentional, such as the above. It's either rpath or > > munging LD_LIBRARY_PATH at startup if you want a working firefox. > > RPATH is perfectly fine for these purposes. Do we have a preference against wrapper scripts for munging LD_LIBRARY_PATH (I think we should)? The reason I ask is that I've been looking at the Fedora DS situation (now a package in extras), where every binary is wrapped in a shell script to munge the LD_LIBRARY_PATH, which just seems wrong to me. Likewise, where should a package place 'internal only' libraries, such as libslapd for Fedora DS, and some similar libraries in an eventual Samba4 package (to avoid bloat by static linking shared internal functionality)? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david_list at boreham.org Sun Mar 11 02:06:18 2007 From: david_list at boreham.org (David Boreham) Date: Sat, 10 Mar 2007 19:06:18 -0700 Subject: [Fedora-directory-devel] Re: RPATH status In-Reply-To: <1173572083.3506.111.camel@localhost.localdomain> References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> <1173572083.3506.111.camel@localhost.localdomain> Message-ID: <45F3641A.9030501@boreham.org> Some more info on this: FDS was designed to install at an arbitrary subdirectory in the filesystem. rpath only supports absolute paths and paths relative to the current working directory, not the location of the binary (some platforms have some support for rpath relative to the main binary location but at the time this was last looked at seriously, that support was spotty and incomplete). And so we have wrappers. They allow a user to add one directory to their path and run any FDS command without regard to setting LD_LIBRARY_PATH. To remove the wrappers you'd need to give up something : install at a fixed location (and use absolute rpaths); don't give users the convenience of running commands without setting LD_LIBRARY_PATH themselves; only run on platforms that have support for relative-to-binary rpath. Andrew Bartlett wrote: >On Fri, 2007-03-09 at 13:13 -0800, Ulrich Drepper wrote: > > >>Christopher Aillon wrote: >> >> >>>> 3 /usr/lib64/firefox-2.0.0.2 >>>> >>>> >>>Some of them are intentional, such as the above. It's either rpath or >>>munging LD_LIBRARY_PATH at startup if you want a working firefox. >>> >>> >>RPATH is perfectly fine for these purposes. >> >> > >Do we have a preference against wrapper scripts for munging >LD_LIBRARY_PATH (I think we should)? > >The reason I ask is that I've been looking at the Fedora DS situation >(now a package in extras), where every binary is wrapped in a shell >script to munge the LD_LIBRARY_PATH, which just seems wrong to me. > >Likewise, where should a package place 'internal only' libraries, such >as libslapd for Fedora DS, and some similar libraries in an eventual >Samba4 package (to avoid bloat by static linking shared internal >functionality)? > >Andrew Bartlett > > > >------------------------------------------------------------------------ > >-- >Fedora-directory-devel mailing list >Fedora-directory-devel at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-directory-devel > > From abartlet at samba.org Sun Mar 11 23:51:52 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Mon, 12 Mar 2007 10:51:52 +1100 Subject: [Fedora-directory-devel] CVS commits list? Message-ID: <1173657112.3506.128.camel@localhost.localdomain> I appreciate the efforts that the Fedora DS team has made to post many patches via Bugzilla for review, but I'm often still in the dark as to when particular fixes hit the tree. Is there any chance we can get a cvs commits mailing list? Or is there one, and I just don't know about it? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From abartlet at samba.org Sun Mar 11 23:59:19 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Mon, 12 Mar 2007 10:59:19 +1100 Subject: [Fedora-directory-devel] Why is there a Makefile in CVS? Message-ID: <1173657559.3506.133.camel@localhost.localdomain> Why is there a Makefile (not Makefile.in) in CVS? Isn't the first thing we want to do (on a checkout) a ./configure, which will replace this file anyway? Likewise, I'm confused: why do we allow prefix and exec_prefix to be specified at 'make' (rather than configure) time? This is typically at configure time in other open source projects. Changing this would seem to remove some additional complexity from the build system... Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david_list at boreham.org Mon Mar 12 00:51:36 2007 From: david_list at boreham.org (David Boreham) Date: Sun, 11 Mar 2007 18:51:36 -0600 Subject: [Fedora-directory-devel] CVS commits list? In-Reply-To: <1173657112.3506.128.camel@localhost.localdomain> References: <1173657112.3506.128.camel@localhost.localdomain> Message-ID: <45F4A418.5060100@boreham.org> fedora-directory-commits at redhat.com From abartlet at samba.org Mon Mar 12 01:54:40 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Mon, 12 Mar 2007 12:54:40 +1100 Subject: [Fedora-directory-devel] CVS commits list? In-Reply-To: <45F4A418.5060100@boreham.org> References: <1173657112.3506.128.camel@localhost.localdomain> <45F4A418.5060100@boreham.org> Message-ID: <1173664480.3506.145.camel@localhost.localdomain> On Sun, 2007-03-11 at 18:51 -0600, David Boreham wrote: > fedora-directory-commits at redhat.com Thanks! -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rmeggins at redhat.com Mon Mar 12 12:20:03 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 12 Mar 2007 06:20:03 -0600 Subject: [Fedora-directory-devel] Why is there a Makefile in CVS? In-Reply-To: <1173657559.3506.133.camel@localhost.localdomain> References: <1173657559.3506.133.camel@localhost.localdomain> Message-ID: <45F54573.6020305@redhat.com> Andrew Bartlett wrote: > Why is there a Makefile (not Makefile.in) in CVS? > Makefile is there for historical reasons and will be removed asap. > Isn't the first thing we want to do (on a checkout) a ./configure, which > will replace this file anyway? > > Likewise, I'm confused: why do we allow prefix and exec_prefix to be > specified at 'make' (rather than configure) time? You can set them at configure time. I use "configure --prefix=/home/rich/11srv && make install" for testing. > This is typically at > configure time in other open source projects. Actually, it is a "feature" of autoconf/automake to allow you to set them at make time, in addition to being able to set them at configure time. It is my understanding that autoconf/automake work fine, no matter if you set them at configure or make time. From "info autoconf": "Most of these variables have values that rely on `prefix' or `exec_prefix'. It is deliberate that the directory output variables keep them unexpanded: typically `@datadir@' will be replaced by `${prefix}/share', not `/usr/local/share'. This behavior is mandated by the GNU coding standards, so that when the user runs: `make' she can still specify a different prefix from the one specified to `configure', in which case, if needed, the package shall hard code dependencies corresponding to the make-specified prefix. `make install' she can specify a different installation location, in which case the package _must_ still depend on the location which was compiled in (i.e., never recompile when `make install' is run). This is an extremely important feature, as many people may decide to install all the files of a package grouped together, and then install links from the final locations to there. ... " There is more in the autoconf info doc about this too. > Changing this would seem > to remove some additional complexity from the build system... > What additional complexity is introduced? > Andrew Bartlett > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Mar 12 12:30:50 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 12 Mar 2007 06:30:50 -0600 Subject: [Fedora-directory-devel] Re: RPATH status In-Reply-To: <45F3641A.9030501@boreham.org> References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> <1173572083.3506.111.camel@localhost.localdomain> <45F3641A.9030501@boreham.org> Message-ID: <45F547FA.4050602@redhat.com> David Boreham wrote: > > Some more info on this: > > FDS was designed to install at an arbitrary subdirectory in the > filesystem. > rpath only supports absolute paths and paths relative to the current > working > directory, not the location of the binary (some platforms have some > support > for rpath relative to the main binary location but at the time this > was last > looked at seriously, that support was spotty and incomplete). > And so we have wrappers. They allow a user to add one directory > to their path and run any FDS command without regard to setting > LD_LIBRARY_PATH. > > To remove the wrappers you'd need to give up something : > install at a fixed location (and use absolute rpaths); don't give > users the convenience of running commands without setting > LD_LIBRARY_PATH themselves; only run on platforms > that have support for relative-to-binary rpath. We're using the first option on Fedora. We install all of the libraries in system locations, so there is no need to set rpath or have wrapper scripts for the command line programs. The only one in question is libslapd.so, and we could put that in the system $_libdir, or some other directory that is "approved" by the FHS. We were planning to get rid of the wrapper scripts sooner or later on Fedora. Does this have to be sooner? Are the wrapper scripts causing some problem (other than an aesthetic one)? We require the use of wrapper scripts on almost every other platform, including RHEL4 - and, AFAIK, on other linux distros that put the NSPR and NSS bundled with the Mozilla clients in the system _libdir. Fedora solved this problem by making NSPR and NSS independent of Mozilla. > > > Andrew Bartlett wrote: > >> On Fri, 2007-03-09 at 13:13 -0800, Ulrich Drepper wrote: >> >> >>> Christopher Aillon wrote: >>> >>>>> 3 /usr/lib64/firefox-2.0.0.2 >>>>> >>>> Some of them are intentional, such as the above. It's either rpath or >>>> munging LD_LIBRARY_PATH at startup if you want a working firefox. >>>> >>> RPATH is perfectly fine for these purposes. >>> >> >> Do we have a preference against wrapper scripts for munging >> LD_LIBRARY_PATH (I think we should)? >> The reason I ask is that I've been looking at the Fedora DS situation >> (now a package in extras), where every binary is wrapped in a shell >> script to munge the LD_LIBRARY_PATH, which just seems wrong to me. >> Likewise, where should a package place 'internal only' libraries, such >> as libslapd for Fedora DS, and some similar libraries in an eventual >> Samba4 package (to avoid bloat by static linking shared internal >> functionality)? >> >> Andrew Bartlett >> >> >> >> ------------------------------------------------------------------------ >> >> -- >> Fedora-directory-devel mailing list >> Fedora-directory-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> >> > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From abo at kth.se Sun Mar 11 09:56:43 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sun, 11 Mar 2007 10:56:43 +0100 Subject: [Fedora-directory-devel] Re: RPATH status In-Reply-To: <1173572083.3506.111.camel@localhost.localdomain> References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> <1173572083.3506.111.camel@localhost.localdomain> Message-ID: <1173607004.3816.18.camel@home.alexander.bostrom.net> s?n 2007-03-11 klockan 11:14 +1100 skrev Andrew Bartlett: > The reason I ask is that I've been looking at the Fedora DS situation > (now a package in extras), where every binary is wrapped in a shell > script to munge the LD_LIBRARY_PATH, which just seems wrong to me. Yeah, it would be better to use RPATH. If a process needs LD_LIBRARY_PATH set, but spawns other processes that do not need it, it's asking for trouble. (For example, a web browser that starts a PDF reader.) /abo From prowley at redhat.com Mon Mar 12 20:36:16 2007 From: prowley at redhat.com (Pete Rowley) Date: Mon, 12 Mar 2007 13:36:16 -0700 Subject: [Fedora-directory-devel] Support for bitwise operations? In-Reply-To: <1173519402.3506.102.camel@localhost.localdomain> References: <1173519402.3506.102.camel@localhost.localdomain> Message-ID: <45F5B9C0.2020002@redhat.com> Andrew Bartlett wrote: > It seems to me that Fedora DS does not support Microsoft's extended > match bitwise operations. > > I chatted with Pete about it on IRC, but thought to document it here for > discussion. While it would be technically possible for me to filter > these on the client side, it becomes silly fast. I need the LDAP > backend side to handle these. > > This is the kind of search Fedora DS needs to accept, for Samba4 to use > it as a backend: > (|(&(!(groupType:1.2.840.113556.1.4.803:=1))(groupType:1.2.840.113556.1.4.803:=2147483648)(groupType:1.2.840.113556.1.4.804:=10)) > > Basic question: why are you storing bit fields in the first place? Why not store the information in a more readily accessible fashion, both to your code, and the administrator of the system? As you noted, the bitwise extensible matches are Microsoft extensions and they have not been specified in any RFC or IETF draft document AFAIK. Consequently you should not expect the functionality to be generally available in LDAP directory servers. -- Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Mar 12 21:59:01 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 12 Mar 2007 15:59:01 -0600 Subject: [Fedora-directory-devel] Please review: migration: Migrate from 1.0.x to 1.1 Message-ID: <45F5CD25.6070004@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231905 Resolves: bug 145179 Bug Description: description Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: I added a new migration script called migrateTo11. This will, by default, copy all instance configuration from the old /opt/fedora-ds location to the new FHS locations. The migratecred command line tool needed to be upgraded to deal with FHS style paths. The first link below are the diffs to existing code. The second is the new proposed .in file. The third is what the script will look like installed in the file system. Platforms tested: RHEL4, FC6 Flag Day: no Doc impact: Yes - will need to document migration on the wiki https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=149871&action=diff https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=149872 https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=149873 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Tue Mar 13 01:24:57 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 13 Mar 2007 12:24:57 +1100 Subject: [Fedora-directory-devel] Support for bitwise operations? In-Reply-To: <45F5B9C0.2020002@redhat.com> References: <1173519402.3506.102.camel@localhost.localdomain> <45F5B9C0.2020002@redhat.com> Message-ID: <1173749097.3229.14.camel@localhost.localdomain> On Mon, 2007-03-12 at 13:36 -0700, Pete Rowley wrote: > Andrew Bartlett wrote: > > It seems to me that Fedora DS does not support Microsoft's extended > > match bitwise operations. > > > > I chatted with Pete about it on IRC, but thought to document it here for > > discussion. While it would be technically possible for me to filter > > these on the client side, it becomes silly fast. I need the LDAP > > backend side to handle these. > > > > This is the kind of search Fedora DS needs to accept, for Samba4 to use > > it as a backend: > > (|(&(!(groupType:1.2.840.113556.1.4.803:=1))(groupType:1.2.840.113556.1.4.803:=2147483648)(groupType:1.2.840.113556.1.4.804:=10)) > > > > > Basic question: why are you storing bit fields in the first place? Why > not store the information in a more readily accessible fashion, both to > your code, and the administrator of the system? As you noted, the > bitwise extensible matches are Microsoft extensions and they have not > been specified in any RFC or IETF draft document AFAIK. Consequently > you should not expect the functionality to be generally available in > LDAP directory servers. As we discussed on the phone, I wasn't aware this was a particularly difficult extension to implement, and was hoping I could rely on this functionality here. Having this search operator available in the server would be very useful, as it would allow these searches to proceed to the server relatively unmolested by our mapping layer. These queries come from our clients (such as Windows, expecting to talk to AD), over LDAP, as well as potentially internally to Samba4. I am concerned that filtering these values on the client side, while possible, would produce excessive network traffic. I'll be working over the next couple of days on a list of the requirements that I know Samba4 will have for it's backend server, and some speculation for areas we may encounter in future. It should appear at http://wiki.samba.org/index.php/Samba4/LDAP_Backend Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lmth at deakin.edu.au Tue Mar 13 03:43:41 2007 From: lmth at deakin.edu.au (lmth at deakin.edu.au) Date: Tue, 13 Mar 2007 14:43:41 +1100 Subject: [Fedora-directory-devel] A request for your input. Message-ID: <20070313144341.ch5bjn700ow0g44o@mail.deakin.edu.au> Hello My name is Lara Thynne and I am a PhD candidate at Deakin University Australia. I am currently researching the boundary between work and leisure activities directly related to the open source community and open source program development. As part of this I am running a survey at the following address. https://dcarf.deakin.edu.au/surveys/oss/ The survey is completely confidential and looks at your views and motivations to use Open Source software and to participate in the community. It will only take a five to ten minutes to complete and your contact details will not be recorded. You can withdraw your participation at any stage. I sincerely apologize for the spammish nature of this e-mail - I don't mean to abuse this list. I am trying to collect responses from as many open source developers and users as possible and a mailing list like can be the only way to reach many developers. Thanks again Lara P.S The program that I am using is open source, of course (www.phpsurveyor.org)! From abartlet at samba.org Tue Mar 13 04:17:09 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 13 Mar 2007 15:17:09 +1100 Subject: [Fedora-directory-devel] Re: RPATH status In-Reply-To: <45F547FA.4050602@redhat.com> References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> <1173572083.3506.111.camel@localhost.localdomain> <45F3641A.9030501@boreham.org> <45F547FA.4050602@redhat.com> Message-ID: <1173759429.28440.5.camel@localhost.localdomain> On Mon, 2007-03-12 at 06:30 -0600, Richard Megginson wrote: > David Boreham wrote: > > > > Some more info on this: > > > > FDS was designed to install at an arbitrary subdirectory in the > > filesystem. > > rpath only supports absolute paths and paths relative to the current > > working > > directory, not the location of the binary (some platforms have some > > support > > for rpath relative to the main binary location but at the time this > > was last > > looked at seriously, that support was spotty and incomplete). > > And so we have wrappers. They allow a user to add one directory > > to their path and run any FDS command without regard to setting > > LD_LIBRARY_PATH. > > > > To remove the wrappers you'd need to give up something : > > install at a fixed location (and use absolute rpaths); don't give > > users the convenience of running commands without setting > > LD_LIBRARY_PATH themselves; only run on platforms > > that have support for relative-to-binary rpath. > We're using the first option on Fedora. We install all of the libraries > in system locations, so there is no need to set rpath or have wrapper > scripts for the command line programs. The only one in question is > libslapd.so, and we could put that in the system $_libdir, or some other > directory that is "approved" by the FHS. Yeah, that seems very out of place in $_libdir > We were planning to get rid of > the wrapper scripts sooner or later on Fedora. Does this have to be > sooner? Are the wrapper scripts causing some problem (other than an > aesthetic one)? Not in particular, but an interesting point was made on the fedora-devel list: If the 'wrapped' binary forks a child, then that unrelated child also inherits the environment, which may not be desired. > We require the use of wrapper scripts on almost every other platform, > including RHEL4 - and, AFAIK, on other linux distros that put the NSPR > and NSS bundled with the Mozilla clients in the system _libdir. Fedora > solved this problem by making NSPR and NSS independent of Mozilla. In Samba4, we 'solved' the similar problems (on a smaller scale) by including the code statically. I can't claim that's a Superior solution... Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From abartlet at samba.org Tue Mar 13 04:20:41 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 13 Mar 2007 15:20:41 +1100 Subject: [Fedora-directory-devel] Why is there a Makefile in CVS? In-Reply-To: <45F54573.6020305@redhat.com> References: <1173657559.3506.133.camel@localhost.localdomain> <45F54573.6020305@redhat.com> Message-ID: <1173759641.28440.9.camel@localhost.localdomain> On Mon, 2007-03-12 at 06:20 -0600, Richard Megginson wrote: > Andrew Bartlett wrote: > > Why is there a Makefile (not Makefile.in) in CVS? > > > Makefile is there for historical reasons and will be removed asap. Great, thanks. > > Isn't the first thing we want to do (on a checkout) a ./configure, which > > will replace this file anyway? > > > > Likewise, I'm confused: why do we allow prefix and exec_prefix to be > > specified at 'make' (rather than configure) time? > You can set them at configure time. I use "configure > --prefix=/home/rich/11srv && make install" for testing. > > This is typically at > > configure time in other open source projects. > Actually, it is a "feature" of autoconf/automake to allow you to set > them at make time, in addition to being able to set them at configure > time. It is my understanding that autoconf/automake work fine, no > matter if you set them at configure or make time. From "info autoconf": > "Most of these variables have values that rely on `prefix' or > `exec_prefix'. It is deliberate that the directory output variables > keep them unexpanded: typically `@datadir@' will be replaced by > `${prefix}/share', not `/usr/local/share'. > > This behavior is mandated by the GNU coding standards, so that when > the user runs: > > `make' > she can still specify a different prefix from the one specified to > `configure', in which case, if needed, the package shall hard code > dependencies corresponding to the make-specified prefix. > > `make install' > she can specify a different installation location, in which case > the package _must_ still depend on the location which was compiled > in (i.e., never recompile when `make install' is run). This is an > extremely important feature, as many people may decide to install > all the files of a package grouped together, and then install > links from the final locations to there. > ... > " > > There is more in the autoconf info doc about this too. Yikes. That's very interesting. Can't blame GNU for lacking features :-) > > Changing this would seem > > to remove some additional complexity from the build system... > > > What additional complexity is introduced? It was this bit in Makefile.am that seems odd to me: # these are for the config files and scripts that we need to generate and replace # the paths and other tokens with the real values set during configure/make # note that we cannot just use AC_OUTPUT to do this for us, since it will do things like this: # LD_LIBRARY_PATH = ${prefix}/lib/fedora-ds # i.e. it literally copies in '${prefix}' rather than expanding it out - we want this instead: # LD_LIBRARY_PATH = /usr/lib/fedora-ds if BUNDLE fixupcmd = sed \ -e 's, at bindir\@,$(bindir),g' \ -e 's, at sbindir\@,$(sbindir),g' \ -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david_list at boreham.org Tue Mar 13 04:22:08 2007 From: david_list at boreham.org (David Boreham) Date: Mon, 12 Mar 2007 22:22:08 -0600 Subject: [Fedora-directory-devel] Re: RPATH status In-Reply-To: <1173759429.28440.5.camel@localhost.localdomain> References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> <1173572083.3506.111.camel@localhost.localdomain> <45F3641A.9030501@boreham.org> <45F547FA.4050602@redhat.com> <1173759429.28440.5.camel@localhost.localdomain> Message-ID: <45F626F0.1030200@boreham.org> Andrew Bartlett wrote: >Not in particular, but an interesting point was made on the fedora-devel >list: If the 'wrapped' binary forks a child, then that unrelated child >also inherits the environment, which may not be desired. > > FDS never forks anything. I suppose a perl backend or the link might _exec_ a child but I can't imagine why it would be useful to fork ever. >In Samba4, we 'solved' the similar problems (on a smaller scale) by >including the code statically. I can't claim that's a Superior >solution... > > Bah ! I spent an entire weekend in 1996 making that code into a shared library. From abartlet at samba.org Tue Mar 13 05:58:25 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 13 Mar 2007 16:58:25 +1100 Subject: [Fedora-directory-devel] Wiki page on LDAP directory server backend Message-ID: <1173765505.28440.19.camel@localhost.localdomain> I wish to thank Pete Rowley for getting me to start putting down in written form some of what has been going around in my head for too many months now: I have spent today working on a page in the Samba Wiki, detailing some of the requirements that we currently know about for Samba4 to use a directory server backend. I've tried to document the various known requirements, as well as some of the things we have brainstormed about in the past. http://wiki.samba.org/index.php/Samba4/LDAP_Backend Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From abartlet at samba.org Tue Mar 13 10:47:12 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 13 Mar 2007 21:47:12 +1100 Subject: [Fedora-directory-devel] Support for bitwise operations? In-Reply-To: <45F5B9C0.2020002@redhat.com> References: <1173519402.3506.102.camel@localhost.localdomain> <45F5B9C0.2020002@redhat.com> Message-ID: <1173782832.3506.182.camel@localhost.localdomain> On Mon, 2007-03-12 at 13:36 -0700, Pete Rowley wrote: > Andrew Bartlett wrote: > > It seems to me that Fedora DS does not support Microsoft's extended > > match bitwise operations. > > > > I chatted with Pete about it on IRC, but thought to document it here for > > discussion. While it would be technically possible for me to filter > > these on the client side, it becomes silly fast. I need the LDAP > > backend side to handle these. > > > > This is the kind of search Fedora DS needs to accept, for Samba4 to use > > it as a backend: > > (|(&(!(groupType:1.2.840.113556.1.4.803:=1))(groupType:1.2.840.113556.1.4.803:=2147483648)(groupType:1.2.840.113556.1.4.804:=10)) > > > > > Basic question: why are you storing bit fields in the first place? Why > not store the information in a more readily accessible fashion, both to > your code, and the administrator of the system? As you noted, the > bitwise extensible matches are Microsoft extensions and they have not > been specified in any RFC or IETF draft document AFAIK. Consequently > you should not expect the functionality to be generally available in > LDAP directory servers. Looking over this, it seems possible to write this as a slapi plugin, which I can then host (no doubt with other random hacks/patches/etc to make this thing happen) in Samba's lorikeet repository. I've looked around, and I can't find a free skeleton slapi module to work/hack from, aside from this one: http://docs.sun.com/source/817-7617/matching.html (which I won't use, because the copyright status is unclear to me). Is there an example matching rule plugin (that I can use in Fedora DS) out there? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rmeggins at redhat.com Tue Mar 13 13:06:20 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 13 Mar 2007 07:06:20 -0600 Subject: [Fedora-directory-devel] Re: RPATH status In-Reply-To: <45F626F0.1030200@boreham.org> References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> <1173572083.3506.111.camel@localhost.localdomain> <45F3641A.9030501@boreham.org> <45F547FA.4050602@redhat.com> <1173759429.28440.5.camel@localhost.localdomain> <45F626F0.1030200@boreham.org> Message-ID: <45F6A1CC.7090700@redhat.com> David Boreham wrote: > Andrew Bartlett wrote: > >> Not in particular, but an interesting point was made on the fedora-devel >> list: If the 'wrapped' binary forks a child, then that unrelated child >> also inherits the environment, which may not be desired. >> > FDS never forks anything. I suppose a perl backend or the link > might _exec_ a child but I can't imagine why it would be useful to > fork ever. > >> In Samba4, we 'solved' the similar problems (on a smaller scale) by >> including the code statically. I can't claim that's a Superior >> solution... >> >> > Bah ! I spent an entire weekend in 1996 making that code into a shared > library. Fedora _strongly discourages_ the use of static libraries. They made us convert svrcore into a shared library so that it could be included into Fedora [Extras]. > > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Mar 13 14:03:48 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 13 Mar 2007 08:03:48 -0600 Subject: [Fedora-directory-devel] Support for bitwise operations? In-Reply-To: <1173782832.3506.182.camel@localhost.localdomain> References: <1173519402.3506.102.camel@localhost.localdomain> <45F5B9C0.2020002@redhat.com> <1173782832.3506.182.camel@localhost.localdomain> Message-ID: <45F6AF44.1030807@redhat.com> Andrew Bartlett wrote: > On Mon, 2007-03-12 at 13:36 -0700, Pete Rowley wrote: > >> Andrew Bartlett wrote: >> >>> It seems to me that Fedora DS does not support Microsoft's extended >>> match bitwise operations. >>> >>> I chatted with Pete about it on IRC, but thought to document it here for >>> discussion. While it would be technically possible for me to filter >>> these on the client side, it becomes silly fast. I need the LDAP >>> backend side to handle these. >>> >>> This is the kind of search Fedora DS needs to accept, for Samba4 to use >>> it as a backend: >>> (|(&(!(groupType:1.2.840.113556.1.4.803:=1))(groupType:1.2.840.113556.1.4.803:=2147483648)(groupType:1.2.840.113556.1.4.804:=10)) >>> >>> >>> >> Basic question: why are you storing bit fields in the first place? Why >> not store the information in a more readily accessible fashion, both to >> your code, and the administrator of the system? As you noted, the >> bitwise extensible matches are Microsoft extensions and they have not >> been specified in any RFC or IETF draft document AFAIK. Consequently >> you should not expect the functionality to be generally available in >> LDAP directory servers. >> > > Looking over this, it seems possible to write this as a slapi plugin, > which I can then host (no doubt with other random hacks/patches/etc to > make this thing happen) in Samba's lorikeet repository. > > I've looked around, and I can't find a free skeleton slapi module to > work/hack from, aside from this one: > http://docs.sun.com/source/817-7617/matching.html (which I won't use, > because the copyright status is unclear to me). > > Is there an example matching rule plugin (that I can use in Fedora DS) > out there? > Not that I know of. Of course, the collation plugin is an "example" of a matching rule plugin - http://cvs.fedora.redhat.com/viewcvs/ldapserver/ldap/servers/plugins/collation/?root=dirsec > Andrew Bartlett > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Mar 13 14:09:21 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 13 Mar 2007 08:09:21 -0600 Subject: [Fedora-directory-devel] Why is there a Makefile in CVS? In-Reply-To: <1173759641.28440.9.camel@localhost.localdomain> References: <1173657559.3506.133.camel@localhost.localdomain> <45F54573.6020305@redhat.com> <1173759641.28440.9.camel@localhost.localdomain> Message-ID: <45F6B091.9080603@redhat.com> Andrew Bartlett wrote: > > It was this bit in Makefile.am that seems odd to me: > > # these are for the config files and scripts that we need to generate > and replace > # the paths and other tokens with the real values set during > configure/make > # note that we cannot just use AC_OUTPUT to do this for us, since it > will do things like this: > # LD_LIBRARY_PATH = ${prefix}/lib/fedora-ds > # i.e. it literally copies in '${prefix}' rather than expanding it out - > we want this instead: > # LD_LIBRARY_PATH = /usr/lib/fedora-ds > if BUNDLE > fixupcmd = sed \ > -e 's, at bindir\@,$(bindir),g' \ > -e 's, at sbindir\@,$(sbindir),g' \ > > It seems odd because it is odd - but there is no other way to replace things like @localstatedir@, @sysconfdir@, @sbindir@, etc. in .in files that we use during the build. I don't know how other projects do this - perhaps they ignore the "mandated GNU coding standards" and just have ${prefix} and ${exec_prefix} expanded during configure, and just let AC_CONFIG_FILES and AC_OUTPUT create all of the real files from their corresponding .in file. > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Tue Mar 13 21:36:43 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Wed, 14 Mar 2007 08:36:43 +1100 Subject: [Fedora-directory-devel] Why is there a Makefile in CVS? In-Reply-To: <45F6B091.9080603@redhat.com> References: <1173657559.3506.133.camel@localhost.localdomain> <45F54573.6020305@redhat.com> <1173759641.28440.9.camel@localhost.localdomain> <45F6B091.9080603@redhat.com> Message-ID: <1173821804.6281.1.camel@localhost.localdomain> On Tue, 2007-03-13 at 08:09 -0600, Richard Megginson wrote: > Andrew Bartlett wrote: > > > > It was this bit in Makefile.am that seems odd to me: > > > > # these are for the config files and scripts that we need to generate > > and replace > > # the paths and other tokens with the real values set during > > configure/make > > # note that we cannot just use AC_OUTPUT to do this for us, since it > > will do things like this: > > # LD_LIBRARY_PATH = ${prefix}/lib/fedora-ds > > # i.e. it literally copies in '${prefix}' rather than expanding it out - > > we want this instead: > > # LD_LIBRARY_PATH = /usr/lib/fedora-ds > > if BUNDLE > > fixupcmd = sed \ > > -e 's, at bindir\@,$(bindir),g' \ > > -e 's, at sbindir\@,$(sbindir),g' \ > > > > > It seems odd because it is odd - but there is no other way to replace > things like @localstatedir@, @sysconfdir@, @sbindir@, etc. in .in files > that we use during the build. I don't know how other projects do this - > perhaps they ignore the "mandated GNU coding standards" and just have > ${prefix} and ${exec_prefix} expanded during configure, and just let > AC_CONFIG_FILES and AC_OUTPUT create all of the real files from their > corresponding .in file. I think so. The coding standard seems to imply that you must be able to change the $prefix and $exec_prefix in the install, but that all internal references must be as if they had *not* been changed. Perhaps that's the clue? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rmeggins at redhat.com Tue Mar 13 22:14:52 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 13 Mar 2007 16:14:52 -0600 Subject: [Fedora-directory-devel] Why is there a Makefile in CVS? In-Reply-To: <1173821804.6281.1.camel@localhost.localdomain> References: <1173657559.3506.133.camel@localhost.localdomain> <45F54573.6020305@redhat.com> <1173759641.28440.9.camel@localhost.localdomain> <45F6B091.9080603@redhat.com> <1173821804.6281.1.camel@localhost.localdomain> Message-ID: <45F7225C.2030501@redhat.com> Andrew Bartlett wrote: > On Tue, 2007-03-13 at 08:09 -0600, Richard Megginson wrote: > >> Andrew Bartlett wrote: >> >>> >>> It was this bit in Makefile.am that seems odd to me: >>> >>> # these are for the config files and scripts that we need to generate >>> and replace >>> # the paths and other tokens with the real values set during >>> configure/make >>> # note that we cannot just use AC_OUTPUT to do this for us, since it >>> will do things like this: >>> # LD_LIBRARY_PATH = ${prefix}/lib/fedora-ds >>> # i.e. it literally copies in '${prefix}' rather than expanding it out - >>> we want this instead: >>> # LD_LIBRARY_PATH = /usr/lib/fedora-ds >>> if BUNDLE >>> fixupcmd = sed \ >>> -e 's, at bindir\@,$(bindir),g' \ >>> -e 's, at sbindir\@,$(sbindir),g' \ >>> >>> >>> >> It seems odd because it is odd - but there is no other way to replace >> things like @localstatedir@, @sysconfdir@, @sbindir@, etc. in .in files >> that we use during the build. I don't know how other projects do this - >> perhaps they ignore the "mandated GNU coding standards" and just have >> ${prefix} and ${exec_prefix} expanded during configure, and just let >> AC_CONFIG_FILES and AC_OUTPUT create all of the real files from their >> corresponding .in file. >> > > I think so. The coding standard seems to imply that you must be able to > change the $prefix and $exec_prefix in the install, but that all > internal references must be as if they had *not* been changed. So, let me see if I understand what you're saying. Let's say I have some .in files which have references to @prefix@ and @bindir@ (which is ${prefix}/bin). I run configure which creates realfile from realfile.in - I don't pass in --prefix to configure, which means @prefix@ will expand to "/usr" and @bindir@ to "/usr/bin" in realfile. Next, I run make prefix=/myprefix install. realfile will still refer to "/usr" even though I've told make to use "/myprefix" instead. Where does it say or imply that? Isn't that what "make DESTDIR=/path install" for? > Perhaps > that's the clue? > > Andrew Bartlett > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Tue Mar 13 22:24:12 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Wed, 14 Mar 2007 09:24:12 +1100 Subject: [Fedora-directory-devel] Why is there a Makefile in CVS? In-Reply-To: <45F7225C.2030501@redhat.com> References: <1173657559.3506.133.camel@localhost.localdomain> <45F54573.6020305@redhat.com> <1173759641.28440.9.camel@localhost.localdomain> <45F6B091.9080603@redhat.com> <1173821804.6281.1.camel@localhost.localdomain> <45F7225C.2030501@redhat.com> Message-ID: <1173824652.6281.11.camel@localhost.localdomain> On Tue, 2007-03-13 at 16:14 -0600, Richard Megginson wrote: > Andrew Bartlett wrote: > > On Tue, 2007-03-13 at 08:09 -0600, Richard Megginson wrote: > > > >> Andrew Bartlett wrote: > >> > >>> > >>> It was this bit in Makefile.am that seems odd to me: > >>> > >>> # these are for the config files and scripts that we need to generate > >>> and replace > >>> # the paths and other tokens with the real values set during > >>> configure/make > >>> # note that we cannot just use AC_OUTPUT to do this for us, since it > >>> will do things like this: > >>> # LD_LIBRARY_PATH = ${prefix}/lib/fedora-ds > >>> # i.e. it literally copies in '${prefix}' rather than expanding it out - > >>> we want this instead: > >>> # LD_LIBRARY_PATH = /usr/lib/fedora-ds > >>> if BUNDLE > >>> fixupcmd = sed \ > >>> -e 's, at bindir\@,$(bindir),g' \ > >>> -e 's, at sbindir\@,$(sbindir),g' \ > >>> > >>> > >>> > >> It seems odd because it is odd - but there is no other way to replace > >> things like @localstatedir@, @sysconfdir@, @sbindir@, etc. in .in files > >> that we use during the build. I don't know how other projects do this - > >> perhaps they ignore the "mandated GNU coding standards" and just have > >> ${prefix} and ${exec_prefix} expanded during configure, and just let > >> AC_CONFIG_FILES and AC_OUTPUT create all of the real files from their > >> corresponding .in file. > >> > > > > I think so. The coding standard seems to imply that you must be able to > > change the $prefix and $exec_prefix in the install, but that all > > internal references must be as if they had *not* been changed. > So, let me see if I understand what you're saying. Let's say I have > some .in files which have references to @prefix@ and @bindir@ (which is > ${prefix}/bin). I run configure which creates realfile from realfile.in > - I don't pass in --prefix to configure, which means @prefix@ will > expand to "/usr" and @bindir@ to "/usr/bin" in realfile. Next, I run > make prefix=/myprefix install. realfile will still refer to "/usr" even > though I've told make to use "/myprefix" instead. Hmm, I was reading the case about 'make install' and not 'make'. I think the GNU standards are insane at this point, and I don't know of any packages or users who need this functionality. Re-running ./configure isn't a very high price... > Where does it say or imply that? Isn't that what "make DESTDIR=/path > install" for? DESTDIR helps, because you don't have to specify a global prefix, which makes creating RPMs sane. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From abartlet at samba.org Tue Mar 13 22:58:29 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Wed, 14 Mar 2007 09:58:29 +1100 Subject: [Fedora-directory-devel] Support for bitwise operations? In-Reply-To: <45F6AF44.1030807@redhat.com> References: <1173519402.3506.102.camel@localhost.localdomain> <45F5B9C0.2020002@redhat.com> <1173782832.3506.182.camel@localhost.localdomain> <45F6AF44.1030807@redhat.com> Message-ID: <1173826709.6281.16.camel@localhost.localdomain> On Tue, 2007-03-13 at 08:03 -0600, Richard Megginson wrote: > Andrew Bartlett wrote: > > Is there an example matching rule plugin (that I can use in Fedora DS) > > out there? > > > Not that I know of. Of course, the collation plugin is an "example" of > a matching rule plugin - > http://cvs.fedora.redhat.com/viewcvs/ldapserver/ldap/servers/plugins/collation/?root=dirsec Yeah, I found that one. I'm still none the wiser (I'm just having trouble penetrating the code). Any chance a skeleton extended match module could be published? Alternately, I would be happy with just patching the source, but I've had trouble finding where internal matching rules are defined. Any clues? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rmeggins at redhat.com Tue Mar 13 23:33:02 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 13 Mar 2007 17:33:02 -0600 Subject: [Fedora-directory-devel] Support for bitwise operations? In-Reply-To: <1173826709.6281.16.camel@localhost.localdomain> References: <1173519402.3506.102.camel@localhost.localdomain> <45F5B9C0.2020002@redhat.com> <1173782832.3506.182.camel@localhost.localdomain> <45F6AF44.1030807@redhat.com> <1173826709.6281.16.camel@localhost.localdomain> Message-ID: <45F734AE.5070308@redhat.com> Andrew Bartlett wrote: > On Tue, 2007-03-13 at 08:03 -0600, Richard Megginson wrote: > >> Andrew Bartlett wrote: >> > > >>> Is there an example matching rule plugin (that I can use in Fedora DS) >>> out there? >>> >>> >> Not that I know of. Of course, the collation plugin is an "example" of >> a matching rule plugin - >> http://cvs.fedora.redhat.com/viewcvs/ldapserver/ldap/servers/plugins/collation/?root=dirsec >> > > Yeah, I found that one. I'm still none the wiser (I'm just having > trouble penetrating the code). Any chance a skeleton extended match > module could be published? > Possibly. > Alternately, I would be happy with just patching the source, but I've > had trouble finding where internal matching rules are defined. Any > clues? > I don't think there are any internal matching rules defined. You might also take a look at the syntaxes plugin. > Thanks, > > Andrew Bartlett > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Mar 15 17:04:01 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 15 Mar 2007 11:04:01 -0600 Subject: [Fedora-directory-devel] Please review: Bug 232377: PAM passthru ENTRY method not working Message-ID: <45F97C81.9050605@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232377 Resolves: bug 232377 Bug Description: PAM passthru ENTRY method not working Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: There are several problems. 1) For the ENTRY method to perform the internal search to get the entry for the bind DN, it must have a component ID (aka plugin identity). The code was already there to get/set it, but it was never initialized in the init function. 2) You cannot mix slapi_sdn_new* with slapi_sdn_init* - slapi_sdn_init will erase the knowledge that the Slapi_DN was allocated with malloc and it will not free it in slapi_sdn_free(). 3) People may assume they can specify a subtree (e.g. ou=people,dc=example,dc=com) instead of a suffix for the list of included/excluded suffixes. The error message will not print a list of valid suffixes for the admin to use. 4) slapi_be_exist was failing because the database does not notify the mapping tree code that the backend is started during startup. This works fine under normal conditions because most all of the code in mapping_tree.c will lookup the backend if the mtn_be pointer in the mapping tree node is NULL. However, slapi_be_exist and slapi_be_select do not do this. The proper solution is to call slapi_mtn_be_started() at database startup time. This is the same thing that happens when a backend is added at runtime. Platforms tested: FC6 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=150138&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From prowley at redhat.com Thu Mar 15 18:14:00 2007 From: prowley at redhat.com (Pete Rowley) Date: Thu, 15 Mar 2007 11:14:00 -0700 Subject: [Fedora-directory-devel] Please review: Bug 232377: PAM passthru ENTRY method not working In-Reply-To: <45F97C81.9050605@redhat.com> References: <45F97C81.9050605@redhat.com> Message-ID: <45F98CE8.7070900@redhat.com> Looks good. Richard Megginson wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232377 > Resolves: bug 232377 > Bug Description: PAM passthru ENTRY method not working > Reviewed by: ??? > Files: see diff > Branch: HEAD > Fix Description: There are several problems. > 1) For the ENTRY method to perform the internal search to get the > entry for the bind DN, it must have a component ID (aka plugin > identity). The code was already there to get/set it, but it was never > initialized in the init function. > 2) You cannot mix slapi_sdn_new* with slapi_sdn_init* - slapi_sdn_init > will erase the knowledge that the Slapi_DN was allocated with malloc > and it will not free it in slapi_sdn_free(). > 3) People may assume they can specify a subtree (e.g. > ou=people,dc=example,dc=com) instead of a suffix for the list of > included/excluded suffixes. The error message will not print a list > of valid suffixes for the admin to use. > 4) slapi_be_exist was failing because the database does not notify the > mapping tree code that the backend is started during startup. This > works fine under normal conditions because most all of the code in > mapping_tree.c will lookup the backend if the mtn_be pointer in the > mapping tree node is NULL. However, slapi_be_exist and > slapi_be_select do not do this. The proper solution is to call > slapi_mtn_be_started() at database startup time. This is the same > thing that happens when a backend is added at runtime. > Platforms tested: FC6 > Flag Day: no > Doc impact: no > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=150138&action=diff > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -- Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Thu Mar 15 20:55:09 2007 From: nhosoi at redhat.com (Noriko Hosoi) Date: Thu, 15 Mar 2007 12:55:09 -0800 Subject: [Fedora-directory-devel] Please review: [Bug 232050] Change format of DBVERSION and guardian files (changelog) In-Reply-To: <200703152039.l2FKdI9K014709@bugzilla.redhat.com> References: <200703152039.l2FKdI9K014709@bugzilla.redhat.com> Message-ID: <45F9B2AD.4080907@redhat.com> Summary: Change format of DBVERSION and guardian files https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232050 [Problem description] The DBVERSION and guardian files used by the database backends should convey some information about the database implementation used (e.g. berkeley db, sqlite), the version, the directory server database backend used, and any other information pertinent to the server being able to use or upgrade the files. The following format is proposed: implementation/version/server backend plugin name[/other tag][/other tag].... For example: bdb/4.2/libback-ldbm/newidl This indicates that the files use Berkeley DB version 4.2, they are used by the server libback-ldbm database plugin, and the index files use the newidl format. The other tags are optional and may be implementation specific. At a minimum, the file must contain the implementation/version/pluginname. The reasons for changing the format are as follows: 1) Make it easy for humans and code to identify what the files are, how they are used, and how to upgrade or migrate them 2) Separate the database file version and formats from the directory server version, vendor, and brand 3) Allow new database implementations, plugins, and features e.g. sqlite/3.0/libback-sqlite 4) A one line description is easy to read in and easy to parse When the server reads in a database with an old format DBVERSION or guardian file, it will change the file to use the new format and upgrade the data as necessary. -------------------------------------------------------------------------------- This change is made against the changelog used by the replication plugin following the format change on the main backend. ------- Additional Comments From nhosoi at redhat.com 2007-03-15 16:39 EST ------- Created an attachment (id=150172) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=150172&action=view) cvs diffs Files: repl_shared.h cl5_api.h cl5_api.c Changes: 1) change the format of changelogdb/{DBVERSION,guardian} files [before] Changelog5/NSMMReplicationPlugin/4.0 [after] bdb/4.4/libreplication-plugin Note: changelog guardian file stores the same string as DBVERSION does, thus changed the format to follow the DBVERSION style. As being done for the backend, use DB_VERSION_MAJOR and _MINOR to get the current version of the Berkeley DB. 2) Added the 3-rd arg buflen to _cl5ReadDBVersion. 3) Added transaction removing code to _cl5Upgrade3_4 4) Added _cl5Upgrade4_4 which is a subset of _cl5Upgrade3_4. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Fri Mar 16 17:05:12 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 16 Mar 2007 11:05:12 -0600 Subject: [Fedora-directory-devel] Please review: Bug 232684: need initscripts for Solaris Message-ID: <45FACE48.4080201@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232684 Resolves: bug 232684 Bug Description: need initscripts for Solaris Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: I was able to just use the existing init script for linux for the most part. However, Solaris has to use plain old Bourne shell for init scripts, so I had to remove several bash-isms. I also added functions for success and failure (Solaris has no library of shell script functions for use in init scripts), and Solaris uses pgrep instead pidof. On Solaris, /var/run is a tmpfs (i.e. in memory) file system which is removed upon reboot. So we have to create the /var/run/fedora-ds directory and change the mode if it doesn't exist. Platforms tested: Solaris 9 Flag Day: no Doc impact: no https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=150248&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Fri Mar 16 17:19:04 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 16 Mar 2007 11:19:04 -0600 Subject: [Fedora-directory-devel] Please review: Bug 231905: migration: Migrate from 1.0.x to 1.1 Message-ID: <45FAD188.3030304@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231905 Resolves: bug 231905 Bug Description: migration: Migrate from 1.0.x to 1.1 Reviewed by: ??? Files: see diff Branch: HEAD Fix Description: The basic strategy is 1) shutdown the old servers - databases should be quiescent 2) run the migration script - this will copy all of the files (under /opt/fedora-ds/slapd-* by default) to their new FHS style locations, and fix up any entries and attributes that are obsolete or have changed (e.g. values that refer to paths) 3) service fedora-ds start The migration script does not need to do anything to the database files - the new database code added by Noriko will handle the database upgrade automagically, but I'm leaving the database upgrade code in the script, commented out, in case we need it in the future. This also fixes an annoying problem with automake - it would build ds_newinst.pl from ds_newinst.pl.in in the source ldap/admin/src directory, and use that version. This is really a problem with multi platform builds, where you want to share the ldapserver source code among multiple platforms. With the fix, built/ldap/admin/src/ds_newinst.pl is generated from srcdir/ldap/admin/src/ds_newinst.pl.in, and srcdir/ldap/admin/src/ds_newinst.pl is not written. Platforms tested: FC6 Flag Day: no Doc impact: Yes - we need to document migration Diffs: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=150251&action=diff migrateTo11.in: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=150252 migrateTo11 expanded: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=150253 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From yoram.kahana at gmail.com Sun Mar 18 16:06:32 2007 From: yoram.kahana at gmail.com (Yoram Kahana) Date: Sun, 18 Mar 2007 18:06:32 +0200 Subject: [Fedora-directory-devel] tls_checkpeer coresponding for the openldap API Message-ID: <37d92a190703180906n4541b8f0xd04aafed8dd34443@mail.gmail.com> Hi, I am using the FDS with the SSL/TLS enable. I had to activate my ldap.confconfig file to the "tls_checkpeer no". It works fine and solved the problem. I am looking for the corresponding solution when using the openldap (or Fedora) API. After the ldap_start_tls_s(ldap,NULL,NULL) I am getting the problem that the server certificate failed in the verifying procedure. The client side error is SSL3_GET_SERVER_CERTIFICATE: certificate verify failed In the server i am getting an error notifying me that the peer could not verify the ca certificate. Any idea for how to define (through the API) to ignore the server certificate similar to the tls_checkpeer Thanks in advance Yoram -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhosoi at redhat.com Mon Mar 19 22:49:22 2007 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 19 Mar 2007 14:49:22 -0800 Subject: [Fedora-directory-devel] Please review: [Bug 233027] make db2bak.pl & db2ldif.pl user more user-friendly In-Reply-To: References: Message-ID: <45FF1372.5070708@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233027 Summary: make db2bak.pl & db2ldif.pl user more user-friendly Product: Fedora Directory Server Version: 1.0.4 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: Command Line Utilities AssignedTo: nhosoi at redhat.com ReportedBy: nhosoi at redhat.com QAContact: ohegarty at redhat.com Estimated Hours: 0.0 ------- Additional Comments From nhosoi at redhat.com 2007-03-19 18:41 EST ------- Created an attachment (id=150442) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=150442&action=view) cvs diff template-db2bak.pl.in template-db2ldif.pl.in Files: ldap/admin/src/scripts/template-db2bak.pl.in ldap/admin/src/scripts/template-db2ldif.pl.in Changes: db2bak.pl: print out the back up directory Back up directory: ... db2ldif.pl: print out the exported ldif file name Exported ldif file: ... The ldif file name format: -[}]+-.ldif Description of problem: [background info] > > Both db2bak.pl and db2ldif.pl do not say much about where they are backing up > or exporting. > > ./db2ldif.pl -D "cn=Directory Manager" -w -n userRoot` > > adding new entry cn=export_2007_3_19_11_1_38, cn=export, cn=tasks, cn=config > > > > ./db2bak.pl -D 'cn=Directory Manager' -w > > adding new entry cn=backup_2007_3_19_11_14_51, cn=backup, cn=tasks, cn=config > > > > Isn't it nicer the perl scripts prints out something like "exporting to > /" or "backing up to " if it's not too noisy? Yes, they should print something like that. > > > > Maybe, we'd better add "backend name" to the path as well? E.g., > laputa-userRoot_2007_3_19_11_14_51.ldif. Sure. [Fix proposal] db2bak.pl ========= ./db2bak.pl -D 'cn=Directory Manager' -w Back up directory: /opt/fedora-ds/slapd-laputa/bak/2007_3_19_14_18_17 adding new entry cn=backup_2007_3_19_14_18_17, cn=backup, cn=tasks, cn=config db2ldif.pl ========== 1) if suffixes are given, the first rdn values are added to the ldif file name following the server id separated by '-'s. ./db2ldif.pl -D 'cn=Directory Manager' -w -s dc=example,dc=com -s o=netscaperoot Exported ldif file: /opt/fedora-ds/slapd-laputa/ldif/laputa-example-netscaperoot-2007_3_19_14_18_7.ldif adding new entry cn=export_2007_3_19_14_18_7, cn=export, cn=tasks, cn=config 2) if backend instance names are given, the instance names are added to the ldif file name following the server id separated by '-'s. ./db2ldif.pl -D 'cn=Directory Manager' -w -n userRoot -n netscapeRoot Exported ldif file: /opt/fedora-ds/slapd-laputa/ldif/laputa-userRoot-netscapeRoot-2007_3_19_14_18_14.ldif adding new entry cn=export_2007_3_19_14_18_14, cn=export, cn=tasks, cn=config note: if '-a' options are given to the both utilities, the specified path is used for the back up dir/ldif file. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Tue Mar 20 00:45:54 2007 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 19 Mar 2007 16:45:54 -0800 Subject: [Fedora-directory-devel] Please review: [Bug 233027] make db2bak.pl & db2ldif.pl user more user-friendly (comment #4) In-Reply-To: <45FF1372.5070708@redhat.com> References: <45FF1372.5070708@redhat.com> Message-ID: <45FF2EC2.3000602@redhat.com> Summary: make db2bak.pl & db2ldif.pl user more user-friendly https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233027 Found some more inconsistencies in the server utilities... Thanks in advance, --noriko ------- Additional Comments From nhosoi at redhat.com 2007-03-19 20:39 EST ------- Created an attachment (id=150447) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=150447&action=view) cvs diff template-db2bak.in, template-db2bak.pl.in, template-db2ldif.in Files: ldap/admin/src/scripts/template-db2bak.in ldap/admin/src/scripts/template-db2bak.pl.in ldap/admin/src/scripts/template-db2ldif.in ldap/admin/src/scripts/template-db2ldif.pl.in Changes: 1) Found db2bak, db2bak.pl, and db2ldif do not backup/export into the dir/file which do not start with the string. It could cause the difficulty to find out which server instance does the backup/exported file belongs to. Also, to make them consistent with db2ldif.pl, added the "server id" string to the back up dir name/exported ldif file name. 2) db2ldif[.pl] takes -M option. With the -M option, the server adds backend name to the ldif file name. To reduce the redundancy, stopped adding the backend name if -M is set. 3) made the ldif file name db2ldif generates consistent with the one db2ldif.pl generates. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233027 > > Summary: make db2bak.pl & db2ldif.pl user more user-friendly > Product: Fedora Directory Server > Version: 1.0.4 > Platform: All > OS/Version: Linux > Status: NEW > Severity: medium > Priority: medium > Component: Command Line Utilities > AssignedTo: nhosoi at redhat.com > ReportedBy: nhosoi at redhat.com > QAContact: ohegarty at redhat.com > Estimated Hours: 0.0 > > ------- Additional Comments From nhosoi at redhat.com 2007-03-19 18:41 > EST ------- > Created an attachment (id=150442) > --> > (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=150442&action=view) > > cvs diff template-db2bak.pl.in template-db2ldif.pl.in > > Files: > ldap/admin/src/scripts/template-db2bak.pl.in > ldap/admin/src/scripts/template-db2ldif.pl.in > > Changes: > db2bak.pl: print out the back up directory > Back up directory: ... > db2ldif.pl: print out the exported ldif file name > Exported ldif file: ... > The ldif file name format: -[} value>]+-.ldif > > > Description of problem: > [background info] > >> > Both db2bak.pl and db2ldif.pl do not say much about where they are >> backing up >> > or exporting. > >> > ./db2ldif.pl -D "cn=Directory Manager" -w -n userRoot` >> > adding new entry cn=export_2007_3_19_11_1_38, cn=export, cn=tasks, >> cn=config >> > >> > ./db2bak.pl -D 'cn=Directory Manager' -w >> > adding new entry cn=backup_2007_3_19_11_14_51, cn=backup, cn=tasks, >> cn=config >> > >> > Isn't it nicer the perl scripts prints out something like >> "exporting to >> > /" or "backing up to " if it's not > too noisy? > Yes, they should print something like that. > >> > >> > Maybe, we'd better add "backend name" to the path as well? E.g., >> > laputa-userRoot_2007_3_19_11_14_51.ldif. > Sure. > [Fix proposal] > db2bak.pl > ========= > ./db2bak.pl -D 'cn=Directory Manager' -w > Back up directory: /opt/fedora-ds/slapd-laputa/bak/2007_3_19_14_18_17 > adding new entry cn=backup_2007_3_19_14_18_17, cn=backup, cn=tasks, > cn=config > > db2ldif.pl > ========== > 1) if suffixes are given, the first rdn values are added to the ldif > file name > following the server id separated by '-'s. > ./db2ldif.pl -D 'cn=Directory Manager' -w -s dc=example,dc=com -s > o=netscaperoot > Exported ldif file: > /opt/fedora-ds/slapd-laputa/ldif/laputa-example-netscaperoot-2007_3_19_14_18_7.ldif > > adding new entry cn=export_2007_3_19_14_18_7, cn=export, cn=tasks, > cn=config > > 2) if backend instance names are given, the instance names are added > to the ldif > file name following the server id separated by '-'s. > ./db2ldif.pl -D 'cn=Directory Manager' -w -n userRoot -n > netscapeRoot > Exported ldif file: > /opt/fedora-ds/slapd-laputa/ldif/laputa-userRoot-netscapeRoot-2007_3_19_14_18_14.ldif > > adding new entry cn=export_2007_3_19_14_18_14, cn=export, cn=tasks, > cn=config > > note: if '-a' options are given to the both utilities, the specified > path is > used for the back up dir/ldif file. > > > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Wed Mar 21 17:34:12 2007 From: nhosoi at redhat.com (Noriko Hosoi) Date: Wed, 21 Mar 2007 09:34:12 -0800 Subject: [Fedora-directory-devel] Please review: [Bug 233215] verify-db.pl still assumes the db dir is always in the instance dir In-Reply-To: References: Message-ID: <46016C94.8020200@redhat.com> Summary: verify-db.pl still assumes the db dir is always in the instance dir https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233215 Product: Fedora Directory Server Version: 1.0.4 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: Command Line Utilities AssignedTo: nhosoi at redhat.com ReportedBy: nhosoi at redhat.com QAContact: ohegarty at redhat.com Estimated Hours: 0.0 Description of problem: The command line utility failed to be updated with the FHS change. If the db is not in the instance dir (or the directory where verify-db.pl is located), it does not check the db files. ------- Additional Comments From nhosoi at redhat.com 2007-03-21 13:28 EST ------- Created an attachment (id=150603) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=150603&action=view) cvs diff template-verify-db.pl.in File: ldap/admin/src/scripts/template-verify-db.pl.in Changes: 0) eliminated the "current directory" from the utility. Now, it can be run from any location. 1) updated to take a new option [-a ] to allow specifying the db dir/changelog dir; by default the start point is "db_dir" (nsslapd-directory in cn=config,cn=ldbm database,cn=plugins,cn=config) 2) instead of assuming the db dir structure (e.g., db//), now it checks all the db files found under the specified path. This allows to run the utility against the backup files, as well. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Wed Mar 21 17:46:26 2007 From: nhosoi at redhat.com (Noriko Hosoi) Date: Wed, 21 Mar 2007 09:46:26 -0800 Subject: [Fedora-directory-devel] Commit: [Bug 233215] verify-db.pl still assumes the db dir is always in the instance dir In-Reply-To: <46016C94.8020200@redhat.com> References: <46016C94.8020200@redhat.com> Message-ID: <46016F72.5060903@redhat.com> Summary: verify-db.pl still assumes the db dir is always in the instance dir https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233215 ------- Additional Comments From nhosoi at redhat.com 2007-03-21 13:43 EST ------- Created an attachment (id=150606) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=150606&action=view) cvs commit message Reviewed by Rich (Thank you!) Checked in into HEAD. > Product: Fedora Directory Server > Version: 1.0.4 > Platform: All > OS/Version: Linux > Status: NEW > Severity: medium > Priority: medium > Component: Command Line Utilities > AssignedTo: nhosoi at redhat.com > ReportedBy: nhosoi at redhat.com > QAContact: ohegarty at redhat.com > Estimated Hours: 0.0 > > > Description of problem: > The command line utility failed to be updated with the FHS change. > > If the db is not in the instance dir (or the directory where > verify-db.pl is > located), it does not check the db files. > > > ------- Additional Comments From nhosoi at redhat.com 2007-03-21 13:28 > EST ------- > Created an attachment (id=150603) > --> > (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=150603&action=view) > > cvs diff template-verify-db.pl.in > > File: ldap/admin/src/scripts/template-verify-db.pl.in > > Changes: > 0) eliminated the "current directory" from the utility. Now, it can > be run > from any location. > 1) updated to take a new option [-a ] to allow > specifying > the db dir/changelog dir; by default the start point is "db_dir" > (nsslapd-directory in cn=config,cn=ldbm database,cn=plugins,cn=config) > 2) instead of assuming the db dir structure (e.g., > db//), now it checks all the db files > found under > the specified path. This allows to run the utility against the backup > files, > as well. > >------------------------------------------------------------------------ > >-- >Fedora-directory-devel mailing list >Fedora-directory-devel at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-directory-devel > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Wed Mar 28 23:50:20 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 29 Mar 2007 09:50:20 +1000 Subject: [Fedora-directory-devel] How to compile the collation plugin? Message-ID: <1175125821.2634.51.camel@localhost.localdomain> I've been working to develop a new bitwise extended match slapi plugin, based on the collation plugin. However, I never stopped to see if the collection plugin worked, or compiled... Can someone give me a clue about how to compile the collation plugin, so I may try the same for my derivative? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rmeggins at redhat.com Thu Mar 29 00:14:29 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Wed, 28 Mar 2007 18:14:29 -0600 Subject: [Fedora-directory-devel] How to compile the collation plugin? In-Reply-To: <1175125821.2634.51.camel@localhost.localdomain> References: <1175125821.2634.51.camel@localhost.localdomain> Message-ID: <460B04E5.3080504@redhat.com> Andrew Bartlett wrote: > I've been working to develop a new bitwise extended match slapi plugin, > based on the collation plugin. > Great! > However, I never stopped to see if the collection plugin worked, or > compiled... > > Can someone give me a clue about how to compile the collation plugin, so > I may try the same for my derivative? > It does build and work. What exactly are you trying to do? > Thanks, > > Andrew Bartlett > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Thu Mar 29 02:59:48 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 29 Mar 2007 12:59:48 +1000 Subject: [Fedora-directory-devel] How to compile the collation plugin? In-Reply-To: <460B04E5.3080504@redhat.com> References: <1175125821.2634.51.camel@localhost.localdomain> <460B04E5.3080504@redhat.com> Message-ID: <1175137188.7846.6.camel@localhost.localdomain> On Wed, 2007-03-28 at 18:14 -0600, Richard Megginson wrote: > Andrew Bartlett wrote: > > I've been working to develop a new bitwise extended match slapi plugin, > > based on the collation plugin. > > > Great! > > However, I never stopped to see if the collection plugin worked, or > > compiled... > > > > Can someone give me a clue about how to compile the collation plugin, so > > I may try the same for my derivative? > > > It does build and work. What exactly are you trying to do? I ran 'make' in that directory. What is the correct procedure? -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rmeggins at redhat.com Thu Mar 29 03:06:45 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Wed, 28 Mar 2007 21:06:45 -0600 Subject: [Fedora-directory-devel] How to compile the collation plugin? In-Reply-To: <1175137188.7846.6.camel@localhost.localdomain> References: <1175125821.2634.51.camel@localhost.localdomain> <460B04E5.3080504@redhat.com> <1175137188.7846.6.camel@localhost.localdomain> Message-ID: <460B2D45.2080601@redhat.com> Andrew Bartlett wrote: > On Wed, 2007-03-28 at 18:14 -0600, Richard Megginson wrote: > >> Andrew Bartlett wrote: >> >>> I've been working to develop a new bitwise extended match slapi plugin, >>> based on the collation plugin. >>> >>> >> Great! >> >>> However, I never stopped to see if the collection plugin worked, or >>> compiled... >>> >>> Can someone give me a clue about how to compile the collation plugin, so >>> I may try the same for my derivative? >>> >>> >> It does build and work. What exactly are you trying to do? >> > > I ran 'make' in that directory. What is the correct procedure? > Just do the usual configure && make from your top level build directory. If you want to just build the collation plugin, just do "make libcollation-plugin.la". We will be removing all Makefiles from the source tree once we are able to build using the autotool build method on all platforms. For now, please just ignore them. > > ------------------------------------------------------------------------ > > -- > Fedora-directory-devel mailing list > Fedora-directory-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Fri Mar 30 02:00:14 2007 From: nhosoi at redhat.com (Noriko Hosoi) Date: Thu, 29 Mar 2007 18:00:14 -0800 Subject: [Fedora-directory-devel] Please review: [Bug 233215] verify-db.pl still assumes the db dir is always in the instance dir In-Reply-To: <200703300130.l2U1UQOh007840@bugzilla.redhat.com> References: <200703300130.l2U1UQOh007840@bugzilla.redhat.com> Message-ID: <460C6F2E.1060508@redhat.com> Summary: verify-db.pl still assumes the db dir is always in the instance dir https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233215 nhosoi at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |ASSIGNED This review request contains the proposed changes on ldapserver, internal spec file for Berkeley DB 4.2.52, and the Berkeley DB 4.2.52. ------- Additional Comments From nhosoi at redhat.com 2007-03-29 21:30 EST ------- There are mutiple problems found around verify-db.pl on Solaris... :( 1, I introduced "DB-DIR" macro for template-verify-db.pl.in, but the corresponding version if create_instance.c hasn't been checked in yet (* create_instance.c.diff is being attached) 2. template-verify-db.in has the following envirament variable PATH set: $ENV{'PATH'} = "$prefix at db_bindir@:$prefix/usr/bin:@db_bindir@:/usr/bin"; And the derived verify-db.pl on 64-bit Solaris looks like this: $ENV{'PATH'} = "$prefix/usr/bin:$prefix/usr/bin:/usr/bin:/usr/bin"; 2-1. The problem is db_* utilities on 64-bit Solaris are installed in /usr/bin/sparcv9, thus verify-db.pl fails to find the executables and exits. 2-2. To get the right path, db4 packaging is supposed to generate db.pc and put the file in /usr/lib/sparcv9/pkgconfig, but svn:pkgs/db4 spec file does not have the code (** db4.template.diff is being attached) Note: the system Berkeley DB on RHELs has db.pc in /usr/lib/pkgconfig. 2-3. Even though db.pc is placed in the right place, ldapserver/m4/db.m4 does not check db.pc with pkg-config, but sets the hardcoded path /usr/bin to db_bindir (*** db.m4.diff is being attached) 3. With all the above fixes, ran verify-db.pl, then one of the Berkeley DB utilities db_printlog crashed... The cause of the crash was a field called timestamp is declared as int32_t, but the pointer to the value is casted to (time_t *), where time_t is 64 bits on the 64-bit machine. The cast mismatch makes ctime/localtime fail and it leads the utility crash. I looked at the db 4.4.20 code, and verified it was fixed. I back-ported the change to 4.2.52 and made a patch since I could not find the patch on the Sleepycat site. (**** patch.4.2.52.txn is being attached) ------- Additional Comments From nhosoi at redhat.com 2007-03-29 21:32 EST ------- Created an attachment (id=151245) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151245&action=view) cvs diff create_instance.c (* create_instance.c.diff in Comment #7) File: ldap/admin/src/create_instance.c Change: 1, I introduced "DB-DIR" macro for template-verify-db.pl.in, but the corresponding version if create_instance.c hasn't been checked in yet. ------- Additional Comments From nhosoi at redhat.com 2007-03-29 21:37 EST ------- Created an attachment (id=151246) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151246&action=view) svn diff db4.template (** db4.template.diff in Comment #7) File: svn:rpms/pkgs/db4/SPECS/db4.template Changes: 1) added a code to generate db.pc for pkg-config 2) apply a patch to fix the db_printlog crash problem. The patch proposal is being attached later (**** patch.4.2.52.txn) ------- Additional Comments From nhosoi at redhat.com 2007-03-29 21:42 EST ------- Created an attachment (id=151247) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151247&action=view) cvs diff ldapserver/m4/db.m4 (*** db.m4.diff) File: ldapserver/m4/db.m4 Change: To set db_bindir, if db.pc exists, check if bindir variable is defined in the file or not. If it's defined, set it to db_bindir. If not, set the default path /usr/bin to db_bindir. ------- Additional Comments From nhosoi at redhat.com 2007-03-29 21:47 EST ------- Created an attachment (id=151248) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151248&action=view) Proposed patch (**** patch.4.2.52.txn) File: svn:rpms/pkgs/db4/SOURCES/patch.4.2.52.txn Fix Description: The cause of the db_printlog crash was the unexpected cast from the pointer to the 32-bit integer to the pointer to time_t/long (64-bit). The patch is a back-port from db 4.4.20, where the problem was already fixed. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Sat Mar 31 02:10:40 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Sat, 31 Mar 2007 12:10:40 +1000 Subject: [Fedora-directory-devel] slapi extednded match plugin: How to limit attribute's to match on? Message-ID: <1175307040.20887.84.camel@localhost.localdomain> I've got my bitwise match plugin to load and run, but now I have an issue. it appears that my matching rule needs to limit what attributes it applies itself to. That is, when I step though to code, from this query: [abartlet at piglett source]$ bin/ldbsearch -H ldapi:///data/samba/samba4/svn/source/st/dc/ldap/ldapi -b "dc=samba,dc=example,dc=com" -s sub '(|(&(!(groupType:1.2.840.113556.1.4.803:=1))(groupType:1.2.840.113556.1.4.803:=2147483648)(groupType:1.2.840.113556.1.4.804:=10)))' sAMAccountName groupType # returned 0 records I seem to be walking all the attributes, not just the attributes in the search expression: 75 errno = 0; 76 a = strtoull((*vals)->bv_val, NULL, 10); 77 if (errno == ERANGE) { 78 ber_bvecfree( vals ); 79 vals = NULL; 80 continue; 81 } (gdb) p (*vals)->bv_val $5 = 0x8411038 "(targetattr = \"*\") (version 3.0;acl \"full access to all by all\";allow (all)(userdn = \"ldap:///anyone\");)\n" The collation plugin is again to opaque for me to quite get how I'm meant to handle this... My plugin in attached. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: bitwise.c Type: text/x-csrc Size: 6805 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: