http://www.nnseek.com/e/mailing.comp.coda-linux/ Posts for mailing.comp.coda-linux Thu, 18 Jan 2007 01:46:15 PST http://www.nnseek.com/ http://www.nnseek.com/img/64.png 64 64 NNSeek http://www.nnseek.com/e/mailing.comp.coda-linux/venus_crashed_my_data_are_zombies_82972947t.html http://www.nnseek.com/e/mailing.comp.coda-linux/venus_crashed_my_data_are_zombies_82972947t.html On Mer 17 janvier 2007 23:30, Jan Harkes a =E9crit :
> Ah, the CML is owned by the user that made the changes, the error log
> file (/usr/coda/etc/console or /var/log/coda/venus.err) may contain som=
e
> indication about that fact,
>
> Reintegrate pending tokens for uid =3D
>
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.

> If this is the case it should be as simple as getting tokens for that
> local user. Another reason for not reintegrating may be that there is a
> conflict, this should also get logged in probably in venus.log. Conflic=
t
> repair can be tricky especially when there are potentially a lot of
> conflicts (up to 4914 in your case). In either case you should be able
> to run

No conflict possible : I began all my backup with a purge of the volume.
From another client, I removed all the files/directories in it and
reintegrated ALL the CML. From a third client, I connected and the volume
was empty. So, all the file I copied in the replicated volume are new one=
.

> cfs checkpointml /coda/.../natalia
>
> which will create a local checkpoint (tar archive) that contains all th=
e
> files that we failed to reintegrate. This can be found as
> /usr/coda/spool//.tar, or
> /var/lib/coda/spool//.tar

This Idea is very interesting if the tarball reflect the real tree of
directories. I will try this evening, but I think it will not work. In
fact, Venus seems not to be able to access this volume anymore. But I don=
t
know the origin of the problem (corrupt files in RVM or Cache...). So
whatever the tree in the archive, I dont think venus will be able to buil=
d
it. I hope, I will try and tell you.

> If you were mostly creating files and everything is in that tar archive
> then it is possible to copy that tarball to a safe place and purge the
> modification log, or restart venus with a -init flag to really wipe it'=
s
> memory. And then untar the archive to get the remaining files copied.
I did not try a -init yet, but I prepared a full copy of the cache & spoo=
l
dir in order to restore it. I suppose that the tarball is to be untared i=
n
the cache dir ?

>
> cfs purgeml /coda/.../natalia # flush all non-reintegrated updates=
.
>
> If you still have the original data around, it may just be simplest to
> purge the CML / reinitialize venus, and use rsync -av to resume the
> copy, that should check if all the existing files were copied correctly
> by calculating it's checksum.

If only... I trusted coda and made a "mv" ! All my data are in this damn
cache dir ! :-(

I'll try the checkpoint method this evening and tell you what happens.

--=20
Francois Cerbelle
Bat. B10 - 6 r d'Andilly - 95600 Eaubonne
SFR: (+33/0) 603 015 512 - FBX: (+33/0) 871 777 756

Posted In: mailing.comp.coda-linux

no comments

Reply

]]> Thu, 18 Jan 2007 01:46:15 PST http://www.nnseek.com/e/mailing.comp.coda-linux/replication_server_problems_82888467t.html http://www.nnseek.com/e/mailing.comp.coda-linux/replication_server_problems_82888467t.html > [root@clusty1 ~]# purgevol_rep --kill /
> awk: $1 !~ /^/$/ { print }
> awk: ^ syntax error
> awk: $1 !~ /^/$/ { print }
> awk: ^ unterminated regexp

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

> VLDB created. Search lengths: RO 0, RW 0, BK 0.
...
> 15:24:50 VLDB_Lookup: cannot find "/"

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

Posted In: mailing.comp.coda-linux

no comments

Reply

]]> Wed, 17 Jan 2007 09:30:10 PST http://www.nnseek.com/e/mailing.comp.coda-linux/replication_server_problems_82836499t.html http://www.nnseek.com/e/mailing.comp.coda-linux/replication_server_problems_82836499t.html
On my client:
[root@clusty4 ~]# cfs whereis /coda/mytest.de
clusty1.mytest.de

