Andreas Jellinghaus wrote:
> 
> 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)..

I've included the man-pages which were included in the coda 4.0 sources
in my packages. They are not included with the last couple of source
package, as most of them are outdated.

> my idea how to use coda is :
> i have a linux server, and 80 pc's booting win* or linux.
> currently they boot win95, loadlin, linux, get the rootfs via nfs
> (readonly, it's / of the server), mount /var from the server (rw)).

<snip>

> 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
>  - not even root on a poolpc can access the homedirectories, unless he
>    knows the password.

Logfiles are not really suited to be stored on a coda-fs. As coda works
on a whole file-caching basis. Homedirs and /usr should live fine in a
coda-fs.

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

I think your best bet would be to stay mainly with the existing setup,
and start with readonly things on coda (f.i. /usr/bin and /usr/lib).

Then there is no need for reintegration or authentication. Hereby you'd
also mainly avoid the unstable parts of coda. Besides, it's probably
hard to keep the writable nfs-exported and coda-fs tree's in sync.

This should give a good start at reducing network load, while keeping
your setup centralized.

> 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.
> 
> with hoard a client machine will continue to work, if the server is down
> for a few minutes.

Even for a few days, my laptop rarely connects to my server and I
can do just about everything. You actually don't need hoard, except when
you want to `force' things into the cache.

> >  - 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, i'm running 2.1.90 with linux-coda 4.4.0 module.

The coda module in linux-2.1.90 is actually more recent than the one in
linux-coda-4.4.0.tgz.

> andreas


about coda-src/asr/parser
I _think_ I solved that by replacing the yacc with $(YACC) in the
Makefile

 y.tab.c: $(srcdir)/resolver.yacc
        yacc -d $<
	^^^^
	$(YACC)

where my YACC is defined as bison -y.

But as I can see from your __eh_pc, it might also be a problem of mixing
a c++ compiler with a cc linking step. Do you happen to use egcs, which
adds exception handling stuff to C++ code?


parser: ${OBJECTS} $(LIBS)
        $(CC) $(LIBFLAGS) ${OBJECTS} $(LIBS) $(LIBFLEX) -o parser
        ^^^^^
	 try with $(CXX)

Jan