Bug 131142 - unable to select which interface to bind to from lock_gulmd
unable to select which interface to bind to from lock_gulmd
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: gfs (Show other bugs)
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:
Last Closed: 2005-05-25 12:41:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:466 normal SHIPPED_LIVE GFS bug fix update 2005-05-25 00:00:00 EDT

  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",

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
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

 foodad {
  ip_interfaces {
    wizzy = ""
  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.


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