1

Scenario: My home dir is on NFS, identities are in LDAP and authorization is via Kerberos. My NFS, LDAP and Kerberos servers are all VMs -- I'm stretching a little hardware a long way at home.

Life is Good ... until -- there's always an until -- my VM server down for maintenance (planned or worse) which then strips me of lots of conveniences for the maintenance/repair work.

For clarity here: $HOME and $USER are the normal, real ones while $CHOME and $CUSER are the local clones.

Option 1: rsync -av $HOME/ $CHOME/ Easy, but while sssd will cache my credentials for the offline period $USER points to $HOME (which is inaccessible) and not $CHOME.

Option 2: Similar but make $CHOME owned by $CUSER instead. Now $USER is denied access to $CHOME or, alternatively $CUSER is denied access $HOME. I can't use root because $HOME is exported with root_squash and I'd like to keep it that way.

Option 3: Like option 2 but use ACLs somehow. Shouldn't I be able to setfacl default ACLs on $CHOME before the first rsync and have them survive? Everything I've tried requires setfacl -R $CHOME again after each rsync and that seems like I'm just doing something wrong.

I really only need the one-way replication, but the best solution would be something like Unison so that this could move beyond a simple recovery/maintenance aid to also support our laptop using NFS while online at home but operating normally while offline.

Improve this question
2
  • Are USER and CUSER actually different numeric userids? They probably don't need to be.
    – Mark Plotnick
    Mar 11, 2015 at 8:04
  • Sorry, I forgot to mention that detail. I started out with both having the same UID, but then $CUSER from /etc/passswd became dominant over $USER from LDAP. I didn't want to reorder things is /etc/nsswitch.conf for fear of unleasing new problems. The more I think about this the more certain I become that there should be no $CUSER and that the best solution would be to do some bind-mount of $CHOME onto $HOME during the auto-mount. I have systemd at my disposal so maybe there's something I can leverage there.
    – JFlo
    Mar 12, 2015 at 18:49

1 Answer 1

Reset to default
1

A couple of variations on your option 2 seem plausible. I'll continue to assume you usually log in with $USER on $HOME, just like in your scenario. You've stated that you can't copy the files from $HOME to $CHOME because of permissions issues ($USER can't access $CUSER), and you can't bypass that with root because of your root_squash.

2a. Adjust the permissions for $USER and $CUSER such that they belong to a common primary group. Set the umask 002 for both so that they create files with group permissions the same as for the user. Update all files in $HOME and $CHOME so that the group ownership is this new group. Use rsync -avH --no-owner [--delete] $HOME/ $CHOME/ to copy changed files. Run a couple of cron jobs (one for $USER and one for $CUSER) to fix up errant permissions and group memberships of all files.

2b. Leave everything "as is", and copy the files from one account to the other using rsync from the client to itself, changing identity across the connection: rsync -avH [--delete] $HOME/ ${CUSER}@localhost:

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .