[zfs-discuss] NFS access by OSX clients (was Cores vs. Speed?)
There's also questions of case sensitivity, locking, being mounted at boot time rather than login time, accomodating more than one user. I've also heard SMB is far slower. The Macs I've switched to automounted NFS are causing me less trouble. If you are in a ``share almost everything'' situation, just add umask 000 to /etc/launchd.conf and reboot. How are you managing UID's on the NFS server? If user eharvey connects to server from client Mac A, or Mac B, or Windows 1, or Windows 2, or any of the linux machines ... the server has to know it's eharvey, and assign the correct UID's etc. When I did this in the past, I maintained a list of users in AD, and duplicate list of users in OD, so the mac clients could resolve names to UID's via OD. And a third duplicate list in NIS so the linux clients could resolve. It was terrible. You must be doing something better? How do you manage your NFS exports? Do all the clients have static assigned IP's, or do you simply export to the whole subnet, or do you do something else? I would consider it a security risk, if any schmo could take any unused IP address, connect to the server, and claim to be eharvey without any problem. Also, I had a umask problem, which presumably you've got solved by the launchd.conf edit. Presumably this umask applies, whether you create a folder in Finder, or create a file in MS Word, or save a new text file from TextEdit ... The umask is applied to every file and every folder creation, regardless of which app is doing the creation, right? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] NFS access by OSX clients (was Cores vs. Speed?)
On Feb 8, 2010, at 4:58 PM, Edward Ned Harvey macenterpr...@nedharvey.com wrote: How are you managing UID's on the NFS server? If user eharvey connects to server from client Mac A, or Mac B, or Windows 1, or Windows 2, or any of the linux machines ... the server has to know it's eharvey, and assign the correct UID's etc. When I did this in the past, I maintained a list of users in AD, and duplicate list of users in OD, so the mac clients could resolve names to UID's via OD. And a third duplicate list in NIS so the linux clients could resolve. It was terrible. You must be doing something better? The way I did this type of integration in my environment was to setup a Linux box with winbind and have NIS make maps just pull out the UID ranges I wanted shared over NIS with all passwords blanked out. Then all -nix based systems use NIS+Kerberos. I suppose one could do the same with LDAP, but winbind has the advantage of auto-creating UIDs based on the user's RID+mapping range which saves A LOT of work in creating UIDs in AD. -Ross ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] NFS access by OSX clients (was Cores vs. Speed?)
There's also questions of case sensitivity, locking, being mounted at boot time rather than login time, accomodating more than one user. I've also heard SMB is far slower. The Macs I've switched to automounted NFS are causing me less trouble. If you are in a ``share almost everything'' situation, just add umask 000 to /etc/launchd.conf and reboot. How are you managing UID's on the NFS server? If user eharvey connects to server from client Mac A, or Mac B, or Windows 1, or Windows 2, or any of the linux machines ... the server has to know it's eharvey, and assign the correct UID's etc. When I did this in the past, I maintained a list of users in AD, and duplicate list of users in OD, so the mac clients could resolve names to UID's via OD. And a third duplicate list in NIS so the linux clients could resolve. It was terrible. You must be doing something better? How do you manage your NFS exports? Do all the clients have static assigned IP's, or do you simply export to the whole subnet, or do you do something else? I would consider it a security risk, if any schmo could take any unused IP address, connect to the server, and claim to be eharvey without any problem. Also, I had a umask problem, which presumably you've got solved by the launchd.conf edit. Presumably this umask applies, whether you create a folder in Finder, or create a file in MS Word, or save a new text file from TextEdit ... The umask is applied to every file and every folder creation, regardless of which app is doing the creation, right? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] NFS access by OSX clients
enh == Edward Ned Harvey macenterpr...@nedharvey.com writes: enh How are you managing UID's on the NFS server? All the macs are installed from the same image using asr. And for the most part, there's just one user, except where there isn't, and then I manage uid's by hand. enh When I did this in the past, I maintained a list of users in enh AD, and duplicate list of users in OD, so the mac clients enh could resolve names to UID's via OD. And a third duplicate enh list in NIS so the linux clients could resolve. It was enh terrible. Why is that terrible? Is it impossible to automate because of the AD piece? OD/NIS should be dumpable from SQL easily, right? If AD is the unscriptable piece, it just seems kind of sad to throw the whole thing out and standardize on the one piece that's the most convoluted and brittle and least automatable, instead of the other way around. enh How do you manage your NFS exports? [...] export to the whole enh subnet yeah, that. r...@1.2.3.0/24 there is a highly stupid bug that would crash mountd for NFSv4 or get incorrect refusal for NFSv3 if the IP was not lookupable in reverse DNS or /etc/hosts. but it may be fixed now because someone from nfs-discuss was unable to reproduce. enh I would consider it a security risk, if any schmo could take enh any unused IP address, connect to the server, and claim to be enh eharvey yeah there is zero security, none at all. I don't really think adding exports restrictions at a finer granularity than subnet would help much. Only Kerberos would help. but most of the security we care about comes from taking snapshots: that's the attack that's relevant here, disgruntled or confused employees deleting everything. This is a robust kind of security, not MM model. also every desktop has a read-only copy of yesterday's shared filesystem, from another nfs server populated with rsync, pre-mounted, in case of problems with the writeable one. At least it is not crap security like SMB, with five or ten wildly different variants and password formats operating on different ports some with MAC session-binding some without. I admit SMB has some security rather than none, but it's a slow crashy clumsy caveat-laden protocol. You might also look at it this way: if there's going to be a panic/DoS or exploitable buffer overflow security problem, it's far more likely to be in the SMB stack than the NFS stack. (that said, 'mknod file b 14 n' seems to panic a Solaris NFS server, at least b71.) enh solved by the launchd.conf edit. Presumably this umask enh applies, whether you create a folder in Finder, or create a enh file in MS Word, or save a new text file from TextEdit ... The enh umask is applied to every file and every folder creation, enh regardless of which app is doing the creation, right? right. This much works perfectly AFAICT. I suppose if you have a user database and want private user folders, you just make them owned by that user and chmod 700. At least that much works everywhere and survives backup, unlike this complete disaster that is ACL's. I get it, the NFSv3 featureset with no text usernames and no Kerberos unchanged in two decades is not a reasonable answer to modern expectations, and NIS is no longer the unifying directory service it once was now that Mac is a credible client. AD can go fuck itself: buy a windows server and another sysadmin to manage it, or suffer the polluting effect it has on your mind and your entire operation. but, yeah, NFSv3 is not enough. It's zero-security simplicity turns out to be exactly what we need here though, and the Mac client with automounter 10.5 or later, is extremely solid, more than the other Mac filesystems or GlobalSAN. pgpeQgCjtTO0o.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
