Help wanted: Parse and import the LDAP display specifiers

[Andrew Kroeger]

All:

I am re-sending this e-mail without the huge attachment that adds the 
MS-provided LDIF files to the source tree, as suggested by abartlet. 
The sheer size of the LDIF files (even when bzipped) got stuck in the 
samba-technical mailing list moderation queue.

As the bulk of the original attachment was the original files sent by 
MS, and my patchset includes a patch to make the files more 
ldif-compliant, I am attaching the remaining patches to this e-mail. 
These patches are dependent on the MS-provided LDIF files being added 
under the source4/setup/display-specifiers/ directory.  The patch that I 
created to do this can be pulled from the display-specifiers branch in 
the git://github.com/id10ts/samba.git repo, as commit 
1249d1036158c4c8bb21f3600f0e8fa354657a65.

After the MS-provided LDIF files have been added in the appropriate 
location, the remaining patches in this e-mail can be applied.

---

All:

Please find attached a set of patches to massage the MS-supplied display 
specifiers and import them as part of the provision.  The patches are 
also available in the display-specifiers branch at 
git://github.com/id10ts/samba.git.

Andrew Bartlett wrote:
> On Wed, 2009-09-02 at 10:24 +0530, Sreepathi Pai wrote:
>> On Wed, Sep 2, 2009 at 7:57 AM, Andrew Bartlett<abartlet at samba.org> wrote:
>>
>>> I wondered if you (or someone else on the list) would like to do the
>>> same with the display specifiers?
>> Sure. I had a look at them at them, and they're in much better shape
>> the schema files! In fact, I was wondering if:
>>
>> * commenting the license text at the top
>> * possibly removing  "changetype: add" from each entry, and
>> * replacing <configuration NC Distinguished Name> with ${CONFIGDN}
>>
>> would do the job? 
> 
> I think so.  And then just having that processing as part of the
> provision, like the schema. 

I added all 5 files sent by Microsoft under setup/display-specifiers/, 
but I import the latest W2K8R2 file (DisplaySpecifiers-Win2k8R2.txt) 
during the provision.

Using the ms_schema.py file as a template, there were a few more changes 
made in addition to what Sreepathi mentioned above:

- I removed some transformations that were only needed for the schema 
(e.g. bit fields and multivalued attribute processing).
- I added the capability to properly parse and output base64-encoded values.
- I removed some attributes that are automatically handled internally by 
Samba and were either not present or were explicitly removed from 
display_specifiers.ldif (e.g. distinguishedName, instanceType, name, 
objectCategory, and (if set to the default of TRUE) showInAdvancedViewOnly).

>> As far as I can tell, there are no fields which
>> require pre-processing like in the AD Schema (e.g.  systemFlags or
>> systemFlagsEx which had to be converted from their constant names to
>> their constant values). They've used the numeric values directly here.
> 
> Excellent.  I did think it looked like an easier task. 
> 
>> I've only had a quick look and can only look at this closely over the
>> weekend (sorry!). Do let me know if you try out the above and whether
>> it works or not.
> 
> That would be great!
> 
> Andrew Bartlett

I verified the changes using an English version of Windows and also made 
sure that "make test" behaved the same after the changes.  I do not have 
a non-English Windows version to test with, but I did verify the 
internationalized strings display (although I don't know exactly what 
they say) using an LDAP browser under Windows to view some of the values 
under other languages.  I would appreciate if someone could verify that 
everything displays as expected in a non-English version of Windows.

There is one outstanding issue relating to the licensing of the new 
ms_display_specifiers.py script I made as a derivative of Sreepathi's 
ms_schema.py script.  I added a GPL3+ disclaimer to the top of the new 
script.  Sreepathi, could you please explicitly confirm that placing 
that license disclaimer on a derivative of your work is OK, or could 
someone with better licensing knowledge confirm that what I am doing is 
OK in terms of the Samba license?  I have no problems removing the 
license disclaimer from the file if there are problems, but I would 
prefer including an explicit license statement if possible.

Sincerely,
Andrew Kroeger

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0002-s4-setup-Change-license-headers-to-LDIF-comments.patch
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20090906/5b30015d/attachment.ksh>