Re: [OpenAFS] AFS version of du

[Brandon S. Allbery KF8NH]

On May 3, 2010, at 11:38 , Steve Simmons wrote:

On May 1, 2010, at 1:35 AM, Brandon S. Allbery KF8NH wrote:

On Apr 30, 2010, at 14:32 , Richard Brittain wrote:
This solves my immediate need, and I'll probably use your mount  
point database too, but begs the question of why perl's
File::Find module works fine, while 'find' breaks.  Underneath  
they are presumably making very similar system calls.


. . . .  File::Find has gone through a lot of development aimed at  
reducing its impact on the system, whereas in my experience the GNU  
folks tend to prefer the throw-more-resources-at-it method.


The findutils developers seem to be an exception to this. In my  
correspondence with them they were pretty firm about not adding  
overhead. Their goal was that any features added that were specific  
to afs, cifs, etc should not add overhead to systems that did not  
have that filesystem type. I can't speak to how well they succeeded,  
but that was their goal.



The specific problem is simply how it walks the directory tree.   
File::Find has historically needed to be especially parsimonious of  
file/directory descriptors for maximum portability (who else here  
remembers when NFILE was 20?), which alters the way it traverses the  
filesystem in ways that may well reduce kernel-level contention and  
resources.  I think the other find variants all assume lots of per- 
process file descriptors and hold lots of directories open as they go  
(I may be wrong, though).


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
Description: This is a digitally signed message part

Re: [OpenAFS] Re: IBM AFS to OpenAFS upgrade complete... problems continue

[Atro Tossavainen]

Thanks all,

* Yes, I know kaserver is deprecated, thank you

* To repeat, running IBM AFS anything on Solaris 10 x64 is not possible

* Running kaserver on hosts other than the current two means running
  all the database services of AFS on hosts other than the current
  two, which leads to all the fun that changing the IP addresses of
  database servers in a cell does, or changing the IP addresses of
  the fileservers in order to restore some other things on the IP
  addresses of the database servers, which leads to other complications
  that I can't have (#2 being our networker backup server, for example)

* I would very much like to get the entire hardware upgrade bit behind
  (including a change of the underlying SAN, the SPARC to x64 servers,
  and the tape library) before embarking on anything to do with the
  logical side of things, such as Kerberos 5, just to keep it manageable
  for myself, it is just me after all.

> My guess is that this would be the result of using 'vos changeaddr', or
> at least something with MH vs non-MH hosts.

MH, non-MH?

Yes, I did have to use vos changeaddr when I changed the new file
servers from their temporary IP addresses to the real ones in order
to see any volumes at all.  I think I've reported that here.

r...@bond / 17 # vldb_check -database /usr/afs/db/vldb.DB0 -servers
VLDB_CHECK_WARNING: Ubik header size is 0 (should be 64)
MH block 0, index 1: 128.214.58.174
MH block 0, index 2: 128.214.88.114
   Server ip addr 0 = MH block 0, index 1
   Server ip addr 1 = MH block 0, index 2
   Server ip addr 2 = 128.214.58.174
   Server ip addr 3 = 128.214.88.114
Scanning 2125 entries for possible repairs

r...@replicon / 16 # /export/home/openafs-1.4.12/sunx86_510/dest/etc/vldb_check 
-database /usr/afs/db/vldb.DB0 -servers
VLDB_CHECK_WARNING: Ubik header size is 0 (should be 64)
MH block 0, index 1: 128.214.58.174
MH block 0, index 2: 128.214.88.114
   Server ip addr 0 = MH block 0, index 1
   Server ip addr 1 = MH block 0, index 2
   Server ip addr 2 = 128.214.58.174
   Server ip addr 3 = 128.214.88.114
Scanning 2125 entries for possible repairs

> With the output of running 'vldb_check -servers' on your VLDB, I'd be
> able to tell.

All ears.  I can't see the obvious fault above.

> VLLog contains nothing on _all_ dbservers?

That's right.  Here they are.

replicon (afsdb1):

Sun May  2 04:01:13 2010 Using 128.214.58.174 as my primary address
Sun May  2 04:01:27 2010 Starting AFS vlserver 4 (/usr/afs/bin/vlserver)
Sun May  2 04:01:27 2010 ubik: A Remote Server has addresses: Sun May  2 
04:01:27 2010 128.214.88.114 Sun May  2 04:01:27 2010 
Sun May  2 04:01:31 2010 ubik:server 128.214.88.114 is back up: will be 
contacted through 128.214.88.114

.old:

Wed Apr 28 14:05:57 2010 Using 128.214.58.174 as my primary address
Wed Apr 28 14:05:57 2010 Starting AFS vlserver 4 (/usr/afs/bin/vlserver)
Fri Apr 30 01:32:19 2010 ubik:server 128.214.88.114 is back up: will be 
contacted through 128.214.88.114
@(#) OpenAFS 1.4.12 built  2010-03-24 

bond (afsdb2):

Sun May  2 04:01:27 2010 Using 128.214.88.114 as my primary address
Sun May  2 04:01:27 2010 Starting AFS vlserver 4 (/usr/afs/bin/vlserver)

.old:

Wed Apr 28 07:32:27 2010 Using 128.214.88.114 as my primary address
Wed Apr 28 07:32:27 2010 Starting AFS vlserver 4 (/usr/afs/bin/vlserver)
Wed Apr 28 07:32:52 2010 Ubik: Synchronize database with server 128.214.58.174
Wed Apr 28 07:32:52 2010 Ubik: Synchronize database completed
Wed Apr 28 14:05:57 2010 ubik: A Remote Server has addresses: Wed Apr 28 
14:05:57 2010 128.214.58.174 Wed Apr 28 14:05:57 2010 
Fri Apr 30 01:32:17 2010 ubik:server 128.214.58.174 is back up: will be 
contacted through 128.214.58.174

-- 
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
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Re: Low load on multi core fileserver

[Andrew Deason]

On Mon, 3 May 2010 23:04:06 -0400
"Brandon S. Allbery KF8NH"  wrote:

> On May 3, 2010, at 09:09 , Frank Burkhardt wrote:
> > is the openafs-fileserver supposed to take advantage of multiple
> > cpu cores?

Yes, however, I think most of the cpu-intensive operations are only in
the RX layer (the network transport / RPC layer). And a lot of the RX
code is very serialized, AFAIR. So, you see a lot of usage on just one
core.

It's one of the unfortunate shortcomings of the RX code. Is this
improved at all in 1.5-specific stuff? I don't remember.

> Last I heard, only the database servers were capable of true
> threaded operation (and that possibly only in 1.5); the fileserver
> still uses the old userspace "threads" library, so can't take
> advantage of real threads or multiple CPUs.

I think you have that a bit backwards. The fileserver almost always uses
pthreads, and has for at least as long as 1.4 has been around; I assume
much longer than that. We only do not use pthreads in the fileserver for
platforms where we know doing so causes problems. I don't think any
modern OpenAFS fileservers are in production that are not pthreaded.

The database servers still use the userspace threads library ('LWP') in
1.4, and we're working towards making them use pthreads in 1.5. Or
rather, they can already be compiled to use pthreads, but doing so
introduces a known race condition that will be fixed when gerrit 1546 or
something like it is merged.

-- 
Andrew Deason
adea...@sinenomine.net

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] "group prefix doesn't match owner"

