OK, this makes sense.  It's unfortunate, though.  We like to run
firewalls on each of our servers and to be pretty strict about what gets
through.  We'll have to implicitly trust certain IP addresses to get
updatesrv to work, or else implement one of your suggested workarounds.
Thanks for the quick feedback though.  I've added this info to the wiki.

..Patrick


On Tue, 2005-04-26 at 13:37 -0400, Jan Harkes wrote:
> 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
> 
-- 
Patrick Walsh
eSoft Incorporated
303.444.1600 x3350
http://www.esoft.com/