[9fans] ftpd

[9fans] ftpd

[arisawa]

Hello 9fans,

The line:
	fd = dial(data,"20",0,0);
in ftpd.c may make a trouble when the server has two IPs.
For example, plan9.aichi-u.ac.jp and ar.aichi-u.ac.jp is the
same machine with different IPs.
I could not get data from plan9.aichi-u.ac.jp from my home,
because my machines are inside of a boardband router with IP
masquerade.

The following may fix the problem.

term% diff /sys/src/cmd/ip/ftpd.c ftpd.c
151a152
> static	char*	myip;
208c209
< 	if(argc)
---
> 	if(argc){
209a211,212
> 		myip = ends->lsys;
> 	}
1558a1562,1568
> 		if(myip){
> 			char buf[80];
> 			snprint(buf, sizeof buf,"%s!20", myip);
> 			fd = dial(data, buf, 0, 0);
> 		}
> 		else
> 			fd = dial(data, "20", 0, 0);



Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp

Re: [9fans] ftpd

[Boyd Roberts]

arisawa@ar.aichi-u.ac.jp wrote:
> The line:
>         fd = dial(data,"20",0,0);
> in ftpd.c may make a trouble when the server has two IPs.

I may be a bit out of context here but it must be remembered
that the IP addresses returned by the remote DNS are returned
in a random order, if we are talking unix BIND/named.

This was a design/implementation decision.

Does plan 9 allow you to specify the 'sort order' [a heuristic
in the client resolver library to get around these types
of problems]?

[9fans] The regular python question

[Matt H]

Hi,

just offering some encouragement to anyone who's fiddling with building
the python port.

"good work, keep it up, I'm counting on you :)"

And I'll happily volunteer to help to plan9ise some of the python written
libraries if that's the way to do it. (my plan9 c isn't worth
counting on just yet).


M

Re: [9fans] The regular python question

[Boyd Roberts]

Matt H wrote:
> just offering some encouragement to anyone who's fiddling with building
> the python port.
>
> "good work, keep it up, I'm counting on you :)"

Well, I have the start of a native port here on coma.  It's at the
point where the Plan 9 lib needs to be coded.  I have coded about
20 functions.  It's not real hard, just tedious (particularily
[gs]etgr*()).

The real hard part was getting configure out of the way, ignoring
junk, creating dependencies and mkfiles.  I wrote an rc script.

I had to stop all that once my 'copious spare time' (tm) ran out.

If I had some time I'd start again and with 2.2 as it's just been
released.

Just mk'd it.  Looks like it would probably load if I'd persisted
with the [gs]etgr*() glop [Modules/grpmodule.c].  Whether it would
run is another question.

Re: [9fans] The regular python question

[Boyd Roberts]

Russ has given me his 9P2000 version and I'm going to turn
it back into release 3 9P.  Doesn't look too hard;  I have
most of the code to do it already.

And yes, it's on the USB floppy VAIO he got to go.

Re: [9fans] The regular python question

[Russ Cox]

I have python working quite well on 9P2000 systems.
There is a small amount of backporting to be done
to get it going on 9P1 (third edition) systems, mostly very little
things like rewriting the dirstat calls.  If someone
wants to tackle that last bit, let me know.

Russ