Andreas Jellinghaus writes:
 > 
 > >  I've been running coda on Debian for some time now, and also created a
 > > set of debian packages (coda-client, coda-server, coda-backup,
 > > coda-doc). However, they do not have any postinstall-configuration.
 > 
 > great ! configuration is not so important, we can write a howto :-)
 > i saw man pages in the postscript docs. are these manpages also in the
 > sources (i ask, because i didn't see any)..

For now, you Debian guys get rpm2cpio and install the binary doc rpm
we have for Coda....

 > 
 > coda could help (if i understodd everything right) :
 >  - useing several 100 mb as cache will reduce network load a lot.
 >    after a reboot, coda can use the data again and will detect changes.
 >  - i still can mount the root from nfs, but then load the rest from
 >    coda, useing venus/cache. either i will move /opt and /usr to coda,
 >    or chroot to /coda

I would _love_ to continue to talk about this, because this would
indeed be _the_ killer application of Coda. 

 >  - not even root on a poolpc can access the homedirectories, unless he
 >    knows the password.



 > 
 > problems i see so far :
 >  - is coda stable enough
 >  - ticket expiry of 25h. for calculations lomger than 25h this could eb
 > 	a problem.
 >  - after login via xdm, the home direcotirs are still protected. so i
 > 	need to call some application in the global Xsession file, that
 >  	will ask for a password and clog.

Some students are working on a PAM module. 

 >  - coda servers don't hold data on normal filesystems, so during test
 >    phase, i need all data twice - once on ext2 for nfs export, and once on
 >    coda partitions

Indeed.

 >  - currently i export / but block several subdirs with "noaccess", and
 > 	mount /var from "/export/`hostname`/, becuase every server needs
 > 	its  own /var/tmp (/tmp is a symlink to /var/tmp), /var/log ...
 > 

 > how do other people administrate unix machines ?
 > the simplest solution, is to have a seperate installation on every
 > machine, and share only some parts via nfs or coda. many people use
 > nfsroot, so they have a central administration. but nfsroot requires a
 > fast network, and everything depends on the state of the nfs server.
 > 
 > how fast is coda (venus cache hits) ? i hope it will not be as fast
 > as direkt hard disk useage, but much faster than nfs.

It currently is a bit faster than NFS (a lot faster on reads), we are
working on WB caching, then it will be a lot faster.

 > 
 > with hoard a client machine will continue to work, if the server is down
 > for a few minutes.
 > 
 > so, what's left ?
 >  - i can't mount / as coda filesystem

Yup, good project.

You also don't have device file support in Coda, another good project.

 >  - i need a few config files in each pc's /etc to differ 
 > 	(inittab, XF86Config and Xserver)

We can adapt Coda for that easily -- compare the @sys facility.  There
is also general Linux VFS code to do expansion of special names: see
linux/fs/nametrans.c.  That's a cool idea. 

 >  - i need a per host /var tree, at least tmp, log, run, spool,
 > 	but share "lib"
 > 
 > but finding a way to have _one_ linux installation for a large group of
 > machines, would rock. suggestions ?
 > 
 > 
 > > My lastest packages are build from coda-4.3.13, but I should get it up
 > > to 4.4.0 this week. I can then send you my .dsc/.diff.gz files, if you'd
 > > like.
 > > 
 > > (About some of your compilation problems:
 > >  - You need to start the compilation using `make coda'
 > ah. i knew there was something. maybe "coda" should be the default
target ?

Yes!

 > 
 > >  - It's also better to compile the kernel module using the code included
 > >    with the 2.1 kernels, or from the linux-coda-4.4.0.tgz package).

Yes, so that's why the include "cfs/coda.h" are there.

 > 
 > yes, i'm running 2.1.90 with linux-coda 4.4.0 module.

2.1.91 seems to have eliminated some nasty freezes on my box.

-- Peter --

 > 
 > andreas