Re: [9fans] replica/pull..

Re: [9fans] replica/pull..

[rsc]

> > I think you need to
> >
> > 	mkdir /n/sources
> > or
> > 	disk/kfscmd 'create /n/sources sys sys 555 d'
> I did that and it complained about /n/sources/replica dir, so I made one.
>
> It then complained about /n/kfs/dis/replica/client/plan9.log (structure
> was upto /n/kfs), so made the dirsa nd touched plan9.log too.

You didn't want to do that.
/n/sources and /n/kfs are mount points
that will get things mounted on them.

If you type 9fs kfs you should then see
many files in /n/kfs/dist.

You should probably remove the files
you created; they'll just confuse things.

	9fs kfs
	rm -r /n/kfs/n/kfs/dist		# NOTE THE DOUBLED /n/kfs !!!

Don't worry about messages about directories or files
not existing in /n/kfs or /n/sources until we settle
the auth problems.

Maybe you typed the wrong password.
Try this:

	auth/factotum
	srv -m tcp!sources.cs.bell-labs.com sources /n/sources

Be sure to type the password you used when you
created the account.  What user name did you use?
I don't see any obvious variants of ishwar in the
user list.

Russ

Re: [9fans] replica/pull..

[Ish Rattan]

On Tue, 28 May 2002 rsc@plan9.bell-labs.com wrote:

> > > I think you need to
> > >
> > > 	mkdir /n/sources
> > > or
> > > 	disk/kfscmd 'create /n/sources sys sys 555 d'
> > I did that and it complained about /n/sources/replica dir, so I made one.
> >
> > It then complained about /n/kfs/dis/replica/client/plan9.log (structure
> > was upto /n/kfs), so made the dirsa nd touched plan9.log too.
>
> You didn't want to do that.
> /n/sources and /n/kfs are mount points
> that will get things mounted on them.
>
> If you type 9fs kfs you should then see
> many files in /n/kfs/dist.
>
> You should probably remove the files
> you created; they'll just confuse things.
>
> 	9fs kfs
> 	rm -r /n/kfs/n/kfs/dist		# NOTE THE DOUBLED /n/kfs !!!
>
I did that and also removed /n/soources/plan9 dir

> Maybe you typed the wrong password.
> Try this:
>
> 	auth/factotum
> 	srv -m tcp!sources.cs.bell-labs.com sources /n/sources

I tried that and it went..

!Addingkey: ...
user[bootes]: ishwar
password: xxxxx

srv tcp!sources.cs.bell-labs.com: mount failed: authentication failed

Another attempt does not prompt and the authentication failure continues..

-ishwar

Re: [9fans] replica/pull..

[Ish Rattan]

On Tue, 28 May 2002 rsc@plan9.bell-labs.com wrote:
> Be sure to type the password you used when you
> created the account.  What user name did you use?
I used username: ishwar

does it have to be a valid account on the client too?

-ishwar

[9fans] Replica/pull..

[Ish Rattan]

If one wants to pull locally modified files too, what option is
there? I tried by renaming the files but complained that files
have been deleted so it won't update.

Also, I looked at /sys/log/auth entries for netkey failure to
connect to cpu/pcauth server, no logs are made. The only odd
line that I saw are of type:

	... keyfs starting warning: 3e0a1084 3e0894f4

If somebody is running a cpu/auth server correctly -- incoming
drawterm  connections can be made using netkey challenge/respnse,
do send me your /sys/src/9/pc/pcauth file (should it be pcppu file?).

Merry Xmas.

-ishwar

Re: [9fans] Replica/pull..

