On Sun, Feb 04, 2001 at 04:24:30PM -0500, Brad Clements wrote:
> On 4 Feb 2001, at 16:11, Jan Harkes wrote:
> 
> > As far as server-server, updateclnt-updatesrv, and volutil-server are
> > concerned, Servers are assumed to be co-located (i.e. in the same
> > machine room), so they will have problems with firewalls. I don't think
> > that `fixing' this is very important as it actually improve security (or at
> > least obscurity) of these daemons behind a firewall.
> 
> Bummer.
> 
> Well I'm running 3 coda servers.. one of which is outside my firewall and 
> behind it's own firewall.
> 
> Soon I'll add a 4th server, also behind it's own firewall.
> 
> "Co-Located" probably isn't really the definition you mean. I suspect "well 
> connected" is a better requirement, in which case the number of 
> intervening firewalls shouldn't really matter. So long as the connectivity is 
> good.
> 
> In my case, it's good.. but I also need firewall security at both locations.
> 
> > > What's the best way to fix this?  Can someone point me towards the 
> > > offending sub-system or code? Maybe I can take a whack at the problem.
> > 
> > Eh, it doesn't really fall into any subsystem. It involves (at least)
> > the following daemons and applications: updateclnt, updatesrv, volutil,
> > codasrv, backup.
> 
> Oh boy.

Well, it isn't that bad really.

You need to have the following.

Replicate the /vice/db directory from the SCM to the other servers. This
is normally done by updateclnt/updatesrv, but can also be done by using
rsync or even scp. These shared databases are only updated when
creating/destroying volumes or when modifying user/group information. So
either a `pull-script' using a cron job, or less automated but probably
simpler a `push-script' after creating volumes/adding users. updateclnt
calls something like volutil newdatabases after the files have been
copied so that should be part of the script.

During volume creation, the SCM needs to get the volumelist from the
other servers. It uses volutil, which will always connect to 2432/udp on
the non-scm servers (from an arbitrary local port).

That pretty much should cover all volume/user related operation.

Then there is clog for which port 370/udp needs to be accessible on
those servers that are listed as `authservers' in venus.conf (when there
are no authentication servers defined, `rootservers' will be used).
There is currently an assumption that the first authentication server is
the r/w replica (i.e. the SCM).

Servers need to resolve between volumes, I believe this all goes between
their 2432/udp and 2433/udp ports.

For venus, access to 2432/udp is needed (2433 too when not using the
masquerade option). Coda's backups through firewalls are possibly
broken, but it might work, I'm not sure. And that `should' be it.

to summarize

    SCM:any/udp <> anyserver:2432/udp
    anyserver:2432/udp <> anyserver:2432/udp
    anyserver:2433/udp <> anyserver:2433/udp
    anyclient:any/udp <> anyserver:370/udp

    if masquerade:
	anyclient:any/udp <> anyserver:2432/udp
    else:
	anyclient:2430/udp <> anyserver:2432/udp
	anyclient:2431/udp <> anyserver:2433/udp

And copy /vice/db to any servers that are unable to run updateclnt.
Using an alternative mechanism.

Jan