Hi all, as promised, I explored the options we have concerning Samba 3.4 x Mozilla LDAP 6 C SDK. As you can see below there is currently no ideal solution and a compromise will be needed. From the business point of view we really would like to be able to put Samba 3.4 to S10U9 -- we are already getting requests for interoperability with Windows 7, [1] and again the answer is Samba 3.4.
Here is a list of options, which were discussed off-channel -- any feedback is welcome: 1) Leave the PSARC case as it is and ask PSARC members for the vote and opinion as mentioned by Darren. This is currently the preferred option by the I-team. 2) Use OpenLDAP, which is already integrated in Nevada and use Mozilla LDAP 6 C SDK as Samba's private component in S10. This will have a clear disadvantage of having different Samba's in S10 and Nevada. Any LDAP related issue will have to be solved separately for Nevada and S10 and the maintenance cost will increase. 3) Mark the Mozilla LDAP 6 C SDK a "public" component in Nevada. Jiri can still help with the integration but we will need a commitment from the Naming folks that they will support this component (at least on level C). The LDAP 6 C SDK still shall be Samba's private component in S10. However, based on the discussion with Naming engineers this would basically mean an LDAP C SDK update in Nevada, a separate PSARC case will be required and such solution will certainly take longer than the time frame we have for S10U9. Besides, we still may have a problem with getting resources from the Naming team to assist with this task. 4) Use OpenLDAP instead of Mozilla LDAP 6 C SDK. This will work in Nevada but will represent a problem for S10. As per the experiments performed by Jiri -- integration of OpenLDAP to S10 (as private Samba's component) is not trivial and this will also mean to integrate much bigger beast than just the LDAP C SDK. OpenLDAP is being changed rather often, so this will also bring an additional burden for the I-team to maintain it as part of Samba in S10. We will have a problem to find resources to do this work (both in terms of people and time). Regards, Lukas [1] http://monaco.sfbay.sun.com/detail.jsf?cr=6913134 Lukas Rovensky wrote: > Darren J Moffat wrote: >> Lukas Rovensky wrote: >>> I believe that all the new Mozilla LDAP 6 libraries should be marked >>> as "private" to Samba in this PSARC. Until there is a funding to >>> integrate and support them they cannot be "public". >> >> That is generally not the acceptable stance. In this particular case >> given the history of the Mozilla LDAP libraries in Solaris going back >> many more years I think this is even more unacceptable. >> >> The risk of having multiple versions of the LDAP libraries dragged >> into the same process (Samba in this case) is quite high. >> >> I strongly encourage the project team to find away so that the Mozilla >> LDAP 6 library is made common (ie a public taxonomy) for all to use - >> that doesn't mean supporting it themselves but working with the >> appropriate groups to do so. If the project can't do that then I feel >> I have to derail this case given the history of LDAP libraries in >> Solaris and the fact it has already been stated by RPE (Revenue >> Product Engineering) that they would rather see the Mozilla LDAP 6 >> library replace the current (hacked up) Mozilla LDAP 5. >> >> Remember that derail does not mean your case is rejected just that it >> needs a vote and ARC opinion. It may not even need a full review in >> this case since the issue isn't with the core architecture of Samba >> but an issue with a dependency. >> > Darren, > > I understand your concerns but your request is really out of scope of > Samba I-team responsibilities. Regardless, we actually tried several > times to get the Mozilla LDAP 6 C SDK integrated to Solaris as common > component but there was always someone who had objections to this. > > Anyway, I will try yet again to explore what are our options in this > space and get back to this forum in early January. However, I guess > that we will have to ask for the vote and ARC opinion to proceed with > this case as you explained. > > Just a note -- having up to data Samba in S10 is really about making > money and keeping our customers on Solaris. Old version of Samba in S10 > means more expensive support for us, lack of new features for customers > and represents a danger that some customers will walk away from Solaris. > > Lukas >