This volume runs only on one server.

Jan Harkes wrote:
> If it only has a single replica, then the most reliable method is to
> remove the existing root volume and create a new one,
>
> purgevol_rep /
>
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

[root@clusty1 ~]# purgevol_rep --kill /
awk: $1 !~ /^/$/ { print }
awk: ^ syntax error
awk: $1 !~ /^/$/ { print }
awk: ^ unterminated regexp
V_BindToServer: binding to host clusty1.mytest.de
VRDB completed.
Fetching volume lists from servers:
V_BindToServer: binding to host clusty1
VLDB completed.

[root@clusty1 ~]# echo $?
0

So I hope it worked...
> createvol_rep / clusty1.mytest.de clusty2.mytest.de clusty3.mytest.de
>
> The client may complain a bit once it notices, so you may have to
> restart venus with -init.
>
[root@clusty1 ~]# createvol_rep / clusty1.mytest.de clusty2.mytest.de
clusty3.mytest.de
/ already exists as a replica on clusty1.mytest.de

[root@clusty1 ~]# echo $?
1

So it looks like that it has not worked for me now...

On the client after the purge:

[root@clusty4 ~]# l /coda/
total 11
dr-xr-xr-x 1 root nfsnobody 2048 Jan 17 10:38 .
drwxr-xr-x 24 root root 4096 Dec 8 11:19 ..
lrw-r--r-- 1 root nfsnobody 12 Jan 17 10:38 mytest.de -> #@mytest.de

[root@clusty4 ~]# cfs whereis mytest.de
mytest.de: No such file or directory


That' from /vice/srv/SrvLog:

15:06:41 AuthLWP-1 received new connection 1070537038 from
192.168.222.21:32807
15:06:41 client_GetVenusId: got new host 192.168.222.21:32807
15:07:41 AuthLWP-2 received new connection 324406173 from
192.168.222.21:32807
15:08:23 New Data Base received
15:09:01 VRDB created, 0 entries
15:09:24 New Data Base received
VLDB created. Search lengths: RO 0, RW 0, BK 0.
15:09:54 New Data Base received
15:14:01 Callback failed RPC2_DEAD (F) for ws 192.168.222.24:32839
15:14:01 Deleting client entry for user coda at 192.168.222.24.32839
rpcid 1618981832
15:14:01 Deleting client entry for user System:AnyUser at
192.168.222.24.32839 rpcid 1308783494
15:16:24 New Data Base received
15:22:04 Deleting client entry for user at 192.168.222.21.32807 rpcid
1070537038
15:24:42 AuthLWP-3 received new connection 22525779 from
192.168.222.24:32841
15:24:42 client_GetVenusId: got new host 192.168.222.24:32841
15:24:42 Building callback conn.
15:24:50 VLDB_Lookup: cannot find "/"
15:26:04 Deleting client entry for user at 192.168.222.21.32807 rpcid
324406173



Achim

Posted In: mailing.comp.coda-linux

no comments

Reply

]]> Wed, 17 Jan 2007 06:36:59 PST http://www.nnseek.com/e/mailing.comp.coda-linux/replication_server_problems_82824211t.html http://www.nnseek.com/e/mailing.comp.coda-linux/replication_server_problems_82824211t.html > [root@clusty4 ~]# cfs listvol /coda/mytest.de/
> Status of volume 7f000000 (2130706432) named "/"
> Volume type is ReadWrite
> Connection State is Connected
> Reintegration age: 4294967295 sec, hogtime 4294967.295 sec
> Minimum quota is 0, maximum quota is unlimited
> Current blocks used are 2
> The partition has 8191888 blocks available out of 8211208
>
> I stopped with your advice after the client setup. I haven't created any
> volumes. So I wonder now, if the /coda/mytest.de/ is now replicated over
> those three servers or not?

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.

If it only has a single replica, then the most reliable method is to
remove the existing root volume and create a new one,

purgevol_rep /

createvol_rep / clusty1.mytest.de clusty2.mytest.de clusty3.mytest.de

The client may complain a bit once it notices, so you may have to
restart venus with -init.

