Re: Fixed Jail ID for ZFS - need proper mgmt?
- Original Message - From: Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net To: freebsd-jail@freebsd.org; m...@freebsd.org; p...@freebsd.org; ja...@freebsd.org Sent: Tuesday, September 04, 2012 9:55 AM Subject: Fixed Jail ID for ZFS - need proper mgmt? Hi, I had been talking to someone about jail management and it turns out people are using jail jid=42 to always have a fixed jail ID. The reason as I understood is that ZFS datasets are associated by jail id for delegation? [I admit having no clue about the ZFS side] If this is true I feel it's a very bad idea as it makes restarting jails a lot harder in case they remain DYING for say a not fully closed TCP session. My memories are: jid are still unique and cannot be re-used, even if in DYING, names can be re-used and thus are not neccessarily unique. Jamie, can you confirm this? Seems we need to sort out one to two problems: 1) can we make sure that the jail management framework can address a ZFS dataset for delegation somehow and automatically do that as part of the startup? 2) in the case of (1) it should be possible to address jails by name as ZFS would be handled automatically and we would not need another unique identifier I guess? Otherwise I'd prefer for people to be able to delegate ZFS datasets to jail names (as well), as long as they are uniquely identifyable (i.e. there are no 17 jails running with a name of filesever). Do we have documentation for the ZFS features in the man pages or elsewhere btw? If not we should add it. Does this make sense? We use fixed jid's here to ensure only one copy of a jail is started. If a jail is in a dying state you can still resurrect the it if your looking to restart it so it not as big a deal as you may think. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to freebsd-jail-unsubscr...@freebsd.org
Re: Fixed Jail ID for ZFS - need proper mgmt?
On 4. 9. 2012 10:55, Bjoern A. Zeeb wrote: Hi, I had been talking to someone about jail management and it turns out people are using jail jid=42 to always have a fixed jail ID. The reason as I understood is that ZFS datasets are associated by jail id for delegation? [I admit having no clue about the ZFS side] ZFS can be delegated to a jail's id using the zfs jail subcommand. If this is true I feel it's a very bad idea as it makes restarting jails a lot harder in case they remain DYING for say a not fully closed TCP session. My memories are: jid are still unique and cannot be re-used, even if in DYING, names can be re-used and thus are not neccessarily unique. Jamie, can you confirm this? Seems we need to sort out one to two problems: 1) can we make sure that the jail management framework can address a ZFS dataset for delegation somehow and automatically do that as part of the startup? IMO the best way would be adding ZFS features to jail startup. I have already proposed such a script, see the sysutils/jailrc port. To have delegated ZFS datasets manageable in a jail, we need the following: a) /dev/zfs must be available in the jail b) zfs jail jailid dataset has to be called (this makes the dataset visible in a jail) - this has to be done every time the jail is created c) the dataset needs the jailed property set to on (this makes the dataset manageable) - this is a permanent property, I am not sure if this should be managed from the startup script 2) in the case of (1) it should be possible to address jails by name as ZFS would be handled automatically and we would not need another unique identifier I guess? Otherwise I'd prefer for people to be able to delegate ZFS datasets to jail names (as well), as long as they are uniquely identifyable (i.e. there are no 17 jails running with a name of filesever). The binding of a ZFS dataset to a jail has to be exact. So we end up with id's. But we could add something like zfs datasets to the jail's configuration file. The jail command would then simply exec zfs jail jailid dataset for each of the datasets on jail creation right before initiating rc startup and zfs unjail jailid dataset for each of the datasets after jail's rc shutdown but before the jail is destroyed. Do we have documentation for the ZFS features in the man pages or elsewhere btw? If not we should add it. zfs(8), section Jails and subcommands jail, unjail Does this make sense? /bz Cheers, mm -- Martin Matuska FreeBSD committer http://blog.vx.sk ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to freebsd-jail-unsubscr...@freebsd.org
Re: Fixed Jail ID for ZFS - need proper mgmt?
On 09/04/12 02:55, Bjoern A. Zeeb wrote: Hi, I had been talking to someone about jail management and it turns out people are using jail jid=42 to always have a fixed jail ID. The reason as I understood is that ZFS datasets are associated by jail id for delegation? [I admit having no clue about the ZFS side] If this is true I feel it's a very bad idea as it makes restarting jails a lot harder in case they remain DYING for say a not fully closed TCP session. My memories are: jid are still unique and cannot be re-used, even if in DYING, names can be re-used and thus are not neccessarily unique. Jamie, can you confirm this? Seems we need to sort out one to two problems: 1) can we make sure that the jail management framework can address a ZFS dataset for delegation somehow and automatically do that as part of the startup? 2) in the case of (1) it should be possible to address jails by name as ZFS would be handled automatically and we would not need another unique identifier I guess? Otherwise I'd prefer for people to be able to delegate ZFS datasets to jail names (as well), as long as they are uniquely identifyable (i.e. there are no 17 jails running with a name of filesever). Do we have documentation for the ZFS features in the man pages or elsewhere btw? If not we should add it. Does this make sense? /bz It's true that a jail left in the DYING state can't be re-created normally. But it can with the -d flag or the allow.dying parameter. In that case, an existing but dying jail will be re-attached to and this resurrected. So it can be gotten around, and would be a matter of education. Or perhaps we could change the default behavior to silently all re-creation of dying jails. Is there any harm in this? I.e. would there be any difference noticeable to the user if a jail was created with some old TCP connections attached to it? - Jamie ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to freebsd-jail-unsubscr...@freebsd.org
Re: Fixed Jail ID for ZFS - need proper mgmt?
On 09/04/12 04:20, Bjoern A. Zeeb wrote: On Tue, 4 Sep 2012, Pawel Jakub Dawidek wrote: On Tue, Sep 04, 2012 at 11:33:06AM +0200, Martin Matuska wrote: On 4. 9. 2012 10:55, Bjoern A. Zeeb wrote: 2) in the case of (1) it should be possible to address jails by name as ZFS would be handled automatically and we would not need another unique identifier I guess? Otherwise I'd prefer for people to be able to delegate ZFS datasets to jail names (as well), as long as they are uniquely identifyable (i.e. there are no 17 jails running with a name of filesever). The binding of a ZFS dataset to a jail has to be exact. So we end up with id's. But we could add something like zfs datasets to the jail's configuration file. The jail command would then simply exec zfs jail jailid dataset for each of the datasets on jail creation right before initiating rc startup and zfs unjail jailid dataset for each of the datasets after jail's rc shutdown but before the jail is destroyed. Datasets shall not be unjailed. Jailing dataset means that it won't be mounted in the main system. You need to run 'zfs mount -a' within a jail, during it start-up to mount its datasets. This is much safer than mounting anything in jail's directory tree from the main system. We already had security issues because of that. This is also how it works in Solaris/IllumOS with zones. And I can't resist to remind how opposed I was to jail ids in the first place. Especially because they were dynamically allocated. When they were introduced I recommended jail names, which we ended up with anyway, but now we have all this jailid thing to manage in older FreeBSD versions. All in all we should move to using jail names, IMHO, the same way zone names are used in Solaris/IllumOS. When I was adding jail support to ZFS there were no jail names, only jail hostnames, which weren't an option really. I guess we'd need to end up with name and if not uniqe + ID or something? Really IDs are not the problem as long as they never appear anywhere in the config file? Just not sure given names are not unique how to handle it the right way? /bz Names are unique. And we don't have the dying-jail problem with them, as creating a jail with the same name as a dying jail is allowed. OK, that means that jail names aren't quite unique - but they're at least unique among the non-dying set. - Jamie ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to freebsd-jail-unsubscr...@freebsd.org
Re: Fixed Jail ID for ZFS - need proper mgmt?
On Tue, 4 Sep 2012, Jamie Gritton wrote: It's true that a jail left in the DYING state can't be re-created normally. But it can with the -d flag or the allow.dying parameter. In that case, an existing but dying jail will be re-attached to and this resurrected. So it can be gotten around, and would be a matter of education. Or perhaps we could change the default behavior to silently all re-creation of dying jails. Is there any harm in this? I.e. would there be any difference noticeable to the user if a jail was created with some old TCP connections attached to it? Yes, really bad and TCP is not the only thing in theory. Assume your management does not make sure the same users gets the same jail; you elak a lot of (possibly security related) information. Would also make it quite hard in terms of auditing etc. to get this right unless done knowingly and on purpose. -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to freebsd-jail-unsubscr...@freebsd.org
