Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Jun 2012 01:39:23 -0700
From:      Devin Teske <devin.teske@fisglobal.com>
To:        Eugene Grosbein <egrosbein@rdtc.ru>
Cc:        McDowell <rcm@fuzzwad.org>, Devin Teske <dteske@freebsd.org>, Freebsd-stable@freebsd.org, Ron
Subject:   Re: [CFT] Need Testers for: sysutils/bsdconfig
Message-ID:  <90361FE2-2298-48E5-B8B6-2BA704781098@fisglobal.com>
In-Reply-To: <4FE4245C.3040806@rdtc.ru>
References:  <2322BE6D-24A8-4F4A-84B2-4DFE33BCA65B@fisglobal.com>	<4FE3EB9D.9070509@fuzzwad.org> <4FE419CD.60708@rdtc.ru> <F34D40AA-3AE4-4A1F-B521-CEC2A06ABC79@fisglobal.com> <4FE4245C.3040806@rdtc.ru>

next in thread | previous in thread | raw e-mail | index | archive | help

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

> 22.06.2012 14:37, Devin Teske =D0=C9=DB=C5=D4:
>=20
>>> 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.
>>>=20
>>=20
>> I'd like to know if the sysctl MIB's for describing network interfaces i=
s 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 h=
as internal limits of 16-bit unsigned integer for the interface instance-nu=
mber).
>>=20
>>=20
>>> 6. Same for ipfw0 pseudo-interface.
>>>=20
>>=20
>> Curious what sysctl says about it.
>=20
> I do not know what sysctl subtree do you refer to.
>=20

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 display=
ed in ifconfig(8).



>>> 7. Networking Devices configuration does not allow to configure any int=
erface
>>> while there are mounted NFS volumes. Should present a warning only, not=
 disallow the operation.
>>=20
>> Did I completely disallow it?
>=20
> Yes.
>=20
>> 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 N=
FS mounts are active.
>>=20
>>=20
>>> For example, it should be possible to configure new vlan interface whil=
e NFS mount
>>> uses another clan.
>>>=20
>>=20
>> 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 rou=
te path to determine that one interface isn't required as an intermediary t=
ransit device? (meaning: can one truly ever know that making a new configur=
ation active on any interface could not potentially drop your entire machin=
e from the net with hung NFS mounts?)
>>=20
>> Many months of testing in the lab produced no less than 6 edge-cases whe=
re -- if a network link or route is modified when NFS mounts are active -- =
the machine can enter an unstable/unusable state.
>>=20
>> So we decided to err on the side of caution when it came to allowing set=
tings to be made-active when NFS mounts are active.
>>=20
>> 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.
>>=20
>> 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 Xdialo=
g(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 ne=
xt iteration of Xdialog(1) to fail due to a surreptitious X authority revoc=
ation based on the hostname-change in mid-session.
>=20
> I'm sure that bsdconfig should emit warnings only but not disallow root t=
o 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 th=
e 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 n=
etwork without ssh -X etc.

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


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

Ok, cool.

Thanks again,
--=20
Devin

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?90361FE2-2298-48E5-B8B6-2BA704781098>