Bug 154102 - piranha gui does not save netmask
piranha gui does not save netmask
Status: CLOSED WONTFIX
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: piranha (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Marek Grac
Cluster QE
:
: 198479 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-07 06:33 EDT by Martin Poole
Modified: 2009-04-16 16:23 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-14 16:10:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Martin Poole 2005-04-07 06:33:16 EDT
Description of problem:

The GUI does not save the value of the NAT nmask. There is no way to change the
mask other than manually editing the lvs.cf file and inserting a nat_nmask value.

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


How reproducible:

always

Steps to Reproduce:
1. select a NAT configuration
2. modify netmask.
3. reload interface.
  
Actual results:

no value stored in config file

Expected results:

value gets stored.

Additional info:

I would argue that if the lvs ip is within the same subnet as that of any
existing ip/alias on the chosen interface then it should use the same netmask.
The effects of allowing multiple overlapping subnets on a single interface (or
at all) can be extreme. In the cases I have seen the result was an overlapping
set of netmasks for the same region (10/8 & 10.0.0/24) which meant VPN clients
didn't work, various other subnets couldn't see the lvs ip, the ARP table
filled, iptables masquerading interface enforcement failed, and general service
degradation/failure.

Obviously fixing the GUI is a first step, but some thought on the above (or
incorporation of a really big warning) would also be nice.
Comment 1 Lon Hohberger 2005-11-21 17:27:52 EST
This works in my setup.  Maybe I've got the wrong version?
Comment 2 Lon Hohberger 2005-11-21 17:29:50 EST
Actually, nat_nmask seems to be preserved even if I change router types...
Comment 3 Mark Krenz 2005-12-05 10:53:26 EST
For what its worth, I'm having the same problem on piranha-0.7.10-2.
Comment 4 Lon Hohberger 2005-12-06 15:00:09 EST
Martin, Mark - I reproduced it on 0.7.10 on RHCS3/RHEL3, but RHCS4 is 0.8.x,
which is what this bug is filed against.

Was it mistakenly filed against RHCS4 when it should have been against RHCS3? 

/me is confused... I think it should be version 3, not 4; it works for me on 4.
Comment 5 Martin Poole 2005-12-07 04:06:54 EST
I think you'll find BZ has wobbled. I filed this back in April against RHCS3.

I'm glad to hear you've reproduced the problem. I was dealing with a customer
issue where they had both /22 & /28 mask subnets in evidence.
Comment 6 Lon Hohberger 2005-12-07 09:47:43 EST
Changing to RHCS 3, then.
Comment 9 Stanko Kupcevic 2006-11-07 16:46:10 EST
*** Bug 198479 has been marked as a duplicate of this bug. ***
Comment 10 Lon Hohberger 2007-06-14 15:53:52 EDT
Reassigning to component owner

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