[Russ Allbery]

Derrick Brashear  writes:
> On Mon, May 3, 2010 at 11:23 PM, Russ Allbery  wrote:

>> Users who create a workgroup named shadow:something and then go to AFS
>> and wonder why fs setacl . shadow:something all doesn't work are
>> unlikely to be easily patched to track by ID instead.

> they should probably avoid chowning the group away between steps a and b.

They're not the ones doing the chowning, and the problem runs much deeper
than chown.  AFS makes it extremely hard to have a group named
bar:something and owned by foo, and I think this is a bug.  We've run into
this bug a bunch of different ways over the years.

The most recent way we had this problem was:

* We have a system that synchronizes groups from LDAP into AFS PTS.

* We don't want that system to have to run as system:administrators
  (principal of least privilege).

* We do want that system to be able to create and manage groups under
  workgroup:*, but we'd also like it to be able to *manage* any other
  group that someone decides to put under its management.  The task of
  putting the group under its management can be done by
  system:administrators.

Unfortunately, there's no way of doing that last bit without renaming the
PTS groups, since if you change the owner, the group magically changes
names.  Which can invalidate other places where people are used to using
the current PTS group name, and also tends to give the groups random and
unhelpful names since it cuts off the first part before the colon, which
is often important information about what the group is for.

Other places where we've run into this was when we wanted to create a set
of groups named cvs-committers:* and manage them all as
system:administrators.  I ended up having to create a fake (and useless)
cvs-committers group to prevent the groups from constantly getting
magically renamed to system:* instead.  Likewise for organization groups;
I end up having to create dummy parent groups matching the prefix that I
don't want and don't want to ever use.

I see no purpose in this restriction, at least if the action is being
performed by system:administrators, and think it should die.

-- 
Russ Allbery (r...@stanford.edu) 
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] "group prefix doesn't match owner"

[Derrick Brashear]

On Mon, May 3, 2010 at 11:23 PM, Russ Allbery  wrote:
> Derrick Brashear  writes:
>> Russ Allbery  wrote:
>>> Derrick Brashear  writes:
>
 A similar "attack" has been discussed before.
>
 pts cg shadow:something
 pts chown shadow:something jaltman
>
 jaltman now owns jaltman:something.
>
>>> This behavior is also really annoying if you have an external group
>>> system whose names you're trying to synchronize with AFS PTS groups.
>
>> only if you track by name and not by id. same issue. :)
>
> Users who create a workgroup named shadow:something and then go to AFS and
> wonder why fs setacl . shadow:something all doesn't work are unlikely to
> be easily patched to track by ID instead.

they should probably avoid chowning the group away between steps a and b.



-- 
Derrick
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Low load on multi core fileserver

[Russ Allbery]

"Brandon S. Allbery KF8NH"  writes:
> On May 3, 2010, at 09:09 , Frank Burkhardt wrote:

>> is the openafs-fileserver supposed to take advantage of multiple cpu
>> cores?

> Last I heard, only the database servers were capable of true threaded
> operation (and that possibly only in 1.5); the fileserver still uses the
> old userspace "threads" library, so can't take advantage of real threads
> or multiple CPUs.

I think you have that backwards -- the database servers are the only
servers not using pthreads now.

-- 
Russ Allbery (r...@stanford.edu) 
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] "group prefix doesn't match owner"

[Russ Allbery]

Derrick Brashear  writes:
> Russ Allbery  wrote:
>> Derrick Brashear  writes:

>>> A similar "attack" has been discussed before.

>>> pts cg shadow:something
>>> pts chown shadow:something jaltman

>>> jaltman now owns jaltman:something.

>> This behavior is also really annoying if you have an external group
>> system whose names you're trying to synchronize with AFS PTS groups.

> only if you track by name and not by id. same issue. :)

Users who create a workgroup named shadow:something and then go to AFS and
wonder why fs setacl . shadow:something all doesn't work are unlikely to
be easily patched to track by ID instead.

-- 
Russ Allbery (r...@stanford.edu) 
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] "group prefix doesn't match owner"

[Derrick Brashear]

On Mon, May 3, 2010 at 10:55 PM, Russ Allbery  wrote:
> Derrick Brashear  writes:
>
>> If it tracked by name.
>
>> A similar "attack" has been discussed before.
>
>> pts cg shadow:something
>> pts chown shadow:something jaltman
>
>> jaltman now owns jaltman:something.
>
> This behavior is also really annoying if you have an external group system
> whose names you're trying to synchronize with AFS PTS groups.

only if you track by name and not by id. same issue. :)
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Low load on multi core fileserver

[Brandon S. Allbery KF8NH]

On May 3, 2010, at 09:09 , Frank Burkhardt wrote:
is the openafs-fileserver supposed to take advantage of multiple cpu  
cores?


Last I heard, only the database servers were capable of true threaded  
operation (and that possibly only in 1.5); the fileserver still uses  
the old userspace "threads" library, so can't take advantage of real  
threads or multiple CPUs.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
Description: This is a digitally signed message part

Re: [OpenAFS] "group prefix doesn't match owner"

[Russ Allbery]

Derrick Brashear  writes:

> If it tracked by name.

