[OpenAFS] OpenAFS Release 1.8.10 available

[Stephan Wiesand]

The OpenAFS Release Team is pleased to announce the availability of OpenAFS
version 1.8.10 for UNIX/Linux. Source files can be accessed via the web at

  http://www.openafs.org/release/1.8.10/

or via AFS at:

  UNIX: /afs/grand.central.org/software/openafs/1.8.10/
  UNC: \\afs\grand.central.org\software\openafs\1.8.10\

OpenAFS 1.8.10 is the next release in the current stable series of OpenAFS
releases for UNIX/Linux systems. It brings performance and reliablity 
improvements,
improved diagnostics, support for the latest Linux mainline kernel (currently 
6.4),
Apple Silicon and macOS releases up to 13 ("Ventura"), much improved support for
the AIX platform, including releases 7.1, 7.2 and 7.3, as well as a number of 
bug
fixes and minor new features.

For the full list of user visible changes in this release, please see

  http://dl.openafs.org/dl/1.8.10/RELNOTES-1.8.10

Bug reports should be filed to openafs-b...@openafs.org.

Stephan Wiesand, OpenAFS Release Manager
on behalf of the OpenAFS Release Team

-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany





-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany



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

[OpenAFS] OpenAFS 1.8.10 beta1 available

[Stephan Wiesand]

The OpenAFS Release Team is pleased to announce that the prerelease
1.8.10pre1 is now available.

Source files and available binaries can be accessed via the web at:

  http://dl.openafs.org/dl/candidate/1.8.10pre1/

or via AFS at:

  UNIX: /afs/grand.central.org/software/openafs/candidate/1.8.10pre1/
  UNC: \\afs\grand.central.org\software\openafs\candidate\1.8.10pre1\

This prerelease brings performance and reliablity improvements,
improved diagnostics, support for the latest Linux mainline kernel
(currently 6.3 and likely 6.4), Apple Silicon and macOS releases
up to 13 ("Ventura"), much improved support for the AIX platform,
including releases 7.1, 7.2 and 7.3, as well as a number of bug
fixes and minor new features.

For the full list of user visible changes foreseen for 1.8.10, please see

  http://dl.openafs.org/dl/candidate/1.8.10pre1/RELNOTES-1.8.10pre1


Please assist us by deploying this prerelease and providing positive or
negative feedback. Bug reports should be filed to openafs-b...@openafs.org.
Reports of success should be sent to openafs-info@openafs.org.

Stephan Wiesand, OpenAFS Release Manager
on behalf of the OpenAFS Release Team




-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany



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

Re: [OpenAFS] 2023 AFS Technologies Workshop - virtual

[Stephan Wiesand]

Hi Tracy,

I'm a bit baffled by the "list of countries and regions" from where one can 
register for this event. To name a few, the workshop seems not to be accessible 
from Iceland, Norway, Finland, Denmark, Slovakia, Hungary, almost all of Africa 
(including South Africa) and Asia (including Taiwan, India,...) etc.

Frankly, I think this is a violation of our code of conduct. While I have 
registered, I'm seriously considering not to participate.

But I still hope this is a misunderstanding.


Best regards,
Stephan

> On 9. Jun 2023, at 16:22, Di Marco White, Tracy J  
> wrote:
> 
> Once you've registered for the conference, please join the Zoom Events Lobby 
> and look through the talks available. Within the lobby, you are able to 
> bookmark talks, and those bookmarked talks are used to build your itinerary 
> for the conference. Please explore Zoom Events in advance if you can.
> 
> Zoom has made available a video (https://youtu.be/LJr-DE4ktb4) walking 
> through these steps.
> 
> Thanks,
> Tracy 
> 
> -Original Message-
> From: Di Marco White, Tracy J [Engineering]
> Sent: Wednesday, June 7, 2023 1:23 PM
> To: OpenAFS Info 
> Subject: 2023 AFS Technologies Workshop - virtual
> 
> Hi all,
> 
> I'd like to invite anyone interested in AFS to register for the 2023 AFS 
> Technologies Workshop taking place next week on June 12th, 13th, & 14th. The 
> workshop is again this year being hosted on Zoom, and registration is open at 
> https://workshop.openafs.org with the talks and timings listed. The main 
> talks will run from 9:30am until 3pm Eastern time, with themed community 
> discussion or social time for an hour before the start each day, and an hour 
> after the talks end each day.
> 
> If you have any issues with registration, please mail to 
> openafs.works...@gmail.com to let us help.
> 
> If you are a student at a higher education institution, please contact 
> openafs.works...@gmail.com to take advantage of our offer of comped 
> registration.
> 
> Please feel free to forward to anyone who you feel is interested in the 
> conference
> 
> If you have any questions, please let us know at openafs.works...@gmail.com.
> 
> Tracy Di Marco White
> On behalf of the 2023 Workshop organizers
> 
> 
> 
> Your Personal Data: We may collect and process information about you that may 
> be subject to data protection laws. For more information about how we use and 
> disclose your personal data, how we protect your information, our legal basis 
> to use your information, your rights and who you can contact, please refer 
> to: www.gs.com/privacy-notices<http://www.gs.com/privacy-notices>
> ___
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info

-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany



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

[OpenAFS] OpenAFS Release 1.8.9 available

[Stephan Wiesand]

The OpenAFS Release Team is pleased to announce the availability of OpenAFS
version 1.8.9 for UNIX/Linux. Source files can be accessed via the web at

  http://www.openafs.org/release/1.8.9/

or via AFS at:

  UNIX: /afs/grand.central.org/software/openafs/1.8.9/
  UNC: \\afs\grand.central.org\software\openafs\1.8.9\

OpenAFS 1.8.9 is the next release in the current stable series of OpenAFS
releases for UNIX/Linux systems. It brings performance and reliability
improvements, improved diagnostics, support for the latest Linux mainline
kernel (currently 6.0) and recent FreeBSD releases as well as a number of
bug fixes.

For the full list of user visible changes in this release, please see

  http://dl.openafs.org/dl/1.8.9/RELNOTES-1.8.9

Bug reports should be filed to openafs-b...@openafs.org.

Stephan Wiesand, OpenAFS Release Manager
on behalf of the OpenAFS Release Team


-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany



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

[OpenAFS] OpenAFS 1.8.9 beta2 available

[Stephan Wiesand]

The OpenAFS Release Team is pleased to announce that the prerelease
1.8.9pre2 is now available.

Source files and available binaries can be accessed via the web at:

  http://dl.openafs.org/dl/candidate/1.8.9pre2/

or via AFS at:

  UNIX: /afs/grand.central.org/software/openafs/candidate/1.8.9pre2/
  UNC: \\afs\grand.central.org\software\openafs\candidate\1.8.9pre2\

This prerelease brings brings performance and reliablity improvements, improved
diagnostics, support for the latest Linux mainline kernel (currently 6.0)
and recent FreeBSD releases as well as a number of bug fixes.

For the full list of user visible changes foreseen for 1.8.9, please see

  http://dl.openafs.org/dl/candidate/1.8.9pre2/RELNOTES-1.8.9pre2


Please assist us by deploying this prerelease and providing positive or
negative feedback. Bug reports should be filed to openafs-b...@openafs.org.
Reports of success should be sent to openafs-info@openafs.org.

Stephan Wiesand, OpenAFS Release Manager
on behalf of the OpenAFS Release Team




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

[OpenAFS] OpenAFS Release 1.8.8 available

[Stephan Wiesand]

The OpenAFS Release Team is pleased to announce the availability of OpenAFS
version 1.8.8 for UNIX/Linux. Source files can be accessed via the web at

  http://www.openafs.org/release/1.8.8/

or via AFS at

  UNIX: /afs/grand.central.org/software/openafs/1.8.8/
  UNC: \\afs\grand.central.org\software\openafs\1.8.8\

This release brings performance and reliability improvements, improved
diagnostics, support for the latest Linux mainline kernel (currently 5.13)
and macOS 11.0 "Big Sur" as well as support for recent FreeBSD releases
and a number of bug fixes.

For the full list of user visible changes foreseen for 1.8.8, please see

  http://dl.openafs.org/dl/candidate/1.8.8/RELNOTES-1.8.8


Bug reports should be filed to openafs-b...@openafs.org.


Stephan Wiesand, OpenAFS Release Manager
on behalf of the OpenAFS Release Team
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] 1.8.x afs_inode_cache more slab usage

[Stephan Wiesand]

Hello,

> On 3. Sep 2020, at 15:53, Chad William Seys  wrote:
> 
> Hello all,
>  It seems that OpenAFS 1.8.x uses more slab (or doesn't free it as quickly) 
> than 1.6.20 .
> 
>  The machine in question uses AFS heavily. it is used to backup our AFS area. 
> It scans through files constantly and in more than directory and in two 
> domains at a time.
>  I recently upgraded from Debian Stretch running openafs 1.6.20 to Debian 
> Buster 1.8.2.  After encountering the problem I also tried Debian Bullseye 
> (testing) with openafs 1.8.6.  Same symptoms.
>  On a 6GB (virtual) machine it used enough to start swapping and kill the 
> machine.

while that's not supposed to happen, I'm wondering whether running afsd with 
'-disable-dynamic-vcaches' would help?

- Stephan

>  The last output of 'slabtop' says:
> OBJS ACTIVE USE OBJSIZE SLABS OBJ/SLAB CACHE SIZE NAME
> 5235885 5235885 100% 1.06K 539811 15 8636976K afs_inode_cache
> 
>  Any way to change this behavior?
> 
> Thanks!
> Cahd.

-- 
Stephan Wiesand
DESY -DV-
Platanenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] AFS client hanged

[Stephan Wiesand]

Hi Andreas,

> On 18. Dec 2019, at 10:48, Andreas Ladanyi  wrote:
> 
> Hi,
> 
>>> kernel-2.6.32-696.20.1.el6.x86_64. After we upgrade to the new linux kernel 
>>> and install the default openafs client version using yum(the version we 
>>> used listed in the following), we have the hang issue. That's why I suspect 
>>> the version compatibility.
>>> AFS clinet--sl7 : l.6.23
>>> [root@bws0825 ~]# rpm -qa|grep openafs
>>> openafs-1.6-sl-client-1.6.23-289.sl7.x86_64
>>> openafs-1.6-sl-authlibs-1.6.23-289.sl7.x86_64
>>> openafs-1.6-sl-devel-1.6.23-289.sl7.x86_64
>>> openafs-1.6-sl-module-tools-1.6.23-289.sl7.x86_64
>>> openafs-1.6-sl-krb5-1.6.23-289.sl7.x86_64
>>> openafs-1.6-sl-1.6.23-289.sl7.x86_64
>>> openafs-1.6-sl-authlibs-devel-1.6.23-289.sl7.x86_64
>>> kmod-openafs-1.6-sl-957-1.6.23-289.sl7.957.x86_64
>>> 
>>> AFS client-SL6: 1.6.23
>>> openafs-krb5-1.6.23-289.sl6.x86_64
>>> openafs-client-1.6.23-289.sl6.x86_64
>>> openafs-1.6.23-289.sl6.x86_64
>>> openafs-kpasswd-1.6.23-289.sl6.x86_64
>>> openafs-module-tools-1.6.23-289.sl6.x86_64
>>> openafs-kernel-source-1.6.23-289.sl6.x86_64
>>> openafs-firstboot-1.6-1.sl6.noarch
>>> openafs-authlibs-1.6.23-289.sl6.x86_64
>>> kmod-openafs-1.6.22.3-1.SL610.el6.noarch
>>> openafs-compat-1.6.23-289.sl6.x86_64
>>> 
> What i could see here is a version difference between kmod-openafs 1.6.22 and 
> openafs-client 1.6.23

While 1.6.23 was a security update and yes, this looks kind of manual, it 
shouldn't matter.

> Does the issue appear on one client only or all clients which are upgraded ?

We run these packages on a lot of SL6 and SL7 systems, and the issue reported 
here at least isn't common. We seem to have a project with a usage pattern able 
to provoke hangs though. That has yet to be investigated. It was about 
something like using zsh tab completion in a git repo...


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

Re: [OpenAFS] rxperf

[Stephan Wiesand]

Hi,

> On 7. Mar 2019, at 09:03, Andreas Ladanyi  wrote:
> 
> Hi,
> 
> i want to test rx performance with rxperf. Where can i get rxperf ?

it happens to be packaged in SL's plumbing-tools rpm. I think the executable 
should work on most other current distros too. This is on Ubuntu 18.04:

/tmp % wget -q -O - 
http://ftp.scientificlinux.org/linux/scientific/7.6/x86_64/os/Packages/openafs-1.6-sl-plumbing-tools-1.6.23-289.sl7.x86_64.rpm
 | rpm2cpio | cpio -id
12502 blocks
/tmp % ./usr/afs/debug/rxperf
usage: /rxperf client -c send -b 
usage: /rxperf client -c recv -b 
usage: /rxperf client -c rpc  -S  -R 
usage: /rxperf client -c file -f filename
/rxperf: usage: common option to the client -w  -r  -T 
times -p port -s server -D
usage: /rxperf server -p port

There's no 1.8.x package yet though.

But you'll also find it in src/tools/rxperf after "./configure 
--disable-kernel-module; make".

Maybe we should add it in our redhat packaging.

Regards,
    Stephan

-- 
Stephan Wiesand
DESY -DV-
Platanenallee 6
15738 Zeuthen, Germany



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

Re: [OpenAFS] accessing /afs processes go into device wait

[Stephan Wiesand]

My guess is that attempting to retrieve SRV and then AFSDB DNS
records for an "htaccess" top level domain is very slow to fail
on the problematic system for some reason.

I think it's kind of a known issue which has crept up in the past
for things like ".trash" as well.

You could probably find out where things get stuck by comparing
tcpdump outputs.

- Stephan

> On 08 Nov 2018, at 20:41, John Sopko  wrote:
> 
> Wow! Removing -afsdb and adding our db servers in the CellServDB seems
> to have fixed the problem. Does not make any sense, this machine and
> others running many years with -afsdb. And fs listcells works when
> -afsdb is used:
> 
> % fs listcells
> Cell dynroot on hosts.
> Cell cs.unc.edu on hosts toucan.cs.unc.edu quail.cs.unc.edu kiwi.cs.unc.edu.
> 
> % host -t AFSDB cs.unc.edu
> cs.unc.edu has AFSDB record 1 kiwi.cs.unc.edu.
> cs.unc.edu has AFSDB record 1 quail.cs.unc.edu.
> cs.unc.edu has AFSDB record 1 toucan.cs.unc.edu.
> 
> Thanks for the help. Is this a known issue?
> 
> 
> On Thu, Nov 8, 2018 at 1:59 PM Stephan Wiesand  
> wrote:
>> 
>> Have you tried w/o -afsdb?
>> 
>>> On 08 Nov 2018, at 19:48, John Sopko  wrote:
>>> 
>>> nsswitch and DNS the same, the AFSDB records resolve fine, the
>>> /afs/cs.unc.edu cell works fine, just not /afs.
>>> 
>>> 
>>> On Thu, Nov 8, 2018 at 12:52 PM Stephan Wiesand  
>>> wrote:
>>>> 
>>>> 
>>>>> On 8. Nov 2018, at 18:22, John Sopko  wrote:
>>>>> 
>>>>> I have been running two legacy Redhat 6.x web servers for several
>>>>> years. The apache httpd processes started to go into device wait state
>>>>> the last few days on one of the servers, the other server is fine,
>>>>> both are configured pretty much the same. I tracked this down to the
>>>>> web server trying to stat /afs/.htaccess. If I try to do an ls in /afs
>>>>> or cat /afs/.htaccess which does not exist, the commands take a long
>>>>> time to complete and first go into device wait state, it can take
>>>>> several minutes or they may hang indefinitely. The afs file system
>>>>> seems to be working fine, just accessing under /afs is the problem. On
>>>>> other Redhat 6.x systems accessing /afs is fast and have no problems.
>>>> 
>>>> Are the nsswitch and DNS resolver configurations the same on all systems?
>>>> Any differences in network restrictions?
>>>> Does it help to run afsd without -afsdb?
>>>> 
>>>> Just a wild guess,
>>>>   Stephan
>>>> 
>>>>> 
>>>>> I am running afsd with:
>>>>> 
>>>>> /usr/vice/etc/afsd -dynroot -fakestat-all -afsdb
>>>>> 
>>>>> Note I tried fakestat-all to see if that would help, I have been
>>>>> running just -fakesat, our db servers have afsdb records.
>>>>> 
>>>>> I removed all cells accept for our cell in CellServDB so only have this:
>>>>> 
>>>>> % pwd
>>>>> /afs
>>>>> 
>>>>> % ls -l
>>>>> total 4
>>>>> lrwxr-xr-x 1 root root   10 Dec 31  1969 cs -> cs.unc.edu/
>>>>> drwxr-xr-x 8 root root 2048 Mar  6  2015 cs.unc.edu/
>>>>> lrwxr-xr-x 1 root root   10 Dec 31  1969 unc -> cs.unc.edu/
>>>>> 
>>>>> I re-formatted the /usr/vice/cache partition and that did not help.
>>>>> 
>>>>> I cannot find any hardware problems, no clues in the syslog or on the
>>>>> console, the system disk including the cache is on a raid1/mirror
>>>>> disk. This is a Dell server and I run Dell OpenMange which is really
>>>>> good at reporting system and especially disk errors.
>>>>> 
>>>>> I am running the same afsd verison on our remaining rhel 6.x servers:
>>>>> 
>>>>> % fs version
>>>>> openafs 1.6.22.2
>>>>> 
>>>>> Distributor ID: RedHatEnterpriseWorkstation
>>>>> Release:6.10
>>>>> 
>>>>> The problem is intermittent but goes into device wait most of the
>>>>> time, for example the first time ran fine, the second time it took
>>>>> 14.96 seconds.
>>>>> 
>>>>> % time ls -l
>>>>> total 4
>>>>> lrwxr-xr-x 1 root root   10 Dec 31  1969 cs -> cs.unc.edu
>>>>> drwxr-xr-x 8 root root 2048 Mar  6  2015 cs.unc.edu
>>>>> lrwxr-xr-x 1 root root   10 Dec 31  1969 unc -> cs.unc.edu
>>>>> 0.000u 0.000s 0:00.00 0.0%  0+0k 0+0io 0pf+0w
>>>>> 
>>>>> % time ls -l
>>>>> total 4
>>>>> lrwxr-xr-x 1 root root   10 Dec 31  1969 cs -> cs.unc.edu
>>>>> drwxr-xr-x 8 root root 2048 Mar  6  2015 cs.unc.edu
>>>>> lrwxr-xr-x 1 root root   10 Dec 31  1969 unc -> cs.unc.edu
>>>>> 0.000u 0.000s 0:14.96 0.0%  0+0k 0+0io 0pf+0w
>>>>> 
>>>>> Thanks for any help or ideas to try.

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

Re: [OpenAFS] accessing /afs processes go into device wait

[Stephan Wiesand]

Have you tried w/o -afsdb?

> On 08 Nov 2018, at 19:48, John Sopko  wrote:
> 
> nsswitch and DNS the same, the AFSDB records resolve fine, the
> /afs/cs.unc.edu cell works fine, just not /afs.
> 
> 
> On Thu, Nov 8, 2018 at 12:52 PM Stephan Wiesand  
> wrote:
>> 
>> 
>>> On 8. Nov 2018, at 18:22, John Sopko  wrote:
>>> 
>>> I have been running two legacy Redhat 6.x web servers for several
>>> years. The apache httpd processes started to go into device wait state
>>> the last few days on one of the servers, the other server is fine,
>>> both are configured pretty much the same. I tracked this down to the
>>> web server trying to stat /afs/.htaccess. If I try to do an ls in /afs
>>> or cat /afs/.htaccess which does not exist, the commands take a long
>>> time to complete and first go into device wait state, it can take
>>> several minutes or they may hang indefinitely. The afs file system
>>> seems to be working fine, just accessing under /afs is the problem. On
>>> other Redhat 6.x systems accessing /afs is fast and have no problems.
>> 
>> Are the nsswitch and DNS resolver configurations the same on all systems?
>> Any differences in network restrictions?
>> Does it help to run afsd without -afsdb?
>> 
>> Just a wild guess,
>>Stephan
>> 
>>> 
>>> I am running afsd with:
>>> 
>>> /usr/vice/etc/afsd -dynroot -fakestat-all -afsdb
>>> 
>>> Note I tried fakestat-all to see if that would help, I have been
>>> running just -fakesat, our db servers have afsdb records.
>>> 
>>> I removed all cells accept for our cell in CellServDB so only have this:
>>> 
>>> % pwd
>>> /afs
>>> 
>>> % ls -l
>>> total 4
>>> lrwxr-xr-x 1 root root   10 Dec 31  1969 cs -> cs.unc.edu/
>>> drwxr-xr-x 8 root root 2048 Mar  6  2015 cs.unc.edu/
>>> lrwxr-xr-x 1 root root   10 Dec 31  1969 unc -> cs.unc.edu/
>>> 
>>> I re-formatted the /usr/vice/cache partition and that did not help.
>>> 
>>> I cannot find any hardware problems, no clues in the syslog or on the
>>> console, the system disk including the cache is on a raid1/mirror
>>> disk. This is a Dell server and I run Dell OpenMange which is really
>>> good at reporting system and especially disk errors.
>>> 
>>> I am running the same afsd verison on our remaining rhel 6.x servers:
>>> 
>>> % fs version
>>> openafs 1.6.22.2
>>> 
>>> Distributor ID: RedHatEnterpriseWorkstation
>>> Release:6.10
>>> 
>>> The problem is intermittent but goes into device wait most of the
>>> time, for example the first time ran fine, the second time it took
>>> 14.96 seconds.
>>> 
>>> % time ls -l
>>> total 4
>>> lrwxr-xr-x 1 root root   10 Dec 31  1969 cs -> cs.unc.edu
>>> drwxr-xr-x 8 root root 2048 Mar  6  2015 cs.unc.edu
>>> lrwxr-xr-x 1 root root   10 Dec 31  1969 unc -> cs.unc.edu
>>> 0.000u 0.000s 0:00.00 0.0%  0+0k 0+0io 0pf+0w
>>> 
>>> % time ls -l
>>> total 4
>>> lrwxr-xr-x 1 root root   10 Dec 31  1969 cs -> cs.unc.edu
>>> drwxr-xr-x 8 root root 2048 Mar  6  2015 cs.unc.edu
>>> lrwxr-xr-x 1 root root   10 Dec 31  1969 unc -> cs.unc.edu
>>> 0.000u 0.000s 0:14.96 0.0%  0+0k 0+0io 0pf+0w
>>> 
>>> Thanks for any help or ideas to try.

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

Re: [OpenAFS] accessing /afs processes go into device wait

[Stephan Wiesand]

> On 8. Nov 2018, at 18:22, John Sopko  wrote:
> 
> I have been running two legacy Redhat 6.x web servers for several
> years. The apache httpd processes started to go into device wait state
> the last few days on one of the servers, the other server is fine,
> both are configured pretty much the same. I tracked this down to the
> web server trying to stat /afs/.htaccess. If I try to do an ls in /afs
> or cat /afs/.htaccess which does not exist, the commands take a long
> time to complete and first go into device wait state, it can take
> several minutes or they may hang indefinitely. The afs file system
> seems to be working fine, just accessing under /afs is the problem. On
> other Redhat 6.x systems accessing /afs is fast and have no problems.

