Le 04/02/2017 à 02:14, Brian Burch a écrit : > <snip/> >> >> so you also have to change 'example' here, encoded it to base64 and >> store the result in the entry. > > So /THAT/ is why my first attempt apparently had no effect at all. I > cloned and renamed all the entries from config.ldif for "example" to > my own partition, but I had no idea ads-contextentry was so > significant, so I left it unchanged! > > I am surprised the default logging scheme did not reveal any error > messages when I restarted the server with the new bad set of config > entries for my new partition. Perhaps if I had increased logging I > would have seen the reason for my failure? Because this is not an error, as strange as it sounds :-)
If you install OpenLDAP, for instance, you won't have a contextEntry at all, you will have to add it :-) Actually, we added it for convenience (I always found it annoying that starting a fresh installed server does not expose anything, simply because the context Entry was missing). > >> You can add also any index you want. >> >> Last, not least, do not forget to restart the server. >> >> Ok, now, if you don't want to use Studio, then that is a PITA, and I >> think it would be a great service for users to provide a script that >> does that on teh command line... It should not be complex to add. > > I know I could un-base64 the ads-contextentry in my working partition, > but forgive me for being a bit lazy... > > Q: should I base64 those four attributes exactly as shown, i.e. with > single spaces, posix newlines, Latin-1 character set... or could I > just use some random base64 string which is unique to the specific > server instance? In other words, how strict are the validation rules > which failed during my first attempt. If you aren't sure, perhaps you > could point me somewhere near the appropriate area in the source code > and I'll work it out for myself. It has to be a valid LDIF file, encoded in base64. So newlines and spaces are significant. Funny enough, if there is some secial chars in your entry, then they should be base64 encoded *before* the entry can be base64 encoded itself. For instance : dn: cn=lécharny,dc=com ObjectClass: person cn: lécharny sn: Emmanuel Lécharny is not a valid cotext entry, because the 'é' is not accepted in a LDIF, so it should be : dn:: Y249bMOpY2hhcm55LGRjPWNvbQ== ObjectClass: person cn:: TMOpY2hhcm55 sn:: RW1tYW51ZWwgTMOpY2hhcm55 (note that encoded values are prefixed with '::' instead of ':'. This is a way to tell that the value is binary - or encoded... -) Now, you can base 64 encode the entry, which gives : ZG46OiBZMjQ5Yk1PcFkyaGhjbTU1TEdSalBXTnZiUT09DQpPYmplY3RDbGFzczogcGVyc29uDQpjbjo6IFRNT3BZMmhoY201NQ0Kc246OiBSVzF0WVc1MVpXd2dUTU9wWTJoaGNtNTU= Now, if we add a '\n' at the end of this entry, the result will be different : ZG46OiBZMjQ5Yk1PcFkyaGhjbTU1TEdSalBXTnZiUT09DQpPYmplY3RDbGFzczogcGVyc29uDQpjbjo6IFRNT3BZMmhoY201NQ0Kc246OiBSVzF0WVc1MVpXd2dUTU9wWTJoaGNtNTUNCg== You can trim the entry to have a limited number of char per line, but a continued line must start with a space. For instance : dn: dc=example,dc =com ObjectClass: doma in dc=example will work. -- Emmanuel Lecharny Symas.com directory.apache.org