> It seems to be the same partition (blocks available). The superuser is
> able to store files on /coda/mytest.de/ (the root directory). I am
> confused a bit about that. Is the /coda/mytest.de/ also replicated?

It is replicated, but probably only on a single site. There is some code
that should allow us to grow or shrink existing replicas, but it is not
always as reliable when we grow from a single replica since those
volumes don't have resolution logs associated with their directories.

> Is it the best way to setup only volumes under
> /coda/mytest.de/ and not to put files directly there?

Actually having a replicated root is useful for clients that are
starting up when your current SCM is unavailable, or when it's harddisk
dies.

All servers will have a copy of all the volume and user information, so
even with a dead harddrive you can recover. Any server can become SCM by
changing /vice/db/scm and restarting the auth2 and update daemons on all
servers in your Coda realm.

Jan

Posted In: mailing.comp.coda-linux

no comments

Reply

]]> Wed, 17 Jan 2007 05:38:19 PST http://www.nnseek.com/e/mailing.comp.coda-linux/venus_crashes_upon_ls_coda_82819859t.html http://www.nnseek.com/e/mailing.comp.coda-linux/venus_crashes_upon_ls_coda_82819859t.html > It did help. It's now working, even if I'm still flabbergasted as to
> why it was looking for the old address instead of the current one.
> But, following your instructions, it definitely looked like a name
> resolution problem or something along those lines.

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

Posted In: mailing.comp.coda-linux

no comments

Reply

]]> Wed, 17 Jan 2007 05:24:59 PST http://www.nnseek.com/e/mailing.comp.coda-linux/venus_crashes_upon_ls_coda_82669075t.html http://www.nnseek.com/e/mailing.comp.coda-linux/venus_crashes_upon_ls_coda_82669075t.html 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:
>
> Jan 16 14:20:54 alinex-7TX2Oz kernel: coda_read_super: device index: 0
> Jan 16 14:20:54 alinex-7TX2Oz kernel: coda_read_super: rootfid is
> (00000001.ff000001.
> 00000001.00000001)
> Jan 16 14:20:54 alinex-7TX2Oz kernel: coda_read_super: rootinode is
> 1049600 dev coda
> Jan 16 14:23:08 alinex-7TX2Oz kernel: coda_upcall: Venus dead on
> (op,un) (10.10) flag
> s 10
> Jan 16 14:23:08 alinex-7TX2Oz kernel: No pseudo device in upcall
> comms at e0b8d420
>
> From googling around and digging on this list, I've learnt that
> this happens because venus dies and the kernel module can no longer
> talk to it, but I'm clueless as to why exactly it happens.
>
> Am I doing something awfully wrong here? I'll be happy to provide
> whatever logs and additional info you may want to see.
>
> Thanks in advance,
>
> Paulo

Posted In: mailing.comp.coda-linux

no comments

Reply

]]> Tue, 16 Jan 2007 07:40:58 PST http://www.nnseek.com/e/mailing.comp.coda-linux/venus_crashes_upon_ls_coda_82668307t.html http://www.nnseek.com/e/mailing.comp.coda-linux/venus_crashes_upon_ls_coda_82668307t.html
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:

Jan 16 14:20:54 alinex-7TX2Oz kernel: coda_read_super: device index: 0
Jan 16 14:20:54 alinex-7TX2Oz kernel: coda_read_super: rootfid is
(00000001.ff000001.
00000001.00000001)
Jan 16 14:20:54 alinex-7TX2Oz kernel: coda_read_super: rootinode is
1049600 dev coda
Jan 16 14:23:08 alinex-7TX2Oz kernel: coda_upcall: Venus dead on
(op,un) (10.10) flag
s 10
Jan 16 14:23:08 alinex-7TX2Oz kernel: No pseudo device in upcall
comms at e0b8d420

From googling around and digging on this list, I've learnt that this
happens because venus dies and the kernel module can no longer talk
to it, but I'm clueless as to why exactly it happens.

Am I doing something awfully wrong here? I'll be happy to provide
whatever logs and additional info you may want to see.

Thanks in advance,

Paulo

