[CFT] Need Testers for: sysutils/bsdconfig

[Devin Teske]

On Jun 22, 2012, at 12:53 AM, Eugene Grosbein wrote:

> 22.06.2012 14:37, Devin Teske пишет:
> 
>>> 5. Same for vlan16. For vlan9 is shows right 'IEEE 802.1Q VLAN network interface'.
>>> It should work same way for vlan1-vlan4095 interfaces at least.
>>> 
>> 
>> I'd like to know if the sysctl MIB's for describing network interfaces is reliable. Maybe I'll keep the static list as a fallback. But yes, you're absolutely right -- I should have supported up to 5 digits even (ifconfig has internal limits of 16-bit unsigned integer for the interface instance-number).
>> 
>> 
>>> 6. Same for ipfw0 pseudo-interface.
>>> 
>> 
>> Curious what sysctl says about it.
> 
> I do not know what sysctl subtree do you refer to.
> 

If you're using em(4) device, try:

sysctl dev.em.0.%desc

Otherwise (for example), if using fxp(4), try:

sysctl dev.fxp.0.%desc

Or for your vlan:

sysctl dev.vlan.16.%desc

And try for your ipfw(4) interface:

sysctl dev.ipfw.0.%desc

Are each of those meaningful?

NOTE: They aren't available unless you have the hardware -- so I can't (for example) try "sysctl dev.fxp.0.%desc" unless I have an fxp0 device displayed in ifconfig(8).



>>> 7. Networking Devices configuration does not allow to configure any interface
>>> while there are mounted NFS volumes. Should present a warning only, not disallow the operation.
>> 
>> Did I completely disallow it?
> 
> Yes.
> 
>> I'll have to re-check -- I thought that I had made it so that you could view/edit the configuration but that the warning says that changes will not become effective until you either reboot or visit the menu again when no NFS mounts are active.
>> 
>> 
>>> For example, it should be possible to configure new vlan interface while NFS mount
>>> uses another clan.
>>> 
>> 
>> Do you know of a handy way of determining which NFS mount is using which network interface? And further, is there a handy way of traversing the route path to determine that one interface isn't required as an intermediary transit device? (meaning: can one truly ever know that making a new configuration active on any interface could not potentially drop your entire machine from the net with hung NFS mounts?)
>> 
>> Many months of testing in the lab produced no less than 6 edge-cases where -- if a network link or route is modified when NFS mounts are active -- the machine can enter an unstable/unusable state.
>> 
>> So we decided to err on the side of caution when it came to allowing settings to be made-active when NFS mounts are active.
>> 
>> I'm not against improving the code, but I'm wondering if it wouldn't be safer to stick to disallowing any/all changes from being made-active (while allowing viewing/editing without making-active) when NFS mounts are active.
>> 
>> NOTE: There are other safe-guards too. For example, if you're logged in via SSH and using X11 forwarding while passing the "-X" flag (to use Xdialog(1)), you are disallowed from making a new hostname active (you can change the hostname, but not make it active) because that would cause the very next iteration of Xdialog(1) to fail due to a surreptitious X authority revocation based on the hostname-change in mid-session.
> 
> I'm sure that bsdconfig should emit warnings only but not disallow root to make any needed changes.

I'm inclined to agree. FreeBSD should not prevent you from being stupid (as someone once told me). I should change the errors to warnings and allow the user to [potentially] hose their connection given ample warning/chance-to-back-out.


> NFS may use completly unrelated routes/interfaces, X11 may be user over network without ssh -X etc.

Got that one covered actually -- you can tell when a user is using X11 forwarding versus X11 local.


> It's pretty annoying for administrator to fight with tools thinking they know better  what root should do.
> 
>>> 8. In DNS Nameserver Configuration, it's not clear that one, in fact,
>>> can remove unneeded DNS server through two-step procedure - first try to edit,
>>> then clear the address. It should be more obvious at first.
>>> 
>> 
>> Can you have a look at "bsdconfig startup_rcconf" and see if that's a better way to go about the deletion-process?
>> 
>> Or perhaps you're just advocating a helpful message in the text above the menu list that explains how to delete the item? (least amount of work)
> 
> Again, just a message.
> 

Ok, cool.

Thanks again,
-- 
Devin

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.