Bug 166526 - ip.sh cannot assign multiple ip address ressources when a later added is a substring a previously added
ip.sh cannot assign multiple ip address ressources when a later added is a su...
Status: CLOSED ERRATA
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: rgmanager (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Lon Hohberger
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-22 16:57 EDT by Mads Peter Bach
Modified: 2009-04-16 16:17 EDT (History)
1 user (show)

See Also:
Fixed In Version: RHCS4U2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-13 14:20:18 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)
Add a slash to make sure the full ip address is matched (367 bytes, patch)
2005-08-22 17:07 EDT, Mads Peter Bach
no flags Details | Diff

  None (edit)
Description Mads Peter Bach 2005-08-22 16:57:03 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

Description of problem:
When two or more ip adresses are added as ressources to a service, and one is a substring a previously added address, the latter one won't be assigned when the service starts.


Version-Release number of selected component (if applicable):
rgmanager-1.9.34-1

How reproducible:
Always

Steps to Reproduce:
1. add address 
192.168.1.31 and
192.168.1.3
as ressources
2. start the service 
3. use ip -f inet -o addr to see that 192.168.1.3 hasn't been assigned.
  

Actual Results:  Only 192.168.1.31 is assigned to an interface.

Expected Results:  Both 192.168.1.31 and 192.168.1.3 should have been assigned.

Additional info:
Comment 1 Mads Peter Bach 2005-08-22 17:07:54 EDT
Created attachment 117983 [details]
Add a slash to make sure the full ip address is matched

Adding a / to the pattern matching ensures that e.g. 192.168.1.3 won't match on
192.168.1.30.
Comment 2 Lon Hohberger 2005-08-26 12:33:10 EDT
This was actually fixed in CVS and should be in U2:

----------------------------
revision 1.11
date: 2005/06/14 19:51:19;  author: lhh;  state: Exp;  lines: +3 -3
Fix bug in ip.sh which would match 10.1.1.1 as being the same as 10.1.1.111

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