Posted In: mailing.comp.coda-linux

no comments

Reply

]]> Tue, 16 Jan 2007 07:38:06 PST http://www.nnseek.com/e/mailing.comp.coda-linux/replication_server_problems_81566995t.html http://www.nnseek.com/e/mailing.comp.coda-linux/replication_server_problems_81566995t.html > Have you guys any further advice? Should i reinstall the whole thing?
> Somehow i am completely stuck here...
>
> As we can see in my last mail volutil.tk has the same values as shown by
> od.

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

Posted In: mailing.comp.coda-linux

no comments

Reply

]]> Wed, 10 Jan 2007 12:29:44 PST http://www.nnseek.com/e/mailing.comp.coda-linux/getting_started_with_coda_on_amd64_26445587t.html http://www.nnseek.com/e/mailing.comp.coda-linux/getting_started_with_coda_on_amd64_26445587t.html
On Tue, Dec 19, 2006 at 03:53:42PM -0500, Brian DeRocher wrote:
> I created a new user brian with pdbtool, but i can't change his
> password with au. I get the same output four different ways.

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"

> I do have an MIT Kerberos KDC running on this machine, but Coda doesn't
> use it, right?

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.

Those changes have not yet been done.

Going with Kerberos lets you use possibly existing (Kerberos) account databases
and/or password administration tools, otherwise there is little need for it.

Regards,
Rune

Posted In: mailing.comp.coda-linux

no comments

Reply

]]> Wed, 20 Dec 2006 03:54:25 PST http://www.nnseek.com/e/mailing.comp.coda-linux/getting_started_with_coda_on_amd64_26270483t.html http://www.nnseek.com/e/mailing.comp.coda-linux/getting_started_with_coda_on_amd64_26270483t.html
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.

When i start up venus, it mounts /coda. I added my realm to
/etc/coda/realms and i can view /coda/naturals/ which is empty.
I can also view /coda/coda.cs.cmu.edu/ and its files.

I created a new user brian with pdbtool, but i can't change his
password with au. I get the same output four different ways.

two:/# au [-x] [-h two.naturals] cp
Your Vice name: admin
Your password:
RPC2_Bind() --> RPC2_SUCCESS
User name: brian
New password: ********
AuthChangePasswd() --> AUTH_FAILED

/vice/srv/SrvLog is not updated.
/vice/auth2/AuthLog has this
Starting Auth Server......

Date: Tue 12/19/2006

15:26:38 Server successfully started
15:27:17 vid = 22
15:27:17 AuthNewConn(0x4113dc58, 0, 66, 2, -1)


clog seems to work.

two:/# clog admin
username: admin@naturals
Password:
Invalid login (RPC2_NOBINDING (F)).
two:/# echo $?
1
two:/# clog admin
username: admin@naturals
Password:
two:/# echo $?
0

two:/coda/naturals# touch a
touch: cannot touch `a': Permission denied

two:/coda/naturals# cfs la /coda/naturals
System:AnyUser rl
System:Administrators rlidwka

two:/coda/naturals# pdbtool list
USER System
* id: 1
* belongs to groups: [ -2 ]
* cps: [ -2 1 ]
* owns groups: [ -2 ]
USER admin
* id: 22
* belongs to groups: [ -1 ]
* cps: [ -1 22 ]
* owns groups: [ -1 ]
GROUP System:AnyUser OWNED BY System
* id: -2
* owner id: 1
* belongs to no groups
* cps: [ -2 ]
* has members: [ 1 ]
GROUP System:Administrators OWNED BY admin
* id: -1
* owner id: 22
* belongs to no groups
* cps: [ -1 ]
* has members: [ 22 ]
USER brian
* id: 23
* belongs to no groups
* cps: [ 23 ]
* owns no groups

Any idea what's going on here or what i can do to resolve these issues?

I do have an MIT Kerberos KDC running on this machine, but Coda doesn't
use it, right?


thanks,
Brian
--
Brian DeRocher
http://brian.derocher.org

Posted In: mailing.comp.coda-linux

no comments

Reply

]]> Tue, 19 Dec 2006 14:58:01 PST