Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?
Moin Fabian :-) I think the zfs allow|deny feature is only for filesystems. I wish me a feature to protect the complete pool. The property is restricted to zpool commands. On my notebook I have created a pool with simulated drives (gpt/drive1..n) and without any warnings or you are sure (y/n) I can destroy them after one second. Sorry but that's not OK for me and I will not write any wrapper scripts to protect my system. I think a new property named protected=on|off for pool and/or filesystems is a good enhancement for this great filesystem. I love zfs. For my personal reasons I will try to rewrite some pieces of the current source code in FreeBSD to get the wanted functionality for me. Please wish me good luck *g* Gruss Markus ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?
On 02/21/2013 03:34 PM, Jan Owoc wrote: Does this do what you want? (zpool destroy is already undo-able) Jan Jan that's not was I want. I want set a property that's enable/disable all modifications with zpool commands (e.g. zfs destroy, zfs detach ...) This property is also possible for zfs commands (e.g. zfs destroy filesystem) I did'nt need a workaround to protect my filesystems based on snapshots with hold-state. Best regards, Markus :-) ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?
It's anyone here on the list that's have some tips for me what files are to modify ? :-) In my current source tree now is a new property PROTECTED available both for pool- und zfs-objects. I have also two functions added to get and set the property above. The source code tree is very big and some files have the same name in different locations. GREP seems to be my new friend. The source code is very nice and good to understand. I will report my results to you (year 2014, 2015 ..., I don't know *lol* ) -Markus That suggestion makes the very bold assumption that you want a long-standing snapshot of the dataset. If it's a rapidly changing dataset, the snapshot will become an issue very quickly. --Tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Feature Request for zfs pool/filesystem protection?
Hi! My name is Markus and I living in germany. I'm new to this list and I have a simple question related to zfs. My favorite operating system is FreeBSD and I'm very happy to use zfs on them. It's possible to enhance the properties in the current source tree with an entry like protected? I find it seems not to be difficult but I'm not an professional C programmer. For more information please take a little bit of time and read my short post at http://forums.freebsd.org/showthread.php?t=37895 I have reviewed some pieces of the source code in FreeBSD 9.1 to find out how difficult it was to add an pool / filesystem property as an additional security layer for administrators. Whenever I modify zfs pools or filesystems it's possible to destroy [on a bad day :-)] my data. A new property protected=on|off in the pool and/or filesystem can help the administrator for datalost (e.g. zpool destroy tank or zfs destroy tank/filesystem command will be rejected when protected=on property is set). It's anywhere here on this list their can discuss/forward this feature request? I hope you have understand my post ;-) Thanks and best regards, Markus ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?
Am 21.02.2013 00:02, schrieb Tim Cook: I think you're underestimating your English, it's quite good :) Thank you Tim :-) In any case, I think the proposal is a good one. With the default behavior being off, it won't break anything for existing datasets, and it can absolutely help prevent a fat finger or a lack of caffeine ruining someone's day. If the feature is already there somewhere, I'm sure someone will chime in. --Tim Yes! After some minutes I have found places in the source to patch it but is a long way to go them *g* The better way is when this property was available for all operating systems and not only in my sand box. Regards, Markus ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?
Am 21.02.2013 00:08, schrieb Mike Gerdts: On Wed, Feb 20, 2013 at 4:49 PM, Markus Grundmann mar...@freebsduser.eu wrote: Whenever I modify zfs pools or filesystems it's possible to destroy [on a bad day :-)] my data. A new property protected=on|off in the pool and/or filesystem can help the administrator for datalost (e.g. zpool destroy tank or zfs destroy tank/filesystem command will be rejected when protected=on property is set). It's anywhere here on this list their can discuss/forward this feature request? I hope you have understand my post ;-) I like the idea and it is likely not very hard to implement. This is very similar to how snapshot holds work. # zpool upgrade -v | grep -i hold 18 Snapshot user holds So long as you aren't using a really ancient zpool version, you could use this feature to protect your file systems. # zfs create a/b # zfs snapshot a/b@snap # zfs hold protectme a/b@snap # zfs destroy a/b cannot destroy 'a/b': filesystem has children use '-r' to destroy the following datasets: a/b@snap # zfs destroy -r a/b cannot destroy 'a/b@snap': snapshot is busy Of course, snapshots aren't free if you write to the file system. A way around that is to create an empty file system within the one that you are trying to protect. # zfs create a/1 # zfs create a/1/hold # zfs snapshot a/1/hold@hold # zfs hold 'saveme!' a/1/hold@hold # zfs holds a/1/hold@hold NAME TAG TIMESTAMP a/1/hold@hold saveme! Wed Feb 20 15:06:29 2013 # zfs destroy -r a/1 cannot destroy 'a/1/hold@hold': snapshot is busy Extending the hold mechanism to filesystems and volumes would be quite nice. Mike Hi Mike! Yes that I have understand. zfs filesystems can protect on this way. With a new protected property the pool and the vdev's are lay under an additional security layer. We are all humans (that's good) but we are full with errors *lol* The protection property helps to lock modification on the infrastructure of zfs. The pools. With a simple zpool set protected=off pool all modifications are available. The different is you must type as administrator additional command to unlock the pool for your next action. An example: In many linux distributions you will be ask Sure? when you type rm *. That's fine or? zpool and zfs commands working without any warnings. Yes I was root but root is not god ;-) -Markus ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?
Look at the delegable properties (zfs allow). For example, you can delegate a user to have specific privileges and then not allow them to destroy. Note: I'm only 99% sure this is implemented in FreeBSD, hopefully someone can verify. -- richard Hi Richard! I think it's implemented but I have never used. I hope this feature can protect zfs before markus aka root :-))) ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Feature Request for zfs pool/filesystem protection?
On 02/21/2013 02:59 AM, Tim Cook wrote: I hear you, but in his scenario of using scripts for management, there isn't necessarily human interaction to confirm the operation (appropriately or not). Having a pool property seems like an easy way to prevent a mis-parsed or outright incorrect script from causing havoc on the system. --Tim ACK. That's what I mean ... ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