[Russ Cox]

     REPLICA(1)                                             REPLICA(1)

     NAME
          changes, pull, push, scan - client-server replica management

     SYNOPSIS
          replica/pull [ -cnsv ] name [ path ]
          replica/push [ -nv ] name [ path ]
          replica/changes name [ path ]
          replica/scan name [ path ]

     DESCRIPTION
          These shell scripts provide a simple log-based client-server
          replica management.  The server keeps a log of changes made
          to its file system, and clients synchronize by reading the
          log and applying these changes locally.

          These scripts are a polished interface to the low-level
          tools described in replica(8). See replica(8) for details on
          the inner workings of replica management.  These tools were
          written primarily as the fourth edition Plan 9 distribution
          mechanism, but they have wider applicability.  For example,
          they could be used to synchronize one's home directory
          between a laptop and a central file server.

          Replicas are described by configuration files.  The name in
          all the replica commands is a configuration file.  Paths
          that do not begin with /, ./, or ../ are assumed to be rela-
          tive to $home/lib/replica.  Configuration files are
          described below.

          Replica/scan is the only one of these programs that does not
          need to be run on the client.  It scans the server file sys-
          tem for changes and appends entries for those changes into
          the server log.  Typically it is run on a machine with a
          fast network connection to the server file system.

          Replica/pull copies changes from the server to the client,
          while replica/push copies changes from the client to the
          server.  (Both run on the client.)  If a list of paths is
          given, only changes to those paths or their children are
          copied.  The -v flag causes pull or push to print a summary
          of what it is doing.  Each status line is of the form