Are the nsswitch and DNS resolver configurations the same on all systems?
Any differences in network restrictions?
Does it help to run afsd without -afsdb?

Just a wild guess,
Stephan

> 
> I am running afsd with:
> 
> /usr/vice/etc/afsd -dynroot -fakestat-all -afsdb
> 
> Note I tried fakestat-all to see if that would help, I have been
> running just -fakesat, our db servers have afsdb records.
> 
> I removed all cells accept for our cell in CellServDB so only have this:
> 
> % pwd
> /afs
> 
> % ls -l
> total 4
> lrwxr-xr-x 1 root root   10 Dec 31  1969 cs -> cs.unc.edu/
> drwxr-xr-x 8 root root 2048 Mar  6  2015 cs.unc.edu/
> lrwxr-xr-x 1 root root   10 Dec 31  1969 unc -> cs.unc.edu/
> 
> I re-formatted the /usr/vice/cache partition and that did not help.
> 
> I cannot find any hardware problems, no clues in the syslog or on the
> console, the system disk including the cache is on a raid1/mirror
> disk. This is a Dell server and I run Dell OpenMange which is really
> good at reporting system and especially disk errors.
> 
> I am running the same afsd verison on our remaining rhel 6.x servers:
> 
> % fs version
> openafs 1.6.22.2
> 
> Distributor ID: RedHatEnterpriseWorkstation
> Release:6.10
> 
> The problem is intermittent but goes into device wait most of the
> time, for example the first time ran fine, the second time it took
> 14.96 seconds.
> 
> % time ls -l
> total 4
> lrwxr-xr-x 1 root root   10 Dec 31  1969 cs -> cs.unc.edu
> drwxr-xr-x 8 root root 2048 Mar  6  2015 cs.unc.edu
> lrwxr-xr-x 1 root root   10 Dec 31  1969 unc -> cs.unc.edu
> 0.000u 0.000s 0:00.00 0.0%  0+0k 0+0io 0pf+0w
> 
> % time ls -l
> total 4
> lrwxr-xr-x 1 root root   10 Dec 31  1969 cs -> cs.unc.edu
> drwxr-xr-x 8 root root 2048 Mar  6  2015 cs.unc.edu
> lrwxr-xr-x 1 root root   10 Dec 31  1969 unc -> cs.unc.edu
> 0.000u 0.000s 0:14.96 0.0%  0+0k 0+0io 0pf+0w
> 
> Thanks for any help or ideas to try.

-- 
Stephan Wiesand
DESY -DV-
Platanenallee 6
15738 Zeuthen, Germany



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

Re: [OpenAFS] disk cache read error in CacheItems

[Stephan Wiesand]

> On 23. Oct 2018, at 12:16, Andreas Ladanyi  wrote:
> 
>> In the last few days we've observed an increasing number of Nodes,
>> which are no longer be reached and have to be rebooted
>> 
>> In the /var/log/messages we see a lot of lines with e.g.
>> 
>> Oct 22 18:48:26 bird858 kernel: afs: disk cache read error in
>> CacheItems slot 25254 off 2020340/13880020 code -5/80
>> Oct 22 18:48:26 bird858 kernel: afs: disk cache read error in
>> CacheItems slot 25253 off 2020260/13880020 code -5/80
>> Oct 22 18:48:26 bird858 kernel: afs: disk cache read error in
>> CacheItems slot 25252 off 2020180/13880020 code -5/80
>> Oct 22 18:48:26 bird858 kernel: afs: disk cache read error in
>> CacheItems slot 25251 off 2020100/13880020 code -5/80
>> 
>> till nothing happens anymore ...
>> 
>> The clients are  Centos 7.5 , 3.10.0-862.14.4.el7.x86_64, OpenAFS
>> 1.6.23 built 2018-09-12 (289.sl7.862.1...@fnal.gov)
>> 
>> Any hints for the possible reason ?
> 
> I have the same constellation with AFS 1.6.23 client from jsbilling repo.
> 
> I cant see this messages in /var/log/messages yet.

We're running the same kernel version and the same client build (it's the SL 
one) on a fair number of SL 7.4 systems, and don't see these issues either.

-5 is EIO, meaning an actual I/O error is reported.

What's the size and type of the cache filesystems? What does "fs getcache 
report"? What are the afsd parameters? Could these nodes be out of space or 
inodes for the cache?

-- 
Stephan Wiesand
DESY -DV-
Platanenallee 6
15738 Zeuthen, Germany



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

Re: [OpenAFS] check in c (linux) whether a directory entry is a mount point for an AFS volume

[Stephan Wiesand]

> On 3. Aug 2018, at 13:08, Christian  wrote:

> is there an easy  way to check in C (under linux) whether a directory
> entry is a mount point for an afs volume and maybe also obtain the name
> of the volume mounted?

popen("fs lsm /the/path", "r") ?
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] centos 7.5 and enotdir

[Stephan Wiesand]

> On 25.Jul 2018, at 18:30, Benjamin Kaduk  wrote:
> 
> On Wed, Jul 25, 2018 at 09:25:18AM -0700, Renata Maria Dart wrote:
>> Hi, we just now are seeing problems with centos 7.5 and Openafs 1.6.8
>> where you can cat or run an executable in AFS, but you cannot ls it.
>> Is this what is being referred to as the enotdir issue that is now
>> fixed in the 1.8.0 OpenAFS tree?
> 
> Yes.

And by the way, it's fixed in the 1.6.22.3 release too. Is there a particular 
reason why you're using such an old client?

- Stephan

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

Re: [OpenAFS] Remarks: aklog+pagsh SL7 x64

[Stephan Wiesand]

Indeed. The SL packaging renames pagsh to pagsh.openafs  to avoid clashes with 
other software like heimdal providing it.

Regarding aklog, I thought that -setpag was broken on Linux many years ago.

> On 31. May 2018, at 17:08, Jonathan Billings  wrote:
> 
> What packages are you using, and where did you install them from?
> 
> On Thu, May 31, 2018 at 11:04 AM, r.laatsch  
> wrote:
> 
> 
> 
>  Forwarded Message 
> Subject:  Remarks: aklog+pagsh SL7 x64
> Date: Thu, 31 May 2018 16:57:42 +0200
> From: r.laatsch 
> To:   
> CC:   
> 
> 
> 
> 
> 
>  Forwarded Message 
> Subject:  
> Date: 
> From: 
> To:   
> CC:   
> 
> 
> I am running SL 7 (in virtualbox, should'nt matter),  64bit, patches 
> applied.
> The openafs rpms are installed.
> 
> Starting afsd succeeded.
> 
> Now:
>  aklog -setpagdoes not set a token (and no pag)
>  pagsh is missing(can be found in the heimdal package)
> Please check this.
>  Best regards
> 
> R. Laatsch

-- 
Stephan Wiesand
DESY -DV-
Platanenallee 6
15738 Zeuthen, Germany



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

Re: [OpenAFS] RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up

[Stephan Wiesand]

> On 23. Mar 2018, at 12:27, Kodiak Firesmith <kfiresm...@gmail.com> wrote:
> 
> I've also tested gsgatlin's 7.5beta RPMs and they work great.  Any chance 
> we'll see the rh75enotdir patch integrated into a release of 1.6.22.3 soon?  
> I'm wondering if it'll be worth it to manually apply that patch to a rebuild 
> of the official OpenAFS RPMs if this isn't on the block for being merged and 
> released soon - but I don't want to blow the time applying that patch to a 
> re-roll if a fixed official release is forthcoming.

We are planning to release a 1.6.22.3 addressing the ENOTDIR issue with the 
EL7.5 kernel soon after the EL7.5 GA release.

- Stephan

> Thanks!
>  - Kodiak
> 
> 
> On Fri, Mar 2, 2018 at 3:47 AM, Anders Nordin <anders.j.nor...@ltu.se> wrote:
> Hello,
> 
> Is there any progress on this issue? Can we expect a stable release for RHEL 
> 7.5?
> 
> MVH
> Anders
> 
> -Original Message-
> From: openafs-info-ad...@openafs.org [mailto:openafs-info-ad...@openafs.org] 
> On Behalf Of Benjamin Kaduk
> Sent: den 9 februari 2018 01:02
> To: Kodiak Firesmith <kfiresm...@gmail.com>
> Cc: openafs-info <openafs-info@openafs.org>
> Subject: Re: [OpenAFS] RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up
> 
> On Wed, Feb 07, 2018 at 11:46:28AM -0500, Kodiak Firesmith wrote:
> > Hello again All,
> >
> > As part of continued testing, I've been able to confirm that the
> > SystemD double-service startup thing only happens to my hosts when
> > going from RHEL
> > 7.4 to RHEL 7.5beta.  On a test host installed directly as RHEL
> > 7.5beta, I get a bit farther with 1.6.18.22, in that I get to the
> > point where OpenAFS "kind of" works.
> 
> Thanks for tracking this down.  The rpm packaging maintainers may want to try 
> to track down why the double-start happens in the upgrade scenario, as that's 
> pretty nasty behavior.
> 
> > What I'm observing is that the openafs client Kernel module (built by
> > DKMS) loads fine, and just so long as you know where you need to go in
> > /afs, you can get there, and you can read and write files and the OpenAFS 
> > 'fs'
> > command works.  But doing an 'ls' of /afs or any path underneath
> > results in
> > "ls: reading directory /afs/: Not a directory".
> >
> > I ran an strace of a good RHEL 7.4 host running ls on /afs, and a RHEL
> > 7.5beta host running ls on /afs and have created pastebins of both, as
> > well as an inline diff.
> >
> > All can be seen at the following locations:
> >
> > works
> > https://paste.fedoraproject.org/paste/Hiojt2~Be3wgez47bKNucQ
> >
> > fails
> > https://paste.fedoraproject.org/paste/13ZXBfJIOMsuEJFwFShBfg
> >
> >
> > diff
> > https://paste.fedoraproject.org/paste/FJKRwep1fWJogIDbLnkn8A
> >
> > Hopefully this might help the OpenAFS devs, or someone might know what
> > might be borking on every RHEL 7.5 beta host.  It does fit with what
> > other
> > 7.5 beta users have observed OpenAFS doing.
> 
> Yes, now it seems like all our reports are consistent, and we just have to 
> wait for a developer to get a better look at what Red Hat changed in the 
> kernel that we need to adapt to.
> 
> -Ben
> 
> > Thanks!
> >  - Kodiak
> >
> > On Mon, Feb 5, 2018 at 12:31 PM, Stephan Wiesand
> > <stephan.wies...@desy.de>
> > wrote:
> >
> > >
> > > > On 04.Feb 2018, at 02:11, Jeffrey Altman <jalt...@auristor.com> wrote:
> > > >
> > > > On 2/2/2018 6:04 PM, Kodiak Firesmith wrote:
> > > >> I'm relatively new to handling OpenAFS.  Are these problems part
> > > >> of a normal "kernel release; openafs update" cycle and perhaps
> > > >> I'm getting snagged just by being too early of an adopter?  I
> > > >> wanted to raise the alarm on this and see if anything else was
> > > >> needed from me as the reporter of the issue, but perhaps that's
> > > >> an overreaction to what is just part of a normal process I just
> > > >> haven't been tuned into in prior RHEL release cycles?
> > > >
> > > >
> > > > Kodiak,
> > > >
> > > > On RHEL, DKMS is safe to use for kernel modules that restrict
> > > > themselves to using the restricted set of kernel interfaces (the
> > > > RHEL KABI) that Red Hat has designated will be supported across
> > > > the lifespan of the RHEL major version number.  OpenAFS is not
> > > > such a kernel module.  As a result it is vulnerable 

Re: [OpenAFS] RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up

[Stephan Wiesand]

> On 02.Mar 2018, at 12:40, Gary Gatling <gsgat...@ncsu.edu> wrote:
> 
>> On Fri, Mar 2, 2018 at 4:14 AM, Stephan Wiesand <stephan.wies...@desy.de> 
>> wrote:
>> 
>> 
>> Once we have a change confirmed to fix the EL7.5 issue and not break other 
>> platforms, yes. Whether it will be available quite in time for 7.5 GA is 
>> hard to say. You can help...
>> 
>> 
>> I will test this patch out later today and let you guys know what I find 
>> out. Thanks a lot.

Make sure you grab the patch from set 3 (the latest revision). It might be the 
final solution.

-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany


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

Re: [OpenAFS] RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up

[Stephan Wiesand]

Hello,

> On 2. Mar 2018, at 09:47, Anders Nordin <anders.j.nor...@ltu.se> wrote:
> 
> Hello,
> 
> Is there any progress on this issue?

incidentally, Mark uploaded https://gerrit.openafs.org/12935 a couple of hours 
ago. It's probably not final since it seems to cause build failures on some 
older platforms. But it's certainly worth a try on EL7.5 beta systems. It would 
also be interesting to know on which other platforms it fails to build (or 
work).

> Can we expect a stable release for RHEL 7.5?

Once we have a change confirmed to fix the EL7.5 issue and not break other 
platforms, yes. Whether it will be available quite in time for 7.5 GA is hard 
to say. You can help...

Best regards,

Stephan


> MVH
> Anders
> 
> -Original Message-
> From: openafs-info-ad...@openafs.org [mailto:openafs-info-ad...@openafs.org] 
> On Behalf Of Benjamin Kaduk
> Sent: den 9 februari 2018 01:02
> To: Kodiak Firesmith <kfiresm...@gmail.com>
> Cc: openafs-info <openafs-info@openafs.org>
> Subject: Re: [OpenAFS] RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up
> 
> On Wed, Feb 07, 2018 at 11:46:28AM -0500, Kodiak Firesmith wrote:
>> Hello again All,
>> 
>> As part of continued testing, I've been able to confirm that the 
>> SystemD double-service startup thing only happens to my hosts when 
>> going from RHEL
>> 7.4 to RHEL 7.5beta.  On a test host installed directly as RHEL 
>> 7.5beta, I get a bit farther with 1.6.18.22, in that I get to the 
>> point where OpenAFS "kind of" works.
> 
> Thanks for tracking this down.  The rpm packaging maintainers may want to try 
> to track down why the double-start happens in the upgrade scenario, as that's 
> pretty nasty behavior.
> 
>> What I'm observing is that the openafs client Kernel module (built by 
>> DKMS) loads fine, and just so long as you know where you need to go in 
>> /afs, you can get there, and you can read and write files and the OpenAFS 
>> 'fs'
>> command works.  But doing an 'ls' of /afs or any path underneath 
>> results in
>> "ls: reading directory /afs/: Not a directory".
>> 
>> I ran an strace of a good RHEL 7.4 host running ls on /afs, and a RHEL 
>> 7.5beta host running ls on /afs and have created pastebins of both, as 
>> well as an inline diff.
>> 
>> All can be seen at the following locations:
>> 
>> works
>> https://paste.fedoraproject.org/paste/Hiojt2~Be3wgez47bKNucQ
>> 
>> fails
>> https://paste.fedoraproject.org/paste/13ZXBfJIOMsuEJFwFShBfg
>> 
>> 
>> diff
>> https://paste.fedoraproject.org/paste/FJKRwep1fWJogIDbLnkn8A
>> 
>> Hopefully this might help the OpenAFS devs, or someone might know what 
>> might be borking on every RHEL 7.5 beta host.  It does fit with what 
>> other
>> 7.5 beta users have observed OpenAFS doing.
> 
> Yes, now it seems like all our reports are consistent, and we just have to 
> wait for a developer to get a better look at what Red Hat changed in the 
> kernel that we need to adapt to.
> 
> -Ben
> 
>> Thanks!
>> - Kodiak
>> 
>> On Mon, Feb 5, 2018 at 12:31 PM, Stephan Wiesand 
>> <stephan.wies...@desy.de>
>> wrote:
>> 
>>> 
>>>> On 04.Feb 2018, at 02:11, Jeffrey Altman <jalt...@auristor.com> wrote:
>>>> 
>>>> On 2/2/2018 6:04 PM, Kodiak Firesmith wrote:
>>>>> I'm relatively new to handling OpenAFS.  Are these problems part 
>>>>> of a normal "kernel release; openafs update" cycle and perhaps 
>>>>> I'm getting snagged just by being too early of an adopter?  I 
>>>>> wanted to raise the alarm on this and see if anything else was 
>>>>> needed from me as the reporter of the issue, but perhaps that's 
>>>>> an overreaction to what is just part of a normal process I just 
>>>>> haven't been tuned into in prior RHEL release cycles?
>>>> 
>>>> 
>>>> Kodiak,
>>>> 
>>>> On RHEL, DKMS is safe to use for kernel modules that restrict 
>>>> themselves to using the restricted set of kernel interfaces (the 
>>>> RHEL KABI) that Red Hat has designated will be supported across 
>>>> the lifespan of the RHEL major version number.  OpenAFS is not 
>>>> such a kernel module.  As a result it is vulnerable to breakage each and 
>>>> every time a new kernel is shipped.
>>> 
>>> Jeffrey,
>>> 
>>> the usual way to use DKMS is to either have it build a module for a 
>>> newly installed kernel or install a prebuilt 

Re: [OpenAFS] RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up

[Stephan Wiesand]

> On 04.Feb 2018, at 02:11, Jeffrey Altman <jalt...@auristor.com> wrote:
> 
> On 2/2/2018 6:04 PM, Kodiak Firesmith wrote:
>> I'm relatively new to handling OpenAFS.  Are these problems part of a
>> normal "kernel release; openafs update" cycle and perhaps I'm getting
>> snagged just by being too early of an adopter?  I wanted to raise the
>> alarm on this and see if anything else was needed from me as the
>> reporter of the issue, but perhaps that's an overreaction to what is
>> just part of a normal process I just haven't been tuned into in prior
>> RHEL release cycles?
> 
> 
> Kodiak,
> 
> On RHEL, DKMS is safe to use for kernel modules that restrict themselves
> to using the restricted set of kernel interfaces (the RHEL KABI) that
> Red Hat has designated will be supported across the lifespan of the RHEL
> major version number.  OpenAFS is not such a kernel module.  As a result
> it is vulnerable to breakage each and every time a new kernel is shipped.

Jeffrey,

the usual way to use DKMS is to either have it build a module for a newly
installed kernel or install a prebuilt module for that kernel. It may be
possible to abuse it for providing a module built for another kernel, but
I think that won't happen accidentally.

You may be confusing DKMS with RHEL's "KABI tracking kmods". Those should
be safe to use within a RHEL minor release (and the SL packaging has been
using them like this since EL6.4), but aren't across minor releases (and
that's why the SL packaging modifies the kmod handling to require a build
for the minor release in question.

> There are two types of failures that can occur:
> 
> 1. a change results in failure to build the OpenAFS kernel module
>for the new kernel
> 
> 2. a change results in the OpenAFS kernel module building and
>successfully loading but failing to operate correctly

The latter shouldn't happen within a minor release, but can across
minor releases.

> It is the second of these possibilities that has taken place with the
> release of the 3.10.0-830.el7 kernel shipped as part of the RHEL 7.5 beta.
> 
> Are you an early adopter of RHEL 7.5 beta?  Absolutely, its a beta
> release and as such you should expect that there will be bugs and that
> third party kernel modules that do not adhere to the KABI functionality
> might have compatibility issues.

The -830 kernel can break 3rd-party modules using non-whitelisted ABIs,
whether or not they adhere to the "KABI functionality".

> There was a compatibility issue with RHEL 7.4 kernel
> (3.10.0_693.1.1.el7) as well that was only fixed in the OpenAFS 1.6
> release series this past week as part of 1.6.22.2:
> 
>  http://www.openafs.org/dl/openafs/1.6.22.2/RELNOTES-1.6.22.2

Yes, and this one was hard to fix. Thanks are due to Mark Vitale for
developing the fix and all those who reviewed and tested it.

> Jeffrey Altman
> AuriStor, Inc.
> 
> P.S. - Welcome to the community.

Seconded. In particular, the problem report regarding the EL7.5beta
kernel was absolutely appropriate.

-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany


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

Re: [OpenAFS] Re: RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up

[Stephan Wiesand]

While additional data points are obviously most welcome, there is no 
expectation that this issue is fixed with 1.6.22.x or 1.8.x right now. Some 
serious work will be required to adapt OpenAFS to the changes in this kernel 
(series), though there's some hope that it won't be quite as hard to fix as the 
7.4 getcwd issue.

- Stephan

> On 02.Feb 2018, at 22:20, Kodiak Firesmith  wrote:
> 
> Not much else to report today other than expanding my test base out to a few 
> more RHEL 7.5b hosts, and re-rolled the 1.6.22.1-1 SRPM again, and am still 
> seeing the same results universally.  Every host fails to boot due to a 
> kernel panic when it tries to load the openafs DKMS kernel module.
> 
> My next move on Monday will be to try an actual kernel-specific kmod instead 
> of DKMS.  If that works I'll be kind of sad since we've had great luck with 
> DKMS until now.
> 
>  - Kodiak
> 
> On Thu, Feb 1, 2018 at 3:26 PM, Kodiak Firesmith  wrote:
> I just rebuilt off-the-shelf RPMs based off of 
> http://www.openafs.org/dl/openafs/1.6.22.1/openafs-1.6.22.1-1.src.rpm 
> thinking maybe we had some historical patch in our build area that might be 
> causing the problem, but alas, even the off-the-shelf RPMs cause a full wedge 
> and reboot when openafs-client.service starts up.  
> 
>  - Kodiak
> 
> On Thu, Feb 1, 2018 at 1:23 PM, Kodiak Firesmith  wrote:
> Hello Rich!
> It's a Dell Optiplex 7020 with an Intel i7-4790.
> 
> Thanks!
>  - Kodiak
> 
> On Thu, Feb 1, 2018 at 1:20 PM, Rich Sudlow  wrote:
> On 01/31/2018 09:43 AM, Kodiak Firesmith wrote:
> https://photos.app.goo.gl/WgPsSUCLK5ojxIuH3
> 
> Greetings
> 
> What processor..etc is this machine?
> 
> Rich
> 
> 
> 
> 
> On Wed, Jan 31, 2018 at 9:41 AM, Kodiak Firesmith  > wrote:
> 
> Folks, re-sending this because the first try never hit the list - perhaps
> mail with attachments are silently dropped or held for manual moderation? 
> I'd originally attached an image of the stack trace.  I'll host it and 
> reply
> to this with a  URL link in case that would also result in a drop or 
> moderation.
> 
> 
> 
> Anyhow:
> 
> In testing the new RHEL 7.5 beta, we've discovered that hosts using AFS 
> fail
> to boot after the upgrade, with Openafs 1.6.22.1 installed.
> 
> We are wondering if some of the non-guaranteed kernel ABIs that OpenAFS 
> uses
> might have changed with the latest kernel provided in RHEL 7.
> 
> I've attached a picture of the trace.
> 
> Anyone else kicking the tires on the new RHEL yet?
> 
> Thanks!

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

Re: [OpenAFS] Re: RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up

[Stephan Wiesand]