> A similar "attack" has been discussed before.

> pts cg shadow:something
> pts chown shadow:something jaltman

> jaltman now owns jaltman:something.

This behavior is also really annoying if you have an external group system
whose names you're trying to synchronize with AFS PTS groups.

-- 
Russ Allbery (r...@stanford.edu) 
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] "group prefix doesn't match owner"

[Derrick Brashear]

On Mon, May 3, 2010 at 10:19 PM, Jeffrey Altman
 wrote:
> On 5/1/2010 6:40 PM, Adam Megacz wrote:
>>
>> Is there any reason why pts won't let system:administrator create groups
>> whose prefix does not match any user?
>>
>>   $pts ex blah
>>   pts: User or group doesn't exist so couldn't look up id for blah
>>   $pts creategroup blah:booh
>>   pts: Badly formed name (group prefix doesn't match owner?) ; unable to 
>> create group blah:booh
>>
>> Clearly this can be circumvented by system:administrator:
>>
>>   $pts cu blah
>>   User blah has id 100015
>>   $pts creategroup blah:booh -owner blah
>>   group blah:booh has id -1012
>>   $pts delete blah
>>   $pts ex blah:booh
>>   Name: blah:booh, id: -1012, owner: 0, creator: megacz,
>>     membership: 0, flags: S-M--, group quota: 0.
>>
>> is there a danger in doing this, other than perhaps confusion?
>
> I suspect that the above is a security issue.  It means that user 1 can
> be assigned pts id "foo" and if "foo" is deleted (but not foo's groups)
> when user 1 leaves the company, then when user 2 comes along and is
> assigned the unused "foo", s/he will inherit all of the groups that
> belonged to user 1.
>
> I suspect the proper behavior should at some point become that deletion
> of pts id "foo" should remove all of the groups as well.

Shouldn't be true. the ptserver tracks by id, not text name. and I
disagree that the change is needed.

> By intentionally creating groups that are owned by no valid pts id,
> you increase the chance that such an id would be used for another purpose.

If it tracked by name.

A similar "attack" has been discussed before.

pts cg shadow:something
pts chown shadow:something jaltman

jaltman now owns jaltman:something.

Derrick
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] "group prefix doesn't match owner"

[Russ Allbery]

Jeffrey Altman  writes:

> I suspect that the above is a security issue.  It means that user 1 can
> be assigned pts id "foo" and if "foo" is deleted (but not foo's groups)
> when user 1 leaves the company, then when user 2 comes along and is
> assigned the unused "foo", s/he will inherit all of the groups that
> belonged to user 1.

> I suspect the proper behavior should at some point become that deletion
> of pts id "foo" should remove all of the groups as well.

Ugh, no, please don't.  Instead, I'd much rather see us break the (IMO
broken) behavior that forces namespace on groups based on who owns them.
We have a perfectly usable owner field that already says who owns the
group.

> By intentionally creating groups that are owned by no valid pts id, you
> increase the chance that such an id would be used for another purpose.

He's creating groups owned by PTS ID 0.  I suspect that's safe.

-- 
Russ Allbery (r...@stanford.edu) 
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Cross compiling openafs modules in Debian stable works with 1.4.7 but fail with 1.4.11 or 1.4.12

[Russ Allbery]

Jose Calhariz  writes:
> On Mon, May 03, 2010 at 07:05:04PM -0700, Russ Allbery wrote:

>> It doesn't work because make libafs_tree only includes the files
>> required for the architecture one runs it on.  The OpenAFS Debian
>> packages switched from a full copy of the source tree to using
>> libafs_tree in that time frame.  I haven't had a chance to try to fix
>> it yet.  If someone else beat me to it, I definitely wouldn't complain.

> How hard is to fix the Debian packages?  I can try to fix it.

It's not the Debian packages.  It's a general bug in the libafs_tree
target in OpenAFS.  It needs to copy over more of the configure machinery
than it does, such as not copying over the pre-generated param.h and
instead copying over the machinery to generate it.

Unfortunately, figuring out exactly what's broken and what additional bits
need to be copied over and built in a libafs build is a fair chunk of the
work that needs to be done.  It's probably not that hard, but it's a bit
tedious.  It's more than four hours of work, I think.

-- 
Russ Allbery (r...@stanford.edu) 
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] "group prefix doesn't match owner"

[Jeffrey Altman]

On 5/1/2010 6:40 PM, Adam Megacz wrote:
> 
> Is there any reason why pts won't let system:administrator create groups
> whose prefix does not match any user?
> 
>   $pts ex blah
>   pts: User or group doesn't exist so couldn't look up id for blah
>   $pts creategroup blah:booh
>   pts: Badly formed name (group prefix doesn't match owner?) ; unable to 
> create group blah:booh 
> 
> Clearly this can be circumvented by system:administrator:
> 
>   $pts cu blah
>   User blah has id 100015
>   $pts creategroup blah:booh -owner blah
>   group blah:booh has id -1012
>   $pts delete blah
>   $pts ex blah:booh
>   Name: blah:booh, id: -1012, owner: 0, creator: megacz,
> membership: 0, flags: S-M--, group quota: 0.
> 
> is there a danger in doing this, other than perhaps confusion?

I suspect that the above is a security issue.  It means that user 1 can
be assigned pts id "foo" and if "foo" is deleted (but not foo's groups)
when user 1 leaves the company, then when user 2 comes along and is
assigned the unused "foo", s/he will inherit all of the groups that
belonged to user 1.

I suspect the proper behavior should at some point become that deletion
of pts id "foo" should remove all of the groups as well.

By intentionally creating groups that are owned by no valid pts id,
you increase the chance that such an id would be used for another purpose.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [OpenAFS] Cross compiling openafs modules in Debian stable works with 1.4.7 but fail with 1.4.11 or 1.4.12

[Jose Calhariz]

On Mon, May 03, 2010 at 07:05:04PM -0700, Russ Allbery wrote:
> Jose Calhariz  writes:
> 
> > I used to cross compile openafs modules to amd64/x86_64 linux kernel
> > from a i386 userland.  I am using the kernel-package command to produce
> > a debian package with the openafs modules.  The last time I compiled new
> > modules was with openafs 1.4.7, for kernel 2.6.26.
> 
> > Now I try to do the same with openafs modules 1.4.11 or 1.4.12 for
> > Linux kernel 2.6.26. But it fails with what seams to be typical cross
> > compiling problems.  I Have looked into the code and logs from
> > openafs-modules-source and kernel-package.  And I found nothing wrong,
> > or different from openafs 1.4.7.  The proper flags for cross-compiling
> > seams to be correct, the generated .o files are for x86_64.  The full
> > error messages are in the end of the email.
> 
> It doesn't work because make libafs_tree only includes the files required
> for the architecture one runs it on.  The OpenAFS Debian packages switched
> from a full copy of the source tree to using libafs_tree in that time
> frame.  I haven't had a chance to try to fix it yet.  If someone else beat
> me to it, I definitely wouldn't complain.
> 

How hard is to fix the Debian packages?  I can try to fix it.

Jose Calhariz

-- 
--
So mesmo um grande esnobismo espiritual faz com que as
pessoas acreditem que podem ser felizes sem
dinheiro.
-- Albert Camus
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Cross compiling openafs modules in Debian stable works with 1.4.7 but fail with 1.4.11 or 1.4.12

[Russ Allbery]

Jose Calhariz  writes:

> I used to cross compile openafs modules to amd64/x86_64 linux kernel
> from a i386 userland.  I am using the kernel-package command to produce
> a debian package with the openafs modules.  The last time I compiled new
> modules was with openafs 1.4.7, for kernel 2.6.26.

> Now I try to do the same with openafs modules 1.4.11 or 1.4.12 for
> Linux kernel 2.6.26. But it fails with what seams to be typical cross
> compiling problems.  I Have looked into the code and logs from
> openafs-modules-source and kernel-package.  And I found nothing wrong,
> or different from openafs 1.4.7.  The proper flags for cross-compiling
> seams to be correct, the generated .o files are for x86_64.  The full
> error messages are in the end of the email.

It doesn't work because make libafs_tree only includes the files required
for the architecture one runs it on.  The OpenAFS Debian packages switched
from a full copy of the source tree to using libafs_tree in that time
frame.  I haven't had a chance to try to fix it yet.  If someone else beat
me to it, I definitely wouldn't complain.

-- 
Russ Allbery (r...@stanford.edu) 
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Cross compiling openafs modules in Debian stable works with 1.4.7 but fail with 1.4.11 or 1.4.12

[Jose Calhariz]

I used to cross compile openafs modules to amd64/x86_64 linux kernel
from a i386 userland.  I am using the kernel-package command to
produce a debian package with the openafs modules.  The last time I
compiled new modules was with openafs 1.4.7, for kernel 2.6.26.

Now I try to do the same with openafs modules 1.4.11 or 1.4.12 for
Linux kernel 2.6.26. But it fails with what seams to be typical cross
compiling problems.  I Have looked into the code and logs from
openafs-modules-source and kernel-package.  And I found nothing wrong,
or different from openafs 1.4.7.  The proper flags for cross-compiling
seams to be correct, the generated .o files are for x86_64.  The full
error messages are in the end of the email.

The initial error message is:

In file included from /usr/src/modules/openafs/src/afs/afsincludes.h:53,
 from 
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c:22:
/usr/src/modules/openafs/src/afs/afs_prototypes.h:950: warning: ‘struct 
flock64’ declared inside parameter list
/usr/src/modules/openafs/src/afs/afs_prototypes.h:950: warning: its scope is 
only this definition or declaration, which is probably not what you want
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c:36:
 warning: ‘struct flock64’ declared inside parameter list
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c:40:
 warning: ‘struct flock64’ declared inside parameter list
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c:45:
 warning: ‘struct flock64’ declared inside parameter list
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c:45:
 error: conflicting types for ‘lockIdSet’
/usr/src/modules/openafs/src/afs/afs_prototypes.h:949: error: previous 
declaration of ‘lockIdSet’ was here


My setup is Debian 5.0/lenny i386 running the amd64 kernel from
Debian.  uname -a

Linux copernico 2.6.26-2-amd64 #1 SMP Tue Mar 9 18:27:05 UTC 2010 x86_64 
GNU/Linux

I am compiling the sources in the package openafs-modules-source.
Version  1.4.7.dfsg1-6+lenny2 from Debian stable works, versions
1.4.11 and 1.4.12 from backports.debian.org don't cross-compile for amd64.


Full error message for afs_vnop_flock.c:

  CC [M]  
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.o
In file included from /usr/src/modules/openafs/src/afs/afsincludes.h:53,
 from 
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c:22:
/usr/src/modules/openafs/src/afs/afs_prototypes.h:950: warning: ‘struct 
flock64’ declared inside parameter list
/usr/src/modules/openafs/src/afs/afs_prototypes.h:950: warning: its scope is 
only this definition or declaration, which is probably not what you want
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c:36:
 warning: ‘struct flock64’ declared inside parameter list
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c:40:
 warning: ‘struct flock64’ declared inside parameter list
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c:45:
 warning: ‘struct flock64’ declared inside parameter list
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c:45:
 error: conflicting types for ‘lockIdSet’
/usr/src/modules/openafs/src/afs/afs_prototypes.h:949: error: previous 
declaration of ‘lockIdSet’ was here
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c: 
In function ‘lockIdSet’:
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c:133:
 error: dereferencing pointer to incomplete type
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c: 
At top level:
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c:157:
 warning: ‘struct flock64’ declared inside parameter list
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c:156:
 error: conflicting types for ‘lockIdcmp2’
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c:38:
 error: previous declaration of ‘lockIdcmp2’ was here
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c: 
In function ‘lockIdcmp2’:
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c:178:
 error: dereferencing pointer to incomplete type
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c:180:
 error: dereferencing pointer to incomplete type
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c:201:
 error: dereferencing pointer to incomplete type
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c: 
In function ‘HandleFlock’:
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-amd64-MP/afs_vnop_flock.c:233:
 error: storage size of ‘flock’ isn’t known
/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.26-2-a

Re: [OpenAFS] Re: Getting started with OpenAFS

[Jason Edgecombe]

Mike Pliskin wrote:

I don't feel qualified to write a tutorial on something I have exactly zero 
experience with :), but some my comments:
 - Andrew's pointers to a typical AFS folder structure are really helpful
 - the note about AlwaysAttach file is helpful as well, and the current doc 
says you need a special partition while Andrew's note explains you don't need 
it - a very important aspect I believe

Additionally, some general notes:
 - more real-life scenarios to cover - i.e. some typical tasks and how you'd 
solve it with afs
 - which version to choose? 1.4 or 1.5?
 - some very basic intro into afs world - structure, distributions, versions, 
installation, authentication etc. There is a Getting Started doc now, but it's 
probably too technical. For instance, it talks about bringing AFS login into 
Linux but I have no idea yet what AFS login is..

Just my 2 cents...
  


Hi Mike,

You are perfectly qualified to point out what's missing and what's 
needed. I think some of this should be on the web site :)


Jason
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Re: "group prefix doesn't match owner"

[Derrick Brashear]

On Mon, May 3, 2010 at 6:42 PM, Adam Megacz  wrote:
>
> Derrick Brashear  writes:
 When creating a group foo:bar as admin, I often find that I have to
 use the -owner parameter to see the owner to foo(something).
>>>
>>> I see.  Is it official AFS policy that this usage is supported?
>>
>> Which usage? I'm not sure what you're asking.
>
> Sorry, let me rephrase.  The following sequence of commands generates an
> error, but appears to work -- by which I mean that it leaves me in a
> state where there is a group named "blah:booh" but no user named "blah".
>
>  $pts cu blah
>  $pts creategroup blah:booh -owner blah
>  $pts delete blah
>  $pts ex blah:booh

if it works, it generates a warning, not an error. you mean invoking a
single diret command generates an error, and the above sequence does
not. correct?

> Is it official AFS policy that this is supposed to work this way, and
> will continue to work this way in the future?

uh. i don't think there's an official AFS policy, period. if the
ptserver starts garbage-collecting orphaned groups, it will be
documented.

> If so, perhaps we should consider changing the error "Badly formed name
> (group prefix doesn't match owner)" into a warning if it's being invoked
> by system:administrators (who could just use the sequence of commands
> above instead).  Or maybe let "-force" override the error.
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Re: "group prefix doesn't match owner"

[Adam Megacz]

Derrick Brashear  writes:
>>> When creating a group foo:bar as admin, I often find that I have to
>>> use the -owner parameter to see the owner to foo(something).
>>
>> I see.  Is it official AFS policy that this usage is supported?
>
> Which usage? I'm not sure what you're asking.

Sorry, let me rephrase.  The following sequence of commands generates an
error, but appears to work -- by which I mean that it leaves me in a
state where there is a group named "blah:booh" but no user named "blah".

  $pts cu blah
  $pts creategroup blah:booh -owner blah
  $pts delete blah
  $pts ex blah:booh

Is it official AFS policy that this is supposed to work this way, and
will continue to work this way in the future?

If so, perhaps we should consider changing the error "Badly formed name
(group prefix doesn't match owner)" into a warning if it's being invoked
by system:administrators (who could just use the sequence of commands
above instead).  Or maybe let "-force" override the error.

  - a

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] Re: Getting started with OpenAFS

[Mike Pliskin]

Hi Jason,

I don't feel qualified to write a tutorial on something I have exactly zero 
experience with :), but some my comments:
 - Andrew's pointers to a typical AFS folder structure are really helpful
 - the note about AlwaysAttach file is helpful as well, and the current doc 
says you need a special partition while Andrew's note explains you don't need 
it - a very important aspect I believe

Additionally, some general notes:
 - more real-life scenarios to cover - i.e. some typical tasks and how you'd 
solve it with afs
 - which version to choose? 1.4 or 1.5?
 - some very basic intro into afs world - structure, distributions, versions, 
installation, authentication etc. There is a Getting Started doc now, but it's 
probably too technical. For instance, it talks about bringing AFS login into 
Linux but I have no idea yet what AFS login is..

Just my 2 cents...

Mike

-Original Message-
From: openafs-info-ad...@openafs.org [mailto:openafs-info-ad...@openafs.org] On 
Behalf Of Jason Edgecombe
Sent: Sunday, May 02, 2010 6:43 PM
To: Mike Pliskin
Cc: Andrew Deason; openafs-info@openafs.org
Subject: Re: [OpenAFS] Re: Getting started with OpenAFS

Hi Mike,

Would you please elaborate on your tutorial comment? What should it contain? 
What key concepts need to be mentioned? Would you be willing to help write such 
a document or give some notes on what it should contain?

The challenge of many of the AFS veterans is that we cannot see things as a new 
user sees them.

Thanks,
Jason

Mike Pliskin wrote:
> Ok thanks for explaining that, maybe it makes sense to post this info into 
> some tutorial online? In terms of geographical diversity, it's uncommon that 
> people from different sites need to write the same info, so it's ok if it is 
> a bit slow.
>
> Mike
>
> -Original Message-
> From: openafs-info-ad...@openafs.org 
> [mailto:openafs-info-ad...@openafs.org] On Behalf Of Andrew Deason
> Sent: Friday, April 30, 2010 7:01 PM
> To: openafs-info@openafs.org
> Subject: [OpenAFS] Re: Getting started with OpenAFS
>
> On Fri, 30 Apr 2010 17:49:16 +0400
> Mike Pliskin  wrote:
>
>   
>> Ok thanks a ton for explaining, the only point left is read-write and 
>> read-only and how to separate those. So far it sounds like I will 
>> need to have a setup like
>> /afs/public/data1
>> /afs/public/data2
>> /afs/public/data3
>> /afs/user1/data1
>> /afs/user2/data2 etc
>> 
>
> The general notion of ROs vs RWs sounds correct, but the path structure is 
> annoying me :) Traditionally, the convention of paths goes something like 
> this:
>
> /afs//
>
> for the RO path, and
>
> /afs//.
>
> for the RW path. (And /afs/./ provides an RW path for anything).
>
> So for example, you'd have /afs/area9.dk/.data1/, that some users can write 
> to and fiddle around with. When someone/something decides it is time to 
> release that data to all sites and make it 'public' via the RO paths, the 
> data in /afs/area9.dk/.data1/ becomes synced with /afs/area9.dk/data1/. You 
> 'decide' this by running a command (specifically 'vos release'). Then people 
> can read the new stuff in /afs/area9.dk/data1/ by accessing one of many 
> servers.
>
> I'm not really sure I'm clear on your usage, though... you have data which 
> will be 'accessed' by geographically diverse clients. But it helps to clarify 
> 'access' into 'read' and 'write'. Do you have people from multiple different 
> sites that will be writing to the same set of data?
> As far as I know, that will always be slow, since you must at least contact 
> the remote sites immediately, or you risk cache coherence problems.
>
> --
> Andrew Deason
> adea...@sinenomine.net
>
> ___
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> :  

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Re: AFS version of du

