Re: [9fans] magic loopback

Re: [9fans] magic loopback

[Fco. J. Ballesteros]

:  > the many clients who open /srv/your-service), posting
:  > to /srv is dramatically less useful than announcing a
:  > network address: there's no way to keep clients separate.

There is. You could use a different file for each client, e.g., like
done with consoles.  Perhaps not the thing to do for venti, but
IMHO it could work well for other programs. (I hope, we are
using just that for the new omero :).

[9fans] magic loopback

[erik quanstrom]

/sys/src/9/boot/local.c:/configloopback contains a special hack to make
the venti configuration
	venti=tcp!127.1!venti
work.  but this code is only run if booting from a local fossil.  so,
if i boot from tcp or il, i have to fiddle around a bit before things
will work.  i'm not against putting a real ip address in the configuration,
but then when the dhcp server decides to hand out a different address,
fossil won't start.

what is the standard way of handling this situation?  is it reasonable
to suggest moving the loopback configuration into general network
setup?

- erik

Re: [9fans] magic loopback

[erik quanstrom]

sorry to reply to myself.  but because /net/ipifc/0/ctl exists, ip/ipconfig is not run to ask
for a *real* ip address.  the default termrc has this
	if(! test -e /net/ipifc/0/ctl)
		ip/ipconfig >/dev/null >[2=1]
which i changed to
	if(! test -e /net/ipifc/0/ctl || ~ 127.0.0.1 `{cat /net/ipifc/0/local})
		ip/ipconfig >/dev/null >[2=1]
to get things running.  am i missing something about how to configure fossil+venti
on a cpuf kernel or is this known?

- erik

Re: [9fans] magic loopback

[Richard Miller]

> am i missing something about how to configure fossil+venti
> on a cpuf kernel or is this known?

It's known: see http://groups.google.com/group/comp.os.plan9/msg/db3e6e93ff7f42da

Re: [9fans] magic loopback

[erik quanstrom]

i totally missed that one.  

this doesn't really seem to be an administration problem too me, though.  if fossl+venti on the
same machine is a common setup, shouldn't they should be able to communicate without the 
network stack?  this would eliminate the need for boot setting up 127.1.

- erik

Re: [9fans] magic loopback

[Richard Miller]

> if fossl+venti on the
> same machine is a common setup, shouldn't they should be able to communicate without the 
> network stack?

Venti doesn't speak 9p2000 (it has its own RPC protocol), so it can't
just be mounted from a local /srv like normal Plan 9 services.

Re: [9fans] magic loopback

[erik quanstrom]

i realize that venti doesn't speak 9p at all. but what i don't understand is
while what you say is theoretically true, there is currently no way
to tell venti to post to /srv.  venti demands and address (-a) that it announce(2)s.

why does venti not have a -s argument?  and, since you mention it,
why doesn't venti use 9p?  it would seem that authentication would be
critical if you're running venti on a separate machine from the fossil.
and it would seem that using announce wouldn't make sense if one
always ran fossil and venti on the same machine.

so what's the part that i'm missing?

- erik

On Tue Sep 19 03:08:52 CDT 2006, 9fans@hamnavoe.com wrote:
> > if fossl+venti on the
> > same machine is a common setup, shouldn't they should be able to communicate without the 
> > network stack?
> 
> Venti doesn't speak 9p2000 (it has its own RPC protocol), so it can't
> just be mounted from a local /srv like normal Plan 9 services.
> 

Re: [9fans] magic loopback

[Russ Cox]

/srv just connects file descriptors.  It doesn't have listen and announce.
So unless you are posting 9P sessions to /srv
(in which case the kernel takes care of multiplexing
the many clients who open /srv/your-service), posting
to /srv is dramatically less useful than announcing a
network address: there's no way to keep clients separate.

9P is not a very good model for Venti.  At best the 9P realization
would be a single file /venti-rpc that clients could open and
use to issue real RPCs.

Russ

Re: [9fans] magic loopback

[erik quanstrom]

okay.  i think i suffer from unix-domain-socket on the brain. :-)
also, i didn't realize that there was an interrpc-dependence in venti
communication.

one advantage of using 9p to encapsulate the venti rpc would be
that authentication would be much easier.  also, venti wouldn't require
a network stack.

how does one protect venti from unauthorized writes if the announce
address isn't on a real network rather than a loopback device?

- erik

Re: [9fans] magic loopback

[Russ Cox]

> one advantage of using 9p to encapsulate the venti rpc would be
> that authentication would be much easier.  also, venti wouldn't require
> a network stack.

9p doesn't specify the authentication protocol.
you could use factotum to authenticate on the
venti connection before speaking venti and
it would be just as trivial.

it's just that no one has felt the need to make venti that
much harder to use by throwing authentication
into the mix.

if you really care about not having a network stack
you could write a network equivalent of /srv.
but really, who runs without any network stack?

> how does one protect venti from unauthorized writes if the announce
> address isn't on a real network rather than a loopback device?

at the moment, there is no such protection in venti.

on the one server where i care a little, i use ip routes
to make sure that only the hosts i want to talk to me
can talk to me.

russ

Re: [9fans] magic loopback

[Charles Forsyth]

> the many clients who open /srv/your-service), posting
> to /srv is dramatically less useful than announcing a
> network address: there's no way to keep clients separate.

still, connecting two plan 9 applications on the same machine
through tcp/ip and its addressing seems gnomely crass.