From Tomas.Heran at Sun.COM Mon Nov 19 08:39:09 2007 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Mon, 19 Nov 2007 17:39:09 +0100 Subject: [Duckwater-discuss] [smf-discuss] SMF v. NSS: deadlock central In-Reply-To: <20071119152646.GA146927@sun.com> References: <20071116232948.GA466915@sun.com> <473EB8FD.8010204@sun.com> <20071119152646.GA146927@sun.com> Message-ID: <4741BC2D.9050808@sun.com> Keith M Wesolowski wrote: > On Sat, Nov 17, 2007 at 10:48:45AM +0100, Tomas Heran wrote: > >> Yes, we're ware of this and we will pay even more attention to it as one >> of Duckwater's goal is to move most of name services configuration to >> SMF. Easy way (IMO) to avoid this kind of problems would be to keep code >> in name service components interacting with svc.configd off of lookup >> code paths - I believe we can do it in most if not all cases. It wasn't > > Let's talk specifics, then: if you don't want retrievals from the > repository in the lookup path, where are you going to do them? > Logically, one might do them at initialization time, and perhaps spin > off a separate thread in nscd to poll for changes (like the existing Yes, initialization time is what I had in mind. W.r.t. polling for changes - we were recently talking about moving the code which monitors changes to configuration files (/etc/nsswitch.conf and /etc/resolv.conf, and more to come with Duckwater) into a separate thread in nscd. We were not planning to poll for any changes to configuration we store in SMF repository though, as I hoped we could simply depend on "svcadm refresh" (or similar) being called when somebody changes name service related configuration data in SMF. > "SMF monitor"). Not great, but maybe. What about when nscd isn't > running? And, does this mean you intend that backends must never For the case when nscd is not running, we are simply depending on /etc/nsswitch.conf to be present on the system - it gets generated by DW's nsadm(1m) command when name services profile is enabled. The same applies for /etc/resolv.conf in our current prototype. This is partially due to the fact that we can't remove these files from the system anyway - many depend on being able to read and modify these. > query the repository (since anything a backend does can be done in the > lookup path, e.g., constructors)? We (our team) need to talk more to be able to say whether we can live with this limitation (i.e. backends must never query SMF repository). There are some back-ends, that (AFAIK) don't read their configuration and instead depend on a back-end specific daemon (nis_cachemgr, ldap_cachemgr, ypbind) to load and handle the configuration and these do load the configuration at the initialization time. But there might be something else out there, which I'm not aware of. We will talk. > > Clearly, it's not enough to get name service lookups out of configd's > authorization path; even if that data were collected when the session > starts up, it could still lead to infinite recursion (configd looks up > authorization data, nss in turn opens a configd session, configd looks > up authorization data, etc.). > >> the case with nscd and "6628289 svc.configd hangs in deadly embrace with >> nscd". It's still not (after fix to 6628289 was put back), but special >> care is now being taken to avoid the possible lock up in nscd. > > I'd like to understand the _rules_ that comprise that "special care". > What block comment describes them? There's no such comment and no general rule(s). Sorry. "Special care" in this case was: make it possible for other door calls (possibly NS data query) into nscd to work while nscd is calling smf_restart_instance and waiting for it to return. We do this when we detect /etc/nsswitch.conf and/or /etc/resolv.conf changed. > >> I believe banning the name service components from calling into configd >> would be very unfortunate, but we can certainly limit the access from NS > > I agree that this would be unfortunate.. > >> to svc.configd to places, where it's safe and identify the parts of >> code, where there's potential threat and make sure we behave correctly >> (as in fix for 6628289). > > What I'm getting out of this is that people see that this is a problem > but don't actually have a specific plan for fixing it. Is that a fair > assessment? That is fair - we don't have any specific plan yet, but we definitely don't ignore the problem. From Tomas.Heran at Sun.COM Tue Nov 20 05:26:21 2007 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Tue, 20 Nov 2007 14:26:21 +0100 Subject: [Duckwater-discuss] [zones-discuss] Interfaces to automate zone system In-Reply-To: <4742D7F7.4000303@Sun.COM> References: <398395.1195480085779.JavaMail.Twebapp@oss-app1> <4742D7F7.4000303@Sun.COM> Message-ID: <4742E07D.7060707@sun.com> Zoram Thanga wrote: > Hi Tomas, > > Tomas Heran wrote: >> Hi Zoram, >> >> you might want to take a look at Project Duckwater - Simplified name >> services management: http://www.opensolaris.org/os/project/duckwater/. >> >> Now, Duckwater's command for creating and managing name services >> configuration - nscfg(1M) - doesn't know anything about zones, but I can >> add an RFE for us to be able to export a name service profile (the set >> of all name service configuration) into a file which you can later >> import somewhere else - e.g. you would configure name services in global >> zone, then exported this configuration (using nscfg) into a file and >> later imported this file (again, using nscfg) into your non-global >> zone(s). >> >> Would that work for you? > > This sounds promising. My basic requirement is that I should be able to > non-interactively install and boot a zone (why? because interactive > install/boot is too tedious in a multi-node environment like Sun Cluster). Makes sense. I'm pretty sure DW will be able to deliver this functionality for name services. > > The user, if he wishes to, can explicitly enter the sysidcfg(4) > parameters for the zone. But we expect that in most cases the only thing > that would be different would be the root password (it would be unwise > to have the same root password for global and non-global zones), and for > the rest of the parameters use either > > a. global zone settings (name service, nfsv4 domain, security policy, > timezone,...) > > or > > b. reasonable defaults (e.g., terminal) > > Stable interfaces to query name service configuration of the global zone > (or any zone for that matter) will be a great help. I'm not sure we will want to commit to deliver stable interfaces *to query* NS configuration (yet), but I hope we can commit to deliver stable interface to migrate a configuration from one place to another, e.g. between computers, between zones etc., provided the two places run compatible nscfg. Thanks, Tomas From Doug.Leavitt at Sun.COM Tue Nov 27 14:09:56 2007 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Tue, 27 Nov 2007 16:09:56 -0600 Subject: [Duckwater-discuss] gate back in sync Message-ID: <474C95B4.2020704@sun.com> The duckwater gate is back in sync (following a weekend of power down, while the utilities company does work) over thanksgiving break where our lab machines are kept. Nightly builds and updates are now running again. Doug.