Home Directory on Coda
From Codawiki
General
(You get a certain path to your home directory per "name service domain", i.e. computers sharing a common view of account information. Such "domain" can be as small as a single home computer or as big as several thousands computers at a corporation.)
By the way, do not be tempted to think about connecting this Unix name service concept to Coda (from time to time people ask about possible libnss_ modifications to deal with Coda), Coda ids and Unix ids are fundamentally incompatible with each other.
I can not stress this too much, there is a fundamental incompatibility. Unix "name service domain" always spans over a limited number of computers with common administration, while service of each Coda realm spans over all computers of the world and the same computer can use many independent Coda realms simultaneously. For reference, approaches like libnss-afs (http://deleuze.hcoop.net/~megacz/software/libnss-afs.html) are fundamentally inapplicable in a global context (this is essentially a clever hack to get some consistency in an AFS client campus managed and used together with a single AFS realm).
Now to the home directory path. It is unfortunately not you as a user but the "name service domain" administrator who sets the path and you may be unable to influence the choice.
This may imply that you get different home directories on different computers.
If you are lucky enough to be able to get a homedir path of your choice and if you have got a personal place on Coda, you may find it convenient to use that place as your home.
Caveats:
- Sometimes you will have to login twice, the first time lacking your home directory, doing clog to your home directory Coda realm and logging out/in again. Sometimes Venus will let you in without tokens to your cached home directory data. It should always do this but this is not implemented properly (yet?) so double login will often be necessary. (Not a big deal, but I would love to have this issue fixed!). [The AFS filesystem deals with this via libpam-afs (http://www.eyrie.org/~eagle/software/pam-afs-session/) but this postulates realm-specific client administration (as superuser). This would be of no use as soon as your home directory is in another Coda realm than the client administrator cares about. It is not necessary either as tokenless access to the cached data allows to make clog transparent.]
- Conflicts appear easily if you are not cautious. Check with "cfs fr ." and "cfs lv ." that you do not have CML entries before logout and especially before shutting down the computer.
- Be prepared to deal with conflicts. In most cases it is easy to remove a conflict together with the information which is causing the conflict, but you should make an extra (local?) copy of the not-yet-reintegrated files before doing e.g. "cfs purgeml ." or before playing with the "repair" command. "cfs discardlocal ." gets rid of one CML at a time and is very handy against conflicts - but make sure to have a copy of your precious data before discarding a corresponding CML!
- Some applications are particularly troublesome, you may need to learn how to configure them to make them Coda-compatible.
- Some applications insist on creating sockets under the home directory, this is a bad idea in general and very unsuitable on Coda particularly.
Once you have your files with you everywhere, you may want to let the whole environment follow you as well, using Dapty (http://www.dapty.com) from the Aetey (http://www.aetey.se/index.php?p=static&id=About&pg=002-About) guys who try to get their living using (and contributing to) Coda.
How to work around silly applications
Q: Conflicts on .bash_history are driving me nuts
A: In your bash startup file set
HISTFILE="$HOME"/.sh_history.`hostname`
If you are running Dapty (http://www.dapty.com), just add this line to your ~/.miljo/config
Q: How to do a corresponding operation with less (~/.lesshst)
A: In the same way, e.g. with:
LESSHISTFILE=-
Q: Conflicts again, now under .mozilla!
A: Presumably you tend to run browsers on several hosts at the same time, and they are unfortunately ignorant of file systems
- spanning many computers
- capable of being disonnected / without lock promises
Create separate browser profiles for each host you are using Mozilla on. If you want to share bookmarks - let the profiles include href-links to each other's bookmarks. The conflicts might happen but will be relatively rare - and can be dealt with by
cfs listlocal . # you see that the first CML entry refers to ..../.mozilla/...../appreg or similar cfs discardlocal . # usually you do not need the modifications