> On 2. Feb 2018, at 09:55, Stephan Wiesand <stephan.wies...@desy.de> wrote:
> 
> 
>> On 2. Feb 2018, at 02:14, Benjamin Kaduk <ka...@mit.edu> wrote:
>> 
>> On Thu, Feb 01, 2018 at 05:11:24PM +0100, Stephan Wiesand wrote:
>>> Comparing the 1.6.22.2 module builds from the SL packaging, where the kABI 
>>> hashes of the used symbols are stored as a requirement, is seems none of 
>>> those hashes changed between -693 and -830.
>>> 
>>> There are two differences in the configure results:
>>> 
>>> -ac_cv_linux_header_sched_signal_h=no
>>> +ac_cv_linux_header_sched_signal_h=yes
>>> 
>>> -ac_cv_linux_struct_file_operations_has_iterate=no
>>> +ac_cv_linux_struct_file_operations_has_iterate=yes
>> 
>> That's very helpful to know.
>> 
>> Does the new tree actually have a sched/signal.h header?
> 
> Yes it does. The only content is a guarded include of 
> 
>> Does the new struct file_operations have an 'iterate' member
>> function?
> 
> Yes it does, wrapped in a RH_KABI_ITERATE macro.

er, nonsense, that's RH_KABI_EXTEND, sorry

> 
>> (The idea being to tell whether they changed something in new and
>> interesting ways or our configure test(s) are broken.)
> 
> It's the former :-(

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

Re: [OpenAFS] Re: RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up

[Stephan Wiesand]

> On 2. Feb 2018, at 02:14, Benjamin Kaduk <ka...@mit.edu> wrote:
> 
> On Thu, Feb 01, 2018 at 05:11:24PM +0100, Stephan Wiesand wrote:
>> Comparing the 1.6.22.2 module builds from the SL packaging, where the kABI 
>> hashes of the used symbols are stored as a requirement, is seems none of 
>> those hashes changed between -693 and -830.
>> 
>> There are two differences in the configure results:
>> 
>> -ac_cv_linux_header_sched_signal_h=no
>> +ac_cv_linux_header_sched_signal_h=yes
>> 
>> -ac_cv_linux_struct_file_operations_has_iterate=no
>> +ac_cv_linux_struct_file_operations_has_iterate=yes
> 
> That's very helpful to know.
> 
> Does the new tree actually have a sched/signal.h header?

Yes it does. The only content is a guarded include of 

> Does the new struct file_operations have an 'iterate' member
> function?

Yes it does, wrapped in a RH_KABI_ITERATE macro.

> (The idea being to tell whether they changed something in new and
> interesting ways or our configure test(s) are broken.)

It's the former :-(

-- 
Stephan Wiesand
DESY -DV-
Platanenallee 6
15738 Zeuthen, Germany



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

Re: [OpenAFS] Re: RHEL 7.5 beta / 3.10.0-830.el7.x86_66 kernel lock up

[Stephan Wiesand]

Comparing the 1.6.22.2 module builds from the SL packaging, where the kABI 
hashes of the used symbols are stored as a requirement, is seems none of those 
hashes changed between -693 and -830.

There are two differences in the configure results:

-ac_cv_linux_header_sched_signal_h=no
+ac_cv_linux_header_sched_signal_h=yes

-ac_cv_linux_struct_file_operations_has_iterate=no
+ac_cv_linux_struct_file_operations_has_iterate=yes

And there's quite a bit of churn in include/linux.fs.h (and some in key.h).

> On 1. Feb 2018, at 16:58, Gary Gatling <gsgat...@ncsu.edu> wrote:
> 
> Ok. This gets weirder. Any directory under /afs says Not a directory. But I 
> can read files like
> 
> /afs/eos.ncsu.edu/software/inventory/software_inventory
> 
> just fine. 
> 
> On Thu, Feb 1, 2018 at 10:55 AM, Gary Gatling <gsgat...@ncsu.edu> wrote:
> I don't get a kernel panic but instead I get:
> 
> [gsgatlin@localhost ~]$ ls /afs/
> ls: reading directory /afs/: Not a directory
> [gsgatlin@localhost ~]$ 
> 
> 
> which is pretty weird. I don't see anything in the syslog about problems with 
> openafs
> 
> Feb  1 10:44:24 localhost systemd: Starting OpenAFS Client Service...
> Feb  1 10:44:24 localhost kernel: libafs: loading out-of-tree module taints 
> kernel.
> Feb  1 10:44:24 localhost kernel: libafs: module license 
> 'http://www.openafs.org/dl/license10.html' taints kernel.
> Feb  1 10:44:24 localhost kernel: Disabling lock debugging due to kernel taint
> Feb  1 10:44:24 localhost kernel: libafs: module verification failed: 
> signature and/or required key missing - tainting kernel
> Feb  1 10:44:24 localhost kernel: Key type afs_pag registered
> Feb  1 10:44:24 localhost kernel: enabling dynamically allocated vcaches
> Feb  1 10:44:24 localhost kernel: Starting AFS cache scan...Memory cache: 
> Allocating 1600 dcache entries...found 0 non-empty cache files (0%).
> Feb  1 10:44:24 localhost afsd: afsd: All AFS daemons started.
> Feb  1 10:44:24 localhost afsd: afsd: All AFS daemons started.
> Feb  1 10:44:24 localhost systemd: Started OpenAFS Client Service.
> 
> I am using openafs-1.6.22
> 
> 
> with
> 
> correct-m4-conditionals-in-curses.m4.patch
> linux-test-for-vfswrite-rather-than-vfsread.patch
> linux-use-kernelread-kernelwrite-when-vfs-varian.patch
> 
> from the arch linux distro in my rpm packages.
> 
> Anyone know what 
> 
> ls: reading directory /afs/: Not a directory
> 
> means and is there some way around it?
> 
> Also, is 1.6.22.2 coming out soon?
> 
> Thanks so much,
> 
> On Wed, Jan 31, 2018 at 9:43 AM, Kodiak Firesmith <kfiresm...@gmail.com> 
> wrote:
> https://photos.app.goo.gl/WgPsSUCLK5ojxIuH3
> 
> 
> On Wed, Jan 31, 2018 at 9:41 AM, Kodiak Firesmith <kfiresm...@gmail.com> 
> wrote:
> Folks, re-sending this because the first try never hit the list - perhaps 
> mail with attachments are silently dropped or held for manual moderation?  
> I'd originally attached an image of the stack trace.  I'll host it and reply 
> to this with a  URL link in case that would also result in a drop or 
> moderation.
> 
> 
> 
> Anyhow:  
> 
> In testing the new RHEL 7.5 beta, we've discovered that hosts using AFS fail 
> to boot after the upgrade, with Openafs 1.6.22.1 installed.  
> 
> We are wondering if some of the non-guaranteed kernel ABIs that OpenAFS uses 
> might have changed with the latest kernel provided in RHEL 7.  
> 
> I've attached a picture of the trace.
> 
> Anyone else kicking the tires on the new RHEL yet?
> 
> Thanks!
> 
> 
> 
> 

-- 
Stephan Wiesand
DESY -DV-
Platanenallee 6
15738 Zeuthen, Germany



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

Re: [OpenAFS] getcwd() error for RHEL 7.4 kernel

[Stephan Wiesand]

On Nov 16, 2017, at 07:06 , Benjamin Kaduk wrote:

> On Wed, Nov 15, 2017 at 01:02:15PM -0500, Matt Vander Werf wrote:
>> Hello,
>> 
>> Are there any updates or progress on a potential fix for this issue?
>> Anything we can do to help figure things out?
> 
> This topic was on the agenda for our release-team meeting yesterday.

Well, it has been for the last couple of weeks.

> If I remmber correctly, multiple developers have gotten fairly
> reliable ways to reproduce the issue locally.
> It also seems that as a workaround, reverting
> https://gerrit.openafs.org/#/c/12451/ is likely to reduce the
> likelihood of triggering events.

Yes, but there's at least one known client configuration (small stat cache, 
-disable-dynamic-vcaches) for which reverting that change actually makes things 
worse.

I ran a number of tests again today. I was unable to trigger any issue with the 
EL7.3 kernel, neither with OpenAFS 1.6.20 nor 1.6.21.1 nor 1.6.21.1 with the 
change in question reverted. I was able to trigger the getcwd issue or the 
other one (a git clone into AFS space failing right away) with the EL7.4 
kernel, depending on circumstances. We do have a problem with the 7.4 kernel, 
with or without that change.

The following could be complete nonsense, so please correct me: The best bet 
for sites getting desperate is probably to increase the minimum stat cache size 
beyond typical actual use on the client.

- Stephan

>> We are running into more and more users encountering the issue on systems
>> we have updated, forcing us to have to downgrade the kernel on them yet as
>> well (including the system we were able to reproduce it on and test with
>> before). Is there any other information we might provide before we do that?
> 
> Given the assumption that developers are reproducing the same
> situation that you are, hopefully there is not a need for additional
> information from the production sites.
> 
> Thanks,
> 
> Ben

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

Re: [OpenAFS] getcwd() error for RHEL 7.4 kernel

[Stephan Wiesand]

> On 20. Oct 2017, at 03:41, Benjamin Kaduk <ka...@mit.edu> wrote:
> 
> Hi Matt,
> 
> On Thu, Oct 19, 2017 at 09:18:56AM -0400, Matt Vander Werf wrote:
>> Hi Ben,
>> 
>> What do you mean by an openafs config.log? Where would this be at? Would it
>> be on the client or the AFS file server? Or is there something that needs
>> to be done to generate this log file?
> 
> This is the config.log generated by the (autoconf) configure script that
> runs as part of the openafs build; I'm interested in the log from a client.

I ran configure against the EL7.3 and EL7.4 GA kernels (3.10.0-514.el7 and 
3.10.0-696.el7) and compared the results.

Besides the fact that in the 7.4 case conftest.c is compiled with an additional 
-DCONFIG_AVX512, which I doubt makes a difference, there are some differences 
in configure test results:

7.3 7.4
locks_lock_file_waitno  yes
inode_lock  no  yes
exported tasklist_lock  yes no

If you still want the full log(s) I can provide them.

-- 
Stephan Wiesand
DESY -DV-
Platanenallee 6
15738 Zeuthen, Germany



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

Re: [OpenAFS] OpenAFS release 1.6.21 available

[Stephan Wiesand]

Garance,

On Aug 11, 2017, at 23:26 , Garance A Drosehn wrote:

> On 11 Aug 2017, at 15:47, Jan Iven wrote:
> 
>> On 11/08/17 21:39, Garance A Drosehn wrote:
>>> 
>>> Ah, thanks!  I had guessed that it might be his PGP key that I
>>> needed, but the only keyserver that my GPG Keychain application
>>> searches is hkp://keys.gnupg.net , and his key did not show up
>>> there.
>>> 
>>> Hmm.  Actually keys.gnupg.net *does* know about his key, but did
>>> not show it to me because it lists the key as expired, and I had
>>> the key-search avoid any keys which are revoked or expired.
>>> [...]

yes, the key has expired quite a while ago.

>>> And when I run the source-rpm through rpm with that key, I still
>>> see the warning "... Signature, key ID 9e590f86: NOKEY".

Note that if I hadn't signed the SRPM at all, your rpm command would have 
silently installed the source package, without any warning. Would you prefer 
that?

>>> It often takes me multiple times to do anything with PGP keys, so
>>> maybe I'm still doing something wrong here?  Especially since I'm
>>> getting the message "Oops: keyid_from_fingerprint: no pubkey" .
>> 
>> 
>> I think you'll need to download the ASCII version of his public
>> key, and provide the file to "rpmkeys --import".

Careful: That will instruct rpm/yum to trust my key forever and for packages 
from any repository. I wouldn't recommend that...

> That is basically what I did, except I did it through the program
> that https://gpgtools.org provides for macOS, called GPG keychain.
> That has worked for other keys that I've added to my pubring.
> 
> Also, once I told GPG keychain to show me keys which have expired, then
> I could find the same key through hkp://keys.gnupg.net.  And after
> updating the key from hkp://keys.gnupg.net , the result was the same.
> 
>> But please note that while verifying source integrity is a good
>> idea, you do not need to install the source RPM. You download
>> (+verify: "rpmkeys --checksig") + recompile it, and the resulting
>> binary RPMs will be not signed (unless you sign them yourself).

See above. Unless you really want to trust my key for everything, I recommend 
importing it into a separate rpmdb used for nothing else but checking my 
signature. ("rpm --dbpath ...").

> I'm not looking to sign the binary RPM's (although I should learn
> to do that!).  I just want to be sure that the source-RPM that I
> downloaded really is the one that OpenAFS.org has released.  And
> that someone hasn't replaced it with a different source-RPM which
> *they* signed with *their* PGP key.
> 
> I'm not sure why, but today I got to thinking that I should be more
> paranoid about that verifying the pgp key as long as someone is
> taking the trouble to sign it.

Good thinking, but you should reject any rpms not signed at all then.

>  I tried the above verify command,
> and the output is:
> 
>   rpmbuild/SRPMS/openafs-1.6.21-1.el7.src.rpm: sha1 md5 OK
> 
> But I *think* that just tells me that the RPM is the same as it
> was when it was signed.  But it doesn't tell me who signed it.

It means the payload checksums are the same as when the SRPM was built. Which 
is just a bit weaker than the sha256 checksums we now provide for the tarballs.

> Apologies for all the extra noise here.

No, bringing this up is fine IMO. I wish more folks would think about whom they 
actually trust when they run "rpm --rebuild", "make" (& Co.), "pip", 
"easy-install", "go get" ...

[...]

> Also, fwiw, I'm using the source-RPM to build for RHEL7, not CentOS.

That shouldn't matter.

> I'm trying to generate new binary-RPM's for the new RHEL7 kernel
> that Redhat released last week.  And I'm having no trouble creating
> those RPM's, but today I got to thinking that my first step should
> be to verify the source-RPM that I start out with.  Not just that the
> digests are valid, but that I know who it was that signed the rpm.

Well, that was me, and the signature on the package is my current best effort 
to prove it. While the key is well past the expiration date set when I created 
it, rpm doesn't care, and a simple google search for the public key file yields 
several hundred hits across the globe, which is mostly due to the fact that it 
was distributed with Scientific Linux releases up to SL5 (admittedly, many no 
longer work since SL5 is EOL and was archived a few months ago).

Ideally, I would sign the srpms with the same private key used for the binary 
rpms we provide. Alas, I don't have access to that key (which on the other hand 
is proof that key secrecy is being taken seriously in the project).

Ultimately, what counts is the git tag for a release signed by an AFS 
gatekeeper/guardian
(thus, NOT me). The src/doc tarballs are programatically derived from a 
checkout of that tag, and the srpm is programatically derived from just those 
(with the sole exception of the CellServDB). Which means there is a reasonably 
strong chain of trust all the way down from git.openafs.org to 

Re: [OpenAFS] strange errors when using a iso file mounted as a loop device, if the iso file is located in AFS

[Stephan Wiesand]

> On 13. Jul 2017, at 12:54, Giovanni Bracco <giovanni.bra...@enea.it> wrote:
> 
> The error is related to accessing archive files that are contained in image 
> ISO files that are physically located in AFS.
> 
> The typical and repeated error is:
>   Errors extracting '/mnt/iso2/common/LINX64.GZ'
>   '"/opt/ansys_inc/extract.sh"' terminated after 1 attempts with the 
> following error(s):
>   Unknown error
>   Exit Code: 2
>  tar: This does not look like a tar archive
> 
> The ISO is mounted locally to the server with
> mount -o loop -t iso9660 file_in_afs.iso /mnt/iso2
> 
> When the iso file is moved on the server local file-system the error 
> disappears.
> 
> The client:
> AFS version:  OpenAFS 1.6.7 built  2014-04-05
> CentOS 6.7 kernel 2.6.32-358.23.2.el6.x86_64
> 
> Any suggestion?

Obviously, try a recent client - 1.6.7 is rather ancient.

And what's the fileserver version?

What are the sizes of the image and the client cache (and which cache type are 
you using)?

-- 
Stephan Wiesand
DESY -DV-
Platanenallee 6
15738 Zeuthen, Germany



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

Re: [OpenAFS] OpenAFS preference pane error

[Stephan Wiesand]

Hello,

On Feb 20, 2017, at 22:55 , Joshua Byers wrote:

> Hello,
> 
> I am wondering if anyone has seen the following error when loading the 
> OpenAFS preference pane in OpenAFS compiled by Sine Nomine 1.6.20 for El 
> Capitan?
> 
> "Invalid parameter not satisfying: aString != nil​"
> 
> I can get tickets and tokens at the command line fine.  However, the 
> preference pane is unreliable at best.

we have a prefpane fix in https://gerrit.openafs.org/#/c/12512/ . It will be in 
the next stable release. I'm not sure whether it will fix your issue though. 
Anyone?


> Thanks in advance,
> 
> Joshua Byers

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1

[Stephan Wiesand]

On Feb 7, 2017, at 20:39 , Brandon Allbery wrote:

> You can't sensibly virtualize IBM POWER / PowerPC architecture on Intel CPUs. 
> (Or even "at all"; I think the closest you get is qemu's PrEP which will not 
> boot AIX.)

Thank you Brandon!

From what I read, Power-VM would probably do the trick. Alas, it seems to 
require a POWER host and be a proprietary product. Which is just what I meant 
when writing "just as hard to find". I'm not aware of any other solution. Well, 
supposedly you can rent AIX VMs in some clouds.

But ultimately, Ben's got the killer argument. If we had the human resources, 
anything else could probably be sorted out.

- Stephan

> 
> -Original Message-
> From: openafs-info-ad...@openafs.org [mailto:openafs-info-ad...@openafs.org] 
> On Behalf Of Ted Creedon
> Sent: Monday, February 6, 2017 4:26 PM
> To: openafs-info@openafs.org
> Subject: Re: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1
> 
> I just happen to have a spare dual xeon 64gb linux box that could be made 
> available.
> and smaller MAC w/ parallels on it.
> 
> I also have a dual 64gb xeon w/ a xeon phi card in it too. cost ~$3K
> 
> with a little effort...
> 
> IBM generally  waives license fees for non profits.
> tedc
> 
> 
> From: Gary Buhrmaster 
> Sent: Monday, February 6, 2017 10:24 AM
> To: Ted Creedon
> Subject: Re: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1
> 
> On Mon, Feb 6, 2017 at 5:34 PM, Ted Creedon  wrote:
>> why not use vm's for all non linux builds?
> 
> If what you meant was for the foundation itself to pay for virtual build 
> servers, all that takes if for the foundation to decide to spend real money.  
> I presume they have considered that, but it might be worth asking the 
> question explicitly if it has not been explicitly answered (I really have not 
> been following the foundations activities).
> 
> It might not even cost a lot (as I recall, there are various on-demand 
> builder spin-up capabilities in at least some SCMs so it is free until the 
> commit), but it is all work someone would have to research.
> 
> I would not be at all surprised if the
> commercial companies providing support
> have not already moved in the direction
> of cloud based virtual builders (makes
> little sense to own a $10K server for
> occasional builds), but that is for their own customers.
> 
> If you mean architecture emulation, it can be very slow (although might be 
> acceptable), but the bigger problem may be licensing of the OS and the 
> compilers.  Last I knew AIX (where this started) is licensed software, and so 
> is XLC (if using the IBM compiler is required for kernel modules).

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

Re: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1

[Stephan Wiesand]

On Feb 6, 2017, at 18:34 , Ted Creedon wrote:

> why not use vm's for all non linux builds?

Because it will be just about as hard to find a system capable of hosting those 
VMs?

Most, if not all, Linux build slaves are VMs. So were the Windows ones.

Looks like it has largely been forgotten already that virtualizing anything not 
x86[_64] still isn't quite as trivial?

- Stephan

> 
> From: openafs-info-ad...@openafs.org  on 
> behalf of Pascal Salet 
> Sent: Monday, February 6, 2017 5:07 AM
> To: openafs-info@openafs.org
> Subject: Re: [OpenAFS] OpenAFS 1.6.20.1 on AIX 7.1
> 
>>> I would be very grateful for any advice on this matter.
>> 
>> Pascal,
>> 
>> To the best of my knowledge there has been no active development of
>> OpenAFS on any AIX release since January 2015.  At that time the AIX 6
>> build machine was removed from the build farm because the organization
>> that provided it for many years could no longer afford to do so.
>> 
>> It does not surprise me if over the last two years there has been
>> drift between OpenAFS and AIX; especially a new major release of AIX.
>> 
>> To answer your question, I am unaware of anyone that has installed
>> OpenAFS on AIX 7.1.
>> 
>> If you can provide more details on the failure, perhaps the community
>> can assist?
>> 
>> If the ability to use OpenAFS on AIX 7.1 is important to your
>> institution, perhaps it would be willing to provide a build host for use
>> by the developer community.
>> 
>> Jeffrey Altman
> 
> Jeffrey,
> 
> thank you very much for clarifying this.
> 
> I will inquire if the university can provide a build-host with AIX7 on
> our former PowerPC-server. This may or may not be feasible, according to
> administrative policies or product licenses.
> 
> The options used are
> ##
> ./configure -with-afs-sysname=rs_aix61 --enable-tivoli-tsm \\
> --enable-transarc-paths --disable-pam --includedir=/usr/include
> ##
> 
> After copying the binaries manually to /usr/afs/ and /usr/vice/etc/
> according to
> https://wiki.openafs.org/archive/HowToBuildOpenAFSFromSource/
> and executing rc.afs, the server freezes and reboots.
> 
> Pascal
> ___
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> ___
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info

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

Re: [OpenAFS] Check free space on AFS share before login

[Stephan Wiesand]

Hmm, it should work in any case. The message can be suppressed with the -noauth 
option for vos.

> On 2 Feb 2017, at 14:42, Richter, Michael <m.rich...@tu-berlin.de> wrote:
> 
> OK, did so. But: running "vos examine" in a shell works. If I put the same 
> line into a script and call this script on the same shell, it doesn't work 
> and gives me this error:
> 
> vsu_ClientInit: Could not get afs tokens, running unauthenticated.

-- 
Stephan Wiesand
DESY -DV-
Platanenallee 6
15738 Zeuthen, Germany



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

Re: [OpenAFS] Check free space on AFS share before login

[Stephan Wiesand]

> On 2 Feb 2017, at 12:43, Richter, Michael <m.rich...@tu-berlin.de> wrote:
> 
> Actually trying... The message comes to the user in LightDM. But I don't have 
> access to the AFS share of the user. I assume it's because pam_exec runs 
> before pam_afs_session:
> 
> -- /etc/pam.d/common-auth
> ~~~
> auth[success=3 default=ignore]  pam_krb5.so minimum_uid=1000
> auth[success=2 default=ignore]  pam_unix.so nullok_secure 
> try_first_pass
> 
> # auth against two domains via LDAP
> auth[success=1 default=ignore]  pam_sss.so use_first_pass 
> 
> authrequisite   pam_deny.so
> authrequiredpam_permit.so
> 
> # mount OwnCloud via webdav
> authoptionalpam_mount.so 
> 
> authoptionalpam_afs_session.so
> authoptionalpam_cap.so
> 
> # check free space in AFS
> authrequisite   pam_exec.so stdout seteuid /opt/check_free.sh
> ~~~
> 
> pam_afs_session is optional because there are users from another domain 
> without an AFS share. The check_free script checks this by itself. I've set 
> it to required too. But still the same. The script doesn't have access to the 
> AFS share. According to the manual of PAM there is no way to set an order.
> 
> Maybe this doesn't work because it's in the PAM process?
> 
> Any hints?

First, let me second Jonathan's objection to produce any output in the common 
pam stack. I'd really really put it into /etc/pam.d/lightdm (right after the 
@include common-auth).

And you don't need read access to the volume root in order to find out. Parsing 
the output of "vos examine -format" should be simple enough.
 
-- 
Stephan Wiesand
DESY -DV-
Platanenallee 6
15738 Zeuthen, Germany



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

Re: [OpenAFS] Check free space on AFS share before login

