From Doug.Leavitt at Sun.COM Wed Sep 12 10:39:06 2007 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Wed, 12 Sep 2007 12:39:06 -0500 Subject: [Duckwater-discuss] post CR 6557371 re-merge complete and pushed Message-ID: <46E8243A.2050001@sun.com> FYI, I've completed the merge of Igor's CR 6557371 conflict resolution, and pushed out the updated tree to the duckwater-hg gate. I'm currently kicking off a test x86 build, prior to the time when the automatic builds are kicked off. I plan to push the next full auto build through DIY PIT for to double check that all is well. Doug. From Doug.Leavitt at Sun.COM Tue Sep 18 06:47:43 2007 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Tue, 18 Sep 2007 08:47:43 -0500 Subject: [Duckwater-discuss] [sysadmin-discuss] passwd to ldap In-Reply-To: References: Message-ID: <46EFD6FF.6010607@sun.com> Yes, ldapaddent is the tool to use in this situation. The Duckwater project is currently updating the configuration components of naming services, including LDAP and ldapaddent. The updated ldapaddent will function in any environment (IE while running NIS or other) to populate/update the DS, not just in the LDAP environment [as it does today]. We are working now to complete testing so that we can distribute a second alpha drop on the duckwater to show our progress. the duckwater project is located here: http://www.opensolaris.org/os/project/duckwater/ Doug. Peter Tribble wrote: > On 9/17/07, Artur Baruchi wrote: >> Hi Guys, >> >> Im installing the LDAP, and I would like to know if exist a tool or a >> script to migrate my users (from the shadow file and passwd file) to >> my ldap database. >> >> If it exists, can someone send me more information about it. > > Isn't that what ldapaddent is for? It's what I've used whenever I've > had the misfortune to go near LDAP. > From Doug.Leavitt at Sun.COM Tue Sep 18 07:14:43 2007 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Tue, 18 Sep 2007 09:14:43 -0500 Subject: [Duckwater-discuss] [sysadmin-discuss] passwd to ldap In-Reply-To: <5b5090780709180653t5b14cbf0mfc76f82139d5e023@mail.gmail.com> References: <46EFD6FF.6010607@sun.com> <5b5090780709180653t5b14cbf0mfc76f82139d5e023@mail.gmail.com> Message-ID: <46EFDD53.4050101@sun.com> LDAP naming services is designed to be LDAP server neutral/agnostic. The "client components" are supported using any server that meets the requirements LDAP V3, VLV etc. as discussed in the documentation. We mainly test using JES DS (5/6) because that is the limit of our engineering/testing resources. We know that LDAP naming is/has been used on JES, OpenLDAP, Novell, [IIRC IBM], and AD DS servers. Since Redhat/Netscape & JES were once the same code base, there should be no issue there either. The idsconfig tool was designed for use with the iPlanet/JES DS 5.x series and has since been modified for better work with JES DS6.x. [We also have some additional mods for DS 6.x in duckwater that haven't made it to OpenSolaris/Solaris yet]. The original purpose of idsconfig was to help setup the DS 5.x because DS 5.x was delivered into the Solaris WOS in Solaris 9. The DS was pulled from the Solaris WOS, essentially, because the delivery schedules [trains] between the two product lines [JES & Solaris] didn't work well together. JES deliveries tend to update much more rapidly than Solaris update releases so it was hard to keep them in sync on the same CD/DVD set. When the DS was removed, idsconfig did not go with it. The naming team currently does not have enough ongoing engineering/testing resources to devote to updating idsconfig to support other LDAP servers [like OpenLDAP] (and test those configurations on a regular basis) so it has not been extended, or revised to support other DSs. We do have some ideas/plans to make idsconfig a little more generic so it can help more. Doug. Brandorr wrote: > Is there a recommended LDAP server for use with OpenSolaris? Here are > the options: http://kkalev.wordpress.com/2007/03/14/open-source-ldap-servers-battle/ > > -Brian > > On 9/18/07, Doug Leavitt wrote: >> Yes, ldapaddent is the tool to use in this situation. >> >> The Duckwater project is currently updating the configuration >> components of naming services, including LDAP and ldapaddent. >> >> The updated ldapaddent will function in any environment >> (IE while running NIS or other) to populate/update the DS, >> not just in the LDAP environment [as it does today]. >> >> We are working now to complete testing so that we can distribute >> a second alpha drop on the duckwater to show our progress. >> >> the duckwater project is located here: >> >> http://www.opensolaris.org/os/project/duckwater/ >> >> Doug. >> >> >> >> Peter Tribble wrote: >>> On 9/17/07, Artur Baruchi wrote: >>>> Hi Guys, >>>> >>>> Im installing the LDAP, and I would like to know if exist a tool or a >>>> script to migrate my users (from the shadow file and passwd file) to >>>> my ldap database. >>>> >>>> If it exists, can someone send me more information about it. >>> Isn't that what ldapaddent is for? It's what I've used whenever I've >>> had the misfortune to go near LDAP. >>> >> _______________________________________________ >> sysadmin-discuss mailing list >> sysadmin-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss >> > > From Doug.Leavitt at Sun.COM Tue Sep 18 08:46:22 2007 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Tue, 18 Sep 2007 10:46:22 -0500 Subject: [Duckwater-discuss] [sysadmin-discuss] passwd to ldap In-Reply-To: <5b5090780709180806o7e9e5585te2627c5b60030b9f@mail.gmail.com> References: <46EFD6FF.6010607@sun.com> <5b5090780709180653t5b14cbf0mfc76f82139d5e023@mail.gmail.com> <46EFDD53.4050101@sun.com> <5b5090780709180806o7e9e5585te2627c5b60030b9f@mail.gmail.com> Message-ID: <46EFF2CE.10106@sun.com> One of the mandates PSARC has imposed before we can remove NIS+ from the system is to supply an LDAP server into the WOS. At the moment, all of the other naming services [NIS/NIS+/DNS] have both a client and server component. iPlanet/JES DS was originally expected to meet that requirement for LDAP. Before we can go back to PSARC to submit the EOF removal project for NIS+ [The project that actually removes the NIS+ packages from Solaris] we need to show that LDAP has replaced NIS+ as a naming service and we have to have a server delivered into the WOS. Our focus at the moment is the first effort. One of the main purposes for the work we are doing in Sparks/Duckwater/Winchester/Reno is to update naming services, and correct problems with LDAP so as to show that LDAP is a viable backend, viable replacement for NIS+ AND that our customers who are dependent upon NIS+ have moved off, or are actively doing so with no issues. At the EOF announcement of NIS+ about 6% of our customer base depended upon NIS+ as compared to < 2% for LDAP. We need to show that those numbers are approaching 0% for NIS+ and that the customer base base/is actively moving to LDAP before we can return to PSARC to request removal of NIS+. So, our first focus is to get LDAP right. That includes fixing the framework and performance issues {sparks}, the approachability issues [like not being able to test a configuration before you covert a machine or not being able to run ldapaddent from a NIS box, administration, auto configuration etc] {duckwater} and interoperability with other LDAPs/schema [IE AD interoperability] {Winchester}. Other items on our plate include making LDAP naming services libldap independent [so we can make it easier to us and others to update/swap out/replace libldap. The code currently depends on our Solaris version of Mozilla's libldap.so.5], and of course delivering an LDAP server. I suspect by the time we complete the higher priority items on the list, we will be able to make a clear decision how to deliver a server back into the WOS and which one it would be. I see a lot of variables at the moment. There are multiple choices: JES DS, Open DS, OpenLDAP... and there are things like Indiana being worked on which will affect a decision. Personally I would first like to see both the libldap providers [OpenLDAP/Mozilla/other?] to sit down and hash out a single unified common API and/or merge into a single library for all open source platforms. That would fix a lot of issues and make easier for all applications to interoperate. In LDAP currently people code and test to a specific libldap library. Unlike other parts of POSIX/UNIX/Linux where people code to a set of APIs (IE libc...) I also think that Indiana will help us build distributions so that OpenSolaris can deliver one or more LDAP DS servers depending on customer needs. Today I see the different DS choices meeting the needs of different customers. Depending on what I was trying to do, I would probably deploy OpenLDAP sometimes and Open DS or JES in other situations. I think Indiana will allow us to let the customer/deployer choose based on their needs/requirements assuming the packaging/distribution and other issues are resolved by Indiana. Doug. Brandorr wrote: > Do you see any chance of incorporating a DS back into OpenSolaris? I > think OpenDS in particular looks very interesting. > > -Brian > > On 9/18/07, Doug Leavitt wrote: >> LDAP naming services is designed to be LDAP server neutral/agnostic. >> The "client components" are supported using any server that meets the >> requirements LDAP V3, VLV etc. as discussed in the documentation. >> >> We mainly test using JES DS (5/6) because that is the limit of our >> engineering/testing resources. >> >> We know that LDAP naming is/has been used on JES, OpenLDAP, Novell, >> [IIRC IBM], and AD DS servers. Since Redhat/Netscape & JES were once the >> same code base, there should be no issue there either. >> >> The idsconfig tool was designed for use with the iPlanet/JES DS 5.x series >> and has since been modified for better work with JES DS6.x. [We also have >> some additional mods for DS 6.x in duckwater that haven't made it to >> OpenSolaris/Solaris yet]. The original purpose of idsconfig was to help >> setup the DS 5.x because DS 5.x was delivered into the Solaris WOS in >> Solaris 9. The DS was pulled from the Solaris WOS, essentially, because the >> delivery schedules [trains] between the two product lines [JES & Solaris] >> didn't work well together. JES deliveries tend to update much more rapidly >> than Solaris update releases so it was hard to keep them in sync on the >> same CD/DVD set. >> >> When the DS was removed, idsconfig did not go with it. The naming team >> currently does not have enough ongoing engineering/testing resources to >> devote to updating idsconfig to support other LDAP servers [like OpenLDAP] >> (and test those configurations on a regular basis) so it has not been extended, >> or revised to support other DSs. >> >> We do have some ideas/plans to make idsconfig a little more generic so it >> can help more. >> >> Doug. >> >> >> Brandorr wrote: >>> Is there a recommended LDAP server for use with OpenSolaris? Here are >>> the options: http://kkalev.wordpress.com/2007/03/14/open-source-ldap-servers-battle/ >>> >>> -Brian >>> >>> On 9/18/07, Doug Leavitt wrote: >>>> Yes, ldapaddent is the tool to use in this situation. >>>> >>>> The Duckwater project is currently updating the configuration >>>> components of naming services, including LDAP and ldapaddent. >>>> >>>> The updated ldapaddent will function in any environment >>>> (IE while running NIS or other) to populate/update the DS, >>>> not just in the LDAP environment [as it does today]. >>>> >>>> We are working now to complete testing so that we can distribute >>>> a second alpha drop on the duckwater to show our progress. >>>> >>>> the duckwater project is located here: >>>> >>>> http://www.opensolaris.org/os/project/duckwater/ >>>> >>>> Doug. >>>> >>>> >>>> >>>> Peter Tribble wrote: >>>>> On 9/17/07, Artur Baruchi wrote: >>>>>> Hi Guys, >>>>>> >>>>>> Im installing the LDAP, and I would like to know if exist a tool or a >>>>>> script to migrate my users (from the shadow file and passwd file) to >>>>>> my ldap database. >>>>>> >>>>>> If it exists, can someone send me more information about it. >>>>> Isn't that what ldapaddent is for? It's what I've used whenever I've >>>>> had the misfortune to go near LDAP. >>>>> >>>> _______________________________________________ >>>> sysadmin-discuss mailing list >>>> sysadmin-discuss at opensolaris.org >>>> http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss >>>> >>> > > From Doug.Leavitt at Sun.COM Thu Sep 20 15:06:17 2007 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Thu, 20 Sep 2007 17:06:17 -0500 Subject: [Duckwater-discuss] 9/19 summary testing Message-ID: <46F2EED9.70308@sun.com> DIY PIT is still not up, but I've been manually running tests all day on 3 boxes using the bits from the 9/19 build based on the post xVM putback. Everything seems to be reasonable. I've run most everything except nss2 only because STEP seems to not be setting up properly with nss2. I've successfully run the basics: svvs, ddivs, nss_*, ldap*, libsldap* part of mstc (I'm running it all now) vs* and other things. I've also resynced and reenabled automatic re-syncing now that the gate is clean again, and I'm rebuilding as well. Will continue testing. Once we have summary from nss2 I think we will be good to put together a fresh alpha bfu. I will start DIY PIT when it is available... Doug.