Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard One problem with back-config is that comments in slapd.conf are lost when converting to cn=config, and cn=config does not offer attributes in which to put comments. So I suggest: Add something like 'MAY ( description $ info )' to object class olcConfig, and slapd.conf keywords with the same name. description to describe the slapd entry, info for other notes about it. The slapd.conf keywords would allow admins to "upgrade" most comments in slapd.conf before converting to cn=config. They'll need to insert any context into the comments though, and preferably move frontend directives with comments in slapd.conf to an explicit frontend database. I think it'd be best if these attribute names do not have a prefix like "olc", so they'll stand out a bit from the rest. Thus the suggestion to stick to preexisting RFCed attributes. However the attribute for general notes ('info') should probably be treated as X-ORDERED 'VALUES', I haven't checked if it's inconvenient to do that with a preexisting attribute without that feature. The valsort overlay does, but I don' suggest to require valsort.
moved from Incoming to Software Enhancements
h.b.furuseth@usit.uio.no wrote: > One problem with back-config is that comments in slapd.conf > are lost when converting to cn=config, and cn=config does > not offer attributes in which to put comments. So I suggest: > > Add something like 'MAY ( description $ info )' to object class > olcConfig, and slapd.conf keywords with the same name. description > to describe the slapd entry, info for other notes about it. > > The slapd.conf keywords would allow admins to "upgrade" most comments in > slapd.conf before converting to cn=config. They'll need to insert any > context into the comments though, and preferably move frontend directives > with comments in slapd.conf to an explicit frontend database. > > I think it'd be best if these attribute names do not have a prefix > like "olc", so they'll stand out a bit from the rest. Thus the > suggestion to stick to preexisting RFCed attributes. However the > attribute for general notes ('info') should probably be treated as > X-ORDERED 'VALUES', I haven't checked if it's inconvenient to do > that with a preexisting attribute without that feature. The valsort > overlay does, but I don' suggest to require valsort. The X-ORDERED flag obviously cannot be added to existing schema elements; you need to define a new attribute. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
hyc@symas.com writes: >h.b.furuseth@usit.uio.no wrote: >> However the attribute for general notes ('info') should probably be >> treated as X-ORDERED 'VALUES', I haven't checked if it's inconvenient >> to do that with a preexisting attribute without that feature. The >> valsort overlay does, but I don' suggest to require valsort. > > The X-ORDERED flag obviously cannot be added to existing schema > elements; That's why I said "treated as" X-ORDERED (when occurring in cn=config). If that's too cumbersome though: > you need to define a new attribute. An attribute private to OpenLDAP should have a prefix like "olc", but an RFCed attribute must wait till (X-)ORDERED is standardized. I suggest "olc-note", then. Still stands out from the rest since the others do not use hyphens, and also sorts it before the other "olc"s. -- Hallvard
The problem with adding an attribute is that this means that comments are per-entry, and cannot be associated with specific attribute values. Having to write comments on an entry that apply to a specific attribute value means having to describe the attribute's value within the comment. Most of my comments have to do with particular attribute values, so this would be awkward -- both for writer and reader. Below is an alternative design. It supports commenting both entries and attributes and working with commented ldif files in an "expected" way. The downside is that this design does not provide a "natural" user interface. Generic LDAP clients would not readily associate comment text with the entries or attributes commented. The OpenLDAP client tools would need to be used to produce and consume "commented ldif" files. No reason why this alternative design could not be implemented alongside the design previously proposed. Have a cn=comment,cn=config subtree. The dn is index=X,attribute=Y,EntryUUID=Z,cn=comment,cn=config. (Where index is the index of the commented attribute when an attribute is multi-valued.) Keep all the comments there. Index and attribute would be optional in the dn; when omitted the comment is on the entry. Pass a flag to ldapmodify and ldapadd so that comments are preserved on input, and a flag for ldapsearch to output such comments. The flag would only work on the cn=config DIT. Comments appearing in an ldif before a dn are attached to the entry. Comments appearing before an attribute are attached to the attribute.
Here are portions of a current slapd.conf file to provide some idea of the comments that "need" preserving. (Note also the use of newlines and whitespace to make values readable. But that's another enhancement request.) This config applies to a very dated version of openldap. While one might want to argue that documentation on, say, creating a crypted password, belongs elsewhere, the only time anyone needs to make a crypted password was to edit this config file. So why have a separate document? include /etc/openldap/schema/core.schema # Cosine is the X500 telephone schema, but we need attributes in there include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema # We don't want nis, but we do need it's attributes include /etc/openldap/schema/nis.schema #include /etc/openldap/schema/redhat/rfc822-MailMember.schema #include /etc/openldap/schema/redhat/autofs.schema #include /etc/openldap/schema/redhat/kerberosobject.schema # Here's where inetMailRecipient is defined include /etc/openldap/schema/misc.schema # TROW specific stuff include /etc/openldap/schema/trow.schema # PWM specific stuff include /etc/openldap/schema/pwm.schema # eduPerson include /etc/openldap/schema/eduperson.schema # Amavisd-new stuff include /etc/openldap/schema/amavisd-new.schema TLSCipherSuite !ADH:MEDIUM:HIGH:!SSLv2:@STRENGTH # # The next three lines allow use of TLS for connections using a dummy test # certificate, but you should generate a proper certificate by changing to # /usr/share/ssl/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. # # Used the procedure below (openssl-0.9.6b-35.7) to make a # self-signed certificate for trixie.trow.com rsa key 1024 bits, expires # 365 days from Jul 23, 2003. (Karl) # #TLSCACertificateFile /var/openssl/demoCA/cacert.pem #TLSCertificateFile /etc/openldap/ssl.crt/trixie.crt #TLSCertificateKeyFile /etc/openldap/ssl.key/trixie-rsa-1024.key # # Self signed cert expires 2037. # TLSCertificateFile /etc/openldap/certificates/trixie-trow-com-cert.pem TLSCertificateKeyFile /etc/openldap/certificates/trixie-trow-com-key.pem # Nice as it is to be logging, Sam, it uses up a lot of resources. # Turn off logging. # loglevel 0 # Log search filter processing, config file parsing, access control processing # (useful for debugging access rules) #loglevel 224 # Log configuration file parsing (and errors!) #loglevel 64 loglevel 256 # To generate a crypted password, try: # perl -e 'print("rootpw {crypt}" . crypt("secretpassword","sa") . "\n");' # "secretpassword" is the password, "sa" is the salt. # (FYI, the salt used in /etc/passwd is the first 2 chars of the # encrypted password.) # We should really be using something better than crypt # to protect our password database! #rootpw {crypt}elLJ3HpZEUmIA # # To generate a md5 password, try: # perl -e 'print("rootpw {crypt}" # . crypt("secretpassword", "\$1\$somesalt") # . "\n");' # (Yes, {crypt} is correct -- system crypt() call handles md5.) # "secretpassword" is the password, "$1$somesalt" is the salt. # (should be 8 chars in addition to the leading $1$). # (FYI, the salt used in /etc/shadow is from the beginning of the # encrypted password up to and including the third dollar sign. # In the program above, all dollar signs should be written with # a preceeding backslash.) # Slave server replication. (for this database) # (This is all probably unnecessary, because we're not making # dynamic changes to the datbase anyhow.) # # Um, we could use kerberos instead of having a plaintext password # here. I can't say for sure, but it occurs to me that the # kerberos keys can't be stored in the filesystem and protected # better than by simply makeing them unreadable to anybody but root. # As long as this file is only readable by root (and we're not # worried about network sniffing) this should be sufficient. # Need to turn this off in order to replicate to Openldap 2.3 and 2.4. # Operational attributes are blown away by oracle2ldap daily anyway. lastmod off # # Need to set a limit here as a lot of children accumulate over time # and they each use close to 50MB of RAM. 3/30/04 Sam # threads 20 defaultaccess none # Evaluated in order. # CAREFUL, collating sequence could mean weird < compares. # Give the standard sort of unix access. Everybody can read # most stuff, but can't see the password. (Besides, more restrictive # access doesn't work.) # Be persnickity and do some filtering. # (except that we're filtering them out when we load the database) # access to filter="(&(objectclass=posixaccount)(uid<1000))" none # access to filter="(&(objectclass=posixgroup)(memberuid<900))" none # Order of access controls is very important! First "access ..." match wins! # Without a <control> after the <who>, it's only <what> that determines # the match. # As many of the 2.1 rules use the "by * + break" construct it might # be possible to enhance performance by re-ordering the rules so that # the most common matches are done early, but care is in (*ahem*) order. # The uid of password maintainers _must_ be the primary uid! # Some programs use the rootdn (Manager) to obtain global read/write # access. The only problem with this is oracle2ldap, where # if the database gets changed while oracle2ldap has the # database in read-only mode, the changes will be lost when # the database is replaced with the new database. # # Shipinet and GADS need to read the entire DB. # At the top to speed things up as ACL processing is hugely inefficient in this # version of LDAP. # access to * by dn.exact="cn=shipinet,ou=Service,dc=trow,dc=com" read by dn.exact="cn=gadirsync,ou=Service,dc=trow,dc=com" read by * + break # # Allow any authenticated users to see the intrinsic root dn. # access to dn.base="" by users read by * + break # #Oracle Self Service # access to dn.subtree="ou=People,dc=trow,dc=com" attrs=entry,preferredUid,oraclePClass,oracleId,preferredEmail,gec os,cn by dn.exact="cn=selfservice,ou=Service,dc=trow,dc=com" read by * + break access to dn.subtree="ou=People,dc=trow,dc=com" attrs=objectClass by dn.exact="cn=selfservice,ou=Service,dc=trow,dc=com" search by * + break # # Other global access # # (This is not really necessary and slows things down a _mite_, but is kind.) # Shipinet does need these -- I think. access to dn="^dc=trow,dc=com$" by * read # # Control access to the Service branch of the ldap database. # # Allow the "syscheck" service to read itself. access to dn.base="cn=syscheck,ou=Service,dc=trow,dc=com" by self read by * + break # PWM LDAP connection health checks. # Remove 'pwmGUID' once the three instances are using their own GUID attrs. access to dn.regex="^cn=pwmhealth[^,]*,ou=Service,dc=trow,dc=com$" attrs=entry,userPassword,pwmGUID,pwmLiveGUID,pwmTestGUID,pwmDevGUID by dn.exact="cn=pwm,ou=Service,dc=trow,dc=com" write by * + break access to dn.regex="^cn=pwmhealth[^,]*,ou=Service,dc=trow,dc=com$" by dn.exact="cn=pwm,ou=Service,dc=trow,dc=com" read by * + break # Apparently PWM needs to read its own objectClasses. access to dn.base="cn=pwm,ou=Service,dc=trow,dc=com" attrs=entry,objectClass by self read by * + break # Folks in Network Services can write, service DNs can bind. access to dn.subtree=ou=Service,dc=trow,dc=com by dn.exact="uid=swilson,ou=People,dc=trow,dc=com" write by dn.exact="uid=jswan,ou=People,dc=trow,dc=com" write by dn.exact="uid=fdavidson,ou=People,dc=trow,dc=com" write by anonymous auth # # Contral access to the group branch. # access to dn.subtree="ou=Group,dc=trow,dc=com" by dn.exact="cn=nss_ldap,ou=Service,dc=trow,dc=com" read by dn.exact="uid=swilson,ou=People,dc=trow,dc=com" write by dn.exact="uid=jswan,ou=People,dc=trow,dc=com" write by dn.exact="uid=fdavidson,ou=People,dc=trow,dc=com" write by * compare # # The rest of this is access to the People branch. # # # Binding # # These access lists disable binding to subsets of the directory. # # Accounts must be active for the user to bind. # # When firstActivated is missing, the account's not yet activated. # If the deactivated attribute is present then the account's # been deactivated. access to dn.subtree="ou=People,dc=trow,dc=com" filter=(|(!(firstActivated=*))(deactivated=*)) attrs=entry by anonymous none by * + break # # Configure the Service dn-s access to the People subtree. # # Try to put services that need to sync with LDAP, thus reading the whole direct ory (or a large # part) as near the top of this section as possible, as complex ACL processing a gainst a large # number of entries degrades performance substantially. # # Uniflow printing system. # access to dn.subtree="ou=People,dc=trow,dc=com" filter=(&(objectClass=AICPerson)(firstActivated=*)(!(deactivated=*))) attrs=entry,preferredUid,preferredEmail,organizationalStatus,gecos,consti tuency,objectClass,telephoneNumber,AICDepartment by dn.exact="cn=uniflow,ou=Service,dc=trow,dc=com" read by * + break # # nss_ldap (the glibc library and pam) # # (objectclass could probably be just search, or we could take the objectclass # filter out of /etc/ldap.conf and add the filter here and allow no access # to objectclass.) access to dn.subtree="ou=People,dc=trow,dc=com" attrs=dn,entry,cn,uid,uidNumber,gidNumber,homeDirectory,userPassword,logi nShell,gecos,description,shadowLastChange,shadowMin,shadowMax,shadowWarning,shad owInactive,shadowExpire,shadowFlag,description,objectclass,preferredUid,makeWWW, useEmail,useDialup,firstActivated,deactivated by dn.exact="cn=nss_ldap,ou=Service,dc=trow,dc=com" read by * + break # # postfix (mail mta, really just some of it's various processes) # access to dn.subtree="ou=People,dc=trow,dc=com" attrs=dn,entry,cn,uid,uidNumber,gidNumber,homeDirectory,gecos,mailrouting address,maillocaladdress,preferredemail,rejectMail by dn.exact="cn=postfix,ou=Service,dc=trow,dc=com" read by * + break