Re: [zones-discuss] Starting Samba in Open Solaris Non Global Zone
Wes Mauer wrote: OpenSolaris 0609. I've managed to get Samba installed in a non global zone, but it will not start. If you truss smbd, I expect that this is failing due to a missing privilege: # truss -f /usr/sfw/sbin/smbd ... 15231: so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, 0x, SOV_DEFAULT) = 1 9 15231: setsockopt(19, SOL_SOCKET, SO_REUSEADDR, 0xFFBFE86C, 4, SOV_DEFAULT) = 0 15231: bind(19, 0xFFBFE870, 16, SOV_SOCKBSD) Err#13 EACCES [sys_smb] The integrated CIFS server project made running a server on port 445 (which CIFS uses) a privileged operation - the process needs to have PRIV_SYS_SMB (see privileges(5)). Samba knows how to operate with this privilege, but the privilege is not in the default set that is considered safe in a zone. You can adjust the zone config to get this to work - here's an example: # zonecfg -z internal zonecfg:internal info limitpriv limitpriv: default,file_downgrade_sl,file_upgrade_sl,sys_trans_label,win_colormap,win_config,win_dac_read,win_dac_write,win_devices,win_fontpath,win_mac_read,win_mac_write,win_selection zonecfg:internal set limitpriv=default,file_downgrade_sl,file_upgrade_sl,sys_trans_label,win_colormap,win_config,win_dac_read,win_dac_write,win_devices,win_fontpath,win_mac_read,win_mac_write,win_selection,sys_smb zonecfg:internal info limitpriv limitpriv: default,file_downgrade_sl,file_upgrade_sl,sys_trans_label,win_colormap,win_config,win_dac_read,win_dac_write,win_devices,win_fontpath,win_mac_read,win_mac_write,win_selection,sys_smb Rob T ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Parallel mount question
Glenn Faden wrote: Well, it doesn't have to be possible. Instead it should be possible to have the mount(2) syscall detect the loopback NFS and convert it into a lofs mount if, say, a flag is set in the arguments, or even by default. I've thought about doing this in the past, but wasn't sure that it would work. The automounter is has some special processing for NFS, and I don't know what would happen if a requested NFS mount got turned into sa LOFS mount. For example, the automounter attempts to unmount anything it mounted that is no longer busy. So, it might also be necessary to modify the umount syscall to translate NFS umounts to LOFS umounts. The automounter periodically attempts to unmount anything mounted atop an autofs trigger node; I don't think anything needs to think about what type of filesystem it is. If autofs were to choke on this, I would expect it to be simple enough to fix it to address the subtlety. Rob T ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] How can I make a device show up in a non-global zone?
Hi all, I'm working on a project (CIFS client) that needs a device driver. I'm working on zones support, including zone checks to make sure cross-zone access doesn't happen. The device doesn't show up in a non-global zone, which doesn't surprise me, since I expect to have to do work to make that happen. What do I need to do to make it visible? Rob T ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] How can I make a device show up in a non-global zone?
Edward Pilatowicz wrote: well, assuming that you're talking about a pseudo device with a static path, then check out: usr/src/lib/brand/native/zone/platform.xml which get's installed as /usr/lib/brand/native/platform.xml if your device doesn't have a static path then things will get more interesting. ;) Hi Ed, I have /dev/nsmb, which is similar to /dev/tcp: just a cloneable pseudo-device, and I just need to effectively do a mknod /export/home/zone/root/dev/nsmb c 270 0. So I think this is exactly what I want :-) Can I get this applied to an already-installed system (i.e. the one that doesn't work now :-) by editing /usr/lib/brand/native/platform.xml and taking action? It's a small thing, but would save me a couple of steps. Thanks, Rob T ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Calum Mackay wrote: It sounds like we're saying that NFS is just a basic system service that we want to provide from our already existing - and independently-managed - zones, rather than setting up zones specifically to provide separate NFS services (with the various exceptions e.g. Jumpstart testing). That seems to make a lot of sense. I tend to agree, and the basic server consolidation target just makes sense. I want to pretend a zone is the box I used to have and not have to bump my nose on a funny behaviour or exceptions. However, there are some wrinkles: 1) I think there are a variety of use cases that may have disjoint requirements from consolidation, and I want to hear about them, too. One example we had awhile back - SAS shares some of its data via NFS, and loses this ability in a zone. Do they need anything different? 2) Since NFS is mostly an in-kernel service, unlike something like Apache, if you have some kind of issue with NFS stability, you lose the whole box, not just the zone. This lack of fault isolation isn't always something that people are aware of. Does this change anything for your use case? 2) Due to the above, it seems like the global zone admin should have a knob to turn to enable or disable the ability of a zone to share out files via NFS. Do people agree? 2.5) Is this related to whether the global zone can share a resource? 3) I know we've talked about a zone not being able to share stuff outside of its namespace, but I wonder if we should further restrict this to sharing storage that's fully administered in the zone, e.g. you can't share a filesystem you got via lofs, but you can share from a /dev/dsk/cxtxdx or a zpool that had been fully delegated to you. Opinions? 4) A bug currently prevents a client instance and a server instance from being safe to use on the same box (apologies, can't quote the bugid from here). How likely, in your use case, is it that this will be a problem, i.e. will your boxes be in the position where a zone needs data shared from another zone as opposed to a separate server? Rob T ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [nfs-discuss] NFS server in zones
Tom Haynes wrote: What about the case where the customer wants to administer the zone they purchased and they do not want the global zone admins to have local access to their data? Well, there is a tradition in Zones of making the global zone substantially more equal than others. Remember that the global zone admin can observe network traffic from local zones and can access any files in local zones. Rob T ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
[EMAIL PROTECTED] wrote: 4) A bug currently prevents a client instance and a server instance from being safe to use on the same box (apologies, can't quote the bugid from here). How likely, in your use case, is it that this will be a problem, i.e. will your boxes be in the position where a zone needs data shared from another zone as opposed to a separate server? Ah, I remembered the RE who owns it, and found the bugid - it's: 5065254 NFS/UFS deadlock when system is both NFS server and client RT ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
On Feb 14, 2007, at 3:17 PM, Edward Pilatowicz wrote: i would refine your second point though because it doesn't take into account lofs mounts. ex, if i have /export/foo in the global zone and then in zonecfg i configure a filesystem resource such that this directory is also lofs mounted in the zone at /export/foo, then who should be able to export the filesystem? it seems to me that both the local zone and the global zone should be able to export it (or not export it) independantly. I disagree - I think a filesystem should have an owner, and the owner should have sole control over sharing. If the global zone needs to share the data, it should take over ownership, and from outside this should be visible as the data moving between servers. In a related area, and to address an earlier question I raised, I don't think getting a filesystem via a lofs mount should entitle you to share it - you should have device access delegated to your zone in order to do that. Zones folks may disagree. Rob T ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Octave Orgeron wrote: --- [EMAIL PROTECTED] wrote: 2) Since NFS is mostly an in-kernel service, unlike something like Apache, if you have some kind of issue with NFS stability, you lose the whole box, not just the zone. This lack of fault isolation isn't always something that people are aware of. Does this change anything for your use case? This is a great point and shows that there has to be some reorg of the NFS framework. I don't know if that means we need a pseudo instance of the kernel modules for each zone. Or if we have to break it up into components that should be unique to each zone and ones that should be common. I don't think we can go there - a service in the kernel which panics takes out all zones, and there's just nothing we can do about that (beyond minimizing panics as we try to do anyway). I think we need to set expectations that fault isolation is not as strong for this service. Sun has other virtualization solutions that would work better for real fault isolation. 2) Due to the above, it seems like the global zone admin should have a knob to turn to enable or disable the ability of a zone to share out files via NFS. Do people agree? I agree there is should be knob. Perhaps something in zonecfg like: add service set type=nfs end That would enable the zone to be an nfs server. What do you think? Yes, I had a setting like this in mind, as opposed to something that includes a path to a resource that may be shared. Rob T ___ zones-discuss mailing list zones-discuss@opensolaris.org
