Subject: [Dev] coda filesystems

From: Brent Verner <[email-masked]>
Date: Wed, 20 Feb 2002 02:19:43 -0500

Do any of you have any experience using coda filesystems?  More 
specifically, can the coda filesystem be used to 'mount' single 
files in an otherwise non-coda directory?

For those of you who do not know what coda is, go visit 
  http://www.coda.cs.cmu.edu/

quick buzzword intro...
   1.  disconnected operation for mobile computing
   2. is freely available under a liberal license
   3. high performance through client side persistent caching
   4. server replication
   5. security model for authentication, encryption and access control
   6. continued operation during partial network failures in server network
   7. network bandwith adaptation
   8. good scalability
   9. well defined semantics of sharing, even in the presence of network failures

thanks.
  brent

-- 
"Develop your talent, man, and leave the world something. Records are 
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing."  -- Duane Allman

---

From: Tanner Lovelace <[email-masked]>
Date: Wed, 20 Feb 2002 02:45:45 -0500 (EST)

>   Do any of you have any experience using coda filesystems?  More

I've been playing around with it a bit.

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

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.

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.

Tanner
-- 
Tanner Lovelace | [email-masked] | http://wtl.wayfarer.org/
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
   He who receives an idea from me, receives instruction himself
   without lessening mine; as he who lights his taper at mine,
   receives light without darkening me.  --  Thomas Jefferson

   Those who are willing to sacrifice essential liberties for a little
   order, will lose both and deserve neither. - Benjamin Franklin

---

From: Brent Verner <[email-masked]>
Date: Wed, 20 Feb 2002 03:03:09 -0500

[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.

| 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 ;-)

thanks.
  brent

---

From: Chris Hedemark <[email-masked]>
Date: Wed, 20 Feb 2002 07:23:04 -0500

You might get some more responses on the main trilug@list since this is more 
of a sysadmin question than a dev question.

---

From: Tanner Lovelace <[email-masked]>
Date: 20 Feb 2002 15:31:00 -0500

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):

> 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).
 
> 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-masked] | 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