-----------------------------------------------------------= -------------------------
----------------------------------------------= --------------------------------------------------------------------

/* kept in memory */
struct dcache {
=A0=A0=A0 struct afs_q=20 lruq;=A0=A0=A0=A0=A0 /* Free queue for in-memory images */
=A0=A0=A0 str= uct afs_q=20 dirty;=A0=A0=A0=A0 /* Queue of dirty entries that need written */
=A0=A0= =A0=20 afs_rwlock_t lock;=A0=A0=A0=A0=A0 /* Protects validPos, some f */
=A0=A0=A0 afs_rwlock_t tlock;=A0=A0=A0=A0 /* Atomizes updates to refCount *= /
=A0=A0=A0=20 afs_rwlock_t mflock;=A0=A0=A0 /* Atomizes accesses/updates to mflags */
= =A0=A0=A0 afs_size_t validPos;=A0=A0=A0 /* number of valid bytes during fetch */
= =A0=A0=A0 afs_int32 index;=A0=A0=A0=A0=A0=A0=A0 /* The index in the CacheInfo file *= /
=A0=A0=A0 short refCount;=A0=A0=A0=A0 /* Associated reference count. */
= =A0=A0=A0 char=20 dflags;=A0=A0=A0=A0=A0=A0=A0 /* Data flags */
=A0=A0=A0 char mflags;=A0= =A0=A0=A0=A0=A0=A0 /* Meta flags */
=A0=A0=A0 struct fcache f;=A0=A0=A0=A0=A0=A0=A0 /* disk image */
= =A0=A0=A0 afs_int32=20 bucket;=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* which bucket these dcache entries = are in */
=A0------------------------------------------------------------------------= ---------------------------------------------------------------------------= ----------------------------------
/* kept on disk and in dcache entries */
struct fcache {
=A0=A0=A0 struct VenusFid fid;=A0=A0=A0 /* Fid for this = file */
=A0=A0=A0 afs_int32 modTime;=A0=A0=A0=A0=A0 /* last time this entry was modified */<= br>=A0=A0=A0=20 afs_hyper_t versionNo;=A0 /* Associated data version number */
=A0=A0=A0= =20 afs_int32 chunk;=A0=A0=A0=A0=A0=A0=A0 /* Relative chunk number */
=A0=A0=A0 afs_dcache_id_t inode;=A0=A0=A0=A0=A0 /* Unix inode for this chun= k */
=A0=A0=A0=20 afs_int32 chunkBytes;=A0=A0 /* Num bytes in this chunk */
=A0=A0=A0 char= =20 states;=A0=A0=A0=A0=A0=A0=A0 /* Has this chunk been modified? */
}; --00163630f3eb155bf204872fa419-- From matt@linuxbox.com Sat May 22 17:34:06 2010 From: matt@linuxbox.com (Matt W. Benjamin) Date: Sat, 22 May 2010 12:34:06 -0400 (EDT) Subject: [OpenAFS-devel] Some doubts with Kernel Module data structures In-Reply-To: <257651333.2263.1274545745145.JavaMail.root@thunderbeast.private.linuxbox.com> Message-ID: <1200885903.2265.1274546045992.JavaMail.root@thunderbeast.private.linuxbox.com> hi, ----- "Sanket Agarwal" wrote: > I am looking into the core data structures of OpenAFS kernel module > for clients, of which I find that struct dcache and struct fcache will > be most important. I wish to ask you a few questions here: struct vcache > > 1. One thing that I am not able to understand on the afs caching part > is what exactly is afs cached if I have a miss. Is that we afs cache > the whole file from the Volume Server ? from the file server; the openafs cm caches segments, not whole files, and in fact afs programs do often call these "chunks," as perhaps you noticed... > Well that seems very > unreasonable because a large file then can never be read! it might be unreasonable, but the openafs cm does not do this > Okay > assuming it is that we afs cache chunks of some specified size. no need to assume it, that's what the cm in fact does > 2. What exactly does a struct dcache points to ? Is it a specific > chunk yes > and is this chunk size same as that of Page size of pages in the > memory(which the kernel will ultimately load as pages in the memory). no, typically a chunk is 64k, but you can set an alternate chunk size when the cm is started, see AFSD(8) > Or is it that dcache points to a specific file and keeps track of all > it's chunks ? a struct vcache is a cache entry for a specific file, it may or may not be up to date (see cache state flags); there may or may not be cached segments of any specific file; if there are, each is associated with a struct dcache > 3. What is the role played by the structure struct fcache, what does > it point to ? I'm not a dcache expert, but cribbing from the code, it looks as if an fcache is involved with representing chunks in the cm's persistent file cache > 4. I see that dcache is stored in the memory but fcache is disk saved > on disk( where , along with the afs cache ?) And why such a decision. > > Cheers > Sanket > There are papers from CMU which offer some insight into the choices that were made at different stages of AFS development. An -older- stage of the cm design is discussed in this http://www.cs.cmu.edu/afs/cs/project/coda-www/ResearchWebPages/docdir/s11.pdf There is some discussion of cache structure (including struct fcache, surprisingly), here: http://web.mit.edu/lugao/MacData/afs/dev.mit.edu/user/warlord/OldFiles/openafs-test/src/doc/pdf/fscm-ispec.pdf -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 From adeason@sinenomine.net Sat May 22 20:27:26 2010 From: adeason@sinenomine.net (Andrew Deason) Date: Sat, 22 May 2010 14:27:26 -0500 Subject: [OpenAFS-devel] Re: Some doubts with Kernel Module data structures References: <257651333.2263.1274545745145.JavaMail.root@thunderbeast.private.linuxbox.com> <1200885903.2265.1274546045992.JavaMail.root@thunderbeast.private.linuxbox.com> Message-ID: <20100522142726.e8c2abb0.adeason@sinenomine.net> On Sat, 22 May 2010 12:34:06 -0400 (EDT) "Matt W. Benjamin" wrote: > ----- "Sanket Agarwal" wrote: > > > I am looking into the core data structures of OpenAFS kernel module > > for clients, of which I find that struct dcache and struct fcache > > will be most important. I wish to ask you a few questions here: > > struct vcache I found this a bit confusing when I first looked at it, so a little more info... a vnode is the OS' filesystem-agnostic in-memory representation of a file. A vcache is the OpenAFS module's in-memory representation of a file. You can get a vnode from a vcache and a vcache from an AFS vnode a couple of different ways, depending on what the client OS is. That's what AFSTOV and VTOAFS are for. > > and is this chunk size same as that of Page size of pages in the > > memory(which the kernel will ultimately load as pages in the > > memory). > > no, typically a chunk is 64k, but you can set an alternate chunk size > when the cm is started, see AFSD(8) Default chunk sizes for a disk cache ranges from 256K to 1M, depending on the size of the cache. For caches smaller than around 500M, the chunksize is 256K; smaller than 1G and it's 512K. Larger and it's 1M. For memcache the default is 8k. > > 3. What is the role played by the structure struct fcache, what does > > it point to ? > > I'm not a dcache expert, but cribbing from the code, it looks as if > an fcache is involved with representing chunks in the cm's persistent > file cache > > > 4. I see that dcache is stored in the memory but fcache is disk > > saved on disk( where , along with the afs cache ?) And why such a > > decision. The CacheItems file is made up of a bunch of 'struct fcache's (each one representing a chunk, as Matt says). We need to save some information about each chunk to disk, so we can find them again. So when a client restarts and asks for file X chunk Y, we can find where that chunk is in the cache. -- Andrew Deason adeason@sinenomine.net From sanket@sanketagarwal.com Mon May 24 14:53:03 2010 From: sanket@sanketagarwal.com (Sanket Agarwal) Date: Mon, 24 May 2010 15:53:03 +0200 Subject: [OpenAFS-devel] Re: Some doubts with Kernel Module data structures In-Reply-To: <20100522142726.e8c2abb0.adeason@sinenomine.net> References: <257651333.2263.1274545745145.JavaMail.root@thunderbeast.private.linuxbox.com> <1200885903.2265.1274546045992.JavaMail.root@thunderbeast.private.linuxbox.com> <20100522142726.e8c2abb0.adeason@sinenomine.net> Message-ID: --00c09f88d1641852c80487575c93 Content-Type: text/plain; charset=ISO-8859-1 Okay, thanks for that help! It made reading the code easier. But I continue with my doubts: In lines in file src/afs/VNOPS/afs_vnop_read.c or src/afs/VNOPS/afs_vnop_write.c I am unable to track the macros for VNOP_READ and VNOP_WRITE. I do find some traces in IRIX/osi_vfs.h but that does not really helps. ---------------------------------- #ifdef AFS_SUN510_ENV { caller_context_t ct; VOP_RWLOCK(tfile->vnode, 1, &ct); code = VOP_WRITE(tfile->vnode, &tuio, 0, afs_osi_credp, &ct); VOP_RWUNLOCK(tfile->vnode, 1, &ct); } ----------------------------------- >From what I undestand this part does the OS dependent read from cache to memory and write to cache from memory. Cheers Sanket On Sat, May 22, 2010 at 9:27 PM, Andrew Deason wrote: > On Sat, 22 May 2010 12:34:06 -0400 (EDT) > "Matt W. Benjamin" wrote: > > > ----- "Sanket Agarwal" wrote: > > > > > I am looking into the core data structures of OpenAFS kernel module > > > for clients, of which I find that struct dcache and struct fcache > > > will be most important. I wish to ask you a few questions here: > > > > struct vcache > > I found this a bit confusing when I first looked at it, so a little more > info... a vnode is the OS' filesystem-agnostic in-memory representation > of a file. A vcache is the OpenAFS module's in-memory representation of > a file. You can get a vnode from a vcache and a vcache from an AFS vnode > a couple of different ways, depending on what the client OS is. That's > what AFSTOV and VTOAFS are for. > > > > and is this chunk size same as that of Page size of pages in the > > > memory(which the kernel will ultimately load as pages in the > > > memory). > > > > no, typically a chunk is 64k, but you can set an alternate chunk size > > when the cm is started, see AFSD(8) > > Default chunk sizes for a disk cache ranges from 256K to 1M, depending > on the size of the cache. For caches smaller than around 500M, the > chunksize is 256K; smaller than 1G and it's 512K. Larger and it's 1M. > > For memcache the default is 8k. > > > > 3. What is the role played by the structure struct fcache, what does > > > it point to ? > > > > I'm not a dcache expert, but cribbing from the code, it looks as if > > an fcache is involved with representing chunks in the cm's persistent > > file cache > > > > > 4. I see that dcache is stored in the memory but fcache is disk > > > saved on disk( where , along with the afs cache ?) And why such a > > > decision. > > The CacheItems file is made up of a bunch of 'struct fcache's (each one > representing a chunk, as Matt says). We need to save some information > about each chunk to disk, so we can find them again. So when a client > restarts and asks for file X chunk Y, we can find where that chunk is in > the cache. > > -- > Andrew Deason > adeason@sinenomine.net > > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel > --00c09f88d1641852c80487575c93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Okay, thanks for that help! It made reading the code easier.
But I conti= nue with my doubts:

In lines in file src/afs/VNOPS/afs_vnop_read.c o= r src/afs/VNOPS/afs_vnop_write.c I am unable to track the macros for VNOP_R= EAD and VNOP_WRITE. I do find some traces in IRIX/osi_vfs.h but that does n= ot really helps.

----------------------------------
#ifdef AFS_SUN510_ENV
=A0=A0= =A0 {
=A0=A0=A0 =A0=A0=A0 caller_context_t ct;

=A0=A0=A0 =A0=A0= =A0 VOP_RWLOCK(tfile->vnode, 1, &ct);
=A0=A0=A0 =A0=A0=A0 code = =3D VOP_WRITE(tfile->vnode, &tuio, 0, afs_osi_credp, &ct);
=A0=A0=A0 =A0=A0=A0 VOP_RWUNLOCK(tfile->vnode, 1, &ct);
=A0=A0=A0= }
-----------------------------------

From what I undestand this= part does the OS dependent read from cache to memory and write to cache fr= om memory.

Cheers
Sanket

On Sat, May 22, = 2010 at 9:27 PM, Andrew Deason <adeason@sinenomine.net> wrote:

On Sat, 22 May 2010 12:34:06 -0400 (EDT)
"Matt W. Benjamin" <matt@= linuxbox.com> wrote:

> ----- "Sanket Agarwal" <sanket@sanketagarwal.com> wrote:
>
> > I am looking into the core data structures of OpenAFS kernel modu= le
> > for clients, of which I find that struct dcache and struct fcache=
> > will be most important. I wish to ask you a few questions here: >
> struct vcache

I found this a bit confusing when I first looked at it, so a little m= ore
info... a vnode is the OS' filesystem-agnostic in-memory representation=
of a file. A vcache is the OpenAFS module's in-memory representation of=
a file. You can get a vnode from a vcache and a vcache from an AFS vnode a couple of different ways, depending on what the client OS is. That's<= br> what AFSTOV and VTOAFS are for.

> > and is this chunk size same as that of Page size of pages in the<= br> > > memory(which the kernel will ultimately load as pages in the
> > memory).
>
> no, typically a chunk is 64k, but you can set an alternate chunk size<= br> > when the cm is started, see AFSD(8)

Default chunk sizes for a disk cache ranges from 256K to 1M, dependin= g
on the size of the cache. For caches smaller than around 500M, the
chunksize is 256K; smaller than 1G and it's 512K. Larger and it's 1= M.

For memcache the default is 8k.

> > 3. What is the role played by the structure struct fcache, what d= oes
> > it point to ?
>
> I'm not a dcache expert, but cribbing from the code, it looks as i= f
> an fcache is involved with representing chunks in the cm's persist= ent
> file cache
>
> > 4. I see that dcache is stored in the memory but fcache is disk > > saved on disk( where , along with the afs cache ?) And why such a=
> > decision.

The CacheItems file is made up of a bunch of 'struct fcache's= (each one
representing a chunk, as Matt says). We need to save some information
about each chunk to disk, so we can find them again. So when a client
restarts and asks for file X chunk Y, we can find where that chunk is in the cache.

--
Andrew Deason
adeason@sinenomine.net

_______________________________________________
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org<= br> https://lists.openafs.org/mailman/listinfo/openafs-devel

--00c09f88d1641852c80487575c93-- From adeason@sinenomine.net Mon May 24 15:20:40 2010 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 24 May 2010 09:20:40 -0500 Subject: [OpenAFS-devel] Re: Some doubts with Kernel Module data structures References: <257651333.2263.1274545745145.JavaMail.root@thunderbeast.private.linuxbox.com> <1200885903.2265.1274546045992.JavaMail.root@thunderbeast.private.linuxbox.com> <20100522142726.e8c2abb0.adeason@sinenomine.net> Message-ID: <20100524092040.ac8c59ac.adeason@sinenomine.net> On Mon, 24 May 2010 15:53:03 +0200 Sanket Agarwal wrote: > Okay, thanks for that help! It made reading the code easier. But I > continue with my doubts: > > In lines in file src/afs/VNOPS/afs_vnop_read.c or > src/afs/VNOPS/afs_vnop_write.c I am unable to track the macros for > VNOP_READ and VNOP_WRITE. VOP_* macros come from the target kernel; OpenAFS does not define them. You have to look in the headers and source (or the API documentation) for e.g. linux or opensolaris to see what they do for those platforms. Typically they just expand to a function call that calls a function pointer derived from the vnode pointer. For example, on Solaris, VOP_WRITE(vp, foo) is effectively a call to (*(vp)->v_op->vop_write)(vp, foo). When looking around for OS-defined stuff like that, convenient sites are for Linux, for Solaris, and for FreeBSD, Darwin, and others (including Linux and Solaris, but with a different interface than LXR or src.opensolaris.org). -- Andrew Deason adeason@sinenomine.net From shadow@gmail.com Mon May 24 17:19:00 2010 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 24 May 2010 12:19:00 -0400 Subject: [OpenAFS-devel] Re: Some doubts with Kernel Module data structures In-Reply-To: <20100524092040.ac8c59ac.adeason@sinenomine.net> References: <257651333.2263.1274545745145.JavaMail.root@thunderbeast.private.linuxbox.com> <1200885903.2265.1274546045992.JavaMail.root@thunderbeast.private.linuxbox.com> <20100522142726.e8c2abb0.adeason@sinenomine.net> <20100524092040.ac8c59ac.adeason@sinenomine.net> Message-ID: On Mon, May 24, 2010 at 10:20 AM, Andrew Deason wr= ote: > On Mon, 24 May 2010 15:53:03 +0200 > Sanket Agarwal wrote: > >> Okay, thanks for that help! It made reading the code easier. =A0But I >> continue with my doubts: >> >> In lines in file src/afs/VNOPS/afs_vnop_read.c or >> src/afs/VNOPS/afs_vnop_write.c I am unable to track the macros for >> VNOP_READ and VNOP_WRITE. > > VOP_* macros come from the target kernel; OpenAFS does not define them. > You have to look in the headers and source (or the API documentation) > for e.g. linux or opensolaris to see what they do for those platforms. > > Typically they just expand to a function call that calls a function > pointer derived from the vnode pointer. For example, on Solaris, > VOP_WRITE(vp, foo) is effectively a call to > (*(vp)->v_op->vop_write)(vp, foo). > > When looking around for OS-defined stuff like that, convenient sites are > for Linux, for > Solaris, and for FreeBSD, Darwin, and others > (including Linux and Solaris, but with a different interface than LXR or > src.opensolaris.org). Basically, this is the I/O-to-disk. You'll want to do your work in the AFS module, which is to say, before VNOP_WRITE is called, and on reads, on the result of VNOP_READ. --=20 Derrick From sarawgi.aditya@gmail.com Mon May 24 17:46:13 2010 From: sarawgi.aditya@gmail.com (Aditya Sarawgi) Date: Mon, 24 May 2010 22:16:13 +0530 Subject: [OpenAFS-devel] Build issues on FreeBSD Message-ID: <4bfaad52.1065730a.47a3.6624@mx.google.com> Hi, After uupdating the openafs source I am unable to build openafs on FreeBSD I'm getting In file included from ./afsutil.h:27, from ./assert.c:21: /usr/include/sys/socket.h:71: error: conflicting types for 'socklen_t' /home/aditya/openafs/include/afs/stds.h:63: error: previous declaration of 'socklen_t' was here *** Error code 1 I think Change Ib5aeb600: Autoconf: Use a standard test for socklen_t http://gerrit.openafs.org/#change,1972 this commit broke the build. Please Fix Thanks Aditya Sarawgi From rra@stanford.edu Mon May 24 18:01:12 2010 From: rra@stanford.edu (Russ Allbery) Date: Mon, 24 May 2010 10:01:12 -0700 Subject: [OpenAFS-devel] Build issues on FreeBSD In-Reply-To: <4bfaad52.1065730a.47a3.6624@mx.google.com> (Aditya Sarawgi's message of "Mon, 24 May 2010 22:16:13 +0530") References: <4bfaad52.1065730a.47a3.6624@mx.google.com> Message-ID: <87k4qtxmhz.fsf@windlord.stanford.edu> Aditya Sarawgi writes: > After uupdating the openafs source I am unable to build openafs on FreeBSD > I'm getting > In file included from ./afsutil.h:27, > from ./assert.c:21: > /usr/include/sys/socket.h:71: error: conflicting types for 'socklen_t' > /home/aditya/openafs/include/afs/stds.h:63: error: previous declaration of 'socklen_t' was here > *** Error code 1 > I think > Change Ib5aeb600: Autoconf: Use a standard test for socklen_t > http://gerrit.openafs.org/#change,1972 > this commit broke the build. Please Fix Could you provide some more information, particularly the config.log output around socklen_t? For some reason, configure didn't think your system had a socklen_t type despite the fact that it does. -- Russ Allbery (rra@stanford.edu) From sxw@inf.ed.ac.uk Mon May 24 18:09:02 2010 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Mon, 24 May 2010 18:09:02 +0100 Subject: [OpenAFS-devel] Build issues on FreeBSD In-Reply-To: <4bfaad52.1065730a.47a3.6624@mx.google.com> References: <4bfaad52.1065730a.47a3.6624@mx.google.com> Message-ID: On 24 May 2010, at 17:46, Aditya Sarawgi wrote: > Hi, >=20 > After uupdating the openafs source I am unable to build openafs on = FreeBSD Did you run regen.sh, or otherwise regenerate the configure script after = updating your tree? S. From sarawgi.aditya@gmail.com Mon May 24 18:58:54 2010 From: sarawgi.aditya@gmail.com (Aditya Sarawgi) Date: Mon, 24 May 2010 23:28:54 +0530 Subject: [OpenAFS-devel] Build issues on FreeBSD In-Reply-To: References: <4bfaad52.1065730a.47a3.6624@mx.google.com> Message-ID: <4bfabe5b.0663730a.1ab6.7358@mx.google.com> On Mon, May 24, 2010 at 06:09:02PM +0100, Simon Wilkinson wrote: > > On 24 May 2010, at 17:46, Aditya Sarawgi wrote: > > > Hi, > > > > After uupdating the openafs source I am unable to build openafs on FreeBSD > > Did you run regen.sh, or otherwise regenerate the configure script after updating your tree? > > S. > Hi, How stupid of me :) Thanks and sorry for raising the false alarm Cheers Aditya Sarawgi From mdw@umich.edu Tue May 25 07:17:38 2010 From: mdw@umich.edu (Marcus Watts) Date: Tue, 25 May 2010 02:17:38 -0400 Subject: [OpenAFS-devel] rxk5 - may 2010 Message-ID: I had promised to have a fully separated set of patches for rxk5 by now. I don't, which is perhaps a good thing. 1. at workshop this week 2. rxk5 nearterm schedule 3. hackathon issues 4. revising the rxk5 paper ____ 1. at workshop this week So, the good news is I'll be at the OpenAFS workshop this week. If you want to talk to me about something here's your chance. I'll be driving down and back. On friday I'll have a fairly tight schedule since I hope to wind up in Rochester NY very late that night. ____ 2. rxk5 nearterm schedule So far as rxk5 goes - I expect to have a tarball containing m83 this week. Was hoping to get that at least done before the workshop, but, well, sleep is probably the best thing now. The next thing I'll be doing is partially separated patches. That is, a set of patches to go from the base version to rxk5. That will be nominally "cvs head 2009/06/21" which is nearly but not exactly 1.5.61. These will probably be a small number of *big* patches, I'm not going to put a lot of work into separating things for this. The next thing after that will be to port rxk5 forward to 1.5.74. I expect some of those changes will overlap what I've got in weird ways, which is the big reason I don't want to put much time into patch microsplitting before this. ____ 3. hackathon issues So far as other stuff goes. At last fall's hackathon and eu workshop, a number of issues got raised: 1. authenticator max_calls. I think I should have seen a proposal or test release for this by now? 2. prf rfc 4402. Want to look into this, haven't yet. 3. initial packet enc. Leaving this for rxgk. 4. k5ssl. I've heard confusing stories about what's happening with heimdal / hcrypto / afs, waiting to see what winds up in the tree. 5. ubik_SRXServerProcV2. ya ya ya. Ok, maybe I'll be putting m84 out above, if I didn't remember to do this. 6. cell_max. " " " 7. cm properties. I'll probably punt on this. What I have now works. 8. way for app to add data to authenticator. I may put this off for later, such as combining it with some form of callback channel protection or some such. 9. one fileserver at a time conversion. I spent some time thinking about this. While many parts look easy, the middle bit started looking more and more like rxgk. Since the rxgk folks will be doing this anyways, I'm not seeing a lot of value to duplicating what I understand they'll have done by september. ____ 4. revising the rxk5 paper Also I should put together some form of revised rxk5 paper. I know various folks have pointed out various minor issues; but other than what I wrote down at the hackathon I have no other recollection what those issues are. If folks could forward those issues to me I'd be grateful. Hope to see all you folks at the workshop! -Marcus Watts From mdw@umich.edu Thu May 27 21:05:08 2010 From: mdw@umich.edu (Marcus Watts) Date: Thu, 27 May 2010 16:05:08 -0400 Subject: [OpenAFS-devel] openafs rxk5 m84 - snapshot Message-ID: I've got a new snapshot for openafs rxk5 - "m84". I'm not sure which version folks would have seen last, so I'm not sure just what changes I've made since. The last few changes I've made here include: 1. rxk5 - report client principal by name not by weird number when discarding expired tokens. 2. white space fix changes. 3. 2009 hackathon issue #5 "ubik_SRXServerProcV2 and afsconf_ServerAuthV2". 4. 2009 hackathon issue #6 "cell_max 256". Normally, I'd do this as a diff, but since the base for this is "cvs 2009/06/21", and I haven't yet finished the white space diff process - I'm going to put this out as a complete self-contained source tarball. cvs 2009/06/21 is just before the git import process, so it is very nearly but not exactly 1.5.61. I'm attempting to use the original "4 space indent, 8 space tab" convention. White space in 1.5.61 is sufficiently random it was starting to annoy me. What I have here is not perfect, but it annoys me much less. Without more ado, here's the snapshot, /afs/umich.edu/group/itd/build/mdw/openafs/patches/openafs-m84.tar.bz2 I expect to have a few more code & bug fixes, updates to hopefully bring it up to 1.5.74^H5, and orthogonally to that, a split process that will result in a whole bunch of sequential diffs to go from release code to rxk5. Eventually, those sequential diffs can turn into something git understands. -Marcus Watts From mdw@umich.edu Fri May 28 07:06:26 2010 From: mdw@umich.edu (Marcus Watts) Date: Fri, 28 May 2010 02:06:26 -0400 Subject: [OpenAFS-devel] openafs rxk5 m84 - as patches Message-ID: There was some dismay about seeing a tarball at the workshop, even though I promised to have better patches "in due course". Even though I can't make those better patches yet, I can certainly make not so good patches now. In this directory, /afs/umich.edu/user/m/d/mdw/build/openafs/patches/ find openafs-20090621.tar.bz2 openafs-h20090621-m84-1-st.diff.bz2 openafs-h20090621-m84-2-r.diff.bz2 openafs-h20090621-m84-3-k5ssl.diff.bz2 openafs-h20090621-m84-4-rxk5.diff.bz2 openafs-h20090621-m84-5-other.diff.bz2 openafs-h20090621-m84-6-afskfw.diff.bz2 openafs-h20090621-m84-7-changed.diff.bz2 openafs-h20090621-m84-8-deleted.diff.bz2 result of applying these patches to the tarball "cvs head 2009/06/21" should exactly match the m84 tarball. in slightly more detail, 20090621.tar.bz2 it came from cvs 1-st whitespace (canonical tabs and trim trailing whitespace) 2-r remove register 3-k5ssl add k5ssl support 4-rxk5 add rxk5 security class 5-other other new files 6-afskfw move afskfw to here. 7-changed other file changes 8-deleted delete files that were moved or removed. The whitespace & register patches are big but mindless. k5ssl & rxk5 patches add complete directories containing self-contained code. not much sense to dividing those further. After that these patches become not so good. These patches do have one property that might not be true in later patch sets: all the intermediate versions should be buildable, albeit with files that might not be useful. -Marcus Watts From rdw@steadingsoftware.com Mon May 31 10:33:39 2010 From: rdw@steadingsoftware.com (Rod Widdowson) Date: Mon, 31 May 2010 10:33:39 +0100 Subject: [OpenAFS-devel] Building with --enable-checking Message-ID: <002e01cb00a4$5bc82130$13586390$@com> Folks, I am having some difficulty getting "configure --enable-checking" to work. I am running from the current HEAD but when I build I am flooded with warnings, so I am pretty convinced that I've missed the magical configuration step to turn on the suppression of warnings in some directories... I've googled around and had a trawl through the archives to no immediate avail; so what am I missing? Thanks /Rod From sxw@inf.ed.ac.uk Mon May 31 10:43:19 2010 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Mon, 31 May 2010 10:43:19 +0100 Subject: [OpenAFS-devel] Building with --enable-checking In-Reply-To: <002e01cb00a4$5bc82130$13586390$@com> References: <002e01cb00a4$5bc82130$13586390$@com> Message-ID: <40B3DE59-0DA7-43B7-A8BB-3EFF1C6FDC60@inf.ed.ac.uk> On 31 May 2010, at 10:33, Rod Widdowson wrote: >=20 > I've googled around and had a trawl through the archives to no = immediate > avail; so what am I missing? In theory, nothing ./configure --enable-checking should be all you need to turn on a checked build, with the appropriate = suppression of 'known' warnings. Now, this only works with gcc 4.2 or later. If you're running an older = version of gcc, turning on enable-checking will probably break things = (we should probably check for this in the configure script). Also, the = warnings that are produced varies by platform, and compiler. I test = regularly on Mac OS X, and Andrew and Marc pick up warnings on i386 and = x86_64 Linux. On other platforms, your mileage will vary. The best bet would probably be if you put the output from make = somewhere, so we can see the errors you're getting. Cheers, Simon. From rdw@steadingsoftware.com Mon May 31 10:48:41 2010 From: rdw@steadingsoftware.com (Rod Widdowson) Date: Mon, 31 May 2010 10:48:41 +0100 Subject: [OpenAFS-devel] Building with --enable-checking In-Reply-To: <40B3DE59-0DA7-43B7-A8BB-3EFF1C6FDC60@inf.ed.ac.uk> References: <002e01cb00a4$5bc82130$13586390$@com> <40B3DE59-0DA7-43B7-A8BB-3EFF1C6FDC60@inf.ed.ac.uk> Message-ID: <002f01cb00a6$785998e0$690ccaa0$@com> GCC 4.1.2 looks pretty much like a bad idea (another strike against Centos5). I'll upgrade to 4.2 and then report back. Thanks /R > -----Original Message----- > From: openafs-devel-admin@openafs.org [mailto:openafs-devel-admin@openafs.org] > On Behalf Of Simon Wilkinson > Sent: 31 May 2010 10:43 > To: Rod Widdowson > Cc: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] Building with --enable-checking > > > On 31 May 2010, at 10:33, Rod Widdowson wrote: > > > > I've googled around and had a trawl through the archives to no immediate > > avail; so what am I missing? > > In theory, nothing > > ./configure --enable-checking > > should be all you need to turn on a checked build, with the appropriate > suppression of 'known' warnings. > > Now, this only works with gcc 4.2 or later. If you're running an older version > of gcc, turning on enable-checking will probably break things (we should > probably check for this in the configure script). Also, the warnings that are > produced varies by platform, and compiler. I test regularly on Mac OS X, and > Andrew and Marc pick up warnings on i386 and x86_64 Linux. On other platforms, > your mileage will vary. > > The best bet would probably be if you put the output from make somewhere, so > we can see the errors you're getting. > > Cheers, > > Simon. > > > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel From sanket@sanketagarwal.com Mon May 31 14:45:35 2010 From: sanket@sanketagarwal.com (Sanket Agarwal) Date: Mon, 31 May 2010 15:45:35 +0200 Subject: [OpenAFS-devel] Encrypted Storage -- GSoC Proposal Message-ID: --00c09f88ce8146fa640487e41226 Content-Type: text/plain; charset=ISO-8859-1 Sorry to be late to let you all know about the project proposal. But here is the proposal picked up straight from socghop( I am lazy enough :D ): ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Title: Encrypted storage ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Abstract: The AFS protocol offers encryption for data transport from client to server. However, that data is stored on the server in cleartext, where it can potentially be read by the administrators of that server. This poses a real world problem for organisations who wish to outsource the provision of their file storage, whilst keeping their data confidential. This project would augment the existing AFS client to support encrypting data blocks before sending them to the file server. Proposal: As mentioned above the idea is to develop an encrypting mechanism at the client side to send cipher text data to the file servers. The scope of such encryption shall be limited to Files as Directory structure modification will need the server's support. The idea is to provide a working prototype in the given time frame of 3 months. Assuming user has a user key( a Public key pair ) a Use Case is as follows, The general work flow of the encryption mechanism would be: *) User writes to a new file on the CM side and tells the client to *encrypt* the data before being sent over the wire. *) The Client generates a Random Key and encrypts the data using an encryption algorithm. *) The Client then constructs a metadata file which contains information+random key and encrypts that using the user key. *) The Client while sending the file also sends the metadata file. This is to identify later if a file was encrypted or not. While requesting for an encrypted file: *) Cache manager checks whether the metadata file exists on the server. *) If no, then no decryption is required. *) If yes, metadata is decrypted using the private key and random key is obtained. *) Any request for a new block from the server will have to be processed through a decryption mechanism. There are several points that need to be noted: *) It is assumed that libhcrypto is available as a part of my project. I will be using it for developing the required interface. *) Regarding the metadata files, there is a GSoC based on Providing common Extended Attribute Support similar to POSIX Xattributes. The future plan would be to fold the metadata files into those xattrbs. *) OpenAFS maintains a 2 level cache, one which resides on the Secondary Memory, and one which resides in the Main Memory. If there is a new block request it is first brought in the Secondary Mem and loaded to Main Memory when User Application requests it. My scheme will be something like this: -> If a new block request is made for an encrypted file, the encrypted block will be kept *as-it-is* w/o any decryption. Only when the block is moved to the Main Memory will it be decrypted. This will avoid issues with chunking. -> Similarly if a block from Main Memory is written back to AFS cache, it'll be encrypted. Assuming MM hits are large, this would not incur much Encryption Call overhead. -> Hence there will be a logial partition b/w Secondary Cache which is on Fileserver's end and Main Cache which is at User Application end. *) In effect, what I'll be doing is adding an interface to the cache manager that allows manipulation of data in the process of it being read from the disk cache, and placed in the page cache (and similarly, when it is being written to the disk cache from the page cache) [ As directed by Simon. ] -> Firstly, a no-op interface which'll intercept the calls but make no changes to the scheme. Some debug messages may be output. -> Inspecting metadata on the disk. -> Implementing the encryption scheme. --00c09f88ce8146fa640487e41226 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry to be late to let you all know about the project proposal. But here i= s the proposal picked up straight from socghop( I am lazy enough :D ):
<= br>

---------------------------------------------------------------------= ---------------------------------------------------------------------------= ----------------------------------

Title: Encrypted storage

------------------------------------------------------------------------= ---------------------------------------------------------------------------= -------------------------------

Abstract:

=A0

The AFS protocol offers encryption for data transport from client to=20 server. However, that data is stored on the server in cleartext, where=20 it can potentially be read by the administrators of that server. This=20 poses a real world problem for organisations who wish to outsource the=20 provision of their file storage, whilst keeping their data confidential. This project would augment the existing AFS client to support=20 encrypting data blocks before sending them to the file server.

=A0

Proposal:

=A0

As mentioned above the idea is to develop an encrypting mechanism at=20 the client side to send cipher text data to the file servers. The scope=20 of such encryption shall be limited to Files as Directory structure=20 modification will need the server's support. The idea is to provide a= =20 working prototype in the given time frame of 3 months.

=A0

Assuming user has a user key( a Public key pair ) a Use Case is as=20 follows,

=A0

The general work flow of the encryption mechanism would be:

=A0

*) User writes to a new file on the CM side and tells the client to=20 *encrypt* the data before being sent over the wire.

