Nicolas Williams wrote: >>> The solution we use works for Solaris. We made no changes to Linux. >>> >>> You can still interop with Linux and use Windows identities provided >>> that you have a Unix name service with users and groups that are the >>> equivalents of Windows ones. SFU will do as a such a name services. >>> >>> >>> >> Is SFU the only option right now? >> > > If you want NFSv3 interop with Linux, yes. > > Other options: interop with Linux via CIFS. > > Is SFU required to use only NFSv3 between Solaris Machines?
Is NFSv4 required for any of this? >> What are my choices if the people who run the AD and Windos >> infrastructure refuse to install SFU? >> > > No interop with Linux with NFSv3. Try using CIFS. > > But Linux SMB mounts are done as a single UserID right? If IT will allo me to run my own AD sub domain, can I run SFU only there, and pass the parent domain User/Passord info through to Solaris and Linux? That's not exactly ideal, but might ork better than getting them to run SFU the way I'd need them to. I'm guessing SFU basically adds a AD<->NIS proxy to the AD server? Does it appear as a NIS server to the Linux and Solaris clients? or something else? NIS+? Any idea if a Solaris NIS server can be a slave to the SFU one (assuming my guess above is correct?) >>> It's not the same algorithm, except for name-based mapping, where it's >>> close enough. >>> >>> >> I'm not sure I get this statement, but maybe I'll get after I read all >> the other blogs and docs you pointed me to. Thanks! >> > > idmapd supports just these ID mapping methods: > > - directory-based name mapping > - rule-based name mapping > - ephemeral ID mapping > - local SID mapping > > The first one works by adding attributes to your AD or native LDAP > schema to name an entity's equivalent entity on the other side. > > That sounds the most striaght forward, but that's the one Linux doesn't support yet right? > The second works by providing local rules that tell you how to map an > entity on one side to one on the other. These rules also work with > names. > Even that sounds good to me. > Ephemeral ID mapping dynamically allocates UIDs and GIDs to Windows > entities on demand. The pool of UIDs and GIDs used for this is the 2^31 > to 2^31-2 range of UID/GID values. We took pains to make sure that the > system does not store these anywhere permanently, and we restart the > allocations on reboot. ZFS stores SIDs now. > > That sounds like it might be great in some situations, but I don't think it'll ork for me... Than again after I read everything I might change my mind. > Local SID mapping is used to map non-ephemeral UIDs/GIDs to RIDs > relative to the local SID when there's no other way to map them. > > By local, you mean local to the local machine? or can these mappings be stored in NIS or NIS+? and shared beteen machines? For that matter can the Rule Mapping mentioned above be distributed in NIS, NIS+, or someother (non-AD) LDAP? Either way I bet Linux doesn't have anything that matches up. >>> We're considering adding more ID mapping options too. >>> >>> >>> >> What types of things are you considering? (If you can talk about them?) >> > > Direct support for SFU (right now you have to configure either DS-based > name mapping or local name rules + nss_ldap with schema mapping to get > SFU support). > > I guess I need to go read up on SFU too. It looks like I've put this off way too long. > Also, perhaps we might want to add some algorithmic ID mapping schemes. > > Cool, I'll keep my eyes open. Any chance any of this will be prted to linux anytime soon? Note to Sun: I'd be wiilling to install (and buy!) Sun Software on all my linux machines, in order to make this all place nice together! -Kyle _______________________________________________ opensolaris-discuss mailing list [email protected]