[Stephan Wiesand]

> On 2 Feb 2017, at 08:37, Richter, Michael <m.rich...@tu-berlin.de> wrote:
> 
> And the output will be shown in LightDM? I'll give that a try.

Better yet, something like this just works as one would hope:

echo WARNING: Your home directory is almost full.
echo Hit Enter to try to log in, but it may fail.
echo If it does, press Ctrl-Alt-F2, log in on the
echo text screen and free some space. Then log out
echo and press Alt-F7 to get back here.
exit 0

- Stephan

> -UrsprĂźngliche Nachricht-----
> Von: Stephan Wiesand [mailto:stephan.wies...@desy.de] 
> Gesendet: Mittwoch, 1. Februar 2017 13:08
> An: openafs-info@openafs.org
> Cc: Richter, Michael
> Betreff: Re: [OpenAFS] Check free space on AFS share before login
> 
> Hi Michael,
> 
>> On 1 Feb 2017, at 11:08, Richter, Michael <m.rich...@tu-berlin.de> wrote:
>> 
>> Hi,
>> we are using  OpenAFS for the home drive. /home/users is a symlink to the 
>> AFS path with all the home shares. The users home is for example 
>> /home/users/username.
>> 
>> The users only have 1 GB of space available in that share. It often happens 
>> that the quota is reached and they are unable to login. Ubuntu doesn’t 
>> give a meaningful error message. I think, Ubuntu doesn’t know what’s the 
>> problem, because it sees only “/” as mountpoint, which has enough free 
>> space available.
>> 
>> Is there a way to check the free space of the user on login and give the 
>> user a good error message if there is not enough free space available in the 
>> AFS share?
> 
> nice idea... I should probably implement that here. Something like
> 
> auth required pam_exec.so stdout /bin/check_home_space
> 
> should work well enough at least with lightdm. Just make the script print a 
> short message to stdout and exit 1 in the failure case.
> 
> Hth
>   Stephan
> 
>> 
>> I think about using pam-script to run a script that checks it but I can’t 
>> see a way to bring back that message to the user. Also pam-afs-session seems 
>> not to have some option for that. Is there some other solution?
>> 
>> Greetings
>> Michael

-- 
Stephan Wiesand
DESY -DV-
Platanenallee 6
15738 Zeuthen, Germany



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

Re: [OpenAFS] Check free space on AFS share before login

[Stephan Wiesand]

On Feb 1, 2017, at 15:42 , Jonathan Billings wrote:

> On Wed, Feb 01, 2017 at 01:07:30PM +0100, Stephan Wiesand wrote:
>> nice idea... I should probably implement that here. Something like
>> 
>> auth required pam_exec.so stdout /bin/check_home_space
>> 
>> should work well enough at least with lightdm. Just make the script
>> print a short message to stdout and exit 1 in the failure case. 
> 
> You really shouldn't have PAM generate standard output for successful
> logins. You will break things like SSH's SFTP.

I wasn't suggesting that, sorry for being unclear. I think this should
be added to the lightdm pam config only (will login through ssh or on
a VT even fail if there's no space left in ~ ?). And on success, the
check script clearly shouldn't print anything to stdout and exit 0.

> We do something like this on our RHEL7 workstations, and we have
> zenity pop up with a warning when they log in if their home
> directory's quota is greater than 95% full.  It runs as an script
> launched from a .desktop file in /etc/xdg/autostart/.

Makes sense, but I think none of this will work if ~ is already 100% full.
You'll just be thrown back to the display manager's login screen w/o a
meaningful error message (maybe that "your session was suspiciously short"
dialog, but I'm not sure that's still present in EL7).

> For console logins, I'd probably use a script in /etc/profile.d/ that
> detected that it was a console login and generate all the output to
> stderr, just in case.  But considering that people don't read the MOTD
> I doubt they'd read warnings like that.

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] Check free space on AFS share before login

[Stephan Wiesand]

> On 1 Feb 2017, at 13:15, Harald Barth <h...@kth.se> wrote:
> 
> I think the problem is well known and what one would need to do is to
> make (at every travesal of an AFS mount point) the OS aware of that
> the AFS volume in question is a seperate "device". Then make the
> statfs syscall on that path return the quota info from AFS. This has
> of course to happen dynamically as you make your way through the AFS
> space.
> 
> This would make every volume look as a seperate file system. There
> are pros and cons in that approach.

I think this is what the in-kernel client does. It's probably the only
way to make AFS compatible with Linux's firm beliefs regarding filesystems
(like that there's only one path to an object in them).

> I think noone has written the code (for Unix/Linux) yet, but the

Andrew Deason whipped up some proof of concept code a while ago. I have
no idea how close this is to something one would consider using, and it
wasn't pursued further. But it's still available:

https://gerrit.openafs.org/#/q/status:open+project:openafs+branch:openafs-stable-1_6_x+topic:linux-mtpt-bindmount

If anyone wants to take off from there...

> Windows client might do this, but I'm by no means someone who knows
> something about AFS on Windows ;-)
> 
> At our site, so far, is has been cheaper to multiply all quotas by 2
> whenever the problem arose again.

-- 
Stephan Wiesand
DESY -DV-
Platanenallee 6
15738 Zeuthen, Germany



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

Re: [OpenAFS] Check free space on AFS share before login

[Stephan Wiesand]

Hi Michael,

> On 1 Feb 2017, at 11:08, Richter, Michael <m.rich...@tu-berlin.de> wrote:
> 
> Hi,
> we are using  OpenAFS for the home drive. /home/users is a symlink to the AFS 
> path with all the home shares. The users home is for example 
> /home/users/username.
>  
> The users only have 1 GB of space available in that share. It often happens 
> that the quota is reached and they are unable to login. Ubuntu doesn’t give a 
> meaningful error message. I think, Ubuntu doesn’t know what’s the problem, 
> because it sees only “/” as mountpoint, which has enough free space available.
>  
> Is there a way to check the free space of the user on login and give the user 
> a good error message if there is not enough free space available in the AFS 
> share?

nice idea... I should probably implement that here. Something like

auth required pam_exec.so stdout /bin/check_home_space

should work well enough at least with lightdm. Just make the script print a 
short message to stdout and exit 1 in the failure case.

Hth
Stephan

>  
> I think about using pam-script to run a script that checks it but I can’t see 
> a way to bring back that message to the user. Also pam-afs-session seems not 
> to have some option for that. Is there some other solution?
>  
> Greetings
> Michael

-- 
Stephan Wiesand
DESY -DV-
Platanenallee 6
15738 Zeuthen, Germany



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

Re: [OpenAFS] New kmod-openafs rpm

[Stephan Wiesand]

Hello Erik,

> On 14 Nov 2016, at 21:42, Gough, Erik S  wrote:
> 
> We recently updated our RHEL6 systems to kernel
> 2.6.32-642.6.2.el6.x86_64 to address the dirty cow vulnerability.  Are
> there plans to release a new afs kernel module for this kernel version?
> The latest I could find was
> kmod-openafs-1.6.18.3-1.2.6.32_642.6.1.el6.x86_64.rpm.

The 1.6.18.3 binary trees were updated with the latest kernel modules. Sorry 
for the delay.

- Stephan


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

[OpenAFS] Re: [OpenAFS-announce] First OpenAFS 1.6.19 release candidate available

[Stephan Wiesand]

Binaries for RHEL5/6 & clones were uploaded and are available through the URLs 
specified in the announcement.

If you can, please test.

On Oct 20, 2016, at 19:46 , Stephan Wiesand wrote:

> The OpenAFS Release Team is pleased to announce that the first 1.6.19
> release candidate, 1.6.19pre1, is now available.
> 
> Source files and available binaries can be accessed via the web at:
> 
>  http://dl.openafs.org/dl/candidate/1.6.19pre1/
> 
> or via AFS at:
> 
>  UNIX: /afs/grand.central.org/software/openafs/candidate/1.6.19pre1/
>  UNC: \\afs\grand.central.org\software\openafs\candidate\1.6.19pre1\
> 
> There are no binaries yet. Those will be uploaded as they become available.
> 
> Besides other bug fixes and minor improvements, this prerelease includes
> fixes that prevent cases where a database write could be lost or an old
> version of the database be used instead of the latest version.
> 
> For the full list of user visible changes foreseen for 1.6.19, please see
> 
>  http://dl.openafs.org/dl/candidate/1.6.19pre1/RELNOTES-1.6.19pre1
> 
> 
> Please assist us by deploying this prerelease and providing positive or
> negative feedback. Bug reports should be filed to openafs-b...@openafs.org.
> Reports of success should be sent to openafs-info@openafs.org.
> 
> Stephan Wiesand, 1.6 Branch Release Manager
> on behalf of the OpenAFS Release Team
> 

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

Re: [OpenAFS] Mac OS sierra support - any news?

[Stephan Wiesand]

Hi,

> On 14 Oct 2016, at 14:28, Elias Michael Ruettinger  
> wrote:
> 
> Hi,
> 
> I just wanted to ask, if there is any news on a mac os sierra open afs 
> release.
> Since the last update, it isn’t supported anymore. :-( 

no patches were offered yet.

Auristor offers a sierra client for download, but I haven't tried it and can't 
tell you anything about it.

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

Re: [OpenAFS] /afs is empty

[Stephan Wiesand]

> On 7 Oct 2016, at 15:48, Andreas Ladanyi  wrote:
> 
> my problem on one afs client is that /afs is empty.

Is AFS actually mounted on /afs ?

- Stephan

> Ubuntu 12.04: 3.2.0-109-generic, OpenAFS 1.6.18.3-1 from PPA
> 
> openafs-client restart doesnt help.
> 
> ps ax | grep afsd:
> 
> 1232 pts/0S+ 0:00 grep afsd
> 27942 ?Ss 0:00 /sbin/afsd -afsdb -fakestat
> 27944 ?S  0:00 [afsd]
> 
> 
> lsmod:
> 
> Module  Size  Used by
> openafs   798728  2
> 
> 
> vos listvldb / listvol:
> 
> lists the volumes
> 
> 
> tokens:
> 
> shows me my afs tokens after kinit / aklog:
> 
> 
> pts listentries:
> 
> shows me the afs users
> 
> 
> /var/log/syslog shows messages from the kernel which belongs to afs:
> 
> afs: WARM shutting down of: vcaches... BkG... CB... afs... CTrunc... AFSDB... 
> RxEvent... UnmaskRxkSignals... RxListener... ALL allocated tables... done
> 
> enabling dynamically allocated vcaches
> Starting AFS cache scan...found 902 non-empty cache files (11%).
> 
> afs: WARM shutting down of: vcaches... BkG... CB... afs... CTrunc... AFSDB... 
> RxEvent... UnmaskRxkSignals... RxListener... ALL allocated tables... done
> 
> enabling dynamically allocated vcaches
> Starting AFS cache scan...found 870 non-empty cache files (11%).
> 
> 
> ls /var/cache/openafs/:
> 
> CacheItems  CellItems  D0  D1  D2  D3  VolumeItems
> 
> 
> Any ideas for this mysterious behavior ?
> 
> 
> regards,
> 
> Andreas

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

Re: [OpenAFS] Number of files in an OpenAFS volume...

[Stephan Wiesand]

On Jul 4, 2016, at 16:27 , Jeffrey Altman wrote:

> The directory size restrictions are one of the reasons that /afs cannot
> be used for a large number of applications.  The AuriStor File System
> implements a new directory format which is understood only by AuriStor
> clients.  This format permits directories to grow to store an unlimited
> number of entries.

Another such restriction is that AFS won't allow hard links across directories, 
even if they're in the same volume. Does AuriStor lift that restriction too?

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] openafs client crashs after ubuntu kernel update

[Stephan Wiesand]

On Apr 7, 2016, at 19:03 , Jeffrey Altman wrote:

> On 4/7/2016 3:08 AM, Andreas Ladanyi wrote:
>> Short feedback:
>> The workaround with afs_GenericStoreProc works for the first tests.
>> Colleges told me that the workaround with afs_GenericStoreProc seems to
>> result in slower read/write operations.
> 
> 
> The performance of OpenAFS returning to the use of afs_GenericStoreProc
> is equivalent to that of the 1.4.x release series.
> 
> Slide 19 of
> 
>  http://conferences.inf.ed.ac.uk/eakc2012/slides/AFS_Performance.pdf
> 
> will show you the difference in the performance curve.  The blue line
> will be equivalent to the performance of OpenAFS 1.6.17 on the Linux 4.3
> kernel and the green line will be the performance of the upcoming 1.6.18
> on the Linux 4.4 and later kernels.
> 
> The AuriStorFS clients for Linux 4.4 through 4.6.rc1 do not suffer this
> performance degradation.

Does Auristor provide Ubuntu LTS client packages? And what's the price tag?



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

Re: [OpenAFS] permission to run 'fs examine'

[Stephan Wiesand]

In the stable release series for Unix it actually happened mid 2013, with the 
1.6.4 release. The relevant passage in the release notes was:

* Allow the fileserver to return volume data like quota or free space,
  which is available publicly elsewhere, without the additional access
  check for read permissions on a volume's root directory the fileserver
  performed before.

We should probably adapt the fs_examine manpage. Any volunteers?

- Stephan

On Mar 17, 2016, at 22:20 , Jeffrey Altman wrote:

> This change occurred in 2012.  See http://gerrit.openafs.org/7705
> 
> The "fs examine" command causes the cache manager to issue a
> RXAFS_GetVolumeStatus RPC.  The returned data is publicly accessible via
> the volserver RPCs so there was no benefit to locking it down via the
> fileserver RPCs.
> 
> The Windows operating system requires knowledge of the volume size, free
> space, quota and other statistics independent of the access rights of
> the user processes.  See the commit message for further details.
> 
> Jeffrey Altman
> 
> 
> On 3/17/2016 3:43 PM, Richard Brittain wrote:
>> I discovered an apparent change in the access control on "fs examine"
>> recently.  The docs say you need 'r' access on the root of the volume
>> for this to work, and that definitely used to work.  We use this inside
>> a wrapper script for more convenient quota checking, and I was used to
>> getting the permission errors, but not any more.
>> 
>> Now it seems to work all the time regardless of tokens or volume ACL,
>> from clients on Linux, Mac and Windows.  Our servers are a mishmash of
>> versions.  The DBs are 1.6.14.1 and 1.6.5, and the file servers 1.6.9
>> and 1.6.14.1.  If this access control is a function of the DB servers,
>> then the timing of our upgrade to 1.6.14.1 might be consistent with when
>> this started.
>> 
>> PRIVILEGE REQUIRED
>>   The issuer must have the "r" (read) permission on the ACL of the root
>> directory of the volume that
>>   houses the file or directory named by the -path argument, and "l"
>> (list) permission on the ACL of each
>>   directory that precedes it in the pathname.
>> 
>> 
>> Richard
> 

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] compile fails kernel version 4.4.0-1-default

[Stephan Wiesand]

On Mar 8, 2016, at 17:29 , Michael Laß wrote:

> Am Dienstag, den 08.03.2016, 16:47 +0100 schrieb mdrslmr:
>> I created a patch from what you suggested above.
>> 
>> [...]
>> 
>> I did all of that on top of AUR-openafs-linux-4.4 which was provided by
>> Bevan, the openafs archlinux packager.
>> 
>> The patch I actually used is attached below.
> 
> That patch is not complete (it's missing the configuration flag).

Indeed. The complete patch as proposed would look like 
http://gerrit.openafs.org/#/c/12217/ . Chas already objected to making it 
possible to reactivate afs_linux_storeproc with a configure switch, and he's 
probably right, but please feel free to comment on that change.

> I
> will update the corresponding git branch for the openafs package soon
> to allow testing. But since LINUX_USE_SPLICE wasn't defined your patch
> should have worked, too.

Right.

> Was the error code 32 returned from git or did the kernel log message
> change accordingly? Does your log again show a lost file server
> connection? And have files been corrupted or just the checkout aborted?


Good questions.

Sigh. Looks like there's more to it.

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] compile fails kernel version 4.4.0-1-default

[Stephan Wiesand]

> On 08 Mar 2016, at 12:02, Chas Williams <3ch...@gmail.com> wrote:
> 
> On Tue, 2016-03-08 at 10:16 +0100, Denis Lohner wrote:
>> Am 08.03.2016 um 04:37 schrieb Benjamin Kaduk:
>>>>> There
>>>>>>> are many call paths in the cache manager that end up at this function,
>>>>>>> most of which are not prepared to properly handle an ERESTARTSYS
>>>>>>> return.
>>>>>>> Since this status can be returned after some data has already been
>>>>>>> written, the correct behavior upon receiving it is far from clear ...
>>>>>>> a
>>>>>>> path towards a client free of this vector for data corruption may
>>>>>>> involve
>>>>>>> avoiding the dependence on splice_from_pipe_next() in preference to
>>>>>>> adopting all call sites to handle the ERSTARTSYS case.
>>>>> 
>>>>> For the 1.6 release, this seems the best choice of action.  The "real"
>>>>> fix would likely be difficult to completely test in a timely fashion.
>>> That only helps if we know what the replacement would be...I am not a
>>> linux VFS expert and do not have any ideas right now.
>> 
>> 
>> I am not a kernel/driver developer nor a file system developer. So
>> please forgive, if the following makes no sense at all.
>> 
>> As far as I understand the issue and the openafs sources, the problem
>> arises as afs_linux_storeproc uses the splice api that can return
>> ERESTARTSYS as of kernel version 4.4.
>> A quick search in the NEWS file and git logs suggests that
>> afs_linux_storeproc was introduced in OpenAFS 1.5.69 (2010-01-19) as a
>> performance improvement:
>> " Linux
>> 
>>* Use splice to speed up storing files."
>> 
>> The original behaviour which uses seperate reads/writes instead of
>> splice and that is (still) used on non-linux systems remained in
>> afs_GenericStoreProc in src/afs/afs_fetchstore.c .
>> 
>> So my question is: Is it possible to rereplace afs_linux_storeproc with
>> afs_GenericStoreProc on linux kernel versions >=4.4  as a temporary
>> solution to the issue either in the openafs sources or as a distribution
>> specific patch, trading some performance for data integrity?
> 
> That would be the first thing I tried.  This code was brought into the
> tree on commit 34ffc9cd7d7eed62229704ad0e1d327f076ea7b6.  There doesn't seem
> to be any additional side effects, so simply not using afs_linux_storeproc 
> should
> still work.

So we'd simply do something like this


diff --git a/src/afs/afs_fetchstore.c b/src/afs/afs_fetchstore.c
index f65f40c..2630209 100644
--- a/src/afs/afs_fetchstore.c
+++ b/src/afs/afs_fetchstore.c
@@ -326,7 +326,7 @@ struct storeOps rxfs_storeUfsOps = {
 .padd =rxfs_storePadd,
 .close =   rxfs_storeClose,
 .destroy = rxfs_storeDestroy,
-#ifdef AFS_LINUX26_ENV
+#if defined(AFS_LINUX26_ENV) && defined(LINUX_USE_SPLICE)
 .storeproc = afs_linux_storeproc
 #else
 .storeproc = afs_GenericStoreProc


and add a configure test defaulting to off?


-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] compile fails kernel version 4.4.0-1-default

[Stephan Wiesand]

On Mar 2, 2016, at 20:07 , Ted Creedon wrote:

> I would have too think that after all this time whatever license there is has 
> been overtaken by events.
> 
> What would IBM do - sue a penniless entity? IBM is not being damaged, in fact 
> its users running IBM PCs and other hardware have benefited from the free 
> support.
> 
> I look at any agreement as a "bait and switch" that enabled IBM to relieve 
> itself from the cost of supporting a defective product.
> 
> In fact IBM licensed a "Pig in a poke".
> 
> Take the ball and run with it.

That easy, yes. Can you please simply take the ball, run a short distance, and 
provide us with a client which works on Linux 4.4+ ?

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

Re: [OpenAFS] Start of afsd fails with "afsd: Error -1 in basic initialization."

[Stephan Wiesand]

On Feb 11, 2016, at 09:50 , Volkmar Glauche wrote:

> also:
> 
> Zitat von Karl-Philipp Richter <rich...@richtercloud.de>:
> 
> 
>> ... There're no system packages installed and OpenAFS and
>> kerberos (in case that matters) are installed from source (OpenAFS
>> openafs-devel-1_5_76-4781-ged52d65) and `lsmod | grep afs` shows:
> 
> Why aren't you using the OpenAFS/Kerberos packages that are shipped with 
> Ubuntu? Current stable Linux releases are 1.6.x. OpenAFS 1.5.x is an older 
> development branch, and its associated libafs kernel module will most likely 
> fail to build on modern kernels. If you really need to build your own AFS, 
> you should go for the latest 1.6 release that supports your kernel.


Note that the last kernel supported is 4.3 . We know we're broken on 4.4 . Not 
sure about 4.3.3 and what Ubuntu may already have backported.

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] Release of MacOS 10 client

[Stephan Wiesand]

Hi Matthias,

http://gerrit.openafs.org/12176 contains a link 
http://download.sinenomine.net/openafs/bins/ . I can't find all the announced 
items there though.

IIRC there was some discussion in the past on whether it's appropriate to link 
to third party repositories from the web site. Maybe it should be revived. How 
about linking to the Auristor installers as well?

Stephan

> On 26 Jan 2016, at 11:29, Matthias Schroeder  
> wrote:
> 
> Hi Margarete,
> 
> that sounds really good. Is the package, code or documentation already 
> available somewhere? I am ready to give it a spin.
> 
> Matthias
> 
>> On 22 Jan 2016, at 19:51, E. Margarete Ziemer  
>> wrote:
>> 
>> I had submitted the email below to openAFS-announce two days ago, where it 
>> “is awaiting moderator approval before being published”.  To keep moving 
>> forward, I am repeat-posting here now.
>> 
>> From: Margarete Ziemer 
>> Date: Wednesday, January 20, 2016 at 12:16 PM
>> To: "openafs-annou...@openafs.org" 
>> Subject: Release of MacOS 10 client
>> 
>>> SNA is happy to release our MacOS 10 AFS Client to OpenAFS.org. 
>>> Specifically, the donation entails: 1) changes to packaging, 2) binaries, 
>>> ie.SNA-signed install package files, 3) documentation of build-process for 
>>> packages.  The versions of the packages and OpenAFS are OpenAFS 1.6.15, 
>>> OpenAFS 1.6.16, Mac OSX 10.10 (Yosemite), and Mac OSX 10.11 (El Capitan).  
>>> Please note that, at present, this code is considered a pre-release.  Three 
>>> of SNA’s customers have been beta testing it with positive results, and 
>>> community testing and use is sought for soonest for bug findings and their 
>>> resolutions. This release will be SNA-certified, because the OpenAFS 
>>> Foundation is not yet capable of signing; as soon as the Foundation will be 
>>> ready to do so, SNA will make available the then-current and future 
>>> releases to the Foundation for the Foundation's signature and (re-)release 
>>> to the community.  
>> 
>> Sincerely, Margarete Ziemer, Sine Nomine Associates, Inc.
> 

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

Re: [OpenAFS] kmod-openafs package in RHEL6 repos breaks updates

[Stephan Wiesand]

Hi Berthold, long time no see...

On Jan 8, 2016, at 09:45 , Berthold Cogel wrote:

> Somehow a kmod-openafs package got in the RHEL6 x86_64 repos that breaks
> the update and installation process. I found this package in the repos
> for 1.6.14..1.6.16
> 
> It's a module that seems to be build for a kernel 3.18, which is not
> available for RHEL6. At least not through the official channels:
> 
> kmod-openafs-1.6.16-1.3.18.21_16.el6.x86_64


