[OpenAFS] Re: Moving Magic Trio to another domain

[Jukka Tuominen]

I'm currently trying to figure out the ldap part. With help, I got access to=
 the afs content without moving it. Users are reintroduced to krb, both afs a=
nd ldap preserved their user data.=20

I exported ldap data into a text file and replaced old domains with new ones=
. Then I imported it back. There is still something wrong there. E.g slapind=
ex only works when pointing specifically the slapd.conf file with -f argumen=
t.  Hmmm...? I grepped all old domain instances in /etc/ and replaced them, b=
ut something more needs to done or I've made a mistake or a typo somewhere.=20=


Br,jukka


Sent from my iPhone

> On 24.9.2013, at 23.12, Kim <dhk@ccreinc.com> wrote:
>=20
> Haven't followed the entire discussion, but I would use "vos dump=20
> | vos restore" to copy the data if this hasn't already been ruled=20
> out.
>=20
> Keeps ACLs/mountpoints/data ...
>=20
> Kim
>=20
>=20
>=20
> On Tue Sep 24 15:07:44 CDT 2013, Andrew Deason=20
> <adeason@sinenomine.net> wrote:
>=20
>> On Tue, 24 Sep 2013 22:50:47 +0300 (EEST)
>> "Jukka Tuominen" <jukka.tuominen@finndesign.fi> wrote:
>>=20
>>>> That shouldn't be the problem here. What actual errors are you
>>>> seeing?  Can you run 'fs lsm' on the things you can't seem to
>>>> access? (That is, 'services' and the homedirs)
>>>=20
>>> '/afs/[domain]/service' is a mount point for volume '#service'
>>>=20
>>>> fs: You don't have the required access rights on
>>> '/afs/[domain]/user/...'
>>>=20
>>> Also,
>>> fs la /afs/[domain]/service
>>> fs: You don't have the required access rights on=20
>>> '/afs/[domain]/service'
>>=20
>> Okay, I thought you meant they were just offline or something. If=20
>> that's
>> the problem, then it probably is related to authentication; it=20
>> seems
>> more like the authentication setup is broken, not related to the
>> migration. Are your tokens not working at all, then? (A way to=20
>> test
>> would be to try writing to, say, a new file in /afs/.cell/ )
>>=20
>> Do you know what the permissions on these dirs are supposed to=20
>> be?
>>=20
>> Do you see anything in syslog, or 'dmesg | tail' on the client=20
>> when you
>> try to access these?
>>=20
>>>> If you want to copy the data from a 'source' cell to a
>>> 'destination'
>>>> cell and you can have both available at the same time, you can
>>> use the
>>>> 'up' tool to copy the directory tree while preserving all of
>>> the
>>>> afs-specific information and avoiding endless loops.
>>>=20
>>> I understood the client pointing to two different domains with a
>>> single destiny. I can also switch between the two servers (old=20
>>> and
>>> new) one at the time, but I can't understand how the server can=20
>>> hold
>>> the two domains at once. When you destroy the krb data, or=20
>>> change the
>>> .confs, it only appears as one, AFAIK. Sorry...
>>=20
>> Sorry, I meant using two different actual machines for that=20
>> scenario
>> (using 'up' to copy the data between the two cells). You'd need=20
>> two
>> separate machines for that, or at least two different IPs, so=20
>> it's not
>> relevant if you only have the one machine to work with.
>>=20
>> It may be possible to do that with one machine by setting up=20
>> chrooted
>> servers bound to a different local IP, but... that's getting a=20
>> bit
>> complex :)
>>=20
>> -- Andrew Deason
>> adeason@sinenomine.net
>>=20
>> _______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>=20