Hello Jan,

Sorry for late reply. I would like to thank you very much for guiding me. The steps you
told me really worked for me and my system is now configured and working fine.

Actually my problem was, that I was not sure if I was really getting some info from my
dns server or not. I forgot to add entry in the resolve.conf and after i added the dns
ip in resolve.conf I was able to connect to the DNS server and get information about the
coda server machines from there.

Also I realized that my resolve.conf entry should also be present on the machines on
which I plan to setup my coda server also, which I believe was missing from
documentation or it was not obvious. The coda server also fetches the realm name from
the dns only.

Anyways things are working quite right for me.

with regards,
Dhiraj Chawla


On Mon, 11 Aug 2008 19:25:04 -0400, Jan Harkes wrote
> On Tue, Aug 12, 2008 at 01:16:10AM +0630, dhiraj_c wrote:
> > I named the entry in DNS as testcoda.net because I want the realm to
> > be named (testcoda.net). I also put the entry in mararc file for dns
> > as testcoda.net and in file db.testcoda.net I added the entries for
> > both the servers.
> 
> I don't really know anything about maradns myself, but working from the
> bottom up would be,
> 
> 1) can you resolve server1.testcoda.net and server2.testcoda.net to ip
>    addresses. i.e.
> 
>     dig -t a server1.testcoda.net
> 
>     if this doesn't work then your /etc/resolv.conf is probably not
>     set up to use your own DNS server.
> 
> 2) once you can resolve the host names to ip addresses, we can short
>    circuit the realm -> host mapping by adding an entry to
>    /etc/coda/realms
> 
>    testcoda.net server1.testcoda.net server2.testcoda.net
> 
>    At this point you should be able to access your realm with cfs lv
>    /coda/testcoda.net. If this doesn't work the but the hostname
>    resolution worked, the servers may not be set up correctly yet.
> 
> 3) once we know that things work we can avoid having to add an explicit
>    entry to /etc/coda/realms on every client by adding the appropriate
>    SRV record to the testcoda.net DNS records. Not sure what maradns
>    wants, but effectively we want a successful result from the following
>    dns lookup,
> 
> 	dig -t srv _codasrv._udp.testcoda.net
> 
>    where a successful result would be something like,
> 
> 	_codasrv._udp.testcoda.net IN SRV 0 0 2432 server1.testcoda.net
> 	_codasrv._udp.testcoda.net IN SRV 0 0 2432 server2.testcoda.net
> 
> > Well what I figured out was my client machine should know the ip
> > address of the DNS server. Where do I provide that? (to be frank I do
> > not have a good knowledge of DNS as of now).
> 
> Most likely a 'nameserver 127.0.0.1' entry in /etc/resolv.conf (where
> 127.0.0.1 is the ip-address of your DNS server.
> 
> > Actually I want to have a configuration in which I have 2 coda servers
> > with different volumes on them under the same realm name and want the
> > client to resolve the realm and the server address to which it wants
> > to connect to, via DNS only. Is this somewhere documented on how to
> > make this configuration?
> 
> When venus tries to access the realm it first looks for the IN SRV
> record, which would then return one or more 'volume' servers in your
> realm. These volume servers are then used to map volume names to file
> servers. Every codasrv process provides volume server functionality, but
> it is mostly separate from their file server functionality. You could
> have a codaserver that exports no files but is only used to answer
> volume location queries. Or it is possible to have a codaserver that
> only handles file requests, by not listing it as one of the realm's root
> servers in the SRV record.
> 
> Once your clients can resolve the SRV record and can discover the root
> servers, everything else should fall out automatically because the
> volume location responses return ip-addresses. Returning ip-addresses is
> a bit of a problem because the servers now do the resolution and a valid
> ip from their perpective may not be the right one for the clients, i.e.
> the local server can resolve to 127.0.0.1 which may be correct locally,
> but is not correct for clients that are running on another machine.
> 
> Jan


--
Students Mail Server @ IIIT Hyderabad.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.