Re: Documentation regarding NFSv4

2020-09-18 Thread Rick Macklem
Oh, and I forgot to mention name<->id# mapping.
If using AUTH_SYS (not kerberos), then you have the
choice of running "nfsuserd" or setting these two sysctls to 1.
vfs.nfs.enable_uidtostring=1
vfs.nfsd.enable_stringtouid=1
--> This makes the server just handle id#s (uid, gid) as numbers in
   a string. (This is the default for Linux these days although it was
'   frowned upon in the early days.)

Running nfsuserd maps uid, gid numbers to/from names using the
password and group databases. This must be used for Kerberos mounts.

Without the above properly configured, you'll see lots of files owned
by "nobody" on the client mounts.

rick


From: Rick Macklem 
Sent: Friday, September 18, 2020 7:21 PM
To: Shawn Webb; freebsd-curr...@freebsd.org; freebsd-stable@freebsd.org
Subject: Re: Documentation regarding NFSv4

Shawn Webb wrote:
>Hey all,
>
>It appears the Handbook and the nfsv4 manpages don't really agree,
>leading to some confusion as to how to properly set up an NFSv4 server
>on FreeBSD.
>
>Any guidance would be appreciated.
1 - I never look at the Handbook, but do try and maintain the man pages.
 Since you didn't explain the specifics related to your confusion, all I can
 say is that the man pages are probably more correct.

Assuming you already have a running NFSv3 NFS server, all you need to do
is:
- Add a V4: line to your /etc/exports files. This does not "export any file 
systems"
  (that is done by other lines in /etc/exports exactly the same as NFSv3).
  However, it does tell the NFSv4 server where the "root" is for NFSv4 clients.
  (ie. Where in the server's file system tree a "nfs-server:/" done by an NFSv4 
client
   ends up.)
- Add nfsv4_server_enable="YES" to your /etc/rc.conf.

Note that, since NFSv4 does allow a mount to cross server mount points (unlike
NFSv3), a client will normally only do a single mount at or near the "root"
specified by the "V4:" line (see "man exports").

If you explain what inconsistencies are in the docs, maybe someone could
fix them.

rick

Thanks,

--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

GPG Key ID:  0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2
https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
___
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: Documentation regarding NFSv4

2020-09-18 Thread Rick Macklem
Shawn Webb wrote:
>Hey all,
>
>It appears the Handbook and the nfsv4 manpages don't really agree,
>leading to some confusion as to how to properly set up an NFSv4 server
>on FreeBSD.
>
>Any guidance would be appreciated.
1 - I never look at the Handbook, but do try and maintain the man pages.
 Since you didn't explain the specifics related to your confusion, all I can
 say is that the man pages are probably more correct.

Assuming you already have a running NFSv3 NFS server, all you need to do
is:
- Add a V4: line to your /etc/exports files. This does not "export any file 
systems"
  (that is done by other lines in /etc/exports exactly the same as NFSv3).
  However, it does tell the NFSv4 server where the "root" is for NFSv4 clients.
  (ie. Where in the server's file system tree a "nfs-server:/" done by an NFSv4 
client
   ends up.)
- Add nfsv4_server_enable="YES" to your /etc/rc.conf.

Note that, since NFSv4 does allow a mount to cross server mount points (unlike
NFSv3), a client will normally only do a single mount at or near the "root"
specified by the "V4:" line (see "man exports").

If you explain what inconsistencies are in the docs, maybe someone could
fix them.

rick

Thanks,

--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

GPG Key ID:  0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2
https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
___
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"


FreeBSD 12.2-BETA2 Now Available

2020-09-18 Thread Glen Barber
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The second BETA build of the 12.2-RELEASE release cycle is now
available.

Installation images are available for:

o 12.2-BETA2 amd64 GENERIC
o 12.2-BETA2 i386 GENERIC
o 12.2-BETA2 powerpc GENERIC
o 12.2-BETA2 powerpc64 GENERIC64
o 12.2-BETA2 powerpcspe MPC85XXSPE
o 12.2-BETA2 sparc64 GENERIC
o 12.2-BETA2 armv6 RPI-B
o 12.2-BETA2 armv7 BANANAPI
o 12.2-BETA2 armv7 BEAGLEBONE
o 12.2-BETA2 armv7 CUBIEBOARD
o 12.2-BETA2 armv7 CUBIEBOARD2
o 12.2-BETA2 armv7 CUBOX-HUMMINGBOARD
o 12.2-BETA2 armv7 RPI2
o 12.2-BETA2 armv7 WANDBOARD
o 12.2-BETA2 armv7 GENERICSD
o 12.2-BETA2 aarch64 GENERIC
o 12.2-BETA2 aarch64 RPI3
o 12.2-BETA2 aarch64 PINE64
o 12.2-BETA2 aarch64 PINE64-LTS

Note regarding arm SD card images: For convenience for those without
console access to the system, a freebsd user with a password of
freebsd is available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/ftp/releases/ISO-IMAGES/12.2/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use SVN to do a source based update of an existing
system, use the "releng/12.2" branch.

A summary of changes since 12.1-BETA1 includes:

o A regression affecting the PowerPC architecture had been fixed.

o A race condition that could lead to a system crash when using jails
  with VIMAGE had been fixed.

o Several wireless driver updates, including an update to ath(4), as
  well as 802.11n support for run(4) and otus(4).

o Capsicum support had been added to rtsol(8) and rtsold(8).

o A fix to certctl(8) to prevent overwriting a file on rehash.

o TRIM support had been added to the bhyve(4) virtio-blk backend.

o Fixes to libcompiler_rt have been added.

o The ice(4) driver had been added, providing support for Intel 100Gb
  ethernet cards.

o Fixes to ixl(4) affecting the PowerPC64 architecture have been added.

o Support for the Novatel Wireless MiFi 8000 and 8800 have been added to
  the urndis(4) driver.

o Fixes to the ure(4) driver to prevent packet-in-packet attacks have
  been addressed.  [SA-20:27]

o Fixes to bhyve(4) to prevent privilege escalation via VMCS access have
  been addressed.  [SA-20:28, SA-20:29]

o A fix to the ftpd(8) daemon to prevent privilege escalation via
  ftpchroot(5) had been addressed.  [SA-20:30]

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 12.2-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/ftp/releases/VM-IMAGES/12.2-BETA2/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-0ac2ea4deed7df976
  eu-north-1 region: ami-06a86489e0ebf2468
  ap-south-1 region: ami-01087b0bd7ab705cb
  eu-west-3 region: ami-047382ed26274083d
  eu-west-2 region: ami-04004ba68a808c246
  eu-south-1 region: ami-0d9b1bfc46181881d
  eu-west-1 region: ami-0512fc8f687e412c0
  ap-northeast-2 region: ami-0cd50852e10e985e4
  me-south-1 region: ami-0f00ec11284f26594
  ap-northeast-1 region: ami-057c02b21871dc72b
  sa-east-1 region: ami-0f1ff5d8cc9886491
  ca-central-1 region: ami-0ead246022df1a239
  ap-east-1 region: ami-0c1518f44dc56de2a
  ap-southeast-1 region: ami-089ae4bd12fef6398
  ap-southeast-2 region: ami-05330786f4f3ee076
  eu-central-1 region: ami-08652cb89d01349a7
  us-east-1 region: ami-007d2232f02b9156b
  us-east-2 region: ami-03444680ed0bc2940
  us-

Documentation regarding NFSv4

2020-09-18 Thread Shawn Webb
Hey all,

It appears the Handbook and the nfsv4 manpages don't really agree,
leading to some confusion as to how to properly set up an NFSv4 server
on FreeBSD.

Any guidance would be appreciated.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

GPG Key ID:  0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2
https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc


signature.asc
Description: PGP signature