[Andrew Deason]

On Mon, 3 May 2010 15:47:41 -0400 (EDT)
Richard Brittain  wrote:

> Bear in mind that I got similarly broken results from Solaris 9 and
> OSX/BSD verion of 'find' when scanning the top levels of the cell, so
> it isn't unique to GNU.  The OSX find might include GNU code - it has
> a lot of similar options beyond traditional Unix find.  A quick test
> showed Solaris behaving itself today but OSX still giving the same
> errors.

Could you capture a truss/strace/etc of the 'find' process when you get
this to break? And would you be willing to share it?

And I think ideally, all that would go in an RT ticket sent to
openafs-bugs.

-- 
Andrew Deason
adea...@sinenomine.net

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AFS version of du

[Richard Brittain]

On Mon, 3 May 2010, Steve Simmons wrote:


File::Find module works fine, while 'find' breaks.  Underneath they are 
presumably making very similar system calls.


. . . .  File::Find has gone through a lot of development aimed at reducing its 
impact on the system, whereas in my experience the GNU folks tend to prefer the 
throw-more-resources-at-it method.


The findutils developers seem to be an exception to this. In my correspondence 
with them they were pretty firm about not adding overhead. Their goal was that 
any features added that were specific to afs, cifs, etc should not add overhead 
to systems that did not have that filesystem type. I can't speak to how well 
they succeeded, but that was their goal.


