Hey Gregor, I've finally committed a first attempt at the sensors config tool. I've settled on putting it into a new tool called "ipmi-sensors-config" for the tool. It currently only supports configuration of thresholds and none of the sensor enabling/disabling. I'm going to pass on that until the time it is needed/requested.
Do you think you could take a look and LMK what you think of it? It's currently in the CVS head. cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/freeipmi co freeipmi cd freeipmi ./autogen.sh ./configure --enable-debug --enable-trace (--enable-debug and --enable-trace if there are issues on your system) cd ipmi-sensors-config/src The manpage is in ipmi-sensors-config/ipmi-sensors-config.8 I will intentionally leave out details, so we can see what you think w/o me swaying your initial opinion :-) Al > Hey Al, > > I don't really get your fears. If I checkout something from the bmc / > sensors, I expect the status-quo of the bmc/sensor-threshold-settings. > If I don't know s.th. about a section / item, I don't touch it and so it > won't be changed by a commit. > When I get an item, which is commented out, I suppose it's a "read only > setting", first. If you wanted to pretend the user, you could suppress > the "dangerous" items by default and write them out only, when the user > forces a verbose (-v) output. > > Why should the user be able to enable / disable sensors? If I don't want > to use a specific sensor as a trigger for an event, I don't configure a > corresponding event-filter-entry, or ? Is the enable / disable-feature > in the specs, at all? > > For the checkout, I imagine s.th. like the following: > > # Sensor Name: Temp > Section Sensor_1 // -> Sensor_<unique sensor-id>). Not the > sensor-name, 'cause different sensors can have the same name. > ## Give your thresholds. Possible values: float number. - > disables the threshold > Lower_Critical 10.0 > Upper_Critical 60.0 > Lower_Noncritical 15.0 > Upper_Noncritical 65.0 > Upper_Nonrecoverable - > Upper_Nonrecoverable - > EndSection > # Sensor Name: Ambiant Temp > Section Sensor_2 > ## Give your thresholds. Possible values: float number. - > disables the threshold > Lower_Critical - > Upper_Critical 50.0 > Lower_Noncritical - > Upper_Noncritical 45.0 > Upper_Nonrecoverable - > Upper_Nonrecoverable - > EndSection > [...] > > I think, the sensors, which don't relate to the Event Type 1h > (threshold-able sensors) don't have any setting, which is configurable > by the user. So they don't need to be listed in the checkout. > > But for now, have a nice week-end :) > Gregor > > Al Chu wrote: >> On Fri, 2008-01-25 at 07:41 -0800, Albert Chu wrote: >>> Hey Gregor, >>> >>>> Btw, to strengthen the case against the command line interface: There >>>> are different event triggers / event classes. For example, the event >>>> trigger 02h relates to the "discrete"-event class which describes one >>>> of >>>> the events "Transition to Idle / Active / Busy". Or the event trigger >>>> 03h. It's a "digital discrete"-event class and describes the events >>>> "State Asserted / Deasserted". >>> I'm glad you brought that up. As I was looking through the spec, I was >>> wondering how deep I wanted to support the configuration. There are >>> some >>> "scary areas" in IPMI that I fear configuring b/c so many vendors >>> implement IPMI poorly. When a vendor configures usernames/passwords >>> incorrectly, and bmc-config subsequently messes something up, well, its >>> only a username and password issue. in-band IPMI can still work. >>> >>> Potentially enabling/disabling sensor scanning may make things really >>> bad >>> on a system. Sort of like my initial resisitance to add boot-parameter >>> configuration to bmc-config. >>> >>> I'm thinking perhaps I will just leave these "scary areas" commented >>> out >>> in the config after you do a checkout. That way, if you really know >>> what >>> you're doing, you are welcome to uncomment and commit away. It's sort >>> of >>> like the SOL port field in the bmc-config. That's a scary config that >>> I >>> don't want people to write to the BMC by default. >>> >>> What do you think? >> >> Thinking about this a bit more, I suppose it begs the question, why >> don't I just leave all fields uncommented until the user wants to >> configure them. >> >> Maybe its enough to say that bmc-config is "generic", but sensors-config >> is "advanced", so you better know what you're doing if you're going to >> be using "sensors-config"??? >> >> Al >> >>> Al > -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel