Re: Install on Debian Trixie (13)

On Mon, Jun 15, 2026 at 07:57:28PM +1200, Alex King wrote:
> I've tried to install coda on Debian Trixie, but it hasn't worked well yet.

I don't think this is a Trixie problem. Although the Debian package was
built for Bookworm, I'm running it on Trixie myself. Just have not had a
release of Coda since Trixie came out and it always takes a while to get
the package build up to speed after being unused for so long.

> I'm new to coda but want to play with it.
> 
> I've installed the Debian Bookwork (12) packages, from
> http://coda.cs.cmu.edu/coda/:
...
> I can create volumes, but not mount them.  I don't know if it's my own lack
> of knowledge, or if other stuff is not working:
> 
> # volutil getvolumelist
> V_BindToServer: binding to host juliet
> P/vicepa Hjuliet Tb1e708 F2fddb4
> Wp.codadocs.0 I64000001 H64 P/vicepa m0 M0 U2 W64000001 C6a2f1b84 D6a2f1b84
> B0 A0
> GetVolumeList finished successfully
> 
> # cfs mkmount /coda/project_codadocs p.codadocs
> /coda: File exists

Actually looks good, a lot better than you might expect. Part of the
problem is the sorry state of our documentation. What is happening here
is that a while ago, Coda introduced the concept of realms. And the way
this is done, is that there is a 'virtual volume' mounted at /coda/

That virtual volume is mostly read-only so you cannot create your own
volumes mountpoints there. What it does do it any lookup for a name that
has two or more '.' characters is taken as a domain name and Coda will
resolve that name to ip addresses and try to connect to those servers.

> # ls -l /coda/
> total 1
> lrw-r--r-- 1 root nogroup 21 Jun 15 09:12 juliet.king.net.nz -> '#@juliet.king.net.nz.'

This looks good, you looked for /coda/juliet.king.net.nz  the client
noticed that name looked a lot like a dns name, so it probably resolved
it to an ip address. It then tried to connect to a Coda server and asked
'what is your root volume'.

The default rootvolume name is '/', but it can be overriden by a writing
the name of the volume to /vice/srv/ROOTVOLUME on the Coda server. Since
your volumelist doesn't show any volumes aside from p.codadocs, there
was no volume to use as the root of your realm and so that is where it
got stuck. You could try to create a root volume on your server with
'createvol_rep'.

> From what I understand from cfs mkm, none of my users (codaadmin nor alex)
> have rights to mount anything on /coda:
> 
> # cfs la /coda/
>       System:AnyUser  rl

Correct the volume there is the virtual realm root volume whose contents
is constructed based on the realms your client happens to know.

> I suspect something isn't working right....
> 
> 
> So I tried connecting to the test server:
> 
> $ ls /coda/testserver.coda.cs.cmu.edu
> /coda/testserver.coda.cs.cmu.edu
> 
> $ clog [email protected]
> username: [email protected]
> Password:
> 
> $ ls -l /coda/testserver.coda.cs.cmu.edu
> lrw-r--r-- 1 root nogroup 29 Jun 15 19:50 /coda/testserver.coda.cs.cmu.edu
> -> '#@testserver.coda.cs.cmu.edu.'
> 
> 
> In /var/log/coda/venus.log I'm getting a bunch of:
> 
> [ W(13) : 0000 : 19:52:07 ] fsobj::TryToCover:
> vdb::Get(#@testserver.coda.cs.cmu.edu.) failed (110)

110 is connection timed out. It should work, but have to admit, I haven't
looked at our testserver in a while. I'll poke it to see what is going on
there. If there are GNUtls certificate check errors, your client may be
trying to connect through a TLS tunnel and maybe the certificate of the
server expired. With the default configuration it should have fallen
back to connecting with UDP, which doesn't use TLS or certificates.

> I also saw gnutls cert check errors, in venus.err:
> 
> setuptls:815 gnutls_session_get_verify_cert_status() --> 66 ((unknown error
> code))
> setuptls:822 gnutls_handshake(128.2.212.163) --> -348 (Error in the
> certificate verification.)
> 
> Any ideas?

A client should be able to connect to the testserver even over TLS, the
certificate root should have been installed as part of the coda-common
install in /etc/coda/ssl/Coda_CA.crt

That certificate was used to sign the realm certificates for
coda.cs.cmu.edu and testserver.coda.cs.cmu.edu. These are in turn used
to sign certificates for the individual servers, the server certificates
expire in a week, so I have a cronjob that refreshes them every 3-4
days.

Jan