Bear in mind that I got similarly broken results from Solaris 9 and 
OSX/BSD verion of 'find' when scanning the top levels of the cell, so it 
isn't unique to GNU.  The OSX find might include GNU code - it has a lot 
of similar options beyond traditional Unix find.  A quick test showed 
Solaris behaving itself today but OSX still giving the same errors.


Richard
--
Richard Brittain,  Research Computing Group,
   Kiewit Computing Services, 6224 Baker/Berry Library
   Dartmouth College, Hanover NH 03755
richard.britt...@dartmouth.edu 6-2085
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Seamless adding of a replication server

[Russ Allbery]

"Karl Tißner"  writes:

> We use Debian 5/6, which is delivered with helpful scripts afs-newcell
> afs-rootvol. But - do I have to install the "afs-newcell" (I do dot want
> a new cell, I already have one), do I have to call "afs-rootvol" (I dont
> need a new root.afs, I want to replicate the other one, or is this
> wrong?). When do I have to call the "bos addhost" command? I am quite
> unsure, as you can see ...

See "Adding Additional Servers" in
/usr/share/doc/openafs-fileserver/README.servers.gz (and let me know if
anything is missing from there).

-- 
Russ Allbery (r...@stanford.edu) 
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] OpenAFS for Windows Integrated Logon - On or Off by default?