*) The Client generates a Random Key and encrypts the data using an=20 encryption algorithm.

*) The Client then constructs a metadata file which contains=20 information+random key and encrypts that using the user key.

*) The Client while=A0 sending the file also sends the metadata file.=20 This is to identify later if a file was encrypted or not.

=A0

While requesting for an encrypted file:

=A0

*) Cache manager checks whether the metadata file exists on the=20 server.

*) If no, then no decryption is required.

*) If yes, metadata is decrypted using the private key and random key is obtained.

*) Any request for a new block from the server will have to be=20 processed through a decryption mechanism.

=A0

There are several points that need to be noted:

=A0

*) It is assumed that libhcrypto is available as a part of my=20 project. I will be using it for developing the required interface.

*) Regarding the metadata files, there is a GSoC based on Providing=20 common Extended Attribute Support similar to POSIX Xattributes. The=20 future plan would be to fold the metadata files into those xattrbs.

*) OpenAFS maintains a 2 level cache, one which resides on the=20 Secondary Memory, and one which resides in the Main Memory. If there is a new block request it is first brought in the Secondary Mem and loaded=20 to Main Memory when User Application requests it. My scheme will be=20 something like this:

=A0=A0=A0 -> If a new block request is made for an encrypted file, th= e=20 encrypted block will be kept *as-it-is* w/o any decryption. Only when=20 the block is moved to the Main Memory will it be =A0=A0 =A0=A0=A0 =A0=A0=A0= =A0=A0=A0=20 =A0decrypted. This will avoid issues with chunking.

