Bug 131142 - unable to select which interface to bind to from lock_gulmd
Summary: unable to select which interface to bind to from lock_gulmd
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Cluster Suite
Classification: Retired
Component: gfs
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: michael conrad tadpol tilstra
QA Contact: GFS Bugs
URL:
Whiteboard:
Depends On:
Blocks: 137219
TreeView+ depends on / blocked
 
Reported: 2004-08-27 21:39 UTC by Adam "mantis" Manthei
Modified: 2010-01-12 02:57 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-05-25 16:41:10 UTC
Embargoed:


Attachments (Terms of Use)
adds ability to specif ip/hostname or interface to bind to (4.04 KB, text/plain)
2004-08-27 21:40 UTC, Adam "mantis" Manthei
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:466 0 normal SHIPPED_LIVE GFS bug fix update 2005-05-25 04:00:00 UTC

Description Adam "mantis" Manthei 2004-08-27 21:39:02 UTC
Description of problem:
There is no capability in lock_gulmd to select the ethernet intrerface
to bind to.  The code is as follows:

void set_myID(void)
{
   /* cute tricks to set the default name and IP. */
   gethostname(myName, 256);
   /* lookup my ip from my full name. */
   if( get_ip_for_name(myName, &myIP) != 0 )
      die(ExitGulm_InitFailed, "Failed to find IP for my name (%s)\n",
            myName);
}

A workaround exists to trick out lock_gulmd to bind to another
interface (although this is quite ugly).  The workaround is to switch
the hostname of the node before starting lock_gulmd, and then revert
back to the original hostname after lock_gulmd has started.  This will
require that you have already named the host in nodes.ccs and
/etc/hosts and/or dns.  Workaround:
   1.  saved_name=$(hostname)
   2.  hostname $new_name
   3.  lock_gulmd
   4.  hostname $saved_name


Users expect to be able to use any interface on their system, not just
whatever resolves to gethostname().  

Users in the field are using the workaround.  (I know because I told
them how to do it ;)  It would be nice to provide a more robust and
lessy kludgy way of doing this.

Comment 1 Adam "mantis" Manthei 2004-08-27 21:40:42 UTC
Created attachment 103190 [details]
adds ability to specif ip/hostname or interface to bind to

Comment 2 michael conrad tadpol tilstra 2004-08-30 15:38:32 UTC
patch looks pretty good. except that the getipbyiface() function
should probably be in the utils_ip.c file.


Comment 3 michael conrad tadpol tilstra 2004-08-30 20:35:18 UTC
question, did you try putting the ips that are on the second interface
into the servers line instead of names?

Comment 4 michael conrad tadpol tilstra 2004-08-30 20:45:54 UTC
nevermind.  that won't work because gulm resloved back the name, which
may not match when connecting to a server (which takes the name and
resolves it to an ip to check, and that may not resolve to the
original ip.)

Comment 5 michael conrad tadpol tilstra 2004-09-10 18:18:20 UTC
ok, this feels a bit off.
Its kinda a hack on a very old tight binding in gulm.
one name == one ip == one machine.  Now this isn't true in many
setups, esspcially those with multiple network devices.  They
typically have many ips, and this is what confuses gulm.

I need to think about this some more, but I think the first step in
the correct solution for this is to remove the ip from that above
assumption.

Comment 6 michael conrad tadpol tilstra 2004-11-01 18:10:31 UTC
have code in cvs head.

Comment 7 michael conrad tadpol tilstra 2004-12-09 19:21:45 UTC
Adds an optional "usedev" key to a node in the nodes.ccs:nodes.
Value of this key is a named device from the ip_interfaces section.
If usedev is present, gulm will use the IP from that device in the
ip_interfaces section.  Otherwise it will grab th IP from libresolv (like
before).

ie:
nodes{
 foodad {
  ip_interfaces {
    wizzy = "1.2.3.4"
  }
  usedev = "wizzy"
 }
}


Comment 8 Jay Turner 2005-05-25 16:41:10 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-466.html



Note You need to log in before you can comment on or make changes to this bug.