On 19/01/2008, <b class="gmail_sendername">Serge Aleynikov</b> <<a href="mailto:saleyn@gmail.com">saleyn@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Chandru wrote:<br>> Well - there is an issue. This is because on the OMC node, host1-rep is<br> > resolving to an IP address to which routing doesn't exist from the OMC (and<br> > I can't get it added). The Security team won't allow this connectivity.<br>
 ><br> > But is there a reason why the node name should have the hostname in it?<br> > Can't we have an erlang node on a machine registering with any arbitrary<br> > name in epmd? There could be kernel configuration on other nodes which can<br>
 > specify the host for each node name. This will have the added benefit that<br> > an mnesia database backup can easily be ported across various sets of nodes<br> > without having to change the name of the nodes in the backup file (which is<br>
 > a bit of a hack).<br> <br> <br>It sounds like what you need is to resolve a host name to IP on OMC that<br>  doesn't resolve using default resolution method.<br> <br> What you can do is specify the {kernel, [{inetrc, CustomConfigFile}]}<br>
 option that will customize the name resolution search path used by<br> distributed Erlang.<br> <br> The CustomConfigFile could contain:<br> <br> {file, hosts, "/etc/hosts"}.<br> {file, resolv, "/etc/resolv.conf"}.<br>
 {lookup, [file, dns]}.<br> {host, IpAddress1, ["db1@host1-rep"]}.<br> {host, IpAddress2, ["db1@host2-rep"]}.<br> <br> This should solve your issue.</blockquote><div><br>An update for the archives in case any one else tries to use this.<br>
<br>  {host, IpAddress2, ["db1@host2-rep"]}.<br><br>should be<br><br> {host, IpAddress2, ["host2-rep"]}.  %% Don't include the node name, just the hostname<br><br>The other thing to keep in mind is that this hostname should not be in /etc/hosts. This custom solution may or may not work if the same name exists in both files because of the way inet:gethostbyname/1 traverses the inet_hosts table. The implementation is not wrong, but it could probably do better. <br>
<br>cheers<br>Chandru<br><br> <br> </div></div>