From wlm020279@yahoo.com Sun Feb 1 00:10:46 2009 From: wlm020279@yahoo.com (William McCabe) Date: Sat, 31 Jan 2009 16:10:46 -0800 (PST) Subject: [OpenAFS] Read-Write Disconnected Mode - How does it work? In-Reply-To: <2CCB90CE-E201-41EC-ADD5-3DCDAB9D23DF@inf.ed.ac.uk> Message-ID: <766089.73387.qm@web52208.mail.re2.yahoo.com> --0-602622910-1233447046=:73387 Content-Type: text/plain; charset=us-ascii Simon, Thanks for the information. To operate on the files while the volume is disconnected, do you need to have the server software installed, or do all of these commands work with the client? Thanks, Bill --- On Sat, 1/31/09, Simon Wilkinson wrote: From: Simon Wilkinson Subject: Re: [OpenAFS] Read-Write Disconnected Mode - How does it work? To: wlm020279@yahoo.com Cc: openafs-info@openafs.org Date: Saturday, January 31, 2009, 6:55 PM On 31 Jan 2009, at 23:34, William McCabe wrote: > The latest version of openafs 1.5.57 can use volumes in a disconnected read-write mode. Indeed it can. The work was done by Dragos Tatulea as part of last year's Google Summer of Code. > Where can I find some documentation for how to use this feature? Is the feature stable? What are the bugs? There's not much user documentation available. Disconnected operations is still under active development - whilst I'd love to get feedback from power users who are testing it, it probably isn't entirely ready for production use. The major showstopper here is that we don't have a mechanism for preserving the state of the cache across machine reboots. This means that if you reboot your machine for any reason whilst disconnected, you lose all of the changes made whilst in the disconnected state. Obviously, this is a significant data loss issue and one that needs to be resolved before its ready for widespread use. That said, of the currently known bugs in disconnected, which are tracked in RT at http://rt.central.org/rt/Ticket/Display.htmlid=124148&user=guest&pass=guest there don't appear to be any other significant data loss issues, and I'd be very grateful to hardy souls who wish to try it out and provide additional bug reports. The user interface is currently pretty primitive (the other major issue that we need to resolve before it's 'done'). Before disconnecting, you must first prime your cache with all of the files you wish to use whilst disconnected. Eventually, we will have a pinning mechanism which will allow the cache manager to do this for you. I typically prime my cache by doing something along the lines of find . | xargs cat > /dev/null Then, you can take the cache manager disconnected by running (as root) fs discon offline You may then read and write files in the primed set as you see fit. When you are back on a decent network connection, you can go back online by running, as root, and with appropriate tokens: fs discon online This may fail either due to conflicts on the server, or due to transient errors such as connection timeouts. If it does so, you can retry simply by running the command again. Server conflicts currently have to be repaired by hand. If you're in a situation where you just can't fix the problem, and you're happy to discard the data, 'fs discon online -force' will reconnect you, throwing away any stored changes. I've so far run a number of file system test utilities against disconnected mode, as well as using it for some day to day work, and a large number of package builds. I'm not currently aware of any way to break the current code. There are some additional fixes in CVS, over the 1.5.57 release, so if you are interested in testing, using the tip of the 1.5 branch is a good place to start. If you do try it out, please do let me know how you get on! Thanks, Simon. --0-602622910-1233447046=:73387 Content-Type: text/html; charset=us-ascii

Simon,

Thanks for the information. To operate on the files while the volume is disconnected, do you need to have the server software installed, or do all of these commands work with the client?

Thanks,

Bill

--- On Sat, 1/31/09, Simon Wilkinson <sxw@inf.ed.ac.uk> wrote:
From: Simon Wilkinson <sxw@inf.ed.ac.uk>
Subject: Re: [OpenAFS] Read-Write Disconnected Mode - How does it work?
To: wlm020279@yahoo.com
Cc: openafs-info@openafs.org
Date: Saturday, January 31, 2009, 6:55 PM

On 31 Jan 2009, at 23:34, William McCabe wrote:

> The latest version of openafs 1.5.57 can use volumes in a disconnected
read-write mode.

Indeed it can. The work was done by Dragos Tatulea as part of last year's
Google Summer of Code.

> Where can I find some documentation for how to use this feature? Is the
feature stable? What are the bugs?

There's not much user documentation available. Disconnected operations is
still under active development - whilst I'd love to get feedback from power
users who are testing it, it probably isn't entirely ready for production
use. The major showstopper here is that we don't have a mechanism for
preserving the state of the cache across machine reboots. This means that if you
reboot your machine for any reason whilst disconnected, you lose all of the
changes made whilst in the disconnected state. Obviously, this is a significant
data loss issue and one that needs to be resolved before its ready for
widespread use.

That said, of the currently known bugs in disconnected, which are tracked in RT
at
http://rt.central.org/rt/Ticket/Display.htmlid=124148&user=guest&pass=guest
there don't appear to be any other significant data loss issues, and I'd
be very grateful to hardy souls who wish to try it out and provide additional
bug reports.

The user interface is currently pretty primitive (the other major issue that we
need to resolve before it's 'done').

Before disconnecting, you must first prime your cache with all of the files you
wish to use whilst disconnected. Eventually, we will have a pinning mechanism
which will allow the cache manager to do this for you. I typically prime my
cache by doing something along the lines of
find . | xargs cat > /dev/null

Then, you can take the cache manager disconnected by running (as root)
fs discon offline

You may then read and write files in the primed set as you see fit.

When you are back on a decent network connection, you can go back online by
running, as root, and
with appropriate tokens:
fs discon online

This may fail either due to conflicts on the server, or due to transient errors
such as connection timeouts. If it does so, you can retry simply by running the
command again. Server conflicts currently have to be repaired by hand. If
you're in a situation where you just can't fix the problem, and
you're happy to discard the data, 'fs discon online -force' will
reconnect you, throwing away any stored changes.

I've so far run a number of file system test utilities against disconnected
mode, as well as using it for some day to day work, and a large number of
package builds. I'm not currently aware of any way to break the current
code. There are some additional fixes in CVS, over the 1.5.57 release, so if you
are interested in testing, using the tip of the 1.5 branch is a good place to
start.

If you do try it out, please do let me know how you get on!

Thanks,

Simon.

--0-602622910-1233447046=:73387-- From sxw@inf.ed.ac.uk Sun Feb 1 00:15:36 2009 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Sun, 1 Feb 2009 00:15:36 +0000 Subject: [OpenAFS] Read-Write Disconnected Mode - How does it work? In-Reply-To: <766089.73387.qm@web52208.mail.re2.yahoo.com> References: <766089.73387.qm@web52208.mail.re2.yahoo.com> Message-ID: <60A7B931-3AFE-478A-87D3-9D93921F0555@inf.ed.ac.uk> On 1 Feb 2009, at 00:10, William McCabe wrote: > Thanks for the information. To operate on the files while the > volume is disconnected, do you need to have the server software > installed, or do all of these commands work with the client? These commands all work with the client only - you don't need any server software installed on your local machine, and disconnected operation requires no changes to your fileservers. I should have added that the bulk of the testing to date has been done on Linux. The code is known to work on Darwin. To my knowledge no testing at all has been done of disconnected operations on any of our other platforms. S. From openafs-info@openafs.org Sun Feb 1 09:26:44 2009 From: openafs-info@openafs.org (Axel Thimm) Date: Sun, 1 Feb 2009 10:26:44 +0100 Subject: [OpenAFS] Re: Fedora 10 kernels: openafs-1.4.8/src/afs/afs.h:161: error: field 'Fid' has incomplete type In-Reply-To: <246A1210-E532-4E7E-980F-CDD02D676DF4@inf.ed.ac.uk> References: <20090131200547.GB28687@victor.nirvana> <246A1210-E532-4E7E-980F-CDD02D676DF4@inf.ed.ac.uk> Message-ID: <20090201092644.GA13288@teufli.physik.fu-berlin.de> On Sat, Jan 31, 2009 at 09:53:43PM +0000, Simon Wilkinson wrote: >=20 > On 31 Jan 2009, at 20:05, Axel Thimm wrote: >=20 > >Fedora 10 kernels starting with 2.6.27.12-170.2.5.fc10.x86_64 fail >=20 >=20 > I've successfully built 1.4.8, without patches, for this kernel - =20 > those errors look different from what I'd expect due to just kernel =20 > changes. Have you checked the integrity of your build host, and =20 > OpenAFS tarball? Yes, I have. The openafs sources are the same (and they do build on i686/i586). The build hosts are also OK, and the error shows up on all of them. There are of course more than just kernel changes in Fedora 10 - there are many updates to other packages that may have caused this, maybe by poluting /usr/include. Have you tried building on a recently updated chroot/host? Perhaps it isn't the kernel changes that bite openafs on x86_64, and I wish Fedora would keep the last kernel-devel around for me to try to rebuild openafs on the the previous kernel to see whether it is the kernel change or the rest of the environment. :/ --=20 Axel.Thimm at ATrpms.net From ragge@ltu.se Sun Feb 1 09:51:51 2009 From: ragge@ltu.se (Anders Magnusson) Date: Sun, 01 Feb 2009 10:51:51 +0100 Subject: [OpenAFS] Volume space "lost in space". Message-ID: <498570B7.90100@ltu.se> We have encountered a strange error here on a volume. vos examine (or fs lq) says that it is 15G in size, but du can only find 4G in the volume. salvager do not find anything wrong with the volume. Any hints? The fileserver runs 1.4.5 (on RHEL4). Reading the RELNOTES for the later releases shows nothing about a fix for this problem. -- Ragge From sxw@inf.ed.ac.uk Sun Feb 1 10:18:00 2009 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Sun, 1 Feb 2009 10:18:00 +0000 Subject: [OpenAFS] Re: Fedora 10 kernels: openafs-1.4.8/src/afs/afs.h:161: error: field 'Fid' has incomplete type In-Reply-To: <20090201092644.GA13288@teufli.physik.fu-berlin.de> References: <20090131200547.GB28687@victor.nirvana> <246A1210-E532-4E7E-980F-CDD02D676DF4@inf.ed.ac.uk> <20090201092644.GA13288@teufli.physik.fu-berlin.de> Message-ID: <109BAA6E-E0E7-4878-B44E-53BDC212363D@inf.ed.ac.uk> On 1 Feb 2009, at 09:26, Axel Thimm wrote: > There are of course more than just kernel changes in Fedora 10 - there > are many updates to other packages that may have caused this, maybe by > poluting /usr/include. Have you tried building on a recently updated > chroot/host? I build with mock, on the day that the new kernel appears - that module was built sucessfully on January 27th, against the package set available in the upstream Fedora 10 repository on that day. > Perhaps it isn't the kernel changes that bite openafs on x86_64 I've just checked again, using mock against today's set of Fedora modules, and 1.4.8 still builds fine against that kernel on x86_64. > I wish Fedora would keep the last kernel-devel around OpenAFS has a repository of every kernel-devel module that Fedora/ RedHat has released for all of the architectures we build on - I can let you have older kernel-devel packages if that would be of use to you. S. From Axel.Thimm@ATrpms.net Sun Feb 1 10:51:12 2009 From: Axel.Thimm@ATrpms.net (Axel Thimm) Date: Sun, 1 Feb 2009 12:51:12 +0200 Subject: [OpenAFS] Re: Fedora 10 kernels: openafs-1.4.8/src/afs/afs.h:161: error: field 'Fid' has incomplete type In-Reply-To: <109BAA6E-E0E7-4878-B44E-53BDC212363D@inf.ed.ac.uk> References: <20090131200547.GB28687@victor.nirvana> <246A1210-E532-4E7E-980F-CDD02D676DF4@inf.ed.ac.uk> <20090201092644.GA13288@teufli.physik.fu-berlin.de> <109BAA6E-E0E7-4878-B44E-53BDC212363D@inf.ed.ac.uk> Message-ID: <20090201105112.GA3713@victor.nirvana> --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sun, Feb 01, 2009 at 10:18:00AM +0000, Simon Wilkinson wrote: > On 1 Feb 2009, at 09:26, Axel Thimm wrote: >> I wish Fedora would keep the last kernel-devel around > > OpenAFS has a repository of every kernel-devel module that Fedora/RedHat= =20 > has released for all of the architectures we build on - I can let you=20 > have older kernel-devel packages if that would be of use to you. Many thanks! I pinged fedora-kernel in parallel and I got this reply: On Sun, Feb 01, 2009 at 10:44:54AM +0100, Matthias Hensler wrote: > On Sun, Feb 01, 2009 at 10:31:10AM +0100, Axel Thimm wrote: > > there is some build regression with openafs and the latest Fedora > > 10 x86_64 kernel and it could be either due to the kernel or due > > to other changes in the build environment. Is there a way to > > retrieve older kernel-devel packages to test this? (Actually I > > think I know the answer is yes, so the question is rather "how" :) >=20 > As far as I see all recent (at least over 1000) kernelbuilds are > available here: > http://koji.fedoraproject.org/koji/packageinfo?packageID=3D8 So there is an archive of old kernel-devel packages lying around. I'll grab these for the tests and get back. Thanks for the offer, nevertheless!!! --=20 Axel.Thimm at ATrpms.net --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmFfpsACgkQQBVS1GOamfErGwCggz1o0kvWaYdRB8xyEVIz84v/ jiwAn1k48IsEgjrBt7ZQJF063o/dSocE =KDK0 -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From sxw@inf.ed.ac.uk Sun Feb 1 11:13:46 2009 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Sun, 1 Feb 2009 11:13:46 +0000 Subject: [OpenAFS] Fedora 10 kernels: openafs-1.4.8/src/afs/afs.h:161: error: field 'Fid' has incomplete type In-Reply-To: <20090131200547.GB28687@victor.nirvana> References: <20090131200547.GB28687@victor.nirvana> Message-ID: <1CE3047A-36D2-4D37-AA0B-B7ECC73A13BF@inf.ed.ac.uk> On 31 Jan 2009, at 20:05, Axel Thimm wrote: > > CC [M] /builddir/openafs-1.4.8/src/libafs/ > MODLOAD-2.6.27.12-170.2.5.fc10.x86_64-Default/afs_analyze.o > In file included from /builddir/openafs-1.4.8/src/afs/afsincludes.h: > 44, > from /builddir/openafs-1.4.8/src/libafs/ > MODLOAD-2.6.27.12-170.2.5.fc10.x86_64-Default/afs_analyze.c:36: > /builddir/openafs-1.4.8/src/afs/afs.h:161: error: field 'Fid' has > incomplete type One thing that might help you in your investigations - all of the symbols you're missing are provided by 'afsint.h', which is a RPC header file produced by rxgen. Three possibilities occur to me - that rxgen is failing for some reason and that error isn't being caught, that some other part of your build system is providing an afsint.h that is being erroneously included first, or that something else is defining the _RXGEN_AFSINT_ sentinel that protects that file. S. From haba@kth.se Sun Feb 1 14:04:37 2009 From: haba@kth.se (Harald Barth) Date: Sun, 01 Feb 2009 15:04:37 +0100 (CET) Subject: [OpenAFS] Volume space "lost in space". In-Reply-To: <498570B7.90100@ltu.se> References: <498570B7.90100@ltu.se> Message-ID: <20090201.150437.100073586.haba@habanero.pdc.kth.se> > We have encountered a strange error here on a volume. vos examine (or fs lq) says that it is 15G in size, > but du can only find 4G in the volume. salvager do not find anything wrong with the volume. Have you told it to reattach orphan files during salvage? You may have salvaging errors. I think there was a bug in the salvager that was fixed in 1.4.8. > Any hints? The fileserver runs 1.4.5 (on RHEL4). Reading the RELNOTES for the later releases > shows nothing about a fix for this problem. Before you run the salvager across the volume, have a look at the file tree on /vicep*. If your volume number is 4711: $ /afs/stacken.kth.se/home/haba/bin/scripts/volid.pl 4711 4711: /vicep?/AFSIDat/b=/b7= that is your tree. How big is that? If you make a tar of that and the V04711 file, you have everything to start over if things go wrong. Don't forget the -p when unpacking the tar, there _is_ info that matters in these bits. Harald. From ragge@ltu.se Sun Feb 1 15:52:59 2009 From: ragge@ltu.se (Anders Magnusson) Date: Sun, 01 Feb 2009 16:52:59 +0100 Subject: [OpenAFS] Volume space "lost in space". In-Reply-To: <20090201.150437.100073586.haba@habanero.pdc.kth.se> References: <498570B7.90100@ltu.se> <20090201.150437.100073586.haba@habanero.pdc.kth.se> Message-ID: <4985C55B.8000202@ltu.se> Harald Barth wrote: >>We have encountered a strange error here on a volume. vos examine (or fs lq) says that it is 15G in size, >>but du can only find 4G in the volume. salvager do not find anything wrong with the volume. >> >> > >Have you told it to reattach orphan files during salvage? > > No, I hadn't. I didn't realize that "bos salvage" didn't complain directly but I needed to do "bos getlog" to see it. But Derrick corrected me :-) -- Ragge >You may have salvaging errors. I think there was a bug in the salvager that was fixed in 1.4.8. > > > >>Any hints? The fileserver runs 1.4.5 (on RHEL4). Reading the RELNOTES for the later releases >>shows nothing about a fix for this problem. >> >> > >Before you run the salvager across the volume, have a look at the file tree on /vicep*. >If your volume number is 4711: > >$ /afs/stacken.kth.se/home/haba/bin/scripts/volid.pl 4711 > 4711: /vicep?/AFSIDat/b=/b7= > >that is your tree. How big is that? If you make a tar of that and the >V04711 file, you have everything to start over if things go wrong. >Don't forget the -p when unpacking the tar, there _is_ info that >matters in these bits. > >Harald. >_______________________________________________ >OpenAFS-info mailing list >OpenAFS-info@openafs.org >https://lists.openafs.org/mailman/listinfo/openafs-info > > From hays@ibiblio.org Sun Feb 1 15:54:37 2009 From: hays@ibiblio.org (hays@ibiblio.org) Date: Sun, 01 Feb 2009 10:54:37 -0500 Subject: [OpenAFS] Stupid NAT routers & UDP keepalive packets Message-ID: <10C7B3B5ADB5E9AD28F23E67@Avatar.local> You could try natkeep, I've got an OSX oriented page with a link to the original source up at: The only advantage it yields, assuming it works for you, is that the packets tapping the port on the nat die there, instead of going all the way back to the servers. --On February 1, 2009 10:50:21 AM -0500 bil wrote: > I guess cronning a 'fs checkservers' for every 2 minutes works well > enough... > > On Thu, Jan 29, 2009 at 01:39:11AM -0600, Ryan C. Underwood wrote: >> >> The standard suggestion to people experiencing AFS disconnections after >> idling on a NAT is to increase the UDP mapping timeout on the router. >> Unfortunately, this is impossible for the majority of idiotic "routers" >> sold in stores with proprietary firmware. Is it possible for the AFS >> client to send a periodic keepalive packet itself for this purpose, >> similar to the OpenSSH client? If I recall correctly, there is even a >> "ping" packet type specified in Rx for this purpose. From jason@rampaginggeek.com Sun Feb 1 15:55:28 2009 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Sun, 01 Feb 2009 10:55:28 -0500 Subject: [OpenAFS] Read-Write Disconnected Mode - How does it work? In-Reply-To: <2CCB90CE-E201-41EC-ADD5-3DCDAB9D23DF@inf.ed.ac.uk> References: <183280.58371.qm@web52209.mail.re2.yahoo.com> <2CCB90CE-E201-41EC-ADD5-3DCDAB9D23DF@inf.ed.ac.uk> Message-ID: <4985C5F0.3080905@rampaginggeek.com> Simon Wilkinson wrote: > I've so far run a number of file system test utilities against > disconnected mode, as well as using it for some day to day work, and a > large number of package builds. I'm not currently aware of any way to > break the current code. There are some additional fixes in CVS, over > the 1.5.57 release, so if you are interested in testing, using the tip > of the 1.5 branch is a good place to start. Hi Simon, How can I build an RPM for Fedora 10 from the 1.5 CVS branch? Thanks, Jason From sxw@inf.ed.ac.uk Sun Feb 1 16:37:37 2009 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Sun, 1 Feb 2009 16:37:37 +0000 Subject: [OpenAFS] Read-Write Disconnected Mode - How does it work? In-Reply-To: <4985C5F0.3080905@rampaginggeek.com> References: <183280.58371.qm@web52209.mail.re2.yahoo.com> <2CCB90CE-E201-41EC-ADD5-3DCDAB9D23DF@inf.ed.ac.uk> <4985C5F0.3080905@rampaginggeek.com> Message-ID: On 1 Feb 2009, at 15:55, Jason Edgecombe wrote: > Simon Wilkinson wrote: >> I've so far run a number of file system test utilities against >> disconnected mode, as well as using it for some day to day work, >> and a large number of package builds. I'm not currently aware of >> any way to break the current code. There are some additional fixes >> in CVS, over the 1.5.57 release, so if you are interested in >> testing, using the tip of the 1.5 branch is a good place to start. > Hi Simon, > > How can I build an RPM for Fedora 10 from the 1.5 CVS branch? The simplest way is to install the 1.5.57 SRPM from /afs/inf.ed.ac.uk/ group/afsbuild/1.5.57/openafs-1.5.57-1.1.1.src.rpm Then replace the src tarball with one obtained from a CVS checkout, and change the release field in the SPEC file to something that indicates the date of that checkout. You can then rebuild the SRPM using the normal rpmbuild commands. Once the patches for bugs 124272 and 124273 (which I've just submitted to make the stuff in the tree match what I'm using for packaging), you'll be able to use the src/packaging/RedHat/makesrpm.pl script to generate a SRPM from a source tree, in the same way as for the 1.4.x branch. S. From steven.jenkins@gmail.com Sun Feb 1 16:42:23 2009 From: steven.jenkins@gmail.com (Steven Jenkins) Date: Sun, 1 Feb 2009 11:42:23 -0500 Subject: [OpenAFS] OpenAFS and Xen wierdnesses: regular loss of afs server connectivity In-Reply-To: <49833A46.4000908@mars.asu.edu> References: <49833A46.4000908@mars.asu.edu> Message-ID: On Fri, Jan 30, 2009 at 12:35 PM, Chris Kurtz wrote: > Specs: > ... > > Jan 30 10:28:48 www4 kernel: afs: Lost contact with volume location > server 149.169.146.57 in cell mars.asu.edu > Jan 30 10:30:03 www4 kernel: afs: volume location server 149.169.146.57 > in cell mars.asu.edu is back up > This isn't the fileserver at all (so the documentation I pointed you to is interesting, but not necessarily relevant), but is the vlserver. Some of the same suggestions apply, though: 1- are the processes crashing? (bos status, logs, etc) 2- are you having quorum issues? (udebug, logs, etc) 3- can you give more resources to the vlservers? For example, are they running on their own VMs? 4- how is your cell configured? (e.g., do you have 3 vlservers) -- Steven Jenkins End Point Corporation http://www.endpoint.com/ From chk@mars.asu.edu Sun Feb 1 20:33:55 2009 From: chk@mars.asu.edu (Chris Kurtz) Date: Sun, 01 Feb 2009 13:33:55 -0700 Subject: [OpenAFS] OpenAFS and Xen wierdnesses: regular loss of afs server connectivity In-Reply-To: References: <49833A46.4000908@mars.asu.edu> Message-ID: <49860733.3000307@mars.asu.edu> Both the guests and hosts are 64bit, and the guests are paravirtualized. The hosts are running ntp from a central clocksource -- I haven't seen any clockdrift. We've seen the io problems, and made changes to eliminate that as much as possible (everything but the bare OS is nfs mounted, and we use nfsv3 with tcp). Nothing is wrong with the afs servers: the haven't crashed, and they continue to serve other non-xen clients with no issues. The afs servers were tuned using that guide and tons of suggestions made at last year's AFS Best Practices Workshop. I'll grab the server config when I get a chance. ...Chris -- Chris Kurtz, chk@mars.asu.edu Systems Manager Mars Space Flight Facility Arizona State University Steven Jenkins wrote: > On Fri, Jan 30, 2009 at 12:35 PM, Chris Kurtz wrote: >> Specs: >> > ... >> Jan 30 10:28:48 www4 kernel: afs: Lost contact with volume location >> server 149.169.146.57 in cell mars.asu.edu >> Jan 30 10:30:03 www4 kernel: afs: volume location server 149.169.146.57 >> in cell mars.asu.edu is back up >> > > This isn't the fileserver at all (so the documentation I pointed you > to is interesting, but not necessarily relevant), but is the vlserver. > Some of the same suggestions apply, though: > > 1- are the processes crashing? (bos status, logs, etc) > 2- are you having quorum issues? (udebug, logs, etc) > 3- can you give more resources to the vlservers? For example, are > they running on their own VMs? > 4- how is your cell configured? (e.g., do you have 3 vlservers) > From jason@rampaginggeek.com Mon Feb 2 01:48:59 2009 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Sun, 01 Feb 2009 20:48:59 -0500 Subject: [OpenAFS] Read-Write Disconnected Mode - How does it work? In-Reply-To: References: <183280.58371.qm@web52209.mail.re2.yahoo.com> <2CCB90CE-E201-41EC-ADD5-3DCDAB9D23DF@inf.ed.ac.uk> <4985C5F0.3080905@rampaginggeek.com> Message-ID: <4986510B.5080006@rampaginggeek.com> Simon Wilkinson wrote: > > On 1 Feb 2009, at 15:55, Jason Edgecombe wrote: > >> Simon Wilkinson wrote: >>> I've so far run a number of file system test utilities against >>> disconnected mode, as well as using it for some day to day work, and >>> a large number of package builds. I'm not currently aware of any way >>> to break the current code. There are some additional fixes in CVS, >>> over the 1.5.57 release, so if you are interested in testing, using >>> the tip of the 1.5 branch is a good place to start. >> Hi Simon, >> >> How can I build an RPM for Fedora 10 from the 1.5 CVS branch? > > The simplest way is to install the 1.5.57 SRPM from > /afs/inf.ed.ac.uk/group/afsbuild/1.5.57/openafs-1.5.57-1.1.1.src.rpm > Then replace the src tarball with one obtained from a CVS checkout, > and change the release field in the SPEC file to something that > indicates the date of that checkout. You can then rebuild the SRPM > using the normal rpmbuild commands. > > Once the patches for bugs 124272 and 124273 (which I've just submitted > to make the stuff in the tree match what I'm using for packaging), > you'll be able to use the src/packaging/RedHat/makesrpm.pl script to > generate a SRPM from a source tree, in the same way as for the 1.4.x > branch. I had some trouble with discon mode. I compiled an RPM from the 1_5 branch in CVS. I can "find . -type f | cat > /dev/null", then I can fs discon offline. Problems that I had: * ls couldn't find "."; reconnecting and disconnecting fixed it. * I tried running my newtests perl scripts, but that failed with some perl errors. * vi complained of multiple swap files when trying to edit the config file for my test suite. * fs discon online said I didn't have the proper permissions when run as root. * "fs discon online -force" made AFS freeze Here is my dmesg output: openafs: module license 'http://www.openafs.org/dl/license10.html' taints kernel. Symbol init_mm is marked as UNUSED, however this module is using it. This symbol will go away in the future. Please evalute if this is the right api to use and if it really is, submit a report the linux kernel mailinglist together with submitting your code for inclusion. Warning: Unable to find the address of authtab NFS Translator hooks will not be installed To correct, specify authtab_addr= Found system call table at 0xfffffffffffffffe (exported) Address 0xfffffffffffffffe is not writable. System call hooks will not be installed; proceeding anyway Found 32-bit system call table at 0xfffffffffffffffe (exported) Address 0xfffffffffffffffe is not writable. System call hooks will not be installed; proceeding anyway Starting AFS cache scan...found 14 non-empty cache files (0%). SELinux: initialized (dev afs, type afs), uses genfs_contexts IPv6 over IPv4 tunneling driver sit0: Disabled Privacy Extensions e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None ADDRCONF(NETDEV_UP): eth0: link is not ready ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready eth0: no IPv6 routers present WARM shutting down of: CB... afs... BkG... CTrunc... AFSDB... RxEvent... UnmaskRxkSignals... RxListener... WARNING: not all blocks freed: large 1 small 4 ALL allocated tables Symbol init_mm is marked as UNUSED, however this module is using it. This symbol will go away in the future. Please evalute if this is the right api to use and if it really is, submit a report the linux kernel mailinglist together with submitting your code for inclusion. Warning: Unable to find the address of authtab NFS Translator hooks will not be installed To correct, specify authtab_addr= Found system call table at 0xffffffff8133f640 (pattern scan) Address 0xffffffff8133f640 is not writable. System call hooks will not be installed; proceeding anyway Warning: failed to find address of 32-bit system call table System call hooks will not be installed; proceeding anyway Starting AFS cache scan...found 14 non-empty cache files (0%). SELinux: initialized (dev afs, type afs), uses genfs_contexts Sync succeeded. You are back online. Network is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCache Sync succeeded. You are back online. Network is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNot allowed yet. Not allowed yet. Network is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheNetwork is down in afs_GetCacheafs_ProcessOpCreate: error while creating vnode on server, code=49733388 . Files not synchronized properly, still in discon state. Please retry or use "force". afs_ProcessOpCreate: error while creating vnode on server, code=49733388 . Files not synchronized properly, still in discon state. Please retry or use "force". afs_ProcessOpCreate: error while creating vnode on server, code=49733388 . Sincerely, Jason From sxw@inf.ed.ac.uk Mon Feb 2 08:28:37 2009 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Mon, 2 Feb 2009 08:28:37 +0000 Subject: [OpenAFS] Read-Write Disconnected Mode - How does it work? In-Reply-To: <4986510B.5080006@rampaginggeek.com> References: <183280.58371.qm@web52209.mail.re2.yahoo.com> <2CCB90CE-E201-41EC-ADD5-3DCDAB9D23DF@inf.ed.ac.uk> <4985C5F0.3080905@rampaginggeek.com> <4986510B.5080006@rampaginggeek.com> Message-ID: <48D82508-F92F-4498-92F6-44517BDE38A3@inf.ed.ac.uk> On 2 Feb 2009, at 01:48, Jason Edgecombe wrote: > I had some trouble with discon mode. I compiled an RPM from the 1_5 > branch in CVS. I can "find . -type f | cat > /dev/null", then I can > fs discon offline. Problems that I had: > * ls couldn't find "."; reconnecting and disconnecting fixed it This suggests that you didn't cache the directory - either it was skipped by the find, or the callback on it had been expired by the time you went offline. Pinning should solve these kinds of issues. > * I tried running my newtests perl scripts, but that failed with > some perl errors. Were these issues related to the filesystem, or other problems? Are those tests available somewhere? > * vi complained of multiple swap files when trying to edit the > config file for my test suite. Odd. Can you get an fstrace log of what vi was trying to do when it complained - I can vi whilst disconnected without any problem. > * fs discon online said I didn't have the proper permissions when > run as root. Did you have tokens? The error code you're getting is UAEACCES, which suggests not. > * "fs discon online -force" made AFS freeze Again, strange. Did you get cmdebug -long output to see if it's hung on a lock, or alt-sysreq-t output to see where each process is blocked? Thanks, Simon. From lw@lwilke.de Mon Feb 2 10:03:55 2009 From: lw@lwilke.de (Lars Wilke) Date: Mon, 2 Feb 2009 11:03:55 +0100 Subject: [OpenAFS] move RO volume Message-ID: <20090202100355.GA30884@ckLennard.net.home> Hi, Just a quick question, is it correct, that it is not possible to move a RO volume from one partition to another partition on the *same* server without doing a vos remove, addsite, release? Using OAFS 1.4.7. Thanks --lars From l.schimmer@cgv.tugraz.at Mon Feb 2 10:38:31 2009 From: l.schimmer@cgv.tugraz.at (Lars Schimmer) Date: Mon, 02 Feb 2009 11:38:31 +0100 Subject: [OpenAFS] problem with OpenAFS client 1.5.57 on windows Message-ID: <4986CD27.9060502@cgv.tugraz.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Just encounterd a problem with 1.5.57 (and 1.5.56) client on windows. On a special RO volume, the explorer hangs forever and I need to kill the explorer to work again on that PC. That behaviour is consistant over reboot of client, upgrade von 1.5.56 to 1.5.57 OpenAFS client and delete cache and restart OpenAFS client. I can reach that special path via linux clien 1.4.7 without problems. I tried to do afsd log and minidump while explorer hung: http://aceini.no-ip.info/afs/afsd.log.020209 http://aceini.no-ip.info/afs/afs.dmp.020209 Any idea? Bug? MfG, Lars Schimmer - -- - ------------------------------------------------------------- TU Graz, Institut f=FCr ComputerGraphik & WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schimmer@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmGzScACgkQmWhuE0qbFyM5TwCdGq8qvLJs3skwxUu7/OiUMVz8 4kAAnRqDcC3nXq4vV9aFzLjppf5D/t7o =3DZyH5 -----END PGP SIGNATURE----- From vishnuramv@gmail.com Mon Feb 2 13:25:17 2009 From: vishnuramv@gmail.com (Vishnu Ram) Date: Mon, 2 Feb 2009 18:55:17 +0530 Subject: [OpenAFS] Client machine hangs after OpenAFS server restart! Message-ID: --0016e64af2ae5524dd0461ef7c4e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I've set up OpenAFS server and client on two different machines, with CentOS 5.2 as the operating system. I'm using OpenAFS for mounting the user home directories. I could login and work with the mounted home directory, but the client machine hangs after I restart the OpenAFS server. The client machine hangs completely and only option is to do a hard reboot. I use applications such as kmail, firefox, openoffice, etc. in the client machine. My objective is to setup highly available user home directories with OpenAFS. Regards, Vishnu --0016e64af2ae5524dd0461ef7c4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I've set up OpenAFS server and client on two different machines, with CentOS 5.2 as the operating system.
I'm using OpenAFS for mounting the user home directories. I could login and work with the mounted home directory, but
the client machine hangs after I restart the OpenAFS server.  The client machine hangs completely and only option is to do a hard reboot. I use applications such as kmail, firefox, openoffice, etc. in the client machine.
My objective is to setup highly available user home directories with OpenAFS.

Regards,
Vishnu
--0016e64af2ae5524dd0461ef7c4e-- From cristina.bulfon@roma1.infn.it Mon Feb 2 14:13:44 2009 From: cristina.bulfon@roma1.infn.it (Cristina Bulfon) Date: Mon, 2 Feb 2009 15:13:44 +0100 Subject: [OpenAFS] AFS FileServer and Heartbeat Message-ID: <090B647A-D08C-42D1-8493-B9FF66B3D98E@roma1.infn.it> --Apple-Mail-9--273729332 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello, We'd like to configure AFS Fileserver using heartbeat in active/ passive mode. The servers have been installed using the Big Box Linux ES46 (based on RedHat) with OpenAFS 1.4.7, heartbeat 2.1.3 and DRBD 8.3.0. The test layout consists of two servers and two partitions ( one is / vicepa and the other is /usr/afs). The disk/partitons are visible through the SAN on both servers and DRBD takes care about that. On the heartbeat side we have the following haresource file afsitfs3.roma1.infn.it IPaddr2::Y.Y.Y.Y/24/eth0:0 afsitfs3.roma1.infn.it drbddisk::r0 Filesystem::/dev/drbd1::/ vicepa::xfs afsitfs3.roma1.infn.it drbddisk::r1 Filesystem::/dev/drbd2::/usr/ afs::ext3 afsitfs3.roma1.infn.it Y.Y.Y.Y afs On the afs side we've also configured the NetInfo and the NetRestrict file, in the NetInfo we put the IP address stored on VLDB server ( in this case Y.Y.Y.Y) while in the NetRestrict put the IP addresses of the two servers. The problem is that everything is working fine inside the LAN but If I try to execute a simple command like "ls" from outiside the LAN I got Connection Timed Out If we look at the FileLog file we saw that the Fileserver takes the IP and hostname as the real server instead of the virtual one. .... Mon Feb 2 13:18:37 2009 FileServer host name is 'afsitfs3.roma1.infn.it Mon Feb 2 13:18:37 2009 FileServer afsitfs3.roma1.infn.it has address 141.108.26.29 (0x1d1a6c8d or 0x8d6c1a1d in host byte order) ..... We really appreciate any suggestion for solving the problem Thanks in advance cristina --Apple-Mail-9--273729332 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
The servers have been = installed using the Big Box Linux ES46 (based on RedHat) with = OpenAFS 1.4.7, heartbeat 2.1.3 and DRBD = 8.3.0.

The test = layout consists of two servers and two partitions ( one is = /vicepa and the other is /usr/afs). The disk/partitons are visible = through the SAN on both servers and DRBD takes care = about that.

On the heartbeat side we have the following = haresource file

afsitfs3.roma1.infn.it =  IPaddr2::Y.Y.Y.Y/24/eth0:0
afsitfs3.roma1.infn.it =  drbddisk::r0 =  Filesystem::/dev/drbd1::/vicepa::xfs
afsitfs3.roma1.infn.it =  drbddisk::r1 =  Filesystem::/dev/drbd2::/usr/afs::ext3
afsitfs3.roma1.infn.it =         Y.Y.Y.Y =   afs

On the afs side we've also configured the NetInfo = and the NetRestrict file, the NetInfo we = put the IP address stored on VLDB server ( in = this case Y.Y.Y.Y) while in the NetRestrict put the = IP addresses of the two = servers.

The problem is that everything is = working fine inside the LAN  but If I try to execute a simple = command like "ls"  from outiside the LAN I got

Connection = Timed Out

If we look at the FileLog file we saw that the = Fileserver takes the IP and hostname as the real server = instead of the = virtual one.
....
Mon Feb  2 13:18:37 = 2009 FileServer host name is = 'afsitfs3.roma1.infn.it
Mon Feb  2 13:18:37 = 2009 FileServer afsitfs3.roma1.infn.it has address 141.108.26.29 = (0x1d1a6c8d or 0x8d6c1a1d in host byte = order)
.....
We really appreciate any suggestion for solving = the problem

Thanks in = advance

cristina
= --Apple-Mail-9--273729332-- From jaltman@secure-endpoints.com Mon Feb 2 14:52:59 2009 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 02 Feb 2009 06:52:59 -0800 Subject: [OpenAFS] problem with OpenAFS client 1.5.57 on windows In-Reply-To: <4986CD27.9060502@cgv.tugraz.at> References: <4986CD27.9060502@cgv.tugraz.at> Message-ID: <498708CB.3010305@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms040205000601070701090902 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit What can you tell us about the directory that you cannot read? Lars Schimmer wrote: > Hi! > > Just encounterd a problem with 1.5.57 (and 1.5.56) client on windows. > On a special RO volume, the explorer hangs forever and I need to kill > the explorer to work again on that PC. > That behaviour is consistant over reboot of client, upgrade von 1.5.56 > to 1.5.57 OpenAFS client and delete cache and restart OpenAFS client. > > I can reach that special path via linux clien 1.4.7 without problems. > > I tried to do afsd log and minidump while explorer hung: > http://aceini.no-ip.info/afs/afsd.log.020209 > http://aceini.no-ip.info/afs/afs.dmp.020209 > > Any idea? Bug? > > MfG, > Lars Schimmer _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info --------------ms040205000601070701090902 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 AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw 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 OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAyMDIxNDUyNTlaMCMGCSqGSIb3DQEJBDEWBBRfusAv l4/06Eu5VWzTj4Z4aydfbDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAGNC+3GS66c7A0z6YK3k3GfMq1G7LVEL9pXDonXfGqEU7gAz1JMWR cbQan467zc9pGIS3s0obHGCWhmytGZRtWyBDH7fDWsrnjKIfBfv9kWASclTwv+bnVilpECZZ YETCPaTdSAWBAtBd5k4b+JA/ogGMnnVr2dF2iqPTWBfTnX3NOd8gf8gL8gGxv2KXKLn8FDhQ QlraqjfgJCMERL/BFeW31U5mZWxDNI7+RGhHL7FowniGcuWv6H6Ppuis19bI8tfzAKAu6i0j hoHB2Z+4i/gWsmuRYC6KCJDNa2YM+bfD4dfmCDeAibQi8AfBHnH4ND5peGKvCMy1rRFg6DpI JQAAAAAAAA== --------------ms040205000601070701090902-- From jaltman@secure-endpoints.com Mon Feb 2 15:00:51 2009 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 02 Feb 2009 07:00:51 -0800 Subject: [OpenAFS] problem with OpenAFS client 1.5.57 on windows In-Reply-To: <4986CD27.9060502@cgv.tugraz.at> References: <4986CD27.9060502@cgv.tugraz.at> Message-ID: <49870AA3.7010403@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms070403050002080003040109 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit What is the volume that you cannot reach? any chance it is cgv.tugraz.at:cgdata.epoch.gipsmu10 or cgv.tugraz.at:eg.egorg.old? Server 129.27.218.32 reported volume 1702194132 as not attached (does not exist). Server 129.27.218.31 reported volume 1702194473 as not attached (does not exist). It does look like there is a bug here as the requests never appear to be timing out. Jeffrey Altman Lars Schimmer wrote: > Hi! > > Just encounterd a problem with 1.5.57 (and 1.5.56) client on windows. > On a special RO volume, the explorer hangs forever and I need to kill > the explorer to work again on that PC. > That behaviour is consistant over reboot of client, upgrade von 1.5.56 > to 1.5.57 OpenAFS client and delete cache and restart OpenAFS client. > > I can reach that special path via linux clien 1.4.7 without problems. > > I tried to do afsd log and minidump while explorer hung: > http://aceini.no-ip.info/afs/afsd.log.020209 > http://aceini.no-ip.info/afs/afs.dmp.020209 > > Any idea? Bug? > > MfG, > Lars Schimmer _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info --------------ms070403050002080003040109 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 AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw 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 OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAyMDIxNTAwNTFaMCMGCSqGSIb3DQEJBDEWBBSWb4jZ hxK1qCVYXAwaKbCIR1mzAjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAM91mZgseBPYHWSx2qLxj7klrhHY9P0NIT2zFs6bDhrggHuEn1zRY FKLUUvGI/kDlE1SwqtPH75+GQMCxpOqPVOGlMeSG7K0uWjNAhCd8tiHW8nnvPjEzeIWpTEYA hqBUdFaYL3TxcbZ1fKBkXRvqOa2lSpGDabDs8YH2e5dRELQbXmz71HR9PbB3PUOTjHWEHE1Y 6Q1XiWZliNqfCz4M9kDdBoQe6llxvdJaWaPAftgdNnUX4tNf2fpotnOSV7Wax+1MTmQvk1eh qy0OrqOPKwLZYNUsAsUT0j1LfKyJ4dm4Xsn5MZWM74HNJ9vK4IF91Jx3KMTs+GdpN+pApxiv KgAAAAAAAA== --------------ms070403050002080003040109-- From afs@freakout.de Mon Feb 2 15:05:19 2009 From: afs@freakout.de (Axel Reinhold) Date: Mon, 2 Feb 2009 16:05:19 +0100 Subject: [OpenAFS] samba 3.3.0 fake-kaserver no more working In-Reply-To: <4982D329.2020103@kzsdabas.hu> Message-ID: <200902021505.n12F5Jlv012622@bongo.freakout.de> --ELM1233493290-7118-0_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" According to G=E9mes G=E9za: > > First of all I'm surprised 3.2.7's fake-kaserver was working. For 3.2.5 > (with openafs 1.4.7) I had to create a patch (attached). > Could that help you at least at finding out what did change. >=20 Dear Gemes, I also patch'd 3.2.7 with similar patches all integrated into a rpm-spec-file. I attach the 3.2.7 (last stable 3.2 samba) and 3.3.0 (first stable 3.3 samba) spec files. I always install into /opt. So afs ends in /opt/afs and samba in /opt/samba. 3.2.7 is working fine and 3.3.0 cores as described. The diff between the two are: 4c4 < Version: 3.3.0 --- > Version: 3.2.7 29c29 < $Id: samba.spec,v 1.73 2009/02/01 12:54:24 axel Exp $ --- > $Id: samba.spec,v 1.72 2009/01/30 11:57:28 axel Exp $ 151,153c151,153 < --- source/configure.in.orig 2009-01-28 12:07:51.000000000 +0100 < +++ source/configure.in 2009-01-28 12:10:56.000000000 +0100 < @@ -100,6 +100,7 @@ --- > --- source/configure.in.orig Sat Jun 16 12:29:54 2007 > +++ source/configure.in Sat Jun 16 13:30:55 2007 > @@ -294,6 +294,7 @@ 158d157 < AC_SUBST(GPEXT_LIBS) 161c160,161 < @@ -2979,6 +2980,7 @@ --- > AC_SUBST(UNINSTALL_PAM_MODULES) > @@ -3078,6 +3079,7 @@ 169c169 < @@ -2989,6 +2991,7 @@ --- > @@ -3086,6 +3088,7 @@ 177,178c177,178 < @@ -6283,6 +6286,7 @@ < AC_MSG_RESULT([ DNSSD_LIBS =3D $DNSSD_LIBS]) --- > @@ -6199,6 +6202,7 @@ > AC_MSG_RESULT([ UUID_LIBS =3D $UUID_LIBS]) 205,217d204 < --- source/lib/afs.c.orig 2009-01-28 09:39:02.000000000 +0100 < +++ source/lib/afs.c 2009-01-28 09:40:37.000000000 +0100 < @@ -230,8 +230,8 @@ < } < =20 < afs_username =3D talloc_sub_advanced(ctx, < - SNUM(conn), conn->user, < - conn->connectpath, conn->gid, < + SNUM(conn), conn->server_info->utok.uid, < + conn->connectpath, conn->server_info->utok.gid, < conn->server_info->sanitized_username, < pdb_get_domain(conn->server_info->sam_account), < afs_username); Regards Axel --=20 |------------------------+--------------------------------------| | Axel Reinhold | Fax: +49-9287-8244 | | Franz-Heinrich-Str. 20 | eMail: axel@freakout.de | | 95100 Selb +-----+ http://www.freakout.de | | Germany | Please do not send more than 100 kilobytes | |------------------+--------------------------------------------| | Fingerprint: 8D EF 9F 22 DF 9A 9B 68 E5 8C 12 C7 8D 6A 97 4E | |---------------------------------------------------------------| | Legal Warning: Do NOT send unsolicited commercial email to me | | I will _NOT_ open Office/.EXE files =3D> please send plain text | --ELM1233493290-7118-0_ Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Disposition: attachment; filename="samba-3.2.7.spec" Content-Description: Summary: the Samba SMB server Name: samba Group: System Environment/Daemons Version: 3.2.7 Release: 1 URL: http://www.samba.org/ L #define samba1 3.2.0 %define samba1 %{version} #define samba2 a %define samba2 %{?_not_exist} %define sambagcc gcc41 Provides: samba Requires: ssl afs Source0: ftp://us2.samba.org/pub/samba/%{name}-%{samba1}.tar.gz %description Samba is the protocol by which a lot of PC-related machines share files, printers, and other information (such as lists of available files and printers). The Windows NT, OS/2, and Linux operating systems support this natively, and add-on packages can enable the same thing for DOS, Windows, VMS, UNIX of all kinds, MVS, and more. This package provides an SMB server that can be used to provide network services to SMB (sometimes called "Lan Manager") clients. Samba uses NetBIOS over TCP/IP (NetBT) protocols and does NOT need the NetBEUI (Microsoft Raw NetBIOS frame) protocol. $Id: samba.spec,v 1.72 2009/01/30 11:57:28 axel Exp $ %prep test "$RPMX" = "3" || false need rh7 test -d /usr/include/afs || false need ln -s /opt/afs/include /usr/include/afs test -d /usr/include/openssl || false need ln -s /opt/ssl/include/openssl /usr/include/openssl %setup -q -n %{name}-%{samba1} for P in `/home/axel/p/rpm/count.sh %{samba2}`; do patch -p1 <%{_sourcedir}/patch-%{samba1}`/home/axel/p/rpm/count.sh -d $P`-%{samba1}${P}.diffs done cp -p source/script/installswat.sh source/script/installswat.sh.orig sed 's/BOOKDIR="\$DESTDIR\/\$SWATDIR/BOOKDIR="$DESTDIR\/$SWATDIR\/help/' \ source/script/installswat.sh patch -b -p1 <<'EOF' --- samba-3.2.5.orig/source/lib/afs.c 2008-12-21 20:55:53.000000000 +0100 +++ samba-3.2.5/source/lib/afs.c 2008-12-23 07:27:15.000000000 +0100 @@ -23,6 +23,7 @@ #define NO_ASN1_TYPEDEFS 1 +#include #include #include #include diff -urN samba-3.2.5.orig/source/lib/afs_settoken.c samba-3.2.5/source/lib/afs_settoken.c --- samba-3.2.5.orig/source/lib/afs_settoken.c 2008-12-21 20:55:53.000000000 +0100 +++ samba-3.2.5/source/lib/afs_settoken.c 2008-12-23 07:36:56.000000000 +0100 @@ -23,6 +23,7 @@ #define NO_ASN1_TYPEDEFS 1 +#include #include #include #include @@ -37,7 +38,24 @@ char * cmarg, int follow) { +/* return( syscall( SYS_afs_syscall, subcall, path, cmd, cmarg, follow)); +*/ + int errcode; + struct afsprocdata afs_syscall_data; + afs_syscall_data.syscall = subcall; + afs_syscall_data.param1 = (long)path; + afs_syscall_data.param2 = cmd; + afs_syscall_data.param3 = (long)cmarg; + afs_syscall_data.param4 = follow; + int proc_afs_file = open(PROC_SYSCALL_FNAME, O_RDWR); + if (proc_afs_file < 0) + proc_afs_file = open(PROC_SYSCALL_ARLA_FNAME, O_RDWR); + if (proc_afs_file < 0) + return -1; + errcode = ioctl(proc_afs_file, VIOC_SYSCALL, &afs_syscall_data); + close(proc_afs_file); + return errcode; } struct ClearToken { --- samba-3.2.3.orig/source/modules/vfs_afsacl.c 2008-08-27 13:23:20.000000000 +0200 +++ samba-3.2.3/source/modules/vfs_afsacl.c 2008-09-26 21:15:08.956586527 +0200 @@ -22,6 +22,7 @@ #undef DBGC_CLASS #define DBGC_CLASS DBGC_VFS +#include #include #include #include EOF patch -b -p0 <<'EOF' --- source/Makefile.in.orig Tue Aug 5 08:22:33 2008 +++ source/Makefile.in Thu Aug 7 11:17:34 2008 @@ -74,6 +74,7 @@ LIBTALLOC_LIBS=@LIBTALLOC_LIBS@ LIBTDB_LIBS=@LIBTDB_LIBS@ LIBNETAPI_LIBS=@LIBNETAPI_LIBS@ +AFS_LIBS=@AFS_LIBS@ INSTALLCMD=@INSTALL@ INSTALLLIBCMD_SH=@INSTALLLIBCMD_SH@ @@ -1337,7 +1338,7 @@ $(KRB5LIBS) $(DYNEXP) $(PRINT_LIBS) $(AUTH_LIBS) \ $(ACL_LIBS) $(PASSDB_LIBS) $(LIBS) $(DNSSD_LIBS) \ $(POPT_LIBS) @SMBD_LIBS@ $(LIBTALLOC_LIBS) $(LIBTDB_LIBS) \ - $(WINBIND_LIBS) + $(WINBIND_LIBS) $(AFS_LIBS) bin/nmbd@EXEEXT@: $(BINARY_PREREQS) $(NMBD_OBJ) @BUILD_POPT@ @LIBTALLOC_SHARED@ @LIBTDB_SHARED@ @echo Linking $@ @@ -1349,7 +1350,7 @@ @echo Linking $@ @$(CC) $(FLAGS) -o $@ $(SWAT_OBJ) $(LDFLAGS) $(DYNEXP) $(PRINT_LIBS) \ $(AUTH_LIBS) $(LIBS) $(PASSDB_LIBS) $(POPT_LIBS) $(KRB5LIBS) \ - $(LDAP_LIBS) $(LIBTALLOC_LIBS) $(LIBTDB_LIBS) $(WINBIND_LIBS) + $(LDAP_LIBS) $(LIBTALLOC_LIBS) $(LIBTDB_LIBS) $(WINBIND_LIBS) $(AFS_LIBS) bin/rpcclient@EXEEXT@: $(BINARY_PREREQS) $(RPCCLIENT_OBJ) @BUILD_POPT@ @LIBTALLOC_SHARED@ @LIBTDB_SHARED@ @LIBWBCLIENT_SHARED@ @echo Linking $@ @@ -1369,7 +1370,7 @@ @echo Linking $@ @$(CC) $(FLAGS) -o $@ $(NET_OBJ) $(DYNEXP) $(LDFLAGS) $(LIBS) \ $(POPT_LIBS) $(KRB5LIBS) $(UUID_LIBS) $(LDAP_LIBS) \ - $(PASSDB_LIBS) $(TERMLDFLAGS) $(TERMLIBS) $(NSCD_LIBS) \ + $(PASSDB_LIBS) $(AFS_LIBS) $(TERMLDFLAGS) $(TERMLIBS) $(NSCD_LIBS) \ @INIPARSERLIBS@ $(LIBTALLOC_LIBS) $(LIBTDB_LIBS) $(WINBIND_LIBS) $(LIBNETAPI_LIBS) bin/profiles@EXEEXT@: $(BINARY_PREREQS) $(PROFILES_OBJ) @BUILD_POPT@ @LIBTALLOC_SHARED@ @LIBTDB_SHARED@ @@ -1767,7 +1768,7 @@ @echo "Linking $@" @$(CC) $(FLAGS) -o $@ $(WINBINDD_OBJ) $(LDFLAGS) $(DYNEXP) $(LIBS) \ $(POPT_LIBS) $(KRB5LIBS) $(LDAP_LIBS) \ - $(PASSDB_LIBS) $(LIBTALLOC_LIBS) $(LIBTDB_LIBS) $(WINBIND_LIBS) + $(PASSDB_LIBS) $(LIBTALLOC_LIBS) $(LIBTDB_LIBS) $(WINBIND_LIBS) $(AFS_LIBS) bin/vlp@EXEEXT@: $(BINARY_PREREQS) $(VLP_OBJ) @LIBTALLOC_SHARED@ @LIBTDB_SHARED@ @LIBWBCLIENT_SHARED@ @echo "Linking $@" --- source/configure.in.orig Sat Jun 16 12:29:54 2007 +++ source/configure.in Sat Jun 16 13:30:55 2007 @@ -294,6 +294,7 @@ AC_SUBST(KRB5_LIBS) AC_SUBST(UUID_LIBS) AC_SUBST(LDAP_LIBS) +AC_SUBST(AFS_LIBS) AC_SUBST(PAM_MODULES) AC_SUBST(INSTALL_PAM_MODULES) AC_SUBST(UNINSTALL_PAM_MODULES) @@ -3078,6 +3079,7 @@ ################################################# # decide whether we can support WITH_AFS and / or WITH_FAKE_KASERVER +AFS_LIBS="" if test x"$samba_cv_WITH_AFS" != x"no" || test x"$samba_cv_WITH_FAKE_KASERVER" != x"no"; then @@ -3086,6 +3088,7 @@ if test -d /usr/include/afs; then CFLAGS="$CFLAGS -I/usr/include/afs" CPPFLAGS="$CPPFLAGS -I/usr/include/afs" + AFS_LIBS="-L/usr/lib/afs -lafsauthent -lafsrpc -lpthread -lcrypto" AC_MSG_RESULT(yes) else AC_MSG_RESULT(no) @@ -6199,6 +6202,7 @@ AC_MSG_RESULT([ UUID_LIBS = $UUID_LIBS]) fi AC_MSG_RESULT([ AUTH_LIBS = $AUTH_LIBS]) +AC_MSG_RESULT([ AFS_LIBS = $AFS_LIBS]) ################################################# # final configure stuff --- source/modules/vfs_afsacl.c Wed Jan 11 15:05:28 2006 +++ source/modules/vfs_afsacl.c Sat Jan 14 11:19:34 2006 @@ -311,6 +311,7 @@ static BOOL unparse_afs_acl(struct afs_acl *acl, char *acl_str) { + struct afs_ace *ace; /* TODO: String length checks!!!! */ int positives = 0; @@ -318,8 +319,7 @@ fstring line; *acl_str = 0; - - struct afs_ace *ace = acl->acelist; + ace = acl->acelist; while (ace != NULL) { if (ace->positive) EOF %build cd source CC=%{sambagcc} \ LDFLAGS="-Wl,-rpath,%{_prefix}/lib" \ /configure \ --prefix=%{_prefix} \ --with-privatedir=/etc/samba \ --with-lockdir=/var/samba/locks \ --with-swatdir=%{_prefix}/swat \ --with-configdir=/etc/samba \ --with-modulesdir=%{_prefix}/lib/modules \ --sharedstatedir=/var/samba \ --localstatedir=/var/samba \ --datarootdir=%{_prefix} \ --with-pam \ --with-fake-kaserver \ --with-vfs-afsacl \ --with-libsmbclient \ --with-quotas \ --enable-shared \ --enable-shared-libs cp -p Makefile Makefile.orig sed 's/-Wl,-Bsymbolic//' Makefile make cd .. %install [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT%{_prefix} cd source make install DESTDIR=$RPM_BUILD_ROOT cd .. ( cd $RPM_BUILD_ROOT%{_prefix}/lib ln -s libtalloc.so libtalloc.so.1 ln -s libtdb.so libtdb.so.1 ln -s libwbclient.so libwbclient.so.0 ) install -d $RPM_BUILD_ROOT%{_docdir} install -d $RPM_BUILD_ROOT%{_docdir}/registry install docs/Samba*.pdf $RPM_BUILD_ROOT%{_docdir} install docs/registry/*.reg $RPM_BUILD_ROOT%{_docdir}/registry strip $RPM_BUILD_ROOT%{_prefix}/*bin/* || true rm -rf $RPM_BUILD_ROOT/{etc,var} --ELM1233493290-7118-0_ Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Disposition: attachment; filename="samba-3.3.0.spec" Content-Description: Summary: the Samba SMB server Name: samba Group: System Environment/Daemons Version: 3.3.0 Release: 1 URL: http://www.samba.org/ L #define samba1 3.2.0 %define samba1 %{version} #define samba2 a %define samba2 %{?_not_exist} %define sambagcc gcc41 Provides: samba Requires: ssl afs Source0: ftp://us2.samba.org/pub/samba/%{name}-%{samba1}.tar.gz %description Samba is the protocol by which a lot of PC-related machines share files, printers, and other information (such as lists of available files and printers). The Windows NT, OS/2, and Linux operating systems support this natively, and add-on packages can enable the same thing for DOS, Windows, VMS, UNIX of all kinds, MVS, and more. This package provides an SMB server that can be used to provide network services to SMB (sometimes called "Lan Manager") clients. Samba uses NetBIOS over TCP/IP (NetBT) protocols and does NOT need the NetBEUI (Microsoft Raw NetBIOS frame) protocol. $Id: samba.spec,v 1.73 2009/02/01 12:54:24 axel Exp $ %prep test "$RPMX" = "3" || false need rh7 test -d /usr/include/afs || false need ln -s /opt/afs/include /usr/include/afs test -d /usr/include/openssl || false need ln -s /opt/ssl/include/openssl /usr/include/openssl %setup -q -n %{name}-%{samba1} for P in `/home/axel/p/rpm/count.sh %{samba2}`; do patch -p1 <%{_sourcedir}/patch-%{samba1}`/home/axel/p/rpm/count.sh -d $P`-%{samba1}${P}.diffs done cp -p source/script/installswat.sh source/script/installswat.sh.orig sed 's/BOOKDIR="\$DESTDIR\/\$SWATDIR/BOOKDIR="$DESTDIR\/$SWATDIR\/help/' \ source/script/installswat.sh patch -b -p1 <<'EOF' --- samba-3.2.5.orig/source/lib/afs.c 2008-12-21 20:55:53.000000000 +0100 +++ samba-3.2.5/source/lib/afs.c 2008-12-23 07:27:15.000000000 +0100 @@ -23,6 +23,7 @@ #define NO_ASN1_TYPEDEFS 1 +#include #include #include #include diff -urN samba-3.2.5.orig/source/lib/afs_settoken.c samba-3.2.5/source/lib/afs_settoken.c --- samba-3.2.5.orig/source/lib/afs_settoken.c 2008-12-21 20:55:53.000000000 +0100 +++ samba-3.2.5/source/lib/afs_settoken.c 2008-12-23 07:36:56.000000000 +0100 @@ -23,6 +23,7 @@ #define NO_ASN1_TYPEDEFS 1 +#include #include #include #include @@ -37,7 +38,24 @@ char * cmarg, int follow) { +/* return( syscall( SYS_afs_syscall, subcall, path, cmd, cmarg, follow)); +*/ + int errcode; + struct afsprocdata afs_syscall_data; + afs_syscall_data.syscall = subcall; + afs_syscall_data.param1 = (long)path; + afs_syscall_data.param2 = cmd; + afs_syscall_data.param3 = (long)cmarg; + afs_syscall_data.param4 = follow; + int proc_afs_file = open(PROC_SYSCALL_FNAME, O_RDWR); + if (proc_afs_file < 0) + proc_afs_file = open(PROC_SYSCALL_ARLA_FNAME, O_RDWR); + if (proc_afs_file < 0) + return -1; + errcode = ioctl(proc_afs_file, VIOC_SYSCALL, &afs_syscall_data); + close(proc_afs_file); + return errcode; } struct ClearToken { --- samba-3.2.3.orig/source/modules/vfs_afsacl.c 2008-08-27 13:23:20.000000000 +0200 +++ samba-3.2.3/source/modules/vfs_afsacl.c 2008-09-26 21:15:08.956586527 +0200 @@ -22,6 +22,7 @@ #undef DBGC_CLASS #define DBGC_CLASS DBGC_VFS +#include #include #include #include EOF patch -b -p0 <<'EOF' --- source/Makefile.in.orig Tue Aug 5 08:22:33 2008 +++ source/Makefile.in Thu Aug 7 11:17:34 2008 @@ -74,6 +74,7 @@ LIBTALLOC_LIBS=@LIBTALLOC_LIBS@ LIBTDB_LIBS=@LIBTDB_LIBS@ LIBNETAPI_LIBS=@LIBNETAPI_LIBS@ +AFS_LIBS=@AFS_LIBS@ INSTALLCMD=@INSTALL@ INSTALLLIBCMD_SH=@INSTALLLIBCMD_SH@ @@ -1337,7 +1338,7 @@ $(KRB5LIBS) $(DYNEXP) $(PRINT_LIBS) $(AUTH_LIBS) \ $(ACL_LIBS) $(PASSDB_LIBS) $(LIBS) $(DNSSD_LIBS) \ $(POPT_LIBS) @SMBD_LIBS@ $(LIBTALLOC_LIBS) $(LIBTDB_LIBS) \ - $(WINBIND_LIBS) + $(WINBIND_LIBS) $(AFS_LIBS) bin/nmbd@EXEEXT@: $(BINARY_PREREQS) $(NMBD_OBJ) @BUILD_POPT@ @LIBTALLOC_SHARED@ @LIBTDB_SHARED@ @echo Linking $@ @@ -1349,7 +1350,7 @@ @echo Linking $@ @$(CC) $(FLAGS) -o $@ $(SWAT_OBJ) $(LDFLAGS) $(DYNEXP) $(PRINT_LIBS) \ $(AUTH_LIBS) $(LIBS) $(PASSDB_LIBS) $(POPT_LIBS) $(KRB5LIBS) \ - $(LDAP_LIBS) $(LIBTALLOC_LIBS) $(LIBTDB_LIBS) $(WINBIND_LIBS) + $(LDAP_LIBS) $(LIBTALLOC_LIBS) $(LIBTDB_LIBS) $(WINBIND_LIBS) $(AFS_LIBS) bin/rpcclient@EXEEXT@: $(BINARY_PREREQS) $(RPCCLIENT_OBJ) @BUILD_POPT@ @LIBTALLOC_SHARED@ @LIBTDB_SHARED@ @LIBWBCLIENT_SHARED@ @echo Linking $@ @@ -1369,7 +1370,7 @@ @echo Linking $@ @$(CC) $(FLAGS) -o $@ $(NET_OBJ) $(DYNEXP) $(LDFLAGS) $(LIBS) \ $(POPT_LIBS) $(KRB5LIBS) $(UUID_LIBS) $(LDAP_LIBS) \ - $(PASSDB_LIBS) $(TERMLDFLAGS) $(TERMLIBS) $(NSCD_LIBS) \ + $(PASSDB_LIBS) $(AFS_LIBS) $(TERMLDFLAGS) $(TERMLIBS) $(NSCD_LIBS) \ @INIPARSERLIBS@ $(LIBTALLOC_LIBS) $(LIBTDB_LIBS) $(WINBIND_LIBS) $(LIBNETAPI_LIBS) bin/profiles@EXEEXT@: $(BINARY_PREREQS) $(PROFILES_OBJ) @BUILD_POPT@ @LIBTALLOC_SHARED@ @LIBTDB_SHARED@ @@ -1767,7 +1768,7 @@ @echo "Linking $@" @$(CC) $(FLAGS) -o $@ $(WINBINDD_OBJ) $(LDFLAGS) $(DYNEXP) $(LIBS) \ $(POPT_LIBS) $(KRB5LIBS) $(LDAP_LIBS) \ - $(PASSDB_LIBS) $(LIBTALLOC_LIBS) $(LIBTDB_LIBS) $(WINBIND_LIBS) + $(PASSDB_LIBS) $(LIBTALLOC_LIBS) $(LIBTDB_LIBS) $(WINBIND_LIBS) $(AFS_LIBS) bin/vlp@EXEEXT@: $(BINARY_PREREQS) $(VLP_OBJ) @LIBTALLOC_SHARED@ @LIBTDB_SHARED@ @LIBWBCLIENT_SHARED@ @echo "Linking $@" --- source/configure.in.orig 2009-01-28 12:07:51.000000000 +0100 +++ source/configure.in 2009-01-28 12:10:56.000000000 +0100 @@ -100,6 +100,7 @@ AC_SUBST(KRB5_LIBS) AC_SUBST(UUID_LIBS) AC_SUBST(LDAP_LIBS) +AC_SUBST(AFS_LIBS) AC_SUBST(GPEXT_LIBS) AC_SUBST(PAM_MODULES) AC_SUBST(INSTALL_PAM_MODULES) @@ -2979,6 +2980,7 @@ ################################################# # decide whether we can support WITH_AFS and / or WITH_FAKE_KASERVER +AFS_LIBS="" if test x"$samba_cv_WITH_AFS" != x"no" || test x"$samba_cv_WITH_FAKE_KASERVER" != x"no"; then @@ -2989,6 +2991,7 @@ if test -d /usr/include/afs; then CFLAGS="$CFLAGS -I/usr/include/afs" CPPFLAGS="$CPPFLAGS -I/usr/include/afs" + AFS_LIBS="-L/usr/lib/afs -lafsauthent -lafsrpc -lpthread -lcrypto" AC_MSG_RESULT(yes) else AC_MSG_RESULT(no) @@ -6283,6 +6286,7 @@ AC_MSG_RESULT([ DNSSD_LIBS = $DNSSD_LIBS]) fi AC_MSG_RESULT([ AUTH_LIBS = $AUTH_LIBS]) +AC_MSG_RESULT([ AFS_LIBS = $AFS_LIBS]) ################################################# # final configure stuff --- source/modules/vfs_afsacl.c Wed Jan 11 15:05:28 2006 +++ source/modules/vfs_afsacl.c Sat Jan 14 11:19:34 2006 @@ -311,6 +311,7 @@ static BOOL unparse_afs_acl(struct afs_acl *acl, char *acl_str) { + struct afs_ace *ace; /* TODO: String length checks!!!! */ int positives = 0; @@ -318,8 +319,7 @@ fstring line; *acl_str = 0; - - struct afs_ace *ace = acl->acelist; + ace = acl->acelist; while (ace != NULL) { if (ace->positive) --- source/lib/afs.c.orig 2009-01-28 09:39:02.000000000 +0100 +++ source/lib/afs.c 2009-01-28 09:40:37.000000000 +0100 @@ -230,8 +230,8 @@ } afs_username = talloc_sub_advanced(ctx, - SNUM(conn), conn->user, - conn->connectpath, conn->gid, + SNUM(conn), conn->server_info->utok.uid, + conn->connectpath, conn->server_info->utok.gid, conn->server_info->sanitized_username, pdb_get_domain(conn->server_info->sam_account), afs_username); EOF %build cd source CC=%{sambagcc} \ LDFLAGS="-Wl,-rpath,%{_prefix}/lib" \ /configure \ --prefix=%{_prefix} \ --with-privatedir=/etc/samba \ --with-lockdir=/var/samba/locks \ --with-swatdir=%{_prefix}/swat \ --with-configdir=/etc/samba \ --with-modulesdir=%{_prefix}/lib/modules \ --sharedstatedir=/var/samba \ --localstatedir=/var/samba \ --datarootdir=%{_prefix} \ --with-pam \ --with-fake-kaserver \ --with-vfs-afsacl \ --with-libsmbclient \ --with-quotas \ --enable-shared \ --enable-shared-libs cp -p Makefile Makefile.orig sed 's/-Wl,-Bsymbolic//' Makefile make cd .. %install [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT%{_prefix} cd source make install DESTDIR=$RPM_BUILD_ROOT cd .. ( cd $RPM_BUILD_ROOT%{_prefix}/lib ln -s libtalloc.so libtalloc.so.1 ln -s libtdb.so libtdb.so.1 ln -s libwbclient.so libwbclient.so.0 ) install -d $RPM_BUILD_ROOT%{_docdir} install -d $RPM_BUILD_ROOT%{_docdir}/registry install docs/Samba*.pdf $RPM_BUILD_ROOT%{_docdir} install docs/registry/*.reg $RPM_BUILD_ROOT%{_docdir}/registry strip $RPM_BUILD_ROOT%{_prefix}/*bin/* || true rm -rf $RPM_BUILD_ROOT/{etc,var} --ELM1233493290-7118-0_-- --ELM1233493290-7118-0_-- From clc31@inbox.com Mon Feb 2 15:06:28 2009 From: clc31@inbox.com (Chaz Chandler) Date: Mon, 2 Feb 2009 07:06:28 -0800 Subject: [OpenAFS] move RO volume Message-ID: <31BE740B88C.00000324clc31@inbox.com> You could do it another way: vos dump from source partition and vos = restore to destination. But generally the easiest way is addsite/remsite. Note that vos remsite is the command to remove an RO volume, not vos remove. The order doesn't matter, but you would vos addsite the volume on the = destination partition and (optionally) vos remsite the volume on the source partition. It's generally best to keep your RW and RO volume on the same partition if = disk space is an issue. Also, since you can have more than one RO volume per server, depending on = what you're trying to accomplish you may not even need to do this. > -----Original Message----- > From: lw=40lwilke.de > Sent: Mon, 2 Feb 2009 11:03:55 +0100 > To: openafs-info=40openafs.org > Subject: =5BOpenAFS=5D move RO volume >=20 > Hi, >=20 > Just a quick question, is it correct, that it is not possible to move a > RO > volume from one partition to another partition on the *same* server > without > doing a vos remove, addsite, release? > Using OAFS 1.4.7. >=20 > Thanks >=20 > --lars > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info=40openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info ____________________________________________________________ GET FREE SMILEYS FOR YOUR IM & EMAIL - Learn more at = http://www.inbox.com/smileys Works with AIM=C2=AE, MSN=C2=AE Messenger, Yahoo=21=C2=AE Messenger, = ICQ=C2=AE, Google Talk=E2=84=A2 and most webmails From jason@rampaginggeek.com Mon Feb 2 15:12:02 2009 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Mon, 02 Feb 2009 10:12:02 -0500 Subject: [OpenAFS] Read-Write Disconnected Mode - How does it work? In-Reply-To: <48D82508-F92F-4498-92F6-44517BDE38A3@inf.ed.ac.uk> References: <183280.58371.qm@web52209.mail.re2.yahoo.com> <2CCB90CE-E201-41EC-ADD5-3DCDAB9D23DF@inf.ed.ac.uk> <4985C5F0.3080905@rampaginggeek.com> <4986510B.5080006@rampaginggeek.com> <48D82508-F92F-4498-92F6-44517BDE38A3@inf.ed.ac.uk> Message-ID: <49870D42.20307@rampaginggeek.com> Simon Wilkinson wrote: > > On 2 Feb 2009, at 01:48, Jason Edgecombe wrote: >> I had some trouble with discon mode. I compiled an RPM from the 1_5 >> branch in CVS. I can "find . -type f | cat > /dev/null", then I can >> fs discon offline. Problems that I had: >> * ls couldn't find "."; reconnecting and disconnecting fixed it > > This suggests that you didn't cache the directory - either it was > skipped by the find, or the callback on it had been expired by the > time you went offline. Pinning should solve these kinds of issues. > >> * I tried running my newtests perl scripts, but that failed with some >> perl errors. > > Were these issues related to the filesystem, or other problems? Are > those tests available somewhere? > >> * vi complained of multiple swap files when trying to edit the config >> file for my test suite. > > Odd. Can you get an fstrace log of what vi was trying to do when it > complained - I can vi whilst disconnected without any problem. > >> * fs discon online said I didn't have the proper permissions when run >> as root. > > Did you have tokens? The error code you're getting is UAEACCES, which > suggests not. > >> * "fs discon online -force" made AFS freeze > > Again, strange. Did you get cmdebug -long output to see if it's hung > on a lock, or alt-sysreq-t output to see where each process is blocked? The tests are at /afs/dementia.org/home/edgester/git/newtests/ I'm certain I had tokens. I'll have to try things again when I get home this evening. Pardon my ignorance, but how do I enable the fs trace log? Where will it be? Can I trigger alt-sysreq-t remotely and get the output? Thanks, Jason From reuter@rzg.mpg.de Mon Feb 2 15:15:47 2009 From: reuter@rzg.mpg.de (Hartmut Reuter) Date: Mon, 02 Feb 2009 16:15:47 +0100 Subject: [OpenAFS] move RO volume In-Reply-To: <31BE740B88C.00000324clc31@inbox.com> References: <31BE740B88C.00000324clc31@inbox.com> Message-ID: <49870E23.4040509@rzg.mpg.de> Chaz Chandler wrote: > You could do it another way: vos dump from source partition and vos res= tore to > destination. But generally the easiest way is addsite/remsite. >=20 > Note that vos remsite is the command to remove an RO volume, not vos re= move. This is not true: vos remsite lets the vldb forget about the RO, but it doesn't remove it=20 from the partition. If you end up with the same RO on more than one partition on your server = only the first one (depending on the order in which the partitions get=20 attached) will come on-line. The other one(s) remain off-line. Hartmut >=20 > The order doesn't matter, but you would vos addsite the volume on the d= estination > partition and (optionally) vos remsite the volume on the source partiti= on. >=20 > It's generally best to keep your RW and RO volume on the same partition= if disk space is > an issue. >=20 > Also, since you can have more than one RO volume per server, depending = on what you're > trying to accomplish you may not even need to do this. >=20 >=20 >>-----Original Message----- >>From: lw@lwilke.de >>Sent: Mon, 2 Feb 2009 11:03:55 +0100 >>To: openafs-info@openafs.org >>Subject: [OpenAFS] move RO volume >> >>Hi, >> >>Just a quick question, is it correct, that it is not possible to move a= >>RO >>volume from one partition to another partition on the *same* server >>without >>doing a vos remove, addsite, release? >>Using OAFS 1.4.7. >> >>Thanks >> >> --lars >>_______________________________________________ >>OpenAFS-info mailing list >>OpenAFS-info@openafs.org >>https://lists.openafs.org/mailman/listinfo/openafs-info >=20 >=20 > ____________________________________________________________ > GET FREE SMILEYS FOR YOUR IM & EMAIL - Learn more at http://www.inbox.c= om/smileys > Works with AIM=C2=AE, MSN=C2=AE Messenger, Yahoo!=C2=AE Messenger, ICQ=C2= =AE, Google Talk=E2=84=A2 and most webmails > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info --=20 ----------------------------------------------------------------- Hartmut Reuter e-mail reuter@rzg.mpg.de phone +49-89-3299-1328 fax +49-89-3299-1301 RZG (Rechenzentrum Garching) web http://www.rzg.mpg.de/~hwr Computing Center of the Max-Planck-Gesellschaft (MPG) and the Institut fuer Plasmaphysik (IPP) ----------------------------------------------------------------- From haba@kth.se Mon Feb 2 15:42:05 2009 From: haba@kth.se (Harald Barth) Date: Mon, 02 Feb 2009 16:42:05 +0100 (CET) Subject: [OpenAFS] AFS FileServer and Heartbeat In-Reply-To: <090B647A-D08C-42D1-8493-B9FF66B3D98E@roma1.infn.it> References: <090B647A-D08C-42D1-8493-B9FF66B3D98E@roma1.infn.it> Message-ID: <20090202.164205.241214561.haba@habanero.pdc.kth.se> For IP adresses, you want to look att the NetInfo and NetRestrict files and man pages. > We'd like to configure AFS Fileserver using heartbeat in active/passive mode. For controlled failover, you need to figre out what to do with the callback information on all files that IMHO only exists in RAM of the serving file server. Maybee the 1.5 server features with restartable callbacks can help you with that. Otherwise you will loose state information with each failovers (parts of the clients will see old file versions). Harald. From lw@lwilke.de Mon Feb 2 15:51:50 2009 From: lw@lwilke.de (Lars Wilke) Date: Mon, 2 Feb 2009 16:51:50 +0100 Subject: [OpenAFS] move RO volume In-Reply-To: <49870E23.4040509@rzg.mpg.de> References: <31BE740B88C.00000324clc31@inbox.com> <49870E23.4040509@rzg.mpg.de> Message-ID: <20090202155150.GA21467@ckLennard.net.home> * Hartmut Reuter wrote: > If you end up with the same RO on more than one partition on your server > only the first one (depending on the order in which the partitions get > attached) will come on-line. The other one(s) remain off-line. Also vos addsite refuses to work if i want to add a second replication site on the same server but on a different partition. The reason i asked is that some volumes are quite large, deleting them and then copying (vos release) them again from a remote server was a bit inconveniet. So i thought, that i might have missed an easier way. Dumping the volumes might be an option next time. cheers --lars From shadow@gmail.com Mon Feb 2 16:09:14 2009 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 2 Feb 2009 11:09:14 -0500 Subject: [OpenAFS] move RO volume In-Reply-To: <49870E23.4040509@rzg.mpg.de> References: <31BE740B88C.00000324clc31@inbox.com> <49870E23.4040509@rzg.mpg.de> Message-ID: On Mon, Feb 2, 2009 at 10:15 AM, Hartmut Reuter wrote: > Chaz Chandler wrote: >> >> You could do it another way: vos dump from source partition and vos >> restore to >> destination. But generally the easiest way is addsite/remsite. >> >> Note that vos remsite is the command to remove an RO volume, not vos >> remove. > > This is not true: > > vos remsite lets the vldb forget about the RO, but it doesn't remove it from > the partition. > > If you end up with the same RO on more than one partition on your server > only the first one (depending on the order in which the partitions get > attached) will come on-line. The other one(s) remain off-line. Worse than that. Volume operations update the one in the vldb; File uses attachment order. Current versions of OpenAFS work very hard to ensure this doesn't happen. From sxw@inf.ed.ac.uk Mon Feb 2 18:23:39 2009 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Mon, 2 Feb 2009 18:23:39 +0000 Subject: [OpenAFS] Read-Write Disconnected Mode - How does it work? In-Reply-To: <49870D42.20307@rampaginggeek.com> References: <183280.58371.qm@web52209.mail.re2.yahoo.com> <2CCB90CE-E201-41EC-ADD5-3DCDAB9D23DF@inf.ed.ac.uk> <4985C5F0.3080905@rampaginggeek.com> <4986510B.5080006@rampaginggeek.com> <48D82508-F92F-4498-92F6-44517BDE38A3@inf.ed.ac.uk> <49870D42.20307@rampaginggeek.com> Message-ID: On 2 Feb 2009, at 15:12, Jason Edgecombe wrote: >> > The tests are at > /afs/dementia.org/home/edgester/git/newtests/ > > I'm certain I had tokens. Did root get those tokens when you su'd to take the machine back online, though? I've been caught out by this before - I've not been in a PAG, and then become root and lost my tokens, tried to go back online, and just been confronted by errors. > Pardon my ignorance, but how do I enable the fs trace log? I jotted some notes for myself on how to do this at http://blob.inf.ed.ac.uk/sxw/2009/01/24/using-fstrace-to-debug-the-afs-cache-manager/ Note that the critical thing is that you must have /usr/vice/etc/C/ afszcm.cat installed. Unfortunately, this currently isn't installed by our RPM - you should be able to find a copy in src/afs/afszcm.cat in your build directory. > Can I trigger alt-sysreq-t remotely and get the output? echo t > /proc/sysrq-trigger should do the trick. The output will be in dmesg, or in the system log. Cheers, Simon. From David.Bear@asu.edu Mon Feb 2 21:10:10 2009 From: David.Bear@asu.edu (David Bear) Date: Mon, 2 Feb 2009 14:10:10 -0700 Subject: [OpenAFS] trouble loading the kernel module Message-ID: <1d1a54bf0902021310v6e1fc139na75d97137f7848aa@mail.gmail.com> --000e0cd3beb2d5ae4a0461f5fa76 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I just installed that latest openafs 1.4 on RHEL 4, using the rpm from openafs.org. The rpm installed alright, but when I tried to start the client I get a message sudo /etc/init.d/openafs-client start Updating CellServDB: Starting openafs-client: FATAL: Module openafs not found. failed to load openafs kernel module. [FAILED] which is strange since I also install the kernel modules, and it does exist locate afs | grep ko /lib/modules/2.6.9-78.0.1.EL/extra/openafs/openafs.ko So, now do I need to modify a config file somewhere or symlink the openafs.ko file to some standard location? -- David Bear College of Public Programs at ASU 602-464-0424 --000e0cd3beb2d5ae4a0461f5fa76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

I just installed that latest openafs 1.4 on RHEL 4, using the rpm from openafs.org.

The rpm installed alright, but when I tried to start the client I get a message

sudo /etc/init.d/openafs-client start
Updating CellServDB:
Starting openafs-client: FATAL: Module openafs not found.
failed to load openafs kernel module. [FAILED]

which is strange since I also install the kernel modules, and it does exist

locate afs | grep ko
/lib/modules/2.6.9-78.0.1.EL/extra/openafs/openafs.ko

So, now do I need to modify a config file somewhere or symlink the openafs.ko file to some standard location?

--

David Bear
College of Public Programs at ASU
602-464-0424
--000e0cd3beb2d5ae4a0461f5fa76-- From sxw@inf.ed.ac.uk Mon Feb 2 21:32:29 2009 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Mon, 2 Feb 2009 21:32:29 +0000 Subject: [OpenAFS] trouble loading the kernel module In-Reply-To: <1d1a54bf0902021310v6e1fc139na75d97137f7848aa@mail.gmail.com> References: <1d1a54bf0902021310v6e1fc139na75d97137f7848aa@mail.gmail.com> Message-ID: On 2 Feb 2009, at 21:10, David Bear wrote: > I just installed that latest openafs 1.4 on RHEL 4, using the rpm > from openafs.org. > [snip] > So, now do I need to modify a config file somewhere or symlink the > openafs.ko file to some standard location? > You shouldn't need to do anything beyond this. There are a few things that you should check. Firstly, make sure that your running kernel matches the model you have installed - you can check the running kernel with uname -r. It's possible that you've upgraded the kernel, but not yet rebooted. Secondly, run depmod -a, just to make sure that the module dependency information is up to date. I think you've probably got a mismatch between AFS module, and running kernel version, though. S. From davidbranquinho@gmail.com Tue Feb 3 00:18:02 2009 From: davidbranquinho@gmail.com (David Miguel) Date: Tue, 3 Feb 2009 00:18:02 +0000 Subject: [OpenAFS] AFS & Kerberos through NAT Message-ID: --000e0cd25938b74cc10461f89a30 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, I installed afs with kerberos, and it seems to be working fine. But, for now, all the servers and clients are on the local network. Can I access afs through NAT? Can I foward the ports of only one afs server, and the kerberos server? Is it enough? Thanks, --david --000e0cd25938b74cc10461f89a30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

I installed afs with kerberos, and it seems to be working fin= e.
But, for now, all the servers and clients are on the local network.
Can I access afs through NAT?

Can I foward the ports of only o= ne afs server, and the kerberos server?
Is it enough?

Thanks,
--david
--000e0cd25938b74cc10461f89a30-- From David.Bear@asu.edu Tue Feb 3 01:14:44 2009 From: David.Bear@asu.edu (David Bear) Date: Mon, 2 Feb 2009 18:14:44 -0700 Subject: [OpenAFS] trouble loading the kernel module In-Reply-To: References: <1d1a54bf0902021310v6e1fc139na75d97137f7848aa@mail.gmail.com> Message-ID: <1d1a54bf0902021714k2bfc6bffwbdf6fdc5bd9dd27d@mail.gmail.com> --000e0cd482148512190461f965ec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Thanks for the suggestion Simon. However, I think my kernel and kernel-mods match -- unless I'm reading this wrong: locate afs | grep ko /lib/modules/2.6.9-78.0.1.EL/extra/openafs/openafs.ko $ uname -a Linux 2.6.9-78.0.13.ELsmp #1 SMP Wed Jan 7 17:45:52 EST 2009 x86_64 x86_64 x86_64 GNU/Linux I thought since the kernel says its SMP that I might need http://openafs.org/dl/openafs/1.4.8/rhel4/x86_64/kmod-openafs-smp-1.4.8-1.1.2.6.9_78.EL.x86_64.rpm but attempts to install that fail with the error: error: Failed dependencies: kernel-smp-x86_64 = 2.6.9-78.EL is needed by kmod-openafs-smp-1.4.8-1.1.2.6.9_78.EL.x86_64 Suggested resolutions: So, I'm little lost. Enlighten me please. On Mon, Feb 2, 2009 at 2:32 PM, Simon Wilkinson wrote: > > On 2 Feb 2009, at 21:10, David Bear wrote: > > I just installed that latest openafs 1.4 on RHEL 4, using the rpm from >> openafs.org. >> >> [snip] > >> So, now do I need to modify a config file somewhere or symlink the >> openafs.ko file to some standard location? >> >> > You shouldn't need to do anything beyond this. There are a few things that > you should check. Firstly, make sure that your running kernel matches the > model you have installed - you can check the running kernel with uname -r. > It's possible that you've upgraded the kernel, but not yet rebooted. > > Secondly, run depmod -a, just to make sure that the module dependency > information is up to date. > > I think you've probably got a mismatch between AFS module, and running > kernel version, though. > > S. > > -- David Bear College of Public Programs at ASU 602-464-0424 --000e0cd482148512190461f965ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks for the suggestion Simon. However, I think my kernel and kernel-m= ods match -- unless I'm reading this wrong:

locate afs | grep ko<= br>/lib/modules/2.6.9-78.0.1.EL/extra/openafs/openafs.ko

$ uname = -a
Linux  2.6.9-78.0.13.ELsmp #1 SMP Wed Jan 7 17:45:52 EST 2009 x86_64 x= 86_64 x86_64 GNU/Linux

I thought since the kernel says its SMP that = I might need

http://openafs.o= rg/dl/openafs/1.4.8/rhel4/x86_64/kmod-openafs-smp-1.4.8-1.1.2.6.9_78.EL.x86= _64.rpm

but attempts to install that fail with the error:

error: Failed de= pendencies:
  kernel-smp-x86_64 =3D 2.6.9-78.EL is needed by = kmod-openafs-smp-1.4.8-1.1.2.6.9_78.EL.x86_64
  Suggested resolut= ions:

So, I'm little lost. Enlighten me please.


On Mon, Feb 2, 2009 at 2:32 PM, Simon Wilkinson <sxw@inf.ed.ac.uk>= wrote:

On 2 Feb 2009, at 21:10, David Bear wrote:

I just installed that latest openafs 1.4 on RHEL 4, using the rpm from openafs.org.

[snip]

So, now do I need to modify a config file somewhere or symlink the openafs.= ko file to some standard location?


You shouldn't need to do anything beyond this. There are a few things t= hat you should check. Firstly, make sure that your running kernel matches t= he model you have installed - you can check the running kernel with uname -= r. It's possible that you've upgraded the kernel, but not yet reboo= ted.

Secondly, run depmod -a, just to make sure that the module dependency infor= mation is up to date.

I think you've probably got a mismatch between AFS module, and running = kernel version, though.

S.




--
David Bear
Co= llege of Public Programs at ASU
602-464-0424
--000e0cd482148512190461f965ec-- From shadow@gmail.com Tue Feb 3 02:55:19 2009 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 2 Feb 2009 21:55:19 -0500 Subject: [OpenAFS] Client machine hangs after OpenAFS server restart! In-Reply-To: References: Message-ID: Does bos status (server) -long show the fileserver is up? What version of OpenAFS? What's in the system log file? Provide as much information as you can. On Mon, Feb 2, 2009 at 8:25 AM, Vishnu Ram wrote: > I've set up OpenAFS server and client on two different machines, with CentOS > 5.2 as the operating system. > I'm using OpenAFS for mounting the user home directories. I could login and > work with the mounted home directory, but > the client machine hangs after I restart the OpenAFS server. The client > machine hangs completely and only option is to do a hard reboot. I use > applications such as kmail, firefox, openoffice, etc. in the client machine. > My objective is to setup highly available user home directories with > OpenAFS. > > Regards, > Vishnu > -- Derrick From steven.jenkins@gmail.com Tue Feb 3 04:46:50 2009 From: steven.jenkins@gmail.com (Steven Jenkins) Date: Mon, 2 Feb 2009 23:46:50 -0500 Subject: [OpenAFS] AFS FileServer and Heartbeat In-Reply-To: <090B647A-D08C-42D1-8493-B9FF66B3D98E@roma1.infn.it> References: <090B647A-D08C-42D1-8493-B9FF66B3D98E@roma1.infn.it> Message-ID: On Mon, Feb 2, 2009 at 9:13 AM, Cristina Bulfon wrote: > Hello, > > We'd like to configure AFS Fileserver using heartbeat in active/passive > mode. ... > On the heartbeat side we have the following haresource file > > afsitfs3.roma1.infn.it IPaddr2::Y.Y.Y.Y/24/eth0:0 > afsitfs3.roma1.infn.it drbddisk::r0 Filesystem::/dev/drbd1::/vicepa::xfs > afsitfs3.roma1.infn.it drbddisk::r1 Filesystem::/dev/drbd2::/usr/afs::ext3 > afsitfs3.roma1.infn.it Y.Y.Y.Y afs > > On the afs side we've also configured the NetInfo and the NetRestrict > file, in the NetInfo we put the IP address stored on VLDB server ( in this > case Y.Y.Y.Y) while in the NetRestrict put the IP addresses of the two > servers. > > The problem is that everything is working fine inside the LAN but If I try > to execute a simple command like "ls" from outiside the LAN I got > > Connection Timed Out > > If we look at the FileLog file we saw that the Fileserver takes the IP and > hostname as the real server instead of the virtual one. > .... > Mon Feb 2 13:18:37 2009 FileServer host name is 'afsitfs3.roma1.infn.it > Mon Feb 2 13:18:37 2009 FileServer afsitfs3.roma1.infn.it has address > 141.108.26.29 (0x1d1a6c8d or 0x8d6c1a1d in host byte order) This implies an error in the NetRestrict file -- it should contain the address of the IP of the actual server. Could you provide the actual contents of the NetInfo and NetRestrict files? That would aid in debugging this problem. -- Steven Jenkins End Point Corporation http://www.endpoint.com/ From cristina.bulfon@roma1.infn.it Tue Feb 3 07:47:34 2009 From: cristina.bulfon@roma1.infn.it (Cristina Bulfon) Date: Tue, 3 Feb 2009 08:47:34 +0100 Subject: [OpenAFS] AFS FileServer and Heartbeat In-Reply-To: References: <090B647A-D08C-42D1-8493-B9FF66B3D98E@roma1.infn.it> Message-ID: --Apple-Mail-3--210499348 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Ciao Steven, sure :-)... following the files content - /usr/afs/local/NetInfo: 141.108.26.31 (corresponding to Y.Y.Y.Y in the previous email, is the virtual IP server ) - /usr/afs/local/NetRestrict 141.108.26.29 141.108.26.49 Just in case I'd like to remind you that the above files are the same files in both servers, /usr/afs is a shareble partition. cristina On Feb 3, 2009, at 5:46 AM, Steven Jenkins wrote: > On Mon, Feb 2, 2009 at 9:13 AM, Cristina Bulfon > wrote: >> Hello, >> >> We'd like to configure AFS Fileserver using heartbeat in active/ >> passive >> mode. > ... >> On the heartbeat side we have the following haresource file >> >> afsitfs3.roma1.infn.it IPaddr2::Y.Y.Y.Y/24/eth0:0 >> afsitfs3.roma1.infn.it drbddisk::r0 Filesystem::/dev/drbd1::/ >> vicepa::xfs >> afsitfs3.roma1.infn.it drbddisk::r1 Filesystem::/dev/drbd2::/usr/ >> afs::ext3 >> afsitfs3.roma1.infn.it Y.Y.Y.Y afs >> >> On the afs side we've also configured the NetInfo and the NetRestrict >> file, in the NetInfo we put the IP address stored on VLDB server >> ( in this >> case Y.Y.Y.Y) while in the NetRestrict put the IP addresses of the >> two >> servers. >> >> The problem is that everything is working fine inside the LAN but >> If I try >> to execute a simple command like "ls" from outiside the LAN I got >> >> Connection Timed Out >> >> If we look at the FileLog file we saw that the Fileserver takes the >> IP and >> hostname as the real server instead of the virtual one. >> .... >> Mon Feb 2 13:18:37 2009 FileServer host name is >> 'afsitfs3.roma1.infn.it >> Mon Feb 2 13:18:37 2009 FileServer afsitfs3.roma1.infn.it has >> address >> 141.108.26.29 (0x1d1a6c8d or 0x8d6c1a1d in host byte order) > > This implies an error in the NetRestrict file -- it should contain the > address of the IP of the actual server. Could you provide the actual > contents of the NetInfo and NetRestrict files? That would aid in > debugging this problem. > > -- > Steven Jenkins > End Point Corporation > http://www.endpoint.com/ > --Apple-Mail-3--210499348 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Ciao Steven,

sure :-)... following the files = content

- = /usr/afs/local/NetInfo:

141.108.26.31  = (corresponding to Y.Y.Y.Y in the previous email, is the virtual = IP server )

- = /usr/afs/local/NetRestrict

141.108.26.29
141.108.26.49

Just in case I'd like to remind you that the above files are the = same files in both servers, /usr/afs is a shareble = partition.

cristina 


On Feb 3, 2009, at 5:46 AM, Steven Jenkins wrote:

On = Mon, Feb 2, 2009 at 9:13 AM, Cristina Bulfon
<cristina.bulfon@roma1.infn.i= t> wrote:
Hello,

We'd like to = configure AFS Fileserver using  heartbeat in = active/passive
mode.
...
On = the heartbeat side we have the following haresource = file

afsitfs3.roma1.infn.it =  IPaddr2::Y.Y.Y.Y/24/eth0:0
afsitfs3.roma1.infn.it  drbddisk::r0 =  Filesystem::/dev/drbd1::/vicepa::xfs
afsitfs3.roma1.infn.it  drbddisk::r1 =  Filesystem::/dev/drbd2::/usr/afs::ext3
afsitfs3.roma1.infn.it =         Y.Y.Y.Y =   afs

On the afs side = we've also configured the NetInfo and the = NetRestrict
file, in the = NetInfo we put the IP address stored on VLDB server ( in = this
case Y.Y.Y.Y) while in = the NetRestrict put the IP addresses of the = two
servers.

The problem is = that everything is working fine inside the LAN  but If I = try
to execute a simple = command like "ls"  from outiside the LAN I = got

Connection Timed Out

If we look at = the FileLog file we saw that the Fileserver takes the IP = and
hostname as the real = server instead of the virtual one.
....
Mon Feb =  2 13:18:37 2009 FileServer host name is = 'afsitfs3.roma1.infn.it
Mon = Feb  2 13:18:37 2009 FileServer afsitfs3.roma1.infn.it has = address
141.108.26.29 = (0x1d1a6c8d or 0x8d6c1a1d in host byte order)

This = implies an error in the NetRestrict file -- it should contain = the
address of the IP of the actual server.  Could you provide = the actual
contents of the NetInfo and NetRestrict files?  That = would aid in
debugging this problem.

--
Steven = Jenkins
End Point Corporation
http://www.endpoint.com/


= --Apple-Mail-3--210499348-- From cristina.bulfon@roma1.infn.it Tue Feb 3 07:50:18 2009 From: cristina.bulfon@roma1.infn.it (Cristina Bulfon) Date: Tue, 3 Feb 2009 08:50:18 +0100 Subject: [OpenAFS] AFS FileServer and Heartbeat In-Reply-To: <20090202.164205.241214561.haba@habanero.pdc.kth.se> References: <090B647A-D08C-42D1-8493-B9FF66B3D98E@roma1.infn.it> <20090202.164205.241214561.haba@habanero.pdc.kth.se> Message-ID: --Apple-Mail-4--210335429 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Ciao Harald, thanks so much for remind me how to handle the callback informations. I will have a look to 1.5 servers. cristina On Feb 2, 2009, at 4:42 PM, Harald Barth wrote: > > For IP adresses, you want to look att the NetInfo and NetRestrict > files and man pages. > >> We'd like to configure AFS Fileserver using heartbeat in active/ >> passive mode. > > For controlled failover, you need to figre out what to do with the > callback information on all files that IMHO only exists in RAM of the > serving file server. Maybee the 1.5 server features with restartable > callbacks can help you with that. Otherwise you will loose state > information with each failovers (parts of the clients will see old > file versions). > > Harald. > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > --Apple-Mail-4--210335429 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Ciao = Harald,

thanks so much for remind me how to handle the = callback informations. I will
have a look to 1.5 = servers.

cristina 


On Feb 2, = 2009, at 4:42 PM, Harald Barth wrote:


For= IP adresses, you want to look att the NetInfo and NetRestrict files and = man pages.

We'd like to configure AFS = Fileserver using  heartbeat in active/passive = mode.

For controlled failover, you need to figre out = what to do with the
callback information on all files that IMHO only = exists in RAM of the
serving file server. Maybee the 1.5 server = features with restartable
callbacks can help you with that. Otherwise = you will loose state
information with each failovers (parts of the = clients will see old
file = versions).

Harald.
_____________________________________________= __
OpenAFS-info mailing list
OpenAFS-info@openafs.org
h= ttps://lists.openafs.org/mailman/listinfo/openafs-info


= --Apple-Mail-4--210335429-- From sxw@inf.ed.ac.uk Tue Feb 3 09:24:32 2009 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Tue, 3 Feb 2009 09:24:32 +0000 Subject: [OpenAFS] trouble loading the kernel module In-Reply-To: <1d1a54bf0902021714k2bfc6bffwbdf6fdc5bd9dd27d@mail.gmail.com> References: <1d1a54bf0902021310v6e1fc139na75d97137f7848aa@mail.gmail.com> <1d1a54bf0902021714k2bfc6bffwbdf6fdc5bd9dd27d@mail.gmail.com> Message-ID: On 3 Feb 2009, at 01:14, David Bear wrote: > Thanks for the suggestion Simon. However, I think my kernel and > kernel-mods match -- unless I'm reading this wrong: > > locate afs | grep ko > /lib/modules/2.6.9-78.0.1.EL/extra/openafs/openafs.ko > > $ uname -a > Linux 2.6.9-78.0.13.ELsmp #1 SMP Wed Jan 7 17:45:52 EST 2009 x86_64 > x86_64 x86_64 GNU/Linux > No, those don't match. 2.6.9-78.0.1.EL != 2.6.9-78.0.13.EL > I thought since the kernel says its SMP that I might need > > http://openafs.org/dl/openafs/1.4.8/rhel4/x86_64/kmod-openafs-smp-1.4.8-1.1.2.6.9_78.EL.x86_64.rpm > That kernel is for 2.6.9-78-EL, not 2.6.9-78-0.13-EL I think you probably want /afs/grand.central.org/software/openafs/1.4.8/rhel4/x86_64/kmod- openafs-smp-1.4.8-1.1.2.6.9_78.0.13.EL.x86_64.rpm S. From cristina.bulfon@roma1.infn.it Tue Feb 3 12:36:12 2009 From: cristina.bulfon@roma1.infn.it (Cristina Bulfon) Date: Tue, 3 Feb 2009 13:36:12 +0100 Subject: [OpenAFS] AFS FileServer and Heartbeat In-Reply-To: References: <090B647A-D08C-42D1-8493-B9FF66B3D98E@roma1.infn.it> <20090202.164205.241214561.haba@habanero.pdc.kth.se> Message-ID: --Apple-Mail-14--193181677 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Ciao, I guess I've solved the problem, the problem was due to a firewall ( I was pretty sure that it was setting correctly). Anyway thanks to everybody. cheers cristina On Feb 3, 2009, at 8:50 AM, Cristina Bulfon wrote: > Ciao Harald, > > thanks so much for remind me how to handle the callback > informations. I will > have a look to 1.5 servers. > > cristina > > > On Feb 2, 2009, at 4:42 PM, Harald Barth wrote: > >> >> For IP adresses, you want to look att the NetInfo and NetRestrict >> files and man pages. >> >>> We'd like to configure AFS Fileserver using heartbeat in active/ >>> passive mode. >> >> For controlled failover, you need to figre out what to do with the >> callback information on all files that IMHO only exists in RAM of the >> serving file server. Maybee the 1.5 server features with restartable >> callbacks can help you with that. Otherwise you will loose state >> information with each failovers (parts of the clients will see old >> file versions). >> >> Harald. >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info >> > --Apple-Mail-14--193181677 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Ciao = Harald,

thanks so much for remind me how to handle the = callback informations. I will
have a look to 1.5 = servers.

cristina 


On Feb 2, = 2009, at 4:42 PM, Harald Barth wrote:


For= IP adresses, you want to look att the NetInfo and NetRestrict files and = man pages.

We'd like to configure AFS = Fileserver using  heartbeat in active/passive = mode.

For controlled failover, you need to figre out = what to do with the
callback information on all files that IMHO only = exists in RAM of the
serving file server. Maybee the 1.5 server = features with restartable
callbacks can help you with that. Otherwise = you will loose state
information with each failovers (parts of the = clients will see old
file = versions).

Harald.
_____________________________________________= __
OpenAFS-info mailing list
OpenAFS-info@openafs.org
<= a = href=3D"https://lists.openafs.org/mailman/listinfo/openafs-info">https://l= ists.openafs.org/mailman/listinfo/openafs-info



= --Apple-Mail-14--193181677-- From davidbranquinho@gmail.com Tue Feb 3 22:45:58 2009 From: davidbranquinho@gmail.com (David Miguel) Date: Tue, 3 Feb 2009 22:45:58 +0000 Subject: [OpenAFS] afs recoverability Message-ID: --0015175cdba64efefb04620b6f98 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, I have some questions about recovering afs. Concerning two scenarios: 1. If I loose all afs servers (binaries, configurations, etc...), and I'm left with the partitions with the volumes inside, can I read the data in the volumes without mounting the entire cell again? 2. Often some files in a disk partition become corrupt, still, we can get all other files from the partition. If part of a volume in /vicepxx becomes corrupt, I loose the hole volume or only some files? Thank you very much, --david --0015175cdba64efefb04620b6f98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

I have some questions about recovering afs. Concerning two sc= enarios:

1. If I loose all afs servers (binaries, configurations, et= c...), and I'm left with the partitions with the volumes inside, can I = read the data in the volumes without mounting the entire cell again?

2. Often some files in a disk partition become corrupt, still, we can g= et all other files from the partition. If part of a volume in /vicepxx beco= mes corrupt, I loose the hole volume or only some files?

Thank you very much,
--david
--0015175cdba64efefb04620b6f98-- From shadow@gmail.com Tue Feb 3 22:49:52 2009 From: shadow@gmail.com (Derrick Brashear) Date: Tue, 3 Feb 2009 17:49:52 -0500 Subject: [OpenAFS] afs recoverability In-Reply-To: References: Message-ID: On Tue, Feb 3, 2009 at 5:45 PM, David Miguel wrote: > Hello, > > I have some questions about recovering afs. Concerning two scenarios: > > 1. If I loose all afs servers (binaries, configurations, etc...), and I'm > left with the partitions with the volumes inside, can I read the data in the > volumes without mounting the entire cell again? not in a manner which is likely sensible, but you can. > 2. Often some files in a disk partition become corrupt, still, we can get > all other files from the partition. If part of a volume in /vicepxx becomes > corrupt, I loose the hole volume or only some files? you lose only the files which go bad. if your storage is unreliable, i suggest keeping backups though, and just restoring when you notice an unhappy file -- Derrick From shadow@gmail.com Tue Feb 3 23:04:15 2009 From: shadow@gmail.com (Derrick Brashear) Date: Tue, 3 Feb 2009 18:04:15 -0500 Subject: [OpenAFS] afs recoverability In-Reply-To: References: Message-ID: >> > 1. If I loose all afs servers (binaries, configurations, etc...), and I'm >> > left with the partitions with the volumes inside, can I read the data in the >> > volumes without mounting the entire cell again? >> >> not in a manner which is likely sensible, but you can. > > Can you please indicate-me where can I read about this (or what program to use). well, it's just a directory of files; but the names of the files are encoded AFS inode numbers. The contents are exactly what you see through the filesystem, but the names don't make it obvious what you're looking at. > (this is because I'm really concerned about storing sensitive data on > afs, if I have no other way of reading it but to get afs working...). given that the fileserver is a userspace process, there shouldn't really be much obstacle to getting it working. even if you can't get a client working, you can take volume dumps from a running server, and use for instance "dumptool" to get a tree of files from it, named as you'd expect. -- Derrick From davidbranquinho@gmail.com Tue Feb 3 23:05:52 2009 From: davidbranquinho@gmail.com (David Miguel) Date: Tue, 3 Feb 2009 23:05:52 +0000 Subject: [OpenAFS] afs recoverability In-Reply-To: References: Message-ID: Thank you for your answer. 2009/2/3 Derrick Brashear : > On Tue, Feb 3, 2009 at 5:45 PM, David Miguel wrote: >> Hello, >> >> I have some questions about recovering afs. Concerning two scenarios: >> >> 1. If I loose all afs servers (binaries, configurations, etc...), and I'm >> left with the partitions with the volumes inside, can I read the data in the >> volumes without mounting the entire cell again? > > not in a manner which is likely sensible, but you can. Can you please indicate-me where can I read about this (or what program to use). (this is because I'm really concerned about storing sensitive data on afs, if I have no other way of reading it but to get afs working...). >> 2. Often some files in a disk partition become corrupt, still, we can get >> all other files from the partition. If part of a volume in /vicepxx becomes >> corrupt, I loose the hole volume or only some files? > > you lose only the files which go bad. if your storage is unreliable, i > suggest keeping backups though, and just restoring when you notice an > unhappy file > > > -- > Derrick > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > -- --david From jason@rampaginggeek.com Tue Feb 3 23:57:55 2009 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Tue, 03 Feb 2009 18:57:55 -0500 Subject: [OpenAFS] afs recoverability In-Reply-To: References: Message-ID: <4988DA03.8090709@rampaginggeek.com> Derrick Brashear wrote: > On Tue, Feb 3, 2009 at 5:45 PM, David Miguel wrote: > >> Hello, >> >> I have some questions about recovering afs. Concerning two scenarios: >> >> 1. If I loose all afs servers (binaries, configurations, etc...), and I'm >> left with the partitions with the volumes inside, can I read the data in the >> volumes without mounting the entire cell again? >> > > not in a manner which is likely sensible, but you can. > > >> 2. Often some files in a disk partition become corrupt, still, we can get >> all other files from the partition. If part of a volume in /vicepxx becomes >> corrupt, I loose the hole volume or only some files? >> > > you lose only the files which go bad. if your storage is unreliable, i > suggest keeping backups though, and just restoring when you notice an > unhappy file > If I recall ,just install and one-machine AFS cell, run vos syncserv or vos syncvlb (I can't remember which). Then the volumes will be online. If you need to recover from tape into non-afs space, look into the read_tape command. If you want to restore volume dumps from files into non-afs space, use restorevol. Jason From shadow@gmail.com Wed Feb 4 00:07:44 2009 From: shadow@gmail.com (Derrick Brashear) Date: Tue, 3 Feb 2009 19:07:44 -0500 Subject: [OpenAFS] afs recoverability In-Reply-To: References: Message-ID: On Tue, Feb 3, 2009 at 6:30 PM, David Miguel wrote: > sorry for the repeated mail... > > 2009/2/3 Derrick Brashear : >>>> > 1. If I loose all afs servers (binaries, configurations, etc...), and I'm >>>> > left with the partitions with the volumes inside, can I read the data in the >>>> > volumes without mounting the entire cell again? >>>> >>>> not in a manner which is likely sensible, but you can. >>> >>> Can you please indicate-me where can I read about this (or what program to use). >> >> well, it's just a directory of files; but the names of the files are >> encoded AFS inode numbers. The contents are exactly what you see >> through the filesystem, but the names don't make it obvious what >> you're looking at. > > So, if I move all the files in ex.: vicepa to vicepx, using 'cp', and > not afs, will all data be copied? 1) if you make sure to preserve owner group and mode, and 2) copy recursively and if you want it to show in afs again, you'll need to use vos syncvldb > Or does afs store data in disk, in a way that it's not standard, and > not visible to common unix utilities? (for example the fcsk problem > with some systems...) it's visible to them just fine, but it's not standard. From haba@kth.se Wed Feb 4 09:55:43 2009 From: haba@kth.se (Harald Barth) Date: Wed, 04 Feb 2009 10:55:43 +0100 (CET) Subject: [OpenAFS] afs recoverability In-Reply-To: References: Message-ID: <20090204.105543.10830772.haba@habanero.pdc.kth.se> > > Or does afs store data in disk, in a way that it's not standard, and > > not visible to common unix utilities? (for example the fcsk problem > > with some systems...) I recommend the "namei" backend of the fileserver which stores everything visible. Namei is default under Linux. You know that you have namei when you have a file tree under AFSIDat like this: # ls -l /vicepa/AFSIDat/ total 4 -r--r--r-- 1 root root 156 Dec 3 15:10 README drwx------ 3 root root 18 Oct 10 10:17 e0 drwx------ 3 root root 18 Sep 19 16:14 x0 Older non-Linux installations use the "inode" backend where the contents of /vicep* are invisible. Harald. From willmaier@ml1.net Wed Feb 4 21:38:52 2009 From: willmaier@ml1.net (Will Maier) Date: Wed, 4 Feb 2009 15:38:52 -0600 Subject: [OpenAFS] Prolonged period of blocked connections Message-ID: <20090204213852.GF11427@lass.lfod.us> Hi folks- In the past, we've observed prolonged periods where one or more of our servers would report more than 200 calls waiting for a thread. This occurred again this morning and lasted for about four hours. While the server reported the blocked calls, top showed that the fileserver was pegged at >= 100% CPU and FileLog (with verbosity increased via SIGTSTP) showed a huge number of SAFS_FetchStatuses (and very little else). During this time, I also noticed that the number of blocked calls seemed to oscillate between 0 and ~220 over a period of about 100 seconds (with ~1300 total clients according to the hosts.dump file). This made me wonder if there wasn't some component that was periodically clearing the backlog and, if so, if the period might be easily modifiable. This condition tends to coincide with a large number of batch jobs that, unfortunately, must get some of their shared libraries, binaries and configuration/seed files from our AFS cell. We've done as much as we can to limit the amount of data in AFS that these jobs require, but we still observe blocked calls, especially when a large number of jobs spin up at approximately the same time. It's also possible that the jobs are overwhelming the clients' caches, which could conceivably cause extra/spurious calls to the server. Is this a possibility? If the periodicity of the backlog's level is a red herring, is there something else we might consider? See below for system details on the file server. The clients all run Linux on 32 and 64-bit machines connected to our servers via gigabit links. Thanks! $ uname -a Linux 2.6.9-42.0.3.ELsmp #1 SMP Thu Oct 5 16:29:37 CDT 2006 x86_64 x86_64 x86_64 GNU/Linux $ rpm -qa | grep openafs openafs-1.4.1-0.11.SL.x86_64 openafs-devel-1.4.7-68.SL4.x86_64 kernel-module-openafs-2.6.9-42.0.3.EL-1.4.1-0.11.SL.x86_64 openafs-firstboot-1.2.11-5.SL.noarch openafs-client-1.4.1-0.11.SL.x86_64 kernel-module-openafs-2.6.9-42.0.3.ELsmp-1.4.1-0.11.SL.x86_64 openafs-server-1.4.1-0.11.SL.x86_64 openafs-krb5-1.4.1-0.11.SL.x86_64 openafs-kpasswd-1.4.1-0.11.SL.x86_64 -- [Will Maier]-----------------[willmaier@ml1.net|http://www.lfod.us/] From shadow@gmail.com Wed Feb 4 21:42:05 2009 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 4 Feb 2009 16:42:05 -0500 Subject: [OpenAFS] Prolonged period of blocked connections In-Reply-To: <20090204213852.GF11427@lass.lfod.us> References: <20090204213852.GF11427@lass.lfod.us> Message-ID: On Wed, Feb 4, 2009 at 4:38 PM, Will Maier wrote: > Hi folks- > > In the past, we've observed prolonged periods where one or more of > our servers would report more than 200 calls waiting for a thread. > This occurred again this morning and lasted for about four hours. bos status (fileserverhost) fs -long and post that information? However, lots of bugs which would affect this fixed since 1.4.1, which is ancient. > While the server reported the blocked calls, top showed that the > fileserver was pegged at >= 100% CPU and FileLog (with verbosity > increased via SIGTSTP) showed a huge number of SAFS_FetchStatuses > (and very little else). > > During this time, I also noticed that the number of blocked calls > seemed to oscillate between 0 and ~220 over a period of about 100 > seconds (with ~1300 total clients according to the hosts.dump file). > This made me wonder if there wasn't some component that was > periodically clearing the backlog and, if so, if the period might be > easily modifiable. > > This condition tends to coincide with a large number of batch jobs > that, unfortunately, must get some of their shared libraries, > binaries and configuration/seed files from our AFS cell. We've done > as much as we can to limit the amount of data in AFS that these jobs > require, but we still observe blocked calls, especially when a large > number of jobs spin up at approximately the same time. It's also > possible that the jobs are overwhelming the clients' caches, which > could conceivably cause extra/spurious calls to the server. Is this > a possibility? > > If the periodicity of the backlog's level is a red herring, is there > something else we might consider? Yes. OpenAFS 1.4.8. -- Derrick From willmaier@ml1.net Wed Feb 4 21:51:51 2009 From: willmaier@ml1.net (Will Maier) Date: Wed, 4 Feb 2009 15:51:51 -0600 Subject: [OpenAFS] Prolonged period of blocked connections In-Reply-To: References: <20090204213852.GF11427@lass.lfod.us> Message-ID: <20090204215151.GG11427@lass.lfod.us> Hi Derrick- On Wed, Feb 04, 2009 at 04:42:05PM -0500, Derrick Brashear wrote: > On Wed, Feb 4, 2009 at 4:38 PM, Will Maier wrote: > > In the past, we've observed prolonged periods where one or more of > > our servers would report more than 200 calls waiting for a thread. > > This occurred again this morning and lasted for about four hours. > > bos status (fileserverhost) fs -long > > and post that information? Here's what I get: Instance fs, (type is fs) currently running normally. Auxiliary status is: file server running. Process last started at Wed Feb 4 12:01:36 2009 (6 proc starts) Last exit at Wed Feb 4 12:01:36 2009 Command 1 is '/usr/afs/bin/fileserver' Command 2 is '/usr/afs/bin/volserver' Command 3 is '/usr/afs/bin/salvager' Here's what top says currently: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3084 root 11 -5 204m 17m 1216 S 174 0.2 299:30.71 fileserver And, for good measure, here's what rxdbebug shows for the server, too: Free packets: 242, packet reclaims: 202, calls: 120829063, used FDs: 64 not waiting for packets. 226 calls waiting for a thread 2 threads are idle > However, lots of bugs which would affect this fixed since 1.4.1, > which is ancient. Indeed. We've been upgrading within RHEL releases so far, but we're planning to jump from RHEL4 (sigh) to RHEL5 (finally) in the near future. That should, at a glance, get us to at least 1.4.7. Thanks! -- [Will Maier]-----------------[willmaier@ml1.net|http://www.lfod.us/] From shadow@gmail.com Wed Feb 4 22:13:47 2009 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 4 Feb 2009 17:13:47 -0500 Subject: [OpenAFS] Prolonged period of blocked connections In-Reply-To: <20090204215151.GG11427@lass.lfod.us> References: <20090204213852.GF11427@lass.lfod.us> <20090204215151.GG11427@lass.lfod.us> Message-ID: On Wed, Feb 4, 2009 at 4:51 PM, Will Maier wrote: > Hi Derrick- > > On Wed, Feb 04, 2009 at 04:42:05PM -0500, Derrick Brashear wrote: >> On Wed, Feb 4, 2009 at 4:38 PM, Will Maier wrote: >> > In the past, we've observed prolonged periods where one or more of >> > our servers would report more than 200 calls waiting for a thread. >> > This occurred again this morning and lasted for about four hours. >> >> bos status (fileserverhost) fs -long >> >> and post that information? > > Here's what I get: > > Instance fs, (type is fs) currently running normally. > Auxiliary status is: file server running. > Process last started at Wed Feb 4 12:01:36 2009 (6 proc starts) > Last exit at Wed Feb 4 12:01:36 2009 > Command 1 is '/usr/afs/bin/fileserver' which means you have some very small number of threads -p 128, for starters, would make life much better, but... > Command 2 is '/usr/afs/bin/volserver' > Command 3 is '/usr/afs/bin/salvager' > > Here's what top says currently: > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 3084 root 11 -5 204m 17m 1216 S 174 0.2 299:30.71 fileserver > > And, for good measure, here's what rxdbebug shows for the server, too: > > Free packets: 242, packet reclaims: 202, calls: 120829063, used FDs: 64 > not waiting for packets. > 226 calls waiting for a thread > 2 threads are idle > > >> However, lots of bugs which would affect this fixed since 1.4.1, >> which is ancient. > > Indeed. We've been upgrading within RHEL releases so far, but we're > planning to jump from RHEL4 (sigh) to RHEL5 (finally) in the near > future. That should, at a glance, get us to at least 1.4.7. 1.4.8 exists for RHEL5, and RHEL4.... From David.Bear@asu.edu Fri Feb 6 01:09:09 2009 From: David.Bear@asu.edu (David Bear) Date: Thu, 5 Feb 2009 18:09:09 -0700 Subject: [OpenAFS] encrypted volumes Message-ID: <1d1a54bf0902051709p45019be6v9cd76fe3275182d7@mail.gmail.com> --0015175cb9380c40d8046235abd1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Has there ever been much discussion on created encrypted volumes? These would work like a local encrypted file system - without they key, they are useless. I'm thinking that you might need an fs setkey or something like that to insert the key into the cache manager.. fs mkmount could have a switch that would specify it was an encrypted volume.. simple musing... -- David Bear College of Public Programs at ASU 602-464-0424 --0015175cb9380c40d8046235abd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Has there ever been much discussion  on created encrypted volumes? =  These would work like a local encrypted file system - without they ke= y, they are useless.  I'm thinking that you might need an fs setke= y or something like that to insert the key into the cache manager.. fs mkmo= unt could have a switch that would specify it was an encrypted volume..

simple musing...


--
David Bear
College o= f Public Programs at ASU
602-464-0424
--0015175cb9380c40d8046235abd1-- From David.Bear@asu.edu Fri Feb 6 01:38:47 2009 From: David.Bear@asu.edu (David Bear) Date: Thu, 5 Feb 2009 18:38:47 -0700 Subject: [OpenAFS] trouble loading the kernel module In-Reply-To: References: <1d1a54bf0902021310v6e1fc139na75d97137f7848aa@mail.gmail.com> <1d1a54bf0902021714k2bfc6bffwbdf6fdc5bd9dd27d@mail.gmail.com> Message-ID: <1d1a54bf0902051738w3a7effa7vd496d63184b28ed7@mail.gmail.com> --0015175cd2ca09413104623615fa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Thank you Simon for helping find all the zeros, ones, and dashes in the correct order. Time for new glasses...This worked. On Tue, Feb 3, 2009 at 2:24 AM, Simon Wilkinson wrote: > > On 3 Feb 2009, at 01:14, David Bear wrote: > > Thanks for the suggestion Simon. However, I think my kernel and >> kernel-mods match -- unless I'm reading this wrong: >> >> locate afs | grep ko >> /lib/modules/2.6.9-78.0.1.EL/extra/openafs/openafs.ko >> >> $ uname -a >> Linux 2.6.9-78.0.13.ELsmp #1 SMP Wed Jan 7 17:45:52 EST 2009 x86_64 >> x86_64 x86_64 GNU/Linux >> >> No, those don't match. > > 2.6.9-78.0.1.EL != 2.6.9-78.0.13.EL > > I thought since the kernel says its SMP that I might need >> >> >> http://openafs.org/dl/openafs/1.4.8/rhel4/x86_64/kmod-openafs-smp-1.4.8-1.1.2.6.9_78.EL.x86_64.rpm >> >> That kernel is for 2.6.9-78-EL, not 2.6.9-78-0.13-EL > > I think you probably want > /afs/grand.central.org/software/openafs/1.4.8/rhel4/x86_64/kmod- > openafs-smp-1.4.8-1.1.2.6.9_78.0.13.EL.x86_64.rpm > > S. > > -- David Bear College of Public Programs at ASU 602-464-0424 --0015175cd2ca09413104623615fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you Simon for helping find all the zeros, ones, and dashes in the cor= rect order. Time for new glasses...This worked.

On Tue, Feb 3, 2009 at 2:24 AM, Simon Wilkinson &l= t;sxw@inf.ed.ac.uk> wrote= :

On 3 Feb 2009, at 01:14, David Bear wrote:

Thanks for the suggestion Simon. However, I think my kernel and kernel-mods= match -- unless I'm reading this wrong:

locate afs | grep ko
/lib/modules/2.6.9-78.0.1.EL/extra/openafs/openafs.ko

$ uname -a
Linux  2.6.9-78.0.13.ELsmp #1 SMP Wed Jan 7 17:45:52 EST 2009 x86_64 x= 86_64 x86_64 GNU/Linux

No, those don't match.

2.6.9-78.0.1.EL !=3D 2.6.9-78.0.13.EL That kernel is for 2.6.9-78-EL, not 2.6.9-78-0.13-EL

I think you probably want
/afs/grand.central.org/software/openafs/1.4.8/rhel4/x= 86_64/kmod-openafs-smp-1.4.8-1.1.2.6.9_78.0.13.EL.x86_64.rpm

S.




--
David Bear
Co= llege of Public Programs at ASU
602-464-0424
--0015175cd2ca09413104623615fa-- From jason@rampaginggeek.com Fri Feb 6 13:43:23 2009 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Fri, 06 Feb 2009 08:43:23 -0500 Subject: [OpenAFS] encrypted volumes In-Reply-To: <1d1a54bf0902051709p45019be6v9cd76fe3275182d7@mail.gmail.com> References: <1d1a54bf0902051709p45019be6v9cd76fe3275182d7@mail.gmail.com> Message-ID: <498C3E7B.90303@rampaginggeek.com> David Bear wrote: > > Has there ever been much discussion on created encrypted volumes? > These would work like a local encrypted file system - without they > key, they are useless. I'm thinking that you might need an fs setkey > or something like that to insert the key into the cache manager.. fs > mkmount could have a switch that would specify it was an encrypted > volume.. > > simple musing... > Why not just use a truecrypt to mount a file from an AFS volume as an encrypted volume? Jason From cclausen@acm.org Fri Feb 6 17:51:21 2009 From: cclausen@acm.org (Christopher D. Clausen) Date: Fri, 6 Feb 2009 11:51:21 -0600 Subject: [OpenAFS] encrypted volumes References: <1d1a54bf0902051709p45019be6v9cd76fe3275182d7@mail.gmail.com> <498C3E7B.90303@rampaginggeek.com> Message-ID: <35A3FA4ABE9E42A0BBEC7C95EEF03340@CDCHOME> Jason Edgecombe wrote: > Why not just use a truecrypt to mount a file from an AFS volume as an > encrypted volume? I've found that mounting anything (even ISOs on loopback) out of AFS causes serious system hangs and/or crashes. < References: <1d1a54bf0902051709p45019be6v9cd76fe3275182d7@mail.gmail.com> <498C3E7B.90303@rampaginggeek.com> Message-ID: <1d1a54bf0902061012y3ebc04exd2f5868f0e88138b@mail.gmail.com> --00163642719e168466046243f781 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Fri, Feb 6, 2009 at 6:43 AM, Jason Edgecombe wrote: > David Bear wrote: > > > > Has there ever been much discussion on created encrypted volumes? > > These would work like a local encrypted file system - without they > > key, they are useless. I'm thinking that you might need an fs setkey > > or something like that to insert the key into the cache manager.. fs > > mkmount could have a switch that would specify it was an encrypted > > volume.. > > > > simple musing... > > > Why not just use a truecrypt to mount a file from an AFS volume as an > encrypted volume? > > Jason > well -- I don't know about truecrypt -- and doubt that windows, mac and linux de jour does as well. AFS volumes represent a very convenient way to have multiple offsite backups of stuff -- and would be a great platform to build a service on like 'carbonite' or the iron mountain data backup solution. Having encrypted volumes would really make this kind of service sing. -- David Bear College of Public Programs at ASU 602-464-0424 --00163642719e168466046243f781 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 6, 2009 at 6:43 AM, Jason Ed= gecombe <ja= son@rampaginggeek.com> wrote:
David Bear wrote:
>
> Has there ever been much discussion  on created encrypted volumes= ?
>  These would work like a local encrypted file system - without th= ey
> key, they are useless.  I'm thinking that you might need an f= s setkey
> or something like that to insert the key into the cache manager.. fs > mkmount could have a switch that would specify it was an encrypted
> volume..
>
> simple musing...
>
Why not just use a truecrypt to mount a file from an AFS volume as an=
encrypted volume?

Jason

well -- I don't know about truecrypt -- a= nd doubt that windows, mac and linux de jour does as well.

AFS volu= mes represent a very convenient way to have multiple offsite backups of stu= ff -- and would be a great platform to build a service on like 'carboni= te' or the iron mountain data backup solution. Having encrypted volumes= would really make this kind of service sing.

--
David Bear
College of Public Programs at ASU
602-464-0424<= br> --00163642719e168466046243f781-- From christopher.rob.jones@cern.ch Fri Feb 6 18:21:32 2009 From: christopher.rob.jones@cern.ch (Chris Jones) Date: Fri, 6 Feb 2009 18:21:32 +0000 Subject: [OpenAFS] encrypted volumes In-Reply-To: <1d1a54bf0902061012y3ebc04exd2f5868f0e88138b@mail.gmail.com> References: <1d1a54bf0902051709p45019be6v9cd76fe3275182d7@mail.gmail.com> <498C3E7B.90303@rampaginggeek.com> <1d1a54bf0902061012y3ebc04exd2f5868f0e88138b@mail.gmail.com> Message-ID: <8483EF61-E4CF-4381-9CBF-9035B1CCF8B9@cern.ch> --Apple-Mail-1-86738642 Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 6 Feb 2009, at 6:12PM, David Bear wrote: > > > On Fri, Feb 6, 2009 at 6:43 AM, Jason Edgecombe > wrote: > David Bear wrote: > > > > Has there ever been much discussion on created encrypted volumes? > > These would work like a local encrypted file system - without they > > key, they are useless. I'm thinking that you might need an fs > setkey > > or something like that to insert the key into the cache manager.. fs > > mkmount could have a switch that would specify it was an encrypted > > volume.. > > > > simple musing... > > > Why not just use a truecrypt to mount a file from an AFS volume as an > encrypted volume? > > Jason > > well -- I don't know about truecrypt -- and doubt that windows, mac > and linux de jour does as well. Actually, truecrypt is available for all of the above ;) > http://www.truecrypt.org/ Its probably one of the best ways of having cross platform encryption. cheers Chris --Apple-Mail-1-86738642 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
On 6 Feb 2009, at = 6:12PM, David Bear wrote:



On Fri, Feb 6, 2009 at 6:43 AM, Jason Edgecombe = <jason@rampaginggeek.com> wrote:
David Bear wrote:
>
> Has there = ever been much discussion  on created encrypted volumes?
> =  These would work like a local encrypted file system - without = they
> key, they are useless.  I'm thinking that you might need = an fs setkey
> or something like that to insert the key into the = cache manager.. fs
> mkmount could have a switch that would specify = it was an encrypted
> volume..
>
> simple musing...
= >
Why not just use a truecrypt to mount a file from an AFS = volume as an
encrypted volume?

= Jason

well -- I don't know about = truecrypt -- and doubt that windows, mac and linux de jour does as well. =

Actually, truecrypt is available for all of = the above ;)

http://www.truecrypt.org/

Its probably one of the best ways of having cross = platform encryption.

cheers = Chris

= --Apple-Mail-1-86738642-- From dirk.heinrichs@online.de Fri Feb 6 18:22:01 2009 From: dirk.heinrichs@online.de (Dirk Heinrichs) Date: Fri, 6 Feb 2009 19:22:01 +0100 Subject: [OpenAFS] encrypted volumes In-Reply-To: <1d1a54bf0902051709p45019be6v9cd76fe3275182d7@mail.gmail.com> References: <1d1a54bf0902051709p45019be6v9cd76fe3275182d7@mail.gmail.com> Message-ID: <200902061922.10000.dirk.heinrichs@online.de> --nextPart2152820.mAQUJEx9FA Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Freitag, 6. Februar 2009 02:09:09 schrieb David Bear: > Has there ever been much discussion on created encrypted volumes? These > would work like a local encrypted file system - without they key, they are > useless. I'm thinking that you might need an fs setkey or something like > that to insert the key into the cache manager.. fs mkmount could have a > switch that would specify it was an encrypted volume.. The problem is that volumes in AFS are not mounted and unmounted all the ti= me.=20 The are mounted into the tree once and are usually available anytime. To=20 prevent access to sensitive files, use ACLs. Things like ecryptfs, truecrypt or LUKS only protect data as long as the=20 volume is _not_ mounted. Once mounted, normal Unix access permissions or AC= Ls=20 apply. So what you could do is to create encrypted vice partitions and put= =20 volumes with sensitive data onto those, so that in case of theft or whateve= r=20 the data cannot be read by the attacker. HTH... Dirk --nextPart2152820.mAQUJEx9FA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iD8DBQBJjH/R8NVtnsLkZ7sRAv+lAJsG/EzMMOXcz6w3iMhwEdQfktejCQCbBTAQ V7v3zK5Ml0WdAdYh5W9xnq4= =ARt5 -----END PGP SIGNATURE----- --nextPart2152820.mAQUJEx9FA-- From dirk.heinrichs@online.de Fri Feb 6 18:27:13 2009 From: dirk.heinrichs@online.de (Dirk Heinrichs) Date: Fri, 6 Feb 2009 19:27:13 +0100 Subject: [OpenAFS] encrypted volumes In-Reply-To: <1d1a54bf0902061012y3ebc04exd2f5868f0e88138b@mail.gmail.com> References: <1d1a54bf0902051709p45019be6v9cd76fe3275182d7@mail.gmail.com> <498C3E7B.90303@rampaginggeek.com> <1d1a54bf0902061012y3ebc04exd2f5868f0e88138b@mail.gmail.com> Message-ID: <200902061927.19090.dirk.heinrichs@online.de> --nextPart1634167.f3hYRWW4zF Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Freitag, 6. Februar 2009 19:12:34 schrieb David Bear: > well -- I don't know about truecrypt -- and doubt that windows, mac and > linux de jour does as well. Well, they do. > AFS volumes represent a very convenient way to have multiple offsite > backups of stuff -- and would be a great platform to build a service on > like 'carbonite' or the iron mountain data backup solution. Having > encrypted volumes would really make this kind of service sing. No. Backup volumes are _not_ a real backup. They are snapshots of the rw=20 volumes which can be used to take a backup from without fear that the data= =20 changes in between. Being a snapshot, they usually stay where their rw volu= me=20 is. So what you really want is not encrypted volumes, but an encrypted back= up.=20 That's a totally different thing. Bye... Dirk --nextPart1634167.f3hYRWW4zF Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iD8DBQBJjIEH8NVtnsLkZ7sRAtjbAJ9fTwes5QPLEZXJGTJ9AFp+8dFN5ACgrQvl UB+0taZoJT9zjzlCyBGjaxs= =o42P -----END PGP SIGNATURE----- --nextPart1634167.f3hYRWW4zF-- From christof.hanke@induhviduals.de Fri Feb 6 20:45:02 2009 From: christof.hanke@induhviduals.de (Christof Hanke) Date: Fri, 6 Feb 2009 22:45:02 +0200 Subject: [OpenAFS] encrypted volumes Message-ID: <200902062245.02335.christof.hanke@induhviduals.de> > Am Freitag, 6. Februar 2009 02:09:09 schrieb David Bear: >> Has there ever been much discussion on created encrypted volumes? These >> would work like a local encrypted file system - without they key, they are >> useless. I'm thinking that you might need an fs setkey or something like >> that to insert the key into the cache manager.. fs mkmount could have a >> switch that would specify it was an encrypted volume.. >The problem is that volumes in AFS are not mounted and unmounted all the time. >The are mounted into the tree once and are usually available anytime. To >prevent access to sensitive files, use ACLs. >Things like ecryptfs, truecrypt or LUKS only protect data as long as the >volume is _not_ mounted. Once mounted, normal Unix access permissions or ACLs >apply. So what you could do is to create encrypted vice partitions and put >volumes with sensitive data onto those, so that in case of theft or whatever >the data cannot be read by the attacker. Sorry, but I think you see this from the wrong angle. The point I think here is to protect sensitive data even against admins, the guys who can read /vicep* anyway... Having said this, it is clear the encryption has to be on the client side. Thus I guess a way to implement this could be : * each Volume has an attribute "encryption-UUID" if the Volume is not encrypted this value is just empty. * A client can have multiple encryption-keys wich are set with "fs setkey -uuid=blah -passphrase=blahblah -alg=superblah" * if the client wants to read from a volume which has an "encryption-UUID" it looks into it's internal table for this UUID and tries to encrypt it with the matching parameters, if there's no such entry it just returns the raw data. I haven't thought about how to implement this *really*, but I hope this could continue the discussion... T/Christof BTW: this could be "easily" extended to the directory- or file-level... From dirk.heinrichs@online.de Fri Feb 6 21:21:21 2009 From: dirk.heinrichs@online.de (Dirk Heinrichs) Date: Fri, 6 Feb 2009 22:21:21 +0100 Subject: [OpenAFS] encrypted volumes In-Reply-To: <200902062245.02335.christof.hanke@induhviduals.de> References: <200902062245.02335.christof.hanke@induhviduals.de> Message-ID: <200902062221.27808.dirk.heinrichs@online.de> --nextPart2080950.gCY9xQCKCv Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Freitag, 6. Februar 2009 21:45:02 schrieb Christof Hanke: > Sorry, but I think you see this from the wrong angle. > The point I think here is to protect sensitive data even against admins, > the guys who can read /vicep* anyway... What prevents an admin from loggin in on the client machine to read the dat= a=20 while the volume is mounted? > Having said this, it is clear the encryption has to be on the client side. I guess the best would be if it would happen at application level. Means: l= et=20 application store their data as GPG-encrypted files directly. Bye... Dirk --nextPart2080950.gCY9xQCKCv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iD8DBQBJjKnX8NVtnsLkZ7sRAmppAJ4rQXl6sGsuCOp+Ydo3r9lgxBqIFgCfZRGr SwE/RICCgYocRerwXZW1PvA= =91Be -----END PGP SIGNATURE----- --nextPart2080950.gCY9xQCKCv-- From pantzer@ludd.ltu.se Fri Feb 6 22:25:16 2009 From: pantzer@ludd.ltu.se (Mattias Pantzare) Date: Fri, 6 Feb 2009 23:25:16 +0100 Subject: [OpenAFS] encrypted volumes In-Reply-To: <200902062221.27808.dirk.heinrichs@online.de> References: <200902062245.02335.christof.hanke@induhviduals.de> <200902062221.27808.dirk.heinrichs@online.de> Message-ID: <1c2dec420902061425y6671a0b2rde6c9b25eefe98bf@mail.gmail.com> On Fri, Feb 6, 2009 at 22:21, Dirk Heinrichs wrote: > Am Freitag, 6. Februar 2009 21:45:02 schrieb Christof Hanke: > >> Sorry, but I think you see this from the wrong angle. >> The point I think here is to protect sensitive data even against admins, >> the guys who can read /vicep* anyway... > > What prevents an admin from loggin in on the client machine to read the data > while the volume is mounted? To do that the admin has to have a valid user on the client machine. The client and the server do not have to be administered by the same people. The users real and the servers kerberos realm might not even be the same realm. From christof.hanke@induhviduals.de Fri Feb 6 22:31:52 2009 From: christof.hanke@induhviduals.de (Christof Hanke) Date: Sat, 7 Feb 2009 00:31:52 +0200 Subject: [OpenAFS] encrypted volumes In-Reply-To: <1c2dec420902061425y6671a0b2rde6c9b25eefe98bf@mail.gmail.com> References: <200902062245.02335.christof.hanke@induhviduals.de> <200902062221.27808.dirk.heinrichs@online.de> <1c2dec420902061425y6671a0b2rde6c9b25eefe98bf@mail.gmail.com> Message-ID: <200902070031.52900.christof.hanke@induhviduals.de> Am Samstag, 7. Februar 2009 00:25:16 schrieb Mattias Pantzare: > On Fri, Feb 6, 2009 at 22:21, Dirk Heinrichs wrote: > > Am Freitag, 6. Februar 2009 21:45:02 schrieb Christof Hanke: > >> Sorry, but I think you see this from the wrong angle. > >> The point I think here is to protect sensitive data even against admins, > >> the guys who can read /vicep* anyway... > > > > What prevents an admin from loggin in on the client machine to read the > > data while the volume is mounted? > > To do that the admin has to have a valid user on the client machine. > The client and the server do not have to be administered by the same > people. The users real and the servers kerberos realm might not even > be the same realm. It is worse than that. The admin must break into the PAG of the user having activated decryption. From openafs-info@openafs.org Sat Feb 7 14:04:41 2009 From: openafs-info@openafs.org (Matthias Teege) Date: Sat, 7 Feb 2009 15:04:41 +0100 Subject: [OpenAFS] encrypted volumes In-Reply-To: <200902062245.02335.christof.hanke@induhviduals.de> Message-ID: <4f48b4a6f9561affac1dc1b151c5a366@mteege.de> > The point I think here is to protect sensitive data even against admins, the > guys who can read /vicep* anyway... We are using encfs [1] on top of AFS for scenarios like yours. Matthias [1] http://www.arg0.net/encfs From ttelford.groups@gmail.com Tue Feb 10 19:08:49 2009 From: ttelford.groups@gmail.com (Troy Telford) Date: Tue, 10 Feb 2009 12:08:49 -0700 Subject: [OpenAFS] AFS to NFS translator in Linux Message-ID: <4991D0C1.6070102@gmail.com> Where can I find some information on how to use the AFS->NFS translator on Linux? (Does it even exist?) Basically, I'm looking for read-only access, in situations where it's either inconvenient or impossible to compile the AFS kernel modules; I have a couple of systems where the module compiles OK, but doesn't load. (Namely OpenSUSE 11.1, using packages from build.opensuse.org) From danielg@teragram.com Tue Feb 10 20:00:36 2009 From: danielg@teragram.com (Daniel Richard G.) Date: Tue, 10 Feb 2009 15:00:36 -0500 Subject: [OpenAFS] AFS to NFS translator in Linux In-Reply-To: <4991D0C1.6070102@gmail.com> References: <4991D0C1.6070102@gmail.com> Message-ID: <006401c98bba$422b4640$c681d2c0$@com> > Where can I find some information on how to use the > AFS->NFS translator on > Linux? (Does it even exist?) My understanding is that the translator currently does not work on Linux. (I do believe it works on Solaris.) > Basically, I'm looking for read-only access, in > situations where it's either > inconvenient or impossible to compile the AFS kernel > modules; I have a couple > of systems where the module compiles OK, but doesn't > load. (Namely OpenSUSE > 11.1, using packages from build.opensuse.org) We use UNFS3 (http://unfs3.sf.net/) for this exact purpose, exporting to a number of old-school Unix systems. I added proper AFS FID support to it recently, so that its filehandle cache plays well with AFS. We run it via kstart so that it keeps the tickets/tokens required to read what it needs out of AFS. I've been meaning to send a note about this to the list, to let folks know about this new AFS->NFS option on Linux. If any AFS gurus could have a peek at afssupport.c in the codebase, I would be grateful for any feedback on the implementation. --Daniel From summatusmentis@gmail.com Tue Feb 10 20:04:59 2009 From: summatusmentis@gmail.com (Jake Thebault-Spieker) Date: Tue, 10 Feb 2009 14:04:59 -0600 Subject: [OpenAFS] AFS to NFS translator in Linux In-Reply-To: <4991D0C1.6070102@gmail.com> References: <4991D0C1.6070102@gmail.com> Message-ID: <2d18958c0902101204v39efe1b0qd4c9b47fddfd4dbb@mail.gmail.com> --000e0cd6ae42785e030462960012 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Tue, Feb 10, 2009 at 1:08 PM, Troy Telford wrote: > Where can I find some information on how to use the AFS->NFS translator on > Linux? (Does it even exist?) I think Daniel is right, in that it's either strenuously recommended against using the NFS translator, or it's completely non-functional on Linux. -- Jacob Thebault-Spieker Cell: (320) 288-6412 http://summatusmentis.wordpress.com --000e0cd6ae42785e030462960012 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 10, 2009 at 1:08 PM, Troy Telford <ttelford.g= roups@gmail.com> wrote:
Where can I find some information on how to use the AFS->NFS translator = on
Linux?  (Does it even exist?)

I think Daniel is r= ight, in that it's either strenuously recommended against using the NFS= translator, or it's completely non-functional on Linux.

--
Jacob Thebault-Spieker
Cell: (320) 288-6412
http://summatusmentis.wordpress.com --000e0cd6ae42785e030462960012-- From ragge@ltu.se Tue Feb 10 20:14:15 2009 From: ragge@ltu.se (Anders Magnusson) Date: Tue, 10 Feb 2009 21:14:15 +0100 Subject: [OpenAFS] AFS to NFS translator in Linux In-Reply-To: <006401c98bba$422b4640$c681d2c0$@com> References: <4991D0C1.6070102@gmail.com> <006401c98bba$422b4640$c681d2c0$@com> Message-ID: <4991E017.4010301@ltu.se> Daniel Richard G. wrote: >> Where can I find some information on how to use the >> AFS->NFS translator on >> Linux? (Does it even exist?) >> > > My understanding is that the translator currently does not work on Linux. (I > do believe it works on Solaris.) > > >> Basically, I'm looking for read-only access, in >> situations where it's either >> inconvenient or impossible to compile the AFS kernel >> modules; I have a couple >> of systems where the module compiles OK, but doesn't >> load. (Namely OpenSUSE >> 11.1, using packages from build.opensuse.org) >> > > We use UNFS3 (http://unfs3.sf.net/) for this exact purpose, exporting to a > number of old-school Unix systems. I added proper AFS FID support to it > recently, so that its filehandle cache plays well with AFS. We run it via > kstart so that it keeps the tickets/tokens required to read what it needs out > of AFS. > Interesting. How do you handle access control for users? Is that just left to the client with the normal uid/gid access bits? -- Ragge > I've been meaning to send a note about this to the list, to let folks know > about this new AFS->NFS option on Linux. If any AFS gurus could have a peek at > afssupport.c in the codebase, I would be grateful for any feedback on the > implementation. > > > --Daniel > > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > From vbfox@ucdavis.edu Tue Feb 10 20:23:05 2009 From: vbfox@ucdavis.edu (Vincent Fox) Date: Tue, 10 Feb 2009 12:23:05 -0800 Subject: [OpenAFS] AFS to NFS translator in Linux In-Reply-To: <006401c98bba$422b4640$c681d2c0$@com> References: <4991D0C1.6070102@gmail.com> <006401c98bba$422b4640$c681d2c0$@com> Message-ID: <4991E229.1050500@ucdavis.edu> Daniel Richard G. wrote: > My understanding is that the translator currently does not work on Linux. (I > do believe it works on Solaris.) > Well if you loosely define "work" as only flips out a few times a week. I ran it for a while on a multi-purposed Solaris admin server and it was inconveniencing us by taking out a semi-important admin server often. Then I moved NFS translator to a dedicated machine and got frustrated with it there too. Now I just a have a script that copies files out of AFS on a recurring basis, and reshares the resulting directory tree in NFS. Avoid the translator IMO. From shadow@gmail.com Tue Feb 10 20:26:06 2009 From: shadow@gmail.com (Derrick Brashear) Date: Tue, 10 Feb 2009 15:26:06 -0500 Subject: [OpenAFS] AFS to NFS translator in Linux In-Reply-To: <4991E229.1050500@ucdavis.edu> References: <4991D0C1.6070102@gmail.com> <006401c98bba$422b4640$c681d2c0$@com> <4991E229.1050500@ucdavis.edu> Message-ID: On Tue, Feb 10, 2009 at 3:23 PM, Vincent Fox wrote: > Daniel Richard G. wrote: >> >> My understanding is that the translator currently does not work on Linux. >> (I do believe it works on Solaris.) >> > > Well if you loosely define "work" as only flips out a few times a week. > I ran it for a while on a multi-purposed Solaris admin server and it was > inconveniencing us by taking out a semi-important admin server often. > Then I moved NFS translator to a dedicated machine and got frustrated > with it there too. You submitted bugs, right? -- Derrick From danielg@teragram.com Tue Feb 10 20:50:18 2009 From: danielg@teragram.com (Daniel Richard G.) Date: Tue, 10 Feb 2009 15:50:18 -0500 Subject: [OpenAFS] AFS to NFS translator in Linux In-Reply-To: <4991E017.4010301@ltu.se> References: <4991D0C1.6070102@gmail.com> <006401c98bba$422b4640$c681d2c0$@com> <4991E017.4010301@ltu.se> Message-ID: <006801c98bc1$2ee04b10$8ca0e130$@com> > > We use UNFS3 (http://unfs3.sf.net/) for this exact > purpose, exporting to a > > number of old-school Unix systems. I added proper > > > Interesting. How do you handle access control for > users? Is that just > left to the > client with the normal uid/gid access bits? Access control? What access control? :-) Our use case has only one effective "user" on the NFS side (an automatic nightly build process), so there isn't a need to restrict certain areas of the file space. If there were, however, I don't see why you couldn't use uid/gid bits in the normal manner. (On the AFS side, the server runs under a dedicated principal that restricts its access to only the areas it needs, so at least it cannot be used to break into restricted areas of AFS.) From vbfox@ucdavis.edu Tue Feb 10 21:01:01 2009 From: vbfox@ucdavis.edu (Vincent Fox) Date: Tue, 10 Feb 2009 13:01:01 -0800 Subject: [OpenAFS] AFS to NFS translator in Linux In-Reply-To: References: <4991D0C1.6070102@gmail.com> <006401c98bba$422b4640$c681d2c0$@com> <4991E229.1050500@ucdavis.edu> Message-ID: <4991EB0D.6080309@ucdavis.edu> Derrick Brashear wrote: > You submitted bugs, right? > > I believe I posted to the list at the time, and the response was *roughly* along the lines of: Dead function, no development We don't work on Solaris much anymore If I am mischaracterizing or misremembering forgive me. My data was RO and not critical that it be up to the minute synchronized with AFS so my workaround gave me results. I moved on with my life rather than bug-hunt it alone. From shadow@gmail.com Tue Feb 10 21:15:43 2009 From: shadow@gmail.com (Derrick Brashear) Date: Tue, 10 Feb 2009 16:15:43 -0500 Subject: [OpenAFS] AFS to NFS translator in Linux In-Reply-To: <4991EB0D.6080309@ucdavis.edu> References: <4991D0C1.6070102@gmail.com> <006401c98bba$422b4640$c681d2c0$@com> <4991E229.1050500@ucdavis.edu> <4991EB0D.6080309@ucdavis.edu> Message-ID: On Tue, Feb 10, 2009 at 4:01 PM, Vincent Fox wrote: > Derrick Brashear wrote: >> >> You submitted bugs, right? >> >> > > I believe I posted to the list at the time, and the > response was *roughly* along the lines of: > > Dead function, no development > We don't work on Solaris much anymore There have actually been a number of bugfixes done to the translator, Solaris and Linux, in the last year, so it's certainly not dead. Neither's the Solaris support. But, good enough. It's conceivable the bugs you hit are the ones we fixed. > If I am mischaracterizing or misremembering forgive me. It's ok. I just don't want the stuff to get lost/forgotten. From deengert@anl.gov Tue Feb 10 21:17:55 2009 From: deengert@anl.gov (Douglas E. Engert) Date: Tue, 10 Feb 2009 15:17:55 -0600 Subject: [OpenAFS] AFS to NFS translator in Linux In-Reply-To: References: <4991D0C1.6070102@gmail.com> <006401c98bba$422b4640$c681d2c0$@com> <4991E229.1050500@ucdavis.edu> Message-ID: <4991EF03.7000508@anl.gov> Derrick Brashear wrote: > On Tue, Feb 10, 2009 at 3:23 PM, Vincent Fox wrote: >> Daniel Richard G. wrote: >>> My understanding is that the translator currently does not work on Linux. >>> (I do believe it works on Solaris.) >>> >> Well if you loosely define "work" as only flips out a few times a week. >> I ran it for a while on a multi-purposed Solaris admin server and it was >> inconveniencing us by taking out a semi-important admin server often. >> Then I moved NFS translator to a dedicated machine and got frustrated >> with it there too. Sounds familiar. We only the translator to boot strap the AFS client. we now SCP the bootstrap info. > > You submitted bugs, right? No, It did seam like it was high on anyone's list to fix. Is it? > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From shadow@gmail.com Tue Feb 10 21:20:30 2009 From: shadow@gmail.com (Derrick Brashear) Date: Tue, 10 Feb 2009 16:20:30 -0500 Subject: [OpenAFS] AFS to NFS translator in Linux In-Reply-To: <4991EF03.7000508@anl.gov> References: <4991D0C1.6070102@gmail.com> <006401c98bba$422b4640$c681d2c0$@com> <4991E229.1050500@ucdavis.edu> <4991EF03.7000508@anl.gov> Message-ID: > Sounds familiar. We only the translator to boot strap the AFS client. > we now SCP the bootstrap info. >> >> You submitted bugs, right? > > No, It did seam like it was high on anyone's list to fix. > Is it? Regardless of if it's high "now", documenting what's there so it can get fixed is always the best scenario. -- Derrick From steven.jenkins@gmail.com Wed Feb 11 01:48:22 2009 From: steven.jenkins@gmail.com (Steven Jenkins) Date: Tue, 10 Feb 2009 20:48:22 -0500 Subject: [OpenAFS] dynamic allocation of vcaches Message-ID: We have a patch (in RT 124344) for adding support to Linux for dynamic allocation of vcaches rather than the current hard limit provided by the -stat flag to afsd. It currently does not have a command-line argument to turn it on (i.e., if the patch is applied, you get dynamic support), and I want to make sure the interface we provide is a reasonable one. I propose: afsd -stat -dynamic-vcaches where N would be the initial value of the number of vcache entries but that the cache manager could dynamically allocate as many as needed). Any concerns with that feature and interface? Thanks, Steven Jenkins From steven.jenkins@gmail.com Wed Feb 11 02:01:34 2009 From: steven.jenkins@gmail.com (Steven Jenkins) Date: Tue, 10 Feb 2009 21:01:34 -0500 Subject: [OpenAFS] Re: dynamic allocation of vcaches In-Reply-To: References: Message-ID: On Tue, Feb 10, 2009 at 8:48 PM, Steven Jenkins wrote: > We have a patch (in RT 124344) Derrick points out that the ticket number is actually 124334. My apologies on that typo. Steven From christof.hanke@induhviduals.de Wed Feb 11 07:42:54 2009 From: christof.hanke@induhviduals.de (Christof Hanke) Date: Wed, 11 Feb 2009 09:42:54 +0200 Subject: [OpenAFS] AFS to NFS translator in Linux In-Reply-To: <4991D0C1.6070102@gmail.com> References: <4991D0C1.6070102@gmail.com> Message-ID: <200902110942.54179.christof.hanke@induhviduals.de> On Tuesday 10 February 2009 21:08:49 Troy Telford wrote: > Where can I find some information on how to use the AFS->NFS translator on > Linux? (Does it even exist?) > > Basically, I'm looking for read-only access, in situations where it's > either inconvenient or impossible to compile the AFS kernel modules; I have > a couple of systems where the module compiles OK, but doesn't load. > (Namely OpenSUSE 11.1, using packages from build.opensuse.org) > What does /var/log/messages say when you try to load the module ? From leo@strike.wu-wien.ac.at Wed Feb 11 18:03:51 2009 From: leo@strike.wu-wien.ac.at (Alexander 'Leo' Bergolth) Date: Wed, 11 Feb 2009 19:03:51 +0100 Subject: [OpenAFS] sometimes loosing token on su Message-ID: <49931307.5040604@strike.wu-wien.ac.at> Hi! First of all: Yes, I have disabled pam_keyinit.so. :-) I am experiencing a very strange problem: On my workstation, switching to root using "su -" (or just su) normally works fine. However sometimes, when trying to "su" in a long running shell, I'm loosing my token. (See the example 1 below.) Logging in via ssh and then doing "su -" works fine though. (See example 2). It looks like there is something wrong with my PAG since after getting a new PAG and a token from within the broken PAG, "su -" keeps my token again. (Example 3) Even doing kinit and aklog -force (before doing su -) doesn't help. Syslog-output with pam_krb5.so debug enabled doesn't show anything suspecting. (See below.) Even commenting out pam_krb5.so just for the su doesn't help. Any hints? Thanks, --leo P.S.: I'm using openafs-1.4.8-30.fc10.i386 on Fedora 10 (kernel 2.6.27.9-159.fc10.i686.PAE). -------------------- Example 1 -------------------- [bergolth@ariel ~]$ tokens Tokens held by the Cache Manager: User's (AFS ID 5020) tokens for afs@wu-wien.ac.at [Expires Feb 12 15:57] --End of list-- [bergolth@ariel ~]$ id -G 3000 10 107 500 501 1098248117 [bergolth@ariel ~]$ keyctl show Session Keyring -3 --alswrv 0 3000 keyring: _ses.4114 480068621 ----s--v 0 0 \_ afs_pag: _pag [bergolth@ariel ~]$ su - [root@ariel ~]# tokens Tokens held by the Cache Manager: --End of list-- [root@ariel ~]# id -G 0 1 2 3 4 6 10 [root@ariel ~]# keyctl show Session Keyring -3 --alswrv 0 3000 keyring: _ses.4114 480068621 ----s--v 0 0 \_ afs_pag: _pag --------------------------------------------------- -------------------- Example 2 -------------------- [bergolth@ariel ~]$ ssh bergolth@ariel [bergolth@ariel:~]$ tokens Tokens held by the Cache Manager: Tokens for afs@wu-wien.ac.at [Expires Feb 12 15:57] --End of list-- [bergolth@ariel:~]$ id -G 3000 10 107 500 501 1098248255 [bergolth@ariel:~]$ keyctl show Session Keyring -3 --alswrv 0 0 keyring: _ses.13949 851940785 ----s--v 0 0 \_ afs_pag: _pag [bergolth@ariel:~]$ su - [root@ariel ~]# tokens Tokens held by the Cache Manager: Tokens for afs@wu-wien.ac.at [Expires Feb 12 15:57] --End of list-- [root@ariel ~]# id -G 0 1 2 3 4 6 10 [root@ariel ~]# keyctl show Session Keyring -3 --alswrv 0 0 keyring: _ses.13949 851940785 ----s--v 0 0 \_ afs_pag: _pag --------------------------------------------------- -------------------- Example 3 -------------------- [bergolth@ariel ~]$ id -G 3000 10 107 500 501 1098248117 [bergolth@ariel ~]$ keyctl show Session Keyring -3 --alswrv 0 3000 keyring: _ses.4114 480068621 ----s--v 0 0 \_ afs_pag: _pag [bergolth@ariel ~]$ pagsh sh-3.2$ id -G 3000 10 107 500 501 1098248260 sh-3.2$ keyctl show Session Keyring -3 --alswrv 5020 3000 keyring: _ses.14509 808791921 ----s--v 0 0 \_ afs_pag: _pag sh-3.2$ aklog sh-3.2$ tokens Tokens held by the Cache Manager: User's (AFS ID 5020) tokens for afs@wu-wien.ac.at [Expires Feb 12 19:49] --End of list-- sh-3.2$ su - [root@ariel ~]# tokens Tokens held by the Cache Manager: User's (AFS ID 5020) tokens for afs@wu-wien.ac.at [Expires Feb 12 19:49] --End of list-- --------------------------------------------------- -------------------- Syslog 1 -------------------- Feb 11 18:18:49 ariel su: pam_unix(su-l:session): session opened for user root by bergolth(uid=5020) Feb 11 18:18:49 ariel su: pam_krb5[13573]: default/local realm 'WU-WIEN.AC.AT' Feb 11 18:18:49 ariel su: pam_krb5[13573]: configured realm 'WU-WIEN.AC.AT' Feb 11 18:18:49 ariel su: pam_krb5[13573]: flag: debug Feb 11 18:18:49 ariel su: pam_krb5[13573]: flags: forwardable Feb 11 18:18:49 ariel su: pam_krb5[13573]: flag: no ignore_afs Feb 11 18:18:49 ariel su: pam_krb5[13573]: flag: no null_afs Feb 11 18:18:49 ariel su: pam_krb5[13573]: flag: user_check Feb 11 18:18:49 ariel su: pam_krb5[13573]: flag: no krb4_convert Feb 11 18:18:49 ariel su: pam_krb5[13573]: flag: krb4_convert_524 Feb 11 18:18:49 ariel su: pam_krb5[13573]: flag: krb4_use_as_req Feb 11 18:18:49 ariel su: pam_krb5[13573]: will try previously set password first Feb 11 18:18:49 ariel su: pam_krb5[13573]: will ask for a password if that fails Feb 11 18:18:49 ariel su: pam_krb5[13573]: will let libkrb5 ask questions Feb 11 18:18:49 ariel su: pam_krb5[13573]: flag: no use_shmem Feb 11 18:18:49 ariel su: pam_krb5[13573]: flag: external Feb 11 18:18:49 ariel su: pam_krb5[13573]: flag: warn Feb 11 18:18:49 ariel su: pam_krb5[13573]: ticket lifetime: 0s (0d,0h,0m,0s) Feb 11 18:18:49 ariel su: pam_krb5[13573]: renewable lifetime: 0s (0d,0h,0m,0s) Feb 11 18:18:49 ariel su: pam_krb5[13573]: banner: Kerberos 5 Feb 11 18:18:49 ariel su: pam_krb5[13573]: ccache dir: /tmp Feb 11 18:18:49 ariel su: pam_krb5[13573]: ccname template: FILE:%d/krb5cc_%U_XXXXXX Feb 11 18:18:49 ariel su: pam_krb5[13573]: keytab: FILE:/etc/krb5.keytab Feb 11 18:18:49 ariel su: pam_krb5[13573]: token strategy: v4,524,2b,rxk5 Feb 11 18:18:49 ariel su: pam_krb5[13573]: checking for externally-obtained v5 credentials Feb 11 18:18:49 ariel su: pam_krb5[13573]: KRB5CCNAME is not set, none found Feb 11 18:18:49 ariel su: pam_krb5[13573]: no v5 creds for user 'root', skipping session setup Feb 11 18:18:49 ariel su: pam_krb5[13573]: pam_open_session returning 0 (Success) -------------------------------------------------- -------------------- Syslog 2 -------------------- Feb 11 18:26:31 ariel su: pam_unix(su-l:session): session opened for user root by bergolth(uid=5020) Feb 11 18:26:31 ariel su: pam_krb5[14103]: default/local realm 'WU-WIEN.AC.AT' Feb 11 18:26:31 ariel su: pam_krb5[14103]: configured realm 'WU-WIEN.AC.AT' Feb 11 18:26:31 ariel su: pam_krb5[14103]: flag: debug Feb 11 18:26:31 ariel su: pam_krb5[14103]: flags: forwardable Feb 11 18:26:31 ariel su: pam_krb5[14103]: flag: no ignore_afs Feb 11 18:26:31 ariel su: pam_krb5[14103]: flag: no null_afs Feb 11 18:26:31 ariel su: pam_krb5[14103]: flag: user_check Feb 11 18:26:31 ariel su: pam_krb5[14103]: flag: no krb4_convert Feb 11 18:26:31 ariel su: pam_krb5[14103]: flag: krb4_convert_524 Feb 11 18:26:31 ariel su: pam_krb5[14103]: flag: krb4_use_as_req Feb 11 18:26:31 ariel su: pam_krb5[14103]: will try previously set password first Feb 11 18:26:31 ariel su: pam_krb5[14103]: will ask for a password if that fails Feb 11 18:26:31 ariel su: pam_krb5[14103]: will let libkrb5 ask questions Feb 11 18:26:31 ariel su: pam_krb5[14103]: flag: no use_shmem Feb 11 18:26:31 ariel su: pam_krb5[14103]: flag: external Feb 11 18:26:31 ariel su: pam_krb5[14103]: flag: warn Feb 11 18:26:31 ariel su: pam_krb5[14103]: ticket lifetime: 0s (0d,0h,0m,0s) Feb 11 18:26:31 ariel su: pam_krb5[14103]: renewable lifetime: 0s (0d,0h,0m,0s) Feb 11 18:26:31 ariel su: pam_krb5[14103]: banner: Kerberos 5 Feb 11 18:26:31 ariel su: pam_krb5[14103]: ccache dir: /tmp Feb 11 18:26:31 ariel su: pam_krb5[14103]: ccname template: FILE:%d/krb5cc_%U_XXXXXX Feb 11 18:26:31 ariel su: pam_krb5[14103]: keytab: FILE:/etc/krb5.keytab Feb 11 18:26:31 ariel su: pam_krb5[14103]: token strategy: v4,524,2b,rxk5 Feb 11 18:26:31 ariel su: pam_krb5[14103]: checking for externally-obtained v5 credentials Feb 11 18:26:31 ariel su: pam_krb5[14103]: KRB5CCNAME is not set, none found Feb 11 18:26:31 ariel su: pam_krb5[14103]: no v5 creds for user 'root', skipping session setup Feb 11 18:26:31 ariel su: pam_krb5[14103]: pam_open_session returning 0 (Success) -------------------------------------------------- -- e-mail ::: Leo.Bergolth (at) wu-wien.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria From ttelford.groups@gmail.com Wed Feb 11 23:20:50 2009 From: ttelford.groups@gmail.com (Troy Telford) Date: Wed, 11 Feb 2009 16:20:50 -0700 Subject: [OpenAFS] Files getting corrupted from some clients Message-ID: <49935D52.1090004@gmail.com> I've got a fairly small AFS cell - only a handful of systems connect to it, though all of them are over a fairly diverse range of Linux distributions. And I'm running into issues with files being corrupted. On the exact same volume, for instance, I can have a host that works fine with AFS - * I'll take the Linux Kernel source, and unpack it. * I then rename the directory that gets unpacked. * I then unpack the source again. * There are no differences in the two directories. And then I have other hosts where I can unpack the tarball, and end up with files that are truncated, missing sections of code, etc. I know you're not supposed to use AFS for database-like things, but it seems that if I can't even unpack a tarball without corruption, there's some sort of problem that needs to be resolved. All of my systems are using OpenAFS 1.4.8. The "problem" systems don't seem to follow any particular linux distribution - or kernel. I have had two systems that have the same binary kernel, the same source code, and one produces file corruption, and the other does not. I'm new to AFS - and am more accustomed to NFS; so I'm not sure if I'm just doing something that AFS doesn't handle well, or if AFS varies that much from client to client. I want to give it a chance, but getting corrupted files when a client writes to disk tends to put a damper on the whole experience. From christof.hanke@induhviduals.de Thu Feb 12 05:54:09 2009 From: christof.hanke@induhviduals.de (Christof Hanke) Date: Thu, 12 Feb 2009 07:54:09 +0200 Subject: [OpenAFS] AFS to NFS translator in Linux Message-ID: <200902120754.09515.christof.hanke@induhviduals.de> Am Donnerstag, 12. Februar 2009 01:06:06 schrieben Sie: > Christof Hanke wrote: > > On Tuesday 10 February 2009 21:08:49 Troy Telford wrote: > >> Where can I find some information on how to use the AFS->NFS translator > >> on Linux? (Does it even exist?) > >> > >> Basically, I'm looking for read-only access, in situations where it's > >> either inconvenient or impossible to compile the AFS kernel modules; I > >> have a couple of systems where the module compiles OK, but doesn't load. > >> (Namely OpenSUSE 11.1, using packages from build.opensuse.org) > > > > What does /var/log/messages say when you try to load the module ? > > I managed to fix that - basically SuSE puts its Module.symvers in a > different place than the module source was looking; fix that and it worked > fine. That's great! I have figured this out also by now and fixed the packages on opensuse.org. Thanks for the problem report anyway, just shows me that I should get a real test environment for all flavours soon... From haba@kth.se Thu Feb 12 10:18:09 2009 From: haba@kth.se (Harald Barth) Date: Thu, 12 Feb 2009 11:18:09 +0100 (CET) Subject: [OpenAFS] Files getting corrupted from some clients In-Reply-To: <49935D52.1090004@gmail.com> References: <49935D52.1090004@gmail.com> Message-ID: <20090212.111809.153194724.haba@habanero.pdc.kth.se> > I know you're not supposed to use AFS for database-like things, but it seems > that if I can't even unpack a tarball without corruption, there's some sort of > problem that needs to be resolved. True. > fairly diverse range of Linux distributions. What file system type(s) do you use for AFS caches? I use ext2 or ext3. Because the cache does not contain anything that _must_ survive a reboot (unless you use the experimental disconnected features in 1.5.x), I suggest ext2 for speed. I had really bad experiences with reiserfs. Does the corruption occur if you use memcache, too? > I'm new to AFS - and am more accustomed to NFS; so I'm not sure if I'm just > doing something that AFS doesn't handle well, or if AFS varies that much from > client to client. If it is of some consolidation for you or not I don't know, but I've run 1.4.8preX on 2000 Linux clients for some time and have upgraded to distro 1.4.8 yesterday. So if there is something basic wrong with 1.4.8 I will definitely notice (gulp). > I want to give it a chance, but getting corrupted files > when a client writes to disk tends to put a damper on the whole experience. No s*** sherlock. Harald. From l.schimmer@cgv.tugraz.at Thu Feb 12 10:32:18 2009 From: l.schimmer@cgv.tugraz.at (Lars Schimmer) Date: Thu, 12 Feb 2009 11:32:18 +0100 Subject: [OpenAFS] Files getting corrupted from some clients In-Reply-To: <20090212.111809.153194724.haba@habanero.pdc.kth.se> References: <49935D52.1090004@gmail.com> <20090212.111809.153194724.haba@habanero.pdc.kth.se> Message-ID: <4993FAB2.602@cgv.tugraz.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Harald Barth wrote: >> I know you're not supposed to use AFS for database-like things, but it= seems >> that if I can't even unpack a tarball without corruption, there's some= sort of >> problem that needs to be resolved. >=20 > True. >=20 >> fairly diverse range of Linux distributions. >=20 > What file system type(s) do you use for AFS caches? I use ext2 or > ext3. Because the cache does not contain anything that _must_ survive > a reboot (unless you use the experimental disconnected features in > 1.5.x), I suggest ext2 for speed. I had really bad experiences with > reiserfs. AFAIK you need to use a fs WITHOUT a journal for cache partitions, so far I only use ext2. I do not know if that is resolved or not. For me/our cell, we run still 1.4.7 (and older clients) and have not seen a data corruptness for years AFAIR. > Harald. MfG, Lars Schimmer - -- - ------------------------------------------------------------- TU Graz, Institut f=FCr ComputerGraphik & WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schimmer@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmT+rIACgkQmWhuE0qbFyOAdwCeNXwhzVe/guw+bOCUTT9+YY4u VisAmwa8LqkvVJjWLMPLPy+f5+Hr3gTa =3D0k7q -----END PGP SIGNATURE----- From glenn@kth.se Mon Feb 2 15:19:20 2009 From: glenn@kth.se (Glenn Bjorcken) Date: Mon, 02 Feb 2009 16:19:20 +0100 Subject: [OpenAFS] move RO volume In-Reply-To: <31BE740B88C.00000324clc31@inbox.com> References: <31BE740B88C.00000324clc31@inbox.com> Message-ID: <49870EF8.9080804@kth.se> Chaz Chandler wrote: >You could do it another way: vos dump from source partition and vos rest= ore to >destination. But generally the easiest way is addsite/remsite. > >Note that vos remsite is the command to remove an RO volume, not vos rem= ove. > =20 > Well, if you do that you just remove it from the VLDB, and leave the=20 actual volume on the server, and usally thats not what you want to do. (even if it can be in special cases.) If I want to move a RO copy I first do a vos addsite, then vos release=20 and then vos remove on the old site. >The order doesn't matter, but you would vos addsite the volume on the de= stination >partition and (optionally) vos remsite the volume on the source partitio= n. > >It's generally best to keep your RW and RO volume on the same partition = if disk space is >an issue. > =20 > Its probably depends on what you are using RO volumes for, but I would=20 say that you usally want both a RO copy on the same partition (its basically free) and then another RO copy on=20 another fileserver, or at least another partition. --=20 ___=20 / __\ __ | UNIX System administrator at | __ / /__ / /__ ____ ____ __ | ICT / KTH Kista | (__/ /_ // / -_) _ ) _ )__) | Email =C2=AB=C2=BB Glenn@kth.se = | \___//_/\__/_//_/_//_/ | Phone =C2=AB=C2=BB +46 8 790 4228= | =20 "Where the russian heart is strong, like the beating of a drum, Where the magic lingers on and the fight for truth is won.. Deep in the European soul.." From shadow@gmail.com Thu Feb 12 20:32:43 2009 From: shadow@gmail.com (Derrick Brashear) Date: Thu, 12 Feb 2009 15:32:43 -0500 Subject: [OpenAFS] openafs kernel module In-Reply-To: References: Message-ID: On Fri, Jan 30, 2009 at 10:38 PM, David Miguel wrote: > Hello, > > I'm trying to install openafs client on a fedora 9 computer. > I installed the rpm's in the www.openafs.org site. > However there is no suitable kmod rpm for my kernel, therefore I don't have > openafs kernel module. > > So I built a kernel module from source, and I got a file named "libafs.ko". > I then renamed this file to openafs.ko. > But when I "insmod openafs.ko", lsmod shows libafs, and not openafs. > > I belive that is the cause of this error message: > > [root@afs openafs-1.5.56]# /etc/init.d/openafs-client start 1.5.56 isn't current; and do you really intend to run a development version? if so, look at 1.5.57. if not, 1.4.8. kmod-openafs-1.4.8-1.1.2.6.27.12_78.2.8.fc9.i686.rpm certainly exists. From v.konrad@lse.ac.uk Fri Feb 13 13:19:27 2009 From: v.konrad@lse.ac.uk (Vladimir Konrad) Date: Fri, 13 Feb 2009 13:19:27 +0000 Subject: [OpenAFS] openafs and screen command - loosing tokens Message-ID: <20090213131927.160d3acc@whirlpool.lse.ac.uk> Hello, I (+ my users) would like to run long running jobs under "screen" command, but currently the job looses access to afs after a user logs out. I tried running kinit + aklog within the "screen" session, but this makes no difference. Is there a way to open a screen command and get tokens specific to this session? I guess this is related to -setpag, but this is not reliable AFAIK. The platforms in question are: Debian Etch - on the servers, with AFS client version 1.4.7 Debian Etch or Lenny on the desktops. Kind regards, Vlad ------ > because it reverses the logical flow of conversation + it is hard to follow. >> why not? >>> do not put a reply at the top of the message, please... Please access the attached hyperlink for an important electronic communications disclaimer: http://www.lse.ac.uk/collections/secretariat/legal/disclaimer.htm From kula@tproa.net Fri Feb 13 14:38:38 2009 From: kula@tproa.net (Thomas Kula) Date: Fri, 13 Feb 2009 09:38:38 -0500 Subject: [OpenAFS] openafs and screen command - loosing tokens In-Reply-To: <20090213131927.160d3acc@whirlpool.lse.ac.uk> References: <20090213131927.160d3acc@whirlpool.lse.ac.uk> Message-ID: <20090213143838.GB543@mcketrick.tproa.net> On Fri, Feb 13, 2009 at 01:19:27PM +0000, Vladimir Konrad wrote: > > Hello, > > I (+ my users) would like to run long running jobs under "screen" command, but currently > the job looses access to afs after a user logs out. > > I tried running kinit + aklog within the "screen" session, but this makes no difference. > > Is there a way to open a screen command and get tokens specific to this session? I guess this > is related to -setpag, but this is not reliable AFAIK. My standard formula for running a screen session with long running credentials is: * Put yourself into a new pag by running pagsh * Make sure you have an independent kerberos credentials cache: export KRB5CCNAME=FILE:`mktemp /tmp/krb5cc.screen.XXXXXX` * Get tickets, get tokens, cd to your home directory * Run screen Works like a charm for me. I wrote a little script called "mypag" that does steps 1 and 2, runs a shell, and then calls unlog and kdestroy when done. This is very handy when I want to do something quickly with an administrative instance --- keeps everything self-contained and when I'm done the admin credentials go away and I'm back to my normal creds. Of course, after the screen sesson is started, re-attaching the conventional screen way is all you need to do. -- Thomas L. Kula | kula@tproa.net | http://kula.tproa.net/ From arolfe@MIT.EDU Fri Feb 13 14:48:14 2009 From: arolfe@MIT.EDU (Alex Rolfe) Date: Fri, 13 Feb 2009 09:48:14 -0500 Subject: [OpenAFS] Files getting corrupted from some clients In-Reply-To: <49935D52.1090004@gmail.com> (Troy Telford's message of "Wed, 11 Feb 2009 16:20:50 -0700") References: <49935D52.1090004@gmail.com> Message-ID: Have you tried doing similar operations (eg, unpacking linux kernel source) just on the local disk of the clients from which you see corruption? The one time we saw something like this turned out to be a linux kernel bug that only showed up when certain modules were loaded (I think it was the raid0 module)- we noticed it as corruption in AFS but it turned out to be easy to replicate with only the local file system. AFS was suffering because files in the client's on-disk cache were corrupted locally and then written back to the server. Alex Troy Telford writes: > And I'm running into issues with files being corrupted. > > On the exact same volume, for instance, I can have a host that works fine with > AFS - > > * I'll take the Linux Kernel source, and unpack it. > * I then rename the directory that gets unpacked. > * I then unpack the source again. > * There are no differences in the two directories. > > And then I have other hosts where I can unpack the tarball, and end up with > files that are truncated, missing sections of code, etc. > > I know you're not supposed to use AFS for database-like things, but it seems > that if I can't even unpack a tarball without corruption, there's some sort of > problem that needs to be resolved. > > All of my systems are using OpenAFS 1.4.8. The "problem" systems don't seem > to follow any particular linux distribution - or kernel. I have had two > systems that have the same binary kernel, the same source code, and one > produces file corruption, and the other does not. > > I'm new to AFS - and am more accustomed to NFS; so I'm not sure if I'm just > doing something that AFS doesn't handle well, or if AFS varies that much from > client to client. I want to give it a chance, but getting corrupted files > when a client writes to disk tends to put a damper on the whole experience. > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info From v.konrad@lse.ac.uk Fri Feb 13 15:25:54 2009 From: v.konrad@lse.ac.uk (Vladimir Konrad) Date: Fri, 13 Feb 2009 15:25:54 +0000 Subject: [OpenAFS] openafs and screen command - loosing tokens In-Reply-To: <20090213143838.GB543@mcketrick.tproa.net> References: <20090213131927.160d3acc@whirlpool.lse.ac.uk> <20090213143838.GB543@mcketrick.tproa.net> Message-ID: <20090213152554.315ca16d@whirlpool.lse.ac.uk> Hello Thomas, > My standard formula for running a screen session with long > running credentials is: > > * Put yourself into a new pag by running > > pagsh > > * Make sure you have an independent kerberos credentials > cache: > > export KRB5CCNAME=FILE:`mktemp /tmp/krb5cc.screen.XXXXXX` > > * Get tickets, get tokens, cd to your home directory > > * Run screen Thanks, it works. > Works like a charm for me. I wrote a little script called > "mypag" that does steps 1 and 2, runs a shell, and then > calls unlog and kdestroy when done. This is very handy > when I want to do something quickly with an administrative > instance --- keeps everything self-contained and when I'm > done the admin credentials go away and I'm back to my normal > creds. Of course, after the screen sesson is started, > re-attaching the conventional screen way is all you need > to do. Good pointer for admin work. Cheers! Vlad ------ > because it reverses the logical flow of conversation + it is hard to follow. >> why not? >>> do not put a reply at the top of the message, please... Please access the attached hyperlink for an important electronic communications disclaimer: http://www.lse.ac.uk/collections/secretariat/legal/disclaimer.htm From rra@stanford.edu Fri Feb 13 17:20:38 2009 From: rra@stanford.edu (Russ Allbery) Date: Fri, 13 Feb 2009 09:20:38 -0800 Subject: [OpenAFS] openafs and screen command - loosing tokens In-Reply-To: <20090213131927.160d3acc@whirlpool.lse.ac.uk> (Vladimir Konrad's message of "Fri\, 13 Feb 2009 13\:19\:27 +0000") References: <20090213131927.160d3acc@whirlpool.lse.ac.uk> Message-ID: <87fxii6yop.fsf@windlord.stanford.edu> Vladimir Konrad writes: > I (+ my users) would like to run long running jobs under "screen" > command, but currently the job looses access to afs after a user logs > out. > > I tried running kinit + aklog within the "screen" session, but this > makes no difference. > > Is there a way to open a screen command and get tokens specific to this > session? I guess this is related to -setpag, but this is not reliable > AFAIK. > > The platforms in question are: > > Debian Etch - on the servers, with AFS client version 1.4.7 > Debian Etch or Lenny on the desktops. You may also want to suggest: krenew -t -- /path/to/long/running/job This will make a copy of the current ticket cache, create a new PAG, obtain new tokens, and then kick off the job, renewing tickets and obtaining new tokens automatically until the job finishes or the tickets can no longer be renewed. You can get krenew from: http://www.eyrie.org/~eagle/software/kstart/ -- Russ Allbery (rra@stanford.edu) From ttelford.groups@gmail.com Fri Feb 13 17:34:36 2009 From: ttelford.groups@gmail.com (Troy Telford) Date: Fri, 13 Feb 2009 10:34:36 -0700 Subject: [OpenAFS] Files getting corrupted from some clients In-Reply-To: <20090212.111809.153194724.haba@habanero.pdc.kth.se> References: <49935D52.1090004@gmail.com> <20090212.111809.153194724.haba@habanero.pdc.kth.se> Message-ID: <4995AF2C.5010008@gmail.com> Harald Barth wrote: > What file system type(s) do you use for AFS caches? I use ext2 or > ext3. Because the cache does not contain anything that _must_ survive > a reboot (unless you use the experimental disconnected features in > 1.5.x), I suggest ext2 for speed. I had really bad experiences with > reiserfs. The cache _was_ on ext3 (with journaling), but I've also tried creating an ext2-filesystem on a file (ie. the filesystem image is then loop-mounted as ext2) - with identical results. > Does the corruption occur if you use memcache, too? I don't know; I've never used memcache. In fact, I didn't know it existed... From ttelford.groups@gmail.com Fri Feb 13 17:43:47 2009 From: ttelford.groups@gmail.com (Troy Telford) Date: Fri, 13 Feb 2009 10:43:47 -0700 Subject: [OpenAFS] Files getting corrupted from some clients In-Reply-To: References: <49935D52.1090004@gmail.com> Message-ID: <4995B153.9090806@gmail.com> Alex Rolfe wrote: > Have you tried doing similar operations (eg, unpacking linux kernel > source) just on the local disk of the clients from which you see > corruption? I have - unpacking to local disk works fine on the systems I've been seeing the issue on. From haba@kth.se Mon Feb 16 09:21:31 2009 From: haba@kth.se (Harald Barth) Date: Mon, 16 Feb 2009 10:21:31 +0100 (CET) Subject: [OpenAFS] openafs and screen command - loosing tokens In-Reply-To: <87fxii6yop.fsf@windlord.stanford.edu> References: <20090213131927.160d3acc@whirlpool.lse.ac.uk> <87fxii6yop.fsf@windlord.stanford.edu> Message-ID: <20090216.102131.167433408.haba@habanero.pdc.kth.se> > krenew -t -- /path/to/long/running/job Or the same functionality as provided with Heimdal's kinit. SYNOPSIS kinit ... ... [principal [command]] ... If a command is given, kinit will set up new credentials caches, and AFS PAG, and then run the given command. When it finishes the credentials will be removed. ... (Heimdal, the package that always has the functionality but hiding it well) Harald. From wlm020279@yahoo.com Mon Feb 16 16:57:44 2009 From: wlm020279@yahoo.com (William McCabe) Date: Mon, 16 Feb 2009 08:57:44 -0800 (PST) Subject: [OpenAFS] Running a local openafs fileserver without kerberos. Message-ID: <822856.91081.qm@web52211.mail.re2.yahoo.com> --0-2080265612-1234803464=:91081 Content-Type: text/plain; charset=us-ascii Openafs users, I would like to run an openafs fileserver on my laptop while it is disconnected. How can I do this with the least amount of overhead? Ideally, it would function in the following way. While disconnected from the internet I could login to my laptop and use my home directory on an openafs volume. When I reconnect it would start sharing out files to the rest of the openafs cell and I would need tokens to access my home directory. Is this possible? Also is there any software out there that can read and write an openafs volume without having install a full fledged openafs fileserver? Thanks, Bill --0-2080265612-1234803464=:91081 Content-Type: text/html; charset=us-ascii
Openafs users,

I would like to run an openafs fileserver on my laptop while it is disconnected. How can I do this with the least amount of overhead?

Ideally, it would function in the following way. While disconnected from the internet I could login to my laptop and use my home directory on an openafs volume. When I reconnect it would start sharing out files to the rest of the openafs cell and I would need tokens to access my home directory.

Is this possible? Also is there any software out there that can read and write an openafs volume without having install a full fledged openafs fileserver?

Thanks,

Bill
--0-2080265612-1234803464=:91081-- From rra@stanford.edu Mon Feb 16 19:31:10 2009 From: rra@stanford.edu (Russ Allbery) Date: Mon, 16 Feb 2009 11:31:10 -0800 Subject: [OpenAFS] Running a local openafs fileserver without kerberos. In-Reply-To: <822856.91081.qm@web52211.mail.re2.yahoo.com> (William McCabe's message of "Mon\, 16 Feb 2009 08\:57\:44 -0800 \(PST\)") References: <822856.91081.qm@web52211.mail.re2.yahoo.com> Message-ID: <87hc2uw54x.fsf@windlord.stanford.edu> William McCabe writes: > I would like to run an openafs fileserver on my laptop while it is > disconnected. How can I do this with the least amount of overhead? > > Ideally, it would function in the following way. While disconnected from > the internet I could login to my laptop and use my home directory on an > openafs volume. When I reconnect it would start sharing out files to the > rest of the openafs cell and I would need tokens to access my home > directory. > > Is this possible? Also is there any software out there that can read and > write an openafs volume without having install a full fledged openafs > fileserver? I think that rather than running a file server on your laptop, you want disconnected mode, which lets you continue to access and use your files while disconnected from the network and then push those changes back once you reconnect. It's implemented in the cache manager rather than in the file server. Disconnected mode is currently still under development and has some bugs, but it's at the point where I believe it's usable if you're willing to put up with it not always working. It's only available in the 1.5 releases, not in the stable 1.4 releases. -- Russ Allbery (rra@stanford.edu) From mizmoose@gmail.com Tue Feb 17 06:14:32 2009 From: mizmoose@gmail.com (Esther Filderman) Date: Tue, 17 Feb 2009 01:14:32 -0500 Subject: [OpenAFS] Register for the OpenAFS & Kerberos Best Practices Workshop 2009 Message-ID: Registration for the OpenAFS & Kerberos Best Practices Workshop is now available on the website, http://workshop.openafs.org/. Register by April 21, 2009 to get the best prices. AFS and Kerberos tutorials are $100 each, the Workshop itself is $150, or register for all three for only $300. After April 21, 2009 prices will go up, so register early. A tentative schedule is available. Further details, including evening/social events, will be forthcoming. Hotel and travel information is also available. We look forward to seeing you at Stanford University this June. The Workshop Organizers http://workshop.openafs.org/ From dboldt@usgs.gov Fri Feb 20 17:59:03 2009 From: dboldt@usgs.gov (David R Boldt) Date: Fri, 20 Feb 2009 12:59:03 -0500 Subject: [OpenAFS] AFS, dates and Windows Message-ID: This is a multipart message in MIME format. --=_alternative 0062CAA485257563_= Content-Type: text/plain; charset="US-ASCII" My background is Unix and so the treatment of date/time by Windows and its interaction with AFS is a bit fuzzy to me. My understanding for Unix is that of the three dates normally stored, atime, ctime and mtime, when saving to AFS, stores mtime. Windows seems to store at least two dates, a creation date and a modified date. Anecdotal evidence suggests that Windows, or at least some applications within Windows, store the creation date in the single AFS date/time slot. Some light on my state of information darkness would be greatly appreciated. -- David Boldt --=_alternative 0062CAA485257563_= Content-Type: text/html; charset="US-ASCII"
My background is Unix and so the treatment of date/time by
Windows and its interaction with AFS is a bit fuzzy to me.

My understanding for Unix is that of the three dates normally
stored, atime, ctime and mtime, when saving to AFS, stores
mtime.

Windows seems to store at least two dates, a creation date
and a modified date.  Anecdotal evidence suggests that
Windows, or at least some applications within Windows,
store the creation date in the single AFS date/time slot.

Some light on my state of information darkness would be
greatly appreciated.

  -- David Boldt
--=_alternative 0062CAA485257563_=-- From jaltman@secure-endpoints.com Fri Feb 20 18:25:23 2009 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Fri, 20 Feb 2009 13:25:23 -0500 Subject: [OpenAFS] AFS, dates and Windows In-Reply-To: References: Message-ID: <499EF593.7040103@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms060800080807060408090007 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit David R Boldt wrote: > > My background is Unix and so the treatment of date/time by > Windows and its interaction with AFS is a bit fuzzy to me. > > My understanding for Unix is that of the three dates normally > stored, atime, ctime and mtime, when saving to AFS, stores > mtime. > > Windows seems to store at least two dates, a creation date > and a modified date. Anecdotal evidence suggests that > Windows, or at least some applications within Windows, > store the creation date in the single AFS date/time slot. > > Some light on my state of information darkness would be > greatly appreciated. > > -- David Boldt Windows maintains creationTime lastAccessTime lastWriteTime changeTime the AFS file server does not communicate creationTime as part of the FetchStatus response and accessTime cannot be accurately tracked in AFS. Therefore, the AFS clientModTime is used for all four of the above values as reported to Windows. Jeffrey Altman --------------ms060800080807060408090007 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 AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw 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 OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAyMjAxODI1MjNaMCMGCSqGSIb3DQEJBDEWBBTVOLN9 q5jf9qmqEWiMVZsQYgXRJzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAaBIYucXkEMkKV3Gq8Fd6aDAbKl840DMe9WSGz2kK9vFGowbhWqz7 ghGSFlXNcd4ar9rMyOuX32JwN/1Y+SGHoRll1hO0u53wIWA3yP43Rr6rVWrcqYWi0KROxYUa AixNLRpmER6xUnREiDqM2OwLDJCr47E6jkuJbmdh4RYttv5ZZf+gHzVBvF/HJjcuaDHSObFN LEzQnNFKnHX/WDYLAlcMocpqZYbpCbXw12PBtxRoPdvx/k71AOXM879z45SjdEiFfpJihiCg f794d9gp0tPAu/CtqFtUbfDhmGpbSou1esCaut4sd/a+29Q9nNvwhzODfmvYOgO7xE2y1OzW 2wAAAAAAAA== --------------ms060800080807060408090007-- From shadow@gmail.com Sun Feb 22 06:20:36 2009 From: shadow@gmail.com (Derrick Brashear) Date: Sun, 22 Feb 2009 01:20:36 -0500 Subject: [OpenAFS] Re: [OpenAFS-devel] OS X 10.5 oddity In-Reply-To: <7671eb70902212211k1f3bf1besd6718967a157b214@mail.gmail.com> References: <7671eb70902212211k1f3bf1besd6718967a157b214@mail.gmail.com> Message-ID: This belongs on openafs-info, since there's no code question or discussion here. Redirecting there. On Sun, Feb 22, 2009 at 1:11 AM, Joel wrote: > I'm at a loss of where to even turn to about this problem. I've used > OpenAFS on OSX for years, but recently I've been having some strange > issues. At seemingly random points in AFS operations, my client will > hang and ultimately contact to the fileserver will be lost, then > restored soon after. > > Going into detail... > > Using the OpenAFS 1.4.8 OSX package, with OSX 10.5.6. > When the client hangs, dmesg repeats this until the "afs: Lost contact > with file server..." message: > in_delayed_cksum_offset: ip_len 51200 (200) doesn't match actual length 214 > which means pretty much what it says, that the length in the packet > doesn't match the actual on-wire length. It seems to always be 14 > bytes shy (the size of the UDP header??). This packet never makes it > through, so I assume the client times out waiting for it and triggers > the "lost contact" state. You leave out details like what the hardware is. Since that function may be related to hardware offloading of IP checksumming, it could matter. From hashbang@gmail.com Sun Feb 22 08:01:00 2009 From: hashbang@gmail.com (Joel) Date: Sun, 22 Feb 2009 02:01:00 -0600 Subject: [OpenAFS] Re: OS X 10.5 oddity In-Reply-To: References: <7671eb70902212211k1f3bf1besd6718967a157b214@mail.gmail.com> Message-ID: <7671eb70902220001q24e51f81xd747de27fdd7ca7@mail.gmail.com> On Sun, Feb 22, 2009 at 12:20 AM, Derrick Brashear wrote: > This belongs on openafs-info, since there's no code question or > discussion here. Redirecting there. > > On Sun, Feb 22, 2009 at 1:11 AM, Joel wrote: >> I'm at a loss of where to even turn to about this problem. I've used >> OpenAFS on OSX for years, but recently I've been having some strange >> issues. At seemingly random points in AFS operations, my client will >> hang and ultimately contact to the fileserver will be lost, then >> restored soon after. >> >> Going into detail... >> >> Using the OpenAFS 1.4.8 OSX package, with OSX 10.5.6. >> When the client hangs, dmesg repeats this until the "afs: Lost contact >> with file server..." message: >> in_delayed_cksum_offset: ip_len 51200 (200) doesn't match actual length 214 >> which means pretty much what it says, that the length in the packet >> doesn't match the actual on-wire length. It seems to always be 14 >> bytes shy (the size of the UDP header??). This packet never makes it >> through, so I assume the client times out waiting for it and triggers >> the "lost contact" state. > > You leave out details like what the hardware is. Since that function > may be related to hardware offloading of IP checksumming, it could > matter. > The machine is a mac pro, using the onboard Intel8254X NIC. From leo@strike.wu-wien.ac.at Mon Feb 23 11:12:55 2009 From: leo@strike.wu-wien.ac.at (Alexander 'Leo' Bergolth) Date: Mon, 23 Feb 2009 12:12:55 +0100 Subject: [OpenAFS] Re: sometimes loosing token on su In-Reply-To: <49931307.5040604@strike.wu-wien.ac.at> References: <49931307.5040604@strike.wu-wien.ac.at> Message-ID: <49A284B7.1090505@strike.wu-wien.ac.at> On 02/11/2009 07:03 PM, Alexander 'Leo' Bergolth wrote: > First of all: Yes, I have disabled pam_keyinit.so. :-) > > I am experiencing a very strange problem: > > On my workstation, switching to root using "su -" (or just su) normally > works fine. > However sometimes, when trying to "su" in a long running shell, I'm > loosing my token. (See the example 1 below.) > > Logging in via ssh and then doing "su -" works fine though. (See example 2). > > It looks like there is something wrong with my PAG since after getting a > new PAG and a token from within the broken PAG, "su -" keeps my token > again. (Example 3) I am still suffering from that problem. Any ideas how I could debug that? Maybe the problem is that sometimes the token get erroneously attached to the user and not to the PAG? (In those broken PAGs, doing su leads to loosing the token but exiting from su brings the token back again. Is there a way to check, if the token is attached to a PAG? Cheers, --leo > Even doing kinit and aklog -force (before doing su -) doesn't help. > > Syslog-output with pam_krb5.so debug enabled doesn't show anything > suspecting. (See below.) Even commenting out pam_krb5.so just for the su > doesn't help. > > Any hints? > > Thanks, > --leo > > P.S.: I'm using openafs-1.4.8-30.fc10.i386 on Fedora 10 (kernel > 2.6.27.9-159.fc10.i686.PAE). > > -------------------- Example 1 -------------------- > [bergolth@ariel ~]$ tokens > > Tokens held by the Cache Manager: > > User's (AFS ID 5020) tokens for afs@wu-wien.ac.at [Expires Feb 12 15:57] > --End of list-- > > [bergolth@ariel ~]$ id -G > 3000 10 107 500 501 1098248117 > > [bergolth@ariel ~]$ keyctl show > Session Keyring > -3 --alswrv 0 3000 keyring: _ses.4114 > 480068621 ----s--v 0 0 \_ afs_pag: _pag > > [bergolth@ariel ~]$ su - > > [root@ariel ~]# tokens > > Tokens held by the Cache Manager: > > --End of list-- > > [root@ariel ~]# id -G > 0 1 2 3 4 6 10 > > [root@ariel ~]# keyctl show > Session Keyring > -3 --alswrv 0 3000 keyring: _ses.4114 > 480068621 ----s--v 0 0 \_ afs_pag: _pag > --------------------------------------------------- > > -------------------- Example 2 -------------------- > [bergolth@ariel ~]$ ssh bergolth@ariel > > [bergolth@ariel:~]$ tokens > > Tokens held by the Cache Manager: > > Tokens for afs@wu-wien.ac.at [Expires Feb 12 15:57] > --End of list-- > > [bergolth@ariel:~]$ id -G > 3000 10 107 500 501 1098248255 > > [bergolth@ariel:~]$ keyctl show > Session Keyring > -3 --alswrv 0 0 keyring: _ses.13949 > 851940785 ----s--v 0 0 \_ afs_pag: _pag > > [bergolth@ariel:~]$ su - > > [root@ariel ~]# tokens > > Tokens held by the Cache Manager: > > Tokens for afs@wu-wien.ac.at [Expires Feb 12 15:57] > --End of list-- > > [root@ariel ~]# id -G > 0 1 2 3 4 6 10 > > [root@ariel ~]# keyctl show > Session Keyring > -3 --alswrv 0 0 keyring: _ses.13949 > 851940785 ----s--v 0 0 \_ afs_pag: _pag > --------------------------------------------------- > > -------------------- Example 3 -------------------- > [bergolth@ariel ~]$ id -G > 3000 10 107 500 501 1098248117 > > [bergolth@ariel ~]$ keyctl show > Session Keyring > -3 --alswrv 0 3000 keyring: _ses.4114 > 480068621 ----s--v 0 0 \_ afs_pag: _pag > > [bergolth@ariel ~]$ pagsh > > sh-3.2$ id -G > 3000 10 107 500 501 1098248260 > > sh-3.2$ keyctl show > Session Keyring > -3 --alswrv 5020 3000 keyring: _ses.14509 > 808791921 ----s--v 0 0 \_ afs_pag: _pag > > sh-3.2$ aklog > > sh-3.2$ tokens > > Tokens held by the Cache Manager: > > User's (AFS ID 5020) tokens for afs@wu-wien.ac.at [Expires Feb 12 19:49] > --End of list-- > > sh-3.2$ su - > > [root@ariel ~]# tokens > > Tokens held by the Cache Manager: > > User's (AFS ID 5020) tokens for afs@wu-wien.ac.at [Expires Feb 12 19:49] > --End of list-- > --------------------------------------------------- > > -------------------- Syslog 1 -------------------- > Feb 11 18:18:49 ariel su: pam_unix(su-l:session): session opened for > user root by bergolth(uid=5020) > Feb 11 18:18:49 ariel su: pam_krb5[13573]: default/local realm > 'WU-WIEN.AC.AT' > Feb 11 18:18:49 ariel su: pam_krb5[13573]: configured realm 'WU-WIEN.AC.AT' > Feb 11 18:18:49 ariel su: pam_krb5[13573]: flag: debug > Feb 11 18:18:49 ariel su: pam_krb5[13573]: flags: forwardable > Feb 11 18:18:49 ariel su: pam_krb5[13573]: flag: no ignore_afs > Feb 11 18:18:49 ariel su: pam_krb5[13573]: flag: no null_afs > Feb 11 18:18:49 ariel su: pam_krb5[13573]: flag: user_check > Feb 11 18:18:49 ariel su: pam_krb5[13573]: flag: no krb4_convert > Feb 11 18:18:49 ariel su: pam_krb5[13573]: flag: krb4_convert_524 > Feb 11 18:18:49 ariel su: pam_krb5[13573]: flag: krb4_use_as_req > Feb 11 18:18:49 ariel su: pam_krb5[13573]: will try previously set > password first > Feb 11 18:18:49 ariel su: pam_krb5[13573]: will ask for a password if > that fails > Feb 11 18:18:49 ariel su: pam_krb5[13573]: will let libkrb5 ask questions > Feb 11 18:18:49 ariel su: pam_krb5[13573]: flag: no use_shmem > Feb 11 18:18:49 ariel su: pam_krb5[13573]: flag: external > Feb 11 18:18:49 ariel su: pam_krb5[13573]: flag: warn > Feb 11 18:18:49 ariel su: pam_krb5[13573]: ticket lifetime: 0s (0d,0h,0m,0s) > Feb 11 18:18:49 ariel su: pam_krb5[13573]: renewable lifetime: 0s > (0d,0h,0m,0s) > Feb 11 18:18:49 ariel su: pam_krb5[13573]: banner: Kerberos 5 > Feb 11 18:18:49 ariel su: pam_krb5[13573]: ccache dir: /tmp > Feb 11 18:18:49 ariel su: pam_krb5[13573]: ccname template: > FILE:%d/krb5cc_%U_XXXXXX > Feb 11 18:18:49 ariel su: pam_krb5[13573]: keytab: FILE:/etc/krb5.keytab > Feb 11 18:18:49 ariel su: pam_krb5[13573]: token strategy: v4,524,2b,rxk5 > Feb 11 18:18:49 ariel su: pam_krb5[13573]: checking for > externally-obtained v5 credentials > Feb 11 18:18:49 ariel su: pam_krb5[13573]: KRB5CCNAME is not set, none found > Feb 11 18:18:49 ariel su: pam_krb5[13573]: no v5 creds for user 'root', > skipping session setup > Feb 11 18:18:49 ariel su: pam_krb5[13573]: pam_open_session returning 0 > (Success) > -------------------------------------------------- > > > -------------------- Syslog 2 -------------------- > Feb 11 18:26:31 ariel su: pam_unix(su-l:session): session opened for > user root by bergolth(uid=5020) > Feb 11 18:26:31 ariel su: pam_krb5[14103]: default/local realm > 'WU-WIEN.AC.AT' > Feb 11 18:26:31 ariel su: pam_krb5[14103]: configured realm 'WU-WIEN.AC.AT' > Feb 11 18:26:31 ariel su: pam_krb5[14103]: flag: debug > Feb 11 18:26:31 ariel su: pam_krb5[14103]: flags: forwardable > Feb 11 18:26:31 ariel su: pam_krb5[14103]: flag: no ignore_afs > Feb 11 18:26:31 ariel su: pam_krb5[14103]: flag: no null_afs > Feb 11 18:26:31 ariel su: pam_krb5[14103]: flag: user_check > Feb 11 18:26:31 ariel su: pam_krb5[14103]: flag: no krb4_convert > Feb 11 18:26:31 ariel su: pam_krb5[14103]: flag: krb4_convert_524 > Feb 11 18:26:31 ariel su: pam_krb5[14103]: flag: krb4_use_as_req > Feb 11 18:26:31 ariel su: pam_krb5[14103]: will try previously set > password first > Feb 11 18:26:31 ariel su: pam_krb5[14103]: will ask for a password if > that fails > Feb 11 18:26:31 ariel su: pam_krb5[14103]: will let libkrb5 ask questions > Feb 11 18:26:31 ariel su: pam_krb5[14103]: flag: no use_shmem > Feb 11 18:26:31 ariel su: pam_krb5[14103]: flag: external > Feb 11 18:26:31 ariel su: pam_krb5[14103]: flag: warn > Feb 11 18:26:31 ariel su: pam_krb5[14103]: ticket lifetime: 0s (0d,0h,0m,0s) > Feb 11 18:26:31 ariel su: pam_krb5[14103]: renewable lifetime: 0s > (0d,0h,0m,0s) > Feb 11 18:26:31 ariel su: pam_krb5[14103]: banner: Kerberos 5 > Feb 11 18:26:31 ariel su: pam_krb5[14103]: ccache dir: /tmp > Feb 11 18:26:31 ariel su: pam_krb5[14103]: ccname template: > FILE:%d/krb5cc_%U_XXXXXX > Feb 11 18:26:31 ariel su: pam_krb5[14103]: keytab: FILE:/etc/krb5.keytab > Feb 11 18:26:31 ariel su: pam_krb5[14103]: token strategy: v4,524,2b,rxk5 > Feb 11 18:26:31 ariel su: pam_krb5[14103]: checking for > externally-obtained v5 credentials > Feb 11 18:26:31 ariel su: pam_krb5[14103]: KRB5CCNAME is not set, none found > Feb 11 18:26:31 ariel su: pam_krb5[14103]: no v5 creds for user 'root', > skipping session setup > Feb 11 18:26:31 ariel su: pam_krb5[14103]: pam_open_session returning 0 > (Success) > -------------------------------------------------- > -- e-mail ::: Leo.Bergolth (at) wu-wien.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria From haba@kth.se Mon Feb 23 11:36:08 2009 From: haba@kth.se (Harald Barth) Date: Mon, 23 Feb 2009 12:36:08 +0100 (CET) Subject: [OpenAFS] Re: sometimes loosing token on su In-Reply-To: <49A284B7.1090505@strike.wu-wien.ac.at> References: <49931307.5040604@strike.wu-wien.ac.at> <49A284B7.1090505@strike.wu-wien.ac.at> Message-ID: <20090223.123608.99407783.haba@habanero.pdc.kth.se> > Maybe the problem is that sometimes the token get erroneously attached > to the user and not to the PAG? Sometimes you want it, sometimes not. From the man page of heimdal rshd(8): -P When using the AFS filesystem, users' authentication tokens are put in something called a PAG (Process Authentication Group). Multiple processes can share a PAG, but normally each login ses- sion has its own PAG. This option disables the setpag() call, so all tokens will be put in the default (uid-based) PAG, making it possible to share tokens between sessions. This is only useful in peculiar environments, such as some batch systems. Looks like we are peculiar. > (In those broken PAGs, doing su leads to > loosing the token but exiting from su brings the token back again. Which leads me to believe that in this case you are using uid based pags. > Is there a way to check, if the token is attached to a PAG? Hm... $ ssh -Y -l haba -K -o GSSAPIKeyExchange=yes ekman '/usr/heimdal/bin/klist -T ; groups' Credentials cache: FILE:/tmp/krb5cc_d23246 Principal: haba@NADA.KTH.SE Issued Expires Principal Feb 23 12:31:47 Feb 24 09:34:11 krbtgt/NADA.KTH.SE@NADA.KTH.SE Feb 23 12:31:48 Feb 24 09:34:11 afs/pdc.kth.se@NADA.KTH.SE Feb 23 12:31:48 Feb 24 09:34:11 afs@NADA.KTH.SE Feb 23 12:31:48 Feb 24 09:34:11 User's (AFS ID 22421) tokens for nada.kth.se Feb 23 12:31:48 Feb 24 09:34:11 User's (AFS ID 22421) tokens for pdc.kth.se gopher 1098410290 id: cannot find name for group ID 1098410290 This is OS and Linux-version dependent. Here (2.6.18-92.1.13.el5.centos.plus), the strange group number is the PAG-ID. Harald. From Sergio.Gelato@astro.su.se Mon Feb 23 22:39:19 2009 From: Sergio.Gelato@astro.su.se (Sergio Gelato) Date: Mon, 23 Feb 2009 23:39:19 +0100 Subject: [OpenAFS] Re: sometimes loosing token on su In-Reply-To: <49A284B7.1090505@strike.wu-wien.ac.at> References: <49931307.5040604@strike.wu-wien.ac.at> <49A284B7.1090505@strike.wu-wien.ac.at> Message-ID: <20090223223919.GA2614@astro.su.se> * Alexander 'Leo' Bergolth [2009-02-23 12:12:55 +0100]: > On 02/11/2009 07:03 PM, Alexander 'Leo' Bergolth wrote: > > First of all: Yes, I have disabled pam_keyinit.so. :-) > > > > I am experiencing a very strange problem: > > > > On my workstation, switching to root using "su -" (or just su) normally > > works fine. > > However sometimes, when trying to "su" in a long running shell, I'm > > loosing my token. (See the example 1 below.) > > > > Logging in via ssh and then doing "su -" works fine though. (See example 2). > > > > It looks like there is something wrong with my PAG since after getting a > > new PAG and a token from within the broken PAG, "su -" keeps my token > > again. (Example 3) > > I am still suffering from that problem. > Any ideas how I could debug that? > > Maybe the problem is that sometimes the token get erroneously attached > to the user and not to the PAG? (In those broken PAGs, doing su leads to > loosing the token but exiting from su brings the token back again. > > Is there a way to check, if the token is attached to a PAG? Just did a few tests (important caveat: I used kernel 2.6.18, not 2.6.27) and here is what a PAGless session looks like: $ keyctl show Session Keyring -3 --alswrv 1000 -1 keyring: _uid_ses.1000 950991447 --alswrv 1000 -1 \_ keyring: _uid.1000 > > Syslog-output with pam_krb5.so debug enabled doesn't show anything > > suspecting. (See below.) Even commenting out pam_krb5.so just for the su > > doesn't help. > > > > Any hints? > > > > Thanks, > > --leo > > > > P.S.: I'm using openafs-1.4.8-30.fc10.i386 on Fedora 10 (kernel > > 2.6.27.9-159.fc10.i686.PAE). > > > > -------------------- Example 1 -------------------- > > [bergolth@ariel ~]$ tokens > > > > Tokens held by the Cache Manager: > > > > User's (AFS ID 5020) tokens for afs@wu-wien.ac.at [Expires Feb 12 15:57] > > --End of list-- > > > > [bergolth@ariel ~]$ id -G > > 3000 10 107 500 501 1098248117 > > > > [bergolth@ariel ~]$ keyctl show > > Session Keyring > > -3 --alswrv 0 3000 keyring: _ses.4114 > > 480068621 ----s--v 0 0 \_ afs_pag: _pag > > > > [bergolth@ariel ~]$ su - > > > > [root@ariel ~]# tokens > > > > Tokens held by the Cache Manager: > > > > --End of list-- > > > > [root@ariel ~]# id -G > > 0 1 2 3 4 6 10 > > > > [root@ariel ~]# keyctl show > > Session Keyring > > -3 --alswrv 0 3000 keyring: _ses.4114 > > 480068621 ----s--v 0 0 \_ afs_pag: _pag > > --------------------------------------------------- I just tried with a 2.6.26 kernel (Debian 5.0) and couldn't reproduce this behaviour. Depending on /etc/pam.d/su I either keep the same PAG and tokens or get into a new PAG which keyctl reports as such. Either way, the behaviour is as I would expect and unlike the one you report. Same thing with a 2.6.28 kernel (Debian 2.6.28-1~experimental.1~snapshot.12721) I've had to apply some post-1.4.8 patches to OpenAFS because that 2.6.28 kernel is really 2.6.28.3 and needs the "2.6.29" patch; they were STABLE14-libuafs-updates-20081229 STABLE14-linux-truncate-race-20090109 STABLE14-linux-i-size-20090112 STABLE14-linux-2629-20090115 Can you reproduce the problem when su is configured not to call pam_krb5 at all? How about when you su to the same user instead of to root? (If you were PAGless, this ought to work. I don't think you are, but it's an easy test.) From ragge@ltu.se Tue Feb 24 09:58:52 2009 From: ragge@ltu.se (Anders Magnusson) Date: Tue, 24 Feb 2009 10:58:52 +0100 Subject: [OpenAFS] Longer volume names than 22 characters. Message-ID: <49A3C4DC.4040909@ltu.se> I took a quick look in the source code, and found that there are two interesting defines (in volser.h): #define VOLSER_MAXVOLNAME 65 #define VOLSER_OLDMAXVOLNAME 32 So, obviously someone has thought about allowing longer names, but the checks seems to be against the old name length so it don't work. What is needed if we want to use longer names? And may it cause incompatibility with clients or other cells or whatever? -- Ragge From leo@strike.wu-wien.ac.at Tue Feb 24 11:15:47 2009 From: leo@strike.wu-wien.ac.at (Alexander 'Leo' Bergolth) Date: Tue, 24 Feb 2009 12:15:47 +0100 Subject: [OpenAFS] Re: sometimes loosing token on su In-Reply-To: <20090223223919.GA2614@astro.su.se> References: <49931307.5040604@strike.wu-wien.ac.at> <49A284B7.1090505@strike.wu-wien.ac.at> <20090223223919.GA2614@astro.su.se> Message-ID: <49A3D6E3.8000701@strike.wu-wien.ac.at> Hi! On 02/23/2009 11:39 PM, Sergio Gelato wrote: > * Alexander 'Leo' Bergolth [2009-02-23 12:12:55 +0100]: >> On 02/11/2009 07:03 PM, Alexander 'Leo' Bergolth wrote: >>> First of all: Yes, I have disabled pam_keyinit.so. :-) >>> >>> I am experiencing a very strange problem: >>> >>> On my workstation, switching to root using "su -" (or just su) normally >>> works fine. >>> However sometimes, when trying to "su" in a long running shell, I'm >>> loosing my token. (See the example 1 below.) >>> >>> Logging in via ssh and then doing "su -" works fine though. (See example 2). >>> >>> It looks like there is something wrong with my PAG since after getting a >>> new PAG and a token from within the broken PAG, "su -" keeps my token >>> again. (Example 3) >> I am still suffering from that problem. >> Any ideas how I could debug that? [...] > I just tried with a 2.6.26 kernel (Debian 5.0) and couldn't reproduce > this behaviour. Depending on /etc/pam.d/su I either keep the same PAG > and tokens or get into a new PAG which keyctl reports as such. Either > way, the behaviour is as I would expect and unlike the one you report. The funny thing is: 1) ssh'ing to the same account and doing su from there also produces the expected results. 2) after restarting the X-Session, su'ing also works for some time (maybe for the lifetime of a token?) Reauthentication currently is done either manually via klog or with pam_krb5 called by kscreensaver. I'll try to reproduce these tests by logging in via ssh and reauthenticating via klog after the token had expired... > I've had to apply some post-1.4.8 patches to OpenAFS because that 2.6.28 > kernel is really 2.6.28.3 and needs the "2.6.29" patch; they were > STABLE14-libuafs-updates-20081229 > STABLE14-linux-truncate-race-20090109 > STABLE14-linux-i-size-20090112 > STABLE14-linux-2629-20090115 > > Can you reproduce the problem when su is configured not to call pam_krb5 > at all? Yes. I've commented out both pam_krb5 and pam_keyinit. Same results. > How about when you su to the same user instead of to root? (If you were > PAGless, this ought to work. I don't think you are, but it's an easy > test.) Thats a good point. su'ing to the same user also doesn't work: [bergolth@ariel ~]$ su bergolth bash: /afs/wu-wien.ac.at/home/edvz/bergolth/.bashrc: Permission denied bash-3.2$ [bergolth@ariel ~]$ sudo -u bergolth bash bash: /afs/wu-wien.ac.at/home/edvz/bergolth/.bashrc: Permission denied bash-3.2$ This disproves my theory of the User-ID attached token... Cheers, --leo -- e-mail ::: Leo.Bergolth (at) wu-wien.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria From shadow@gmail.com Tue Feb 24 14:43:06 2009 From: shadow@gmail.com (Derrick Brashear) Date: Tue, 24 Feb 2009 09:43:06 -0500 Subject: [OpenAFS] Longer volume names than 22 characters. In-Reply-To: <49A3C4DC.4040909@ltu.se> References: <49A3C4DC.4040909@ltu.se> Message-ID: On Tue, Feb 24, 2009 at 4:58 AM, Anders Magnusson wrote: > I took a quick look in the source code, and found that there are two > interesting defines (in volser.h): > > #define VOLSER_MAXVOLNAME 65 > #define VOLSER_OLDMAXVOLNAME 32 > > So, obviously someone has thought about allowing longer names, but the > checks seems to be against > the old name length so it don't work. > What is needed if we want to use longer names? =A0And may it cause > incompatibility with clients > or other cells or whatever? All vlserver calls already use 65: const VL_MAXNAMELEN =3D 65; Sadly, look what's on the on-disk volume header: typedef struct VolumeDiskData { struct versionStamp stamp; /* Must be first field */ VolumeId id; /* Volume id--unique over all systems */ #define VNAMESIZE 32 /* including 0 byte */ char name[VNAMESIZE]; /* Unofficial name for the volume */ So basically, you'd have to upgrade that, including having an upgrade and downgrade path for volume headers (and then switch out vos anywhere you wanted to actually be able to manipulate the volumes) It's not actually all that hard, realistically. From bettsjohn@mac.com Tue Feb 24 15:08:35 2009 From: bettsjohn@mac.com (John Betts) Date: Tue, 24 Feb 2009 10:08:35 -0500 Subject: [OpenAFS] Registering a new OpenAFS SYS_NAME_ID Message-ID: <6A9687B6-D731-45AD-B349-4642E1FB1A5D@mac.com> I recently created a port for 32bit sparc_linux26 with SYS_NAME_ID_sparc_linux26 1703. (OpenAFS 1.5.57) In the interests of not having to reconfigure and compile later if there was another sysname with ID 1703, how could we make this "official" ? In short I copied and modified: param.sparc_linux24.h to param.sparc_linux26.h edited to add sparc_linux26 definitions as appropriate in: acinclude.m4 aclocal.m4 libafs/MakefileProto.LINUX.in ./src/cf/osconf.m4 (And I can't remember if it was configure or myself that modified: src/config/afs_sysnames.h src/cofnig/afsconfig.h ) Thanks in advance JB From jaltman@secure-endpoints.com Tue Feb 24 15:17:35 2009 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Tue, 24 Feb 2009 10:17:35 -0500 Subject: [OpenAFS] Registering a new OpenAFS SYS_NAME_ID In-Reply-To: <6A9687B6-D731-45AD-B349-4642E1FB1A5D@mac.com> References: <6A9687B6-D731-45AD-B349-4642E1FB1A5D@mac.com> Message-ID: <49A40F8F.6040105@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms040308070107020503080907 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit The AFS Assigned Numbers Registry is implementation independent and is maintained at http://www.central.org/pages/numbers/systypes.html At the bottom of the page is listed a registration policy. Requests should be sent to registrar at grand.central.org Feel free to send a patch with your OpenAFS changes to openafs-bugs@openafs.org. Thank you. Jeffrey Altman John Betts wrote: > I recently created a port for 32bit sparc_linux26 with > SYS_NAME_ID_sparc_linux26 1703. (OpenAFS 1.5.57) > > In the interests of not having to reconfigure and compile later if there > was another sysname with ID 1703, how could we make this "official" ? > > In short I copied and modified: > param.sparc_linux24.h to param.sparc_linux26.h > > edited to add sparc_linux26 definitions as appropriate in: > acinclude.m4 > aclocal.m4 > libafs/MakefileProto.LINUX.in > ./src/cf/osconf.m4 > > (And I can't remember if it was configure or myself that modified: > src/config/afs_sysnames.h > src/cofnig/afsconfig.h > ) > > Thanks in advance > JB > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > --------------ms040308070107020503080907 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 AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw 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 OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAyMjQxNTE3MzVaMCMGCSqGSIb3DQEJBDEWBBSPjjRT 24Ds3IeyFO0FG4k8QLRs5TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAcyNM2VzV7NezQdneptFAEZ03aVEUyOQbGgHVua6kEUanEt7yYIRO kgK0M2Vw/hIaDi357MuZKccYjf65/7bmnB3ItcSRyAsQhYWwBxCt/9OnNJBEOCMl7eJ7n2Ox rp47AbRZDVVyrDivnkvvKjq6/gxs//4hmkOMqXgjKd581n4gXc7HBC09kFSckJwWoKOPNzOK e9PaxjEZks9HeWOD/ehlRxWBvip+Sa35Z7gd4WiNvhYuv8sAkQwBbFdH0BWVLe9r5IEQDW4z PJnxYdybwzAEQhpNmen9CqSqewKm19gK+GT6v/C/RLO7P4ru5ubpV1CqzykUz/BMUTPEvBwr GwAAAAAAAA== --------------ms040308070107020503080907-- From ksumner@email.unc.edu Tue Feb 24 15:43:07 2009 From: ksumner@email.unc.edu (Kevin Sumner) Date: Tue, 24 Feb 2009 10:43:07 -0500 Subject: [OpenAFS] Registering a new OpenAFS SYS_NAME_ID In-Reply-To: <49A40F8F.6040105@secure-endpoints.com> References: <6A9687B6-D731-45AD-B349-4642E1FB1A5D@mac.com> <49A40F8F.6040105@secure-endpoints.com> Message-ID: <49A4158B.3060704@email.unc.edu> Does OpenAFS not adhere strictly to that list at Grand Central, or is that list in need of updating to reflect newer registrations? Or am I missing something else entirely? I'm asking because OpenAFS on my two workstations reports "amd64_linux26" and "i386_linux26" -- no *_linux26 entries are listed at all. IIRC the *_linux26 scheme has been the default in Linux 2.6 builds for quite a while. And while I don't have a box with OpenAFS on Solaris in front of me, I think Solaris 10 on Sparc defaults to sun4x_510. Just curious. Kevin Sumner ITS Enterprise Storage Management University of North Carolina at Chapel Hill CB# 1150, 440 W. Franklin Street, Office G408 Chapel Hill, NC 27599-1150 ksumner@unc.edu 919.962.1547 (office) 919.259.9734 (mobile) 919.445.9485 (fax) Jeffrey Altman wrote: > The AFS Assigned Numbers Registry is implementation independent > and is maintained at > > http://www.central.org/pages/numbers/systypes.html > > At the bottom of the page is listed a registration policy. > Requests should be sent to registrar at grand.central.org > > Feel free to send a patch with your OpenAFS changes to > openafs-bugs@openafs.org. > > Thank you. > > Jeffrey Altman > > > John Betts wrote: >> I recently created a port for 32bit sparc_linux26 with >> SYS_NAME_ID_sparc_linux26 1703. (OpenAFS 1.5.57) >> >> In the interests of not having to reconfigure and compile later if there >> was another sysname with ID 1703, how could we make this "official" ? >> >> In short I copied and modified: >> param.sparc_linux24.h to param.sparc_linux26.h >> >> edited to add sparc_linux26 definitions as appropriate in: >> acinclude.m4 >> aclocal.m4 >> libafs/MakefileProto.LINUX.in >> ./src/cf/osconf.m4 >> >> (And I can't remember if it was configure or myself that modified: >> src/config/afs_sysnames.h >> src/cofnig/afsconfig.h >> ) >> >> Thanks in advance >> JB >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info >> From bettsjohn@mac.com Tue Feb 24 16:02:05 2009 From: bettsjohn@mac.com (John Betts) Date: Tue, 24 Feb 2009 11:02:05 -0500 Subject: [OpenAFS] Registering a new OpenAFS SYS_NAME_ID In-Reply-To: <49A40F8F.6040105@secure-endpoints.com> References: <6A9687B6-D731-45AD-B349-4642E1FB1A5D@mac.com> <49A40F8F.6040105@secure-endpoints.com> Message-ID: <6AE22C49-F6FC-46E5-AEC8-BBD187D9DD74@mac.com> Thanks. I sent requests to the registry and a patch to openafs-bugs. Trackers 124401 and 124402 respectively. Best regards, JB On Feb 24, 2009, at 10:17 AM, Jeffrey Altman wrote: > The AFS Assigned Numbers Registry is implementation independent > and is maintained at > > http://www.central.org/pages/numbers/systypes.html > > At the bottom of the page is listed a registration policy. > Requests should be sent to registrar at grand.central.org > > Feel free to send a patch with your OpenAFS changes to > openafs-bugs@openafs.org. > > Thank you. > > Jeffrey Altman > > > John Betts wrote: >> I recently created a port for 32bit sparc_linux26 with >> SYS_NAME_ID_sparc_linux26 1703. (OpenAFS 1.5.57) >> >> In the interests of not having to reconfigure and compile later if >> there >> was another sysname with ID 1703, how could we make this "official" ? >> >> In short I copied and modified: >> param.sparc_linux24.h to param.sparc_linux26.h >> >> edited to add sparc_linux26 definitions as appropriate in: >> acinclude.m4 >> aclocal.m4 >> libafs/MakefileProto.LINUX.in >> ./src/cf/osconf.m4 >> >> (And I can't remember if it was configure or myself that modified: >> src/config/afs_sysnames.h >> src/cofnig/afsconfig.h >> ) >> >> Thanks in advance >> JB >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info >> From shadow@gmail.com Tue Feb 24 16:11:59 2009 From: shadow@gmail.com (Derrick Brashear) Date: Tue, 24 Feb 2009 11:11:59 -0500 Subject: [OpenAFS] Registering a new OpenAFS SYS_NAME_ID In-Reply-To: <49A4158B.3060704@email.unc.edu> References: <6A9687B6-D731-45AD-B349-4642E1FB1A5D@mac.com> <49A40F8F.6040105@secure-endpoints.com> <49A4158B.3060704@email.unc.edu> Message-ID: On Tue, Feb 24, 2009 at 10:43 AM, Kevin Sumner wrot= e: > Does OpenAFS not adhere strictly to that list at Grand Central, or is tha= t > list in need of updating to reflect newer registrations? =A0Or am I missi= ng > something else entirely? The list isn't up to date with respect to allocations. From ragge@ltu.se Tue Feb 24 17:50:30 2009 From: ragge@ltu.se (Anders Magnusson) Date: Tue, 24 Feb 2009 18:50:30 +0100 Subject: [OpenAFS] Longer volume names than 22 characters. In-Reply-To: References: <49A3C4DC.4040909@ltu.se> Message-ID: <49A43366.6000408@ltu.se> Derrick Brashear wrote: > On Tue, Feb 24, 2009 at 4:58 AM, Anders Magnusson wrote: > >> I took a quick look in the source code, and found that there are two >> interesting defines (in volser.h): >> >> #define VOLSER_MAXVOLNAME 65 >> #define VOLSER_OLDMAXVOLNAME 32 >> >> So, obviously someone has thought about allowing longer names, but the >> checks seems to be against >> the old name length so it don't work. >> What is needed if we want to use longer names? And may it cause >> incompatibility with clients >> or other cells or whatever? >> > > All vlserver calls already use 65: > const VL_MAXNAMELEN = 65; > So that means that the protocol (what is sent between the client and server) is already "65-byte-clean"? > Sadly, look what's on the on-disk volume header: > typedef struct VolumeDiskData { > struct versionStamp stamp; /* Must be first field */ > VolumeId id; /* Volume id--unique over all systems */ > #define VNAMESIZE 32 /* including 0 byte */ > char name[VNAMESIZE]; /* Unofficial name for the volume */ > Hm, grepping shows that it is used in a bunch of structs. But besides VolumeDiskData , I assume all of them are only used inside the binaries...? > So basically, you'd have to upgrade that, including having an upgrade > and downgrade path for volume headers (and then switch out vos > anywhere you wanted to actually be able to manipulate the volumes) > So what you mean is basically this: - Change VNAMESIZE to 65 - Wrap VOLUMEINFOVERSION to 2 - Add compatibility code to where the struct is read from disk to convert it to new internal format. - Change all sanity checks for volume name length to new length. > It's not actually all that hard, realistically. > Probably not if there's knowledge of the internals :-) Biggest problem for me would be that I don't have any clues of the side effects of changes I might cause :-) -- Ragge From deengert@anl.gov Tue Feb 24 20:28:25 2009 From: deengert@anl.gov (Douglas E. Engert) Date: Tue, 24 Feb 2009 14:28:25 -0600 Subject: [OpenAFS] OpenAFS 1.4.7.dfsg1-6 on Ubuntu Intrepid Message-ID: <49A45869.8060302@anl.gov> OpenAFS Version: 1.4.7.dfsg1-6 will run on Ubuntu Intrepid if started manually. But if stated by init out of rc2.d, afsd returns with: afsd: Mounting the AFS root on '/afs', flags: 0. afsd: Can't mount AFS on /afs(22) If I move /etc/rc2.d/S25openafs-client to S29openafs-client then it works from init. This moves it after the S28NetworkManager Anyone have any ideas why afsd could not mount the root on /afs? Does it need something the Network Manager did? The kernel is 2.6.27-11-generic -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From jaltman@secure-endpoints.com Tue Feb 24 20:37:48 2009 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Tue, 24 Feb 2009 15:37:48 -0500 Subject: [OpenAFS] OpenAFS 1.4.7.dfsg1-6 on Ubuntu Intrepid In-Reply-To: <49A45869.8060302@anl.gov> References: <49A45869.8060302@anl.gov> Message-ID: <49A45A9C.6070008@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms000302040503070107010603 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Douglas E. Engert wrote: > OpenAFS Version: 1.4.7.dfsg1-6 will run on Ubuntu Intrepid if started > manually. But if stated by init out of rc2.d, afsd returns with: > > afsd: Mounting the AFS root on '/afs', flags: 0. > afsd: Can't mount AFS on /afs(22) > > If I move /etc/rc2.d/S25openafs-client to S29openafs-client > then it works from init. This moves it after the S28NetworkManager > > Anyone have any ideas why afsd could not mount the root on /afs? > Does it need something the Network Manager did? > > The kernel is 2.6.27-11-generic If you are not using dynroot my guess is that the network wasn't available and therefore the workstation cell's root.afs could not be accessed. --------------ms000302040503070107010603 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 AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw 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 OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAyMjQyMDM3NDhaMCMGCSqGSIb3DQEJBDEWBBQ69bP1 QEF84AZcUlQI0zQXGMIrEDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEACq4SpGQ6IBqAXEsJPZJpYSZY9/rCNVC3bt7DHpgx2xZCZ8kG5l8I Xt8T5511M9J895onauDo7kMAIS+UsnAI9tW4Q5Oov8NEawl9KUpxMm+QgEv6Y3muoNQQnnAu 0d6SJK+Uw5VrAl3aRv2sQWgTw8Ax99ZBBQha2ss6V75NaCpe0xvMxdf+o1nvwoHLKCvqavNS NKwkmknbRH2FobAQxd7O8dKrACLkLxiJ1+I0NBx5/YcXiTvXOe0neLk+lCT8FfvjLjmw4hFV e2m2DN2WWNH/LxHILxfUj5/4yrzq5lAvTBUsh2NNgFSEimLEzU77YbrzMnD/PPF28m8c+XEq jAAAAAAAAA== --------------ms000302040503070107010603-- From rra@stanford.edu Tue Feb 24 21:18:02 2009 From: rra@stanford.edu (Russ Allbery) Date: Tue, 24 Feb 2009 13:18:02 -0800 Subject: [OpenAFS] OpenAFS 1.4.7.dfsg1-6 on Ubuntu Intrepid In-Reply-To: <49A45869.8060302@anl.gov> (Douglas E. Engert's message of "Tue\, 24 Feb 2009 14\:28\:25 -0600") References: <49A45869.8060302@anl.gov> Message-ID: <87k57fedpx.fsf@windlord.stanford.edu> "Douglas E. Engert" writes: > OpenAFS Version: 1.4.7.dfsg1-6 will run on Ubuntu Intrepid if started > manually. But if stated by init out of rc2.d, afsd returns with: > > afsd: Mounting the AFS root on '/afs', flags: 0. > afsd: Can't mount AFS on /afs(22) > > If I move /etc/rc2.d/S25openafs-client to S29openafs-client > then it works from init. This moves it after the S28NetworkManager > > Anyone have any ideas why afsd could not mount the root on /afs? > Does it need something the Network Manager did? You have to use -dynroot for any system where the network is started by some other process at some arbitrary point in the boot cycle (or even after the system has booted). As of 1.4.8.dfsg1-1, dynroot is now the default for new installations. I should have done that a long time ago; sorry about that. -- Russ Allbery (rra@stanford.edu) From deengert@anl.gov Tue Feb 24 22:26:09 2009 From: deengert@anl.gov (Douglas E. Engert) Date: Tue, 24 Feb 2009 16:26:09 -0600 Subject: [OpenAFS] OpenAFS 1.4.7.dfsg1-6 on Ubuntu Intrepid In-Reply-To: <87k57fedpx.fsf@windlord.stanford.edu> References: <49A45869.8060302@anl.gov> <87k57fedpx.fsf@windlord.stanford.edu> Message-ID: <49A47401.1020100@anl.gov> Yep, using -dynroot got it working Thanks guys. Russ Allbery wrote: > "Douglas E. Engert" writes: > >> OpenAFS Version: 1.4.7.dfsg1-6 will run on Ubuntu Intrepid if started >> manually. But if stated by init out of rc2.d, afsd returns with: >> >> afsd: Mounting the AFS root on '/afs', flags: 0. >> afsd: Can't mount AFS on /afs(22) >> >> If I move /etc/rc2.d/S25openafs-client to S29openafs-client >> then it works from init. This moves it after the S28NetworkManager >> >> Anyone have any ideas why afsd could not mount the root on /afs? >> Does it need something the Network Manager did? > > You have to use -dynroot for any system where the network is started by > some other process at some arbitrary point in the boot cycle (or even > after the system has booted). > > As of 1.4.8.dfsg1-1, dynroot is now the default for new installations. I > should have done that a long time ago; sorry about that. > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From ragge@ltu.se Wed Feb 25 12:18:45 2009 From: ragge@ltu.se (Anders Magnusson) Date: Wed, 25 Feb 2009 13:18:45 +0100 Subject: [OpenAFS] Windows client stop working after changing network adapters. Message-ID: <49A53725.1040105@ltu.se> Hi, I got a report of this strange problem with the Windows client on a laptop. Client is 1.5.57, laptop is XP SP2: Logging in via VPN to the wireless network -> AFS works fine. Disconnect VPN, use wireless network directly (AFS is allowed) -> AFS stop working. Reconnecting via VPN does not help. Writing tokens says: C:\>tokens Tokens held by the Cache Manager: AFS device may not have started To me it sounds like the SMB gateway or AFS interface stop working, but looking at the configuration of the interface it seems OK. Note that this might happen after any change of network interfaces (like up/down), not necessarily an IP number change. Also, it is not dependent of any VPN client to encounter the problem, using just plain wireless (or connecting/disconnecting cable) gives this result. Any hints? I'll add the afsd_init.log below. The entries: 2009-02-25 09:57:10: smb_LanAdapterChange 2009-02-25 09:57:10: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... 2009-02-25 09:57:10: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... always shows up when it stops talking. What can we do to debug this? -- Ragge 09:53:40: Create log file 09:53:40: Created log file PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\ATI Technologies\ATI Control Panel;C:\WINDOWS\system32\WindowsPowerShell\v1.0;C:\Program Files\MIT\Kerberos\bin;C:\Program Files\OpenAFS\Common;C:\Program Files\OpenAFS\Client\Program 2009-02-25 09:53:41: OEM Code Page = 850 2009-02-25 09:53:41: locale = C 2009-02-25 09:53:41: running on 2000+ - using RegisterServiceCtrlHandlerEx 2009-02-25 09:53:41: C:\Program Files\OpenAFS\Client\Program\afsd_service.exe version 1.5.5700 2009-02-25 09:53:41: Num of Process Modules: 46 2009-02-25 09:53:41: C:\Program Files\OpenAFS\Client\Program\libosi.dll version 1.5.5700 2009-02-25 09:53:43: C:\Program Files\OpenAFS\Common\afsrpc.dll version 1.5.5700 2009-02-25 09:53:44: C:\Program Files\OpenAFS\Common\afspthread.dll version 1.5.5700 2009-02-25 09:53:44: C:\Program Files\OpenAFS\Common\afsauthent.dll version 1.5.5700 2009-02-25 09:53:44: C:\Program Files\OpenAFS\Client\Program\libafsconf.dll version 1.5.5700 2009-02-25 09:53:44: osi_InitDebug code 0 2009-02-25 09:53:44: gethostname fdc-l017 2009-02-25 09:53:45: Lock Order Validation Off 2009-02-25 09:53:45: Trace Options = 0 2009-02-25 09:53:45: Default trace buffer size 10000 2009-02-25 09:53:45: osi_LogCreate log addr 9958c0 2009-02-25 09:53:45: Cache size 500000 2009-02-25 09:53:45: Chunk size 262144 (18) 2009-02-25 09:53:45: Block size 4096 2009-02-25 09:53:45: Defaulting to 4 background daemons 2009-02-25 09:53:46: Defaulting to 25 server threads 2009-02-25 09:53:46: Status cache entries: 20000 2009-02-25 09:53:46: Default volume cache entries: 3333 2009-02-25 09:53:46: Default cell cache entries: 1024 2009-02-25 09:53:46: Logoff token transfer on 2009-02-25 09:53:46: Logoff token transfer timeout 120 seconds 2009-02-25 09:53:46: Default root volume name root.afs 2009-02-25 09:53:46: Mount root /afs 2009-02-25 09:53:47: Default cache path C:\WINDOWS\TEMP\AFSCache 2009-02-25 09:53:47: Cache type is FILE 2009-02-25 09:53:47: Cache Validation on Startup 2009-02-25 09:53:47: Set to trap on panic 2009-02-25 09:53:47: Sys name x86_win32 i386_w2k i386_nt40 2009-02-25 09:53:47: SecurityLevel is crypt 2009-02-25 09:53:47: CM ForceAnonVLDB is off 2009-02-25 09:53:47: DNS will be used to find AFS cell servers 2009-02-25 09:53:47: Freelance client feature is activated 2009-02-25 09:53:47: SMB Server Unicode Support is enabled 2009-02-25 09:53:47: Dot files/dirs will be marked hidden 2009-02-25 09:53:47: Maximum number of multiplexed sessions is 50 2009-02-25 09:53:47: Maximum number of VCs per server is 100 2009-02-25 09:53:47: SMB authentication type is EXTENDED 2009-02-25 09:53:47: RX Jumbograms are disabled 2009-02-25 09:53:47: RX extraPackets is 2176 2009-02-25 09:53:47: RX udpbufsize is 262144 2009-02-25 09:53:47: RX maximum MTU is 1260 2009-02-25 09:53:47: RX Peer Statistics gathering is enabled 2009-02-25 09:53:47: RX Process Statistics gathering is enabled 2009-02-25 09:53:47: RX Hot Thread is enabled 2009-02-25 09:53:47: CM CallBackPort is 7001 2009-02-25 09:53:47: EnableServerLocks: server requested 2009-02-25 09:53:47: CM DeleteReadOnly is 0 2009-02-25 09:53:47: CM BPlusTrees is 1 2009-02-25 09:53:47: No PrefetchExecutableExtensions 2009-02-25 09:53:47: CM OfflineReadOnlyIsValid is 0 2009-02-25 09:53:47: CM GiveUpAllCallBacks is 0 2009-02-25 09:53:47: CM FollowBackupPath is 0 2009-02-25 09:53:48: First Network address 82f062eb SubnetMask fffffc00 2009-02-25 09:53:48: lanmanworkstation : SessTimeout 45 2009-02-25 09:53:48: ConnDeadTimeout is 22 2009-02-25 09:53:48: HardDeadTimeout is 45 2009-02-25 09:53:48: Cache File "C:\WINDOWS\TEMP\AFSCache" already exists 2009-02-25 09:53:48: Existing File Size: 00000000:217747D4 2009-02-25 09:53:48: Granularity - 10000 2009-02-25 09:53:48: Reusing existing AFS Cache data: 2009-02-25 09:53:49: Base Address = 202D0000 2009-02-25 09:53:49: stats = 20000 2009-02-25 09:53:49: chunkSize = 262144 2009-02-25 09:53:49: blockSize = 4096 2009-02-25 09:53:49: bufferSize = 561465300 2009-02-25 09:53:49: cacheType = 1 2009-02-25 09:53:49: volumeHashTableSize = 467 2009-02-25 09:53:49: currentVolumes = 6 2009-02-25 09:53:49: maxVolumes = 3333 2009-02-25 09:53:49: cellHashTableSize = 139 2009-02-25 09:53:49: currentCells = 3 2009-02-25 09:53:49: maxCells = 1024 2009-02-25 09:53:49: scacheHashTableSize = 9973 2009-02-25 09:53:49: currentSCaches = 6861 2009-02-25 09:53:49: maxSCaches = 20000 2009-02-25 09:53:49: Validating Cache Contents 2009-02-25 09:53:55: Volume Serial Number: 0x288b5350 2009-02-25 09:53:55: Machine SID: S-1-5-21-602162358-507921405-839522115 2009-02-25 09:53:55: Initializing Uuid to 7895e3f7-a31a-414d-afa9-f7c543c2f251 2009-02-25 09:53:55: Initializing Volume Data 2009-02-25 09:53:55: Initializing Cell Data 2009-02-25 09:53:55: Initializing ACL Data 2009-02-25 09:53:55: Initializing Stat Data 2009-02-25 09:53:55: CM UseDNLC = 1 2009-02-25 09:53:55: CM DebugDNLC = 0 2009-02-25 09:53:55: Initializing Data Buffers 2009-02-25 09:53:55: Cache Initialization Complete 2009-02-25 09:53:55: cm_InitMappedMemory code 0 2009-02-25 09:53:56: rx_SetNoJumbo successful 2009-02-25 09:53:56: rx_SetMaxMTU 1260 successful 2009-02-25 09:53:56: rx_SetUdpBufSize 262144 2009-02-25 09:53:56: rx_Init code 0 2009-02-25 09:53:57: rx_NewService addr 16fff68 2009-02-25 09:53:57: rx_NewService addr 16fffb0 2009-02-25 09:53:57: rx_StartServer 2009-02-25 09:53:57: cm_GetRootCellName code 0, cm_freelanceEnabled= 1, rcn= ltu.se 2009-02-25 09:53:58: Mountpoint[0] = ltu.se#ltu.se:root.cell. 2009-02-25 09:53:58: Mountpoint[1] = .ltu.se%ltu.se:root.cell. 2009-02-25 09:53:58: Mountpoint[2] = .root%ltu.se:root.afs. 2009-02-25 09:53:58: Mountpoint[3] = kth.se#kth.se:root.cell. 2009-02-25 09:53:59: Mountpoint[4] = athena.mit.edu#athena.mit.edu:root.cell. 2009-02-25 09:53:59: Mountpoint[5] = openafs.org#openafs.org:root.cell. 2009-02-25 09:53:59: cm_GetSCache code 0 scache 2056b808 2009-02-25 09:53:59: MpsSvc Service could not be opened for query: 0x424 2009-02-25 09:53:59: cm_InitDaemon complete 2009-02-25 09:53:59: RPC server listening 2009-02-25 09:53:59: AutoStart 0x2 2009-02-25 09:53:59: StoreAnsiFilenames = 0 2009-02-25 09:53:59: daemonCheckDownInterval is 180 2009-02-25 09:53:59: EnableSMBAsyncStore = 1 2009-02-25 09:53:59: daemonCheckUpInterval is 240 2009-02-25 09:53:59: SMBAsyncStoreSize = 131072 2009-02-25 09:53:59: daemonCheckVolInterval is 3600 2009-02-25 09:53:59: daemonCheckCBInterval is 60 2009-02-25 09:53:59: daemonCheckVolCBInterval is 0 2009-02-25 09:53:59: daemonCheckLockInterval is 60 2009-02-25 09:53:59: daemonCheckTokenInterval is 180 2009-02-25 09:53:59: daemonCheckOfflineVolInterval is 600 2009-02-25 09:53:59: daemonPerformanceTuningInterval is 0 2009-02-25 09:53:59: LAN adapter number 10 2009-02-25 09:54:00: Using >AFS< as SMB server name 2009-02-25 09:54:00: smb_localNamep is >AFS< 2009-02-25 09:54:00: Netbios NCBRESET lana 10 succeeded 2009-02-25 09:54:00: lana_list.length 1 2009-02-25 09:54:03: Netbios NCBADDNAME lana=10 code=0 retcode=0 complete=0 2009-02-25 09:54:03: Netbios NCBADDNAME added new name >AFS < 2009-02-25 09:54:03: Netbios NCBADDNAME succeeded on lana 10 2009-02-25 09:54:03: smb_NetbiosInit smb_LANadapter=10 2009-02-25 09:54:03: MsV1_0SetProcessOption success 2009-02-25 09:54:03: Setting SMB server domain name to [FDC-L017] 2009-02-25 09:54:03: smb_StartListeners 2009-02-25 09:54:03: smb_Init complete 2009-02-25 09:54:03: Unable to open Windows Firewall Profile 2009-02-25 09:54:03: GlobalAutoMap thread completed 2009-02-25 09:55:07: Windows Firewall Configuration succeeded 2009-02-25 09:56:47: smb_LanAdapterChange 2009-02-25 09:56:47: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... 2009-02-25 09:56:47: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... 2009-02-25 09:56:53: Mountpoint[0] = ltu.se#ltu.se:root.cell. 2009-02-25 09:56:53: Mountpoint[1] = .ltu.se%ltu.se:root.cell. 2009-02-25 09:56:53: Mountpoint[2] = .root%ltu.se:root.afs. 2009-02-25 09:56:53: Mountpoint[3] = kth.se#kth.se:root.cell. 2009-02-25 09:56:53: Mountpoint[4] = athena.mit.edu#athena.mit.edu:root.cell. 2009-02-25 09:56:53: Mountpoint[5] = openafs.org#openafs.org:root.cell. 2009-02-25 09:57:10: smb_LanAdapterChange 2009-02-25 09:57:10: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... 2009-02-25 09:57:10: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... 2009-02-25 10:00:57: smb_LanAdapterChange 2009-02-25 10:01:16: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... 2009-02-25 10:01:16: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... 2009-02-25 10:01:19: smb_LanAdapterChange 2009-02-25 10:01:19: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... 2009-02-25 10:01:19: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... 2009-02-25 10:01:23: smb_LanAdapterChange 2009-02-25 10:01:23: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... 2009-02-25 10:01:23: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... 2009-02-25 10:10:01: smb_LanAdapterChange 2009-02-25 10:10:01: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... 2009-02-25 10:10:01: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... 2009-02-25 10:10:29: smb_LanAdapterChange 2009-02-25 10:10:29: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... 2009-02-25 10:10:29: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... From jonathan.wheeler@stfc.ac.uk Wed Feb 25 15:22:54 2009 From: jonathan.wheeler@stfc.ac.uk (Wheeler, JF (Jonathan)) Date: Wed, 25 Feb 2009 15:22:54 -0000 Subject: [OpenAFS] Problem on OpenAFS server Message-ID: My cell currently has 3 servers. On one server (afs1), I find that the fileserver and volserver are continuously being restarted. The contents of /usr/afs/log/FileLog.old are: Wed Feb 25 14:46:34 2009 File server starting Wed Feb 25 14:48:04 2009 Cannot initialize RX bind failed The end of /usr/afs/log/BosLog reads: Wed Feb 25 14:43:34 2009: fs:salv exited with code 0 Wed Feb 25 14:45:04 2009: fs:file exited with code 1 Wed Feb 25 14:45:04 2009: fs:vol exited on signal 15 Wed Feb 25 14:45:04 2009: fs:salv exited with code 0 Wed Feb 25 14:46:34 2009: fs:file exited with code 1 Wed Feb 25 14:46:34 2009: fs:vol exited on signal 15 Wed Feb 25 14:46:34 2009: fs:salv exited with code 0 Wed Feb 25 14:48:04 2009: fs:file exited with code 1 Wed Feb 25 14:48:04 2009: fs:vol exited on signal 15 Wed Feb 25 14:48:04 2009: fs:salv exited with code 0 Can anyone give me a clue about what is happening, and how I should fix it ? Please ask if there is more information required; we are running opernafs-1.4.6-58 on Scientific Linux version 4.6 (very similar to RedHat EL version 4.6). The output of command "bos status" for all systems (afs[1-3]) is normal. Jonathan Wheeler=20 e-Science Centre=20 Rutherford Appleton Laboratory -- Scanned by iCritical. From christof.hanke@induhviduals.de Wed Feb 25 15:34:35 2009 From: christof.hanke@induhviduals.de (Christof Hanke) Date: Wed, 25 Feb 2009 17:34:35 +0200 Subject: [OpenAFS] Problem on OpenAFS server In-Reply-To: References: Message-ID: <200902251734.36028.christof.hanke@induhviduals.de> On Wednesday 25 February 2009 17:22:54 Wheeler, JF (Jonathan) wrote: > My cell currently has 3 servers. On one server (afs1), I find that the > fileserver and volserver are continuously being restarted. The contents > of /usr/afs/log/FileLog.old are: > > Wed Feb 25 14:46:34 2009 File server starting > Wed Feb 25 14:48:04 2009 Cannot initialize RX > bind failed > That is the problem. Check if there is another instance of the fileserver running, which is not in control of this bosserver, or if some other program blocks port 7000. HTH, Christof > The end of /usr/afs/log/BosLog reads: > > Wed Feb 25 14:43:34 2009: fs:salv exited with code 0 > Wed Feb 25 14:45:04 2009: fs:file exited with code 1 > Wed Feb 25 14:45:04 2009: fs:vol exited on signal 15 > Wed Feb 25 14:45:04 2009: fs:salv exited with code 0 > Wed Feb 25 14:46:34 2009: fs:file exited with code 1 > Wed Feb 25 14:46:34 2009: fs:vol exited on signal 15 > Wed Feb 25 14:46:34 2009: fs:salv exited with code 0 > Wed Feb 25 14:48:04 2009: fs:file exited with code 1 > Wed Feb 25 14:48:04 2009: fs:vol exited on signal 15 > Wed Feb 25 14:48:04 2009: fs:salv exited with code 0 > > Can anyone give me a clue about what is happening, and how I should fix > it ? Please ask if there is more information required; we are running > opernafs-1.4.6-58 on Scientific Linux version 4.6 (very similar to > RedHat EL version 4.6). > > The output of command "bos status" for all systems (afs[1-3]) is normal. > > Jonathan Wheeler > e-Science Centre > Rutherford Appleton Laboratory From rogerssp@physics.unc.edu Wed Feb 25 15:43:27 2009 From: rogerssp@physics.unc.edu (Sean Rogers) Date: Wed, 25 Feb 2009 10:43:27 -0500 (EST) Subject: [OpenAFS] AFS delaying server shutdown when network connectivity is lost Message-ID: Hi, I've been doing some testing involving shutting down servers (running Debian etch 2.6.18) while network connectivity has been lost. If the machine can't access AFS while it is shutting down I get the following messages: Jan 29 10:03:09 attack shutdown[6299]: shutting down for system halt Jan 29 10:03:09 attack init: Switching to runlevel: 0 Jan 29 10:03:50 attack apcupsd[6248]: 000.0,000.0,119.0,00.00,60.00,09.0,23.0,000.0,000.0,000.0,030.0,0 Jan 29 10:04:07 attack kernel: afs: Lost contact with volume location server x.x.x.x in cell physics.unc.edu Jan 29 10:04:07 attack kernel: afs: Lost contact with volume location server x.x.x.x in cell physics.unc.edu Jan 29 10:04:59 attack kernel: afs: Lost contact with volume location server x.x.x.x in cell physics.unc.edu Jan 29 10:04:59 attack kernel: afs: Lost contact with volume location server x.x.x.x in cell physics.unc.edu Jan 29 10:05:50 attack apcupsd[6248]: 000.0,000.0,119.0,00.00,60.00,09.0,23.0,000.0,000.0,000.0,038.0,1 Jan 29 10:05:57 attack kernel: afs: Lost contact with volume location server x.x.x.x in cell physics.unc.edu Jan 29 10:05:57 attack kernel: afs: Lost contact with volume location server x.x.x.x in cell physics.unc.edu This continues for 10 to 15 minutes, preventing the machine from shutting down. I've been able to fix this problem by setting AFS_DYNROOT to true in afs.conf.client file, but I was wondering if there was another solution to this problem? Thanks, Sean From jonathan.wheeler@stfc.ac.uk Wed Feb 25 16:05:23 2009 From: jonathan.wheeler@stfc.ac.uk (Wheeler, JF (Jonathan)) Date: Wed, 25 Feb 2009 16:05:23 -0000 Subject: FW: [OpenAFS] Problem on OpenAFS server Message-ID: > -----Original Message----- > From: openafs-info-admin@openafs.org [mailto:openafs-info- > admin@openafs.org] On Behalf Of Christof Hanke >=20 > On Wednesday 25 February 2009 17:22:54 Wheeler, JF (Jonathan) wrote: > > My cell currently has 3 servers. On one server (afs1), I find that the > > fileserver and volserver are continuously being restarted. The contents > > of /usr/afs/log/FileLog.old are: > > > > Wed Feb 25 14:46:34 2009 File server starting > > Wed Feb 25 14:48:04 2009 Cannot initialize RX > > bind failed > > > That is the problem. > Check if there is another instance of the fileserver running, which is not > in control of this bosserver, or if some other program blocks port 7000. >=20 > HTH, Absolutely it did. There was indeed another copy of fileserver running and "kill -9" fixed the problem. Thank you for your help. Jonathan Wheeler=20 e-Science Centre=20 Rutherford Appleton Laboratory -- Scanned by iCritical. From jaltman@secure-endpoints.com Wed Feb 25 16:45:47 2009 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 25 Feb 2009 11:45:47 -0500 Subject: [OpenAFS] Windows client stop working after changing network adapters. In-Reply-To: <49A53725.1040105@ltu.se> References: <49A53725.1040105@ltu.se> Message-ID: <49A575BB.8070907@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms070907040302020402070303 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Anders: The NRC_BRIDGE error means that the IP address the netbios name "AFS" is bound to is no longer available. The afsd_service smb_Listener thread therefore attempts to rebind the name to the existing adapter. The NRC_WILD error is a failure to be able to perform the re-bind. It therefore resets the adapter at the Netbios layer which breaks all communication across the adapter and then rebinds. The smb_LanAdapterChange log message indicates that Windows has reported a change in the IP address list (either an addition or removal of an IP address) via the NotifyAddrChange() API. So the question you need to answer is "why is Windows modifying the IP address list so frequently?" Jeffrey Altman Anders Magnusson wrote: > Hi, > > I got a report of this strange problem with the Windows client on a > laptop. Client is 1.5.57, laptop is XP SP2: > > Logging in via VPN to the wireless network -> AFS works fine. > Disconnect VPN, use wireless network directly (AFS is allowed) -> AFS > stop working. > Reconnecting via VPN does not help. > > Writing tokens says: > > C:\>tokens > Tokens held by the Cache Manager: > AFS device may not have started > > To me it sounds like the SMB gateway or AFS interface stop working, but > looking at the > configuration of the interface it seems OK. > > Note that this might happen after any change of network interfaces (like > up/down), not > necessarily an IP number change. Also, it is not dependent of any VPN > client to encounter > the problem, using just plain wireless (or connecting/disconnecting > cable) gives this result. > > Any hints? I'll add the afsd_init.log below. > > The entries: > 2009-02-25 09:57:10: smb_LanAdapterChange > 2009-02-25 09:57:10: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... > 2009-02-25 09:57:10: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... > always shows up when it stops talking. > > What can we do to debug this? > > -- Ragge > > 09:53:40: Create log file > 09:53:40: Created log file > PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program > Files\ATI Technologies\ATI Control > Panel;C:\WINDOWS\system32\WindowsPowerShell\v1.0;C:\Program > Files\MIT\Kerberos\bin;C:\Program Files\OpenAFS\Common;C:\Program > Files\OpenAFS\Client\Program > 2009-02-25 09:53:41: OEM Code Page = 850 > 2009-02-25 09:53:41: locale = C > 2009-02-25 09:53:41: running on 2000+ - using RegisterServiceCtrlHandlerEx > 2009-02-25 09:53:41: C:\Program > Files\OpenAFS\Client\Program\afsd_service.exe version 1.5.5700 > 2009-02-25 09:53:41: Num of Process Modules: 46 > 2009-02-25 09:53:41: C:\Program Files\OpenAFS\Client\Program\libosi.dll > version 1.5.5700 > 2009-02-25 09:53:43: C:\Program Files\OpenAFS\Common\afsrpc.dll version > 1.5.5700 > 2009-02-25 09:53:44: C:\Program Files\OpenAFS\Common\afspthread.dll > version 1.5.5700 > 2009-02-25 09:53:44: C:\Program Files\OpenAFS\Common\afsauthent.dll > version 1.5.5700 > 2009-02-25 09:53:44: C:\Program > Files\OpenAFS\Client\Program\libafsconf.dll version 1.5.5700 > 2009-02-25 09:53:44: osi_InitDebug code 0 > 2009-02-25 09:53:44: gethostname fdc-l017 > 2009-02-25 09:53:45: Lock Order Validation Off > 2009-02-25 09:53:45: Trace Options = 0 > 2009-02-25 09:53:45: Default trace buffer size 10000 > 2009-02-25 09:53:45: osi_LogCreate log addr 9958c0 > 2009-02-25 09:53:45: Cache size 500000 > 2009-02-25 09:53:45: Chunk size 262144 (18) > 2009-02-25 09:53:45: Block size 4096 > 2009-02-25 09:53:45: Defaulting to 4 background daemons > 2009-02-25 09:53:46: Defaulting to 25 server threads > 2009-02-25 09:53:46: Status cache entries: 20000 > 2009-02-25 09:53:46: Default volume cache entries: 3333 > 2009-02-25 09:53:46: Default cell cache entries: 1024 > 2009-02-25 09:53:46: Logoff token transfer on > 2009-02-25 09:53:46: Logoff token transfer timeout 120 seconds > 2009-02-25 09:53:46: Default root volume name root.afs > 2009-02-25 09:53:46: Mount root /afs > 2009-02-25 09:53:47: Default cache path C:\WINDOWS\TEMP\AFSCache > 2009-02-25 09:53:47: Cache type is FILE > 2009-02-25 09:53:47: Cache Validation on Startup > 2009-02-25 09:53:47: Set to trap on panic > 2009-02-25 09:53:47: Sys name x86_win32 i386_w2k i386_nt40 > 2009-02-25 09:53:47: SecurityLevel is crypt > 2009-02-25 09:53:47: CM ForceAnonVLDB is off > 2009-02-25 09:53:47: DNS will be used to find AFS cell servers > 2009-02-25 09:53:47: Freelance client feature is activated > 2009-02-25 09:53:47: SMB Server Unicode Support is enabled > 2009-02-25 09:53:47: Dot files/dirs will be marked hidden > 2009-02-25 09:53:47: Maximum number of multiplexed sessions is 50 > 2009-02-25 09:53:47: Maximum number of VCs per server is 100 > 2009-02-25 09:53:47: SMB authentication type is EXTENDED > 2009-02-25 09:53:47: RX Jumbograms are disabled > 2009-02-25 09:53:47: RX extraPackets is 2176 > 2009-02-25 09:53:47: RX udpbufsize is 262144 > 2009-02-25 09:53:47: RX maximum MTU is 1260 > 2009-02-25 09:53:47: RX Peer Statistics gathering is enabled > 2009-02-25 09:53:47: RX Process Statistics gathering is enabled > 2009-02-25 09:53:47: RX Hot Thread is enabled > 2009-02-25 09:53:47: CM CallBackPort is 7001 > 2009-02-25 09:53:47: EnableServerLocks: server requested > 2009-02-25 09:53:47: CM DeleteReadOnly is 0 > 2009-02-25 09:53:47: CM BPlusTrees is 1 > 2009-02-25 09:53:47: No PrefetchExecutableExtensions > 2009-02-25 09:53:47: CM OfflineReadOnlyIsValid is 0 > 2009-02-25 09:53:47: CM GiveUpAllCallBacks is 0 > 2009-02-25 09:53:47: CM FollowBackupPath is 0 > 2009-02-25 09:53:48: First Network address 82f062eb SubnetMask fffffc00 > 2009-02-25 09:53:48: lanmanworkstation : SessTimeout 45 > 2009-02-25 09:53:48: ConnDeadTimeout is 22 > 2009-02-25 09:53:48: HardDeadTimeout is 45 > 2009-02-25 09:53:48: Cache File "C:\WINDOWS\TEMP\AFSCache" already exists > 2009-02-25 09:53:48: Existing File Size: 00000000:217747D4 > 2009-02-25 09:53:48: Granularity - 10000 > 2009-02-25 09:53:48: Reusing existing AFS Cache data: > 2009-02-25 09:53:49: Base Address = 202D0000 > 2009-02-25 09:53:49: stats = 20000 > 2009-02-25 09:53:49: chunkSize = 262144 > 2009-02-25 09:53:49: blockSize = 4096 > 2009-02-25 09:53:49: bufferSize = 561465300 > 2009-02-25 09:53:49: cacheType = 1 > 2009-02-25 09:53:49: volumeHashTableSize = 467 > 2009-02-25 09:53:49: currentVolumes = 6 > 2009-02-25 09:53:49: maxVolumes = 3333 > 2009-02-25 09:53:49: cellHashTableSize = 139 > 2009-02-25 09:53:49: currentCells = 3 > 2009-02-25 09:53:49: maxCells = 1024 > 2009-02-25 09:53:49: scacheHashTableSize = 9973 > 2009-02-25 09:53:49: currentSCaches = 6861 > 2009-02-25 09:53:49: maxSCaches = 20000 > 2009-02-25 09:53:49: Validating Cache Contents > 2009-02-25 09:53:55: Volume Serial Number: 0x288b5350 > 2009-02-25 09:53:55: Machine SID: S-1-5-21-602162358-507921405-839522115 > 2009-02-25 09:53:55: Initializing Uuid to > 7895e3f7-a31a-414d-afa9-f7c543c2f251 > 2009-02-25 09:53:55: Initializing Volume Data > 2009-02-25 09:53:55: Initializing Cell Data > 2009-02-25 09:53:55: Initializing ACL Data > 2009-02-25 09:53:55: Initializing Stat Data > 2009-02-25 09:53:55: CM UseDNLC = 1 > 2009-02-25 09:53:55: CM DebugDNLC = 0 > 2009-02-25 09:53:55: Initializing Data Buffers > 2009-02-25 09:53:55: Cache Initialization Complete > 2009-02-25 09:53:55: cm_InitMappedMemory code 0 > 2009-02-25 09:53:56: rx_SetNoJumbo successful > 2009-02-25 09:53:56: rx_SetMaxMTU 1260 successful > 2009-02-25 09:53:56: rx_SetUdpBufSize 262144 > 2009-02-25 09:53:56: rx_Init code 0 > 2009-02-25 09:53:57: rx_NewService addr 16fff68 > 2009-02-25 09:53:57: rx_NewService addr 16fffb0 > 2009-02-25 09:53:57: rx_StartServer > 2009-02-25 09:53:57: cm_GetRootCellName code 0, cm_freelanceEnabled= 1, > rcn= ltu.se > 2009-02-25 09:53:58: Mountpoint[0] = ltu.se#ltu.se:root.cell. > 2009-02-25 09:53:58: Mountpoint[1] = .ltu.se%ltu.se:root.cell. > 2009-02-25 09:53:58: Mountpoint[2] = .root%ltu.se:root.afs. > 2009-02-25 09:53:58: Mountpoint[3] = kth.se#kth.se:root.cell. > 2009-02-25 09:53:59: Mountpoint[4] = > athena.mit.edu#athena.mit.edu:root.cell. > 2009-02-25 09:53:59: Mountpoint[5] = openafs.org#openafs.org:root.cell. > 2009-02-25 09:53:59: cm_GetSCache code 0 scache 2056b808 > 2009-02-25 09:53:59: MpsSvc Service could not be opened for query: 0x424 > 2009-02-25 09:53:59: cm_InitDaemon complete > 2009-02-25 09:53:59: RPC server listening > 2009-02-25 09:53:59: AutoStart 0x2 > 2009-02-25 09:53:59: StoreAnsiFilenames = 0 > 2009-02-25 09:53:59: daemonCheckDownInterval is 180 > 2009-02-25 09:53:59: EnableSMBAsyncStore = 1 > 2009-02-25 09:53:59: daemonCheckUpInterval is 240 > 2009-02-25 09:53:59: SMBAsyncStoreSize = 131072 > 2009-02-25 09:53:59: daemonCheckVolInterval is 3600 > 2009-02-25 09:53:59: daemonCheckCBInterval is 60 > 2009-02-25 09:53:59: daemonCheckVolCBInterval is 0 > 2009-02-25 09:53:59: daemonCheckLockInterval is 60 > 2009-02-25 09:53:59: daemonCheckTokenInterval is 180 > 2009-02-25 09:53:59: daemonCheckOfflineVolInterval is 600 > 2009-02-25 09:53:59: daemonPerformanceTuningInterval is 0 > 2009-02-25 09:53:59: LAN adapter number 10 > 2009-02-25 09:54:00: Using >AFS< as SMB server name > 2009-02-25 09:54:00: smb_localNamep is >AFS< > 2009-02-25 09:54:00: Netbios NCBRESET lana 10 succeeded > 2009-02-25 09:54:00: lana_list.length 1 > 2009-02-25 09:54:03: Netbios NCBADDNAME lana=10 code=0 retcode=0 complete=0 > 2009-02-25 09:54:03: Netbios NCBADDNAME added new name >AFS < > 2009-02-25 09:54:03: Netbios NCBADDNAME succeeded on lana 10 > 2009-02-25 09:54:03: smb_NetbiosInit smb_LANadapter=10 > 2009-02-25 09:54:03: MsV1_0SetProcessOption success > 2009-02-25 09:54:03: Setting SMB server domain name to [FDC-L017] > 2009-02-25 09:54:03: smb_StartListeners > 2009-02-25 09:54:03: smb_Init complete > 2009-02-25 09:54:03: Unable to open Windows Firewall Profile > 2009-02-25 09:54:03: GlobalAutoMap thread completed > 2009-02-25 09:55:07: Windows Firewall Configuration succeeded > 2009-02-25 09:56:47: smb_LanAdapterChange > 2009-02-25 09:56:47: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... > 2009-02-25 09:56:47: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... > 2009-02-25 09:56:53: Mountpoint[0] = ltu.se#ltu.se:root.cell. > 2009-02-25 09:56:53: Mountpoint[1] = .ltu.se%ltu.se:root.cell. > 2009-02-25 09:56:53: Mountpoint[2] = .root%ltu.se:root.afs. > 2009-02-25 09:56:53: Mountpoint[3] = kth.se#kth.se:root.cell. > 2009-02-25 09:56:53: Mountpoint[4] = > athena.mit.edu#athena.mit.edu:root.cell. > 2009-02-25 09:56:53: Mountpoint[5] = openafs.org#openafs.org:root.cell. > 2009-02-25 09:57:10: smb_LanAdapterChange > 2009-02-25 09:57:10: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... > 2009-02-25 09:57:10: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... > 2009-02-25 10:00:57: smb_LanAdapterChange > 2009-02-25 10:01:16: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... > 2009-02-25 10:01:16: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... > 2009-02-25 10:01:19: smb_LanAdapterChange > 2009-02-25 10:01:19: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... > 2009-02-25 10:01:19: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... > 2009-02-25 10:01:23: smb_LanAdapterChange > 2009-02-25 10:01:23: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... > 2009-02-25 10:01:23: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... > 2009-02-25 10:10:01: smb_LanAdapterChange > 2009-02-25 10:10:01: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... > 2009-02-25 10:10:01: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... > 2009-02-25 10:10:29: smb_LanAdapterChange > 2009-02-25 10:10:29: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... > 2009-02-25 10:10:29: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... > > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > --------------ms070907040302020402070303 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 AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw 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 OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAyMjUxNjQ1NDdaMCMGCSqGSIb3DQEJBDEWBBRHZaTf czdcze8I+ELQsdBQljz61jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAlSCPddHrSlY7BG2hBBVsG6uRGvbYlqIhsJ43TI48KdTP1TGcBaoV YvoWFQ+5KAD99UQs2/NKVNRHDaVhdKmRDZCXDeIzpIH3xFOinNLcdLvrj88xy8uKMKN8eVpJ vihSNjp8Ba6Y5y68RsrGb/ScmisN2GVyAWfcw/JYN78uJ1UK++D/tvlIoMDCnIG08+mApYuC p+aBYnVbfOrsq4OY1U7DS5ijMUY1jeI0pyd+8P3YnN4G7O08H8Jm6oeTfln1mDgiMIpY+i88 rNeFOx0dQptDKwbUSsWMlPB2TXovOwM5FoiDfxZerX2PaynuPtEfF3kYLV1VJXRO7/8SnNds IgAAAAAAAA== --------------ms070907040302020402070303-- From jaltman@secure-endpoints.com Wed Feb 25 17:22:43 2009 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 25 Feb 2009 12:22:43 -0500 Subject: [OpenAFS] Windows client stop working after changing network adapters. In-Reply-To: <49A575BB.8070907@secure-endpoints.com> References: <49A53725.1040105@ltu.se> <49A575BB.8070907@secure-endpoints.com> Message-ID: <49A57E63.10601@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms050203010800040800020000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit As a follow up to my own post. The problem is not that this sequence of events is occurring. It is supposed to. The problem is that it is occurring as frequently as it is when there is no apparent reason for the network stack to be resetting its IP address. On one of the Lenovo laptops the Intel drivers for the wired adapter attempts to hide the status of the network from Windows in order to prevent XP from displaying the "not connected balloon" from the notification area. The side effect of this is that the connection management software sees both the wireless and wired connections, turns off the wireless, then realizes the wired doesn't really exist, turns back on the wireless, thinks the wired is there, and repeats ... >From the user perspective the network performance sucks because there are a huge number of retries due to packet loss on the wireless interface. From the perspective of afsd_service, the IP address list is constantly changing. The fix for this machine was to disable the wired adapter entirely because it was never being used. Jeffrey Altman Jeffrey Altman wrote: > Anders: > > The NRC_BRIDGE error means that the IP address the netbios name "AFS" is > bound to is no longer available. The afsd_service smb_Listener thread > therefore attempts to rebind the name to the existing adapter. The > NRC_WILD error is a failure to be able to perform the re-bind. It > therefore resets the adapter at the Netbios layer which breaks all > communication across the adapter and then rebinds. > > The smb_LanAdapterChange log message indicates that Windows has reported > a change in the IP address list (either an addition or removal of an IP > address) via the NotifyAddrChange() API. > > So the question you need to answer is "why is Windows modifying the IP > address list so frequently?" > > Jeffrey Altman > > > Anders Magnusson wrote: >> Hi, >> >> I got a report of this strange problem with the Windows client on a >> laptop. Client is 1.5.57, laptop is XP SP2: >> >> Logging in via VPN to the wireless network -> AFS works fine. >> Disconnect VPN, use wireless network directly (AFS is allowed) -> AFS >> stop working. >> Reconnecting via VPN does not help. >> >> Writing tokens says: >> >> C:\>tokens >> Tokens held by the Cache Manager: >> AFS device may not have started >> >> To me it sounds like the SMB gateway or AFS interface stop working, but >> looking at the >> configuration of the interface it seems OK. >> >> Note that this might happen after any change of network interfaces (like >> up/down), not >> necessarily an IP number change. Also, it is not dependent of any VPN >> client to encounter >> the problem, using just plain wireless (or connecting/disconnecting >> cable) gives this result. >> >> Any hints? I'll add the afsd_init.log below. >> >> The entries: >> 2009-02-25 09:57:10: smb_LanAdapterChange >> 2009-02-25 09:57:10: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... >> 2009-02-25 09:57:10: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... >> always shows up when it stops talking. >> >> What can we do to debug this? >> >> -- Ragge >> >> 09:53:40: Create log file >> 09:53:40: Created log file >> PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program >> Files\ATI Technologies\ATI Control >> Panel;C:\WINDOWS\system32\WindowsPowerShell\v1.0;C:\Program >> Files\MIT\Kerberos\bin;C:\Program Files\OpenAFS\Common;C:\Program >> Files\OpenAFS\Client\Program >> 2009-02-25 09:53:41: OEM Code Page = 850 >> 2009-02-25 09:53:41: locale = C >> 2009-02-25 09:53:41: running on 2000+ - using RegisterServiceCtrlHandlerEx >> 2009-02-25 09:53:41: C:\Program >> Files\OpenAFS\Client\Program\afsd_service.exe version 1.5.5700 >> 2009-02-25 09:53:41: Num of Process Modules: 46 >> 2009-02-25 09:53:41: C:\Program Files\OpenAFS\Client\Program\libosi.dll >> version 1.5.5700 >> 2009-02-25 09:53:43: C:\Program Files\OpenAFS\Common\afsrpc.dll version >> 1.5.5700 >> 2009-02-25 09:53:44: C:\Program Files\OpenAFS\Common\afspthread.dll >> version 1.5.5700 >> 2009-02-25 09:53:44: C:\Program Files\OpenAFS\Common\afsauthent.dll >> version 1.5.5700 >> 2009-02-25 09:53:44: C:\Program >> Files\OpenAFS\Client\Program\libafsconf.dll version 1.5.5700 >> 2009-02-25 09:53:44: osi_InitDebug code 0 >> 2009-02-25 09:53:44: gethostname fdc-l017 >> 2009-02-25 09:53:45: Lock Order Validation Off >> 2009-02-25 09:53:45: Trace Options = 0 >> 2009-02-25 09:53:45: Default trace buffer size 10000 >> 2009-02-25 09:53:45: osi_LogCreate log addr 9958c0 >> 2009-02-25 09:53:45: Cache size 500000 >> 2009-02-25 09:53:45: Chunk size 262144 (18) >> 2009-02-25 09:53:45: Block size 4096 >> 2009-02-25 09:53:45: Defaulting to 4 background daemons >> 2009-02-25 09:53:46: Defaulting to 25 server threads >> 2009-02-25 09:53:46: Status cache entries: 20000 >> 2009-02-25 09:53:46: Default volume cache entries: 3333 >> 2009-02-25 09:53:46: Default cell cache entries: 1024 >> 2009-02-25 09:53:46: Logoff token transfer on >> 2009-02-25 09:53:46: Logoff token transfer timeout 120 seconds >> 2009-02-25 09:53:46: Default root volume name root.afs >> 2009-02-25 09:53:46: Mount root /afs >> 2009-02-25 09:53:47: Default cache path C:\WINDOWS\TEMP\AFSCache >> 2009-02-25 09:53:47: Cache type is FILE >> 2009-02-25 09:53:47: Cache Validation on Startup >> 2009-02-25 09:53:47: Set to trap on panic >> 2009-02-25 09:53:47: Sys name x86_win32 i386_w2k i386_nt40 >> 2009-02-25 09:53:47: SecurityLevel is crypt >> 2009-02-25 09:53:47: CM ForceAnonVLDB is off >> 2009-02-25 09:53:47: DNS will be used to find AFS cell servers >> 2009-02-25 09:53:47: Freelance client feature is activated >> 2009-02-25 09:53:47: SMB Server Unicode Support is enabled >> 2009-02-25 09:53:47: Dot files/dirs will be marked hidden >> 2009-02-25 09:53:47: Maximum number of multiplexed sessions is 50 >> 2009-02-25 09:53:47: Maximum number of VCs per server is 100 >> 2009-02-25 09:53:47: SMB authentication type is EXTENDED >> 2009-02-25 09:53:47: RX Jumbograms are disabled >> 2009-02-25 09:53:47: RX extraPackets is 2176 >> 2009-02-25 09:53:47: RX udpbufsize is 262144 >> 2009-02-25 09:53:47: RX maximum MTU is 1260 >> 2009-02-25 09:53:47: RX Peer Statistics gathering is enabled >> 2009-02-25 09:53:47: RX Process Statistics gathering is enabled >> 2009-02-25 09:53:47: RX Hot Thread is enabled >> 2009-02-25 09:53:47: CM CallBackPort is 7001 >> 2009-02-25 09:53:47: EnableServerLocks: server requested >> 2009-02-25 09:53:47: CM DeleteReadOnly is 0 >> 2009-02-25 09:53:47: CM BPlusTrees is 1 >> 2009-02-25 09:53:47: No PrefetchExecutableExtensions >> 2009-02-25 09:53:47: CM OfflineReadOnlyIsValid is 0 >> 2009-02-25 09:53:47: CM GiveUpAllCallBacks is 0 >> 2009-02-25 09:53:47: CM FollowBackupPath is 0 >> 2009-02-25 09:53:48: First Network address 82f062eb SubnetMask fffffc00 >> 2009-02-25 09:53:48: lanmanworkstation : SessTimeout 45 >> 2009-02-25 09:53:48: ConnDeadTimeout is 22 >> 2009-02-25 09:53:48: HardDeadTimeout is 45 >> 2009-02-25 09:53:48: Cache File "C:\WINDOWS\TEMP\AFSCache" already exists >> 2009-02-25 09:53:48: Existing File Size: 00000000:217747D4 >> 2009-02-25 09:53:48: Granularity - 10000 >> 2009-02-25 09:53:48: Reusing existing AFS Cache data: >> 2009-02-25 09:53:49: Base Address = 202D0000 >> 2009-02-25 09:53:49: stats = 20000 >> 2009-02-25 09:53:49: chunkSize = 262144 >> 2009-02-25 09:53:49: blockSize = 4096 >> 2009-02-25 09:53:49: bufferSize = 561465300 >> 2009-02-25 09:53:49: cacheType = 1 >> 2009-02-25 09:53:49: volumeHashTableSize = 467 >> 2009-02-25 09:53:49: currentVolumes = 6 >> 2009-02-25 09:53:49: maxVolumes = 3333 >> 2009-02-25 09:53:49: cellHashTableSize = 139 >> 2009-02-25 09:53:49: currentCells = 3 >> 2009-02-25 09:53:49: maxCells = 1024 >> 2009-02-25 09:53:49: scacheHashTableSize = 9973 >> 2009-02-25 09:53:49: currentSCaches = 6861 >> 2009-02-25 09:53:49: maxSCaches = 20000 >> 2009-02-25 09:53:49: Validating Cache Contents >> 2009-02-25 09:53:55: Volume Serial Number: 0x288b5350 >> 2009-02-25 09:53:55: Machine SID: S-1-5-21-602162358-507921405-839522115 >> 2009-02-25 09:53:55: Initializing Uuid to >> 7895e3f7-a31a-414d-afa9-f7c543c2f251 >> 2009-02-25 09:53:55: Initializing Volume Data >> 2009-02-25 09:53:55: Initializing Cell Data >> 2009-02-25 09:53:55: Initializing ACL Data >> 2009-02-25 09:53:55: Initializing Stat Data >> 2009-02-25 09:53:55: CM UseDNLC = 1 >> 2009-02-25 09:53:55: CM DebugDNLC = 0 >> 2009-02-25 09:53:55: Initializing Data Buffers >> 2009-02-25 09:53:55: Cache Initialization Complete >> 2009-02-25 09:53:55: cm_InitMappedMemory code 0 >> 2009-02-25 09:53:56: rx_SetNoJumbo successful >> 2009-02-25 09:53:56: rx_SetMaxMTU 1260 successful >> 2009-02-25 09:53:56: rx_SetUdpBufSize 262144 >> 2009-02-25 09:53:56: rx_Init code 0 >> 2009-02-25 09:53:57: rx_NewService addr 16fff68 >> 2009-02-25 09:53:57: rx_NewService addr 16fffb0 >> 2009-02-25 09:53:57: rx_StartServer >> 2009-02-25 09:53:57: cm_GetRootCellName code 0, cm_freelanceEnabled= 1, >> rcn= ltu.se >> 2009-02-25 09:53:58: Mountpoint[0] = ltu.se#ltu.se:root.cell. >> 2009-02-25 09:53:58: Mountpoint[1] = .ltu.se%ltu.se:root.cell. >> 2009-02-25 09:53:58: Mountpoint[2] = .root%ltu.se:root.afs. >> 2009-02-25 09:53:58: Mountpoint[3] = kth.se#kth.se:root.cell. >> 2009-02-25 09:53:59: Mountpoint[4] = >> athena.mit.edu#athena.mit.edu:root.cell. >> 2009-02-25 09:53:59: Mountpoint[5] = openafs.org#openafs.org:root.cell. >> 2009-02-25 09:53:59: cm_GetSCache code 0 scache 2056b808 >> 2009-02-25 09:53:59: MpsSvc Service could not be opened for query: 0x424 >> 2009-02-25 09:53:59: cm_InitDaemon complete >> 2009-02-25 09:53:59: RPC server listening >> 2009-02-25 09:53:59: AutoStart 0x2 >> 2009-02-25 09:53:59: StoreAnsiFilenames = 0 >> 2009-02-25 09:53:59: daemonCheckDownInterval is 180 >> 2009-02-25 09:53:59: EnableSMBAsyncStore = 1 >> 2009-02-25 09:53:59: daemonCheckUpInterval is 240 >> 2009-02-25 09:53:59: SMBAsyncStoreSize = 131072 >> 2009-02-25 09:53:59: daemonCheckVolInterval is 3600 >> 2009-02-25 09:53:59: daemonCheckCBInterval is 60 >> 2009-02-25 09:53:59: daemonCheckVolCBInterval is 0 >> 2009-02-25 09:53:59: daemonCheckLockInterval is 60 >> 2009-02-25 09:53:59: daemonCheckTokenInterval is 180 >> 2009-02-25 09:53:59: daemonCheckOfflineVolInterval is 600 >> 2009-02-25 09:53:59: daemonPerformanceTuningInterval is 0 >> 2009-02-25 09:53:59: LAN adapter number 10 >> 2009-02-25 09:54:00: Using >AFS< as SMB server name >> 2009-02-25 09:54:00: smb_localNamep is >AFS< >> 2009-02-25 09:54:00: Netbios NCBRESET lana 10 succeeded >> 2009-02-25 09:54:00: lana_list.length 1 >> 2009-02-25 09:54:03: Netbios NCBADDNAME lana=10 code=0 retcode=0 complete=0 >> 2009-02-25 09:54:03: Netbios NCBADDNAME added new name >AFS < >> 2009-02-25 09:54:03: Netbios NCBADDNAME succeeded on lana 10 >> 2009-02-25 09:54:03: smb_NetbiosInit smb_LANadapter=10 >> 2009-02-25 09:54:03: MsV1_0SetProcessOption success >> 2009-02-25 09:54:03: Setting SMB server domain name to [FDC-L017] >> 2009-02-25 09:54:03: smb_StartListeners >> 2009-02-25 09:54:03: smb_Init complete >> 2009-02-25 09:54:03: Unable to open Windows Firewall Profile >> 2009-02-25 09:54:03: GlobalAutoMap thread completed >> 2009-02-25 09:55:07: Windows Firewall Configuration succeeded >> 2009-02-25 09:56:47: smb_LanAdapterChange >> 2009-02-25 09:56:47: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... >> 2009-02-25 09:56:47: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... >> 2009-02-25 09:56:53: Mountpoint[0] = ltu.se#ltu.se:root.cell. >> 2009-02-25 09:56:53: Mountpoint[1] = .ltu.se%ltu.se:root.cell. >> 2009-02-25 09:56:53: Mountpoint[2] = .root%ltu.se:root.afs. >> 2009-02-25 09:56:53: Mountpoint[3] = kth.se#kth.se:root.cell. >> 2009-02-25 09:56:53: Mountpoint[4] = >> athena.mit.edu#athena.mit.edu:root.cell. >> 2009-02-25 09:56:53: Mountpoint[5] = openafs.org#openafs.org:root.cell. >> 2009-02-25 09:57:10: smb_LanAdapterChange >> 2009-02-25 09:57:10: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... >> 2009-02-25 09:57:10: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... >> 2009-02-25 10:00:57: smb_LanAdapterChange >> 2009-02-25 10:01:16: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... >> 2009-02-25 10:01:16: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... >> 2009-02-25 10:01:19: smb_LanAdapterChange >> 2009-02-25 10:01:19: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... >> 2009-02-25 10:01:19: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... >> 2009-02-25 10:01:23: smb_LanAdapterChange >> 2009-02-25 10:01:23: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... >> 2009-02-25 10:01:23: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... >> 2009-02-25 10:10:01: smb_LanAdapterChange >> 2009-02-25 10:10:01: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... >> 2009-02-25 10:10:01: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... >> 2009-02-25 10:10:29: smb_LanAdapterChange >> 2009-02-25 10:10:29: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... >> 2009-02-25 10:10:29: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... >> >> >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info >> --------------ms050203010800040800020000 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 AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw 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 OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAyMjUxNzIyNDNaMCMGCSqGSIb3DQEJBDEWBBR4siOi ZYxu29pQrsVkVN7xL3ewMTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAZR2yh0XJ0deMcB8aR9feMs1DWqqzMoKawJvrb8uIZqnylFEOWvoY QQlLoE+WZI4LJJN5eVsyr6t7mw/ozgkfnpe9hJI3ATJcm/AHlchAyQmE77eJs880LKeiSrgh rXvnZntuVYtg6QV0YX0nvdlaCu3HggzYiHGLg7xpybAYmcbEXFtQVkY4J+K3/nXQlenk+XlR T0kOef7IR8ozvjwpwmChPFccSco9n7ZVUrXAVodIiJJ4WGiqwqBKCpSp5CLaun11CP+VB2Zd GDrV6S2NEOmt11PbFNFMs+KvRgdfMl8b6RGQWqi03nybW6lvGU3xYmF9g+yto9jc9ZFLyxxw xAAAAAAAAA== --------------ms050203010800040800020000-- From ragge@ltu.se Wed Feb 25 17:38:15 2009 From: ragge@ltu.se (Anders Magnusson) Date: Wed, 25 Feb 2009 18:38:15 +0100 Subject: [OpenAFS] Windows client stop working after changing network adapters. In-Reply-To: <49A57E63.10601@secure-endpoints.com> References: <49A53725.1040105@ltu.se> <49A575BB.8070907@secure-endpoints.com> <49A57E63.10601@secure-endpoints.com> Message-ID: <49A58207.90004@ltu.se> Ok, thanks. Hm, this was on a Dell Inspiron 8600. So the AFS problem is that Windows is resetting its network adapters each 6 second, and each time afsd needs to rebind to the MLA? Ok, strange in that case. It's also interesting that everything works fine until the first disconnect (like changing from wireless to cable), then it starts bailing out. But OK, we have some more things to go on now. Thanks! (will try Lenovo tomorrow, we usually buy those machines now...) -- Ragge Jeffrey Altman wrote: > As a follow up to my own post. The problem is not that this sequence of > events is occurring. It is supposed to. The problem is that it is > occurring as frequently as it is when there is no apparent reason for > the network stack to be resetting its IP address. > > On one of the Lenovo laptops the Intel drivers for the wired adapter > attempts to hide the status of the network from Windows in order to > prevent XP from displaying the "not connected balloon" from the > notification area. The side effect of this is that the connection > management software sees both the wireless and wired connections, turns > off the wireless, then realizes the wired doesn't really exist, turns > back on the wireless, thinks the wired is there, and repeats ... > > >From the user perspective the network performance sucks because there > are a huge number of retries due to packet loss on the wireless > interface. From the perspective of afsd_service, the IP address list is > constantly changing. > > The fix for this machine was to disable the wired adapter entirely > because it was never being used. > > Jeffrey Altman > > > Jeffrey Altman wrote: > >> Anders: >> >> The NRC_BRIDGE error means that the IP address the netbios name "AFS" is >> bound to is no longer available. The afsd_service smb_Listener thread >> therefore attempts to rebind the name to the existing adapter. The >> NRC_WILD error is a failure to be able to perform the re-bind. It >> therefore resets the adapter at the Netbios layer which breaks all >> communication across the adapter and then rebinds. >> >> The smb_LanAdapterChange log message indicates that Windows has reported >> a change in the IP address list (either an addition or removal of an IP >> address) via the NotifyAddrChange() API. >> >> So the question you need to answer is "why is Windows modifying the IP >> address list so frequently?" >> >> Jeffrey Altman >> >> >> Anders Magnusson wrote: >> >>> Hi, >>> >>> I got a report of this strange problem with the Windows client on a >>> laptop. Client is 1.5.57, laptop is XP SP2: >>> >>> Logging in via VPN to the wireless network -> AFS works fine. >>> Disconnect VPN, use wireless network directly (AFS is allowed) -> AFS >>> stop working. >>> Reconnecting via VPN does not help. >>> >>> Writing tokens says: >>> >>> C:\>tokens >>> Tokens held by the Cache Manager: >>> AFS device may not have started >>> >>> To me it sounds like the SMB gateway or AFS interface stop working, but >>> looking at the >>> configuration of the interface it seems OK. >>> >>> Note that this might happen after any change of network interfaces (like >>> up/down), not >>> necessarily an IP number change. Also, it is not dependent of any VPN >>> client to encounter >>> the problem, using just plain wireless (or connecting/disconnecting >>> cable) gives this result. >>> >>> Any hints? I'll add the afsd_init.log below. >>> >>> The entries: >>> 2009-02-25 09:57:10: smb_LanAdapterChange >>> 2009-02-25 09:57:10: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... >>> 2009-02-25 09:57:10: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... >>> always shows up when it stops talking. >>> >>> What can we do to debug this? >>> >>> -- Ragge >>> >>> 09:53:40: Create log file >>> 09:53:40: Created log file >>> PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program >>> Files\ATI Technologies\ATI Control >>> Panel;C:\WINDOWS\system32\WindowsPowerShell\v1.0;C:\Program >>> Files\MIT\Kerberos\bin;C:\Program Files\OpenAFS\Common;C:\Program >>> Files\OpenAFS\Client\Program >>> 2009-02-25 09:53:41: OEM Code Page = 850 >>> 2009-02-25 09:53:41: locale = C >>> 2009-02-25 09:53:41: running on 2000+ - using RegisterServiceCtrlHandlerEx >>> 2009-02-25 09:53:41: C:\Program >>> Files\OpenAFS\Client\Program\afsd_service.exe version 1.5.5700 >>> 2009-02-25 09:53:41: Num of Process Modules: 46 >>> 2009-02-25 09:53:41: C:\Program Files\OpenAFS\Client\Program\libosi.dll >>> version 1.5.5700 >>> 2009-02-25 09:53:43: C:\Program Files\OpenAFS\Common\afsrpc.dll version >>> 1.5.5700 >>> 2009-02-25 09:53:44: C:\Program Files\OpenAFS\Common\afspthread.dll >>> version 1.5.5700 >>> 2009-02-25 09:53:44: C:\Program Files\OpenAFS\Common\afsauthent.dll >>> version 1.5.5700 >>> 2009-02-25 09:53:44: C:\Program >>> Files\OpenAFS\Client\Program\libafsconf.dll version 1.5.5700 >>> 2009-02-25 09:53:44: osi_InitDebug code 0 >>> 2009-02-25 09:53:44: gethostname fdc-l017 >>> 2009-02-25 09:53:45: Lock Order Validation Off >>> 2009-02-25 09:53:45: Trace Options = 0 >>> 2009-02-25 09:53:45: Default trace buffer size 10000 >>> 2009-02-25 09:53:45: osi_LogCreate log addr 9958c0 >>> 2009-02-25 09:53:45: Cache size 500000 >>> 2009-02-25 09:53:45: Chunk size 262144 (18) >>> 2009-02-25 09:53:45: Block size 4096 >>> 2009-02-25 09:53:45: Defaulting to 4 background daemons >>> 2009-02-25 09:53:46: Defaulting to 25 server threads >>> 2009-02-25 09:53:46: Status cache entries: 20000 >>> 2009-02-25 09:53:46: Default volume cache entries: 3333 >>> 2009-02-25 09:53:46: Default cell cache entries: 1024 >>> 2009-02-25 09:53:46: Logoff token transfer on >>> 2009-02-25 09:53:46: Logoff token transfer timeout 120 seconds >>> 2009-02-25 09:53:46: Default root volume name root.afs >>> 2009-02-25 09:53:46: Mount root /afs >>> 2009-02-25 09:53:47: Default cache path C:\WINDOWS\TEMP\AFSCache >>> 2009-02-25 09:53:47: Cache type is FILE >>> 2009-02-25 09:53:47: Cache Validation on Startup >>> 2009-02-25 09:53:47: Set to trap on panic >>> 2009-02-25 09:53:47: Sys name x86_win32 i386_w2k i386_nt40 >>> 2009-02-25 09:53:47: SecurityLevel is crypt >>> 2009-02-25 09:53:47: CM ForceAnonVLDB is off >>> 2009-02-25 09:53:47: DNS will be used to find AFS cell servers >>> 2009-02-25 09:53:47: Freelance client feature is activated >>> 2009-02-25 09:53:47: SMB Server Unicode Support is enabled >>> 2009-02-25 09:53:47: Dot files/dirs will be marked hidden >>> 2009-02-25 09:53:47: Maximum number of multiplexed sessions is 50 >>> 2009-02-25 09:53:47: Maximum number of VCs per server is 100 >>> 2009-02-25 09:53:47: SMB authentication type is EXTENDED >>> 2009-02-25 09:53:47: RX Jumbograms are disabled >>> 2009-02-25 09:53:47: RX extraPackets is 2176 >>> 2009-02-25 09:53:47: RX udpbufsize is 262144 >>> 2009-02-25 09:53:47: RX maximum MTU is 1260 >>> 2009-02-25 09:53:47: RX Peer Statistics gathering is enabled >>> 2009-02-25 09:53:47: RX Process Statistics gathering is enabled >>> 2009-02-25 09:53:47: RX Hot Thread is enabled >>> 2009-02-25 09:53:47: CM CallBackPort is 7001 >>> 2009-02-25 09:53:47: EnableServerLocks: server requested >>> 2009-02-25 09:53:47: CM DeleteReadOnly is 0 >>> 2009-02-25 09:53:47: CM BPlusTrees is 1 >>> 2009-02-25 09:53:47: No PrefetchExecutableExtensions >>> 2009-02-25 09:53:47: CM OfflineReadOnlyIsValid is 0 >>> 2009-02-25 09:53:47: CM GiveUpAllCallBacks is 0 >>> 2009-02-25 09:53:47: CM FollowBackupPath is 0 >>> 2009-02-25 09:53:48: First Network address 82f062eb SubnetMask fffffc00 >>> 2009-02-25 09:53:48: lanmanworkstation : SessTimeout 45 >>> 2009-02-25 09:53:48: ConnDeadTimeout is 22 >>> 2009-02-25 09:53:48: HardDeadTimeout is 45 >>> 2009-02-25 09:53:48: Cache File "C:\WINDOWS\TEMP\AFSCache" already exists >>> 2009-02-25 09:53:48: Existing File Size: 00000000:217747D4 >>> 2009-02-25 09:53:48: Granularity - 10000 >>> 2009-02-25 09:53:48: Reusing existing AFS Cache data: >>> 2009-02-25 09:53:49: Base Address = 202D0000 >>> 2009-02-25 09:53:49: stats = 20000 >>> 2009-02-25 09:53:49: chunkSize = 262144 >>> 2009-02-25 09:53:49: blockSize = 4096 >>> 2009-02-25 09:53:49: bufferSize = 561465300 >>> 2009-02-25 09:53:49: cacheType = 1 >>> 2009-02-25 09:53:49: volumeHashTableSize = 467 >>> 2009-02-25 09:53:49: currentVolumes = 6 >>> 2009-02-25 09:53:49: maxVolumes = 3333 >>> 2009-02-25 09:53:49: cellHashTableSize = 139 >>> 2009-02-25 09:53:49: currentCells = 3 >>> 2009-02-25 09:53:49: maxCells = 1024 >>> 2009-02-25 09:53:49: scacheHashTableSize = 9973 >>> 2009-02-25 09:53:49: currentSCaches = 6861 >>> 2009-02-25 09:53:49: maxSCaches = 20000 >>> 2009-02-25 09:53:49: Validating Cache Contents >>> 2009-02-25 09:53:55: Volume Serial Number: 0x288b5350 >>> 2009-02-25 09:53:55: Machine SID: S-1-5-21-602162358-507921405-839522115 >>> 2009-02-25 09:53:55: Initializing Uuid to >>> 7895e3f7-a31a-414d-afa9-f7c543c2f251 >>> 2009-02-25 09:53:55: Initializing Volume Data >>> 2009-02-25 09:53:55: Initializing Cell Data >>> 2009-02-25 09:53:55: Initializing ACL Data >>> 2009-02-25 09:53:55: Initializing Stat Data >>> 2009-02-25 09:53:55: CM UseDNLC = 1 >>> 2009-02-25 09:53:55: CM DebugDNLC = 0 >>> 2009-02-25 09:53:55: Initializing Data Buffers >>> 2009-02-25 09:53:55: Cache Initialization Complete >>> 2009-02-25 09:53:55: cm_InitMappedMemory code 0 >>> 2009-02-25 09:53:56: rx_SetNoJumbo successful >>> 2009-02-25 09:53:56: rx_SetMaxMTU 1260 successful >>> 2009-02-25 09:53:56: rx_SetUdpBufSize 262144 >>> 2009-02-25 09:53:56: rx_Init code 0 >>> 2009-02-25 09:53:57: rx_NewService addr 16fff68 >>> 2009-02-25 09:53:57: rx_NewService addr 16fffb0 >>> 2009-02-25 09:53:57: rx_StartServer >>> 2009-02-25 09:53:57: cm_GetRootCellName code 0, cm_freelanceEnabled= 1, >>> rcn= ltu.se >>> 2009-02-25 09:53:58: Mountpoint[0] = ltu.se#ltu.se:root.cell. >>> 2009-02-25 09:53:58: Mountpoint[1] = .ltu.se%ltu.se:root.cell. >>> 2009-02-25 09:53:58: Mountpoint[2] = .root%ltu.se:root.afs. >>> 2009-02-25 09:53:58: Mountpoint[3] = kth.se#kth.se:root.cell. >>> 2009-02-25 09:53:59: Mountpoint[4] = >>> athena.mit.edu#athena.mit.edu:root.cell. >>> 2009-02-25 09:53:59: Mountpoint[5] = openafs.org#openafs.org:root.cell. >>> 2009-02-25 09:53:59: cm_GetSCache code 0 scache 2056b808 >>> 2009-02-25 09:53:59: MpsSvc Service could not be opened for query: 0x424 >>> 2009-02-25 09:53:59: cm_InitDaemon complete >>> 2009-02-25 09:53:59: RPC server listening >>> 2009-02-25 09:53:59: AutoStart 0x2 >>> 2009-02-25 09:53:59: StoreAnsiFilenames = 0 >>> 2009-02-25 09:53:59: daemonCheckDownInterval is 180 >>> 2009-02-25 09:53:59: EnableSMBAsyncStore = 1 >>> 2009-02-25 09:53:59: daemonCheckUpInterval is 240 >>> 2009-02-25 09:53:59: SMBAsyncStoreSize = 131072 >>> 2009-02-25 09:53:59: daemonCheckVolInterval is 3600 >>> 2009-02-25 09:53:59: daemonCheckCBInterval is 60 >>> 2009-02-25 09:53:59: daemonCheckVolCBInterval is 0 >>> 2009-02-25 09:53:59: daemonCheckLockInterval is 60 >>> 2009-02-25 09:53:59: daemonCheckTokenInterval is 180 >>> 2009-02-25 09:53:59: daemonCheckOfflineVolInterval is 600 >>> 2009-02-25 09:53:59: daemonPerformanceTuningInterval is 0 >>> 2009-02-25 09:53:59: LAN adapter number 10 >>> 2009-02-25 09:54:00: Using >AFS< as SMB server name >>> 2009-02-25 09:54:00: smb_localNamep is >AFS< >>> 2009-02-25 09:54:00: Netbios NCBRESET lana 10 succeeded >>> 2009-02-25 09:54:00: lana_list.length 1 >>> 2009-02-25 09:54:03: Netbios NCBADDNAME lana=10 code=0 retcode=0 complete=0 >>> 2009-02-25 09:54:03: Netbios NCBADDNAME added new name >AFS < >>> 2009-02-25 09:54:03: Netbios NCBADDNAME succeeded on lana 10 >>> 2009-02-25 09:54:03: smb_NetbiosInit smb_LANadapter=10 >>> 2009-02-25 09:54:03: MsV1_0SetProcessOption success >>> 2009-02-25 09:54:03: Setting SMB server domain name to [FDC-L017] >>> 2009-02-25 09:54:03: smb_StartListeners >>> 2009-02-25 09:54:03: smb_Init complete >>> 2009-02-25 09:54:03: Unable to open Windows Firewall Profile >>> 2009-02-25 09:54:03: GlobalAutoMap thread completed >>> 2009-02-25 09:55:07: Windows Firewall Configuration succeeded >>> 2009-02-25 09:56:47: smb_LanAdapterChange >>> 2009-02-25 09:56:47: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... >>> 2009-02-25 09:56:47: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... >>> 2009-02-25 09:56:53: Mountpoint[0] = ltu.se#ltu.se:root.cell. >>> 2009-02-25 09:56:53: Mountpoint[1] = .ltu.se%ltu.se:root.cell. >>> 2009-02-25 09:56:53: Mountpoint[2] = .root%ltu.se:root.afs. >>> 2009-02-25 09:56:53: Mountpoint[3] = kth.se#kth.se:root.cell. >>> 2009-02-25 09:56:53: Mountpoint[4] = >>> athena.mit.edu#athena.mit.edu:root.cell. >>> 2009-02-25 09:56:53: Mountpoint[5] = openafs.org#openafs.org:root.cell. >>> 2009-02-25 09:57:10: smb_LanAdapterChange >>> 2009-02-25 09:57:10: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... >>> 2009-02-25 09:57:10: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... >>> 2009-02-25 10:00:57: smb_LanAdapterChange >>> 2009-02-25 10:01:16: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... >>> 2009-02-25 10:01:16: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... >>> 2009-02-25 10:01:19: smb_LanAdapterChange >>> 2009-02-25 10:01:19: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... >>> 2009-02-25 10:01:19: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... >>> 2009-02-25 10:01:23: smb_LanAdapterChange >>> 2009-02-25 10:01:23: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... >>> 2009-02-25 10:01:23: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... >>> 2009-02-25 10:10:01: smb_LanAdapterChange >>> 2009-02-25 10:10:01: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... >>> 2009-02-25 10:10:01: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... >>> 2009-02-25 10:10:29: smb_LanAdapterChange >>> 2009-02-25 10:10:29: NCBLISTEN lana=10 failed with NRC_BRIDGE, retrying ... >>> 2009-02-25 10:10:29: NCBLISTEN lana=10 failed with NRC_NOWILD, retrying ... >>> >>> >>> _______________________________________________ >>> OpenAFS-info mailing list >>> OpenAFS-info@openafs.org >>> https://lists.openafs.org/mailman/listinfo/openafs-info >>> >>> From R.Eggermont@TUDelft.nl Wed Feb 25 17:51:26 2009 From: R.Eggermont@TUDelft.nl (Robbert Eggermont) Date: Wed, 25 Feb 2009 18:51:26 +0100 Subject: [OpenAFS] Open files dissapear? Message-ID: <49A5851E.1060405@TUDelft.nl> L.S., I just put together a cell (for the first time) for evaluation purposes. Linux server and linux clients seem to work fine (all running OpenAFS 1.4.8), but I noticed one strange problem: While running blogbench (http://www.pureftpd.org/project/blogbench) on an OpenAFS directory, I get frequent "read(): No such file or directory" and "read(): Input/output error" warnings. > # blogbench -d test > > Frequency = 10 secs > Scratch dir = [test] > Spawning 3 writers... > Spawning 1 rewriters... > Spawning 5 commenters... > Spawning 100 readers... > Benchmarking for 30 iterations. > The test will run during 5 minutes. > > Nb blogs R articles W articles R pictures W pictures R comments W comments > read(): No such file or directoryread(): No such file or directory 13 183616 734 116511 629 67020 1855 > 20 127610 290 85064 445 67612 1046 > read(): Input/output errorread(): No such file or directory 25 6729 257 4919 211 4072 483 > read(): No such file or directoryread(): Input/output error 27 4168 151 3182 220 3575 413 > read(): No such file or directoryread(): No such file or directoryread(): No such file or directory 31 3602 183 2799 158 2527 353 Etc. On closer inspection, it appears that files are being unlinked that are still opened by the program. This should not be possible, right? Is this a feature, a configuration problem (if so what?) or a problem in the filesystem layer or OpenAFS code? Regards, Robbert Eggermont -- Robbert Eggermont Information & Communication Theory R.Eggermont@TUDelft.nl Electr.Eng., Mathematics & Comp.Science +31 (15) 2783234 Delft University of Technology From haba@kth.se Thu Feb 26 08:54:56 2009 From: haba@kth.se (Harald Barth) Date: Thu, 26 Feb 2009 09:54:56 +0100 (CET) Subject: [OpenAFS] Open files dissapear? In-Reply-To: <49A5851E.1060405@TUDelft.nl> References: <49A5851E.1060405@TUDelft.nl> Message-ID: <20090226.095456.163277544.haba@habanero.pdc.kth.se> > Is this a feature, a configuration problem (if so what?) or a problem in > the filesystem layer or OpenAFS code? Definitely not a feature IMHO. To help us think more about it: Distro? Kernel version? File system type of your cache? Is the cache its own partition? Is the problem repeatable? (I guess yes) Does the problem go away with memcache? Harald. PS: Feels like something is garbage collecting inodes a bit too agressively. From R.Eggermont@TUDelft.nl Thu Feb 26 09:57:35 2009 From: R.Eggermont@TUDelft.nl (Robbert Eggermont) Date: Thu, 26 Feb 2009 10:57:35 +0100 Subject: [OpenAFS] Open files dissapear? In-Reply-To: <20090226.095456.163277544.haba@habanero.pdc.kth.se> References: <49A5851E.1060405@TUDelft.nl> <20090226.095456.163277544.haba@habanero.pdc.kth.se> Message-ID: <49A6678F.6080400@TUDelft.nl> Harald Barth wrote: >> Is this a feature, a configuration problem (if so what?) or a problem in >> the filesystem layer or OpenAFS code? > > Definitely not a feature IMHO. To help us think more about it: First setup: Opensuse 10.3 standalone server/client machine (tests run on the server) kernel-default-2.6.22.19-0.2 (i686) openafs-1.4.8-55.1 openafs-kmp-default-1.4.8_2.6.22.19_0.2-55.1 openafs-client-1.4.8-55.1 openafs-server-1.4.8-55.1 Cache: shared ext3 partition (/) Repeatable: yes, in every run of blogbench Memcache: problem still present Second setup: Server: Redhat Enterprise Linux 5, 2.6.18-92.1.18.el5 x86_64 rpms from openafs download repository Clients: Opensuse 10.3, kernel versions 2.6.22.17-0.1-default and 2.6.22.19-0.2-default (i686 and x86_64), same openafs rpms as above, using memcache Problem is repeatable. I'm willing to experiment some more (when time permits). Robbert -- Robbert Eggermont Information & Communication Theory R.Eggermont@TUDelft.nl Electr.Eng., Mathematics & Comp.Science +31 (15) 2783234 Delft University of Technology From haba@kth.se Thu Feb 26 10:52:50 2009 From: haba@kth.se (Harald Barth) Date: Thu, 26 Feb 2009 11:52:50 +0100 (CET) Subject: [OpenAFS] Open files dissapear? In-Reply-To: <49A6678F.6080400@TUDelft.nl> References: <49A5851E.1060405@TUDelft.nl> <20090226.095456.163277544.haba@habanero.pdc.kth.se> <49A6678F.6080400@TUDelft.nl> Message-ID: <20090226.115250.222249353.haba@habanero.pdc.kth.se> Thanks for all the data! Did a quick test on my laptop. I consider my laptop to have "working AFS" ;-) > Problem is repeatable. Here too (with client 1.4.5 against server 1.4.7) so we can eliminate "problem due to recent changes in OpenAFS". $ ./src/blogbench -d /afs/...test/blogbench/ Frequency = 10 secs Scratch dir = [/afs/...test/blogbench/] Spawning 3 writers... Spawning 1 rewriters... Spawning 5 commenters... Spawning 100 readers... Benchmarking for 30 iterations. The test will run during 5 minutes. Nb blogs R articles W articles R pictures W pictures R comments W comments read(): No such file or directoryread(): No such file or directoryread(): No such file or directoryread(): No such file or directory >From the blogbench webpage: > Since some filesystems are unable to manage more than 32k or 64k > links to the same directory (an example is UFS), you should not > force the test to run a silly amount of time on these filesystems. So is blogbench running into the directory size limit of AFS and ignoring the error code or something like that? If I throttle down blogbench a bit it does not bail out: $ ./src/blogbench -c 2 -r 10 -w 2 -i 10 -d /afs/...test/blogbench/ Frequency = 10 secs Scratch dir = [/afs/...test/blogbench/] Spawning 2 writers... Spawning 1 rewriters... Spawning 2 commenters... Spawning 10 readers... Benchmarking for 10 iterations. The test will run during 1 minutes. Nb blogs R articles W articles R pictures W pictures R comments W comments 12 15764 672 8215 591 8715 1471 23 36326 611 21185 606 19617 1372 27 25634 302 14719 228 12865 670 37 35388 625 20725 631 17091 1085 41 11578 283 7091 170 6474 609 46 11071 368 7273 403 5718 704 47 1262 56 842 98 1284 106 59 23557 805 14762 544 12034 1236 60 3390 40 1813 83 1523 102 66 11984 319 7592 475 5874 756 Final score for writes: 66 Final score for reads : 3574 I don't know enough of the inner works of blogbench to be able to say more. Harald. From R.Eggermont@TUDelft.nl Fri Feb 27 09:38:36 2009 From: R.Eggermont@TUDelft.nl (Robbert Eggermont) Date: Fri, 27 Feb 2009 10:38:36 +0100 Subject: [OpenAFS] Open files dissapear? In-Reply-To: <20090226.115250.222249353.haba@habanero.pdc.kth.se> References: <49A5851E.1060405@TUDelft.nl> <20090226.095456.163277544.haba@habanero.pdc.kth.se> <49A6678F.6080400@TUDelft.nl> <20090226.115250.222249353.haba@habanero.pdc.kth.se> Message-ID: <49A7B49C.9030405@TUDelft.nl> Harald Barth wrote: > So is blogbench running into the directory size limit of AFS and > ignoring the error code or something like that? I would rule this out: the test only puts a limited amount of files in aech subdirectory, so it's only possible to hit the limits if the directories are not cleaned between runs. Furthermore, the problem occurs also very early in the test when only a couple of hundred files have been created. > If I throttle down blogbench a bit it does not bail out: I tried reducing the number of writer, rewriter, commenters and reader thread to 1. Same problem. >From what I learned from the webpage and the code, blogbench operates as followes: - The (re)writer threads open() a temporary file, write() some data, close() the file, and rename() the file to it's "real" name. - The reader threads open() a file (read-only), read() the file in, and close() the file. These are all standard C functions, nothing fancy. I've run blogbench on nfs and cifs mounts and there the problem doesn't show. I would say that the problems appears when a reader opens a file at the same moment as a rewriter renames a temporary file to that name. If I run stat() on the filename directly before and directly after the error occurs, the filename is linked to different inodes. I've been able to verify with lsof that the file descriptor is still open at that time, so it seems that the inode was removed prematurely. I also noticed another problem that may be related (or maybe not): > # ls -l > ls: cannot access pcmcia.h: No such file or directory > total 0 > ?????????? ? ? ? ? ? pcmcia.h I have a couple of files like this. I know very little about openafs, but could this (these?) be related to a problem in my Volume database? Regards, Robbert -- Robbert Eggermont Information & Communication Theory R.Eggermont@TUDelft.nl Electr.Eng., Mathematics & Comp.Science +31 (15) 2783234 Delft University of Technology From haba@kth.se Fri Feb 27 10:05:44 2009 From: haba@kth.se (Harald Barth) Date: Fri, 27 Feb 2009 11:05:44 +0100 (CET) Subject: [OpenAFS] Open files dissapear? In-Reply-To: <49A7B49C.9030405@TUDelft.nl> References: <49A6678F.6080400@TUDelft.nl> <20090226.115250.222249353.haba@habanero.pdc.kth.se> <49A7B49C.9030405@TUDelft.nl> Message-ID: <20090227.110544.179277710.haba@habanero.pdc.kth.se> > I would rule this out: the test only puts a limited amount of files in > aech subdirectory, so it's only possible to hit the limits if the > directories are not cleaned between runs. Furthermore, the problem > occurs also very early in the test when only a couple of hundred files > have been created. We'll have to look more at the problem, yes. > I would say that the problems appears when a reader opens a file at the > same moment as a rewriter renames a temporary file to that name. Hmm. strace() next. > I also noticed another problem that may be related (or maybe not): > > # ls -l > > ls: cannot access pcmcia.h: No such file or directory > > total 0 > > ?????????? ? ? ? ? ? pcmcia.h My files look like this if I have list but not read access on the directory, for example it the token for the user (who has "read") has expired and system:anyuser has "list". > I know very little about openafs, but could this (these?) be related to > a problem in my Volume database? Probably not. The stat information of files has nothing to do with the volume database. Harald. From R.Eggermont@TUDelft.nl Fri Feb 27 13:37:50 2009 From: R.Eggermont@TUDelft.nl (Robbert Eggermont) Date: Fri, 27 Feb 2009 14:37:50 +0100 Subject: [OpenAFS] Open files dissapear? In-Reply-To: <20090227.110544.179277710.haba@habanero.pdc.kth.se> References: <49A6678F.6080400@TUDelft.nl> <20090226.115250.222249353.haba@habanero.pdc.kth.se> <49A7B49C.9030405@TUDelft.nl> <20090227.110544.179277710.haba@habanero.pdc.kth.se> Message-ID: <49A7ECAE.90606@TUDelft.nl> Harald Barth wrote: >> I also noticed another problem that may be related (or maybe not): >>> # ls -l >>> ls: cannot access pcmcia.h: No such file or directory >>> total 0 >>> ?????????? ? ? ? ? ? pcmcia.h > > My files look like this if I have list but not read access on the > directory, for example it the token for the user (who has "read") has > expired and system:anyuser has "list". I have a token, rlidwka rights and I was able to remove all other files in the directory, except this one? Robbert -- Robbert Eggermont Information & Communication Theory R.Eggermont@TUDelft.nl Electr.Eng., Mathematics & Comp.Science +31 (15) 2783234 Delft University of Technology From ragge@ltu.se Sat Feb 28 16:44:12 2009 From: ragge@ltu.se (Anders Magnusson) Date: Sat, 28 Feb 2009 17:44:12 +0100 Subject: [OpenAFS] "smbclient" for AFS? Message-ID: <49A969DC.60304@ltu.se> Hi, quick question before I go deeper into it: Does it exist something similar to "smbclient" for AFS? For those who don't know; it's like an ftp client but for smb. I want something that do not need the kernel stuff to access AFS space. -- Ragge From bettsjohn@mac.com Sat Feb 28 19:07:00 2009 From: bettsjohn@mac.com (John Betts) Date: Sat, 28 Feb 2009 14:07:00 -0500 Subject: [OpenAFS] Only db server host can log into a "remote" fileserver volume References: <151BD794-E988-4485-9EAA-941582E33243@globalholdings.org> Message-ID: I am having trouble accessing a particular volume hosted by a stand- alone OpenAFS fileserver, from any client other than the one running on the DB Server Host. (_including_ the client running on the file server hosting the volume in question). When I try and access the volume I get the following error in /var/log/ system: Feb 27 20:39:23 [client] kernel: afs: Lost contact with file server [file.server.host2.ip] in cell [my.cell] (all multi-homed ip addresses down for the server) Feb 27 20:39:34 [client] kernel: afs: file server [file.server.host2.ip] in cell [my.cell] is back up (multi-homed address; other same-host interfaces may still be down) I would appreciate any help you could provide me in debugging this problem. My setup is as follows (all on same local subnet, all servers only have one network interface) host1 - DB Server + File Server (Ubuntu 8.10 Server Linux i386 OpenAFS 1.4.7) - hosting volume cell.shared on vicepa mounted on /afs/my.cell/ shared host2 - File Server (Linux sparc OpenAFS 1.5.57) - hosting volume cell.data on vicepa mounted on /afs/my.cell/data host3 - Client (Intel OS X 10.5 Client - OpenAFS 1.5.57) host4 - Client (PPC OS X 10.5 Server - OpenAFS 1.5.57 + Kerberos v5 KDC) ACL's on cell.shared and cell.data are both [loosened for debugging purposes]: fs listacl testdata Access list for testdata is Normal rights: system:administrators rlidwka system:anyuser rlidwka 1) if I am on any of the above hosts, I can go to /afs/my.cell/shared and perform any operation 2) if I am on host1 (DB Server host), I can go to /afs/my.cell/data and perform any operation 3) if I am on any host other than host1, including host 2 where cell.data is hosted, I get the Lost contact with file server error. I checked all the log files (BosLog,FileLog,VolserLog,etc.) and saw no activity. The only file that got showed any error was the system log. For what it's worth, my kerberos realm and AFS cell's differ, though I have krb.conf that points to my realm. I am stumped. Thanks in advance, JB From cclausen@acm.org Sat Feb 28 19:34:42 2009 From: cclausen@acm.org (Christopher D. Clausen) Date: Sat, 28 Feb 2009 13:34:42 -0600 Subject: [OpenAFS] Only db server host can log into a "remote" fileserver volume References: <151BD794-E988-4485-9EAA-941582E33243@globalholdings.org> Message-ID: John Betts wrote: > I am having trouble accessing a particular volume hosted by a stand- > alone OpenAFS fileserver, from any client other than the one running > on the DB Server Host. > (_including_ the client running on the file server hosting the volume > in question). > > host1 - DB Server + File Server (Ubuntu 8.10 Server Linux i386 OpenAFS > 1.4.7) - hosting volume cell.shared on vicepa mounted on /afs/my.cell/ > shared > host2 - File Server (Linux sparc OpenAFS 1.5.57) - hosting volume > cell.data on vicepa mounted on /afs/my.cell/data > host3 - Client (Intel OS X 10.5 Client - OpenAFS 1.5.57) > host4 - Client (PPC OS X 10.5 Server - OpenAFS 1.5.57 + Kerberos v5 > KDC) > 1) if I am on any of the above hosts, I can go to /afs/my.cell/shared > and perform any operation > 2) if I am on host1 (DB Server host), I can go to /afs/my.cell/data > and perform any operation > 3) if I am on any host other than host1, including host 2 where > cell.data is hosted, I get the Lost contact with file server error. It sounds like you have a non-routable IP in the volume database somewhere. Please show output of: vos listvldb -nore Also show contents of /etc/hosts from host1 and host2 Several of us are on the #openafs IRC channel on Freenode and we can help you debug further. < I am trying to build the kmod-openafs under FC10. I am able to build the user-space packages with no problem. The following might be helpful: 1. [root@tx3241-04 ~]# rpm -qa | grep kernel kernel-2.6.27.15-170.2.24.fc10.i686 kerneloops-0.12-1.fc10.i386 kernel-headers-2.6.27.15-170.2.24.fc10.i386 kernel-firmware-2.6.27.15-170.2.24.fc10.noarch kernel-devel-2.6.27.15-170.2.24.fc10.i686 As you can see, I have a package kernel-devel-2.6.27.15-170.2.24.fc10.i686 2. rpm -q --provides kernel-devel-2.6.27.15-170.2.24.fc10.i686 kernel-devel-i686 = 2.6.27.15-170.2.24.fc10 kernel-devel = 2.6.27.15-170.2.24.fc10 kernel-devel-uname-r = 2.6.27.15-170.2.24.fc10.i686 kernel-devel = 2.6.27.15-170.2.24.fc10 Now, when I try to compile afs for my kernel to make a kmod package: [root@tx3241-04 SPECS]# rpmbuild openafs.realmkit.spec --target=i686 Building target platforms: i686 Building for target i686 error: Failed build dependencies: kernel-devel-i686 = 2.6.27.15-170.2.24.fc10.i686 is needed by openafs-1.4.8-1.1.1.src Can you tell me why the spec file is failing and how to fix this? Thanks, Warren