freeipmi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Freeipmi-devel] Re: Comments on bmc-config specification 2.0


From: Albert Chu
Subject: [Freeipmi-devel] Re: Comments on bmc-config specification 2.0
Date: Tue, 16 Mar 2004 13:24:52 -0800

>  ## Values: None = 0, MD2 = 1, MD5 = 2, Straight Password = 3, 
>  ##         OEM Proprietary = 4
>  max_privilege_auth_type_admin_level 3

Did you write this out?  Or cut and paste it from a --checkout?  B/c I
can't find this anywhere in a --checkout.

I think the wording of this option is the only issue at hand.  How about

max_privilege_callback_level_auth_type.none 0
max_privilege_callback_level_auth_type.md2 0
max_privilege_callback_level_auth_type.md5 0
max_privilege_callback_level_auth_type.straight_password 1
max_privilege_callback_level_auth_type.oem_proprietary 0

That way, it is almost word for word with the spec.  

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory

----- Original Message -----
From: Anand Babu <address@hidden>
Date: Tuesday, March 16, 2004 12:50 pm
Subject: Re: Comments on bmc-config specification 2.0

> LATE REPLY!!, This email is relevant to Alpha4 release and above.
> 
> ,----[ Albert Chu <address@hidden> ]
> | 1) We need something that allows us to enable or disable users.  As
> | far as I can tell, there is nothing for that.  I am referring
> | enabling/disabling users through the set user password command.  I
> | think something along the lines of:
> | 
> | # 1 is enable, 0 is disable user1_access 1
> | 
> | Would be suitable.
> `----
> 
> "No access" does the same.
> 
>  ###   values: Reserved = 0, Callback = 1, User = 2, Operator = 3,
>  ###           Administrator = 4, OEM proprietary = 5, No access = 15
>  userX.user_privilege_level_limit 15
> 
> 
> 
> ,----
> | 2) I think we need an option to set the power restore policy 
> (22.7 in
> | the spec).
> `----
> 
> Implemented. (Alpha4)
> 
> 
> ,----[ Albert Chu <address@hidden> ]
> | 3) With the options related to set user access and set channel 
> access| (and maybe others), how do we specify the IPMI channel?  Does
> | bmc-config always assume the channel is Tiger4 Lan = 0x07??  This 
> may| be true for current tiger4s, but it could change if Intel 
> makes a
> | change in the firmware.  I'm not sure of the best way to handle 
> this.| Here are several thoughts:
> | 
> |     - --channel-num option on the command line channel_num in the
> |     - configuration file.  All configuration after channel_num use
> |     - this particular channel number.
> `----
> 
> Probing of LAN and Serial channels are handled automatically using
> "get channel info" API.
> 
> 
> ,----[ Albert Chu <address@hidden> ]
> | 4) All of the "max_privilege_auth_type_X_level.Y" options don't seem
> | quite right to me.  Shouldn't they instead be "auth_type_enable" or
> | something like that??  We aren't setting the maximum privilege, 
> we're| enabling authentication types.
> `----
> 
> auth_type_enable is different option. It is already handled by 
> "No Access" value for privilege level. This option describes the type
> of authentication used. It has multiple values.
> 
> Current setting is some what like this:
> 
>  ## Values: None = 0, MD2 = 1, MD5 = 2, Straight Password = 3, 
>  ##         OEM Proprietary = 4
>  max_privilege_auth_type_admin_level 3
> 
> 
> ,----[ Albert Chu <address@hidden> ]
> | 5) gratuitous_arp_interval - When you do a --checkout, can we 
> document| that gratuitous arp interval is in 500 millisecond 
> chunks.  In
> | general, can we document units wherever it seems reasonable?
> | retry_time and page_blackout_interval seem like good candidates for
> | units documentation as well.
> `----
> 
> Implemented. (Alpha4)
> 
> 
> ,----[ Albert Chu <address@hidden> ]
> | 6) ipmi_messaging_access_mode, user_level_authentication,
> | pef_alerting, per message authentication and
> | channel_privilege_level_limit seem to be listed twice.
> `----
> 
> Fixed. (Alpha4)
> 
> 
> Happy Hacking,
> -- 
> Anand Babu
> Free as in Freedom <www.gnu.org>
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]