From steven.jenkins@gmail.com  Fri Jun  1 01:27:14 2007
From: steven.jenkins@gmail.com (Steven Jenkins)
Date: Thu, 31 May 2007 20:27:14 -0400
Subject: [OpenAFS-devel] status of src/tests
In-Reply-To: <Pine.GSO.4.61-042.0705311626010.25687@johnstown.andrew.cmu.edu>
References: <ef99b6f40705311308n7e0b0809qfbddceecf4853e1b@mail.gmail.com>
 <Pine.GSO.4.61-042.0705311626010.25687@johnstown.andrew.cmu.edu>
Message-ID: <ef99b6f40705311727wa5fd667p4b83e2131c61601a@mail.gmail.com>

------=_Part_21596_30658141.1180657634088
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 5/31/07, Derrick J Brashear <shadow@dementia.org> wrote:
>
> ...
> I am, but, I haven't had time to finish what I'm working on; My slides
> about my works in progress are on the AFS Best Practices 2007 site, last
> day.
>
> src/tests hasn't been updated but much of what's there can at least be
> reused.



I've taken a look at your presentation, and it seems much of what you're
thinking of is dealing  at a fairly low level (code speaking).   The
src/tests tree is dealing with AFS at a functional/command level.

>From that standpoint, I'll probably start playing around with src/tests.

Thanks,
Steven

------=_Part_21596_30658141.1180657634088
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br><br><div><span class="gmail_quote">On 5/31/07, <b class="gmail_sendername">Derrick J Brashear</b> &lt;<a href="mailto:shadow@dementia.org">shadow@dementia.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
...<br>I am, but, I haven&#39;t had time to finish what I&#39;m working on; My slides<br>about my works in progress are on the AFS Best Practices 2007 site, last<br>day.<br><br>src/tests hasn&#39;t been updated but much of what&#39;s there can at least be
<br>reused.</blockquote><div><br><br>I&#39;ve taken a look at your presentation, and it seems much of what you&#39;re thinking of is dealing&nbsp; at a fairly low level (code speaking).&nbsp;&nbsp; The&nbsp; src/tests tree is dealing with AFS at a functional/command level.&nbsp; 
<br><br>From that standpoint, I&#39;ll probably start playing around with src/tests.<br><br>Thanks,<br>Steven<br><br><br><br> </div><br></div><br>

------=_Part_21596_30658141.1180657634088--

From kane96@gmx.de  Fri Jun  1 08:19:52 2007
From: kane96@gmx.de (kane96@gmx.de)
Date: Fri, 01 Jun 2007 09:19:52 +0200
Subject: [OpenAFS-devel] distribution for JAFS
Message-ID: <20070601071952.160240@gmx.net>

Hi,
can you name me a distribution, kernel and java version (or what else is important that JAFS works) that works with JAFS.
I tried ubuntu and debian and had problems with both.
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

From psomogyi@gamax.hu  Fri Jun  1 10:44:09 2007
From: psomogyi@gamax.hu (Peter Somogyi)
Date: Fri, 1 Jun 2007 11:44:09 +0200
Subject: [OpenAFS-devel] distribution for JAFS
In-Reply-To: <20070601071952.160240@gmx.net>
References: <20070601071952.160240@gmx.net>
Message-ID: <200706011144.09923.psomogyi@gamax.hu>

> can you name me a distribution, kernel and java version (or what else is
> important that JAFS works) that works with JAFS. I tried ubuntu and debian
> and had problems with both.

See http://rt.central.org/rt/Ticket/Display.html?id=21930
(that was a few years ago) + google on openafs-devel and openafs-info.

Peter

From mdw@spam.ifs.umich.edu  Fri Jun  1 11:09:58 2007
From: mdw@spam.ifs.umich.edu (Marcus Watts)
Date: Fri, 01 Jun 2007 06:09:58 -0400
Subject: [OpenAFS-devel] distribution for JAFS
In-Reply-To: <20070601071952.160240@gmx.net>
References: <20070601071952.160240@gmx.net>
Message-ID: <E1Hu450-00034U-JH@spam.ifs.umich.edu>

writes kane96@gmx.de
> 
> Date:    Fri, 01 Jun 2007 09:19:52 +0200
> To:      openafs-devel@openafs.org
> From:    kane96@gmx.de
> Subject: [OpenAFS-devel] distribution for JAFS
> 
> Hi,
> can you name me a distribution, kernel and java version (or what else is import
> ant that JAFS works) that works with JAFS.
> I tried ubuntu and debian and had problems with both.

I built jafs last summer with openafs 1.5.x + rxk5 patches, debian
unstable and sun java 1.5(.0?).  I don't know that what what I built
worked.  At the time, I couldn't find anybody who would admit to caring,
so "it builds" was a convenient stopping point.

When I try building today, it breaks.  As best I can tell, somebody got
overly clever with gnu make, and it looks like either gnu make behavior
changed or I broke something.

Is this how it broke for you, or did something else break?  I see earlier
comments from you regarding bison/yacc but I assume you got past that.
You don't say which version of java or openafs that you used.

Since you apparently do care about jafs, I gotta ask: what do you hope to
do with this?  Do you have anything that works (or worked?).  How do you
intend to or hope to handle authentication?  Keytabs, tokens, passwords,
or what?

				-Marcus Watts

From mancini@math.unifi.it  Fri Jun  1 11:41:15 2007
From: mancini@math.unifi.it (Alberto Mancini)
Date: Fri, 1 Jun 2007 12:41:15 +0200 (CEST)
Subject: [OpenAFS-devel] status of src/tests
In-Reply-To: <847e389f0706010327m1d93b374tbabe7cc05f32c428@mail.gmail.com>
References: <ef99b6f40705311308n7e0b0809qfbddceecf4853e1b@mail.gmail.com>
 <847e389f0706010327m1d93b374tbabe7cc05f32c428@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0706011228240.18391@ossigeno.math.unifi.it>

Actually, 
I think that ``dumptool'' should not be in src/tests directory too.

If someone is doing some work in the ``tests'' directory
could be a good idea to change this.

I have no idea of the ``meaning'' of most of the files in
the tests dir but i can help in moving/testing dumptool.

There is any open issue with dumptool ?

Ciao,
 				Alberto.



> I'm looking at putting together a somewhat comprehensive suite of tests and
> noticed src/tests.  Is anyone currently working on testing or is it pretty
> much orphaned?
>
> Thanks,
> Steven

From kane96@gmx.de  Fri Jun  1 14:32:22 2007
From: kane96@gmx.de (kane96@gmx.de)
Date: Fri, 01 Jun 2007 15:32:22 +0200
Subject: [OpenAFS-devel] JAFS make error
In-Reply-To: <Pine.GSO.4.61-042.0705241026210.19224@johnstown.andrew.cmu.edu>
References: <20070524122512.103150@gmx.net>
 <Pine.GSO.4.61-042.0705240832280.19224@johnstown.andrew.cmu.edu>
 <20070524141236.65600@gmx.net>
 <Pine.GSO.4.61-042.0705241026210.19224@johnstown.andrew.cmu.edu>
Message-ID: <20070601133222.162570@gmx.net>

the problem with ubuntu was, that i did not run 'make clean' after installing flex, bison, ...

i use java 1.5 and openafs 1.4.4
now, there is an error by 'make jafs':
ACL.c: In function ‘setACL’:
ACL.c:111: warning: incompatible implicit declaration of built-in function ‘strlen’
/usr/lib/jvm/java-1.5.0-sun/bin/javac -classpath ../classes ../classes/org/openafs/jafs/File.java
../classes/org/openafs/jafs/File.java:97: java.lang.Comparable cannot be inherited with different arguments: <> and <java.io.File>public class File extends java.io.File implements Comparable
       ^
Note: ../classes/org/openafs/jafs/File.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error


-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

From kane96@gmx.de  Fri Jun  1 14:39:37 2007
From: kane96@gmx.de (kane96@gmx.de)
Date: Fri, 01 Jun 2007 15:39:37 +0200
Subject: [OpenAFS-devel] distribution for JAFS
In-Reply-To: <E1Hu450-00034U-JH@spam.ifs.umich.edu>
References: <20070601071952.160240@gmx.net>
 <E1Hu450-00034U-JH@spam.ifs.umich.edu>
Message-ID: <20070601133937.162570@gmx.net>

> I see earlier
> comments from you regarding bison/yacc but I assume you got past that.

the problem was that i didn't execute 'make clean' - look at the "JAFS make error"-thread again

> You don't say which version of java or openafs that you used.
I use java 1.5 and openafs 1.4.4

> Since you apparently do care about jafs, I gotta ask: what do you hope to
> do with this?  Do you have anything that works (or worked?).  How do you
> intend to or hope to handle authentication?  Keytabs, tokens, passwords,
> or what?
it's the first time i use JAFS. I want to write a GUI to set directory-permissions on AFS on Linux.
I saw the testAFS.java-file in the JAVA-directory in openafs and want to try it like that.

-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

From mdw@spam.ifs.umich.edu  Sat Jun  2 05:52:48 2007
From: mdw@spam.ifs.umich.edu (Marcus Watts)
Date: Sat, 02 Jun 2007 00:52:48 -0400
Subject: [OpenAFS-devel] JAFS make error
In-Reply-To: <20070601133222.162570@gmx.net>
References: <20070524122512.103150@gmx.net> <Pine.GSO.4.61-042.0705240832280.19224@johnstown.andrew.cmu.edu> <20070524141236.65600@gmx.net> <Pine.GSO.4.61-042.0705241026210.19224@johnstown.andrew.cmu.edu> <20070601133222.162570@gmx.net>
Message-ID: <E1HuLbc-0004R8-B3@spam.ifs.umich.edu>

> Date:    Fri, 01 Jun 2007 15:32:22 +0200
> To:      OpenAFS-devel@openafs.org
> From:    kane96@gmx.de
> Subject: Re: [OpenAFS-devel] JAFS make error
> 
> the problem with ubuntu was, that i did not run 'make clean' after installing f
> lex, bison, ...
> 
> i use java 1.5 and openafs 1.4.4
> now, there is an error by 'make jafs':
> ACL.c: In function ‘setACL’:
> ACL.c:111: warning: incompatible implicit declaration of built-in function ‘strl
> en’
> /usr/lib/jvm/java-1.5.0-sun/bin/javac -classpath ../classes ../classes/org/open
> afs/jafs/File.java
> ../classes/org/openafs/jafs/File.java:97: java.lang.Comparable cannot be inheri
> ted with different arguments: <> and <java.io.File>public class File extends ja
> va.io.File implements Comparable
>        ^
> Note: ../classes/org/openafs/jafs/File.java uses unchecked or unsafe operations
> .
> Note: Recompile with -Xlint:unchecked for details.
> 1 error

Ok, that's a familiar error.  Java 1.5 doesn't like the construction
there.  If you can use java 1.4, that should fix it.  This is probably
your simplest solution if you can do it, because other people have
reported success in the past using stock jafs with java 1.4.

Otherwise, the file
	/afs/umich.edu/group/itd/build/mdw/tmp/afs-m40-java.patch
