On Mer 17 janvier 2007 23:30, Jan Harkes a =E9crit :

e

I am not at home and I can not test what you told me, but I can give some
extra info :
Yes there is such a line (vol u.natalia and uid 1001). But the cache file=
s
belongs to root:staff and event if I connect with the 1001 uid (natalia),
venus tell me it reintegrate changes, but nothing happens. No CML are
reintegrated, no network transfert occurs and the same message will
happen, later.

On Wed, Jan 17, 2007 at 03:30:58PM +0100, Achim Stumpf wrote:

Sigh, I clearly don't purge data often enough.

...

Ok, that is good. I guess the volume replica was successfully removed
from the 'volume location database'. So what went wrong was removing the
volume from the 'replication database'.

But that is pretty easy to fix,

- on your SCM edit /vice/db/VRList and remove the line that starts with /
- Then run 'volutil makevrdb /vice/db/VRList'

Jan

Hi,

On my client:
[root@clusty4 ~]# cfs whereis /coda/mytest.de
clusty1.mytest.de

This volume runs only on one server.

Jan Harkes wrote:

I got:
[root@clusty1 ~]# purgevol_rep /
Only testing, use 'purgevol_rep --kill /' to really purge the volume
Don't forget we were only testing
use 'purgevol_rep --kill /' to really purge the volume

On Tue, Jan 16, 2007 at 12:40:40PM +0100, Achim Stumpf wrote:

That is simple,

cfs whereis /coda/mytest.de

I think that the default setup created only a single replica, since the
volume got created when we set up the SCM before we had the other
servers up.

On Wed, Jan 17, 2007 at 10:46:37AM +0000, Paulo Andre wrote:

Good thing it works now. What worries me is that venus died like that.
It shouldn't be doing that and just return a symlink that points at
nothing to the user.

Jan

From running venus in conjunction with 'codacon', I've been able to
learn that the problem seems to be lying on the fact that venus is
trying to contact an host that doesn't exist anymore. This is
suspicious, because it seems to be a residue from a previous
installation. However, I've wiped everything I could think of in the
client and start with a clean slate but still it tries to connect to
that old address. Where can this be hidden?

Cheers,

P.

On Jan 16, 2007, at 2:25 PM, Paulo Andre wrote:

Hi,

I've been trying to get a coda server and client to happily talk to
each other but unfortunately it's been proving difficult. Everything
seems to be installed OK on both machines, and I can 'clog' just fine
from the client into the server. But then when I try to read /coda it
just hangs for about a minute and bombs out with:

prla@citidesk1:/var/lib/coda/cache$ ls /coda
ls: /coda/193.137.121.129: No such device

With 193.137.121.129 being the coda server. A quick glance at /var/
log/messages on the client tells me that:

On Wed, Jan 10, 2007 at 11:40:26AM +0100, Achim Stumpf wrote:

I saw that. So the failure to bind to the second server isn't an
authentication issue. I can only think of a couple of reasons why we get
a no-binding result.

1) there is no Coda server running on clusty2.
2) for some reason DNS or /etc/hosts is messed up and we end up trying
to connect to some other machine that isn't running a Coda server.
3) There is a firewall on clusty2 that is dropping/rejecting incoming
UDP packets to the codaserver port (2432/udp).

Jan

Hi Brian,

On Tue, Dec 19, 2006 at 03:53:42PM -0500, Brian DeRocher wrote:

User passwotrd management is not totally intuitive.

You have to

1. create an account with pdbtool
2. create a password record for the account with "au nu"
3. then you can reset a password with "au cp"

Not in a default configuration.

Coda can use it, but the current Kerberos-related code is mostly unmaintained
and hardly used by anyone (?), while the existing "new" support for Kerberos
did not yet made its way to the upstream codebase.

Coda and Kerberos identities can/should not in general be mapped one-to-one,
which implies a need for some changes in the way Coda handles accounts -
to be able to properly use Kerberos (as well as other authentication means)
without subsiding to its/their limitations.

Hello,

I'm trying to setup an amd64 coda server. Below i'll explain my
environment, the steps i've taken so far, and my issues :(

Server: AMD Opteron 265, 2GB ram, 1TB disk, hardware RAID, running
Debian stable (sarge) with a 2.6.17-mm6 kernel (for the areca driver)
coda kernel module loaded.

I started following the instructions here:
http://coda.wikidev.net/The_Coda_Administration_and_User_Manual

I downloaded, compiled, and installed these:
package version
liblua5.1-0 5.1.1-2
liblwp2 2.3
librpc2-4 2.4
librvm1 1.13
coda-server 6.0.16
coda-update 6.0.16
coda-client 6.0.16

vice-setup seemed to work ok. I'm using separate partitions for
rvm_log and rvm_data.