[CFT] Need Testers for: sysutils/bsdconfig

[Devin Teske]

On Jun 22, 2012, at 5:27 AM, Clayton Milos wrote:

>>>>>> 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).

I've made the necessary changes to support vlan0-vlan99999 (though the system will only support up to vlan65534).


>>>>>> 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).
> 
>> That's driver-dependent. For example, lagg does not presents %desc nor
>> ipfw0 and I suppose pretty many others do not. You could use %desc if it's
>> present and fall back to internal static list otherwise.
> 

Ok, I've added that functionality, but … since neither lagg(4) nor ipfw(4) provide %desc MIB, … what should we provide as static fallbacks?


> Just something cosmetic but when I add a user when it comes to select the
> shell it does not have a title like: Select a shell
> 

I fixed this too.


> Also it said that my user add failed but it was actually added as uid 1005.

I'm working on this one. I'm changing the routines to allow the UNIX pw(8) errors to filter through, rather than masking them with a static error on non-success.


> I added another user and it stated the uid 1005 when I was creating it but
> showed 1006 in the summary screen. It also said that adding the user failed.

"pw usernext" is executed to get the next uid/gid pair that is available. It's possible a user was added in the process. I've not witnessed this, but will try to replicate.


> Perhaps I used to short a password as there was no password field entered in
> /etc/master.passwd
> twat:*:1005:1005::1340540161:1340626570:twat:/home/twat:/bin/sh
> test1:*:1006:1006::1340454020:1340496000:test1:/home/test1:/bin/tcsh
> 

The password is only set (as a separate command) if the pw(8) useradd succeeded. I'm working on catching errors in edge-cases where we should proceed despite non-success.


> When selecting user account expiry the calendar starts at 1 January 1970. I
> understand that this is when Unix time started but it would be nice for it
> to start from the current date.
> 

I filed PR docs/169354 against the passwd(5) manual. If nobody picks up the PR in a timely fashion, I'll pro-actively modify bsdconfig to follow what the man-page _should_ say versus what it _does_ say about "how to treat the value of zero" (the default).
-- 
Thanks for testing!,
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.