[9fans] pull

[9fans] pull

[Eric Smith]

[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

I'm sorry, I'm sure this is already very clearly documented somewhere.  I'm
a newbie and having a little trouble getting started.

I created a user and have the network up.

When I try to do 'pull' I'm asked for authentication (user/password).

When searching I've seen things like, "9p read factotum/ctl" -- just
assuming I'm supposed to type that in as written to read about how to
authenticate for 'pull' but it doesn't work -- neither for me nor glenda.

Sorry to be asking such a rudimentary question,
Eric

[-- Attachment #2: Type: text/html, Size: 563 bytes --]

Re: [9fans] pull

[Lluís Batlle]

[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]

(guessing) I think you need a new "mount" and "9fs" which support the -n
parameter (noauth).

Maybe you installed using an old iso?

I found the same problem when I installed plan9 the last days... I
downloaded the newer 386 mount binary, and I could manually mount sources.
Using /n/sources I copied the newer 9fs script, and I think then everything
worked fine. I don't remember copying a new pull script or so.

I'd like to read a few explanation about the introduction of noauth, and why
it wasn't there before. I've not found it in the 9fans list archives. Maybe
someone can clarify? Thanks in advance.

2006/4/6, Eric Smith <esmithmail@gmail.com>:
>
> I'm sorry, I'm sure this is already very clearly documented somewhere.
> I'm a newbie and having a little trouble getting started.
>
> I created a user and have the network up.
>
> When I try to do 'pull' I'm asked for authentication (user/password).
>
> When searching I've seen things like, "9p read factotum/ctl" -- just
> assuming I'm supposed to type that in as written to read about how to
> authenticate for 'pull' but it doesn't work -- neither for me nor glenda.
>
> Sorry to be asking such a rudimentary question,
> Eric
>

[-- Attachment #2: Type: text/html, Size: 1528 bytes --]

Re: [9fans] pull

[Russ Cox]

> I'd like to read a few explanation about the introduction of noauth, and why
> it wasn't there before. I've not found it in the 9fans list archives. Maybe
> someone can clarify? Thanks in advance.

Most of the time mount -n is not needed.
If the file server allows mounting without authentication
then the usual sequence of messages will discover this
without needing a special flag.  Your computer will say
"I want to mount as viriketo" and sources will say "never
heard of him; no authentication needed" and log you in
as none.  All is well.

The problem is that 99% of people running pull the first
time are logged in as glenda, and there *is* a glenda
account on sources.  So your computer says
"I want to mount as glenda" and sources will say "okay,
authenticate".  And then you drop into factotum doing
authentication, and the only successful way out is to
authenticate as someone.

I could get rid of the need for mount -n if I deleted the
glenda account from sources, but that's a bit involved
because those machines use glenda as the hostowner
(bootes).

Russ

Re: [9fans] pull

[Heiko Dudzus]

> You can ignore this message if you want, but I print it to make
> you wonder what's going on.  In this case, you should probably
> be running
> 
> 	replica/pull -v -c 386/9pcf /dist/replica/network
> 
> which will pull any files except skip past changes to 386/9pcf.
> 
> What you typed:
> 
> 	replica/pull -v -c 386/9pcf /dist/replica/network 386/9pcf
> 
> will not pull any changes.  It says "pull only files matching 386/9pcf
> (the last argument) but whenever you see a change to 386/9pcf,
> ignoring it in favor of the local version (the -c option)."

It's getting clearer to me.  What I wanted to say was: "Keep your eyes
on conflicts with 386/9pcf and resolve them with the clients version."

> At any point in time, replica/pull knows how much of
> /dist/replica/client/plan9.log it has successfully applied and
> can ignore on the next run.  It stores this information in
> /dist/replica/client/plan9.time.  Plan9.log is applied up to and
> including the line that begins with the numbers in plan9.time.

Ok. Thanks for the explanation.

Heiko

[9fans] pull - read this!

[Russ Cox]

THE OPTIONS TO PULL HAVE CHANGED - READ THIS MESSAGE!

I don't have the energy to explain the antiword behavior in full,
but I just made some changes that should make it less
likely going forward.

I changed the way -c and -s work in pull (which is really
replica/applylog for the purposes of this discussion).

Before, the only way to safely make pull remember that
it had done some -c stuff was to run replica/pull -vc
with no patterns and hope that no new server changes
had appeared since the last pull you did (usually seconds
before).  I made pull a little more aggressive about updating
its "I'm done with the log up to this point" time, but if
you get really far behind and are trying to catch up, it's
just not good enough.

Instead, I changed -c and -s.

Now, instead of -c and -s applying to all possible files
encountered, they take names as arguments and only
apply to those.  This means you can specify both on
a command line.

So for example, I just updated my own system:

	% pull
	sys/src/cmd/8c/txt.c: locally modified; will not update
	sys/src/cmd/venti/config.c: locally removed; will not update
	sys/src/cmd/venti/fmtindex.c: locally removed; will not update
	386/bin/replica/applylog: locally modified; will not update
	sys/src/cmd/replica/applylog.c: locally modified; will not update
	%

and then had to address the conflicts.  I wanted to keep
my venti changes but the others could be overwritten:

	% pull -c sys/src/cmd/venti -c 386/bin/replica \
		-c sys/src/cmd/replica -s sys/src/cmd/8c
	% pull
	c sys/src/cmd/8c/txt.c
	%

Because the options changed to take arguments, I had
to update /usr/glenda/bin/rc/pull and /rc/bin/replica/defs too.

If you have your own copy of glenda's pull script, 
you'll want to incorporate the changes.  Or just make
yours run hers:

	% cat /usr/rsc/bin/rc/pull
	#!/bin/rc
	exec /usr/glenda/bin/rc/pull $*
	% 

The man pages are updated too.

All this won't take effect until you do a pull and get the new files.

Russ

Re: [9fans] pull

[Heiko Dudzus]

Russ Cox wrote:
> I changed the way -c and -s work in pull

I have a strange thing with the new pull:

| # replica/pull -v -c 386/9pcf /dist/replica/network 386/9pcf
| stopped updating log apply time because of 386/bin/mkstate
| #

But 386/bin/mkstate neither exists on sources nor on the local
filesystem.

What's going on there?

Heiko

Re: [9fans] pull

[Russ Cox]

> Russ Cox wrote:
> > I changed the way -c and -s work in pull
> 
> I have a strange thing with the new pull:
> 
> | # replica/pull -v -c 386/9pcf /dist/replica/network 386/9pcf
> | stopped updating log apply time because of 386/bin/mkstate
> | #
> 
> But 386/bin/mkstate neither exists on sources nor on the local
> filesystem.
> 
> What's going on there?

You can ignore this message if you want, but I print it to make
you wonder what's going on.  In this case, you should probably
be running

	replica/pull -v -c 386/9pcf /dist/replica/network

which will pull any files except skip past changes to 386/9pcf.

What you typed:

	replica/pull -v -c 386/9pcf /dist/replica/network 386/9pcf

will not pull any changes.  It says "pull only files matching 386/9pcf
(the last argument) but whenever you see a change to 386/9pcf,
ignoring it in favor of the local version (the -c option)."  

At any point in time, replica/pull knows how much of
/dist/replica/client/plan9.log it has successfully applied and
can ignore on the next run.  It stores this information in
/dist/replica/client/plan9.time.  Plan9.log is applied up to and
including the line that begins with the numbers in plan9.time.

If replica/pull reads through the log but cannot update
plan9.time to mark that it has been through that part, 
then it prints something to tell you why.  In this case,
the part of the log yet to be applied mentions 386/bin/mkstate,
and you've instructed replica/pull only to pay attention to
log lines mentioning 386/9pcf, so it will not change plan9.time
to say that the log is fully applied (it's not!).

I'm sorry this is so confusing.  I don't have a better way
to explain it.  The new -s and -c options make things
so that you should never need to put arguments after
/dist/replica/network on a pull command line.

Russ

[9fans] pull

[ron minnich]

I've done some looking around but it's not clear how I use 'pull' to a
fossil. The basic command gets lots of kfs errors, since there is no kfs.

Is this the usual pilot error on my part or is it just not ready yet?

thanks

ron

Re: [9fans] pull

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

We use this script (in our /rc/bin/pull).
The magic I mention is whatever you have to do to convince
your fossil to allow wstats and ignore permissions for the
changes made while pulling. We use the allow command
we added to fossil, but you may have to import a connection
that has been created to allow such things.

#!/bin/rc

rfork ne

*** ADD HERE YOUR MAGIC to put fossil into allow mode
opt=()
clean=no
while(! ~ $#* 0 && ~ $1 -*){
	if (~ $1 -C)
		clean=yes
	if not
		opt=($opt $1)
	shift
}
if(~ $1 --)
	shift

replica/pull -v $opt /dist/replica/network $*

*** ADD HERE YOUR MAGIC to put fossil out off allow mode

exit ''

[-- Attachment #2: Type: message/rfc822, Size: 2417 bytes --]

From: ron minnich <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: [9fans] pull
Date: Thu, 9 Oct 2003 09:16:26 -0600 (MDT)
Message-ID: <Pine.LNX.4.44.0310090915200.2724-100000@maxroach.lanl.gov>


I've done some looking around but it's not clear how I use 'pull' to a
fossil. The basic command gets lots of kfs errors, since there is no kfs.

Is this the usual pilot error on my part or is it just not ready yet?

thanks

ron

Re: [9fans] pull

[mirtchov]

> I've done some looking around but it's not clear how I use 'pull' to a
> fossil. The basic command gets lots of kfs errors, since there is no kfs.
>
> Is this the usual pilot error on my part or is it just not ready yet?
>
> thanks
>
> ron

I love the 'history' comand!

here are the changes I've made to do pulls on fossil:

plan9-2% history -D /dist/replica/network
Jul  4 13:19:30 MDT 2003 /dist/replica/network 466 [bootes]
Jul  4 13:19:30 MDT 2003 /n/dump/2003/1009/dist/replica/network 466 [bootes]
/n/dump/2003/1009/dist/replica/network:13,15 c /n/dump/2003/0704/dist/replica/network:13,15
< fn clientmount { 9fs boot }
< c=/n/boot/dist/replica
< clientroot=/n/boot
---
> fn clientmount { 9fs kfs }
> c=/n/kfs/dist/replica
> clientroot=/n/kfs
Oct 24 11:43:35 MDT 2002 /n/dump/2003/0704/dist/replica/network 463 [bootes]
plan9-2%