Rick Macklem wrote:
?Felix Palmen wrote:
[stuff snipped]
>>Ok, thanks for the insight here! So maybe, I could have a look at
>>poudriere's code? If I understand you correctly, keeping the file open
>>and just issuing more write() calls wouldn't trigger that problem?
>Nope,
Felix Palmen wrote:
[stuff snipped]
>Ok, thanks for the insight here! So maybe, I could have a look at
>poudriere's code? If I understand you correctly, keeping the file open
>and just issuing more write() calls wouldn't trigger that problem?
Nope, I don't think keeping the file open would help
Felix Palmen wrote:
>* Rick Macklem [20211009 15:35]:
>> Felix Palmen wrote:
>> Assuming your NFS performance is acceptable for other things and it
>> is only this log file that is a problem, then I doubt there is much you
>> can do to improve it.
>
>Yes, that'
Felix Palmen wrote:
>I use a -CURRENT bhyve vm for testing port builds with poudriere. As
>this vm is only running when needed, but I want to always have access to
>the build logs, I use NFS to mount /usr/local/poudriere/data/logs from
>the host.
>
>I noticed some few ports take ridiculously long
Dirk Meyer wrote:
>Baptiste Daroussin schrieb:,
[stuff snipped]
>
>We have already "toor" for sh.
As an aside, I will note that having multiple passwd entries for the same uid
somewhat
breaks the mapping done by nfsuserd(8), since it will map the uid to one of the
names.
It is not a big issue,
Hi,
I am trying to MFC a commit to stable/12.
The cherry-pick works, but the resultant code
is not correct and won't build.
--> I broke the build yesterday and manually
reverted the breakage.
So, how do I do this?
Do I have to manually edit the file after the
cherry-pick and then do
Mateusz Guzik wrote:
>I reproduced the panic, things work for me with the patch below.
>However, there may be more to it so I'm going to ask Rick to weigh in.
>but short version is that length returned by nfsrv_parsename is off by
>one compared to copyinstr.
Yes, it appears that, now, ni_pathlen
Mateusz Guzik wrote:
>On 5/31/21, Mateusz Guzik wrote:
>> It's probably my commit d81aefa8b7dd8cbeffeda541fca9962802404983 ,
>> I'll look at this later.
>
>Well let me rephrase. While the panic was added in said commit, I
>suspect the bug is on nfs side -- it has its own namei variant which I
Rodney W. Grimes wrote:
[stuff snipped]
>Daniel Ebdrup Jensen wrote:
>> Hi Rick,
>>
>> If I understand your plans correctly, you're not going to be making
>> it so that minorversion=N complains?
>
>Ah, I think that if you specify a minorversion and the server
>does not support that
Daniel Ebdrup Jensen wrote:
>On Thu, May 13, 2021 at 11:02:35PM +0000, Rick Macklem wrote:
>>Hi,
>>
>>I believe that NFSv4.1 and NFSv4.2 are now mature in freebsd-current/main.
>>I also believe that NFSv4.1/4.2 is a better protocol than NFSv4.0.
>>(In p
Hi,
I believe that NFSv4.1 and NFSv4.2 are now mature in freebsd-current/main.
I also believe that NFSv4.1/4.2 is a better protocol than NFSv4.0.
(In particular, the sessions mechanism for "exactly once RPC semantics"
is a significant improvement over the duplicate request cache for NFSv4.0,
Chris Roose wrote:
> Jason Unovitch wrote:
> > Does anything change if you set -tso -lro on the serving NIC on your
> > FreeBSD server side? Do the Linux clients remain responsive then?
>
> Thank you, Jason. This seems to have cleared the problem up for me.
> Since disabling TSO and LRO on the
stead of reply all.
There is also a reddit thread about this
https://www.reddit.com/r/freebsd/comments/mqol4o/nfs_issues_since_upgrading_to_13release/
On Sat, Apr 17, 2021 at 1:10 AM Rick Macklem
mailto:rmack...@uoguelph.ca>> wrote:
Just fyi, I just got a "recursed on non-r
Just fyi, I just got a "recursed on non-recursed mutex" panic in
socantrcvmore() with the D29690 patch, so you might not
want to test with that one yet.
rick
From: owner-freebsd-curr...@freebsd.org on
behalf of Olav Gjerde
Sent: Thursday, April 15,
Stupid Outlook...
I wrote:
[stuff snipped]
>- Alternately you can try rscheff@'s alternate proposed patch that is at
> https://reviews.freebsd.og/D29690.
Oops, that's
https:/reviews.freebsd.org/D29690
But you can figure out the link;-), rick
rick
I have not yet had time to test this one,
I wrote:
[stuff snipped]
>- Alternately you can try rscheff@'s alternate proposed patch that is at
> https://reviews.freebsd.og/D29690.
Oops, that's
https:/reviews.freebsd.org/D29690
rick
I have not yet had time to test this one, but since I cannot reproduce the
hang, I can
only do
Allan Jude wrote:
>On 4/15/2021 9:22 AM, Chris Roose wrote:
>> I posted this in -questions and someone suggested I post here as well.
>>
>> I'm having NFS availability issues between my Proxmox client and FreeBSD
>> server (10G link) since upgrading to 13->RELEASE. And unfortunately I
>>
Hi,
If anyone would like to review D29475, which adds required support
for BindConnectionToSession, please do so.
--> Needed to make callbacks to continue working after a TCP
reconnect occurs, due to a networking partition.
Until this patch is in a client, it is recommended to not run the
AM
To: freebsd-current@freebsd.org
Subject: Re: Getting started with ktls
On Fri, Mar 19, 2021 at 09:37:30PM +, Rick Macklem wrote:
>J. wrote:
>>on the (main/14) server, /etc/rpc.tlsservd was not already there; I had
>>to create it. Is this correct?
>>
>>version is
Hi,
A thread over on freebsd-net@ discusses a situation where
Linux clients seem to get stuck when the TCP connection
is partially torn down. (FIN_WAIT_2 on the client and
CLOSE_WAIT on the server.)
The thread is here:
http://docs.FreeBSD.org/cgi/mid.cgi?YQXPR0101MB0968FB1FF0FC481CE37E9A81DD649
J. wrote:
>on the (main/14) server, /etc/rpc.tlsservd was not already there; I had
>to create it. Is this correct?
>
>version is main-n245454
I'll admit I have no idea what n245454 means, but the daemons were
committed to main on Feb 18, 2021.
Installing them from ports should be fine.
rick
--
J. wrote:
>On Tue, Mar 16, 2021 at 11:46:27PM +0000, Rick Macklem wrote:
>>Well, if you do "sysctl -a | fgrep kern.ipc.tls.stats" and it is working,
>>you should see the count for at least one of the "crypts" ticking up.
>>If they are all zero, it isn
J. wrote:
>On Sun, Mar 14, 2021 at 08:55:18PM +0000, Rick Macklem wrote:
>>Alan explains how to set it up, below.
>>However, I thought I'd note that maybe one person has tested KTLS
>>on arm64, so you should consider doing this for test purposes only.
>>If you do d
[stuff snipped]
> J. wrote:
>>
>> I'd like to have it (ktls) available on the ARM64
>> stable/13-n244876-0b45290603b. Is it just a matter of adding the option,
>> and then the sysctls become available? Is it "better" with openssl[-devel]
>> in ports or openssl in base?
>>
>> thanks,
>> --
>> J.\
I'm going to cheat and top post (the discussion looks
pretty convoluted).
- The kernel must be built with "options KERN_TLS"
- OpenSSL must be built with KTLS enabled
- These two sysctls need to be set to 1
kern.ipc.tls.enable
kern.ipc.mb_use_ext_pgs
then it all happens "behind the
I reproduced the problem and the attached trivial patch
seems to fix it. Please test the patch if you can.
Mateusz, I assume the directory shouldn't try and add
a cache entry for itself?
I don't test NFSv3 much and I don't test "rdirplus"
much, so it slipped through the cracks.
Thanks for
Warner Losh wrote:
>On Fri, Feb 26, 2021 at 11:16 AM Rodney W. Grimes <
>freebsd-...@gndrsh.dnsmgr.net> wrote:
>
>> > On Fri, Feb 26, 2021 at 9:24 AM Rodney W. Grimes <
>> > freebsd-...@gndrsh.dnsmgr.net> wrote:
>> >
>> > > > My understanding is that KTLS works very well with OpenSSL for
>>
Crypto is way out of my area of expertise.
Anyone have ideas on this?
Thanks, rick
From: Peter Eriksson
Sent: Thursday, February 4, 2021 6:56 AM
To: Rick Macklem
Subject: Have you seen this bug?
CAUTION: This email originated from outside
Benjamin Kaduk wrote:
>On Tue, Feb 02, 2021 at 03:48:06AM +0000, Rick Macklem wrote:
>> Benjamin Kaduk wrote:
>> >On Tue, Feb 02, 2021 at 12:46:25AM +, Rick Macklem wrote:
>> >> I've recently been testing the daemons that do the
>> >> n
Benjamin Kaduk wrote:
>On Tue, Feb 02, 2021 at 12:46:25AM +0000, Rick Macklem wrote:
>> I've recently been testing the daemons that do the
>> non-application data stuff for nfs-over-tls with the
>> openssl in head.
>>
>> These daemons work fine with both ports
I've recently been testing the daemons that do the
non-application data stuff for nfs-over-tls with the
openssl in head.
These daemons work fine with both ports/security/openssl (openssl-1.1.1h)
and ports/security/openssl-devel (openssl3-alpha).
However, when linked to the openssl in head, the
Rick Macklem wrote:
>Guido Falsi wrote:
>[good stuff snipped]
>>Performed a full bisect. Tracked it down to commit aa906e2a4957, adding
>>KTLS support to embedded OpenSSL.
>>
>>I filed a bug report about this:
>>
>>https://bugs.freebsd.org/bugzilla
Guido Falsi wrote:
[good stuff snipped]
>Performed a full bisect. Tracked it down to commit aa906e2a4957, adding
>KTLS support to embedded OpenSSL.
>
>I filed a bug report about this:
>
>https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253135
>
>
>Apart from switching to svn:// scheme, another
Benjamin Kaduk wrote:
>On Sat, Jan 23, 2021 at 03:25:59PM +0000, Rick Macklem wrote:
>> Ronald Klop wrote:
>> >On Wed, 20 Jan 2021 21:21:15 +0100, Neel Chauhan wrote:
>> >But I think for Tor to support KTLS it needs to implement some things
>> >itself. More i
Ronald Klop wrote:
>On Wed, 20 Jan 2021 21:21:15 +0100, Neel Chauhan wrote:
>
>> Hi freebsd-current@,
>>
>> I know that In-Kernel TLS was merged into the FreeBSD HEAD tree a while
>> back.
>>
>> With 13.0-RELEASE around the corner, I'm thinking about upgrading my
>> home server, well if I can
Well, it depends on what "stressdisk" (never heard of it) does.
If it:
1 - Reads a large non-sparse file on a UFS file system.
2 - Uses lseek(SEEK_DATA/SEEK_HOLE) with a small blocksize
or copy_file_range(2) with a small length. (copy_file_range(2)
does SEEK_DATA/SEEK_HOLE internally.)
the
content is safe. If in doubt, forward suspicious emails to ith...@uoguelph.ca
El día sábado, enero 02, 2021 a las 11:29:36a. m. -0700, Alan Somers escribió:
> > El día sábado, enero 02, 2021 a las 05:06:05p. m. +, Rick Macklem
> > escribió:
> >
> > >
Just fyi, I've reproduced the problem.
All I did was create a 20Gbyte file
on UFS on a slow (4Gbyte or RAM,
slow spinning disk) laptop.
(The UFS file system is just what the installer creates these days.)
cp still hasn't finished and is definitely
taking a looott longer than dd did.
I'll start
The patches that I believe fix this are now committed to head.
Have a good 2021, rick
From: owner-freebsd-curr...@freebsd.org on
behalf of Rick Macklem
Sent: Thursday, December 31, 2020 5:56 PM
To: Konstantin Belousov
Cc: freebsd-current@freebsd.org
le of days, given the FreeBSD release schedule.
From: owner-freebsd-curr...@freebsd.org on
behalf of Konstantin Belousov
Sent: Thursday, December 31, 2020 6:40 AM
To: Rick Macklem
Cc: freebsd-current@freebsd.org; Alan Somers; Kirk McKusick; Mark Johnst
Rick Macklem wrote:
>Kostik wrote:
> >
> >Idea of the change is to restart the syscall at top level. So for NFS
> >server the right approach is to not send a response and also to not
> >free the request mbuf chain, but to restart processing.
> Yes. I took
Kostik wrote:
>On Wed, Dec 30, 2020 at 02:02:48AM +0000, Rick Macklem wrote:
>> Hi,
>>
>> Post r367671...
>> When multiple files are being created by an NFS client in the same
>> directory, the VOP_CREATE()/ufs_create() can fail with ERELOOKUP.
>> This re
If you are exporting UFS file systems via NFS and your kernel is
built from head/current sources newer than Nov. 15
(r367672 or newer), the NFS service will be broken.
The only workaround is to turn both SU and SU+j off for the
exported file systems via tunefs.
rick
Hi,
Post r367671...
When multiple files are being created by an NFS client in the same
directory, the VOP_CREATE()/ufs_create() can fail with ERELOOKUP.
This results in a EIO return to the NFS client.
--> This causes "nfsv4 client/server protocol prob err=10026"
on the client for NFSv4.0
Hi,
So I just did my first git commit. Pretty scary, but it looks ok.
Now, how do I reference one commit in another related
commit's log?
By the long winded hash or ??
I'm not sure if I should ask here or on the git mailing list,
but I figured this isn't a technical git question...
Thanks for
Hi,
I've put D26938 up on phabricator. The patch applies to the
/etc/rc.d scripts mountd and nfsd, to make use of the new
mountd "-R" option committed via r376026.
If anyone can review this, please do so.
(Is there a group review for rc scripts?)
Thanks, rick
Mehmet Erol Sanliturk wrote:
>On Wed, Oct 21, 2020 at 4:04 AM Rick Macklem
>mailto:rmack...@uoguelph.ca>> wrote:
>>Warner Losh wrote:
>>>On Mon, Oct 19, 2020, 7:25 PM Rick Macklem
>>>mailto:rmack...@uoguelph.ca><mailto:rmack...@uoguelph.ca<mailto:rmac
Warner Losh wrote:
>On Mon, Oct 19, 2020, 7:25 PM Rick Macklem
>mailto:rmack...@uoguelph.ca>> wrote:
>>I'll admit I've hesitated to ask this for a long time, but I guess I have
>>to;-)
>>I've created two daemons for NFS-over-TLS, using the code in
>>/usr/sr
nfsd does.
I don't have a strong opinion either way.
What do others think?
Thanks for the comment, rick
- Peter
> On 20 Oct 2020, at 02:56, Rick Macklem wrote:
>
> Hi,
>
> I've put a patch up on phabricator that adds a new option to mountd
> which disables use of rpcbind. Th
I'll admit I've hesitated to ask this for a long time, but I guess I have to;-)
I've created two daemons for NFS-over-TLS, using the code in
/usr/src/usr.sbin/gssd/gssd.c as a starting point.
--> As such, I left the copyright notice from this file on the two files.
(As you can see, it is a 2
Hi,
I've put a patch up on phabricator that adds a new option to mountd
which disables use of rpcbind. This can be done for NFSv4 only servers.
It appears that rpcbind is now considered a security risk by some.
I listed freqlabs@ as a reviewer, but if anyone else would like to review
it, please
Meowthink reported a problem on freebsd-hackers@ where the
gssd would not start up because /usr was not yet mounted.
(I moved the discussion here, hoping to catch more comments.)
He has a separately mounted /usr and, recently, gssd was failing
to start since /usr was not yet mounted when
Mateusz Guzik wrote:
>On 9/27/20, Alan Somers wrote:
>> On Sun, Sep 27, 2020 at 7:49 AM Wall, Stephen
>> wrote:
>>
>>>
>>> > I'll assume you are referring to the "flags" argument when you say
>>> "param" above.
>>>
>>> Correct, I was misremembering the man page.
>>>
>>> > However, since the
Wall, Stephen wrote:
> Could the as yet unused options param have a bit assigned to trigger the new
> behavior? Inform the linux community of the addition and let them decide if
> they
> would like to adopt it as well.
I'll assume you are referring to the "flags" argument when you say "param"
I know cross-posting is frowned upon, but I wanted everyone who might
like to comment to see this.
Currently copy_file_range(2) only supports regular files, which is compatible
with the Linux one, where EINVAL is returned when either file descriptor
refers to a non-regular file.
Alan Somers
Hi,
I just put a patch up in phabricator (D26521) which avoids always
malloc()'ng a large MAX_NGROUPS sized groups list by having a
small one in the structure and then only malloc()'ng when a large
groups list is needed.
I've listed kib@ and freqlabs@ as reviewers, but anyone else is
welcome to
Christian Weisgerber wrote:
> On 2020-09-19, Zaphod Beeblebrox wrote:
>
> > Hrm. Maybe what I hear others saying, tho, and not entirely being replied
> > to is just a nice concise document of the why. What I hear you saying is
> > that GIT has momentum and that it's popular... (and I accept
Russell L. Carter wrote:
>On 2020-09-18 16:28, Rick Macklem wrote:
> > 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 t
ed, 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-current@freebsd.org; freebsd-sta...@freebsd.org
Subject: Re: Documentation regarding NFSv
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.
John-Mark Gurney wrote:
>Rick Macklem wrote this message on Fri, Sep 04, 2020 at 01:20 +:
>> The server side NFS over TLS daemon (rpc.tlsservd) can reload an updated
>> CRL (Certificate Revocation List) when a SIGHUP is posted to it.
>> However, it does not SSL_shutdown
John-Mark Gurney wrote:
>Rick Macklem wrote this message on Fri, Sep 04, 2020 at 01:20 +:
>> The server side NFS over TLS daemon (rpc.tlsservd) can reload an updated
>> CRL (Certificate Revocation List) when a SIGHUP is posted to it.
>> However, it does not SSL_shutdown
Hi,
The server side NFS over TLS daemon (rpc.tlsservd) can reload an updated
CRL (Certificate Revocation List) when a SIGHUP is posted to it.
However, it does not SSL_shutdown()/close() extant TCP connections using TLS.
(Those would only be closed if the daemon is restarted.)
I am now thinking
Julian H. Stacey wrote:
>Hi curr...@freebsd.org,
>
>/sys/modules/ nfscl & nfsd
>With .ctm_status src-cur 14656 .svn_revision 364986
>
>/usr/src/sys/fs/nfsclient/nfs_clkrpc.c:40:10: fatal error: 'opt_kern_tls.h'
>file not found
># #include "opt_kern_tls.h"
>
># /usr/src/sys/modules/nfsd
>#
Gary Jennejohn wrote:On Tue, 1 Sep 2020 13:00:33 +0200 (CEST)
>Ronald Klop wrote:
>> Van: Rick Macklem
>> Datum: dinsdag, 1 september 2020 04:37
>> Aan: "freebsd-current@FreeBSD.org"
>> Onderwerp: should rpctlssd be called rpc.tlssd?
>> >
&
This sounds trivial, but I thought I'd ask, in case anyone
has a preference?
The NFS over TLS code includes two daemons, one for
the client and one for the server.
I have called them rpctlscd and rpctlssd.
There was/is a tradition in Sun RPC of putting a "." in
the names.
So, should I be calling
Poul-Henning Kamp wrote:
>Rick Macklem writes:
>> Poul-Henning Kamp wrote:
>
>> Is https://reviews.freebsd.org/D26225
>> sufficient to allow me to use 1.3.6.1.4.1.2238.1.1.1 for a user@domain
>> name in this otherName component of subjAltName in the X.509 cert?
Poul-Henning Kamp wrote:
>Rick Macklem writes:
>> For the NFS over TLS work, I have a need for an Internet OID.
>> (I understand that IETF assigns ones for things like SNMP under
>> 1.3.6.1.4.1...)
>
>See:
>
>/usr/share/snmp/mibs/FREEBSD-MIB.txt
Is h
For the NFS over TLS work, I have a need for an Internet OID.
(I understand that IETF assigns ones for things like SNMP under
1.3.6.1.4.1...)
I'm referring to the long strings of numbers separated by "."s,
where each number is a subtree administered by someone.
If either the project or
Hi,
I put D25923 up on phabricator a little while ago.
I clicked on a couple of people that I thought might like to
review it.
However, if anyone else would like to review it, please do so.
The review is as much about the concept as the actual implementation.
Thanks, rick
Here is the
Konstantin Belousov wrote:
>On Tue, Aug 11, 2020 at 03:10:39AM +0000, Rick Macklem wrote:
>> Konstantin Belousov wrote:
>> >On Mon, Aug 10, 2020 at 12:46:00AM +, Rick Macklem wrote:
>> >> Konstantin Belousov wrote:
>> >> >On Fri, Aug 07,
Konstantin Belousov wrote:
>On Mon, Aug 10, 2020 at 12:46:00AM +0000, Rick Macklem wrote:
>> Konstantin Belousov wrote:
>> >On Fri, Aug 07, 2020 at 09:43:14PM -0700, Kirk McKusick wrote:
>> >> I do not have the answer to your question, but I am copying Kostik
>&
Hi,
I've been at this game for a while and one of the axioms is...
"Everything is harder than it at first looks."
Currently, when the FreeBSD NFS client does a write, it does:
- VOP_WRITE() copies the data into buffer cache block(s).
--> An nfsiod thread (or sometimes the thread that called
Andrew Gallatin wrote:
>On 2020-07-19 19:34, Rick Macklem wrote:
>> I spent a little time chasing a problem in the nfs-over-tls code, where it
>> would sometimes end up with corrupted data in the file(s) of a mirrored
>> pNFS configuration.
>>
>> I think the
I spent a little time chasing a problem in the nfs-over-tls code, where it
would sometimes end up with corrupted data in the file(s) of a mirrored
pNFS configuration.
I think the problem was that the code filled the data to be written into
anonymous page M_EXTPG mbufs, then did a m_copym() { copy
Ryan Libby wrote:
>On Sun, Jun 28, 2020 at 9:57 PM Rick Macklem wrote:
>>
>> Just in case you were waiting for another email, I have now run several
>> cycles of the kernel build over NFS on a recent head kernel with the
>> one line change and it has n
anything in the next few days, I'll put it in a PR so it
doesn't get forgotten.
rick
From: owner-freebsd-curr...@freebsd.org on
behalf of Rick Macklem
Sent: Thursday, June 18, 2020 11:42 PM
To: Ryan Libby
Cc: Konstantin Belousov; Jeff Roberson; freebsd
Kostya Berger wrote:
>CURRENT r362292
>sysutils/openzfs-kmod build aborts with error:...
>/usr/ports/sysutils/openzfs-kmod/work/zfs->c0eb5c35e/module/os/freebsd/zfs/zfs_vfsops.c:128:19:
> error:
> incompatible pointer types initializing 'vfs_checkexp_t *' (aka 'int
> (*)(struct
>
Ryan Libby wrote:
>On Mon, Jun 15, 2020 at 5:06 PM Rick Macklem wrote:
>>
>> Rick Macklem wrote:
>> >r358098 will hang fairly easily, in 1-3 cycles of the kernel build over =
NFS.
>> >I thought this was the culprit, since I did 6 cycles of r358097 without =
a han
Hi,
r362158 changed the arguments for zfs_checkexp() in head.
There were no other changes, since the arguments are simply
passed on to vfs_stdcheckexp().
Is there something else that needs to be done,
such as sending this patch upstream?
rick
___
Rick Macklem wrote:
>r358098 will hang fairly easily, in 1-3 cycles of the kernel build over NFS.
>I thought this was the culprit, since I did 6 cycles of r358097 without a hang.
>However, I just got a hang with r358097, but it looks rather different.
>The r358097 hang did not have a
ote:
>On Fri, May 22, 2020 at 11:46:26PM +, Rick Macklem wrote:
>> Konstantin Belousov wrote:
>> >On Wed, May 20, 2020 at 11:58:50PM -0700, Ryan Libby wrote:
>> >> On Wed, May 20, 2020 at 6:04 PM Rick Macklem wrote:
>> >> >
>> >> > Hi,
Hi,
I just put a patch that has a couple of new mbuf handling functions here:
https://reviews.freebsd.org/D25182
I listed glebius@, gallatin@ and jhb@ as possible reviewers, but if anyone
else wants to review or comment on these, please feel free to do so.
rick
Hi,
During testing of a mountd.c patch I have, I found an "old bug" where the
mountd.c code assumed that getgrouplist() would always duplicate
cr_groups[0] in cr_groups[1].
If I read the commit logs correctly, this was always the case until
r174547 (only 12years ago), which switched
now, rick
From: Pete Wright
Sent: Monday, June 1, 2020 8:05 PM
To: Rick Macklem; FreeBSD Current
Subject: Re: vfs_mouse.c breakage?
CAUTION: This email originated from outside of the University of Guelph. Do not
click links or open attachments unless you recognize the sende
Pete Wright wrote:
>Subject: vfs_mouse.c breakage?
Not sure if the vfs mouse is broken (sorry, I couldn't resist), but...
I think it needs a:
#include
but it will take a little while for me to test this.
Thanks for reporting it, rick
>hello - i am having issues building CURRENT after this was
Hi,
I have put a patch up on phabricator
https://reviews.freebsd.org/D25088
I have listed kib@ and freqlabs@ as reviewers, but if anyone else
wishes to review it, be my guest.
It updates "struct export_args" to make the ex_flags field 64bits and
the mapped user (is called ex_anon in the current
Konstantin Belousov wrote:
>On Fri, May 22, 2020 at 11:46:26PM +0000, Rick Macklem wrote:
>> Konstantin Belousov wrote:
>> >On Wed, May 20, 2020 at 11:58:50PM -0700, Ryan Libby wrote:
>> >> On Wed, May 20, 2020 at 6:04 PM Rick Macklem wrote:
>> >> &g
Konstantin Belousov wrote:
>On Wed, May 20, 2020 at 11:58:50PM -0700, Ryan Libby wrote:
>> On Wed, May 20, 2020 at 6:04 PM Rick Macklem wrote:
>> >
>> > Hi,
>> >
>> > Since I hadn't upgraded a kernel through the winter, it took me a while
>> &g
John Baldwin wrote:
>On 5/21/20 2:01 PM, Rick Macklem wrote:
>> Hi,
>>
>> I have now completed changes to the code in projects/nfs-over-tls, which
>> implements TLS encryption of NFS RPC messages. (This roughly conforms
>> to the internet draft "Towards Remot
Hi,
I have now completed changes to the code in projects/nfs-over-tls, which
implements TLS encryption of NFS RPC messages. (This roughly conforms
to the internet draft "Towards Remote Procedure Call Encryption By Default",
which should soon become an RFC. For now, TLS1.2 is used instead of
Hi,
Since I hadn't upgraded a kernel through the winter, it took me a while
to bisect this, but r358252 seems to be the culprit.
If I do a kernel build over NFS using my not so big Pentium 4 (single core,
1.25Gbytes RAM, i386), about every second attempt will hang.
When I do a "ps" in the
John-Mark Gurney wrote:
>Rick Macklem wrote this message on Thu, Mar 26, 2020 at 14:33 +:
>> John-Mark Gurney wrote:
>> [lots of stuff snipped]
>> >Rick Macklem wrote:
>> >> I had originally planned on some "secret" in the certificate (like a CN
of Rick Macklem
Sent: Thursday, March 26, 2020 10:33 AM
To: John-Mark Gurney
Cc: Alexander Leidinger; freebsd-current@FreeBSD.org
Subject: Re: TLS certificates for NFS-over-TLS floating client
John-Mark Gurney wrote:
[lots of stuff snipped]
>Rick Macklem wrote:
>> I had originally planne
John-Mark Gurney wrote:
[lots of stuff snipped]
>Rick Macklem wrote:
>> I had originally planned on some "secret" in the certificate (like a CN name
>> that satisfies some regular expression or ???) but others convinced me that
>> that wouldn't provide anything beyo
John-Mark Gurney wrote:
>Rick Macklem wrote this message on Mon, Mar 23, 2020 at 23:53 +:
>> Alexander Leidinger wrote:
>> John-Mark Gurney wrote:
>> >>Rick Macklem wrote:
>> >>> to be the best solution. The server can verify that the certificat
Alexander Leidinger wrote:
John-Mark Gurney wrote:
>>Rick Macklem wrote:
>>> to be the best solution. The server can verify that the certificate
>>> was issued by
>>> the local CA. Unfortunately, if the client is compromised and the
>>> certificate is
Miroslav Lachman wrote:
>Rick Macklem wrote on 2020/03/19 03:09:
>> Miroslav Lachman wrote:
>>>
>> [...]
>
>>> NFS (or any other server) should check list of revoked certificates too.
>>> Otherwise you will not be able to deny access to user which you
Jan Bramkamp wrote:
>On 20.03.20 02:44, Russell L. Carter wrote:
>> Here I commit heresy, by A) top posting, and B) by just saying, why
>> not make it easy, first, to tunnel NFSv4 sessions through
>> e.g. net/wireguard or sysutils/spiped? NFS is point to point.
>> Security infrastructure that
John-Mark Gurney wrote:
>Rick Macklem wrote this message on Wed, Mar 04, 2020 at 03:15 +:
>> I am slowly trying to understand TLS certificates and am trying to figure
>> out how to do the following:
>> -> For an /etc/exports file with...
>> /home -tls -network 1
101 - 200 of 688 matches
Mail list logo
