Bug 131142

Summary: unable to select which interface to bind to from lock_gulmd
Product: [Retired] Red Hat Cluster Suite Reporter: Adam "mantis" Manthei <amanthei>
Component: gfsAssignee: michael conrad tadpol tilstra <mtilstra>
Status: CLOSED ERRATA QA Contact: GFS Bugs <gfs-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: herrmann, pcfe, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-05-25 16:41:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 137219    
Attachments:
Description Flags
adds ability to specif ip/hostname or interface to bind to none

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