sigh. RHEL + external kernel modules is so broken, thanks to the Fedora 
religion :-(

The repositories (packages *and* metadata) are just rsynced from the place 
where Stephen provides them. Omitting select packages and rebuilding the 
metadata is certainly doable but yet more work for which there is no manpower 
available.

I'll see what I can do but please don't hold your breath...

Thanks for the report. At least it proves that some are still using the 
repository.

NB what are you using (or going to use) for EL7?

Stephan

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

Re: [OpenAFS] Repeated lost contact with servers - only at one location

[Stephan Wiesand]

On Dec 15, 2015, at 14:15 , Jan Iven wrote:

> On 12/15/2015 11:53 AM, Orel Gueta wrote:
>> Hi Ben,
>> 
>> Thanks for the tip, however if I do "fs checkservers -cell cern.ch
>> ", I get the same result. Perhaps because
>> /etc/openafs/ThisCell is set to CERN.CH ?
> 
> yes.
> 
>> Either way, regardless if I specify the cell or not, I see a few servers
>> down, at cern.ch  and in other places.
> 
> I would suspect some network thing. Perhaps some stateful firewall is timing 
> out too fast for slow servers (or a high-latency network) to reply in time.

Possibly, but I think Ubuntu still defaults to iptables disabled. It could be a 
NAT issue too, but that should break ping as well. Maybe it's something with 
the MTU or fragmented UDP packets. The "-rxmaxfrags" and "-rxmaxmtu" arguments 
to afsd may be worthwile playing with.

I've also seen servers on a "friendly" site blacklisting my clients in the past 
just due to an "ls -R" and some latency... but that was a while ago.

Regards,
Stephan

> You might want to use "rxdebug afs263.cern.ch 7000 -version" as a simple 
> ping-like test (which nevertheless uses the AFS protocol, unlike real "ping). 
> If that also fails, you have simplified the test case.
> You could then use "wireshark" to get a network-level packet trace (you would 
> expect to note missing packets, i.e client repeatedly sending something to 
> UDP/7000 but not getting an answer).
> And perhaps see whether your new Ubuntu comes with a newer firewall, and try 
> to configure that in "logging" mode, then check whether it happily ditches 
> those reply packets from the server..
> 
> By the way, the packet-eating device might also be your local home router. 
> Perhaps old Ubuntu configured it to open some ports via UPNP, and the new 
> release no longer does this.
> 
> Cheers
> jan
> 
>> Orel
>> 
>> On 14 December 2015 at 23:38, Benjamin Kaduk > > wrote:
>> 
>>On Mon, 14 Dec 2015, Orel Gueta wrote:
>> 
>>> - fs checkservers reports a few servers down (likeafs263.cern.ch 
>> ), but I
>>> can ping them.
>> 
>>A quick note -- fs checkservers only checks for the local cell by
>>default
>>-- try "fs checkservers -cell cern.ch " to check a
>>foreign cell.
>> 
>> 
>>-Ben

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

Re: [OpenAFS] containers / AFS / Ubuntu - stopped working

[Stephan Wiesand]

Hi Neil,

thanks for the report, but I'm afraid I'm not getting it.

On Nov 27, 2015, at 13:42 , Neil Davies wrote:

> I’ve been successfully running containers for several years. 
> initially using lxc and now docker, inside machines where there was: 
>   an outer AFS service; 
>   accessed by the processes inside the container.
> 
> It worked fine (we are happy with the UID/token issue) until a recent upgrade.

What was upgraded?

> After this upgrade I am no longer able, in the container, able to push tokens 
> into the kernel - it gives a pioctl.

What does "push tokens into the kernel" mean? What's the error? "pioctl failed"?

> That was a couple of weeks ago it broke, I backed out the change

What did you back out?

Thanks
Stephan

> and I’m going to try to isolate the issue - before I do I was wondering if 
> there was anyone else on the list that has had this experience?

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] make fails on linux 4.3.0-1

[Stephan Wiesand]

On Nov 13, 2015, at 18:07 , Benjamin Kaduk wrote:

> On Fri, 13 Nov 2015, Ted Creedon wrote:
> 
>> or opensuse tumbleweed
>> 
>> make[3]: Entering directory '/data/openafs-1.6.15/src/gtx'

To make it clear, this is not at all about the linux kernel version. It's about 
backward incompatibilities of ncurses.

> gtx is hardly an essential part of openafs; I would recommend that someone
> backports commit 5d53c12b95c6ffac6c00e4fec6138a51b6185dd7 and you can just
> disable building gtx.

Thanks to Mike for doing this. http://gerrit.openafs.org/#change,12095 was 
merged and will thus be part of 1.6.16pre1. It is sad though that we sacrifice 
scout(1) and afsmonitor(1) this way, rather than fix gtx. Amy volunteers?

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

Re: [OpenAFS] Anyone still use the old 'vspace' script?

[Stephan Wiesand]

Garance,

On Oct 26, 2015, at 19:12 , Garance A Drosehn wrote:

> I'm also
> (currently) stuck with very old versions of OpenAFS on all our AFS servers.

why? What kept you from at least using current versions on new servers 
replacing older ones?

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

Re: [OpenAFS] Linux find command inconsistent

[Stephan Wiesand]

On Sep 15, 2015, at 15:46 , John Sopko wrote:

> I run a monthly report to find all mount points and volumes using the
> linux find command. I used to run this on Red Hat 5 for years. I moved
> the script to Red Hat 6 and found after testing that on Red Hat 6 and
> 7 and Ubuntu 14.04 the find command give inconsistent results and does
> not find nearly as many files as Red Hat 5 does.
> 
> I can copy the Red Hat 5 find binary to Red Hat 6 which executes ok
> but still has a problem.

The same "problem"?

> I tried serveral client machines.
> 
> For example on Red Hat 5 I run a command to find all directories and count 
> them:
> 
> % lsb_release -d
> Description:Red Hat Enterprise Linux Client release 5.11 (Tikanga)
> 
> |sopko@kramer:56% pwd
> /afs/cs.unc.edu/project
> 
> % find . -noleaf -type d | wc -l
> 343403
> 
> On Red Hat 6 I get:
> 
> % lsb_release -d
> Description:Red Hat Enterprise Linux Workstation release 6.7 (Santiago)
> 
> |sopko@lark1:81% pwd
> /afs/cs.unc.edu/project
> 
> |sopko@lark1:82% find . -noleaf -type d | wc -l
> find: `./par/Last_Backup/Last_Backup': No such device

This suggests the client is refusing to recurse into the very same backup 
volume (I assume "par" is a volume root and "par/Last_Backup" is a mount point 
for the corresponding .backup volume?).

> 38763
> 
> I also like to use the find command to set afs acl's on directories
> but can not trust it to work.
> 
> I am running 1.6.11 on the servers, 1.6.9 on the rhel5 client and
> 1.6.11 on the rhel6 client and 1.6.14 on Ubuntu. Can anyone shed any
> light on what is going on?


See above. The RHEL6/Ubuntu result is likely to be the better one.

In any case, find and AFS have never been friends and probably can't be.

OpenAFS releases since 1.6.10 include the volscan(8) utility. It will not be 
quite as trivial to use for your purposes since you need to run it on volumes 
and stitch paths as seen by clients together yourself, but for just that reason 
results will be meaningful - for example in the presence of circular mounts. 
And it's much more efficient too.

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

[OpenAFS] BPW slide decks?

[Stephan Wiesand]

I was unable to participate in this week's workshop. But of course I'm curious. 
Any chance the slide decks (I guess there are no recordings?) could be made 
available somewhere?

-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] CellServDB priority of entries

[Stephan Wiesand]

 On 11 Aug 2015, at 09:02, Andreas Ladanyi andreas.lada...@kit.edu wrote:
 
 i dont know if i remember correctly, but think i red something about
 priorities for DB server entries listed in the file CellServDB in the
 past. I couldnt find something in the manpage cellservdb. I think the
 priority is given by the ip adress, isnt it ?

Right. See fs_getserverprefs(1)

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

Re: [OpenAFS] kmod rpm versions?

[Stephan Wiesand]

 On 07 Aug 2015, at 16:04, John Hascall j...@iastate.edu wrote:
 
 I am a BSD refugee who is new to AFS on RHEL, so please excuse this question 
 if it is dumb.
 
 I installed a new RHEL6 box and the kernel version is:
 
 2.6.32-573.el6.x86_64
 
 so the kmod rpm refuses to install:
 
 (2/2): kmod-openafs-1.6.13-1.2.6.32_504.30.3.el6.x86_64. | 320 kB 00:00
 
 Total   927 kB/s |  29 MB 00:32
 Running rpm_check_debug
 Running Transaction Test
 
 
 Transaction Check Error:
   package kernel-2.6.32-573.el6.x86_64 (which is newer than 
 kernel-2.6.32-504.30.3.el6.x86_64) is already installed
 
 How do I proceed from here?

The kernel module for the latest EL6 kernel hasn't been built yet, presumably 
because that kernel is not yet available in the ordinary CentOS updates channel.

To build yourself, make sure these are installed (probably a bit more than you 
need):

rpm-build
make
pam-devel
gcc
flex
bison
ncurses-devel
perl
redhat-rpm-config
autoconf
automake
fuse-devel
krb5-devel

Then rebuild the srpm:

rpmbuild --rebuild --define build_modules 1 --define kernvers 
2.6.32-573.el6.x86_64 
http://www.openafs.org/dl/openafs/1.6.13/openafs-1.6.13-1.src.rpm

- Stephan

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

Re: [OpenAFS] backup: Volume name is illegal ; Failed to evaluate volume set

[Stephan Wiesand]

Hi,

 On 04 Aug 2015, at 11:29, Gunnar Krull gkli...@cs.uni-goettingen.de wrote:
 
 Yesterday I upgraded the OpenAFS packages on our servers running Debian 
 Wheezy from 1.6.9-1~bpo70+1 to 1.6.13-1 (compiled and build from sid source).
 
 Since then the backup command stopped working with an error, e.g.:
 
 # /usr/sbin/backup dump -volumeset coursebackup -dump /aug
 Starting dump of volume set 'coursebackup' (dump level '/aug')
 backup: Volume name is illegal ; Failed to evaluate volume set
 
 The backup volume set looks like this:
 
 backup listv
 Volume set coursebackup:
Entry   1: server .*, partition .*, volumes: course\..*\.backup
 
 Everything else seemed to be okay, no problems with fileservers and volume 
 servers.
 Now, I've gone back to the old version, installing the 1.6.9 packages. With 
 this version the backup is working again.
 
 Any idea what could cause the error in the latest version?

it's a known regression introduced with commit 
63087b338e3d0fbbb26ee183a039052bf07aaaec  in 1.6.13. An alternative solution is 
being worked on in http://gerrit.openafs.org/1196{7,8,9} and should be released 
soon.

The changes will need some tweaking when applied to 1.6.

Thanks for the report.

- Stephan

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

[OpenAFS] additional binaries for OpenAFS 1.6.13 available

[Stephan Wiesand]

In addition to those already announced, binaries for RHEL7, Fedora and
current openSUSE/SLE distributions are available from:

  http://www.openafs.org/dl/openafs/1.6.13/onetime/

or the corresponding path in AFS:

  /afs/grand.central.org/software/openafs/1.6.13/onetime
 \\afs\grand.central.org\software\openafs\1.6.13\onetime

These packages won't be updated. In particular, no modules for new kernels will
be added. Such updates will be available from the usual downstream repositories
soon.

Thanks are due to Ben Kaduk for the FreeBSD builds, Christof Hanke for the 
openSUSE/SLE and Solaris ones and Stephen Quinney for all RHEL/Fedora packages.

Stephan Wiesand,
for the OpenAFS Release Team

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

Re: [OpenAFS] additional binaries for OpenAFS 1.6.13 available

[Stephan Wiesand]

No, just systemd unit files where appropriate. Sorry for that.

On Jul 30, 2015, at 20:10 , Ted Creedon wrote:

 Any systemd scripts?
 
 
 From: openafs-info-ad...@openafs.org openafs-info-ad...@openafs.org on 
 behalf of Stephan Wiesand stephan.wies...@desy.de
 Sent: Thursday, July 30, 2015 7:01 AM
 To: openafs-info@openafs.org
 Subject: [OpenAFS] additional binaries for OpenAFS 1.6.13 available
 
 In addition to those already announced, binaries for RHEL7, Fedora and
 current openSUSE/SLE distributions are available from:
 
  http://www.openafs.org/dl/openafs/1.6.13/onetime/
 
 or the corresponding path in AFS:
 
  /afs/grand.central.org/software/openafs/1.6.13/onetime
 \\afs\grand.central.org\software\openafs\1.6.13\onetime
 
 These packages won't be updated. In particular, no modules for new kernels 
 will
 be added. Such updates will be available from the usual downstream 
 repositories
 soon.
 
 Thanks are due to Ben Kaduk for the FreeBSD builds, Christof Hanke for the 
 openSUSE/SLE and Solaris ones and Stephen Quinney for all RHEL/Fedora 
 packages.
 
 Stephan Wiesand,
 for the OpenAFS Release Team

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

Re: [OpenAFS] afsd: Error calling AFSOP_CACHEINODE: not configured

[Stephan Wiesand]

On Jul 1, 2015, at 11:55 , Andreas Ladanyi wrote:

 Hi,
 
 openafs 1.6.11.1 / Centos 7
 SELinux=permissive
 iptables is empty
 
 bos server runs by systemd script.
 
 bos status server:
 
 Instance vlserver, currently running normally.
 Instance ptserver, currently running normally.
 Instance dafs, currently running normally.
 Auxiliary status is: file server running.
 
 
 systemctl status openafs-client.service
 openafs-client.service - OpenAFS Client Service
   Loaded: loaded (/usr/lib/systemd/system/openafs-client.service; disabled)
   Active: failed (Result: exit-code) since Wed 2015-07-01 11:17:34
 CEST; 2min 59s ago
  Process: 3377 ExecStart=/usr/vice/etc/afsd $AFSD_ARGS (code=exited,
 status=1/FAILURE)
  Process: 3375 ExecStartPre=/sbin/modprobe openafs (code=exited,
 status=0/SUCCESS)
  Process: 3373 ExecStartPre=/bin/chmod 0644 /usr/vice/etc/CellServDB
 (code=exited, status=0/SUCCESS)
  Process: 3371 ExecStartPre=/bin/sed -n w/usr/vice/etc/CellServDB
 /usr/vice/etc/CellServDB.local /usr/vice/etc/CellServDB.dist
 (code=exited, status=0/SUCCESS)
 
 Jul 01 11:17:34 i44fs1.info.uni-karlsruhe.de systemd[1]: Starting
 OpenAFS Client Service...
 Jul 01 11:17:34 i44fs1.info.uni-karlsruhe.de afsd[3377]: afsd: Error
 calling AFSOP_CACHEINODE: not configured
 Jul 01 11:17:34 i44fs1.info.uni-karlsruhe.de systemd[1]:
 openafs-client.service: control process exited, code=exited status=1
 Jul 01 11:17:34 i44fs1.info.uni-karlsruhe.de systemd[1]: Failed to start
 OpenAFS Client Service.
 Jul 01 11:17:34 i44fs1.info.uni-karlsruhe.de systemd[1]: Unit
 openafs-client.service entered failed state.
 
 /etc/sysconfig/openafs:
 # OpenAFS Client Configuration
 #AFSD_ARGS=-dynroot -fakestat -afsdb
 AFSD_ARGS=-fakestat -afsdb

What's wrong with dynroot?

Do you have the root.afs and root.cell volumes in place?

Stephan

 # OpenAFS Server Configuration
 BOSSERVER_ARGS=
 
 /usr/vice/etc/cacheinfo:
 /afs:/usr/vice/cache:10
 
 
 
 regards,
 Andreas
 

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

Re: [OpenAFS] Uninstall OpenAFS after make install

[Stephan Wiesand]

.x86_64-SP/afs_chunk.o
  CC [M]  
 /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc20.x86_64-SP/afs_conn.o
  CC [M]  
 /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc20.x86_64-SP/afs_daemons.o
 /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc20.x86_64-SP/afs_daemons.c:
  In function ‘afs_CheckRootVolume’:
 /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc20.x86_64-SP/afs_daemons.c:403:24:
  error: ‘struct dentry’ has no member named ‘d_alias’
   list_del_init(dp-d_alias);
^
 /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc20.x86_64-SP/afs_daemons.c:404:19:
  error: ‘struct dentry’ has no member named ‘d_alias’
   list_add(dp-d_alias, (AFSTOV(vcp)-i_dentry));
   ^
 /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc20.x86_64-SP/afs_daemons.c:404:7:
  warning: passing argument 2 of ‘list_add’ from incompatible pointer type 
 [enabled by default]
   list_add(dp-d_alias, (AFSTOV(vcp)-i_dentry));
   ^
 In file included from include/linux/wait.h:6:0,
 from 
 /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/afs/sysincludes.h:124,
 from 
 /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc20.x86_64-SP/afs_daemons.c:19:
 include/linux/list.h:61:20: note: expected ‘struct list_head *’ but argument 
 is of type ‘struct hlist_head *’
 static inline void list_add(struct list_head *new, struct list_head *head)
^
 make[4]: *** 
 [/var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc20.x86_64-SP/afs_daemons.o]
  Error 1
 make[3]: *** 
 [_module_/var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc20.x86_64-SP]
  Error 2
 make[3]: Leaving directory `/usr/src/kernels/3.19.8-100.fc20.x86_64'
 FAILURE: make exit code 2
 make[2]: *** [openafs.ko] Error 1
 make[2]: Leaving directory 
 `/var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc20.x86_64-SP'
 make[1]: *** [linux_compdirs] Error 2
 make[1]: Leaving directory 
 `/var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs'
 make: *** [all] Error 2
 
 
 Best,  Stephan
 
 regards,
 Andreas
 
 smime.p7s

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] bos server instances doesnt come up

[Stephan Wiesand]

Please answer Jeffrey's questions, and we may be able to help. Alternatively, 
trust in my intuition and grep my previous mails for SELinux.

Stephan

On Jun 29, 2015, at 19:20 , Andreas Ladanyi wrote:

 Hi,
 
 ok, the problem isnt gone.
 
 If i start  the bos server:
 
 /usr/afs/bin/bosserver -noauth 
 
 bos status tells me the instances are running normally.
 
 
 If i start the openafs-server with the systemd scripts:
 =
 
 enafs-server.service - OpenAFS Server Service
   Loaded: loaded (/usr/lib/systemd/system/openafs-server.service; enabled)
   Active: active (running) since Mon 2015-06-29 18:58:56 CEST; 1min 37s ago
  Process: 3481 ExecStop=/usr/bin/bos shutdown localhost -wait -localauth 
 (code=exited, status=0/SUCCESS)
 Main PID: 3490 (bosserver)
   CGroup: /system.slice/openafs-server.service
   └─3490 /usr/afs/bin/bosserver -nofork
 
 Jun 29 18:58:56 i44fs1.info.uni-karlsruhe.de systemd[1]: Starting OpenAFS 
 Server Service...
 Jun 29 18:58:56 i44fs1.info.uni-karlsruhe.de systemd[1]: Started OpenAFS 
 Server Service.
 
 
 But bos status tells me:
 ===
 
 Instance vlserver, temporarily disabled, stopped for too many errors, 
 currently starting up.
 Instance ptserver, temporarily disabled, stopped for too many errors, 
 currently starting up.
 Instance dafs, temporarily disabled, stopped for too many errors, currently 
 shutdown.
Auxiliary status is: file server shut down.
 
 
 I get the PtLog and VLLog error messages with the ubik errors:
 
 PtLog:
 
 
 ptserver: file not found when processing dbase Ubik init failed
 ptserver: running unauthenticated
 
 
 VLLog:
 =
 
 vlserver: Ubik init failed: file not found when processing dbase
 
 
 
 Andy
 
 
 
 Hi Jeffrey,
 
 i use the description  OpenAFS Quick Start Guide for Unix. At this time
 i have done the steps at
 http://docs.openafs.org/QuickStartUnix/index.html#HDRWQ52.html
 
 I tried to start the bos server with the systemd script. I think at this
 state it wasnt a good idea.
 On 6/25/2015 5:02 AM, Andreas Ladanyi wrote:
 
 PtLog:
 
 
 ptserver: file not found when processing dbase Ubik init failed
 ptserver: running unauthenticated
 
 VLLog:
 =
 
 vlserver: Ubik init failed: file not found when processing dbase
 
 The database file cannot be created or opened.
 
 How was OpenAFS installed and on which OS/version?
 with the openafs srpm package from the openafs website. I built my own
 binary rpms from this srpm package and installed it. The OS is centos 7.
 Jeffrey Altman

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] bos server instances doesnt come up

[Stephan Wiesand]

