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

2018-04-13 Thread 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

2018-04-13 Thread 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