Red Hat Bugzilla – Bug 130413
RFE: Ability to write subnet masks normally (ie, VLSN or CIDR).
Last modified: 2007-11-30 17:07:03 EST
Description of problem: When adding a bunch of options for a particular subnet, the format used by system-config-netboot is confusing. Yes, we both know the files used in the background are matched by removing digits from the IP, but it shouldn't be necessary for people to know that. It'd be nice if the tool let people write in subnet masks the same way the other system-config tools do. Upon clicking OK, the tool would check to make sure masks entered this way were possible to use with TFTP. Version-Release number of selected component (if applicable): 0.1.3-7 How reproducible: Always Steps to Reproduce: 1.Want to set up network booting for a particular subnet. Enter in the subnet using VLSN just like all the other system-config tools. Actual results: This doesn't work. The subnet mask must be written in a rather unusual way. The tooltips and System Admin guide don't make this particular obvious either. Expected results: It'd be nice if using VLSN was possible. This would make things easier and more consistent with other system-config- tools. Additional info: Thanks.
Internal RFE bug #132312 entered; will be considered for future releases.
I clearing out some old bugs here - sorry for the delay . This can't really be fixed in s-c-nb, because PXE doesn't really work that way: the PXE client boot code looks for a file named with each whole BYTE of the hex IP address, which can't really be specified with VLSP / CIDR notation, which allows individual BITS to be specified . The s-c-db "New Host" dialog does let you omit whole bytes from the IP address and creates files accordingly. Please try out the latest s-c-nb for RHEL-3: redhat-config-netboot-0.1.16 http://people.redhat.com/~jvdias/redhat-config-netboot Thanks !
This can't really be fixed in s-c-nb, Er, yes it can. User enters subnet mask. If the subnet mask doesn't cover a whole byte range, ask the user to enter another.
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.