may be of interest.  This was for openafs 1.5.15, but should be
mostly close to 1.4.4.  This diff dates from 20070313, and there was email
discussion on this list concerning that.  The diff in there for File.java
will fix your compile error above.  It might create problems too, all I
know for sure is that it compiles.  The fixes to src/JAVA/libjafs/*.c
are important if you are using amd64 but might also be necessary for
recent compilers or glibc includes.  I don't think they'll hurt anything.
The src/JAVA/libjafs/Makefile.in hack to use a/ j/ is not right.  I think this
worked for me because I had left-over "installed" headers and the dependency
logic is still wacko.  You might want to discard this part of the patch.
Otherwise, you might have success by 1st building without this patch,
(at the top level, env JAVA_HOME=... make -k jafs) and after it blows up,
apply this patch and without doing make clean, do make jafs.  Yes this
is horrible.  The fixes to libadmin shlib* src/cf/osconf.m4 concern
building pic versions of libraries.  You don't need this if you only
care about i386.  This is also the part of the patch that is likely to
not apply cleanly to 1.4.4.  This is mainly what people were talking
about march 13 about this patch.

I may have a better patch soon.  People here at umich (itcs umce) are
starting to dig more into java, so there's an increased chance a working
java afs library will actually be helpful.

					-Marcus Watts

From kane96@gmx.de  Mon Jun  4 13:46:35 2007
From: kane96@gmx.de (kane96@gmx.de)
Date: Mon, 04 Jun 2007 14:46:35 +0200
Subject: [OpenAFS-devel] JAFS make error
In-Reply-To: <E1HuLbc-0004R8-B3@spam.ifs.umich.edu>
References: <20070524122512.103150@gmx.net>
 <Pine.GSO.4.61-042.0705240832280.19224@johnstown.andrew.cmu.edu>
 <20070524141236.65600@gmx.net>
 <Pine.GSO.4.61-042.0705241026210.19224@johnstown.andrew.cmu.edu>
 <20070601133222.162570@gmx.net> <E1HuLbc-0004R8-B3@spam.ifs.umich.edu>
Message-ID: <20070604124635.54550@gmx.net>

> Ok, that's a familiar error.  Java 1.5 doesn't like the construction
> there.  If you can use java 1.4, that should fix it.  This is probably
> your simplest solution if you can do it, because other people have
> reported success in the past using stock jafs with java 1.4.

I installed jdk 1.4.2_14 and it is setuped correctly as I can see in "java -version" and "update-alternatives --config java":

cglab06:/usr/lib/j2sdk1.4-sun/include# update-alternatives --config java

Es gibt 3 Alternativen, die »java« bereitstellen.

  Auswahl      Alternative
-----------------------------------------------
          1    /usr/bin/gij-wrapper-4.1
          2    /usr/lib/jvm/java-1.5.0-sun/jre/bin/java
*+        3    /usr/lib/j2sdk1.4-sun/bin/java

I also set $JAVA_HOME to "/usr/lib/j2sdk1.4-sun".


"make jafs" can't find jni.h but the file exists in "/usr/lib/j2sdk1.4-sun/include":

gcc -pipe -I/home/cglabadmin/Desktop/openafs-1.4.4/src/libuafs -I/home/cglabadmin/Desktop/openafs-1.4.4/include -I/include -I /include  -O2  -D_REENTRANT -DLIBJUAFS -DAFS_PTHREAD_ENV -pthread -D_REENTRANT -g -O2 -D_LARGEFILE64_SOURCE -c GetNativeString.c
GetNativeString.c:2:17: error: jni.h: Datei oder Verzeichnis nicht gefunden
In file included from GetNativeString.c:3:
GetNativeString.h:5: error: expected ‘)’ before ‘*’ token
GetNativeString.h:6: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘GetJavaString’
GetNativeString.c:5: error: expected ‘)’ before ‘*’ token
GetNativeString.c:49: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘GetJavaString’
make[2]: *** [GetNativeString.o] Fehler 1
make[2]: Leaving directory `/home/cglabadmin/Desktop/openafs-1.4.4/src/JAVA/libjafs'
make[1]: *** [libjafs] Fehler 2
make[1]: Leaving directory `/home/cglabadmin/Desktop/openafs-1.4.4/src/JAVA/libjafs'
make: *** [libjafs] Fehler 2

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

From kane96@gmx.de  Mon Jun  4 14:31:16 2007
From: kane96@gmx.de (kane96@gmx.de)
Date: Mon, 04 Jun 2007 15:31:16 +0200
Subject: [OpenAFS-devel] JAFS make error
In-Reply-To: <E1HuLbc-0004R8-B3@spam.ifs.umich.edu>
References: <20070524122512.103150@gmx.net>
 <Pine.GSO.4.61-042.0705240832280.19224@johnstown.andrew.cmu.edu>
 <20070524141236.65600@gmx.net>
 <Pine.GSO.4.61-042.0705241026210.19224@johnstown.andrew.cmu.edu>
 <20070601133222.162570@gmx.net> <E1HuLbc-0004R8-B3@spam.ifs.umich.edu>
Message-ID: <20070604133116.54560@gmx.net>

now, I did ./configure --with-java-home=... and it works :)
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

From rust710@gmail.com  Mon Jun  4 16:00:05 2007
From: rust710@gmail.com (Andrew Radamis)
Date: Mon, 4 Jun 2007 11:00:05 -0400
Subject: [OpenAFS-devel] Cache Volumes
Message-ID: <149e99a30706040800x362a3e70vfe6f56efe8100228@mail.gmail.com>

------=_Part_3803_23654534.1180969205100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I'm going to start out by saying that I know how to setup and manage an
openafs cell, following the documentation on the openafs.org site. I have
very limited knowledge of the inner workings of afs, I have a conceptual
picture at best.

I've been toying with an idea and my question is about feasibility of doing
it.

To make it a little easier to explain, and to head off the possibility of a
what would you ever use that for I'm going to explain it with a scenario.


In this scenario we have two site, cleverly named site A and B. At each site
has an AFS server and a some client computers running afs. Both sites are in
the same cell and connected by a slow link(VPN or what-not). There are 2
types of users, users who are always at there home site, and users who may
roam. Users may or may not use the same computer at each site. The first
type of users are obviously not the problem.


Which brings me to my question. A cache volume is my idea of a solution. It
would be similar to a replication site with the exception of users being
able to write to it. I understand why users can't write to normal
replication sites so I'd assume the cache volume would need the additional
stipulation of it can only be used when the real volume exists and is
online. Files will need to copied to the remote server, this can I suppose
be done through making the client wait till done, or letting the cache
volume accept it and background send it. Second one would be preferred of
course, but does have the problem of it the user beats the upload to the
other office.

I'm under no illusion of this being simple, but I am interested in
possibility of this. I estimate that the company I work for might have a
need for this in 3-5 years.

Thanks,

Andrew

------=_Part_3803_23654534.1180969205100
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I&#39;m going to start out by saying that I know how to setup and manage an openafs cell, following the documentation on the <a href="http://openafs.org">openafs.org</a> site. I have very limited knowledge of the inner workings of afs, I have a conceptual picture at best.
<br><br>I&#39;ve been toying with an idea and my question is about feasibility of doing it.<br><br>To make it a little easier to explain, and to head off the possibility of a what would you ever use that for I&#39;m going to explain it with a scenario.
<br><br><br>In this scenario we have two site, cleverly named site A and B. At each site has an AFS server and a some client computers running afs. Both sites are in the same cell and connected by a slow link(VPN or what-not). There are 2 types of users, users who are always at there home site, and users who may roam. Users may or may not use the same computer at each site. The first type of users are obviously not the problem.
<br><br><br>Which brings me to my question. A cache volume is my idea of a solution. It would be similar to a replication site with the exception of users being able to write to it. I understand why users can&#39;t write to normal replication sites so I&#39;d assume the cache volume would need the additional stipulation of it can only be used when the real volume exists and is online. Files will need to copied to the remote server, this can I suppose be done through making the client wait till done, or letting the cache volume accept it and background send it. Second one would be preferred of course, but does have the problem of it the user beats the upload to the other office.
<br><br>I&#39;m under no illusion of this being simple, but I am interested in possibility of this. I estimate that the company I work for might have a need for this in 3-5 years.<br><br>Thanks,<br><br>Andrew<br>

------=_Part_3803_23654534.1180969205100--

From haba@kth.se  Mon Jun  4 16:12:25 2007
From: haba@kth.se (Harald Barth)
Date: Mon, 04 Jun 2007 17:12:25 +0200 (MEST)
Subject: [OpenAFS-devel] Cache Volumes
In-Reply-To: <149e99a30706040800x362a3e70vfe6f56efe8100228@mail.gmail.com>
References: <149e99a30706040800x362a3e70vfe6f56efe8100228@mail.gmail.com>
Message-ID: <20070604.171225.56176167.haba@habarber.pdc.kth.se>

> Which brings me to my question. A cache volume is my idea of a solution. It
> would be similar to a replication site with the exception of users being
> able to write to it.

Readwrite consistence is complicated. A first step would be to have a
volume that is a "shadow" of a rw. Like a readonly but that the
changes are synced continously (but asynchronous). Then at a given
signal, the shadow and the rw could be locked and after that exchange
roles. 

Everything beyond that I see as an XL programming effort. The "shadow
volume" programming effort might be sized M and the the "exchange
roles" with a bit of luck only size S.

Harald.

From steven.jenkins@gmail.com  Mon Jun  4 16:37:45 2007
From: steven.jenkins@gmail.com (Steven Jenkins)
Date: Mon, 4 Jun 2007 11:37:45 -0400
Subject: [OpenAFS-devel] Cache Volumes
In-Reply-To: <149e99a30706040800x362a3e70vfe6f56efe8100228@mail.gmail.com>
References: <149e99a30706040800x362a3e70vfe6f56efe8100228@mail.gmail.com>
Message-ID: <ef99b6f40706040837td17c664lbf2129d1b6b89365@mail.gmail.com>

------=_Part_2772_9980087.1180971465040
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 6/4/07, Andrew Radamis <rust710@gmail.com> wrote:
>
> ...
> In this scenario we have two site, cleverly named site A and B. At each
> site has an AFS server and a some client computers running afs. Both sites
> are in the same cell and connected by a slow link(VPN or what-not). There
> are 2 types of users, users who are always at there home site, and users who
> may roam. Users may or may not use the same computer at each site. The first
> type of users are obviously not the problem.
>
>
> Which brings me to my question. A cache volume is my idea of a solution.
> It would be similar to a replication site with the exception of users being
> able to write to it. I understand why users can't write to normal
> replication sites so I'd assume the cache volume would need the additional
> stipulation of it can only be used when the real volume exists and is
> online. Files will need to copied to the remote server, this can I suppose
> be done through making the client wait till done, or letting the cache
> volume accept it and background send it. Second one would be preferred of
> course, but does have the problem of it the user beats the upload to the
> other office.
>

Your proposal would be a very large change to how AFS works.  However, on a
small scale, you might accomplish similar functionality manually via
examining the cache and doing vos move's.  As the number of users increases
(and especially the number of shared volumes) , you'll need to re-architect
a solution.  But I suspect that solution can be more easily layered on top
of AFS rather than done in AFS itself.

I strongly suspect virtually every AFS site  that is geographically
distributed has dealt with this problem one way or another.  As long as you
don't have lots of RW data that is shared across a WAN, vos move's should
suffice.

If you have questions on how that might work, feel free to elaborate.

Steven

------=_Part_2772_9980087.1180971465040
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br><br><div><span class="gmail_quote">On 6/4/07, <b class="gmail_sendername">Andrew Radamis</b> &lt;<a href="mailto:rust710@gmail.com">rust710@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
...<br>In this scenario we have two site, cleverly named site A and B. At each site has an AFS server and a some client computers running afs. Both sites are in the same cell and connected by a slow link(VPN or what-not). There are 2 types of users, users who are always at there home site, and users who may roam. Users may or may not use the same computer at each site. The first type of users are obviously not the problem.
<br><br><br>Which brings me to my question. A cache volume is my idea of a solution. It would be similar to a replication site with the exception of users being able to write to it. I understand why users can&#39;t write to normal replication sites so I&#39;d assume the cache volume would need the additional stipulation of it can only be used when the real volume exists and is online. Files will need to copied to the remote server, this can I suppose be done through making the client wait till done, or letting the cache volume accept it and background send it. Second one would be preferred of course, but does have the problem of it the user beats the upload to the other office.
<br></blockquote></div><br>Your proposal would be a very large change to how AFS works.&nbsp; However, on a small scale, you might accomplish similar functionality manually via examining the cache and doing vos move&#39;s.&nbsp; As the number of users increases (and especially the number of shared volumes) , you&#39;ll need to re-architect a solution.&nbsp; But I suspect that solution can be more easily layered on top of AFS rather than done in AFS itself.&nbsp; 
<br><br>I strongly suspect virtually every AFS site&nbsp; that is geographically distributed has dealt with this problem one way or another.&nbsp; As long as you don&#39;t have lots of RW data that is shared across a WAN, vos move&#39;s should suffice.&nbsp; 
<br><br>If you have questions on how that might work, feel free to elaborate.<br><br>Steven<br><br>

------=_Part_2772_9980087.1180971465040--

From shadow@dementia.org  Mon Jun  4 16:49:46 2007
From: shadow@dementia.org (Derrick J Brashear)
Date: Mon, 4 Jun 2007 11:49:46 -0400 (EDT)
Subject: [OpenAFS-devel] Cache Volumes
In-Reply-To: <ef99b6f40706040837td17c664lbf2129d1b6b89365@mail.gmail.com>
References: <149e99a30706040800x362a3e70vfe6f56efe8100228@mail.gmail.com>
 <ef99b6f40706040837td17c664lbf2129d1b6b89365@mail.gmail.com>
Message-ID: <Pine.GSO.4.61-042.0706041147400.25687@johnstown.andrew.cmu.edu>

On Mon, 4 Jun 2007, Steven Jenkins wrote:

>> Which brings me to my question. A cache volume is my idea of a solution.
>> It would be similar to a replication site with the exception of users being
>> able to write to it. I understand why users can't write to normal
>> replication sites so I'd assume the cache volume would need the additional
>> stipulation of it can only be used when the real volume exists and is
>> online. Files will need to copied to the remote server, this can I suppose
>> be done through making the client wait till done, or letting the cache
>> volume accept it and background send it. Second one would be preferred of
>> course, but does have the problem of it the user beats the upload to the
>> other office.
>> 
>
> Your proposal would be a very large change to how AFS works.  However, on a
> small scale, you might accomplish similar functionality manually via
> examining the cache and doing vos move's.  As the number of users increases
> (and especially the number of shared volumes) , you'll need to re-architect
> a solution.  But I suspect that solution can be more easily layered on top
> of AFS rather than done in AFS itself.

Actually, in some sense code to do this exists but is out of date. the 
CITI folks had something called "iafs", which was basically "make my cache 
manager also be a server". The access control model is of course going to 
be fun, but it's doable.


Of course this is a development solution, not something you can roll out 
of a box today, so Steven's answer is probably the one you want as an end 
user unless you have a longer time scale in mind for this and have time or 
resources to throw at fixing the problem.



From matt@linuxbox.com  Mon Jun  4 17:31:06 2007
From: matt@linuxbox.com (Matt Benjamin)
Date: Mon, 04 Jun 2007 12:31:06 -0400
Subject: [OpenAFS-devel] Cache Volumes
In-Reply-To: <Pine.GSO.4.61-042.0706041147400.25687@johnstown.andrew.cmu.edu>
References: <149e99a30706040800x362a3e70vfe6f56efe8100228@mail.gmail.com> <ef99b6f40706040837td17c664lbf2129d1b6b89365@mail.gmail.com> <Pine.GSO.4.61-042.0706041147400.25687@johnstown.andrew.cmu.edu>
Message-ID: <46643E4A.70401@linuxbox.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

This does sound like the right approach.  I'd forgotten CITI had
accomplished this.  It's good to see it under discussion again.

Matt

Derrick J Brashear wrote:
> 
> Actually, in some sense code to do this exists but is out of date. the
> CITI folks had something called "iafs", which was basically "make my
> cache manager also be a server". The access control model is of course
> going to be fun, but it's doable.
> 
> 
> Of course this is a development solution, not something you can roll out
> of a box today, so Steven's answer is probably the one you want as an
> end user unless you have a longer time scale in mind for this and have
> time or resources to throw at fixing the problem.
> 
> 
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel




- --

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGZD5KJiSUUSaRdSURCGZ4AJ9bl9t0oL/W9JlihayVteOO1cr/7gCfSF+6
DxARDkeTpdRn7K19C6mxBpg=
=+4o+
-----END PGP SIGNATURE-----

From shadow@dementia.org  Mon Jun  4 17:33:11 2007
From: shadow@dementia.org (Derrick J Brashear)
Date: Mon, 4 Jun 2007 12:33:11 -0400 (EDT)
Subject: [OpenAFS-devel] Cache Volumes
In-Reply-To: <46643E4A.70401@linuxbox.com>
References: <149e99a30706040800x362a3e70vfe6f56efe8100228@mail.gmail.com>
 <ef99b6f40706040837td17c664lbf2129d1b6b89365@mail.gmail.com>
 <Pine.GSO.4.61-042.0706041147400.25687@johnstown.andrew.cmu.edu>
 <46643E4A.70401@linuxbox.com>
Message-ID: <Pine.GSO.4.61-042.0706041231560.25687@johnstown.andrew.cmu.edu>

On Mon, 4 Jun 2007, Matt Benjamin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> This does sound like the right approach.  I'd forgotten CITI had
> accomplished this.  It's good to see it under discussion again.

There's a lot of neat work that has been done, some of which for various 
reasons will never see the light of day; I do try to keep a running list 
of what's out there and when possible collect source for later reuse even 
if the time hasn't yet come.

In the case of work done at CITI while a lot has bitrotted at least we can 
get it.

From kane96@gmx.de  Mon Jun  4 17:42:18 2007
From: kane96@gmx.de (kane96@gmx.de)
Date: Mon, 04 Jun 2007 18:42:18 +0200
Subject: [OpenAFS-devel] JAFS: ** Can't determine local cell name!
Message-ID: <20070604164218.251100@gmx.net>

hello,
i get an error by creating a Token-object.
The local cell name is in /etc/openafs/ThisCell and the ip's of our two afs-servers are in /etc/openafs/CellServDB:

AFSException: Error Code: 180500; Message: error reading cell database
AFSException: Error Code: 180500; Message: error reading cell database
	at org.openafs.jafs.Token.getToken(Native Method)
	at org.openafs.jafs.Token.login(Token.java:252)
	at org.openafs.jafs.Token.<init>(Token.java:166)
	at meinTest.main(meinTest.java:21)
** Can't determine local cell name!

ErrorMessages.properties: E180500 = error reading cell database
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

From mdw@spam.ifs.umich.edu  Mon Jun  4 21:24:28 2007
From: mdw@spam.ifs.umich.edu (Marcus Watts)
Date: Mon, 04 Jun 2007 16:24:28 -0400
Subject: [OpenAFS-devel] JAFS make error
In-Reply-To: <20070604124635.54550@gmx.net>
References: <20070524122512.103150@gmx.net> <Pine.GSO.4.61-042.0705240832280.19224@johnstown.andrew.cmu.edu> <20070524141236.65600@gmx.net> <Pine.GSO.4.61-042.0705241026210.19224@johnstown.andrew.cmu.edu> <20070601133222.162570@gmx.net> <E1HuLbc-0004R8-B3@spam.ifs.umich.edu> <20070604124635.54550@gmx.net>
Message-ID: <E1HvJ6K-0007Fx-II@spam.ifs.umich.edu>

kane96@gmx.de writes:
...
> *+        3    /usr/lib/j2sdk1.4-sun/bin/java
...
> I also set $JAVA_HOME to "/usr/lib/j2sdk1.4-sun".

Right, looks fine.  I'm not sure the readme's document this as
well as they should.

> 
> "make jafs" can't find jni.h but the file exists in "/usr/lib/j2sdk1.4-sun/incl
> ude":
> 
> gcc -pipe -I/home/cglabadmin/Desktop/openafs-1.4.4/src/libuafs -I/home/cglabadm
...
> GetNativeString.c:2:17: error: jni.h: Datei oder Verzeichnis nicht gefunden

Yes.  In "afs-m40-java2.patch" I had this:
-       INC := -I${TOP_INCDIR} -I${TOP_INCDIR}/afs/ -I${JAVA_HOME}/include -I ${JNI_INC}
+       INC := -I${TOP_INCDIR} -I${TOP_INCDIR}/afs/ -I${JAVA_HOME}/include -I ${JNI_INC} -I ${JNI_INC}/linux

to fix this.  As far as I know, this is a debian linux packaging weirdness,
perhaps related to wanting to support multiple different java environments
simultaneously.


> now, I did ./configure --with-java-home=... and it works :)

There's a "--with-java-home"?  You *sure* about that?....
As long as it works though...


> hello,
> i get an error by creating a Token-object.
> The local cell name is in /etc/openafs/ThisCell and the ip's of our two afs-ser
> vers are in /etc/openafs/CellServDB:
> 
> AFSException: Error Code: 180500; Message: error reading cell database
> AFSException: Error Code: 180500; Message: error reading cell database
> 	at org.openafs.jafs.Token.getToken(Native Method)
> 	at org.openafs.jafs.Token.login(Token.java:252)
> 	at org.openafs.jafs.Token.<init>(Token.java:166)
> 	at meinTest.main(meinTest.java:21)
> ** Can't determine local cell name!

Try "strace".  It might be looking at /etc/openafs/server/ThisCell
or /usr/vice/etc/ThisCell or something...  If it's looking at
/usr/{vice,af}/etc/ThisCell then you've managed to configure with
transarc paths but installed something configured with fhs paths.
If it's looking at /usr/local - then you didn't set prefix, &etc.

Your pre-compiled debian install was probably configured this way:
	env afslogsdir=/var/log/openafs sh configure
	--with-afs-sysname=i386_linux26 --disable-kernel-module \
	--prefix=/usr --sysconfdir=/etc \
	--libexecdir=/usr/lib --localstatedir=/var/lib
		(sysname might vary - amd64_linux26?  Try "fs sys"...)
Do a "make clean" before reconfiguring built source.

					-Marcus Watts

From kane96@gmx.de  Tue Jun  5 11:36:18 2007
From: kane96@gmx.de (kane96@gmx.de)
Date: Tue, 05 Jun 2007 12:36:18 +0200
Subject: [OpenAFS-devel] JAFS make error
In-Reply-To: <E1HvJ6K-0007Fx-II@spam.ifs.umich.edu>
References: <20070524122512.103150@gmx.net>
 <Pine.GSO.4.61-042.0705240832280.19224@johnstown.andrew.cmu.edu>
 <20070524141236.65600@gmx.net>
 <Pine.GSO.4.61-042.0705241026210.19224@johnstown.andrew.cmu.edu>
 <20070601133222.162570@gmx.net> <E1HuLbc-0004R8-B3@spam.ifs.umich.edu>
 <20070604124635.54550@gmx.net> <E1HvJ6K-0007Fx-II@spam.ifs.umich.edu>
Message-ID: <20070605103618.12230@gmx.net>

> > now, I did ./configure --with-java-home=... and it works :)
> 
> There's a "--with-java-home"?  You *sure* about that?....
> As long as it works though...

yes, it's not in "./configure --help", i found it somewhere else. But if I don't set it I get the jni.h-not-found-error again (without testing your patch).


> Try "strace".  It might be looking at /etc/openafs/server/ThisCell
> or /usr/vice/etc/ThisCell or something...  If it's looking at
> /usr/{vice,af}/etc/ThisCell then you've managed to configure with
> transarc paths but installed something configured with fhs paths.
> If it's looking at /usr/local - then you didn't set prefix, &etc.

I tried strace but didn't find "ThisCell" or any of these folders. Do I have to search for something else in output?


> Your pre-compiled debian install was probably configured this way:
> 	env afslogsdir=/var/log/openafs sh configure
> 	--with-afs-sysname=i386_linux26 --disable-kernel-module \
> 	--prefix=/usr --sysconfdir=/etc \
> 	--libexecdir=/usr/lib --localstatedir=/var/lib
> 		(sysname might vary - amd64_linux26?  Try "fs sys"...)
> Do a "make clean" before reconfiguring built source.

I only did "./configure --with-java-home=..." without anything else. Now i did it with your parameters but nothing changed.

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

From kane96@gmx.de  Wed Jun  6 14:17:31 2007
From: kane96@gmx.de (kane96@gmx.de)
Date: Wed, 06 Jun 2007 15:17:31 +0200
Subject: [OpenAFS-devel] JAFS make error
In-Reply-To: <20070605103618.12230@gmx.net>
References: <20070524122512.103150@gmx.net>
 <Pine.GSO.4.61-042.0705240832280.19224@johnstown.andrew.cmu.edu>
 <20070524141236.65600@gmx.net>
 <Pine.GSO.4.61-042.0705241026210.19224@johnstown.andrew.cmu.edu>
 <20070601133222.162570@gmx.net> <E1HuLbc-0004R8-B3@spam.ifs.umich.edu>
 <20070604124635.54550@gmx.net> <E1HvJ6K-0007Fx-II@spam.ifs.umich.edu>
 <20070605103618.12230@gmx.net>
Message-ID: <20070606131731.92940@gmx.net>

> > Your pre-compiled debian install was probably configured this way:
> > 	env afslogsdir=/var/log/openafs sh configure
> > 	--with-afs-sysname=i386_linux26 --disable-kernel-module \
> > 	--prefix=/usr --sysconfdir=/etc \
> > 	--libexecdir=/usr/lib --localstatedir=/var/lib
> > 		(sysname might vary - amd64_linux26?  Try "fs sys"...)
> > Do a "make clean" before reconfiguring built source.
> 
> I only did "./configure --with-java-home=..." without anything else. Now i
> did it with your parameters but nothing changed.
> 
I used "--disable-transarc-paths" and JAFS can find the local-cell-name now.
But there is the next error when creating token t0 in testAFS.java:

Ubik Call failedAFSException: Error Code: 180498; Message: Ubik Call failed

	at org.openafs.jafs.Token.getToken(Native Method)
	at org.openafs.jafs.Token.login(Token.java:252)
	at org.openafs.jafs.Token.<init>(Token.java:166)
	at testAFS.main(testAFS.java:643)



-- 
NEU! +++ Bis 30.06. Sparpreis sichern! GMX empfiehlt 4DSL von 1&1.  +++
Jetzt inklusive Handy-Flatrate!*: http://www.gmx.net/de/go/dsl

From steven.jenkins@gmail.com  Fri Jun  8 02:18:28 2007
From: steven.jenkins@gmail.com (Steven Jenkins)
Date: Thu, 7 Jun 2007 21:18:28 -0400
Subject: [OpenAFS-devel] hidden commands
Message-ID: <ef99b6f40706071818h47d14ab7pdf044319d83a4ec9@mail.gmail.com>

------=_Part_40602_13932250.1181265508389
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

There  has been a discussion over on openafs-docs about vos online/offline &
hidden commands -- there is a desire to have all commands and all options
documented and visible for consistency's sake, although the documentation
may note where a command is dangerous or requires special privileges.

I did a quick check of the source and found the following CMD_HIDDEN
commands:

- cmd.c: all commands have hidden 'version', and 'help' flags.
- admin_tools.c: kas setkey
- admin_tools.c: kas getpassword/getpasswd(which I couldn't get to work --
see transcript below)
- admin_tools.c: kas getrandomkey
- admin_tools.c: kas getticket
- admin_tools.c: kas debuginfo
- fs.c: fs monitor
- vos.c: vos online
- vos.c: vos offline

Jeff Altman suggested I start a discussion of which should be made visible.
Apparently some of these commands were made hidden simply because IBM was
not permitted to "add new features" at the time the command was added (e.g.,
vos online/offline), although I don't know the history of these commands.

Steven

Notes:

- kas getpassword:

I did not take time to debug this, not knowing if it is even expected to
work.  It's a side issue that shouldn't detract from the discussion of 'what
should be done about hidden commands' -- I include it here for reference:

[admin@sjfcafs11 ]$ tokens

Tokens held by the Cache Manager:

User's (AFS ID 15) tokens for afs@example.org [Expires Jun  8 22:31]
   --End of list--
[admin@sjfcafs11 ]$ id
uid=15(admin) gid=501(admin) groups=501(admin)
[admin@sjfcafs11 ]$ kas getpassword -name admin
kas:getpassword: caller not authorized getting admin's password via loopback
connection to GetPassword

I also tried unsuccessfully as root, with admin's token.

------=_Part_40602_13932250.1181265508389
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br>There&nbsp; has been a discussion over on openafs-docs about vos online/offline &amp; hidden commands -- there is a desire to have all commands and all options documented and visible for consistency&#39;s sake, although the documentation may note where a command is dangerous or requires special privileges.&nbsp; 
<br><br>I did a quick check of the source and found the following CMD_HIDDEN commands:<br><br>- cmd.c: all commands have hidden &#39;version&#39;, and &#39;help&#39; flags.
<br>- admin_tools.c: kas setkey <br>- admin_tools.c: kas getpassword/getpasswd(which I couldn&#39;t get to work -- see transcript below)<br>- admin_tools.c: kas getrandomkey<br>- admin_tools.c: kas getticket<br>- admin_tools.c: kas debuginfo
<br>- fs.c: fs monitor<br>- vos.c: vos online<br>- vos.c: vos offline<br><br>Jeff Altman suggested I start a discussion of which should be made visible.<br>Apparently some of these commands were made hidden simply because IBM was not
permitted to &quot;add new features&quot; at the time the command was added (e.g., vos online/offline), although I don&#39;t know the history of these commands.<br><br>Steven<br><br>Notes:<br><br>- kas getpassword:
<br><br>I did not take time to debug this, not knowing if it is even expected to work.&nbsp; It&#39;s a side issue that shouldn&#39;t detract from the discussion of &#39;what should be done about hidden commands&#39; -- I include it here for reference:
<br><br>[admin@sjfcafs11 ]$ tokens<br><br>Tokens held by the Cache Manager:<br><br>User&#39;s (AFS ID 15) tokens for 
<a href="mailto:afs@example.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">afs@example.org</a> [Expires Jun&nbsp; 8 22:31]<br>&nbsp;&nbsp; --End of list--<br>[admin@sjfcafs11 ]$ id<br>uid=15(admin) gid=501(admin) groups=501(admin)
<br>[admin@sjfcafs11 ]$ kas getpassword -name admin
<br>kas:getpassword: caller not authorized getting admin&#39;s password via loopback connection to GetPassword<br><br>I also tried unsuccessfully as root, with admin&#39;s token.<br><br>

------=_Part_40602_13932250.1181265508389--

From rra@stanford.edu  Fri Jun  8 02:28:11 2007
From: rra@stanford.edu (Russ Allbery)
Date: Thu, 07 Jun 2007 18:28:11 -0700
Subject: [OpenAFS-devel] hidden commands
In-Reply-To: <ef99b6f40706071818h47d14ab7pdf044319d83a4ec9@mail.gmail.com>
 (Steven Jenkins's message of "Thu, 7 Jun 2007 21:18:28 -0400")
References: <ef99b6f40706071818h47d14ab7pdf044319d83a4ec9@mail.gmail.com>
Message-ID: <87zm3b8cb8.fsf@windlord.stanford.edu>

Steven Jenkins <steven.jenkins@gmail.com> writes:

> There has been a discussion over on openafs-docs about vos
> online/offline & hidden commands -- there is a desire to have all
> commands and all options documented and visible for consistency's sake,
> although the documentation may note where a command is dangerous or
> requires special privileges.

> I did a quick check of the source and found the following CMD_HIDDEN
> commands:

> - cmd.c: all commands have hidden 'version', and 'help' flags.
> - admin_tools.c: kas setkey
> - admin_tools.c: kas getpassword/getpasswd(which I couldn't get to work --
> see transcript below)
> - admin_tools.c: kas getrandomkey
> - admin_tools.c: kas getticket
> - admin_tools.c: kas debuginfo
> - fs.c: fs monitor
> - vos.c: vos online
> - vos.c: vos offline

> Jeff Altman suggested I start a discussion of which should be made
> visible.  Apparently some of these commands were made hidden simply
> because IBM was not permitted to "add new features" at the time the
> command was added (e.g., vos online/offline), although I don't know the
> history of these commands.

kas is essentially dead code at this point, so we can either leave it
alone or go with what we do with everything else, whichever is easier.

For the rest, it seems reasonable to expose them and document them unless
they're actually dangerous for some reason (and if so, we should probably
still document them and just put big warnings around them).

While we're at it, it might be a good idea to rip out the MR-AFS stuff
still left around in the bos command suite (bos help salvage, for
example).

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

From mdw@spam.ifs.umich.edu  Fri Jun  8 03:32:02 2007
From: mdw@spam.ifs.umich.edu (Marcus Watts)
Date: Thu, 07 Jun 2007 22:32:02 -0400
Subject: [OpenAFS-devel] hidden commands
In-Reply-To: <ef99b6f40706071818h47d14ab7pdf044319d83a4ec9@mail.gmail.com>
References: <ef99b6f40706071818h47d14ab7pdf044319d83a4ec9@mail.gmail.com>
Message-ID: <E1HwUGg-0004VD-5A@spam.ifs.umich.edu>

"Steven Jenkins" <steven.jenkins@gmail.com> writes:
...
> - admin_tools.c: kas getpassword/getpasswd(which I couldn't get to work --
...
> [admin@sjfcafs11 ]$ kas getpassword -name admin
> kas:getpassword: caller not authorized getting admin's password via loopback
> connection to GetPassword
> 
> I also tried unsuccessfully as root, with admin's token.

Root or not makes no differences to a client/server program.  Nor should
it.  Just because you have root on your mongrel frankenstein linux box
in some dark cubby hole of your great <local institution> does not mean
the guys in white hats should trust you.

On the *other* hand; your IP address does matter, & "kas getpassword"
should only work on connections made via "localhost" -- ie, on the host
running kaserver.  kas has code in it to do this, plus error messages
to point you this way.

AND...  you have to have a special build of kaserver with "GETPASSWORD"
turned on.  Otherwise kamGetPassword in src/kauth/kaprocs.c is very
boring and always returns KANOAUTH.

At umich.edu when we were running kaserver, we ran with "GETPASSWORD"
enabled.  We used it so that we could rename principals -- ptserver has a
rename option, but kaserver doesn't.  With special code running on the kdc
though, we could fetch the key, save it, delete the old ka instance,
create a new ka instance, and restore the user's key.  Since k4 keys didn't
depend on the principal (only the cell), this worked.

kaserver today has another way to do this as well; "kamGetEntry" will
return the key for administrative users.  "kas examine -showkey" will
do this.  This is a "new" feature (well, new somewhere in late transarc),
AFS 3.4 would only do this if security was turned off in the cell.
The people who made this change were clearly a lot less paranoid than
the people who worked on the GetPassword rpc.

				-Marcus Watts

From kane96@gmx.de  Fri Jun  8 12:42:07 2007
From: kane96@gmx.de (kane96@gmx.de)
Date: Fri, 08 Jun 2007 13:42:07 +0200
Subject: [OpenAFS-devel] JAFS make error
In-Reply-To: <20070606131731.92940@gmx.net>
References: <20070524122512.103150@gmx.net>
 <Pine.GSO.4.61-042.0705240832280.19224@johnstown.andrew.cmu.edu>
 <20070524141236.65600@gmx.net>
 <Pine.GSO.4.61-042.0705241026210.19224@johnstown.andrew.cmu.edu>
 <20070601133222.162570@gmx.net> <E1HuLbc-0004R8-B3@spam.ifs.umich.edu>
 <20070604124635.54550@gmx.net> <E1HvJ6K-0007Fx-II@spam.ifs.umich.edu>
 <20070605103618.12230@gmx.net> <20070606131731.92940@gmx.net>
Message-ID: <20070608114207.251750@gmx.net>

> I used "--disable-transarc-paths" and JAFS can find the local-cell-name
> now.
> But there is the next error when creating token t0 in testAFS.java:
> 
> Ubik Call failedAFSException: Error Code: 180498; Message: Ubik Call
> failed
> 
> 	at org.openafs.jafs.Token.getToken(Native Method)
> 	at org.openafs.jafs.Token.login(Token.java:252)
> 	at org.openafs.jafs.Token.<init>(Token.java:166)
> 	at testAFS.main(testAFS.java:643)
> 

I think the problem is that we use Kerberos V and not kaserver.
Are there any implementations for authentification on Kerberos V for JAFS? 

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

From kane96@gmx.de  Fri Jun  8 12:58:55 2007
From: kane96@gmx.de (kane96@gmx.de)
Date: Fri, 08 Jun 2007 13:58:55 +0200
Subject: [OpenAFS-devel] Developing an User-Interface for AFS Permissions
Message-ID: <20070608115855.251720@gmx.net>

Hi,
I want to built an User Interface to set directory permissions on AFS for Linux.
First i tried to do this in java because the JAFS API looks very simple, but it doesn't work because we use Kerberos V and not Kaserver.

Now I want to develop the interface in C/C++, but don't know how to start? For Java there was a testAFS.java to see how it works.
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

From haba@kth.se  Fri Jun  8 13:20:06 2007
From: haba@kth.se (Harald Barth)
Date: Fri, 08 Jun 2007 14:20:06 +0200 (MEST)
Subject: [OpenAFS-devel] Developing an User-Interface for AFS
 Permissions
In-Reply-To: <20070608115855.251720@gmx.net>
References: <20070608115855.251720@gmx.net>
Message-ID: <20070608.142006.101336151.haba@habarber.pdc.kth.se>

> I want to built an User Interface to set directory permissions on AFS for Linux.

http://www.openafs.org/pipermail/openafs-info/2005-October/020006.html

Harald.

From steven.jenkins@gmail.com  Fri Jun  8 17:56:16 2007
From: steven.jenkins@gmail.com (Steven Jenkins)
Date: Fri, 8 Jun 2007 12:56:16 -0400
Subject: [OpenAFS-devel] hidden commands
In-Reply-To: <E1HwUGg-0004VD-5A@spam.ifs.umich.edu>
References: <ef99b6f40706071818h47d14ab7pdf044319d83a4ec9@mail.gmail.com>
 <E1HwUGg-0004VD-5A@spam.ifs.umich.edu>
Message-ID: <ef99b6f40706080956p6d9bc20cyc442143ac3a11b42@mail.gmail.com>

------=_Part_46616_1550563.1181321776568
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 6/7/07, Marcus Watts <mdw@spam.ifs.umich.edu> wrote:
>
> ...




At umich.edu when we were running kaserver, we ran with "GETPASSWORD"
> enabled.  We used it so that we could rename principals -- ptserver has a
> rename option, but kaserver doesn't.  With special code running on the kdc
> though, we could fetch the key, save it, delete the old ka instance,
> create a new ka instance, and restore the user's key.  Since k4 keys
> didn't
> depend on the principal (only the cell), this worked.
>
...

Would removing the code from the src tree be the best option at this point?

Steven

------=_Part_46616_1550563.1181321776568
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br><br><div><span class="gmail_quote">On 6/7/07, <b class="gmail_sendername">Marcus Watts</b> &lt;<a href="mailto:mdw@spam.ifs.umich.edu">mdw@spam.ifs.umich.edu</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
...</blockquote><div><br>&nbsp;</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">At <a href="http://umich.edu">umich.edu</a> when we were running kaserver, we ran with &quot;GETPASSWORD&quot;
<br>enabled.&nbsp;&nbsp;We used it so that we could rename principals -- ptserver has a<br>rename option, but kaserver doesn&#39;t.&nbsp;&nbsp;With special code running on the kdc<br>though, we could fetch the key, save it, delete the old ka instance,
<br>create a new ka instance, and restore the user&#39;s key.&nbsp;&nbsp;Since k4 keys didn&#39;t<br>depend on the principal (only the cell), this worked.<br></blockquote></div>...<br><br>Would removing the code from the src tree be the best option at this point? 
<br><br>Steven<br><br>

------=_Part_46616_1550563.1181321776568--

From shadow@dementia.org  Fri Jun  8 18:32:42 2007
From: shadow@dementia.org (Derrick J Brashear)
Date: Fri, 8 Jun 2007 13:32:42 -0400 (EDT)
Subject: [OpenAFS-devel] hidden commands
In-Reply-To: <ef99b6f40706080956p6d9bc20cyc442143ac3a11b42@mail.gmail.com>
References: <ef99b6f40706071818h47d14ab7pdf044319d83a4ec9@mail.gmail.com>
 <E1HwUGg-0004VD-5A@spam.ifs.umich.edu> <ef99b6f40706080956p6d9bc20cyc442143ac3a11b42@mail.gmail.com>
Message-ID: <Pine.GSO.4.61-042.0706081331590.25687@johnstown.andrew.cmu.edu>

why bother removing it. all of src/kauth is already on the block

On Fri, 8 Jun 2007, Steven Jenkins wrote:

> On 6/7/07, Marcus Watts <mdw@spam.ifs.umich.edu> 
> wrote:
>> 
>> ...
>
>
>
>
> At umich.edu when we were running kaserver, we ran 
> with "GETPASSWORD"
>> enabled.  We used it so that we could rename 
>> principals -- ptserver has a
>> rename option, but kaserver doesn't.  With 
>> special code running on the kdc
>> though, we could fetch the key, save it, delete 
>> the old ka instance,
>> create a new ka instance, and restore the user's 
>> key.  Since k4 keys
>> didn't
>> depend on the principal (only the cell), this 
>> worked.
>> 
> ...
>
> Would removing the code from the src tree be the 
> best option at this point?
>
> Steven
>

From jpw@wszib.edu.pl  Fri Jun  8 19:26:16 2007
From: jpw@wszib.edu.pl (Jakub Witkowski)
Date: Fri, 08 Jun 2007 20:26:16 +0200
Subject: [OpenAFS-devel] Please add configure option to switch off the system call table
 patching in Linux
Message-ID: <1181327176.2242.11.camel@jpw-laptop>

--=-BbeZYGAMLQHbbVhSbNdk
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hello,

Can you please add a configure switch to #ifdef out the syscall table
patching mechanism, especially the writable check and actual write
functions?

Syscall patching does not work in both Xen and KVM enabled kernels and I
expect that it will become increasingly dysfunctional as new kernel
releases will add more virtualization-centric changes.

Thank you,

Jakub.

--=-BbeZYGAMLQHbbVhSbNdk
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: To jest =?UTF-8?Q?cz=C4=99=C5=9B=C4=87?= listu
	podpisana cyfrowo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGaZ9HozPug5EmwHARArSPAJ9wL+pf2kYRcljwEv2vbrYNU2Sn1wCgvQa6
P5MR42boxr4Qtg5/nz45FQU=
=qAPw
-----END PGP SIGNATURE-----

--=-BbeZYGAMLQHbbVhSbNdk--


From shadow@dementia.org  Fri Jun  8 19:33:47 2007
From: shadow@dementia.org (Derrick J Brashear)
Date: Fri, 8 Jun 2007 14:33:47 -0400 (EDT)
Subject: [OpenAFS-devel] Please add configure option to switch off the
 system call table patching in Linux
In-Reply-To: <1181327176.2242.11.camel@jpw-laptop>
References: <1181327176.2242.11.camel@jpw-laptop>
Message-ID: <Pine.GSO.4.61-042.0706081432550.25687@johnstown.andrew.cmu.edu>

On Fri, 8 Jun 2007, Jakub Witkowski wrote:

> Hello,
>
> Can you please add a configure switch to #ifdef out the syscall table
> patching mechanism, especially the writable check and actual write
> functions?

If you send it I promise we'll get it in 1.4.5, better yet:

> Syscall patching does not work in both Xen and KVM enabled kernels and I
> expect that it will become increasingly dysfunctional as new kernel
> releases will add more virtualization-centric changes.

If you can have configure look at the CONFIG_XEN or whatever in the 
kernels its being built against and explicitly disable itself in those 
cases (reverse the sense of the test) even better.


From rra@stanford.edu  Fri Jun  8 19:38:15 2007
From: rra@stanford.edu (Russ Allbery)
Date: Fri, 08 Jun 2007 11:38:15 -0700
Subject: [OpenAFS-devel] Please add configure option to switch off the system call table patching in Linux
In-Reply-To: <1181327176.2242.11.camel@jpw-laptop> (Jakub Witkowski's message
 of "Fri, 08 Jun 2007 20:26:16 +0200")
References: <1181327176.2242.11.camel@jpw-laptop>
Message-ID: <87lkeu5m20.fsf@windlord.stanford.edu>

Jakub Witkowski <jpw@wszib.edu.pl> writes:

> Syscall patching does not work in both Xen and KVM enabled kernels and I
> expect that it will become increasingly dysfunctional as new kernel
> releases will add more virtualization-centric changes.

OpenAFS doesn't work at all with Xen-enabled kernels right now, unless
someone committed the patch to switch from spin_lock_irq to
spin_lock_irqsave and avoid the symbol enabling paravirt makes GPL-only.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

From steven.jenkins@gmail.com  Sat Jun  9 01:39:19 2007
From: steven.jenkins@gmail.com (Steven Jenkins)
Date: Fri, 8 Jun 2007 20:39:19 -0400
Subject: [OpenAFS-devel] hidden commands
In-Reply-To: <Pine.GSO.4.61-042.0706081331590.25687@johnstown.andrew.cmu.edu>
References: <ef99b6f40706071818h47d14ab7pdf044319d83a4ec9@mail.gmail.com>
 <E1HwUGg-0004VD-5A@spam.ifs.umich.edu>
 <ef99b6f40706080956p6d9bc20cyc442143ac3a11b42@mail.gmail.com>
 <Pine.GSO.4.61-042.0706081331590.25687@johnstown.andrew.cmu.edu>
Message-ID: <ef99b6f40706081739s73277059tc2da427226ff8f9c@mail.gmail.com>

------=_Part_49963_9798260.1181349559630
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 6/8/07, Derrick J Brashear <shadow@dementia.org> wrote:
>
> why bother removing it. all of src/kauth is already on the block
>

What's the scheduled removal date for all of src/kauth? It it's fairly
imminent, I agree there's no big win.  However, if it's still 'to be decided
when', then I think there's value in going ahead and doing some
opportunistic cleaning.

Steven

------=_Part_49963_9798260.1181349559630
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br><br><div><span class="gmail_quote">On 6/8/07, <b class="gmail_sendername">Derrick J Brashear</b> &lt;<a href="mailto:shadow@dementia.org">shadow@dementia.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
why bother removing it. all of src/kauth is already on the block<br></blockquote></div><br>What&#39;s the scheduled removal date for all of src/kauth? It it&#39;s fairly imminent, I agree there&#39;s no big win.&nbsp; However, if it&#39;s still &#39;to be decided when&#39;, then I think there&#39;s value in going ahead and doing some opportunistic cleaning.
<br><br>Steven<br><br>

------=_Part_49963_9798260.1181349559630--

From mdw@spam.ifs.umich.edu  Sat Jun  9 08:57:40 2007
From: mdw@spam.ifs.umich.edu (Marcus Watts)
Date: Sat, 09 Jun 2007 03:57:40 -0400
Subject: [OpenAFS-devel] JAFS make error
In-Reply-To: <20070608114207.251750@gmx.net>
References: <20070524122512.103150@gmx.net> <Pine.GSO.4.61-042.0705240832280.19224@johnstown.andrew.cmu.edu> <20070524141236.65600@gmx.net> <Pine.GSO.4.61-042.0705241026210.19224@johnstown.andrew.cmu.edu> <20070601133222.162570@gmx.net> <E1HuLbc-0004R8-B3@spam.ifs.umich.edu> <20070604124635.54550@gmx.net> <E1HvJ6K-0007Fx-II@spam.ifs.umich.edu> <20070605103618.12230@gmx.net> <20070606131731.92940@gmx.net> <20070608114207.251750@gmx.net>
Message-ID: <E1HwvpM-0006cn-UZ@spam.ifs.umich.edu>

kane96@gmx.de writes:
> Date:    Fri, 08 Jun 2007 13:42:07 +0200
> To:      OpenAFS-devel@openafs.org
> From:    kane96@gmx.de
> Subject: Re: [OpenAFS-devel] JAFS make error
> 
> > I used "--disable-transarc-paths" and JAFS can find the local-cell-name
> > now.
> > But there is the next error when creating token t0 in testAFS.java:
> > 
> > Ubik Call failedAFSException: Error Code: 180498; Message: Ubik Call
> > failed
> > 
> > 	at org.openafs.jafs.Token.getToken(Native Method)
> > 	at org.openafs.jafs.Token.login(Token.java:252)
> > 	at org.openafs.jafs.Token.<init>(Token.java:166)
> > 	at testAFS.main(testAFS.java:643)
> > 
> 
> I think the problem is that we use Kerberos V and not kaserver.
> Are there any implementations for authentification on Kerberos V for JAFS? 

All the recent releases of openafs contain exactly the same copy of jafs,
and that copy of jafs requires kaserver.

You don't say what version of Kerberos V you are running.  If you
were running MIT kerberos V, you could also build and run fakeka.
That won't get you a working version of jafs, but it will get you closer.
jafs uses afsclient_TokenGetNew from libclientadmin.a - which always
calls both GetAFSToken (which will work you run fakeka), and GetKASToken
(which will *not* work with fakeka.)

So, I'm working on an improved version of jafs.  I plan to do these
three things:

/1/ make it work without kas.
/2/ make it work with kerberos 5 + rxkad.
/3/ make it work with kerberos 5 + rxk5.
I'm now discovering I also need to do a bit of
/4/ fix stupid error handling.
	There are a lot of places both in the test utility and in
	libjafs where the error behavior is to loop forever printing
	error messages.

I have something that gets past /1/, but runs into assorted
problems after that.  It didn't like not having /afs/.<cell> available,
the missing kas token caused other things to blow up, &etc.

I don't actually like the way that "Token" works at all.  Passing in
cellname is ok.  Passing in the user identity is ok, although passing in
an empty/null name to set noauth mode is interesting.  Passing in a
password sucks.  For an automated process, I'd also like to be able to
work with srvtabs, keytabs, getting a token from an already-authenticated
pag, or using an existing kerberos 5 credentials cache.  I'm not at
all sure how a java programmer would expect to do these things.

				-Marcus Watts

From mdw@spam.ifs.umich.edu  Sat Jun  9 09:32:05 2007
From: mdw@spam.ifs.umich.edu (Marcus Watts)
Date: Sat, 09 Jun 2007 04:32:05 -0400
Subject: [OpenAFS-devel] hidden commands
In-Reply-To: <ef99b6f40706080956p6d9bc20cyc442143ac3a11b42@mail.gmail.com>
References: <ef99b6f40706071818h47d14ab7pdf044319d83a4ec9@mail.gmail.com> <E1HwUGg-0004VD-5A@spam.ifs.umich.edu> <ef99b6f40706080956p6d9bc20cyc442143ac3a11b42@mail.gmail.com>
Message-ID: <E1HwwMf-0006g5-79@spam.ifs.umich.edu>

"Steven Jenkins" <steven.jenkins@gmail.com> sent:
...
> At umich.edu when we were running kaserver, we ran with "GETPASSWORD"
> > enabled.  We used it so that we could rename principals -- ptserver has a
> > rename option, but kaserver doesn't.  With special code running on the kdc
> > though, we could fetch the key, save it, delete the old ka instance,
> > create a new ka instance, and restore the user's key.  Since k4 keys
> > didn't
> > depend on the principal (only the cell), this worked.
> >
> ...
> 
> Would removing the code from the src tree be the best option at this point?

Why?  And which code are you talking about?

uniqname code to handle renaming principals in kaserver?
kaprocs.c code kamGetPassword?
kaprocs.c code kamGetEntry if logic for memcpy(&aentry->key... ?
admin_tools.c GetPassword command?
kauth.rg Getpassword grammar?

I think some more beneficial things we could do which would move
retiring kaserver forward include:

/1/ revise install directions to describe installing with
    kerberos V kdc by default. (both MIT & heimdal?)
/2/ put --enable-kaserver/--disable-kaserver into distributions.
/3/ make klog.k5 (from cvs head) the default in distributions.

I think a lot of sites already run without kaserver, so these
3 things should be close to reflecting status quo.  /1/ has
already come up several times--have we done something about this yet?

The rxk5 version of klog.k5 may have an interesting use of CMD_HIDDEN .
It has options "-k4" and "-k5" to enable the use of rxkad or rxk5.
If built without rxk5 support, it still supports the "-k4" option,
but makes it hidden.

				-Marcus

From sxw@inf.ed.ac.uk  Sat Jun  9 10:34:51 2007
From: sxw@inf.ed.ac.uk (Simon Wilkinson)
Date: Sat, 9 Jun 2007 10:34:51 +0100
Subject: [OpenAFS-devel] hidden commands
In-Reply-To: <E1HwwMf-0006g5-79@spam.ifs.umich.edu>
References: <ef99b6f40706071818h47d14ab7pdf044319d83a4ec9@mail.gmail.com> <E1HwUGg-0004VD-5A@spam.ifs.umich.edu> <ef99b6f40706080956p6d9bc20cyc442143ac3a11b42@mail.gmail.com> <E1HwwMf-0006g5-79@spam.ifs.umich.edu>
Message-ID: <2324BC54-673C-4D39-99E0-C2F1D163D8D0@inf.ed.ac.uk>

On 9 Jun 2007, at 09:32, Marcus Watts wrote:

> /1/ revise install directions to describe installing with
>     kerberos V kdc by default. (both MIT & heimdal?)

I've done this for the QuickStart Guide. It currently assumes that  
you're using a MIT KDC, but it would be trivial for someone with  
Heimdal knowledge to add paragraphs describing the Heimdal  
incantations. The changes are all in CVS HEAD.

Cheers,

Simon.


From shadow@dementia.org  Sat Jun  9 21:32:23 2007
From: shadow@dementia.org (Derrick J Brashear)
Date: Sat, 9 Jun 2007 16:32:23 -0400 (EDT)
Subject: [OpenAFS-devel] hidden commands
In-Reply-To: <ef99b6f40706081739s73277059tc2da427226ff8f9c@mail.gmail.com>
References: <ef99b6f40706071818h47d14ab7pdf044319d83a4ec9@mail.gmail.com>
 <E1HwUGg-0004VD-5A@spam.ifs.umich.edu>  <ef99b6f40706080956p6d9bc20cyc442143ac3a11b42@mail.gmail.com>
 <Pine.GSO.4.61-042.0706081331590.25687@johnstown.andrew.cmu.edu>
 <ef99b6f40706081739s73277059tc2da427226ff8f9c@mail.gmail.com>
Message-ID: <Pine.GSO.4.61-042.0706091631360.25687@johnstown.andrew.cmu.edu>

On Fri, 8 Jun 2007, Steven Jenkins wrote:

> On 6/8/07, Derrick J Brashear 
> <shadow@dementia.org> wrote:
>> 
>> why bother removing it. all of src/kauth is 
>> already on the block
>> 
>
> What's the scheduled removal date for all of 
> src/kauth? It it's fairly
> imminent, I agree there's no big win.  However, if 
> it's still 'to be decided
> when', then I think there's value in going ahead 
> and doing some
> opportunistic cleaning.

Then we have to test and make sure it's good, still, until that removal 
does come. It's not worth the time.

From Atro.Tossavainen@helsinki.fi  Tue Jun  5 06:35:57 2007
From: Atro.Tossavainen@helsinki.fi (Atro Tossavainen)
Date: Tue, 5 Jun 2007 08:35:57 +0300 (EEST)
Subject: [OpenAFS-devel] "configure" shortcomings
Message-ID: <200706050535.l555Zv3O010974@ruuvi.it.helsinki.fi>

Was just building OpenAFS in a rather bare-bones environment and noted
the following.

"configure" should complain and abort if flex and yacc are missing
from the system (because the compilation process will attempt to use
these and will complain and abort if they are missing).

"configure" should at least mention the lack of PAM headers (it might
do this already, just didn't see it in the logs).

-- 
Atro Tossavainen (Mr.)               / The Institute of Biotechnology at
Systems Analyst, Techno-Amish &     / the University of Helsinki, Finland,
+358-9-19158939  UNIX Dinosaur     / employs me, but my opinions are my own.
< URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS

From mdw@spam.ifs.umich.edu  Mon Jun 11 23:22:35 2007
From: mdw@spam.ifs.umich.edu (Marcus Watts)
Date: Mon, 11 Jun 2007 18:22:35 -0400
Subject: [OpenAFS-devel] more JAFS stuff
Message-ID: <E1HxsHT-0000F6-Uz@spam.ifs.umich.edu>

I've gotten jafs to at least run through a semblance of its
test utility 'testAFS' without errors that are at least too
glaring.  I still have lots of debug messages, and I don't
think I've got the no-kas case quite right.  But I'm
running into a more general problem now.

I think JAFS has a basic design problem.  It really likes
to gather lots of information in advance of its being needed.
It maintains list of users, servers, and other parts of the cell,
as part of the cell object.  The comments in the jafs code suggest
that its author was assuming it would be the main administrative
agent in a cell (or better yet the sole administrative agent),
which was presumably of small-to-medium size.  This causes a number
of problems:

/1/ the list of users is gotten by doing a "pts listentries"
	-- probably only admin can do this.
/2/ the list of users is the union of pts & kas users.
	-- at best annoying if one isn't running kaserver.
/3/ the list of servers is gotten using the equivalent
	of "vos listaddrs" and probably "vos listpart".
	this runs real slow if one or more servers are down.
/4/ these lists are refreshed more frequently than necessary.
/5/ a failure to refresh a list isn't reported very gracefully.

I think fixing these requires doing a somewhat more radical
job of altering its API.  I'd like to change things so that
the routines offered are a more direct reflection of the underlying
operations on the various servers, and any data consistency
issues are a much more clear responsibility of the calling application.
Ie, if you want a list of all users, you ask for it.  If you want to save it,
that's your problem.  If you want a list of servers, again ask for it;
unless you then ask for a list of partitions on a server, you won't get it.

I'm very interested in any ideas other people might have on this.

				-Marcus

From dean@av8.com  Tue Jun 12 02:16:00 2007
From: dean@av8.com (Dean Anderson)
Date: Mon, 11 Jun 2007 21:16:00 -0400 (EDT)
Subject: [OpenAFS-devel] Re: [OpenAFS] 1.5.19 build fails on SunOS 5.11 snv62
 SPARC
Message-ID: <Pine.LNX.4.44.0706112112580.5175-100000@citation2.av8.net>

Take look at this: 

		--Dean

---------- Forwarded message ----------
Date: Mon, 7 May 2007 09:02:22 -0400
From: James Carlson <james.d.carlson@Sun.COM>
To: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: opensolaris-code@opensolaris.org, mladen@imit.kth.se,
     Dana H. Myers <Dana.Myers@Sun.COM>
Subject: [osol-code] usable kernel symbols [was Re: Executing a kernel
    thread periodically]

Thomas De Schampheleire writes:
> There some things I would like to make sure first: can I use all kernel
> functions from a module? In Linux, modules can only use those functions from
> the kernel which are exported by the EXPORT_SYMBOL macro.

Do you really mean "can I" (am I able to) or "should I" (is this a
wise choice)?

Yes, all non-static symbols are available.  In the kernel, we're all
friends.

However, if you have any hope that your module will not just fall over
the next time something in the kernel changes, you should limit
yourself to the functions and symbols documented in section (9s, 9e,
9f) of the man pages.  See also the "writing device drivers" book.

Which interfaces are available depends in part on how you deliver your
software.  If it's not part of ON (you create your own packages or
other install mechanisms), then you should stick to the DDI, and read
the documentation carefully.  If it's part of ON (integrated via
OpenSolaris), then you're able to use "Consolidation Private"
interfaces without special arrangement, which include many of the
undocumented kernel symbols.

You can use symbols in a way contrary to what the original developer
intended if you establish something called an "ARC contract" on the
interfaces you need.  I wouldn't recommend doing this unless it's just
_absolutely_ necessary to make your driver work.

> I suppose there is a similar mechanism for OpenSolaris, isn't there? In that
> case: how do I know which functions are exported and which aren't?

You know by reading the documentation.  No, we don't have equivalent
symbol scoping mechanisms yet for the kernel.  (We probably should,
and it'd be a very nice thing to have, but it just hasn't been done.)

> Secondly, I am still stuck with the question about how my module will be
> loaded. It should be loaded by default when booting, is there a way to
> achieve that?

At a guess, I think you might want to create a driver (so that you'll
have a control node) and do something like this in your driver.conf
file:

name="mydriver" parent="pseudo" instance=0;
ddi-forceattach=1;

-- 
James Carlson, Solaris Networking              <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code




From kane96@gmx.de  Thu Jun 14 17:40:39 2007
From: kane96@gmx.de (kane96@gmx.de)
Date: Thu, 14 Jun 2007 18:40:39 +0200
Subject: [OpenAFS-devel] JAFS make error
In-Reply-To: <E1HwvpM-0006cn-UZ@spam.ifs.umich.edu>
References: <20070524122512.103150@gmx.net>
 <Pine.GSO.4.61-042.0705240832280.19224@johnstown.andrew.cmu.edu>
 <20070524141236.65600@gmx.net>
 <Pine.GSO.4.61-042.0705241026210.19224@johnstown.andrew.cmu.edu>
 <20070601133222.162570@gmx.net> <E1HuLbc-0004R8-B3@spam.ifs.umich.edu>
 <20070604124635.54550@gmx.net> <E1HvJ6K-0007Fx-II@spam.ifs.umich.edu>
 <20070605103618.12230@gmx.net> <20070606131731.92940@gmx.net>
 <20070608114207.251750@gmx.net> <E1HwvpM-0006cn-UZ@spam.ifs.umich.edu>
Message-ID: <20070614164039.287570@gmx.net>

> You don't say what version of Kerberos V you are running.
Ohh, sorry, I forget. We use MIT Version
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

From megacz@cs.berkeley.edu  Thu Jun 14 22:30:40 2007
From: megacz@cs.berkeley.edu (Adam Megacz)
Date: Thu, 14 Jun 2007 14:30:40 -0700
Subject: [OpenAFS-devel] defaults for 1.4.5: afsdb and dynroot?
Message-ID: <x3bqfip6kf.fsf@nowhere.com>

Is there any chance that the MacOS+Linux packages for the next release
could enable AFSDB and DYNROOT by default?

  - a

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380


From kane96@gmx.de  Fri Jun 15 09:43:12 2007
From: kane96@gmx.de (kane96@gmx.de)
Date: Fri, 15 Jun 2007 10:43:12 +0200
Subject: [OpenAFS-devel] kvibille-0.1 make error
Message-ID: <20070615084312.236560@gmx.net>

Hi,
i get errors by doing "make" on kvibille-0.1. I did "./configure" without any other options:

kvibille_main_window.hpp:42: error: extra qualification 'KvibilleWindow::' on member 'makeColumn'
kvibille_main_window.hpp:49: error: extra qualification 'KvibilleWindow::' on member 'afegeixNoSeleccionable'
kvibille_main_window.hpp:55: error: extra qualification 'KvibilleWindow::' on member 'afegeixSeleccionable'
kvibille_main_window.hpp:56: error: extra qualification 'KvibilleWindow::' on member 'setStatus'
kvibille_main_window.hpp:146: error: extra qualification 'KvibilleWindow::' on member 'afegeixElement'
make[2]: *** [libkvibille_nautilus_la-kvibille_nautilus_page.lo] Error 1

-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

From megacz@cs.berkeley.edu  Sat Jun 16 20:05:49 2007
From: megacz@cs.berkeley.edu (Adam Megacz)
Date: Sat, 16 Jun 2007 12:05:49 -0700
Subject: [OpenAFS-devel] Re: defaults for 1.4.5: afsdb and dynroot?
References: <x3bqfip6kf.fsf@nowhere.com>
Message-ID: <x37iq3wwhe.fsf@nowhere.com>

Adam Megacz <megacz@cs.berkeley.edu> writes:
> Is there any chance that the MacOS+Linux packages for the next release
> could enable AFSDB and DYNROOT by default?

Correction: just afsdb.  It seems that 1.4.4 ships with dynroot
enabled (good!) but afsdb disabled (bad!).

   - a

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380


From scs@umich.edu  Mon Jun 18 17:00:29 2007
From: scs@umich.edu (Steve Simmons)
Date: Mon, 18 Jun 2007 12:00:29 -0400
Subject: [OpenAFS-devel] defaults for 1.4.5: afsdb and dynroot?
In-Reply-To: <x3bqfip6kf.fsf@nowhere.com>
References: <x3bqfip6kf.fsf@nowhere.com>
Message-ID: <8DFECC6D-B632-4666-8598-144509C2EE55@umich.edu>

On Jun 14, 2007, at 5:30 PM, Adam Megacz wrote:

>
> Is there any chance that the MacOS+Linux packages for the next release
> could enable AFSDB and DYNROOT by default?

I would have no objections to this.

Steve

From shadow@dementia.org  Mon Jun 18 17:10:24 2007
From: shadow@dementia.org (Derrick J Brashear)
Date: Mon, 18 Jun 2007 12:10:24 -0400 (EDT)
Subject: [OpenAFS-devel] defaults for 1.4.5: afsdb and dynroot?
In-Reply-To: <8DFECC6D-B632-4666-8598-144509C2EE55@umich.edu>
References: <x3bqfip6kf.fsf@nowhere.com> <8DFECC6D-B632-4666-8598-144509C2EE55@umich.edu>
Message-ID: <Pine.GSO.4.61-042.0706181207220.25687@johnstown.andrew.cmu.edu>

On Mon, 18 Jun 2007, Steve Simmons wrote:

>
> On Jun 14, 2007, at 5:30 PM, Adam Megacz wrote:
>
>> 
>> Is there any chance that the MacOS+Linux packages for the next release
>> could enable AFSDB and DYNROOT by default?
>
> I would have no objections to this.

If you're installed vmware fusion, you know Installer.app can have 
something integrated to ask questions; The ideal case would be that we'd 
have something pop up to ask for
1) your choice of cell name
2) whether you wish to use the bundled CellServDB, download one, (or enter 
one by hand?)
3) a small set of options, like afsdb, which i think should default to on

and also have it work in CLI mode (run /usr/sbin/installer sometime if you 
don't know what I mean)...

but also have some way to install in question-free mode.

Changing to afsdb by default mid-1.4 does offer some possible confusion, 
but given some other changes which (basically need to) appear in 1.4.5 
perhaps it won't be that confusing compared to other things.



From megacz@cs.berkeley.edu  Mon Jun 18 17:28:13 2007
From: megacz@cs.berkeley.edu (Adam Megacz)
Date: Mon, 18 Jun 2007 09:28:13 -0700
Subject: [OpenAFS-devel] Re: defaults for 1.4.5: afsdb and dynroot?
References: <x3bqfip6kf.fsf@nowhere.com>
 <8DFECC6D-B632-4666-8598-144509C2EE55@umich.edu>
 <Pine.GSO.4.61-042.0706181207220.25687@johnstown.andrew.cmu.edu>
Message-ID: <x3myyxkz1e.fsf@nowhere.com>

Derrick J Brashear <shadow@dementia.org> writes:
> 3) a small set of options, like afsdb, which i think should default to on

I'll look into figuring out how this is done.  It would also be nice
if it defaulted to on for Windows (unless it already does?) and Linux
(I'm pretty sure it doesn't).

> Changing to afsdb by default mid-1.4 does offer some possible
> confusion, but given some other changes which (basically need to)
> appear in 1.4.5 perhaps it won't be that confusing compared to other
> things.

Unless my understanding is incorrect, I don't think that adding -afsdb
can ever cause any functionality which was previously working to stop
working.  Doesn't viced only check for AFSDB records if the cell is
not found in CellServDB?

  - a

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380


From jaltman@secure-endpoints.com  Mon Jun 18 18:21:33 2007
From: jaltman@secure-endpoints.com (Jeffrey Altman)
Date: Mon, 18 Jun 2007 13:21:33 -0400
Subject: [OpenAFS-devel] Re: defaults for 1.4.5: afsdb and dynroot?
In-Reply-To: <x3myyxkz1e.fsf@nowhere.com>
References: <x3bqfip6kf.fsf@nowhere.com>	<8DFECC6D-B632-4666-8598-144509C2EE55@umich.edu>	<Pine.GSO.4.61-042.0706181207220.25687@johnstown.andrew.cmu.edu> <x3myyxkz1e.fsf@nowhere.com>
Message-ID: <4676BF1D.5060704@secure-endpoints.com>

This is a cryptographically signed message in MIME format.

--------------ms060107020008060208000301
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Adam Megacz wrote:
> Derrick J Brashear <shadow@dementia.org> writes:
>> 3) a small set of options, like afsdb, which i think should default to on
> 
> I'll look into figuring out how this is done.  It would also be nice
> if it defaulted to on for Windows (unless it already does?) and Linux
> (I'm pretty sure it doesn't).

The Windows AFS client service defaults to off.
The Windows AFS installer defaults to on.

This is how it should be configured for other platforms as well.

>> Changing to afsdb by default mid-1.4 does offer some possible
>> confusion, but given some other changes which (basically need to)
>> appear in 1.4.5 perhaps it won't be that confusing compared to other
>> things.
> 
> Unless my understanding is incorrect, I don't think that adding -afsdb
> can ever cause any functionality which was previously working to stop
> working.  Doesn't viced only check for AFSDB records if the cell is
> not found in CellServDB?

Turning on AFSDB records will result in two unwanted behaviors.

(1) Administrators who install a restricted CellServDB file to limit the
accessible cells will no longer find their client's restricted to the
specified list

(2) Users will experience delays where there weren't any before when
accessing /afs/foobar where foobar is not a cell listed in either
CellServDB or DNS.

Jeffrey Altman

--------------ms060107020008060208000301
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC
AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX
DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy
aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c
bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF
PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184
9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d
1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG
A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1
AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk
0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr
5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow
czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl
ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv
aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU
3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl
DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL
AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM
94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV
lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB
gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t
ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3
UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw
gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp
bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w
MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU
aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg
RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV
+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr
hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/
p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8
MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls
Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh
YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/
TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc
OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID
YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA2MTgxNzIxMzNaMCMGCSqGSIb3DQEJBDEWBBTh/5P1
1L4ofll2TTQBm+7Cx7H/tTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB
BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg
KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg
Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ
KoZIhvcNAQEBBQAEggEAT+/8ZENJvsro3mnPm3cxQC07BnTABhctA+p37otrTfRmIB5XhvrA
7j4qVPKxaFFwgOgkI1DbyatJK4VNTRGTUzX75DM7s8VhfRlylzR0v1hlRNYFA1T2pRjn0luJ
bTffr9oTENFQWJFV1pNfm3Fj0tfv1ld7h07dY7812gEJVskhzhxibboxqXFwd5sg+QZncbnx
QjYxDdTDqccWx/ngEdyVe/AljeDlmBQK4uYujQcl1z8PP8M/IgJ+F482/Q8Y3h9l8nYGDXw/
6fXTGxtoJpc+ZRJ+QoO//VMp00CU4E+Lst/2PCh+bK8ULhovUe3VoyigIqBF5M26gfzC+bwJ
CAAAAAAAAA==
--------------ms060107020008060208000301--


From shadow@dementia.org  Mon Jun 18 18:33:48 2007
From: shadow@dementia.org (Derrick J Brashear)
Date: Mon, 18 Jun 2007 13:33:48 -0400 (EDT)
Subject: [OpenAFS-devel] Re: defaults for 1.4.5: afsdb and dynroot?
In-Reply-To: <x3myyxkz1e.fsf@nowhere.com>
References: <x3bqfip6kf.fsf@nowhere.com> <8DFECC6D-B632-4666-8598-144509C2EE55@umich.edu>
 <Pine.GSO.4.61-042.0706181207220.25687@johnstown.andrew.cmu.edu>
 <x3myyxkz1e.fsf@nowhere.com>
Message-ID: <Pine.GSO.4.61-042.0706181332350.25687@johnstown.andrew.cmu.edu>

On Mon, 18 Jun 2007, Adam Megacz wrote:

>
> Derrick J Brashear <shadow@dementia.org> writes:
>> 3) a small set of options, like afsdb, which i think should default to on
>
> I'll look into figuring out how this is done.  It would also be nice
> if it defaulted to on for Windows (unless it already does?) and Linux
> (I'm pretty sure it doesn't).

If you don't know what the default is, how do you know you want it to 
change? :)

> Unless my understanding is incorrect, I don't think that adding -afsdb
> can ever cause any functionality which was previously working to stop
> working.  Doesn't viced only check for AFSDB records if the cell is
> not found in CellServDB?

It can cause a behavior change which while silly could be deliberate, but 
really it's more about finding bugs which wouldn't have mattered before if 
you chose the defaults.



From shadow@dementia.org  Mon Jun 18 21:46:17 2007
From: shadow@dementia.org (Derrick J Brashear)
Date: Mon, 18 Jun 2007 16:46:17 -0400 (EDT)
Subject: [OpenAFS-devel] IP address change monitoring?
Message-ID: <Pine.GSO.4.61-042.0706181644360.11595@johnstown.andrew.cmu.edu>

Right now we do this on Windows and MacOS (to trigger updates to the 
client)

What other platforms support a sensible way of getting IP address change 
notifications? (We could certainly get dhcp notification by script in most 
Linuxes but that's OS-specific. I suppose if that's the best we can do I 
can provide a helper which you can run when your addresses changed which 
gathers and sets new addresses)

Thoughts?
Derrick


From megacz@cs.berkeley.edu  Mon Jun 18 22:25:03 2007
From: megacz@cs.berkeley.edu (Adam Megacz)
Date: Mon, 18 Jun 2007 14:25:03 -0700
Subject: [OpenAFS-devel] Re: defaults for 1.4.5: afsdb and dynroot?
References: <x3bqfip6kf.fsf@nowhere.com>
 <8DFECC6D-B632-4666-8598-144509C2EE55@umich.edu>
 <Pine.GSO.4.61-042.0706181207220.25687@johnstown.andrew.cmu.edu>
 <x3myyxkz1e.fsf@nowhere.com> <4676BF1D.5060704@secure-endpoints.com>
Message-ID: <x3k5u1uf9s.fsf@nowhere.com>

Jeffrey Altman <jaltman@secure-endpoints.com> writes:
> The Windows AFS client service defaults to off.
> The Windows AFS installer defaults to on.
> This is how it should be configured for other platforms as well.

I'm not as familiar with the Windows client as with the other
platforms, but do you mean that "if unspecified, the client will not
use afsdb; however, the installer will specify afsdb unless told
otherwise by the user during installation"?  That would make sense.

> (1) Administrators who install a restricted CellServDB file to limit the
> accessible cells will no longer find their client's restricted to the
> specified list

Ok, good point.

> (2) Users will experience delays where there weren't any before when
> accessing /afs/foobar where foobar is not a cell listed in either
> CellServDB or DNS.

True, but probably an extremely infrequent event.

  - a

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380


From shadow@dementia.org  Mon Jun 18 22:58:14 2007
From: shadow@dementia.org (Derrick J Brashear)
Date: Mon, 18 Jun 2007 17:58:14 -0400 (EDT)
Subject: [OpenAFS-devel] Re: defaults for 1.4.5: afsdb and dynroot?
In-Reply-To: <x3k5u1uf9s.fsf@nowhere.com>
References: <x3bqfip6kf.fsf@nowhere.com> <8DFECC6D-B632-4666-8598-144509C2EE55@umich.edu>
 <Pine.GSO.4.61-042.0706181207220.25687@johnstown.andrew.cmu.edu>
 <x3myyxkz1e.fsf@nowhere.com> <4676BF1D.5060704@secure-endpoints.com>
 <x3k5u1uf9s.fsf@nowhere.com>
Message-ID: <Pine.GSO.4.61-042.0706181757200.11595@johnstown.andrew.cmu.edu>

On Mon, 18 Jun 2007, Adam Megacz wrote:

>
> Jeffrey Altman <jaltman@secure-endpoints.com> writes:
>> The Windows AFS client service defaults to off.
>> The Windows AFS installer defaults to on.
>> This is how it should be configured for other platforms as well.
>
> I'm not as familiar with the Windows client as with the other
> platforms, but do you mean that "if unspecified, the client will not
> use afsdb; however, the installer will specify afsdb unless told
> otherwise by the user during installation"?  That would make sense.
>
>> (1) Administrators who install a restricted CellServDB file to limit the
>> accessible cells will no longer find their client's restricted to the
>> specified list
>
> Ok, good point.

Note that the smart thing for said admins to do is use a transform or a 
customized installer, but we have no transform tool for MacOS (yet. I have 
plans...)

>> (2) Users will experience delays where there weren't any before when
>> accessing /afs/foobar where foobar is not a cell listed in either
>> CellServDB or DNS.
>
> True, but probably an extremely infrequent event.

Depends if you have an dumb scripts.


From shadow@dementia.org  Sat Jun 23 15:58:01 2007
From: shadow@dementia.org (Derrick J Brashear)
Date: Sat, 23 Jun 2007 10:58:01 -0400 (EDT)
Subject: [OpenAFS-devel] IP address change monitoring?
In-Reply-To: <Pine.GSO.4.61-042.0706181644360.11595@johnstown.andrew.cmu.edu>
References: <Pine.GSO.4.61-042.0706181644360.11595@johnstown.andrew.cmu.edu>
Message-ID: <Pine.GSO.4.61-042.0706231057460.11595@johnstown.andrew.cmu.edu>

On Mon, 18 Jun 2007, Derrick J Brashear wrote:

> Right now we do this on Windows and MacOS (to trigger updates to the client)
>
> What other platforms support a sensible way of getting IP address change 
> notifications? (We could certainly get dhcp notification by script in most 
> Linuxes but that's OS-specific. I suppose if that's the best we can do I can 
> provide a helper which you can run when your addresses changed which gathers 
> and sets new addresses)
>
> Thoughts?

Nobody cares? Nobody wants this?


From shadow@dementia.org  Sat Jun 23 16:00:54 2007
From: shadow@dementia.org (Derrick J Brashear)
Date: Sat, 23 Jun 2007 11:00:54 -0400 (EDT)
Subject: [OpenAFS-devel] Re: [OpenAFS] 1.5.19 build fails on SunOS 5.11
 snv62 SPARC
In-Reply-To: <002b01c7a236$d2d7cc00$2d01a8c0@IBMT42>
References: <25350446.249531179267215380.JavaMail.root@franklin.tjhsst.edu>
 <C955206C-9853-43CF-BD0A-9742023C005A@umbc.edu> <002b01c7a236$d2d7cc00$2d01a8c0@IBMT42>
Message-ID: <Pine.GSO.4.61-042.0706231058450.11595@johnstown.andrew.cmu.edu>

On Tue, 29 May 2007, William Yang wrote:

> Then the best idea I can come up with right now is just to add a 
> configure script check that determines what kernel version is running 
> and to set an independent define for those particular code blocks.

Well, it's worse than that. If we use netstack stuff anywhere we need to 
version the kernel module for pre- and post- netstack, I assume. So...

What version(s) is netstack in?


From sxw@inf.ed.ac.uk  Sat Jun 23 18:30:33 2007
From: sxw@inf.ed.ac.uk (Simon Wilkinson)
Date: Sat, 23 Jun 2007 18:30:33 +0100
Subject: [OpenAFS-devel] IP address change monitoring?
In-Reply-To: <Pine.GSO.4.61-042.0706231057460.11595@johnstown.andrew.cmu.edu>
References: <Pine.GSO.4.61-042.0706181644360.11595@johnstown.andrew.cmu.edu> <Pine.GSO.4.61-042.0706231057460.11595@johnstown.andrew.cmu.edu>
Message-ID: <031F1B82-8C47-4FDF-B8C0-F4ED23996F29@inf.ed.ac.uk>

On 23 Jun 2007, at 15:58, Derrick J Brashear wrote:

> On Mon, 18 Jun 2007, Derrick J Brashear wrote:
>
>> Right now we do this on Windows and MacOS (to trigger updates to  
>> the client)
>>
>> What other platforms support a sensible way of getting IP address  
>> change notifications? (We could certainly get dhcp notification by  
>> script in most Linuxes but that's OS-specific. I suppose if that's  
>> the best we can do I can provide a helper which you can run when  
>> your addresses changed which gathers and sets new addresses)
>>
>> Thoughts?
>
> Nobody cares? Nobody wants this?

We'd be interested on this.

 From what I can see, address change monitoring in the Linux  
application space is in a certain state of flux. There seem to be a  
large number of window manager (believe it or not) specifc mechanisms  
for dealing with address change. I think that the best mechanism here  
would be to provide a 'fs' command that can be run to signal AFS that  
the interface addresses have changed, as you suggest. That way sites,  
and distributions, can integrate it into whatever funky interface  
management system they prefer.

Cheers,

Simon.


From jhutz@cmu.edu  Tue Jun 26 01:27:11 2007
From: jhutz@cmu.edu (Jeffrey Hutzelman)
Date: Mon, 25 Jun 2007 20:27:11 -0400
Subject: [OpenAFS-devel] Solaris heads-up
In-Reply-To: <FB9C5A91-CC2B-4C22-B8D7-2D042F23CEC2@umbc.edu>
References: <FB9C5A91-CC2B-4C22-B8D7-2D042F23CEC2@umbc.edu>
Message-ID: <8ED4F6A835C466B1B924EEE8@sirius.fac.cs.cmu.edu>


On Friday, May 25, 2007 02:02:45 PM -0400 Dale Ghent <daleg@umbc.edu> wrote:

>
> This was just putback into nevada:
>
> 6549515 PSARC 2007/064: uid_t and gid_t to become unsigned
>
> I haven't looked through the afs code, but off the top of anyone's  head,
> will this impact the client?

No, I don't think this should cause an issue.  We already treat groups as 
unsigned, casting as necessary.  We do normally treat vice ID's as signed, 
so things may be a bit confusing in contexts where these are conflated with 
UNIX UID's, such as with file ownership.  However, there should not be any 
actual problems here.

-- Jeff

From jhutz@cmu.edu  Tue Jun 26 01:32:22 2007
From: jhutz@cmu.edu (Jeffrey Hutzelman)
Date: Mon, 25 Jun 2007 20:32:22 -0400
Subject: [OpenAFS-devel] Re: [OpenAFS] 1.5.19 build fails on SunOS 5.11
 snv62 SPARC
In-Reply-To: <Pine.LNX.4.44.0706112112580.5175-100000@citation2.av8.net>
References: <Pine.LNX.4.44.0706112112580.5175-100000@citation2.av8.net>
Message-ID: <E62DF3B38DE76BA559D1C15A@sirius.fac.cs.cmu.edu>


On Monday, June 11, 2007 09:16:00 PM -0400 Dean Anderson <dean@av8.com> 
wrote:

> Take look at this:

None of this is news to us.
Bear in mind that the Solaris DDI is very slanted toward "device drivers"; 
that is, pieces of code whose purpose is to talk to hardware.  OpenAFS is 
not a device driver, which has relatively little impact on the level of 
stability we can expect from interfaces not in the DDI, but makes a big 
difference in whether it is possible to do what we do using only those 
interfaces.

Fortunately, the OpenSolaris project is, slowly, documenting and 
stabilizing kernel interfaces needed by components other than device 
drivers.  We begin using these new and/or newly-documented interfaces 
according to need, opportunity, and availability of cycles.

-- Jeff

From jhutz@cmu.edu  Tue Jun 26 01:45:42 2007
From: jhutz@cmu.edu (Jeffrey Hutzelman)
Date: Mon, 25 Jun 2007 20:45:42 -0400
Subject: [OpenAFS-devel] status of src/tests
In-Reply-To: <Pine.LNX.4.64.0706011228240.18391@ossigeno.math.unifi.it>
References: <ef99b6f40705311308n7e0b0809qfbddceecf4853e1b@mail.gmail.com>
 <847e389f0706010327m1d93b374tbabe7cc05f32c428@mail.gmail.com>
 <Pine.LNX.4.64.0706011228240.18391@ossigeno.math.unifi.it>
Message-ID: <6E2F2FBD384498C9BB73BA44@sirius.fac.cs.cmu.edu>


On Friday, June 01, 2007 12:41:15 PM +0200 Alberto Mancini 
<mancini@math.unifi.it> wrote:

> Actually, I think that ``dumptool'' should not be in src/tests directory
> too.
>
> If someone is doing some work in the ``tests'' directory
> could be a good idea to change this.
>
> I have no idea of the ``meaning'' of most of the files in
> the tests dir but i can help in moving/testing dumptool.
>
> There is any open issue with dumptool ?

Oh, dear.  There's a copy of dumptool in there?  That's probably as 
out-of-date as the copy of my volume dump utilities, the latest version of 
which can be found in /afs/grand.central.org/software/dumpscan.

I don't think either of those tools, or various others, really belong in 
the OpenAFS distribution.  OpenAFS should concentrate on being a 
filesystem, not on incorporating into its distribution every tool someone 
might want to use with it.

That said, it's fine for the tests to include snapshots or stripped-down 
versions of tools _for use in the tests_.  This is considerably more 
manageable than expecting someone to download and build various other 
packages in order to make the tests work.  It's also useful because tests 
often depend on the precise output of things, and can fail in strange ways 
when the "wrong" versions of tools are used.  So, leave it in if it's being 
used, but consider whether it's possible to construct tests that use 
dumptool _or_ the dumpscan tools, instead of both.


It is probably the case that dumptool provides functionality not currently 
available from the dumpscan tools and libraries.  I would be glad to accept 
patches to correct this situation.

-- Jeff

From shadow@dementia.org  Tue Jun 26 01:48:03 2007
From: shadow@dementia.org (Derrick J Brashear)
Date: Mon, 25 Jun 2007 20:48:03 -0400 (EDT)
Subject: [OpenAFS-devel] status of src/tests
In-Reply-To: <6E2F2FBD384498C9BB73BA44@sirius.fac.cs.cmu.edu>
References: <ef99b6f40705311308n7e0b0809qfbddceecf4853e1b@mail.gmail.com>
 <847e389f0706010327m1d93b374tbabe7cc05f32c428@mail.gmail.com>
 <Pine.LNX.4.64.0706011228240.18391@ossigeno.math.unifi.it>
 <6E2F2FBD384498C9BB73BA44@sirius.fac.cs.cmu.edu>
Message-ID: <Pine.GSO.4.61-042.0706252046170.11595@johnstown.andrew.cmu.edu>

On Mon, 25 Jun 2007, Jeffrey Hutzelman wrote:

> Oh, dear.  There's a copy of dumptool in there?  That's probably as 
> out-of-date as the copy of my volume dump utilities, the latest version of 
> which can be found in /afs/grand.central.org/software/dumpscan.

I don't think Ken did any work to dumptool since then.

> I don't think either of those tools, or various others, really belong in the 
> OpenAFS distribution.  OpenAFS should concentrate on being a filesystem, not 
> on incorporating into its distribution every tool someone might want to use 
> with it.

Because dumps are portable. Oh wait. They're not. OpenAFS implements them.
You're diluting your point by making it on this particular topic.


From jhutz@cmu.edu  Tue Jun 26 02:05:11 2007
From: jhutz@cmu.edu (Jeffrey Hutzelman)
Date: Mon, 25 Jun 2007 21:05:11 -0400
Subject: [OpenAFS-devel] IP address change monitoring?
In-Reply-To: <Pine.GSO.4.61-042.0706231057460.11595@johnstown.andrew.cmu.edu>
References: <Pine.GSO.4.61-042.0706181644360.11595@johnstown.andrew.cmu.edu>
 <Pine.GSO.4.61-042.0706231057460.11595@johnstown.andrew.cmu.edu>
Message-ID: <D12480C436B109232CE5D2D6@sirius.fac.cs.cmu.edu>


On Saturday, June 23, 2007 10:58:01 AM -0400 Derrick J Brashear 
<shadow@dementia.org> wrote:

> On Mon, 18 Jun 2007, Derrick J Brashear wrote:
>
>> Right now we do this on Windows and MacOS (to trigger updates to the
>> client)
>>
>> What other platforms support a sensible way of getting IP address change
>> notifications? (We could certainly get dhcp notification by script in
>> most  Linuxes but that's OS-specific. I suppose if that's the best we
>> can do I can  provide a helper which you can run when your addresses
>> changed which gathers  and sets new addresses)
>>
>> Thoughts?
>
> Nobody cares? Nobody wants this?

I certainly want this; I carry my laptop around ~everwhere, and it's not 
fun when things stop working or become slow because my machine is 
advertising an address it hasn't had for weeks, on a network on the other 
side of the city.

I haven't looked in much detail, but on Linux it should be possible to get 
this sort of notification directly from the network stack, via a netlink 
socket.  Alternately, most modern distributions are set up to send dbus 
events on interface state changes; this is used by the various GUI network 
management widgets.  Still, this notification is ultimately coming from 
dhclient, so we're probably better off getting what we need directly from 
the kernel if we can (does anyone know if HAL monitors interface state?)

-- Jeff

From jhutz@cmu.edu  Tue Jun 26 02:07:18 2007
From: jhutz@cmu.edu (Jeffrey Hutzelman)
Date: Mon, 25 Jun 2007 21:07:18 -0400
Subject: [OpenAFS-devel] status of src/tests
In-Reply-To: <Pine.GSO.4.61-042.0706252046170.11595@johnstown.andrew.cmu.edu>
References: <ef99b6f40705311308n7e0b0809qfbddceecf4853e1b@mail.gmail.com>
 <847e389f0706010327m1d93b374tbabe7cc05f32c428@mail.gmail.com>
 <Pine.LNX.4.64.0706011228240.18391@ossigeno.math.unifi.it>
 <6E2F2FBD384498C9BB73BA44@sirius.fac.cs.cmu.edu>
 <Pine.GSO.4.61-042.0706252046170.11595@johnstown.andrew.cmu.edu>
Message-ID: <7E7C643C82C77BFDE521ABAB@sirius.fac.cs.cmu.edu>


On Monday, June 25, 2007 08:48:03 PM -0400 Derrick J Brashear 
<shadow@dementia.org> wrote:

> On Mon, 25 Jun 2007, Jeffrey Hutzelman wrote:
>
>> Oh, dear.  There's a copy of dumptool in there?  That's probably as
>> out-of-date as the copy of my volume dump utilities, the latest version
>> of  which can be found in /afs/grand.central.org/software/dumpscan.
>
> I don't think Ken did any work to dumptool since then.
>
>> I don't think either of those tools, or various others, really belong in
>> the  OpenAFS distribution.  OpenAFS should concentrate on being a
>> filesystem, not  on incorporating into its distribution every tool
>> someone might want to use  with it.
>
> Because dumps are portable. Oh wait. They're not. OpenAFS implements them.
> You're diluting your point by making it on this particular topic.

A variety of things implement them, and not all of those things are 
OpenAFS.  They are part of the AFSVol RPC interface, which is not private 
to OpenAFS.  If you want to repeat the argument about whether you should be 
gatekeeping OpenAFS or filling the kitchen sink, I suggest we do so offline.

-- Jeff

From rees@umich.edu  Tue Jun 26 03:22:19 2007
From: rees@umich.edu (Jim Rees)
Date: Mon, 25 Jun 2007 21:22:19 -0500
Subject: [OpenAFS-devel] IP address change monitoring?
In-Reply-To: <D12480C436B109232CE5D2D6@sirius.fac.cs.cmu.edu>
References: <Pine.GSO.4.61-042.0706181644360.11595@johnstown.andrew.cmu.edu> <Pine.GSO.4.61-042.0706231057460.11595@johnstown.andrew.cmu.edu> <D12480C436B109232CE5D2D6@sirius.fac.cs.cmu.edu>
Message-ID: <20070626022218.GA23605@citi.umich.edu>

I discard all my callbacks and rx connections on suspend.  That works 99% of
the time, because at least on my laptop, address changes tend to happen when
I suspend in one location then resume in another.

The code I use to do this is not in openafs cvs but could be added if
someone wants to do the work.

From shadow@dementia.org  Tue Jun 26 04:07:15 2007
From: shadow@dementia.org (Derrick J Brashear)
Date: Mon, 25 Jun 2007 23:07:15 -0400 (EDT)
Subject: [OpenAFS-devel] IP address change monitoring?
In-Reply-To: <20070626022218.GA23605@citi.umich.edu>
References: <Pine.GSO.4.61-042.0706181644360.11595@johnstown.andrew.cmu.edu>
 <Pine.GSO.4.61-042.0706231057460.11595@johnstown.andrew.cmu.edu>
 <D12480C436B109232CE5D2D6@sirius.fac.cs.cmu.edu> <20070626022218.GA23605@citi.umich.edu>
Message-ID: <Pine.GSO.4.61-042.0706252306240.11595@johnstown.andrew.cmu.edu>

On Mon, 25 Jun 2007, Jim Rees wrote:

> I discard all my callbacks and rx connections on suspend.  That works 99% of
> the time, because at least on my laptop, address changes tend to happen when
> I suspend in one location then resume in another.

It's on my list of things to implement for the MacOS client; I know how, I 
just need the time.

> The code I use to do this is not in openafs cvs but could be added if
> someone wants to do the work.

Send it. I'll look when I have time.



From daleg@umbc.edu  Tue Jun 26 05:00:36 2007
From: daleg@umbc.edu (Dale Ghent)
Date: Tue, 26 Jun 2007 00:00:36 -0400
Subject: [OpenAFS-devel] Re: [OpenAFS] 1.5.19 build fails on SunOS 5.11 snv62 SPARC
In-Reply-To: <005301c7b78f$278e1de0$2d01a8c0@IBMT42>
References: <25350446.249531179267215380.JavaMail.root@franklin.tjhsst.edu> <C955206C-9853-43CF-BD0A-9742023C005A@umbc.edu> <002b01c7a236$d2d7cc00$2d01a8c0@IBMT42> <Pine.GSO.4.61-042.0706231058450.11595@johnstown.andrew.cmu.edu> <005301c7b78f$278e1de0$2d01a8c0@IBMT42>
Message-ID: <E18D3599-C5B7-4C40-9FF9-B8A4A828C026@umbc.edu>

On Jun 25, 2007, at 9:13 PM, William Yang wrote:

> In Solaris 10, I can say definitively that it is used in kernel  
> 120011-06 (used in update 4 beta, projected release for 7/07 I  
> believe), but I don't know if there are any earlier versions that  
> use it.  I don't know about Solaris Express versions, but I would  
> guess from the subject line that starting with at least snv_62,  
> netstack was used.

netstack came about as a result of the integration of IP Instances[1]  
into the Nevada code base. IP Instances as a feature was deemed  
worthy by Sun to back port to Solaris 10, and thus it is ending up as  
one of the new features that Solaris updates add (Update 4 in this case)

Because IP Instances was putback to Nevada, it'll thus be in any  
Solaris Express released since that point... so Yes, it's in Solaris  
Express (SX, SXCE, SXDE) and will be in Solaris 10u4 as you pointed  
out... which is a good heads-up to have in our (OpenAFS's) case  
because my repeated begging to my Sun sales team to get me on the  
update beta programs seems to not go far.

[1] http://www.opensolaris.org/os/project/crossbow/Docs/si-design.pdf

/dale

--
Dale Ghent
Specialist, Storage and UNIX Systems
UMBC - Office of Information Technology
ECS 201 - x51705




From shadow@dementia.org  Tue Jun 26 05:04:12 2007
From: shadow@dementia.org (Derrick J Brashear)
Date: Tue, 26 Jun 2007 00:04:12 -0400 (EDT)
Subject: [OpenAFS-devel] Re: [OpenAFS] 1.5.19 build fails on SunOS 5.11
 snv62 SPARC
In-Reply-To: <E18D3599-C5B7-4C40-9FF9-B8A4A828C026@umbc.edu>
References: <25350446.249531179267215380.JavaMail.root@franklin.tjhsst.edu>
 <C955206C-9853-43CF-BD0A-9742023C005A@umbc.edu> <002b01c7a236$d2d7cc00$2d01a8c0@IBMT42>
 <Pine.GSO.4.61-042.0706231058450.11595@johnstown.andrew.cmu.edu>
 <005301c7b78f$278e1de0$2d01a8c0@IBMT42> <E18D3599-C5B7-4C40-9FF9-B8A4A828C026@umbc.edu>
Message-ID: <Pine.GSO.4.61-042.0706260003400.11595@johnstown.andrew.cmu.edu>

On Tue, 26 Jun 2007, Dale Ghent wrote:

> On Jun 25, 2007, at 9:13 PM, William Yang wrote:
>
>> In Solaris 10, I can say definitively that it is used in kernel 120011-06 
>> (used in update 4 beta, projected release for 7/07 I believe), but I don't 
>> know if there are any earlier versions that use it.  I don't know about 
>> Solaris Express versions, but I would guess from the subject line that 
>> starting with at least snv_62, netstack was used.
>
> netstack came about as a result of the integration of IP Instances[1] into 
> the Nevada code base. IP Instances as a feature was deemed worthy by Sun to 
> back port to Solaris 10, and thus it is ending up as one of the new features 
> that Solaris updates add (Update 4 in this case)
>
> Because IP Instances was putback to Nevada, it'll thus be in any Solaris 
> Express released since that point... so Yes, it's in Solaris Express (SX, 
> SXCE, SXDE) and will be in Solaris 10u4 as you pointed out... which is a good 
> heads-up to have in our (OpenAFS's) case because my repeated begging to my 
> Sun sales team to get me on the update beta programs seems to not go far.

sorry, what i'm getting at is, how do we have a universal (pre and post 
whatever build) kernel module?

From daleg@umbc.edu  Tue Jun 26 05:14:00 2007
From: daleg@umbc.edu (Dale Ghent)
Date: Tue, 26 Jun 2007 00:14:00 -0400
Subject: [OpenAFS-devel] Re: [OpenAFS] 1.5.19 build fails on SunOS 5.11 snv62 SPARC
In-Reply-To: <Pine.GSO.4.61-042.0706260003400.11595@johnstown.andrew.cmu.edu>
References: <25350446.249531179267215380.JavaMail.root@franklin.tjhsst.edu> <C955206C-9853-43CF-BD0A-9742023C005A@umbc.edu> <002b01c7a236$d2d7cc00$2d01a8c0@IBMT42> <Pine.GSO.4.61-042.0706231058450.11595@johnstown.andrew.cmu.edu> <005301c7b78f$278e1de0$2d01a8c0@IBMT42> <E18D3599-C5B7-4C40-9FF9-B8A4A828C026@umbc.edu> <Pine.GSO.4.61-042.0706260003400.11595@johnstown.andrew.cmu.edu>
Message-ID: <B37E77B9-F09B-4210-A500-8A5AB3DCC4E9@umbc.edu>

On Jun 26, 2007, at 12:04 AM, Derrick J Brashear wrote:

> sorry, what i'm getting at is, how do we have a universal (pre and  
> post whatever build) kernel module?

I'll have to take a look at this netstack thingy more closely to see  
if there's an existing ABI to access it. I really haven't had the  
time recently to stay up on this stuff due to other things and I lost  
my Nevada/AFS build box. In case that such a thing doesn't exist, I  
fear it's a job that'll fall to autoconf :(

/dale

--
Dale Ghent
Specialist, Storage and UNIX Systems
UMBC - Office of Information Technology
ECS 201 - x51705




From shadow@dementia.org  Tue Jun 26 05:29:11 2007
From: shadow@dementia.org (Derrick J Brashear)
Date: Tue, 26 Jun 2007 00:29:11 -0400 (EDT)
Subject: [OpenAFS-devel] Re: [OpenAFS] 1.5.19 build fails on SunOS 5.11
 snv62 SPARC
In-Reply-To: <B37E77B9-F09B-4210-A500-8A5AB3DCC4E9@umbc.edu>
References: <25350446.249531179267215380.JavaMail.root@franklin.tjhsst.edu>
 <C955206C-9853-43CF-BD0A-9742023C005A@umbc.edu> <002b01c7a236$d2d7cc00$2d01a8c0@IBMT42>
 <Pine.GSO.4.61-042.0706231058450.11595@johnstown.andrew.cmu.edu>
 <005301c7b78f$278e1de0$2d01a8c0@IBMT42> <E18D3599-C5B7-4C40-9FF9-B8A4A828C026@umbc.edu>
 <Pine.GSO.4.61-042.0706260003400.11595@johnstown.andrew.cmu.edu>
 <B37E77B9-F09B-4210-A500-8A5AB3DCC4E9@umbc.edu>
Message-ID: <Pine.GSO.4.61-042.0706260028380.11595@johnstown.andrew.cmu.edu>

On Tue, 26 Jun 2007, Dale Ghent wrote:

> On Jun 26, 2007, at 12:04 AM, Derrick J Brashear wrote:
>
>> sorry, what i'm getting at is, how do we have a universal (pre and post 
>> whatever build) kernel module?
>
> I'll have to take a look at this netstack thingy more closely to see if 
> there's an existing ABI to access it. I really haven't had the time recently 
> to stay up on this stuff due to other things and I lost my Nevada/AFS build 
> box. In case that such a thing doesn't exist, I fear it's a job that'll fall 
> to autoconf :(

that was my fear also, because, well, then we can't ship a (one) module 
and know it'll work.

From jhutz@cmu.edu  Tue Jun 26 16:08:54 2007
From: jhutz@cmu.edu (Jeffrey Hutzelman)
Date: Tue, 26 Jun 2007 11:08:54 -0400 (EDT)
Subject: [OpenAFS-devel] IP address change monitoring?
In-Reply-To: <Pine.GSO.4.61-042.0706252306240.11595@johnstown.andrew.cmu.edu>
Message-ID: <Pine.LNX.4.33L.0706261106530.23251-100000@minbar.fac.cs.cmu.edu>

On Mon, 25 Jun 2007, Derrick J Brashear wrote:

> On Mon, 25 Jun 2007, Jim Rees wrote:
>
> > I discard all my callbacks and rx connections on suspend.  That works 99% of
> > the time, because at least on my laptop, address changes tend to happen when
> > I suspend in one location then resume in another.

That would certainly be an improvement, but we do also need to change the
set of addresses we report to the fileserver.

It occurs to me that even on platforms with no special notification
mechanism, we ought to be able to have a daemon that wakes up once in a
while, scans the set of interfaces, and updates the CM.  Certainly things
like DNS servers do this.


From mancini@math.unifi.it  Tue Jun 26 16:29:50 2007
From: mancini@math.unifi.it (Alberto Mancini)
Date: Tue, 26 Jun 2007 17:29:50 +0200 (CEST)
Subject: [OpenAFS-devel] status of src/tests
In-Reply-To: <6E2F2FBD384498C9BB73BA44@sirius.fac.cs.cmu.edu>
References: <ef99b6f40705311308n7e0b0809qfbddceecf4853e1b@mail.gmail.com>
 <847e389f0706010327m1d93b374tbabe7cc05f32c428@mail.gmail.com>
 <Pine.LNX.4.64.0706011228240.18391@ossigeno.math.unifi.it>
 <6E2F2FBD384498C9BB73BA44@sirius.fac.cs.cmu.edu>
Message-ID: <Pine.LNX.4.64.0706261712390.11358@ossigeno.math.unifi.it>

> Oh, dear.  There's a copy of dumptool in there?  That's probably as 
> out-of-date as the copy of my volume dump utilities, the latest version of 
> which can be found in /afs/grand.central.org/software/dumpscan.

Yes but, where is dumptool if not in the tests directory ?
the path (found in src/tests/README.dumptool)
   /afs/transarc.com/public/afs-contrib/dumptool/
is not valid (at least, the cell  transarc.com is not in the
grand.central.org CellServDB file).


> It is probably the case that dumptool provides functionality not currently 
> available from the dumpscan tools and libraries.  I would be glad to accept 
> patches to correct this situation.

actually, dumpscan in /afs/grand.central.org/software/dumpscan
can be compiled (with some work) but does not recognize my dumps

----------------------------------------------------------------------
afsdump_dirlist: Bad magic number in AFS volume dump Invalid page tag 
(41235) in page 0
*** 1 errors
*** FAILED: Bad magic number in AFS volume dump
----------------------------------------------------------------------
My mistake ?

Sincerely,
 			Alberto Mancini

From jaltman@secure-endpoints.com  Tue Jun 26 17:15:12 2007
From: jaltman@secure-endpoints.com (Jeffrey Altman)
Date: Tue, 26 Jun 2007 12:15:12 -0400
Subject: [OpenAFS-devel] Proposal for new ptserver RPC: pr_WhoAmI
Message-ID: <46813B90.7080507@secure-endpoints.com>

This is a cryptographically signed message in MIME format.

--------------ms040204040207050402070607
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

With the addition of Kerberos referrals support in MIT Kerberos 1.6, the
hack that we have used for determining when aklog should auto-register a
user a a foreign entity in the pt database no longer works.

When a referral is used the client is handed by the Kerberos library a
service ticket of the form "afs/cell@" instead of "afs/cell@REALM".
This is because when referrals are used the client does not know the
realm.  If the library stored the service ticket as "afs/cell@REALM"
then when the application wanted to re-use it, it would not be found in
the cache.  While it might be nice for the Kerberos ticket data
structure to contain both the requested and obtained service principal
names, this would be a backward incompatible change which we are
unlikely to see implemented.

As a result, the client in unable to determine whether the token it has
obtained represents a local or foreign user.  The only way this can be
determined is by asking a server to report back who the user has
authenticated as.

My proposal is to add a new RPC:

struct prwhoami {
  afs_int32 flags;
  afs_int32 id;
  char name[PR_MAXNAMELEN];
}
typedef struct prwhoami prwhoami;

WhoAmI(
  OUT prwhoami *who
) = NNN;

The server will return to the caller the name that would be looked up in
the database plus either the actual assigned AFSID or ANONYMOUSID.

This new RPC is intentionally old-style.  In much the same way that we
will need to add pr_CreateUserEx() in order to support multiple name
types, we will need to add pr_WhoAmIEx() to support multiple name types.

The pr_WhoAmI RPC would be used to solve the pts registration problem as
follows:

* aklog would obtain a token
* make a call to pr_WhoAmI to obtain the name and id from the ptserver
* if the id is ANONYMOUSID then it would proceed to call pr_CreateUser
with the name provided by the server.

Comments?

This is OpenAFS RT ticket 64147
http://rt.central.org/rt/Ticket/Display.html?id=64147

Jeffrey Altman
Secure Endpoints Inc.

--------------ms040204040207050402070607
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC
AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX
DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy
aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c
bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF
PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184
9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d
1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG
A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1
AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk
0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr
5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow
czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl
ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv
aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU
3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl
DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL
AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM
94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV
lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB
gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t
ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3
UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw
gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp
bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w
MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU
aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg
RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV
+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr
hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/
p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8
MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls
Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh
YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/
TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc
OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID
YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA2MjYxNjE1MTJaMCMGCSqGSIb3DQEJBDEWBBQV7n7Y
4n20cbR0EUbp27Xyd17ZYDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB
BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg
KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg
Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ
KoZIhvcNAQEBBQAEggEAm6m36FXCh3sDSoIerp/1au1Jd2aTL+h49QGKI8KXBkDK+XGH2SQu
g1GUdvEKigx0OfCDn/o1gdDnQi0gS8NBYqDedfpQN4cyOrr0Py4rs/0bjGG2iehYNapS4lAC
1KaBT5SQ58wUOBJRV/tat/DYsBlgj1JkHdX3uTHbsjmosf/YsJhz4k6ICi0a3lArfImy7fyh
zSrBwaCyylwKBbtYZOb4Acn/JyXPzm6u5ddcT1H568Wik/YMMSMlaPhnGUwgiPGSI5+yZXr4
3Xn/qDExD++JtUzp1DFBc6NCyXnoiq9RHHwSiGE6FyrhmyaSHpN+NN4oY5oTAP05hJSfwIYe
yQAAAAAAAA==
--------------ms040204040207050402070607--


From jhutz@cmu.edu  Tue Jun 26 18:08:50 2007
From: jhutz@cmu.edu (Jeffrey Hutzelman)
Date: Tue, 26 Jun 2007 13:08:50 -0400
Subject: [OpenAFS-devel] status of src/tests
In-Reply-To: <Pine.LNX.4.64.0706261712390.11358@ossigeno.math.unifi.it>
References: <ef99b6f40705311308n7e0b0809qfbddceecf4853e1b@mail.gmail.com>
 <847e389f0706010327m1d93b374tbabe7cc05f32c428@mail.gmail.com>
 <Pine.LNX.4.64.0706011228240.18391@ossigeno.math.unifi.it>
 <6E2F2FBD384498C9BB73BA44@sirius.fac.cs.cmu.edu>
 <Pine.LNX.4.64.0706261712390.11358@ossigeno.math.unifi.it>
Message-ID: <856E15683EE8E3D5C07432D9@sirius.fac.cs.cmu.edu>


On Tuesday, June 26, 2007 05:29:50 PM +0200 Alberto Mancini 
<mancini@math.unifi.it> wrote:

>> Oh, dear.  There's a copy of dumptool in there?  That's probably as
>> out-of-date as the copy of my volume dump utilities, the latest version
>> of  which can be found in /afs/grand.central.org/software/dumpscan.
>
> Yes but, where is dumptool if not in the tests directory ?
> the path (found in src/tests/README.dumptool)
>    /afs/transarc.com/public/afs-contrib/dumptool/
> is not valid (at least, the cell  transarc.com is not in the
> grand.central.org CellServDB file).
>
>
>> It is probably the case that dumptool provides functionality not
>> currently  available from the dumpscan tools and libraries.  I would be
>> glad to accept  patches to correct this situation.
>
> actually, dumpscan in /afs/grand.central.org/software/dumpscan
> can be compiled (with some work)

I'll be happy to accept patches to improve the build system.


> but does not recognize my dumps
>
> ----------------------------------------------------------------------
> afsdump_dirlist: Bad magic number in AFS volume dump Invalid page tag
> (41235) in page 0
> *** 1 errors
> *** FAILED: Bad magic number in AFS volume dump
> ----------------------------------------------------------------------
> My mistake ?

afsdump_dirlist operates on a file containing a directory as it appears on 
the wire (and, coincidentally, on the fileserver and in the cache).  It 
does not operate on whole dumps.  To get a listing of all the directories 
in a volume dump, try something like

afsdump_scan -Pvd <file>

-- Jeff

From jhutz@cmu.edu  Tue Jun 26 18:35:52 2007
From: jhutz@cmu.edu (Jeffrey Hutzelman)
Date: Tue, 26 Jun 2007 13:35:52 -0400
Subject: [OpenAFS-devel] Proposal for new ptserver RPC: pr_WhoAmI
In-Reply-To: <46813B90.7080507@secure-endpoints.com>
References: <46813B90.7080507@secure-endpoints.com>
Message-ID: <AA8DEE1DC86FFFAD0898ED69@sirius.fac.cs.cmu.edu>

Discussion of protocol issues should go to afs3-standardization.
I have copied this message there.


On Tuesday, June 26, 2007 12:15:12 PM -0400 Jeffrey Altman 
<jaltman@secure-endpoints.com> wrote:

> My proposal is to add a new RPC:

Yeah; that sounds reasonable.



> struct prwhoami {
>   afs_int32 flags;
>   afs_int32 id;
>   char name[PR_MAXNAMELEN];
> }
> typedef struct prwhoami prwhoami;
>
> WhoAmI(
>   OUT prwhoami *who
> ) = NNN;
>
> The server will return to the caller the name that would be looked up in
> the database plus either the actual assigned AFSID or ANONYMOUSID.
>
> This new RPC is intentionally old-style.  In much the same way that we
> will need to add pr_CreateUserEx() in order to support multiple name
> types, we will need to add pr_WhoAmIEx() to support multiple name types.

I don't think so.  In the new world, PTS entries don't have multiple types 
of names; there is still just the one name.  What they have is one or more 
authentication names, possibly of different types, possibly of the same 
type, which map to that entry.




> The pr_WhoAmI RPC would be used to solve the pts registration problem as
> follows:
>
> * aklog would obtain a token
> * make a call to pr_WhoAmI to obtain the name and id from the ptserver
> * if the id is ANONYMOUSID then it would proceed to call pr_CreateUser
> with the name provided by the server.
>
> Comments?

Please make use of the flags to indicate whether the user is registered 
and/or should try self-registration, rather than inferring that from the 
returned ID.  I say this for a couple of reasons...

First, there may not be any name the client can self-register.  The 
ptserver maps authenticated principal names to pts entries by first looking 
for explicit mappings, then applying one or more transformations to turn 
the principal name into a PTS entry name, which it then looks up(*). 
Clients can self-register when...

- there is no explcit mapping (else it would be registered already)
- one of the transformations applies, but...
- produces a name which is not currently in the database

In that case, the ptserver can tell you what name to register.  But if no 
transformation applies, then there is no name you can self-register, and so 
there is no name for the ptserver to return in a whoami response.  In this 
situation, the ptserver should return ANONYMOUSID, no name, and indicate 
(via flags) that the client is not registered and cannot self-register.

Second, it is possible that the client can self-register, but the ptserver 
does not know in advance what name the client may use.  For example, it may 
be that a client is allowed to register using an enterprise-wide name 
assigned to him, where there is a directory that allows mapping such a name 
to all the principals that belong to it, but not the reverse.  A bit 
far-fetched, perhaps, but possible.  In this case, the ptserver should 
again return ANONYMOUSID and no name, and should indicate that the client 
is not registered but may self-register (if it can figure out the right 
name).

Thirdly, it is possible that the ptserver may grant otherwise-unregistered 
principals access according to some shared ID identified by a pattern.  In 
this case, the returned viceid should be the shared one, but flags should 
still indicate that the client is unregistered and may self-register.


In fact, I'm beginning to think the result should separately indicate:
- the viceID currently used for that client (possibly ANONYMOUSID)
- the name currently used for that client (possibly system:anyuser)
- the name the client may self-register with (possibly empty)
- whether the client is registered
- whether the client may self-register


Comments?

(*) Note that in the current ptserver, there is no way to set, represent,
    or store explicit mappings, so all lookups are done by transformation,
    and there is one fixed transformation for each auth name type (krb4
    and krb5).  It's actually slightly messier than that, since krb5 names
    are sometimes transformed to krb4 names outside the ptserver, but that
    isn't relevant here.  The important thing is that today's behavior is
    consistent with the new model plus some constraints.


> This is OpenAFS RT ticket 64147
> http://rt.central.org/rt/Ticket/Display.html?id=64147
>
> Jeffrey Altman
> Secure Endpoints Inc.



From jaltman@secure-endpoints.com  Tue Jun 26 19:52:22 2007
From: jaltman@secure-endpoints.com (Jeffrey Altman)
Date: Tue, 26 Jun 2007 14:52:22 -0400
Subject: [AFS3-std] Re: [OpenAFS-devel] Proposal for new ptserver RPC:
 pr_WhoAmI
In-Reply-To: <AA8DEE1DC86FFFAD0898ED69@sirius.fac.cs.cmu.edu>
References: <46813B90.7080507@secure-endpoints.com> <AA8DEE1DC86FFFAD0898ED69@sirius.fac.cs.cmu.edu>
Message-ID: <46816066.7060002@secure-endpoints.com>

This is a cryptographically signed message in MIME format.

--------------ms080206000505020907050704
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Jeffrey Hutzelman wrote:
> Discussion of protocol issues should go to afs3-standardization.
> I have copied this message there.
Agreed. Both lists is fine for now.
>
>
> Please make use of the flags to indicate whether the user is
> registered and/or should try self-registration, rather than inferring
> that from the returned ID.  I say this for a couple of reasons...
>
> [pruned]
>
> In fact, I'm beginning to think the result should separately indicate:
> - the viceID currently used for that client (possibly ANONYMOUSID)
> - the name currently used for that client (possibly system:anyuser)
> - the name the client may self-register with (possibly empty)
> - whether the client is registered
> - whether the client may self-register
>
>
> Comments?
We can have two flags:

    PR_WAI_IS_REGISTERED   0x0001
    PR_WAI_MAY_REGISTER   0x0002

PR_WAI_IS_REGISTERED is set when the viceID specified is assigned to
that entity and not to a group

PR_WAI_MAY_REGISTER is set when the ptserver determines that there is a
name that could be registered but which doesn't exist in the database
AND if such a request was received it could in fact be processed.  There
is no point encouraging the client to attempt to register
user@foo.bar.com if the configuration of the server would not permit it.

I think that adding the second name field is a good idea.

Jeffrey Altman
Secure Endpoints Inc.


--------------ms080206000505020907050704
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC
AxcwggKAoAMCAQICEALr5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oX
DTA4MDUzMDA2MTM1N1owczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy
aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCsoz/0+s4Cn65n/3bU3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5c
bhSnJPmb2OOb1frx64dlDgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCF
PKhZfcrGAXoVCrFBadnLAokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu184
9Cj6I4nY5bt+r94kyDHM94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d
1ZXepBXyexQbwOYvftpVlMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcG
A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1
AZAvCv+ZMMRRKWCsrG5tItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk
0oiBQcQD8A+UHwrcmaj3UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAxcwggKAoAMCAQICEALr
5BE3U6n+HWCoLbyhohMwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUzMTA2MTM1N1oXDTA4MDUzMDA2MTM1N1ow
czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl
ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv
aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoz/0+s4Cn65n/3bU
3shXw4y5u1uEMEsBOiqNU0PfIKGYQe95b1FKNbNAkctSdQT6GF5cbhSnJPmb2OOb1frx64dl
DgskaG561xa8XPA1aP8Cc+33dgsSLIxGEh97lyUYHEfWBC03KMCFPKhZfcrGAXoVCrFBadnL
AokQbUTFahVg/qQx2IT3wSj1sCIfV5UDuXcEKHCvRtEZIsSzu1849Cj6I4nY5bt+r94kyDHM
94MHYBJi+6tWLFRy2gkIB3HEPmxAiQrKljNpH9bOffiBLIAgmJ6d1ZXepBXyexQbwOYvftpV
lMEFHHQmdiwH3tj69hE78XvM5X9J+SbjbuNpAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB
gQB8FShDN2Ig034Y5eyadiFDEtOvsIJ3Z2xV9aTL4u8xMlz1gZR1AZAvCv+ZMMRRKWCsrG5t
ItV8DFPSfWAGMpInmMarA4f76JRLQEUhkRUg8GpkJM5ryk5EDakk0oiBQcQD8A+UHwrcmaj3
UWxQ9zCjDgU+1mY9nEQxZZyp4eeUfzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw
gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp
bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w
MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU
aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg
RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV
+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr
hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/
p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8
MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls
Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh
YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/
TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc
OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID
YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
AuvkETdTqf4dYKgtvKGiEzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA2MjYxODUyMjJaMCMGCSqGSIb3DQEJBDEWBBTu7TtE
jedI+VYu9ZAq2JjAD2K3azBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB
BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg
KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg
Q0ECEALr5BE3U6n+HWCoLbyhohMwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEALr5BE3U6n+HWCoLbyhohMwDQYJ
KoZIhvcNAQEBBQAEggEAMlKEawwqUvr1XpH6c8Bv4B4el/s33hM8vIuhE05GxAYrbxuRIZ+v
4CB5ckyE1Bi068qejQK4GTsAv3u6lcs0zfFS8cpSX9hBiwW1bZr6hOUYJ7j6NayNy0m18TUt
6A6Uk+EHG6eL2hI7mIl0fEV5lnojnpTN0awdCqZlB2hw45C50Fj5FokgDHc3jeR26nV2nv0Y
zW/jWSkLhOKEA9M1YyurCtT8LksBLigmBqWrg88BWAn8qOgUlA4Sfn3goKl1LlbF5COlpvbE
8L56KZYS8cQFdYQ4ISsRp5vMpO1V2cqaw/ucx+1xkQz4bTRxrF/boxR6GgGYJ6tl9U8z07PV
WAAAAAAAAA==
--------------ms080206000505020907050704--


From jhutz@cmu.edu  Tue Jun 26 20:12:16 2007
From: jhutz@cmu.edu (Jeffrey Hutzelman)
Date: Tue, 26 Jun 2007 15:12:16 -0400
Subject: [AFS3-std] Re: [OpenAFS-devel] Proposal for new ptserver RPC:
 pr_WhoAmI
In-Reply-To: <46816066.7060002@secure-endpoints.com>
References: <46813B90.7080507@secure-endpoints.com>
 <AA8DEE1DC86FFFAD0898ED69@sirius.fac.cs.cmu.edu>
 <46816066.7060002@secure-endpoints.com>
Message-ID: <B28CB5E7879089401193F99E@sirius.fac.cs.cmu.edu>


On Tuesday, June 26, 2007 02:52:22 PM -0400 Jeffrey Altman 
<jaltman@secure-endpoints.com> wrote:

> Jeffrey Hutzelman wrote:
>> Discussion of protocol issues should go to afs3-standardization.
>> I have copied this message there.
> Agreed. Both lists is fine for now.
>>
>>
>> Please make use of the flags to indicate whether the user is
>> registered and/or should try self-registration, rather than inferring
>> that from the returned ID.  I say this for a couple of reasons...
>>
>> [pruned]
>>
>> In fact, I'm beginning to think the result should separately indicate:
>> - the viceID currently used for that client (possibly ANONYMOUSID)
>> - the name currently used for that client (possibly system:anyuser)
>> - the name the client may self-register with (possibly empty)
>> - whether the client is registered
>> - whether the client may self-register
>>
>>
>> Comments?
> We can have two flags:
>
>     PR_WAI_IS_REGISTERED   0x0001
>     PR_WAI_MAY_REGISTER   0x0002
>
> PR_WAI_IS_REGISTERED is set when the viceID specified is assigned to
> that entity and not to a group
>
> PR_WAI_MAY_REGISTER is set when the ptserver determines that there is a
> name that could be registered but which doesn't exist in the database
> AND if such a request was received it could in fact be processed.  There
> is no point encouraging the client to attempt to register
> user@foo.bar.com if the configuration of the server would not permit it.
>
> I think that adding the second name field is a good idea.

OK, so we return an "effective" ID and name, and a flag that indicates 
these belong specificaly to the client.

And then we have a "potential" name, and a flag that indicates that 
registration of that name by this client will probably succeed.

Yes?



From jaltman@secure-endpoints.com  Tue Jun 26 20:26:10 2007
From: jaltman@secure-endpoints.com (Jeffrey Altman)
Date: Tue, 26 Jun 2007 15:26:10 -0400
Subject: [AFS3-std] Re: [OpenAFS-devel] Proposal for new ptserver RPC:
 pr_WhoAmI
In-Reply-To: <B28CB5E7879089401193F99E@sirius.fac.cs.cmu.edu>
References: <46813B90.7080507@secure-endpoints.com> <AA8DEE1DC86FFFAD0898ED69@sirius.fac.cs.cmu.edu> <46816066.7060002@secure-endpoints.com> <B28CB5E7879089401193F99E@sirius.fac.cs.cmu.edu>
Message-ID: <46816852.2050905@secure-endpoints.com>

Jeffrey Hutzelman wrote:
> 
> 
> On Tuesday, June 26, 2007 02:52:22 PM -0400 Jeffrey Altman
> <jaltman@secure-endpoints.com> wrote:
> 
>> Jeffrey Hutzelman wrote:
>>> Discussion of protocol issues should go to afs3-standardization.
>>> I have copied this message there.
>> Agreed. Both lists is fine for now.
>>>
>>>
>>> Please make use of the flags to indicate whether the user is
>>> registered and/or should try self-registration, rather than inferring
>>> that from the returned ID.  I say this for a couple of reasons...
>>>
>>> [pruned]
>>>
>>> In fact, I'm beginning to think the result should separately indicate:
>>> - the viceID currently used for that client (possibly ANONYMOUSID)
>>> - the name currently used for that client (possibly system:anyuser)
>>> - the name the client may self-register with (possibly empty)
>>> - whether the client is registered
>>> - whether the client may self-register
>>>
>>>
>>> Comments?
>> We can have two flags:
>>
>>     PR_WAI_IS_REGISTERED   0x0001
>>     PR_WAI_MAY_REGISTER   0x0002
>>
>> PR_WAI_IS_REGISTERED is set when the viceID specified is assigned to
>> that entity and not to a group
>>
>> PR_WAI_MAY_REGISTER is set when the ptserver determines that there is a
>> name that could be registered but which doesn't exist in the database
>> AND if such a request was received it could in fact be processed.  There
>> is no point encouraging the client to attempt to register
>> user@foo.bar.com if the configuration of the server would not permit it.
>>
>> I think that adding the second name field is a good idea.
> 
> OK, so we return an "effective" ID and name, and a flag that indicates
> these belong specificaly to the client.
> 
> And then we have a "potential" name, and a flag that indicates that
> registration of that name by this client will probably succeed.
> 
> Yes?

Yes.

Jeffrey Altman
Secure Endpoints Inc.

From daleg@umbc.edu  Wed Jun 27 17:17:00 2007
From: daleg@umbc.edu (Dale Ghent)
Date: Wed, 27 Jun 2007 12:17:00 -0400
Subject: [OpenAFS-devel] Re: [OpenAFS] 1.5.19 build fails on SunOS 5.11 snv62 SPARC
In-Reply-To: <Pine.GSO.4.61-042.0706260028380.11595@johnstown.andrew.cmu.edu>
References: <25350446.249531179267215380.JavaMail.root@franklin.tjhsst.edu> <C955206C-9853-43CF-BD0A-9742023C005A@umbc.edu> <002b01c7a236$d2d7cc00$2d01a8c0@IBMT42> <Pine.GSO.4.61-042.0706231058450.11595@johnstown.andrew.cmu.edu> <005301c7b78f$278e1de0$2d01a8c0@IBMT42> <E18D3599-C5B7-4C40-9FF9-B8A4A828C026@umbc.edu> <Pine.GSO.4.61-042.0706260003400.11595@johnstown.andrew.cmu.edu> <B37E77B9-F09B-4210-A500-8A5AB3DCC4E9@umbc.edu> <Pine.GSO.4.61-042.0706260028380.11595@johnstown.andrew.cmu.edu>
Message-ID: <892DE32B-50C0-494E-A948-5B81F6EA6A60@umbc.edu>

On Jun 26, 2007, at 12:29 AM, Derrick J Brashear wrote:

> On Tue, 26 Jun 2007, Dale Ghent wrote:
>>
>> I'll have to take a look at this netstack thingy more closely to  
>> see if there's an existing ABI to access it. I really haven't had  
>> the time recently to stay up on this stuff due to other things and  
>> I lost my Nevada/AFS build box. In case that such a thing doesn't  
>> exist, I fear it's a job that'll fall to autoconf :(
>
> that was my fear also, because, well, then we can't ship a (one)  
> module and know it'll work.

I took a closer look at this today. It seems that the only reasonable  
way around this is to not do the interface probing/sorting in the  
kernel module and instead do it in userspace via ADVISEADDR from  
afsd. We are, after all, touching private stuff in the kernel to get  
the interfaces.

/dale

--
Dale Ghent
Specialist, UNIX and Storage Systems
UMBC - Office of Information Technology
ENG 201 - 410-443-1705




From shadow@dementia.org  Wed Jun 27 17:20:17 2007
From: shadow@dementia.org (Derrick J Brashear)
Date: Wed, 27 Jun 2007 12:20:17 -0400 (EDT)
Subject: [OpenAFS-devel] Re: [OpenAFS] 1.5.19 build fails on SunOS 5.11
 snv62 SPARC
In-Reply-To: <892DE32B-50C0-494E-A948-5B81F6EA6A60@umbc.edu>
References: <25350446.249531179267215380.JavaMail.root@franklin.tjhsst.edu>
 <C955206C-9853-43CF-BD0A-9742023C005A@umbc.edu> <002b01c7a236$d2d7cc00$2d01a8c0@IBMT42>
 <Pine.GSO.4.61-042.0706231058450.11595@johnstown.andrew.cmu.edu>
 <005301c7b78f$278e1de0$2d01a8c0@IBMT42> <E18D3599-C5B7-4C40-9FF9-B8A4A828C026@umbc.edu>
 <Pine.GSO.4.61-042.0706260003400.11595@johnstown.andrew.cmu.edu>
 <B37E77B9-F09B-4210-A500-8A5AB3DCC4E9@umbc.edu>
 <Pine.GSO.4.61-042.0706260028380.11595@johnstown.andrew.cmu.edu>
 <892DE32B-50C0-494E-A948-5B81F6EA6A60@umbc.edu>
Message-ID: <Pine.GSO.4.61-042.0706271219280.11595@johnstown.andrew.cmu.edu>

On Wed, 27 Jun 2007, Dale Ghent wrote:

> I took a closer look at this today. It seems that the only reasonable way 
> around this is to not do the interface probing/sorting in the kernel module 
> and instead do it in userspace via ADVISEADDR from afsd. We are, after all, 
> touching private stuff in the kernel to get the interfaces.

Well, that's not horrible.

We do it that way on MacOS... is there any way to get notification of 
address changes from the kernel on Solaris, so we can update the 
interfaces real-time there like we do on MacOS?


From wyang@tjhsst.edu  Tue Jun 26 02:13:06 2007
From: wyang@tjhsst.edu (William Yang)
Date: Mon, 25 Jun 2007 21:13:06 -0400
Subject: [OpenAFS-devel] Re: [OpenAFS] 1.5.19 build fails on SunOS 5.11
 snv62 SPARC
References: <25350446.249531179267215380.JavaMail.root@franklin.tjhsst.edu>
 <C955206C-9853-43CF-BD0A-9742023C005A@umbc.edu>
 <002b01c7a236$d2d7cc00$2d01a8c0@IBMT42>
 <Pine.GSO.4.61-042.0706231058450.11595@johnstown.andrew.cmu.edu>
Message-ID: <005301c7b78f$278e1de0$2d01a8c0@IBMT42>

This is a multi-part message in MIME format.

------=_NextPart_000_0050_01C7B76D.9FF48930
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In Solaris 10, I can say definitively that it is used in kernel =
120011-06 (used in update 4 beta, projected release for 7/07 I believe), =
but I don't know if there are any earlier versions that use it.  I don't =
know about Solaris Express versions, but I would guess from the subject =
line that starting with at least snv_62, netstack was used.

Hope this helps.

William Yang
TJHSST Student Systems Administrator
wyang@tjhsst.edu
  ----- Original Message -----=20
  From: Derrick J Brashear=20
  To: William Yang=20
  Cc: Dale Ghent ; OpenAFS Devel=20
  Sent: Saturday, June 23, 2007 11:00 AM
  Subject: Re: [OpenAFS-devel] Re: [OpenAFS] 1.5.19 build fails on SunOS =
5.11 snv62 SPARC


  On Tue, 29 May 2007, William Yang wrote:

  > Then the best idea I can come up with right now is just to add a=20
  > configure script check that determines what kernel version is =
running=20
  > and to set an independent define for those particular code blocks.

  Well, it's worse than that. If we use netstack stuff anywhere we need =
to=20
  version the kernel module for pre- and post- netstack, I assume. So...

  What version(s) is netstack in?


------=_NextPart_000_0050_01C7B76D.9FF48930
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3059" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>In Solaris 10, I can say definitively =
that it is=20
used in kernel 120011-06 (used in update 4 beta, projected release for =
7/07 I=20
believe), but I don't know if there are any earlier versions that use =
it.&nbsp;=20
I don't know about Solaris Express versions, but I would guess from the =
subject=20
line that starting with at least snv_62, netstack was used.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Hope this helps.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>William Yang</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>TJHSST Student Systems =
Administrator</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"mailto:wyang@tjhsst.edu">wyang@tjhsst.edu</A></FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dshadow@dementia.org =
href=3D"mailto:shadow@dementia.org">Derrick J=20
  Brashear</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A title=3Dwyang@tjhsst.edu =

  href=3D"mailto:wyang@tjhsst.edu">William Yang</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A title=3Ddaleg@umbc.edu=20
  href=3D"mailto:daleg@umbc.edu">Dale Ghent</A> ; <A=20
  title=3Dopenafs-devel@openafs.org=20
  href=3D"mailto:openafs-devel@openafs.org">OpenAFS Devel</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Saturday, June 23, 2007 =
11:00=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: [OpenAFS-devel] =
Re:=20
  [OpenAFS] 1.5.19 build fails on SunOS 5.11 snv62 SPARC</DIV>
  <DIV><BR></DIV>On Tue, 29 May 2007, William Yang wrote:<BR><BR>&gt; =
Then the=20
  best idea I can come up with right now is just to add a <BR>&gt; =
configure=20
  script check that determines what kernel version is running <BR>&gt; =
and to=20
  set an independent define for those particular code =
blocks.<BR><BR>Well, it's=20
  worse than that. If we use netstack stuff anywhere we need to =
<BR>version the=20
  kernel module for pre- and post- netstack, I assume. So...<BR><BR>What =

  version(s) is netstack in?<BR><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0050_01C7B76D.9FF48930--


From mfedyk@mikefedyk.com  Sat Jun 30 00:00:12 2007
From: mfedyk@mikefedyk.com (Mike Fedyk)
Date: Fri, 29 Jun 2007 16:00:12 -0700
Subject: openafs-utils (was: [OpenAFS-devel] status of src/tests)
In-Reply-To: <6E2F2FBD384498C9BB73BA44@sirius.fac.cs.cmu.edu>
References: <ef99b6f40705311308n7e0b0809qfbddceecf4853e1b@mail.gmail.com> <847e389f0706010327m1d93b374tbabe7cc05f32c428@mail.gmail.com> <Pine.LNX.4.64.0706011228240.18391@ossigeno.math.unifi.it> <6E2F2FBD384498C9BB73BA44@sirius.fac.cs.cmu.edu>
Message-ID: <46858EFC.4050607@mikefedyk.com>

Jeffrey Hutzelman wrote:
> I don't think either of those tools, or various others, really belong in 
> the OpenAFS distribution.  OpenAFS should concentrate on being a 
> filesystem, not on incorporating into its distribution every tool 
> someone might want to use with it.

Then where should the afs-utils package be kept?  Having the tools kept 
in one place under source control with a bug tracker can only be good.

That said, in what circumstances are these tools useful?

From cclausen@acm.org  Sat Jun 30 00:18:04 2007
From: cclausen@acm.org (Christopher D. Clausen)
Date: Fri, 29 Jun 2007 18:18:04 -0500
Subject: openafs-utils (was: [OpenAFS-devel] status of src/tests)
References: <ef99b6f40705311308n7e0b0809qfbddceecf4853e1b@mail.gmail.com> <847e389f0706010327m1d93b374tbabe7cc05f32c428@mail.gmail.com> <Pine.LNX.4.64.0706011228240.18391@ossigeno.math.unifi.it> <6E2F2FBD384498C9BB73BA44@sirius.fac.cs.cmu.edu> <46858EFC.4050607@mikefedyk.com>
Message-ID: <6198F150861246659C77B1D940FF89BF@CDCHOME>

Mike Fedyk <mfedyk@mikefedyk.com> wrote:
> Jeffrey Hutzelman wrote:
>> I don't think either of those tools, or various others, really
>> belong in the OpenAFS distribution.  OpenAFS should concentrate on
>> being a filesystem, not on incorporating into its distribution every
>> tool someone might want to use with it.
>
> Then where should the afs-utils package be kept?

Hopefully in some "openafs-contrib" folder in some location in AFS.  I'd 
offer space in one of my cells, but current network policies prevent me 
from doing that.

> Having the tools
> kept in one place under source control with a bug tracker can only be
> good.

Actually, no, its not.  People will expect support from OpenAFS for it 
if they such things are included with the normal openafs source 
distribution.  This could potentially be bad for the OpenAFS project 
itself as well as companies that offer OpenAFS support.  I certainly 
wouldn't want to have some random utility thrown into source control and 
then a client saying "its in openafs, we need it working in our 
environment."

<<CDC