[Dave B]

My thoughts...

if the 1.6 branch is about to come out, then that version number change
would be a good place to make the integrated login change.

That said, as long as it's well announced, I don't have a problem w. the
change being made in 1.5.whatever ... now that I've learned how to do
transforms, this additional change should be relatively trivial.

On Mon, 2010-05-03 at 13:51 -0400, Jeffrey Altman wrote:
> The OpenAFS for Windows distributions come in two different installation
> packaging flavors.  The .EXE installer based on NSIS defaults integrated
> logon to be disabled.  The .MSI installer based on WiX defaults
> integrated logon to be enabled.  The reason for this difference is
> historical.  The MSI installer package was developed at MIT for use in
> pushing out OpenAFS to large numbers of clients via an automated "quiet"
> process.  The EXE installers were designed for use by individuals.  For
> the individual case the integrated logon functionality is less likely to
> be needed whereas the managed desktop environment is more likely to want it.
> 
> Over the years the MSI installer package has begun to be used more
> frequently by individual users.   This is especially true for 64-bit
> Windows because there is no EXE option available.  When integrated logon
> is turned on by default and it is not properly configured this can cause
> long delays when attempting to logon to the machine.  Proper
> configuration requires a cell name, perhaps a realm name, and Kerberos
> configuration data available either via local configuration files or DNS
> SRV records.  This long delay results in end users (and even some
> experienced OpenAFS developers) believing that OpenAFS has somehow
> broken their machine.
> 
> What I want to do is change the default in the MSI installer to be "off"
> [var.LogonOptions = "0"] but such a change will cause site specific
> transforms to do the wrong thing unless the transform is rebuilt.  Even
> though this change will be documented in the ChangeLog, the Release
> Notes, and in the Release Announcement I suspect that there are going to
> be a number of sites that will get burned by this change.  We have known
> about this problem for many years now and have put off dealing with it. 
> The question is, "is now the time to address the problem and prevent
> additional end users from getting burned when they decide to experiment
> with OpenAFS for Windows on their machine?"
> 
> One option would be to hold off on this change for another month or two
> and apply it to the tree just before the 1.6 branch is cut.
> 
> Thoughts?
> 
> Jeffrey Altman
> 
> 
-- 

David William Botsch
Programmer/Analyst
CNF Computing
bot...@cnf.cornell.edu



___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] OpenAFS for Windows Integrated Logon - On or Off by default?

[Jeffrey Altman]

The OpenAFS for Windows distributions come in two different installation
packaging flavors.  The .EXE installer based on NSIS defaults integrated
logon to be disabled.  The .MSI installer based on WiX defaults
integrated logon to be enabled.  The reason for this difference is
historical.  The MSI installer package was developed at MIT for use in
pushing out OpenAFS to large numbers of clients via an automated "quiet"
process.  The EXE installers were designed for use by individuals.  For
the individual case the integrated logon functionality is less likely to
be needed whereas the managed desktop environment is more likely to want it.