^[9             verb path serverpath mode uid gid mtime length
^[9          Verb describes the event: addition of a file (a), deletion
          of a file (d), a change to a file's contents (c), or a
          change to a file's metadata (m).  Path is the file path on
          the client; serverpath is the file path on the server.
          Mode, uid, gid, and mtime are the file's metadata as in the
          Dir structure (see stat(5)). For deletion events, the meta-
          data is that of the deleted file.  For other events, the

     Page 1                       Plan 9            (printed 12/25/02)

     REPLICA(1)                                             REPLICA(1)

          metadata is that after the event.  The -n flag causes pull
          or push to print the summary but not actually carry out the
          actions.

          Push and pull are careful to notice simultaneous changes to
          a file or its metadata on both client and server.  Such
          simultaneous changes are called conflicts. Here, simultane-
          ous does not mean at the same instant but merely that both
          changes were carried out without knowledge of the other.
          For example, if a client and server both make changes to a
          file without an intervening push or pull, the next push or
          pull will report an update/update conflict.  If a conflict
>>>       is detected, both files are left the same.  The -c flag to
>>>       pull causes updates to be resolved using the client's copy,
>>>       while -s specifies the server's copy.  Typically these flags
>>>       are only used when invoking pull with a specific list of
>>>       files that are known to be conflicting.

          Replica/changes prints a list of local changes made on the
          client that have not yet been pushed to the server.  It is
          like push with the -n flag, except that it does not check
          for conflicts and thus does not require the server to be
          available.

          The replica configuration file is an rc(1) script that must
          define the following functions and variables:

          servermount
               A function that mounts the server; run on both client
               and server.

          serverupdate
               A function that rescans the server for changes.  Typi-
               cally this command dials a CPU server known to be close
               to the file server and runs replica/scan on that well-
               connected machine.

          serverroot
               The path to the root of the replicated file system on
               the server, as it will be in the name space after run-
               ning servermount.

          serverlog
               The path to the server's change log, after running
               servermount.

          serverproto
               The path to the proto file describing the server's
               files, after running servermount.  Only used by scan.

          serverdb
               The path to the server's file database, after running

     Page 2                       Plan 9            (printed 12/25/02)

     REPLICA(1)                                             REPLICA(1)

               servermount.  Only used by scan.

          clientmount
               A function to mount the client file system; run only on
               the client.

          clientroot
               The path to the root of the replicated file system on
               the client, after running clientmount.

          clientlog
               The path to the client's copy of the server log file.
               The client log is maintained by pull.

          clientproto
               The path to the proto file describing the client's
               files.  Only used by changes. Often just a copy of
               $serverproto.

          clientdb
               The path to the client's file database, after running
               clientmount.

          clientexclude
               A (potentially empty) list of paths to exclude from
               synchronization.  A typical use of this is to exclude
               the client database and log files.  These paths are
               relative to the root of the replicated file system.

          As an example, the Plan 9 distribution replica configuration
          looks like:
              fn servermount { 9fs sources; bind /n/sources/plan9 /n/dist }
              fn serverupdate { status='' }
              serverroot=/n/dist
              s=/n/dist/dist/replica
              serverlog=$s/plan9.log
              serverproto=$s/plan9.proto

              fn clientmount { 9fs kfs }
              clientroot=/n/kfs
              c=/n/kfs/dist/replica
              clientlog=$c/client/plan9.log
              clientproto=$c/plan9.proto
              clientdb=$c/client/plan9.db
              clientexclude=(dist/replica/client)

          (Since the Plan 9 developers run scan manually to update the
          log, the clients need not do anything to rescan the file
          system.  Thus serverupdate simply returns successfully.)

          The fourth edition Plan 9 distribution uses these tools to
          synchronize installations with the central server at Bell

     Page 3                       Plan 9            (printed 12/25/02)

     REPLICA(1)                                             REPLICA(1)

          Labs.  The replica configuration files and metadata are kept
          in /dist/replica.  To update your system, make sure you are
          connected to the internet and run
              disk/kfscmd allow
              replica/pull /dist/replica/network
              disk/kfscmd disallow

          To see a list of changes made to the local file system since
          installation, run
              replica/changes /dist/replica/network
          (Although the script is called network, since changes is a
          local-only operation, the network need not be configured.)

     SEE ALSO
          replica(8)

     Page 4                       Plan 9            (printed 12/25/02)

Re: [9fans] Replica/pull..

[Russ Cox]

It occurs to me that all your auth problems
are consistent with the cpu server not being
able (or more likely, not knowing how) to
contact the auth server.  (I realize they're the
same machine, but that doesn't preclude this
from happening.)

Run auth/debug at the cpu server console
and see what it tells you.

Russ

Re: [9fans] Replica/pull..

[Ish Rattan]

Here is the output of /auth/debug and my /lib/ndb/local (as auth/debug
is complaining about auth server..). Thanks for your patience.

-ishwar
---

cpu% auth/debug
p9sk1 key: dom=cps.cmich.edu proto=p9sk1 user=bootes !hex? !password?
	cannot dial auth server: no auth server found for cps.cmich.edu
	csquery authdom=cps.cmich.edu auth=* failed
	csquery dom=cps.cmich.edu auth=''
	dial net!!ticket failed: cs: can't translate address
cpu% cd /lib/ndb
cpu% cat local

#
#  files comprising the database, use as many as you like, see ndb(6)
#
database=
	file=/lib/ndb/local
	file=/lib/ndb/common

ipnet=141-net  ip=141.209.0.0  ipmask=255.255.0.0  ipsubmask=255.255.240.0
	dns=141.209.1.22
	dnsdomain=cmich.edu

ipnet=131-net  ip=141.209.128.0  ipmask=255.255.240.0
	ipgw=141.209.128.1
	dns=141.209.131.10
	dnsdomain=cps.cmich.edu

ip=141.209.131.89  sys=gaya  ether=000347a5f14d  proto=il
	dom=gaya.cps.cmich.edu
	auth=gaya.cps.cmich.edu  authdom=gaya.cps.cmich.edu
	cpu=gaya.cps.cmich.edu

auth=sources.cs.bell-labs.com authdom=outside.plan9.bell-labs.com

---
On Wed, 25 Dec 2002, Russ Cox wrote:

> It occurs to me that all your auth problems
> are consistent with the cpu server not being
> able (or more likely, not knowing how) to
> contact the auth server.  (I realize they're the
> same machine, but that doesn't preclude this
> from happening.)
>
> Run auth/debug at the cpu server console
> and see what it tells you.
>
> Russ
>

Re: [9fans] Replica/pull..

[Russ Cox]

There's your problem.  The p9sk1 key your CPU
server is using has an auth domain of cps.cmich.edu.
The entry for your auth server (gaya, I'm assuming)
has an auth domain of gaya.cps.cmich.edu.

You need to change one or the other.  Either
change the machine key with auth/wrkey
and reboot, or change /lib/ndb/local and
echo -n refresh >/net/cs.

Russ

Re: [9fans] replica/pull..

[rsc]

> What TCP port will it be using (just in case its being blocked by our
> router)

We need to be able to dial out to TCP ports 564 (fs) and 567 (auth).

>     rsc> You are also having authentication problems.  What does
>     rsc> ndb/query authdom outside.plan9.bell-labs.com auth
>
> sources.plan9.bell-labs.com

I'm sure you mean sources.cs.bell-labs.com,
but I figured I'd point it out anyway.

Russ

Re: [9fans] replica/pull..

[rsc]

We probably mangled your pasword
when you created the account (you were
one of the earlier people to create an account).

I'll send you a new password.

Russ

Re: [9fans] replica/pull..

[rsc]

I think you need to

	mkdir /n/sources
or
	disk/kfscmd 'create /n/sources sys sys 555 d'

You are also having authentication problems.
What does

	ndb/query authdom outside.plan9.bell-labs.com auth

print?

Russ

Re: [9fans] replica/pull..

[Ish Rattan]

On Tue, 28 May 2002 rsc@plan9.bell-labs.com wrote:

> I think you need to
>
> 	mkdir /n/sources
> or
> 	disk/kfscmd 'create /n/sources sys sys 555 d'
I did that and it complained about /n/sources/replica dir, so I made one.

It then complained about /n/kfs/dis/replica/client/plan9.log (structure
was upto /n/kfs), so made the dirsa nd touched plan9.log too.

> You are also having authentication problems.
> What does
>
> 	ndb/query authdom outside.plan9.bell-labs.com auth
>
> print?
sources.cs.bell-labs.com

I can't ping outside.plan9.bell-labs.com, maybe it is not relevant?

The error message is now

srv tcp!sources.cs.bell-labs.com: mount failed: authentication failed
rm: /n/kfs/dist/replica/client/plan9.log: '/n/kfs/dist/replica/client/plan9.log' does not exist
rm /n/kfs/dist/replica/client/plan9.log: rm 432: '/n/kfs/dist/replica/client/plan9.log' does not exist

-ishwar

Re: [9fans] replica/pull..

[Adrian Tritschler]

>>>>> "rsc" == rsc  <rsc@plan9.bell-labs.com> writes:

    rsc> I think you need to mkdir /n/sources or

    rsc>  disk/kfscmd 'create /n/sources sys sys 555 d'

After creating the directory as above, a second attempt results in:

srv tcp!sources.cs.bell-labs.com: mount failed: Hangup
bind: /n/sources/plan9: '/n/sources/plan9' does not exist
servermount: bind 55941: bind

Is there a way of finding more details about why the mount failed?

What TCP port will it be using (just in case its being blocked by our
router)

    rsc> You are also having authentication problems.  What does
    rsc> ndb/query authdom outside.plan9.bell-labs.com auth

sources.plan9.bell-labs.com

        Adrian

---------------------------------------------------------------
Adrian Tritschler    mailto:Adrian.Tritschler@its.monash.edu.au
Microcomputers, Infrastructure Services    Tel: +61.3.990.54794
ITS Division, P.O. Box 28C              Mobile: +61.408.145.149
Monash University, Vic, Australia, 3800.   Fax: +61.3.990.54746
---------------------------------------------------------------

Re: [9fans] 9660srv

[Russ Cox]

> Uhhh.. How do I get a copy? My Plan9 machine isn't connected to the
> net, and I use SneakerNet(tm) to move files over from the family PC
> that is.

For this specific case it happens that we repackaged
the installation archive after I fixed 9660srv,
so you could download a new installation archive,
write it to a CD, mount the CD on /n/dist, and then run

	cp /n/dist/dist/replica/cd /tmp/cd
	chmod +x /tmp/cd
	disk/kfscmd allow
	replica/pull /tmp/cd
	disk/kfscmd disallow

I realize that's a large amount of data to grab
to get such a small fix (I would just live with the
broken 9660srv, in this case).

We don't have a good story for you in general.
We assumed that people would be connected to the
network while running Plan 9.  It would take a
non-trivial amount of work to reverse that
assumption.

Sorry.
Russ

[9fans] replica/pull..

[Ish Rattan]

On a standlone server the command

replica/pull -v /tmp/network produces the error:

srv tcp!sources.cs.bell-labs.com: mount failed: authentication failed
bind: /n/sources/plan9: '/n/sources' does not exist
servermount: bind 293: bind

(/tmp/network is the script posted here by rsc)

-ishwar