Hello
 
the listen command you see should be run from the fossil console i think, see fossilcons(8)
 
you can configure fossil using fossil/conf to run the listen command on each boot
 
something like:
% fossil/conf /dev/sdC0 > flproto
add listen command to flproto
% cat flproto | fossil/conf -w /dev/sdC0
 
check the fossil man pages for the correct syntax.
 
slds.
 
gabi

 
On 1/9/07, Alberto Cortés <alcortes@it.uc3m.es> wrote:
I have a cpu/auth/fs server configured as the Wiki
("Configuring_a_Standalone_CPU_Server") suggests. I have created
some test user accounts.

I also have an standalone terminal (with its own fossil).

I can cpu from the terminal to the server (as any user).
I can drawterm to the server (as any user).

My problem(s):
I can not boot the terminal with the server as fs and auth:
(boot: can't connect to file server: connection timed out)
Also, I can not 9fs to the server.



Running "snoopy" and "netstat -n" on the server I have discovered
that my server is not a fs server at all. There is nobody
listening at tcp 564.

/rc/bin/service/!tcp564 launch exportfs which I belive is not
authenticated: if I rename /rc/bin/service/!tcp564 to
/rc/bin/service/tcp564 and reboot the server, my problem is
gone, I can 9fs to it and boot the terminal with the server
as fs and auth. But the user is not asked for a password when
booting :(.

Searching 9fans archive I have read that:

   disk/kfscmd 'listen tcp!*!564'

is this solutions to all my problems.

Also on the wiki (Setting_up_fossil) says:

   If you want to serve the network you can run the commands

       listen tcp!*!9fs
       listen il!*!9fs


but there are some things in kfscmd manpage that I don't fully
ubnderstands and prevent me from using the "disk/kfscmd" solution:

   listen [address]

       [...]
       This feature is intended to facilitate small
       networks of a couple machines in the situation when
       convenience is more important than performance. This
       command is only useful on machines with (possibly
       simulated) NVRAM, which needs to be readable to the kfs
       processes; see readnvram in authsrv(2). The production
       file server (see fs(4)) is strongly encouraged for
       anything more than casual use.
       [...]

So, how do I properly build a file server?


--
http://bach.gast.it.uc3m.es/~alcortes/index.html