On Wed, Dec 18, 2002 at 03:17:24PM -0500, Jan Harkes wrote:
> But it also makes things a bit difficult. For instance, the server still
> needs to bind to 0.0.0.0 or else it would miss packets on interfaces
> that came up after the server was started. The server also has to deal
> with interfaces that are brought down.
A server with interfaces going up and down? That should only happen
during administrational tasks, and then the administrator could inform
the server process (or just restart it). as i noted in an earlier mail,
for example isc bind is doing this, and it works rather will

> When you're not responding to a request, but initiating a transaction
> (server->server during resolution, or server->client while setting up
> the callback connection) you have to make a decision which socket to
> use. So in a way the application suddenly has to know a whole lot about
> how your network is routed etc.
>From what I saw so far, the server only addresses a client after the
client contacted the server first. Just send the request from the
interface the client sent it's packets to earlier. For the server-server
case you have to define the IP you want to send packets from (in the case
of bind) if you don't like the default choice.

> > > createvol_rep should be run on the SCM, and 'volutil' without a hostname
> > > connects to localhost. i.e. the server on SCM.
> > localhost resolves here to 192.168.0.1 while he rpc is sending from
> > 192.168.2.1... thus it fails
from coda-src/volutil/volclient.cc:156
    gethostname(s_hostname, sizeof(s_hostname) -1);

from man gethostname:
DESCRIPTION
       These functions are used to access or to change the host name of
       the current processor.

which is the same as `hostname` and in most cases != localhost

> > > >   * cfs mkmount works but it segfaults and locks the whole system. After
> > > >     rebooting, the mountpoint exists and everything is fine
> > > 
> > > Never had that happen to me. What linux kernel are you using?
> >
> > debian/sid, linux-2.4.0 + cryptoapi-0.1.0 + rsbac-1.2.1 (rsbac.org) +
> > super-freeswan-1.99-kb2 (www.freeswan.ca/code/super-freeswan/). Note
> > that this happens while running rsbac in softmode (i.e. the access
> > restrictions don't apply) and the rsbac system isn't complaining about
> > some security violations)
> 
> 2.4.0 or 2.4.20? I didn't think anyone ever used 2.4.0, it was a bit buggy.
missed the 2, sorry, it's 2.4.20

regards
-- jochen