> Hi Peter,
> 
> "Peter J. Braam" <braam_at_cs.cmu.edu> wrote:
> >| On Mon, 7 Sep 1998, Manuel Guesdon wrote:
> >| > 1) Sometime, when I try: kclog manu, I get:
> >| > 	<<Local login only, could not contact venus>>
> >| > 	Why ? (Venus is runnin on the client and the scm).
> >| 
> >| Your venus must have crashed: see /usr/coda/etc/console and
> >| /usr/coda/venus.cache/venus.log
> 
> /usr/coda/venus.cache/venus.log seems OK
> in /usr/coda/etc/console, I have a " root cannot acquire Coda tokens!"
> 

This is an unfortunate but currently necessary feature. Since the token
you get from `clog' is valid for ALL your current sessions, a root user
obtaining tokens will give access rights to all daemon processes running
as root as well.

The silly thing is, that root can make modifications as an unauthenticated
user in connected mode, and the same goes for disconnected mode, but you
need to authenticate to reintegrate. But then you cannot reintegrate the 
changes a root user made. (anybody say deadlock?)

The only solution right now is to make a checkpoint of the volume 
modifications the root user made, which creates a backup of all 
modifications to /usr/coda/spool/0/xxx.cml and /usr/coda/spool/0/xxx.tar:

  cfs checkpointml <path to volume>

Then purge the modification log:

  cfs purgeml <path to volume>

And then using the checkpointed cml and tarball redo the changes
(preferably as a non-root user ofcourse).

> >| > 2) If I do a "cfs mkmount /coda/pc/shiva pc.shiva" on the pc.shiva
> >| > server, on a client I can't see anything in /coda (with ls -l) but I
> >| > can open a file in /coda/pc/shiva/. Is it normal ?
> >| > 
> >| 
> >| You can ONLY see /coda files on clients. Servers do NOT server /coda, but
> >| server "invisible" stuff - hmm. 
> 
> It was a server with client too
> 

You made changes while disconnected, so they are not stored at the servers. 
Since the changes were made by `root' any chance of reintegration is blocked.

> I have found a bug in kclog:
> When you forget -host (i.e running "kclog -kerberos5 manuel" for exemple),
> It crach in krbsupport.c line 304 when calling gethostbyname in
> krb5GetSecret because hostname is null. The problem is that there is no
> test to verify that the host option was set in clog.c
> 
> Do I send bug reports to the list or... ?

The list is fine, there is also bugs_at_coda.cs.cmu.edu which should deposit the 
bugreports directly into a Jitterbug bug-tracking system.

Jan Harkes