If you'd answer Jeffrey's questions we could tell you to disable SELinux.

 On 25 Jun 2015, at 13:56, Andreas Ladanyi andreas.lada...@kit.edu wrote:
 
 If i start the bosserver with the command:
 
 /usr/afs/bin/bosserver -noauth 
 
 then creating the instances with:
 
 bos create instance -noauth now works.
 
 Before that i tried to use the systemd afs server script which makes
 trouble when creating instances with bos command like described below.
 
 Hi,
 
 i installed Openafs 1.6.11.1. The pt / vl / bu instances dont come up.
 
 bos status FQDN server -noauth
 bos: running unauthenticated
 Instance buserver, temporarily disabled, stopped for too many errors,
 currently starting up.
 Instance ptserver, temporarily disabled, stopped for too many errors,
 currently starting up.
 Instance vlserver, temporarily disabled, stopped for too many errors,
 currently starting up.
 
 Boslog:
 
 
 The executables which are missed in the filesystem are available.
 
 
 
 Thu Jun 25 10:52:36 2015: BNODE 'vlserver' repeatedly failed to start,
 perhaps missing executable.
 Thu Jun 25 10:52:36 2015: vlserver will retry start in 32 seconds
 Thu Jun 25 10:52:40 2015: buserver started pid 72469: /usr/afs/bin/buserver
 Thu Jun 25 10:52:40 2015: buserver exited with code 255
 Thu Jun 25 10:52:40 2015: buserver started pid 72470: /usr/afs/bin/buserver
 Thu Jun 25 10:52:40 2015: buserver exited with code 255
 Thu Jun 25 10:52:40 2015: buserver started pid 72471: /usr/afs/bin/buserver
 Thu Jun 25 10:52:40 2015: buserver exited with code 255
 Thu Jun 25 10:52:40 2015: buserver started pid 72472: /usr/afs/bin/buserver
 Thu Jun 25 10:52:40 2015: buserver exited with code 255
 Thu Jun 25 10:52:40 2015: buserver started pid 72473: /usr/afs/bin/buserver
 Thu Jun 25 10:52:40 2015: buserver exited with code 255
 Thu Jun 25 10:52:40 2015: buserver started pid 72474: /usr/afs/bin/buserver
 Thu Jun 25 10:52:40 2015: buserver exited with code 255
 Thu Jun 25 10:52:40 2015: buserver started pid 72475: /usr/afs/bin/buserver
 Thu Jun 25 10:52:40 2015: buserver exited with code 255
 Thu Jun 25 10:52:40 2015: buserver started pid 72476: /usr/afs/bin/buserver
 Thu Jun 25 10:52:40 2015: buserver exited with code 255
 Thu Jun 25 10:52:40 2015: buserver started pid 72477: /usr/afs/bin/buserver
 Thu Jun 25 10:52:40 2015: buserver exited with code 255
 Thu Jun 25 10:52:40 2015: buserver started pid 72478: /usr/afs/bin/buserver
 Thu Jun 25 10:52:40 2015: buserver exited with code 255
 Thu Jun 25 10:52:40 2015: buserver started pid 72479: /usr/afs/bin/buserver
 Thu Jun 25 10:52:40 2015: buserver exited with code 255
 Thu Jun 25 10:52:40 2015: buserver started pid 72480: /usr/afs/bin/buserver
 Thu Jun 25 10:52:40 2015: buserver exited with code 255
 Thu Jun 25 10:52:40 2015: BNODE 'buserver' repeatedly failed to start,
 perhaps missing executable.
 Thu Jun 25 10:52:40 2015: buserver will retry start in 60 seconds
 Thu Jun 25 10:53:00 2015: ptserver started pid 72481: /usr/afs/bin/ptserver
 Thu Jun 25 10:53:00 2015: ptserver exited with code 2
 Thu Jun 25 10:53:00 2015: ptserver started pid 72482: /usr/afs/bin/ptserver
 Thu Jun 25 10:53:00 2015: ptserver exited with code 2
 Thu Jun 25 10:53:00 2015: ptserver started pid 72483: /usr/afs/bin/ptserver
 Thu Jun 25 10:53:00 2015: ptserver exited with code 2
 Thu Jun 25 10:53:00 2015: ptserver started pid 72484: /usr/afs/bin/ptserver
 Thu Jun 25 10:53:00 2015: ptserver exited with code 2
 Thu Jun 25 10:53:00 2015: ptserver started pid 72485: /usr/afs/bin/ptserver
 Thu Jun 25 10:53:00 2015: ptserver exited with code 2
 Thu Jun 25 10:53:00 2015: ptserver started pid 72486: /usr/afs/bin/ptserver
 Thu Jun 25 10:53:00 2015: ptserver exited with code 2
 Thu Jun 25 10:53:00 2015: ptserver started pid 72487: /usr/afs/bin/ptserver
 Thu Jun 25 10:53:00 2015: ptserver exited with code 2
 Thu Jun 25 10:53:00 2015: ptserver started pid 72488: /usr/afs/bin/ptserver
 Thu Jun 25 10:53:00 2015: ptserver exited with code 2
 Thu Jun 25 10:53:00 2015: ptserver started pid 72489: /usr/afs/bin/ptserver
 Thu Jun 25 10:53:00 2015: ptserver exited with code 2
 Thu Jun 25 10:53:00 2015: ptserver started pid 72490: /usr/afs/bin/ptserver
 Thu Jun 25 10:53:00 2015: ptserver exited with code 2
 Thu Jun 25 10:53:00 2015: ptserver started pid 72491: /usr/afs/bin/ptserver
 Thu Jun 25 10:53:00 2015: ptserver exited with code 2
 Thu Jun 25 10:53:00 2015: ptserver started pid 72492: /usr/afs/bin/ptserver
 Thu Jun 25 10:53:00 2015: ptserver exited with code 2
 Thu Jun 25 10:53:00 2015: BNODE 'ptserver' repeatedly failed to start,
 perhaps missing executable.
 Thu Jun 25 10:53:00 2015: ptserver will retry start in 60 seconds
 Thu Jun 25 10:53:09 2015: vlserver started pid 72493: /usr/afs/bin/vlserver
 Thu Jun 25 10:53:09 2015: vlserver exited with code 2
 Thu Jun 25 10:53:09 2015: vlserver started pid 72494: /usr/afs/bin/vlserver
 Thu Jun 25 10:53:09 2015: vlserver exited with code 2
 Thu Jun 25 10:53:09 2015: vlserver started pid 72495: 

Re: [OpenAFS] Uninstall OpenAFS after make install

[Stephan Wiesand]

 On 22 Jun 2015, at 09:40, Andreas Ladanyi andreas.lada...@kit.edu wrote:
 
 iam using Centos 7 and openafs 1.6.11.1 from source tarball.
 In general when a packaged version of something is available, it should
 be preferred over a source build, since the packaging system tracks which
 files are installed by the package and should allow for cleaner
 uninstalls.
 
 http://openafs.org/dl/openafs/1.6.11.1/openafs-1.6.11.1-1.src.rpm is the
 1.6.11 srpm, which ought to be buildable into binary rpms with, e.g.,
 mock.
 I used this now, but an yum-builddep of this srpm package tells me that
 the package:
 
 kernel-devel-x86_64 = 2.6.18-404.el5 is needed but not found on centos
 7. centos 7 ist working with 3.10.

yum-builddep is looking at the wrong info when used on srpms. Install or unpack 
the srpm and run yum-builddep openafs.spec instead.

 I found out that centos 5 is working with kernel 2.6.18.

Indeed, the srpm was built on en EL5 system.

  But its
 interesting to see that for RHEL 7 there are packages on the openafs
 webseite for release 1.6.8.

That's by accident only. It was decided that packaging OpenAFS has to happen 
downstream and thus the project should not provide Linux packages for new 
major OpenAFS releases (1.8+) or new major distribution releases (F21+, EL7+). 

That decision should probably be revisited since the anticipated downstream 
packaging for EL7 hasn't happened (AFAIK) and the once existing packaging for 
Fedora seems not to have made it past the early days of F20.

Binary packages for those distributions are still being built and can be found 
in /afs/inf.ed.ac.uk/group/afsbuild , they're just no longer uploaded. Which 
seems kind of silly, given the lack of alternatives.

Best,
Stephan


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

Re: [OpenAFS] Uninstall OpenAFS after make install

[Stephan Wiesand]

 On 22 Jun 2015, at 15:15, lada...@ira.uka.de wrote:
 
 I used this now, but an yum-builddep of this srpm package tells me that
 the package:  kernel-devel-x86_64 = 2.6.18-404.el5 is needed but not
 found on centos 7. centos 7 ist working with 3.10.
 
 yum-builddep is looking at the wrong info when used on srpms. Install or
 unpack the srpm and run yum-builddep openafs.spec instead.
 
 On Centos 7:
 yum-builddep openafs.spec works.
 rpmbuild -ba openafs.spec exits with 0. I got my rpm packages.
 
 On Fedora 20:
 I add a yum repository file which points to the 1.6.10 rpm Fedora 20 packages 
 at openafs.org
 
 yum install produce the following output with some errors and bad exit:

1.6.10 is too old for that kernel, you need at least 1.6.11. NB F20 is EOL.

Best,
Stephan

 Running transaction
  Installing : openafs-1.6.10-2.fc20.x86_64
   
 1/5
  Installing : openafs-client-1.6.10-2.fc20.x86_64 
   
 2/5
  Installing : dkms-openafs-1.6.10-2.fc20.x86_64   
   
 3/5
 Error! DKMS tree already contains: openafs-1.6.10-2.fc20
 You cannot add the same module/version combo more than once.
 
 Kernel preparation unnecessary for this kernel.  Skipping...
 
 Building module:
 cleaning build area...(bad exit status: 2)
 ./configure 
 --with-linux-kernel-headers=/lib/modules/3.19.8-100.fc20.x86_64/build 
 --with-linux-kernel-packaging  make  case 3.19.8-100.fc20.x86_64 in 
 2.4.*) mv src/libafs/MODLOAD-*/libafs-* openafs.o ;; *) mv 
 src/libafs/MODLOAD-*/openafs.ko . ;; 
 esac(bad exit status: 2)
 Error! Bad return status for module build on kernel: 3.19.8-100.fc20.x86_64 
 (x86_64)
 Consult /var/lib/dkms/openafs/1.6.10-2.fc20/build/make.log for more 
 information.
 
 Kernel preparation unnecessary for this kernel.  Skipping...
 
 Building module:
 cleaning build area...(bad exit status: 2)
 ./configure 
 --with-linux-kernel-headers=/lib/modules/3.19.8-100.fc20.x86_64/build 
 --with-linux-kernel-packaging  make  case 3.19.8-100.fc20.x86_64 in 
 2.4.*) mv src/libafs/MODLOAD-*/libafs-* openafs.o ;; *) mv 
 src/libafs/MODLOAD-*/openafs.ko . ;; 
 esac.(bad exit status: 2)
 Error! Bad return status for module build on kernel: 3.19.8-100.fc20.x86_64 
 (x86_64)
 Consult /var/lib/dkms/openafs/1.6.10-2.fc20/build/make.log for more 
 information.
 warning: %post(dkms-openafs-1.6.10-2.fc20.x86_64) scriptlet failed, exit 
 status 10
 Non-fatal POSTIN scriptlet failure in rpm package 
 dkms-openafs-1.6.10-2.fc20.x86_64
  Installing : openafs-docs-1.6.10-2.fc20.x86_64   
   
 4/5
  Installing : openafs-krb5-1.6.10-2.fc20.x86_64   
   
 5/5
  Verifying  : openafs-docs-1.6.10-2.fc20.x86_64   
   
 1/5
  Verifying  : dkms-openafs-1.6.10-2.fc20.x86_64   
   
 2/5
  Verifying  : openafs-krb5-1.6.10-2.fc20.x86_64   
   
 3/5
  Verifying  : openafs-client-1.6.10-2.fc20.x86_64 
   
 4/5
  Verifying  : openafs-1.6.10-2.fc20.x86_64
   
 5/5
 
 Installed:
  dkms-openafs.x86_64 0:1.6.10-2.fc20  openafs.x86_64 0:1.6.10-2.fc20  
 openafs-client.x86_64 0:1.6.10-2.fc20  openafs-docs.x86_64 0:1.6.10-2.fc20  
 openafs-krb5.x86_64 0:1.6.10-2.fc20
 
 Complete!
 
 
 
 The Consult /var/lib/dkms/openafs/1.6.10-2.fc20/build/make.log for more 
 information:
 
  CC [M]  
 /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc20.x86_64-SP/afs_cbqueue.o
  CC [M]  
 /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc20.x86_64-SP/afs_cell.o
  CC [M]  
 /var/lib/dkms/openafs/1.6.10-2.fc20/build/src/libafs/MODLOAD-3.19.8-100.fc20.x86_64-SP/afs_chunk.o
  CC [M]  
 

Re: [OpenAFS] On desupporting Linux 2.4

[Stephan Wiesand]

 On 26 Feb 2015, at 14:08, Chas Williams (CONTRACTOR) c...@cmf.nrl.navy.mil 
 wrote:
 
 In message alpine.gso.1.10.1502251140560.3...@multics.mit.edu,Benjamin 
 Kaduk writes:
 In particular, the threading library used by Linux 2.4, LinuxThreads, is
 
 Not completely accurate -- there are some 2.6 kernel based distributions
 with LinxuxThreads (although they hopefully provide NPTL as well).
 
 When discussion on http://gerrit.openafs.org/#change,6947 began in 2012,
 it was claimed that dropping support for Linux 2.4 was premature at that
 time.  It is now nearly three years later, and no progress has been made
 on that change in gerrit, because of the difficulty of dealing with
 LinuxThreads and Linux 2.4.
 
 RHEL4 is the last RHEL distribution to use LinuxThreads by default (at
 least to the best of my knowledge that is the case).

To the best of my knowledge: RHEL3 introduced NPTL, as the default. RHEL4 was 
the last RHEL offering LinuxThreads compatibility.

  RHEL4 went out of
 production in 2012 and extended support is available until 2017.
 
 SLES9 was the last SuSE to have LinuxThreads and went out of general
 support in 2011.  I can't find any information on extended support.
 
 So in 2012 it was a bit premature to consider ending support given the
 upgrade cycle for some organizations.  At this point you should have
 moved on though.
 
 As such, I propose that OpenAFS drop support for Linux 2.4 (and thus
 LinuxThreads) starting with the forthcoming 1.8 release.  Because this is
 a substantial change, I invite comments from the community as to whether
 it is appropriate and acceptable to desupport Linux 2.4, and what the
 scope of the impact of such a change would be.
 
 Since 1.6 will still be an alternative I don't see any issues.  I guess
 the big question is how long will 1.6 get security/bug fixes with 1.8
 released?

Good question. It will of course depend on available (human) resources, and my 
perception is that the current gradient isn't good. Ideally, I'd personally 
like to see 1.6 receiving security  critical bug fixes until the 
(non-extended) end of life of the enterprise linux distros current at the time 
of the 1.8.0 release. A reasonable minimum IMO is about one year after 1.8 is 
considered at least as mature and stable as 1.6. But in the end, it's the 
gatekeepers' decision.

And: I wonder how many such old systems are actually updated at all.

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

Re: [OpenAFS] Openafs-1.6.5 client crash when update the OPTIONS in afs config file

[Stephan Wiesand]

On Dec 27, 2014, at 13:43 , Sergio Gelato wrote:

 * huangql [2014-12-24 17:46:19 +0800]:
 I failed to restart afs service after I changed OPTIONS value in 
 /etc/sysconfig/afs file.
 
 What was the old value, and what did you change it to?

I second this question, as well as the others.

 At this time, I need to reboot the machine to make the new configuration 
 validate.
 
 Are you saying that afsd crashes on service restart but not when it is started
 for the first time after a reboot (with the same options)?
 
 Openafs version: 1.6.5
 
 A bit old. You may want to check the change logs of later versions for
 potentially relevant bug fixes.

Looks like the ordinary SL6.{x|x=5} packages. They're not supposed to crash 
under normal circumstances. Updating to 6.6 should bring the OpenAFS client to 
version 1.6.10, and there are indeed many fixes in there that should make the 
client fail with an error message rather than a panic or a segfault. But the 
culprit is most likely bad input from /etc/sysconfig/afs in either case. So, 
again: what't that file's content?

 Os version: Scientific Linux release 6.5 (Carbon)  2.6.32-431.el6.x86_64 
 
 I got the error message as following:
 
 [root@bws0609 ~]# /etc/init.d/afs restart
 Stopping AFS client. 
 Sending all processes using /afs the TERM signal ...   [  OK  ]
 Sending all processes using /afs the KILL signal ...   [  OK  ]
 Starting AFS client. 
 /etc/init.d/afs: line 230: 26271 Segmentation fault  /usr/vice/etc/afsd 
 ${AFSD_OPTIONS}

You shouldn't run the init script directly. Use service afs restart instead.

 Has a core file been left behind? If so, could you extract a backtrace from 
 it?
 
 Dec 24 17:30:29 bws0609 kernel: Starting AFS cache scan...
 Dec 24 17:30:29 bws0609 kernel: afsd[26271]: segfault at 18 ip 
 003736679753 sp 7fff5f346fa0 error 4 in 
 libc-2.12.so[373660+18a000]
 
 To me this looks like an attempt to dereference a null pointer to a struct
 (with the component of interest being at offset 0x18). A backtrace might
 help one figure out where that unexpected null pointer came from.

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] Re: accessing R/O volume becomes slow

[Stephan Wiesand]

 On 27 Nov 2014, at 11:26, Hans-Werner Paulsen h...@mpa-garching.mpg.de 
 wrote:
 On 11/26/2014 09:15 PM, Andrew Deason wrote:
 On Wed, 26 Nov 2014 10:51:00 +0100
 Hans-Werner Paulsen h...@mpa-garching.mpg.de wrote:
 
 Checking the machine I see more than 5 million of afs_inode_cache slab
 entries. Is this normal? Any hint how to proceed?
 That's not unusual if you are accessing a lot of files (say, about 5
 million recently accessed). But having a lot of vcaches in memory can
 cause certain operations to be slow; there was a fix just added in
 1.6.10 to improve speed for a background cleanup process with lots of
 files (well, and PAGs): 94f1d4.
 Yesterday, on another machine I created and deleted 4 million files on AFS. 
 The number of afs_inode_cache slabs grew from 1 million to 5 million. Today 
 there are still 5 million entries.

It should shrink when there's memory pressure. If you're still worried, there's 
the -disable-dynamic-vcaches switch for afsd.

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

Re: [OpenAFS] any experiences with OpenAFS client on the upcoming MacOS 10.10 (yosemite) release?

[Stephan Wiesand]

I shouldn't try to provide that text, but this bit from 
http://www.openafs.org/credits.html may help:

Several institutions have funded internal development of AFS code which has 
been contributed for inclusion in OpenAFS distributions. 

• Apple Computer, Inc - MacOS 10.3 client/server port


- Stephan

On 2014-10-20, at 21:58, Dave Botsch bot...@cnf.cornell.edu wrote:

 I can request it on our account, but I need a *clear* explanation, for
 Apple, of ... what your kernel extension does and why your customers
 are required to install it.
 
 If someone who knows the internals better than I can provide this text,
 that'd be great.
 
 Thanks.
 
 On Mon, Oct 20, 2014 at 03:48:11PM -0400, Dave Botsch wrote:
 I used the git head, and first had to create the various darwin-140
 files as those were not there.
 
 My attempt to compile the git head on a fresh install of Yosemite then
 failed with the following:
 
 http://fpaste.org/143001/
 
 I don't know if Cornell's developer level allows signing of kernel
 extensions or not. I can certainly check.
 
 On Mon, Oct 20, 2014 at 03:40:49PM -0400, Benjamin Kaduk wrote:
 On Mon, 20 Oct 2014, Mattias Pantzare wrote:
 
 I have tried to compile 1.6.10 on OS X 10.10.
 
 The first problem is that it will not compile with xcode 5 or 6. I have not
 checked if there is a way to change the compiler to gcc on xcode 6, so it
 might be possible (the command gcc starts c-lang).
 
 The git master compiles just fine with xcode 6 on my Mavericks machine, so
 if there are build failures, they are probably just small patches that
 need to be merged from the master branch to the 1.6 branch.  (I don't
 think you can get real gcc from xcode 6 or higher.)
 
 10.10 requires all kernel extensions to be signed. They ship a list of
 hashes for old kernel extensions, that is why some versions of openafs will
 work on an upgraded system. But new openafs versions have to be signed.
 
 Some individual or organization will need to step forward to do that
 signing; I do not believe that there is an OpenAFS organization
 currently able or prepared to do so.  (Perhaps the Foundation could, but I
 am not sure.)  The Windows installers that OpenAFS distributes are signed
 by Secure Endpoints or YFSI (I forget which), who have graciously been
 using their codesigning certificates for this purpose.  I do not know if
 they will be willing to perform the same service for OS X installers.
 
 -Ben

-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany



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

[OpenAFS] Additional 1.6.10pre1 binaries available for testing

[Stephan Wiesand]

Additional binaries for the first 1.6.10 prerelease are now available for
the following platforms:

OpenSUSE 12.3, 13.1, factory, tumbleweed
SUSE Linux Enterprise 11 SP2, 11 SP3
Solaris 10 (x86 only) and 11 (x86 and SPARC)

and can be accessed through the link/paths given in the announcement.

Thanks are due to Andrew Deason for providing the Solaris builds and
to Christof Hanke for the SUSE ones.

On Aug 18, 2014, at 22:02 , Stephan Wiesand wrote:

 The OpenAFS 1.6 Release Team announces that the first 1.6.10 release candidate
 1.6.10pre1 has been tagged in the OpenAFS source repository, available at:
 
  git://git.openafs.org/openafs.git
 
 as tag: openafs-stable-1_6_10pre1 .
 
 Source files and available binaries can be accessed via the web at:
 
  http://dl.openafs.org/dl/candidate/1.6.10pre1/
 
 or via AFS at:
 
  UNIX: /afs/grand.central.org/software/openafs/candidate/1.6.10pre1/
  UNC: \\afs\grand.central.org\software\openafs\candidate\1.6.10pre1\
 
 Binaries are available for Fedora 19/20 and RHEL 5/6 thanks to Stephen 
 Quinney.
 For other platforms, they will be uploaded as they become available.
 
 Besides many other fixes and enhancements, this release candidate includes the
 following changes:
 
  * volscan(8), a swiss army knife utility for gathering information about
volume content efficiently on the fileserver hosting it, was added.
 
  * The client now reports just under 2 TiB free space in /afs. Previously,
it reported 9 GiB on most platforms, which could cause problems with
software checking for sufficient free space before attempting to write
files larger than that.
 
  * Client support for Linux kernels up to at least 3.16
 
  * Support for FreeBSD 9.3 and 10.1
 
 For the full list of user visible changes foreseen for 1.6.10, please see
 
  http://dl.openafs.org/dl/candidate/1.6.10pre1/RELNOTES-1.6.10pre1
 
 
 There is a known issue with out-of-tree builds. This is being worked on in
 
   http://gerrit.openafs.org/11392
 
 and the final solution will be included in the 1.6.10 release.
 
 
 Please assist us by deploying this prerelease and providing positive or
 negative feedback. Bug reports should be filed to openafs-b...@openafs.org .
 Reports of success should be sent to openafs-info@openafs.org .
 
 1.6 releases are no longer targeting MS Windows.
 
 Stephan Wiesand, 1.6 Branch Release Manager
 for the OpenAFS Release Team

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

Re: [OpenAFS] client behind NAT firewall

[Stephan Wiesand]

On 2014-08-05, at 15:08, Brandon Allbery ballb...@sinenomine.net wrote:

 On Tue, 2014-08-05 at 09:30 +0200, Alex wrote:
 Now, I didn't find in the admin guide or wiki[1] some useful
 information
 about client's firewall, but I could find some information on the
 Internet saying that client doesn't work without opening 7001 for
 incoming UDP [2]. This should be open for callbacks (if I understood
 correctly). I also tested the client behind NAT with some public cells
 and it worked well. So, does a client work behind a firewall NAT even
 without opening inbound ports? If not, is there any solution for this?
 
 You will get basic client functionality even without opening the port.
 What you won't get is notifications from the server that something the
 server knows to be cached on the client has been modified elsewhere and
 the client should flush its cached information (this is the callback).

And what those who modify such content elsewhere get is that they have
to wait while the server tries to break the callback. I believe we even
have seen file creation fail due to this, although it probably shouldn't.

 In most cases, clients already discard this cached information after
 some amount of time; additionally, if you are mostly using read-only
 volumes then the cached information would only be invalidated by a new
 volume release. In addition, even if you open the port, most NAT
 implementations don't retain UDP NAT mappings for long enough to be
 useful for callback breaks (generally their expected use case for UDP is
 DNS). So you might be able to get by with just running fs checkvolumes
 periodically in a cron job to make up for missing callback breaks on
 volume releases. For the most reliable operation, however, you should
 check that the NAT gateway can remember UDP NAT mappings *specifically
 on client port 7001* for at least 2 hours and open 7001/udp in the
 firewall so the client can receive callback breaks.

-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] client behind NAT firewall

[Stephan Wiesand]

On 2014-08-05, at 9:30, Alex euergetiko...@gmail.com wrote:

 Please help me to make a decision here. I am trying to determine whether
 Openafs is the right choice for us and it is not clear for me if
 modifying client's firewall is mandatory or not. The situation is like
 this:
 
 -all Openafs servers are behind the same NAT firewall. Firewall rules
 can be changed.

I'm not that NAT savvy... how could this possibly work (more than one server)?

 -client computers are behind another NAT firewall. Firewall rules cannot
 be changed.
 -some clients are on Windows, some on Linux.

-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] Re: File locking

[Stephan Wiesand]

Todd,

unless there's a problem found with it, this patch will be part of the next 
ordinary stable release.

Thanks a lot for reporting your problems with 1.6 and reporting back on the 
proposed fix. And Kudos to Andrew for whipping that up so swiftly.

