On Tue, Apr 26, 2005 at 09:24:25AM -0600, Patrick Walsh wrote:
> 	While testing server firewall rules and checking traffic between two
> servers, I noticed some odd udp traffic.  It turns out that updatesrv is
> using ports that it shouldn't be.  updatesrv should be listening to the
> codasrv port, 2432 (as listed in /etc/services), but instead it's

No it shouldn't (and in fact it can't because codasrv is already using
port 2432. I'm not entirely sure why, but updatesrv doesn't use a fixed
port, but registers it's port with rpc2portmap. rpc2portmap in turn is
using a fixed port number.

So when updateclnt wants to contact updatesrv on the SCM it first sends
a query to <SCM>:rpc2portmap, which returns the port on which updatesrv
is listening.

> listening to these ports:
> 
> # lsof -P -i -n |grep updatesrv
> updatesrv 10956     root    3u  IPv4 6028190       UDP *:33802
> updatesrv 30339     root    5u  IPv4 5699700       UDP *:33756

That looks like you have 2 updatesrv processes running.

> 	It appears that the ports that updatesrv listens on are completely
> random and I have no way of knowing what ports to open on my firewall
> ahead of time.
> Is this correct?
    
    Yes

> Is there a way to force updatesrv to listen on a particular port?

    No, the assumption is that the communication between coda servers
    always goes over the same trusted part of the network. So both
    should probably be either behind the same firewall, or should have
    some sort of secure VPN connection between them in which case the
    random ports don't matter either.

> Or is there a range of ports that it will always be listening on?

    No.

However...

The only thing that updateclnt and updatesrv really do is to make sure
that all the files in /vice/db are copied from the SCM to the other
servers, and you could pretty much do this with any other mechanism.
rdist, rsync, scp, CVS, SVN, Arch, git. The only 'special' thing is that
if anything got updated, the server needs to be notified which can be
done with 'volutil updatedb'.

The following is a simple script that could be run on the non-scm
servers from crontab every 5 minutes or so. This does mean that it can
take up to 5 minutes before new users/volumes or changed passwords are
seen by all servers but for the rest it should work.

    rsync -a scm:/vice/db/ /vice/db
    volutil updatedb

(I'm not sure whether the SCM needs to get 'volutil updatedb' as well
to force it to reread the files).

Alternatively you could perform a push update from the SCM, which makes
sure that everyone gets the updates around the same time. This can also
be run by hand after creating new volumes or users to force the update,
in which case only password changes are propagated by the periodic cron
job.

    rsync -a /vice/db/ non-scm1:/vice/db
    rsync -a /vice/db/ non-scm2:/vice/db
    volutil updatedb
    volutil -h non-scm1 updatedb
    volutil -h non-scm2 updatedb

The volutil updatedb command is really only needed to force a reload of
the VLDB and VRDB files, any changes to the user/group database or
auth2.pw file are automatically seen as soon as the timestamp changes.

Jan