clean update 12.2 > 13.0

[Chris]

Wow.. Best update I have done in years. At least for me 12.2 > 13.0 was 
great.  Great job !


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zfs native encryption best practices on RELENG13

[Alan Somers]

On Mon, Apr 26, 2021 at 3:04 PM mike tancsa  wrote:

> On 4/23/2021 11:47 PM, Peter Libassi wrote:
> > Yes, I’ve come to the same conclusion. This should be used on a
> > data-zpool and not on the system-pool (zroot). Encryption is per
> > dataset. Also if found that if the encrypted dataset is not mounted of
> > some reason you will be writing to the parent unencrypted dataset.. At
> > least it works for encrypted thumb_drive, i just posted this quick
> > guide
> https://forums.freebsd.org/threads/freebsd-13-openzfs-encrypted-thumb-drive.80008/
> > <
> https://forums.freebsd.org/threads/freebsd-13-openzfs-encrypted-thumb-drive.80008/
> >
> >
> >
> >
>
> Thanks, good points to consider!  I wonder too if there are any
> performance differences
>
> ---Mike
>

Yes there are.  Firstly, if you're using raid, then geli must encrypt both
data and parity.  ZFS crypto, however, only encrypts data because it
operates at a higher level.  That's a pretty substantial performance win
for ZFS during writes.  It's a nonissue for reads from a healthy array,
since ZFS doesn't need to read parity in that case.  Secondly, ZFS crypto
doesn't yet support hardware acceleration.  That's a huge win for geli if
you happen to have a hardware crypto engine (for this purpose AESNI does
not count as hardware, and it works fine with either geli or ZFS).
Thirdly, in my benchmarks I found about a 5% speed advantage for GELI
during reads, though I don't know why.  But of course none of this matters
if you're using a small number of HDDs.  It's only an issue if you have
fast SSDs or a large number of HDDs.
-Alan
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zfs native encryption best practices on RELENG13

[mike tancsa]

On 4/23/2021 11:47 PM, Peter Libassi wrote:
> Yes, I’ve come to the same conclusion. This should be used on a
> data-zpool and not on the system-pool (zroot). Encryption is per
> dataset. Also if found that if the encrypted dataset is not mounted of
> some reason you will be writing to the parent unencrypted dataset.. At
> least it works for encrypted thumb_drive, i just posted this quick
> guide 
> https://forums.freebsd.org/threads/freebsd-13-openzfs-encrypted-thumb-drive.80008/
> 
>
>
>

Thanks, good points to consider!  I wonder too if there are any
performance differences

    ---Mike


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zfs native encryption best practices on RELENG13

[mike tancsa]

On 4/23/2021 5:23 PM, Xin Li wrote:
> On 4/23/21 13:53, mike tancsa wrote:
>> Starting to play around with RELENG_13 and wanted explore ZFS' built in
>> encryption.  Is there a best practices doc on how to do full disk
>> encryption anywhere thats not GELI based  ?  There are lots for 
>> GELI,
>> but nothing I could find for native OpenZFS encryption on FreeBSD
>>
>> i.e box gets rebooted, enter in passphrase to allow it to boot kind of
>> thing from the boot loader prompt ?
> I think loader do not support the native OpenZFS encryption yet.
> However, you can encrypt non-essential datasets on a boot pool (that is,
> if com.datto:encryption is "active" AND the bootfs dataset is not
> encrypted, you can still boot from it).
>
> BTW instead of entering passphrase at loader prompt, if / is not
> encrypted, it's also possible to do something like
> https://lists.freebsd.org/pipermail/freebsd-security/2012-August/006547.html
> .
>
> Personally I'd probably go with GELI (or other kind of full disk
> encryption) regardless if OpenZFS's native encryption is used because my
> primary goal is to be able to just throw away bad disks when they are
> removed from production [1].  If the pool is not fully encrypted, there
> is always a chance that the sensitive data have landed some unencrypted
> datasets and never gets fully overwritten.
>
> [1] Also keep in mind: https://xkcd.com/538/

Thanks for the perspective and links.  I have a couple of use case
scenarios.  One, for devices in somewhat physically untrusted
environments.  Someone breaks into the store, and steals the PC.  
I can
see the advantages of GELI to this environment.  The other is the
ability for customers to send me encrypted datasets for offsite backup. 
If its encrypted, I have less exposure if the dataset is encrypted and I
cant see the contents.   Same for making backups to disks to put in cold
storage although yes, I can see GELI having an an advantage again for
full disk encryption. 


    ---Mike


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Despite the documentation, "etcupdate extract" handles -D destdir (and its contribution to the default workdir)

[John Baldwin]

On 4/24/21 12:22 PM, Mark Millard via freebsd-current wrote:

# etcupdate -?
Illegal option -?