=A0=A0=A0 -> Similarly if a block from Main Memory is written back to= =20 AFS cache, it'll be encrypted. Assuming MM hits are large, this would= =20 not incur much Encryption Call overhead.

=A0=A0=A0 -> Hence there will be a logial partition b/w Secondary Cac= he=20 which is on Fileserver's end and Main Cache which is at User Applicatio= n end.

*) In effect, what I'll be doing is adding an interface to the cache= =20 manager that allows manipulation of data in the process of it being read from the disk cache, and placed in the page cache (and similarly, when=20 it is being written to the disk cache from the page cache) [ As directed by Simon. ]

=A0=A0=A0 -> Firstly, a no-op interface which'll intercept the ca= lls but make no changes to the scheme. Some debug messages may be output.

=A0=A0=A0 -> Inspecting metadata on the disk.

=A0=A0=A0 -> Implementing the encryption scheme.

--00c09f88ce8146fa640487e41226-- From joonas2_91@hotmail.com Fri May 21 08:39:24 2010 From: joonas2_91@hotmail.com (Joonas Huhtala) Date: Fri, 21 May 2010 10:39:24 +0300 Subject: [OpenAFS-devel] openAFS windows client create time problem Message-ID: --_5a7ffac7-7007-486b-864e-344daa4eec16_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I have problem with files create times. In our system we have folders=20 in afs where files automatically remove after 10 days about that when you copy file to folder. Delete-script look files create time and delete all files witch are older than 10 days. Problem is that when I copy file from windows to afs it didn=92t change file create time to time when I=20 copy file. I have file: windows_test Files properties Windows own folder: Created 10.May 2010=2C 9:40:52 Modified: 10. May 2010=2C 9:41:32 Accessed: 21. May 2010=2C 9:49:23 When I copy file to afs folder: Created: 10. May 2010=2C 9:41:32 Modified: 10. May 2010=2C 9:41:32 Accessed: 10. May 2010=2C 9:41:32 When I copy file to other Windows own folder: Created: 21. May 2010=2C 9:56:37 Modified: 10. May 2010=2C 9:41:32 Accessed: 21. May 2010=2C 9:56:39 When I copy file from Linux to afs it change create time to time when I cop= y=20 file to afs folder. I test afs client version 1.5.6500 in windows XP and 1.5.7400 in windows 7. -Joonas Huhtala =20 _________________________________________________________________ Windows puhelimella saat enemm=E4n vastinetta rahoillesi. http://www.windowsmobile.fi= --_5a7ffac7-7007-486b-864e-344daa4eec16_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I have problem with files create times. In our system we have folders
i= n afs where files automatically remove after 10 days about that when
you= copy file to folder. Delete-script look files create time and delete
al= l files witch are older than 10 days. Problem is that when I copy file
f= rom windows to afs it didn=92t change file create time to time when I
c= opy file.

