From kaduk@mit.edu Wed Oct 9 07:52:24 2019 From: kaduk@mit.edu (Benjamin Kaduk) Date: Tue, 8 Oct 2019 23:52:24 -0700 Subject: [OpenAFS] looking for (old) paper discussing the global name space Message-ID: <20191009065224.GO76545@kduck.mit.edu> Hi all, A bit off topic, but as NFSv4 is implementing cross-server referrals, the prospect of having a central server that just makes referrals to other (data-hosting) servers as a sort of global file system namespace has come up, and I offered to find a reference to use for discussion of the prior work. For context, that reference would be used from https://tools.ietf.org/html/draft-ietf-nfsv4-rfc5661sesqui-msns-02#section-11.5.6 . I did find https://www.cs.cmu.edu/~satya/docdir/spasojevic-tocs-afs-measurement-1996.pdf which has some discussion of this topic in the scope of a broader retrospective on the wide-area filesystem, but I was wondering if anyone knew of a more-focused reference for the global nature of the namespace. Thanks, Ben From steven.jenkins@gmail.com Wed Oct 9 13:38:26 2019 From: steven.jenkins@gmail.com (Steven Jenkins) Date: Wed, 9 Oct 2019 08:38:26 -0400 Subject: [OpenAFS] looking for (old) paper discussing the global name space In-Reply-To: <20191009065224.GO76545@kduck.mit.edu> References: <20191009065224.GO76545@kduck.mit.edu> Message-ID: --0000000000005a856a059479905f Content-Type: text/plain; charset="UTF-8" You might take a look at https://www.hpl.hp.com/hpjournal/95dec/dec95a3.pdf. That's for DCE/DFS, not AFS, but it discusses how global namespace management was done in the DCE/DFS context. DNS also has AFSDB records, and you could look to find the RFC(s) that covered those (e.g., RFC 5395) However, I do not know that they were/are widely-used. Steven On Wed, Oct 9, 2019 at 2:53 AM Benjamin Kaduk wrote: > Hi all, > > A bit off topic, but as NFSv4 is implementing cross-server referrals, the > prospect of having a central server that just makes referrals to other > (data-hosting) servers as a sort of global file system namespace has come > up, and I offered to find a reference to use for discussion of the prior > work. For context, that reference would be used from > > https://tools.ietf.org/html/draft-ietf-nfsv4-rfc5661sesqui-msns-02#section-11.5.6 > . I did find > > https://www.cs.cmu.edu/~satya/docdir/spasojevic-tocs-afs-measurement-1996.pdf > which has some discussion of this topic in the scope of a broader > retrospective on the wide-area filesystem, but I was wondering if anyone > knew of a more-focused reference for the global nature of the namespace. > > Thanks, > > Ben > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > --0000000000005a856a059479905f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

You might take a look at=C2=A0https://www.hpl.hp.com/hpjournal/95dec/dec95a3.pdf.= =C2=A0 That's for DCE/DFS, not AFS, but it discusses how global namespa= ce management was done in the DCE/DFS context.

DNS also has AFSDB records, and you could look to find the RFC(s) that c= overed those (e.g., RFC 5395) =C2=A0However, I do not know that they were/a= re widely-used. =C2=A0
Steven


On Wed, Oct 9, 2019 at 2:53 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi all,

A bit off topic, but as NFSv4 is implementing cross-server referrals, the prospect of having a central server that just makes referrals to other
(data-hosting) servers as a sort of global file system namespace has come up, and I offered to find a reference to use for discussion of the prior work.=C2=A0 For context, that reference would be used from
https://tools.ietf.= org/html/draft-ietf-nfsv4-rfc5661sesqui-msns-02#section-11.5.6
.=C2=A0 I did find
https://www.cs.cmu.edu/= ~satya/docdir/spasojevic-tocs-afs-measurement-1996.pdf
which has some discussion of this topic in the scope of a broader
retrospective on the wide-area filesystem, but I was wondering if anyone knew of a more-focused reference for the global nature of the namespace.
Thanks,

Ben
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@= openafs.org
https://lists.openafs.org/mailman/listinfo/op= enafs-info
--0000000000005a856a059479905f-- From kaduk@mit.edu Wed Oct 23 00:35:23 2019 From: kaduk@mit.edu (Benjamin Kaduk) Date: Tue, 22 Oct 2019 16:35:23 -0700 Subject: [OpenAFS] OpenAFS Security Releases 1.8.5, 1.6.24 available Message-ID: <20191022233523.GK69013@kduck.mit.edu> --uZ3hkaAS1mZxFaxD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The OpenAFS Guardians are happy to announce the availability of Security Releases OpenAFS 1.8.5 and 1.6.24. Source files can be accessed via the web at: https://www.openafs.org/release/openafs-1.8.5.html https://www.openafs.org/release/openafs-1.6.24.html or via AFS at: UNIX: /afs/grand.central.org/software/openafs/1.8.5/ UNC: \\afs\grand.central.org\software\openafs\1.8.5\ UNIX: /afs/grand.central.org/software/openafs/1.6.24/ UNC: \\afs\grand.central.org\software\openafs\1.6.24\ These releases include fixes for three security advisories: http://openafs.org/pages/security/OPENAFS-SA-2019-001.txt http://openafs.org/pages/security/OPENAFS-SA-2019-002.txt http://openafs.org/pages/security/OPENAFS-SA-2019-003.txt OPENAFS-SA-2019-001 and OPENAFS-SA-2019-002 are for information disclosure over the network via uninitialized RPC output variables; they differ in that -001 affects RPCs that failed, whereas -002 can occur even for successful returns. OPENAFS-SA-2019-003 is a denial of service condition whereby anonymous attackers can cause pthreaded database servers to segmentation fault (NULL dereference). Please see the release notes and security advisories for additional details. Bug reports should be filed to openafs-bugs@openafs.org. Benjamin Kaduk for the OpenAFS Guardians --uZ3hkaAS1mZxFaxD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAl2vkjUACgkQKNmm82Tr dRKD7wwgxMveEcGpo+6JWhWHAk8zQFtVgNxO8AM7jhnD9lnrzgNxN9sO7dzUco3Z xAymT4uBgDMG+pw79NwysaVKjhksNeRtqvfigd0D7EfUs+zeGgcuy3KdFS/llYEE RKUMd8+XXpfulwRkNM8ebp+vAsZGJYNyy0IZjbtUDlgZNckDvLBtHEPwo/L0ukyR LcBobpjsN6CneW0xIVVcH1qQhebDwIE/cKOTUbKGawzahCOdmv4x8ZLFhMPYrJ7V 1/8Opn8/YJeEYEvAuQT4tFZo6wot+3XgniL94rJxzXA+EqqY8NRoM6Zv2n5JKAWa 56TL7I7iJY7DOMQQXduQWDF4L+H5ayUA6F/qexnlt5Xx2sTbtTeEES5SvP6VJQRv dbY9laThydVO8jshsfQ5RjE3OS5/QN1RkCooM/e6hHZ+pau3+65GbnVbJT6BVAwK N84v19TsciJ9+P5wybRi5TuQIJXsvtYGl4gbQ0h+b9gEXpzuzZmWHKUUAiMKraOu 0IkPRPXgDlvryg== =OnIu -----END PGP SIGNATURE----- --uZ3hkaAS1mZxFaxD--