Please note that I've redirected this to the main trilug list since this is not properly a development question, but more of a general linux filesystem question and more people there might have more ideas (as Chris suggested):
On Wed, 2002-02-20 at 03:03, Brent Verner wrote:
> [2002-02-20 02:45] Tanner Lovelace said:
> | On Wed, 20 Feb 2002, Brent Verner wrote:
> |
> | > Do any of you have any experience using coda filesystems? More
> |
> | I've been playing around with it a bit.
>
> cool deal!
>
> | > specifically, can the coda filesystem be used to 'mount' single
> | > files in an otherwise non-coda directory?
> |
> | No, I don't believe so. Coda requires a partition that
> | it can use for it's own stuff and it doesn't store the
> | files there like you would expect but more like a database
> | would store stuff.
>
> Yeah, I just got read an overview of the client-server protocol
> and inferred this fact.
>
> | For example, on the system I've been working with,
> | the clients mount the coda filesystem at /coda. Under
> | there, I have a directory called /coda/users/lovelace.
> | This is the same on whatever client I want to use.
> | I have a file who's full path is /coda/users/lovelace/test.
> | On the server itself, that file is located at
> | /vicepa/0/0/74. Coda manages the translation from
> | it's setup to the user viewed filesystem.
>
> right. this is similar to what I would like to do. I was
> thinking of mounting the clients at /.coda and symlinking
> the files I need 'shared' from their system locations.
That is certainly doable. UNC Computer Science department
does something like this for their setup (only with AFS,
not coda).
> | The reason it's setup like this is so it can do all
> | the cool stuff like disconnected operation, replication,
> | real-time backups, etc...
> |
> | One other thing. Getting a coda server up and running
> | is not for the faint of heart. It really helps if you
> | have a good knowledge of how AFS (the predecessor to Coda)
> | works beforehand.
>
> Specifically, what I'm looking to do is work around the
> lack of proper federated-auth-mechanism support across
> multiple systems -- linux, *bsd. I intend to have all
> account info in a PG database on one machine, and have
> a coda server on that machine present the appropriate
> files used by the getgr* and getpw* functions. If all
> this goes well, I'll implement a similar system to ease
> the hassle of maintaining multiple proftpd passwd/group
> files for our multi-virtualhost ftp set up at work -- I
> absolutely _loathe_ having to figure out /which/ passwd
> file has to be updated with the current system; there
> must be a less error-prone/painful solution, and maybe
> a coda hack will be that ;-)
>
Hmm... that sounds eminently doable. Let me try to describe
how one particular setup at unc works. This is a section
of the file system setup for people to install whatever
software they want (for multiple different achitectures).
Each computer has a section called /usr/local/contrib/moderated.
People in the right group can install software there.
/usr/local/contrib/moderated on each computer (linux, sgi,
sun, hp, etc..) is a soft link to /var/contrib/pathname.
In the /var/contrib/ directory, there are 3 links. ro/
points to a read-only copy of the files and rw/ points
to a read-write copy of the files (so the files can
be updated and not break installed systems).
/var/contrib/pathname normally points to ro/ but can
be changed to rw/ if needed for a particular installation
method.
Okay, so ro and rw point to specific places in
afs space. ro points to
/afs/cs.unc.edu/project/contrib/moderated/<arch>
where <arch> is the appropriate architecture for the
machine in question. Note that this is set by
afs permissions to be read only. rw/ points to
a read-write copy that can be copied over to the
read-only version using an afs release mechanism.
The different architectures it supports at the
moment are
common - for non-architecture specific files
hp - hp computers
hp64 - hp 64 bit computers
linux - linux computers
mips - mips computers
sgi - sgi computers (at least R5k)
sgi-mips4 - sgi computers before R5k (instruction set changed, I think)
solaris - Sun Solaris
sparc - Sun Sparc stations
Each architecture specific directory has the normal
setup of bin/ lib/ share/ etc... with links from
there to the appropriate directories in common for
things like share and info that don't change across
different architectures.
So, each computer can just consider
/usr/local/contrib/moderated/{bin,lib,share,man,info,etc...}
to be the normal directory it looks for things in
and everything is taken care of in afs space. Since
it's in afs space, afs handles the authentication
for access through its central authentication servers.
Since coda is fairly similar to AFS (being its *direct*
descendent) I would think this would work very well
with coda instead of afs.
Tanner
--
Tanner Lovelace | [EMAIL PROTECTED] | http://wtl.wayfarer.org/
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
GPG Fingerprint = A66C 8660 924F 5F8C 71DA BDD0 CE09 4F8E DE76 39D4
GPG Key can be found at http://wtl.wayfarer.org/lovelace.gpg.asc
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
Those who are willing to sacrifice essential liberties for a little
order, will lose both and deserve neither. -- Benjamin Franklin
History teaches that grave threats to liberty often come in times
of urgency, when constitutional rights seem too extravagant to
endure. -- Justice Thurgood Marshall, 1989
signature.asc
Description: This is a digitally signed message part