I have file: windows_test

Files properties Windows = own folder:

Created 10.May 2010=2C 9:40:52
Modified: 10. May 2010= =2C 9:41:32
Accessed: 21. May 2010=2C 9:49:23

When I copy file to= afs folder:

Created: 10. May 2010=2C 9:41:32
Modified: 10. May 2= 010=2C 9:41:32
Accessed: 10. May 2010=2C 9:41:32

When I copy file= to other Windows own folder:

Created: 21. May 2010=2C 9:56:37
Mo= dified: 10. May 2010=2C 9:41:32
Accessed: 21. May 2010=2C 9:56:39
When I copy file from Linux to afs it change create time to time when I co= py
file to afs folder.

I test afs client version 1.5.6500 in win= dows XP and 1.5.7400 in windows 7.

-Joonas Huhtala
=

Windows puhelimella saat enemm=E4n vastinetta rahoillesi. Vertaile t=E4st=E4. = --_5a7ffac7-7007-486b-864e-344daa4eec16_-- From FBA@zurich.ibm.com Fri May 21 17:21:23 2010 From: FBA@zurich.ibm.com (Frank Bagehorn) Date: Fri, 21 May 2010 18:21:23 +0200 Subject: [OpenAFS-devel] afsd crashes SLES11 SP1 system Message-ID: This is an S/MIME signed message. ---------z1643_boundary_sign Content-Type: text/plain; charset="US-ASCII" Hi all, I upgraded one of my servers to SLES 11 SP1 (with the code that I think is the one to be released beginning of June) for testing. I have OpenAFS 1.4.12 installed (the SLES 11 RPMs from the download area). As soon as afsd starts, the machine freezes completely and needs a hard reset. I compiled the 1.5.74 version on that box and tried that, but same result. I don't see any useful messages in the log, /var/log/messages only shows the usual things about the kernel being tainted: May 21 18:04:35 erlach kernel: [ 2020.251214] libafs: module license 'http://www.openafs.org/dl/license10.html' taints kernel. May 21 18:04:35 erlach kernel: [ 2020.251222] Disabling lock debugging due to kernel taint What should I do to gather more useful information about the possible root cause of this ? The kernel in question is 2.6.32.12-0.6.2 according to Novell/SuSE numbering. Regards Frank ---------------------------------------------------------------------------- Dr. Frank Bagehorn Manager ZRL Information Services Sr. IT Architect / Certified IT Architect IBM Zurich Research Lab. Saeumerstr. 4 CH-8803 Rueschlikon Switzerland ---------------------------------------------------------------------------- SMTP: fba@zurich.ibm.com Notes: Frank Bagehorn/Zurich/IBM@IBMCH phone: ++41 (044) 724 83 23 fax: ++41 (044) 724 89 59 ---------z1643_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIIe1AIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIIbLDCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggMDMIICbAIRALkvYMyIn6F6Rgm4W3Bsiq8w DQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8 MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAt IEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVz ZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMB4XDTk4MDUxODAwMDAwMFoX DTI4MDgwMTIzNTk1OVowgcExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8 MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAt IEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVz ZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQCniAEhdCznGgPwmOGXPA8hCPGc25fpmvzCBAYTvl9SyMweLBJWLLgBaSzMmR+t sJaueQTyEznBe5i6CCzowoQTLKpp6Qn0x6kCpELCI09K2PAOovsxbMnmb5knB/Xm9Ex4nm3rRob6 uYbJVPKyxK/URhxayRUw/w1s9S0Obc5/dwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAHIu+X/R8XH7 xJ72xV5RikCYuGj4mxyD2OKdvf/toeZm6i8J9MrX6qUrlfYkYIZNRC6DpcQtoNOueGlvctpsrgjw Y5I35rvEMBetd8xJNarP2I/RvrcYlkdzalQiNGQtthabWVu0UVk6swsU9BLfZ6D0rTJkXrFGcieM EnvFRLSuMIIFLDCCBJWgAwIBAgIQOHHBU5PI6PSfHgxNDfRmQzANBgkqhkiG9w0BAQUFADCBwTEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1 YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAx OTk4IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmswHhcNMDMwNTA2MDAwMDAwWhcNMDgwNTA1MjM1OTU5WjCB+TEL MAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29y cG9yYXRpb24xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTAzMTAwLgYDVQQLEydD bGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExJDAiBgNVBAMTG0lCTSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1WetNd2gfv1X YdadpxfLuaONI1yc6Ldn5xdIGH25IOEIsBRR66+ge5u4DkiaskjmT90D5DQv5Y3NHs5mvhNGnDcM 6SxhL/Sj5Fnn6W4nuW1dx1WCwdTqqocOm8XWEB6Cqk3PrvQlVV9SzhOELUBp8wgEfCYluoUbgjLf 04ffugECAwEAAaOCAekwggHlMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMAsGA1UdDwQE AwIBBjARBglghkgBhvhCAQEEBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVM YWJlbDItMTI3MB0GA1UdDgQWBBSRwXOwc9XZknRnzRvxURQ0MbYsWjCB6AYDVR0jBIHgMIHdoYHH pIHEMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsTM0Ns YXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgGA1UE CxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29ya4IRALkvYMyIn6F6Rgm4W3Bsiq8wDQYJKoZIhvcN AQEFBQADgYEACBgFEwMbNSXwLj3nIObITvxAdLFCOSkpsnrWLQaRJgZSaRFhzdzMpSWRXex0dZ7b yy7RJE7wcqFfN9R1HYPafpSLE5GZH+2hua7GWR/CodYO81W4kPSIJXV7ZxdP2p/fy8zMyILnmVCa cKhR9ODXfWi8z9XUQjZpPXzUda7+kzwwggUsMIIElaADAgECAhA4ccFTk8jo9J8eDE0N9GZDMA0G CSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6 BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBH MjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMzA1MDYwMDAwMDBaFw0w ODA1MDUyMzU5NTlaMIH5MQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNp bmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDMxMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEk MCIGA1UEAxMbSUJNIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDVZ6013aB+/Vdh1p2nF8u5o40jXJzot2fnF0gYfbkg4QiwFFHrr6B7m7gOSJqySOZP 3QPkNC/ljc0ezma+E0acNwzpLGEv9KPkWefpbie5bV3HVYLB1Oqqhw6bxdYQHoKqTc+u9CVVX1LO E4QtQGnzCAR8JiW6hRuCMt/Th9+6AQIDAQABo4IB6TCCAeUwEgYDVR0TAQH/BAgwBgEB/wIBADBE BgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNh Mi1nMi5jcmwwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMjcwHQYDVR0OBBYEFJHBc7Bz1dmSdGfNG/FRFDQxtixa MIHoBgNVHSMEgeAwgd2hgcekgcQwgcExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3Jp emVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrghEAuS9gzIifoXpG CbhbcGyKrzANBgkqhkiG9w0BAQUFAAOBgQAIGAUTAxs1JfAuPecg5shO/EB0sUI5KSmyetYtBpEm BlJpEWHN3MylJZFd7HR1ntvLLtEkTvByoV831HUdg9p+lIsTkZkf7aG5rsZZH8Kh1g7zVbiQ9Igl dXtnF0/an9/LzMzIgueZUJpwqFH04Nd9aLzP1dRCNmk9fNR1rv6TPDCCBVswggTEoAMCAQICEDNm l/4zSQSeFrdeqCvFdnEwDQYJKoZIhvcNAQEFBQAwgfkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwMzEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MDkwNjI5MDAwMDAwWhcNMTAwNjI5MjM1OTU5WjCBhzEuMCwGA1UEChQlSW50ZXJuYXRpb25hbCBC dXNpbmVzcyBNYWNoaW5lcyBDb3JwLjEXMBUGA1UEAwwORnJhbmsgQmFnZWhvcm4xGTAXBgoJkiaJ k/IsZAEBFAk5OTk3MzA4NDgxITAfBgkqhkiG9w0BCQEWEmZiYUB6dXJpY2guaWJtLmNvbTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA60/mBJ48Fi694hQk3uCjIaTnnxIJ2sAHMNj2NLUUus+/ +AgDBLmRj46x8MWDZW3e2OnZTSVTKxmwbJ/+c7UGr2pxvf48TulHLQ6b7V/mRQ6ElJphlv86222q uXBJ+z+Vk2AHznt0XPjqmYWHkjVB0B6RaH9lal3rjsf5jrkuYRUCAwEAAaOCAlIwggJOMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgWgMGYGA1UdHwRfMF0wW6BZoFeGVWh0dHA6Ly9vbnNpdGVjcmwudmVy aXNpZ24uY29tL0ludGVybmF0aW9uYWxCdXNpbmVzc01hY2hpbmVzQ29ycENvcnBvcmF0ZUNJTy9M YXRlc3RDUkwwggEpBgNVHSAEggEgMIIBHDCCARgGC2CGSAGG+EUBBxcCMIIBBzArBggrBgEFBQcC ARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjCB1wYIKwYBBQUHAgIwgcoagcdOb3Rp Y2UgVGV4dD1OT1RJQ0U6IFByaXZhdGUga2V5IG1heSBiZSByZWNvdmVyZWQgYnkgVmVyaVNpZ24n cyBjdXN0b21lciB3aG8gbWF5IGJlIGFibGUgdG8gZGVjcnlwdCBtZXNzYWdlcyB5b3Ugc2VuZCB0 byBjZXJ0aWZpY2F0ZSBob2xkZXIuICBVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMB8GA1UdIwQYMBaAFJHBc7Bz1dmSdGfNG/FRFDQxtixa MB0GA1UdDgQWBBTQEm87nuzyRj76RN7olRROJrWETjAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOg FAwSZmJhQHp1cmljaC5pYm0uY29tMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBglg hkgBhvhCAQEEBAMCBaAwDQYJKoZIhvcNAQEFBQADgYEAfJimCPnPWPYk77bvoBNtGLzk7wcHkUbN R0gBmL5w6alO4eRdn0ELeeNEkUusIrTYR27CnwfEnUUbPDSipMzYOmPs94Fdjh0QW4z/GhAZ441Z e5sLq7BXc3UxfKchO98NICQP4vQEG10+fcltG1I10YZRk4zJVz47/mAYqURn3BwwggVbMIIExKAD AgECAhAzZpf+M0kEnha3XqgrxXZxMA0GCSqGSIb3DQEBBQUAMIH5MQswCQYDVQQGEwJVUzE0MDIG A1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDMxMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MB4XDTA5MDYyOTAwMDAwMFoXDTEwMDYyOTIzNTk1OVowgYcxLjAsBgNVBAoUJUludGVybmF0 aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycC4xFzAVBgNVBAMMDkZyYW5rIEJhZ2Vob3JuMRkw FwYKCZImiZPyLGQBARQJOTk5NzMwODQ4MSEwHwYJKoZIhvcNAQkBFhJmYmFAenVyaWNoLmlibS5j b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOtP5gSePBYuveIUJN7goyGk558SCdrABzDY 9jS1FLrPv/gIAwS5kY+OsfDFg2Vt3tjp2U0lUysZsGyf/nO1Bq9qcb3+PE7pRy0Om+1f5kUOhJSa YZb/OtttqrlwSfs/lZNgB857dFz46pmFh5I1QdAekWh/ZWpd647H+Y65LmEVAgMBAAGjggJSMIIC TjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDBmBgNVHR8EXzBdMFugWaBXhlVodHRwOi8vb25zaXRl Y3JsLnZlcmlzaWduLmNvbS9JbnRlcm5hdGlvbmFsQnVzaW5lc3NNYWNoaW5lc0NvcnBDb3Jwb3Jh dGVDSU8vTGF0ZXN0Q1JMMIIBKQYDVR0gBIIBIDCCARwwggEYBgtghkgBhvhFAQcXAjCCAQcwKwYI KwYBBQUHAgEWH2h0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwgdcGCCsGAQUFBwICMIHK GoHHTm90aWNlIFRleHQ9Tk9USUNFOiBQcml2YXRlIGtleSBtYXkgYmUgcmVjb3ZlcmVkIGJ5IFZl cmlTaWduJ3MgY3VzdG9tZXIgd2hvIG1heSBiZSBhYmxlIHRvIGRlY3J5cHQgbWVzc2FnZXMgeW91 IHNlbmQgdG8gY2VydGlmaWNhdGUgaG9sZGVyLiAgVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAfBgNVHSMEGDAWgBSRwXOwc9XZknRnzRvx URQ0MbYsWjAdBgNVHQ4EFgQU0BJvO57s8kY++kTe6JUUTia1hE4wLQYDVR0RBCYwJKAiBgorBgEE AYI3FAIDoBQMEmZiYUB6dXJpY2guaWJtLmNvbTAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYJYIZIAYb4QgEBBAQDAgWgMA0GCSqGSIb3DQEBBQUAA4GBAHyYpgj5z1j2JO+276ATbRi8 5O8HB5FGzUdIAZi+cOmpTuHkXZ9BC3njRJFLrCK02Eduwp8HxJ1FGzw0oqTM2Dpj7PeBXY4dEFuM /xoQGeONWXubC6uwV3N1MXynITvfDSAkD+L0BBtdPn3JbRtSNdGGUZOMyVc+O/5gGKlEZ9wcMYID gzCCA38CAQEwggEOMIH5MQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNp bmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDMxMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEk MCIGA1UEAxMbSUJNIENlcnRpZmljYXRpb24gQXV0aG9yaXR5AhAzZpf+M0kEnha3XqgrxXZxMAkG BSsOAwIaBQCgggHJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEw MDUyMTE2MjEyMlowIwYJKoZIhvcNAQkEMRYEFLNZzzuC2Kka8f1IMS2QdzdvQqz7MEMGCSqGSIb3 DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcNAwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMC AgEoMIIBIwYLKoZIhvcNAQkQAgsxggESoIIBDjCB+TELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0lu dGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTAzMTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExJDAiBgNVBAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQM2aX /jNJBJ4Wt16oK8V2cTANBgkqhkiG9w0BAQEFAASBgLM1UObRgOFmNtGp5STByeay3eDtyDva5kET oU1XhJ6ve/HSkC8xXjatiQ6UG+huHcwGU/LnT2pHZlmio+ip+86ikDlJIJkj90KAqzOhzpfgKJkK hRm0UUPJQu67E6i3v2J/QGqt+Fwe9hhn85Un27nIF8ttbzlHlMyb4TvehdPiAAAAAA== ---------z1643_boundary_sign-- From mattjsm@gmail.com Fri May 7 22:29:02 2010 From: mattjsm@gmail.com (Matt Smith) Date: Fri, 7 May 2010 16:29:02 -0500 Subject: [OpenAFS-devel] GSoC Intro - Matt Smith - Port Client to NetBSD 5 Message-ID: Hello OpenAFSers! I'm Matt Smith and I am currently a senior at Iowa State University with (hopefully) just one more semester left to cover. Classes officially ended today, so it's time to start really getting into this project. The project that I proposed deals with creating a functioning OpenAFS client for NetBSD 5 since there hasn't been one for awhile now. Proposal available at http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/openafs/t127230761006 I've spent quite a bit of time using both OpenAFS and NetBSD at ISU, so it's rather exciting to finally get to delve much deeper into how the client really functions. Cheers, Matt Smith