[OpenAFS] Re: vos move fails to work on new openafs fileserver, seems fine from other hosts

[Fred Drueck]

I have found the answer to my own problem; the issue was a line in the:

/etc/hosts

file like:

127.0.1.1 newserver.math.uic.edu newserver

So the AFS server was trying to talk to it's loopback address while
external hosts were connecting to the external IP address.

Mystery solved!

-Fred

On Thu, Apr 5, 2018 at 7:15 PM, Fred Drueck  wrote:

>
>
> On Thu, Apr 5, 2018 at 6:56 PM, Fred Drueck  wrote:
>
>> Hello other OpenAFS users,
>>
>> I've recently setup a new file server to try and facilitate upgrading our
>> OpenAFS servers to a newer version of debian (the current stable distro:
>> stretch).
>>
>> The server and db server setup seems to have gone smoothly, but I've got
>> problems with moving the AFS volumes.
>>
>> If I try to do a vos move from the old fileserver to the new one, the
>> move will fail with:
>>
>> Failed to move data for the volume 536881885
>>
>>VOLSER: Problems encountered in doing the dump !
>>
>> However, if I work on the old file server, or another openafs client
>> system (in fact, I've got another debian stretch system using the exact
>> same version the debian openafs-client package) I can move the volume to
>> the new server.
>>
>> And I can verify by looking at the /vicepc directory that the file is
>> there, the vldb says it's there but if I try to move the file back to the
>> older server working on the new server it will fail with a message that the
>> volume is not found, something like:
>>
>> The volume 536881885 is not on the specified site.
>> The current site is : server newserver.math.uic.edu partition /vicepc
>>
>> OK ... but that's exactly the arguments I passed to vos as the
>> -fromserver and -toserver
>>
>> And, if I switch over to another openafs-client or the old AFS file
>> server I can issue the vos command to move the volume back just fine.
>>
>> Anybody have any ideas what's going wrong?
>>
>> -Fred
>>
>
> Looking through the logs, the only thing I saw that looked maybe relevant
> was:
>
> Thu Apr  5 19:02:45 2018 VReadVolumeDiskHeader: Couldn't open header for
> volume 536881887 (errno 2).
>
> but if that's such a problem then why can the other AFS clients happily
> manipulate the volume?
>
> It's puzzling.
>
> -Fred
>

[OpenAFS] Re: vos move fails to work on new openafs fileserver, seems fine from other hosts

[Fred Drueck]

On Thu, Apr 5, 2018 at 6:56 PM, Fred Drueck  wrote:

> Hello other OpenAFS users,
>
> I've recently setup a new file server to try and facilitate upgrading our
> OpenAFS servers to a newer version of debian (the current stable distro:
> stretch).
>
> The server and db server setup seems to have gone smoothly, but I've got
> problems with moving the AFS volumes.
>
> If I try to do a vos move from the old fileserver to the new one, the move
> will fail with:
>
> Failed to move data for the volume 536881885
>
>VOLSER: Problems encountered in doing the dump !
>
> However, if I work on the old file server, or another openafs client
> system (in fact, I've got another debian stretch system using the exact
> same version the debian openafs-client package) I can move the volume to
> the new server.
>
> And I can verify by looking at the /vicepc directory that the file is
> there, the vldb says it's there but if I try to move the file back to the
> older server working on the new server it will fail with a message that the
> volume is not found, something like:
>
> The volume 536881885 is not on the specified site.
> The current site is : server newserver.math.uic.edu partition /vicepc
>
> OK ... but that's exactly the arguments I passed to vos as the -fromserver
> and -toserver
>
> And, if I switch over to another openafs-client or the old AFS file server
> I can issue the vos command to move the volume back just fine.
>
> Anybody have any ideas what's going wrong?
>
> -Fred
>

Looking through the logs, the only thing I saw that looked maybe relevant
was:

Thu Apr  5 19:02:45 2018 VReadVolumeDiskHeader: Couldn't open header for
volume 536881887 (errno 2).

but if that's such a problem then why can the other AFS clients happily
manipulate the volume?

It's puzzling.

-Fred

[OpenAFS] vos move fails to work on new openafs fileserver, seems fine from other hosts

[Fred Drueck]

Hello other OpenAFS users,

I've recently setup a new file server to try and facilitate upgrading our
OpenAFS servers to a newer version of debian (the current stable distro:
stretch).

The server and db server setup seems to have gone smoothly, but I've got
problems with moving the AFS volumes.

If I try to do a vos move from the old fileserver to the new one, the move
will fail with:

Failed to move data for the volume 536881885

   VOLSER: Problems encountered in doing the dump !

However, if I work on the old file server, or another openafs client system
(in fact, I've got another debian stretch system using the exact same
version the debian openafs-client package) I can move the volume to the new
server.

And I can verify by looking at the /vicepc directory that the file is
there, the vldb says it's there but if I try to move the file back to the
older server working on the new server it will fail with a message that the
volume is not found, something like:

The volume 536881885 is not on the specified site.
The current site is : server newserver.math.uic.edu partition /vicepc

OK ... but that's exactly the arguments I passed to vos as the -fromserver
and -toserver

And, if I switch over to another openafs-client or the old AFS file server
I can issue the vos command to move the volume back just fine.

Anybody have any ideas what's going wrong?

-Fred

[OpenAFS] OpenAFS Release 1.8.0 available

[Benjamin Kaduk]

The OpenAFS Guardians are happy to announce the availability of the
first release in a new stable series of releases, OpenAFS 1.8.0.
Source files can be accessed via the web at:

https://www.openafs.org/release/openafs-1.8.0.html

or via AFS at:

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

The new stable relase branch includes sweeping changes throughout
the tree; please consult the release notes for full details.  Very
brief highlights include: a new KeyFileExt for long-term keys that
supersedes rxkad.keytab, a new (logrotate-compatible) log rotation
scheme, pthreaded ubik servers enabled by default along with other
pthread conversions, many additional code quality fixes spotted by
static analysis tools, the use of Heimdal's roken and crypto support
libraries, and API and file support for many configuration knobs.
This release also switches the client to use encryption by default,
to match many distribution packages and the Windows client, and
removes support for Linux versions prior to 2.6.

The changes since the last release candidate are just some
documentation updates, a build fix for FreeBSD clients, a fix for
ENOTDIR issues seen on RedHat 7.5 Linux, improvements to the RPM
packaging, and fixing a NUL-termination bug.

I would like to take this chance to thank the many people who worked
tirelessly to make this release happen: the developers contributing
code and code review, everyone who has tested and ran the
pre-release versions (including in production!), and the moral
support from everyone to help get the release finished.  There are
too many people to name them all, but know indeed that your efforts
are greatly appreciated!

Please assist the guardians by deploying and testing this release and
providing positive or negative feedback.  Bug reports should be filed
to openafs-b...@openafs.org ; reports of successes should be sent to
openafs-info@openafs.org.

Benjamin Kaduk
for the OpenAFS Guardians


signature.asc
Description: PGP signature