Stephan

On Jul 17, 2014, at 21:20 , Todd Lewis wrote:

 Andrew,
 
 The suggested patch was applied, installed, and our application now works 
 correctly again with the new client.
 
 Thank you very much for your timely response. Looking forward to this patch 
 making its way to release soon.
 --
 todd_le...@unc.edu
 
 On 07/17/2014 11:59 AM, Andrew Deason sent:
 On Thu, 17 Jul 2014 10:07:07 -0400
 Todd Lewis todd_le...@unc.edu wrote:
 
 Was there some change in file locking semantics that would make sense
 of this? Does this application tickle a corner case error in openafs's
 file locking, or does more rigorous lock handling in the newer client
 expose a bug in the application? I have tried to replicate the failure
 with a very simple C program with no success, but that mostly
 indicates I'm not sure what I'm testing for.
 
 I assume the path you gave was for an RO volume, yes?
 
 In that case, no, it's just a mistake; specifically, my mistake (sorry).
 It's trying to return the error EBADF (9) to you, which is wrong, and
 it's returning that code incorrectly, which makes this a bit more
 confusing.
 
 There was some code added a while back to skip some processing for locks
 on RO volumes. But for some reason I added some linux-specific check
 much earlier before the platform-agnostic check, which makes this fail
 for F_GETLK requests in addition to F_SETLK ones. (For F_SETLK, we
 should indeed fail with EBADF here.) I'm not sure why I did that, since
 this should have been handled by the platform-agnostic code; none of my
 notes or comments about this seem to say anything about it.
 
 And in that Linux-specific check, the error is just plain returned
 incorrectly (which just happens from time to time, since Linux has a
 very specific different way of doing this). I think I just didn't notice
 this when running it originally (and almost missed it just now), because
 I saw a '9' get returned and assumed that's what was supposed to happen.
 But it's not, of course; fcntl is supposed to return -1 and set errno to
 9.
 
 A proposed fix is here (gerrit 11316):
 http://git.openafs.org/?p=openafs.git;a=commitdiff_plain;h=93451d74474bcd8ed9e0f59cf690d3d61c3022f9
 
 If you are able to test code changes in your client, give that a try.

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] additional OpenAFS 1.6.9 binaries available

[Stephan Wiesand]

On Jun 25, 2014, at 18:16 , Jeffrey Altman wrote:

 On 6/25/2014 11:39 AM, Dave Botsch wrote:
 At the very least, I'd like to see a spec included in the source so
 that one can rebuild on one's own the binaries from the source (on at
 least the base RHEL and current Fedora).
 
 The underlying issue is what should be in the spec file and who is going
 to maintain it?   Its not like there is a single distribution of Linux.
 Each distribution has its own requirements and preferences for how
 applications, daemons, and kernel modules should be installed and
 configured.

Having a reference spec for one platform in the tree would still be good.
I do share your concern regarding its maintenance though.

 The spec file currently in the OpenAFS tree is in violation of many of
 the Fedora and RHEL guidelines.  For starters, the use of transarc paths
 instead of FHS is a big issue.  For RHEL7 there is significant work that
 needs to be done to produce compliant packaging.

Strictly speaking, the FHS violation is not an actual issue unless /usr
is immutable. And that's only just begun to be a concern with atomic
deployment / rpm-ostree. And that's in its infancy. And at least for client
systems, a workaround seems feasible. But I agree that that's not the way
forward in the long run.

 For Fedora, the rpm fusion packaging is much closer to what the
 community wants to see.

I'm not sure. Significant parts of the existing community may still be
using transarc paths and not keen on this change. Attracting new
community members with transarc paths is probably difficult though.

   For RHEL, the ElRepo packaging is much closer
 to what is required for RHEL7.

RHEL7 itself doesn't require anything special. It's rather us saying
that on a new platform (with 10 years of support life) we don't want
to continue with something that's already looking baroque.

But yes, it would be good to leave the packaging to downstream.

Alas, the ELRepo packaging handles the kernel modules in a way the
OpenAFS developers clearly disapprove of, and I'm not sure that's
fixable.

  It is our view that given available
 resources that downstream distributions should package OpenAFS and end
 users should work with the downstream distributions to determine how
 those packages should function.
 
 One of the primary benefits of this approach is that downstream
 packagers do not need to wait for new OpenAFS releases to distribute
 packages that support new kernel releases or address other distribution
 specific functionality.
 
 IMHO, not offering binaries and telling users to go someplace else is
 not perceived as friendly to the users... UNLESS.. there is a direct
 pointer to said trusted 3rd party binary builder. Especially if binaries
 are available for Mac and Windows... it comes off as a screw you to
 linux users.

If that's what my previous message conveyed, I'm really sorry.

But note that we only ever provided a spec for EL/Fedora, and uploaded
binaries for those built from that spec - and for SUSE built from
something entirely different. Debian/Ubuntu packaging has been done
downstream for a long time, and the same holds for other distributions.

On the other hand, configure; make; make install is still supposed to
work on any Linux distribution. And that's all several other platforms
ever had.

 Funny you should bring up OSX and Windows.   For OSX the packaging is
 now two OS revisions out of date.  Installers cannot be built for
 Mavericks or Yosemite with current build tools.   The installers can
 only be built using the development tool chain for Mountain Lion.

And no more volunteers for doing it either. I'm really glad Ken H. helped
us out with such an installer so we have something that can be installed
easily on Mavericks when I approached him. But that's hardly a sustainable
model.

 On Windows, the packaging scripts have not been updated in almost six
 years.  They cannot be built using current versions of the WiX tool
 chain.  They do not support merge modules and do not support installing
 32-bit and 64-bit components in the same msi.
 
 Installation packaging is hard.  In some ways it is harder than writing
 the file system.  Both the OSX and Windows installation packaging
 requires a total rewrite.  If there was a downstream source that could
 take responsibility for doing that work, we would ask them to do so.
 The way things are at present OSX and Windows are simply limping along.
 
 Jeffrey Altman

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

Re: [OpenAFS] OpenAFS 1.6.9 EL5 repository metadata

[Stephan Wiesand]

Uploaded. Thanks for the report and the quick reaction.

Stephan

On 2014-06-20, at 12:55, Stephen Quinney step...@jadevine.org.uk wrote:

 Apologies, that was caused by me manually regenerating the repodata for EL5 
 from an EL6 machine without using checksum option. I'll fix the repodata now, 
 it will take a little while before it reaches the public repository.
 
 Stephen
 
 
 On 20 June 2014 11:35, Andreas Lehner andreas.leh...@verdi.de wrote:
 Hello.
 
 The OpenAFS 1.6.9 binaries provided for Red Hat Enterprise Linux 5[0]
 carry a defective repomd.xml[1]. EL5 provides versions of yum and
 hashing libraries that are incapable of computing sha256 checksums.
 Previous OpenAFS releases were created using sha checksums[2].
 
 The packages seem to have been built on EL6 or current Fedora. Newer
 versions of createrepo on EL6 use sha256 by default as opposed to sha in
 previous versions. Passing --checksum sha to createrepo should remedy
 the issue.
 
 Best regards
   Andreas Lehner
 
 [0]
 https://lists.openafs.org/pipermail/openafs-info/2014-June/040734.html
 [1]
 http://dl.openafs.org/dl/openafs/1.6.9/rhel5/i386/repodata/repomd.xml
 [2]
 http://dl.openafs.org/dl/openafs/1.6.8/rhel5/i386/repodata/repomd.xml

-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany

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

[OpenAFS] additional OpenAFS 1.6.9 binaries available

[Stephan Wiesand]

Thanks to Stephen Quinney, RPMs for Fedora 18/19/20 and Red Hat Enterprise
Linux 5/6 (and clones) are now available.


Note that there are no RHEL7 binaries. The release team feels that we should
not continue to provide packages using the old transarc paths for new Linux
platforms, and that we should leave packaging for those to downstream projects
rather than creating FHS compliant packages ourselves. This would mean that
we'd no longer provide any binaries for RHEL7+ and Fedora 21+.

Your feedback on this plan is most welcome.

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] additional OpenAFS 1.6.9 binaries available

[Stephan Wiesand]

On Jun 18, 2014, at 20:07 , Jonathan Billings wrote:

 On Wed, Jun 18, 2014 at 1:52 PM, Stephan Wiesand stephan.wies...@desy.de
 wrote:
 
 Note that there are no RHEL7 binaries. The release team feels that we
 should
 not continue to provide packages using the old transarc paths for new Linux
 platforms, and that we should leave packaging for those to downstream
 projects
 rather than creating FHS compliant packages ourselves. This would mean that
 we'd no longer provide any binaries for RHEL7+ and Fedora 21+.
 
 
 Do we want to continue development of the RPM spec file in the OpenAFS git
 tree?  Split off a RHEL7/Fedora version?


Interesting question. My personal opinion is that if we do it at all, yes
we should forge a new spec for RHEL 7+ and Fedora 21+ which does away with
all the legacy. And that it would bitrot quickly unless we actually use it.
And that maintaining the spec is the bigger problem than providing the
builds.

Thus, probably: No.

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] Salvageserver 1.6.1-3+deb7u1 core dump

[Stephan Wiesand]

On 2014-06-17, at 10:25, Harald Barth h...@kth.se wrote:

 More from the core:
 
 (gdb) bt
 #0  0x7fbe95040475 in raise () from /lib/x86_64-linux-gnu/libc.so.6
 #1  0x7fbe950436f0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
 #2  0x0042f162 in osi_Panic (
msg=msg@entry=0x4635f0 assertion failed: %s, file: %s, line: %d\n)
at ./../rx/rx_user.c:251
 #3  0x0042f17d in osi_AssertFailU (
expr=expr@entry=0x4586bb Delete(dh, \..\) == 0, 
file=file@entry=0x458337 ../vol/vol-salvage.c, line=line@entry=3997)
at ./../rx/rx_user.c:261
 #4  0x00408078 in SalvageVolume (
salvinfo=salvinfo@entry=0x7fff12474f80, rwIsp=rwIsp@entry=0x1bd68b0, 
alinkH=0x1bd44a0) at ../vol/vol-salvage.c:3997
 #5  0x0040af8d in DoSalvageVolumeGroup (salvinfo=salvinfo@entry=0x0, 
isp=0x1bd68b0, nVols=nVols@entry=2) at ../vol/vol-salvage.c:2092
 #6  0x0040c391 in SalvageFileSys1 (partP=partP@entry=0x1bca880, 
singleVolumeNumber=536904480) at ../vol/vol-salvage.c:937
 #7  0x004041a9 in DoSalvageVolume (slot=optimized out, 
node=0x1bd4030) at ../vol/salvaged.c:640
 #8  SalvageServer (argv=optimized out, argc=optimized out)
at ../vol/salvaged.c:574
 #9  handleit (as=optimized out, arock=optimized out)
at ../vol/salvaged.c:299
 #10 0x004572a4 in cmd_Dispatch (argc=7, argc@entry=6, argv=0x1bc1c20, 
argv@entry=0x7fff12475768) at cmd.c:905
 #11 0x00404c67 in main (argc=6, argv=0x7fff12475768)
at ../vol/salvaged.c:418
 
 So this is bailing out at 
 vol_salvage.c opr_Verify(afs_dir_Delete(dh, ..) == 0)
 which looks a lot like 
 
 http://git.openafs.org/?p=openafs.git;a=commitdiff;h=e8faeae6dcae0e566de2b21d53d3f78f3cc44e3f
 
 Improve JudgeEntry() detection of orphaned directories to
 prevent unintentional deletion of their '.' and '..' entries.
 This in turn prevents a later assert (opr_Verify) when we try to
 delete and re-add '..' in order to attach the orphan.
 ...
 
 So well, now I only need to find something that contains that patch
 (1.6.9 I suppose) for wheezy, correct?

This change went into 1.6.6, so 1.6.7 would do as well.

-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany

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

[OpenAFS] Re: [OpenAFS-announce] OpenAFS 1.6.9 release available

[Stephan Wiesand]

On Jun 12, 2014, at 19:44 , Stephan Wiesand wrote:

 The OpenAFS Release Team is pleased to announce the availability of
 OpenAFS version 1.6.9. Source files can be accessed via the web at:
 
  http://www.openafs.org/dl/openafs/1.6.9/
 
 or via AFS at:
 
  /afs/grand.central.org/software/openafs/1.6.9/
 \\afs\grand.central.org\software\openafs\1.6.9\
 
 OpenAFS 1.6.9 is the next in the current series of stable releases
 of OpenAFS for all platforms except Microsoft Windows. The only
 change since the 1.6.8 release is:
 
 * Fix for OpenAFS-SA-2014-002
 
 Bug reports should be filed to openafs-b...@openafs.org .
 
 No binaries are available at the time of release, but they will
 be uploaded and accessible through the web link given above as
 they are built.


Thanks to the efforts of Ben Kaduk, Andrew Deason and Christof
Hanke, binaries for FreeBSD, Solaris and SUSE Linux are now available.

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

[OpenAFS] Additional 1.6.8pre2 binaries available for testing

[Stephan Wiesand]

Additional binaries for the second 1.6.8 prerelease are now available for
the following platforms

RHEL 7 rc ( clones)
OpenSUSE 12.2, 12.3, 13.1
SUSE Linux Enterprise 11 SP2, 11 SP3

and can be accessed through the link/paths given in the announcement.

Thanks are due to Stephen Quinney for providing the EL7 builds and
to Christof Hanke for the SUSE ones.

The cache consistency issue observed on Linux clients at one site
turned out to be an older problem and probably has existed for several
years. It will be addressed in OpenAFS 1.6.9.

We currently intend to release 1.6.8 next Wednesday, without further
changes to 1.6.8pre2.

On May 2, 2014, at 19:59 , Stephan Wiesand wrote:

 Additional binaries for the second 1.6.8 prerelease are now available for
 the following platforms
 
 RHEL 5, 6 ( clones)
 Fedora 18, 19, 20
 
 and can be accessed through the link/paths given in the announcement.
 
 Thanks are due to Stephen Quinney for providing those.
 
 While there are possible issues not addressed in this prerelease (see
 00README.txt), most sites are unlikely to encounter them. And if they
 do, the data points would be most valuable.
 
 On Apr 24, 2014, at 20:01 , Stephan Wiesand wrote:
 
 The OpenAFS 1.6 Release Team announces that the second 1.6.8 release 
 candidate
 1.6.8pre2 has been tagged in the OpenAFS source repository, available at:
 
 git://git.openafs.org/openafs.git
 
 as tag: openafs-stable-1_6_8pre2 .
 
 Source files can be accessed via the web at:
 
 http://dl.openafs.org/dl/candidate/1.6.8pre2/
 
 or via AFS at:
 
 UNIX: /afs/grand.central.org/software/openafs/candidate/1.6.8pre2/
 UNC: \\afs\grand.central.org\software\openafs\candidate\1.6.8pre2\
 
 Solaris binaries are already available, thanks to Andrew Deason.
 Binaries for other platforms will be uploaded as they're built.
 
 Please take note of the following significant changes in 1.6.8:
 
 * The default fileserver sync behavior changes from delayed to
 onclose. This means that explicit syncing only happens when a
 volume is detached. This was the recommended option in previous
 stable releases, and it's believed to improve data integrity.
 
 * When a client is shut down, it will give up its callbacks. The Windows
 client has been doing this since 2007. Note that older fileservers
 (1.3.50 to 1.4.5 and 1.5.0 to 1.5.27) had a bug in the implementation of
 the relevant RPC that could cause crashes or other undefined behavior
 when this happens.
 
 For the list of all user visible changes foreseen for 1.6.8, please see
 
 http://dl.openafs.org/dl/candidate/1.6.8pre2/RELNOTES-1.6.8pre2
 
 The only changes in this release candidate since pre1 are the security
 and DoS fixes from 1.6.7 and a FreeBSD specific build fix.
 
 This is likely to be the final candidate. Further changes before the
 1.6.8 release are only foreseen if new problems are found during pre2
 testing.
 
 
 Please assist us by deploying this prerelease and providing positive or
 negative feedback. Bug reports should be filed to openafs-b...@openafs.org .
 Reports of success should be sent to openafs-info@openafs.org .
 
 1.6 releases are no longer targeting MS Windows.
 
 Stephan Wiesand, 1.6 Branch Release Manager
 for the OpenAFS Release Team

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] Re: OpenAFS and windows/unix versioning

[Stephan Wiesand]

 be some restrictions on
 getting all packaging to go along with such a scheme. It also looks a
 little weird to me, especially if we need point releases like:
 
 2.2014.05.1
 
 Of course, the other way is to have the date be first and have
 subversions off of that, like 2014.05.1 or 2014.05 update 1, but then
 you have dates that are actually misleading, since 2014.05.9 might be
 released in the year 2019. So that seems _worse_.
 
 None of these seem like blocker issues and are maybe fixable, but I'm
 not sure if this is worth it to just get the benefit of I know what
 month release X is from just by looking at it.

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] OpenAFS and windows/unix versioning

[Stephan Wiesand]

On May 7, 2014, at 19:07 , Garance A Drosehn wrote:

 On May 6, 2014 6:05:03 PM Andrew Deason adea...@sinenomine.net wrote:
 
 Summary: What version numbers would you like for Windows and Unix
 releases in the future? Some options are described below.
 
 On 7 May 2014, at 10:13, Dave B. wrote:
 
 One of our main thoughts is that the version numbers should be
 indicative of client/server compatibility.
 
 Unified versions would be best, but I can see where that runs into
 practical difficulties.  The project hasn't had unified versions for
 quite awhile now, and that has not been much of a problem for my site.
 
 It would be nice to have some scheme which makes it easier to compare
 versions across platforms.  Not quite in the sense of client/server
 compatibility, but in the sense of easily stating what capabilities
 are in the clients which connect to some server.  A cell administrator
 might want to make a decision (or announcement) based on the
 capabilities of the average client which connects, for instance.

That didn't work even where we had unified versions. Like Windows clients
give up callbacks during shutdown and hurt outdated servers since 1.3.x
in 2007 but Unix clients will only start doing it now with 1.6.8. So the
1.6.1 Windows client behaves quite differently from the Unix/Linux ones.

 How about always including a 'u' or a 'w' in the major version number?
  [hrm.  those look too much alike, so maybe use different letters]
 So version 14u.1.2 would be in the releases recommended for unix, and
 14w.1.2 would be in the releases recommended for windows.  The numbers
 after the 'u' or 'w' would not have to be in lock-step, so '.1.2' in
 one line of releases isn't necessarily related to '.1.2' in the other
 set.  But both lines might jump to a '.2.0' release to signify some
 important change (such as a critical security fix).
 
 This is just a suggestion, and I don't know if it runs into practical
 issues on some platforms.  I do not feel strongly about changing the
 way versions have been handled.

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] Issue with immutable /usr

[Stephan Wiesand]

On May 5, 2014, at 00:44 , Brandon Allbery wrote:

 On Sun, 2014-05-04 at 13:17 -0400, Jon Stanley wrote:
 In the default configuration of OpenAFS as shipped (1.6.7), the
 systemd unit file attempts to edit /usr/vice/etc/CellServDB. In a new
 method of OS deployment, called rpm-ostree[1], the /usr namespace is
 completely immutable and versioned. FHS also dictates that services
 are not to make changes in /usr (though with the FHS being in a bit of
 flux, I can't actually see the standard anywhere to cite it).
 
 For whatever reason, the Red Hat-targeting releases of OpenAFS use the
 old Transarc paths instead of modern paths as used by, for example, the
 Debian-targeting releases. I suspect you just want to arrange to build
 RPMs based on the modern paths: remove --enable-transarc-paths from the
 configure parameters, and probably adjust %files to match.


At least the systemd unit file will still reference /usr/vice/etc, so it's a 
bit more than that.

And it's a change I don't see within the 1.6.x series.

One could build with --enable-transarc-paths, move /usr/vice/etc over to 
/etc/openafs-client, and package that plus a symlink /usr/vice/etc - 
/etc/openafs-client . Maybe.

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

[OpenAFS] Additional 1.6.8pre2 binaries available for testing

[Stephan Wiesand]

Additional binaries for the second 1.6.8 prerelease are now available for
the following platforms

RHEL 5, 6 ( clones)
Fedora 18, 19, 20

and can be accessed through the link/paths given in the announcement.

Thanks are due to Stephen Quinney for providing those.

While there are possible issues not addressed in this prerelease (see
00README.txt), most sites are unlikely to encounter them. And if they
do, the data points would be most valuable.

On Apr 24, 2014, at 20:01 , Stephan Wiesand wrote:

 The OpenAFS 1.6 Release Team announces that the second 1.6.8 release candidate
 1.6.8pre2 has been tagged in the OpenAFS source repository, available at:
 
  git://git.openafs.org/openafs.git
 
 as tag: openafs-stable-1_6_8pre2 .
 
 Source files can be accessed via the web at:
 
  http://dl.openafs.org/dl/candidate/1.6.8pre2/
 
 or via AFS at:
 
  UNIX: /afs/grand.central.org/software/openafs/candidate/1.6.8pre2/
  UNC: \\afs\grand.central.org\software\openafs\candidate\1.6.8pre2\
 
 Solaris binaries are already available, thanks to Andrew Deason.
 Binaries for other platforms will be uploaded as they're built.
 
 Please take note of the following significant changes in 1.6.8:
 
 * The default fileserver sync behavior changes from delayed to
  onclose. This means that explicit syncing only happens when a
  volume is detached. This was the recommended option in previous
  stable releases, and it's believed to improve data integrity.
 
 * When a client is shut down, it will give up its callbacks. The Windows
  client has been doing this since 2007. Note that older fileservers
  (1.3.50 to 1.4.5 and 1.5.0 to 1.5.27) had a bug in the implementation of
  the relevant RPC that could cause crashes or other undefined behavior
  when this happens.
 
 For the list of all user visible changes foreseen for 1.6.8, please see
 
 http://dl.openafs.org/dl/candidate/1.6.8pre2/RELNOTES-1.6.8pre2
 
 The only changes in this release candidate since pre1 are the security
 and DoS fixes from 1.6.7 and a FreeBSD specific build fix.
 
 This is likely to be the final candidate. Further changes before the
 1.6.8 release are only foreseen if new problems are found during pre2
 testing.
 
 
 Please assist us by deploying this prerelease and providing positive or
 negative feedback. Bug reports should be filed to openafs-b...@openafs.org .
 Reports of success should be sent to openafs-info@openafs.org .
 
 1.6 releases are no longer targeting MS Windows.
 
 Stephan Wiesand, 1.6 Branch Release Manager
 for the OpenAFS Release Team

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

[OpenAFS] OpenAFS 1.6.8 binaries available for testing

[Stephan Wiesand]

Binaries for the first 1.6.8 prerelease are now available for the
following platforms

Solaris 10, 11
FreeBSD 8.4, 9.1, 9.2, 10.0
RHEL 5, 6
Fedora 18, 19, 20
OpenSUSE 12.2, 12.3, 13.1, factory, tumbleweed
SUSE Linux Enterprise 11SP2, 11SP3 

and can be accessed through the link/paths given in the announcement.

Thanks are due to Andrew Deason, Ben Kaduk, Christof Hanke and
Stephen Quinney for providing those.

On 2014-04-01, at 16:54, Stephan Wiesand stephan.wies...@desy.de wrote:

 The OpenAFS 1.6 Release Team announces that the first 1.6.8 release candidate
 1.6.8pre1 has been tagged in the OpenAFS source repository, available at:
 
  git://git.openafs.org/openafs.git
 
 as tag: openafs-stable-1_6_8pre1 .
 
 Source files can be accessed via the web at:
 
  http://dl.openafs.org/dl/candidate/1.6.8pre1/
 
 or via AFS at:
 
  UNIX: /afs/grand.central.org/software/openafs/candidate/1.6.8pre1/
  UNC: \\afs\grand.central.org\software\openafs\candidate\1.6.8pre1\
 
 No binaries are available yet, but they'll be uploaded as they're built.
 
 Besides many other fixes and enhancements, this release candidate includes
 the following significant changes:
 
 * The default fileserver sync behavior changes from delayed to
  onclose. This means that explicit syncing only happens when a
  volume is detached. This was the recommended option in previous
  stable releases, and it's believed to improve data integrity.
 
 * When a client is shut down, it will give up its callbacks. The Windows
  client has been doing this since 2007. Note that older fileservers
  (1.3.50 to 1.4.5 and 1.5.0 to 1.5.27) had a bug in the implementation of
  the relevant RPC that could cause crashes or other undefined behavior
  when this happens.
 
 For the list of user visible changes foreseen for 1.6.8, please see
 
 http://dl.openafs.org/dl/candidate/1.6.8pre1/RELNOTES-1.6.8pre1
 
 
 Please note that 1.6.7 will be a security only release based upon 1.6.6.
 The details of this are not yet public, but the relevant changes will be
 part of the final 1.6.8 release, even though they aren't included in the
 1.6.8pre1 prerelease.
 
 
 Please assist us by deploying this prerelease and providing positive or
 negative feedback. Bug reports should be filed to openafs-b...@openafs.org .
 Reports of success should be sent to openafs-info@openafs.org .
 
 1.6 releases are no longer targeting MS Windows.
 
 Stephan Wiesand, 1.6 Branch Release Manager
 for the OpenAFS Release Team
 
 ___
 OpenAFS-announce mailing list
 openafs-annou...@openafs.org
 https://lists.openafs.org/mailman/listinfo/openafs-announce

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

Re: [OpenAFS] Linux OpenAFS EncFS?

[Stephan Wiesand]

On Feb 17, 2014, at 19:48 , Jukka Tuominen wrote:

 Do you accept euros? :)
 
 I just think that this might be a good time to get European funding for 
 Internet security projects like this?

