[OpenAFS] Re: How to remove a bogus (127.0.1.1) server entry for readonly? eply-to: boyland@uwm.edu

[John Tang Boyland]

Andrew Deason <adeason@sinenomine.net> wrote:
] On Mon, 09 Dec 2013 07:37:54 -0600
] John Tang Boyland <boyland@pabst.cs.uwm.edu> wrote:
] 
] > $ vos listaddrs
] > peter.cae.uwm.edu
] > solomons.cs.uwm.edu
] > jeremiah.cs.uwm.edu
] 
] Could you 'vos listaddrs -noresolve -printuuid' ?

$ vos listaddrs -noresolve -printuuid
UUID: 008a0a7a-a6f4-127c-bc-18-0101007faa77
129.89.50.57

UUID: 00674436-fc1a-1a71-82-8a-6c265981aa77
129.89.38.124

UUID: 001bca38-e388-1e03-b2-3c-cb3a5981aa77
129.89.143.70

] > I'm really surprised that "vos remsite" doesn't work.
] > What am I doing wrong?
] 
] The reason it doesn't work is because 'vos' has logic to convert any
] localhost-y address to the address the local hostname resolves to, to
] try and avoid people from adding localhost addresses into the vldb.
] 
] However, you shouldn't need to do this, and I'm a little confused as to
] how you got the vldb in this state. If you know what fileserver it is
] that registered the 127.0.1.1 address, and you NetRestrict it, when you
] bring the fileserver up, it should register its addresses properly in
] the vldb, and you wouldn't see that entry for 127.0.1.1 again.
] 
] But you also shouldn't need to NetRestrict that address, since the code
] for detecting the local addresses should ignore loopback-y addresses
] when the fileserver registers its addresses. Is there any more
] information you can provide on the server that did this, or how you got
] the vldb in this state?

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.

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

$ sudo vos remsite peter.cae.uwm.edu a common.usr.local -localauth -verbose
Deleting the replication site for volume 536873999 ... done
Removed replication site peter.cae.uwm.edu /vicepa for volume common.usr.local

That did the trick.  Thanks.
(The bogus entry came first, the good entry was preserved.)
...
    number of sites -> 4
       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  -- New release

] 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

But yes, your idea worked.  Thank you very much.

] '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.

Best regards,
John