Bug 131142 - unable to select which interface to bind to from lock_gulmd
unable to select which interface to bind to from lock_gulmd
Status: CLOSED ERRATA
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: gfs (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: michael conrad tadpol tilstra
GFS Bugs
:
Depends On:
Blocks: 137219
  Show dependency treegraph
 
Reported: 2004-08-27 17:39 EDT by Adam "mantis" Manthei
Modified: 2010-01-11 21:57 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-25 12:41:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Adam "mantis" Manthei 2004-08-27 17:39:02 EDT
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 17:40:42 EDT
Created attachment 103190 [details]
adds ability to specif ip/hostname or interface to bind to
Comment 2 michael conrad tadpol tilstra 2004-08-30 11:38:32 EDT
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 16:35:18 EDT
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 16:45:54 EDT
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 14:18:20 EDT
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 13:10:31 EST
have code in cvs head.
Comment 7 michael conrad tadpol tilstra 2004-12-09 14:21:45 EST
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 12:41:10 EDT
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.