From jm130794@gmail.com Tue Oct 1 19:51:31 2013 From: jm130794@gmail.com (Jean-Marc Choulet) Date: Tue, 01 Oct 2013 20:51:31 +0200 Subject: [OpenAFS] Move the fileserver to another machine Message-ID: <524B19B3.6020004@gmail.com> Hello, For our first OpenAFS server, we used one machine for host all daemons : files server, database server, ... Now, we want to move the files server to another machine. Is it difficult to do that, an how ? Can you give us some links and advices ? Thanks, Jean-Michel From Anne Salemme Tue Oct 1 20:08:47 2013 From: Anne Salemme (Anne Salemme) Date: Tue, 1 Oct 2013 12:08:47 -0700 (PDT) Subject: [OpenAFS] Move the fileserver to another machine In-Reply-To: <524B19B3.6020004@gmail.com> References: <524B19B3.6020004@gmail.com> Message-ID: <1380654527.35831.YahooMailNeo@web5803.biz.mail.ne1.yahoo.com> --1762445147-1563842309-1380654527=:35831 Content-Type: text/plain; charset=us-ascii on simple way would be: - add a new fileserver to the cell - 'vos move' all the volumes off the old fileserver to the new fileserver then you can either leave the old one running, but don't use it....or remove the old fileserver service from the cell. basically, you don't move the files, you move the volumes. anne ________________________________ From: Jean-Marc Choulet To: OpenAFS-info Sent: Tuesday, October 1, 2013 2:51 PM Subject: [OpenAFS] Move the fileserver to another machine Hello, For our first OpenAFS server, we used one machine for host all daemons : files server, database server, ... Now, we want to move the files server to another machine. Is it difficult to do that, an how ? Can you give us some links and advices ? Thanks, Jean-Michel _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info --1762445147-1563842309-1380654527=:35831 Content-Type: text/html; charset=us-ascii

on simple way would be:

- add a new fileserver to the cell

- 'vos move' all the volumes off the old fileserver to the new fileserver

then you can either leave the old one running, but don't use it....or remove the old fileserver service from the cell.

basically, you don't move the files, you move the volumes.

anne

From: Jean-Marc Choulet <jm130794@gmail.com>
To: OpenAFS-info <openafs-info@openafs.org>
Sent: Tuesday, October 1, 2013 2:51 PM
Subject: [OpenAFS] Move the fileserver to another machine

Hello,

For our first OpenAFS server, we used one machine for host all daemons : files server, database server, ...

Now, we want to move the files server to another machine. Is it difficult to do that, an how ? Can you give us some links and advices ?

Thanks,

Jean-Michel
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

--1762445147-1563842309-1380654527=:35831-- From jukka.tuominen@finndesign.fi Wed Oct 2 12:32:00 2013 From: jukka.tuominen@finndesign.fi (Jukka Tuominen) Date: Wed, 2 Oct 2013 14:32:00 +0300 (EEST) Subject: [OpenAFS] Re: Moving Magic Trio to another domain In-Reply-To: References: <5474075.2191.1380053523112.JavaMail.root@web03> Message-ID: I decided to reduce complexity and remove ldap from the equation, since it wasn't really utilized. I then updated the nsswitch.conf and pam.d confs accordingly. Now, I have a single client machine (VM) that works as intended using gdm gui login. Strangely enough, I cannot make other clients to work, not even running the very same VM under another host. AFAIU, it's the authorization through gdm, that doesn't work. Logging in as a local user + kinit;aklog works fine. In the client that's successful, auth.log: Oct 2 12:21:51 hostname gdm-session-worker[1208]: pam_succeed_if(gdm:auth): requirement "user ingroup nopasswdlogin" not met by user "username" Oct 2 12:21:55 hostname gdm-session-worker[1208]: pam_unix(gdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=username Oct 2 12:21:55 hostname gdm-session-worker[1208]: pam_krb5(gdm:auth): user username authenticated as username@NEW.DOMAIN Oct 2 12:21:55 hostname gdm-session-worker[1208]: pam_unix(gdm:session): session opened for user username by (uid=0) Other clients pass authentication, but not authorization through gdm, and the login screen is returned. /gdm/:0-slave.log.1: gdm-session-worker[1135]: pam_succeed_if(gdm:auth): requirement "user ingroup nopasswdlogin" not met by user "username" gdm-session-worker[1135]: pam_unix(gdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=username gdm-session-worker[1135]: pam_krb5(gdm:auth): user username authenticated as username@NEW.DOMAIN gdm-session-worker[1135]: pam_unix(gdm:session): session opened for user username by (uid=0) gdm-simple-slave[749]: WARNING: Failed to add user authorization: could not find user "username" on system ** ERROR:gdm-simple-slave.c:397:start_session_timeout: assertion failed: (auth_file != NULL) The working client machine is much faster than the others, so it can be a timeout issue, but then again, I never had that issue in the old-domain setup. The rejection happens in just about 1-2 seconds. Any ideas what could be the cause and how to fix it? br, jukka From jhutz@cmu.edu Wed Oct 2 16:34:23 2013 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Wed, 02 Oct 2013 11:34:23 -0400 Subject: [OpenAFS] Re: Questions about multihoming servers In-Reply-To: <52430254.1030102@your-file-system.com> References: <52421212.9050603@secure-endpoints.com> <52426080.5040706@your-file-system.com> <20130925101424.95f03cba.adeason@sinenomine.net> <52430254.1030102@your-file-system.com> Message-ID: <1380728063.29625.69.camel@destiny.pc.cs.cmu.edu> On Wed, 2013-09-25 at 11:33 -0400, Jeffrey Altman wrote: > All that logic does is IP address aliasing for the purpose of elections. > However, it does not permit the use of multiple addresses. UBIK does > not distribute RPCs across all of the DISK_UpdateInterfaceAddr() listed > addresses. It always uses the address in the CellServDB. AND you > cannot put multiple addresses for a server in the server's CellServDB. No. It always _starts_ by using the address in the CellServDB. Once addresses have been exchanged, Ubik will switch to a different address if the first one fails. This affects both elections (the VOTE service) and replication (the DISK service). > Go back to the original posting. The reason for adding multiple > interfaces was to increase throughput on the server. The OP doesn't say that. He asks for an opinion on link aggregation vs multihoming, either of which may be intended to provide increased throughput, redundancy, or both. > If only one > address is used for UBIK replication that is not multihomed support. Only one address _at a time_ is used. That certainly qualifies not only as supporting multihomed servers but taking advantage of it. > For the DB clients (cache manager, pts, vos, etc) which use a different > CellServDB from the server's CellServDB it is possible to list all of > the public addresses. The same is true if DNS SRV and AFSDB records are > used. However, each address appears to the client as a unique server. > This is fine for most situations but it also wasteful. The DB clients > do not have access to the list of registered addresses. Nor do they really need such access. Sure, if a connection goes down you might prefer to try a different server rather than an alternate address of the same server. Of course, if the failed component is the router leading to the unreachable interface, that may be exactly the wrong strategy. Fortunately, cache managers regularly check on dbserver availability and will generally not send real requests to a server already known to be down. All of that said, in general, link aggregation should be preferred over having a server with multiple interfaces on the same subnet. The latter arrangement offers very few benefits and generally does not result in improved throughput. -- Jeff From jhutz@cmu.edu Wed Oct 2 16:43:42 2013 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Wed, 02 Oct 2013 11:43:42 -0400 Subject: [OpenAFS] Re: Questions about multihoming servers In-Reply-To: <20130925114243.0df09044.adeason@sinenomine.net> References: <52421212.9050603@secure-endpoints.com> <52426080.5040706@your-file-system.com> <20130925101424.95f03cba.adeason@sinenomine.net> <52430254.1030102@your-file-system.com> <51EE7A23-80E3-4948-AEEC-4FCEB3DDD060@sinenomine.net> <20130925114243.0df09044.adeason@sinenomine.net> Message-ID: <1380728622.29625.75.camel@destiny.pc.cs.cmu.edu> On Wed, 2013-09-25 at 11:42 -0500, Andrew Deason wrote: > if 15640 still occurs, that's a bug 15640 was not a bug in OpenAFS when it was submitted 9 years ago, and it's still not a bug in OpenAFS. If you want multi-homed dbservers to work, then the primary addresses listed for each server in Ubik's CellServDB must be the one your operating system will actually use when sending packets to other servers' primary addresses. Otherwise, they will not be recognized as coming from a legitimate server. There are certainly things we could do to improve this situation, such as extending the CellServDB format to allow providing Ubik with a complete list of each server's addresses, or extending the address exchange that happens when a new server starts up such that the initial RPC does not have to be made from the new server's primary address. However, the absence of those enhancements is not a bug and does not mean that OpenAFS does not support multihomed databse servers or that it cannot take advantage of multiple addresses on such servers. -- Jeff From adeason@sinenomine.net Wed Oct 2 17:07:27 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Wed, 2 Oct 2013 11:07:27 -0500 Subject: [OpenAFS] Re: Questions about multihoming servers References: <52421212.9050603@secure-endpoints.com> <52426080.5040706@your-file-system.com> <20130925101424.95f03cba.adeason@sinenomine.net> <52430254.1030102@your-file-system.com> <51EE7A23-80E3-4948-AEEC-4FCEB3DDD060@sinenomine.net> <20130925114243.0df09044.adeason@sinenomine.net> <1380728622.29625.75.camel@destiny.pc.cs.cmu.edu> Message-ID: <20131002110727.010f5a76.adeason@sinenomine.net> On Wed, 02 Oct 2013 11:43:42 -0400 Jeffrey Hutzelman wrote: > On Wed, 2013-09-25 at 11:42 -0500, Andrew Deason wrote: > > > if 15640 still occurs, that's a bug > > 15640 was not a bug in OpenAFS when it was submitted 9 years ago, and > it's still not a bug in OpenAFS. If you want multi-homed dbservers to > work, then the primary addresses listed for each server in Ubik's > CellServDB must be the one your operating system will actually use > when sending packets to other servers' primary addresses. Otherwise, > they will not be recognized as coming from a legitimate server. I don't see how that could be the case currently, or why that would be necessary. SDISK_UpdateInterfaceAddr does not pay attention to the address where the packets are actually coming from, only the addresses given in the RPC arguments. Is there something else you're thinking of that creates a limitation like you describe? -- Andrew Deason adeason@sinenomine.net From adeason@sinenomine.net Wed Oct 2 17:25:53 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Wed, 2 Oct 2013 11:25:53 -0500 Subject: [OpenAFS] Re: Moving Magic Trio to another domain References: <5474075.2191.1380053523112.JavaMail.root@web03> Message-ID: <20131002112553.3f994d66.adeason@sinenomine.net> On Wed, 2 Oct 2013 14:32:00 +0300 (EEST) "Jukka Tuominen" wrote: > gdm-simple-slave[749]: WARNING: Failed to add user authorization: could > not find user "username" on system > ** > ERROR:gdm-simple-slave.c:397:start_session_timeout: assertion failed: > (auth_file != NULL) > > The working client machine is much faster than the others, so it can > be a timeout issue, but then again, I never had that issue in the > old-domain setup. The rejection happens in just about 1-2 seconds. > > Any ideas what could be the cause and how to fix it? Where is your passwd information? That is, your database of usernames and uids and such. It just looks like one machine can resolve 'username' to a uid, but on the other machine it cannot. This doesn't seem to have much to do with openafs anymore. -- Andrew Deason adeason@sinenomine.net From jukka.tuominen@finndesign.fi Wed Oct 2 18:42:18 2013 From: jukka.tuominen@finndesign.fi (Jukka Tuominen) Date: Wed, 2 Oct 2013 20:42:18 +0300 (EEST) Subject: [OpenAFS] Re: Moving Magic Trio to another domain In-Reply-To: <20131002112553.3f994d66.adeason@sinenomine.net> References: <5474075.2191.1380053523112.JavaMail.root@web03> <20131002112553.3f994d66.adeason@sinenomine.net> Message-ID: <4e09dd1ddb7e936909335cc4c0632278.squirrel@webmail.neutech.fi> > On Wed, 2 Oct 2013 14:32:00 +0300 (EEST) > "Jukka Tuominen" wrote: > >> gdm-simple-slave[749]: WARNING: Failed to add user authorization: could >> not find user "username" on system >> ** >> ERROR:gdm-simple-slave.c:397:start_session_timeout: assertion failed: >> (auth_file != NULL) >> >> The working client machine is much faster than the others, so it can >> be a timeout issue, but then again, I never had that issue in the >> old-domain setup. The rejection happens in just about 1-2 seconds. >> >> Any ideas what could be the cause and how to fix it? > > Where is your passwd information? That is, your database of usernames > and uids and such. It just looks like one machine can resolve 'username' > to a uid, but on the other machine it cannot. If I log in as a local unix user, then both machines can find the same information on command line. So far, all the services are on a single virtual machine to ease the development work. It now consists of a kerberos server, all openafs servers, and a libnss-afs package to pass on (afs?) metadata (+ other irrelevant services). None of the user information resides on the client side. In fact, the client machine is a read-only system, with a live-cd-type-of temporary ram-disk, and only the afs-homedirs are persistent over booting. Only the afs-cache partition survives boots to speed-up WAN connections. The two different client instances are identical (VM snapshots), and I also tried a USB memory stick boot that doesn't work anymore either. The working client runs under the same VM host as the server, so the connection is LAN. The clients that don't work are on another VM host, and neither LAN nor WAN connection work. nsswitch.conf BTW passwd: afs files group: afs files afspag shadow: files ... > > This doesn't seem to have much to do with openafs anymore. The reason why I ask this here was because when I had a faulty host-princ generated and added to the client's keytab, an authorization error was raised, similarly. So, I'm unsure whether the gdm is the source of the problem or the symptom of the authorization error elsewhere. AFAIU, afs is responsible of the authorization, am I wrong?. But if you feel this is out of the scope of this mailing list, I will seek the solution elsewhere. br, jukka > > -- > Andrew Deason > adeason@sinenomine.net > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > From utoddl@email.unc.edu Wed Oct 2 18:55:59 2013 From: utoddl@email.unc.edu (Todd Lewis) Date: Wed, 02 Oct 2013 13:55:59 -0400 Subject: [OpenAFS] Re: Moving Magic Trio to another domain In-Reply-To: <4e09dd1ddb7e936909335cc4c0632278.squirrel@webmail.neutech.fi> References: <5474075.2191.1380053523112.JavaMail.root@web03> <20131002112553.3f994d66.adeason@sinenomine.net> <4e09dd1ddb7e936909335cc4c0632278.squirrel@webmail.neutech.fi> Message-ID: <524C5E2F.90000@email.unc.edu> On 10/02/2013 01:42 PM, Jukka Tuominen sent: > > servers, and a libnss-afs package to pass on (afs?) metadata (+ other Surprised you got libnss-afs to build against 1.6.*. The openafs headers are missing some key stuff. > nsswitch.conf BTW > > passwd: afs files > group: afs files afspag > shadow: files Probably not the problem, or even related to the problem, but I'd put files before afs in nsswitch.conf Also, are you running nscd on both hosts? libnss-afs is not thread safe otherwise. -- +--------------------------------------------------------------+ / Todd_Lewis@unc.edu 919-445-0091 http://www.unc.edu/~utoddl / / "He has no enemies, but is intensely disliked / / by his friends." - Oscar Wilde / +--------------------------------------------------------------+ From jukka.tuominen@finndesign.fi Wed Oct 2 19:08:24 2013 From: jukka.tuominen@finndesign.fi (Jukka Tuominen) Date: Wed, 2 Oct 2013 21:08:24 +0300 (EEST) Subject: [OpenAFS] Re: Moving Magic Trio to another domain In-Reply-To: <524C5E2F.90000@email.unc.edu> References: <5474075.2191.1380053523112.JavaMail.root@web03> <20131002112553.3f994d66.adeason@sinenomine.net> <4e09dd1ddb7e936909335cc4c0632278.squirrel@webmail.neutech.fi> <524C5E2F.90000@email.unc.edu> Message-ID: > > > On 10/02/2013 01:42 PM, Jukka Tuominen sent: >> >> servers, and a libnss-afs package to pass on (afs?) metadata (+ other > > Surprised you got libnss-afs to build against 1.6.*. The openafs headers > are missing some key stuff. Actually, I found a .deb from /afs/megacz.com/pub/software/libnss-afs/ and it installed fine (read: didn't tell about possible errors) > >> nsswitch.conf BTW >> >> passwd: afs files >> group: afs files afspag >> shadow: files > > Probably not the problem, or even related to the problem, but I'd put > files before afs in nsswitch.conf I haven't tried that now, but will shortly... > > Also, are you running nscd on both hosts? libnss-afs is not thread safe > otherwise. Yes, it is installed. br, jukka > -- > +--------------------------------------------------------------+ > / Todd_Lewis@unc.edu 919-445-0091 http://www.unc.edu/~utoddl / > / "He has no enemies, but is intensely disliked / > / by his friends." - Oscar Wilde / > +--------------------------------------------------------------+ > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > From adeason@sinenomine.net Wed Oct 2 19:16:25 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Wed, 2 Oct 2013 13:16:25 -0500 Subject: [OpenAFS] Re: Moving Magic Trio to another domain References: <5474075.2191.1380053523112.JavaMail.root@web03> <20131002112553.3f994d66.adeason@sinenomine.net> <4e09dd1ddb7e936909335cc4c0632278.squirrel@webmail.neutech.fi> Message-ID: <20131002131625.20d41836.adeason@sinenomine.net> On Wed, 2 Oct 2013 20:42:18 +0300 (EEST) "Jukka Tuominen" wrote: > nsswitch.conf BTW > > passwd: afs files > group: afs files afspag > shadow: files Where is your home directory information stored? It's not in afs; we don't have a place for that that I'm aware of. The home directories themselves may be in afs, but the information that "user X has home directory /afs/foo/user/X" is not stored in an openafs database. > > This doesn't seem to have much to do with openafs anymore. > > The reason why I ask this here was because when I had a faulty > host-princ generated and added to the client's keytab, an > authorization error was raised, similarly. So, I'm unsure whether the > gdm is the source of the problem or the symptom of the authorization > error elsewhere. AFAIU, afs is responsible of the authorization, am I > wrong?. But if you feel this is out of the scope of this mailing list, > I will seek the solution elsewhere. I assume the errors you get from gdm are because gdm cannot get some information about "username" from the system. But I don't know enough about gdm to know what exactly it is failing on. Try running: $ getent passwd username on both systems. Does the output differ? -- Andrew Deason adeason@sinenomine.net From jukka.tuominen@finndesign.fi Wed Oct 2 19:39:44 2013 From: jukka.tuominen@finndesign.fi (Jukka Tuominen) Date: Wed, 2 Oct 2013 21:39:44 +0300 (EEST) Subject: [OpenAFS] Re: Moving Magic Trio to another domain In-Reply-To: <20131002131625.20d41836.adeason@sinenomine.net> References: <5474075.2191.1380053523112.JavaMail.root@web03> <20131002112553.3f994d66.adeason@sinenomine.net> <4e09dd1ddb7e936909335cc4c0632278.squirrel@webmail.neutech.fi> <20131002131625.20d41836.adeason@sinenomine.net> Message-ID: <1526a49cfcf143c04107cc525b381723.squirrel@webmail.neutech.fi> > On Wed, 2 Oct 2013 20:42:18 +0300 (EEST) > "Jukka Tuominen" wrote: > >> nsswitch.conf BTW >> >> passwd: afs files >> group: afs files afspag >> shadow: files BTW, I tried to change the order, but no change there. > > Where is your home directory information stored? It's not in afs; we > don't have a place for that that I'm aware of. The home directories > themselves may be in afs, but the information that "user X has home > directory /afs/foo/user/X" is not stored in an openafs database. According to http://techpubs.spinlocksolutions.com/dklar/afs.html libnss-afs provides that, assuming afs homedir path convention (which are used in this case) > >> > This doesn't seem to have much to do with openafs anymore. >> >> The reason why I ask this here was because when I had a faulty >> host-princ generated and added to the client's keytab, an >> authorization error was raised, similarly. So, I'm unsure whether the >> gdm is the source of the problem or the symptom of the authorization >> error elsewhere. AFAIU, afs is responsible of the authorization, am I >> wrong?. But if you feel this is out of the scope of this mailing list, >> I will seek the solution elsewhere. > > I assume the errors you get from gdm are because gdm cannot get some > information about "username" from the system. But I don't know enough > about gdm to know what exactly it is failing on. > > Try running: > > $ getent passwd username > > on both systems. Does the output differ? No, both succeed. br, jukka > > -- > Andrew Deason > adeason@sinenomine.net > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > From jhutz@cmu.edu Wed Oct 2 20:13:43 2013 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Wed, 02 Oct 2013 15:13:43 -0400 Subject: [OpenAFS] Re: Questions about multihoming servers In-Reply-To: <20131002110727.010f5a76.adeason@sinenomine.net> References: <52421212.9050603@secure-endpoints.com> <52426080.5040706@your-file-system.com> <20130925101424.95f03cba.adeason@sinenomine.net> <52430254.1030102@your-file-system.com> <51EE7A23-80E3-4948-AEEC-4FCEB3DDD060@sinenomine.net> <20130925114243.0df09044.adeason@sinenomine.net> <1380728622.29625.75.camel@destiny.pc.cs.cmu.edu> <20131002110727.010f5a76.adeason@sinenomine.net> Message-ID: <1380741223.4668.4.camel@destiny.pc.cs.cmu.edu> On Wed, 2013-10-02 at 11:07 -0500, Andrew Deason wrote: > On Wed, 02 Oct 2013 11:43:42 -0400 > Jeffrey Hutzelman wrote: > > > On Wed, 2013-09-25 at 11:42 -0500, Andrew Deason wrote: > > > > > if 15640 still occurs, that's a bug > > > > 15640 was not a bug in OpenAFS when it was submitted 9 years ago, and > > it's still not a bug in OpenAFS. If you want multi-homed dbservers to > > work, then the primary addresses listed for each server in Ubik's > > CellServDB must be the one your operating system will actually use > > when sending packets to other servers' primary addresses. Otherwise, > > they will not be recognized as coming from a legitimate server. > > I don't see how that could be the case currently, or why that would be > necessary. SDISK_UpdateInterfaceAddr does not pay attention to the > address where the packets are actually coming from, only the addresses > given in the RPC arguments. Is there something else you're thinking of > that creates a limitation like you describe? Hrm. I'd have to do some further digging -- that analysis was based in no small part on what I wrote in the ticket back in 2004, and it doesn't look like there was ever a reply to that. I agree that SDISK_UpdateInterfaceAddr doesn't use the address of the incoming connection and never has. From prochazka.nicolas@gmail.com Wed Oct 2 20:48:16 2013 From: prochazka.nicolas@gmail.com (nicolas prochazka) Date: Wed, 2 Oct 2013 21:48:16 +0200 Subject: [OpenAFS] [ OpenAFS - Cache FileSystem ] Message-ID: Hello, For your intention, In Faq, we can read : The OpenAFS cache manager will detect an unsupported filesystem and refuse to start. The following file systems have been reported to work for the AFS client cache: ext2 ext3 hfs (HP-UX) xfs (at least on IRIX 6.5) ufs (Solaris, ?Tru64Unix) But if I configure cache on zfs on linux ( zfsonlinux.org) , i got kernel panic : [114328.841466] Starting AFS cache scan... [114349.618208] openafs: Inconsistent file handles within cache [114349.618238] ------------[ cut here ]------------ [114349.618926] kernel BUG at /tmp/openafs/src/libafs/MODLOAD-3.11.2-MP/osi_file.c:129! [114349.620004] invalid opcode: 0000 [#1] SMP [114349.620004] Modules linked in: libafs(PO) zfs(PO) zunicode(PO) zavl(PO) zcommon(PO) znvpair(PO) spl(O) kvm_intel kvm [114349.620004] CPU: 0 PID: 32590 Comm: afsd Tainted: P O 3.11.2 #1 [114349.620004] Hardware name: NEC Express5800/120Rj-2 [N8100-1407E]/MS-9192-01S, BIOS 1.0.4S31 03/05/2010 [114349.620004] task: ffff88076e5f2000 ti: ffff880559c6c000 task.ti: ffff880559c6c000 [114349.620004] RIP: 0010:[] [] osi_get_fh+0xc8/0xe0 [libafs] [114349.620004] RSP: 0018:ffff880559c6dc38 EFLAGS: 00010296 [114349.620004] RAX: 000000000000002f RBX: 0000000000000007 RCX: 0000000000000000 [114349.620004] RDX: ffff88082fc0fa88 RSI: ffff88082fc0e178 RDI: 0000000000000246 [114349.620004] RBP: ffff880559c6dc48 R08: 0000000000000400 R09: ffffffff82716488 [114349.635745] R10: 000000000000041c R11: 000000000000041b R12: 0000000000000000 [114349.635745] R13: 000000000062dd80 R14: ffff88077ad03800 R15: 0000000000000001 [114349.635745] FS: 00007f2afb49c700(0000) GS:ffff88082fc00000(0000) knlGS:0000000000000000 [114349.635745] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [114349.635745] CR2: 000000007398600c CR3: 00000005583ef000 CR4: 00000000000027e0 [114349.635745] Stack: [114349.635745] ffff88077ad03800 0000000300000001 ffff880559c6dc68 ffffffffa02975c0 [114349.635745] ffff880559c6dc88 ffff88051fdb6900 ffff880559c6dca8 ffffffffa025ddfa [114349.635745] ffff880559c6dc98 ffffffff81064565 ffff880559c6dca8 ffffffff81f182cd [114349.635745] Call Trace: [114349.635745] [] osi_InitCacheInfo+0x40/0x80 [libafs] [114349.635745] [] afs_InitCacheInfo+0x2a/0x130 [libafs] [114349.635745] [] ? ns_capable+0x35/0x60 [114349.635745] [] ? mutex_lock+0x1d/0x50 [114349.635745] [] afs_syscall_call+0x105e/0x1bf0 [libafs] [114349.635745] [] ? do_last.isra.57+0x11b/0xc60 [114349.635745] [] ? inode_permission+0x18/0x50 [114349.635745] [] ? link_path_walk+0x23d/0x8e0 [114349.635745] [] ? lg_local_unlock+0x1a/0x20 [114349.635745] [] ? mntput_no_expire+0x49/0x160 [114349.635745] [] afs_syscall+0x17c/0x650 [libafs] [114349.635745] [] afs_unlocked_ioctl+0x69/0xd0 [libafs] [114349.635745] [] proc_reg_unlocked_ioctl+0x3f/0x70 [114349.635745] [] do_vfs_ioctl+0x8b/0x4f0 [114349.635745] [] ? final_putname+0x26/0x50 [114349.635745] [] SyS_ioctl+0x50/0x90 [114349.635745] [] system_call_fastpath+0x16/0x1b [114349.635745] Code: 8b 0d 75 2c 02 00 89 05 73 2c 02 00 89 c2 85 c9 79 ac 8b 4d fc 89 0d 60 2c 02 00 eb a1 48 c7 c7 08 42 2b a0 31 c0 e8 3a 40 c7 e1 <0f> 0b 48 c7 c7 e0 41 2b a0 31 c0 e8 2a 40 c7 e1 0f 0b 66 0f 1f [114349.635745] RIP [] osi_get_fh+0xc8/0xe0 [libafs] [114349.635745] RSP [114351.110672] ---[ end trace b1f29ac8defa1347 ]--- From adeason@sinenomine.net Wed Oct 2 23:02:32 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Wed, 2 Oct 2013 17:02:32 -0500 Subject: [OpenAFS] Re: Moving Magic Trio to another domain References: <5474075.2191.1380053523112.JavaMail.root@web03> <20131002112553.3f994d66.adeason@sinenomine.net> <4e09dd1ddb7e936909335cc4c0632278.squirrel@webmail.neutech.fi> <20131002131625.20d41836.adeason@sinenomine.net> <1526a49cfcf143c04107cc525b381723.squirrel@webmail.neutech.fi> Message-ID: <20131002170232.36565466.adeason@sinenomine.net> On Wed, 2 Oct 2013 21:39:44 +0300 (EEST) "Jukka Tuominen" wrote: > > Try running: > > > > $ getent passwd username > > > > on both systems. Does the output differ? > > No, both succeed. Okay, then I don't know what gdm is complaining about. I assume from your previous mails that kinit, aklog, and /afs access all work, so I don't know what is "wrong" for the user. I assume it has to do with these messages, since these are the only things different in the log you posted earlier: > gdm-simple-slave[749]: WARNING: Failed to add user authorization: could > not find user "username" on system > ** > ERROR:gdm-simple-slave.c:397:start_session_timeout: assertion failed: > (auth_file != NULL) But those are gdm error messages, and I don't know what they mean. Either look in gdm documentation or ask gdm people what they mean, or maybe try turning up gdm debugging or 'strace'ing the gdm process or something. -- Andrew Deason adeason@sinenomine.net From marc.c.dionne@gmail.com Wed Oct 2 23:18:05 2013 From: marc.c.dionne@gmail.com (Marc Dionne) Date: Wed, 2 Oct 2013 18:18:05 -0400 Subject: [OpenAFS] [ OpenAFS - Cache FileSystem ] In-Reply-To: References: Message-ID: On Wed, Oct 2, 2013 at 3:48 PM, nicolas prochazka wrote: > Hello, > For your intention, > In Faq, we can read : > > The OpenAFS cache manager will detect an unsupported filesystem and > refuse to start. > > The following file systems have been reported to work for the AFS client cache: > > ext2 > ext3 > hfs (HP-UX) > xfs (at least on IRIX 6.5) > ufs (Solaris, ?Tru64Unix) That information is somewhat outdated; for more recent OpenAFS releases and Linux kernels there are no runtime checks, and any filesystem that is exportable by NFS has a good chance of being usable for holding the client cache. So the list of possible filesystems is substantially larger than the above. > But if I configure cache on zfs on linux ( zfsonlinux.org) , > i got kernel panic : > > [114328.841466] Starting AFS cache scan... > [114349.618208] openafs: Inconsistent file handles within cache I haven't looked at zfs code closely, but that message suggests that - zfs does provide the necessary exportfs API calls, so should be usable in theory - maybe your cache location crosses a mount point between zfs and some other filesystem - or, zfs produces file handles of variable length. The current client code assumes that handles have a constant size, so if this is the case, some changes will be required before zfs can be used to hold the AFS disk cache. Marc From prochazka.nicolas@gmail.com Thu Oct 3 09:18:40 2013 From: prochazka.nicolas@gmail.com (nicolas prochazka) Date: Thu, 3 Oct 2013 10:18:40 +0200 Subject: [OpenAFS] [ OpenAFS - Cache FileSystem ] In-Reply-To: References: Message-ID: Ok, thanks for this precision about openafs cache. Regards, Nicolas Prochazka 2013/10/3 Marc Dionne : > On Wed, Oct 2, 2013 at 3:48 PM, nicolas prochazka > wrote: >> Hello, >> For your intention, >> In Faq, we can read : >> >> The OpenAFS cache manager will detect an unsupported filesystem and >> refuse to start. >> >> The following file systems have been reported to work for the AFS client cache: >> >> ext2 >> ext3 >> hfs (HP-UX) >> xfs (at least on IRIX 6.5) >> ufs (Solaris, ?Tru64Unix) > > That information is somewhat outdated; for more recent OpenAFS > releases and Linux kernels there are no runtime checks, and any > filesystem that is exportable by NFS has a good chance of being usable > for holding the client cache. So the list of possible filesystems is > substantially larger than the above. > >> But if I configure cache on zfs on linux ( zfsonlinux.org) , >> i got kernel panic : >> >> [114328.841466] Starting AFS cache scan... >> [114349.618208] openafs: Inconsistent file handles within cache > > I haven't looked at zfs code closely, but that message suggests that > - zfs does provide the necessary exportfs API calls, so should be > usable in theory > - maybe your cache location crosses a mount point between zfs and some > other filesystem > - or, zfs produces file handles of variable length. The current > client code assumes that handles have a constant size, so if this is > the case, some changes will be required before zfs can be used to hold > the AFS disk cache. > > Marc From smckee@umich.edu Thu Oct 3 14:00:59 2013 From: smckee@umich.edu (Shawn McKee) Date: Thu, 3 Oct 2013 09:00:59 -0400 Subject: [OpenAFS] [ OpenAFS - Cache FileSystem ] In-Reply-To: References: Message-ID: --001a11c2eea0053a2004e7d5c7df Content-Type: text/plain; charset=ISO-8859-1 Hi Nicolas, Just as an FYI we are running our AFS cell (atlas.umich.edu) over ZFS v0.6.2 on Scientific Linux 6.4 64-bit without a problem. Shawn On Wed, Oct 2, 2013 at 3:48 PM, nicolas prochazka < prochazka.nicolas@gmail.com> wrote: > Hello, > For your intention, > In Faq, we can read : > > The OpenAFS cache manager will detect an unsupported filesystem and > refuse to start. > > The following file systems have been reported to work for the AFS client > cache: > > ext2 > ext3 > hfs (HP-UX) > xfs (at least on IRIX 6.5) > ufs (Solaris, ?Tru64Unix) > > > But if I configure cache on zfs on linux ( zfsonlinux.org) , > i got kernel panic : > > [114328.841466] Starting AFS cache scan... > [114349.618208] openafs: Inconsistent file handles within cache > [114349.618238] ------------[ cut here ]------------ > [114349.618926] kernel BUG at > /tmp/openafs/src/libafs/MODLOAD-3.11.2-MP/osi_file.c:129! > [114349.620004] invalid opcode: 0000 [#1] SMP > [114349.620004] Modules linked in: libafs(PO) zfs(PO) zunicode(PO) > zavl(PO) zcommon(PO) znvpair(PO) spl(O) kvm_intel kvm > [114349.620004] CPU: 0 PID: 32590 Comm: afsd Tainted: P O > 3.11.2 #1 > [114349.620004] Hardware name: NEC Express5800/120Rj-2 > [N8100-1407E]/MS-9192-01S, BIOS 1.0.4S31 03/05/2010 > [114349.620004] task: ffff88076e5f2000 ti: ffff880559c6c000 task.ti: > ffff880559c6c000 > [114349.620004] RIP: 0010:[] [] > osi_get_fh+0xc8/0xe0 [libafs] > [114349.620004] RSP: 0018:ffff880559c6dc38 EFLAGS: 00010296 > [114349.620004] RAX: 000000000000002f RBX: 0000000000000007 RCX: > 0000000000000000 > [114349.620004] RDX: ffff88082fc0fa88 RSI: ffff88082fc0e178 RDI: > 0000000000000246 > [114349.620004] RBP: ffff880559c6dc48 R08: 0000000000000400 R09: > ffffffff82716488 > [114349.635745] R10: 000000000000041c R11: 000000000000041b R12: > 0000000000000000 > [114349.635745] R13: 000000000062dd80 R14: ffff88077ad03800 R15: > 0000000000000001 > [114349.635745] FS: 00007f2afb49c700(0000) GS:ffff88082fc00000(0000) > knlGS:0000000000000000 > [114349.635745] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [114349.635745] CR2: 000000007398600c CR3: 00000005583ef000 CR4: > 00000000000027e0 > [114349.635745] Stack: > [114349.635745] ffff88077ad03800 0000000300000001 ffff880559c6dc68 > ffffffffa02975c0 > [114349.635745] ffff880559c6dc88 ffff88051fdb6900 ffff880559c6dca8 > ffffffffa025ddfa > [114349.635745] ffff880559c6dc98 ffffffff81064565 ffff880559c6dca8 > ffffffff81f182cd > [114349.635745] Call Trace: > [114349.635745] [] osi_InitCacheInfo+0x40/0x80 [libafs] > [114349.635745] [] afs_InitCacheInfo+0x2a/0x130 [libafs] > [114349.635745] [] ? ns_capable+0x35/0x60 > [114349.635745] [] ? mutex_lock+0x1d/0x50 > [114349.635745] [] afs_syscall_call+0x105e/0x1bf0 > [libafs] > [114349.635745] [] ? do_last.isra.57+0x11b/0xc60 > [114349.635745] [] ? inode_permission+0x18/0x50 > [114349.635745] [] ? link_path_walk+0x23d/0x8e0 > [114349.635745] [] ? lg_local_unlock+0x1a/0x20 > [114349.635745] [] ? mntput_no_expire+0x49/0x160 > [114349.635745] [] afs_syscall+0x17c/0x650 [libafs] > [114349.635745] [] afs_unlocked_ioctl+0x69/0xd0 [libafs] > [114349.635745] [] proc_reg_unlocked_ioctl+0x3f/0x70 > [114349.635745] [] do_vfs_ioctl+0x8b/0x4f0 > [114349.635745] [] ? final_putname+0x26/0x50 > [114349.635745] [] SyS_ioctl+0x50/0x90 > [114349.635745] [] system_call_fastpath+0x16/0x1b > [114349.635745] Code: 8b 0d 75 2c 02 00 89 05 73 2c 02 00 89 c2 85 c9 > 79 ac 8b 4d fc 89 0d 60 2c 02 00 eb a1 48 c7 c7 08 42 2b a0 31 c0 e8 > 3a 40 c7 e1 <0f> 0b 48 c7 c7 e0 41 2b a0 31 c0 e8 2a 40 c7 e1 0f 0b 66 > 0f 1f > [114349.635745] RIP [] osi_get_fh+0xc8/0xe0 [libafs] > [114349.635745] RSP > [114351.110672] ---[ end trace b1f29ac8defa1347 ]--- > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > --001a11c2eea0053a2004e7d5c7df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Nicolas,

Just as an FYI we are runni= ng our AFS cell (atlas.umich.edu) ov= er ZFS =A0v0.6.2 on Scientific Linux 6.4 64-bit without a problem.

Shawn

On Wed, Oct 2, 2013 at 3:48 PM, nicolas prochazka <prochazka.nicolas@gmail.com> wrote:

Hello,
For your intention,
In Faq, we can read :

The OpenAFS cache manager will detect an unsupported filesystem and
refuse to start.

The following file systems have been reported to work for the AFS client ca= che:

ext2
ext3
hfs (HP-UX)
xfs (at least on IRIX 6.5)
ufs (Solaris, ?Tru64Unix)

But if I configure cache on zfs on linux ( zfsonlinux.org) ,
i got kernel panic :

[114328.841466]= Starting AFS cache scan...
[114349.618208]= openafs: Inconsistent file handles within cache
[114349.618238]= ------------[ cut here ]------------
[114349.618926]= kernel BUG at
/tmp/openafs/src/libafs/MODLOAD-3.11.2-MP/osi_file.c:129!
[114349.620004]= invalid opcode: 0000 [#1] SMP
[114349.620004]= Modules linked in: libafs(PO) zfs(PO) zunicode(PO)
zavl(PO) zcommon(PO) znvpair(PO) spl(O) kvm_intel kvm
[114349.620004]= CPU: 0 PID: 32590 Comm: afsd Tainted: P =A0 =A0 =A0 =A0 =A0 O 3.11.2 #1 [114349.620004] Hardware name: NEC Express5800/120Rj-2
[N8100-1407E]/MS-9192-01S, BIOS 1.0.4S31 03/05/2010
[114349.620004] task: ffff88076e5f2000 ti: ffff880559c6c000 task.ti:
ffff880559c6c000
[114349.620004] RIP: 0010:[<ffffffffa02971e8>] =A0[<ffffffffa02971= e8>]
osi_get_fh+0xc8/0xe0 [libafs]
[114349.620004] RSP: 0018:ffff880559c6dc38 =A0EFLAGS: 00010296
[114349.620004] RAX: 000000000000002f RBX: 0000000000000007 RCX:
0000000000000000
[114349.620004] RDX: ffff88082fc0fa88 RSI: ffff88082fc0e178 RDI:
0000000000000246
[114349.620004] RBP: ffff880559c6dc48 R08: 0000000000000400 R09:
ffffffff82716488
[114349.635745] R10: 000000000000041c R11: 000000000000041b R12:
0000000000000000
[114349.635745] R13: 000000000062dd80 R14: ffff88077ad03800 R15:
0000000000000001
[114349.635745] FS: =A000007f2afb49c700(0000) GS:ffff88082fc00000(0000)
knlGS:0000000000000000
[114349.635745] CS: =A00010 DS: 0000 ES: 0000 CR0: 0000000080050033
[114349.635745] CR2: 000000007398600c CR3: 00000005583ef000 CR4:
00000000000027e0
[114349.635745] Stack:
[114349.635745] =A0ffff88077ad03800 0000000300000001 ffff880559c6dc68
ffffffffa02975c0
[114349.635745] =A0ffff880559c6dc88 ffff88051fdb6900 ffff880559c6dca8
ffffffffa025ddfa
[114349.635745] =A0ffff880559c6dc98 ffffffff81064565 ffff880559c6dca8
ffffffff81f182cd
[114349.635745] Call Trace:
[114349.635745] =A0[<ffffffffa02975c0>] osi_InitCacheInfo+0x40/0x80 [= libafs]
[114349.635745] =A0[<ffffffffa025ddfa>] afs_InitCacheInfo+0x2a/0x130 = [libafs]
[114349.635745] =A0[<ffffffff81064565>] ? ns_capable+0x35/0x60
[114349.635745] =A0[<ffffffff81f182cd>] ? mutex_lock+0x1d/0x50
[114349.635745] =A0[<ffffffffa02a28de>] afs_syscall_call+0x105e/0x1bf= 0 [libafs]
[114349.635745] =A0[<ffffffff8117a2ab>] ? do_last.isra.57+0x11b/0xc60=
[114349.635745] =A0[<ffffffff811775a8>] ? inode_permission+0x18/0x50<= br> [114349.635745] =A0[<ffffffff81177a8d>] ? link_path_walk+0x23d/0x8e0<= br> [114349.635745] =A0[<ffffffff8108538a>] ? lg_local_unlock+0x1a/0x20 [114349.635745] =A0[<ffffffff81189e79>] ? mntput_no_expire+0x49/0x160=
[114349.635745] =A0[<ffffffffa022a9ec>] afs_syscall+0x17c/0x650 [liba= fs]
[114349.635745] =A0[<ffffffffa02421f9>] afs_unlocked_ioctl+0x69/0xd0 = [libafs]
[114349.635745] =A0[<ffffffff811cf86f>] proc_reg_unlocked_ioctl+0x3f/= 0x70
[114349.635745] =A0[<ffffffff8117d5fb>] do_vfs_ioctl+0x8b/0x4f0
[114349.635745] =A0[<ffffffff81177376>] ? final_putname+0x26/0x50
[114349.635745] =A0[<ffffffff8117dab0>] SyS_ioctl+0x50/0x90
[114349.635745] =A0[<ffffffff81f1bb99>] system_call_fastpath+0x16/0x1= b
[114349.635745] Code: 8b 0d 75 2c 02 00 89 05 73 2c 02 00 89 c2 85 c9
79 ac 8b 4d fc 89 0d 60 2c 02 00 eb a1 48 c7 c7 08 42 2b a0 31 c0 e8
3a 40 c7 e1 <0f> 0b 48 c7 c7 e0 41 2b a0 31 c0 e8 2a 40 c7 e1 0f 0b 6= 6
0f 1f
[114349.635745] RIP =A0[<ffffffffa02971e8>] osi_get_fh+0xc8/0xe0 [lib= afs]
[114349.635745] =A0RSP <ffff880559c6dc38>
[114351.110672] ---[ end trace b1f29ac8defa1347 ]---
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info

--001a11c2eea0053a2004e7d5c7df-- From Arne.Wiebalck@cern.ch Thu Oct 3 14:07:59 2013 From: Arne.Wiebalck@cern.ch (Arne Wiebalck) Date: Thu, 3 Oct 2013 13:07:59 +0000 Subject: [OpenAFS] [ OpenAFS - Cache FileSystem ] In-Reply-To: References: Message-ID: <92F612DDE3CDEA439793C598481F5702CDBE1A96@CERNXCHG01.cern.ch> --Apple-Mail=_9F9AE67A-37EE-4BC2-917B-2B3EF77CF3B5 Content-Type: multipart/alternative; boundary="Apple-Mail=_7A24A293-C1A7-48B8-A452-23F89DBA7FED" --Apple-Mail=_7A24A293-C1A7-48B8-A452-23F89DBA7FED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Shawn, =46rom what I understood, you use ZFS on the servers, not the clients, = right? Cheers, Arne On Oct 3, 2013, at 3:00 PM, Shawn McKee wrote: > Hi Nicolas, >=20 > Just as an FYI we are running our AFS cell (atlas.umich.edu) over ZFS = v0.6.2 on Scientific Linux 6.4 64-bit without a problem. >=20 > Shawn >=20 >=20 > On Wed, Oct 2, 2013 at 3:48 PM, nicolas prochazka = wrote: > Hello, > For your intention, > In Faq, we can read : >=20 > The OpenAFS cache manager will detect an unsupported filesystem and > refuse to start. >=20 > The following file systems have been reported to work for the AFS = client cache: >=20 > ext2 > ext3 > hfs (HP-UX) > xfs (at least on IRIX 6.5) > ufs (Solaris, ?Tru64Unix) >=20 >=20 > But if I configure cache on zfs on linux ( zfsonlinux.org) , > i got kernel panic : >=20 > [114328.841466] Starting AFS cache scan... > [114349.618208] openafs: Inconsistent file handles within cache > [114349.618238] ------------[ cut here ]------------ > [114349.618926] kernel BUG at > /tmp/openafs/src/libafs/MODLOAD-3.11.2-MP/osi_file.c:129! > [114349.620004] invalid opcode: 0000 [#1] SMP > [114349.620004] Modules linked in: libafs(PO) zfs(PO) zunicode(PO) > zavl(PO) zcommon(PO) znvpair(PO) spl(O) kvm_intel kvm > [114349.620004] CPU: 0 PID: 32590 Comm: afsd Tainted: P O = 3.11.2 #1 > [114349.620004] Hardware name: NEC Express5800/120Rj-2 > [N8100-1407E]/MS-9192-01S, BIOS 1.0.4S31 03/05/2010 > [114349.620004] task: ffff88076e5f2000 ti: ffff880559c6c000 task.ti: > ffff880559c6c000 > [114349.620004] RIP: 0010:[] [] > osi_get_fh+0xc8/0xe0 [libafs] > [114349.620004] RSP: 0018:ffff880559c6dc38 EFLAGS: 00010296 > [114349.620004] RAX: 000000000000002f RBX: 0000000000000007 RCX: > 0000000000000000 > [114349.620004] RDX: ffff88082fc0fa88 RSI: ffff88082fc0e178 RDI: > 0000000000000246 > [114349.620004] RBP: ffff880559c6dc48 R08: 0000000000000400 R09: > ffffffff82716488 > [114349.635745] R10: 000000000000041c R11: 000000000000041b R12: > 0000000000000000 > [114349.635745] R13: 000000000062dd80 R14: ffff88077ad03800 R15: > 0000000000000001 > [114349.635745] FS: 00007f2afb49c700(0000) GS:ffff88082fc00000(0000) > knlGS:0000000000000000 > [114349.635745] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [114349.635745] CR2: 000000007398600c CR3: 00000005583ef000 CR4: > 00000000000027e0 > [114349.635745] Stack: > [114349.635745] ffff88077ad03800 0000000300000001 ffff880559c6dc68 > ffffffffa02975c0 > [114349.635745] ffff880559c6dc88 ffff88051fdb6900 ffff880559c6dca8 > ffffffffa025ddfa > [114349.635745] ffff880559c6dc98 ffffffff81064565 ffff880559c6dca8 > ffffffff81f182cd > [114349.635745] Call Trace: > [114349.635745] [] osi_InitCacheInfo+0x40/0x80 = [libafs] > [114349.635745] [] afs_InitCacheInfo+0x2a/0x130 = [libafs] > [114349.635745] [] ? ns_capable+0x35/0x60 > [114349.635745] [] ? mutex_lock+0x1d/0x50 > [114349.635745] [] afs_syscall_call+0x105e/0x1bf0 = [libafs] > [114349.635745] [] ? do_last.isra.57+0x11b/0xc60 > [114349.635745] [] ? inode_permission+0x18/0x50 > [114349.635745] [] ? link_path_walk+0x23d/0x8e0 > [114349.635745] [] ? lg_local_unlock+0x1a/0x20 > [114349.635745] [] ? mntput_no_expire+0x49/0x160 > [114349.635745] [] afs_syscall+0x17c/0x650 [libafs] > [114349.635745] [] afs_unlocked_ioctl+0x69/0xd0 = [libafs] > [114349.635745] [] = proc_reg_unlocked_ioctl+0x3f/0x70 > [114349.635745] [] do_vfs_ioctl+0x8b/0x4f0 > [114349.635745] [] ? final_putname+0x26/0x50 > [114349.635745] [] SyS_ioctl+0x50/0x90 > [114349.635745] [] system_call_fastpath+0x16/0x1b > [114349.635745] Code: 8b 0d 75 2c 02 00 89 05 73 2c 02 00 89 c2 85 c9 > 79 ac 8b 4d fc 89 0d 60 2c 02 00 eb a1 48 c7 c7 08 42 2b a0 31 c0 e8 > 3a 40 c7 e1 <0f> 0b 48 c7 c7 e0 41 2b a0 31 c0 e8 2a 40 c7 e1 0f 0b 66 > 0f 1f > [114349.635745] RIP [] osi_get_fh+0xc8/0xe0 = [libafs] > [114349.635745] RSP > [114351.110672] ---[ end trace b1f29ac8defa1347 ]--- > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info >=20 --Apple-Mail=_7A24A293-C1A7-48B8-A452-23F89DBA7FED Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Hi Shawn,

From what I understood, you use ZFS on the servers, not the clients, right?

Cheers,

Arne

On Oct 3, 2013, at 3:00 PM, Shawn McKee <smckee@umich.edu>

wrote:

Hi Nicolas,

Just as an FYI we are running our AFS cell (atlas.umich.edu) over ZFS v0.6.2 on Scientific Linux 6.4 64-bit without a problem.

Shawn

On Wed, Oct 2, 2013 at 3:48 PM, nicolas prochazka <prochazka.nicolas@gmail.com> wrote:

Hello,
For your intention,
In Faq, we can read :

The OpenAFS cache manager will detect an unsupported filesystem and
refuse to start.

The following file systems have been reported to work for the AFS client cache:

ext2
ext3
hfs (HP-UX)
xfs (at least on IRIX 6.5)
ufs (Solaris, ?Tru64Unix)

But if I configure cache on zfs on linux ( zfsonlinux.org) ,
i got kernel panic :

[114328.841466] Starting AFS cache scan...
[114349.618208] openafs: Inconsistent file handles within cache
[114349.618238] ------------[ cut here ]------------
[114349.618926] kernel BUG at
/tmp/openafs/src/libafs/MODLOAD-3.11.2-MP/osi_file.c:129!
[114349.620004] invalid opcode: 0000 [#1] SMP
[114349.620004] Modules linked in: libafs(PO) zfs(PO) zunicode(PO)
zavl(PO) zcommon(PO) znvpair(PO) spl(O) kvm_intel kvm
[114349.620004] CPU: 0 PID: 32590 Comm: afsd Tainted: P O 3.11.2 #1
[114349.620004] Hardware name: NEC Express5800/120Rj-2
[N8100-1407E]/MS-9192-01S, BIOS 1.0.4S31 03/05/2010
[114349.620004] task: ffff88076e5f2000 ti: ffff880559c6c000 task.ti:
ffff880559c6c000
[114349.620004] RIP: 0010:[<ffffffffa02971e8>] [<ffffffffa02971e8>]
osi_get_fh+0xc8/0xe0 [libafs]
[114349.620004] RSP: 0018:ffff880559c6dc38 EFLAGS: 00010296
[114349.620004] RAX: 000000000000002f RBX: 0000000000000007 RCX:
0000000000000000
[114349.620004] RDX: ffff88082fc0fa88 RSI: ffff88082fc0e178 RDI:
0000000000000246
[114349.620004] RBP: ffff880559c6dc48 R08: 0000000000000400 R09:
ffffffff82716488
[114349.635745] R10: 000000000000041c R11: 000000000000041b R12:
0000000000000000
[114349.635745] R13: 000000000062dd80 R14: ffff88077ad03800 R15:
0000000000000001
[114349.635745] FS: 00007f2afb49c700(0000) GS:ffff88082fc00000(0000)
knlGS:0000000000000000
[114349.635745] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[114349.635745] CR2: 000000007398600c CR3: 00000005583ef000 CR4:
00000000000027e0
[114349.635745] Stack:
[114349.635745] ffff88077ad03800 0000000300000001 ffff880559c6dc68
ffffffffa02975c0
[114349.635745] ffff880559c6dc88 ffff88051fdb6900 ffff880559c6dca8
ffffffffa025ddfa
[114349.635745] ffff880559c6dc98 ffffffff81064565 ffff880559c6dca8
ffffffff81f182cd
[114349.635745] Call Trace:
[114349.635745] [<ffffffffa02975c0>] osi_InitCacheInfo+0x40/0x80 [libafs]
[114349.635745] [<ffffffffa025ddfa>] afs_InitCacheInfo+0x2a/0x130 [libafs]
[114349.635745] [<ffffffff81064565>] ? ns_capable+0x35/0x60
[114349.635745] [<ffffffff81f182cd>] ? mutex_lock+0x1d/0x50
[114349.635745] [<ffffffffa02a28de>] afs_syscall_call+0x105e/0x1bf0 [libafs]
[114349.635745] [<ffffffff8117a2ab>] ? do_last.isra.57+0x11b/0xc60
[114349.635745] [<ffffffff811775a8>] ? inode_permission+0x18/0x50
[114349.635745] [<ffffffff81177a8d>] ? link_path_walk+0x23d/0x8e0
[114349.635745] [<ffffffff8108538a>] ? lg_local_unlock+0x1a/0x20
[114349.635745] [<ffffffff81189e79>] ? mntput_no_expire+0x49/0x160
[114349.635745] [<ffffffffa022a9ec>] afs_syscall+0x17c/0x650 [libafs]
[114349.635745] [<ffffffffa02421f9>] afs_unlocked_ioctl+0x69/0xd0 [libafs]
[114349.635745] [<ffffffff811cf86f>] proc_reg_unlocked_ioctl+0x3f/0x70
[114349.635745] [<ffffffff8117d5fb>] do_vfs_ioctl+0x8b/0x4f0
[114349.635745] [<ffffffff81177376>] ? final_putname+0x26/0x50
[114349.635745] [<ffffffff8117dab0>] SyS_ioctl+0x50/0x90
[114349.635745] [<ffffffff81f1bb99>] system_call_fastpath+0x16/0x1b
[114349.635745] Code: 8b 0d 75 2c 02 00 89 05 73 2c 02 00 89 c2 85 c9
79 ac 8b 4d fc 89 0d 60 2c 02 00 eb a1 48 c7 c7 08 42 2b a0 31 c0 e8
3a 40 c7 e1 <0f> 0b 48 c7 c7 e0 41 2b a0 31 c0 e8 2a 40 c7 e1 0f 0b 66
0f 1f
[114349.635745] RIP [<ffffffffa02971e8>] osi_get_fh+0xc8/0xe0 [libafs]
[114349.635745] RSP <ffff880559c6dc38>
[114351.110672] ---[ end trace b1f29ac8defa1347 ]---
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

--Apple-Mail=_7A24A293-C1A7-48B8-A452-23F89DBA7FED-- --Apple-Mail=_9F9AE67A-37EE-4BC2-917B-2B3EF77CF3B5 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINuDCCBi4w ggUWoAMCAQICCmEPqkwAAAAAAAMwDQYJKoZIhvcNAQEFBQAwQTESMBAGCgmSJomT8ixkARkWAmNo MRQwEgYKCZImiZPyLGQBGRYEY2VybjEVMBMGA1UEAxMMQ0VSTiBSb290IENBMB4XDTA2MTAwMzA5 MzYxM1oXDTE2MTAwMzA5NDYxM1owWTESMBAGCgmSJomT8ixkARkWAmNoMRQwEgYKCZImiZPyLGQB GRYEY2VybjEtMCsGA1UEAxMkQ0VSTiBUcnVzdGVkIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwdFGqthhWlgUOSZ6C6hReNEVGzbjf2IQgxo7 /rOfOQHZH3krQPQ37fqFroEr46PrruymZ/U+QAzmESZQ4Z+nCfBhm7cEi0TIhihHd4cEPaPxawGR T9Ck7BBk9za8TUljF6c/JodnIcmIrpbazEbSAS1KEXwETHDsTrQ7lJ+6SzDP4/oOwrHrgJx+tKsm gOsFSbBEK4OYx1UYQpYS9OJQk2Sc0q4a/SCSu+xbN8ppmgV3WFytN8NW20n3NpCCWYPzo9rXmPRA 7a/c6mf+RV5gPCnUqeW6KUvix5kz9+X8/4SQV/fU12OPdRvtkqcC+PpiePK7bjMLQJEYwvchJrSz AwIDAQABo4IDDjCCAwowDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUmMyS0EYwNoyw7ZgNclGp R0zdviEwCwYDVR0PBAQDAgGGMBAGCSsGAQQBgjcVAQQDAgECMCMGCSsGAQQBgjcVAgQWBBT/Rljl vgfrVK8GmAaYe+TbiXbJ7DBRBgNVHSAESjBIMEYGCisGAQQBYAoCAQEwODA2BggrBgEFBQcCARYq aHR0cDovL2NhLmNlcm4uY2gvY2EvY3JsL3BvbGljeS9jcC1jcHMucGRmMBkGCSsGAQQBgjcUAgQM HgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFJgK9+w+7FnWHa2ZvLUBPt7spudQMIH8BgNVHR8EgfQw gfEwge6ggeuggeiGLWh0dHA6Ly9jYS5jZXJuLmNoL2NhL2NybC9DRVJOJTIwUm9vdCUyMENBLmNy bIaBtmxkYXA6Ly8vQ049Q0VSTiUyMFJvb3QlMjBDQSxDTj1jZXJucm9vdGNhLENOPUNEUCxDTj1Q dWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNl cm4sREM9Y2g/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERp c3RyaWJ1dGlvblBvaW50MIIBBAYIKwYBBQUHAQEEgfcwgfQwRAYIKwYBBQUHMAKGOGh0dHA6Ly9j YS5jZXJuLmNoL2NhL2NybC9jZXJucm9vdGNhX0NFUk4lMjBSb290JTIwQ0EuY3J0MIGrBggrBgEF BQcwAoaBnmxkYXA6Ly8vQ049Q0VSTiUyMFJvb3QlMjBDQSxDTj1BSUEsQ049UHVibGljJTIwS2V5 JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1jZXJuLERDPWNoP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqG SIb3DQEBBQUAA4IBAQAfEzvOeYohKndmJqnVdiCqZ38tSBxOOPsKUHW4UY1jBfYMXbnZ9keFQFlK /g5X4aZPNBEHXw0eKpQVsMhEPWQrvx8T/f7GwtU+JNQhkgK9tnezmHxYzWgEC9MXZhfYzFSwMIF6 kSKllmUTnN35uF1EnT8+64daje+yEVcpmM34p8Fw125/WpKnRmwNp0YkUk6uMti6Y6vOTHttzIN5 P6elGoat8sadMqrVnaMNzG8hGUvSkYivYBs7msAPuwmXgLvIkXWPW+MDFs+x5Kzx75ZHv3c2WoKg UxL5KZH9QqiR7t8P6YBfYW6SpzyGRi4QHN/iOLhXZ06R6aPljLEOn41JMIIHgjCCBmqgAwIBAgIK HYLrgQACAAHOszANBgkqhkiG9w0BAQUFADBZMRIwEAYKCZImiZPyLGQBGRYCY2gxFDASBgoJkiaJ k/IsZAEZFgRjZXJuMS0wKwYDVQQDEyRDRVJOIFRydXN0ZWQgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkwHhcNMTMwMzI2MDkxNjM1WhcNMTQwMzI2MDkxNjM1WjCBjjESMBAGCgmSJomT8ixkARkWAmNo MRQwEgYKCZImiZPyLGQBGRYEY2VybjEWMBQGA1UECxMNT3JnYW5pYyBVbml0czEOMAwGA1UECxMF VXNlcnMxETAPBgNVBAMTCHdpZWJhbGNrMQ8wDQYDVQQDEwY1NTg1MTAxFjAUBgNVBAMTDUFybmUg V2llYmFsY2swggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKWiuJsxwe2ZAkHn+FKzTT VBNe7lhl2PmTjPmZsedrVI0gZkUpjlb6x21avo3S+kacxPpVdNVmidE1k7Dmn+MLLwli8Ha+ePqN e2kD33K01bjf8G1l5KquZwMsJKB2gSwSs1JK5uq3qcB5b1mrzPVOqOqNPUMg1NUkEjYql4ooG5Cj GfVwlAhRarBssM07JtnToszp/fiCqttCR4pAAjURvQKV3T+Epiexwgzkv57mLAXe3vNf8giDigJP zvNc+3pGqA8faVOGSqOo+9m6NheYPH4pcYcnhgA177HRfHxJ9fqzEahLNzXjoa9vtW8cpbSxyzY1 wbOCvQW1hz/uCP/5AgMBAAGjggQUMIIEEDAdBgNVHQ4EFgQUFIvKPnfKzu1UVQjsxgpwQPtpkwAw HwYDVR0jBBgwFoAUmMyS0EYwNoyw7ZgNclGpR0zdviEwggEyBgNVHR8EggEpMIIBJTCCASGgggEd oIIBGYZHaHR0cDovL2NhLmNlcm4uY2gvY2EvY3JsL0NFUk4lMjBUcnVzdGVkJTIwQ2VydGlmaWNh dGlvbiUyMEF1dGhvcml0eS5jcmyGgc1sZGFwOi8vL0NOPUNFUk4lMjBUcnVzdGVkJTIwQ2VydGlm aWNhdGlvbiUyMEF1dGhvcml0eSxDTj1DRVJOUEtJLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBT ZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNlcm4sREM9Y2g/Y2VydGlm aWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50 MIIBLwYIKwYBBQUHAQEEggEhMIIBHTCBxQYIKwYBBQUHMAKGgbhsZGFwOi8vL0NOPUNFUk4lMjBU cnVzdGVkJTIwQ2VydGlmaWNhdGlvbiUyMEF1dGhvcml0eSxDTj1BSUEsQ049UHVibGljJTIwS2V5 JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1jZXJuLERDPWNoP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MFMGCCsG AQUFBzAChkdodHRwOi8vY2EuY2Vybi5jaC9jYS9jcmwvQ0VSTiUyMFRydXN0ZWQlMjBDZXJ0aWZp Y2F0aW9uJTIwQXV0aG9yaXR5LmNydDAOBgNVHQ8BAf8EBAMCBaAwPQYJKwYBBAGCNxUHBDAwLgYm KwYBBAGCNxUIg73QCYLtjQ2G7Ysrgd71N4WA0GIehb+6A4TEzEwCAWQCAQowKQYDVR0lBCIwIAYI KwYBBQUHAwIGCCsGAQUFBwMEBgorBgEEAYI3CgMEMCUGA1UdIAQeMBwwDAYKKwYBBAFgCgIBAjAM BgoqhkiG90wFAgIBMDUGCSsGAQQBgjcVCgQoMCYwCgYIKwYBBQUHAwIwCgYIKwYBBQUHAwQwDAYK KwYBBAGCNwoDBDBHBgNVHREEQDA+oCUGCisGAQQBgjcUAgOgFwwVYXJuZS53aWViYWxja0BjZXJu LmNogRVBcm5lLldpZWJhbGNrQGNlcm4uY2gwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgIC AIAwDgYIKoZIhvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4IB AQBPiPoalqg44BSHOfc5XKMLl8dbU2ixH84cWFWmv8WrkM1oTVOopGUi9dO2qiN3PbzgkW3h4yB6 hEvTn7CVCfuzPXjEb9dQEJEmVheW8xA96GYWYWdXqdNHWtPMJB4tFh0skOMo35DwavZlrE30LLR+ BK8faePfnQ6PgPrdBESQaU4ZemLS5Q/eKfz2d4kSt5+70rj8ypD7pmMdUu/n1TFxuG3UNCFSMs6G SUV0/PBjyV1O8jGtVbE9vNZE+NTuzWiYgI5Z6Pl6cHefI6miSn++PDjHzfaIPi0san0KMOXLqvA8 ZfjtAb2QMEvvKziTdg9Q4Y7wHCdi7aqKWmTbwyqUMYIC4TCCAt0CAQEwZzBZMRIwEAYKCZImiZPy LGQBGRYCY2gxFDASBgoJkiaJk/IsZAEZFgRjZXJuMS0wKwYDVQQDEyRDRVJOIFRydXN0ZWQgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkCCh2C64EAAgABzrMwCQYFKw4DAhoFAKCCAU8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMDAzMTMwOTA3WjAjBgkqhkiG9w0B CQQxFgQUyFH/4Rj7L9AP/+KfCiAwNMnEZ8UwdgYJKwYBBAGCNxAEMWkwZzBZMRIwEAYKCZImiZPy LGQBGRYCY2gxFDASBgoJkiaJk/IsZAEZFgRjZXJuMS0wKwYDVQQDEyRDRVJOIFRydXN0ZWQgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkCCh2C64EAAgABzrMweAYLKoZIhvcNAQkQAgsxaaBnMFkxEjAQ BgoJkiaJk/IsZAEZFgJjaDEUMBIGCgmSJomT8ixkARkWBGNlcm4xLTArBgNVBAMTJENFUk4gVHJ1 c3RlZCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIKHYLrgQACAAHOszANBgkqhkiG9w0BAQEFAASC AQCWBPJaZc3F6qklm3rE+ijtgCHiU7I1F414SEw1lL6N+ivAyKNXPJvfCXHeIz+hnc+Jz841EKP2 b2e+yeNZV4TtOPQ/MfWNLSJseRjjSP2eLAV8ZpYm+nN9ukUpbD8MouaiInxSOIGFbUeQJMJ7eVf/ M0k5NksP69xgSmlfRaP7ErZobgzMbbQhyNeAdbx/n1XqyAR1aguGFI07aNEphVV8+75tS2vACojv peSTUKv1Lpdk5IwOdP4kTrf0DnKfMLTdQylp/o7SoCF5sh9pGblptf7j+QQ14dREDMTxcdMcNkai 7QTIX7MMB2TUZpNsHmf/Km5iMxMLFKFSJviZjmLZAAAAAAAA --Apple-Mail=_9F9AE67A-37EE-4BC2-917B-2B3EF77CF3B5-- From smckee@umich.edu Thu Oct 3 14:10:26 2013 From: smckee@umich.edu (Shawn McKee) Date: Thu, 3 Oct 2013 09:10:26 -0400 Subject: [OpenAFS] [ OpenAFS - Cache FileSystem ] In-Reply-To: <92F612DDE3CDEA439793C598481F5702CDBE1A96@CERNXCHG01.cern.ch> References: <92F612DDE3CDEA439793C598481F5702CDBE1A96@CERNXCHG01.cern.ch> Message-ID: --047d7b6da1cad0341804e7d5e817 Content-Type: text/plain; charset=ISO-8859-1 Hi Arne, Yes, sorry for the confusion. I missed the main word in the thread of "cache"! Our clients are primarily using ext4 so my comments don't really apply. Shawn On Thu, Oct 3, 2013 at 9:07 AM, Arne Wiebalck wrote: > Hi Shawn, > > From what I understood, you use ZFS on the servers, not the clients, right? > > Cheers, > Arne > > > On Oct 3, 2013, at 3:00 PM, Shawn McKee > wrote: > > Hi Nicolas, > > Just as an FYI we are running our AFS cell (atlas.umich.edu) over ZFS > v0.6.2 on Scientific Linux 6.4 64-bit without a problem. > > Shawn > > > On Wed, Oct 2, 2013 at 3:48 PM, nicolas prochazka < > prochazka.nicolas@gmail.com> wrote: > >> Hello, >> For your intention, >> In Faq, we can read : >> >> The OpenAFS cache manager will detect an unsupported filesystem and >> refuse to start. >> >> The following file systems have been reported to work for the AFS client >> cache: >> >> ext2 >> ext3 >> hfs (HP-UX) >> xfs (at least on IRIX 6.5) >> ufs (Solaris, ?Tru64Unix) >> >> >> But if I configure cache on zfs on linux ( zfsonlinux.org) , >> i got kernel panic : >> >> [114328.841466] Starting AFS cache scan... >> [114349.618208] openafs: Inconsistent file handles within cache >> [114349.618238] ------------[ cut here ]------------ >> [114349.618926] kernel BUG at >> /tmp/openafs/src/libafs/MODLOAD-3.11.2-MP/osi_file.c:129! >> [114349.620004] invalid opcode: 0000 [#1] SMP >> [114349.620004] Modules linked in: libafs(PO) zfs(PO) zunicode(PO) >> zavl(PO) zcommon(PO) znvpair(PO) spl(O) kvm_intel kvm >> [114349.620004] CPU: 0 PID: 32590 Comm: afsd Tainted: P O >> 3.11.2 #1 >> [114349.620004] Hardware name: NEC Express5800/120Rj-2 >> [N8100-1407E]/MS-9192-01S, BIOS 1.0.4S31 03/05/2010 >> [114349.620004] task: ffff88076e5f2000 ti: ffff880559c6c000 task.ti: >> ffff880559c6c000 >> [114349.620004] RIP: 0010:[] [] >> osi_get_fh+0xc8/0xe0 [libafs] >> [114349.620004] RSP: 0018:ffff880559c6dc38 EFLAGS: 00010296 >> [114349.620004] RAX: 000000000000002f RBX: 0000000000000007 RCX: >> 0000000000000000 >> [114349.620004] RDX: ffff88082fc0fa88 RSI: ffff88082fc0e178 RDI: >> 0000000000000246 >> [114349.620004] RBP: ffff880559c6dc48 R08: 0000000000000400 R09: >> ffffffff82716488 >> [114349.635745] R10: 000000000000041c R11: 000000000000041b R12: >> 0000000000000000 >> [114349.635745] R13: 000000000062dd80 R14: ffff88077ad03800 R15: >> 0000000000000001 >> [114349.635745] FS: 00007f2afb49c700(0000) GS:ffff88082fc00000(0000) >> knlGS:0000000000000000 >> [114349.635745] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> [114349.635745] CR2: 000000007398600c CR3: 00000005583ef000 CR4: >> 00000000000027e0 >> [114349.635745] Stack: >> [114349.635745] ffff88077ad03800 0000000300000001 ffff880559c6dc68 >> ffffffffa02975c0 >> [114349.635745] ffff880559c6dc88 ffff88051fdb6900 ffff880559c6dca8 >> ffffffffa025ddfa >> [114349.635745] ffff880559c6dc98 ffffffff81064565 ffff880559c6dca8 >> ffffffff81f182cd >> [114349.635745] Call Trace: >> [114349.635745] [] osi_InitCacheInfo+0x40/0x80 [libafs] >> [114349.635745] [] afs_InitCacheInfo+0x2a/0x130 >> [libafs] >> [114349.635745] [] ? ns_capable+0x35/0x60 >> [114349.635745] [] ? mutex_lock+0x1d/0x50 >> [114349.635745] [] afs_syscall_call+0x105e/0x1bf0 >> [libafs] >> [114349.635745] [] ? do_last.isra.57+0x11b/0xc60 >> [114349.635745] [] ? inode_permission+0x18/0x50 >> [114349.635745] [] ? link_path_walk+0x23d/0x8e0 >> [114349.635745] [] ? lg_local_unlock+0x1a/0x20 >> [114349.635745] [] ? mntput_no_expire+0x49/0x160 >> [114349.635745] [] afs_syscall+0x17c/0x650 [libafs] >> [114349.635745] [] afs_unlocked_ioctl+0x69/0xd0 >> [libafs] >> [114349.635745] [] proc_reg_unlocked_ioctl+0x3f/0x70 >> [114349.635745] [] do_vfs_ioctl+0x8b/0x4f0 >> [114349.635745] [] ? final_putname+0x26/0x50 >> [114349.635745] [] SyS_ioctl+0x50/0x90 >> [114349.635745] [] system_call_fastpath+0x16/0x1b >> [114349.635745] Code: 8b 0d 75 2c 02 00 89 05 73 2c 02 00 89 c2 85 c9 >> 79 ac 8b 4d fc 89 0d 60 2c 02 00 eb a1 48 c7 c7 08 42 2b a0 31 c0 e8 >> 3a 40 c7 e1 <0f> 0b 48 c7 c7 e0 41 2b a0 31 c0 e8 2a 40 c7 e1 0f 0b 66 >> 0f 1f >> [114349.635745] RIP [] osi_get_fh+0xc8/0xe0 [libafs] >> [114349.635745] RSP >> [114351.110672] ---[ end trace b1f29ac8defa1347 ]--- >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info >> > > > --047d7b6da1cad0341804e7d5e817 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Arne,

Yes, sorry for the confusion. = =A0 I missed the main word in the thread of "cache"!

Our clients are primarily using ext4 so my comments don't = really apply.

Shawn

On Thu, Oct 3, 2013 at 9:07 AM, Arne Wiebalck <Arne.Wiebalck@cern.ch> wrote:

Hi Shawn= ,

From what I understood, you use ZFS on the servers, no= t the clients, right?

Cheers,
=A0Arne

=
On Oct 3, 2013, at 3:00 PM, Shawn McKee <smckee@umich.edu>
=A0wrot= e:

Hi Ni= colas,

Just as an FYI we are running our AFS cell (atlas.umich.edu) over = ZFS =A0v0.6.2 on Scientific Linux 6.4 64-bit without a problem.

Shawn

On Wed, Oct 2, 2013 at 3:48 PM, nicolas prochazka <prochazka.nicolas@gmail.com> wrote:

Hello,
For your intention,
In Faq, we can read :

The OpenAFS cache manager will detect an unsupported filesystem and
refuse to start.

The following file systems have been reported to work for the AFS client ca= che:

ext2
ext3
hfs (HP-UX)
xfs (at least on IRIX 6.5)
ufs (Solaris, ?Tru64Unix)

But if I configure cache on zfs on linux ( zfsonlinux.org) ,
i got kernel panic :

[= 114328.841466] Starting AFS cache scan...
[= 114349.618208] openafs: Inconsistent file handles within cache
[= 114349.618238] ------------[ cut here ]------------
[= 114349.618926] kernel BUG at
/tmp/openafs/src/libafs/MODLOAD-3.11.2-MP/osi_file.c:129!
[= 114349.620004] invalid opcode: 0000 [#1] SMP
[= 114349.620004] Modules linked in: libafs(PO) zfs(PO) zunicode(PO)
zavl(PO) zcommon(PO) znvpair(PO) spl(O) kvm_intel kvm
[= 114349.620004] CPU: 0 PID: 32590 Comm: afsd Tainted: P =A0 =A0 =A0 =A0 = =A0 O 3.11.2 #1
[= 114349.620004] Hardware name: NEC Express5800/120Rj-2
[N8100-1407E]/MS-9192-01S, BIOS 1.0.4S31 03/05/2010
[= 114349.620004] task: ffff88076e5f2000 ti: ffff880559c6c000 task.ti:
ffff880559c6c000
[= 114349.620004] RIP: 0010:[<ffffffffa02971e8>] =A0[<ffffffffa02= 971e8>]
osi_get_fh+0xc8/0xe0 [libafs]
[= 114349.620004] RSP: 0018:ffff880559c6dc38 =A0EFLAGS: 00010296
[= 114349.620004] RAX: 000000000000002f RBX: 0000000000000007 RCX:
0000000000000000
[= 114349.620004] RDX: ffff88082fc0fa88 RSI: ffff88082fc0e178 RDI:
0000000000000246
[= 114349.620004] RBP: ffff880559c6dc48 R08: 0000000000000400 R09:
ffffffff82716488
[= 114349.635745] R10: 000000000000041c R11: 000000000000041b R12:
0000000000000000
[= 114349.635745] R13: 000000000062dd80 R14: ffff88077ad03800 R15:
0000000000000001
[= 114349.635745] FS: =A000007f2afb49c700(0000) GS:ffff88082fc00000(0000)<= br> knlGS:0000000000000000
[= 114349.635745] CS: =A00010 DS: 0000 ES: 0000 CR0: 0000000080050033
[= 114349.635745] CR2: 000000007398600c CR3: 00000005583ef000 CR4:
00000000000027e0
[114349.635745] Stack:
[114349.635745] =A0ffff88077ad03800 0000000300000001 ffff880559c6dc68
ffffffffa02975c0
[114349.635745] =A0ffff880559c6dc88 ffff88051fdb6900 ffff880559c6dca8
ffffffffa025ddfa
[114349.635745] =A0ffff880559c6dc98 ffffffff81064565 ffff880559c6dca8
ffffffff81f182cd
[114349.635745] Call Trace:
[114349.635745] =A0[<ffffffffa02975c0>] osi_InitCacheInfo+0x40/0x80 [= libafs]
[114349.635745] =A0[<ffffffffa025ddfa>] afs_InitCacheInfo+0x2a/0x130 = [libafs]
[114349.635745] =A0[<ffffffff81064565>] ? ns_capable+0x35/0x60
[114349.635745] =A0[<ffffffff81f182cd>] ? mutex_lock+0x1d/0x50
[114349.635745] =A0[<ffffffffa02a28de>] afs_syscall_call+0x105e/0x1bf= 0 [libafs]
[114349.635745] =A0[<ffffffff8117a2ab>] ? do_last.isra.57+0x11b/0xc60=
[114349.635745] =A0[<ffffffff811775a8>] ? inode_permission+0x18/0x50<= br> [114349.635745] =A0[<ffffffff81177a8d>] ? link_path_walk+0x23d/0x8e0<= br> [114349.635745] =A0[<ffffffff8108538a>] ? lg_local_unlock+0x1a/0x20 [114349.635745] =A0[<ffffffff81189e79>] ? mntput_no_expire+0x49/0x160=
[114349.635745] =A0[<ffffffffa022a9ec>] afs_syscall+0x17c/0x650 [liba= fs]
[114349.635745] =A0[<ffffffffa02421f9>] afs_unlocked_ioctl+0x69/0xd0 = [libafs]
[114349.635745] =A0[<ffffffff811cf86f>] proc_reg_unlocked_ioctl+0x3f/= 0x70
[114349.635745] =A0[<ffffffff8117d5fb>] do_vfs_ioctl+0x8b/0x4f0
[114349.635745] =A0[<ffffffff81177376>] ? final_putname+0x26/0x50
[114349.635745] =A0[<ffffffff8117dab0>] SyS_ioctl+0x50/0x90
[114349.635745] =A0[<ffffffff81f1bb99>] system_call_fastpath+0x16/0x1= b
[114349.635745] Code: 8b 0d 75 2c 02 00 89 05 73 2c 02 00 89 c2 85 c9
79 ac 8b 4d fc 89 0d 60 2c 02 00 eb a1 48 c7 c7 08 42 2b a0 31 c0 e8
3a 40 c7 e1 <0f> 0b 48 c7 c7 e0 41 2b a0 31 c0 e8 2a 40 c7 e1 0f 0b 6= 6
0f 1f
[114349.635745] RIP =A0[<ffffffffa02971e8>] osi_get_fh+0xc8/0xe0 [lib= afs]
[114349.635745] =A0RSP <ffff880559c6dc38>
[114351.110672] ---[ end trace b1f29ac8defa1347 ]---
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@= openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

--047d7b6da1cad0341804e7d5e817-- From jm130794@gmail.com Thu Oct 3 16:24:37 2013 From: jm130794@gmail.com (Jean-Marc Choulet) Date: Thu, 03 Oct 2013 17:24:37 +0200 Subject: [OpenAFS] Update squeeze openafs-fileserver to squeeze-backports Message-ID: <524D8C35.2020707@gmail.com> Hello, We want to upgrade openafs-fileserver to squeeze-backports and we get this errors : LANG=C apt-get -t squeeze-backports install openafs-client Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: bison flex Use 'apt-get autoremove' to remove them. Suggested packages: openafs-doc The following packages will be upgraded: openafs-client 1 upgraded, 0 newly installed, 0 to remove and 5 not upgraded. 1 not fully installed or removed. Need to get 0 B/3843 kB of archives. After this operation, 717 kB of additional disk space will be used. Reading changelogs... Done Preconfiguring packages ... openafs-client failed to preconfigure, with exit status 1 (Reading database ... 38192 files and directories currently installed.) Preparing to replace openafs-client 1.4.12.1+dfsg-4+squeeze2 (using .../openafs-client_1.6.1-3+deb7u1~bpo60+1_amd64.deb) ... Unpacking replacement openafs-client ... Processing triggers for man-db ... Setting up openafs-client (1.6.1-3+deb7u1~bpo60+1) ... Installing new version of config file /etc/init.d/openafs-client ... dpkg: error processing openafs-client (--configure): subprocess installed post-installation script returned error exit status 1 configured to not write apport reports Errors were encountered while processing: openafs-client E: Sub-process /usr/bin/dpkg returned an error code (1) root@fs01:~# Do you any ideas ? Thank, Jean-Marc From kaduk@MIT.EDU Thu Oct 3 16:28:04 2013 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Thu, 3 Oct 2013 11:28:04 -0400 (EDT) Subject: [OpenAFS] Update squeeze openafs-fileserver to squeeze-backports In-Reply-To: <524D8C35.2020707@gmail.com> References: <524D8C35.2020707@gmail.com> Message-ID: On Thu, 3 Oct 2013, Jean-Marc Choulet wrote: > Hello, > > We want to upgrade openafs-fileserver to squeeze-backports and we get this > errors : > > LANG=C apt-get -t squeeze-backports install openafs-client Sorry, are you upgrading the fileserver package or the client package? The subject and body disagree. -Ben Kaduk From jm130794@gmail.com Thu Oct 3 16:33:03 2013 From: jm130794@gmail.com (Jean-Marc Choulet) Date: Thu, 03 Oct 2013 17:33:03 +0200 Subject: [OpenAFS] Update squeeze openafs-fileserver to squeeze-backports In-Reply-To: References: <524D8C35.2020707@gmail.com> Message-ID: <524D8E2F.8010509@gmail.com> Le 03/10/2013 17:28, Benjamin Kaduk a �crit : > On Thu, 3 Oct 2013, Jean-Marc Choulet wrote: > >> Hello, >> >> We want to upgrade openafs-fileserver to squeeze-backports and we get >> this errors : >> >> LANG=C apt-get -t squeeze-backports install openafs-client > > Sorry, are you upgrading the fileserver package or the client package? > The subject and body disagree. > > -Ben Kaduk First, we made apt-get -t squeeze-backports install openafs-fileserver... but apt-get said it cannot install open-fileserver because openafs-client cannot be configured... From jm130794@gmail.com Thu Oct 3 16:34:46 2013 From: jm130794@gmail.com (Jean-Marc Choulet) Date: Thu, 03 Oct 2013 17:34:46 +0200 Subject: [OpenAFS] Update squeeze openafs-fileserver to squeeze-backports In-Reply-To: References: <524D8C35.2020707@gmail.com> Message-ID: <524D8E96.2070707@gmail.com> Le 03/10/2013 17:28, Benjamin Kaduk a �crit : > On Thu, 3 Oct 2013, Jean-Marc Choulet wrote: > >> Hello, >> >> We want to upgrade openafs-fileserver to squeeze-backports and we get >> this errors : >> >> LANG=C apt-get -t squeeze-backports install openafs-client > > Sorry, are you upgrading the fileserver package or the client package? > The subject and body disagree. > > -Ben Kaduk # apt-get remove openafs-client openafs-fileserver Lecture des listes de paquets... Fait Construction de l'arbre des d�pendances Lecture des informations d'�tat... Fait Le paquet openafs-client n'est pas install�, et ne peut donc �tre supprim� Le paquet openafs-fileserver n'est pas install�, et ne peut donc �tre supprim� Les paquets suivants ont �t� install�s automatiquement et ne sont plus n�cessaires : menu libmpfr4 fakeroot bison linux-kbuild-2.6.32 linux-headers-2.6.32-5-common libgomp1 gcc-4.3 gcc-4.4 cpp libgmp3c2 gcc linux-headers-2.6.32-5-amd64 dkms flex openafs-modules-dkms libc6-dev gcc-4.3-base cpp-4.3 cpp-4.4 linux-libc-dev manpages-dev libc-dev-bin binutils linux-headers-2.6-amd64 make Veuillez utiliser � apt-get autoremove � pour les supprimer. 0 mis � jour, 0 nouvellement install�s, 0 � enlever et 0 non mis � jour. root@fs01:~# LANG=C apt-get -t squeeze-backports install openafs-fileserver Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: bison flex Use 'apt-get autoremove' to remove them. The following extra packages will be installed: openafs-client Suggested packages: openafs-doc The following NEW packages will be installed: openafs-client openafs-fileserver 0 upgraded, 2 newly installed, 0 to remove and 5 not upgraded. Need to get 0 B/6904 kB of archives. After this operation, 15.3 MB of additional disk space will be used. Do you want to continue [Y/n]? Preconfiguring packages ... openafs-client failed to preconfigure, with exit status 1 Selecting previously deselected package openafs-client. (Reading database ... 37939 files and directories currently installed.) Unpacking openafs-client (from .../openafs-client_1.6.1-3+deb7u1~bpo60+1_amd64.deb) ... Selecting previously deselected package openafs-fileserver. Unpacking openafs-fileserver (from .../openafs-fileserver_1.6.1-3+deb7u1~bpo60+1_amd64.deb) ... Processing triggers for man-db ... Setting up openafs-client (1.6.1-3+deb7u1~bpo60+1) ... update-alternatives: using /usr/bin/pagsh.openafs to provide /usr/bin/pagsh (pagsh) in auto mode. dpkg: error processing openafs-client (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of openafs-fileserver: openafs-fileserver depends on openafs-client; however: Package openafs-client is not configured yet. dpkg: error processing openafs-fileserver (--configure): dependency problems - leaving unconfigured configured to not write apport reports configured to not write apport reports Errors were encountered while processing: openafs-client openafs-fileserver E: Sub-process /usr/bin/dpkg returned an error code (1) root@fs01:~# From kaduk@MIT.EDU Thu Oct 3 16:35:35 2013 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Thu, 3 Oct 2013 11:35:35 -0400 (EDT) Subject: [OpenAFS] Update squeeze openafs-fileserver to squeeze-backports In-Reply-To: <524D8E2F.8010509@gmail.com> References: <524D8C35.2020707@gmail.com> <524D8E2F.8010509@gmail.com> Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-571904656-1380814535=:16692 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 3 Oct 2013, Jean-Marc Choulet wrote: > Le 03/10/2013 17:28, Benjamin Kaduk a =E9crit : >> On Thu, 3 Oct 2013, Jean-Marc Choulet wrote: >>=20 >>> Hello, >>>=20 >>> We want to upgrade openafs-fileserver to squeeze-backports and we get t= his=20 >>> errors : >>>=20 >>> LANG=3DC apt-get -t squeeze-backports install openafs-client >>=20 >> Sorry, are you upgrading the fileserver package or the client package? T= he=20 >> subject and body disagree. >>=20 >> -Ben Kaduk > First, we made apt-get -t squeeze-backports install openafs-fileserver...= but=20 > apt-get said it cannot install open-fileserver because openafs-client can= not=20 > be configured... Did you try to install them together? apt-get -t squeeze-backports install openafs-fileserver openafs-client=20 [opeanfs-dkms] (I don't know if you're using DKMS or not). -Ben ---559023410-571904656-1380814535=:16692-- From jm130794@gmail.com Thu Oct 3 16:39:42 2013 From: jm130794@gmail.com (Jean-Marc Choulet) Date: Thu, 03 Oct 2013 17:39:42 +0200 Subject: [OpenAFS] Update squeeze openafs-fileserver to squeeze-backports In-Reply-To: References: <524D8C35.2020707@gmail.com> <524D8E2F.8010509@gmail.com> Message-ID: <524D8FBE.4050309@gmail.com> Le 03/10/2013 17:35, Benjamin Kaduk a �crit : > On Thu, 3 Oct 2013, Jean-Marc Choulet wrote: > >> Le 03/10/2013 17:28, Benjamin Kaduk a �crit : >>> On Thu, 3 Oct 2013, Jean-Marc Choulet wrote: >>> >>>> Hello, >>>> >>>> We want to upgrade openafs-fileserver to squeeze-backports and we >>>> get this errors : >>>> >>>> LANG=C apt-get -t squeeze-backports install openafs-client >>> >>> Sorry, are you upgrading the fileserver package or the client >>> package? The subject and body disagree. >>> >>> -Ben Kaduk >> First, we made apt-get -t squeeze-backports install >> openafs-fileserver... but apt-get said it cannot install >> open-fileserver because openafs-client cannot be configured... > > Did you try to install them together? > apt-get -t squeeze-backports install openafs-fileserver openafs-client > [opeanfs-dkms] (I don't know if you're using DKMS or not). > > -Ben Yes, but we always have theses errors From adeason@sinenomine.net Thu Oct 3 17:13:12 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 3 Oct 2013 11:13:12 -0500 Subject: [OpenAFS] Re: Update squeeze openafs-fileserver to squeeze-backports References: <524D8C35.2020707@gmail.com> <524D8E96.2070707@gmail.com> Message-ID: <20131003111312.ca5462df.adeason@sinenomine.net> On Thu, 03 Oct 2013 17:34:46 +0200 Jean-Marc Choulet wrote: > Setting up openafs-client (1.6.1-3+deb7u1~bpo60+1) ... > update-alternatives: using /usr/bin/pagsh.openafs to provide > /usr/bin/pagsh (pagsh) in auto mode. > dpkg: error processing openafs-client (--configure): > subprocess installed post-installation script returned error exit status 1 This is maybe more appropriate in a debian bug or a more debian-centric forum, but we can try, and Russ reads this list anyway. That doesn't seem to be telling you why the postinst script failed, and I'm not really sure of everything that it does that can fail. But I think you can get it to say what it's doing by doing something like this after it fails: Edit /var/lib/dpkg/info/openafs-client.postinst, and change the 'set -e' near the top to 'set -xe'. Then run 'dpkg --configure --pending', or maybe just try to install openafs-client again. It should print out a bunch more stuff about what commands it is running, which should give a clue as to what is actually failing. (And thanks for running with LANG=C; that is helpful.) -- Andrew Deason adeason@sinenomine.net From jm130794@gmail.com Thu Oct 3 17:28:09 2013 From: jm130794@gmail.com (Jean-Marc Choulet) Date: Thu, 03 Oct 2013 18:28:09 +0200 Subject: [OpenAFS] Re: Update squeeze openafs-fileserver to squeeze-backports In-Reply-To: <20131003111312.ca5462df.adeason@sinenomine.net> References: <524D8C35.2020707@gmail.com> <524D8E96.2070707@gmail.com> <20131003111312.ca5462df.adeason@sinenomine.net> Message-ID: <524D9B19.3020004@gmail.com> Le 03/10/2013 18:13, Andrew Deason a �crit : > On Thu, 03 Oct 2013 17:34:46 +0200 > Jean-Marc Choulet wrote: > >> Setting up openafs-client (1.6.1-3+deb7u1~bpo60+1) ... >> update-alternatives: using /usr/bin/pagsh.openafs to provide >> /usr/bin/pagsh (pagsh) in auto mode. >> dpkg: error processing openafs-client (--configure): >> subprocess installed post-installation script returned error exit status 1 > This is maybe more appropriate in a debian bug or a more debian-centric > forum, but we can try, and Russ reads this list anyway. > > That doesn't seem to be telling you why the postinst script failed, and > I'm not really sure of everything that it does that can fail. But I > think you can get it to say what it's doing by doing something like > this after it fails: > > Edit /var/lib/dpkg/info/openafs-client.postinst, and change the 'set -e' > near the top to 'set -xe'. Then run 'dpkg --configure --pending', or > maybe just try to install openafs-client again. It should print out a > bunch more stuff about what commands it is running, which should give a > clue as to what is actually failing. (And thanks for running with > LANG=C; that is helpful.) > # vi /var/lib/dpkg/info/openafs-client.postinst -> change set -e to set -xe root@fs01:~# LANG=C apt-get -t squeeze-backports install openafs-fileserver openafs-client Reading package lists... Done Building dependency tree Reading state information... Done openafs-client is already the newest version. openafs-fileserver is already the newest version. The following packages were automatically installed and are no longer required: bison flex Use 'apt-get autoremove' to remove them. 0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded. 2 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Do you want to continue [Y/n]? Setting up openafs-client (1.6.1-3+deb7u1~bpo60+1) ... + [ configure = configure ] + update-alternatives --install /usr/bin/pagsh pagsh /usr/bin/pagsh.openafs 100 --slave /usr/share/man/man1/pagsh.1.gz pagsh.1.gz /usr/share/man/man1/pagsh.openafs.1.gz + update-alternatives --install /usr/bin/klog klog /usr/bin/klog.afs 10 --slave /usr/share/man/man1/klog.1.gz klog.1.gz /usr/share/man/man1/klog.afs.1.gz + test -d /afs + . /usr/share/debconf/confmodule + [ ! ] + PERL_DL_NONLAZY=1 + export PERL_DL_NONLAZY + [ ] + exec /usr/share/debconf/frontend configure dpkg: error processing openafs-client (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of openafs-fileserver: openafs-fileserver depends on openafs-client; however: Package openafs-client is not configured yet. dpkg: error processing openafs-fileserver (--configure): dependency problems - leaving unconfigured configured to not write apport reports configured to not write apport reports Errors were encountered while processing: openafs-client openafs-fileserver E: Sub-process /usr/bin/dpkg returned an error code (1) root@fs01:~# From rra@stanford.edu Thu Oct 3 17:28:31 2013 From: rra@stanford.edu (Russ Allbery) Date: Thu, 03 Oct 2013 09:28:31 -0700 Subject: [OpenAFS] Re: Update squeeze openafs-fileserver to squeeze-backports In-Reply-To: <20131003111312.ca5462df.adeason@sinenomine.net> (Andrew Deason's message of "Thu, 3 Oct 2013 11:13:12 -0500") References: <524D8C35.2020707@gmail.com> <524D8E96.2070707@gmail.com> <20131003111312.ca5462df.adeason@sinenomine.net> Message-ID: <87siwipbdc.fsf@windlord.stanford.edu> Andrew Deason writes: > Jean-Marc Choulet wrote: >> Setting up openafs-client (1.6.1-3+deb7u1~bpo60+1) ... >> update-alternatives: using /usr/bin/pagsh.openafs to provide >> /usr/bin/pagsh (pagsh) in auto mode. >> dpkg: error processing openafs-client (--configure): >> subprocess installed post-installation script returned error exit status 1 > This is maybe more appropriate in a debian bug or a more debian-centric > forum, but we can try, and Russ reads this list anyway. > That doesn't seem to be telling you why the postinst script failed, and > I'm not really sure of everything that it does that can fail. But I > think you can get it to say what it's doing by doing something like this > after it fails: > Edit /var/lib/dpkg/info/openafs-client.postinst, and change the 'set -e' > near the top to 'set -xe'. Then run 'dpkg --configure --pending', or > maybe just try to install openafs-client again. It should print out a > bunch more stuff about what commands it is running, which should give a > clue as to what is actually failing. (And thanks for running with > LANG=C; that is helpful.) This may or may not work the way that you want because of how debconf works, but yes, that's what I'd suggest as well. I suspect the problem is with setting up alternatives for klog, since that's the next line immediately after setting up alternatives for pagsh. Therefore, the output of: ls -l /usr/bin/klog /usr/share/man/man1/klog.1.gz \ /etc/alternatives/klog /etc/alternatives/klog.1.gz might be useful. In particular, if you have an actual binary instead of a symlink installed as /usr/bin/klog, bad things will happen (although I would have expected some sort of error message). -- Russ Allbery (rra@stanford.edu) From jm130794@gmail.com Thu Oct 3 17:40:05 2013 From: jm130794@gmail.com (Jean-Marc Choulet) Date: Thu, 03 Oct 2013 18:40:05 +0200 Subject: [OpenAFS] Re: Update squeeze openafs-fileserver to squeeze-backports In-Reply-To: <87siwipbdc.fsf@windlord.stanford.edu> References: <524D8C35.2020707@gmail.com> <524D8E96.2070707@gmail.com> <20131003111312.ca5462df.adeason@sinenomine.net> <87siwipbdc.fsf@windlord.stanford.edu> Message-ID: <524D9DE5.6010004@gmail.com> Le 03/10/2013 18:28, Russ Allbery a �crit : > ls -l /usr/bin/klog /usr/share/man/man1/klog.1.gz \ > /etc/alternatives/klog /etc/alternatives/klog.1.gz root@fs01:~# ls -l /usr/bin/klog /usr/share/man/man1/klog.1.gz /etc/alternatives/klog /etc/alternatives/klog.1.gz lrwxrwxrwx 1 root root 18 2 oct. 07:24 /etc/alternatives/klog -> /usr/bin/klog.krb5 lrwxrwxrwx 1 root root 34 2 oct. 07:24 /etc/alternatives/klog.1.gz -> /usr/share/man/man1/klog.krb5.1.gz lrwxrwxrwx 1 root root 22 2 oct. 07:24 /usr/bin/klog -> /etc/alternatives/klog lrwxrwxrwx 1 root root 27 2 oct. 07:24 /usr/share/man/man1/klog.1.gz -> /etc/alternatives/klog.1.gz root@fs01:~# From prochazka.nicolas@gmail.com Thu Oct 3 18:34:27 2013 From: prochazka.nicolas@gmail.com (nicolas prochazka) Date: Thu, 3 Oct 2013 19:34:27 +0200 Subject: [OpenAFS] [ Openafs : cache on zfs ] Message-ID: Hello again , after some tests to use zfs as afs cache, linux kernel tells : BUG : soft lockup - CPU0 stuck for 23s ! [ afs_cachetrim:2908] Any ideas are welcome, Regards, Nicolas Prochazka From jm130794@gmail.com Thu Oct 3 18:45:49 2013 From: jm130794@gmail.com (Jean-Marc Choulet) Date: Thu, 03 Oct 2013 19:45:49 +0200 Subject: [OpenAFS] Re: Update squeeze openafs-fileserver to squeeze-backports In-Reply-To: <87siwipbdc.fsf@windlord.stanford.edu> References: <524D8C35.2020707@gmail.com> <524D8E96.2070707@gmail.com> <20131003111312.ca5462df.adeason@sinenomine.net> <87siwipbdc.fsf@windlord.stanford.edu> Message-ID: <524DAD4D.8090503@gmail.com> Le 03/10/2013 18:28, Russ Allbery a �crit : > Andrew Deason writes: >> Jean-Marc Choulet wrote: >>> Setting up openafs-client (1.6.1-3+deb7u1~bpo60+1) ... >>> update-alternatives: using /usr/bin/pagsh.openafs to provide >>> /usr/bin/pagsh (pagsh) in auto mode. >>> dpkg: error processing openafs-client (--configure): >>> subprocess installed post-installation script returned error exit status 1 >> This is maybe more appropriate in a debian bug or a more debian-centric >> forum, but we can try, and Russ reads this list anyway. >> That doesn't seem to be telling you why the postinst script failed, and >> I'm not really sure of everything that it does that can fail. But I >> think you can get it to say what it's doing by doing something like this >> after it fails: >> Edit /var/lib/dpkg/info/openafs-client.postinst, and change the 'set -e' >> near the top to 'set -xe'. Then run 'dpkg --configure --pending', or >> maybe just try to install openafs-client again. It should print out a >> bunch more stuff about what commands it is running, which should give a >> clue as to what is actually failing. (And thanks for running with >> LANG=C; that is helpful.) > This may or may not work the way that you want because of how debconf > works, but yes, that's what I'd suggest as well. > > I suspect the problem is with setting up alternatives for klog, since > that's the next line immediately after setting up alternatives for pagsh. > Therefore, the output of: > > ls -l /usr/bin/klog /usr/share/man/man1/klog.1.gz \ > /etc/alternatives/klog /etc/alternatives/klog.1.gz > > might be useful. In particular, if you have an actual binary instead of a > symlink installed as /usr/bin/klog, bad things will happen (although I > would have expected some sort of error message). > Humm... We did that : # cp -a /etc/openafs /etc/openafs.BAK # apt-get remove openafs-krb5 openafs-client openafs-fileserver --purge # apt-get -t squeeze-backports install openafs-fileserver openafs-client # /etc/init.d/openafs-client stop # /etc/init.d/openafs-fileserver stop # cp -a /etc/openafs.BAK/* /etc/openafs/ # /etc/init.d/openafs-client stop # /etc/init.d/openafs-fileserver stop Apparently, now everything works. Jean-Marc From jm130794@gmail.com Thu Oct 3 18:59:21 2013 From: jm130794@gmail.com (Jean-Marc Choulet) Date: Thu, 03 Oct 2013 19:59:21 +0200 Subject: [OpenAFS] Re: Update squeeze openafs-fileserver to squeeze-backports In-Reply-To: <524DAD4D.8090503@gmail.com> References: <524D8C35.2020707@gmail.com> <524D8E96.2070707@gmail.com> <20131003111312.ca5462df.adeason@sinenomine.net> <87siwipbdc.fsf@windlord.stanford.edu> <524DAD4D.8090503@gmail.com> Message-ID: <524DB079.9080308@gmail.com> This is a multi-part message in MIME format. --------------090102060609000406050604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We correct errors in the previous message. We solved the problem like this: # rm -rf /etc/openafs # apt-get remove openafs-krb5 openafs-client openafs-fileserver --purge # apt-get -t squeeze-backports install openafs-fileserver openafs-client # /etc/init.d/openafs-client stop # /etc/init.d/openafs-fileserver stop # rsync -av xxx.xxx.xxx.xxx:/etc/openafs /etc/ # /etc/init.d/openafs-client start # /etc/init.d/openafs-fileserver start It was not perhaps a problem with alternatives ? Thanks, Jean-Marc --------------090102060609000406050604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

We correct errors in the previous message. We solved the problem like this:

# rm -rf /etc/openafs
# apt-get remove openafs-krb5 openafs-client openafs-fileserver --purge
# apt-get -t squeeze-backports install openafs-fileserver openafs-client
# /etc/init.d/openafs-client stop
# /etc/init.d/openafs-fileserver stop
# rsync -av xxx.xxx.xxx.xxx:/etc/openafs /etc/
# /etc/init.d/openafs-client start
# /etc/init.d/openafs-fileserver start

It was not perhaps a problem with alternatives ?

Thanks,

Jean-Marc

--------------090102060609000406050604-- From prochazka.nicolas@gmail.com Thu Oct 3 19:08:48 2013 From: prochazka.nicolas@gmail.com (nicolas prochazka) Date: Thu, 3 Oct 2013 20:08:48 +0200 Subject: [OpenAFS] Re: [ Openafs : cache on zfs ] In-Reply-To: References: Message-ID: hello, sorry for the spam, this is a misconfigured cache option. Regards, Nicolas Prochazka. 2013/10/3 nicolas prochazka : > Hello again , > after some tests to use zfs as afs cache, > linux kernel tells : > BUG : soft lockup - CPU0 stuck for 23s ! [ afs_cachetrim:2908] > > Any ideas are welcome, > Regards, > Nicolas Prochazka From adeason@sinenomine.net Thu Oct 3 19:16:58 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 3 Oct 2013 13:16:58 -0500 Subject: [OpenAFS] Re: [ Openafs : cache on zfs ] References: Message-ID: <20131003131658.5efb190a.adeason@sinenomine.net> On Thu, 3 Oct 2013 19:34:27 +0200 nicolas prochazka wrote: > Hello again , > after some tests to use zfs as afs cache, > linux kernel tells : > BUG : soft lockup - CPU0 stuck for 23s ! [ afs_cachetrim:2908] > > Any ideas are welcome, It seems pretty likely from your other message that using zfsonlinux for the openafs client cache is not going to work at all until someone takes the time to add support for it. Just use another filesystem. Even on other platforms, ZFS has some characteristics that make it not ideal for a cache, and in the past I've recommended using something else when it's easy to do so (e.g. UFS on Solaris, even if it's jus on a zvol). At least on Solaris, ZFS does some somewhat unique things with space allocations that have created some semi-unavoidable problems for the cache manager. I can understand if someone is using ZFS for their root fs, and they don't want to make a separate fs just for the cache, but if you're making an fs just for the cache or something, it doesn't make a lot of sense. -- Andrew Deason adeason@sinenomine.net From ballbery@sinenomine.net Thu Oct 3 19:19:02 2013 From: ballbery@sinenomine.net (Brandon Allbery) Date: Thu, 3 Oct 2013 18:19:02 +0000 Subject: [OpenAFS] Re: [ Openafs : cache on zfs ] In-Reply-To: Message-ID: T24gMTAvMy8xMyAxNDowOCwgIm5pY29sYXMgcHJvY2hhemthIiA8cHJvY2hhemthLm5pY29sYXNA Z21haWwuY29tPiB3cm90ZToNCg0KPmhlbGxvLA0KPnNvcnJ5IGZvciB0aGUgc3BhbSwgdGhpcyBp cyBhIG1pc2NvbmZpZ3VyZWQgY2FjaGUgb3B0aW9uLg0KPlJlZ2FyZHMsDQo+Tmljb2xhcyBQcm9j aGF6a2EuDQo+DQo+MjAxMy8xMC8zIG5pY29sYXMgcHJvY2hhemthIDxwcm9jaGF6a2Eubmljb2xh c0BnbWFpbC5jb20+Og0KPj4gSGVsbG8gYWdhaW4gLA0KPj4gYWZ0ZXIgc29tZSB0ZXN0cyB0byB1 c2UgemZzIGFzIGFmcyBjYWNoZSwNCj4+IGxpbnV4IGtlcm5lbCB0ZWxscyA6DQo+PiBCVUcgOiBz b2Z0IGxvY2t1cCAtIENQVTAgc3R1Y2sgZm9yIDIzcyAhIFsgYWZzX2NhY2hldHJpbToyOTA4XQ0K DQpTb21lb25lIHNob3VsZCBwcm9iYWJseSBtZW50aW9uIHRoYXQgT3BlbkFGUyBjYWNoZSBvbiBa RlMgaGFzIHBlcmZvcm1hbmNlDQppc3N1ZXMgKGdyZWF0IGNhcmUgaXMgbmVlZGVkIHRvIGdldCBj YWNoZSBjaHVua3MgdG8gbWVzaCB3ZWxsIHdpdGggWkZTDQpibG9ja3MgYW5kIHN0cmlwZXM7IHRo ZSBsYXR0ZXIgYXJlIG5vdCB0dW5hYmxlKSBhbmQgaXQncyBnZW5lcmFsbHkgZWFzaWVyDQphbmQg cHJlZmVyYWJsZSB0byB1c2UgYSBmYXN0IGZpbGVzeXN0ZW0gb24gYSB6dm9sdW1lLg0KDQotLSAN CmJyYW5kb24gcyBhbGxiZXJ5IGtmOG5oICAgIHNpbmUgbm9taW5lIGFzc29jaWF0ZXMNCmFsbGJl cnkuYkBnbWFpbC5jb20gICAgICAgYmFsbGJlcnlAc2luZW5vbWluZS5uZXQNCnVuaXgsIG9wZW5h ZnMsIGtlcmJlcm9zLCBpbmZyYXN0cnVjdHVyZSwgeG1vbmFkDQoNCg0KDQo= From adeason@sinenomine.net Thu Oct 3 19:21:59 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 3 Oct 2013 13:21:59 -0500 Subject: [OpenAFS] Re: Update squeeze openafs-fileserver to squeeze-backports References: <524D8C35.2020707@gmail.com> <524D8E96.2070707@gmail.com> <20131003111312.ca5462df.adeason@sinenomine.net> <524D9B19.3020004@gmail.com> Message-ID: <20131003132159.82205b0c.adeason@sinenomine.net> On Thu, 03 Oct 2013 18:28:09 +0200 Jean-Marc Choulet wrote: > + exec /usr/share/debconf/frontend configure > dpkg: error processing openafs-client (--configure): > subprocess installed post-installation script returned error exit status 1 Apparently your problem has gone away now, but here is where the error is coming from. I don't know if that's a bug in debconf, or if the openafs packaging is invoking debconf incorrectly, but that's where it's happening. You'd have to ask Debian (ask Russ or some other list, or file a bug with debconf). -- Andrew Deason adeason@sinenomine.net From rra@stanford.edu Thu Oct 3 19:27:40 2013 From: rra@stanford.edu (Russ Allbery) Date: Thu, 03 Oct 2013 11:27:40 -0700 Subject: [OpenAFS] Re: Update squeeze openafs-fileserver to squeeze-backports In-Reply-To: <524D9B19.3020004@gmail.com> (Jean-Marc Choulet's message of "Thu, 03 Oct 2013 18:28:09 +0200") References: <524D8C35.2020707@gmail.com> <524D8E96.2070707@gmail.com> <20131003111312.ca5462df.adeason@sinenomine.net> <524D9B19.3020004@gmail.com> Message-ID: <874n8yp5ur.fsf@windlord.stanford.edu> Jean-Marc Choulet writes: > Setting up openafs-client (1.6.1-3+deb7u1~bpo60+1) ... > + [ configure = configure ] > + update-alternatives --install /usr/bin/pagsh pagsh > /usr/bin/pagsh.openafs 100 --slave /usr/share/man/man1/pagsh.1.gz > pagsh.1.gz /usr/share/man/man1/pagsh.openafs.1.gz > + update-alternatives --install /usr/bin/klog klog /usr/bin/klog.afs 10 > --slave /usr/share/man/man1/klog.1.gz klog.1.gz > /usr/share/man/man1/klog.afs.1.gz > + test -d /afs > + . /usr/share/debconf/confmodule > + [ ! ] > + PERL_DL_NONLAZY=1 > + export PERL_DL_NONLAZY > + [ ] > + exec /usr/share/debconf/frontend configure Okay, not a problem with alternatives. Something failed after debconf got invoked, which unfortunately loses the set -x. That unfortunately makes it a lot harder to figure out what failed. Your subsequent message indicates that there was some problem with the local configuration that was triggering a bug in the postinst. Unfortunately, I'm not sure what. :/ -- Russ Allbery (rra@stanford.edu) From rra@stanford.edu Thu Oct 3 19:39:34 2013 From: rra@stanford.edu (Russ Allbery) Date: Thu, 03 Oct 2013 11:39:34 -0700 Subject: [OpenAFS] Re: Update squeeze openafs-fileserver to squeeze-backports In-Reply-To: <20131003132159.82205b0c.adeason@sinenomine.net> (Andrew Deason's message of "Thu, 3 Oct 2013 13:21:59 -0500") References: <524D8C35.2020707@gmail.com> <524D8E96.2070707@gmail.com> <20131003111312.ca5462df.adeason@sinenomine.net> <524D9B19.3020004@gmail.com> <20131003132159.82205b0c.adeason@sinenomine.net> Message-ID: <87zjqqnqqh.fsf@windlord.stanford.edu> Andrew Deason writes: > Apparently your problem has gone away now, but here is where the error > is coming from. I don't know if that's a bug in debconf, or if the > openafs packaging is invoking debconf incorrectly, but that's where it's > happening. You'd have to ask Debian (ask Russ or some other list, or > file a bug with debconf). set -x doesn't follow shell scripts through debconf because debconf does some black magic to reinvoke the script. It's one of the things that makes debugging postinst scripts so "interesting." -- Russ Allbery (rra@stanford.edu) From pontius@btv.ibm.com Thu Oct 3 19:46:55 2013 From: pontius@btv.ibm.com (Dale Pontius) Date: Thu, 03 Oct 2013 14:46:55 -0400 Subject: [OpenAFS] Re: [ Openafs : cache on zfs ] In-Reply-To: <20131003131658.5efb190a.adeason@sinenomine.net> References: <20131003131658.5efb190a.adeason@sinenomine.net> Message-ID: <524DBB9F.9060207@btv.ibm.com> On 10/03/2013 02:16 PM, Andrew Deason wrote: > On Thu, 3 Oct 2013 19:34:27 +0200 > nicolas prochazka wrote: > >> Hello again , >> after some tests to use zfs as afs cache, >> linux kernel tells : >> BUG : soft lockup - CPU0 stuck for 23s ! [ afs_cachetrim:2908] >> >> Any ideas are welcome, > It seems pretty likely from your other message that using zfsonlinux for > the openafs client cache is not going to work at all until someone takes > the time to add support for it. Just use another filesystem. > > Even on other platforms, ZFS has some characteristics that make it not > ideal for a cache, and in the past I've recommended using something else > when it's easy to do so (e.g. UFS on Solaris, even if it's jus on a > zvol). At least on Solaris, ZFS does some somewhat unique things with > space allocations that have created some semi-unavoidable problems for > the cache manager. > > I can understand if someone is using ZFS for their root fs, and they > don't want to make a separate fs just for the cache, but if you're > making an fs just for the cache or something, it doesn't make a lot of > sense. > My impression has always been that journalling is not only not needed for the afs cache, but even not desirable. Up until recently I'd use the simplest thing - an ext2 partition with noatime. On my latest installs I've begun using ext4 with the journal turned off, figuring that with any luck afs cache blocks would map to ext4 extents, giving me better cache performance than even ext2. Then again somewhere else, on top of no journal, I got the options: /dev/sdb6 /var/cache/openafs ext4 data=writeback,barrier=0,nobh,errors=remount-ro,noatime 1 2 Dale Pontius -- Dale Pontius Senior Engineer IBM Corporation Phone: (802) 769-6850 Tie-Line: 446-6850 email: pontius@us.ibm.com This e-mail and its attachments, if any, may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message from your system without copying it and notify sender of the misdirection by reply e-mail. From adeason@sinenomine.net Thu Oct 3 20:47:39 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 3 Oct 2013 14:47:39 -0500 Subject: [OpenAFS] Re: Update squeeze openafs-fileserver to squeeze-backports References: <524D8C35.2020707@gmail.com> <524D8E96.2070707@gmail.com> <20131003111312.ca5462df.adeason@sinenomine.net> <524D9B19.3020004@gmail.com> <20131003132159.82205b0c.adeason@sinenomine.net> <87zjqqnqqh.fsf@windlord.stanford.edu> Message-ID: <20131003144739.f3d54c62.adeason@sinenomine.net> On Thu, 03 Oct 2013 11:39:34 -0700 Russ Allbery wrote: > > > + exec /usr/share/debconf/frontend configure [...] > set -x doesn't follow shell scripts through debconf because debconf does > some black magic to reinvoke the script. It's one of the things that > makes debugging postinst scripts so "interesting." I'm not sure if it matters, and sorry if this is getting too far off topic, but I'm not following this as the reason. It's invoking /usr/share/debconf/frontend, which at least for a debian system I'm glancing at, is a perl script, so of course the perl isn't going to honor 'set -x'. But if you mean that that perl reinvokes the original postinst shell script, I don't see how it could do so; how does it know which script to run? -- Andrew Deason adeason@sinenomine.net From ballbery@sinenomine.net Thu Oct 3 20:49:42 2013 From: ballbery@sinenomine.net (Brandon Allbery) Date: Thu, 3 Oct 2013 19:49:42 +0000 Subject: [OpenAFS] Re: Update squeeze openafs-fileserver to squeeze-backports In-Reply-To: <20131003144739.f3d54c62.adeason@sinenomine.net> Message-ID: T24gMTAvMy8xMyAxNTo0NywgIkFuZHJldyBEZWFzb24iIDxhZGVhc29uQHNpbmVub21pbmUubmV0 PiB3cm90ZToNCg0KPk9uIFRodSwgMDMgT2N0IDIwMTMgMTE6Mzk6MzQgLTA3MDANCj5SdXNzIEFs bGJlcnkgPHJyYUBzdGFuZm9yZC5lZHU+IHdyb3RlOg0KPg0KPj4gPiA+ICsgZXhlYyAvdXNyL3No YXJlL2RlYmNvbmYvZnJvbnRlbmQgIGNvbmZpZ3VyZQ0KPlsuLi5dDQo+PiBzZXQgLXggZG9lc24n dCBmb2xsb3cgc2hlbGwgc2NyaXB0cyB0aHJvdWdoIGRlYmNvbmYgYmVjYXVzZSBkZWJjb25mIGRv ZXMNCj4+IHNvbWUgYmxhY2sgbWFnaWMgdG8gcmVpbnZva2UgdGhlIHNjcmlwdC4gIEl0J3Mgb25l IG9mIHRoZSB0aGluZ3MgdGhhdA0KPj4gbWFrZXMgZGVidWdnaW5nIHBvc3RpbnN0IHNjcmlwdHMg c28gImludGVyZXN0aW5nLiINCj4NCj5JJ20gbm90IHN1cmUgaWYgaXQgbWF0dGVycywgYW5kIHNv cnJ5IGlmIHRoaXMgaXMgZ2V0dGluZyB0b28gZmFyIG9mZg0KPnRvcGljLCBidXQgSSdtIG5vdCBm b2xsb3dpbmcgdGhpcyBhcyB0aGUgcmVhc29uLiBJdCdzIGludm9raW5nDQo+L3Vzci9zaGFyZS9k ZWJjb25mL2Zyb250ZW5kLCB3aGljaCBhdCBsZWFzdCBmb3IgYSBkZWJpYW4gc3lzdGVtIEknbQ0K PmdsYW5jaW5nIGF0LCBpcyBhIHBlcmwgc2NyaXB0LCBzbyBvZiBjb3Vyc2UgdGhlIHBlcmwgaXNu J3QgZ29pbmcgdG8NCj5ob25vciAnc2V0IC14Jy4gQnV0IGlmIHlvdSBtZWFuIHRoYXQgdGhhdCBw ZXJsIHJlaW52b2tlcyB0aGUgb3JpZ2luYWwNCj5wb3N0aW5zdCBzaGVsbCBzY3JpcHQsIEkgZG9u J3Qgc2VlIGhvdyBpdCBjb3VsZCBkbyBzbzsgaG93IGRvZXMgaXQga25vdw0KPndoaWNoIHNjcmlw dCB0byBydW4/DQoNCkkgc3VzcGVjdCB0aGF0J3MgdGhlIG1lbnRpb25lZCBibGFjayBtYWdpYyAo YW5kIEkgY2FuIHRoaW5rIG9mIHNldmVyYWwNCmV2aWwgd2F5cyB0byBwdWxsIGl0IG9mZikuDQoN Ci0tIA0KYnJhbmRvbiBzIGFsbGJlcnkga2Y4bmggICAgc2luZSBub21pbmUgYXNzb2NpYXRlcw0K YWxsYmVyeS5iQGdtYWlsLmNvbSAgICAgICBiYWxsYmVyeUBzaW5lbm9taW5lLm5ldA0KdW5peCwg b3BlbmFmcywga2VyYmVyb3MsIGluZnJhc3RydWN0dXJlLCB4bW9uYWQNCg0KDQoNCg== From rra@stanford.edu Thu Oct 3 21:15:25 2013 From: rra@stanford.edu (Russ Allbery) Date: Thu, 03 Oct 2013 13:15:25 -0700 Subject: [OpenAFS] Re: Update squeeze openafs-fileserver to squeeze-backports In-Reply-To: <20131003144739.f3d54c62.adeason@sinenomine.net> (Andrew Deason's message of "Thu, 3 Oct 2013 14:47:39 -0500") References: <524D8C35.2020707@gmail.com> <524D8E96.2070707@gmail.com> <20131003111312.ca5462df.adeason@sinenomine.net> <524D9B19.3020004@gmail.com> <20131003132159.82205b0c.adeason@sinenomine.net> <87zjqqnqqh.fsf@windlord.stanford.edu> <20131003144739.f3d54c62.adeason@sinenomine.net> Message-ID: <87d2nmnmaq.fsf@windlord.stanford.edu> Andrew Deason writes: > I'm not sure if it matters, and sorry if this is getting too far off > topic, but I'm not following this as the reason. It's invoking > /usr/share/debconf/frontend, which at least for a debian system I'm > glancing at, is a perl script, so of course the perl isn't going to > honor 'set -x'. But if you mean that that perl reinvokes the original > postinst shell script, I don't see how it could do so; how does it know > which script to run? See /usr/share/debconf/confmodule. Basically, it passes in $0. I suspect the actual problem isn't so much that, now that I've looked at it more, but with this bit: # Only do this once. if [ -z "$DEBCONF_REDIR" ]; then # Redirect standard output to standard error. This prevents common # mistakes by making all the output of the postinst or whatever # script is using this library not be parsed as confmodule commands. # # To actually send something to standard output, send it to fd 3. exec 3>&1 if [ "$DEBCONF_USE_CDEBCONF" ]; then exec 1>&5 else exec 1>&2 fi DEBCONF_REDIR=1 export DEBCONF_REDIR fi I bet the -x output ends up still happening, but going off into some other file descriptor where it gets ignored. -- Russ Allbery (rra@stanford.edu) From adeason@sinenomine.net Thu Oct 3 21:41:55 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 3 Oct 2013 15:41:55 -0500 Subject: [OpenAFS] Re: Update squeeze openafs-fileserver to squeeze-backports References: <524D8C35.2020707@gmail.com> <524D8E96.2070707@gmail.com> <20131003111312.ca5462df.adeason@sinenomine.net> <524D9B19.3020004@gmail.com> <20131003132159.82205b0c.adeason@sinenomine.net> <87zjqqnqqh.fsf@windlord.stanford.edu> <20131003144739.f3d54c62.adeason@sinenomine.net> <87d2nmnmaq.fsf@windlord.stanford.edu> Message-ID: <20131003154155.077bff49.adeason@sinenomine.net> On Thu, 03 Oct 2013 13:15:25 -0700 Russ Allbery wrote: > Andrew Deason writes: > > > I'm not sure if it matters, and sorry if this is getting too far off > > topic, but I'm not following this as the reason. It's invoking > > /usr/share/debconf/frontend, which at least for a debian system I'm > > glancing at, is a perl script, so of course the perl isn't going to > > honor 'set -x'. But if you mean that that perl reinvokes the original > > postinst shell script, I don't see how it could do so; how does it know > > which script to run? > > See /usr/share/debconf/confmodule. Basically, it passes in $0. But it's not, according to the 'set -x' output. There is no script filename passed to .../frontend. It's running this, which is why I put it back in the quoted context: > > > + exec /usr/share/debconf/frontend configure > I suspect the actual problem isn't so much that, now that I've looked > at it more, but with this bit: > > # Only do this once. > if [ -z "$DEBCONF_REDIR" ]; then But we're not running this. If we ran that, it would appear in the 'set -x' output at least once, before output was redirected. (Unless .../frontend is re-running the script and redirecting output before it runs the script, but as mentioned above, I don't see how it could be doing that.) -- Andrew Deason adeason@sinenomine.net From rra@stanford.edu Thu Oct 3 21:46:44 2013 From: rra@stanford.edu (Russ Allbery) Date: Thu, 03 Oct 2013 13:46:44 -0700 Subject: [OpenAFS] Re: Update squeeze openafs-fileserver to squeeze-backports In-Reply-To: <20131003154155.077bff49.adeason@sinenomine.net> (Andrew Deason's message of "Thu, 3 Oct 2013 15:41:55 -0500") References: <524D8C35.2020707@gmail.com> <524D8E96.2070707@gmail.com> <20131003111312.ca5462df.adeason@sinenomine.net> <524D9B19.3020004@gmail.com> <20131003132159.82205b0c.adeason@sinenomine.net> <87zjqqnqqh.fsf@windlord.stanford.edu> <20131003144739.f3d54c62.adeason@sinenomine.net> <87d2nmnmaq.fsf@windlord.stanford.edu> <20131003154155.077bff49.adeason@sinenomine.net> Message-ID: <87txgym6a3.fsf@windlord.stanford.edu> Andrew Deason writes: > But it's not, according to the 'set -x' output. There is no script > filename passed to .../frontend. It's running this, which is why I put > it back in the quoted context: >> > > + exec /usr/share/debconf/frontend configure Oh, indeed, I missed that. Hm. >> I suspect the actual problem isn't so much that, now that I've looked >> at it more, but with this bit: >> >> # Only do this once. >> if [ -z "$DEBCONF_REDIR" ]; then > But we're not running this. If we ran that, it would appear in the 'set > -x' output at least once, before output was redirected. (Unless > .../frontend is re-running the script and redirecting output before it > runs the script, but as mentioned above, I don't see how it could be > doing that.) Yeah, there's some piece missing here. I've never entirely understood how this stuff works. I do know that set -x never works with any shell script that uses debconf (in other words, this is not specific to OpenAFS and has been an issue for a long time), so there's something that debconf is doing that prevents it from working, but I don't know exactly what. -- Russ Allbery (rra@stanford.edu) From moa@fysik.su.se Fri Oct 4 09:27:30 2013 From: moa@fysik.su.se (=?ISO-8859-1?Q?Torbj=F6rn_Moa?=) Date: Fri, 04 Oct 2013 10:27:30 +0200 Subject: [OpenAFS] Update squeeze openafs-fileserver to squeeze-backports In-Reply-To: <524D8C35.2020707@gmail.com> References: <524D8C35.2020707@gmail.com> Message-ID: <524E7BF2.9010409@fysik.su.se> Hi, I don't know if this is at all related, but I vaguely recall having had a similar problem. It turned out that the cell name string in /etc/openafs/ThisCell, as made by the initial installation config, didn't have a line termination, which made the upgrade config script choke when trying to read it. Consequently, it was easily fixed by just adding a at the end of the line. But then again, this may not be your problem at all, although the symptoms are quite similar. Best wishes, Torbj=F6rn On 10/03/2013 05:24 PM, Jean-Marc Choulet wrote: > Hello, >=20 > We want to upgrade openafs-fileserver to squeeze-backports and we get > this errors : >=20 > LANG=3DC apt-get -t squeeze-backports install openafs-client > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following packages were automatically installed and are no longer > required: > bison flex > Use 'apt-get autoremove' to remove them. > Suggested packages: > openafs-doc > The following packages will be upgraded: > openafs-client > 1 upgraded, 0 newly installed, 0 to remove and 5 not upgraded. > 1 not fully installed or removed. > Need to get 0 B/3843 kB of archives. > After this operation, 717 kB of additional disk space will be used. > Reading changelogs... Done > Preconfiguring packages ... > openafs-client failed to preconfigure, with exit status 1 > (Reading database ... 38192 files and directories currently installed.) > Preparing to replace openafs-client 1.4.12.1+dfsg-4+squeeze2 (using > .../openafs-client_1.6.1-3+deb7u1~bpo60+1_amd64.deb) ... > Unpacking replacement openafs-client ... > Processing triggers for man-db ... > Setting up openafs-client (1.6.1-3+deb7u1~bpo60+1) ... > Installing new version of config file /etc/init.d/openafs-client ... > dpkg: error processing openafs-client (--configure): > subprocess installed post-installation script returned error exit stat= us 1 > configured to not write apport reports > Errors were encountered while > processing: > openafs-client > E: Sub-process /usr/bin/dpkg returned an error code (1) > root@fs01:~# >=20 > Do you any ideas ? >=20 > Thank, >=20 > Jean-Marc > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info From milek@task.gda.pl Fri Oct 4 14:09:11 2013 From: milek@task.gda.pl (milek@task.gda.pl) Date: Fri, 4 Oct 2013 14:09:11 +0100 Subject: [OpenAFS] Re: [ Openafs : cache on zfs ] In-Reply-To: <20131003131658.5efb190a.adeason@sinenomine.net> References: <20131003131658.5efb190a.adeason@sinenomine.net> Message-ID: <005f01cec102$eb45d240$c1d176c0$@task.gda.pl> > -----Original Message----- > From: openafs-info-admin@openafs.org [mailto:openafs-info- > admin@openafs.org] On Behalf Of Andrew Deason > Sent: 03 October 2013 19:17 > To: openafs-info@openafs.org > Subject: [OpenAFS] Re: [ Openafs : cache on zfs ] > > On Thu, 3 Oct 2013 19:34:27 +0200 > nicolas prochazka wrote: > > > Hello again , > > after some tests to use zfs as afs cache, linux kernel tells : > > BUG : soft lockup - CPU0 stuck for 23s ! [ afs_cachetrim:2908] > > > > Any ideas are welcome, > > It seems pretty likely from your other message that using zfsonlinux > for the openafs client cache is not going to work at all until someone > takes the time to add support for it. Just use another filesystem. > > Even on other platforms, ZFS has some characteristics that make it not > ideal for a cache, and in the past I've recommended using something > else when it's easy to do so (e.g. UFS on Solaris, even if it's jus on > a zvol). At least on Solaris, ZFS does some somewhat unique things with > space allocations that have created some semi-unavoidable problems for > the cache manager. > > I can understand if someone is using ZFS for their root fs, and they > don't want to make a separate fs just for the cache, but if you're > making an fs just for the cache or something, it doesn't make a lot of > sense. We've been running AFS cache on ZFS directly for some time now, with no issues. The trick is to set AFS cache size somewhat smaller than the amount of space present by the file system (so essentially we slightly over-provision). On top of it we enable ZFS compression on the cache file system, so in reality we overprovision even more. All works fine. Given that AFS cache tends to be small (several GBs, anyone is using considerably larger cache?), a small over-provisioning is not an issue. For example, create ZFS file system for AFS cache as: # zfs create -o atime=off -o quota=8G -o reservation=8G -o compression=lzjb -o recordsize=8K -o mountpoint=/afscache rpool/afscache And in cacheinfo the specified cache size is: 6710886 This is less than 2GB overprovisioned (assuming nothing will compress), but with modern disk sizes of OS it doesn't matter at all and seems to be a safe enough margin. The compression is not for disk space saving it is more for doing less i/o in some cases (depending on data). -- Robert Milkowski http://milek.blogspot.com From milek@task.gda.pl Fri Oct 4 14:09:59 2013 From: milek@task.gda.pl (milek@task.gda.pl) Date: Fri, 4 Oct 2013 14:09:59 +0100 Subject: [OpenAFS] Re: [ Openafs : cache on zfs ] In-Reply-To: <20131003131658.5efb190a.adeason@sinenomine.net> References: <20131003131658.5efb190a.adeason@sinenomine.net> Message-ID: <006001cec103$084734b0$18d59e10$@task.gda.pl> > -----Original Message----- > From: openafs-info-admin@openafs.org [mailto:openafs-info- > admin@openafs.org] On Behalf Of Andrew Deason > Sent: 03 October 2013 19:17 > To: openafs-info@openafs.org > Subject: [OpenAFS] Re: [ Openafs : cache on zfs ] > > On Thu, 3 Oct 2013 19:34:27 +0200 > nicolas prochazka wrote: > > > Hello again , > > after some tests to use zfs as afs cache, linux kernel tells : > > BUG : soft lockup - CPU0 stuck for 23s ! [ afs_cachetrim:2908] > > > > Any ideas are welcome, > > It seems pretty likely from your other message that using zfsonlinux > for the openafs client cache is not going to work at all until someone > takes the time to add support for it. Just use another filesystem. > > Even on other platforms, ZFS has some characteristics that make it not > ideal for a cache, and in the past I've recommended using something > else when it's easy to do so (e.g. UFS on Solaris, even if it's jus on > a zvol). At least on Solaris, ZFS does some somewhat unique things with > space allocations that have created some semi-unavoidable problems for > the cache manager. > > I can understand if someone is using ZFS for their root fs, and they > don't want to make a separate fs just for the cache, but if you're > making an fs just for the cache or something, it doesn't make a lot of > sense. We've been running AFS cache on ZFS directly for some time now, with no issues. The trick is to set AFS cache size somewhat smaller than the amount of space present by the file system (so essentially we slightly over-provision). On top of it we enable ZFS compression on the cache file system, so in reality we overprovision even more. All works fine. Given that AFS cache tends to be small (several GBs, anyone is using considerably larger cache?), a small over-provisioning is not an issue. For example, create ZFS file system for AFS cache as: # zfs create -o atime=off -o quota=8G -o reservation=8G -o compression=lzjb -o recordsize=8K -o mountpoint=/afscache rpool/afscache And in cacheinfo the specified cache size is: 6710886 This is less than 2GB overprovisioned (assuming nothing will compress), but with modern disk sizes of OS it doesn't matter at all and seems to be a safe enough margin. The compression is not for disk space saving it is more for doing less i/o in some cases (depending on data). -- Robert Milkowski http://milek.blogspot.com From jblaine@kickflop.net Fri Oct 4 15:31:47 2013 From: jblaine@kickflop.net (Jeff Blaine) Date: Fri, 04 Oct 2013 10:31:47 -0400 Subject: [OpenAFS] ZFS-on-Linux on production fileservers? Message-ID: <524ED153.6070303@kickflop.net> [ For those running ext3/ext4, a question further down for you as ] [ well! ] We're still a 100% Solaris + ZFS file server shop. We're EOLing our Sun SPARC hardware (with tears in our eyes) this year. Before we spend a significant amount of time evaluating this, I figured I'd ask first. Any brief response would be greatly appre- ciated. The generously longer the better :) * Are you using ZFS-on-Linux in production for file servers? * If not, and you looked into it, what stopped you? * If you are, how is it working out for you? ext3/ext4 people: What is your fsck strategy? From daniel.vanderster@cern.ch Fri Oct 4 15:37:13 2013 From: daniel.vanderster@cern.ch (Dan Van Der Ster) Date: Fri, 4 Oct 2013 14:37:13 +0000 Subject: [OpenAFS] ZFS-on-Linux on production fileservers? In-Reply-To: <524ED153.6070303@kickflop.net> References: <524ED153.6070303@kickflop.net> Message-ID: <3B502314D0477C4F9478870C279E14E60103D66ED0@CERNXCHG12.cern.ch> On Oct 4, 2013, at 4:31 PM, Jeff Blaine wrote: > * If not, and you looked into it, what stopped you? We stopped because of the memory fragmentation issue. ZFS will use ~twice t= he arc limit you set, and (in my experience) if you don't set the it wisely= (e.g. 20-25% total memory), your server will lock up solid. Cheers, Dan CERN IT= From dirk.heinrichs@altum.de Fri Oct 4 15:51:22 2013 From: dirk.heinrichs@altum.de (Dirk Heinrichs) Date: Fri, 04 Oct 2013 16:51:22 +0200 Subject: [OpenAFS] [ Openafs : cache on zfs ] In-Reply-To: References: Message-ID: <1403220.sinFVVVIy4@gondor> --nextPart15875109.VTdBbRl300 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Am Donnerstag 03 Oktober 2013, 19:34:27 schrieb nicolas prochazka: > after some tests to use zfs as afs cache, > linux kernel tells : > BUG : soft lockup - CPU0 stuck for 23s ! [ afs_cachetrim:2908] > > Any ideas are welcome, You could put the cache on a "normal" Linux FS inside a ZVOL. See http://pthree.org/2012/12/21/zfs-administration-part-xiv-zvols/ HTH... Dirk -- Dirk Heinrichs Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913 GPG Public Key C2E467BB | Jabber: dirk.heinrichs@altum.de --nextPart15875109.VTdBbRl300 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iD8DBQBSTtXq8NVtnsLkZ7sRAnv9AJ0cWbyOfM7kcvX/N1eheJY7i6Jv0wCgpW/Z i14zQdM4WluRU7gs8QsVUPg= =2FeY -----END PGP SIGNATURE----- --nextPart15875109.VTdBbRl300-- From dirk.heinrichs@altum.de Fri Oct 4 15:59:05 2013 From: dirk.heinrichs@altum.de (Dirk Heinrichs) Date: Fri, 04 Oct 2013 16:59:05 +0200 Subject: [OpenAFS] ZFS-on-Linux on production fileservers? In-Reply-To: <524ED153.6070303@kickflop.net> References: <524ED153.6070303@kickflop.net> Message-ID: <1556031.KOxVVHbF72@gondor> --nextPart4916945.YOJJ9PngQ3 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Am Freitag 04 Oktober 2013, 10:31:47 schrieb Jeff Blaine: > We're still a 100% Solaris + ZFS file server shop. We're EOLing > our Sun SPARC hardware (with tears in our eyes) this year. > > Before we spend a significant amount of time evaluating this, I > figured I'd ask first. Any brief response would be greatly appre- > ciated. The generously longer the better :) > > * Are you using ZFS-on-Linux in production for file servers? > * If not, and you looked into it, what stopped you? > * If you are, how is it working out for you? A couple of weeks ago, I tried to install a _desktop_ system on ZFSonLinux. Can't remember the exact reason, but I quickly decided to stick with a native Linux FS. OTOH, I run my own small home cell on an Arm box (Guruplug) using btrfs (both vicepXX and client cache). If it must be ZFS, would FreeBSD be an option? Bye... Dirk -- Dirk Heinrichs Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913 GPG Public Key C2E467BB | Jabber: dirk.heinrichs@altum.de --nextPart4916945.YOJJ9PngQ3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iD4DBQBSTte58NVtnsLkZ7sRAoscAJipqOP/L2shlCDDR0xbMK++99OFAJ0eZaoh KVugfcaItYB///Ns/iMhNw== =7GBC -----END PGP SIGNATURE----- --nextPart4916945.YOJJ9PngQ3-- From milek@task.gda.pl Fri Oct 4 16:51:28 2013 From: milek@task.gda.pl (milek@task.gda.pl) Date: Fri, 4 Oct 2013 16:51:28 +0100 Subject: [OpenAFS] ZFS-on-Linux on production fileservers? In-Reply-To: <524ED153.6070303@kickflop.net> References: <524ED153.6070303@kickflop.net> Message-ID: <071b01cec119$97036b90$c50a42b0$@task.gda.pl> > -----Original Message----- > From: openafs-info-admin@openafs.org [mailto:openafs-info- > admin@openafs.org] On Behalf Of Jeff Blaine > Sent: 04 October 2013 15:32 > To: OpenAFS > Subject: [OpenAFS] ZFS-on-Linux on production fileservers? > > [ For those running ext3/ext4, a question further down for you as ] > [ well! ] > > We're still a 100% Solaris + ZFS file server shop. We're EOLing our Sun > SPARC hardware (with tears in our eyes) this year. > Why not ZFS on Solaris 11 x86? You can run it on non-Oracle hardware if you prefer. We have a pretty large installation on top of Solaris 11 x86 + ZFS, both on Oracle and 3rd party x86 servers. See my presentation about it last year. -- Robert Milkowski http://milek.blogspot.com From dirk.heinrichs@altum.de Fri Oct 4 17:08:20 2013 From: dirk.heinrichs@altum.de (Dirk Heinrichs) Date: Fri, 04 Oct 2013 18:08:20 +0200 Subject: [OpenAFS] ZFS-on-Linux on production fileservers? In-Reply-To: <071b01cec119$97036b90$c50a42b0$@task.gda.pl> References: <524ED153.6070303@kickflop.net> <071b01cec119$97036b90$c50a42b0$@task.gda.pl> Message-ID: <1421936.F1lXk8MIj9@gondor> --nextPart125539342.AMzx767xYH Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Am Freitag 04 Oktober 2013, 16:51:28 schrieb milek@task.gda.pl: > See my presentation about it last year. Link? Bye... Dirk -- Dirk Heinrichs Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913 GPG Public Key C2E467BB | Jabber: dirk.heinrichs@altum.de --nextPart125539342.AMzx767xYH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iD8DBQBSTuf08NVtnsLkZ7sRAmg0AKCUzAFbWGCf+qqlwOd7fFaBEY8HKwCfc5NR PyaMY+Yc4c4QWauRMyOvwas= =DkkM -----END PGP SIGNATURE----- --nextPart125539342.AMzx767xYH-- From stephan.wiesand@desy.de Fri Oct 4 17:13:46 2013 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Fri, 4 Oct 2013 18:13:46 +0200 Subject: [OpenAFS] ZFS-on-Linux on production fileservers? In-Reply-To: <1421936.F1lXk8MIj9@gondor> References: <524ED153.6070303@kickflop.net> <071b01cec119$97036b90$c50a42b0$@task.gda.pl> <1421936.F1lXk8MIj9@gondor> Message-ID: <2474F2E4-60E3-430E-AE43-692EC5C41DCB@desy.de> On Oct 4, 2013, at 18:08 , Dirk Heinrichs wrote: > Am Freitag 04 Oktober 2013, 16:51:28 schrieb milek@task.gda.pl: > >> See my presentation about it last year. > > Link? http://conferences.inf.ed.ac.uk/eakc2012/ -- Stephan Wiesand DESY -DV- Platanenenallee 6 15738 Zeuthen, Germany From milek@task.gda.pl Fri Oct 4 17:18:24 2013 From: milek@task.gda.pl (milek@task.gda.pl) Date: Fri, 4 Oct 2013 17:18:24 +0100 Subject: [OpenAFS] ZFS-on-Linux on production fileservers? In-Reply-To: <1421936.F1lXk8MIj9@gondor> References: <524ED153.6070303@kickflop.net> <071b01cec119$97036b90$c50a42b0$@task.gda.pl> <1421936.F1lXk8MIj9@gondor> Message-ID: <073a01cec11d$5a1e7180$0e5b5480$@task.gda.pl> > -----Original Message----- > From: openafs-info-admin@openafs.org [mailto:openafs-info- > admin@openafs.org] On Behalf Of Dirk Heinrichs > Sent: 04 October 2013 17:08 > To: openafs-info@openafs.org > Subject: Re: [OpenAFS] ZFS-on-Linux on production fileservers? > > Am Freitag 04 Oktober 2013, 16:51:28 schrieb milek@task.gda.pl: > > > See my presentation about it last year. > > Link? http://conferences.inf.ed.ac.uk/eakc2012/slides/AFS_on_Solaris_ZFS.pdf -- Robert Milkowski http://milek.blogspot.com From dirk.heinrichs@altum.de Fri Oct 4 17:28:49 2013 From: dirk.heinrichs@altum.de (Dirk Heinrichs) Date: Fri, 04 Oct 2013 18:28:49 +0200 Subject: [OpenAFS] ZFS-on-Linux on production fileservers? In-Reply-To: <073a01cec11d$5a1e7180$0e5b5480$@task.gda.pl> References: <524ED153.6070303@kickflop.net> <1421936.F1lXk8MIj9@gondor> <073a01cec11d$5a1e7180$0e5b5480$@task.gda.pl> Message-ID: <2786795.ZLK4PgOQS7@gondor> --nextPart4112548.iYbkFzxJ2e Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Am Freitag 04 Oktober 2013, 17:18:24 schrieb milek@task.gda.pl: > http://conferences.inf.ed.ac.uk/eakc2012/slides/AFS_on_Solaris_ZFS.pdf Thanks a lot. Bye... Dirk -- Dirk Heinrichs Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913 GPG Public Key C2E467BB | Jabber: dirk.heinrichs@altum.de --nextPart4112548.iYbkFzxJ2e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iD8DBQBSTuzB8NVtnsLkZ7sRAhFIAJ9qWUdYR5kVVo2lkzkOAWPWlM5SZQCeMPL8 VTUAU1BV1+gDGlf8o1MfLCk= =mTTI -----END PGP SIGNATURE----- --nextPart4112548.iYbkFzxJ2e-- From rra@stanford.edu Fri Oct 4 17:30:04 2013 From: rra@stanford.edu (Russ Allbery) Date: Fri, 04 Oct 2013 09:30:04 -0700 Subject: [OpenAFS] Update squeeze openafs-fileserver to squeeze-backports In-Reply-To: <524E7BF2.9010409@fysik.su.se> (=?utf-8?Q?=22Torbj=C3=B6rn?= Moa"'s message of "Fri, 04 Oct 2013 10:27:30 +0200") References: <524D8C35.2020707@gmail.com> <524E7BF2.9010409@fysik.su.se> Message-ID: <87pprlvw1f.fsf@windlord.stanford.edu> Torbj=C3=B6rn Moa writes: > I don't know if this is at all related, but I vaguely recall having had > a similar problem. It turned out that the cell name string in > /etc/openafs/ThisCell, as made by the initial installation config, > didn't have a line termination, which made the upgrade config script > choke when trying to read it. Consequently, it was easily fixed by just > adding a at the end of the line. > But then again, this may not be your problem at all, although the > symptoms are quite similar. Oh! It's failing in the *.config script! Of course. That's why the -x output goes away; that script is being run by debconf and it's a separate script that doesn't have -x. # Configure the client cell. Default to the current ThisCell file and, # failing that, the lowercased local domain name, if available. Ignore err= ors # on read, since it may fail if there's no newline in the file. if [ -r /etc/openafs/ThisCell ] ; then read cell < /etc/openafs/ThisCell db_set openafs-client/thiscell "$cell" fi Well, the comment indicates that I knew about this problem at some point, but I see no sign of actually doing what the comment says it should be doing. On the other hand, I can't figure out why that read would fail when there's no trailing newline (it doesn't for me with either bash or dash). --=20 Russ Allbery (rra@stanford.edu) From spsc-sysadmin@mlist.tugraz.at Fri Oct 4 17:36:55 2013 From: spsc-sysadmin@mlist.tugraz.at (Markus Koeberl) Date: Fri, 4 Oct 2013 18:36:55 +0200 Subject: [OpenAFS] ZFS-on-Linux on production fileservers? In-Reply-To: <524ED153.6070303@kickflop.net> References: <524ED153.6070303@kickflop.net> Message-ID: <201310041836.56717.markus.koeberl@tugraz.at> On Friday 04 October 2013 16:31:47 Jeff Blaine wrote: > [ For those running ext3/ext4, a question further down for you as ] > [ well! ] > > We're still a 100% Solaris + ZFS file server shop. We're EOLing > our Sun SPARC hardware (with tears in our eyes) this year. > > Before we spend a significant amount of time evaluating this, I > figured I'd ask first. Any brief response would be greatly appre- > ciated. The generously longer the better :) > > * Are you using ZFS-on-Linux in production for file servers? At home I started playing about two years ago. I am now using a 3 disk raidz and a mirror. Had big problems with my hardware at the beginning. But thanks to ZFS I was able to eliminate the bad disks. Now everything is working. At work I have one server running for 2 months now without big troubles ~30 linux $HOME volumes on a SSD mirror ~350 RO and 250 RW volumes on 12x2TB sata mirror +l2arc > * If not, and you looked into it, what stopped you? > * If you are, how is it working out for you? I set arc_max to 8GB on a 24GB machine which lets me 1.9GB free at the moment. There have been suggestions on the mailinglist to play with arc_metadata_max and to set vm.min_free_kbytes to about 1% of RAM to avoid huge load or a lock up. I have not played around with this because limiting arc to 8GB es good enough for me at the moment. With compression set to lz4 it gives me good performance. I strongly suggest to test well and to have a look at the current limitations of zfsonlinux (there have been several discussions on the mailing list). regards Markus -- Markus Koeberl Graz University of Technology Signal Processing and Speech Communication Laboratory E-mail: markus.koeberl@tugraz.at From James.E.Dobson@Dartmouth.EDU Fri Oct 4 17:44:23 2013 From: James.E.Dobson@Dartmouth.EDU (James E. Dobson) Date: Fri, 4 Oct 2013 12:44:23 -0400 Subject: [OpenAFS] ZFS-on-Linux on production fileservers? In-Reply-To: <071b01cec119$97036b90$c50a42b0$@task.gda.pl> References: <524ED153.6070303@kickflop.net> <071b01cec119$97036b90$c50a42b0$@task.gda.pl> Message-ID: <524EF067.2030604@Dartmouth.EDU> FWIW: I'm using SmartOS (USB device boot) to boot a "smart machine" (aka a "zone") with OpenAFS. Giving up any large amount of space for boot devices on my fileservers seems rather stupid. This has been in production for several months now. Using Debian + zfsonlinux with some success for other systems. Jed Dobson Dartmouth College From adeason@sinenomine.net Fri Oct 4 18:44:06 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Fri, 4 Oct 2013 12:44:06 -0500 Subject: [OpenAFS] Re: Update squeeze openafs-fileserver to squeeze-backports References: <524D8C35.2020707@gmail.com> <524E7BF2.9010409@fysik.su.se> <87pprlvw1f.fsf@windlord.stanford.edu> Message-ID: <20131004124406.b5fa9971.adeason@sinenomine.net> On Fri, 04 Oct 2013 09:30:04 -0700 Russ Allbery wrote: > Well, the comment indicates that I knew about this problem at some > point, but I see no sign of actually doing what the comment says it > should be doing. On the other hand, I can't figure out why that read > would fail when there's no trailing newline (it doesn't for me with > either bash or dash). Looks like it does to me (bash): $ printf "foo\n" > foo.file ; echo $? 0 $ read foo < foo.file ; echo $? 0 $ printf "foo" > foo.file ; echo $? 0 $ read foo < foo.file ; echo $? 1 -- Andrew Deason adeason@sinenomine.net From rra@stanford.edu Fri Oct 4 18:52:43 2013 From: rra@stanford.edu (Russ Allbery) Date: Fri, 04 Oct 2013 10:52:43 -0700 Subject: [OpenAFS] Re: Update squeeze openafs-fileserver to squeeze-backports In-Reply-To: <20131004124406.b5fa9971.adeason@sinenomine.net> (Andrew Deason's message of "Fri, 4 Oct 2013 12:44:06 -0500") References: <524D8C35.2020707@gmail.com> <524E7BF2.9010409@fysik.su.se> <87pprlvw1f.fsf@windlord.stanford.edu> <20131004124406.b5fa9971.adeason@sinenomine.net> Message-ID: <87li28vs7o.fsf@windlord.stanford.edu> Andrew Deason writes: > Russ Allbery wrote: >> Well, the comment indicates that I knew about this problem at some >> point, but I see no sign of actually doing what the comment says it >> should be doing. On the other hand, I can't figure out why that read >> would fail when there's no trailing newline (it doesn't for me with >> either bash or dash). > Looks like it does to me (bash): > $ printf "foo\n" > foo.file ; echo $? > 0 > $ read foo < foo.file ; echo $? > 0 > $ printf "foo" > foo.file ; echo $? > 0 > $ read foo < foo.file ; echo $? > 1 Oh, I see. It reads the file and sets the variable, but then exits with a non-zero status. So adding || true will fix this. I will do that for the next version of the package. -- Russ Allbery (rra@stanford.edu) From haba@kth.se Fri Oct 4 19:11:29 2013 From: haba@kth.se (Harald Barth) Date: Fri, 04 Oct 2013 20:11:29 +0200 (CEST) Subject: [OpenAFS] ZFS-on-Linux on production fileservers? In-Reply-To: <524ED153.6070303@kickflop.net> References: <524ED153.6070303@kickflop.net> Message-ID: <20131004.201129.1726380486523145845.haba@habook> > * Are you using ZFS-on-Linux in production for file servers? Yes. > * If not, and you looked into it, what stopped you? Long there was fear and doubt, but the (not) "quality" of HW-Raid solutions and hassle of Linux SW-Raid convinced us that it could not be worse with ZFS. > * If you are, how is it working out for you? It does. The are-the-zpools-OK reporting could be more comfortable and the zpool status output is not compatible to the old one. But compared to problems we had before, that's a no-brainer. Don't be surprised if raidz needs CPU power to calculate the checksums, so you need to get the balance between I/O and CPU/cores right for the raidz level you want. > ext3/ext4 people: What is your fsck strategy? Before that we used xfs on HW- and SW-Raid. We had no problems with the xfs part of it. However we felt all the time that the possible max log sizes were 1990-ish. Harald. From chanlists@googlemail.com Fri Oct 4 23:36:53 2013 From: chanlists@googlemail.com (Christian) Date: Sat, 05 Oct 2013 00:36:53 +0200 Subject: [OpenAFS] not enough space in target directory Message-ID: <524F4305.4030102@googlemail.com> All, we are seeing some weird issues with the windows client (1.7.26, but hat also seen that with previous 1.7 versions). Often, when attempting to write data, my users get a popup box complaining about insufficient space in the target directory. In those cases, writing the data to the RW path (.cell.name) instead works just fine. Note that the volumes which are being accessed in those cases do NOT have RO replicas, just some of the volumes from which they are mounted. Write access just fails intermittently when accessed through a path which contains OTHER replicated volumes. So, for example, say that the volume "users" containing the mount points for the individual user volumes is replicated. Then write access to /afs/our.cell/users/joe.user will fail intermittently, while writing to /afs/.our.cell/users/joe.user always works. We use dynroot and SRV records. I have read the debugging instructions, but I am a little unsure about how we should proceed here. What should I do? Try fs trace? Thanks, Christian From jaltman@your-file-system.com Sat Oct 5 01:18:29 2013 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Fri, 04 Oct 2013 20:18:29 -0400 Subject: [OpenAFS] not enough space in target directory In-Reply-To: <524F4305.4030102@googlemail.com> References: <524F4305.4030102@googlemail.com> Message-ID: <524F5AD5.2070006@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms020804020002050401090100 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable File a bug report with Microsoft if the problem is experienced when using the explorer shell or applications relying upon the shell api for file access. This is a known bug in the explorer shell and Microsoft has been working on it for more than six months. As with all Windows bugs, a fix is prioritized based upon the number of complaints received from paying support customers. Jeffrey Altman On 10/4/2013 6:36 PM, Christian wrote: > All, >=20 > we are seeing some weird issues with the windows client (1.7.26, but ha= t > also seen that with previous 1.7 versions). Often, when attempting to > write data, my users get a popup box complaining about insufficient > space in the target directory. In those cases, writing the data to the > RW path (.cell.name) instead works just fine. Note that the volumes > which are being accessed in those cases do NOT have RO replicas, just > some of the volumes from which they are mounted. Write access just fail= s > intermittently when accessed through a path which contains OTHER > replicated volumes. >=20 > So, for example, say that the volume "users" containing the mount point= s > for the individual user volumes is replicated. Then write access to > /afs/our.cell/users/joe.user will fail intermittently, while writing to= > /afs/.our.cell/users/joe.user always works. We use dynroot and SRV reco= rds. >=20 > I have read the debugging instructions, but I am a little unsure about > how we should proceed here. What should I do? Try fs trace? >=20 > Thanks, >=20 > Christian > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info --------------ms020804020002050401090100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhAl sq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc2MTA4NjMxMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChjpVdVk6XeKFff4To xGglVcP3FVY95LfwfBUKbQKppRYgfKBFW1RIEG+KXpc3IGOOTUX0Lg1xaukRwuoqv/pqRMNK JabXcr1RFuCFg9xfcmP5Z+65qQ+IRxYCKdcNfu3GdS7rMOY57+VLU7aZnnMgnt0oE42awze8 gYQSJsdjZKKZS9DBnzxJYfzqhIw7txoMdV7rwPAZm5yujsqI/eWuZPZ+qZ+8GTsnHJzZNvc6 KrDGU6aVfknM+qf92hXA2VXvmtf1B17BBbGX6Hgat71Ufw5oXFly6/Vt+e5mKIozXytw8qPX NllsG89ITVzn0OovcpcSRFBrXanzVn7JVj33AgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFMC1SMuRefXyNAwkZM+Lgu7iJ6nFMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHVBsY+l21fY0twxzNnO0QbadbRT4n7k3rYfOMbP noBDkYQx5lcrYn19f7e+ADMPdW/MY2ZjFM76aiRgiTo2IjMB7z4vyX6hfGJKTIHX9loDW0H2 z2o0jYqXDQtXx9A/gfMtVh9J+8O5IuCPsVtXgI4p6kRQHN+Er2Rzu1I4BILxE9HsDb/ruX6p NXZSUQ2AcMP87ZVfz+reumMpJgWWAoiQWJCgp+qZ2c2AG+yV+FstiMpxIj/qB9+BrFRuam8d IGbH0tIS2tyc7pgit8Pid2Zv7HGT2NFu69INsKIyqGImhMVuOUaCq/kNi3Z+6R5Hm3ljift8 ZF52Kiq4whe8KlcxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCECWyrbsULgHrdnyrUnPHH4IwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMDA1MDAxODI5WjAjBgkqhkiG9w0BCQQxFgQUjqf3TnMDVHHgLj2PYUSYn/Vvyy8wbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQJbKtuxQuAet2fKtSc8cfgjCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhAlsq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBAQUABIIB AH7M4CoLd6KLwTRZsjFcT9Z9PKds99y7ZyNGwEwnKn5amTfJ1B17apaF/J4qXq6eMAL13mI1 mxhr3T6hX0S9dIHVpQj2p1xHw+S5/PSA+Dwi0EaylL59IpnqX5is8PXCx8gVft2DOvOKV03l eUfp4sp7+YylRGQx1YoBGSvJHI6O5QtwRIY0hjGcmAfPc/VIg5DRjgUpLj9SxQR/Fzx6Mapz 1DtQaId/kpYDUlMXsds7RCVFO0keGyJ4OkUOSP8ocmthUrtN0rkSzp03mO6KHsaB1lmLmabk albiMjHzi669oqi/Z/ysjYKIn3cgqbc0NDgIDT+SnfALCeVY53/UKEgAAAAAAAA= --------------ms020804020002050401090100-- From jm130794@gmail.com Sat Oct 5 08:27:45 2013 From: jm130794@gmail.com (Jean-Marc Choulet) Date: Sat, 05 Oct 2013 09:27:45 +0200 Subject: [OpenAFS] OpenAFS over without VPN Message-ID: <524FBF71.8020208@gmail.com> Hello, For now, we use OpenAFS in a VPN tunnel for WAN access. Is it secure (or not) to use OpenVPN over WAN without our VPN ? Jean-Marc From geza@kzsdabas.hu Sat Oct 5 09:14:29 2013 From: geza@kzsdabas.hu (=?ISO-8859-1?Q?G=E9mes_G=E9za?=) Date: Sat, 05 Oct 2013 10:14:29 +0200 Subject: [OpenAFS] OpenAFS over without VPN In-Reply-To: <524FBF71.8020208@gmail.com> References: <524FBF71.8020208@gmail.com> Message-ID: <524FCA65.10805@kzsdabas.hu> 2013-10-05 09:27 keltez�ssel, Jean-Marc Choulet �rta: > Hello, > > For now, we use OpenAFS in a VPN tunnel for WAN access. Is it secure > (or not) to use OpenVPN over WAN without our VPN ? > > Jean-Marc > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info Hi, IMHO the currently available fcrypt encryption doesn't efficiently protect (taking into account current computing speeds) the data in transit, so if your data is confidential, then yes it could be a good idea, even if it has a performance penalty. Regards. Geza Gemes From prochazka.nicolas@gmail.com Sat Oct 5 10:51:00 2013 From: prochazka.nicolas@gmail.com (nicolas prochazka) Date: Sat, 5 Oct 2013 11:51:00 +0200 Subject: [OpenAFS] [ Openafs : cache on zfs ] In-Reply-To: <1403220.sinFVVVIy4@gondor> References: <1403220.sinFVVVIy4@gondor> Message-ID: Thanks for this link,it is very interesting Regards. 2013/10/4 Dirk Heinrichs : > Am Donnerstag 03 Oktober 2013, 19:34:27 schrieb nicolas prochazka: > >> after some tests to use zfs as afs cache, >> linux kernel tells : >> BUG : soft lockup - CPU0 stuck for 23s ! [ afs_cachetrim:2908] >> >> Any ideas are welcome, > > You could put the cache on a "normal" Linux FS inside a ZVOL. See > http://pthree.org/2012/12/21/zfs-administration-part-xiv-zvols/ > > HTH... > > Dirk > -- > Dirk Heinrichs > Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913 > GPG Public Key C2E467BB | Jabber: dirk.heinrichs@altum.de From mansaxel@besserwisser.org Sat Oct 5 19:55:20 2013 From: mansaxel@besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sat, 5 Oct 2013 20:55:20 +0200 Subject: [OpenAFS] ZFS-on-Linux on production fileservers? In-Reply-To: <524ED153.6070303@kickflop.net> References: <524ED153.6070303@kickflop.net> Message-ID: <20131005185520.GC2403@besserwisser.org> --tqI+Z3u+9OQ7kwn0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: [OpenAFS] ZFS-on-Linux on production fileservers? Date: Fri, Oct 0= 4, 2013 at 10:31:47AM -0400 Quoting Jeff Blaine (jblaine@kickflop.net): > [ For those running ext3/ext4, a question further down for you as ] > [ well! ] >=20 > We're still a 100% Solaris + ZFS file server shop. We're EOLing > our Sun SPARC hardware (with tears in our eyes) this year. >=20 > Before we spend a significant amount of time evaluating this, I > figured I'd ask first. Any brief response would be greatly appre- > ciated. The generously longer the better :) >=20 > * Are you using ZFS-on-Linux in production for file servers? > * If not, and you looked into it, what stopped you? > * If you are, how is it working out for you? >=20 > ext3/ext4 people: What is your fsck strategy? I'd second the question about FreeBSD that was asked earlier. My personal cell runs vicep* on ZFS, 4 zmirrored 2TB SATA drives on an old Dell 2950 with 8G RAM. I also iSCSI share a few devices (around a TB, mail spool, backup spool, and scratch partition) from it. I'm very happy. Rock solid; as good as Solaris on X86 but Larry does not even get credit. Performance-wise, perhaps not super hot, but enough. The only important part is that you MUST NOT have a 32-bit kernel. Now, today, that probably is the default. --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'm RELIGIOUS!! I love a man with a HAIRPIECE!! Equip me with MISSILES!! --tqI+Z3u+9OQ7kwn0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlJQYJcACgkQ02/pMZDM1cWvdQCePlqIplllNaOyq6REwn6ICPja wDcAoIVajATOOIQZFOUaB5QzehL0Twhs =h7z7 -----END PGP SIGNATURE----- --tqI+Z3u+9OQ7kwn0-- From Coy.Hile@COYHILE.COM Sat Oct 5 21:13:22 2013 From: Coy.Hile@COYHILE.COM (Coy Hile) Date: Sat, 5 Oct 2013 20:13:22 +0000 Subject: [OpenAFS] ZFS-on-Linux on production fileservers? In-Reply-To: <20131005185520.GC2403@besserwisser.org> References: <524ED153.6070303@kickflop.net>,<20131005185520.GC2403@besserwisser.org> Message-ID: <84003055f9724fb894d63af64b8aca14@exch01.COYHILE.COM> Along the same lines, is anybody using any of the Illumos distributions? = =A0Personally, I'm working on rolling my own SmartOS build that has the AFS= kernel module installed so that VMs could be AFS fileservers or clients. (= Correct me if I'm wrong, but the AFS kernel module is required only for the= clients and the fileservers, right? If I host is only an AFS dbserver, it = has no requirement for the kernel module to be loaded, does it?=0A= =0A= -c=0A= =0A= =0A= ________________________________________=0A= From: openafs-info-admin@openafs.org on behalf of M=E5ns Nilsson=0A= Sent: Saturday, October 5, 2013 6:55 PM=0A= To: Jeff Blaine=0A= Cc: OpenAFS=0A= Subject: Re: [OpenAFS] ZFS-on-Linux on production fileservers?=0A= =0A= Subject: [OpenAFS] ZFS-on-Linux on production fileservers? Date: Fri, Oct 0= 4, 2013 at 10:31:47AM -0400 Quoting Jeff Blaine (jblaine@kickflop.net):=0A= > [ For those running ext3/ext4, a question further down for you as ]=0A= > [ well!=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ]=0A= >=0A= > We're still a 100% Solaris + ZFS file server shop. We're EOLing=0A= > our Sun SPARC hardware (with tears in our eyes) this year.=0A= >=0A= > Before we spend a significant amount of time evaluating this, I=0A= > figured I'd ask first. Any brief response would be greatly appre-=0A= > ciated. The generously longer the better :)=0A= >=0A= > * Are you using ZFS-on-Linux in production for file servers?=0A= > * If not, and you looked into it, what stopped you?=0A= > * If you are, how is it working out for you?=0A= >=0A= > ext3/ext4 people: What is your fsck strategy?=0A= =0A= I'd second the question about FreeBSD that was asked earlier. My=0A= personal cell runs vicep* on ZFS, 4 zmirrored 2TB SATA drives on an old=0A= Dell 2950 with 8G RAM. I also iSCSI share a few devices (around a TB,=0A= mail spool, backup spool, and scratch partition) from it. I'm very=0A= happy. Rock solid; as good as Solaris on X86 but Larry does not even=0A= get credit. Performance-wise, perhaps not super hot, but enough.=0A= =0A= The only important part is that you MUST NOT have a 32-bit kernel. Now,=0A= today, that probably is the default.=0A= =0A= --=0A= M=E5ns Nilsson=A0=A0=A0=A0 primary/secondary/besserwisser/machina=0A= MN-1334-RIPE=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 +46 705 989668=0A= I'm RELIGIOUS!!=A0 I love a man with a HAIRPIECE!!=A0 Equip me with MISSILE= S!!=0A= From jason@rampaginggeek.com Sat Oct 5 22:35:16 2013 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Sat, 05 Oct 2013 17:35:16 -0400 Subject: [OpenAFS] ZFS-on-Linux on production fileservers? In-Reply-To: <84003055f9724fb894d63af64b8aca14@exch01.COYHILE.COM> References: <524ED153.6070303@kickflop.net>,<20131005185520.GC2403@besserwisser.org> <84003055f9724fb894d63af64b8aca14@exch01.COYHILE.COM> Message-ID: <52508614.6070609@rampaginggeek.com> On 10/05/2013 04:13 PM, Coy Hile wrote: > Along the same lines, is anybody using any of the Illumos distributions? Personally, I'm working on rolling my own SmartOS build that has the AFS kernel module installed so that VMs could be AFS fileservers or clients. (Correct me if I'm wrong, but the AFS kernel module is required only for the clients and the fileservers, right? If I host is only an AFS dbserver, it has no requirement for the kernel module to be loaded, does it? > > -c > > Only the client needs the kernel module. The file servers and db servers do not need the kernel module. That said, you'll need an AFS client for running some admin commands, but that can be done from a separate machine from the fileserver/dbserver. For example, setting access rights on folders requires an AFS client. Jason From adeason@sinenomine.net Sun Oct 6 00:08:44 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Sat, 5 Oct 2013 18:08:44 -0500 Subject: [OpenAFS] Re: OpenAFS over without VPN References: <524FBF71.8020208@gmail.com> Message-ID: <20131005180844.a067de90c66ca3070b47b4ac@sinenomine.net> On Sat, 05 Oct 2013 09:27:45 +0200 Jean-Marc Choulet wrote: > For now, we use OpenAFS in a VPN tunnel for WAN access. Is it secure > (or not) to use OpenVPN over WAN without our VPN ? If you use a VPN, it will almost certainly be more secure (and faster, compared to native openafs encryption with 'fs setcrypt'). Whether or not using openafs without a vpn is "secure" depends on your requirements. Native openafs communication can be encrypted with a single-DES session key, so if an attacker can break that DES key, they can impersonate the user for the duration of that session, and only that session. It is known that brute-forcing DES keys is feasible these days, but it does take time and resources (and I believe for this specific attack you'd need to intercept parts of a legit session). For the purposes of this paragraph, a "session" means an AFS token; you get one whenever you 'aklog'. So, if that sounds like a problem for you, then you probably want to keep your VPN. Any modern VPN system would be using something stronger than DES, and so would be more secure. If you need to encrypt the contents/payload of any openafs communication, the VPN would also be faster, since more modern crypto algorithms are almost all faster than the algorithm that openafs currently uses (known as "fcrypt"; similar to DES), in addition to being stronger. -- Andrew Deason adeason@sinenomine.net From ktdreyer@ktdreyer.com Sun Oct 6 01:16:54 2013 From: ktdreyer@ktdreyer.com (Ken Dreyer) Date: Sat, 5 Oct 2013 18:16:54 -0600 Subject: [OpenAFS] ZFS-on-Linux on production fileservers? In-Reply-To: <524ED153.6070303@kickflop.net> References: <524ED153.6070303@kickflop.net> Message-ID: On Fri, Oct 4, 2013 at 8:31 AM, Jeff Blaine wrote: > * Are you using ZFS-on-Linux in production for file servers? > * If not, and you looked into it, what stopped you? The reason I have advocated against ZFS-on-Linux at work for our fileservers is that out-of-tree modules on Linux are such a hassle. It's painful enough to have to manage OpenAFS's kmod, and if we started relying on ZFS for Linux, we'd be compounding that pain. - Ken From dirk.heinrichs@altum.de Sun Oct 6 07:36:51 2013 From: dirk.heinrichs@altum.de (Dirk Heinrichs) Date: Sun, 06 Oct 2013 08:36:51 +0200 Subject: [OpenAFS] ZFS-on-Linux on production fileservers? In-Reply-To: References: <524ED153.6070303@kickflop.net> Message-ID: <2225819.YAcOtmWtXp@gondor> --nextPart1687641.0DvIhxLQYo Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Am Samstag 05 Oktober 2013, 18:16:54 schrieb Ken Dreyer: > The reason I have advocated against ZFS-on-Linux at work for our > fileservers is that out-of-tree modules on Linux are such a hassle. Hmm, not on Debian derivatives, thanks to DKMS. Bye... Dirk -- Dirk Heinrichs Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913 GPG Public Key C2E467BB | Jabber: dirk.heinrichs@altum.de --nextPart1687641.0DvIhxLQYo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iD8DBQBSUQUD8NVtnsLkZ7sRAhSzAKCp1C6haxeyoivOuZopDvAz9zF57gCeLcCB Jhgd+zFZvpfxGLj2Ib5V+iY= =QOWH -----END PGP SIGNATURE----- --nextPart1687641.0DvIhxLQYo-- From mansaxel@besserwisser.org Sun Oct 6 09:30:00 2013 From: mansaxel@besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sun, 6 Oct 2013 10:30:00 +0200 Subject: [OpenAFS] ZFS-on-Linux on production fileservers? In-Reply-To: <84003055f9724fb894d63af64b8aca14@exch01.COYHILE.COM> References: <524ED153.6070303@kickflop.net> <20131005185520.GC2403@besserwisser.org> <84003055f9724fb894d63af64b8aca14@exch01.COYHILE.COM> Message-ID: <20131006083000.GE2403@besserwisser.org> --84ND8YJRMFlzkrP4 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: RE: [OpenAFS] ZFS-on-Linux on production fileservers? Date: Sat, O= ct 05, 2013 at 08:13:22PM +0000 Quoting Coy Hile (Coy.Hile@COYHILE.COM): > Along the same lines, is anybody using any of the Illumos distributions? = =C2=A0Personally, I'm working on rolling my own SmartOS build that has the = AFS kernel module installed so that VMs could be AFS fileservers or clients= =2E (Correct me if I'm wrong, but the AFS kernel module is required only fo= r the clients and the fileservers, right? If I host is only an AFS dbserver= , it has no requirement for the kernel module to be loaded, does it? You are quite correct.=20 My server does not have the client code installed. I do not even build the kernel module on it. I also run a second server machine on old=20 Sparc iron, and neither it has the kernel module installed. The only hassle is that some bos commands need the '-localauth' flag when run on the file server. --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Hello, GORRY-O!! I'm a GENIUS from HARVARD!! --84ND8YJRMFlzkrP4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlJRH4gACgkQ02/pMZDM1cUXHgCfbAwbiXy0zn3zbm/O+hHKpDAF nGwAnizpH3UD0OokJCJJWWnnGVb6aUKn =g3+D -----END PGP SIGNATURE----- --84ND8YJRMFlzkrP4-- From ktdreyer@ktdreyer.com Sun Oct 6 23:12:31 2013 From: ktdreyer@ktdreyer.com (Ken Dreyer) Date: Sun, 6 Oct 2013 16:12:31 -0600 Subject: [OpenAFS] ZFS-on-Linux on production fileservers? In-Reply-To: <2225819.YAcOtmWtXp@gondor> References: <524ED153.6070303@kickflop.net> <2225819.YAcOtmWtXp@gondor> Message-ID: On Sun, Oct 6, 2013 at 12:36 AM, Dirk Heinrichs wrote: > Am Samstag 05 Oktober 2013, 18:16:54 schrieb Ken Dreyer: > >> The reason I have advocated against ZFS-on-Linux at work for our >> fileservers is that out-of-tree modules on Linux are such a hassle. > > Hmm, not on Debian derivatives, thanks to DKMS. Sure, I don't mean to imply that there aren't tools available to try to make the process user-friendly. But I still find them painful. For example, DKMS would require me to install the compiler and various development libraries on every single AFS (or ZFS) system. That may be acceptable for production systems, but it's not optimal for large production server deployments. Moreover, it's not a good use of resources to rebuild the same software over and over across all our production systems. I'll grant that both of those are relatively minor since disk space and CPU resources are getting cheaper, but at the same time, the number of virtual machines in our environment is always increasing. The third reason I find DKMS painful is the issue of repeatable builds. At work we use a binary-based OS distribution because we want to reduce as much as possible the category of risk associated with builds that can differ slightly from system to system. It's been my experience that DKMS had the tendency to work or fail depending on subtle configuration drift across systems. When considering production servers, DKMS packages just don't have the same risk profile as a regular binary package. From my experience, DKMS is one more area of possible configuration entropy that I want to avoid. I haven't use Debian enough to know how well DKMS works there. And on Red Hat, I haven't used DKMS for a couple years. Please feel free to take what I'm saying with a grain of salt :) Of the the four options that I know: 1. Rebuild entirely new binaries for every new kernel version 2. DKMS 3. Use and trust Red Hat's kABI 4. Just avoid out-of-tree modules each one has pros and cons, and none give me a warm fuzzy feeling, particularly for something as critical as a file system. - Ken From rra@stanford.edu Mon Oct 7 03:21:46 2013 From: rra@stanford.edu (Russ Allbery) Date: Sun, 06 Oct 2013 19:21:46 -0700 Subject: [OpenAFS] ZFS-on-Linux on production fileservers? In-Reply-To: (Ken Dreyer's message of "Sun, 6 Oct 2013 16:12:31 -0600") References: <524ED153.6070303@kickflop.net> <2225819.YAcOtmWtXp@gondor> Message-ID: <8738odrfb9.fsf@windlord.stanford.edu> Ken Dreyer writes: > For example, DKMS would require me to install the compiler and various > development libraries on every single AFS (or ZFS) system. You can use DKMS to create installable packages and just install those packages on the other systems. > The third reason I find DKMS painful is the issue of repeatable builds. Same solution there. :) -- Russ Allbery (rra@stanford.edu) From chas@cmf.nrl.navy.mil Wed Oct 9 13:01:13 2013 From: chas@cmf.nrl.navy.mil (chas williams - CONTRACTOR) Date: Wed, 9 Oct 2013 08:01:13 -0400 Subject: [OpenAFS] ZFS-on-Linux on production fileservers? In-Reply-To: <84003055f9724fb894d63af64b8aca14@exch01.COYHILE.COM> References: <524ED153.6070303@kickflop.net> <20131005185520.GC2403@besserwisser.org> <84003055f9724fb894d63af64b8aca14@exch01.COYHILE.COM> Message-ID: <20131009080113.5548a708@thirdoffive.cmf.nrl.navy.mil> On Sat, 5 Oct 2013 20:13:22 +0000 Coy Hile wrote: > Along the same lines, is anybody using any of the Illumos distributions? I briefly ran an AFS fileserver on an Illumos x86 distribution (specifically OpenIndiana) inside a VM. Unsurprisingly it worked. From ballbery@sinenomine.net Wed Oct 9 14:39:10 2013 From: ballbery@sinenomine.net (Brandon Allbery) Date: Wed, 9 Oct 2013 13:39:10 +0000 Subject: [OpenAFS] ZFS-on-Linux on production fileservers? In-Reply-To: <20131009080113.5548a708@thirdoffive.cmf.nrl.navy.mil> Message-ID: T24gMTAvOS8xMyAwODowMSwgImNoYXMgd2lsbGlhbXMgLSBDT05UUkFDVE9SIiA8Y2hhc0BjbWYu bnJsLm5hdnkubWlsPg0Kd3JvdGU6DQoNCj5PbiBTYXQsIDUgT2N0IDIwMTMgMjA6MTM6MjIgKzAw MDANCj5Db3kgSGlsZSA8Q295LkhpbGVAQ09ZSElMRS5DT00+IHdyb3RlOg0KPg0KPj4gQWxvbmcg dGhlIHNhbWUgbGluZXMsIGlzIGFueWJvZHkgdXNpbmcgYW55IG9mIHRoZSBJbGx1bW9zIGRpc3Ry aWJ1dGlvbnM/DQo+DQo+SSBicmllZmx5IHJhbiBhbiBBRlMgZmlsZXNlcnZlciBvbiBhbiBJbGx1 bW9zIHg4NiBkaXN0cmlidXRpb24NCj4oc3BlY2lmaWNhbGx5IE9wZW5JbmRpYW5hKSBpbnNpZGUg YSBWTS4gIFVuc3VycHJpc2luZ2x5IGl0IHdvcmtlZC4NCg0KRm9yIHdoYXQgaXQncyB3b3J0aCwg SSB0ZXN0ZWQgaHR0cDovL3dpa2kub3BlbmFmcy5vcmcvU29sYXJpc1F1aWNrU3RhcnQvDQpvbiBP cGVuSW5kaWFuYSBpbiBhIFZNLCBhbmQgYWxzbyByYW4gdGhyb3VnaCBtb3N0IG9mIGl0IG9uIFNt YXJ0T1MNCmFsdGhvdWdoIGl0IHR1cm5lZCBvdXQgU21hcnRPUyB3YXMgbm90IGF0IGFsbCBoYXBw eSB3aXRoIHRoZSBoYXJkd2FyZSBJDQpoYWQgYXZhaWxhYmxlIChhbmNpZW50IGNoZWFwIG5ldGJv b2ssIHNvIG5vdCBleGFjdGx5IHN1cnByaXNpbmcpLg0KDQotLSANCmJyYW5kb24gcyBhbGxiZXJ5 IGtmOG5oICAgIHNpbmUgbm9taW5lIGFzc29jaWF0ZXMNCmFsbGJlcnkuYkBnbWFpbC5jb20gICAg ICAgYmFsbGJlcnlAc2luZW5vbWluZS5uZXQNCnVuaXgsIG9wZW5hZnMsIGtlcmJlcm9zLCBpbmZy YXN0cnVjdHVyZSwgeG1vbmFkDQoNCg0KDQo= From botsch@cnf.cornell.edu Wed Oct 9 15:10:59 2013 From: botsch@cnf.cornell.edu (Dave Botsch) Date: Wed, 9 Oct 2013 10:10:59 -0400 Subject: [OpenAFS] October 2013 Newsletter is out Message-ID: <20131009141058.GN13716@cnf.cornell.edu> The October edition of the OpenAFS Newsletter is out. Peruse at: http://www.openafs.org/newsletter -- ******************************** David William Botsch Programmer/Analyst CNF Computing botsch@cnf.cornell.edu ******************************** From jm130794@gmail.com Fri Oct 11 11:10:34 2013 From: jm130794@gmail.com (Jean-Marc Choulet) Date: Fri, 11 Oct 2013 12:10:34 +0200 Subject: [OpenAFS] Change IP of my AFS DB Server Message-ID: <5257CE9A.7030904@gmail.com> Hello, We have two AFS database servers with IP addresses 172.20.33.45 and 172.20.33.46. Can we change IP addresses of these servers to a and b without problems ? We are going to update all ours client stations of course. Regards, Jean-Marc From adeason@sinenomine.net Fri Oct 11 16:27:35 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Fri, 11 Oct 2013 10:27:35 -0500 Subject: [OpenAFS] Re: Change IP of my AFS DB Server References: <5257CE9A.7030904@gmail.com> Message-ID: <20131011102735.6729a9d6.adeason@sinenomine.net> On Fri, 11 Oct 2013 12:10:34 +0200 Jean-Marc Choulet wrote: > We have two AFS database servers with IP addresses 172.20.33.45 and Just in case you don't know, it's usually recommended to have at least 3 dbservers if you have more than 1. Having 3 dbservers is the minimum number of sites so that you can operate will full functionality if any one machine goes down. With only two servers, if your 172.20.33.45 site goes down, you won't be able to make changes to the databsases. It's not a big deal or anything, just mentioning it in passing. > 172.20.33.46. Can we change IP addresses of these servers to a and b > without problems ? If you don't care about a little downtime, then yes, certainly. The simplest way to do that is to bring down the servers, change the server-side CellServDB to point at the new addresses, update all of the clients, and bring up the servers with the new IP addresses. If you have the old IPs referenced anywhere else, like in NetInfo/NetRestrict files or in IP ACLs or something, you'd of course want to change those, too. If it takes a long time to move the machines to IPs a and b, and you want things to stay available, the above won't work, since the dbservers will both be down while moving. Keeping the cell at least somewhat available during such a move is more involved, but also possible. > We are going to update all ours client stations of course. Talking specifically about Unix clients: Note that a client must be restarted to notice changes in the client CellServDB. If you want to notify a running client of changes without restarting it, you can run the 'fs newcell' command to tell the client about the new dbserver info. -- Andrew Deason adeason@sinenomine.net From stephan.wiesand@desy.de Fri Oct 11 16:36:52 2013 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Fri, 11 Oct 2013 17:36:52 +0200 Subject: [OpenAFS] No buffer space available In-Reply-To: <20130723114053.ea104ee2.adeason@sinenomine.net> References: <20130723111115.GA25256@nct-3.MPA-Garching.MPG.DE> <20130723114053.ea104ee2.adeason@sinenomine.net> Message-ID: On Jul 23, 2013, at 18:40 , Andrew Deason = wrote: > On Tue, 23 Jul 2013 13:11:17 +0200 > Hans-Werner Paulsen wrote: >=20 >> sometimes creating a file (using different programs) fails with the >> error message "No buffer space available". This is on amd64_linux26 >> with OpenAFS 1.6.2 (both client and server). Any idea? >=20 > I don't see anywhere we'd be generating that error code (ENOBUFS), and = I > can't see how it would show up that way if we got it back from a = socket > or something. Do you have any idea if the machine is under a lot of = load > or memory pressure, or if the directory has a lot of entries in it? To add a data point: I just encountered this while copying two rather small files for the = 1.6.5.1 release from here (~ Berlin) to PENN-CENTRAL.SRV.CS.CMU.EDU. % cp /tmp/openafs-release-* . -iv =20 `/tmp/openafs-release-fedora-1.6.5.1-1.noarch.rpm' -> = `./openafs-release-fedora-1.6.5.1-1.noarch.rpm' cp: cannot create regular file = `./openafs-release-fedora-1.6.5.1-1.noarch.rpm': No buffer space = available `/tmp/openafs-release-rhel-1.6.5.1-1.noarch.rpm' -> = `./openafs-release-rhel-1.6.5.1-1.noarch.rpm' So the first one failed. The destination file was created, but had = length 0. The very next attempt succeeded. It's the first time I ever = encountered this problem. Client is SL6.4, 2.6.32-358.18.1.el6.x86_64, = OpenAFS 1.6.5.1 (built against the -358.el6 kernel - which I know voids = my warranty ;-), disk cache on ext4. Not reproducible, nothing in the logs or the kernel message buffer. The client was not under any load and has 12 GB of free (really unused) = RAM. The server seemed not to be busy either. The only special condition = is the long distance between client and server. No showstopper, and probably very hard to track down without a = reproducer. --=20 Stephan Wiesand DESY - DV - Platanenallee 6 15732 Zeuthen, Germany From adeason@sinenomine.net Fri Oct 11 18:01:25 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Fri, 11 Oct 2013 12:01:25 -0500 Subject: [OpenAFS] Re: No buffer space available References: <20130723111115.GA25256@nct-3.MPA-Garching.MPG.DE> <20130723114053.ea104ee2.adeason@sinenomine.net> Message-ID: <20131011120125.e7c0bade.adeason@sinenomine.net> On Fri, 11 Oct 2013 17:36:52 +0200 Stephan Wiesand wrote: > > I don't see anywhere we'd be generating that error code (ENOBUFS), > > and I can't see how it would show up that way if we got it back from > > a socket or something. Do you have any idea if the machine is under > > a lot of load or memory pressure, or if the directory has a lot of > > entries in it? For some reason I never looked at the actual value of this; I thought ENOBUFS was some low-numbered errno for some reason. But it appears to be 105, which is VNOSERVICE, which means this is probably due to idle-dead brokenness. Speaking to you in the context of 1.6 maintenance: this isn't really new (though this specific manifestation might be, I'm not sure). Gerrit 8462 would help with it, and could possibly go into 1.6.6 if we want to do something about it. Actually fixing it was discussed in 8464; I just need to get around to actually implementing it sometime (none of the submitted patches in there are correct; a different solution is discussed somewhere in there). > To add a data point: > > I just encountered this while copying two rather small files for the > 1.6.5.1 release from here (~ Berlin) to PENN-CENTRAL.SRV.CS.CMU.EDU. I assume this was hanging for a little while before erroring out, yes? -- Andrew Deason adeason@sinenomine.net From stephan.wiesand@desy.de Fri Oct 11 18:29:40 2013 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Fri, 11 Oct 2013 19:29:40 +0200 Subject: [OpenAFS] Re: No buffer space available In-Reply-To: <20131011120125.e7c0bade.adeason@sinenomine.net> References: <20130723111115.GA25256@nct-3.MPA-Garching.MPG.DE> <20130723114053.ea104ee2.adeason@sinenomine.net> <20131011120125.e7c0bade.adeason@sinenomine.net> Message-ID: <264F78CC-53ED-4A0A-A93D-CCE790940C1A@desy.de> On Oct 11, 2013, at 19:01 , Andrew Deason wrote: > On Fri, 11 Oct 2013 17:36:52 +0200 > Stephan Wiesand wrote: >=20 >>> I don't see anywhere we'd be generating that error code (ENOBUFS), >>> and I can't see how it would show up that way if we got it back from >>> a socket or something. Do you have any idea if the machine is under >>> a lot of load or memory pressure, or if the directory has a lot of >>> entries in it? >=20 > For some reason I never looked at the actual value of this; I thought > ENOBUFS was some low-numbered errno for some reason. But it appears to > be 105, which is VNOSERVICE, which means this is probably due to > idle-dead brokenness. >=20 > Speaking to you in the context of 1.6 maintenance: this isn't really = new > (though this specific manifestation might be, I'm not sure). Gerrit = 8462 > would help with it, and could possibly go into 1.6.6 if we want to do > something about it. Actually fixing it was discussed in 8464; I just > need to get around to actually implementing it sometime (none of the > submitted patches in there are correct; a different solution is > discussed somewhere in there).=20 >=20 >> To add a data point: >>=20 >> I just encountered this while copying two rather small files for the >> 1.6.5.1 release from here (~ Berlin) to PENN-CENTRAL.SRV.CS.CMU.EDU. >=20 > I assume this was hanging for a little while before erroring out, yes? Sorry, I really can't tell. When you copy files around a quarter of the = globe, there are always delays. And as usual, I fired the command and = then went on to something else. I'm fairly sure it didn't hang for more = than about a minute though. --=20 Stephan Wiesand DESY -DV- Platanenenallee 6 15738 Zeuthen, Germany From adeason@sinenomine.net Fri Oct 11 19:10:17 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Fri, 11 Oct 2013 13:10:17 -0500 Subject: [OpenAFS] Re: No buffer space available References: <20130723111115.GA25256@nct-3.MPA-Garching.MPG.DE> <20130723114053.ea104ee2.adeason@sinenomine.net> <20131011120125.e7c0bade.adeason@sinenomine.net> <264F78CC-53ED-4A0A-A93D-CCE790940C1A@desy.de> Message-ID: <20131011131017.afe1b063.adeason@sinenomine.net> On Fri, 11 Oct 2013 19:29:40 +0200 Stephan Wiesand wrote: > > Speaking to you in the context of 1.6 maintenance: this isn't really > > new (though this specific manifestation might be, I'm not sure). > > Gerrit 8462 would help with it, and could possibly go into 1.6.6 if > > we want to do something about it. As has been pointed out to me, this has been in 1.6 for a while. Sorry; I thought I checked, but I was looking at the 'git log' for an older version. Same thing, though. With 8462 we retry on VNOSERVICE errors, but the CreateFile operation is not idempotent, so we can't retry it. We probably should retry CreateFile operations, and swallow an EEXIST error if it doesn't matter (file was created without O_EXCL). And/or we really shouldn't let VNOSERVICE propagate to userspace. > > I assume this was hanging for a little while before erroring out, > > yes? > > Sorry, I really can't tell. When you copy files around a quarter of > the globe, there are always delays. And as usual, I fired the command > and then went on to something else. I'm fairly sure it didn't hang for > more than about a minute though. "About a minute" I think is enough for this. -- Andrew Deason adeason@sinenomine.net From dirk.heinrichs@altum.de Sat Oct 12 08:17:42 2013 From: dirk.heinrichs@altum.de (Dirk Heinrichs) Date: Sat, 12 Oct 2013 09:17:42 +0200 Subject: [OpenAFS] Re: [OpenAFS-announce] OpenAFS 1.6.5.1 release available In-Reply-To: References: Message-ID: <4946311.Qc48NFmalA@moria> --nextPart4111752.NDj3dxrO2s Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Am Freitag 11 Oktober 2013, 20:32:50 schrieb Stephan Wiesand: > can be built against kernels without keyring support, What's the impact of this? Isn't keyring support needed for PAGs? Bye... Dirk -- Dirk Heinrichs Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913 GPG Public Key C2E467BB | Jabber: dirk.heinrichs@altum.de --nextPart4111752.NDj3dxrO2s Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iD8DBQBSWPeW8NVtnsLkZ7sRAuTIAJ4g6DVsob6s0mswsLqfGIDx5acB4ACdH1jl bwGIOh5cj5OAtqzNEKfvdDI= =wOen -----END PGP SIGNATURE----- --nextPart4111752.NDj3dxrO2s-- From hanke@rzg.mpg.de Sat Oct 12 11:20:41 2013 From: hanke@rzg.mpg.de (Christof Hanke) Date: Sat, 12 Oct 2013 12:20:41 +0200 Subject: [OpenAFS] Re: [OpenAFS-announce] OpenAFS 1.6.5.1 release available In-Reply-To: <4946311.Qc48NFmalA@moria> References: <4946311.Qc48NFmalA@moria> Message-ID: <20131012122041.0000145e@unknown> On Sat, 12 Oct 2013 09:17:42 +0200 Dirk Heinrichs wrote: > Am Freitag 11 Oktober 2013, 20:32:50 schrieb Stephan Wiesand: > > > can be built against kernels without keyring support, > > What's the impact of this? Isn't keyring support needed for PAGs? > PAGs existed before keyring support, they were implemented by two high-numbered group-ids given to the user in that shell. The afs-client could differentiate between PAGs by these gids. The original implementation now compiles again. Ciao, Christof From stephen@physics.unc.edu Sat Oct 12 17:51:06 2013 From: stephen@physics.unc.edu (stephen@physics.unc.edu) Date: Sat, 12 Oct 2013 12:51:06 -0400 (EDT) Subject: [OpenAFS] Windows and Mac auto-update? Message-ID: What's the current thinking (plans?) regarding auto-update functionality for the Windows and Mac OpenAFS client packages? The ability to check and optionally download & install new versions seems pretty basic. Maybe something like some popular browsers and other non-Microsoft-update software already provide? I think this would be a desirable feature to add. Cheers, Stephen From jaltman@your-file-system.com Sat Oct 12 23:22:10 2013 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Sat, 12 Oct 2013 18:22:10 -0400 Subject: [OpenAFS] Windows and Mac auto-update? In-Reply-To: References: Message-ID: <5259CB92.1050509@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms070104030007000209030506 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stephan, There are no plans to do so that I am aware of. Auto-update functionality raises a variety of issues: * Privacy - Call home capabilities provide someone the ability to monitor where the software is installed. * Trust - Who do you trust to provide the software? How will it be verified? * Support - Is the entity distributing the software going to support the end user if a problem occurs? * Cost - Who is going to pay to run the servers and develop the update service? Four or five years ago Secure Endpoints described an update service that was implemented based upon Google's Project Omaha. In the end the effort was abandoned because there was insufficient interest from organizations willing to subscribe to the service. On Windows in particular there are additional issues related to the need to distribute and update multiple packages in a synchronized manner: * 64-bit or 32-bit OpenAFS MSI * 32-bit Tools OpenAFS MSI on 64-bit systems * A Kerberos distribution * A credentials manager (Network Identity Manager or other) * Cell / Realm / Organization Configuration packages As a file system an update when applied disables access to AFS until the next reboot. If this is performed in an automated fashion while the user is running other applications it can result in data loss. At the moment OpenAFS packages for Windows are signed by Your File System Inc. OSX packages are not signed at all. Signing costs money both for access to the appropriate signing certificates approved by or provided by the OS vendor and for the Professional Liability Insurance that should be held by any entity that is issuing signed binaries. In theory this is a service that the OpenAFS Foundation can provide to the community once it figures out its business plan, fund raising strategy and governance model. In the meantime I do not expect to see a free update service be incorporated into the OSX and Windows distributions. Jeffrey Altman P.S. - You might ask why Your File System Inc. signs the Windows installers but does not sign the OSX installers. In the absence of a legal entity representing OpenAFS the choice effectively was between YFSI signing the packages and the file system drivers with its certificate that is cross-signed by Microsoft or requiring that all users of OpenAFS on Windows configure their systems to run in developer mode which disables driver validation checks. The latter was an unacceptable option since it would have put the vast majority of end users systems running OpenAFS at risk. In my former capacity as OpenAFS Elder I had a moral obligation to maintain the viability of OpenAFS for the community. I permitted that obligation to pursuade myself wearing the CEO hat of Your File System Inc. to accept the on-going costs and associated liabilities. There is no requirement for OSX that kernel extensions be signed by a certificate issued to by Apple to an approved organization. At least not yet. Although I suspect that OSX Maverick will be the last release on which kernel extensions will be loadable without signature. In Maverick end users are presented with a rather scary dialog for unsigned kernel extensions. On 10/12/2013 12:51 PM, stephen@physics.unc.edu wrote: > What's the current thinking (plans?) regarding auto-update functionalit= y > for the Windows and Mac OpenAFS client packages? >=20 > The ability to check and optionally download & install new versions > seems pretty basic. Maybe something like some popular browsers and othe= r > non-Microsoft-update software already provide? I think this would be a > desirable feature to add. >=20 > Cheers, > Stephen >=20 > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info --------------ms070104030007000209030506 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhAl sq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc2MTA4NjMxMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChjpVdVk6XeKFff4To xGglVcP3FVY95LfwfBUKbQKppRYgfKBFW1RIEG+KXpc3IGOOTUX0Lg1xaukRwuoqv/pqRMNK JabXcr1RFuCFg9xfcmP5Z+65qQ+IRxYCKdcNfu3GdS7rMOY57+VLU7aZnnMgnt0oE42awze8 gYQSJsdjZKKZS9DBnzxJYfzqhIw7txoMdV7rwPAZm5yujsqI/eWuZPZ+qZ+8GTsnHJzZNvc6 KrDGU6aVfknM+qf92hXA2VXvmtf1B17BBbGX6Hgat71Ufw5oXFly6/Vt+e5mKIozXytw8qPX NllsG89ITVzn0OovcpcSRFBrXanzVn7JVj33AgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFMC1SMuRefXyNAwkZM+Lgu7iJ6nFMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHVBsY+l21fY0twxzNnO0QbadbRT4n7k3rYfOMbP noBDkYQx5lcrYn19f7e+ADMPdW/MY2ZjFM76aiRgiTo2IjMB7z4vyX6hfGJKTIHX9loDW0H2 z2o0jYqXDQtXx9A/gfMtVh9J+8O5IuCPsVtXgI4p6kRQHN+Er2Rzu1I4BILxE9HsDb/ruX6p NXZSUQ2AcMP87ZVfz+reumMpJgWWAoiQWJCgp+qZ2c2AG+yV+FstiMpxIj/qB9+BrFRuam8d IGbH0tIS2tyc7pgit8Pid2Zv7HGT2NFu69INsKIyqGImhMVuOUaCq/kNi3Z+6R5Hm3ljift8 ZF52Kiq4whe8KlcxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCECWyrbsULgHrdnyrUnPHH4IwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMDEyMjIyMjEwWjAjBgkqhkiG9w0BCQQxFgQUoP1sAEYwSV2HGyFTF22+HRA8IAowbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQJbKtuxQuAet2fKtSc8cfgjCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhAlsq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBAQUABIIB AB4Kee2w1Ux6mGb1A3VuTUm0IoNiG2+NEJGHX5m8MRn6T+QTK/+OuWP6K1xMxZ7qs6lfNi7p jgxU6L1mC6jW75Y95uncmePzd1qyPq4A3KgePzW4/EcFlNwkHjeToCwKBqgV1DtX5E7AuFTg IdgPnL9YJQX2hZm32y6qL02VdRlfST3o8t6S3UOVy06gl29jTFcBKJwkP6NaTW5Ml35XjF/v dL+CWnWrbDcRQw2iYMQC/dSDl2DiQ7NEZlaxmq4pwLlZIXehKpL9+U36DUG0iFN+f2aKIbDR 7F6P/XwO3DR9L2aT++xotFym55Ow4RiE2KDnz6z6Au0nOafn8pVTZekAAAAAAAA= --------------ms070104030007000209030506-- From chanlists@googlemail.com Mon Oct 14 14:33:48 2013 From: chanlists@googlemail.com (Christian) Date: Mon, 14 Oct 2013 15:33:48 +0200 Subject: [OpenAFS] not enough space in target directory In-Reply-To: <524F5AD5.2070006@your-file-system.com> References: <524F4305.4030102@googlemail.com> <524F5AD5.2070006@your-file-system.com> Message-ID: <525BF2BC.3000904@googlemail.com> Jeffrey, thanks for the hint. I had been blaming this on myself, suspecting something was not correctly configured. Now I have a really dumb question: is this one of the things you can only do with a support contract? Or via connect.microsoft.com? Is there any additional information I should submit? We are a University in Germany and run Windows 7 Enterprise... Best, Christian Am 05.10.2013 02:18, schrieb Jeffrey Altman: > File a bug report with Microsoft if the problem is experienced when > using the explorer shell or applications relying upon the shell api for > file access. > > This is a known bug in the explorer shell and Microsoft has been working > on it for more than six months. As with all Windows bugs, a fix is > prioritized based upon the number of complaints received from paying > support customers. > > Jeffrey Altman > > On 10/4/2013 6:36 PM, Christian wrote: >> All, >> >> we are seeing some weird issues with the windows client (1.7.26, but hat >> also seen that with previous 1.7 versions). Often, when attempting to >> write data, my users get a popup box complaining about insufficient >> space in the target directory. In those cases, writing the data to the >> RW path (.cell.name) instead works just fine. Note that the volumes >> which are being accessed in those cases do NOT have RO replicas, just >> some of the volumes from which they are mounted. Write access just fails >> intermittently when accessed through a path which contains OTHER >> replicated volumes. >> >> So, for example, say that the volume "users" containing the mount points >> for the individual user volumes is replicated. Then write access to >> /afs/our.cell/users/joe.user will fail intermittently, while writing to >> /afs/.our.cell/users/joe.user always works. We use dynroot and SRV records. >> >> I have read the debugging instructions, but I am a little unsure about >> how we should proceed here. What should I do? Try fs trace? >> >> Thanks, >> >> Christian >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info > From jaltman@secure-endpoints.com Mon Oct 14 14:59:38 2013 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 14 Oct 2013 09:59:38 -0400 Subject: [OpenAFS] not enough space in target directory In-Reply-To: <525BF2BC.3000904@googlemail.com> References: <524F4305.4030102@googlemail.com> <524F5AD5.2070006@your-file-system.com> <525BF2BC.3000904@googlemail.com> Message-ID: <525BF8CA.9020602@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms070608050904030704010303 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Christian, Feel free to make noise wherever you wish but the reality is that when Microsoft has a the choice to make between developers spending time on the Shell and addressing bugs with its own tools (SkyDrive, ReFS, etc) or those of third party products, Microsoft is going to focus on its own stuff unless an entity (or an effected community) is paying them sufficient money to make it worthwhile. In the end it requires multiple paid support contract reports to raise the profile of the bug enough that it will be fixed. Jeffrey Altman On 10/14/2013 9:33 AM, Christian wrote: > Jeffrey, >=20 > thanks for the hint. I had been blaming this on myself, suspecting > something was not correctly configured. >=20 > Now I have a really dumb question: is this one of the things you can > only do with a support contract? Or via connect.microsoft.com? Is there= > any additional information I should submit? We are a University in > Germany and run Windows 7 Enterprise... >=20 > Best, >=20 > Christian >=20 > Am 05.10.2013 02:18, schrieb Jeffrey Altman: >> File a bug report with Microsoft if the problem is experienced when >> using the explorer shell or applications relying upon the shell api fo= r >> file access. >> >> This is a known bug in the explorer shell and Microsoft has been worki= ng >> on it for more than six months. As with all Windows bugs, a fix is >> prioritized based upon the number of complaints received from paying >> support customers. >> >> Jeffrey Altman >> >> On 10/4/2013 6:36 PM, Christian wrote: >>> All, >>> >>> we are seeing some weird issues with the windows client (1.7.26, but = hat >>> also seen that with previous 1.7 versions). Often, when attempting to= >>> write data, my users get a popup box complaining about insufficient >>> space in the target directory. In those cases, writing the data to th= e >>> RW path (.cell.name) instead works just fine. Note that the volumes >>> which are being accessed in those cases do NOT have RO replicas, just= >>> some of the volumes from which they are mounted. Write access just fa= ils >>> intermittently when accessed through a path which contains OTHER >>> replicated volumes. >>> >>> So, for example, say that the volume "users" containing the mount poi= nts >>> for the individual user volumes is replicated. Then write access to >>> /afs/our.cell/users/joe.user will fail intermittently, while writing = to >>> /afs/.our.cell/users/joe.user always works. We use dynroot and SRV re= cords. >>> >>> I have read the debugging instructions, but I am a little unsure abou= t >>> how we should proceed here. What should I do? Try fs trace? >>> >>> Thanks, >>> >>> Christian >>> _______________________________________________ >>> OpenAFS-info mailing list >>> OpenAFS-info@openafs.org >>> https://lists.openafs.org/mailman/listinfo/openafs-info >> >=20 > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info >=20 --------------ms070608050904030704010303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhBD 9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc1NTk5Njg2MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDGK4TaaHgHBkEIqx9 xgS06g4a1HdPcm5Lspe5OkYgSdxRiX84qp6msq+DWu1yQqmAxoS0a70Ctp99UgojGzKn2F8g nIEEFe0bOMbye736C4LWashMhB8iRXbNmfQHJU5mrLoeghHUnTsmRZsFOagpwZgHAC4ZKITq 87yJvVGGfIAS77EuoZx3PlQCTeq6xdmas4BzLxb+DF3vYkRvtLOnh3ixsEu1Js1QjIcrBIA8 bZp0fU9SZWTU1MSHheYykKhBDBNurQpYEJ1VkJGvgITfcRUUfifxe7HbMlyDHJQtzn9mpocE xiF1Vtzthcw6BhdqDhw4IvhWin+CY1Q6XOoHAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFLNBzIZb/xB6K+oeDwfBVLaB3qbUMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHgy34Smu5krf/eRWcjkEwnLYWZSXqo8T6/FBeSS TUE/E7DB6k27NUate7u5keQnrWmohWErxU/ona1WVHIdvSmK1Ow4IbUM9Pl4TKsDmBezDd8U eQU6q7KtkQuooeO/OgaJ49NXq/UgqoTXi72sAVpiPtOqgRJ4m+oO6Hv9OF5co49z5zMRFI6A SHEVi/41s8iYxlv++2ghtDDIA6vLS3MhGogh0wXFszn/dcWeluOkQZR9glfLr7Y853v3OBoh u1k40Q3NpnTl9ZgODP6Gh/hD08fXmBka0/p9rFRhR1NQBQg0WQbwS0ScFiECviWt9TbN2k/e GLwmOQD4a4Md7uoxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEP2DS/S5ZSBTt+yrappszwwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMDE0MTM1OTM4WjAjBgkqhkiG9w0BCQQxFgQUAz+KajmxmfybvTuobTj1UkuiglcwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQQ/YNL9LllIFO37KtqmmzPDCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhBD9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBAQUABIIB AFwxYsHcB8Qmn06BtljqEhmXOkTeuwvHQpLJNuicoHCuEYkB4BNoA9i3tO7OKVKThVgZ6CUs fOIIzIcRsGLBGlEgi7p5swxZfb3v336hgGu0AzXCoB6MUW3G8FnqRN3ZIcGrA/VsAbrHsmFO pPqUwGB431xAYv00P37lw5wwnka5khD4KemKfJf4EQA6ji4MhsnCH05qSww2Tn3b96becHv9 ua3VwS6UfsAyZyCZrZMCTLX+UBZr3G2eOPd4RaSlSN7jgQW720+bilVHO/Hb6arrzvNe1GAG c3A7KIIHJf8vLwgMrFBDLTnGAtKE/1Gqan9AYpi9+udmg8cRY8Bz7dgAAAAAAAA= --------------ms070608050904030704010303-- From chanlists@googlemail.com Mon Oct 14 15:18:07 2013 From: chanlists@googlemail.com (Christian) Date: Mon, 14 Oct 2013 16:18:07 +0200 Subject: [OpenAFS] not enough space in target directory In-Reply-To: <525BF8CA.9020602@secure-endpoints.com> References: <524F4305.4030102@googlemail.com> <524F5AD5.2070006@your-file-system.com> <525BF2BC.3000904@googlemail.com> <525BF8CA.9020602@secure-endpoints.com> Message-ID: <525BFD1F.9070008@googlemail.com> Jeffrey, Hm. Sorry if I wasn't clear. I am not sure if we have a support contract or not. I am just a part-time sysadmin at a University institute. My main job is running a research group in physics. I hadn't been able to find out from the central IT people at the University level whether we have a support contract for Windows :-( so we probably don't... Is there a way to find out whether one has a support contract? Christian Am 14.10.2013 15:59, schrieb Jeffrey Altman: > Christian, > > Feel free to make noise wherever you wish but the reality is that when > Microsoft has a the choice to make between developers spending time on > the Shell and addressing bugs with its own tools (SkyDrive, ReFS, etc) > or those of third party products, Microsoft is going to focus on its own > stuff unless an entity (or an effected community) is paying them > sufficient money to make it worthwhile. In the end it requires multiple > paid support contract reports to raise the profile of the bug enough > that it will be fixed. > > Jeffrey Altman > > On 10/14/2013 9:33 AM, Christian wrote: >> Jeffrey, >> >> thanks for the hint. I had been blaming this on myself, suspecting >> something was not correctly configured. >> >> Now I have a really dumb question: is this one of the things you can >> only do with a support contract? Or via connect.microsoft.com? Is there >> any additional information I should submit? We are a University in >> Germany and run Windows 7 Enterprise... >> >> Best, >> >> Christian >> >> Am 05.10.2013 02:18, schrieb Jeffrey Altman: >>> File a bug report with Microsoft if the problem is experienced when >>> using the explorer shell or applications relying upon the shell api for >>> file access. >>> >>> This is a known bug in the explorer shell and Microsoft has been working >>> on it for more than six months. As with all Windows bugs, a fix is >>> prioritized based upon the number of complaints received from paying >>> support customers. >>> >>> Jeffrey Altman >>> >>> On 10/4/2013 6:36 PM, Christian wrote: >>>> All, >>>> >>>> we are seeing some weird issues with the windows client (1.7.26, but hat >>>> also seen that with previous 1.7 versions). Often, when attempting to >>>> write data, my users get a popup box complaining about insufficient >>>> space in the target directory. In those cases, writing the data to the >>>> RW path (.cell.name) instead works just fine. Note that the volumes >>>> which are being accessed in those cases do NOT have RO replicas, just >>>> some of the volumes from which they are mounted. Write access just fails >>>> intermittently when accessed through a path which contains OTHER >>>> replicated volumes. >>>> >>>> So, for example, say that the volume "users" containing the mount points >>>> for the individual user volumes is replicated. Then write access to >>>> /afs/our.cell/users/joe.user will fail intermittently, while writing to >>>> /afs/.our.cell/users/joe.user always works. We use dynroot and SRV records. >>>> >>>> I have read the debugging instructions, but I am a little unsure about >>>> how we should proceed here. What should I do? Try fs trace? >>>> >>>> Thanks, >>>> >>>> Christian >>>> _______________________________________________ >>>> OpenAFS-info mailing list >>>> OpenAFS-info@openafs.org >>>> https://lists.openafs.org/mailman/listinfo/openafs-info >>> >> >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info >> > From jhutz@cmu.edu Mon Oct 14 17:12:45 2013 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Mon, 14 Oct 2013 12:12:45 -0400 Subject: [OpenAFS] Windows and Mac auto-update? In-Reply-To: References: Message-ID: <1381767165.3095.4.camel@destiny.pc.cs.cmu.edu> On Sat, 2013-10-12 at 12:51 -0400, stephen@physics.unc.edu wrote: > What's the current thinking (plans?) regarding auto-update functionality > for the Windows and Mac OpenAFS client packages? No thanks. The infrastructure from which these software packages are distributed is operated on a volunteer basis using donated equipment, facilities, and network service. Such an update mechanism would likely result in a significant increase in load which we are not prepared to handle. Unlike major operating systems and web browsers, OpenAFS does not release security-critical updates every few weeks. -- Jeff From wangshuaijie@gmail.com Tue Oct 15 08:03:27 2013 From: wangshuaijie@gmail.com (shuaijie wang) Date: Tue, 15 Oct 2013 15:03:27 +0800 Subject: [OpenAFS] What is the meaning of exit code 4 of aklog Message-ID: --001a11c2dc3c711f1a04e8c22e3d Content-Type: text/plain; charset=ISO-8859-1 Hi all, I wrote a program that forks a child and execs aklog binary, sometimes aklog exit with status code, 4, and AFS token is not set up correctly. Does anyone know what is the meaning of this exit code 4 of aklog binary? Thanks. --001a11c2dc3c711f1a04e8c22e3d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi all,

I wrote a program that= forks a child and execs aklog binary, sometimes aklog exit with status cod= e, 4, and AFS token is not set up correctly.

Does anyone know what= is the meaning of this exit code 4 of aklog binary?

Thanks.

--001a11c2dc3c711f1a04e8c22e3d-- From jaltman@secure-endpoints.com Tue Oct 15 08:11:43 2013 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Tue, 15 Oct 2013 03:11:43 -0400 Subject: [OpenAFS] What is the meaning of exit code 4 of aklog In-Reply-To: References: Message-ID: <525CEAAF.3080703@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms080705040606020209050507 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/15/2013 3:03 AM, shuaijie wang wrote: > Hi all, >=20 > I wrote a program that forks a child and execs aklog binary, sometimes > aklog exit with status code, 4, and AFS token is not set up correctly. > Does anyone know what is the meaning of this exit code 4 of aklog binar= y? >=20 > Thanks. It means that aklog failed due to a Kerberos failure 1. Cannot obtain the user realm 2. Cannot obtain a service ticket for AFS 3. The krb524 service failed --------------ms080705040606020209050507 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhBD 9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc1NTk5Njg2MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDGK4TaaHgHBkEIqx9 xgS06g4a1HdPcm5Lspe5OkYgSdxRiX84qp6msq+DWu1yQqmAxoS0a70Ctp99UgojGzKn2F8g nIEEFe0bOMbye736C4LWashMhB8iRXbNmfQHJU5mrLoeghHUnTsmRZsFOagpwZgHAC4ZKITq 87yJvVGGfIAS77EuoZx3PlQCTeq6xdmas4BzLxb+DF3vYkRvtLOnh3ixsEu1Js1QjIcrBIA8 bZp0fU9SZWTU1MSHheYykKhBDBNurQpYEJ1VkJGvgITfcRUUfifxe7HbMlyDHJQtzn9mpocE xiF1Vtzthcw6BhdqDhw4IvhWin+CY1Q6XOoHAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFLNBzIZb/xB6K+oeDwfBVLaB3qbUMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHgy34Smu5krf/eRWcjkEwnLYWZSXqo8T6/FBeSS TUE/E7DB6k27NUate7u5keQnrWmohWErxU/ona1WVHIdvSmK1Ow4IbUM9Pl4TKsDmBezDd8U eQU6q7KtkQuooeO/OgaJ49NXq/UgqoTXi72sAVpiPtOqgRJ4m+oO6Hv9OF5co49z5zMRFI6A SHEVi/41s8iYxlv++2ghtDDIA6vLS3MhGogh0wXFszn/dcWeluOkQZR9glfLr7Y853v3OBoh u1k40Q3NpnTl9ZgODP6Gh/hD08fXmBka0/p9rFRhR1NQBQg0WQbwS0ScFiECviWt9TbN2k/e GLwmOQD4a4Md7uoxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEP2DS/S5ZSBTt+yrappszwwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMDE1MDcxMTQzWjAjBgkqhkiG9w0BCQQxFgQULWbPlbUJGlkYny3VJPzuvq3MScwwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQQ/YNL9LllIFO37KtqmmzPDCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhBD9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBAQUABIIB AI9kXIcOdUsYx+PPhKTwqVsCLmQVgqdo3+XOGfsBVtlCzkflkhHqei1Q/qTu4nmX7d0PZmj3 0Hnf94RSCZKT7YbFgerDpjBIB+YrJFEdZ3LqOeh/zeLdvfvYUNPqCdt3xAWqyUAFYhzONZ6y hk8G3A3+xyZVQSNuYo2DA1mMkcWGpbIMcdF/5m39acloAwhfylRWopWX30JquKnIAgqOS0ar q93G+dLnetN64bunHyj1VhRfSpAQtcvLgkxDttSFo70tMOgYdvDiulSTsU6g3FhaMd5ytShz l8KZk6tVEzwjU8Ci7qEWhwYXunhf8jc48UG1zwaQ2gGe4nxO68Ha3gAAAAAAAAA= --------------ms080705040606020209050507-- From nicolas-ml@deffayet.com Tue Oct 15 12:37:50 2013 From: nicolas-ml@deffayet.com (Nicolas DEFFAYET) Date: Tue, 15 Oct 2013 11:37:50 +0000 Subject: [OpenAFS] RClone - Volume already exists Message-ID: <1381837070.6906.4.camel@srv31.corp.novso.com> Hello, I have troubles with some volumes during the vos release: # vos release backups -verbose -localauth backups RWrite: 536870926 ROnly: 536870936 Backup: 536870946 RClone: 536870936 number of sites -> 2 server primary partition /vicepa RW Site -- New release server secondary partition /vicepa RO Site -- Old release This is a complete release of volume 536870926 Cloning RW volume 536870926 to temporary RO...Failed to clone the RW volume 536870926 Volume already exists Error in vos release command. Volume already exists # Ted have reported a problem of RClone (http://lists.openafs.org/pipermail/openafs-info/2012-May/038225.html), the feedback from Andrew was: "That usually appears after an interrupted volume release. It should stop being displayed after you release the volume successfully, or delete it, etc." I have same problem but how fix it without using vos delsite and vos addsite and re-download the full volume from primary server to secondary server ? The problem have appeared after the reboot of secondary server and only few volumes have this problem of RClone generating the error "Volume already exists" during release. According the documentation from IBM: "If necessary, the Volume Server creates a temporary copy (a clone) of the read/write source called the ReleaseClone (see the following discussion of when the Volume Server does or does not create a new ReleaseClone.) It assigns the ReleaseClone its own volume ID number, which the VL Server records in the RClone field of the source volume's VLDB entry." "To override the default behavior, forcing the Volume Server to create and release a new ReleaseClone to the read-only sites, include the -f flag. This is appropriate if, for example, the data at the read/write site has changed since the existing ReleaseClone was created during the previous release operation." -> -f flags don't fix the issue, same error "Volume already exists" It seem that the flag doesn't exist with OpenAFS and so no effect when trying to use it. How remove this temporary copy ? I have tried to salvage the volume but it don't fix the issue, same error "Volume already exists" # bos salvage -server 127.0.0.1 -partition /vicepa -volume backups -verbose -localauth # vos exa backups -verbose -localauth Fetching VLDB entry for 536870926 .. done Getting volume listing from the server primary .. done backups 536870926 RW 62387494 K On-line primary /vicepa RWrite 536870926 ROnly 536870936 Backup 536870946 MaxQuota 0 K Creation Tue Sep 11 16:28:18 2007 Copy Tue Sep 11 16:13:44 2007 Backup Tue Oct 15 06:25:02 2013 Last Access Mon Oct 14 23:37:41 2013 Last Update Mon Oct 14 14:53:53 2013 0 accesses in the past day (i.e., vnode references) RWrite: 536870926 ROnly: 536870936 Backup: 536870946 RClone: 536870936 number of sites -> 2 server primary partition /vicepa RW Site -- New release server secondary partition /vicepa RO Site -- Old release # # vos listvldb -verbose -localauth VLDB entries for all servers archives RWrite: 536870925 ROnly: 536870935 Backup: 536870945 number of sites -> 2 server primary partition /vicepa RW Site server secondary partition /vicepa RO Site backups RWrite: 536870926 ROnly: 536870936 Backup: 536870946 RClone: 536870936 number of sites -> 2 server primary partition /vicepa RW Site -- New release server secondary partition /vicepa RO Site -- Old release # # vos listvol -server primary -verbose -localauth Total number of volumes on server primary partition /vicepa: 28 archives 536870925 RW 55518591 K On-line archives.backup 536870945 BK 55518591 K On-line backups 536870926 RW 62387494 K On-line backups.backup 536870946 BK 62387494 K On-line [...] # # vos listvol -server secondary -verbose -localauth Total number of volumes on server secondary partition /vicepa: 14 archives.readonly 536870935 RO 55518591 K On-line backups.readonly 536870936 RO 65102879 K On-line [...] # Thanks Best Regards, -- Nicolas DEFFAYET From ballbery@sinenomine.net Tue Oct 15 13:36:43 2013 From: ballbery@sinenomine.net (brandon s allbery kf8nh) Date: Tue, 15 Oct 2013 08:36:43 -0400 Subject: [OpenAFS] What is the meaning of exit code 4 of aklog In-Reply-To: References: Message-ID: <1378275e-3b1f-4af6-ad25-8b1745e56ae0@email.android.com> ------37D947IGZCR8SWG8JRAYJM0QRFR4OC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The exit code is only of very limited use; if you're having problems with= aklog, use aklog -d to debug. shuaijie wang wrote: >Hi all, > >I wrote a program that forks a child and execs aklog binary, sometimes >aklog exit with status code, 4, and AFS token is not set up correctly. >Does anyone know what is the meaning of this exit code 4 of aklog >binary? > >Thanks. --=20 Sent from my Android device with K-9 Mail. Please excuse my brevity. ------37D947IGZCR8SWG8JRAYJM0QRFR4OC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable The exit code is only of very limited use= ; if you're having problems with aklog, use aklog -d to debug.

shuaijie wang <wangshuaijie@gmail.com> = wrote:

Hi all,

I wrote a progra= m that forks a child and execs aklog binary, sometimes aklog exit with st= atus code, 4, and AFS token is not set up correctly.
Does anyo= ne know what is the meaning of this exit code 4 of aklog binary?

Thanks.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity. ------37D947IGZCR8SWG8JRAYJM0QRFR4OC-- From adeason@sinenomine.net Tue Oct 15 15:08:25 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Tue, 15 Oct 2013 10:08:25 -0400 Subject: [OpenAFS] Re: RClone - Volume already exists References: <1381837070.6906.4.camel@srv31.corp.novso.com> Message-ID: <20131015100825.47410db7.adeason@sinenomine.net> On Tue, 15 Oct 2013 11:37:50 +0000 Nicolas DEFFAYET wrote: > I have troubles with some volumes during the vos release: > # vos release backups -verbose -localauth What version of OpenAFS is 'vos'? What version is the volserver? > backups > RWrite: 536870926 ROnly: 536870936 Backup: 536870946 > RClone: 536870936 > number of sites -> 2 > server primary partition /vicepa RW Site -- New release > server secondary partition /vicepa RO Site -- Old release > This is a complete release of volume 536870926 > Cloning RW volume 536870926 to temporary RO...Failed to clone the RW > volume 536870926 > Volume already exists > Error in vos release command. > Volume already exists What's happening here is that the volserver said "volume 536870936 doesn't exist", and when we tried to clone to volume 536870936, the volserver said "you can't do that, because 536870936 already exists". At least, that is what it means with newer versions, I'm not sure if various older versions are in play. So of course, that's a little confusing. Can you run on the 'primary': # ls -l /vicepa/V0536870936.vol # volinfo /vicepa 536870936 volinfo may be in /usr/afs/bin, if you can't find it. And can you look in VolserLog and FileLog on "primary" to see if new messages appear when you try to perform the release? Can you try salvaging the volume 536870926 on "primary", and provide what SalvageLog says? (or SalsrvLog if you are running DAFS) > Ted have reported a problem of RClone > (http://lists.openafs.org/pipermail/openafs-info/2012-May/038225.html), > the feedback from Andrew was: > > "That usually appears after an interrupted volume release. It should > stop being displayed after you release the volume successfully, or > delete it, etc." I don't think he was asking about an issue with it (unless there were further emails involving an issue; I'm just skimming that), he was just asking what the RClone field means / why it's there. So that explanaiton is about the RClone field appearing, not about an error. > -> -f flags don't fix the issue, same error "Volume already exists" It > seem that the flag doesn't exist with OpenAFS and so no effect when > trying to use it. It certainly does exist in OpenAFS; if that option didn't exist, you'd get an error that the option doesn't exist :) It just doesn't help with this issue, because we are failing before -f/-force makes a difference. -- Andrew Deason adeason@sinenomine.net From jackhill@jackhill.us Tue Oct 15 17:58:51 2013 From: jackhill@jackhill.us (Jack Hill) Date: Tue, 15 Oct 2013 12:58:51 -0400 (EDT) Subject: [OpenAFS] not enough space in target directory In-Reply-To: <524F5AD5.2070006@your-file-system.com> References: <524F4305.4030102@googlemail.com> <524F5AD5.2070006@your-file-system.com> Message-ID: On Fri, 4 Oct 2013, Jeffrey Altman wrote: > File a bug report with Microsoft if the problem is experienced when > using the explorer shell or applications relying upon the shell api for > file access. > > This is a known bug in the explorer shell and Microsoft has been working > on it for more than six months. As with all Windows bugs, a fix is > prioritized based upon the number of complaints received from paying > support customers. > > Jeffrey Altman Jeffrey, I believe that one of my users has encountered this bug (unfortunately, we do not have a support contract), but it is happening very infrequently: I only know of two occurrences from one client machine in the past several months. Can you expand on what the symptoms of the bug are and how to confirm that we are suffering from it? Will all volumes be affected if accessed via a path that traverses a replicated root.cell? Also, since it appears that we won't be able to get it fixed, what work-arounds are there (I can think of: don't use Windows, use a different file manager (but this won't help applications shat use the shell API), and always access volumes via the RW path/use replication sparingly.)? Best, Jack From i.crowther@gmail.com Wed Oct 16 00:07:05 2013 From: i.crowther@gmail.com (Ian Crowther) Date: Wed, 16 Oct 2013 00:07:05 +0100 Subject: [OpenAFS] not enough space in target directory In-Reply-To: References: <524F4305.4030102@googlemail.com> <524F5AD5.2070006@your-file-system.com> Message-ID: > I believe that one of my users has encountered this bug (unfortunately, we > do not have a support contract), but it is happening very infrequently: I > only know of two occurrences from one client machine in the past several > months. Can you expand on what the symptoms of the bug are and how to > confirm that we are suffering from it? Will all volumes be affected if > accessed via a path that traverses a replicated root.cell? > > Also, since it appears that we won't be able to get it fixed, what > work-arounds are there (I can think of: don't use Windows, use a different > file manager (but this won't help applications shat use the shell API), and > always access volumes via the RW path/use replication sparingly.)? I'm assuming that this is the problem that I suffered. I encountered it frequently when copying DVDs of largish files to AFS. Since then I haven't encountered it at all. One thing I noticed in my case was that process monitor reported that explorer checked free space on the root volume instead of the volume that was being written to. Would somehow ensuring that the AFS server's root volume reports sufficient free space be an adequate workaround? I have no idea, but if I were still affected I'd try it... Regards, From nicolas-ml@deffayet.com Wed Oct 16 12:19:09 2013 From: nicolas-ml@deffayet.com (Nicolas DEFFAYET) Date: Wed, 16 Oct 2013 11:19:09 +0000 Subject: [OpenAFS] Re: RClone - Volume already exists In-Reply-To: <20131015100825.47410db7.adeason@sinenomine.net> References: <1381837070.6906.4.camel@srv31.corp.novso.com> <20131015100825.47410db7.adeason@sinenomine.net> Message-ID: <1381922349.22363.2.camel@srv31.corp.novso.com> On Tue, 2013-10-15 at 10:08 -0400, Andrew Deason wrote: > On Tue, 15 Oct 2013 11:37:50 +0000 > Nicolas DEFFAYET wrote: > > > I have troubles with some volumes during the vos release: > > # vos release backups -verbose -localauth > > What version of OpenAFS is 'vos'? What version is the volserver? I use: openafs 1.6.1-3+deb7u1 amd64 (Debian Wheezy) > > backups > > RWrite: 536870926 ROnly: 536870936 Backup: 536870946 > > RClone: 536870936 > > number of sites -> 2 > > server primary partition /vicepa RW Site -- New release > > server secondary partition /vicepa RO Site -- Old release > > This is a complete release of volume 536870926 > > Cloning RW volume 536870926 to temporary RO...Failed to clone the RW > > volume 536870926 > > Volume already exists > > Error in vos release command. > > Volume already exists > > What's happening here is that the volserver said "volume 536870936 > doesn't exist", and when we tried to clone to volume 536870936, the > volserver said "you can't do that, because 536870936 already exists". > At least, that is what it means with newer versions, I'm not sure if > various older versions are in play. > > So of course, that's a little confusing. Can you run on the 'primary': > > # ls -l /vicepa/V0536870936.vol > # volinfo /vicepa 536870936 # ls -l /vicepa/V0536870936.vol -rw-r--r-- 1 root root 76 Oct 14 13:17 /vicepa/V0536870936.vol # > volinfo may be in /usr/afs/bin, if you can't find it. And can you look > in VolserLog and FileLog on "primary" to see if new messages appear when > you try to perform the release? Can you try salvaging the volume > 536870926 on "primary", and provide what SalvageLog says? (or SalsrvLog > if you are running DAFS) # volinfo /vicepa 536870936 Volinfo: Error attaching volume header V0536870936.vol # # bos salvage -server 127.0.0.1 -partition /vicepa -volume 536870936 -localauth Starting salvage. bos: salvage completed # SalvageLog --- @(#) OpenAFS 1.6.1-3+deb7u1-debian built 2013-07-25 STARTING AFS SALVAGER 2.4 (/usr/lib/openafs/salvager /vicepa 536870936) namei_ListAFSSubDirs: warning: VG 536870936 does not have a link table; salvager will recreate it. 536870936 is a read-only volume; not salvaged --- Thanks for your help -- Nicolas DEFFAYET From l.schimmer@cgv.tugraz.at Wed Oct 16 12:52:15 2013 From: l.schimmer@cgv.tugraz.at (Lars Schimmer) Date: Wed, 16 Oct 2013 13:52:15 +0200 Subject: [OpenAFS] Re: RClone - Volume already exists In-Reply-To: <1381922349.22363.2.camel@srv31.corp.novso.com> References: <1381837070.6906.4.camel@srv31.corp.novso.com> <20131015100825.47410db7.adeason@sinenomine.net> <1381922349.22363.2.camel@srv31.corp.novso.com> Message-ID: <525E7DEF.2060308@cgv.tugraz.at> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --J4u9DrDJuXxV5lX8W2RlGH9LmXvuHqwxM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2013-10-16 13:19, Nicolas DEFFAYET wrote: > SalvageLog > --- > @(#) OpenAFS 1.6.1-3+deb7u1-debian built 2013-07-25=20 > STARTING AFS SALVAGER 2.4 (/usr/lib/openafs/salvager /vicepa 536870936)= > namei_ListAFSSubDirs: warning: VG 536870936 does not have a link table;= > salvager will recreate it. > 536870936 is a read-only volume; not salvaged In these cases I always do a bos salvage server partition TWICE ! It will salvage the complete partition and cleans up the partition also. Downside: server is down for this event. > Thanks for your help >=20 >=20 MfG, Lars Schimmer --=20 ------------------------------------------------------------- TU Graz, Institut f=C3=BCr ComputerGraphik & WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schimmer@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 --J4u9DrDJuXxV5lX8W2RlGH9LmXvuHqwxM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlJeffAACgkQmWhuE0qbFyMKAgCdHnXjYT6Y+ccw/xgKVGVYSEjv 6lkAn1ajaLZJCIKLNly3ZYNe2FY0vgzQ =uHWh -----END PGP SIGNATURE----- --J4u9DrDJuXxV5lX8W2RlGH9LmXvuHqwxM-- From adeason@sinenomine.net Wed Oct 16 14:11:00 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Wed, 16 Oct 2013 09:11:00 -0400 Subject: [OpenAFS] Re: RClone - Volume already exists References: <1381837070.6906.4.camel@srv31.corp.novso.com> <20131015100825.47410db7.adeason@sinenomine.net> <1381922349.22363.2.camel@srv31.corp.novso.com> Message-ID: <20131016091100.0d73ce23.adeason@sinenomine.net> On Wed, 16 Oct 2013 11:19:09 +0000 Nicolas DEFFAYET wrote: > # bos salvage -server 127.0.0.1 -partition /vicepa -volume 536870936 > -localauth > Starting salvage. > bos: salvage completed > # > > SalvageLog > --- > @(#) OpenAFS 1.6.1-3+deb7u1-debian built 2013-07-25 > STARTING AFS SALVAGER 2.4 (/usr/lib/openafs/salvager /vicepa 536870936) > namei_ListAFSSubDirs: warning: VG 536870936 does not have a link table; > salvager will recreate it. > 536870936 is a read-only volume; not salvaged > --- Salvage the RW volume id. It will look at the associated RO along with the RW. -- Andrew Deason adeason@sinenomine.net From botsch@cnf.cornell.edu Wed Oct 16 18:32:40 2013 From: botsch@cnf.cornell.edu (Dave Botsch) Date: Wed, 16 Oct 2013 13:32:40 -0400 Subject: [OpenAFS] oafs win update fail - lots of processes using files Message-ID: <20131016173239.GN13716@cnf.cornell.edu> Was looking to update my Server 2008 32-bit machine from 1.5.78 to 1.7.23 ... the installer is being a bit ridiculous with files in use: AFS Client DHCP Client Network Id Mgr Task Scheduler TCP/IP NetBIOS Helper Windows Event Log Two of those are expected, the rest... wtf... and terminating them would most likely not leave me with a happy machine. Any thoughts? Should I, after stopping Net ID Mgr and AFS Client, click "Ignore" ? -- ******************************** David William Botsch Programmer/Analyst @CNFComputing botsch@cnf.cornell.edu ******************************** From jaltman@secure-endpoints.com Wed Oct 16 18:51:00 2013 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 16 Oct 2013 13:51:00 -0400 Subject: [OpenAFS] oafs win update fail - lots of processes using files In-Reply-To: <20131016173239.GN13716@cnf.cornell.edu> References: <20131016173239.GN13716@cnf.cornell.edu> Message-ID: <525ED204.8020800@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms060109070102060500090904 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/16/2013 1:32 PM, Dave Botsch wrote: > Was looking to update my Server 2008 32-bit machine from 1.5.78 to > 1.7.23 ... the installer is being a bit ridiculous with files in use: >=20 > AFS Client=20 Clearing the afsd_service.exe is used by the AFS Client Service > DHCP Client Unclear what this loaded. Use Process Explorer to find out. > Network Id Mgr The AFS Credentials Provider is of course used by NetIdMgr > Task Scheduler Again, not sure what this is loading. Process Explorer will tell you. > TCP/IP NetBIOS Helper NetBIOS is used by the afsd_service.exe > Windows Event Log If you have the Windows Event Log viewer open it uses the afsd_service.exe binary to translate the log messages. >=20 > Two of those are expected, the rest... wtf... and terminating them woul= d > most likely not leave me with a happy machine. >=20 > Any thoughts? Should I, after stopping Net ID Mgr and AFS Client, click= > "Ignore" ?=20 You press Ignore because you will need to reboot in any case. --------------ms060109070102060500090904 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhBD 9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc1NTk5Njg2MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDGK4TaaHgHBkEIqx9 xgS06g4a1HdPcm5Lspe5OkYgSdxRiX84qp6msq+DWu1yQqmAxoS0a70Ctp99UgojGzKn2F8g nIEEFe0bOMbye736C4LWashMhB8iRXbNmfQHJU5mrLoeghHUnTsmRZsFOagpwZgHAC4ZKITq 87yJvVGGfIAS77EuoZx3PlQCTeq6xdmas4BzLxb+DF3vYkRvtLOnh3ixsEu1Js1QjIcrBIA8 bZp0fU9SZWTU1MSHheYykKhBDBNurQpYEJ1VkJGvgITfcRUUfifxe7HbMlyDHJQtzn9mpocE xiF1Vtzthcw6BhdqDhw4IvhWin+CY1Q6XOoHAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFLNBzIZb/xB6K+oeDwfBVLaB3qbUMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHgy34Smu5krf/eRWcjkEwnLYWZSXqo8T6/FBeSS TUE/E7DB6k27NUate7u5keQnrWmohWErxU/ona1WVHIdvSmK1Ow4IbUM9Pl4TKsDmBezDd8U eQU6q7KtkQuooeO/OgaJ49NXq/UgqoTXi72sAVpiPtOqgRJ4m+oO6Hv9OF5co49z5zMRFI6A SHEVi/41s8iYxlv++2ghtDDIA6vLS3MhGogh0wXFszn/dcWeluOkQZR9glfLr7Y853v3OBoh u1k40Q3NpnTl9ZgODP6Gh/hD08fXmBka0/p9rFRhR1NQBQg0WQbwS0ScFiECviWt9TbN2k/e GLwmOQD4a4Md7uoxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEP2DS/S5ZSBTt+yrappszwwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMDE2MTc1MTAwWjAjBgkqhkiG9w0BCQQxFgQUdaEnYPeUqtUJa199P9O4Pcv0e8EwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQQ/YNL9LllIFO37KtqmmzPDCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhBD9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBAQUABIIB AJO36KSaekIy2f+sUkM2pC183MwYAQMlznTDdO3qkMHdSn7fNhItO9RG19NIShErr1WwEiZC 6PnuTu4MwXGVzv7+d9igAeqj5WZneFC2to/GA9Xp0ucfA1ADsZB3PUt4Vouy93OCTrJJEf/t A4l/iPJH/NYPSPf0NbZSsIPiAqZsYUdXje7PQdWZ+sI47Os2lkOdgvpNNMQ7j47/x1acy6XG FCUoVH3REZMd5NQOt7aKQRftFaNFDiskHUSMz/3uxhCv2SySN7mH6izYN98KaY5CL9uG5SFn jYoOJ9NGbBh0+PT6GS/ZO+rEJAIIfGBE4FTYOOJpDD87xVUbj0kMfkcAAAAAAAA= --------------ms060109070102060500090904-- From botsch@cnf.cornell.edu Wed Oct 16 19:18:20 2013 From: botsch@cnf.cornell.edu (Dave Botsch) Date: Wed, 16 Oct 2013 14:18:20 -0400 Subject: [OpenAFS] oafs win update fail - lots of processes using files In-Reply-To: <525ED204.8020800@secure-endpoints.com> References: <20131016173239.GN13716@cnf.cornell.edu> <525ED204.8020800@secure-endpoints.com> Message-ID: <20131016181820.GR13716@cnf.cornell.edu> Will click Ignore, then and generally not worry about it. But, looking... DHCP CLient, TCPIP NetBIOS, and EventLog are all showing in the installer the same PID. Which maps to, in Process Explorer: svchosts.exe -k LocalServiceNetworkRestricted. and those all have afsd_service.exe listed in the DLL pane. The Task Schedulere is svchost.exe -k netsvcs I don't see anything directly using afs stuff there, but perhaps it's using something that's using something... On Wed, Oct 16, 2013 at 01:51:00PM -0400, Jeffrey Altman wrote: > On 10/16/2013 1:32 PM, Dave Botsch wrote: > > Was looking to update my Server 2008 32-bit machine from 1.5.78 to > > 1.7.23 ... the installer is being a bit ridiculous with files in use: > > > > AFS Client > > Clearing the afsd_service.exe is used by the AFS Client Service > > > DHCP Client > > Unclear what this loaded. Use Process Explorer to find out. > > > Network Id Mgr > > The AFS Credentials Provider is of course used by NetIdMgr > > > Task Scheduler > > Again, not sure what this is loading. Process Explorer will tell you. > > > TCP/IP NetBIOS Helper > > NetBIOS is used by the afsd_service.exe > > > Windows Event Log > > If you have the Windows Event Log viewer open it uses the > afsd_service.exe binary to translate the log messages. > > > > > Two of those are expected, the rest... wtf... and terminating them would > > most likely not leave me with a happy machine. > > > > Any thoughts? Should I, after stopping Net ID Mgr and AFS Client, click > > "Ignore" ? > > You press Ignore because you will need to reboot in any case. > > > -- ******************************** David William Botsch Programmer/Analyst @CNFComputing botsch@cnf.cornell.edu ******************************** From jaltman@secure-endpoints.com Wed Oct 16 21:43:41 2013 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 16 Oct 2013 16:43:41 -0400 Subject: [OpenAFS] oafs win update fail - lots of processes using files In-Reply-To: <20131016181820.GR13716@cnf.cornell.edu> References: <20131016173239.GN13716@cnf.cornell.edu> <525ED204.8020800@secure-endpoints.com> <20131016181820.GR13716@cnf.cornell.edu> Message-ID: <525EFA7D.1030006@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms010809070604050107070203 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Look at the DLLs loaded into those processes. One of them must be a file that is about to be replaced. On 10/16/2013 2:18 PM, Dave Botsch wrote: > Will click Ignore, then and generally not worry about it. >=20 > But, looking... >=20 > DHCP CLient, TCPIP NetBIOS, and EventLog are all showing in the > installer the same PID. Which maps to, in Process Explorer: >=20 > svchosts.exe -k LocalServiceNetworkRestricted. >=20 > and those all have afsd_service.exe listed in the DLL pane. >=20 > The Task Schedulere is svchost.exe -k netsvcs >=20 > I don't see anything directly using afs stuff there, but perhaps it's > using something that's using something... >=20 > On Wed, Oct 16, 2013 at 01:51:00PM -0400, Jeffrey Altman wrote: >> On 10/16/2013 1:32 PM, Dave Botsch wrote: >>> Was looking to update my Server 2008 32-bit machine from 1.5.78 to >>> 1.7.23 ... the installer is being a bit ridiculous with files in use:= >>> >>> AFS Client=20 >> >> Clearing the afsd_service.exe is used by the AFS Client Service >> >>> DHCP Client >> >> Unclear what this loaded. Use Process Explorer to find out. >> >>> Network Id Mgr >> >> The AFS Credentials Provider is of course used by NetIdMgr >> >>> Task Scheduler >> >> Again, not sure what this is loading. Process Explorer will tell you.= >> >>> TCP/IP NetBIOS Helper >> >> NetBIOS is used by the afsd_service.exe >> >>> Windows Event Log >> >> If you have the Windows Event Log viewer open it uses the >> afsd_service.exe binary to translate the log messages. >> >>> >>> Two of those are expected, the rest... wtf... and terminating them wo= uld >>> most likely not leave me with a happy machine. >>> >>> Any thoughts? Should I, after stopping Net ID Mgr and AFS Client, cli= ck >>> "Ignore" ?=20 >> >> You press Ignore because you will need to reboot in any case. >> >> >> >=20 >=20 >=20 --------------ms010809070604050107070203 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhBD 9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc1NTk5Njg2MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDGK4TaaHgHBkEIqx9 xgS06g4a1HdPcm5Lspe5OkYgSdxRiX84qp6msq+DWu1yQqmAxoS0a70Ctp99UgojGzKn2F8g nIEEFe0bOMbye736C4LWashMhB8iRXbNmfQHJU5mrLoeghHUnTsmRZsFOagpwZgHAC4ZKITq 87yJvVGGfIAS77EuoZx3PlQCTeq6xdmas4BzLxb+DF3vYkRvtLOnh3ixsEu1Js1QjIcrBIA8 bZp0fU9SZWTU1MSHheYykKhBDBNurQpYEJ1VkJGvgITfcRUUfifxe7HbMlyDHJQtzn9mpocE xiF1Vtzthcw6BhdqDhw4IvhWin+CY1Q6XOoHAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFLNBzIZb/xB6K+oeDwfBVLaB3qbUMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHgy34Smu5krf/eRWcjkEwnLYWZSXqo8T6/FBeSS TUE/E7DB6k27NUate7u5keQnrWmohWErxU/ona1WVHIdvSmK1Ow4IbUM9Pl4TKsDmBezDd8U eQU6q7KtkQuooeO/OgaJ49NXq/UgqoTXi72sAVpiPtOqgRJ4m+oO6Hv9OF5co49z5zMRFI6A SHEVi/41s8iYxlv++2ghtDDIA6vLS3MhGogh0wXFszn/dcWeluOkQZR9glfLr7Y853v3OBoh u1k40Q3NpnTl9ZgODP6Gh/hD08fXmBka0/p9rFRhR1NQBQg0WQbwS0ScFiECviWt9TbN2k/e GLwmOQD4a4Md7uoxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEP2DS/S5ZSBTt+yrappszwwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMDE2MjA0MzQxWjAjBgkqhkiG9w0BCQQxFgQUc2ekmjBx73QsGBQXFLtGeH3MUBwwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQQ/YNL9LllIFO37KtqmmzPDCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhBD9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBAQUABIIB AE6cpU/cZuf5vavzIRk9Pn6psKmJYX5vDCrsjp9U3GJ11JMnvRGUVhzSW0Yfps+GE5VpQ0sX 9XLy4H+k13XRjSsZivmkrBj1LByrDmxmVrtyAwegKKDXVoLoxx7WlpJDwkznhc8wkl27/zpp tUXLfzhrmqdbY5eHYergzXXXwRTLWW5owrhoLU5ibsNsONEjz9cA7y2jvuqMzHpspfkgvfF6 v+OXwNVQvBtYs/8aOVhFoTRMN+BY3yo5JaJUAZd8M0bgrEcCvdqHvmwPvxQSG1sBYcujNgg6 n3dDlwAVZ9rbqkQLqaRBbjm73YPPFm5jSJE2yiBZv+RtYOkAwR66kS8AAAAAAAA= --------------ms010809070604050107070203-- From fredrik.kallgren@genesis.se Thu Oct 17 08:56:36 2013 From: fredrik.kallgren@genesis.se (Fredrik =?ISO-8859-1?Q?K=E4llgren?=) Date: Thu, 17 Oct 2013 09:56:36 +0200 Subject: [OpenAFS] ls: cannot open directory .: No such device Message-ID: <1381996596.26807.17.camel@fkaws> Hi, first off. I'm new to AFS and this question might be kind if stupid. But here goes. I've set up a server going through 'OpenAFS Quick Start Guide for UNIX'. No problems occured during the installation. I've also set up another machine as the client.=20 But when I try to ls (from the client) the '/afs/' I get "ls: cannot open directory.: No such device". I can see traffic traveling from client to the server so it's probably no network problem. kinit and aklog seems to work fine. I would appreciate to get some advice or pointers on what I'm doing wrong. The feeling is that there are problem with authentication. But I'm really not sure. /K=C3=A4llgren From christof.hanke@rzg.mpg.de Thu Oct 17 09:39:37 2013 From: christof.hanke@rzg.mpg.de (Christof Hanke) Date: Thu, 17 Oct 2013 10:39:37 +0200 Subject: [OpenAFS] ls: cannot open directory .: No such device In-Reply-To: <1381996596.26807.17.camel@fkaws> References: <1381996596.26807.17.camel@fkaws> Message-ID: <20131017103937.10c4233b@dijon.rzg.mpg.de> Hi, On Thu, 17 Oct 2013 09:56:36 +0200 Fredrik K=C3=A4llgren wrote: > Hi, >=20 > first off. I'm new to AFS and this question might be kind if stupid. But > here goes. >=20 > I've set up a server going through 'OpenAFS Quick Start Guide for UNIX'. > No problems occured during the installation. I've also set up another > machine as the client.=20 >=20 > But when I try to ls (from the client) the '/afs/' I get "ls: > cannot open directory.: No such device". I can see traffic traveling > from client to the server so it's probably no network problem. kinit and > aklog seems to work fine. >=20 "No such device" means=20 that there is no AFS-Volume behind the mountpoint you want to traverse=20 do a "fs lsmount /afs/" on the client and check that the volume=20 this mountpoint is pointing to really exists in your cell. HTH, Christof > I would appreciate to get some advice or pointers on what I'm doing > wrong. The feeling is that there are problem with authentication. But > I'm really not sure. >=20 >=20 > /K=C3=A4llgren >=20 >=20 > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info From jukka.tuominen@finndesign.fi Thu Oct 17 12:49:42 2013 From: jukka.tuominen@finndesign.fi (Jukka Tuominen) Date: Thu, 17 Oct 2013 14:49:42 +0300 (EEST) Subject: [OpenAFS] Boot sequence OpenAFS/ GDM In-Reply-To: <1526a49cfcf143c04107cc525b381723.squirrel@webmail.neutech.fi> References: <5474075.2191.1380053523112.JavaMail.root@web03> <20131002112553.3f994d66.adeason@sinenomine.net> <4e09dd1ddb7e936909335cc4c0632278.squirrel@webmail.neutech.fi> <20131002131625.20d41836.adeason@sinenomine.net> <1526a49cfcf143c04107cc525b381723.squirrel@webmail.neutech.fi> Message-ID: I managed to narrow down the problem of having some clients consistently succeeding and some consistently failing on gdm login into afs homedirs. I believe the problem is the undetermined booting order between afs and gdm. While the faster clients work fine every time, slower ones do never. However, if I restart gdm on a failing client, it works fine until the next boot. I found some discussions about this issue on the net, but not a solution that would work. I wonder if there's a speed-independent way to get the boot sequence right every time? (BTW, I tried asking help on a gdm mailing list, but no answers there. Sorry to bother you, again :) br, jukka From ballbery@sinenomine.net Thu Oct 17 14:15:23 2013 From: ballbery@sinenomine.net (Brandon Allbery) Date: Thu, 17 Oct 2013 13:15:23 +0000 Subject: [OpenAFS] Boot sequence OpenAFS/ GDM In-Reply-To: Message-ID: T24gMTAvMTcvMTMgMDc6NDksICJKdWtrYSBUdW9taW5lbiIgPGp1a2thLnR1b21pbmVuQGZpbm5k ZXNpZ24uZmk+IHdyb3RlOg0KDQo+SSBmb3VuZCBzb21lIGRpc2N1c3Npb25zIGFib3V0IHRoaXMg aXNzdWUgb24gdGhlIG5ldCwgYnV0IG5vdCBhIHNvbHV0aW9uDQo+dGhhdCB3b3VsZCB3b3JrLiBJ IHdvbmRlciBpZiB0aGVyZSdzIGEgc3BlZWQtaW5kZXBlbmRlbnQgd2F5IHRvIGdldCB0aGUNCj5i b290IHNlcXVlbmNlIHJpZ2h0IGV2ZXJ5IHRpbWU/DQoNClRoaXMgaXMgZG9uZSBieSBib290IGRl cGVuZGVuY2llcywgYW5kIHRoZSBkZXRhaWxzIGNhbiBkaWZmZXIgYmV0d2Vlbg0Kb3BlcmF0aW5n IHN5c3RlbXMgYW5kIGRpc3RyaWJ1dGlvbnMuIEhvd2V2ZXIsIGl0IHJlcXVpcmVzIHRoYXQgdGhl IEFGUw0Kc3RhcnR1cCBzY3JpcHQgYmUgbW9kaWZpZWQgc28gdGhhdCBpdCBvbmx5IGV4aXRzIGFm dGVyIEFGUyBpcyBydW5uaW5nLA0KaW5zdGVhZCBvZiB0aGUgc3RhbmRhcmQgYmVoYXZpb3Igd2hl cmUgYWZzZCBpcyBzZW50IGludG8gdGhlIGJhY2tncm91bmQgdG8NCndhaXQgZm9yIG5ldHdvcmsu DQoNClRoZSBjaGVhdHkgd2F5IHRvIGRvIHRoaXMgaXMgdG8gYWRkIHNvbWV0aGluZyBsaWtlDQoN CiAgICB3aGlsZSBzbGVlcCA1OyBkbw0KICAgICAgICB0ZXN0IC1kIC9hZnMvZ3JhbmQuY2VudHJh bC5vcmcvc2VydmljZSAmJiBicmVhaw0KICAgIGRvbmUNCg0KdG8gdGhlIHN0YXJ0dXAgcGhhc2Us IHRvIHdhaXQgdW50aWwgd2UgY2FuIHJlYWNoIHNvbWV0aGluZyAoeW91IG1heSB3YW50DQp0byB1 c2UgYSBwYXRoIGluIHlvdXIgbG9jYWwgY2VsbCkgYmVmb3JlIHJldHVybmluZyBjb250cm9sIHRv IHRoZSBzdGFydHVwDQptYW5hZ2VyOyB0aGVuIHlvdSBjYW4gbWFrZSB0aGUgZ2RtIHN0YXJ0dXAg ZGVwZW5kIG9uIGFmcy4NCg0KLS0gDQpicmFuZG9uIHMgYWxsYmVyeSBrZjhuaCAgICBzaW5lIG5v bWluZSBhc3NvY2lhdGVzDQphbGxiZXJ5LmJAZ21haWwuY29tICAgICAgIGJhbGxiZXJ5QHNpbmVu b21pbmUubmV0DQp1bml4LCBvcGVuYWZzLCBrZXJiZXJvcywgaW5mcmFzdHJ1Y3R1cmUsIHhtb25h ZA0KDQoNCg0K From jhutz@cmu.edu Thu Oct 17 17:24:34 2013 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Thu, 17 Oct 2013 12:24:34 -0400 Subject: [OpenAFS] Boot sequence OpenAFS/ GDM In-Reply-To: References: Message-ID: <1382027074.26784.50.camel@minbar.fac.cs.cmu.edu> On Thu, 2013-10-17 at 13:15 +0000, Brandon Allbery wrote: > The cheaty way to do this is to add something like > > while sleep 5; do > test -d /afs/grand.central.org/service && break > done > > to the startup phase, to wait until we can reach something (you may want > to use a path in your local cell) Indeed you might. I don't promise that /afs/grand.central.org/service will be reachable whenever you happen to want to boot your machines. :-) From jukka.tuominen@finndesign.fi Thu Oct 17 20:00:31 2013 From: jukka.tuominen@finndesign.fi (Jukka Tuominen) Date: Thu, 17 Oct 2013 22:00:31 +0300 (EEST) Subject: [OpenAFS] Boot sequence OpenAFS/ GDM In-Reply-To: References: Message-ID: <2eb5fe24c75aa7fc8de1ef8ea15cd7d1.squirrel@webmail.neutech.fi> Thanks Brandon, your solution worked. However, if I plugged off network, I couldn't log into local/unix account. Ideally, afs could wait for the network max 5 seconds (less if found earlier), and then release the thread and continue waiting on the background. I don't know scripting that well, but for the time being, I just added a dumb 5 second delay before gdm starts. If anybody can suggest a script like this, I'd be grateful. It probably wouldn't hurt to make it even the default feature, since there were quite a lot of similar symptoms out there while googling around. Also, I've noticed that logging into local account when off-line is very slow with afsd around. Maybe this kind of "wait >> release and continue waiting on the background" approach could speed up things when off-line? br, jukka > On 10/17/13 07:49, "Jukka Tuominen" wrote: > >>I found some discussions about this issue on the net, but not a solution >>that would work. I wonder if there's a speed-independent way to get the >>boot sequence right every time? > > This is done by boot dependencies, and the details can differ between > operating systems and distributions. However, it requires that the AFS > startup script be modified so that it only exits after AFS is running, > instead of the standard behavior where afsd is sent into the background > to > wait for network. > > The cheaty way to do this is to add something like > > while sleep 5; do > test -d /afs/grand.central.org/service && break > done > > to the startup phase, to wait until we can reach something (you may want > to use a path in your local cell) before returning control to the startup > manager; then you can make the gdm startup depend on afs. > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b@gmail.com ballbery@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > > > > :�� From ballbery@sinenomine.net Thu Oct 17 20:04:55 2013 From: ballbery@sinenomine.net (Brandon Allbery) Date: Thu, 17 Oct 2013 19:04:55 +0000 Subject: [OpenAFS] Boot sequence OpenAFS/ GDM In-Reply-To: <2eb5fe24c75aa7fc8de1ef8ea15cd7d1.squirrel@webmail.neutech.fi> Message-ID: T24gMTAvMTcvMTMgMTU6MDAsICJKdWtrYSBUdW9taW5lbiIgPGp1a2thLnR1b21pbmVuQGZpbm5k ZXNpZ24uZmk+IHdyb3RlOg0KDQo+eW91ciBzb2x1dGlvbiB3b3JrZWQuIEhvd2V2ZXIsIGlmIEkg cGx1Z2dlZCBvZmYgbmV0d29yaywgSSBjb3VsZG4ndCBsb2cNCj5pbnRvIGxvY2FsL3VuaXggYWNj b3VudC4gSWRlYWxseSwgYWZzIGNvdWxkIHdhaXQgZm9yIHRoZSBuZXR3b3JrIG1heCA1DQo+c2Vj b25kcyAobGVzcyBpZiBmb3VuZCBlYXJsaWVyKSwgYW5kIHRoZW4gcmVsZWFzZSB0aGUgdGhyZWFk IGFuZCBjb250aW51ZQ0KPndhaXRpbmcgb24gdGhlIGJhY2tncm91bmQuDQoNClllcy4gQXQgbXkg cHJldmlvdXMgam9iIEkgaGFkIGEgcmV3cml0ZSBvZiB0aGUgTGludXggQUZTIHN0YXJ0dXAgd2hp Y2ggZGlkDQp0aGF0LCBzcGVjaWZpY2FsbHkgZm9yIGxhcHRvcC9kaXNjb25uZWN0ZWQgY2xpZW50 IHN1cHBvcnQuIChTYWRseSBpdCB3YXMNCm9ubHkgaW5zdGFsbGVkIG9uIGxhcHRvcHMsIGFuZCB3 YXMgbmV2ZXIgdXBzdHJlYW1lZC4pDQoNCi0tIA0KYnJhbmRvbiBzIGFsbGJlcnkga2Y4bmggICAg c2luZSBub21pbmUgYXNzb2NpYXRlcw0KYWxsYmVyeS5iQGdtYWlsLmNvbSAgICAgICBiYWxsYmVy eUBzaW5lbm9taW5lLm5ldA0KdW5peCwgb3BlbmFmcywga2VyYmVyb3MsIGluZnJhc3RydWN0dXJl LCB4bW9uYWQNCg0KDQoNCg== From ballbery@sinenomine.net Thu Oct 17 20:22:56 2013 From: ballbery@sinenomine.net (Brandon Allbery) Date: Thu, 17 Oct 2013 19:22:56 +0000 Subject: [OpenAFS] Boot sequence OpenAFS/ GDM In-Reply-To: Message-ID: T24gMTAvMTcvMTMgMTU6MDQsICJCcmFuZG9uIEFsbGJlcnkiIDxiYWxsYmVyeUBzaW5lbm9taW5l Lm5ldD4gd3JvdGU6DQoNCj5PbiAxMC8xNy8xMyAxNTowMCwgIkp1a2thIFR1b21pbmVuIiA8anVr a2EudHVvbWluZW5AZmlubmRlc2lnbi5maT4gd3JvdGU6DQo+DQo+PnlvdXIgc29sdXRpb24gd29y a2VkLiBIb3dldmVyLCBpZiBJIHBsdWdnZWQgb2ZmIG5ldHdvcmssIEkgY291bGRuJ3QgbG9nDQo+ PmludG8gbG9jYWwvdW5peCBhY2NvdW50LiBJZGVhbGx5LCBhZnMgY291bGQgd2FpdCBmb3IgdGhl IG5ldHdvcmsgbWF4IDUNCj4+c2Vjb25kcyAobGVzcyBpZiBmb3VuZCBlYXJsaWVyKSwgYW5kIHRo ZW4gcmVsZWFzZSB0aGUgdGhyZWFkIGFuZCBjb250aW51ZQ0KPj53YWl0aW5nIG9uIHRoZSBiYWNr Z3JvdW5kLg0KPg0KPlllcy4gQXQgbXkgcHJldmlvdXMgam9iIEkgaGFkIGEgcmV3cml0ZSBvZiB0 aGUgTGludXggQUZTIHN0YXJ0dXAgd2hpY2ggZGlkDQo+dGhhdCwgc3BlY2lmaWNhbGx5IGZvciBs YXB0b3AvZGlzY29ubmVjdGVkIGNsaWVudCBzdXBwb3J0LiAoU2FkbHkgaXQgd2FzDQo+b25seSBp bnN0YWxsZWQgb24gbGFwdG9wcywgYW5kIHdhcyBuZXZlciB1cHN0cmVhbWVkLikNCg0KVG8gYmUg bW9yZSBwcmVjaXNlIGhlcmU6IGl0IGdyYWJiZWQgdGhlIGhvc3RuYW1lcyBvZiB0aGUgbG9jYWwg Y2VsbCBhbmQNCnRyaWVkIHRvIHBpbmcgdGhlbSwgdGhlbiB0byByeGRlYnVnIHRoZW0sIGJvdGgg d2l0aCBzaG9ydCB0aW1lb3V0cy4gSWYNCnRob3NlIGZhaWxlZCBpdCBza2lwcGVkIHRoZSBBRlMg c3RhcnR1cCBlbnRpcmVseSwgb3RoZXJ3aXNlIGl0IGRpZCB0aGUNCnN0YXJ0dXAsIHdhaXRlZCB1 cCB0byA2MHMgZm9yIG91ciBjZWxsIHRvIGJlIGFjY2Vzc2libGUsIGxvZ2dlZCBhIG1lc3NhZ2UN CmlmIG5vdCBhbmQgZXhpdGVkLg0KDQotLSANCmJyYW5kb24gcyBhbGxiZXJ5IGtmOG5oICAgIHNp bmUgbm9taW5lIGFzc29jaWF0ZXMNCmFsbGJlcnkuYkBnbWFpbC5jb20gICAgICAgYmFsbGJlcnlA c2luZW5vbWluZS5uZXQNCnVuaXgsIG9wZW5hZnMsIGtlcmJlcm9zLCBpbmZyYXN0cnVjdHVyZSwg eG1vbmFkDQoNCg0KDQo= From jaltman@your-file-system.com Sun Oct 20 03:16:57 2013 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Sat, 19 Oct 2013 22:16:57 -0400 Subject: [OpenAFS] not enough space in target directory In-Reply-To: References: <524F4305.4030102@googlemail.com> <524F5AD5.2070006@your-file-system.com> Message-ID: <52633D19.8030908@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms050002000204080902080306 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/15/2013 12:58 PM, Jack Hill wrote: > Also, since it appears that we won't be able to get it fixed,=20 I never said it won't be fixed. I said as with anything else fixing it will be prioritized based upon the number of customers that are impacted and believe it is important to them or their organization. One way of measuring importance is whether or not you or your organization is willing to spend money to get it fixed. I apply the same measurement to determining when and whether to fix a bug in the Windows client. How many users are impacted? Will it result in data loss? How much time will it take to diagnose the cause? Is there someone willing to pay for that time? How disruptive will the eventual fix be? If this community wants Microsoft to prioritize the interaction with the OpenAFS client on Windows, then it is going to have communicate that to Microsoft's development organizations. The most common way for that to occur is by filing bug reports when preview releases are shipped or by paying for bug reports after the final release is out. Jeffrey Altman --------------ms050002000204080902080306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhAl sq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc2MTA4NjMxMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChjpVdVk6XeKFff4To xGglVcP3FVY95LfwfBUKbQKppRYgfKBFW1RIEG+KXpc3IGOOTUX0Lg1xaukRwuoqv/pqRMNK JabXcr1RFuCFg9xfcmP5Z+65qQ+IRxYCKdcNfu3GdS7rMOY57+VLU7aZnnMgnt0oE42awze8 gYQSJsdjZKKZS9DBnzxJYfzqhIw7txoMdV7rwPAZm5yujsqI/eWuZPZ+qZ+8GTsnHJzZNvc6 KrDGU6aVfknM+qf92hXA2VXvmtf1B17BBbGX6Hgat71Ufw5oXFly6/Vt+e5mKIozXytw8qPX NllsG89ITVzn0OovcpcSRFBrXanzVn7JVj33AgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFMC1SMuRefXyNAwkZM+Lgu7iJ6nFMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHVBsY+l21fY0twxzNnO0QbadbRT4n7k3rYfOMbP noBDkYQx5lcrYn19f7e+ADMPdW/MY2ZjFM76aiRgiTo2IjMB7z4vyX6hfGJKTIHX9loDW0H2 z2o0jYqXDQtXx9A/gfMtVh9J+8O5IuCPsVtXgI4p6kRQHN+Er2Rzu1I4BILxE9HsDb/ruX6p NXZSUQ2AcMP87ZVfz+reumMpJgWWAoiQWJCgp+qZ2c2AG+yV+FstiMpxIj/qB9+BrFRuam8d IGbH0tIS2tyc7pgit8Pid2Zv7HGT2NFu69INsKIyqGImhMVuOUaCq/kNi3Z+6R5Hm3ljift8 ZF52Kiq4whe8KlcxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCECWyrbsULgHrdnyrUnPHH4IwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMDIwMDIxNjU3WjAjBgkqhkiG9w0BCQQxFgQUpLOXN28u6wb+gtj5ajLVHPdj7PwwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQJbKtuxQuAet2fKtSc8cfgjCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhAlsq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBAQUABIIB AC1HSHsq6WBa8c/oZS1bQG0MGw/HSNRhwnGIa1LEgauXgOVS5ewwR0Hn5/Z09+8qhk3iKt5Z 6pyswq0Y4Ii8GaJjQBO2H5MHFqBV6SDvXXtA5BjlIgJiwrntd1VS5BaXfJsRdawfIS4faMcU N702M/wEVUeiGGV5KDCn5/yK0YZf9CUtAvEESKboR4DUo9DoivEX62/Gr0bgN25FN0fNgjr2 zvmlgXQ07D+8+XTzL745IRnt3hKq+Ic8BTRR6zW4uJ1boRq3eD7RyEON9xiOgjkFY1vSx49c nQ4PHgwFXY1c6xZO1G7gvmsTdXa88gusoKG8r8khXMXTLUtyCzVqrXYAAAAAAAA= --------------ms050002000204080902080306-- From jaltman@your-file-system.com Sun Oct 20 03:26:38 2013 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Sat, 19 Oct 2013 22:26:38 -0400 Subject: [OpenAFS] not enough space in target directory In-Reply-To: References: <524F4305.4030102@googlemail.com> <524F5AD5.2070006@your-file-system.com> Message-ID: <52633F5E.7090501@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms040805000907050501070204 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/15/2013 7:07 PM, Ian Crowther wrote: > One thing I noticed in my case was that process monitor reported that > explorer checked free space on the root volume instead of the volume > that was being written to. That is the underlying problem. Instead of using GetVolumeInformationByHandleW() called on the destination directory the Explorer Shell is using GetVolumeInformation() which must be provided the root directory of the volume. When the Explorer Shell gets the root directory wrong and choose say the root of a drive letter mapping, then it gets the wrong volume attributes and free space. > Would somehow ensuring that the AFS server's root volume reports > sufficient free space be an adequate workaround? I have no idea, but > if I were still affected I'd try it... Readonly volumes have 0 bytes free. That is why this is a problem for AFS and not Windows File Shares. Windows doesn't support the concept of booting from a readonly volume and then accessing writable areas from a read/write volume. If it did, the Explorer Shell would be immune to this issue. The problem doesn't occur all of the time and Microsoft doesn't have internal AFS to test against so it is a challenge for them. Jeffrey Altman --------------ms040805000907050501070204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhAl sq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc2MTA4NjMxMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChjpVdVk6XeKFff4To xGglVcP3FVY95LfwfBUKbQKppRYgfKBFW1RIEG+KXpc3IGOOTUX0Lg1xaukRwuoqv/pqRMNK JabXcr1RFuCFg9xfcmP5Z+65qQ+IRxYCKdcNfu3GdS7rMOY57+VLU7aZnnMgnt0oE42awze8 gYQSJsdjZKKZS9DBnzxJYfzqhIw7txoMdV7rwPAZm5yujsqI/eWuZPZ+qZ+8GTsnHJzZNvc6 KrDGU6aVfknM+qf92hXA2VXvmtf1B17BBbGX6Hgat71Ufw5oXFly6/Vt+e5mKIozXytw8qPX NllsG89ITVzn0OovcpcSRFBrXanzVn7JVj33AgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFMC1SMuRefXyNAwkZM+Lgu7iJ6nFMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHVBsY+l21fY0twxzNnO0QbadbRT4n7k3rYfOMbP noBDkYQx5lcrYn19f7e+ADMPdW/MY2ZjFM76aiRgiTo2IjMB7z4vyX6hfGJKTIHX9loDW0H2 z2o0jYqXDQtXx9A/gfMtVh9J+8O5IuCPsVtXgI4p6kRQHN+Er2Rzu1I4BILxE9HsDb/ruX6p NXZSUQ2AcMP87ZVfz+reumMpJgWWAoiQWJCgp+qZ2c2AG+yV+FstiMpxIj/qB9+BrFRuam8d IGbH0tIS2tyc7pgit8Pid2Zv7HGT2NFu69INsKIyqGImhMVuOUaCq/kNi3Z+6R5Hm3ljift8 ZF52Kiq4whe8KlcxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCECWyrbsULgHrdnyrUnPHH4IwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMDIwMDIyNjM4WjAjBgkqhkiG9w0BCQQxFgQUkMorcOIdRbhb2y+9970+whYlrNUwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQJbKtuxQuAet2fKtSc8cfgjCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhAlsq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBAQUABIIB AG37OEgYWaF12+cWyt374JvHTZZMYKAvRXqGvdBWk9tvV64cPQfNQ//xPAbpKWdt8CP93bEa XHsQlxnQj7YyGDkdQSXtcHRUrrCiajMWwZz2pIlUKkSAmD1e73D2/Cie2aUIi+9M8Hp5Y94r Uhj4hUpfyjq5ATKUpJVtFcxqqJcTaVnHNTSyXRZwu/PSfmk9yXAvAxCLKa4n3MZfvYe7hHKa nhwWJzk7Wa4tlbb8kxM6qg4Y2mNvlFS064BmYgbfqp0PmkcmIRb30kU6Mcuzeiz0rFW6g8UL SfWD2Xs9WN9T1PpILxi6s7hPqIH7MyAh0yVQuwonMwzk9QRXggt5gFYAAAAAAAA= --------------ms040805000907050501070204-- From stephen@physics.unc.edu Mon Oct 21 14:29:04 2013 From: stephen@physics.unc.edu (stephen@physics.unc.edu) Date: Mon, 21 Oct 2013 09:29:04 -0400 (EDT) Subject: [OpenAFS] not enough space in target directory In-Reply-To: <52633F5E.7090501@your-file-system.com> References: <524F4305.4030102@googlemail.com> <524F5AD5.2070006@your-file-system.com> <52633F5E.7090501@your-file-system.com> Message-ID: Hi Jeff, Thanks for the further clarification of this problem. Your description of the problem below -- and on the MS tech forum back in March -- seems to imply that until this issue is fixed by MS, that there are potential work-arounds that could be taken by the OpenAFS client. Possibly undesirable from a developer's perspective, but effective for end-users... thoughts? Cheers, Stephen On Sat, 19 Oct 2013, Jeffrey Altman wrote: > On 10/15/2013 7:07 PM, Ian Crowther wrote: >> One thing I noticed in my case was that process monitor reported that >> explorer checked free space on the root volume instead of the volume >> that was being written to. > > That is the underlying problem. Instead of using > GetVolumeInformationByHandleW() called on the destination directory the > Explorer Shell is using GetVolumeInformation() which must be provided > the root directory of the volume. When the Explorer Shell gets the root > directory wrong and choose say the root of a drive letter mapping, then > it gets the wrong volume attributes and free space. > >> Would somehow ensuring that the AFS server's root volume reports >> sufficient free space be an adequate workaround? I have no idea, but >> if I were still affected I'd try it... > > Readonly volumes have 0 bytes free. That is why this is a problem for > AFS and not Windows File Shares. Windows doesn't support the concept of > booting from a readonly volume and then accessing writable areas from a > read/write volume. If it did, the Explorer Shell would be immune to > this issue. > > The problem doesn't occur all of the time and Microsoft doesn't have > internal AFS to test against so it is a challenge for them. > > Jeffrey Altman > > > From stephen@jadevine.org.uk Mon Oct 21 15:18:06 2013 From: stephen@jadevine.org.uk (Stephen Quinney) Date: Mon, 21 Oct 2013 15:18:06 +0100 Subject: [OpenAFS] client kernel panic on EL6 Message-ID: --047d7b343ecaed6ef104e940f3c9 Content-Type: text/plain; charset=ISO-8859-1 Has anyone else seen a kernel panic like this on EL6 with 1.6.5 and kernel 2.6.32-358.14.1.el6? Or does anyone have any suggestions as to what might have caused the problem? afs: disk cache read error in CacheItems slot 353815 off 28305220/36284420 code -4/80 openafs: assertion failed: tdc, file: /builddir/build/BUILD/openafs-1.6.5/src/libafs/MODLOAD-2.6.32-358.14.1.el6 .x86_64-SP/afs_dcache.c, line: 1512 2013-10-20T19:27------------[ cut here ]------------ :13.739622+01:00kernel BUG at /builddir/build/BUILD/openafs-1.6.5/src/libafs/MODLOAD-2.6.32-358.14.1.el6.x86_64- SP/afs_dcache.c:1512! kubelik kernel:invalid opcode: 0000 [#1] openafs: assertSMP ion failed: tdc, file: /builddirlast sysfs file: /sys/devices/pci0000:00/0000:00:02.0/0000:06:00.0/0000:07:00.0/0000:08:00.0/000 0:09:00.0/net/eth1/ifalias /build/BUILD/openafs-1.6.5/src/lCPU 1 ibafs/MODLOAD-2. Modules linked in:6.32-358.14.1.el openafs(P)6.x86_64-SP/afs_(U)dcache.c, line: bridge1512 2013-10-20T ipmi_devintf19:27:13.811101+ pcspkr01:00 kubelik ke nfsrnel: kernel BUG lockd at /builddir/bu fscach eild/BUILD/openaf auth_rpcgsss-1.6.5/src/liba nfs_aclfs/MODLOAD-2.6.3 sunrpc2-358.14.1.el6.x p4_clockmod86_64-SP /afs_dca freq_tableche.c:1512! speedstep_lib bonding 8021q garp stp llc ipv6 ses enclosure bnx2 microcode dcdbas serio_raw sg iTCO_wdt iTCO_ve ndor_support i5000_edac edac_core i5k_amb shpchp ext3 jbd mbcache sd_mod crc_t10dif megaraid_sas sr_mod cdrom pa ta_acpi ata_generic ata_piix radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core dm_mirror dm_region_hash dm_log dm_mod [last unloaded: mperf] Pid: 21990, comm: du Tainted: P --------------- 2.6.32-358.14.1.el6.x86_64 #1 Dell Inc. PowerEdge 1 950/0UR033 RIP: 0010:[] [] afs_AllocDCache+0x41e/0x4b0 [openafs] RSP: 0018:ffff88001382fc48 EFLAGS: 00010292 RAX: 000000000000009a RBX: 0000000000000000 RCX: 0000000000005d54 RDX: 0000000000000000 RSI: 0000000000000046 RDI: 0000000000000246 RBP: ffff88001382fc88 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000002000 R12: 0000000000000000 R13: ffff88007bb8a000 R14: 0000000000000000 R15: 00000000000681d0 FS: 00007fade9acd700(0000) GS:ffff880002240000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000ed3108 CR3: 00000000166d1000 CR4: 00000000000007e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process du (pid: 21990, threadinfo ffff88001382e000, task ffff88001384e040) Stack: ffff88000a2825c0 0000000000000001 ffff880027183e80 ffff88007bb8a000 00000000001a0740 00000000000681d0 00000000000681d0 00000000000681d0 ffff88001382fda8 ffffffffa058eefd 000001b50b146005 0000000420002d55 Call Trace: [] afs_GetDCache+0x1c9d/0x22e0 [openafs] [] ? afs_CopyOutAttrs+0xba/0x300 [openafs] [] afs_linux_readdir+0x175/0xa80 [openafs] [] ? filldir+0x0/0xe0 [] ? filldir+0x0/0xe0 [] vfs_readdir+0xc0/0xe0 [] sys_getdents+0x89/0xf0 [] system_call_fastpath+0x16/0x1b Code: 58 00 00 00 00 e9 46 fe ff ff b9 e8 05 00 00 48 c7 c2 18 f5 5e a0 48 c7 c6 50 be 5e a0 48 c7 c7 b0 f5 5e a0 31 c0 e8 c2 32 f8 e0 <0f> 0b eb fe b9 e9 05 00 00 48 c7 c2 18 f5 5e a0 48 c7 c6 54 be RIP [] afs_AllocDCache+0x41e/0x4b0 [openafs] RSP 2013-10-20T19:27:14.500338+01:00 kubelik kernel: RIP [] afs_AllocDCache+0x41e---[ end trace b87d32f01b9f2d88 ]--- /0x4b0 [openafs]Kernel panic - not syncing: Fatal exception Pid: 21990, comm: du Tainted: P D --------------- 2.6.32-358.14.1.el6.x86_64 #1 Call Trace: [] ? panic+0xa7/0x16f [] ? oops_end+0xe4/0x100 [] ? die+0x5b/0x90 [] ? do_trap+0xc4/0x160 [] ? do_invalid_op+0x95/0xb0 [] ? afs_AllocDCache+0x41e/0x4b0 [openafs] [] ? vprintk+0x251/0x560 [] ? afs_warn+0x58/0x60 [openafs] [] ? invalid_op+0x1b/0x20 [] ? afs_AllocDCache+0x41e/0x4b0 [openafs] [] ? afs_AllocDCache+0x41e/0x4b0 [openafs] [] ? afs_GetDCache+0x1c9d/0x22e0 [openafs] [] ? afs_CopyOutAttrs+0xba/0x300 [openafs] [] ? afs_linux_readdir+0x175/0xa80 [openafs] [] ? filldir+0x0/0xe0 [] ? filldir+0x0/0xe0 [] ? vfs_readdir+0xc0/0xe0 [] ? sys_getdents+0x89/0xf0 [] ? system_call_fastpath+0x16/0x1b panic occurred, switching back to text console --047d7b343ecaed6ef104e940f3c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Has anyone else seen a kernel panic like this on EL6 with = 1.6.5 and kernel 2.6.32-358.14.1.el6? Or does anyone have any suggestions a= s to what might have caused the problem?

afs: disk cache re= ad error in CacheItems slot 353815 off 28305220/36284420 code -4/80
openafs: assertion failed: tdc, file: /builddir/build/BUILD/openafs-1.6.5/s= rc/libafs/MODLOAD-2.6.32-358.14.1.el6
.x86_64-SP/afs_dcache.c, line: 151= 2
2013-10-20T19:27------------[ cut here ]------------
:13.739622+01:= 00kernel BUG at /builddir/build/BUILD/openafs-1.6.5/src/libafs/MODLOAD-2.6.= 32-358.14.1.el6.x86_64-
SP/afs_dcache.c:1512!
=A0kubelik kernel:invalid opcode: 0000 [#1]=A0 ope= nafs: assertSMP ion failed: tdc,
=A0file: /builddirlast sysfs file: /sys= /devices/pci0000:00/0000:00:02.0/0000:06:00.0/0000:07:00.0/0000:08:00.0/000=
0:09:00.0/net/eth1/ifalias
/build/BUILD/openafs-1.6.5/src/lCPU 1 ibafs/M= ODLOAD-2.
Modules linked in:6.32-358.14.1.el openafs(P)6.x86_64-SP/afs_(= U)dcache.c, line:=A0 bridge1512
2013-10-20T ipmi_devintf19:27:13.811101+= pcspkr01:00 kubelik ke nfsrnel: kernel BUG lockd at /builddir/bu fscach eild/BUILD/openaf auth_rpcgsss-1.6.5/src/liba nfs_aclfs/MODLOAD-2.6.3 sunrp= c2-358.14.1.el6.x p4_clockmod86_64-SP
/afs_dca freq_tableche.c:1512!
= =A0speedstep_lib bonding 8021q garp stp llc ipv6 ses enclosure bnx2 microco= de dcdbas serio_raw sg iTCO_wdt iTCO_ve
ndor_support i5000_edac edac_core i5k_amb shpchp ext3 jbd mbcache sd_mod cr= c_t10dif megaraid_sas sr_mod cdrom pa
ta_acpi ata_generic ata_piix radeo= n ttm drm_kms_helper drm i2c_algo_bit i2c_core dm_mirror dm_region_hash dm_= log
=A0dm_mod [last unloaded: mperf]
Pid: 21990, comm: du Tainted: P=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 ---------------=A0=A0=A0 2.6.32-358.14.1.el6.x86_6= 4 #1 Dell Inc. PowerEdge 1
950/0UR033
RIP: 0010:[<ffffffffa058a46e= >]=A0 [<ffffffffa058a46e>] afs_AllocDCache+0x41e/0x4b0 [openafs] RSP: 0018:ffff88001382fc48=A0 EFLAGS: 00010292
RAX: 000000000000009a RBX= : 0000000000000000 RCX: 0000000000005d54
RDX: 0000000000000000 RSI: 0000= 000000000046 RDI: 0000000000000246
RBP: ffff88001382fc88 R08: 0000000000= 000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000002000 R12: 0000000000000000
R13: f= fff88007bb8a000 R14: 0000000000000000 R15: 00000000000681d0
FS:=A0 00007= fade9acd700(0000) GS:ffff880002240000(0000) knlGS:0000000000000000
CS:= =A0 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000ed3108 CR3: 00000000166d1000 CR4: 00000000000007e0
DR0: 0= 000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000= 000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process du (pid: 2= 1990, threadinfo ffff88001382e000, task ffff88001384e040)
Stack:
=A0ffff88000a2825c0 0000000000000001 ffff880027183e80 ffff88007bb= 8a000
<d> 00000000001a0740 00000000000681d0 00000000000681d0 00000= 000000681d0
<d> ffff88001382fda8 ffffffffa058eefd 000001b50b146005= 0000000420002d55
Call Trace:
=A0[<ffffffffa058eefd>] afs_GetDCache+0x1c9d/0x22e0 [o= penafs]
=A0[<ffffffffa05ae1fa>] ? afs_CopyOutAttrs+0xba/0x300 [ope= nafs]
=A0[<ffffffffa05d6225>] afs_linux_readdir+0x175/0xa80 [opena= fs]
=A0[<ffffffff81196290>] ? filldir+0x0/0xe0
=A0[<ffffffff8119629= 0>] ? filldir+0x0/0xe0
=A0[<ffffffff81196510>] vfs_readdir+0xc0= /0xe0
=A0[<ffffffff81196699>] sys_getdents+0x89/0xf0
=A0[<ff= ffffff8100b072>] system_call_fastpath+0x16/0x1b
Code: 58 00 00 00 00 e9 46 fe ff ff b9 e8 05 00 00 48 c7 c2 18 f5 5e a0 48 = c7 c6 50 be 5e a0 48 c7 c7 b0 f5 5e a0 31 c0 e8 c2 32 f8 e0 <0f> 0b e= b fe b9 e9 05 00 00 48 c7 c2 18 f5 5e a0 48 c7 c6 54 be
RIP=A0 [<fff= fffffa058a46e>] afs_AllocDCache+0x41e/0x4b0 [openafs]
=A0RSP <ffff88001382fc48>
2013-10-20T19:27:14.500338+01:00 kubelik= kernel: RIP=A0 [<ffffffffa058a46e>] afs_AllocDCache+0x41e---[ end tr= ace b87d32f01b9f2d88 ]---
/0x4b0 [openafs]Kernel panic - not syncing: Fa= tal exception
Pid: 21990, comm: du Tainted: P=A0=A0=A0=A0=A0 D=A0=A0=A0 ---------------= =A0=A0=A0 2.6.32-358.14.1.el6.x86_64 #1
Call Trace:
=A0[<ffffffff8= 150d668>] ? panic+0xa7/0x16f
=A0[<ffffffff81511894>] ? oops_end= +0xe4/0x100
=A0[<ffffffff8100f19b>] ? die+0x5b/0x90
=A0[<ffffffff815110d4>] ? do_trap+0xc4/0x160
=A0[<ffffffff8100c= db5>] ? do_invalid_op+0x95/0xb0
=A0[<ffffffffa058a46e>] ? afs_A= llocDCache+0x41e/0x4b0 [openafs]
=A0[<ffffffff8106f261>] ? vprintk= +0x251/0x560
=A0[<ffffffffa0564d98>] ? afs_warn+0x58/0x60 [openafs]
=A0[<fff= fffff8100be5b>] ? invalid_op+0x1b/0x20
=A0[<ffffffffa058a46e>] = ? afs_AllocDCache+0x41e/0x4b0 [openafs]
=A0[<ffffffffa058a46e>] ? = afs_AllocDCache+0x41e/0x4b0 [openafs]
=A0[<ffffffffa058eefd>] ? afs_GetDCache+0x1c9d/0x22e0 [openafs]
= =A0[<ffffffffa05ae1fa>] ? afs_CopyOutAttrs+0xba/0x300 [openafs]
= =A0[<ffffffffa05d6225>] ? afs_linux_readdir+0x175/0xa80 [openafs]
= =A0[<ffffffff81196290>] ? filldir+0x0/0xe0
=A0[<ffffffff81196290>] ? filldir+0x0/0xe0
=A0[<ffffffff8119651= 0>] ? vfs_readdir+0xc0/0xe0
=A0[<ffffffff81196699>] ? sys_getde= nts+0x89/0xf0
=A0[<ffffffff8100b072>] ? system_call_fastpath+0x16/= 0x1b
panic occurred, switching back to text console

--047d7b343ecaed6ef104e940f3c9-- From stephan.wiesand@desy.de Mon Oct 21 15:33:13 2013 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Mon, 21 Oct 2013 16:33:13 +0200 Subject: [OpenAFS] client kernel panic on EL6 In-Reply-To: References: Message-ID: <0EC81EA4-014D-422D-BABC-3FDABCB065A5@desy.de> On Oct 21, 2013, at 16:18 , Stephen Quinney = wrote: > Has anyone else seen a kernel panic like this on EL6 with 1.6.5 and = kernel > 2.6.32-358.14.1.el6? Or does anyone have any suggestions as to what = might > have caused the problem? We're running all our EL6 systems with this client, many if not all all = on -358.* kernels, at least some actually 358.14.1, and x86_64 like your = system. I believe we haven't seen this happen. > afs: disk cache read error in CacheItems slot 353815 off = 28305220/36284420 > code -4/80 > openafs: assertion failed: tdc, file: > = /builddir/build/BUILD/openafs-1.6.5/src/libafs/MODLOAD-2.6.32-358.14.1.el6= > .x86_64-SP/afs_dcache.c, line: 1512 > 2013-10-20T19:27------------[ cut here ]------------ > :13.739622+01:00kernel BUG at > = /builddir/build/BUILD/openafs-1.6.5/src/libafs/MODLOAD-2.6.32-358.14.1.el6= .x86_64- > SP/afs_dcache.c:1512! > kubelik kernel:invalid opcode: 0000 [#1] openafs: assertSMP ion = failed: > tdc, > file: /builddirlast sysfs file: > = /sys/devices/pci0000:00/0000:00:02.0/0000:06:00.0/0000:07:00.0/0000:08:00.= 0/000 > 0:09:00.0/net/eth1/ifalias > /build/BUILD/openafs-1.6.5/src/lCPU 1 ibafs/MODLOAD-2. > Modules linked in:6.32-358.14.1.el = openafs(P)6.x86_64-SP/afs_(U)dcache.c, > line: bridge1512 > 2013-10-20T ipmi_devintf19:27:13.811101+ pcspkr01:00 kubelik ke = nfsrnel: > kernel BUG lockd at /builddir/bu fscach > eild/BUILD/openaf auth_rpcgsss-1.6.5/src/liba nfs_aclfs/MODLOAD-2.6.3 > sunrpc2-358.14.1.el6.x p4_clockmod86_64-SP > /afs_dca freq_tableche.c:1512! > speedstep_lib bonding 8021q garp stp llc ipv6 ses enclosure bnx2 = microcode > dcdbas serio_raw sg iTCO_wdt iTCO_ve > ndor_support i5000_edac edac_core i5k_amb shpchp ext3 jbd mbcache = sd_mod > crc_t10dif megaraid_sas sr_mod cdrom pa > ta_acpi ata_generic ata_piix radeon ttm drm_kms_helper drm = i2c_algo_bit > i2c_core dm_mirror dm_region_hash dm_log > dm_mod [last unloaded: mperf] > Pid: 21990, comm: du Tainted: P --------------- > 2.6.32-358.14.1.el6.x86_64 #1 Dell Inc. PowerEdge 1 > 950/0UR033 > RIP: 0010:[] [] > afs_AllocDCache+0x41e/0x4b0 [openafs] > RSP: 0018:ffff88001382fc48 EFLAGS: 00010292 > RAX: 000000000000009a RBX: 0000000000000000 RCX: 0000000000005d54 > RDX: 0000000000000000 RSI: 0000000000000046 RDI: 0000000000000246 > RBP: ffff88001382fc88 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000002000 R12: 0000000000000000 > R13: ffff88007bb8a000 R14: 0000000000000000 R15: 00000000000681d0 > FS: 00007fade9acd700(0000) GS:ffff880002240000(0000) = knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 0000000000ed3108 CR3: 00000000166d1000 CR4: 00000000000007e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process du (pid: 21990, threadinfo ffff88001382e000, task = ffff88001384e040) > Stack: > ffff88000a2825c0 0000000000000001 ffff880027183e80 ffff88007bb8a000 > 00000000001a0740 00000000000681d0 00000000000681d0 = 00000000000681d0 > ffff88001382fda8 ffffffffa058eefd 000001b50b146005 = 0000000420002d55 > Call Trace: > [] afs_GetDCache+0x1c9d/0x22e0 [openafs] > [] ? afs_CopyOutAttrs+0xba/0x300 [openafs] > [] afs_linux_readdir+0x175/0xa80 [openafs] > [] ? filldir+0x0/0xe0 > [] ? filldir+0x0/0xe0 > [] vfs_readdir+0xc0/0xe0 > [] sys_getdents+0x89/0xf0 > [] system_call_fastpath+0x16/0x1b > Code: 58 00 00 00 00 e9 46 fe ff ff b9 e8 05 00 00 48 c7 c2 18 f5 5e = a0 48 > c7 c6 50 be 5e a0 48 c7 c7 b0 f5 5e a0 31 c0 e8 c2 32 f8 e0 <0f> 0b eb = fe > b9 e9 05 00 00 48 c7 c2 18 f5 5e a0 48 c7 c6 54 be > RIP [] afs_AllocDCache+0x41e/0x4b0 [openafs] > RSP > 2013-10-20T19:27:14.500338+01:00 kubelik kernel: RIP = [] > afs_AllocDCache+0x41e---[ end trace b87d32f01b9f2d88 ]--- > /0x4b0 [openafs]Kernel panic - not syncing: Fatal exception > Pid: 21990, comm: du Tainted: P D --------------- > 2.6.32-358.14.1.el6.x86_64 #1 > Call Trace: > [] ? panic+0xa7/0x16f > [] ? oops_end+0xe4/0x100 > [] ? die+0x5b/0x90 > [] ? do_trap+0xc4/0x160 > [] ? do_invalid_op+0x95/0xb0 > [] ? afs_AllocDCache+0x41e/0x4b0 [openafs] > [] ? vprintk+0x251/0x560 > [] ? afs_warn+0x58/0x60 [openafs] > [] ? invalid_op+0x1b/0x20 > [] ? afs_AllocDCache+0x41e/0x4b0 [openafs] > [] ? afs_AllocDCache+0x41e/0x4b0 [openafs] > [] ? afs_GetDCache+0x1c9d/0x22e0 [openafs] > [] ? afs_CopyOutAttrs+0xba/0x300 [openafs] > [] ? afs_linux_readdir+0x175/0xa80 [openafs] > [] ? filldir+0x0/0xe0 > [] ? filldir+0x0/0xe0 > [] ? vfs_readdir+0xc0/0xe0 > [] ? sys_getdents+0x89/0xf0 > [] ? system_call_fastpath+0x16/0x1b > panic occurred, switching back to text console --=20 Stephan Wiesand DESY - DV - Platanenallee 6 15732 Zeuthen, Germany From adeason@sinenomine.net Mon Oct 21 16:13:43 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 21 Oct 2013 10:13:43 -0500 Subject: [OpenAFS] Re: client kernel panic on EL6 References: Message-ID: <20131021101343.e3038182.adeason@sinenomine.net> On Mon, 21 Oct 2013 15:18:06 +0100 Stephen Quinney wrote: > Has anyone else seen a kernel panic like this on EL6 with 1.6.5 and > kernel 2.6.32-358.14.1.el6? Or does anyone have any suggestions as to > what might have caused the problem? > > afs: disk cache read error in CacheItems slot 353815 off 28305220/36284420 > code -4/80 > openafs: assertion failed: tdc, file: In short: this means we got an error when reading from the cache fs. I assume that -4 is -EINTR, so that means we probably need to block signals on Linux when reading from the cache fs. (Or support getting interrupted by signals, but we don't do that now.) Some more info: Historically, the unix client hasn't really handled cache i/o errors at all. In various places a failed read or write from/to the cache would panic the machine, or error to userspace, or corrupt cache accounting information, etc etc. This is improving over time, and it's much better now than it has been in the past, but not all instances have been fixed yet. That particular error you saw occurs when reading a dcache slot from disk. In the past, an error like this would corrupt cache information, since the old code assumed that errors like this never happened. We've suspected that this is what's causing some other reports of crashes and small cache corruption involving dslot hash chain corruption; we didn't really _know_, since in those cases, the "problem" happened at some point in the past by the time the crash occurred. This dslot read error has been a candidate for the cause of those issues (and I believe, pretty much the only candidate that hasn't been otherwise ruled out). So we added a log message when that error occurs, and made the relevant function return an error. Various code paths were adjusted to try to handle the error as gracefully as possible, but some were more complex/difficult than others. A few, such as the specific backtrace you mentioned, have not hit 1.6 yet, since I was concerned about introducing new/different errors in the error handling since we didn't really know what was going on in these scenarios. Anyway, you're the first person I've seen actually hit this since the more informative log messages were introduced, so hooray! Now we finally know what's going on (in one scenario, at least). Developer references: Noticing the disk error was added in gerrit 7940, though many other commits have been changing it and fixing issues. The "easy" error-handling cases mentioned above are in 7941 and 9287. Some of the more "hard" cases are 8376, 8377, 8405, 8406. -- Andrew Deason adeason@sinenomine.net From huangql@ihep.ac.cn Tue Oct 22 10:38:53 2013 From: huangql@ihep.ac.cn (huangql) Date: Tue, 22 Oct 2013 17:38:53 +0800 Subject: [OpenAFS] PAM authentication failed on SL6 Message-ID: <201310221738532169840@ihep.ac.cn> Dear all, I found the same PAM configuration doesn't work on SL6 (always works well on SL4 and SL5), and even the previleged account "root" can not login normally after we configure PAM to enabling AFS login. Some specification as following: Operating system: Scientific Linux release 6.4 (Carbon) 2.6.32-358.14.1.el6.x86_64 OpenAFS: openafs-1.4.15 without Kerberos 5 Cell name: ihep.ac.cn # cat /etc/pam.d/login #%PAM-1.0 auth sufficient pam_afs.so try_first_pass ignore_root setenv_password_expires auth required pam_securetty.so auth required pam_stack.so service=system-auth auth required pam_nologin.so account required pam_stack.so service=system-auth password required pam_stack.so service=system-auth # pam_selinux.so close should be the first session rule session required pam_selinux.so close session required pam_stack.so service=system-auth session required pam_loginuid.so session optional pam_console.so # pam_selinux.so open should be the last session rule session required pam_selinux.so open # cat /etc/pam.d/su #%PAM-1.0 auth sufficient pam_afs.so try_first_pass ignore_root setenv_password_expires auth sufficient /lib/security/$ISA/pam_rootok.so # Uncomment the following line to implicitly trust users in the "wheel" group. #auth sufficient /lib/security/$ISA/pam_wheel.so trust use_uid # Uncomment the following line to require a user to be in the "wheel" group. #auth required /lib/security/$ISA/pam_wheel.so use_uid auth required /lib/security/$ISA/pam_stack.so service=system-auth account sufficient /lib/security/$ISA/pam_succeed_if.so uid=0 use_uid quiet account required /lib/security/$ISA/pam_stack.so service=system-auth password required /lib/security/$ISA/pam_stack.so service=system-auth # pam_selinux.so close must be first session rule session required /lib/security/$ISA/pam_selinux.so close session required /lib/security/$ISA/pam_stack.so service=system-auth # pam_selinux.so open and pam_xauth must be last two session rules session required /lib/security/$ISA/pam_selinux.so open session optional /lib/security/$ISA/pam_xauth.so # cat /etc/pam.d/sshd #%PAM-1.0 auth sufficient pam_afs.so try_first_pass ignore_root setenv_password_expires auth required pam_stack.so service=system-auth auth required pam_nologin.so account required pam_stack.so service=system-auth password required pam_stack.so service=system-auth session required pam_stack.so service=system-auth #cat /etc/pam.d/sudo #%PAM-1.0 auth sufficient pam_afs.so try_first_pass ignore_root setenv_password_expires auth sufficient /lib/security/$ISA/pam_rootok.so # Uncomment the following line to implicitly trust users in the "wheel" group. #auth sufficient /lib/security/$ISA/pam_wheel.so trust use_uid # Uncomment the following line to require a user to be in the "wheel" group. #auth required /lib/security/$ISA/pam_wheel.so use_uid auth required /lib/security/$ISA/pam_stack.so service=system-auth account sufficient /lib/security/$ISA/pam_succeed_if.so uid=0 use_uid quiet account required /lib/security/$ISA/pam_stack.so service=system-auth password required /lib/security/$ISA/pam_stack.so service=system-auth # pam_selinux.so close must be first session rule session required /lib/security/$ISA/pam_selinux.so close session required /lib/security/$ISA/pam_stack.so service=system-auth # pam_selinux.so open and pam_xauth must be last two session rules session required /lib/security/$ISA/pam_selinux.so open session optional /lib/security/$ISA/pam_xauth.so The questions stuck me for weeks. Does anyone get the same problem and could you give me some suggestions? Thank you very much in advance. Best Regards Qiulan Huang 2013-10-22 ==================================================================== Computing center,the Institute of High Energy Physics, China Huang, Qiulan Tel: (+86) 10 8823 6010-105 P.O. Box 918-7 Fax: (+86) 10 8823 6839 Beijing 100049 P.R. China Email: huangql@ihep.ac.cn =================================================================== From ballbery@sinenomine.net Tue Oct 22 14:22:58 2013 From: ballbery@sinenomine.net (Brandon Allbery) Date: Tue, 22 Oct 2013 13:22:58 +0000 Subject: [OpenAFS] PAM authentication failed on SL6 In-Reply-To: <201310221738532169840@ihep.ac.cn> Message-ID: T24gMTAvMjIvMTMgMDU6MzgsICJodWFuZ3FsIiA8aHVhbmdxbEBpaGVwLmFjLmNuPiB3cm90ZToN Cj5UaGUgcXVlc3Rpb25zIHN0dWNrIG1lIGZvciB3ZWVrcy4gRG9lcyBhbnlvbmUgZ2V0IHRoZSBz YW1lIHByb2JsZW0gYW5kDQo+Y291bGQgeW91IGdpdmUgbWUgc29tZSBzdWdnZXN0aW9ucz8NCg0K WW91IGRvbid0IHByb3ZpZGUgZW5vdWdoIGluZm9ybWF0aW9uLCBiZWNhdXNlIGFsbCB0aGUgc3Rh Y2tzIHlvdSBwcm92aWRlZA0KdXNlIHBhbV9zdGFjay5zbyB0byBsb2FkIHRoZSBzeXN0ZW0tYXV0 aCBzdGFjayB3aGljaCB5b3UgZGlkbid0IHByb3ZpZGUuDQoNCi0tIA0KYnJhbmRvbiBzIGFsbGJl cnkga2Y4bmggICAgc2luZSBub21pbmUgYXNzb2NpYXRlcw0KYWxsYmVyeS5iQGdtYWlsLmNvbSAg ICAgICBiYWxsYmVyeUBzaW5lbm9taW5lLm5ldA0KdW5peCwgb3BlbmFmcywga2VyYmVyb3MsIGlu ZnJhc3RydWN0dXJlLCB4bW9uYWQNCg0KDQoNCg== From huangql@ihep.ac.cn Tue Oct 22 15:53:56 2013 From: huangql@ihep.ac.cn (=?utf-8?B?aHVhbmdxbA==?=) Date: Tue, 22 Oct 2013 22:53:56 +0800 Subject: [OpenAFS] =?utf-8?B?UmU6IFJlOiBbT3BlbkFGU10gUEFNIGF1dGhlbnRpY2F0aW9uIGZhaWxlZCBvbiBTTDY=?= Message-ID: <201310222253567613742@ihep.ac.cn> This is a multi-part message in MIME format. --=====003_Dragon264050515273_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJhbmRvbiwNCg0KTWFueSB0aGFua3MgZm9yIHlvdXIgcHJvbXB0IHJlcGx5LiANCg0KVGhl IHJlZCBjaGFyYWN0ZXJzICBhcmUgdGhlIHBvaW50cyBmb3IgUEFNIGF1dGhlbnRpY2F0aW9uLCB5 b3UgbWVhbiB0aGVyZSBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uLCBjb3VsZCB5b3UgZXhwcmVz cyB3aGF0IG90aGVyIG1lc3NhZ2UgY291bGQgSSBwcm92aWRlPw0KDQoNCiMgY2F0IC9ldGMvcGFt LmQvbG9naW4NCg0KIyVQQU0tMS4wDQphdXRoICAgICAgIHN1ZmZpY2llbnQgICBwYW1fYWZzLnNv IHRyeV9maXJzdF9wYXNzIGlnbm9yZV9yb290IHNldGVudl9wYXNzd29yZF9leHBpcmVzDQphdXRo ICAgICAgIHJlcXVpcmVkICAgICBwYW1fc2VjdXJldHR5LnNvDQphdXRoICAgICAgIHJlcXVpcmVk ICAgICBwYW1fc3RhY2suc28gc2VydmljZT1zeXN0ZW0tYXV0aA0KYXV0aCAgICAgICByZXF1aXJl ZCAgICAgcGFtX25vbG9naW4uc28NCmFjY291bnQgICAgcmVxdWlyZWQgICAgIHBhbV9zdGFjay5z byBzZXJ2aWNlPXN5c3RlbS1hdXRoDQpwYXNzd29yZCAgIHJlcXVpcmVkICAgICBwYW1fc3RhY2su c28gc2VydmljZT1zeXN0ZW0tYXV0aA0KIyBwYW1fc2VsaW51eC5zbyBjbG9zZSBzaG91bGQgYmUg dGhlIGZpcnN0IHNlc3Npb24gcnVsZQ0Kc2Vzc2lvbiAgICByZXF1aXJlZCAgICAgcGFtX3NlbGlu dXguc28gY2xvc2UNCnNlc3Npb24gICAgcmVxdWlyZWQgICAgIHBhbV9zdGFjay5zbyBzZXJ2aWNl PXN5c3RlbS1hdXRoDQpzZXNzaW9uICAgIHJlcXVpcmVkICAgICBwYW1fbG9naW51aWQuc28NCnNl c3Npb24gICAgb3B0aW9uYWwgICAgIHBhbV9jb25zb2xlLnNvDQojIHBhbV9zZWxpbnV4LnNvIG9w ZW4gc2hvdWxkIGJlIHRoZSBsYXN0IHNlc3Npb24gcnVsZQ0Kc2Vzc2lvbiAgICByZXF1aXJlZCAg ICAgcGFtX3NlbGludXguc28gb3Blbg0KDQoNCiMgY2F0IC9ldGMvcGFtLmQvc3UNCg0KIyVQQU0t MS4wDQphdXRoICAgICAgIHN1ZmZpY2llbnQgICBwYW1fYWZzLnNvIHRyeV9maXJzdF9wYXNzIGln bm9yZV9yb290IHNldGVudl9wYXNzd29yZF9leHBpcmVzDQphdXRoICAgICAgIHN1ZmZpY2llbnQg ICAvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3Jvb3Rvay5zbw0KIyBVbmNvbW1lbnQgdGhlIGZvbGxv d2luZyBsaW5lIHRvIGltcGxpY2l0bHkgdHJ1c3QgdXNlcnMgaW4gdGhlICJ3aGVlbCIgZ3JvdXAu DQojYXV0aCAgICAgICBzdWZmaWNpZW50ICAgL2xpYi9zZWN1cml0eS8kSVNBL3BhbV93aGVlbC5z byB0cnVzdCB1c2VfdWlkDQojIFVuY29tbWVudCB0aGUgZm9sbG93aW5nIGxpbmUgdG8gcmVxdWly ZSBhIHVzZXIgdG8gYmUgaW4gdGhlICJ3aGVlbCIgZ3JvdXAuDQojYXV0aCAgICAgICByZXF1aXJl ZCAgICAgL2xpYi9zZWN1cml0eS8kSVNBL3BhbV93aGVlbC5zbyB1c2VfdWlkDQphdXRoICAgICAg IHJlcXVpcmVkICAgICAvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3N0YWNrLnNvIHNlcnZpY2U9c3lz dGVtLWF1dGgNCmFjY291bnQgICAgc3VmZmljaWVudCAgIC9saWIvc2VjdXJpdHkvJElTQS9wYW1f c3VjY2VlZF9pZi5zbyB1aWQ9MCB1c2VfdWlkIHF1aWV0DQphY2NvdW50ICAgIHJlcXVpcmVkICAg ICAvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3N0YWNrLnNvIHNlcnZpY2U9c3lzdGVtLWF1dGgNCnBh c3N3b3JkICAgcmVxdWlyZWQgICAgIC9saWIvc2VjdXJpdHkvJElTQS9wYW1fc3RhY2suc28gc2Vy dmljZT1zeXN0ZW0tYXV0aA0KIyBwYW1fc2VsaW51eC5zbyBjbG9zZSBtdXN0IGJlIGZpcnN0IHNl c3Npb24gcnVsZQ0Kc2Vzc2lvbiAgICByZXF1aXJlZCAgICAgL2xpYi9zZWN1cml0eS8kSVNBL3Bh bV9zZWxpbnV4LnNvIGNsb3NlDQpzZXNzaW9uICAgIHJlcXVpcmVkICAgICAvbGliL3NlY3VyaXR5 LyRJU0EvcGFtX3N0YWNrLnNvIHNlcnZpY2U9c3lzdGVtLWF1dGgNCiMgcGFtX3NlbGludXguc28g b3BlbiBhbmQgcGFtX3hhdXRoIG11c3QgYmUgbGFzdCB0d28gc2Vzc2lvbiBydWxlcw0Kc2Vzc2lv biAgICByZXF1aXJlZCAgICAgL2xpYi9zZWN1cml0eS8kSVNBL3BhbV9zZWxpbnV4LnNvIG9wZW4N CnNlc3Npb24gICAgb3B0aW9uYWwgICAgIC9saWIvc2VjdXJpdHkvJElTQS9wYW1feGF1dGguc28N Cg0KIyBjYXQgIC9ldGMvcGFtLmQvc3NoZA0KDQojJVBBTS0xLjANCmF1dGggICAgICAgc3VmZmlj aWVudCAgIHBhbV9hZnMuc28gdHJ5X2ZpcnN0X3Bhc3MgaWdub3JlX3Jvb3Qgc2V0ZW52X3Bhc3N3 b3JkX2V4cGlyZXMNCmF1dGggICAgICAgcmVxdWlyZWQgICAgIHBhbV9zdGFjay5zbyBzZXJ2aWNl PXN5c3RlbS1hdXRoDQphdXRoICAgICAgIHJlcXVpcmVkICAgICBwYW1fbm9sb2dpbi5zbw0KYWNj b3VudCAgICByZXF1aXJlZCAgICAgcGFtX3N0YWNrLnNvIHNlcnZpY2U9c3lzdGVtLWF1dGgNCnBh c3N3b3JkICAgcmVxdWlyZWQgICAgIHBhbV9zdGFjay5zbyBzZXJ2aWNlPXN5c3RlbS1hdXRoDQpz ZXNzaW9uICAgIHJlcXVpcmVkICAgICBwYW1fc3RhY2suc28gc2VydmljZT1zeXN0ZW0tYXV0aA0K DQoNCiNjYXQgL2V0Yy9wYW0uZC9zdWRvICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQojJVBBTS0xLjANCmF1dGggICAgICAgc3VmZmljaWVu dCAgIHBhbV9hZnMuc28gdHJ5X2ZpcnN0X3Bhc3MgaWdub3JlX3Jvb3Qgc2V0ZW52X3Bhc3N3b3Jk X2V4cGlyZXMNCmF1dGggICAgICAgc3VmZmljaWVudCAgIC9saWIvc2VjdXJpdHkvJElTQS9wYW1f cm9vdG9rLnNvDQojIFVuY29tbWVudCB0aGUgZm9sbG93aW5nIGxpbmUgdG8gaW1wbGljaXRseSB0 cnVzdCB1c2VycyBpbiB0aGUgIndoZWVsIiBncm91cC4NCiNhdXRoICAgICAgIHN1ZmZpY2llbnQg ICAvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3doZWVsLnNvIHRydXN0IHVzZV91aWQNCiMgVW5jb21t ZW50IHRoZSBmb2xsb3dpbmcgbGluZSB0byByZXF1aXJlIGEgdXNlciB0byBiZSBpbiB0aGUgIndo ZWVsIiBncm91cC4NCiNhdXRoICAgICAgIHJlcXVpcmVkICAgICAvbGliL3NlY3VyaXR5LyRJU0Ev cGFtX3doZWVsLnNvIHVzZV91aWQNCmF1dGggICAgICAgcmVxdWlyZWQgICAgIC9saWIvc2VjdXJp dHkvJElTQS9wYW1fc3RhY2suc28gc2VydmljZT1zeXN0ZW0tYXV0aA0KYWNjb3VudCAgICBzdWZm aWNpZW50ICAgL2xpYi9zZWN1cml0eS8kSVNBL3BhbV9zdWNjZWVkX2lmLnNvIHVpZD0wIHVzZV91 aWQgcXVpZXQNCmFjY291bnQgICAgcmVxdWlyZWQgICAgIC9saWIvc2VjdXJpdHkvJElTQS9wYW1f c3RhY2suc28gc2VydmljZT1zeXN0ZW0tYXV0aA0KcGFzc3dvcmQgICByZXF1aXJlZCAgICAgL2xp Yi9zZWN1cml0eS8kSVNBL3BhbV9zdGFjay5zbyBzZXJ2aWNlPXN5c3RlbS1hdXRoDQojIHBhbV9z ZWxpbnV4LnNvIGNsb3NlIG11c3QgYmUgZmlyc3Qgc2Vzc2lvbiBydWxlDQpzZXNzaW9uICAgIHJl cXVpcmVkICAgICAvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3NlbGludXguc28gY2xvc2UNCnNlc3Np b24gICAgcmVxdWlyZWQgICAgIC9saWIvc2VjdXJpdHkvJElTQS9wYW1fc3RhY2suc28gc2Vydmlj ZT1zeXN0ZW0tYXV0aA0KIyBwYW1fc2VsaW51eC5zbyBvcGVuIGFuZCBwYW1feGF1dGggbXVzdCBi ZSBsYXN0IHR3byBzZXNzaW9uIHJ1bGVzDQpzZXNzaW9uICAgIHJlcXVpcmVkICAgICAvbGliL3Nl Y3VyaXR5LyRJU0EvcGFtX3NlbGludXguc28gb3Blbg0Kc2Vzc2lvbiAgICBvcHRpb25hbCAgICAg L2xpYi9zZWN1cml0eS8kSVNBL3BhbV94YXV0aC5zbw0KDQoNClRoYW5rcyBhIGxvdC4NCg0KQmVz dCBSZWdhcmRzDQpRaXVsYW4gSHVhbmcNCjIwMTMtMTAtMjINCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpDb21wdXRp bmcgY2VudGVyLHRoZSBJbnN0aXR1dGUgb2YgSGlnaCBFbmVyZ3kgUGh5c2ljcywgQ2hpbmENCkh1 YW5nLCBRaXVsYW4gICAgICAgICAgICAgICAgICAgICAgICBUZWw6ICgrODYpIDEwIDg4MjMgNjAx MC0xMDUNClAuTy4gQm94IDkxOC03ICAgICAgICAgICAgICAgICAgICAgICBGYXg6ICgrODYpIDEw IDg4MjMgNjgzOQ0KQmVpamluZyAxMDAwNDkgIFAuUi4gQ2hpbmEgICAgICAgICAgIEVtYWlsOiBo dWFuZ3FsQGloZXAuYWMuY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0gDQoNCg0KDQrlj5Hku7bkurrvvJogQnJhbmRv biBBbGxiZXJ5IA0K5Y+R6YCB5pe26Ze077yaIDIwMTMtMTAtMjIgIDIxOjIzOjAzIA0K5pS25Lu2 5Lq677yaIGh1YW5ncWw7IG9wZW5hZnMtaW5mbyANCuaKhOmAge+8miANCuS4u+mimO+8miBSZTog W09wZW5BRlNdIFBBTSBhdXRoZW50aWNhdGlvbiBmYWlsZWQgb24gU0w2IA0KIA0KT24gMTAvMjIv MTMgMDU6MzgsICJodWFuZ3FsIiA8aHVhbmdxbEBpaGVwLmFjLmNuPiB3cm90ZToNCj5UaGUgcXVl c3Rpb25zIHN0dWNrIG1lIGZvciB3ZWVrcy4gRG9lcyBhbnlvbmUgZ2V0IHRoZSBzYW1lIHByb2Js ZW0gYW5kDQo+Y291bGQgeW91IGdpdmUgbWUgc29tZSBzdWdnZXN0aW9ucz8NCllvdSBkb24ndCBw cm92aWRlIGVub3VnaCBpbmZvcm1hdGlvbiwgYmVjYXVzZSBhbGwgdGhlIHN0YWNrcyB5b3UgcHJv dmlkZWQNCnVzZSBwYW1fc3RhY2suc28gdG8gbG9hZCB0aGUgc3lzdGVtLWF1dGggc3RhY2sgd2hp Y2ggeW91IGRpZG4ndCBwcm92aWRlLg0KLS0gDQpicmFuZG9uIHMgYWxsYmVyeSBrZjhuaCAgICBz aW5lIG5vbWluZSBhc3NvY2lhdGVzDQphbGxiZXJ5LmJAZ21haWwuY29tICAgICAgIGJhbGxiZXJ5 QHNpbmVub21pbmUubmV0DQp1bml4LCBvcGVuYWZzLCBrZXJiZXJvcywgaW5mcmFzdHJ1Y3R1cmUs IHhtb25hZA0K --=====003_Dragon264050515273_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNv bnRlbnQ9Ik1TSFRNTCAxMC4wMC45MjAwLjE2NzIxIj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglm b250LWZhbWlseTog5a6L5L2TOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFZlcmRh bmE7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQOWui+S9kzsNCn0NCkBwYWdlIFNl Y3Rpb24xIHtzaXplOiA1OTUuM3B0IDg0MS45cHQ7IG1hcmdpbjogNzIuMHB0IDkwLjBwdCA3Mi4w cHQgOTAuMHB0OyBsYXlvdXQtZ3JpZDogMTUuNnB0OyB9DQpQLk1zb05vcm1hbCB7DQoJRk9OVC1T SVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjog anVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3Jh cGgNCn0NCkxJLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAi VGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBw dDsgVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGgNCn0NCkRJVi5Nc29Ob3JtYWwgew0KCUZP TlQtU0laRTogMTAuNXB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJ R046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IFRFWFQtSlVTVElGWTogaW50ZXItaWRl b2dyYXBoDQp9DQpBOmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVy bGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJ T046IHVuZGVybGluZQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09S QVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmtGb2xsb3dlZCB7DQoJQ09MT1I6 IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uRW1haWxTdHlsZTE3 IHsNCglGT05ULUZBTUlMWTogVmVyZGFuYTsgRk9OVC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdp bmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsgVEVYVC1ERUNPUkFUSU9OOiBub25lOyBtc28t c3R5bGUtdHlwZTogcGVyc29uYWwtY29tcG9zZQ0KfQ0KRElWLlNlY3Rpb24xIHsNCglwYWdlOiBT ZWN0aW9uMQ0KfQ0KVU5LTk9XTiB7DQoJRk9OVC1TSVpFOiAxMHB0DQp9DQpCTE9DS1FVT1RFIHsN CglNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW07IE1BUkdJTi1UT1A6IDBweA0K fQ0KT0wgew0KCU1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4DQp9DQpVTCB7DQoJ TUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgNCn0NCjwvU1RZTEU+DQo8L0hFQUQ+ DQo8Qk9EWSBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogdmVyZGFuYTsgTUFS R0lOOiAxMHB4Ij4NCjxESVY+DQo8RElWPkhpIEJyYW5kb24sPC9ESVY+DQo8RElWPiZuYnNwOzwv RElWPg0KPERJVj5NYW55IHRoYW5rcyBmb3IgeW91ciBwcm9tcHQgcmVwbHkuIDwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+VGhlIHJlZCBjaGFyYWN0ZXJzJm5ic3A7IGFyZSB0aGUgcG9p bnRzIGZvciBQQU0gYXV0aGVudGljYXRpb24sIHlvdSBtZWFuIA0KdGhlcmUgaXMgbm90IGVub3Vn aCBpbmZvcm1hdGlvbiwgY291bGQgeW91IGV4cHJlc3Mgd2hhdCBvdGhlciBtZXNzYWdlIGNvdWxk IEkgDQpwcm92aWRlPzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGNvbG9yPSNmZjAwMDA+IyZuYnNwO2NhdCZuYnNwOy9ldGMvcGFtLmQvbG9n aW48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSNmZjAwMDA+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48L0RJVj4NCjxESVY+IyVQQU0tMS4wPC9ESVY+DQo8RElWPjxGT05UIA0KY29s b3I9I2ZmMDAwMD5hdXRoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 c3VmZmljaWVudCZuYnNwOyZuYnNwOyZuYnNwO3BhbV9hZnMuc28mbmJzcDt0cnlfZmlyc3RfcGFz cyZuYnNwO2lnbm9yZV9yb290Jm5ic3A7c2V0ZW52X3Bhc3N3b3JkX2V4cGlyZXM8L0ZPTlQ+PC9E SVY+DQo8RElWPmF1dGgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDty ZXF1aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3BhbV9zZWN1cmV0dHkuc288L0RJ Vj4NCjxESVY+YXV0aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Jl cXVpcmVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGFtX3N0YWNrLnNvJm5ic3A7c2Vy dmljZT1zeXN0ZW0tYXV0aDwvRElWPg0KPERJVj5hdXRoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVxdWlyZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtw YW1fbm9sb2dpbi5zbzwvRElWPg0KPERJVj5hY2NvdW50Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 cmVxdWlyZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwYW1fc3RhY2suc28mbmJzcDtz ZXJ2aWNlPXN5c3RlbS1hdXRoPC9ESVY+DQo8RElWPnBhc3N3b3JkJm5ic3A7Jm5ic3A7Jm5ic3A7 cmVxdWlyZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwYW1fc3RhY2suc28mbmJzcDtz ZXJ2aWNlPXN5c3RlbS1hdXRoPC9ESVY+DQo8RElWPiMmbmJzcDtwYW1fc2VsaW51eC5zbyZuYnNw O2Nsb3NlJm5ic3A7c2hvdWxkJm5ic3A7YmUmbmJzcDt0aGUmbmJzcDtmaXJzdCZuYnNwO3Nlc3Np b24mbmJzcDtydWxlPC9ESVY+DQo8RElWPnNlc3Npb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDty ZXF1aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3BhbV9zZWxpbnV4LnNvJm5ic3A7 Y2xvc2U8L0RJVj4NCjxESVY+c2Vzc2lvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlcXVpcmVk Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGFtX3N0YWNrLnNvJm5ic3A7c2VydmljZT1z eXN0ZW0tYXV0aDwvRElWPg0KPERJVj5zZXNzaW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVx dWlyZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwYW1fbG9naW51aWQuc288L0RJVj4N CjxESVY+c2Vzc2lvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO29wdGlvbmFsJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7cGFtX2NvbnNvbGUuc288L0RJVj4NCjxESVY+IyZuYnNwO3BhbV9z ZWxpbnV4LnNvJm5ic3A7b3BlbiZuYnNwO3Nob3VsZCZuYnNwO2JlJm5ic3A7dGhlJm5ic3A7bGFz dCZuYnNwO3Nlc3Npb24mbmJzcDtydWxlPC9ESVY+DQo8RElWPnNlc3Npb24mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtyZXF1aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3BhbV9zZWxp bnV4LnNvJm5ic3A7b3BlbjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jZmYwMDAwPiMmbmJzcDtjYXQmbmJz cDsvZXRjL3BhbS5kL3N1PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jZmYwMDAwPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+IyVQQU0tMS4wPC9ESVY+DQo8RElWPjxGT05UIA0KY29s b3I9I2ZmMDAwMD5hdXRoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 c3VmZmljaWVudCZuYnNwOyZuYnNwOyZuYnNwO3BhbV9hZnMuc28mbmJzcDt0cnlfZmlyc3RfcGFz cyZuYnNwO2lnbm9yZV9yb290Jm5ic3A7c2V0ZW52X3Bhc3N3b3JkX2V4cGlyZXM8L0ZPTlQ+PC9E SVY+DQo8RElWPmF1dGgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtz dWZmaWNpZW50Jm5ic3A7Jm5ic3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8kSVNBL3BhbV9yb290b2su c288L0RJVj4NCjxESVY+IyZuYnNwO1VuY29tbWVudCZuYnNwO3RoZSZuYnNwO2ZvbGxvd2luZyZu YnNwO2xpbmUmbmJzcDt0byZuYnNwO2ltcGxpY2l0bHkmbmJzcDt0cnVzdCZuYnNwO3VzZXJzJm5i c3A7aW4mbmJzcDt0aGUmbmJzcDsid2hlZWwiJm5ic3A7Z3JvdXAuPC9ESVY+DQo8RElWPiNhdXRo Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7c3VmZmljaWVudCZuYnNw OyZuYnNwOyZuYnNwOy9saWIvc2VjdXJpdHkvJElTQS9wYW1fd2hlZWwuc28mbmJzcDt0cnVzdCZu YnNwO3VzZV91aWQ8L0RJVj4NCjxESVY+IyZuYnNwO1VuY29tbWVudCZuYnNwO3RoZSZuYnNwO2Zv bGxvd2luZyZuYnNwO2xpbmUmbmJzcDt0byZuYnNwO3JlcXVpcmUmbmJzcDthJm5ic3A7dXNlciZu YnNwO3RvJm5ic3A7YmUmbmJzcDtpbiZuYnNwO3RoZSZuYnNwOyJ3aGVlbCImbmJzcDtncm91cC48 L0RJVj4NCjxESVY+I2F1dGgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtyZXF1aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy9saWIvc2VjdXJpdHkvJElT QS9wYW1fd2hlZWwuc28mbmJzcDt1c2VfdWlkPC9ESVY+DQo8RElWPmF1dGgmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOy9saWIvc2VjdXJpdHkvJElTQS9wYW1fc3RhY2suc28mbmJzcDtzZXJ2aWNlPXN5 c3RlbS1hdXRoPC9ESVY+DQo8RElWPmFjY291bnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzdWZm aWNpZW50Jm5ic3A7Jm5ic3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8kSVNBL3BhbV9zdWNjZWVkX2lm LnNvJm5ic3A7dWlkPTAmbmJzcDt1c2VfdWlkJm5ic3A7cXVpZXQ8L0RJVj4NCjxESVY+YWNjb3Vu dCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlcXVpcmVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7L2xpYi9zZWN1cml0eS8kSVNBL3BhbV9zdGFjay5zbyZuYnNwO3NlcnZpY2U9c3lzdGVt LWF1dGg8L0RJVj4NCjxESVY+cGFzc3dvcmQmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlZCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy9saWIvc2VjdXJpdHkvJElTQS9wYW1fc3RhY2suc28m bmJzcDtzZXJ2aWNlPXN5c3RlbS1hdXRoPC9ESVY+DQo8RElWPiMmbmJzcDtwYW1fc2VsaW51eC5z byZuYnNwO2Nsb3NlJm5ic3A7bXVzdCZuYnNwO2JlJm5ic3A7Zmlyc3QmbmJzcDtzZXNzaW9uJm5i c3A7cnVsZTwvRElWPg0KPERJVj5zZXNzaW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVxdWly ZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3Nl bGludXguc28mbmJzcDtjbG9zZTwvRElWPg0KPERJVj5zZXNzaW9uJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7cmVxdWlyZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsvbGliL3NlY3VyaXR5 LyRJU0EvcGFtX3N0YWNrLnNvJm5ic3A7c2VydmljZT1zeXN0ZW0tYXV0aDwvRElWPg0KPERJVj4j Jm5ic3A7cGFtX3NlbGludXguc28mbmJzcDtvcGVuJm5ic3A7YW5kJm5ic3A7cGFtX3hhdXRoJm5i c3A7bXVzdCZuYnNwO2JlJm5ic3A7bGFzdCZuYnNwO3R3byZuYnNwO3Nlc3Npb24mbmJzcDtydWxl czwvRElWPg0KPERJVj5zZXNzaW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVxdWlyZWQmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3NlbGludXgu c28mbmJzcDtvcGVuPC9ESVY+DQo8RElWPnNlc3Npb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtv cHRpb25hbCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy9saWIvc2VjdXJpdHkvJElTQS9w YW1feGF1dGguc288L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj48 Rk9OVCBjb2xvcj0jZmYwMDAwPiMmbmJzcDtjYXQmbmJzcDsmbmJzcDsvZXRjL3BhbS5kL3NzaGQ8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSNmZjAwMDA+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj4jJVBBTS0xLjA8L0RJVj4NCjxESVY+PEZPTlQgDQpjb2xvcj0jZmYwMDAwPmF1dGgm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzdWZmaWNpZW50Jm5ic3A7 Jm5ic3A7Jm5ic3A7cGFtX2Fmcy5zbyZuYnNwO3RyeV9maXJzdF9wYXNzJm5ic3A7aWdub3JlX3Jv b3QmbmJzcDtzZXRlbnZfcGFzc3dvcmRfZXhwaXJlczwvRk9OVD48L0RJVj4NCjxESVY+YXV0aCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlcXVpcmVkJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGFtX3N0YWNrLnNvJm5ic3A7c2VydmljZT1zeXN0ZW0tYXV0 aDwvRElWPg0KPERJVj5hdXRoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7cmVxdWlyZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwYW1fbm9sb2dpbi5zbzwv RElWPg0KPERJVj5hY2NvdW50Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVxdWlyZWQmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwYW1fc3RhY2suc28mbmJzcDtzZXJ2aWNlPXN5c3RlbS1h dXRoPC9ESVY+DQo8RElWPnBhc3N3b3JkJm5ic3A7Jm5ic3A7Jm5ic3A7cmVxdWlyZWQmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwYW1fc3RhY2suc28mbmJzcDtzZXJ2aWNlPXN5c3RlbS1h dXRoPC9ESVY+DQo8RElWPnNlc3Npb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlZCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3BhbV9zdGFjay5zbyZuYnNwO3NlcnZpY2U9c3lz dGVtLWF1dGg8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjxGT05UIA0KY29sb3I9I2ZmMDAwMD4jY2F0Jm5i c3A7L2V0Yy9wYW0uZC9zdWRvPC9GT05UPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L0RJVj4NCjxESVY+IyVQQU0tMS4wPC9ESVY+DQo8 RElWPjxGT05UIA0KY29sb3I9I2ZmMDAwMD5hdXRoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7c3VmZmljaWVudCZuYnNwOyZuYnNwOyZuYnNwO3BhbV9hZnMuc28mbmJz cDt0cnlfZmlyc3RfcGFzcyZuYnNwO2lnbm9yZV9yb290Jm5ic3A7c2V0ZW52X3Bhc3N3b3JkX2V4 cGlyZXM8L0ZPTlQ+PC9ESVY+DQo8RElWPmF1dGgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtzdWZmaWNpZW50Jm5ic3A7Jm5ic3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8k SVNBL3BhbV9yb290b2suc288L0RJVj4NCjxESVY+IyZuYnNwO1VuY29tbWVudCZuYnNwO3RoZSZu YnNwO2ZvbGxvd2luZyZuYnNwO2xpbmUmbmJzcDt0byZuYnNwO2ltcGxpY2l0bHkmbmJzcDt0cnVz dCZuYnNwO3VzZXJzJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDsid2hlZWwiJm5ic3A7Z3JvdXAuPC9E SVY+DQo8RElWPiNhdXRoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 c3VmZmljaWVudCZuYnNwOyZuYnNwOyZuYnNwOy9saWIvc2VjdXJpdHkvJElTQS9wYW1fd2hlZWwu c28mbmJzcDt0cnVzdCZuYnNwO3VzZV91aWQ8L0RJVj4NCjxESVY+IyZuYnNwO1VuY29tbWVudCZu YnNwO3RoZSZuYnNwO2ZvbGxvd2luZyZuYnNwO2xpbmUmbmJzcDt0byZuYnNwO3JlcXVpcmUmbmJz cDthJm5ic3A7dXNlciZuYnNwO3RvJm5ic3A7YmUmbmJzcDtpbiZuYnNwO3RoZSZuYnNwOyJ3aGVl bCImbmJzcDtncm91cC48L0RJVj4NCjxESVY+I2F1dGgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy9s aWIvc2VjdXJpdHkvJElTQS9wYW1fd2hlZWwuc28mbmJzcDt1c2VfdWlkPC9ESVY+DQo8RElWPmF1 dGgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlZCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy9saWIvc2VjdXJpdHkvJElTQS9wYW1fc3RhY2suc28m bmJzcDtzZXJ2aWNlPXN5c3RlbS1hdXRoPC9ESVY+DQo8RElWPmFjY291bnQmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtzdWZmaWNpZW50Jm5ic3A7Jm5ic3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8kSVNB L3BhbV9zdWNjZWVkX2lmLnNvJm5ic3A7dWlkPTAmbmJzcDt1c2VfdWlkJm5ic3A7cXVpZXQ8L0RJ Vj4NCjxESVY+YWNjb3VudCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlcXVpcmVkJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8kSVNBL3BhbV9zdGFjay5zbyZuYnNw O3NlcnZpY2U9c3lzdGVtLWF1dGg8L0RJVj4NCjxESVY+cGFzc3dvcmQmbmJzcDsmbmJzcDsmbmJz cDtyZXF1aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy9saWIvc2VjdXJpdHkvJElT QS9wYW1fc3RhY2suc28mbmJzcDtzZXJ2aWNlPXN5c3RlbS1hdXRoPC9ESVY+DQo8RElWPiMmbmJz cDtwYW1fc2VsaW51eC5zbyZuYnNwO2Nsb3NlJm5ic3A7bXVzdCZuYnNwO2JlJm5ic3A7Zmlyc3Qm bmJzcDtzZXNzaW9uJm5ic3A7cnVsZTwvRElWPg0KPERJVj5zZXNzaW9uJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7cmVxdWlyZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsvbGliL3NlY3Vy aXR5LyRJU0EvcGFtX3NlbGludXguc28mbmJzcDtjbG9zZTwvRElWPg0KPERJVj5zZXNzaW9uJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVxdWlyZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3N0YWNrLnNvJm5ic3A7c2VydmljZT1zeXN0ZW0tYXV0 aDwvRElWPg0KPERJVj4jJm5ic3A7cGFtX3NlbGludXguc28mbmJzcDtvcGVuJm5ic3A7YW5kJm5i c3A7cGFtX3hhdXRoJm5ic3A7bXVzdCZuYnNwO2JlJm5ic3A7bGFzdCZuYnNwO3R3byZuYnNwO3Nl c3Npb24mbmJzcDtydWxlczwvRElWPg0KPERJVj5zZXNzaW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7cmVxdWlyZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsvbGliL3NlY3VyaXR5LyRJ U0EvcGFtX3NlbGludXguc28mbmJzcDtvcGVuPC9ESVY+DQo8RElWPnNlc3Npb24mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtvcHRpb25hbCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy9saWIv c2VjdXJpdHkvJElTQS9wYW1feGF1dGguc288L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlRoYW5rcyBhIGxv dC48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj48L0RJVj4NCjxE SVY+QmVzdCZuYnNwO1JlZ2FyZHM8L0RJVj4NCjxESVY+UWl1bGFuJm5ic3A7SHVhbmc8L0RJVj4N CjxESVY+MjAxMy0xMC0yMjwvRElWPg0KPERJVj49PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvRElWPg0KPERJVj5Db21w dXRpbmcmbmJzcDtjZW50ZXIsdGhlJm5ic3A7SW5zdGl0dXRlJm5ic3A7b2YmbmJzcDtIaWdoJm5i c3A7RW5lcmd5Jm5ic3A7UGh5c2ljcywmbmJzcDtDaGluYTwvRElWPg0KPERJVj5IdWFuZywmbmJz cDtRaXVsYW4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUZWw6Jm5ic3A7KCs4NikmbmJz cDsxMCZuYnNwOzg4MjMmbmJzcDs2MDEwLTEwNTwvRElWPg0KPERJVj5QLk8uJm5ic3A7Qm94Jm5i c3A7OTE4LTcmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtGYXg6Jm5ic3A7KCs4NikmbmJzcDsxMCZu YnNwOzg4MjMmbmJzcDs2ODM5PC9ESVY+DQo8RElWPkJlaWppbmcmbmJzcDsxMDAwNDkmbmJzcDsm bmJzcDtQLlIuJm5ic3A7Q2hpbmEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtFbWFpbDombmJzcDtodWFuZ3FsQGloZXAuYWMu Y248L0RJVj4NCjxESVY+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PSA8L0RJVj4NCjxIUiBjb2xvcj0jYjVjNGRmIFNJWkU9 MT4NCjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTVFJPTkc+5Y+R5Lu2 5Lq677yaPC9TVFJPTkc+IEJyYW5kb24gQWxsYmVyeSANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05HPuWPkemAgeaXtumXtO+8mjwvU1RST05HPiAy MDEzLTEwLTIyJm5ic3A7IDIxOjIzOjAzIA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTIgZmFjZT1WZXJkYW5hPjxTVFJPTkc+5pS25Lu25Lq677yaPC9TVFJPTkc+IGh1YW5ncWw7IG9w ZW5hZnMtaW5mbyANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFu YT48U1RST05HPuaKhOmAge+8mjwvU1RST05HPiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNp emU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz7kuLvpopjvvJo8L1NUUk9ORz4gUmU6IFtPcGVuQUZT XSBQQU0gDQphdXRoZW50aWNhdGlvbiBmYWlsZWQgb24gU0w2IDwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48L0ZPTlQ+IDwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTIgZmFjZT1WZXJkYW5hPg0KPERJVj5PbiZuYnNwOzEwLzIyLzEzJm5ic3A7MDU6MzgsJm5ic3A7 Imh1YW5ncWwiJm5ic3A7Jmx0O2h1YW5ncWxAaWhlcC5hYy5jbiZndDsmbmJzcDt3cm90ZTo8L0RJ Vj4NCjxESVY+Jmd0O1RoZSZuYnNwO3F1ZXN0aW9ucyZuYnNwO3N0dWNrJm5ic3A7bWUmbmJzcDtm b3ImbmJzcDt3ZWVrcy4mbmJzcDtEb2VzJm5ic3A7YW55b25lJm5ic3A7Z2V0Jm5ic3A7dGhlJm5i c3A7c2FtZSZuYnNwO3Byb2JsZW0mbmJzcDthbmQ8L0RJVj4NCjxESVY+Jmd0O2NvdWxkJm5ic3A7 eW91Jm5ic3A7Z2l2ZSZuYnNwO21lJm5ic3A7c29tZSZuYnNwO3N1Z2dlc3Rpb25zPzwvRElWPg0K PERJVj48L0RJVj4NCjxESVY+WW91Jm5ic3A7ZG9uJ3QmbmJzcDtwcm92aWRlJm5ic3A7ZW5vdWdo Jm5ic3A7aW5mb3JtYXRpb24sJm5ic3A7YmVjYXVzZSZuYnNwO2FsbCZuYnNwO3RoZSZuYnNwO3N0 YWNrcyZuYnNwO3lvdSZuYnNwO3Byb3ZpZGVkPC9ESVY+DQo8RElWPnVzZSZuYnNwO3BhbV9zdGFj ay5zbyZuYnNwO3RvJm5ic3A7bG9hZCZuYnNwO3RoZSZuYnNwO3N5c3RlbS1hdXRoJm5ic3A7c3Rh Y2smbmJzcDt3aGljaCZuYnNwO3lvdSZuYnNwO2RpZG4ndCZuYnNwO3Byb3ZpZGUuPC9ESVY+DQo8 RElWPjwvRElWPg0KPERJVj4tLSZuYnNwOzwvRElWPg0KPERJVj5icmFuZG9uJm5ic3A7cyZuYnNw O2FsbGJlcnkmbmJzcDtrZjhuaCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3NpbmUmbmJzcDtub21p bmUmbmJzcDthc3NvY2lhdGVzPC9ESVY+DQo8RElWPmFsbGJlcnkuYkBnbWFpbC5jb20mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtiYWxsYmVyeUBzaW5lbm9taW5lLm5l dDwvRElWPg0KPERJVj51bml4LCZuYnNwO29wZW5hZnMsJm5ic3A7a2VyYmVyb3MsJm5ic3A7aW5m cmFzdHJ1Y3R1cmUsJm5ic3A7eG1vbmFkPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj48L0RJVj4N CjxESVY+PC9ESVY+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon264050515273_=====-- From ballbery@sinenomine.net Tue Oct 22 15:58:41 2013 From: ballbery@sinenomine.net (Brandon Allbery) Date: Tue, 22 Oct 2013 14:58:41 +0000 Subject: [OpenAFS] PAM authentication failed on SL6 In-Reply-To: <201310222253567613742@ihep.ac.cn> Message-ID: --_000_CE8C0A4DE40ballberysinenominenet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 L2V0Yy9wYW0uZC9zeXN0ZW0tYXV0aCBpcyB3aGVyZSB0aG9zZSBlbnRyaWVzIGJlbG9uZywgYW5k IGJ5IHB1dHRpbmcgdGhlbSBkaXJlY3RseSBpbiB0aGVzZSBlbnRyaWVzIGluc3RlYWQgb2YgaW4g dGhlIGNlbnRyYWwgc3lzdGVtLWF1dGggc3RhY2sgeW91IGFyZSB2ZXJ5IHByb2JhYmx5IGNhdXNp bmcgY29uZmxpY3RzIHRoYXQgcHJldmVudCBsb2NhbCBhdXRoIChhcyBmb3Igcm9vdCkgYW5kIHBv c3NpYmx5IEFGUyBhdXRoIChiZWNhdXNlIGJvdGggbG9jYWwgcGFzc3dvcmQgYW5kIEFGUyBwYXNz d29yZCBhcmUgY2hlY2tlZCkgdG8gZmFpbC4gQnV0IEkgY2FuJ3QgYmUgY2VydGFpbiBvZiB0aGlz IGFzIHlvdSBoYXZlIG5vdCBzaG93biAvZXRjL3BhbS5kL3N5c3RlbS1hdXRoLCBhcyBJIG1lbnRp b25lZCBlYXJsaWVyLg0KDQoNCi0tDQoNCmJyYW5kb24gcyBhbGxiZXJ5IGtmOG5oICAgIHNpbmUg bm9taW5lIGFzc29jaWF0ZXMNCg0KYWxsYmVyeS5iQGdtYWlsLmNvbSAgICAgICBiYWxsYmVyeUBz aW5lbm9taW5lLm5ldA0KDQp1bml4LCBvcGVuYWZzLCBrZXJiZXJvcywgaW5mcmFzdHJ1Y3R1cmUs IHhtb25hZA0KDQoNCkZyb206IGh1YW5ncWwgPGh1YW5ncWxAaWhlcC5hYy5jbjxtYWlsdG86aHVh bmdxbEBpaGVwLmFjLmNuPj4NCkRhdGU6IFR1ZXNkYXksIE9jdG9iZXIgMjIsIDIwMTMgMTA6NTMN ClRvOiBCcmFuZG9uIEFsbGJlcnkgPGJhbGxiZXJ5QHNpbmVub21pbmUubmV0PG1haWx0bzpiYWxs YmVyeUBzaW5lbm9taW5lLm5ldD4+LCAib3BlbmFmcy1pbmZvQG9wZW5hZnMub3JnPG1haWx0bzpv cGVuYWZzLWluZm9Ab3BlbmFmcy5vcmc+IiA8b3BlbmFmcy1pbmZvQG9wZW5hZnMub3JnPG1haWx0 bzpvcGVuYWZzLWluZm9Ab3BlbmFmcy5vcmc+Pg0KU3ViamVjdDogUmU6IFJlOiBbT3BlbkFGU10g UEFNIGF1dGhlbnRpY2F0aW9uIGZhaWxlZCBvbiBTTDYNCg0KSGkgQnJhbmRvbiwNCg0KTWFueSB0 aGFua3MgZm9yIHlvdXIgcHJvbXB0IHJlcGx5Lg0KDQpUaGUgcmVkIGNoYXJhY3RlcnMgIGFyZSB0 aGUgcG9pbnRzIGZvciBQQU0gYXV0aGVudGljYXRpb24sIHlvdSBtZWFuIHRoZXJlIGlzIG5vdCBl bm91Z2ggaW5mb3JtYXRpb24sIGNvdWxkIHlvdSBleHByZXNzIHdoYXQgb3RoZXIgbWVzc2FnZSBj b3VsZCBJIHByb3ZpZGU/DQoNCg0KIyBjYXQgL2V0Yy9wYW0uZC9sb2dpbg0KDQojJVBBTS0xLjAN CmF1dGggICAgICAgc3VmZmljaWVudCAgIHBhbV9hZnMuc28gdHJ5X2ZpcnN0X3Bhc3MgaWdub3Jl X3Jvb3Qgc2V0ZW52X3Bhc3N3b3JkX2V4cGlyZXMNCmF1dGggICAgICAgcmVxdWlyZWQgICAgIHBh bV9zZWN1cmV0dHkuc28NCmF1dGggICAgICAgcmVxdWlyZWQgICAgIHBhbV9zdGFjay5zbyBzZXJ2 aWNlPXN5c3RlbS1hdXRoDQphdXRoICAgICAgIHJlcXVpcmVkICAgICBwYW1fbm9sb2dpbi5zbw0K YWNjb3VudCAgICByZXF1aXJlZCAgICAgcGFtX3N0YWNrLnNvIHNlcnZpY2U9c3lzdGVtLWF1dGgN CnBhc3N3b3JkICAgcmVxdWlyZWQgICAgIHBhbV9zdGFjay5zbyBzZXJ2aWNlPXN5c3RlbS1hdXRo DQojIHBhbV9zZWxpbnV4LnNvIGNsb3NlIHNob3VsZCBiZSB0aGUgZmlyc3Qgc2Vzc2lvbiBydWxl DQpzZXNzaW9uICAgIHJlcXVpcmVkICAgICBwYW1fc2VsaW51eC5zbyBjbG9zZQ0Kc2Vzc2lvbiAg ICByZXF1aXJlZCAgICAgcGFtX3N0YWNrLnNvIHNlcnZpY2U9c3lzdGVtLWF1dGgNCnNlc3Npb24g ICAgcmVxdWlyZWQgICAgIHBhbV9sb2dpbnVpZC5zbw0Kc2Vzc2lvbiAgICBvcHRpb25hbCAgICAg cGFtX2NvbnNvbGUuc28NCiMgcGFtX3NlbGludXguc28gb3BlbiBzaG91bGQgYmUgdGhlIGxhc3Qg c2Vzc2lvbiBydWxlDQpzZXNzaW9uICAgIHJlcXVpcmVkICAgICBwYW1fc2VsaW51eC5zbyBvcGVu DQoNCg0KIyBjYXQgL2V0Yy9wYW0uZC9zdQ0KDQojJVBBTS0xLjANCmF1dGggICAgICAgc3VmZmlj aWVudCAgIHBhbV9hZnMuc28gdHJ5X2ZpcnN0X3Bhc3MgaWdub3JlX3Jvb3Qgc2V0ZW52X3Bhc3N3 b3JkX2V4cGlyZXMNCmF1dGggICAgICAgc3VmZmljaWVudCAgIC9saWIvc2VjdXJpdHkvJElTQS9w YW1fcm9vdG9rLnNvDQojIFVuY29tbWVudCB0aGUgZm9sbG93aW5nIGxpbmUgdG8gaW1wbGljaXRs eSB0cnVzdCB1c2VycyBpbiB0aGUgIndoZWVsIiBncm91cC4NCiNhdXRoICAgICAgIHN1ZmZpY2ll bnQgICAvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3doZWVsLnNvIHRydXN0IHVzZV91aWQNCiMgVW5j b21tZW50IHRoZSBmb2xsb3dpbmcgbGluZSB0byByZXF1aXJlIGEgdXNlciB0byBiZSBpbiB0aGUg IndoZWVsIiBncm91cC4NCiNhdXRoICAgICAgIHJlcXVpcmVkICAgICAvbGliL3NlY3VyaXR5LyRJ U0EvcGFtX3doZWVsLnNvIHVzZV91aWQNCmF1dGggICAgICAgcmVxdWlyZWQgICAgIC9saWIvc2Vj dXJpdHkvJElTQS9wYW1fc3RhY2suc28gc2VydmljZT1zeXN0ZW0tYXV0aA0KYWNjb3VudCAgICBz dWZmaWNpZW50ICAgL2xpYi9zZWN1cml0eS8kSVNBL3BhbV9zdWNjZWVkX2lmLnNvIHVpZD0wIHVz ZV91aWQgcXVpZXQNCmFjY291bnQgICAgcmVxdWlyZWQgICAgIC9saWIvc2VjdXJpdHkvJElTQS9w YW1fc3RhY2suc28gc2VydmljZT1zeXN0ZW0tYXV0aA0KcGFzc3dvcmQgICByZXF1aXJlZCAgICAg L2xpYi9zZWN1cml0eS8kSVNBL3BhbV9zdGFjay5zbyBzZXJ2aWNlPXN5c3RlbS1hdXRoDQojIHBh bV9zZWxpbnV4LnNvIGNsb3NlIG11c3QgYmUgZmlyc3Qgc2Vzc2lvbiBydWxlDQpzZXNzaW9uICAg IHJlcXVpcmVkICAgICAvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3NlbGludXguc28gY2xvc2UNCnNl c3Npb24gICAgcmVxdWlyZWQgICAgIC9saWIvc2VjdXJpdHkvJElTQS9wYW1fc3RhY2suc28gc2Vy dmljZT1zeXN0ZW0tYXV0aA0KIyBwYW1fc2VsaW51eC5zbyBvcGVuIGFuZCBwYW1feGF1dGggbXVz dCBiZSBsYXN0IHR3byBzZXNzaW9uIHJ1bGVzDQpzZXNzaW9uICAgIHJlcXVpcmVkICAgICAvbGli L3NlY3VyaXR5LyRJU0EvcGFtX3NlbGludXguc28gb3Blbg0Kc2Vzc2lvbiAgICBvcHRpb25hbCAg ICAgL2xpYi9zZWN1cml0eS8kSVNBL3BhbV94YXV0aC5zbw0KDQojIGNhdCAgL2V0Yy9wYW0uZC9z c2hkDQoNCiMlUEFNLTEuMA0KYXV0aCAgICAgICBzdWZmaWNpZW50ICAgcGFtX2Fmcy5zbyB0cnlf Zmlyc3RfcGFzcyBpZ25vcmVfcm9vdCBzZXRlbnZfcGFzc3dvcmRfZXhwaXJlcw0KYXV0aCAgICAg ICByZXF1aXJlZCAgICAgcGFtX3N0YWNrLnNvIHNlcnZpY2U9c3lzdGVtLWF1dGgNCmF1dGggICAg ICAgcmVxdWlyZWQgICAgIHBhbV9ub2xvZ2luLnNvDQphY2NvdW50ICAgIHJlcXVpcmVkICAgICBw YW1fc3RhY2suc28gc2VydmljZT1zeXN0ZW0tYXV0aA0KcGFzc3dvcmQgICByZXF1aXJlZCAgICAg cGFtX3N0YWNrLnNvIHNlcnZpY2U9c3lzdGVtLWF1dGgNCnNlc3Npb24gICAgcmVxdWlyZWQgICAg IHBhbV9zdGFjay5zbyBzZXJ2aWNlPXN5c3RlbS1hdXRoDQoNCg0KI2NhdCAvZXRjL3BhbS5kL3N1 ZG8NCg0KIyVQQU0tMS4wDQphdXRoICAgICAgIHN1ZmZpY2llbnQgICBwYW1fYWZzLnNvIHRyeV9m aXJzdF9wYXNzIGlnbm9yZV9yb290IHNldGVudl9wYXNzd29yZF9leHBpcmVzDQphdXRoICAgICAg IHN1ZmZpY2llbnQgICAvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3Jvb3Rvay5zbw0KIyBVbmNvbW1l bnQgdGhlIGZvbGxvd2luZyBsaW5lIHRvIGltcGxpY2l0bHkgdHJ1c3QgdXNlcnMgaW4gdGhlICJ3 aGVlbCIgZ3JvdXAuDQojYXV0aCAgICAgICBzdWZmaWNpZW50ICAgL2xpYi9zZWN1cml0eS8kSVNB L3BhbV93aGVlbC5zbyB0cnVzdCB1c2VfdWlkDQojIFVuY29tbWVudCB0aGUgZm9sbG93aW5nIGxp bmUgdG8gcmVxdWlyZSBhIHVzZXIgdG8gYmUgaW4gdGhlICJ3aGVlbCIgZ3JvdXAuDQojYXV0aCAg ICAgICByZXF1aXJlZCAgICAgL2xpYi9zZWN1cml0eS8kSVNBL3BhbV93aGVlbC5zbyB1c2VfdWlk DQphdXRoICAgICAgIHJlcXVpcmVkICAgICAvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3N0YWNrLnNv IHNlcnZpY2U9c3lzdGVtLWF1dGgNCmFjY291bnQgICAgc3VmZmljaWVudCAgIC9saWIvc2VjdXJp dHkvJElTQS9wYW1fc3VjY2VlZF9pZi5zbyB1aWQ9MCB1c2VfdWlkIHF1aWV0DQphY2NvdW50ICAg IHJlcXVpcmVkICAgICAvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3N0YWNrLnNvIHNlcnZpY2U9c3lz dGVtLWF1dGgNCnBhc3N3b3JkICAgcmVxdWlyZWQgICAgIC9saWIvc2VjdXJpdHkvJElTQS9wYW1f c3RhY2suc28gc2VydmljZT1zeXN0ZW0tYXV0aA0KIyBwYW1fc2VsaW51eC5zbyBjbG9zZSBtdXN0 IGJlIGZpcnN0IHNlc3Npb24gcnVsZQ0Kc2Vzc2lvbiAgICByZXF1aXJlZCAgICAgL2xpYi9zZWN1 cml0eS8kSVNBL3BhbV9zZWxpbnV4LnNvIGNsb3NlDQpzZXNzaW9uICAgIHJlcXVpcmVkICAgICAv bGliL3NlY3VyaXR5LyRJU0EvcGFtX3N0YWNrLnNvIHNlcnZpY2U9c3lzdGVtLWF1dGgNCiMgcGFt X3NlbGludXguc28gb3BlbiBhbmQgcGFtX3hhdXRoIG11c3QgYmUgbGFzdCB0d28gc2Vzc2lvbiBy dWxlcw0Kc2Vzc2lvbiAgICByZXF1aXJlZCAgICAgL2xpYi9zZWN1cml0eS8kSVNBL3BhbV9zZWxp bnV4LnNvIG9wZW4NCnNlc3Npb24gICAgb3B0aW9uYWwgICAgIC9saWIvc2VjdXJpdHkvJElTQS9w YW1feGF1dGguc28NCg0KDQpUaGFua3MgYSBsb3QuDQoNCkJlc3QgUmVnYXJkcw0KUWl1bGFuIEh1 YW5nDQoyMDEzLTEwLTIyDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KQ29tcHV0aW5nIGNlbnRlcix0aGUgSW5zdGl0 dXRlIG9mIEhpZ2ggRW5lcmd5IFBoeXNpY3MsIENoaW5hDQpIdWFuZywgUWl1bGFuICAgICAgICAg ICAgICAgICAgICAgICAgVGVsOiAoKzg2KSAxMCA4ODIzIDYwMTAtMTA1DQpQLk8uIEJveCA5MTgt NyAgICAgICAgICAgICAgICAgICAgICAgRmF4OiAoKzg2KSAxMCA4ODIzIDY4MzkNCkJlaWppbmcg MTAwMDQ5ICBQLlIuIENoaW5hICAgICAgICAgICBFbWFpbDogaHVhbmdxbEBpaGVwLmFjLmNuPG1h aWx0bzpodWFuZ3FsQGloZXAuYWMuY24+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0K5Y+R5Lu25Lq677yaIEJyYW5kb24gQWxsYmVyeQ0K5Y+R6YCB5pe26Ze0 77yaIDIwMTMtMTAtMjIgIDIxOjIzOjAzDQrmlLbku7bkurrvvJogaHVhbmdxbDsgb3BlbmFmcy1p bmZvDQrmioTpgIHvvJoNCuS4u+mimO+8miBSZTogW09wZW5BRlNdIFBBTSBhdXRoZW50aWNhdGlv biBmYWlsZWQgb24gU0w2DQpPbiAxMC8yMi8xMyAwNTozOCwgImh1YW5ncWwiIDxodWFuZ3FsQGlo ZXAuYWMuY248bWFpbHRvOmh1YW5ncWxAaWhlcC5hYy5jbj4+IHdyb3RlOg0KPlRoZSBxdWVzdGlv bnMgc3R1Y2sgbWUgZm9yIHdlZWtzLiBEb2VzIGFueW9uZSBnZXQgdGhlIHNhbWUgcHJvYmxlbSBh bmQNCj5jb3VsZCB5b3UgZ2l2ZSBtZSBzb21lIHN1Z2dlc3Rpb25zPw0KWW91IGRvbid0IHByb3Zp ZGUgZW5vdWdoIGluZm9ybWF0aW9uLCBiZWNhdXNlIGFsbCB0aGUgc3RhY2tzIHlvdSBwcm92aWRl ZA0KdXNlIHBhbV9zdGFjay5zbyB0byBsb2FkIHRoZSBzeXN0ZW0tYXV0aCBzdGFjayB3aGljaCB5 b3UgZGlkbid0IHByb3ZpZGUuDQotLQ0KYnJhbmRvbiBzIGFsbGJlcnkga2Y4bmggICAgc2luZSBu b21pbmUgYXNzb2NpYXRlcw0KYWxsYmVyeS5iQGdtYWlsLmNvbTxtYWlsdG86YWxsYmVyeS5iQGdt YWlsLmNvbT4gICAgICAgYmFsbGJlcnlAc2luZW5vbWluZS5uZXQ8bWFpbHRvOmJhbGxiZXJ5QHNp bmVub21pbmUubmV0Pg0KdW5peCwgb3BlbmFmcywga2VyYmVyb3MsIGluZnJhc3RydWN0dXJlLCB4 bW9uYWQNCg== --_000_CE8C0A4DE40ballberysinenominenet_ Content-Type: text/html; charset="utf-8" Content-ID: <9D590CB4535F0344ACD801B55F3A679C@mex05.mlsrvr.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+DQo8ZGl2Pi9l dGMvcGFtLmQvc3lzdGVtLWF1dGggaXMgd2hlcmUgdGhvc2UgZW50cmllcyBiZWxvbmcsIGFuZCBi eSBwdXR0aW5nIHRoZW0gZGlyZWN0bHkgaW4gdGhlc2UgZW50cmllcyBpbnN0ZWFkIG9mIGluIHRo ZSBjZW50cmFsIHN5c3RlbS1hdXRoIHN0YWNrIHlvdSBhcmUgdmVyeSBwcm9iYWJseSBjYXVzaW5n IGNvbmZsaWN0cyB0aGF0IHByZXZlbnQgbG9jYWwgYXV0aCAoYXMgZm9yIHJvb3QpIGFuZCBwb3Nz aWJseSBBRlMgYXV0aCAoYmVjYXVzZQ0KIGJvdGggbG9jYWwgcGFzc3dvcmQgYW5kIEFGUyBwYXNz d29yZCBhcmUgY2hlY2tlZCkgdG8gZmFpbC4gQnV0IEkgY2FuJ3QgYmUgY2VydGFpbiBvZiB0aGlz IGFzIHlvdSBoYXZlIG5vdCBzaG93biAvZXRjL3BhbS5kL3N5c3RlbS1hdXRoLCBhcyBJIG1lbnRp b25lZCBlYXJsaWVyLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0i bWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDb25zb2xhczsgIj4tLSZuYnNwOzwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENvbnNvbGFzOyAiPmJyYW5kb24gcyBhbGxi ZXJ5IGtmOG5oICZuYnNwOyAmbmJzcDtzaW5lIG5vbWluZSBhc3NvY2lhdGVzPC9wPg0KPHAgc3R5 bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ29uc29sYXM7ICI+YWxsYmVyeS5iQGdtYWls LmNvbSAmbmJzcDsgJm5ic3A7ICZuYnNwOyBiYWxsYmVyeUBzaW5lbm9taW5lLm5ldDwvcD4NCjxw IHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENvbnNvbGFzOyAiPnVuaXgsIG9wZW5h ZnMsIGtlcmJlcm9zLCBpbmZyYXN0cnVjdHVyZSwgeG1vbmFkPC9wPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNf Qk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6 ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRp dW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQ QURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRm IDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+ DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPmh1YW5ncWwgJmx0 OzxhIGhyZWY9Im1haWx0bzpodWFuZ3FsQGloZXAuYWMuY24iPmh1YW5ncWxAaWhlcC5hYy5jbjwv YT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5U dWVzZGF5LCBPY3RvYmVyIDIyLCAyMDEzIDEwOjUzPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPlRvOiA8L3NwYW4+QnJhbmRvbiBBbGxiZXJ5ICZsdDs8YSBocmVmPSJtYWlsdG86 YmFsbGJlcnlAc2luZW5vbWluZS5uZXQiPmJhbGxiZXJ5QHNpbmVub21pbmUubmV0PC9hPiZndDss ICZxdW90OzxhIGhyZWY9Im1haWx0bzpvcGVuYWZzLWluZm9Ab3BlbmFmcy5vcmciPm9wZW5hZnMt aW5mb0BvcGVuYWZzLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpvcGVuYWZzLWlu Zm9Ab3BlbmFmcy5vcmciPm9wZW5hZnMtaW5mb0BvcGVuYWZzLm9yZzwvYT4mZ3Q7PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogUmU6IFtPcGVu QUZTXSBQQU0gYXV0aGVudGljYXRpb24gZmFpbGVkIG9uIFNMNjxicj4NCjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1IiIGNvbnRlbnQ9Ik1TSFRN TCAxMC4wMC45MjAwLjE2NzIxIj4NCjxzdHlsZT5AZm9udC1mYWNlIHsNCglmb250LWZhbWlseTog 5a6L5L2TOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFZlcmRhbmE7DQp9DQpAZm9u dC1mYWNlIHsNCglmb250LWZhbWlseTogQOWui+S9kzsNCn0NCkBwYWdlIFNlY3Rpb24xIHtzaXpl OiA1OTUuM3B0IDg0MS45cHQ7IG1hcmdpbjogNzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0OyBs YXlvdXQtZ3JpZDogMTUuNnB0OyB9DQpQLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMC41cHQ7 IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFS R0lOOiAwY20gMGNtIDBwdDsgVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGgNCn0NCkxJLk1z b05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJv bWFuIjsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1KVVNU SUZZOiBpbnRlci1pZGVvZ3JhcGgNCn0NCkRJVi5Nc29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTAu NXB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJR046IGp1c3RpZnk7 IE1BUkdJTjogMGNtIDBjbSAwcHQ7IFRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoDQp9DQpB Omxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BB Ti5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGlu ZQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJT046IHVuZGVy bGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmtGb2xsb3dlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVY VC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uRW1haWxTdHlsZTE3IHsNCglGT05ULUZB TUlMWTogVmVyZGFuYTsgRk9OVC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZP TlQtU1RZTEU6IG5vcm1hbDsgVEVYVC1ERUNPUkFUSU9OOiBub25lOyBtc28tc3R5bGUtdHlwZTog cGVyc29uYWwtY29tcG9zZQ0KfQ0KRElWLlNlY3Rpb24xIHsNCglwYWdlOiBTZWN0aW9uMQ0KfQ0K VU5LTk9XTiB7DQoJRk9OVC1TSVpFOiAxMHB0DQp9DQpCTE9DS1FVT1RFIHsNCglNQVJHSU4tQk9U VE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW07IE1BUkdJTi1UT1A6IDBweA0KfQ0KT0wgew0KCU1B UkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4DQp9DQpVTCB7DQoJTUFSR0lOLUJPVFRP TTogMHB4OyBNQVJHSU4tVE9QOiAwcHgNCn0NCjwvc3R5bGU+DQo8ZGl2IHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hOyBNQVJHSU46IDEwcHgiPg0KPGRpdj4NCjxk aXY+SGkgQnJhbmRvbiw8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk1hbnkgdGhhbmtz IGZvciB5b3VyIHByb21wdCByZXBseS4gPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5U aGUgcmVkIGNoYXJhY3RlcnMmbmJzcDsgYXJlIHRoZSBwb2ludHMgZm9yIFBBTSBhdXRoZW50aWNh dGlvbiwgeW91IG1lYW4gdGhlcmUgaXMgbm90IGVub3VnaCBpbmZvcm1hdGlvbiwgY291bGQgeW91 IGV4cHJlc3Mgd2hhdCBvdGhlciBtZXNzYWdlIGNvdWxkIEkgcHJvdmlkZT88L2Rpdj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iI2ZmMDAw MCI+IyZuYnNwO2NhdCZuYnNwOy9ldGMvcGFtLmQvbG9naW48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxm b250IGNvbG9yPSIjZmYwMDAwIj48L2ZvbnQ+Jm5ic3A7PC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRp dj4jJVBBTS0xLjA8L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiNmZjAwMDAiPmF1dGgmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzdWZmaWNpZW50Jm5ic3A7Jm5ic3A7 Jm5ic3A7cGFtX2Fmcy5zbyZuYnNwO3RyeV9maXJzdF9wYXNzJm5ic3A7aWdub3JlX3Jvb3QmbmJz cDtzZXRlbnZfcGFzc3dvcmRfZXhwaXJlczwvZm9udD48L2Rpdj4NCjxkaXY+YXV0aCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlcXVpcmVkJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7cGFtX3NlY3VyZXR0eS5zbzwvZGl2Pg0KPGRpdj5hdXRoJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVxdWlyZWQmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtwYW1fc3RhY2suc28mbmJzcDtzZXJ2aWNlPXN5c3RlbS1hdXRoPC9kaXY+ DQo8ZGl2PmF1dGgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1 aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3BhbV9ub2xvZ2luLnNvPC9kaXY+DQo8 ZGl2PmFjY291bnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlZCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO3BhbV9zdGFjay5zbyZuYnNwO3NlcnZpY2U9c3lzdGVtLWF1dGg8L2Rp dj4NCjxkaXY+cGFzc3dvcmQmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlZCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO3BhbV9zdGFjay5zbyZuYnNwO3NlcnZpY2U9c3lzdGVtLWF1dGg8L2Rp dj4NCjxkaXY+IyZuYnNwO3BhbV9zZWxpbnV4LnNvJm5ic3A7Y2xvc2UmbmJzcDtzaG91bGQmbmJz cDtiZSZuYnNwO3RoZSZuYnNwO2ZpcnN0Jm5ic3A7c2Vzc2lvbiZuYnNwO3J1bGU8L2Rpdj4NCjxk aXY+c2Vzc2lvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlcXVpcmVkJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7cGFtX3NlbGludXguc28mbmJzcDtjbG9zZTwvZGl2Pg0KPGRpdj5zZXNz aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVxdWlyZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtwYW1fc3RhY2suc28mbmJzcDtzZXJ2aWNlPXN5c3RlbS1hdXRoPC9kaXY+DQo8ZGl2 PnNlc3Npb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlZCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO3BhbV9sb2dpbnVpZC5zbzwvZGl2Pg0KPGRpdj5zZXNzaW9uJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7b3B0aW9uYWwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwYW1f Y29uc29sZS5zbzwvZGl2Pg0KPGRpdj4jJm5ic3A7cGFtX3NlbGludXguc28mbmJzcDtvcGVuJm5i c3A7c2hvdWxkJm5ic3A7YmUmbmJzcDt0aGUmbmJzcDtsYXN0Jm5ic3A7c2Vzc2lvbiZuYnNwO3J1 bGU8L2Rpdj4NCjxkaXY+c2Vzc2lvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlcXVpcmVkJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGFtX3NlbGludXguc28mbmJzcDtvcGVuPC9kaXY+ DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2 Pjxmb250IGNvbG9yPSIjZmYwMDAwIj4jJm5ic3A7Y2F0Jm5ic3A7L2V0Yy9wYW0uZC9zdTwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiNmZjAwMDAiPjwvZm9udD4mbmJzcDs8L2Rpdj4N CjxkaXY+IyVQQU0tMS4wPC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjZmYwMDAwIj5hdXRoJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7c3VmZmljaWVudCZuYnNwOyZu YnNwOyZuYnNwO3BhbV9hZnMuc28mbmJzcDt0cnlfZmlyc3RfcGFzcyZuYnNwO2lnbm9yZV9yb290 Jm5ic3A7c2V0ZW52X3Bhc3N3b3JkX2V4cGlyZXM8L2ZvbnQ+PC9kaXY+DQo8ZGl2PmF1dGgmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzdWZmaWNpZW50Jm5ic3A7Jm5i c3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8kSVNBL3BhbV9yb290b2suc288L2Rpdj4NCjxkaXY+IyZu YnNwO1VuY29tbWVudCZuYnNwO3RoZSZuYnNwO2ZvbGxvd2luZyZuYnNwO2xpbmUmbmJzcDt0byZu YnNwO2ltcGxpY2l0bHkmbmJzcDt0cnVzdCZuYnNwO3VzZXJzJm5ic3A7aW4mbmJzcDt0aGUmbmJz cDsmcXVvdDt3aGVlbCZxdW90OyZuYnNwO2dyb3VwLjwvZGl2Pg0KPGRpdj4jYXV0aCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3N1ZmZpY2llbnQmbmJzcDsmbmJzcDsm bmJzcDsvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3doZWVsLnNvJm5ic3A7dHJ1c3QmbmJzcDt1c2Vf dWlkPC9kaXY+DQo8ZGl2PiMmbmJzcDtVbmNvbW1lbnQmbmJzcDt0aGUmbmJzcDtmb2xsb3dpbmcm bmJzcDtsaW5lJm5ic3A7dG8mbmJzcDtyZXF1aXJlJm5ic3A7YSZuYnNwO3VzZXImbmJzcDt0byZu YnNwO2JlJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDsmcXVvdDt3aGVlbCZxdW90OyZuYnNwO2dyb3Vw LjwvZGl2Pg0KPGRpdj4jYXV0aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO3JlcXVpcmVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8k SVNBL3BhbV93aGVlbC5zbyZuYnNwO3VzZV91aWQ8L2Rpdj4NCjxkaXY+YXV0aCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlcXVpcmVkJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8kSVNBL3BhbV9zdGFjay5zbyZuYnNwO3NlcnZpY2U9 c3lzdGVtLWF1dGg8L2Rpdj4NCjxkaXY+YWNjb3VudCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3N1 ZmZpY2llbnQmbmJzcDsmbmJzcDsmbmJzcDsvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3N1Y2NlZWRf aWYuc28mbmJzcDt1aWQ9MCZuYnNwO3VzZV91aWQmbmJzcDtxdWlldDwvZGl2Pg0KPGRpdj5hY2Nv dW50Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVxdWlyZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3N0YWNrLnNvJm5ic3A7c2VydmljZT1zeXN0 ZW0tYXV0aDwvZGl2Pg0KPGRpdj5wYXNzd29yZCZuYnNwOyZuYnNwOyZuYnNwO3JlcXVpcmVkJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8kSVNBL3BhbV9zdGFjay5z byZuYnNwO3NlcnZpY2U9c3lzdGVtLWF1dGg8L2Rpdj4NCjxkaXY+IyZuYnNwO3BhbV9zZWxpbnV4 LnNvJm5ic3A7Y2xvc2UmbmJzcDttdXN0Jm5ic3A7YmUmbmJzcDtmaXJzdCZuYnNwO3Nlc3Npb24m bmJzcDtydWxlPC9kaXY+DQo8ZGl2PnNlc3Npb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1 aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy9saWIvc2VjdXJpdHkvJElTQS9wYW1f c2VsaW51eC5zbyZuYnNwO2Nsb3NlPC9kaXY+DQo8ZGl2PnNlc3Npb24mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtyZXF1aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy9saWIvc2VjdXJp dHkvJElTQS9wYW1fc3RhY2suc28mbmJzcDtzZXJ2aWNlPXN5c3RlbS1hdXRoPC9kaXY+DQo8ZGl2 PiMmbmJzcDtwYW1fc2VsaW51eC5zbyZuYnNwO29wZW4mbmJzcDthbmQmbmJzcDtwYW1feGF1dGgm bmJzcDttdXN0Jm5ic3A7YmUmbmJzcDtsYXN0Jm5ic3A7dHdvJm5ic3A7c2Vzc2lvbiZuYnNwO3J1 bGVzPC9kaXY+DQo8ZGl2PnNlc3Npb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlZCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy9saWIvc2VjdXJpdHkvJElTQS9wYW1fc2VsaW51 eC5zbyZuYnNwO29wZW48L2Rpdj4NCjxkaXY+c2Vzc2lvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O29wdGlvbmFsJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8kSVNB L3BhbV94YXV0aC5zbzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2 Pjxmb250IGNvbG9yPSIjZmYwMDAwIj4jJm5ic3A7Y2F0Jm5ic3A7Jm5ic3A7L2V0Yy9wYW0uZC9z c2hkPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iI2ZmMDAwMCI+PC9mb250PiZuYnNw OzwvZGl2Pg0KPGRpdj4jJVBBTS0xLjA8L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiNmZjAwMDAi PmF1dGgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzdWZmaWNpZW50 Jm5ic3A7Jm5ic3A7Jm5ic3A7cGFtX2Fmcy5zbyZuYnNwO3RyeV9maXJzdF9wYXNzJm5ic3A7aWdu b3JlX3Jvb3QmbmJzcDtzZXRlbnZfcGFzc3dvcmRfZXhwaXJlczwvZm9udD48L2Rpdj4NCjxkaXY+ YXV0aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlcXVpcmVkJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGFtX3N0YWNrLnNvJm5ic3A7c2VydmljZT1zeXN0 ZW0tYXV0aDwvZGl2Pg0KPGRpdj5hdXRoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7cmVxdWlyZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwYW1fbm9sb2dp bi5zbzwvZGl2Pg0KPGRpdj5hY2NvdW50Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVxdWlyZWQm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwYW1fc3RhY2suc28mbmJzcDtzZXJ2aWNlPXN5 c3RlbS1hdXRoPC9kaXY+DQo8ZGl2PnBhc3N3b3JkJm5ic3A7Jm5ic3A7Jm5ic3A7cmVxdWlyZWQm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwYW1fc3RhY2suc28mbmJzcDtzZXJ2aWNlPXN5 c3RlbS1hdXRoPC9kaXY+DQo8ZGl2PnNlc3Npb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1 aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3BhbV9zdGFjay5zbyZuYnNwO3NlcnZp Y2U9c3lzdGVtLWF1dGg8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj48L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjZmYwMDAwIj4j Y2F0Jm5ic3A7L2V0Yy9wYW0uZC9zdWRvPC9mb250PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L2Rpdj4NCjxkaXY+IyVQQU0tMS4wPC9k aXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjZmYwMDAwIj5hdXRoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7c3VmZmljaWVudCZuYnNwOyZuYnNwOyZuYnNwO3BhbV9hZnMu c28mbmJzcDt0cnlfZmlyc3RfcGFzcyZuYnNwO2lnbm9yZV9yb290Jm5ic3A7c2V0ZW52X3Bhc3N3 b3JkX2V4cGlyZXM8L2ZvbnQ+PC9kaXY+DQo8ZGl2PmF1dGgmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtzdWZmaWNpZW50Jm5ic3A7Jm5ic3A7Jm5ic3A7L2xpYi9zZWN1 cml0eS8kSVNBL3BhbV9yb290b2suc288L2Rpdj4NCjxkaXY+IyZuYnNwO1VuY29tbWVudCZuYnNw O3RoZSZuYnNwO2ZvbGxvd2luZyZuYnNwO2xpbmUmbmJzcDt0byZuYnNwO2ltcGxpY2l0bHkmbmJz cDt0cnVzdCZuYnNwO3VzZXJzJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDsmcXVvdDt3aGVlbCZxdW90 OyZuYnNwO2dyb3VwLjwvZGl2Pg0KPGRpdj4jYXV0aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO3N1ZmZpY2llbnQmbmJzcDsmbmJzcDsmbmJzcDsvbGliL3NlY3VyaXR5 LyRJU0EvcGFtX3doZWVsLnNvJm5ic3A7dHJ1c3QmbmJzcDt1c2VfdWlkPC9kaXY+DQo8ZGl2PiMm bmJzcDtVbmNvbW1lbnQmbmJzcDt0aGUmbmJzcDtmb2xsb3dpbmcmbmJzcDtsaW5lJm5ic3A7dG8m bmJzcDtyZXF1aXJlJm5ic3A7YSZuYnNwO3VzZXImbmJzcDt0byZuYnNwO2JlJm5ic3A7aW4mbmJz cDt0aGUmbmJzcDsmcXVvdDt3aGVlbCZxdW90OyZuYnNwO2dyb3VwLjwvZGl2Pg0KPGRpdj4jYXV0 aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlcXVpcmVkJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8kSVNBL3BhbV93aGVlbC5zbyZu YnNwO3VzZV91aWQ8L2Rpdj4NCjxkaXY+YXV0aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO3JlcXVpcmVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7L2xpYi9z ZWN1cml0eS8kSVNBL3BhbV9zdGFjay5zbyZuYnNwO3NlcnZpY2U9c3lzdGVtLWF1dGg8L2Rpdj4N CjxkaXY+YWNjb3VudCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3N1ZmZpY2llbnQmbmJzcDsmbmJz cDsmbmJzcDsvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3N1Y2NlZWRfaWYuc28mbmJzcDt1aWQ9MCZu YnNwO3VzZV91aWQmbmJzcDtxdWlldDwvZGl2Pg0KPGRpdj5hY2NvdW50Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7cmVxdWlyZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsvbGliL3NlY3Vy aXR5LyRJU0EvcGFtX3N0YWNrLnNvJm5ic3A7c2VydmljZT1zeXN0ZW0tYXV0aDwvZGl2Pg0KPGRp dj5wYXNzd29yZCZuYnNwOyZuYnNwOyZuYnNwO3JlcXVpcmVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8kSVNBL3BhbV9zdGFjay5zbyZuYnNwO3NlcnZpY2U9c3lz dGVtLWF1dGg8L2Rpdj4NCjxkaXY+IyZuYnNwO3BhbV9zZWxpbnV4LnNvJm5ic3A7Y2xvc2UmbmJz cDttdXN0Jm5ic3A7YmUmbmJzcDtmaXJzdCZuYnNwO3Nlc3Npb24mbmJzcDtydWxlPC9kaXY+DQo8 ZGl2PnNlc3Npb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlZCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOy9saWIvc2VjdXJpdHkvJElTQS9wYW1fc2VsaW51eC5zbyZuYnNwO2Ns b3NlPC9kaXY+DQo8ZGl2PnNlc3Npb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlZCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy9saWIvc2VjdXJpdHkvJElTQS9wYW1fc3RhY2su c28mbmJzcDtzZXJ2aWNlPXN5c3RlbS1hdXRoPC9kaXY+DQo8ZGl2PiMmbmJzcDtwYW1fc2VsaW51 eC5zbyZuYnNwO29wZW4mbmJzcDthbmQmbmJzcDtwYW1feGF1dGgmbmJzcDttdXN0Jm5ic3A7YmUm bmJzcDtsYXN0Jm5ic3A7dHdvJm5ic3A7c2Vzc2lvbiZuYnNwO3J1bGVzPC9kaXY+DQo8ZGl2PnNl c3Npb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOy9saWIvc2VjdXJpdHkvJElTQS9wYW1fc2VsaW51eC5zbyZuYnNwO29wZW48L2Rp dj4NCjxkaXY+c2Vzc2lvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO29wdGlvbmFsJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8kSVNBL3BhbV94YXV0aC5zbzwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj4mbmJz cDs8L2Rpdj4NCjxkaXY+VGhhbmtzIGEgbG90LjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxk aXY+PC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj5CZXN0Jm5ic3A7UmVnYXJkczwvZGl2Pg0KPGRp dj5RaXVsYW4mbmJzcDtIdWFuZzwvZGl2Pg0KPGRpdj4yMDEzLTEwLTIyPC9kaXY+DQo8ZGl2Pj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PC9kaXY+DQo8ZGl2PkNvbXB1dGluZyZuYnNwO2NlbnRlcix0aGUmbmJzcDtJbnN0 aXR1dGUmbmJzcDtvZiZuYnNwO0hpZ2gmbmJzcDtFbmVyZ3kmbmJzcDtQaHlzaWNzLCZuYnNwO0No aW5hPC9kaXY+DQo8ZGl2Pkh1YW5nLCZuYnNwO1FpdWxhbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO1RlbDombmJzcDsoJiM0Mzs4NikmbmJzcDsxMCZuYnNwOzg4MjMmbmJzcDs2MDEwLTEw NTwvZGl2Pg0KPGRpdj5QLk8uJm5ic3A7Qm94Jm5ic3A7OTE4LTcmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtGYXg6Jm5ic3A7KCYjNDM7ODYpJm5ic3A7MTAmbmJzcDs4ODIzJm5ic3A7NjgzOTwvZGl2 Pg0KPGRpdj5CZWlqaW5nJm5ic3A7MTAwMDQ5Jm5ic3A7Jm5ic3A7UC5SLiZuYnNwO0NoaW5hJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7RW1haWw6Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmh1YW5ncWxAaWhlcC5hYy5jbiI+aHVh bmdxbEBpaGVwLmFjLmNuPC9hPjwvZGl2Pg0KPGRpdj49PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09IDwvZGl2Pg0KPGhyIGNv bG9yPSIjYjVjNGRmIiBzaXplPSIxIj4NCjwvZGl2Pg0KPGRpdj48Zm9udCBzaXplPSIyIiBmYWNl PSJWZXJkYW5hIj48c3Ryb25nPuWPkeS7tuS6uu+8mjwvc3Ryb25nPiBCcmFuZG9uIEFsbGJlcnkg PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBzaXplPSIyIiBmYWNlPSJWZXJkYW5hIj48c3Ryb25n PuWPkemAgeaXtumXtO+8mjwvc3Ryb25nPiAyMDEzLTEwLTIyJm5ic3A7IDIxOjIzOjAzIDwvZm9u dD4NCjwvZGl2Pg0KPGRpdj48Zm9udCBzaXplPSIyIiBmYWNlPSJWZXJkYW5hIj48c3Ryb25nPuaU tuS7tuS6uu+8mjwvc3Ryb25nPiBodWFuZ3FsOyBvcGVuYWZzLWluZm8gPC9mb250Pg0KPC9kaXY+ DQo8ZGl2Pjxmb250IHNpemU9IjIiIGZhY2U9IlZlcmRhbmEiPjxzdHJvbmc+5oqE6YCB77yaPC9z dHJvbmc+IDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVmVyZGFuYSI+ PHN0cm9uZz7kuLvpopjvvJo8L3N0cm9uZz4gUmU6IFtPcGVuQUZTXSBQQU0gYXV0aGVudGljYXRp b24gZmFpbGVkIG9uIFNMNg0KPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBzaXplPSIyIiBmYWNl PSJWZXJkYW5hIj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IHNpemU9IjIiIGZhY2U9IlZlcmRh bmEiPg0KPGRpdj5PbiZuYnNwOzEwLzIyLzEzJm5ic3A7MDU6MzgsJm5ic3A7JnF1b3Q7aHVhbmdx bCZxdW90OyZuYnNwOyZsdDs8YSBocmVmPSJtYWlsdG86aHVhbmdxbEBpaGVwLmFjLmNuIj5odWFu Z3FsQGloZXAuYWMuY248L2E+Jmd0OyZuYnNwO3dyb3RlOjwvZGl2Pg0KPGRpdj4mZ3Q7VGhlJm5i c3A7cXVlc3Rpb25zJm5ic3A7c3R1Y2smbmJzcDttZSZuYnNwO2ZvciZuYnNwO3dlZWtzLiZuYnNw O0RvZXMmbmJzcDthbnlvbmUmbmJzcDtnZXQmbmJzcDt0aGUmbmJzcDtzYW1lJm5ic3A7cHJvYmxl bSZuYnNwO2FuZDwvZGl2Pg0KPGRpdj4mZ3Q7Y291bGQmbmJzcDt5b3UmbmJzcDtnaXZlJm5ic3A7 bWUmbmJzcDtzb21lJm5ic3A7c3VnZ2VzdGlvbnM/PC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj5Z b3UmbmJzcDtkb24ndCZuYnNwO3Byb3ZpZGUmbmJzcDtlbm91Z2gmbmJzcDtpbmZvcm1hdGlvbiwm bmJzcDtiZWNhdXNlJm5ic3A7YWxsJm5ic3A7dGhlJm5ic3A7c3RhY2tzJm5ic3A7eW91Jm5ic3A7 cHJvdmlkZWQ8L2Rpdj4NCjxkaXY+dXNlJm5ic3A7cGFtX3N0YWNrLnNvJm5ic3A7dG8mbmJzcDts b2FkJm5ic3A7dGhlJm5ic3A7c3lzdGVtLWF1dGgmbmJzcDtzdGFjayZuYnNwO3doaWNoJm5ic3A7 eW91Jm5ic3A7ZGlkbid0Jm5ic3A7cHJvdmlkZS48L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2Pi0t Jm5ic3A7PC9kaXY+DQo8ZGl2PmJyYW5kb24mbmJzcDtzJm5ic3A7YWxsYmVyeSZuYnNwO2tmOG5o Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7c2luZSZuYnNwO25vbWluZSZuYnNwO2Fzc29jaWF0ZXM8 L2Rpdj4NCjxkaXY+PGEgaHJlZj0ibWFpbHRvOmFsbGJlcnkuYkBnbWFpbC5jb20iPmFsbGJlcnku YkBnbWFpbC5jb208L2E+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 PGEgaHJlZj0ibWFpbHRvOmJhbGxiZXJ5QHNpbmVub21pbmUubmV0Ij5iYWxsYmVyeUBzaW5lbm9t aW5lLm5ldDwvYT48L2Rpdj4NCjxkaXY+dW5peCwmbmJzcDtvcGVuYWZzLCZuYnNwO2tlcmJlcm9z LCZuYnNwO2luZnJhc3RydWN0dXJlLCZuYnNwO3htb25hZDwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxk aXY+PC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv c3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CE8C0A4DE40ballberysinenominenet_-- From huangql@ihep.ac.cn Tue Oct 22 16:27:58 2013 From: huangql@ihep.ac.cn (=?utf-8?B?aHVhbmdxbA==?=) Date: Tue, 22 Oct 2013 23:27:58 +0800 Subject: [OpenAFS] =?utf-8?B?UmU6IFJlOiBbT3BlbkFGU10gUEFNIGF1dGhlbnRpY2F0aW9uIGZhaWxlZCBvbiBTTDY=?= Message-ID: <201310222327577025308@ihep.ac.cn> This is a multi-part message in MIME format. --=====003_Dragon804576371781_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZWFyIEJyYW5kb24sDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2guDQoNCkkgZG9uJ3QgZG8gYW55 IG1vZGlmaWNhdGlvbiBmb3IgdGhlIGZpbGUgL2V0Yy9wYW0uZC9zeXN0ZW0tYXV0aCwgdGhlIGNv bnRlbnQgaXMgOg0KDQpbcm9vdEBid3MwNDgxIH5dIyB2aSAvZXRjL3BhbS5kL3N5c3RlbS1hdXRo DQojJVBBTS0xLjANCiMgVGhpcyBmaWxlIGlzIGF1dG8tZ2VuZXJhdGVkLg0KIyBVc2VyIGNoYW5n ZXMgd2lsbCBiZSBkZXN0cm95ZWQgdGhlIG5leHQgdGltZSBhdXRoY29uZmlnIGlzIHJ1bi4NCmF1 dGggICAgICAgIHJlcXVpcmVkICAgICAgcGFtX2Vudi5zbw0KYXV0aCAgICAgICAgc3VmZmljaWVu dCAgICBwYW1fZnByaW50ZC5zbw0KYXV0aCAgICAgICAgc3VmZmljaWVudCAgICBwYW1fdW5peC5z byBudWxsb2sgdHJ5X2ZpcnN0X3Bhc3MNCmF1dGggICAgICAgIHJlcXVpc2l0ZSAgICAgcGFtX3N1 Y2NlZWRfaWYuc28gdWlkID49IDUwMCBxdWlldA0KYXV0aCAgICAgICAgcmVxdWlyZWQgICAgICBw YW1fZGVueS5zbw0KYWNjb3VudCAgICAgcmVxdWlyZWQgICAgICBwYW1fdW5peC5zbw0KYWNjb3Vu dCAgICAgc3VmZmljaWVudCAgICBwYW1fbG9jYWx1c2VyLnNvDQphY2NvdW50ICAgICBzdWZmaWNp ZW50ICAgIHBhbV9zdWNjZWVkX2lmLnNvIHVpZCA8IDUwMCBxdWlldA0KYWNjb3VudCAgICAgcmVx dWlyZWQgICAgICBwYW1fcGVybWl0LnNvDQpwYXNzd29yZCAgICByZXF1aXNpdGUgICAgIHBhbV9j cmFja2xpYi5zbyB0cnlfZmlyc3RfcGFzcyByZXRyeT0zIHR5cGU9DQpwYXNzd29yZCAgICBzdWZm aWNpZW50ICAgIHBhbV91bml4LnNvIG1kNSBzaGFkb3cgbnVsbG9rIHRyeV9maXJzdF9wYXNzIHVz ZV9hdXRodG9rDQpwYXNzd29yZCAgICByZXF1aXJlZCAgICAgIHBhbV9kZW55LnNvDQpzZXNzaW9u ICAgICBvcHRpb25hbCAgICAgIHBhbV9rZXlpbml0LnNvIHJldm9rZQ0Kc2Vzc2lvbiAgICAgcmVx dWlyZWQgICAgICBwYW1fbGltaXRzLnNvDQpzZXNzaW9uICAgICBbc3VjY2Vzcz0xIGRlZmF1bHQ9 aWdub3JlXSBwYW1fc3VjY2VlZF9pZi5zbyBzZXJ2aWNlIGluIGNyb25kIHF1aWV0IHVzZV91aWQN CnNlc3Npb24gICAgIHJlcXVpcmVkICAgICAgcGFtX3VuaXguc28NCg0KRG8gSSBrZWVwIHRoZSBz ZXJ2ZXJhbCBmaWxlcyBpbmNsdWRpbmcgL2V0Yy9wYW0uZC9sb2dpbiwgc3UsIHN1ZG8gYW5kIHNz aGQgaW50YWN0LCBqdXN0IGNoYW5nZSB0aGUgc3lzdGVtLWF1dGggZmlsZT8NCg0KQ291bGQgeW91 IHNob3cgbWUgaG93IHRvIHNldCBlbnRyaWVzIGluIC9ldGMvcGFtLmQvc3lzdGVtLWF1dGg/DQoN Ck1hbnkgdGhhbmtzIGZvciB5b3UuDQoNCg0KQ2hlZXJzLA0KUWl1bGFuDQogIA0KDQoNCjIwMTMt MTAtMjIgDQoNCg0KDQpodWFuZ3FsIA0KDQoNCg0K5Y+R5Lu25Lq677yaIEJyYW5kb24gQWxsYmVy eSANCuWPkemAgeaXtumXtO+8miAyMDEzLTEwLTIyICAyMjo1ODo0NyANCuaUtuS7tuS6uu+8miBo dWFuZ3FsOyBvcGVuYWZzLWluZm8gDQrmioTpgIHvvJogDQrkuLvpopjvvJogUmU6IFtPcGVuQUZT XSBQQU0gYXV0aGVudGljYXRpb24gZmFpbGVkIG9uIFNMNiANCiANCi9ldGMvcGFtLmQvc3lzdGVt LWF1dGggaXMgd2hlcmUgdGhvc2UgZW50cmllcyBiZWxvbmcsIGFuZCBieSBwdXR0aW5nIHRoZW0g ZGlyZWN0bHkgaW4gdGhlc2UgZW50cmllcyBpbnN0ZWFkIG9mIGluIHRoZSBjZW50cmFsIHN5c3Rl bS1hdXRoIHN0YWNrIHlvdSBhcmUgdmVyeSBwcm9iYWJseSBjYXVzaW5nIGNvbmZsaWN0cyB0aGF0 IHByZXZlbnQgbG9jYWwgYXV0aCAoYXMgZm9yIHJvb3QpIGFuZCBwb3NzaWJseSBBRlMgYXV0aCAo YmVjYXVzZSBib3RoIGxvY2FsIHBhc3N3b3JkIGFuZCBBRlMgcGFzc3dvcmQgYXJlIGNoZWNrZWQp IHRvIGZhaWwuIEJ1dCBJIGNhbid0IGJlIGNlcnRhaW4gb2YgdGhpcyBhcyB5b3UgaGF2ZSBub3Qg c2hvd24gL2V0Yy9wYW0uZC9zeXN0ZW0tYXV0aCwgYXMgSSBtZW50aW9uZWQgZWFybGllci4NCg0K DQotLSANCmJyYW5kb24gcyBhbGxiZXJ5IGtmOG5oICAgIHNpbmUgbm9taW5lIGFzc29jaWF0ZXMN CmFsbGJlcnkuYkBnbWFpbC5jb20gICAgICAgYmFsbGJlcnlAc2luZW5vbWluZS5uZXQNCnVuaXgs IG9wZW5hZnMsIGtlcmJlcm9zLCBpbmZyYXN0cnVjdHVyZSwgeG1vbmFkDQoNCg0KDQoNCkZyb206 IGh1YW5ncWwgPGh1YW5ncWxAaWhlcC5hYy5jbj4NCkRhdGU6IFR1ZXNkYXksIE9jdG9iZXIgMjIs IDIwMTMgMTA6NTMNClRvOiBCcmFuZG9uIEFsbGJlcnkgPGJhbGxiZXJ5QHNpbmVub21pbmUubmV0 PiwgIm9wZW5hZnMtaW5mb0BvcGVuYWZzLm9yZyIgPG9wZW5hZnMtaW5mb0BvcGVuYWZzLm9yZz4N ClN1YmplY3Q6IFJlOiBSZTogW09wZW5BRlNdIFBBTSBhdXRoZW50aWNhdGlvbiBmYWlsZWQgb24g U0w2DQoNCg0KDQpIaSBCcmFuZG9uLA0KDQpNYW55IHRoYW5rcyBmb3IgeW91ciBwcm9tcHQgcmVw bHkuIA0KDQpUaGUgcmVkIGNoYXJhY3RlcnMgIGFyZSB0aGUgcG9pbnRzIGZvciBQQU0gYXV0aGVu dGljYXRpb24sIHlvdSBtZWFuIHRoZXJlIGlzIG5vdCBlbm91Z2ggaW5mb3JtYXRpb24sIGNvdWxk IHlvdSBleHByZXNzIHdoYXQgb3RoZXIgbWVzc2FnZSBjb3VsZCBJIHByb3ZpZGU/DQoNCg0KIyBj YXQgL2V0Yy9wYW0uZC9sb2dpbg0KDQojJVBBTS0xLjANCmF1dGggICAgICAgc3VmZmljaWVudCAg IHBhbV9hZnMuc28gdHJ5X2ZpcnN0X3Bhc3MgaWdub3JlX3Jvb3Qgc2V0ZW52X3Bhc3N3b3JkX2V4 cGlyZXMNCmF1dGggICAgICAgcmVxdWlyZWQgICAgIHBhbV9zZWN1cmV0dHkuc28NCmF1dGggICAg ICAgcmVxdWlyZWQgICAgIHBhbV9zdGFjay5zbyBzZXJ2aWNlPXN5c3RlbS1hdXRoDQphdXRoICAg ICAgIHJlcXVpcmVkICAgICBwYW1fbm9sb2dpbi5zbw0KYWNjb3VudCAgICByZXF1aXJlZCAgICAg cGFtX3N0YWNrLnNvIHNlcnZpY2U9c3lzdGVtLWF1dGgNCnBhc3N3b3JkICAgcmVxdWlyZWQgICAg IHBhbV9zdGFjay5zbyBzZXJ2aWNlPXN5c3RlbS1hdXRoDQojIHBhbV9zZWxpbnV4LnNvIGNsb3Nl IHNob3VsZCBiZSB0aGUgZmlyc3Qgc2Vzc2lvbiBydWxlDQpzZXNzaW9uICAgIHJlcXVpcmVkICAg ICBwYW1fc2VsaW51eC5zbyBjbG9zZQ0Kc2Vzc2lvbiAgICByZXF1aXJlZCAgICAgcGFtX3N0YWNr LnNvIHNlcnZpY2U9c3lzdGVtLWF1dGgNCnNlc3Npb24gICAgcmVxdWlyZWQgICAgIHBhbV9sb2dp bnVpZC5zbw0Kc2Vzc2lvbiAgICBvcHRpb25hbCAgICAgcGFtX2NvbnNvbGUuc28NCiMgcGFtX3Nl bGludXguc28gb3BlbiBzaG91bGQgYmUgdGhlIGxhc3Qgc2Vzc2lvbiBydWxlDQpzZXNzaW9uICAg IHJlcXVpcmVkICAgICBwYW1fc2VsaW51eC5zbyBvcGVuDQoNCg0KIyBjYXQgL2V0Yy9wYW0uZC9z dQ0KDQojJVBBTS0xLjANCmF1dGggICAgICAgc3VmZmljaWVudCAgIHBhbV9hZnMuc28gdHJ5X2Zp cnN0X3Bhc3MgaWdub3JlX3Jvb3Qgc2V0ZW52X3Bhc3N3b3JkX2V4cGlyZXMNCmF1dGggICAgICAg c3VmZmljaWVudCAgIC9saWIvc2VjdXJpdHkvJElTQS9wYW1fcm9vdG9rLnNvDQojIFVuY29tbWVu dCB0aGUgZm9sbG93aW5nIGxpbmUgdG8gaW1wbGljaXRseSB0cnVzdCB1c2VycyBpbiB0aGUgIndo ZWVsIiBncm91cC4NCiNhdXRoICAgICAgIHN1ZmZpY2llbnQgICAvbGliL3NlY3VyaXR5LyRJU0Ev cGFtX3doZWVsLnNvIHRydXN0IHVzZV91aWQNCiMgVW5jb21tZW50IHRoZSBmb2xsb3dpbmcgbGlu ZSB0byByZXF1aXJlIGEgdXNlciB0byBiZSBpbiB0aGUgIndoZWVsIiBncm91cC4NCiNhdXRoICAg ICAgIHJlcXVpcmVkICAgICAvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3doZWVsLnNvIHVzZV91aWQN CmF1dGggICAgICAgcmVxdWlyZWQgICAgIC9saWIvc2VjdXJpdHkvJElTQS9wYW1fc3RhY2suc28g c2VydmljZT1zeXN0ZW0tYXV0aA0KYWNjb3VudCAgICBzdWZmaWNpZW50ICAgL2xpYi9zZWN1cml0 eS8kSVNBL3BhbV9zdWNjZWVkX2lmLnNvIHVpZD0wIHVzZV91aWQgcXVpZXQNCmFjY291bnQgICAg cmVxdWlyZWQgICAgIC9saWIvc2VjdXJpdHkvJElTQS9wYW1fc3RhY2suc28gc2VydmljZT1zeXN0 ZW0tYXV0aA0KcGFzc3dvcmQgICByZXF1aXJlZCAgICAgL2xpYi9zZWN1cml0eS8kSVNBL3BhbV9z dGFjay5zbyBzZXJ2aWNlPXN5c3RlbS1hdXRoDQojIHBhbV9zZWxpbnV4LnNvIGNsb3NlIG11c3Qg YmUgZmlyc3Qgc2Vzc2lvbiBydWxlDQpzZXNzaW9uICAgIHJlcXVpcmVkICAgICAvbGliL3NlY3Vy aXR5LyRJU0EvcGFtX3NlbGludXguc28gY2xvc2UNCnNlc3Npb24gICAgcmVxdWlyZWQgICAgIC9s aWIvc2VjdXJpdHkvJElTQS9wYW1fc3RhY2suc28gc2VydmljZT1zeXN0ZW0tYXV0aA0KIyBwYW1f c2VsaW51eC5zbyBvcGVuIGFuZCBwYW1feGF1dGggbXVzdCBiZSBsYXN0IHR3byBzZXNzaW9uIHJ1 bGVzDQpzZXNzaW9uICAgIHJlcXVpcmVkICAgICAvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3NlbGlu dXguc28gb3Blbg0Kc2Vzc2lvbiAgICBvcHRpb25hbCAgICAgL2xpYi9zZWN1cml0eS8kSVNBL3Bh bV94YXV0aC5zbw0KDQojIGNhdCAgL2V0Yy9wYW0uZC9zc2hkDQoNCiMlUEFNLTEuMA0KYXV0aCAg ICAgICBzdWZmaWNpZW50ICAgcGFtX2Fmcy5zbyB0cnlfZmlyc3RfcGFzcyBpZ25vcmVfcm9vdCBz ZXRlbnZfcGFzc3dvcmRfZXhwaXJlcw0KYXV0aCAgICAgICByZXF1aXJlZCAgICAgcGFtX3N0YWNr LnNvIHNlcnZpY2U9c3lzdGVtLWF1dGgNCmF1dGggICAgICAgcmVxdWlyZWQgICAgIHBhbV9ub2xv Z2luLnNvDQphY2NvdW50ICAgIHJlcXVpcmVkICAgICBwYW1fc3RhY2suc28gc2VydmljZT1zeXN0 ZW0tYXV0aA0KcGFzc3dvcmQgICByZXF1aXJlZCAgICAgcGFtX3N0YWNrLnNvIHNlcnZpY2U9c3lz dGVtLWF1dGgNCnNlc3Npb24gICAgcmVxdWlyZWQgICAgIHBhbV9zdGFjay5zbyBzZXJ2aWNlPXN5 c3RlbS1hdXRoDQoNCg0KI2NhdCAvZXRjL3BhbS5kL3N1ZG8gICAgICAgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiMlUEFNLTEuMA0KYXV0aCAgICAg ICBzdWZmaWNpZW50ICAgcGFtX2Fmcy5zbyB0cnlfZmlyc3RfcGFzcyBpZ25vcmVfcm9vdCBzZXRl bnZfcGFzc3dvcmRfZXhwaXJlcw0KYXV0aCAgICAgICBzdWZmaWNpZW50ICAgL2xpYi9zZWN1cml0 eS8kSVNBL3BhbV9yb290b2suc28NCiMgVW5jb21tZW50IHRoZSBmb2xsb3dpbmcgbGluZSB0byBp bXBsaWNpdGx5IHRydXN0IHVzZXJzIGluIHRoZSAid2hlZWwiIGdyb3VwLg0KI2F1dGggICAgICAg c3VmZmljaWVudCAgIC9saWIvc2VjdXJpdHkvJElTQS9wYW1fd2hlZWwuc28gdHJ1c3QgdXNlX3Vp ZA0KIyBVbmNvbW1lbnQgdGhlIGZvbGxvd2luZyBsaW5lIHRvIHJlcXVpcmUgYSB1c2VyIHRvIGJl IGluIHRoZSAid2hlZWwiIGdyb3VwLg0KI2F1dGggICAgICAgcmVxdWlyZWQgICAgIC9saWIvc2Vj dXJpdHkvJElTQS9wYW1fd2hlZWwuc28gdXNlX3VpZA0KYXV0aCAgICAgICByZXF1aXJlZCAgICAg L2xpYi9zZWN1cml0eS8kSVNBL3BhbV9zdGFjay5zbyBzZXJ2aWNlPXN5c3RlbS1hdXRoDQphY2Nv dW50ICAgIHN1ZmZpY2llbnQgICAvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3N1Y2NlZWRfaWYuc28g dWlkPTAgdXNlX3VpZCBxdWlldA0KYWNjb3VudCAgICByZXF1aXJlZCAgICAgL2xpYi9zZWN1cml0 eS8kSVNBL3BhbV9zdGFjay5zbyBzZXJ2aWNlPXN5c3RlbS1hdXRoDQpwYXNzd29yZCAgIHJlcXVp cmVkICAgICAvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3N0YWNrLnNvIHNlcnZpY2U9c3lzdGVtLWF1 dGgNCiMgcGFtX3NlbGludXguc28gY2xvc2UgbXVzdCBiZSBmaXJzdCBzZXNzaW9uIHJ1bGUNCnNl c3Npb24gICAgcmVxdWlyZWQgICAgIC9saWIvc2VjdXJpdHkvJElTQS9wYW1fc2VsaW51eC5zbyBj bG9zZQ0Kc2Vzc2lvbiAgICByZXF1aXJlZCAgICAgL2xpYi9zZWN1cml0eS8kSVNBL3BhbV9zdGFj ay5zbyBzZXJ2aWNlPXN5c3RlbS1hdXRoDQojIHBhbV9zZWxpbnV4LnNvIG9wZW4gYW5kIHBhbV94 YXV0aCBtdXN0IGJlIGxhc3QgdHdvIHNlc3Npb24gcnVsZXMNCnNlc3Npb24gICAgcmVxdWlyZWQg ICAgIC9saWIvc2VjdXJpdHkvJElTQS9wYW1fc2VsaW51eC5zbyBvcGVuDQpzZXNzaW9uICAgIG9w dGlvbmFsICAgICAvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3hhdXRoLnNvDQoNCg0KVGhhbmtzIGEg bG90Lg0KDQpCZXN0IFJlZ2FyZHMNClFpdWxhbiBIdWFuZw0KMjAxMy0xMC0yMg0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NCkNvbXB1dGluZyBjZW50ZXIsdGhlIEluc3RpdHV0ZSBvZiBIaWdoIEVuZXJneSBQaHlzaWNz LCBDaGluYQ0KSHVhbmcsIFFpdWxhbiAgICAgICAgICAgICAgICAgICAgICAgIFRlbDogKCs4Nikg MTAgODgyMyA2MDEwLTEwNQ0KUC5PLiBCb3ggOTE4LTcgICAgICAgICAgICAgICAgICAgICAgIEZh eDogKCs4NikgMTAgODgyMyA2ODM5DQpCZWlqaW5nIDEwMDA0OSAgUC5SLiBDaGluYSAgICAgICAg ICAgRW1haWw6IGh1YW5ncWxAaWhlcC5hYy5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSANCg0KDQoNCuWPkeS7tuS6 uu+8miBCcmFuZG9uIEFsbGJlcnkgDQrlj5HpgIHml7bpl7TvvJogMjAxMy0xMC0yMiAgMjE6MjM6 MDMgDQrmlLbku7bkurrvvJogaHVhbmdxbDsgb3BlbmFmcy1pbmZvIA0K5oqE6YCB77yaIA0K5Li7 6aKY77yaIFJlOiBbT3BlbkFGU10gUEFNIGF1dGhlbnRpY2F0aW9uIGZhaWxlZCBvbiBTTDYgDQpP biAxMC8yMi8xMyAwNTozOCwgImh1YW5ncWwiIDxodWFuZ3FsQGloZXAuYWMuY24+IHdyb3RlOg0K PlRoZSBxdWVzdGlvbnMgc3R1Y2sgbWUgZm9yIHdlZWtzLiBEb2VzIGFueW9uZSBnZXQgdGhlIHNh bWUgcHJvYmxlbSBhbmQNCj5jb3VsZCB5b3UgZ2l2ZSBtZSBzb21lIHN1Z2dlc3Rpb25zPw0KWW91 IGRvbid0IHByb3ZpZGUgZW5vdWdoIGluZm9ybWF0aW9uLCBiZWNhdXNlIGFsbCB0aGUgc3RhY2tz IHlvdSBwcm92aWRlZA0KdXNlIHBhbV9zdGFjay5zbyB0byBsb2FkIHRoZSBzeXN0ZW0tYXV0aCBz dGFjayB3aGljaCB5b3UgZGlkbid0IHByb3ZpZGUuDQotLSANCmJyYW5kb24gcyBhbGxiZXJ5IGtm OG5oICAgIHNpbmUgbm9taW5lIGFzc29jaWF0ZXMNCmFsbGJlcnkuYkBnbWFpbC5jb20gICAgICAg YmFsbGJlcnlAc2luZW5vbWluZS5uZXQNCnVuaXgsIG9wZW5hZnMsIGtlcmJlcm9zLCBpbmZyYXN0 cnVjdHVyZSwgeG1vbmFkDQo= --=====003_Dragon804576371781_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PVVURi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNv bnRlbnQ9Ik1TSFRNTCAxMC4wMC45MjAwLjE2NzIxIj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglm b250LWZhbWlseTog5a6L5L2TOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFZlcmRh bmE7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQOWui+S9kzsNCn0NCkBwYWdlIFNl Y3Rpb24xIHtzaXplOiA1OTUuM3B0IDg0MS45cHQ7IG1hcmdpbjogNzIuMHB0IDkwLjBwdCA3Mi4w cHQgOTAuMHB0OyBsYXlvdXQtZ3JpZDogMTUuNnB0OyB9DQpQLk1zb05vcm1hbCB7DQoJRk9OVC1T SVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjog anVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3Jh cGgNCn0NCkxJLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAi VGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBw dDsgVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGgNCn0NCkRJVi5Nc29Ob3JtYWwgew0KCUZP TlQtU0laRTogMTAuNXB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJ R046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IFRFWFQtSlVTVElGWTogaW50ZXItaWRl b2dyYXBoDQp9DQpBOmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVy bGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJ T046IHVuZGVybGluZQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09S QVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmtGb2xsb3dlZCB7DQoJQ09MT1I6 IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uRW1haWxTdHlsZTE3 IHsNCglGT05ULUZBTUlMWTogVmVyZGFuYTsgRk9OVC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdp bmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsgVEVYVC1ERUNPUkFUSU9OOiBub25lOyBtc28t c3R5bGUtdHlwZTogcGVyc29uYWwtY29tcG9zZQ0KfQ0KRElWLlNlY3Rpb24xIHsNCglwYWdlOiBT ZWN0aW9uMQ0KfQ0KVU5LTk9XTiB7DQoJRk9OVC1TSVpFOiAxMHB0DQp9DQo8L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHZlcmRhbmE7 IE1BUkdJTjogMTBweCI+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODAgc2l6ZT0yIGZhY2U9VmVy ZGFuYT48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+RGVhciBC cmFuZG9uLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+VGhhbmsgeW91IHZlcnkgbXVjaC48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPkkgZG9uJ3QgZG8gYW55Jm5ic3A7bW9kaWZpY2F0 aW9uJm5ic3A7Zm9yIHRoZSZuYnNwO2ZpbGUgDQovZXRjL3BhbS5kL3N5c3RlbS1hdXRoLCB0aGUg Y29udGVudCBpcyA6PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjwvRk9O VD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD4NCjxESVY+W3Jvb3RAYndz MDQ4MSZuYnNwO35dIyZuYnNwO3ZpJm5ic3A7L2V0Yy9wYW0uZC9zeXN0ZW0tYXV0aDwvRElWPg0K PERJVj4jJVBBTS0xLjA8L0RJVj4NCjxESVY+IyZuYnNwO1RoaXMmbmJzcDtmaWxlJm5ic3A7aXMm bmJzcDthdXRvLWdlbmVyYXRlZC48L0RJVj4NCjxESVY+IyZuYnNwO1VzZXImbmJzcDtjaGFuZ2Vz Jm5ic3A7d2lsbCZuYnNwO2JlJm5ic3A7ZGVzdHJveWVkJm5ic3A7dGhlJm5ic3A7bmV4dCZuYnNw O3RpbWUmbmJzcDthdXRoY29uZmlnJm5ic3A7aXMmbmJzcDtydW4uPC9ESVY+DQo8RElWPmF1dGgm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlZCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3BhbV9lbnYuc288L0RJVj4NCjxESVY+ YXV0aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3N1ZmZp Y2llbnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwYW1fZnByaW50ZC5zbzwvRElWPg0KPERJVj5h dXRoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7c3VmZmlj aWVudCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3BhbV91bml4LnNvJm5ic3A7bnVsbG9rJm5ic3A7 dHJ5X2ZpcnN0X3Bhc3M8L0RJVj4NCjxESVY+YXV0aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlcXVpc2l0ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO3BhbV9zdWNjZWVkX2lmLnNvJm5ic3A7dWlkJm5ic3A7Jmd0Oz0mbmJzcDs1MDAmbmJzcDtx dWlldDwvRElWPg0KPERJVj5hdXRoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7cmVxdWlyZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtw YW1fZGVueS5zbzwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+YWNjb3VudCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO3JlcXVpcmVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7cGFtX3VuaXguc288L0RJVj4NCjxESVY+YWNjb3VudCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO3N1ZmZpY2llbnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwYW1fbG9jYWx1c2VyLnNv PC9ESVY+DQo8RElWPmFjY291bnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzdWZmaWNp ZW50Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGFtX3N1Y2NlZWRfaWYuc28mbmJzcDt1aWQmbmJz cDsmbHQ7Jm5ic3A7NTAwJm5ic3A7cXVpZXQ8L0RJVj4NCjxESVY+YWNjb3VudCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO3JlcXVpcmVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7cGFtX3Blcm1pdC5zbzwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+cGFzc3dvcmQmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXNpdGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtwYW1fY3JhY2tsaWIuc28mbmJzcDt0cnlfZmlyc3RfcGFzcyZuYnNwO3JldHJ5PTMmbmJzcDt0 eXBlPTwvRElWPg0KPERJVj5wYXNzd29yZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3N1ZmZpY2ll bnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwYW1fdW5peC5zbyZuYnNwO21kNSZuYnNwO3NoYWRv dyZuYnNwO251bGxvayZuYnNwO3RyeV9maXJzdF9wYXNzJm5ic3A7dXNlX2F1dGh0b2s8L0RJVj4N CjxESVY+cGFzc3dvcmQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlZCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3BhbV9kZW55LnNvPC9ESVY+DQo8RElWPjwvRElWPg0K PERJVj5zZXNzaW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7b3B0aW9uYWwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwYW1fa2V5aW5pdC5zbyZuYnNwO3Jldm9rZTwv RElWPg0KPERJVj5zZXNzaW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVxdWlyZWQm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwYW1fbGltaXRzLnNvPC9ESVY+DQo8 RElWPnNlc3Npb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtbc3VjY2Vzcz0xJm5ic3A7 ZGVmYXVsdD1pZ25vcmVdJm5ic3A7cGFtX3N1Y2NlZWRfaWYuc28mbmJzcDtzZXJ2aWNlJm5ic3A7 aW4mbmJzcDtjcm9uZCZuYnNwO3F1aWV0Jm5ic3A7dXNlX3VpZDwvRElWPg0KPERJVj5zZXNzaW9u Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVxdWlyZWQmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtwYW1fdW5peC5zbzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+RG8gSSBrZWVwIHRoZSBzZXJ2ZXJhbCBmaWxlcyBpbmNsdWRpbmcgL2V0Yy9wYW0uZC9sb2dp biwgc3UsIHN1ZG8gYW5kIHNzaGQgDQppbnRhY3QsIGp1c3QgY2hhbmdlIHRoZSBzeXN0ZW0tYXV0 aCBmaWxlPzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Q291bGQgeW91IHNob3cgbWUg aG93IHRvIHNldCBlbnRyaWVzIGluIC9ldGMvcGFtLmQvc3lzdGVtLWF1dGg/PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj5NYW55IHRoYW5rcyBmb3IgeW91LjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkNoZWVycyw8L0RJVj4NCjxESVY+UWl1 bGFuPC9ESVY+Jm5ic3A7Jm5ic3A7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAw MDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBj b2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBjb2xvcj0jYzBjMGMwIHNpemU9MiBmYWNlPVZlcmRhbmE+MjAxMy0xMC0yMiA8L0ZP TlQ+PC9ESVY+PEZPTlQgDQpjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+DQo8SFIg c3R5bGU9IldJRFRIOiAxMDBweCIgYWxpZ249bGVmdCBjb2xvcj0jYjVjNGRmIFNJWkU9MT4NCjwv Rk9OVD4NCjxESVY+PEZPTlQgY29sb3I9I2MwYzBjMCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTUEFO Pmh1YW5ncWw8L1NQQU4+IDwvRk9OVD48L0RJVj4NCjxIUiBjb2xvcj0jYjVjNGRmIFNJWkU9MT4N Cg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTVFJPTkc+5Y+R5Lu25Lq677yaPC9T VFJPTkc+IEJyYW5kb24gQWxsYmVyeSANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y IGZhY2U9VmVyZGFuYT48U1RST05HPuWPkemAgeaXtumXtO+8mjwvU1RST05HPiAyMDEzLTEwLTIy Jm5ic3A7IDIyOjU4OjQ3IA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1W ZXJkYW5hPjxTVFJPTkc+5pS25Lu25Lq677yaPC9TVFJPTkc+IGh1YW5ncWw7IG9wZW5hZnMtaW5m byANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05H PuaKhOmAge+8mjwvU1RST05HPiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNl PVZlcmRhbmE+PFNUUk9ORz7kuLvpopjvvJo8L1NUUk9ORz4gUmU6IFtPcGVuQUZTXSBQQU0gDQph dXRoZW50aWNhdGlvbiBmYWlsZWQgb24gU0w2IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yIGZhY2U9VmVyZGFuYT48L0ZPTlQ+IDwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1W ZXJkYW5hPg0KPERJVj4NCjxESVY+L2V0Yy9wYW0uZC9zeXN0ZW0tYXV0aCBpcyB3aGVyZSB0aG9z ZSBlbnRyaWVzIGJlbG9uZywgYW5kIGJ5IHB1dHRpbmcgdGhlbSANCmRpcmVjdGx5IGluIHRoZXNl IGVudHJpZXMgaW5zdGVhZCBvZiBpbiB0aGUgY2VudHJhbCBzeXN0ZW0tYXV0aCBzdGFjayB5b3Ug YXJlIA0KdmVyeSBwcm9iYWJseSBjYXVzaW5nIGNvbmZsaWN0cyB0aGF0IHByZXZlbnQgbG9jYWwg YXV0aCAoYXMgZm9yIHJvb3QpIGFuZCANCnBvc3NpYmx5IEFGUyBhdXRoIChiZWNhdXNlIGJvdGgg bG9jYWwgcGFzc3dvcmQgYW5kIEFGUyBwYXNzd29yZCBhcmUgY2hlY2tlZCkgdG8gDQpmYWlsLiBC dXQgSSBjYW4ndCBiZSBjZXJ0YWluIG9mIHRoaXMgYXMgeW91IGhhdmUgbm90IHNob3duIA0KL2V0 Yy9wYW0uZC9zeXN0ZW0tYXV0aCwgYXMgSSBtZW50aW9uZWQgZWFybGllci48L0RJVj4NCjxESVY+ PEJSPjwvRElWPg0KPERJVj4NCjxQIHN0eWxlPSJGT05ULUZBTUlMWTogQ29uc29sYXM7IE1BUkdJ TjogMHB4Ij4tLSZuYnNwOzwvUD4NCjxQIHN0eWxlPSJGT05ULUZBTUlMWTogQ29uc29sYXM7IE1B UkdJTjogMHB4Ij5icmFuZG9uIHMgYWxsYmVyeSBrZjhuaCAmbmJzcDsgDQombmJzcDtzaW5lIG5v bWluZSBhc3NvY2lhdGVzPC9QPg0KPFAgc3R5bGU9IkZPTlQtRkFNSUxZOiBDb25zb2xhczsgTUFS R0lOOiAwcHgiPmFsbGJlcnkuYkBnbWFpbC5jb20gJm5ic3A7ICZuYnNwOyANCiZuYnNwOyBiYWxs YmVyeUBzaW5lbm9taW5lLm5ldDwvUD4NCjxQIHN0eWxlPSJGT05ULUZBTUlMWTogQ29uc29sYXM7 IE1BUkdJTjogMHB4Ij51bml4LCBvcGVuYWZzLCBrZXJiZXJvcywgDQppbmZyYXN0cnVjdHVyZSwg eG1vbmFkPC9QPg0KPERJVj48QlI+PC9ESVY+PC9ESVY+PC9ESVY+DQo8RElWPjxCUj48L0RJVj48 U1BBTiBpZD1PTEtfU1JDX0JPRFlfU0VDVElPTj4NCjxESVYgDQpzdHlsZT0iRk9OVC1TSVpFOiAx MXB0OyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgRk9OVC1GQU1JTFk6IENhbGlicmk7 IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBD T0xPUjogYmxhY2s7IFBBRERJTkctQk9UVE9NOiAwaW47IFRFWFQtQUxJR046IGxlZnQ7IFBBRERJ TkctVE9QOiAzcHQ7IFBBRERJTkctTEVGVDogMGluOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7 IFBBRERJTkctUklHSFQ6IDBpbiI+PFNQQU4gDQpzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPkZy b206IDwvU1BBTj5odWFuZ3FsICZsdDs8QSANCmhyZWY9Im1haWx0bzpodWFuZ3FsQGloZXAuYWMu Y24iPmh1YW5ncWxAaWhlcC5hYy5jbjwvQT4mZ3Q7PEJSPjxTUEFOIA0Kc3R5bGU9IkZPTlQtV0VJ R0hUOiBib2xkIj5EYXRlOiA8L1NQQU4+VHVlc2RheSwgT2N0b2JlciAyMiwgMjAxMyAxMDo1MzxC Uj48U1BBTiANCnN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+VG86IDwvU1BBTj5CcmFuZG9uIEFs bGJlcnkgJmx0OzxBIA0KaHJlZj0ibWFpbHRvOmJhbGxiZXJ5QHNpbmVub21pbmUubmV0Ij5iYWxs YmVyeUBzaW5lbm9taW5lLm5ldDwvQT4mZ3Q7LCAiPEEgDQpocmVmPSJtYWlsdG86b3BlbmFmcy1p bmZvQG9wZW5hZnMub3JnIj5vcGVuYWZzLWluZm9Ab3BlbmFmcy5vcmc8L0E+IiAmbHQ7PEEgDQpo cmVmPSJtYWlsdG86b3BlbmFmcy1pbmZvQG9wZW5hZnMub3JnIj5vcGVuYWZzLWluZm9Ab3BlbmFm cy5vcmc8L0E+Jmd0OzxCUj48U1BBTiANCnN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+U3ViamVj dDogPC9TUEFOPlJlOiBSZTogW09wZW5BRlNdIFBBTSBhdXRoZW50aWNhdGlvbiANCmZhaWxlZCBv biBTTDY8QlI+PC9ESVY+DQo8RElWPjxCUj48L0RJVj4NCjxESVY+DQo8TUVUQSBuYW1lPUdFTkVS QVRPUiBjb250ZW50PSJNU0hUTUwgMTAuMDAuOTIwMC4xNjcyMSI+DQo8U1RZTEU+QGZvbnQtZmFj ZSB7DQoJZm9udC1mYW1pbHk6IOWui+S9kzsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5 OiBWZXJkYW5hOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDlrovkvZM7DQp9DQpA cGFnZSBTZWN0aW9uMSB7c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4w cHQgNzIuMHB0IDkwLjBwdDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0K CUZPTlQtU0laRTogMTAuNXB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQt QUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IFRFWFQtSlVTVElGWTogaW50ZXIt aWRlb2dyYXBoDQp9DQpMSS5Nc29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTAuNXB0OyBGT05ULUZB TUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNt IDBjbSAwcHQ7IFRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoDQp9DQpESVYuTXNvTm9ybWFs IHsNCglGT05ULVNJWkU6IDEwLjVwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBU RVhULUFMSUdOOiBqdXN0aWZ5OyBNQVJHSU46IDBjbSAwY20gMHB0OyBURVhULUpVU1RJRlk6IGlu dGVyLWlkZW9ncmFwaA0KfQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9O OiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1E RUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVY VC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0K CUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWls U3R5bGUxNyB7DQoJRk9OVC1GQU1JTFk6IFZlcmRhbmE7IEZPTlQtV0VJR0hUOiBub3JtYWw7IENP TE9SOiB3aW5kb3d0ZXh0OyBGT05ULVNUWUxFOiBub3JtYWw7IFRFWFQtREVDT1JBVElPTjogbm9u ZTsgbXNvLXN0eWxlLXR5cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJ cGFnZTogU2VjdGlvbjENCn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KQkxPQ0tR VU9URSB7DQoJTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtOyBNQVJHSU4tVE9Q OiAwcHgNCn0NCk9MIHsNCglNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweA0KfQ0K VUwgew0KCU1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4DQp9DQo8L1NUWUxFPg0K DQo8RElWIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hOyBNQVJH SU46IDEwcHgiPg0KPERJVj4NCjxESVY+SGkgQnJhbmRvbiw8L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPk1hbnkgdGhhbmtzIGZvciB5b3VyIHByb21wdCByZXBseS4gPC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj5UaGUgcmVkIGNoYXJhY3RlcnMmbmJzcDsgYXJlIHRoZSBwb2lu dHMgZm9yIFBBTSBhdXRoZW50aWNhdGlvbiwgeW91IG1lYW4gDQp0aGVyZSBpcyBub3QgZW5vdWdo IGluZm9ybWF0aW9uLCBjb3VsZCB5b3UgZXhwcmVzcyB3aGF0IG90aGVyIG1lc3NhZ2UgY291bGQg SSANCnByb3ZpZGU/PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgY29sb3I9I2ZmMDAwMD4jJm5ic3A7Y2F0Jm5ic3A7L2V0Yy9wYW0uZC9sb2dp bjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9I2ZmMDAwMD48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjwvRElWPg0KPERJVj4jJVBBTS0xLjA8L0RJVj4NCjxESVY+PEZPTlQgDQpjb2xv cj0jZmYwMDAwPmF1dGgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtz dWZmaWNpZW50Jm5ic3A7Jm5ic3A7Jm5ic3A7cGFtX2Fmcy5zbyZuYnNwO3RyeV9maXJzdF9wYXNz Jm5ic3A7aWdub3JlX3Jvb3QmbmJzcDtzZXRlbnZfcGFzc3dvcmRfZXhwaXJlczwvRk9OVD48L0RJ Vj4NCjxESVY+YXV0aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Jl cXVpcmVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGFtX3NlY3VyZXR0eS5zbzwvRElW Pg0KPERJVj5hdXRoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVx dWlyZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwYW1fc3RhY2suc28mbmJzcDtzZXJ2 aWNlPXN5c3RlbS1hdXRoPC9ESVY+DQo8RElWPmF1dGgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Bh bV9ub2xvZ2luLnNvPC9ESVY+DQo8RElWPmFjY291bnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDty ZXF1aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3BhbV9zdGFjay5zbyZuYnNwO3Nl cnZpY2U9c3lzdGVtLWF1dGg8L0RJVj4NCjxESVY+cGFzc3dvcmQmbmJzcDsmbmJzcDsmbmJzcDty ZXF1aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3BhbV9zdGFjay5zbyZuYnNwO3Nl cnZpY2U9c3lzdGVtLWF1dGg8L0RJVj4NCjxESVY+IyZuYnNwO3BhbV9zZWxpbnV4LnNvJm5ic3A7 Y2xvc2UmbmJzcDtzaG91bGQmbmJzcDtiZSZuYnNwO3RoZSZuYnNwO2ZpcnN0Jm5ic3A7c2Vzc2lv biZuYnNwO3J1bGU8L0RJVj4NCjxESVY+c2Vzc2lvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Jl cXVpcmVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGFtX3NlbGludXguc28mbmJzcDtj bG9zZTwvRElWPg0KPERJVj5zZXNzaW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVxdWlyZWQm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwYW1fc3RhY2suc28mbmJzcDtzZXJ2aWNlPXN5 c3RlbS1hdXRoPC9ESVY+DQo8RElWPnNlc3Npb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1 aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3BhbV9sb2dpbnVpZC5zbzwvRElWPg0K PERJVj5zZXNzaW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7b3B0aW9uYWwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtwYW1fY29uc29sZS5zbzwvRElWPg0KPERJVj4jJm5ic3A7cGFtX3Nl bGludXguc28mbmJzcDtvcGVuJm5ic3A7c2hvdWxkJm5ic3A7YmUmbmJzcDt0aGUmbmJzcDtsYXN0 Jm5ic3A7c2Vzc2lvbiZuYnNwO3J1bGU8L0RJVj4NCjxESVY+c2Vzc2lvbiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO3JlcXVpcmVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGFtX3NlbGlu dXguc28mbmJzcDtvcGVuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSNmZjAwMDA+IyZuYnNwO2NhdCZuYnNw Oy9ldGMvcGFtLmQvc3U8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSNmZjAwMDA+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj4jJVBBTS0xLjA8L0RJVj4NCjxESVY+PEZPTlQgDQpjb2xv cj0jZmYwMDAwPmF1dGgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtz dWZmaWNpZW50Jm5ic3A7Jm5ic3A7Jm5ic3A7cGFtX2Fmcy5zbyZuYnNwO3RyeV9maXJzdF9wYXNz Jm5ic3A7aWdub3JlX3Jvb3QmbmJzcDtzZXRlbnZfcGFzc3dvcmRfZXhwaXJlczwvRk9OVD48L0RJ Vj4NCjxESVY+YXV0aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3N1 ZmZpY2llbnQmbmJzcDsmbmJzcDsmbmJzcDsvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3Jvb3Rvay5z bzwvRElWPg0KPERJVj4jJm5ic3A7VW5jb21tZW50Jm5ic3A7dGhlJm5ic3A7Zm9sbG93aW5nJm5i c3A7bGluZSZuYnNwO3RvJm5ic3A7aW1wbGljaXRseSZuYnNwO3RydXN0Jm5ic3A7dXNlcnMmbmJz cDtpbiZuYnNwO3RoZSZuYnNwOyJ3aGVlbCImbmJzcDtncm91cC48L0RJVj4NCjxESVY+I2F1dGgm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzdWZmaWNpZW50Jm5ic3A7 Jm5ic3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8kSVNBL3BhbV93aGVlbC5zbyZuYnNwO3RydXN0Jm5i c3A7dXNlX3VpZDwvRElWPg0KPERJVj4jJm5ic3A7VW5jb21tZW50Jm5ic3A7dGhlJm5ic3A7Zm9s bG93aW5nJm5ic3A7bGluZSZuYnNwO3RvJm5ic3A7cmVxdWlyZSZuYnNwO2EmbmJzcDt1c2VyJm5i c3A7dG8mbmJzcDtiZSZuYnNwO2luJm5ic3A7dGhlJm5ic3A7IndoZWVsIiZuYnNwO2dyb3VwLjwv RElWPg0KPERJVj4jYXV0aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O3JlcXVpcmVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8kSVNB L3BhbV93aGVlbC5zbyZuYnNwO3VzZV91aWQ8L0RJVj4NCjxESVY+YXV0aCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlcXVpcmVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8kSVNBL3BhbV9zdGFjay5zbyZuYnNwO3NlcnZpY2U9c3lz dGVtLWF1dGg8L0RJVj4NCjxESVY+YWNjb3VudCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3N1ZmZp Y2llbnQmbmJzcDsmbmJzcDsmbmJzcDsvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3N1Y2NlZWRfaWYu c28mbmJzcDt1aWQ9MCZuYnNwO3VzZV91aWQmbmJzcDtxdWlldDwvRElWPg0KPERJVj5hY2NvdW50 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVxdWlyZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3N0YWNrLnNvJm5ic3A7c2VydmljZT1zeXN0ZW0t YXV0aDwvRElWPg0KPERJVj5wYXNzd29yZCZuYnNwOyZuYnNwOyZuYnNwO3JlcXVpcmVkJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8kSVNBL3BhbV9zdGFjay5zbyZu YnNwO3NlcnZpY2U9c3lzdGVtLWF1dGg8L0RJVj4NCjxESVY+IyZuYnNwO3BhbV9zZWxpbnV4LnNv Jm5ic3A7Y2xvc2UmbmJzcDttdXN0Jm5ic3A7YmUmbmJzcDtmaXJzdCZuYnNwO3Nlc3Npb24mbmJz cDtydWxlPC9ESVY+DQo8RElWPnNlc3Npb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJl ZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy9saWIvc2VjdXJpdHkvJElTQS9wYW1fc2Vs aW51eC5zbyZuYnNwO2Nsb3NlPC9ESVY+DQo8RElWPnNlc3Npb24mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtyZXF1aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy9saWIvc2VjdXJpdHkv JElTQS9wYW1fc3RhY2suc28mbmJzcDtzZXJ2aWNlPXN5c3RlbS1hdXRoPC9ESVY+DQo8RElWPiMm bmJzcDtwYW1fc2VsaW51eC5zbyZuYnNwO29wZW4mbmJzcDthbmQmbmJzcDtwYW1feGF1dGgmbmJz cDttdXN0Jm5ic3A7YmUmbmJzcDtsYXN0Jm5ic3A7dHdvJm5ic3A7c2Vzc2lvbiZuYnNwO3J1bGVz PC9ESVY+DQo8RElWPnNlc3Npb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlZCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy9saWIvc2VjdXJpdHkvJElTQS9wYW1fc2VsaW51eC5z byZuYnNwO29wZW48L0RJVj4NCjxESVY+c2Vzc2lvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO29w dGlvbmFsJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8kSVNBL3Bh bV94YXV0aC5zbzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjxG T05UIGNvbG9yPSNmZjAwMDA+IyZuYnNwO2NhdCZuYnNwOyZuYnNwOy9ldGMvcGFtLmQvc3NoZDwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9I2ZmMDAwMD48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPiMlUEFNLTEuMDwvRElWPg0KPERJVj48Rk9OVCANCmNvbG9yPSNmZjAwMDA+YXV0aCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3N1ZmZpY2llbnQmbmJzcDsm bmJzcDsmbmJzcDtwYW1fYWZzLnNvJm5ic3A7dHJ5X2ZpcnN0X3Bhc3MmbmJzcDtpZ25vcmVfcm9v dCZuYnNwO3NldGVudl9wYXNzd29yZF9leHBpcmVzPC9GT05UPjwvRElWPg0KPERJVj5hdXRoJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVxdWlyZWQmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtwYW1fc3RhY2suc28mbmJzcDtzZXJ2aWNlPXN5c3RlbS1hdXRo PC9ESVY+DQo8RElWPmF1dGgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtyZXF1aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3BhbV9ub2xvZ2luLnNvPC9E SVY+DQo8RElWPmFjY291bnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlZCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3BhbV9zdGFjay5zbyZuYnNwO3NlcnZpY2U9c3lzdGVtLWF1 dGg8L0RJVj4NCjxESVY+cGFzc3dvcmQmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlZCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3BhbV9zdGFjay5zbyZuYnNwO3NlcnZpY2U9c3lzdGVtLWF1 dGg8L0RJVj4NCjxESVY+c2Vzc2lvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlcXVpcmVkJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGFtX3N0YWNrLnNvJm5ic3A7c2VydmljZT1zeXN0 ZW0tYXV0aDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+PEZPTlQgDQpjb2xvcj0jZmYwMDAwPiNjYXQmbmJz cDsvZXRjL3BhbS5kL3N1ZG88L0ZPTlQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvRElWPg0KPERJVj4jJVBBTS0xLjA8L0RJVj4NCjxE SVY+PEZPTlQgDQpjb2xvcj0jZmYwMDAwPmF1dGgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtzdWZmaWNpZW50Jm5ic3A7Jm5ic3A7Jm5ic3A7cGFtX2Fmcy5zbyZuYnNw O3RyeV9maXJzdF9wYXNzJm5ic3A7aWdub3JlX3Jvb3QmbmJzcDtzZXRlbnZfcGFzc3dvcmRfZXhw aXJlczwvRk9OVD48L0RJVj4NCjxESVY+YXV0aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO3N1ZmZpY2llbnQmbmJzcDsmbmJzcDsmbmJzcDsvbGliL3NlY3VyaXR5LyRJ U0EvcGFtX3Jvb3Rvay5zbzwvRElWPg0KPERJVj4jJm5ic3A7VW5jb21tZW50Jm5ic3A7dGhlJm5i c3A7Zm9sbG93aW5nJm5ic3A7bGluZSZuYnNwO3RvJm5ic3A7aW1wbGljaXRseSZuYnNwO3RydXN0 Jm5ic3A7dXNlcnMmbmJzcDtpbiZuYnNwO3RoZSZuYnNwOyJ3aGVlbCImbmJzcDtncm91cC48L0RJ Vj4NCjxESVY+I2F1dGgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtz dWZmaWNpZW50Jm5ic3A7Jm5ic3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8kSVNBL3BhbV93aGVlbC5z byZuYnNwO3RydXN0Jm5ic3A7dXNlX3VpZDwvRElWPg0KPERJVj4jJm5ic3A7VW5jb21tZW50Jm5i c3A7dGhlJm5ic3A7Zm9sbG93aW5nJm5ic3A7bGluZSZuYnNwO3RvJm5ic3A7cmVxdWlyZSZuYnNw O2EmbmJzcDt1c2VyJm5ic3A7dG8mbmJzcDtiZSZuYnNwO2luJm5ic3A7dGhlJm5ic3A7IndoZWVs IiZuYnNwO2dyb3VwLjwvRElWPg0KPERJVj4jYXV0aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO3JlcXVpcmVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7L2xp Yi9zZWN1cml0eS8kSVNBL3BhbV93aGVlbC5zbyZuYnNwO3VzZV91aWQ8L0RJVj4NCjxESVY+YXV0 aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlcXVpcmVkJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8kSVNBL3BhbV9zdGFjay5zbyZu YnNwO3NlcnZpY2U9c3lzdGVtLWF1dGg8L0RJVj4NCjxESVY+YWNjb3VudCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO3N1ZmZpY2llbnQmbmJzcDsmbmJzcDsmbmJzcDsvbGliL3NlY3VyaXR5LyRJU0Ev cGFtX3N1Y2NlZWRfaWYuc28mbmJzcDt1aWQ9MCZuYnNwO3VzZV91aWQmbmJzcDtxdWlldDwvRElW Pg0KPERJVj5hY2NvdW50Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVxdWlyZWQmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsvbGliL3NlY3VyaXR5LyRJU0EvcGFtX3N0YWNrLnNvJm5ic3A7 c2VydmljZT1zeXN0ZW0tYXV0aDwvRElWPg0KPERJVj5wYXNzd29yZCZuYnNwOyZuYnNwOyZuYnNw O3JlcXVpcmVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7L2xpYi9zZWN1cml0eS8kSVNB L3BhbV9zdGFjay5zbyZuYnNwO3NlcnZpY2U9c3lzdGVtLWF1dGg8L0RJVj4NCjxESVY+IyZuYnNw O3BhbV9zZWxpbnV4LnNvJm5ic3A7Y2xvc2UmbmJzcDttdXN0Jm5ic3A7YmUmbmJzcDtmaXJzdCZu YnNwO3Nlc3Npb24mbmJzcDtydWxlPC9ESVY+DQo8RElWPnNlc3Npb24mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtyZXF1aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy9saWIvc2VjdXJp dHkvJElTQS9wYW1fc2VsaW51eC5zbyZuYnNwO2Nsb3NlPC9ESVY+DQo8RElWPnNlc3Npb24mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtyZXF1aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Oy9saWIvc2VjdXJpdHkvJElTQS9wYW1fc3RhY2suc28mbmJzcDtzZXJ2aWNlPXN5c3RlbS1hdXRo PC9ESVY+DQo8RElWPiMmbmJzcDtwYW1fc2VsaW51eC5zbyZuYnNwO29wZW4mbmJzcDthbmQmbmJz cDtwYW1feGF1dGgmbmJzcDttdXN0Jm5ic3A7YmUmbmJzcDtsYXN0Jm5ic3A7dHdvJm5ic3A7c2Vz c2lvbiZuYnNwO3J1bGVzPC9ESVY+DQo8RElWPnNlc3Npb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtyZXF1aXJlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy9saWIvc2VjdXJpdHkvJElT QS9wYW1fc2VsaW51eC5zbyZuYnNwO29wZW48L0RJVj4NCjxESVY+c2Vzc2lvbiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO29wdGlvbmFsJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7L2xpYi9z ZWN1cml0eS8kSVNBL3BhbV94YXV0aC5zbzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+VGhhbmtzIGEgbG90 LjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjwvRElWPg0KPERJ Vj5CZXN0Jm5ic3A7UmVnYXJkczwvRElWPg0KPERJVj5RaXVsYW4mbmJzcDtIdWFuZzwvRElWPg0K PERJVj4yMDEzLTEwLTIyPC9ESVY+DQo8RElWPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9ESVY+DQo8RElWPkNvbXB1 dGluZyZuYnNwO2NlbnRlcix0aGUmbmJzcDtJbnN0aXR1dGUmbmJzcDtvZiZuYnNwO0hpZ2gmbmJz cDtFbmVyZ3kmbmJzcDtQaHlzaWNzLCZuYnNwO0NoaW5hPC9ESVY+DQo8RElWPkh1YW5nLCZuYnNw O1FpdWxhbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RlbDombmJzcDsoKzg2KSZuYnNw OzEwJm5ic3A7ODgyMyZuYnNwOzYwMTAtMTA1PC9ESVY+DQo8RElWPlAuTy4mbmJzcDtCb3gmbmJz cDs5MTgtNyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0ZheDombmJzcDsoKzg2KSZuYnNwOzEwJm5i c3A7ODgyMyZuYnNwOzY4Mzk8L0RJVj4NCjxESVY+QmVpamluZyZuYnNwOzEwMDA0OSZuYnNwOyZu YnNwO1AuUi4mbmJzcDtDaGluYSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0VtYWlsOiZuYnNwOzxBIA0KaHJlZj0ibWFpbHRv Omh1YW5ncWxAaWhlcC5hYy5jbiI+aHVhbmdxbEBpaGVwLmFjLmNuPC9BPjwvRElWPg0KPERJVj49 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09IDwvRElWPg0KPEhSIGNvbG9yPSNiNWM0ZGYgU0laRT0xPg0KPC9ESVY+DQo8RElW PjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz7lj5Hku7bkurrvvJo8L1NUUk9ORz4g QnJhbmRvbiBBbGxiZXJ5IA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1W ZXJkYW5hPjxTVFJPTkc+5Y+R6YCB5pe26Ze077yaPC9TVFJPTkc+IDIwMTMtMTAtMjImbmJzcDsg MjE6MjM6MDMgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+ PFNUUk9ORz7mlLbku7bkurrvvJo8L1NUUk9ORz4gaHVhbmdxbDsgb3BlbmFmcy1pbmZvIA0KPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTVFJPTkc+5oqE6YCB 77yaPC9TVFJPTkc+IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFu YT48U1RST05HPuS4u+mimO+8mjwvU1RST05HPiBSZTogW09wZW5BRlNdIFBBTSANCmF1dGhlbnRp Y2F0aW9uIGZhaWxlZCBvbiBTTDYgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFj ZT1WZXJkYW5hPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT4N CjxESVY+T24mbmJzcDsxMC8yMi8xMyZuYnNwOzA1OjM4LCZuYnNwOyJodWFuZ3FsIiZuYnNwOyZs dDs8QSANCmhyZWY9Im1haWx0bzpodWFuZ3FsQGloZXAuYWMuY24iPmh1YW5ncWxAaWhlcC5hYy5j bjwvQT4mZ3Q7Jm5ic3A7d3JvdGU6PC9ESVY+DQo8RElWPiZndDtUaGUmbmJzcDtxdWVzdGlvbnMm bmJzcDtzdHVjayZuYnNwO21lJm5ic3A7Zm9yJm5ic3A7d2Vla3MuJm5ic3A7RG9lcyZuYnNwO2Fu eW9uZSZuYnNwO2dldCZuYnNwO3RoZSZuYnNwO3NhbWUmbmJzcDtwcm9ibGVtJm5ic3A7YW5kPC9E SVY+DQo8RElWPiZndDtjb3VsZCZuYnNwO3lvdSZuYnNwO2dpdmUmbmJzcDttZSZuYnNwO3NvbWUm bmJzcDtzdWdnZXN0aW9ucz88L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPllvdSZuYnNwO2Rvbid0 Jm5ic3A7cHJvdmlkZSZuYnNwO2Vub3VnaCZuYnNwO2luZm9ybWF0aW9uLCZuYnNwO2JlY2F1c2Um bmJzcDthbGwmbmJzcDt0aGUmbmJzcDtzdGFja3MmbmJzcDt5b3UmbmJzcDtwcm92aWRlZDwvRElW Pg0KPERJVj51c2UmbmJzcDtwYW1fc3RhY2suc28mbmJzcDt0byZuYnNwO2xvYWQmbmJzcDt0aGUm bmJzcDtzeXN0ZW0tYXV0aCZuYnNwO3N0YWNrJm5ic3A7d2hpY2gmbmJzcDt5b3UmbmJzcDtkaWRu J3QmbmJzcDtwcm92aWRlLjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+LS0mbmJzcDs8L0RJVj4N CjxESVY+YnJhbmRvbiZuYnNwO3MmbmJzcDthbGxiZXJ5Jm5ic3A7a2Y4bmgmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtzaW5lJm5ic3A7bm9taW5lJm5ic3A7YXNzb2NpYXRlczwvRElWPg0KPERJVj48 QSANCmhyZWY9Im1haWx0bzphbGxiZXJ5LmJAZ21haWwuY29tIj5hbGxiZXJ5LmJAZ21haWwuY29t PC9BPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxBIA0KaHJlZj0i bWFpbHRvOmJhbGxiZXJ5QHNpbmVub21pbmUubmV0Ij5iYWxsYmVyeUBzaW5lbm9taW5lLm5ldDwv QT48L0RJVj4NCjxESVY+dW5peCwmbmJzcDtvcGVuYWZzLCZuYnNwO2tlcmJlcm9zLCZuYnNwO2lu ZnJhc3RydWN0dXJlLCZuYnNwO3htb25hZDwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+PC9ESVY+ DQo8RElWPjwvRElWPjwvRk9OVD48L0RJVj48L0RJVj48L0RJVj48L1NQQU4+PC9GT05UPjwvRElW PjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon804576371781_=====-- From rmdyer@uncc.edu Tue Oct 22 17:18:34 2013 From: rmdyer@uncc.edu (Dyer, Rodney) Date: Tue, 22 Oct 2013 16:18:34 +0000 Subject: [OpenAFS] not enough space in target directory In-Reply-To: <52633F5E.7090501@your-file-system.com> References: <524F4305.4030102@googlemail.com> <524F5AD5.2070006@your-file-system.com> <52633F5E.7090501@your-file-system.com> Message-ID: <18B8F39B03C7B445B4C3B97D55D4555B1333A396@RPITSEXMS3.its.uncc.edu> VGhpcyBwcm9ibGVtIGlzIGFmZmVjdGluZyB1cyBhcyB3ZWxsLg0KDQpJJ20gbm90IGVudGlyZWx5 IGNvbnZpbmNlZCB0aGlzIHByb2JsZW0gY291bGRuJ3QgYmUgZml4ZWQgd2l0aCBzb21lIEFGUyBj bGllbnQgdHJpY2tlcnkuDQoNCk91ciBpc3N1ZSBpcyB0aGF0IHdlIGhhdmUgYSBkcml2ZSBtYXBw ZWQgdG8gdGhlIGNlbGwgcm9vdC4NCg0KU2luY2Ugb3VyIGRyaXZlIGlzIG1hcHBlZCB0byB0aGUg cm9vdCwgdGhlIGFwcGxpY2F0aW9uICd0aGlua3MnIHRoZSBlbnRpcmUgZmlsZSBzeXN0ZW0gb24g dGhhdCAnZHJpdmUnIGlzIG9uZSAndm9sdW1lJy4NCg0KU29tZSBvZiBvdXIgYXBwbGljYXRpb25z IHRyeSB0byBiZSAnc21hcnQnIGFuZCBjaGVjayB0aGUgJ2Rpc2sgZnJlZScgYmVmb3JlIHRoZXkg cGVyZm9ybSB0aGVpciB3cml0ZXMuDQoNCihOb3RlOiBJbiBteSBoaXN0b3J5IGFzIGEgcHJvZ3Jh bW1lciwgd2Ugd291bGQganVzdCBvcGVuIHRoZSBmaWxlIGZvciAnd3JpdGUnIGFuZCBrZWVwIHdy aXRpbmcgdW50aWwgd2UgcnVuIG91dCBvZiBzcGFjZSB3aXRoIGEgJ291dCBvZiBzcGFjZScgZXJy b3Igb2NjdXJzIGZyb20gdGhlICdDJyBjYWxscy4gIEkgdGhpbmsgdGhlIGVycm9yIHdhcyBFTk9T UEMsICdObyBzcGFjZSBsZWZ0IG9uIGRldmljZScuICkNCg0KSSB1bmRlcnN0YW5kIHRoYXQgLWlm LSB0aGUgQUZTIGNsaWVudCB3ZXJlIHRvIHJldHVybiBhbiBhcmJpdHJhcmlseSBsYXJnZSBzaXpl IG51bWJlciBmb3IgdGhlICdkaXNrIGZyZWUnIG9uIHRoZW0gbWFwcGVkIGRyaXZlLCBhbmQgdGhl IGFwcGxpY2F0aW9uIHdyaXRlcyBpbnRvIGEgc3ViLWZvbGRlciwgdGhlbiB0aGF0IHN1Yi1mb2xk ZXIgbWF5IGJlIGFuIEFGUyB2b2x1bWUgdGhhdCBkb2Vzbid0IGhhdmUgdGhhdCAnZGlzayBzcGFj ZScgYXZhaWxhYmxlLiAgSW4gdGhhdCBjYXNlIHRoZSBhcHBsaWNhdGlvbiB3b3VsZCBsb3NlIGRh dGEgd2hlbiBnb2luZyBvdmVyIHF1b3RhIGZvciB0aGUgdm9sdW1lLiAgU28gc29tZSBkZWNpc2lv biB3YXMgbWFkZSB0byByZXR1cm4gJ3plcm8gYnl0ZXMgYXZhaWxhYmxlJyBvbiBhbGwgZHJpdmVz IG1hcHBlZCB0byB0aGUgQUZTIHJvb3QuDQoNCllvdSBnZXQgYXJvdW5kIHRoZSBpc3N1ZSBieSBt YXBwaW5nIGEgZHJpdmUgZGlyZWN0bHkgdG8gdGhlIEFGUyB2b2x1bWUgaW4gd2hpY2ggeW91IG5l ZWQgdG8gd3JpdGUgdG8uDQoNCklmIHlvdSBkb24ndCBjYXJlIGFib3V0IGxvc2luZyBkYXRhLCBv bmUgc29sdXRpb24gaXMgdG8gJ3N5bWxpbmsnIHRoZSBjZWxsIGludG8gdGhlIEM6IGRyaXZlLCBh cyBmb2xsb3dzLi4uDQoNCiAgICAgQzpcPm1rbGluayAvZCBjOlxhZnMgXFxhZnNccm9vdC5hZnMN Cg0KICAgICBBIERJUiBvZiBjOlwgd2lsbCB0aGVuIHJldHVybiB3aGF0IGlzIGF2YWlsYWJsZSBv biB5b3VyIEM6IGRyaXZlLg0KDQpXZSByYW4gdGhlIEFGUyBjbGllbnQgZm9yIHllYXJzIG9uIFdp bmRvd3MgWFAgYW5kIGl0IGFsd2F5cyByZXR1cm5zIDIgVEIgYXMgZnJlZSBvbiBhIG1hcHBlZCBk cml2ZS4NCg0KVGhpcyBpcyBhIFZFUlkgYW5ub3lpbmcgcHJvYmxlbS4NCg0KSSB3aXNoIEFGUyB3 b3VsZCBwcmV2ZW50IHlvdSBmcm9tIHdyaXRpbmcgbW9yZSBpbnRvIGEgdm9sdW1lIHRoYW4gdGhl IHF1b3RhIHNpemUgdGhhdCB5b3Ugd2VyZSBhbGxvY2F0ZWQuICBJbiB0aGF0IGNhc2UgcmV0dXJu aW5nIEVOT1NQQywgJ05vIHNwYWNlIGxlZnQgb24gZGV2aWNlJyBzaG91bGQgYmUgYXBwbGljYWJs ZS4NCg0KUm9kbmV5DQoNClJvZG5leSBNLiBEeWVyDQpPcGVyYXRpb25zIGFuZCBTeXN0ZW1zIChT cGVjaWFsaXN0KQ0KTW9zYWljIENvbXB1dGluZyBHcm91cA0KV2lsbGlhbSBTdGF0ZXMgTGVlIENv bGxlZ2Ugb2YgRW5naW5lZXJpbmcNClVuaXZlcnNpdHkgb2YgTm9ydGggQ2Fyb2xpbmEgYXQgQ2hh cmxvdHRlDQpFbWFpbDogcm1keWVyQHVuY2MuZWR1DQpQaG9uZTogKDcwNCk2ODctMTk0Mg0KSGVs cCBEZXNrIExpbmU6ICg3MDQpNjg3LTUwODANCkZBWDogKDcwNCk2ODctMjM1Mg0KT2ZmaWNlOsKg IENhbWVyb24gSGFsbCwgUm9vbSAyMzINCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogb3BlbmFmcy1pbmZvLWFkbWluQG9wZW5hZnMub3JnIFttYWlsdG86b3BlbmFm cy1pbmZvLWFkbWluQG9wZW5hZnMub3JnXSBPbiBCZWhhbGYgT2YgSmVmZnJleSBBbHRtYW4NClNl bnQ6IFNhdHVyZGF5LCBPY3RvYmVyIDE5LCAyMDEzIDEwOjI3IFBNDQpUbzogSWFuIENyb3d0aGVy OyBvcGVuYWZzLWluZm9Ab3BlbmFmcy5vcmcNClN1YmplY3Q6IFJlOiBbT3BlbkFGU10gbm90IGVu b3VnaCBzcGFjZSBpbiB0YXJnZXQgZGlyZWN0b3J5DQoNCk9uIDEwLzE1LzIwMTMgNzowNyBQTSwg SWFuIENyb3d0aGVyIHdyb3RlOg0KPiBPbmUgdGhpbmcgSSBub3RpY2VkIGluIG15IGNhc2Ugd2Fz IHRoYXQgcHJvY2VzcyBtb25pdG9yIHJlcG9ydGVkIHRoYXQNCj4gZXhwbG9yZXIgY2hlY2tlZCBm cmVlIHNwYWNlIG9uIHRoZSByb290IHZvbHVtZSBpbnN0ZWFkIG9mIHRoZSB2b2x1bWUNCj4gdGhh dCB3YXMgYmVpbmcgd3JpdHRlbiB0by4NCg0KVGhhdCBpcyB0aGUgdW5kZXJseWluZyBwcm9ibGVt LiAgSW5zdGVhZCBvZiB1c2luZw0KR2V0Vm9sdW1lSW5mb3JtYXRpb25CeUhhbmRsZVcoKSBjYWxs ZWQgb24gdGhlIGRlc3RpbmF0aW9uIGRpcmVjdG9yeSB0aGUNCkV4cGxvcmVyIFNoZWxsIGlzIHVz aW5nIEdldFZvbHVtZUluZm9ybWF0aW9uKCkgd2hpY2ggbXVzdCBiZSBwcm92aWRlZA0KdGhlIHJv b3QgZGlyZWN0b3J5IG9mIHRoZSB2b2x1bWUuICBXaGVuIHRoZSBFeHBsb3JlciBTaGVsbCBnZXRz IHRoZSByb290DQpkaXJlY3Rvcnkgd3JvbmcgYW5kIGNob29zZSBzYXkgdGhlIHJvb3Qgb2YgYSBk cml2ZSBsZXR0ZXIgbWFwcGluZywgdGhlbg0KaXQgZ2V0cyB0aGUgd3Jvbmcgdm9sdW1lIGF0dHJp YnV0ZXMgYW5kIGZyZWUgc3BhY2UuDQoNCj4gV291bGQgc29tZWhvdyBlbnN1cmluZyB0aGF0IHRo ZSBBRlMgc2VydmVyJ3Mgcm9vdCB2b2x1bWUgcmVwb3J0cw0KPiBzdWZmaWNpZW50IGZyZWUgc3Bh Y2UgYmUgYW4gYWRlcXVhdGUgd29ya2Fyb3VuZD8gSSBoYXZlIG5vIGlkZWEsIGJ1dA0KPiBpZiBJ IHdlcmUgc3RpbGwgYWZmZWN0ZWQgSSdkIHRyeSBpdC4uLg0KDQpSZWFkb25seSB2b2x1bWVzIGhh dmUgMCBieXRlcyBmcmVlLiAgIFRoYXQgaXMgd2h5IHRoaXMgaXMgYSBwcm9ibGVtIGZvcg0KQUZT IGFuZCBub3QgV2luZG93cyBGaWxlIFNoYXJlcy4gIFdpbmRvd3MgZG9lc24ndCBzdXBwb3J0IHRo ZSBjb25jZXB0IG9mDQpib290aW5nIGZyb20gYSByZWFkb25seSB2b2x1bWUgYW5kIHRoZW4gYWNj ZXNzaW5nIHdyaXRhYmxlIGFyZWFzIGZyb20gYQ0KcmVhZC93cml0ZSB2b2x1bWUuICBJZiBpdCBk aWQsIHRoZSBFeHBsb3JlciBTaGVsbCB3b3VsZCBiZSBpbW11bmUgdG8NCnRoaXMgaXNzdWUuDQoN ClRoZSBwcm9ibGVtIGRvZXNuJ3Qgb2NjdXIgYWxsIG9mIHRoZSB0aW1lIGFuZCBNaWNyb3NvZnQg ZG9lc24ndCBoYXZlDQppbnRlcm5hbCBBRlMgdG8gdGVzdCBhZ2FpbnN0IHNvIGl0IGlzIGEgY2hh bGxlbmdlIGZvciB0aGVtLg0KDQpKZWZmcmV5IEFsdG1hbg0KDQoNCg== From bloeb@nd.edu Tue Oct 22 18:29:44 2013 From: bloeb@nd.edu (Bart Loeb) Date: Tue, 22 Oct 2013 13:29:44 -0400 Subject: [OpenAFS] A Message-ID: <487E3D48-AC58-483D-B6BA-D2202D66CEB8@nd.edu> Sent from my iPhone From ArunR@microland.com Tue Oct 1 11:07:43 2013 From: ArunR@microland.com (Arun Raj) Date: Tue, 1 Oct 2013 15:37:43 +0530 Subject: [OpenAFS] Documentation on How OpenAFS works Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CEBE8D.FE6E6537 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Team, = Can anyone of you provide us a detailed documentation on "How OpenAFS is designed to work?" We are planning to recommend OpenAFS in an organization for their Mac machines. The organization is looking forward to renew the Kerberos tokens on their Mac machines. = Thanks & Regards, = Arun Raj The information transmitted is intended only for the person or entity to wh= ich it is addressed and may contain confidential and/or privileged material= . = Any review, re-transmission, dissemination or other use of or taking of any= action in reliance upon,this information by persons or entities other than= the intended recipient is prohibited. = If you received this in error, please contact the sender and delete the mat= erial from your computer. = Microland takes all reasonable steps to ensure that its electronic communic= ations are free from viruses. = However, given Internet accessibility, the Company cannot accept liability = for any virus introduced by this e-mail or any attachment and you are advis= ed to use up-to-date virus checking software. ------_=_NextPart_001_01CEBE8D.FE6E6537 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Team,

Can anyone of you provide us a detailed document= ation on “How OpenAFS is designed to work?” We are planni= ng to recommend OpenAFS in an organization for their Mac machines. Th= e organization is looking forward to renew the Kerberos tokens on their Mac= machines.

Thanks & Regards,

Arun Raj

T= he information transmitted is intended only for the person or entity to whi= ch it is addressed and may contain confidential and/or privileged material.=
Any review, re-transmission, dissemination or other use of or taking o= f any action in reliance upon,this information by persons or entities other= than the intended recipient is prohibited.
If you received this in err= or, please contact the sender and delete the material from your computer. <= br>Microland takes all reasonable steps to ensure that its electronic commu= nications are free from viruses.
However, given Internet accessibility,= the Company cannot accept liability for any virus introduced by this e-mai= l or any attachment and you are advised to use up-to-date virus checking so= ftware.

------_=_NextPart_001_01CEBE8D.FE6E6537-- From tdopirak@gmail.com Thu Oct 10 23:17:19 2013 From: tdopirak@gmail.com (Tom Dopirak) Date: Thu, 10 Oct 2013 18:17:19 -0400 Subject: [OpenAFS] Re: [Elders] [OpenAFS-announce] OpenAFS Foundation Update In-Reply-To: References: Message-ID: <2AAD656A-F787-4D7E-910A-5D188F313797@gmail.com> --Apple-Mail-689ECA02-5B10-4DF5-BECA-744F8573DCA8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable You rock. Thanks. Sent from my iPad > On Oct 7, 2013, at 14:42, Roman Mitz wrote: >=20 > It's been a while. Here are the latest updates, with apologies for the de= lay. >=20 > Updates: > * A signed agreement has been struck between IBM and representatives of t= he Creation Committee. >=20 > * Our lawyers reviewed, then submitted the incorporation papers for The Op= enAFS Foundation, Inc.;=20 >=20 > * The foundation has been created. >=20 > * A bank account has been opened. >=20 > * All funds remaining from previous years (not dedicated to the OpenAFS Wo= rkshops) have been transferred into the new bank account. >=20 > * Working on filing non-profit status with the IRS. >=20 >=20 >=20 > Details: >=20 > * Todd has been instrumental in facilitating the complicated process of ge= tting a signed agreement and of having IBM agree that we may use the terms "= AFS" and "OpenAFS" in the name and description of the Foundation. This was a= critical step in preventing potential legal issues over naming and terminol= ogy in the future, which many of us had been fearing and hoping to avoid. Fu= ture agreements covering other aspects will likely have to be forged, but th= e first step has been done successfully. >=20 > * The firm's team reviewed what our group had compiled to-date as required= materials going into the application package for the foundation of the Foun= dation. OpenAFS Foundation, Inc., is now incorporated and marked as non-pro= fit-to-be in the incorporation categorization. This means that the Foundati= on now exists as a legal, independent entity. For the purposes of the incor= poration, all five of us had to be listed as preliminary directors, but we w= ill hand over this role when the first true board members have been chosen. >=20 > * Also, Roman opened an independent bank account for the Foundation with t= he PNC Bank. As the minimal number of authorized signors should be two, the= Pittsburgh location was the logical choice. >=20 > * All moneys previously donated to the cause of OpenAFS were transferred f= rom the previous account at CMU into the new bank account. Funds for the cu= rrent OpenAFS Workshops are kept separately in that existing organization. W= e are happy that we could meet the fiscal year deadline by Carnegie Mellon, a= nd all went smoothly. These moneys are now available to the Foundation as o= perating funds. >=20 >=20 >=20 > Next steps and how you can help: >=20 > * The Creation Committee, after having procured a tax ID for the newly inc= orporated Foundation, will need to compile the packet of materials supportin= g our application for official non-profit status with the IRS. It is the IR= S that awards this status, if our application is approved; if the approval f= ails, we will have the opportunity to improve the organization and/or applic= ation and re-try at a later date. >=20 > * In the not too distant future, the preliminary board (i.e. Our Creation C= ommittee) wants to hand over the baton to the initial Board of Directors. T= hus, we are seeking individuals with a proven track record of business succe= ss and with good connections. You may help us with suggestions or volunteer= ing; resumes would be most helpful. The Creation Committee can then contact= viable candidates and invite them to serve pro-bono on our initial Board of= Directors. >=20 > Roman, on behalf of the Creation Committee >=20 >=20 >=20 > PS: This update is being published in both the OpenAFS newsletter and via t= he openafs-announce list in an attempt to reach the broadest audience. Plea= se direct any questions or comments to foundation-discuss@openafs.org -- Tha= nk you. --Apple-Mail-689ECA02-5B10-4DF5-BECA-744F8573DCA8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

You rock. Thanks.

Sent from my iPad

On Oct 7, 2013, at 14:42, Roman Mitz <rmitz@openafs.org> wrote:

It's been a while. Here are the latest updates, with apologies for the delay.

Updates:
* A signed agreement has been struck between IBM and representatives of the Creation Committee.

* Our lawyers reviewed, then submitted the incorporation papers for The OpenAFS Foundation, Inc.;
* The foundation has been created.
* A bank account has been opened.
* All funds remaining from previous years (not dedicated to the OpenAFS Workshops) have been transferred into the new bank account.

* Working on filing non-profit status with the IRS.

Details:
* Todd has been instrumental in facilitating the complicated process of getting a signed agreement and of having IBM agree that we may use the terms "AFS" and "OpenAFS" in the name and description of the Foundation. This was a critical step in preventing potential legal issues over naming and terminology in the future, which many of us had been fearing and hoping to avoid. Future agreements covering other aspects will likely have to be forged, but the first step has been done successfully.

* The firm's team reviewed what our group had compiled to-date as required materials going into the application package for the foundation of the Foundation. OpenAFS Foundation, Inc., is now incorporated and marked as non-profit-to-be in the incorporation categorization. This means that the Foundation now exists as a legal, independent entity. For the purposes of the incorporation, all five of us had to be listed as preliminary directors, but we will hand over this role when the first true board members have been chosen.

* Also, Roman opened an independent bank account for the Foundation with the PNC Bank. As the minimal number of authorized signors should be two, the Pittsburgh location was the logical choice.
* All moneys previously donated to the cause of OpenAFS were transferred from the previous account at CMU into the new bank account. Funds for the current OpenAFS Workshops are kept separately in that existing organization. We are happy that we could meet the fiscal year deadline by Carnegie Mellon, and all went smoothly. These moneys are now available to the Foundation as operating funds.

Next steps and how you can help:
* The Creation Committee, after having procured a tax ID for the newly incorporated Foundation, will need to compile the packet of materials supporting our application for official non-profit status with the IRS. It is the IRS that awards this status, if our application is approved; if the approval fails, we will have the opportunity to improve the organization and/or application and re-try at a later date.

* In the not too distant future, the preliminary board (i.e. Our Creation Committee) wants to hand over the baton to the initial Board of Directors. Thus, we are seeking individuals with a proven track record of business success and with good connections. You may help us with suggestions or volunteering; resumes would be most helpful. The Creation Committee can then contact viable candidates and invite them to serve pro-bono on our initial Board of Directors.

Roman, on behalf of the Creation Committee

PS: This update is being published in both the OpenAFS newsletter and via the openafs-announce list in an attempt to reach the broadest audience. Please direct any questions or comments to foundation-discuss@openafs.org -- Thank you.

--Apple-Mail-689ECA02-5B10-4DF5-BECA-744F8573DCA8-- From dhk@ccreinc.com Thu Oct 17 16:40:54 2013 From: dhk@ccreinc.com (Kim Kimball) Date: Thu, 17 Oct 2013 09:40:54 -0600 Subject: [OpenAFS] Re: RClone - Volume already exists In-Reply-To: <15975251.35668.1381924534619.JavaMail.root@m09> References: <1381837070.6906.4.camel@srv31.corp.novso.com> <20131015100825.47410db7.adeason@sinenomine.net> <1381922349.22363.2.camel@srv31.corp.novso.com> <15975251.35668.1381924534619.JavaMail.root@m09> Message-ID: <52600506.7080606@ccreinc.com> Did you try to "vos zap" against the Rclone ID? ISTR that working for me at some point ... Kim On 10/16/2013 5:52 AM, Lars Schimmer wrote: > On 2013-10-16 13:19, Nicolas DEFFAYET wrote: > >> SalvageLog >> --- >> @(#) OpenAFS 1.6.1-3+deb7u1-debian built 2013-07-25 >> STARTING AFS SALVAGER 2.4 (/usr/lib/openafs/salvager /vicepa 536870936) >> namei_ListAFSSubDirs: warning: VG 536870936 does not have a link table; >> salvager will recreate it. >> 536870936 is a read-only volume; not salvaged > In these cases I always do a bos salvage server partition TWICE ! > It will salvage the complete partition and cleans up the partition also. > Downside: server is down for this event. > >> Thanks for your help >> >> > > MfG, > Lars Schimmer From dvorkias@rwjms.rutgers.edu Wed Oct 23 04:30:27 2013 From: dvorkias@rwjms.rutgers.edu (Dvorkin, Asya) Date: Tue, 22 Oct 2013 23:30:27 -0400 Subject: [OpenAFS] OpenAFS backups with InMage Message-ID: <71335543-7DA9-4B37-8ABF-47563D7A8DD7@rutgers.edu> Hello, We are considering purchasing backup/data replication software by the compa= ny InMage. I've asked during their presentation if they support OpenAFS ba= ckups and was given a positive response. =20 I'm wondering if anyone in the group successfully uses InMage's Scout produ= ct in conjunction with OpenAFS? Thank you, Asya= From adeason@sinenomine.net Wed Oct 23 21:58:49 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Wed, 23 Oct 2013 15:58:49 -0500 Subject: [OpenAFS] Re: client kernel panic on EL6 References: <20131021101343.e3038182.adeason@sinenomine.net> Message-ID: <20131023155849.a34340e6.adeason@sinenomine.net> On Mon, 21 Oct 2013 10:13:43 -0500 Andrew Deason wrote: > Various code paths were adjusted to try to handle the error as > gracefully as possible, but some were more complex/difficult than > others. A few, such as the specific backtrace you mentioned, have not > hit 1.6 yet, since I was concerned about introducing new/different > errors in the error handling since we didn't really know what was > going on in these scenarios. After some discussion, these are now being considered for inclusion in 1.6.6 (gerrits 10354-10358). If anyone wants more information on this issue, follow ticket 131747 -- Andrew Deason adeason@sinenomine.net From jaltman@your-file-system.com Sun Oct 27 08:41:57 2013 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Sun, 27 Oct 2013 03:41:57 -0400 Subject: [OpenAFS] not enough space in target directory In-Reply-To: <18B8F39B03C7B445B4C3B97D55D4555B1333A396@RPITSEXMS3.its.uncc.edu> References: <524F4305.4030102@googlemail.com> <524F5AD5.2070006@your-file-system.com> <52633F5E.7090501@your-file-system.com> <18B8F39B03C7B445B4C3B97D55D4555B1333A396@RPITSEXMS3.its.uncc.edu> Message-ID: <526CC3C5.6020004@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms020308000003020008010802 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/22/2013 12:18 PM, Dyer, Rodney wrote: > This problem is affecting us as well. >=20 > I'm not entirely convinced this problem couldn't be fixed with some AFS= client trickery. As you so often like to tell me the application should attempt the operation to the file system and let it fail if it is going to fail. The problem with the Explorer Shell is that it tries to be smarter than the file system. The Explorer Shell maintains a cache of all of path components including which volume that path is in, what the volume attributes are and how much free space is present there. When that cache becomes corrupted the explorer shell makes incorrect decisions about which volume a path refers to and how much free space there is. To the best of my knowledge there is no ability to reset the explorer cache other than killing the explorer process. When the explorer shell guesses that there is no free space at a particular path it will never even try the operation. It assumes it is smarter. > Our issue is that we have a drive mapped to the cell root. >=20 > Since our drive is mapped to the root, the application 'thinks' the ent= ire file system on that 'drive' is one 'volume'. I'm not sure how you have come to this conclusion. Lets say that your cell layout looks like: \\afs\college.edu\user\username\windows\profile.V2\ where college.exe mp-> root.cell.readonly user mp-> root.user.readonly username mp-> user.username windows =3D directory profile.V2 =3D directory and you have mapped R: to \\afs\college.edu If the application thinks that the entire tree under R: is one volume that is not the fault of AFS. AFS tells the application this is not the case by setting the Reparse Point File Attribute on each mount point and by setting the Surrogate Bit in the Reparse Point Tag value. The RP Surrogate bit tells the application that the reparse point is a place holder for some other object which might not be in the same volume. The application doesn't need to know anything about AFS. It just needs to follow the rules for parsing the output of Win32 Directory Queries and File Information Queries. If you have an application that is incapable of processing reparse points you should raise that issue with the application vendor because that application is going to break on every Windows File System that supports reparse points. > Some of our applications try to be 'smart' and check the 'disk free' be= fore they perform their writes. The applications do this because the Windows Cache (not the AFS cache) will permit an application to write into the cache as much data as it wants until the file system tells the Windows Cache that there is no more room. Unfortunately some network file system clients have a very poor idea of the free space on the server (think SMB/CIFS). As a result the application can write hundreds of MBs or GBs of data into the Windows cache before the Windows cache begins to lazy write the data to the network. If it turns out there is no room, the application is told a network error occurred and the data is lost. In XP a balloon would appear with an error message indicating that data was lost. In Vista and above the error is written to the Windows Application Event Log but the end user isn't even told. So applications have a very good reason to check the free space or use non-cached writes if they actually care about their data getting to the file server when the disk is "remote" because aren't all "remote" disks "SMB/CIFS"? > (Note: In my history as a programmer, we would just open the file for '= write' and keep writing until we run out of space with a 'out of space' e= rror occurs from the 'C' calls. I think the error was ENOSPC, 'No space = left on device'. ) I have just explained the problem with this approach. > I understand that -if- the AFS client were to return an arbitrarily lar= ge size number for the 'disk free' on them mapped drive, and the applicat= ion writes into a sub-folder, then that sub-folder may be an AFS volume t= hat doesn't have that 'disk space' available. In that case the applicati= on would lose data when going over quota for the volume. So some decisio= n was made to return 'zero bytes available' on all drives mapped to the A= FS root. The AFS redirector reports the actual amount of free space for each volume when asked. If the AFS redirector is never asked, it never tells. Readonly volumes have 0 free space and therefore the reported free space is 0 bytes. No one is forcing applications to query the amount of free space on the volume. If an application is doing so its because the author felt that it was necessary to protect the user. Lying about the size of the partition, the size of the volume and the amount of free space accessible to the user puts the application at risk. By lying the application developer that does the right thing is being punished in place of the application developer that does the wrong thing. > You get around the issue by mapping a drive directly to the AFS volume = in which you need to write to. You could also contact the application author and file a bug report to get the application fixed. > If you don't care about losing data, one solution is to 'symlink' the c= ell into the C: drive, as follows... >=20 > C:\>mklink /d c:\afs \\afs\root.afs >=20 > A DIR of c:\ will then return what is available on your C: drive. Which is great until the free space on the C: drive drops to nothing because of shadow volume snapshots, pagefile increases, or other reasons. Current free space on my C: disk. 618,112 bytes free 99.9 % in use It was 5GB free about 12 hours ago. During disk backups the volume checkpoint and NTFS journal uses up all of the free space. All you are doing is trading one problem for another. > We ran the AFS client for years on Windows XP and it always returns 2 T= B as free on a mapped drive. This statement is incorrect. As an SMB server it is not possible for the individual AFS volumes to be reported as independent devices. Therefore the size of the one volume reported to the SMB client is that of the entire AFS name space. That is effectively infinite but such a volume cannot be reported. So the volume size was always reported as 2TB and the free space as 1TB. Then you would run Microsoft Office and find that sometimes your powerpoint or word or excel documents would get corrupted because the application believed the data was written to disk and it was only during the cache flush that occurs when the last handle is closed that the data would be pushed to the file server where there would be no space. There was also the problem that applications couldn't write a file larger than 1TB and some applications would get very confused when the sum of all files in a directory tree were larger than the partition size.= Finally because there was no mechanism of exposing volume boundaries, when a user tried to delete a tree in the explorer shell it would walk the entire tree to the leafs and start deleting stuff. What it should have done is deleted the mount point if the user had permission and done nothing outside the current volume if the user didn't have permission. > This is a VERY annoying problem. Yes it is and the correct way to get it fixed is to file bug reports with the application vendors. Asking the AFS redirector to break the rules only makes matters worse. > I wish AFS would prevent you from writing more into a volume than the q= uota size that you were allocated. In that case returning ENOSPC, 'No sp= ace left on device' should be applicable. The AFS file server does prevent you from writing more into a volume than the quota size and the AFS redirector queries the file server after each 1MB of data is written on a given file to update its estimates. But the AFS redirector cannot return an error on a WriteFile() request it has not yet been asked to perform. Whether or not the AFS redirector returns out of space errors is irrelevant. The applications that have issues are having issues because they are attempting to work around issues with other file systems by querying the free space or the volume attributes and are doing so incorrectly. The AFS redirector returns two errors: Out of space when the partition is full and out of quota when the volume quota is reached. Jeffrey Altman --------------ms020308000003020008010802 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhAl sq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc2MTA4NjMxMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChjpVdVk6XeKFff4To xGglVcP3FVY95LfwfBUKbQKppRYgfKBFW1RIEG+KXpc3IGOOTUX0Lg1xaukRwuoqv/pqRMNK JabXcr1RFuCFg9xfcmP5Z+65qQ+IRxYCKdcNfu3GdS7rMOY57+VLU7aZnnMgnt0oE42awze8 gYQSJsdjZKKZS9DBnzxJYfzqhIw7txoMdV7rwPAZm5yujsqI/eWuZPZ+qZ+8GTsnHJzZNvc6 KrDGU6aVfknM+qf92hXA2VXvmtf1B17BBbGX6Hgat71Ufw5oXFly6/Vt+e5mKIozXytw8qPX NllsG89ITVzn0OovcpcSRFBrXanzVn7JVj33AgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFMC1SMuRefXyNAwkZM+Lgu7iJ6nFMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHVBsY+l21fY0twxzNnO0QbadbRT4n7k3rYfOMbP noBDkYQx5lcrYn19f7e+ADMPdW/MY2ZjFM76aiRgiTo2IjMB7z4vyX6hfGJKTIHX9loDW0H2 z2o0jYqXDQtXx9A/gfMtVh9J+8O5IuCPsVtXgI4p6kRQHN+Er2Rzu1I4BILxE9HsDb/ruX6p NXZSUQ2AcMP87ZVfz+reumMpJgWWAoiQWJCgp+qZ2c2AG+yV+FstiMpxIj/qB9+BrFRuam8d IGbH0tIS2tyc7pgit8Pid2Zv7HGT2NFu69INsKIyqGImhMVuOUaCq/kNi3Z+6R5Hm3ljift8 ZF52Kiq4whe8KlcxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCECWyrbsULgHrdnyrUnPHH4IwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMDI3MDc0MTU3WjAjBgkqhkiG9w0BCQQxFgQURbeiFvQJJX3RXmaQ2KBApsAV0zswbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQJbKtuxQuAet2fKtSc8cfgjCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhAlsq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBAQUABIIB AC4cdGKPq8dcDBP5oTEmk0quBRtFDi5RP1Hle1O63Zqkq5c2OQm4q+r1oZH+k5plnm6Ox3yS a7WGyaOsdFiEkYH/dGpjDPfEwskUjWuhs4BeHgSyX2Ca6TBxtY5LxGtiGfo3OrErkTJQPVYG CMohND+EePeK1Pro/NOOJb5klLQFS7e9imZjGjmqoZTRzLuSZPOglt2s5P6fve0luiTp6nR2 kVUIqmVAArD5jpF09Yy3g4A09YN8iQ5yq84Mbh1ovwTA2hsMbROoMhIgLU1SR7rrF75b6Icb d731KBVuSN2mEr7p5S4CW056Gs4HmvfLXoN/3kzariRbvUodPLLkBNMAAAAAAAA= --------------ms020308000003020008010802-- From kendrick.hernandez@umbc.edu Mon Oct 28 15:32:44 2013 From: kendrick.hernandez@umbc.edu (Kendrick Hernandez) Date: Mon, 28 Oct 2013 10:32:44 -0400 Subject: [OpenAFS] Questions about 'vldb_check -fix' Message-ID: --089e0168147029e43d04e9cdf980 Content-Type: text/plain; charset=UTF-8 Hi, I have some notes left from a previous admin, that we have some vldb corruption that can be fixed by running 'vldb_check -fix'. My understanding is that we need to shut down the vlserver on our 3 db servers, and run this command on the lowest IP site, bring that up first, and then bring up the rest. In order to minimize downtime, I'd like to run vldb_check on an offline copy of the vldb, but I'm wondering if the vlserver needs to be completely shutdown prior to making the copy, or if read-only mode would be good enough? If yes, I would basically bring down the vlserver on two sites, leaving it running on the site with the lowest ip (which if I understand correctly would go into read-only mode at this point). Then I'd make a copy of vldb.db0, run 'vldb_check -fix' on the copy, hand-propagate that out to the remaining sites, and then bring down the vlserver on the lowest ip site just before moving the fixed copy into place. I could then bring up the vlserver on the lowest ip site, and the remaining sites. Does this sound reasonable? We're looking to migrate our db servers from 1.4 to 1.6 in the future, and if I can fix the vldb corruption this way, then I could copy the vldb (and other dbs) to the new servers and run 'vldb_check -fix' there, before finally switching over from the last old db server. k- -- : Kendrick Hernandez : UNIX Systems Administrator : UNIX Systems and Infrastructure : Division of Information Technology : University of Maryland, Baltimore County --089e0168147029e43d04e9cdf980 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

I have some = notes left from a previous admin, that we have some vldb corruption that ca= n be fixed by running 'vldb_check -fix'. My understanding is that w= e need to shut down the vlserver on our 3 db servers, and run this command = on the lowest IP site, bring that up first, and then bring up the rest.

In order to minimize downtime, I'd like to run vldb= _check on an offline copy of the vldb, but I'm wondering if the vlserve= r needs to be completely shutdown prior to making the copy, or if read-only= mode would be good enough? If yes, I would basically bring down the vlserv= er on two sites, leaving it running on the site with the lowest ip (which i= f I understand correctly would go into read-only mode at this point). Then = I'd make a copy of vldb.db0, run 'vldb_check -fix' on the copy,= hand-propagate that out to the remaining sites, and then bring down the vl= server on the lowest ip site just before moving the fixed copy into place. = I could then bring up the vlserver on the lowest ip site, and the remaining= sites.

Does this sound reasonable? We're looking to migrat= e our db servers from 1.4 to 1.6 in the future, and if I can fix the vldb c= orruption this way, then I could copy the vldb (and other dbs) to the new s= ervers and run 'vldb_check -fix' there, before finally switching ov= er from the last old db server.

--

: Kend= rick Hernandez
: UNIX Systems Administrator
: UNIX Systems and Infras= tructure
: Division of Information Technology
: University of Marylan= d, Baltimore County

--089e0168147029e43d04e9cdf980-- From adeason@sinenomine.net Mon Oct 28 17:25:37 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 28 Oct 2013 11:25:37 -0500 Subject: [OpenAFS] Re: Questions about 'vldb_check -fix' References: Message-ID: <20131028112537.56e36c10.adeason@sinenomine.net> On Mon, 28 Oct 2013 10:32:44 -0400 Kendrick Hernandez wrote: > In order to minimize downtime, I'd like to run vldb_check on an > offline copy of the vldb, but I'm wondering if the vlserver needs to > be completely shutdown prior to making the copy, or if read-only mode > would be good enough? This "read-only mode" (basically, "not having quorum") is about as safe as just shutting down the server processes, yes. The sync site will not immediately go into "read-only mode" until about a minute after the other two servers are sutdown, but I don't think you need to actually wait for that. If the other two servers are down, the sync site won't be able to commit any data, so the database should be unchanging so it should be "safe" for copying. However, neither this, nor shutting down the servers, is completely guaranteed to be safe. If the sync site is in the middle of committing data to the database when you do this, you will get a vldb.DB0 file that has some data partially written to it. There are some ways to deal with that, but I'm not sure if there's a completely robust solution for what you're talking about: If you SIGSTOP the process, copy both vldb.DB0 and vldb.DBSYS1 out, and then SIGCONT the process, that will give you enough information to reconstruct a valid database. The DBSYS1 file is a journal log, though, and I don't think we have any tooling to manually just replay the log into the DB0 file. (Maybe we should; that would solve this pretty easily, I think.) Without replying the log, though, you can just look at if the DBSYS1 log is "empty". If it is, the corresponding DB0 file is definitely fine, and you can just use that. If it's not, you can just throw away the recorded files and try again. But if the other two sites are shutdown, we may be in the middle of a write transaction that will not complete until we timeout, so it can be difficult to detect a false positive. The DBSYS1 file is "empty" I think if it's 64 bytes full of 0s; but there may be other ways it can appear "empty". Another way of getting a robust vldb.DB0 copy is using the propsed ubik_cp tool . I don't think that will work, though, if two of the sites are shutdown and we're in the middle of a write transaction. I could be wrong about that, though, I haven't tried. Also, all of this possible corruption is probably pretty rare. If you don't care so much about 100% guarantees and such, you can probably just copy the database twice, waiting a few seconds between each copy, and if they are the same, it's really likely that they're fine. That is especially true if two of the sites are shutdown, since we should have at most 1 in-progress write. > Then I'd make a copy of vldb.db0, run 'vldb_check -fix' on the copy, > hand-propagate that out to the remaining sites, and then bring down > the vlserver on the lowest ip site just before moving the fixed copy > into place. I could then bring up the vlserver on the lowest ip site, > and the remaining sites. If 'vldb_check -fix' bumps the database version number, you would be able to just install the new db on one site and let them synchronize themselves. I don't think it does that (yet), so yeah, you should hand-propagate the files. That's faster, anyway. -- Andrew Deason adeason@sinenomine.net From giovanni.ponti@enea.it Thu Oct 24 08:31:35 2013 From: giovanni.ponti@enea.it (Giovanni Ponti) Date: Thu, 24 Oct 2013 09:31:35 +0200 Subject: [OpenAFS] Livesys command missing in rpm openafs-client Message-ID: <5268CCD7.80101@enea.it> Hello, I have a machine running CentoOS 5.3 x86_64, kernel 2.6.18-194.26.1.el5. I installed the latest rpm of the openafs-client (Version 1.6.5, Release 1el5). I tried to execute the "livesys" command, but the system does not find it. Notice that the same command is correctly found on a machine running Linux Mint 13 LTS x86_64, kernel 3.2.0-23, with the repository deb package of openafs-client, version 1.6.1. How is it possible? Thank & regards, Giovanni Ponti -- Giovanni Ponti, PhD UTICT-HPC ENEA - C.R. Portici P.le E. Fermi, 1 (Loc. Granatello) 80055 Portici (NA), Italy phone : (+39) 081-7723564 | int.: [89] 2564 fax : (+39) 081-7723344 email : giovanni.ponti@enea.it web : http://www.afs.enea.it/gponti From rmdyer@uncc.edu Tue Oct 29 22:19:48 2013 From: rmdyer@uncc.edu (Dyer, Rodney) Date: Tue, 29 Oct 2013 21:19:48 +0000 Subject: [OpenAFS] not enough space in target directory In-Reply-To: <526CC3C5.6020004@your-file-system.com> References: <524F4305.4030102@googlemail.com> <524F5AD5.2070006@your-file-system.com> <52633F5E.7090501@your-file-system.com> <18B8F39B03C7B445B4C3B97D55D4555B1333A396@RPITSEXMS3.its.uncc.edu> <526CC3C5.6020004@your-file-system.com> Message-ID: <18B8F39B03C7B445B4C3B97D55D4555B1333B142@RPITSEXMS3.its.uncc.edu> PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvcGVuYWZzLWluZm8tYWRtaW5A b3BlbmFmcy5vcmcgW21haWx0bzpvcGVuYWZzLWluZm8tDQo+IGFkbWluQG9wZW5hZnMub3JnXSBP biBCZWhhbGYgT2YgSmVmZnJleSBBbHRtYW4NCj4gU2VudDogU3VuZGF5LCBPY3RvYmVyIDI3LCAy MDEzIDM6NDIgQU0NCj4gVG86IG9wZW5hZnMtaW5mb0BvcGVuYWZzLm9yZw0KPiBTdWJqZWN0OiBS ZTogW09wZW5BRlNdIG5vdCBlbm91Z2ggc3BhY2UgaW4gdGFyZ2V0IGRpcmVjdG9yeQ0KPiANCj4g T24gMTAvMjIvMjAxMyAxMjoxOCBQTSwgRHllciwgUm9kbmV5IHdyb3RlOg0KPiA+DQo+ID4gKE5v dGU6IEluIG15IGhpc3RvcnkgYXMgYSBwcm9ncmFtbWVyLCB3ZSB3b3VsZCBqdXN0IG9wZW4gdGhl IGZpbGUgZm9yDQo+ICd3cml0ZScgYW5kIGtlZXAgd3JpdGluZyB1bnRpbCB3ZSBydW4gb3V0IG9m IHNwYWNlIHdpdGggYSAnb3V0IG9mIHNwYWNlJyBlcnJvcg0KPiBvY2N1cnMgZnJvbSB0aGUgJ0Mn IGNhbGxzLiAgSSB0aGluayB0aGUgZXJyb3Igd2FzIEVOT1NQQywgJ05vIHNwYWNlIGxlZnQgb24N Cj4gZGV2aWNlJy4gKQ0KPiANCj4gSSBoYXZlIGp1c3QgZXhwbGFpbmVkIHRoZSBwcm9ibGVtIHdp dGggdGhpcyBhcHByb2FjaC4NCg0KV2UgaGF2ZSBhIHByb2JsZW0gdGhlbiwgYXMgdGhlcmUgaXMg bm8gd2F5IHRoYXQgSSBrbm93IG9mIHRvIGNoZWNrIHdoYXQgc3BhY2UgaXMgbGVmdCBvbiB0aGUg ZGV2aWNlIGZpcnN0LCB0aGVuIGJlZ2luIHdyaXRpbmcgd2l0aCBhIGxvY2sgb24gdGhlIGZyZWUg c3BhY2UgeW91IHdhbnQuICBCZXR3ZWVuIHRoZSB0aW1lIHRoYXQgeW91J3ZlIGNoZWNrZWQgdGhl IGZyZWUgc3BhY2UsIGFuZCB5b3UgYmVnaW4gd3JpdGluZywgeW91IG1heSBoYXZlIGxvc3QgdGhl IHNwYWNlIHRvIGFub3RoZXIgdXNlci4gIFRvIHNvbHZlIHRoaXMgcHJvYmxlbSB5b3Ugd291bGQg bmVlZCB0byB0cnkgYW5kIGFsbG9jYXRlIGFsbCB0aGUgc3BhY2UgbmVlZGVkIGZpcnN0LCB0aGVu IHdyaXRlIGludG8gaXQuDQogDQo+IA0KPiA+IElmIHlvdSBkb24ndCBjYXJlIGFib3V0IGxvc2lu ZyBkYXRhLCBvbmUgc29sdXRpb24gaXMgdG8gJ3N5bWxpbmsnIHRoZSBjZWxsIGludG8NCj4gdGhl IEM6IGRyaXZlLCBhcyBmb2xsb3dzLi4uDQo+ID4NCj4gPiAgICAgIEM6XD5ta2xpbmsgL2QgYzpc YWZzIFxcYWZzXHJvb3QuYWZzDQo+ID4NCj4gPiAgICAgIEEgRElSIG9mIGM6XCB3aWxsIHRoZW4g cmV0dXJuIHdoYXQgaXMgYXZhaWxhYmxlIG9uIHlvdXIgQzogZHJpdmUuDQo+IA0KPiBXaGljaCBp cyBncmVhdCB1bnRpbCB0aGUgZnJlZSBzcGFjZSBvbiB0aGUgQzogZHJpdmUgZHJvcHMgdG8gbm90 aGluZw0KPiBiZWNhdXNlIG9mIHNoYWRvdyB2b2x1bWUgc25hcHNob3RzLCBwYWdlZmlsZSBpbmNy ZWFzZXMsIG9yIG90aGVyDQo+IHJlYXNvbnMuICAgQ3VycmVudCBmcmVlIHNwYWNlIG9uIG15IEM6 IGRpc2suDQo+IA0KPiAgICAgICAgICA2MTgsMTEyIGJ5dGVzIGZyZWUNCj4gICAgICAgICAgICAg ICA5OS45ICUgaW4gdXNlDQo+IA0KPiBJdCB3YXMgNUdCIGZyZWUgYWJvdXQgMTIgaG91cnMgYWdv LiAgRHVyaW5nIGRpc2sgYmFja3VwcyB0aGUgdm9sdW1lDQo+IGNoZWNrcG9pbnQgYW5kIE5URlMg am91cm5hbCB1c2VzIHVwIGFsbCBvZiB0aGUgZnJlZSBzcGFjZS4NCj4gDQo+IEFsbCB5b3UgYXJl IGRvaW5nIGlzIHRyYWRpbmcgb25lIHByb2JsZW0gZm9yIGFub3RoZXIuDQoNClRoYXQgd2FzIG5v dCByZWFsbHkgdGhlIHBvaW50LiAgVGhpcyB3YXMgc2ltcGx5IGFuIGFsdGVybmF0aXZlIHRvIHNv bWVvbmUgd2FudGluZyB0byBkZWxpYmVyYXRlbHkgbGl2ZSBsaWZlIGluIHRoZSBlZGdlICh3aXRo IHBvc3NpYmxlIGZhaWx1cmUpLg0KWW91IGNvdWxkIGFsd2F5cyB1c2UgYSBzcGFyZSBkcml2ZSwg b3IgcGFydGl0aW9uIHdoZXJlIHlvdSBuZXZlciB3cm90ZSBmaWxlcyBpbiB0byBzeW1saW5rIEFG Uy4NCg0KPiA+IFRoaXMgaXMgYSBWRVJZIGFubm95aW5nIHByb2JsZW0uDQo+IA0KPiBZZXMgaXQg aXMgYW5kIHRoZSBjb3JyZWN0IHdheSB0byBnZXQgaXQgZml4ZWQgaXMgdG8gZmlsZSBidWcgcmVw b3J0cw0KPiB3aXRoIHRoZSBhcHBsaWNhdGlvbiB2ZW5kb3JzLiAgQXNraW5nIHRoZSBBRlMgcmVk aXJlY3RvciB0byBicmVhayB0aGUNCj4gcnVsZXMgb25seSBtYWtlcyBtYXR0ZXJzIHdvcnNlLg0K DQpTbyB5b3UgbXVzdCBiZSBzYXlpbmcgdGhpcyBwcm9ibGVtIGlzIGFsc28gcHJldmFsZW50IHdp dGggb3RoZXIgZmlsZSBzeXN0ZW1zIHN1Y2ggYXMgdGhvc2UgdGhhdCByZXByZXNlbnQgdGhlbXNl bHZlcyBhcyBDSUZTIGxpa2UgTmV0QXBwLCBhbmQgZXZlbiBNaWNyb3NvZnQncyBvd24gREZTPw0K DQo+IA0KPiA+IEkgd2lzaCBBRlMgd291bGQgcHJldmVudCB5b3UgZnJvbSB3cml0aW5nIG1vcmUg aW50byBhIHZvbHVtZSB0aGFuIHRoZQ0KPiBxdW90YSBzaXplIHRoYXQgeW91IHdlcmUgYWxsb2Nh dGVkLiAgSW4gdGhhdCBjYXNlIHJldHVybmluZyBFTk9TUEMsICdObyBzcGFjZQ0KPiBsZWZ0IG9u IGRldmljZScgc2hvdWxkIGJlIGFwcGxpY2FibGUuDQo+IA0KPiBUaGUgQUZTIGZpbGUgc2VydmVy IGRvZXMgcHJldmVudCB5b3UgZnJvbSB3cml0aW5nIG1vcmUgaW50byBhIHZvbHVtZQ0KPiB0aGFu IHRoZSBxdW90YSBzaXplIGFuZCB0aGUgQUZTIHJlZGlyZWN0b3IgcXVlcmllcyB0aGUgZmlsZSBz ZXJ2ZXIgYWZ0ZXINCj4gZWFjaCAxTUIgb2YgZGF0YSBpcyB3cml0dGVuIG9uIGEgZ2l2ZW4gZmls ZSB0byB1cGRhdGUgaXRzIGVzdGltYXRlcy4NCj4gQnV0IHRoZSBBRlMgcmVkaXJlY3RvciBjYW5u b3QgcmV0dXJuIGFuIGVycm9yIG9uIGEgV3JpdGVGaWxlKCkgcmVxdWVzdA0KPiBpdCBoYXMgbm90 IHlldCBiZWVuIGFza2VkIHRvIHBlcmZvcm0uDQo+IA0KPiBXaGV0aGVyIG9yIG5vdCB0aGUgQUZT IHJlZGlyZWN0b3IgcmV0dXJucyBvdXQgb2Ygc3BhY2UgZXJyb3JzIGlzDQo+IGlycmVsZXZhbnQu ICBUaGUgYXBwbGljYXRpb25zIHRoYXQgaGF2ZSBpc3N1ZXMgYXJlIGhhdmluZyBpc3N1ZXMgYmVj YXVzZQ0KPiB0aGV5IGFyZSBhdHRlbXB0aW5nIHRvIHdvcmsgYXJvdW5kIGlzc3VlcyB3aXRoIG90 aGVyIGZpbGUgc3lzdGVtcyBieQ0KPiBxdWVyeWluZyB0aGUgZnJlZSBzcGFjZSBvciB0aGUgdm9s dW1lIGF0dHJpYnV0ZXMgYW5kIGFyZSBkb2luZyBzbw0KPiBpbmNvcnJlY3RseS4NCg0KVGhhdCdz IGNlcnRhaW5seSBhIGh1Z2UgbGlzdCBvZiB2ZW5kb3JzLCBhbmQgcHJvZ3JhbW1lcnMgZXZlcnl3 aGVyZS4gIEkgZG9uJ3Qga25vdyBhbnkgZ3JhZHVhdGVzIHdobyBnZXQgdHJhaW5lZCBpbiBzdWNo IG9ic2N1cmUgZmlsZSBzeXN0ZW0gbGV2ZWwgaW5mb3JtYXRpb24uDQoNClJvZG5leQ0KDQo= From adeason@sinenomine.net Tue Oct 29 23:52:00 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Tue, 29 Oct 2013 17:52:00 -0500 Subject: [OpenAFS] Re: Livesys command missing in rpm openafs-client References: <5268CCD7.80101@enea.it> Message-ID: <20131029175200.775ce8cd.adeason@sinenomine.net> On Thu, 24 Oct 2013 09:31:35 +0200 Giovanni Ponti wrote: > I have a machine running CentoOS 5.3 x86_64, kernel > 2.6.18-194.26.1.el5. I installed the latest rpm of the openafs-client > (Version 1.6.5, Release 1el5). > > I tried to execute the "livesys" command, but the system does not find > it. > > Notice that the same command is correctly found on a machine running > Linux Mint 13 LTS x86_64, kernel 3.2.0-23, with the repository deb > package of openafs-client, version 1.6.1. > > How is it possible? The RPMs don't package the "livesys" command. I don't know why, but it looks like they've been like that for a long time, and the packaging does do that deliberately. Perhaps it should be included, but I'll let someone else provide a reason for this if there is one. If it helps, you can get basically the same information from 'fs sysname', with a little bit more string parsing. -- Andrew Deason adeason@sinenomine.net From ktdreyer@ktdreyer.com Wed Oct 30 00:04:54 2013 From: ktdreyer@ktdreyer.com (Ken Dreyer) Date: Tue, 29 Oct 2013 17:04:54 -0600 Subject: [OpenAFS] Re: Livesys command missing in rpm openafs-client In-Reply-To: <20131029175200.775ce8cd.adeason@sinenomine.net> References: <5268CCD7.80101@enea.it> <20131029175200.775ce8cd.adeason@sinenomine.net> Message-ID: On Tue, Oct 29, 2013 at 4:52 PM, Andrew Deason wrote: > The RPMs don't package the "livesys" command. I don't know why, but it > looks like they've been like that for a long time, and the packaging > does do that deliberately. Perhaps it should be included, but I'll let > someone else provide a reason for this if there is one. This looks like a bug to me. - Ken From jaltman@your-file-system.com Wed Oct 30 03:44:46 2013 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Tue, 29 Oct 2013 22:44:46 -0400 Subject: [OpenAFS] not enough space in target directory In-Reply-To: <18B8F39B03C7B445B4C3B97D55D4555B1333B142@RPITSEXMS3.its.uncc.edu> References: <524F4305.4030102@googlemail.com> <524F5AD5.2070006@your-file-system.com> <52633F5E.7090501@your-file-system.com> <18B8F39B03C7B445B4C3B97D55D4555B1333A396@RPITSEXMS3.its.uncc.edu> <526CC3C5.6020004@your-file-system.com> <18B8F39B03C7B445B4C3B97D55D4555B1333B142@RPITSEXMS3.its.uncc.edu> Message-ID: <5270729E.7060109@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms040807050206030709040500 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/29/2013 5:19 PM, Dyer, Rodney wrote: > We have a problem then, as there is no way that I know of to check what= space is left on the device first, then begin writing with a lock on the= free space you want. Between the time that you've checked the free spa= ce, and you begin writing, you may have lost the space to another user. This is why the AFS file server allows a user to go over quota by a small amount before it begins failing writes. > To solve this problem you would need to try and allocate all the space needed first, then write into it. This is a very common pattern for exactly this reason. Especially for file copies. The target file is opened, the file size is allocated and then the data is written into the target location. The Win32 API calls are: CreateFile to create the file SetFilePointerEx to advance the file pointer to the size to allocate SetEndOfFile to commit that size to disk --------------ms040807050206030709040500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhAl sq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc2MTA4NjMxMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChjpVdVk6XeKFff4To xGglVcP3FVY95LfwfBUKbQKppRYgfKBFW1RIEG+KXpc3IGOOTUX0Lg1xaukRwuoqv/pqRMNK JabXcr1RFuCFg9xfcmP5Z+65qQ+IRxYCKdcNfu3GdS7rMOY57+VLU7aZnnMgnt0oE42awze8 gYQSJsdjZKKZS9DBnzxJYfzqhIw7txoMdV7rwPAZm5yujsqI/eWuZPZ+qZ+8GTsnHJzZNvc6 KrDGU6aVfknM+qf92hXA2VXvmtf1B17BBbGX6Hgat71Ufw5oXFly6/Vt+e5mKIozXytw8qPX NllsG89ITVzn0OovcpcSRFBrXanzVn7JVj33AgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFMC1SMuRefXyNAwkZM+Lgu7iJ6nFMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHVBsY+l21fY0twxzNnO0QbadbRT4n7k3rYfOMbP noBDkYQx5lcrYn19f7e+ADMPdW/MY2ZjFM76aiRgiTo2IjMB7z4vyX6hfGJKTIHX9loDW0H2 z2o0jYqXDQtXx9A/gfMtVh9J+8O5IuCPsVtXgI4p6kRQHN+Er2Rzu1I4BILxE9HsDb/ruX6p NXZSUQ2AcMP87ZVfz+reumMpJgWWAoiQWJCgp+qZ2c2AG+yV+FstiMpxIj/qB9+BrFRuam8d IGbH0tIS2tyc7pgit8Pid2Zv7HGT2NFu69INsKIyqGImhMVuOUaCq/kNi3Z+6R5Hm3ljift8 ZF52Kiq4whe8KlcxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCECWyrbsULgHrdnyrUnPHH4IwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMDMwMDI0NDQ2WjAjBgkqhkiG9w0BCQQxFgQU50xZv5NqG4H6y/ocDS5iF8Q5HqAwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQJbKtuxQuAet2fKtSc8cfgjCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhAlsq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBAQUABIIB AGZ+iS4yRmKACXCu6A3hD4SPlW5yC7q9OyiqPuFPn466EuqfMU1gMhdYKU0p4zpNtmpQQSGp YvU0up3w9lBl/pD60pdLpv/glEfY3lms7PK/9FmID44tHOG/+Dd30fvaRA6WnTha5dxAUigG kT4ec7K1RdAxq+cW+8PC11pFVpzNUcjU3J2BlOqGPZPCJnQatP7lhsJNF3sNIZ61au0ftylY 5qUX7BzlvPPAKQBJ5hJXu1P+4lXGwbXLgkq8PlWQZB9aK1dgS2ISmNiCa076DHYib6U4Iz4v 7yYiimp5xiV28KGDHUcvt80EcuomS70wT6jWN6/hYLNMxZ1VJcR0ZIQAAAAAAAA= --------------ms040807050206030709040500-- From hcaldwell@usgs.gov Wed Oct 30 23:08:57 2013 From: hcaldwell@usgs.gov (Hugh Caldwell) Date: Wed, 30 Oct 2013 18:08:57 -0400 Subject: [OpenAFS] "Bug" in fs setquota Message-ID: <7e6046a5ff18d119a8fad31d0ed98231@mail.gmail.com> --e89a8ff1c99e7affce04e9fc9473 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Hi, When trying to increase the quota on a volume I accidentally entered a negative value after the =96max flag. This ended up deleting all the conten= ts of the directory. I don=92t know if this is technically a bug but it=92s a feature I could do without. :D The command I ran was Fs setquota =96p \\afs\rest_of _path -max -50000 Thanks, Hugh Caldwell NetServices, LLC EWeb Systems Administrator United States Geological Survey 703-648-6812 (Office) 703-598-3472 (Cellular) hcaldwell@usgs.gov Room 2C123B --e89a8ff1c99e7affce04e9fc9473 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable

Hi,

=A0

When trying to increase the quota on a volum= e I accidentally entered a negative value after the =96max flag. This ended= up deleting all the contents of the directory. I don=92t know if this is t= echnically a bug but it=92s a feature I could do without. :D

=A0

The command I ran was<= /p>

Fs setquota =96p =A0\\afs\rest_of _path -max -50000

=A0

Thanks,

=A0

Hugh Caldwell
NetServices, LLC<= br>EWeb Systems Administrator
United States Geological Survey
703-648-6812 (Office)
703-598-3472 = (Cellular)
hcaldwell@usgs.gov<= br>Room 2C123B

=A0

--e89a8ff1c99e7affce04e9fc9473-- From jaltman@your-file-system.com Thu Oct 31 03:55:09 2013 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Wed, 30 Oct 2013 22:55:09 -0400 Subject: [OpenAFS] "Bug" in fs setquota In-Reply-To: <7e6046a5ff18d119a8fad31d0ed98231@mail.gmail.com> References: <7e6046a5ff18d119a8fad31d0ed98231@mail.gmail.com> Message-ID: <5271C68D.6060100@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms050209060105070203060003 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I can imagine how this would result in Windows believing that the entire volume had nothing to show but I don't see how this command would result in the data for a single directory being deleted from the file server. A quota adjustment should not result in the removal of any data. How would the file server know what to discard? I suspect the data is still on the file server and it just needs a new quota to be set. Perhaps by using a vos command instead of an fs command= =2E On 10/30/2013 6:08 PM, Hugh Caldwell wrote: > Hi, >=20 > =20 >=20 > When trying to increase the quota on a volume I accidentally entered a > negative value after the =E2=80=93max flag. This ended up deleting all = the > contents of the directory. I don=E2=80=99t know if this is technically = a bug but > it=E2=80=99s a feature I could do without. :D >=20 > =20 >=20 > The command I ran was >=20 > Fs setquota =E2=80=93p \\afs\rest_of _path -max -50000 > >=20 > =20 >=20 > Thanks, >=20 > =20 >=20 > Hugh Caldwell > NetServices, LLC > EWeb Systems Administrator > United States Geological Survey > 703-648-6812 (Office) > 703-598-3472 (Cellular) > hcaldwell@usgs.gov > Room 2C123B >=20 > =20 >=20 --------------ms050209060105070203060003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhAl sq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc2MTA4NjMxMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChjpVdVk6XeKFff4To xGglVcP3FVY95LfwfBUKbQKppRYgfKBFW1RIEG+KXpc3IGOOTUX0Lg1xaukRwuoqv/pqRMNK JabXcr1RFuCFg9xfcmP5Z+65qQ+IRxYCKdcNfu3GdS7rMOY57+VLU7aZnnMgnt0oE42awze8 gYQSJsdjZKKZS9DBnzxJYfzqhIw7txoMdV7rwPAZm5yujsqI/eWuZPZ+qZ+8GTsnHJzZNvc6 KrDGU6aVfknM+qf92hXA2VXvmtf1B17BBbGX6Hgat71Ufw5oXFly6/Vt+e5mKIozXytw8qPX NllsG89ITVzn0OovcpcSRFBrXanzVn7JVj33AgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFMC1SMuRefXyNAwkZM+Lgu7iJ6nFMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHVBsY+l21fY0twxzNnO0QbadbRT4n7k3rYfOMbP noBDkYQx5lcrYn19f7e+ADMPdW/MY2ZjFM76aiRgiTo2IjMB7z4vyX6hfGJKTIHX9loDW0H2 z2o0jYqXDQtXx9A/gfMtVh9J+8O5IuCPsVtXgI4p6kRQHN+Er2Rzu1I4BILxE9HsDb/ruX6p NXZSUQ2AcMP87ZVfz+reumMpJgWWAoiQWJCgp+qZ2c2AG+yV+FstiMpxIj/qB9+BrFRuam8d IGbH0tIS2tyc7pgit8Pid2Zv7HGT2NFu69INsKIyqGImhMVuOUaCq/kNi3Z+6R5Hm3ljift8 ZF52Kiq4whe8KlcxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCECWyrbsULgHrdnyrUnPHH4IwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMDMxMDI1NTA5WjAjBgkqhkiG9w0BCQQxFgQUHfUpacqrwTvHU2S8HyYU2DOZwsYwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQJbKtuxQuAet2fKtSc8cfgjCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhAlsq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBAQUABIIB AG8Ry7hyEhOHOb2OuSTk5VCbZEAEm73O+ga+3E5UjxFiY26r8Wzg5PpzmXWGRYg3GCKD4BBO vTNVpvwHS8tv+wlAks//BhGULlAdMHJxXv4Zo1PLPKjfai8IW7GZl/sSy1Q+8nFy5atMr2Hd defBTCRZ8eXiMVlcZ/aT81WjeTfy8q3BBC047TAkJDC39D+FOgZCQbm92Mw8UK4M8IoDTj2p 7H4oJSHSpXvWx2PDkpfO5AXER1hPiPY4UV8+Ka9sV87uKaoqR71u4o7eqljudqNlR9o3r7Xb 8gy+R0JsqEb+MmhqKOd4237mm6uYuxBGPuhxb9tDrBS/rbABwTTIH8UAAAAAAAA= --------------ms050209060105070203060003--