From Doug.Leavitt at Sun.COM Tue Mar 4 15:05:18 2008 From: Doug.Leavitt at Sun.COM (Doug.Leavitt at Sun.COM) Date: Tue, 4 Mar 2008 15:05:18 -0800 (PST) Subject: [Duckwater-discuss] draft 0.5 finder/nss-finder Message-ID: <20080304230518.3AB9311125F@mail.opensolaris.org> Author: Doug Leavitt Repository: /hg/duckwater/duckwater-docs Latest revision: 5900ad951206368bf26aa7463c3fe070e5e8f638 Total changesets: 1 Log message: draft 0.5 finder/nss-finder Files: create: finder/nss-finder.rst From Doug.Leavitt at Sun.COM Tue Mar 4 15:13:09 2008 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Tue, 04 Mar 2008 17:13:09 -0600 Subject: [Duckwater-discuss] Draft 0.5 of the finder APIs posted Message-ID: <47CDD785.1000809@sun.com> The rst version is in the duckwater-docs hg gate. The drafts is posted to the Duckwater documentation page. this draft reflects the current code base in duckwater-hg. Comments always appreciated. Doug. From Tomas.Heran at Sun.COM Wed Mar 5 05:06:27 2008 From: Tomas.Heran at Sun.COM (Tomas.Heran at Sun.COM) Date: Wed, 5 Mar 2008 05:06:27 -0800 (PST) Subject: [Duckwater-discuss] Updated diagrams to reflect how nss_ldap.so.1 accesses configuration Message-ID: <20080305130627.990E3100C4E@mail.opensolaris.org> Author: Tomas Heran Repository: /hg/duckwater/duckwater-docs Latest revision: 5833768270ec3004164fb495d3f6141616816757 Total changesets: 1 Log message: Updated diagrams to reflect how nss_ldap.so.1 accesses configuration Files: update: diagrams/duckwater-config-access.graffle update: diagrams/duckwater-config-access.pdf update: diagrams/duckwater-config-create.graffle update: diagrams/duckwater-config-create.pdf From Doug.Leavitt at Sun.COM Wed Mar 5 08:31:53 2008 From: Doug.Leavitt at Sun.COM (Doug.Leavitt at Sun.COM) Date: Wed, 5 Mar 2008 08:31:53 -0800 (PST) Subject: [Duckwater-discuss] extendable -> extensible, formatting fix Message-ID: <20080305163153.D3A1A1099F7@mail.opensolaris.org> Author: Doug Leavitt Repository: /hg/duckwater/duckwater-docs Latest revision: 786f87c97e3af0c3771e94999bdbb52ac7ffd53c Total changesets: 1 Log message: extendable -> extensible, formatting fix Files: update: finder/nss-finder.rst From Doug.Leavitt at Sun.COM Wed Mar 5 08:44:25 2008 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Wed, 05 Mar 2008 10:44:25 -0600 Subject: [Duckwater-discuss] finder page revised Message-ID: <47CECDE9.5010203@sun.com> I made a few minor corrections. http://www.opensolaris.org/os/project/duckwater/Documentation/finder/ has been revised to match the docs page. The original versioning page: http://www.opensolaris.org/os/project/duckwater/Documentation/nssversion/ has been revised to be the PSARC/2008/035 page. Doug. From Tomas.Heran at Sun.COM Mon Mar 10 10:09:26 2008 From: Tomas.Heran at Sun.COM (Tomas.Heran at Sun.COM) Date: Mon, 10 Mar 2008 10:09:26 -0700 (PDT) Subject: [Duckwater-discuss] Updated NSS module config APIs doc. Message-ID: <20080310170926.EFDFB3B834@mail.opensolaris.org> Author: Tomas Heran Repository: /hg/duckwater/duckwater-docs Latest revision: c652795b5535a5028eb15ae249db1baae6e5ddd9 Total changesets: 1 Log message: Updated NSS module config APIs doc. Updates to libnsconf API Files: update: design/dw-libnsconf.rst update: design/dw-nss_module-cfgapi.rst From Tomas.Heran at Sun.COM Mon Mar 10 10:18:01 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Mon, 10 Mar 2008 18:18:01 +0100 Subject: [Duckwater-discuss] Updated NSS module config APIs doc. In-Reply-To: <20080310170926.EFDFB3B834@mail.opensolaris.org> References: <20080310170926.EFDFB3B834@mail.opensolaris.org> Message-ID: <47D56D49.1040205@sun.com> I've update the NSS Config APIs design document. The URL of the updated document on opensolaris.org is here: http://opensolaris.org/os/project/duckwater/Documentation/nssconfig/ As always - review/comments/ideas/etc. would be much appreciated. Thanks, Tomas Tomas.Heran at Sun.COM wrote: > Author: Tomas Heran > Repository: /hg/duckwater/duckwater-docs > Latest revision: c652795b5535a5028eb15ae249db1baae6e5ddd9 > Total changesets: 1 > Log message: > Updated NSS module config APIs doc. > Updates to libnsconf API > > > Files: > update: design/dw-libnsconf.rst > update: design/dw-nss_module-cfgapi.rst > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss From igor.zymin at sun.com Fri Mar 14 07:05:59 2008 From: igor.zymin at sun.com (igor.zymin at sun.com) Date: Fri, 14 Mar 2008 07:05:59 -0700 (PDT) Subject: [Duckwater-discuss] man-pages update Message-ID: <20080314140602.64416124E8C@mail.opensolaris.org> Author: iz202018 Repository: /hg/duckwater/duckwater-docs Latest revision: 75559254875bbbb1bef609b7381e5d534f2356f9 Total changesets: 1 Log message: man-pages update Files: create: manpages/ldap_cachemgr.diffs create: manpages/ldapaddent.diffs create: manpages/ldaplist.diffs update: manpages/ldapaddent.txt update: manpages/ldaplist.txt update: manpages/nscfg.txt From Chin-Long.Shu at Sun.COM Fri Mar 14 08:11:31 2008 From: Chin-Long.Shu at Sun.COM (Chin-Long Shu) Date: Fri, 14 Mar 2008 10:11:31 -0500 Subject: [Duckwater-discuss] subscribe Message-ID: <47DA95A3.9000806@Sun.COM> From Tomas.Heran at Sun.COM Mon Mar 17 08:08:31 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Mon, 17 Mar 2008 16:08:31 +0100 Subject: [Duckwater-discuss] Updated diagrams Message-ID: <47DE896F.8090104@sun.com> Attached are the two updated Duckwater diagrams. I simplified the "color-coding" to make it easier to read even when printed on B/W printer. Comments? Thanks, Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: duckwater-config-create.pdf Type: application/pdf Size: 92594 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: duckwater-config-access.pdf Type: application/pdf Size: 81417 bytes Desc: not available URL: From Tomas.Heran at Sun.COM Wed Mar 19 09:59:21 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Wed, 19 Mar 2008 17:59:21 +0100 Subject: [Duckwater-discuss] Enabling NS profile Message-ID: <47E14669.4040106@sun.com> Yesterday Doug and I and later Nico and I had a phone discussions about DW profiles etc. and one of things we agreed needs more thought (and possible changes) is the actual enabling of given profile. [01] Maybe "enabling" the profile isn't the right thing. Maybe rather "installing" it to a "current active profile" location would be better. [02] nsadm(1M) maybe shouldn't have privilege to do the actual work of enabling profile (making the property values changes, enabling/disabling back-end services etc.). Maybe it should just notify nscd(1M) (which will have those privileges) to the work. Doug, Nico - please correct me, or fill in more details, if I misinterpreted, misunderstood or simply left out anything. Thanks, Tomas From Doug.Leavitt at Sun.COM Wed Mar 19 11:00:37 2008 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Wed, 19 Mar 2008 13:00:37 -0500 Subject: [Duckwater-discuss] Enabling NS profile In-Reply-To: <47E14669.4040106@sun.com> References: <47E14669.4040106@sun.com> Message-ID: <47E154C5.5020500@sun.com> As I recall, from the previous design discussions and agreements with the sparks team: nsadm needs to verify that the user executing the nsadm command has the appropriate (RBAC) authority to run the command, and enable a previously created profile. The piece of the puzzle that seems to be missing from the most recent diagrams, but has been previously described in the one pager and other design documentation is the nsutil tool. From our previous agreements, nsadm triggered the execution of nsutil [or triggered a signal to a nsutil daemon], which was the actual code responsible for coordinating with nscd and the backend code. 1. nsutil is supposed to trigger nscd to complete "in progress" requests and go into a stable enable files only mode 2. it was then supposed it enable and disable backend services via nsconf and the nss_* backend APIs 3. then resignal nscd to re-initialize the switch to the new configuration I agree that nscd was not supposed to do the actual work of switching the smf profiles around. This was a limitation/defect of the previous alpha duckwater delivery We also previously agreed it was not to be done in nscd, because it would unnecessarily complicate nscd internal organization. The previous agreement was for the nsutil tool to do this. Please review the one-pager and previous older materials. Note: nsutil seems to be incorrectly missing from the current diagrams? It's definition seems to be missing from some of the newer revisions as well. I can't find any e-mails or other that point to this decision being changed. I can find older references in some of the previous revisions of the design documents in the various documentation gates and previous emails. Doug. Tomas Heran wrote: > Yesterday Doug and I and later Nico and I had a phone discussions about > DW profiles etc. and one of things we agreed needs more thought (and > possible changes) is the actual enabling of given profile. > > [01] Maybe "enabling" the profile isn't the right thing. Maybe rather > "installing" it to a "current active profile" location would be > better. > > [02] nsadm(1M) maybe shouldn't have privilege to do the actual work of > enabling profile (making the property values changes, > enabling/disabling back-end services etc.). Maybe it should just > notify nscd(1M) (which will have those privileges) to the work. > > Doug, Nico - please correct me, or fill in more details, if I > misinterpreted, misunderstood or simply left out anything. > > Thanks, > Tomas > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss From Doug.Leavitt at Sun.COM Wed Mar 19 11:04:47 2008 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Wed, 19 Mar 2008 13:04:47 -0500 Subject: [Duckwater-discuss] Enabling NS profile In-Reply-To: <47E154C5.5020500@sun.com> References: <47E14669.4040106@sun.com> <47E154C5.5020500@sun.com> Message-ID: <47E155BF.10505@sun.com> One correction. I do have email references to nsutil being a set of co-process threads inside nscd (from notes in a joint discussion we had on 11/13/07). My error. We will need to clarify this before we proceed to inception. Doug. Doug Leavitt wrote: > As I recall, from the previous design discussions and agreements with > the sparks team: > > nsadm needs to verify that the user executing the nsadm command > has the appropriate (RBAC) authority to run the command, and > enable a previously created profile. > > The piece of the puzzle that seems to be missing from the most recent > diagrams, but has been previously described in the one pager and > other design documentation is the nsutil tool. > > From our previous agreements, nsadm triggered the execution of > nsutil [or triggered a signal to a nsutil daemon], which was the actual code > responsible for coordinating with nscd and the backend code. > > 1. nsutil is supposed to trigger nscd to complete "in progress" requests > and go into a stable enable files only mode > 2. it was then supposed it enable and disable backend services via nsconf > and the nss_* backend APIs > 3. then resignal nscd to re-initialize the switch to the new configuration > > > I agree that nscd was not supposed to do the actual work of > switching the smf profiles around. This was a limitation/defect of the > previous alpha duckwater delivery > > We also previously agreed it was not to be done in nscd, because it would > unnecessarily complicate nscd internal organization. > > The previous agreement was for the nsutil tool to do this. Please > review the one-pager and previous older materials. > > Note: nsutil seems to be incorrectly missing from the current diagrams? > It's definition seems to be missing from some of the newer revisions as well. > > I can't find any e-mails or other that point to this decision being changed. > I can find older references in some of the previous revisions of the > design documents in the various documentation gates and previous emails. > > Doug. > > Tomas Heran wrote: >> Yesterday Doug and I and later Nico and I had a phone discussions about >> DW profiles etc. and one of things we agreed needs more thought (and >> possible changes) is the actual enabling of given profile. >> >> [01] Maybe "enabling" the profile isn't the right thing. Maybe rather >> "installing" it to a "current active profile" location would be >> better. >> >> [02] nsadm(1M) maybe shouldn't have privilege to do the actual work of >> enabling profile (making the property values changes, >> enabling/disabling back-end services etc.). Maybe it should just >> notify nscd(1M) (which will have those privileges) to the work. >> >> Doug, Nico - please correct me, or fill in more details, if I >> misinterpreted, misunderstood or simply left out anything. >> >> Thanks, >> Tomas >> _______________________________________________ >> duckwater-discuss mailing list >> duckwater-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss From Tomas.Heran at Sun.COM Wed Mar 19 12:20:39 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Wed, 19 Mar 2008 20:20:39 +0100 Subject: [Duckwater-discuss] Enabling NS profile In-Reply-To: <47E154C5.5020500@sun.com> References: <47E14669.4040106@sun.com> <47E154C5.5020500@sun.com> Message-ID: <47E16787.3010104@sun.com> Doug Leavitt wrote: > As I recall, from the previous design discussions and agreements with > the sparks team: > > nsadm needs to verify that the user executing the nsadm command > has the appropriate (RBAC) authority to run the command, and > enable a previously created profile. > > The piece of the puzzle that seems to be missing from the most recent > diagrams, but has been previously described in the one pager and > other design documentation is the nsutil tool. nsutil (as described on DW opensolaris.org pages) is just a simple tool to notify nscd about what's going on with back-ends - has one started?, stopped?, configuration refresh started and/or finished?. http://opensolaris.org/os/project/duckwater/Documentation/Reconfiguration/ > > From our previous agreements, nsadm triggered the execution of > nsutil [or triggered a signal to a nsutil daemon], which was the actual > code > responsible for coordinating with nscd and the backend code. See above. > > 1. nsutil is supposed to trigger nscd to complete "in progress" requests > and go into a stable enable files only mode > 2. it was then supposed it enable and disable backend services via nsconf > and the nss_* backend APIs > 3. then resignal nscd to re-initialize the switch to the new configuration It was never the intention. Provided that nsutil is called from start, stop and refresh methods of back-end services, how would it do the things you describe here - esp. 1 and 2? > > > I agree that nscd was not supposed to do the actual work of > switching the smf profiles around. This was a limitation/defect of the > previous alpha duckwater delivery Please elaborate. I don't understand - what is the limitation/defect of previous alpha duckwater delivery? > > We also previously agreed it was not to be done in nscd, because it would > unnecessarily complicate nscd internal organization. I do remember only agreeing that nscd will not be a restarter for everything. This still holds true. > > The previous agreement was for the nsutil tool to do this. Please > review the one-pager and previous older materials. Again, I'm not aware of any such agreement. One pager says this about nsutil: Additionally a private utility application, named nsutil, is planned to help nsconf coordinate nscd(1M) and other back-end components, such as ldap_cachemgr(1M), ypbind(1M) etc. during name service configuration transitions. "is planned to help *coordinate*" ... nothing about switching the profile. We will need nsutil when we will have Enh. SMF Profiles, since then the configuration properties will just change under the services (like ldap/client, dns/client, nis/client ...) and they'll be sent "refresh" command by SMF. Having nsutil and calling it from start, stop and refresh methods is supposed to help nscd keep track of what back-ends are in what state. The other day you mentioned that Chin-Long is actually working on some way for back-ends to communicate their status to nscd. Chin-Long (or anybody from sparks), could you please elaborate? > > Note: nsutil seems to be incorrectly missing from the current diagrams? > It's definition seems to be missing from some of the newer revisions as > well. We don't have any diagram on how the Duckwater profile switch happens. Maybe we should, but I decided not to make one for pre-inception. I was hoping we would create one (or just describe the process) now ... in coordination with SMF with respect to their future development (i.e. Enhanced SMF Profiles). Tomas > > I can't find any e-mails or other that point to this decision being > changed. > I can find older references in some of the previous revisions of the > design documents in the various documentation gates and previous emails. > > Doug. > > Tomas Heran wrote: >> Yesterday Doug and I and later Nico and I had a phone discussions about >> DW profiles etc. and one of things we agreed needs more thought (and >> possible changes) is the actual enabling of given profile. >> >> [01] Maybe "enabling" the profile isn't the right thing. Maybe rather >> "installing" it to a "current active profile" location would be >> better. >> >> [02] nsadm(1M) maybe shouldn't have privilege to do the actual work of >> enabling profile (making the property values changes, >> enabling/disabling back-end services etc.). Maybe it should just >> notify nscd(1M) (which will have those privileges) to the work. >> >> Doug, Nico - please correct me, or fill in more details, if I >> misinterpreted, misunderstood or simply left out anything. >> >> Thanks, >> Tomas >> _______________________________________________ >> duckwater-discuss mailing list >> duckwater-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss From Tomas.Heran at Sun.COM Wed Mar 19 12:44:00 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Wed, 19 Mar 2008 20:44:00 +0100 Subject: [Duckwater-discuss] Enabling NS profile In-Reply-To: <47E155BF.10505@sun.com> References: <47E14669.4040106@sun.com> <47E154C5.5020500@sun.com> <47E155BF.10505@sun.com> Message-ID: <47E16D00.6000404@sun.com> Doug Leavitt wrote: > One correction. I do have email references to nsutil being a set of > co-process > threads inside nscd (from notes in a joint discussion we had on 11/13/07). Got the email too - it is saying: "move/put nsutil into nscd as a co-process" We really should talk in detail about what that means since it somehow doesn't correspond (in my mind) with what the nsutil's job was meant to be as described in: http://opensolaris.org/os/project/duckwater/Documentation/Reconfiguration/ ... and as briefly mentioned in 1-pager. (Just talked to Doug now over IM.) - I gave myself an AI for tomorrow to draw a diagram and describe in detail how the Duckwater profile enabling (or switch) works *now* and present it at the meeting tomorrow, to make sure we all know what's going on and so that we all are on the same page when discussing what's needed to be changed (if anything) etc. Tomas > My error. We will need to clarify this before we proceed to inception. > > Doug. > > Doug Leavitt wrote: >> As I recall, from the previous design discussions and agreements with >> the sparks team: >> >> nsadm needs to verify that the user executing the nsadm command >> has the appropriate (RBAC) authority to run the command, and >> enable a previously created profile. >> >> The piece of the puzzle that seems to be missing from the most recent >> diagrams, but has been previously described in the one pager and >> other design documentation is the nsutil tool. >> >> From our previous agreements, nsadm triggered the execution of >> nsutil [or triggered a signal to a nsutil daemon], which was the >> actual code >> responsible for coordinating with nscd and the backend code. >> >> 1. nsutil is supposed to trigger nscd to complete "in progress" requests >> and go into a stable enable files only mode >> 2. it was then supposed it enable and disable backend services via nsconf >> and the nss_* backend APIs >> 3. then resignal nscd to re-initialize the switch to the new >> configuration >> >> >> I agree that nscd was not supposed to do the actual work of >> switching the smf profiles around. This was a limitation/defect of the >> previous alpha duckwater delivery >> >> We also previously agreed it was not to be done in nscd, because it would >> unnecessarily complicate nscd internal organization. >> >> The previous agreement was for the nsutil tool to do this. Please >> review the one-pager and previous older materials. >> >> Note: nsutil seems to be incorrectly missing from the current diagrams? >> It's definition seems to be missing from some of the newer revisions >> as well. >> >> I can't find any e-mails or other that point to this decision being >> changed. >> I can find older references in some of the previous revisions of the >> design documents in the various documentation gates and previous emails. >> >> Doug. >> >> Tomas Heran wrote: >>> Yesterday Doug and I and later Nico and I had a phone discussions about >>> DW profiles etc. and one of things we agreed needs more thought (and >>> possible changes) is the actual enabling of given profile. >>> >>> [01] Maybe "enabling" the profile isn't the right thing. Maybe rather >>> "installing" it to a "current active profile" location would be >>> better. >>> >>> [02] nsadm(1M) maybe shouldn't have privilege to do the actual work of >>> enabling profile (making the property values changes, >>> enabling/disabling back-end services etc.). Maybe it should just >>> notify nscd(1M) (which will have those privileges) to the work. >>> >>> Doug, Nico - please correct me, or fill in more details, if I >>> misinterpreted, misunderstood or simply left out anything. >>> >>> Thanks, >>> Tomas >>> _______________________________________________ >>> duckwater-discuss mailing list >>> duckwater-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss >> _______________________________________________ >> duckwater-discuss mailing list >> duckwater-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss From Doug.Leavitt at Sun.COM Wed Mar 19 12:46:53 2008 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Wed, 19 Mar 2008 14:46:53 -0500 Subject: [Duckwater-discuss] Enabling NS profile In-Reply-To: <47E16787.3010104@sun.com> References: <47E14669.4040106@sun.com> <47E154C5.5020500@sun.com> <47E16787.3010104@sun.com> Message-ID: <47E16DAD.4040800@sun.com> Sorry, my bad RE "where is nsutil documented". Sigh, I looked at everything else, just not that page... In any case, we still need to get the nscd co-process decisions down in a more concrete documented form. I don't see it anywhere, or perhaps I missed that html page too. :) Doug. Tomas Heran wrote: > nsutil (as described on DW opensolaris.org pages) is just a simple tool > to notify nscd about what's going on with back-ends - has one started?, > stopped?, configuration refresh started and/or finished?. > > http://opensolaris.org/os/project/duckwater/Documentation/Reconfiguration/ > From Nicolas.Williams at sun.com Wed Mar 19 12:51:57 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 19 Mar 2008 14:51:57 -0500 Subject: [Duckwater-discuss] Enabling NS profile In-Reply-To: <47E154C5.5020500@sun.com> References: <47E14669.4040106@sun.com> <47E154C5.5020500@sun.com> Message-ID: <20080319195156.GS16998@Sun.COM> On Wed, Mar 19, 2008 at 01:00:37PM -0500, Doug Leavitt wrote: > As I recall, from the previous design discussions and agreements with > the sparks team: > > nsadm needs to verify that the user executing the nsadm command > has the appropriate (RBAC) authority to run the command, and > enable a previously created profile. That's NOT how svcadm works. When Enhanced SMF profiles arrive, how will things work? I'm guessing: you "install" the selected profile and SMF refreshes everything. So what does nsadm get to do then? Nothing? Just report status info? From Nicolas.Williams at sun.com Wed Mar 19 12:55:41 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 19 Mar 2008 14:55:41 -0500 Subject: [Duckwater-discuss] Enabling NS profile In-Reply-To: <47E14669.4040106@sun.com> References: <47E14669.4040106@sun.com> Message-ID: <20080319195540.GT16998@Sun.COM> On Wed, Mar 19, 2008 at 05:59:21PM +0100, Tomas Heran wrote: > Yesterday Doug and I and later Nico and I had a phone discussions about > DW profiles etc. and one of things we agreed needs more thought (and > possible changes) is the actual enabling of given profile. > > [01] Maybe "enabling" the profile isn't the right thing. Maybe rather > "installing" it to a "current active profile" location would be > better. > > [02] nsadm(1M) maybe shouldn't have privilege to do the actual work of > enabling profile (making the property values changes, > enabling/disabling back-end services etc.). Maybe it should just > notify nscd(1M) (which will have those privileges) to the work. > > Doug, Nico - please correct me, or fill in more details, if I > misinterpreted, misunderstood or simply left out anything. Yes, IMO "nsadm enable " should be "nsadm install " and needs to be born Obsolete since (correct me if I'm wrong) Enhanced SMF profiles will subsume name service profiles. And IMO nsadm should require NO privilege. Doing anything useful with it should require [RBAC] authorization, of course, but that should be done in a daemon, as we do in so many other parts of Solaris. The natural daemon for this is nscd, since it already exists and has all the necessary privilege. Nico -- From Nicolas.Williams at sun.com Wed Mar 19 13:35:10 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 19 Mar 2008 15:35:10 -0500 Subject: [Duckwater-discuss] Comments on Duckwater Message-ID: <20080319203510.GD16999@Sun.COM> - We need a summary of Enhanced SMF profiles that captures the aspects of it that are relevant to Duckwater and NWAM, and confirmation from that project team. E.g., "The intention is that Enhanced SMF profiles will capture all/most/some of every service's properties/property groups, and you can switch from one SMF profile to another without rebooting. SMF will put the new profile's properties into effect atomically and will enable/disable/refresh all affected services." - If that's true then, IMO, that captures the most important functionality of nsadm w.r.t. name services profiles. Thom?? covered this in his "Enabling NS profiles" post. - nsadm shouldn't require any non-basic privilege to run. It should require RBAC authorizations in order to switch name service profiles. That means some daemon must do all of nsadm's non-informational work. That should be nscd. This too is covered by Thom??' post. - The same applies to nscfg, incidentally, but since it already works by calling libscf functions to do the heavy lifting it already gets this right. - Finder APIs. IMO they don't belong in libc, not if they have few consumers. - The pretty pictures in the presentation need to have color-coded boxes. It needs to be clear which legacy components change directly and which ones don't. - Legacy configuration files: - NIS ones should be all private, so, no issue here (and also no need to change them, I think) - /var/ldap/client -- subsumed by nscfg and name service profiles (yay!) - /etc/resolv.conf can be changed dynamically, e.g., by DHCP hook scripts, and needs to remain because many apps may have been linked statically with a resolver. So /etc/resolv.conf must be written to by DW, and in profiles where DNS information does not come from DHCP we may need DW to detect changes and do something about them (see below). - /etc/nsswitch.conf doesn't often change dynamically, but people do edit it manually. And this really must continue to work as before. For /etc/resolv.conf and /etc/nsswitch.conf I propose that when the current profile specifies their content and they are subsequently changed (manually or otherwise) outside DW, then DW should do something about that, such as: - Note the change and import it in to a special name service profile ("current" or something like that) which users can then rename, ... - Note the change and fail to install other name service profiles unless a force option is used (but if nsadm's profile installation functionality will go away then this can't be the right answer). - Something else? Nico -- From Tomas.Heran at Sun.COM Wed Mar 26 07:26:02 2008 From: Tomas.Heran at Sun.COM (Tomas.Heran at Sun.COM) Date: Wed, 26 Mar 2008 07:26:02 -0700 (PDT) Subject: [Duckwater-discuss] WIP - updating libnsconf API document. Message-ID: <20080326142602.5B672122FBA@mail.opensolaris.org> Author: Tomas Heran Repository: /hg/duckwater/duckwater-docs Latest revision: 26007f4faae539598826b9c66689ccbf0519a764 Total changesets: 1 Log message: WIP - updating libnsconf API document. Updated diagrams. Files: create: questions/PSARC-20questions update: design/dw-libnsconf.rst update: design/dw-nss_module-cfgapi.rst update: diagrams/duckwater-config-access.graffle update: diagrams/duckwater-config-access.pdf update: diagrams/duckwater-config-create.graffle update: diagrams/duckwater-config-create.pdf update: diagrams/duckwater-legend.graffle update: diagrams/duckwater-legend.pdf From Tomas.Heran at Sun.COM Wed Mar 26 08:26:41 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Wed, 26 Mar 2008 16:26:41 +0100 Subject: [Duckwater-discuss] Updated NSS module config APIs doc. In-Reply-To: <47D56D49.1040205@sun.com> References: <20080310170926.EFDFB3B834@mail.opensolaris.org> <47D56D49.1040205@sun.com> Message-ID: <47EA6B31.7090906@sun.com> Comments anybody? Or should I consider this one "done"? Thanks, T. Tomas Heran wrote: > I've update the NSS Config APIs design document. The URL of the updated > document on opensolaris.org is here: > > http://opensolaris.org/os/project/duckwater/Documentation/nssconfig/ > > As always - review/comments/ideas/etc. would be much appreciated. > > Thanks, > Tomas > > Tomas.Heran at Sun.COM wrote: >> Author: Tomas Heran >> Repository: /hg/duckwater/duckwater-docs >> Latest revision: c652795b5535a5028eb15ae249db1baae6e5ddd9 >> Total changesets: 1 >> Log message: >> Updated NSS module config APIs doc. >> Updates to libnsconf API >> >> >> Files: >> update: design/dw-libnsconf.rst >> update: design/dw-nss_module-cfgapi.rst >> _______________________________________________ >> duckwater-discuss mailing list >> duckwater-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss From Nicolas.Williams at sun.com Wed Mar 26 08:52:24 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 26 Mar 2008 10:52:24 -0500 Subject: [Duckwater-discuss] Updated NSS module config APIs doc. In-Reply-To: <47D56D49.1040205@sun.com> References: <20080310170926.EFDFB3B834@mail.opensolaris.org> <47D56D49.1040205@sun.com> Message-ID: <20080326155224.GB16998@Sun.COM> On Mon, Mar 10, 2008 at 06:18:01PM +0100, Tomas Heran wrote: > http://opensolaris.org/os/project/duckwater/Documentation/nssconfig/ - Why make the be name part of the modules' symbol names? You don't need to, and for other plug-in SPIs in Solaris we usually don't (but I think counter-examples exist). Basically, it's easier to pass a constant string to dlsym(3C) than it is to alloc and snprintf() a string that then gets passed to dlsym() and then de-alloced. - What is "void **priv"? - What is "nsconf_config_t **cfg"? - What are the various function arguments? I've no idea what _nss__config_create()'s char *name argument is for, for example. - Isn't this SPI going to result in an enourmous amount of code duplication in the modules? I mean, all those property/value access functions will just translate into calls to SMF, or perhaps utility functions from the thing loading the modules (nscd), right? Nico -- From Tomas.Heran at Sun.COM Wed Mar 26 09:09:27 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Wed, 26 Mar 2008 17:09:27 +0100 Subject: [Duckwater-discuss] Enabling NS profile In-Reply-To: <20080319195540.GT16998@Sun.COM> References: <47E14669.4040106@sun.com> <20080319195540.GT16998@Sun.COM> Message-ID: <47EA7537.3050805@sun.com> Nicolas Williams wrote: > On Wed, Mar 19, 2008 at 05:59:21PM +0100, Tomas Heran wrote: >> Yesterday Doug and I and later Nico and I had a phone discussions about >> DW profiles etc. and one of things we agreed needs more thought (and >> possible changes) is the actual enabling of given profile. >> >> [01] Maybe "enabling" the profile isn't the right thing. Maybe rather >> "installing" it to a "current active profile" location would be >> better. >> >> [02] nsadm(1M) maybe shouldn't have privilege to do the actual work of >> enabling profile (making the property values changes, >> enabling/disabling back-end services etc.). Maybe it should just >> notify nscd(1M) (which will have those privileges) to the work. >> >> Doug, Nico - please correct me, or fill in more details, if I >> misinterpreted, misunderstood or simply left out anything. > > Yes, IMO "nsadm enable " should be "nsadm install " > and needs to be born Obsolete since (correct me if I'm wrong) Enhanced > SMF profiles will subsume name service profiles. > > And IMO nsadm should require NO privilege. Doing anything useful with > it should require [RBAC] authorization, of course, but that should be > done in a daemon, as we do in so many other parts of Solaris. The > natural daemon for this is nscd, since it already exists and has all the > necessary privilege. > Follow-up on the phone discussion from last week. I believe we agreed that "profile activation/installation" can be moved to nscd(1M). One obstacle to overcome was import of legacy configuration files into a new name services profile (stored in SMF) at the boot time after an install or upgrade (from pre-Duckwater system) if no NS profile is present in SMF. We agreed, that this can as easily be done in nscd(1M). In [legacy] I proposed to introduce new transient service (or milestone) which will do the job and which (using SMF dependencies) will be guaranteed to run before *all* name service subsystem components. It is now clear, that we will not need this new transient service and will rather have nscd(1M) do the job of importing the configuration files into a new NS profile and then activating this profile. I propose this "legacy config import" happens before nscd(1M) "daemonizes", so that by the time the start method of 'name-service-cache:default' finishes, it's guaranteed that we do have a profile (if we didn't have one before). So far so good, but we also need to make sure that no other NS components (back-end services - e.g. 'ldap/client:default' etc.) runs before nscd is done importing the configuration. As of now, ldap/client etc. are not dependent on name-service-cache. Anybody sees any problem making the back-end services dependent on 'name-service-cache:default'? And since by all this we'll essentially make nscd(1M) (or 'name-service-cache:default') required, how will we make sure it's always enabled? What do we do if anybody disables it? Thanks, Tomas [legacy] http://opensolaris.org/os/project/duckwater/Documentation/legacyconffiles/#install-update From Nicolas.Williams at sun.com Wed Mar 26 09:39:32 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 26 Mar 2008 11:39:32 -0500 Subject: [Duckwater-discuss] Enabling NS profile In-Reply-To: <47EA7537.3050805@sun.com> References: <47E14669.4040106@sun.com> <20080319195540.GT16998@Sun.COM> <47EA7537.3050805@sun.com> Message-ID: <20080326163932.GD16998@Sun.COM> On Wed, Mar 26, 2008 at 05:09:27PM +0100, Tomas Heran wrote: > Follow-up on the phone discussion from last week. I believe we agreed > that "profile activation/installation" can be moved to nscd(1M). I think that's the right thing to do, yes. > One obstacle to overcome was import of legacy configuration files into a > new name services profile (stored in SMF) at the boot time after an > install or upgrade (from pre-Duckwater system) if no NS profile is > present in SMF. We agreed, that this can as easily be done in nscd(1M). I also think that's the right thing to do (among other things it's much, *much* easier to develop and test upgrade behaviour if you do it this way instead of via pkg class action scripts (ew)). > In [legacy] I proposed to introduce new transient service (or milestone) > which will do the job and which (using SMF dependencies) will be > guaranteed to run before *all* name service subsystem components. It is > now clear, that we will not need this new transient service and will > rather have nscd(1M) do the job of importing the configuration files > into a new NS profile and then activating this profile. Excellent. > I propose this "legacy config import" happens before nscd(1M) > "daemonizes", so that by the time the start method of > 'name-service-cache:default' finishes, it's guaranteed that we do have a > profile (if we didn't have one before). Yes. > So far so good, but we also need to make sure that no other NS > components (back-end services - e.g. 'ldap/client:default' etc.) runs > before nscd is done importing the configuration. As of now, ldap/client > etc. are not dependent on name-service-cache. > > Anybody sees any problem making the back-end services dependent on > 'name-service-cache:default'? I don't. > And since by all this we'll essentially make nscd(1M) (or > 'name-service-cache:default') required, how will we make sure it's > always enabled? What do we do if anybody disables it? We can have a reqiured_all dependency on it from the multi-user milestone. Nico -- From Tomas.Heran at Sun.COM Wed Mar 26 09:47:59 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Wed, 26 Mar 2008 17:47:59 +0100 Subject: [Duckwater-discuss] Updated NSS module config APIs doc. In-Reply-To: <20080326155224.GB16998@Sun.COM> References: <20080310170926.EFDFB3B834@mail.opensolaris.org> <47D56D49.1040205@sun.com> <20080326155224.GB16998@Sun.COM> Message-ID: <47EA7E3F.10400@sun.com> Nicolas Williams wrote: > On Mon, Mar 10, 2008 at 06:18:01PM +0100, Tomas Heran wrote: >> http://opensolaris.org/os/project/duckwater/Documentation/nssconfig/ > > - Why make the be name part of the modules' symbol names? > > You don't need to, and for other plug-in SPIs in Solaris we usually > don't (but I think counter-examples exist). > > Basically, it's easier to pass a constant string to dlsym(3C) than it > is to alloc and snprintf() a string that then gets passed to dlsym() > and then de-alloced. Doug, as this is specified by Finder API doc (and implied by the Finder code), could you comment please? > > > - What is "void **priv"? I was told it's common way in nsswitch APIs to pass "private data". Doug, Michen - could you please elaborate and maybe point us to code where this is used? > > > - What is "nsconf_config_t **cfg"? > nsconf_config_t is generic in-memory structure libnsconf is using for handling configurations. I will describe more. > > - What are the various function arguments? > > I've no idea what _nss__config_create()'s char *name argument is > for, for example. > I will improve that - as in add more description. > > - Isn't this SPI going to result in an enourmous amount of code > duplication in the modules? I mean, all those property/value access > functions will just translate into calls to SMF, or perhaps utility > functions from the thing loading the modules (nscd), right? These functions will translate into calls to libnsconf. In theory, we could just require nscd (or rather nscfg in this case) to directly use libnsconf "nsconf_config_t" handling functions, but each module has to do its specific checking of property name and value - which can't happen in libnsconf since it doesn't know anything about particular back-end. or _nss__config_create - it does use libnsconf to allocate the structure, but then each module adds its back-end specific properties, with descriptions, defaults etc. Sure, we will still have a few functions, which will only call their corresponding ones from libnsconf. We were discussing this off-list some time ago and thought it'd be better for consumers (nscfg etc.) to have the complete API available to them in the module rather than having to do something using module SPI and some other things by calling libnsconf directly. Doug, please correct me if I'm wrong or remember some of this incorrectly. Tomas From Nicolas.Williams at sun.com Wed Mar 26 09:55:24 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 26 Mar 2008 11:55:24 -0500 Subject: [Duckwater-discuss] Updated NSS module config APIs doc. In-Reply-To: <47EA7E3F.10400@sun.com> References: <20080310170926.EFDFB3B834@mail.opensolaris.org> <47D56D49.1040205@sun.com> <20080326155224.GB16998@Sun.COM> <47EA7E3F.10400@sun.com> Message-ID: <20080326165524.GE16998@Sun.COM> On Wed, Mar 26, 2008 at 05:47:59PM +0100, Tomas Heran wrote: > > - Isn't this SPI going to result in an enourmous amount of code > > duplication in the modules? I mean, all those property/value access > > functions will just translate into calls to SMF, or perhaps utility > > functions from the thing loading the modules (nscd), right? > > These functions will translate into calls to libnsconf. In theory, we Then they are not needed. I think you can get by with a much, much simpler SPI: - legacy import/export functions - a refresh function From Nicolas.Williams at sun.com Wed Mar 26 10:12:11 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 26 Mar 2008 12:12:11 -0500 Subject: [Duckwater-discuss] Updated NSS module config APIs doc. In-Reply-To: <20080326165524.GE16998@Sun.COM> References: <20080310170926.EFDFB3B834@mail.opensolaris.org> <47D56D49.1040205@sun.com> <20080326155224.GB16998@Sun.COM> <47EA7E3F.10400@sun.com> <20080326165524.GE16998@Sun.COM> Message-ID: <20080326171211.GF16998@Sun.COM> On Wed, Mar 26, 2008 at 11:55:24AM -0500, Nicolas Williams wrote: > On Wed, Mar 26, 2008 at 05:47:59PM +0100, Tomas Heran wrote: > > > - Isn't this SPI going to result in an enourmous amount of code > > > duplication in the modules? I mean, all those property/value access > > > functions will just translate into calls to SMF, or perhaps utility > > > functions from the thing loading the modules (nscd), right? > > > > These functions will translate into calls to libnsconf. In theory, we > > Then they are not needed. I think you can get by with a much, much > simpler SPI: > > - legacy import/export functions > - a refresh function And a prop/vale validation function (for prop setting). From Doug.Leavitt at Sun.COM Wed Mar 26 10:17:02 2008 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Wed, 26 Mar 2008 12:17:02 -0500 Subject: [Duckwater-discuss] Updated NSS module config APIs doc. In-Reply-To: <47EA7E3F.10400@sun.com> References: <20080310170926.EFDFB3B834@mail.opensolaris.org> <47D56D49.1040205@sun.com> <20080326155224.GB16998@Sun.COM> <47EA7E3F.10400@sun.com> Message-ID: <47EA850E.50603@sun.com> Tomas Heran wrote: > > Nicolas Williams wrote: >> On Mon, Mar 10, 2008 at 06:18:01PM +0100, Tomas Heran wrote: >>> http://opensolaris.org/os/project/duckwater/Documentation/nssconfig/ >> - Why make the be name part of the modules' symbol names? >> >> You don't need to, and for other plug-in SPIs in Solaris we usually >> don't (but I think counter-examples exist). >> >> Basically, it's easier to pass a constant string to dlsym(3C) than it >> is to alloc and snprintf() a string that then gets passed to dlsym() >> and then de-alloced. > > > Doug, as this is specified by Finder API doc (and implied by the Finder > code), could you comment please? Naming service nsswitch modules always include the module name as part of the external symbol names, because multiple nsswitch modules are almost always loaded simultaneously with other nsswitch modules and the finder and nsswitch system uses the module name to help distinguish which specific API is being requested and/or used. This is a well known documented behavior of name service switch modules. > >> >> - What is "void **priv"? > > I was told it's common way in nsswitch APIs to pass "private data". > > Doug, Michen - could you please elaborate and maybe point us to code > where this is used? Name service APIs manage and pass along an optional priv pointer for backends for private use (and maintenance of state if desired). This is another well known long standing behavior of the nsswitch. ... > Doug, please correct me if I'm wrong or remember some of this > incorrectly. Will do so later. I have to go back review the document and get the context of the question etc. to respond properly. Doug. From mvw at planets.elm.net Wed Mar 26 12:39:42 2008 From: mvw at planets.elm.net (Marco van Wieringen) Date: Wed, 26 Mar 2008 20:39:42 +0100 Subject: [Duckwater-discuss] First code review for changing the debugging of libsldap [bugid 6655471] In-Reply-To: <47A1AB44.40102@sun.com> References: <1201643152.1624.15.camel@oberon> <1201646962.1624.63.camel@oberon> <1201706015.1624.78.camel@oberon> <47A0A365.7060300@sun.com> <1201712071.1624.108.camel@oberon> <47A0BBF6.90903@sun.com> <1201717455.2701.51.camel@xylabone> <1201720033.5551.13.camel@oberon> <1201720916.2701.103.camel@xylabone> <1201725901.5551.34.camel@oberon> <47A1AB44.40102@sun.com> Message-ID: <1206560382.3430.44.camel@oberon> Hi, Its been some time but I have put 2 code reviews on cr.opensolaris.com with my first public available code for changing the debugging of the libsldap library on both the ductwater and normal onnv tree of opensolaris. I have been working on it the last 2 months when I had some spare time to spend. I would have hoped to be somewhat further but after trying it for a couple of weeks now I think I'm somewhat stuck on a particular part of the dtrace implementation. I had very good input from Milan Jurik (who is both a great sponsor and a very good person to speak with regarding some ideas both he and I had.) This first part is also much due to his good input. What I have done up until now: - Created a wrapper __s_api_dprintf(const char *fmt, ...) which calls the dtrace probe dbgmessage after creating an internal string with the message. - Each call to syslog(LOG_DEBUG is replaced with a call to __s_api_dprintf - I overhauled all #if DEBUG statements and replaced the fprintf/fflush pairs with calls to __s_api_dprintf too - All debug statements which only print a start of function I removed as we think the pid provider can do that already (e.g. show entry and return from a function) - Ripped out the old debug file handling which as I understand from an earlier discussion was obsoleted anyhow. I think it wasn't used much anyhow (maybe even none was left) and with this dtrace stuff in place I think it can go. - Started writing some stuff in both dtrace and the code to do some more clever things in exporting some libsldap structures via probes which mean we can remove quite some debug statements and replace those with propper dtrace code. Maybe done more but this is what comes to mind. The diffs will give a definitive answer on that. The last bit is also where my fun started. I probably am just overlooking something but I cannot get the copyinstr to work for some members of the structures I defined up until now. Maybe someone with lots of dtrace knowledge can help me out there. Its probably something very stupid but mind you that up till 2 months ago I did nothing with dtrace. Currently the output for a debug run looks like this: (The error in this output is from the copyinstr) ???oberon# ./libsldap.d& [1] 8043 oberon# dtrace: script './libsldap.d' matched 9 probes ldaplist dn: ou=Timezone,dc=planets,dc=elm,dc=net dn: ou=ipTnet,dc=planets,dc=elm,dc=net dn: automountMapName=auto_home,dc=planets,dc=elm,dc=net dn: automountMapName=auto_direct,dc=planets,dc=elm,dc=net dn: automountMapName=auto_master,dc=planets,dc=elm,dc=net dn: ou=httpaccounts,dc=planets,dc=elm,dc=net dn: ou=SolarisProfAttr,dc=planets,dc=elm,dc=net dn: ou=svnaccounts,dc=planets,dc=elm,dc=net dn: automountmapname=auto_projects,dc=planets,dc=elm,dc=net dn: ou=virtual mail,dc=planets,dc=elm,dc=net dn: ou=mailaccounts,dc=planets,dc=elm,dc=net dn: ou=SolarisAuthAttr,dc=planets,dc=elm,dc=net dn: ou=group,dc=planets,dc=elm,dc=net dn: ou=rpc,dc=planets,dc=elm,dc=net dn: ou=protocols,dc=planets,dc=elm,dc=net dn: ou=networks,dc=planets,dc=elm,dc=net dn: ou=netgroup,dc=planets,dc=elm,dc=net dn: ou=aliases,dc=planets,dc=elm,dc=net dn: ou=people,dc=planets,dc=elm,dc=net dn: ou=services,dc=planets,dc=elm,dc=net dn: ou=ethers,dc=planets,dc=elm,dc=net dn: ou=profile,dc=planets,dc=elm,dc=net dn: ou=printers,dc=planets,dc=elm,dc=net dn: ou=hosts,dc=planets,dc=elm,dc=net oberon# CPU ID FUNCTION:NAME 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: +++Simple bind 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: Adding connection (serverAddr=192.168.72.26) 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: Initialized sessionPool 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: Connection added [0] 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: connectionID=1024 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: shared=1 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: usedBit=0 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: threadID=1 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: serverAddr=192.168.72.26 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: AuthType=3 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: TlsType=1 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: SaslMech=0 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: SaslOpt=0 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: hostCertPath=/var/ldap 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: userID=cn=proxyagent,ou=profile,dc=planets,dc=elm,dc=net dtrace: error on enabled probe ID 16 (ID 51637: libsldap8044:libsldap.so.1:addConnection:AddConnection): invalid address (0x8094ae0) in action #19 at DIF offset 20 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: connection added into cache 1024 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: Dropping connection cID=1024 flag=0x1000, fini = 0 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: Connection no longer available (fini = 0, shared = 1) 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: unbind (fini = 0, shared = 0) 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: Dropping connection cID=1024 flag=0x0, fini = 1 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: no need to remove (fini = 1, cp = 0) 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: Dropping connection cID=1025 flag=0x0, fini = 1 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: no need to remove (fini = 1, cp = 0) 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: Dropping connection cID=1026 flag=0x0, fini = 1 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: no need to remove (fini = 1, cp = 0) 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: Dropping connection cID=1027 flag=0x0, fini = 1 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: no need to remove (fini = 1, cp = 0) 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: Dropping connection cID=1028 flag=0x0, fini = 1 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: no need to remove (fini = 1, cp = 0) 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: Dropping connection cID=1029 flag=0x0, fini = 1 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: no need to remove (fini = 1, cp = 0) 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: Dropping connection cID=1030 flag=0x0, fini = 1 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: no need to remove (fini = 1, cp = 0) 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: Dropping connection cID=1031 flag=0x0, fini = 1 0 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: no need to remove (fini = 1, cp = 0) 1 51640 __s_api_dprintf:dbgmessage ldaplist[8044] - tid= 1: +++TLS transport fg [1] + running ./libsldap.d ^C I am open to any input. Is this the way we wanna go ? Something different ? Better ways to do things ... Maybe some reindenting needs to be done. And maybe someone has an idea on the dtrace problems I'm facing, any help or input is gladly accepted. I might not have to much time to finish everything as I'm heading on a holiday for 2 months in 7 weeks. But for sure I will pick things up again after returning and exploring Australia. Final the important stuff the 2 URL's http://cr.opensolaris.org/~mvw/6655471-onnv/ http://cr.opensolaris.org/~mvw/6655471-duckwater/ Marco van Wieringen From Doug.Leavitt at Sun.COM Wed Mar 26 14:36:55 2008 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Wed, 26 Mar 2008 16:36:55 -0500 Subject: [Duckwater-discuss] ypinit mis-merge correction pushed Message-ID: <47EAC1F7.2070409@sun.com> I just caught, corrected and pushed an issue with ypinit.sh. When this change went into nevada: changeset: 5896:9da4de721b0a user: pwernau date: Thu Dec 20 07:47:54 2007 -0800 summary: PSARC 2007/677 Allow ypinit -c to use IP addresses The resulting merge and subsequent remerges were both incorrect. changeset: 5947:529df13bed34 user: Tomas Heran date: Mon Jan 07 18:33:58 2008 +0100 summary: Remerge ypinit.sh changeset: 5897:49c4fdd18784 parent: 5889:39a76c33f158 parent: 5896:9da4de721b0a user: Douglas Leavitt date: Thu Dec 20 09:49:20 2007 -0800 summary: branch merge This follow-on correction fixes the remaining issue. The problems is that re-merge called an non-existent shell function 'is_ipv4address' from the old dw source code, instead of the better replacement function 'is_valid_ipaddr' from the new code base. (The new API checks both ipv4 & ipv6 faster than the old. Additionally the mis-merged code still wrote into /etc/hosts which it shouldn't because the other changes for PSARC 2007/677 made that unnecessary. Here was the putback diff. I have tryed it out on a dw build. Doug. Actual diff of the changes are: .hg pdiff diff -r c9230305b29f usr/src/cmd/ypcmd/ypinit.sh --- a/usr/src/cmd/ypcmd/ypinit.sh Wed Mar 26 11:47:53 2008 -0700 +++ b/usr/src/cmd/ypcmd/ypinit.sh Wed Mar 26 16:25:33 2008 -0500 @@ -89,10 +89,8 @@ get_host_list_from_arg () { grep $server $hosts_file $hosts6_file > /dev/null if [ $? = 1 ] then - is_ipv4address $server + is_valid_ipaddr $server if [ $? = 0 ]; then - echo "$server $server # added by ypinit(1M)" \ - >> $hosts_file continue fi echo "server $server not found in $hosts_file \ the corrected change set is: changeset: 6525:895bdbff9e46 user: Doug Leavitt date: Wed Mar 26 16:22:30 2008 -0500 summary: ypinit mismerge corrections From Tomas.Heran at Sun.COM Wed Mar 26 15:02:58 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Wed, 26 Mar 2008 23:02:58 +0100 Subject: [Duckwater-discuss] ypinit mis-merge correction pushed In-Reply-To: <47EAC1F7.2070409@sun.com> References: <47EAC1F7.2070409@sun.com> Message-ID: <47EAC812.1090903@sun.com> Doug Leavitt wrote: > I just caught, corrected and pushed an issue with ypinit.sh. > When this change went into nevada: > > changeset: 5896:9da4de721b0a > user: pwernau > date: Thu Dec 20 07:47:54 2007 -0800 > summary: PSARC 2007/677 Allow ypinit -c to use IP addresses > > > The resulting merge and subsequent remerges were both incorrect. > > changeset: 5947:529df13bed34 > user: Tomas Heran > date: Mon Jan 07 18:33:58 2008 +0100 > summary: Remerge ypinit.sh > > changeset: 5897:49c4fdd18784 > parent: 5889:39a76c33f158 > parent: 5896:9da4de721b0a > user: Douglas Leavitt > date: Thu Dec 20 09:49:20 2007 -0800 > summary: branch merge > > This follow-on correction fixes the remaining issue. > > The problems is that re-merge called an non-existent shell > function 'is_ipv4address' from the old dw source code, instead > of the better replacement function 'is_valid_ipaddr' from the new > code base. (The new API checks both ipv4 & ipv6 faster than > the old. Additionally the mis-merged code still wrote into Oh, I thought I've fixed that incorrect remerge too. I'll have to go back and look ... maybe I have a unpushed changes in some of my workspaces somewhere. > /etc/hosts which it shouldn't because the other changes for > PSARC 2007/677 made that unnecessary. Right. > > Here was the putback diff. I have tryed it out on a dw build. > Doug. > > Actual diff of the changes are: > > > .hg pdiff > diff -r c9230305b29f usr/src/cmd/ypcmd/ypinit.sh > --- a/usr/src/cmd/ypcmd/ypinit.sh Wed Mar 26 11:47:53 2008 -0700 > +++ b/usr/src/cmd/ypcmd/ypinit.sh Wed Mar 26 16:25:33 2008 -0500 > @@ -89,10 +89,8 @@ get_host_list_from_arg () { > grep $server $hosts_file $hosts6_file > /dev/null > if [ $? = 1 ] > then > - is_ipv4address $server > + is_valid_ipaddr $server > if [ $? = 0 ]; then > - echo "$server $server # added by ypinit(1M)" \ > - >> $hosts_file > continue > fi > echo "server $server not found in $hosts_file \ > > the corrected change set is: > changeset: 6525:895bdbff9e46 > user: Doug Leavitt > date: Wed Mar 26 16:22:30 2008 -0500 > summary: ypinit mismerge corrections > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss From Tomas.Heran at Sun.COM Thu Mar 27 06:07:59 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Thu, 27 Mar 2008 14:07:59 +0100 Subject: [Duckwater-discuss] First code review for changing the debugging of libsldap [bugid 6655471] In-Reply-To: <1206560382.3430.44.camel@oberon> References: <1201643152.1624.15.camel@oberon> <1201646962.1624.63.camel@oberon> <1201706015.1624.78.camel@oberon> <47A0A365.7060300@sun.com> <1201712071.1624.108.camel@oberon> <47A0BBF6.90903@sun.com> <1201717455.2701.51.camel@xylabone> <1201720033.5551.13.camel@oberon> <1201720916.2701.103.camel@xylabone> <1201725901.5551.34.camel@oberon> <47A1AB44.40102@sun.com> <1206560382.3430.44.camel@oberon> Message-ID: <47EB9C2F.8060702@sun.com> Marco, Marco van Wieringen wrote: > > The last bit is also where my fun started. I probably am just > overlooking something but I cannot get the copyinstr to work > for some members of the structures I defined up until now. > Maybe someone with lots of dtrace knowledge can help me out > there. Its probably something very stupid but mind you that up > till 2 months ago I did nothing with dtrace. > [snip] > dtrace: error on enabled probe ID 16 (ID 51637: > libsldap8044:libsldap.so.1:addConnection:AddConnection): invalid address > (0x8094ae0) in action #19 at DIF offset 20 I believe the problem lies in the Connection structure translator (in file libsldap.d), specifically in the way you are copying the serverAddr: > 178 /* > 179 * Translator from ns_internal.h struct Connection to dtrace defined struct libsldap_connection > 180 */ > 181 #pragma D binding "1.5" translator > 182 translator struct libsldap_connection { > 183 connectionId = *(int *)copyin((uintptr_t)&P->connectionId, sizeof (ConnectionID)); > 184 usedBit = *(boolean_t *)copyin((uintptr_t)&P->usedBit, sizeof(boolean_t)); > 185 notAvail = *(boolean_t *)copyin((uintptr_t)&P->notAvail, sizeof(boolean_t)); > 186 shared = *(int *)copyin((uintptr_t)&P->shared, sizeof (int)); > 187 pid = *(pid_t *)copyin((uintptr_t)&P->pid, sizeof(pid_t)); > 188 serverAddr = copyinstr((uintptr_t)P->serverAddr); > 189 }; Based on /usr/lib/dtrace/iscsi.d and my own experiments, I believe line 188 should go like this: serverAddr = (curthread->t_procp->p_model == 0x00100000) ? copyinstr((uintptr_t)*(uint32_t *)copyin((uintptr_t) &P->serverAddr, sizeof (uint32_t))) : copyinstr((uintptr_t)*(uint64_t *)copyin((uintptr_t) &P->serverAddr, sizeof (uint64_t))); Please let me know whether it worked for you. Tomas