From David.Bear@asu.edu Wed Oct 1 02:07:19 2008 From: David.Bear@asu.edu (David Bear) Date: Tue, 30 Sep 2008 18:07:19 -0700 Subject: [OpenAFS] error installing open from repository with yum Message-ID: <1d1a54bf0809301807l66695116h545b3f7998ead483@mail.gmail.com> ------=_Part_36062_4340183.1222823239036 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sorry to bug -- but I am lost attempting to use yum to install openafs. I am using RHEL 5.2. I grabbed the latest maint repository of openafs with wget http://openafs.org/dl/openafs/1.4.7/openafs-repository-rhel-1.4.7-2.noarch.rpm Then installed it: rpm -i openafs-repository-rhel-1.4.7-2.noarch.rpm But when I attempt to install it yum install openafs-client Loading "rhnplugin" plugin Loading "security" plugin http://dl.openafs.org/dl/openafs/1.4.7/rhel-5Server/i386/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: openafs. Please verify its path and try again Is there an error in the repo file ? or did I grab the wrong repository? -- David Bear College of Public Programs at ASU 602-464-0424 ------=_Part_36062_4340183.1222823239036 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Sorry to bug -- but I am lost attempting to use yum to install openafs.

I am using RHEL 5.2.

I grabbed  the latest maint repository of openafs with
wget http://openafs.org/dl/openafs/1.4.7/openafs-repository-rhel-1.4.7-2.noarch.rpm

Then installed it:
rpm -i openafs-repository-rhel-1.4.7-2.noarch.rpm

But when I attempt to install it
yum install openafs-client
Loading "rhnplugin" plugin
Loading "security" plugin
http://dl.openafs.org/dl/openafs/1.4.7/rhel-5Server/i386/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
Error: Cannot retrieve repository metadata (repomd.xml) for repository: openafs. Please verify its path and try again

Is there an error in the repo file ? or did I grab the wrong repository?

--
David Bear
College of Public Programs at ASU
602-464-0424
------=_Part_36062_4340183.1222823239036-- From todd_taft@unc.edu Wed Oct 1 04:30:40 2008 From: todd_taft@unc.edu (Todd D. Taft) Date: Tue, 30 Sep 2008 23:30:40 -0400 Subject: [OpenAFS] error installing open from repository with yum In-Reply-To: <1d1a54bf0809301807l66695116h545b3f7998ead483@mail.gmail.com> References: <1d1a54bf0809301807l66695116h545b3f7998ead483@mail.gmail.com> Message-ID: <48E2EEE0.7020800@unc.edu> I think it's an error in the repo. I tried to do the same thing several days ago. I've opened a bug report on this issue. [grand.central.org #118071] I changed the first baseurl entry in /etc/yum.repos.d/openafs to: baseurl=http://dl.openafs.org/dl/openafs/1.4.7/rhel5/$basearch/ That seemed to work. The only problem is that they don't yet have a pre-built kernel module available for the kernel that Red Hat released at the end of last week. --Todd David Bear wrote: > Sorry to bug -- but I am lost attempting to use yum to install openafs. > > I am using RHEL 5.2. > > I grabbed the latest maint repository of openafs with > wget > http://openafs.org/dl/openafs/1.4.7/openafs-repository-rhel-1.4.7-2.noarch.rpm > > Then installed it: > rpm -i openafs-repository-rhel-1.4.7-2.noarch.rpm > > But when I attempt to install it > yum install openafs-client > Loading "rhnplugin" plugin > Loading "security" plugin > http://dl.openafs.org/dl/openafs/1.4.7/rhel-5Server/i386/repodata/repomd.xml: > [Errno 14] HTTP Error 404: Not Found > Trying other mirror. > Error: Cannot retrieve repository metadata (repomd.xml) for repository: > openafs. Please verify its path and try again > > Is there an error in the repo file ? or did I grab the wrong repository? > > -- > David Bear > College of Public Programs at ASU > 602-464-0424 -- Todd D. Taft todd_taft@unc.edu From sxw@inf.ed.ac.uk Wed Oct 1 08:11:38 2008 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Wed, 1 Oct 2008 08:11:38 +0100 Subject: [OpenAFS] error installing open from repository with yum In-Reply-To: <1d1a54bf0809301807l66695116h545b3f7998ead483@mail.gmail.com> References: <1d1a54bf0809301807l66695116h545b3f7998ead483@mail.gmail.com> Message-ID: <634C1B3E-03E4-471B-8280-A2B8B5BA343A@inf.ed.ac.uk> On 1 Oct 2008, at 02:07, David Bear wrote: > > http://dl.openafs.org/dl/openafs/1.4.7/rhel-5Server/i386/repodata/repomd.xml > : [Errno 14] HTTP Error 404: Not Found Hmmm. Your $release field seems to get set to '5Server', rather than '5'. The solution here is either for Derrick to create some more symlinks, or for you to edit the file (/etc/yum.repo.d/openafs.repo), and replace $release with a hardcoded value. More symlinks is a better option. S. From sxw@inf.ed.ac.uk Wed Oct 1 08:12:33 2008 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Wed, 1 Oct 2008 08:12:33 +0100 Subject: [OpenAFS] error installing open from repository with yum In-Reply-To: <48E2EEE0.7020800@unc.edu> References: <1d1a54bf0809301807l66695116h545b3f7998ead483@mail.gmail.com> <48E2EEE0.7020800@unc.edu> Message-ID: On 1 Oct 2008, at 04:30, Todd D. Taft wrote: > That seemed to work. The only problem is that they don't yet have a > pre-built kernel module available for the kernel that Red Hat > released at the end of last week. It's just been built (the build system had a hiccup), and should get copied over at some point soon. S. From geza@kzsdabas.hu Wed Oct 1 19:08:45 2008 From: geza@kzsdabas.hu (=?ISO-8859-1?Q?G=E9mes_G=E9za?=) Date: Wed, 01 Oct 2008 20:08:45 +0200 Subject: [OpenAFS] Re: How do you resolve the problem with DES In-Reply-To: <14128578.1207371222868930090.JavaMail.nabble@isper.nabble.com> References: <14128578.1207371222868930090.JavaMail.nabble@isper.nabble.com> Message-ID: <48E3BCAD.80603@kzsdabas.hu> This is a multi-part message in MIME format. --------------090506030608030403090901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit pentruinregistrare@gmail.com írta: > I install libssl-dev 0.9.8c-4etch3, libopenafs-dev 1.4.2-6etch1 and try compile samba-3.2.4 after configure --with-fake-kaserver --with-vfs-afsacl but in "make" process I received that: > > "lib/afs.o: In function `afs_createtoken': > afs.c:(.text+0x2b7): undefined reference to `DES_key_sched' > afs.c:(.text+0x2e9): undefined reference to `DES_pcbc_encrypt' > collect2: ld returned 1 exit status > make: *** [bin/smbd] Error 1" > > Witch file or files exactly I must modify to correct that problem? > Thanks in advance > > > Apply the attached patch, it is bug id 5799 in samba bugzilla. But please note, that while it fixes the compile problem, it doesn't make the fake-kaserver part functional :-( (yet ), because in source/lib/afs_settoken.c there is a deprecated openafs syscall, now I try to figure out how could I rewrite it. Cheers Geza --------------090506030608030403090901 Content-Type: text/x-patch; name="afs.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="afs.patch" diff -urN samba-3.2.3.orig/source/configure samba-3.2.3/source/configure --- samba-3.2.3.orig/source/configure 2008-09-26 21:01:25.120601000 +0200 +++ samba-3.2.3/source/configure 2008-09-26 21:10:56.595590574 +0200 @@ -53356,12 +53356,82 @@ if test x"$samba_cv_WITH_AFS" != x"no" || test x"$samba_cv_WITH_FAKE_KASERVER" != x"no"; then + { echo "$as_me:$LINENO: checking for DES_pcbc_encrypt in -lcrypto" >&5 +echo $ECHO_N "checking for DES_pcbc_encrypt in -lcrypto... $ECHO_C" >&6; } +if test "${ac_cv_lib_crypto_DES_pcbc_encrypt+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + ac_check_lib_save_LIBS=$LIBS +LIBS="-lcrypto $LIBS" +cat >conftest.$ac_ext <<_ACEOF +/* confdefs.h. */ +_ACEOF +cat confdefs.h >>conftest.$ac_ext +cat >>conftest.$ac_ext <<_ACEOF +/* end confdefs.h. */ + +/* Override any GCC internal prototype to avoid an error. + Use char because int might match the return type of a GCC + builtin and then its argument prototype would still apply. */ +#ifdef __cplusplus +extern "C" +#endif +char DES_pcbc_encrypt (); +int +main () +{ +return DES_pcbc_encrypt (); + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext conftest$ac_exeext +if { (ac_try="$ac_link" +case "(($ac_try" in + *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;; + *) ac_try_echo=$ac_try;; +esac +eval "echo \"\$as_me:$LINENO: $ac_try_echo\"") >&5 + (eval "$ac_link") 2>conftest.er1 + ac_status=$? + grep -v '^ *+' conftest.er1 >conftest.err + rm -f conftest.er1 + cat conftest.err >&5 + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && { + test -z "$ac_c_werror_flag" || + test ! -s conftest.err + } && test -s conftest$ac_exeext && + $as_test_x conftest$ac_exeext; then + ac_cv_lib_crypto_DES_pcbc_encrypt=yes +else + echo "$as_me: failed program was:" >&5 +sed 's/^/| /' conftest.$ac_ext >&5 + + ac_cv_lib_crypto_DES_pcbc_encrypt=no +fi + +rm -f core conftest.err conftest.$ac_objext conftest_ipa8_conftest.oo \ + conftest$ac_exeext conftest.$ac_ext +LIBS=$ac_check_lib_save_LIBS +fi +{ echo "$as_me:$LINENO: result: $ac_cv_lib_crypto_DES_pcbc_encrypt" >&5 +echo "${ECHO_T}$ac_cv_lib_crypto_DES_pcbc_encrypt" >&6; } +if test $ac_cv_lib_crypto_DES_pcbc_encrypt = yes; then + LIBS="$LIBS -lcrypto" +fi + + # see if this box has the afs-headers in /usr/include/afs { echo "$as_me:$LINENO: checking for /usr/include/afs" >&5 echo $ECHO_N "checking for /usr/include/afs... $ECHO_C" >&6; } if test -d /usr/include/afs; then - CFLAGS="$CFLAGS -I/usr/include/afs" - CPPFLAGS="$CPPFLAGS -I/usr/include/afs" + mkdir -p ./include/afs + for f in afs.h auth.h param.h prs_fs.h stds.h venus.h ; do + cp -a /usr/include/afs/$f ./iclude/afs/ + done + CFLAGS="$CFLAGS -Iinclude/afs" + CPPFLAGS="$CPPFLAGS -Iinclude/afs" { echo "$as_me:$LINENO: result: yes" >&5 echo "${ECHO_T}yes" >&6; } else diff -urN samba-3.2.3.orig/source/configure.in samba-3.2.3/source/configure.in --- samba-3.2.3.orig/source/configure.in 2008-09-26 21:01:27.208591000 +0200 +++ samba-3.2.3/source/configure.in 2008-09-26 21:10:07.023786290 +0200 @@ -2834,11 +2834,17 @@ if test x"$samba_cv_WITH_AFS" != x"no" || test x"$samba_cv_WITH_FAKE_KASERVER" != x"no"; then + AC_CHECK_LIB( crypto, DES_pcbc_encrypt, LIBS="$LIBS -lcrypto" ) + # see if this box has the afs-headers in /usr/include/afs AC_MSG_CHECKING(for /usr/include/afs) if test -d /usr/include/afs; then - CFLAGS="$CFLAGS -I/usr/include/afs" - CPPFLAGS="$CPPFLAGS -I/usr/include/afs" + mkdir -p ./include/afs + for f in afs.h auth.h param.h prs_fs.h stds.h venus.h ; do + cp -a /usr/include/afs/$f ./iclude/afs/ + done + CFLAGS="$CFLAGS -Iinclude/afs" + CPPFLAGS="$CPPFLAGS -Iinclude/afs" AC_MSG_RESULT(yes) else AC_MSG_RESULT(no) diff -urN samba-3.2.3.orig/source/lib/afs.c samba-3.2.3/source/lib/afs.c --- samba-3.2.3.orig/source/lib/afs.c 2008-09-26 21:01:22.943600000 +0200 +++ samba-3.2.3/source/lib/afs.c 2008-09-28 18:07:11.986286809 +0200 @@ -23,6 +23,7 @@ #define NO_ASN1_TYPEDEFS 1 +#include #include #include #include diff -urN samba-3.2.3.orig/source/lib/afs_settoken.c samba-3.2.3/source/lib/afs_settoken.c --- samba-3.2.3.orig/source/lib/afs_settoken.c 2008-09-22 18:51:18.683589000 +0200 +++ samba-3.2.3/source/lib/afs_settoken.c 2008-09-26 21:14:26.275582872 +0200 @@ -23,6 +23,7 @@ #define NO_ASN1_TYPEDEFS 1 +#include #include #include #include diff -urN samba-3.2.3.orig/source/modules/vfs_afsacl.c samba-3.2.3/source/modules/vfs_afsacl.c --- samba-3.2.3.orig/source/modules/vfs_afsacl.c 2008-08-27 13:23:20.000000000 +0200 +++ samba-3.2.3/source/modules/vfs_afsacl.c 2008-09-26 21:15:08.956586527 +0200 @@ -22,6 +22,7 @@ #undef DBGC_CLASS #define DBGC_CLASS DBGC_VFS +#include #include #include #include --------------090506030608030403090901-- From shadow@gmail.com Wed Oct 1 20:36:32 2008 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 1 Oct 2008 15:36:32 -0400 Subject: [OpenAFS] error installing open from repository with yum In-Reply-To: References: <1d1a54bf0809301807l66695116h545b3f7998ead483@mail.gmail.com> <48E2EEE0.7020800@unc.edu> Message-ID: On Wed, Oct 1, 2008 at 3:12 AM, Simon Wilkinson wrote: > > On 1 Oct 2008, at 04:30, Todd D. Taft wrote: > >> That seemed to work. The only problem is that they don't yet have a >> pre-built kernel module available for the kernel that Red Hat released at >> the end of last week. > > It's just been built (the build system had a hiccup), and should get copied > over at some point soon. > yum and the missing rpms should be fixed as of about 4 hours ago. From David.Bear@asu.edu Wed Oct 1 21:49:52 2008 From: David.Bear@asu.edu (David Bear) Date: Wed, 1 Oct 2008 13:49:52 -0700 Subject: [OpenAFS] error installing open from repository with yum In-Reply-To: References: <1d1a54bf0809301807l66695116h545b3f7998ead483@mail.gmail.com> <48E2EEE0.7020800@unc.edu> Message-ID: <1d1a54bf0810011349o26c1e47fxd099bd554207b4df@mail.gmail.com> ------=_Part_55765_694934.1222894192501 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, Oct 1, 2008 at 12:36 PM, Derrick Brashear wrote: > On Wed, Oct 1, 2008 at 3:12 AM, Simon Wilkinson wrote: > > > > On 1 Oct 2008, at 04:30, Todd D. Taft wrote: > > > >> That seemed to work. The only problem is that they don't yet have a > >> pre-built kernel module available for the kernel that Red Hat released > at > >> the end of last week. > > > > It's just been built (the build system had a hiccup), and should get > copied > > over at some point soon. > > > > yum and the missing rpms should be fixed as of about 4 hours ago. excellent. So I should wget the new repostory rpm and re-run yum? -- David Bear College of Public Programs at ASU 602-464-0424 ------=_Part_55765_694934.1222894192501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline


On Wed, Oct 1, 2008 at 12:36 PM, Derrick Brashear <shadow@gmail.com> wrote:
On Wed, Oct 1, 2008 at 3:12 AM, Simon Wilkinson <sxw@inf.ed.ac.uk> wrote:
>
> On 1 Oct 2008, at 04:30, Todd D. Taft wrote:
>
>> That seemed to work.  The only problem is that they don't yet have a
>> pre-built kernel module available for the kernel that Red Hat released at
>> the end of last week.
>
> It's just been built (the build system had a hiccup), and should get copied
> over at some point soon.
>

yum and the missing rpms should be fixed as of about 4 hours ago.
excellent. So I should wget the new repostory rpm and re-run yum?


--
David Bear
College of Public Programs at ASU
602-464-0424
------=_Part_55765_694934.1222894192501-- From sxw@inf.ed.ac.uk Wed Oct 1 22:00:31 2008 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Wed, 1 Oct 2008 22:00:31 +0100 Subject: [OpenAFS] error installing open from repository with yum In-Reply-To: <1d1a54bf0810011349o26c1e47fxd099bd554207b4df@mail.gmail.com> References: <1d1a54bf0809301807l66695116h545b3f7998ead483@mail.gmail.com> <48E2EEE0.7020800@unc.edu> <1d1a54bf0810011349o26c1e47fxd099bd554207b4df@mail.gmail.com> Message-ID: On 1 Oct 2008, at 21:49, David Bear wrote: > excellent. So I should wget the new repostory rpm and re-run yum? No new repository RPM. Providing everything has propagated on the OpenAFS servers, just re-running yum should pick things up. Let me know if it doesn't. S. From todd_taft@unc.edu Wed Oct 1 23:23:19 2008 From: todd_taft@unc.edu (Todd D. Taft) Date: Wed, 01 Oct 2008 18:23:19 -0400 Subject: [OpenAFS] error installing open from repository with yum In-Reply-To: References: <1d1a54bf0809301807l66695116h545b3f7998ead483@mail.gmail.com> <48E2EEE0.7020800@unc.edu> Message-ID: <48E3F857.8010905@unc.edu> Derrick Brashear wrote: > yum and the missing rpms should be fixed as of about 4 hours ago. A number of the links on http://www.openafs.org/pages/release/latest.html to the various aliased Red Hat Versions (5.1, 5Server, etc.) are broken... However, using the openafs-repository-rhel rpm seems to be working just fine. On one of my systems running RHEL 5.2 server, I blew away my previous AFS config and RPMs and was able to re-install the AFS client without problems (after fixing ThisCell, cacheinfo, etc., of course). I also noticed that http://www.openafs.org/release/1.4.7/index-rhel5.html doesn't have links to the rpms that make the yum repos; I'm not sure if that is intentional or not... --Todd -- Todd D. Taft todd_taft@unc.edu From David.Bear@asu.edu Thu Oct 2 00:11:41 2008 From: David.Bear@asu.edu (David Bear) Date: Wed, 1 Oct 2008 16:11:41 -0700 Subject: [OpenAFS] error installing open from repository with yum In-Reply-To: References: <1d1a54bf0809301807l66695116h545b3f7998ead483@mail.gmail.com> <48E2EEE0.7020800@unc.edu> <1d1a54bf0810011349o26c1e47fxd099bd554207b4df@mail.gmail.com> Message-ID: <1d1a54bf0810011611t302c6efbk364fd6d2fa4bc032@mail.gmail.com> ------=_Part_57963_25830832.1222902701672 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, Oct 1, 2008 at 2:00 PM, Simon Wilkinson wrote: > > On 1 Oct 2008, at 21:49, David Bear wrote: > > excellent. So I should wget the new repostory rpm and re-run yum? >> > > No new repository RPM. Providing everything has propagated on the OpenAFS > servers, just re-running yum should pick things up. > > Let me know if it doesn't. > > S. > Sorry to be a royal pain in the ... but there still seems to be a problem. Per Derrick's recommdation I grabed the rhel repository, installed that and then ran yum: sudo yum install openafs-client Loading "rhnplugin" plugin Loading "security" plugin openafs 100% |=========================| 951 B 00:00 primary.xml.gz 100% |=========================| 10 kB 00:00 openafs : ################################################## 77/77 rhel-i386-server-5 100% |=========================| 1.4 kB 00:00 primary.xml.gz 100% |=========================| 1.6 MB 00:00 rhel-i386-: ################################################## 4366/4366 rhel-i386-server-vt-5 100% |=========================| 1.4 kB 00:00 primary.xml.gz 100% |=========================| 25 kB 00:00 rhel-i386-: ################################################## 133/133 rhn-tools-rhel-i386-serve 100% |=========================| 1.2 kB 00:00 Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check ---> Package openafs-client.i386 0:1.4.7-el5.1.1 set to be updated --> Processing Dependency: openafs-kmod >= 1.4.7 for package: openafs-client --> Processing Dependency: openafs = 1.4.7 for package: openafs-client --> Running transaction check ---> Package dkms-openafs.i386 0:1.4.7-el5.1.1 set to be updated --> Processing Dependency: dkms for package: dkms-openafs ---> Package openafs.i386 0:1.4.7-el5.1.1 set to be updated --> Finished Dependency Resolution Error: Missing Dependency: dkms is needed by package dkms-openafs YUCK.. This isn't yummy at all. Is the dkms-openafs module supposed to be available as well? -- David Bear College of Public Programs at ASU 602-464-0424 ------=_Part_57963_25830832.1222902701672 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline


On Wed, Oct 1, 2008 at 2:00 PM, Simon Wilkinson <sxw@inf.ed.ac.uk> wrote:

On 1 Oct 2008, at 21:49, David Bear wrote:

excellent. So I should wget the new repostory rpm and re-run yum?

No new repository RPM. Providing everything has propagated on the OpenAFS servers, just re-running yum should pick things up.

Let me know if it doesn't.

S.

Sorry to be a royal pain in the ... but there still seems to be a problem. Per Derrick's recommdation I grabed the rhel repository, installed that and then ran yum:

sudo yum install openafs-client
Loading "rhnplugin" plugin
Loading "security" plugin
openafs 100% |=========================| 951 B 00:00
primary.xml.gz 100% |=========================| 10 kB 00:00
openafs : ################################################## 77/77
rhel-i386-server-5 100% |=========================| 1.4 kB 00:00
primary.xml.gz 100% |=========================| 1.6 MB 00:00
rhel-i386-: ################################################## 4366/4366
rhel-i386-server-vt-5 100% |=========================| 1.4 kB 00:00
primary.xml.gz 100% |=========================| 25 kB 00:00
rhel-i386-: ################################################## 133/133
rhn-tools-rhel-i386-serve 100% |=========================| 1.2 kB 00:00
Setting up Install Process
Parsing package install arguments
Resolving Dependencies
--> Running transaction check
---> Package openafs-client.i386 0:1.4.7-el5.1.1 set to be updated
--> Processing Dependency: openafs-kmod >= 1.4.7 for package: openafs-client
--> Processing Dependency: openafs = 1.4.7 for package: openafs-client
--> Running transaction check
---> Package dkms-openafs.i386 0:1.4.7-el5.1.1 set to be updated
--> Processing Dependency: dkms for package: dkms-openafs
---> Package openafs.i386 0:1.4.7-el5.1.1 set to be updated
--> Finished Dependency Resolution
Error: Missing Dependency: dkms is needed by package dkms-openafs

YUCK.. This isn't yummy at all. Is the dkms-openafs module supposed to be available as well?



--
David Bear
College of Public Programs at ASU
602-464-0424
------=_Part_57963_25830832.1222902701672-- From sxw@inf.ed.ac.uk Thu Oct 2 00:20:29 2008 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Thu, 2 Oct 2008 00:20:29 +0100 Subject: [OpenAFS] error installing open from repository with yum In-Reply-To: <1d1a54bf0810011611t302c6efbk364fd6d2fa4bc032@mail.gmail.com> References: <1d1a54bf0809301807l66695116h545b3f7998ead483@mail.gmail.com> <48E2EEE0.7020800@unc.edu> <1d1a54bf0810011349o26c1e47fxd099bd554207b4df@mail.gmail.com> <1d1a54bf0810011611t302c6efbk364fd6d2fa4bc032@mail.gmail.com> Message-ID: <88B90C17-118F-48CB-B11C-F53A1D810A8F@inf.ed.ac.uk> On 2 Oct 2008, at 00:11, David Bear wrote: > YUCK.. This isn't yummy at all. Is the dkms-openafs module supposed > to be available as well? > For some reason, it seems to be deciding to use the dkms-openafs module to settle the openafs-kmod dependency, rather than the pre- built kernel module. I'll need to dig deeper into this. For now, you can get around it by explicitly adding kmod-openafs to the yum update line. S. From shadow@gmail.com Thu Oct 2 00:31:17 2008 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 1 Oct 2008 19:31:17 -0400 Subject: [OpenAFS] error installing open from repository with yum In-Reply-To: <48E3F857.8010905@unc.edu> References: <1d1a54bf0809301807l66695116h545b3f7998ead483@mail.gmail.com> <48E2EEE0.7020800@unc.edu> <48E3F857.8010905@unc.edu> Message-ID: On Wed, Oct 1, 2008 at 6:23 PM, Todd D. Taft wrote: > Derrick Brashear wrote: > >> yum and the missing rpms should be fixed as of about 4 hours ago. > > A number of the links on http://www.openafs.org/pages/release/latest.html to > the various aliased Red Hat Versions (5.1, 5Server, etc.) are broken... Those links aren't supposed to even be there. Fixed again. From bacchi@rpi.edu Thu Oct 2 15:06:41 2008 From: bacchi@rpi.edu (Andrew Bacchi) Date: Thu, 02 Oct 2008 10:06:41 -0400 Subject: [OpenAFS] configuring largefile server In-Reply-To: References: <48DA56B3.5000309@rpi.edu> Message-ID: <48E4D571.5090205@rpi.edu> Derrick, I don't think it defaults to building the largefile-fileserver. I had a user that could not 'cat' two files together making a single file of over 3GB, with my build of OpenAFS-1.4.6. I then built 1.4.7, and specified --enable-largefile-fileserver. Now I can 'cat' those files together. Here's my section of the openafs.spec file, and the resulting config.log. config_opts="--enable-redhat-buildsys \ %{?_with_bitmap_later:--enable-bitmap-later} \ %{?_with_bos_restricted:--enable-bos-restricted-mode} \ %{?_with_fast_restart:--enable-fast-restart} \ %{?_with_largefiles:--enable-largefile-fileserver} \ %{?_with_supergroups:--enable-supergroups} \ --enable-fast-restart \ --enable-largefile-fileserver \ --enable-largefiles \ --enable-transarc-paths" $ ./configure --with-afs-sysname=i386_linux26 --prefix=/usr --libdir=/usr/lib --bindir=/usr/bin --sbindir=/usr/sbin --disable-strip-binaries --with-krb5-conf= /usr/kerberos/bin/krb5-config --enable-redhat-buildsys --enable-fast-restart --e nable-largefile-fileserver --enable-largefiles --enable-transarc-paths Derrick Brashear wrote: > On Wed, Sep 24, 2008 at 11:03 AM, Andrew Bacchi wrote: >> I've built openafs using the SRPM for openafs-1.4.6 on Redhat ES4. The >> openafs.spec file specifies config_opts as --enable-redhat-buildsys, which >> includes and should build a largefile-fileserver. Correct? >> >> My config.log file confirms I'm building with --enable-redhat-buildsys. >> Do I need to explicitly use --enable-largefile-fileserver? > > No. > > Defaults to on since 1.4.2. > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > -- veritatas simplex oratio est -Seneca Andrew Bacchi Systems Programmer Rensselaer Polytechnic Institute phone: 518.276.6415 fax: 518.276.2809 http://www.rpi.edu/~bacchi/ From jaltman@secure-endpoints.com Fri Oct 3 00:11:31 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 02 Oct 2008 19:11:31 -0400 Subject: [OpenAFS] 1.4.8, Rx Performance Improvements, and a Small Business Innovative Research grant Message-ID: <48E55523.40606@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms010408080807080201090308 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In discussions during 2007 with the HEPiX community, it was made clear to the gatekeepers that identifying and correcting trouble spots within Rx was one of the most important areas that OpenAFS needed to improve in order to maintain the existing deployments within that community of users. No one had the resources to put towards such a pursuit and it was suggested that OpenAFS apply for a United States Small Business Innovative Research (SBIR) grant to fund the work. There are two problems with such an approach. First, OpenAFS does not legally exist and even when it does have a legal Foundation, it would not be eligible for an SBIR grant due to its not-for-profit status. Since we did not have any other source of funding to perform the work it was suggested that one of the existing commercial support companies submit a grant application. In October 2007 I founded Your File System Inc. as a for-profit company that would be eligible to receive an SBIR grant and use the funding to accomplish two goals. First, to benefit the OpenAFS community by documenting the existing architectures and protocols used by OpenAFS as well as engage in profiling and performance analysis that could be used as input to the development of next generation implementations. Secondly, because the company is receiving SBIR funding, to develop a sustainable business model that could support the development of a next generation distributed storage system. The SBIR grant has provided funding for developer hours as well as test equipment. In particular, the SBIR grant has provided a 10GBit/second network testbed which is being used for Rx profiling. I am pleased to announce the first public benefit to the OpenAFS community as a result of the SBIR grant with the expectation that there will be much more to come in the future. There have been many efforts over the last five years to improve Rx. Tom Keiser implemented per thread free packet queues to reduce the contention for the global lock protecting the free packet queue. Other work has been performed to reduce the dependency on global locks. Rx hot threads have been implemented on a broader range of platforms. Various bug fixes have been accepted as they have been validated. Still with all of this work, Rx still has experienced noticeable performance problems. In November 2006 there was discussion regarding a 350ms hiccup that was experienced repeatedly and was significantly hampering performance. Several folks have tried to pin it down over the years unsuccessfully. Funded by the SBIR grant there have been efforts over the last couple of months to analyze Rx performance data from a number of sources. There were several symptoms identified that it was unclear were related to the hiccup but were worth investigating. First there was a periodic out of memory error experienced in Windows test clients. Second, there was a consistent lack of free packets. Third, there were a much larger number of retries than could be explained due to packets lossage on the network. What the investigations uncovered were a related set of problems; some of which affect all implementations of Rx derived from the Transarc implementation. The problems fall into several categories: 1. Resetting a Call object emptied packet queues without adding the packets to the free packet queue. rxi_ResetCall() would call queue_Init() on queues with active rx_packets on them. once the queues were cleared the packets were leaked and any acknowledgment of receipt or transmission of other outgoing data would be lost. Instead of initializing the queues the contents of the queues should simply be freed either by a call to rxi_FreePackets() or by setting the force flag on rxi_ClearTransmitQueue() and rxi_ClearReceiveQueue(). 2. Packets queued for transmission would not be sent. In rx.c there were two instances of RX_GLOBAL_RXLOCK_KERNEL which should have been AFS_GLOBAL_RXLOCK_KERNEL. This oversight resulted in rx_calls that were actively transmitting packets to reset the call prematurely and leak the outgoing packets. 3. Packets would be leaked while read operations were progressing. rxi_ReadProc()/rxi_ReadProc32() failed to remove the currentPacket and put it on the call's iov queue when all of its data was read. This resulted in the packet being lost either when the next read packet was fetched, when the next packet was transmitted, or when the call was reset. 4. The algorithm in OpenAFS which is used to allocate additional packets when there were no free packets was overly aggressive. It was based on the overall number of packets that had been previously allocated. Each allocation would increase a larger number than the previous one. The side effects of these issues have been present in AFS for a very long time and have been seen in both clients and servers. Corrections for these errors have been integrated into 1.5.53 and 1.4.8-pre1. As a result of these problems Rx was periodically not sending the anticipated acknowledgment packet which in turn resulted in a timeout and retransmission. The Rx stack was also frequently finding itself out of free packets and was forced to block on a global lock while additional packets structures were allocated from the process' memory pool. The end result was a performance improvement of greater than 9.5% when comparing the Rx performance of 1.4.8 over 1.4.7. Rough tests show that the 1.4.8 Rx stack is capable of 124MBytes/second over a 10Gbit link. There is still a long way to go to fill a 10Gbit pipe but it is a start. Now we are only off by one order of magnitude. Some might ask, "how is it that these bugs remained present in the OpenAFS source tree for all of these years?" The answer is quite simple. "No one ever thought to look for packet leaks." Many organizations still perform weekly server restarts and never noticed the memory leaks and the rxdebug -rxstats output lists the free packet count but no one ever thought that it was important to report the number of allocated packets. As a result no one noticed that the reason there were free packets available was because packets were constantly being allocated instead of recycled. Over the years many individuals have noticed the extra resends. Its just that no one was able to identify why they were being sent. The resends did not prevent the system from functioning. It was just slower than it should be. As these changes become available for both clients and servers I am expecting users to see a much improved throughput rate and several previously unexplained server and client crashes will now being a thing of the past. In order to get OpenAFS 1.4.8 released we need the assistance of the community to test the pre-releases. 1.4.8-pre1 was announced yesterday. The best way to move the release process along is for organizations that deploy OpenAFS to test the pre-releases and send e-mails to this mailing list confirming what works. Silence cannot be interpreted by the gatekeepers as all is well. I look forward to your reports of success and to reporting future grant funded contributions in the future. Jeffrey Altman --------------ms010408080807080201090308 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMDIyMzExMzFaMCMGCSqGSIb3DQEJBDEWBBRqwUQR zShdvPOsIOrajnkYrbvwWjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAoHkm0Zb3+z+6Q+iwfm9efRERqnXcg8A8vq1IX5s19BkvJutbP7k6 Vn2udEw3QHnZlPbUcBl+Eqt7GLI91W7JRq+oaDav7HWL28vGT+G1BIN2036zb6tNUrVfwYSV hG5QYhRjnkDi+liWBM17Zd/9RkyejHySqzKng0h0TbnugenMP3coKHpCsaspv8dwARQuYTYz Yi+wrC/lrUYFleJ2Ie1rvXm3GM0Gy2Ji4/Cs/de/6uneTGPfzri52+XYxI9nV5KqpzTGWANP 6MFIsClAmmL39uL2FaAltra/Y+sTF7kSQw9gRLCjJ6H3iGEmCBdwiUXZBXYhSR1aslRB9IEx dgAAAAAAAA== --------------ms010408080807080201090308-- From jason@rampaginggeek.com Fri Oct 3 02:33:55 2008 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Thu, 02 Oct 2008 21:33:55 -0400 Subject: [OpenAFS] Re: [OpenAFS-announce] OpenAFS 1.4.8 release candidate 1 available In-Reply-To: References: Message-ID: <48E57683.5050908@rampaginggeek.com> Derrick J Brashear wrote: > The OpenAFS Gatekeepers announce the availability of the first release > candidate for OpenAFS version 1.4.8. > Source files and available binaries can be accessed via the web at: > > http://www.openafs.org/release/openafs-1.4.8pre1.html > > or via AFS at: > > UNIX: /afs/grand.central.org/software/openafs/candidate/1.4.8pre1/ > UNC: \\afs\grand.central.org\software\openafs\candidate\1.4.8pre1\ > > > A number of changes to improve Rx behavior as well as other bugfixes > are present. > > Please assist the gatekeepers by deploying this release and providing > positive or negative feedback. Bug reports should be filed to > openafs-bugs@openafs.org . Reports of success should be sent to > openafs-info@openafs.org . Should the Mac OS X package work on Tiger PPC? Thanks, Jason From jaltman@secure-endpoints.com Fri Oct 3 03:04:36 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 02 Oct 2008 22:04:36 -0400 Subject: [OpenAFS] Re: [OpenAFS-announce] OpenAFS 1.4.8 release candidate 1 available In-Reply-To: <48E57683.5050908@rampaginggeek.com> References: <48E57683.5050908@rampaginggeek.com> Message-ID: <48E57DB4.7070609@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms080203080204030808030104 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jason Edgecombe wrote: > Derrick J Brashear wrote: >> The OpenAFS Gatekeepers announce the availability of the first release >> candidate for OpenAFS version 1.4.8. >> Source files and available binaries can be accessed via the web at: >> >> http://www.openafs.org/release/openafs-1.4.8pre1.html >> >> or via AFS at: >> >> UNIX: /afs/grand.central.org/software/openafs/candidate/1.4.8pre1/ >> UNC: \\afs\grand.central.org\software\openafs\candidate\1.4.8pre1\ >> >> >> A number of changes to improve Rx behavior as well as other bugfixes >> are present. >> >> Please assist the gatekeepers by deploying this release and providing >> positive or negative feedback. Bug reports should be filed to >> openafs-bugs@openafs.org . Reports of success should be sent to >> openafs-info@openafs.org . > Should the Mac OS X package work on Tiger PPC? > > Thanks, > Jason There is no 10.4 (Tiger) package on the release page. The only available package is for 10.5 (Leopard). Jeffrey Altman --------------ms080203080204030808030104 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMDMwMjA0MzZaMCMGCSqGSIb3DQEJBDEWBBSxOC82 9xreMhgW7deCvWE839rXAzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAHUXDh+XqWMJtuKMeG774W2gSx94LikBGdNv8CD5UaTwWRA0qicMs JF8s7iFMrqYNjPEm4SMJPibPWlfAdwh7OZ8rMIYY5zxRaTtw3njVp0ohWSwBZLK4biYBVEB8 UXOnThF6pghXMSXJcgasXXXYYR7B5sG4YTQAiQ6JASzBhGjJbc5Lyy50hHOgCZFYUm85/x4y GE1KVkUCxKqLIHSLOAnja65lIA4eZLVrQ3WoAj5ujBJxqa8gHq9d9iOHsEVjvHwnCElsy7s0 5ietkXEmhg15YgVMOhutUzQPUDOhRHsGqCQQ03WUGAa65/Rhn79jJhASzZ0BD2FS5FJd11t6 ZwAAAAAAAA== --------------ms080203080204030808030104-- From rtb@pclella.cern.ch Fri Oct 3 11:08:33 2008 From: rtb@pclella.cern.ch (Rainer Toebbicke) Date: Fri, 3 Oct 2008 12:08:33 +0200 Subject: [OpenAFS] 1.4.8, Rx Performance Improvements, and a Small Business Innovative Research grant In-Reply-To: <48E55523.40606@secure-endpoints.com> References: <48E55523.40606@secure-endpoints.com> Message-ID: <48E5EF21.4040102@pclella.cern.ch> > As a result of these problems Rx was periodically not sending the=20 > anticipated acknowledgment packet which in turn resulted in a timeout > and retransmission. The Rx stack was also frequently finding itself > out of free packets and was forced to block on a global lock while > additional packets structures were allocated from the process'=20 > memory pool. The end result was a performance improvement of greater > than 9.5% when comparing the Rx performance of 1.4.8 over 1.4.7. =20 >=20 > Rough tests show that the 1.4.8 Rx stack is capable of 124MBytes/second > over a 10Gbit link. There is still a long way to go to fill a 10Gbit > pipe but it is a start. Now we are only off by one order of magnitude. >=20 Having in the past repeatedly dug into the RX code (without spotting=20 those problems!) I am of course very interested and will try the new=20 code as soon as possible! Just a few findings on RX from my previous (vain) attempts to make it=20 "lightning fast" - perhaps they trigger ideas for whoever is still=20 working on it or corrections from those who know better: 1. as latency grows when crossing routers or even public networks the=20 default window of 32 packets is too small. On the other hand, the=20 handling of the transmission queue grows with n**2, and even fast=20 processors are quickly overwhelmed. Here's where "oprofile" is a=20 valuable tool. Some of this can be reduced with queue hints, wisely=20 posting retransmit events and trying to avoid scanning the whole queue=20 in several places; 2. jumbograms are a pain: years ago we had a research network dropping=20 fragmented packets and spent weeks on pinning that down. Currently we=20 suspect another one. Firewalls choke on them. They also increase=20 complexity for access list in routers. And of course the probability=20 increases of having to retransmit the whole jumbogram because one=20 fragment got lost. What makes me frown is that it is apparently=20 faster if the kernels split and reassemble jumbograms on the fly, than=20 by RX doing it with much more knowledge about the state; 3. the path for handling an ACK packet is very long, I measured on the=20 order of 10 microseconds on average on a modern processor. At over=20 100 MB/s you'd be handling ~50000 ACKs per second in a non-jumbogram=20 configuration and have hardly any time left to send out new packets. A=20 lot is spent on waiting for the call-lock: even when that one is=20 released quickly (which it isn't in the standard implementation, as=20 the code leisurely walks around with it for extended periods, but I=20 experimented with a "release" flag), the detour through the scheduler=20 slows down things dramatically. The lock structure should probably be=20 revisited to make contention between ack recv & transmit threads less=20 likely; 4. slow start is implemented state-of-the-art, fast recovery however=20 looks odd to me (actually: "inexisting" but I may be fooled by some=20 jumbogram smoke). When it comes to congestion avoidance, a lot of the=20 research that went into TCP in the last ten years is obviously=20 missing. I started experimenting with CUBIC in the hope that it helps=20 to reduce retransmits and keeping a constant flow, let's see; 5. earlier this year we mentioned handling of new calls, which is=20 again a quadratic problem due to the mixture of service classes. This=20 makes it impractical to allow for thousands of waiting calls, creating=20 a problem on a cluster with thousands of nodes. With those observations... does rx-over-tcp look like a solution? On=20 the packet-transmission side probably, but the encapsulation very=20 likely still demands significant processing power. And running a=20 server with 10000 or 20000 TCP connections does not sound that obvious=20 either. Voil=E0... my 0.02 =A4. Sorry for being verbose, I couldn't resist. --=20 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D Rainer Toebbicke European Laboratory for Particle Physics(CERN) - Geneva, Switzerland Phone: +41 22 767 8985 Fax: +41 22 767 7155 From shadow@gmail.com Fri Oct 3 14:27:06 2008 From: shadow@gmail.com (Derrick Brashear) Date: Fri, 3 Oct 2008 09:27:06 -0400 Subject: [OpenAFS] re-ip a database server In-Reply-To: References: Message-ID: On Fri, Sep 26, 2008 at 9:42 AM, Suzanne McTaggart wrote: > This past weekend I re-ip'ed my afs database server from one net to another. > > Everything seems to be functioning except I do not get the correct listing > from vos lista. As it lists the old ip address but not the new name or new > ip. > > bash-3.1# vos lista > vsu_ClientInit: Could not get afs tokens, running unauthenticated. > 207.224.230.135 > 207.224.230.4 listaddrs lists fileserver, not database server addresses. did you move all the volumes and shut down the old fileserver? From Stephan.Wiesand@desy.de Fri Oct 3 16:05:33 2008 From: Stephan.Wiesand@desy.de (Stephan Wiesand) Date: Fri, 3 Oct 2008 17:05:33 +0200 (CEST) Subject: [OpenAFS] 1.4.8pre1 success on EL3/4/5 Message-ID: Built without problems, and the client survived light testing, on Scientifc Linux 3/4/5, i386 and x86_64. The fileserver apparently works on SL5/x86_64. -- Stephan Wiesand DESY - DV - Platanenallee 6 15738 Zeuthen, Germany From jaltman@secure-endpoints.com Fri Oct 3 13:54:22 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Fri, 03 Oct 2008 08:54:22 -0400 Subject: [OpenAFS] 1.4.8, Rx Performance Improvements, and a Small Business Innovative Research grant In-Reply-To: <48E5EF21.4040102@pclella.cern.ch> References: <48E55523.40606@secure-endpoints.com> <48E5EF21.4040102@pclella.cern.ch> Message-ID: <48E615FE.6060705@secure-endpoints.com> Rainer Toebbicke wrote: > Just a few findings on RX from my previous (vain) attempts to make it > "lightning fast" - perhaps they trigger ideas for whoever is still > working on it or corrections from those who know better: > > 1. as latency grows when crossing routers or even public networks the > default window of 32 packets is too small. On the other hand, the > handling of the transmission queue grows with n**2, and even fast > processors are quickly overwhelmed. Here's where "oprofile" is a > valuable tool. Some of this can be reduced with queue hints, wisely > posting retransmit events and trying to avoid scanning the whole queue > in several places; > > 2. jumbograms are a pain: years ago we had a research network dropping > fragmented packets and spent weeks on pinning that down. Currently we > suspect another one. Firewalls choke on them. They also increase > complexity for access list in routers. And of course the probability > increases of having to retransmit the whole jumbogram because one > fragment got lost. What makes me frown is that it is apparently faster > if the kernels split and reassemble jumbograms on the fly, than by RX > doing it with much more knowledge about the state; > > 3. the path for handling an ACK packet is very long, I measured on the > order of 10 microseconds on average on a modern processor. At over 100 > MB/s you'd be handling ~50000 ACKs per second in a non-jumbogram > configuration and have hardly any time left to send out new packets. A > lot is spent on waiting for the call-lock: even when that one is > released quickly (which it isn't in the standard implementation, as the > code leisurely walks around with it for extended periods, but I > experimented with a "release" flag), the detour through the scheduler > slows down things dramatically. The lock structure should probably be > revisited to make contention between ack recv & transmit threads less > likely; > > 4. slow start is implemented state-of-the-art, fast recovery however > looks odd to me (actually: "inexisting" but I may be fooled by some > jumbogram smoke). When it comes to congestion avoidance, a lot of the > research that went into TCP in the last ten years is obviously missing. > I started experimenting with CUBIC in the hope that it helps to reduce > retransmits and keeping a constant flow, let's see; > > 5. earlier this year we mentioned handling of new calls, which is again > a quadratic problem due to the mixture of service classes. This makes it > impractical to allow for thousands of waiting calls, creating a problem > on a cluster with thousands of nodes. 6. the rx statistics global lock is still a bottleneck > With those observations... does rx-over-tcp look like a solution? On the > packet-transmission side probably, but the encapsulation very likely > still demands significant processing power. And running a server with > 10000 or 20000 TCP connections does not sound that obvious either. One of the problems that Rx/udp has is that all of the processing must be done by the CPUs and none of it can be offloaded to the network adapters. Modern network adapters and supporting drivers permit the offloading of tcp stream processing. Pushing this work into hardware is considered critical to filling 10GB network pipes. Certainly switching to an Rx/tcp model is going to be the long term future. At the same time, there are still improvements that can be made to Rx/udp that can provide benefits to existing clients. > Voilà... my 0.02 €. Sorry for being verbose, I couldn't resist. The community is very appreciative for all of the efforts you have put into analyzing Rx over the years. I look forward to your continued involvement. Jeffrey Altman From kenh@cmf.nrl.navy.mil Fri Oct 3 14:58:31 2008 From: kenh@cmf.nrl.navy.mil (Ken Hornstein) Date: Fri, 03 Oct 2008 09:58:31 -0400 Subject: [OpenAFS] 1.4.8, Rx Performance Improvements, and a Small Business Innovative Research grant In-Reply-To: <48E5EF21.4040102@pclella.cern.ch> Message-ID: <200810031358.m93DwV4f001009@hedwig.cmf.nrl.navy.mil> >With those observations... does rx-over-tcp look like a solution? On >the packet-transmission side probably, but the encapsulation very >likely still demands significant processing power. And running a >server with 10000 or 20000 TCP connections does not sound that obvious >either. Here's what I can tell you, based on my experience: - The encapsulation for rx-over-tcp wasn't, in my experience, a huge performance sink. The trick was trying to create a protocol that didn't starve multiple writers who were trying to use the same connection. I think I made some decent progress on this; I was able to convince myself that the problem wasn't insurmountable. - Web servers seem to manage this sort of thing fine (admittedly, there are a lot of front-end devices they can use than OpenAFS cannot, but still, a lot of work has been done on handling tons of TCP connections). There are some obvious ways of dealing with this. I think in practice it will be a non-issue. --Ken From dhk@ccre.com Fri Oct 3 17:24:36 2008 From: dhk@ccre.com (Kim Kimball) Date: Fri, 03 Oct 2008 10:24:36 -0600 Subject: [OpenAFS] Mount point weirdness: fs lsm X, fs lq X return different volumes for same mount point. In-Reply-To: <29783928.1222781635636.JavaMail.root@m01> References: <48E15910.7000400@ccre.com> <29783928.1222781635636.JavaMail.root@m01> Message-ID: <48E64744.8040308@ccre.com> Jeffrey Altman wrote: > Questions that pop into mind: > > 1) what versions of the clients were involved? > > Multiple, Solaris, Linux, Windows, Macintosh. > 2) what was the output of vos examine on the volume names? > Correct output -- using volume name, returned correct numeric ID and on line status. Using number, returned correct name and on line status. > 3) same problem after a cache manager shutdown and restart? > No attempted. Issue resolved within five minutes of fix -- first fix was to dump/restore affected volumes to force new volIDs. This worked. All clients fine after fix, simultaneously, so don't think restart would have helped. fs checkv was used after each fix effort, along with lots of fs checkv just for good measure. > 4) same problem from Unix and Windows clients? > > Yes. Thanks! Kim > Jeffrey Altman > > > Kim Kimball wrote: > >> Had a weird one on Thursday, and am looking for any plausible >> explanation so I can close out the incident report. >> My best answer right now is NAFC (not an effing clue.) >> >> I'm using "X-mounted" to describe "volume named in mountpoint" not equal >> to "volume accessed at mountpoint" >> >> Probably relevant: We were moving volumes to clear a file server, and >> noticed an unusual number of orphaned volumes. >> When I went to start 'vos zapping' the orphans, many of them turned out >> to be those that incorrectly showed up at a given mount point. >> >> Could it be that the 'vos move' failures that created the orphans are >> the proximate cause of the X-mounts? If so, how could the two be related? >> >> Any FC greatly appreciated. >> >> Kim >> >> ==================================== >> Synopsis: >> >> From any AFS client, the volume named in a mount point was not the >> volume actually accessed >> >> >> Initial symptom: >> web servers start puking when invoking perl modules >> cd to path where perl modules are expected, and instead of perl >> modules see bunch of unrelated png libraries >> check mount point to volume containing perl modules, and mount >> point correctly names perl volume >> fs lq on mount point returns name of volume containing png >> libraries -- not the name of the volume specified in fs lsm >> >> The diagnostic: >> fs lsm --> volumeA >> fs lq --> volumeZ >> >> Confirmation: >> cd >> ls >> ----- returns list of files/directories stored in volumeZ >> >> The mount point is correct; that is, fs lsm returns the expected volume >> name. >> The volume accessed at the mount point is incorrect. >> The files/directories in the incorrectly accessed volume are correct. >> >> ------------------------------- >> We turned up forty plus instances of X-mounted (for lack of a better >> word) volumes. >> >> The fix: >> remove the mount point >> release the volume (containing mount point) >> create same mount point >> release volume again >> >> vos addsite newserver newpart _mounted_ volume (as named in mount point) >> vos release _mounted_ volume >> fs checkv >> >> Then get expected responses. >> fs lsm --> volumeA >> fs lq --> volumeA >> >> ======================== >> >> Other efforts: >> >> I did restart the fs instances on all file servers, suspecting some sort >> of off-by-one'ish glitch in some unknown index/table/? >> >> The restarts had no impact. >> >> 'vos move" of the volume containing the mount point did not help. >> >> ----------------- >> >> >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info >> From dhk@ccre.com Fri Oct 3 17:46:27 2008 From: dhk@ccre.com (Kim Kimball) Date: Fri, 03 Oct 2008 10:46:27 -0600 Subject: [OpenAFS] Mount point weirdness: fs lsm X, fs lq X return different volumes for same mount point. In-Reply-To: <11055703.1222782971532.JavaMail.root@m01> References: <48E15910.7000400@ccre.com> <48E226B7.5050809@secure-endpoints.com> <11055703.1222782971532.JavaMail.root@m01> Message-ID: <48E64C63.10200@ccre.com> Derrick Brashear wrote: > I don't see fs checkv before the attempted fix. Was it? > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > > > Hi Derrick, Sorry to delay in response. A wooky ripped my left shoulder out of the socket (IOW I flipped a recumbent trike) and I was getting the good news (it can be scoped) and catching up on my 401-keg plan, Anyway, we used fs checkv like it was going out of style. The first fix, which I don't believe I mentioned, was to dump/restore the volume containing the mount point, and the volume mounted, to force new volIDs. This worked, resolving the issue for all the various client types and versions, simultaneously, for the dumped/restored volumes. I don't believe dump/restore of the parent was necessary but didn't try independently. I figured this would work as there was obviously some confusion about volIDs/names and I wasn't sure where the confusion might be. Figuring it might be an oddity with the file servers, I bos restarted all of them. I chose not to reboot as the critical volumes were 'back in place.' The bos restart did not help, and I continued to see the same disparity between 'fs lsm' and 'fs lq' on about forty mount points. Since these were mostly disused volumes, I experimented with other approaches. I tried salvaging the vol.ume containing the disobeyed mount point; no joy. vos syncvl/syncser no joy. Fairly reliable, and it may have been just the second step that bailed me out: 1. Remove mount point from volume A 2. vos release volume A 3. vos addsite newsite volume B (the mounted volume) 4. vos release volumeB Note that all of these volumes were replicated, both the volumes A and volumes B. Note also that due to volume moves that did not fully complete there was an orphan for most if not all of the volumes B. These moves were within a few hours of the incident. I can get precise move times from logs if of interest. Cleaning up the orphans was done concomitant with other efforts and may have had impact. I will look for additional existing instances today, and if I find any will not fix -- perhaps we can use for diagnostic. (So of course now I regret fixing those volumes I fixed. I love computing! ) Thanks. Kim From steven.jenkins@gmail.com Fri Oct 3 17:56:18 2008 From: steven.jenkins@gmail.com (Steven Jenkins) Date: Fri, 3 Oct 2008 12:56:18 -0400 Subject: [OpenAFS] Mount point weirdness: fs lsm X, fs lq X return different volumes for same mount point. In-Reply-To: <48E64C63.10200@ccre.com> References: <48E15910.7000400@ccre.com> <48E226B7.5050809@secure-endpoints.com> <11055703.1222782971532.JavaMail.root@m01> <48E64C63.10200@ccre.com> Message-ID: If you have tcpdump data for cache manager <-> vlserver and cache manager <-> fileserver traffic during one of these corruptions, that could be very helpful. I've found tcpdump (or wireshark/tshark) to be useful in tracking down issues like this because you can very quickly see if the problem is 1- cache manager asking for the wrong thing to start with (possibly cache corruption -- not conclusive because you have to determine if the cache manager got the bad data and cached it, or if the cache manager 'broke' the data; picking one client and clearing it's cache, then re-trying can help answer that question). Note that in your case, this is pretty unlikely, given that you saw it across multiple clients on mutiple OSes. 2- vlserver giving a wrong answer 3- neither of the above, which means the fileserver is giving a wrong answer. The usual suspects (e.g., cmdebug) are also helpful here. It might also be useful to get the callback state from the fileservers to see what they think the cache managers have for data (if in case 3 above). Given that 'failed volume moves' seem to have been a trigger for this, logfiles might have something interesting, especially if you can provide volume names & volume id's for the X-volumes' -- Steven Jenkins End Point Corporation http://www.endpoint.com/ From jaltman@secure-endpoints.com Fri Oct 3 22:08:04 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Fri, 03 Oct 2008 17:08:04 -0400 Subject: [OpenAFS] Mount point weirdness: fs lsm X, fs lq X return different volumes for same mount point. In-Reply-To: <48E64744.8040308@ccre.com> References: <48E15910.7000400@ccre.com> <29783928.1222781635636.JavaMail.root@m01> <48E64744.8040308@ccre.com> Message-ID: <48E689B4.9090902@secure-endpoints.com> Kim: What I am parsing out of this is the following: 1. The mount point target strings were correct as viewed from all of the cache managers. 2. The FID reported by "fs examine " was the wrong volume ID on all cache managers. 3. vos examine reported the correct volume ID 4. vos examine reported the correct volume name 5. fs checkvolume which resets all of the volume location in the cache manager did not fix the problem. This seems to imply that ubik_VL_GetEntryByNameN() was succeeding (vos examine) but VL_GetEntryByNameU() was failing. This could indicate that different VL servers were being contacted by vos vs the cache manager and one of the VLDB instances was corrupt. The key items to confirm are that the FID for the target volume is in fact wrong which I suspect it must be since you have so many different client versions affected simultaneously. Second, would be to use a network monitor to confirm which VLDB instance has bad data. Jeffrey Altman Secure Endpoints Inc. Kim Kimball wrote: > Jeffrey Altman wrote: >> Questions that pop into mind: >> >> 1) what versions of the clients were involved? >> >> > Multiple, Solaris, Linux, Windows, Macintosh. >> 2) what was the output of vos examine on the volume names? >> > Correct output -- using volume name, returned correct numeric ID and on > line status. Using number, returned correct name and on line status. >> 3) same problem after a cache manager shutdown and restart? >> > No attempted. Issue resolved within five minutes of fix -- first fix > was to dump/restore affected volumes to force new volIDs. This worked. > > All clients fine after fix, simultaneously, so don't think restart would > have helped. > > fs checkv was used after each fix effort, along with lots of fs checkv > just for good measure. >> 4) same problem from Unix and Windows clients? >> >> > Yes. > > Thanks! > > Kim > >> Jeffrey Altman >> >> >> Kim Kimball wrote: >> >>> Had a weird one on Thursday, and am looking for any plausible >>> explanation so I can close out the incident report. >>> My best answer right now is NAFC (not an effing clue.) >>> >>> I'm using "X-mounted" to describe "volume named in mountpoint" not equal >>> to "volume accessed at mountpoint" >>> >>> Probably relevant: We were moving volumes to clear a file server, and >>> noticed an unusual number of orphaned volumes. >>> When I went to start 'vos zapping' the orphans, many of them turned out >>> to be those that incorrectly showed up at a given mount point. >>> >>> Could it be that the 'vos move' failures that created the orphans are >>> the proximate cause of the X-mounts? If so, how could the two be >>> related? >>> >>> Any FC greatly appreciated. >>> >>> Kim >>> >>> ==================================== >>> Synopsis: >>> >>> From any AFS client, the volume named in a mount point was not the >>> volume actually accessed >>> >>> >>> Initial symptom: >>> web servers start puking when invoking perl modules >>> cd to path where perl modules are expected, and instead of perl >>> modules see bunch of unrelated png libraries >>> check mount point to volume containing perl modules, and mount >>> point correctly names perl volume >>> fs lq on mount point returns name of volume containing png >>> libraries -- not the name of the volume specified in fs lsm >>> >>> The diagnostic: >>> fs lsm --> volumeA >>> fs lq --> volumeZ >>> >>> Confirmation: >>> cd >>> ls >>> ----- returns list of files/directories stored in volumeZ >>> >>> The mount point is correct; that is, fs lsm returns the expected volume >>> name. >>> The volume accessed at the mount point is incorrect. >>> The files/directories in the incorrectly accessed volume are correct. >>> >>> ------------------------------- >>> We turned up forty plus instances of X-mounted (for lack of a better >>> word) volumes. >>> >>> The fix: >>> remove the mount point >>> release the volume (containing mount point) >>> create same mount point >>> release volume again >>> >>> vos addsite newserver newpart _mounted_ volume (as named in mount >>> point) >>> vos release _mounted_ volume >>> fs checkv >>> >>> Then get expected responses. >>> fs lsm --> volumeA >>> fs lq --> volumeA >>> >>> ======================== >>> >>> Other efforts: >>> >>> I did restart the fs instances on all file servers, suspecting some sort >>> of off-by-one'ish glitch in some unknown index/table/? >>> >>> The restarts had no impact. >>> >>> 'vos move" of the volume containing the mount point did not help. >>> >>> ----------------- >>> >>> >>> _______________________________________________ >>> 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 David.Bear@asu.edu Fri Oct 3 19:57:24 2008 From: David.Bear@asu.edu (David Bear) Date: Fri, 3 Oct 2008 11:57:24 -0700 Subject: [OpenAFS] cache manager hangs on windows Message-ID: <1d1a54bf0810031157v2f148b4auc5b2af0fc56833da@mail.gmail.com> ------=_Part_41954_17327440.1223060244849 Content-Type: multipart/alternative; boundary="----=_Part_41955_25438485.1223060244849" ------=_Part_41955_25438485.1223060244849 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline We have a system where openafs has hung twice now in the midst of editing an excell spreadsheet. The system is a windows XP with SP3. (standard 32 bit windows xp professional) Remotely, afs still responds to these commands /usr/sbin/rxdebug -servers system.dhcp.asu.edu -port 7001 -version Trying 129.219.56.213 (port 7001): AFS version: OpenAFS_1.5.5200 /usr/sbin/rxdebug -servers system.dhcp.asu.edu -port 7001 -rxstats Trying 129.219.56.213 (port 7001): Free packets: 1523, packet reclaims: 0, calls: 17853, used FDs: 0 not waiting for packets. 0 calls waiting for a thread 1 threads are idle rx stats: free packets 1523, allocs 43722, alloc-failures(rcv 0/0,send 0/0,ack 0) greedy 0, bogusReads 0 (last from host 0), noPackets 5, noBuffers 0, selects 0, sendSelects 0 packets read: data 20763 ack 19909 busy 0 abort 0 ackall 0 challenge 4 response 0 debug 2 params 0 unused 0 unused 0 unused 0 version 0 other read counters: data 20763, ack 19909, dup 0 spurious 0 dally 0 packets sent: data 22681 ack 2978 busy 0 abort 3 ackall 0 challenge 0 response 4 debug 0 params 0 unused 0 unused 0 unused 0 version 0 other send counters: ack 2978, data 45362 (not resends), resends 3, pushed 0, acked&ignored 2322 (these should be small) sendFailed 0, fatalErrors 0 Average rtt is 0.003, with 1434 samples Minimum rtt is 0.000, maximum is 0.016 9 server connections, 0 client connections, 13 peer structs, 0 call structs, 60 free call structs Done. But the windows explorer shell and excel are completely hung. Any attempts to use KFW to get new kerberos tickets fail -- the NIM just hangs. Any attempts to use afscreds to get tokens will hang afscreds. I am attaching the output of cmdebug -servers pp-kcass.dhcp.asu.edu -port 7001 -long -- zipped. Anyone have any pointers? -- David Bear College of Public Programs at ASU 602-464-0424 ------=_Part_41955_25438485.1223060244849 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

We have a system where openafs has hung twice now in the midst of editing an excell spreadsheet.

The system is a windows XP with SP3. (standard 32 bit windows xp professional)

Remotely, afs still responds to these commands

/usr/sbin/rxdebug -servers system.dhcp.asu.edu -port 7001 -version
Trying 129.219.56.213 (port 7001):
AFS version: OpenAFS_1.5.5200
/usr/sbin/rxdebug -servers system.dhcp.asu.edu -port 7001 -rxstats
Trying 129.219.56.213 (port 7001):
Free packets: 1523, packet reclaims: 0, calls: 17853, used FDs: 0
not waiting for packets.
0 calls waiting for a thread
1 threads are idle
rx stats: free packets 1523, allocs 43722, alloc-failures(rcv 0/0,send 0/0,ack 0)
  greedy 0, bogusReads 0 (last from host 0), noPackets 5, noBuffers 0, selects 0, sendSelects 0
  packets read: data 20763 ack 19909 busy 0 abort 0 ackall 0 challenge 4 response 0 debug 2 params 0 unused 0 unused 0 unused 0 version 0
  other read counters: data 20763, ack 19909, dup 0 spurious 0 dally 0
  packets sent: data 22681 ack 2978 busy 0 abort 3 ackall 0 challenge 0 response 4 debug 0 params 0 unused 0 unused 0 unused 0 version 0
  other send counters: ack 2978, data 45362 (not resends), resends 3, pushed 0, acked&ignored 2322
  (these should be small) sendFailed 0, fatalErrors 0
  Average rtt is 0.003, with 1434 samples
  Minimum rtt is 0.000, maximum is 0.016
  9 server connections, 0 client connections, 13 peer structs, 0 call structs, 60 free call structs
Done.

But the windows explorer shell and excel are completely hung. 

Any attempts to use KFW to get new kerberos tickets fail -- the NIM just hangs.

Any attempts to use afscreds to get tokens will hang afscreds.

I am attaching the output of cmdebug -servers pp-kcass.dhcp.asu.edu -port 7001 -long -- zipped.

Anyone have any pointers?


--
David Bear
College of Public Programs at ASU
602-464-0424
------=_Part_41955_25438485.1223060244849-- ------=_Part_41954_17327440.1223060244849 Content-Type: application/x-gzip; name=pp-kcass-cmdump.txt.gz Content-Transfer-Encoding: base64 X-Attachment-Id: f_flv6gmju0 Content-Disposition: attachment; filename=pp-kcass-cmdump.txt.gz H4sICElo5kgAA3BwLWtjYXNzLWNtZHVtcC50eHQA1F1Nc2XHbV3bv+ItbZfN6gb6M6skdpKNssnC WbhSqtv3Q54Sh1SRHMn690HfvrJp84BDjqm64NhyWZo3M6/VjQPgADj46nb+9jJ//Pp+nuY/r1/1 v7t/mB4+3f/L5Vc3tzfr1z9MHx4+3Hzz61/uP9c+bV9/c33bpuvPfrT/puvd9+vdSz45T9fXbZq/ fdHv+uP9vH3zkk9O84u+5rxev+xztzc3L/ncp/uXHfr72+tPHz//71w+uUzrx9sX/dnLzfX8ou/4 8OH6/rMfvP/YXnrd/aN388NL/uz/vFvX6+lmXr/+6vZzn5UH91/rw39/elj/8rmP/tt2v9y3jw/y u87Pfvbh9tv15j++X28+/237qb76cP+w3uxX+tnP/s/0w79/2l702/7hw93X/zs9zH/++ivts7/5 zeX33Swv8lXvfrz868X9xdESV+Zy2W7vLnQVuRBHn+MVuZjpyrOPMVz+NN1/ulqXT//3y8tff/iS QuZL+/Fhvb9c/vDHy6MfdLncrdt887D/ndt/1U8meXHHj1+sf/nuw5384vHz7nL73Xpz/wt3+eHu w8N6d7//05vbu4/T9WX7cL3uf99PJr/kV/LNlfNQbdvswHkcJTkPeefgeS41kM/4PP7E8zRaCz09 j8/yf698CDkwPg8l78neefyW2jLO8zt/Jf+V/1z+9FcbvpIHPV1f/V4w9O9OcyEXCjwN5787jf8n TjMQ9HJ3e/vwwtOURGt+fBp62WnkPPhu/uE0/8zdfLz9JL/Ld7cfbv7xNPOvfyt/yLT87vbm+sff Xj7Kpx4u30/XHxZ8yjk0F59ihOeUxaYCh+iVN+ijC/beYHCUp6fnSU7O5FNkBSEuwdWETsM1vtlp FvnE/HB79+NL8aEtWwX4Td47uZvoBNQwfgcWXDF3Ny24JYC3JngXBt5hf2T1rS0tNeBfu+2UYTsa fpPz8LWdfD+xJgf8Kzvu11NYgQIdwC/nGc+WU2s4+Ekj+Cn4ND36MXg58thiA8ECp+LGY9OMx9Vq MFgQcJs8eGwCbmGAm3I/RJGU13bmeUpZ5oiC09jBQN5bwq6HiiviY+F5+MTzzCm3jN8bjfcW3xe4 CRqs+L2V8d4qPA9nny0G21G+Nz3FN6Yqp/HFK67nGaxOp2G1YJsDZ+lvLYy3lvBp5APJYGDQYpk2 6EjjcKQ4bnvuct7uOK+OQoPLIOuWqK0eUdv7AoKcxH88PU+oOw4QkeJHqzOZdAuuMUjgBNdoJAmk pDxy4GjwPFS8w360xzndjyr3wzkkhbQ6N26L04T96JFgK2Ag5kUWsU0ybJT0CBykAQcKVhuFA8Hq mID9sMsDq3FYYBOrZ0kGNuxIj4xUCao5l2IwqG68zSjpkcdWxmNTjMdokiCZpbiZp+wUR7oqAnDK 7QT5eczn+DNPMy01gxRBTKfuphNezxe8XcbzWtOJTuKcp4dh9ns8rXlRk9zH0sJWoc+pB1eggBr3 l2jPbLIkCIxCtl736SGbEoEKhpvkQSP5BbnQ4NxANdXnSMxm7zzVu/kR5y7fMcfAV0Ec65WvOSmo lrwk3fZOI4FzA7dDgfcEIRethkAlZYPGE9ZGwHjE0kP3OV6r79SEKyJvCWyvP806J0SzxdRJ3RSr cjfsExsMPiVeSyAX7UA9SDaFNLQar+VtqfNTJPCuuH4/qhcVh6Tl1mc2HEiA41eUG3g/AhzF7zwT FNQzg4LJwdygDpItKUggaaiGBKd6HVppcfCthf2tKZfjSyWDPEFZUkvYdMp+HOV2MlM1SBPQlBOo 9YbKNEI2jdHNnA0+tsBrABE1M4/sQDmNDgT17XDt1YRuqhtwOoJqo8yrETjPoNrbdbZ8AaoFxYMO ei2RVhbtv87cQ1tnqqh0sFfdWM6KYcBTrcVgMN3SnFALIvtRCdH4m2fe2nmGM4e4JPzWBruWtH4P myV4QWjE3whGH5UQeDlyd5S1dpwzK9Z5oxWkBiX02/F7cobf2sUng7ezNF4hl5vdIHG0QoivNRnM DQQKHOBy5TkNoj2+nmE7jy2Uy6mwOyK7I3HTiqI23U4VK5lAME3csSCzU5AtZLL41gSqPULqEX72 Gi92oyFzikr4GU5lDD1iPXwOftRBNOMxmrvRBLGtF3lHs1RR3ltOjg2azyxhJiAKOhwcubUSU5vF 6tZAQ45g9ajsaL2Gz2D125nPF1R2InhszHnP3d5VM45EbBU40cRpJ3NJCXEkZGMlxDmTzBUvyorZ HMmbcjdGzSaueSmovDvI6aDdDpMWE5x5O2XhDYGAi3WMjxUc44h/lQu0dztLoxWmb9kd6ZvWcWwz ZpOgIM2wjEijMU8b3Ql7pdveeVKLoFNKkGuw7VrR2mRLa06LB+MHocaD/1TemtFkVAKcgvMdfySj yuXYtR0fYEBNo4starRhjNVgCX4Ry0FFa8HqMe1SsCcN8hQ1vv3MhGdd44pGY2ufXA6OtPZ2XykZ nPQV11NQx4eYz6ALstZTYJM5XGlBJQRBt7Cjm9oiYXOQL/nZgRb3EvvtdOYQglufN89KV4F/u4rI F702RmyBvLaRjWat58Pma4suzqBrksMYdXl9hy6fRxyWILeAgfpgPpQxpFB9UhzPmaR7iw6NWYoj 5aFhoM3Aerkcg1AgQahD98M0iqMakaMOkF/4vCBUorYFlxD8yK+1kojR/LptkrpAtzMKVqweJ2is 7rlBqENtrd12jgROodkCF4vd7UvzC0pIO+KN5/a+6qM0wSIPueTGKFJVzlOdExg3dx55bw5oY/T3 diQ9Wh+1p2wQqzNFpG8Uaho5NmvPTW9tPTUKddOMGnU7Y9DZQ61jyiZ7KGBQUIbNmQZjkDVws1my 2qgGFOiMnKeXFBU2NMkHlcDtzN7WFpYtYzA4SopaySo4i4FbyVsF3HsH68FWVw3ccsoGneks3hI2 tmU6KAPlPBIiabWec+dGF9TYJu8tjKEXbQ42leQs3s8SN1C7EuwaM0msNYDErrFj7jhlCQF154j5 hGE++HrYJ9Ji6zPzUnE/hOBazOfgQBR4M+p+xHwCGFPu5nPk2dpkL/fCibnz0ASLcb0DZIfrpPW7 E5ViEN6W5haUy8l7O1JtbVKZXTCIB2ldGWptJjcKClXhqThRNShn1MK8Avmfbj9Hrq2wiDH1wRhz 9zOtG2qdCJKwDvejqTAEZ1ExR6KdCoeTMh3UgQJv2XuLTFVh76ECUL0qvhatE1kjEQOfqEIZ5ooU QsVyBmugzSj64qpBz9O20tBQnyDbzsAnp4xYMCWtbeJUVeQWCAXWIxLtiSn2PDGyWvo9lzhwSMFV oIAP4kBrNQjR4uhY5DAD+5H/3atX2tSlyWkrwQJesBcdpIF2Gu9zMdg2MU9pAm0G4kWPJA5PwER2 bHECZk5UEKcjpjM4A2V67OJD+fl7Xb8kaGsrFAwOcXAG2nCfL95ikk0T7HcV1+PdcD0KaZBC7yA3 dx5ObQZRm5jPUY97XxKuyywXgc1ncAZa3Ga1XBpagcqNIQ7OQJ1XjFHrNTiVgo9pBV1UHOPwpK8f SjjPk9ZpWx6Zzk8DV1QkqCavKUv43j9iMBvl6GaoVF/dVQ01qCom6rD/qY3veWUkCSjoMLgpp+ju +5AtUu+1TQQHYPYEoRSNeQ+UNSrnZJh2UN0s86DatOExq1FOmxYQVBP5XcIgOo0KvWRn1O2gsnx3 O4Nq04Caorp26Nxm10pAqd6n3hHWG/fe01iCWxOa6Ym9IUzgy2vMVHLeYkDdvH90nEpELle5mpKu iir9Mb4BPIw7M3vLC4GSSKjlaKrWRBv1BpBzRxLKBBdwJB+GF1XOk8SoDMJAC9MCtWhDPHhQTXDK FYsxW+8ORcOXxfVklPaVaUoMqi6sOFdLj1bQHCphQRi8YdGEw40uEQgTWvDQ39vBtWmtyHI/BrO3 MkvCgzKe6PaMR0WDZFGuTYK2Aqip7oBoBG3asK9N5caWpgkE1cS0CzVVTQBE73uXt3ta3/vGDaSj 4kkHL6Xmo44sthpxqFBdItQ8Wg+1BO6Zisi5FZ6t4WJvOGhqrbXNV4uth5w2vIKjhp39eH0p/szb oTUw6uKXuIBGXKB0fqQkeG6vKDJtDuqe5pCOIoJmPTHZ9KNzexTnPPKj1P2oogQk9yZhjr3q9VLm Ari2UOvoY9F2CBgtIeTJbeg4MQlSe3lq2I0W8p3S+pk56i9C6oibkMNREVGXvZi8no3Khrr0RttU V6XVmvhz0JbXnNvEPxFaLiTYdlR4cAWOOfagwdz9CLbFDHOEsGObotpGhbUM+0wRA/GkFc1hiycN uydViF1m57Vy77ntBcxgxKKjwUG8a6usbIo6Sw5HqMdVcrixEpLe2f5eyROUSOcg3pUcu2ffBjv1 ytzCCiOdvUaqSbTkwBbLCJvrUu5A0qTuZQStV8KkEjLNjHakdD869DWVmNqqvqYgNeos6EidBlIr SJBSyga50NbqgmS3xeMcSyExF+ojmWwPbxJoIiEDQbbBvWv6OZc9pDN4nnXCw4o+jekX/N58lA8r cdupWVxbNyw0EQ/uXVu2brRzqtWMpuH6cqhhPzhPCIJuWh536jQPZwfynhL2sm/RVlr5GFw1+Nzq klfUIi5wXQZca4t5YrG4LEXMZ8LqevEgRN+Xul6eZpdAWb6rIRdVGn18A3Nl+dZSRE27ggVhYAHm QJIEqBYf2+a3ALJSzlmgwBdNlkGPQ/15O61K8suC+II0uFDlpUUXyGD+Jvl1RY1GAgODbdO22xmF AfGihJqNxHKOxjZN3jkWi5sUJ1oCmCGNzo1pEU3fWT5ncatqmeOcUHqdBtkGYY1SqlXRy6CTqd2K YoIxy9OX2ShgkHOMBkNQiQkC1kaPg2yr70vEsbUyI3VnAYODbFNSBIHEaNCNrryuiAytfqdztKFY k3ROmdPjRVCPkGAQbRimc02BlJs5s2i1uTCh9n0/+nVfLxd64r6HpS0b1qyPYy6+vrORpFag/GnP EAYK4NvptXhtQ+zJFPW2Qcspu+WoqgXJYsAmAegK+qbktaVB42iCh0YD0DXyBkbj497J0gM25ThG +8CKWxZQr4qxl998yl5J3eSjmmTOqcXrVjxqOew/dixQVcSjs9hCWdy2IiEGGhKomhqlyZ1JrVNp sB10X9ZXtat55jDntYNKePN4jfffQDrvncfKAA95Yg0FzjSbyC4gsrBPi0msrGnsXgqzwY4PCXAq 3oyQBvVZtWExmy6n0tTK04DA0y6rmUnJ2gS+2eTQS8towr9D9CA/WctCbWJ0a8kh2blesh7nwfF0 qJktSiCL+SAyt5vPwRK8sz2kND3e1ffIfPoQTyYFDXxw8edfEvslneGBUGe4SzS0pjSZtlpUgZkz e8NbixE8t24+g8TRghx5isqmlJNVDrcKGF1Ou6KEPvSiRzlvV6l69dBLCgGtTOKcj+Ttne0gnRrq KaC+XWi8NSUyyEwmu/NymNB5mOoIqV/PS51XeGstIDX0fjlH7ob9DkUJuE2GofOKV1fko/SmDYnY 9KM0wYVj1BeO7I5Hoz6qp2oRDBqjxv3+3o449H3pneYtoCQulE59SLSjiUo8E1afGheE4lFOmqMb cwjaxjHxtBYVc0rnZwEcuNT72agna7gkQkV9bm8n+vFF5oOKo918jrQHwxsl503uU4zVgeUiHd6G QpOin5VCKqz0g547ETtXvCwlH2UeTd1dDM9irBMy0tjteDAmEbTFY9ylRO2dR/4lE5qDc/tyno4H EN88p5SVfnd/sjtFuULHgyOPe1/KjS1NEdFUzPvq6KqJSzzT1Hae4HalMoEku8c4o2ql6ZjEYnGT QCglPMK2vzWDClQXdYvN+AbmmkHD2jLIexKnclVi1fqOn9k4dqbbERCoQHmuxK6T4UtSvA6lTNq8 2KlsW4xw0l9QOgyUVpslTE6M0SzhMfA60fX5xN7SpkRtdR/wMXc/rRFqL+i1hIPR0bIemw2ULaSI SAOJcoZCk1aL477409555hRgCyXncpAg+H48B28xaqMpNwBvEoMe2hIaWpdksf14ixsD80nci78p afv69BiHzpM/XtdYEBS4fY+A07UO5ZcZjHEE2VDnfke2QYdqilPyyywqGhVXI5irqBQkpi4Kt8ve u2Jw9ZMk14xXwZW9Riru9F11Us+pok7qPtQyYE3bbMeRbNoOUpXotjOoXV0CyKQKw5zbjLipfjHj PFqN1GgdbuMVLBWRcxzpqFYZSd5ixy7HFXVM9D6wLksrMPd6md1zqcO24sWDlQa6adQ7ZYvPba7F QzV0CoOa0ugPq+az1Al0vMcR6fRTvavCYnALI+aQi8TU3V9CcOvH9IovpXMljQIUBBPrCcN6NKLa pvW0VCtsMmDeiVB19lpvMni763l1k8FCDXieLng6+AI1gfNR65469XLcMoH8Orp45KMa/WGTdK/T lkGrK5Wyz74oWzi8z9XkVpHWCiY/6pElaGSOTfn9ueYZC1THIyXV+ILgNYmmU+O2TIrxjKxH0T29 xB452DvOtG4rBuqht61Jtel62+G8aZF1dmjjC5XeJM5BW8jjS+ihuLkJi7kmuCRFHtmRkSq8O2WT FbgWEuqWkL/o4Km1kJqKRd3GtCzb/JSdkrup2lE8+b6ox9xRZlomJMy0b1n3JTvlZhIFi9rhzfEG KiIC0mOFjSbZGJlMbuZa2IOVIh0IDipHTd5MMoeJPRZk6T7U70UphTkswSAOcKpoGkFe22Cmorre MlncDru2DS0YEi+ahhdV9vFEn7SetpO9qMOCH/EgcnCIk/vGBIs9h60h5sNzcUeCoHnRTCZrVktm MAon1jOIqagNXtrsqO4bX+rTbLTsQQG2nNRnLwxSurVmONQXatlV6lkdrohB6w4/s/t4rrFh0Y80 eBwtdzPK4yzrEtFmrtIVZuQStC3eJhcRR5ozqMSXfddtj0A1TXe98/jccsi0QAmTsvfksHo5Rvdy zXlZwGSFxGqDM9QkDo1yhsVVF5+idJVElFhTYvA1cTUY4bQQ0YZL+YuPvFrbCFnJ4k47rvOC+HbJ C4YqdVF2C3XjUvzoqVMvCyfcWZAGBarsE7lwqRZL1/LYUHFHsOCgQLUZOEFqgwFo7F1gKEFIRzaq UDkpmbwd8TwFqrcWfxTilesxWkqUqC1ieaY0WFCNzDHal7OuPAN5JnL7iKLruR2eiJWHaJA5zAvP YCSpm80AA60tx+btzClOcAKu+KMQr8WhNqdexHocFs5JgzrUyClfg8Xy29o2tI2YSg91OjmliGhx jNoqqzNDN1qJQJog1nNQh1op3mZruEQ6M+4/ToNr08gco8XrdXURcYdulzJxpOhqBueCliicHBoQ XJxW/JGUauO9iS0OvuRaIqBCxXoGdaiJH7PLFjuQ5xomJHZIlA9+SkuybRYSJC+NqKktxzg23mY9 ErUo/rG0uoAynJjPLhos5qO17Nqcjp83auA8caCbmI8qllEsMu9iPgELNeUjzVaFp0yGOhu7AkTB fPa9o5qi1/Y8JO8tLhub4+pAItfNZySmXoNrm++tyXNDnXoCb4e4hJYqkPcGz7OUpWI4GLRO0lqQ baJb5crLU4q3KzFU1fOYFEGmyS+gm6WrN+4iWprgdievnEEgaEvweP46H4yOxhnYFHPd/IpE20Ko +yYrTTn4GdGPt2OrX73oITDjt9YFzuStKYMIFLLzSjv1uRshxdhhykODz/HqVJ/JwpU4nQl1f4jT OTaQavt7mS3yUznOBJqNxOkM+lBrBTMaE8yVN1Am7dB20G1apx47i9fD2zqBKbjEdd/08OoOgx6z ntYd3jZCZE7p2SgHbZFVX0Wo1UXORDZuhR4vS/pJz4gleytF09se38CcnpHAtEc7K3hvOuwwrRZ5 TMK0xP4Emak8eF2lpmiVaBNYq3j3aD54XW13RU0WG6rnsHhAhMr1HMTh+2rOaYvb8KxyGcShRoQa tZ7iwoK2WUl6eiVPyivJW3LV4mnmlFB7uGAbD9rQayW4VDS1tnM1g92CRq+DS1c1VLWJUp9FOLNR b13DgppzRgWuS24ql1OctszqXMdTGc4ilIPT1Sj3yBZth7etgR2Kvvh9oVVUOpCfya1PHE8ULxrw 0pcyCGqNcA8pWhzjEZimFcI07TCtsDhRfKjBVGdOEa0S6DB90NPvK2ZrIQTUgZxjOpgCpVpl9LXN efZwpq8c9LTy3MZ3MJfxzJVWtBlBwGCQoCrd3hV17F3P5NMCVgx1mYVerXJROU92Yj3KmNWZTbtL +3/qrn7Hc9tIvsr8e8DdgGTz83EkSgKCs72HuyRA3v6aotYZZKsGns0Y7AkCG0YC24J+qu6uqq6u HVUehYOHOGQzgk1mas8NXXoI+nO6f24M3UzGNpYgAbjaFAse1pD5WGx2OT0FFBg8sGCyhowFTdVk IK1+Oxkp1/rtPGwO60JtltJST9ga+DudaWAb/nisYtse5UIW8ZLKPJNCFixeQtYpzt77iUfxoLEW p1DdorC47ZfkLNrAtngW8PUMNJhkGyMPjVqq41YcmLCl+Pu4Xf24FL8uCmzzfgO/NB9yzOOKQGBs gc1QwJ7zBq/e3nbqAdTU7W6zkLYDn6yoD6/78UzNpTkZOl6DX1u9tXhfS8Btzns56J/Xs/1U2WnI fqxlZxqmGNf2om/HoI+lXA6tLIfoJxHKYj/4FYGlmTlXy8g+qeUmTJcRBmpfXWNXOJZuxW7+wntj 7RFF6FasSTto77lDzapNZrcw96TNJVIFg4jM1AoGk56qTPHN1WJuY3Xylv94Q4aOFEp6kUeCzTD0 bY9Y8G0PVc12fG32oFV7yQzfTr7fDt17CRavxIYuDh180T4nz4M8pM9pYtJ5vO/FwYXyNqlderXT JrTV6lEeQ0h1hB83Ol2/Ywhdd8772KtHvK7U+PCg9CQkPR2/tu4EdEZg1J0ZlkFCQq3+2HreQ4cn SGOebRs5niZhZOoYbNtCwiFN7dFF2Ehqkzvcdilwq6JNqppeILX5czt2eMtqwMFD7dIdOJtwsDkh jc5DvRN4yzlaNOwqHFQUt61wUG84IPESXiKlqlfCwRUquhDrJ6UzOFGWFVqdxdZNy09FRteS6kO9 s/RGly2ulMtVC8jLqHl424Z1mryeGnIyOMX1XBDjNuBtEqIsncVoRGB0HW38SxorvvoJkTSTEUjJ oppWokF0O9rADnUMCr7RgPcUR1a6ucfZ92vHJ7rao/Sw+I9i0lZdakEbvtrrTPqd3iFtTQySBpv3 F7oeH3J2t9jDWjeb8RJaegQ5WrT0PPQ7M1MWZ1G82s+tIR+yy2muxbL302KwmKQVekBo4CfDO1od cu+yFroW+3lK6U+NChm0olpL0/S9M7HUaBBdOS+PYim1o7vlHsaI8s5gse+9olJ6U4jD905KT2kt GGzc9u4QJRqCuKn2MHnEqIWql96BMp+8e9Qeaka26T6MviIWUWvPo/awbJbiisExTrHNAdZtYNs0 i9PewCa2ST4PtEGmlXJgG/MfaifEjlqtxDb9uVXE8U5BYVRSdjjJa/dgcE7YXINb5eKmGscEkpSr GAS3s7gd2Xe9e/Qe0oga3RxpIZ/bj+KiV6RulV1cz9HkloXovzs6/jIi6FryhN31+d77M/fh9FwS muDkPrI8YJoBm006Z09aPjB7+IhXLF4iJosX1KIf2IbYw3n0gQWjvyRvccKW2Lc39wd/j2QYNvFK k2bGvzRBgs+Tff/vH7/+8pff/vuPE1MJKdgjpWQWHNLeKD5bbD83LxkUnMHk1JvJ+bhVb+0uTz2R aCUjlmVctGKGd3q0Uz6vXfvwLs/lAsoMjooBo/X8WuvkobQMEC2lm6HOheSyjE0E96cHz/1MBmUp IJLWVz/O2Oh4wFq1mCUa/HKaH3E/qPOcuSwkF9AXcRY9oVcoJ9rxne6CoSMwik2cxcHg6Hhw035t uguYjVIftBqsO3ssDi75ipvuAqaIvDNYr+0/ywUjaVObic6NWdtitlhIt9g2dNXqRrcBB1/LaxR2 97adftN/htF/slPe97+BuQX5cCaUlqGlZwzWo/Tgl5NibWz7ZWVn0LPr2DmVHmsBTUMPFmvPvu8n kBMHtk3xmlHURi3iim0bpqjbdOawWvoy0t7sPU/oAc1wozeYJvFGzBIiwwNrjsuR/fJv5oTvLNvY WG6U93jR0cIgUPfuIyRA/aPuME+1zfy5nn3AHvH8KL00Cd2kGrJvFZ1YVmjzj5iI29Ci344YfB6F AocOcUxjzoAC4iyIidK6K50FOpV6sC8yWoM4WwP8/RRFDQYHS/MYUomoNdDSM9XRRggd/S02gwc8 dYwLOM01P+ooo6mNtgZ7vLC5wD/6G27danDJIh6c5/2J/Oj9uHcSFCro3aQxgJt7nHjG5n/U39LI 34/C9pMoGeoXBhvtKV/IM6VIMAUe0rS9lOq8QUVEhzgUHDyQOt9ITXbhUsrV4hAX9niireXpyxmV lHQ62dtkDDZfkQPZ5TS3x4R8PbF45qheex7yPND22EgOvjPeyeuJvopBS+jR5cAhdPnRrwmnYzRv Zt8v1IiOQvroivj9aNc23K/mniftpQO3RMt3av093JBk5xIt9jkpN+RqK9k99C6jdGzS1doYnNuP lMFIPGxVSCU1eQLqktwBUT3q6NThcHSOlNaE7FkpdCwFNpRxNoBtCj1CWlCjwFbLibbKRx2da5fE BqZlJ7HTnUuNU60d6HkUqB/him0mZW9xbVmRLQrqq7N7yF2+++INFp7q6tZ/HHlaja9BKmFDJfgk BKaXLop0YfThVEaE3ejiHpDFQw86AqVgHaZyRdYU8+ipDcaFKhgUQOcMMJhKDws00dnCossgeukA DOo98wzXIXmcmILFmScd0qHQ491tAhFHzwo4ZqdeOWMfUWAyuhtrl3ctxWyoz02Yh2plLdWZtKAg upE9dc+kuJTqa0tMh1uJ1ntKJ5h5Rimda6SN6NhF64/FoWc7kAc5+fAEtJDXU1MwOfPs6QS2iXZb qodpgjl0arAYq9ezJ4NCmdIiC3c2Oihs236gY1AtjodKkZ2AeScbbJ11dz/8BpOqJUydlB5P0v+v wW9n8yGhxi3kYaCKJTD6w+Zd4n24jvHQ88iKTJa3GYd89EAcVGXKiozSGd+OwefJki7g3q15hG9r H0p3fPnB9ZV9m5QIV7DLIA99ZFfK7U5xOWKTQZgmAxzHMDz+lSwn+ZV9Wy+7x9x7mCI2C9w1OsVJ KxtaTZhe/jH2sMjdGhnltjR/OyUBfehA60f6ZUK29nYG++oc0wk8bjlqb1CzY0PpmO8MCr9aewoO MylTiROKbiZrTynbiSJ3vUwHIr0AY3MxVmeXhvILXM4zvD6SUwk5VhYTuJgzQAeuxv7S4AwS+Xqk hMxCXZfWHq3w2Csepu5LQ3d9sFh79hRPYDNQrPaPUMp2LcYLsvc8MWYBrZuUEVitCPbhwOpP/Hg+ fqInbKhv0yFu7vqyFTKb3kMtPB4nzZRHKWXPYxOpe+kFbmBOforeWzYaebgfwRFkm0IpzXNNYhEJ rnQg4TcnudeX6ZFVfiVyHT21+esA/MdoCuLdFDChp+Vq8d3sY7UNTgi3DfnOc/tKfE7PnrjbyqP7 so04mydwe6ud0KGPTsqW5UtzBt2H2ecAhEX94wgPlkaveJZoNATEIcIgFDfZXRbgmDLjCxajgaBM E0WDONGASQkleoO/tnLUC1QebQxmNAO9B1W9RbCu5URB76P4TGd1ws8T9eeYCbitTAI5ukemCQXr +ghxTEwwevgh1wZ00iDRT4Mb3SilM8/nGSo/2unkqFANDuDGFl6bNGbif2e6XropX7Z9gz21PLIi QWr9nyxuyl+hNHRueeYdjvYAI7U23K0a7HP2JAcqpFp58qw8LH+q1GxyXdFn5GhRaHt0RbYE07zF pR6dSRP268mj9BCoDsVbVBL091YQo6O/tzp/b4w9NHqleA8O4ZvLZRrcEuYMRDuDaNARdp5SEAdy +w+jk5/IQl4b1BLI9nJ9pB524srm3Ye05YpOKLVYbsvRx88RfuLr+Win01uPWMWWR0lgiwk26V3F toAsRyXfFip9OUxXtDn2tFAvmFsfp5uSCT1G2eoreJRULTVNYeTjO2SfB9Qf/XRkaxcoO9qGhtmG OnoFl94UWCvJe4/sbYrTUxlhspVRST5roUSXPGV0BZ7eK/c5m7wUWcuFDnyPLmdK8uRgijgnrIyu 7HKSu/wbpP59mbSNZVJ2IIFNCFH/dutsu/2KSBfRGjo1K5biGFq1uIW9p9BRyITW0EcXIbz7cF0b 7AlauhpQ47WGPkwoawlsplUf3aEFi4HTU+aJNKTWpGy15ypoP0nGzYd4W8E/auH/vMf5cPr2keub ovN7ZGjM8bVWljYz//nmIkPr3j0gpsJIP7tHHSKQetHJ22CH031DOe9Sy+w+CQ36Tve57od26rOg wyLaDjxiPHHotZQYCbp2Q34/CUk9xV4WF2q06Gz74YF4rUVnRiHT45D6egzujYnv6NNpTl5zIj81 /uGkUtd1a1l2eDE6h0fnZWyuzb2Kywmy6upbuR1GTNuh78YvXIA7ek1om09qm6JoZCs8qZq8Ht92 eFJVe5upvNEgSptutjNtJzpI7NPjcv9aBqMjKNZi4WB6CtixlFS8xZqzp80jYbTM/CyFNpYTapMt bE2xGgRRDmq6CQkJ1QKaLMZKxBH+98+HybXoeOle9b9R2Crf+M+nPMpNR+ZQRN55pl+//U3/dv/z 7S+//fVfnin+x3/qP207/uvbb7/8g0F3QZmuA7qn6BvZ+phN6N771eDhPolT9GWzXC0mWYPewwZI KoXuxyfO7EbVJBuqUNeRCKdQ92jYTFTk+3Brkw/3C0B3y3dkUyjsIumLPo3BcaGmq+Bb8mXmt2XS +JQ2KrK55+npIpaWNjVsxh2M36PF52m7gFX5gW5T9qXJlDa1ni3EDTyPotsjk9IDEFoS7T3O5fwJ wDqnNo/efdhh4NdFbYbuNyKTzjgtfCzSuygsavPl89iDn6HfywYingcUPDIpqaSe31FaCwXbie5F KhQ86tXXUnv2XE7AIejjDI/BCBb/MMu7kqzyCedsypTiPDuHPQKq7L2cVvMGyCrF6UeK+1oxqOdx NuSkbHdT7SL7dMrI5bX3OFs4Nrh86YaQPfQe1lTbTNAZu8vo7LLLdRpDM6MQWrSYUqulJ6JkSi09 j/L7tfgdnbEvgG6j9DyaD1shM2o+zO7CUY4ypQV2stzoOXlJHd7t0rr/2pJjNvF30utXosHZWgBW 1+TzJK9ZV230SFw4fakY3KYfjBxL8GnwqPYE4C0eOI3uvjUywI31BjZHUu2rK3o/+udH+2G3U2o2 SYhmhwjEAW5TXPBsodSmjWo/UgHFVOFgEqLYb+Bjrp6NpSs/n6PnC90k1M9n8u8snMGorK2fjyC7 q/754d+/2M277CKOo5NJWHtmebUJB4ePJ2IQtfxM/xEJRh76STDoP9qO2vH+cpm0AUug4pzbuswm HdR25AkZZLXkkpmLwqY2oj3oDoz8zZXXnNhJ+XfeyzqnuIJ0Q1yogvSUERKz7rrAovjX1lCfwKWR AdKPjEBX+2w+T7ounEMX5/YYzdw1OsCVuANrdR3523ciMvHvuhSLwZ5AckKbpNqyTfaQuamM7mGX Y5wt//HX5usgd7WSkjs9Xssr66iX2qvThSNN7ssc8R4DvlLd6fm4UAsq9yHc5BmbY/LinUJbxPFG 8VESWO5h89XgywmbO9Disvaf07tH0t590b7B4IW4cz862rVo95EeLaV4PJCUhSnYK7f79n4KOtKj f86zn8YfTyilWJRGZMAx8r837UF/YuN/naSYjuNAzimtOm5WHQwEUnxjnuSVv7Ry1Y560HlvyAnZ Wr5T6w3G1uuIENHr0a9pajyJXSwvYlEi3dN54nCj+GgiTOMxykvtZwBNW863NYdGhr4zjuZlUNC0 L4YBm27oVTrDBZbyLtSzu7QBrbWCJaVRdOosOmzdokSLPU4/pJEeZ7ooqQXe1WzQFdq3KMhfoH+a DTWzwZtcwJReAMcW3Ywy+fjhsaXDwVlxIlh8tB26E2dSe9NuzaE78t6Pbu3jITML98njCdP3WxgQ HfSvyVzQUmXG8JWxpz0dCbUD0vxUedPXchv2diYkGwS5XQVacphJIiSLWXpHqQUaqcs0UrOtl+jo cLDUSJ1LwHds2nSAkVhar60RixBfuiW/yYE6NkkyK+jHIwzWTaJH3z3K35f7Ks/AArZOajMYcO9n Q+ukigVhYgHub4ILzqJDQnx24EZX82Pnn+YXWEw51P5GcCpgenQdZiYQZ1J8l9xx4mmb3i/CSI1U 62IQ1o6+dUROKxI8uijrP22+n976BUiCgQRxIgH+esLICzJ4S2BPx4ETwdIjHnwxb146UAzl+L09 ShXGg1xas6gk9pIbQOrxe3vYdraeGGM2aHTXB4hgfku+Pt48ZmCxadUVd3VgNWx+rPSxlReTx+AU CCoYdwYQTDY3EP7T6PimhSeTcfRh28nbMfo8fUswJFTSXH5jF9dNuqW0nz6BZXKg2kPnsswCq+6i IwA3zvh4JstG7la86HszeTHJXxH48hSlHzsOS/ywecEmauMMDO71dk36WlgA3bDoGqyh4s8NTNfN D9ckc0qZZKcVpB3iQKWFyRmymCaja286HTS0ljiTqQeuEVJKfPIGn2dP/UCpbYpr09rODlYYvQQn W9uQBF/vmLMQhd5RNHqAI50ZuVpHOu38fojP0Elki3xL308VtDaqQJ0nUJNzL7FRk+5aq1Q/ADk1 4GDShmzH3+g5HoWDgpLASs6TbMOBH2Z7aknHCZ4naKkMt0uCXK1QtKCbSGXlcO1qekNOfU/V81r5 dVBoxNWqLVu2+PWcR97QPe9QxkqFxELS3QeOO4O/tkN7A0RVK1hPKpQlZ72zdb0YDZBfaqDBpA7Z SGrV/7XFE5xVHWg9qV22Bis2qUPp8taf9x0NQpM6II68HT/qrEGH0eViBPqoz+W1jZNWH516wspd sZYQ565AMDlqdiPFKBBEt3uwvFPHtei7ayNVVH+DzeCQoDNpR2KvpLkvSlzU0ykBH0fWKfHRC4o3 rHcNHe8GY5p3viWD8XnasTUov7k4fa0koi3E4FmPs7JjC91t+ODtPZCOaDPiytHe1KCceO5HBoRO aO3ZdSEbCCk5T5JLFg9wBduOy1Tf2Gq/0YM8PZ34wFALUxQh++PZOZNbsNXJW6fu9xan1TzmHba8 E7Kw47BLsa2F4w0WfD8wlEcsOhOrWM3xCi3Lak6WkhALWkZ+hI+FWnKMpksdW0AYrXNovudQEi/l Qx0jt73fWTly+JffWXWGf2d/KKO+OaRejy2LCWzElqM/VUbsrjUc9oDNx2UKpGyn98WLsyhZpUOg MOLizJ8k8Rg+O5PEe5HyVvD9/RtKr/d5l4/NoiF8Xgv6b3xDecxxP/7m9I/5tUljzpwX/fIMtgYi 5UTLo6746Q9n7hwJgXHVS6WesAXEf9T7zEOIgkP0wgjZq7i19m1pVW0dhOiNqlpnVcWTqf4Qx+ac ufWXo9cNWUC0Aj1SHJYWtV8NFvOc97QjZ5tO0eVhd1mqRHTsBvbSyfQUdLVPO7t8L5OzQNoRyGLw cfpWElogDVKn04Dt9d0bvvaeJ7fLA9Kt3mjg780lbJxw3uKZhyznBfZh9Y/1rqXs2ykhGWR1wuYK XEqYWO2ZLv+SmrOYXNDThfxgA6sfJQ5/PKO3trgLp1hdUEJouS/GDqymSQwmTfyjnwZeV8WBNINM 2NKI0d5NK6mHPgOpjw/ka6W7Jwk7+n7uIBOvnwiBg9aCxTQw7Q2Qa2+01vFurUkwS8wtN4Ob2Jfk jPTFet/iGM/Dwur55vJSAu4MOAfoXizX1o2gdYhjsjb3c1O09igqtNy3SQdaf61Iht6OSNDt8U2w FTKb4Y1SNtS71eJvOZsEAXknLjAP79qrVmdFxIE2O9NtwA4QGi0+23V/BujzeTzJrJjatB1d6URx 6PlueHIlIWfvOFvyOrdB33LExwfr1EvpElmuxDuxdoxzW0aDz9jqn7Q1g+rq2aCwtJJ6uK44SNEZ 7U5YEMVpaQQLVm6Xa6fjkeyjnU6dnQ7pREuKFn9vitUCOp2B1VOfL9QiavKK2p62DPBgXLB5DONf qzUo+npQzJn38yocS6HLNVtcWzz3wwNHspajOt06BN1a9MGgsN23hC4tj+ozRVO2hWk0CLmFihpr bUTzbETZr801i2OciGS0DePm8QpPN8y19Fj0haSeIgIDd7+fUUxxI6pPyhS5pWa3cGqvA4tpnstx JLTJxxZZJuXSRK20X9gTEqcnpHytALc9tR0ppuU+C6fFVFhz7bwY5EH0O8AKsMirz0JWZd8ZfNrC GKq+d6D+hiG/z9LDGjebQ2k8ewWLv+KSe60tkmw9q/x7dteF9v/vqWcUUtznxCi5kQ9nJb9b4nEh flerfpjJoSzn3QW2GLey8KS4VeDiDU1/bCOxGs8I2nP7YhDWjn4c+NplnEYQcr7C6naPbEPn/TEL JIQnsYlpiyX/+aG7P3OaR9DMo1hQJxZ83Nay9BD2WRzKO6v3scvRtDE2tAwftrnXc2olBdgmzs8F EnaZp5VisWfTkbThU7FtKr9fbGO+SH4bCPK777XoX7CmgO7Fhfx5BsR/yzt+VBCxNwB7ukEK9VqP zsHcO7qG2x3PcY+czQqqzxbDapuEt1a3f6YazGQ6dgYmDUcz+YRW6nF921ABGpAw5VJmrFQot5iI ug8LJcgVD+HJCqNGRJOST/WSI0C4Np7t49eg/vxsrT+AcD31iBfO4yMBkx7OaBUSrUIgGUT71DCZ RHarx2iMUzqdvN0m+Y5wrysvjfz92y9/+/V8+d9v3/76xwuPQ/FA9b7iqYWHpVGFlC0eJe1bQ73o QOpHzSafjX5RFlPsdZJLYDlbkbpOpGasThaLfYH2bQHlAymqPWIpOyDtI2sM1toQRYCLt4m85sz4 QwoFI8x3FRuqQ+n/U3e1OZbrtnIrs4KGJOpzObZs738Jj7I8k0a66mDOvJ6I8+MCARLgtnKsElks ViUU/1B9nEBAgnr0uaFpXSsnCelIn03Sf+KzfLDQMbJjoW1GXvajnK6jGNJahtWmr5VYGcTgfSG/ yUoS9Nx7BtMdcX7OrslxREJk9kZrnSY2j/d52jO7JmAWx7TeHphdEndkDqa1wFTmEI8jfVNbNvnY 9AMnYKdnmEgWlKw6bcbTIaWRv1cS9M7TRO/amNJo6Xrs1hwcwEX3DOBIcROjs7h+qS3bhs0C0zNF YMopm1OEMR5FIdiSZuI6G4qYjO5TcEMGJwpuZSoliNuEr0mYjc7K+qZU/TejxuBehwtC2+lcTa76 yt5BYxCLzPzO9x3Sv68yeNtL5zoP8I7Wm+kYVRv50lyIFlet+lZ3wE0PmH7mISyVQ6pJWMsJhSr6 UtwUuAp7Rm0mJWiZU4Bd4Hh25iyEUqBeWPzYYg/Uz/G3/5EW5FtaEEnR5hXEDRbVfQsFOiJLGYop NjjgwFb//gDuxRvq0M6yvqFzcE38Mn7UVC2Sa1rgBOR8KHkmYDOK/UU+z8IwqL5laNcU3ZxRUalh bRafnXRurX+FAf3c3p7oxHUiwxKPDQlam7hH90U4ghyKRYsmfWwCtmFIcyxV2fxDWjX42JxnyCiS 2MuzHcJaNh+CQc+2S2RDe8r1ToweCM1ez5xs+jrXBPeUo5vjHCGfW2ze4vxD25wCKKlY2mxziLLI ZEfdU79wEFSas5zKqPbWLPo36rfmoE91dJPOZX2BUTrq6FoSwL4gT/qTTHSs0lHlGn/517tza3R9 yKwuiC1bVIHqy+NRSqy/CRwXmU21r6nZfHkSjukqc3hQyM+Tco0Gz9MVqFHcpWS5wYAE2RgNiu1b x9DmJ9MuDApsCsLDpv9gMVGYa4nMgr+KGNyCPfp5Aj3egOo5OahM4W5z7a1vZcO9qJ+UIc1+uf8I eJ7vk0b8SVpKamiyU26GzRWilxw+r+znWZlgcZ5+R1o8f7vL6NPD5J8lWrQ67Glv2MY1PwQoW3eR ZLFJ2Hs4wH6IPj0zNroyjZTFuNhTrggW/GN9Op63n1FZ1/GksBdg+1OLTDkOdTHizhgrK9C4ux0v w4c8X1Fi0lYkMDp36fL4ng40r9ZX52FACQ6MIBuDXNueEwyxKPfe2xhUMboglmYQp+vWUMeTB/nh c2V0wQsoWMfrtnRFHGo1yA+5rYre1X6txIKjXw0EKY439OF1/y2HttjL+Qmqf04PygfTf7+Y6ax7 cDaJDW2KuvGV1ZIoO23TimnvUlFKnwL0w+ayyiZGi8sG5ZITLBvE26XRh8zqASm1GsSA1HMC5c2o B+qsB/DnFqo0NgxZqc/VviCipUrFtIegpsMdky6afc8nDLnMM+SSpG+86gvWaQmK/tWfx7vPzl7x H0nLNYMH+Y2dvRFCimxbnctuwDVjqI3CtdbTBckjFK6fgQjdHi8WnQ1z6BdQFLQPJmB78b2t2wnR Sk1Acq+iWpljHRJtZ7VS00tTEPeplybclwZPeKWkQHaRv1GE80eXJsBV8Rgeqp2pJVuyKMMpqe6f pm6/cFoGTr9dS/8PVLm/gdOiBRgSfbgic3zAVAUvLFsXG8rsoDDwWmxPbTsZHwyCtJIknpV7YgoJ HUGcQkK8IYEas9k020/tRLJJRew53WGFW4wmIUHbuAONRkd2ww1xzP/ct2wxiieJu+pXrsD7D6b4 eEEWrFs7OOWoyNTDPSsUbyuNF65QiBwZjXSaDC1OqIHYEvyIiWbDrkTozR0B0WuKaPlGNMzkJn1r yXK1/74K9A/YwsNDsYci2py4NXyewY5alBb1PXboGhHDnBxE8rn5Ei1u8oazOiT90oJgykDJCNFr zW3xPFWvz/4VocOQR9z1KHObbBbNvvqeK7BaCJLvvcrAPMJfvDrrBiGbOwUNqRTZboqacTlFvzQy o1rJGV55u6CAug0kCDWT9aMxQxSDN+c43IWW3RSp51yHxEDaRWrvYF5ADHOEEJnoOHqLMsO03yaY Xwxkym0hEQrzO095vLHmjnPuO9oVlUGA3g4fpBEds2yD9vpZXPFfGUMvH3RSZZJrT6k1wLVrczCM LuzpWH+DwznP4dgDNGxTkhdZboj4ZtGR8Ty6IO+VaVWiZRkzmCzZYomjVUFFz45zZU5C2HG0oLb4 6qStoV9HX9E5SWTh0D57Z5Bz33sU8OqMV3ROdiJbPtB2x+B5qm8N+bdrvzOXD+ik16ZDuGw1ojBl Pc80Y2sE3UosTNG6lv44T8QXKBzMGQ8eJIQilcHB972mf1RUb6jnkVafERwTGg64tnd9+uY9JnRl zqwiiz/g12ex43kAfsCljHrn/cLt7+u/fqPeKc0lQFGlcL9AQRyrd7jWaOkLtF0dIXYoigol5vdd m79voeJtsnov/viv8npoWkdmVU3ME2P++82tupwSkIYlVz9Euo1FbdAfxruFUolD/yhIftRn8EbA 4IXn9FKcLulEPY/i9DN4Y2VoEovvTj5dd1/b6xRuvT6NUQ6+VYNyqSP6A1GHMbbbnfF9yiCsUx7v Z+5Aq5/CXeHoc4NpNu13ikWRUTq3K4ERb/pgpY1J7Zf2oSdya1dAe+ZuNICvMqHH4j60AuuyAWjP 3I3EV7o88q3MnefSjwaFNmh/qhCQSn5baOjXbe7tOcKsx1Lis35Ero7RlJAi/jpBV9C0K3hf6NFM sKDVHVW+vqBhNKKjCmVuP1ItLrxl8QWMeX35IDhgE6X3VlB0pbQytkI8Iwf4WdK6WIB21AvvueV7 zy2xXfEXJjIrJzpHvy7ErOkL+sxDIURHBYtokSnsu9tgWF2UZx5KlR7FpCVj9AHxAnqSu4hmQhyT 2ohTjgB66RQeRd77oLbOQiZLQr30WEK8d9/ZxMBovPClXRkyzW0yVhFDDWzw3nJ1Bh1k9i4BaorK bWUa/NvJ3Cud5XYHFxHHIGeCGjuNOGewzTmOAIM19NG5x4eZkbcv9g3WVtJhu75W0nXs7jGPhRcA /ferm9/RE0g/QLhGCmli9ftjg3VYrZcezadSqM+sADduvsiYxJn73LQNbR60Bdq4sTEBi6/1ZeEL GvcOfhVJw6XIRUf5QW2oLYJAig1V0vqCTok+ieD1NRW2pbNyce/cd2Q1K6484VT455FYM5sVrGx0 9h7JrCA+M13GRYnLBgucvrmMC5zbj3EYEr3Lrn9fovDbAB1z3sDEsMbwUTPNQPxhcmKo1Q1M1pHW 3Kxu2Hqbbyw5cPHyRAb0TQrtGX0QXMvRZORm364LrB4NIJhDQ/aI6mmKwWJ6vP1olarJWLAe7w6+ PsPSPRJgW/nuXEPlhMaGbXhlhpCZ3Z+It2g73VOraAyqcBAmHFCvWZMuGPVOOEWmfzPNiTnqJ61B iTJ35ecWzkOAMlfRLUx0Y9K1wYDa+3UkHyiPIt2Roj4kdnlerIqvjUS8Gth8H2A9B6KJxmsIS3xd yxS4K37dPKjDPYJt6nApUTYxc9N6B6YgKcDFCXBkLmo0J6AkOZDbgj6oM6KGxFZ6l7MzCNhyxgwc WMQN0ZdviWy86P/GMbJtJWDvPQkya1ZImBMelvr6Y8zo7P08x+FhRI1enzyvD6mvRzKCQYjbR/YB Itvu4+iD+o9pDLcrIlNg/dwm956Y6WzSSsneeeKREFoPr59pasiY3aD/jcFVij1H5EHtS8mPKodp QF2yqMpJCnB4rpjv8jqxTTEJFgu4cFW0P57caE61HiXGGD+qY5qpsJbbkYwtNNszuWK3x6a1ft/O E0zkFd3SZEUTk4MmsZj3JrlGwL0lcQ9XxVybbf48csoOIp5SGxGWPhdioBmSCFvqXVm6Ra2rQa8d 7jyxEhkv+iI3eeVpFAscEh9H5x6el1ljeJN2oFpYNxTApVjwEKNs1yU6ixp3rQw8IkZLuW3mtDIg YuosLhis3LY9ZFCJ5ir3JhKNEOIxsOtklPqpCVqA1bvzkKLvLygv3kRCwn19d+J8d8hxYogWi1At CxoQfwwoeGg3wormHC2m2u45HehzUyiIEwoIaa31nMWmtOgH1YHgaCz0sorN14jZthL+/qro79CI CmTIoy2luQH7vmBvndA1uusCdVsZE0YtUWmOujSL6YI91YrW+xWsJ8FLLKlHj2DyPNspyO5Y0e1h EJngIDsx2PSkvSGNeKv3QDsoxrGrM8yczB2nBIeER8mFOcIi+yJeizaLfHXtrQHhkQ/3wFRiJcmp KZcopNRZGZZYznAhysDfDIiLgW3Cpszmv2tLgxwQ/a6lQb5LA7Z1PR4eg3KQcKUD7VjcRsFaiTKs 1stjUXx0HNGDl3S8PXM6wrzPfaoWI5J6dyfK5JO51BOYY8ELufg6o4+9V4f3EtIzG6GBKIoj9n6c 1joyYRkDk/nyUOURW/L336ep/BMo2JD5ZBI/yVB2dfJgsOz9OtGdaNk/jPZ62GMwE2cRhRACbStT HY5DduTprv/vz1kCS7yv3qTJdt+OE/OH+ZklEBLkxehqbWVQoAWlVgZzssgEO1rTWVwbKb7s4OlR dAsT3ZhwLzEdYlqJbtqVHshSMzo/6XfqtN1Mmv/o9alY15In/c48wHwcZrbmzqOF9YFk8Hp73Lw+ TPfKN+XXXp8uKJfL19sJ3VWmFJWSk8Fi5zy9g14zNwOvfRw5TsmxGDxOay5BBt5PBp49pi9kLWuH cTVhH4M8GXgW+OJTsKgalx4OZNfYbl1yLmSbzOvnyEiQxW1pB5rK8fjM+RU7j49Go9VzRRpeBes5 IKGOpyEFg49Pce0EtZvWOjeHmB0jdUpmpejKVkFrA8HLi3ky1plpXlOzqGs5ji0iibVen2eiQIO8 s82JQj+wb1ueREhmIlE9qUF4S/uRABy0endyoZBV5jtT1WBtIHJ2ENzrm8Q7xCYwFeKLTm6t5rXv oFUYaP1w1kzm1rJFucG2XygzKd0LF6N2Y5rXXC2KQc7zRMGDY4FkQFyhCvgULG6aH0e70HEUrCcF z1bNjYK1ltY7jkwqk6fKpNZpensMfm7h6BtIu9XKeSxoS0rE8kzRbTifmEO33ktBKlEp5R6R0LeU K0HWmYamc4ufrfd/GlL6D2p7yLxaQlx3jJ5yBlPFgQGTq2bxQkbJHC3YKg58KQ/Zxiqc0qJBgdtR PBorxpZui02q3OXa0HVmIPreNPythUnsEoXBj+ijRSpHv7WA00TKQ+UwQYtzFqkcvQHH8V/iwzve IQ2zFmqsd/8F5sxasmSU3FtvYaivlXU6RjuD7KKAWsDHeyaSA3Oje8GCfp9v8J80OoIk79rotIeW ojLxZJFmU2iLQFc9oG3ShoHOREwaH+5nTNiEaib3vi/a9ev86Pbe4HaS4vRDsrE62geLPgbn6XZY 49xtmwIFySQXMbnOk2UroMQRH+tHbYmKWfL/IID0Dyip0AMQSwxK6jaZYGvyvvG15ZUq15435Dsz kG0yuixX1ajLUd/2AzbVsTyMLoO22wLe3HnKMYzRAcUmz3iUFQbBmdSyFP85UuDXAszIrmAWR0uj iH9jAWbPR0fFQZnZ17Eyr6OQskW9XqkeCnT0p/poeh4MCDW5WnCH/Y2xD39kh+rARFH8yBUYdqi4 EpUYXSKk7tLch6OeMFfAhYfUJY2PUbzW4i2DPk7xuj6kLrV3TRbVYAoGGf0+WgJN9RRzOXqxLL+2 86louXx8bw+ByB4gqwTi1pGOX7+3SSAWpjDIUQzWB1eUE21faj165z/QvRFtjiz+PuIc2mBOEh/t OykSigSL9Y7CgUfXR+FgehkwF6qgz6nBGZy2CwXFjcR71WLAAfPRsfn8aLsQHGwX6uR4C/OpLDkb PM95OgfbHz+X/Gi6TSzN4GuqKLZ/Uh/+SkxwZQaOMHVbacOgytxxJGyZgHWdYI1/nqGzrGSBea2T TkWWjgMNHlqU6VlsKgx69w3SonWGD9X3Q7sWjn63LQPx1IC2SYsWpj1UKDA4Kt2LO6EXSHVzpkCG pV6hzaIXSLhSxZXOw+ywu2NzRCJdpHwVTNxlaCuVzXtyshiBHbpH00Uf22ARh5c92bkKY93R3nkk 1A0LKZObDw+5O2lYj1t8eAoKhRkPz8Nas+/NJuW297YDlndg9WStWYrfWIozKD1UrK6IQlSsnkJX 5kNltE0IV0O66nTXbQOr2YasMxlOql3cQa7PJBGFKUOrt0m6nQXKDap7GHiantAsjkz7ngV3pW2S okzd4muzaC1+FYeUVOP5mUNTdn9yKhaVu/r8INfAcX8mKSr/lqpS749Hyr1S/UNaU/tdZ7Hc6SWj vjTd1Y7CNRG9BpfF4utz7vqYgkQ/H28jqsS+thSbxddni0fBfhPtoeCJhCJnahS2GA0ESyji5ESF NNpGi1G90zv04k5zq4fJeFP1wSTp1hyY+IzH514iY2igDaxjUURL8z2Pa0MkVbhV1i6y0joFb3HH by8SkZuOvj1zQsLsM4waAPTcChYgtWeiQN5SqdEkGhzb5+vzaxEmuqCHKpFo4KvEYpA46Kl4vMAc J2NNxJVWG9O9hAvlWujtmaQos5swqn2VsHmkg1ewnuNsIrQOWumw27NSrrP34DEJ3x4SnnU+XP66 OL3Yo85U6kwvfns57of8fQ0fZ3XiAQrRdH9ro9ChCVHeYl19HPlAXfYY+05sY1Jeo3Vo2zI01ro5 XhfZsrwWqMngik/XLg77hLXJ8VZS6BiFAv3cKlxZcvEhEf8xJWIJDcXC6FM6SUTm1SIuWLR13Nrp wLp8zc19jFITI7XeusoCopa6Bu7lhE4tyU1KlM3mjVJu59Fg/F0o+dYlN2bOUFuKBgs3LawLCu1R NHgoUTbxselfrWgQoYloDZMSZW4GRttS8TsyRU2SH1IHg7X42iyqDbSuRktlAw4mh1j/LZl1dHKg x0e8/lMSc+B9sRqzzl1cC4MACCqFgvTwoWwaZxOq96LtJ4aCh6FidbVNaNOnB+arhTt5dTw9bCVT mkWRaAnX5wCinztlzX+kxLZhli4y/8ZOmZY7De4AJzdZxEqfH5MT+nCFDpqFKh8l0OV5/iOFddvm 5cpoO1shIj8MFV2IoVYAK9vSdtSIc6VHZSC+ESmVL4Nys2c9cRzpAAzVeH0ehpdqko22pV5gzs1t Xz1eHwJxRjdizqNCa5BQhovbeH3wa+olBYvjuODPAlYUYk0fLZOIqFd12/fdnXeR7QruQly1b3eQ H3txTNagybcObKvF50cywfZgirB2ZyVIl02QPtSHoUeusbCtK98io0IXkwUHIj8Uox+m+h+zEc7N w5F8cnPKU5kbFaeq1745147k4vrmTPkuc9QxurVYYhCkMQhteE/o9fm3Vi20xEHkx7g+k3mn0Xfe ZHOwd49M+cf1eSYjVC1uEg70+mQUMqDX55kksO/N5vXpsmVwfWpx9ySBbJh7/RIraXhWevKLPyL4 dZKUuXdF+jeJNrXiZb92pEVWbAs3tv1bgeyKbUgwMbBtzhEi3cH0THC01JH/uE4k0GmS5sovXmH2 Y8Ws4DmcX2mn0/ctgfZNsdo/cziGbTbJ3eGtiaIjZXhWB2bx+oqa+r7TvJ1efrbugVRPPjwThfJz yLpGNLSrI0NHV+7uzTdC4UjSAxOJ60oRmFb5HYgO9Rt7dEYk/zLZFBb0pHUMhOg85zssX9FoikUe tnRfr02s5UP/YLYkzy5OcOsuTt8bjPhWcH6monQt1mThWUbY3Ve3wCYfKTEal/4wsXwfBvw/Jjta r2U0P9B6LY96ja5e2uxF4+4dwLaB1XliNfHXG1htUbBbLgeIQ60t5aHb6aqvTbC+UgfCAn175uYy oz6Mhq1e+UL2rvqZlTl9o7tW3A91JbF77vfWB+Cp71F8Yk9pdpndnsX5cBtWgeU5fKNxhDZVU3v3 GaDBeFDnGL7RCCWjw8Rzz5CZkknsMvdDo6Vb3+sFV0mTn8R7Y2mrzaQnUDmT90DKooBNocCHgGu3 6v5+FszvSFnSJihPevBPExP+NXb3THhhUSa7yywDjWKcFqQOrY2E1m4CkXoZaJ1t8AmSEJFNmP6n h95lLZBNK4Mzd0H+yG7KJXwjjo45tZDINvZKeU4rY3gFZgl+zhIYT3VDublfZz9LAR5u4/2Zkysc UDpsZyJbIVvb/ZwOr5PGqXpnnoFGse3UA4GvTXyZMhBSjupJQyZE4tLt5bpFrKzOz+D3/ZW4pStK bofJCU3q9AViK2RGU7xEzwBKgwHWU0tJvzdxzDpj6fd27CgQN0gdH12izfbSxA4u3PUVCV2DHyId Sdnj3ido6c3I0bVxq+HCG3FhTuIaniy2ItWRt3Stp2OHGjcFt2fyS0VhJntt2ctnCeJ/4hYVq/W1 ZBs9918AD7M2RaVUQPPqQzpTVEgPJ94HR4BtbZ1zbHjXN06Wl/ltGu1Juxai4DwDC+bgp7FdbKOr /7UFvJRQ5gSYRGNLGuHZ9r43xTaUcnOHyt/YlgjvFptPBuvqsp87ouHFuckZsDbBaJO9FwF1jqLb w8ITvYGTWolT+lJ0O2vAGp3wsNakyx59kUGNzhnShpwzFA3mjJH8PkFyY7vyazMXz4gFFGVOSVhg nFE74XIdn3flfwooirRb4uYwtnkfG/N+X/nr5Nj7pzr0l4qqfFDbXZPrPFoTHIjLGco2KYlNrl6c 5e/rJ/j6qBQgmvg/6q5lx45cOf5Kbw3YAsnk83NOsapWhr323ztJlu4VPBGNOXLrMhuz0UDz6FIV k5kRkRH6dpaCiogmrCqorvNO0N85r5QeZnmYvEmHzX4cGZDY4755WDhi6Fq8s/h6tFtDgdKjPi/G imX4GTXV6+cRkCxMapkwDmMWTcI4V78cgHTTvGxGKfhmPkBHPsG7ET8QUG09yWCgvU8NpPXceXke VxNSCh5ChCHUUUcDe69H7ldAAWQlVj0/OhmwWA5v8WN7+Tsgb1r9mBaZSL42LdPR4u7LeR4HsDgb hXrxISxd0Sgf0o/eEXcd3fKt52N1sogSXNEn5DmV09qteFfBu7Objn0ytn+ZCtoP6tv4yY7I1/EG b1+fR0apY3rfLEaUjJ5+2IEYbNW09UTdgB5veUgQgrNrrbM4SvdcO3YvKYsEYTeOSLFYocXLDW6c FN2ynaN226NhMPg4d0Vq6hBmJmlino0mLTL68Xoh5b4enckZBILbWNVOajOQMKpWH4z9e5kwiLs8 aG706CwhG3Vz9sliJ330KVlHn1tcnxtb7P3w2WBl08/NYQ+T+oC4TNZqc4/8OF8vJCeQ2iZIwDCP T2rbvk3Yw/UXPjsPXkjcTo3ihSW2Cr611IbTtvbRDr8bHVCFyaT2ggQRsYejFORVCkhXYNTO6OoH cnbXr+2BpEgliD5aFE2e55mxYL8+8CcT4thUhPfzdSKRrg5xq7K9b9K20X7yEty1+dEWSMLeP96N RZJGHE83R66jAWHUgrpqARt4bHLVr7NkhHlE/0A4zDmL7yduDr59gVpQiwydh2O+c8Of1qCeVSub R07OWtkWXkiIN+988gbXD8orQPwzlLqcnEn6k5dWIwl52NvnnCgLLrVhHD76HFwLgg8j6cLc59Z7 RhkPWtvmNoXWNjaRGuUR230g031psi5SUg0+Mdv+Ok3rb0gKOph3tFA/yBREp3UiH22dwW+tlIYi fPWHXcAhSa/xPnqLvhLHldBW4jg7DzrFxmub8Ed0vYJSHeIKrKj6i7dnnq8j4X/je/Mv5KJXRmCF L7QxoDlw/l/gzkKvnVwjyoFrwzF8XDss49IFZnC4sxSUOzuIufsHOCTjWxw7o/ZOznVeN4x6mWJJ vVnITpV32SJY0HuIpLA9OCjzcraZXNOLIL/9VP0keX9DMrkz28EHtILUJuYeKgVBc0wWk8l7TQWv HbRFibDkGj9DOcw9TwnpQoU6+gXrMt/jWkyuHUT3ykiX50pb66IkY8zr62OlbavPYRJBFI9b46hv TPFRamNbYls/t1wuhOu24VI/+gL8ONoX1Ghwe/ws2YHPLTW/HgdvUbTYciFSwy/s2X6nLygOFAMf 1unRH5tMCEXnVYNf23XkAJxoJbi1hMTunub1ke09Tr9aAndpkLZ2x1l+4idgwb4JofeMItNG0/Yw Vsz12KaO5by8YCOJtshrFirkk0lbwKu9AnI5jH4xcMw03Krvaa4NmVK3tPhe5lSQ09D2mesLjish y9Nxeh6O53vZ0l5nRRfpuHniunlIYxBjY+9nbzXQx4GEb1uEL7tJjWYIhFuPPKoGYXFw1J/a5uem xwclPOjxSYtGIOXAqtKoxQJV7nVZ7pe3ZeE7G4OaOjYtaQ+j+M2SknpAq+NeXFyL/dS/1WSykM4I BzKY0kq9UtaJ32kswWWDBGnvCd08oxQsVoRk8djtQ/UU4D70Ya1IMTAKuElNCUmNXGkLAWH+uq2a NDR7uftCUjAtB3GWA2YrY9Osvrh0QJI06+OIeOZEG6ctvzlAR6tbAmPCqG5L/sHcGlPxLCdlb3WL qFqP6raoEc8aN5t9qFa3ALOsvHvgdzz3hCjFYnW7jnQCxE1CcAuhYkxc1J7c3uMcV/ZgTBif2wJ1 PNsezWJx3bKV4lF0RSh1NTs0motX660GhzUjE7BxfBZIRc3qbc49/aovFGslbdkwlLflU1+Yo/ju 4CPnkX+hsX/uw84YjsYs0H1O1aIhU+muIypBXJr5sEzAb1Wn1yNiRkZhW3ibZ5pqm4XtOkIC96je O8/OMu5Cfc2NMSN7Vcj3ieJh45Twj7pGN+FMKlquVj2oa1oOlt6IONRLtKnUy87/mnb7zzi49qMV JpigurYa91nlaIOTkW/eMP1cdYDaa5s0YwntLkhD6apb9iXEVNeXEr3NQlBQwxanI/UoBCzypUaL 94647JF8P8ojzyGHpxSxOO5oV4COz+gKFvjBhHpRLPpR3/kuiPNtcyk2VGFSvTxvWHPPo+10QtVA 2lpYrm8vLG/cRmivUiO4dJofl87bGkr/55Of+ILijZZepg/omkLhe9FO2jVHivTXjTm/UQX8AWU5 MfxoOjizfDHvLKaR9y7QSVc7goc/ID7uIWaLi/EtjcVXJGmbVOLb4b07HaaGuS8YC7QMPBqW72Xh nlMTZJUT02xuaqAW+zbHgtRTg0G31S2xbsWlYBidMbnhzrp2p9yQPXDLMvbI9e/fPjv7Lh2pJSPv H710Hp73fYXRZuizQAsG7xdzQA+PTYN9vXcShtrzw+wwh+Bocicp9lJRzm1YxUCbHDzqRJ8L887a +b3lnk8EtbdpWzBmA/x+YkxV/jg2/Vv5Lsh50pfmnxy776VjET9SOkFvEB9FG/NhqNWiI8t53gHF EGt5e5gd8nqiHyfL3PP0XlAbOsrbwyR+r+iq0G4PrtPR66z4nUoQ91QqI+J3Am0SckNxT20u+4/y Rt5P1kbIoFDiPK+OIoj1/DwMwjczlignAkK1vC0vBpb8pv+UReBQ4pl+BXN+Jr+N01MbUxWsnwA+ zM7kt5xeEdTqAX0s44JC16yCRUnbcbkLtAajVi9yNDBIJ4hFH8pWS7r+SsR7V1eYEE4gHllCyRl8 HGkN+354v1I6yecW9PcswgbXeSGfDL1i83QvYP7UJblM8h32bpTnEzXWcb6ecfOQamDUNPi4LiQt CNEtb0B2ekwuI4RbPDg7eo0uIp6FDBoVh6cuaNt/dKEr9o3o2WKKTQwyCdqFRnR22jRm0S6UIIha +pLFrrr3M2Enk7LkBYHJdW36hGpXXRAiqrVtLSMwgZ5RvWHyXdD7kYmBuMgS4PQKZkPp1nD1kOAu QpvuH+P44FqtXaiLBs0o9fggm6ZxfBYXxxB4770Y7HSSFilkLxHjUn/QLJ5ULULWWg08wgyiDw8E T5Z8ZTysvefJrgfov+9HMtdorFnoKDfa3VkOQo04y6q6tWpFyF+fpLDuYGvsqNcTj6js/Liz4OMT 9UtsBpud7F4ePE6bqwi5erKKkGJgluh7QQMPyWyt1Yu/CmT1xbVkcexprxL6X0ED7Zt/tEK4K5sz j3YFjTBXdXUFBAotYWwvmnszvRbkZDKunYcaITtjuQSLO3AlFwHmBdmtZX8WB2lSoRNTrZCFS4uF o9lcNjuc4ASR2HqD+iWnboTEFn2t5OjsvHJ67y8gcB1FerFwgbEi+noMvp/zPDvG2sJieVjwoDQn Ft3q76O2v2pcvdaIAbiREBsf5iRk7mn04hHsFRqWZKIStECcZw3bXg6740zyVB5ehJkA2XQyOUq/ EVxQmjwSEOpdYHKZPKV0g+V4vXwecJf1OTlYfD39KjeSGEQ3swQic0E2qXkP7eoo6EFv0qUNJW3O UIoFcpPuDejySBuqtaA+yC55O6WY9KguVzzq/yHk9Ula+UHykj790P4FG33x3/5d/xev8z/++7/+ 83+YuURooLEe3cFCq9n+i1GJ6J3vgEzo9D5dGp1G2JESK8Nzdpoe5qE6BslJUyHqmyObFjosCCPj diIg6azItl6m4mj4GrEdbF+YoHLvrHDgUIFUH/CdVGz9HL3BblS7A+gYGtNaHmFhpL42iylq/b6R HnlcqEOAGBzJJh6iiWxw2SJ0d4MVeZ9msR6WexjVkRy9xeKml08Ejq56+cgiRwgX91FSsWgMVkO4 oUOtl5WqyEbtqK2qRXLk0vsFX6ZLakB0LUNe7Q02pFqusYoq1Qd/JzKq5vOfTyf+Lf/tC9ym4/ws lJdh8ENUYbBea1PjDyBC1OZM64H+mryeDxkCOHOPo/PPBfTV43NbSKIwJZVN30MJsaLrR8vBkk40 0r3lmtm+xc5yEKp21xi5zqs9IHRc4sj1zufRLu0Cs0KK+cF2mPDI5qqsnK+jAXZxLI+0SmRHOik0 Tx5mZ6vzOgKy3C0iM+iOnJxP4APZh1P1O59470qWepeRpUYx0d5fF9gbGXV6YdZCdrKTTxb3yI7S X4jMLm0qeGNl6urQvMXnKeGqvxaCn7hb+5EyEyNvDYb7G7hbPXqBPImXpaNirVss2eI+TEoJhl/G /Mj2mGmoTRFvDscNjlBqZUVIk4TvzzYxd76dePhMOPq6Oh1cEfRTq5V0OntFvHIiowbtRJdcp5FW J4qw59k6+PSG5C2++LTWlZjFc0hjHcPe84wyBlWisp6HeQiLBFYOthpp9FdD24shtcVkCbUUNznJ nVe4gZHG6OAe1oc5AYRicdNcLx8YsRjzg1uzxXmbKxe9t4p1om3RCsJ8W2yuYIVDHwLi1mMzO4TM dkh05rPoF9bv4wVoEh1vZihhZAox3pSGnXLEFoHqIMWy5Iis1REXLL6b0C7S6sx4geBIzNWw1BEC Iu4Ede58dZRt06JMgVh0ZOGi1FAMDnMtRVTbcphK3kAIYO6M/BH2qcaTPyryQnVurScQ9vdDf4vh IHu7nCbY06AteoTFduXi2LrFXhOAU9xfcQPvZAAH7yfKf927+X8ABzm8GvSqLGvBh1mLixTW6uzF DWKDIYtlebbk99fJ9u5djFQe1FjHR2zNcBCbcqpaomBJ4pBTjdsUDz7Rj3hsewoK0b+Q457epmHd poTRHiZCBruDQwc5zGi3h2JkULzNSUHLAQJCtBwsCiuTOduo97u0qwV0A6VxA1kM6vkbN5CUEkDX U2dcnG+OrJh+yJCNGHxHUhALrGW8ziaOkD96bWaTJmi9nmBhYVSEh8yiKcwmoaoUOjJFrHM/W782 VuA+CSHai1yPWHZ4AcV1AZHnqbk0g9tY8UpIPy5zb9bFSCUuNomS6zwhFSwTF3WJtAcfEpPFYhBT zKBU63W6WDk2LOjnaDEiKrTLYfP0sPS8RA2v52ooy809Tz/uEwoPsntohe9lFZTj+I+DYlDrDy1w LIDkE9nB1lLt7wOpk9sMIhqlmq1mpsTkYXt765bBqqkWg0WSsNdjVCx6XBKR554enockYeibzT3t 0n1HqdIyQsxrLGxcMFqrU48XypjXWr3ElcS7JdZU2DLj1lWfGmE2RPTpQXYIx+hTtQiOJnfcaPHc +YVdM0b7I3uLwJs2bpChl2ltr40bOT0ta1m09zglnGdFwMHYNaVBXowj8enP04t/AzjQ0bSidSyt 2A+/wGh6m7pR/XKQOVWK9cGuyaSdhpDe3uOMIHkwactUwboYWE72MEIzOMrp1xZAgRtf24JG2cq2 0eWy0M4DIAfjQl0aPuKTqg1EZcT2Xg1SJlRJWipyZprsxaQ7QJKMqAWtBg90zWa5nC0+TnEv5FVX JI2FBf8buV5f9zTvJxjLC8oRs1uYaGQaCv1jMPhutNkRtFgmk2R0yROPAxeaRQ+kmMoJLV/rg1J9 L85UL8wDLdG3urTjbAnYKAwSD09caWQJqohppXZBYjGx8Gg1AsRam5hV2N6NZv+Qfdq9ErKAT63W ZafhIl30yeRhNrcE6UDsfPR5+QEQK8GPULPFGXu4g0DZePYL343fSzaejqMhDMTN2VQnBLZY9jHs 3ww+j1ZqsNCcYn0QUTyP5sKt7bdePK/agD+Vd2NRjmXhfdKwmTCoKt55XOLyKnEk8lO8SU3iGEoR yqslblk2sE1go2NC706gACn7hcIzNYhRCqu3myT5lCntT+9ngf952ShV7/mrI621zFxz6nZicoa7 zn4hM0GZuRA68zAdyAxcMfedhXYmTI/IElYy5zBx2SK5KHIcANutc8F0lGn8OME3z17PTl2ldqIJ KA1GmV5sT2Odtc0yfbqS0eemQ80qa+8HlO0ra8cVHdydz37xCJGNCVMhYu7lyPFqQGiQhzeIlmkq QNxpcUCvnCgdWVKFJRhPjow84oVGgG8eETJat4htobqMFDHKyhc9OEBxVOdy3CjTjIGzCRikHhH+ MW7RJQgj8sM40r6ImnInNqXXjkPqUP1pH04ETzuhNrrds/X9xArTlSQtVt4zBdUUyZqDQo/zOmFA e/YPpYi7gqKV2uIwmu4Yf6FIfzpsyThBQszPPrl20p8HDGg7fZcbvRmJS7cbmE2QTTVLaD1BZ7rS lniKXDtej1sgdXqrM128Lyg9bIvhYaFxRp3psisoozCMH3c0OYW5csfi2fPsrGslerT4W2fPpl0B Tfy1mdnRq7BbdLmbsLgoq89z+ooYOL12HvoaXqMx11ItLlm86om2ErIsCwC2Zf7JLFr2WQCk6gAl opVtUQiFiHKcmFyGK9Gh7bE6FyxGJWCF2uY6aWinA2k3Yz5Y9yj51nxqPht0eD2vSNiD8hCkbH4r Jg2s4yUBoO0DLagLLWC1wGbfppUaacC0UoeH8IU3T6jZZYZ+7HStTakcyBsoueUNVBi5YxMFLcE7 oJuqcyVhVLfvlXWj1SCB6jaqweQSC4m30D4nW9yAOe7mEZeo1XopXMnqctTTxXZjtyqNzjsAecGo Bg83iqt11INnkbNKrgTg1TJiYdaQTb1aAluO3fl6ihSkzqnz7hnVgO366h+DwdOjUw+hrKZ3hlYD xiPoVWqwWPfTdbTsq6dnsTx0KrVpKRxT9IC10rv0YRIYaWXzLq1H7ygmV9KDuDGhhE3bjBpuJNod XsIPb4Wh6ly8Lwa3K4rc2DZDFtFDQ6ajWETcdLJ5gc5NZpKKG1HS7PB45gu0EwE5L7nR16a1Oq9a zU5PrNWgC8jwMYDyAu+nvIAIKW3KC1r00NUxLMF7YiCIb8WzxmDnx3a7eKPGYPo1jTuJmYBUZ1Fp 1IeWBXfVi4Qjr0dyTiY50lQS2htL7uFGsLBNJziTGnHJ3YPTI9ND1MVAhVO8a9tqAlJrR1ukkheD TffgbLY51xnwRsJ04pZUqGlGbN7gxVPkPEBtq7NrG20OSSRzg6Sz9zjaF7yQF532BXX1Bd9rJj3O u4IN+VGrF3PFEDej9q7V9TMAwYTz8ccgrgjZo51BNbh3Ka+eQTGQPEQTrnEZJZ9Id5bqfLcIQiDq 1IKNWkBunuKySameF4HLSePm0eNBZKFBP0rmVLuTSgitw8wEbT/XGmkkpVoynUi3ZslWIbuKcxdO CtNPGaXijtIj8gOq08x+hMYx/4LqWTT75jHBQ41OlkXFEXjX52KTmZerA6FBnUz2qG7s9XCjza1T z3kWxI1IfrgENpTmyoTIO6uBtAOat4UlNEgUbyspMGujr1sr/x1htQiierRar/UkAocOzRFLHdnJ 9VynP9H2mM49U2hQiBmQlxItwru9BkL91of6Zc1OLMwWee8a6d2RUEer9aJKyfnxtUaLKz0pZYS5 peQfsge/noH2MOH73jjM3FFKRxv6XZ8bExpIEiYL2zsp3AHsxdapMxh3KdOH2mx1dMo+sdOZPEwp 2Y31NVoEqc4rE6vN+jDZ7P3YbK1L7A1+bvHh4ujSlck4Zr1LC0wn1MFz3aUYBglNbMqrR545nhQe QoG4itdULQIHUYc1BLq50uZSnCfkonapwlzSdyIHJZzlF5HoP2xNvP+RCskf+mw5tlqwNcnnUI6j mrCAaxowbXNFQeefgvrRsNCdRK/UES9lsEM4r1qADn5cQYugJymSVt/P6YpH/XX0Mgn6+n4a3teV hHcJei3YHm3HacF+WAWGhRi9UPXGhMPPtBYfFyobftxAgc09j56eA7wfrW0LiKeZfjaN+Xv1iFcY tWCRcsRu02otOC4n2IY7Psgoa69tHp87aX+ADB3bNHR8X3tU9q2Tldd9gk3McdLzj9gqW7gY8VHk 6OyEEeVwCEbUSrBAaxbnp/+cRZRK2lnBYKrtaFqoKJEe6b9I9353vp7S3AEWLgZqvdavsIP98Amh HMne9Th9BFip2+Lk2LTwSSDz3q4tI1Gydm0rZ55Fjnwiq3Qbu7brANfouHYeiJfBIDadAmOqAnSI WriezV/chKYodBtmM6oTYPj3tOMfTSib4HzOBhmSEs7wS237J2ogAzV4++CkPz/u/J3o1dddgVOY 3qcLuM6E0y4pM5Zkb70uSFw56vVisTyTu4VgEXnTEpcRa6olbgHxDNXxpVmU72V9BYA1Hft+TV8A o7SlNIPbizk4AbCozKzFMUgTh8rQaLzNVsXB6w7AaK/WtEgF8nZi8MLezlaCvsRCLHUWQU+2/fxw GDZ4/WhpK+BrG6VtcVieelSadNI4LldhrHSOiyRhoI5RK3t5acODbtL04O9MOO6GHaS5x4lnuFHy 6szC1OJG/M+CTnps0N5Z3K7Tdfi1zSCIUQ0IhTXWTAzePb2fKEp2nJ6FWBMgRG8esdgYVFdevwza P3XwXn9Dq1tJlczZWswtjnJaDArYWdJi8ADWREw1fA1s3j0eaCt1KHUPDIKLW9S+zeLWxXFfEW38 RT89+RNTH30Cg+xzquytIqY052V+xgy2PiHivg5BfD9+SCcexMwnnbGJgf3end+/w8x7bd3AqvkM KR1XKaxtLTRPlLz6Wrdepb0itY7k5dPAPjhxjm3O74WpXIHk1cxPGZ0B7qtFW4Nkcps5VOwRlBYZ R+a4mXhlszP4X+qudEeP5Di+yvw1YA/qyjoep09A8K5o2JIAvb2zOtvWQIwY7BAjdH7/CC65O7XV FXlEZCSyFJ6ZQb0yA9rRmRs83B0n5y1AP0S5CazXGoqRLaH+4ZT1377CZIJxZGFV9sNjF2g51JQd 2dgFNdXhDmiP7izuEfuCpHA3RNn0vE/CVKQukCMptiG70SU34vH5tEMqAmsNSdfzicxKo+RcHAp1 Vq0UEJ+twccoObZp3muTqq0narppVRpshpG5G3CHuifPM5Zja7jM7lcwZehWavDZc0vAAU2D6c1e Md2Rz6/t2HaBRjTXjqiZipIhn6i1kUM0KGHZYJltjHbPVG7wJtlh7tbjisxro8SJ1ik1dp5P1CCP uvTHFa3JjilOG/hZeVOGvgeH6LYfdQMWdTPZuSkSuh3GJftbYihgt1IM11KI2omR01vVL9Jh100r 04yX3chNZrMlF2F4TN40ORioK6rJQbLkgOmPfG6N04L643k+JAdzubQmB+RzK11jrb/j5GXf4EBM vflsqg5z6fbaYztApT3Bul5gTfjfNu/VoVR0P5YMvIImWN8DMSyYNiqfeNipfyelz81ns+DTh8e+ qKJbQcFU0a1c6NbZwJLPTtV8BRGWPnOvtKIba4Q0l+t+Fd0qWHSh6GZyA7bPK6fKxuMeJRW27cRq nWpiUSp0G/oH/V2PyIIWZYsU0/KyxzO3kDh8PEuKHbURR5mLIVIvdECOg8GTlY9suSPpeLgI+tm2 JgNyM9A6TK1b2lpF2uT2zh04H2WA/wBvuh9jBxbdM0OwMTmiQYp1zv35u6Qe5Og4vzaNCzXcah57 iTlvFe74q6ZxoSsYffqHbXs5oaFTlVtRRas5p83EtUDp+LWzcEZUwsxJ7Gzj57NMY0T6ygnZN9NI TDVCHGwz87NDwGGssP6Jpqliy28kN4/5tWY8DcCBiBgz18lxirg0qFKwHgGXCyY7IETjnApw+Hry GlDCo2BtsgNC03sVW2/rKNhhp5rIhZQ/Xltva1sOZFDVr1ZvuXZ0vJJBVVmlo9QtXLN/RTMakuto weBRbt1iwG6cca5hnM03DAd5iLDv7fs8AX6p3F6wQUgzOTwRicVp1O2w16ulQgfJ2wymJnMhy6O8 lgq5yQbm6BWujdimazKdGoTse8QbVqrJQmit4BauByKCFa6N+WHjCpfI0t95qqaiyBk+XfaViXm/ 1sqXYX2fHv4X7IKWFmB3J13NxFTZ5zb06jyuVWhaYsJuVTWne6Z600Lbo+5A0Rq5pU60Np6e7cD5 xP31UTjY9gPIkFKJ4xonIX0qnyMY216Qt+jEamPpaangc6exYnVGaxUUq28ei27ASYwpebbtlgMQ hfTebuKH7lihWP1sm2rDldy1cnpmonR/VPd4PVsPJ2i7TWwzWpvtIXDaFt3jWRCtrecxbPv6eNlz o3Kz/47k1kUuRqGXzFjGucTR3+UoVhdosVOraQ5oneAVq8eOFksqVtvKGKZP7tGl3cl+dGi+p4/n ZrCYHN6nQ9WxrSf0Sb02gitYM9VB1ajl8f1soQMRxXw/xvnQYOqT88nlkOOfaOCmOejQMrsP5jBs PwE8zPeZu/2K5mBBgjdNdO6WNXk7WWsEh1iQJSVkAJ3M6lEC22NaJXhcH6VY3UFPR7G63i1rtiNi DI+ET255RVidYjIxPEncrtBDvrcnW7zblCHDRDTd/CLTI/qse7Y9H9gvqN2UD4ulUVwuoM/bCnd4 tLvFS+DA6azCsS0HoLNnamACPtI2yBq0usPzjJ6P8TP/e+3KVAAjtoixikenOsXqhOgrxeq7X83E rz7fjsjWAT0ylQSmNWBlz6hs19/D9MgGWlQT2m56hF2P0zS07yd0Euw2ecEXf7pkR8o6+V/ocdBt /Q1xCNFXV8h5vs/89Veq0jWDqmdmBjdZypRuPj0B2jJQppPa3KwS9Nfk9djP4K7u0Ug6oLXbtbJ9 RlLCzWvV6lGrs55a4sAO4rUpRsja6c86iN/nK/rVDuLa+o7WEs3pEoukDNt8QrVm1Rlv+ms32/Na 5ymxnx/cnOaMrMT4HhXTwrteEtusMn9swvx+Hxb8/uOv+m/5rx9/+vNf/ngkXaCpaL/JHmZwMHU6 /m5na+cBEoMZeYz4Zf13t/3q3tBYjH5od7+a3Y/PvFpL7ArQTUKbMhA65EORevr/P4XU5ThOQMqX kC6rcQZrfPj3UaeGpaOHoylOtxSHGTWUWSe5+85y79BPNJmWX+hCyV6KR2OQM5UNumyNOSur4EVc tmIKwyVO7+lAgiPNCm5e8bWMdfZjOdBaIo07RsqzHFS0JHJ4P3lsHxeUfeB5+uR5GEy/uax3Wta7 gd0CmyOjc+Y+BS2aEyTAkc6coFtOwKprn9rdPR7ICF7LN7HyjVXXtHxLzyUF634kdBgFtpvwfa0h PwW2jhyCFNhMYJDZNuO3WB0+npqPAhLQLIrTGksLo6xmq81f1lbPEw0wK7IZg02HenwiQZa6oCQ0 DzN+ZvZNnxznydtZjnOgpKCHZgT2IIEnR5em9tu6R9zK6UaQ0kDqE9vK3irANsWCMrGA2oyPwXSU zzpOpB3xo+HyqpwkApN/lOKRszq2WpGG/1J/5DoCgeooLj+2lvMKZK4K1cbG04Een/OXa2sb2jCt 2GaE72Chx+lG5nxGtIe1XSb9STp5PbGG3Mjw/7N7ClfUnJrctVFwmQgPp6TXIRps+4IaoTP2GINN 3k/skj3GUoWDCmvSYQw2FRhwF/hntUZJoJPO5X2WcmSbcj8ZuHo0sT6OgWrs0maqo+cZpH8oObPx 8icZeTmk7j+LjaS9Z5aEfsKOft9Jvjw71s4B6KoJaze/wzSh0j0qP1ZN2fD61W7sKMUBn0qJms8C 5ivy9OOeKTVbNpBoCvooKaJZGWARFKSNHOVm9i49TbRwqUj3kdNlyVCF6qkLE4Q+iWlprAt6O+Fy qNSCh40jzBWSDv2a5LhcqH+y2NNA9N4HWSZ7XcK/XFfwP3///bc//fk//+kgf8hhbx3AInni9c2L kKK0leYR3zQNRb33idfGW9F1KhI8iqoVqBJIq0VmGjp1rl8H7EfDz3kilxYF7JvpYQp+n4CtRXZD o779woVZZL9W0+Css3wB6o9xqT/YLClXf+TnMtEazoGURqnbKpVJHcJVKqE2j3cjW0SbbmY0LRZN SYHdRmL21U82QLa9b3h/cTcijk6Ple7xfupZkQWIQttN9VB3cZdT//OnR1xCufQSQQRiQayiGbnD rX6K1BF5bSpS3+3Q1/LT2o+tgPXSmhIUm+1jls+xdo+JgdbZggybUh03dcWG4Tjx+2j7sES0Inea TxgaMPWhT1no2ioC6/l8TPQ+XstzRmRLgFnUtLpaWk1iz9tcp+3vOPoGDmzOP2Op1jwDn0czisnZ uztPWedOc5jrGFVKNt3MwMSmLx/NdaJs2ELHts2TrX6f7TX/vuv5uj1Yr0gEolB9Mz1fV1Y/igXr tqANn8F2xqXGpK5vdYrF3J2nnmsAtgx9hJu5YscZ3aMgTEMP+txm6LEJC4JtXj+3pRVkfdguKNDo wm5nrsCDpykPQkE9FrxusRiJXdiwVXa5rvTYq6B+TrK4I5GYPMegEclh2qZQHdHGBIXqm71iKn6f 7lM5rwFAtULbzfewbbKX9ZG74+zHuSJTBn0+RpYWpt0toTpMQ9NYC1a4XZ7iiT6frJ8iOc+jTYN9 XTGZMG4yAX9vsdfs0eBIQymCAw2l425X8w14HltuZW0L0lAFWw+VGtO7vuUSHIaflqUBjZvCm7Ej TAnidNb3aBnOxCWDA4lse1fSG3RYlYqsO2JHqtUJmbWo9FI9JgcafdCo74w+Rv0WRvdkRQp/59n2 toKW6ERrIxTI84m9dI/b1eq5CLgfRQMjFKiA16cCMZ77iZw2w2VbnRNFg9bKcCjgPXY5EaOQ7DyK bkzwGpPH3Hpra0XulAoHNkhWSIv3reToMDlQOKiIL00tGKNA3k/sLXu8n5YjWtijcGCMApUaFLr8 +9lcVBBaz1z0buu8lkWYbAFtY57wZvQ8gwMZjRlXPwlvZz3QeeIo49r3K4G03eb+aYfhZz8ORDAq vIkRpoVRPsmloeMej4EcA0uyjSNsaYJLV36NpQuiF5M9Ho2lOPakzId7Hq18et3hOpirrxMEC3n7 mJs9iFb0yW1K674FONvTgjE+JPZ47YPkvArQtswmoYXSV9uZICjTmaHU/CYGW6ASaOh5tI3Y08f9 Nv9vvDsDzxi0p/PWPfZEtcQ+0IKOIpddYC/EeCbGSuf8nhy5KGtOeBPZ5fKcGFS/1RGiQ6jW00TU g9c8p1ieg/NQhQn9y/7yNi17AhD0T6w2yoeDm8uBpSJlAz1rqfFuupEyoYTisWWtOTVyqtXQYwwW 1VH5FMBr4lawyNo832PCPdEUcvKYGWiVgMb9ZpVwM3JMqZOjR3Tb9rrA9TYtGINFvjevmZumOgjd Yo/hlvG+lnG1yNrAWLai261DJIRpLdnjcZqmzpDAijeBxaQ6Pgmss8qG+OxSzO6IaXU+AesnUzdN zjZE+GiqUy3VwY8nSxampHpyvvSUrZHzhOs8kXxuNQubUXg2mJYT0fOpm+27/gIHUylTEOvuPOu+ IYJxBp+bkCOqZKeWIGvTd42DzyWCnwvBX8lSp8WtAy8AReubYHytiaWtHR2PMte7w8tcUfX9ODzP emo6iqJPtr2rVJbMO7zft43syx1emVETYVs3LQjxfU8lZo9YvR25QRF8ize7+FoieH07O9opPeLN LrJUx6fYYD/2BZHzigW3MJmOx80Sz915algjXh3ZTWzAXF5zah7ruDOlFa6BGMns0hmb3XL0qNVZ zwArBYWDmyFhLfhePL6fMX/+n+2oRpguTnoe0kOUMBM+f6dJSwCnuZcNtMq2XWmlwIYxn2zxlrFk kBj0kW76ivVAfCon8nrW8TPdMwdhNbce1MNJQnCI1PsZKlpgrpHHOojUJ6gnJnN7ONFJcISkxZtP IF9bG7k6RLZ+7fz+6WubKql3jTvUzq24dEsfaSyAKp3I1ieysW1Kb6U2h+RV6aXB0cV0sSORFdhv RR+Pv9vRyzmRxUmwhk7S0oYZoNXqEAvKmqEnSLgWdczzsLHs3oLDsWzF6ogWmCtWmwKeOYy/tVIc 3s8ejwxiTyrZ9iyyAQWXexb3ciIvqthr1G8txvrlpZHp+761Lw/KHmmDswntInokM2Rrw6UtqgJy zDDuzF6bxh02m6CFncO4k8uGBhf7VY3OuIOPkys3DXzUTHiLDX1twZptKRYyaqE3ybwqn7wekTUB 10Cpl1V6ymwMs9TisVkgW9iQRCdcW2FmGCVW9rElj5sT1j0scEy2xW7ghp9P0bsLDs+jSfXHyPMR 3NIFbnzSIjkcVJL1XEFrd35uNnjFTBr6KB4r7GNfd9ALTfkaHAm0m5OGXqO/4/QQP1pr/eNrq9PJ rXVm+vw24c/fcerYkeJIQ2m3UEoezxS0OGwXaOLW8BRZCoZt+DxesW0bZwActpYItsuPDZVy+xl5 bpdfD9tHEu7/nk4OkvSGCtHqRU0YgsOXM1IbK86pyxV2SGsqxrnL2F3Y2Y8TDY1MWwaj4CiJUGWQ JPRZCq6dsLi+5seCsL2RWTobGnlUxy/SQG9Kg8plncG2jsSa6XGeJRGWA1ZwOVjYYX3dUT3aoWrY iVjFn5KFHWy/W0KgdqhPgoFiW8k4pb4YOLbsav4th9imSXOFfpuSbuUhW01Ymkts6ymAYVJ9PXff nVxP1ljqMJKuZ9xxQZqKvR7GKfpUiY+UtoIzA2N5mFO6ojjJQZ98PUspO1itFkedFog1sC2yn3R2 n7NATGNBawZmdW0cD5srF5pRP8xfa80JOZFmNiBsRdSUhToseNJyCoikCm13a5dcj9cVv0dc8UBP uokENmLhU6g3pmswTAyaEQlMg3yRp+6gbW35RNvYe7xa1WWQVuhbHMOjTm9rFRqLl9RNU027Uyl4 dM2oPWATnVwNDUjLILfGOu8Pt3YDGB/T4DNuoocML7damcz10eHlI1bUnVJ0u5kEBgc+VdWKbhlJ 28wjTNGNicRziQ79UC/jfTRwJck8gSL53KYrv8Oyp4d2oo6bSJl0gpDTSBSPaXWVtgN1Trs2dLTE dgzE2Niw4veJP34pD02oSNDIc7cPaZUwJ2PcfWt5XTKoEzTy3LwIgwKfs2PrXjYkBUst37wIO08K HoetRpIj4jzUmu90XsRl872seQeD2DMxuDlfIpkIebC8+tHXoxk0aFDNyGMuLRGfp06/E4ej2PsZ NnQeRbdbJc5mFfUPOMyr8yjI5WgqCAzd2PiYz/Z70/eBJAZF0sX1UA8dPhn75NemaXVAChAF65tN INfj1ERHwbp3nFYbm0CouKmmcGi1KWtvyJoy2LBiap1oJpw2DWQLEVVx4dryq8GHyKpTEmE9qker 0tYKNkrvt0z8tRZElToSuB+pYpZabPYy6v05TEXr2TJQu+oPe5NXDA00d3NI9mxHWIHufYL1TV6x 8/hEAwXrHHBmfZFXRIt86UAcapH1Fja4gqgYnxDJcXLJHhd7ynoI2EY2sdq0yESloxk5XQnzqOpI 8RhtWgzNtNWp4vNoVpfZ6PKzI0q5Y1f+bnRcfa0VN+suCRWm+q6Mv2LvZ/ryO7R3HansDaai/eKv 6AK8GNji1UfRTQaqFBTdjB+hupbq0o9OY6kgfkS/NuMTyHkufsQjnxDOiguffvEJZF9cqZVkbnpv jxYKewb63TmOHQqbxOZKZM1+nlKB6H9hBTLxVhWqY2Mum58oWuS5wct4Lhk7PA9TtBDON0aZe6bd PZqtlYQ2jczftRD6WuX1WQ9UXs9eqNk4kgEYTdgS6x0+GnNCR7yVxhxjRiK5np5Kd3g9GnMCGFbU mFOMGcHn0XxAKhNQPUolhCUiF8ci1/PphQ1iz39GzvNo0JGjQEPxenc/SNzJkj0OX0o6M0pxxgTr KFRMWaK4XIl7jg1JDBSsjfatTLrrc2Ox1CMhOWUo7b0F1qjmeUF5zsJRS7cdbbJQYDMWITJWxKc4 J/V6IGALI5h4SsjtlFw8urO0vWbgXd+HWB+UXk+PHo2acjwEbbUZkm3GgnhMlNIy63w8K2gZFS8g G0b5VqbcVYx3GHi2/VxQ51DhwPrUkSB1KcHj0Eg+U15/LkZzmGKwVNjaoVETswB5FAykLtCJX+42 NQujdebb7o5T1pIQIa9YbXoWkoTGPugWpWcpxRjA45lgYJQiS9uSYqJPMBCSG9xtXTZm4bNx2GRB fk36fO4+6GtNWexNVrgpQbIJd8kEWcxxsNzgWVZkRLymZ9ysCJHuOt3tu50VrYFpde7yTNRi8xPf tu+rsL9aJsh6VsRfK1Sb+oMwcG8jJ48L/Na9JpLn3BwChOosrU2nDXd5qGYGJwilCm13u+21Is9+ 9hU6vedwd3fJCiWnUKCfE4NqU7qSmZHSUvGo409jQe22CQcmMCANnVilRYcTftt+oOejcCB3exfe z4SDxAjsJ+9HZD9ApiO13T4g5Ho0NfCYuG09Qi+60t5jaJ156NBImh4k4lo8BdZw1UTVZNrqLSeX JanWPBUQIxOp79YudUN2OTKiSIBK7IkEdz8URh5LDBwiQV/3j07vVQOkFE1A379oCXb5B3zXMf72 47e//n68/fePH3/5g8c4jnUDxkZjWmXkxtSgChChOxys0G+pgQHs1vKFzszW6JPKoD4oLGj1w96K 6wObQfMXPrDP38ky/8ec/zhETPobNbWcf+lLK//27/pfW/b/+PHn3/5Os9AKPrqJbdbcbcROq7fh URZaat+ADkzqNfY/rTbpd+exfXjWHdWkM6k2yQSR6cXYe3SICuveM3YBkbv3DlEullIz2xT5qAQk bfFD/2MkDfn9SnLepbMFMBzj4r+++/EHMKFNAgGmb3cLnq2ECi6dQ/fcO9K1KLjNT44rXXkoes61 SdKK5kmrfXUtEIOwVMLcEOPu/UiMO2iClDhtM8Js7XyZ+n12OrYHuB0uB2NHGmN7fG4tz2cpB6IW W7ioRfJyqojHPatpDNQxmB0d04eS23lrqXn03dU6rmArAzHuKhHq1+k8nKRzgGRHsa0YtjH7es1V HYJBjhMOYO7WLXfDNVARTcnJ5/Zkmb22vMC9NnEOL0+LMHY/PnUgIucCuDgtFW49JTMCaXSA7OEu 1QqouBl7jFps+HpiaD4N7MexoNn/koelbV/vIHwfGnw1bctnPj+QIx8C6WX4Tubk47VLwd/VHGs/ I1SEtfdeK+GwPxsaeXDB1b6faGhEg6ixpImkbPpHPd7NFpcBKmyJWWNo+oXd6w/ezX62FVBwCmbR KNLGNguM4pFIyMfIOJ02pR7bKyDdY10t675gaVs0aRu5nVj1PA7XDWn0HNi6vhpBmghKOy3elrYh Q+TW2pXe0Hllj9qcpS8L6uGEy16zBqZ4l2vO3N3VtLgg45w+an3vJdKFKW24FOmdc/oawrTxo41p dkuoDutQTdbGDmG6XjD9Wgrkdp6CdsiL1Lk8mm0UkET3cTx6NzWgeeUapqvE7BEwERj/1L6PV/yV 3vS1bPznIqdEK3JYukZnyfNzvWlNpceA/ahquoLEJhRb96jQk3U74dboEU0Q2oj4OMXukZIfYTmA a8Gcvk4hMEtnKZExB8+aZy3LgUJou4XubKuVz80vLVbU7ehT/TEzAkolTlmlu9NsLUXUKtSM4H+p u5ZdS5Kk+Ct3iwSleD8+Jx+REhJMs4AFf497RMI0tNmV7lUV4aWZ3VRPd3aedDc3Nzd7VQX0ZMyk Yire434gImgTEbCnKSUYxDd19IGIaSloqtR1nVAeGr/M3s7OJip9JwE6SvvOEhUEenpt8r73aLdH niy1r8Hty7KCjcRnzg8KKM+lvyQ7W/DavIqPjx8g8za6MgsBWxmUaNLxY5wHYnCkQEflccnC4LM4 q30avVieUcCzZLVfUD8JggdKp2nEO5eH1R8oCW4mPKjjCh0MvEnrn3yOE/I33a9jikru3qJ3FgHO /cioiZnpV+hB5lDd+BhsOfGJCQT1RZUVKcBhT2NTsH/e7cHZ1+UVRpDBzah7XjzdAMVA6eo56zCd h9HXI7UtQL+PGuasQ5O5gsUm2lK+gdC9OPVt9dWxi+tUSzdoxpJKq2B0E8Cmn44Shr8Vlr6fcqBZ Rwr1q4ogkM3oCjFLKUCrd7e49lApO20UUA+XQHyNNJ4ljGAanKbo1N7T5BOZZuU4ldNqpPfll7M1 av1MN/TY7v4VTLKbpEhR284N71NulDroe07rmiKTDa9Mb9FgrN11XwN5hgvOebUrBLc1eUMGP5/q +wXIAgEGaQID+DS1uZxxSF+IfSdDnfwJ1geq/uwhM+nKR04W6/TRrhP00dr8pHEYAjUpJoj3E4H1 eVSdcZjerL+TRU55rgKKgAwH61qHkLlWFyFS0zqIT5SaVl8Vzu+Vzxf9jfR42nOWCpzEkhf5YbIg 4q2RXDUUFBQtDeUVe7DrMJs2tDEfN/i9CWQrC7IREVt02eIFUnxCj7C2Le0KY0Grs4inq3wdYNqR 2raWvESR91HK/8Pp3nfwTSvQnK2uJS8LIQ4E32y+B5HCBo7dtFK/co/f6060jlqRtWGY9y0y9ETm 595NAoNcvAOGTLnOy/6gKTvw55adyXMdQaAZNNLalqEE2/F+sqzaJ2yvx5Gg/rMtKzMmlPpo0eY2 pCSEcQQTvNsQZpBjE1ILBo3gyFor2ysoYM9j05H6KRfavgkGzcuRmp1Zx5gshirLr+YAlLtUtpej pjSOSY76Sjmg19OKlDYZ0+iulw/X+8z2pYsGYB6hXbStLkoKdayR2QBu5qQqMMiRUr2WVcSk0Shm k7dzg59a6/3dJLLtgU2+/X7ygxKFpPGs7Q4zPzd6knzd5591hn9uPGtxHcnz5BItygpClx8WXCCE dSLGuLakQeb2nmfcZ0POeWm+HlcwQz0F7hYNMc52NqRiaWGOCKlTNxmdiew9T0rxBnSB4IK2cAGB 1bU2izrd6C+UkKSwbZmfswjV5lw3+Dx1CA6FA7bqWBQaUNGUScLgqvJf2H3iOk8m/jhBrfMMVuvz PjKAOtp91jqRBNeEnrrFyzf5PjKQTeU6r8elHBCHYBdsPs6TYVSFNNN1jtSJVWMNPRj0/hLw1vEm Ia5NAnHF+PC5WQSj18gROTiH2tbmCp/1eoENNG9wqzdbfh5AUsnnE9bnQ4RtxbVsUNj2lAsFxms3 Xf70LKCv9cTsmLZe88Vpe4W66briIaNp6C4y59afZ3/8nfJ2klS7sCTindkv5O4Mio3iKH92pf77 Jq6rpDoT9v0jd5PpDqf8jVEaghS3tezBtE50rUp1+9UKkG9UA+cbWF7V6lW0G0lStM3Tlyv5DOhq 3zTEO/rAzDHow6gEe5s4xx83GhK6+hXMMo2HBF8dNaTeWgaedBRYBsIsAwTjGCV05MvwQNPWnVtR neSw4kP+nMnQjZFuAHG0qq1FD7lFiLFnBqm37kjvVlCmclLDj6Qm6F8uaxtPR1P1QHIo+PPd8jDD AmeSnIotI8OC4t1ybiY7RZ+0hP/qLc939iIzJQxsEuZehLozfnSL1NTZzoDORFrwr7cpKWy+NGLE sjk30UdETbVSJyRgzOEn1vT7CkHoMstg4mOdIbBQhxpisfhynpywO0Z6eUPmk5OaRYlr9QP55Ago eBXI7PXEyhSuW0HB6U/sCNreJRzOTSwtNOaUs3Pnm5NDS0Xpo+9WhOndbQqqpbIN8GuTxjOPRBLT gWVvcccjs9sJ5McqFF2F+svhFP7n/da+WqjL0x+gy5FC8Mp1mXTf5u1obAk9jiC2MBEb0YOGGQJj zyanPt0DAOpD131IzIFYZnnlpw2+nvxcA4klXNf1m8ICps3poRjsO+fjPNZTt3f9Bj8f75pyvgaZ j8sjrVGu4V2/MRGlTVfQ5PONDGZ6yelHaqmzSl2bN7gOkTbaAcqRNjotaBMjQJN67Zp7muiODoic 2qYrfUw89c1exNO4z4BsJ5M6Gem3wdw+SrQoMhJQgIJtBRS8WnembrV5CHvV6LHWPS2tOzNgMGoo cY3UgBlLUJHK6jrw/ejWOlmMua7yg4LnsH3eWMFKEIMLnWg+et15Q360C7FstS0P928owzcevbiK 1Hnd+Vd7zPCATecS+XACMCvQD+fdiOIoS3kzrRk0k+gxoiMRmXaWjxGzZfpESr3zELaF0AGalrbj Zh2gGTXyP9r7sT3yMEDskbuOojJvsjOEUhPjcPZKv9LAWVX5ZUDJj82oElRGN3QkorVg7REJZpPR 2uRR/FMKcp9MGiKkS+Cv3lqq1HKboCCXjEKE9Phg6qSI1iOVQPH0Tp1UF6CJtgfyPOtMOZMz8lCq J31n7zYkdXT9JrXglYGySIfqLc47sSU070gfXQkVpFRb7aPXiDcpbWsbguOT1UyHmp/vFH7leKAU y9qXkVH+nfh2+aF1QFB7wWplmQF+HbPtTeSMA/zWal8n/sSd7bN3szEMpc7rQ1TWXp7g9zKevEZN +Ca+L3aaKj68t7hGzCU4uBWNyx3D00KgaUrmHif6A10mekEDy2aqkAkhNN8MErpjPNDaMM/LRFfI mlen62Rwt3OnioLhQ0paEnJlMlCbRE5wiCmQWXSJQNmRcvTVYuz4OQayNgyhucWAMklBbs3i2jpf V3R/VRwnXY1mZndMf2gh7fOSCL3dgGufl6K64Q2e9BwVTxv8pZXnrmDnJh/OEkqR+0qrPu7XKHAB Lx/OYkDZEjFEk/evx5kCOh/3+cdM4v5y4PjGmxCZqiO6dkuxvFM1G0NtpljeqaAoaGmgdTXQLx/s bGygPT8PbKB+aqfZnOOLqwYJnJrU9RxVtaX6YrZ5RuWfsZQBUiz16NU1nwm26YkS0zvZm6dc8Ei0 57YsJEjGkzoHsu3u5pbTgQhHW85LtDMLiWxSw1a99EJYCaaYNeOWE10shMqV/rVxaPO9I67Q9eQW XiO5O/qoBtdUPZ9IMZlljFkcAalsRpXTh8zGoO3EPM2YUmEJsLUHi0k19xMHqm1pWjcrxGGCApvw U6a2E007KfUFcb4s9vA/b0/1VYhzjgdlWGqhftcG7HovVJNbHX8gUZ420uUeQTLuvVpLGVR7pHuc KEdIMOYPPR1j9gTN0XP+reLc3DugCwVgzs1B+fLotvHcbdypA5dwHxbrIdWa8FHJ9WpwqyOYLYIu qqXg3RyQwqbBvQaf5ykZ6fRT6FMcweS5n0yi+8p09f4GWx3Bn1MtybIpenQFF7WfaKr9HUTwJEx6 1CUrYhp9wa0WU1OvkaElTmj+ZaYZwpE51WCVPttxIe10C/n1m8TTW2w8pHfv9OYrIEC7C1NjSIRF VW9JMMTZ+vU0VXb9dW/gSw4/NKibWQPbdGOLvt+AaxfA1pfnOUnoTUn/iL0rXgHUKDtEa8Ei2xkz ZdSTvsbhYeeJ6ywEm+XpDTx1L9vLGrYHRSW+rCF5mN7ow+xkDccY0IY6z4txaf2kjYaeLA4H9zMe TBTMOAeBBYzHsXmXLG20QnMPKcWrjeLZ2mobFZjTgIxNS9sidcnvrZaaLCZC15QOUKrV9HeVNuKq 7X2qBo0Mw3AFVANtk+8OgcxvJReLKsOre8Ib1sUbdlKtjaLqS00kkLYo+8kbspC0T8iPfavR685I nqu1YPGGrJWqcM/gy2nBtf9Vq+W1SBmYjs1S3phJ1sevV+r/6x//If8v//bHP//t3//Ps6R/+Ef5 mxz3P/3xt3/5T1riMqB3pcS9ShZ2v2MzdDT01kBH1cXVEhqRI2UfamXB0JsRT0Jq0BTbS4TQI2Wj REg9YChs84tCZH6tRjdxWZ4Buc/2PulqFpf2CYW4j66+y6jgt9bn4EOGbKOpfN5VQLepX/akc5g9 Tm6O1ICddj9S0wKw19ea1lZNI8+j+Z0Gv5n7uZHvl9a0pWjrzKLRZk2TKc6j+IMWyjvFEVht9HnG 2Q9km5fDykZiJTq2bHHLc96lAbFEUES3Wg7zoS7e4tRT3XNBG5Y4NYfEENT30Blg21ncBOsj2zy9 fl1KIyql5gfkW68seyBy3fZSVKSRGi0G+R7IxT33Mq3zArMEjT0zK7PNH08B9lLy8UyZHjFpTL0H Ugr8zo/nGkdBQULqmbFKG9OG27y4Trk2gNuaW2ejLEbI5EJeUA6yZdNC8JJTzEOze4vcu3w5HthL yZczbeYKfjfNd01G+MU3Fd9Zwt0Zs1PhZarZQr4WiyBHfm0Rad3l17byU4mFplUe507jgfkHeeYf VEZLmRyspUw70EP1x7aoUGbinoqzubbqFzIuaaG+Aw/7eLrJO8tU6gX9TevKp2DsburFor9prwVl h8ic45Y6HBPvPafE4jZ22uQIoia2Mv2lQMmvzaz/Qj9R9LBUg0WBMqdwo9Ugl1CA/iOvrFF122Wn vSZ3vjm1P9vk/F08VYq0H/n7Eqvw2NnWaqt1c78COrOS8XrtQ5iJUamOicF2jtfVDWS/0F1a5AdJ eSpZdfC/eEP6HdR2DaTdl9KW1o6HScFszm+C2g5EtaW8zDGww9SHzQFORoQD0e6hxcUbkpHno3Rv MfFN/nk9vOnzPwSVsQwuHi1YdtpJ1BtNb1LVZoByYBf+UWq5wUtlqQPI6ljrQFl1gOn0bG5Fr3E3 fDMWFy/FEnqNQrZcagSlIK/IVIE4jGazqTOq7kYWDNJEF5XDSsGHknPmnuYqz4HXidPPTD4eJgo1 ej06BH/C+SAuaoqAHKv22rmUAYp1XsmcIZGwGrP+Je4cSB8uvWdt44lXjnclZIM/NykGGWtc5+EY cZtT4My0EnstwE6kENeP56XamAetTYV4krETkAV5JdiFFNiAYNMXdJxHhnK2kn+0Upkk1KTI6H5O dHHpU5qmWdJ3mPrY5ru5wtXBCkGXcnN4Y2dJnwxvP88e+OsRFbeDstY8FWCFJlaVZrDnXONC55Za 1V7KkEA2jUcw+DzjTgm8HR+Woi0HMlr72E0mikkpQOejWgpeHgfPOznE2AzOo7X7AiCoRr/PDQJh qGNulUG2nU7h1V0HeBwpBpM0rGz7lmslKbA7ScOnnAfYJuoVzzQwKZ7EBuSiCQnmnkeKGzqCk+KW Xp6NyidNkgV3uiEETXm5/xArhs/66D73SRneGtgl5hWNJPiTEVOFZgZsbTzu8uC3JpVgyr8qkX/F Vkge9E/MDPjOsHMhlwz9cl6ajcEcm7Rhj73nv67eUtckBM9U4TYlH9U5OOikafgRG7M5Ddpk7b2a x4+OYqt8VUfd+uXtwUfZF7ZRwzNA3psUgUl/Vjy2hZoCM9LcGSzYDo+8jpWPCpOPYjvRkDqjP3eC NYED6JpCi9qiPylckwcyWNTyc0Yg1696GxJrYpSH/DWsRG81lLjjQGEoYekJZHIjJ/G5CiSw93Zk ckP6CK3TL4nD9O2hWpTrS21Dxq1S2yabS7wNY0ryJ3918M53asGJhIZaCxabSwCbVYBzp4K49pDK OvBnyi+T3ucyGkSkmlxhGzIaMLW+b84g53E/xwXMDbUSvBwO0+vbVIS38yxw1CmTAa0EFbRWicup 34kKpO80ZDgX1tYtB7LXUWwUDe51ZHSDSimpbIvRJXbuag1q0QQselXmAVKqqEuwklLkRjl2k7m2 Mr9lRLJJNXgVOb8XKdXrKDCyuywKlNg15p6STVyAFO7y9eRFGZIZ7iP5bvG26rhnHgXABevahcml bK7exvmA8bp4Pbf21bOop080rVvjx4+A8viC1uE1XxNcIPO3xVSU0MuF9Stp8QUsajS5alHxEX2v 6PJNXs/MSyyEoo51ujma4z8EhyLvEu08r5zt9yJ1azjRcZUucmfnIQ6Hvmdi3ro3GOWOETk2hlUN cmDsVHCUPdzcSWHnkSqwVgiEMbCql5Kvx6Mg5ZTC4t09eT9G7RdkuEQuevL1LK4ao9CYcyJTz1bc Jl814qqlVnu3ajXGBr6Uxnz0dk4JMsXBK2X5el6umjkZyZ+1iEOv40HOPyrPmziUiUGLJ8dvdd/9 zrjDjWyZwrQu0VLNEtNStDhi55HOP1mX/Pd2tCu0/rI5W/x5TfTr67ezAAAqJW1R1BjeRJ8KeStb AUF16QTrneKVJ5BpJ8AKID/C7ir+ZLY+zjWOE0sK8su4k5+a0claRrCA8I1bRUD6K0l78q5kg9Pb Vd0JLY9TWCw1S7s3ehwiH/WJ7KWWYXhIBBBYpdmGOx0ABPKtT9K9YfAZg4sETG8tBtG3CrzZFK4t pSEubvLxyAMb/HjOcXbsw5Jf0h3im+Cyb/GX79++ddF7AUsmn+OPFj27HZ8rBHjRG/eRhod/Krjr 1zq9LnppyEsXZGQv5EVAjgd1Wr6Lybc3wkn5nAlLsBvkZOCaV3wIC+TAl+Nd8NkTULDTUWa4VMHj aBNdFBujqI2SBNcYEUWqS4V+1yEQU+vqLXqSB7vz4ykpFLR8q8n9kLGHGcp8Ip3cen2QwgBzaPeq MFKHfXaRaNQHMBwOnFvrODMrGx6qo8uRvJytle0J7kB8blTT8/D1BMifSK99uYWeEeVwaQtdh8mE av9Ijfoc/zyLj29UtSYvB1bp+FK51JbNW5RQX+O+ce5bWVQ7ng588FXjIc2hzzveiPmQmcHLz80T MP3Zx7NRzFae80Qhdt6/MSjk24kxWFyD1NBPQORKkZ5rg4bxTXTReYNzqMBPB+YcgZ8vx4ZfTq1R /lp7lucCPwMa26SwLc0xBTg27WT0DB4r9svaguBpJ3bXE/Oe3Qk/8/HAw36XZqEOtTHElp1FR8Mj y9eD4HTTbUhJdKvDCnX4iVdvXy/UI6CQmsW3d8/8DAUbWUwVG9cREe8RvLrjxOKoU5YMOwYpNmk8 DuoM61zukOhh+aSoVmrnbdW4QwB0rq4Ql+qYNNKP4ns3CAuGixeQ5mnnebcHv5c7Ti75BtuqvJx0 g/yHnSCkZHB7UJ7bAymb1LY3SZmliakcxN7j1Oe4Qd+RgbS+SkMSVZMKxQVb0zYen4DGXXHO2o2y aqDElUFcUEM7wPvprq1lFUahoaVaydPsrNXlaQ8cEuLLUWNgUEPqnQCDrT+29lRoCZriOkAgLh8f 6tdksBhIqW7ogHyZ6UqpZq55MVlUSiXnLkRO5d5/xFK+zH3Iv4JtkDrG44BtJ6yUa8aCSgEhEt3N fqB3RJn3UqbXlpeAUKvjWyxH/tN4/T+6r/6jkPxx3bzh0/7qNt6L3k+Duq+2VqIYespbiyRAaGu7 qS4e8MpFkbS2G4zV1CCLSQl2ku0yGVRwN67t5l2J/l4Zlqn4AcjpvAyopd2wQcemb1HUOHVYotcO kRrrZ2fRiv4cHfmdS4mua2HNbpCM6qZrCNhWqq2dKIZqIbVMXBe2yiOeckKT1l78uqhK7LL/I7O5 beeiasQYEJ9bW538J9uLfhJ9sDHa2inthPrO2oVEvET0zbtsUG8sfccD/lP6TnqXvOzazaZ5e3mu C/GfPqw9Ivt0jIo9rvEMoJTSQv3urGkfNWneXvVCHBbqtRfFIEfAnF7FmltUCZp/wMcjtaCtWoBR QS9B0ba5vnP5GoCySPnClVVF+qj8DjvxLNnrIdGeG6Y7pbT2vMy8PUmJN1jbYnwCstFda3ipbczK LFaLpwdS2zogDPVn9q6tGcPWvMX7sFQqkhzn5REuIw+DOV71oeYep8o/MUx6a2uTSPxkQs8spGZz qT6ARLf4tEwxIsYFvcYYycvZq6CWag3pgrQWidQX2OYiscZ8AcWxlLa1eUuEaIu9W8zha8+J3Ge1 ky4pKPl6PjRcyCCbc46OchK1VL+bt98r3TqXHODVW3qXIWx9EHszWarrg8STrs9FYidrXpkRWBjf Vlft1pG5lG9xnsCmTiwkpJQHi/sDaT0J6I7lX/5ajOI4aC+1wlkk3rOr6HgnFzc7aSGWC9XzNIed e97oS0aGJTKkLUsMErvj5QURre5miVEo4NemyGDtrZktaPY0O2QvMnAJTAndx3c5ytyybLpRy9AT wdpKO+m7HGV8m02X01zSjfLRVgKCdFL2ODbP4at8PGjP4/rckXaMqn2Qv5DUgq13fM99AUJHzWJW 58GoWoaHxLjdrQdJ3QXkNCelbe1ImVmBUWe2nA8PUGhrajoZIvmx2QzrjiN7FJqa8gxKbIXcJerA w46rdrpO5lteDWw778KX2dLb5Nqiu9HjKMoJC+UQVCDjtU375iOirEQZANYCm8w8oTiNVzb3PKlU 5MmUV+ZGSHiraFYuIQNpBxIwPTiabZQYf9UWi0HdcUnjBgNpVFMZr76SjGujPLXfKzUKHoU/ppTX ypep9mONJpWtd0GWoH0pwbpyHL/T6eg1xgACAy1ta+VLcEH2Ghpp73na0U60wvZekI6jQl1mkqPH jPuc88oABwhS1ub2uhPzTLVjIszH3pWI7wCyyXTwbq/xZN2yzwzi7CxrqWR0cp1XVE1IZMPzUb3J z2Y4AaCQx8nv8poQH0ardDrOAF1Y4ru8/i/qvm3HkhxJ7lfyVYBUoPPOz4nrkyA96+/lHozdKaDN CntKOaLnzmJ6sVk9nRwG/WJubkalTQcbwC2O0h3ujfY+h9ekxnl4OQ6zjlZsGfhwaWh7pr2DqDRq 9clOs7J709B2gxKnSnmnvbh7G7UI20VaSswxjj6OBe+0l3WjTsdvu7YA4DwhjzwX/AnRqLfksbsu tV3AHKlMLyFNPWzhJRYm/LP0ONu4kSZTe2QNqa0Yg6Va+76y4OOdF+nI/ECmMlsqVN+0hMpmiWth qdzQDs9kHGoWxXC78Q0ZTrCSoddiOgGNZUiYg2uyk5hyZ5qTKy/nCFp54ZpgsiRIFvW6w6MlaEGe b5p23lEi66ydpp3aBohrZZpWaZj+WZbQeRtofDAmpW0IGVx/pZw8qhhpzZbA16Y12zusgh+b6N9Y PS7xXHtBNAkbd2jiyWx1NMeSm0NNJo3UDdAKNFLPwShxf6yDCn2sVZLYC9hOtEg9p/DM696pyr5G 6oAqNo3U72SUdNdeJ6Nn6ch1Z1KmTIL2RyWeFsIFrkdD27szBm/HyFSlE3ngpQyw2jfQXZdpWaV5 lPH2vXI+4gHXKsIcVpFeNIXEll5WBurj3m68MTbeySjzqqmBDeKXAm1x6wCYimEm0lipfDMXa1zZ JFx1VGTU29rTXH+6Cqu9w7Lm+hjhBPQi0/Z6B4l0d9RlQV1OCVCDNs9BIuNIuKXm9QziWpneaDEz pUanKqcapivoDzRMz+EbWR0tMRafWMGBNVvHO+VlSdQp4+M8EIFFU35/XHoTsXQQ/UjZ41nZIWjJ lkAFWqW+EwQY2iTmnIgs6OI1/7AhL748JXVTZwSjPGp1+LnlbSATZePlzVDNmKA+1/xzHjvAQcs0 fdNQ/cNY1I9HAArVc5hIVkdzbuxbWxqq723De8rjHfWyROpUCfCKG4ByehtPc13C5/7WSwvqcEY4 661zvQqr54lorGaG0Eslj7dewO2kWl/cEPtZFr05uAlbjD6xNPEUkEct8czRNdHI0G50uJyNHncG 62JjkqY08WBYt4ZWWNm28vGkcd/IztLWrkNn9taSWmShYK2xw75jpycbJ0ZiyCfD+PH+TrPlA7kL Wt55x4k/qyrQ9J5BKCjT/FF/TCJBzy6Ps/de0dPpYkAOC2scyCkLNc1uOZEvp35HD8aWwudcw6UV 25CEBPQ06czBNeOCOlWgLWcSZPk26Wz6F3Y9PschR8gRjEMssD3Tt8ycU2MOHpvR875vJFign9uc vuENf7dIWznjgcyrpLzTN8o2dGnxkvqJ9Rfq5LnjvKO1dtDaGUM5a10dYgJ5x4J1ncGaFG09deaC sHYWnw+klRNHCDMa/CwpI40GG6IcavkzpyKUDepTUbPoCwHnKdNcTMs2QnRPpCFdfZxTixYY3N4h D8PdH9a4u+O07W7IqrebYkExeRMWqyuz5ls7RjgRhbKkB3aPg7TXX613NkVYCx2mCnWztOWcsY0U om4ZoVsAuadKe7E2eBwJxkNyyNHTPqGjx6Oh+p2KsMI6UL2PtaE6XHCLvM4xAhMIrbl4lP7J25Eg Mae8Qx4mOhebx8dz1u1G9lW5NosFnWkcuvTr1R6ugWm8RbY8Ixvz4hq5OMyjQ+tqiOYUQ3M+9yH/ xpL6c5+XWKGdUHkhagIb5kAn8UvRgn4JIIBZkH4nCKRic5pD690GVKJtkwxKgvTQZpTNq5bm0Ftu 6PY0Qp2BgLU7Pts3/awGmCGU6YyiP2am93pUh+BH2+oJsLb0uNhJ7szoJddAbieu5LHkbYugGR2T lmN/+VG8jyvUCzmjGBNixjZGLfCJFWiJswH5PC1xxixxPqa3LsyjGtk2xDzWyPbC1D/LJr4cxwWX LeuEdSuDCnyW0/p2Okg89nZe1J2OR10mHq2oT6Sgp6HrxUEJ7O60ok45IB2jKv3FCmAiNTGW1Ahh d+nSSwsDuju0t7cmbr2huHRM00R6wg2rOmHQSoApryPFflUcDPoE3amHqk+uxNBy87dE+h+eoxLG s6DYaSyoJg/m7jj12k/I0etzt5c8ntG0ZvDY8wSpeGQlL6xLyrbyCAS4u562bTcktdUJtFU2v/ZZ hWplkDBi0Cesy5hGTrdhDzkD0gzPTZ6qmg1FXAKHWqucYPV6JJmix6Sm/sNZ0rKz1OuIkFnQXyiH yEy13liJsxbKuRvyf9Ow9mK6zLWmRI9a+/XuA7ybMYkfVuqwhid6LKivUCJyqtCwNoFQ6m3ps8bR zy0CmpF9bhM5JD4vXj+37Ww7WoHLLc0w/Tn4sW63t9R9Bx9bmfKGMZPQ5rfd2U+4PNpe3JBBOT5Z H9ruHBg37BM3ZJNep1hB1v9oNETI9eGG91px5qnaJpFB/NJ1S20QdkSoNhh6hjZSgZbcPOLUKV7j N9veETVwW2Md5TG7dQjq5v/23/UfsZ3/43//r//5f+i6f0VexJPMYs0POdfjP+7ujrTHblDOebx4 G04/I0WzhHJXjF4hoz7BQtyEd9kgzin6ftzXAR0rRpzwrhBThDCKR/i9HDca9ejreQFEJpszIuPw r1SivEK7sVf0eAFERnqv3eVOQmsHMHzRYrQ8xSiDdKju/ldcZy6kb6dhGmWceBsTl5DAptirq9EO HSvai7extUuNBOQ4K9+OdmMNbyQY3pZiYp1PiuJxxzcd5f4NN/gP8L00G5SGwGSAsm1n+zuN9mNI 61Drgnf9BYvPhTwSw6rXLpSXE+lnaaB+wd0f5hqfGxLbLlNcwn7MJj3C3GEXc3YHmPQ8ENQTC4hC tVeWwRGioNimqWdiokKcEcrwuQwXr/QbcvCvTi6Z8cvn4Pu/H6H6L3VyYUN2Y9JeoJd8c/1xhXF3 R1ruCKrd9Jt7gVGii+603CnHdaORj/QJvjWC8/bQPeK8Rz8DxuHHC74x0p55ZDs8z30eAAexz+0F q0jr49RiudS9gs+tzH3SmNn1OB3Op35gmy55uBOR6Bul3EMikqGLg8EA+rRjUkE0GLDZvE9phqT9 PxJp0Xqnz96HEal4vbNWTasNZBSbS3hxEFa/+bQd0/oN6lLGkV7YjdTXXoNbOVF9PcrrGU1uxyXB Oo2wX//ss0e3si0M1vnkERjHbSUKUo4d8XfHJIPYVIE8HJ82pBoIMqgKLBDMPpvZi7hlG5wVjEwt ELwYIikLcqseSWGPBxIayU1fAYeMsP9CI5e3cwBXRX1Ds5FrFLWuxeEb0k6hghmJvaHJ2GE+Fk4F 0vUNwTG9vqEXDGGrpT5tU8quNSW4n1Ae4abYOpPS8elDmI62A9a4FnTBEiqN2KOyzdKVCTWHksAm 5kMU7elzp4S6jvSqtQFSPBsyXgSEMRF91gaptgGIotpAx0elhfnc1ZaZFv/K49j3j9g6EsLUrmcb 87325lBER9PODkckJUyAivWkTtlh2sMhE09LOxMPjSSwOT1PylUiKt2alW6fd3DZQ+lW6h4ArlPm Sowp3DM21fAIirbtKHCkMEXS9f8mIKI0j1I6x33seJc5TYw3kkrUaeVWpaPaICdbXwz6RX3ubbMS dYtap0EZ7mjXE0WYPYcE7U79Xc8VxgaFtUqY5L0fplgbt+uG9PHxgtZsQuJTFESjQUFKVHHkCYoy j2+9P5cJNR7tRAl1mMrr59tx33eW/4eE2q59Q/vzUaYDEWHwScrCvrnv82H/K+nAAoB4/dpkDhZ+ mKrw2WpFGTW3qeY2yBNyuch4hCRAwdoCwgRHIwHenJYHejsCyNbNPjgN1kxf/A93833Vwad3s8l1 gCVTCfKr9dgZIsqOIt+o3/TxZ9aPAIalFgPemQIV33XpsJi2UxrIO8nWYuj6SGXxublYi9GXIwCD l2rkI3092FpNStW+lsilr0QRtdYJSJJKQ9vErCMTdEuByaWvrXV2QUvNMbxQInlCThvT6wgdwAam FxbMD/fTQP2Na3+fRrcr9Bva4RZ5pz0/y4S95oykA2XUX73rl8akkSN7Nis7bK2mM4hqWk1PBRoS rbWco7vmS00T0nUhl+/cptAeNfn26COdQ9tQxnn0TaIMJjvBa5z+7+/gaHze9wxqHI3PL3DIRKud tjmhIjKlpc8Xe2fQh0/j2OOuSEDUgvQ7G2GqgT4VRPV+EOxu9/MCu2xO+pUqGfouxd2vC7XVEqOV a4aEsvvptZH6ZmXeueu2AZETTaK2PxJ7Y7BHKzE43CbTFq6A783ez0R2qQKvzyInjgLdhySE6abE RvMtFY8qACUMqCis7yc+74cog7RqP/MHG+73NTDlqLxQNcmnklwK0dw1C+DvSkiG5oxP0ZyvuI6+ W/PYwBShVHs5oZmQyaed6Frme4eROpc4AWqmj/yHzLN0E3PvqKoec36ghShOpMl8l0mg/j6A+m8K nVKQCKIGgheiZtzDJh71QPRzywCits9tYqFMgVf0OA4/t7SngtR0osy+pzPMvXWPVMpyHg3R3zWP 1plHmWJYF2Z1tbZPKAFME+35TBiUMQxy96nRcMffAZD/oLpaF62Hqp1U1SVUtkW2Mvf0dnYEUkuQ uTVPCAbaDSXGl1gKuvdjh+JNJU4olMnPGPXa4evRzwp2paPa8oh1cYQoLo8WtLvzaFV942WYMlEd ZhvplFEZQy+ADmbvZxqYE9TN9AUZf+r7WJV/UxxcESKiJU6UiupV+lwxb5eeCGbTEmY2ZYNfvky2 Ml6fIaPa2t7PRN2YwXzu1aNiejyrgGqnjZcv8fk62Tq+xNG3m7ydF6Eip3HqC5Oux8cOVDrVKh3G M6ohM7xt5cspR92QtolG6om3sT4hD/2Xv9s5W97gIK4/2vyDaWe41NnTsFaAQ5QtyEywLTEamH6V Hpu4uu1gFlfmbCRmthDnVIvqCucJrkcvJr0IFZv1JBO4dnee/b4RZGCf24R0EqPm+Pzc8iUHYFFa l9CfLoFQkbVbLaTKWUqd0u+tIeahfm8vRMWUn4smJn/3U8oJ/aRHe6LBX1Q56xi7Z0g3uBt7Oy+e w7TchKpnrMVzJAmscvpT5TAtEF5Pr6xyjr4XgLbZy3nxD0ZpSSk73CjVr21Dqo76tb14AfMj8zmF qzIyiAQ5G0knjMB4h38ggaz83FI6D2Dmp4nnAat7o6MrDhcsba9bE2hvUdKEP5hioG2ge2zh8rkh xcAYyxzKM9KEUzKlFm6widNw8MIfLFz71NLRPgHNFstEc7RPIM9HezWPs550h3Og2UgPekctMGyK D0rXMncP1GHr/2Vz7BTYt+Z01HOFbccExDThKSaA+BVzdVgatO2sSEOnh5Z/lZCYOaG2pNHhcbTS QZWBhrb2QiCs57Ef+jtPzn0D5ykT0dHQxlgGpXk0vqolQfqhVjpvi02kkWvNrNJZyWop4T7A9Twu zKFHvA+XUmwmHfZv5oP9xWmu1iEHJE75tv45d3ct13XfQFnwOGHOUE11dIZH/LCcByyro5U5qTHp mRhKFIdV9anJFIgyWKh+4UPGCPMJH9YiG4J3R32GpBrbYJMtKdZGGHtxLRVZXzXahEmTgDgYU9yn gVcu5UDRIIQJHzK3UpcuzNoi9IDgth6fFoHRp1pn9I+l/eioFwaq8wSqGYnf6cj30P9o7HfVJriL Nd/dRrZ8xYjxqTLpU2xwFUNk3oRLI9tVDuR9F9PkurLd2FjF4w523gNckZcQp4Y9OU82tqVH9pSE BA06Sp7oOxNvc7qjpIXOAIvYFg4m+p6Zm2wQj5r8mnxih/hUfpIPK9sqdbdZmXzysWWgdabBYGqD MYJOq9GjoYVRQIGKgQaDNMVQ2Xk0l4pDQEdTDGziNPe8sxFC3S2JGo6sRAy2XBNaU4pPF2ezBPx8 SomJ7fUsrd1yhwiIhrV31sPoej7bhNMYe7grnbORzOB3n7Vbucx5B4W3aWvBVhad2kBocEN7MGVi BtrkUYcBSQ4pVLWEG62TanR78VCC6QzJjBK2dJLdroqluNNchMHS4hb3NF78uxWB/mbac194ESa/ 0x5qcuNTPiPVjBZHck8P3ZWZsrsEQbTNLtiSvc9ZD9mV97pSWq56IM3qR0TYQjW5HKnF41JCu46C 2LvpEd1NgYEgSUshh4VOOu8RYNdjPP5GfGS/qu2Y+TtNrZpa/nkaU6Xs4fMgsI5Imc5+X/9EQm0+ GvMgnbX0LozXtpKxu4+K3OE0lpV3YsUk6HxO4M4gFwAOLULPEQ/LN06L6VSuG51Hy5u5p0h021Kl DPGlSFs89cv65/fWNQrY3hhjhfLll/R9WjMfq9BdmnFgKV0nSE1Ih6JRLTmsBvaubwA01n0qNekL +VzBceV5trPuSKkp9zJLz48Nob5xOvrpx7aPGwU2C9TvxIpRJXy21RqoOxYQ7+/EikDuTvucWgQu kdpvO4MBfjxdy1JyHlmJGmofimR27XubIxG2dul3QroDFNS+t3ck8rNkKYskNLLKyUDqMAIxIvTq Z1NLSICaY89ngu6MOdW0EXKYe/T5JCxcXyZI3dnE1ytILQk7qvUXpP5832ppbXD3hPyG+tSb0VqH Da1i8ahupO3Nef+zKc1thF9VmGL9MNFKf4fJV7owRl0nRk1cfUuSwNZIv0+s+i8K6y0g3qEFg4np dqZan4NPiedwAmceDQbjhUGZM7ZPabB4phvk0h6mmMnnEPVCjc1ypYLq0FgnZZeqiY/B6Ptrl1+u EzOq68SnmJ2NU0b1ESQgsoQ+nRef+lkU5KT/YJB3kvkUx9iYlniXwdYu11ahkhEtdNT2Ijo4FJgU AKtyVjZxecsZDRPDQ2Uxu3IGGvjktbV7Q+si0QRODQ3NgfH0fHY9+yZod8yi2wR1mCKy0ypUC4MO XEktuk1Qh+nnZI5Wr0VEe8BdwqNnojGZcVkKpYItBQ12SUhCONS5t9zIhoV0/YnDQvToG1yA0ffz glQsHngFRe2bg+9nglRsr9xpl132eCOX4lDnMmkjPHHpNXms3tKRb6A5Y5quMVAt/ijJoxDdvm0D iU/p43khKjaMSyE5/NiOFBuS2Mz98VcdVHuKkwwWOlwdktFsMTyzRXs5GDKQYDYw/i7nDNuFZnEa 2SZ+yLb+pXZmp7YW37061muqL6RDlfVKcqimVe5H8vif7Jz0qzNp2qeLQ0dJdeGc9D4Q8B5TCBOb YkbyWol7dIwtl/akiE3d3p1YIl8grVWHceCS2vAYu714DtU569EhnTqlE3ImRm1z7MvmcE49bTRO d4RP6fOZ+BRzH5OaPLrd5WPbQAWqz+ddvMQb8qFwk5Glk4SxV6xz1iZgwFbkv8rwuEiqnxvaTbLP 7QUM2FgxZJfROmw32MPWz+1d7cPHkViqx6rtklLBoMc+t9lfs71lbRGaw9W+7awFRbfcHxPcwYYj f2gRllY6iKFjb+cFCyh1VzyWBuWqAiwf9O28e2Pscr6SR+1gDdUH8oPStzPba7YWqzV3c1jpxL5X hO1KiM+aL8F2JedYA/aNXUpwO8M40S6PPp+3I2WzEZ/Yrsa2gFJpHtNXgNqpeYQ/ypUr9MRu72IS 6xK+ose5VeoHYrfVuRLbItnwLTELg0GXkvhHEfSpSZAZCpgTofleOaxCtcwRBFNrqJ5gDkN25XFQ cHeePGLeEJhTfnVGq+ZhQFbai4yOZI3S86HZwj+bJyaXKKipmwL0Y8RHmXbEQMZvtdNuZ+3y2CFI yVUrzwnm0P1Rp6ZwZ9oA1qZ/fXhgrCD4w9NZZ2qVUhYkS6vlWp7lGonR2rl5pOZot4P24i0UTGCK Ktb7pLKk3I7fWusR9fds41e05m0k3uvYbwAPs1S0IIcNTHfkGb1Fo+J9+HLMWX4hg3KHKpQ9ziDN tuBS9Lj4kvrewSSxTum5FnEc0FLOHEzxcb6vIPirnNNASWA550VAf5ZUWw29QIldS6FmTsHCtE++ bko1ItN1TTuToccA3VS6R1+e08ztcdqZADVtdbjxy2KJXQEkCT1knsHt86pgbeeWd0TQ02jwAtRs q0+bJI/RIN4BAAUp2+sR00f+YXy2fiK+bnq8O+31/DAtsHKcaJEnNJmKzkwLzKOYUUn7htTQ85jK THSUyNud76tBP+ZLjfh7BfovyKP96lShzSPkkUaKA/UFEqwvoLiny76g7HKBeZuEOl7+J93ecQkQ aGsQAN9Ys2ed2ZOFs1o9mtpdEpErl2XPd0TFSGyte9xL3O8T7cRbupkjHWKn6lWzIGWtBgKKBfHX yAQsnL+nv1hQYzvA5ejD6HMGQoWZqP7C0kbn2rfxT4w9STRJ6s7MVJ2u95crB9C2We8zAxvz5HLq ey1aWWKQ4B3oMHwtVY80qdS3E1D19e2EieHg6+lN9G/Fx/k+2ay/agsa0gRND5XA4jTT/pHhsqlO R0Vmt3lMoSk2BuGqZnFdAVplK6DGKc/KaNDEz6wDUmQ9zso4XerYAOBRw2MMG+neQTYeiL9PLV13 a//sc5IWzLZvzaTpzYCMnOb7pAr+Bo0qFexbjzjeeSiLA/puHNZrlyQkD2wh4J2H0glizA5tYcse B0LXtH2b6+MssD378P7Oo3lHgNyx5Z13hsjI7T7FJPKI9454HuNXZ8wIl6BHCccGHVHGO3Ij92J2 Qg6/My0/kciHxYFnRjVo65bNzNfdebSvHsjuKT1cAns3BCcY2eXUYL9bQEshQ99NM++KnyMLmq7t 7qgNHY9GOFPNS7mzYejSYu3UggDGgXc6Rb4zrXuYV+/iegBpTj7aszMO0PUJ02lyd56cRwB9Tn3U V6yWZruIhe66rS0H2gG+Ngtr73QKR4LYMm11Vp7nDgmp/SQNaxKS0LjGutBY12lrF3k0pf/Zhdr6 e3jgZ9yFDipUslTG7Loi2G2Js5AO1ABBhkFV7r40rdcKwNc0Tr9zELZ5lIpH/neXnpDIXHwoX1H/ CuN0M0wkwb5NZCW+prn9RDJm8WF5RGPkUTFdj69nH8dB+uo68yguc1oXl0vw5WhQi1oeUMr2J3A4 EP2Jx7FobXdOoA8V+dVZa+CTNL3dv6tN/jZwq79GZvYH85/vbuAWr3SBLqfnqWrKiGsu6R0t7xdC ooaxpaXivkBSromkz7509VBCRSTJ9Ngna+GJjUNi196U7RutPE8J7YQaJeOdHpJ0k0b2SIvYx7aD vuBZopzphhGKqn6p/s6TrtZBeE5aXD4YAYnQtQXm8LQUIzjKjYaHmjz7TJ7EESnLYCD74mAgYN0g psc+2YIBSTuif9bh69G000Go7rnNtPOxmLasE9O+RGMbAnDqIyaVBjWuq2E4LDzbUbcC65tu9Q07 zJfL+qZcA9YEpjGvXY7+f9iiTklMPHct+LnvyIwzhTkEETI0sF1sh9rT+70hBMfi2hy2EWzaxJyZ f+VS8HMPBUE4+uu+S+8Y9EilUU2CpfczzgjB6RreIRUTyuulYj2PtXlH7giU6EXSr078Qnw2oWfM J3I/CeaU+qh7frpjsG6XMl23AK/UpBHLSk/me1Jq92hhW8I2AF9aI/QcTzGAwK1X6r0jwdz0eIta hMbPxmuETlk7N1TdxGDVDQOivlxWN3GLyHBLtLwxjFAq4+ZrNTAcykddIqhts3TzzkLpjvgYHrlR ZRyIYhxGm6tgn668f+da9cfTtnMUJLeUwpznUDM0n3stGtgqoLBaYJuDXWzjIr0OLRf86axovYUo uTVM1wauyeqTtlaOFpCqj6aVKU1CfJOTjFYdIjhaSTdI96rhHU+xnXdpLkNbzfA8wYgEFto+H+l8 3/V8XoHuRQBhWquCpwJl++HcqW5lBRq3e/+tN/itxLGNMNoafLkscbTRacj9KJjovDY6HyuVLc2g e0DipSnMEQjbDE81eWRE7PfWAIPAMug7ofpZxjraUN7gPBqgw8ygMKRlfV7MnHsxIeI84X5bDe+E inG9JBEt1sULVNsNNIpiforpGjD/5utPlNx1GWdoKGi4vJnsDgJ8mjRgJ29n6XT37DfaDU0yl3TY 2KCW4LM5uHaMS+d33saWDbpLCf20W5JBM52sJQH1bvlyWRJsdRxw0TXNRVcm56PHxkS8xZrMd0Ou RxrS5J0fsoUwDQUOz5Ou66iwmH62D5l7oNTmUaushqOd/wSnsz2ekT/Gb9JCycKzZRDTNES/o0NW rfnEb8zVkYzaJsWD2PDqnxxC9qfWjkJTwosG+R2FwvIz5SA1k3Jtpf63ppxLYBdqKYf2bV8uU045 zoHkPpO8Qx0SCJ6Cwd/bufR3BiwCSzkTZ2c0gq/RPaZQLdcK0jFOD1hobwe2Ovp2Ym8ktq18O4ek HexSSjBx9lbST1KQi3sIAw7cjC4df5aGsSadhoK0hDKVS0lfID0HJrKycmhwhvNG8n7paUPt4fws fxOtcQbSikjyImwYlY450FJ65fVonM6QZFxlQjh02yDZnqW/66kZ0okkTGnM9DGEs9BaS/ucCjoD 7XOerWo2eq8mFuyvz2nnhuZtNZbpPkN4ktq2RdYdrHUC2JH1rgW2iU0zpyOnqiQ5jwKx6cdjL3Ib N59Qe6qCWEWmrdAz7ar5DvK6rlq7nAjFpWuc6A2jRXyNWB2G6OMeN344ZSKfOBBI0dqHyRGsTKH5 kA1oYWlI+0V1v7njRFjndnbcGflp2Yc2qbhkeqi5dYjHhaN8/b5A9a++IBkRj7Y4Xy77gjPsA/ke pqcvsFeDDTSK8fdIuln5atJ5X0gxJgbbBuvMACD36tGfIY68IxdH7drmsI1RjOXZGnf4dLYLru4/ RIKof2VQLucYLxW+OLcThbZY62NvgpvqpK2RsFXKleiNlgQdOgXW+KJrbIdq1OKw9tRa+sSbyGWi a50E62zSjf7O07XTwcuhZU4OOlFWkN66Q2KEVgYVUwvjpBayyY7FA4fhbes7MkCM+aEW1sBkfVwu t+Raocyf6V48kMdPwnKPNnbkqzWq2VXH3pm0bGi2aOnuS9OyLYHmzSLbhD9JJEhaDHlUaE/XJQWN 3iU8ZRsBpzXReizbNI+eB45rL/rJ+rc22ER06dRtHzcKBSXbVCfQqoAzptdFglPj14FrghdfI3fT Rve45nbcRTCMk14Yh/HZR/NIwik1QTUskTLTzuebR+vIki2UgCxb5ClA0+PS9s/TFNNtFxzYclia diQcYJNKH099Mbaf5eCmcQ2uIerjeaEpgk7rBXpkGudcBziPTW6ex8Nks2MVj+TPcmwHIE6PlN6h KFNe4vq/S28ntR21byWkpz0on+++L3RyS+VEcLs8ocBCG9sJ8erAPQ7MxKkvEMoGVfqtOWRK2WgN dQi5Pah77xGz8oylQ8a8aSVQfevnBhgFPQ8biTTKJ/BYg14SLsAAtbTz4mwksHldeW0xIxPuMOaM l5nXezU8Oo4OuTh5roSwRcTYhBHBl3YIbQuootZPaWIfeCFZH1WLRGvhG/3r/6pDgB7pNhm1ry3/ JG+QdJ37geZVYgu8nQEFTrk4NZ8nsp7IJtHONsP+5HOy1BzdXgiuCOb0gFkIS6/FYXNQmtwAndZP aXqFUa93n2GtmF4CuJ7yUPK0mv5Je/zbng6gvVSimMTXXwwO4jpZyXLmEzShmj7nug5Zd5WSwyBD 0aVU1iNCKqu+fwM/4+dC0+uYn/u4O1hAtMJzAtOstElpeKTl7ndBwLSF6DkGGUyzzOd6y977jgYH vT7rIJkO4J2C03m7MlyuznP7iD2eFKPH+ft272hbR+sEc0C0Sprsvo8WmLTP0k2366wZTt0el2cW DEqOHsk4+ZAbSmSOXzSuccLkwp4gpzOh3ZbcnpFO73j3KI0UGIy7FLq5rvNEBnvtYeGEzrAbKTZa dBcFtC8IePWozgniINK/To21qgQSpKc8XmRAbordYQ69JCA7R61x8pzpULkVfVkOr2fb7wtwDHsp E/j8fB66Tvw3b6MhgmFMJvsZhVm9f5n0j8uhQSugXtNQ0OY8lA1BnC7rlOO8cCiYA7dIrsfpwC0O kyKBM6pn/F6Y1YneW3EYCrReC8ARWeu1+tRrP+vxXIfAKUgp6WmsP8dv1hk63nVkZKWhnUGenQED crtkh43bKbEhjRIb3s7Axiwda/I50tkbqNn0mb8jHUI0/oOZxtKaYHTkPmE1ziROs5otmtmbv/Pk W3ZgsWUdT306HrJfLeFxDHAX2vrZG5Bl1Qrn16DCEbxgW4jlWvmJlqv7q1hGDvMH4c+1Ix196bhe e0c6bP8oJuautTSsxfsCg3f9d4PaSyCs9q9YqkdH8SJd0PgwlXdywPTxfMrMbpIPQpHqs/wkjuIa 1YrDpYNNXwEq2Mbj82xFDluiqCM5XOTVZhRRviyLvtMQUuQ4FZZL17EnCOc+u68s8ZTWGdi+MlaP cSCifo3NetGWqE2lvh2Xo6q2g6mopZ53VMWU2HJpDks2fTwVVNT6eMrcO2AltdPzlFhv4EKhuecd VbFKx+cqYmn3gdyP5EGmLPcw14ampY6/89yp7Ghy3R/DIJMvI7G6h+xx8+AUOdBmiIaDd4jwszYp jnoXtAk/WpijUSJbVGLOQshSK7OPFjpjIKgtPguJTHg6h/zvR93/ZsSzF7QIb1T9oIdhWnlDGJiz dNCb64VktEWmYVBlqG4OHo3dNJMKUNS3TDrZ4Kzt0WdVHWZSDW0NgTkp9HcowrpSp+DUkeHSW4/P 42Ei51FLCoehoNx7B4nHBh6zzmHH8Zl3rutsKI+2hwAWOl3gy9EjqbVpsQJWxIbNR3uOVPuvh+7w NNuoO4CnLLK9MDUrcoSKS63t4XoAicci2zsVIY8nJwpTr+15WkZihqnOqUgin1t+FpfdHSddR9lg zfbsUpDN8TbNuv/NwPvf4B/lAmiOVPvWRsKi+sbKyR4NUvXLgp5OTwmaGi1B27O07I4Uvm0XQgui OTppYcCmoy5J4XG/LkBwr7E9M56EZ4kiZUggqO73iU3+xdU0ETSK16Tzorqs/PS555KPgNZ29L/7 udTf+MzKZTldmgzYvcV3WZRomEVJbEtsKTBVjgMMRXqVh573uUpWXriXvAvSL5NSHp2f/KMsK++B 9Am0tpmzRKbY/odlxKWfWe0dGZ+MFibBqJPLkRaaw8n1KSdKOlZKP5P4EujmTvE4602X6Uyj2vNZ pUikWvuD7uxSSnjsiP5V45glAXOzTxIZwrYS89A+FPVtYhKHsyRgeguhebyecm8nGI1qbJuzKoZO O41t+5kbmB1YLKgzFjCV41g8biVutR+I5W5bYDNW42ggTTqDDFc2Oy135B00NLg9oBQucVKOgZCo v7HZ+ZtgUNAg3oLB3A9hqEeq3SNnXzNpx1Td3ufroTsILgfx13VGND5obW6LMWqraP/mkKpbWkI7 o1XS9Oau1IDPZZ1zSjyRDFOzWUihWpMc9/i+xcS/6BAiZHzUOQlhrZtT9pdGaWQrqlE6P1GaCALn FIiS4eoojTarLErPoSjt33wy9tse4u86P2Ya0sMvDQSFjaiWqoLn//bf9R+xnf/jf/+v//l/SJOQ 6gbEF1KzDk4yXR93+n40jybMDR9h5lG2/BaLRyHddB0hwo70YYNmUlM7ZYO2XS5EktBaOv/Ko2US DsrDPHJXUls/CsydihhDjy4o+1T7GRvsRds7Q6QcapeSsylvCXHCozU7tqFM7AT/ZBmy9N3kdoCo plXBJBRg1NDUcQgL9BsLtr+qCgI2qKmTUMCQD6cLL/utHxbOOXHmHHw/2lX8f/AV/RtmXo5QvN0G 16ZIS3A2l2IF13UcyCmgtUktIuQVDXrB4/ZOTW0Hb6fGPvcpaLnm03qrxLbB+U575ztkHtKSNIe3 03LdYRrVas3iNEYJ4jCLAYcz+JE3bEpR5wyejkWFCmUtBXH2DAej2sLVOYNnAxEudr60yhlS73+W n8asNrE5goBKGr2Q2/k+6cy/6dyOE+9SjHeWyDA2nzTDdLXfxzv/6tzSs3vAXIabxgKHbP1UAxbN azIn10yjMcXGxM7XEqi3CDVy2jt8Yx8b54MvTjwVlKAaocOTeHCRE0dpZPdgcYOQC6IZ5trmpJe1 o1/ZpQ7L1TKC26XUh5FTPvfgW+cDrWG6472Q8Y55GRvcJzFP+4OGmrf2bPAFqlli24oOa5x+nDvY eBNzSMx6HBwHzOqWFDgrS4IS9gwaUQ3SU9OQ8HFijZUxJFYeJ/UKnYOqkb9CDcRB3fYRPY54W44D lNOacyahAH9rtlsp+OF8o3L734A4+qnhuPYO4Bnh2Gf5uY0E3R41h76jN8YD7d1js5OlXoAQPs04 rafBoJTU4XIvpGW5oLx+mnNefJpkEo3EzGVpKCh7AytIthHyDBGZoaAGco8yBVrjROguKuEdIjLL Os6cXHo9snckpqvNW5/NG6WvaCp1eJ50n4BqqI/nGYcQR5dUJUV8O9/oIvZXTkgCMo9ImRbd9XPC /vcl0o8tUEbakIKEpp0XM2RKx8W0EN19aqfsJ5ztSJizHWGAu16OwzSari03tF2ZHoY7U27+g0r4 Ug0JbTpBM5qGLYkl44LCpTdtEApbg18ZCfq4dwDoir0drZrZy5HqUvF8JNS8aSToL4jDgAKfVpza INxIhlojwcSnmQGC0wahVK1xkAFfmVPe+vGUd6HzVj816yPYQ781fTmU0NqDQwxnGxF9afZyXm47 k8MwZou/82gObUi3SF/OhAwF8z1Kb6l5fDl7yojVGvpcfm1M9UtG9miIdB0CvTZKE4OnmRCTy4XR dI0LpFCtbx5xfUZdcVrfaFi7BioIerawxpZFQ2sOnSv3ni+0/NqfhSqzRWNkj9w8LlFomEaIoYXp F2FjGbTl4rDA0TAdkdCxhumJgDJ82quf9V4CIhtrmH7pHkwM1OfygX5v0J0iPw7Q+r1Ry+Smh/V3 nv0uqEHQ700mysZsEsWQHH/nyUdAkhj2vfX5vTFRNp+01usMgiYIpT3OLvXjLbGVllVBoNt40LO0 Qraq+FHSWGdS009BSwdiUSBnxv/UCE2wz8UxTS4wErWYNuFCthGiP/OpmrlBwWaNaS9cyGR+fC6K pqtfBcKFz/oRg6abiEfSVz/u40AowXjwNZY+v6yh8Xc147xQSBstPkOdQbYOvmoLHqng/bgEbLoZ uGlxjS3saNXjsLbRuAaFfvLjMWxxjRmOZ5fUaY1rDSnlaVx7wU9Gneb0z6W1za7tKF5EDFOIHp8n aUHAJgdLmVJ7unHtmR5Iqgc2pvLJZ9VI3YCntZgOvUZqtlppwc/fYbZyBeQvWsQGvCaZ9zHSvo7/ WWPDhi5jLiBl5jPMm+qVWeeuHRag+iHFJ4uyJlRjnsf990tLHDR/L4+8h4nIfdq0ret02h460vhJ rcdfefRGHLrlWS+F7+b7JBf+qiZIiAWuNcEc67Cn41S0fb8LonpYTfCOdX7WgLef4ayoAB2Wc5hg 0Zc53To8zHFVoKKtCTRaAmXV51dNDg9zhYH2QaKE8FjwsVW3L2nDI5e15tyAor6xVnqrTHb6D89m qTbBeRwoSsdh2/yp1AbPk1OOjfnSfN/88G/CdDiRP2J+TKAtTLP78anUrK2bDBym37EOYxP4nFZr mG4nBHEsstFaWlJ3OBMtLd7Af69Ke2W0SQrVP+VRd+VqEsC3Zm316+9GvrUWJDjc59dYAInT+fFK tVjAuLk5NIew1CnjAI7jGgviO3JjEro+R7waCyLQa7alD4sFfMPFo7doP8eJrELCw48oHJ+W6jG0 9WO7wejAApdtIpJ1HXno+w4Pc8sOy+lncsB6g1o83kyL2/77YV4VQ63VftVM+fkrl5H/CzqGLd0N 7orWuROCIcPYtRYniXSp9Mq97yBQy2gpTFgKX1OWQo1sV2Ifd4obGlaZ2/gsDEji6aE0h/FAC4MI xEqsMHjn1pSsn4rHwiBKAVI/VhjMuXVkkmxmG+/vPFsuJ1w+eIxs7X6oMa/LtZ1+ynnD/GOkD1a1 fWWXrsnXcVd0OaUNw6g7A6dWKumys2gkOAEpL8rjepBsuY90PNU0A93dTT5O1CHUZOtu0hJdEOOm FCvBqUMqqgosrs25NYN1vWLUx75VFAeiYdRMesXO4zAOaFGQEYHaxH6fooBNq5q4XBvf+nWAPRdL Ou+AhyFtvVaHfYIWBQHB7vp45oCHgW1OSQV6Pw0Q3O1+XmSXEXR9qhyXct2IsC+P1rnlHgyAPAKO BABZuf4abasfx4M44wE7T6zB4Tqv1jmCmp7Sn70qJorxhzpnnamg3gyyCbBYMKcIDGyLOXj02ykx BMD7yNX6a8mBSZsac89hnaOhTQDv2ELbBKrLz7JxKH3riG9YQnsoU+Vjcf1vVPv5mDKVSwdkw9Hy M+5lulJ8K2SpcGa9OwoE8oidW9LBYS1Loc6vK5GpaJRwiEzZFp8lHSIQHpMVR+5ejnY8SBtHA3Wa I57ImLo5eZQpaOms0LauP8qmA4MFqaRCRDGWCmXluie0H1LCmHHtc+xjnejCdUhCIGjpz4IYkWGy 2SiBDNM6+/RLNIPC3kAmYMgyjlNynsaAQsLAC+jSsJY8nkcLGVRLW9rJM+0QxbwuKRPAfSVh/05y o2VeTTuTKcEcalI0KqK7+9nHHuDCS5OJfdDIVmp2yPw45b4xcJhe4JCWbcGjGlPpe0JYQZE0E8/n xPB1oHvbNVqjAXb7pbX253J5//6T/BcG2KWdO5ArsAg3JwmNKFG3FNhIcams4V7gilXoj8tT7MQb PrbB6PuLR3Dtd72s3/gsz941UdZOj826u8PctcNdhNHSY25NrV30pXkk6l1SBXrDP/YUln5YfLNl En/n2e+I+AWWfl7onUHVPufXuQwoaSZ9PDxX4j7uM/1cUiDjPTd5wTa60Gfeae4uR2sdRM6xj21i u2y9wrTcHdY6tmkFalHLpH1mUiac1Q3Gdnee7d42JGQ0Wp5kMCLlLrUWj7ap2mh3xBLPjxy1vR82 S/Daa8cK4oG+nzwhN+JnGbOIR9GPnFOEnJZH/tzeD4F4Q42DvJ+VEK8WBwdYt9LvLb7YDoFE3W7A 9N8Fw38jgRjrne7CpepRBWyL2lHDSjTPBWwiEyxZanLY9mgwgMv+Ggwm8EYni6l5DG791PYatT3R aPzsMH9YvFyJumnmSYhhkJ9tf4sETLk1VY9tT6kXorlapJ7DuEbWLFrtTG1/5eM5pEZcieaJujHj N6eVaLnzhlZ6kvzSGyIIIu958roZdtv6APORmuKU/agYzCmlNwaHLpX9SJpgENVohEk9JJbqD1rt MEpfYr6hMLC9+MfPcq+6a4NL2FoVPHajXBcwudz4P6Mg224LbBPPYW5cTqmUNRxIK6OkJ/d4ROD/ 8HJOBFPry3nBHLoS67U5OJABpKkCar1GWXrdo5tlagFNSe0bmzMRNiX9w1rSUpreODKG3fOE3YkE UApxsI9tZT19xjagGazkFzkk9fSQ6rFes7yPGC0xlAlTfx7Z1lFa+tkCchOywKaRgIU1rX58FjgN CGVYmJ6YYWUEV6f84xYRplvj04jGzIQynB4njtbA/M0C9aTndAyx6c1FRv9Yu4pwCKqntT946TnM Ub0Vpt+6MlAfEjfsaFleiJoJs5iFkr/v7agXoudYIp3ix0SYRWoKTPtj5fd2p2ND/agZIOl5tM3G 4c1oFGxktRRyP/uO6GClmwylMJV6l3l0G6PjtbE0xwfYZdCUAbtHOdq+pY5U0Ft6xgdMuCCN4TDx aAWaSGB74XZGlOjV5eWce0KKRjYNyZmwPmKknuqrKVMVmI2Kza31S6MQThWHg6p47zuaImpJMCVM iGd3rqlnhyG6VE2iuLeeLImOSwLDd7LDj03DdMQrcGnOdpgSg9OS+rLcj1QyentS6OebIuvsd85Y L+yiXOZch1lXOV1K6ufWoTx9elprtubvs7XWlNORoGZLD2LItpSLdIdR+q61gXpAG4MyuVJsEVZ/ 5tML1vyeYFSbg52KJ6K56sU6RNj0Y7uQyHYyoUOmrMtjWlq41btdN2Th5KeMJuG59urR5v6OUsAU pI9h091OhWXoxcR1UgWHmEsLTDZz1sZmh05JBHGPyHFj5Dg3YMnIwMRbcOqUsLaMrhUiazJFPphS Y9CC1CNSuPUDjHS0jJZJliQbylYMeFxz0YTTMDk3zXko83zTjOMRKdzGMRASpQXB5BeSxcSYDRDx 971pKd2xmXqZIzfmLBaTy7WqWjtULgkWrFOrbO86aSZ16B5Qc7/BBLFUKz/1gZAmNIURu8MBb9oy lMx6YOnUEuPj/WELduX8Pdczo7Uqeew5LVjj88jQ1+NQYWob24UwgtzSOxXFhVvS43hEP89YIvaq qHNMRd3FJCaH56m5ZfB8SrUplUUDVlc36jK4lvW1N8Bi07rZXk+uTMT5D4X1ymiw9zwQG8cKIP3a MhPZ1jASPb6elO4O9fOGTCmjQYbWoZbikA0ez3NDepottfgMRclsR2sHW8F0dz93zQfCcrQUnaRW toek0dzj7E2zT0dYW372Ei37UGchl24ihyTE/rLsM2eJ1PnJZ2ndz9GgB1w2lJpB7sbVcQiE9uOs AoDD0KwULTlQbV3xCLhpMEayZjXmyf9q5HaKaSb7O04qWwP8ldRtI17yCKRuG9lkHt0dp9RDgO+T 9QmTdzxIZaCRgHnaLe4TEpi/WaR+Z6NEPUvjNBOhXNsnZAFsUIvU7zyR8dx9qjP1swbkM2ZswlkZ kFl8aS5BqiFygvmo/revhUGvVPlYmke/pNIqmsRrrJ4mfUSY6cu0Ax2WbUNSAiO4mE0do1cm22ic V4f7LuWOFxrDpQdD/Fxi+/tmIx+TJKTcWG6/vnMrwqEuLXosp3vYj/HP7yxFPU6MgxBY4sh6cJd0 KTbnmXQppuNcs0sGdblNgh5MFU322PBOcpyeXPZuJqdJeutJCCf7IeaV0B22O9t1XXBM2h6DsTyY ubrT3lpzKBpiaw6tM4cyvoS4nJKm7fidDPqvrNMs67BWNBJKTu3fN7L6NOsUSReggZZaXoiaVZ4x Ma2ftQoSOSBWqybRdzxKjd9cakuldguQk5E+4kuXwJ3bsLsjcaAtxUBDBkWOjGqdtdamgXoKiUfd 4yT5Bhj1yKk/5Bx8Gq2/o+BOZ6k8fQp3g7fT6mRPslWXZPQcf7ezjXFiR64yEWoGsznNosdj3YSi W3vno2xt1Gd0i1snOFt8yFNm64Sr0FqqQz2m6whwHl+GOSIIo+b8gUa5bu1NvzW0wmff2jsNIdPe FKJHxL20FhHGpnXM3O3/HCv49xtf0/FBiCfCCoo8JsT6gH6Qj0iuCaliWBSIMwoQVo7U4XEOv/ec kHhR748ZVzYhLbKJVDxCbHfNFVFCtSqYFMqKganUgl6sP1LbIfr74yw6pwd0R8RnVdBtDAAp1fHZ TOxs+ubWYuzEnsqPaa/FA2ZhFTXH+rufu8qNxOn1/UzeB2Pp2fsh51mr+pMO5FSh72cC1dQrSSOf z/vJoMceQZ7lF4aE/iGXfl+H/fmmZapgS9nuZuIfmO5uuSmxLeWVeI52ajfCdWOWp2ojDbbPy4lb LYi7L4+hsgY2ISC1yZa4XLaUDRkhaGB7QXfYIoiEltkY/vtq6r8qDBpKPEn6bK+Ji0jTz9Cji0hu 2wEM1mus7+Ca1AVOV3nOhwcOr2d2pMx3wyk/L9+17yBWv/zJPgjLyK1pbz0RCczCW5/hjazCtT6Y 4sdS1lQdEHsfrU00FBM/3Ia3so2BFEweD7gYI13mIRq00RY51xU6cUeKcxoM3iaOKYB1l1u+d44X Iu/rxzabbDYhbYUaXK6F20YCuUcLNzMcjIUhuy5FgtNx5fZPKoux8/TXJdrnNvBl7dtaD+KENmI1 TKcJuguOA1HLBpZGV4Zp7a47MA3QLtSk6VOkmsepMPedlehHqhU9nNTtdiSPyMCcbsWRu+Mc+jsj x2uN0y9YQHD33KvHou3aZYNJdDzKhkSO5Q9hTdYB77UOJJZjBWidBSi5G6frli0dOxjxjKz9jg3j cSAww+vhcRgvaWDYvU3YsJGxSAzVI1pQtnah7VGbv4WU2FCEv5yybjiqrQ62GHzs1S2HEq5uqgaK uMuhI6UCWp1pnyq24EuSTtMT+Us6Z9wCAXJeFJR8bKV2j4HNRM0ACmqBus9ATc5ja/4Ok+hdww1C gYW2ue9CHDpFS1fWHSz1um79At+b1v9lNjufcwvWxbZ0towuR/99wgR0y3/AAlTMn3RdiRMi4hbk x0goj4C5BWmUQDBQKd+nOfc3zU75faf3X3TdOum6TG2qZmEr5CsfTio7MrCTPh5r29xJL+q129He +sYQaJqja1bljCw+Fy0H0qXXRDreiQizESmJ3c9ayF17BBgOygu5M1Kbz47niL2hxV5NpHMCx6x6 WxmRFG5Lt6xaPaABT24zkZLrcUnSO0Q2oP5jj2fOq5hnjVOekeaYA42v8yOlZ7mUSUrwLmHpImw7 d1C1pZ6epmcwJ2X71hzmnm3sCb2d3PqUCiYThFRT8dgkVBvVoM0kG4hYqcOgtpE9csO3ahrUKFT3 d5pIzB1yp6zQpepMPaEFUit1JpmFKdTnXhthGi0udTLmu485UGRjnj8oUa48j9zHjTZIY3747uVz inhc2MZpRwAoh7kY8yMMIfZif9p7WRmqr7hF0MVJG3ZBla4luRyOnrHfeClpzAkP9UfSP+vw4RTJ aB1B806eeYew3UsPicDuK9m6pd4XWhXROD1ZOZHk0ZZ7c3g9Y4/I8cny6CRKEE9Y7cDz8Mgy2gUO rWJ52MefeyLEdaQc7XjQNqyFgom7E/njHIpLG/JtSwmRcvJUCE1sBOfVVn2MbUdi2+NpEezt4PvR PzSYP/RS+PAsVwRSRnacmDKhgH2ZKItDnSlNpANqF8QwwTZCLohZhDFZlo7j7y1iMDTPIWkkQ1IT 4CWvZyX2vqUTarJoNJgqemRq5XX7uocj/jZV/JdAkwa3GAfZ4tE8anQrd7HgTpKQ0UMf6bHs7czZ 0imco9Ego914jQYveki+Nv0SXaJtPXbAoSy25FslksMYzOMQLMhHyAjMCeMRYtCn9bM8YQ+9AGjQ F8MLftCVS20w/J1HP7YI9JmKbZDqx0YO00ONDuuCFlpDazzJyB/S9Lnjorp2/Vv9zXjO2C4osx3D ixcwaTOfb+dsDW2NpZ6m9jHRZGk1DCE49VKGwXkX/HSqPR1yNy2KxxLnTuGCFg8jPfJZHV+OZqqa yEbfNzrb/UUoODY4gus2gdPsw7ju2pAGh+Zp+mkJmJDWFF5VQNJeO11QPMIV4U5SDC/8wahTJXjM olu6EuK65ylkog0PSaRO2R96Px0ukEaZDTZX3W8ez1PzVtDI6kGnQg1M9yOl6LHjGV0aMCK2EKGZ hzmqapuUPY5704UmVvZ2pjUXY+aERteSFr+dEwpLRJntKFNBd0pmkfsYSJQllkdYolDfa4+U3dHD caCXk4K9HALqBi3pHGadax8ZcUKriG1Y9Y8pYHHdbPQId4JSOVFmX822ev8Qohe/Goh76HuZr+Zz ft7SV9OAS0WxHR59NaT2LNml+duW94CsE2175wHbic+tQVbF4baYvpwOLV6iTJSAiZc4zTe5xgHg 3JpsS9lanZ9lq1zPVnf4dgxgY21o8qlV0OVCvpYa1eb6DjOMdxnV9OFcHaec2YSypjqZBbu/y7lT SEi3tY885zoksH1FaR5XKuoVwg1rNcPX2JAqpe6RUHBIQPJs+rHFt6NmYY0si62+nFAuRC6qD9/D lIzIcQadwC9V0sx3BYHNioLJ0SWKWWJ8S4d4odzaG8BAPTmtzB7a5XpID1tFojI2fddfl9xMyjU7 ZOLUs//u7/JbVHuwG+aNFIdHweMjNgFRLXXjrUhmesdfGvTE4Tb8VtoJ3R97fHkrTI/aJ4vtNM4k rHDiC0WxJDqGR2aELRzFf1YEsRjK3hsbGpjSh0NHlHKPBjiGo9iGshmLsRmIPi+HlxPvPSCcsI8y N5RJCs36E1bhrJy+b1uMGJeO75YYMVXX9tXj49FgUAA5woLBi7AxDSOfwUAfzwUTaTYol3Wi3bx7 /B0m3ltA9Zo+njl+J473uYxeHD6e66oJ7O08eTS1QSxEpIzKGJNrIbYzou5An84LsZFQXUNmdc5i TEpAHi1GN67UfEdG8gmw1d+p+v8qCmxU3RubG5gzjMNpaAkn0pcapU230UyEz2ulmNTSnZ1NDkyM iHO42/F5ch/Z4/Ag3n2LOE7nGaeZGyzngq8tCg6BVsoxTgyU3M+fuOBrV+ELsnvSkvpR/WHciFRq ZBuWS1cS77aD2Y5GgzqjAdk88BsNGtwLeSRbLRowPxSfX1s/WuywBLXZTmZM/ZKbQ/L0GfcdlGwa CtJEqOnlENXzxecZJkYN64L81AVs8taaRyhH64Id8AlGMU0MiwQMb5fiMe/c8T6RBIvm0TmrIvuv X7WLR02MbezIHNoi2wQL+s9a7deOpyH5Lw0GEzlk5/nDfGex4HEB39soaQoe4+7akByCFsj37Y7/ jRts3dESkm23PtMqhrv3ERm7fakP5DYS8HexKK3HkcEy6R+mVesUWPaeLjiG789qvz4QAhb8YSiy OI+2gkB3eUB3hhpqYSQOq4ImZwY7SD0//VtIhJw7JEdW5Kx0ic81F+wAmadmCYE/RDTqOYzTWoRW 0F9b3pkgNdFd+JPM6VqQelwYabNpLzMhT6myfcTF4AfkG2vRNu1TyaK1hCpM8Get8045SBqdGrSV adDGVB0+nq0dEYlraxH6gm3k8bTuchG+y3kAMEc0iD8kFmIy6LMsKNokYxXAMmnHhKYrMVaP02uN 1AEEA4vUcyZCeDnawVWPrvcaqTsYIxS7Ho3UXO14OLyccnYkqKtx+sUNWRZ1qr8SZSB1qWSaC1qd EqcnfXPUXnAlzaiZ18Q/41pNJgNoMgU4jeaWCtNlW0qUyNuObqePOokfRKaghpyYisRSafoYMzTk a3N1h5mn/iHtfB/o/jnJ/TwBbmhh+h3w4I8tNs1MDmu2eh5jQwV1sdF1IdOqmqJHVGobO1p10YIt T74hy6FSk0d/+LhHKErfnll81Fsg4zfRFoEUoCvHb2c8ka+tPp78jkSoJZ94HInEcEDUPba5vsMc Bl2u75S7H2CPbxTTmLMahylOlupx2yXXvCF6nvYHcwOBOT0ZkcVhLLgNLcBVwWS0sTX4XFyq6RbJ yLBGRre1/jiMTfSTlLXrNQLchC+2XcVWxeZvAA+zciDSQj3A5dRsCoBWUePApn+ws/ZtZd7Z0iao AtW6YMrJUBV3n/4hRzgaZhnld5pIgDandY5+T0hOpqbyriiT63G6ohzDdQfIlOg24aE6EqLPzt9p aigJKH9ZoA4zULNpYmJKZquLNphIY5tOT8xYzCcK2kpFsmxa5bzzKsIMl9S7w8l11LSDPjatciYf lKC6OeuH6JC3r+11Bjrhxa5HqwICUYt+oB5JOWlrYP3N0ug7D2Gza59p9IzHgdcQ8jscZR6DPpU+ 6tXLDoejVoIyDsuXBJcbPGdvgMOSugU2ybRks2UYh1mnpSOArDNKmYQpUlBLycS1eylhKtcS0CKs SH2Hb8RSrOXKXs7iBuFAk3gNwy+R+qctKh8VPB6LbHOYOH7WGoL+1xwHqqht/623wWRyvirzvF/L Pb7QZu+o4eUeMzeH5FKg8dZ/IekSrdkm95hS2nJg3i5rQ3UWENw0VNcnVONQYIL1pAJdGqqbxAuc puYwh6OY6K4ZtlTi2x1XEvS2tEe0MJYfIWqL1IwN6nMUr90ofDyxTWEZ5rXhcjgaJZ8BUVvjsyJC LOKfF+Iw6Wg5vUOVxmLbSMQSyTA2j99ZPe9Q0WGG0XEiKW+ciuvnIyHJSU2g76iKtTp6OQ6PU7og RMqq6bl+QI0Fi4GJ7tYSTz0CGfNOjgQLBF4Z+11O+Hb6IzFFlTEst7o7zHUdghDDYYtvOXQGE9Tg crFKi7UKOjct1vpTrOFqIOmfIS9n7SLS3dA2hZXSkxFO+uqstWdzSGUre96QXIGEZ1AVOzUKyN1j JIjmaQ/70Gd3ZzAC9Zdxq92dpp7XBm0PxmOMRim6tTkEP49QLiwIWia3iF2O06TTUocC7loUzGUK tnxgMIHDyc4Rxwm4eakbYih5DEbN87nQq31oQ0bqpiz19KEMYdPWujq8nhh2KNUY+9wNYas7fzA/ WDcV7Uc9oNJxf5SO6ZSqeoTXyq3tAWx23t0DMuFNWTJ5OEudt/KeoIxEfMgRLAxoCvVIJtC2eofe ouNRoycxIEkRh/VAvOuFKHn98RY1Ej9udUrPmc13lxrZpnbi+W6ZNCmac7zOd9PvOMG/PrZmGA7z HI+5eJQ6vq57oFanxvart0j9BE2/HZ4mraNOpzIOYPaYnlpASgiMmhszOcxaO7QkaC95lBq1p04B RzX92zKjFH2f1vnfgIUZWT1q/pyywGxp3CtYeN0IvzFXiocHbtauJOk0Vg+s/Ni0pRZQq8WSHrnJ weLAl63BubudJhJBJKjZRLLsAmDGESuiK76cbwxrf5VBEQnHMuhkSLHrcTqqHn38zvP4LYM+224M +tQI7jCDtqT/FKh3np8wjeNACqbK4hD61IIAKza3ud9C8I7SWgwOt15H2xL0qeqPJjDbDHtsnt19 avW8SkGHqXYYZptuwh4OoZsiO0IKJRnGnlqmrM/iUmhBPzMk0SqaUSYjgrGjnLJyS8s7sHGoqb3L IGxH1OcyyNjDCeW006Su8VG1R5WSI9QELscKgpdYSMeHLpXb0z3QaDdqB6qHyqwiMIVjh99aantG e1RZXq4XPE4UcwnAnZus5HrFu3ZwHCsJ5jII0VrQ1sA4lO6uZ0tHRyWO1f4zUmNeRA45J4dVQcnb BZUM06R70bKgBoetW73qJrDGeehedGkvdIdxrV6xweqz2WHIipux94dDvnQbEoBquyVPLdhKwFS8 FNOwAO6OFKFNdcTbu+WlR7EBlU8Ka9lrBWw8kfCABNH8QwnMTu9n7cCtbMgypMo7cKN6sy5121va C5jsjtLCAxPgnBN7z0Kat5Vo7h1KATOqOEylJIfeyMhNRmMowVpCUTrA/FBT6CQUMUHT4pJbWC9p AuG1ZwGRMSJKZdXNyp2wep4bpH9XOwz7zh5be383k8omoJQ2TbKXYszYXjV59Bc+U21Y17i+bC/y cop0j61B3m/oL6w5tM4cyuw1QvQISuV2JnAekx+ZIA65HqcgjrUGqBMtUbQRjYnCuR41I7QNPUF9 Y23oXOOnTMkSmPzn4nXKHZCMtV6bA14sYmiC7RIwxCZL1UzTdoMBr9Zrc/pOtFlbHEzaZ2W9pgWO IICtpEn3Ym11amT7cDHiMSJuq20TpBKgvZrLi7/DXEdvoK02eG3u7RIKqwwttkmNs5JZeIQ6ANHD aoKX7sUGO9mlXHtpuYI5lebQOnPoz9p01eZAwA6/1tP2dpit6PwN3AnkbelMQAZYc2ibghGMWhhr dTkTvWuBkgRxShIUSipyGdpS6xfAPGqOLw0Hlp/6R+zV4ZJgJWIYJVYwftd0ZBypTgh5+j9mNOTu cobWXWAiKqFb3imZWNUZWpgIhLMSJxgyftfK/M/jpGEGSJ+v739fWPu0MdCmWrAFxTOfenR+f5IK Tj3PDPSweqy/9GKE6P+WmhmCs9TrtW4NrVKWWGYL+vGCzjd2OR8LRdw1AZqklZ5zz5VMQkULtUHg m7VGvBGW0tl4BE85wHiSPjk4+YjIgkLLgSmwQOSMJfXG0MKV1xPl0bgD+TM++ZPKR7XscGagleeB xNfMYGuGadaHSvEIro0cEadolNYfwIMYauhnyNqcpQJFm35aOBS8JA8mXJiax/FhPdvvpm7/2bbF 8IhfsJZaf+JwDBIvOZGCaX/ULyzv4LZNr82cLN1RCaySBu4tGtjyE9hoU10J8rnYZatE0IRqD2pN aGOikrVoRUciQV2KRzUUCSxO9xmnmQyOTwCntIxUl2oac6bT2ei9uFRk3bZ8oUWq/LShFqh/lprx aHtG26EaI2zhgFzOCMPj5cRDu32URdvjK5z1f0kFOgpj5i5tEPqWkSRWN05RroFxI0pqHm145d6h wXjs09KNbvFz2OP70ujnqoWhAI12TaL1SaJU1IfiBGu3Ww44BZmdqNgmG0Zyx/AY1eItAcjgWMU2 18JIOZ1rLQyZXkv+LBXZUqX4DA5KpYpYPokeLW0ZNm99TqtJDk3Pj9yF6XqFCvS9inTLocR74kta c8mLuFsFT2fU9M50CM6eQ2THWQrihPsGu7sapvsTplnKyZIc9jpNyo17nWdCRSQ/NXxTyYil27ta TKOs83+pu9aVy27l+CrzN5B8SGpdH0d7XSBwznEISSBvn5a0nAxM1Wa+4XPU88vYHuwttNSX6uoq LabrMw9l8LRPziAfT8O0B+okI0yHFabJ5yaVqYDvTaPlvpE1yPjcsmfT3fULzA3fc8hI0SPHqehR KLnwjazPTsKXpJqB/G+Osrb2qAmvtnwG1WOKPnboI1qXLAG+HC3kConTW9l44XZQwVTrz7WDyOwA 9Atl9drOaXUsZwWNqL4dt0AcpmY8livsxTWRiExrB699+p8VVk7HlCzGgnDUCzkKx5Lqwj1wu6PV UWJ6OJuLNrRUGVJazBWq7pOCwWb0lPhCy0f6nT0ECcrSH9sK5s7j734h6YhQl381ZedyTsE+9orc LwE6mb5Ojn5x1P+MHka+LlB/9jCtvipcPqqjXitvRDIN9jrp1ocBG9G4GlGC5cZQ/3qPk18B2u8D sAlS8GMxLDKQoGkMt3c34aovLCdXJwm8Mc6XNjoW4U9tRBGZYDSiz/idsabFRYMhWhNorAj1SIu6 Qk0dTYq05ytWIP6rbeg0SWecaVctQjhaqzVkJBxLdqtWI31oG4Ie9s5za72MhjpJFsOQiuFYrAYO VxoQxxul2kOSYnMQmzh7cncGDEPNoUuUgKr/lsxy6N6xQYuIYJjq5Hx5uiruTA6penZo5jbQm9mF esL08CVYVPm64+sE4LQft6OlNNtB/NZSYS40W5kR+fVC/k3BDwoblmQdL6eJQaOGLmdFd6NVwghs 0dGCLYlFfmFw55VhgbMobGyzOlWLc4N8NbSpkwaFLXuy2TLnOgbDWuxnRAuIwYc1oyJyZbE1Iie3 efQeE9LA0Pj88PHYsJorZ+/VXUoJLR14Vx9zLVLiGCWw5asiln7ybarH0AGiY1the2nTxw1BAjcV c0k9kF01+aXdcgO1FS0+H4WF3+tDK1Iv5KiT2lTEwgL60eVAQNxBRtx4OdUjB+FRfOZVfBJ4Lbhm UbrwiCEDjn6MGtqchvBPb1TKPkPkW+oJ0aiSJ3tNr4ctg2SLFcEQ9QF7e5pC68NeI1E61GyRZpyK oD23HP0zDWXX08QiLTe8QkGIVEnTwCkLYU3HoS9Lqumdoa3X80BK7UOaZPU6v5e0ufY6CP4Mw6x2 9DqsxNG22uBp8pXkhvXaFPRgnCJx0eBhen5dIBL4JGWCn6xiewN+1m1pJ4d2Afaa1KE575NjYsZG XVsOV27kj65Z5yHjUUVWk9au+QonXKn004WG+lF9s0jGKyIOcCK0mJ50L8/GoX5YvJm7mpREUMYJ tYyCIFNgmi+2fN0K4qfDwOlOyJjOi3zDtdcsXs2hvTGgRo0osMg37G6MrlPGIyTo6xqfiQ5DPkUs tm1FPLoejQN5xgFUec6SVL9JdBqpO7f4Y54SsqCprmE11Rjy0LKnsYnO1v1DaQdy2xwb76uSJnFa G1WLuy3t7ClDspdMshfbRX5jV71vAbEc3SPHo5jCIoAzPdboiGngZkfHVIEKeBj2oZp2mD+lniYY nLdp2ulgE3mknUUk4Ocx6bsbtdFBhK9Q26pw2IyK42v7Xk48BHmFaQ59gGkGR9lkRbTrRFlHc+hi RSDo0wcnuVQ4dpeyszNIpVbQGeTol5FbJYP3N9T8vRLtZwBMvKRN5ujaSLU2xOQMMjx6jjcSYEtT tTAInbbRKBC/TmX6s1Hgcq/8Pb8j6JVU99E+cg2f79f++mgW/+mf9X/Rz3/54x9/+2/KLRQw1PGx lGdwQIY6+kmyrLNXIK90JKA/9vdX/cnIhRKTwfHuKdIv3IwuLgFjfBmtCq7rFhCrvdagH7UEqs4c HdlGlp3+Bs2Rb62ub4111iUwccnN31rCFWhbQzeKsfF9173eILnD9d0QVl1AWuskNu0neqnYI70t dJrM362i7ZLKC2pnZ7e6URKpjW5Uyt1PwJKS1D6aJMrI4zjB193Np4WKjkzYBEs1d8w8sXrh2Ogz ON7VKhQuuzYXVqBmVWjMxMJ+957bC4BSLaenG2UeW6maXD3qqSOvZz+WEAcGSvZb/NCrN1mzhRsP ENozQGA7FG7gWebOE0usILJpHl3+IPX3Aj9eVSqKBnVZO8bGejmj3CL93DqeWrcHOGSsSZstQqod Zp/Q/AQOw+c90PbtV6fSW4dv58GmWKhu0aR9S3UnkprVUL1kMIRYOY3BtsFYcLiWMM+wPe0102a1 +XZ6zBV8bi37qZLn0dc2hqOx4bptTIB3Ars9Ajp4jrJYk8Q37N28aisdJ3ZEapU84rRLQYhOnrTA jrNzdF36iewBBrHoY6y6MIkS/dQMWjf0nhD3S3sE/1BAiZe9iDPJ+sgvKJQXmqws+mnJlZ1Z9I43 gD5azovCwlSNtaKzuOZyir+hYLu4B2hjFbVN7QhtENCei8bpBbQ1PLnWQGFyBV6LAjRDGNfzAG2U Bposbr6m2k5EOQ5tqi9lthvyhnK8LxSEnhIgToYRBlYFSgZWJSXmW7sz72gsaIAmMT62BRbQbtTm x9bzwKnBwDcuB2vm+cw/trrvY+vSMjqMRrQ14aE0XdGgaO9yqtPf9SO1QPSf6hfnmJ5pKMXi6qs2 owU9HQ0FCzckMLXmncZuZ28oCBFKyYhbQE5gDDCjtojhegFdcJnWtfqTC7UT9cxmZ3PVFqHts7iF FYTfzWanXYAElmN8qjbivefFWxwn+rt4NL32Y61/RgMS3VIzCevGLgL5k21tiDBHNJMNXIv+AlVb y2Eu7wRcFAw3NLKdvNUm+U73BVA23+oApkLzhGSkdUPJhHq819C+o9UqjWx+9aPkfqwSP9LZE1oR yXW5ima2Mhpds3ic0hoC2mJc8zdWUhsVYuqpBGjh0MKi6DFKm16PxaL6FHeh8bW+ngUXkGX4GagN ojmhvAqaj4a2iPtMeNZk4kn3tAQBoWBJArN1a6OcKc08DUxERuaJK/MQqkTNI4SYyzyS7htRC8Li gGVCLQguC9Nd2Kv85RoCpzQUPGAOHYqYNEWLkhC1QDPPml4Tt/GmNarFjqf0dABJwyGBMwZwEnHZ Vn1weO9l7wAuHpJhUV2fqQirC8Tk7WgVmqEVkvgH/mA8lpwtciVikRM4uuSYnuk1PM4w7KKbvV+X R39pExYb1IRRGxTPQptJ2wOtQRF0qDWorDVlRnVPTSy+HU08guxphsjEejuMx6L5yuDbqe7lgT+i iCaeAVTj2wmt1mzw6aTbn2Cg2HJbBomZebyFoXho7nJEUoF83aE5OZC2yPRN+Xl2Mverd7H8OBWp KX8styNcgurHSIYiOyvqO10XAAu0QxhZVJ+7kDgd9VoNLpCm5o8IziNuDa/Zt/ZmeL1vjbzV13n8 +KWlEIcgE9tT/hZMSmOc7uxgvKPhITyoIQHcNb0yx+StX9rlLlDgaJR+UEPycIoUizBb9e0G85Ca xrRKH0dk84M0dszNHadLQhrho2J7RvHk9Vit2MIdAPIxXs+DGpL7idSYd+/rOa4IOG36eh6gjdmg 1OYNXo+U7JHmeatjOqpplC5b6okN1jijKgBaOT4NVk79nZYTD20NQIETJollPByygjBoHxbnvHI0 D6vPOqpPZgWv76YaFDFKtwsAMGyT4j6iAGtDba6K1a79JMQ8ysQ8CMHo3Shko1irpI7GiNKmm3Vi UixvItrWBKqdJmbphgUXCmNL2SRRp/K6oWFyjgsuxE8nDbzQ4HGid7A7GKXnBAnYen/S1EvOsxNs f92vgLYSk5MP4XbWb9rQfcIl+cwZCufVqdfKnA/0j3mDnUGOhwcj3jSRXC3XyN6OL4HF6K9TmPql PqdB7YUWH3YEuR2jfY6WaxkJnGqYXsg02z4wyo7Q+7kxeyU+fSjjfmkEt0iiLq8O8DVNO8+Il3mL av1psCrI3idQgEoZA3iXGPUr+EpniDs3YM9wnRhjk4WxkZ1Rq0WO1CuB1zO87CYPFMfqNFztSRbd up/cfEZGtuIWRfcXvBz2FQX6qRUAf45PbQFSZLEqxUaVALeSPUpFLsP6qc1VeIISpFKF7Lp8oc/G r3A9ckgIv5nEPDo4oN/ZPqsqLQgOQGEb39mD3zB1HKsLb8WBAsfP6wmDQvVJSUPv9oFr9XWi0e4w UZ4rO5H6IFH8Zifq2eTVgZSu/mVuv37yYmRjdL5yzUjkx+tJXC0MV3uzVbnvI9NME4B82YgAD3Lz e1mmH6EeSEO31bjWQQTfjh8ES4MNdZccMTkqPS0OOU8cksj2zhNLFFBE51ieFocgBM5VizIyWkK3 +CM3yrcQP2Ji049hZG2w/TzDiSi5IxY88ACbGNhcqiylnIKoXnk2OASTTrU2Qr7ZWnW2kg8QqSWl sVKZImPklpYt0tm7FAQOaGDLS+OH6q7YHE+JpEC0MJYaG7MVNSqhe7jDg71KPWd80A52PzZbgztd tWISwdrWYeV0atXiefT9dKyjmx/WNOGseP0SDWZSTT4lwUI0PpAHOY9GPotUgugDWgjJQVY4SPBz C7GWRkjgfuco5HBasuDrWUhBZNI4NsFPba5PBH4O51dfHfXho94HdR+TtYv+YJxKV4/AZIska1du 725il4aYHuKXXB6Txtnq7/KmCC1QBbSsIhRXBdq9NYej2la1hVPqiVuEuOCCSKoc36LF9YnWXh5N EFtNCy5gC9ax6Zuzdx69nbvBfjRrP8q3xSUajAN3PAXwPtuwq9IYzYQmTdrydl8C8A4acjczDBDR lVyErIp/If75S4PqCOY5OU5R/ZAcU57OxWQvGrJDs8M5d9c+lQlpFzHZuoUjV0jPr6O1HpYhlEeQ i0Ei6ykdxYEwNxBn0mH8b5tabCVHD5dbyhRgIrPdGLMQi+6tJYGm0IwQ6iEtvVIo29Vp0SJZMjWX kayH+LXk9nmC/hce57NpR44U+4/1QEjDIqBWhkmNsxjsqevlMpDM1OqmjuqGAKA+uGYwCpzSLkwn SgtgY+/GaFTrIVxwsbpML3gyeo/jCgnHY2dU697H7xqdP+1Fvf/IjbE+31A8/vrC8yf8RTWyQXaE +EWRYi4BbyLbPuqKxgJ3oE5H3IgFzJnXeYu06TulCy1W19Dmbkv5nXZbDjdMG2FgW0guCdT6h4LF QF2KVsUwsE2Dbua/p80QGyNuFVg4r4SWD5uE8W7Ymrj4ahAh6D13jHzWZSb4m6k0a01QMe8zPSg7 iWvj3xlkFKTSbzCBz8k9OAG5nlpNOjpFH4/vZm6tDrN7jdAfn1w4En1Ob4/Rg+TjqP97jCHW77L3 rbw5z3/98bf//Pv17d//+OM/fvY8R/KALNVKfFQWSDSQwQG3dz0lvzIM1HVB7fjtvAvUWwnttRVg 5KLV2pL+ZE6PJmuC3F35bqQzX071v/JyvpAtzR/MTxTT8Srfm8H/GQvCB2upx5nwtbgvO9Hf//hP /a/82x//+o+fDQH1vL83fv6uHBgENqZLol9iMDj96D01RP7UcmBxIpgrgB9Ftr3z5B6/F8z989VY /cZ+4tWcMTvSGzzzQ6aEEwNRn988b7vTC3ahY96WyISquugM5s/eCzLgHM9nrbsy6flvviWDzye1 nhHlS8LiETC/V5NIbr2Cv9GXlsaXxvQVrDKNY+qgthlhYE102MsxKldWz7M7lEXjzKJsJaxki1vV GtNcgCXBQNkxb03P4n0xiKwVf/cXwHHlIzfGmH4jtfTXV9A/kUR7zzfgEow4/fC9yAfXxDOZzL19 W38BsWnt2xbAhhudmEty+IvbCrAdvlSAeWhsy2uuw16QF5PE3NReBc5Dw5qHEkNRmwuv9YqXwCw6 Yhtb4P+mecngu6mXe53oMHGSvdg0ZxJ57R3mvDqYVPux7RqH/weuB3K0iET1XpF8vkbftpZbiED7 IBlYJEhpvRYxAyevkQ67nxBNArkaBmpHJU4eHxsh4Ax12WQQ9dDiMwJ9dn05Y6KTWEybv+Avxgp+ 6eUg+7Pxcp6JDhse5mAxRuczvUBnEFKJH742tqQz1iYMdtQi8kJKrGXejnjHhHLfTAx21mpnjDfm 4OQ1byOvx9cqFu3P6tEjJEjlEQqo+kXxFpNoDgciGctAPKZlLUVBTVrWXkc90Twnu+nZEtmo+g0a 9XULYZ/3bMkerIONMP0g7WQ6VVy2uAeigaDhwXteuHTCNUHQ7rUZDNS569eGaoI8dQkY8FGSRc0I 0bcO5rpD6n9ahTlGlOSrhzuTTsnHAWUJ2oI7iO7aWDYwKEtwa0WAhgZlujqGLGTpKETnhMAdOz1b 6nlcN4RyJ/pJWgNfikVbkKT9JBi3ydRYGCmUKRba3OHXrFOw70R7BlSk/AzBWRTIPHw5QYUzss4z BiEwQUmpWuxEj95w1pkzKsZdCyYX+PMQNf/xMLW5jzC4WATAKU4IUXJnVEu3h+uHJT+OIKxv88Hi vK2U7MFktxU3mV5Ei0BTaAjEwn5nCtWU0woEpSf0yTzCptC5uasJ5+XQ8n6ZTqijHoDn8d4Nf0R7 GuDaGUQskFeecQ4rpqVaFMiLJRRgbTAkScY4p7hP65duXQJJ8kLFWpltDgUITJIi6hVOB7PnnE2R htq7aFEOq5R0oJlucXPfnYgtpVgZv8PvNJzoSU+DC881cafC+dFZlC181bE7DXZ2vZvnab/Z3oRm ULlQHEhzBMIkTFu1KPkZWrjBIuUA2esE2QmOO/xRo8GO+siHgCWdkUGf4SETW9I7NIhLa5wuwCRM k84cHrKJTklE0Gd3nM5g3qZnmVoERM4npmlUZ25r97peGRq2jM1DKYltuMYiFkcGqbUXGoZKaKtW +7TS9EYCa/O+wFotjVqNxIAhwUIsADYjUQE5tWh2dIvgQTgE2uZUi4PDMwa0gDxi9DMIxeXnIH16 g4uh9fJHhjF6brky5ahSo0FYTWO0Q8oKxU1lBQKw63k1rFmspQPy1htPZzE8qOeEzVr68FXI03lG hwyUtsmN6unKQIjVp9Smh0b9NGu67bNqKCW+wHRKn86ctRFmfhy+MwZ395u8EkIIxs0I+8zovfj8 dUSvz96Lvo7rhPF5UlcZQ9oN7QhzLyZVPRCS/g5+2mvWwOxCo2P6qzs/s54kwQjg3CJ3MP6A0Qit xU3FY7ayxmxUSVKGQpa586TWD8CH8CJptQWf3mv7f9Anooe57oK86su4G9/0NORbs+mErAknwUGb X5MpXNukIVhCVL931mpaRnvkdNbKFFx7s4Zs8NloWOtAu3iEtcUeoPYmZsOa4EWjuiZTxF9ziBeb lP0+NCGiSDB119rY0McwbhKLZBWNBEiVXSPBmoDgHJolNEJaCzt5+a8aTuirpS3BmhiQYCDRpDft 63QRnGc8ngVKU7/Q3JLBYJBuV4AdiD6eJeXDyNKxZYuxrRRB7iZtWAePx0OkfDQ9CeZE7BWTTNEB DoFmHv+ghWy4a3MlNJ/xBhzJkAeCU+nw8Jtv1ST26Ss2Qa0L+8xshSpKNjifStd1IGuTUhfXi5E+ fWtMzXxzKEBGYRoKFvpJtsMleqKxsjsUJLBoMELBg35StNBkERp67EjQR8uCMLEPokwSvBdnkCh5 +FoBOj2CwUJzM9Oat9mPplfxaCLqwzRsCZXNEI0atpQSbihZ6Begi1/P0PjLBrUiekoO7VNqNFhI G3XVshkNNJUGoDA9Xs+DtFFRApNOVOloGUWDMQdZ0Y34tjiXGbVoZ/bR19Mh2BYmOkVUl0aDTWK1 3wvopIw2KvX1LEDnFxzSNwMgB2x62gOAkNRjFAA5ozsBTK3BoD34FJskxmpxMFpSQ8vvUiTONUQ8 tw6SgyO7/FsdHTUWIGdxjQUTnyIqRbGIWMykSf/HsC5oD/5BEo/4wjiTW9/Odb0QQVdD2yIcE9KH L1qSG6SwaFl9YXfX9sBtjMpWYjF4Hs38B7JD1cIgr8KA8NlCihZH2KX4BtoEDQYTbyPyPnpvnsgV bW2yk+9QaiHW5edWmR+qTZWSdA8wA8W2B9Bh43ibLemtzQC2pxtYdYieMYyC9qsGY3VPHpkcaKwO C939zezptG4rYLlyxOoHD2XK86NttXeeWPKNDOr0UU26xOdlQDcKr9Q7fD9K+L+JfB3LBxSpHuuV 9m5Gs04EkUCzzoR2ifhSDBKIiZOXnd9Zv1BzPWqCumoCAk4VX5kO8NYsGnIE0K6mnbzSDinZjLqD 9BSQnNQI0wt5p357NrG2wzfBVtztQarJJMHnYJKyr0kUCq/UsR9CuSw+WxTKK4f3AMrxOWXtrov+ DV6C91lIKJCtpmFVMs46Y52CjkSyWPRIL8VdoHdrQ05qZB18GvEle2JUuZOYc8p9gB2xEQYW5M4I lN9ysqgfUe9YoD9dHcxwysr5ZnJVtByhoFVeDQNxhgFSSRvVXyq9BIiAhoWA4iW+scPniT/IF0qB /9K2qCc+6QsmoGpSYnE02l8JqUmNAucZJjJ+qwx9bXPn0TjdYP0pa1hFDIU1gxJtrK0AdRjKrBAx FDe7A4Lofhur2AZjgeadDEJbkOjWdIfRdX1tFhH3fHokCV41UGvHXZkqTm3ZYCgoh/NIhEnzTp55 h22IzN9gTxT8lZClxohsz6CX5VGbrVvqISEytcRpTFWoAL1FDaYm/UZyGNnrgRqr19hJgtu4LBri +b2Z259eQeUjt897o4evw6L+h7p33REsN46EX6X+GrAbJJPXxzlXYAHbWizWC/jtv0zyyGrvRNSn 6q3RyTbkGUHTUhf7kJG3yIj/B68gDaICwo4G0TXlJebVXT8jYU++GURv2QdyPmrVxohab7LRQe3d o8FjObaGxOVMdXElBWRfLGjlTVK2N1uGh3GIcVKwxrxUs93EW/19Hw08acMp9TOG/73Yuv2OG1y7 7rbPR2fwH92jufgmkhCVWpOcbkkO1TDzqbvQ6nkAruEwepEhNVl56ZKIoMy7fJzzQi8nz50KyXWw 5nTuLMV5c7Zzyn4DfoQB25qJsqWKj9EJXerlmaiGSpiBrhVytgr7SQb656c7n3SnA0S1MbvTbKxT XbImtz03QKHWkCOLTcCsUb2GnCvWC40OxhxYs8JthOgwX9OQ04FfkIacFmbIYUuwTmW0Nwnoro0p xZRK6F+3dXvZWSOCTT4NoYtPQFbFcspEY+5dFtteIxKdNbOgtbrDHk/VX+PvtmlCdqCv08NS+mCs vFSrR9qXpgQbmB5YSrDm74yu/xF7dDir6nfaoQr9mPN3RpLS5+Nwxrttx4nXLGWRPZgJr9MoqoHn RItiGngmnyCxnd4sHv1EW73RcRSo1wgeFwem19SISs6rZPCjnFgd3EYhRmhlgadnZhHwcuA50FxU A8+zM8q6Htxw612m1I5ckAypH4oEa+4qUDsEg6K5M7LckrwsHNja2yfF2/ddty87CW4HrEQVqdfU mlsLO0XqjBruhtST8pEYWapHj2ISitSo4hktzyE8Uc6TKMyg6lWyVD/GdcAcZ5KLGKyF0hx2CjQB zWgHyZZFFqyRnK3nyJz3Xn05+gOD+iAWmySmxG25PQrP3mULSHdhdLN2SyPhjC1K0y9HXs67CfUO bYMUptcInvmMO4XpcsWMnJ9jkkXWJ+epsZhTr7vWR7/qDRm6wyY7jANaptauu4+zSUAOqRZDJ32F buzMn8EdfeWU7cb5Z3ymorTbLh4X+BQLEjY/kDUVZS6pXrFgbBF4VWmQXDYbRKrxMz3dF5W19w2J Yhiwrc1k0gX9MMaew07OCC0efxzuJP0dDdiIDadxjh0eRpFgoI+jSPCMEdlqZXOpzbb31BHPcMRp jpgH60ulUok627udgmNut4Jlih+9d9om8EjLq0WgD2efGN0SswvIJXgkt9/xSGAp2RQlw8qnieBC 6Y2tuby5e7BtW8OU1vyMeX+vbUTzPQZ0cAlT30PDKwS2VJoM1mJ7k++xSYxol6KWvga9xA5Jz9sc rvIecd9Iq+CZVTFCuKTgkL7S73DjpMAYH1TgtNTkkMfW6o14bKOV1WIjApqjjESIX69y9UsYyJxC ge2ZvP1e5iGSpKPiQANPWoGHbfWHSoZVr0LBZopXsLbua5KIj1M0B6pkh+/7zEN+pe/RNjC1TmZV o0jACtGUPY5F93s70eBtlPIjt0j5uXwH4b0GaDn6jkx3YsqL2k5GB9Mh0WNPatsOvF2ZnznV7+Ye clyAoGspwRqKdsaQCJmplby6vxd2RJ/WhKzOBDQyza8mHqlsm6SEPLgUpucYUfBxSoyJWFa9CtOt XieY8mqOM8ntZK0/Fz0vIXy8GUNv2TOwdjEv1DrXkAbBNqmtkHT6zWJU9qsCX0F9U8H8HGhTyqg6 /pBAi4OfvXl/SglsyMuaOFG/oENYayn+N+WVv+4kjh8txK8uV37opXWwkyjbXvAscbamymC81jAG 4bW+2ivYBuK1WmbwjEZ/r+1kzQwG9EPJafEKKCt8xO7wPFVfA9I27bJktWmi41QlfLuQA4Il1kuT ngRTUdxgGjlvPp+77FCrQAvsPAtsorGvcbZ6ROxS0gl6bVH/NqeJrE74ZIrwfcf5MjtPUkOeiZqG zkk8cXcpoVYmDPxyGoqOo2noXBAh8pm5lNBIq+3NNHScccc83bF4upFJsPh0euqaVGfY1Z0cFtI3 dJq4bVvf0cBKs4KHJPF7rY4f6SrQ5j6nRWLpbNTrU8tMkQ1VpIZsc3tccBTVzxcr8UJ5GdlQv0CR bW5UEInGXEMMBKdf3R4/xoHsApZrleU4+DwafBsrSV8tsKPxQWGOU1eOQ3U+EsvZXo48BeU45v60 Ig8rEXw2D3PZMlqElbIEmRhWu2SA1TPDkUgZs5szyEyk1FQddnPyKRnE0TI1J6Np0pO+rujr8nec klIEbXctRpeXA6utndoobyVcWK2gLBoLmfJ4JYCd+RBoYJfTIugxIcDUmBPKy+oL98/eFH9LqeNk T7LG7kf1OIKTfm3QsaouogQRBO3J7EbcZWwaQwNc75cpoKk/NEuofdqG5P0WNCCVsiRlGBJ80vf4 87vVXL6o3ciZosvyPiDFTiyZahW8yjaUgIQxtNgZk87GVqucXrWtxIFl2criGDG3AKe19Zn3Czol 5rToeUx9Uqp4VG7WqDOAlm4yj2uNOlR81qWGez8z7Lf38SOG3knl5rOd2+q+g/RGI+hUAyUiHyVI IazWVyNo0t8Ee4/ntcNH1KXi0OTT4Rj+rmGgCDp6WzujxEAopRpZ6fbmecYZNrQKrxlOWhkOCTtO +9PF1nTg95l6TJFE0dkAdWgrWEM6kAjL3BCxHIcqFZiMq7uvozlORUmB5jiT2MqA2qm81JGuDVmP a07w8PMwWGtMKh719TUnyAlWokbUZdpflhM49Kra9n5j5/GyyKDMiE9K96iQk/Y9YjtbWZwCkoBG C7UOz6ORJyO5LI08SzovMhaYz8gj+/XzMPFvBD1bG+2DZtQ9EmHDd7+ObOP+IxTEas32L6t86Id9 LZ8+W4Ayc703ezZJvrw5Xl+0Fk13QK4Upf1oese+SluxweJrI5AgiIOjidpD+WL1dEhMkO1VeA7b gdSnTaJ1wjPR94g1B7aD9Go76j5jgol0X8u8RMGslNhZv+PNTPrMis4wV5OHMcmsUvnywbu52vXz VOenXM0Y1IwvaUMQh7ui7VCYxnXB2qRgezt2XH/H2faGLDYs9VxsY+bG6TX1TLkgi0RN1R4SG+N9 eU3Vzg0kN9aisVSNFjrdpSab9P2C8n910YqIKUVOldBwXiVMpqM0VLblYWMdjTpkb0dkUJ2sV10p 8i5gN9nizsPJww1QY014dE3WuPPz7vhPcccIoIwaoefxqPVTjh7QgqUmbWsBlngh6T0sxNHl7cCD /MYt8CxCKzPacBp4yi4b2rCUslR0mRqoS7WfO19IC9TkJpdKAcsKajBBMHcfR7OCHSVtmhU8BEOW tfncQTLdNcTJq7ZsrVkBS6l78OgedJetkvpt3TZiWxc1iiaHg6pbj4BeTx7WX0s5sXahaBHhsMFm BFDszSsPi425b43sUfxL8wJB7c+QjMXGFg+yZq8uZwf1QnGnhPpQJknB4zSOtlrhemVri1NAvA+G BGIc8iqnIG93ATNey9rWJIRIysSSqC7wm9CWUoHaplHiwzIkHFCnllWHBh+QhRq0LaoUl16IbHn8 3Sw0ZaQDKGVpz1LDVJ6FtvcmCNd5IR0JvYaG03TxIDCFxlfXxuN5AC3Q0mz+HiUTExRzkWZuqW/2 CroiGKJHaM621qwzMxjVh0M+z6s6ZnvtWESiPhxQ1nP3Gkb3AGYIGkaXQg6xRNLDkIz6ZUukSjJq a36YJRJR/HFqiaRhtKJtXg2jD5Xt98qozzwOYKRuYXSxiwZdHXd5Ho08vcEKYbKLcPkmtj/m8DAK bYL19evDLmKCMlI80sFb3Qpo5ii0TdUFMrw2ojgJPO8OEVI5kMCpQsHiFiW28uZzRazGfKAVPiPm Rc3MiNJcrCkEUl6/WfCUlJCw9ujlWbBk8rM+1X4UqBuQmlOgzotaMNimtc/xtQJ1QuNRvYcG1GQB IRatRv0dZtu3HfVBTf5mAjXz3XG6V5VSPVCNoNC2ZvGJ7VX5vGzt7vUEovRxblhGM6sky8mWiruj GR3p3gH1w7BgjXsHYx37XBMr+3ahIY/UpZRFaa0eV6v6dZwVZqBzds2K0ehy5+2MPYCbJuHZeWN7 4/TDyPdlbF+WMNu3gFSyFKTX3Jp4CGkBrR/H37fR/CahjqGC9BqNJpYR+HTnzW1PKJ+ueRg9LzA+ eA7YGy3l9yjUmq1FEHAModfgjYqvDPHYnVZQaxfK1mQO3jAMlFps2dzdYdJ5FcRvb232pKqQVDr3 Mtgg8c1CtGx3gjbQdYkWUVKBx/C57QM51ChKLyexwAYhTqtqRemGdnmjpDV3o85oPuXyakgRmdRM fpGV1TjBKSmEQRgfb76dM/cDjXkVqJ8xImOwjOZzu1I6ZE7KnLwxqcnaidfwu/SidJ1QEdhMXWIq lpaB8yTNGHrBHcP06sdpFe31S4wzm8an+XCK07XtUHqljmnSTUm63KT7vXm1lfmguabJmulH5BZg BC1R0SHhmJNfXavaR0GKUhpD10iUGaM5VWXUGHqiOYhtVq4YirNp86rqDmmTZQ+Irq/5y1LIYkQ2 Wuoo5L3X7whFwMStj65Rp9EaNA6PhNaqcRIshmh28wwN2MCtxuiwbCvHiEirWYuctS9KsrUojWpH vAlshz4bkHxatvZMq9lQhzuGvApsIgLtK8Wm1YTBNisdhzypO24VUAksW6srW6MKrZmZIb0bdXpC xCJ9N898lwnJeJ2+x4DtadpiE1BHJJ9UDy3dKtJj09v0TETZagif6rzcY0sFgoFNRBkPR0s3j4cp x7RvQpFnLb2RUjS2nFgkfXUzJF0NSM4auPUFbuTxFP2FDktr0QoZtNlKk0VqZQPenDJJQV+diI7j vsF6smH1M7BmuxQKiw6fTz5lA7MQ/Tx1fR4WSnv2qKbdY4KhZyh2ra1EomGWa20O98Q0lEIOtYbS h+/BrptPnQ8Npch6y0LpQyhgdY/XULofJ+yC2gyeMqWaaem5O4yGngSXLE27fYYectlaGMXhUmI9 c75AnmPyjHooJpUlaXhc6M3bvaFJryY6a0+MJW61dY/qmRpJB1Iys6OsSMqyap+8SYXqHbEkFKof 1gdj5NTuUyK87SARNah+mAW/1wKCQnWDXm/ZmAWMyJbaKA4pOT3GDVGoRx9Lz4wQ9vWupeBwV+xO J9Kbs9CTVuhhj0d/gcOWzpAtA25enH13xtH9ZPz2nuDkOK4LibBEkYdWQDI2pzBQ4xWBUkFpU6jR /A9IeR0baxe8+XBaTQGxPsr07LaoQz5PC9Xj5zkkVFBfW9SZNIkWWK/ap6i2Rp14oAIhG02CkfNS c+lz35JZG/3tMH+1hi8/GuW0fgJqfz5D9++whtfI0xBZd8xtJIs87AFJ8HjhWq0Cycc2kZfGalKF vlEdVgma6BTE1dVEZwn/kGAqqVRWk76J12nf0XWzKm75jDIaWNYDE7x+dfltu5Hwj6UHD2OCMcF8 LvAMGRfgH8dqEm2/II3xXuKmmUHFO7394ebQ+s2lzKnWo0gCzDKDvjIDEoGcSmz3azsE1qNzJM9G vt0yOneHqSakDdK23CYRbAhbR4q1szHPy/UosqewrOChGDBYa5IdtkLz0QXpha+JfAqsU51bZGuj r7p1bxfaUbaosxgTZIXcK7aVo1fQO7SsYPmKEYZBSrl6HGIrUu9YKqcvBggTpXZKn1Ksrjus4iZj gnluaOhx2Ju604FM7AzbFsOgwI8Tu7RMDK7ju14IJxI008RgyhtqYsCWlCcF0933yVu+CbgtioEw ho7Px3Pna4MVdh9LB4zRwerIrFf9Mhj87CXyExjMmS9zrfkQoj75drvgAln16HE6XJOuTh5xkOrt XX/OsyP+vsbRtmjIZGaVUk3EsftlMthRkX3AMB3aCdXw+6SoUC049MTvW375FT2J8wbdaoPqtKCa NUR9Ml3HWeBCrEL1mmELCT1O89B+jX1DeU6ZM1ImwvBRPBIMWh03aE0ptE2ZYNLMMZFgYgAZw6uk 96PDRqhJnU4oYGSjUbPDrzPu4wLQZlA9ebuDtXPK+AcsKf4KtB03YB4atOUFbWxjxCezLZ0H9Hfo mrfZfRt4sDjFWipZGvk+mYxfgmrSqM5rjs1sIDXX8Rh6+iUndEwrc7BIHe+TR+VjheoNxFGF6ilF S7ZIS0yVNENfzUJvOQuSbtWnM5uHzHxDk4KUHHZzNAsNyNt2mNbpDD0ky+mle1R01/qtIigoRtST VhnFIBa2hP1yv6BktA4nc2aVLGv44tTqG7ULvq5ndCLlAgujD/+DsUL1nzn8OKntJ9i1kjjSHF3R scjwuE8+zoxEnCdvagVRNrbyKT+p9U6NMIjmH5nigLELHAbRO1835FD2sXZfmDyTBJfrCPWsYYBi tNgMYVBJ6tpLdNg1TPtOHJVbXvUOeTq5Fo8ieq2cAvSMNLeZPp3EtCbrfyfglODVGcJtvBxcXT8z EVId9FpZyvYqsKVwgpTNwuhDlvi9yB9ail7YDSE/A1+qx+BSaEYDD8Q2s1TWwEP9rgvrUr/cKoCB Ry9hWPUOfDxuWwV3vgvcgxthLVcQ2ZwoIUSHWY6cewRZjp0mhVbwy0kpZ5YVvGovtteBTW5bXXEU p9S1GZMUn+fVZkHaC1qDG6Z4OiMPzAtiUpgQ0vx4s099ltQwTa+taTwrR532QbXkIVSj/Ezjf6+C tF99D7Dk6RZ5PnG8drgG1+pArY+hkWcmoczcobOk7dW+Yc0SAWuqp/pDIyUjH4s5Rfmj6CmuIUF3 w7VnXkUytlqbRxxQXIuoflNcW6PrSJK2VrtHpYxx9RPpzCiuPaNrutfnskJQXCsdZdQ1GK4xocOP zMSC323l3BsUARphUaaYv1gVo+y4o1On/UCiRpa0TX7rYI+nmFS6v+9zpO3EdtdtDXsj41NHl9oS 9ZRxgqSghtlqK3Sa2JvDVlu/siQIBcmggNk7fLiUQW/btoE+m23FLVkJ2tWV5pINGtIFxPQktilN TRVp6bDqG6udL69YXeeOagPTllk5DrO67oPR9t9MQDVVQczjMTPQLGSVXOG7EVnNdx1hd0no62hx sBgsxPstBwVEMnx71UGgxAOtjmrQWaPRyHjuPv2H+9XuG1WidQ7fyDhEYdqjg0DSRAXpFsTUw8pw SM8w9dgdxtA7CIICiZYR5BiI2JStv3lsUd8lBGjwMMIzGyVdHC12PE4TWw8n2LdUpF7TN+LdHVog hJxXe4atBqhmVGJcq8rM40GyeKQVnGbYgMuDNX2LjObuc4OnXxWWB2Y6qkhN/W07MYp/OaHO8ad1 sb+KmKT4o0U6eHtzwf/vEDGR80xA2yxGI+7HUolXfLTNbNIueHPGM8w3EAfTxQ2PODlIsYjLNZ6y ISk9jT7xGSiyOiG06rDtfmhqDWxUk5E7Fr4xjeqS2Lb/q/h2bid0R6hzJsIGPL2QHauXdTKujKYI wwyGIqsRPqmv/3yZJr7mfyLPtChm/WQt6i/rsaTv64J+uVmw7RviTmqSs6ScWetDYvLIotaMADJ1 FaQXoS0SzQItr9km7Jsg3WO4EcVIQXopTRGXFK+sD01CI1jzN5B+BlYsb3OqpNdzbKir2+aAh+mG N5eWL9e17dB8dDwrCLRxmJhM/as59TU62hDRK/g0qUnB43SYKHUne9d5kXKIjcBnsvuvSmSUsKNl S8WCZ171uznYlAsmbG1OeKg2U/a4OTpKOtHmqAbSxWgj1ZvNs7rPQLoh00ENpGt4TcSmvA6v5Qhx A5etWOtQsxzaM6jRYdf9ljOgr9PTMnkY1IEjunR8aUOgda85wq/QQ5X0qkfVAq2tB+p9KFQ/U57f yxlyhPrf2m1/g2qb8lAyaE3VY57T+glq69HT3FMmQmAlN0lEUuJNNRZNQit077U1ZTHrIVzwBBmE efxuUhBuAdKt+rPO24YzUCmZ2tq9GXSGhIEEGzUpWIwp4ptmJPfhEKbrdWdIlRhTUFOTAlIhOB3A ydYEKf/0tHbiBzXwHZExwF6uEApeGOvPyIotjCWXPgLSZSDFxmo2fSMwYo4C8nDY+9AfeEcpqLnA aRCljp3JI7n11AwUZGwaJY19XH/BSOD7guhXm7qyHzeIOUms1BmUs5/0xA4jaKsBiu2b0MrKpVnL 0KeYu4JawGYiY82pEkk/ewseGVMKAxUSW5vNqRjnOFXxaJHUemhgiDh6nmRDohCccyuNkA3fJOel /UBlqOZrY/G/mIe3hCYOI87ZSgFug5avLcIUaROYzwgTx3h1bVTLY0QxsjpnzRJZ01BcQoHWbgF1 qKutKFvtxtK13jxqlxxpR/v9htRrWEXKnTrsQvo7jyJ1gOps3YZVbAifqsKbv8NsmnzCtGBEhQIN LyxjywGzPYxn9VbGth1BoKNylKdfyEYhPrl5R7sF+avnsbJpJkftke8xJNzgolkQXbwvYgkr5lDs cHJQr+vCQXTKN+txKaWgeGx/jpD3iPLPbmM3SmqtJs/v7jDlOmH3c5h3t8142cxacmfFzpsdnHbV BmwQup6ma3bDNPab5tv+Xs5hxmI4H1gD6/R7kaW02EGuo6OXqUVNdvhys90ef2pZ234cqJmrMfTh 69MZoksZQMW1nwVbf8K1OaNiA8QWPFo91VAzIE1KLGlu7hAx3c9syN+8a+O6I7Z0GItmSAwGUw+d 5Wvv5gTnhTeRpo675gTEoLOUyt7Om4X1WQoahBhSr3l1wmE0Nk2CHKYFbasJ65bodYtNSApqrJfq 0G+0nMcBCuuew8wKWHXQRRz2c69roKwg1jC9bSvz7tanxRZ6X81Atwuq6UqLsyXFFHI+mYR8n2ze l2s3W9mBtcEcUdEdseJRD+MsuYMEx0BtTUNpN9d26P2dZ0jcMMVwLIohaeGkMg2t3AUdDaKCFRrn 9N32xwg7InWG0u/yiu4D+h+Uuc5L1l+zhqNCmjhvxpxtPw+orx/lYYOT5vQnbqPvlgeyNVgezLEb N3zz6P54aHYDqeAlPDNRAtVaIXlU0h0xJUDJM2hbRCliwaUluTCofpX4FSTfKI6OOTmgFlwu3QWP up+gAWqX7RnrsGZ7qx6p+ntPCS7ySpgEiUGKHQ2k1WOxc7eKfIctjtYVR5nIfskehyH9bh3RccKY DWoqY+ay277lrUCHNAmLUkDMNvTQwthF73YKciJg8PR0Wdewa4Xn7/tkhWpAYNHyTWb5VpmCkUci W72OE5qHjGmAoAUCGVX1Yaaq7i7bUHCrKGcb1tJlvC+7ax5hrQQ4R+xpNj5iIBrUpVbTbnTX09Uc FI3eDAmeniEj4/icH8S7o+lObcuwuzD12Wq9U3/H0Wq0QlXtuqpR4sYXciXegq+qavcu+wWRwBpT hFf0MXW1/X0ayYKMEhWmZTEKCAk0hpDICtLLjTY5wbDKkGA12oQgtdNGmz6dCBU02xSkJ5QC0wBk bak3jVBKGHDJRX/HH70n7ExhXbZOPJ5enh4UgewiCYtdlMldyz2wFOfdFZd0IbPuuvaSWemmWSbT /Hq3FM0blF/pk46jHwf3pRQkKiNQv5mAbvvZ0Nspaw6fA5GT8SqJMWwUD0tra4Im6htSksPSTcNO AyLU9rfVBGWUVqdN0NbOAOYhGnYWvQgDdc69kc2QV+lF9ZYDUD4syVkUCcY0LLl4THLSHivqGrZe bFpVhey+phhrdghtl14bJG+qgXRRcjKjsAht5Lx5nrwVmFSL/SWnzhhTnzRy3pOZM1NuYDicNGkz nKY+KC79nY5UkUyW/W3ND5gCoNMguu1HRY0cc0NaSQFb5W3RY6cgaeqMSB8xWL+dDUOcmu5s+ToR DNSqfzGiChsf8FWK9/q56UonWnPRmFNXzMHptJRBy4M3x6KasSW0X6l/W8MDMub9yBpEHSKb5tIX Hh4saVPin+yT+1VSOoAUqGHwjxhHYi+nD5fqcq0dG5iFaDa9+p/ENqT2SLQj3rW2NnV9WFj3NeOt eHgQa6oeJzuafXZkg6LZ5yJ8EKUfDVQ2MXV3nhHiz8Odn2LonFRxGxSPblX5Os4TdgyzdQwr83Hg Wzvv7rnsARVuRcuYla4xyQUpHm3rzqI4jdPpNXcTEnVyTMHjbRu20AKW+nNcrvC0oysu21JFXwFo fIxh1smRKlDreZLHDUuNowUgtQaeNQzBcSe3wUY7r8bRvccTco4l9cX9YuOQkT0qZGncGcAzROPO nIuy3QNrsvk7jJY7HRDctdwxpLZyhxHZYs0Oy4OzVCj/p3975qLk+8SWPSJ1a/sNGjl6xtWgxl9H az7WxnlVONOGN2B8YHIYkj8RBCalm8XW99qFUQ6Yfc6xDqXnajLt8JaVG1o4aHqTV77G6Lk+eUWK AtAHybKXhQLs++TAdnnfDTnh593Xv122OHvT3MJBHF62EtOFzGlML1PxgbCkkuTg0XLrlg1SDDWA 2sxN7yGZ6Sh2M9H2V8/T0oV2K0dbzPZC7O21dEjZ4XmuuN3YBro+k4PfS5rxSAX6pSq0PZMdggZ2 Uoe1zrgCpEpJX7u8TEzmk37ue0nBdQ30cWKVJS7Hwk6sjckwvRx2OtICNndRDTvULWRUh4fRTHoD 3OnZzTUJepx8FhNEJpn0m+TctJ8JEXHiFNDV9L+wgWgQjyy2ceaIwqhCwNORoufJHolF+e4ZqWHU vJCAPR4bwDtsgF4pdnQczXLyynIwTOdcMmsTvKk6e5aCpogWRZ+pKAU3l/uVitQ/7/X/hNQ2C2Fc 8NSbRwM+ReoM9vcUqecYkcwO8uiF8FnfXaPIhSH1kpAouODJsRe2SfHy0+lgZ8eezpqFsNlBGtWj h+2VWkAFT59dqcQ0JD5JQPv3XbevJqBHzwca7IRoHgE9lS9TcV5k5GnplrFDVXuY4LTL5pL01e/7 RHsH5mObqRhwMuaRv8O0Ni6QEYw+5oxqEFBrRYHP34xKq83ewaeptlc5IssGtDyoDrM1OWJDLo/T JHXEzIRXoksu6+gxFRxA1/pRxQEn6cPy2DEc50A+43aexcMh62FmdM1GVG8mBO2o6DwG08/wgHny puQR2c6yVYBsluCsESJm6edQS2Vo8Ob30bDzM+/rp7BjkypGBE+9ZIfQpmGnA56Uhp05DyVzKinG ycNh592ux31CIcO+lDBIFPUpQt8UuX62bkhpujYk+dHMtOmLB5E/nwKe/+mf9bfYzn/5y7//63+y wejZ8d5Be6YHv5fgwpHyhrFN1mA0kxtXzFvd33kU237eqPobtiUbjDJqe2riUda05e0CXBzFtmWS StKCVCtLqd8MO6nvO05z0lJhKoQ+bRYODplS7b5uIIfRhyXVChSMIZFqc0iePsMdAK8oDok/8nTo /CJe5/dWdu68nYD9WUeYX0Ya06EXlw5ibWsdOVSZ9aHFnEjMT7w22M4ydlS/acxZE2uyd/CRe/Xo INbv6wwon042FWVMcEX34vGy5YqY+qN3izmZaGFE08pwWOrIkdKJGh82pRqR0sBjdDmxzjty3NJ8 YE2siaB+mXv+fzIz4hd2QtLkpP5xIhqXaToLOTkUjwqgco8Grpq1o0zunPokj+CRk3eb1DnwPtHi LQa9b182Q3txqbKN3DHjq4cVP0mn3em+gcbPghJpjZ9rVp2Zpv7IyWHI0fjZUK89pjmrpqZBiYjk vUxm3RJgfOUy/QFyZboEmnoSg6p3vdA09USLVH2s0TtZN6ijk057fDPktENTT4wEaSEBW6sMLtf2 erorFv2TZ/ROuKw5ZI+sFUWCeMNMeg5EqfXJ8PhxRMINLpv1OxYjj+3wlpJY2faqmNQpdwUwXezt jNjoSDR7xOnWjwGIEWOYImPOpKRuQ38B/jbpVZje9oJ9BHtewMY6n15J7e0AK6IGbM/I7feyO+j3 eTSY4syRGztM0VP7O4w+HQHLYfoy0nw6OMNpsdOn866YfoVWyVLyMwHBOY5Wr92j5kqWo19wf2Jq sA2qZso8xj/kPcZXv2ou6N3IHOewo8Tqkca699igM4CspcrBVsWdep5sfdygNpA027g1VCb96XN0 2K5yoM33MhcRLYayTq7PHVFpYSBKe5wyC5Z/kusmoTFNj1dznL5fYId3mJ+ohR2cTTcDcgzT6U0Z tiPlG8C0/bTPEATn07lFl4o4muFUZA5gRtaK1HS7pRDd3Jf5kqmjUqemWeqQjMDGIGQ17OV8be8A CKySmQ8HlwZ6VtPOgw8nvLu/O8D6hML0eLq5BNaa8fH8fR19OBHdtSjW/aS7E7Ukh5yIs+wV+Aob qq3WNN5CFNsKYzH01flhvciujizOSmUGnHy5+t0YujVkSGPMCIMCnOFUfVNkfyK+6apxxTsiQUaF gqedywrr5FLzr9/HjqbVUaz9yRZeRVx6cisURKxLkFdvuuCETYOseBSS0uotAQ02rd7W8tGgEj/F pzZr3xNY2xsjrgYoHrvZIixbqnxzsqNPp+JGgTXYiIy+xp0UHVaiW9oFqUtq1FkLLo1IyLSQ2eTg zY3Xs2w7qXVWN5dsvH7UKh71zeUoG1quLqbSPBIxeLSw41Jcsm9IrV2BYLVziVuQpqbd4V1TIAho 1S1m6xgyNrtxIxxetCtepCU1npYU26Sq4rFJ0I6jgzGVfhwLoSkSWlFRAPdIXMl3u5BGc7WMwNR9 qE1yziRje9cZ4DiRHriUsiYhzKauSfI4RJS7xfTHnECDaJqMPLr67nJTp1x7BpfNkoJFJ2Csds2m 2XneLUVNfwmFndXOJZrGpQxCNH51uaXf27bBsGPtT0Zo//iwJry7q6Zhpw5UV6fwtNjYkpvPhQM5 4s9q4D/la3Xma7Sd2z2OEWW/QgNXrZrj3ojU7ySaBoO709R7Lz+Vof+1JFp+tEQseD9bEv0+JsH/ w5KoBtKGzbbKmu0Upgnem0fX9Hi3A1QItU9r4Rku8aA3RMZpfbfNthWQFyhWz4479QmxBQt3h2m9 R2RYOeIa7mCkjnUMZoj4ph74kWRgant55gdUpzl6nIeUdmwgaat9uqPqyyGXrUr22DO8ejtBzmZD 3tWYYvoE0rJHkcl+j3vArG023BlKxxAd3jVFAmSOqkgwZzu0K9VLcYhrmoNGJFymyD2FFiI7j+ZB 0WEMPY1chJHtGYcw0facnCJbAUu8imxpIRt5PBpfPX4eRYItwpxgzg/YutuHee+4O0zNewRMKWm2 FRK0giZ5dU+ZmYe9DGwH2EUcI81JVYRzUQWB3AM+jbxqhabVM0hxarU2jubL+ONEhYhKTBG/cbXy V3D63KFTSAqrRY0/j9VwLoWNz7IfQGzBcPqZVbG2oWSPO+Px3jrgSChO54XT1CvEqWTmyB1lbGWO d1gn52M0j5O3vAncQUpz8kbaH4rRleSfr7ZAFQkqiDqKBHF1DVk7x+nOjtaiN5YpqWscQmQmP1oT jymOaGqGliuLeSLqlePLFB65Uklih02cMhvurEFdXW5SSO0b2KSIy68yDWENw08a7q/OdvI44YZY mrOdyATOJXcCbG/OReN9ZkBf0RBaZwgllaiZp3psf6YeNigG3CZ7JTHTvehyZbzcsSMVmRDyY/XK aJN8y+XdqHNmlK9VW3y18gD22qNNRAiBOr7L1j8D2D2wpGBRdAkWeM0/z3Im1AE1QdmVFJAkJ+qv dThMLMXwAG2LtrktypiTfFs0f99xvrwtevc7wJzABjuFr1J4VJVrvVXk+TzSHOxEPHOzXcRKxrxv 8nNTjwUKsQ0TYkt0KdmEV/x9G00ikZSpBZ20gg4jHMfkscN2xWMDXHBD6SUfQW6bV10cLd0yyKcN pdcYsf5echjSQ0PLlTVNGcPORjuSWMvw3R5OH4jAEotN3ZhP3Yc5Ovk7TLOhG4TpNXXDA96Ue2Of 5tU1inD/rMn4108zFKX1oZNWrsQhrKp+s26rIR7Io05ROi+UxiigGB08tjwUpQsqdRSln5Eok8rz iWqKA3LDdM1mbmQ97CMVlzw2xYGCPOr0aUwcwA2cluLoZMn6VXWCewxS5qxpdWVXzedUZ4x2/zco SHnK+/xgwYYyDMv3Ddv+z1/+9T/+7fr4X3/5y//+v47xd3AMS5ITdKcN3OoCN5aypVZdgtt+I+cT BbdnjkhaoE5FWvvdLhBJFaptUMUW3hSqmTnAq4fZxvHf9nbW80k/WHfgw2iEf/Ix/u0v/6H/K//z L//j33/h+bRebiBUoHC9Rm+Y8GHWAcOhmIzEkND8oAUjFaQmhGeYSpBAPtSbmmxHSheSzpS5YWnh h4HBVHp2937krhWwi0SK2SFlNkiU4FLHrOr/NFLR1dDTV+hhm0g+W+4aejL0dErpGVxTGQmXefXe wwGtXPKi5Aw26nXqUdVKOgvsHa71Ha5FzxaUX309pVRY9VQbXDPXoI/cg0N2UetygUaohtE16MUX rfbaiO5Cenm407HqbHsYH+SqfbJi+S5Qx4hrhPLMRsluvwRq4/AqUMuRkJFDkGJm1sJmiZ+4I74n bbqFDRntWNR5JqOMw6KHcRhFUzs6KHg0x8kzx2EeG9kEXt2dpt9SoSdFnaNEuiNWk8Me9dW7IFwz vs1a28HniaYW7BDXSsoJ6S4orj3jt99LHfysG0pALe48pAICBSLJIxRcox1odycasSAn5sJJYTqW 71OU+SpMX5qwkeJgjUYTK94qI+S8W4peLe2wFJ02VYy+orhGxEBfhulUoOpsnaNEusCXPcL00a4L jBJjtb8odDGBD5emW+W+C9JmVIx+hm+sCNVU2iGmtV42IGeolc6c8xLW5GfznVe5+r13rDBXlq4p iaDWaGQElleli+q4sRFSW4SPxlDaZwSVc6vAUlSsn5ukdbZcGYfL2Y4GFgRsGkPX4Jpxjp022MwH CSwhaQztM4ay/KZpaefvNP02DiiKoXMMT1dfi0et85oHMkKSZsQvW30l/bVuppb+jnMcGWafQdrq eFANM9rxeI+eW0OoaEqlKcEzsiZiJaXWRh7Om1MqTQnQXsgYeVI+ElnfS6MS4+dX1/eOeFawZW0h dFE+Gl3kddmP0hTnQufRFOfRKiG3LUaqzvhuEM0baOJYEF0ECXLf3Baid9kBWV+krpkoG4TU3hzS v/qd40D9wjbpHtwwZLic6uQbECcV2CY5IuH8RsRi758ddH6pNkCGIQZsi0xA1LTdAlvKGdmIlSRr XE2+j1efqtSOEwxEFQimTCtjGhoVz+HbUSA4NggEc7xLFYE7UdV/F6PTmRApT2NnX3vJzP4kZpax vas5KwO5WY88x9WJxZw2PEowKbBlnLH1Na5udMtlEBbby1suWwJkgjxx2rzsSCmaJbAlpDcv26Up DjIMKcsfUXGa+Qn6dKcZe84Yp9eAlzXb7QM5PE24I9wVbTbgZYw8hQKPuvpVs0+0j2hu1ROnyQAx xT4KuWpvVtZaV+8CfQ/MXrQzGs4nXY/vW6r6atdDk+kMSDgac+YebyI+O1rlkIHbqz47Rzx3nEz3 Napm8tOa5nlktitID8SVVJB+xrsk/XTKNB7h2uFuZbOBKCPh6NfxODcQ2Qqy5rbfcsEaq9y4Buir 6We7Ang8CgVrhshI7UbT9/d1ztovNENUKHhmbowGPprHqY4+nQKJuc3mIOyqGcvY4dPRiqVB9QiZ UYfYitYqRXDvM72ZD8h+FsgtrJO0QjrTRWpn0sbvwsC5Qz3TsuYGOLsxnTYWcd7MCBQGBiZN92du QBf3XA6rFQYCXNzr1smls10z5vZ3mJa3Dpxc9KqtTi7uS2uyIEIIUt/HxPuVZG3rsCxI+el8ksLA 6VU74hUxa6U/nWnGY/W5Za3foWPBhTY5X6YSAScHwbbn/bGKRji3C2UE3Xq5dEIVQ/QIBV0EbO0p FKzeJ+4QtBzNpMLdxutZ24W96sbT+2T0Qp9uvD2eFfmHVZPJG5wyHSPROH9ZlPHakIGYAkFdQMC4 BJpnO5yDjOvYkMi5DJkqef3LMhLf6Gr/1YbUCMd9QlSbnU8m7NEL6xS+279JF9IvrGNxpvuXV8Je /DKtpwvkNwrRs2gTojMrQViZ8yahqNmKBIBo/R3z7N6Qsk3vIXXlfrMIvdIhaOtIs56nVUgX9lxm axpCBTvSjKeVS4e7jNP+ctC54dBAg05fQef30p+3MS7oFtZqnXZTAmafpxRW7LzZ9dCws2VYV8/O NF3VqR7fjiI1ctVQpJ6dXCHIZsBG6up3J9X7hfbEFdkWP59EHq8MKa2rK96nHKszzQQzTWjTYWe6 lXigoZv+jnVFUma7V6I4nBz0uwkS9Ih9dtrp8m7yqAiutUFBtidiGajVBgzZeAb63rarvvgTUNo1 hs6gozGUUYp8uu4psnVEjLBO1UI2JksQk0eu5Fnrid2pxmq2s0o09VgdInUb9QaPZ4w6RyGs7VFL ZV/nzaZUuc+MzA709Tz9T0aO8Pl6DikC6J9azfzoPbPDaGrqsSelUCBo+6iksoYH8nvRwBUKGlAw NChYw4POztPpNtWrNPBQblC+1d6Woehv5h7Wr5ahMsGYswPquiceFfI0hl5wRXTYTJTuVrfg0RHx OMqOzA5CXipS1ACeJ2wvsgtHHSDkaACdA14hGD1KYBjwZgDtWtCAtfc0VxBHYs1csw1zeNHKfSH6 mqUDzxSEEaRiyw6TzyttJ9L91Ai6CO0sXfOa3sTrALviWmWGNUOk981oVP7OM8KRDzTYGXOwQ9qF safqcN1VgU0ASiuwzXG1EEHjFKkhYnvz09xHB8labMYylsaUiqp5onjs5d47JHrIWK5hzP7okxD6 omtYvCKANU08H3tH6lDnMvFUNIZXTaPOMwZhXqJOHfdqTUB4yVB6jak6K6p9fp8e71QAStc0bXgz ZXp0l4OQUS7gSaMwvUbW+K5JzJ3U1K+6Vd4lVpARRL1jtu9aSyZ3rfbisdF+SUUW1paxrZE1CaNu VxDDNiKsQ22GyARKFAmGwwznjidie2gC0yZ1hQnk8SAq7w0OxrXfqPWpqfLKCBhZ0qNQ0VnLAaYg FnKe+SEr3PrwWOgoDAw8BSnPfJelBG5hQKDYyrD5IZPz0DLUI0bfrewJDneN+pmGsPzGdhQdnueI dwRDA3s8z4iKXTafzNxyHwMbjI9nqMPm1T7dNBQMkDeqgcEzEv29lg5ySAm8n9ytm6vYwBRXasQ9 tvKNKmxfp+aOC/U/FQwM2PjuUXS4Wj2iGWn+8TASNVkrTBJLv5k47OVqStBAx8NQ7Zm2/V7WIJK2 A23tadRZ5FyC0llTnEYmVG+SjfceGpKYHbk+nkeMnOtTYlaRoCP/iRRsfMhEFqZSkb/DXFKQnZuG nPoMDsgeonF2HT4eBYMImOAKBvEZHBBwc1oftJET1CVoc4iY2eRd822HCZs+nXTDIGpjECqirx/H YZOgBa2r//hpuonH9MIm722KS/kb716SgG62ZgndVL7INTOZY4fpjYLawMvI9emtEX1ZmcYU7s6j dVsDdY6B2tNnZyY0uXuMoG2cJ5DJVFCbA0TWZ4/ZpRLj3UoBG5WWry0K+GAkHH0+DkE6hZJB1WZa EmvoRpmSPhdEhz4CkK5ls0sfmY0Qh0TmpvFuBO1ng8nnbLNTob/uUehPY86B6F6K06v5SbRwPrKW dg65eGfNB5jpGE6v5jRDAi3IPa7tKU53qFTUllIR636auI+/0+jTaYj2mcJsTTPhwqgg4e8wdwkF 7x3FJf/LeB6tBI97VKXEA1EjcrC/SGDMCJfL4v2WA/UKJVl7jQqY+tynPNId0KC62vgwtRa/zMl9 UfFTEbqCcZsh9JqADDKoFnHZvlGETkAjUxF6LrsyvnQcto3k7jRXH4JALYqxckUCUfyMMeiv9Xee vZ8DqMlpQGmr88lW3JKChMP8RiNoqij5jHMGQp00osey7RohIaJkN+EYSYV5tnzkgGmsUt+LOOnU khqxo1r4MRK3rq9BHN6zS4ogg8qS2toHy+Td5JQ9WoX1O+Qd5QMxWXON2rhVj6B2xBsVbRZC17iN ZZ5pJKaF824IPU4wnhqjzz3XzCQye/BoVKtJ1wWaUXXMvYlUWLb2iSvIuxGnHSeq2eKctbHB4age Zzma3gykuqTpTV/pDUaCWqswluSbmp+aTEdAV1EkSGvWNqjJicvBriJBAxv8igRr1sYUTFvzaHum T6chMnuKNmujMivBlpPdHaa3llHdZlKfetWGnRSzv2NmltVvbuloZSBAoF0rgynQrpXB77UhvoWw I3Z+jrLaN1+2BfnGz/PVZPqSfIEBiKWfT1v69/o4Z5UdcDwMp9f4kDDAUzRmlb/zKE5H0CtUnF7j Q0ZfG9Wjeaj+Kf9shvpXnDZDxxRGYVXoR6wOr5oWogEcxg5pQYdLyzaHg9B2lwIqAzGytOTI6KtO ycV7Py5kUqshp66Qw7I1n6h2JNP6g6j2DNvYApVPsrRUOYAyniKwKRII1TRPEjxmOG3sERrV9jU7 ZCvvpWaHHyeHe6D+Wh9i47aSGce4zSaju/N0LcCQFWo1w+qRiCCBxCGDTHbfZBhrMj3QaVK0yS4V W6o1OcxuNFurgLxmuPaMqHBHKsbaPC6Jt9Fu6HPS54iKFW6xd4++IHe1H/yPKF2sDk36M+OPU0yi nUzc3kRpxYGItnarzI13RmJNM8t293FSuiPyB0rJ5lNMMsY4rg77N7L1G0kUjWCa5qmwNZAPKcI2 Q9+8aoprAQx1DNeeuQEOoaLPyiMTL/frxC2PNlsejFj4CS/ivZZHtanOHyNoKdN74svNG/k+M4Cv q65tO8jUpt2uhRsmKltc6pSNciTkGVples8wWQWFNI9ZZ0rXjkyb9P8Mn6lpU/S4y6L1Zwf6uFbH PdMP0ocy/oDHjxPyAPGmjvhoLbHdcJ8KcooDFXo7jznMYX21mHtx2Ly5JCOzwFhSX5vhdGfCp72e vpwdyURUE11TXMNfRzOBNByitCZqBY7a0hy1MYJkjB5J+WdNUPRCZswxXGPLRj17JK0pEAQwOlQg mNOCwh5OLx6pRAoEgqqCksZDjWJtQq+UwloRNSqlOTCg+ywlOyTf6BNpgOBR2vTYFKrzmaUwaek3 KzapdwdyMSIzI9CoT2JozoEVbO/SVRLc05MZdHLpxALVq8q8/rwB6RBUmYrM1OK906/z7ts5G2BE 6NtJ8+0whZVPtg7fHX+MHXCjNOrM8Qcj5MbWg8ME5xI5kcmmRp2lEsEWDZwyvYb5M8GoMwcGdBUs e0zYajoLqHSyzJdTAlYkWVaODo+jdTW6awbTdcE0a3r4nLsrEhRo7jzW/IOu6OThMMVRJEBdD0OC Ja3A+NJpUPXvd5Ww7g2K+cgcGbCVFiMW+juMZjgBFAf2dPp6OiRjk9Y9ttj06QRsGxpWM5dx81sv DlOcK40T8wrHwytk8n5Oo2jYM7KeSTLbuURjRcNOdRh28pEryD8lTY+jGGk6PbLH/DNtoyHR3xbn KqWW19SNLojDuHPWiGzeFdpyWNBGFRi7y+nueTRElMzmeDYyG7zn0DwWb230DS3s6e+4uu1MgTGE 4bCyVqBuuNs+nm478wjzSS3UJCdD2TWx/jQTJVEA87h/eOe9Iz2CppHFBAkk0MCTEkna3vSuP1JE HV1DtrSQjXV0fV62NtqGrbXCargzen7Th+XvOJdE5EQVi4Sn4U7VS50KtO9jhwWPNdyZ/IW+Ho/T g1b1efzx4/RJme6FbCLX0W1fzGGDOiK7akOCp0FNewUuh7xbCAUw2o1MMBlSTPfXp5tjivvP6lFG KuzhR2o/mtAlHXaQWP98B438T/+sv8V2/stf/v1f/5NCdUZt3WDm9QbVlKSfo0M0UKiu6L4pVK8u NeMaaznkUfZzxOuGWn9iXWpq5PbhUgNDYtmAto+lbXWmbRGHntyELr+/uXNw1oBcdQysnzY1a4R6 bVOnA2iyGhbMPjVTLYtxeFxEVCyIYBRvWLD61IwI6nTYq0gdEhr25knUpxKz04PP32niNaAUY7au O5ON+IjJ40ik3OeGRiIhlseFhknOp+YxbdOCFHENDdmeKcLv5UJz5i0hl6AWZAoYUj1GnoaO99LQ PtCWqMJ0nCMR2tatrTkEgkvCjrKCMpesDabZ8l52KU0g5UJ7oknL5zQlfkhKHeO8h+7GCJrlDCz2 VZ62O+2EugyjW6gXsA/UajTOkpTJrrjUKWn3eUO72jyXQ1gYlWazOXef5kp3QQlokbCa7oyp67TR pjdGQHFdR372KVgU9en13LaYkVb79EK0wIO/TpYcyOLrN5q5/dIUISHfzRYN2KwcZUJ5mnE7fD0K 1BlbhJRnisDa1D6TthHPCwr/5Tmy4pKZHoVkFNoC0NFXRItrhsDooFLFI5GlZRnYxz7OEQ+RKil6 YBJ54pt99y2MHSnjZFl9aiaM80lS8J5Bcr30x0bEAjPbG5k6OU3nZHc3TaIWbxim17CXRFF9UYWJ Mr487EXScgbTa8QTcTFqzGOPjZwU5AK9jzrKIzfLygOfSc5Q8AJyGOZ8lGIgk95cqpCUIMq7IXTA rcQ8J71Urb169AfRkHMDbdY4TbYs5OB0LY/KxMteDTlnuS/sxF3W9IBMQ7yma1voG/Ch0Oi5xDDk yyYhL456FdQSKHUU1B4DNJZKOzVAi6ccMJWeY0Q2hP/oHnmgmhBk1CVos9luCQE5z1z58Xeelgss DaaPk+Ea0ZNqMRBTjW901/mV/CYh5wbDtTU7iCz/rE7zm9QATisU5AkFia2MOs1v4nFllBJoupYb 33/16R7YK5Jrt157nr12QqKOtQuzbnizNrjSheRmrUvwNEDZkqXPuNO0rgZvR6EtrVEVLt0s9yE+ Ia9Cm6ZsAiZvCm11jUKY4JcYs9Xf56nnjvV+yupPJ5aBtupR+0+hrUMhCU3aFNoYr3Vkjw022dqF tndGmN3pkhl18hOt5jfLnSudsGFYJD0NUEaW8qlaotCWESlcoW0NQ3BxrTBtmz3oOJpIvAlt14WM aRTa1vCAWT6X3j1OeRXa8OhtJqHc2s3pbVNoE4FZWzZoYxl1zx7ZRQoFucExb3pIur/XEmwb94UJ OWnNQkjTMJRBktBXm4YKbAlt8mUZs5HD5KU+aeR833G+7MOb5AbsIpGp0BjZ2C3lVj1SdLW4HlgZ vD7DA2KPGnrxmYEOXFzXNTxI1JAiehTQHGG/ofeJJtQKeUxnrpgEiLvDXH27EZ9Ai+tlxctcK6P+ OXg8Tzog8UvDzsMHZyRdAz1/52ldswIcduY8hPQ+SgzF5zzkPIH6gkHbMw/5vbYpFNpO8HwU2tYI IbGdXp+tnBH3c4PQ1g3amJhZzsFhBnrcqaDiWqHg4RyztTefa5ZNAwje3ElzhEBEwvPIhUx6X4WC q4eBFqs08iyXVOL6ahuaLC14M6M+csh41FufkQiLpCN73EqsZ0cipwptz0iEdam9Ftd7R4tVqc6R CFX9aR6nozWXBPpsqWvY6VolkC7oJznOmx13zXHQTVNgkzlAIFy2UtIgLlX61N7cddGcGsedNd9h uzsfNXsk7OcwjRn+2KQuQ19O+fJS/Ie8t0oxWrgQa7KYWtaQRoqDUl0qgp4tdgQDUtszqmLFjjSP 7KKkNw0UOxpynlEVkwmPyWNt3cPVzz+GnGilWwpDyIqYhs/okNKqATQNVBvUOXijCu45OsS0Nu5B Qs4c7BAV6qopBDlOene9cq4Yg5Aja+5WGUjX7NEGpR5joOGBfpjVnWakVo+eW1oYbHhlpz1TN+LC 2UvxSS7azggz6Tmmois7w6Ph6ynHBhpS1j4zaan89TnIi55osuUDaZvKlAWOkW3Aa+XqkeqhIC24 9ylz5IYFz633OYjH27vrR+NE0qb6dZbyLKaARn1vdBPxVRqb4hMe8Moa8JJNUSuqPapKKUzfeAW+ rakb5YB6bXhsrcN8bY6paASt4hIKrktwvrbGILh/U6VUogr8KhHnkpaRzbi+nTWlYibwH6U0IpL1 bmu6H2iTonVNP2NrrHCrmpg6LNxOfR7A096gYE2pKGfSJxTEe7/AEnwd7Wnl/l4SBYpsKcAEdE6p qNpkHg57ONfVbzSwbtGEZFpj8n9ainocUkkPJ9IynM4UQ4RVB1N4zt1pNOx0WB0EWSM3jGvm9kKI OK+KYbQqFYSdMizqRE3nsINQ1F/JRKW+TyHrF55O3ZD3QQrTK7VlKu3hs9zRd5OQppRGnTVA5HTW 4NHVZcRRbwTTzSZuZAHeYk7ymOHIhgQK9NOkleGQfLr27pEmdRtpAHYKluUj86WotXjkrVz5qMCF z/LpRfUgO0gfJUWXCWi9T+B9oFDQ12CHUiZ9mnQrFMSKatFmswO6A99cGtfVcCaQsWXT+BH9KzmN SRQ4NBDSpxOAbZ09nWdazaQ9fPL0paQT1DpJUW0RWplc3ifnefP79HTtoPNhULCmB5Ri6LMWHbHv F8wKbHrA1saNMOkQCi5NJdEWRZH8zN1YMdqzRxmmu6WB9t3GXBbVf8b295p+P4dgsPeCJZvrWNOd rzpTpPJ9zKKvTnc0KWgI2RQJngY13Rt3mRRk2RqIPHlE/Tb5F1xD0ntyzYpqFfGK9FUYqlHPuuTS CinvO7LjVFRbkx1WHXzI8MhkzTEFIFqkKYFtJVtKgENozFILiTpvMo1TbD/PRf/GK5JkvCKC0XrQ yjwF36RLKqwlULsZrD3N9t9rZ3wLVdBsJxeZ3BU62uGbld83tf4FXAuAwqa4Zq12ti5uTGOHX0Zx rZBsbU3dyAZFTJYr+DvP3g9BmlKaws3scwgtDVw2DG8TyQJIEIJl02lkRs+N1QQo3Z1HSr4QEXyE mU0Xqp87cmZI/WqrIN4N5QVdS7eRKqsNPkSIhNm7aHDfB/g6sko3ffHMakcTVIeM1iPb3AOG0Wd6 wIa8PsFgxLZnlFH3OT1gOpMK1g7vmpSSkarpCHXp/LCVkKIpm0O7EMUBqEI/dXEMqYnqrIbaxhYp 3uSy3bkW0PeoyXps+he2UKV/DB57oFfuA9PB8xqHMHXwD0nExOFlkYIdeVJYAbfcdpjIceWegq/C wREOpGE2RYGHCJVsDi7J+iIX2oFvFnhia2TP5UNC84htZ70iljYdz+yNZaE+18Y1kBbQLUiGbRpI 6d5O8ljCpVjODbY+5koVI7hXfVQu2+0CvUW14FlhtDPGxwisQHgVCdI+wNPJ2XAtlkBYuh8Sk8fj aNjZsEJBmsKzkQjpRhMNdIgEV94DMKXQtKCsaRXZevMqRn/W88AmG+MZjVIvJKemdQ1K5uWy/GlI e+qzzuH3sQ2/3jmsPy9W/RR25pyXMo717fj7MjVuG5BekW4K1HoylhI0acyy7s0UJ0UtK/+Yf0Zj tVoUJfesDpeWaK3EiDSlNIrmFUXJeEdGZs2CV72DsoZRnICuOa9Q/XaXMH31I6C2robRusIoznIU 8CrTb39z/HblbQPfx8LoM0agE57hsRod8coVILWZ1uU6CMU9teRxUUzDTgHQpmFnDqwYl61qcurv MJrgVIIEazQqBKmdlqJ7LxkpsvWhf5FUWaeAJjg2lnsrwdFsDWqd57I0CshuyGf8lffcBBWjC5oe KEb3hdEE07QQZf5775Y6WwGmB4bRTweUDRByZk2pd2FN+oVgbcxpCKtz9J84bOe2Eg6wS2EJW18J G4k5oedIzvPmWpXCdASXzWB6jd6Y27hTmO6tDFRXK3ZbgjNaJtBWQmV9jzfLnRHqAd2QhnVAubVT EofINmKIUIapG9PwE4Usj4Oq3o4TGVLkVtZNY4yPapqz/m7add8NdHBkNdimjB5+ODFVh5/nyBJh g62FNQphjslZiscoemXN2GDlVp8GKM3ZCpNkexcLSh4Q2KzHxkQKzNveYbFTJCJrUZM4X8MDRmvV cOWw66FJTgUtQ01yyjPbIRSJoEWNw/Oc9dghv6iF1WxnZMNcgkdSuGIBXA1RLHhI7kyqIFlU8nee fgbUK9BSNK0KjshNGmnHYct9xHwHWPHMPIcRWGJwOegtpaMly9bMqSrVRiqekqrWCP7ynLPkE2qd t/C0qIlDjX5Fj6tIJR4XFM4rS5qN7YyKmb74+zz6dkaHeYE1Qdnu+MfkvLr7NneTgchfGkjXeIco 5EyuIblrr+rmtXLhcYgsVgFZh4+1mMyZu/Mc8UDO1oYFT5Oa7e9I8EgxGi1C8mTLluikFnH3Q0+a ayWyk69yW8O5Iek8yVNWpgay4C/So8edXk3c4BBBE7clWMB6Bh/Cvs/biY7cINGRYK1dtt2v17E5 nMVrlVARuCkYPK1QRvwYNml0d55+XAew5IzNxD6C0AW4aKZ27k7T8r2jRdiwFpI0lOLz5F6FCYC9 2Xi/esx4aiWLWcAWr0tIyeFtU6jOSG5O8lzoU6gmNZw0l+3dK/cLpG6WmT39NjbwFdvFdHeeEVtA zo8S5iCBjRR99t4VqgNit8rENoNqynN36VclV9qAPEbT5HTa1GBtwxJGJzOr8qYn0h2OG8xIDQrS hAJm/FgkM2f4d6Egoq9jULDabWzdUrM2cQgFteozAdujplkgnyxYfSQ2wX510BMPZC1oWPA0d38z q0QZ90816UgpBQ2hafxo+et+VfnPd3TI//TP+lts57/85d//9T8JaXdktOAbR589xFHpElzPxCbt 5WTnyEi9QBEuL4QjfpYyuke70atdJzCIt2R0UagI+VArOfHo93Sl3vCApC2aa6frCDYDd/d9trhB rbZcly7LYOkb3654j6931n2DZhUtrgZ8JqtJsSaPC/IpHXBbRIJNshnhffZ4/R3mDvsFymxDtrqQ DYegVIrPPbjcOkA2+8NfZEq2pqhYHRyeZ4zSkct1tYHCEFaU6qmrw9No3EnAJSkZQ2rGHUJwizmU 7nA+otBWoF1ai2uewMQYnFrE99NMEUAL0UalQRg31GkLRLFtgLrHsG1NE8gOadbH5TJr0+iCjCAV 29Y0oTOKWwoeJ9ma5WxIoynXtZUwKKuFZjnvqWpe9x2B0rbItCBXYGOLiskEaNx9G62yd8R7V2Rb w5HM1v1r9Zi0Xf3YEe/d7tmMPIwS1jJd7Hs3kp4nktpWGFgUKsI6ikVrcNIRfTOS9h42zOOfSiaj sYVyp+zqs14HYFHp+0mrY52pzq7LzK23o6HMTb/PYr8z9XCn3+fK9UR+nfZvVyyli7FSHOK1xR+k 5DqmwVAqVJ4l62V02AFRfGtoUV4/zWIeEbJBTHRG8q6u8yk3oLyWJTylCRyZlipOsO2EN+G6yRkA qTLWbnBt7nYY3uLI/wDl4F+4bnvYgInN2vrXJ0La1V2CT6uHFMBpDNyedihT39cy2yEYnC0NxAXR YLpGPpm5p0WXA8Y7bQV9nxGsXa1gPUgwbebo4+88TU+AxJqyFaa96K0isbSG7DC3vrMMqFUdbP6b 9NORWOr082gsTaiWUyRY1CNqeRsGkwR6tSfa9wQlKeuUpCTT+Vg1F3IYSkeUC7mQ6osyog5jHWmV 4PCqjXAfER5mso5YQyea+ZC7w2iN0BEbuUzmhIVRxhY3eUF/59EwmkE/1MLoM4hj5/FJeE0hHOD7 tDCVg1NhSmdezTjidqPFq2wGUFli+HI79Bu5/F+W1Bv5RKv/tU5vZTaPl9Q9uleMOPV/AazN5WWq gRzFIayl6+iQnBNaX+kNGWG7TW+OAxHCFKEXmYV9nxKKR3cEDTsJMav13z5jHgYEEjxK6ChMV3Ce NhV0DKa5IpA4jDpnkxt1pjSKPjNfFnaGS2eeHO6Mi9GRVueQnEeGFIeMlnrVnxct/hZ5jMevkYfp G5XKtpdfZYrHgNyVo4YjaxU0Iav/pdTI1kZedeNI20b61GEFH2ZJ7LRPncuJuO968dbaCHs9Cgce pRkUrCM4TwtTFSgVqufqE9w0N2ho4dcu0xr7slxnVI8LpRp8NjyWT89YngTTHsTj99EyIWGwThOs yZB0dJdDUgWDBjJRA4NnqEh3yIZHwlG87x2cp01ZIAMDxm7zyQE55B6I9S5N1ky+MHCbvQR35xmj DRBL9W8/+hCmjP6RA2nmtO9LDL4sUJvOG3DEczeBI+H7ivrpGEy/KmrS9htZLNc2WbtM5D2U7HHV t0lCLNcYpvt1pynbJzy99xpTtxYIaFWk9lnuJCYibqxEZg356upLLgkNq/TWrVnvoMuKOTicXWvM qeA8bSroWMxhvEOf3YIcQoUKIHHobRO2XvHZhl94j+N69a2iYtQk3rUSJdJTMeUeHeYDmkxnvEkq i1ZQmGR9Fo93rV0po92XELQW7VrxsEZbrx5ZEmPIGUDTvbY15iUpQcvJJ2H3iIjDovdsEXaJ9JRV quw878adVFAjRz/UGo4OuvoiHld8Ne4E8H3alJuxuMP8xlr981cuf6GPs5eBTAU0zckrzWGutyby 5O+6nS3dWLlN1uyarcpX2/bx933u0FsG36ePNu1FSBb6WU7d3hv2tiNfEKnXsJdJ8JsOmr9PcxxX QPO3YM4vVu58OWVL30dt/eqnKXc4gVt06cactJyNRJ2eO1vvfZWnm/OB1pX10q3ZKBHYnBwWhylo Pa6KeNS5zUV/tg/rEwbife2AX6QhdA162YqV0b8cjnZMbumnntRfhVlEfrTMkk/+XeTPX038O4RZ rrYfiAJmiqArC2VK77V6VN4+5L4BvFlasIbxhaRtToXBrpQ6MurStM1UD1NjNr69FibW9GbalmO4 wXmsBljcHKJkEmMpxWF3SmvS1lBjty9yAWHm1OR0XpUbWpAvOazhNWvoSOgemW0agEpHNVx9htcU taPHWXw5689g8F8BqFgA+nJ9EP/8JPTvCEB3FkEJ3AizLi0lMPl6n2wjDagVXDkLqGu3gogbfRQt AB0G1LPlgvbKNaAugkFhq2M+OeIK2PFGpWlfBAOW7rTi8TTbtkWkC5aGTUnzb2W6nvYTadBZqtNX qsO2rIRq0L0cTCNAAgumi/xBBKtNnsWjOku8zw34w2kwfcgfv9eySDnPFEE11yyYfn2zwkUwrUlQ dm0Dn2oDn8iw2ic/ZxtnQYL8YeZvaRQmFKhJQ3aoaaLFaUaOkdLywzdijdGh99Pf9xkjHRUWP4vV QiQMQokeVZHTSBtitehXMWpoDES7LZo/u8N21ZVlR2Cgr+YhgpBSO7VWHH6fcu61gurHdJE5qfrF tujfU/2UvULVGSNSzY6Uv2NRtA7tRvlOXpv/dOvKJSsshZrB7qUmOw/riOlVj+hxDbvGsaHGjiYG fSYGLHfzOcy+7usAvCNZQx/9AmyIFcXjoq/G0QrHpX0SWxhhL0eX7gLSpy3XH+u4MT3ItI4jdY/o eUkW+q4ymFRQ91gcfYgt5PE4HSmcbXSgsmlZ6MNyY/uKPjVqFQ2QVFMcMTzqLOy++ewg1lQQ4TUG ReuJ1aQ4ldyZVc+rvLCrZ8QL6yb2bhxRprOpyZ3D17Pl3BB/V//TmeVQuXee5by3ZZFCQ7pTmuUs jhvrVXsliPbtBIZ3Gkcn7YgQEGPoOTiMoxp3AhAQtrjzUFtYl2qYmKi78xxyCd6Tzw9jj9KRXdJB aq0F1Nd57o1IbsQyxZDAI7BVPRBkuVkYtbDD+KGZ9g7fzNpqKAPMrWQ137VEYF8n5+pwDKclQoQL ZGPyDBjLrdTscS5/5bSjvZGS48MzoDa4Lgs4TakTGMMZtC3WUWWB1GdKPfYblXCaFyziHtV699ku kDxOSKIa4SFRfd3Y91VsSxnxKg2q84Tq32yvp58XMpGuY47kCefI/HmGw7dz7SWBwJO7DUU0LWA7 8k0P6vDjXKkfSBxMofqZYjMJgyLJ4XnO1k/kK6BQvfgsZE1ef6kw3fpX61EtK6FnSlsigWwq/8ly wpv16IbUWRSfF18vs05OSh47bTWnA+30aGL6Y1hVytRCB5v2vht1ChL/sKgzyQVsNUFC8qhlMkYM B2oWjDm8pm0pSR4lqkWgwnsyV6tJOyQ0PS12BhtYvWkhfcl9IwVxDTtzeJ2YJuVHbh6Z1YdcqBzV sFMW9aP+XvZJNVQknSNrJhKNwIbno9UMMd0dJx83UkQ3bJvz0cR2l30WPGOEXWBGvQaKTDwndWaq +GoKKluEiiZ5mipmaqWm19DjZrkI3LIwrF4UcbajpCDPiEavWlt1/bFgSl3WQLHSPb/kUW+3xrRD eaMY5wCOOKlpAhTIdftGduivKDgOtOKnSfUz5GGkUJ8COqOfckFsW0MeQv0IWu44DDyKbRUqBOZp q6jYxvaXW/MoQVdDwyRKO460zjptnxjzvPl2znbvyOVOoW3NrCrjUObMhvGvhp6r/+wY+19+vuYz lGLAyKYhaTTSpk5vUguqrWTDijTOkVViEi01elywUKBGq2NtyvAbUJNWTtbP6PA4o98lAqBuYY2s CBIUcal5uJmxJdpOGmFtJ+Gmu5RhFnj47bxbYI8dCmfk6Ueqf2WPx+fISsKNNuFs1t7nrghhtcUo VBf93T71XUnD4BkpUq8h2j18FdyiAjKMPHVGHnzbxqiN7fa9+XrycSM3Uos8cwJHzEg/utmv4uPI u5EngAFpmxr8FnkY5XC64Li7a6Nf9wCt3RbWQJHaQIXuEAnuNO4DTq/jtFZtpPFu9GOWU79KCN3z Ad5Onmu+NiAlGhM5j+qQ36pAjdTBDKifgSIjF+jncXjdpNUzQKDuE6ghskXzJQ6k+fF9+rS/UiJI RiRKBeo1tGIKIDl57FPXq97IRa2FNbQis3hzXPWYs231RGJnPZlzUqqZ7PF8iF42h5zDK98Jb/yn Z2hFbZZ95mwjon1lizxrk4d0Qnu35uKfvZ/4C5G0JUF+D2HyC7RGYEO43LNHsbPrajf0gpIpv91J opNyN+lnd8fJW6+YRVmfGSlL3HwSxKVKBAyDaFm1RVIIBrGF2DIGt/hmjVA1X0HgppF0jUgZVnut Ec6BXJabDbBHZvQCGdVjX/fK14F3/dMzIqXdApdjkRLPG0QeWc2pmNi+crVK1t9xrraj+jrZ0GNO fHHgqbUNvajwPOVdNsvewEqsIfUz8SWJaByjOpxapbgF4CygSJ0mUsPbptew9EjEXV/V2DzuE9mU h5jW/Jp1c2LyyEDe7g2VcJa1pZW1EfekFgubi7z5edJeroGz6ryyanyeMTQxIPvKb/ZCz3bt2IKw rhlpY8svWt85rEpTHBuQdLU10QkG8PVoZMqx4aQ6vVnzVK3i0Pq1gsGakZKxSJLA+AXfJxH4K83Q 2tH6tT6etcpDGjrRDCIddg+vthUEbpoZLP1tAm6aVVORpjerhDw0xIPvsyyhcupsdUx/mceZfLvv DewmiRgYSCOhNHWtIAi0vVrDXa0kVPTYJEF/ZPJtRFxykLctHIjzHozNMhMDXCWkLolJ7b75dbSI Q1m1FnHTfkxrHzZJ8Nk+1MSgYDu1ukbYRJ42Kop45Lal2G8gd6iJwRphw0ja+qhCIk99d99fkJyr JQZrhE1KOH07Hku43O8EjVN6nHtwrLXrUgo597OhCk6jaF9RlJFzUvDYnhqjCI47acYdcpoSsjgU aEr7PUgOuqhgJCvoKQjbTXqzRNAcNAA1BstB1z4CiaO59tjI93mzRtA4GrFwjjxjOLp46bIZesiO mrsWRxfDgHjGRluYdXgeTXMK8OiRbtctlNZYmlMoeerV45wB6tZrIJ0UA6YI5nQwcoWjots2DaFs YQc+HoUJqQUn1eldxoT8/HV+Cj15hh5C1Ms1V4caWneLF1IQD3OZR0se1mvT47rste1XR1lbHenh tuEstLde2ariq6G0XhmvYbdlb0VG2Fp6R8Y3ejOUagkXsMtqWyP5Rl1wXS6Ppa0je8VU5Ie1bL4u t/19/YKv1gg1xQvRQjXszHk80ZkxBeQ/v+D5FZwuNzL3bnHN4wlzKrfCSKHvrsH1HazExm5GD9J6 JBvLORfC/XiZ2HYivW3LqJ8tRaY45TOjHqcciNgW+7RG0PqaCc008cjZzWW7kQ1U7ss1llGQXQJb CqfATZExaVNCtq/DKCwjeHODdNtiBPM3y9jWXhIr3kT/EEhx/ebA6tbAc+OMbXFCSbkTJQ9GOnyX vn9uYA/OMpxFZWkECpy22mo6NrCnaNw9xbcSSHEdNQP1WFzXlG4UeYLmMTPL+b2UKK+Ub7Qsoki9 ZJpI/WZUUtYseHmguG1oH8E6oTyhrm0wbHuXRXlWxJWwNtpMcyJjsvgcwG1179CRpy9HHsan1nKU yJ7Ke/ZChxxoucKA+qEZseUKn+zwkvcBp4ljcg4Fh51U9B+RsPMmEPRwXTBp63NrjLnIa6Hkcfk6 n1FAh9qiziRNkRXFjyTBY8N9G8cNBlaag/a190JyHKm2++vvsqX9FpKDLgYlyQr0lrZKctCXSVNQ 7FDL0WfcywTbfJajo28NZgVp0YyYBlAZw2HPve/lBLct5TZpOWMQZwSxTZ5fgupNcUQv+H+dR6+0 hKZ/cuN7050W0EaPJaNrK4GUpqVJZir8L3epIlqH0/Rt8adY181pl0pL04J0AjXjefhT1HjM5ZZF TVGAp6JF1ck4IilPLJXK1r953e5UTuxzlxYVmWUJtUl36Dcko1wnTEgn750IiUcZuZJa7s2YOtoQ qD6VFuWIlD76pqJDKNj63ZAOXbANpZnB4a8jWdpwmPFc+djR8EqhelF0mH6wV6iWo6AdmGE+vvoN mAAq7b/n90T47xY7vmsyO9aViCHHOEpwmL/dJexo2KP/pk+VCaJioHm3yVK5m5Re9b7xMmlfKyPk tpXRhZlBvSof3A7kG21pzkNvw/WCpNaCw66b/l9Gnt6xT8cUrebYprzP/cuq50FptaZti9+Gi1Ot WDpxUntVESjFPoDZsqY5k8UvbFT6UT1+nLRfsFOlSejiIpOvU+vInYDBm+PSK98nlqXMS8ggsnGc T2+rQ46Oa7j+EKhIIuqUHbrXuCFwG21JHA1y37yOSPIZIQFRwW2xqJhuhk9bDs0N0FKP5QaLyk/q BAX4UByywrTGbpgfKosfyr6PcawcShwpvCE4MHhbRKpIrTlcbl1p7jbwakJ/2BOMGFaqRyPPkXK7 AQtxPp9RC1teTrE67OjUFDqihYWYF3mCLVr4JE+YMgMS3V3mApZY/17CJvuVMuC29Phj5EJ8LD6j 7H1f3vbVlsFoWmMjuaa5cKV/+oxOyT/Mq4OEekPFGY2ii8VPkrbcSmETrDejaNq2hDw8NYo+nD2W hObq0T5ao07G8lN9UUE6YVHFVMVh1lZThN4CitOLbsD2FX36WFxFww6s4cpDoyI4bYrVDsfZVz1g GO1jKBqk9vXu7jcKOX4Vqq96IUKlYttYDETydnIMjWHBm9imBTZqGBgWrCFpZ0PfZJ0rd5dNC9IL m4/lNSRlCbVPLBj9yh0k1C1NgihBgqjAx1rv76oBVaRoUqbHao5MldJp76OmDQnRaU6aFlWckPYs 03ZYHpxtv1DWpkiw5gidzRRT82hQvF/tQL2PGIbVPIWo53zm7P19x/nytmK8T6QLprA2hwiZLclT MeSXefylIHcejaKLOkXuWg4jsi2ldyUz2oXGCGVu/VvKxsKOzz3fffQNfB+pwwY9wrps/OnI942s vvp0FNcGytikjTVC6IRnFOPwGETHiDtUZJDJzCFsyg8tUrPDm1ZTuATXbnOAkKlztMuHc6UekbaR AsGavxGzIbttTAvo3drtRFvyBtSLLNEJ9d2MuhxS30e3n+yP0+sY5tZIIV9Hs1OPlMO+3TdK2fJi uI7ODG3WDwHP8zlQQ2p1zTLqN1elp2DdjLHmIuTaeaXuKmZX4BurmD1VdFh2UEb2qM5wnLUg6cMY ZWXWJKB+0nt/L7POZ4LLMEEruBmAWNXj08ezxusEyhmlmw5IFKoZWjU9IIjwKp9FGkI4i6dr4EvI lNae8qiB2rcCW+9/RewRWFX68b2IXYt868Ek7Df2IrPmjrFESaKgoZdh3KsM63qimYIlPosJ0glj fEhh4sjvKlHtgnQ0NKI+Mx8i/B5qYcyWd3Xp4rHBKmjqHTFPzzyE5QdvqmiMfkiBp5kbf8QbyiIQ 0Qx89TRbzPHn3ZGkVU8PP3L80Qrdmee5wZ9P5c//9M/6W2znv/zl3//1P9kWo/mOfQbcLOn5+Fbg HlHSNycMNxxua/4zh6dMKtkpo+oqcSDp55LrGp6SbYXPPDHf3Z6NyGf+p3vHenHfeu9a0B/lez/U fSGxEFlen8Y0IFvOMTHjjnenJ9uFlCtlGXdofGXDLZ+qvBqRrgoj0hw8srS795QcMl70qqHVWcvm FiOpsx30Oths61W5kD1VZA3xN1Sgaxi+USFfWRDcJZuj6D8m0aiGVhiffLy5E3xe0FVBy7xJfRms G0yzofJ9RcSXOyXHGIDHI0vdSWGZzSD165EK702W4qH1ELZXGc+8m9F7RyXyTm8jdgf756nlVUOQ vGdMeRR3p+m7RKT09jeE+4e0tpumwe1bD7afxw5pCfGhJXxda/S95qmp3aNxV091OdCTyjUrkDNH 8Ff3ZXKCim8jTm/JUhinJxaJDqsHrYYEUf61GnrGkSTLbk080uEUFQ60W/9fqMAkatYP8X2okHr5 3otXzx30uSWXNGMrG4M73QDQaqijsbH08HAuGCXbZzXU99yAR8lP9+4f0v1pUcL3alht4yqIV2ZV eOuJjFlzyX04TBquq2W0CDCXhTWvIwTTWH1yma/cBaUKit7P8Istc/skM2+1VyRgpZfJ9FTTL/hH fJ9x81dTH5F+IVm7WMKiMA7WaCzCJpMvQ7aggZdC9kO5wAl3C3pgh6mPVgghwXJoUi7I04m2LeRw QKQB6AQE058C0D+mDRwlfndnTn/0Px6slfGjyyhf5WjH8d5q0Nhj3//YMtXKbnHLSOlQWmLWUu/e uNLBIs1PN+4f02L89pRHxobMSwy41wbXIAerLXjUUTysyYhz7TXZJ03GmFrzSGrcNB1AKvJams+U FANdzsWE1dyd5iqScQ7XnnkkMTvthiD+ztP3KkgL+2+w8I/py5lY3jfnP+NEIyJ9RmuAN3AsktCT y/ynXTus7CTMZ8SEbKJLna6rpBsv2LSlTYzdwz/0ngSPHshbPiMUuUuLQktQzmsX+M5IjXTEtLqm ZCfa/JyzQ0+jIeVAS7dZA6riHM20ExPyfZUoJ4eA9CCGWOdCNEuxnQrCiT4RlB00marRTYhiUgmx MI2hNycOZRtIxKZVmfXPl6UR6nsOM2fX5Bl3ENZAdTDbD59U+q0eiIugSU6c7aqvb0F+I6p9Wbci tR2tOWgAXRuqzGbb6fJ90UIA8fwU1uZCNJMac3rXRouomyhrf9ic6L/MRXizJk3XcQEosIygroyA uDbWbnYg7jICiZKR7qBGnT6jDlFJKTGZd5O7qHNI38HWrUJ1XPO5QTSwpYtHh6ax7chHr0bTJC6V rDbU3JgF5av0+VzhSnSWOis33DDIuZlntbtPcxUNozjwLAoCMdr2SrOqcgqq3DTwzIX1wpIcnzO5 UgK0ps5DVpLz9X2NNwvRAX2pR5wwrWGHhNHejB/n7uOcXf8Fe1JxzeQGSUFHcunZKFcOiOVSbTdD f+ICoS32WlvBnye+ye5VaKtI2E6hbc3nmbuu0y31Yx8barJpgjObUqQD6hMLquwdSAgoTre5180y 6lapkfObjH/Faeitm8fMDLiuCBdRfO/b3KFHRASpxorXT/N1Hsh7hfUYY0cOBcGMaKfdD0kIevsH vJpfArWIzDTLtNg2UGMLgT4dF87eNiix3uMzHmU0f5+dgpI6dJBQXJv7muX3MpC4SrzQcco00bTr xjofPs+j1w1po9h1e8aIJKGO+msdXrcj5QziTi6mBJfTl9e546siivuOe4ZtjUKYH2gtHpsecu4H ZrhNCQRik6WHsbUzd12P0W4Ud2QJp8WEmzixSTDNFHcdtiHmHgFmiAoDWh6wbO1D/5m/m7afZ0XD A01vVmHwO+0sXSUNwOW3iPNMQlgE9ZkQHFI3oPhkEecZuzHt0Vw8up+XWDYsSNHWZIdpXrfGeh5v AoGiwA4Sghbn3C3prfutTFcU107kC5xTMG4ESwc+8nD4dNK1NdTw6CPOMVUnNse5tjEI1+NVGeKr Xqiunlr+pvTE5C1HYKrK79YGBVLYyrSTMqRmmho+kfrsFcp16r+bU7cRfi8Vb2kl4tlBWz2p32l2 UOXoaFVWw86a68DDxFBaJ3WovNkvbP1EYg2xDmOF66chbanYpf35TbZfsZ1tF1C9lpzStDomOVvW X0gmB+9qNfTaUOlWplYDyQmiSGcO4a+KKks7weJLsiVSzQnonkjzqOC97TGgGWIU86LvlWG0y+a0 RpwNat/3lFbEYcN3KeTdvDt8z30DH0eqqcGGyixXLGMrDjs4VbYT0YpC7GtGhSs3zUwra7W/q56x NZh+iu1cGkuKoLRWdtEhdTpvtSB1kzzWvjKjTLqEgqO1G+3zhTgTglETYUmVlNkGxZsJgRYHFVEM yzRis+KAuZmG5NGuyPJlMKdqcY7dkh7ry+paLxuXbaj/2dJsThMf7Y+kv8zjaaT3A2Y41s1lJs3r J/iFlbc/9zCH1Buziqb0piYFTLnA58spacCMTaPonIhW2myX5PCuKbAF1P8s0xvLgI11DH0O4LU6 SEipWwHP3g7jevh8O1u/EzIu0yhaVxQl3WmJ1SOxXQsENN41LKgLCxidNZgvpbvLVmU/kXeuYsEc 8VaqD5YYFfzVBrWNpmFSsIYHVHLTjHL8HecqeQejKoO2Z/TGRlXdHpa784x2bBUmOVNjhrGNbYfR 4WU7e7mhhHVPfWEBNV1y6Ts9jlbQ5msJizLJ2LlO29NbBOWBAducila6UJXZYb5vU/QXgO1OEbIm o+2KWhzFSJCKJCaL8eqC2FERK6/FOalKdMvaa/WWJCKPyVzNY7KxmXUJmZn+vRx2YB+nTC8fDTts LjqlAf2dp92HgG03MYUcs2smUJBrYHo/bz6dw8aIMOzIMxVlfJzucslltO1nB5Kfvk6eX4e0pYqY N72709Rad6SI3MukFFBbC81QGX3l1TWKNAoif2kYnVNe5joikli58+5ecrrQ12lSno47vm1J6zrm 6vXq59mPDBkfYTEKGBn8ky2X9/wSkv4LSRvaVZs5AZMo8MlsvzNsUEdzpDKylHXjMbKlVh36aF/3 FUG5I8soKiYSRj8+tLDzKBZcY8J7O2MtIzIj049emTDOy9XowBLi8oyuiYJZGt1jr6DKnpCaTIhj znoraxb47OreLZzInyOY2qkVcGxNLNfh8fPodUPS4XbdnqEIWxPzmYXaMwDfx/TwVvCha2I++7pa xCEfYH09a8bDjlOrx62qO5uqJczblooZW7VOUdgY4dU+9XE3tNhvXyg3uptcI6a1Svq+Gc9Xs7Zy 7ZCkG4K9HAU2sn/wmSHmm1JMd44nMmvXtC2vtI0ooWul1BwWpIdofY3zgmdixaxFJHjc4jPHIaBT 0OKc9ia2lGj+rNFh2lal70inQIF6DeBIv8CpnaymOR2Ja4dlCKVpDgk8fQSPtmpXaVB5oZSwJnDM 7ldBbDhEA5mUXBhIlzAb0ZzMtojpcIPnLjGg/lRPM/rUTAbYUXpkcq3v8gsy2kgytH5mimzi61Qu K20BybkrvK0xHEkOchisSnh1qyLUDVQ9LY6HX8DECmr3qM0mV7jTH8dWUUHiR4qRmuIml1L7ab9v xJbQzK2vzI2kBr0Ks0J4dcP/0OQZNncXnTr/Tprnl+YrgE5tgfRpt7FWtYKBw26oAvXAiqB5TeFY d9fprmWVcaCyR4F6DXro2rXLVcu72fIXzEMX75Axp/SjDofXTWLqaJjQxBgGlrdhMJDMz/Pm4Cpd +4koBiPa8zGsJvdtJCuJ3H2fw2zfMBys7jszWnU6vNLYA/NqraFX7Pm6gsn3Xbevy+fNLuAfd3vN VT4Z0/jLh/k+Gc0vu8qnbUCK61hTUsLez7WH7PCi5XuvP4sy9dZ70/ym/mgEomPUszhsHGpIqbDl nsIcWDWWELTqUddwjC2A+ZtF0MU4JBbLGmDN1cLdea6j7KCyrjZ+kxwZM3zU2Byepm7hZ2Pv+Wx6 9Pxs8j/9s/4m2/kvf/n3f/1PmlML0GCwILpmipEuWrmc+Vat1BDbKIgloaZbQJJQThCPb5KQezzg plUds8BOnazEflYkvInYV7kPuF5R4tPcpdZVzaM8U5UTpQYWgebQt5E8pzX6fN6sEUzRC5WkWvM8 Q19C1lOkY+r0r5IPw55hr1rC06vGvfdStYhzaFpz7IrXsMZOa/JLZiMp1dEc9tvuHNFQ3mrSRdhL TJ6+Zp8tKrlITbomv/H38hdTuK5wLaHEZy2B7cZmKtH0KlxfktCSfKtT1Ihos0hQHHdIRT6kF5K8 rckV4U1o/RNd6hrd/UJ8SkW3RdgjyUGURGc9r46urr0hTVr9LovXkvD30dyhC5nMv6tncgdo0Ffi M1CgBMScHKJ1vrYDCdBp8jYnpY2BdTGJLXfH2foYoNzWhM6wugayf/lRhKrSvitt1JErVzYHjpCF TBY/6SD29zqImhd0zAgrz+jq97JESGFviLqbwtMRxWWPniYFj5Sjo1Rw1Wp6GlWM954La++8OxhJ JyKE6WV7BiMMpjXSOkwLrtIaYIBo2ElPz4BKOmvZ4+88+ngS+D4txUWnZHvysSSPYSefV0AtHZn0 qZ6ZyNknt+3NpPo2IwectC1KC5MMzmN0h7dNziMi5dM29+QzWY7VfCFGUpC+S9a7Mt7ELk+/mtHB fPrZ3eG8gSiDtGlyqzkbfjwiwyUWaCANIKOuBtQWSEnO1nNmfi/vBp5rxwSq9HQ/mKpejB4D6Tj6 jprVJa3VZaYA4pLdlg79of54mEmmzInxC7S2gxsWmpnW945y7QndM8XqxcwhKq4K3y677mc/L6ze WJ4uKBMK9WkoojhQEKNacWD1Pdgk2zYSHJY7igMFGtqlxXJl/tAucWCcUtFh4phL2Kmz6sBptXOI JLS1rI9nNXXZqqJTibNr7ALy6WohVFMCpnwquYnDlqEBASSIF1mSzjSGfsTikMCvryciv0F9PXm9 Hrb84lN9P13bgaBaQ+lquTNFvbWg7e48xz0y4FEqGtTVOEyM5OoT3cp2VCh4KIvkynb+Pwk930fP +bpN37lBxm6RJYPM5HM0De0OwS3Zo8ZgMCUCO8tz8qjV4fRa81AB02t7PKsRytgFTrvuW0sRSk+J rMfzdVPy9xjiIgNKvIcYFpWlsyKBCwe/y2w7Cyyui6wuNcuqJRSPVIl2Hz9vW/3UN+zWNxxkJpJL 9Ljzr9C2obwgTh6lQRuJozWM5PDr3DkcSMNAP1NdeQ5zr0gu8zatejoitilUr74u8YL7UKDwuOZ7 lQP1dQ0NVuuQzRSnOpi/86SUA2pRKRKE9X5YKJ1OEe7OU0I9kJViT6a3m2pmjsROo8/ZjxNQc+z9 rJYboRp9jOySx6/vZ0N1qb6fp+VGeeLJI098nGlH903fz+pSsezAKTFU71sC8dTu29OlIt+nxehy DpdDA0qbGk/r04InYu+aFnkUMtD3k9F9KyU/fSpqapM95gf76Cie9tB+9ByY6wMtfPTdvdiwTrAF YstJCwoYa9enOpimbif4NAoF7WlRsVTUZ5V9lXYAFrI9naerQ91iu0drgRLTz7oM/7Xum340poz+ iYvauzqBIaIvoyC9tkXIfmySltkw4VW1mTMF5ARlc92FBGy5z+ny5RbP8n/dNNuQ9XvT/q4N2f0E TVGDt6eJSODAKePoKvsNO/AlP30qxm9rozlURa5JC4U/nic368Fr8tzZbF5B0WHjQLbaUQ++y3Tv q4XZYbstTPcGZiT2fJ7GDrlutbicKYxzh2YjRqVcmP27wYE+H1woPI0q7hzrcQPz1icEC22bkUSt Tr9uiP2ePcctd0VSqJrwrGk225bPc5Dn7uNccqGBXKz2gXKlNCr2bXL4Pmj78vC3bwN0QKpR9ozX wngGfWSH85FDsoDplcH00z/8sm7G2zBdkHhbHOXpV/9uEtybIPO+tCoFZgqlryo2j59n3COi4aLl 1KMwIcdch8ePcxezsgA529Kvr7Uxyd0yPBqqXUVLN5wTrOY7tyvvHkl7W4sHWBqxveXJm6DH4TnB 97UNvkwWv9tAikCaE6zJL1nCjjFlj+02LRASiTxrkkDI716RepxNEBgorD2THsao9Glro2Bwokha SlntUCrlGM0Lz915zr4duF3dV7taGKMyF5eh9KwXAje9b2ucwNDNa/v9ashUTfHNlrEb81SLIQbm LvDy80lI4Uifz2q3sULB9n09EpK1TMD9nL7aodSy/CN7JCTnfndMbCmrB8/gzSvBWlIBM4XcrFCw dig7jk9JVJGxgeVy/bOXxRJlLmRO26FX6Q3x9hQOVruNufuayKtDONBo2jBvr6/2LvNYHG147FBp NBUkZqBwsNq7DK6dRlPZasICiNMDsxYqks55R2++n207Eng/ycyXJVMJ+0/Ml9/rIEo9GtJIH7Es pQmy/J+lNbb8/3296l/CtoQ4VIptT9uA0XRM2sTf21Fsi3gTs6+eKLP6jm14HM9rqoM4ooptdfVE Wexx2uPtpSLOnskFTsMReyS4VChUXu/d6UgImLNXF2ePOcjGKs1h201LhQszJ/rT2WHn8Xnfxlmg gYq+n9XZYfjmlMO77WlHeNDMcCT1yFZLPwmm/UWFvXFg0bPxtHUIA8npZbtqbEibUsHgabsxnkEd zSG4WRMR75bWp03FGGK1e+SBpCE7LkxTX8GHiQY2Ex13d56cxgUKuZbqo+hILJidDhgVDipogxgc PG0qStNxCQf6fGAdp8/naVNR6d3oUdz1kDJA282+z9M3oDpuLr9PClsE1j0tTQ58Yp7S0ZqIHifA NZ5AENWiz9OmoqywURxet3FeJ1rO1ufztHUYHcSn1LNGn4KUDUKUtKIPm5JUvZL+zqNwHbHMyXhK bTY09fl9ctouANf6Z/9IvJIZfQjZ48z0qvsJZtqyDPAicx0xkSCmT/cyGjQsGdaeRghb/m3iMdkZ sdzbH9lUMaQpBhAYJVl68XjbyrYXEEs1vlqTN9FKzpIgdNuSGR2/RhOtKSEKr0bS1RRlDlEfJXsU njh735FHoenbT6TOhG5QR/Wo7TjOIwaYGSyo7tRD0ufARxPrCwoBjLD6IGRH7kNGTh7BoJcCHJU0 kj7EV8ZLTtWj5cg4T6g7oddttUEYHDjV21N461ibv602FfVQybG7TER7BXBgz2f1DTL1w6SLjO8+ HxEAB/p8VluHoZtTj3lF6wONTPX5rDZIY35xPtsGcmswBXrpufzIiVEnPnLAkkdd3pPhVSA48dZ8 Wzy3xhxuaowOgU2BIIC9OAOC1aCiNY9PGu8m1wVpvH1pPlPekUfmxDhSAu2plvrqttEg6tP3blw5 oCCqqLa6U+ztONVLH0dEvmr6eVb3g4J0EY+96quKYF5LW81Qst4ziSIOz3P264YmpSOsZhvbKnWq FTbGle4/tj+K0XRq5obS0aNw4LhkQ/2COBa29cbmpD4ztixQqFKxIC8soPVB8Dj2Pe5+wfbHCE/7 g32elDwmoCXkn+UM/kscqP/oeEIqQ4Ms+TLt++gfv4LSoeElv/Y02nCnYLqAO7xpY5znTxPSn1Ct G6pR+TaXqFb7ff6Eav+lDOT3mv0dykAK1QUNSRWqn9Yhm8n73LXQJ3KCYlSherXaGnErztI8VnD5 aAl1QkPMc3WkUeuEWlkn9FUlnZF2UMFp6IlPZxfPsEsdtnPq7vsMhbOM0rYRDOCoyJ5LgLMUFNH1 FAuevu7v5UKU047UTRQLnr7h7+VXfGRBXtL2dp62LkwOYo8lMjnhN5UDSx4/y6X/9HaSvR3qh1uG QyC4aha8IttX65BpNmkS4TGOKhZsoL42LHia1IzMMqJHAdGcjg2QjVoaT7eN5qLVY8mjcbQCdRPD gtXZ5TJULs8z+pYSjKPZsIAS9WpwCNRX23YkPdNlKoQNtlzu0R5KcSBjJZAVRDvDNbc5QT3At1Ec eNq6rNzxaQGxbSPihkFfDQO2Kq+/zGO9c+QcQefQcG21dZnFjdOJ1bjijYVNVtzpVMqA8MBefz6t gYmiPp+nE8oY7z17HPKUawyQUkuexA+tsdmiPE9y3qyux7h6Axm1jXs1ilK3HpfVaM0xgMijDz39 GKmz0XWTNhxyctJ578hrJERTrE6jMYUwKZ0phL2qAVLlAo64GnjG2vPt7On4VDzThDqA+s0Cz5qJ UG8on3uxe4sXVN1dNpiZE5B9LiNoIIWKgXqg1adm903To+ww8uQ0BKz6tmndZYGUWha7fD5jnO0C 9ZsRdmumxag43RSRjvWNxuKD9t9LY0KT6gaoOYptaTXdiW9XiZocOTyPYkHG+kYrC+30+4Tic225 n2DPV7Fg9alZiZ2tMe/vODKuC4wRLNVZkiaMEypVGD383VQnHNCxuIyntUu9rlzS3c8Rd5C6GRys OQL17vIpHppTvAEcaEa9WrusxHZKPJStdaRoMmKbilotML+EkFn/8NXnc58VRB+tscOssSMT1+uj Oey4jase2DtlZW69s6miz8Ratn1HxNBslPcgmanRiZlo+7ttmusg4zsDt2cwwvWnPAbTrVVBlPdq e6RZP8KXxQJTfW2YYDrbIPIoUq/mO63hfNoOKRRU7M8xntkINY102axupt4GE7eyyEasZ+A2cct4 XaSMZzhCzlPMKtzf99HErSDdUMW2ZzhCezouh1cKBxX03BQO1jCBlHEtjOiSwm9yZyCSphCeWQ+j g4lLWWQJW0b25V1my7oWwt+14WPzaCdd84COMDU8LWsmp+VzpUfhICDpUKMdLzggAi0pdI+FT9bk Da35TtNIgwOi3jZq9bi1PNo+TtgStY0e7khYukN627jKjuhtim1P+53loRpLHfYMjlyQhL2+HXla oozq6nPcc6UakDaYYtvTsmbzhFQ8KrTktN9AWk+x4GmJsiLb53H0+VQ0LdXn83SsGRyIZIfT7HOE DVfZ8rQQ2XXz+Xw0IgZYmManhUgS62wKSP6Oo9ctoAGWXrfVoxpkolDE5XLsdZ8BDLMl90XTicwt rqfh0Kf0qnUD8x4D67WLzT6P077BIfonDRNRWT035t7ltK+TQtvQuu+0GzE0oKrVLluI48qww6to sNpUzH7oI+XqMPhcNUREBdHns9o61E6JU6leDqYFj+dltXWoe5dP1RnN3TJQSdfn87R1WGrtE930 +RQkCpTCSg464/M7RbfrqojzugwgpA1CE40ht+GQPHHVktE8rtS4ujrs8zhlUmkwbVi8TVZXh5l3 SRaPqbUxQZGouMSnq/N7Ed3KVqFNtl63VWgPZmIu1aNCw9nvGy9c5NUI4X5KLtEt17sibph5Wiy0 ZuQWp9Fn3NIRpT/Zkiz3MPfZRdzvAju8cXV1WN3j9K7JliOq44KYplYchfg/xNADa8C/yp2QeGBd oLy6Oswb6pP576tY3W7kZ2FYsLpug3YRXe4ujnFdAU0Ukq33UAvzFIPDKq7dqaO0Ooh5KenjoZt+ PlmV47CdWIBtabUQWVHqVGxC84INi03kp6fD5BxNFcnfebYzIw9my9uenhs8j1YPkhIJpfIqtl0H knw35FrYxrggPjvw4wgVNHX0+ayeG6niUm3JY1p9l4jW/WIX8x5KtbCVmJq6R0mDQ78D9LYZ+elR UclAShN91zbyiHheGp8eIvXn0F/p7zyyHxlZqykcPD1e0rPOw2VZqnAQIac/rR4iqbI/ZARx+Hk0 mma0EqPP52nqMHcb29f0d55t33dkPlRqeppuxPVbM1YmRfWyrEFETNEU0tPjZT1rnzIN6bwraMFn 82COCtkMrHNndc+bdWmJ4fwp+PxV37X+GBEm1RIkjIBhIL2ZtOUWKq4RVi+U1qM+e6F1Sz97sf9V ENXvd/k79FC3/UrIH1uR7envkp6OzX4dfqOczoD7oenph7L+u8+69NAMDfqxj/L0q5mXUukekbr0 siGbAUlPS5RAdSvN4y7mdW+ozJZcF1OHdRB7DB4p8NuZM0GDtfrLX4/PacI1BFH6FQ1mXj3C78U8 Kl3w6q88TTeSVrtd8MknEAUxcFtNN+rj5zMN3U5BPn72fGbTTeh183meZO0mHEzrej6syeuz6Xal eCJWf5e5al4LET1K08nD34aPAnKErHF5moisivPp03H1gQyYY7ceokIc8/vWVNVjj0rRrYFxqaHb 6iFSxyuf4zgtFU7MQ5y5m6IbPI+mDuZBhM/zfbvZv+JycwheUli56GBqiFN5wt/30ftGetZlNd2Y hZdTtNZoOgC66X2b2Y7eN0ZE9Cm+Oa7eQbaj921lbyP8btSjA+3LavSZuXVlyU5JzWOPt467bn/s 7qTwY0R8ktQafTjfp2D9/9TeOUo9wBtSTKirfUCsvGLUctthAaRvKCEKkr6htN4Qo7v5XJQrfaBG vL6hut4QSRFyDR7r01vuA5lijigzg0tfVm/5RtLBV9VbtmNHlBCLP3nFH4bXPvdiziGE7lYX3Y14 RcVYkkclp3G1E/lKKxY8zZ3fy++m9A6l+mUS4VNl6Y5TLNAfPmx/nGLlH4PpIWatFEhikN/kGsRj gDqh1GnCzDqiHzXiIsF8yt6CtLrFlPsfchy/3+TvmWAdO2L0G0w/TTfG4pXmEQZ6PCNquoVs0gZx FGaO61SVSsMOWfCpT5P39zKZ17DTMMtanqYos1ayebC/85jlMlSlmgsxGnYYMvgMO9spgpiICgdP l4o9H59mv/p8yLJ5fbqI+Lrl0prHikefT8JEXnm6blQ1rHikuuV6DEAN0+eT1vMh0aeM4bHpVvOO eMm2bG67CkJ5lT7FeLczXYA+ocfJTw+R8V5b9NikGjGdSOlkxL7EkvG2bExSB5kpxPCqLpVUTBSt T8+a+ZP5nJFoMMWKr/npiTIt61o85qLj2gcaaKeQn5Y11XHqySW/JXU0YVQ4SAsOmNSJ/lqHaJ22 rSO7tTqlNJIEpmY9eiDExJefT9uhEk1+2qFMl8rn89nyuBHNekQzjTK0xslBDU0S+TzvlnIl7TAX bc80garuuURrhbeMJozTc83gjQx+LHvzWJrq77sje78yG6J6IDxNiFopNLIy+ya9ZWt7RdGnFrHO G+2/fzJN+L6v82Ut+Gybogjanu4uS3R8cuHHtV2ozNY/+tV8x5T4D+uCsLv2ahl39QCgQHq3uqcG JsApklgX5E2kbqHCp6ORJ63IgyPpKLkzJY3+auRpqKtjkWfNrqivrM/no4nbiWR16pSh0R864cgT c03Zoda4Jm4BqBs0KU8TkeShThM3RbeB2gaKbqvHGxn1KEhzWPccpQTQpLLns3rw1L3UKzUsCV5n Lk9bB9+3rDjucY2k9TOjmY/CdV5wjc9TeuyR3LdXNxh73QEPROHgaYr+XktLqcMevKF1WmiNn48e h84U3kRrhTfB2/MrGR3MoyxK96iQeo6KurwGb2tGwgwynTr8bWc88bp5edpU5P1oFPaY7YxrXAiu U1jpwYhkSOLUYLb0/YLM17K6vKz2cSqfnrZdUPSpU/vI4I0Qw1rujCT6JrwpHKAur8HBGiowA1On RGuFg462GBUOFhGRtamsSeLw+UjYbgQHPcdltEQMWWNq0WMXXuGtI7hWeHvaiL+X7l7pG5awLasL z4ofp/CmxU8F103hoK+u9W9mrqJwgLrwBgeL8EbCTx3iktOv4aeDGbCFnzXESsR3rYXeiEL3q1uZ 9YDwpnDwtEbZFItzLd+F645sMs1sZMJ1JVOfqMV4Jb3El9MD1DwwPHh6ieT7xNo9fp+8yQUZSGVN FkhyHWOKHuGtb7Gh1ugPqvdKnX8/v2Wb3my5/3aMmPQ/qNZY+uQ8/+cv//of/3Z9/K+//OV//73R dCsnmtHrTdO/9C4kGeXn+kbGzpenWFpo44lpeRqjjL3Xus+d2YIqbcOCpzHKxnKT5+PuPKXfO7hs Terqw5NMNJqnlENou1NuKJTWqSOYJqGarC9mj1PG7QxI8ERTt7oaOzi17k0zAzYnGW9i9SkZrGDJ DzaZJ0sxMcbP29W/hNVfBbfSrUMAwe1pi7L1Rake6SBa+Oy4D9KftijTBzGLYH/nKf3ERkt1TRVY Xu3UDlzBAOmDGBg8bR34itzqaZQtIzUajS1tJTpfXf6N471NuXaeERGtQ5aw5PrZorlPuf7U046o iHXqCBq64qZOCTlEUmS/uZRZNJ1Eewop1GekwJjJKWWHtl6aiKIer2H107NmI1OfI5Kt7RAMamuL u0d6bp9w976vZ/D1qme7QJrTpnWHBR7ix1rEZRzN9dwwu2UF0kHIR/rie3PIGt+OGwkbWCBdK39s vJhz8ViUln4MUPW06aVg140EUq0ePOoebV0TNAgFY0EBaxl4hIIiewEiDYrTYw0TqBmrT2V7rbAj ml1pXrCoLUKa76Hk5DCO7lUCIoqGxdzLQ1hDx2vNkzfUPVSsXsMEwuk3NGgOix4NpR3OFuvTrCaz hFAlO3T4ywrGuH841iyBubF+6LtzGErPO5Jm9Zg1HNOe+ASrv08J7esCTjdSntC8oD3dNnwaLRCa x36OYsGNJiOKBav5TmiIrUevg98LCWzVKf9ssYewXlvOyaHSSa6jQTG3tprvLK0uuXnUC9v7fiK9 sLBYexpKWUPno7O576vPJ5cCWjqG1WvWw6yMhxSPqZu+asH6ZyuWjkS78CE5HI7ccu2IBzJinztL nfCOYhulEzh4dyfmLnDjr612NcvcbEbiEK01mkISvEbTh3aEK4USq63/uDtP6TWg6JPCgutBWK/2 fIbD71Ny3sAKlsHbmvZQtyWfavB3kgOxXuuUT7e9PgIHIQW2E/PyaD5A7462mohsh8Sp+uZ15B2Q xrutmkuO3HKtupzFHRccjyi4PS1E3DZI+uE8nqee+4VLhfa0eAkYxF485m65XBV8HwO3NR6h/qU+ wa10za4hGKwWL0vdasoej6PvR5AGZ53WA4bVOJa2qr+QtEHeHGUrHFTQ5VU46Gu/FLfgFfV6YBTR N1PRem4XdsVrTxeRaVYmq4rc3beSBWm+6mMPTxeednldUkFyhF34Nn2JDA5IKuoUDrbj3JGzij6f p/FGurwtuRzIbakgXZ1Yc/whXdg62ScM3u9rU315gNWuiso4hYKnicismbXO9gkF0GpaoeDpwP9e JlhZ/5h/6sDX3kq2QemX6e8KHl86xqRUlhzS+OQ8nP7+dyh1l34gf68m/emPMnFEn3sxWqBWtIdV p7eKJT345o08FLb9aewoaqP+qKH24iMyTRqnFWpuMaJ+oiLd0x9l/etoC/b+zlOuAylBK9I9/Wsq xhk8nkfhQGDS05/+KJXmrX++vNsvPZ9QcNKz+qOk32v2Kx5zUs2UExIJaTkZvLVCmC6jyGC7F2/C m36ggbyJ6rS/sdiH4S1rYBzk+bzLgK0F1dwp9Kd/TZ1JQneZyKUBWlYGb/Z+aqDmuT5FXKQJnC+E bP1rY5CT71N6Z5KCb+766O9bQDiVMolvMbP+tYmLOiRTSDo7ICiXKRkUR8iMx5e7R82G7TjQ9Mei z2pgk8/z0aNkh58n12vDyuMrOxhk88+krcUlusULDIMN3fpCNyZg6RPdtPiJkNQ7XX1mJYkHJiIt ONQaTnvLJJquDqlQnmUuLqeN5wA8WE2u14CBPZ9agkeJnVxu5BqjzyeG9XyYgKVPWu92lg3N50od q0PKOr5OvY1LTxfWBVj3bZD1MoXrVB0+n1w3pHmiz2c15BkalNJdcl1yFLDZbM8nredDBRJ9Nkmv XkB2kKY+YrApKvk8kRJ73ySO2rwRJW91enxZMGUeX6NFct3eLE0V3QpikSu6PZ1Eyj7wim4di90v OGDumTFEE0Txd56sBQ7sJJoAn8EBW24e0SNTOR3jRtFnpBgWcxSfR8HNqnB370d/3wC4VVpq91Vq YzhIqebhMPrkLXUgdNBkrLkP8551agB6azIKGqO1WaWQuq2XY+l+KX/+PuOvgHW+sePfePrWVA7N pc15rveOlQHWdRtUcGvU4vE85UZ+swbWT1+UBdPkcq4g+oCwZ1lbY9PC1puLML26V7Xu84X6oopu a4xFr9uc0Lv7PKXdDW+VjKfxRlcAe3WI1iUH1Oe15/M03qhqkMvOwSgj/MQ6mBbubeh5tPChPUTO envz5dxyVeh6keKz8IORQIOsFIefZjt2REWKpYXFGmXUKqfComXECCZYimxrY4Eigf7XHCJb3VK6 /q+X06Prl/N3kKpyPW9cm46ncc2ovW243KjX5BrEH8Xr9HR6GbXXZ7VQzm3/SWxnpDQH9Ln9aNxe 8s1t+r/nzm3pAsMfBYZnuMAqBp/2PpfciHkQY1kKvcw9hn+mL1Ivv5Pfm86tX7gXMq2kOmHxZRFh 6v3v0lz0BDgffSYLTD5oNJc0F7lP5FWk+Pa04n8vvrJWcw0JCPVsRIpUNYvGSZxoZHI4CB5jq6j+ 0STu6V0T2o7Zuzost0u/MhiVKFY/kyzyfHJ3qQ5f4pl/2goe+l1Klh9FK6CUM9V8pPH0RSl1fSLp vxP9S4y/QPQv4ftS0a/L2+fYft40/eu+goEZG/l+GJHtG27W37Wx8G9/+Q/9n/uff/kf//4rGwv1 hs5YGnyewQ8B6xiKS8q1/mEhdTT9j5/BDzNw9xl8mv740BmrhdW7ZjQXp7bA1ttBvcQcnkkJyw0C lYd/WdEloMRac9G6clHSG21VGOX61Q5C1JQF5G59LZTESgqFTwSeXu1ctwC3tlMMz6SEag679MlT /EpgzmjotiYl1CfPp4ZyG/sBt9BbWJxexkKSkT2S+O6SoCl9z7axYKUCUz3o5sbt7jx5S0iAS9F6 TX7y7xV8sn4caH8R13kGO4/IcEmBlTshny/9PGvyw2xanSY7+nygpLpW2ss2s7HzxBgd+rClO1Uo 293iGpcwzqhTX8Z0bheC65HSYiExH8MxJb3dfZ/SWwULjQpva/zDNmSKJI/7mVoqRrT/p9EnrehD vLGcNqpKOwtq9Cpcr8EP+z4f2WejSs4DDBUUjGUNflg/QULyyLnO4fp53/Sv/Z3246sSynn8/3pj 1ePo/70tUhXy2zd2q85xHlAgrcW1sEBIfDknus34bls0nkiLIoc1wiLigh89Ro/Ug3Tugj6PjRtX 7CFUilCqS723GjoBgzUlwd5YbnO3dG0RLdNr8Fm5WyX6gkMUz/F55E2qy107ZPi3uKYkjPXmdJ1x 3FtCyYH+4a8pIyH1erVw11rhQLWc1gp91QokCtXWg8Pz5C0moH2icL2mWERf0KugWJEL9a0N3lYf njkWOd0+lxoDKeWePjzTHvZZyo17HKQzuuY+5L59pFo9dt70vkUgVWX37emMsu+jOanDdEe/T4Pa 3TGuzjXzKXEafhTeOlo3zfHpJJLStIhLOcurHsjYI8Vi+3KaG1Sm/9gTy97eLLXP0Tckn1paejpV VO3aJVzrgz8JHDyd0d+ME38PrPQW49O5ZoTE1KvH76PFAjLJyvHpvJFGolO/yVtOZEpvxemiJNKx dq0e/SaLnBXPGfPTqWIUZZ/FqYRxISFLLU4Xha8Rf9M4qHr3q+Hn3pG4htTZO4iZSrl8pOjw81xl G0j7JE7lLY2mZO4jEoQp9r7ZOxh3PyCpKsancc2eTyzB4fcpIydk+5Xj00ok6FZa98g6KHIELDOa n9bbb0ZQPveBBK81+iwSEhlrK1IMRkJ6Mxm9xnETOEgLDsj+eZ+66+7Os+09Y5ZLelguDA6kFIek t2ICqDB5e1pVzOE0DY/7S7nqnYKtqvy0qihl1GepfVzxp8/zVwJ5jUYgb4xAnomtR0rvEciPljva lBPbXAqFTn/JUUr8PseVrx5lH22AjHrk8aPnSPM1dpQo7/kraHGGnn/Kvf/orTA/4G6/wF+udhdJ qPPR7ThWGnTKOQrZ4Q6wJgMoeFoy0FcywEzlahGHyc1xl4bmVqXJ05liyZpPEfU87gM4xyzNcQ2e RKPb3Og9bpYWOSNeZs6r784sgZ0ykk+5AtSEL9Gkj6hqpUt7cLGlCTgjHYuOTPZ+c6uJZTZvbsq2 U5BHnmHBQ9FhmZrP7ZFx9wo9DGN6+gQU26JHv+YypAHCnmLbGvKQjE0D6fDo3l5KiIAeati2hghM cdzpEOHaNYQAQXixtodV1XgGp/8l2/txhwaKbgJSakO3RXft7Dw+0a0n25iF6LYYR3Tbwie6FYUv yGhZ4FYLS0RH8bh7dY07oDZBLCbTIGI0Akw4sj6bv/PsprIF0C3Edd3oMozTtkfJ947cwXMoa2bF HGedonU+xg0oBlJnYh0z0xT9hCz+fe2PX5n4hohzgzVDKExguLq0xttGrdAAtMnig7Ey2xZLPd62 cgRQZtvrWTMRVvg4nYlcY0ciQYbWi6DTmRl9rh6D6V1MfQUmO4te3Unpk2145/A8KUERGq2Hlp82 szvPtXlcLS0jHcBaUuFtzUSIWUwMPXjUg093LKTSXiMrxhb/KFkcJju5nRcu5cqa8TC9fqeV9jXO jHrwsYbFmCCOzWmM0ghcv9mFL0NOMCJtWZ6uKPk8Jbu0Xmt7hV1Ea2Wv58PY/DV51LcvcuxYobs8 Xd7fi04poV8o+mg0XUMf4vwZawns+bwq6Xb3iPiHKcrD5mc6J8FlNNVioWE4eBqJ5LrVMDwuW+Rr P1FyXWKyiSlL3aQKo39830zhl+g5aBPTYs+i53Ri3lFbqIRM+Wbs0dKnkMbB0+Zl9Byf4DY0xiM6 mAafp49IgqnTNfPNCBIArFuXH9YGYYpun4zkvu84Xx3Jjbth746Y114Pmf8qGHSPdbbWPRE8HkXq p8lL3s4nFsAvJwYdrfn1EtbEdJC6Z4h0jwpBuR04catPU5Rszdfs8rpdW0CJtcWevGIPOU/sw+Pa 4naPG7cR89NGZIm1z7pU4a0iNpXC29pTYqS9T6xvXp5oJ8jWkadrTQb0Vb+dQ3gb6Tx/Egz7KzU0 hm51Qm0EDYxZzfYsXu1S7TVDF7luBueN9ahKKS63YO4deUpKLct+nkBBar15DKVFrgPIplvoeSYK jKwzqsuJzyYwNVCoflqiv1mZcDcihpgX+YjM572eJ28B6TcpCjwdeHLdav0HlAm/VJXuuGNdV8ea Cj/7HMjdxhTFmfVi6wwSe7JeRYdwcB25AO7esLpHsslYYhZ8oULJ784Tto5um+bVi9zCWP2lVI8N 67ZfAbHgNd95GvB0Idulx9K4rorlQPJSbyL0iUmgcJi5aV3aoBzI6oJUYqnyUaR5ZIpuLewolrYR Z4uK6fC6bFGVXCtovltcWcMetq3kNTE4akP+cSPJUq0l66SfSTe9KWp/jXtHqs+K1YvaMshwMVaD CXff52ijQHvmVharnw2vnLZExxU6EoFXrF7DOMIF0VQneqTqlJEaVEleLZ1afzNWfy47aOkYvK1x DxXl9glv/awFwNvcLdfYQ0jwllc3h+uLmrgVXGWXNbxi8xGn+2TjvBIaXpnSxwID9n26+Ri6O881 diQBr8EnLuIR4e2J5XQOZV7zOKG3eV5NkMoMO5z2q3PZNtARVXBra97DWONOZR3l6AHlbm20lVh/ 2bj01dlvLcjeQrHgGY4wI+PicjB/lypg9qv/X+auLBuOfPJx+msfR4FgR1bgeRXYtbKkbVZ37r5N yblgPn9b3XcqX+0TCPbR0HLcKNH0MxozYqQ3LY33trL108BmwTKJapUmoHww8m49em5IAkBTgsUH Y53dEV0qNGg9GrAWalmDHjbDdlogHGkglyi9bwYFJpMBzxO1HqKLmN/3en5lcFVulBNoGH0GV2wQ 16PHglS2Av2l2/KXbtQTU8ZgHJA38SCPKwBpcY2kaxBHXIjMtac5/Dy5nAFs9lgkfQZxbHXE5yih tzPh3YS6RiNs7iuaOjj8PndKUJm/jikDIJGt9jTpLjk6d9kKrhKeUQ8j6SSXfuZju+P9R86RlkKa IgyS6+jLkeZwj0x/KCFYnVcshQWp6EELkdpMrxrkjnqD9lTL5ZnDMVnxPly6jmTZkCy/YvUzumJ0 yhE9juWlnifUnKhxjuVLoN1Q6l/85nXbNoF7Vxp71qiHjbGdGspK2zdYypWpvNsoXdzp99HYk1Fu YL4WK/awXQtDDH/fR1PRCrog+sM+oysi+66ByWMlV3LKgENl8PaMrn4vCmKPBVou9hKmLH9lpj2i AZfA9ZsaJ9foBxgmGFznBdfkPPqyksNh3NE79PtVuH6Gcaz08Xnfxp1v1Akx6sSEN0Y7Unjz+H3M LRvYWii8PcMrXCm0EPXT+TuOVtpIU0fhrT/DK+6i4rFnfZZ7gEpOSvsxcmts2MN71t+nTvdlJe7R Kqp7FAnWnhIbXXkdy995oPPoi1qjOEJq+dCX49FPSeu4DKQdFQme6RWR5C8tdo/HyenGY+z+TK/Y 7ojPwFP3LSCKW1vO7I3Y38XRi9lOo/N8o5b9ryQ68YIOHTX2lejQxNp6df6+T6loOSEVsxrIrYYv qz7H91wTrmPARaUW5g6zRLZ45bQhqrEH7v9r7HnmcaTqqa14bOpo7MmYElbX/KqyaXb2yeUfLYNY qrFnzXsa61GZmZ/D48jd0Iq5xp417/nNZHiv/UDzK6lt6YgSNrL+OUh1eJyabyjsWFJZUM2mixyq 36OCXKM3lOdoFhpWHMVQnUOKQt7OmxLW25ZOLD3Tntkiq+B8Gt+NW6BvpH6gNYtj9FCnWNBTvFBq kIy8G2Ww/X/+eeKb5N20nRlsJlims0a/ZFMppmxCFO4+T73GDqA69viwXb+Mbd/YDv06ofJCetwt r15bJZ6eUf+bHku4XM4dxR1NC9ZoEbOo3Cq11HwlpHpWUltx9MvtqRfvWuvHhYxUNO48c0XaL3Bp L69xBxr3WMN3xR3G3k3Box17OW5I2QtTRyeOFhjnqNCS9F3aRBlgjq3YtuaKjI88WnIp1aLwRbBt zRWJmL3XdpvmOWiD2fKCvPICpgwkKTmssPMV0QamYvVYWE0aIC63YK6RN7y+nCZdvLCdHj1pc5i0 7Wc9UdKmsWcNSdlQ0e1oRKCtUortGZJS/m7wuFFaww1tlVrui7LH1rE/iaUvU/YGHPqu7mFlagbm H+Ew1clFwQ2228Ya+jIVN6d5tciFpKvtuvV13ZgCov4zh5QwLROQMn8qElfs+fKSn7xXJ+x73TGh pa0xNh37+sTqLe87wGqLpYtwxDoGvfpkgIwbOS4qtq0xdmNQ3YrHsueOZwd8MMtD68pDSeKW6/C4 OrIdNYLQY1i9xvJMWdwpfVdDP1QTLvKMfX8nZfG2nxlb9rQ1JiVjxdaTS/3QfLcBsGBYFio5EvpU N1YpgoJk9pkvDrFlQ7bfs7FuSE2W/PSYnVEP45uTnjIyYoAoUj9DX4wEZkPfHFbY21EqCqSKbM/Q 9/fS4a5lapcBZFtT0siIrh6RbRv3DhZKFdn6mirSKZzPj1NGucBla7k9kxF816Kx9RxmBddxbkjv TLOcaeUX2WQktxgdNgwUCyLSM1AseCY9v9eWxVbvghZK9fms4QgbJnyypPRugyrBJbIU+8PdZaOr aFQxd+fRoqdC68j2DBPYdQvZY952jYKum9WkixuaCBz0qJmqv/NseyiIrqfv54fZiowvFwkvckPT dkK/kRbi4oaSbpsRkhIJpa8a342+4YZOf5rvmFidOue6vnmefm6JpDpPgwpjW+n66Rw2dNJ2ZTBZ tPu2GDqkY5CsgiC5zpvf57j7QMT3HMPqVtPubsZl6cvf566to9wglmFz+cDm8hTcYv0+QtgvTBZv bA4li03JlECyhiyHkXS7B6S3KRg8HR2SGTjtVpfR0ORXE52nZ8AszEf1qPN8mJIw6hnEsLqhTEgn lu7RtFjzarg3YsvwK6/+vRLRtNcbeSbY+uuKPWRJqYbG2gZvxp7r3m6wRCZtXjeNpEwXqIrHlts1 agFtA0PrxQMhtqv6siKTQXzz82geis6jaD2eLhX7Pj7LbLkSUhBdKpWK1p20EGspHptu5+gZSLUY Wq8OL5OekZaiw8z6LvuBtAxijStz+zJ/N77X4U17u6GScIhrUEosIBSqB+sZvIkFe4wRz+LG03KD 54lazya2mPDmefI4NsCvXuvLhgWk6qm5uOxYj7IBOrKFnkWbIBuyMffWHVal52gXCqWKbatjTSlu PteU9hRIx3qsrg5ZKS1BUnaY6uRxBrDmtxiI9nxIodArNSB62fougG35YVWp5MhOU8UKVnen0TJu Rxp7+ngW+Z2JHEnoHveXFcNuaMGcra1Di1JJ3eO6r1YJyFnNoHopIBIqfy9VBrlt7V2oHsADQm9b fBqIv5eQjubUO4BqhbbF2Ou/12wx1Tv81NMZGu97Gz/E8uqvL1++p9fUY7+QvlEoxjHQ+pmtyX+y EPcmC7n1E/ZyNCNYrVCyTer12dQt/iwyMe9Zj37vWf6nf9bfYjv/5S///q//SQpSKxLwnsWSse+s vduix9HINVoEcdQiz5pjE913K1eHw3Z1buHASejqvncSeJy6LCpOC5CaMJbOStsIV7wUPazD85TR Uc3T8njabaT57nStR19PBc1q0zhaszhCfY8hRo/K4klfz0+f56+JgXkssr7uZE34O4niNNKcieum /X/UXcmuHbly/JW7NWALTCbHz6lxZdhr/72TxXJDfh1xodNWm/kWPUFqSCWSkVNEpOF0J8YMRXN1 2HevMTdoTdnCpEwwMbbb1CDIP6aglho4vmm/kBxYGRdQ2WNwMIc9xNBxONMw3tHaYLpVkBzYG5oN 0U6GI9pcCnv0ynAd+4/4sZ3WWLG0bIyQQ7//XL0NXbkQBxCJLTDS7sqCJ6Zb/7FAGJ8y7DJIQ8rr p1jAEWTOMh/LCDiEc5hL98gBq2duyJzFAs5bizK30K/ikfdRtpy29qeA4/mq/ULEKZv28Ocw6hkL fiWO1pqwYWCakyuitZAmkRnvrnxLuV9ow4BBw5yMdJa72U91WCVUbe3nXVcxxuFdn6xQCEyk9E1f 5+83pvyFK6dbRhvMtcr0D6W7V/NYZOruiFq+YZsqN5k0HaJcHEuYXXas031dIFFoj0LBJc7RLDRU 6B7a8iMkK5Rm0DUFh8viUj0i3C3f52yELYeKzWuecO8gT3B8036pMk3IvXpE1DlgJIoYu63K7KhW RtQ7bCegHo0B42QlE3yLWel26bXyqy0jOyrD65cLwohuPvE69xP5bhoozDZ8/+fay140CCCNt+Ff LUkZSVQ7bcKvnM7fcirsjYY4KeNszGiQnT2ezqZa/wzZj9szU1t8Y3v2/+H1/CuTxrA1aBkmMqm8 DBIsT/BoQ9NyLlD01+TtYDN/x+c3Ab9npdeJFXUKRKY1hznK6nRhtkuIu7qiHbmWIeQ5ymIaxqCx EOb40pp7KyeqgKTowxxnu5W+cXRbt0Eh7i1jC/g4mePEDlGLASB5Oyst7Q3bIrTiFZlUXoIFlus0 j+YTd04NRdSWHxGW1XRMk6nZo9trqi0gDWMO7+AHh57YevXItB6bvOBupSZvL/ufS5OZwqPr/9Px RP2R6PbVr+Hsgr4l67pZ1qE9oKTAos6D0mwL0VfB/ImhGl72MbccJxwBhTgtgsjIREJNySEK3KGf cFOpyEs+wpP6WKvLPTeW4iBP4ZHizPE8kcoOhSBbsbbURiOdP+uv/qcpOkKOsICzuO75pila8Y5s mTuyCTFMxIodh1oYAwLkIWoRJ87+O2sZOI04BgUVuDcZFMRJ6CcRdGjJPOpke7zbzxwKixs56Y9n 16J05htYcywOcfpsMQL1iAXROoPop/YmK0sdA2m043eA9Dv7xTfNriIdj6wE6RhbQ6Vba/psu4of H85vnCl87FF5VpiuGaxNxS+bXSXpHpeUGqxFtHLEYG2OEQhMS+/dI6zdsgmSlNag0/iMFTo5dJcZ qKEXYr1KrI+xVsd+wl+qiZKqVqY5170hewatgy5uAMaorzVWdTj6vVM7gERWZg/UygBiLS6pCguk SxXmTQ5kbiJl+oQx43daWq8MpHdoB1p9lx6N7MA2jNWpVJcGvP22KgEZosb0Gjcx55lWisfHk2tH poEtj5TaSh6iUPjK9rAcnk/c24Y2RFnsmSaI7L61OD71b5b8/ZXcoB5AjDnez+xRMweAb4gtvw8N /orPXuugaThyt9kEpd/j01/86hH5i49CYVJaiMbcfrxFh4VC7kcFuXV9OiCj5079uF0u99RQDgJv ccIb4cOPOOvwut05K/TZSzpuW6J0eFrH5XW5Qe4nKkrtrr30HLYhu5a/f3HCX4CCmhu2z8hTxExM Aw3KKcF6ZegZQjIs9tO3zGb0KZ/e/H2siEJmLTG9i34ZS6eIx1T0LltCg570lD3N/pu5zySPkXSL SkwDdTZ3mSq7iMsqu55VgUPyeD6TTEmHIz6pOaluAs6nPpF0oDVd++0SDVTkhG7p+XFLt+qTFApW QgRy3Vai9dXuA81GpJTJnCIrySRoYoXPWu7ujrQjdt0etdJQBJPFI8mjp0EKJaHgYydEOWCknzNM X5flbBZE4Yg0xvycSyd2gV5R7Q55R84zFnVm7505NOQYPPrYX+1C/NYBA5NdQBYQlVijONQpjQNC S1Qsir79ApwVtFqDR8cJez8RLVGx91Pm+2Gsd6f2oVdE/cMcx9A3sdb7d3PFddh27JJRQp1beukS pCAtNbFezmIsENQ7NCyYQ2zSqxYriIpDOsue746WJtj5vAUpuW0aYnDYMOh3gM2pGMucJXwj9/U4 J839OBEhND+h1GCPQNtXas3h5xyy3SBly7E/0CafasyHdmsVtO2pV/B0euk/xs7bDzNQQ4jfpxz7 mJqT945FimnW1cQPSESLOrxmhgIVZTiGAnPFIlFVPHZ0DjOC2nMDhu+DONVTZpJLPrxeHELPHVSh I4TO8Q4pd1LtyiB6ZZdAt3yiTRYt6yMRqdSrlvdAV5YHJd1I/qa92GVrzIr/q3SPRBZDAkGza0OC t7am0x17WP6+R+03jHoFNaSHB2aB8mMb1LW16JbR5hSLPLMWJQ46qYXsUbHc7RdGpFC7b28tysDA Zy26pUMwabfMARxTvthNDQ4zg+vcKlby6KO3jIQhLiFKdbj9IdUdfU/N6a0P2LqEMExU3X3OYVEG UVmkzq1QNKumvY+4sK973QVhm2HBHI4ynb9TZ9c7NeSJLNPtbGjDSFZdU4kesaDJBkiuhm11jnfI +aRmaECE8SsT0S1aUQqruDx7OZiYY6jXqkfeVNx7wMu+tU2sxuAWQyhsoedSHlg4AwK38OyCkV6E 9EJ1fKy/3K1f1440I/Hh8A98Y/t9rb5wiAdb2HZEzpneRgPfmJtoSNXhikWVUFH8SQ9ttzWyTlrq mNT7ez5xPxuoswdczzEck/TEmj2GU3s+AfmY2PN5S1PG1ROXImyD6x2N4aw0jROumUg+ZrYEc2nT 7U4dltqzr1MrI4M53UHUr3NHViZ2397SlCTXTtPRfN6KwqndtzTvG07fVGMSUsqtJLfZ+aC1hON8 ZrnAlOUPEcbf+VxDCobxeo5K8cYeyT2WgEelstTJoMQC0+uoP1Qr4YJ9p8VeN7vq9x5xW3Rux+5M MmLFhEeJ0tmkgv0cInV6gjGJBXOb+fpqCzn8Yd+wSXqdAxLmKq6DVeEv8By1JSS+TMOhduSh+HBU rWAllImVOLD1u8Bdfq2+w1LSgq89ZIctxCJnAcPFrPLM5Il1znd0o3W4djW5QTt0PJ3Zrmb+ZiE3 j0ZAMVwdGYD01KfHBNuo5NFjotifMeJRlmdFXM2MCua03rmsgMYw3WY9SrRWUlJTh3etiAa0hb0N qVWIiWwq/k46ttSNP6eOytGW0xzLM474N44mK78nSes/tQtKqzmLQXTRH2z1JUUB+x+//ZLNkt3j aH98ieWFGoolUvW3YnXcMA+kPfVBYXIEO0H2fpbOrvbzAPDWq/xoiSM1zUDLQj5Y04wZ763Mo8EZ qNqVbKQTurS0vrcTTuU1zNZHY9jmtLRuuoPWxzifNs8Hp6DaemcS7LUmgQXy9VqWxzGjktRAJND7 tvZ8UkAOLfKkOuN8SGuqlMJaoUtLnmMsjQNpaHnGCcpSg2/S0LKw97HBsUhUmWMrosFOhnou/Rji 3RGlJZTpeViUUcK41dnKRKceN2p/2PdYXt1SIe2Cp+/uEKtr3VAeqlMMNyCBGNHF7FEhr/t+I7ar vZ45taKG6I/nnrvvKelE5iyxDQ6IZd3Mpzp28Vgl1FsVejXlNI3bWJvaqm92PEu/5zozUPynx99d QmKLir9J3BZjG/SXCKPmGdhGqoSRt5HPWep6aL9l5LJpoBZnnkNcHEPPwWEe2qPsYMST2hDI220j wtjYMt09tnIdlB3Pjv0L+qywGdk1qopH8rvsF7huReroH8qnHo4Sf9/HfJqE1uO60bA3jJczgIBk BcHiK5mJrKQe7mO0AW5a0If2njrZ6/sVY44Oc2o7no6ormG8HDseJQ8nJenk4SylftznDUbxgyTx 9j8YU693j0sIteeO+jlDeznq0c9nVvL7Xs/n9egJJdh2OC/vgwTRsVvBYYWwSYYbEuzttOftMMly qx4VFpcFd7TRSsbnPEGUKeRbqQ5pU0e2D0C9nCGxGG/n85HiukZ1urQBPXls7a3e2NkoXWe1Eqft rh1oM6TUMPuGkW2QTtWjWjGdBdYHg8DfNZJhvCFbZITDxVE0QZ9q1TeKUgKlyyhawglXLY+1VvO2 Ma1ik+KwV3BLPLGv87ObuEgkep7QskekPvsWUCO017lghNggf5flrCt4Tr0FMPS0y49u5cHHQSf9 PqrEp5+iIUONb3tEl7FU3JQSjfbmcIbzGw/mL72bigbxKT4Lb4uQjnuyPwiPmuUiSVDxNmj7w2OO qS5L9rhwrN+HQncznRLfTlqg2pt69KS12xYRbcpuW5y3jZQ7XavHVoE9AqjyNTQoEw1gx30AeCOq vsVoIAeiUNr5pHk+OMtJklxKyi26B+BgIENDOtCAdT7s6HDHPf6+PaR/6XQq0izb6Ty7K4R0pmLU 6tHD9chyIZFVn0JFLR/nOL+xD/r5mlhBgWcczkxASesjx+IUqsMBjVyjzMRA8TCx5OhymXeUjoQI 8VkOaRU0FFwaRlhFhOsd+Y3uEn9pz9CNGa75zUMJ2b3Y+ZFO29IlXf0Q2NWt9cECZuP6DRasq3eO ekUAbFmHICk11shxaeLa7x36uts/Z+ODLbRy2vgwXCtwLUKUmYISPpumQkkSi01pD+ya8+xaZ/u5 vnPNWRdEr5GqYFSbvH0mqwg9eZSRn71viPLR65xVUStKj/32vd03iqAhhXfOy1aN8e3ki5EAal4M CWaxQ7iTKSdG21/cLLgSMnK1f85ZItnNpUWzx+Kt3h3t7bSETGaLmtHzng/6u5nHf4EncZQOtJaS +xNJk3bmyaLFoweD4cEGuroDD9rEAyas8Mn7iNehoOIZwedp5jSiSSqpFdLaXTsSCfeOzmfwjie+ 4fuWx94oj/h21g49TPS1dyfvx6uG1M4nAzwY5/N2DIhQJKhLH4YrB0XkgtzLXPfARr5OV9loSFDr b3jQJh7g5u7YdVOwMEl+nzr+r7wfq2BgJfcao9Pz8WlPezYRFE9ltAxG5fOp6tJgfB0n9O7IxGQk O1N1yYLpN7s4FgefAFRjBm7xbR/i3nsxDPHYDj2ybii57m0ypz4vs2WdGUOqRwPIVsssFGr4XO2/ 1rsxBCxLen3emQOQZGVclsWsQwGK2IEFkwmWSaFdc/Z4PlYoJJTohCRv44AtvnXaOAjXBnRJA9ve FiKOPDkll7K+eJ0XMqNsucSZ6ODzqSp0T9fKQrsZTEGTpl7eQpvtuGsuZYr5ErQ4aeDBZCFjBtVj 11YdmunZ+8nIzNXez9t4Y8xd6oW8NLFOQSOSkeY0coPaCPXQ57xnv1oFXbeR5zR7OZ9utvpK63Lq qxXBHFeZEji2z6a16HH/YNqOC4lFwuNZL51uh3TqIb7tgvS90nQkb8Or6Z+I43rd/QLvRuvD1JNC mjlfI7o6vGvnZoESTa7a5B+zXoFLTLNiR5CFSe71XTREWwXF41Liut0RdqaChh+pUuKUlOqxtt7S js2Ca3zrHXI8XS2j9vc9qfYdQEEt9V21TvrUNbic8/TeEmKA5N7evi4JO1HU46qHft8bWvUQtb19 UHzdUrD62mH5dvU7g+8Zz2fOSQsRLFu+EByufjk3q5Jhq21SwShYe0wLthia4sfz7OVJzOjwmwWR i0kGNxL42uN5e20UDFwO4eJ5ZsQQr6k8e1862cszjOzZ0Gpl7+PaQkF9dwODWfMQD6BULUVyuNeq HobW+P2k+X5w432YOnscKvbzFEzSGe6aSQPBA4k9e8zdbu2K3o89neE5lSQyzykZbVJ332PJQUZ4 befT5vng+5ZaTx6H8pqTouSt5TqH2GQxj9d9Alc/Ou6FxjknLYS0JxaGSbKzEt/6eRRsAPIYo9t9 Y6RKS3Yclqb7fiZEMsj9+R7Da7ZcZPgk+/ueq18byHfGfZu9d1Jr6zCpcbjAot9lQ/s47L7Fed/I 7NfQ2mM8rceVEGkv1Foewxl83SQJPZ6V8HZuaYeE8fYQxhMxbfNZ+1iuU1FuYHctzbvGlqX4VC/3 eMafcoMuuVp0HeaAI3crlbmfWjXL+FMr6+xD+47EyzLECdIj9dqlnnphHaVl348b4YDFnTLjDsY1 Kc8iFX937b428nbeOoFdtqIeybu1nhnEUY3TPkcq61EllzYT9TgvtJsn1OnlykzRh/8WCTtLoWBo E8D6ilbtYxKJod8FnYUO71sWlFA/I9IcyUyxhd5Z+bbSxTW188C96v6Wo6wZqsmjKdhV9gjKA03P GlLpRJIgQXt2iGp73HYwJdWYwkQ1wgr9ZiC/lkgpBW1StM95i1FG/6ixOxzEWZ6pyBRsKKqe4q0S YltWIZOepUSjq28n9HSuOic9bItvrsK2ei+Wx2ZkhNz7Q6pOrHfI2UZx3eZOSwkaqqxD7eFJCcgG bEvXGLQtXTnWrghJ1SnMRgEtRe1THVq5Wooj4K6NwnqkOAzYOJ1loQfdpgcSWoVS48MDg3xQKa3n gmdwoxW/NOwEJOSxqzb7BILDqCEeLayX8nU3RTO4Zx3xKAA+vWq60qr+VJQRGKjNOodUoblRSd/K OucuuoPpwdP1CJ+fTOrrOG2GzxWRJ+N0Y7BHw4KnZacO8fnqFxrEj9xmNtqJwspQL0eHILBf7QQd gt51xBu2EuEbV5Z1IFCsBIW9qCn0t6vGiLoG4C6v2nmDGbxdtTT5hmQjpObW2IaHlTOdLeQGl9ol mWUb246Su3qMn9ceblzmpFnmsEa7VRMejVnsfNDqmocdMc+H8HWdns8W0gn0LuN73nyNTA6cfk+R coL3k3TwWy0xIPxJC6SVOZwtpUhs9w0XxNY0KWDMql5rSw67BFXrzw50fVgI28lk+dGUNqRWzkPT v/yr/RLb+W//+R///l/sCekJvUymJNaeEKEdptSrw75uPrefJdh/nJElO/r5zPo3Pp//wxldNUfs P5Vm95A4H9oh9uYQ5rbQA1wEleRN48jesTTO09/3lKM1tO5yWO4+3xMZtdqnjcF5Q/+p+HAMUm2f 897zuh7VtdkH4MczyzliRvdVrDp1yGu7c0vIq7qVMHmUTN8Xa2W86rWt93Yjnt6oT0frnVlMfNN6 X+dMadG0ItbUUJRPJGAetdUlqe3Y9x0cTu959A7YFl+XVjP1OE7U2w2GDk8DkcliA1uQsLSBuLfr RvKKkPrrecg86KpLW6N4ndBTr5XROhiwRvLQ3BvTKq48H0OCiCaKhgSzNGUjRS2xO1wAc21sgp1n q4pZG9n3sl2xi3PQDOUvKc66JzLrKZ/yMQ0pQOucItM6h3nUdm0ec1DdjgByao3tJbSw59OSx6UP x9FR5y22EYHGv35cma7jFxgUNOQyY3+bXVGivJRiEELaOmuhumW4UTHFWY5GMlUY2jKHbaqzhQOZ TMhwCJQeGTeHZ9T6+7hGH7MoW04/0XX/oLqHNphglW2Fs99yyw7PxrLQiIallmTOLJR8TszdI6/N oODCHd78dHgrE8XWmIQcz9oBVqyIvB8NBSYUMKCW7vG66X5sP0HBT0KRIboshnvY+7T3yD5nqXG9 PQJABcvDpklSJzv7eBSVso42YdXbBhggI2FLM2EjUSePFNXhVbtkQwVCTmOHWu2UBeLRp8lwQJCq wnDg7eOQbkFX8WiipUF3Ul3PjQKJLOkKQYXEnZUpW9zSDbQVtTwUndgITEsJWhxmoNeWL8wzyGWG UcabyN2j75Q9nwMavCd9mx84zREVl94S9Rhicpi1TW0vCTz2upg0fuV103ru2z/MSGv/kfOPpoxH yamHbV1PV+slP8WcP4a9bj/kF4a9I8eEy1+KzPkO2VIeNVL6/trqWpAH3cCCt9FGGru1RI/CMcOC ioRww13rwQLS/BAdG9nd2X5o/1/NnD+woI4n9Knueoga13WlSsJe9bnNGEoOxn5EHaY4l9YNfI+l MOX1a2NdqWc5kbt3o23XArDa7UX7BayO1wX93VuJc2hF6uuvYQTrMM/ZQla0wtOwenZCyV5vr4ah NQW0XsSwOj3dNkp+7yNDdfc5BnEdWGg9i6EfiGPypDgETP6+ZwulI4iz1z27bWRTudd1HPWUjOjv dt3ic92Yg1YOzeEI7tIeUIfKItDrZEJS7G82Qa3dnJSgemSwWQbTqFEdKV0psK5DZXctIKi2u/bo 4ejKyyYuNw1tBW2RH9AWJ7QxJUzKjPq+dpCwFejemNJsIBIR9tdQzTmE6v2oCVVxJdTXTY86vSeP yqt6hg0pR+z5PB0d0nxPUgcxxN0im2uriBQ6ns+cwzHhVY2UPbU0M5BzRyRXez6zgUjYesMBzel1 yyQRfZoGlKwXCzMHXFrL1SOAHtWQIQ3D3UhkmGo/lVmCreyB2OtBo7jxemb7ncnIUo0eNTCb6A6t XFOaLTfKMvAZfPJ9/kwR/58pdizV/upM8suWq8aFYoTez4ioOYOB9OAApX8Uj6y2O/eAmFOtxDlW ZAxxQxCP2oot3B3BtD2ct/9BBj1OH46mKqi52380zR/vTeoLjWba1jJoHrr9kF9R9VnMAY9nRJ3Z sCZaEQm5eWSI2+NRxECOKb/dnP+m7lp29spx46t4GyAxdKf0ODq3VZCs8/ahpDM9RnfVj/mMHoh/ L7xo27CPJVJksVjFDDlsBk9uF9I4E6mveRK5d5LEojlP7w/0S/HDR823SBrsL8Ko7kQ/7gDggvGO LvSD5elo0jgptu4RWuCkLj9FVoCGkC1qBnenkYNTwUI/2DKCUW33uzeHdVpkAe9kWcQn79jC8s7Z Yush57+Sqkto4WcpwqZxPzIzrti6OfZkSKmuJa7NF2LEoSVoaiY5yFfFHOS8sA82tTL7jj7IKEXf 0breUZarbS7Hay4oWB5MFlJNuIexOpM+HN0dBcu35QUW0KmVzevW03Oj8GnBj+PJRL3NpuBZ6/rP DxN10kTNPiWmxhgtmyPnwA42skBqtssjoVWTDc/hsTBtXmgBncHZzGxahD7nX2G2Ep0bVQFbrrBZ FejH9AQjp47IYfVn1SO0V6/dpR5wa8wNzeBMpfcpfUo2QqADJ4AHU8bBkJBJoVgktd0dNm4jpa3J QWAKZ8XkGL6HCMVYQioLwyGDqjEWDQafnDN2jwQPW4irGPg0csZmya7Iyb029DHO+5EFPlc3y/vY ut3fgneuy4sQMBUjm/IL7fC/uo/+sWgpvmo2CMSbTz8mBoP7SHo6HjG/9HTeFvR7DRDTlTJaf3M+ zsj5GPr0+yLnyXrXoI9qmXujjXKOs1j0hdV6oHVYdc4Why3BppYM8lZae+4GP2ZWndSBuFlEpbW4 KWDTZWzGLqSDeYvVIhZJOD3cGS/1lhfpYAMqm1OD64lIkkmzWp5ZjWuhM5mPfZoy8Y4ZbcC6Ij9T Tcy+yqTbaA+9YmmpsnABmqFtvp5BrojipjUZn5OZPM4Xh7NRoTH0iLVnZXU4zHvD6OFoFs6IyFoG uh4qlf36wrV7p2R4D+3C1DVZfQGTAzV6PPo9Ffc5sirpzDBCm9/zlPYgWcMySBF63Uj0jBm2RSXq +2w3ygbFh3fJEjc6LXiTKzt63QJu3GSVOPl7rR30UE/MA5f3KWXEaZvfoyX1CUYGwU81s1FSE3wt ir62BoGCUAXxcEKq72vKYByb55Ofx4F5m3bVP4Mwkv4XCkb7dPPuI3lQhOY6nOxiEkYBzxLE4Kzt 7ocHE5AROG8vir9Hv5QK5+2cul/1bkgovLU2a2o2dP+ipt430tEs4MFe8sgCb9H2veDCHHIUkAXE jyzwMd14o45Zum/EvRlrRT9b1GKBLYkWBhXubQ7kxPvi9S2mvxc9P3iPerfgnF9J4HNceh/qoRla kCC9Xy+OZmiCrpU0uIjmDkf0DwajUH1A63pAmcO1lqYGXZQ1dgr2qKlvZ/DN2Pm+C+gM9HjKPB5a rP3wxWAjqscDB9V6PKvRYdZvRo+n+HrDheQhjONqootUnNC+M3rkcGgXJJdWf6ZWCTztQ9HKweK+ 63ECK5SRqhdrhT08LdZqcLBzunKj1Zbi0ytOwPQZxVkcieZUBfZuwwpl5DZ8PMknYSSpra7qoRzY FbYtkKB8L8hd0lMQpivThVh7IcKO0NznLTpw3f0MwFp9pIO1iMhIX5r5ikFQSuuvhqxD4uxGh483 Kw3G3+HfjOP8VvgULMrWVndNl6xtLo3HVC/UxYlfIwTWYEcfmBHXztLgesKF1l6dn9xcNuvl3Fy3 DzSMx3Mir0TnphdfZtODLxrSfdhHrHKCUZW+omG9omzNbSiG2gubOzb46miR86qxEX1TKd7ijqhc 5Yaa2m358VEyjlGxvH4K9OhdRVtk1y0OkQzyiG5dCwuTUYxenYW1le81uBZ/d0gBbWFqM7I8HXNk 0bO1xnG5ICGZWspSCceyOC21JuS6yc6WVPp9Qvu6oNk6SSwkWWsxZ3PV7bwAZWpkgzWuYtlNa20x 2GF3fyJ63sgGCz0sTAo0DwaSue+Raxjbwmww9SMYCSy2ypige/n654EHI+1FD1lNbfV4akNqk3o8 U52RkcCi9uAG357uLwfno9m9AAgzsbN5PFEegWB1dm9HSvA2o99znfkGw3hte6YwcGaf88XIdyP7 2F8FUnKyews3tpJo83Biexp0G41rkkAJlLxP2AoXnIcAxqHetUWmZqfzxV3bR6aOOVRo/1j9mvky aEryaFfN3bUe/QmR6uxWmSNsCmd1QyRU2PSEuTH6+V1L+7CpEse+7l/hnCHy4zPnUbvWDJ5M7q6D NCC1LFEctsw7iG4G995SPAIInDAECkZWY3FjEjjMT6+/LPX/k/41SKBUHMsi/av7I8PRQXarL2Au 6ka3rHP3HQx6pc7dnUD9T/SCWpyEnJIutCimD+tIz+xwmLKxVkT7xAnufkUguzRKgcUpIC2oz4kS dPe21PqnwFLAr56NTRG915+1d9eS5IYcU+vcq9LQ+V7eNCWlAIeIw/2kVjaoMjpDlKt1JLvi2jJz ocWNzbLzfCQgvEMT+Mxr32lfVPNaBUcz8toiRxBwwOdWWaW2Na8droOl/ph8WuQIdjjZWxRg6v50 GIryC4pi36MZz6LTcKmxoL0Q/Z6F3ghbeOP7vHuR3AbdbDWzTeMTlqi9b0SkYPNc57rBVFSzQVhT XtLoaOwEiyT3HusBqF/jur2AB5u7tWTRNyjFfiFAakhkjT6Uycl80b1tVMqTAjnhtch0F23EOflH lGrxst39jghm1+BZaCFpeHzW6tUgz1CDJwMa9Qiet7um52MSxGlahcL7Ftsg5gljfHxRt+0TlEmx IUJBGJJfMxN8Kxwnlgd5jocc3maUykxWi2ScW+8S6nd8HT+0FBjywUiT+rt3Hk6HVo85rBKUic0a NU0+zx6RFFMVLdtyJPLmXwRO2feEXtqGIVpR8W3pe2CcPTVfTW7x6RPaEEHXy9rcqY08OeJ8Mjhw S7f3AGWT2l5U6vPh7t7yswnkT/tFJGgfy5j9jYs7nw8P5EIkHM1rqxVl8vOjdTN4ONcTAmqttUkd qBTbhf9CLm/fm3McqaPBjua1tPIamYTUbNLvNeojimS/XB1ywL4JoeeOLoiV0lu3rbVohlKTOay+ mkmBGh1X90ciIhLofVvLB2x8IDEy3aKtsNR5BKjb7iapKHu2fNAKg6XK1pWq4VCJpiF1TEOESZbM v4K5w9HgadAAKYfVVzOTgBjFYvBct29YZG6yczV42Pe0ZhGj1vO5oUlAjqsbZShbHBq79r7n8tIR ub0Et9bHmZJuLT4S9fbNVaiHdFY/KYZjKfTTKnRfpROrv6GA5iR+jcvGNg/4qHfvGt8Nk5tetrcj Jd/jc7ToGDK+AAq25vh2CeTxMdolVElowjPO562s2SpFSxatK6XFAO3qaljza+Kf7rVRsKg4We7D Q0VQDY9135jWHNc025usa0H8grE+PpP1d5Kbk+ZPaGldwyKBEXhK40pP1t5lu88IeTmaBsYKuSeF jk9achvktIkWNBA1CO7t4ljsTMdee7ET7gK6Ur2FL3pIjscoHbRcIaKlRE1tb99DRbOct9gnjH0w fN3evod8j9HSoF3tQX2CH5MR3xIVlLBIctfLdmN+a3qbOAaB2ESoUhSHRIzGqst4Rz93R/sbJdo+ PZzzaoJGiiX4tyMlh2M0cpIIIh1qoi4rUTNSm801hNLOBLfhc1o9aWNrYja/J1bxuCf1qycN3+t7 uiZjqF2S0+pJ2Rwu6b+Dwe9pp0NKRtLCu/bCWlKb7I+zOI98xcbay0zVn+vs71u3Fiknmipq7Cy8 IHyvKWkLT/zlHf3DyNINqVMf6KCnpGiRH17u3AR8jkQ3VsjJCFuzQLMItj25ZQS2jfw9GaGRjEl9 cBbZ4X34HeCHdIE5bChvNHjO82gInNJksBpsRmwzyt7X83lQBzcUatf5UId7k9sVl7sSXkwaWo0l fIy1bVxMSud9guXRMOgs8xX9HDjcxzWKLmaUCDSxhZXYcODEGisTktipnheuHtF6oiaCBX2E76We V/zlkblDGEMEFxOLnBgCoxvtpOeUw2VECw05L/CDDEWsLlwehxRk+1ZCWHgBs+j0Ga+Sb/6edJ4O hE8YeXrmto8FmcI+MEdzm0PdaF2Cx5rb8OGkmn0kuW2nVGMJDxryFPcKsZCrloZWoL2rdif3QP/U 8DpAYr57EsmUnLOVeRjPgIcI+cWmmCOfTSwn6iehEZxGT1nRQ3QlUkzMq2LnDC62JwHT7tGLTuYh 6xCy8xaJri3m8vy1v25tCoAFQkMe/zHngK39Tu4N03bzCxx+swlc7g9mUua3v2ZDHpv9W0xz7+OP 26Y52kn7WfxPHjhf8Pc3atOLVP+nD6nO8Iek//hP/SP69V//+z///X9UtDWhXXLv/BIxIbBu8o2t Wu1M1Fd4IPHQRT/l6T+fJ/59DPGPV3nymTGOkyeO4xkl9Iv+bWvRVh+0NuZ983MSz0Qy+OG0fUCO Hk7HzWhx63CYPZLNik2ufCE3Lv2OJfnBCKE+szywlRDq7pjABGHYWmrVRoCp4NMQ3TaX1fThgZJz etnCumwMoeabL3ut3+qDNBhcjDNLfwyChn0Kpz3pvz5OBGmdDZOcsynG0tNwrIPfU9b3sD0Rp9WQ ve9J55nB9CCMimCgUp/b9e6cW185oEQwruDM0owKavPR6TkdWPW8vBUOoxjZ7Nyi8w/qRKuEBRoS CwSvhWkgO0lb353S0fnE5YAQPFtRbN5kI3pUIdTW9M53vhfKJmnAbCgbxGnGRY3VbZJBe/YJ9zvy ltTseGyO39J5OeSmPKqc+fJ8J8ZUuH1AoJSmtoXokglCKKF5cjg7Z71ypQut92rsLGcx4ss3bPkI 52PrACH5A8sZydshUIkZk3JGejyCOFNjbD2O55sZqz++nxBlk2GmHGJl852qQWfweFJ2D1RsjIvG 8vlSxY99onMaOxlBHxo7bwfH8HZue79Xpy141JFqqq4rVbMNHnEWeRKaCwLCdDUXTF8xYkRuNVXL 4SHLqEZNbUkic90YSBuRqN+qp5lcx9iULLyAmqKUaPG23WeL8La1OH7IDNf9gm64j8UiVzgQdVJD Z+IFxOlJQ4dqsuwMnaPe7ULPjsz1t9QYchiqt8gMPy65YX/9D1l3/Ix6l+nwbS906DKqqTUVLDiH EQuMwtTReWhoWSUufiurQptU5g699yENBb083qWJFxCpYJ/Gmoi9bNDj82ARk7rwAuqOUsZPmTue 60oFI9WLP8nAXZOiEno4HSsA1dWQUpFQm+DUdWSY27QiWGXB54ez0wFS0MxKptmor54QpmIr+uvs cVs1rzm44u+WEU9hvPCULSq6P+l6UOjos7OmCOx7kkgzKBd8un5An6Q0p73MRtkkJ+euDnHz4pJ0 14qNQAVfEEG37o0ed0YbIi6t4ShDCkw6b+iTk9A+hT45C8dhioBByr8fcP8d0TlXsJ6EvPsh+HS0 mg5Gy2lINdS8tkYI1GywJGcQ+ZDLH8h5QxPbaq7Z8NqmplnPtSI5Wg2fF8hh32OTdizH+SBygXbP q9v5XljBfUboyTX9KoaqGf4cjbrhM2IuePS2XQDKGbftxQrYcqJNmlE7rgdCU2maCDCQ2uawV570 gJdUpj3fcE3DuEdOjVok7QQKNARuRDesEzYcDw8ROGw+s7u2N3YaMlXX2Gkv8MFoYDZpU/cZIG1q WlaM1EbqnLHCbPB4ih+KRH/hHpc4tN1z+rikTvsSgWa1DmoC/auuOe9vmIvtQz2u8FTUH7g0dSQ+ N7jd2IfKfR8AmpY5ORgZmgx2fDLZh2pGq9iUr71oIRWdNEmibkG7NLB+4Me+mBfKof7hTdI99Hhu bDja3s6aMiRMPjhyu4hp1Hl1buS2aftqcQR/HJlYIdRXzQwfT6z6ghqcIx5araHOrQ2RnGUX8umr szFTHylDNs7Yp9BCgd01X4altLm7lrXRBEt8wdc0vZQr8x7+wvxtKxvnem7MAy0LJSCZrbgYDYqF 95Q8tn9rC8RhwoZWtcz6FVEqmPWny/J5/blvU0z6eaA2x+W5m8yM+Wx+yzHmuzCr1ZnVmNRxys5g 2GgWqJhuXCYbnHHyfqRkkcPWU4R0Y80CC1xjagVWtWfTfQH5FS1w2pqExO8l16rXDXMMXZkDayGM Vj0ei/iaXrcCu7fiFh5FdfNstgeXjzeC2l3OM1F/XH6GjVDuERMUn43ZDbYxq6W/0MzbfNWQpOG4 agsoYJp5RjObXPeFMCnNBLMTFYLjuChCPmcrE+eIHVXTdZDBtSzg3PZqEWhP5y3gc8JADAf8+XnJ ttGeoqdwwIlbcQvEYR7xRneqUq8e2nbLZBimxpaQjG7zHldDmTouFTNtsFns2IRA9boVSCco7u1E 2fzd5laVZmpBKuHeyarZWCsamxi0G9XjccDOYRzP2yKQ6PGpWiRLpewTwqVGcz1T9bdy5Lv9g2JH 79rceKNKWcWbBHEGAgpTgX/7g+9ljHSduQGJHL1ra7GfGQnZ5HrcvqFEoHdtVaAscMQzDfetXAKP dZtLfO3rIrPt9mJxFnIlB3UXfJv2dZkoyhgtQfN1ICtLTQSre2M4jtGlkOzzr5y8fzI9ZDA9Pu8O 6r4x1eUrlGJyeZIjmISuSSJ4PY4DlWpVBks/iCOlp9eClXU6f9/J/EYOuGOC1lt5cQuZMZrN3aPn yQAsjO9asnx80dq+i6ZvZ0IM/UnzGG8nqaG1gPMG/U80PWeoQl/8QgiIbKbV4eHZU0XD0Nzm8PDz sNk4cMsuIBtbzQGLifcbnIh9cXM8JaN5jhtS2kk+l1jY2KvFUB60BaJBs3AOVnB6/SUGC85Y9XnE 37OAAWJ8YjUJxHLDtZYqw1pDiwGmz/rFcGrnBOSUjuzTtcF5TarI+RSfh6GQufO5fOmoJ3Alzlzw sUjeRntufUAdymuhhAV0RAax21QkkNvdWBS8rfqGFGta3xSD9U3r7QHtmq95ioKTai2OFG8wEaQr IQV6mavIvgYiL5lSa44A0jtHh73caIFqxM6LDdClFpPzgvPpCcVOiWGRclkuqC5aFPeJ1yXXX4Nn LB8G8uRocZoSiZydVy01zV+/fMprSOOH+nxmhicmpQvluk6s79XWUIqxV8WzO7YzQT/paogNobVa WrUak1dIPhNi/tb3U5/P408XrTrLF+1fcAzSRI12wkaiflECardlMlGn1A+QqIObMEH8jQp04zTn ak9FvFx9dZaXNTHes8oieHK6kMR5HXVbqI1xVvjhxH1+yb0/Ha2C+NbmLIfQPvnHDGLlPuzTNfgx rs0ZNaWr6C+1WN44F1H5qU9PmU8P0S70Ugf72Bx1TbM0mhmMLP3CUmxlz+ao7Ti9h97cMbywB2sP bH5PuYcNN+pF67QVJXBuCq4Y/JrBz4fWz8WvN/Rzja99b2gv1wO19EtYCChxEfQtOoupTY56IUqE ZurJ8KgMALXJkwzPcxNAt65Mjb8ntjj2eMx1o5cvCU3dXBnbBsJWq00CoJoHKpQwLXHlgY8/5se+ cu08ngDXqmNcJuO00eG7E1tpeOVq0OegxIVOJ7Z2lEx6hMTuOpi8SR4Vjq+BUaNCKRbTtOa1iiq2 KmWxVoj+Wmhx2CaZA3P02RHE+hxmdfPZYXPEXJzBOeLZGxTPLsO2YWaD70Vi7blHuCle4sLbEytB i7M459XrhomS3k0otNLtFpMiwDXfJ+axxgXkMCtrPxQB7X2P5BjwjmhcqCHz4UwhWRQzTe4QuMxf hmlQcNRwq01amLnvyeG8AK1gOh1oH8DAaqOs6ex6+vOEZ5oC+J81M13WrXTJfwF4L1c98YQ0Lkgn sRfVpuCsNgvI/SSMxmc0C0zzy2SzcIe7oz1rTW9LooAU11bxqZ5rwPhhfEEQEkVGyx055ET5etQH szygcxGTn6M1P7Q80Ou2elNWvRltfuIpGee29PambFvUZrdwPKVjUEcGqMM4oSa3dmJ+EgR1htRk ZjRq77VSNZjYgqQbnYxGzurjWCFqNHKyLwcq3HJcSqBUeDrHaJAy0cuV0FhRE8Hbln4vbWM5AjZz iXUIZSWmx5ZrZV32zlWkcvWAUYP0tnEME7Vp8XblCjcRNBussSKtqW1et/RcJ2iztaZeZBYmumBy EJfuAjX1B8FVO1ICIPqYCwudnRP5Wm/BAGJ+OwSGUDVK1tsMvyPFBX146np4qP0J9dfYqixVzhv6 2Jb0NjzfS+M4yXnBZT43fWwLUQj/SsVs31zxPqaDPYqdt91h7YFNdDfddwQbysHJmpMSZyeb/UH1 AjmHmgFW75YJVG0U+tDWGn1P0P/9s9bkGFIgI6bMfc2VbzhW1NB5+53vRZySc0grICAnLDbL5/rT e/ud6vHKWF79Tma4oU02dUy9/ZKp/9itGF6PmRi52FzslTs5gBgGX8uwpYmNTeCSVGZXt/Vk4nM1 NBMxezL/wkxED6mAqe84pDoPidJCObltZxWqTYLHuG5+x76sv7aZrbU2JjOrvPACRtKJmt8sFm7p KFCKRdbM6jeA3Y0Zzp0JVaHJh1noEFe0lAJZVvZbG7jjrsiad7HbNCMQnNr5arMwOAISMdLIWdPe TA3UTeowyN0foKUrOS2cmigdfwW777xtd88R+6DE9fAwPdDQnEVWtRxSELDrfVzrPNSAy+R89O73 DfbG9Hjy3L9shVy3KiEZfEeb3A6RKUv8f+quZbeyHDb+ircBEkMUJVH6nPNcBck6fx9KOjPtjFlG ruFEdAOza2DuaUl8FItV5QFA4DqPy2hQzhZtHfc80baMcHefgE4kspQNtS6QWRf8pgUYDdXN4LJo qJ7EaiQ/69Qz4Dz0G0ywbc5EEHHXpQ7YfglZBbUGggnnILzgTarHFXnebGQ39EW4vhlbQCCozSXx Yyvbaelo9jJmBjb0eHziOXc6rI2evpUwJRky0NLkkJvD8yn3QRZNXN/PbLBBQ9oXND3SPxJfluNG DHVuXiKQyiWJMh+bhX5I5pl4gLC2tnDQd3ypnmbZgJReecAP5HHf51r+7tpx5mSDU2WSJUBLKlIF mSUu3rhia9FXY9vcJM1201Mk9AVtd+ScPdDVzPORyTBARbXT+7bl29z5j0WewSICd31S9bhIsqUb ZTZxcMsiVY8Ug7zvycqlej5PrYPAap+k3UzNSj+aS+dUHvXYLkXQZUuHpatJ2loPQAeuK7oUArri vVu8UH07T98DcmmOwg6/ZytULae0OPbH+tv5ZXQjKtWYlkpOkw0GxbYzoeXlpfI59y3WuqJet6dN QKnHKc+V2DoeCm2o7KLH45JvlONZDcqEhuk5g/uGJco6OwSNA9HaG9M4MMc8BTRwnNjjHGG/SWy6 kTw9AqgJuEFn6MU16GHjOTKBarRf4XQwIruQZQ1NNJ2ukXeV07Jg287LUgwtXJ+WB6TRlILH9Reu h7UuIsMEsqdR0MG9VfJI/7iOy6Ln9OOZHQ+Mbj73yrdyNLtqm0wq/TBwPiVVh25pOQaTPhXqHFuh 1+NzbCWXZXCrb+dBD+3uujt02Het4wsrM8+ebNfEOrtrNBnRu5Ydvh2NBbs9wq6zg0Mj+S6J7lAx Q2RjYzKi1+3peFBNnQs7DNWJr9tivYc6p6Rwj9RjKNgkBKvK0bczu2uoAcLd2dPd4chVyKSztPg+ ZQ1tQcpAFdTUK5vra7uT1cBRrWWSc+zIxqlwAUXbyjnPHu5iWUBpZJtgAawKNBh4jGx1s8g5kst0 FmmIzFLFY0u6lXuzpafq02LDSJ09SjWlc2eTg9zmyBfethQANBV/bmr1uib6ZXGN+tuZeAGscqQ2 h77q0i42cGp9O3G+HbRo4bSB2+5mbJFqqG4PjxLQP/Q2ssO3I8cm9hihTbwAFQZdJ8ghXiAbbSbs Xh68ADVwPovQdmRrL7aH6gdtQwYwkaJD9PCKR7Mm2DX1j+rl2S/C3fW3R2t8PSJ1SAn5XWepCDpc ui+SjmIbdLUHm0JlgXbYDu+abFlMOeQy+lEOiAk2AGF/n0P1sKA2PZ4HLkBV6Jt+rL/vSSFdZiiQ On1IkeWD04liR9iNBZjUQpkmMCCRSqmI+7F0n6cFsUTO+nLY3OcB6tuUAnKHXNljS5FmcNskS5jR AK2VY+rUys85bgb7L+1psVEmJfLYJpw1FNNuKMkoDOJv2iNtR7KEXLVqa7PBBviUVy7LydduAAbc hmkKrHOwTRevpIFVNnd5JM44ALLOFzZda6HD3GyorT1wAaJNCXukF5TrrEYRqseT5vGgOCAuNc7O tJ0WzaikMNtrFAn0T3IYpjWymdsv3Yp0RjYUC2pCyPvSfrSelnl8h3Mm8g48sKlmIlBULw0HIVdr jVTv2+zh4PnofXPYJGhVcH84n79d4ZpeN600gfgHSQrVYw0at2KKa6YwWzi080+5eHw9J5/ZAN5T oFkXoJkiwt27b/YyRb3WTmthWSPB7HdQlSNZCwp/Z8NXrYY9OedS3mMSJO/uFAfNt4QPeefvryGt QgOSdn8rZPNYSlo4iT9CAzFgNm7yuwR2M2cxmAV93DGGb4g/+YWs5rrD2et52ZPE6XDXkNpUn745 PJxr42gswMWRP0dQs8tp0sSLFvqWLl/TxaZWfZeiHI8HpJwsgNK2+nyi5UTazyfO8wEUvSzSHBI/ RK5iWZFqwH3aHbSUhEcia2lG9aPj5R/xRnmviGTkc62Cj1rK5wRKYTRufQHbDgS5hgQqz5+r1b4l Scv0j4MZjGO3B/O/0G7UaGAZRPZoMAU2gZQrl9jQIS1d9z/SblJZup7eiAZoHdanplGJdzF2K2Jn 6dUaIgJ1CwF5wKUDnkLtNk4ncneLDTWjUM1B0ILi0un10X04zcv29NYICNXC22Np0IKlm9ODwUSm wL4yFUlI12jpAulBzRiP9vOZfU9Fmy/iUo6yEB/GpkhqgxMami3AH4umU1CJ/qCdwLeOJ1nb8Xo8 s7JG8IfTPTjZizWy0kgc51ofGvdK+b9n738nGpAlftqjwUSnGnKL1dNx2MhtR7BNx1KcjQIkf3BI HvcRtkxWdNPrNsQlGvocn6COVqKWd7ReN5q4AVgdo6pVhcMxXOI7GyzXGNrYkK/0m7xf5NyyAep0 L6up62x/DMWWPQp/XHyetoMaDV+el9UL8kp2wV6KacYR41ANRmH6Cw+otWE6HyY7PMXZwdmWY50b XpHp+so4wPnerKI6dS/FwAlMe9+KRJ/wLlkevj1MT/gQLCaxBj7U8yyFD+u1mRJNcVrZgGV//VKo mbO4JQ2mFkOKsyUF6K42CC69HjIVK/Foy1NHywOUdjn+f3D0vhEMpIh1PPohcSrtIgREoLrm2pan L8hbr4eHozeo2bTlIY91wXaImMLOKT6AAToen+KAGqwtoZkerDu6mwJgIEduXZTTXS69St4MwC3F oUWpxwQFwcRjcNPXY3FZ+uuZgMHvMlTU1xPtSVx88BxwPEljvEPAoFDYDPp+aoO2qyEbFNZO1Q65 1WCqvLehazSksgD6HoNDfIrrHaztihImq9p29e4gKpr7/iAL5FvBwPqcHgwmnPO7LCKvLVhgaE89 ZaYeQANpsaKF/7WzhHKYmnqJH/QQvJ4SksfSoBBtRqmjwS3N4IZ2sGvySNa7YtkNEEQrgzgqA9An UIga+Rx+TtFf/PlzCr23UBFbz+Vekr4bscKavpsHzkHb8YhJubpma9VawNYwPdG23yUZzImTEaY1 iZaZRO0oHXPq6kHuovTVqFp0Cc06dWYdMERIJSJG9crvaUdiU31fHmdixN7vUq4Or5u+Hosc2l9P R9vE3o/Xvi4CZRYtW1eKThWpNsGAJ9qGRr5Os2iJLd6fCfyJ3iPz6zqUCyWNWOi2cMM4FJ21HkDV Z2iotV66GS/VQqn7qwgzroHuoOXKDnf6tnNnU1gi8QTawNCKuoaDw6FV5nwYA0XtzYaGa+XXtd1/ Lq69vJYkNZl6U61P4PSyESqmtTTyeNmOxvZCLE9cCqLUPmu2S4plMdTPZ6K6BB6PZisk0LSyyIn1 IGOfPPOwuhw2NQD5gLaqK2N1Dtq9GVtwJPofFADyKDalF63ZqyJxYjgEqumohY/Dh5NTDsZF6wja iNIJLY963K4ooX1UY/lzzVq/Zq+Ti37uybxMYGkhWE1OGPYOMSBb8lL1swFU+HOV53ea0CYgf84m lFCxxsUn5aPuVrGmrdz4HLSE4NLesh18Wv6JUR7PJ+AZT5G0afN3OOd1mN6jFIYQbUVDKpdgYdbf bi4gBJ4f8zryua6M1ptWLZmcKI93AMRxOVaHZXRt+0eV4I/rfMOFOAJ8oGgv7lBIosRzs4wGW0p9 s4pR0dlgGFhZdHK8LkubTVuyaeGN9t56W+AQibrKXo3SkxrzyDn8elhbl3PSdUSTqa9XrWuWgJdD LILsyFeaovCds3yuPAt3lBAGNSh8XtdpL2iINg+ml6QzRCNkwOfQXXuCQkbrGXtfYPMhvnwyC3WO o83Q13/3MOIZWtbRG4hOZikokIlMadMwt0Ggwr7HeFZK3oyPSXGU0FSAvj7X0EA8SytJuTm187Be Te6v5vVEs27qIbu2auZ4rcYxXkMrYT69oG8qFt1TL1if4kRuaNheS/O42qLHw5YOkx5PGseDNnXw Nv9a7gBZykVSeOpmAjaudthCDsnFdwin7QLLPeNIfN3Sdl3zmfKeTXunMAdSAOX44mNoXTEQY7MV QGt4MBs4XmsIIFzLxL3YHE4PYzQCLIi3oUntEILa65Us3ncseTwc1Erju5bCuocT6LCGa4kGalMq YBC99eGaw8PJW7bWqrt38jyc12ce6yYFie/NUGrWqDYHOIiDi5tPXgd2xrNZzWfs++EhCxiy44OJ dSHCERJbWGfN1KX06XXgNq5LN9t576Zhcn4EjUF/k6T43Kg+72zyH/IjAQw5qz6FL7bzui1sQL9n kIcyGrJLFo97UyWVy3B97ftf77VwBMUNUdcpcPc1186WZ1CJZZCHBDDx37IGcYe1ml62zXKx1ctW 52X7XSJFnFsxCN+Zx0J1RsRIjQUZ3ba1c4/7Nun4ocdqrXwIxDbOjLD1tTjh1YxYIPLe+p7eq1m0 LqzVrkZGFuXS5XyCJGS7l6BY2dKhh8YBa1GibxY9SQfAA/psPFqHJa0KDJkVbabr7EHBXeMoyKlu 6bs5I1nzQr2CacQBNP34YpKzlPC9czHAKM2idWZR0LZxzNXhPtt2ag1qZtGpvZYR9CmtissiJySj dytj3bAfD2J4aYvqECTYjmpO2/R44jweZBDgc3BQUk3Wsm7f/qjapiFdhVrQZVsaC45CxvJHGeO2 ftlAidNiQTj72svG2XKq08uW5mVDsa02j2OQRPtuktZoMPAanBtAUGqlVUi6q4UVyPBETBEttGFU Kq1Txtsu/QL7pj01G9SLccn1vKRZlLUylto0EBSQRLWp84jjyF3JmBukKLMEtd1ruyVK8ag2zSWJ 0SHUrg9BOdosaQ0QrJHCnritnVHxuX22oeiz3cpwnW38APNkfm6i842Mc6XTcrTv72LGAdCLVoGg x9KzOZLFxOUW3iNrkWOv7EsNqHNbyb6pR63b54/JLb3H2CKatrH+8Xcy28WntcpScnrQQkSShtSo xSH62oxdtlo1gTYBz0b/EkyfPzei+lYTas6pS86zCSUwNygNan0uNUbleiWDh9sNNbDJq8u9j6tY hm4p1lkJIPJ6t99weDDbEW+Lr6IXbbbTaLbb2GXdKfrLjaiWOM7jYTuolaZVg0MwSsvobAyrC4fZ T9t15xu1qi/MX92ZzxRNBeOQ5wgkIvDGJ/S5XXSYbpU5zxwKlPNjN6hx+HpSqWQtGhGNpbZWfhcv f/8o5/VXW9DLm5rgruGb07aAymaG6fLUA+B7plamu4vGO2/VaNnKaNmQeo/Ps8lxrBF8Tjk8Uw7y 300pIGGllTEt7qH80ztwHE3Ro0moVPN5NJy10vx8NHloZFMuKJ7VBmcFK7f1c6Hd1MgmmeH5deme dUP3S+ptzaV4KvdIAZT8IuxRGSadORv7LFqopffGISM1do0PDnd0237vBrZeeWiUapWNnEB8Ksh2 JxbTH4wGGbfJ63XNurmH3MdHc7A/QAd1oANYcFNLQRwqELFQspbBS5fJjy0hUM3pLrhG6GxKScc5 YPvGLsu6i6ahuFogVA9pmj0DYg7EUjyuF2gNTRb/rmR5mjXEI2rNo0h+SXwYzZpmnNhVIQA08BZz QIahKwOBhL1ZW8e5axXXDHSVKDIhWO3nOs/v9DciH8Hov4povWlaRP+ukVSUaloHU5AJ2qClqS96 z6UcFd7J2Mzpqkm98KztVTi6y3wug6OJm9HhxKEXGRiYvVPmlIDF2Q8uT35HRDpaemSV61N3QnTd pS0L76UcRi9dwzvcOZ4/018Y0NL+Mlm4QwaXUL/2xrkiRsfifJOMQUHMKYx8A2oBCsHjXk7c2SJ0 kMQw5Acq2AN7y1rkOazV9OEc2cifXRuCQYvj9eGkeO0GdqsxrcyYBuBOpzEtnnJYULRetTqULtBK W9UW1OFViyTN6HK0ZZszD+BC+VXLtk5pVd/NR/7tn3czwNvfhat3v1njWyg1DdDI3dAlYpPjGa0n E3KdjTQIaE7FVOTer2gybdJ7QxTvIUrqkQq5tdQ+l2iUqd8yVKK5nHfqz43/eC9aaDr+kvQv/6r/ i+38t//8j3//LwTahN1yYdHcOHnRQNfbq+xd0vdu8Ly1iO5Tjyhwb5KCR71laZmz0eC0Xqfl3zUs 3M6zmY66uT34INrF8em9wGdNpnx0G4NpJmTn/paSRw5h3sJt7BtXbrOORtrevcVx+DklXZbmMlO3 kgixVTCT6jp/DmkDGqiLtdVaSngYKmha4PP1pL00a/UrahczXw/qQjsm5+97JGyXRe3KeeLrSLlD L5tDXuSdJFsmRm2sUNeIVqhJgjikQ+njCeYUtISHhYs6hBQAjLsYvqFmlgW9Df1l1DvZipgM6W4K Sl8qEnlUWJLQLN3V2BmrPQ6Ai0YpeySsVjrM9kAiTdlVQMD1ikpvlyRrNqWBYK5/wSJH2KMFbZJ4 WjZGFLuWdAqvm/+sJN7s7bRgHEo8NXERed1phUO0G3NdHhyv3oqCUNBy8+jTyOkuYuSc0mdtDbXV by5zznYVS/Gmh4GJeqD6JrXisR4ozNUaTwV5AFCQQ0XLbIdXrYTLXNZ/TA0j2pzkxGgCsjLpHCWI PQGRGaRfF/xfqIhJ2TRxpzRMzyXYjU6TmAFZhRdHAktkrUeCCUohyY4vHCeXgjhSo9W4UTdoS9D0 3CeFXXatB6x1tvRYhNuQR6LWGiDfrFxvb9v20Yj6z1wnxfcGlYjeSgoOW+o75mjJeEnsMl69M4Ds VTh0W2urLc0oPguXKaiCKOxaEyHy6sqxm1Alo/jswtj6fgiIxlGSSoDGTis/Z7taMEXjhoRkD9OI W4z70KX7+tu2Ge5MGgr6iBdRvd60vnE4c7up7dZgRyJNxgrMoRSA3s3aHHpe1dw67neNUkaSN8xM DpuD7aqbOXcrNMFPtAMSq0sNc307yXA71rfT93MKAtgoeBwbcCofN9z/6qol9K4axoE3l121Jsls tAaRmEbt+bKNwRutqz311WRTIabQgxRC5UiXrybGrVUz49T+ahDI7nXVSG5L1FMP58FvoJpf8ajA fErZja6NQxnLrc2e6DBlqOq5spTWItOS+06cBpO9Apn83jO4JLDKvbH1cnLQlwPFlbowmcOPOcth 0Qi0Vpttm61A0D0OBDhRL+2pNRJsFhylkeDBb9BkV8jj0iEf7TCLm9wxArhHXUvzyCKgVqwcKrED ub0xAGmHpKFl6qVp574Ou5J+pMvBph5Rcyn8X87OtrE4OPLY0iNGexSPNA8+qbD5eHpXDVZcNU5r dPP3MTfV3YpsGqnn40l2MCA9vubwezR9WDbu2hekiUhZJZv23Hmwro3P6eqmK/HCWAwmQeFHgLmC uqBRbQ4xDy1BxVre11A9iR5s3zbWAqgCJbyldcF9WTO3Hqon6AG+h2KoiP65OLTthjG1hrYOekDZ i6xdt7+PyRqjLJczzmk2CGgg2qnG/j6nhl3C57TTNygiB7Y/hkMSVOOsfDic9o/UiL8BKerKcV80 Ox4BKb1VxQByRXqMpspoaUevJ2J5LB2C3BfZqMfjlsFIxINckte015FgxrQOSaEN8bfEHm2ANsqH dTiUShyzamAUqn01UC//QfDzW+XNYVefcc50GLk0UURriGuJki1YjgxDx6Mvt6BtkBg9WjdmkdNU KmQeUDvCP7+geaxzDM5UgtEZ6Ed2oaWCXDWdLupwoma8HE06dSYdtNeCi5u1Sec0A4EmnQm1g0Cg hbTLtTA+u6mMkXTKQHMRPYpdLh3ldrOhu1jT2KHSqIYG7zF7tJjI98G2ygpPcBo51DvlFMWzFGvt SM8lTgjHfjvSNL6Dpnol5sEpWtaNGtnCDG0IznVaT+dyGG2oJtG5PIF011xyJTVOW3hUj9NzEAL6 ULfNwZmq2RyUMQhBZElhj2TJcm6mlV5sNQ2gHaGFb9w1tN19D8vWjECtgSCOQAAl/ioh0Yi1Nc6x 2yRwfuY6wAbELViY2WQXljEHQb2BHpzHu7bXs35mSGlm1ToHkXDmD3AHSNHdTmOdUkPw3AQBoLTP dT2+ts2I0NLie4wViGHRF4LsS51ztpAMk22tpB/xC7tSS9Lg56ydVB8fTSY+RrRn/GE/HK8RrW2t 2V3bGH+glrqk5JAWwWULhjSmflDPnlnS66bHK7scDWrWYFeD2lw5QkihSyxKtlSM9X2iJHMH2Q5r qbGAyoZWOppIqNUa64bWfY2iHh5yAdEIAXDPtWPdIxhhuse1ZwQCvsdvXOPbrNTGCATRb3yOdbd7 u01v3cIPVAi8M5zSo9pWr2IlHelQIWzZCnkkft5Us4UPaGXzYFGgLZAOaPv7nu0uVindL9uDdyCd TK+RoH5c4f9w2TregcTK+l61w5dz1ExWn6MfRJp70ssL77yuzbkiRUvYK1C/aNpnAxA3B+6pyp11 hj6caGthpQl2AA86v0Ch3IYEDnEIU0gOvh2f4hdJSrJkGFN+JtVIBYddGtRrXPsfCqZ/4lrHoiri 5LJ43AzVVsd6O5HS3HBDVpQunba3O5/Gmk4PBBMjQARjp4Egt6saQnI1lWcYitpqnxSPtsl5mgVB hzwqaqpTSmByuLj6DP9N3bXkWJLDxqvUCQaiSP2Ok78HGP5svPLtTaXScAET0XAN2kj2YoABqhaV nakQGQxGIMMlrz6XmJ35MnuLGnF/389OQwMdPzurDyVI4GenR/zY5NMRFjiwLT0RjdSKuLrrFcEA yaezIqirIqC3Tg05ATnrgAuIbZIEOD9julAX4mgur6adnQUln04kWIsGJMlVrVdG5r7LSBUBq7sT CRbpQdqDqH2o7Z8LHB7L9V7eHWTi5u2etYC0R7FNDZWf/eZwmCuzpRTwFjU/PKD89ArnGVKxiLCm IUO1zoJMpicULI0xcciU6h9jQM+l7WMHEOVOKFiUFOE9JNuIKMfL5yehdVdN8nTWdLJDV1te3UDc bQMUaNG/2kwN+WmFk99r3fLIhmKQk9jDSZExiJSQsc5ju6SiCqff5Cex+SvFEll0fZVgy/sFNkG8 0fHPjIyqo84P/R/4QiOdNvkO+SdrBm86l9aMVkLFxu0mKZj3zK0WVtmMd2+bisTStZaHx2WitZgt qLZSUQ6A3zbLjKDzhbCIrnhjO/cTVp438clsyrRHjKSrSTtYcVW/O1WJNuoXKFB/38H5KQocfjkC Y8xSJjrXHyu+5b0n0Xog+bqXz7a2JSrhoJI/Z8BWzfG5oXJTyjTDs8bs42RYRDxzfBZsWVoeep1J 8GLi87FrBcSA15zzeWbNiQfuRdSIG/OrZZoetUCzmH7z6/BhxLFOSQEt77Y2x0CXp5+de/uYxLRY 98cmdr+vxrR8FDrK+tl56HXW38RUEuUhaHFqnh27zw6Jcpz9WgnIDPgbQCFHpmMZeDCoDmqa76Va LbD9nAQ7W2aR0SzgNVqlXUBdnPt8N0kVJxxJUVHWgb4JBWMT21HlOZN0/kH/+fu66Z/Wax9pG6nX lgKPJQCYBVXgKXT3c5B+Jh9U7tkjLumVLIIMylb+qXQWdRbUSdJBLR2ovhlz8jEgQs9mW1h0xqsh gfthANRmfXOnzghpQYP2BprOBIagsx6oqx7A31rUWlo+HckhstjaayOdaEycdlxL2GapPGOcP0tZ PBMC0VjK752lvSGW+ZNzY2sGb47Zxnbshqq1MYcFg3xqkkOWnn63o8xDv3T6unQI6eko3gPeodsh UIxba12kNGt0gp4d/9YKqD77LKb9W4O3juRarRCv7FelN/2jYCl03jprakikN96kVjaffhMIDkkD LIOVdg/afkxKy4ujqU+GXr9+bBZXWKhbaUiTpUN3AXSUejnQS6eCfPZq5sz6rVfjCJCg+G5MmpDl nk7oDsgNeAta0Fq4lwJLfMdOTckakoeSo4KAQK871+oxizUJOZ/O+5GBRnqGG6cFz0Q7ULWxl/Pu olGGG4cOaovEJU1OWBI3b9/N1r4hwc0SEhmu1NICNtQjnw34Sfu//bxxaqPJDKXmgMBW5DIwMJgQ sMposvvRe4qY59z2/QI7h3McsKQqf9YOWD5tw75+toSexHZRp/tVRBeCKwsyiXBkW8xnYZrvmKPd seneQI0z0k0VMpG0pohxTX52BmpBpeQlIyBQEJQq/JRDALLNqmCN3ZnKw99gSNPFI2+Iya3T0Os+ O0wkHZMhMLUBqpzsUH2XoNTGnOuK39t1z6caoj5bLktSRLzjrI7KAoHeLEHHtpcMge2mCsn0cIiV gNsfQ7sCwYo3QfMSxWtg648msPb76s///K9//7d/+Y9//b8i9Nih0tMReolV2IUzJlUd7r14NdBQ ilat7eE8qXtkSPJmzwlVa/PGWWKViiHNhCoIXgaBeiKh10g3h0uEuHWMiOqOfOYPzmUoS0RAPKNs hpwFnBxu13miXV0/PA/zSTjpoCIC/9jaDm+cmy4kXXW988LCPYyX0opejgP1mrqz/JyYpfTQ1jO6 QG83dhYGNP9oAgRvXaAOAqjmnCCwJrqEYc/DqyHyLO/202cnN+jDFFJXv5A3aB4JbYDNG3TJO8jE PadSjWy0vTtxrxkcnDmD/mtMl3YCaiXizGDbLrQAMj+2h7whcoigDaiDgWFrlbJmOmRLt1ifJuHh 7GRNaoZb4dNc3vzWYTK8GVsbD9vGVr5v6fzv2ZE0zw4bhfpvBjw7vXhrjEdUS0FAAgJLrakQCeur 4uIjn+ji0VSenUPSVZs/ckAs8Is0Y2K6PeTanyVd88PTBF08kufhYVKvbhGDwfIpF9Z/lzUFIR9b kfnm4rVuRa4P4AnM8jNzY3J2TSE7t5x28K3Ny3UGtfDkUyFt9VvdwbbbiTy/a+2LjyJbrlF9/cZm B9g9dhCwCQJM5/WVmUfMu9WaDKzAqYthJ22oTq928nJeHoUemL/pi7+p1EQy5Ch0q0mQ4YVXBH1V BNQJL6RCylvKAfTFWcoy9sMS1q+YiTOOBN/lXt+QoE4kYJM2fzUBYU0PMwBr5iCdNRMT5tzbYP6e 78LAcYKk7QkDi8FhU+qgDI7DQAPCQoeB+lhfEbbQz1tEJvfOaUW12h0H5LUae5xeI4Ztqx2f7+q1 /wmpX8tgf1ZIvV/sOMq5rBRKLCz8+hVCv+dJ8pH6QfksXt6s8RTeO5xSr0HcSl9uqLUhIZ7j2iIL K1F6BR1POa6diPx0XHsIDzIO9a80onFcO9sFlYVTzy5W2F7oVxMmJXiVIuifC0vA25KAM+diLx0i OkhOLgBwuaZ31IR3QuT1LK/McK9Hz9IH6kTzzeWyzkDn1Rvu3Wy7Hx0MbYsrJDKPuCWbnIhec2h7 MnbZMoimEdD1O5+i5CpdQ17SukmetpnxnkdPOzs8PDeXy6bvap1wn+8+zNjALoh5tzObN1KyeS2t EY08rqMBjsCRYDyE4Z8Vf7xVfwe4yFn+/5TMzYOpWN/92PRAIYEj3wQoMy6WlAN+bP0sG9azt6WN IDafIjWniNfOdWTMto+HAKUCtpBbbv6xNRR6OPLNsbE7VJTNd99lP+sHeRb6Q813I+nHvbW8t4ns sNaR6ktTW5wU662/vI4ICGuWOlp6z95T++P0ysSSvyA+Xnw5137gOMrxEKB/VjBtkU8BrJStPHTp Qm6dX3RuL6OaoHTNkaeCjTh/e8EW8t3kkRStHPkVulQ4jMSxOt9buOfxs9OA8do8Ow/JRhV5ITtR K/sGVDg5TVOCytb4g5oSnOlChKF3oVMWYYko2KRqZ+XNq+uHNV9of8Iv0cUSMP8ob0QjmmbrmQ8U rzl0UlLMh/WrmwZ8GAcCwdG046GkmHwtpnLl2K0hK9YkfdG5pBGVapXZ/L17eFTReqgfnqexJnyu v58RksXJgsLBhk5Kivl9eusW0QLDkbqjkXXLsz2YSE1eTuuVOJS8DAaWIT/d0mKlyJw37uhNB7LL 9cOzlEXMS+orj4geJbt8NvA8E9yWMQG7SXvvLSJXcKYMo47y3ESc54exoCVF5Nu3aztgvHNLi5hq TJmXNeSaddULp9H1h/4g78d/ISLrrmfa4VKVTqKNOfx85ZCCnNKuBA5PlnIbsQmjC37R87T3ep62 o6CwnNJagM9kbC2pSI1Y5hynoiSqIZP8UCqglhLwYa6uCSnZdCnZBkkG+dI2/v8Frf8IpSsMEm9p 8YZk3c1RukcUGpZckSer2a2blC6E1M1zhyze4+z+PQH9lyPAveRig/gZT/sl5p397iVqaIFv3pFL /8XMvr4sR1x480u0wO1KvXldNt7x3wr4seWRBhqIeEW9jFfIy7GiwjZ53/X22BKMRm9p8brEbdaL bYsIBlv5kITK/nCHbMbTGvEDfxmrLwXbr47VSxSeGXv4FTJE2LEgwWVRu6lQCmwWsTs4dhN08fgT LpkE8S3SaiWHXBAZO8xGb2lRu8QnLyoWjHwcwOdHHAPSfCq2JuZQPgKSh1u5dqRzd2h7mF2WVxvT 6qfk80QBdVZXQF0m3JTmFpH7KO1MaJAg9TaZlEyXEgNKJdrRCnIATXdAOlN9ZH+nARX7jmsFpnA3 eVhqUoPmNJhZ3suLYheqCfRef5WhpN8Jqth3mG6AZJswfducszU+KSki+aHprIDTnVXBrfwQ4sU0 k26VPM+rp6cWQx2CXzvPTIRpwEaP6M6ox5YFtaM2lbqUBFVpAdsDPUcBruA2+tS4k+2Qr9pKCmie uw/LwBU8i+pD5LB08ZiE+3Ypep557zzTHVISqOaIvKEDtQAiZwK13UDN6s8yckCgHoc0oAr3gk1X wfbzecjvw+mfC49toBpH070fopk5APrHFlGyr8enQEMZuydv7Mr5GhENZY56DhwlOtIqCUj0u1UR AtRvkob7UGQoM4G6L6Bm/n895ARhu6w3DNTPgIeUoEX6CEhMjbwfgGWbQF1voKbBQSkkFowCLY7T dNKVktk48UvnmCvc42wzpBbyOPc2kkM1N5zMAcucnrZ0/f1rM5kmOcpsgS35L8aTT+pxfaB9kc1h Vaa2JSNilGDu2w7m8PPeyevewQ1CGVJZAfpmK+r3DkpxmMritO4dpm21kMICs3yAusCsPQwofpyc c4u4U+HXTh24P+jz2mErvY4FEvAW3ZMoVLo3eUajjAZNIWOs/d7Z0QqP3zu27h0mprYWcpZ4XANl PY4yZ4l0MOplQ8SHucTAfn+r7a/CzED9xSS4vyPeN7zWiVqTA21WSb29shyrf9pW5/fa6moJ1Woz Ve+v4Z0zJnCyiDXSt71Z3Pj9iTIR5/2Z1/3JopJrijiA9wtHAElwbxfcFw7jC01CMtPpqmA/eZZr tso1/LmVbiWimfae0oXV7bL0BJ3gWkm1RyzXtlbJBVrXBUrKT8kScbXKPlsCe6NefvZVfmI0iFp+ nv48QPqVx/jLT06ie5b83vl9lpM/vXf2kQ/Uuc0dyoXUVDaZNeJoxz80LKHOawRP0pCijkL0OC/A eXjtOYeIpG+7nybiw+hUQv+99uxTiCPdmFVWHhpxleLYpGGDxlHXNYoHO2a1MUrq5QyHDejBzfqS 62fyeoIeHW9DE6oKVNIzqWINQmsR/TMd2mAWkkPbmvIyP1BNIa9Rh7ZREQNa5uSN1ARTvhKxrZ6O 2siP6abaZ5Ytezdlht3Fq6jl88HGbGNpi4hLjrexlKB+VVtU9g9yZHIseEYh7OqREjHX3mpGVscO 1Y9an0yqusZMTbYPg7Y1FyWxdVFfz7Z9DNrPZpmkwfi5jbu+twFr+9UBY2jWn+EBcwmvEnFLzKu2 Axpm5bQ0EsTqw5KUiItVevYNKahV0sO203SKkKLjKkdF1hg9PS7utGoLOkrMFWbuaHkabKLNm2v/ AZuePdUDJqa2tQRbSHDdnToSkDBwdLtgGEpf3oaZzN609ohGLNdnKCoMtC7JvjGw7hZR8lH2rUNN uKSHCaURFSFHo1POdiA6p06TKVa1zcF1wDHCXnNBTYJD2yOjpvYL2gKq8/ZkBcuo8zNGIFCdLUXE gtw/HVShs9JZqhweyhny8NheFa5cy7026mBAdRIhKx0Hg+8r19/A4OZ2mSq81Bbw5ejI7Xuiw5PC NXPUO7NqXH8mfpY3U7j2bQyUBJ1n++b/TyXuEU1bHaUTMjCStcXnKM0+NJOITNuedEMvpzZ9Jjzk 1rFRI6L08HYHRbvM+cGNasyQOmyJs3/ftv6GajetyyDaWg3YHVz901BJ0KeTmfwDidFv9F34KRAc m3Yw3pnlwFJ9kJVESTYs4Eri9ekXGlfpErUOY5+aTmOdcI+zjyxwS0zrozkmz9NbyIJgnxG9kCjQ Z1zFjOm1hBxX+Vfz7f38T4HTrft/dJPiK2SBs1m70KLLuHN3chNME1juQw3r8/RNQxnbiyKYdlBb 4x2myYl7h3aFncFt0shsF7RETKzah+xIbejAtsSgTHU8Ey4jPo9/bzDkqekzrCLG9NVCUobjKB8Y AyuyBgjM+zxoW20mO5yNjsXoKrX7yRHdixwL8obq6Ta3D5RdPNZ7QCH1p/ndgimpJZliOoluNeIw 0bENKXUntq3pTqXvRyJiwZ68BsDYtqY7bLUqKBaU1hrAgix1WVHThZeITE65+gUunnEPEpOy3fEZ Dktw7dX85N3R4O+EYfen8XqabYh9haynixc40ElXZI2pWLZ10PpzbJbgxlubYyp2gc6ZdUAOxzE6 gdWqidFrTFXZ8+RKmp131w96EiSQyFlvdvrn+wcv+v/NFEsYj5bTEhoSHagfLLGA1dqemiA21y/Q NUNkQShB1VLeHAwUJORvZs3cmBwnKLJ9dIPBOy2PFexi5HlakhQQDLbr6tiTvq7pTmUrIrVEDEbS vVQFLFu5WTaaThGyKrg+vQN9hOmSFtG4AM0lokj3PAxtWWZpy3eWBMOHHYZkKHDPslSgzEVXrVrE IiftihXUy7GksEAx/8WIU94yGlpA6PWWeuRG1BEzaZTtU7wsldrR7E20reEOc9B0KIjolFWv7UBG Zir5GVozqVQP6aBZ+rUh4zxpy6Kx0sAAbIzxqmC/yrGjcLRh9SbZOo7akJQ0kZpAXpXjpO3CcQHL TaKwdYrcJ8ET7mMbvWz69+5a5I55akIF+5IjltRe5igoqU1vQ1ChZrq9h1S1lv1KSF/k0PbMEhnP FjMuoH0a2kzUMrd6/cckOfVXDem7+xQFWWjOm/SZJmKojloZfFqryOLUC9El0mXTXp1ux/Gex8G6 4wyEZShRWKiYaov4PCNbrn8H66md7I1JJ1VzDQht+ficqGprmlYqtLGz4+U4IdvetZkqKBV6YsEz fWMLFVUjmuyX7awwUl3yM4lnfroxg3euup2AMbDlLZMTm/K0mfYQ73GObW+A251QvQSUbDDSMs1D eReqD8O+k/YMe6nPfo/YxNXcM2iytU4q1H/MBIe5ScQB6T7shDlP2p65Fbt9Yhai+bigltpvn4d6 Jyl2kqb/4f8zgfiPhPubwKFvXkNf5gxqJUVE6z3tH+yiZ8/oit0+tRMS5N3GZzsFPE/rUwcm3Zie Wpqxycibn9u+C6bfta1JD2vkoqL1tQn2LchrssikYL+A65fhTZCm2uHNbngj457cmySy6P/m95Zl Q460s9pZUj1ljZzQeLGX4Q1lo8jMqJrnp7KtvqCTbMcD5HToeNDXSKGx66dLRFm1beWDV/11jRSo 2aEI80B+tZkTG3AiNydYYo1ZIH+Vyjx237SZOTZ/ARgOllBHSTXqxyuicCIf54FoXofruuAaXz+5 aGK86KtcSDoL3kooecEbuU5lhLQEc3hDlmAT3hbP28j7Eest4PdWtgnYEN7WWIEZHv4i6/bd58kJ 4EGv+RnQk+q6ePca8DZVr9LQtqLcZqF5kgus2mkRs263j//NuNqxBQc0wSakl4n/VRtaUvLTcYte lTG9VHwk74U9+N1Tgeh13j193T0EC4bWkK1PKx+Up+o/WWIqY8RoCzmT29MB3UL98NR1eP4wMdV2 CRKE+N3zMFXM2dk0or1m3q4NhBHPOI6ZD9tJ6eZvrxUyV6ivKg76iTTJ/noeJoR02q1pRM14t4r0 OhMO1kibaKy9j9MR8HP76KZoLOf/+mtsysbAtfSIuZBeWZ/IndZPR1/wxsR7miLCtZ71Qtepij3M ARNUxdy5sP3sIDh+wlu94Q0fH//aCivd3oQ3/9w66nxqqw/xxgRVvLR+mTkQ4Bg64WDNschS6dSU p4Bj7bZdKJ68jZuocjBncxKlt8+rRIikilwC/XN7iBCG1tkidj7jqB/oJS72EAfk/czFxoC8qOb9 ODC69RvdmNRajEWUvzrGKmOg3sfuyHVrwsI7f3F83kTrfBw7IkIc3dYYixAhufXKaPhXx6aS4JjR 4eAhQqhNWMhiZ3jzeSLx+Jjfmx8fRoR89RHw8tn3dKJewUu3Z4pFoolTHxHtxMfRNpQD46dnSfiY YUtpGrHY2dNnB/ul8/gsKoS4U0pPxnrtV3vTo3Wc5Dn3f2vnZqg54pTEi7MTrGfn+x2Z8YgrvpPZ X/Q3OQqSJ9+sQc3MSqf6hxZwUeGj4wIDknmRrgEjW1SQFtSntqOBz0S2RSIqRmrxH0QU9ltqBbWl t5bXvzZWVWeLKHZznE5IfeQ4vTgd5gpSukYENt33gbuEsShe5ijuMB3w9XiTLTh0KC/pOLt3/Kkj Rl96l1CR2sDBbU2wiDZZqj9ORNIgXTs2FV/72ZV5IGrViBOfcRwn6uIcrNdIQcnEJ6iWt46rkrLt pkSpj9tXTAY+XQUx1v65LY6K+YVp0YhiEP/cOoIDlbIYeKIVlZxCBhXXU62A2yfdSTBKF31qaYwz eBPdRuvnwJfpTblRk8qvEdF8wi+fhMbzTfOaxxElvD+vsdzlVytR/8NBj91rWVIqsgEcdaO59PMD KZ3W7p6UYVtIf7puDanGvXDTJW2hw56WQppxpyuh4ZXfPIsOZX5uQaUgfvNkHOxb1nSECMOmZjyi DtE/NshP5ZRuepd6VUqWgJ9b2TRBG6d79OvQRm6eoHVOPvYd2SM7gK/RLxEl++srOWJZLbkAswZ/ mrkxO+fvPwaDVyk3Oy5EIE4PhzvWggjDvrKkiAk3o6bv0b7fweAmq5m3oyULmQgjBr03/e55ZglM dxRzA0s/DUX7OrjlBW5/1gKjfrogK15pY9VtbDDP67bf9zg/rdvUPv9N3ZXtWHYcx1/pVwNyo/bl c84KECYpA5YN6O+dWXUsXogRA91BG5U9T4TYFLt4qnKJjIw40Las8g9m3UZ1UeVH7H2cfuwnyjxS 5zzoO9NqsCkNUvJ2AwrvCG8xUiNcdtVyWCclmi/fb1SCPmMrchajYyspcdDar5Y4k/9BagK1j7PY 8EhBHRrOoWOQwIQ3VZ/O4HFCrRu6bGqb4P3wL4bc0G4z54T7OhFdQiq2NCs2cttiTM3iHEFCMaKK S4nzjOEYFdlmiZM3n8EamZQ4aZY41NfCpB1MPM8TyvA2P0scxv7gJc46mVfJkglJv+ehWdsaW+qh h9G0u0yzNjTEA8tJ51U+cyt5btq1MovKO0eGhHFozyjxAOIe8mqygvFwXXElKbTXegA/GE2ic/zG BHizMuXNhYHdR0jNKbU9016mrJWZQPLqLNrQsq9k0WnnyTjVNdVgENSVwriBLCpZp8ysQ65bbs6i 7GZyLSPyRx4kPQnU74qLa+nzo+NsIbp4/3EctQZyRXri/oUROxzZo0q0hrkG44nTTegtMD2qpXJu tVa0VCoxbg5J2VeKPRt8QxLjGqqsJcY9FAPCoJLC2hvsFPqxV9SXRl8eYjXbs0jRYueT7p7A82lD rFJj3PfCQrOLG9i6SnkcxzcGT7VYg8GRfK95P2DB4+cYjgoLN4vIe0w+gmBQu58rfp1Qd2uPxWCo 3hUixPXbHGIHQgczumSxHS0gx+I8dkY8mfOEniTzGFQOTCEhMqWasc56h3J3cWMa1L7x/XonxV6+ sN7J11XQHmYPynHTIpvJC0vQMNiiXtld4BEFidUDC3kbPvjKvcV3P47cgA1p10oH1MbHYRQ3CX5M bW8tJWw/AaFS8s7Dm4B3zTefPVPQWEtAzCXB2trPQTbD3YoUo/a+jtSiAd02qUUnuzoxKVGbbl67 3wPekW1zME+keKWylnrI3nlybxt0/W5zK4423BYZiHmLOziM+qjNUMD2l3uxyOTvNe0Rh4I5j2PF gSrX2TvO7rcD78e2OfDhqrW0tF4qBuI2JGdQuxLctFOAjU+K0q86fJy4UrV2SzWiRQsp2iYjjNFA QikWkdF+bAcSsY6+TrpronVOt9j5pFyQqrAEtzlfpInUZ5Ns5JryhmGDMSdhEv0xdYt01+s+d7BU OhCdRHQzJKw5i7Z+aW9o3VdqgrmV8G5TqqTeZTWBZB1opVJqnwMsIiaca6Gko6X41HFcYN9KHSI/ vWPOCfqnGbxqoW4VS6XH6ZzQWJCWpGOy3dkKVuavE3pn8q4+R4s7FvW+kIROayq3KbeNKM5IrUBm 80uF+Xtx94VzzphbMRuIj5otCgJVVzwggkgBmmYBiuN0713tyuBx+lIC1bYBgRYpcOYomz0do0rC knigyY0knjlVZKihaiYbrHBKqjcI1XEMRpSnQ81XTaq+5+uA7FBpdyYRhBN1HGO7rjyPPIIbOC7G 6qZ3MSnaJNNmppqxFAY9NhTbNJFOEn8i3ahRC69e49Zh6gljSkq24T7U/cbgcfK1bwgGldczycjf zHCx3FcF4IeE6mGAl6HhlQ89ZUewj74ylaYaAhgrSiqdjAn2eIwKOe6+QwMiSaXPEJv6qwWLI6t6 nQ5s96U8Cjffmai4Uf+hduYMjhOUzjebONIm5OCjxRHc0dEYQXPPM7NinhbNW2ziejkcbnvCGCkS 3VAtDiweJ28J9dittDnwZV8nh2ARp46bu9FuQlfEwMXE9Jp+gOsutWL2HRr2SKx+BqSYDxaKIxTe 1XswB9TgbiV9hiDfh2i6Sm1A3s5KBKTmq2PIoM06B4aCrMtypIlLa8kSMSP7B009I7KxjUXfvUFA RyIbGlklxd296+l94651uHs/zojUc6JvU+csUdau6owb/DZhB0WOZJ3JLUiMA/bhLQ6vJUxDZw4J 088wnlH0bI4T83XuAP6QhrRMyiGbJ/6AZ7QyjUqgjqAGrV21tDRQw8jmXS6N6batbEh7PiMJ1HPa y15P6sWgdL0aWUDH1Tb1Pxi1gEfqsI4Qmv0egV+kknJiiSyuWX039x6R+EcPebJbqU6TTXXaULcD 7PdpgTPVkBsTbevB4sxq9w16pkjz9ozjGUfPyU/bO08/roimPFLmPCwjlkdTrgbbnbxltDsmZc7D MiI1aB5rWOaOU/N5ARUDSaNhplEY3WqLyROkTdrxlf1OuBtGcuYAm7J1g8UitEhJDaj7cjAtcgon syTHBtiLYxtUepfYNie+RJ32R2sva2PbeSHYXWLbQ2bhBGSLSFuSx4IKndIeggEJ1al5i5TDmo8T lAYS29KMbTAYdJdGuY2OU1fGtuj3BjKpVjoPFYywKF0NzE1t7cQ3vO5ZvcTqOCe+DM1JJhtsCW5Q SVyC25zBMX1ao/pGEtwadsJtk2BAk0/INrHDivA2CW7PyJeZ9JgNbg2wjXTLegY3+HpqC8pKtFe4 hXp1QP/IWhhIrcmN7ioh7a5F3SWVwio0znkiW1G06asY3ZGxB3saDha+489TilQT5POsVKDad1fh Sl+arr4dQyBqI9lsuhRXqCQumWdOFKl4sE02SzrrgaS3dZLQUmVMMJUyMjgXqXk/wW68BOpnogiD QWmSRIkaXV4rbeTaiau2OVFkLY8U1gaL0GMLJ6bm5EnNIXImJcfAJGrXsgsqlNyVWDDHVsxZsctP GMw9IbQT7cTGaYktVSiLBtFZdCyXaBDA6ljt6RlbweeT5Os1wkKOXye0+RPMtpTqjqPBGFs10iMk VXax93Xk9TgkxlCan+A7YbN8SI1qMbpVaXoAoCO3baK7ZCUhqmkHCW5Lc08Z8h7otg10l+3Cfciz Mvh18tYu6NXVZ0fKGmyjHenuy4b2yeXxPOgumZQW+ZsGy1BJpA7p7rr0Wb1n5knRVYsuhBIJPNgd k0gwsVDSYYcmBYNB1bZefMYCm2lgh41ti+hY2N7XyaHvYAondyl99hgbG5F23wwyXM/ruJG6WctV vtDYrXyT/FFXrseXhBaWJao9sC4ZKRZnUodB+reYYA5NA5siqwi6y8PUwJa+nBgLgEFzUhKll6vG Joq1sB3Ste1bRn6XetseKIc5wLhkckJa7hORw+W2DbSg0XpaXaXNHSf33YMZT/B9ej5QXWeLtlZp qzs4TKtuTnszqaZTKxbLNXk6HS0lydN5kA+WdqSSMNgdyNN5HfC8Pp3ZWjPXdVeKwUiQ+xHA+E2e zpQIpbKNFnX05K4lUK8pQv3gBExA3LdmEKOWuxYwjJNmY83iWk3R4HF2ny7gFKufZ3aiTApM2aIW i5x+3wDGkbczNSgZdd/k2+nlep2HvNy1PFs3RvtoVI526XB099dL2ukhBFf7Z2/tsyW8hDD/kBS6 cggvR0EKJvpuZq9DFWZsGgnIVasbDGt59jos58iTMhjWUvUVp9ApO0cHoxarzy14RDwecis63gke 1zf68SzWN/J2OvRIaWF2blRSIrliMK7J23kdVL2+ndm5sTmv/KhBHb3U9wTAaXk7cyGJLsJafDvx aPv957jWqtKLHHs5Ut0ki/Si7fYbggvl5czGjekV/MCvb+3LOY+Os85o3DpXoLR4nDsdESsZlaED FsgQUXVdE7luK9lSyZ0XyqI5K4bT+k94VawrpuOe9xeS7j+qzz6qT7pxbbL6lBCNfDd092OG6O8E rtWjH0gi2I11ay1vmHkvl9pfC0xfCdoktTgRD7YGazVIHxfSpvfy6861RGIW/SE/ZlH1OIdYkbx2 DQ+YS3qDVJzNzu18Ja685tABSBE/yJF1DN62eKUdaGkmxT6908Hau9vwK7HP88LlWnzANapbYnLP RdLODRiTKl000877wPQ6qQJ5N680j5d3Uwa4RtisH0Y3D4orN8LZhyZocolJ0ErpyTROVybRcF8B 277VMEtpYnMrPTejS65dPDg7KHI0FDx4IStybGrk7LskUgQS5LlI0ZkKi9FFiq1GJNqqRc6zwke+ j1GHl16OHVvHl4Hn0jwq0c0gnluiO0A4yGPpTbkrTOmD67mvbRHOiBSmJBo8COj3UsyKOV4I+Jjr 8FIXOEYB5a7XS7/Pdle06iL/9duMbrhw8yWZVP6RaFAwB7QMhLpT+KNb3HSpuWXABq+9PVx9fNtU bJ91cCuFNMN9nqg2kFrngQ1xsA7RR4u2o9fdkTCo+kMPX2U2g/eueoPsot0fF6AUaLB+QHeafKyW OohepDzCZ0+M6e1LL2GQppv6kcFOr3Slk/LB2F8mUWrJPB5ptPk816o6kfrw1WeLyxRdQjXmFZQ5 4WFItc0d2LpvUMbI15Z04drjp6OGN2xyvVJKs+a6AShUEumz6kIwEHXpNMg5lkjdwOaOXLM0kXe2 JuZ7soi8h/so2FeotlkYkDJUbbsMGvHI4ymA+KHB7VGTYG2PVdLUnoGjnQa3Cb1zWaZksMm+U3Vo o6KFqrrHLbB5b0ilGDzPVkNFGnpS6EzNuUxUwLwvNkcj/gYYlc6xZ6HzPvz+dU3226Q27240VZRM WjSTBraNZHM0EuoRkFCOClOOITYRk/jwxWrTE1DqkVQ6R1ds5cUoQiWpx4OhvKaeNFMPaeLUfMPg eST1OGDdK6mnzukViQVe4p7BHi7cZ8WS+83NSoecRytRgxzK665IT1PyvuK7vhOOgfwN1T40d5zd 7yeWmUpzesU4E0bVaLeaL3SeOKyipTIoOLq1pk/N3nmiuw5Q6Wj2STP74MotNpdYo7BSs2DfzgJd 4/Pc7aW7ykYdO7O/N7AZLwcZhi8OC5uZZbj1sr3CBq/JZw4X2UpfNbkOe8dwIzna4JXgJvmFieXU EizWohKt64VrtzldJFbrVttsiQYOFAcaDeY0jnwfTT4Wl5O2fu0oWktrM/o4OptPzNUufh0Z+X0a 1ZYTLkR1tNih2+34AsFi37PVeEKd+uE/qpUBrnSq7y4aPI/8OzKARINOC+bbITwqKVItGnbuIUJM R2LbHMZlSq42aRYtCf4V03l9PmU8H6bTZnM+EurZ0WKCGxCiFqIMEs3NpGPnnl5D9f8tjXj1SGmJ eSvP38Dc1si+7RvoejQWTPidChrZrKolFiCJGYkF+Rn3fC96tcSCLeJU2kYsYE22b8w+bS1LpyRg zyW/69RvpawW5ZPbG15tdcNO3sM9TSsD5uRt87bJb7+DaYIKt06WDiO89mrRImXfGtxVlOA2AV6i nzVim8HXs4dwYKX6/ADwjDBu0wxOgttrNHgJborwSnCj6xY2tQFj2FDd5opak0c6i5OgaHHnX4Jb QdsjcRgmaXBjo1+OUC2uQy+0qeTG+ojUocxVtTZnsS3N27ED5kSruqukO4vfrHLbWgOlgQbrB99l 20rVm5wuhlCwlUB+5iPfi8/f89Gw35gyrCVY01InNIPRoPjaAF9cCjd5Pa47dtt+8HVWwu9Hq8jo QYPbnPYw/Rx5VyYxnS0gVRONBg++S/o4P3jm9s4T1DkMRoMHf2eE8ZBN1jq571iZtk2IlxKsC1M1 WYrppHgjw3WJE8Oji7r1GV0mS1vZwXWT2mDaLDN5hpqqxV2leHoHBDbbsCJ1jmXSjxibwcItlnQi TqUfl21IuLHNuGgx9+xbPaGsc47PPIGZerdoM1b7HTtx5DlPKO+roq9ts9sdcKye84Qf7FsYLA1a qhHH6jqlD5mWTsshG9xQyNvukG10LY/2DKtEjWKIMe6A5pbzsI3One2VGuW1hHoltEmmUgfjtmEU xOdSe8Cojl+7bxEdJr3GZ+DDNv1qtIgh7q4UvN9T5sCH0PY+eqTuL4tRN4fEt+MQdlXU7Xs1Pj2f DTgTa/KZAyw2/JXkY5Cnc90V+UanrBiiknhJm12dtyhTm7ctAUq/5J7HQ41OS42ywuIOvo4Gt2fg Q7rsHGo0GNy22negOaHBoM1gQF6PURu1rjxQGAz6HPiwDQXpSi02crFDVWQ3NhS0EqUqlSadxyS4 BTBRkOCWZnBjoo6uWUSs93AcuI+bRuWlfDPOayo7WI/T6DYnJFgaOcTqHZv4rGT0SzR4La1fo8Gc KHCNdIuU8esuyKlcR+/z9TBd8ZyKwfGvvJ6CnfvKnF99M25Li65cf75tWarTz+jpXdP1uP9v2t5/ /f23X3/5/T/+xYMUBatRg61qIL5od4drAl/Z1uLKpJOv0yE2shuCBgq9M/36GFiUXnmeulUoDRR0 qdSp7z0JA7GY9PTeakP4hySdOYjrbOk3F4voYS/1lQXymnTG4IrI8WsJajFKp6OcwNM7qBp/o9Ah 2/6X5/Z10jNvb//furwDE84ckTK+kQREZre+tHk7LgdWrkLwQ5A/BsZu49IMX6dI9+7HKddWrj/f sxKUzMK5RiEUi7zd5o+CiJR+2AuM1EO0HBvdgPk61eqfyDk9VuiepDCBT9SVuIYQDIJsknMCYupJ pTwHikS/Xt2xLcI4ObgdUcF6HZ8n00q6FYs63LG2CCwIQ44j57ztMxLXKc5INdAxqa2P0ahnJr4l WFy1kp7NY//r8kyuyccxakqct9MDPLfV+sDTDC8sJjfH9q2caBNO4tqcvTF/AaNwrpygA5O7kPMI BGyywwPBuuJTAkGsuC0YYyoiHyx/WjHIKbjuUgF9MuX2ILkkDrSuzZ654+wuJqTEX1p9hrzfyykh 3wGuxKrkYSwxkqwjMZq11EsRj5xvsH/dXHyW+lDf5l3x3RHhnLZ0qa/tG+7b4uzb3pbUC1+Hsr/d t6UD7cbLFVM0SrWN3l6NX0s1LBX6kOYpOsW8oHyJzWSBs28RFGyttrnDw8gr8n2aQRp1L+UEzqpe ue8ji1KYQJe2zR2n7qEjblErIXwmbbrfnoAsfTxhh9vKkkWfeSgrp+VnDWbR5rMHgVryzmP5AGNb 9VX+SXycvPLz3LGeaHBQYxqSU4GtwyapGEyiOMUjnq6fgoeJMkGzVN0GY3UvfoP2Sd6NcTXRLhjR zWCLoFqhyJ9HosEz32UbSUYHO71cQIAux1I+I5UAkteTDCIFOQYHZiHyV4oYFk8RQ76BsDS05ZrA XStR253EVvlMalTvWz5AxaZR7ZmHktP0Rpd3FpdsAdAiNKrNeSjTznLN4qaY1DhQtECi2hwiMqOh KiWowfMcrSH7eKUYTtECgny0UFQNBJ6nLi0KckGa6D7nZ7RDa2qTnLxe8plxUTAHCCy2+W4xGsjz gdsH8nzmAKEytofN1bea9g4UgJpLDzSFb1vMtbCyYK0GcvbYYTU/AwTYwXnXmmc2XSuhNnk99cTJ Z6LudITgTepNubQBEQZ5PW3C1JVMEeS7WUSnWvSvaJsEgahhWjKPUt9pRa08lZ84yxaii/cfZ/FB /ocSaow/ONRvf/1v+b/7z7/+8vvf/ulQx7/9Rf5t2/nvf/3917//5eM3+am/ffzP9usvJ7mL9YAS APK4BuzL1IF4lfqFe37vVqlqrwqQq1b73P8nirUqJ2xxnCVxIiSYZf3EFSkkr+xRc8cJt98x5bU9 O6Ww9fY+ynMksO9Ky7g9SFMEq4Y2gcXKcF+bunR78icpUh/kikEjNs/TS3iNBq/PZyJXjPye5Afs HUeumwOsEL1uE7mqDB2x+Xma3xLC5SUOlMFGJNfNu9wtrjAfvSBhOj3IXIvDTYT3uZREyrql4W1L O2iKNBxoU5Qd1rOXSr1lxt9byn512w6A7Co1t9R1AXes0YXEHs/aJbJ0QCEq7wd+xTzjVA7EYKWz h75BJm9rD37F5DNsuiqVeFwgVuexPeKLi6wjqsHico+EggIWsiUUDLUJCQU4tDnX1WHF3Ofpx42A eQ3VE17ElZtXNYNCrltbGw1qxI3CgOMCaeK81NUGAYW6h4gcF1uR55OkmaM9eOsGCwN5PQ4bmY+F bHk9xEhFKrpq8fWU5IEsnd62AV8FThq16Bi3+xCQp5IcdGqIktzTFXckn2dlMNi3mLG19NhgluvG NrC6s6i5WbPzyAEv+OH1G9mi7A8Qqq/7PG8TrvNxwj1MHwakw7bjcnIWmW/Zu1ez0j+o8FWp8D/h wrzuy2ybKwe4ZhrvZhggI8eePCupV44ct+uKWDZj7JVKGMDvpqbuLG5kp71cSLOp+YczyqJaTM0g TSydd0HOd1k9leQ3pnMGHtXW0a279DtgNe6xjZSoxkJ0KRYrguCuCPi8IXeNalhu5odf5uuWZN+e iBzXAWZzzfVPuWlMmkWuJ+pCpXFdt4rd/IYGVd6H9sCFTNw5BgYRLN23OCQG4J76gdfw17HK6W8+ HaCnbk6rTuUc4GIgtUo16L7usv1MV+ARLVnv2RxWVTasarGQfLMSzZUQXTbYtIUJGLJ8k2KzCBj2 LeNZVX0QKSbhaBMwjCm/SjP8w10xx88emcyEyRm8XDQPtmP1ok0silHDbHY4sd6vCXR8GKW12P0w 6ZUBQkZVZz8AItW816rg7a4tf12f8+5tO1RZE4E30c2hGzHEllPWQOLAUqJo3xymutUHK2Q6WsGk 82UvciScdiZWyI6TSjAYDeS63bAqiG4ODojkTMgpB4Mz0T3VggYhfmqfZsekaVPOFmW3pQgtsN2p z24cLNrUQVLbOijOsFLgKB7bCSwsWtfVuIGKklRaLKZSiQXFwcogTuyT7WG6btFKLW1b/efKYJRs WSuD96HPhRJ0qacL1ThmT/Iv1DjFB5RJvdqvtxzJBD6W7DK+bGFt4qkNobmSeOaQihj3+Rorcx5b SoFPecMr83EihoSb56VJMNiO9nCdaJ3MDTebGNh2nOQri/sj8mt5cNskjZaRRgm7SLtYhueuvGxV joCWF4PvY4LIeLomJSn/l7prwbEkx3FXyRMULP99nPje/wgr2W93CttkYrNQC6sbGAwwkwO8mAjT EkWR/Wo3rqjTJHISo6dT9hi3fEt9wditi3lUs+rTJfFxHEEyhug1QCR5cMNCWYkKZ6eO4Hm1BQPG 7jV9jN2JWWjQztqhqEifBvkb6blRSBPbsvzZpyZ537ztPMYDDo30YECQ6WDnGw+6fedGj/qJECBM m1C9bDCDk1vM8v+Ozn+S05dvrMVLk/9kLmciBt3ujs31jADm1JKSLMvgH09D475P7XnLBaReuU5T d4U0snGgNbTH/bAS2wuUXmUulUsN1J7aZw7P8Y4Bw7xTWCM3EmM1Qs9MiLeTy623PAnICKqZ1Hfm uP9N0bnv4GgHcyKNZIzL1J0Yh/usoEd5nhMj9OSkmTjfjodDHurWN4GaNVEk6Mx67isHbBW8U+Kh 7eM5EKPWfo3ELBj4J1b/XlTNH3xiAxx9S0OZVGdigqiUPPoypfZcOQCC0O2L+T8QhGP0FwgK9bqR NcvBES/WK2Tmgr5T4aHFTQOzqVzzMj8my+/6NhPxBdzsYfLo86ArZ/nRsnAHn/fn+0IyugfrQLX5 /HnDthXc0gHvzzy520QfpieHH1ps40LR0GGaBRsO4C+tWKK0wzL6uXpEB8fsJ1NNxENPJGWPdppH LOX459tZ8/aaApkTpEJFknujRosAuYpi9OLUmIi9NnE50S33A+bThgSLi2Zar6/u0aBEYUDQ5lSM ywvnX+XY2MsrA8PaoqMJSdh6L9HhPsvz5hOUa7aYvI4Ow7WYPW61jWKpKPDoLJqQGQL26jHjRd9O BZdOrtPfUN8OGU+HXoNDZm2UfuKFlrwoAipVsWVed49zai2NgjcUCxazRuwntU+NRBe1dTR1tAGd l6x7XgHx5P04DenV04MyE/X0xHV68MUjMVWPzj7HeVbgfqH36NrYZdmplJT6myq8n3c7x4WtTsui cpiLlCSP4Q5H0+sddKJ6dPo6Oszky2em0B3Kib61kOISgBMXKW3dAlPkbjX2KYdgz78ym+v8jbGP Q3nH0d8bOcc0E+TG3smISvro2WGC6tHaCwLG9PTMOifRcajT0/O86QT6b714Pv0oqUJzs3Pl7nF6 eSpKUFUwmJRuwj5FtvMuiVC6O/XftaSTgMHsr5k5q2gT5/D1PC0JKNvyzOu1r41UbaU2j6LPEo+K ZIXBbh5t49jszWnQS+qjgbTBlb2hXTRbqMyhOkS2o+UbmVIrUueF1OTsJH19Duu2UcoDksgNCiZf kP9dpks1yY3MTOfekcyIHrK+WzyyObc+EJ4hxLwuHrIXFnJgSL2zznlzOUDZJj2Z12zskViwpaog Quq2nVW11jkFoEGu9UNPkaZHryaPXgtHKx1pWRXcFv/BHPedJioruKUbg9uk2zK5SWXk4rDOqXF0 ENdZpnGu1MDUUvp3LFxoq/vn1Q6UPqrgVhe4YTDoQf+UfG1bnbFaQeFCdnoWBcL2QdyennbgjZA6 GapMDfKMsnf3OC23inyng7bYdt6ZLU5JmAuV8PekEn/wcvRCFLTCa65FQZhXphYGHhvsJvcADbaZ MAWTgyeioP7K0slgRHa+nVsbaeTCptDWF7QR0z89Vsxqdi+0tQPs7Ci01Q8/RbAgScsOu7hR6sDh o3WxoUxqJDk47Hq0DA1Aqqtl6KLbWE+aW/Ap0XtR3I70LJPdjczdo5fkceqrpycDlbudnrhOD0uF 5GqjzYVBwYYLddGH38hzXJ6eeIBFMQvwXqcH36UK4pbf5+5xeq4dWZiFlD5kNb5Le0uVKfX23j0V eePY6fkwboxB7NXjwqjePS+OD6qLcWMpfXqTOtQYpD5utJ6czHwljMQSQ7I+uMM5qYJBAY9jYYML DFhqfE/d5cdmEh34sS0GhC5YJY+jkfO8BqYM0uJDBVc6o9tQ2KPgqCKbOcO2D2XAwEAbU4dgoIDb AL9bZtKb1MDiiL9hQHYyVArVucHT0xYDwjQ6erwcdtlaGSSwLaJvx4YjVXDw1lfX08NmPXuVu/KC waJC9afrIT1pKS05rNuOHk/cY7dPj82+tl6rw+eJ8Xhxl9Bmj1244ohpQ/em7TwXFoSlRemQsbye ntAc6t5PRTck2KujfWIfWReXtAP393606wwNf26zKS1M0xKGR8fJ9sQDYHXK5ssWUmSE6DeE294F JTlAcry2qmtQyhiQGrrHSVyqel2im7SGdZPSj615FFb3Ox8Y23JY2IZfTynd0mHdfW1nbyf42vRK msZsmfGHLnd8tS4omD1si/+gFlNfxeOsJ10vGiv2Mab5LFtQ+srBJ5tTRsUtwmRzyjf6KYdVTrvK +78dGdr4ZexHH6S5Xj8TP8vOIdwZOxRVa4XTV4XDutHaPUoPi9wD5sKHj7YNvx5tyqvHGZziWsC8 bltiI2Kxb/8wDf9WXCtnF1DiZKN1JUbSXX+1KGx3bKtrVgw3ShfVmmCNEQSeHgk12oTBoY2JZLDw rxXosjFh7U7J4lFVPUq6sdlUm8Qu82gTcSltU6yGAgOjRxdWE6K6xuGxoj6P40UBCDFNY7NM3XR5 Bfr3HufnFagcmKVui6XutMhpHoOTR3srMJrRCtR6a6HbLz5HPK+88FMry4CWhjlwC6B9BrTPG16g m1KQ/lC6rGIb4rE56G+NF2wO+pwf8Ijh5NGMId6DhAXkz/QNk1LZnN3J69lpqauXDtTl6KUT16VD SDanl056agNZfE3Cr6hVGylwZAir17Y+TBwVRSLFlNYNyu4c7uG+MQmlSwYmM3qD9jXboa5zuXkM crilF7Ao0qN5g7J1y2+MG/fFc/e3EFvtvqZUhJgu+h06HLrVfJxAIJGyWR3bYgW7QEUPnL8mNOWO spCqZe3QTPv1A9zRUXe4YJ0WprmM3p7EkD71KixScK9SKgxgBJbr+Ix0CAwo2HmcH2qH8wKnKYPo JdLtpFjT/yI6pKO09ux4x7+veSgV6Q6PEvdxPBXsKUct4H5FqYRml1KyOEwO0rOTEVdYx0dlSKe7 Lk3n9OwMvDfaPyMqtk/xFT0KpZr+elCulWJ6falCxqG2mMja0J1Sj5FNZgihYM2oWFhqy8NhV60X Ynn/eXj07dT1dvjuW3coMmxXfVHeoygWTEfwf1OR84ZWIcs+FsvOZtWpVo/ltAJbxiu9/TOjYreo iMs4+PcpGXxrZfwamfGe33DS+8zCX0k3WNqxanrJ8TjdkVnaxs5qWsu1G/u29jXPYU21xOIRo88S Dghq2UCNPcyXS1A72vtgz5/+mX9QkLa1cncv55Wacbh9WXIvqo9q4lErOfQZcCrKWDQ7C3112om2 dwCaXT+38SEL6fERj/uVr5QHB6KUpSRgAd1+P7eIcyrGpAyZx5T+XXUI1VqyCZq5tbB6USbDyfo5 OgQ3PT0JZVjq6fnwONRYN7C0t82nZ6DYjTAN5+z0sOep1WOs2Cix4WZ0TF6KqNgM2jx2CHcrARnR 6r/PMRXdcuFjqn1F9dGeByy/2tlZPM5g7VsoHsdUenYS4KXs7CzKncpwnJ4dM5bDhc4kckgUl56d 4FHDpp9bBwt89rmt7poaun/l6JA21C6nArlHzHp6bLufVNW2HeuxLpD84HlVWR02Sxz+quJRbxzj mbGd2ZgdNstI0kf1KPvKT8lgfy8FW9kJqbKmx2lI7xvqiaaJJl6ZVSiBthLpBtJmaEtgA8mgbVEG g0omo0fJpIJBxxnKdVEGVI7jFgxeIJWaMv0JBmTYKyV6nI42PSegCu1zCcmy7uHb0To8djK7rlu/ tnRlMOExWDMDsJpIFKTUFNkq/Fbb41ArGvc2+bTYzBg06f/Q39d2tPsGQx5JOSyCiiRb6j+Zef5s JavzmdHyQW7mvGC0DpOy1OTRWFfBOmGdbl2EW2LvxyvhJldHlEEMi3Cj6gKXwepdUgBtT5+bOwbW 8O2Y5DgQA7C4c3J154To6hjTTOXKjND5hgHZuOrSMpK4G7Qt9nAwyf5XZ2X13rotdeTOFqZ5nkEB ex6nUJDPB5rnxbDYQza5kuZxQURv0g64d1k2H/a5EWjLzXZh3D3P0JIGuFLb61kEFZv0pOIyZazd ETSl9no+BBUVUbpcUX5bCaAONTT4UDrweURSqVDOkkPaucAz8p1JF7coHTrq6UxRvXcSVwNwQc8t ftoEAgbNZ/DT0a4bfG2ylhHs9FDZRE8OT88p4cKTuPbhQKhsojLh4d6spGcAo+BS2tJRsjBi+xId MogjX6/ALkEmpcMiFG2v1+HX1p6Rfvee/G8FVYzVFFQM2eYvcKigihdmDOTDGHB5W3JYVpdYHqyg ap8O+98labnDNQC92+P4VYb83Kvg7+HATxu4JvlFI2yZcgmrdHA7Wkpo0SGqpZgTKtliWlZmzI/6 m5ezb71fIXrAEVyUSeSwnIpYhLk3bw0OuNqF5AVzPlozk+zO1WZ/T5Pf54bpYpOWqtQWw+lA8Rn2 wwCpK3pwUuHFJzs4Uv9eq/NzWkpQALHdnx+egHY6UhyK9BQIMvQGjjJpHJYzaKFbDh+nSclIcyhT Z2SXDkbpEntnayI7z05924Oc82QKxO15iNFHDTmQWnonT3C1gmJUSx+r0fnxHRr3afTKXVnpuTRt mZVrpbIV/61Q0IMAI7PexnQsYDoJkyE5RILjbR00Oj2JFdLU7sehZcnIZ4cRaVEmlUsLTyksRWhv x/Z0FPLU4gp5YlLD0VNwWN1ogzlgRvy0ZDMUYDHkrbNSeusSrJQDzd1kig3txmERaa2S/be/OEX8 kxunw2zbbkS73vrMVqZL85kpliPKIY95mTHRmBqPFMHRzgu8Gzszk5dOzKlVP6nq8M5RpE4wpSZK X3kOtJjODr+1dqUHMB6l5V9NXwC5dr7JuN7bGVwP+tZk7r4ZXJPUEK1KxWHGdb/kABsIqdfwKxYi LEp2KzVSSe/sC442Asg9UCSIYSEB064IDa/biwTHDUxyxGYHEwnIrSOxejT60Bv0OOEAcQ5E9fWw fZdq58rd82jRlnAyZ19TA5aobhoeh84l+rl1mH0Q46JzucWUx/H70Y8XadxjXqt81KORFzl/D6p/ WuTkpFCNJMdpGbEwHdsoLo0Ar6O+cIDY2sqH/3EBGvcVoLE9yOXYcGAJCUiuoMTRh8M5yKE9MqIL Fafzwmm2TTGvJHfPo7gWb3yNLnaa61Y8DnYUCDJIRtOarc6ajXXWPjM52xELGIVERehfIxeuKXIp jDhjg+HWLeSVUcMMs6Sk6lBT1OTJSDEpcfU79BLV1iE7pA3Tex/AHri1Pi21mXGeKMj7e5iRxw3D oE1TNGORmGjF9CzuHqdf4XcO9Ddcy4ZrZA4itQaPO2JdjgMwuiJr501baILT2tt5nCGeZvMBioIW ykp0ob4yOXicU2mRc5JmtK4ih3c7xSFSl3PcoBntY6YNx8Y2YL9yEp9g8LyQmOqzyKFm1I3p8XYe njtcGW/w9bW2Q9Js44qvcQdu6al3BNdoX8kUNDCgNYdIoNdou3B7sPh2ajcXGKW7N3qrJZRNoUC9 UlCY9YJeWR5L0KK/H7FsMa99ROZh5HIK/9aEnKiTuUuJcBk4FbH1ujEEJVeUX2kAsG5QhgPFpeu5 dqIhgA9NtHWzNHKaAZ1Y/bkZ1WKGzUEKK4ePThE9KvTP+kY0gA/TudluUNyIStT/GxxyUmesD4qn UJTOC6XZYJS7nm/93M5WgeyraX1jFQHLP8iZBYltLT5r7GDulnqbU9FMwilCdVkQKE5fwExGcTqt qShbCInZpVPWyP2CUakxzTEVzxkeHu10FQk6CttQJKgLCVhQjRQmZdv6ud3HDVL44gywtHrtx0Fv G6NSFdYEWFE3vXRioqmvk4Hz92ba205QsOU2xzoxkMCqOrKVme4eR3GgQZvwmPIKfaQLoi5d3GsK oCJIthhmua8/nVZbguq+ieiLwrmtWltyVjbfNc9Nh63BqVc76ak/Yx26yu9yVfzoRW7YuqWlxKGZ OzOOx93znKMmtEQhSx5RAmmsY0/Vo9Gx3qEdhqWWpc+lrkU+79B6An/91ufMjbnONnEZfqCXjsCw gJjmzI2Kir66x2S0foXfJWy/dTpr5sbsimoZDlVF+qs70BL0VH6V8QdxSPu4tVpOFDBsHZn1bK2w cU4Mg72Zv8d6/lGTk1DwVgv1Mz2k8U7Do8GC/qoB2LUeo2JaYtu7xYL7/D3M2WvBNlJj6deY93SL w2MqmlY3rWDCY+nXyOJe1OrU4wREq4GIqptYlpCVupZ53NYZqTbsGZHmtI2xHWbI6LDy7Of7FEgV RrtAaVzIl1SHT3PGcqNkNIXpz+yQ9W0+uaizvh2MdHpqVhD8uIiOf2/m/uNh2309gLtRDPhMQX++ sdc3Tg4bqtMMoJf2RjCiSay5OvzMtMOpEbCEYw4/qJV+Ch5zQkYMBQN0XoNDtnSULbTP3eOkM//u kfkf37UWfvVMvbDmL3AoLy7Qzljx+TM1ZLqoEIPDMlpvzw5SUvX2nCqvzBwLR2UwsLP9jFdGhpL6 rymWznqwsM1KyNT9d+c6pRadBZtNj7XfRpZ3JWQrsT1+bSnDWm0uTjANXhb6te3U4B02/cAc7pLf CCkJ9O71yHmOXAqQf9u9s8a6pMuxiBCH45wz5hsZFypUf8a6TFbok/E4pHXsUDKWhJU4eiSLSiHL uztjDo5ekT2eLe1+VBHk8tE/8zgC0XbmBUyuHZ81DWW7LbUWh5+bHp+GsgT1+KyJG5N9fpMHv7dF KCdw0tfudLYIbGpQs8d4qn4+HWxRpd6nPqoQfVQKxSO9lo4zoDInz/xn49rJzfMN176zDFVkayht S5HtM9xlUYIWNujv/SiyHYBiM2RbIzcC1KbPd9hfn70eYKXSLtKlZGWZJ627vHiO+xrAdCXGMh2N C92j4vr8fTSbItsNIl8V2RadyxbfY/QYYKtIENEOoiLBGoTEf9klqr8b0AWGBGt2wNYnRmBAvZmd vuG42lzamaPcN+z0PiPwdObyewj8/5Bsemx6FirI9Umy9asD+wsD6CVeYzE0pjHw+JlpA42ya1to izRkXpluVw1KAfGBPSxNLp0fVo+GBEcvF9huM4heoxAiyvVqkDdyegHHphBd5vSAtm2teLSO0Xog nrAemPqowuZUJXuspM9YIvI1VyRYnBTT5ov+rUNCdxypgD2dESx+wvzZmAA8ebQ0HuEuuM8pkwBl MG02RQ6PztFHhpHpOS9+Gueimot+9PixxS4nkLDpJRmWSopYf4oWBcTSeOv84IwJZjgpGHwYNvJ+ pGWPs8SY4oMXXsskQOnekRRxyLG1/h5IiiMznc6+OsbidEUSf89z9P7gyLCy+PbIemufzljjTC8Y V3VZmg8mkphEvLuH6eURtPoeZkyyYRt+HmnmfOwP2/TmGYDGMSyYlCENtB/doyO4fmoN2LUrVPel niYK0GwzO4dXqWLBwDHJZTHUke0d6ON4xIIjBWCcq3VosDqU7ItbHerRsP24rwScsWKsc4G3sPGB y0UKRYIMRlWGBJMyZJtU+gl6nLzFflXkaRxmwLgBNRkelFI9Oi0osgmymlVkW4Jjpmtttkvq73kU 2RJOGC8fxp1MQ6qeK4d0Tjn1Ef75PIpsdbnKUZa6eHSgHzk+gM6xEN7FTrHHke4xkbvrmQZOGKn3 KZ8kg0Q9Vp3t8+8s2mIrA7FTKSUDOOo+T6+dui/V7UzPhdIqFdc+nDseWit+d4+Tt6M3FOJiuPah qQlO12ixAe6eJ10Bekfof1pnnCjj2qp4LECPp2bwuSmszX3xwqg2nxtiOQ5gLmkgvXhQBgSpebRf 6udxgubAdg0NpFk0agvJ45f2ynkj1XEbZvqntQLJ4/5qrTD7+b0F6FOBW5EB9WckwmS6fAV+a4Z1 7QGbMpYP686G16l5pNnecA00jE9irjiF158O196StpQo6iBk+UwQyLvR1+aRKBhZEk59rotxJzVB Gq07fJzTcupwzTYHIo3mCLbqcZn3qe3EaWh1Me7MvswpFIwc7o6bt0XqEh1obMnjQOSqV0eG7fpI hUc3EFwzfmHfOu9THuj4V8uqPhlhmAPJ18n7QHqcaYA9ip6WUJ/VniN4lBQoBBQcclAX0c7cl5xC QD5bBk4YI0zH6diYUv8riccZb0lhIDdwmXODVBk5/Y1Qf+v+69kOuPI2zHfFegPchtY4KlOwbH2e nhsUgmZZU1Fm9pVb9OiLoxdowxHwdc1CmKJAzEvS3+Oc1tQApI4TqakhhsvBTj+PAjLqUh9TaMgy n+3kOAwL0nsnoIG13jtrDMI8MZzeO3pyIo7kNjGONgbURmIEh0BwvWEA+08DtjVFJB4f0iSQ3Oe9 UrZRbuSWZ/KHaf9JbD4k1+LRkO14w4tJqVFXJ8qytvrwmEWR3vyCMKeellaKepZkj+mo+b4zWK+M ecYF2boo60P5uujORfhXzoYW4bVqq6tqI2NEkeERq4/rQq4ldvesURXbEBFTuft7npHkxY6zLc67 h2baB49W2lroBBBaqYXOGoewOeIQj+m1Z7pPnIo4Ppwh036VkBwi9ThLCACpw/RqZpvJ+vI8ilfS K78v8v3n2lmLYmywU5LHtfF0yIFiQno1k9bYRUjNpiU3y9/8e7K8/6LuWnP0yGHcVXKCgR+yLR+n nvc/wsr2Nzu9GLKBDrKw5keQAGkgMaqKliiK/B2YPgQrCuoaVFEJtWSP6wc9vxfYRRowLROmaexJ 81jlJINpmHjQ82fOiz8fUUms5dnpZWZAjYL3RkcTFlCzbRdtHqnD/JQLuDRqnDQ1K0F/5dYdHkZP faGOrU/XBdaNSmviUMd2aisw/MS+jNVdk4K6jNA+f+c5rv5gt9b2mSMyf5xaPS7y9TM9wEVCZX46 JGb8lyG4RyGbXTsNqIvGtVPntUPzKHpyuOmSe0ep3DoI91jpaaION2eP3QGKdBqXTlqXDqN1NXvM TNezHyAp2XB6+n6RBeUYtLCns3fD0spmhNNjNjqIHKYt0uiRxzGY7tgPtH1mvcwBsGlxSIIaTHfg JGH15YRpxnrknojb5GaYjmC8M2BaJ0wz1xIrTx3eOm88I7KYa32YZ1p3wHbhazIs8FfinPmCzbUB tSygJljwzfxt75qY3GD+NkrQNblmXhLV7iuH5zmufKDuzbDtM09kDY+9bi6xLT5gK1FlDkTovmjL zEhiL7Y9F2B04/APn9hGvp3ic+XtOHoFK3xSZzRiilD0EUe8FRmHxLA1E83qaZhl3eeOGDPPdCos KPIGYAusJf5V+FY/E02WtG/Lxa6cAhPRrFxeVw5fc/GIAtYYIH/wAdGfsRtTF7UYHRKg/ZSjIYie wwOhbbVLlzmD6AoatwHRa4bI0vdK9KiPuN7wgoC3Ud4s/QpBAglDjeyRnD5fGLs1haADC0jrJjV5 5HPtdYvYiknXLIRp86R77ERLfRSMqrQMpT5dGef2xvuiePP9KDItSrPuZL6mdlF6FEYM2Rds2rqs ERUxLRL7rBiq7UQBtfOAryb3sNg1iGl26MziaeKf26L4ndyt1L9qvv62BM65Dktg1uLM/4E/S+B8 HjB3K8YPkcs86LsGjzT7ewvwwVCZMg9hRGGPwSE893yfYHo4bps1AmHcwC/1uIao5T6BHm8UN8t+ mtw40g3GHU7eq106QGzchhov1sA2eKO4TKnKR4Rtm9YRg5Q0EmV7zJVODdpWJLheYLagZQ1D2afT R/abu4djSFCRq4chwWLZWYHzSz26FV31emDkluQlJCAL1tNAz2GeoN2iAu2nY/zI2tn+u1r54O/5 6KkHeN2sYJs7O6wzyN2+Hn/U2iuKPEAHsqWFbEz9GZ1yHnfAuuk+aWka/Rpdrh3o2V6QMWwv29RI seX3b6JS9xag/8fW459rZw1AqMNk8Riz0/N1gkcz3rTJrvH8k+5xr/LMxwvXeGNabBT7ckpRj8rc pHdDKpxR40T72GkkBQ892KnzOOtzof0jqwo+5CdR5lYtrN/ZSnvcMYEBlVVkOpbgqXlE0+6wBDWY 7h2M23qY6y3k2QwdSHeIbHppjvgOnUQupXGKeuwPztyhO6sh26JxGFJLDx6XxnM4DzAHGSWbrpKN vW41FYe0lH08AkJS7eMZs2ohW9Z2LQWPmq8nwqczgHoGPQrZ3JMm2SNQW5lTALQNMJg8W2Qz0SIe 7bGyIa6AjyfUMbBO1pPCoahdSdOL9v/ZW+53lsbfhMDAwG1p2AhYx9aixyQx664F9G/2hzDBgED1 N931ztPc/TyhubH0tUTBeh6naUgGBgFA9QCDSbVFJmi1SsfhTXq2kMGId2C1LqzG4DY2dphf89Ym ISv0azYQWFQbA2utwaNN6ysNDUWitrC2X5kgp6XkcX1Pz9rBnrX9IU1wg1BtVxPfpOg7ieqSkC3b ALe1elBIiy3icjMkv5eAtkfr1H6xw4zsUYf0R5d6grjUaN3D4kGZgEUkOqyqNSqKG4/W68jMRWMZ 3akEdfh4zpHWgMu2pQNlN6lq8MjsHk/pwEU3pdqmGehPnU1/7bSif2tBwVt2lDY24X94krFmtesk TzlRQoDU+lG147cs6khE8PeWWTldsclPXwsh5b+VaZ3f80Hr/HUKcthhrEv1mBHQy5i1wxtnzUOY sj26dPZIWhLKQwsiYfUGLHOrB48sm904GUY4xPyZ7zBJTu/V4fNp93GiNEGrCOqqCKg/QfS4gGTY hnZcBratTYpCWHdJ4nEZ0eAggk2KAQdriECdWlPxWICe9QH1tP1BZuvGpPpsPWw3GLQbuv/F/BmJ sNWQ7FM9Ge1IQKufx3GiITmuc7K2xLaQtpozWn0Gup1x96R19xDasHf1uFWl5S5geK2l/VXDz1Oq yp+TTv60oL5Kgh6thtLLv6yQ0zjtQ4/7fNDKeKp99m2kQXCa+lrCCQxnx5WzRlVMrp9Dc6nIaQ3a LcT8Ge2wSydVjxX1UEOAUZWBtCyQxgVo770wad7OydtTn47W97L2WX82pv/yuCL2pJBAZz1unCkv EqqRaHRqvbeaPlBBEHMJa/DG+MLYxWMSp0FbBSt8A9rW4I1qJ1NzWE3b40FmeePxfEYH/61m1KA6 oTV4g+oPnUuuHqs/PeYJ2usWQBySvW5xTg8SU1FL9bgrlmMpZHqgE6vZOpKGwpIPtr5u8hagaBto vTRGbM5ba/Mo+qj5PUA7aoWB/tUzzbG17o6xunv9/+oFIt4MDOTDtBGwrjLya9w9HesRFAUipRZn j8Bcpb7pEfYVOl3eE8QHDWSbLDWNgM7i8SK1A1yIyLFXbc1FK2ENUx/DH3ffzlXCgxYtrTD4THgY 6z5Gp/6ez1l6QGu9cSxdz4wa/L5liXZif+cZtgRgrVezfIg2yBsWu2DHBYyOIzsdAO3zP6DSPcdJ UieqdHc5T0xalPCGS89GGINYIg1L3fl47v4kqDAq4TMTIWW1UzQ47n6hxCrr0dZN+mMqNP65x/Nj K7PeDwAFw2Vy3jzKegReFuwTSljNFtFhrGZbXBvpeGJM0WPezqnlBfoiLf2vGmicLX0y+c/ZsPzY vOjtCfhMqi6NBAHo1qo6HMKnMUDA981kqOkspPbm8Dg5PxGm07SwbDFYX/0NPm+tPl+7PvF985nu MKsCa1Id1gPnGMFDVrcsDQvpRFMIleUE7KwHsr4nWN7RwRPM6hOWN9F+shb8eP7g/fk7Gt23gEiK gQaT1CVT6/H5eGTZLqsiERrYb4tzr6QiqLF7ZKXOXC60KmY1wSJ1CVcw0lI9Oued4choMzGNQ43q kypyaMH250QSPx7En+kEcqkBbUsiwR6OthHg7Q7aDAsCyD0wLEiLcWd6fTuQQ57gyceFoqA1jubA 2refvmsx/7lZ70/ftVrkBIRukpkDLa2yIGie/Rp3un9pPAshDdc4pLFdF5+Jj3fHVh/225omVkLq FmmMBN27u/McF6wL0uKoqZK6eOSoz+tsyEZTwoco+Pn8YJ8A7Mz2SeOSegklSAsXhxmqw5Lavh3Y wtlvi3BnAwQVmmu9t8jpNwq5T20uIlWam+yxyDEgKCAwZADBoqfZLVqHIMTds7EGoROcXnRuZUFv RZvDd63L/QI/3fF4FpvDlt6GZZa/41h3XS4026lhddfwODGGmpkRy8715KE6BseZmyELqcnXo6l5 DOm++3Xh0Whc5FRlkjalUdCbkVpBez08sRZS/9hif+P8oDwtoTmvpFEWWIvAarZvNhP3alhKBR9P bLEuDQubjJYQPQamSnvy1yS+//Wl72n40lOH4F8efent3jnwFCEt3pAfx6O21YCtQiF1SR/ekMXw afS4XCX3U1DCqF04aWIB88/jdMHWbaTHPhVgYjTERWuKQN63FErNDpOt7/5msBQ/3rcPXcA0Rrl5 fN/6kQ6QMtrD6OACdWH5NRlfd6fJp7YXIvVIEKHyvF8ukdqu0YiEx3aNLkMmNvCVmDwKj5u1CIjK iblN5rCQmzT2HsgOT9zqTS8vWiKfuskJbZlMEaoq0xfshLarBCVX6YfNYYIpn9BWH3lQclUvwyWY rcHGETjs8OI5s6CY+4EGn4EiMzHiYt3NHVxCHbbVZbODox5THk1/7v7ccLO3pA85xawafX46vV8N aiXqUuoKm/EUmie0d4XcblKM1It3z4R3D1qzw6FIi/eLrBqjxDWDU7YBp1Squ7eJexQYgI3PZ7FT bKbo9POxJuAF75u0QR7GFMmef+yFbljtvHrK0zNYuFzJqVWUdKQ5JLZJvpOdSloVDXkMDBa1y0Jr +tgf9feyXW+7YdB9yYsBaeT5xJpdFgbZ6mfY9rRP20PBrXncejmtqkZ7FUmnbr/SrpTr9vdR1dc7 1kH+XRjU/FcNNAyWnqTu20AYzQ7S5ZRhrh16hhx11ChNChYZydaS4DkEXaFRBi81HgBBtVQrMwvf O0PoD7hzBkqvbSSWDd/FZYlzyavQfbLkxRs26inh07RA+g140BR1+jcXnvNi947DgaIhWwIDUgnN viEyvf71HUbvczKyCzSAlWu7QPUzfiPjxG9W4rfyOMW6azwSqXMkklkaF7dj2TkSuY/woPGoQcHi 2UgI+XcF9darR7IAZY4apC2yACNBC5UyOTutmc6cTzThsc9n2Rsy6UdKxePa2JmPjsXubdHUQmhq +yuXe71HgG7uI9V+fT7MftKnO5Oh7omkOcEKAy3ayWkkVCac2gluVufcMLSm5A+Vw74enx6HTwo3 GFqNr2dRhzRFxFoMhzLKJ/aMioMUZ8KYNMbmVB0RI+7O01UDsG3UrmvIwxw1g0sfZ7FSE7octqWi ZAahKsPw3d1x2pErmJCOPdlVGbCRlYjHWJQm14sG2MHqtoHUpEkYhhMECTaXoRkNFHORD29IzvON 0mhvnZMLmsG12D9tD3NwFftRf+fJ76Ht38jW7ekM7wK27N+kOzxMlTuhCZykOb1ulQmNvMrarhZB TypDdJjtMJSiLh4/nbu/yMh5QMGHnCJkm9MRggG1ILItWI1jT4BtXEqkWved71rS9uD07raoUCHG TDGNiEh3T+cqU1eI3rbFf1DzH5/U4Rm0obCXpHM1vpL+2qcxU26HFKSg1KGgpJvX8993qKDMAQ1F rCT4jBLpxKp7jBy95L5QGLl9OYv6IM1bCkU9JsLmrohqM1wLSyfBuIJe2SR+r7JAD5CSNLd0JlDz hLGeHKqp70MqkhnZ67a4HCVFqNMA4jMfgmVguphQpsuJRbPDwcg9Rr4QDsrq4FhCX24pOmRCez8v wOwORnc4OZNMBAmtVNLy/Lkh3O+ophTmQ0vSZfzBWjipweNWn9hnAloezbr8s1gowq/cPGooL3kS ioCzj2f1PFRDKeqRnLKu80ERfVFSXdsV5DL1aoQeNMFwIV1eDPR182j8kbQf2HNf1xSBVjqhqUOk vo98opfNPp5PC0c3ll1yh7nHCFZFeghrikCeTm2FPZ2dE9LjDgmW1WPxZQT3EmRrJXmMh36u1pA0 ZzoxVGEJAn18V/5OY58O9M+yT+fTw5GXLbbu0Sb0OkekIIS2JacmtqfRuiXxWBdY6w/k4cOobX08 BNmc+lB27RFEj/YwZKEhM9vGoZVw2JFa0dZw9FP5dKRkxiMleNR+vFIEScG0jSirpIlRuyG27BDc ulpdhm6evyPj2UVqH53Dx9NVL5BKbh/PXI5nA98Rh+cQ2fSSryHR/6QQ1zpSiElqmv1UYFKJnUWO XTwBRpLrUIVat0pkYNH+QhxC232kFwV25lI/ZA7hqpMhtcNv5wztgsFPuhyamDXgTL3GOQL7gp+S HgGv+usawTHzuRTsJvX3cLq+B3g4htOycBq7tcnIwnOIBfbtHChB0b6dxeV0tq88bI/8PZ5yaEam ObHnT/ATIarHCMJhj6ClXLhH6GswQkya7Ic6M6vf+b7plUr8d11g1XSYNymLVg7B49t2XuHEvh91 kTk0o097cHiT6pW/xvd+eTppPh1WtUnwyH4YtgkKhLSns/iCzgzBfBqctaO/cB12dHBRWqQ5DzRV ZPPL9jWM+MvLJvNlI+SH9atMyrL3Io0v0B+Pl2311yxkLNvzc1iEluNCq3A5DWVOrGyHlM8Q/uCO 72/UoCj2elyia4bA1q+tJogO29GrlhcUOdLmVt9YJIXH6UO57xDXDAi+tghfgGB21yy+pvfsMQJO r/gC2jB3w4FxGtwfFAOIgkF6a1bSJW8CK3AGa2311p0ME51uxMpdUcU2aoEhlGAUdY5NHK76X2e+ 8IpVXxMEJvwYKbfkPDt9Aa07+Drs/YIE69thIrAWs8MrtNWMnMM19yX7YMvKVrF53KqwCqfD4NHS PlQBaUVDEY8xAhKuGyoLxiB+DNthd5DG0jYxy0k7l6+tKs4V3aI6O2tGs0mgC2M7JWDteCLS68Zg vVsOnWwkxTHWJt/OzoeTzoj0eSPDYdjO1Uycs7SVxIB6Z5TVJXfD+tb2IT6YZMpnt9PVKmoYKTJ2 e+2ojPmIsTrkcY4sD1joUwlre5TsJ441kuJwMz6H64BrPCUsErRhcJOaCmM+dpY513k3aHKoa4bA OPeUgkfx8SuCeKkxitc5iie7L1FiZovxO3seq9siqKrHFv/6emjOQ80OweA+2o0DbNqHBiXnaVPZ 5+48esjzoCZBJ0ldSQs3wp8cemq211432JDKaEhZe+01vyaUAmLtDNmWfpLNQ6rdTA7ZAmtIUQc3 Lp619sIsWaQGn2svreF5VZsktbD9XqeJna30ipLt6hB+hJLxkmLOIQ4nN9jC7Wx69JIqsIWbExHK UvOdvr2Kw+vCSve5xWMv238rHvZp7wOkEtL6kreyAY9TG0otNcJ4oRLWUISUOUNEwa6erSkPoTVk q5n6SkVgN+k3Wy9/rkf4cQKpyoujxobDzCjMyD2ahVmB7SwLDNjOC5Zsc8JDPOpjTAMO3X05+Uzy deXl70X/4YI+7KT+U4v+VhIkbCkxPRvzsC4jKJ08srpHDMjAxNBs6agZDEivHjUsrcoFLOqtF62z F8UDqxRDNODD48SdvOEdpaPNXrt01sCKhZLnVpvDx3OmJ6EZQurLoZ6MRL6R6pZ9Bib3US9sQDl5 qUwtAZt9Vg6hQFXqCy7RNnzDZ9gwuUNb9Dh+ex9oRpvsNF0aaw7Gw3NIFLTyIsMP+7+u2ShbdxkL Lw7tZQ7RFy1atr4UOQwHhoe9x97gKhVEW+ZhDTrqNXaH5hIcyqXupglcOhL7MKhn7KfLvuC8yoNn 8FoXRJNH4xSiu07PMtTnpNHnsISXHNSja+srIsgNUKvOSUhm7oZJgscV2KR3BHTuKNfW8g7Zhx/9 UCSjkL3bB+XrZOcfXOtTI0EEOfb4EiOkdp7mjW9HWjYZOolYC+EIvjHP2wdsVns2HPKiH2aaOS/E 6lFnWK6U0JpYivZsKmM+Xd45rV4VZdhp+PCebOCWk0e3n1PegFvQuMQEpPSM1rr63H6tESt0+4dm Z8/HUM9hS/1oyEDsYa/bh8DhGSIeS2lrdASYlqjEJSZgUwO3jc6DbPbH2/ahC8njcUoX9tK/jt+/ FqAyC1AWXzXDX9wdR494g21rSXleOz8Pht5n/HWeF8KBgdNr9s62+rWV4rAieNqjyOBDw0f0xaa7 XsXtBeV2G64tiSFx+CghCet0dkry7qNcQJI3cO3DfRIgcIprT3szwGl72yYhlaiRO3fQ3FvkFFSD jsfz4T1YSrzPx5PL9SA/3SRhkLlEn2sI3piUYK97842GVAOql5SAFTnd3jaH2Javo4E1pB5iHZ6G xHLBnkHzaH2uh7WiKHBj0ASVLY1/UxP8uVftpzWB2JNAG/06NCuihQZCl+wy/rFPrTcY6dS50M+G oUnEY1ziJWfBfgt9cTiRnMepe2arN+KkRGNYdyjTr42+wd9xco4HEnwlmQNEEh2SMg/e2SrSLw+K drH6cw0Q6VjHZ199Hx1t7FjpHxaLw0Kh66io/Z3nvKqA+tNKgrRYNjYR1R5dTt+P3lEeij2fxXsQ XymvtJQVoIosMZLUCQb4bYshdY/Q1t5ygK/HkPrT7TCjnxw8Cgz7ab/+PaZKw4U6DfkK6Q5KYq/a zu09KwtOaDFXw2qtI5lZ17nm6+7pJO0FDRDSkIAOq+mfSr76PslXtZcLLbjkYdNqFSiTEyStrK3e qjO2qgAa/ZT0aUQxOy3SK9MT7GSlrAR9wfxdJc3hASN0c9Oq5Dg7kcAu0a9qj69IsFicSIoCp0jw 9JThtZM+DQKrCWr1WLP1oiH+m/ao2UocpRK2XzUyh4Kt7h5niiDhSfKchLBEF58D+Lt1FG0942kG CsDXLPYhriJbbjtBzVqDF9QDA6SXBpy0biNFibUGe0cHegP2c6Dah/agA/jsUZNXLkGvm+TFF/5c Lrlvhngct4JHk1ObpdpvyHA2xoueMX+Rfv6zddTVoICKvea/727r6JIrQMv2Gj90x39LRnCnciPL dsO0KZQs7FVTewkdBg0/7VVA5Vpl82moWV9QAts/3MoPXIL6AtX019il/G8dxu4bRUvv9u18qCgy qnZaRdd4BiCaVslhlTcQCrrGVolnRN8Jbe3oHWVa5/RxaWZrR6rBIfFZ5X3A2zZsvCZRSN41p9GI l/aMJ9U5LJzGLVvqUth59nbUmgBBMLDgw62Rcs0aUI8jt5rTjfZb+oy1LoFFn2h26bFwpAtZZqrW ee+wZRCfNl/PkW+oA88ftgOXoC11htObr53wggAxu3Y+3Br+cmqloUFx77LrjcMES04L2Ri39j/V XctuIDcO/BVfA2wMvUl9jvp1SjJAsLvA/v2SUmdgxKxBPDDQ9Gkwc7E1apWoYrGqNI9yyW3EYTfc 4uIKE0o78IlstFcrQZ2ZJxSg0Nfq8uzI862ZSZwtLsoDCnFeIgpveHZzcramkXuYm/ODpEeHOH1U GmbiVs1lIYG9niTIh5TGjxr7SElg99s0iqJQQRJ9HIf2eVbAH1a1X5nN6ZZ8P6yRb27vHlXg2xjF co8psWpyestougUzbP05tjDtVoQL98USwPAjlyGC+0WAJUiLYUsoj4ZdSjxGOq3cdO5lbg5MeHSZ TLWdm1UMKETfdCEKPwoBUTjPpoQQUK+lRUkl5BghLzuH+5OP1I73ApzC6r7WG5BKSrVWXK6GixWV LP+6Xjq2tDBSzolsO49PHBT/ic5uPi7jZZCK+vxF/glB+3NNnc70Vhv1ffwwz2ODpEQ5KEC4+85G uoLRcuc+2Q5g8uf1/kz7GNYThzSeboYko4GwGorDzTk2WZMN0YspTIAfkIvK4+xEpslbvC+kS1mF NCrXsHLtWeKTreXIH2kJ8VD8O5Z/P8mzCxQ0483GfbIdIJXqR6bmzzbcrt3KopGjc1NRgL2Rssej MfNZs5X5LEfnfoOiWcrGHkN45VvbjO3pYZI39LWk33vRCRbzW7uZNeQ477OS3hM1WxhRFi0NJJ9R myAO26FX7mx0d7Us4FkWoMmJhmWSz8bWXnaQU8s3TYAavBom5G9/aJey2QKDyeEA48JOqYL2YX5S SsDXVi3LTzk8i8kFKqnIXcPT3H1sUlMXS/VFs72rh8feHzWS6uDwPNt9vyyNsR6em/YAN2ls7LEw 2HIalj6f8gSDoqFVX4mdHrFYl08PkzMEbn9ykXbwscVHP7ZKBcRVtgUGyA9nCuHdbY5UOt3YHD08 60EKPzZij+uRw1MsGbjSaOvwIC/TmDyuZ6StG8FUPSw2x37ylBpkvf44w7RTtoxZSUPD5s1jryer usXhzZP4TAZSKxgsHRsq22JLHk3/jnHaWUEtryc2PDw+b55tO4c5Xh2q3qQ1fLFJN6lEN1tdVFbD Cgg+5HNL2WMluuXDmkkmjdqaeAAcmGqlCCzOn33GnUCQkxdtAGbGvZ6fVlI0GqQ6S/UqvzBS5GQY zf1sKmJuZJlmylXJqzRAM+M+CcQhxZthZdjjYtzsOlQdA0E78RM1Hz/TSDjCW7Ovv+aqXj88HBbb py3jv99++8/v58uf3779+x9XOL1b5kukGVuKaCBUOAb1m/P3jcnz4LIqttzKIqaQtMgpsZsOWcLf xveU9XD6mZVf/iU/ZBy/fvvjt//BGpStPnyo9a5BkWV7bx4nXaRmq5ZuUhbUVs2GRLo9eqTetxwv SwFGM0NQbx0U5xSaR13rFupmrKdwW20rJPwgKRgcAgLtpRufW4+TqUYSI6ea40z7FsO7SzS/wsIG ottz2lwposFQcll0bv54GPfDm1KZ3105PjflH1w4uXRT0lq6ApoAQEEkQfJpm7vTaTBsWrKtXiLQ f2ln1KMlY25bMBhQAWheAI0mX31aGNLJ3N5jWixcXn9gNTt/A3eGC7RnNlpVPc5WCDCaLdwjmA2L Tx6cYxzAUa7crQM0WRm6R8eVPNJmsLlF0G4dnK/l/Uk7BwOne5ydAyCQ8FrZ7GHf7R58XQIW0KZK jL3an+wcyKugWxPj8ipo61WAihxqHuOcpIouliBHsODuHIBXW+wuR8Y3jas0E4Vpbg8MRsXy9s9b zkcr6rPVy5oL4RkWFGAYd6SCNMePnp0Uqzm8R2nhNBqpatljuiPtNAwo6HGKdBnya9XjYgTXiuFk qrh2c+yoJuDkM9btsM30W7k7OnAq2SuuJaPDK7jWF6592FfuE3nQD+Na5cOKe2ZawwfQ0bjH5JAo KBtZMN3z8jEl1G57qcWjUQntvVnLSbM9BTSGXuvPxKeVs6X159KAonqNQm4eWfYcTiO0VnC63qw0 cjKs5PGxk6/jrY3MXyyBFATIL/fFJUGQE721mv7OdtTa1F4Spmm4XIxcnsFMqWz1bh6i6TCfTO64 LkuuIvfN3fr4WmoiAehodA7lm5sADRbjtbDJoVsWGDRH9xTQUGCtz0nEo9Jle+jXpTMGAB1rzEjH +qw3QR8Wyy5YcHd1kEjf5/dWQjOLNdIldRC7ictorYceszRulQ3VmsDa3TBADXefKE07WzRuT4tj hzyUy7rzKm2YUXvcVCEpfweKzygw4HD+/Wx9t1zntTeVG6Nhg5faPM68HmMflk+mnKjVASlQP+AS 1LaLm5VDI5fO0heDgq1UrtFhcMvoVzC9Mvnu6Hwtmy9Btmp0dntaHR3gJ9cKIfOlJwWfcnaqoV7V s7M6BkhG4PTsnFuy2m1F3c3ntwZKAqfGHvuWmu2N1ZasEEBblO/No/BT3gfZiN2U90G7CQ80YS0v B4dYIPW05Zurx2cR0wU5Lvis2viqZPm1y/e2GrxgPbJUl15sx9jA/rTFfRTU2OHoUSe573QYOsmi JtoT3pD1n8/lbOk6jUkqhYOy4ACs5weO+o9SU/vo1lhyDmrHJice0bmwr5OeywuSswO4gra4ggIV oC6FRSfRZdylRV2n9ewgD+2s8Q7+lrOdA8Q7ttULAdsTZfsSeJM+CdVlU0fJ99tTSZO2wByVz47o XgYoqtv9IIWSPJdVgcA0G7IvheklJ4AP7BgTmHJ7FAl4WHncRS3OJxIgSzafBvRHI7a7om2R1AWR 1NDp51Ek6FIVvGFCv/uABurKfyDVFwXWyXhzOZ+HBT9RU4/eDHqq9glsNX14AKE/h2xSEwCBYbvp AsRS+4xx2ftxGQ14dVhaSAA2h1Jlh8thPprxvFYkWMwhiAeImRs6Os8+3waYe2338/pr6b4Ex07L I4tZW/GJE7Buj4HVMtjdeuR1zcZ7p6jL8Tw+6HXtEw36Jv/P7y8eeWqm1xSRKi8m6sHjaqTOqdY1 qsvRaxSU1HKPepxILjufxrdWtWbLrUJPD6fZe2WAnhXdxBQS5fic6JcnQjYe11Fp2/VEQH2EQB6J 3ZPiZlu10iLeKyJ2k0t5u9ykwGCObjIHCj9cduS3dFr5e/K98WokQOI9Vp+eXwNYHdOiDCpKDHj8 Kv0/qH4Yj9jdGwA= ------=_Part_41954_17327440.1223060244849-- From l.schimmer@cgv.tugraz.at Sat Oct 4 21:20:28 2008 From: l.schimmer@cgv.tugraz.at (Lars Schimmer) Date: Sat, 04 Oct 2008 22:20:28 +0200 Subject: [OpenAFS] cache manager hangs on windows In-Reply-To: <1d1a54bf0810031157v2f148b4auc5b2af0fc56833da@mail.gmail.com> References: <1d1a54bf0810031157v2f148b4auc5b2af0fc56833da@mail.gmail.com> Message-ID: <48E7D00C.5080106@cgv.tugraz.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Anyone have any pointers? Hi! Have you tried with 1.5.53 ? > David Bear > College of Public Programs at ASU > 602-464-0424 MfG, Lars Schimmer - -- - ------------------------------------------------------------- TU Graz, Institut f=FCr ComputerGraphik & WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schimmer@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI59AMmWhuE0qbFyMRAvjqAJwNU+HSASeiEXCNU5vjR2uecCyWUQCeM4R5 2QeByYvJxgnHOe7A7vcs9BA=3D =3D0I60 -----END PGP SIGNATURE----- From l.schimmer@cgv.tugraz.at Sat Oct 4 21:24:22 2008 From: l.schimmer@cgv.tugraz.at (Lars Schimmer) Date: Sat, 04 Oct 2008 22:24:22 +0200 Subject: [OpenAFS] network map fail! In-Reply-To: <19666126.post@talk.nabble.com> References: <19666126.post@talk.nabble.com> Message-ID: <48E7D0F6.6030003@cgv.tugraz.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 karlherrman wrote: > Hi.. I have install openafs server 1.4.7 on a fedora9 and now i'am tryi= ng to > accessing my afs share from a vista client. I have no problem with gett= ing > "tokens", but the map network drive fails? It can't find the path? Hi! Did you enter the right servers into cellservDB or into the DNS? Could you reach \\AFS\your.cell.name\ ? Is that the first AFS client on windows? Did you setup one working before= ? Usual I enter my databaseservers into cellservDB, set default cell to my cgv.tugraz.at cell and start openafs service. You can control the service startup logfile in C:\window\temp\ > mvh karlherrman MfG, Lars Schimmer - -- - ------------------------------------------------------------- TU Graz, Institut f=FCr ComputerGraphik & WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schimmer@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI59D2mWhuE0qbFyMRAvo0AJ9N8NtwGAZ08iCiuIPfj9mFU+KVMwCeJYPV ieB2ezobxVuP5VAJB0vvxtg=3D =3Dz/rg -----END PGP SIGNATURE----- From jaltman@secure-endpoints.com Sat Oct 4 22:51:56 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Sat, 04 Oct 2008 17:51:56 -0400 Subject: [OpenAFS] network map fail! In-Reply-To: <19666126.post@talk.nabble.com> References: <19666126.post@talk.nabble.com> Message-ID: <48E7E57C.2020003@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms000606030302010908060408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit karlherrman wrote: > Hi.. I have install openafs server 1.4.7 on a fedora9 and now i'am trying to > accessing my afs share from a vista client. I have no problem with getting > "tokens", but the map network drive fails? It can't find the path? Map drives from the Explorer Shell and not from the AFSCreds application. AFSCreds has problems with user account control on Vista. Please read the release notes. There is a section on this topic. Jeffrey Altman --------------ms000606030302010908060408 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMDQyMTUxNTZaMCMGCSqGSIb3DQEJBDEWBBQ5uaB3 WvwPBknvVczG0w8ZGtTJjzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAf3g/dLAke0VGJ7Rbb5/nEmcuuUYWGasD3ToEvpYRzMWGn8rdkwsF B/WRBRxH7iR65+vDEa/QfKpsTjYrxTUAKIpRdFb5xm3NLo/LTiip+osqenHetuted76qvjvZ tvx8P4saqhuk3340ExXEIq32/L47QRpf0o6jsEJd5KtlyhMb0Y/+AF24/UdG+iCazapw2AVd 6SaLYIZZHrlR79D9NHm2MjY/RuInSEBbUcTA9MtAGiv6ADskBggxPFnjpcC/I+RoZ/gUXmdL +ArsdnJrYSao2W4tiMt2P+OrO4mxbE6mYAz7Hi8ihVfNMJJ9okWkPHvkO0ngyU/ycGRjcWMT RAAAAAAAAA== --------------ms000606030302010908060408-- From jaltman@secure-endpoints.com Sat Oct 4 22:55:26 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Sat, 04 Oct 2008 17:55:26 -0400 Subject: [OpenAFS] cache manager hangs on windows In-Reply-To: <1d1a54bf0810031157v2f148b4auc5b2af0fc56833da@mail.gmail.com> References: <1d1a54bf0810031157v2f148b4auc5b2af0fc56833da@mail.gmail.com> Message-ID: <48E7E64E.5090301@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms080802000204070308030709 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David Bear wrote: > I am attaching the output of cmdebug -servers pp-kcass.dhcp.asu.edu > -port 7001 -long -- zipped. > > Anyone have any pointers? capture a minidump with "fs minidump" as per the release notes and send it to your support provider or to openafs-bugs@openafs.org. Jeffrey Altman --------------ms080802000204070308030709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMDQyMTU1MjZaMCMGCSqGSIb3DQEJBDEWBBRv45fG ShBRSM741J0BAdBFCN9igDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAcNues7xPZZFwnyG4Sad6Ul27zELXLgYOJCR6M9pet92y8msLH6PS S882kuT/Wrz+Zs3+f6N60F3anunM8M8UdnA4esGzQ1L18dpmHa+i9EFJEA78NIVgIp9bwBqm nFOzIAvtxApWn/RSI3yfHqJHx+w1Dx4xQKublhUr7VIz25cluy44IS+Bob9CtaPSzanCnqPT taW6AHgrsOPxmnrxn9rET5ILAhM8kppbyK0sUWJtTHFArfJ+J/cJBTbb13dnCMRWnP76xE6A kZuXssuBi4qxIo+rFqj7xN+nIdDrh3NSziobh/id9x1njFNUyQVgwdQyGAWEa8rfr+e+h2v1 /wAAAAAAAA== --------------ms080802000204070308030709-- From geza@kzsdabas.hu Sun Oct 5 21:41:06 2008 From: geza@kzsdabas.hu (=?ISO-8859-2?Q?G=E9mes_G=E9za?=) Date: Sun, 05 Oct 2008 22:41:06 +0200 Subject: [OpenAFS] Linking GPL3 code with IPL? (Was: afs_syscall (Samba as a client of OpenAFS)) In-Reply-To: <48DFDFCE.2090809@kzsdabas.hu> References: <48DFDFCE.2090809@kzsdabas.hu> Message-ID: <48E92662.7060608@kzsdabas.hu> Hi, I've built up a patch (attachment 3658 to bug 5799 on samba bugzilla) which makes fake-kaserver and vfs-afsacl work again. But the patched configure makes smbd, net and maybe other binaries link with libsys.a in order to communicate with the openafs kernel code. The question is what are the legal consequences, are the binaries distributable et all? Thanks Geza From chas@cmf.nrl.navy.mil Mon Oct 6 14:17:57 2008 From: chas@cmf.nrl.navy.mil (Chas Williams (CONTRACTOR)) Date: Mon, 06 Oct 2008 09:17:57 -0400 Subject: [OpenAFS] 1.4.8, Rx Performance Improvements, and a Small Business Innovative Research grant In-Reply-To: <200810031358.m93DwV4f001009@hedwig.cmf.nrl.navy.mil> Message-ID: <200810061317.m96DHvMe023746@cmf.nrl.navy.mil> at one point, people talked about making rx work with xplot. sometime ago, i did this but didnt really get far enough to get something that i would consider release quality. however, given the interest i think i will just release what i have. ftp://ftp.cmf.nrl.navy.mil/pub/chas/afs/rxtrace2xplot.pl there are some comments at the top about how to use this. basically you feed it the output from tcpdump and it breaks it up by call. i believe the converter still gets confused at times by the bidirectional nature of rx. the program attempts to print helpful diagnostics about the sessions under trace. i probably did not get everything right about the rx protocol. use the answers with a grain of salt. anyway, i included some sample files in that directory as well. the sample shows activity from a client. the client is apparently having trouble because you can clearly see periodic retransmits due to a missing ack. i highlight these in red on the xplot graph. see the jpeg for a zoomed view. it helps to take a look at some tcp transactions first to get an idea of what xplot is trying to tell you. but the rx view is basically the same. i try to draw the hard and soft ack windows, as i recall soft acks are light gray. watching a 'normal' rx connection is interesting. the slow start is pretty obvious. something i notice is that afs rarely manages to fill its transmit window. i could dig up some more sample traces if there is interest. and one comment about this: >Rainer Toebbicke wrote: > 3. the path for handling an ACK packet is very long, I measured on the > order of 10 microseconds on average on a modern processor. At over 100 > MB/s you'd be handling ~50000 ACKs per second in a non-jumbogram > configuration and have hardly any time left to send out new packets. A > lot is spent on waiting for the call-lock: even when that one is > released quickly (which it isn't in the standard implementation, as the > code leisurely walks around with it for extended periods, but I > experimented with a "release" flag), the detour through the scheduler > slows down things dramatically. The lock structure should probably be > revisited to make contention between ack recv & transmit threads less > likely; afs' ack strategy is broken as designed. rx can potentially ack every other packet twice, soft and hard. scanning/handling of the softack field is just a killer. we should just handle hard acks and use the softack field to pad the following data fields to 'good' alignments. i beleive this could be made to be backward compat with the existing protocol without too much trouble. stretch acks are a big win for tcp and other 'enhanced' protocols. this is also part of the reason why jumbograms are a win. they essentially stretch the ack interval since only a single ack is sent for each jumbogram instead of each segment of the jumbogram. From lorenl@north-winds.org Mon Oct 6 19:22:06 2008 From: lorenl@north-winds.org (Loren M. Lang) Date: Mon, 06 Oct 2008 11:22:06 -0700 Subject: [OpenAFS] Check for inode and namei support Message-ID: <1223317326.25871.17.camel@ruth.aloha.tallye.com> --=-jOo962S/Vbc7EMVGUgIR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable How do I determine whether I have a version of OpenAFS compiled for inode or namei? Also, is there a list of filesystems that OpenAFS requires for it's inode fileserver? I assume that it's only usable on Linux with Ext2/3 if inode is usable at all on Linux. Also, inode probably won't work on ZFS in Solaris either. --=20 Loren M. Lang lorenl@north-winds.org http://www.north-winds.org/ Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B --=-jOo962S/Vbc7EMVGUgIR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBI6ldO3O67OXZU3lsRArTZAJ4g1tddRwK+KuL4h81Towhb52/9EwCfdEco 3KQ63uPk3MdMt9CtYJgbMuY= =YJsM -----END PGP SIGNATURE----- --=-jOo962S/Vbc7EMVGUgIR-- From shadow@gmail.com Mon Oct 6 19:25:46 2008 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 6 Oct 2008 14:25:46 -0400 Subject: [OpenAFS] Check for inode and namei support In-Reply-To: <1223317326.25871.17.camel@ruth.aloha.tallye.com> References: <1223317326.25871.17.camel@ruth.aloha.tallye.com> Message-ID: On Mon, Oct 6, 2008 at 2:22 PM, Loren M. Lang wrote: > How do I determine whether I have a version of OpenAFS compiled for > inode or namei? > > Also, is there a list of filesystems that OpenAFS requires for it's > inode fileserver? I assume that it's only usable on Linux with Ext2/3 > if inode is usable at all on Linux. Also, inode probably won't work on > ZFS in Solaris either. Never on Linux. Solaris ufs; Irix xfs; HP-UX hfs; AIX jfs; and nothing else, at least from memory. From geza@kzsdabas.hu Mon Oct 6 20:25:04 2008 From: geza@kzsdabas.hu (=?ISO-8859-2?Q?G=E9mes_G=E9za?=) Date: Mon, 06 Oct 2008 21:25:04 +0200 Subject: [OpenAFS] Re: Linking GPL3 code with IPL? (Was: afs_syscall (Samba as a client of OpenAFS)) In-Reply-To: References: <48DFDFCE.2090809@kzsdabas.hu> <48E92662.7060608@kzsdabas.hu> Message-ID: <48EA6610.2090006@kzsdabas.hu> Volker Lendecke írta: > On Sun, Oct 05, 2008 at 10:41:06PM +0200, Gémes Géza wrote: > >> I've built up a patch (attachment 3658 to bug 5799 on samba bugzilla) >> which makes fake-kaserver and vfs-afsacl work again. >> But the patched configure makes smbd, net and maybe other binaries link >> with libsys.a in order to communicate with the openafs kernel code. The >> question is what are the legal consequences, are the binaries >> distributable et all? >> > > At the time I wrote the fake kaserver stuff I had the same > concerns and thus did a fresh implementation of the ticket > generation and syscall wrappers. Can't you do the same with > the proc_afs_syscall thing? This can't be much code. > > Volker > Unfortunately this time it seems to be a lot harder, the main change being at least to my understanding, the fact that the openafs kernel module doesn't advertise its services as a system call, and thus we cannot link with just libc code which calls into the kernel, but need to explicitly use openafs calls for the same propose resulting in a need to link to their code. Hope is not lost totally yet as I've read about some work of developing a GPL licensed kernel module, and then we could use some glue code from there. Geza From geza@kzsdabas.hu Mon Oct 6 20:37:53 2008 From: geza@kzsdabas.hu (=?ISO-8859-2?Q?G=E9mes_G=E9za?=) Date: Mon, 06 Oct 2008 21:37:53 +0200 Subject: [OpenAFS] Re: Linking GPL3 code with IPL? (Was: afs_syscall (Samba as a client of OpenAFS)) In-Reply-To: References: <48DFDFCE.2090809@kzsdabas.hu> <48E92662.7060608@kzsdabas.hu> <48EA6610.2090006@kzsdabas.hu> Message-ID: <48EA6911.3090505@kzsdabas.hu> Volker Lendecke írta: > On Mon, Oct 06, 2008 at 09:25:04PM +0200, Gémes Géza wrote: > >> Unfortunately this time it seems to be a lot harder, the main change >> being at least to my understanding, the fact that the openafs kernel >> module doesn't advertise its services as a system call, and thus we >> cannot link with just libc code which calls into the kernel, but need to >> explicitly use openafs calls for the same propose resulting in a need to >> link to their code. >> Hope is not lost totally yet as I've read about some work of developing >> a GPL licensed kernel module, and then we could use some glue code from >> there. >> > > While not having looked at AFS code, it must at the end come > down to some syscall. Either an ioctl, a write call to some > code in /proc/whatever, or something else. 99% the coding > work is just setting up the right structures and make that > call. > > Volker > Yes it does an ioctl to /proc/fs/openafs/......, but if I look at the code my implementation can be GPL released? Geza From scs@umich.edu Mon Oct 6 20:50:53 2008 From: scs@umich.edu (Steve Simmons) Date: Mon, 6 Oct 2008 15:50:53 -0400 Subject: [OpenAFS] Sysid file and name/addr/uuid confusion Message-ID: We've bumped into an interesting problem here with a host actively serving afs files but not showing up in 'vos listaddr.' There was no actual service issue (ie, everything worked), but a number of our utilities which use the output of vos listaddr-like stuff were failing to process the 'missing' host. It appears that if the public interface addresses change either by rehoming the machine and/or changing the NetInfo file, the file server longer shows up by name when using the vldb. Thus when one does for H in `vos listaddr -noauth | sort | uniq` ; do <> done the 'missing' host is never backed up. Similarly, vos listvldb -server H shows no volumes, even though H is actively serving them. If you dump the vldb, you can see the address of H in the db. If you empty the host and do 'vos changeaddr -remove' it works just fine. If you then start to put volumes on the server, they work just fine -- but the server still won't show up in vos listaddr. This strikes me as bad performance. :-) We've now repaired the problem with this particular host by removing the volumes, shutting down afs, removing the sysfile, and starting up afs again. A new sysfile is created, and the host now shows up properly in listaddr. We're going to do some playing around with our test cell in an attempt to replicate the problem, but are curious if others have seen this problem and if they think it's a bug or a feature. Steve From shadow@gmail.com Mon Oct 6 21:21:13 2008 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 6 Oct 2008 16:21:13 -0400 Subject: [OpenAFS] Re: Linking GPL3 code with IPL? (Was: afs_syscall (Samba as a client of OpenAFS)) In-Reply-To: <48EA6610.2090006@kzsdabas.hu> References: <48DFDFCE.2090809@kzsdabas.hu> <48E92662.7060608@kzsdabas.hu> <48EA6610.2090006@kzsdabas.hu> Message-ID: The GPL module won't help you as it's the kernel and not the userland. =20= Doing ioctls on a proc file isn't really proprietary; You don't need =20 to link our code. Derrick On Oct 6, 2008, at 15:25, G=C3=A9mes G=C3=A9za wrote: > Volker Lendecke =C3=ADrta: >> On Sun, Oct 05, 2008 at 10:41:06PM +0200, G=C3=A9mes G=C3=A9za wrote: >> >>> I've built up a patch (attachment 3658 to bug 5799 on samba =20 >>> bugzilla) >>> which makes fake-kaserver and vfs-afsacl work again. >>> But the patched configure makes smbd, net and maybe other binaries =20= >>> link >>> with libsys.a in order to communicate with the openafs kernel =20 >>> code. The >>> question is what are the legal consequences, are the binaries >>> distributable et all? >>> >> >> At the time I wrote the fake kaserver stuff I had the same >> concerns and thus did a fresh implementation of the ticket >> generation and syscall wrappers. Can't you do the same with >> the proc_afs_syscall thing? This can't be much code. >> >> Volker >> > Unfortunately this time it seems to be a lot harder, the main change > being at least to my understanding, the fact that the openafs kernel > module doesn't advertise its services as a system call, and thus we > cannot link with just libc code which calls into the kernel, but =20 > need to > explicitly use openafs calls for the same propose resulting in a =20 > need to > link to their code. > Hope is not lost totally yet as I've read about some work of =20 > developing > a GPL licensed kernel module, and then we could use some glue code =20 > from > there. > > Geza > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info From geza@kzsdabas.hu Mon Oct 6 21:27:21 2008 From: geza@kzsdabas.hu (=?UTF-8?B?R8OpbWVzIEfDqXph?=) Date: Mon, 06 Oct 2008 22:27:21 +0200 Subject: [OpenAFS] Re: Linking GPL3 code with IPL? (Was: afs_syscall (Samba as a client of OpenAFS)) In-Reply-To: References: <48DFDFCE.2090809@kzsdabas.hu> <48E92662.7060608@kzsdabas.hu> <48EA6610.2090006@kzsdabas.hu> Message-ID: <48EA74A9.7030201@kzsdabas.hu> The question here is not about ioctl, but about using the same data structure as used in proc_afs_syscall Thanks Geza > The GPL module won't help you as it's the kernel and not the userland. > Doing ioctls on a proc file isn't really proprietary; You don't need > to link our code. > > Derrick > > > On Oct 6, 2008, at 15:25, Gémes Géza wrote: > >> Volker Lendecke írta: >>> On Sun, Oct 05, 2008 at 10:41:06PM +0200, Gémes Géza wrote: >>> >>>> I've built up a patch (attachment 3658 to bug 5799 on samba bugzilla) >>>> which makes fake-kaserver and vfs-afsacl work again. >>>> But the patched configure makes smbd, net and maybe other binaries >>>> link >>>> with libsys.a in order to communicate with the openafs kernel code. >>>> The >>>> question is what are the legal consequences, are the binaries >>>> distributable et all? >>>> >>> >>> At the time I wrote the fake kaserver stuff I had the same >>> concerns and thus did a fresh implementation of the ticket >>> generation and syscall wrappers. Can't you do the same with >>> the proc_afs_syscall thing? This can't be much code. >>> >>> Volker >>> >> Unfortunately this time it seems to be a lot harder, the main change >> being at least to my understanding, the fact that the openafs kernel >> module doesn't advertise its services as a system call, and thus we >> cannot link with just libc code which calls into the kernel, but need to >> explicitly use openafs calls for the same propose resulting in a need to >> link to their code. >> Hope is not lost totally yet as I've read about some work of developing >> a GPL licensed kernel module, and then we could use some glue code from >> there. >> >> Geza >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info From shadow@gmail.com Mon Oct 6 22:21:19 2008 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 6 Oct 2008 17:21:19 -0400 Subject: [OpenAFS] Re: Linking GPL3 code with IPL? (Was: afs_syscall (Samba as a client of OpenAFS)) In-Reply-To: <48EA74A9.7030201@kzsdabas.hu> References: <48DFDFCE.2090809@kzsdabas.hu> <48E92662.7060608@kzsdabas.hu> <48EA6610.2090006@kzsdabas.hu> <48EA74A9.7030201@kzsdabas.hu> Message-ID: On Mon, Oct 6, 2008 at 4:27 PM, G=E9mes G=E9za wrote: > The question here is not about ioctl, but about using the same data > structure as used in proc_afs_syscall > So you either believe you can't look at the structure without tainting yourself, in which case I'll happily describe it to you, or you can look and get on with life. I'm not sure what the requirement of linking the IPL'd libsys is. Derrick From rra@stanford.edu Mon Oct 6 23:52:04 2008 From: rra@stanford.edu (Russ Allbery) Date: Mon, 06 Oct 2008 15:52:04 -0700 Subject: [OpenAFS] Perl AFS module with OpenAFS 1.4.7 Message-ID: <87vdw5nxpn.fsf@windlord.stanford.edu> I vaguely recall there was a mailing list message reporting problems with the AFS Perl module with current versions of OpenAFS, but I can't find it again now. I was refreshing my x86 Debian packages and had to make a few minor fixes for the com_err renaming, but nothing seems horribly broken. With the below patch applied (and the KAS test disabled, since we have no kaserver), the module passes all of its tests. I haven't used it to do anything beyond that, though. For some reason, the XS version checking was failing miserably with Perl 5.10 (complaining about undefined variables), so I had to disable it. I'm not sure what's up with that; I haven't investigated further. A better fix than this one is probably to rename all of the com_err calls to use the afs_* names, but this was expedient and I wasn't sure if any of the other symbols were used. diff -ru AFS-2.4.0/src/AFS.xs AFS-2.4.0-new/src/AFS.xs --- AFS-2.4.0/src/AFS.xs 2006-02-16 05:13:16.000000000 -0800 +++ AFS-2.4.0-new/src/AFS.xs 2008-10-06 15:33:15.000000000 -0700 @@ -43,6 +43,8 @@ #include "ppport.h" #include +#define AFS_OLD_COM_ERR 1 +#include /* tired of seeing messages about TRUE/FALSE being redefined in rx/xdr.h */ #undef TRUE #undef FALSE @@ -122,7 +124,9 @@ typedef struct ubik_client *AFS__VOS; typedef struct rx_connection *AFS__BOS; +#ifndef __AFS_COM_ERR_H extern char *error_message(); +#endif extern struct ubik_client *cstruct; extern int UV_SetSecurity(); #ifdef OpenAFS @@ -10998,6 +11002,8 @@ MODULE = AFS PACKAGE = AFS PREFIX = afs_ +VERSIONCHECK: DISABLE + BOOT: initialize_bz_error_table(); initialize_vols_error_table(); -- Russ Allbery (rra@stanford.edu) From mmeffie@sinenomine.net Tue Oct 7 02:40:50 2008 From: mmeffie@sinenomine.net (Michael Meffie) Date: Mon, 06 Oct 2008 21:40:50 -0400 Subject: [OpenAFS] Check for inode and namei support In-Reply-To: <1223317326.25871.17.camel@ruth.aloha.tallye.com> References: <1223317326.25871.17.camel@ruth.aloha.tallye.com> Message-ID: <48EABE22.4060105@sinenomine.net> Loren M. Lang wrote: > How do I determine whether I have a version of OpenAFS compiled for > inode or namei? A fileserver compiled with a namei backend will contain the namei_iopen symbol (along with namei_iread, namei_iwrite, and others). You can use the nm tool to check, # nm src/viced/fileserver | grep namei ... 08091470 T namei_iopen 08092640 T namei_iread 08092590 T namei_iwrite A fileserver server compiled with a inode backend will contain ih_open instead of namei_iopen, # nm src/viced/fileserver | grep ih_open ih_open | 363224|extern|code |$CODE$ # nm src/viced/fileserver | grep namei | wc -l 0 > > Also, is there a list of filesystems that OpenAFS requires for it's > inode fileserver? I assume that it's only usable on Linux with Ext2/3 > if inode is usable at all on Linux. Also, inode probably won't work on > ZFS in Solaris either. From haba@kth.se Tue Oct 7 09:01:50 2008 From: haba@kth.se (Harald Barth) Date: Tue, 07 Oct 2008 10:01:50 +0200 (CEST) Subject: [OpenAFS] 1.4.8, Rx Performance Improvements, and a Small Business Innovative Research grant In-Reply-To: <200810061317.m96DHvMe023746@cmf.nrl.navy.mil> References: <200810031358.m93DwV4f001009@hedwig.cmf.nrl.navy.mil> <200810061317.m96DHvMe023746@cmf.nrl.navy.mil> Message-ID: <20081007.100150.249414631.haba@habanero.pdc.kth.se> > ftp://ftp.cmf.nrl.navy.mil/pub/chas/afs/rxtrace2xplot.pl Thanks. As xplot was not available as portage I tried xplot->gnuplot. Don't do that. The xplot graphics shows much better what is going on than the converted gnuplot. I used xplot 0.90.7.1 from http://www.xplot.org/. Harald. From haba@kth.se Tue Oct 7 09:13:34 2008 From: haba@kth.se (Harald Barth) Date: Tue, 07 Oct 2008 10:13:34 +0200 (CEST) Subject: [OpenAFS] Check for inode and namei support In-Reply-To: References: <1223317326.25871.17.camel@ruth.aloha.tallye.com> Message-ID: <20081007.101334.86114187.haba@habanero.pdc.kth.se> > > Also, is there a list of filesystems that OpenAFS requires for it's > > inode fileserver? I assume that it's only usable on Linux with Ext2/3 > > if inode is usable at all on Linux. Also, inode probably won't work on > > ZFS in Solaris either. > > Never on Linux. Solaris ufs; Irix xfs; HP-UX hfs; AIX jfs; and nothing > else, at least from memory. And I'd use namei on those, too. I just like to see that the data is there. I avoid the following file system combinations: reiserfs+anything (puts your files at risk) Solaris+ufs+logging+inodefileserver (will eat your files) jfs on Linux (untested) We should distribute solaris binaries for namei and inode. Harald. From haba@kth.se Tue Oct 7 09:26:39 2008 From: haba@kth.se (Harald Barth) Date: Tue, 07 Oct 2008 10:26:39 +0200 (CEST) Subject: [OpenAFS] Sysid file and name/addr/uuid confusion In-Reply-To: References: Message-ID: <20081007.102639.99684892.haba@habanero.pdc.kth.se> > for H in `vos listaddr -noauth | sort | uniq` ; do > <> > done Have you tried vos from 1.5.X which has the -noresolve? Does it give you more information? Harald. $ /usr/openafs-1.5.36/sbin/vos listaddrs -noresolve -printuuid -cell umich.edu vsu_ClientInit: Could not get afs tokens, running unauthenticated. UUID: 000dbb64-2717-1355-89-3d-8401d38daa77 141.211.1.132 UUID: 00735ece-abc2-18af-b6-77-9b01d38daa77 141.211.1.155 UUID: 007dd980-996f-118c-a0-aa-2201d38daa77 141.211.1.34 UUID: 004deb08-1d93-119f-99-6f-2001d38daa77 141.211.1.32 UUID: 002f4a2c-4e6e-18d9-bb-02-b70cd38daa77 141.211.12.183 UUID: 0026ab7e-8484-137b-88-73-6c01d38daa77 141.211.1.108 UUID: 001a8c90-30ac-137a-ba-ff-6b01d38daa77 141.211.1.107 UUID: 0088c692-ada4-18af-96-91-9d01d38daa77 141.211.1.157 UUID: 00042842-57cc-18d9-89-6a-9901d38daa77 141.211.1.153 UUID: 00245720-401c-153e-96-bc-8801d38daa77 141.211.1.136 UUID: 001e2d8c-92f8-14d7-a7-ef-7401d38daa77 141.211.13.16 UUID: 00526566-8da7-185a-a7-84-b50cd38daa77 141.211.12.181 UUID: 004450e8-a288-14d7-92-97-7501d38daa77 141.211.1.117 UUID: 0059e82c-99f4-1356-ad-0a-8d01d38daa77 141.211.1.141 UUID: 0054a312-3450-14bd-a6-92-6e01d38daa77 141.211.12.190 UUID: 00409aac-2b78-1358-a2-db-8901d38daa77 141.211.1.137 UUID: 002172e4-e1da-1374-87-1d-6a01d38daa77 141.211.1.106 UUID: 005703dc-c03d-1356-89-40-8501d38daa77 141.211.1.133 UUID: 004801ac-9045-1759-84-6e-120dd38daa77 141.211.13.18 UUID: 0091125c-b019-1355-90-29-8301d38daa77 141.211.1.131 UUID: 007b4a62-5cae-1183-bb-07-2101d38daa77 141.211.1.33 UUID: 00427b4c-8f45-14d7-b9-67-7101d38daa77 141.211.1.113 UUID: 004a7ed2-de32-138d-83-86-8701d38daa77 141.211.1.135 UUID: 002bb826-58b9-1355-8e-fb-8b01d38daa77 141.211.1.139 UUID: 003efa26-8f4b-14d7-ab-85-7201d38daa77 141.211.13.14 UUID: 004695ba-58b8-1355-ab-6d-8a01d38daa77 141.211.1.138 UUID: 005b8c68-95c8-1759-a8-09-7301d38daa77 141.211.1.115 UUID: 000931e8-e0f3-1815-92-07-9701d38daa77 141.211.1.151 UUID: 0060afd6-7502-181b-af-5b-9f01d38daa77 141.211.1.159 UUID: 00508d36-8f31-14d7-81-19-7001d38daa77 141.211.12.191 UUID: 00701aa2-0a6f-1861-9c-b4-b40cd38daa77 141.211.12.180 UUID: 00453eae-1723-14c0-8c-23-6f01d38daa77 141.211.1.111 UUID: 003f561a-4a1f-18ea-bc-bf-b60cd38daa77 141.211.12.182 From sysman@tiara.sinica.edu.tw Tue Oct 7 09:47:35 2008 From: sysman@tiara.sinica.edu.tw (TIARA System Man) Date: Tue, 7 Oct 2008 16:47:35 +0800 Subject: [OpenAFS] questions about volume size? Message-ID: dear guys, one of our users has 1.7TB data. i asked him to reduce his data. he already removed many files. currently, his folder size is 900GB. but, his volume still occupied 1.7TB. is this normal? how could i reduce his volume size? thanks for your help!! best, s -- Sam Tseng Academia Sinica Institute of Astronomy and Astrophysics Tel: +886-2-3365-2200 ext 742 Fax: +886-2-2367-7849 From hanke@csc.fi Tue Oct 7 09:51:36 2008 From: hanke@csc.fi (Christof Hanke) Date: Tue, 7 Oct 2008 11:51:36 +0300 Subject: [OpenAFS] questions about volume size? In-Reply-To: References: Message-ID: <200810071151.36951.hanke@csc.fi> Hi, you could try to release the volume to delete the files really from the fileserver. Cheers, Christof On Tuesday 07 October 2008 11:47:35 TIARA System Man wrote: > dear guys, > > one of our users has 1.7TB data. i asked him to reduce his data. he > already removed many files. currently, his folder size is 900GB. but, > his volume still occupied 1.7TB. is this normal? how could i reduce > his volume size? thanks for your help!! > > best, s > > -- > Sam Tseng > Academia Sinica > Institute of Astronomy and Astrophysics > Tel: +886-2-3365-2200 ext 742 > Fax: +886-2-2367-7849 > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info From sysman@tiara.sinica.edu.tw Tue Oct 7 09:58:50 2008 From: sysman@tiara.sinica.edu.tw (TIARA System Man) Date: Tue, 7 Oct 2008 16:58:50 +0800 Subject: [OpenAFS] questions about volume size? In-Reply-To: <200810071151.36951.hanke@csc.fi> References: <200810071151.36951.hanke@csc.fi> Message-ID: hi christof, i got this error. [root@fs home]# vos release -id home.rwaur Volume 536871041 has no replicas - release operation is meaningless! VOLSER: illegal operation Error in vos release command. VOLSER: illegal operation would you please teach me how to release volumes? thank you very much! best, s On Tue, Oct 7, 2008 at 4:51 PM, Christof Hanke wrote: > Hi, > > you could try to release the volume to delete the files really from the > fileserver. > > Cheers, > > Christof > > On Tuesday 07 October 2008 11:47:35 TIARA System Man wrote: >> dear guys, >> >> one of our users has 1.7TB data. i asked him to reduce his data. he >> already removed many files. currently, his folder size is 900GB. but, >> his volume still occupied 1.7TB. is this normal? how could i reduce >> his volume size? thanks for your help!! >> >> best, s >> >> -- >> Sam Tseng >> Academia Sinica >> Institute of Astronomy and Astrophysics >> Tel: +886-2-3365-2200 ext 742 >> Fax: +886-2-2367-7849 >> _______________________________________________ >> 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 > -- Sam Tseng Academia Sinica Institute of Astronomy and Astrophysics Tel: +886-2-3365-2200 ext 742 Fax: +886-2-2367-7849 From haba@kth.se Tue Oct 7 09:58:40 2008 From: haba@kth.se (Harald Barth) Date: Tue, 07 Oct 2008 10:58:40 +0200 (CEST) Subject: [OpenAFS] questions about volume size? In-Reply-To: References: Message-ID: <20081007.105840.169660212.haba@habanero.pdc.kth.se> > one of our users has 1.7TB data. i asked him to reduce his data. he > already removed many files. currently, his folder size is 900GB. but, > his volume still occupied 1.7TB. is this normal? how could i reduce > his volume size? thanks for your help!! If you do a vos backup on the volume, the backup volume which shares the space with the regular volume should be synced (in size, too). Harald. From sysman@tiara.sinica.edu.tw Tue Oct 7 10:12:28 2008 From: sysman@tiara.sinica.edu.tw (TIARA System Man) Date: Tue, 7 Oct 2008 17:12:28 +0800 Subject: [OpenAFS] questions about volume size? In-Reply-To: <20081007.105840.169660212.haba@habanero.pdc.kth.se> References: <20081007.105840.169660212.haba@habanero.pdc.kth.se> Message-ID: hi harald, thanks for reply. however, i did not do vos backup. :) best, s On Tue, Oct 7, 2008 at 4:58 PM, Harald Barth wrote: > >> one of our users has 1.7TB data. i asked him to reduce his data. he >> already removed many files. currently, his folder size is 900GB. but, >> his volume still occupied 1.7TB. is this normal? how could i reduce >> his volume size? thanks for your help!! > > If you do a vos backup on the volume, the backup volume which shares > the space with the regular volume should be synced (in size, too). > > Harald. > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > -- Sam Tseng Academia Sinica Institute of Astronomy and Astrophysics Tel: +886-2-3365-2200 ext 742 Fax: +886-2-2367-7849 From haba@kth.se Tue Oct 7 10:30:31 2008 From: haba@kth.se (Harald Barth) Date: Tue, 07 Oct 2008 11:30:31 +0200 (CEST) Subject: [OpenAFS] questions about volume size? In-Reply-To: References: <20081007.105840.169660212.haba@habanero.pdc.kth.se> Message-ID: <20081007.113031.237383818.haba@habanero.pdc.kth.se> > thanks for reply. however, i did not do vos backup. :) To Sam: Never created a backup volume? To the community: How does this work "under the hood"? I thought, when I make a backup volume, files are "cloned" with link(2)? Is this the same for Namei and Inode? Does not look like it is done like that (all volumes on server pompano have backup volumes of the same size as the original ones) pompano# cd /vicepa/AFSIDat/p0/pGj+U/+/+/ pompano# ls -l total 5624 ---------- 1 root root 0 Sep 19 17:27 0++++6 ---------- 1 5937 adm 5754336 Sep 19 17:27 2++++A ---------- 1 adm root 2048 Sep 19 17:27 =++++2 pompano# stat 0++++6 File: `0++++6' Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: fd04h/64772d Inode: 2417392386 Links: 1 Access: (0000/----------) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2008-09-19 17:27:11.705744327 +0200 Modify: 2008-09-19 17:27:11.705744327 +0200 Change: 2008-09-19 17:27:11.705744327 +0200 So how is it done? Harald. From sysman@tiara.sinica.edu.tw Tue Oct 7 10:51:31 2008 From: sysman@tiara.sinica.edu.tw (TIARA System Man) Date: Tue, 7 Oct 2008 17:51:31 +0800 Subject: [OpenAFS] questions about volume size? In-Reply-To: <20081007091858.GA11284@garuru.org> References: <20081007091858.GA11284@garuru.org> Message-ID: dear armin, it looks like if i do salvage, afs server will shutdown for while. is it correct? [root@fs vicepc]# bos salvage -server fs -partition c bos: shutting down fs. Starting salvage. bos: waiting for salvage to complete. another question, is salvage better then zap? please tell me. thank you. best, s On Tue, Oct 7, 2008 at 5:18 PM, Armin Burchardt wrote: > Hi Sam! > > Did you salvage the partition? > $ bos salvage -server yourserver -partition a > (replace servername and partition with real data) > > Regards, > Armin > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkjrKX4ACgkQ5CNiFpMd5HjebwCeN8I924IZ4UlwSC5R5qhiAF/w > 0MwAoIYi12zhgygXvCD1TYTTiL2SNSzJ > =9yUC > -----END PGP SIGNATURE----- > > -- Sam Tseng Academia Sinica Institute of Astronomy and Astrophysics Tel: +886-2-3365-2200 ext 742 Fax: +886-2-2367-7849 From haba@kth.se Tue Oct 7 11:44:40 2008 From: haba@kth.se (Harald Barth) Date: Tue, 07 Oct 2008 12:44:40 +0200 (CEST) Subject: [OpenAFS] questions about volume size? In-Reply-To: References: <20081007.113031.237383818.haba@habanero.pdc.kth.se> Message-ID: <20081007.124440.204105468.haba@habanero.pdc.kth.se> > i tried to move this home.rwaur volume before. so, it did clone before move it. When you interrupt a vos move with ^C, it may leave clones lying around. That is a bug, but not an easy one to fix because all the logic is in vos and not the server. Unfortunately that means manual vos zap later. Harald. From haba@kth.se Tue Oct 7 11:46:46 2008 From: haba@kth.se (Harald Barth) Date: Tue, 07 Oct 2008 12:46:46 +0200 (CEST) Subject: [OpenAFS] questions about volume size? In-Reply-To: References: <20081007091858.GA11284@garuru.org> Message-ID: <20081007.124646.226745822.haba@habanero.pdc.kth.se> > it looks like if i do salvage, afs server will shutdown for while. is > it correct? If you salvage the whole server. if you salvage one volume, only that one is shut down. > another question, is salvage better then zap? please tell me. thank you. The can solve different problems, but both can solve "extra volumes lying around". Harald. From shadow@gmail.com Tue Oct 7 12:29:28 2008 From: shadow@gmail.com (Derrick Brashear) Date: Tue, 7 Oct 2008 07:29:28 -0400 Subject: [OpenAFS] Check for inode and namei support In-Reply-To: <20081007.101334.86114187.haba@habanero.pdc.kth.se> References: <1223317326.25871.17.camel@ruth.aloha.tallye.com> <20081007.101334.86114187.haba@habanero.pdc.kth.se> Message-ID: On Tue, Oct 7, 2008 at 4:13 AM, Harald Barth wrote: > >> > Also, is there a list of filesystems that OpenAFS requires for it's >> > inode fileserver? I assume that it's only usable on Linux with Ext2/3 >> > if inode is usable at all on Linux. Also, inode probably won't work on >> > ZFS in Solaris either. >> >> Never on Linux. Solaris ufs; Irix xfs; HP-UX hfs; AIX jfs; and nothing >> else, at least from memory. > > And I'd use namei on those, too. I just like to see that the data is > there. > > I avoid the following file system combinations: > reiserfs+anything (puts your files at risk) > Solaris+ufs+logging+inodefileserver (will eat your files) > jfs on Linux (untested) > > We should distribute solaris binaries for namei and inode. We do for Solaris 10. For older systems, if you already have them chances are you are already using inode fileserver. From chas@cmf.nrl.navy.mil Tue Oct 7 14:20:51 2008 From: chas@cmf.nrl.navy.mil (Chas Williams (CONTRACTOR)) Date: Tue, 07 Oct 2008 09:20:51 -0400 Subject: [OpenAFS] 1.4.8, Rx Performance Improvements, and a Small Business Innovative Research grant In-Reply-To: <20081007.100150.249414631.haba@habanero.pdc.kth.se> Message-ID: <200810071320.m97DKpfD004530@cmf.nrl.navy.mil> In message <20081007.100150.249414631.haba@habanero.pdc.kth.se>,Harald Barth wr ites: >As xplot was not available as portage I tried xplot->gnuplot. >Don't do that. The xplot graphics shows much better what is >going on than the converted gnuplot. I used xplot 0.90.7.1 >from http://www.xplot.org/. i added some sample plots from some early results. write.xplot shows a 1m write from a client to the server. it consists of two calls (and i think the retransmit message from rxtrace2xplot is bogus here since it doesnt understand the backward direction of the exchange). compare this with read.xplot from the same directory. this is a ready of a 1m file with a cache chunksize of 14. (i think i am missing some arrow heads). note that there is an rx call for chunksize. this makes the plot somewhat difficult to read but you can see that this doesnt perform well (perhaps i should put arrows pointing down for one direction and point up for the other direction). with 11 rx datagrams per read (2^14/RX_DATAGRAM_SIZE) you can see that rx never really gets out of slow start. you get 3 packets, 4 and then the last 4. next call, you restart at 3 packets again. the rx window never gets close to filling. also, every 11 packets, you need to wait for a another complete roundtrip to the server. so while rx could be improved, afs' usage thereof could be improved a bit. From jaltman@secure-endpoints.com Tue Oct 7 14:44:14 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Tue, 07 Oct 2008 09:44:14 -0400 Subject: [OpenAFS] 1.4.8, Rx Performance Improvements, and a Small Business Innovative Research grant In-Reply-To: <200810071320.m97DKpfD004530@cmf.nrl.navy.mil> References: <200810071320.m97DKpfD004530@cmf.nrl.navy.mil> Message-ID: <48EB67AE.6060705@secure-endpoints.com> Chas Williams (CONTRACTOR) wrote: > In message <20081007.100150.249414631.haba@habanero.pdc.kth.se>,Harald Barth wr > ites: >> As xplot was not available as portage I tried xplot->gnuplot. >> Don't do that. The xplot graphics shows much better what is >> going on than the converted gnuplot. I used xplot 0.90.7.1 >>from http://www.xplot.org/. > > i added some sample plots from some early results. > > write.xplot shows a 1m write from a client to the server. it consists of > two calls (and i think the retransmit message from rxtrace2xplot is bogus > here since it doesnt understand the backward direction of the exchange). > > compare this with read.xplot from the same directory. this is a ready > of a 1m file with a cache chunksize of 14. (i think i am missing some > arrow heads). note that there is an rx call for chunksize. this makes > the plot somewhat difficult to read but you can see that this doesnt > perform well (perhaps i should put arrows pointing down for one direction > and point up for the other direction). with 11 rx datagrams per read > (2^14/RX_DATAGRAM_SIZE) you can see that rx never really gets out of > slow start. you get 3 packets, 4 and then the last 4. next call, you > restart at 3 packets again. the rx window never gets close to filling. > also, every 11 packets, you need to wait for a another complete roundtrip > to the server. > > so while rx could be improved, afs' usage thereof could be improved a > bit. why is slow start "per call"? That can't be right. From chas@cmf.nrl.navy.mil Tue Oct 7 15:08:18 2008 From: chas@cmf.nrl.navy.mil (Chas Williams (CONTRACTOR)) Date: Tue, 07 Oct 2008 10:08:18 -0400 Subject: [OpenAFS] 1.4.8, Rx Performance Improvements, and a Small Business Innovative Research grant In-Reply-To: <48EB67AE.6060705@secure-endpoints.com> Message-ID: <200810071408.m97E8Ivd004977@cmf.nrl.navy.mil> In message <48EB67AE.6060705@secure-endpoints.com>,Jeffrey Altman writes: >why is slow start "per call"? That can't be right. i might be reading the graph wrong. it has been awhile. the read.xplot isnt quite right, so i cant see where we are waiting for acks. but just given the spacing on the x axis, it looks like there are 3 packets and then 4 packet and 4 packets. it might not be slow start, but one of the congestion windows? From jaltman@secure-endpoints.com Tue Oct 7 15:19:47 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Tue, 07 Oct 2008 10:19:47 -0400 Subject: [OpenAFS] 1.4.8, Rx Performance Improvements, and a Small Business Innovative Research grant In-Reply-To: <200810071408.m97E8Ivd004977@cmf.nrl.navy.mil> References: <200810071408.m97E8Ivd004977@cmf.nrl.navy.mil> Message-ID: <48EB7003.3070606@secure-endpoints.com> Chas Williams (CONTRACTOR) wrote: > In message <48EB67AE.6060705@secure-endpoints.com>,Jeffrey Altman writes: >> why is slow start "per call"? That can't be right. > > i might be reading the graph wrong. it has been awhile. the read.xplot > isnt quite right, so i cant see where we are waiting for acks. but > just given the spacing on the x axis, it looks like there are 3 > packets and then 4 packet and 4 packets. it might not be slow start, > but one of the congestion windows? Chas: I'm not suggesting the graph is wrong. I'm suggesting that Rx is brain dead. Jeffrey Altman From scs@umich.edu Tue Oct 7 21:08:34 2008 From: scs@umich.edu (Steve Simmons) Date: Tue, 7 Oct 2008 16:08:34 -0400 Subject: [OpenAFS] Sysid file and name/addr/uuid confusion In-Reply-To: <20081007.102639.99684892.haba@habanero.pdc.kth.se> References: <20081007.102639.99684892.haba@habanero.pdc.kth.se> Message-ID: <54402BAF-03D8-491D-AFC5-67682737DE5C@umich.edu> On Oct 7, 2008, at 4:26 AM, Harald Barth wrote: > >> for H in `vos listaddr -noauth | sort | uniq` ; do >> <> >> done > > Have you tried vos from 1.5.X which has the -noresolve? > Does it give you more information? Can't say - we already fixed the problem on the afflicted host, and haven't yet tried to duplicate it in our test cell. Steve From scs@umich.edu Tue Oct 7 21:10:45 2008 From: scs@umich.edu (Steve Simmons) Date: Tue, 7 Oct 2008 16:10:45 -0400 Subject: [OpenAFS] questions about volume size? In-Reply-To: References: <20081007.105840.169660212.haba@habanero.pdc.kth.se> Message-ID: <5C7C8484-E09A-4EF7-82E4-67A11B3DD049@umich.edu> If you ever even once did a vos backup on the volume, the .backup volume still exists and still consumes space. Do a vos examine on the volume and see if it shows one. On Oct 7, 2008, at 5:12 AM, TIARA System Man wrote: > hi harald, > > thanks for reply. however, i did not do vos backup. :) > > best, s > > On Tue, Oct 7, 2008 at 4:58 PM, Harald Barth wrote: >> >>> one of our users has 1.7TB data. i asked him to reduce his data. he >>> already removed many files. currently, his folder size is 900GB. >>> but, >>> his volume still occupied 1.7TB. is this normal? how could i reduce >>> his volume size? thanks for your help!! >> >> If you do a vos backup on the volume, the backup volume which shares >> the space with the regular volume should be synced (in size, too). >> >> Harald. >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info >> > > > > -- > Sam Tseng > Academia Sinica > Institute of Astronomy and Astrophysics > Tel: +886-2-3365-2200 ext 742 > Fax: +886-2-2367-7849 > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > > From terry@nd.edu Tue Oct 7 21:20:39 2008 From: terry@nd.edu (Terry McCoy) Date: Tue, 07 Oct 2008 16:20:39 -0400 Subject: [OpenAFS] Empty partitions Message-ID: <48EBC497.80103@nd.edu> I have noticed when I move all the volumes from an AFS file server's partition, there appears to be "left over" crud. Is it safe to delete the files and directories under the AFSIDat directory? Or is there anorther way for the file server to clean out the partition? See example below [root@foobar]# vos listvol foobar vicepio Total number of volumes on server foobar partition /vicepio: 0 Total volumes onLine 0 ; Total volumes offLine 0 ; Total busy 0 [root@foobar]# df -h /vicepio Filesystem Size Used Avail Use% Mounted on /dev/sda3 300G 3.1G 297G 2% /vicepio [root@foobar]# cd /vicepio [root@foobar# ls -la total 232 drwxrwxrwx 4 root root 208896 Oct 5 07:11 . drwxr-xr-x 30 root root 4096 Sep 12 16:07 .. drwx------ 258 root root 12288 Sep 12 23:48 AFSIDat drwx------ 2 root root 4096 Sep 12 16:08 Lock [root@foobar]# ls -la Lock total 212 drwx------ 2 root root 4096 Sep 12 16:08 . drwxrwxrwx 4 root root 208896 Oct 5 07:11 .. -rw------- 1 root root 0 Sep 12 16:08 vicepio [root@foobar# ls -l AFSIDat total 1028 drwx------ 3 root root 4096 Oct 5 07:07 = drwx------ 3 root root 4096 Oct 5 07:03 == drwx------ 3 root root 4096 Oct 5 07:05 + drwx------ 3 root root 4096 Oct 5 06:59 += drwx------ 3 root root 4096 Oct 5 07:03 0 drwx------ 3 root root 4096 Oct 5 07:10 =0 drwx------ 3 root root 4096 Oct 5 07:04 +0 drwx------ 3 root root 4096 Oct 5 07:04 0= drwx------ 3 root root 4096 Oct 5 07:04 00 drwx------ 3 root root 4096 Oct 5 07:06 01 drwx------ 3 root root 4096 Oct 5 07:07 1 drwx------ 3 root root 4096 Oct 5 07:08 =1 drwx------ 3 root root 4096 Oct 5 07:01 +1 drwx------ 3 root root 4096 Oct 5 07:09 1= drwx------ 3 root root 4096 Oct 5 07:10 10 drwx------ 3 root root 4096 Oct 5 07:04 11 drwx------ 3 root root 4096 Oct 5 06:59 2 drwx------ 3 root root 4096 Oct 5 06:54 2= -- +-- -- -- -- -- -- -- -- -- -- -- -- -- + | | | Terry McCoy email: terry@nd.edu | | Sr Systems Engineer phone: (574) 631-4274 | | | | Office of Information Technologies | | 315 Information Technology Center | | University of Notre Dame | | Notre Dame, Indiana 46556 | | | | | | perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' | | | +-- -- -- -- -- -- -- -- -- -- -- -- -- + From jason@rampaginggeek.com Thu Oct 9 03:03:48 2008 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Wed, 08 Oct 2008 22:03:48 -0400 Subject: [OpenAFS] results for 1.4.8pre2 on Mac OS X Tiger PPC Message-ID: <48ED6684.5000909@rampaginggeek.com> I compiled 1.4.8pre2 for Mac OS X tiger ppc and installed it. Things look good. I have one observation though. Is it normal for files to disappear from the finder when clicking on them? My home directory has "system:anyuser l" acl. I browsed to it in finder while unauthenticated. After I authenticated, the folders with the "no entry" icon didn't change but I could browse in them. Strangely, the files in my home directory would disappear when I clicked on them in finder. Things work fine if I authenticate before opening finder. IO had to log out and back int to clear the icons. Is this expected behavior? Thanks, Jason From jaltman@secure-endpoints.com Thu Oct 9 03:15:38 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 08 Oct 2008 22:15:38 -0400 Subject: [OpenAFS] results for 1.4.8pre2 on Mac OS X Tiger PPC In-Reply-To: <48ED6684.5000909@rampaginggeek.com> References: <48ED6684.5000909@rampaginggeek.com> Message-ID: <48ED694A.7050804@secure-endpoints.com> Jason Edgecombe wrote: > I compiled 1.4.8pre2 for Mac OS X tiger ppc and installed it. > > Things look good. > > I have one observation though. Is it normal for files to disappear from > the finder when clicking on them? My home directory has "system:anyuser > l" acl. I browsed to it in finder while unauthenticated. After I > authenticated, the folders with the "no entry" icon didn't change but I > could browse in them. Strangely, the files in my home directory would > disappear when I clicked on them in finder. Things work fine if I > authenticate before opening finder. IO had to log out and back int to > clear the icons. > > Is this expected behavior? > > Thanks, > Jason This is expected. Finder unclutters the view by removing objects that you do not have permission to open. Jeffrey Altman From jason@rampaginggeek.com Thu Oct 9 03:12:35 2008 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Wed, 08 Oct 2008 22:12:35 -0400 Subject: [OpenAFS] disk free in finder? Message-ID: <48ED6893.9060905@rampaginggeek.com> I noticed that the disk free space in finder shows ~976GB. Thanks for bumping that up. Should that be bumped again to 2TB just to account for the possible case that someone may drag a 2TB file into a 2TB volume? What is the impact of bumping the limit again? Thanks, Jason From afs@freakout.de Thu Oct 9 07:09:13 2008 From: afs@freakout.de (Axel Reinhold) Date: Thu, 9 Oct 2008 08:09:13 +0200 Subject: [OpenAFS] 1.5.53 and 1.5.54 do no more compile with Linux 2.4 Message-ID: <200810090609.m9969DTb002960@bongo.freakout.de> While 1.5.52 did well with Linux 2.4 - since the last two versions 1.5.53 and 1.5.54 no more compiling: openafs-1.5.54/src/afs/LINUX/osi_vnodeops.c: In function 'afs_linux_read': openafs-1.5.54/src/afs/LINUX/osi_vnodeops.c:97: error: 'struct file' has no member named 'f_mapping' From muksyed@stanford.edu Thu Oct 9 07:53:33 2008 From: muksyed@stanford.edu (Mukarram Syed) Date: Wed, 8 Oct 2008 23:53:33 -0700 Subject: [OpenAFS] unsubscribe Message-ID: <025501c929db$c1325e10$8c1942ab@stanford.edu> This is a multi-part message in MIME format. ------=_NextPart_000_0256_01C929A1.14D38610 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ------=_NextPart_000_0256_01C929A1.14D38610 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

------=_NextPart_000_0256_01C929A1.14D38610-- From shadow@gmail.com Thu Oct 9 13:56:12 2008 From: shadow@gmail.com (Derrick Brashear) Date: Thu, 9 Oct 2008 08:56:12 -0400 Subject: [OpenAFS] 1.5.53 and 1.5.54 do no more compile with Linux 2.4 In-Reply-To: <200810090609.m9969DTb002960@bongo.freakout.de> References: <200810090609.m9969DTb002960@bongo.freakout.de> Message-ID: Fix in CVS. Grab delta DEVEL15-bypasscache-fix-linux24-20081009 and apply. On Thu, Oct 9, 2008 at 2:09 AM, Axel Reinhold wrote: > While 1.5.52 did well with Linux 2.4 - since the last two versions 1.5.53 and 1.5.54 no more compiling: > > openafs-1.5.54/src/afs/LINUX/osi_vnodeops.c: In function 'afs_linux_read': > openafs-1.5.54/src/afs/LINUX/osi_vnodeops.c:97: error: 'struct file' has no member named 'f_mapping' From shadow@gmail.com Thu Oct 9 15:36:26 2008 From: shadow@gmail.com (Derrick Brashear) Date: Thu, 9 Oct 2008 10:36:26 -0400 Subject: [OpenAFS] disk free in finder? In-Reply-To: <48ED6893.9060905@rampaginggeek.com> References: <48ED6893.9060905@rampaginggeek.com> Message-ID: On Wed, Oct 8, 2008 at 10:12 PM, Jason Edgecombe wrote: > I noticed that the disk free space in finder shows ~976GB. Thanks for > bumping that up. Should that be bumped again to 2TB just to account for > the possible case that someone may drag a 2TB file into a 2TB volume? > > What is the impact of bumping the limit again? It probably should go to 2tb. The math behind this is sort of wretched. From john@iastate.edu Thu Oct 9 15:42:34 2008 From: john@iastate.edu (John Hascall) Date: Thu, 09 Oct 2008 09:42:34 CDT Subject: [OpenAFS] OpenAFS Crash on Vista Message-ID: <9986.1223563354@malison.ait.iastate.edu> Is this kind of thing of any value? Problem signature: Problem Event Name: APPCRASH Application Name: afsd_service.exe Application Version: 1.5.5000.0 Application Timestamp: 487e13a8 Fault Module Name: MSVCR80.dll Fault Module Version: 8.0.50727.805 Fault Module Timestamp: 45d27cd1 Exception Code: c0000005 Exception Offset: 000172d7 OS Version: 6.0.6000.2.0.0.256.4 Locale ID: 1033 Additional Information 1: 1be8 Additional Information 2: 48b515cc25cd7357d1da518e9bdd0b82 Additional Information 3: a5e1 Additional Information 4: 83754147814c8703abf135f9f75608c2 From shadow@gmail.com Thu Oct 9 15:46:29 2008 From: shadow@gmail.com (Derrick Brashear) Date: Thu, 9 Oct 2008 10:46:29 -0400 Subject: [OpenAFS] OpenAFS Crash on Vista In-Reply-To: <9986.1223563354@malison.ait.iastate.edu> References: <9986.1223563354@malison.ait.iastate.edu> Message-ID: One from 1.5.54 might be of more value :) On Thu, Oct 9, 2008 at 10:42 AM, John Hascall wrote: > > Is this kind of thing of any value? > > Problem signature: > Problem Event Name: APPCRASH > Application Name: afsd_service.exe > Application Version: 1.5.5000.0 > Application Timestamp: 487e13a8 > Fault Module Name: MSVCR80.dll > Fault Module Version: 8.0.50727.805 > Fault Module Timestamp: 45d27cd1 > Exception Code: c0000005 > Exception Offset: 000172d7 > OS Version: 6.0.6000.2.0.0.256.4 > Locale ID: 1033 > Additional Information 1: 1be8 > Additional Information 2: 48b515cc25cd7357d1da518e9bdd0b82 > Additional Information 3: a5e1 > Additional Information 4: 83754147814c8703abf135f9f75608c2 > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > From john@iastate.edu Thu Oct 9 15:52:31 2008 From: john@iastate.edu (John Hascall) Date: Thu, 09 Oct 2008 09:52:31 CDT Subject: [OpenAFS] OpenAFS Crash on Vista In-Reply-To: Your message of Thu, 09 Oct 2008 10:46:29 -0400. Message-ID: <10012.1223563951@malison.ait.iastate.edu> I am just a simple unfrozen caveman, but your system of numbers confuses me... 1.5.54 > 1.5.5000 ? Plus all this talk about 1.4.8 as if it is the latest and greatest thing... John > One from 1.5.54 might be of more value :) > > On Thu, Oct 9, 2008 at 10:42 AM, John Hascall wrote: > > > > Is this kind of thing of any value? > > > > Problem signature: > > Problem Event Name: APPCRASH > > Application Name: afsd_service.exe > > Application Version: 1.5.5000.0 > > Application Timestamp: 487e13a8 > > Fault Module Name: MSVCR80.dll > > Fault Module Version: 8.0.50727.805 > > Fault Module Timestamp: 45d27cd1 > > Exception Code: c0000005 > > Exception Offset: 000172d7 > > OS Version: 6.0.6000.2.0.0.256.4 > > Locale ID: 1033 > > Additional Information 1: 1be8 > > Additional Information 2: 48b515cc25cd7357d1da518e9bdd0b82 > > Additional Information 3: a5e1 > > Additional Information 4: 83754147814c8703abf135f9f75608c2 From shadow@gmail.com Thu Oct 9 15:56:16 2008 From: shadow@gmail.com (Derrick Brashear) Date: Thu, 9 Oct 2008 10:56:16 -0400 Subject: [OpenAFS] OpenAFS Crash on Vista In-Reply-To: <10012.1223563951@malison.ait.iastate.edu> References: <10012.1223563951@malison.ait.iastate.edu> Message-ID: 1.5.5400 (which is 1.5.54) > 1.5.5000 (1.5.50) On Thu, Oct 9, 2008 at 10:52 AM, John Hascall wrote: > > > I am just a simple unfrozen caveman, > but your system of numbers confuses me... > > 1.5.54 > 1.5.5000 ? If you were from Omicron-Perseii 8, it would also infuriate you. From ksumner@email.unc.edu Thu Oct 9 16:33:50 2008 From: ksumner@email.unc.edu (Kevin Sumner) Date: Thu, 09 Oct 2008 11:33:50 -0400 Subject: [OpenAFS] OpenAFS Crash on Vista In-Reply-To: References: <10012.1223563951@malison.ait.iastate.edu> Message-ID: <48EE245E.2090105@email.unc.edu> Also, concerning 1.4.x vs. 1.5.x: 1.4.8 is the soon-to-be-latest-and-greatest... in the Maintenance branch. It's recommended that Windows users use the Features branch, 1.5. It's like Linux used to do with 2.4 & 2.5 -- 2.4 was the more stable branch, but you got lots of latest-and-greatest in 2.5... and a few more bugs as a bonus. In 1.5, 1.5.54 is the latest-and-greatest. This should probably be in the docs somewhere, or at least more exposed -- I couldn't find it quickly on openafs.org. As for the issues on Vista, I've got Vista Enterprise 32-bit here at work, and upgrading from 1.5.52 to .54 has resolved at least a few of my strange-though-not-oft-encountered problems. Cheers, Kevin -- Kevin Sumner ITS Enterprise Storage Management University of North Carolina at Chapel Hill CB# 1150, 440 W. Franklin Street, Office G408 Chapel Hill, NC 27599-1150 T: (919) 962-1547 M: (919) 259-9734 F: (919) 445-9485 kevin_sumner@unc.edu Derrick Brashear wrote: > 1.5.5400 (which is 1.5.54) > 1.5.5000 (1.5.50) > > On Thu, Oct 9, 2008 at 10:52 AM, John Hascall wrote: >> >> I am just a simple unfrozen caveman, >> but your system of numbers confuses me... >> >> 1.5.54 > 1.5.5000 ? > > If you were from Omicron-Perseii 8, it would also infuriate you. > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info From jaltman@secure-endpoints.com Thu Oct 9 16:51:09 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 09 Oct 2008 11:51:09 -0400 Subject: [OpenAFS] OpenAFS Crash on Vista In-Reply-To: <9986.1223563354@malison.ait.iastate.edu> References: <9986.1223563354@malison.ait.iastate.edu> Message-ID: <48EE286D.9050808@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms090200070306080107030100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Not really. The 1.5.5000.0 (1.5.50) builds are several months old and many many bugs have already been fixed in them. Especially without an afsd.dmp file to provide a stack trace it would not be worth my time to investigate the cause of this issue. Jeffrey Altman John Hascall wrote: > Is this kind of thing of any value? > > Problem signature: > Problem Event Name: APPCRASH > Application Name: afsd_service.exe > Application Version: 1.5.5000.0 > Application Timestamp: 487e13a8 > Fault Module Name: MSVCR80.dll > Fault Module Version: 8.0.50727.805 > Fault Module Timestamp: 45d27cd1 > Exception Code: c0000005 > Exception Offset: 000172d7 > OS Version: 6.0.6000.2.0.0.256.4 > Locale ID: 1033 > Additional Information 1: 1be8 > Additional Information 2: 48b515cc25cd7357d1da518e9bdd0b82 > Additional Information 3: a5e1 > Additional Information 4: 83754147814c8703abf135f9f75608c2 > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info --------------ms090200070306080107030100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMDkxNTUxMTBaMCMGCSqGSIb3DQEJBDEWBBR+lcQz SjycbhxUF1Ej9PzqRgeebjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAE4KCPHSNIfie7mHIMkPPU/UqjrcZfEUzo0IlfJuPmSW+w/NR4eZt x2YoxdY1p7FhQomoBIqHz4wRuITyt6LTiGBwW5HwMpee74kxRmMhjtHXOzbPNaK/HmC6lzf0 hj0yj6AhtWlzmClmiYjdiRzFuQygrBd7OefRBmjsT1n6Qsj328SLK4HQQ05nzNhq9OUuZi1J B19yiN2KeDfYd5Q9v1Gz8RfoqNAMrUv38O4NVAHAmhGTWuuE7Wi2/BKA0JU5z3l9ERRJcR5Z BgFN/2fbLFLPDWCi/FlAPpn7QrsDzzdBeCyf61YXXODwjAYQ28z8RjDJRxUjiBvEyKYBzLZU LAAAAAAAAA== --------------ms090200070306080107030100-- From avison48@yahoo.co.uk Thu Oct 9 17:33:09 2008 From: avison48@yahoo.co.uk (avison48) Date: Thu, 9 Oct 2008 16:33:09 +0000 (GMT) Subject: [OpenAFS] Re: Win2K AFS server, setup SL4.5 test-cell server then migrate... Message-ID: <981623.59083.qm@web27308.mail.ukl.yahoo.com> Greetings all, Couple questions to clarify, in learning about two very different AFS conte= xts (old =3D IBM/TA 3.5 Win2K, new =3D OpenAFS RHEL4.5) I think this is true - with OpenAFS, there are AFS accounts & Kerberos principals (entities/accounts so to speak) but only the Kerberos one has a password. Is that Correct? (That is the opposite of our current sytem where AFS accounts have nothing= =20 to do with Kerberos AFACT - ) Is this true: an OpenAFS "account" (made with pts createuser) can't=20 authenticate to AFS (that is to be able to use AFS dataspace) without a=20 Kerberos principal. Or if it can, how ? Thank you! It's coming along thanks to the kind help of people here! =0A=0A=0A From jaltman@secure-endpoints.com Thu Oct 9 18:31:40 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 09 Oct 2008 13:31:40 -0400 Subject: [OpenAFS] Re: Win2K AFS server, setup SL4.5 test-cell server then migrate... In-Reply-To: <981623.59083.qm@web27308.mail.ukl.yahoo.com> References: <981623.59083.qm@web27308.mail.ukl.yahoo.com> Message-ID: <48EE3FFC.6050902@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms000106010704020508060703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit avison48 wrote: > Greetings all, > > Couple questions to clarify, in learning about two very different AFS contexts (old = IBM/TA 3.5 Win2K, new = OpenAFS RHEL4.5) > > I think this is true - with OpenAFS, there are AFS accounts & Kerberos > principals (entities/accounts so to speak) but only the Kerberos one has a > password. > Is that Correct? > > (That is the opposite of our current sytem where AFS accounts have nothing > to do with Kerberos AFACT - ) > > > Is this true: an OpenAFS "account" (made with pts createuser) can't > authenticate to AFS (that is to be able to use AFS dataspace) without a > Kerberos principal. Or if it can, how ? > > > Thank you! > It's coming along thanks to the kind help of people here! pts createuser creates a mapping between an authenticated name and a numeric ID value assigned to a user. There is no authentication information provided there. The authentication either comes from the AFS kaserver (which is a variation on a Kerberos v4 KDC) or a native Kerberos realm. Jeffrey Altman --------------ms000106010704020508060703 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMDkxNzMxNDBaMCMGCSqGSIb3DQEJBDEWBBT7Te/a yol0XcHr9qh7E5cWyAu6/jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAMdpG2+sLpf+5x2R2sZ05OVXGLamNF+F3QpJA9I6Z7qiF65n+8hV2 EG3l4kiHv2qGMcvfPhueHmea8k/bni9pybmrrp1mfm6qnLWf9VJKfA846rEiDhyB2+bBVzNn hO37I+uc3dMXt7gh3MhQhZQWCIlT9Z4vWrvl7gUyPseqW4LoCIB1eufpBMHRh2s0oDiOkbMa 6aNG51IhfnGLoBGeoL2T2ngVPTCPXXEmin/HYXaMhkjyzl3zeq/hEmqAY8hiocl+9F8OWrIl HNRVQ0VuY0HcXdzf910SwqRtvShvIomLheK2dCEFlu8MnTqqhrlS+QmUvldeMYm/ozZRqBJ4 FAAAAAAAAA== --------------ms000106010704020508060703-- From pohl@syssoft.uni-trier.de Thu Oct 9 19:26:50 2008 From: pohl@syssoft.uni-trier.de (Stefan Pohl) Date: Thu, 09 Oct 2008 20:26:50 +0200 Subject: [OpenAFS] 1.4.8pre2 partial success on OpenSolaris (after bugfix) Message-ID: <48EE4CEA.4090302@syssoft.uni-trier.de> Hi, after applying a simple bugfix (see bug #119443, this should also be relevant to HPUX and DUX) it is possible to load the nonfs kernelmodule on OpenSolaris Systems. Server and client daemons can be started and everything seems to work OK sofar. I tested this with OpenSolaris build 98 on i386 and amd64. I can't comment on stability yet, since I just started evaluating OpenAFS for possible production use in our workgroup and these are the first test machines. As for the bugfix: I simply replaced src/afs/afs_osi.h with the version from 1.4.7 release, since the only changes between the two are the changes that caused the breakage: > atlas:~/downloads # diff openafs-1.4.8pre2/src/afs/afs_osi.h > openafs-1.4.7/src/afs/afs_osi.h > 152a153,161 > > #ifdef AFS_SGI65_ENV > > #define gop_lookupname(fnamep,segflg,followlink,compvpp) \ > > lookupname((fnamep),(segflg),(followlink),NULL,(compvpp),\ > > NULL) > > #else > > #define gop_lookupname(fnamep,segflg,followlink,compvpp) \ > > lookupname((fnamep),(segflg),(followlink),NULL,(compvpp)) > > #endif > > As for the partial success: - nfs-enabled kernel modules are not still not build (bug #119118) - kdump is still not compiled (bug #117749) But at least OpenAFS is now useable again on OpenSolaris. By wading through the compiler/gmake output produced by building OpenAFS, I noticed a couple of things and I'm not shure how serious they are. Please let me know if these are serious problems, and if I should file bug-reports on them: - in total 1847 warnings on 'implicit function declaration' of functions like des_key_sched, ubik_Call, setpag, des_read_pw_strig, geteuid, etc. just to mention a few of them - compilation of fc_test.c produces following output: /opt/SUNWspro/bin/cc -O -I/sherman/admin_pohl/downloads/openafs-1.4.8pre2/src/config -I. -I. -I/sherman/admin_pohl/downloads/openafs-1.4.8pre2/include -I/sherman/admin_pohl/downloads/openafs-1.4.8pre2/include/afs -I/sherman/admin_pohl/downloads/openafs-1.4.8pre2/include/rx -I/sherman/admin_pohl/downloads/openafs-1.4.8pre2 -I/sherman/admin_pohl/downloads/openafs-1.4.8pre2/src -I/sherman/admin_pohl/downloads/openafs-1.4.8pre2/src -dy -Bdynamic -c fc_test.c "fc_test.c", line 56: warning: initializer does not fit or is out of range: 240 "fc_test.c", line 56: warning: initializer does not fit or is out of range: 230 "fc_test.c", line 56: warning: initializer does not fit or is out of range: 130 "fc_test.c", line 56: warning: initializer does not fit or is out of range: 238 "fc_test.c", line 56: warning: initializer does not fit or is out of range: 172 "fc_test.c", line 56: warning: initializer does not fit or is out of range: 152 "fc_test.c", line 57: warning: initializer does not fit or is out of range: 228 "fc_test.c", line 57: warning: initializer does not fit or is out of range: 132 "fc_test.c", line 57: warning: initializer does not fit or is out of range: 195 "fc_test.c", line 57: warning: initializer does not fit or is out of range: 216 "fc_test.c", line 57: warning: initializer does not fit or is out of range: 170 "fc_test.c", line 57: warning: initializer does not fit or is out of range: 174 "fc_test.c", line 57: warning: initializer does not fit or is out of range: 247 "fc_test.c", line 58: warning: initializer does not fit or is out of range: 210 "fc_test.c", line 58: warning: initializer does not fit or is out of range: 217 "fc_test.c", line 58: warning: initializer does not fit or is out of range: 163 "fc_test.c", line 58: warning: initializer does not fit or is out of range: 181 "fc_test.c", line 58: warning: initializer does not fit or is out of range: 215 "fc_test.c", line 59: warning: initializer does not fit or is out of range: 245 "fc_test.c", line 59: warning: initializer does not fit or is out of range: 209 "fc_test.c", line 59: warning: initializer does not fit or is out of range: 248 "fc_test.c", line 59: warning: initializer does not fit or is out of range: 145 "fc_test.c", line 59: warning: initializer does not fit or is out of range: 172 "fc_test.c", line 59: warning: initializer does not fit or is out of range: 146 "fc_test.c", line 60: warning: initializer does not fit or is out of range: 239 "fc_test.c", line 65: warning: initializer does not fit or is out of range: 202 "fc_test.c", line 65: warning: initializer does not fit or is out of range: 144 "fc_test.c", line 65: warning: initializer does not fit or is out of range: 245 "fc_test.c", line 65: warning: initializer does not fit or is out of range: 157 "fc_test.c", line 65: warning: initializer does not fit or is out of range: 203 "fc_test.c", line 65: warning: initializer does not fit or is out of range: 212 "fc_test.c", line 65: warning: initializer does not fit or is out of range: 210 "fc_test.c", line 65: warning: initializer does not fit or is out of range: 136 "fc_test.c", line 66: warning: initializer does not fit or is out of range: 157 "fc_test.c", line 66: warning: initializer does not fit or is out of range: 216 "fc_test.c", line 66: warning: initializer does not fit or is out of range: 224 "fc_test.c", line 66: warning: initializer does not fit or is out of range: 163 "fc_test.c", line 67: warning: initializer does not fit or is out of range: 254 "fc_test.c", line 67: warning: initializer does not fit or is out of range: 221 "fc_test.c", line 67: warning: initializer does not fit or is out of range: 224 "fc_test.c", line 67: warning: initializer does not fit or is out of range: 137 "fc_test.c", line 68: warning: initializer does not fit or is out of range: 142 "fc_test.c", line 68: warning: initializer does not fit or is out of range: 140 "fc_test.c", line 68: warning: initializer does not fit or is out of range: 148 "fc_test.c", line 68: warning: initializer does not fit or is out of range: 252 "fc_test.c", line 68: warning: initializer does not fit or is out of range: 199 "fc_test.c", line 68: warning: initializer does not fit or is out of range: 228 "fc_test.c", line 68: warning: initializer does not fit or is out of range: 136 "fc_test.c", line 68: warning: initializer does not fit or is out of range: 170 "fc_test.c", line 68: warning: initializer does not fit or is out of range: 222 "fc_test.c", line 107: warning: argument #1 is incompatible with prototype: prototype: pointer to struct ktc_encryptionKey {array[8] of char data} : "rxkad_prototypes.h", line 29 argument : pointer to const unsigned char "fc_test.c", line 109: warning: argument #1 is incompatible with prototype: prototype: pointer to void : "rxkad_prototypes.h", line 33 argument : pointer to const char "fc_test.c", line 124: warning: argument #1 is incompatible with prototype: prototype: pointer to struct ktc_encryptionKey {array[8] of char data} : "rxkad_prototypes.h", line 29 argument : pointer to const unsigned char "fc_test.c", line 126: warning: argument #1 is incompatible with prototype: prototype: pointer to void : "rxkad_prototypes.h", line 33 argument : pointer to const char "fc_test.c", line 141: warning: argument #1 is incompatible with prototype: prototype: pointer to struct ktc_encryptionKey {array[8] of char data} : "rxkad_prototypes.h", line 29 argument : pointer to const unsigned char "fc_test.c", line 149: warning: argument #2 is incompatible with prototype: prototype: pointer to array[16] of const int : "rxkad_prototypes.h", line 22 argument : pointer to int "fc_test.c", line 149: warning: argument #3 is incompatible with prototype: prototype: pointer to array[2] of const int : "rxkad_prototypes.h", line 22 argument : pointer to unsigned int "fc_test.c", line 150: warning: argument #2 is incompatible with prototype: prototype: pointer to array[16] of const int : "rxkad_prototypes.h", line 18 argument : pointer to int "fc_test.c", line 150: warning: argument #3 is incompatible with prototype: prototype: pointer to array[2] of const int : "rxkad_prototypes.h", line 18 argument : pointer to unsigned int "fc_test.c", line 162: warning: argument #1 is incompatible with prototype: prototype: pointer to struct ktc_encryptionKey {array[8] of char data} : "rxkad_prototypes.h", line 29 argument : pointer to const unsigned char "fc_test.c", line 165: warning: argument #1 is incompatible with prototype: prototype: pointer to struct ktc_encryptionKey {array[8] of char data} : "rxkad_prototypes.h", line 29 argument : pointer to const unsigned char "fc_test.c", line 181: warning: argument #1 is incompatible with prototype: prototype: pointer to void : "rxkad_prototypes.h", line 33 argument : pointer to const char "fc_test.c", line 185: warning: argument #1 is incompatible with prototype: prototype: pointer to void : "rxkad_prototypes.h", line 33 argument : pointer to const char Stefan Pohl -- Stefan Pohl | pohl@syssoft.uni-trier.de | pohl@informatik.uni-trier.de Administrator Informatik Uni Trier Administrator Systemsoftware und verteilte Systeme Uni Trier Raum-Nr.: H515, H507, H504 From jkoyle@koyle.org Thu Oct 9 21:27:57 2008 From: jkoyle@koyle.org (John Koyle) Date: Thu, 09 Oct 2008 14:27:57 -0600 Subject: [OpenAFS] OS X Leopard token grabbing Message-ID: <48EE694D.3060105@koyle.org> I have the latest client on Leopard with the kerb extras package. I'm able to obtain a kerb ticket via the kerberos app, however I must open a terminal and issue aklog to obtain an AFS token. Is there a recommended way for integrating these two steps in a simple way for our users? Most of the solutions I've found to this point are for Tiger. Thanks, John From shadow@gmail.com Thu Oct 9 22:09:36 2008 From: shadow@gmail.com (Derrick Brashear) Date: Thu, 9 Oct 2008 17:09:36 -0400 Subject: [OpenAFS] OS X Leopard token grabbing In-Reply-To: <48EE694D.3060105@koyle.org> References: <48EE694D.3060105@koyle.org> Message-ID: check out the AFSCommander package. Derrick On Oct 9, 2008, at 16:27, John Koyle wrote: > I have the latest client on Leopard with the kerb extras package. I'm > able to obtain a kerb ticket via the kerberos app, however I must > open a > terminal and issue aklog to obtain an AFS token. > > Is there a recommended way for integrating these two steps in a simple > way for our users? Most of the solutions I've found to this point are > for Tiger. > > Thanks, > John > > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info From marc.c.dionne@gmail.com Fri Oct 10 00:54:54 2008 From: marc.c.dionne@gmail.com (Marc Dionne) Date: Thu, 09 Oct 2008 19:54:54 -0400 Subject: [OpenAFS] openafs-1.4.8pre2: Success on Fedora 10, kernel 2.6.27 Message-ID: <48EE99CE.3050706@gmail.com> I can report success building and running openafs-1.4.8pre2 client on 64-bit Fedora 10 (rawhide) and a locally built kernel 2.6.27 (release version). Marc From stefaan.deroeck@gmail.com Fri Oct 10 12:11:56 2008 From: stefaan.deroeck@gmail.com (Stefaan) Date: Fri, 10 Oct 2008 13:11:56 +0200 Subject: [OpenAFS] 1.4.8_pre2: Failure on Gentoo stable amd64 Message-ID: <28edf05e0810100411t32f182b9x779aebeeb1e0af4e@mail.gmail.com> Hi! On my linux-x86_64 box, running kernel 2.6.25-gentoo-r7, gcc-4.1.2, glibc-2.6.1, I get this error with 1.4.8_pre2. I haven't yet tried a downgrade to 1.4.7, but that version used to work fine on this machine... This is repeatable, I have had to reboot multiple times already. On my linux-x86_64 box running kernel 2.6.26-gentoo, gcc-4.3.1, glibc-2.8_p20080602, I haven't yet got errors like these. The new openafs-prerelease hasn't been used extensively on either machine up until now. Any ideas? Many thanks, Stefaan libafs: module license 'http://www.openafs.org/dl/license10.html' taints kernel. Symbol init_mm is marked as UNUSED, however this module is using it. This symbol will go away in the future. Please evalute if this is the right api to use, and if it really is, submit a report the linux kernel mailinglist together with submitting your code for inclusion. Found system call table at 0xffffffff805f37e0 (pattern scan) Found 32-bit system call table at 0xfffffffffffffffe (exported) Address 0xfffffffffffffffe is not writable. System call hooks will not be installed; proceeding anyway Starting AFS cache scan...Memory cache: Allocating 1562 dcache entries...found 0 non-empty cache files (0%). BUG: unable to handle kernel paging request at fffffffffffffffe IP: [] _read_lock+0x11/0x20 PGD 203067 PUD 204067 PMD 0 Oops: 0002 [1] PREEMPT SMP CPU 0 Modules linked in: libafs(P) iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_atiixp parport_pc snd_ac97_codec parport ac97_bus ohci1394 ieee1394 snd_pcm snd_timer k8temp i2c_piix4 i2c_core snd snd_page_alloc Pid: 28968, comm: afsd Tainted: P 2.6.25-gentoo-r7 #2 RIP: 0010:[] [] _read_lock+0x11/0x20 RSP: 0018:ffff810014685e70 EFLAGS: 00010213 RAX: ffff810014685fd8 RBX: fffffffffffffffe RCX: 0000000000000002 RDX: 0000000000000000 RSI: 0000000000000010 RDI: fffffffffffffffe RBP: fffffffffffffffe R08: 0000000000000001 R09: ffff810034ae7740 R10: 0000000000000000 R11: 2222222222222222 R12: 0000000048ef26fd R13: 0000000048ef26c6 R14: 0000000048ef26c6 R15: 0000000048ef26fd FS: 00007fc9c746f700(0000) GS:ffffffff807ab000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: fffffffffffffffe CR3: 000000000b5fc000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process afsd (pid: 28968, threadinfo ffff810014684000, task ffff81000db27820) Stack: ffff810014685eec ffffffff8811bd9a 0000000048ef26fd ffff810014685eec 0000000048ef26fd ffffffff88122834 0000000048ef26fd ffffffff88110906 48ef1ace48ef26b4 0000000048ef26c6 0000000048ef26fd 0000000026b7b379 Call Trace: [] ? :libafs:afs_osi_TraverseProcTable+0x1a/0xb0 [] ? :libafs:afs_GCPAGs+0xa4/0x190 [] ? :libafs:afs_Daemon+0x506/0x530 [] ? :libafs:afsd_launcher+0x0/0x7b0 [] ? :libafs:afsd_launcher+0x36d/0x7b0 [] ? schedule_tail+0x39/0x80 [] ? child_rip+0xa/0x12 [] ? :libafs:afsd_launcher+0x0/0x7b0 [] ? :libafs:afsd_launcher+0x40/0x7b0 [] ? child_rip+0x0/0x12 Code: 00 00 f0 66 0f c1 03 38 e0 74 06 f3 90 8a 03 eb f6 5b c3 0f 1f 80 00 00 00 00 53 48 89 fb bf 01 00 00 00 e8 22 31 00 00 48 89 df 83 2f 01 79 05 e8 14 3f db ff 5b c3 66 90 48 83 ec 18 48 89 RIP [] _read_lock+0x11/0x20 RSP CR2: fffffffffffffffe ---[ end trace bed264b5fe6403b8 ]--- note: afsd[28968] exited with preempt_count 1 From Volker.Lendecke@SerNet.DE Mon Oct 6 06:26:28 2008 From: Volker.Lendecke@SerNet.DE (Volker Lendecke) Date: Mon, 6 Oct 2008 07:26:28 +0200 Subject: [OpenAFS] Re: Linking GPL3 code with IPL? (Was: afs_syscall (Samba as a client of OpenAFS)) In-Reply-To: <48E92662.7060608@kzsdabas.hu> References: <48DFDFCE.2090809@kzsdabas.hu> <48E92662.7060608@kzsdabas.hu> Message-ID: --5QAgd0e35j3NYeGe Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 05, 2008 at 10:41:06PM +0200, G=E9mes G=E9za wrote: > I've built up a patch (attachment 3658 to bug 5799 on samba bugzilla) > which makes fake-kaserver and vfs-afsacl work again. > But the patched configure makes smbd, net and maybe other binaries link > with libsys.a in order to communicate with the openafs kernel code. The > question is what are the legal consequences, are the binaries > distributable et all? At the time I wrote the fake kaserver stuff I had the same concerns and thus did a fresh implementation of the ticket generation and syscall wrappers. Can't you do the same with the proc_afs_syscall thing? This can't be much code. Volker --5QAgd0e35j3NYeGe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFI6aGDUzqjrWwMRl0RArc1AJ9ugLNYn0IzSEFaGIQOlOleFYVtqQCeNa7Q erAxn053rgIpY5m17y1tvp0= =eQi0 -----END PGP SIGNATURE----- --5QAgd0e35j3NYeGe-- From Volker.Lendecke@SerNet.DE Mon Oct 6 20:34:54 2008 From: Volker.Lendecke@SerNet.DE (Volker Lendecke) Date: Mon, 6 Oct 2008 21:34:54 +0200 Subject: [OpenAFS] Re: Linking GPL3 code with IPL? (Was: afs_syscall (Samba as a client of OpenAFS)) In-Reply-To: <48EA6610.2090006@kzsdabas.hu> References: <48DFDFCE.2090809@kzsdabas.hu> <48E92662.7060608@kzsdabas.hu> <48EA6610.2090006@kzsdabas.hu> Message-ID: --FCuugMFkClbJLl1L Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 06, 2008 at 09:25:04PM +0200, G=E9mes G=E9za wrote: > Unfortunately this time it seems to be a lot harder, the main change > being at least to my understanding, the fact that the openafs kernel > module doesn't advertise its services as a system call, and thus we > cannot link with just libc code which calls into the kernel, but need to > explicitly use openafs calls for the same propose resulting in a need to > link to their code. > Hope is not lost totally yet as I've read about some work of developing > a GPL licensed kernel module, and then we could use some glue code from > there. While not having looked at AFS code, it must at the end come down to some syscall. Either an ioctl, a write call to some code in /proc/whatever, or something else. 99% the coding work is just setting up the right structures and make that call. Volker --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFI6mheUzqjrWwMRl0RAg2oAJwKxJJ5h9f6DSbB4UuhJfxZBJYOJACeMI1s fVgqle5ocR9Z3kuNe72Cwgk= =SsGl -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- From Volker.Lendecke@SerNet.DE Mon Oct 6 20:45:55 2008 From: Volker.Lendecke@SerNet.DE (Volker Lendecke) Date: Mon, 6 Oct 2008 21:45:55 +0200 Subject: [OpenAFS] Re: Linking GPL3 code with IPL? (Was: afs_syscall (Samba as a client of OpenAFS)) In-Reply-To: <48EA6911.3090505@kzsdabas.hu> References: <48DFDFCE.2090809@kzsdabas.hu> <48E92662.7060608@kzsdabas.hu> <48EA6610.2090006@kzsdabas.hu> <48EA6911.3090505@kzsdabas.hu> Message-ID: --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 06, 2008 at 09:37:53PM +0200, G=E9mes G=E9za wrote: > > While not having looked at AFS code, it must at the end come > > down to some syscall. Either an ioctl, a write call to some > > code in /proc/whatever, or something else. 99% the coding > > work is just setting up the right structures and make that > > call. > > > > Volker > > =20 > Yes it does an ioctl to /proc/fs/openafs/......, but if I look at the > code my implementation can be GPL released? Well, I'm not a license lawyer, but I think that if you look at the code, maybe take notes, wait a couple of days and then start coding the Samba part you should be fine. Any people with more authoritative comments around? Volker --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFI6mrzUzqjrWwMRl0RAje0AJ0QvbuEcWac25SqcSy6Bvuyq3NwMwCeJycO Pc5O9r97L5oBOgq1jH7NV5I= =eQgP -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o-- From lha@kth.se Tue Oct 7 05:16:04 2008 From: lha@kth.se (=?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Mon, 6 Oct 2008 21:16:04 -0700 Subject: [OpenAFS] Re: Linking GPL3 code with IPL? (Was: afs_syscall (Samba as a client of OpenAFS)) In-Reply-To: References: <48DFDFCE.2090809@kzsdabas.hu> <48E92662.7060608@kzsdabas.hu> <48EA6610.2090006@kzsdabas.hu> Message-ID: <1D74364B-6AFB-4659-A3A4-46B75BCFBC7B@kth.se> 6 okt 2008 kl. 12:34 skrev Volker Lendecke: > On Mon, Oct 06, 2008 at 09:25:04PM +0200, G=E9mes G=E9za wrote: >> Unfortunately this time it seems to be a lot harder, the main change >> being at least to my understanding, the fact that the openafs kernel >> module doesn't advertise its services as a system call, and thus we >> cannot link with just libc code which calls into the kernel, but =20 >> need to >> explicitly use openafs calls for the same propose resulting in a =20 >> need to >> link to their code. >> Hope is not lost totally yet as I've read about some work of =20 >> developing >> a GPL licensed kernel module, and then we could use some glue code =20= >> from >> there. > > While not having looked at AFS code, it must at the end come > down to some syscall. Either an ioctl, a write call to some > code in /proc/whatever, or something else. 99% the coding > work is just setting up the right structures and make that > call. Heimdal includes a wrapper library (libkafs) that provides uniform =20 interface to afs syscalls. Love From hctseng@tiara.sinica.edu.tw Tue Oct 7 10:45:02 2008 From: hctseng@tiara.sinica.edu.tw (Sam Tseng) Date: Tue, 7 Oct 2008 17:45:02 +0800 Subject: [OpenAFS] questions about volume size? In-Reply-To: <20081007.113031.237383818.haba@habanero.pdc.kth.se> References: <20081007.105840.169660212.haba@habanero.pdc.kth.se> <20081007.113031.237383818.haba@habanero.pdc.kth.se> Message-ID: sorry to bother you guys. i think i found the answer. :$ i tried to move this home.rwaur volume before. so, it did clone before move it. when i list volume in partition c only has one volume home.rwaur. but, i list /vicepc/. it shows three volumes. so i zap them. however, i don't know is this correct way to do this or not? but, it works. [root@fs +]# vos listvol fs Total number of volumes on server fs partition /vicepc: 1 home.rwaur 536871041 RW 1036276240 K On-line Total volumes onLine 1 ; Total volumes offLine 0 ; Total busy 0 [root@fs vicepc]# ls AFSIDat Lock lost+found V0536871041.vol V0536871168.vol V0536871171.vol [root@fs vicepc]# vos zap -server fs -id 0536871168 vos: Missing required parameter '-partition' [root@fs vicepc]# vos zap -server fs -partition c -id 536871168 Volume 536871168 deleted [root@fs vicepc]#vos zap -server fs -partition c -id 536871171 Volume 536871171 deleted thank you all!! best, s On Tue, Oct 7, 2008 at 5:30 PM, Harald Barth wrote: >> thanks for reply. however, i did not do vos backup. :) > > To Sam: > > Never created a backup volume? > > To the community: > > How does this work "under the hood"? I thought, when I make a backup > volume, files are "cloned" with link(2)? Is this the same for Namei > and Inode? > > Does not look like it is done like that (all volumes on server pompano > have backup volumes of the same size as the original ones) > > pompano# cd /vicepa/AFSIDat/p0/pGj+U/+/+/ > pompano# ls -l > total 5624 > ---------- 1 root root 0 Sep 19 17:27 0++++6 > ---------- 1 5937 adm 5754336 Sep 19 17:27 2++++A > ---------- 1 adm root 2048 Sep 19 17:27 =++++2 > > pompano# stat 0++++6 > File: `0++++6' > Size: 0 Blocks: 0 IO Block: 4096 regular empty file > Device: fd04h/64772d Inode: 2417392386 Links: 1 > Access: (0000/----------) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2008-09-19 17:27:11.705744327 +0200 > Modify: 2008-09-19 17:27:11.705744327 +0200 > Change: 2008-09-19 17:27:11.705744327 +0200 > > So how is it done? > > Harald. > -- Sam Tseng Academia Sinica Institute of Astronomy and Astrophysics Tel: +886-2-3365-2200 ext 742 Fax: +886-2-2367-7849 From rkemp@srhs.net Mon Oct 13 14:52:56 2008 From: rkemp@srhs.net (Randy Kemp) Date: Mon, 13 Oct 2008 09:52:56 -0400 Subject: [OpenAFS] File Server appears to stop responding In-Reply-To: <48E071A6.3030708@srhs.net> References: <48DD3552.5070000@srhs.net> <20080927.131045.60540471.haba@habanero.pdc.kth.se> <48E071A6.3030708@srhs.net> Message-ID: <48F352B8.9040104@srhs.net> This is a multi-part message in MIME format. --------------060203090901040706050704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I had users again today to test with. The problem with fileserver ceasing to respond and generating the "CallPreamble: Couldn't get CPS. Too many lockers" error occurred again. I'm now running fileserver with the following parameters, "-p 128 -b 512 -l 3072 -s 3072 -vc 3072 -cb 65536 -busyat 1536 -rxpck 1024 -nojumbo". At the time that the problem started there were two physical clients connected, one was a standalone workstation and the other was the aforementioned application server with approximately 40 users logged in. All requests from said application server are now coming from a single address to a single interface on the AFS server. It turns out that restarting AFS vs. rebooting the server does not make the problem go away as I previously thought. It was purely coincidental that I had also restarted the application server last time. What I have now discovered is that even rebooting the AFS server does not resolve the problem (errors start immediately upon startup) and it now appears that the problem is only resolved by restarting the client on the application server. The application server is running OpenAFS client version 1.4.7 on Ubuntu Linux with kernel version 2.6.24. I've attached the FileLog and I trimmed out the repeating errors. Any ideas? Randy Kemp wrote: > Harald Barth wrote: >>> I've been experiencing a problem where fileserver appears to simply >>> stop responding to requests. I currently only have one AFS server >>> (OpenAFS version 1.4.7). >>> >> OS? >> > Linux Kernel version 2.6.25. I was running 2.6.24 when this problem > started. >> What parameters do you start the fileserver with? > No parameters currently. Perhaps that's part of my problem. I've > done some research on the fileserver parameters and will see if > tweaking those improves things. >>> I have to completely reboot the server to resolve it. >> >> Hm. What is not freed correctly? >> > Exactly, that's the strange part. >> >>> This log was generated after I restarted fileserver and it still >>> wasn't working. >>> >> >> The "CallPreamble: Couldn't get CPS. Too many lockers" indicates that >> the fileserver can not send any rx calls any more. The question now is >> how it got into that state and why restarting (other than reboot) does >> not clear it. >> > Thanks for explaining that. Now I just need to figure out why. I > unfortunately won't have a large number of users to test with for a > couple of weeks. > -- Randy Kemp --------------060203090901040706050704 Content-Type: text/plain; name="FileLog-20081013" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="FileLog-20081013" Sun Oct 12 04:00:30 2008 File server starting Sun Oct 12 04:00:30 2008 afs_krb_get_lrealm failed, using phoenix.srhs.net. Sun Oct 12 04:00:30 2008 VL_RegisterAddrs rpc failed; will retry periodically (code=5376, err=0) Sun Oct 12 04:00:30 2008 Set thread id 126 for FSYNC_sync Sun Oct 12 04:00:30 2008 FSYNC_sync: bind failed with (98), removed bogus /var/lib/openafs/fssync.sock Sun Oct 12 04:00:30 2008 Partition /vicepa: attaching volumes Sun Oct 12 04:00:30 2008 Partition /vicepa: attached 1863 volumes; 0 volumes not attached Sun Oct 12 04:00:30 2008 Set thread id 127 for 'FiveMinuteCheckLWP' Sun Oct 12 04:00:30 2008 Set thread id 129 for 'FsyncCheckLWP' Sun Oct 12 04:00:30 2008 Set thread id 128 for 'HostCheckLWP' Sun Oct 12 04:00:30 2008 Getting FileServer name... Sun Oct 12 04:00:30 2008 FileServer host name is 'afs' Sun Oct 12 04:00:30 2008 Getting FileServer address... Sun Oct 12 04:00:30 2008 FileServer afs has address 10.141.4.2 (0x2048d0a or 0xa8d0402 in host byte order) Sun Oct 12 04:00:30 2008 File Server started Sun Oct 12 04:00:30 2008 Mon Oct 13 07:48:59 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:49:17 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:49:35 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:49:35 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:49:54 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:49:54 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:49:54 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:49:54 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:50:48 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:50:48 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:50:48 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:50:48 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:50:49 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:50:49 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:50:49 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:50:49 2008 CallPreamble: Couldn't get CPS. Too many lockers [trimmed repeating error] Mon Oct 13 07:55:08 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:55:08 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:55:08 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:55:08 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:55:08 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:55:08 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:55:08 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:55:08 2008 CallPreamble: Couldn't get CPS. Too many lockers Mon Oct 13 07:55:08 2008 Shutting down file server at Mon Oct 13 07:55:08 2008 Mon Oct 13 07:55:08 2008 Vice was last started at Sun Oct 12 04:00:30 2008 Mon Oct 13 07:55:08 2008 Large vnode cache, 3072 entries, 22 allocs, 49437 gets (4292 reads), 5933 writes Mon Oct 13 07:55:08 2008 Small vnode cache,3072 entries, 2328 allocs, 77690 gets (4823 reads), 19130 writes Mon Oct 13 07:55:08 2008 Volume header cache, 3072 entries, 49547 gets, 0 replacements Mon Oct 13 07:55:08 2008 Partition /vicepa: 1941465536 available 1K blocks (minfree=0), Mon Oct 13 07:55:08 2008 1933775811 free blocks Mon Oct 13 07:55:08 2008 With 512 directory buffers; 51616 reads resulted in 719 read I/Os Mon Oct 13 07:55:08 2008 Total Client entries = 610, blocks = 9; Host entries = 6, blocks = 1 Mon Oct 13 07:55:08 2008 There are 610 connections, process size 28412 Mon Oct 13 07:55:08 2008 There are 6 workstations, 2 are active (req in < 15 mins), 0 marked "down" Mon Oct 13 07:55:08 2008 VShutdown: shutting down on-line volumes... Mon Oct 13 07:55:16 2008 VShutdown: complete. Mon Oct 13 07:55:16 2008 File server has terminated normally at Mon Oct 13 07:55:16 2008 allenge 205 response 216 debug 0 params 0 unused 0 unused 0 unused 0 version 0 other send counters: ack 1122699, data 100014 (not resends), resends 174, pushed 0, acked&ignored 8182 (these should be small) sendFailed 0, fatalErrors 0 Average rtt is 0.005, with 935 samples Minimum rtt is 0.000, maximum is 0.042 222 server connections, 130 client connections, 10 peer structs, 260 call structs, 1 free call structs 14928 add CB, 16144 break CB, 0 del CB, 3042 del FE, 369 CB's timed out, 0 space reclaim, 4 del host 8719 CBs, 8719 FEs, (17438 of total of 65536 16-byte blocks) --------------060203090901040706050704-- From shadow@gmail.com Mon Oct 13 14:58:34 2008 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 13 Oct 2008 09:58:34 -0400 Subject: [OpenAFS] File Server appears to stop responding In-Reply-To: <48F352B8.9040104@srhs.net> References: <48DD3552.5070000@srhs.net> <20080927.131045.60540471.haba@habanero.pdc.kth.se> <48E071A6.3030708@srhs.net> <48F352B8.9040104@srhs.net> Message-ID: On Mon, Oct 13, 2008 at 9:52 AM, Randy Kemp wrote: > I had users again today to test with. The problem with fileserver > ceasing to respond and generating the "CallPreamble: Couldn't get CPS. > Too many lockers" error occurred again. To the app server, or to both machines? I assume, actually, only to the app server. > I'm now running fileserver with the following parameters, "-p 128 -b 512 > -l 3072 -s 3072 -vc 3072 -cb 65536 -busyat 1536 -rxpck 1024 -nojumbo". > At the time that the problem started there were two physical clients > connected, one was a standalone workstation and the other was the > aforementioned application server with approximately 40 users logged > in. All requests from said application server are now coming from a > single address to a single interface on the AFS server. > It turns out that restarting AFS vs. rebooting the server does not make > the problem go away as I previously thought. It was purely coincidental > that I had also restarted the application server last time. What I have > now discovered is that even rebooting the AFS server does not resolve > the problem (errors start immediately upon startup) and it now appears > that the problem is only resolved by restarting the client on the > application server. The application server is running OpenAFS client > version 1.4.7 on Ubuntu Linux with kernel version 2.6.24. echo t > /proc/sysrq-trigger on the application server, as root, when the fileserver won't talk to it, collect the system log from e.g. /var/log/messages with the backtrace in it, and let us see that. From rkemp@srhs.net Mon Oct 13 15:14:00 2008 From: rkemp@srhs.net (Randy Kemp) Date: Mon, 13 Oct 2008 10:14:00 -0400 Subject: [OpenAFS] File Server appears to stop responding In-Reply-To: References: <48DD3552.5070000@srhs.net> <20080927.131045.60540471.haba@habanero.pdc.kth.se> <48E071A6.3030708@srhs.net> <48F352B8.9040104@srhs.net> Message-ID: <48F357A8.8050709@srhs.net> Derrick Brashear wrote: > On Mon, Oct 13, 2008 at 9:52 AM, Randy Kemp wrote: > >> I had users again today to test with. The problem with fileserver >> ceasing to respond and generating the "CallPreamble: Couldn't get CPS. >> Too many lockers" error occurred again. >> > To the app server, or to both machines? I assume, actually, only to > the app server. > The last time it occurred (when I sent the first message) it stopped responding to all connected clients. I did not think to test that this. >> I'm now running fileserver with the following parameters, "-p 128 -b 512 >> -l 3072 -s 3072 -vc 3072 -cb 65536 -busyat 1536 -rxpck 1024 -nojumbo". >> At the time that the problem started there were two physical clients >> connected, one was a standalone workstation and the other was the >> aforementioned application server with approximately 40 users logged >> in. All requests from said application server are now coming from a >> single address to a single interface on the AFS server. >> >> It turns out that restarting AFS vs. rebooting the server does not make >> the problem go away as I previously thought. It was purely coincidental >> that I had also restarted the application server last time. What I have >> now discovered is that even rebooting the AFS server does not resolve >> the problem (errors start immediately upon startup) and it now appears >> that the problem is only resolved by restarting the client on the >> application server. The application server is running OpenAFS client >> version 1.4.7 on Ubuntu Linux with kernel version 2.6.24. >> > > echo t > /proc/sysrq-trigger on the application server, as root, when > the fileserver won't talk to it, collect the system log from e.g. > /var/log/messages with the backtrace in it, and let us see that. > I have about 90 users that will try to log in to the app server later today so I'm sure it will do it again. I'll do this and test it from other clients if/when it happens. -- Randy Kemp From singh.madhusudan@gmail.com Mon Oct 13 21:07:58 2008 From: singh.madhusudan@gmail.com (Madhusudan Singh) Date: Mon, 13 Oct 2008 13:07:58 -0700 Subject: [OpenAFS] Openafs broken on Ubuntu Hardy ? Message-ID: ------=_Part_170398_21275724.1223928478319 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, I am running the latest versions of openafs-modules-source, openafs-client and openafs-krb5 on an up to date installation of Ubuntu Hardy. I used modules-assistant to compile the kernel module against my kernel : $ uname -r 2.6.24-21-generic $ sudo apt-cache policy openafs-client openafs-client: Installed: 1.4.6.dfsg1-2 Candidate: 1.4.6.dfsg1-2 Version table: *** 1.4.6.dfsg1-2 0 500 http://us.archive.ubuntu.com hardy/universe Packages 100 /var/lib/dpkg/status $ sudo apt-cache policy openafs-modules-source openafs-modules-source: Installed: 1.4.6.dfsg1-2 Candidate: 1.4.6.dfsg1-2 Version table: *** 1.4.6.dfsg1-2 0 500 http://us.archive.ubuntu.com hardy/universe Packages 100 /var/lib/dpkg/status $ sudo apt-cache policy openafs-krb5 openafs-krb5: Installed: 1.4.6.dfsg1-2 Candidate: 1.4.6.dfsg1-2 Version table: *** 1.4.6.dfsg1-2 0 500 http://us.archive.ubuntu.com hardy/universe Packages 100 /var/lib/dpkg/status I can get my tokens alright. $ klist Ticket cache: FILE:/tmp/krb5cc_457671 Default principal: XYZABC@YYY.EDU Valid starting Expires Service principal 10/13/08 12:53:57 10/14/08 12:53:58 krbtgt/YYY.EDU@YYY.EDU 10/13/08 12:54:03 10/14/08 12:53:58 afs@YYY.EDU Kerberos 4 ticket cache: /tmp/tkt457671 klist: You have no tickets cached $ tokens Tokens held by the Cache Manager: User's (AFS ID 123456) tokens for afs@YYY.edu [Expires Oct 14 12:53] --End of list-- The user ids of the local user (username A) and the remote user (username XYZABC, A<>XYZABC), are identical. When I try to the user's afs share after getting tokens : :$ cd /afs/YYY.edu/users/X/Y/Z/XYZABC bash: cd: /afs/YYY.edu/users/X/Y/Z/XYZABC: Permission denied I have previously successfully authenticated to this cell with an older version of openafs (it was a year ago, do not remember which). Meanwhile, restarting openafs-client reveals some junk in dmesg. Is this a bug, and if so, what are my options ? Thanks. ----------------------------- dmesg : [10676.480995] COLD shutting down of: CB... afs... BkG... CTrunc... AFSDB... RxEvent... UnmaskRxkSignals... RxListener... [10677.108727] WARNING: at /build/buildd/linux-2.6.24/mm/slub.c:2323 kmem_cache_destroy() [10677.108736] Pid: 6035, comm: rmmod Tainted: P 2.6.24-21-generic #1 [10677.108760] [] kmem_cache_destroy+0x156/0x160 [10677.108780] [] cleanup_module+0x1e/0x53 [openafs] [10677.108825] [] sys_delete_module+0x112/0x190 [10677.108843] [] do_page_fault+0x13f/0x730 [10677.108854] [] do_munmap+0x180/0x1f0 [10677.108872] [] sysenter_past_esp+0x6b/0xa9 [10677.108886] [] unix_stream_sendmsg+0xc0/0x390 [10677.108899] ======================= [10680.950197] Found system call table at 0xc0325500 (pattern scan) [10680.950418] sysctl_check_dir: failed: /afs .1 ref: /kernel .1 [10680.950432] sysctl table check failed: /afs .1 Inconsistent directory names [10680.950440] Pid: 6103, comm: modprobe Tainted: P 2.6.24-21-generic #1 [10680.950473] [] set_fail+0x45/0x60 [10680.950486] [] sysctl_check_table+0x354/0x5b0 [10680.950496] [] register_sysctl_table+0x50/0xa0 [10680.950505] [] osi_sysctl_init+0xa/0x20 [openafs] [10680.950535] [] init_module+0x40/0xa6 [openafs] [10680.950565] [] sys_init_module+0x126/0x19c0 [10680.950593] [] request_key+0x0/0x60 [10680.950605] [] sysenter_past_esp+0x6b/0xa9 [10680.950618] ======================= [10680.950620] sysctl table check failed: /afs .1 procname does not match binary path procname [10680.950625] Pid: 6103, comm: modprobe Tainted: P 2.6.24-21-generic #1 [10680.950629] [] set_fail+0x45/0x60 [10680.950636] [] sysctl_check_table+0x296/0x5b0 [10680.950645] [] register_sysctl_table+0x50/0xa0 [10680.950652] [] osi_sysctl_init+0xa/0x20 [openafs] [10680.950678] [] init_module+0x40/0xa6 [openafs] [10680.950706] [] sys_init_module+0x126/0x19c0 [10680.950732] [] request_key+0x0/0x60 [10680.950743] [] sysenter_past_esp+0x6b/0xa9 [10680.950755] ======================= [10680.950761] sysctl table check failed: /afs/hm_retry_RO .1.1 Sysctl already exists [10680.950766] Pid: 6103, comm: modprobe Tainted: P 2.6.24-21-generic #1 [10680.950773] [] set_fail+0x45/0x60 [10680.950780] [] sysctl_check_table+0x354/0x5b0 [10680.950790] [] sysctl_check_table+0x2aa/0x5b0 [10680.950799] [] register_sysctl_table+0x50/0xa0 [10680.950806] [] osi_sysctl_init+0xa/0x20 [openafs] [10680.950832] [] init_module+0x40/0xa6 [openafs] [10680.950859] [] sys_init_module+0x126/0x19c0 [10680.950886] [] request_key+0x0/0x60 [10680.950896] [] sysenter_past_esp+0x6b/0xa9 [10680.950908] ======================= [10680.950910] sysctl table check failed: /afs/hm_retry_RO .1.1 procname does not match binary path procname [10680.950915] Pid: 6103, comm: modprobe Tainted: P 2.6.24-21-generic #1 [10680.950919] [] set_fail+0x45/0x60 [10680.950926] [] sysctl_check_table+0x296/0x5b0 [10680.950936] [] sysctl_check_table+0x2aa/0x5b0 [10680.950945] [] register_sysctl_table+0x50/0xa0 [10680.950951] [] osi_sysctl_init+0xa/0x20 [openafs] [10680.950977] [] init_module+0x40/0xa6 [openafs] [10680.951004] [] sys_init_module+0x126/0x19c0 [10680.951030] [] request_key+0x0/0x60 [10680.951041] [] sysenter_past_esp+0x6b/0xa9 [10680.951053] ======================= [10680.951057] sysctl table check failed: /afs/hm_retry_RW .1.2 Sysctl already exists [10680.951062] Pid: 6103, comm: modprobe Tainted: P 2.6.24-21-generic #1 [10680.951069] [] set_fail+0x45/0x60 [10680.951076] [] sysctl_check_table+0x354/0x5b0 [10680.951085] [] sysctl_check_table+0x2aa/0x5b0 [10680.951094] [] register_sysctl_table+0x50/0xa0 [10680.951101] [] osi_sysctl_init+0xa/0x20 [openafs] [10680.951127] [] init_module+0x40/0xa6 [openafs] [10680.951154] [] sys_init_module+0x126/0x19c0 [10680.951180] [] request_key+0x0/0x60 [10680.951191] [] sysenter_past_esp+0x6b/0xa9 [10680.951202] ======================= [10680.951204] sysctl table check failed: /afs/hm_retry_RW .1.2 procname does not match binary path procname [10680.951209] Pid: 6103, comm: modprobe Tainted: P 2.6.24-21-generic #1 [10680.951213] [] set_fail+0x45/0x60 [10680.951220] [] sysctl_check_table+0x296/0x5b0 [10680.951228] [] sysctl_check_table+0x2aa/0x5b0 [10680.951237] [] register_sysctl_table+0x50/0xa0 [10680.951243] [] osi_sysctl_init+0xa/0x20 [openafs] [10680.951269] [] init_module+0x40/0xa6 [openafs] [10680.951295] [] sys_init_module+0x126/0x19c0 [10680.951320] [] request_key+0x0/0x60 [10680.951331] [] sysenter_past_esp+0x6b/0xa9 [10680.951342] ======================= [10680.951358] sysctl table check failed: /afs/hm_retry_int .1.3 Unknown sysctl binary path [10680.951364] Pid: 6103, comm: modprobe Tainted: P 2.6.24-21-generic #1 [10680.951372] [] set_fail+0x45/0x60 [10680.951379] [] sysctl_check_table+0x296/0x5b0 [10680.951388] [] sysctl_check_table+0x2aa/0x5b0 [10680.951397] [] register_sysctl_table+0x50/0xa0 [10680.951403] [] osi_sysctl_init+0xa/0x20 [openafs] [10680.951429] [] init_module+0x40/0xa6 [openafs] [10680.951455] [] sys_init_module+0x126/0x19c0 [10680.951480] [] request_key+0x0/0x60 [10680.951491] [] sysenter_past_esp+0x6b/0xa9 [10680.951508] ======================= [10680.951512] sysctl table check failed: /afs/GCPAGs .1.4 Sysctl already exists [10680.951517] Pid: 6103, comm: modprobe Tainted: P 2.6.24-21-generic #1 [10680.951522] [] set_fail+0x45/0x60 [10680.951530] [] sysctl_check_table+0x354/0x5b0 [10680.951539] [] sysctl_check_table+0x2aa/0x5b0 [10680.951548] [] register_sysctl_table+0x50/0xa0 [10680.951554] [] osi_sysctl_init+0xa/0x20 [openafs] [10680.951580] [] init_module+0x40/0xa6 [openafs] [10680.951605] [] sys_init_module+0x126/0x19c0 [10680.951630] [] request_key+0x0/0x60 [10680.951640] [] sysenter_past_esp+0x6b/0xa9 [10680.951652] ======================= [10680.951653] sysctl table check failed: /afs/GCPAGs .1.4 procname does not match binary path procname [10680.951659] Pid: 6103, comm: modprobe Tainted: P 2.6.24-21-generic #1 [10680.951662] [] set_fail+0x45/0x60 [10680.951669] [] sysctl_check_table+0x296/0x5b0 [10680.951678] [] sysctl_check_table+0x2aa/0x5b0 [10680.951686] [] register_sysctl_table+0x50/0xa0 [10680.951692] [] osi_sysctl_init+0xa/0x20 [openafs] [10680.951718] [] init_module+0x40/0xa6 [openafs] [10680.951744] [] sys_init_module+0x126/0x19c0 [10680.951769] [] request_key+0x0/0x60 [10680.951780] [] sysenter_past_esp+0x6b/0xa9 [10680.951791] ======================= [10680.951799] sysctl table check failed: /afs/rx_deadtime .1.5 Unknown sysctl binary path [10680.951804] Pid: 6103, comm: modprobe Tainted: P 2.6.24-21-generic #1 [10680.951812] [] set_fail+0x45/0x60 [10680.951819] [] sysctl_check_table+0x296/0x5b0 [10680.951828] [] sysctl_check_table+0x2aa/0x5b0 [10680.951836] [] register_sysctl_table+0x50/0xa0 [10680.951841] [] osi_sysctl_init+0xa/0x20 [openafs] [10680.951867] [] init_module+0x40/0xa6 [openafs] [10680.951893] [] sys_init_module+0x126/0x19c0 [10680.951919] [] request_key+0x0/0x60 [10680.951929] [] sysenter_past_esp+0x6b/0xa9 [10680.951940] ======================= [10680.951948] sysctl table check failed: /afs/bkVolPref .1.6 Unknown sysctl binary path [10680.951954] Pid: 6103, comm: modprobe Tainted: P 2.6.24-21-generic #1 [10680.951961] [] set_fail+0x45/0x60 [10680.951968] [] sysctl_check_table+0x296/0x5b0 [10680.951977] [] sysctl_check_table+0x2aa/0x5b0 [10680.951985] [] register_sysctl_table+0x50/0xa0 [10680.951990] [] osi_sysctl_init+0xa/0x20 [openafs] [10680.952016] [] init_module+0x40/0xa6 [openafs] [10680.952043] [] sys_init_module+0x126/0x19c0 [10680.952068] [] request_key+0x0/0x60 [10680.952079] [] sysenter_past_esp+0x6b/0xa9 [10680.952090] ======================= [10681.027707] Starting AFS cache scan...found 154 non-empty cache files (9%). ------=_Part_170398_21275724.1223928478319 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello,

I am running the latest versions of openafs-modules-source, openafs-client and openafs-krb5 on an up to date installation of Ubuntu Hardy. I used modules-assistant to compile the kernel module against my kernel :
$ uname -r
2.6.24-21-generic

$ sudo apt-cache policy openafs-client
openafs-client:
  Installed: 1.4.6.dfsg1-2
  Candidate: 1.4.6.dfsg1-2
  Version table:
 *** 1.4.6.dfsg1-2 0
        500 http://us.archive.ubuntu.com hardy/universe Packages
        100 /var/lib/dpkg/status
$ sudo apt-cache policy openafs-modules-source
openafs-modules-source:
  Installed: 1.4.6.dfsg1-2
  Candidate: 1.4.6.dfsg1-2
  Version table:
 *** 1.4.6.dfsg1-2 0
        500 http://us.archive.ubuntu.com hardy/universe Packages
        100 /var/lib/dpkg/status

$ sudo apt-cache policy openafs-krb5
openafs-krb5:
  Installed: 1.4.6.dfsg1-2
  Candidate: 1.4.6.dfsg1-2
  Version table:
 *** 1.4.6.dfsg1-2 0
        500 http://us.archive.ubuntu.com hardy/universe Packages
        100 /var/lib/dpkg/status

I can get my tokens alright.

$ klist
Ticket cache: FILE:/tmp/krb5cc_457671
Default principal: XYZABC@YYY.EDU

Valid starting     Expires            Service principal
10/13/08 12:53:57  10/14/08 12:53:58  krbtgt/YYY.EDU@YYY.EDU
10/13/08 12:54:03  10/14/08 12:53:58  afs@YYY.EDU


Kerberos 4 ticket cache: /tmp/tkt457671
klist: You have no tickets cached

$ tokens

Tokens held by the Cache Manager:

User's (AFS ID 123456) tokens for afs@YYY.edu [Expires Oct 14 12:53]
   --End of list--

The user ids of the local user (username A) and the remote user (username XYZABC, A<>XYZABC), are identical.

When I try to the user's afs share after getting tokens :

:$ cd /afs/YYY.edu/users/X/Y/Z/XYZABC
bash: cd: /afs/YYY.edu/users/X/Y/Z/XYZABC: Permission denied

I have previously successfully authenticated to this cell with an older version of openafs (it was a year ago, do not remember which).

Meanwhile, restarting openafs-client reveals some junk in dmesg. Is this a bug, and if so, what are my options ?

Thanks.

-----------------------------

dmesg :

[10676.480995] COLD shutting down of: CB... afs... BkG... CTrunc... AFSDB... RxEvent... UnmaskRxkSignals... RxListener...
[10677.108727] WARNING: at /build/buildd/linux-2.6.24/mm/slub.c:2323 kmem_cache_destroy()
[10677.108736] Pid: 6035, comm: rmmod Tainted: P        2.6.24-21-generic #1
[10677.108760]  [<c018dd76>] kmem_cache_destroy+0x156/0x160
[10677.108780]  [<f9896ede>] cleanup_module+0x1e/0x53 [openafs]
[10677.108825]  [<c0152082>] sys_delete_module+0x112/0x190
[10677.108843]  [<c031e19f>] do_page_fault+0x13f/0x730
[10677.108854]  [<c01803e0>] do_munmap+0x180/0x1f0
[10677.108872]  [<c01043b2>] sysenter_past_esp+0x6b/0xa9
[10677.108886]  [<c0310000>] unix_stream_sendmsg+0xc0/0x390
[10677.108899]  =======================
[10680.950197] Found system call table at 0xc0325500 (pattern scan)
[10680.950418] sysctl_check_dir: failed: /afs .1 ref: /kernel .1
[10680.950432] sysctl table check failed: /afs .1 Inconsistent directory names
[10680.950440] Pid: 6103, comm: modprobe Tainted: P        2.6.24-21-generic #1
[10680.950473]  [<c0145885>] set_fail+0x45/0x60
[10680.950486]  [<c0145bf4>] sysctl_check_table+0x354/0x5b0
[10680.950496]  [<c0134580>] register_sysctl_table+0x50/0xa0
[10680.950505]  [<f8ebcf2a>] osi_sysctl_init+0xa/0x20 [openafs]
[10680.950535]  [<f8ace040>] init_module+0x40/0xa6 [openafs]
[10680.950565]  [<c01506a6>] sys_init_module+0x126/0x19c0
[10680.950593]  [<c01e57d0>] request_key+0x0/0x60
[10680.950605]  [<c01043b2>] sysenter_past_esp+0x6b/0xa9
[10680.950618]  =======================
[10680.950620] sysctl table check failed: /afs .1 procname does not match binary path procname
[10680.950625] Pid: 6103, comm: modprobe Tainted: P        2.6.24-21-generic #1
[10680.950629]  [<c0145885>] set_fail+0x45/0x60
[10680.950636]  [<c0145b36>] sysctl_check_table+0x296/0x5b0
[10680.950645]  [<c0134580>] register_sysctl_table+0x50/0xa0
[10680.950652]  [<f8ebcf2a>] osi_sysctl_init+0xa/0x20 [openafs]
[10680.950678]  [<f8ace040>] init_module+0x40/0xa6 [openafs]
[10680.950706]  [<c01506a6>] sys_init_module+0x126/0x19c0
[10680.950732]  [<c01e57d0>] request_key+0x0/0x60
[10680.950743]  [<c01043b2>] sysenter_past_esp+0x6b/0xa9
[10680.950755]  =======================
[10680.950761] sysctl table check failed: /afs/hm_retry_RO .1.1 Sysctl already exists
[10680.950766] Pid: 6103, comm: modprobe Tainted: P        2.6.24-21-generic #1
[10680.950773]  [<c0145885>] set_fail+0x45/0x60
[10680.950780]  [<c0145bf4>] sysctl_check_table+0x354/0x5b0
[10680.950790]  [<c0145b4a>] sysctl_check_table+0x2aa/0x5b0
[10680.950799]  [<c0134580>] register_sysctl_table+0x50/0xa0
[10680.950806]  [<f8ebcf2a>] osi_sysctl_init+0xa/0x20 [openafs]
[10680.950832]  [<f8ace040>] init_module+0x40/0xa6 [openafs]
[10680.950859]  [<c01506a6>] sys_init_module+0x126/0x19c0
[10680.950886]  [<c01e57d0>] request_key+0x0/0x60
[10680.950896]  [<c01043b2>] sysenter_past_esp+0x6b/0xa9
[10680.950908]  =======================
[10680.950910] sysctl table check failed: /afs/hm_retry_RO .1.1 procname does not match binary path procname
[10680.950915] Pid: 6103, comm: modprobe Tainted: P        2.6.24-21-generic #1
[10680.950919]  [<c0145885>] set_fail+0x45/0x60
[10680.950926]  [<c0145b36>] sysctl_check_table+0x296/0x5b0
[10680.950936]  [<c0145b4a>] sysctl_check_table+0x2aa/0x5b0
[10680.950945]  [<c0134580>] register_sysctl_table+0x50/0xa0
[10680.950951]  [<f8ebcf2a>] osi_sysctl_init+0xa/0x20 [openafs]
[10680.950977]  [<f8ace040>] init_module+0x40/0xa6 [openafs]
[10680.951004]  [<c01506a6>] sys_init_module+0x126/0x19c0
[10680.951030]  [<c01e57d0>] request_key+0x0/0x60
[10680.951041]  [<c01043b2>] sysenter_past_esp+0x6b/0xa9
[10680.951053]  =======================
[10680.951057] sysctl table check failed: /afs/hm_retry_RW .1.2 Sysctl already exists
[10680.951062] Pid: 6103, comm: modprobe Tainted: P        2.6.24-21-generic #1
[10680.951069]  [<c0145885>] set_fail+0x45/0x60
[10680.951076]  [<c0145bf4>] sysctl_check_table+0x354/0x5b0
[10680.951085]  [<c0145b4a>] sysctl_check_table+0x2aa/0x5b0
[10680.951094]  [<c0134580>] register_sysctl_table+0x50/0xa0
[10680.951101]  [<f8ebcf2a>] osi_sysctl_init+0xa/0x20 [openafs]
[10680.951127]  [<f8ace040>] init_module+0x40/0xa6 [openafs]
[10680.951154]  [<c01506a6>] sys_init_module+0x126/0x19c0
[10680.951180]  [<c01e57d0>] request_key+0x0/0x60
[10680.951191]  [<c01043b2>] sysenter_past_esp+0x6b/0xa9
[10680.951202]  =======================
[10680.951204] sysctl table check failed: /afs/hm_retry_RW .1.2 procname does not match binary path procname
[10680.951209] Pid: 6103, comm: modprobe Tainted: P        2.6.24-21-generic #1
[10680.951213]  [<c0145885>] set_fail+0x45/0x60
[10680.951220]  [<c0145b36>] sysctl_check_table+0x296/0x5b0
[10680.951228]  [<c0145b4a>] sysctl_check_table+0x2aa/0x5b0
[10680.951237]  [<c0134580>] register_sysctl_table+0x50/0xa0
[10680.951243]  [<f8ebcf2a>] osi_sysctl_init+0xa/0x20 [openafs]
[10680.951269]  [<f8ace040>] init_module+0x40/0xa6 [openafs]
[10680.951295]  [<c01506a6>] sys_init_module+0x126/0x19c0
[10680.951320]  [<c01e57d0>] request_key+0x0/0x60
[10680.951331]  [<c01043b2>] sysenter_past_esp+0x6b/0xa9
[10680.951342]  =======================
[10680.951358] sysctl table check failed: /afs/hm_retry_int .1.3 Unknown sysctl binary path
[10680.951364] Pid: 6103, comm: modprobe Tainted: P        2.6.24-21-generic #1
[10680.951372]  [<c0145885>] set_fail+0x45/0x60
[10680.951379]  [<c0145b36>] sysctl_check_table+0x296/0x5b0
[10680.951388]  [<c0145b4a>] sysctl_check_table+0x2aa/0x5b0
[10680.951397]  [<c0134580>] register_sysctl_table+0x50/0xa0
[10680.951403]  [<f8ebcf2a>] osi_sysctl_init+0xa/0x20 [openafs]
[10680.951429]  [<f8ace040>] init_module+0x40/0xa6 [openafs]
[10680.951455]  [<c01506a6>] sys_init_module+0x126/0x19c0
[10680.951480]  [<c01e57d0>] request_key+0x0/0x60
[10680.951491]  [<c01043b2>] sysenter_past_esp+0x6b/0xa9
[10680.951508]  =======================
[10680.951512] sysctl table check failed: /afs/GCPAGs .1.4 Sysctl already exists
[10680.951517] Pid: 6103, comm: modprobe Tainted: P        2.6.24-21-generic #1
[10680.951522]  [<c0145885>] set_fail+0x45/0x60
[10680.951530]  [<c0145bf4>] sysctl_check_table+0x354/0x5b0
[10680.951539]  [<c0145b4a>] sysctl_check_table+0x2aa/0x5b0
[10680.951548]  [<c0134580>] register_sysctl_table+0x50/0xa0
[10680.951554]  [<f8ebcf2a>] osi_sysctl_init+0xa/0x20 [openafs]
[10680.951580]  [<f8ace040>] init_module+0x40/0xa6 [openafs]
[10680.951605]  [<c01506a6>] sys_init_module+0x126/0x19c0
[10680.951630]  [<c01e57d0>] request_key+0x0/0x60
[10680.951640]  [<c01043b2>] sysenter_past_esp+0x6b/0xa9
[10680.951652]  =======================
[10680.951653] sysctl table check failed: /afs/GCPAGs .1.4 procname does not match binary path procname
[10680.951659] Pid: 6103, comm: modprobe Tainted: P        2.6.24-21-generic #1
[10680.951662]  [<c0145885>] set_fail+0x45/0x60
[10680.951669]  [<c0145b36>] sysctl_check_table+0x296/0x5b0
[10680.951678]  [<c0145b4a>] sysctl_check_table+0x2aa/0x5b0
[10680.951686]  [<c0134580>] register_sysctl_table+0x50/0xa0
[10680.951692]  [<f8ebcf2a>] osi_sysctl_init+0xa/0x20 [openafs]
[10680.951718]  [<f8ace040>] init_module+0x40/0xa6 [openafs]
[10680.951744]  [<c01506a6>] sys_init_module+0x126/0x19c0
[10680.951769]  [<c01e57d0>] request_key+0x0/0x60
[10680.951780]  [<c01043b2>] sysenter_past_esp+0x6b/0xa9
[10680.951791]  =======================
[10680.951799] sysctl table check failed: /afs/rx_deadtime .1.5 Unknown sysctl binary path
[10680.951804] Pid: 6103, comm: modprobe Tainted: P        2.6.24-21-generic #1
[10680.951812]  [<c0145885>] set_fail+0x45/0x60
[10680.951819]  [<c0145b36>] sysctl_check_table+0x296/0x5b0
[10680.951828]  [<c0145b4a>] sysctl_check_table+0x2aa/0x5b0
[10680.951836]  [<c0134580>] register_sysctl_table+0x50/0xa0
[10680.951841]  [<f8ebcf2a>] osi_sysctl_init+0xa/0x20 [openafs]
[10680.951867]  [<f8ace040>] init_module+0x40/0xa6 [openafs]
[10680.951893]  [<c01506a6>] sys_init_module+0x126/0x19c0
[10680.951919]  [<c01e57d0>] request_key+0x0/0x60
[10680.951929]  [<c01043b2>] sysenter_past_esp+0x6b/0xa9
[10680.951940]  =======================
[10680.951948] sysctl table check failed: /afs/bkVolPref .1.6 Unknown sysctl binary path
[10680.951954] Pid: 6103, comm: modprobe Tainted: P        2.6.24-21-generic #1
[10680.951961]  [<c0145885>] set_fail+0x45/0x60
[10680.951968]  [<c0145b36>] sysctl_check_table+0x296/0x5b0
[10680.951977]  [<c0145b4a>] sysctl_check_table+0x2aa/0x5b0
[10680.951985]  [<c0134580>] register_sysctl_table+0x50/0xa0
[10680.951990]  [<f8ebcf2a>] osi_sysctl_init+0xa/0x20 [openafs]
[10680.952016]  [<f8ace040>] init_module+0x40/0xa6 [openafs]
[10680.952043]  [<c01506a6>] sys_init_module+0x126/0x19c0
[10680.952068]  [<c01e57d0>] request_key+0x0/0x60
[10680.952079]  [<c01043b2>] sysenter_past_esp+0x6b/0xa9
[10680.952090]  =======================
[10681.027707] Starting AFS cache scan...found 154 non-empty cache files (9%).

------=_Part_170398_21275724.1223928478319-- From pohl@syssoft.uni-trier.de Tue Oct 14 00:33:14 2008 From: pohl@syssoft.uni-trier.de (Stefan Pohl) Date: Tue, 14 Oct 2008 01:33:14 +0200 Subject: [OpenAFS] Openafs broken on Ubuntu Hardy ? In-Reply-To: References: Message-ID: <48F3DABA.2020905@syssoft.uni-trier.de> Hi, Madhusudan Singh schrieb: > Hello, > > I am running the latest versions of openafs-modules-source, > openafs-client and openafs-krb5 on an up to date installation of > Ubuntu Hardy. I used modules-assistant to compile the kernel module > against my kernel : > $ uname -r > 2.6.24-21-generic > > $ sudo apt-cache policy openafs-client > openafs-client: > Installed: 1.4.6.dfsg1-2 > Candidate: 1.4.6.dfsg1-2 > Version table: > *** 1.4.6.dfsg1-2 0 > 500 http://us.archive.ubuntu.com hardy/universe Packages > 100 /var/lib/dpkg/status > $ sudo apt-cache policy openafs-modules-source > openafs-modules-source: > Installed: 1.4.6.dfsg1-2 > Candidate: 1.4.6.dfsg1-2 > Version table: > *** 1.4.6.dfsg1-2 0 > 500 http://us.archive.ubuntu.com hardy/universe Packages > 100 /var/lib/dpkg/status > > $ sudo apt-cache policy openafs-krb5 > openafs-krb5: > Installed: 1.4.6.dfsg1-2 > Candidate: 1.4.6.dfsg1-2 > Version table: > *** 1.4.6.dfsg1-2 0 > 500 http://us.archive.ubuntu.com hardy/universe Packages > 100 /var/lib/dpkg/status I just completed an OpenAFS-client test setup on Ubuntu Hardy. Same versions of the Openafs-stuff, slightly older kernel (2.6.24-19-generic) and it works. So it's not broken on Ubuntu Hardy as such. > I can get my tokens alright. > > $ klist > Ticket cache: FILE:/tmp/krb5cc_457671 > Default principal: XYZABC@YYY.EDU > > Valid starting Expires Service principal > 10/13/08 12:53:57 10/14/08 12:53:58 krbtgt/YYY.EDU > @YYY.EDU > 10/13/08 12:54:03 10/14/08 12:53:58 afs@YYY.EDU > > > Kerberos 4 ticket cache: /tmp/tkt457671 > klist: You have no tickets cached > > $ tokens > > Tokens held by the Cache Manager: > > User's (AFS ID 123456) tokens for afs@YYY.edu [Expires Oct 14 12:53] > --End of list-- > > The user ids of the local user (username A) and the remote user > (username XYZABC, A<>XYZABC), are identical. > > When I try to the user's afs share after getting tokens : > > :$ cd /afs/YYY.edu/users/X/Y/Z/XYZABC > bash: cd: /afs/YYY.edu/users/X/Y/Z/XYZABC: Permission denied This look like the user you authenticate as, simply doesn't have the required permissions to access the directory. > > I have previously successfully authenticated to this cell with an > older version of openafs (it was a year ago, do not remember which). If you could access the directory a year ago, maybe the acls of the directory got changed in the meantime. Is your user the owner of the directory? Can you access the directories above that directory? > > Meanwhile, restarting openafs-client reveals some junk in dmesg. Is > this a bug, and if so, what are my options ? I see pretty much the same stuff in my dmesg, although I didn't compare line for line :-). With my setup it works despite of these messages. HTH Stefan Pohl > > Thanks. > > ----------------------------- > > dmesg : > > [10676.480995] COLD shutting down of: CB... afs... BkG... CTrunc... > AFSDB... RxEvent... UnmaskRxkSignals... RxListener... > [10677.108727] WARNING: at /build/buildd/linux-2.6.24/mm/slub.c:2323 > kmem_cache_destroy() > [10677.108736] Pid: 6035, comm: rmmod Tainted: P > 2.6.24-21-generic #1 > [10677.108760] [] kmem_cache_destroy+0x156/0x160 > [10677.108780] [] cleanup_module+0x1e/0x53 [openafs] > [10677.108825] [] sys_delete_module+0x112/0x190 > [10677.108843] [] do_page_fault+0x13f/0x730 > [10677.108854] [] do_munmap+0x180/0x1f0 > [10677.108872] [] sysenter_past_esp+0x6b/0xa9 > [10677.108886] [] unix_stream_sendmsg+0xc0/0x390 > [10677.108899] ======================= > [10680.950197] Found system call table at 0xc0325500 (pattern scan) > [10680.950418] sysctl_check_dir: failed: /afs .1 ref: /kernel .1 > [10680.950432] sysctl table check failed: /afs .1 Inconsistent > directory names > [10680.950440] Pid: 6103, comm: modprobe Tainted: P > 2.6.24-21-generic #1 > [10680.950473] [] set_fail+0x45/0x60 > [10680.950486] [] sysctl_check_table+0x354/0x5b0 > [10680.950496] [] register_sysctl_table+0x50/0xa0 > [10680.950505] [] osi_sysctl_init+0xa/0x20 [openafs] > [10680.950535] [] init_module+0x40/0xa6 [openafs] > [10680.950565] [] sys_init_module+0x126/0x19c0 > [10680.950593] [] request_key+0x0/0x60 > [10680.950605] [] sysenter_past_esp+0x6b/0xa9 > [10680.950618] ======================= > [10680.950620] sysctl table check failed: /afs .1 procname does not > match binary path procname > [10680.950625] Pid: 6103, comm: modprobe Tainted: P > 2.6.24-21-generic #1 > [10680.950629] [] set_fail+0x45/0x60 > [10680.950636] [] sysctl_check_table+0x296/0x5b0 > [10680.950645] [] register_sysctl_table+0x50/0xa0 > [10680.950652] [] osi_sysctl_init+0xa/0x20 [openafs] > [10680.950678] [] init_module+0x40/0xa6 [openafs] > [10680.950706] [] sys_init_module+0x126/0x19c0 > [10680.950732] [] request_key+0x0/0x60 > [10680.950743] [] sysenter_past_esp+0x6b/0xa9 > [10680.950755] ======================= > [10680.950761] sysctl table check failed: /afs/hm_retry_RO .1.1 Sysctl > already exists > [10680.950766] Pid: 6103, comm: modprobe Tainted: P > 2.6.24-21-generic #1 > [10680.950773] [] set_fail+0x45/0x60 > [10680.950780] [] sysctl_check_table+0x354/0x5b0 > [10680.950790] [] sysctl_check_table+0x2aa/0x5b0 > [10680.950799] [] register_sysctl_table+0x50/0xa0 > [10680.950806] [] osi_sysctl_init+0xa/0x20 [openafs] > [10680.950832] [] init_module+0x40/0xa6 [openafs] > [10680.950859] [] sys_init_module+0x126/0x19c0 > [10680.950886] [] request_key+0x0/0x60 > [10680.950896] [] sysenter_past_esp+0x6b/0xa9 > [10680.950908] ======================= > [10680.950910] sysctl table check failed: /afs/hm_retry_RO .1.1 > procname does not match binary path procname > [10680.950915] Pid: 6103, comm: modprobe Tainted: P > 2.6.24-21-generic #1 > [10680.950919] [] set_fail+0x45/0x60 > [10680.950926] [] sysctl_check_table+0x296/0x5b0 > [10680.950936] [] sysctl_check_table+0x2aa/0x5b0 > [10680.950945] [] register_sysctl_table+0x50/0xa0 > [10680.950951] [] osi_sysctl_init+0xa/0x20 [openafs] > [10680.950977] [] init_module+0x40/0xa6 [openafs] > [10680.951004] [] sys_init_module+0x126/0x19c0 > [10680.951030] [] request_key+0x0/0x60 > [10680.951041] [] sysenter_past_esp+0x6b/0xa9 > [10680.951053] ======================= > [10680.951057] sysctl table check failed: /afs/hm_retry_RW .1.2 Sysctl > already exists > [10680.951062] Pid: 6103, comm: modprobe Tainted: P > 2.6.24-21-generic #1 > [10680.951069] [] set_fail+0x45/0x60 > [10680.951076] [] sysctl_check_table+0x354/0x5b0 > [10680.951085] [] sysctl_check_table+0x2aa/0x5b0 > [10680.951094] [] register_sysctl_table+0x50/0xa0 > [10680.951101] [] osi_sysctl_init+0xa/0x20 [openafs] > [10680.951127] [] init_module+0x40/0xa6 [openafs] > [10680.951154] [] sys_init_module+0x126/0x19c0 > [10680.951180] [] request_key+0x0/0x60 > [10680.951191] [] sysenter_past_esp+0x6b/0xa9 > [10680.951202] ======================= > [10680.951204] sysctl table check failed: /afs/hm_retry_RW .1.2 > procname does not match binary path procname > [10680.951209] Pid: 6103, comm: modprobe Tainted: P > 2.6.24-21-generic #1 > [10680.951213] [] set_fail+0x45/0x60 > [10680.951220] [] sysctl_check_table+0x296/0x5b0 > [10680.951228] [] sysctl_check_table+0x2aa/0x5b0 > [10680.951237] [] register_sysctl_table+0x50/0xa0 > [10680.951243] [] osi_sysctl_init+0xa/0x20 [openafs] > [10680.951269] [] init_module+0x40/0xa6 [openafs] > [10680.951295] [] sys_init_module+0x126/0x19c0 > [10680.951320] [] request_key+0x0/0x60 > [10680.951331] [] sysenter_past_esp+0x6b/0xa9 > [10680.951342] ======================= > [10680.951358] sysctl table check failed: /afs/hm_retry_int .1.3 > Unknown sysctl binary path > [10680.951364] Pid: 6103, comm: modprobe Tainted: P > 2.6.24-21-generic #1 > [10680.951372] [] set_fail+0x45/0x60 > [10680.951379] [] sysctl_check_table+0x296/0x5b0 > [10680.951388] [] sysctl_check_table+0x2aa/0x5b0 > [10680.951397] [] register_sysctl_table+0x50/0xa0 > [10680.951403] [] osi_sysctl_init+0xa/0x20 [openafs] > [10680.951429] [] init_module+0x40/0xa6 [openafs] > [10680.951455] [] sys_init_module+0x126/0x19c0 > [10680.951480] [] request_key+0x0/0x60 > [10680.951491] [] sysenter_past_esp+0x6b/0xa9 > [10680.951508] ======================= > [10680.951512] sysctl table check failed: /afs/GCPAGs .1.4 Sysctl > already exists > [10680.951517] Pid: 6103, comm: modprobe Tainted: P > 2.6.24-21-generic #1 > [10680.951522] [] set_fail+0x45/0x60 > [10680.951530] [] sysctl_check_table+0x354/0x5b0 > [10680.951539] [] sysctl_check_table+0x2aa/0x5b0 > [10680.951548] [] register_sysctl_table+0x50/0xa0 > [10680.951554] [] osi_sysctl_init+0xa/0x20 [openafs] > [10680.951580] [] init_module+0x40/0xa6 [openafs] > [10680.951605] [] sys_init_module+0x126/0x19c0 > [10680.951630] [] request_key+0x0/0x60 > [10680.951640] [] sysenter_past_esp+0x6b/0xa9 > [10680.951652] ======================= > [10680.951653] sysctl table check failed: /afs/GCPAGs .1.4 procname > does not match binary path procname > [10680.951659] Pid: 6103, comm: modprobe Tainted: P > 2.6.24-21-generic #1 > [10680.951662] [] set_fail+0x45/0x60 > [10680.951669] [] sysctl_check_table+0x296/0x5b0 > [10680.951678] [] sysctl_check_table+0x2aa/0x5b0 > [10680.951686] [] register_sysctl_table+0x50/0xa0 > [10680.951692] [] osi_sysctl_init+0xa/0x20 [openafs] > [10680.951718] [] init_module+0x40/0xa6 [openafs] > [10680.951744] [] sys_init_module+0x126/0x19c0 > [10680.951769] [] request_key+0x0/0x60 > [10680.951780] [] sysenter_past_esp+0x6b/0xa9 > [10680.951791] ======================= > [10680.951799] sysctl table check failed: /afs/rx_deadtime .1.5 > Unknown sysctl binary path > [10680.951804] Pid: 6103, comm: modprobe Tainted: P > 2.6.24-21-generic #1 > [10680.951812] [] set_fail+0x45/0x60 > [10680.951819] [] sysctl_check_table+0x296/0x5b0 > [10680.951828] [] sysctl_check_table+0x2aa/0x5b0 > [10680.951836] [] register_sysctl_table+0x50/0xa0 > [10680.951841] [] osi_sysctl_init+0xa/0x20 [openafs] > [10680.951867] [] init_module+0x40/0xa6 [openafs] > [10680.951893] [] sys_init_module+0x126/0x19c0 > [10680.951919] [] request_key+0x0/0x60 > [10680.951929] [] sysenter_past_esp+0x6b/0xa9 > [10680.951940] ======================= > [10680.951948] sysctl table check failed: /afs/bkVolPref .1.6 Unknown > sysctl binary path > [10680.951954] Pid: 6103, comm: modprobe Tainted: P > 2.6.24-21-generic #1 > [10680.951961] [] set_fail+0x45/0x60 > [10680.951968] [] sysctl_check_table+0x296/0x5b0 > [10680.951977] [] sysctl_check_table+0x2aa/0x5b0 > [10680.951985] [] register_sysctl_table+0x50/0xa0 > [10680.951990] [] osi_sysctl_init+0xa/0x20 [openafs] > [10680.952016] [] init_module+0x40/0xa6 [openafs] > [10680.952043] [] sys_init_module+0x126/0x19c0 > [10680.952068] [] request_key+0x0/0x60 > [10680.952079] [] sysenter_past_esp+0x6b/0xa9 > [10680.952090] ======================= > [10681.027707] Starting AFS cache scan...found 154 non-empty cache > files (9%). > From senseiwa@mac.com Tue Oct 14 09:49:57 2008 From: senseiwa@mac.com (Franco Milicchio) Date: Tue, 14 Oct 2008 10:49:57 +0200 Subject: [OpenAFS] Openafs broken on Ubuntu Hardy ? In-Reply-To: <48F3DABA.2020905@syssoft.uni-trier.de> References: <48F3DABA.2020905@syssoft.uni-trier.de> Message-ID: <26AAB8F5-46F1-4AC1-86ED-82624F369613@mac.com> --Apple-Mail-4-853861717 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 14, 2008, at 1:33am, Stefan Pohl wrote: > Hi, > > > Madhusudan Singh schrieb: >> Hello, >> >> I am running the latest versions of openafs-modules-source, openafs- >> client and openafs-krb5 on an up to date installation of Ubuntu >> Hardy. I used modules-assistant to compile the kernel module >> against my kernel : >> $ uname -r >> 2.6.24-21-generic >> > I just completed an OpenAFS-client test setup on Ubuntu Hardy. Same > versions of the Openafs-stuff, slightly older kernel (2.6.24-19- > generic) and it works. So it's not broken on Ubuntu Hardy as such. Well, at least it wasn't broken until 2.6.24-19-generic :) >> I can get my tokens alright. >> >> :$ cd /afs/YYY.edu/users/X/Y/Z/XYZABC >> bash: cd: /afs/YYY.edu/users/X/Y/Z/XYZABC: Permission denied > This look like the user you authenticate as, simply doesn't have the > required permissions to access the directory. > >> >> I have previously successfully authenticated to this cell with an >> older version of openafs (it was a year ago, do not remember which). > If you could access the directory a year ago, maybe the acls of the > directory got changed in the meantime. Is your user the owner of the > directory? Can you access the directories above that directory? I agree. Can you please post the output of fs listacl on the directories that you can't access? Also, can you access /afs and /afs/YYY.edu ? -- Sensei UNIX: The world's first computer virus. (The UNIX Haters Handbook) --Apple-Mail-4-853861717 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGITCCAtow ggJDoAMCAQICEEz+Y9F/rca7N/SKFb18rYowDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIyODA4NTgzMVoXDTA5MDIyNzA4NTgz MVowQjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEfMB0GCSqGSIb3DQEJARYQc2Vu c2Vpd2FAbWFjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOd2dYQhwIPSO0ug dAC57eXKdoev/Rmym5+h4BstfBvUiVd2yIHtFYkXbCdrYBoFhQTYmCUSWpj6/EdsgEoWzC3dwEKu bOkiixWZAqjdfL0Zf0TSA1NlYxPQHJcfyh3wKq1mzFsngSvaO4kTT0kNjYvgnQ2seyi7kGziYebr 29kmCGVT8OFSSIaoRws61T/A4nutNnoUV/qVXRc4Ll3LCsy+GVMcUggAoDWeLTqKYqc7Zvmt2swM o2lRcH0IyUX2EVeAcQcWhev+NNrPEfjQszmzn4yZIiaUlVFKBQRAFSt9OOXI/NaN6G07xp4bHV1B vFUoDGbzL49bHeh3+qhLpyUCAwEAAaMtMCswGwYDVR0RBBQwEoEQc2Vuc2Vpd2FAbWFjLmNvbTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAH39aDyoeAVqe79x1s1HC8GRf8KS6xRVvjhc ZvUoeevqmYFPBQfuT1bHa6edE5JfrRC6fpvP8ffWWbXqEnk99cSjISOnHHUJl7FQf0RvQTLACJKh Hr0928Tyap4IKNaxewuyNDicp7CSU9yR2V/FGoQU2v/zx8EyAA0h9ibzWSNAMIIDPzCCAqigAwIB AgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7 TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRA HmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYy aHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0P BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG 9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8 /a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQ Gls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBM/mPRf63Guzf0ihW9fK2KMAkGBSsOAwIaBQCgggFv MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAxNDA4NDk1N1ow IwYJKoZIhvcNAQkEMRYEFFKt9PNoMIU9PXRHSuKKXYPyluqNMIGFBgkrBgEEAYI3EAQxeDB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQTP5j0X+txrs39IoVvXyt ijCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIQTP5j0X+txrs39IoVvXytijANBgkqhkiG9w0BAQEFAASCAQAduRMhPKAjysm9dVql Ar7o9FcdvIhsHZAFMFZJXSIFQSLeyb+r7mNmO+UYqaqBq1ndVKIRTepWgpPGOwG5O39LECtZTHUq guarjwPI3TgnCddT/a2MYvRdsVeBE3RbTpTi0LGfSbeR0WhF10XreiwDqX3rYvwpmp4bXcpVYZ14 eek+FGauJGmz9gAKMPHSHpXvF1yclBEE49HgPdqAgWAY+rpNpGL3wfrOSVOgR3XvzmGjwvW6RRER QE9Wj7ulin456FRFHPE2uhqrwLzLl6eplIcEHen8S03zRwuspiMyru6Jj0D0yO/dxdsbjwPBJfdT AqokKv7V/7ng/4gT1vtjAAAAAAAA --Apple-Mail-4-853861717-- From andym@oak.njit.edu Tue Oct 14 14:34:59 2008 From: andym@oak.njit.edu (Andy Malato) Date: Tue, 14 Oct 2008 09:34:59 -0400 (EDT) Subject: [OpenAFS] max size of vice partition Message-ID: Hello, I was wondering what the maximum size for a vice partition is? I remember reading somewhere that 2TB was the largest, but don't quite recall where I read that. Currently, I am running oafs 1.4.7 on Solaris 10 and I have two vice partitions that are 1.5TB in size. When the system boots, I get messages from fsck about BAD SUPER BLOCK: MAGIC NUMBER WRONG on the two partitions that are 1.5TB. The other vice partitions which are all under 1TB in size, do not exhibit this behavior. Even though an error is produced by fsck, the partitions are mounted and the volumes on them are attached. Running newfs against the partition does not fix the problem. I suspect the problem is with the AFS supplied version of fsck having problems with partitions larger than 1TB? Thanks for any feedback one can provide. Regards, Andy Malato New Jersey Institute of Technology University Computing Systems From haba@kth.se Tue Oct 14 15:19:07 2008 From: haba@kth.se (Harald Barth) Date: Tue, 14 Oct 2008 16:19:07 +0200 (CEST) Subject: [OpenAFS] max size of vice partition In-Reply-To: References: Message-ID: <20081014.161907.27340661.haba@habanero.pdc.kth.se> > I was wondering what the maximum size for a vice partition is? I > remember reading somewhere that 2TB was the largest, but don't quite > recall where I read that. Yes, without patches 2TB is max for 1.4.7. > Currently, I am running oafs 1.4.7 on Solaris 10 and I have two vice > partitions that are 1.5TB in size. What file system type on Solaris? I suspect ufs. > When the system boots, I get > messages from fsck about BAD SUPER BLOCK: MAGIC NUMBER WRONG on the two > partitions that are 1.5TB. The other vice partitions which are all > under 1TB in size, do not exhibit this behavior. That could be a Solaris specific behaviour. I would test with zfs+namei or if that not works with ufs+namei and hope the problem goes away. > I suspect the problem is with the AFS supplied version of fsck having problems > with partitions larger than 1TB? Probably. Convert your world to namei and get rid of the special fsck. Namei type partitions can run the OS supplied file system utilities. Harald. From shadow@gmail.com Tue Oct 14 15:49:10 2008 From: shadow@gmail.com (Derrick Brashear) Date: Tue, 14 Oct 2008 10:49:10 -0400 Subject: [OpenAFS] max size of vice partition In-Reply-To: References: Message-ID: In 1.4.7 it was 2tb. In 1.4.8 it will be another 32 powers of 2 larger, a number I am too lazy to calculate. On Tue, Oct 14, 2008 at 9:34 AM, Andy Malato wrote: > Hello, > > I was wondering what the maximum size for a vice partition is? I > remember reading somewhere that 2TB was the largest, but don't quite > recall where I read that. > > Currently, I am running oafs 1.4.7 on Solaris 10 and I have two vice > partitions that are 1.5TB in size. When the system boots, I get > messages from fsck about BAD SUPER BLOCK: MAGIC NUMBER WRONG on the two > partitions that are 1.5TB. The other vice partitions which are all > under 1TB in size, do not exhibit this behavior. > > Even though an error is produced by fsck, the partitions are mounted and > the volumes on them are attached. Running newfs against the partition does > not fix the problem. > > I suspect the problem is with the AFS supplied version of fsck having problems > with partitions larger than 1TB? Possibly. Note that in Solaris 10 if you update too far you will eventually take a UFS change which breaks the OpenAFS inode fileserver, and by default Solaris 10 builds starting in 1.4.8 will give you a namei fileserver for that reason. For performance reasons you probably want ZFS-backed namei partitions, especially if you are setting up large partitions. From avison48@yahoo.co.uk Tue Oct 14 17:41:38 2008 From: avison48@yahoo.co.uk (avison48) Date: Tue, 14 Oct 2008 16:41:38 +0000 (GMT) Subject: [OpenAFS] Messed up, got "?" directories! how to clean up? Message-ID: <412704.65382.qm@web27303.mail.ukl.yahoo.com> Greetings AFS gurus! I'm getting there with this new server, but am still working thru how to make directories for projects & users. Each gets a "volume", is that right? A chunk of space. I've screwed up some by now & have some "?" directories : in /afs/.ktest.phy (the "read-write") ?--------- ? ? ? ? ? lister ?--------- ? ? ? ? ? user in /afs/ktest.phy ?--------- ? ? ? ? ? home drwxrwxrwx 2 root root 2048 Oct 8 17:15 user/ How do I delete these things so to start afresh? Think I've tried fs rmmount lister and possibly vos remove home (but root's history seems to have lost that data) Very grateful for your advice! Pointers to online howto welcome too - I have now found quite a bit of doc on how to make things, but nothin= g yet on how to clean up .... accidents.=0A=0A=0A From avison48@yahoo.co.uk Tue Oct 14 17:44:12 2008 From: avison48@yahoo.co.uk (avison48) Date: Tue, 14 Oct 2008 16:44:12 +0000 (GMT) Subject: [OpenAFS] Re: Win2K AFS server, setup SL4.5 test-cell server then migrate... Message-ID: <338515.48092.qm@web27305.mail.ukl.yahoo.com> Respectful greetings AFS gurus, In trying to migrate the account-data & user-data off this antique Win2K IBM/TransArc3.5 AFS server onto RHEL4.5 OpenAfs server (& retire the Win2K server); would this idea work: I believe the RHEL4.5 server can become a secondary fileserver & database server to this antique Win2K AFS server. That would enable it to mirror all the user-account info & user-data - correct? No clients at all would point to it - just want it to mirror all the data. Would it then be possible to shutdown AFS services on this new server, and configure it as an AFS server _not_ secondary to the antique Win2K AFS server, but as "the" AFS server of the afs cell. (I believe if it does not know about / try to contact the other AFS server, it could exist) With its own kerberos server running on it, its own Keyfile. Still with no AFS clients except itself. If it could "wake up" and own all the user-accounts & user-data as its own, in its status as an AFS server (not secondary) - that would be great. I'm concerned about where in its ... mirroring of user-account & user-data, would be critical ties or references to its old "master" AFS server. Would that work? If not, how can the data with all the ACLs & etc be transferred to a new server? With humble gratitude to your kindness in helping! =0A=0A=0A From steven.jenkins@gmail.com Tue Oct 14 18:07:48 2008 From: steven.jenkins@gmail.com (Steven Jenkins) Date: Tue, 14 Oct 2008 13:07:48 -0400 Subject: [OpenAFS] Re: Win2K AFS server, setup SL4.5 test-cell server then migrate... In-Reply-To: <338515.48092.qm@web27305.mail.ukl.yahoo.com> References: <338515.48092.qm@web27305.mail.ukl.yahoo.com> Message-ID: On Tue, Oct 14, 2008 at 12:44 PM, avison48 wrote: > > Respectful greetings AFS gurus, > > > In trying to migrate the account-data & user-data off this antique Win2K > IBM/TransArc3.5 AFS server onto RHEL4.5 OpenAfs server (& retire the Win2K > server); > would this idea work: > > I believe the RHEL4.5 server can become a secondary fileserver & database > server to this antique Win2K AFS server. That would enable it to mirror all > the user-account info & user-data - correct? > That is probably correct. The primary question is where your current Kerberos authentication comes from. If you're running the kaserver on your IBM/Transarc AFS server (and given your other emails, that appears to be the case), then your migration should not be too painful (except for updating the CellServDB information on all the clients). A secondary question is how your IP address space will look: given that you'll have exactly 2 AFS servers, you could get into some difficulty with respect to making changes. If you can, bring up the Red Hat server with an IP address lower than your current W2K AFS server. Finally, keep in mind that AFS will only automatically synchronize the user-account info and the volume location information -- you will actually have to move the user data yourself via vos commands (e.g., vos move). > No clients at all would point to it - just want it to mirror all the data. > > Would it then be possible to shutdown AFS services on this new server, > and configure it as an AFS server _not_ secondary to the antique Win2K AFS > server, but as "the" AFS server of the afs cell. > (I believe if it does not know about / try to contact the other AFS > server, it could exist) > With its own kerberos server running on it, its own Keyfile. > Still with no AFS clients except itself. > > If it could "wake up" and own all the user-accounts & user-data as its own, > in its status as an AFS server (not secondary) - that would be great. > > I'm concerned about where in its ... mirroring of user-account & user-data, > would be critical ties or references to its old "master" AFS server. > In general, doing a bos removehost $server $server-to-forget + bos restart $server $process of a server process removes references to $server-to-forget. However, for user data, you will actually need to migrate data from your existing AFS server to the new one: vos listvol -server $old-server will tell you what is on your old server. You should cross-check that with vos listvldb -server $old-server to make sure no references remain to your old server. > Would that work? > > If not, how can the data with all the ACLs & etc be transferred to a new > server? > Assuming you know the current afs password, you should be able to follow the instructions about adding an additional server machine at http://www.openafs.org/pages/doc/QuickStartUnix/auqbg006.htm#HDRWQ99, paying special attention to the section on adding a database server. At a high level, you need to: - tell your existing AFS server about the new one - configure the new AFS server - tell all your clients about the new AFS server - verify everyone is talking to the new one properly - move all user data (i.e., vos move's, and any vos backup's, vos addsite's, and vos release's needed). - stop the old AFS server - tell the new server to stop talking to the old server - tell all the clients to stop talking to the old server The documentation has details on those steps. Feel free to ask, though, if you have further questions. -- Steven Jenkins End Point Corporation http://www.endpoint.com/ From nog@MPA-Garching.MPG.DE Tue Oct 14 19:35:56 2008 From: nog@MPA-Garching.MPG.DE (Norbert E Gruener) Date: Tue, 14 Oct 2008 20:35:56 +0200 Subject: [OpenAFS] Perl AFS module with OpenAFS 1.4.7 In-Reply-To: <87vdw5nxpn.fsf@windlord.stanford.edu> References: <87vdw5nxpn.fsf@windlord.stanford.edu> Message-ID: <20081014183556.GA13661@ncq-1.MPA-Garching.MPG.DE> Hi Russ, On Tue, Oct 07 2008, Russ Allbery wrote: > I vaguely recall there was a mailing list message reporting problems with > the AFS Perl module with current versions of OpenAFS, but I can't find it > again now. I was refreshing my x86 Debian packages and had to make a few > minor fixes for the com_err renaming, but nothing seems horribly broken. > With the below patch applied (and the KAS test disabled, since we have no > kaserver), the module passes all of its tests. I haven't used it to do > anything beyond that, though. > > For some reason, the XS version checking was failing miserably with Perl > 5.10 (complaining about undefined variables), so I had to disable it. I'm > not sure what's up with that; I haven't investigated further. > > A better fix than this one is probably to rename all of the com_err calls > to use the afs_* names, but this was expedient and I wasn't sure if any of > the other symbols were used. I will release a new version within the next few days. I am just doing the final tests. Cheers, Norbert -- Ceterum censeo | PGP encrypted mail preferred. Redmond esse delendam. | PGP Key at www.MPA-Garching.MPG.de/~nog/ From singh.madhusudan@gmail.com Tue Oct 14 19:52:37 2008 From: singh.madhusudan@gmail.com (Madhusudan Singh) Date: Tue, 14 Oct 2008 11:52:37 -0700 Subject: [OpenAFS] Openafs broken on Ubuntu Hardy ? In-Reply-To: <48F3DABA.2020905@syssoft.uni-trier.de> References: <48F3DABA.2020905@syssoft.uni-trier.de> Message-ID: ------=_Part_12943_30464195.1224010357707 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, Thanks for your response. On Mon, Oct 13, 2008 at 4:33 PM, Stefan Pohl wrote: > Hi, > > >> I am running the latest versions of openafs-modules-source, openafs-client >> and openafs-krb5 on an up to date installation of Ubuntu Hardy. I used >> modules-assistant to compile the kernel module against my kernel : >> $ uname -r >> 2.6.24-21-generic >> >> $ sudo apt-cache policy openafs-client >> openafs-client: >> Installed: 1.4.6.dfsg1-2 >> Candidate: 1.4.6.dfsg1-2 >> Version table: >> *** 1.4.6.dfsg1-2 0 >> 500 http://us.archive.ubuntu.com hardy/universe Packages >> 100 /var/lib/dpkg/status >> $ sudo apt-cache policy openafs-modules-source >> openafs-modules-source: >> Installed: 1.4.6.dfsg1-2 >> Candidate: 1.4.6.dfsg1-2 >> Version table: >> *** 1.4.6.dfsg1-2 0 >> 500 http://us.archive.ubuntu.com hardy/universe Packages >> 100 /var/lib/dpkg/status >> >> $ sudo apt-cache policy openafs-krb5 >> openafs-krb5: >> Installed: 1.4.6.dfsg1-2 >> Candidate: 1.4.6.dfsg1-2 >> Version table: >> *** 1.4.6.dfsg1-2 0 >> 500 http://us.archive.ubuntu.com hardy/universe Packages >> 100 /var/lib/dpkg/status >> > I just completed an OpenAFS-client test setup on Ubuntu Hardy. Same > versions of the Openafs-stuff, slightly older kernel (2.6.24-19-generic) and > it works. So it's not broken on Ubuntu Hardy as such. Ok. That gives me hope. > > > >> >> :$ cd /afs/YYY.edu/users/X/Y/Z/XYZABC >> bash: cd: /afs/YYY.edu/users/X/Y/Z/XYZABC: Permission denied >> > This look like the user you authenticate as, simply doesn't have the > required permissions to access the directory. Impossible. I can ssh into the server with the same username and password without any issues. I use rsync to do regular (every 1 hour) backups to this directory ( a process that is cumbersome, which is why I am looking to set up my openafs client). Someone else on the list asked me for the results of fs listacl etc. I can cd to /afs/YYY.EDU/users/X/Y/Z and all its parents perfectly well. I can issue ls and see what is present. o/p of fs listacl at the above level (which is one level above my own directory) : $ fs listacl Access list for . is Normal rights: systems:backup rl system:administrators rlidwka system:anyuser rl I cannot cd into my own directory, so I ssh'ed into the server and issued fs listacl : $ fs listacl Access list for . is Normal rights: systems:backup rl www-hosts l system:administrators rlidwka XYZABC rlidwka > > >> I have previously successfully authenticated to this cell with an older >> version of openafs (it was a year ago, do not remember which). >> > If you could access the directory a year ago, maybe the acls of the > directory got changed in the meantime. Is your user the owner of the > directory? Can you access the directories above that directory? > The owner of all directories under /afs/YYY.EDU/users/X/Y/Z is root.root (tested both through the local /afs tree and by ssh'ing to the server and doing a cd ..). I do not recall what this was when things were working fine (never needed to check), but is this normal (sounds fishy) ? In a different cell, a long time ago, I seem to vaguely recall that the directory was owned by the user in question. To test if this was messing up things, I cd'ed to /afs/YYY.EDU/users/X/Y/Z/XYZABC and issued a command : $ cd XYZABC/Private bash: cd: XYZABC/Private: Permission denied This is more nonsense as ~/Private holds my backups :) Maybe the fact that I do not own /afs/YYY.EDU/users/X/Y/Z/XYZABC is shortcircuiting that command. The owner of all files inside /afs/YYY.EDU/users/X/Y/Z/XYZABC is obviously XYZABC. With regards. ------=_Part_12943_30464195.1224010357707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello,

Thanks for your response.

On Mon, Oct 13, 2008 at 4:33 PM, Stefan Pohl <pohl@syssoft.uni-trier.de> wrote:
Hi,


I am running the latest versions of openafs-modules-source, openafs-client and openafs-krb5 on an up to date installation of Ubuntu Hardy. I used modules-assistant to compile the kernel module against my kernel :
$ uname -r
2.6.24-21-generic

$ sudo apt-cache policy openafs-client
openafs-client:
 Installed: 1.4.6.dfsg1-2
 Candidate: 1.4.6.dfsg1-2
 Version table:
 *** 1.4.6.dfsg1-2 0
       500 http://us.archive.ubuntu.com hardy/universe Packages
       100 /var/lib/dpkg/status
$ sudo apt-cache policy openafs-modules-source
openafs-modules-source:
 Installed: 1.4.6.dfsg1-2
 Candidate: 1.4.6.dfsg1-2
 Version table:
 *** 1.4.6.dfsg1-2 0
       500 http://us.archive.ubuntu.com hardy/universe Packages
       100 /var/lib/dpkg/status

$ sudo apt-cache policy openafs-krb5
openafs-krb5:
 Installed: 1.4.6.dfsg1-2
 Candidate: 1.4.6.dfsg1-2
 Version table:
 *** 1.4.6.dfsg1-2 0
       500 http://us.archive.ubuntu.com hardy/universe Packages
       100 /var/lib/dpkg/status
I just completed an OpenAFS-client test setup on Ubuntu Hardy. Same versions of the Openafs-stuff, slightly older kernel (2.6.24-19-generic) and it works. So it's not broken on Ubuntu Hardy as such.

Ok. That gives me hope.
 




:$ cd /afs/YYY.edu/users/X/Y/Z/XYZABC
bash: cd: /afs/YYY.edu/users/X/Y/Z/XYZABC: Permission denied
This look like the user you authenticate as, simply doesn't have the required permissions to access the directory.

Impossible. I can ssh into the server with the same username and password without any issues. I use rsync to do regular (every 1 hour) backups to this directory ( a process that is cumbersome, which is why I am looking to set up my openafs client).

Someone else on the list asked me for the results of fs listacl etc.

I can cd to /afs/YYY.EDU/users/X/Y/Z and all its parents perfectly well. I can issue ls and see what is present.

o/p of fs listacl at the above level (which is one level above my own directory) :

$ fs listacl
Access list for . is
Normal rights:
  systems:backup rl
  system:administrators rlidwka
  system:anyuser rl

I cannot cd into my own directory, so I ssh'ed into the server and issued fs listacl :


  $ fs listacl
Access list for . is
Normal rights:
  systems:backup rl
  www-hosts l
  system:administrators rlidwka
  XYZABC rlidwka




I have previously successfully authenticated to this cell with an older version of openafs (it was a year ago, do not remember which).
If you could access the directory a year ago, maybe the acls of the directory got changed in the meantime. Is your user the owner of the directory? Can you access the directories above that directory?

The owner of all directories under /afs/YYY.EDU/users/X/Y/Z is root.root (tested both through the local /afs tree and by ssh'ing to the server and doing a cd ..). I do not recall what this was when things were working fine (never needed to check), but is this normal (sounds fishy) ? In a different cell, a long time ago, I seem to vaguely recall that the directory was owned by the user in question. To test if this was messing up things, I cd'ed to /afs/YYY.EDU/users/X/Y/Z/XYZABC and issued a command :

$ cd XYZABC/Private
bash: cd: XYZABC/Private: Permission denied

This is more nonsense as ~/Private holds my backups :) Maybe the fact that I do not own /afs/YYY.EDU/users/X/Y/Z/XYZABC is shortcircuiting that command.
 
The owner of all files inside /afs/YYY.EDU/users/X/Y/Z/XYZABC is obviously XYZABC.

With regards.
------=_Part_12943_30464195.1224010357707-- From jaltman@secure-endpoints.com Tue Oct 14 20:12:44 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Tue, 14 Oct 2008 15:12:44 -0400 Subject: [OpenAFS] Openafs broken on Ubuntu Hardy ? In-Reply-To: References: <48F3DABA.2020905@syssoft.uni-trier.de> Message-ID: <48F4EF2C.7040902@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms060402040900010703050605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Madhusudan Singh wrote: > :$ cd /afs/YYY.edu/users/X/Y/Z/XYZABC > bash: cd: /afs/YYY.edu/users/X/Y/Z/XYZABC: Permission denied > > This look like the user you authenticate as, simply doesn't have the > required permissions to access the directory. > > > Impossible. I can ssh into the server with the same username and > password without any issues. Does your local client have a token for the XYZABC user? --------------ms060402040900010703050605 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMTQxOTEyNDRaMCMGCSqGSIb3DQEJBDEWBBRtk4vy PPQwqn1NdNgkZFGhdQHF9DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAcnWbZRPsjf0tfr2FYpbYj3cQLUa6DDABS3veR3TUV74dJGlQ5+gq nr8uV5Hy9S1S61r6dtnht95/SIDm/DutXgxQm2mRL+ysWdKe78mXZR5QING70AwgXmi85bTG brz7Dpg/sVhl+yfKzQ6UeWoddN0/JqzCzSTuM9aXizF7hRDtjrm8hKjLlPmkWpgECIOO8pV/ wcTHQUO+Se9H6ABe5CzRMaab+AWaFf8iaygoRFRErR7QU5tOY/o+AxyKUX1guJkjqugDZ/DM a0IvaEhtkHaygOQ5sllDXLEko9d5I7fDK5AhQSPFqgW4v9mlOHsriORHBGDPdfhpAJbdsSTt XwAAAAAAAA== --------------ms060402040900010703050605-- From singh.madhusudan@gmail.com Tue Oct 14 21:24:51 2008 From: singh.madhusudan@gmail.com (Madhusudan Singh) Date: Tue, 14 Oct 2008 13:24:51 -0700 Subject: [OpenAFS] Openafs broken on Ubuntu Hardy ? In-Reply-To: <48F4EF2C.7040902@secure-endpoints.com> References: <48F3DABA.2020905@syssoft.uni-trier.de> <48F4EF2C.7040902@secure-endpoints.com> Message-ID: ------=_Part_14502_5403535.1224015892014 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tue, Oct 14, 2008 at 12:12 PM, Jeffrey Altman < jaltman@secure-endpoints.com> wrote: > Madhusudan Singh wrote: > > :$ cd /afs/YYY.edu/users/X/Y/Z/XYZABC > > bash: cd: /afs/YYY.edu/users/X/Y/Z/XYZABC: Permission denied > > > > This look like the user you authenticate as, simply doesn't have the > > required permissions to access the directory. > > > > > > Impossible. I can ssh into the server with the same username and > > password without any issues. > > Does your local client have a token for the XYZABC user? > > I was dearly hoping to avoid such questions by mentioning this rather prominently (along with o/p's of tokens and klist) in my initial post on the thread. Please refer to that. ------=_Part_14502_5403535.1224015892014 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline


On Tue, Oct 14, 2008 at 12:12 PM, Jeffrey Altman <jaltman@secure-endpoints.com> wrote:
Madhusudan Singh wrote:
>         :$ cd /afs/YYY.edu/users/X/Y/Z/XYZABC
>         bash: cd: /afs/YYY.edu/users/X/Y/Z/XYZABC: Permission denied
>
>     This look like the user you authenticate as, simply doesn't have the
>     required permissions to access the directory.
>
>
> Impossible. I can ssh into the server with the same username and
> password without any issues.

Does your local client have a token for the XYZABC user?


I was dearly hoping to avoid such questions by mentioning this rather prominently (along with o/p's of tokens and klist) in my initial post on the thread. Please refer to that.
------=_Part_14502_5403535.1224015892014-- From utoddl@email.unc.edu Wed Oct 15 03:35:26 2008 From: utoddl@email.unc.edu (Todd Lewis) Date: Tue, 14 Oct 2008 22:35:26 -0400 Subject: [OpenAFS] Openafs broken on Ubuntu Hardy ? In-Reply-To: References: <48F3DABA.2020905@syssoft.uni-trier.de> <48F4EF2C.7040902@secure-endpoints.com> Message-ID: <48F556EE.1000703@email.unc.edu> On 10/14/2008 04:24 PM, Madhusudan Singh wrote: > > > On Tue, Oct 14, 2008 at 12:12 PM, Jeffrey Altman > > wrote: > > Madhusudan Singh wrote: > > :$ cd /afs/YYY.edu/users/X/Y/Z/XYZABC > > bash: cd: /afs/YYY.edu/users/X/Y/Z/XYZABC: Permission denied > > > > This look like the user you authenticate as, simply doesn't > have the > > required permissions to access the directory. > > > > > > Impossible. I can ssh into the server with the same username and > > password without any issues. > > Does your local client have a token for the XYZABC user? > > > I was dearly hoping to avoid such questions by mentioning this rather > prominently (along with o/p's of tokens and klist) in my initial post on > the thread. Please refer to that. Patience, friend. We're only trying to help. Do you want your problem fixed or what? Jeffrey's a busy guy; whether he'll have the time to refer back to old messages is not to be taken for granted. I'm not such a busy guy, so I did refer to your initial post. It contains much detail that many initial reports/requests for help often lack. However, crucial information is also obviously obfuscated. You're clearly aware of many issues that could be related to the problem, and no doubt you've taken great care in providing relevant info while covering your privacy issues. However, given that you don't know what's causing the problem, it's possible that the key piece of missing info was destroyed in the obfuscation process. (Granted, I didn't see any likely candidates while reviewing your initial post again.) So, I have no solution to offer, no theory to explain the phenomenon you're seeing. But I will offer this advice: When people are offering to help, and ask a simple question, it may well be worth the time for you, a single individual, to repeat the relevant test and provide the new output rather than expecting N-1 list subscribers to go back and review your initial post. What you've described can be explained exactly by having the wrong tokens (which is what I'm betting on still, even having reviewed you i/p). Double checking never hurts. [Almost relevant aside: This afternoon, my reasonably intelligent neighbor asked me to come over and see if I could coax her new monitor into working again. She'd tried everything. Turns out both ends of the power cable have to be firmly plugged in. When you finally crack this problem, you're likely to find it's something like that.] I'll stop preaching and ask the only other thing that comes to mind. Is your home volume on a different server from the volumes above it? If so, how far off are the clocks on the parent server, your home volume server, and your client? (Probably not relevant, maybe not even a possible source of the problem, but if it's not wrong tokens, you gotta look elsewhere...) -- Todd_Lewis@not.really.obfuscated.edu From senseiwa@mac.com Tue Oct 14 19:00:36 2008 From: senseiwa@mac.com (Franco Milicchio) Date: Tue, 14 Oct 2008 20:00:36 +0200 Subject: [OpenAFS] Openafs broken on Ubuntu Hardy ? In-Reply-To: References: <48F3DABA.2020905@syssoft.uni-trier.de> Message-ID: <8C77AB53-BDCC-47A2-BC52-6D9BE0AA2FDE@mac.com> --Apple-Mail-87-886900381 Content-Type: multipart/alternative; boundary=Apple-Mail-86-886900285 --Apple-Mail-86-886900285 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 14, 2008, at 8:52pm, Madhusudan Singh wrote: > Someone else on the list asked me for the results of fs listacl etc. > > I can cd to /afs/YYY.EDU/users/X/Y/Z and all its parents perfectly > well. I can issue ls and see what is present. Ok, you can access them, that's good news for now. > o/p of fs listacl at the above level (which is one level above my > own directory) : > > $ fs listacl > Access list for . is > Normal rights: > systems:backup rl > system:administrators rlidwka > system:anyuser rl So /afs/YYY.EDU/users/X/Y/Z are accessible, and your home XYZABC resides in Z (as a separate volume, I presume). > I cannot cd into my own directory, so I ssh'ed into the server and > issued fs listacl : > > $ fs listacl > Access list for . is > Normal rights: > systems:backup rl > www-hosts l > system:administrators rlidwka > XYZABC rlidwka > The owner of all directories under /afs/YYY.EDU/users/X/Y/Z is > root.root (tested both through the local /afs tree and by ssh'ing to > the server and doing a cd ..). I do not recall what this was when > things were working fine (never needed to check), but is this normal > (sounds fishy) ? In a different cell, a long time ago, I seem to > vaguely recall that the directory was owned by the user in question. > To test if this was messing up things, I cd'ed to /afs/YYY.EDU/users/ > X/Y/Z/XYZABC and issued a command : > > $ cd XYZABC/Private > bash: cd: XYZABC/Private: Permission denied > > This is more nonsense as ~/Private holds my backups :) Maybe the > fact that I do not own /afs/YYY.EDU/users/X/Y/Z/XYZABC is > shortcircuiting that command. > > The owner of all files inside /afs/YYY.EDU/users/X/Y/Z/XYZABC is > obviously XYZABC. That would have been my second question: can you please post the relevant output of ls -l for your home? I mean, do you have the UNIX permissions to access that directory? Cheers! -- Franco Milicchio Chuck Norris can divide by zero. --Apple-Mail-86-886900285 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Oct 14, 2008, = at 8:52pm, Madhusudan Singh wrote:

Someone = else on the list asked me for the results of fs listacl etc.

I = can cd to /afs/YYY.EDU/users/X/Y/Z and all its = parents perfectly well. I can issue ls and see what is = present.

Ok, you = can access them, that's good news for now.

o/p of = fs listacl at the above level (which is one level above my own = directory) :

$ fs listacl
Access list for . is
Normal = rights:
  systems:backup rl
  system:administrators = rlidwka
  system:anyuser = rl

So = /afs/YYY.EDU/users/X/Y/Z are accessible, and your home XYZABC resides in = Z (as a separate volume, I presume).

I cannot = cd into my own directory, so I ssh'ed into the server and issued fs = listacl :

  $ fs listacl
Access list for . is
Normal = rights:
  systems:backup rl
  www-hosts l
  = system:administrators rlidwka
  XYZABC = rlidwka

The owner = of all directories under /afs/YYY.EDU/users/X/Y/Z is root.root = (tested both through the local /afs tree and by ssh'ing to the server = and doing a cd ..). I do not recall what this was when things were = working fine (never needed to check), but is this normal (sounds fishy) = ? In a different cell, a long time ago, I seem to vaguely recall that = the directory was owned by the user in question. To test if this was = messing up things, I cd'ed to /afs/YYY.EDU/users/X/Y/Z/XYZABC = and issued a command :

$ cd XYZABC/Private
bash: cd: = XYZABC/Private: Permission denied

This is more nonsense as = ~/Private holds my backups :) Maybe the fact that I do not own /afs/YYY.EDU/users/X/Y/Z/XYZABC = is shortcircuiting that command.
 
The owner of all files = inside /afs/YYY.EDU/users/X/Y/Z/XYZABC = is obviously XYZABC.

That = would have been my second question: can you please post the relevant = output of ls -l for your home? I mean, do you have the UNIX permissions = to access that = directory?

Cheers!

=

= --Apple-Mail-86-886900285-- --Apple-Mail-87-886900381 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGITCCAtow ggJDoAMCAQICEEz+Y9F/rca7N/SKFb18rYowDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIyODA4NTgzMVoXDTA5MDIyNzA4NTgz MVowQjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEfMB0GCSqGSIb3DQEJARYQc2Vu c2Vpd2FAbWFjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOd2dYQhwIPSO0ug dAC57eXKdoev/Rmym5+h4BstfBvUiVd2yIHtFYkXbCdrYBoFhQTYmCUSWpj6/EdsgEoWzC3dwEKu bOkiixWZAqjdfL0Zf0TSA1NlYxPQHJcfyh3wKq1mzFsngSvaO4kTT0kNjYvgnQ2seyi7kGziYebr 29kmCGVT8OFSSIaoRws61T/A4nutNnoUV/qVXRc4Ll3LCsy+GVMcUggAoDWeLTqKYqc7Zvmt2swM o2lRcH0IyUX2EVeAcQcWhev+NNrPEfjQszmzn4yZIiaUlVFKBQRAFSt9OOXI/NaN6G07xp4bHV1B vFUoDGbzL49bHeh3+qhLpyUCAwEAAaMtMCswGwYDVR0RBBQwEoEQc2Vuc2Vpd2FAbWFjLmNvbTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAH39aDyoeAVqe79x1s1HC8GRf8KS6xRVvjhc ZvUoeevqmYFPBQfuT1bHa6edE5JfrRC6fpvP8ffWWbXqEnk99cSjISOnHHUJl7FQf0RvQTLACJKh Hr0928Tyap4IKNaxewuyNDicp7CSU9yR2V/FGoQU2v/zx8EyAA0h9ibzWSNAMIIDPzCCAqigAwIB AgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7 TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRA HmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYy aHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0P BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG 9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8 /a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQ Gls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBM/mPRf63Guzf0ihW9fK2KMAkGBSsOAwIaBQCgggFv MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAxNDE4MDAzNlow IwYJKoZIhvcNAQkEMRYEFGuYFB/92LYTKM51p0y+bmqhQRegMIGFBgkrBgEEAYI3EAQxeDB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQTP5j0X+txrs39IoVvXyt ijCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIQTP5j0X+txrs39IoVvXytijANBgkqhkiG9w0BAQEFAASCAQALnnya1PLVvclBK4Hc 4OeZnmuCgaAdecmA4AusFRGmLdiiLDakU/I548UxAP6sOeZjtQjZrQZ4/ZjV8meyPkFb6hIZZpFN YfzMFiWFOWb4Q7olGfjT2Z+AeMku42Uq8YlgQ5vGRKFKzDGtqZmKD3SdKsgffdRzOsrI+ZG+8HC4 LQIpQwZoC9hFit4tobtHH8LrrfAADDfd0kym9bkFIusc+0C6FHAK04kNwI9KScS+LvkT0yUEYiar GhzpStgxWjCL/4605nqLK89xWLyUzXOUzu1XsCDdQ78xZiTpMBX73pcgh5dZFox0P4wivZlcQn0Z AY2n/3xpC6deftPtspdAAAAAAAAA --Apple-Mail-87-886900381-- From Sergio.Gelato@astro.su.se Wed Oct 15 14:59:04 2008 From: Sergio.Gelato@astro.su.se (Sergio Gelato) Date: Wed, 15 Oct 2008 15:59:04 +0200 Subject: [OpenAFS] Openafs broken on Ubuntu Hardy ? In-Reply-To: References: <48F3DABA.2020905@syssoft.uni-trier.de> Message-ID: <20081015135904.GA6666@hanuman.astro.su.se> * Madhusudan Singh [2008-10-14 11:52:37 -0700]: > >> I am running the latest versions of openafs-modules-source, openafs-client > >> and openafs-krb5 on an up to date installation of Ubuntu Hardy. I used > >> modules-assistant to compile the kernel module against my kernel : > >> $ uname -r > >> 2.6.24-21-generic > >> [...] Stefan Pohl: > > I just completed an OpenAFS-client test setup on Ubuntu Hardy. Same > > versions of the Openafs-stuff, slightly older kernel (2.6.24-19-generic) and > > it works. So it's not broken on Ubuntu Hardy as such. > > Ok. That gives me hope. I upgraded from -19 to -21 this morning, built and installed openafs-modules-2.6.24-21-generic_1.4.6.dfsg1-2+2.6.24-21.42_i386.deb using m-a as usual, and it still works. > >> :$ cd /afs/YYY.edu/users/X/Y/Z/XYZABC > >> bash: cd: /afs/YYY.edu/users/X/Y/Z/XYZABC: Permission denied > >> > > This look like the user you authenticate as, simply doesn't have the > > required permissions to access the directory. > > Impossible. I can ssh into the server with the same username and password > without any issues. I use rsync to do regular (every 1 hour) backups to this > directory ( a process that is cumbersome, which is why I am looking to set > up my openafs client). All right. Your problem *is* client-side, then. Could you look at the output of "klist -a -n" and verify that your AFS service ticket is for the right address? (Addressless is usually OK.) NAT gateways sometimes interfere. > o/p of fs listacl at the above level (which is one level above my own > directory) : > > $ fs listacl > Access list for . is > Normal rights: > systems:backup rl > system:administrators rlidwka > system:anyuser rl In other words, you don't need a token to get this far: the ACL grants anonymous read access. > I cannot cd into my own directory, so I ssh'ed into the server and issued fs Which authentication method did you use with ssh? Does GSSAPI work? > listacl : > > $ fs listacl > Access list for . is > Normal rights: > systems:backup rl > www-hosts l > system:administrators rlidwka > XYZABC rlidwka Looks good. One question, though: is the server you ran this on a member of www-hosts ? > The owner of all directories under /afs/YYY.EDU/users/X/Y/Z is root.root > (tested both through the local /afs tree and by ssh'ing to the server and > doing a cd ..). I do not recall what this was when things were working fine > (never needed to check), but is this normal (sounds fishy) ? In a different > cell, a long time ago, I seem to vaguely recall that the directory was owned > by the user in question. The UID that owns the volume root has implicit "a" permission on all directories in the volume. That would let you recover from a "fs setacl $HOME XYZABC none" without having to bother the AFS administrators. But since the ACL explicitly grants you full access, you should have full access --- as long as your token is valid. > To test if this was messing up things, I cd'ed to > /afs/YYY.EDU/users/X/Y/Z/XYZABC and issued a command : > > $ cd XYZABC/Private > bash: cd: XYZABC/Private: Permission denied So you were trying to access /afs/YYY.EDU/users/X/Y/Z/XYZABC/XYZABC/Private ? Was this on the server or on your client? If on the client (as your other statements are suggesting), it simply restates that your token is not being accepted. If on the server, I'd want to see the ACL on that subdirectory (and know whether the server is in www-hosts). > This is more nonsense as ~/Private holds my backups :) Maybe the fact that I > do not own /afs/YYY.EDU/users/X/Y/Z/XYZABC is shortcircuiting that command. I don't see how that would work as an explanation. > The owner of all files inside /afs/YYY.EDU/users/X/Y/Z/XYZABC is obviously > XYZABC. Not so obviously since you said that the top-level directory is owned by root, not by XYZABC. You could be locked out of a subdirectory by its ACL. My impression is that the token you got on your client is either invalid or belongs to a different AFS user. The explanations I can think of are (a) that you are behind a NAT and your token is for the wrong address; (b) that you're obtaining the token via Kerberos cross-realm and it's really for user XYZABC@OTHER.REALM (in which case you could try fs setacl /afs/YYY.EDU/users/X/Y/Z/XYZABC XYZABC@other.realm all on the server where you do have access, or learn how to authenticate to the correct realm in the first place). Can't the helpdesk at YYY.EDU help you with this? From Isaac.Perez@orb-data.com Wed Oct 15 15:15:03 2008 From: Isaac.Perez@orb-data.com (Isaac Perez) Date: Wed, 15 Oct 2008 15:15:03 +0100 Subject: [OpenAFS] server configuration error Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C92ECF.EA167A36 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi=20All, I'm=20trying=20to=20configure=20an=20OpenAFS=20server=20on=20a=20windows=20= 2003=20server. After=20setting=20the=20configuration=20with=20the=20wizard=20(first=20tim= e configuration),=20I=20always=20get=20the=20same=20error=20when=20it=20trie= s=20to=20setup=20the server: 17:11:46=2010/13/08:=20=20Creating=20volume=20root.afs=20on=20partition=20= 3=20with=20a=20quota of=205000. 17:11:48=2010/13/08:=20=20Error=200xffffffff=20has=20occurred:=20server=20= or=20network=20not responding. =20 The=20server=20should=20be=20the=20same=20machine,=20and=20all=20services=20= seem=20to=20be running.=20It=20also=20creates=20the=20volume=20in=20the=20specified=20par= tition.=20And=20the AFS=20Server=20Manager=20shows=20the=20cell=20and=20the=20volume/partition= =20as=20if=20they were=20working=20fine=20(or=20that's=20what=20I=20think). The=20client=20is=20able=20to=20mount=20the=20partition,=20but=20can't=20c= onnect=20to=20get=20AFS tokens=20nor=20create=20files,=20etc...=20in=20the=20mounted=20drive. The=20error=20is=20Authentication=20server=20unavailable. =20 There=20is=20no=20firewall=20and=20the=20client=20can=20ping=20the=20serve= r. =20 Not=20sure=20where=20start=20looking. Any=20ideas? =20 Thanks, Isaac ______________________________________________________________________ This=20email=20has=20been=20scanned=20by=20the=20MessageLabs=20Email=20Sec= urity=20System. For=20more=20information=20please=20visit=20http://www.messagelabs.com/ema= il=20 ______________________________________________________________________ ------_=_NextPart_001_01C92ECF.EA167A36 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable  

Hi=20All,

I’m=20trying=20to=20configure=20an=20OpenAFS server=20on=20a=20windows=202003=20server.

After=20setting=20the=20configuration=20with=20the=20= wizard=20(first=20time configuration),=20I=20always=20get=20the=20same=20error=20when=20it=20trie= s=20to=20setup=20the=20server:

17:11:46=2010/13/08:  Creating=20volume=20root.afs=20on=20partition=203=20with=20a=20quot= a=20of=205000.

17:11:48=2010/13/08:  Error=200xffffffff=20has=20occurred:=20server=20or=20network=20not=20= responding.

 

The=20server=20should=20be=20the=20same=20machine,=20= and=20all=20services=20seem to=20be=20running.=20It=20also=20creates=20the=20volume=20in=20the=20speci= fied=20partition.=20And=20the AFS=20Server=20Manager=20shows=20the=20cell=20and=20the=20volume/partition= =20as=20if=20they=20were working=20fine=20(or=20that’s=20what=20I=20think).

The=20client=20is=20able=20to=20mount=20the=20parti= tion,=20but=20can’t connect=20to=20get=20AFS=20tokens=20nor=20create=20files,=20etc...=20in=20= the=20mounted=20drive.

The=20error=20is=20Authentication=20server=20unavai= lable.

 

There=20is=20no=20firewall=20and=20the=20client=20c= an=20ping=20the=20server.

 

Not=20sure=20where=20start=20looking. Any=20ideas?

 

Thanks,
Isaac


______________________________________________________________________
= This=20email=20has=20been=20scanned=20by=20the=20MessageLabs=20Email=20Sec= urity=20System.
For=20more=20information=20please=20visit=20http://www.messagelabs.com/ema= il=20
______________________________________________________________________
= ------_=_NextPart_001_01C92ECF.EA167A36-- From shadow@gmail.com Wed Oct 15 15:13:43 2008 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 15 Oct 2008 10:13:43 -0400 Subject: [OpenAFS] Openafs broken on Ubuntu Hardy ? In-Reply-To: <20081015135904.GA6666@hanuman.astro.su.se> References: <48F3DABA.2020905@syssoft.uni-trier.de> <20081015135904.GA6666@hanuman.astro.su.se> Message-ID: > (a) that you are behind a NAT and your token is for the wrong address; Tokens (not tickets) are addressless always. From shadow@gmail.com Wed Oct 15 15:16:39 2008 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 15 Oct 2008 10:16:39 -0400 Subject: [OpenAFS] server configuration error In-Reply-To: References: Message-ID: On Wed, Oct 15, 2008 at 10:15 AM, Isaac Perez wrote: > > > Hi All, > > I'm trying to configure an OpenAFS server on a windows 2003 server. > > After setting the configuration with the wizard (first time configuration), > I always get the same error when it tries to setup the server: Windows servers are not currently supported; the setup wizard, in particular, is known to have thread safety issues. > 17:11:46 10/13/08: Creating volume root.afs on partition 3 with a quota of > 5000. > > 17:11:48 10/13/08: Error 0xffffffff has occurred: server or network not > responding. > > > > The server should be the same machine, and all services seem to be running. > It also creates the volume in the specified partition. And the AFS Server > Manager shows the cell and the volume/partition as if they were working fine > (or that's what I think). > > The client is able to mount the partition, but can't connect to get AFS > tokens nor create files, etc... in the mounted drive. > > The error is Authentication server unavailable. > > > > There is no firewall and the client can ping the server. > > > > Not sure where start looking. > > Any ideas? > > > > Thanks, > Isaac > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > -- Derrick From jaltman@secure-endpoints.com Wed Oct 15 15:26:52 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 15 Oct 2008 10:26:52 -0400 Subject: [OpenAFS] server configuration error In-Reply-To: References: Message-ID: <48F5FDAC.2030504@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms080708060703050501000909 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Isaac: I suggest that you read the release notes. The OpenAFS servers on the Windows platform may or may not work. The configuration wizard certainly does not. They can be configured by hand using the same instructions as for the UNIX servers. However, I wouldn't put production data onto such a server. Jeffrey Altman Isaac Perez wrote: > =20 >=20 > Hi All, >=20 > I=E2=80=99m trying to configure an OpenAFS server on a windows 2003 ser= ver. >=20 > After setting the configuration with the wizard (first time > configuration), I always get the same error when it tries to setup the > server: >=20 > 17:11:46 10/13/08: Creating volume root.afs on partition 3 with a quot= a > of 5000. >=20 > 17:11:48 10/13/08: Error 0xffffffff has occurred: server or network no= t > responding. >=20 > =20 >=20 > The server should be the same machine, and all services seem to be > running. It also creates the volume in the specified partition. And the= > AFS Server Manager shows the cell and the volume/partition as if they > were working fine (or that=E2=80=99s what I think). >=20 > The client is able to mount the partition, but can=E2=80=99t connect to= get AFS > tokens nor create files, etc... in the mounted drive. >=20 > The error is Authentication server unavailable. >=20 > =20 >=20 > There is no firewall and the client can ping the server. >=20 > =20 >=20 > Not sure where start looking. >=20 > Any ideas? >=20 > =20 >=20 > Thanks, > Isaac >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ --------------ms080708060703050501000909 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMTUxNDI2NTJaMCMGCSqGSIb3DQEJBDEWBBSTxG0S HtbjaamrFeE7xpsoSALaZTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAIDCD6ywqEK3f4mLyO+vKFDOJsanOtS9vxfDGsQUn5ktzaDwhdtlJ 05Dm8u9x1AaSWEjEaM3zqUQVFvPtW/ey8KorxU537nNiEVKtCSMynqa1t4NtPQrN8BWD7kEb SxC5lpmT59t1/JYy008xcVh2ABrc8MjawwvYo1bQ9C6+GMy+vwiy7ANgE+Gqp4NhMjmDGj47 TtztPZ9TLwno3dykU4A24xhKMhp2iCbcFDiUSAFUibuzE8gWTShozSlY7dSf7l/RTEFLjbgH 2Yt14vMkXil6ln5liwtD2efjc1wtV79LX02pLS9+G7bgyY2rWqS3PfJC9GFVjAGdDfIRwAbZ dgAAAAAAAA== --------------ms080708060703050501000909-- From Isaac.Perez@orb-data.com Wed Oct 15 15:31:20 2008 From: Isaac.Perez@orb-data.com (Isaac Perez) Date: Wed, 15 Oct 2008 15:31:20 +0100 Subject: [OpenAFS] server configuration error In-Reply-To: <48F5FDAC.2030504@secure-endpoints.com> References: <48F5FDAC.2030504@secure-endpoints.com> Message-ID: SmVmZnJleSwKVGhhbmtzIGZvciB0aGUgYW5zd2VyLCB3aXRoIHRoaXMgYW5kIHRoZSBvdGhlciBh bnN3ZXIgSSBnb3QsIEkgdGhpbmsgSSdsbCBub3QgdXNlIG9wZW5BRlMuCgpDaGVlcnMsCklzYWFj CgrCoMKgwqDCoMKgwqDCoMKgwqDCoCDCoMKgwqDCoMKgwqDCoMKgwqDCoCDCoMKgwqDCoMKgwqDC oMKgwqDCoCDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAKCgotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQpGcm9tOiBvcGVuYWZzLWluZm8tYWRtaW5Ab3BlbmFmcy5vcmcgW21haWx0bzpvcGVu YWZzLWluZm8tYWRtaW5Ab3BlbmFmcy5vcmddIE9uIEJlaGFsZiBPZiBKZWZmcmV5IEFsdG1hbgpT ZW50OiAxNSBPY3RvYmVyIDIwMDggMTU6MjcKVG86IElzYWFjIFBlcmV6CkNjOiBvcGVuYWZzLWlu Zm9Ab3BlbmFmcy5vcmcKU3ViamVjdDogUmU6IFtPcGVuQUZTXSBzZXJ2ZXIgY29uZmlndXJhdGlv biBlcnJvcgoKSXNhYWM6CgpJIHN1Z2dlc3QgdGhhdCB5b3UgcmVhZCB0aGUgcmVsZWFzZSBub3Rl cy4KVGhlIE9wZW5BRlMgc2VydmVycyBvbiB0aGUgV2luZG93cyBwbGF0Zm9ybSBtYXkgb3IgbWF5 IG5vdCB3b3JrLgpUaGUgY29uZmlndXJhdGlvbiB3aXphcmQgY2VydGFpbmx5IGRvZXMgbm90LgpU aGV5IGNhbiBiZSBjb25maWd1cmVkIGJ5IGhhbmQgdXNpbmcgdGhlIHNhbWUgaW5zdHJ1Y3Rpb25z IGFzIGZvcgp0aGUgVU5JWCBzZXJ2ZXJzLiAgSG93ZXZlciwgSSB3b3VsZG4ndCBwdXQgcHJvZHVj dGlvbiBkYXRhIG9udG8Kc3VjaCBhIHNlcnZlci4KCkplZmZyZXkgQWx0bWFuCgoKSXNhYWMgUGVy ZXogd3JvdGU6Cj4gIAo+IAo+IEhpIEFsbCwKPiAKPiBJ4oCZbSB0cnlpbmcgdG8gY29uZmlndXJl IGFuIE9wZW5BRlMgc2VydmVyIG9uIGEgd2luZG93cyAyMDAzIHNlcnZlci4KPiAKPiBBZnRlciBz ZXR0aW5nIHRoZSBjb25maWd1cmF0aW9uIHdpdGggdGhlIHdpemFyZCAoZmlyc3QgdGltZQo+IGNv bmZpZ3VyYXRpb24pLCBJIGFsd2F5cyBnZXQgdGhlIHNhbWUgZXJyb3Igd2hlbiBpdCB0cmllcyB0 byBzZXR1cCB0aGUKPiBzZXJ2ZXI6Cj4gCj4gMTc6MTE6NDYgMTAvMTMvMDg6ICBDcmVhdGluZyB2 b2x1bWUgcm9vdC5hZnMgb24gcGFydGl0aW9uIDMgd2l0aCBhIHF1b3RhCj4gb2YgNTAwMC4KPiAK PiAxNzoxMTo0OCAxMC8xMy8wODogIEVycm9yIDB4ZmZmZmZmZmYgaGFzIG9jY3VycmVkOiBzZXJ2 ZXIgb3IgbmV0d29yayBub3QKPiByZXNwb25kaW5nLgo+IAo+ICAKPiAKPiBUaGUgc2VydmVyIHNo b3VsZCBiZSB0aGUgc2FtZSBtYWNoaW5lLCBhbmQgYWxsIHNlcnZpY2VzIHNlZW0gdG8gYmUKPiBy dW5uaW5nLiBJdCBhbHNvIGNyZWF0ZXMgdGhlIHZvbHVtZSBpbiB0aGUgc3BlY2lmaWVkIHBhcnRp dGlvbi4gQW5kIHRoZQo+IEFGUyBTZXJ2ZXIgTWFuYWdlciBzaG93cyB0aGUgY2VsbCBhbmQgdGhl IHZvbHVtZS9wYXJ0aXRpb24gYXMgaWYgdGhleQo+IHdlcmUgd29ya2luZyBmaW5lIChvciB0aGF0 4oCZcyB3aGF0IEkgdGhpbmspLgo+IAo+IFRoZSBjbGllbnQgaXMgYWJsZSB0byBtb3VudCB0aGUg cGFydGl0aW9uLCBidXQgY2Fu4oCZdCBjb25uZWN0IHRvIGdldCBBRlMKPiB0b2tlbnMgbm9yIGNy ZWF0ZSBmaWxlcywgZXRjLi4uIGluIHRoZSBtb3VudGVkIGRyaXZlLgo+IAo+IFRoZSBlcnJvciBp cyBBdXRoZW50aWNhdGlvbiBzZXJ2ZXIgdW5hdmFpbGFibGUuCj4gCj4gIAo+IAo+IFRoZXJlIGlz IG5vIGZpcmV3YWxsIGFuZCB0aGUgY2xpZW50IGNhbiBwaW5nIHRoZSBzZXJ2ZXIuCj4gCj4gIAo+ IAo+IE5vdCBzdXJlIHdoZXJlIHN0YXJ0IGxvb2tpbmcuCj4gCj4gQW55IGlkZWFzPwo+IAo+ICAK PiAKPiBUaGFua3MsCj4gSXNhYWMKPiAKPiAKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gVGhpcyBlbWFpbCBo YXMgYmVlbiBzY2FubmVkIGJ5IHRoZSBNZXNzYWdlTGFicyBFbWFpbCBTZWN1cml0eSBTeXN0ZW0u Cj4gRm9yIG1vcmUgaW5mb3JtYXRpb24gcGxlYXNlIHZpc2l0IGh0dHA6Ly93d3cubWVzc2FnZWxh YnMuY29tL2VtYWlsCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVGhpcyBlbWFpbCBo YXMgYmVlbiBzY2FubmVkIGJ5IHRoZSBNZXNzYWdlTGFicyBFbWFpbCBTZWN1cml0eSBTeXN0ZW0u CkZvciBtb3JlIGluZm9ybWF0aW9uIHBsZWFzZSB2aXNpdCBodHRwOi8vd3d3Lm1lc3NhZ2VsYWJz LmNvbS9lbWFpbCAKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwo= From jaltman@secure-endpoints.com Wed Oct 15 15:51:14 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 15 Oct 2008 10:51:14 -0400 Subject: [OpenAFS] server configuration error In-Reply-To: References: <48F5FDAC.2030504@secure-endpoints.com> Message-ID: <48F60362.7080302@secure-endpoints.com> Isaac Perez wrote: > Jeffrey, > Thanks for the answer, with this and the other answer I got, I think I'll not use openAFS. > > Cheers, > Isaac OpenAFS Servers on Windows are under supported because no one uses them. If you want to host OpenAFS Servers on a Windows box I recommend using UNIX Servers in VMs. The OpenAFS clients on Windows are well supported and will make your end users happy. Jeffrey Altman From yangw3@umdnj.edu Wed Oct 15 17:31:01 2008 From: yangw3@umdnj.edu (Wenping Yang) Date: Wed, 15 Oct 2008 12:31:01 -0400 Subject: [OpenAFS] Openafs 1.4.7, Active Directory 2003 user could not access AFS home directory Message-ID: <48F61AC5.3080101@umdnj.edu> Hello, I was trying to setup openafs 1.4.7 working with both Microsoft active directory and MIT Kerberos 5 server, but it didn't work well. My goal is to enable both AD user and AFS user to access AFS space. The current situation is that both AD and MIT Kerberos authentication work fine, users on both sides could get tickets and tokens, but only AFS user is able to access its AFS home directory, AD users got "Permission denied" error. My AFS and MIT kerberos server is running Linux CentOS 5 - kernel 2.6.18-92.1.10.el5 AD server is Windows 2003 Enterprise edition SP2 AD domain: MESH.UMDNJ.EDU MIT Kerberos realm: MED.UMDNJ.EDU I have two users: MIT Kerberos user: user1 AD user: user101 Here is what I have done: On AD side: C:\Program Files\Support Tools>ktpass.exe -princ afs/med.umdnj.edu@MESH.UMDNJ.ED U -mapuser afsmed@MESH.UMDNJ.EDU -mapOp add -out keytab.afs +rndPass -crypto DES -CBC-CRC +DesOnly -ptype KRB5_NT_PRINCIPAL +DumpSalt Targeting domain controller: rarwjmsist2.mesh.umdnj.edu Using legacy password setting method Successfully mapped afs/med.umdnj.edu to afsmed. Building salt with principalname afs/med.umdnj.edu and domain MESH.UMDNJ.EDU... Hashing password with salt "MESH.UMDNJ.EDUafsmed.umdnj.edu". Key created. Output keytab to keytab.afs: Keytab version: 0x502 keysize 59 afs/med.umdnj.edu@MESH.UMDNJ.EDU ptype 1 (KRB5_NT_PRINCIPAL) vno 4 et ype 0x1 (DES-CBC-CRC) keylength 8 (0x01255b6b83402068) Account afsmed has been set for DES-only encryption. ktpass.exe version is 5.2.3790.3959 Add the key [root@RArwjmsIST1 ~]# asetkey add 4 /etc/krb5.keytab afs/med.umdnj.edu@MESH.UMDNJ.EDU [root@RArwjmsIST1 ~]# asetkey list kvno 3: key is: b0c49b017ffb9440 kvno 4: key is: 61a443c4b55197cd In /etc/krb5.keytab: ktutil: rkt krb5.keytab ktutil: l slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 4 afs/med.umdnj.edu@MESH.UMDNJ.EDU 2 3 afs/med.umdnj.edu@MED.UMDNJ.EDU 3 3 afs@MED.UMDNJ.EDU root@RArwjmsIST1 ~]# klist -e klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0) Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached [root@RArwjmsIST1 ~]# tokens Tokens held by the Cache Manager: --End of list-- [root@RArwjmsIST1 ~]# kinit user1 Password for user1@MED.UMDNJ.EDU: [root@RArwjmsIST1 ~]# aklog [root@RArwjmsIST1 ~]# klist -e Ticket cache: FILE:/tmp/krb5cc_0 Default principal: user1@MED.UMDNJ.EDU Valid starting Expires Service principal 10/15/08 11:41:54 10/16/08 11:41:54 krbtgt/MED.UMDNJ.EDU@MED.UMDNJ.EDU Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1 10/15/08 11:41:56 10/16/08 11:41:54 afs/med.umdnj.edu@MED.UMDNJ.EDU Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with CRC-32 Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached [root@RArwjmsIST1 ~]# tokens Tokens held by the Cache Manager: User's (AFS ID 10001) tokens for afs@med.umdnj.edu [Expires Oct 16 11:41] --End of list-- [root@RArwjmsIST1 ~]# ls -l /afs/med.umdnj.edu/home/user1 total 8 -rw-r--r-- 1 user1 root 9 Sep 3 12:13 testfile drwxrwxrwx 2 user1 root 2048 Sep 4 12:46 testdir drwxrwxrwx 5 root root 2048 Sep 5 14:35 Yesterday From above you can see MIT kerberos user works well. Next I tested with AD user: [root@RArwjmsIST1 ~]# [root@RArwjmsIST1 ~]# unlog [root@RArwjmsIST1 ~]# kdestroy [root@RArwjmsIST1 ~]# klist -e klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0) Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached [root@RArwjmsIST1 ~]# tokens Tokens held by the Cache Manager: --End of list-- [root@RArwjmsIST1 ~]# kinit user101@MESH.UMDNJ.EDU Password for user101@MESH.UMDNJ.EDU: [root@RArwjmsIST1 ~]# aklog [root@RArwjmsIST1 ~]# klist -e Ticket cache: FILE:/tmp/krb5cc_0 Default principal: user101@MESH.UMDNJ.EDU Valid starting Expires Service principal 10/15/08 11:43:07 10/15/08 21:43:06 krbtgt/MESH.UMDNJ.EDU@MESH.UMDNJ.EDU renew until 10/16/08 11:43:07, Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5 10/15/08 11:43:09 10/15/08 21:43:06 afs/med.umdnj.edu@MESH.UMDNJ.EDU renew until 10/16/08 11:43:07, Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with RSA-MD5 Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached [root@RArwjmsIST1 ~]# tokens Tokens held by the Cache Manager: User's (AFS ID 10006) tokens for afs@med.umdnj.edu [Expires Oct 15 21:43] --End of list-- [root@RArwjmsIST1 ~]# ls -l /afs/med.umdnj.edu/home/user101 ls: /afs/med.umdnj.edu/home/user101: Permission denied [root@RArwjmsIST1 ~]# touch /afs/med.umdnj.edu/home/user101/test touch: cannot touch `/afs/med.umdnj.edu/home/user101/test': Permission denied You see user101 has tiekets and token, but could not access its AFS home directory. Permission under /afs/med.umdnj.edu/home/user101 is [admin@RArwjmsIST1 user101]$ fs la . Access list for . is Normal rights: system:administrators rlidwka user101 rlidwk Here is krb5.conf: [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = MED.UMDNJ.EDU dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h forwardable = yes noaddresses = false [realms] MED.UMDNJ.EDU = { kdc = RArwjmsIST1.umdnj.edu:88 admin_server = RArwjmsIST1.umdnj.edu:749 default_domain = med.umdnj.edu } MESH.UMDNJ.EDU = { kdc = RArwjmsIST2.umdnj.edu:88 admin_server = RArwjmsIST2.umdnj.edu:749 default_domain = mesh.umdnj.edu } [domain_realm] .med.umdnj.edu = MED.UMDNJ.EDU med.umdnj.edu = MED.UMDNJ.EDU .mesh.umdnj.edu = MESH.UMDNJ.EDU mesh.umdnj.edu = MESH.UMDNJ.EDU [kdc] profile = /var/kerberos/krb5kdc/kdc.conf I also tried linux ktutil to generate keytab file: ktutil: addent -password -p afs/med.umdnj.edu@MESH.UMDNJ.EDU -k 5 -e des-cbc-crc still I got the same results. I could not figure out why it doesn't work. Any advise would be appreciated. Wenping Yang From shadow@gmail.com Wed Oct 15 17:50:04 2008 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 15 Oct 2008 12:50:04 -0400 Subject: [OpenAFS] Openafs 1.4.7, Active Directory 2003 user could not access AFS home directory In-Reply-To: <48F61AC5.3080101@umdnj.edu> References: <48F61AC5.3080101@umdnj.edu> Message-ID: is MESH.UMDNJ.EDU in krb.conf on the AFS servers? Also, can you kinit with the password you're using to ktutil add on the linux machine when creating the keytab for the AD domain? From yangw3@umdnj.edu Wed Oct 15 18:57:51 2008 From: yangw3@umdnj.edu (Wenping Yang) Date: Wed, 15 Oct 2008 13:57:51 -0400 Subject: [OpenAFS] Openafs 1.4.7, Active Directory 2003 user could not access AFS home directory In-Reply-To: References: <48F61AC5.3080101@umdnj.edu> Message-ID: <48F62F1F.4000209@umdnj.edu> Derrick Brashear wrote: > is MESH.UMDNJ.EDU in krb.conf on the AFS servers? > > No, MESH.UMDNJ.EDU is not on AFS servers. I saw a message talking about adding "-realm" in AFS fileserver, but I am not sure how to make it work for two realms. > Also, can you kinit with the password you're using to ktutil add on > the linux machine when creating the keytab for the AD domain? > No, it did not work. [root@RArwjmsIST1 ~]# kinit afs/med.umdnj.edu@MESH.UMDNJ.EDU Password for afs/med.umdnj.edu@MESH.UMDNJ.EDU: kinit(v5): Preauthentication failed while getting initial credentials From shadow@gmail.com Wed Oct 15 20:30:18 2008 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 15 Oct 2008 15:30:18 -0400 Subject: [OpenAFS] Openafs 1.4.7, Active Directory 2003 user could not access AFS home directory In-Reply-To: <48F62F1F.4000209@umdnj.edu> References: <48F61AC5.3080101@umdnj.edu> <48F62F1F.4000209@umdnj.edu> Message-ID: On Wed, Oct 15, 2008 at 1:57 PM, Wenping Yang wrote: > > Derrick Brashear wrote: >> >> is MESH.UMDNJ.EDU in krb.conf on the AFS servers? >> >> > > No, MESH.UMDNJ.EDU is not on AFS servers. I saw a message talking about > adding "-realm" in AFS fileserver, but I am not sure how to make it work > for two realms. put it in /usr/afs/etc/krb.conf (or equivalent) on the fileservers, or it's not going to work. > >> Also, can you kinit with the password you're using to ktutil add on >> the linux machine when creating the keytab for the AD domain? >> > > No, it did not work. > > [root@RArwjmsIST1 ~]# kinit afs/med.umdnj.edu@MESH.UMDNJ.EDU > Password for afs/med.umdnj.edu@MESH.UMDNJ.EDU: > kinit(v5): Preauthentication failed while getting initial credentials ok, well, that error doesn't say the password is bad, so it's not pertinent. (service principal presumably won't let you password authenticate) -- Derrick From yangw3@umdnj.edu Wed Oct 15 20:52:23 2008 From: yangw3@umdnj.edu (Wenping Yang) Date: Wed, 15 Oct 2008 15:52:23 -0400 Subject: [OpenAFS] Openafs 1.4.7, Active Directory 2003 user could not access AFS home directory In-Reply-To: References: <48F61AC5.3080101@umdnj.edu> <48F62F1F.4000209@umdnj.edu> Message-ID: <48F649F7.20707@umdnj.edu> Derrick Brashear wrote: > On Wed, Oct 15, 2008 at 1:57 PM, Wenping Yang wrote: > >> Derrick Brashear wrote: >> >>> is MESH.UMDNJ.EDU in krb.conf on the AFS servers? >>> >>> >>> >> No, MESH.UMDNJ.EDU is not on AFS servers. I saw a message talking about >> adding "-realm" in AFS fileserver, but I am not sure how to make it work >> for two realms. >> > > put it in /usr/afs/etc/krb.conf (or equivalent) on the fileservers, or > it's not going to work. > > Hi Derrick, Thank you for your quick response. I am sorry for having made some confusion here. Actually realm MESH.UMDNJ.EDU is in my krb5.conf file. The AFS fileserver I referred to is AFS fileserver daemon. Currently it is running as /usr/afs/bin/fileserver I wonder if it needs to be changed to /usr/afs/bin/fileserver -L -realm REALM-NAME if so, how to deal with two realms here? Thanks. Here is my krb5.conf file: [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = MED.UMDNJ.EDU dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h forwardable = yes noaddresses = false [realms] MED.UMDNJ.EDU = { kdc = RArwjmsIST1.umdnj.edu:88 admin_server = RArwjmsIST1.umdnj.edu:749 default_domain = med.umdnj.edu } MESH.UMDNJ.EDU = { kdc = RArwjmsIST2.umdnj.edu:88 admin_server = RArwjmsIST2.umdnj.edu:749 default_domain = mesh.umdnj.edu } [domain_realm] .med.umdnj.edu = MED.UMDNJ.EDU med.umdnj.edu = MED.UMDNJ.EDU .mesh.umdnj.edu = MESH.UMDNJ.EDU mesh.umdnj.edu = MESH.UMDNJ.EDU [kdc] profile = /var/kerberos/krb5kdc/kdc.conf From jaltman@secure-endpoints.com Wed Oct 15 22:11:18 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 15 Oct 2008 17:11:18 -0400 Subject: [OpenAFS] Openafs 1.4.7, Active Directory 2003 user could not access AFS home directory In-Reply-To: <48F649F7.20707@umdnj.edu> References: <48F61AC5.3080101@umdnj.edu> <48F62F1F.4000209@umdnj.edu> <48F649F7.20707@umdnj.edu> Message-ID: <48F65C76.3010204@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms050801040403030400000709 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Wenping Yang wrote: > > Derrick Brashear wrote: >> On Wed, Oct 15, 2008 at 1:57 PM, Wenping Yang wrote: >> >>> Derrick Brashear wrote: >>> >>>> is MESH.UMDNJ.EDU in krb.conf on the AFS servers? >>>> >>>> >>>> >>> No, MESH.UMDNJ.EDU is not on AFS servers. I saw a message talking about >>> adding "-realm" in AFS fileserver, but I am not sure how to make it >>> work >>> for two realms. >>> >> >> put it in /usr/afs/etc/krb.conf (or equivalent) on the fileservers, or >> it's not going to work. >> >> > > Hi Derrick, > > Thank you for your quick response. I am sorry for having made some > confusion here. Actually realm MESH.UMDNJ.EDU is in my krb5.conf file. Derrick is not referring to the Kerberos v5 configuration. He is referring to the AFS kdc.cnf file which is located at the path he specified or another path depending on the file hierarchy used by your deployment. http://www.openafs.org/pages/manpages/5/krb.conf.html Jeffrey Altman --------------ms050801040403030400000709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMTUyMTExMThaMCMGCSqGSIb3DQEJBDEWBBSlUQLe SRY/sItHqL5rJyNqAGraPzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAfDOck56o5dGanvqrbDp0yJ2HVvfrwNX+T5g5Od6iiaPCOnItLxzW gdaX5FbYEVSYE+nR7Mtl93B9sx5+th0K2XcfSjIcTjKtKPwsa9X7F/izjUy5KHsGkMI7Y3/n Zt0U3WK4VQ5gXrX/j/kWsLIvJc8iiIKDXcH0Uu2kI+zYR48aKdyt2xIAeaW7fMabV95HoH+1 +Tsw67c/HxZ/zbrkuU3hu1X7x8g5fQfrpH8AueU2Mlrgurt/wDyWt9OlfZTu8JtgYWnfyl7T 2RByTUcdsc128pgTCphSOC6vw7KEKV1kU6wRuHsEGBhpgjwWzpC1IFr+vEri2pWhEuQo7zZ6 VQAAAAAAAA== --------------ms050801040403030400000709-- From jason@rampaginggeek.com Thu Oct 16 00:27:06 2008 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Wed, 15 Oct 2008 19:27:06 -0400 Subject: [OpenAFS] server configuration error In-Reply-To: References: <48F5FDAC.2030504@secure-endpoints.com> Message-ID: <48F67C4A.1090604@rampaginggeek.com> Isaac Perez wrote: > Jeffrey, > Thanks for the answer, with this and the other answer I got, I think I'll not use openAFS. > > Hi Isaac, Is running a non-windows openafs server a deal-breaker? If you specify your requirements, then perhaps, we can suggest what might work? Sincerely, Jason From David.Bear@asu.edu Thu Oct 16 01:20:10 2008 From: David.Bear@asu.edu (David Bear) Date: Wed, 15 Oct 2008 17:20:10 -0700 Subject: [OpenAFS] Messed up, got "?" directories! how to clean up? In-Reply-To: <412704.65382.qm@web27303.mail.ukl.yahoo.com> References: <412704.65382.qm@web27303.mail.ukl.yahoo.com> Message-ID: <1d1a54bf0810151720h7ef1f8d9wce94091c80066045@mail.gmail.com> ------=_Part_40636_3082786.1224116410676 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tue, Oct 14, 2008 at 9:41 AM, avison48 wrote: > Greetings AFS gurus! > > I'm getting there with this new server, but am still working thru > how to make directories for projects & users. > Each gets a "volume", is that right? A chunk of space. > > I've screwed up some by now & have some "?" directories : > > in /afs/.ktest.phy (the "read-write") > > ?--------- ? ? ? ? ? lister > ?--------- ? ? ? ? ? user > > in /afs/ktest.phy > > ?--------- ? ? ? ? ? home > drwxrwxrwx 2 root root 2048 Oct 8 17:15 user/ > > I would be concerned about how you got these before trying to delete them. > How do I delete these things so to start afresh? > Think I've tried fs rmmount lister and possibly vos remove home > (but root's history seems to have lost that data) > > Very grateful for your advice! Pointers to online howto welcome > too - I have now found quite a bit of doc on how to make things, but > nothing yet on how to clean up .... accidents. > I have always found emacs dired mode a very good helper in getting rid of directory entries that had bad characters in them. > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > -- David Bear College of Public Programs at ASU 602-464-0424 ------=_Part_40636_3082786.1224116410676 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline


On Tue, Oct 14, 2008 at 9:41 AM, avison48 <avison48@yahoo.co.uk> wrote:
Greetings AFS gurus!

I'm getting there with this new server, but am still working thru
how to make directories for projects & users.
Each gets a "volume", is that right? A chunk of space.

I've screwed up some by now & have some "?" directories :

in /afs/.ktest.phy (the "read-write")

?---------  ? ?    ?       ?            ? lister
?---------  ? ?    ?       ?            ? user

in /afs/ktest.phy

?---------  ? ?    ?       ?            ? home
drwxrwxrwx  2 root root 2048 Oct  8 17:15 user/

I would be concerned about how you got these before trying to delete them.
 
How do I delete these things so to start afresh?
Think I've tried fs rmmount lister and possibly vos remove home
(but root's history seems to have lost that data)

Very grateful for your advice! Pointers to online howto welcome
too - I have now found quite a bit of doc on how to make things, but nothing yet on how to clean up .... accidents.
I have always found emacs dired mode a very good helper in getting rid of directory entries that had bad characters in them.
 
 
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info



--
David Bear
College of Public Programs at ASU
602-464-0424
------=_Part_40636_3082786.1224116410676-- From Isaac.Perez@orb-data.com Thu Oct 16 08:32:22 2008 From: Isaac.Perez@orb-data.com (Isaac Perez) Date: Thu, 16 Oct 2008 08:32:22 +0100 Subject: [OpenAFS] server configuration error In-Reply-To: <48F67C4A.1090604@rampaginggeek.com> References: <48F5FDAC.2030504@secure-endpoints.com> <48F67C4A.1090604@rampaginggeek.com> Message-ID: CgpIaSBKZWZmcmV5LAoKT3VyIHByb2JsZW0gaXMgdGhlIGxhY2sgb2YgcGVyZm9ybWFuY2UgYW5k IHJlbGlhYmlsaXR5IG9mIENJRlMvU01CIGFjcm9zcyBWUE4sIEkgZm91bmQgb3BlbkFGUyBhbmQg SSB0aG91Z2h0IHRoYXQgaXQgd291bGQgYmUgd29ydGggdG8gZ2l2aW5nIGl0IGEgY2hhbmNlLgpB cyBzb21lIHdpbmRvd3MgYXBwbGljYXRpb25zIG11c3QgcnVuIGluIHRoZSBzZXJ2ZXIsIG1vdmlu ZyBpdCB0byBsaW51eCBpcyBub3QgYW4gb3B0aW9uLiBJbnN0YWxsaW5nIGEgdmlydHVhbGl6ZWQg bGludXggbWFjaGluZSBpbiB0aGUgc2VydmVyIGNvdWxkIGJlIGFuIG9wdGlvbi4gQnV0IGl0IHdp bGwgYWRkIGxldmVscyBvZiBjb21wbGV4aXR5IHRvIHRoZSBzeXN0ZW0sIGFuZCBJIHdvdWxkIG5v dCBsaWxrZSB0aGF0LgoKwqDCoMKgwqDCoMKgwqDCoMKgwqAgwqDCoMKgwqDCoMKgwqDCoMKgwqAg wqDCoMKgwqDCoMKgwqDCoMKgwqAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgCkFzIHNvbWUg cGVvcGxlIHN1Z2dlc3RlZCwgZ29pbmcgdG8gcGF5ZWQgc3VwcG9ydCBjb3VsZCBoZWxwIHRoZSBw cm9qZWN0LiBCdXQgSSBkb3VidCBteSBkaXJlY3RvcnMgd2lsbCBhcHByb3ZlIGJ1ZGdldCBmb3Ig c29tZXRoaW5nIGRvZXNuJ3Qgd29ya3MgaW4gd2luZG93cyBmcm9tIHRoZSBzdGFydC4KCkkgdHJp ZWQgd2luZG93cyBORlMsIGJ1dCBpdCBzZWVtcyB0aGF0IHdpbmRvd3MgY2xpZW50cyB3aXRoIHdp bmRvd3Mgc2VydmVyIGRvZXNuJ3Qgd29yayBhcyB3ZWxsIGFzIFdpbmRvd3MtTGludXguCgpBbnkg aWRlYSBvZiBob3cgY291bGQgaW1wcm92ZSB0aGUgY29tbXVuaWNhdGlvbnMgd2l0aCBhIHJlbGlh YmxlIHNlcnZpY2UvcHJvdG9jb2w/CgpUaGFua3MsCklzYWFjCgotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQpGcm9tOiBKYXNvbiBFZGdlY29tYmUgW21haWx0bzpqYXNvbkByYW1wYWdpbmdnZWVr LmNvbV0gClNlbnQ6IDE2IE9jdG9iZXIgMjAwOCAwMDoyNwpUbzogSXNhYWMgUGVyZXoKQ2M6IGph bHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb207IG9wZW5hZnMtaW5mb0BvcGVuYWZzLm9yZwpTdWJq ZWN0OiBSZTogW09wZW5BRlNdIHNlcnZlciBjb25maWd1cmF0aW9uIGVycm9yCgpJc2FhYyBQZXJl eiB3cm90ZToKPiBKZWZmcmV5LAo+IFRoYW5rcyBmb3IgdGhlIGFuc3dlciwgd2l0aCB0aGlzIGFu ZCB0aGUgb3RoZXIgYW5zd2VyIEkgZ290LCBJIHRoaW5rIEknbGwgbm90IHVzZSBvcGVuQUZTLgo+ Cj4gICAKSGkgSXNhYWMsCgpJcyBydW5uaW5nIGEgbm9uLXdpbmRvd3Mgb3BlbmFmcyBzZXJ2ZXIg YSBkZWFsLWJyZWFrZXI/IElmIHlvdSBzcGVjaWZ5CnlvdXIgcmVxdWlyZW1lbnRzLCB0aGVuIHBl cmhhcHMsIHdlIGNhbiBzdWdnZXN0IHdoYXQgbWlnaHQgd29yaz8KClNpbmNlcmVseSwKSmFzb24K Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KVGhpcyBlbWFpbCBoYXMgYmVlbiBzY2FubmVkIGJ5IHRoZSBNZXNzYWdl TGFicyBFbWFpbCBTZWN1cml0eSBTeXN0ZW0uCkZvciBtb3JlIGluZm9ybWF0aW9uIHBsZWFzZSB2 aXNpdCBodHRwOi8vd3d3Lm1lc3NhZ2VsYWJzLmNvbS9lbWFpbCAKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpUaGlzIGVtYWlsIGhhcyBiZWVuIHNjYW5uZWQgYnkgdGhlIE1lc3NhZ2VMYWJz IEVtYWlsIFNlY3VyaXR5IFN5c3RlbS4KRm9yIG1vcmUgaW5mb3JtYXRpb24gcGxlYXNlIHZpc2l0 IGh0dHA6Ly93d3cubWVzc2FnZWxhYnMuY29tL2VtYWlsIApfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCg== From haba@kth.se Thu Oct 16 10:08:55 2008 From: haba@kth.se (Harald Barth) Date: Thu, 16 Oct 2008 11:08:55 +0200 (CEST) Subject: [OpenAFS] server configuration error In-Reply-To: References: <48F67C4A.1090604@rampaginggeek.com> Message-ID: <20081016.110855.240158305.haba@habanero.pdc.kth.se> > Our problem is the lack of performance and reliability of CIFS/SMB > across VPN, I found openAFS and I thought that it would be worth to > giving it a chance. I guess that reliability will improve. If performance will improve would be guessing real hard. > As some windows applications must run in the server, moving it to linux is not an option. Because there is only one server or because these applications today use the file system that is exported by SMB? In AFS, you always access AFS space through a client mount, not the files on the server. > Installing a virtualized linux machine in the server could be an > option. But it will add levels of complexity to the system, and I > would not lilke that. Another aspect is security. I like my AFS servers separate. Harald. From shadow@gmail.com Thu Oct 16 13:07:43 2008 From: shadow@gmail.com (Derrick Brashear) Date: Thu, 16 Oct 2008 08:07:43 -0400 Subject: [OpenAFS] server configuration error In-Reply-To: References: <48F5FDAC.2030504@secure-endpoints.com> <48F67C4A.1090604@rampaginggeek.com> Message-ID: On Thu, Oct 16, 2008 at 3:32 AM, Isaac Perez wrote: > > > Hi Jeffrey, > > Our problem is the lack of performance and reliability of CIFS/SMB across VPN, I found openAFS and I thought that it would be worth to giving it a chance. > As some windows applications must run in the server, Applications don't need to run in the server. You can install Windows applications on a fileserver hosted on a Linux machine. Or is the issue that you have just one machine? > moving it to linux is not an option. Installing a virtualized linux machine in the server could be an option. But it will add levels of complexity to the system, and I would not lilke that. From jaltman@secure-endpoints.com Thu Oct 16 14:19:35 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 16 Oct 2008 09:19:35 -0400 Subject: [OpenAFS] server configuration error In-Reply-To: References: <48F5FDAC.2030504@secure-endpoints.com> <48F67C4A.1090604@rampaginggeek.com> Message-ID: <48F73F67.9070603@secure-endpoints.com> Isaac: You may be under the assumption that AFS is similar to SMB or CIFS where the file system that is exported to the world is locally readable/writable to applications on the file server. This is not the case. In AFS, volumes containing directories, files, mount points and symlinks are stored in a format that is only readable to the AFS server processes. All access to that data is performed via the AFS client (or AFS cache manager.) This model provides many of AFS' strengths: * location independence - the applications do not care where the data is located and volumes can be moved from one file server to another while it is being used. This is important for load balancing or hardware maintenance without downtime. * readonly replication - a readonly snapshot of a volume can be taken and replicated to multiple file servers to improve access to clients and provide failover. * online backup - for each read/write volume a single backup volume can be maintained that permits users to recover the file they accidentally deleted. Backup volumes are created using copy-on-write semantics so they do not take up additional space on the disk until the user begins to make changes to the read-write volume. * heterogeneous server deployments - an AFS cell can use a mixture of operating system and hardware platforms for its servers and clients. * authentication - all access goes through the file server process and is therefore authenticated in a consistent manner. Kerberos is always used. The performance benefit that you will receive by using AFS is avoidance of the VPN for access and data caching on the client. Instead of reading data from the file server each time the file is opened, the client can access it out of the local disk cache if the data version of the file has not changed. Although Microsoft has made great strides in improving CIFS performance over the WAN with SMB 2.0 as found in Vista and 2008, it requires that both parties be either Vista or 2008. Old Windows operating systems can not take advantage of the benefits. If you want to run the AFS Services on a Windows Server, I can certainly make that happen but there is a month or two of work that needs to be done to make it production quality. Given that it doesn't matter what OS the services run on because the data on disk cannot be locally accessed in any case, every organization that has asked for AFS services on Windows Server always ends up deciding to just use Linux, MacOS X, Solaris, etc. because it is cheaper in the short term to use what is already available. If on the other hand you do want to use Windows builds of the services please contact me off-list. Jeffrey Altman Isaac Perez wrote: > > Hi Jeffrey, > > Our problem is the lack of performance and reliability of CIFS/SMB across VPN, I found openAFS and I thought that it would be worth to giving it a chance. > As some windows applications must run in the server, moving it to linux is not an option. Installing a virtualized linux machine in the server could be an option. But it will add levels of complexity to the system, and I would not lilke that. > > As some people suggested, going to payed support could help the project. But I doubt my directors will approve budget for something doesn't works in windows from the start. > > I tried windows NFS, but it seems that windows clients with windows server doesn't work as well as Windows-Linux. > > Any idea of how could improve the communications with a reliable service/protocol? > > Thanks, > Isaac From jonathan.wheeler@stfc.ac.uk Thu Oct 16 14:59:46 2008 From: jonathan.wheeler@stfc.ac.uk (Wheeler, JF (Jonathan)) Date: Thu, 16 Oct 2008 14:59:46 +0100 Subject: [OpenAFS] Linux startup script for OpenAFS server Message-ID: I am in the process of installing OpenAFS on Linux servers; currently our AFS server runs on AIX. The RPMs that install the Linux server software (Scientific Linux for anyone interested) do not seem to have a start-up script for the server. Before I write my own, does anyone have such a script that they would be willing to post to the list or just to me. Many thanks Jonathan Wheeler e-Science Centre Rutherford Appleton Laboratory (cell rl.ac.uk) -- Scanned by iCritical for STFC. From haba@kth.se Thu Oct 16 16:13:46 2008 From: haba@kth.se (Harald Barth) Date: Thu, 16 Oct 2008 17:13:46 +0200 (CEST) Subject: [OpenAFS] Linux startup script for OpenAFS server In-Reply-To: References: Message-ID: <20081016.171346.265676300.haba@habanero.pdc.kth.se> I start with # /usr/openafs/sbin/bosserver & by hand and then it normally runs and runs and runs. Sometimes Linux decides to crash on me, in that cases I don't need a shutdown script ;) I must admit that I have not had any urge to write a startup script. Such a beast should probably just start bosserver for startup and do a bos shutdown localhost -local followed by killing the bosserver. That should make a clean start possible again. Harald. From yangw3@umdnj.edu Thu Oct 16 16:30:46 2008 From: yangw3@umdnj.edu (Wenping Yang) Date: Thu, 16 Oct 2008 11:30:46 -0400 Subject: [OpenAFS] Openafs 1.4.7, Active Directory 2003 user could not access AFS home directory In-Reply-To: <48F65C76.3010204@secure-endpoints.com> References: <48F61AC5.3080101@umdnj.edu> <48F62F1F.4000209@umdnj.edu> <48F649F7.20707@umdnj.edu> <48F65C76.3010204@secure-endpoints.com> Message-ID: <48F75E26.8060800@umdnj.edu> Jeffrey Altman wrote: > Wenping Yang wrote: > >> Derrick Brashear wrote: >> >>> On Wed, Oct 15, 2008 at 1:57 PM, Wenping Yang wrote: >>> >>> >>>> Derrick Brashear wrote: >>>> >>>> >>>>> is MESH.UMDNJ.EDU in krb.conf on the AFS servers? >>>>> >>>>> >>>>> >>>>> >>>> No, MESH.UMDNJ.EDU is not on AFS servers. I saw a message talking about >>>> adding "-realm" in AFS fileserver, but I am not sure how to make it >>>> work >>>> for two realms. >>>> >>>> >>> put it in /usr/afs/etc/krb.conf (or equivalent) on the fileservers, or >>> it's not going to work. >>> >>> >>> >> Hi Derrick, >> >> Thank you for your quick response. I am sorry for having made some >> confusion here. Actually realm MESH.UMDNJ.EDU is in my krb5.conf file. >> > > Derrick is not referring to the Kerberos v5 configuration. > He is referring to the AFS kdc.cnf file which is located at the path > he specified or another path depending on the file hierarchy used > by your deployment. > > http://www.openafs.org/pages/manpages/5/krb.conf.html > > Jeffrey Altman > Jeffrey and Derrick, Thank you for the information. I was so stupid that did not get Derrick's point in the first place. Unfortunately, I am still getting "permission denied" after I put krb.conf file in both places: [root@RArwjmsIST1 etc]# cat /usr/vice/etc/krb.conf MESH.UMDNJ.EDU [root@RArwjmsIST1 etc]# cat /usr/afs/etc/krb.conf MESH.UMDNJ.EDU Best regards, Wenping From shadow@gmail.com Thu Oct 16 16:36:48 2008 From: shadow@gmail.com (Derrick Brashear) Date: Thu, 16 Oct 2008 11:36:48 -0400 Subject: [OpenAFS] Openafs 1.4.7, Active Directory 2003 user could not access AFS home directory In-Reply-To: <48F75E26.8060800@umdnj.edu> References: <48F61AC5.3080101@umdnj.edu> <48F62F1F.4000209@umdnj.edu> <48F649F7.20707@umdnj.edu> <48F65C76.3010204@secure-endpoints.com> <48F75E26.8060800@umdnj.edu> Message-ID: > > Thank you for the information. I was so stupid that did not get Derrick's > point in the first place. > > Unfortunately, I am still getting "permission denied" after I put krb.conf > file in both places: > > [root@RArwjmsIST1 etc]# cat /usr/vice/etc/krb.conf > MESH.UMDNJ.EDU > [root@RArwjmsIST1 etc]# cat /usr/afs/etc/krb.conf > MESH.UMDNJ.EDU You only need it in the latter, (assuming that's where KeyFile also is, it's /usr/afs/etc), and the server needs to have been restarted. If you still lose, the next step is to look at the key you got from AD. From yangw3@umdnj.edu Thu Oct 16 18:23:14 2008 From: yangw3@umdnj.edu (Wenping Yang) Date: Thu, 16 Oct 2008 13:23:14 -0400 Subject: [OpenAFS] Openafs 1.4.7, Active Directory 2003 user could not access AFS home directory In-Reply-To: References: <48F61AC5.3080101@umdnj.edu> <48F62F1F.4000209@umdnj.edu> <48F649F7.20707@umdnj.edu> <48F65C76.3010204@secure-endpoints.com> <48F75E26.8060800@umdnj.edu> Message-ID: <48F77882.1040303@umdnj.edu> Derrick Brashear wrote: >> Thank you for the information. I was so stupid that did not get Derrick's >> point in the first place. >> >> Unfortunately, I am still getting "permission denied" after I put krb.conf >> file in both places: >> >> [root@RArwjmsIST1 etc]# cat /usr/vice/etc/krb.conf >> MESH.UMDNJ.EDU >> [root@RArwjmsIST1 etc]# cat /usr/afs/etc/krb.conf >> MESH.UMDNJ.EDU >> > > You only need it in the latter, (assuming that's where KeyFile also > is, it's /usr/afs/etc), and the server needs to have been restarted. > > If you still lose, the next step is to look at the key you got from AD. > Finally it works. I removed the AD key from AFS Keyfile, generated a new keyfile from AD, added it into AFS Keyfile, which fixed the problem. Thank you for your help. Wenping From tcreedon@easystreet.net Thu Oct 16 19:24:39 2008 From: tcreedon@easystreet.net (Ted Creedon) Date: Thu, 16 Oct 2008 10:24:39 -0800 Subject: [OpenAFS] Linux startup script for OpenAFS server In-Reply-To: <20081016.171346.265676300.haba@habanero.pdc.kth.se> References: <20081016.171346.265676300.haba@habanero.pdc.kth.se> Message-ID: grab one from the SuSE distro, there's a server and client bash script /etc/init.d/afs-server /etc/init.d/afs-client /etc/sysconfig/afs-client.conf (called by the client script) On Thu, Oct 16, 2008 at 7:13 AM, Harald Barth wrote: > > I start with > > # /usr/openafs/sbin/bosserver & > > by hand and then it normally runs and runs and runs. Sometimes Linux > decides to crash on me, in that cases I don't need a shutdown script > ;) I must admit that I have not had any urge to write a startup > script. Such a beast should probably just start bosserver for startup > and do a bos shutdown localhost -local followed by killing the > bosserver. That should make a clean start possible again. > > Harald. > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > From rkemp@srhs.net Mon Oct 13 20:31:27 2008 From: rkemp@srhs.net (Randy Kemp) Date: Mon, 13 Oct 2008 15:31:27 -0400 Subject: [OpenAFS] File Server appears to stop responding In-Reply-To: <48F357A8.8050709@srhs.net> References: <48DD3552.5070000@srhs.net> <20080927.131045.60540471.haba@habanero.pdc.kth.se> <48E071A6.3030708@srhs.net> <48F352B8.9040104@srhs.net> <48F357A8.8050709@srhs.net> Message-ID: <48F3A20F.2000205@srhs.net> This is a multi-part message in MIME format. --------------070705070407040700010900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It did it again as suspected. The requested backtrace is attached. It's inaccessible from any client (not just the app server) on all interfaces. No one will need to use AFS or the app server for the remainder of the day so I will leave it in this state in case anyone comes up with some other bit of info that might be useful to retrieve. Randy Kemp wrote: > Derrick Brashear wrote: >> On Mon, Oct 13, 2008 at 9:52 AM, Randy Kemp wrote: >> >>> I had users again today to test with. The problem with fileserver >>> ceasing to respond and generating the "CallPreamble: Couldn't get CPS. >>> Too many lockers" error occurred again. >>> >> To the app server, or to both machines? I assume, actually, only to >> the app server. >> > The last time it occurred (when I sent the first message) it stopped > responding to all connected clients. I did not think to test that this. >>> I'm now running fileserver with the following parameters, "-p 128 -b >>> 512 >>> -l 3072 -s 3072 -vc 3072 -cb 65536 -busyat 1536 -rxpck 1024 -nojumbo". >>> At the time that the problem started there were two physical clients >>> connected, one was a standalone workstation and the other was the >>> aforementioned application server with approximately 40 users logged >>> in. All requests from said application server are now coming from a >>> single address to a single interface on the AFS server. >>> It turns out that restarting AFS vs. rebooting the server does >>> not make >>> the problem go away as I previously thought. It was purely >>> coincidental >>> that I had also restarted the application server last time. What I >>> have >>> now discovered is that even rebooting the AFS server does not resolve >>> the problem (errors start immediately upon startup) and it now appears >>> that the problem is only resolved by restarting the client on the >>> application server. The application server is running OpenAFS client >>> version 1.4.7 on Ubuntu Linux with kernel version 2.6.24. >>> >> >> echo t > /proc/sysrq-trigger on the application server, as root, when >> the fileserver won't talk to it, collect the system log from e.g. >> /var/log/messages with the backtrace in it, and let us see that. >> > I have about 90 users that will try to log in to the app server later > today so I'm sure it will do it again. I'll do this and test it from > other clients if/when it happens. > -- Randy Kemp --------------070705070407040700010900 Content-Type: text/plain; name="messages" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="messages" Oct 13 14:58:01 app1 kernel: [12203.098285] SysRq : Show State Oct 13 14:58:01 app1 kernel: [12203.098295] task PC stack pid father Oct 13 14:58:01 app1 kernel: [12203.098298] init S 0000000000000000 0 1 0 Oct 13 14:58:01 app1 kernel: [12203.098303] ffff8104774dd9c8 0000000000000086 0000000000000000 ffffffff80232633 Oct 13 14:58:01 app1 kernel: [12203.098308] ffff810280062880 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:01 app1 kernel: [12203.098311] ffffffff8067d0a0 ffffffff80680c00 ffff81027598a230 ffff8104774dd994 Oct 13 14:58:01 app1 kernel: [12203.098316] Call Trace: Oct 13 14:58:01 app1 kernel: [12203.098336] [set_next_entity+0x23/0x50] set_next_entity+0x23/0x50 Oct 13 14:58:01 app1 kernel: [12203.098348] [] datagram_poll+0x0/0x100 Oct 13 14:58:01 app1 kernel: [12203.098356] [cciss:schedule_timeout+0x95/0xd0] schedule_timeout+0x95/0xd0 Oct 13 14:58:01 app1 kernel: [12203.098362] [fuse:remove_wait_queue+0x19/0x60] remove_wait_queue+0x19/0x60 Oct 13 14:58:01 app1 kernel: [12203.098366] [reiserfs:add_wait_queue+0x1c/0x2360] add_wait_queue+0x1c/0x60 Oct 13 14:58:01 app1 kernel: [12203.098372] [inotify_poll+0x57/0x70] inotify_poll+0x57/0x70 Oct 13 14:58:01 app1 kernel: [12203.098377] [do_select+0x468/0x570] do_select+0x468/0x570 Oct 13 14:58:01 app1 kernel: [12203.098390] [__pollwait+0x0/0x130] __pollwait+0x0/0x130 Oct 13 14:58:01 app1 kernel: [12203.098396] [] default_wake_function+0x0/0x10 Oct 13 14:58:01 app1 kernel: [12203.098402] [] default_wake_function+0x0/0x10 Oct 13 14:58:01 app1 kernel: [12203.098409] [] default_wake_function+0x0/0x10 Oct 13 14:58:01 app1 kernel: [12203.098415] [number+0x191/0x2e0] number+0x191/0x2e0 Oct 13 14:58:01 app1 kernel: [12203.098419] [number+0x2c4/0x2e0] number+0x2c4/0x2e0 Oct 13 14:58:01 app1 kernel: [12203.098424] [dummy_inode_delete+0x0/0x10] dummy_inode_delete+0x0/0x10 Oct 13 14:58:01 app1 kernel: [12203.098429] [update_curr+0x71/0x100] update_curr+0x71/0x100 Oct 13 14:58:01 app1 kernel: [12203.098435] [enqueue_entity+0x37/0x70] enqueue_entity+0x37/0x70 Oct 13 14:58:01 app1 kernel: [12203.098443] [vsnprintf+0x331/0x6e0] vsnprintf+0x331/0x6e0 Oct 13 14:58:01 app1 kernel: [12203.098448] [current_fs_time+0x1e/0x30] current_fs_time+0x1e/0x30 Oct 13 14:58:01 app1 kernel: [12203.098455] [libata:snprintf+0x44/0x50] snprintf+0x44/0x50 Oct 13 14:58:01 app1 kernel: [12203.098462] [pipe_read+0x2a6/0x440] pipe_read+0x2a6/0x440 Oct 13 14:58:01 app1 kernel: [12203.098469] [core_sys_select+0x209/0x300] core_sys_select+0x209/0x300 Oct 13 14:58:01 app1 kernel: [12203.098483] [release_task+0x284/0x360] release_task+0x284/0x360 Oct 13 14:58:01 app1 kernel: [12203.098487] [fuse:remove_wait_queue+0x19/0x60] remove_wait_queue+0x19/0x60 Oct 13 14:58:01 app1 kernel: [12203.098491] [do_wait+0xa1c/0xcd0] do_wait+0xa1c/0xcd0 Oct 13 14:58:01 app1 kernel: [12203.098502] [sys_select+0x44/0x1c0] sys_select+0x44/0x1c0 Oct 13 14:58:01 app1 kernel: [12203.098506] [] default_wake_function+0x0/0x10 Oct 13 14:58:01 app1 kernel: [12203.098510] [sys_read+0x53/0x90] sys_read+0x53/0x90 Oct 13 14:58:01 app1 kernel: [12203.098517] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:01 app1 kernel: [12203.098526] Oct 13 14:58:01 app1 kernel: [12203.098528] kthreadd S 0000000000000003 0 2 0 Oct 13 14:58:01 app1 kernel: [12203.098532] ffff81027598df20 0000000000000046 0000000000000c31 0000007000000001 Oct 13 14:58:01 app1 kernel: [12203.098538] 0000000000000c31 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:01 app1 kernel: [12203.098542] ffffffff8067d0a0 ffffffff80680c00 ffff81027598aa10 0000000000000001 Oct 13 14:58:01 app1 kernel: [12203.098547] Call Trace: Oct 13 14:58:01 app1 kernel: [12203.098562] [kthreadd+0x132/0x140] kthreadd+0x132/0x140 Oct 13 14:58:01 app1 kernel: [12203.098567] [child_rip+0xa/0x12] child_rip+0xa/0x12 Oct 13 14:58:01 app1 kernel: [12203.098577] [do_set_mempolicy+0x43/0x110] do_set_mempolicy+0x43/0x110 Oct 13 14:58:01 app1 kernel: [12203.098581] [kthreadd+0x0/0x140] kthreadd+0x0/0x140 Oct 13 14:58:01 app1 kernel: [12203.098585] [child_rip+0x0/0x12] child_rip+0x0/0x12 Oct 13 14:58:01 app1 kernel: [12203.098589] Oct 13 14:58:01 app1 kernel: [12203.098591] migration/0 S 0000000000000000 0 3 2 Oct 13 14:58:01 app1 kernel: [12203.098595] ffff810275991ed0 0000000000000046 0000000000000000 0000007000000001 Oct 13 14:58:01 app1 kernel: [12203.098601] 000000000002b572 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:01 app1 kernel: [12203.098606] ffffffff8067d0a0 ffffffff80680c00 ffff81027598b1f0 ffff810275991e9c Oct 13 14:58:01 app1 kernel: [12203.098610] Call Trace: Oct 13 14:58:01 app1 kernel: [12203.098624] [migration_thread+0x0/0x240] migration_thread+0x0/0x240 Oct 13 14:58:01 app1 kernel: [12203.098630] [migration_thread+0x142/0x240] migration_thread+0x142/0x240 Oct 13 14:58:01 app1 kernel: [12203.098636] [migration_thread+0x0/0x240] migration_thread+0x0/0x240 Oct 13 14:58:01 app1 kernel: [12203.098641] [kthread+0x4b/0x80] kthread+0x4b/0x80 Oct 13 14:58:01 app1 kernel: [12203.098645] [child_rip+0xa/0x12] child_rip+0xa/0x12 Oct 13 14:58:01 app1 kernel: [12203.098655] [kthread+0x0/0x80] kthread+0x0/0x80 Oct 13 14:58:01 app1 kernel: [12203.098659] [child_rip+0x0/0x12] child_rip+0x0/0x12 Oct 13 14:58:01 app1 kernel: [12203.098663] Oct 13 14:58:01 app1 kernel: [12203.098664] ksoftirqd/0 S 0000000000000000 0 4 2 Oct 13 14:58:01 app1 kernel: [12203.098669] ffff810275993f00 0000000000000046 0000000000000000 ffffffff80680c00 Oct 13 14:58:01 app1 kernel: [12203.098675] ffffffff8067d0a0 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:01 app1 kernel: [12203.098680] ffffffff8067d0a0 ffffffff80680c00 ffff81027598b9d0 ffff810275993ecc Oct 13 14:58:01 app1 kernel: [12203.098684] Call Trace: Oct 13 14:58:01 app1 kernel: [12203.098697] [ksoftirqd+0x0/0xf0] ksoftirqd+0x0/0xf0 Oct 13 14:58:01 app1 kernel: [12203.098703] [ksoftirqd+0xe5/0xf0] ksoftirqd+0xe5/0xf0 Oct 13 14:58:01 app1 kernel: [12203.098708] [kthread+0x4b/0x80] kthread+0x4b/0x80 Oct 13 14:58:01 app1 kernel: [12203.098713] [child_rip+0xa/0x12] child_rip+0xa/0x12 Oct 13 14:58:01 app1 kernel: [12203.098722] [kthread+0x0/0x80] kthread+0x0/0x80 Oct 13 14:58:01 app1 kernel: [12203.098726] [child_rip+0x0/0x12] child_rip+0x0/0x12 Oct 13 14:58:01 app1 kernel: [12203.098730] Oct 13 14:58:02 app1 kernel: [12203.098731] watchdog/0 S 0000000000000000 0 5 2 Oct 13 14:58:02 app1 kernel: [12203.098736] ffff810275997f00 0000000000000046 0000000000000000 ffff810275994048 Oct 13 14:58:02 app1 kernel: [12203.098741] ffff810275997e60 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:02 app1 kernel: [12203.098745] ffffffff8067d0a0 ffffffff80680c00 ffff810275994230 ffff810275997ecc Oct 13 14:58:02 app1 kernel: [12203.098750] Call Trace: Oct 13 14:58:02 app1 kernel: [12203.098764] [watchdog+0x0/0x60] watchdog+0x0/0x60 Oct 13 14:58:02 app1 kernel: [12203.098769] [watchdog+0x43/0x60] watchdog+0x43/0x60 Oct 13 14:58:02 app1 kernel: [12203.098774] [kthread+0x4b/0x80] kthread+0x4b/0x80 Oct 13 14:58:02 app1 kernel: [12203.098778] [child_rip+0xa/0x12] child_rip+0xa/0x12 Oct 13 14:58:02 app1 kernel: [12203.098788] [kthread+0x0/0x80] kthread+0x0/0x80 Oct 13 14:58:02 app1 kernel: [12203.098792] [child_rip+0x0/0x12] child_rip+0x0/0x12 Oct 13 14:58:02 app1 kernel: [12203.098796] Oct 13 14:58:02 app1 kernel: [12203.098797] migration/1 S 0000000000000001 0 6 2 Oct 13 14:58:02 app1 kernel: [12203.098802] ffff81027599bed0 0000000000000046 000000000002bd72 0000007000000001 Oct 13 14:58:02 app1 kernel: [12203.098807] 000000000000e9d0 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:02 app1 kernel: [12203.098812] ffffffff8067d0a0 ffffffff80680c00 ffff810275994a10 00000000012 Oct 13 14:58:02 app1 kernel: <4142read+>]xff1 000000ffff000 f902]ffffff20d19853hild_hd40]810c00 f050 Oct 13 14:58:02 app1 kernel: [kf]x kthre_rip0/22002 00000 Oct 13 14:58:02 app1 kernel: [1023.03.0940/0/0x12 Oct 13 14:58:02 app1 kernel: <4]x82o[0[f0 Oct 13 14:58:02 app1 kernel: [59a3.0ffffffd1985d_rip+/2f8102a3fff67d12203f082 Oct 13 14:58:02 app1 kernel: 3f[/0x80 Oct 13 14:58:02 app1 kernel: Oct 13 14:58:02 app1 kernel: 0000000004>[17203.<4>420x0/0x4/0x80 Oct 13 14:58:02 app1 kernel: [1< < Oct 13 14:58:02 app1 kernel: <4>[122203.0fffffffe>] at5] ff10fff0a012a>]ff827f7ef[]4.lm fded0 03.0ffff8<4>[4>[1/00/0x24/04>[12[1203004000001fff0Trf.099533] 8]ff80d18atc0fff806ffa08027f023e998>] kth[122>[5 00700fff0c00 7[12203f Oct 13 14:58:02 app1 kernel: e9600082203.0 fff] [cpufreq_userspace:__crc_cpufreq_gov_userspace+0x3e4f29d9/0x43451fe9] chiat ff001ff7d0[1270>] a<0f0r[0+] chilrqd/ f>[180c00680a0x0/e5//04>[.10.1 000 fff ffCff80fffff[0f408] 9b>] 80h[5 00203.10ffff804>[70 Oct 13 14:58:02 app1 kernel: 0f0toremo506a50 ktld_readp S 0f8180680fff08_ti] w5>] wftfxe9.l53e50> chi 2754>[1 ffff Cal_heal>] __fffff [<203.102>b22>e203.10<4>[000c0ffff12209ffff[[12203.1f4]9 1001603.1010000 [ [38] 10120/0x0x0ea/0x<4>>[220000000000[fff0 i0+0x0/00x0/0xtiohreaer_td_rid+0+0000c0 2200 fff9] Ca>>>2x8 wffff80ffffff] cthred_r fff000 fd0a0 [198>fff[] genfffff [<4] [204af] geffffff8[< [158<4>[1df10f[12 00ff8 ff0 Oct 13 14:58:02 app1 kernel: <480ffffff [[10 Oct 13 14:58:02 app1 kernel: <110 Oct 13 14:58:02 app1 kernel: <30f[8d302000000ffff3.5aaffffffffff2] 75.1 [ffffff] k867] ff80cfff0000 Oct 13 14:58:02 app1 kernel: hf3a< Oct 13 14:58:02 app1 kernel: d [] e> pdth_rip+2] /. 200ffff800 ff: Oct 13 14:58:02 app1 kernel: 02059] ] ffff220 0200fff20fff [2121]2r2mf>82[12190>25ffffffff8020258e>] 000000203.102kswad_wak ksw4b/0/0 Oct 13 14:58:02 app1 kernel: <4<4>000006] ffc00 Trx560 Oct 13 14:58:02 app1 kernel: 8r[e01e 22203.110240 000fff2446f [<468.11024>[110x1x80 Oct 13 14:58:02 app1 kernel: [/201202f<4>[12ec2302 [<8] .102203.102510 [fff202 Oct 13 14:58:02 app1 kernel: <000ff ff0 f w105203.10203.20[]506f88>] c0>hil 1] f00 Oct 13 14:58:02 app1 kernel: Oct 13 14:58:02 app1 kernel: f0worker aut800>]e9b>8>]]ild_ 2]000ff8d02030>]785>]fn[+r30h0253e5>] cen102 Oct 13 14:58:02 app1 kernel: ff8a03.1] :1 [[10 Oct 13 14:58:02 app1 kernel: 4>[12/2.lk 00000 03.1fffff[122>[000 0010329038d _0[ad+0xe5/0_wthrr_tx4b/a80 Oct 13 14:58:02 app1 kernel: < Oct 13 14:58:02 app1 kernel: <400000003.ffff80Call 0:20f Oct 13 14:58:02 app1 kernel: 43_025002538>0x0/0x100000 486] ff ffffratasr_tker_t100r1af]0 kthrerip+S c0 3.100 ff] Ca:at0>] wor5497] [03] 801033.101220.103839431 460100 Oct 13 14:58:02 app1 kernel: <274da4adx0[+u4read+0readx4[123.10.10 0000] ff810122590x0eadove_wf00[00fxkthreaip+0 00 0.104f8060ace:evi:lf8025ff] >7>] 98]x5hanod:ff.100460] 3.r[0f00f4] ff4833ff19]70 Oct 13 14:58:02 app1 kernel: 000 ffff/8 Oct 13 14:58:02 app1 kernel: df<6 [][[0000fff20274000c0 00 1 f f :/eiserfff80ff426fffffffffffffff8ff020d1805[12000fffffff1 e Oct 13 14:58:02 app1 kernel: df2203.10x30x1>[1203.51603. [cf0xf105248] [1[12/0x1on+e_loout+owup+0xssk_p>] 351cf0f0800f3_fffff8020100300c0fff03.105er_th a>] 0>] kthrilx4>[122030080 00d f f _02/0xe0 Oct 13 14:58:02 app1 kernel: <4f/x/0xx6hrsi:+04>[5]122 Oct 13 14:58:02 app1 kernel: <4000fff80ffff192>]process_83802c3[x00t.08659] 8] [5683224>[/0x<4>0 Oct 13 14:58:02 app1 kernel: <4+0x199xd<4>[10 0400000[12203.16403.1088+f5dh]03.16>[ 000fff] 4>[12lock_wrle_tim_ rea>tty_ldiscbffff802bd<0c20[0[0 fffffffd0.1ockn_wscwai0x23uncef_wf+0x0 Oct 13 14:58:02 app1 kernel: 2203.106 Oct 13 14:58:02 app1 kernel: [12203.106059[10680c80ce: Oct 13 14:58:02 app1 kernel: 03.106 Oct 13 14:58:02 app1 kernel: < Oct 13 14:58:02 app1 kernel: ] t+f Oct 13 14:58:02 app1 kernel: 73>e30ff12203.106172] 00000000c00 Oct 13 14:58:02 app1 kernel: [1220 ffff8108414ff8028578d>] f32a schedule_timewait_queue+0x233/0x7a0 Oct 13 14:58:02 app1 kernel: <40/0x10 Oct 13 14:58:02 app1 kernel: [1220 Oct 13 14:58:02 app1 kernel: [1226242] [>] system_ca S 00000000c14>f[ff[f/00le_time adeauef2/[12 [[12203.10644312203.106450203.106462] 0ire+0x27/0xbrite+0x6f/0xd0d1at2s02d0f0 Oct 13 14:58:02 app1 kernel: [1806ffa2/0x80 Oct 13 14:58:02 app1 kernel: [12[12.106577] [] chilad+0x0/0x80 Oct 13 14:58:02 app1 kernel: <<400f00f0f00x80 Oct 13 14:58:02 app1 kernel: [12203.1066410dbworker_threaread+0xe5/on+0x0/0x30 Oct 13 14:58:02 app1 kernel: 4>[12203.1066 [ipv6:__crc_inet6_release+0x12db06c/0x12cb4d7d] kthread0x0/000007131ec0 00000ffff803.a10673.1+0x102 x0<+f4a[ff8child_rip+0xa/12203.106797] 6>[12203.1068 ffff810876512203.10681280680c00 Oct 13 14:58:02 app1 kernel: 617d1f0 0000ff80248852] :cpufreq88347] [02506a0>] wor] worker_thread+0x4b/0x80 Oct 13 14:58:02 app1 kernel: <>12203.106890 Oct 13 14:58:02 app1 kernel: [12203.1 Oct 13 14:58:02 app1 kernel: <000f3f3648 [106943] [cpufreq_userspace:__crc_cpufreq_gov_userspace+0x2f4f2a64/0x43451fe9] kth_rip+0xa/0x203.106969] 20>[122008004] Call Trax114>[12203.10107024] [] thread+0x0/0x8x100 0[f[f[0x0/0x110 Oct 13 14:58:02 app1 kernel: [12203[1<4110 Oct 13 14:58:02 app1 kernel: [12202203.10718020253e50>] ktrip+0x0/0x120c53ec0 0000046] 000000000 Oct 13 14:58:02 app1 kernel: 81 8 Oct 13 14:58:02 app1 kernel: 0fer1d+0x0/0x110 Oct 13 14:58:02 app1 kernel: [1224>021] [cpufreq_userspace:__crc_cpufreq_gov_userspace+0x3e4abd57/0x43451fe9] running task ning task n S 00000009b08 000000003]fff0rf7e52+0x1l+l+0x26f/0x380 Oct 13 14:58:02 app1 kernel: >[>[x0/0x10 Oct 13 14:58:02 app1 kernel: 12203.107322203.10732t0f00ffff0 [0 Oct 13 14:58:02 app1 kernel: <41207>[23+0polekM] ff 0 f]get_ff [76] [h0_d>0f07723] [] 001d ffff03.750c88chee_w_qu/0x4>[078022[ait_d_wax8>>1xf3e.108158] 200x4<<4x8.10803.1082fff8020c30823410276015cff689fffffe.a .a81]ffffff80ff12] 0101f1f Oct 13 14:58:02 app1 kernel: [12205>02a>4c1ff8ff8>] 102758[fff804d.108] [[120000 0000 Oct 13 14:58:02 app1 kernel: [8>[1 Oct 13 14:58:02 app1 kernel: [0fx0>[0030000002030003e2>] 6>]_rqup+ht+io/0xbc0 Oct 13 14:58:02 app1 kernel: c37e>nscd1]2ff ff.10synmsg6/x38/0x/<4>[[12003.1ff49094] [2003.10f86 2c2031938109 [5503.03.10957x30 Oct 13 14:58:02 app1 kernel: 1220 Oct 13 14:58:02 app1 kernel: <4on/0xx5a/4de_bbit_w0f[]084sf0 S 0084149667] c0088]695]09715]ff[[1ff81f80420csceaddect+it+0x+0ion+0x_wb4>] __if033/f9_0254469>]805>]02109099800c00 f068race: Oct 13 14:58:02 app1 kernel: xe0 Oct 13 14:58:02 app1 kernel: +0 Oct 13 14:58:02 app1 kernel: [12200x468/0p f]>380x_dgram_s z]f8ffff] 351deqxt_ask0/0c0 Oct 13 14:58:02 app1 kernel: /0x100 Oct 13 14:58:02 app1 kernel: 0x830000000000011ffffff8 f0s84llx0/0x130unctionwaaefauefau2362f80ffff028>[10/0x1ofx1 707ff8068000 ce: Oct 13 14:58:02 app1 kernel: [12203.11>[12203.110365]37[[122] [3.[1244>4>[12<10 Oct 13 14:58:02 app1 kernel: 2f Oct 13 14:58:02 app1 kernel: 9f060 6329 081081fff [< []51cf1pageioc0 Oct 13 14:58:02 app1 kernel: <<4122001 086ff Oct 13 14:58:02 app1 kernel: [ 04f58 Oct 13 14:58:02 app1 kernel: _64>[12203.11092ffffff5f66ff8042c2b8] vfstl+0x7e0100ffff0c00 Oct 13 14:58:02 app1 kernel: 1f011.111fd210f+y0c0 Oct 13 14:58:02 app1 kernel: [12122111110109[1122000ff8f80e: Oct 13 14:58:02 app1 kernel: 122111111[1 >fff00_ffff802362ffffffff[1 0 ff8ffffff03.1n_failex6e/ctionl+0x_task030y1[>f Oct 13 14:58:02 app1 kernel: tltl+0x700c883.111640]ffffff81 Oct 13 14:58:02 app1 kernel: <40x+0x00x10x9d/xbf/0.t .o xa14>[12203.111174fffff8058]000680cffff8e:4>[>[1220xxb7sk_fa4e1o82df>0x22>[03.01 86 ffffffffff2] _itaclt_wa+0airxbf/0+0+0x+0x943o1lf9ts200000000100ff065.11203055062ffffff] do_up_rauet+022/0xe/00000000ac89] f200200 Oct 13 14:58:02 app1 kernel: ff804>]default_wf8f8023_2+fx0f3a462b8d>] d>] vfs_sy00000 000.11ff80fff81: Oct 13 14:58:02 app1 kernel: 0x3e/0xd2l1t 8x134/0xbc94/0xb0 Oct 13 14:58:02 app1 kernel: [122030 Oct 13 14:58:02 app1 kernel: [12203.112125ffffffffffff80202203 1 Oct 13 14:58:02 app1 kernel: <4]0 Oct 13 14:58:02 app1 kernel: 00001]ffffffffff [jbd:__crc_journal_forget+0x4376ea/0x4620a2c] 0f>>.0000fffffff8067d4>[122] itacault_0f Oct 13 14:58:02 app1 kernel: 53f[000fff8ff803afff8fffffff8fffff80ff [1_]xi].t112922]<4>[2765b008068ffffff0lfx6t[4effffffff8[112203f052_24088] [_proxy_pda+0xf63/0x1fffff] e3/0x70 Oct 13 14:58:02 app1 kernel: 325] ffffffffffff802fs__stem_le-k0] f8a Oct 13 14:58:02 app1 kernel: ]f3vt_waitacau f> fu do+0x0x82037] fff] c f4>[ffff810274[14>[122xdion+02 9a00uf2/0xb0 Oct 13 14:58:02 app1 kernel: 0x9a Oct 13 14:58:02 app1 kernel: Oct 13 14:58:02 app1 kernel: 0 Oct 13 14:58:02 app1 kernel: <>[122<0 6353 00 f0680c180 Oct 13 14:58:02 app1 kernel: 0f6l3x1ad0 Oct 13 14:58:02 app1 kernel: [12203.3.113630] [[12203.1137100 [] 02ffffffffffeffb34>] d0f1 20ff0s_ioctl+0ll07.1fff80c4>[3.19] 6] fffff>_wa0xb22[1220339295] [<4251] Oct 13 14:58:02 app1 kernel: 5000ccc285] [c0f80ff8fefdle_re0xb<4>443fff0c3ole810275cd9c88 00ffff8ff0018 vfteee8d>] __f>d_geiococt/0x[120 f81ffffff3.1146down_ftacnction+ioake_u>f1w[1r[xf0xa0 Oct 13 14:58:02 app1 kernel: [/00347 0 630086f3.1100000]204>[x0/0x1o[/o<3e[03.114795<9a Oct 13 14:58:02 app1 kernel: <40f[12203.] Oct 13 14:58:02 app1 kernel: [12 02ff1d0>[1155ffff2203.1[10000000c0fff80f044[0e2vfffffffff try_t__ge dioc_io7e/00000fff0 Oct 13 14:58:02 app1 kernel: 36a11157123] 1122032203.1x500 Oct 13 14:58:02 app1 kernel: <4]ef Oct 13 14:58:02 app1 kernel: 1xp1lf3.115794]0]6 10 ff.11200976t_wwak+0x70 Oct 13 14:58:02 app1 kernel: 03. [ff8] do_peturn+0x_ioctl+05c< 0 0c00 80680ra30x0x10x72207] ff325fd>04>] do22/0x83 Oct 13 14:58:02 app1 kernel: 000001 883.116f10011>]3ctl+0+00xx4>[>[12203.2203116161711] <6[1220fffff15] aa]f3u0036261f25f0351d_pag0x7d/0x Oct 13 14:58:02 app1 kernel: <1632 1080 fff4>[6>] _a5ff8 [3u6c[0f Oct 13 14:58:02 app1 kernel: 20] 001>7e>] kit-cbdc88 4507581] 9] [ffffffff[12203.[12203.1 680701723000ffffffffys S 0f8108 Oct 13 14:58:02 app1 kernel: [1ff8060 ffff Oct 13 14:58:02 app1 kernel: 2_18 e]xd>39feff>]>]o_ad+lt+_red/0xa0 Oct 13 14:58:02 app1 kernel: /0x2cxb083 Oct 13 14:58:02 app1 kernel: <0001000] 680c00 Oct 13 14:58:02 app1 kernel: fe: Oct 13 14:58:02 app1 kernel: <4]ifef.ia[1.11725][<>[1 4a70c00a0] Ca35//0xd0 Oct 13 14:58:02 app1 kernel: ion+0 Oct 13 14:58:02 app1 kernel: <4.18118] [7829] 2<>0od0<36>[122086 81 f6] 020fff03a>] >] _upe2] ff84602c2b8d0>] vfs_2f7e>] 20303f3f[176>] __d] de3>>] 039futx13<4>220 [fff>] it-592203.1fffff806806ll Tr.d8i<[3l1ioe_mm_fau_rtrn0x0/01/0>[1 0 000ffffff03.ctincti73ges+0x9d0 Oct 13 14:58:02 app1 kernel: [xfc0 Oct 13 14:58:02 app1 kernel: <4]+fx8v8lf3.118374] f420ff11] [lt_aio0x4160x11[12203.1184820xxb0 Oct 13 14:58:02 app1 kernel: [10x64>[12218 [] do_sy802bf8fffffy2020888f ffffff45f04fff80f80fffff8fffffff804d6__v0x2ion90 Oct 13 14:58:02 app1 kernel: .118986] [[122022032222.[1x109f/0x10xe/0xcx70 Oct 13 14:58:02 app1 kernel: 80 Oct 13 14:58:02 app1 kernel: ecuiff8812203.14>[1200desr_mo0f2_f2s50e/000000000004600124a1924>[0x30x9/Post+0:awakenfs:r93c5fff9] [0<910f0h19568] af3.0f0a.11dstmeo_frgett_edatamov32>] 0ff800>80f883e35119a0 Oct 13 14:58:02 app1 kernel: <4]o1f0s1ffx190nersd_taf]na0>]fffs_fff12ffffff02203. 99998[<028] [emon+[t040f2: >[1 1 Oct 13 14:58:02 app1 kernel: 00fff ffffffcb6cd [powernow_k8:__mod_license1313+0x1e76ca90/0x20] yu0a10h4>[120x7bx2f/04>[100] [<1220300fffa0 fllit+eafs:ff.12vent1><10:2l]1e1/0x430 Oct 13 14:58:02 app1 kernel: t+0x0xc0 Oct 13 14:58:02 app1 kernel: <487xurgDaeafs:fsild:afs0>fff3.12s876.0.7.ff80ff890].14x1Che4roce_t_queunloopenaf2362<21047] [70her+2 d17020 ff1fff80680 Oct 13 14:58:02 app1 kernel: x190 Oct 13 14:58:02 app1 kernel: <40x0c0 Oct 13 14:58:02 app1 kernel: n+0x0x448hera/0x_l:op20d1020000f0f>[1220] :f8fff Oct 13 14:58:02 app1 kernel: <+0che2 Oct 13 14:58:02 app1 kernel: <40 Oct 13 14:58:02 app1 kernel: 70 Oct 13 14:58:02 app1 kernel: 12203. 000]f80680c00 Oct 13 14:58:02 app1 kernel: 0 fTr/0x11w] remo5452c>] add_waai+0x2it+ke_funcdefau2362k1a8od1+f03/0x100 Oct 13 14:58:02 app1 kernel: 12 ffff19292586 Oct 13 14:58:02 app1 kernel: 0 680 Tra<4>[1x0/02203.1<40x290m.v1[>fx_read+0x5+00c22ffc0[1203.13.1220.[0 sock_c03fff []>] r 7ca249c0030 ffffff804>] releas3e59ff9] [5[s2 f1+f30 Oct 13 14:58:02 app1 kernel: >[1222 6> f8ffffff3.ue_hrtm+0xe Oct 13 14:58:02 app1 kernel: <0x0 Oct 13 14:58:02 app1 kernel: <4.1708717] Oct 13 14:58:02 app1 kernel: 000001806f Oct 13 14:58:02 app1 kernel: tf20 Oct 13 14:58:02 app1 kernel: [14>[4>[12203<4>[.122 000000008f8104>[12efxf4_33ction+0x0/t+0xx80 Oct 13 14:58:02 app1 kernel: 03[fff905]03 fffffffffff12 sc020>ufxf3tf1]0] [<3001]300923015] []230fff203.127f13090 fff4 Oct 13 14:58:02 app1 kernel: ]42f _ +nbd-s37] 00fff52]u_ne+0x0 Oct 13 14:58:02 app1 kernel: 4>[0/0x30/0xde5d/0x170 Oct 13 14:58:02 app1 kernel: add+0x2a[]10f53 system_d f8 Oct 13 14:58:02 app1 kernel: 80ff331/0122 [ >[1220 Oct 13 14:58:02 app1 kernel: <4000003.1233730 f122203f0f Oct 13 14:58:02 app1 kernel: cf/of7d/0xd20cvmsg+red/0xb0x0/ek+0x194>[1<4>0008 000 Oct 13 14:58:02 app1 kernel: ff fCr.0x95/0xdmon+0x5a/0x90 Oct 13 14:58:02 app1 kernel: <4c/0x60 Oct 13 14:58:02 app1 kernel: [1222068] 2357580] [1220/0x15t3_1xf3f[<12322020320 ff22 Oct 13 14:58:02 app1 kernel: <00fffff122o_wime_queuit_qll+0x0x0/0/tion+lte>] 0fdf0t>df22 Oct 13 14:58:02 app1 kernel: [30 Oct 13 14:58:02 app1 kernel: <03.22[00000057] 0007f0u./0x30 Oct 13 14:58:02 app1 kernel: 0x<>x1 Oct 13 14:58:02 app1 kernel: <<42202395 [] trac2200 0 Oct 13 14:58:02 app1 kernel: a 0 f0dfffff802fff80] 4ff808020c3560] tr>[000000cdb8 1]ffffffffff[203.0xeke_utex+0x_nys_f Oct 13 14:58:02 app1 kernel: 00- 08ff f124ul_wdd_ add_wai>] dllwault62f80fff8fffff24920nf22fln Oct 13 14:58:02 app1 kernel: 0x483.] 9] [203..1249942c0ffface:40 Oct 13 14:58:02 app1 kernel: <1212212204>38030 Oct 13 14:58:02 app1 kernel: <]a6k00t2of802 ] d5426002e3 sys_po+00 00000c00 Oct 13 14:58:02 app1 kernel: 00ffffff3/k_sutex_d.n.105hf802c1 [>8023802c4a8bste 000fffff f[05f5i8025452c>ff802c37df>] do_60>] __pollwai_f_funfauld6e>] f803efffff1u>9fc]1n+0x3x18/0 Oct 13 14:58:02 app1 kernel: <2 0000000 Oct 13 14:58:02 app1 kernel: 0 ffffffffffff80468>]_pollwctiofaff8922x10 Oct 13 14:58:02 app1 kernel: 3w1a5/f1uffffffff802c40c9>] ffffffffff8046f102c4661>] system_call+0x705 0 7236 0000000000ffffff806807d0a0 ffffff Trace: Oct 13 14:58:02 app1 kernel: 3.126025] [031] [[12203048 002 <0f a] _f20fnf1 03.12662500ff7d20 te_twait_ququll+0x5+0x2<4>[122+0akedefaufif1s7xf03.1263.12203.100000000000ff12f0i[>[12203.1104>[0/xbx3<4>[12203.68] Oct 13 14:58:02 app1 kernel: 2 6ffff5] 08 [< [[1280c00616 3hf6chan+0x23kiscty] fsx903 Oct 13 14:58:02 app1 kernel: [10 0000080000.127163f791877] [<>470010000000068 ffffTr2203<4>[1qfxf8l].130 Oct 13 14:58:02 app1 kernel: [1x0on+e_au8dp_pe_mm_fa_freturnll+0c00008 003.00 ff80601+fo6x01 0000d83b0.1ff>0/00x1x60[12518524532 [ffffff [[03.12[s]0s1070000ff2] f90f>80803dbpol_fche_paitag+x1ite_stom_lomap_fau>249232n7d02>e[1732000f f000000 Oct 13 14:58:02 app1 kernel: [0tfff9sar0fa280t2xf35.44x0c_ywn0080678845 Oct 13 14:58:02 app1 kernel: Oct 13 14:58:02 app1 kernel: .fn20>xxx0100ff Oct 13 14:58:02 app1 kernel: 0t90ff20oonc4 47323x_0ke ff c2x2x0f41<9.fff313-f f2 6fT0Tsp9ea5<+G]0o+ld>cu>]ox0000f8>2_a23ff010ado10faa6foa__xxlefff5/ux00<<0x0fo f0008>d2>slwwmncf73[] [<802802do_r0x00] Oct 13 14:58:02 app1 kernel: <00080 fff123932220n]8f30>[ Oct 13 14:58:02 app1 kernel: 2ueoo01o0kc51[ bfff5202ffffff fff1ff[7a>] 888<[[[1[30.7790fT<[1[401122f0fkofxc4f5]6411ff0]+0<23000f10xmlto/x1i2+>3.000_0040/cct30f5681770689fx Oct 13 14:58:02 app1 kernel: xt/3f<441382f68 te40ff<11i0313. ff>3 0>[2[oaaaalev+0a b7_eelt0xfku2f6180x00000003f [30/_+0ttdav_x003103 Oct 13 14:58:02 app1 kernel: fc_a0<<] fy 20 re00ff0[[/7x20 6as_t+eu84/_ f8_st>y0fffn05p3110213>>2f f3.22 13>n]2br00[ s 000[0+dfau 1f8f1 Oct 13 14:58:02 app1 kernel: ffc ri2>2e+ae0001033210:2fff008352e]x+00cc50f6.2644x1ad36v7ffc<0 Oct 13 14:58:02 app1 kernel: 31led[130 Oct 13 14:58:02 app1 kernel: 80ff>luad6ff Oct 13 14:58:02 app1 kernel: ]l00 0 012[7.2000/0 Oct 13 14:58:02 app1 kernel: 12fd50ef8ff<<5f623>[0_b2s 100<+c7d:26d Oct 13 14:58:02 app1 kernel: [2068750223630r]+301f34<6002ff9x0 b20084_ix>31068684ff2bff e38]ffdd+nt duf12>>00 7322[0c00ff02>0driee9bt Oct 13 14:58:02 app1 kernel: cf2to3o1_ff 2nnn+uns-a2fc0lff7]/0tn+k02b2f >9c284332>[+ 1p[11f62e_u5b 0epffc 26fff578092.]330f0.:8w2083.8d97 f65702fd4890>0> 0ff>52n4f21uf020ck3a46>s4f]1 wc0016f_2344102<1f40fff0020ff0f2 Oct 13 14:58:02 app1 kernel: 0o020 [201x07e18ax175b4fx[142142217>f00]02 220]10a00]0f/f 7f311212fr0 fbf8832<] 0dm_f88 fff8 >a f0f<_xnkdf2 8506f14[0[t__kdf ff3f106f8f21[<41ff00 3 86f[<1418.14]682>+.b200<4422[14od_vav sb014tt_ffake0io10 Oct 13 14:58:02 app1 kernel: 6.o00ief e03 Oct 13 14:58:02 app1 kernel: 00470o404f1000022e0230[00d_py_kef 266100ff46f25 [ 213f Oct 13 14:58:02 app1 kernel: .[]f313.0 f021a>e _]cff[35585f f3fsr+0 ffr d91tfeea8f .4sf<3[d]0iorsm0 2as>>>luriifxx4>44f4>4c1 Oct 13 14:58:02 app1 kernel: 0+d220014248f9f<07yw_d28<0d2030fs>]dpf2<116[0f0.00 0 c<3.14211d18ye7 65c fu_wri4ix1ra22 Oct 13 14:58:02 app1 kernel: f4ff2l0818822x1] Oct 13 14:58:02 app1 kernel: ae09>_se0 08[0u/01ef961 d[1.50363>eer 1 >7ffff8 0w0x[3014]58te-821 Oct 13 14:58:02 app1 kernel: ]]fff 30 Oct 13 14:58:02 app1 kernel: /0x044e// Oct 13 14:58:02 app1 kernel: 927002006l51caakice70380382254+40044ff84 Oct 13 14:58:02 app1 kernel: >x/xbe Oct 13 14:58:02 app1 kernel: 0ff<1>f.ff<6f028ff] [80fe0f40010 f8]wa0>_/<006<008cf4at >fffff e Oct 13 14:58:02 app1 kernel: 0xb/x<8 86.43f802f0.2[x[0 _>]3>tf0fdd]wau1sbt<1]6 Oct 13 14:58:02 app1 kernel: ff5f82] 8 Oct 13 14:58:02 app1 kernel: f8f30.614811.114[ 00 8< 4e4>0ex0a>0f910 f.cvf2f 20281ffl4a60111002ffff[ff 2<<20[encs00 cd451ff _f30 fTr3. 8f[1f_ 12827 fd>fcf3ef43f3.] .f ee_]02ff]339e_[0 ] 03f2o f5009b78scl]ffd3k1512x61 a0C9exxlit[ ffffa_00f0ffff46ffc wa]f82t >fffff rvtdva f1f001226014ufakx>1005 Oct 13 14:58:02 app1 kernel: 1+<4>+0y0f0:1420ffffs]ff25]4>501ffTd[] [] 10 rbtieso]c002f2232ffo2151616[25 >854]<15 nfur+ou713t0c651115 c0.1f[ f 8f8020 fduf[12015412f4367.0ff [4fffcf<35[[0f[1230f2ffed08 20 05ff.18f T+x1u_26fff82xx15< 0ffcf7f2006 4s0ixvrawa5>sf09q_uux0xnd3 +] f5eadf2avef80]f9411f3f4>0f[ 4> Oct 13 14:58:02 app1 kernel: [. ff18ffffff8888141o] r0f0]8574uuut3[8]ff[ c[ [850 f >f8[540x55rf0[0x0f>>>001]f<16m8545ff<00038 c<2ca>of3.40l l0tiriuaff_2ff aff3_klt]8f11i2820x8067/_y 806so_a]mccda]0x+Sf]x1+e92f90008[535495 f5+.f]3 0]002__i0 Oct 13 14:58:02 app1 kernel: 10no0[+0s>512958 7f59 Oct 13 14:58:02 app1 kernel: 12>2f57] >f172f22cdcf28f 1/160ffd Oct 13 14:58:02 app1 kernel: 203x6+0 Oct 13 14:58:02 app1 kernel: 2f80f561595[[[<40d34tr8w.0>[024>t30un__]8 240.844fffffff]<]31]f4ff b1ffbslt 82f>/03f00 ff2.15fff702cault_+0x+04>[356]15666 [02c0+e00 +/0fc[7f7590]2887 56fff f8-6f>6f[4f0210t_e30a> 522666]dlwu2f_12 Oct 13 14:58:02 app1 kernel: ox<006fe9xde_2+2f57 000ff2oiiiix141xuef[14080 07[<11071220f20xm0v Oct 13 14:58:02 app1 kernel: [230[22848712x/_+4027] f71f[ 1_15201d04010fe:0xi<0<28f>t01 fff8c80 [10 07 Oct 13 14:58:02 app1 kernel: e>.< 58+.>8_p0.8438>[1 Oct 13 14:58:02 app1 kernel: ./+0> Oct 13 14:58:02 app1 kernel: x>620ff02]df02[>....4[f[2_pot-1f_tleioucccccc29]ff64c1ff880ffx<3fffff37[3822ff<5_ al6i 231xuf9 f6C_xx2]fffff]10w00 000]ff 00f1ff> s18f0 ][[00kte>7ls_x/2008fxd0x3f0fff200fff80] l0f4f8:04yual6 333f06.080a3x5c32cffff][< Oct 13 14:58:02 app1 kernel: 69[122fff9<[ 1.fcc Oct 13 14:58:02 app1 kernel: 109c[f6114>+dd2[< mf[f8ca0 Oct 13 14:58:02 app1 kernel: 8ia0ff81001o0<>[2220x/r_ 1 6/<2f222ffffff 1007xatb Oct 13 14:58:02 app1 kernel: f]0c0f Oct 13 14:58:02 app1 kernel: 12390ba>euf>>[x1t/3f0 Oct 13 14:58:02 app1 kernel: 02a>ctx13+ad 4[12 Oct 13 14:58:02 app1 kernel: 854 Oct 13 14:58:02 app1 kernel: lctfu320tianx0f07rsv0x5lac f<3<4ffC_52370[]_xul0f6fffa17 80f<61f023>o9c0<22 0cf4ft08f6f885ff8[18_]us+rs]012f82>f0>060f < 61f23.]]]620 Oct 13 14:58:02 app1 kernel: 0ed1 f0ir>iii_ue002.f_[05fex43 6.0ak f 0[<4000bt>xf6fu2f8xef4fr0x00000ffrsbf8<2352ff6ffffif_pire_pcp06 Oct 13 14:58:02 app1 kernel: wl_>k_x02 Oct 13 14:58:02 app1 kernel: 0164f8.f40n8/ne_]ea8av00411]f 560 u.15 0873>05..3[41/16]f<667325_+ Oct 13 14:58:02 app1 kernel: osf42f.203084.65650o21edf8[0fc2.[f0>]82w.2bf7ff1f Oct 13 14:58:02 app1 kernel: <<8160n0]ff8ff0ff861>f20[0<++42[16>[6ff0.1[m] >t8ax000fffff6xs0/ct_trf88 >0f00f8>]l__2e3d8<27fffal0<1f88 767 9f f]0s]80 Oct 13 14:58:02 app1 kernel: ].> Oct 13 14:58:02 app1 kernel: 00s7] ]0371 [x0a1] 0680211f8ffffle8akal3728flqx0t2ff03[fe2>a]>s0042 fff 7f0unex5s/ cc70f[170o0885/:>ff8 on8d7e10f5_wpid _432885388 0898>1>8.<9wd 0 0 f/04>12<>9 Oct 13 14:58:02 app1 kernel: f03x1w 0.063f7_i0137bte08f02 00f Oct 13 14:58:02 app1 kernel: /.11/nl>f522]422secfl>123 0804 5302/29.f67_x Oct 13 14:58:02 app1 kernel: 00f4e h9783 _ _aa39bf8>]e >0 Oct 13 14:58:02 app1 kernel: [fffff/221__de olad68ax40s_l146<<<2[]264x0f 320f0_queq30wf Oct 13 14:58:02 app1 kernel: 6wfl 0ff1>2<[ff521 Oct 13 14:58:02 app1 kernel: 2f4 Oct 13 14:58:02 app1 kernel: 0n+/000f1 wa 5d]17f>0/21300200f.11x71603[fff2f>]2c23t<_+0 8107 ] ]2 >effcx90x00f15f//i+ufweulf1[5e01fff4f>x10k2>08f11]f6 fff/0010cx002f92 9110c0f8022f89124e/x008.7emm_xu_o_msadaxxd8f[t52f80f0>3106e _ws:f0[02xax90 ff_ef_ f5f850cf12ff804>0>0. ff1sc>a>8 31mv>0 [7][3710 f5_o/[83.<2ff3<00f.0fp01[14719a80[f<40f58o3d<0enad>0ff 0imi+i/nofwltd04ee061c]0f222222d6adl200 eeiu0xu6_0fia ya30a<2nlx13l00 x0a200f41ff854ff]_0 Oct 13 14:58:02 app1 kernel: +_4 003f f20<0ue]3[040440>_ux60xeym[feysux01a[fff84c0f00fn-1220401e2y2] ff f5[2f2f0[fff[ 0n+6//10 Oct 13 14:58:02 app1 kernel: fT4033]]012910 [<[5f0 10c1a<[dftifxodl i2be02f0T2x x0il3ffffff fff10fTfff20 4hn+f5 Oct 13 14:58:02 app1 kernel: 303c[.1 000217<<777176]fffdwep [6335_i5[16ff2d>88f0241ca lx00c08140] c0xune_al/020 fcec37d__ptt_ d8<_>00000031[32//cf12f2000f]5 [fff[f584x[412 >20[ffff80f kau 000200ft30 13000on2fff3 0802]5 3211361 <]se541cc Oct 13 14:58:02 app1 kernel: fua/7 f0rimu_uf70f12>001 Oct 13 14:58:02 app1 kernel: c_23f]<00f91ff f8faes_wa l 0< fdds_5f>va3 6ffd4fa 9541/do3000220xx0_t017000390ta> 170f3 ta<1[2ffdo[][ 450086tdo0>120/fy <00ff fff0000>e yer]80f] dff ff e- 004tc_t]f...][ 8018 88 fff36f f8 Oct 13 14:58:02 app1 kernel: 000022>[_[[[f802]00s4> 0002 fflllllt_cff0.11b.ff0_lx0390x521189 f9seue30k_7f [1fil+030r31 feeeoc0f 1140x Oct 13 14:58:02 app1 kernel: [8ff8]d>]f]8t20digutsy18fffo00f82fff4aff902 Oct 13 14:58:02 app1 kernel: >1f8 Oct 13 14:58:02 app1 kernel: 0.00i]]0802080r5+qc/0+f[[ Oct 13 14:58:02 app1 kernel: 0/80006 0002625pm d02f2218001fff2a_0cfuee9957rdfC Oct 13 14:58:02 app1 kernel: 40f t+cpoffff ff 4fff30ser0f1f8f2<8f22+3 00 0 f[.132x0<3311 1] 8 083.3[33 f4oe20300f.d0 Oct 13 14:58:02 app1 kernel: 400td0a]_scd <4t+>/08270f0] >fec>061f0f 0]000 Oct 13 14:58:02 app1 kernel: 22>8]4x8_<0x/><008.1[oiy2<4 f<528f f[ d/0e0 08000 Oct 13 14:58:02 app1 kernel: />f08r2>002 Oct 13 14:58:02 app1 kernel: i>>[xapo11>>44<.20ff Oct 13 14:58:02 app1 kernel: >]8i46nt]02f 20f710 Oct 13 14:58:02 app1 kernel: ffgfff0.1873 Oct 13 14:58:02 app1 kernel: _ffffffb][f8]tdf_f]bf fcb210ff1he236f]22f]fffdb000 1c0x0032x0uucf312t+0x<4>]10 .f[55<40xffka2+0012>>44>[286663[10x1x_b 660>0f0fx020>+lwescg868 0922>43[[1xf_r8m40c0e44>0/d0x3.9]731 f 7.11x3s0020/t02214/nec2/x80cemie_d/f[<80+und_0>[0301fes_]]8_0un__y0c8ff830t_l82272[yfff80ff0a0< 52] .<_f006<0caf_pll0e]f021.ff8f111[lxx0x54s ff44wc1a m/<400ffc8<.06ve_w_wrd1227] 1 Oct 13 14:58:02 app1 kernel: 000ff00 888555]80s_30>[3.1.188<]] >600 Oct 13 14:58:02 app1 kernel: 6817 2xmf_re+0x2 Oct 13 14:58:02 app1 kernel: ffffffff8880x3203888] 1]f24[/234 000.aow+12]2f060f>n0.12 fa_ox01018f26[ Oct 13 14:58:02 app1 kernel: 0ff83>00<0_a_s5f 70 227ll6_0]<4>1f0106fS 008 ff901 Oct 13 14:58:02 app1 kernel: 8>] ke_0 Oct 13 14:58:02 app1 kernel: 12ffflt_ke_nsff8 .1 afffd>8a40>fui[klw07 ff11 f80fu/41[20900000ffff1] fut+0xd03446aulunc0 Oct 13 14:58:02 app1 kernel: [ Oct 13 14:58:02 app1 kernel: <0c>f Oct 13 14:58:02 app1 kernel: 0f3edyd200>0ff.[ / 586[8 4]0>0f1f36f1[f00tl a5>ff [<<4>xc4fn667e20f6 e_d4f [0xul000018 Oct 13 14:58:02 app1 kernel: oerdvb5b733[1fe1i2712]200ffCtudcffee_d8f2fy00fff24]o_da6.< Oct 13 14:58:02 app1 kernel: ff220 Oct 13 14:58:02 app1 kernel: Oct 13 14:58:02 app1 kernel: 0ff2298203ff3>80]0ff241os2ff8 ri>f1c2f28>0n26 0f8]fffd3d<4xw2f5l0005875f02[0x0s__a Oct 13 14:58:02 app1 kernel: /0f000131[fcffffau722+000 Oct 13 14:58:02 app1 kernel: .7f]]]co>ffff0fff_oe_x3 4f7bf4wrx 389]fc aake>195.40f824uu_abio44 019<401>>120_au]] _ff8.79fbf8 s .6]8e:of80tff6883 docu /ff25f30079d7 ves_er 9]22x250f9+0<4120l3fff3831 Oct 13 14:58:02 app1 kernel: [[ Oct 13 14:58:02 app1 kernel: x>6f49+ea_11c[5ff4aau6f50+esl7f82.22ffff24x0f81[100f118ff32310/x12100f <1<8>2404>1[90f10f9 067.0<+++ce_ub>e 6>8c2]wa_ycax+a+0l65021 ff2yce859f69]96f 1ff<1700af191961[/6 Oct 13 14:58:02 app1 kernel: c3. ]2e2]10>>[92 Oct 13 14:58:02 app1 kernel: 3aroe0f6>0525d] 31>032 00]889]c80[ fc9ff 819< 00e 03 2o0>1]fg80ff94ff<910i_s20e+77f02]ff20>0ffx08.0<31f>]_ >ff28] f30f9 080] f]ock__r0x094f[12fffffff6a092ff6].3903911ff008.2f[991102 214 m097ffedsd>[f9e0 fffffff][2. Oct 13 14:58:02 app1 kernel: a19<6f.0f2080] ><2es_e749/1 019]]]f_lfa0ff.0]070l>1200738t+3ion0x80] 20c3 4100000203.4>0/ 86 f8[8051021102e0]0.2. Oct 13 14:58:02 app1 kernel: 088o28f80 0f1/0ffc00ff02/l+02x803b2002re_r0b5 0033 20 Oct 13 14:58:02 app1 kernel: :eff3x]bx/ 8.01>]>0fwefdcf f 3 Oct 13 14:58:02 app1 kernel: 1 fff] .2000 Oct 13 14:58:02 app1 kernel: c83f83ffff0fft.320c[.3[25sl Oct 13 14:58:02 app1 kernel: .458 ce: Oct 13 14:58:02 app1 kernel: e0 Oct 13 14:58:02 app1 kernel: 2fff60f7[01/203fd3fxp>[1 6500ft23ne 3f5_frto000f2i308112x0of2[0ff0e+lx1] Oct 13 14:58:02 app1 kernel: f2c30 ffffo_x0002a31afpowrdd 9]0ffth.0f ee 82an02>8[04>S:fnwrc+00 002.0[00f42t]2f515f03 f030ccfo+4000fll0x Oct 13 14:58:02 app1 kernel: 235 3>a088f07 0f[fds0 7f[03]00ed8fet00400f0[[4fffffe22480dsd__>20f5d1f 3280x<.20ffffe8+0x[a+0.170C0eutfxntl0[1x+0[f5f1] 4680 u1 fe+0x1 2700c00faxx2200 Oct 13 14:58:02 app1 kernel: [136002e.2054ff828 wad>]53l22000ca0 al Oct 13 14:58:02 app1 kernel: <.34]eefaauakex90e0duead+.203..20ff0 Oct 13 14:58:02 app1 kernel: sf f[5>>>[1+k0x//26reul+toa6f 3fex_30046aff2ff0f>0iteu/<>0 0f8f 2 Oct 13 14:58:02 app1 kernel: 10_cc6c]est8 200g_que7122] ffff800k5ff220f3 Oct 13 14:58:02 app1 kernel: >[409[/0.[< [91]62f01273.0677.20 e68f08/ff[ff 020iaw<20c3e49c61122c53[+6n_wakfunnc+0xx1t>afa3.ds>uuuuu]0fff07f03.1ff[003f[f022<020ff122. Oct 13 14:58:02 app1 kernel: 63]80>]ake_f4>[2037511>] dte/0x9223]810fff0<<<<60200< 36874 f<777ff8]]f[37122251c7e0 ffff:9d[221f_rea47647e0 ff8af0f dd+0x+/0x4> [8f0_fd42f57208 Oct 13 14:58:02 app1 kernel: 000T<>0287 2c680Caf< Oct 13 14:58:02 app1 kernel: ffffa380ff..>u22x05030fffte] fs26003xu> w32>120080>ft.130 Oct 13 14:58:02 app1 kernel: >[12209]2>fc_40ffaftl0000n_au_rbx00f0tl_x00ca_e] f f2 190s_mus100 5 0/os_0i0f[<0<<022f80he42 >xo9]578ffe867.exc/0 d8>] wad0ff02ff8droof20306878a[ 00096788]>f8030ff]1f0 Oct 13 14:58:02 app1 kernel: 10 00228x2>[1076fffffff03e] ddo_0x5>[12203842fff58]] f2 c<4>09 108 _00]804x Oct 13 14:58:02 app1 kernel: cocbf000016c0xe Oct 13 14:58:02 app1 kernel: 2s>7047] ffff3torppad+0<4>8]397f81.2<4>0]aullo> 115>[ [[[5f0]7ff [ff[2f0f25] Oct 13 14:58:02 app1 kernel: a099000xx0o+0 Oct 13 14:58:02 app1 kernel: fn3ff2 Oct 13 14:58:02 app1 kernel: 23 Oct 13 14:58:02 app1 kernel: s_basbee01 Oct 13 14:58:02 app1 kernel: ncee1 Oct 13 14:58:02 app1 kernel: fspa]o drwfx4<0e 4/6k008fllxe Oct 13 14:58:02 app1 kernel: 03r Oct 13 14:58:02 app1 kernel: 4c>>0[6fl21k4b3fd123624220ucf75480l.0.006>.204>673f.[6_200 f283>_uc>f81fe0ys_s0x203.4ff Oct 13 14:58:02 app1 kernel: fitce f0x21 Oct 13 14:58:02 app1 kernel: 623]]20 t>f.]22[1 000f20..7 [fffv206ffi11140x0] 8f99f] 9b_ f] ff005e]2x[5< 8f8s13f2.>xc0aald_wae8001575 Oct 13 14:58:02 app1 kernel: d/ Oct 13 14:58:02 app1 kernel: 0b]120<]20f0f41 290fef4>0 4cu4>/>03 3.1fax01 Oct 13 14:58:02 app1 kernel: 084x+ke_k0efcf23x00cffffs00fff<9_Of ]>+00f82doa02f212144A:2t0s26fff 8f0001ffff8710c] >>] t_wl_ta0 Oct 13 14:58:02 app1 kernel: f-se4fff6lw Oct 13 14:58:02 app1 kernel: tem>x00a8i>odce[80ff56f222 [208fo_f:]33tea3ff08509 ] 85857f830x f0f_ws4c0t]2084290f 374ffd1r ]8 106w200_id+wrd0803[ff2f1221[200f1426] ]f8[001aait_003.7 0 0f09f3[fff40202 [ff0230f71d14>[1300c00 face6cb/069ffvx0009f8opefe28x 0ff[/rr0x02<9f902ln8f044f06 213200fff9_503232.[0f_1003 Oct 13 14:58:02 app1 kernel: [4 2pf 4ftd dpux2c05404<36ef]2fff021f 409/L:fug] 20032f57ff 85oell052107n>stc1xx2<6f7re]0080+dx3f0230] 0c3fus 07d1f [d 2ff312fy f f658ecfffc_0x0e 00ea_ d]dc]37a90a3+idf_fh82be 2>u5r/000<63 Oct 13 14:58:02 app1 kernel: s [f[ Oct 13 14:58:02 app1 kernel: fu] 3[2.<2uld0e60sdc0f.ouea73ff522[220<>>>4>21ffffff10/f<231200f3.5iul003ffx_f_>sm] 690x700 Oct 13 14:58:02 app1 kernel: <]dm-0f0 2 f770./021[]9<6ff302i]peof7ffffffd>4 Oct 13 14:58:02 app1 kernel: 3<4 00802244w Oct 13 14:58:02 app1 kernel: 3 000ai_:[[1<cnd_lor4/0] ffff] sff000[120 Oct 13 14:58:02 app1 kernel: _ ff80 d6/0 Oct 13 14:58:02 app1 kernel: wu6fs44100ff75f[f12l_sr6f0006.t Par44_aaf4ff783>0f_0>f _cvx0if884e2n353]f 82fa>f08fcl000300f68fd0x60sv>e 2.37ff4>fm f7f[f] f0fux Oct 13 14:58:02 app1 kernel: [e2b2fff0 031 fs5] 0 Oct 13 14:58:02 app1 kernel: 1[0fa85xl1.750f80a0 1/n23fCal0[3. [_proxy_pda+0xfef/0x1fffff]k]0_] 8fae5+000f09] 87]1kre78.6fe3030005142.2]0fff803854ffdro1[1224>00002 0d62864>f<.c[11x00<4f070m_cd]413]04//nel0+S60x2ncti/0x 0b12a2e.4>ig+dxbf8+[[673.04>[fffff80nb67b5ebf[1000f8uidxfo1fff <28c11>>24.30a12>< 0.55a Oct 13 14:58:02 app1 kernel: _faoo5f7]s212/fff91>.22f20f0 2]03ffff2287] ead>[tl 6fa6/0>3.2] 02col3f1k0/0210fff20330vt[fs 84f .20[12>[1xs5f8cxeu2441[f0f Oct 13 14:58:02 app1 kernel: >46cf Oct 13 14:58:02 app1 kernel: ]3[f Oct 13 14:58:02 app1 kernel: cckb/00<10u_]e0f<1 310080353e[ 1112< [57bd+0x4>>[10] ff800 Oct 13 14:58:02 app1 kernel: lff 1<00 [8f08ff2c8<0ati_]rrslsts5 fpdequlock4+wa]7[f31 f00fff28ib.2 f][12pen_off]00f1f]31ffff81] 99000 <8f4566721>0] ]]70]37fffff 22310 Oct 13 14:58:02 app1 kernel: f381it f0+ fff02430x0 Oct 13 14:58:02 app1 kernel: 332.f322f822 fv 4fmn+e4>07f8]]]]50] ]]]]]]6].><30f0_r0laax00530o70078f: fmexel023.220c730.< :fd075 80f33fffffff4c4utoimeoinain+0x]> 8ff4>] dp]00oe7800_vtoc]fll0d[0dffdou18fau0823ff>oflff[92<<<<<<5f4580 0f8kcccaaa+euxtir2a> 7d7xr Oct 13 14:58:02 app1 kernel: ] 29]03ff20] f4< [3vt]2f8e>]-69cff8.233.2akemmox70d00x3x380b/04> Oct 13 14:58:02 app1 kernel: <03. 023452a08 2[f443ff40f[13 0fff43 00f8>8]>3f 140[2e0c06 >n39 syse00000fff0> 4f0 Oct 13 14:58:02 app1 kernel: 00308e_wt0xx1>454>[041doux83 00f4[4 Oct 13 14:58:02 app1 kernel: 3333f [fff3cf2fp1n00]635] fd603ef2>a<>[1600080fffr/0x303]>33>t Oct 13 14:58:02 app1 kernel: xx80d01x00ce[>10190fff825]5>a0/x130023<5.472f+2127ff3>]_wafv_0e[96.6 Oct 13 14:58:02 app1 kernel: 0468]802s5cf2f1s>[122497ff 3f8f10ec70f[16 002_tx1i2<3ffc82f2f02533.242s00 d Oct 13 14:58:02 app1 kernel: 3f13 g90f8a+iexf>f<]7902 ff00 7>dcfv0f7ulewa>e2f [ uf711fsf9 726071d>ax83 000ffffffe:] c0>37e Sb4>[6823[10x3_ooxa75al]082ff32nf4<0328280880b836< 010f 6ff44efffffff0x7e0805_qe300eun2ff>0x0e0 fCf4>30cccckeu/[20002224 Oct 13 14:58:02 app1 kernel: 08 [2]823242< Oct 13 14:58:02 app1 kernel: 0 Oct 13 14:58:02 app1 kernel: x00ce30s43]>f23[ Oct 13 14:58:02 app1 kernel: f4f/ff[1c0]fff0f07eff08l_ 8 Oct 13 14:58:02 app1 kernel: [..24.12305f>0ffffff333333fe>94c6 c22ee+0x0082 ff8[1c>[01<4+ Oct 13 14:58:02 app1 kernel: 0012/0+o/0t.[0 [00fe]b.afff2be8 920b51t7]x0486e46]6f.<203f0d/>te0f4ptex002834025>xx_s002>fftime/<4>.2fff23220fb/x007f7140xcnup_xap0ffff1021241] [88000>] nw] ncritevxx00fd+f3ffdi530f Oct 13 14:58:02 app1 kernel: ]y0nwl+dx_e+480f9s]][12w_i4ff<328 4002]72f0d0>07f]f<20] c2b48f0bx04200]f]<[e20000.d57e>ke_x42ex3[16T+psak 1>2]31229[f2ff0 2fffff7777f0]f8321811037kl+000086 fffff3] x954>4440dgcfvf79f8[04f0dde>f<23d0x20826][12fsf3+3002f0r0 Oct 13 14:58:02 app1 kernel: i08<4 80fff0ffff4303c68820d[<4>122[0f2 0 [f3>4207 .3>20fffff]a ecx1412 Oct 13 14:58:02 app1 kernel: 0 x0ff3425f5pe/ 0 f2.f:]0802b30>_r4>[] 08f8_wsf60f2b0>f[_fffffff000 7]f[[0f c203.[ Oct 13 14:58:02 app1 kernel: <4x27c6so 020230 47>8ff<44811] ]hrx2b Oct 13 14:58:02 app1 kernel: 371000806f804ex_w0/rk_trf4]88[12 ] 45 [82]>ff5ffutor4>[0 03e f2f [2bhread3.2 fffa30fffgsix0 f.33]ff620f5[f4koxb.f3655.5 ff5[2oedap ff52f2c_00[022dff051ucidd9d] f7>o 6[330/_2effulu>>es/710f2/oe84f2ff36f300ff48fffd8ef22>3]ffe- f0 _bff7] 2a9.2 2373x402[2 10anadP:[31f [_proxy_pda+0xf7/0x1fffff]rt501227022f06f22[p869xt0 Oct 13 14:58:02 app1 kernel: ><2100fd2e2] [22b3] 27/30008ffa283c[e00k 880f fauwa2bc00a l8>2 4 020c: Oct 13 14:58:02 app1 kernel: 2t>[122] 80s d7cf2.006] 49003fff19]e0.1>>_e4tor_re40d9>22sycil+x0/10 Oct 13 14:58:02 app1 kernel: 1bea002]ff2_f] 81 23lxx0xdd:bx009a0c>pc7179030[0094i>f5ff8] [[cfke_rll05f0r0 etctio118[+f5146000fff68024x2>0 defead/02>[1 3.281]c48ffff0+0x160X3f74+3203 068d0l T>[xd02s]61f:0x Oct 13 14:58:02 app1 kernel: 521x079e100f8xwo10x406 Oct 13 14:58:02 app1 kernel: 38[fi/> 0.50t>danx 7ff0fe]00ff6shc4u k255[<]17f32f 33.27a0:6/[1x1w/fffff[_f4008+uta/f/f2[[0 f0]_080:330< f7>.k22>01147251f ] r+u 76f Oct 13 14:58:02 app1 kernel: 0000584>>]2+t40+kfaf8em30f56] [3.2122 [[1ror+0x44024>[121.252102]f600f[<3.1x0>811.f3.]2. 06e0 Oct 13 14:58:02 app1 kernel: 0 Oct 13 14:58:02 app1 kernel: 03f[].1>fv400 Oct 13 14:58:02 app1 kernel: 03.tai9/0x2a3.2] s0x.2512280c0f2p>4008[1224[dd80ffffacx194>Af.>d0c00 Tr2203.f1fffS07ffffionon+[16 0< >fs:rx:xds:afsomff1500 Oct 13 14:58:02 app1 kernel: 5 400 fff[112x2ff802f8f1f9f8fo_1]/ 8f8r/tf> [ Oct 13 14:58:02 app1 kernel: oC:2f7ff08bo5c0< Oct 13 14:58:02 app1 kernel: <] f ]afa2<80+f<9f2+f]ff8]d_000f>2ue/1+uuuuudeb_000.0catf22 04f90ff[.2f4ffff/< Oct 13 14:58:02 app1 kernel: 2ia0x]fff]f[02>5123 Oct 13 14:58:02 app1 kernel: 805f <598ff eeufynf82[ Oct 13 14:58:02 app1 kernel: d0 Oct 13 14:58:02 app1 kernel: 702ule_uc/0[1] 3f 00eeb792f2>l+7 Oct 13 14:58:02 app1 kernel: 24>e Oct 13 14:58:02 app1 kernel: 221031 825f3l+0_Locs:ae080c00.5n_x9x1990 ff+0/0[824ff028x501c Oct 13 14:58:02 app1 kernel: <4 Oct 13 14:58:02 app1 kernel: <5100<09pena>2b50x5[12 50 80cl Tr0/10x.m88f0 Oct 13 14:58:02 app1 kernel: f20diaf < < Oct 13 14:58:02 app1 kernel: x7e/046 fff80] gf4621dxl13 Oct 13 14:58:02 app1 kernel: 3x_fd ffx25.2 1f]0f9[e0f83dse81f741 [<8df>lln+00xl0o02122f9584]2200c Oct 13 14:58:02 app1 kernel: ]fff]8f40m00ff12xoedlt>8032>120 a9afe5308 4de]fff2f.29f04f620 f 2+3a2 1[f8>4cf3fll+0000000fff10cbfo1]101+kfd >00a0 fC+0x20310/0/0x84<4>260c300000003ff89ff60x126f 00al34131402f1e_x 1869fff850 >] 02030x8f0a0 Oct 13 14:58:02 app1 kernel: ex10fff260em0002 00 ff2he40 Oct 13 14:58:02 app1 kernel: 3]30]80cff61>46ff20280 Oct 13 14:58:02 app1 kernel: >tf1f8s004sx/+dpe74 ff2e04f00ffffmfff20c0000<0e_ [ 6>f2 Oct 13 14:58:02 app1 kernel: 3b s1.f>tx221 < 43.42d200ff<+blt9>0 20f228f834ff.6 fff4fff fff>>ef0f4b5aedob26] f2]d_epofuo0ot6610ff4 Oct 13 14:58:02 app1 kernel: fff42x]uc]08/3 fff212406332223<0/b2f.0a0/0x2>03. f80r_]>f Oct 13 14:58:02 app1 kernel: 9fcl0[ 8ff0cff<[f5syk 0cT//0+te4f8fff1cf1epal ff86>1_23f5fff20]78[3_s0 Oct 13 14:58:02 app1 kernel: f8ff0x40n437 Oct 13 14:58:02 app1 kernel: nr0e>f40 Oct 13 14:58:02 app1 kernel: 000260u>f612f20 014360<0 d]ue3f2to<08oe0f1cff0b4[]1<64>d0 03cu 2b4cultc_cti0xxxabc[1244<[xeld2ff80s S00000080668]0 Oct 13 14:58:02 app1 kernel: .2] 012016>[1fc00/0xd202767 Oct 13 14:58:02 app1 kernel: efau/220] 1220fa]08p8f<4><35<> 00f4820823.<0cctept 286>c0b48v10e10fcf6]61/0rr]f27f:o7d3anotx1012203]03[126 Tr>x+3]3 fauf+0x12 Oct 13 14:58:02 app1 kernel: 37 1 Oct 13 14:58:02 app1 kernel: ff[10ff][fpenanope:o435>]/+e0vg0000100xus04 0 0faef9f2006]okenff.210160f7>12<] 0f2c<[nye480fri9f.0596]cf6032ey Oct 13 14:58:02 app1 kernel: 09cde]f]] ]f0ffc0mdff28f499f[ff.00 c 1xfff01> Oct 13 14:58:02 app1 kernel: 9 8fffCi7f2ca5c_th_+0x <0t0000 25fff0>]_f2f[>fe0x22 590000 f4sf< 0u/nxt_d_0x0df3]8ff3d> Oct 13 14:58:02 app1 kernel: [27686ff[ 0cffec20fo600201 Oct 13 14:58:02 app1 kernel: to_0.2>03ffff> _6002.fkffol0 f130[5f1111/0x Oct 13 14:58:02 app1 kernel: 1ff[ f01_0n440394100 42bc0auteead_rea200_ppef[[nfff 00<022Si:f502080131ff[001f0ttur>732480000cTt2f462e 0f2 u02f70 07[s: 0<< 000f.f] 2908>fff5204>f]82+t+a+00 Oct 13 14:58:02 app1 kernel: [faf1on+0n+0xxta ]x5+dbefa2ie222. 0 Oct 13 14:58:02 app1 kernel: f52>a1tt_io/8] 4200f3th_c_7x5f.2200[4 0f<7n0xsff8e7i01f0 f4>c80< t3r1fff200000d023 :oopen6>fs_[.2 000 .20 >//02 f<4>[270 Oct 13 14:58:02 app1 kernel: x5251ee9]<1fffffall000000f7]7/f[0/t >9bll0b280_0f]>75[1xe+vfnff Oct 13 14:58:02 app1 kernel: 0ff[20e4f0seh0 af020de00c4ua1_ff6]<66>09a+70220c93227 [f308f7>f0ff[<63ff343ff46Ob af2f82 <1412. f [ffff52_po0 Oct 13 14:58:02 app1 kernel: i0m[113 6>c7<4x2[<00]o42fff[f9.0 Oct 13 14:58:02 app1 kernel: f7000072g f Oct 13 14:58:02 app1 kernel: 1i2402f[103[0] 0f]004xc0/422>0884xneosy002ff de/0086f08[ffff521pi]ef0] 928f8226ff2[30dl7ff80a002[232 ff[5]00 024466 00000dd14 f220x30 Oct 13 14:58:02 app1 kernel: 122 0_0 Oct 13 14:58:02 app1 kernel: 22 f>fdf<[3.> 07d0all0nfa:0f<0eu0tycte [0clott/0x1 Oct 13 14:58:02 app1 kernel: 00[8>8ffff2ff82>00 f]1202f 5 f 5700f0fff 2fxf3.2 6ff0]0 y f28 f602rsf3z +886f0f02ff 23 8x60 Oct 13 14:58:02 app1 kernel: 4t>_[31] [02cp_ex83 608fff068190 Oct 13 14:58:02 app1 kernel: ina0 Oct 13 14:58:02 app1 kernel: e..282f03068fa0n]w 3ff2].29 ff81[_to ff2736ff8 38vem2f80[f<4>50_af>062f32+f0000803.<4>ooku0x122fff8023ec3f2a1:f234sfc_ult+0[>0_dl8f_fm_ev_wr+0x0nrr1.0ll Oct 13 14:58:02 app1 kernel: Oct 13 14:58:02 app1 kernel: 12360ff24fe83 Oct 13 14:58:02 app1 kernel: 000ff0a0 Tedf>80 61eean a00808[fc[eioopff831f]5rf20123n ]00>fff.2 Oct 13 14:58:02 app1 kernel: /in]ud.0ffc5/183t_ 8[]0[+0x31722810f842ff3n887s4f]s+e03.f634xlf>]s 0fc40[f2waf0f>e _syl8 f9e6fy+0c6f ff58 003.<8f0082x0 2ffff reax8 0 04] 330i810484>[285f3102< [f0053<5582<44f2>x1i_>22 o220 2fff805kt>7750[122x511089508f2x1Tffffutex33[12.2333303.21220] ] Pag54/.20[12ff068c00fff5ebt donc1//+0_lf8T71>[ [[ .042325f86]5>+x10 0f[0Ap84f[e_sd82008fs___nlwuw0<8x.d_ll7080c22s[0 dxaff>u0d4> ]1b+20]01f88 720c014 Oct 13 14:58:02 app1 kernel: ff.< 0f[twity/o0kec0f88f2f88[[8 ca0[6f0]314]] /20ff4qto0af0_emmt+400 0]d301aps3. Oct 13 14:58:02 app1 kernel: 0f4 Oct 13 14:58:02 app1 kernel: 2a 9ff2 f70]423168828b8f9] 6cf2<7897]28f 7182g<889891[128cf0a2]a02 Oct 13 14:58:02 app1 kernel: >[[5600fl>2203fff80_fu800f0Tmf_>adf f8f/3.70d11bw Oct 13 14:58:02 app1 kernel: e4]03ff t0c4>332+f/t1p 80 f2t0oaesf+78060c00[907 [0>]] dwak85. 220fff068e: Oct 13 14:58:02 app1 kernel: 1321f50610n0o]f[f25cee0 Oct 13 14:58:02 app1 kernel: 0af22204>ab ]]2939>2]1>a] oa>0<00fs0e2+w]]] eb3]>]]v0f>5237cf3]6. Oct 13 14:58:02 app1 kernel: 2Sf0689[ff> ffff e02o_u0vdye_564>[10f[2bf:32ff[<>f0500004601203meox1c3.ff8fff82f]] 0[003ff.f1o el0002f.vdd otoal 8[2>9033.20 f8[1c7f001f04f[43[p 5] f802 _nfo Oct 13 14:58:02 app1 kernel: 08fl<4<40 Oct 13 14:58:02 app1 kernel: m]6ff 0fc28120f08ff28ffff]1x2102 01e2<>4>332[0d2318:o83[..150d42_<43f fffl+/[404u0424219]0312:o98 x6fo Oct 13 14:58:02 app1 kernel: 1 Oct 13 14:58:02 app1 kernel: <<29ffffi08f0 7f7f 3/+0 Oct 13 14:58:02 app1 kernel: 00a>>tis0kfffff>f[ 200 2029500[uei 0f42802]pe_on+>[12<4[03 Oct 13 14:58:02 app1 kernel: 95.0<4rww_ f75n2+e5 8f0f8f6]fnptus+eStueVC+0x0x53/0d/0/0x96963ffff80 _ S 8[fff1 [<524<0ixxum_0 Oct 13 14:58:02 app1 kernel: 044fff53460/0x Oct 13 14:58:02 app1 kernel: <22 [] 0f8ff7e> 104400 Oct 13 14:58:02 app1 kernel: Oct 13 14:58:02 app1 kernel: 1508700fff<2820[2<>9 4f9_tcf0x:4shd83 ff2bc:>ff2x090x 420xteiuff69][c]0ef0x [522s101 flSif8[7+000002] 4>it+0 Oct 13 14:58:02 app1 kernel: f /_tnaf2r]0fd1eu0r2efffff32f0cffp4f02 [1 00>]fffff 0786cff1<192[[0x22839ff8 Oct 13 14:58:02 app1 kernel: f43/fxrs]64_8 00[0[_[985ffffffffff8f8002362cefultaulll+0>[91 0fff8098+0x5/0x><[1030 2tffff88200T944[29 Oct 13 14:58:02 app1 kernel: e__>ff802g40d89>[10f [3b22<< fff0fpf:opedeqa_ligencuric_>] riiflabx2x0x83 Oct 13 14:58:02 app1 kernel: 08ff13xo+erf+.5062c+_o]c] [ <64>262fp13c290t:at1]667f]]3>9fctec30fo00>[11+0x+016/xA3f2 fff32430>0f 3/pxepf2st f0ce:o2f wakeo_ti4>[730030[_proxy_pda+0xe/0x1fffff]ll+ 008fff<4>r]t]00 xf8fa0.+rr>b6_>_92fe>6f .8010_281 0000 sx807>ffae+eefe[0 003.313o42f4fof< f .3030003>[0c:x00 Oct 13 14:58:02 app1 kernel: t>d]2<<4>0fffef0fd2a[[2cf94.2119][ Oct 13 14:58:02 app1 kernel: 070>23.xt19//[900 0f30f70f022ff7]74] 2fd312>3203ok0f12203f] 0ceS 81f+008fff]_d+0llf/0 Oct 13 14:58:02 app1 kernel: 0x 0002ff3]1f0.0ite0tio03.67] ffcal6 000020]2.1tt_wo>f8023 00>f0230c Oct 13 14:58:02 app1 kernel: 220013 Oct 13 14:58:02 app1 kernel: 0<37.303] c_eff0f8f7330]ff80>] do+0 c>ed>_ >8x [<22c4m_48002305<35>[1[20cer19bfff Oct 13 14:58:02 app1 kernel: 2xtwaw ][ff8c40c0e/21/xeefm_c0000108303f4c0] 0x3x2aee/+04>[1ff sy 03.06278] [f0fffffo37ff Oct 13 14:58:02 app1 kernel: [c440 3500f6/47diu>0<<83.3 Oct 13 14:58:02 app1 kernel: f4<3 Oct 13 14:58:02 app1 kernel: 0/taa400 16 f0 00ff 12xxttb8<7l.fff04_eo2[31nd[l0c>2003 6f8 06s <0>7xa>03[f0fdv 30f4dunct6[12 241fff6a32cff 33 0c]0f6racaaeenff]f[13cc80cff81]328e>[<00c0f03.[ex5110084>eecfb0n2020003213 ffff82]9fx] 3]2f3 d_322233[0+_d8393 o8ff4.[rffff4ii8__pocmit0x086ff030f] 340ff062[12309969ffffut0xc03. 1000ff80e:695/6e+01200<40+f] domult Oct 13 14:58:02 app1 kernel: <874 100f8509 [994]0tef02312 Oct 13 14:58:02 app1 kernel: 3f8f220ffa019]0ff01x60__24 044> f61s5ff<>a 2865 0briu088r]a_ud]stmn0x[0100d/ Oct 13 14:58:02 app1 kernel: >0000 Oct 13 14:58:02 app1 kernel: x1x010062[<[f9f>o/0 Oct 13 14:58:02 app1 kernel: 124>20063324302101<41t110 cf0k f0 x0 Oct 13 14:58:02 app1 kernel: 12_wax2122<3023fff>000>fffffue3fff[1.9f>ad0xnx30 Oct 13 14:58:02 app1 kernel: f2][31603[f0r2f8<4 Oct 13 14:58:02 app1 kernel: 23sv_4>[0cT< Oct 13 14:58:02 app1 kernel: 028cc2[ 01f1a8>f1<2e3 Oct 13 14:58:02 app1 kernel: s<31xeabx6l 07iecua_o_]] b02f f258 0680fffe: Oct 13 14:58:02 app1 kernel: Oct 13 14:58:02 app1 kernel: [ff30x1c///-6ra4x Oct 13 14:58:02 app1 kernel: 12 00Cwe_>2fbe392]0220] a76o]0830b8f]fff 233 Oct 13 14:58:02 app1 kernel: 0f[88[0fce.> 0ff03>x<385 [<___a>dff]0<0140f<1>12x4[09002[[1>[23f33 f l 0] fff0t0f 24xc1 0d2 f830xff+0d f81y c08[.3]41 0[1200f8ffff354[15fff1bf03t33820[02f<][ 8f8ff10dc5btule_q0x601[/o]ffff9invll+203[fv3<00ais 83e8f]7ff1 0[1796]] ] ffff]0fxf 8/0x/0xxd04>4>/2s[06ace1.31fff545o_s0x022220] 1edfff8ff3410fa53<[[[[89] 1ffff x 03 646f25ff2fkefaulsync_yms 0feu ueu]a]1]26926][fff313] [.1x9e0ffd1a 4>[81978 0f3fv<5x00e1 ff34_07afff3 00f2]005da6f122wax95<314] io+40 08e.39f[ff.4110803323f006] 201e6fwakux/u>]e <893<4 f]0x23321x8fff0>02ef6r0ae.00fatff0fb30.65[[0sf803s33.320 tr_c5/022[<[6f03e1ve_ret<4>510f80 Oct 13 14:58:02 app1 kernel: <057ff130tem 33okup/e/00x10 Oct 13 14:58:02 app1 kernel: .3f80l+03207 Oct 13 14:58:02 app1 kernel: 2[/0fc0 Oct 13 14:58:02 app1 kernel: 4022>f a02>>xaf i0062 <<221.0ac0]2d_lu_>>62f 3f4/.2. 0f2te]eff[40 Oct 13 14:58:02 app1 kernel: +s_i 1100i8 704f <0c0204ffffff30dfff2f01<2220003 0f<45 Oct 13 14:58:02 app1 kernel: /0xa23+x[122 Oct 13 14:58:02 app1 kernel: 5 202cf2>>>x09/x6 03cu/0x03 Oct 13 14:58:02 app1 kernel: nee2fd12018646 4nsf4>[6f 602[<[1203[cvom5+3003f6645fffnx10xci5a3>[1457 syS 000fff20301e248f8044652cnoti/ofun0tf1t>f47f3f5]ddl00on_]x82 Oct 13 14:58:02 app1 kernel: f328]_p0co_d2 0030020yri0 f[11810>]] scdeq_queu<00tittwaccfa><25f4ffc>ttff3]ff 5cf46 f fff5350x6<4>ffoua-01e0fr4fk04iii+070+1275 00: Oct 13 14:58:02 app1 kernel: ][5>>>>0 Oct 13 14:58:02 app1 kernel: < Oct 13 14:58:02 app1 kernel: 8 f320 Oct 13 14:58:02 app1 kernel: 3f0_08f51208:[5]f923f4f8 Oct 13 14:58:02 app1 kernel: 7]l23.32046] s67/056a3 +esb64abffft002ff0s:a0f[f<23 820 80212[4[xtos0f7]0000ff3n2_01f8] [2>0f.s48f6f64>4x3f c23f0f2p:>7df4+e301005] ffay/08ddb Oct 13 14:58:02 app1 kernel: <>0nc>co8f 0280642>] si__fuosiin46/ Oct 13 14:58:02 app1 kernel: Oct 13 14:58:02 app1 kernel: fc8>ue_own]323[ Oct 13 14:58:02 app1 kernel: 6ffa7ff[672au01n38 > < [9283>[1>0 ff44[2sxnak>f2/01220[f0 [242 db8ffffff220afse_e_Los_lied[97080 Oct 13 14:58:02 app1 kernel: 0fCi__anff7]3066>f882236f0defa 13sst <860[<220 Oct 13 14:58:02 app1 kernel: 0 044/0cS:be802a6002y a2_e8<[0adm600 0cf7ent+xx0_cefaefff8e3ff02333 f608ff9m_7.330 Oct 13 14:58:02 app1 kernel: v7d7308 +kuq[243f900]4 Oct 13 14:58:02 app1 kernel: ff fve3x0f008[ 3pffff01012183.08]affff9ffffff 3[7ff408 31 f310 0ie>61f]. fff4e1le Oct 13 14:58:02 app1 kernel: fcf43[e Oct 13 14:58:02 app1 kernel: 80ff280t] 20F:ff3d+0e Oct 13 14:58:02 app1 kernel: 80f3>_fmw Oct 13 14:58:02 app1 kernel: < 068c0fff Oct 13 14:58:02 app1 kernel: 0+ Oct 13 14:58:02 app1 kernel: 0 Oct 13 14:58:02 app1 kernel: _ f8f 83 88088ebf0f82d87>x+e220730_0xS 533t_ba d5+f223>00f2rff5n cu18n+a+a> [8 01>x0cn0ff]30ff<cf Oct 13 14:58:02 app1 kernel: rtes0fffffdbtx3.f8>[uef0+>8>0aad5esyafcf]830f3032x45f8700:c07f73ff1ff0 Oct 13 14:58:02 app1 kernel: ff4p ff0_oe1ff<5>320no3 6216 083.0.320 Oct 13 14:58:02 app1 kernel: clre[]3.rn40]we+43 fff2] Sf6500e >] sx08 t __us0f>f18ue_e0flreef002fffte40865ff 3f500280]35>001fff5ecv_Scti+f:f8211f7waix1.3359 [78f8 f 025]4 mex34 Oct 13 14:58:02 app1 kernel: < Oct 13 14:58:02 app1 kernel: [02>8026rm 0 1 pl2vyx006c>rd Oct 13 14:58:02 app1 kernel: 68681262/ga1 2203.03. f2203f8000] 8 36530x8ff Oct 13 14:58:02 app1 kernel: 3333388900[3331f3.70]023ad+0x336ff8ff66ff8029fdct0f2>] :>843ffs_w800f0T00tauncn0x34>42] 1f f0472.337f097ri Oct 13 14:58:02 app1 kernel: 10793.<_fute 00f80a0_r6x72700 f737557 [ 4>1000>2203220220222273000]>[120[]xc122] Oct 13 14:58:02 app1 kernel: fffff806949fff8840>n42aff] [sc Oct 13 14:58:02 app1 kernel: c00 0220 [[0.04>[2032 Oct 13 14:58:02 app1 kernel: 338] ath_flx8aa/338fff8022sy189ffffff3.3+0xxxx1x00akf919a4 Oct 13 14:58:02 app1 kernel: 0>3]f8 xele2fse0ff4u>f36f2fo9reassa9203 1 Oct 13 14:58:02 app1 kernel: 00ff ff.33<4>[3202fe1f[020000x660 Oct 13 14:58:02 app1 kernel: 793620>]>] wan+tcaut_ 8+18ff80xb0.33fff2>08491f2 0fff90e69 s 14f ctuof[1] 3.+f22[000ff4>0 >10079a]f 2rulu>s80f44>.120u[y00fff112]ffc38]f3xs1.0213 00x44 1 Oct 13 14:58:02 app1 kernel: 7400+90<21231 0 flimquex0 Oct 13 14:58:02 app1 kernel: ffffff>] x18x1c126 3>f_polttioon/0x<+kef.3420 f80ddfff>f xl]y0fffi3sqwlt+c+n++_2881ffff.34fff6f8>] 133.332] f[1s_p14e2f0f2td202caultultt_writ Oct 13 14:58:02 app1 kernel: <.3.34f/e:80/1]206/eelo] du>e2f00fffde>32afb2f1f[d<004f]8f2911bdef]f] 3 008634.5 f61e570 030f3fyswaittio Oct 13 14:58:02 app1 kernel: .3438]601+00v+0x<00 008 0870022ux_x60 Oct 13 14:58:02 app1 kernel: 34] ff8 00000817] 03.x954>5]0a00fff01e50]ffffff 3 Oct 13 14:58:02 app1 kernel: 6e272768ff xobx0_ax1 Oct 13 14:58:02 app1 kernel: 5ncti/00000080667dra fffff 3860xf< 443f/0<.083c82te5080.fff8 akee_tio10vax8f626ff02 0 01 k+/0486>[2f8320f034f_e0x3xcage 1ft s060f0fl 0ff1o02c]61105>9681b sy/0x03.122f220c0c0034f80254d_0x345 [[4]246 074]2+a2ff425f>f6 [f6f0c>16 4]039 <<0f][8<[fv Oct 13 14:58:02 app1 kernel: _8/4 6f832 0f ef7>f f0f[ff43>[2[030 0740f8f[ 08 f[fffx6<12483<6908 Oct 13 14:58:02 app1 kernel: f Oct 13 14:58:02 app1 kernel: 6x50><0f47c Oct 13 14:58:02 app1 kernel: 4f 43.7322ffebdf20 Tst_4f8 7[0ss 00 01f> 060]f[400] 67432b2563ffda<104f[40f3fe 7ca3 Oct 13 14:58:02 app1 kernel: ]2f_d+/b00 Oct 13 14:58:02 app1 kernel: f3ysh3 86uff8]ff 82/10do6]00438du<0063o>deemo6e ssr1f_ddufe 08h4c ]4[ [0<34f90313]4u0 < Oct 13 14:58:02 app1 kernel: 2<108ff32o9f40 Oct 13 14:58:02 app1 kernel: 8 te92bf4f493eSf1t4><3 00.d0 Oct 13 14:58:02 app1 kernel: .54fff_pota3f]00otorm_se7e 406f0>072>00al Txc_[4e99ffdae18fffff] sk5ffffdit_u]b]100ff6<4>12122300:0fec9pene] fst<4>3064>fe>o7ff Oct 13 14:58:02 app1 kernel: t100.6ffs>62c0>] c062db_wrlf fffa4>03.03.353..34>[d4>[150 ]]70]1[12[098 [3c>a 0ff1rx203.><4>[124>[46]fffit2c/11703000c Oct 13 14:58:02 app1 kernel: <0opf30l6 fff.fs_t__osk:08fp5f00 Oct 13 14:58:02 app1 kernel: ns:a_fs:717] :o50Snt5xm0x8e0x4>[ [<0390 f1<33.350 Oct 13 14:58:02 app1 kernel: <40xc1:0 33]12>000ff1220<4>[ff80cf:ff2b9 f<4<3]084>[] 802fs_+ Oct 13 14:58:02 app1 kernel: 0ff0c03.[ff8680203ff1785 222/110f1220ff80ckeb4 814c<2ef802]aulh+04<4>3492657800 34a800sys_ag0 8 Oct 13 14:58:02 app1 kernel: [122d0 Oct 13 14:58:02 app1 kernel: .fffk3 87f++Ws:ap803_plin3/313f0]49]5405f0c3td 5eb408 Oct 13 14:58:02 app1 kernel: eb41cfwax1ti83 Oct 13 14:58:02 app1 kernel: 01f[7.f003dc_ke9 >fff202]]___lo+i2_44 Oct 13 14:58:02 app1 kernel: <][1206c00f<4[5.ffff [<241wal+00000006f000:af2fff b Oct 13 14:58:02 app1 kernel: fff] d Oct 13 14:58:02 app1 kernel: 100000fffra [<4] [<3.3[0806x95.35[<426d40ff500f561c9f0 Oct 13 14:58:02 app1 kernel: <086rs ]:_x[12][330c0ff8752001f_m] ss70ff0 Oct 13 14:58:02 app1 kernel: 3.33503..0eefrif0<4>3 ff8f8060635642ff8rue+0>088f2cf]<4>[b/0+00x1xAaf7>sfdtb/03 804_c0b0f80lwake+ Oct 13 14:58:02 app1 kernel: .35 [cpufreq_ondemand:__crc_cpufreq_gov_ondemand+0x13cc02c/0x7615ed9d]x0005] 2202>+0463k_ne0[1267] 8<37< Oct 13 14:58:02 app1 kernel: 6fffff<4> 330f303. fff4d_daim_>> 9242800357 [8842f5e:f130xb1>581ff8d 00000058248up_<4> Oct 13 14:58:02 app1 kernel: 0 08e60][12f]0f.3_ Oct 13 14:58:02 app1 kernel: 1>[+snf531fkc4.3f]i1ff[4tokpda] k_sx/12100fefa4]gaxl+0xx001f1c300000.35>[1e_tste12ff83 [f [f0f0073 >[aflt_s f3f8220301>]e_7/0019800e0uexx03affff0]o12207e3680c[125] f8020cd-9d459700 Oct 13 14:58:02 app1 kernel: 235975ff f7508190 Oct 13 14:58:02 app1 kernel: [] on+3 f4959935e1a31cbff8fffffffff[22 [<1cfwakd+>[fffdrof36133cf1t+00000008>d0_/21ed_r<4>[1 020oo5677][166803_won+0x685 Oct 13 14:58:02 app1 kernel: 0f4>>c332 1f_5220 Oct 13 14:58:02 app1 kernel: ffffff06825]ff8efall000000fff80l 4>[179] rdatunc Oct 13 14:58:02 app1 kernel: x148/0 Oct 13 14:58:02 app1 kernel: 7[4>[12204909 00ffff8119[[fff30884c38236f>:rrx_F_Crx110c0 Oct 13 14:58:02 app1 kernel: 270<> Oct 13 14:58:02 app1 kernel: 80b2fdx83 0ffffff62603.em_000ff83612meo0xbfff3e5autc_c_srb> t37]2waitiox00 2 0ffffffrac3.3ffwakcal0000f8003.3<42033] 2ffff f330034 [fff7] 067144314 Oct 13 14:58:02 app1 kernel: p_r0xc82fff363] 36<4>371dim+0x0 Oct 13 14:58:02 app1 kernel: 43362410xx7ad403.ffffd-s043f362204> e470a_fv[k3[f8020crve044] 03.4495>ne20 Oct 13 14:58:02 app1 kernel: 38] >] comxd_d+/80830aa83 Oct 13 14:58:02 app1 kernel: 0ffffff3984>[03. [<94_wa67d0x3<4 260] a90 Oct 13 14:58:02 app1 kernel: 3fffo0a801de1o 08 _tid+022208] ] ] sockead12.364ffs_r000800f80431/0x426950209 3fe6022]wak00086003120600 Oct 13 14:58:02 app1 kernel: <647 0000 ffff3.3fffc0>te000001000>] km_0000028ff8f21e.0x[s_:afsuct Oct 13 14:58:02 app1 kernel: <364] ff22000000802dff9ffffff88[4aff2 Oct 13 14:58:02 app1 kernel: c f].3653578dff8a91578ee_locnalt_tailagi>] teri.3662 Oct 13 14:58:02 app1 kernel: ffC/0<7042f09l] 6593 [3.>[140 Oct 13 14:58:02 app1 kernel: 0xx+0658fff0c3 81ff b[000ff86dd[em028102f80612si_t:e0134xpefp3 000 0 ffl T4>[[1220000f0cxea8 0x3st0802596]2dbile/0x[0]0f4_<>]d/0/0xxlus0x9[12802_gr0x7 02800 a0 T0330x4>[133367ffffcs ff 6_5_c9ope] :2_fix1d>[1fff] sfff751224>]+0xx3 Oct 13 14:58:02 app1 kernel: 04fffracxed0x00tsfi]gs e803]6783122<4>76]199rit/06794>[000060>[3 ffffea3f03.386[ff4ef 8ffs2>] :3fffile/0x [ff8epff880030 f80 ffff80arck_s:ao 0d1d>es660 <20c 2368c00fff:op0>] :oafs3>]td/22098000 Oct 13 14:58:02 app1 kernel: fff8 0 628_n1f0r:a0 Oct 13 14:58:02 app1 kernel: 220 f80>] S 00000 ff887pSiuncee1a1c20689vfit+83 Oct 13 14:58:02 app1 kernel: 003f[640:/1_147fffc 67275]179 Oct 13 14:58:02 app1 kernel: _toex_0xx10/0xf0223.303.fffff8802s83ffffff2000xfff802cff803.0c0b7e>] m_fee+0xep+n+1c203f] s 0000203.3 lts00f66o+3 fi37/4 0f81806f80 Oct 13 14:58:02 app1 kernel: 19012] 02800] c29ll+020000068f0sd7f>21rff3h0x1203.05eb6800 f[123.31220323]fffff203]0x700000ffd0a Tra8]08903.]21shs0ilf80f3<8] 7.37111371d1>_ex0x14>[ Oct 13 14:58:02 app1 kernel: 20000c061[uloupg+0220>[14>[1xx0x4[106f8>wakelaf_Wr_Us:a hre0x1ush+01 0f] aff3ceL/f3720fagtr/fi_Slo:af0x30 Oct 13 14:58:02 app1 kernel: ffc>]_ca00000 ff ff0re>0 Oct 13 14:58:02 app1 kernel: 46 ff C/0x3ekaf].70322222039] f3103738d Oct 13 14:58:02 app1 kernel: fff8] 80895390ddck_oopelie+01/046[124f90f1]f8f802fff6244>[<4>_fai_SakeAfspenil<43] 122203068da2ff0.41]p]f]rf[] fia:opauleblSleObtnuxe+ Oct 13 14:58:02 app1 kernel: [ff8 s00000ffffffacex281eraf7>/me a1fslonux+x1b203[12.37] 7]63503pf ]frfedv_u190 [74655497]4>[00039728fa+0x220.37] 0x7000fa.fff<]34.f8eadtion Oct 13 14:58:02 app1 kernel: 3 00 c00 ff.3fffe02884ff428 [50]ages_lose22 86>d12 Oct 13 14:58:02 app1 kernel: xf<6>1220ff80680122ff8ffffff6efffc29cal0000ff8ad+ Oct 13 14:58:02 app1 kernel: <320800][f7773>[12>>[1<4>203[1222] 0] ffff :enamisee0x1_l 1< fff<4>71]6.37x70<4>1220x1/0x7683f :o55eos20>[13f81ff595] []7ut]f72 42f41a0b>]0f7>64>tas0xa Oct 13 14:58:02 app1 kernel: 376fff] s_ox7e000 fff8]nt03.3.3.37.37coff 0.. f[12 [< 3.3769 Oct 13 14:58:02 app1 kernel: 0 Oct 13 14:58:02 app1 kernel: fff88c38def :pe_RegetchS50<4>>[12.213403 06703x0/0x>[1fff>] >[1202000068ffe: Oct 13 14:58:02 app1 kernel: x] 0x720384f80cff4>[40 Oct 13 14:58:02 app1 kernel: 7836] Pr0 Oct 13 14:58:02 app1 kernel: 9/us+0as>]f5n8[+31]walkx Oct 13 14:58:02 app1 kernel: ] 20c000000fb478>[1pennafuoc+x2e61/570x16Sp83f/ief+090] +0x4>[fff] s S 7c8>[1ff4f [] 1/07x169_e3e70sa40ffr797 [f8029>]_fd.37 [f80ca000ffffffffalx9/0on+12>[1t+0xtr] f44_f13f2 [fff8f79wal/0x [ff8yst00008ffffff80er/0x<4>] 96]<4>00aXAf]0ys8ae[2b7>]pat1a9<4>fff48dr_4>[4 0000080122 0798042effff100x_2 37]i_0884302b1b>ath122119fff _0x5812 20 06 ff2[1bd0bb52l0f Oct 13 14:58:02 app1 kernel: enafena3>]1>]9>]1a>a3>ennc11fe<44>[4>[4>4>4>[4a6dfs_misalk Oct 13 14:58:02 app1 kernel: 1202.3 ffl ef>]2 [cpufreq_userspace:__crc_cpufreq_gov_userspace+0x3bfae3c9/0x43451fe9]3f888025>]bbinpens:assix16 Oct 13 14:58:02 app1 kernel: <. [f[1122203 [12222038384.381181280 :o bd>_us+0ath+ollku__tra20f] Ca_wax0/0x42201/0/0xx16x19St+00/04>[><4846x370x1>sx+0l+ktsr[38fffce:2x100x8x10eepx_Wpu+0xhStnn14f0/10 Oct 13 14:58:02 app1 kernel: .3 [fff]8220es_ib0 fvfs8103306819dff8e>0>] :oafsrxb716>enope:fffpeafsnque]e283 Oct 13 14:58:02 app1 kernel: 02f<2fff9>] 00000045206755]_enee Oct 13 14:58:02 app1 kernel: <45c061/xb0500 Oct 13 14:58:02 app1 kernel: 1b0 Oct 13 14:58:02 app1 kernel: tux2218bb/050m_t330x_b_nffff80_ca00086 c00fffTra+02800x10 Oct 13 14:58:02 app1 kernel: 10x7<4>8] .38>[1>038mef>dpr3x[3.30338] 03.735fffff13]]3143ff0>rore/ 0 0ffff3foc080Esf2x_0>[xe5nafs_ainu0 Oct 13 14:58:02 app1 kernel: 12861 [3bt_f27/22ffd-t5b7c00 ff[12ca:ffxeadf0 f 89770 Oct 13 14:58:02 app1 kernel: x42n+04>[20373]ff_wad+04>[_proxy_pda+0xd/0x1fffff] 447c833] Oct 13 14:58:02 app1 kernel: <>6f8fv:]fb3f0fff [<0 Oct 13 14:58:02 app1 kernel: Oct 13 14:58:02 app1 kernel: /0x [[1tessc4/ion389] fff802wa70 Oct 13 14:58:02 app1 kernel: 1 ] s00006706781]ex_x_rpe0 Oct 13 14:58:02 app1 kernel: 0][fffvfs5[1220000c09 8f[_proxy_pda+0xd/0x1fffff]th_lk01225>] [122] 1 Oct 13 14:58:02 app1 kernel: a01:f[82to0/0xf0/0lIsPafsfs:enaenaafiss/0x00 Oct 13 14:58:02 app1 kernel: f80vfs27/ [20cd-tr0fff[c+ee38f>03.[122<4>x0/0x0 Oct 13 14:58:02 app1 kernel: .30x3<4>6/04>[.920_reesss+066/1223937] ff8>]t_[12 [7 g000f8103.<3f [0co8 0 <435flinha9/ Oct 13 14:58:02 app1 kernel: 9375ee_usx9078[1200006f>[2209 Oct 13 14:58:02 app1 kernel: 921<4> Oct 13 14:58:02 app1 kernel: 2+eenf3xwn > k_pa_+0x3.3 [[00f8fff16]]ameb/04>[] ff s000000ffffface9/0xxcWrn3 Oct 13 14:58:02 app1 kernel: fff0_enr+0x3val_Ac+0x>[10xe03 [<22b_us+003fff 000 fffffndf9800+_7Gl/open]pa0x4>[ [f8 s_us0x39557.30000f]ana8/Pff3bs120/0e4/0x/00 Oct 13 14:58:02 app1 kernel: 62220301ffffffd70 Oct 13 14:58:02 app1 kernel: 204000 9[f2 Oct 13 14:58:02 app1 kernel: 0235b>] e30f88>] 3cc fff8] fffc0rth220..398but_x0/3 61d 3/Ps323ffff3] [13/0>[139ff9>]+0x0] fff10970b750 Oct 13 14:58:02 app1 kernel: a3lexff88ff>] e383ef8ff12212.3978 f80cffc8b70]f00f0e450>1/xb Oct 13 14:58:02 app1 kernel: [ Oct 13 14:58:02 app1 kernel: 220<4203.220220ook+kpffatl 00afsafs_rxirxirxirx_xdrxdrRXkafs_tssBpatrry_4/0six160[2988991900co4>[+0xb/0+_ces_Iafsx_dopepenafon++0x0 Oct 13 14:58:02 app1 kernel: 202c_ls203] f802f] ff8r_w0x2 Oct 13 14:58:02 app1 kernel: <]220638[4>fbhxa13_bff212b04f] tsei004fC_ Oct 13 14:58:02 app1 kernel: e>4fp2 []x5+ar sc758a/[.40fff] _4>[2161 Oct 13 14:58:02 app1 kernel: ff800 f12207] fffffffff401 20S_e0xc.1sufff2847d80f]714[1_R:f4fff20 Oct 13 14:58:02 app1 kernel: O[212247] 3b>sta220] 020fs58ffff>[195pe_wallos:rnaf]f<80/]f7f]f.2f0] 030 1+cd_waf>]58f6owefbf3rffffftem000000680a0 ll ter/0<4>50 Oct 13 14:58:02 app1 kernel: 1/0b0 Oct 13 14:58:02 app1 kernel: 4x1b0x11_f:f2is:f .22[00f80c42ff1b0 Oct 13 14:58:02 app1 kernel: s+00x1on4>[ Oct 13 14:58:02 app1 kernel: x0/elltsy_rafs:ax_0/0>[1.405] b>_000f2nif+rfsce0]3.2<44404]ff8s_lx2797]f80sd-f8521122810c3fa:rxWrii_S>] n1f312. 620[6.44eleff8bR589[0[[64_newl<4> Oct 13 14:58:02 app1 kernel: <122[12f8c2a [72xk_g>71 0 ff.o 0>ft_u44 08c.>4s62ao3f:[202o32ssta/220122.403.40c0 fffffff62c2b3efop2b7>] 9>]8841f4 Oct 13 14:58:02 app1 kernel: a9>a222<30x33f2[>1oh1f032:>f+f.410h_0/>46] 1f][ ef01[410 [<48it+x83 00fff0684>[3.4f0.xe9631fe5o3/f l _s]e001d41<1+_A9f f[12203.412452] [] :openafs:rxi_ReaKeepAlive4]] en_8+afxfxselink_path_walk+0x87/0xe90 Oct 13 14:58:02 app1 kernel: <420.:.f._415520] [do_path_lookup+0x8a/0x250]0f][]n_802b8b1c>] vfs_lstat_fd+0x2c/0x70 Oct 13 14:58:02 app1 kernel: [12203.416019] [sys_newlstat+0x27/0x50] sys_newlstat+0x27/0x50 Oct 13 14:58:02 app1 kernel: [12203.416024] [ipv6:__put_user_4+0x20/0x30] __put_user_4+0x20/0x30 Oct 13 14:58:02 app1 kernel: [12203.416030] [error_exit+0x0/0x51] error_exit+0x0/0x51 Oct 13 14:58:02 app1 kernel: [12203.416035] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:02 app1 kernel: [12203.416043] Oct 13 14:58:02 app1 kernel: [12203.416046] gvfsd-trash S 0000000000000003 0 20881 1 Oct 13 14:58:02 app1 kernel: [12203.416049] ffff810674d877c8 0000000000000086 ffff810674d87728 0000000000000000 Oct 13 14:58:02 app1 kernel: [12203.416053] ffff8104481b8000 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:02 app1 kernel: [12203.416056] ffffffff8067d0a0 ffffffff80680c00 ffff81061f9d0a10 ffffc20000000000 Oct 13 14:58:02 app1 kernel: [12203.416060] Call Trace: Oct 13 14:58:02 app1 kernel: [12203.416083] [] :openafs:afs_mutex_enter+0x9/0x40 Oct 13 14:58:02 app1 kernel: [12203.416108] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:02 app1 kernel: [12203.416114] [] default_wake_function+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.416136] [] :openafs:rxi_ReadProc+0xdf/0x450 Oct 13 14:58:02 app1 kernel: [12203.416157] [] :openafs:rxi_WriteProc+0x2ef/0x3c0 Oct 13 14:58:02 app1 kernel: [12203.416177] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:02 app1 kernel: [12203.416200] [] :openafs:rx_ReadProc32+0x57/0xb0 Oct 13 14:58:02 app1 kernel: [12203.416219] [] :openafs:xdrrx_getint32+0x16/0x40 Oct 13 14:58:02 app1 kernel: [12203.416239] [] :openafs:xdr_AFSFetchStatus+0x19/0x1b0 Oct 13 14:58:02 app1 kernel: [12203.416258] [] :openafs:RXAFS_FetchStatus+0x1bb/0x220 Oct 13 14:58:02 app1 kernel: [12203.416263] [try_to_wake_up+0x66/0x3c0] try_to_wake_up+0x66/0x3c0 Oct 13 14:58:02 app1 kernel: [12203.416283] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:02 app1 kernel: [12203.416302] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:02 app1 kernel: [12203.416310] [enqueue_task_fair+0x38/0x50] enqueue_task_fair+0x38/0x50 Oct 13 14:58:02 app1 kernel: [12203.416324] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:02 app1 kernel: [12203.416328] [enqueue_task+0x13/0x30] enqueue_task+0x13/0x30 Oct 13 14:58:02 app1 kernel: [12203.416348] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:02 app1 kernel: [12203.416351] [enqueue_entity+0x37/0x70] enqueue_entity+0x37/0x70 Oct 13 14:58:02 app1 kernel: [12203.416357] [enqueue_task_fair+0x38/0x50] enqueue_task_fair+0x38/0x50 Oct 13 14:58:02 app1 kernel: [12203.416360] [__rmqueue+0x2f/0x240] __rmqueue+0x2f/0x240 Oct 13 14:58:02 app1 kernel: [12203.416364] [enqueue_task+0x13/0x30] enqueue_task+0x13/0x30 Oct 13 14:58:02 app1 kernel: [12203.416382] [] :openafs:afs_linux_dentry_revalidate+0x2f3/0x370 Oct 13 14:58:02 app1 kernel: [12203.416401] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:02 app1 kernel: [12203.416405] [try_to_wake_up+0x66/0x3c0] try_to_wake_up+0x66/0x3c0 Oct 13 14:58:02 app1 kernel: [12203.416425] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:02 app1 kernel: [12203.416449] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:02 app1 kernel: [12203.416455] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:02 app1 kernel: [12203.416461] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:02 app1 kernel: [12203.416470] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:02 app1 kernel: [12203.416484] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:02 app1 kernel: [12203.416487] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:02 app1 kernel: [12203.416492] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:02 app1 kernel: [12203.416497] [vfs_lstat_fd+0x2c/0x70] vfs_lstat_fd+0x2c/0x70 Oct 13 14:58:02 app1 kernel: [12203.416508] [sys_newlstat+0x27/0x50] sys_newlstat+0x27/0x50 Oct 13 14:58:02 app1 kernel: [12203.416513] [ipv6:__put_user_4+0x20/0x30] __put_user_4+0x20/0x30 Oct 13 14:58:02 app1 kernel: [12203.416518] [error_exit+0x0/0x51] error_exit+0x0/0x51 Oct 13 14:58:02 app1 kernel: [12203.416523] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:02 app1 kernel: [12203.416531] Oct 13 14:58:02 app1 kernel: [12203.416533] gvfsd-trash S 0000000000000000 0 20883 1 Oct 13 14:58:02 app1 kernel: [12203.416536] ffff8103fccdd7b8 0000000000000086 0000000000000000 ffff8103fccdd7d0 Oct 13 14:58:02 app1 kernel: [12203.416540] ffffffff8046f130 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:02 app1 kernel: [12203.416544] ffffffff8067d0a0 ffffffff80680c00 ffff810448194a10 ffff8103fccdd784 Oct 13 14:58:02 app1 kernel: [12203.416547] Call Trace: Oct 13 14:58:02 app1 kernel: [12203.416551] [thread_return+0x3a/0x59a] thread_return+0x3a/0x59a Oct 13 14:58:02 app1 kernel: [12203.416561] [try_to_wake_up+0x66/0x3c0] try_to_wake_up+0x66/0x3c0 Oct 13 14:58:02 app1 kernel: [12203.416583] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:02 app1 kernel: [12203.416589] [] default_wake_function+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.416612] [] :openafs:rxi_AllocSendPacket+0x83/0x170 Oct 13 14:58:02 app1 kernel: [12203.416633] [] :openafs:rxi_WriteProc+0x103/0x3c0 Oct 13 14:58:02 app1 kernel: [12203.416655] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:02 app1 kernel: [12203.416677] [] :openafs:rx_WriteProc32+0x59/0xb0 Oct 13 14:58:02 app1 kernel: [12203.416698] [] :openafs:xdrrx_putint32+0x1a/0x30 Oct 13 14:58:02 app1 kernel: [12203.416718] [] :openafs:afs_xdr_int+0x23/0x70 Oct 13 14:58:02 app1 kernel: [12203.416737] [] :openafs:RXAFS_FetchStatus+0x71/0x220 Oct 13 14:58:02 app1 kernel: [12203.416759] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:02 app1 kernel: [12203.416778] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:02 app1 kernel: [12203.416792] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.416810] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:02 app1 kernel: [12203.416832] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:02 app1 kernel: [12203.416839] [enqueue_task+0x13/0x30] enqueue_task+0x13/0x30 Oct 13 14:58:02 app1 kernel: [12203.416857] [] :openafs:afs_linux_dentry_revalidate+0x2f3/0x370 Oct 13 14:58:02 app1 kernel: [12203.416876] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:02 app1 kernel: [12203.416897] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:02 app1 kernel: [12203.416921] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:02 app1 kernel: [12203.416927] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:02 app1 kernel: [12203.416933] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:02 app1 kernel: [12203.416942] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:02 app1 kernel: [12203.416955] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:02 app1 kernel: [12203.416959] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:02 app1 kernel: [12203.416964] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:02 app1 kernel: [12203.416969] [vfs_lstat_fd+0x2c/0x70] vfs_lstat_fd+0x2c/0x70 Oct 13 14:58:02 app1 kernel: [12203.416980] [sys_newlstat+0x27/0x50] sys_newlstat+0x27/0x50 Oct 13 14:58:02 app1 kernel: [12203.416984] [ipv6:__put_user_4+0x20/0x30] __put_user_4+0x20/0x30 Oct 13 14:58:02 app1 kernel: [12203.416990] [error_exit+0x0/0x51] error_exit+0x0/0x51 Oct 13 14:58:02 app1 kernel: [12203.416995] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:02 app1 kernel: [12203.417003] Oct 13 14:58:02 app1 kernel: [12203.417004] gvfsd-trash S 0000000000000005 0 20892 1 Oct 13 14:58:02 app1 kernel: [12203.417007] ffff8104724b97c8 0000000000000086 ffff8104724b9728 0000000000000000 Oct 13 14:58:02 app1 kernel: [12203.417011] ffff810426db6a00 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:02 app1 kernel: [12203.417015] ffffffff8067d0a0 ffffffff80680c00 ffff8103fc92c230 ffffc20000000000 Oct 13 14:58:02 app1 kernel: [12203.417019] Call Trace: Oct 13 14:58:02 app1 kernel: [12203.417042] [] :openafs:afs_mutex_enter+0x9/0x40 Oct 13 14:58:02 app1 kernel: [12203.417067] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:02 app1 kernel: [12203.417073] [] default_wake_function+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.417095] [] :openafs:rxi_ReadProc+0xdf/0x450 Oct 13 14:58:02 app1 kernel: [12203.417116] [] :openafs:rxi_WriteProc+0x2ef/0x3c0 Oct 13 14:58:02 app1 kernel: [12203.417137] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:02 app1 kernel: [12203.417158] [] :openafs:rx_ReadProc32+0x57/0xb0 Oct 13 14:58:02 app1 kernel: [12203.417180] [] :openafs:xdrrx_getint32+0x16/0x40 Oct 13 14:58:02 app1 kernel: [12203.417199] [] :openafs:xdr_AFSFetchStatus+0x19/0x1b0 Oct 13 14:58:02 app1 kernel: [12203.417218] [] :openafs:RXAFS_FetchStatus+0x1bb/0x220 Oct 13 14:58:02 app1 kernel: [12203.417240] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:02 app1 kernel: [12203.417260] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:02 app1 kernel: [12203.417274] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.417280] [enqueue_task+0x13/0x30] enqueue_task+0x13/0x30 Oct 13 14:58:02 app1 kernel: [12203.417294] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:02 app1 kernel: [12203.417316] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:02 app1 kernel: [12203.417319] [find_busiest_group+0x1fa/0x850] find_busiest_group+0x1fa/0x850 Oct 13 14:58:02 app1 kernel: [12203.417326] [__rmqueue+0x2f/0x240] __rmqueue+0x2f/0x240 Oct 13 14:58:02 app1 kernel: [12203.417345] [] :openafs:afs_linux_dentry_revalidate+0x2f3/0x370 Oct 13 14:58:02 app1 kernel: [12203.417363] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:02 app1 kernel: [12203.417383] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:02 app1 kernel: [12203.417407] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:02 app1 kernel: [12203.417413] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:02 app1 kernel: [12203.417418] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:02 app1 kernel: [12203.417428] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:02 app1 kernel: [12203.417441] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:02 app1 kernel: [12203.417445] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:02 app1 kernel: [12203.417450] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:02 app1 kernel: [12203.417454] [vfs_lstat_fd+0x2c/0x70] vfs_lstat_fd+0x2c/0x70 Oct 13 14:58:02 app1 kernel: [12203.417466] [sys_newlstat+0x27/0x50] sys_newlstat+0x27/0x50 Oct 13 14:58:02 app1 kernel: [12203.417470] [ipv6:__put_user_4+0x20/0x30] __put_user_4+0x20/0x30 Oct 13 14:58:02 app1 kernel: [12203.417476] [error_exit+0x0/0x51] error_exit+0x0/0x51 Oct 13 14:58:02 app1 kernel: [12203.417480] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:02 app1 kernel: [12203.417488] Oct 13 14:58:02 app1 kernel: [12203.417490] gvfsd-trash S 0000000000000000 0 20911 1 Oct 13 14:58:02 app1 kernel: [12203.417493] ffff81043f0317b8 0000000000000086 0000000000000086 0000000000000001 Oct 13 14:58:02 app1 kernel: [12203.417497] ffff81043f0317a0 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:02 app1 kernel: [12203.417501] ffffffff8067d0a0 ffffffff80680c00 ffff810449d8b9d0 000000000000000f Oct 13 14:58:02 app1 kernel: [12203.417504] Call Trace: Oct 13 14:58:02 app1 kernel: [12203.417534] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:02 app1 kernel: [12203.417540] [] default_wake_function+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.417562] [] :openafs:rxi_AllocSendPacket+0x83/0x170 Oct 13 14:58:02 app1 kernel: [12203.417584] [] :openafs:rxi_WriteProc+0x103/0x3c0 Oct 13 14:58:02 app1 kernel: [12203.417605] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:02 app1 kernel: [12203.417627] [] :openafs:rx_WriteProc32+0x59/0xb0 Oct 13 14:58:02 app1 kernel: [12203.417647] [] :openafs:xdrrx_putint32+0x1a/0x30 Oct 13 14:58:02 app1 kernel: [12203.417667] [] :openafs:afs_xdr_int+0x23/0x70 Oct 13 14:58:02 app1 kernel: [12203.417686] [] :openafs:RXAFS_FetchStatus+0x71/0x220 Oct 13 14:58:02 app1 kernel: [12203.417708] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:02 app1 kernel: [12203.417727] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:02 app1 kernel: [12203.417741] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.417760] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:02 app1 kernel: [12203.417781] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:02 app1 kernel: [12203.417804] [] :openafs:afs_linux_dentry_revalidate+0x2f3/0x370 Oct 13 14:58:02 app1 kernel: [12203.417821] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:02 app1 kernel: [12203.417842] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:02 app1 kernel: [12203.417866] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:02 app1 kernel: [12203.417872] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:02 app1 kernel: [12203.417877] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:02 app1 kernel: [12203.417887] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:02 app1 kernel: [12203.417900] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:02 app1 kernel: [12203.417904] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:02 app1 kernel: [12203.417908] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:02 app1 kernel: [12203.417913] [vfs_lstat_fd+0x2c/0x70] vfs_lstat_fd+0x2c/0x70 Oct 13 14:58:02 app1 kernel: [12203.417924] [sys_newlstat+0x27/0x50] sys_newlstat+0x27/0x50 Oct 13 14:58:02 app1 kernel: [12203.417929] [ipv6:__put_user_4+0x20/0x30] __put_user_4+0x20/0x30 Oct 13 14:58:02 app1 kernel: [12203.417935] [error_exit+0x0/0x51] error_exit+0x0/0x51 Oct 13 14:58:02 app1 kernel: [12203.417939] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:02 app1 kernel: [12203.417948] Oct 13 14:58:02 app1 kernel: [12203.417949] gvfsd-trash S 0000000000000000 0 20931 1 Oct 13 14:58:02 app1 kernel: [12203.417953] ffff8103f90537b8 0000000000000082 ffff81028006d800 ffff810280073c00 Oct 13 14:58:02 app1 kernel: [12203.417957] ffffffff802329d7 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:02 app1 kernel: [12203.417961] ffffffff8067d0a0 ffffffff80680c00 ffff8104144179d0 ffffffff8847f568 Oct 13 14:58:02 app1 kernel: [12203.417965] Call Trace: Oct 13 14:58:02 app1 kernel: [12203.417969] [enqueue_entity+0x37/0x70] enqueue_entity+0x37/0x70 Oct 13 14:58:02 app1 kernel: [12203.417979] [try_to_wake_up+0x66/0x3c0] try_to_wake_up+0x66/0x3c0 Oct 13 14:58:02 app1 kernel: [12203.418001] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:02 app1 kernel: [12203.418008] [] default_wake_function+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.418030] [] :openafs:rxi_AllocSendPacket+0x83/0x170 Oct 13 14:58:02 app1 kernel: [12203.418051] [] :openafs:rxi_WriteProc+0x103/0x3c0 Oct 13 14:58:02 app1 kernel: [12203.418072] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:02 app1 kernel: [12203.418094] [] :openafs:rx_WriteProc32+0x59/0xb0 Oct 13 14:58:02 app1 kernel: [12203.418114] [] :openafs:xdrrx_putint32+0x1a/0x30 Oct 13 14:58:02 app1 kernel: [12203.418133] [] :openafs:afs_xdr_int+0x23/0x70 Oct 13 14:58:02 app1 kernel: [12203.418153] [] :openafs:RXAFS_FetchStatus+0x71/0x220 Oct 13 14:58:02 app1 kernel: [12203.418174] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:02 app1 kernel: [12203.418194] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:02 app1 kernel: [12203.418208] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.418226] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:02 app1 kernel: [12203.418247] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:02 app1 kernel: [12203.418270] [] :openafs:afs_linux_dentry_revalidate+0x2f3/0x370 Oct 13 14:58:02 app1 kernel: [12203.418288] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:02 app1 kernel: [12203.418309] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:02 app1 kernel: [12203.418333] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:02 app1 kernel: [12203.418338] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:02 app1 kernel: [12203.418344] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:02 app1 kernel: [12203.418353] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:02 app1 kernel: [12203.418367] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:02 app1 kernel: [12203.418370] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:02 app1 kernel: [12203.418375] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:02 app1 kernel: [12203.418380] [vfs_lstat_fd+0x2c/0x70] vfs_lstat_fd+0x2c/0x70 Oct 13 14:58:02 app1 kernel: [12203.418391] [sys_newlstat+0x27/0x50] sys_newlstat+0x27/0x50 Oct 13 14:58:02 app1 kernel: [12203.418395] [ipv6:__put_user_4+0x20/0x30] __put_user_4+0x20/0x30 Oct 13 14:58:02 app1 kernel: [12203.418401] [error_exit+0x0/0x51] error_exit+0x0/0x51 Oct 13 14:58:02 app1 kernel: [12203.418406] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:02 app1 kernel: [12203.418413] Oct 13 14:58:02 app1 kernel: [12203.418415] gvfsd-trash S 0000000000000003 0 20945 1 Oct 13 14:58:02 app1 kernel: [12203.418419] ffff8106750df7c8 0000000000000086 ffff8106750df728 0000000000000000 Oct 13 14:58:02 app1 kernel: [12203.418423] ffff810676d63e00 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:02 app1 kernel: [12203.418428] ffffffff8067d0a0 ffffffff80680c00 ffff81061f9d0230 ffffc20000000000 Oct 13 14:58:02 app1 kernel: [12203.418431] Call Trace: Oct 13 14:58:02 app1 kernel: [12203.418454] [] :openafs:afs_mutex_enter+0x9/0x40 Oct 13 14:58:02 app1 kernel: [12203.418480] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:02 app1 kernel: [12203.418486] [] default_wake_function+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.418508] [] :openafs:rxi_ReadProc+0xdf/0x450 Oct 13 14:58:02 app1 kernel: [12203.418529] [] :openafs:rxi_WriteProc+0x2ef/0x3c0 Oct 13 14:58:02 app1 kernel: [12203.418550] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:02 app1 kernel: [12203.418572] [] :openafs:rx_ReadProc32+0x57/0xb0 Oct 13 14:58:02 app1 kernel: [12203.418592] [] :openafs:xdrrx_getint32+0x16/0x40 Oct 13 14:58:02 app1 kernel: [12203.418611] [] :openafs:xdr_AFSFetchStatus+0x19/0x1b0 Oct 13 14:58:02 app1 kernel: [12203.418631] [] :openafs:RXAFS_FetchStatus+0x1bb/0x220 Oct 13 14:58:02 app1 kernel: [12203.418635] [lock_timer_base+0x34/0x70] lock_timer_base+0x34/0x70 Oct 13 14:58:02 app1 kernel: [12203.418655] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:02 app1 kernel: [12203.418675] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:02 app1 kernel: [12203.418689] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.418706] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:02 app1 kernel: [12203.418727] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:02 app1 kernel: [12203.418735] [] default_wake_function+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.418754] [] :openafs:afs_linux_dentry_revalidate+0x2f3/0x370 Oct 13 14:58:02 app1 kernel: [12203.418772] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:02 app1 kernel: [12203.418793] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:02 app1 kernel: [12203.418818] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:02 app1 kernel: [12203.418823] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:02 app1 kernel: [12203.418829] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:02 app1 kernel: [12203.418838] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:02 app1 kernel: [12203.418852] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:02 app1 kernel: [12203.418855] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:02 app1 kernel: [12203.418860] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:02 app1 kernel: [12203.418865] [vfs_lstat_fd+0x2c/0x70] vfs_lstat_fd+0x2c/0x70 Oct 13 14:58:02 app1 kernel: [12203.418876] [sys_newlstat+0x27/0x50] sys_newlstat+0x27/0x50 Oct 13 14:58:02 app1 kernel: [12203.418881] [ipv6:__put_user_4+0x20/0x30] __put_user_4+0x20/0x30 Oct 13 14:58:02 app1 kernel: [12203.418887] [error_exit+0x0/0x51] error_exit+0x0/0x51 Oct 13 14:58:02 app1 kernel: [12203.418891] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:02 app1 kernel: [12203.418900] Oct 13 14:58:02 app1 kernel: [12203.418902] gvfsd-trash S 0000000000000000 0 20949 1 Oct 13 14:58:02 app1 kernel: [12203.418905] ffff81043b1eb8c8 0000000000000082 0000000000000000 0000000000000001 Oct 13 14:58:02 app1 kernel: [12203.418910] ffff81043b0e47e0 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:02 app1 kernel: [12203.418914] ffffffff8067d0a0 ffffffff80680c00 ffff81043b0e4a10 ffff81043b1eb894 Oct 13 14:58:02 app1 kernel: [12203.418918] Call Trace: Oct 13 14:58:02 app1 kernel: [12203.418947] [] :openafs:afs_osi_SleepSig+0xed/0x190 Oct 13 14:58:02 app1 kernel: [12203.418952] [] default_wake_function+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.418966] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.418987] [] :openafs:afs_osi_Sleep+0x69/0xc0 Oct 13 14:58:02 app1 kernel: [12203.419004] [] :openafs:Afs_Lock_Obtain+0x184/0x1c0 Oct 13 14:58:02 app1 kernel: [12203.419024] [] :openafs:afs_GetVCache+0x162/0x450 Oct 13 14:58:02 app1 kernel: [12203.419039] [] :openafs:afs_dir_GetBlob+0xd/0x30 Oct 13 14:58:02 app1 kernel: [12203.419055] [] :openafs:FindItem+0x7e/0x110 Oct 13 14:58:02 app1 kernel: [12203.419078] [] :openafs:afs_lookup+0xa32/0x13e0 Oct 13 14:58:02 app1 kernel: [12203.419093] [] :openafs:afs_TraverseCells+0x38/0xc0 Oct 13 14:58:02 app1 kernel: [12203.419125] [] :openafs:afs_linux_dentry_revalidate+0xd3/0x370 Oct 13 14:58:02 app1 kernel: [12203.419143] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:02 app1 kernel: [12203.419164] [] :openafs:afs_access+0x168/0x420 Oct 13 14:58:02 app1 kernel: [12203.419168] [__d_lookup+0xaf/0x140] __d_lookup+0xaf/0x140 Oct 13 14:58:02 app1 kernel: [12203.419176] [do_lookup+0x64/0x250] do_lookup+0x64/0x250 Oct 13 14:58:02 app1 kernel: [12203.419184] [__link_path_walk+0x14b/0xe90] __link_path_walk+0x14b/0xe90 Oct 13 14:58:02 app1 kernel: [12203.419188] [try_to_wake_up+0x66/0x3c0] try_to_wake_up+0x66/0x3c0 Oct 13 14:58:02 app1 kernel: [12203.419196] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:02 app1 kernel: [12203.419210] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:02 app1 kernel: [12203.419213] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:02 app1 kernel: [12203.419217] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:02 app1 kernel: [12203.419222] [vfs_lstat_fd+0x2c/0x70] vfs_lstat_fd+0x2c/0x70 Oct 13 14:58:02 app1 kernel: [12203.419234] [sys_newlstat+0x27/0x50] sys_newlstat+0x27/0x50 Oct 13 14:58:02 app1 kernel: [12203.419238] [vfs_write+0x14e/0x190] vfs_write+0x14e/0x190 Oct 13 14:58:02 app1 kernel: [12203.419240] [ipv6:__put_user_4+0x20/0x30] __put_user_4+0x20/0x30 Oct 13 14:58:02 app1 kernel: [12203.419245] [sys_write+0x53/0x90] sys_write+0x53/0x90 Oct 13 14:58:02 app1 kernel: [12203.419251] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:02 app1 kernel: [12203.419258] Oct 13 14:58:02 app1 kernel: [12203.419260] gvfsd-trash S 0000000000000000 0 20951 1 Oct 13 14:58:02 app1 kernel: [12203.419263] ffff8104221418c8 0000000000000086 0000000000000000 0000000000000000 Oct 13 14:58:02 app1 kernel: [12203.419267] 0000000000000000 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:02 app1 kernel: [12203.419271] ffffffff8067d0a0 ffffffff80680c00 ffff8104265a6a10 ffff810422141894 Oct 13 14:58:02 app1 kernel: [12203.419275] Call Trace: Oct 13 14:58:02 app1 kernel: [12203.419304] [] :openafs:afs_osi_SleepSig+0xed/0x190 Oct 13 14:58:02 app1 kernel: [12203.419309] [] default_wake_function+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.419323] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.419344] [] :openafs:afs_osi_Sleep+0x69/0xc0 Oct 13 14:58:02 app1 kernel: [12203.419360] [] :openafs:Afs_Lock_Obtain+0x184/0x1c0 Oct 13 14:58:02 app1 kernel: [12203.419381] [] :openafs:afs_GetVCache+0x162/0x450 Oct 13 14:58:02 app1 kernel: [12203.419396] [] :openafs:afs_dir_GetBlob+0xd/0x30 Oct 13 14:58:02 app1 kernel: [12203.419411] [] :openafs:FindItem+0x7e/0x110 Oct 13 14:58:02 app1 kernel: [12203.419434] [] :openafs:afs_lookup+0xa32/0x13e0 Oct 13 14:58:02 app1 kernel: [12203.419448] [] :openafs:afs_TraverseCells+0x38/0xc0 Oct 13 14:58:02 app1 kernel: [12203.419480] [] :openafs:afs_linux_dentry_revalidate+0xd3/0x370 Oct 13 14:58:02 app1 kernel: [12203.419498] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:02 app1 kernel: [12203.419519] [] :openafs:afs_access+0x168/0x420 Oct 13 14:58:02 app1 kernel: [12203.419523] [__d_lookup+0xaf/0x140] __d_lookup+0xaf/0x140 Oct 13 14:58:02 app1 kernel: [12203.419531] [do_lookup+0x64/0x250] do_lookup+0x64/0x250 Oct 13 14:58:02 app1 kernel: [12203.419538] [__link_path_walk+0x14b/0xe90] __link_path_walk+0x14b/0xe90 Oct 13 14:58:02 app1 kernel: [12203.419547] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:02 app1 kernel: [12203.419555] [thread_return+0x3a/0x59a] thread_return+0x3a/0x59a Oct 13 14:58:02 app1 kernel: [12203.419564] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:02 app1 kernel: [12203.419568] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:02 app1 kernel: [12203.419572] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:02 app1 kernel: [12203.419577] [vfs_lstat_fd+0x2c/0x70] vfs_lstat_fd+0x2c/0x70 Oct 13 14:58:02 app1 kernel: [12203.419583] [thread_return+0x3a/0x59a] thread_return+0x3a/0x59a Oct 13 14:58:02 app1 kernel: [12203.419590] [sys_newlstat+0x27/0x50] sys_newlstat+0x27/0x50 Oct 13 14:58:02 app1 kernel: [12203.419595] [ipv6:__put_user_4+0x20/0x30] __put_user_4+0x20/0x30 Oct 13 14:58:02 app1 kernel: [12203.419599] [sys_write+0x53/0x90] sys_write+0x53/0x90 Oct 13 14:58:02 app1 kernel: [12203.419605] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:02 app1 kernel: [12203.419613] Oct 13 14:58:02 app1 kernel: [12203.419614] gvfsd-trash S 0000000000000000 0 20961 1 Oct 13 14:58:02 app1 kernel: [12203.419618] ffff8104281cd7c8 0000000000000082 0000000000000000 ffffc20005a32250 Oct 13 14:58:02 app1 kernel: [12203.419622] 0000000000000001 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:02 app1 kernel: [12203.419626] ffffffff8067d0a0 ffffffff80680c00 ffff8103fca3d1f0 ffff8104281cd794 Oct 13 14:58:02 app1 kernel: [12203.419629] Call Trace: Oct 13 14:58:02 app1 kernel: [12203.419658] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:02 app1 kernel: [12203.419664] [] default_wake_function+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.419686] [] :openafs:rxi_ReadProc+0xdf/0x450 Oct 13 14:58:02 app1 kernel: [12203.419707] [] :openafs:rxi_WriteProc+0x2ef/0x3c0 Oct 13 14:58:02 app1 kernel: [12203.419728] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:02 app1 kernel: [12203.419750] [] :openafs:rx_ReadProc32+0x57/0xb0 Oct 13 14:58:02 app1 kernel: [12203.419770] [] :openafs:xdrrx_getint32+0x16/0x40 Oct 13 14:58:02 app1 kernel: [12203.419789] [] :openafs:xdr_AFSFetchStatus+0x19/0x1b0 Oct 13 14:58:02 app1 kernel: [12203.419809] [] :openafs:RXAFS_FetchStatus+0x1bb/0x220 Oct 13 14:58:02 app1 kernel: [12203.419814] [try_to_wake_up+0x66/0x3c0] try_to_wake_up+0x66/0x3c0 Oct 13 14:58:02 app1 kernel: [12203.419833] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:02 app1 kernel: [12203.419853] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:02 app1 kernel: [12203.419867] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.419873] [enqueue_task+0x13/0x30] enqueue_task+0x13/0x30 Oct 13 14:58:02 app1 kernel: [12203.419887] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:02 app1 kernel: [12203.419909] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:02 app1 kernel: [12203.419916] [enqueue_task+0x13/0x30] enqueue_task+0x13/0x30 Oct 13 14:58:02 app1 kernel: [12203.419934] [] :openafs:afs_linux_dentry_revalidate+0x2f3/0x370 Oct 13 14:58:02 app1 kernel: [12203.419952] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:02 app1 kernel: [12203.419973] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:02 app1 kernel: [12203.419997] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:02 app1 kernel: [12203.420003] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:02 app1 kernel: [12203.420008] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:02 app1 kernel: [12203.420018] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:02 app1 kernel: [12203.420031] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:02 app1 kernel: [12203.420035] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:02 app1 kernel: [12203.420040] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:02 app1 kernel: [12203.420045] [vfs_lstat_fd+0x2c/0x70] vfs_lstat_fd+0x2c/0x70 Oct 13 14:58:02 app1 kernel: [12203.420056] [sys_newlstat+0x27/0x50] sys_newlstat+0x27/0x50 Oct 13 14:58:02 app1 kernel: [12203.420060] [ipv6:__put_user_4+0x20/0x30] __put_user_4+0x20/0x30 Oct 13 14:58:02 app1 kernel: [12203.420066] [error_exit+0x0/0x51] error_exit+0x0/0x51 Oct 13 14:58:02 app1 kernel: [12203.420071] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:02 app1 kernel: [12203.420079] Oct 13 14:58:02 app1 kernel: [12203.420080] gvfsd-trash S 0000000000000000 0 20968 1 Oct 13 14:58:02 app1 kernel: [12203.420085] ffff8103f955d7b8 0000000000000082 0000000000000000 ffff810280073c00 Oct 13 14:58:02 app1 kernel: [12203.420088] ffffffff802329d7 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:02 app1 kernel: [12203.420093] ffffffff8067d0a0 ffffffff80680c00 ffff810426dc39d0 ffff8103f955d784 Oct 13 14:58:02 app1 kernel: [12203.420096] Call Trace: Oct 13 14:58:02 app1 kernel: [12203.420101] [enqueue_entity+0x37/0x70] enqueue_entity+0x37/0x70 Oct 13 14:58:02 app1 kernel: [12203.420111] [try_to_wake_up+0x66/0x3c0] try_to_wake_up+0x66/0x3c0 Oct 13 14:58:02 app1 kernel: [12203.420132] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:02 app1 kernel: [12203.420138] [] default_wake_function+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.420160] [] :openafs:rxi_AllocSendPacket+0x83/0x170 Oct 13 14:58:02 app1 kernel: [12203.420182] [] :openafs:rxi_WriteProc+0x103/0x3c0 Oct 13 14:58:02 app1 kernel: [12203.420202] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:02 app1 kernel: [12203.420225] [] :openafs:rx_WriteProc32+0x59/0xb0 Oct 13 14:58:02 app1 kernel: [12203.420245] [] :openafs:xdrrx_putint32+0x1a/0x30 Oct 13 14:58:02 app1 kernel: [12203.420264] [] :openafs:afs_xdr_int+0x23/0x70 Oct 13 14:58:02 app1 kernel: [12203.420284] [] :openafs:RXAFS_FetchStatus+0x71/0x220 Oct 13 14:58:02 app1 kernel: [12203.420303] [] :openafs:rx_NewConnection+0x18b/0x1c0 Oct 13 14:58:02 app1 kernel: [12203.420323] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:02 app1 kernel: [12203.420343] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:02 app1 kernel: [12203.420357] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.420374] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:02 app1 kernel: [12203.420395] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:02 app1 kernel: [12203.420418] [] :openafs:afs_linux_dentry_revalidate+0x2f3/0x370 Oct 13 14:58:02 app1 kernel: [12203.420437] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:02 app1 kernel: [12203.420458] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:02 app1 kernel: [12203.420482] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:02 app1 kernel: [12203.420487] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:02 app1 kernel: [12203.420493] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:02 app1 kernel: [12203.420503] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:02 app1 kernel: [12203.420516] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:02 app1 kernel: [12203.420519] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:02 app1 kernel: [12203.420524] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:02 app1 kernel: [12203.420529] [vfs_lstat_fd+0x2c/0x70] vfs_lstat_fd+0x2c/0x70 Oct 13 14:58:02 app1 kernel: [12203.420540] [sys_newlstat+0x27/0x50] sys_newlstat+0x27/0x50 Oct 13 14:58:02 app1 kernel: [12203.420545] [ipv6:__put_user_4+0x20/0x30] __put_user_4+0x20/0x30 Oct 13 14:58:02 app1 kernel: [12203.420550] [error_exit+0x0/0x51] error_exit+0x0/0x51 Oct 13 14:58:02 app1 kernel: [12203.420556] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:02 app1 kernel: [12203.420563] Oct 13 14:58:02 app1 kernel: [12203.420565] gvfsd-trash S 0000000000000004 0 20972 1 Oct 13 14:58:02 app1 kernel: [12203.420569] ffff8103fb0017b8 0000000000000086 0000000000000086 0000000000000001 Oct 13 14:58:02 app1 kernel: [12203.420572] ffff8103fb0017a0 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:02 app1 kernel: [12203.420577] ffffffff8067d0a0 ffffffff80680c00 ffff8103fd19e230 000000000000000f Oct 13 14:58:02 app1 kernel: [12203.420580] Call Trace: Oct 13 14:58:02 app1 kernel: [12203.420610] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:02 app1 kernel: [12203.420616] [] default_wake_function+0x0/0x10 Oct 13 14:58:02 app1 kernel: [12203.420638] [] :openafs:rxi_AllocSendPacket+0x83/0x170 Oct 13 14:58:02 app1 kernel: [12203.420660] [] :openafs:rxi_WriteProc+0x103/0x3c0 Oct 13 14:58:02 app1 kernel: [12203.420681] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:02 app1 kernel: [12203.420703] [] :openafs:rx_WriteProc32+0x59/0xb0 Oct 13 14:58:02 app1 kernel: [12203.420723] [] :openafs:xdrrx_putint32+0x1a/0x30 Oct 13 14:58:02 app1 kernel: [12203.420743] [] :openafs:afs_xdr_int+0x23/0x70 Oct 13 14:58:03 app1 kernel: [12203.420763] [] :openafs:RXAFS_FetchStatus+0x71/0x220 Oct 13 14:58:03 app1 kernel: [12203.420767] [lock_timer_base+0x34/0x70] lock_timer_base+0x34/0x70 Oct 13 14:58:03 app1 kernel: [12203.420787] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.420807] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:03 app1 kernel: [12203.420821] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.420838] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:03 app1 kernel: [12203.420859] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:03 app1 kernel: [12203.420883] [] :openafs:afs_linux_dentry_revalidate+0x2f3/0x370 Oct 13 14:58:03 app1 kernel: [12203.420901] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:03 app1 kernel: [12203.420922] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:03 app1 kernel: [12203.420946] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:03 app1 kernel: [12203.420952] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:03 app1 kernel: [12203.420957] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:03 app1 kernel: [12203.420967] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:03 app1 kernel: [12203.420980] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:03 app1 kernel: [12203.420983] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:03 app1 kernel: [12203.420989] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:03 app1 kernel: [12203.420993] [vfs_lstat_fd+0x2c/0x70] vfs_lstat_fd+0x2c/0x70 Oct 13 14:58:03 app1 kernel: [12203.421004] [sys_newlstat+0x27/0x50] sys_newlstat+0x27/0x50 Oct 13 14:58:03 app1 kernel: [12203.421008] [ipv6:__put_user_4+0x20/0x30] __put_user_4+0x20/0x30 Oct 13 14:58:03 app1 kernel: [12203.421014] [error_exit+0x0/0x51] error_exit+0x0/0x51 Oct 13 14:58:03 app1 kernel: [12203.421018] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.421027] Oct 13 14:58:03 app1 kernel: [12203.421030] gvfsd-trash S 0000000000000000 0 20976 1 Oct 13 14:58:03 app1 kernel: [12203.421033] ffff8103f90e38c8 0000000000000086 0000000000000000 0000000000000001 Oct 13 14:58:03 app1 kernel: [12203.421037] ffff8103f90e3828 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.421041] ffffffff8067d0a0 ffffffff80680c00 ffff81041c4c31f0 ffff8103f90e3894 Oct 13 14:58:03 app1 kernel: [12203.421045] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.421074] [] :openafs:afs_osi_SleepSig+0xed/0x190 Oct 13 14:58:03 app1 kernel: [12203.421078] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.421093] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.421114] [] :openafs:afs_osi_Sleep+0x69/0xc0 Oct 13 14:58:03 app1 kernel: [12203.421130] [] :openafs:Afs_Lock_Obtain+0x184/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.421151] [] :openafs:afs_GetVCache+0x162/0x450 Oct 13 14:58:03 app1 kernel: [12203.421166] [] :openafs:afs_dir_GetBlob+0xd/0x30 Oct 13 14:58:03 app1 kernel: [12203.421181] [] :openafs:FindItem+0x7e/0x110 Oct 13 14:58:03 app1 kernel: [12203.421205] [] :openafs:afs_lookup+0xa32/0x13e0 Oct 13 14:58:03 app1 kernel: [12203.421219] [] :openafs:afs_TraverseCells+0x38/0xc0 Oct 13 14:58:03 app1 kernel: [12203.421251] [] :openafs:afs_linux_dentry_revalidate+0xd3/0x370 Oct 13 14:58:03 app1 kernel: [12203.421269] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:03 app1 kernel: [12203.421290] [] :openafs:afs_access+0x168/0x420 Oct 13 14:58:03 app1 kernel: [12203.421294] [__d_lookup+0xaf/0x140] __d_lookup+0xaf/0x140 Oct 13 14:58:03 app1 kernel: [12203.421302] [do_lookup+0x64/0x250] do_lookup+0x64/0x250 Oct 13 14:58:03 app1 kernel: [12203.421310] [__link_path_walk+0x14b/0xe90] __link_path_walk+0x14b/0xe90 Oct 13 14:58:03 app1 kernel: [12203.421319] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:03 app1 kernel: [12203.421332] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:03 app1 kernel: [12203.421336] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:03 app1 kernel: [12203.421340] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:03 app1 kernel: [12203.421345] [vfs_lstat_fd+0x2c/0x70] vfs_lstat_fd+0x2c/0x70 Oct 13 14:58:03 app1 kernel: [12203.421356] [sys_newlstat+0x27/0x50] sys_newlstat+0x27/0x50 Oct 13 14:58:03 app1 kernel: [12203.421361] [vfs_write+0x14e/0x190] vfs_write+0x14e/0x190 Oct 13 14:58:03 app1 kernel: [12203.421363] [ipv6:__put_user_4+0x20/0x30] __put_user_4+0x20/0x30 Oct 13 14:58:03 app1 kernel: [12203.421368] [sys_write+0x53/0x90] sys_write+0x53/0x90 Oct 13 14:58:03 app1 kernel: [12203.421373] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.421381] Oct 13 14:58:03 app1 kernel: [12203.421383] gvfsd-trash S 0000000000000001 0 21005 1 Oct 13 14:58:03 app1 kernel: [12203.421385] ffff81043f04f8c8 0000000000000082 ffffffff8029308d 0000000000000001 Oct 13 14:58:03 app1 kernel: [12203.421390] ffff8104774c5180 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.421393] ffffffff8067d0a0 ffffffff80680c00 ffff810467818a10 ffffffff883e9e30 Oct 13 14:58:03 app1 kernel: [12203.421398] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.421401] [zone_statistics+0x7d/0x80] zone_statistics+0x7d/0x80 Oct 13 14:58:03 app1 kernel: [12203.421418] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.421432] [] :openafs:afs_TraverseCells+0x38/0xc0 Oct 13 14:58:03 app1 kernel: [12203.421447] [] :openafs:afs_GetCellStale+0x33/0x40 Oct 13 14:58:03 app1 kernel: [12203.421463] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:03 app1 kernel: [12203.421485] [] :openafs:afs_osi_SleepSig+0xed/0x190 Oct 13 14:58:03 app1 kernel: [12203.421490] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.421505] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.421526] [] :openafs:afs_osi_Sleep+0x69/0xc0 Oct 13 14:58:03 app1 kernel: [12203.421542] [] :openafs:Afs_Lock_Obtain+0x184/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.421563] [] :openafs:afs_GetVCache+0x162/0x450 Oct 13 14:58:03 app1 kernel: [12203.421578] [] :openafs:afs_dir_GetBlob+0xd/0x30 Oct 13 14:58:03 app1 kernel: [12203.421593] [] :openafs:FindItem+0x7e/0x110 Oct 13 14:58:03 app1 kernel: [12203.421615] [] :openafs:afs_lookup+0xa32/0x13e0 Oct 13 14:58:03 app1 kernel: [12203.421629] [] :openafs:afs_TraverseCells+0x38/0xc0 Oct 13 14:58:03 app1 kernel: [12203.421660] [] :openafs:afs_linux_dentry_revalidate+0xd3/0x370 Oct 13 14:58:03 app1 kernel: [12203.421679] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:03 app1 kernel: [12203.421699] [] :openafs:afs_access+0x168/0x420 Oct 13 14:58:03 app1 kernel: [12203.421704] [__d_lookup+0xaf/0x140] __d_lookup+0xaf/0x140 Oct 13 14:58:03 app1 kernel: [12203.421711] [do_lookup+0x64/0x250] do_lookup+0x64/0x250 Oct 13 14:58:03 app1 kernel: [12203.421719] [__link_path_walk+0x14b/0xe90] __link_path_walk+0x14b/0xe90 Oct 13 14:58:03 app1 kernel: [12203.421729] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:03 app1 kernel: [12203.421742] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:03 app1 kernel: [12203.421746] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:03 app1 kernel: [12203.421751] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:03 app1 kernel: [12203.421756] [vfs_lstat_fd+0x2c/0x70] vfs_lstat_fd+0x2c/0x70 Oct 13 14:58:03 app1 kernel: [12203.421767] [sys_newlstat+0x27/0x50] sys_newlstat+0x27/0x50 Oct 13 14:58:03 app1 kernel: [12203.421771] [vfs_write+0x14e/0x190] vfs_write+0x14e/0x190 Oct 13 14:58:03 app1 kernel: [12203.421774] [ipv6:__put_user_4+0x20/0x30] __put_user_4+0x20/0x30 Oct 13 14:58:03 app1 kernel: [12203.421778] [sys_write+0x53/0x90] sys_write+0x53/0x90 Oct 13 14:58:03 app1 kernel: [12203.421784] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.421792] Oct 13 14:58:03 app1 kernel: [12203.421793] gvfsd-trash S 0000000000000006 0 21332 1 Oct 13 14:58:03 app1 kernel: [12203.421796] ffff8104444197c8 0000000000000082 ffff810444419728 0000000000000000 Oct 13 14:58:03 app1 kernel: [12203.421800] ffff810672c8a800 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.421804] ffffffff8067d0a0 ffffffff80680c00 ffff81042cc819d0 ffffc20000000000 Oct 13 14:58:03 app1 kernel: [12203.421808] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.421831] [] :openafs:afs_mutex_enter+0x9/0x40 Oct 13 14:58:03 app1 kernel: [12203.421856] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:03 app1 kernel: [12203.421862] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.421884] [] :openafs:rxi_ReadProc+0xdf/0x450 Oct 13 14:58:03 app1 kernel: [12203.421905] [] :openafs:rxi_WriteProc+0x2ef/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.421926] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:03 app1 kernel: [12203.421947] [] :openafs:rx_ReadProc32+0x57/0xb0 Oct 13 14:58:03 app1 kernel: [12203.421967] [] :openafs:xdrrx_getint32+0x16/0x40 Oct 13 14:58:03 app1 kernel: [12203.421986] [] :openafs:xdr_AFSFetchStatus+0x19/0x1b0 Oct 13 14:58:03 app1 kernel: [12203.422005] [] :openafs:RXAFS_FetchStatus+0x1bb/0x220 Oct 13 14:58:03 app1 kernel: [12203.422011] [try_to_wake_up+0x66/0x3c0] try_to_wake_up+0x66/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.422036] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:03 app1 kernel: [12203.422050] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.422068] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:03 app1 kernel: [12203.422089] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:03 app1 kernel: [12203.422092] [enqueue_entity+0x37/0x70] enqueue_entity+0x37/0x70 Oct 13 14:58:03 app1 kernel: [12203.422098] [enqueue_task_fair+0x38/0x50] enqueue_task_fair+0x38/0x50 Oct 13 14:58:03 app1 kernel: [12203.422101] [find_get_pages_tag+0x34/0x90] find_get_pages_tag+0x34/0x90 Oct 13 14:58:03 app1 kernel: [12203.422121] [] :openafs:afs_linux_dentry_revalidate+0x2f3/0x370 Oct 13 14:58:03 app1 kernel: [12203.422139] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:03 app1 kernel: [12203.422160] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:03 app1 kernel: [12203.422184] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:03 app1 kernel: [12203.422189] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:03 app1 kernel: [12203.422195] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:03 app1 kernel: [12203.422204] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:03 app1 kernel: [12203.422217] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:03 app1 kernel: [12203.422221] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:03 app1 kernel: [12203.422225] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:03 app1 kernel: [12203.422230] [vfs_lstat_fd+0x2c/0x70] vfs_lstat_fd+0x2c/0x70 Oct 13 14:58:03 app1 kernel: [12203.422242] [sys_newlstat+0x27/0x50] sys_newlstat+0x27/0x50 Oct 13 14:58:03 app1 kernel: [12203.422246] [ipv6:__put_user_4+0x20/0x30] __put_user_4+0x20/0x30 Oct 13 14:58:03 app1 kernel: [12203.422252] [error_exit+0x0/0x51] error_exit+0x0/0x51 Oct 13 14:58:03 app1 kernel: [12203.422257] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.422265] Oct 13 14:58:03 app1 kernel: [12203.422268] gvfsd-trash S 0000000000000001 0 21338 1 Oct 13 14:58:03 app1 kernel: [12203.422271] ffff81078a9b17c8 0000000000000086 ffffffff8046fd5d ffffffff8847f348 Oct 13 14:58:03 app1 kernel: [12203.422275] ffffffff8847f348 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.422279] ffffffff8067d0a0 ffffffff80680c00 ffff810860df2230 ffffffff88423ff0 Oct 13 14:58:03 app1 kernel: [12203.422283] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.422286] [__mutex_lock_slowpath+0x8d/0xe0] __mutex_lock_slowpath+0x8d/0xe0 Oct 13 14:58:03 app1 kernel: [12203.422308] [] :openafs:rxi_StartUnlocked+0x0/0x70 Oct 13 14:58:03 app1 kernel: [12203.422311] [powernow_k8:mutex_lock+0xa/0x10] mutex_lock+0xa/0x10 Oct 13 14:58:03 app1 kernel: [12203.422329] [] :openafs:afs_mutex_enter+0x9/0x40 Oct 13 14:58:03 app1 kernel: [12203.422354] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:03 app1 kernel: [12203.422361] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.422383] [] :openafs:rxi_ReadProc+0xdf/0x450 Oct 13 14:58:03 app1 kernel: [12203.422403] [] :openafs:rxi_WriteProc+0x2ef/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.422424] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:03 app1 kernel: [12203.422446] [] :openafs:rx_ReadProc32+0x57/0xb0 Oct 13 14:58:03 app1 kernel: [12203.422466] [] :openafs:xdrrx_getint32+0x16/0x40 Oct 13 14:58:03 app1 kernel: [12203.422484] [] :openafs:xdr_AFSFetchStatus+0x19/0x1b0 Oct 13 14:58:03 app1 kernel: [12203.422504] [] :openafs:RXAFS_FetchStatus+0x1bb/0x220 Oct 13 14:58:03 app1 kernel: [12203.422526] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.422546] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:03 app1 kernel: [12203.422560] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.422577] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:03 app1 kernel: [12203.422598] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:03 app1 kernel: [12203.422621] [] :openafs:afs_linux_dentry_revalidate+0x2f3/0x370 Oct 13 14:58:03 app1 kernel: [12203.422639] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:03 app1 kernel: [12203.422659] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:03 app1 kernel: [12203.422684] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:03 app1 kernel: [12203.422690] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:03 app1 kernel: [12203.422695] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:03 app1 kernel: [12203.422705] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:03 app1 kernel: [12203.422719] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:03 app1 kernel: [12203.422722] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:03 app1 kernel: [12203.422727] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:03 app1 kernel: [12203.422731] [vfs_lstat_fd+0x2c/0x70] vfs_lstat_fd+0x2c/0x70 Oct 13 14:58:03 app1 kernel: [12203.422743] [sys_newlstat+0x27/0x50] sys_newlstat+0x27/0x50 Oct 13 14:58:03 app1 kernel: [12203.422747] [ipv6:__put_user_4+0x20/0x30] __put_user_4+0x20/0x30 Oct 13 14:58:03 app1 kernel: [12203.422753] [error_exit+0x0/0x51] error_exit+0x0/0x51 Oct 13 14:58:03 app1 kernel: [12203.422758] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.422767] Oct 13 14:58:03 app1 kernel: [12203.422768] aklog S 0000000000000006 0 23246 1 Oct 13 14:58:03 app1 kernel: [12203.422771] ffff81085a1777c8 0000000000000086 ffff81085a177728 0000000000000000 Oct 13 14:58:03 app1 kernel: [12203.422775] ffff81087643d000 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.422779] ffffffff8067d0a0 ffffffff80680c00 ffff810839c4aa10 ffffc20000000000 Oct 13 14:58:03 app1 kernel: [12203.422783] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.422805] [] :openafs:afs_mutex_enter+0x9/0x40 Oct 13 14:58:03 app1 kernel: [12203.422831] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:03 app1 kernel: [12203.422837] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.422860] [] :openafs:rxi_ReadProc+0xdf/0x450 Oct 13 14:58:03 app1 kernel: [12203.422881] [] :openafs:rxi_WriteProc+0x2ef/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.422901] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:03 app1 kernel: [12203.422923] [] :openafs:rx_ReadProc32+0x57/0xb0 Oct 13 14:58:03 app1 kernel: [12203.422942] [] :openafs:xdrrx_getint32+0x16/0x40 Oct 13 14:58:03 app1 kernel: [12203.422961] [] :openafs:xdr_AFSFetchStatus+0x19/0x1b0 Oct 13 14:58:03 app1 kernel: [12203.422980] [] :openafs:RXAFS_FetchStatus+0x1bb/0x220 Oct 13 14:58:03 app1 kernel: [12203.423000] [] :openafs:rx_NewConnection+0x18b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.423021] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.423040] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:03 app1 kernel: [12203.423054] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.423071] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:03 app1 kernel: [12203.423092] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:03 app1 kernel: [12203.423115] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:03 app1 kernel: [12203.423135] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:03 app1 kernel: [12203.423159] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:03 app1 kernel: [12203.423164] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:03 app1 kernel: [12203.423169] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:03 app1 kernel: [12203.423179] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:03 app1 kernel: [12203.423185] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.423189] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.423193] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.423200] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:03 app1 kernel: [12203.423204] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:03 app1 kernel: [12203.423208] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:03 app1 kernel: [12203.423214] [vfs_stat_fd+0x2f/0x80] vfs_stat_fd+0x2f/0x80 Oct 13 14:58:03 app1 kernel: [12203.423219] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.423223] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.423227] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.423233] [sys_newstat+0x27/0x50] sys_newstat+0x27/0x50 Oct 13 14:58:03 app1 kernel: [12203.423236] [ext2:dput+0x1f/0xe10] dput+0x1f/0x130 Oct 13 14:58:03 app1 kernel: [12203.423239] [fuse:mntput_no_expire+0x27/0x4bb0] mntput_no_expire+0x27/0xb0 Oct 13 14:58:03 app1 kernel: [12203.423245] [reiserfs:filp_close+0x54/0x3c0] filp_close+0x54/0x90 Oct 13 14:58:03 app1 kernel: [12203.423248] [sys_close+0x9f/0x100] sys_close+0x9f/0x100 Oct 13 14:58:03 app1 kernel: [12203.423253] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.423261] Oct 13 14:58:03 app1 kernel: [12203.423263] nbdrootd S 0000000000000000 0 23407 6252 Oct 13 14:58:03 app1 kernel: [12203.423266] ffff810866991e78 0000000000000082 0000000000000000 ffff81027f799838 Oct 13 14:58:03 app1 kernel: [12203.423270] 0000000000000007 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.423274] ffffffff8067d0a0 ffffffff80680c00 ffff81084251f1f0 ffff810866991e44 Oct 13 14:58:03 app1 kernel: [12203.423277] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.423288] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.423295] [do_wait+0x5e7/0xcd0] do_wait+0x5e7/0xcd0 Oct 13 14:58:03 app1 kernel: [12203.423305] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.423312] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.423320] Oct 13 14:58:03 app1 kernel: [12203.423321] nbd-server S 0000000000000000 0 23408 23407 Oct 13 14:58:03 app1 kernel: [12203.423325] ffff8101e6da1b58 0000000000000082 0000000000000000 0000000100000286 Oct 13 14:58:03 app1 kernel: [12203.423329] ffff81085fcf2400 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.423333] ffffffff8067d0a0 ffffffff80680c00 ffff8101eb538230 ffff8101e6da1b24 Oct 13 14:58:03 app1 kernel: [12203.423336] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.423350] [cciss:schedule_timeout+0x95/0xd0] schedule_timeout+0x95/0xd0 Oct 13 14:58:03 app1 kernel: [12203.423355] [ipv6:lock_sock_nested+0x9c/0xe0] lock_sock_nested+0x9c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.423360] [ipv6:_spin_lock_bh+0x9/0x20] _spin_lock_bh+0x9/0x20 Oct 13 14:58:03 app1 kernel: [12203.423363] [af_packet:release_sock+0x13/0xb0] release_sock+0x13/0xb0 Oct 13 14:58:03 app1 kernel: [12203.423368] [sk_wait_data+0x8a/0xe0] sk_wait_data+0x8a/0xe0 Oct 13 14:58:03 app1 kernel: [12203.423371] [] autoremove_wake_function+0x0/0x30 Oct 13 14:58:03 app1 kernel: [12203.423377] [ipv6:tcp_recvmsg+0x67d/0xd20] tcp_recvmsg+0x67d/0xd20 Oct 13 14:58:03 app1 kernel: [12203.423390] [ipv6:sock_common_recvmsg+0x30/0x50] sock_common_recvmsg+0x30/0x50 Oct 13 14:58:03 app1 kernel: [12203.423395] [sock_aio_read+0x15d/0x170] sock_aio_read+0x15d/0x170 Oct 13 14:58:03 app1 kernel: [12203.423407] [ext2:do_sync_read+0xd9/0xbb0] do_sync_read+0xd9/0x120 Oct 13 14:58:03 app1 kernel: [12203.423414] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.423417] [] autoremove_wake_function+0x0/0x30 Oct 13 14:58:03 app1 kernel: [12203.423425] [thread_return+0x3a/0x59a] thread_return+0x3a/0x59a Oct 13 14:58:03 app1 kernel: [12203.423434] [vfs_read+0x185/0x190] vfs_read+0x185/0x190 Oct 13 14:58:03 app1 kernel: [12203.423437] [fget_light+0x3d/0xa0] fget_light+0x3d/0xa0 Oct 13 14:58:03 app1 kernel: [12203.423441] [sys_read+0x53/0x90] sys_read+0x53/0x90 Oct 13 14:58:03 app1 kernel: [12203.423447] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.423454] Oct 13 14:58:03 app1 kernel: [12203.423456] sshd S 0000000000000000 0 25897 1 Oct 13 14:58:03 app1 kernel: [12203.423459] ffff81075356be78 0000000000000082 0000000000000000 ffff81087f36d380 Oct 13 14:58:03 app1 kernel: [12203.423463] 0000000000000007 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.423467] ffffffff8067d0a0 ffffffff80680c00 ffff8108515cc230 ffff81075356be44 Oct 13 14:58:03 app1 kernel: [12203.423470] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.423481] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.423487] [do_wait+0x5e7/0xcd0] do_wait+0x5e7/0xcd0 Oct 13 14:58:03 app1 kernel: [12203.423498] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.423505] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.423513] Oct 13 14:58:03 app1 kernel: [12203.423515] aklog S 0000000000000006 0 25898 25897 Oct 13 14:58:03 app1 kernel: [12203.423517] ffff8102400af7b8 0000000000000086 ffff810426950000 0000000000000000 Oct 13 14:58:03 app1 kernel: [12203.423521] 000000000001d660 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.423526] ffffffff8067d0a0 ffffffff80680c00 ffff8101eb816230 000000000000000f Oct 13 14:58:03 app1 kernel: [12203.423529] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.423560] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:03 app1 kernel: [12203.423565] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.423588] [] :openafs:rxi_AllocSendPacket+0x83/0x170 Oct 13 14:58:03 app1 kernel: [12203.423610] [] :openafs:rxi_WriteProc+0x103/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.423630] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:03 app1 kernel: [12203.423652] [] :openafs:rx_WriteProc32+0x59/0xb0 Oct 13 14:58:03 app1 kernel: [12203.423673] [] :openafs:xdrrx_putint32+0x1a/0x30 Oct 13 14:58:03 app1 kernel: [12203.423693] [] :openafs:afs_xdr_int+0x23/0x70 Oct 13 14:58:03 app1 kernel: [12203.423712] [] :openafs:RXAFS_FetchStatus+0x71/0x220 Oct 13 14:58:03 app1 kernel: [12203.423731] [] :openafs:rx_NewConnection+0x18b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.423752] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.423771] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:03 app1 kernel: [12203.423785] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.423803] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:03 app1 kernel: [12203.423823] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:03 app1 kernel: [12203.423846] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:03 app1 kernel: [12203.423866] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:03 app1 kernel: [12203.423890] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:03 app1 kernel: [12203.423896] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:03 app1 kernel: [12203.423902] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:03 app1 kernel: [12203.423911] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:03 app1 kernel: [12203.423919] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.423927] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:03 app1 kernel: [12203.423931] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:03 app1 kernel: [12203.423936] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:03 app1 kernel: [12203.423941] [vfs_stat_fd+0x2f/0x80] vfs_stat_fd+0x2f/0x80 Oct 13 14:58:03 app1 kernel: [12203.423949] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.423954] [sys_newstat+0x27/0x50] sys_newstat+0x27/0x50 Oct 13 14:58:03 app1 kernel: [12203.423957] [ext2:dput+0x1f/0xe10] dput+0x1f/0x130 Oct 13 14:58:03 app1 kernel: [12203.423964] [error_exit+0x0/0x51] error_exit+0x0/0x51 Oct 13 14:58:03 app1 kernel: [12203.423969] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.423977] Oct 13 14:58:03 app1 kernel: [12203.423978] sshd S 0000000000000000 0 26260 1 Oct 13 14:58:03 app1 kernel: [12203.423981] ffff810842911e78 0000000000000082 0000000000000000 ffff81087f645188 Oct 13 14:58:03 app1 kernel: [12203.423985] 0000000000000007 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.423989] ffffffff8067d0a0 ffffffff80680c00 ffff81083e98f9d0 ffff810842911e44 Oct 13 14:58:03 app1 kernel: [12203.423993] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.424003] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.424010] [do_wait+0x5e7/0xcd0] do_wait+0x5e7/0xcd0 Oct 13 14:58:03 app1 kernel: [12203.424021] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.424029] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.424037] Oct 13 14:58:03 app1 kernel: [12203.424038] aklog S 0000000000000006 0 26261 26260 Oct 13 14:58:03 app1 kernel: [12203.424041] ffff8101e81837b8 0000000000000082 ffff810867db8048 ffff810480073c00 Oct 13 14:58:03 app1 kernel: [12203.424045] ffffffff802329d7 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.424049] ffffffff8067d0a0 ffffffff80680c00 ffff81026c5851f0 ffffffff8847f568 Oct 13 14:58:03 app1 kernel: [12203.424053] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.424057] [enqueue_entity+0x37/0x70] enqueue_entity+0x37/0x70 Oct 13 14:58:03 app1 kernel: [12203.424068] [try_to_wake_up+0x66/0x3c0] try_to_wake_up+0x66/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.424090] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:03 app1 kernel: [12203.424096] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.424119] [] :openafs:rxi_AllocSendPacket+0x83/0x170 Oct 13 14:58:03 app1 kernel: [12203.424140] [] :openafs:rxi_WriteProc+0x103/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.424161] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:03 app1 kernel: [12203.424183] [] :openafs:rx_WriteProc32+0x59/0xb0 Oct 13 14:58:03 app1 kernel: [12203.424203] [] :openafs:xdrrx_putint32+0x1a/0x30 Oct 13 14:58:03 app1 kernel: [12203.424223] [] :openafs:afs_xdr_int+0x23/0x70 Oct 13 14:58:03 app1 kernel: [12203.424242] [] :openafs:RXAFS_FetchStatus+0x71/0x220 Oct 13 14:58:03 app1 kernel: [12203.424261] [] :openafs:rx_NewConnection+0x18b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.424281] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.424301] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:03 app1 kernel: [12203.424315] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.424334] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:03 app1 kernel: [12203.424355] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:03 app1 kernel: [12203.424377] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:03 app1 kernel: [12203.424397] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:03 app1 kernel: [12203.424422] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:03 app1 kernel: [12203.424428] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:03 app1 kernel: [12203.424433] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:03 app1 kernel: [12203.424443] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:03 app1 kernel: [12203.424451] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.424458] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:03 app1 kernel: [12203.424462] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:03 app1 kernel: [12203.424467] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:03 app1 kernel: [12203.424472] [vfs_stat_fd+0x2f/0x80] vfs_stat_fd+0x2f/0x80 Oct 13 14:58:03 app1 kernel: [12203.424480] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.424486] [sys_newstat+0x27/0x50] sys_newstat+0x27/0x50 Oct 13 14:58:03 app1 kernel: [12203.424489] [ext2:dput+0x1f/0xe10] dput+0x1f/0x130 Oct 13 14:58:03 app1 kernel: [12203.424497] [error_exit+0x0/0x51] error_exit+0x0/0x51 Oct 13 14:58:03 app1 kernel: [12203.424503] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.424510] Oct 13 14:58:03 app1 kernel: [12203.424512] sshd S 0000000000000000 0 31472 6160 Oct 13 14:58:03 app1 kernel: [12203.424516] ffff8108708819c8 0000000000000086 0000000000000000 0000000000000246 Oct 13 14:58:03 app1 kernel: [12203.424519] ffff8106768151a0 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.424524] ffffffff8067d0a0 ffffffff80680c00 ffff81085951b1f0 ffff810870881994 Oct 13 14:58:03 app1 kernel: [12203.424527] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.424541] [cciss:schedule_timeout+0x5f/0xd0] schedule_timeout+0x5f/0xd0 Oct 13 14:58:03 app1 kernel: [12203.424545] [process_timeout+0x0/0x10] process_timeout+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.424549] [cciss:schedule_timeout+0x5a/0xd0] schedule_timeout+0x5a/0xd0 Oct 13 14:58:03 app1 kernel: [12203.424554] [do_select+0x468/0x570] do_select+0x468/0x570 Oct 13 14:58:03 app1 kernel: [12203.424557] [dst_output+0x0/0x10] dst_output+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.424568] [__pollwait+0x0/0x130] __pollwait+0x0/0x130 Oct 13 14:58:03 app1 kernel: [12203.424573] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.424579] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.424585] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.424591] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.424596] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.424602] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.424608] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.424613] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.424619] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.424625] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.424633] [core_sys_select+0x209/0x300] core_sys_select+0x209/0x300 Oct 13 14:58:03 app1 kernel: [12203.424645] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.424648] [] autoremove_wake_function+0x0/0x30 Oct 13 14:58:03 app1 kernel: [12203.424661] [sys_select+0xd1/0x1c0] sys_select+0xd1/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.424668] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.424676] Oct 13 14:58:03 app1 kernel: [12203.424677] sshd S 0000000000000000 0 31476 31472 Oct 13 14:58:03 app1 kernel: [12203.424681] ffff810671945e78 0000000000000082 8000000264236065 ffff81067fe43d50 Oct 13 14:58:03 app1 kernel: [12203.424685] 0000000000000007 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.424689] ffffffff8067d0a0 ffffffff80680c00 ffff810670d2f9d0 0000000100007af5 Oct 13 14:58:03 app1 kernel: [12203.424692] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.424706] [do_wait+0x5e7/0xcd0] do_wait+0x5e7/0xcd0 Oct 13 14:58:03 app1 kernel: [12203.424717] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.424724] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.424732] Oct 13 14:58:03 app1 kernel: [12203.424734] aklog S 0000000000000000 0 31477 31476 Oct 13 14:58:03 app1 kernel: [12203.424737] ffff8101fe5b57b8 0000000000000086 0000000000000000 ffff810680068c00 Oct 13 14:58:03 app1 kernel: [12203.424740] ffffffff802329d7 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.424745] ffffffff8067d0a0 ffffffff80680c00 ffff81026442b9d0 ffff8101fe5b5784 Oct 13 14:58:03 app1 kernel: [12203.424748] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.424752] [enqueue_entity+0x37/0x70] enqueue_entity+0x37/0x70 Oct 13 14:58:03 app1 kernel: [12203.424762] [try_to_wake_up+0x66/0x3c0] try_to_wake_up+0x66/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.424784] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:03 app1 kernel: [12203.424790] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.424812] [] :openafs:rxi_AllocSendPacket+0x83/0x170 Oct 13 14:58:03 app1 kernel: [12203.424834] [] :openafs:rxi_WriteProc+0x103/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.424854] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:03 app1 kernel: [12203.424876] [] :openafs:rx_WriteProc32+0x59/0xb0 Oct 13 14:58:03 app1 kernel: [12203.424896] [] :openafs:xdrrx_putint32+0x1a/0x30 Oct 13 14:58:03 app1 kernel: [12203.424916] [] :openafs:afs_xdr_int+0x23/0x70 Oct 13 14:58:03 app1 kernel: [12203.424935] [] :openafs:RXAFS_FetchStatus+0x71/0x220 Oct 13 14:58:03 app1 kernel: [12203.424954] [] :openafs:rx_NewConnection+0x18b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.424975] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.424994] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:03 app1 kernel: [12203.425008] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.425025] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:03 app1 kernel: [12203.425046] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:03 app1 kernel: [12203.425068] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:03 app1 kernel: [12203.425089] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:03 app1 kernel: [12203.425113] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:03 app1 kernel: [12203.425119] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:03 app1 kernel: [12203.425124] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:03 app1 kernel: [12203.425133] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:03 app1 kernel: [12203.425139] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.425142] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.425147] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.425154] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:03 app1 kernel: [12203.425158] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:03 app1 kernel: [12203.425163] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:03 app1 kernel: [12203.425168] [vfs_stat_fd+0x2f/0x80] vfs_stat_fd+0x2f/0x80 Oct 13 14:58:03 app1 kernel: [12203.425173] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.425177] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.425181] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.425187] [sys_newstat+0x27/0x50] sys_newstat+0x27/0x50 Oct 13 14:58:03 app1 kernel: [12203.425190] [ext2:dput+0x1f/0xe10] dput+0x1f/0x130 Oct 13 14:58:03 app1 kernel: [12203.425194] [fuse:mntput_no_expire+0x27/0x4bb0] mntput_no_expire+0x27/0xb0 Oct 13 14:58:03 app1 kernel: [12203.425199] [reiserfs:filp_close+0x54/0x3c0] filp_close+0x54/0x90 Oct 13 14:58:03 app1 kernel: [12203.425203] [sys_close+0x9f/0x100] sys_close+0x9f/0x100 Oct 13 14:58:03 app1 kernel: [12203.425207] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.425214] Oct 13 14:58:03 app1 kernel: [12203.425216] sshd S 0000000000000000 0 31596 6160 Oct 13 14:58:03 app1 kernel: [12203.425219] ffff81084dd659c8 0000000000000086 0000000000000000 ffffffff8044cfcc Oct 13 14:58:03 app1 kernel: [12203.425223] e0108d0a00000001 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.425227] ffffffff8067d0a0 ffffffff80680c00 ffff810870472230 ffff81084dd65994 Oct 13 14:58:03 app1 kernel: [12203.425230] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.425234] [fib4_rule_action+0x5c/0x70] fib4_rule_action+0x5c/0x70 Oct 13 14:58:03 app1 kernel: [12203.425248] [cciss:schedule_timeout+0x5f/0xd0] schedule_timeout+0x5f/0xd0 Oct 13 14:58:03 app1 kernel: [12203.425251] [process_timeout+0x0/0x10] process_timeout+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.425255] [cciss:schedule_timeout+0x5a/0xd0] schedule_timeout+0x5a/0xd0 Oct 13 14:58:03 app1 kernel: [12203.425260] [do_select+0x468/0x570] do_select+0x468/0x570 Oct 13 14:58:03 app1 kernel: [12203.425264] [dst_output+0x0/0x10] dst_output+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.425274] [__pollwait+0x0/0x130] __pollwait+0x0/0x130 Oct 13 14:58:03 app1 kernel: [12203.425280] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.425285] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.425291] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.425297] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.425303] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.425309] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.425314] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.425320] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.425326] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.425332] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.425339] [core_sys_select+0x209/0x300] core_sys_select+0x209/0x300 Oct 13 14:58:03 app1 kernel: [12203.425351] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.425354] [] autoremove_wake_function+0x0/0x30 Oct 13 14:58:03 app1 kernel: [12203.425367] [sys_select+0xd1/0x1c0] sys_select+0xd1/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.425375] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.425383] Oct 13 14:58:03 app1 kernel: [12203.425384] sshd S 0000000000000000 0 31597 31596 Oct 13 14:58:03 app1 kernel: [12203.425388] ffff810670c2fe78 0000000000000086 0000000000000000 ffff81067df84470 Oct 13 14:58:03 app1 kernel: [12203.425391] 0000000000000007 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.425396] ffffffff8067d0a0 ffffffff80680c00 ffff81066ccbb1f0 ffff810670c2fe44 Oct 13 14:58:03 app1 kernel: [12203.425399] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.425410] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.425417] [do_wait+0x5e7/0xcd0] do_wait+0x5e7/0xcd0 Oct 13 14:58:03 app1 kernel: [12203.425427] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.425434] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.425442] Oct 13 14:58:03 app1 kernel: [12203.425444] aklog S 0000000000000006 0 31598 31597 Oct 13 14:58:03 app1 kernel: [12203.425448] ffff81084681b7b8 0000000000000086 ffff810426950000 0000000000000000 Oct 13 14:58:03 app1 kernel: [12203.425451] 000000000001d660 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.425456] ffffffff8067d0a0 ffffffff80680c00 ffff8108669e71f0 000000000000000f Oct 13 14:58:03 app1 kernel: [12203.425459] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.425491] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:03 app1 kernel: [12203.425496] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.425519] [] :openafs:rxi_AllocSendPacket+0x83/0x170 Oct 13 14:58:03 app1 kernel: [12203.425541] [] :openafs:rxi_WriteProc+0x103/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.425562] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:03 app1 kernel: [12203.425583] [] :openafs:rx_WriteProc32+0x59/0xb0 Oct 13 14:58:03 app1 kernel: [12203.425604] [] :openafs:xdrrx_putint32+0x1a/0x30 Oct 13 14:58:03 app1 kernel: [12203.425623] [] :openafs:afs_xdr_int+0x23/0x70 Oct 13 14:58:03 app1 kernel: [12203.425643] [] :openafs:RXAFS_FetchStatus+0x71/0x220 Oct 13 14:58:03 app1 kernel: [12203.425662] [] :openafs:rx_NewConnection+0x18b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.425683] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.425703] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:03 app1 kernel: [12203.425716] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.425734] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:03 app1 kernel: [12203.425755] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:03 app1 kernel: [12203.425777] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:03 app1 kernel: [12203.425797] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:03 app1 kernel: [12203.425822] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:03 app1 kernel: [12203.425827] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:03 app1 kernel: [12203.425832] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:03 app1 kernel: [12203.425842] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:03 app1 kernel: [12203.425848] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.425851] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.425856] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.425864] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:03 app1 kernel: [12203.425867] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:03 app1 kernel: [12203.425872] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:03 app1 kernel: [12203.425877] [vfs_stat_fd+0x2f/0x80] vfs_stat_fd+0x2f/0x80 Oct 13 14:58:03 app1 kernel: [12203.425883] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.425887] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.425891] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.425897] [sys_newstat+0x27/0x50] sys_newstat+0x27/0x50 Oct 13 14:58:03 app1 kernel: [12203.425900] [ext2:dput+0x1f/0xe10] dput+0x1f/0x130 Oct 13 14:58:03 app1 kernel: [12203.425904] [fuse:mntput_no_expire+0x27/0x4bb0] mntput_no_expire+0x27/0xb0 Oct 13 14:58:03 app1 kernel: [12203.425908] [reiserfs:filp_close+0x54/0x3c0] filp_close+0x54/0x90 Oct 13 14:58:03 app1 kernel: [12203.425912] [sys_close+0x9f/0x100] sys_close+0x9f/0x100 Oct 13 14:58:03 app1 kernel: [12203.425915] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.425923] Oct 13 14:58:03 app1 kernel: [12203.425925] sshd S 0000000000000000 0 31848 31472 Oct 13 14:58:03 app1 kernel: [12203.425928] ffff810863137e78 0000000000000082 0000000000000000 ffff81087f7fb4e8 Oct 13 14:58:03 app1 kernel: [12203.425932] 0000000000000007 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.425936] ffffffff8067d0a0 ffffffff80680c00 ffff81083e98e230 ffff810863137e44 Oct 13 14:58:03 app1 kernel: [12203.425940] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.425951] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.425958] [do_wait+0x5e7/0xcd0] do_wait+0x5e7/0xcd0 Oct 13 14:58:03 app1 kernel: [12203.425969] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.425976] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.425984] Oct 13 14:58:03 app1 kernel: [12203.425986] aklog S 0000000000000000 0 31849 31848 Oct 13 14:58:03 app1 kernel: [12203.425990] ffff810859d697b8 0000000000000082 0000000000000000 ffff810001044c00 Oct 13 14:58:03 app1 kernel: [12203.425993] ffffffff802329d7 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.425997] ffffffff8067d0a0 ffffffff80680c00 ffff810867db8230 ffff810859d69784 Oct 13 14:58:03 app1 kernel: [12203.426000] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.426005] [enqueue_entity+0x37/0x70] enqueue_entity+0x37/0x70 Oct 13 14:58:03 app1 kernel: [12203.426015] [try_to_wake_up+0x66/0x3c0] try_to_wake_up+0x66/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.426037] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:03 app1 kernel: [12203.426042] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.426064] [] :openafs:rxi_AllocSendPacket+0x83/0x170 Oct 13 14:58:03 app1 kernel: [12203.426086] [] :openafs:rxi_WriteProc+0x103/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.426106] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:03 app1 kernel: [12203.426128] [] :openafs:rx_WriteProc32+0x59/0xb0 Oct 13 14:58:03 app1 kernel: [12203.426148] [] :openafs:xdrrx_putint32+0x1a/0x30 Oct 13 14:58:03 app1 kernel: [12203.426169] [] :openafs:afs_xdr_int+0x23/0x70 Oct 13 14:58:03 app1 kernel: [12203.426188] [] :openafs:RXAFS_FetchStatus+0x71/0x220 Oct 13 14:58:03 app1 kernel: [12203.426207] [] :openafs:rx_NewConnection+0x18b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.426228] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.426247] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:03 app1 kernel: [12203.426262] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.426279] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:03 app1 kernel: [12203.426300] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:03 app1 kernel: [12203.426324] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:03 app1 kernel: [12203.426344] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:03 app1 kernel: [12203.426368] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:03 app1 kernel: [12203.426374] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:03 app1 kernel: [12203.426379] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:03 app1 kernel: [12203.426388] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:03 app1 kernel: [12203.426395] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.426398] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.426402] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.426410] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:03 app1 kernel: [12203.426414] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:03 app1 kernel: [12203.426419] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:03 app1 kernel: [12203.426423] [vfs_stat_fd+0x2f/0x80] vfs_stat_fd+0x2f/0x80 Oct 13 14:58:03 app1 kernel: [12203.426429] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.426433] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.426437] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.426443] [sys_newstat+0x27/0x50] sys_newstat+0x27/0x50 Oct 13 14:58:03 app1 kernel: [12203.426446] [ext2:dput+0x1f/0xe10] dput+0x1f/0x130 Oct 13 14:58:03 app1 kernel: [12203.426450] [fuse:mntput_no_expire+0x27/0x4bb0] mntput_no_expire+0x27/0xb0 Oct 13 14:58:03 app1 kernel: [12203.426454] [reiserfs:filp_close+0x54/0x3c0] filp_close+0x54/0x90 Oct 13 14:58:03 app1 kernel: [12203.426458] [sys_close+0x9f/0x100] sys_close+0x9f/0x100 Oct 13 14:58:03 app1 kernel: [12203.426461] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.426469] Oct 13 14:58:03 app1 kernel: [12203.426471] sshd S 0000000000000000 0 31964 31596 Oct 13 14:58:03 app1 kernel: [12203.426474] ffff810863501e78 0000000000000082 0000000000000000 ffff81087f99f868 Oct 13 14:58:03 app1 kernel: [12203.426478] 0000000000000007 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.426482] ffffffff8067d0a0 ffffffff80680c00 ffff81086688ea10 ffff810863501e44 Oct 13 14:58:03 app1 kernel: [12203.426486] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.426497] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.426504] [do_wait+0x5e7/0xcd0] do_wait+0x5e7/0xcd0 Oct 13 14:58:03 app1 kernel: [12203.426515] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.426522] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.426530] Oct 13 14:58:03 app1 kernel: [12203.426532] aklog S 0000000000000000 0 31965 31964 Oct 13 14:58:03 app1 kernel: [12203.426535] ffff8102644cb7b8 0000000000000086 ffff81000103e800 ffff810001044c00 Oct 13 14:58:03 app1 kernel: [12203.426539] ffffffff802329d7 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.426543] ffffffff8067d0a0 ffffffff80680c00 ffff8102724e59d0 ffffffff8847f568 Oct 13 14:58:03 app1 kernel: [12203.426547] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.426551] [enqueue_entity+0x37/0x70] enqueue_entity+0x37/0x70 Oct 13 14:58:03 app1 kernel: [12203.426561] [try_to_wake_up+0x66/0x3c0] try_to_wake_up+0x66/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.426582] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:03 app1 kernel: [12203.426588] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.426610] [] :openafs:rxi_AllocSendPacket+0x83/0x170 Oct 13 14:58:03 app1 kernel: [12203.426632] [] :openafs:rxi_WriteProc+0x103/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.426652] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:03 app1 kernel: [12203.426674] [] :openafs:rx_WriteProc32+0x59/0xb0 Oct 13 14:58:03 app1 kernel: [12203.426693] [] :openafs:xdrrx_putint32+0x1a/0x30 Oct 13 14:58:03 app1 kernel: [12203.426713] [] :openafs:afs_xdr_int+0x23/0x70 Oct 13 14:58:03 app1 kernel: [12203.426732] [] :openafs:RXAFS_FetchStatus+0x71/0x220 Oct 13 14:58:03 app1 kernel: [12203.426752] [] :openafs:rx_NewConnection+0x18b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.426772] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.426792] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:03 app1 kernel: [12203.426806] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.426823] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:03 app1 kernel: [12203.426844] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:03 app1 kernel: [12203.426866] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:03 app1 kernel: [12203.426887] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:03 app1 kernel: [12203.426911] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:03 app1 kernel: [12203.426917] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:03 app1 kernel: [12203.426922] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:03 app1 kernel: [12203.426932] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:03 app1 kernel: [12203.426937] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.426941] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.426945] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.426953] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:03 app1 kernel: [12203.426957] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:03 app1 kernel: [12203.426961] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:03 app1 kernel: [12203.426966] [vfs_stat_fd+0x2f/0x80] vfs_stat_fd+0x2f/0x80 Oct 13 14:58:03 app1 kernel: [12203.426972] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.426975] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.426979] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.426985] [sys_newstat+0x27/0x50] sys_newstat+0x27/0x50 Oct 13 14:58:03 app1 kernel: [12203.426988] [ext2:dput+0x1f/0xe10] dput+0x1f/0x130 Oct 13 14:58:03 app1 kernel: [12203.426992] [fuse:mntput_no_expire+0x27/0x4bb0] mntput_no_expire+0x27/0xb0 Oct 13 14:58:03 app1 kernel: [12203.426996] [reiserfs:filp_close+0x54/0x3c0] filp_close+0x54/0x90 Oct 13 14:58:03 app1 kernel: [12203.427000] [sys_close+0x9f/0x100] sys_close+0x9f/0x100 Oct 13 14:58:03 app1 kernel: [12203.427004] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.427012] Oct 13 14:58:03 app1 kernel: [12203.427013] in.tftpd S 0000000000000000 0 468 6252 Oct 13 14:58:03 app1 kernel: [12203.427016] ffff81085d1a99c8 0000000000000082 0000000000000000 ffffffff80232f9a Oct 13 14:58:03 app1 kernel: [12203.427021] 001200d200000000 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.427025] ffffffff8067d0a0 ffffffff80680c00 ffff810856d8c230 ffff81085d1a9994 Oct 13 14:58:03 app1 kernel: [12203.427028] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.427032] [find_busiest_group+0x1fa/0x850] find_busiest_group+0x1fa/0x850 Oct 13 14:58:03 app1 kernel: [12203.427046] [cciss:schedule_timeout+0x5f/0xd0] schedule_timeout+0x5f/0xd0 Oct 13 14:58:03 app1 kernel: [12203.427050] [process_timeout+0x0/0x10] process_timeout+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.427054] [cciss:schedule_timeout+0x5a/0xd0] schedule_timeout+0x5a/0xd0 Oct 13 14:58:03 app1 kernel: [12203.427060] [do_select+0x468/0x570] do_select+0x468/0x570 Oct 13 14:58:03 app1 kernel: [12203.427072] [__pollwait+0x0/0x130] __pollwait+0x0/0x130 Oct 13 14:58:03 app1 kernel: [12203.427077] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.427085] [udp_recvmsg+0x222/0x260] udp_recvmsg+0x222/0x260 Oct 13 14:58:03 app1 kernel: [12203.427090] [zone_statistics+0x7d/0x80] zone_statistics+0x7d/0x80 Oct 13 14:58:03 app1 kernel: [12203.427094] [get_page_from_freelist+0x47b/0x6c0] get_page_from_freelist+0x47b/0x6c0 Oct 13 14:58:03 app1 kernel: [12203.427101] [zone_statistics+0x7d/0x80] zone_statistics+0x7d/0x80 Oct 13 14:58:03 app1 kernel: [12203.427111] [__alloc_pages+0x9d/0x3d0] __alloc_pages+0x9d/0x3d0 Oct 13 14:58:03 app1 kernel: [12203.427118] [__alloc_pages+0x9d/0x3d0] __alloc_pages+0x9d/0x3d0 Oct 13 14:58:03 app1 kernel: [12203.427128] [core_sys_select+0x209/0x300] core_sys_select+0x209/0x300 Oct 13 14:58:03 app1 kernel: [12203.427140] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.427144] [do_page_fault+0x1d0/0x840] do_page_fault+0x1d0/0x840 Oct 13 14:58:03 app1 kernel: [12203.427156] [sys_select+0xd1/0x1c0] sys_select+0xd1/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.427163] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.427171] Oct 13 14:58:03 app1 kernel: [12203.427172] nbdrootd S 0000000000000000 0 517 6252 Oct 13 14:58:03 app1 kernel: [12203.427176] ffff8108704e5e78 0000000000000082 0000000000000000 ffff81087fc91e98 Oct 13 14:58:03 app1 kernel: [12203.427179] 0000000000000007 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.427184] ffffffff8067d0a0 ffffffff80680c00 ffff81083a4ee230 ffff8108704e5e44 Oct 13 14:58:03 app1 kernel: [12203.427187] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.427198] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.427204] [do_wait+0x5e7/0xcd0] do_wait+0x5e7/0xcd0 Oct 13 14:58:03 app1 kernel: [12203.427214] [dupfd+0x166/0x1a0] dupfd+0x166/0x1a0 Oct 13 14:58:03 app1 kernel: [12203.427217] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.427225] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.427233] Oct 13 14:58:03 app1 kernel: [12203.427234] nbd-server S 0000000000000000 0 518 517 Oct 13 14:58:03 app1 kernel: [12203.427238] ffff810862101b58 0000000000000086 0000000000000000 0000000100000402 Oct 13 14:58:03 app1 kernel: [12203.427242] ffff810476967000 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.427246] ffffffff8067d0a0 ffffffff80680c00 ffff810847d059d0 ffff810862101b24 Oct 13 14:58:03 app1 kernel: [12203.427250] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.427264] [cciss:schedule_timeout+0x95/0xd0] schedule_timeout+0x95/0xd0 Oct 13 14:58:03 app1 kernel: [12203.427268] [ipv6:lock_sock_nested+0x9c/0xe0] lock_sock_nested+0x9c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.427273] [ipv6:_spin_lock_bh+0x9/0x20] _spin_lock_bh+0x9/0x20 Oct 13 14:58:03 app1 kernel: [12203.427276] [af_packet:release_sock+0x13/0xb0] release_sock+0x13/0xb0 Oct 13 14:58:03 app1 kernel: [12203.427281] [sk_wait_data+0x8a/0xe0] sk_wait_data+0x8a/0xe0 Oct 13 14:58:03 app1 kernel: [12203.427285] [] autoremove_wake_function+0x0/0x30 Oct 13 14:58:03 app1 kernel: [12203.427292] [ipv6:tcp_recvmsg+0x67d/0xd20] tcp_recvmsg+0x67d/0xd20 Oct 13 14:58:03 app1 kernel: [12203.427304] [ipv6:sock_common_recvmsg+0x30/0x50] sock_common_recvmsg+0x30/0x50 Oct 13 14:58:03 app1 kernel: [12203.427309] [sock_aio_read+0x15d/0x170] sock_aio_read+0x15d/0x170 Oct 13 14:58:03 app1 kernel: [12203.427321] [ext2:do_sync_read+0xd9/0xbb0] do_sync_read+0xd9/0x120 Oct 13 14:58:03 app1 kernel: [12203.427329] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.427332] [] autoremove_wake_function+0x0/0x30 Oct 13 14:58:03 app1 kernel: [12203.427345] [vfs_read+0x185/0x190] vfs_read+0x185/0x190 Oct 13 14:58:03 app1 kernel: [12203.427350] [sys_read+0x53/0x90] sys_read+0x53/0x90 Oct 13 14:58:03 app1 kernel: [12203.427355] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.427363] Oct 13 14:58:03 app1 kernel: [12203.427364] aklog S 0000000000000000 0 691 1 Oct 13 14:58:03 app1 kernel: [12203.427368] ffff8101e80c97b8 0000000000000086 0000000000000000 ffff810001044c00 Oct 13 14:58:03 app1 kernel: [12203.427372] ffffffff802329d7 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.427376] ffffffff8067d0a0 ffffffff80680c00 ffff8102031d0230 ffff8101e80c9784 Oct 13 14:58:03 app1 kernel: [12203.427379] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.427383] [enqueue_entity+0x37/0x70] enqueue_entity+0x37/0x70 Oct 13 14:58:03 app1 kernel: [12203.427393] [try_to_wake_up+0x66/0x3c0] try_to_wake_up+0x66/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.427416] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:03 app1 kernel: [12203.427422] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.427444] [] :openafs:rxi_AllocSendPacket+0x83/0x170 Oct 13 14:58:03 app1 kernel: [12203.427465] [] :openafs:rxi_WriteProc+0x103/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.427487] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:03 app1 kernel: [12203.427509] [] :openafs:rx_WriteProc32+0x59/0xb0 Oct 13 14:58:03 app1 kernel: [12203.427529] [] :openafs:xdrrx_putint32+0x1a/0x30 Oct 13 14:58:03 app1 kernel: [12203.427549] [] :openafs:afs_xdr_int+0x23/0x70 Oct 13 14:58:03 app1 kernel: [12203.427568] [] :openafs:RXAFS_FetchStatus+0x71/0x220 Oct 13 14:58:03 app1 kernel: [12203.427587] [] :openafs:rx_NewConnection+0x18b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.427608] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.427627] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:03 app1 kernel: [12203.427641] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.427659] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:03 app1 kernel: [12203.427680] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:03 app1 kernel: [12203.427703] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:03 app1 kernel: [12203.427724] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:03 app1 kernel: [12203.427748] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:03 app1 kernel: [12203.427754] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:03 app1 kernel: [12203.427759] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:03 app1 kernel: [12203.427768] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:03 app1 kernel: [12203.427774] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.427777] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.427782] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.427790] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:03 app1 kernel: [12203.427794] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:03 app1 kernel: [12203.427799] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:03 app1 kernel: [12203.427804] [vfs_stat_fd+0x2f/0x80] vfs_stat_fd+0x2f/0x80 Oct 13 14:58:03 app1 kernel: [12203.427810] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.427813] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.427817] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.427823] [sys_newstat+0x27/0x50] sys_newstat+0x27/0x50 Oct 13 14:58:03 app1 kernel: [12203.427826] [ext2:dput+0x1f/0xe10] dput+0x1f/0x130 Oct 13 14:58:03 app1 kernel: [12203.427830] [fuse:mntput_no_expire+0x27/0x4bb0] mntput_no_expire+0x27/0xb0 Oct 13 14:58:03 app1 kernel: [12203.427835] [reiserfs:filp_close+0x54/0x3c0] filp_close+0x54/0x90 Oct 13 14:58:03 app1 kernel: [12203.427838] [sys_close+0x9f/0x100] sys_close+0x9f/0x100 Oct 13 14:58:03 app1 kernel: [12203.427842] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.427850] Oct 13 14:58:03 app1 kernel: [12203.427852] nbdrootd S 0000000000000000 0 895 6252 Oct 13 14:58:03 app1 kernel: [12203.427855] ffff8108494b3e78 0000000000000086 0000000000000000 ffff81027defa930 Oct 13 14:58:03 app1 kernel: [12203.427859] 0000000000000007 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.427863] ffffffff8067d0a0 ffffffff80680c00 ffff81083d578230 ffff8108494b3e44 Oct 13 14:58:03 app1 kernel: [12203.427866] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.427877] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.427884] [do_wait+0x5e7/0xcd0] do_wait+0x5e7/0xcd0 Oct 13 14:58:03 app1 kernel: [12203.427893] [dupfd+0x166/0x1a0] dupfd+0x166/0x1a0 Oct 13 14:58:03 app1 kernel: [12203.427897] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.427904] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.427912] Oct 13 14:58:03 app1 kernel: [12203.427914] nbd-server S 0000000000000000 0 896 895 Oct 13 14:58:03 app1 kernel: [12203.427917] ffff810211075b58 0000000000000086 0000000000000000 0000000100000402 Oct 13 14:58:03 app1 kernel: [12203.427922] ffff810476967000 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.427926] ffffffff8067d0a0 ffffffff80680c00 ffff810240164a10 ffff810211075b24 Oct 13 14:58:03 app1 kernel: [12203.427930] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.427944] [cciss:schedule_timeout+0x95/0xd0] schedule_timeout+0x95/0xd0 Oct 13 14:58:03 app1 kernel: [12203.427948] [ipv6:lock_sock_nested+0x9c/0xe0] lock_sock_nested+0x9c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.427953] [ipv6:_spin_lock_bh+0x9/0x20] _spin_lock_bh+0x9/0x20 Oct 13 14:58:03 app1 kernel: [12203.427957] [af_packet:release_sock+0x13/0xb0] release_sock+0x13/0xb0 Oct 13 14:58:03 app1 kernel: [12203.427961] [sk_wait_data+0x8a/0xe0] sk_wait_data+0x8a/0xe0 Oct 13 14:58:03 app1 kernel: [12203.427965] [] autoremove_wake_function+0x0/0x30 Oct 13 14:58:03 app1 kernel: [12203.427972] [ipv6:tcp_recvmsg+0x67d/0xd20] tcp_recvmsg+0x67d/0xd20 Oct 13 14:58:03 app1 kernel: [12203.427984] [ipv6:sock_common_recvmsg+0x30/0x50] sock_common_recvmsg+0x30/0x50 Oct 13 14:58:03 app1 kernel: [12203.427990] [sock_aio_read+0x15d/0x170] sock_aio_read+0x15d/0x170 Oct 13 14:58:03 app1 kernel: [12203.428000] [ext2:do_sync_read+0xd9/0xbb0] do_sync_read+0xd9/0x120 Oct 13 14:58:03 app1 kernel: [12203.428009] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.428012] [] autoremove_wake_function+0x0/0x30 Oct 13 14:58:03 app1 kernel: [12203.428025] [vfs_read+0x185/0x190] vfs_read+0x185/0x190 Oct 13 14:58:03 app1 kernel: [12203.428028] [fget_light+0x3d/0xa0] fget_light+0x3d/0xa0 Oct 13 14:58:03 app1 kernel: [12203.428032] [sys_read+0x53/0x90] sys_read+0x53/0x90 Oct 13 14:58:03 app1 kernel: [12203.428037] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.428045] Oct 13 14:58:03 app1 kernel: [12203.428047] sshd S 0000000000000000 0 1718 1 Oct 13 14:58:03 app1 kernel: [12203.428050] ffff81066c143e78 0000000000000082 0000000000000000 ffff81067fb413e8 Oct 13 14:58:03 app1 kernel: [12203.428054] 0000000000000007 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.428058] ffffffff8067d0a0 ffffffff80680c00 ffff8105eb0571f0 ffff81066c143e44 Oct 13 14:58:03 app1 kernel: [12203.428061] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.428071] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.428078] [do_wait+0x5e7/0xcd0] do_wait+0x5e7/0xcd0 Oct 13 14:58:03 app1 kernel: [12203.428089] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.428096] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.428104] Oct 13 14:58:03 app1 kernel: [12203.428105] aklog S 0000000000000006 0 1720 1718 Oct 13 14:58:03 app1 kernel: [12203.428109] ffff8108630977c8 0000000000000086 ffff810863097728 0000000000000000 Oct 13 14:58:03 app1 kernel: [12203.428113] ffff8101e584d800 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.428117] ffffffff8067d0a0 ffffffff80680c00 ffff8107915d39d0 ffffc20000000000 Oct 13 14:58:03 app1 kernel: [12203.428120] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.428144] [] :openafs:afs_mutex_enter+0x9/0x40 Oct 13 14:58:03 app1 kernel: [12203.428169] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:03 app1 kernel: [12203.428175] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.428197] [] :openafs:rxi_ReadProc+0xdf/0x450 Oct 13 14:58:03 app1 kernel: [12203.428218] [] :openafs:rxi_WriteProc+0x2ef/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.428239] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:03 app1 kernel: [12203.428261] [] :openafs:rx_ReadProc32+0x57/0xb0 Oct 13 14:58:03 app1 kernel: [12203.428282] [] :openafs:xdrrx_getint32+0x16/0x40 Oct 13 14:58:03 app1 kernel: [12203.428301] [] :openafs:xdr_AFSFetchStatus+0x19/0x1b0 Oct 13 14:58:03 app1 kernel: [12203.428320] [] :openafs:RXAFS_FetchStatus+0x1bb/0x220 Oct 13 14:58:03 app1 kernel: [12203.428340] [] :openafs:rx_NewConnection+0x18b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.428360] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.428379] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:03 app1 kernel: [12203.428393] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.428411] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:03 app1 kernel: [12203.428432] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:03 app1 kernel: [12203.428454] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:03 app1 kernel: [12203.428475] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:03 app1 kernel: [12203.428499] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:03 app1 kernel: [12203.428505] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:03 app1 kernel: [12203.428510] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:03 app1 kernel: [12203.428520] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:03 app1 kernel: [12203.428525] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.428529] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.428532] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.428540] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:03 app1 kernel: [12203.428545] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:03 app1 kernel: [12203.428549] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:03 app1 kernel: [12203.428554] [vfs_stat_fd+0x2f/0x80] vfs_stat_fd+0x2f/0x80 Oct 13 14:58:03 app1 kernel: [12203.428560] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.428563] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.428567] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.428572] [sys_newstat+0x27/0x50] sys_newstat+0x27/0x50 Oct 13 14:58:03 app1 kernel: [12203.428576] [ext2:dput+0x1f/0xe10] dput+0x1f/0x130 Oct 13 14:58:03 app1 kernel: [12203.428580] [fuse:mntput_no_expire+0x27/0x4bb0] mntput_no_expire+0x27/0xb0 Oct 13 14:58:03 app1 kernel: [12203.428584] [reiserfs:filp_close+0x54/0x3c0] filp_close+0x54/0x90 Oct 13 14:58:03 app1 kernel: [12203.428588] [sys_close+0x9f/0x100] sys_close+0x9f/0x100 Oct 13 14:58:03 app1 kernel: [12203.428593] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.428601] Oct 13 14:58:03 app1 kernel: [12203.428603] sshd S 0000000000000003 0 2087 1 Oct 13 14:58:03 app1 kernel: [12203.428607] ffff81060fd6de78 0000000000000086 800000072c456065 ffff81067fba0748 Oct 13 14:58:03 app1 kernel: [12203.428610] 0000000000000007 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.428615] ffffffff8067d0a0 ffffffff80680c00 ffff81067341aa10 0000000100000828 Oct 13 14:58:03 app1 kernel: [12203.428618] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.428629] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.428635] [do_wait+0x5e7/0xcd0] do_wait+0x5e7/0xcd0 Oct 13 14:58:03 app1 kernel: [12203.428646] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.428653] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.428661] Oct 13 14:58:03 app1 kernel: [12203.428662] aklog S 0000000000000000 0 2088 2087 Oct 13 14:58:03 app1 kernel: [12203.428666] ffff810856c317b8 0000000000000086 0000000000000000 0000000000000000 Oct 13 14:58:03 app1 kernel: [12203.428670] 000000000001d660 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.428675] ffffffff8067d0a0 ffffffff80680c00 ffff8107915d2a10 ffff810856c31784 Oct 13 14:58:03 app1 kernel: [12203.428678] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.428708] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:03 app1 kernel: [12203.428714] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.428737] [] :openafs:rxi_AllocSendPacket+0x83/0x170 Oct 13 14:58:03 app1 kernel: [12203.428759] [] :openafs:rxi_WriteProc+0x103/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.428779] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:03 app1 kernel: [12203.428800] [] :openafs:rx_WriteProc32+0x59/0xb0 Oct 13 14:58:03 app1 kernel: [12203.428821] [] :openafs:xdrrx_putint32+0x1a/0x30 Oct 13 14:58:03 app1 kernel: [12203.428841] [] :openafs:afs_xdr_int+0x23/0x70 Oct 13 14:58:03 app1 kernel: [12203.428860] [] :openafs:RXAFS_FetchStatus+0x71/0x220 Oct 13 14:58:03 app1 kernel: [12203.428879] [] :openafs:rx_NewConnection+0x18b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.428900] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.428920] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:03 app1 kernel: [12203.428934] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.428951] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:03 app1 kernel: [12203.428972] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:03 app1 kernel: [12203.428996] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:03 app1 kernel: [12203.429016] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:03 app1 kernel: [12203.429040] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:03 app1 kernel: [12203.429046] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:03 app1 kernel: [12203.429051] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:03 app1 kernel: [12203.429061] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:03 app1 kernel: [12203.429066] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.429070] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.429075] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.429082] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:03 app1 kernel: [12203.429086] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:03 app1 kernel: [12203.429091] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:03 app1 kernel: [12203.429096] [vfs_stat_fd+0x2f/0x80] vfs_stat_fd+0x2f/0x80 Oct 13 14:58:03 app1 kernel: [12203.429101] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.429105] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.429109] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.429115] [sys_newstat+0x27/0x50] sys_newstat+0x27/0x50 Oct 13 14:58:03 app1 kernel: [12203.429118] [ext2:dput+0x1f/0xe10] dput+0x1f/0x130 Oct 13 14:58:03 app1 kernel: [12203.429122] [fuse:mntput_no_expire+0x27/0x4bb0] mntput_no_expire+0x27/0xb0 Oct 13 14:58:03 app1 kernel: [12203.429126] [reiserfs:filp_close+0x54/0x3c0] filp_close+0x54/0x90 Oct 13 14:58:03 app1 kernel: [12203.429129] [sys_close+0x9f/0x100] sys_close+0x9f/0x100 Oct 13 14:58:03 app1 kernel: [12203.429133] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.429141] Oct 13 14:58:03 app1 kernel: [12203.429143] sshd S 0000000000000000 0 2108 1 Oct 13 14:58:03 app1 kernel: [12203.429146] ffff81085b1b9e78 0000000000000086 0000000000000000 ffff81087f407f50 Oct 13 14:58:03 app1 kernel: [12203.429150] 0000000000000007 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.429154] ffffffff8067d0a0 ffffffff80680c00 ffff810863182a10 ffff81085b1b9e44 Oct 13 14:58:03 app1 kernel: [12203.429158] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.429169] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.429176] [do_wait+0x5e7/0xcd0] do_wait+0x5e7/0xcd0 Oct 13 14:58:03 app1 kernel: [12203.429187] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.429195] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.429202] Oct 13 14:58:03 app1 kernel: [12203.429204] aklog S 0000000000000000 0 2109 2108 Oct 13 14:58:03 app1 kernel: [12203.429208] ffff8101e55617b8 0000000000000082 0000000000000000 ffff810001044c00 Oct 13 14:58:03 app1 kernel: [12203.429211] ffffffff802329d7 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.429216] ffffffff8067d0a0 ffffffff80680c00 ffff8101e6d9aa10 ffff8101e5561784 Oct 13 14:58:03 app1 kernel: [12203.429219] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.429223] [enqueue_entity+0x37/0x70] enqueue_entity+0x37/0x70 Oct 13 14:58:03 app1 kernel: [12203.429233] [try_to_wake_up+0x66/0x3c0] try_to_wake_up+0x66/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.429254] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:03 app1 kernel: [12203.429260] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.429282] [] :openafs:rxi_AllocSendPacket+0x83/0x170 Oct 13 14:58:03 app1 kernel: [12203.429304] [] :openafs:rxi_WriteProc+0x103/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.429324] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:03 app1 kernel: [12203.429346] [] :openafs:rx_WriteProc32+0x59/0xb0 Oct 13 14:58:03 app1 kernel: [12203.429365] [] :openafs:xdrrx_putint32+0x1a/0x30 Oct 13 14:58:03 app1 kernel: [12203.429385] [] :openafs:afs_xdr_int+0x23/0x70 Oct 13 14:58:03 app1 kernel: [12203.429405] [] :openafs:RXAFS_FetchStatus+0x71/0x220 Oct 13 14:58:03 app1 kernel: [12203.429424] [] :openafs:rx_NewConnection+0x18b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.429445] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.429464] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:03 app1 kernel: [12203.429478] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.429496] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:03 app1 kernel: [12203.429517] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:03 app1 kernel: [12203.429520] [apparmor_inode_permission+0x0/0x60] apparmor_inode_permission+0x0/0x60 Oct 13 14:58:03 app1 kernel: [12203.429541] [] :openafs:afs_EvalFakeStat_int+0x270/0x3a0 Oct 13 14:58:03 app1 kernel: [12203.429560] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:03 app1 kernel: [12203.429580] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:03 app1 kernel: [12203.429604] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:03 app1 kernel: [12203.429610] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:03 app1 kernel: [12203.429615] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:03 app1 kernel: [12203.429625] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:03 app1 kernel: [12203.429630] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.429634] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.429639] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.429646] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:03 app1 kernel: [12203.429650] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:03 app1 kernel: [12203.429655] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:03 app1 kernel: [12203.429660] [vfs_stat_fd+0x2f/0x80] vfs_stat_fd+0x2f/0x80 Oct 13 14:58:03 app1 kernel: [12203.429665] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.429669] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.429673] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.429678] [sys_newstat+0x27/0x50] sys_newstat+0x27/0x50 Oct 13 14:58:03 app1 kernel: [12203.429682] [ext2:dput+0x1f/0xe10] dput+0x1f/0x130 Oct 13 14:58:03 app1 kernel: [12203.429685] [fuse:mntput_no_expire+0x27/0x4bb0] mntput_no_expire+0x27/0xb0 Oct 13 14:58:03 app1 kernel: [12203.429690] [reiserfs:filp_close+0x54/0x3c0] filp_close+0x54/0x90 Oct 13 14:58:03 app1 kernel: [12203.429693] [sys_close+0x9f/0x100] sys_close+0x9f/0x100 Oct 13 14:58:03 app1 kernel: [12203.429697] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.429705] Oct 13 14:58:03 app1 kernel: [12203.429706] sshd S 0000000000000004 0 2496 1 Oct 13 14:58:03 app1 kernel: [12203.429709] ffff8102110f5e78 0000000000000082 800000026cfc3065 ffff81027e7b84a8 Oct 13 14:58:03 app1 kernel: [12203.429714] 0000000000000007 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.429717] ffffffff8067d0a0 ffffffff80680c00 ffff81023f40d1f0 00000001000009c1 Oct 13 14:58:03 app1 kernel: [12203.429721] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.429732] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.429739] [do_wait+0x5e7/0xcd0] do_wait+0x5e7/0xcd0 Oct 13 14:58:03 app1 kernel: [12203.429751] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.429758] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.429766] Oct 13 14:58:03 app1 kernel: [12203.429767] aklog S 0000000000000000 0 2499 2496 Oct 13 14:58:03 app1 kernel: [12203.429770] ffff8102598997b8 0000000000000086 0000000000000000 ffff810001044c00 Oct 13 14:58:03 app1 kernel: [12203.429774] ffffffff802329d7 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.429778] ffffffff8067d0a0 ffffffff80680c00 ffff81022aebf9d0 ffff810259899784 Oct 13 14:58:03 app1 kernel: [12203.429782] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.429786] [enqueue_entity+0x37/0x70] enqueue_entity+0x37/0x70 Oct 13 14:58:03 app1 kernel: [12203.429796] [try_to_wake_up+0x66/0x3c0] try_to_wake_up+0x66/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.429817] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:03 app1 kernel: [12203.429824] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.429846] [] :openafs:rxi_AllocSendPacket+0x83/0x170 Oct 13 14:58:03 app1 kernel: [12203.429868] [] :openafs:rxi_WriteProc+0x103/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.429889] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:03 app1 kernel: [12203.429910] [] :openafs:rx_WriteProc32+0x59/0xb0 Oct 13 14:58:03 app1 kernel: [12203.429930] [] :openafs:xdrrx_putint32+0x1a/0x30 Oct 13 14:58:03 app1 kernel: [12203.429950] [] :openafs:afs_xdr_int+0x23/0x70 Oct 13 14:58:03 app1 kernel: [12203.429970] [] :openafs:RXAFS_FetchStatus+0x71/0x220 Oct 13 14:58:03 app1 kernel: [12203.429989] [] :openafs:rx_NewConnection+0x18b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.430010] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.430029] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:03 app1 kernel: [12203.430044] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.430061] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:03 app1 kernel: [12203.430082] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:03 app1 kernel: [12203.430105] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:03 app1 kernel: [12203.430125] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:03 app1 kernel: [12203.430149] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:03 app1 kernel: [12203.430155] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:03 app1 kernel: [12203.430160] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:03 app1 kernel: [12203.430169] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:03 app1 kernel: [12203.430175] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.430178] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.430182] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.430189] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:03 app1 kernel: [12203.430193] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:03 app1 kernel: [12203.430198] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:03 app1 kernel: [12203.430203] [vfs_stat_fd+0x2f/0x80] vfs_stat_fd+0x2f/0x80 Oct 13 14:58:03 app1 kernel: [12203.430209] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.430212] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.430216] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.430221] [sys_newstat+0x27/0x50] sys_newstat+0x27/0x50 Oct 13 14:58:03 app1 kernel: [12203.430225] [ext2:dput+0x1f/0xe10] dput+0x1f/0x130 Oct 13 14:58:03 app1 kernel: [12203.430229] [fuse:mntput_no_expire+0x27/0x4bb0] mntput_no_expire+0x27/0xb0 Oct 13 14:58:03 app1 kernel: [12203.430234] [reiserfs:filp_close+0x54/0x3c0] filp_close+0x54/0x90 Oct 13 14:58:03 app1 kernel: [12203.430237] [sys_close+0x9f/0x100] sys_close+0x9f/0x100 Oct 13 14:58:03 app1 kernel: [12203.430242] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.430249] Oct 13 14:58:03 app1 kernel: [12203.430251] nbdrootd S 0000000000000000 0 2798 6252 Oct 13 14:58:03 app1 kernel: [12203.430255] ffff8108448d1e78 0000000000000082 0000000000000000 ffff81087f575610 Oct 13 14:58:03 app1 kernel: [12203.430259] 0000000000000007 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.430263] ffffffff8067d0a0 ffffffff80680c00 ffff8108594db1f0 ffff8108448d1e44 Oct 13 14:58:03 app1 kernel: [12203.430266] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.430277] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.430283] [do_wait+0x5e7/0xcd0] do_wait+0x5e7/0xcd0 Oct 13 14:58:03 app1 kernel: [12203.430294] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.430302] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.430309] Oct 13 14:58:03 app1 kernel: [12203.430311] nbd-server S 0000000000000000 0 2799 2798 Oct 13 14:58:03 app1 kernel: [12203.430314] ffff8107959a7b58 0000000000000082 0000000000000000 0000000100000402 Oct 13 14:58:03 app1 kernel: [12203.430319] ffff810476967000 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.430323] ffffffff8067d0a0 ffffffff80680c00 ffff81083b5e4a10 ffff8107959a7b24 Oct 13 14:58:03 app1 kernel: [12203.430326] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.430341] [cciss:schedule_timeout+0x95/0xd0] schedule_timeout+0x95/0xd0 Oct 13 14:58:03 app1 kernel: [12203.430346] [ipv6:lock_sock_nested+0x9c/0xe0] lock_sock_nested+0x9c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.430351] [ipv6:_spin_lock_bh+0x9/0x20] _spin_lock_bh+0x9/0x20 Oct 13 14:58:03 app1 kernel: [12203.430354] [af_packet:release_sock+0x13/0xb0] release_sock+0x13/0xb0 Oct 13 14:58:03 app1 kernel: [12203.430359] [sk_wait_data+0x8a/0xe0] sk_wait_data+0x8a/0xe0 Oct 13 14:58:03 app1 kernel: [12203.430362] [] autoremove_wake_function+0x0/0x30 Oct 13 14:58:03 app1 kernel: [12203.430369] [ipv6:tcp_recvmsg+0x67d/0xd20] tcp_recvmsg+0x67d/0xd20 Oct 13 14:58:03 app1 kernel: [12203.430381] [ipv6:sock_common_recvmsg+0x30/0x50] sock_common_recvmsg+0x30/0x50 Oct 13 14:58:03 app1 kernel: [12203.430386] [sock_aio_read+0x15d/0x170] sock_aio_read+0x15d/0x170 Oct 13 14:58:03 app1 kernel: [12203.430397] [ext2:do_sync_read+0xd9/0xbb0] do_sync_read+0xd9/0x120 Oct 13 14:58:03 app1 kernel: [12203.430405] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.430409] [] autoremove_wake_function+0x0/0x30 Oct 13 14:58:03 app1 kernel: [12203.430421] [vfs_read+0x185/0x190] vfs_read+0x185/0x190 Oct 13 14:58:03 app1 kernel: [12203.430424] [sys_read+0x9/0x90] sys_read+0x9/0x90 Oct 13 14:58:03 app1 kernel: [12203.430428] [sys_read+0x53/0x90] sys_read+0x53/0x90 Oct 13 14:58:03 app1 kernel: [12203.430434] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.430442] Oct 13 14:58:03 app1 kernel: [12203.430443] nbdrootd S 0000000000000000 0 2950 6252 Oct 13 14:58:03 app1 kernel: [12203.430448] ffff810863101e78 0000000000000082 0000000000000000 ffff81087f6618c0 Oct 13 14:58:03 app1 kernel: [12203.430452] 0000000000000007 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.430457] ffffffff8067d0a0 ffffffff80680c00 ffff810838884a10 ffff810863101e44 Oct 13 14:58:03 app1 kernel: [12203.430460] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.430470] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.430477] [do_wait+0x5e7/0xcd0] do_wait+0x5e7/0xcd0 Oct 13 14:58:03 app1 kernel: [12203.430488] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.430494] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.430502] Oct 13 14:58:03 app1 kernel: [12203.430503] nbd-server S 0000000000000000 0 2951 2950 Oct 13 14:58:03 app1 kernel: [12203.430508] ffff810843423b58 0000000000000086 0000000000000000 0000000100000402 Oct 13 14:58:03 app1 kernel: [12203.430512] ffff81084cc7cc00 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.430515] ffffffff8067d0a0 ffffffff80680c00 ffff8108538f6230 ffff810843423b24 Oct 13 14:58:03 app1 kernel: [12203.430519] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.430534] [cciss:schedule_timeout+0x95/0xd0] schedule_timeout+0x95/0xd0 Oct 13 14:58:03 app1 kernel: [12203.430538] [ipv6:lock_sock_nested+0x9c/0xe0] lock_sock_nested+0x9c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.430543] [ipv6:_spin_lock_bh+0x9/0x20] _spin_lock_bh+0x9/0x20 Oct 13 14:58:03 app1 kernel: [12203.430547] [af_packet:release_sock+0x13/0xb0] release_sock+0x13/0xb0 Oct 13 14:58:03 app1 kernel: [12203.430551] [sk_wait_data+0x8a/0xe0] sk_wait_data+0x8a/0xe0 Oct 13 14:58:03 app1 kernel: [12203.430555] [] autoremove_wake_function+0x0/0x30 Oct 13 14:58:03 app1 kernel: [12203.430562] [ipv6:tcp_recvmsg+0x67d/0xd20] tcp_recvmsg+0x67d/0xd20 Oct 13 14:58:03 app1 kernel: [12203.430574] [ipv6:sock_common_recvmsg+0x30/0x50] sock_common_recvmsg+0x30/0x50 Oct 13 14:58:03 app1 kernel: [12203.430580] [sock_aio_read+0x15d/0x170] sock_aio_read+0x15d/0x170 Oct 13 14:58:03 app1 kernel: [12203.430591] [ext2:do_sync_read+0xd9/0xbb0] do_sync_read+0xd9/0x120 Oct 13 14:58:03 app1 kernel: [12203.430599] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.430603] [] autoremove_wake_function+0x0/0x30 Oct 13 14:58:03 app1 kernel: [12203.430611] [aa_file_permission+0x32/0xf0] aa_file_permission+0x32/0xf0 Oct 13 14:58:03 app1 kernel: [12203.430619] [vfs_read+0x185/0x190] vfs_read+0x185/0x190 Oct 13 14:58:03 app1 kernel: [12203.430621] [sys_lseek+0x2f/0x90] sys_lseek+0x2f/0x90 Oct 13 14:58:03 app1 kernel: [12203.430626] [sys_read+0x53/0x90] sys_read+0x53/0x90 Oct 13 14:58:03 app1 kernel: [12203.430631] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.430639] Oct 13 14:58:03 app1 kernel: [12203.430641] sshd S 0000000000000000 0 4476 6160 Oct 13 14:58:03 app1 kernel: [12203.430644] ffff8106731b39c8 0000000000000086 0000000000000000 ffffffff8044cfcc Oct 13 14:58:03 app1 kernel: [12203.430649] ec058d0a00000001 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.430652] ffffffff8067d0a0 ffffffff80680c00 ffff810670d2f1f0 ffff8106731b3994 Oct 13 14:58:03 app1 kernel: [12203.430656] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.430660] [fib4_rule_action+0x5c/0x70] fib4_rule_action+0x5c/0x70 Oct 13 14:58:03 app1 kernel: [12203.430674] [cciss:schedule_timeout+0x5f/0xd0] schedule_timeout+0x5f/0xd0 Oct 13 14:58:03 app1 kernel: [12203.430677] [process_timeout+0x0/0x10] process_timeout+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.430681] [cciss:schedule_timeout+0x5a/0xd0] schedule_timeout+0x5a/0xd0 Oct 13 14:58:03 app1 kernel: [12203.430686] [do_select+0x468/0x570] do_select+0x468/0x570 Oct 13 14:58:03 app1 kernel: [12203.430689] [dst_output+0x0/0x10] dst_output+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.430700] [__pollwait+0x0/0x130] __pollwait+0x0/0x130 Oct 13 14:58:03 app1 kernel: [12203.430705] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.430711] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.430716] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.430722] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.430727] [ipv6:_spin_lock_bh+0x9/0x20] _spin_lock_bh+0x9/0x20 Oct 13 14:58:03 app1 kernel: [12203.430730] [af_packet:release_sock+0x13/0xb0] release_sock+0x13/0xb0 Oct 13 14:58:03 app1 kernel: [12203.430734] [ipv6:tcp_recvmsg+0x5b7/0xd20] tcp_recvmsg+0x5b7/0xd20 Oct 13 14:58:03 app1 kernel: [12203.430747] [ipv6:sock_common_recvmsg+0x30/0x50] sock_common_recvmsg+0x30/0x50 Oct 13 14:58:03 app1 kernel: [12203.430752] [sock_aio_read+0x15d/0x170] sock_aio_read+0x15d/0x170 Oct 13 14:58:03 app1 kernel: [12203.430759] [core_sys_select+0x209/0x300] core_sys_select+0x209/0x300 Oct 13 14:58:03 app1 kernel: [12203.430771] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.430775] [] autoremove_wake_function+0x0/0x30 Oct 13 14:58:03 app1 kernel: [12203.430784] [tty_ldisc_deref+0x52/0x80] tty_ldisc_deref+0x52/0x80 Oct 13 14:58:03 app1 kernel: [12203.430792] [sys_select+0xd1/0x1c0] sys_select+0xd1/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.430799] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.430807] Oct 13 14:58:03 app1 kernel: [12203.430808] sshd S 0000000000000000 0 4498 4476 Oct 13 14:58:03 app1 kernel: [12203.430812] ffff81061f855e78 0000000000000086 0000000000000000 ffff81067e7b8cf8 Oct 13 14:58:03 app1 kernel: [12203.430816] 0000000000000007 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.430820] ffffffff8067d0a0 ffffffff80680c00 ffff810676c5f9d0 ffff81061f855e44 Oct 13 14:58:03 app1 kernel: [12203.430823] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.430834] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.430841] [do_wait+0x5e7/0xcd0] do_wait+0x5e7/0xcd0 Oct 13 14:58:03 app1 kernel: [12203.430852] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.430859] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.430867] Oct 13 14:58:03 app1 kernel: [12203.430869] aklog S 0000000000000000 0 4499 4498 Oct 13 14:58:03 app1 kernel: [12203.430872] ffff8103fb4617b8 0000000000000086 0000000000000000 ffff810280073c00 Oct 13 14:58:03 app1 kernel: [12203.430876] ffffffff802329d7 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.430879] ffffffff8067d0a0 ffffffff80680c00 ffff8103fa8f11f0 ffff8103fb461784 Oct 13 14:58:03 app1 kernel: [12203.430883] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.430887] [enqueue_entity+0x37/0x70] enqueue_entity+0x37/0x70 Oct 13 14:58:03 app1 kernel: [12203.430897] [try_to_wake_up+0x66/0x3c0] try_to_wake_up+0x66/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.430918] [] :openafs:afs_cv_wait+0xee/0x280 Oct 13 14:58:03 app1 kernel: [12203.430924] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.430947] [] :openafs:rxi_AllocSendPacket+0x83/0x170 Oct 13 14:58:03 app1 kernel: [12203.430969] [] :openafs:rxi_WriteProc+0x103/0x3c0 Oct 13 14:58:03 app1 kernel: [12203.430990] [] :openafs:rxi_ScheduleKeepAliveEvent+0x61/0x70 Oct 13 14:58:03 app1 kernel: [12203.431012] [] :openafs:rx_WriteProc32+0x59/0xb0 Oct 13 14:58:03 app1 kernel: [12203.431033] [] :openafs:xdrrx_putint32+0x1a/0x30 Oct 13 14:58:03 app1 kernel: [12203.431053] [] :openafs:afs_xdr_int+0x23/0x70 Oct 13 14:58:03 app1 kernel: [12203.431072] [] :openafs:RXAFS_FetchStatus+0x71/0x220 Oct 13 14:58:03 app1 kernel: [12203.431091] [] :openafs:rx_NewConnection+0x18b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.431112] [] :openafs:afs_Conn+0x14b/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.431132] [] :openafs:afs_FetchStatus+0xf0/0x570 Oct 13 14:58:03 app1 kernel: [12203.431146] [] :openafs:afs_choose_cell_by_num+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.431163] [] :openafs:afs_IsPrimaryCell+0x20/0x50 Oct 13 14:58:03 app1 kernel: [12203.431185] [] :openafs:afs_GetAccessBits+0xe5/0x100 Oct 13 14:58:03 app1 kernel: [12203.431207] [] :openafs:afs_AccessOK+0xed/0x1a0 Oct 13 14:58:03 app1 kernel: [12203.431228] [] :openafs:afs_access+0x3c4/0x420 Oct 13 14:58:03 app1 kernel: [12203.431252] [] :openafs:afs_linux_permission+0x66/0xe0 Oct 13 14:58:03 app1 kernel: [12203.431258] [permission+0xb0/0x160] permission+0xb0/0x160 Oct 13 14:58:03 app1 kernel: [12203.431263] [__link_path_walk+0x87/0xe90] __link_path_walk+0x87/0xe90 Oct 13 14:58:03 app1 kernel: [12203.431273] [link_path_walk+0x5b/0x100] link_path_walk+0x5b/0x100 Oct 13 14:58:03 app1 kernel: [12203.431278] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.431282] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.431286] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.431294] [do_path_lookup+0x8a/0x250] do_path_lookup+0x8a/0x250 Oct 13 14:58:03 app1 kernel: [12203.431298] [getname+0x1a9/0x220] getname+0x1a9/0x220 Oct 13 14:58:03 app1 kernel: [12203.431303] [__user_walk_fd+0x4b/0x80] __user_walk_fd+0x4b/0x80 Oct 13 14:58:03 app1 kernel: [12203.431308] [vfs_stat_fd+0x2f/0x80] vfs_stat_fd+0x2f/0x80 Oct 13 14:58:03 app1 kernel: [12203.431313] [invalidate_inode_buffers+0x2a/0x100] invalidate_inode_buffers+0x2a/0x100 Oct 13 14:58:03 app1 kernel: [12203.431317] [jbd:bit_waitqueue+0x1c/0xe0] bit_waitqueue+0x1c/0xb0 Oct 13 14:58:03 app1 kernel: [12203.431321] [jbd:wake_up_bit+0x18/0x40] wake_up_bit+0x18/0x40 Oct 13 14:58:03 app1 kernel: [12203.431326] [sys_newstat+0x27/0x50] sys_newstat+0x27/0x50 Oct 13 14:58:03 app1 kernel: [12203.431330] [ext2:dput+0x1f/0xe10] dput+0x1f/0x130 Oct 13 14:58:03 app1 kernel: [12203.431333] [fuse:mntput_no_expire+0x27/0x4bb0] mntput_no_expire+0x27/0xb0 Oct 13 14:58:03 app1 kernel: [12203.431338] [reiserfs:filp_close+0x54/0x3c0] filp_close+0x54/0x90 Oct 13 14:58:03 app1 kernel: [12203.431341] [sys_close+0x9f/0x100] sys_close+0x9f/0x100 Oct 13 14:58:03 app1 kernel: [12203.431345] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.431353] Oct 13 14:58:03 app1 kernel: [12203.431354] sshd S 0000000000000000 0 4563 6160 Oct 13 14:58:03 app1 kernel: [12203.431358] ffff81084bc579c8 0000000000000086 0000000000000000 0000000000000246 Oct 13 14:58:03 app1 kernel: [12203.431362] ffff8106768151a0 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.431366] ffffffff8067d0a0 ffffffff80680c00 ffff81085b8d79d0 ffff81084bc57994 Oct 13 14:58:03 app1 kernel: [12203.431370] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.431385] [cciss:schedule_timeout+0x5f/0xd0] schedule_timeout+0x5f/0xd0 Oct 13 14:58:03 app1 kernel: [12203.431389] [process_timeout+0x0/0x10] process_timeout+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.431393] [cciss:schedule_timeout+0x5a/0xd0] schedule_timeout+0x5a/0xd0 Oct 13 14:58:03 app1 kernel: [12203.431398] [do_select+0x468/0x570] do_select+0x468/0x570 Oct 13 14:58:03 app1 kernel: [12203.431402] [dst_output+0x0/0x10] dst_output+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.431412] [__pollwait+0x0/0x130] __pollwait+0x0/0x130 Oct 13 14:58:03 app1 kernel: [12203.431418] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.431423] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.431429] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.431435] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.431442] [ipv6:__alloc_skb+0x96/0x4f0] __alloc_skb+0x96/0x160 Oct 13 14:58:03 app1 kernel: [12203.431446] [ipv6:_spin_lock_bh+0x9/0x20] _spin_lock_bh+0x9/0x20 Oct 13 14:58:03 app1 kernel: [12203.431449] [af_packet:release_sock+0x13/0xb0] release_sock+0x13/0xb0 Oct 13 14:58:03 app1 kernel: [12203.431454] [ipv6:tcp_sendmsg+0x76e/0xde0] tcp_sendmsg+0x76e/0xc30 Oct 13 14:58:03 app1 kernel: [12203.431467] [sock_aio_write+0x14e/0x160] sock_aio_write+0x14e/0x160 Oct 13 14:58:03 app1 kernel: [12203.431474] [core_sys_select+0x209/0x300] core_sys_select+0x209/0x300 Oct 13 14:58:03 app1 kernel: [12203.431486] [] autoremove_wake_function+0x0/0x30 Oct 13 14:58:03 app1 kernel: [12203.431494] [current_fs_time+0x1e/0x30] current_fs_time+0x1e/0x30 Oct 13 14:58:03 app1 kernel: [12203.431498] [tty_ldisc_deref+0x52/0x80] tty_ldisc_deref+0x52/0x80 Oct 13 14:58:03 app1 kernel: [12203.431506] [sys_select+0xd1/0x1c0] sys_select+0xd1/0x1c0 Oct 13 14:58:03 app1 kernel: [12203.431513] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.431521] Oct 13 14:58:03 app1 kernel: [12203.431522] bash S 0000000000000000 0 4570 4563 Oct 13 14:58:03 app1 kernel: [12203.431526] ffff810856cf3e78 0000000000000086 0000000000000000 ffff81027e8ff720 Oct 13 14:58:03 app1 kernel: [12203.431530] 0000000000000007 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.431534] ffffffff8067d0a0 ffffffff80680c00 ffff81085b8d6a10 ffff810856cf3e44 Oct 13 14:58:03 app1 kernel: [12203.431538] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.431548] [__up_read+0x21/0xb0] __up_read+0x21/0xb0 Oct 13 14:58:03 app1 kernel: [12203.431555] [do_wait+0x5e7/0xcd0] do_wait+0x5e7/0xcd0 Oct 13 14:58:03 app1 kernel: [12203.431564] [recalc_sigpending+0xe/0x40] recalc_sigpending+0xe/0x40 Oct 13 14:58:03 app1 kernel: [12203.431567] [fuse:sigprocmask+0x67/0x1630] sigprocmask+0x67/0xf0 Oct 13 14:58:03 app1 kernel: [12203.431571] [] default_wake_function+0x0/0x10 Oct 13 14:58:03 app1 kernel: [12203.431574] [sys_ioctl+0x91/0xb0] sys_ioctl+0x91/0xb0 Oct 13 14:58:03 app1 kernel: [12203.431579] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.431587] Oct 13 14:58:03 app1 kernel: [12203.431588] sh ? 0000000000000000 0 5202 2874 Oct 13 14:58:03 app1 kernel: [12203.431592] ffff81024d81fee8 0000000000000046 0000000000000000 0000000000000011 Oct 13 14:58:03 app1 kernel: [12203.431596] ffff810854917048 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.431600] ffffffff8067d0a0 ffffffff80680c00 ffff8101eb610230 ffff81024d81feb4 Oct 13 14:58:03 app1 kernel: [12203.431604] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.431614] [reiserfs:filp_close+0x54/0x3c0] filp_close+0x54/0x90 Oct 13 14:58:03 app1 kernel: [12203.431621] [do_exit+0x63b/0x950] do_exit+0x63b/0x950 Oct 13 14:58:03 app1 kernel: [12203.431629] [do_group_exit+0x2c/0x80] do_group_exit+0x2c/0x80 Oct 13 14:58:03 app1 kernel: [12203.431633] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.431641] Oct 13 14:58:03 app1 kernel: [12203.431643] sh ? 0000000000000000 0 5214 15692 Oct 13 14:58:03 app1 kernel: [12203.431646] ffff8104261a7ee8 0000000000000046 0000000000000000 0000000000000011 Oct 13 14:58:03 app1 kernel: [12203.431649] ffff810235c73048 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.431654] ffffffff8067d0a0 ffffffff80680c00 ffff81046fcef9d0 ffff8104261a7eb4 Oct 13 14:58:03 app1 kernel: [12203.431657] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.431672] [do_exit+0x63b/0x950] do_exit+0x63b/0x950 Oct 13 14:58:03 app1 kernel: [12203.431680] [do_group_exit+0x2c/0x80] do_group_exit+0x2c/0x80 Oct 13 14:58:03 app1 kernel: [12203.431685] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.431692] Oct 13 14:58:03 app1 kernel: [12203.431694] sh ? 0000000000000000 0 5229 1046 Oct 13 14:58:03 app1 kernel: [12203.431698] ffff81085887dee8 0000000000000046 0000000000000000 0000000000000011 Oct 13 14:58:03 app1 kernel: [12203.431701] ffff810856cf6808 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.431705] ffffffff8067d0a0 ffffffff80680c00 ffff810863072a10 ffff81085887deb4 Oct 13 14:58:03 app1 kernel: [12203.431708] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.431719] [reiserfs:filp_close+0x54/0x3c0] filp_close+0x54/0x90 Oct 13 14:58:03 app1 kernel: [12203.431725] [do_exit+0x63b/0x950] do_exit+0x63b/0x950 Oct 13 14:58:03 app1 kernel: [12203.431733] [do_group_exit+0x2c/0x80] do_group_exit+0x2c/0x80 Oct 13 14:58:03 app1 kernel: [12203.431737] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.431745] Oct 13 14:58:03 app1 kernel: [12203.431747] sh ? 0000000000000000 0 5233 8711 Oct 13 14:58:03 app1 kernel: [12203.431750] ffff81025a90bee8 0000000000000046 0000000000000000 0000000000000011 Oct 13 14:58:03 app1 kernel: [12203.431753] ffff81061102b048 ffffffff80680c00 ffffffff80680c00 ffffffff80680c00 Oct 13 14:58:03 app1 kernel: [12203.431758] ffffffff8067d0a0 ffffffff80680c00 ffff8101eb6119d0 ffff81025a90beb4 Oct 13 14:58:03 app1 kernel: [12203.431761] Call Trace: Oct 13 14:58:03 app1 kernel: [12203.431771] [reiserfs:filp_close+0x54/0x3c0] filp_close+0x54/0x90 Oct 13 14:58:03 app1 kernel: [12203.431778] [do_exit+0x63b/0x950] do_exit+0x63b/0x950 Oct 13 14:58:03 app1 kernel: [12203.431786] [do_group_exit+0x2c/0x80] do_group_exit+0x2c/0x80 Oct 13 14:58:03 app1 kernel: [12203.431790] [system_call+0x7e/0x83] system_call+0x7e/0x83 Oct 13 14:58:03 app1 kernel: [12203.431798] Oct 13 14:58:03 app1 kernel: [12203.431801] bash R running task 0 5239 4570 Oct 13 14:58:03 app1 kernel: [12203.431808] Sched Debug Version: v0.07, 2.6.24-19-server #1 Oct 13 14:58:03 app1 kernel: [12203.431810] now at 23704556.368794 msecs Oct 13 14:58:03 app1 kernel: [12203.431811] .sysctl_sched_latency : 80.000000 Oct 13 14:58:03 app1 kernel: [12203.431813] .sysctl_sched_min_granularity : 16.000000 Oct 13 14:58:03 app1 kernel: [12203.431816] .sysctl_sched_wakeup_granularity : 40.000000 Oct 13 14:58:03 app1 kernel: [12203.431818] .sysctl_sched_batch_wakeup_granularity : 40.000000 Oct 13 14:58:03 app1 kernel: [12203.431820] .sysctl_sched_child_runs_first : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.431822] .sysctl_sched_features : 7 Oct 13 14:58:03 app1 kernel: [12203.431825] Oct 13 14:58:03 app1 kernel: [12203.431825] cpu#0, 2210.184 MHz Oct 13 14:58:03 app1 kernel: [12203.431827] .nr_running : 2 Oct 13 14:58:03 app1 kernel: [12203.431829] .load : 2048 Oct 13 14:58:03 app1 kernel: [12203.431830] .nr_switches : 56715174 Oct 13 14:58:03 app1 kernel: [12203.431833] .nr_load_updates : 2370013 Oct 13 14:58:03 app1 kernel: [12203.431834] .nr_uninterruptible : 24001 Oct 13 14:58:03 app1 kernel: [12203.431836] .jiffies : 4297307680 Oct 13 14:58:03 app1 kernel: [12203.431838] .next_balance : 4297.307681 Oct 13 14:58:03 app1 kernel: [12203.431840] .curr->pid : 2874 Oct 13 14:58:03 app1 kernel: [12203.431842] .clock : 23700130.016122 Oct 13 14:58:03 app1 kernel: [12203.431844] .idle_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.431846] .prev_clock_raw : 12203105.459108 Oct 13 14:58:03 app1 kernel: [12203.431848] .clock_warps : 0 Oct 13 14:58:03 app1 kernel: [12203.431849] .clock_overflows : 16662 Oct 13 14:58:03 app1 kernel: [12203.431851] .clock_deep_idle_events : 0 Oct 13 14:58:03 app1 kernel: [12203.431852] .clock_max_delta : 9.999998 Oct 13 14:58:03 app1 kernel: [12203.431854] .cpu_load[0] : 0 Oct 13 14:58:03 app1 kernel: [12203.431856] .cpu_load[1] : 64 Oct 13 14:58:03 app1 kernel: [12203.431858] .cpu_load[2] : 328 Oct 13 14:58:03 app1 kernel: [12203.431859] .cpu_load[3] : 656 Oct 13 14:58:03 app1 kernel: [12203.431860] .cpu_load[4] : 1185 Oct 13 14:58:03 app1 kernel: [12203.431862] Oct 13 14:58:03 app1 kernel: [12203.431863] cfs_rq Oct 13 14:58:03 app1 kernel: [12203.431865] .exec_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.431867] .MIN_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.431868] .min_vruntime : 3435714.752787 Oct 13 14:58:03 app1 kernel: [12203.431870] .max_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.431872] .spread : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.431874] .spread0 : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.431875] .nr_running : 1 Oct 13 14:58:03 app1 kernel: [12203.431877] .load : 1024 Oct 13 14:58:03 app1 kernel: [12203.431878] .nr_spread_over : 0 Oct 13 14:58:03 app1 kernel: [12203.431880] Oct 13 14:58:03 app1 kernel: [12203.431881] cfs_rq Oct 13 14:58:03 app1 kernel: [12203.431882] .exec_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.431884] .MIN_vruntime : 7189518.617383 Oct 13 14:58:03 app1 kernel: [12203.431886] .min_vruntime : 3435714.752787 Oct 13 14:58:03 app1 kernel: [12203.431888] .max_vruntime : 7189518.617383 Oct 13 14:58:03 app1 kernel: [12203.431890] .spread : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.431891] .spread0 : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.431893] .nr_running : 2 Oct 13 14:58:03 app1 kernel: [12203.431894] .load : 2048 Oct 13 14:58:03 app1 kernel: [12203.431897] .nr_spread_over : 0 Oct 13 14:58:03 app1 kernel: [12203.431899] Oct 13 14:58:03 app1 kernel: [12203.431899] runnable tasks: Oct 13 14:58:03 app1 kernel: [12203.431900] task PID tree-key switches prio exec-runtime sum-exec sum-sleep Oct 13 14:58:03 app1 kernel: [12203.431901] ---------------------------------------------------------------------------------------------------------- Oct 13 14:58:03 app1 kernel: [12203.431922] afs_rxlistener 6478 7189518.617383 25066227 120 0 0 0.000000 0.000000 0.000000 Oct 13 14:58:03 app1 kernel: [12203.431960] R python 2874 7189518.570499 9438 120 0 0 0.000000 0.000000 0.000000 Oct 13 14:58:03 app1 kernel: [12203.432122] Oct 13 14:58:03 app1 kernel: [12203.432123] cpu#1, 2210.184 MHz Oct 13 14:58:03 app1 kernel: [12203.432125] .nr_running : 1 Oct 13 14:58:03 app1 kernel: [12203.432127] .load : 1024 Oct 13 14:58:03 app1 kernel: [12203.432129] .nr_switches : 9396473 Oct 13 14:58:03 app1 kernel: [12203.432130] .nr_load_updates : 2171489 Oct 13 14:58:03 app1 kernel: [12203.432132] .nr_uninterruptible : 20354 Oct 13 14:58:03 app1 kernel: [12203.432134] .jiffies : 4297307680 Oct 13 14:58:03 app1 kernel: [12203.432136] .next_balance : 4297.307687 Oct 13 14:58:03 app1 kernel: [12203.432138] .curr->pid : 10147 Oct 13 14:58:03 app1 kernel: [12203.432139] .clock : 21714890.243543 Oct 13 14:58:03 app1 kernel: [12203.432142] .idle_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.432144] .prev_clock_raw : 14253098.201978 Oct 13 14:58:03 app1 kernel: [12203.432145] .clock_warps : 0 Oct 13 14:58:03 app1 kernel: [12203.432147] .clock_overflows : 293470 Oct 13 14:58:03 app1 kernel: [12203.432148] .clock_deep_idle_events : 0 Oct 13 14:58:03 app1 kernel: [12203.432150] .clock_max_delta : 9.999932 Oct 13 14:58:03 app1 kernel: [12203.432152] .cpu_load[0] : 1024 Oct 13 14:58:03 app1 kernel: [12203.432154] .cpu_load[1] : 1024 Oct 13 14:58:03 app1 kernel: [12203.432155] .cpu_load[2] : 1024 Oct 13 14:58:03 app1 kernel: [12203.432157] .cpu_load[3] : 1028 Oct 13 14:58:03 app1 kernel: [12203.432159] .cpu_load[4] : 1248 Oct 13 14:58:03 app1 kernel: [12203.432160] Oct 13 14:58:03 app1 kernel: [12203.432161] cfs_rq Oct 13 14:58:03 app1 kernel: [12203.432162] .exec_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.432164] .MIN_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.432165] .min_vruntime : 7292503.365933 Oct 13 14:58:03 app1 kernel: [12203.432168] .max_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.432169] .spread : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.432171] .spread0 : 3856788.613146 Oct 13 14:58:03 app1 kernel: [12203.432172] .nr_running : 1 Oct 13 14:58:03 app1 kernel: [12203.432174] .load : 1024 Oct 13 14:58:03 app1 kernel: [12203.432176] .nr_spread_over : 0 Oct 13 14:58:03 app1 kernel: [12203.432178] Oct 13 14:58:03 app1 kernel: [12203.432178] cfs_rq Oct 13 14:58:03 app1 kernel: [12203.432180] .exec_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.432181] .MIN_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.432183] .min_vruntime : 7292503.365933 Oct 13 14:58:03 app1 kernel: [12203.432185] .max_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.432187] .spread : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.432188] .spread0 : 3856788.613146 Oct 13 14:58:03 app1 kernel: [12203.432190] .nr_running : 1 Oct 13 14:58:03 app1 kernel: [12203.432192] .load : 1024 Oct 13 14:58:03 app1 kernel: [12203.432193] .nr_spread_over : 0 Oct 13 14:58:03 app1 kernel: [12203.432196] Oct 13 14:58:03 app1 kernel: [12203.432196] runnable tasks: Oct 13 14:58:03 app1 kernel: [12203.432197] task PID tree-key switches prio exec-runtime sum-exec sum-sleep Oct 13 14:58:03 app1 kernel: [12203.432198] ---------------------------------------------------------------------------------------------------------- Oct 13 14:58:03 app1 kernel: [12203.432343] R firefox 10147 10648285.677712 160547 120 0 0 0.000000 0.000000 0.000000 Oct 13 14:58:03 app1 kernel: [12203.432412] Oct 13 14:58:03 app1 kernel: [12203.432412] cpu#2, 2210.184 MHz Oct 13 14:58:03 app1 kernel: [12203.432414] .nr_running : 1 Oct 13 14:58:03 app1 kernel: [12203.432416] .load : 1024 Oct 13 14:58:03 app1 kernel: [12203.432418] .nr_switches : 12544414 Oct 13 14:58:03 app1 kernel: [12203.432419] .nr_load_updates : 1997686 Oct 13 14:58:03 app1 kernel: [12203.432421] .nr_uninterruptible : 20135 Oct 13 14:58:03 app1 kernel: [12203.432423] .jiffies : 4297307680 Oct 13 14:58:03 app1 kernel: [12203.432425] .next_balance : 4297.307694 Oct 13 14:58:03 app1 kernel: [12203.432427] .curr->pid : 7669 Oct 13 14:58:03 app1 kernel: [12203.432429] .clock : 19976860.421703 Oct 13 14:58:03 app1 kernel: [12203.432431] .idle_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.432433] .prev_clock_raw : 14631239.597985 Oct 13 14:58:03 app1 kernel: [12203.432435] .clock_warps : 0 Oct 13 14:58:03 app1 kernel: [12203.432437] .clock_overflows : 493192 Oct 13 14:58:03 app1 kernel: [12203.432438] .clock_deep_idle_events : 0 Oct 13 14:58:03 app1 kernel: [12203.432440] .clock_max_delta : 9.999875 Oct 13 14:58:03 app1 kernel: [12203.432442] .cpu_load[0] : 1024 Oct 13 14:58:03 app1 kernel: [12203.432444] .cpu_load[1] : 1024 Oct 13 14:58:03 app1 kernel: [12203.432445] .cpu_load[2] : 1024 Oct 13 14:58:03 app1 kernel: [12203.432446] .cpu_load[3] : 1024 Oct 13 14:58:03 app1 kernel: [12203.432448] .cpu_load[4] : 1039 Oct 13 14:58:03 app1 kernel: [12203.432450] Oct 13 14:58:03 app1 kernel: [12203.432451] cfs_rq Oct 13 14:58:03 app1 kernel: [12203.432452] .exec_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.432454] .MIN_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.432455] .min_vruntime : 8191169.783160 Oct 13 14:58:03 app1 kernel: [12203.432457] .max_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.432459] .spread : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.432461] .spread0 : 4755455.030373 Oct 13 14:58:03 app1 kernel: [12203.432462] .nr_running : 1 Oct 13 14:58:03 app1 kernel: [12203.432464] .load : 1024 Oct 13 14:58:03 app1 kernel: [12203.432465] .nr_spread_over : 0 Oct 13 14:58:03 app1 kernel: [12203.432467] Oct 13 14:58:03 app1 kernel: [12203.432468] cfs_rq Oct 13 14:58:03 app1 kernel: [12203.432469] .exec_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.432471] .MIN_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.432473] .min_vruntime : 8191169.783160 Oct 13 14:58:03 app1 kernel: [12203.432475] .max_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.432476] .spread : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.432478] .spread0 : 4755455.030373 Oct 13 14:58:03 app1 kernel: [12203.432479] .nr_running : 1 Oct 13 14:58:03 app1 kernel: [12203.432481] .load : 1024 Oct 13 14:58:03 app1 kernel: [12203.432483] .nr_spread_over : 0 Oct 13 14:58:03 app1 kernel: [12203.432485] Oct 13 14:58:03 app1 kernel: [12203.432486] runnable tasks: Oct 13 14:58:03 app1 kernel: [12203.432486] task PID tree-key switches prio exec-runtime sum-exec sum-sleep Oct 13 14:58:03 app1 kernel: [12203.432488] ---------------------------------------------------------------------------------------------------------- Oct 13 14:58:03 app1 kernel: [12203.432615] R firefox 7669 10064790.239766 69519 120 0 0 0.000000 0.000000 0.000000 Oct 13 14:58:03 app1 kernel: [12203.432699] Oct 13 14:58:03 app1 kernel: [12203.432700] cpu#3, 2210.184 MHz Oct 13 14:58:03 app1 kernel: [12203.432701] .nr_running : 2 Oct 13 14:58:03 app1 kernel: [12203.432703] .load : 1024 Oct 13 14:58:03 app1 kernel: [12203.432706] .nr_switches : 11368226 Oct 13 14:58:03 app1 kernel: [12203.432707] .nr_load_updates : 1912109 Oct 13 14:58:03 app1 kernel: [12203.432709] .nr_uninterruptible : 24284 Oct 13 14:58:03 app1 kernel: [12203.432711] .jiffies : 4297307680 Oct 13 14:58:03 app1 kernel: [12203.432712] .next_balance : 4297.307703 Oct 13 14:58:03 app1 kernel: [12203.432715] .curr->pid : 6083 Oct 13 14:58:03 app1 kernel: [12203.432716] .clock : 19121093.346442 Oct 13 14:58:03 app1 kernel: [12203.432718] .idle_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.432720] .prev_clock_raw : 11708950.245763 Oct 13 14:58:03 app1 kernel: [12203.432722] .clock_warps : 0 Oct 13 14:58:03 app1 kernel: [12203.432724] .clock_overflows : 470897 Oct 13 14:58:03 app1 kernel: [12203.432725] .clock_deep_idle_events : 0 Oct 13 14:58:03 app1 kernel: [12203.432727] .clock_max_delta : 9.999980 Oct 13 14:58:03 app1 kernel: [12203.432729] .cpu_load[0] : 2048 Oct 13 14:58:03 app1 kernel: [12203.432731] .cpu_load[1] : 1940 Oct 13 14:58:03 app1 kernel: [12203.432733] .cpu_load[2] : 1763 Oct 13 14:58:03 app1 kernel: [12203.432734] .cpu_load[3] : 1683 Oct 13 14:58:03 app1 kernel: [12203.432736] .cpu_load[4] : 1619 Oct 13 14:58:03 app1 kernel: [12203.432737] Oct 13 14:58:03 app1 kernel: [12203.432738] cfs_rq Oct 13 14:58:03 app1 kernel: [12203.432740] .exec_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.432742] .MIN_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.432744] .min_vruntime : 2542548.053692 Oct 13 14:58:03 app1 kernel: [12203.432746] .max_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.432748] .spread : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.432750] .spread0 : -893166.699095 Oct 13 14:58:03 app1 kernel: [12203.432751] .nr_running : 1 Oct 13 14:58:03 app1 kernel: [12203.432753] .load : 1024 Oct 13 14:58:03 app1 kernel: [12203.432754] .nr_spread_over : 0 Oct 13 14:58:03 app1 kernel: [12203.432757] Oct 13 14:58:03 app1 kernel: [12203.432757] cfs_rq Oct 13 14:58:03 app1 kernel: [12203.432759] .exec_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.432761] .MIN_vruntime : 6576267.358654 Oct 13 14:58:03 app1 kernel: [12203.432762] .min_vruntime : 2542548.070990 Oct 13 14:58:03 app1 kernel: [12203.432765] .max_vruntime : 6576267.358654 Oct 13 14:58:03 app1 kernel: [12203.432766] .spread : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.432768] .spread0 : -893166.681797 Oct 13 14:58:03 app1 kernel: [12203.432770] .nr_running : 1 Oct 13 14:58:03 app1 kernel: [12203.432771] .load : 1024 Oct 13 14:58:03 app1 kernel: [12203.432774] .nr_spread_over : 0 Oct 13 14:58:03 app1 kernel: [12203.432776] Oct 13 14:58:03 app1 kernel: [12203.432776] runnable tasks: Oct 13 14:58:03 app1 kernel: [12203.432777] task PID tree-key switches prio exec-runtime sum-exec sum-sleep Oct 13 14:58:03 app1 kernel: [12203.432778] ---------------------------------------------------------------------------------------------------------- Oct 13 14:58:03 app1 kernel: [12203.432791] dd 6083 6576267.377924 84298 120 0 0 0.000000 0.000000 0.000000 Oct 13 14:58:03 app1 kernel: [12203.432990] Oct 13 14:58:03 app1 kernel: [12203.432991] cpu#4, 2210.184 MHz Oct 13 14:58:03 app1 kernel: [12203.432993] .nr_running : 1 Oct 13 14:58:03 app1 kernel: [12203.432994] .load : 1024 Oct 13 14:58:03 app1 kernel: [12203.432996] .nr_switches : 11397454 Oct 13 14:58:03 app1 kernel: [12203.432997] .nr_load_updates : 1610385 Oct 13 14:58:03 app1 kernel: [12203.432999] .nr_uninterruptible : -21880 Oct 13 14:58:03 app1 kernel: [12203.433001] .jiffies : 4297307680 Oct 13 14:58:03 app1 kernel: [12203.433002] .next_balance : 4297.307678 Oct 13 14:58:03 app1 kernel: [12203.433004] .curr->pid : 5239 Oct 13 14:58:03 app1 kernel: [12203.433005] .clock : 16103860.674051 Oct 13 14:58:03 app1 kernel: [12203.433007] .idle_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433009] .prev_clock_raw : 12203431.800673 Oct 13 14:58:03 app1 kernel: [12203.433010] .clock_warps : 0 Oct 13 14:58:03 app1 kernel: [12203.433012] .clock_overflows : 784227 Oct 13 14:58:03 app1 kernel: [12203.433013] .clock_deep_idle_events : 0 Oct 13 14:58:03 app1 kernel: [12203.433015] .clock_max_delta : 9.999906 Oct 13 14:58:03 app1 kernel: [12203.433017] .cpu_load[0] : 0 Oct 13 14:58:03 app1 kernel: [12203.433018] .cpu_load[1] : 0 Oct 13 14:58:03 app1 kernel: [12203.433019] .cpu_load[2] : 0 Oct 13 14:58:03 app1 kernel: [12203.433021] .cpu_load[3] : 0 Oct 13 14:58:03 app1 kernel: [12203.433022] .cpu_load[4] : 0 Oct 13 14:58:03 app1 kernel: [12203.433023] Oct 13 14:58:03 app1 kernel: [12203.433024] cfs_rq Oct 13 14:58:03 app1 kernel: [12203.433025] .exec_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433027] .MIN_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.433028] .min_vruntime : 4013150.318447 Oct 13 14:58:03 app1 kernel: [12203.433030] .max_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.433031] .spread : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433033] .spread0 : 577435.565660 Oct 13 14:58:03 app1 kernel: [12203.433034] .nr_running : 1 Oct 13 14:58:03 app1 kernel: [12203.433036] .load : 1024 Oct 13 14:58:03 app1 kernel: [12203.433037] .nr_spread_over : 0 Oct 13 14:58:03 app1 kernel: [12203.433039] Oct 13 14:58:03 app1 kernel: [12203.433039] cfs_rq Oct 13 14:58:03 app1 kernel: [12203.433040] .exec_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433042] .MIN_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.433044] .min_vruntime : 4013150.318447 Oct 13 14:58:03 app1 kernel: [12203.433045] .max_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.433047] .spread : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433048] .spread0 : 577435.565660 Oct 13 14:58:03 app1 kernel: [12203.433050] .nr_running : 1 Oct 13 14:58:03 app1 kernel: [12203.433051] .load : 1024 Oct 13 14:58:03 app1 kernel: [12203.433053] .nr_spread_over : 0 Oct 13 14:58:03 app1 kernel: [12203.433055] Oct 13 14:58:03 app1 kernel: [12203.433055] runnable tasks: Oct 13 14:58:03 app1 kernel: [12203.433056] task PID tree-key switches prio exec-runtime sum-exec sum-sleep Oct 13 14:58:03 app1 kernel: [12203.433057] ---------------------------------------------------------------------------------------------------------- Oct 13 14:58:03 app1 kernel: [12203.433266] R bash 5239 4809337.514843 9 120 0 0 0.000000 0.000000 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433273] Oct 13 14:58:03 app1 kernel: [12203.433273] cpu#5, 2210.184 MHz Oct 13 14:58:03 app1 kernel: [12203.433275] .nr_running : 0 Oct 13 14:58:03 app1 kernel: [12203.433276] .load : 0 Oct 13 14:58:03 app1 kernel: [12203.433279] .nr_switches : 9952331 Oct 13 14:58:03 app1 kernel: [12203.433280] .nr_load_updates : 2369742 Oct 13 14:58:03 app1 kernel: [12203.433282] .nr_uninterruptible : -24405 Oct 13 14:58:03 app1 kernel: [12203.433284] .jiffies : 4297307680 Oct 13 14:58:03 app1 kernel: [12203.433286] .next_balance : 4297.307681 Oct 13 14:58:03 app1 kernel: [12203.433289] .curr->pid : 0 Oct 13 14:58:03 app1 kernel: [12203.433290] .clock : 23697420.005253 Oct 13 14:58:03 app1 kernel: [12203.433292] .idle_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433295] .prev_clock_raw : 14253153.488668 Oct 13 14:58:03 app1 kernel: [12203.433297] .clock_warps : 0 Oct 13 14:58:03 app1 kernel: [12203.433298] .clock_overflows : 6983 Oct 13 14:58:03 app1 kernel: [12203.433300] .clock_deep_idle_events : 0 Oct 13 14:58:03 app1 kernel: [12203.433303] .clock_max_delta : 9.999989 Oct 13 14:58:03 app1 kernel: [12203.433304] .cpu_load[0] : 0 Oct 13 14:58:03 app1 kernel: [12203.433306] .cpu_load[1] : 0 Oct 13 14:58:03 app1 kernel: [12203.433307] .cpu_load[2] : 0 Oct 13 14:58:03 app1 kernel: [12203.433309] .cpu_load[3] : 0 Oct 13 14:58:03 app1 kernel: [12203.433311] .cpu_load[4] : 0 Oct 13 14:58:03 app1 kernel: [12203.433312] Oct 13 14:58:03 app1 kernel: [12203.433312] cfs_rq Oct 13 14:58:03 app1 kernel: [12203.433314] .exec_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433315] .MIN_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.433317] .min_vruntime : 3222841.733075 Oct 13 14:58:03 app1 kernel: [12203.433320] .max_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.433321] .spread : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433323] .spread0 : -212873.019712 Oct 13 14:58:03 app1 kernel: [12203.433324] .nr_running : 0 Oct 13 14:58:03 app1 kernel: [12203.433325] .load : 0 Oct 13 14:58:03 app1 kernel: [12203.433328] .nr_spread_over : 0 Oct 13 14:58:03 app1 kernel: [12203.433329] Oct 13 14:58:03 app1 kernel: [12203.433330] cfs_rq Oct 13 14:58:03 app1 kernel: [12203.433331] .exec_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433333] .MIN_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.433334] .min_vruntime : 3222841.733075 Oct 13 14:58:03 app1 kernel: [12203.433337] .max_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.433338] .spread : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433340] .spread0 : -212873.019712 Oct 13 14:58:03 app1 kernel: [12203.433341] .nr_running : 0 Oct 13 14:58:03 app1 kernel: [12203.433343] .load : 0 Oct 13 14:58:03 app1 kernel: [12203.433345] .nr_spread_over : 0 Oct 13 14:58:03 app1 kernel: [12203.433347] Oct 13 14:58:03 app1 kernel: [12203.433348] runnable tasks: Oct 13 14:58:03 app1 kernel: [12203.433348] task PID tree-key switches prio exec-runtime sum-exec sum-sleep Oct 13 14:58:03 app1 kernel: [12203.433350] ---------------------------------------------------------------------------------------------------------- Oct 13 14:58:03 app1 kernel: [12203.433554] Oct 13 14:58:03 app1 kernel: [12203.433555] cpu#6, 2210.184 MHz Oct 13 14:58:03 app1 kernel: [12203.433557] .nr_running : 0 Oct 13 14:58:03 app1 kernel: [12203.433559] .load : 0 Oct 13 14:58:03 app1 kernel: [12203.433561] .nr_switches : 33412471 Oct 13 14:58:03 app1 kernel: [12203.433562] .nr_load_updates : 1794329 Oct 13 14:58:03 app1 kernel: [12203.433565] .nr_uninterruptible : -16570 Oct 13 14:58:03 app1 kernel: [12203.433566] .jiffies : 4297307680 Oct 13 14:58:03 app1 kernel: [12203.433568] .next_balance : 4297.307681 Oct 13 14:58:03 app1 kernel: [12203.433570] .curr->pid : 0 Oct 13 14:58:03 app1 kernel: [12203.433571] .clock : 17943292.358016 Oct 13 14:58:03 app1 kernel: [12203.433574] .idle_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433575] .prev_clock_raw : 14631289.355101 Oct 13 14:58:03 app1 kernel: [12203.433577] .clock_warps : 0 Oct 13 14:58:03 app1 kernel: [12203.433579] .clock_overflows : 2477802 Oct 13 14:58:03 app1 kernel: [12203.433580] .clock_deep_idle_events : 0 Oct 13 14:58:03 app1 kernel: [12203.433582] .clock_max_delta : 9.999964 Oct 13 14:58:03 app1 kernel: [12203.433584] .cpu_load[0] : 0 Oct 13 14:58:03 app1 kernel: [12203.433586] .cpu_load[1] : 0 Oct 13 14:58:03 app1 kernel: [12203.433588] .cpu_load[2] : 0 Oct 13 14:58:03 app1 kernel: [12203.433589] .cpu_load[3] : 0 Oct 13 14:58:03 app1 kernel: [12203.433590] .cpu_load[4] : 6 Oct 13 14:58:03 app1 kernel: [12203.433591] Oct 13 14:58:03 app1 kernel: [12203.433592] cfs_rq Oct 13 14:58:03 app1 kernel: [12203.433593] .exec_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433596] .MIN_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.433597] .min_vruntime : 4871587.063338 Oct 13 14:58:03 app1 kernel: [12203.433599] .max_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.433600] .spread : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433602] .spread0 : 1435872.310551 Oct 13 14:58:03 app1 kernel: [12203.433604] .nr_running : 0 Oct 13 14:58:03 app1 kernel: [12203.433606] .load : 0 Oct 13 14:58:03 app1 kernel: [12203.433607] .nr_spread_over : 0 Oct 13 14:58:03 app1 kernel: [12203.433609] Oct 13 14:58:03 app1 kernel: [12203.433609] cfs_rq Oct 13 14:58:03 app1 kernel: [12203.433610] .exec_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433613] .MIN_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.433615] .min_vruntime : 4871587.063338 Oct 13 14:58:03 app1 kernel: [12203.433616] .max_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.433618] .spread : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433619] .spread0 : 1435872.310551 Oct 13 14:58:03 app1 kernel: [12203.433622] .nr_running : 0 Oct 13 14:58:03 app1 kernel: [12203.433623] .load : 0 Oct 13 14:58:03 app1 kernel: [12203.433625] .nr_spread_over : 0 Oct 13 14:58:03 app1 kernel: [12203.433627] Oct 13 14:58:03 app1 kernel: [12203.433627] runnable tasks: Oct 13 14:58:03 app1 kernel: [12203.433628] task PID tree-key switches prio exec-runtime sum-exec sum-sleep Oct 13 14:58:03 app1 kernel: [12203.433630] ---------------------------------------------------------------------------------------------------------- Oct 13 14:58:03 app1 kernel: [12203.433835] Oct 13 14:58:03 app1 kernel: [12203.433836] cpu#7, 2210.184 MHz Oct 13 14:58:03 app1 kernel: [12203.433837] .nr_running : 0 Oct 13 14:58:03 app1 kernel: [12203.433839] .load : 0 Oct 13 14:58:03 app1 kernel: [12203.433841] .nr_switches : 15489442 Oct 13 14:58:03 app1 kernel: [12203.433842] .nr_load_updates : 1562754 Oct 13 14:58:03 app1 kernel: [12203.433844] .nr_uninterruptible : -25878 Oct 13 14:58:03 app1 kernel: [12203.433846] .jiffies : 4297307680 Oct 13 14:58:03 app1 kernel: [12203.433847] .next_balance : 4297.307681 Oct 13 14:58:03 app1 kernel: [12203.433849] .curr->pid : 0 Oct 13 14:58:03 app1 kernel: [12203.433850] .clock : 15627545.809225 Oct 13 14:58:03 app1 kernel: [12203.433852] .idle_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433855] .prev_clock_raw : 11708942.593540 Oct 13 14:58:03 app1 kernel: [12203.433857] .clock_warps : 0 Oct 13 14:58:03 app1 kernel: [12203.433858] .clock_overflows : 3248036 Oct 13 14:58:03 app1 kernel: [12203.433860] .clock_deep_idle_events : 0 Oct 13 14:58:03 app1 kernel: [12203.433861] .clock_max_delta : 9.999857 Oct 13 14:58:03 app1 kernel: [12203.433864] .cpu_load[0] : 1024 Oct 13 14:58:03 app1 kernel: [12203.433865] .cpu_load[1] : 513 Oct 13 14:58:03 app1 kernel: [12203.433867] .cpu_load[2] : 286 Oct 13 14:58:03 app1 kernel: [12203.433868] .cpu_load[3] : 202 Oct 13 14:58:03 app1 kernel: [12203.433870] .cpu_load[4] : 168 Oct 13 14:58:03 app1 kernel: [12203.433872] Oct 13 14:58:03 app1 kernel: [12203.433873] cfs_rq Oct 13 14:58:03 app1 kernel: [12203.433874] .exec_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433876] .MIN_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.433877] .min_vruntime : 4068994.835503 Oct 13 14:58:03 app1 kernel: [12203.433879] .max_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.433881] .spread : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433882] .spread0 : 633280.082716 Oct 13 14:58:03 app1 kernel: [12203.433884] .nr_running : 0 Oct 13 14:58:03 app1 kernel: [12203.433885] .load : 0 Oct 13 14:58:03 app1 kernel: [12203.433888] .nr_spread_over : 0 Oct 13 14:58:03 app1 kernel: [12203.433889] Oct 13 14:58:03 app1 kernel: [12203.433889] cfs_rq Oct 13 14:58:03 app1 kernel: [12203.433891] .exec_clock : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433893] .MIN_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.433894] .min_vruntime : 4068994.835503 Oct 13 14:58:03 app1 kernel: [12203.433896] .max_vruntime : 0.000001 Oct 13 14:58:03 app1 kernel: [12203.433899] .spread : 0.000000 Oct 13 14:58:03 app1 kernel: [12203.433900] .spread0 : 633280.082716 Oct 13 14:58:03 app1 kernel: [12203.433902] .nr_running : 0 Oct 13 14:58:03 app1 kernel: [12203.433903] .load : 0 Oct 13 14:58:03 app1 kernel: [12203.433905] .nr_spread_over : 0 Oct 13 14:58:03 app1 kernel: [12203.433908] Oct 13 14:58:03 app1 kernel: [12203.433909] runnable tasks: Oct 13 14:58:03 app1 kernel: [12203.433909] task PID tree-key switches prio exec-runtime sum-exec sum-sleep Oct 13 14:58:03 app1 kernel: [12203.433911] ---------------------------------------------------------------------------------------------------------- Oct 13 14:58:03 app1 kernel: [12203.434115] --------------070705070407040700010900-- From dlg@dsrw.org Fri Oct 17 23:47:13 2008 From: dlg@dsrw.org (david l goodrich) Date: Fri, 17 Oct 2008 17:47:13 -0500 Subject: [OpenAFS] error: 'CTL_UNNUMBERED' undeclared here (not in a function) Message-ID: <20081017224713.GC23456@aether.dsrw.org> --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable i'm trying to build the openafs module on an ubuntu 8.04 system with a 2.6.16.29-xenU kernel. root@fawkes:~# dpkg -l |awk '/openafs-modules/ {print $2,$3}' openafs-modules-source 1.4.6.dfsg1-2 root@fawkes:~# uname -r 2.6.16.29-xenU root@fawkes:~#=20 after some help from cclausen on irc, i'm reasonably confident the build environment is sound, but m-a a-i openafs-modules fails=20 like debian Bug #458331: CC [M] /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.16.29-xenU-MP/osi= _sysctl.o /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.16.29-xenU-MP/osi_sysctl.c:= 32: error: 'CTL_UNNUMBERED' undeclared here (not in a function) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.16.29-xenU-MP/osi_sysctl.c:= 108: error: initializer element is not constant /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.16.29-xenU-MP/osi_sysctl.c:= 108: error: (near initialization for 'fs_sysctl_table[0].ctl_name') make[7]: *** [/usr/src/modules/openafs/src/libafs/MODLOAD-2.6.16.29-xenU-MP= /osi_sysctl.o] Error 1 =20 but since i'm trying to use 1.4.6.dfsg1-2, the patches russ recommends in the email exchange[1] are already in the module. Any other thoughts as to why this may be happening? Thanks. --waldo 1. http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg434942.= html =20 --C7zPtVaVf+AK4Oqc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI+RXxHDmo5jqnP4QRArEmAJ9Y3t+6Y7JKKLvjHePyje3oHm8URQCcD74y A2OfuF7RhqbjeWV3JGvMdqE= =7MD2 -----END PGP SIGNATURE----- --C7zPtVaVf+AK4Oqc-- From shadow@gmail.com Sat Oct 18 04:04:26 2008 From: shadow@gmail.com (Derrick Brashear) Date: Fri, 17 Oct 2008 23:04:26 -0400 Subject: [OpenAFS] error: 'CTL_UNNUMBERED' undeclared here (not in a function) In-Reply-To: <20081017224713.GC23456@aether.dsrw.org> References: <20081017224713.GC23456@aether.dsrw.org> Message-ID: On Fri, Oct 17, 2008 at 6:47 PM, david l goodrich wrote: > i'm trying to build the openafs module on an ubuntu 8.04 system > with a 2.6.16.29-xenU kernel. > > root@fawkes:~# dpkg -l |awk '/openafs-modules/ {print $2,$3}' > openafs-modules-source 1.4.6.dfsg1-2 1.4.7 is current. can you try building that regardless of what's currently packaged? From avison48@yahoo.co.uk Sat Oct 18 17:53:41 2008 From: avison48@yahoo.co.uk (avison48) Date: Sat, 18 Oct 2008 16:53:41 +0000 (GMT) Subject: [OpenAFS] Flag this message Message-ID: <441949.27283.qm@web27303.mail.ukl.yahoo.com> Good day, all, & especially Steven Jenkins who responded (thank you!) I do have some clarification questions. I'm very grateful for your patience and for your being so helpful. Rough recap of plan: . antique Win2K IBM/TransArc 3.5 AFS server . new RHEL4 OpenAFS server . Initially make the new server a secondary server of all the old server's user-account info & data . then break the join between them & the new server should be an=20 independent AFS server (not secondary) > The primary question is where your current Kerberos authentication > comes from. If you're running the kaserver on your IBM/Transarc AFS > server (and given your other emails, that appears to be the case), Yes, the Win2K IBM/TransArc 3.5 AFS server runs kaserver. So this is the "Traditional" AFS kerberos server. I had thought this antique AFS server was authenticating to our MS2003 kerberos server; but I see it's not, it has its own 'internal' kerberos server. Our MS2003 KDC admin says there's no "afs" principal. > A secondary question is how your IP address space will look: given The old server & the new server are on entirely different subnets, & numerically the last 2 quads of new server are both higher than the antique. The old subnet is not really supposed to have servers on it=20 (shrug, that's the way my predecessor built it) but I can change the new=20 server to a lower-numbered IP on the old subnet temporarily, then change it= =20 back to its correct subnet when it's "the" one & only AFS server of the=20 cell (changing CellServDB on it + clients & etc) - assuming this won't=20 break anything AFS related - for instance, the KeyFile? (if the IP gets=20 embedded in there?) > Finally, keep in mind that AFS will only automatically synchronize the > user-account info and the volume location information -- you will > actually have to move the user data yourself via vos commands (e.g., > vos move). Yes, I see vos copy exists for openafs but not IBM/TransArc. > In general, doing a bos removehost $server $server-to-forget + bos > restart $server $process of a server process removes references to > $server-to-forget. Ah! So it will 'wake up' with no ties to the old server. What a relief if the disengagement from old & new life as solo/independent is that simple. I like your outline, thank you very much for the suggestion. I need to understand more about the kerberos bits. Many apologies if this seems thick, & please accept gratitude for your kind patience. =20 The old AFS server runs its own kerberos server kaserver, with an AFS admin account known to it. (And logically, all the current AFS user accounts authenticate to that kaserver using klog.) The new AFS server will run its own kerberos server (I've given up trying= =20 to use the MS2003 kerberos server) & that kerberos server will have its own distinct afs principal - yes? - & its own admin principal, & kerberos principals for all the AFS users. Is that correct? Or must the new server have the KeyFile from the old AFS server.... but that would point to antique kaserver on the old AFS server? Must be "No", no future there! A secondary database server is supposed to run the authentication & protection services, with data it gets from the original AFS server. So is it correct that bos addhost, which is to do all that replication,=20 will insert all the old AFS server's info about AFS user accounts, groups, passwords, expiry dates etc etc etc, *from* the Win2K kaserver, *into* the= =20 kerberos server running on the new RHEL4 AFS server. Yes? (if bos addhost starts upclient, the new AFS server must need upclient configured off when it becomes the only AFS server) Or does a human have to create all the kerberos principals (not that many) on the new RHEL4 kerberos server by hand, then do bos addhost? And the old kaserver on Win2K, & the new kerberos server on RHEL4 won't ... interfere with each other, or anything bad... Is that correct? Sorry for all the questions & thank you very much for advice!! =0A=0ASend instant messages to your online friends http://uk.messenger.yaho= o.com From avison48@yahoo.co.uk Sat Oct 18 17:56:05 2008 From: avison48@yahoo.co.uk (avison48) Date: Sat, 18 Oct 2008 16:56:05 +0000 (GMT) Subject: [OpenAFS] Re: Win2K AFS server, setup SL4.5 test-cell server then migrate... Message-ID: <720316.60386.qm@web27304.mail.ukl.yahoo.com> Take 2 with right subject!! (yahoo=3Dcurses+curses) Good day, all, & especially Steven Jenkins who responded (thank you!) I do have some clarification questions. I'm very grateful for your patience and for your being so helpful. Rough recap of plan: . antique Win2K IBM/TransArc 3.5 AFS server . new RHEL4 OpenAFS server . Initially make the new server a secondary server of all the old server's user-account info & data . then break the join between them & the new server should be an=20 independent AFS server (not secondary) > The primary question is where your current Kerberos authentication > comes from. If you're running the kaserver on your IBM/Transarc AFS > server (and given your other emails, that appears to be the case), Yes, the Win2K IBM/TransArc 3.5 AFS server runs kaserver. So this is the "Traditional" AFS kerberos server. I had thought this antique AFS server was authenticating to our MS2003 kerberos server; but I see it's not, it has its own 'internal' kerberos server. Our MS2003 KDC admin says there's no "afs" principal. > A secondary question is how your IP address space will look: given The old server & the new server are on entirely different subnets, & numerically the last 2 quads of new server are both higher than the antique. The old subnet is not really supposed to have servers on it=20 (shrug, that's the way my predecessor built it) but I can change the new=20 server to a lower-numbered IP on the old subnet temporarily, then change it= =20 back to its correct subnet when it's "the" one & only AFS server of the=20 cell (changing CellServDB on it + clients & etc) - assuming this won't=20 break anything AFS related - for instance, the KeyFile? (if the IP gets=20 embedded in there?) > Finally, keep in mind that AFS will only automatically synchronize the > user-account info and the volume location information -- you will > actually have to move the user data yourself via vos commands (e.g., > vos move). Yes, I see vos copy exists for openafs but not IBM/TransArc. > In general, doing a bos removehost $server $server-to-forget + bos > restart $server $process of a server process removes references to > $server-to-forget. Ah! So it will 'wake up' with no ties to the old server. What a relief if the disengagement from old & new life as solo/independent is that simple. I like your outline, thank you very much for the suggestion. I need to understand more about the kerberos bits. Many apologies if this seems thick, & please accept gratitude for your kind patience. =20 The old AFS server runs its own kerberos server kaserver, with an AFS admin account known to it. (And logically, all the current AFS user accounts authenticate to that kaserver using klog.) The new AFS server will run its own kerberos server (I've given up trying= =20 to use the MS2003 kerberos server) & that kerberos server will have its own distinct afs principal - yes? - & its own admin principal, & kerberos principals for all the AFS users. Is that correct? Or must the new server have the KeyFile from the old AFS server.... but that would point to antique kaserver on the old AFS server? Must be "No", no future there! A secondary database server is supposed to run the authentication & protection services, with data it gets from the original AFS server. So is it correct that bos addhost, which is to do all that replication,=20 will insert all the old AFS server's info about AFS user accounts, groups, passwords, expiry dates etc etc etc, *from* the Win2K kaserver, *into* the= =20 kerberos server running on the new RHEL4 AFS server. Yes? (if bos addhost starts upclient, the new AFS server must need upclient configured off when it becomes the only AFS server) Or does a human have to create all the kerberos principals (not that many) on the new RHEL4 kerberos server by hand, then do bos addhost? And the old kaserver on Win2K, & the new kerberos server on RHEL4 won't ... interfere with each other, or anything bad... Is that correct? Sorry for all the questions & thank you very much for advice!! =0A=0ASend instant messages to your online friends http://uk.messenger.yaho= o.com From dlg@dsrw.org Mon Oct 20 22:50:05 2008 From: dlg@dsrw.org (david l goodrich) Date: Mon, 20 Oct 2008 16:50:05 -0500 Subject: [OpenAFS] error: 'CTL_UNNUMBERED' undeclared here (not in a function) In-Reply-To: References: <20081017224713.GC23456@aether.dsrw.org> Message-ID: <20081020215005.GA2919@aether.dsrw.org> --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 17, 2008 at 11:04:26PM -0400, Derrick Brashear wrote: > On Fri, Oct 17, 2008 at 6:47 PM, david l goodrich wrote: > > i'm trying to build the openafs module on an ubuntu 8.04 system > > with a 2.6.16.29-xenU kernel. > > > > root@fawkes:~# dpkg -l |awk '/openafs-modules/ {print $2,$3}' > > openafs-modules-source 1.4.6.dfsg1-2 >=20 > 1.4.7 is current. > can you try building that regardless of what's currently packaged? 1.4.7 seems to work, i'm able to build and load the kernel module. I guess i'll wait for the ubuntu package to catch up. thanks. --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI/P0NHDmo5jqnP4QRAihKAKCBOQgrwYvmiTbUIY4iYRj3cW0Q2wCeICbh zMVzJVtEnoWw/moWPeQt3qo= =hpsC -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From jcifuen@us.ibm.com Tue Oct 21 19:01:23 2008 From: jcifuen@us.ibm.com (Jaime Cifuentes) Date: Tue, 21 Oct 2008 12:01:23 -0600 Subject: [OpenAFS] Linux kernel and corresponding OpenAFS upgrade packages Message-ID: --0__=08BBFE7ADFF2E0E68f9e8a93df938690918c08BBFE7ADFF2E0E6 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Hello all, Our OS team tried to upgrade the RedHat Enterprise Linux servers.= Originally they stated the new kernel level was 78.0.1, so our senior coworker obtained the OpenAFS packages we needed for that kernel. He downloaded kmod-openafs-smp-1.4.7-1.1.2.6.9_78.0.1.EL.i686.rpm, kmod-openafs-1.4.7-1.1.2.6.9_78.0.1.EL.i686.rpm, and kmod-openafs-hugemem-1.4.7-1.1.2.6.9_78.0.1.EL.i686.rpm. However, whe= n they (the OS team) updated the kernel, they upgraded it to 78.0.5, and being this server an OpenAFS fileserver, they decided to not install th= e AFS packages above, because they did not know if those were the correct= packages for OpenAFS. The senior member has left the company, but did not tell us how t= o determine what OpenAFS packages work with what Linux kernel. So, I hav= e two questions: How do I determine what OpenAFS packages are needed for a given OS kernel, and/or what specific packages do I need for RedHat Enterprise Linux 78.0.5?= Any information will be greatly appreciated. Jaime Cifuentes DCE/DFS-AFS Support, Hitachi San Jose, CA.= --0__=08BBFE7ADFF2E0E68f9e8a93df938690918c08BBFE7ADFF2E0E6 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Hello all,

Our OS team tried to upgrade the RedHat Enterprise Linux servers. Ori= ginally they stated the new kernel level was 78.0.1, so our senior cowo= rker obtained the OpenAFS packages we needed for that kernel. He downlo= aded kmod-openafs-smp-1.4.7-1.1.2.6.9_78.0.1.EL.i686.rpm, kmod-openafs-= 1.4.7-1.1.2.6.9_78.0.1.EL.i686.rpm, and kmod-openafs-hugemem-1.4.7-1.1.= 2.6.9_78.0.1.EL.i686.rpm. However, when they (the OS team) updated th= e kernel, they upgraded it to 78.0.5, and being this server an OpenAFS = fileserver, they decided to not install the AFS packages above, because= they did not know if those were the correct packages for OpenAFS.
=
The senior member has left the company, but did not tell us how to det= ermine what OpenAFS packages work with what Linux kernel. So, I have t= wo questions:

  1. How do I determine what OpenAFS packages are needed for a given OS = kernel, and/or
  2. what specific packages do I need for RedHat Enterprise Linux 78.0.5= ?

Any information will be greatly appreciated.


Jaime Cifuentes
DCE/DFS-AFS Support, Hitachi
San Jose, CA.= --0__=08BBFE7ADFF2E0E68f9e8a93df938690918c08BBFE7ADFF2E0E6-- From shadow@gmail.com Tue Oct 21 19:27:31 2008 From: shadow@gmail.com (Derrick Brashear) Date: Tue, 21 Oct 2008 14:27:31 -0400 Subject: [OpenAFS] Linux kernel and corresponding OpenAFS upgrade packages In-Reply-To: References: Message-ID: On Tue, Oct 21, 2008 at 2:01 PM, Jaime Cifuentes wrote: > Hello all, > > Our OS team tried to upgrade the RedHat Enterprise Linux servers. Originally > they stated the new kernel level was 78.0.1, so our senior coworker obtained > the OpenAFS packages we needed for that kernel. He downloaded > kmod-openafs-smp-1.4.7-1.1.2.6.9_78.0.1.EL.i686.rpm, > kmod-openafs-1.4.7-1.1.2.6.9_78.0.1.EL.i686.rpm, and > kmod-openafs-hugemem-1.4.7-1.1.2.6.9_78.0.1.EL.i686.rpm. However, when they > (the OS team) updated the kernel, they upgraded it to 78.0.5, and being this > server an OpenAFS fileserver, they decided to not install the AFS packages > above, because they did not know if those were the correct packages for > OpenAFS. > > The senior member has left the company, but did not tell us how to determine > what OpenAFS packages work with what Linux kernel. So, I have two questions: > > How do I determine what OpenAFS packages are needed for a given OS kernel, every kernel has its own module package, named with the complete kernel version in the rpm name. If it's not there we haven't uploaded the build yet (and if so, I apologize) > and/or > what specific packages do I need for RedHat Enterprise Linux 78.0.5? if you have yum enabled you can set up the machine with our repo rpm to just find the kmods you need. -- Derrick From dirk.heinrichs.ext@nsn.com Wed Oct 22 07:03:05 2008 From: dirk.heinrichs.ext@nsn.com (Dirk Heinrichs) Date: Wed, 22 Oct 2008 08:03:05 +0200 Subject: [OpenAFS] Linux kernel and corresponding OpenAFS upgrade packages In-Reply-To: References: Message-ID: <200810220803.07244.dirk.heinrichs.ext@nsn.com> --nextPart1292306.jTXq76UYbg Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Dienstag 21 Oktober 2008 20:01:23 schrieb ext Jaime Cifuentes: > =A0 =A0 Our OS team tried to upgrade the RedHat Enterprise Linux servers. > Originally they stated the new kernel level was 78.0.1, so our senior > coworker obtained the OpenAFS packages we needed for that kernel. He > downloaded kmod-openafs-smp-1.4.7-1.1.2.6.9_78.0.1.EL.i686.rpm, > kmod-openafs-1.4.7-1.1.2.6.9_78.0.1.EL.i686.rpm, and > kmod-openafs-hugemem-1.4.7-1.1.2.6.9_78.0.1.EL.i686.rpm. =A0 However, when > they (the OS team) updated the kernel, they upgraded it to 78.0.5, and > being this server an OpenAFS fileserver, they decided to not install the > AFS packages above, because they did not know if those were the correct > packages for OpenAFS. You don't need the kernel modules at all for server machines. Bye... Dirk =2D-=20 Dirk Heinrichs | Tel: +49 (0)162 234 3408 Configuration Manager | Fax: +49 (0)211 47068 111 Capgemini Deutschland | Mail: dirk.heinrichs@capgemini.com Wanheimerstra=DFe 68 | Web: http://www.capgemini.com D-40468 D=FCsseldorf | ICQ#: 110037733 GPG Public Key C2E467BB | Keyserver: wwwkeys.pgp.net --nextPart1292306.jTXq76UYbg Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iD8DBQBI/sIb8NVtnsLkZ7sRAo+nAJ9Nx8pogqqzBvT7G+t3+UNQUK8cYQCfXHAa fA+Vg5GiNDoi7e1yq3VQsOA= =yrff -----END PGP SIGNATURE----- --nextPart1292306.jTXq76UYbg-- From haba@kth.se Wed Oct 22 10:51:50 2008 From: haba@kth.se (Harald Barth) Date: Wed, 22 Oct 2008 11:51:50 +0200 (CEST) Subject: [OpenAFS] Linux kernel and corresponding OpenAFS upgrade packages In-Reply-To: References: Message-ID: <20081022.115150.222755675.haba@habanero.pdc.kth.se> > kmod-openafs-hugemem-1.4.7-1.1.2.6.9_78.0.1.EL.i686.rpm. However, when > they (the OS team) updated the kernel, they upgraded it to 78.0.5, and > being this server an OpenAFS fileserver, they decided to not install the > AFS packages above, because they did not know if those were the correct > packages for OpenAFS. I don't have any kmod stuff installed on my OpenAFS servers at all as they don't need to run the client. One less thing that can break, one less thing to care about when upgrading the kernel. My AFS servers are only AFS servers and nothing else. Harald. From shadow@gmail.com Wed Oct 22 13:44:51 2008 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 22 Oct 2008 08:44:51 -0400 Subject: [OpenAFS] Linux kernel and corresponding OpenAFS upgrade packages In-Reply-To: <20081022.115150.222755675.haba@habanero.pdc.kth.se> References: <20081022.115150.222755675.haba@habanero.pdc.kth.se> Message-ID: On Wed, Oct 22, 2008 at 5:51 AM, Harald Barth wrote: > >> kmod-openafs-hugemem-1.4.7-1.1.2.6.9_78.0.1.EL.i686.rpm. However, when >> they (the OS team) updated the kernel, they upgraded it to 78.0.5, and >> being this server an OpenAFS fileserver, they decided to not install the >> AFS packages above, because they did not know if those were the correct >> packages for OpenAFS. > > I don't have any kmod stuff installed on my OpenAFS servers at all as > they don't need to run the client. One less thing that can break, one > less thing to care about when upgrading the kernel. My AFS servers are > only AFS servers and nothing else. Agreed with one caveat: any utility you use with a token (rather than -localauth) won't work with no kernel module. As long as you stick to -localauth all is well. Derrick From ecgarris@iupui.edu Wed Oct 22 14:58:42 2008 From: ecgarris@iupui.edu (Eric Chris Garrison) Date: Wed, 22 Oct 2008 09:58:42 -0400 Subject: [OpenAFS] OpenAFS with Samba volume move confusion? Message-ID: <48FF3192.9000907@iupui.edu> Hello, I have a head-scratcher of a problem. In the past, we've been able to move volumes from one OpenAFS server to another without disturbing users. Most of our users access OpenAFS through Samba on gateway servers, using Kerberos 5 to authenticate. I decided to upgrade our servers from 1.4.4 to 1.4.7 this week, so I was going to do rolling upgrades, that is, moving volumes from one server to another, upgrade the server, then move them back and so on. This time, we find that Samba claims to not be able to see the volume. If the user deliberately selects another samba gateway, it'll work fine. If the samba server on the gateway is restarted, it'll cure the problem as well. So it sounds like Samba is getting confused as the volume moves. Anyone know why that might be, and what might cure it? This problem would really negate most of the reasons we chose OpenAFS as an underlying filesystem, if we can't just move volumes around as needed. Thanks for any advice! Chris -- Eric Chris Garrison | Principal Mass Storage Specialist ecgarris@iupui.edu | Indiana University - Research Storage W: 317-278-1207 M: 317-250-8649 | Jabber IM: ecgarris@iupui.edu From haba@kth.se Wed Oct 22 15:04:02 2008 From: haba@kth.se (Harald Barth) Date: Wed, 22 Oct 2008 16:04:02 +0200 (CEST) Subject: [OpenAFS] OpenAFS with Samba volume move confusion? In-Reply-To: <48FF3192.9000907@iupui.edu> References: <48FF3192.9000907@iupui.edu> Message-ID: <20081022.160402.150981812.haba@habanero.pdc.kth.se> > I decided to upgrade our servers from 1.4.4 to 1.4.7 this week, so I was > going to do rolling upgrades, that is, moving volumes from one server to > another, upgrade the server, then move them back and so on. This time, we > find that Samba claims to not be able to see the volume. What client version on the samba gateway? Is "fs checkv" after the move a workaround? Harald. From ecgarris@iupui.edu Wed Oct 22 15:43:36 2008 From: ecgarris@iupui.edu (Eric Chris Garrison) Date: Wed, 22 Oct 2008 10:43:36 -0400 Subject: [OpenAFS] OpenAFS with Samba volume move confusion? In-Reply-To: <20081022.160402.150981812.haba@habanero.pdc.kth.se> References: <48FF3192.9000907@iupui.edu> <20081022.160402.150981812.haba@habanero.pdc.kth.se> Message-ID: <48FF3C18.7000507@iupui.edu> Harald Barth wrote: >> I decided to upgrade our servers from 1.4.4 to 1.4.7 this week, so I was >> going to do rolling upgrades, that is, moving volumes from one server to >> another, upgrade the server, then move them back and so on. This time, we >> find that Samba claims to not be able to see the volume. > > What client version on the samba gateway? > Is "fs checkv" after the move a workaround? > > Harald. Samba is at version 3.0.25b-1.el4.4 on our gateways. I'm not sure if that's a workaround, since I've been unable to reproduce the behavior, it is just certain random users. Must be a special case, maybe they're using the volume right as the move happens? I'm baffled. I could include it in the mvto script. That or a fs flush? Thanks, Chris -- Eric Chris Garrison | Principal Mass Storage Specialist ecgarris@iupui.edu | Indiana University - Research Storage W: 317-278-1207 M: 317-250-8649 | Jabber IM: ecgarris@iupui.edu From jaltman@secure-endpoints.com Wed Oct 22 16:00:31 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 22 Oct 2008 11:00:31 -0400 Subject: [OpenAFS] OpenAFS with Samba volume move confusion? In-Reply-To: <48FF3C18.7000507@iupui.edu> References: <48FF3192.9000907@iupui.edu> <20081022.160402.150981812.haba@habanero.pdc.kth.se> <48FF3C18.7000507@iupui.edu> Message-ID: <48FF400F.1000505@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms010808040700000905000905 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All pre-1.4.8 file servers (going back to IBM) have a bug where the volume will be reported VNOVOL instead of VBUSY/VMOVED while the move is taking place. This happens before the move has completed so when the clients go back to the VLDB to update the location info they are told that the location is the same as it thought it was. For the next two hours the client will attempt to find the volume in the wrong place until the VL info expires or "fs checkvolumes" is issued. This bug is fixed by DELTA STABLE14-volser-reclone-bring-online-before-giveback-20080716 which can be applied to 1.4.7 although at this point you might just want to use the 1.4.8-preX servers. Jeffrey Altman Eric Chris Garrison wrote: > Harald Barth wrote: >>> I decided to upgrade our servers from 1.4.4 to 1.4.7 this week, so I was >>> going to do rolling upgrades, that is, moving volumes from one server to >>> another, upgrade the server, then move them back and so on. This time, we >>> find that Samba claims to not be able to see the volume. >> What client version on the samba gateway? >> Is "fs checkv" after the move a workaround? >> >> Harald. > > > Samba is at version 3.0.25b-1.el4.4 on our gateways. I'm not sure if > that's a workaround, since I've been unable to reproduce the behavior, it > is just certain random users. Must be a special case, maybe they're using > the volume right as the move happens? I'm baffled. I could include it in > the mvto script. That or a fs flush? > > Thanks, > > Chris --------------ms010808040700000905000905 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMjIxNTAwMzFaMCMGCSqGSIb3DQEJBDEWBBS0nS4W /uEHT83HTUu6A/f1/I7LJDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAEjmaCQnIR9ZqqQbNFpTx/yys6kLr/YwrOfjduIB50OzvI9PsEycb Hu67vjHaXssBZDlFWhgkONtt/Xsj/5iwnOlJAAehW/0E2dQSzyrGLxXn3LvUredl2B0xCurq QSECrm2SIVtUtB8hEY3xSheAFuYdNSnWUg8Jc4fgV6cO/Z+jSYAPOipUsDKsK3M0tRiQlqsg 0lDzmIAy8vovDU0/qaBA6xieFaaEXCcASEOHPiTbEgNUFDXsXh7M+0/wQ4HhgPQmo+Rs4y1n 4s3aENEdNzpDdKW9il6tpRpteWvLHPM9ED8/ThK87Xpe7AVW5VL9385AIaQ5LUik4Mf88g+x 4QAAAAAAAA== --------------ms010808040700000905000905-- From haba@kth.se Wed Oct 22 16:33:33 2008 From: haba@kth.se (Harald Barth) Date: Wed, 22 Oct 2008 17:33:33 +0200 (CEST) Subject: [OpenAFS] OpenAFS with Samba volume move confusion? In-Reply-To: <48FF400F.1000505@secure-endpoints.com> References: <20081022.160402.150981812.haba@habanero.pdc.kth.se> <48FF3C18.7000507@iupui.edu> <48FF400F.1000505@secure-endpoints.com> Message-ID: <20081022.173333.149650345.haba@habanero.pdc.kth.se> I was thinking about the AFS client version, but.... > All pre-1.4.8 file servers (going back to IBM) have a bug where the > volume will be reported VNOVOL instead of VBUSY/VMOVED while the > move is taking place. ...that explains it quite well. > .. or "fs checkvolumes" is issued. Which has to be issued on all AFS clients (= samba servers?) As the bug is fixed you will not have the problem next time :) Harald. From David.Bear@asu.edu Wed Oct 22 20:05:36 2008 From: David.Bear@asu.edu (David Bear) Date: Wed, 22 Oct 2008 12:05:36 -0700 Subject: [OpenAFS] openafs pioctl issue on windows Message-ID: <1d1a54bf0810221205r75e30746o49dcff3c409e7638@mail.gmail.com> ------=_Part_32457_23485762.1224702336351 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I am using /usr/sbin/rxdebug -server pp-bvossoughi.dhcp.asu.edu -port 7001 -vers Trying 10.218.16.141 (port 7001): AFS version: OpenAFS_1.5.5400 This system has had intermittent erros with accessing openafs. The issue seems to be always an access/token issue. KFW 3.2.2 is install and the user is able to get tokens in the asu.edurealm. NIM show the TGT's. However, any attempt to use 'tokens' to display the afs tokens causes this: C:\Documents and Settings\bvossoug>tokens Tokens held by the Cache Manager: pioctl temp != 0: 0x66543218 --End of list -- I googled and found someone with a similar error here: http://www.openafs.org/pipermail/openafs-info/2006-December/024568.html But I don't know if it could be related since there was no resolution on the thread and it is so old. I created an fs minidump and copied that ad the afsd_init.log to an afs location that should be world readable at /afs/asu.edu/pp/oss/afsDumps ( the acl is set as system:anyuser so I hope the world can read this location ) Any pointers on where to go next? (BTW, the issue seems to be tied to a specific user logon. I was able to log on to windows as myself, get tokens, and use afs) -- David Bear College of Public Programs at ASU 602-464-0424 ------=_Part_32457_23485762.1224702336351 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

I am using

/usr/sbin/rxdebug -server pp-bvossoughi.dhcp.asu.edu -port 7001 -vers

Trying 10.218.16.141 (port 7001):
AFS version: OpenAFS_1.5.5400

This system has had intermittent erros with accessing openafs. The issue seems to be always an access/token issue.

KFW 3.2.2 is install and the user is able to get tokens in the asu.edu realm. NIM show the TGT's.

However, any attempt to use 'tokens' to display the afs tokens causes this:

C:\Documents and Settings\bvossoug>tokens
Tokens held by the Cache Manager:

pioctl temp != 0: 0x66543218
  --End of list --

I googled and found someone with a similar error here: 
http://www.openafs.org/pipermail/openafs-info/2006-December/024568.html

But I don't know if it could be related since there was no resolution on the thread and it is so old.

I created an fs minidump and copied that ad the afsd_init.log to an afs location that should be world readable at

/afs/asu.edu/pp/oss/afsDumps

( the acl is set as system:anyuser so I hope the world can read this location )

Any pointers on where to go next? (BTW, the issue seems to be tied to a specific user logon. I was able to log on to windows as myself, get tokens, and use afs)

--

David Bear
College of Public Programs at ASU
602-464-0424
------=_Part_32457_23485762.1224702336351-- From jaltman@secure-endpoints.com Wed Oct 22 20:18:41 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 22 Oct 2008 15:18:41 -0400 Subject: [OpenAFS] openafs pioctl issue on windows In-Reply-To: <1d1a54bf0810221205r75e30746o49dcff3c409e7638@mail.gmail.com> References: <1d1a54bf0810221205r75e30746o49dcff3c409e7638@mail.gmail.com> Message-ID: <48FF7C91.9070605@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms010203020200060405080108 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit NIM uses the same pioctl call as tokens.exe to obtain the tokens list. As long as they are being executed from within the same logon session they will display the same results. Hint: "Run as ..." or "Run as administrator" produces a new logon session. Jeffrey Altman David Bear wrote: > I am using > > /usr/sbin/rxdebug -server pp-bvossoughi.dhcp.asu.edu > -port 7001 -vers > > Trying 10.218.16.141 (port 7001): > AFS version: OpenAFS_1.5.5400 > > This system has had intermittent erros with accessing openafs. The issue > seems to be always an access/token issue. > > KFW 3.2.2 is install and the user is able to get tokens in the asu.edu > realm. NIM show the TGT's. > > However, any attempt to use 'tokens' to display the afs tokens causes this: > > C:\Documents and Settings\bvossoug>tokens > Tokens held by the Cache Manager: > > pioctl temp != 0: 0x66543218 > --End of list -- > > I googled and found someone with a similar error here: > http://www.openafs.org/pipermail/openafs-info/2006-December/024568.html > > But I don't know if it could be related since there was no resolution on > the thread and it is so old. > > I created an fs minidump and copied that ad the afsd_init.log to an afs > location that should be world readable at > > /afs/asu.edu/pp/oss/afsDumps > > ( the acl is set as system:anyuser so I hope the world can read this > location ) > > Any pointers on where to go next? (BTW, the issue seems to be tied to a > specific user logon. I was able to log on to windows as myself, get > tokens, and use afs) > > -- > > David Bear > College of Public Programs at ASU > 602-464-0424 --------------ms010203020200060405080108 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMjIxOTE4NDFaMCMGCSqGSIb3DQEJBDEWBBRxUCNT uGXbAB5YmLvYT5wz8pm42TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAc3eGngmTw0qDg83kr2Vjgfd4a0gA6/J/iqmEufr3rJj+tZ+MDzD+ BASB0gTdxeH/xEc0M203auyBaNfYxwx+v9ozoD7pnA8KWK0/kWBOtMPdyUpmkSwt5l8WUmwJ 9wmU8q/rZ/omFLPSna5Gy4P/zbgi+NXU+kbDKKptqnH2rDibH43IwZk6YoAG77iThPD5zjmt MpxCiJ9zuIb4cJUSgrxfZ6X3ETQ/v8Rfj9Nh9CKOLJIQtb2Oi4ovrUWe2LxeCQjGXwY5HWM5 UP+prWKL81aNYhRgrsiwdFqatmg6hzrVaLeNdBzAYfV/9uCcuOWs3gQooz5JrHJedrmQZyTI xgAAAAAAAA== --------------ms010203020200060405080108-- From David.Bear@asu.edu Wed Oct 22 20:56:44 2008 From: David.Bear@asu.edu (David Bear) Date: Wed, 22 Oct 2008 12:56:44 -0700 Subject: [OpenAFS] openafs pioctl issue on windows In-Reply-To: <48FF7C91.9070605@secure-endpoints.com> References: <1d1a54bf0810221205r75e30746o49dcff3c409e7638@mail.gmail.com> <48FF7C91.9070605@secure-endpoints.com> Message-ID: <1d1a54bf0810221256y1143977pf648adc4a10221e4@mail.gmail.com> ------=_Part_33691_32877454.1224705404574 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, Oct 22, 2008 at 12:18 PM, Jeffrey Altman < jaltman@secure-endpoints.com> wrote: > NIM uses the same pioctl call as tokens.exe to obtain the tokens list. > > As long as they are being executed from within the same logon session > they will display the same results. > > Hint: "Run as ..." or "Run as administrator" produces a new logon session. > Okay -- I tried this from cmd, in a new session. This failes. C:\WINDOWS\system32>tokens Tokens held by the Cache Manager: --End of list -- pioctl temp != 0: 0x66543218 Then C:\WINDOWS\system32>kinit iddwb kinit(v5): Inappropriate I/O control operation while getting initial credentials So, I guess kfw is not working properly here. Any pointers on what could be wrong with KFW? > Jeffrey Altman > > David Bear wrote: > > I am using > > > > /usr/sbin/rxdebug -server pp-bvossoughi.dhcp.asu.edu > > -port 7001 -vers > > > > Trying 10.218.16.141 (port 7001): > > AFS version: OpenAFS_1.5.5400 > > > > This system has had intermittent erros with accessing openafs. The issue > > seems to be always an access/token issue. > > > > KFW 3.2.2 is install and the user is able to get tokens in the asu.edu > > realm. NIM show the TGT's. > > > > However, any attempt to use 'tokens' to display the afs tokens causes > this: > > > > C:\Documents and Settings\bvossoug>tokens > > Tokens held by the Cache Manager: > > > > pioctl temp != 0: 0x66543218 > > --End of list -- > > > > I googled and found someone with a similar error here: > > http://www.openafs.org/pipermail/openafs-info/2006-December/024568.html > > > > But I don't know if it could be related since there was no resolution on > > the thread and it is so old. > > > > I created an fs minidump and copied that ad the afsd_init.log to an afs > > location that should be world readable at > > > > /afs/asu.edu/pp/oss/afsDumps > > > > ( the acl is set as system:anyuser so I hope the world can read this > > location ) > > > > Any pointers on where to go next? (BTW, the issue seems to be tied to a > > specific user logon. I was able to log on to windows as myself, get > > tokens, and use afs) > > > > -- > > > > David Bear > > College of Public Programs at ASU > > 602-464-0424 > -- David Bear College of Public Programs at ASU 602-464-0424 ------=_Part_33691_32877454.1224705404574 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Wed, Oct 22, 2008 at 12:18 PM, Jeffrey Altman <jaltman@secure-endpoints.com> wrote:
NIM uses the same pioctl call as tokens.exe to obtain the tokens list.

As long as they are being executed from within the same logon session
they will display the same results.

Hint: "Run as ..." or "Run as administrator" produces a new logon session.
Okay -- I tried this from cmd, in a new session.
This failes.
C:\WINDOWS\system32>tokens

Tokens held by the Cache Manager:

  --End of list --
pioctl temp != 0: 0x66543218
Then
C:\WINDOWS\system32>kinit iddwb
kinit(v5): Inappropriate I/O control operation while getting initial credentials

So, I guess kfw is not working properly here. Any pointers on what could be wrong with KFW?
 
Jeffrey Altman

David Bear wrote:
> I am using
>
> /usr/sbin/rxdebug -server pp-bvossoughi.dhcp.asu.edu
> <http://pp-bvossoughi.dhcp.asu.edu> -port 7001 -vers
>
> Trying 10.218.16.141 (port 7001):
> AFS version: OpenAFS_1.5.5400
>
> This system has had intermittent erros with accessing openafs. The issue
> seems to be always an access/token issue.
>
> KFW 3.2.2 is install and the user is able to get tokens in the asu.edu
> <http://asu.edu> realm. NIM show the TGT's.
>
> However, any attempt to use 'tokens' to display the afs tokens causes this:
>
> C:\Documents and Settings\bvossoug>tokens
> Tokens held by the Cache Manager:
>
> pioctl temp != 0: 0x66543218
>   --End of list --
>
> I googled and found someone with a similar error here:
> http://www.openafs.org/pipermail/openafs-info/2006-December/024568.html
>
> But I don't know if it could be related since there was no resolution on
> the thread and it is so old.
>
> I created an fs minidump and copied that ad the afsd_init.log to an afs
> location that should be world readable at
>
> /afs/asu.edu/pp/oss/afsDumps <http://asu.edu/pp/oss/afsDumps>
>
> ( the acl is set as system:anyuser so I hope the world can read this
> location )
>
> Any pointers on where to go next? (BTW, the issue seems to be tied to a
> specific user logon. I was able to log on to windows as myself, get
> tokens, and use afs)
>
> --
>
> David Bear
> College of Public Programs at ASU
> 602-464-0424



--
David Bear
College of Public Programs at ASU
602-464-0424
------=_Part_33691_32877454.1224705404574-- From jaltman@secure-endpoints.com Wed Oct 22 22:28:33 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Wed, 22 Oct 2008 17:28:33 -0400 Subject: [OpenAFS] openafs pioctl issue on windows In-Reply-To: <1d1a54bf0810221256y1143977pf648adc4a10221e4@mail.gmail.com> References: <1d1a54bf0810221205r75e30746o49dcff3c409e7638@mail.gmail.com> <48FF7C91.9070605@secure-endpoints.com> <1d1a54bf0810221256y1143977pf648adc4a10221e4@mail.gmail.com> Message-ID: <48FF9B01.9030908@secure-endpoints.com> If NIM is getting and listing tokens, then KFW is working just fine. pioctl error 0x66543218 means "End of List" The tokens command does not use KFW. It speaks to the AFS cache manager via the pioctl interface which is implemented as a file open/write/read/close sequence on a file called _._AFS_IOCTL_._ in the AFS name space. The file open is performed in the context of a particular SMB session. Each session has an authenticated identity. The tokens are stored in the AFS cache manager bound to the SMB authentication identity. If you are able to obtain/list tokens with NIM and not from tokens. It means that the two processes are running in different sessions and are authenticating over SMB using different identities. There is no way to monitor the SMB authentication identity other than by running the AFS cache manager under a debugger and intercepting the authentication requests. With oafw 1.5.54 if you use "fs memdump" it will output the list of tokens that are known as part of the output to %windir%\temp\afsd_alloc.log. However, it won't tell you what smb authentication session a command is executed under. As for your KFW error you will need to provide a lot more info. What version? What OS? What credential cache type:name? For example, if you are using the MSLSA: credential cache to make use of the Windows Logon credentials, you can't perform kinit. Jeffrey Altman David Bear wrote: > > > On Wed, Oct 22, 2008 at 12:18 PM, Jeffrey Altman > > wrote: > > NIM uses the same pioctl call as tokens.exe to obtain the tokens list. > > As long as they are being executed from within the same logon session > they will display the same results. > > Hint: "Run as ..." or "Run as administrator" produces a new logon > session. > > Okay -- I tried this from cmd, in a new session. > This failes. > C:\WINDOWS\system32>tokens > > Tokens held by the Cache Manager: > > --End of list -- > pioctl temp != 0: 0x66543218 > Then > C:\WINDOWS\system32>kinit iddwb > kinit(v5): Inappropriate I/O control operation while getting initial > credentials > > So, I guess kfw is not working properly here. Any pointers on what could > be wrong with KFW? > > > Jeffrey Altman > > David Bear wrote: > > I am using > > > > /usr/sbin/rxdebug -server pp-bvossoughi.dhcp.asu.edu > > > -port 7001 -vers > > > > Trying 10.218.16.141 (port 7001): > > AFS version: OpenAFS_1.5.5400 > > > > This system has had intermittent erros with accessing openafs. The > issue > > seems to be always an access/token issue. > > > > KFW 3.2.2 is install and the user is able to get tokens in the > asu.edu > > realm. NIM show the TGT's. > > > > However, any attempt to use 'tokens' to display the afs tokens > causes this: > > > > C:\Documents and Settings\bvossoug>tokens > > Tokens held by the Cache Manager: > > > > pioctl temp != 0: 0x66543218 > > --End of list -- > > > > I googled and found someone with a similar error here: > > > http://www.openafs.org/pipermail/openafs-info/2006-December/024568.html > > > > But I don't know if it could be related since there was no > resolution on > > the thread and it is so old. > > > > I created an fs minidump and copied that ad the afsd_init.log to > an afs > > location that should be world readable at > > > > /afs/asu.edu/pp/oss/afsDumps > > > > > ( the acl is set as system:anyuser so I hope the world can read this > > location ) > > > > Any pointers on where to go next? (BTW, the issue seems to be tied > to a > > specific user logon. I was able to log on to windows as myself, get > > tokens, and use afs) > > > > -- > > > > David Bear > > College of Public Programs at ASU > > 602-464-0424 > > > > > -- > David Bear > College of Public Programs at ASU > 602-464-0424 From steven.jenkins@gmail.com Thu Oct 23 02:53:11 2008 From: steven.jenkins@gmail.com (Steven Jenkins) Date: Wed, 22 Oct 2008 21:53:11 -0400 Subject: [OpenAFS] Unix Systems Programmer position at End Point Message-ID: The team I work in at End Point Corporation is looking for a strong self-starter developer with a good Unix systems programming background to work on the development and maintenance of software for a variety of projects. Required skills: * Strong communication skills and professionalism * Ability to dive into new technologies and quickly come up to speed * Strong C & Unix programming experience * Solid understanding and experience of full product lifecycle * Solid understanding of TCP/IP * Familiarity with representative protocols, architectural, and operational issues in large, distributed systems (e.g., Kerberos, RDBMS, DNS, LDAP, configuration management, backups, monitoring, etc.) * Experience with at least two of: Linux, Solaris, HP-UX, AIX, BSD * Knowledge of at least one scripting language (awk, Perl, Python, Ruby, etc.) Desired skills: * Familiarity with distributed and/or clustered filesystems (NFS, AFS, CIFS, GFS, NAS, etc.) * Kernel level knowledge and experience with Unix-based systems * Familiarity with RDBMS internals (e.g., DB2, Oracle, Sybase, MySQL, PostgreSQL, etc.) * Knowledge of Microsoft Windows internals Things that will set you apart: * strong Solaris administration and/or kernel development (dtrace, mdb, ZFS) * strong skills on non-Linux operating systems * a passion for analyzing core dumps (especially kernel dumps) * AFS operational knowledge * AFS development experience (e.g., prototypes of projects on the OpenAFS roadmap would be particularly interesting) * strong experience with configuration management systems (cfengine, bcfg, lcfg, quattor, Puppet, etc) * experience in automating virtual environments (e.g., libvirt, VMware Perl API, etc) More about the team & our work: * not a web development position (see End Point's website for those) * most of our work is currently in C (75%) * some in Perl and shell (20% -- mostly test scaffolding and automation, but some CPAN work, too) * some work in Ruby (5% currently, but varies depending on projects -- note that this is completely separate from the Ruby on Rails web development that other teams at End Point do). * other languages done occasionally (e.g., we've done a bit of Java & Python over the past year, but less than 1% of the other coding we've done) * projects in AFS, PostgreSQL internals, Ruby internals, Varnish, Quattor, Puppet, OpenSolaris and various Perl modules on CPAN (and in various Linux distributions) over the past year. This is a full-time salaried position with benefits. Employees work from home offices in the U.S., or at our office in Manhattan. Except in exceptional circumstances, applicants must be U.S. citizens or permanent residents. Principals only, please. Please email Steven Jenkins with information about your interest, experience, and qualifications. -- Steven Jenkins End Point Corporation http://www.endpoint.com/ From tdamato@odu.edu Thu Oct 23 18:54:36 2008 From: tdamato@odu.edu (Tony D'Amato) Date: Thu, 23 Oct 2008 13:54:36 -0400 Subject: [OpenAFS] OpenAFS 1.4.8pre3 on Solaris 10 x86 Message-ID: <4900BA5C.7090403@odu.edu> I've just installed OpenAFS 1.4.8pre3 on my Solaris 10 x86 workstation at work... so far, so good... I know there was a discussion some time ago about using SMF to manage OpenAFS, and I believe I've got it stable enough to share with the group if anyone is interested... -- Tony D'Amato, SCSA (it's Exchange that puts "Nicholas" there) Senior UNIX Systems Administrator Server Support Group, OCCS Old Dominion University From atro.tossavainen+openafs@helsinki.fi Thu Oct 23 19:55:05 2008 From: atro.tossavainen+openafs@helsinki.fi (Atro Tossavainen) Date: Thu, 23 Oct 2008 21:55:05 +0300 (EEST) Subject: [OpenAFS] OpenAFS 1.4.8pre3 on Solaris 10 x86 In-Reply-To: <4900BA5C.7090403@odu.edu> Message-ID: <200810231855.m9NIt5sw025234@ruuvi.it.helsinki.fi> > I know there was a discussion some time ago about using SMF to manage > OpenAFS, and I believe I've got it stable enough to share with the group > if anyone is interested... Absolutely. Please. -- Atro Tossavainen (Mr.) / The Institute of Biotechnology at Systems Analyst, Techno-Amish & / the University of Helsinki, Finland, +358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own. < URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS From tdamato@odu.edu Thu Oct 23 21:16:35 2008 From: tdamato@odu.edu (Tony D'Amato) Date: Thu, 23 Oct 2008 16:16:35 -0400 Subject: [OpenAFS] OpenAFS 1.4.8pre3 on Solaris 10 x86 In-Reply-To: <4900CED0.9050601@nd.edu> References: <4900BA5C.7090403@odu.edu> <4900CED0.9050601@nd.edu> Message-ID: <4900DBA3.1070408@odu.edu> This is a multi-part message in MIME format. --------------050303090207070505040600 Content-Type: multipart/alternative; boundary="------------050800030505050700090809" --------------050800030505050700090809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Rich Sudlow wrote: > Tony D'Amato wrote: > >> I've just installed OpenAFS 1.4.8pre3 on my Solaris 10 x86 workstation >> at work... so far, so good... >> >> I know there was a discussion some time ago about using SMF to manage >> OpenAFS, and I believe I've got it stable enough to share with the group >> if anyone is interested... >> >> > > Hi Tony > I'm interested in SMF also - If you could send it to me or > preferably to the list I think others would appreciate it. > Okay... you've talked me into it *grin* Please note that my SMF support is from the client side at this point. I'm preparing some Solaris 10 OpenAFS servers, so I'll have a chance to begin to play there. This SMF support has been pieced together from various mailing lists and thus include the original author's names - I take no credit for the original code except that this version works for me. YMMV. Basically, I use two files, a manifest and an exec method, attached below: openafs-client.xml, saved as /var/svc/manifest/network/openafs/client.xml openafs-client.sh, saved as /usr/vice/etc/openafs-client After copying them in place, I issue svccfg -v import /var/svc/manifest/network/openafs/client.xml svcadm -v enable network/openafs/client to fire it up. (The comparable server versions would have 'client' replaced with 'server', but I'm not prepared to share those yet, unless you really want to play with untested code...) Here they are. If anyone has any comments/concerns/gotchas that I may be unaware of, please let me know (and please be nice to me *grin*) Thanks! -- Tony D'Amato, SCSA (it's Exchange that puts "Nicholas" there) Senior UNIX Systems Administrator Server Support Group, OCCS Old Dominion University --------------050800030505050700090809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Rich Sudlow wrote:
Tony D'Amato wrote:
  
I've just installed OpenAFS 1.4.8pre3 on my Solaris 10 x86 workstation
at work... so far, so good...

I know there was a discussion some time ago about using SMF to manage
OpenAFS, and I believe I've got it stable enough to share with the group
if anyone is interested...

    

Hi Tony
        I'm interested in SMF also - If you could send it to me or
preferably to the list I think others would appreciate it.
  

Okay... you've talked me into it *grin*

Please note that my SMF support is from the client side at this point. I'm preparing some Solaris 10 OpenAFS servers, so I'll have a chance to begin to play there. This SMF support has been pieced together from various mailing lists and thus include the original author's names - I take no credit for the original code except that this version works for me. YMMV.

Basically, I use two files, a manifest and an exec method, attached below:

   openafs-client.xml, saved as /var/svc/manifest/network/openafs/client.xml

   openafs-client.sh, saved as /usr/vice/etc/openafs-client

After copying them in place, I issue

    svccfg -v import /var/svc/manifest/network/openafs/client.xml
    svcadm -v enable network/openafs/client

to fire it up. (The comparable server versions would have 'client' replaced with 'server', but I'm not prepared to share those yet, unless you really want to play with untested code...)

Here they are. If anyone has any comments/concerns/gotchas that I may be unaware of, please let me know (and please be nice to me *grin*) Thanks!
-- 
Tony D'Amato, SCSA (it's Exchange that puts "Nicholas" there)
Senior UNIX Systems Administrator
Server Support Group, OCCS
Old Dominion University
--------------050800030505050700090809-- --------------050303090207070505040600 Content-Type: text/xml; name="openafs-client.xml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="openafs-client.xml" --------------050303090207070505040600 Content-Type: text/plain; name="openafs-client.sh" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="openafs-client.sh" #!/bin/sh # # Copyright 2005. Coy Hile. All Rights Reserved # ident "@(#)openafs-client.sh 1.4 05/10/20" # # Service Management method for OpenAFS client # # We assume that the application is being installed using Transarc # paths. . /lib/svc/share/smf_include.sh AFSDB=`svcprop -p OpenAFS/afsdb svc:/network/openafs/client` DYNROOT=`svcprop -p OpenAFS/dynroot svc:/network/openafs/client` FAKESTAT=`svcprop -p OpenAFS/fakestat svc:/network/openafs/client` case "$1" in start) # # Make sure an entry for afs exists in /etc/name_to_sysnum. If not, # add it and reboot the system so that the changes take effect. # if grep -s "afs" /etc/name_to_sysnum > /dev/null; then echo "Entry for afs already exists in /etc/name_to_sysnum" else echo "Creating entry for afs in /etc/name_to_sysnum" cp /etc/name_to_sysnum /etc/name_to_sysnum.orig sed '/nfs/i\ afs 65' /etc/name_to_sysnum > /tmp/name_to_sysnum mv /tmp/name_to_sysnum /etc/name_to_sysnum #### don't automatically reboot #### #echo "Rebooting now for new /etc/name_to_sysnum to take effect" #sync; sync; sync #/etc/reboot echo "" echo "#######################################################################" echo "" echo " 'afs' entry was added/updated in /etc/name_to_sysnum." echo " You will need to reboot prior to running OpenAFS." echo " Skipping OpenAFS startup." echo "" echo "#######################################################################" echo "" echo "'afs' entry was added/updated in /etc/name_to_sysnum." >> /dev/console echo "You will need to reboot prior to running OpenAFS." >> /dev/console echo "Skipping OpenAFS startup." >> /dev/console exit 1 fi # Check that /bin/isalist is executable if [ ! -x /bin/isalist ]; then echo "/bin/isalist is not executable; skipping startup" exit 1; fi # Determine the right locations for the kernel modules and load them case `/bin/isalist` in *amd64* ) nfssrv=/kernel/misc/amd64/nfssrv afs=/kernel/fs/amd64/afs ;; *sparcv9* ) nfssrv=/kernel/misc/sparcv9/nfssrv afs=/kernel/fs/sparcv9/afs ;; * ) nfssrv=/kernel/misc/nfssrv afs=/kernel/fs/afs ;; esac if [ -f $nfssrv ]; then modid=`modinfo | awk '/nfssrv/ {print $1}'` if [ ! -z "$modid" ] ; then echo "NFS kernel extensions already loaded" else echo "Loading NFS server kernel module" modload $nfssrv fi else echo "$nfssrv does not exist. skipping AFS startup" exit 1 fi if [ -f $afs ]; then modid=`modinfo | awk '/afs .* filesystem/ {print $1}'` if [ ! -z "$modid" ] ; then echo "AFS kernel extensions already loaded" else echo "Loading AFS kernel module" modload $afs fi else echo "$afs does not exist. skipping AFS startup" exit 1 fi # Set up the server options and start the bosserver. OPTIONS= if [ "$AFSDB" = true ]; then OPTIONS="-afsdb" fi if [ "$DYNROOT" = true ]; then OPTIONS="$OPTIONS -dynroot" fi if [ "$FAKESTAT" = true ]; then OPTIONS="$OPTIONS -fakestat" fi # Check that the root directory for AFS and the client cache # directories both exist # for dir in `/usr/bin/awk -F: '{print $1,$2}' /usr/vice/etc/cacheinfo ` do if [ ! -d ${dir} ]; then echo "${dir} does no exist. Not starting AFS client" exit 2 fi done pgrep -f /usr/vice/etc/afsd >/dev/null if [ $? -eq 0 ]; then echo "AFS already running - not starting afsd" exit 0 else echo "Starting afsd" /usr/vice/etc/afsd $OPTIONS fi # end of start method ;; stop ) echo "Shutting down AFS client processes" cd / umount /afs /usr/vice/etc/afsd -shutdown -waitclose sleep 10 ################################################ ## WARNING - DO NOT unload the module! ## Causes Kernel Panics! ################################################ # unload kernel module # but not for afs server #if [ -x /usr/afs/bin/bosserver ]; then # echo "Kernel module not unloaded due to this machine is an afs server" #else # modid=`modinfo | awk '/afs .* filesystem/ {print $1}'` # if [ ! -z "$modid" ]; then # modunload -i $modid # [ $? -eq 0 ] && echo "Kernel module unloaded." # else # echo "No AFS kernel module loaded" # fi #fi ;; *) echo "Usage: $0 {start|stop}" exit 1 ;; esac --------------050303090207070505040600-- From rkemp@srhs.net Thu Oct 23 21:47:39 2008 From: rkemp@srhs.net (Randy Kemp) Date: Thu, 23 Oct 2008 16:47:39 -0400 Subject: [OpenAFS] File Server appears to stop responding In-Reply-To: <48F3A20F.2000205@srhs.net> References: <48DD3552.5070000@srhs.net> <20080927.131045.60540471.haba@habanero.pdc.kth.se> <48E071A6.3030708@srhs.net> <48F352B8.9040104@srhs.net> <48F357A8.8050709@srhs.net> <48F3A20F.2000205@srhs.net> Message-ID: <4900E2EB.70405@srhs.net> I'm still having this problem. I've done some more debugging to try and track down the cause. It occurred again today and I used 'cmdebug' to get info from the client and 'rxdebug' to get info from the server. I ran these from a machine independent of both the client and server in question. The interesting thing is that when I ran 'cmdebug' not only did it take a very long time to execute and display a huge list of locks but as soon as it completed both the client and server starting functioning properly. A subsequent run of 'cmdebug' displayed no locks. I suppose it's possible that this could be coincidental but this problem has occurred countless times and until now has never resolved itself and the client has always had to be restarted. Is it possible that 'cmdebug' could have triggered something in the client that caused it to un-hang? This is the first time I've used 'cmdebug' with it in this state. Clearly this is a client problem that puts the server in an inaccesable state. However, it seems to me that there is also a problem with fileserver since a single client can so easily cause it to be inaccessable to all clients. I'm now running 1.4.8pre2 on the server. The output of 'cmdebug' is below. I had to cut out the 'rxdebug' with rxstats output because of the list's message size limit. If anyone would like to see that I can send it too. $ cmdebug app1.thinland.srhs.net Lock afs_xvcache status: (reader_waitingwriter_waitingupgrade_waiting, write_locked(pid:21773 at:138), 207 waiters) Lock afs_xserver status: (none_waiting, 1 read_locks(pid:0)) Lock afs_xvcb status: (writer_waiting, write_locked(pid:6465 at:273), 4 waiters) ** Cache entry @ 0x559fc000 for 2.536872292.672.7299 [phoenix.srhs.net] locks: (none_waiting, upgrade_locked(pid:30572 at:121)) 10654496 bytes DV 0 refcnt 2 callback 53c6ce00 expires 1224796783 1 opens 1 writers normal file states (0x21), stat'd ** Cache entry @ 0x36003000 for 2.536871938.2.206 [phoenix.srhs.net] locks: (upgrade_waiting, upgrade_locked(pid:2729 at:121), 2 waiters) 396689 bytes DV 1435 refcnt 2 callback 53c6ce00 expires 1224782830 2 opens 2 writers normal file states (0x21), stat'd ** Cache entry @ 0x85d22700 for 2.536874302.714.5569 [phoenix.srhs.net] locks: (none_waiting, upgrade_locked(pid:18490 at:121)) 64554 bytes DV 1 refcnt 2 callback 53c6ce00 expires 1224796655 1 opens 1 writers normal file states (0x21), stat'd ** Cache entry @ 0x7487e380 for 2.536874044.2.206 [phoenix.srhs.net] locks: (writer_waitingupgrade_waiting, upgrade_locked(pid:2584 at:121), 6 waiters) 385251 bytes DV 1315 refcnt 2 callback 53c6ce00 expires 1224788718 1 opens 1 writers normal file states (0x21), stat'd ** Cache entry @ 0x5e540700 for 2.536871620.402.4804 [phoenix.srhs.net] locks: (none_waiting, upgrade_locked(pid:16183 at:121)) 56025088 bytes DV 561 refcnt 2 callback 53c6ce00 expires 1224783726 1 opens 1 writers normal file states (0x21), stat'd ** Cache entry @ 0x69819a80 for 2.536873822.288.3237 [phoenix.srhs.net] locks: (none_waiting, upgrade_locked(pid:30568 at:121)) 54714368 bytes DV 542 refcnt 2 callback 53c6ce00 expires 1224796783 1 opens 1 writers normal file states (0x21), stat'd ** Cache entry @ 0xccc5fa80 for 2.536874170.992.13816 [phoenix.srhs.net] locks: (upgrade_waiting, upgrade_locked(pid:3674 at:121), 5 waiters) 514657 bytes DV 43 refcnt 2 callback 53c6ce00 expires 1224796527 1 opens 1 writers normal file states (0x21), stat'd ** Cache entry @ 0x7b104000 for 2.536874170.994.13854 [phoenix.srhs.net] locks: (none_waiting, upgrade_locked(pid:13553 at:121)) 64948 bytes DV 1 refcnt 2 callback 53c6ce00 expires 1224796655 1 opens 1 writers normal file states (0x21), stat'd ** Cache entry @ 0x0985f380 for 2.536874200.2.606 [phoenix.srhs.net] locks: (upgrade_waiting, upgrade_locked(pid:2725 at:121), 4 waiters) 226343 bytes DV 842 refcnt 2 callback 53c6ce00 expires 1224782830 1 opens 1 writers normal file states (0x21), stat'd ** Cache entry @ 0x721d7700 for 2.536873201.2.606 [phoenix.srhs.net] locks: (none_waiting, upgrade_locked(pid:3482 at:121)) 304988 bytes DV 941 refcnt 2 callback 53c6ce00 expires 1224796655 1 opens 1 writers normal file states (0x21), stat'd ** Cache entry @ 0x3ddb6700 for 2.536876402.908.11304 [phoenix.srhs.net] locks: (none_waiting, upgrade_locked(pid:24115 at:121)) 62072 bytes DV 10 refcnt 2 callback 53c6ce00 expires 1224796655 1 opens 1 writers normal file states (0x21), stat'd ** Cache entry @ 0x7198d700 for 2.536873378.892.10147 [phoenix.srhs.net] locks: (writer_waitingupgrade_waiting, write_locked(pid:28527 at:66), 3 waiters) 505958 bytes DV 25 refcnt 2 callback 53c6ce00 expires 1224796782 2 opens 2 writers normal file states (0x21), stat'd ** Cache entry @ 0x0c4b3000 for 2.536874302.27.24 [phoenix.srhs.net] locks: (none_waiting, write_locked(pid:18490 at:147)) 2048 bytes DV 719 refcnt 2 callback 53c6ce00 expires 1224796655 0 opens 0 writers normal file states (0x1), stat'd ** Cache entry @ 0xe50f8380 for 2.536872292.2.606 [phoenix.srhs.net] locks: (writer_waitingupgrade_waiting, upgrade_locked(pid:4888 at:121), 12 waiters) 462170 bytes DV 1271 refcnt 2 callback 53c6ce00 expires 1224782958 2 opens 2 writers normal file states (0x21), stat'd ** Cache entry @ 0x1cc66000 for 2.536874344.1.1 [phoenix.srhs.net] locks: (none_waiting, write_locked(pid:5920 at:135)) 4096 bytes DV 1275 refcnt 2 callback 53c6ce00 expires 1224797295 0 opens 0 writers volume root states (0x1), stat'd ** Cache entry @ 0x820cea80 for 2.536876324.114.7527 [phoenix.srhs.net] locks: (none_waiting, upgrade_locked(pid:401 at:121)) 144 bytes DV 0 refcnt 2 callback 53c6ce00 expires 1224797295 1 opens 1 writers normal file states (0x21), stat'd ** Cache entry @ 0x6983ba80 for 2.536874368.31.229 [phoenix.srhs.net] locks: (none_waiting, write_locked(pid:3380 at:54)) 0 bytes DV 0 refcnt 2 callback 53c6ce00 expires 0 0 opens 0 writers normal file states (0x0) ** Cache entry @ 0x884c0700 for 2.536873363.33.31 [phoenix.srhs.net] locks: (none_waiting, write_locked(pid:5660 at:54)) 9840 bytes DV 0 refcnt 2 callback 53c6ce00 expires 0 0 opens 0 writers normal file states (0x0) ** Cache entry @ 0xd8d66380 for 2.536874755.690.5213 [phoenix.srhs.net] locks: (none_waiting, upgrade_locked(pid:27886 at:121)) 57968 bytes DV 26 refcnt 2 callback 53c6ce00 expires 1224796783 1 opens 1 writers normal file states (0x21), stat'd ** Cache entry @ 0xb9979380 for 2.536876381.91.1631 [phoenix.srhs.net] locks: (none_waiting, write_locked(pid:13043 at:54)) 2048 bytes DV 242 refcnt 3 callback 53c6ce00 expires 1224782446 0 opens 0 writers normal file states (0x0) ** Cache entry @ 0x14d7e000 for 2.536873405.1.1 [phoenix.srhs.net] locks: (none_waiting, write_locked(pid:5824 at:135)) 4096 bytes DV 1173 refcnt 2 callback 53c6ce00 expires 1224797295 0 opens 0 writers volume root states (0x1), stat'd ** Cache entry @ 0xb2409700 for 2.536872703.712.7884 [phoenix.srhs.net] locks: (none_waiting, upgrade_locked(pid:28492 at:121)) 2382 bytes DV 0 refcnt 2 callback 53c6ce00 expires 1224797295 1 opens 1 writers normal file states (0x21), stat'd ** Cache entry @ 0x461bc000 for 2.536876402.1114.11312 [phoenix.srhs.net] locks: (none_waiting, upgrade_locked(pid:17206 at:121)) 121827 bytes DV 1 refcnt 2 callback 53c6ce00 expires 1224796783 1 opens 1 writers normal file states (0x21), stat'd ** Cache entry @ 0xd8c99a80 for 2.536872703.734.7872 [phoenix.srhs.net] locks: (upgrade_waiting, upgrade_locked(pid:5823 at:121), 2 waiters) 503437 bytes DV 15 refcnt 2 callback 53c6ce00 expires 1224796783 1 opens 1 writers normal file states (0x21), stat'd ** Cache entry @ 0x558ad700 for 2.536874470.2.606 [phoenix.srhs.net] locks: (upgrade_waiting, upgrade_locked(pid:5894 at:121), 3 waiters) 250418 bytes DV 894 refcnt 2 callback 53c6ce00 expires 1224796782 1 opens 1 writers normal file states (0x21), stat'd ** Cache entry @ 0x3dd60a80 for 2.536876402.128.3198 [phoenix.srhs.net] locks: (none_waiting, upgrade_locked(pid:24115 at:121)) 1015808 bytes DV 2032 refcnt 2 callback 53c6ce00 expires 1224797295 1 opens 1 writers normal file states (0x21), stat'd ** Cache entry @ 0x0c45d000 for 2.536874512.2.206 [phoenix.srhs.net] locks: (writer_waitingupgrade_waiting, write_locked(pid:27196 at:66), 12 waiters) 189750 bytes DV 897 refcnt 2 callback 53c6ce00 expires 1224796783 3 opens 3 writers normal file states (0x21), stat'd ** Cache entry @ 0xd8d0e380 for 2.536873378.131.2007 [phoenix.srhs.net] locks: (none_waiting, write_locked(pid:25829 at:135)) 2048 bytes DV 102 refcnt 2 callback 53c6ce00 expires 1224784111 0 opens 0 writers normal file states (0x1), stat'd ** Cache entry @ 0x8d02e380 for 2.536874695.884.9977 [phoenix.srhs.net] locks: (writer_waitingupgrade_waiting, write_locked(pid:3822 at:66), 14 waiters) 512293 bytes DV 48 refcnt 2 callback 53c6ce00 expires 1224796527 6 opens 6 writers normal file states (0x21), stat'd ** Cache entry @ 0x46096380 for 2.536874014.545.9379 [phoenix.srhs.net] locks: (none_waiting, write_locked(pid:22297 at:616)) 2048 bytes DV 0 refcnt 2 callback 00000000 expires 1224797295 0 opens 0 writers normal file states (0x0) ** Cache entry @ 0x68187380 for 2.536874470.101.1024 [phoenix.srhs.net] locks: (none_waiting, write_locked(pid:29269 at:135)) 2048 bytes DV 42 refcnt 2 callback 53c6ce00 expires 1224784111 0 opens 0 writers normal file states (0x1), stat'd ** Cache entry @ 0x46d07000 for 2.536874602.25.222 [phoenix.srhs.net] locks: (none_waiting, write_locked(pid:5932 at:54)) 2048 bytes DV 0 refcnt 2 callback 53c6ce00 expires 0 0 opens 0 writers normal file states (0x0) ** Cache entry @ 0xcad4c000 for 2.536874512.137.2220 [phoenix.srhs.net] locks: (none_waiting, write_locked(pid:26552 at:135)) 2048 bytes DV 62 refcnt 2 callback 53c6ce00 expires 1224784111 0 opens 0 writers normal file states (0x1), stat'd ** Cache entry @ 0xcad4c000 for 2.536874512.137.2220 [phoenix.srhs.net] locks: (none_waiting, write_locked(pid:26552 at:135)) 2048 bytes DV 62 refcnt 2 callback 53c6ce00 expires 1224784111 0 opens 0 writers normal file states (0x1), stat'd Randy Kemp wrote: > It did it again as suspected. The requested backtrace is attached. > It's inaccessible from any client (not just the app server) on all > interfaces. No one will need to use AFS or the app server for the > remainder of the day so I will leave it in this state in case anyone > comes up with some other bit of info that might be useful to retrieve. > > Randy Kemp wrote: >> Derrick Brashear wrote: >>> On Mon, Oct 13, 2008 at 9:52 AM, Randy Kemp wrote: >>> >>>> I had users again today to test with. The problem with fileserver >>>> ceasing to respond and generating the "CallPreamble: Couldn't get CPS. >>>> Too many lockers" error occurred again. >>>> >>> To the app server, or to both machines? I assume, actually, only to >>> the app server. >>> >> The last time it occurred (when I sent the first message) it stopped >> responding to all connected clients. I did not think to test that this. >>>> I'm now running fileserver with the following parameters, "-p 128 >>>> -b 512 >>>> -l 3072 -s 3072 -vc 3072 -cb 65536 -busyat 1536 -rxpck 1024 -nojumbo". >>>> At the time that the problem started there were two physical clients >>>> connected, one was a standalone workstation and the other was the >>>> aforementioned application server with approximately 40 users logged >>>> in. All requests from said application server are now coming from a >>>> single address to a single interface on the AFS server. >>>> It turns out that restarting AFS vs. rebooting the server does >>>> not make >>>> the problem go away as I previously thought. It was purely >>>> coincidental >>>> that I had also restarted the application server last time. What I >>>> have >>>> now discovered is that even rebooting the AFS server does not resolve >>>> the problem (errors start immediately upon startup) and it now appears >>>> that the problem is only resolved by restarting the client on the >>>> application server. The application server is running OpenAFS client >>>> version 1.4.7 on Ubuntu Linux with kernel version 2.6.24. >>>> >>> >>> echo t > /proc/sysrq-trigger on the application server, as root, when >>> the fileserver won't talk to it, collect the system log from e.g. >>> /var/log/messages with the backtrace in it, and let us see that. >>> >> I have about 90 users that will try to log in to the app server later >> today so I'm sure it will do it again. I'll do this and test it from >> other clients if/when it happens. -- Randy Kemp From john@cs.wisc.edu Thu Oct 23 22:14:43 2008 From: john@cs.wisc.edu (John Perkins) Date: Thu, 23 Oct 2008 16:14:43 -0500 Subject: [OpenAFS] Delays starting AFS client 1.5.5400/1.5.5403 for Windows XP Message-ID: <20081023161443.83594ed5.john@cs.wisc.edu> We've seen a handful of computers at our site get stuck during the AFS initialization sequence. Here is a snippet from the afsd_init.log: 10/23/2008 3:07:31 PM: cm_GetRootCellName code 0, cm_freelanceEnabled= 1, rcn= c s.wisc.edu 10/23/2008 3:07:31 PM: Mountpoint[0] = .cs%cs.wisc.edu:root.cell. 10/23/2008 3:07:31 PM: Mountpoint[1] = .cs.wisc.edu%cs.wisc.edu:root.cell. 10/23/2008 3:07:31 PM: Mountpoint[2] = cs.wisc.edu#cs.wisc.edu:root.cell. 10/23/2008 3:07:31 PM: Mountpoint[3] = @cell#cs.wisc.edu:root.cell. 10/23/2008 3:07:31 PM: Mountpoint[4] = cs#cs.wisc.edu:root.cell. 10/23/2008 3:07:31 PM: Mountpoint[5] = .@cell%cs.wisc.edu:root.cell. 10/23/2008 3:07:31 PM: cm_GetSCache code 0 scache 2a1f408 10/23/2008 3:07:31 PM: cm_InitDaemon complete 10/23/2008 3:07:31 PM: RPC server listening 10/23/2008 3:07:31 PM: MpsSvc Service could not be opened for query: 0x424 10/23/2008 3:07:31 PM: StoreAnsiFilenames = 0 10/23/2008 3:07:31 PM: EnableSMBAsyncStore = 1 10/23/2008 3:07:31 PM: AutoStart 0x2 10/23/2008 3:07:31 PM: SMBAsyncStoreSize = 131072 10/23/2008 3:07:31 PM: daemonCheckDownInterval is 180 10/23/2008 3:07:31 PM: LAN adapter number 3 10/23/2008 3:07:31 PM: daemonCheckUpInterval is 240 10/23/2008 3:07:31 PM: Using >AFS< as SMB server name 10/23/2008 3:07:31 PM: daemonCheckVolInterval is 3600 10/23/2008 3:07:31 PM: smb_localNamep is >AFS< 10/23/2008 3:07:31 PM: daemonCheckCBInterval is 60 10/23/2008 3:07:31 PM: Netbios NCBRESET lana 3 succeeded 10/23/2008 3:07:31 PM: daemonCheckVolCBInterval is 0 10/23/2008 3:07:31 PM: lana_list.length 1 10/23/2008 3:07:31 PM: daemonCheckLockInterval is 60 10/23/2008 3:07:31 PM: daemonCheckTokenInterval is 180 10/23/2008 3:07:31 PM: daemonCheckOfflineVolInterval is 600 10/23/2008 3:07:31 PM: daemonPerformanceTuningInterval is 0 10/23/2008 3:07:34 PM: Netbios NCBADDNAME lana=3 code=0 retcode=0 complete=0 10/23/2008 3:07:34 PM: Netbios NCBADDNAME added new name >AFS < 10/23/2008 3:07:34 PM: Netbios NCBADDNAME succeeded on lana 3 10/23/2008 3:07:34 PM: smb_NetbiosInit smb_LANadapter=3 10/23/2008 3:07:34 PM: Setting SMB server domain name to [RACHEL] 10/23/2008 3:07:34 PM: smb_StartListeners 10/23/2008 3:07:34 PM: smb_Init complete 10/23/2008 3:07:34 PM: Windows Firewall Configuration succeeded 10/23/2008 3:07:34 PM: GlobalAutoMap thread completed 10/23/2008 3:28:23 PM: Mountpoint[0] = .cs%cs.wisc.edu:root.cell. 10/23/2008 3:28:23 PM: Mountpoint[1] = .cs.wisc.edu%cs.wisc.edu:root.cell. 10/23/2008 3:28:23 PM: Mountpoint[2] = cs.wisc.edu#cs.wisc.edu:root.cell. 10/23/2008 3:28:23 PM: Mountpoint[3] = @cell#cs.wisc.edu:root.cell. 10/23/2008 3:28:23 PM: Mountpoint[4] = cs#cs.wisc.edu:root.cell. 10/23/2008 3:28:23 PM: Mountpoint[5] = .@cell%cs.wisc.edu:root.cell. Once we see the Mountpoint[x] entries show up, the AFS client is running properly. My question is what would cause this to wait 20 minutes before this continues on. I did collect an "fs trace" log (trace starting when server starts) in /afs/cs.wisc.edu/u/j/o/john/public/html/winafs-logs/1.5.5403-delay If anyone can shed some light on what might be causing this delay, please enlighten me. -- ============================================================================ John Perkins | University of Wisconsin-Madison Researcher | Department of Computer Science john@cs.wisc.edu | 1210 W. Dayton St. 608-262-0438/608-262-6626 FAX | Madison, WI 53706-1685 ============================================================================ From David.Bear@asu.edu Thu Oct 23 23:56:07 2008 From: David.Bear@asu.edu (David Bear) Date: Thu, 23 Oct 2008 15:56:07 -0700 Subject: [OpenAFS] openafs pioctl issue on windows In-Reply-To: <48FF9B01.9030908@secure-endpoints.com> References: <1d1a54bf0810221205r75e30746o49dcff3c409e7638@mail.gmail.com> <48FF7C91.9070605@secure-endpoints.com> <1d1a54bf0810221256y1143977pf648adc4a10221e4@mail.gmail.com> <48FF9B01.9030908@secure-endpoints.com> Message-ID: <1d1a54bf0810231556i78e6c26fk7e612da83d9f6a35@mail.gmail.com> ------=_Part_59797_23797965.1224802567144 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Comments inline below.. On Wed, Oct 22, 2008 at 2:28 PM, Jeffrey Altman < jaltman@secure-endpoints.com> wrote: > If NIM is getting and listing tokens, then KFW is working just fine. > > pioctl error 0x66543218 means "End of List" > Okay, I generated garbage for you. Sorry. I thought I could produce this remotely, so I did a psexec shell and captured this info. Clearly, I would be been using a different smb session than the primary user. > The tokens command does not use KFW. It speaks to the AFS cache manager > via the pioctl interface which is implemented as a file > open/write/read/close sequence on a file called _._AFS_IOCTL_._ in the > AFS name space. The file open is performed in the context of a > particular SMB session. Each session has an authenticated identity. > The tokens are stored in the AFS cache manager bound to the SMB > authentication identity. > > I have been back to the system, logged in with the users credentials instead of my own and generated the afsd_alloc.log. It is on /afs/ asu.edu/pp/oss/afsDumps along with the output of klist, a screen shot of NIM and the configuration files I use with I install KfW. > > With oafw 1.5.54 if you use "fs memdump" it will output the list of > tokens that are known as part of the output to > %windir%\temp\afsd_alloc.log. However, it won't tell you what smb > authentication session a command is executed under. > KFW is version 3.2.2 -- resintalled today. Windows is XP Pro with SP2 credential cache is API: -- we do make use of windows logon credentials. I've stopped using kinit and only use NIM to get and destroy tickets. I do succesfully get tickets in asu.edu, as the output of klist shows: Ticket cache: API:bvossoug@ASU.EDU Default principal: bvossoug@ASU.EDU Valid starting Expires Service principal 10/23/08 15:34:38 10/24/08 01:34:39 krbtgt/ASU.EDU@ASU.EDU renew until 10/30/08 15:30:56 but I'm not getting the afs@asu.edu credential.. ?? why? So, does this indicate the problem is with KfW instead of openafs? > > > > On Wed, Oct 22, 2008 at 12:18 PM, Jeffrey Altman > > > > wrote: > > > > NIM uses the same pioctl call as tokens.exe to obtain the tokens > list. > > > > As long as they are being executed from within the same logon session > > they will display the same results. > > > > Hint: "Run as ..." or "Run as administrator" produces a new logon > > session. > > > > Okay -- I tried this from cmd, in a new session. > > This failes. > > C:\WINDOWS\system32>tokens > > > > Tokens held by the Cache Manager: > > > > --End of list -- > > pioctl temp != 0: 0x66543218 > > Then > > C:\WINDOWS\system32>kinit iddwb > > kinit(v5): Inappropriate I/O control operation while getting initial > > credentials > > > > So, I guess kfw is not working properly here. Any pointers on what could > > be wrong with KFW? > > > > > > Jeffrey Altman > > > > David Bear wrote: > > > I am using > > > > > > /usr/sbin/rxdebug -server pp-bvossoughi.dhcp.asu.edu > > > > > -port 7001 -vers > > > > > > Trying 10.218.16.141 (port 7001): > > > AFS version: OpenAFS_1.5.5400 > > > > > > This system has had intermittent erros with accessing openafs. The > > issue > > > seems to be always an access/token issue. > > > > > > KFW 3.2.2 is install and the user is able to get tokens in the > > asu.edu > > > realm. NIM show the TGT's. > > > > > > However, any attempt to use 'tokens' to display the afs tokens > > causes this: > > > > > > C:\Documents and Settings\bvossoug>tokens > > > Tokens held by the Cache Manager: > > > > > > pioctl temp != 0: 0x66543218 > > > --End of list -- > > > > > > I googled and found someone with a similar error here: > > > > > > http://www.openafs.org/pipermail/openafs-info/2006-December/024568.html > > > > > > But I don't know if it could be related since there was no > > resolution on > > > the thread and it is so old. > > > > > > I created an fs minidump and copied that ad the afsd_init.log to > > an afs > > > location that should be world readable at > > > > > > /afs/asu.edu/pp/oss/afsDumps > > > > > > > > ( the acl is set as system:anyuser so I hope the world can read > this > > > location ) > > > > > > Any pointers on where to go next? (BTW, the issue seems to be tied > > to a > > > specific user logon. I was able to log on to windows as myself, get > > > tokens, and use afs) > > > > > > -- > > > > > > David Bear > > > College of Public Programs at ASU > > > 602-464-0424 > > > > > > > > > > -- > > David Bear > > College of Public Programs at ASU > > 602-464-0424 > > > -- David Bear College of Public Programs at ASU 602-464-0424 ------=_Part_59797_23797965.1224802567144 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Comments inline below..

On Wed, Oct 22, 2008 at 2:28 PM, Jeffrey Altman <jaltman@secure-endpoints.com> wrote:
If NIM is getting and listing tokens, then KFW is working just fine.

pioctl error 0x66543218 means "End of List"
Okay, I generated garbage for you. Sorry. I thought I could produce this remotely, so I did a psexec shell and captured this info. Clearly, I would be been using a different smb session than the primary user.
 
The tokens command does not use KFW.  It speaks to the AFS cache manager
via the pioctl interface which is implemented as a file
open/write/read/close sequence on a file called _._AFS_IOCTL_._ in the
AFS name space.  The file open is performed in the context of a
particular SMB session.  Each session has an authenticated identity.
The tokens are stored in the AFS cache manager bound to the SMB
authentication identity.

I have been back to the system, logged in with the users credentials instead of my own and generated the afsd_alloc.log. It is on /afs/asu.edu/pp/oss/afsDumps along with the output of klist, a screen shot of NIM and the configuration files I use with I install KfW.
 

With oafw 1.5.54 if you use "fs memdump" it will output the list of
tokens that are known as part of the output to
%windir%\temp\afsd_alloc.log.  However, it won't tell you what smb
authentication session a command is executed under.
KFW is version 3.2.2 -- resintalled today.
Windows is XP Pro with SP2
credential cache is API: -- we do make use of windows logon credentials.
I've stopped using kinit and only use NIM to get and destroy tickets. I do succesfully get tickets in asu.edu,  as the output of klist shows:
Ticket cache: API:bvossoug@ASU.EDU
Default principal: bvossoug@ASU.EDU

Valid starting Expires Service principal
10/23/08 15:34:38 10/24/08 01:34:39 krbtgt/ASU.EDU@ASU.EDU
 renew until 10/30/08 15:30:56

but I'm not getting the afs@asu.edu credential.. ?? why?
So, does this indicate the problem is with KfW instead of openafs? 
>
>
> On Wed, Oct 22, 2008 at 12:18 PM, Jeffrey Altman
> <jaltman@secure-endpoints.com <mailto:jaltman@secure-endpoints.com>> wrote:
>
>     NIM uses the same pioctl call as tokens.exe to obtain the tokens list.
>
>     As long as they are being executed from within the same logon session
>     they will display the same results.
>
>     Hint: "Run as ..." or "Run as administrator" produces a new logon
>     session.
>
> Okay -- I tried this from cmd, in a new session.
> This failes.
> C:\WINDOWS\system32>tokens
>
> Tokens held by the Cache Manager:
>
>   --End of list --
> pioctl temp != 0: 0x66543218
> Then
> C:\WINDOWS\system32>kinit iddwb
> kinit(v5): Inappropriate I/O control operation while getting initial
> credentials
>
> So, I guess kfw is not working properly here. Any pointers on what could
> be wrong with KFW?
>
>
>     Jeffrey Altman
>
>     David Bear wrote:
>     > I am using
>     >
>     > /usr/sbin/rxdebug -server pp-bvossoughi.dhcp.asu.edu
>     <http://pp-bvossoughi.dhcp.asu.edu>
>     > <http://pp-bvossoughi.dhcp.asu.edu> -port 7001 -vers
>     >
>     > Trying 10.218.16.141 (port 7001):
>     > AFS version: OpenAFS_1.5.5400
>     >
>     > This system has had intermittent erros with accessing openafs. The
>     issue
>     > seems to be always an access/token issue.
>     >
>     > KFW 3.2.2 is install and the user is able to get tokens in the
>     asu.edu <http://asu.edu>
>     > <http://asu.edu> realm. NIM show the TGT's.
>     >
>     > However, any attempt to use 'tokens' to display the afs tokens
>     causes this:
>     >
>     > C:\Documents and Settings\bvossoug>tokens
>     > Tokens held by the Cache Manager:
>     >
>     > pioctl temp != 0: 0x66543218
>     >   --End of list --
>     >
>     > I googled and found someone with a similar error here:
>     >
>     http://www.openafs.org/pipermail/openafs-info/2006-December/024568.html
>     >
>     > But I don't know if it could be related since there was no
>     resolution on
>     > the thread and it is so old.
>     >
>     > I created an fs minidump and copied that ad the afsd_init.log to
>     an afs
>     > location that should be world readable at
>     >
>     > /afs/asu.edu/pp/oss/afsDumps <http://asu.edu/pp/oss/afsDumps>
>     <http://asu.edu/pp/oss/afsDumps>
>     >
>     > ( the acl is set as system:anyuser so I hope the world can read this
>     > location )
>     >
>     > Any pointers on where to go next? (BTW, the issue seems to be tied
>     to a
>     > specific user logon. I was able to log on to windows as myself, get
>     > tokens, and use afs)
>     >
>     > --
>     >
>     > David Bear
>     > College of Public Programs at ASU
>     > 602-464-0424
>
>
>
>
> --
> David Bear
> College of Public Programs at ASU
> 602-464-0424





--
David Bear
College of Public Programs at ASU
602-464-0424
------=_Part_59797_23797965.1224802567144-- From lorenl@north-winds.org Fri Oct 24 01:05:54 2008 From: lorenl@north-winds.org (Loren M. Lang) Date: Thu, 23 Oct 2008 17:05:54 -0700 Subject: [OpenAFS] OpenAFS Quotas Message-ID: <1224806754.18201.19.camel@ruth.aloha.tallye.com> --=-e28oX3Xd/NH1k+oA6/C4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I have a dedicated partition for my OpenAFS server mounted at /vicepa and several volumes on it. Do I need to make sure that the total of all the quotas on all my volumes do not exceed my partition size or does OpenAFS handle a full partition without causing corruption to volumes. =20 Also, how do quotas affect read-only and backup volumes on the same partition, does the read-only volume inherit it's quota from the RW volume possibly doubling the space requirements in case the RW version changes significantly before the next release? I was experimenting with exceeding the quota on an otherwise empty volume. The quota was 1024K. When I cp /dev/zero to the volume, I naturally get a Quota exceeded error and the cp fails, however, my concern is that the resulting file is zero bytes long. With such a small quota, I can believe that cp might try to write it all at once and fail so I tried using dd instead with obs=3D512. This should ensure that each write is only 512 bytes long and all but the last write should be written, however, the file remains at zero bytes and fs quota reports me at 1%. I tried using dd to write 512K bytes instead which succeeded and fs quota reports me at 51% of my quota. I created a second file with the same command and it succeeded putting me at 101% of my quota. At this point I can't even create files which is expected. Maybe I am just hitting a quirk with such a small quota, but I am just concerned that data is being lost unnecessarily when I hit the quota. --=20 Loren M. Lang lorenl@north-winds.org http://www.north-winds.org/ Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B --=-e28oX3Xd/NH1k+oA6/C4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBJARFi3O67OXZU3lsRAgQsAJ0ZGgUKE4koLvCAhiStex0qoWUWWgCeK3if P5yCztrKpTMlD6fC42+Y0/M= =gVFY -----END PGP SIGNATURE----- --=-e28oX3Xd/NH1k+oA6/C4-- From mizmoose@gmail.com Fri Oct 24 01:54:41 2008 From: mizmoose@gmail.com (Esther Filderman) Date: Thu, 23 Oct 2008 20:54:41 -0400 Subject: [OpenAFS] OpenAFS Quotas In-Reply-To: <1224806754.18201.19.camel@ruth.aloha.tallye.com> References: <1224806754.18201.19.camel@ruth.aloha.tallye.com> Message-ID: On Thu, Oct 23, 2008 at 8:05 PM, Loren M. Lang wrote: > I have a dedicated partition for my OpenAFS server mounted at /vicepa > and several volumes on it. Do I need to make sure that the total of all > the quotas on all my volumes do not exceed my partition size or does > OpenAFS handle a full partition without causing corruption to volumes. Some people do this to ease the management of their cell. Some people do load balancing, whether automagically (via 3rd party tools) or by hand, when partitions start to get full. That said, when a partition on a server gets full, moving volumes off of it becomes a minor nightmare. Generally to make a clean move, you need to be able to make a copy, and without that room, the move can't happen. (To make a move, it's basically done by locking the volume, making a copy, releasing the lock [so the user sees little "down" time], dumping the copy to the new location, re-locking the volume, doing an incremental copy [if needed] and unlocking and dumping that, then bringing the new volume online & telling things that the location of the volume has changed.) However, I understand there's now a "-live" switch that lets you move a volume without making a copy, but that means that the volume is locked the whole time, so no changes can happen. This means more downtime for the user. > Also, how do quotas affect read-only and backup volumes on the same > partition, does the read-only volume inherit it's quota from the RW > volume possibly doubling the space requirements in case the RW version > changes significantly before the next release? *local* RO and backup volumes on the same partition (as opposed ro read-only copies on other servers) should not completely double the space used, as they share some ... um. yeah, brain freeze here, sorry. Anyway. They're not literal clones, so they don't use up the same literal amount of space. However, the perceived quota is the same. If the RW is set to 5G of space, the RO and the backup volume appear to be 5G of space. Only a RO copy on another site will truly use that 5G. (How big will the local copy actually be? That depends on a variety of things including, most importantly, what has changed since the clone was created.) [...] > this point I can't even create files which is expected. Maybe I am just > hitting a quirk with such a small quota, but I am just concerned that > data is being lost unnecessarily when I hit the quota. In the early days of AFS there was a bug where you would go to move a file into a new volume, the volume would fill up, and it would unlink (delete) the original before going, "Hey, there's no room!" and giving you a 0 length file. This was quickly fixed so if you move a file to a volume and fill up the volume, yes, you may get a 0 length file at the new site, but the old file isn't deleted. moose From jaltman@secure-endpoints.com Fri Oct 24 03:07:47 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 23 Oct 2008 19:07:47 -0700 Subject: [OpenAFS] Delays starting AFS client 1.5.5400/1.5.5403 for Windows XP In-Reply-To: <20081023161443.83594ed5.john@cs.wisc.edu> References: <20081023161443.83594ed5.john@cs.wisc.edu> Message-ID: <49012DF3.1040308@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms080902020305060801030801 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit John: Quite simple really. You have \\afs\cs.wisc.edu\s\std\bin in the PATH environment variable under which the afsd_service.exe is started. The end result is that every time afsd_service.exe tries to load a dll the computer tries to access \\afs\cs.wisc.edu\s\std\bin and times out because "guess what?" the afs service has not yet started. Jeffrey Altman Secure Endpoints Inc. John Perkins wrote: > We've seen a handful of computers at our site get stuck during the > AFS initialization sequence. Here is a snippet from the afsd_init.log: > > 10/23/2008 3:07:31 PM: cm_GetRootCellName code 0, cm_freelanceEnabled= 1, rcn= c > s.wisc.edu > 10/23/2008 3:07:31 PM: Mountpoint[0] = .cs%cs.wisc.edu:root.cell. > 10/23/2008 3:07:31 PM: Mountpoint[1] = .cs.wisc.edu%cs.wisc.edu:root.cell. > 10/23/2008 3:07:31 PM: Mountpoint[2] = cs.wisc.edu#cs.wisc.edu:root.cell. > 10/23/2008 3:07:31 PM: Mountpoint[3] = @cell#cs.wisc.edu:root.cell. > 10/23/2008 3:07:31 PM: Mountpoint[4] = cs#cs.wisc.edu:root.cell. > 10/23/2008 3:07:31 PM: Mountpoint[5] = .@cell%cs.wisc.edu:root.cell. > 10/23/2008 3:07:31 PM: cm_GetSCache code 0 scache 2a1f408 > 10/23/2008 3:07:31 PM: cm_InitDaemon complete > 10/23/2008 3:07:31 PM: RPC server listening > 10/23/2008 3:07:31 PM: MpsSvc Service could not be opened for query: 0x424 > 10/23/2008 3:07:31 PM: StoreAnsiFilenames = 0 > 10/23/2008 3:07:31 PM: EnableSMBAsyncStore = 1 > 10/23/2008 3:07:31 PM: AutoStart 0x2 > 10/23/2008 3:07:31 PM: SMBAsyncStoreSize = 131072 > 10/23/2008 3:07:31 PM: daemonCheckDownInterval is 180 > 10/23/2008 3:07:31 PM: LAN adapter number 3 > 10/23/2008 3:07:31 PM: daemonCheckUpInterval is 240 > 10/23/2008 3:07:31 PM: Using >AFS< as SMB server name > 10/23/2008 3:07:31 PM: daemonCheckVolInterval is 3600 > 10/23/2008 3:07:31 PM: smb_localNamep is >AFS< > 10/23/2008 3:07:31 PM: daemonCheckCBInterval is 60 > 10/23/2008 3:07:31 PM: Netbios NCBRESET lana 3 succeeded > 10/23/2008 3:07:31 PM: daemonCheckVolCBInterval is 0 > 10/23/2008 3:07:31 PM: lana_list.length 1 > 10/23/2008 3:07:31 PM: daemonCheckLockInterval is 60 > 10/23/2008 3:07:31 PM: daemonCheckTokenInterval is 180 > 10/23/2008 3:07:31 PM: daemonCheckOfflineVolInterval is 600 > 10/23/2008 3:07:31 PM: daemonPerformanceTuningInterval is 0 > 10/23/2008 3:07:34 PM: Netbios NCBADDNAME lana=3 code=0 retcode=0 complete=0 > 10/23/2008 3:07:34 PM: Netbios NCBADDNAME added new name >AFS < > 10/23/2008 3:07:34 PM: Netbios NCBADDNAME succeeded on lana 3 > > 10/23/2008 3:07:34 PM: smb_NetbiosInit smb_LANadapter=3 > 10/23/2008 3:07:34 PM: Setting SMB server domain name to [RACHEL] > 10/23/2008 3:07:34 PM: smb_StartListeners > 10/23/2008 3:07:34 PM: smb_Init complete > 10/23/2008 3:07:34 PM: Windows Firewall Configuration succeeded > 10/23/2008 3:07:34 PM: GlobalAutoMap thread completed > 10/23/2008 3:28:23 PM: Mountpoint[0] = .cs%cs.wisc.edu:root.cell. > 10/23/2008 3:28:23 PM: Mountpoint[1] = .cs.wisc.edu%cs.wisc.edu:root.cell. > 10/23/2008 3:28:23 PM: Mountpoint[2] = cs.wisc.edu#cs.wisc.edu:root.cell. > 10/23/2008 3:28:23 PM: Mountpoint[3] = @cell#cs.wisc.edu:root.cell. > 10/23/2008 3:28:23 PM: Mountpoint[4] = cs#cs.wisc.edu:root.cell. > 10/23/2008 3:28:23 PM: Mountpoint[5] = .@cell%cs.wisc.edu:root.cell. > > Once we see the Mountpoint[x] entries show up, the AFS client is > running properly. My question is what would cause this to wait 20 > minutes before this continues on. > > I did collect an "fs trace" log (trace starting when server starts) in > /afs/cs.wisc.edu/u/j/o/john/public/html/winafs-logs/1.5.5403-delay > > If anyone can shed some light on what might be causing this delay, > please enlighten me. > --------------ms080902020305060801030801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMjQwMjA3NDdaMCMGCSqGSIb3DQEJBDEWBBSCyeBa V21I0hxjWUg2AUbr7YU1iDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAbaYJ2hdsbqIlDv3DnX+WX/cS2ZShB7J14nHsFaHYu++M5wfqx4kz Tid+RXndwJrdVNCGTA8M+j74PENsTsLi7Dj2lP4pQna3jqNgTKXtl0RpqjoqbgP2ev8ZAqvP bUEZD7/pJYMAI2WiUYBBYDpFEJgG++05Myn0VQtM0YEBiMMSwncRTSYnld6JH0AYN5nIOpYZ do+r8Bj05vHnP3FuixNGvkv76vsJaVoWCA/UAkmPPv3wRMLBwIPIJebIptlwuCBSxyHQmEfQ 239TPfGiR/f/Nc5aI/4zjhIVjKfY8lTCACFSo7kYMvk7j45RWt1fEDxIFs7c5+VHW8IjY5MU JQAAAAAAAA== --------------ms080902020305060801030801-- From jaltman@secure-endpoints.com Fri Oct 24 03:11:47 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 23 Oct 2008 19:11:47 -0700 Subject: [OpenAFS] openafs pioctl issue on windows In-Reply-To: <1d1a54bf0810231556i78e6c26fk7e612da83d9f6a35@mail.gmail.com> References: <1d1a54bf0810221205r75e30746o49dcff3c409e7638@mail.gmail.com> <48FF7C91.9070605@secure-endpoints.com> <1d1a54bf0810221256y1143977pf648adc4a10221e4@mail.gmail.com> <48FF9B01.9030908@secure-endpoints.com> <1d1a54bf0810231556i78e6c26fk7e612da83d9f6a35@mail.gmail.com> Message-ID: <49012EE3.30600@secure-endpoints.com> David Bear wrote: > KFW is version 3.2.2 -- resintalled today. > Windows is XP Pro with SP2 > credential cache is API: -- we do make use of windows logon credentials. > I've stopped using kinit and only use NIM to get and destroy tickets. I > do succesfully get tickets in asu.edu , as the output > of klist shows: > Ticket cache: API:bvossoug@ASU.EDU > Default principal: bvossoug@ASU.EDU > > Valid starting Expires Service principal > 10/23/08 15:34:38 10/24/08 01:34:39 krbtgt/ASU.EDU > @ASU.EDU > renew until 10/30/08 15:30:56 > > but I'm not getting the afs@asu.edu credential.. ?? > why? > So, does this indicate the problem is with KfW instead of openafs? You have not received any service tickets. All you have is a TGT. Can you obtain service tickets for any service? kvno.exe You could also turn on logging in NIM and examine the log. My guess is that assuming you have the AFS credential acquisition properly configured for NIM that the clock on the machine is not set correctly. Wrong time or wrong time zone. Jeffrey Altman Secure Endpoints Inc. From mansaxel@besserwisser.org Sun Oct 26 00:57:50 2008 From: mansaxel@besserwisser.org (Mans Nilsson) Date: Sun, 26 Oct 2008 01:57:50 +0200 Subject: [OpenAFS] Timed out error on some operations in AFS when accessing from Solaris zone. Message-ID: <20081025235749.GA17407@besserwisser.org> I have a number of apps that try getcwd() from a zone in an AFS directory= , and failing.=20 Truss says:=20 getcwd(0xFFBFDAE0, 4096) Err#145 ETIMEDOUT Exactly the same operation, but performed from the global zone, works fla= wlessly.=20 Tokens are in order, I can create files, open them, "pwd" from bash and ksh works, but some apps simply can't tell where they are. Gnu Make is one, iirc, along with some other bits and pieces in my toolchain -- the first occurances were in compiling. This occurs in several zones, on 5.10 Generic_125100-10 sun4u with opena= fs 1.4.4. Zone setup for loopback sharing is typically:=20 fs: dir: /afs special: /afs raw not specified type: lofs options: [] fs: dir: /usr/vice/cache special: /usr/vice/cache raw not specified type: lofs options: [] ...which is the only way I've seen things set up. Any hints? I'm open to upgrading, no problemo.=20 --=20 M=E5ns Nilsson =09 From shadow@dementia.org Mon Oct 27 07:30:54 2008 From: shadow@dementia.org (Derrick J Brashear) Date: Mon, 27 Oct 2008 02:30:54 -0400 (EDT) Subject: [OpenAFS] Foundation Plan redux Message-ID: Folks, there's been precious little in the way of comments regarding the plan for a potential Foundation for OpenAFs, mostly positive, but I'm unwilling to believe people like it that much so much as are lazy. If you have comments please send them! Public discussion is encouraged. Please reply if you'd like to talk about it! Thank you, Derrick Brashear OpenAFS gatekeeperelder and some other stuff, today speaking for himself From dboyes@sinenomine.net Mon Oct 27 15:48:25 2008 From: dboyes@sinenomine.net (David Boyes) Date: Mon, 27 Oct 2008 10:48:25 -0400 Subject: [OpenAFS] Foundation Plan redux In-Reply-To: References: Message-ID: <435B77BA27FC254099B1763E498DEF665F493A@va1exc02.SNAADS.sinenomine.net> > there's been precious little in the way of comments regarding the plan for > a potential Foundation for OpenAFs, mostly positive, but I'm unwilling to > believe people like it that much so much as are lazy. >=20 > If you have comments please send them! Public discussion is encouraged. > Please reply if you'd like to talk about it! I've been reading the draft documents Derrick posted wrt to the AFS Foundation proposal, and while there's a lot to like here, I'd like to raise a few things that I think aren't addressed yet.=20 First off, I think that the folks that have been working on this deserve a lot of credit for pushing the idea forward and getting the footwork done. It's good to see progress on this front, and it's needed doing for a long time. The current volunteer model is limping a bit (mostly for lack of paid resources to get specific things done), and the additional structure and organization around the idea of a non-profit conservatorship of the AFS environment will help get a number of long-standing problems addressed. I like the basic structure of the foundation, but that leads me to my questions,=20 What I look for in a successful organization is a clear understanding of the basic goals of the organization, and how it plans to sustain itself over time. Financials are all well and good, but the largest open question I have has to do with generating a strong set of leaders and keeping a pipeline of those individuals coming by consciously developing new leaders. I don't see much discussion of either in these documents. I'd like to propose the following set of principles for discussion:=20 * Conservatorship.=20 The Foundation's primary goal should be to act as a non-profit conservator of the AFS code base. It should be generally acknowledged that the foundation is acting as a legal representative of the community, and serves on behalf of the community. * Transparancy The processes and procedures used to make decisions and select goals and leaders should be clearly documented and applied, and it should be easily determined how decisions are arrived at and the decisions each participant made.=20 * Sustainability Any organization that is going to survive beyond the first generation needs a clear development plan and a succession plan to ensure that leadership is available and understands the tasks and steps to run the organization. The current documents do a fair job with the first principle of conservatorship, but I don't see much work on the other two yet. Perhaps the idea is to develop the processes as things progress, but there are good working examples of similar organizations that would probably prove to be valuable examples if used as a starting point.=20 I'm also concerned that there is little discussion of the sustainability principle. How does one become part of the various organizations or committees described in the proposed documents? How long can one obtain as a gatekeeper or board member? Is there a term limit (a desirable thing, IMHO, as it forces an organization to develop new leaders rather than having the same faces in the same places)?=20 All these questions are certainly things where answers can be found, but I'd like to open the discussion and see if others have constructive suggestions to develop a plan we can all live with. I'm happy to discuss these issues with anyone, and look forward to seeing where the final outcome may take us. -- db=20 David Boyes Sine Nomine Associates From Jerry.Normandin@dafca.com Mon Oct 27 16:15:48 2008 From: Jerry.Normandin@dafca.com (Jerry Normandin) Date: Mon, 27 Oct 2008 08:15:48 -0700 Subject: [OpenAFS] Foundation Plan redux In-Reply-To: <435B77BA27FC254099B1763E498DEF665F493A@va1exc02.SNAADS.sinenomine.net> Message-ID: <3BE535873FE31A4186EF7828495A26A43446A7@EXVBE005-3.exch005intermedia.net> A real foundation that will generate some revenue for the openafs contributors and he people who have been a major contributor to the Openafs forms would be great. Are you looking to assemble full time/ part time code contributors? How about a free and paid helpdesk model too! I really don't think Unix System Admins are lazy. When you deploy openafs it's usually to fill a particular need. AFS is an excellent file system to role out on in a campus environment! -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] On Behalf Of David Boyes Sent: Monday, October 27, 2008 10:48 AM To: Derrick J Brashear; openafs-info@openafs.org Subject: RE: [OpenAFS] Foundation Plan redux > there's been precious little in the way of comments regarding the plan for > a potential Foundation for OpenAFs, mostly positive, but I'm unwilling to > believe people like it that much so much as are lazy. >=20 > If you have comments please send them! Public discussion is encouraged. > Please reply if you'd like to talk about it! I've been reading the draft documents Derrick posted wrt to the AFS Foundation proposal, and while there's a lot to like here, I'd like to raise a few things that I think aren't addressed yet.=20 First off, I think that the folks that have been working on this deserve a lot of credit for pushing the idea forward and getting the footwork done. It's good to see progress on this front, and it's needed doing for a long time. The current volunteer model is limping a bit (mostly for lack of paid resources to get specific things done), and the additional structure and organization around the idea of a non-profit conservatorship of the AFS environment will help get a number of long-standing problems addressed. I like the basic structure of the foundation, but that leads me to my questions,=20 What I look for in a successful organization is a clear understanding of the basic goals of the organization, and how it plans to sustain itself over time. Financials are all well and good, but the largest open question I have has to do with generating a strong set of leaders and keeping a pipeline of those individuals coming by consciously developing new leaders. I don't see much discussion of either in these documents. I'd like to propose the following set of principles for discussion:=20 * Conservatorship.=20 The Foundation's primary goal should be to act as a non-profit conservator of the AFS code base. It should be generally acknowledged that the foundation is acting as a legal representative of the community, and serves on behalf of the community. * Transparancy The processes and procedures used to make decisions and select goals and leaders should be clearly documented and applied, and it should be easily determined how decisions are arrived at and the decisions each participant made.=20 * Sustainability Any organization that is going to survive beyond the first generation needs a clear development plan and a succession plan to ensure that leadership is available and understands the tasks and steps to run the organization. The current documents do a fair job with the first principle of conservatorship, but I don't see much work on the other two yet. Perhaps the idea is to develop the processes as things progress, but there are good working examples of similar organizations that would probably prove to be valuable examples if used as a starting point.=20 I'm also concerned that there is little discussion of the sustainability principle. How does one become part of the various organizations or committees described in the proposed documents? How long can one obtain as a gatekeeper or board member? Is there a term limit (a desirable thing, IMHO, as it forces an organization to develop new leaders rather than having the same faces in the same places)?=20 All these questions are certainly things where answers can be found, but I'd like to open the discussion and see if others have constructive suggestions to develop a plan we can all live with. I'm happy to discuss these issues with anyone, and look forward to seeing where the final outcome may take us. -- db=20 David Boyes Sine Nomine Associates _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From shadow@gmail.com Mon Oct 27 16:22:27 2008 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 27 Oct 2008 11:22:27 -0400 Subject: [OpenAFS] Foundation Plan redux In-Reply-To: <3BE535873FE31A4186EF7828495A26A43446A7@EXVBE005-3.exch005intermedia.net> References: <435B77BA27FC254099B1763E498DEF665F493A@va1exc02.SNAADS.sinenomine.net> <3BE535873FE31A4186EF7828495A26A43446A7@EXVBE005-3.exch005intermedia.net> Message-ID: Jerry, On Mon, Oct 27, 2008 at 11:15 AM, Jerry Normandin wrote: > A real foundation that will generate some revenue for the openafs > contributors and he people who have been a major contributor to the > Openafs forms would be great. Are you looking to assemble full time/ > part time code contributors? How about a free and paid helpdesk model > too! Existing companies will happily provide you support, and they are listed at http://www.openafs.org/support.html The goal of the foundation is not to become a new entrant in this space. Indeed, in my opinion, to grow a robust ecosystem for OpenAFS, it's critical that the Foundation not attempt to take this business away from current and future providers. The goal is to grow OpenAFS, not rather to subsume, consume, or co-opt what is there. Obviously I can speak only for myself and am but one voice, but the plan you see was not crafted with the idea you've proposed in mind. Derrick speaking only for myself From deengert@anl.gov Mon Oct 27 16:33:22 2008 From: deengert@anl.gov (Douglas E. Engert) Date: Mon, 27 Oct 2008 10:33:22 -0500 Subject: [OpenAFS] Timed out error on some operations in AFS when accessing from Solaris zone. In-Reply-To: <20081025235749.GA17407@besserwisser.org> References: <20081025235749.GA17407@besserwisser.org> Message-ID: <4905DF42.7040202@anl.gov> Mans Nilsson wrote: > I have a number of apps that try getcwd() from a zone in an AFS directory, and failing. > > Truss says: > > getcwd(0xFFBFDAE0, 4096) Err#145 ETIMEDOUT Works for us. > > Exactly the same operation, but performed from the global zone, works flawlessly. > > Tokens are in order, I can create files, open them, "pwd" from bash and > ksh works, but some apps simply can't tell where they are. Gnu Make is > one, iirc, along with some other bits and pieces in my toolchain -- the > first occurances were in compiling. > > This occurs in several zones, on 5.10 Generic_125100-10 sun4u with openafs 1.4.4. Zone setup for loopback sharing is typically: > > fs: > dir: /afs > special: /afs > raw not specified > type: lofs > options: [] This looks OK, but we don't mount the cache, or run the cachemanager in a zone. The cachemaneger is run from the global. So the following is not needed: > fs: > dir: /usr/vice/cache > special: /usr/vice/cache > raw not specified > type: lofs > options: [] > (Note: AFS is not zone aware, so PAGs and UID based tokens are shred across zones.) > ...which is the only way I've seen things set up. > > Any hints? I'm open to upgrading, no problemo. On the system I just tested, we have 1.4.4, with Generic_137111-07. > > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From hans@MPA-Garching.MPG.DE Mon Oct 27 17:16:45 2008 From: hans@MPA-Garching.MPG.DE (Hans-Werner Paulsen) Date: Mon, 27 Oct 2008 17:16:45 +0100 Subject: [OpenAFS] flock on AFS files Message-ID: <20081027161645.GA7352@ncq-5.MPA-Garching.MPG.DE> Hello, today I am totally confused how the flock(2) call should work on AFS files. Normally locking works in the following way: 1 fd =3D open("afs-file",O_RDWR) do something 2 flock(fd,LOCK_EX) do something with "afs-file" 3 flock(fd,LOCK_UN) do something 4 close(fd) When there are two processes (on different machines) executing that code, the (2) flock call has to update the local copy of the afs-file, otherwise locking is useless. And the (3) flock call has to sync the local copy with the fileserver. Writing a small test program I see that this synchronization isn't done. How can I use the flock(2) call on AFS files? Thank you for any help, HW --=20 Hans-Werner Paulsen hans@MPA-Garching.MPG.DE MPI f=FCr Astrophysik Tel 089-30000-2602 Karl-Schwarzschild-Str. 1 Fax 089-30000-2235=09 D-85741 Garching From sxw@inf.ed.ac.uk Mon Oct 27 17:17:56 2008 From: sxw@inf.ed.ac.uk (Simon Wilkinson) Date: Mon, 27 Oct 2008 09:17:56 -0700 Subject: [OpenAFS] Foundation Plan redux In-Reply-To: <435B77BA27FC254099B1763E498DEF665F493A@va1exc02.SNAADS.sinenomine.net> References: <435B77BA27FC254099B1763E498DEF665F493A@va1exc02.SNAADS.sinenomine.net> Message-ID: <428CFEBA-29B5-4574-A2B2-F93C0C2E8359@inf.ed.ac.uk> On 27 Oct 2008, at 07:48, David Boyes wrote: > * Transparancy > > The processes and procedures used to make decisions and select > goals and > leaders should be clearly documented and applied, and it should be > easily determined how decisions are arrived at and the decisions each > participant made. From my reading, it seems like the proposal already addresses issues of transparency. Do you have specific areas in which you have concerns? > > * Sustainability > > Any organization that is going to survive beyond the first generation > needs a clear development plan and a succession plan to ensure that > leadership is available and understands the tasks and steps to run the > organization. > > The current documents do a fair job with the first principle of > conservatorship, but I don't see much work on the other two yet. > Perhaps > the idea is to develop the processes as things progress, but there are > good working examples of similar organizations that would probably > prove > to be valuable examples if used as a starting point. > > I'm also concerned that there is little discussion of the > sustainability > principle. How does one become part of the various organizations or > committees described in the proposed documents? It's not clear to me how one becomes a board member, beyond the normal corporate election structures. Criteria for becoming a gatekeeper (appointment by the TAC), or a TAC member (appointment, in the case of corporate members, or election for individual members) seem pretty clear. > How long can one obtain > as a gatekeeper or board member? Is there a term limit (a desirable > thing, IMHO, as it forces an organization to develop new leaders > rather > than having the same faces in the same places)? In this case, as with AFS standardisation, I strongly disagree that term limits are desirable. At their worst, they just ensure the retirement of strong post holders, and their replacement with inexperienced ones. OpenAFS badly needs a way of encouraging new faces, and growing those individuals into positions of responsibility. I don't believe that requiring the abdication of successful leaders after some arbitrary period will help with this. It's kind of like cutting off the head of a random animal in the hope that it will grow a new one - it works in a small number of cases, but the rest of the time you'll end up with a lifeless corpse. Cheers, Simon. From summatusmentis@gmail.com Mon Oct 27 17:31:09 2008 From: summatusmentis@gmail.com (Jake Thebault-Spieker) Date: Mon, 27 Oct 2008 11:31:09 -0500 Subject: [OpenAFS] Foundation Plan redux In-Reply-To: <428CFEBA-29B5-4574-A2B2-F93C0C2E8359@inf.ed.ac.uk> References: <435B77BA27FC254099B1763E498DEF665F493A@va1exc02.SNAADS.sinenomine.net> <428CFEBA-29B5-4574-A2B2-F93C0C2E8359@inf.ed.ac.uk> Message-ID: <2d18958c0810270931g67b9b738i6f566e5aad709e96@mail.gmail.com> ------=_Part_38111_25191800.1225125069090 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline > In this case, as with AFS standardisation, I strongly disagree that term > limits are desirable. At their worst, they just ensure the retirement of > strong post holders, and their replacement with inexperienced ones. > > OpenAFS badly needs a way of encouraging new faces, and growing those > individuals into positions of responsibility. I don't believe that requiring > the abdication of successful leaders after some arbitrary period will help > with this. It's kind of like cutting off the head of a random animal in the > hope that it will grow a new one - it works in a small number of cases, but > the rest of the time you'll end up with a lifeless corpse. > > I very much agree. While the concept of term limits makes some sense, in this case, there seems to be very little reason for them. As someone who would like to be one of the 'new faces' mentioned above, encouragement is helpful :) I'm not sure what I'm saying anymore, beyond: No term limits. -- Jacob Thebault-Spieker Cell: (320) 288-6412 http://summatusmentis.wordpress.com ------=_Part_38111_25191800.1225125069090 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
In this case, as with AFS standardisation, I strongly disagree that term limits are desirable. At their worst, they just ensure the retirement of strong post holders, and their replacement with inexperienced ones.

OpenAFS badly needs a way of encouraging new faces, and growing those individuals into positions of responsibility. I don't believe that requiring the abdication of successful leaders after some arbitrary period will help with this. It's kind of like cutting off the head of a random animal in the hope that it will grow a new one - it works in a small number of cases, but the rest of the time you'll end up with a lifeless corpse.

I very much agree. While the concept of term limits makes some sense, in this case, there seems to be very little reason for them. As someone who would like to be one of the 'new faces' mentioned above, encouragement is helpful :) I'm not sure what I'm saying anymore, beyond: No term limits.

--
Jacob Thebault-Spieker
Cell: (320) 288-6412
http://summatusmentis.wordpress.com
------=_Part_38111_25191800.1225125069090-- From Openafs-Info (E-mail)" References: <20081027161645.GA7352@ncq-5.MPA-Garching.MPG.DE> Message-ID: <4905ECE8.8040603@email.unc.edu> I've got quite a bit of code that does flock() on files in AFS, but I've always worked under the assumption that this would only work if a single client is doing the writing. I don't recall whether that assumption was based on empirical testing, reading it somewhere, or being told. In those few cases where this is not practical, I have a designated writer client that other clients connect to through other means (sockets) and coordinate the updates that way. That's reasonably straightforward, but painful enough that I avoid it whenever possible. Probably not the answer you wanted... -- Todd_Lewis@unc.edu On 10/27/2008 12:16 PM, Hans-Werner Paulsen wrote: > Hello, > today I am totally confused how the flock(2) call should work on > AFS files. > Normally locking works in the following way: > 1 fd = open("afs-file",O_RDWR) > do something > 2 flock(fd,LOCK_EX) > do something with "afs-file" > 3 flock(fd,LOCK_UN) > do something > 4 close(fd) > > When there are two processes (on different machines) executing that > code, the (2) flock call has to update the local copy of the afs-file, > otherwise locking is useless. And the (3) flock call has to sync the > local copy with the fileserver. > Writing a small test program I see that this synchronization isn't done. > How can I use the flock(2) call on AFS files? > Thank you for any help, > > HW > From singh.madhusudan@gmail.com Mon Oct 27 17:39:50 2008 From: singh.madhusudan@gmail.com (Madhusudan Singh) Date: Mon, 27 Oct 2008 09:39:50 -0700 Subject: [OpenAFS] Openafs broken on Ubuntu Hardy ? In-Reply-To: <20081015135904.GA6666@hanuman.astro.su.se> References: <48F3DABA.2020905@syssoft.uni-trier.de> <20081015135904.GA6666@hanuman.astro.su.se> Message-ID: ------=_Part_30197_20677569.1225125590079 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, Apologies for the long delay. I forgot about this issue as I got busy. > I upgraded from -19 to -21 this morning, built and installed > openafs-modules-2.6.24-21-generic_1.4.6.dfsg1-2+2.6.24-21.42_i386.deb > using m-a as usual, and it still works. > Ok. > > > >> :$ cd /afs/YYY.edu/users/X/Y/Z/XYZABC > > >> bash: cd: /afs/YYY.edu/users/X/Y/Z/XYZABC: Permission denied > > >> > > > This look like the user you authenticate as, simply doesn't have the > > > required permissions to access the directory. > > > > Impossible. I can ssh into the server with the same username and password > > without any issues. I use rsync to do regular (every 1 hour) backups to > this > > directory ( a process that is cumbersome, which is why I am looking to > set > > up my openafs client). > > All right. Your problem *is* client-side, then. Could you look at the > output of "klist -a -n" and verify that your AFS service ticket is for > the right address? (Addressless is usually OK.) NAT gateways sometimes > interfere. > $ klist -a -n Ticket cache: FILE:/tmp/krb5cc_457671 Default principal: XYZABC@YYY.EDU Valid starting Expires Service principal 10/27/08 09:17:57 10/28/08 09:17:57 krbtgt/YYY.EDU@YYY.EDU Addresses: (none) 10/27/08 09:18:01 10/28/08 09:17:57 afs@YYY.EDU Addresses: (none) Kerberos 4 ticket cache: /tmp/tkt457671 klist: You have no tickets cached Appears to be addressless. I tried this with my own firewall down (not that has anything to do with what you were talking about - just wanted to eliminate a possible point of failure). > > > I cannot cd into my own directory, so I ssh'ed into the server and issued > fs > > Which authentication method did you use with ssh? Does GSSAPI work? > I have never really looked into this. I believe that I have ssh-krb5 or some such thing installed. A quick look inside my /etc/ssh/sshd_config on the client indicates "GSSAPIAuthentication yes" is set. > > listacl : > > > > $ fs listacl > > Access list for . is > > Normal rights: > > systems:backup rl > > www-hosts l > > system:administrators rlidwka > > XYZABC rlidwka > > Looks good. One question, though: is the server you ran this on a member > of www-hosts ? I have no idea (it does host www directories for users). How do I find out ? > > > > The owner of all directories under /afs/YYY.EDU/users/X/Y/Z is root.root > > (tested both through the local /afs tree and by ssh'ing to the server and > > doing a cd ..). I do not recall what this was when things were working > fine > > (never needed to check), but is this normal (sounds fishy) ? In a > different > > cell, a long time ago, I seem to vaguely recall that the directory was > owned > > by the user in question. > > The UID that owns the volume root has implicit "a" permission on all > directories in the volume. That would let you recover from a "fs setacl > $HOME XYZABC none" without having to bother the AFS administrators. But > since the ACL explicitly grants you full access, you should have full > access --- as long as your token is valid. > > > To test if this was messing up things, I cd'ed to > > /afs/YYY.EDU/users/X/Y/Z/XYZABC and issued a command : > > > > $ cd XYZABC/Private > > bash: cd: XYZABC/Private: Permission denied > > So you were trying to access /afs/ > YYY.EDU/users/X/Y/Z/XYZABC/XYZABC/Private ? > Yes. > > Was this on the server or on your client? If on the client (as your > other statements are suggesting), it simply restates that your token > is not being accepted. If on the server, I'd want to see the ACL on > that subdirectory (and know whether the server is in www-hosts). This was on the client. On the server, I have no issues accessing anything that I own. > > > > This is more nonsense as ~/Private holds my backups :) Maybe the fact > that I > > do not own /afs/YYY.EDU/users/X/Y/Z/XYZABC is shortcircuiting that > command. > > I don't see how that would work as an explanation. Shooting in the dark with my ignorance as an able ally :) > > > > The owner of all files inside /afs/YYY.EDU/users/X/Y/Z/XYZABC is > obviously > > XYZABC. > > Not so obviously since you said that the top-level directory is owned by > root, not by XYZABC. You could be locked out of a subdirectory by its ACL. > When I login to the server through ssh, I see the following : drwxr-xr-x 6 XYZABC XYZABC 2048 Oct 27 09:24 Private I guess I should have included that instead of simply stating that I can read/write to the directory etc. You can read/write to any directory without being the owner if you have the right ACL's / unix file permissions. > My impression is that the token you got on your client is either invalid > or belongs to a different AFS user. The explanations I can think of are I simply fail to see how it can belong to a different AFS user. The UID is the same and the username used is the same for the attempt to get tokens, and for the successful login to the server (as well as the ownership of the subdirectories like above). Maybe you should explain why you continue to suspect this ? > > (a) that you are behind a NAT and your token is for the wrong address; Addressless above. > > (b) that you're obtaining the token via Kerberos cross-realm and it's > really for user XYZABC@OTHER.REALM (in which case you could try > fs setacl /afs/YYY.EDU/users/X/Y/Z/XYZABC XYZABC@other.realm all > on the server where you do have access, or learn how to authenticate to > the correct realm in the first place). The realm listed in the token is YYY.EDU. To just check against any mess up of this sort, I logged in to the server using ssh. Issued klist -a -n ON the SERVER : $ klist -a -n Ticket cache: FILE:/tmp/krb5cc_457671_Rdt7da Default principal: XYZABC@YYY.EDU Valid starting Expires Service principal 10/27/08 09:32:49 10/27/08 19:32:48 krbtgt/YYY.EDU@YYY.EDU renew until 10/27/08 19:32:48 Addresses: Kerberos 4 ticket cache: /tmp/tkt457671_QToYEM Principal: XYZABC@YYY.EDU Issued Expires Principal 10/27/08 09:32:49 10/27/08 19:27:49 krbtgt.YYY.EDU@YYY.EDU 10/27/08 09:32:49 10/27/08 19:32:49 afs@YYY.EDU Notable differences - its not addressless and kerberos 4 tickets were issued as well. > > Can't the helpdesk at YYY.EDU help you with this? > I will definitely ask them (though most of them are windows addled unix ignoramuses - this is one your more "modern" IT departments) once I have exhausted all chances of the problem being at my end. Thanks for your help and patience so far. Any suggestions would be greatly appreciated. With regards. ------=_Part_30197_20677569.1225125590079 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello,

Apologies for the long delay. I forgot about this issue as I got busy.


I upgraded from -19 to -21 this morning, built and installed
openafs-modules-2.6.24-21-generic_1.4.6.dfsg1-2+2.6.24-21.42_i386.deb
using m-a as usual, and it still works.

Ok.
 

> >> :$ cd /afs/YYY.edu/users/X/Y/Z/XYZABC
> >> bash: cd: /afs/YYY.edu/users/X/Y/Z/XYZABC: Permission denied
> >>
> > This look like the user you authenticate as, simply doesn't have the
> > required permissions to access the directory.
>
> Impossible. I can ssh into the server with the same username and password
> without any issues. I use rsync to do regular (every 1 hour) backups to this
> directory ( a process that is cumbersome, which is why I am looking to set
> up my openafs client).

All right. Your problem *is* client-side, then. Could you look at the
output of "klist -a -n" and verify that your AFS service ticket is for
the right address? (Addressless is usually OK.) NAT gateways sometimes
interfere.

 $ klist -a -n
Ticket cache: FILE:/tmp/krb5cc_457671
Default principal: XYZABC@YYY.EDU

Valid starting     Expires            Service principal
10/27/08 09:17:57  10/28/08 09:17:57  krbtgt/YYY.EDU@YYY.EDU
        Addresses: (none)
10/27/08 09:18:01  10/28/08 09:17:57  afs@YYY.EDU
        Addresses: (none)


Kerberos 4 ticket cache: /tmp/tkt457671
klist: You have no tickets cached

Appears to be addressless. I tried this with my own firewall down (not that has anything to do with what you were talking about - just wanted to eliminate a possible point of failure).



> I cannot cd into my own directory, so I ssh'ed into the server and issued fs

Which authentication method did you use with ssh? Does GSSAPI work?

I have never really looked into this. I believe that I have ssh-krb5 or some such thing installed.  A quick look inside my /etc/ssh/sshd_config on the client indicates "GSSAPIAuthentication yes" is set.


> listacl :
>
>   $ fs listacl
> Access list for . is
> Normal rights:
>   systems:backup rl
>   www-hosts l
>   system:administrators rlidwka
>   XYZABC rlidwka

Looks good. One question, though: is the server you ran this on a member
of www-hosts ?

I have no idea (it does host www directories for users). How do I find out ?
 


> The owner of all directories under /afs/YYY.EDU/users/X/Y/Z is root.root
> (tested both through the local /afs tree and by ssh'ing to the server and
> doing a cd ..). I do not recall what this was when things were working fine
> (never needed to check), but is this normal (sounds fishy) ? In a different
> cell, a long time ago, I seem to vaguely recall that the directory was owned
> by the user in question.

The UID that owns the volume root has implicit "a" permission on all
directories in the volume. That would let you recover from a "fs setacl
$HOME XYZABC none" without having to bother the AFS administrators. But
since the ACL explicitly grants you full access, you should have full
access --- as long as your token is valid.

> To test if this was messing up things, I cd'ed to
> /afs/YYY.EDU/users/X/Y/Z/XYZABC and issued a command :
>
> $ cd XYZABC/Private
> bash: cd: XYZABC/Private: Permission denied

So you were trying to access /afs/YYY.EDU/users/X/Y/Z/XYZABC/XYZABC/Private ?

Yes.
 

Was this on the server or on your client? If on the client (as your
other statements are suggesting), it simply restates that your token
is not being accepted. If on the server, I'd want to see the ACL on
that subdirectory (and know whether the server is in www-hosts).

This was on the client. On the server, I have no issues accessing anything that I own.
 


> This is more nonsense as ~/Private holds my backups :) Maybe the fact that I
> do not own /afs/YYY.EDU/users/X/Y/Z/XYZABC is shortcircuiting that command.

I don't see how that would work as an explanation.

Shooting in the dark with my ignorance as an able ally :)
 


> The owner of all files inside /afs/YYY.EDU/users/X/Y/Z/XYZABC is obviously
> XYZABC.

Not so obviously since you said that the top-level directory is owned by
root, not by XYZABC. You could be locked out of a subdirectory by its ACL.

When I login to the server through ssh, I see the following :

 drwxr-xr-x    6 XYZABC XYZABC     2048 Oct 27 09:24 Private

I guess I should have included that instead of simply stating that I can read/write to the directory etc. You can read/write to any directory without being the owner if you have the right ACL's / unix file permissions.


My impression is that the token you got on your client is either invalid
or belongs to a different AFS user. The explanations I can think of are

I simply fail to see how it can belong to a different AFS user. The UID is the same and the username used is the same for the attempt to get tokens, and for the successful login to the server (as well as the ownership of the subdirectories like above).

Maybe you should explain why you continue to suspect this ?
 

(a) that you are behind a NAT and your token is for the wrong address;

Addressless above.
 

(b) that you're obtaining the token via Kerberos cross-realm and it's
really for user XYZABC@OTHER.REALM (in which case you could try
       fs setacl /afs/YYY.EDU/users/X/Y/Z/XYZABC XYZABC@other.realm all
on the server where you do have access, or learn how to authenticate to
the correct realm in the first place).

The realm listed in the token is YYY.EDU. To just check against any mess up of this sort, I logged in to the server using ssh. Issued klist -a -n ON the SERVER :

$ klist -a -n
Ticket cache: FILE:/tmp/krb5cc_457671_Rdt7da
Default principal: XYZABC@YYY.EDU

Valid starting     Expires            Service principal
10/27/08 09:32:49  10/27/08 19:32:48  krbtgt/YYY.EDU@YYY.EDU
        renew until 10/27/08 19:32:48
        Addresses: <an actual IP address>


Kerberos 4 ticket cache: /tmp/tkt457671_QToYEM
Principal: XYZABC@YYY.EDU

  Issued              Expires             Principal
10/27/08 09:32:49  10/27/08 19:27:49  krbtgt.YYY.EDU@YYY.EDU
10/27/08 09:32:49  10/27/08 19:32:49  afs@YYY.EDU

Notable differences - its not addressless and kerberos 4 tickets were issued as well.





Can't the helpdesk at YYY.EDU help you with this?

I will definitely ask them (though most of them are windows addled unix ignoramuses - this is one your more "modern" IT departments) once I have exhausted all chances of the problem being at my end. Thanks for your help and patience so far. Any suggestions would be greatly appreciated.

With regards.
------=_Part_30197_20677569.1225125590079-- From jerrymc@msu.edu Mon Oct 27 17:49:32 2008 From: jerrymc@msu.edu (Jerry McAllister) Date: Mon, 27 Oct 2008 12:49:32 -0400 Subject: [OpenAFS] Foundation Plan redux In-Reply-To: <428CFEBA-29B5-4574-A2B2-F93C0C2E8359@inf.ed.ac.uk> References: <435B77BA27FC254099B1763E498DEF665F493A@va1exc02.SNAADS.sinenomine.net> <428CFEBA-29B5-4574-A2B2-F93C0C2E8359@inf.ed.ac.uk> Message-ID: <20081027164932.GI98028@gizmo.acns.msu.edu> On Mon, Oct 27, 2008 at 09:17:56AM -0700, Simon Wilkinson wrote: > > On 27 Oct 2008, at 07:48, David Boyes wrote: > >* Transparancy > > > >The processes and procedures used to make decisions and select > >goals and > >leaders should be clearly documented and applied, and it should be > >easily determined how decisions are arrived at and the decisions each > >participant made. > > From my reading, it seems like the proposal already addresses issues > of transparency. Do you have specific areas in which you have concerns? > > > > >* Sustainability > > > >Any organization that is going to survive beyond the first generation > >needs a clear development plan and a succession plan to ensure that > >leadership is available and understands the tasks and steps to run the > >organization. > > > >The current documents do a fair job with the first principle of > >conservatorship, but I don't see much work on the other two yet. > >Perhaps > >the idea is to develop the processes as things progress, but there are > >good working examples of similar organizations that would probably > >prove > >to be valuable examples if used as a starting point. > > > >I'm also concerned that there is little discussion of the > >sustainability > >principle. How does one become part of the various organizations or > >committees described in the proposed documents? > > It's not clear to me how one becomes a board member, beyond the > normal corporate election structures. Criteria for becoming a > gatekeeper (appointment by the TAC), or a TAC member (appointment, in > the case of corporate members, or election for individual members) > seem pretty clear. > > >How long can one obtain > >as a gatekeeper or board member? Is there a term limit (a desirable > >thing, IMHO, as it forces an organization to develop new leaders > >rather > >than having the same faces in the same places)? > > In this case, as with AFS standardisation, I strongly disagree that > term limits are desirable. At their worst, they just ensure the > retirement of strong post holders, and their replacement with > inexperienced ones. Without some way of encorporating new persons in to the process/organization, it will die. <-- that's a period there. Of course, you do not want to cut off wise contributions just because they have been doing it for a while. So, you need something more creative. Create a structure that a person naturally works through and reaches a point of continuing participation, but does not impede new persons from moving in to the structure and work with responsibility. Organizations die or become ineffective as often by stagnation as by incorporating new, inexperienced and possible incompetent persons. So, think of a way to ameliorate both undesirable tendancies. ////jerry > > OpenAFS badly needs a way of encouraging new faces, and growing those > individuals into positions of responsibility. I don't believe that > requiring the abdication of successful leaders after some arbitrary > period will help with this. It's kind of like cutting off the head of > a random animal in the hope that it will grow a new one - it works in > a small number of cases, but the rest of the time you'll end up with > a lifeless corpse. > > Cheers, > > Simon. > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info From Sergio.Gelato@astro.su.se Tue Oct 28 09:31:25 2008 From: Sergio.Gelato@astro.su.se (Sergio Gelato) Date: Tue, 28 Oct 2008 09:31:25 +0100 Subject: [OpenAFS] Openafs broken on Ubuntu Hardy ? In-Reply-To: References: <48F3DABA.2020905@syssoft.uni-trier.de> <20081015135904.GA6666@hanuman.astro.su.se> Message-ID: <20081028083125.GB7025@hanuman.astro.su.se> * Madhusudan Singh [2008-10-27 09:39:50 -0700]: > > > I cannot cd into my own directory, so I ssh'ed into the server and issued > > fs > > > > Which authentication method did you use with ssh? Does GSSAPI work? > > > > I have never really looked into this. I believe that I have ssh-krb5 or some > such thing installed. A quick look inside my /etc/ssh/sshd_config on the > client indicates "GSSAPIAuthentication yes" is set. The reason I asked is that GSSAPI authentication would leverage the same Kerberos TGT you got your client-side AFS token from. It's a way of confirming that there is nothing wrong with your TGT and that a forwarded TGT gives you a working AFS token on the server. Invoking ssh with the -v option should show you which authentication method is being used. Alternatively, if you're prompted for a password you aren't using GSSAPI. > > Looks good. One question, though: is the server you ran this on a member > > of www-hosts ? > > I have no idea (it does host www directories for users). How do I find out ? pts members www-hosts But judging from the rest of what you said, the answer to this particular question isn't going to matter. > Notable differences - its not addressless and kerberos 4 tickets were issued > as well. As Derrick reminded us (thanks for the correction), the token is addressless in any case. I would hope that your cell's servers can deal with a token that is derived directly from a Kerberos 5 ticket, but that's really a question for your local helpdesk as they should know what their cell is running. For the avoidance of doubt, you could try to invoke aklog with the -524 option and see if that helps; but it's a rather long shot. > > Can't the helpdesk at YYY.EDU help you with this? > > I will definitely ask them (though most of them are windows addled unix > ignoramuses - this is one your more "modern" IT departments) once I have > exhausted all chances of the problem being at my end. Thanks for your help > and patience so far. Any suggestions would be greatly appreciated. The reason why you might be luckier asking them is that it's their realm and their cell, and they should know exactly how they've set things up and have access to their KDC logs which may contain useful information about your problem. Besides, aren't they paid to help? Even if the problem turns out to be entirely at your end, it's still useful for them to know what functionality their users are looking for (in your case, running the AFS client on an Ubuntu laptop); that tells them e.g. what how-to documents they need to publish. So don't be too shy. From jaltman@secure-endpoints.com Tue Oct 28 15:08:54 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Tue, 28 Oct 2008 07:08:54 -0700 Subject: [OpenAFS] Openafs broken on Ubuntu Hardy ? In-Reply-To: References: <48F3DABA.2020905@syssoft.uni-trier.de> <20081015135904.GA6666@hanuman.astro.su.se> Message-ID: <49071CF6.7030109@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms040307030500020206040309 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Madhusudan Singh wrote: > $ klist -a -n > Ticket cache: FILE:/tmp/krb5cc_457671 > Default principal: XYZABC@YYY.EDU > > Valid starting Expires Service principal > 10/27/08 09:17:57 10/28/08 09:17:57 krbtgt/YYY.EDU > @YYY.EDU > Addresses: (none) > 10/27/08 09:18:01 10/28/08 09:17:57 afs@YYY.EDU > Addresses: (none) > Kerberos v5 based AFS token does not work. > $ klist -a -n > Ticket cache: FILE:/tmp/krb5cc_457671_Rdt7da > Default principal: XYZABC@YYY.EDU > > Valid starting Expires Service principal > 10/27/08 09:32:49 10/27/08 19:32:48 krbtgt/YYY.EDU > @YYY.EDU > renew until 10/27/08 19:32:48 > Addresses: > > > Kerberos 4 ticket cache: /tmp/tkt457671_QToYEM > Principal: XYZABC@YYY.EDU > > Issued Expires Principal > 10/27/08 09:32:49 10/27/08 19:27:49 krbtgt.YYY.EDU > @YYY.EDU > 10/27/08 09:32:49 10/27/08 19:32:49 afs@YYY.EDU Kerberos v4 based AFS token does work. What are the versions of the servers? Use "rxdebug 7001 -version" to find out. Jeffrey Altman --------------ms040307030500020206040309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMjgxNDA4NTRaMCMGCSqGSIb3DQEJBDEWBBQJLvWf WuuxLHBHR0CnN7qC/yknMDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAkCGHFDgV/m+EXY28Z/XClBZgpngHYA52BxOr09MegNAahedx1Tzc jVZS1O3Y6dhbjgnwdZJC84A0U9hclQ+j23XWw1ilnC/uX1vkMDgPBfVDPXzW0hgJ0dvSgGfN kHbkTZ+hdoR0ISoaB/7QHigN+2lHZeVKVEBco/QKNxn+8zmXftiLOA2gXjH/qz22eBiWf7CJ HWN2vYjnvHbVopmhHxnEqoYKwretxkMluOOdycj99VuVt9SvqxdH192b3OD4d/0JwFTRUPDg SwS/rt0jhUqSDxOAAixw7TbLdRrmc5WNAfFySSpJUn0YOADbVumPaBWqHAdeGKmdIxPWd9vw zwAAAAAAAA== --------------ms040307030500020206040309-- From eegay@uncc.edu Tue Oct 28 19:53:55 2008 From: eegay@uncc.edu (Gay, Earl) Date: Tue, 28 Oct 2008 14:53:55 -0400 Subject: [OpenAFS] AFS Filedrawers + modwaklog Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C9392E.8700CD2D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, does anyone know where the best place to ask for help with = modwaklog is other than the semi-inactive modwaklog-devel mailing list? = I'm trying to get Filedrawers working, and I'm having issues getting = modwaklog to compile on 64-bit RHEL 5.2. I'm using OpenAFS 1.4.7, apr = 1.2.7-11, and Apache 2.2.3-11.el5_1.3. My error is essentially the = following: [eegay@64BIT:~/filedrawers/modwaklog] $ export CFLAGS=3D"-fPIC = -I/usr/include/apr-1" ; ./configure --with-afs-libs=3D/usr/lib64/afs = --with-afs-headers=3D/usr/include/afs = --with-apache-headers=3D/usr/include/httpd --with-apxs=3D/usr/sbin/apxs [eegay@64BIT:~/filedrawers/modwaklog] $ make *** Warning: Linking the shared library mod_waklog.la against the = non-libtool *** objects mod_waklog.o lifetime.o version.o is not portable! /usr/bin/ld: mod_waklog.o: relocation R_X86_64_32 against `a local = symbol' can not be used when making a shared object; recompile with = -fPIC mod_waklog.o: could not read symbols: Bad value collect2: ld returned 1 exit status apxs:Error: Command failed with rc=3D65536 . make: *** [mod_waklog.so] Error 1 [eegay@64BIT:~/filedrawers/modwaklog] $ It works fine on 32 bit, but I get this error when trying to get it = going with 64 bit. Any pointers would be greatly appreciated. Thanks, Earl ------_=_NextPart_001_01C9392E.8700CD2D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AFS Filedrawers + modwaklog

Hello, does anyone know where the best place to ask = for help with modwaklog is other than the semi-inactive modwaklog-devel = mailing list? I'm trying to get Filedrawers working, and I'm having = issues getting modwaklog to compile on 64-bit RHEL 5.2. I'm using = OpenAFS 1.4.7, apr 1.2.7-11, and Apache 2.2.3-11.el5_1.3. My error is = essentially the following:

[eegay@64BIT:~/filedrawers/modwaklog] $ export CFLAGS=3D"-fPIC = -I/usr/include/apr-1" ; ./configure = --with-afs-libs=3D/usr/lib64/afs --with-afs-headers=3D/usr/include/afs = --with-apache-headers=3D/usr/include/httpd = --with-apxs=3D/usr/sbin/apxs
[eegay@64BIT:~/filedrawers/modwaklog] $ make
*** Warning: Linking the shared library mod_waklog.la against the = non-libtool
*** objects  mod_waklog.o lifetime.o version.o is not portable!
/usr/bin/ld: mod_waklog.o: relocation R_X86_64_32 against `a local = symbol' can not be used when making a shared object; recompile with = -fPIC
mod_waklog.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
apxs:Error: Command failed with rc=3D65536
.
make: *** [mod_waklog.so] Error 1
[eegay@64BIT:~/filedrawers/modwaklog] $

It works fine on 32 bit, but I get this error when trying to get it = going with 64 bit. Any pointers would be greatly appreciated.

Thanks,
Earl

------_=_NextPart_001_01C9392E.8700CD2D-- From shadow@gmail.com Tue Oct 28 19:59:26 2008 From: shadow@gmail.com (Derrick Brashear) Date: Tue, 28 Oct 2008 14:59:26 -0400 Subject: [OpenAFS] AFS Filedrawers + modwaklog In-Reply-To: References: Message-ID: On Tue, Oct 28, 2008 at 2:53 PM, Gay, Earl wrote: > Hello, does anyone know where the best place to ask for help with modwaklog > is other than the semi-inactive modwaklog-devel mailing list? More patience than 10 minutes probably does get you an answer on that list. Certainly I know I sent one :) From rmeans@law.berkeley.edu Tue Oct 28 22:37:46 2008 From: rmeans@law.berkeley.edu (Ryan L. Means) Date: Tue, 28 Oct 2008 14:37:46 -0700 Subject: [OpenAFS] Integrated logon and locking/unlocking workstatations Message-ID: <4907862A.6010106@law.berkeley.edu> Good afternoon, We are just starting to use AFS here at the School of Law at UC Berkeley. Everything seems to be working well with OpenAFS for Windows and the integrated logon functionality that grabs a Kerberos 5 ticket and then the AFS token. Unfortunately, it seems that when a user locks their workstation, leaves for longer than the 10 hour ticket expiration period, and then comes back, the ticket and token have expired and the act of unlocking the workstation doesn't get another set. We do have an abnormal setup here where there are two realms, one MIT, one AD. The passwords are synchronized between the realms, but the user does log into their workstation using the AD identity and access AFS resources with the MIT identity. So far, with the integrated login, this hasn't been a problem. Is this locking/unlocking issue caused by the split realms, or is there another force at work? Thanks to anyone who can help! Ryan From jaltman@secure-endpoints.com Tue Oct 28 23:57:47 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Tue, 28 Oct 2008 15:57:47 -0700 Subject: [OpenAFS] Integrated logon and locking/unlocking workstatations In-Reply-To: <4907862A.6010106@law.berkeley.edu> References: <4907862A.6010106@law.berkeley.edu> Message-ID: <490798EB.3060804@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms050006020105090809030804 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit There is no notification to any process that is running that the MSLSA obtained new Kerberos v5 tickets OR a hook that would obtain the user's name/password during unlocking to use to request a new TGT and AFS token. There is nothing abnormal about your setup. What are you using for a credential manager? Jeffrey Altman Ryan L. Means wrote: > Good afternoon, > > We are just starting to use AFS here at the School of Law at UC > Berkeley. Everything seems to be working well with OpenAFS for Windows > and the integrated logon functionality that grabs a Kerberos 5 ticket > and then the AFS token. Unfortunately, it seems that when a user locks > their workstation, leaves for longer than the 10 hour ticket expiration > period, and then comes back, the ticket and token have expired and the > act of unlocking the workstation doesn't get another set. > > We do have an abnormal setup here where there are two realms, one MIT, > one AD. The passwords are synchronized between the realms, but the user > does log into their workstation using the AD identity and access AFS > resources with the MIT identity. So far, with the integrated login, this > hasn't been a problem. Is this locking/unlocking issue caused by the > split realms, or is there another force at work? > > Thanks to anyone who can help! > > Ryan > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > --------------ms050006020105090809030804 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMjgyMjU3NDdaMCMGCSqGSIb3DQEJBDEWBBTvGD6c UeqKmcSxlDrczX3ki8XQUDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEADRQjsA2i6GE7CroMe8CcoRYtshG3nCXm208KRE3p5hdUaF2YrZQQ Tv2wHBIHPUbLA+mk6l7arcRnaZYuY5kfKOzV5v1lmRKH+OOQ3ZAIa4tJbonSenuRpXgMqTkR 8pwxmd4iZ2CFgalhXbwc4Mn52BibT31+c9n3qrxYpFWBXctU34tkXBgaWNaNjq8VIyTbPhYf P3Yecn62NpDphnfFrSO0c4f6xqroIMTBmQWJopED9t6AYeZd8fU2hSW0tbrD1rXApdt9l2bF YVVFB78ias83kGkKD8lriyBsPsMXFN4mu4O+Rw9ICcR85B84drgZoqOPabnxicmUre8dpq9M 8wAAAAAAAA== --------------ms050006020105090809030804-- From rmeans@law.berkeley.edu Wed Oct 29 00:11:17 2008 From: rmeans@law.berkeley.edu (Ryan L. Means) Date: Tue, 28 Oct 2008 16:11:17 -0700 Subject: [OpenAFS] Integrated logon and locking/unlocking workstatations In-Reply-To: <490798EB.3060804@secure-endpoints.com> References: <4907862A.6010106@law.berkeley.edu> <490798EB.3060804@secure-endpoints.com> Message-ID: <49079C15.4010502@law.berkeley.edu> Jeffrey Altman wrote: > There is no notification to any process that is running that > the MSLSA obtained new Kerberos v5 tickets OR a hook that would > obtain the user's name/password during unlocking to use to request > a new TGT and AFS token. So you're saying there really isn't any way to do the same thing on unlock that happens on login. Can you think of any other way to solve or work around this problem besides just telling the user to log out instead of locking? Unfortunately, they won't buy having to type in their password twice every time they come in in the morning. > > There is nothing abnormal about your setup. > > What are you using for a credential manager? I'm using MIT KFW 3.2.2. Thanks, Ryan From jaltman@secure-endpoints.com Wed Oct 29 00:36:58 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Tue, 28 Oct 2008 16:36:58 -0700 Subject: [OpenAFS] Integrated logon and locking/unlocking workstatations In-Reply-To: <49079C15.4010502@law.berkeley.edu> References: <4907862A.6010106@law.berkeley.edu> <490798EB.3060804@secure-endpoints.com> <49079C15.4010502@law.berkeley.edu> Message-ID: <4907A21A.8030503@secure-endpoints.com> Ryan L. Means wrote: > Jeffrey Altman wrote: >> There is no notification to any process that is running that >> the MSLSA obtained new Kerberos v5 tickets OR a hook that would >> obtain the user's name/password during unlocking to use to request >> a new TGT and AFS token. > > So you're saying there really isn't any way to do the same thing on > unlock that happens on login. Can you think of any other way to solve or > work around this problem besides just telling the user to log out > instead of locking? Unfortunately, they won't buy having to type in > their password twice every time they come in in the morning. > >> >> There is nothing abnormal about your setup. >> >> What are you using for a credential manager? > > I'm using MIT KFW 3.2.2. The problem is that I don't know what can be used by NetIDMgr as a trigger to attempt re-importing the MSLSA: TGT and using it to obtain derivative credentials. There is no code for this at present. Jeffrey Altman From lorenl@north-winds.org Wed Oct 29 01:44:35 2008 From: lorenl@north-winds.org (Loren M. Lang) Date: Tue, 28 Oct 2008 17:44:35 -0700 Subject: [OpenAFS] Mounting a backup Message-ID: <1225241075.8581.22.camel@ruth.aloha.tallye.com> --=-GjQlAVBb57dOKzxhTHjK Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I am looking for a way to mount a snapshot of last nights backup. All volumes have a backup volume currently and I then mounted root.cell as /afs/./archive. archive was read-only and did not change when I changed the RW volume for root.cell and released it, but all the mount points under the backup volume traversed to the RO or RW volumes. Is there a way to make the mount points traverse similarly to how mount points for volumes with RO clones work? --=20 Loren M. Lang lorenl@north-winds.org http://www.north-winds.org/ Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B --=-GjQlAVBb57dOKzxhTHjK Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBJB7Hz3O67OXZU3lsRAj6AAJ9aaW709MPvemYvASWKtHFCqRoBwgCeJe3O 3bPe+7ZdVLlwlS70zulkzSI= =MVvw -----END PGP SIGNATURE----- --=-GjQlAVBb57dOKzxhTHjK-- From steven.jenkins@gmail.com Wed Oct 29 16:31:33 2008 From: steven.jenkins@gmail.com (Steven Jenkins) Date: Wed, 29 Oct 2008 11:31:33 -0400 Subject: [OpenAFS] Mounting a backup In-Reply-To: <1225241075.8581.22.camel@ruth.aloha.tallye.com> References: <1225241075.8581.22.camel@ruth.aloha.tallye.com> Message-ID: On Tue, Oct 28, 2008 at 8:44 PM, Loren M. Lang wrote: > I am looking for a way to mount a snapshot of last nights backup. All > volumes have a backup volume currently and I then mounted root.cell > as /afs/./archive. archive was read-only and did not change when > I changed the RW volume for root.cell and released it, but all the mount > points under the backup volume traversed to the RO or RW volumes. Is > there a way to make the mount points traverse similarly to how mount > points for volumes with RO clones work? There is not a way to create a mountpoint that will 'automatically' traverse backup volumes without specifying the backup volume itself, for example, you'll need to do something like fs mkmount -dir /afs/mycell/backups/somepath -vol myvol.backup Changing traversal semantics while in .backup volumes (e.g., to be 'once in a .backup volume, prefer to traverse to backup volumes) could be done, but, to my knowledge, that's not on anyone's Road Map. How helpful would that change be? Thanks, Steven Jenkins End Point Corporation http://www.endpoint.com/ From jason@rampaginggeek.com Wed Oct 29 17:46:45 2008 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Wed, 29 Oct 2008 12:46:45 -0400 Subject: [OpenAFS] Mounting a backup In-Reply-To: References: <1225241075.8581.22.camel@ruth.aloha.tallye.com> Message-ID: <49089375.8050101@rampaginggeek.com> Steven Jenkins wrote: > On Tue, Oct 28, 2008 at 8:44 PM, Loren M. Lang wrote: > >> I am looking for a way to mount a snapshot of last nights backup. All >> volumes have a backup volume currently and I then mounted root.cell >> as /afs/./archive. archive was read-only and did not change when >> I changed the RW volume for root.cell and released it, but all the mount >> points under the backup volume traversed to the RO or RW volumes. Is >> there a way to make the mount points traverse similarly to how mount >> points for volumes with RO clones work? >> > > > There is not a way to create a mountpoint that will 'automatically' > traverse backup volumes without specifying the backup volume itself, > for example, you'll need to do something like > > fs mkmount -dir /afs/mycell/backups/somepath -vol myvol.backup > > Changing traversal semantics while in .backup volumes (e.g., to be > 'once in a .backup volume, prefer to traverse to backup volumes) > could be done, but, to my knowledge, that's not on anyone's Road Map. > > How helpful would that change be? > This feature is available as an option to the afsd command. If you add the "-backuptree" option to the afs client startup script, then it will prefer backup volumes once in a backup volume. This "-backuptree" option is not enabled by default. See http://www.openafs.org/pages/manpages/8/afsd.html for more info. Thanks, Jason From steven.jenkins@gmail.com Wed Oct 29 17:52:58 2008 From: steven.jenkins@gmail.com (Steven Jenkins) Date: Wed, 29 Oct 2008 12:52:58 -0400 Subject: [OpenAFS] Mounting a backup In-Reply-To: <49089375.8050101@rampaginggeek.com> References: <1225241075.8581.22.camel@ruth.aloha.tallye.com> <49089375.8050101@rampaginggeek.com> Message-ID: ... >> > This feature is available as an option to the afsd command. If you add > the "-backuptree" option to the afs client startup script, then it will > prefer backup volumes once in a backup volume. This "-backuptree" option > is not enabled by default. > Wow. Great. I'm too out-of-date; I need a 'What's changed in OpenAFS' view sometime. -- Steven Jenkins End Point Corporation http://www.endpoint.com/ From lorenl@north-winds.org Wed Oct 29 20:42:16 2008 From: lorenl@north-winds.org (Loren M. Lang) Date: Wed, 29 Oct 2008 12:42:16 -0700 Subject: [OpenAFS] Cell name size limit in Network Identity Manager Message-ID: <1225309336.18842.7.camel@ruth.aloha.tallye.com> --=-x6ukBwUcXtAmR8+4YMHt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I have a cell with a rather long cell name, rockcreekchristiancenter.org. It was not my decision to go with that name. I am having trouble adding it to identities in the Network Identity Manager, it does not allow me to type the final g in the cell name. If I make that cell the default cell for the client, it will be automatically filled in and I can just click add, but for other computers, I must edit the registry to add the g. What's even more frustrating is that it is a font size limit, not a character limit. rockcreekchristiancentei.org fits and it the same number of characters, but an r was replaced with an i. --=20 Loren M. Lang lorenl@north-winds.org http://www.north-winds.org/ Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B --=-x6ukBwUcXtAmR8+4YMHt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBJCLyY3O67OXZU3lsRAr6eAJwMg1JsAU8MIpBSqmd1Qr1sl56vQQCeMPJf c5YkInFsf7W///phvQlNn40= =hJlx -----END PGP SIGNATURE----- --=-x6ukBwUcXtAmR8+4YMHt-- From lorenl@north-winds.org Wed Oct 29 20:47:44 2008 From: lorenl@north-winds.org (Loren M. Lang) Date: Wed, 29 Oct 2008 12:47:44 -0700 Subject: [OpenAFS] Retrieve credentials for cell automatically Message-ID: <1225309664.18842.13.camel@ruth.aloha.tallye.com> --=-I+hRQCI+UcmKujv6pqds Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I am looking for a way to tell the Network Identity Manager to retrieve credentials for the home cell of a client when a new user logs in. Currently, when users log in, they will get their Kerberos credentials automatically from the default MIT Kerberos realm, but not AFS credentials. They have to edit the identity settings for that identity and click add to add the default AFS cell to their identity. After that future log-ins will work, but, as we do not use roaming profiles, logging in to a different computer for the first time and they will still have to add the cell. The default realm is EXAMPLE.COM and the default cell is example.com. Since this setting is stored per-identity per-user, I am not sure how to set it up automatically other than a fancy logon script. --=20 Loren M. Lang lorenl@north-winds.org http://www.north-winds.org/ Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B --=-I+hRQCI+UcmKujv6pqds Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBJCL3g3O67OXZU3lsRAlCxAKDiYT4n0T7+LBSchK78EMRyRT3VzgCeP1gE VZG/qq/f1u2EgpoPrCUbTcw= =ovbL -----END PGP SIGNATURE----- --=-I+hRQCI+UcmKujv6pqds-- From Jerry.Normandin@dafca.com Wed Oct 29 20:57:07 2008 From: Jerry.Normandin@dafca.com (Jerry Normandin) Date: Wed, 29 Oct 2008 12:57:07 -0700 Subject: [OpenAFS] Cell name size limit in Network Identity Manager In-Reply-To: <1225309336.18842.7.camel@ruth.aloha.tallye.com> Message-ID: <3BE535873FE31A4186EF7828495A26A4344954@EXVBE005-3.exch005intermedia.net> I'd rename the cell to rccc.org That's much easier to type, and no problems adding it into the identities manager. -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org] On Behalf Of Loren M. Lang Sent: Wednesday, October 29, 2008 3:42 PM To: openafs-info Subject: [OpenAFS] Cell name size limit in Network Identity Manager I have a cell with a rather long cell name, rockcreekchristiancenter.org. It was not my decision to go with that name. I am having trouble adding it to identities in the Network Identity Manager, it does not allow me to type the final g in the cell name. If I make that cell the default cell for the client, it will be automatically filled in and I can just click add, but for other computers, I must edit the registry to add the g. What's even more frustrating is that it is a font size limit, not a character limit. rockcreekchristiancentei.org fits and it the same number of characters, but an r was replaced with an i. --=20 Loren M. Lang lorenl@north-winds.org http://www.north-winds.org/ Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B From jason@rampaginggeek.com Thu Oct 30 01:56:21 2008 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Wed, 29 Oct 2008 20:56:21 -0400 Subject: [OpenAFS] Mounting a backup In-Reply-To: References: <1225241075.8581.22.camel@ruth.aloha.tallye.com> <49089375.8050101@rampaginggeek.com> Message-ID: <49090635.401@rampaginggeek.com> Steven Jenkins wrote: > ... > >> This feature is available as an option to the afsd command. If you add >> the "-backuptree" option to the afs client startup script, then it will >> prefer backup volumes once in a backup volume. This "-backuptree" option >> is not enabled by default. >> >> > > Wow. Great. > > I'm too out-of-date; I need a 'What's changed in OpenAFS' view sometime Reading the changlogs or CVS emails helps, but some stuff is there but still needs to be documented. Jason From Felix.Frank@Desy.de Thu Oct 30 11:18:16 2008 From: Felix.Frank@Desy.de (Felix Frank) Date: Thu, 30 Oct 2008 11:18:16 +0100 (CET) Subject: [OpenAFS] Foundation Plan redux In-Reply-To: <428CFEBA-29B5-4574-A2B2-F93C0C2E8359@inf.ed.ac.uk> References: <435B77BA27FC254099B1763E498DEF665F493A@va1exc02.SNAADS.sinenomine.net> <428CFEBA-29B5-4574-A2B2-F93C0C2E8359@inf.ed.ac.uk> Message-ID: >> How long can one obtain >> as a gatekeeper or board member? Is there a term limit (a desirable >> thing, IMHO, as it forces an organization to develop new leaders rather >> than having the same faces in the same places)? > > In this case, as with AFS standardisation, I strongly disagree that term > limits are desirable. At their worst, they just ensure the retirement of > strong post holders, and their replacement with inexperienced ones. > > OpenAFS badly needs a way of encouraging new faces, and growing those > individuals into positions of responsibility. I don't believe that requiring > the abdication of successful leaders after some arbitrary period will help > with this. It's kind of like cutting off the head of a random animal in the > hope that it will grow a new one - it works in a small number of cases, but > the rest of the time you'll end up with a lifeless corpse. I'm not sure about the accuracy of that simile. The above suggestion doesn't imply the metaphorical "cutting off" of anything, as experienced leaders would surely be expected to stay around and fill at least an advisory (if not controlling) role. But then, bearing that in mind, it's unclear to me as well how much good term limits could actually do towards the goal of encouraging new people to take actual responsibility. But too strict a seperation of responsibilities would probably lead to the decapitated body you described. Regards, Felix From l.schimmer@cgv.tugraz.at Thu Oct 30 15:25:32 2008 From: l.schimmer@cgv.tugraz.at (Lars Schimmer) Date: Thu, 30 Oct 2008 15:25:32 +0100 Subject: [OpenAFS] Windows apache htdocs in AFS space? Message-ID: <4909C3DC.8000003@cgv.tugraz.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! On one of our projects we need a apache server on a windows client. We thought about putting the htdocs into AFS space and created a IP entry for the user into the PTS database and a special directory for the data of the htdoc with the IP in the ACL. (server is jsut internal reachable with no security riscy data). The problem now: start windows pc, start apache - apache dies Sart windows PC, access the directory in the AFS space with explorer, start apache -works. Any idea why access the directory with explorer let the apache not to crah, or better: why does apache crash if AFS was not "touched" by explorer before? MfG, Lars Schimmer - -- - ------------------------------------------------------------- TU Graz, Institut f=FCr ComputerGraphik & WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schimmer@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkJw9wACgkQmWhuE0qbFyOsogCdE9cwL/N+ekVII7BYdKLS/7JH 7XkAni5oLGeglX5hm4spd4mG89tqWp2R =3DKSrh -----END PGP SIGNATURE----- From l.schimmer@cgv.tugraz.at Thu Oct 30 15:26:08 2008 From: l.schimmer@cgv.tugraz.at (Lars Schimmer) Date: Thu, 30 Oct 2008 15:26:08 +0100 Subject: [OpenAFS] Re: Windows apache htdocs in AFS space? In-Reply-To: <4909C3DC.8000003@cgv.tugraz.at> References: <4909C3DC.8000003@cgv.tugraz.at> Message-ID: <4909C400.6060608@cgv.tugraz.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lars Schimmer wrote: > Hi! >=20 > On one of our projects we need a apache server on a windows client. > We thought about putting the htdocs into AFS space and created a IP > entry for the user into the PTS database and a special directory for th= e > data of the htdoc with the IP in the ACL. > (server is jsut internal reachable with no security riscy data). >=20 > The problem now: start windows pc, start apache - apache dies > Sart windows PC, access the directory in the AFS space with explorer, > start apache -works. >=20 > Any idea why access the directory with explorer let the apache not to > crah, or better: why does apache crash if AFS was not "touched" by > explorer before? Missed: Win XP SP3, OpenAFS 1.5.54 MfG, Lars Schimmer - -- - ------------------------------------------------------------- TU Graz, Institut f=FCr ComputerGraphik & WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schimmer@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkJxAAACgkQmWhuE0qbFyMAJQCfXVLYliSsISh1e+CBbjQ66FoQ d48AnR1gKhTvXWoi3MfgzKo+tZ7yYz1V =3DvLyA -----END PGP SIGNATURE----- From deengert@anl.gov Thu Oct 30 16:10:31 2008 From: deengert@anl.gov (Douglas E. Engert) Date: Thu, 30 Oct 2008 10:10:31 -0500 Subject: [OpenAFS] Integrated logon and locking/unlocking workstatations In-Reply-To: <4907862A.6010106@law.berkeley.edu> References: <4907862A.6010106@law.berkeley.edu> Message-ID: <4909CE67.3070806@anl.gov> Ryan L. Means wrote: > Good afternoon, > > We are just starting to use AFS here at the School of Law at UC > Berkeley. Everything seems to be working well with OpenAFS for Windows > and the integrated logon functionality that grabs a Kerberos 5 ticket > and then the AFS token. Unfortunately, it seems that when a user locks > their workstation, leaves for longer than the 10 hour ticket expiration > period, and then comes back, the ticket and token have expired and the > act of unlocking the workstation doesn't get another set. > > We do have an abnormal setup here where there are two realms, one MIT, > one AD. Different realm names? > The passwords are synchronized between the realms, but the user > does log into their workstation using the AD identity and access AFS > resources with the MIT identity. Is the AFS access then using K4 or K5 to get AFS tokens? > So far, with the integrated login, this > hasn't been a problem. Is this locking/unlocking issue caused by the > split realms, or is there another force at work? > > Thanks to anyone who can help! Is there any reason that you could not use the AD K5 realm to get the afs K5 ticket? At least for Windows users? As Jeff pointed out in a prevuios note there is no notification for th screen unlock where the netmgr could get the username and password to use with the second realm. With K5, tickets may be renewable and the netmgr will renew K5 tickets and get a new AFS token so the 10 hour limit is not a real issue till the RenewUntil time was reached. If your MIT real is using K5 does it allow renewable tickets, and for how long? If you could use the Windows KDC with AFS, the netmgr could use the MSLSA to get the updated TGT created by screen unlock with a new RenewUntil time. Jeff, The netmgr can import tickets from MSLSA, but only appears to do this at login or when the import credentials is selected. Could it do this on a periodic bases to check if the MSLA TGT might have been updated by a screen unlock? Or did I miss something? So if Ryan can use the Windows DC as the KDC, with renewable tickets with a reasonable RenewUntil time, and the users unlock their machines some time withing the RenewUntil time, they would never loose their AFS token. > > Ryan > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From matt@linuxbox.com Thu Oct 30 17:07:43 2008 From: matt@linuxbox.com (Matt Benjamin) Date: Thu, 30 Oct 2008 12:07:43 -0400 Subject: rotation/term limits: Was: [OpenAFS] Foundation Plan redux In-Reply-To: References: <435B77BA27FC254099B1763E498DEF665F493A@va1exc02.SNAADS.sinenomine.net> <428CFEBA-29B5-4574-A2B2-F93C0C2E8359@inf.ed.ac.uk> Message-ID: <4909DBCF.4070200@linuxbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I think I'm with Felix here. I'm not completely sure whether term limits do or don't help in the abstract. It felt to me the last time I thought through this that diversity or size or balance of the body might be equally important factors. Before the current drafts were published, I took the position that perhaps there was nothing intrinsically wrong with the original gatekeeper role, and that we simply needed to be recruiting and developing more of them. That's not how things are moving, though. In the proposal, there are at least three different leadership bodies, board, TAC, project leaders in the organization structure Derrick has proposed. There will no longer be gatekeepers or elders, at least in name. Presumably rotation or other restrictions might be more important for some of the proposed bodies than others. It seems important to really understand (or discuss more explicitly) the kinds of decisions or activities the individuals in each of those bodies will need to perform, and look at how exclusivity and rotation/non-rotation would play into those. Matt Felix Frank wrote: >>> How long can one obtain >>> as a gatekeeper or board member? Is there a term limit (a desirable >>> thing, IMHO, as it forces an organization to develop new leaders rather >>> than having the same faces in the same places)? > But then, bearing that in mind, it's unclear to me as well how much good > term limits could actually do towards the goal of encouraging new people > to take actual responsibility. But too strict a seperation of > responsibilities would probably lead to the decapitated body you described. > - -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJCdvPJiSUUSaRdSURCPReAJ9es0oIpcFevqhhk28uCzeEOzosVACfco+S 74NMNJiZqrA+dXCjBvyZyzY= =2nCo -----END PGP SIGNATURE----- From jaltman@secure-endpoints.com Thu Oct 30 17:37:34 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 30 Oct 2008 09:37:34 -0700 Subject: [OpenAFS] Integrated logon and locking/unlocking workstatations In-Reply-To: <4909CE67.3070806@anl.gov> References: <4907862A.6010106@law.berkeley.edu> <4909CE67.3070806@anl.gov> Message-ID: <4909E2CE.8000007@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms090509040005090907030507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Douglas E. Engert wrote: > Jeff, > The netmgr can import tickets from MSLSA, but only appears to do this > at login or when the import credentials is selected. Could it do this > on a periodic bases to check if the MSLA TGT might have been updated > by a screen unlock? Or did I miss something? > > So if Ryan can use the Windows DC as the KDC, with renewable tickets > with a reasonable RenewUntil time, and the users unlock their machines > some time withing the RenewUntil time, they would never loose > their AFS token. There are lots of things NIM could do. None of them are things that NIM does today. Therefore, NIM as currently shipped will not do what Ryan needs. The correct one is to receive notification that the LSA has new tickets and do something with them. The only notifications I see are for terminal server. I will need to research what other possibilities there are. Jeffrey Altman --------------ms090509040005090907030507 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMzAxNjM3MzRaMCMGCSqGSIb3DQEJBDEWBBTWAp24 Sp9wGnAtqR/CAQI3UDvCATBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAVnHLfm1ZOIWw8FGoKOI6+3u56BbFDS7Fzxi80ws+iw3Col2VxbeJ BrgeYgdh5MefFXhLwA+Kjv1gbrpB2wHymP161kSgsyQ3UzK44DLftLrwqraIcxnoUzgpbViE XiJe9x0A8H9aGAbqfpkxD3lGejISQeMo660HZbpo/1HCb/0O2fgmf/hHCB2OjqkxU3bf6qVc 2dAKaN+DWId0SQIscM7wbGiwVwggGNF2rQSXhZeKEk92BW/socKktGYNeqTHyrL4bm07Dusd 2uz6pFHTJqfIaw9DoN3DR7MEaxCFKBupzNYOdIrnmMv18jikSLp4yoboE3+6J9korY1gbaED UAAAAAAAAA== --------------ms090509040005090907030507-- From ragge@ltu.se Thu Oct 30 18:46:31 2008 From: ragge@ltu.se (Anders Magnusson) Date: Thu, 30 Oct 2008 18:46:31 +0100 Subject: [OpenAFS] Integrated logon and locking/unlocking workstatations In-Reply-To: <4909E2CE.8000007@secure-endpoints.com> References: <4907862A.6010106@law.berkeley.edu> <4909CE67.3070806@anl.gov> <4909E2CE.8000007@secure-endpoints.com> Message-ID: <4909F2F7.5040603@ltu.se> Jeffrey Altman wrote: > Douglas E. Engert wrote: > > >> Jeff, >> The netmgr can import tickets from MSLSA, but only appears to do this >> at login or when the import credentials is selected. Could it do this >> on a periodic bases to check if the MSLA TGT might have been updated >> by a screen unlock? Or did I miss something? >> >> So if Ryan can use the Windows DC as the KDC, with renewable tickets >> with a reasonable RenewUntil time, and the users unlock their machines >> some time withing the RenewUntil time, they would never loose >> their AFS token. >> > > There are lots of things NIM could do. None of them are things that > NIM does today. Therefore, NIM as currently shipped will not do what > Ryan needs. > > The correct one is to receive notification that the LSA has new tickets > and do something with them. The only notifications I see are for > terminal server. I will need to research what other possibilities > there are. > Not that I know how any of these things works in Windows, but wouldn't it be possible to get the LSA to keep track of and renew the afs ticket, and then just have a really small program that just asks the LSA for the afs principal and convert it to an afs token? And then let the LSA handle everything around. -- Ragge From rmeans@law.berkeley.edu Thu Oct 30 18:31:17 2008 From: rmeans@law.berkeley.edu (Ryan L. Means) Date: Thu, 30 Oct 2008 10:31:17 -0700 Subject: [OpenAFS] Integrated logon and locking/unlocking workstatations In-Reply-To: <4909CE67.3070806@anl.gov> References: <4907862A.6010106@law.berkeley.edu> <4909CE67.3070806@anl.gov> Message-ID: <4909EF65.10405@law.berkeley.edu> Douglas E. Engert wrote: > Ryan L. Means wrote: >> Good afternoon, >> >> We are just starting to use AFS here at the School of Law at UC >> Berkeley. Everything seems to be working well with OpenAFS for Windows >> and the integrated logon functionality that grabs a Kerberos 5 ticket >> and then the AFS token. Unfortunately, it seems that when a user locks >> their workstation, leaves for longer than the 10 hour ticket >> expiration period, and then comes back, the ticket and token have >> expired and the act of unlocking the workstation doesn't get another set. >> >> We do have an abnormal setup here where there are two realms, one MIT, >> one AD. > > Different realm names? Yes, the BERKELEY.EDU realm exists on the MIT KDC, but there is another realm name for the Windows AD KDC. To make a long story short, the administrators of our previously existing MIT KDC infrastructure did not trust that Windows AD would provide an acceptable KDC. For a while we even had a cross-realm trust and users would log into their workstations with the MIT realm identity instead of the AD one (that is no longer the case). There are plans to merge the two KDCs now, but it could be over a year before that happens, if it happens at all. > Is the AFS access then using K4 or K5 to get AFS tokens? K5 from the MIT KDC. > Is there any reason that you could not use the AD K5 realm to get the > afs K5 ticket? At least for Windows users? Other than the problem of it being very confusing for our users that move from Windows to Mac to Unix, no. The problem is that the protection server currently only allows one identity for each AFS user (right?). So if we could have both identities in there there wouldn't be any problems at all. > As Jeff pointed out in a prevuios note there is no notification for th > screen unlock where the netmgr could get the username and password to use > with the second realm. > > With K5, tickets may be renewable and the netmgr will renew K5 tickets > and get a new AFS token so the 10 hour limit is not a real issue > till the RenewUntil time was reached. If your MIT real is using K5 > does it allow renewable tickets, and for how long? Yes, it does allow renewable tickets for up to 7 days. But, it doesn't seem like netmgr is renewing them when the workstation is locked. That would help the problem because then users who never log out would only be prompted every 7 days... > If you could use the Windows KDC with AFS, the netmgr could use > the MSLSA to get the updated TGT created by screen unlock with a new > RenewUntil time. Right, but this isn't going to be workable for us until the realms are merged. > Jeff, > The netmgr can import tickets from MSLSA, but only appears to do this > at login or when the import credentials is selected. Could it do this > on a periodic bases to check if the MSLA TGT might have been updated > by a screen unlock? Or did I miss something? > > So if Ryan can use the Windows DC as the KDC, with renewable tickets > with a reasonable RenewUntil time, and the users unlock their machines > some time withing the RenewUntil time, they would never loose > their AFS token. > Thanks, Doug! From shadow@gmail.com Thu Oct 30 18:36:35 2008 From: shadow@gmail.com (Derrick Brashear) Date: Thu, 30 Oct 2008 13:36:35 -0400 Subject: rotation/term limits: Was: [OpenAFS] Foundation Plan redux In-Reply-To: <4909DBCF.4070200@linuxbox.com> References: <435B77BA27FC254099B1763E498DEF665F493A@va1exc02.SNAADS.sinenomine.net> <428CFEBA-29B5-4574-A2B2-F93C0C2E8359@inf.ed.ac.uk> <4909DBCF.4070200@linuxbox.com> Message-ID: > In the proposal, there are at least three different leadership bodies, > board, TAC, project leaders in the organization structure Derrick has > proposed. The board isn't really directly technical, at least in the sense of being responsible for technical decisions of the project (or of related projects which might find a home under the foundation umbrella; for instance if any of the libraries being used in the extended callback enhancement work needed a home and would be made available for general use, it would be of tremendous benefit to OpenAFS to have those continue to be maintained and developed, but not all users of those libraries would want or need to be involved in other OpenAFS efforts; Another TAC could be convened for that project). Their duty is to ensure the corporation would fulfill all legal responsibilities, and obligations and expectations of its members. The Technical Advisory Council, why would you want term limits? One presumes people who are donating money aren't just throwing the money away and will be intelligent about putting their best-qualified people towards stewarding what they've provided. Likewise, the elected community members will I assume not get re-elected if they are not serving their constituency. In that regard a term limit restricts the freedom of members to vote for those they feel best represent their views and are interested in serving. As to the project leaders, they are subject to recall and additional members being added to their ranks, but a term would be "as long as they continue to be of use to the community", effectively. Derrick speaking for myself only Derrick From jaltman@secure-endpoints.com Thu Oct 30 18:49:54 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 30 Oct 2008 10:49:54 -0700 Subject: [OpenAFS] Integrated logon and locking/unlocking workstatations In-Reply-To: <4909EF65.10405@law.berkeley.edu> References: <4907862A.6010106@law.berkeley.edu> <4909CE67.3070806@anl.gov> <4909EF65.10405@law.berkeley.edu> Message-ID: <4909F3C2.9040303@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms090607000302060602000306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ryan L. Means wrote: > Yes, it does allow renewable tickets for up to 7 days. But, it doesn't > seem like netmgr is renewing them when the workstation is locked. That > would help the problem because then users who never log out would only > be prompted every 7 days... NetIDMgr doesn't know that the machine is locked. It renews the tickets for as long as the KDC will do so. Jeffrey Altman --------------ms090607000302060602000306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMzAxNzQ5NTRaMCMGCSqGSIb3DQEJBDEWBBQUbeYW +Qzg8bSLGL6zjJO+o/PG0TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAW2hTuZr4AmMWCPV7iufDMn6c10eAp1DuRqgjZAiA1CCHE469+1c9 RT4bY67qKdpBvTBXNOOSpEPab4s5JrsZ2p28y2r/+PGO7pIggOZW/oL5er8fzv1pziKnPi61 f8pzfjAspM+kKpAGUdSCbaNeQ4sbVwRgY3dKZQbtsSJkVrG8eiNMOk8gXDHSu/vAxafFc7CY UcXFJrBuC+LzXCEz66aeLkoTXBwGvUm/SV7xWWQ4wUSQd/NVPuBBpBqrdxNVKJZjOOatTaro k1QRcg3jLfYe03nX5/EnKOAeBFLecbUXwQSAsouhCe+Mcx/KBzzlgtR6w2amUtmHMSJRt/Dm FQAAAAAAAA== --------------ms090607000302060602000306-- From jaltman@secure-endpoints.com Thu Oct 30 18:52:25 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 30 Oct 2008 10:52:25 -0700 Subject: [OpenAFS] Integrated logon and locking/unlocking workstatations In-Reply-To: <4909F2F7.5040603@ltu.se> References: <4907862A.6010106@law.berkeley.edu> <4909CE67.3070806@anl.gov> <4909E2CE.8000007@secure-endpoints.com> <4909F2F7.5040603@ltu.se> Message-ID: <4909F459.1020304@secure-endpoints.com> Anders Magnusson wrote: > Not that I know how any of these things works in Windows, but wouldn't it be > possible to get the LSA to keep track of and renew the afs ticket, and > then just > have a really small program that just asks the LSA for the afs principal > and convert > it to an afs token? And then let the LSA handle everything around. The LSA does not renew service tickets. The LSA renews the TGT. An application that requests a service ticket obtains it using the TGT. The application that periodically requests the AFS service ticket and produces a token is NetIDMgr. Jeffrey Altman From rmeans@law.berkeley.edu Thu Oct 30 18:54:27 2008 From: rmeans@law.berkeley.edu (Ryan L. Means) Date: Thu, 30 Oct 2008 10:54:27 -0700 Subject: [OpenAFS] Integrated logon and locking/unlocking workstatations In-Reply-To: <4909F3C2.9040303@secure-endpoints.com> References: <4907862A.6010106@law.berkeley.edu> <4909CE67.3070806@anl.gov> <4909EF65.10405@law.berkeley.edu> <4909F3C2.9040303@secure-endpoints.com> Message-ID: <4909F4D3.1000609@law.berkeley.edu> Jeffrey Altman wrote: > Ryan L. Means wrote: > >> Yes, it does allow renewable tickets for up to 7 days. But, it doesn't >> seem like netmgr is renewing them when the workstation is locked. That >> would help the problem because then users who never log out would only >> be prompted every 7 days... > > NetIDMgr doesn't know that the machine is locked. > It renews the tickets for as long as the KDC will do so. No, I understand. What I'm saying is that I believe that while the workstation is locked, NetIDMgr is not continuing to renew the tickets in the background. But, that doesn't make any sense since it's a service and doesn't require an interactive session with the desktop. I'll explore more thoroughly. Ryan From David.Bear@asu.edu Thu Oct 30 19:43:15 2008 From: David.Bear@asu.edu (David Bear) Date: Thu, 30 Oct 2008 11:43:15 -0700 Subject: [OpenAFS] openafs pioctl issue on windows In-Reply-To: <49012EE3.30600@secure-endpoints.com> References: <1d1a54bf0810221205r75e30746o49dcff3c409e7638@mail.gmail.com> <48FF7C91.9070605@secure-endpoints.com> <1d1a54bf0810221256y1143977pf648adc4a10221e4@mail.gmail.com> <48FF9B01.9030908@secure-endpoints.com> <1d1a54bf0810231556i78e6c26fk7e612da83d9f6a35@mail.gmail.com> <49012EE3.30600@secure-endpoints.com> Message-ID: <1d1a54bf0810301143h3e52c4f5l22845b7163804064@mail.gmail.com> ------=_Part_16910_15078553.1225392195300 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This is getting stranger and stranger -- Jeff, I finally got the name of another service to test.. below is a screen shot of what happened. On Thu, Oct 23, 2008 at 7:11 PM, Jeffrey Altman < jaltman@secure-endpoints.com> wrote: > David Bear wrote: > > KFW is version 3.2.2 -- resintalled today. > > Windows is XP Pro with SP2 > > credential cache is API: -- we do make use of windows logon credentials. > > I've stopped using kinit and only use NIM to get and destroy tickets. I > > do succesfully get tickets in asu.edu , as the output > > of klist shows: > > Ticket cache: API:bvossoug@ASU.EDU API%3Abvossoug@ASU.EDU > > > Default principal: bvossoug@ASU.EDU > > > > Valid starting Expires Service principal > > 10/23/08 15:34:38 10/24/08 01:34:39 krbtgt/ASU.EDU > > @ASU.EDU > > renew until 10/30/08 15:30:56 > > > > but I'm not getting the afs@asu.edu credential.. ?? > > why? > > So, does this indicate the problem is with KfW instead of openafs? > > You have not received any service tickets. All you have is a TGT. > > Can you obtain service tickets for any service? > > kvno.exe > > You could also turn on logging in NIM and examine the log. > > My guess is that assuming you have the AFS credential acquisition > properly configured for NIM that the clock on the machine is not > set correctly. Wrong time or wrong time zone. > > I check the date/time.. It syncing with the domain controls which sync the the kerb servers. It all works. I did the following in a cmd shell: C:\Documents and Settings\bvossoug>klist Ticket cache: API:bvossoug@ASU.EDU Default principal: bvossoug@ASU.EDU Valid starting Expires Service principal 10/30/08 08:45:08 10/30/08 18:45:10 krbtgt/ASU.EDU@ASU.EDU renew until 11/06/08 08:44:55 C:\Documents and Settings\bvossoug>aklog pioctl temp != 0: 0x66543218 NOTE how AKLOG fails. Then, testing with kvno to get another service, works okay. C:\Documents and Settings\bvossoug>kvno host/ppp1.asu.edu@ASU.EDU host/ppp1.asu.edu@ASU.EDU: kvno = 4 NOW the thing thats weird is that AFTER i did the kvno, NIM suddenly updated itself and suddenly I had afs@ASU.EDU service tickets. So I check using the tokens command C:\Documents and Settings\bvossoug>tokens Tokens held by the Cache Manager: User bvossoug@ASU.EDU's tokens for afs@asu.edu [Expires Oct 30 18:45] pioctl temp != 0: 0x66543218 --End of list ---- So, tokens finally says that the user as an AFS token, but still returns the pioctrol error. This is getting curiouser and curiouser... -- David Bear College of Public Programs at ASU 602-464-0424 ------=_Part_16910_15078553.1225392195300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

This is getting stranger and stranger -- Jeff, I finally got the name of another service to test.. below is a screen shot of what happened.

On Thu, Oct 23, 2008 at 7:11 PM, Jeffrey Altman <jaltman@secure-endpoints.com> wrote:
David Bear wrote:
> KFW is version 3.2.2 -- resintalled today.
> Windows is XP Pro with SP2
> credential cache is API: -- we do make use of windows logon credentials.
> I've stopped using kinit and only use NIM to get and destroy tickets. I
> do succesfully get tickets in asu.edu <http://asu.edu>,  as the output
> of klist shows:
> Ticket cache: API:bvossoug@ASU.EDU <mailto:API%3Abvossoug@ASU.EDU>
> Default principal: bvossoug@ASU.EDU <mailto:bvossoug@ASU.EDU>
>
> Valid starting Expires Service principal
> 10/23/08 15:34:38 10/24/08 01:34:39 krbtgt/ASU.EDU
> <http://ASU.EDU>@ASU.EDU <http://ASU.EDU>
>  renew until 10/30/08 15:30:56
>
> but I'm not getting the afs@asu.edu <mailto:afs@asu.edu> credential.. ??
> why?
> So, does this indicate the problem is with KfW instead of openafs?

You have not received any service tickets.  All you have is a TGT.

Can you obtain service tickets for any service?

 kvno.exe <service-ticket-name>

You could also turn on logging in NIM and examine the log.

My guess is that assuming you have the AFS credential acquisition
properly configured for NIM that the clock on the machine is not
set correctly.  Wrong time or wrong time zone.

I check the date/time.. It syncing with the domain controls which sync the the kerb servers. It all works. 

I did the following in a cmd shell:


C:\Documents and Settings\bvossoug>klist

Ticket cache: API:bvossoug@ASU.EDU
Default principal: bvossoug@ASU.EDU
 Valid starting Expires Service principal

10/30/08 08:45:08 10/30/08 18:45:10 krbtgt/ASU.EDU@ASU.EDU

  renew until 11/06/08 08:44:55

C:\Documents and Settings\bvossoug>aklog
pioctl temp != 0: 0x66543218

NOTE how AKLOG fails.

Then, testing with kvno to get another service, works okay.

C:\Documents and Settings\bvossoug>kvno host/ppp1.asu.edu@ASU.EDU
host/ppp1.asu.edu@ASU.EDU: kvno = 4

NOW the thing thats weird is that AFTER i did the kvno, NIM suddenly updated itself and suddenly I had afs@ASU.EDU service tickets. So I check using the tokens command 

C:\Documents and Settings\bvossoug>tokens
Tokens held by the Cache Manager:

User bvossoug@ASU.EDU's tokens for afs@asu.edu [Expires Oct 30 18:45]

pioctl temp != 0: 0x66543218

  --End of list ----

So, tokens finally says that the user as an AFS token, but still returns the pioctrol error.

This is getting curiouser and curiouser...

--
David Bear

College of Public Programs at ASU
602-464-0424
------=_Part_16910_15078553.1225392195300-- From Jeffrey Altman" The pioctl error is not strange. Previously in this thread I indicated = that it means 'end of list'. Aklog reads the list of existing tokens. = There were none. Tokens reads the list of tokens. There was one. Jeffrey Altman -original message- Subject: Re: [OpenAFS] openafs pioctl issue on windows From: "David Bear" Date: 2008-10-30 11:43 This is getting stranger and stranger -- Jeff, I finally got the name = of another service to test.. below is a screen shot of what happened. On Thu, Oct 23, 2008 at 7:11 PM, Jeffrey Altman < jaltman@secure-endpoints.com> wrote: > David Bear wrote: > > KFW is version 3.2.2 -- resintalled today. > > Windows is XP Pro with SP2 > > credential cache is API: -- we do make use of windows logon = credentials. > > I've stopped using kinit and only use NIM to get and destroy tickets. = I > > do succesfully get tickets in asu.edu , as the = output > > of klist shows: > > Ticket cache: API:bvossoug@ASU.EDU = API%3Abvossoug@ASU.EDU > > > Default principal: bvossoug@ASU.EDU > > > > Valid starting Expires Service principal > > 10/23/08 15:34:38 10/24/08 01:34:39 krbtgt/ASU.EDU > > @ASU.EDU > > renew until 10/30/08 15:30:56 > > > > but I'm not getting the afs@asu.edu credential.. = ?? > > why? > > So, does this indicate the problem is with KfW instead of = openafs? > > You have not received any service tickets. All you have is a TGT. > > Can you obtain service tickets for any service? > > kvno.exe > > You could also turn on logging in NIM and examine the log. > > My guess is that assuming you have the AFS credential acquisition > properly configured for NIM that the clock on the machine is not > set correctly. Wrong time or wrong time zone. > > I check the date/time.. It syncing with the domain controls which sync = the the kerb servers. It all works. I did the following in a cmd shell: C:\Documents and Settings\bvossoug>klist Ticket cache: API:bvossoug@ASU.EDU Default principal: bvossoug@ASU.EDU Valid starting Expires Service principal 10/30/08 08:45:08 10/30/08 18:45:10 krbtgt/ASU.EDU@ASU.EDU renew until 11/06/08 08:44:55 C:\Documents and Settings\bvossoug>aklog pioctl temp !=3D 0: 0x66543218 NOTE how AKLOG fails. Then, testing with kvno to get another service, works okay. C:\Documents and Settings\bvossoug>kvno host/ppp1.asu.edu@ASU.EDU host/ppp1.asu.edu@ASU.EDU: kvno =3D 4 NOW the thing thats weird is that AFTER i did the kvno, NIM suddenly = updated itself and suddenly I had afs@ASU.EDU service tickets. So I check using = the tokens command C:\Documents and Settings\bvossoug>tokens Tokens held by the Cache Manager: User bvossoug@ASU.EDU's tokens for afs@asu.edu [Expires Oct 30 18:45] pioctl temp !=3D 0: 0x66543218 --End of list ---- So, tokens finally says that the user as an AFS token, but still returns = the pioctrol error. This is getting curiouser and curiouser... -- David Bear College of Public Programs at ASU 602-464-0424 From David.Bear@asu.edu Thu Oct 30 22:18:54 2008 From: David.Bear@asu.edu (David Bear) Date: Thu, 30 Oct 2008 14:18:54 -0700 Subject: [OpenAFS] openafs pioctl issue on windows In-Reply-To: References: Message-ID: <1d1a54bf0810301418n34da4f63u6246acdd57280331@mail.gmail.com> ------=_Part_19906_21928354.1225401534471 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thu, Oct 30, 2008 at 1:25 PM, Jeffrey Altman < jaltman@secure-endpoints.com> wrote: > The pioctl error is not strange. Previously in this thread I indicated > that it means 'end of list'. Aklog reads the list of existing tokens. > There were none. Tokens reads the list of tokens. There was one. > > What seems strange to me is that on 'normally functioning systems' (those with openafs and kfw that works as expected) I don't see the pioctl error. The other strange thing is why did I suddenly get a afs@asu.edu service ticket after performing the kvno on the other host principal? > Jeffrey Altman > > -original message- > Subject: Re: [OpenAFS] openafs pioctl issue on windows > From: "David Bear" > Date: 2008-10-30 11:43 > > This is getting stranger and stranger -- Jeff, I finally got the name of > another service to test.. below is a screen shot of what happened. > > On Thu, Oct 23, 2008 at 7:11 PM, Jeffrey Altman < > jaltman@secure-endpoints.com> wrote: > > > David Bear wrote: > > > KFW is version 3.2.2 -- resintalled today. > > > Windows is XP Pro with SP2 > > > credential cache is API: -- we do make use of windows logon > credentials. > > > I've stopped using kinit and only use NIM to get and destroy tickets. I > > > do succesfully get tickets in asu.edu , as the output > > > of klist shows: > > > Ticket cache: API:bvossoug@ASU.EDU < > API%3Abvossoug@ASU.EDU > > API%3Abvossoug@ASU.EDU < > API%253Abvossoug@ASU.EDU >> > > > Default principal: bvossoug@ASU.EDU > > > > > > Valid starting Expires Service principal > > > 10/23/08 15:34:38 10/24/08 01:34:39 krbtgt/ASU.EDU > > > @ASU.EDU > > > renew until 10/30/08 15:30:56 > > > > > > but I'm not getting the afs@asu.edu credential.. > ?? > > > why? > > > So, does this indicate the problem is with KfW instead of openafs? > > > > You have not received any service tickets. All you have is a TGT. > > > > Can you obtain service tickets for any service? > > > > kvno.exe > > > > You could also turn on logging in NIM and examine the log. > > > > My guess is that assuming you have the AFS credential acquisition > > properly configured for NIM that the clock on the machine is not > > set correctly. Wrong time or wrong time zone. > > > > I check the date/time.. It syncing with the domain controls which sync > the > the kerb servers. It all works. > > I did the following in a cmd shell: > > > C:\Documents and Settings\bvossoug>klist > > Ticket cache: API:bvossoug@ASU.EDU < > API%3Abvossoug@ASU.EDU > > Default principal: bvossoug@ASU.EDU > Valid starting Expires Service principal > > 10/30/08 08:45:08 10/30/08 18:45:10 krbtgt/ASU.EDU@ASU.EDU > > renew until 11/06/08 08:44:55 > > C:\Documents and Settings\bvossoug>aklog > pioctl temp != 0: 0x66543218 > > NOTE how AKLOG fails. > > Then, testing with kvno to get another service, works okay. > > C:\Documents and Settings\bvossoug>kvno host/ppp1.asu.edu@ASU.EDU > host/ppp1.asu.edu@ASU.EDU: kvno = 4 > > NOW the thing thats weird is that AFTER i did the kvno, NIM suddenly > updated > itself and suddenly I had afs@ASU.EDU service tickets. So I check using > the > tokens command > > C:\Documents and Settings\bvossoug>tokens > Tokens held by the Cache Manager: > > User bvossoug@ASU.EDU's tokens for afs@asu.edu [Expires Oct 30 18:45] > > pioctl temp != 0: 0x66543218 > > --End of list ---- > > So, tokens finally says that the user as an AFS token, but still returns > the > pioctrol error. > > This is getting curiouser and curiouser... > > -- > David Bear > College of Public Programs at ASU > 602-464-0424 > > > -- David Bear College of Public Programs at ASU 602-464-0424 ------=_Part_19906_21928354.1225401534471 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Thu, Oct 30, 2008 at 1:25 PM, Jeffrey Altman <jaltman@secure-endpoints.com> wrote:
The pioctl error is not strange.  Previously in this thread I indicated that it means 'end of list'.  Aklog reads the list of existing tokens.  There were none.  Tokens reads the list of tokens.  There was one.

What seems strange to me is that on 'normally functioning systems' (those with openafs and kfw that works as expected) I don't see the pioctl error. 
The other strange thing is why did I suddenly get a afs@asu.edu service ticket after performing the kvno on the other host principal?
 
Jeffrey Altman

-original message-
Subject: Re: [OpenAFS] openafs pioctl issue on windows
From: "David Bear" <David.Bear@asu.edu>
Date: 2008-10-30 11:43

This is getting stranger and stranger -- Jeff, I finally got the name of
another service to test.. below is a screen shot of what happened.

On Thu, Oct 23, 2008 at 7:11 PM, Jeffrey Altman <
jaltman@secure-endpoints.com> wrote:

> David Bear wrote:
> > KFW is version 3.2.2 -- resintalled today.
> > Windows is XP Pro with SP2
> > credential cache is API: -- we do make use of windows logon credentials.
> > I've stopped using kinit and only use NIM to get and destroy tickets. I
> > do succesfully get tickets in asu.edu <http://asu.edu>,  as the output
> > of klist shows:
> > Ticket cache: API:bvossoug@ASU.EDU <API%3Abvossoug@ASU.EDU> <mailto:
> API%3Abvossoug@ASU.EDU <API%253Abvossoug@ASU.EDU>>
> > Default principal: bvossoug@ASU.EDU <mailto:bvossoug@ASU.EDU>
> >
> > Valid starting Expires Service principal
> > 10/23/08 15:34:38 10/24/08 01:34:39 krbtgt/ASU.EDU
> > <http://ASU.EDU>@ASU.EDU <http://ASU.EDU>
> >  renew until 10/30/08 15:30:56
> >
> > but I'm not getting the afs@asu.edu <mailto:afs@asu.edu> credential.. ??
> > why?
> > So, does this indicate the problem is with KfW instead of openafs?
>
> You have not received any service tickets.  All you have is a TGT.
>
> Can you obtain service tickets for any service?
>
>  kvno.exe <service-ticket-name>
>
> You could also turn on logging in NIM and examine the log.
>
> My guess is that assuming you have the AFS credential acquisition
> properly configured for NIM that the clock on the machine is not
> set correctly.  Wrong time or wrong time zone.
>
> I check the date/time.. It syncing with the domain controls which sync the
the kerb servers. It all works.

I did the following in a cmd shell:


C:\Documents and Settings\bvossoug>klist

Ticket cache: API:bvossoug@ASU.EDU <API%3Abvossoug@ASU.EDU>
Default principal: bvossoug@ASU.EDU
 Valid starting Expires Service principal

10/30/08 08:45:08 10/30/08 18:45:10 krbtgt/ASU.EDU@ASU.EDU

 renew until 11/06/08 08:44:55

C:\Documents and Settings\bvossoug>aklog
pioctl temp != 0: 0x66543218

NOTE how AKLOG fails.

Then, testing with kvno to get another service, works okay.

C:\Documents and Settings\bvossoug>kvno host/ppp1.asu.edu@ASU.EDU
host/ppp1.asu.edu@ASU.EDU: kvno = 4

NOW the thing thats weird is that AFTER i did the kvno, NIM suddenly updated
itself and suddenly I had afs@ASU.EDU service tickets. So I check using the
tokens command

C:\Documents and Settings\bvossoug>tokens
Tokens held by the Cache Manager:

User bvossoug@ASU.EDU's tokens for afs@asu.edu [Expires Oct 30 18:45]

pioctl temp != 0: 0x66543218

 --End of list ----

So, tokens finally says that the user as an AFS token, but still returns the
pioctrol error.

This is getting curiouser and curiouser...

--
David Bear
College of Public Programs at ASU
602-464-0424





--
David Bear
College of Public Programs at ASU
602-464-0424
------=_Part_19906_21928354.1225401534471-- From jaltman@secure-endpoints.com Thu Oct 30 23:17:15 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 30 Oct 2008 15:17:15 -0700 Subject: [OpenAFS] Integrated logon and locking/unlocking workstatations In-Reply-To: <4909F4D3.1000609@law.berkeley.edu> References: <4907862A.6010106@law.berkeley.edu> <4909CE67.3070806@anl.gov> <4909EF65.10405@law.berkeley.edu> <4909F3C2.9040303@secure-endpoints.com> <4909F4D3.1000609@law.berkeley.edu> Message-ID: <490A326B.2080702@secure-endpoints.com> Ryan L. Means wrote: > Jeffrey Altman wrote: >> Ryan L. Means wrote: >> >>> Yes, it does allow renewable tickets for up to 7 days. But, it doesn't >>> seem like netmgr is renewing them when the workstation is locked. That >>> would help the problem because then users who never log out would only >>> be prompted every 7 days... >> >> NetIDMgr doesn't know that the machine is locked. >> It renews the tickets for as long as the KDC will do so. > > No, I understand. What I'm saying is that I believe that while the > workstation is locked, NetIDMgr is not continuing to renew the tickets > in the background. But, that doesn't make any sense since it's a service > and doesn't require an interactive session with the desktop. I'll > explore more thoroughly. Turn on the logging from the NetIDMgr General page. It will log everything it does. From jaltman@secure-endpoints.com Thu Oct 30 23:18:58 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 30 Oct 2008 15:18:58 -0700 Subject: [OpenAFS] openafs pioctl issue on windows In-Reply-To: <1d1a54bf0810301418n34da4f63u6246acdd57280331@mail.gmail.com> References: <1d1a54bf0810301418n34da4f63u6246acdd57280331@mail.gmail.com> Message-ID: <490A32D2.5020601@secure-endpoints.com> David Bear wrote: > > > On Thu, Oct 30, 2008 at 1:25 PM, Jeffrey Altman > > wrote: > > The pioctl error is not strange. Previously in this thread I > indicated that it means 'end of list'. Aklog reads the list of > existing tokens. There were none. Tokens reads the list of tokens. > There was one. > > What seems strange to me is that on 'normally functioning systems' > (those with openafs and kfw that works as expected) I don't see the > pioctl error. You are seeing the pioctl error message because you have turned on the pioctl debugging interface via the registry. You would see it on any system on which you have turned it on. > The other strange thing is why did I suddenly get a afs@asu.edu > service ticket after performing the kvno on the > other host principal? You didn't. aklog obtained. Jeffrey Altman From jason@rampaginggeek.com Fri Oct 31 00:15:19 2008 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Thu, 30 Oct 2008 19:15:19 -0400 Subject: [OpenAFS] Re: Windows apache htdocs in AFS space? In-Reply-To: <4909C400.6060608@cgv.tugraz.at> References: <4909C3DC.8000003@cgv.tugraz.at> <4909C400.6060608@cgv.tugraz.at> Message-ID: <490A4007.7020303@rampaginggeek.com> Lars Schimmer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Lars Schimmer wrote: > >> Hi! >> >> On one of our projects we need a apache server on a windows client. >> We thought about putting the htdocs into AFS space and created a IP >> entry for the user into the PTS database and a special directory for the >> data of the htdoc with the IP in the ACL. >> (server is jsut internal reachable with no security riscy data). >> >> The problem now: start windows pc, start apache - apache dies >> Sart windows PC, access the directory in the AFS space with explorer, >> start apache -works. >> >> Any idea why access the directory with explorer let the apache not to >> crah, or better: why does apache crash if AFS was not "touched" by >> explorer before? >> > > Missed: Win XP SP3, OpenAFS 1.5.54 > I have noticed similar behaviour. I'm running WinXP SP3 and openafs 1.5.54. I will authenticate and have tokens, but I have to access my AFS mapped drives in explorer before I can see them on the command line. Jason From jaltman@secure-endpoints.com Fri Oct 31 11:41:28 2008 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Fri, 31 Oct 2008 03:41:28 -0700 Subject: [OpenAFS] Windows apache htdocs in AFS space? In-Reply-To: <4909C3DC.8000003@cgv.tugraz.at> References: <4909C3DC.8000003@cgv.tugraz.at> Message-ID: <490AE0D8.6070709@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms060506030801070009020501 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lars Schimmer wrote: > Hi! > > On one of our projects we need a apache server on a windows client. > We thought about putting the htdocs into AFS space and created a IP > entry for the user into the PTS database and a special directory for the > data of the htdoc with the IP in the ACL. > (server is jsut internal reachable with no security riscy data). > > The problem now: start windows pc, start apache - apache dies > Sart windows PC, access the directory in the AFS space with explorer, > start apache -works. > > Any idea why access the directory with explorer let the apache not to > crah, or better: why does apache crash if AFS was not "touched" by > explorer before? > > MfG, > Lars Schimmer Apache is an open source project. Perhaps by debugging Apache and figuring why it is crashing you can determine what is making it unhappy. Is Apache starting before afsd_service.exe? If so, you might want to put a dependency in the apache service configuration so that it won't start until after the "TransarcAFSDaemon" service has started. Is Apache accessing AFS via a drive letter mapping or via a UNC path? Jeffrey Altman --------------ms060506030801070009020501 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEDsE+kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoX DTA5MDUzMDE5MTUyOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCtf5bVJdYFtHIrV2XALpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qI zPrPadePhJ3OWwNt1ZlUlpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL6 6bj8uoCSX0D7ZjZiAS8993NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXe N6QjJdvaK0846lDqeBFoCEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK 3RWcMy8DV7Q5Z+jSEdPn5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs /Fqn4XkT70SG4s8v4Zg6TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1 vgwJ5TfZYlKvt4D0Z4zexu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAxcwggKAoAMCAQICEDsE +kRcmomW1hYG6BoqhGEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDUzMDE5MTUyOVoXDTA5MDUzMDE5MTUyOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtf5bVJdYFtHIrV2XA LpA5oaMu7FPYU7RP7vJhd8Cu9Kd9ud2crX2pHK4avuPaYb4Vg9qIzPrPadePhJ3OWwNt1ZlU lpc5URnOfpg/I9iymZBUSnCFVLuIvoncacqyUlzqdYEF8XGEoEL66bj8uoCSX0D7ZjZiAS89 93NvgiPYpf10acMyWQ4max+P7Wg9T03Nw2F6EsmP6gWxBRsekTXeN6QjJdvaK0846lDqeBFo CEzIUMQXj2kiXVPCPEdxPc/L1sDMYf0GLaDIg8qyThpGd0X6DwfK3RWcMy8DV7Q5Z+jSEdPn 5X0l4anOTrjr3IwE57MC3bVs0EEpUODTzftnAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQA9kndmeLrdQOUbhNGGms/FnfDyraH4OjA4PIIMOCbGWK0YXczs/Fqn4XkT70SG4s8v4Zg6 TaAcJrZBVcZQXyzrhlF2Zev/g69zZMHQe+2r4i/3FBVKAtFCoea1vgwJ5TfZYlKvt4D0Z4ze xu9Y0VwCIR4plWjVD76zC2CGB/2fhjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ OwT6RFyaiZbWFgboGiqEYTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMzExMDQxMjhaMCMGCSqGSIb3DQEJBDEWBBSnUnj/ 6R+38EH93NyiEW8cU5KIMDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEDsE+kRcmomW1hYG6BoqhGEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDsE+kRcmomW1hYG6BoqhGEwDQYJ KoZIhvcNAQEBBQAEggEAhFLHwoziq/NkGT7I/LbadC00uZhW9txGWYYYVPuEkeB+w0X5m7LD ypQnY1+ih4gy47mlttRNWktcqQ1VPDAg5IxMub3w84YpF2lGYuA3xXpGYbzJC66BZ5hYKzkL siudEnTBFH4Mhd7CThk5l+7ET2Eni+PwkIhOw04Z52ZVeXGZ2fiLUNTEB95RiSLSJbo7UKNb 3T4m/cWyCeeT6AziFV3pHIqAvF5Z9ayGxkKGlaCyXK28nsP5ykobsGMAqVfGTcCk0n54gISd 7HGm+iopLaS8/x4PzA0R9GSvLQSDIqrZaWuDV5oJZNRSwK2+EDVU27dH6PqW7rgl1hMTTdbw VQAAAAAAAA== --------------ms060506030801070009020501-- From jason@rampaginggeek.com Fri Oct 31 14:57:05 2008 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Fri, 31 Oct 2008 09:57:05 -0400 Subject: [OpenAFS] Adding -fPIC to openafs rpms builds? Message-ID: <490B0EB1.4090801@rampaginggeek.com> Hi all, We have been wrestling with mod_waklog on at work, and now it complains that the openafs libraries weren't compiled with the -fPIC compiler option. Since we're using the openafs rhel5 x86_64 rpms from openafs.org, I was wondering about adding -fPIC to the rpms builds. Is -fPIC enabled in the openafs.org rpms? Should it be added to the openafs.org rpms? Thanks, Jason From shadow@gmail.com Fri Oct 31 15:59:44 2008 From: shadow@gmail.com (Derrick Brashear) Date: Fri, 31 Oct 2008 10:59:44 -0400 Subject: [OpenAFS] Adding -fPIC to openafs rpms builds? In-Reply-To: <490B0EB1.4090801@rampaginggeek.com> References: <490B0EB1.4090801@rampaginggeek.com> Message-ID: This came up on the waklog devel list. Why the (shared, and thus PIC) libraries are not being linked I can't say. waklog should *only* be making the AFS syscall. You don't even need all the libraries. It should either 1) link *shared* libafsrpc or 2) provide its own syscall stub (license-reusable one in heimdal) or 3) try to link libkafs/libkopenafs Changing all the RPMs because waklog's build system is wrong? Bad idea. -- Derrick From jason@rampaginggeek.com Fri Oct 31 18:23:50 2008 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Fri, 31 Oct 2008 13:23:50 -0400 Subject: [OpenAFS] openafs foundation & cross-project integration (was Re: [OpenAFS] Adding -fPIC to openafs rpms builds?) In-Reply-To: References: <490B0EB1.4090801@rampaginggeek.com> Message-ID: <490B3F26.1040500@rampaginggeek.com> Derrick Brashear wrote: > This came up on the waklog devel list. Why the (shared, and thus PIC) > libraries are not being linked I can't say. waklog should *only* be > making the AFS syscall. You don't even need all the libraries. It > should either > 1) link *shared* libafsrpc > or > 2) provide its own syscall stub (license-reusable one in heimdal) > or > 3) try to link libkafs/libkopenafs > > Changing all the RPMs because waklog's build system is wrong? Bad idea. > > Is one of the goals of the new foundation to help with integration between related projects? If not, can that be added? I'm not assigning blame. Integration issues with projects like mod_waklog need to be addressed if we want openafs to succeed. Sincerely, Jason From shadow@gmail.com Fri Oct 31 18:32:54 2008 From: shadow@gmail.com (Derrick Brashear) Date: Fri, 31 Oct 2008 13:32:54 -0400 Subject: openafs foundation & cross-project integration (was Re: [OpenAFS] Adding -fPIC to openafs rpms builds?) In-Reply-To: <490B3F26.1040500@rampaginggeek.com> References: <490B0EB1.4090801@rampaginggeek.com> <490B3F26.1040500@rampaginggeek.com> Message-ID: On Fri, Oct 31, 2008 at 1:23 PM, Jason Edgecombe wrote: > Derrick Brashear wrote: >> This came up on the waklog devel list. Why the (shared, and thus PIC) >> libraries are not being linked I can't say. waklog should *only* be >> making the AFS syscall. You don't even need all the libraries. It >> should either >> 1) link *shared* libafsrpc >> or >> 2) provide its own syscall stub (license-reusable one in heimdal) >> or >> 3) try to link libkafs/libkopenafs >> >> Changing all the RPMs because waklog's build system is wrong? Bad idea. >> >> > > Is one of the goals of the new foundation to help with integration > between related projects? Absolutely. > If not, can that be added? I'm not assigning > blame. Integration issues with projects like mod_waklog need to be > addressed if we want openafs to succeed. Agreed. In particular, we need to provide documentation explaining how OpenAFS should be used to do various things, by things which will link our libraries to do so. This is one of those. -- Derrick