zfs send without -R on bastille create

[vegged]

Since there are no descendent file systems in the bastille create scenario, stripping zfs send of the --replicate option enables support for encrypted datasets. Fixes #839.

[tschettervictor]

What about cloning?
And renaming?

[vegged]

What about cloning?

Cloning requires further brainstorming. Getting thick jails to work is a first step, and an opportunity to get confirmation on the use of -R with zfs send: if it serves no other purpose than sending a snapshot -r comprised of several datasets in one go, I suppose we could check source datasets for zfs native encryption properties before snapshotting, and implement their replication individually? I'm happy to try once/if the loss of -R is cleared.

And renaming?

No issue there AFAIK! Renaming works out of the box on encrypted datasets in my experience.

Happy to get feedback from you seasoned Bastille folks & run tests to further my understanding!

[tschettervictor]

There shouldn't be an issue removing the -R I think. It just replicates the release to the jail base, so there are no child datasets when creating.

Cloning will need some more work to achieve this goal.

@yaazkal @bmac2

[vegged]

Unrelated to encryption, second commit fixes #858.

[tschettervictor]

I have a suggestion. What if we check the property of the Bastille dataset, and if encryption is enabled, we send with -w but if not then we send as we currently do.

[tschettervictor]

@vegged Here is what I mean.

We can "zfs get -H -o encryption pool/dataset" to return "on" for encryption enabled, and "off" for disabled. We will then use the output to build an "OPTIONS" variable that will add "-w" if encryption is enabled.

Would this work for you?
Does sending with -w resolve the issue?

[bmac2]

@vegged fix the conflicts in your branch so I can merge this one

[bmac2]

this PR addresses #839

[tschettervictor]

Let's hang on with merging.

@vegged did you read my suggestion?

[vegged]

I have a suggestion. What if we check the property of the Bastille dataset, and if encryption is enabled, we send with -w but if not then we send as we currently do.

Unfortunately, sending with -w (or --raw) is not a valid workaround, as I mentioned in this comment, due to a long lasting zfs limitation.

Since there are no child datasets in the thick jail scenario, is there any drawback to removing -R altogether, @tschettervictor?

[tschettervictor]

None that I can see.

But if there was a reason it is included, we should do what I suggested, but except for -w, we just send without -R on encrypted datasets.

[bmac2]

I think victor;s suggestion of checking if the db is encrypted and remove the -R so we don't accidentally break anything