Back trying Coda again after a short respite (since 5.2.0, IIRC).

This time I'm serious, my files are spread across three machines and I
can no longer count on strong connections on the LAN.  (My dept's
techs assure me that _our_ routers and gateways are working fine, that
somehow the University Computer Center has a router with indigestion
and it can take our local network down, and did so 12 times last week
:-( often for 2-4 hours at a crack.  Sheesh.)

Anyway, I've CVS checkout'ed whatever is at the HEAD of coda, rvm,
rpc2, and lwp (at a couple of times over the last week), done

	sh bootstrap.sh && ./configure && make && make install

in each subdirectory with a successful build on a Gateway G6 (P-III
450E) running Debian unstable and Linux 2.2.10, a successful build on
a Gateway Solo 9300 (P-II 450) running Debian stable and Linux 2.2.14,
and a successful build on a Gateway P5-120 running Debian unstable
with Linux 2.2.14.  (If you have a database of builds I'd be happy to
be more specific about hardware and stuff.)  All separate checkouts
over a period of about a week.

Comments so far:

1. `make maintainer-clean' is happy, happy in ./lwp, ./rvm, and
./rpc2, leaving no cruft (although it does delete two INSTALL files
which are in CVS, not sure which).  The closest thing for ./coda,
`make distclean', leaves about a dozen pieces of cruft according to
CVS.

Debian likes to do `make distclean', or even more stringent cleaning,
after building source packages.  Me too.  Just compulsive, I
guess....  I can supply patches if you like.

2. I probably will make Debian packages for my personal use (so I can
move the coda stuff out of /usr/local into /usr).  I am unwilling to
commit to being a Debian maintainer (this will be the first serious
attempt at packaging for me), but will be happy to provide my skeletal
packages to a real maintainer for improvement, or to other users on an
"as-is" basis.  That is, there will be very little sanity-checking
done, and almost no attempt will be made to do automated server or
client configuration.  I just want something that will do dpkg
--install and dpkg --purge, and hopefully dpkg --remove, for me.

When I create a set of .debs (include source packages) I could post
here, unless the Coda maintainers would prefer a direct private
notification first.

3. I think that "startserver", possibly among others, would be
unacceptable for installation into /usr/sbin on Debian (too generic).
Alternatives would be a rename or a Coda executable library directory
under /usr/lib.  (This could be done for Debian only, I think.)

4. Also, the space in /usr is pretty tight for me; this got me into
trouble because running venus at the same time as a Debian update
filled up my /usr, and it just wasn't obvious why files were getting
truncated (with no errors that I could see in codacon or
/usr/local/coda/console) to 0 on write.  This needs better
documentation, I think.  (It's pretty clear on reflection that there
are a bunch of places where Coda can run out of space and so truncate
file writes, but the fact that it does so so silently was quite a
surprise.)

I would strongly prefer that all log files, RVM, RVM transaction logs,
Venus cache files, etc live under /var.  This can probably be easily
configured with autoconf options, and done automatically in Debian if
you prefer the /usr setup that is now the default.  Please note that
the File Hierarchy Standard that all Linux distributions claim
conformance to may mandate the relocation of these things to /var.
(This kind of policy issue would have to be settled before a proper
Debian packaging could be done.)

5. Check out this listing:

    tleepslib:/mnt/Projects/Coda# ls -l /coda
    total 9
    -rw-r--r--    1 500      nogroup         0 Apr 14 19:15 00BUGS
    -rw-r--r--    1 500      nogroup      2795 Apr 14 19:16 00README
    drwxr-xr-x    2 500      nogroup      2048 Apr 14 19:06 Projects
    drwxrwxrwx    2 root     nogroup      2048 Apr 14 19:07 Research
    drwxrwxrwx    2 root     nogroup      2048 Apr 14 19:06 Teach

`Projects' is a directory made with mkdir by the Coda administrator,
`Research' and `Teach' are volume mount points.  It's not obvious from
the docs that the Coda administrator account needs to be a real
account (that particular piece of sanity-checking I _would_ do in the
Debian config stuff).  Also, it seems strange to me that root needs to
own the volume mount points, but that seemed to be logically necessary
given that the Coda server volume management commands seem to need to
be done by root (that could just be an artifact of Debian _not_
putting /usr/sbin on PATH for ordinary users; I didn't try a fully
qualified path, or all the different combinations of commands by
different users).

6. BTW, if there was a coda-doc module in the CVS tree I would be more
than happy to putter around in the HOWTO and man pages, patching what
I could understand that seemed to be wrong or incomplete, adding
comments and examples, and annoying you with questions about what I
don't grok ;-)  (Is there an official place to send patches?)

7. After the mess described in 4., I moved the stuff from /usr to /var
and patched up with symlinks.  Venus started but a df hung on /coda.
This seems to be a kernel issue, as lots of stuff, including
completion of the VShutdown for codasrv, hung until rmmod'ing coda.
(umounting /coda was not enough.)  Venus otherwise seemed to be
working simultaneously.

Re-modprobe'ing and restarting both codasrv and venus still gives same
problem.

At least `killall -9 df' seems to work.  (But I wouldn't want to `kill
-9' codasrv!!)

Hm.  Today df'ing seems to work OK, although I haven't changed
anything (rebooted, or whatever) since the last time.  All my tokens
have expired, though.  clog'ing an ordinary user to codakami (the
Admin, the only Coda user I have at the moment) and ... df works
again.  Now clog'ing root to codakami, and ... df works again.
Weird.  Oh well....  (Of course df doesn't really work, it tells me
"9000000" which has nothing to do with any of my Coda capacities.  But
at least it doesn't hang without reporting the df for /coda like it
did on Friday.)

8. My experimental server is storing data in
/mnt/Projects/Coda/vicepa.  I assume there's nothing particularly
dangerous about this since I have fsck turned off on that partition.
(I don't particularly care if I lose all the test data in there, since
I plan to clear out a couple of partitions per the HOWTO when I start
doing serious relocation of data.  I will have a proper /vicepa in the
near future....)

9. All of the above is done with codasrv and venus both running on the
G6 P-III/450E.  I have also sucessfully connected from the notebook, and

10. Ah, the compile and install on the P5-120 is now finished.  Oh,
yeah; at least on my Debian systems, /etc/conf.modules is completely
ignored, except for a warning, in favor of /etc/modules.conf.

Furthermore, writing anything to /etc/modules.conf will get lost on
the next Debian update that involves modules (in particular, when it
invokes update-modules).  On Debian systems, you should write that
information to /etc/modutils/coda and then invoke update-modules.
Or you can mv /etc/conf.modules to /etc/modutils/coda and invoke
updatemodules, which is what I just (successfully tested) did.

11. Doing a CVS checkout of XEmacs into /coda/Projects/XEmacs.
chugga-chugga, chugga-chugga, ... slow, slow.  But then, everything in
my testbed Coda installation currently lives in one partition of one
ATAPI drive, one gets what one pays for ;-)

12. Seems I forgot to tell you how cool all this is.

			   VERY VERY COOL!!

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091

Hi, Owen!  Fancy meeting you here!