Re: [zones-discuss] Question on user account config with zones
And new semantics to allow that would have one twist: you really only want to allow this zone-requested loopback when the filesystem to mount is share(1M)'d to the zone. You can't allow zones to have arbitrary loopback mounts created upon request. So this might need support for share -F lofs and corresponding support to (auto)mount global zone lofs exports in local zones. The global zone knows all this and could deal with this gracefully using some form of protocol that establishes not only what the zone wants to mount but also where. More interesting is it when a local zone shares something and another zone wants to mount it Casper ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Question on user account config with zones
[EMAIL PROTECTED] wrote On 07/31/06 07:36,: Hi all, I have a customer with the following question I'm curious on what the best way to propagate all the user accounts on the global zone down to the zones that are already created. The only way that I know is to just copy the files needed like /etc/passwd and /etc/shadow, etc. Is there a way to inherit these config files during the zone creation in order to skip the manual copy of these files if the accounts stay the same?? They will need home directories also. Just like you would share them between ordinary systems: using a nameservice. Just as you would do if these were different systems TM. Home directories are more problematic; you will need to loopback mount them into the local zones. Is the underlying problem being worked on, or is it worth an RFE to make this transparent (automount if remote, auto-lofs if local (not sure how to tell))? Steffen Casper ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Question on user account config with zones
On 7/31/06, Steffen Weiberle [EMAIL PROTECTED] wrote: Home directories are more problematic; you will need to loopback mount them into the local zones. Is the underlying problem being worked on, or is it worth an RFE to make this transparent (automount if remote, auto-lofs if local (not sure how to tell))? How are they more problematic ??? I must be missing something here ? If the home directories are auto-mounted, then work just like on a non-zoned system. NFS from remote servers is mounted via NFS, if the global zone is the home directory server, then the NFS mount is supposed to be converted into an LOFS mount (just as any auto-mount of a server by itself is). I haven't tried this yet, as none of our zoned systems are NFS server (yet), but home directory mounts from remote servers into non-global zones works just fine. -- Paul Kraus ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Question on user account config with zones
Paul Kraus wrote: On 7/31/06, Steffen Weiberle [EMAIL PROTECTED] wrote: Home directories are more problematic; you will need to loopback mount them into the local zones. Is the underlying problem being worked on, or is it worth an RFE to make this transparent (automount if remote, auto-lofs if local (not sure how to tell))? How are they more problematic ??? I must be missing something here ? If the home directories are auto-mounted, then work just like on a non-zoned system. NFS from remote servers is mounted via NFS, if the global zone is the home directory server, then the NFS mount is supposed to be converted into an LOFS mount (just as any auto-mount of a server by itself is). I haven't tried this yet, as none of our zoned systems are NFS server (yet), but home directory mounts from remote servers into non-global zones works just fine. There is no way for the non-global zone automounter to convert these automounts from NFS to LOFS. Firstly, there is no API for the non-global zone to determine that the NFS server is, in fact, the global zone sharing the same kernel. Secondly, even if it could make this determination, there is no way for the the NFS semantics to be turned into equivalent LOFS semantics because the exported pathname is outside of the non-global zone's root directory. Since the non-global zone automounter is unaware and unable to do anything else, it will simply do an NFS mount. The problem is that CR 5065254 (NFS/UFS deadlock when system is both NFS server and client) is likely to cause a deadlock. --Glenn ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Question on user account config with zones
There is no way for the non-global zone automounter to convert these automounts from NFS to LOFS. Firstly, there is no API for the non-global zone to determine that the NFS server is, in fact, the global zone sharing the same kernel. It can easily tell this though. Secondly, even if it could make this determination, there is no way for the the NFS semantics to be turned into equivalent LOFS semantics because the exported pathname is outside of the non-global zone's root directory. That's just a small matter of programming :-) Since the non-global zone automounter is unaware and unable to do anything else, it will simply do an NFS mount. The problem is that CR 5065254 (NFS/UFS deadlock when system is both NFS server and client) is likely to cause a deadlock. Might cause a deadlock. I don't think it's an unsurmountable problem but it needs a bit of smarts in automount and a bit of help from the global zone. Casper ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Question on user account config with zones
Paul Kraus wrote: On 7/31/06, Steffen Weiberle [EMAIL PROTECTED] wrote: Home directories are more problematic; you will need to loopback mount them into the local zones. Is the underlying problem being worked on, or is it worth an RFE to make this transparent (automount if remote, auto-lofs if local (not sure how to tell))? How are they more problematic ??? I must be missing something here ? If the home directories are auto-mounted, then work just like on a non-zoned system. NFS from remote servers is mounted via NFS, if the global zone is the home directory server, then the NFS mount is supposed to be converted into an LOFS mount (just as any auto-mount of a server by itself is). I haven't tried this yet, as none of our zoned systems are NFS server (yet), but home directory mounts from remote servers into non-global zones works just fine. I believe the problem is that the zone looks like a separate system so the automounter within the zone does not know to use lofs to mount the filesystem from the global zone; it uses nfs instead. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Question on user account config with zones
On 7/31/06, Glenn Faden [EMAIL PROTECTED] wrote: Paul Kraus wrote: If the home directories are auto-mounted, then work just like on a non-zoned system. NFS from remote servers is mounted via NFS, if the global zone is the home directory server, then the NFS mount is supposed to be converted into an LOFS mount (just as any auto-mount of a server by itself is). I haven't tried this yet, as none of our zoned systems are NFS server (yet), but home directory mounts from remote servers into non-global zones works just fine. There is no way for the non-global zone automounter to convert these automounts from NFS to LOFS. Firstly, there is no API for the non-global zone to determine that the NFS server is, in fact, the global zone sharing the same kernel. Secondly, even if it could make this determination, there is no way for the the NFS semantics to be turned into equivalent LOFS semantics because the exported pathname is outside of the non-global zone's root directory. I lied above. We had tried this and it did work, but not as I had thought. As part of testing LDAP authentication we have a couple non-global zones setup on the machine that also happens to be our home directory NFS server. One NG zone is a whole root zone running the JES LDAP server. The second NG zone is a sparse zone acting as an LDAP client for authentication. The password, shadow, group, and auto_home tables are served via LDAP. When I log into the second NG zone I get my home directory from the global zone. Since the non-global zone automounter is unaware and unable to do anything else, it will simply do an NFS mount. The problem is that CR 5065254 (NFS/UFS deadlock when system is both NFS server and client) is likely to cause a deadlock. Taking a closer look, it appears that the mount is, in fact, an NFS mount from the global to the NG zone. [EMAIL PROTECTED]:/home/pkraus df -F lofs /dev (/dev ):13661412 blocks 1068602 files /lib (/lib ): 2881356 blocks 483877 files /platform (/platform ): 2881356 blocks 483877 files /sbin (/sbin ): 2881356 blocks 483877 files /usr (/usr ): 2881356 blocks 483877 files [EMAIL PROTECTED]:/home/pkraus df -F nfs /home/pkraus (farewelltr:/export/home/pkraus):33038948 blocks 2991056 files [EMAIL PROTECTED]:/home/pkraus Where ldap is the name of the NG zone and farewelltr is the name of the global zone. So in summary, auto mounted home directories should work in a NG zone as long as the home directory NFS server is NOT the global zone on the same host... -- Paul Kraus ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Question on user account config with zones
[EMAIL PROTECTED] wrote: There is no way for the non-global zone automounter to convert these automounts from NFS to LOFS. Firstly, there is no API for the non-global zone to determine that the NFS server is, in fact, the global zone sharing the same kernel. It can easily tell this though. It's not obvious to me how the non-global zone can determine the hostname of its global zone unless the global zone puts that information somewhere (like in a new file). Secondly, even if it could make this determination, there is no way for the the NFS semantics to be turned into equivalent LOFS semantics because the exported pathname is outside of the non-global zone's root directory. That's just a small matter of programming :-) Seems like the kernel has to help out here. Since the non-global zone automounter is unaware and unable to do anything else, it will simply do an NFS mount. The problem is that CR 5065254 (NFS/UFS deadlock when system is both NFS server and client) is likely to cause a deadlock. Might cause a deadlock. I don't think it's an unsurmountable problem but it needs a bit of smarts in automount and a bit of help from the global zone. I'd like to see this fixed, too.We have a workaround for Trusted Extensions, but it seems to be to hard for people to understand. --Glenn ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Question on user account config with zones
It's not obvious to me how the non-global zone can determine the hostname of its global zone unless the global zone puts that information somewhere (like in a new file). Connect to rpcbind and then check whether getpeerucred() works :-) That's just a small matter of programming :-) Seems like the kernel has to help out here. Either: - we need to allow global zone's auto mounter to do mount by proxy for certain bits in zones or - allow zones to requires loopback mounts to be established for them. Casper ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Question on user account config with zones
Glenn Faden writes: It can easily tell this though. It's not obvious to me how the non-global zone can determine the hostname of its global zone unless the global zone puts that information somewhere (like in a new file). It should not be based on something flimsy (and user-administrable) like the host name. Instead, I think we need a way to ask the system (perhaps a new ioctl?) whether a given known IP address represents a local address or a remote one. Or just fix the deadlock. ;-} Seems like the kernel has to help out here. I agree. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Question on user account config with zones
Rainer Orth wrote: Glenn Faden [EMAIL PROTECTED] writes: Since the non-global zone automounter is unaware and unable to do anything else, it will simply do an NFS mount. The problem is that CR 5065254 (NFS/UFS deadlock when system is both NFS server and client) is likely to cause a deadlock. Does anyone know if this only affects UFS, or ZFS as well? A couple of new fileservers I'm building, based on S10 U2, will only use ZFS (except for /, /var of course), so if this is UFS-only, I would be unaffected. The paritcular scenario which 5065254 addresses is specific to NFS-segmap-UFS interaction. ZFS should not be affected by that specific case. However, I do not have any testing to confirm whether it is affected by any other deadlock cases. Mahesh Rainer ___ zones-discuss mailing list zones-discuss@opensolaris.org