Over the years the MSI installer package has begun to be used more
frequently by individual users.   This is especially true for 64-bit
Windows because there is no EXE option available.  When integrated logon
is turned on by default and it is not properly configured this can cause
long delays when attempting to logon to the machine.  Proper
configuration requires a cell name, perhaps a realm name, and Kerberos
configuration data available either via local configuration files or DNS
SRV records.  This long delay results in end users (and even some
experienced OpenAFS developers) believing that OpenAFS has somehow
broken their machine.

What I want to do is change the default in the MSI installer to be "off"
[var.LogonOptions = "0"] but such a change will cause site specific
transforms to do the wrong thing unless the transform is rebuilt.  Even
though this change will be documented in the ChangeLog, the Release
Notes, and in the Release Announcement I suspect that there are going to
be a number of sites that will get burned by this change.  We have known
about this problem for many years now and have put off dealing with it. 
The question is, "is now the time to address the problem and prevent
additional end users from getting burned when they decide to experiment
with OpenAFS for Windows on their machine?"

One option would be to hold off on this change for another month or two
and apply it to the tree just before the 1.6 branch is cut.

Thoughts?

Jeffrey Altman




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [OpenAFS] Re: "group prefix doesn't match owner"

[Derrick Brashear]

On Sun, May 2, 2010 at 5:11 PM, Adam Megacz  wrote:
>
> Markus Koeberl  writes:
>>>   $pts creategroup blah:booh
>>
>> Maybe what you want is to create a group blah.
>
> No -- I actually want it to be called blah:booh.
>
> Making sure group names always have a colon in them is important in
> cells that have supergroups enabled; otherwise it's hard to tell what
> the output of "pts mem" actually means (ie when you need to invoke "pts
> mem" a second time to drill down into a nested group).
>
>> When creating a group foo:bar as admin, I often find that I have to
>> use the -owner parameter to see the owner to foo(something).
>
> I see.  Is it official AFS policy that this usage is supported?

Which usage? I'm not sure what you're asking.
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Re: Seamless adding of a replication server

[Andrew Deason]

On Mon, 03 May 2010 11:34:18 +0200
"Karl Tißner"  wrote:

> The existing documentation I found explains the replication, if more
> than one server already exists, or the installation of a standalone
> new server. But how do I seamless integrate a new server in my cell?

I'm not sure what the difference between a "standalone new server" and
an "integrated new server" in a cell would be, so perhaps you already
have the instructions you need. But, to try and be sure, some
instructions are below, but they may include some things you already
know.

> We use Debian 5/6, which is delivered with helpful scripts afs-newcell
> afs-rootvol. But - do I have to install the "afs-newcell" (I do dot
> want a new cell, I already have one),

No, don't run that.

> do I have to call "afs-rootvol"

No, don't run that.

> When do I have to call the "bos addhost" command? I am quite unsure,
> as you can see ... 

'bos addhost' is just for new dbservers; you're adding just a
fileserver. I don't have any step-by-step instructions I can point you
at (possibly because there aren't that many steps). But here's what I'd
say:

After you install OpenAFS on the new server, copy the contents of
/etc/openafs/server (also known as /usr/afs/etc) from the old server to
the new server. Do NOT copy the stuff in /var/lib/openafs/local (also
known as /usr/afs/local).

Then, setup the vicepX partitions however you want (I'm assuming you
know how to do that; if not, just ask). Run bosserver, and from there
you can run 'bos create' to setup the fileserver instance.  Normally
you'd want to run something like:

bos create newserver fs fs \
/usr/lib/openafs/fileserver \
/usr/lib/openafs/volserver \
/usr/lib/openafs/salvager

(or edit BosConfig yourself before starting bosserver)

>From there, I'd verify that the new server is working, by
'vos create'ing some new volumes on it and making sure they work. Once
you're confident that the new server is working, you can run

vos addsite newserver  
vos release 

To make the new server a replication site for the volume , and
to release data to it. Note that I'm assuming you already have a
replication site on the old server, as well; if you don't, you should
add one there, first.

-- 
Andrew Deason
adea...@sinenomine.net

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] AFS version of du

[Steve Simmons]

On May 1, 2010, at 1:35 AM, Brandon S. Allbery KF8NH wrote:

> On Apr 30, 2010, at 14:32 , Richard Brittain wrote:
>> This solves my immediate need, and I'll probably use your mount point 
>> database too, but begs the question of why perl's
>> File::Find module works fine, while 'find' breaks.  Underneath they are 
>> presumably making very similar system calls.
> 
> . . . .  File::Find has gone through a lot of development aimed at reducing 
> its impact on the system, whereas in my experience the GNU folks tend to 
> prefer the throw-more-resources-at-it method.

The findutils developers seem to be an exception to this. In my correspondence 
with them they were pretty firm about not adding overhead. Their goal was that 
any features added that were specific to afs, cifs, etc should not add overhead 
to systems that did not have that filesystem type. I can't speak to how well 
they succeeded, but that was their goal.

Steve___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Re: IBM AFS to OpenAFS upgrade complete... problems continue

[Andrew Deason]

On Mon, 3 May 2010 15:23:29 +0300 (EEST)
Atro Tossavainen  wrote:

> Mon May  3 15:18:31 2010 VL_RegisterAddrs rpc failed; The IP address exists 
> on a different server; repair it
> Mon May  3 15:18:31 2010 VL_RegisterAddrs rpc failed; See VLLog for details

My guess is that this would be the result of using 'vos changeaddr', or
at least something with MH vs non-MH hosts. With the output of running
'vldb_check -servers' on your VLDB, I'd be able to tell.

> (It's now 15.22 as I write this.)
> 
> VLLog contains nothing.

VLLog contains nothing on _all_ dbservers?

-- 
Andrew Deason
adea...@sinenomine.net

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] IBM AFS to OpenAFS upgrade complete... problems continue

[Derrick Brashear]

On Mon, May 3, 2010 at 8:23 AM, Atro Tossavainen
 wrote:
> Hello all,
>
> I am pleased(?) to say that the SPARC Solaris 8 hosts running IBM AFS
> are gone and all @ our place is now on x86_64 Solaris 10 hosts running
> OpenAFS 1.4.12.
>
> I am still experiencing kaserver database issues of the same kind as
> before, with one of the boxes reporting unknown key version number.
> I can't reproduce this at will.  At present, it seems to be all right,
> but only on Friday one of our users couldn't change their password
> because of this.
>
> I am also experiencing new issues with clients reporting connection
> timing out on AFS files, with the servers NOT going missing at any
> stage as far as I can see.  In addition, the FileLog of the server
> that was changed first does contain an awful lot of "VL_RegisterAddrs
> rpc failed" messages:
>
> Mon May  3 15:18:31 2010 VL_RegisterAddrs rpc failed; The IP address exists 
> on a different server; repair it
> Mon May  3 15:18:31 2010 VL_RegisterAddrs rpc failed; See VLLog for details
>
> (It's now 15.22 as I write this.)
>
> VLLog contains nothing.
>
> All help appreciated, as always.

If you can't turn of ka *service* can you at least migration to krb5
(one shot with afs2k5db or with Heimdal) and then run either fakeka
with an MIT kdc, or heimdal's kaserver emulation?




-- 
Derrick
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Low load on multi core fileserver

[Frank Burkhardt]

Hi AFS-Fans,

is the openafs-fileserver supposed to take advantage of multiple cpu cores?

I got a new big server which I tried to use as a afs-fileserver (just for
fun - the server will be dedicated to something else later). However, 7 of
its 8 cores seems to idle all the time - even when 7 afs-clients are writing
data into volumes on harddisks attached to the server. BTW: There's one
harddisc per volume.

The network seems not to be a bottleneck - performance varies between 10 and
20 MB/s on a 1GBit-Link.

I admit to have a rather old Openafs version (1.4.10). Is there a chance to
increase utilisation of this server? Will upgrading to 1.4.12 fix this?

The server runs Debian Lenny without further modifications - kernel is
2.6.26 (x86_64).

Thank you for any help.

Regards,

Frank
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] IBM AFS to OpenAFS upgrade complete... problems continue

[Jeffrey Altman]

On 5/3/2010 8:23 AM, Atro Tossavainen wrote:
> Hello all,
> 
> I am pleased(?) to say that the SPARC Solaris 8 hosts running IBM AFS
> are gone and all @ our place is now on x86_64 Solaris 10 hosts running
> OpenAFS 1.4.12.
> 
> I am still experiencing kaserver database issues of the same kind as
> before, with one of the boxes reporting unknown key version number.
> I can't reproduce this at will.  At present, it seems to be all right,
> but only on Friday one of our users couldn't change their password
> because of this.

Unfortunately, kaserver is a service that has been deprecated within
OpenAFS since the release of 1.4.

  http://www.openafs.org/no-more-des.html

As described, in the upcoming 1.6 release kaserver will become an
optional build component and in 1.8 kserver will be off by default.  If
the 1.4 kaserver is unreliable in your environment I would recommend
continuing to use the IBM kaserver on the platforms where it is
supported or you can try the OpenAFS 1.2 kaserver on the platforms where
it is supported.

Another option that you can try is to use the 1.5.74 kaserver.  I
mention this because although there has been no kaserver specific work
over the last five years, the src/kauth directory has not been ignored
by the efforts to prototype all functions and remove all warnings.
However, the kaserver code is plagued with warnings from the DES library
(particularly on 64-bit systems) and no efforts have been made to
correct them.

Migrating to krb5 is the preferred option of the community.

OpenAFS will accept patches to kaserver that fix functionality.  The
challenge is going to be finding someone to identify the bug(s) and
develop and test the patch.  We have not had anyone since the creation
of OpenAFS be interested in spending significant effort on the kaserver
source code.

> I am also experiencing new issues with clients reporting connection
> timing out on AFS files, with the servers NOT going missing at any
> stage as far as I can see.  In addition, the FileLog of the server
> that was changed first does contain an awful lot of "VL_RegisterAddrs
> rpc failed" messages:
> 
> Mon May  3 15:18:31 2010 VL_RegisterAddrs rpc failed; The IP address exists 
> on a different server; repair it
> Mon May  3 15:18:31 2010 VL_RegisterAddrs rpc failed; See VLLog for details
> 
> (It's now 15.22 as I write this.)
> 
> VLLog contains nothing.
> 
> All help appreciated, as always.

Did you examine the VLLog log on the VLDB server that is currently the
sync site?

Jeffrey Altman






smime.p7s
Description: S/MIME Cryptographic Signature

[OpenAFS] IBM AFS to OpenAFS upgrade complete... problems continue

[Atro Tossavainen]

Hello all,

I am pleased(?) to say that the SPARC Solaris 8 hosts running IBM AFS
are gone and all @ our place is now on x86_64 Solaris 10 hosts running
OpenAFS 1.4.12.

I am still experiencing kaserver database issues of the same kind as
before, with one of the boxes reporting unknown key version number.
I can't reproduce this at will.  At present, it seems to be all right,
but only on Friday one of our users couldn't change their password
because of this.

I am also experiencing new issues with clients reporting connection
timing out on AFS files, with the servers NOT going missing at any
stage as far as I can see.  In addition, the FileLog of the server
that was changed first does contain an awful lot of "VL_RegisterAddrs
rpc failed" messages:

Mon May  3 15:18:31 2010 VL_RegisterAddrs rpc failed; The IP address exists on 
a different server; repair it
Mon May  3 15:18:31 2010 VL_RegisterAddrs rpc failed; See VLLog for details

(It's now 15.22 as I write this.)

VLLog contains nothing.

All help appreciated, as always.
-- 
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
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Seamless adding of a replication server

[Karl Tißner]

Hello,

I am looking for a tutorial or a step-to-step instruction for adding a 
replication server to an existing singe OpenAFS server installation. This is an 
heavily used production server, and so I am a bit afraid of doing something 
wrong (losing the VLDB, for example).

The existing documentation I found explains the replication, if more than one 
server already exists, or the installation of a standalone new server. But how 
do I seamless integrate a new server in my cell?

We use Debian 5/6, which is delivered with helpful scripts afs-newcell  
afs-rootvol. But - do I have to install the "afs-newcell" (I do dot want a new 
cell, I already have one), do I have to call "afs-rootvol" (I dont need a new 
root.afs, I want to replicate the other one, or is this wrong?). When do I have 
to call the "bos addhost" command? I am quite unsure, as you can see ... 
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info