It would probably take much more than adequate funding for a solid 
implementation to get such a feature in. In particular, more funding - and more 
time than a funding agency will ever grant you for delivering something.

 Personally, I feel a bit bad that a great system like OpenAFS needs to be 
 stitched with a separate VPN and file encryption software, when it could be 
 all built-in.

Combining tools doing their jobs well is not a bad strategy. Using EncFS with 
OpenAFS as the backend sounds interesting. Alas, it seems a bit stale.

Stephan

 
 Best
 
 Sent from my iPhone
 
 On 17.2.2014, at 18.35, Jeffrey Altman jalt...@your-file-system.com wrote:
 
 On 2/17/2014 11:10 AM, Troy Benjegerdes wrote:
 Could some of the professionals here please estimate a direct dollar cost 
 for
 such a thing?
 
 Who is going to pay for the design and estimation efforts?
 
 There are many approaches that can be used but before selecting one over
 another it is important to perform a threat analysis to determine which
 risks the solution must protect against and what the use cases are.
 
 For any estimate to be reasonable there will need to a work break down
 of the implementation tasks.
 
 It would not be unreasonable for such a design analysis and work break
 down to cost $10,000.
 
 An implementation that could be used by banks or government agencies
 would easily cost hundreds of thousands of U.S. dollars and take a year
 or more.
 
 Jeffrey Altman

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

Re: [OpenAFS] Extract files from /vicepa

[Stephan Wiesand]

On 2014-01-17, at 15:41, Germán Ferrari german.ferr...@gmail.com wrote:

 El ene 17, 2014 9:43 AM, Harald Barth h...@kth.se escribió:
 
 
   If I understood correctly, the easiest way to restore the files is to 
   setup
   another afs server and just overwrite the /vicepa folder with the one I
   have. Is this correct?
 
  Yes, I think that's still correct. The easiest way to set up a AFS
  server is probably to take a linux distro which has pre-packaged
  binaries for AFS client and server. Debian for example.
 
   I don't understand the part about the salvager deleting the data.
 
  I think the ownership and mode bits conain information if the file in
  question is active. The salvager may delete inactive data. But prior
  to copying your old data into your new /vicepa/ you can remove the
  salvager from BosConfig and then run the salvager by hand with
  -nowrite which will tell you what the salvager would have done.
 
   I have
   the recovered /vicepa folder on a ntfs partition. I'm trying to recover
   again the folder but to an ext4 partition trying to preserve ownership and
   modes ...
 
  Good if you can do that. Zip and Tar archives can be told to preserve
  ownership as well.
 
  Harald.
 
 
 Ok. 
 
 I was hoping there was some simple way to extract the data, which did not 
 involve the creation of an afs server.

I have a perl script from 2005 that could do this - but only for pure r/w 
volumes. If there's a backup or readonly clone on the same partition, it will 
probably fail miserably. It's not polished, may have to be adapted to current 
perl versions etc. And I think it recovered nothing but the file content and 
the path, not mode/owner/ACLs...

Setting up a server is certainly the better option and may well be easier and 
faster. But if you're desperate enough, let me know.

Regards,
Stephan

-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] Extract files from /vicepa

[Stephan Wiesand]

On 2014-01-17, at 16:43, Coy Hile coy.h...@coyhile.com wrote:

 
 
 I have a perl script from 2005 that could do this - but only for pure r/w 
 volumes. If there's a backup or readonly clone on the same partition, it 
 will probably fail miserably. It's not polished, may have to be adapted to 
 current perl versions etc. And I think it recovered nothing but the file 
 content and the path, not mode/owner/ACLs...
 
 Setting up a server is certainly the better option and may well be easier 
 and faster. But if you're desperate enough, let me know.
 
 along not completely dissimilar lines…
 
 I’ve currently got a bunch of old data (couple hundred gigs maybe) from vos 
 dump that I’d like to be able to examine to see exactly what’s there anymore. 
 Right now, my personal cell lives on a couple VMs out in various public 
 clouds, and I haven’t got around to standing up a fileserver inside the 
 firewall yet.
 
 is there a tool (preferably stand-alone) that I could run on those old dumps 
 to copy the data out of them into a local directory on, say, my mac.  Then I 
 can copy whatever of it I want to keep back into AFS later.

afsdump_scan and afsdump_extract are part of the OpenAFS source tree but not 
built by default. They build fine (there are make targets for them) and 
basically work. There's an improved version by jhutz in 
/afs/grand.central.org/software/dumpscan/dumpscan-1.2.tar.gz that was more 
difficult to build IIRC.

Stephan

-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] Extract files from /vicepa

[Stephan Wiesand]

On Jan 17, 2014, at 19:35 , Jeffrey Hutzelman wrote:

 On Fri, 2014-01-17 at 16:52 +0100, Stephan Wiesand wrote:
 On 2014-01-17, at 16:43, Coy Hile coy.h...@coyhile.com wrote:
 
 
 
 I have a perl script from 2005 that could do this - but only for pure r/w 
 volumes. If there's a backup or readonly clone on the same partition, it 
 will probably fail miserably. It's not polished, may have to be adapted to 
 current perl versions etc. And I think it recovered nothing but the file 
 content and the path, not mode/owner/ACLs...
 
 Setting up a server is certainly the better option and may well be easier 
 and faster. But if you're desperate enough, let me know.
 
 along not completely dissimilar lines…
 
 I’ve currently got a bunch of old data (couple hundred gigs maybe) from vos 
 dump that I’d like to be able to examine to see exactly what’s there 
 anymore. Right now, my personal cell lives on a couple VMs out in various 
 public clouds, and I haven’t got around to standing up a fileserver inside 
 the firewall yet.
 
 is there a tool (preferably stand-alone) that I could run on those old 
 dumps to copy the data out of them into a local directory on, say, my mac.  
 Then I can copy whatever of it I want to keep back into AFS later.
 
 afsdump_scan and afsdump_extract are part of the OpenAFS source tree
 but not built by default. They build fine (there are make targets for
 them) and basically work. There's an improved version by jhutz in
 /afs/grand.central.org/software/dumpscan/dumpscan-1.2.tar.gz that was
 more difficult to build IIRC.
 
 The versions in the openafs source are ancient copies that were put
 there as part of an effort to develop a test suite.  They are not up to
 date and contain some significant bugs.  I asked Derrick at the time not
 to fork this, but he chose to do so anyway.

They serve a purpose by just making us aware these tools exist.

 The latest released version is 1.2, but I more or less have enough
 changes to do a 1.3 release, including a couple of bug fixes, a couple
 of new features, and somewhat better ability to build against newer
 OpenAFS.  The build system is not terribly polished, but the tools do
 work.  A CVS repository can be found in
 /afs/cs.cmu.edu/project/systems-jhutz/Repository in the 'dumpscan'
 module.
 
 I suppose if sufficiently prodded, I could probably be convinced to
 convert this to git, post it someplace more easily accessible, and do a
 release.


In a perfect world, Andrew would now pick up your CVS repository, merge the
improvements into the github one he mentioned, and start submitting the
results to gerrit.openafs.org. I'd love to see the state of the art of this
being part of our regular OpenAFS releases. Obviously, there's a real need
for these tools.

Are there any licensing obstacles?

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

Re: [OpenAFS] Success - Deployment of OpenAFS 1.6.6 pre2 release candidate

[Stephan Wiesand]

Rich,

On Jan 8, 2014, at 20:06 , Rich Sudlow wrote:

 During our bi-annual mantenance outage last weekend we took the plunge and 
 upgraded our servers most running rh6.5+patches and 3 solaris 10
 (patched to latest patches) to 1.6.6pre2 (in addition to SineNomine's 
 EINVAL.patch for volserver which didn't make the release). Cell is
 crc.nd.edu - a little over 500 TB usable - 22 servers
 
 We also rebuilt or updated 1383 clients (all Red Hat 6.4 or 6.5+patches)
 
 This was done without incident and things have been running without for 3 
 days.

thanks a lot for your valor and the success report. The EINVAL patch (gerrit 
10447 as pointed out by Andrew) isn't accepted on the master branch yet and 
thus is really too late for 1.6.6 - sorry.

Our current plan is to release 1.6.6 within ~10 days, with no further changes 
except to the RPM spec file and possibly ripping out the server side NAT ping 
feature (unless we receive feedback that it actually helps somewhere). Thus, 
chances are that what you have deployed is very close to the 1.6.6 release.

Stephan

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] OpenAFS with future Linux kernel 3.13

[Stephan Wiesand]

On Dec 11, 2013, at 20:32 , Russ Allbery wrote:

 Jose Manuel dos Santos Calhariz jose.calha...@tecnico.ulisboa.pt writes:
 
 Is anyone using OpenAFS with the future Linux kernel 3.13?
 
 I need to use kernel 3.13.0-rc1 and 3.13.0-rc2 with OpenAFS for a OpenAFS
 fileserver, but I get compile errors:
 
 It's on my list to package OpenAFS 1.6.6pre1 (or pre2 if it's out) for
 Debian, but I'm not sure yet when I'll get to it.  Not that this helps a
 great deal for stable, since I won't do the backport until 1.6.6 final is
 out.


I think 1.6.5.1 should be sufficient. If it isn't, chances are the 1.6.5.2 
we're planning to have available soon will be.

NB If it's just a fileserver, the kernel module isn't required.

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] [ openafs-devel ] kernel panic

[Stephan Wiesand]

Hello Nicolas,

thanks again for the reports, but more information will be needed.

- What platform? (distribution, architecture)
- afsd parameters?
- How to reproduce?
- How reproducible is this? (= how confident are you that 3.11.7+1.6.5.1 is ok?)
- Any chance you could try 3.11.7 with 1.6.6pre1 and/or 3.11.8 with 1.6.5.1?
- Can you reproduce the problem with an ext4 cache?

Regards,
Stephan

On 2013-11-18, at 16:34, nicolas prochazka prochazka.nico...@gmail.com wrote:

 I've never seen this problem with previous version, but i do some
 update in same time
 
 kernel 3.11.7 + openafs 1.6.5.1   : no problem
 kernel 3.11.8 + openafs 1.6.6pre : problem
 
 
 I've test with  tmpfs , --memory , and zfs cache.   ( same issue with
 tmpfs and zfs  , with --memory, sometime the copy of file is stopped
 and cache does not grow anymore )  for cache system.  backing
 filesystem ( vicea ) is zfs.
 
 this problem appears to random way,
 it seems more frequents when i acces to afs mount , very soon after
 afsd is starting .
 
 Regards,
 
 
 
 
 
 2013/11/18 Stephan Wiesand stephan.wies...@desy.de:
 Hello Nicolas,
 
 thanks for testing 1.6.6pre1 before it's even announced!
 
 Could you give us more details about the client platform, cache 
 configuration and backing filesystem, and how you reproduce this crash?
 
 Are you sure you can't provoke this problem on 1.6.5.1, 1.6.5 or 1.6.3?
 
 Regards,
Stephan
 
 On 2013-11-18, at 14:33, nicolas prochazka prochazka.nico...@gmail.com 
 wrote:
 
 hello again, and sorry for the spam.
 After 30m of copy, the bug persist with 1.6.6pre1 module / afsd
 
 Regards,
 Nicolas Prochazka
 
 2013/11/18 nicolas prochazka prochazka.nico...@gmail.com:
 Hello again,
 some tests after,
 it seems to be a bad configuration in my side
 : use of openafs 1.6.6pre1 kernel module with openafs 1.6.5.1 afsd cache 
 daemons
 
 Regards,
 Nicolas Prochazka
 
 2013/11/18 nicolas prochazka prochazka.nico...@gmail.com:
 hello,
 
 setup  :
 openafs : OpenAFS 1.6.6pre1
 kernel 3.11.8
 
 when i start afsd ,
 [  231.083287] openafs: Can't get dentry
 [  231.083323] [ cut here ]
 [  231.083326] kernel BUG at
 /tmp/openafs-d294e9c/src/libafs/MODLOAD-3.11.8-MP/osi_file.c:53!
 [  231.083328] invalid opcode:  [#1] SMP
 [  231.083337] Modules linked in: libafs(PO) zfs(PO) zunicode(PO)
 zavl(PO) zcommon(PO) znvpair(PO) spl(O) [last unloaded: libafs]
 [  231.083347] CPU: 0 PID: 16582 Comm: ndvClusterManag Tainted: P
O 3.11.8 #1
 [  231.083348] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
 VirtualBox 12/01/2006
 [  231.083350] task: 8800a5267000 ti: 8800a1b2 task.ti:
 8800a1b2
 [  231.083351] RIP: 0010:[a02c3db6]  [a02c3db6]
 afs_linux_raw_open+0x96/0xf0 [libafs]
 [  231.083372] RSP: 0018:8800a1b21788  EFLAGS: 00010296
 [  231.083373] RAX: 0019 RBX:  RCX: 
 8277c488
 [  231.083374] RDX: 001f RSI: 0082 RDI: 
 0246
 [  231.083375] RBP: 8800a1b217a8 R08: 0400 R09: 
 8277c488
 [  231.083376] R10: 0266 R11: 0265 R12: 
 8800a945a000
 [  231.083377] R13: 8800a5267000 R14:  R15: 
 3b9ac9ff
 [  231.083387] FS:  7f3b75f51700() GS:88011fc0()
 knlGS:
 [  231.083389] CS:  0010 DS:  ES:  CR0: 80050033
 [  231.083390] CR2: 00458dc0 CR3: a1af8000 CR4: 
 06f0
 [  231.083395] Stack:
 [  231.083396]  00d0a5267000 88011fff c9000f5d6cc8
 8800a945a000
 [  231.083399]  8800a1b217d8 a02c3ec4 8800b8ed6000
 8800b8ed6000
 [  231.083401]  c9000f5d6c00  8800a1b21908
 a027f5f1
 [  231.083403] Call Trace:
 [  231.083412]  [a02c3ec4] osi_UFSOpen+0xb4/0x190 [libafs]
 [  231.083422]  [a027f5f1] afs_GetDCache+0x901/0x2380 [libafs]
 [  231.083439]  [8116159b] ? 
 __mem_cgroup_commit_charge+0xab/0x310
 [  231.083449]  [a029f433] ? afs_AccessOK+0x113/0x1e0 [libafs]
 [  231.083457]  [a02a975d] afs_lookup+0x38d/0x1c30 [libafs]
 [  231.083465]  [a029d3e4] ? afs_FindVCache+0x354/0x680 [libafs]
 [  231.083474]  [a029e18e] ? afs_GetVCache+0x7e/0x5d0 [libafs]
 [  231.083482]  [a02a6edc] ? afs_EvalFakeStat_int+0x32c/0x4e0 
 [libafs]
 [  231.083491]  [81f6890e] ? _raw_spin_lock+0xe/0x20
 [  231.083498]  [a02cc27b]
 afs_linux_dentry_revalidate+0x18b/0x450 [libafs]
 [  231.083506]  [a029f433] ? afs_AccessOK+0x113/0x1e0 [libafs]
 [  231.083514]  [a029bf89] ? afs_PutVCache+0x79/0x140 [libafs]
 [  231.083522]  [a029f67b] ? afs_access+0x17b/0x7d0 [libafs]
 [  231.083526]  [81010101] ? compat_arch_ptrace+0x191/0x220
 [  231.083529]  [81177325] lookup_fast+0x245/0x2f0
 [  231.083532]  [81177759] ? __inode_permission+0x69/0xc0
 [  231.083534

Re: [OpenAFS] [ openafs-devel ] kernel panic

[Stephan Wiesand]

 [  231.083598] ---[ end trace 3a0f610d92191038 ]---
 
 
 with kernel 3.11.7 i do not have this issues,
 but I must re test this case.

-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] client kernel panic on EL6

[Stephan Wiesand]

] ? system_call_fastpath+0x16/0x1b
 panic occurred, switching back to text console

-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15732 Zeuthen, Germany

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

Re: [OpenAFS] No buffer space available

[Stephan Wiesand]

On Jul 23, 2013, at 18:40 , Andrew Deason adea...@sinenomine.net wrote:

 On Tue, 23 Jul 2013 13:11:17 +0200
 Hans-Werner Paulsen h...@mpa-garching.mpg.de wrote:
 
 sometimes creating a file (using different programs) fails with the
 error message No buffer space available. This is on amd64_linux26
 with OpenAFS 1.6.2 (both client and server). Any idea?
 
 I don't see anywhere we'd be generating that error code (ENOBUFS), and I
 can't see how it would show up that way if we got it back from a socket
 or something. Do you have any idea if the machine is under a lot of load
 or memory pressure, or if the directory has a lot of entries in it?


To add a data point:

I just encountered this while copying two rather small files for the 1.6.5.1 
release from here (~ Berlin) to PENN-CENTRAL.SRV.CS.CMU.EDU.

% cp /tmp/openafs-release-* . -iv   
`/tmp/openafs-release-fedora-1.6.5.1-1.noarch.rpm' - 
`./openafs-release-fedora-1.6.5.1-1.noarch.rpm'
cp: cannot create regular file `./openafs-release-fedora-1.6.5.1-1.noarch.rpm': 
No buffer space available
`/tmp/openafs-release-rhel-1.6.5.1-1.noarch.rpm' - 
`./openafs-release-rhel-1.6.5.1-1.noarch.rpm'

So the first one failed. The destination file was created, but had length 0. 
The very next attempt succeeded. It's the first time I ever encountered this 
problem. Client is SL6.4, 2.6.32-358.18.1.el6.x86_64, OpenAFS 1.6.5.1 (built 
against the -358.el6 kernel - which I know voids my warranty ;-), disk cache on 
ext4.

Not reproducible, nothing in the logs or the kernel message buffer.

The client was not under any load and has 12 GB of free (really unused) RAM. 
The server seemed not to be busy either. The only special condition is the long 
distance between client and server.

No showstopper, and probably very hard to track down without a reproducer.


-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15732 Zeuthen, Germany

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

Re: [OpenAFS] Re: No buffer space available

[Stephan Wiesand]

On Oct 11, 2013, at 19:01 , Andrew Deason wrote:

 On Fri, 11 Oct 2013 17:36:52 +0200
 Stephan Wiesand stephan.wies...@desy.de wrote:
 
 I don't see anywhere we'd be generating that error code (ENOBUFS),
 and I can't see how it would show up that way if we got it back from
 a socket or something. Do you have any idea if the machine is under
 a lot of load or memory pressure, or if the directory has a lot of
 entries in it?
 
 For some reason I never looked at the actual value of this; I thought
 ENOBUFS was some low-numbered errno for some reason. But it appears to
 be 105, which is VNOSERVICE, which means this is probably due to
 idle-dead brokenness.
 
 Speaking to you in the context of 1.6 maintenance: this isn't really new
 (though this specific manifestation might be, I'm not sure). Gerrit 8462
 would help with it, and could possibly go into 1.6.6 if we want to do
 something about it. Actually fixing it was discussed in 8464; I just
 need to get around to actually implementing it sometime (none of the
 submitted patches in there are correct; a different solution is
 discussed somewhere in there). 
 
 To add a data point:
 
 I just encountered this while copying two rather small files for the
 1.6.5.1 release from here (~ Berlin) to PENN-CENTRAL.SRV.CS.CMU.EDU.
 
 I assume this was hanging for a little while before erroring out, yes?

Sorry, I really can't tell. When you copy files around a quarter of the globe, 
there are always delays. And as usual, I fired the command and then went on to 
something else. I'm fairly sure it didn't hang for more than about a minute 
though.

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] ZFS-on-Linux on production fileservers?

[Stephan Wiesand]

On Oct 4, 2013, at 18:08 , Dirk Heinrichs wrote:

 Am Freitag 04 Oktober 2013, 16:51:28 schrieb mi...@task.gda.pl:
 
 See my presentation about it last year.
 
 Link?

http://conferences.inf.ed.ac.uk/eakc2012/

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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

Re: [OpenAFS] Re: [ OpenAFS ] 1.6.x / module compilation / 3.11

[Stephan Wiesand]

On Sep 16, 2013, at 21:31 , Andrew Deason wrote:

 On Mon, 16 Sep 2013 23:13:34 +0200
 nicolas prochazka prochazka.nico...@gmail.com wrote:
 
 Hello,
 Why the git commit 1f577e41b65e9bd213a915a296ecf5bedd17fcc1  ( Linux
 3.11: Adapt to d_count changes )
 is only commit on master branch and not into the 1.6 stable branch ?
 
 It's already been proposed for the 1.6.x branch here:
 http://gerrit.openafs.org/#change,10241. Stephan Wiesand, the release
 manager, would be the best source of an answer to this, but I believe
 he's traveling with sporadic internet access right now,

Correct. Andrew, thanks for your response - I was indeed offline.

 so I can provide some guesses. Either:
 
 - The release manager just hasn't gotten to it yet (as mentioned, I
   believe he is traveling).

Correct.

 - We're waiting for more developers to review it.

Correct.

 - We're waiting for the people with sufficient access to do the
   necessary things for branching off for a 1.6.5.1 release containing
   just Linux support, which will be merged back into 1.6.x.

Correct. This has happened now, thanks to Simon.

To summarize, this change is not only headed for the 1.6 stable branch, we'll 
even create a point release to support that kernel.

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany

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