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.

On clusty1:
# volutil -h clusty2.mytest.de getvolumelist
V_BindToServer: binding to host clusty2.mytest.de
RPC2_NewBinding to server clusty2.mytest.de failed with RPC2_NOBINDING (F)

On Mon, Dec 18, 2006 at 10:35:05AM +0100, Achim Stumpf wrote:

That looks good.

...

And the server on clusty2 recognized the vicepa partition. So something
else must be going wrong here.

Hi,

On clusty1 (SCM):
# cat vicetab
clusty1.mytest.de /vicepa ftree width=256,depth=3
clusty2.mytest.de /vicepa ftree width=256,depth=3

On clusty2 (slave):
# cat vicetab
clusty1.mytest.de /vicepa ftree width=256,depth=3
clusty2.mytest.de /vicepa ftree width=256,depth=3

After that I have restarted the servers on both machines.
And on clusty1 (SCM):
# createvol_rep coda.rep clusty1.mytest.de/vicepa clusty2.mytest.de/vicepa
egrep: /tmp/vollist.1947: No such file or directory
egrep: /tmp/vollist.1947: No such file or directory
grep: /tmp/vollist.1947: No such file or directory
Found no partitions for server clusty2.mytest.de.

The same thing happened :o(

The SrvLog of clusty1 (SCM):
Date: Mon 12/18/2006

Hi Achim,

I think you need to have all vice partitions on all Coda servers
listed in the vicetab on your SCM. e.g.

clusty1.mytest.de /vicepa ftree width=256,depth=3
clusty2.mytest.de /vicepa ftree width=256,depth=3

Theoretically it is then replicated down to other servers with
updateclnt, but I found that in reality, this is not always the case,
and that I needed to manually replicate this file to all the servers.

Doing this "worked for me" when I was running a multi-server cell.

Regards, Sean
scaron@umich.edu

Jan Harkes wrote:

Hi Jan, ...

On Wed, Dec 13, 2006 at 08:44:20AM +0100, Achim Stumpf wrote:

Check if clusty2 is mentioned in the vicetab file. Also check it's
server log, maybe /vicepa is listed in vicetab, but the server it cannot
find the /vicepa partition or something.

Jan

u+codalist-p4pg@chalmers.se wrote:

On Tue, Dec 12, 2006 at 11:39:13AM -0500, Sean Caron wrote:

Sean,

you are right of course, but the original problem seemed to be that
volutil could not contact the corresponding server
(which suggests that either the volutil process or the server on clusty2
did not have access to the appropriate token, volutil.tk ?)

As createvol_rep runs volutil, it would fail as well.

Regards,
Rune