Nicolas Williams wrote: > On Wed, Jun 18, 2008 at 04:39:52PM -0400, Kyle McDonald wrote: > >> Is SFU required to use only NFSv3 between Solaris Machines? >> > > No. A Unix name service is strongly implied. That could be SFU. > > Could be SFU? I thought if you want Windows, Linux and Solaris, it had to be SFU? >>> No interop with Linux with NFSv3. Try using CIFS. >>> >>> >> But Linux SMB mounts are done as a single UserID right? >> > > I don't know. I haven't tried (and don't have a Linux system to try > with). > I'm pretty sure you put the Username (and password!!) as options to mount in the /etc/fstab. But there could be something newer now. > >> 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? >> > > We run an AD domain. So do others. I'm not sure what you mean by "pass > the parent domain User/Passord info through to Solaris and Linux". > > I meant, I'm not looking to manage accounts. I was thinking that if I had a PDC (or whatever AD calls it) for a subdomain, that I could run and manage SFU, while passing through the parent domains user accoutn DB... I think older NT domains called this 'Trusting'... I kno enough to kno it's different ith AD, but not *how* it's different. > In AD you don't use passwords -- you use NTLM and Kerberos V > credentials. Yes, those are generally obtained via passwords (ignore > PKINIT for now), but once acquired you don't use your password. > Kerberos....That's my next project... :)
Does that make the Solaris Windows integration easier or harder? > >>> 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? >> > > Samba supports name-based mapping rules. I don't recall if it supports > anything like directory-based name mapping. > Samba won't help as I don't plan on serving any files to indows from Linux.. Thought there may cases in the future where I can't avoid it. > >>> 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. >> > > It's easy! > But it needs to be distributed to each client identically. Then again the DS based mapping is hat needs SFU right? and I bet SFU needs to run on the AD server that has all the other info about the accounts right? I mean it's not like the AD on a subdomain could have a sparse AD LDAP database that adds the mapping info but refers requests for the rest through to the IT Corp AD Domain LDAP database? > >>> 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 work for me... Than again after I read everything I might change my >> mind. >> > > It's great if you're building file servers. file servers that only serve windows (or at least SMB) clients right? > If you're building clients > then you need nss_ad (ongoing project) and even then that doesn't help > you with NFSv3. > > What is nss_ad going to allow? >> For that matter can the Rule Mapping mentioned above be distributed in >> NIS, NIS+, or someother (non-AD) LDAP? >> > > No. If you need to distribute your name mappings, use directory-based > name mapping. > Or there's always Rsync, or Scp. ;) >> Either way I bet Linux doesn't have anything that matches up. >> > > Just rules. > Local Rules... Similiar to Solaris's? I mean even if the file format to specify them is different, is it possible to setup the same local rules mapping on both Solaris and Linux? > >> I guess I need to go read up on SFU too. It looks like I've put this off >> way too long. >> > > So, what are you trying to do? > > I need to setup a new farm of software build servers. They'll consist of all different versions of Linux (multiple versions of RHEL, and SLES) and a few S10 for building our software. I also need to setup a bunch of NFS fileservers to support this build Farm. The Developers all have indows desktops that are clients of the IT 'CORP' AD domain, and they'll also want access to the files on the servers through CIFS, so I really want to setup sNV servers ith ZFS and CIFS. So for the most part, it's Solaris to Windows with CIFS, and Solaris to Solaris and Linux with NFS. There might be a fe Linux machines that end up with filesystem to share via NFS and/or SAMBA, but I think those will be 'nice to haves' that I can work around if it can't be made to work. I just don't want to be in the bussiness of creating and managing user accounts. Today, the IT dept has several separate user databases, that they create accounts for new employees in when they join the company. Changin passords is a problem, and is rare. Currently one of the places they create an account (in addition to AD) is a linux NIS server (with only passwd and group maps) they run - Basically this is the only UNIX machine in the company they've agreed to setup, manage and support. Currently most of the linux machines either use no Name service (most of them are like this) or a few join that NIS domain. I've already setup my own Solaris NIS server as Master for my NIS domain, and a slave for the IT NIS domain, then through a little trick (soft linking the passwd and group DB's from the directory for thier NIS domain to the directory for mine) I've managed to make sure that my NIS domain is uptodate with their User and Group changes, while still having the ability to manage the other NIS maps myself (mainly the automount tables, and one of my own for looking up console NTS ports for servers.) Now I have a meeting with IT coming up because I hear they have 'things in the works' for trying to link their separate user DB's together better, and I'm trying to figure out what it is I should request or recommend they do to get the best fit for the Solaris NFS servers and Linux/Solaris NFS clients I'll be installing soon. It sounds like many of the pieces are there or nearly there, but there's just a little glue still missing... >> Any chance any of this will be prted to linux anytime soon? >> > > By us? Not a chance. We're busy enough as it is! > > But the code *is* CDDLed, and mostly user-land code. The kernel parts > you can write from scratch if you like -- it's not hard. You'd have to > use an IPC other than doors, of course. > > Oh, one more thing: there's no range of UIDs/GIDs in Linux that can be > stolen for ephemeral ID mapping, the way we did for Solaris, because > Linux used unsigned ints for uid_t/gid_t from the get go. > > Yeah. That might turn our to be a real downer, but even if I as left with >> 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! >> > > I wish I could replace the Linux machines with Solaris (I'd do it in a second if I could) but since alot of the software be build are kernel drivers, we tend to have to build on the type and version of Linux we want to run on. Thus, I'd be willing to pay money to install a sun nss_something, or pam_something modules, plus any other software needed to get a compatible mapping mechanism on linux as you have on Nevada. > Solaris is Sun SW... :) :) > > Thank you for that! :) -Kyle _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