usage: etcupdate [-npBF] [-d workdir] [-r | -s source | -t tarball]
  [-A patterns] [-D destdir] [-I patterns] [-L logfile]
  [-M options]
etcupdate build [-B] [-d workdir] [-s source] [-L logfile] [-M options]
  
etcupdate diff [-d workdir] [-D destdir] [-I patterns] [-L logfile]
etcupdate extract [-B] [-d workdir] [-s source | -t tarball] [-L 
logfile]
  [-M options]
etcupdate resolve [-p] [-d workdir] [-D destdir] [-L logfile]
etcupdate status [-d workdir] [-D destdir]

The "etcupdate extract" material does not show -D destdir as valid.


Thanks, it was a documentation oversight I've just fixed.  It is definitely
supposed to work and is quite useful for cross-builds (e.g. I use it frequently
to update rootfs images I use with qemu for RISC-V or MIPS that I run under
qemu, or when updating the SD-card for my RPI that I cross-build on an x86
host).

--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: iPhone tethering not working

[Li-Wen Hsu]

On Mon, Apr 26, 2021 at 8:34 PM 宋立杰  wrote:

>
> > 在 2021年4月25日，23:04，Li-Wen Hsu  写道：
> >
> > On Sun, Apr 25, 2021 at 9:55 PM 宋立杰  wrote:
> >>
> >> Yes, there is no ue0. And I made a mistake, it is 12.2-RELEASE other
> than STABLE. Sorry for that. Do I need to install STABLE to keep up with
> the newest development?
> >>
> >> This time usbmuxd works, but why it has to run in foreground? And
> what’s the difference to usb_config?
> >> And running in background, I can get DHCP offer this time, but I still
> can’t ping to any website, “The network is down”. Why?
> >>
> >> Best wishes,
> >> A BSD newbie
> >
> > Please don't forget CC the list unless there is sensitive information,
> > the discussion may also help others.
> >
> > For iOS 14, that patch is needed so if Apple did the same change in
> > the newer iOS 13 branch, upgrading to 12.2-STABLE is necessary. You
> > can also upgrade to 13.0-RELEASE if you want to keep tracking
> > -RELEASE.
> >
> > You can exit usbmuxd when you see ue0 is available. TBH I don't check
> > the details in those tools.
> >
> > If you can get an IP from DHCP, but cannot do any transmission, that's
> > exactly the same behavior on iOS 14 without that patch so upgrading to
> > a newer version might help.
> >
> > Best,
> > Li-Wen
>
> Sorry, I made another mistake 😂, this is my first time to use a mailing
> list.
>

That's OK, welcomed to the community. :-)


> Applying the 12.2-RELEASE-p6 patch doesn’t seem to work, how can I
> transfer to 12.2-STABLE?
>

-RELEASE only receive security and errata fixes, I'm not really sure that
patch should be in errata. But if others think it's worthy, I can try to do
so.

This doc should help, if there is any unclear, please report and help us
update it:

https://docs.freebsd.org/en/books/handbook/cutting-edge/#current-stable

Or you can just apply that patch to 12.2-RELEASE's source and rebuild the
if_ipheth.ko module to test, if that's easier for you.

Also, using 13.0-RELEASE might be easier to install and test. Please
consider this route if you don't have a special reason to stay with 12.

Best,
Li-Wen
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: iPhone tethering not working

[宋立杰 via freebsd-stable]

> 在 2021年4月25日，23:04，Li-Wen Hsu  写道：
> 
> On Sun, Apr 25, 2021 at 9:55 PM 宋立杰  wrote:
>> 
>> Yes, there is no ue0. And I made a mistake, it is 12.2-RELEASE other than 
>> STABLE. Sorry for that. Do I need to install STABLE to keep up with the 
>> newest development?
>> 
>> This time usbmuxd works, but why it has to run in foreground? And what’s the 
>> difference to usb_config?
>> And running in background, I can get DHCP offer this time, but I still can’t 
>> ping to any website, “The network is down”. Why?
>> 
>> Best wishes,
>> A BSD newbie
> 
> Please don't forget CC the list unless there is sensitive information,
> the discussion may also help others.
> 
> For iOS 14, that patch is needed so if Apple did the same change in
> the newer iOS 13 branch, upgrading to 12.2-STABLE is necessary. You
> can also upgrade to 13.0-RELEASE if you want to keep tracking
> -RELEASE.
> 
> You can exit usbmuxd when you see ue0 is available. TBH I don't check
> the details in those tools.
> 
> If you can get an IP from DHCP, but cannot do any transmission, that's
> exactly the same behavior on iOS 14 without that patch so upgrading to
> a newer version might help.
> 
> Best,
> Li-Wen

Sorry, I made another mistake 😂, this is my first time to use a mailing list.

Applying the 12.2-RELEASE-p6 patch doesn’t seem to work, how can I transfer to 
12.2-STABLE?

Best wishes,
A BSD newbie
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"