Coda File System

Re: creating rep_volumes without success

From: Mohamed Alwakeel <mohamed.alwakeel_at_365corp.com>
Date: Tue, 5 Mar 2002 16:50:30 -0000
This is what happened when I did sh -x createvol_rep

sh -x createvol_rep u.server E0000102 /vicepa
+
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6
/bin:/root/bin:/usr/local/sbin
+ export PATH
+ prefix=/usr/local
+ vicedir=
+ . codaconfedit server.conf
++ ELF
createvol_rep: ELF: command not found
+ '[' x = x ']'
+ vicedir=/vice
+ '[' '!' -f /vice/hostname -o '!' -f /vice/db/scm ']'
++ cat /vice/hostname
++ cat /vice/db/scm
+ '[' mezzo1 '!=' mezzo1 ']'
+ '[' 3 -lt 2 -o 3 -gt 4 ']'
+ SERVERS=
+ NSERVERS=0
+ MAXSERVERS=8
+ VOLNAME=u.server
+ VSGADDR=E0000102
+ PARTITION=/vicepa
+ '[' '!' -f /vice/db/VRList -a -f /vice/vol/VRList ']'
+ touch /vice/db/VRList
+ '[' '!' -f /vice/vol/BigVolumeList ']'
++ awk ' $1 ~ /^[WRB]u.server$/  {print $1}' /vice/vol/BigVolumeList
+ '[' xu.server = x ']'
++ awk ' $1 ~ /^[WRB]u.server\.[0-7]$/  {print $1}' /vice/vol/BigVolumeList
+ '[' xu.server = x ']'
++ cat /vice/db/scm
+ volutil -h mezzo1 dumpvrdb /vice/db/VRList.new
V_BindToServer: binding to host mezzo1
VolDumpVRDB failed with Unknown RPC2 return code 200
+ '[' 255 -ne 0 ']'
+ echo 'Failed to dump the current VRDB into /vice/db/VRList.new'
Failed to dump the current VRDB into /vice/db/VRList.new



Any ideas ?

Thanks

----- Original Message -----
From: "Jan Harkes" <jaharkes_at_cs.cmu.edu>
To: <codalist_at_coda.cs.cmu.edu>
Sent: Tuesday, March 05, 2002 4:42 PM
Subject: Re: creating rep_volumes without success


> On Tue, Mar 05, 2002 at 03:59:14PM -0000, Mohamed Alwakeel wrote:
> > But root or any addional volumes dont replicate accross server to client
> > and vica versa, there are no errors on the logs and all seems to be o.k.
> > After days of learning how coda works I realised the setup scripts were
not
> > creating all the volume files, after doing an ls in /vice/vol this is
all
> > that was there :-
> >  BigVolumeList  remote
>
> I believe the rest is either in /vice/db, or created whenever volumes
> are created.
>
> >  createvol_rep u.server E0000103 /vicepa
> >
> > while vice server running but that generated strange error messaga:-
> > /usr/local/sbin/createvol_rep: ELF: command not found
>
> Ehh, what command is failing here? createvol_rep is a shell-script, so
> you can run it with sh -x createvol_rep to see where it fails.
>
> > V_BindToServer: binding to host mezzo1
> > VolDumpVRDB failed with Unknown RPC2 return code 200
> > Failed to dump the current VRDB into /vice/db/VRList.new
>
> Interesting, there is no RPC2 error code 200, maybe it is an error that
> came from the server itself, in which case there should be something in
> /vice/srv/SrvLog
>
> > Also I tried adding new volume no in VSGDB and trying above again and it
> > failed again, even if I use an existing volume no it also fails with
same
> > error.
>
> If you change anything in the /vice/db/servers or /vice/db/VSGDB files,
> you need to restart all servers. These files are only read during
> startup.
>
> > By the way there is some bugs in the src linux rpms, when I try to a rpm
> > rebuild it all seems to be o.k. but fails becuase path to init scripts
is
> > wrong and it cant find them so fails the rpm recompile/build, again this
is
> > with version 5.3.18 and 5.3.17, I have not tried any other versions.
>
> I don't know, I build the RPMs on a redhat 5.2 system, which is pretty
> old. It seems like anyone who is building from source simply skips the
> package it up in an RPM step.
>
> > Last question with the clog command is there anyway to get the tokens to
> > stay longer than the default which I think is 2 days ? or is there a way
> > just to avoid this and have it configured so you dont have to keep on
> > logging into client box every so often to keep on authenticating to
server
>
> Default is 25 hours, no they can't stay longer except if you modify the
> source, there is no way to avoid it, use a cronjob
>     ( cat /etc/coda-password | clog -pipe username )
>
> to keep authenticated to the server, security wise this is identical to
> having a srv.tab kerberos key in /etc.
>
> Jan
>
Received on 2002-03-05 11:52:24