[OpenAFS] Re: How to remove a bogus (127.0.1.1) server entry for readonly?

[Andrew Deason]

On Mon, 09 Dec 2013 12:50:20 -0600
John Tang Boyland <boyland@pabst.cs.uwm.edu> wrote:

> The server was a new server we set up because our old Solaris server
> couldn't be upgraded to 1.6.5.  I wrote a shell script to move
> all the volumes over and re-release them, but ... of course
> I made a mistake in the script and when I control-C'ed it, I
> interrupted a release which left the volume entry locked.
> When I then did the addsite, somehow between the entry being locked,
> and me unlocking it manually, it got the wrong IP address.
> It was two weeks ago (I was busy doing other things, and this
> wasn't a fire that needed to be put out...)  so I don't remember
> exactly what was happening, but I think all the addsites got
> bogus IPs and I was able to get rid of them and then NetRestrict.
> All except this one.

Is it possible you ran any of this with older 'vos' (that is, the 'vos'
from the old Solaris server), or you can this from a machine with that
127.0.1.1 hostname entry?

This probably has nothing to do with server registration and stuff; I
assume at some point you somehow just added an rosite with 127.0.1.1,
but no server ever advertised that address. That should be possible in
various scenarios, certain versions in play, etc.

> Interesting that from the server in question (peter.cae),
> the vos examine looks different:
> ...
>     number of sites -> 5
>        server peter.cae.uwm.edu partition /vicepa RW Site  -- New release
>        server solomons.cs.uwm.edu partition /vicepa RO Site  -- New release
>        server jeremiah.cs.uwm.edu partition /vicepc RO Site  -- New release
>        server peter.cae.uwm.edu partition /vicepa RO Site  -- Old release
>        server peter.cae.uwm.edu partition /vicepa RO Site  -- New release

This output is usually less confusing in situations like this if you run
with -noresolv, just by the way. But you've managed to figure it out
regardless :)

> ] However, if you really just want to get rid of the entry, it should be
> ] possible to work around this by temporarily changing the resolution of
> ] the local hostname to 127.0.1.1, and running the 'vos remsite' again
> ] (that is, put an entry in /etc/hosts like '127.0.1.1 myhostname'; just
> ] make sure to take it out quickly). 'vos remsite', of course, does not
> ] remove any actual volume data on the destination site, and just adjusts
> ] the vldb entry.
> 
> /etc/hosts has that entry already:
> 
> $ more hosts
> 127.0.0.1	localhost
> 127.0.1.1	peter.cae.uwm.edu	peter

Er, is this the only entry for 'peter'? Unless my mind is too scattered
to think properly at the moment, that's really not recommended, and I
think completely breaks the current way "vos" tries to avoid adding
loopback addresses in the vldb. I know various Linux distributions do
this by default, but that's only because they don't have a way of
knowing what the real IP is for the system, and they want the hostname
to be able to resolve. For a "real" server system, you'd want the
hostname to resolve to the actual public IP you use for it (either put a
real IP in there, or rely on DNS). Otherwise, various tools where you
specify the name 'peter' will get resolved to 127/8, and that's not good
if we're storing that in a distributed database like for AFS.

> ] 'vos' should probably do a couple of things to make this easier:
> ] 
> ]  - Print out that it's doing this loopback address translation thing (at
> ]    least with -verbose, but probably always?)
> ]  - Allow you to force specifying a loopback address if you really need
> ]    to. I'm not sure if that should be a separate option, or maybe just
> ]    avoid doing this for -noresolv?
> 
> Yes, that would be nice.  -noresolve seems the right flag.

I could see the case for a separate flag, to make really really sure
someone specifically wants this behavior; someone might just want
-noresolv so the output displays IPs. But maybe that's being overly
paranoid.

Anyway, if someone wants to track this or look into making these
changes, take a look at:
<https://rt.central.org/rt/Ticket/Display.html?id=131784&user=guest&pass=guest>

-- 
Andrew Deason
adeason@sinenomine.net