Re: [Ipmitool-devel] 'Sel set time' off by an hour if executed from an exec file.

2012-09-24 Thread Jim Mankovich

All,
I've attached a fix for this based on what was reported in Bug #3568976 and I 
verified
this fix resolved the reported problem.

If no one has an problem with this fix, I'll commit the change to TOB at the 
end of this
week.

Thanks in Advance,
Jim

-- Jim Mankovich | jm...@hp.com (MST) --

On 9/21/2012 7:51 AM, Jon Bamber wrote:


Dick

I agree with a Zdenek, we use tm.tm_isdst = (-1); in the patch 3497103Settable and shared 
sensor sdr , but you can alos use the option now to send the current time which 
is useful but undocumented in the help.

Jon

*Jonathan Bamber*




__
For additional information including the registered office and the treatment of 
Xyratex confidential information please visit www.xyratex.com
__




--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html


___
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel




From 79e7f26b610ae98968255aec51a36a631be9c43b Mon Sep 17 00:00:00 2001
From: Jim Mankovich jm...@hp.com
Date: Mon, 24 Sep 2012 14:04:00 -0600
Subject: [PATCH] Init is daylight savings time to unavailable
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=1.7.9.5

This is a multi-part message in MIME format.
--1.7.9.5
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit

ipmitool sel time set acts differently when executed explicitly on the command
line vs when executed from a file using ipmitool exec filename.  The
problem is due to lack of initialization of the timeval structure tm_isdst
field.  We set the daylight savings time rule to unavailable so mktime will
attempt to determine whether or not DST is in effect.  See Bug ID: 3568976
for details.

Signed-off-by: Jim Mankovich jm...@hp.com
---
 lib/ipmi_sel.c |1 +
 1 file changed, 1 insertion(+)


--1.7.9.5
Content-Type: text/x-patch; name=0001-Init-is-daylight-savings-time-to-unavailable.patch
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename=0001-Init-is-daylight-savings-time-to-unavailable.patch

diff --git a/lib/ipmi_sel.c b/lib/ipmi_sel.c
index 3c99b66..35bd0b3 100644
--- a/lib/ipmi_sel.c
+++ b/lib/ipmi_sel.c
@@ -2480,6 +2480,7 @@ ipmi_sel_set_time(struct ipmi_intf * intf, const char * time_string)
 			lprintf(LOG_ERR, Specified time could not be parsed);
 			return -1;
 		}
+		tm.tm_isdst = -1; /* dst information unavailable */
 		t = mktime(tm);
 		if (t  0) {
 			lprintf(LOG_ERR, Specified time could not be parsed);

--1.7.9.5--


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel


Re: [Ipmitool-devel] 'Sel set time' off by an hour if executed from an exec file.

2012-09-24 Thread Zdenek Styblik
On Mon, Sep 24, 2012 at 11:06 PM, Jim Mankovich jm...@hp.com wrote:

 All,
 I've attached a fix for this based on what was reported in Bug #3568976 and I 
 verified
 this fix resolved the reported problem.

 If no one has an problem with this fix, I'll commit the change to TOB at the 
 end of this
 week.

 Thanks in Advance,
 Jim

 -- Jim Mankovich | jm...@hp.com (MST) --

ACK.

Z.


 On 9/21/2012 7:51 AM, Jon Bamber wrote:

 Dick

   I agree with a Zdenek, we use tm.tm_isdst = (-1); in the patch “3497103  
 Settable and shared sensor sdr” , but you can alos use the option “now” to 
 send the current time which is useful but undocumented in the help.

 Jon





 Jonathan Bamber





 __
 For additional information including the registered office and the treatment 
 of Xyratex confidential information please visit www.xyratex.com
 __




 --
 Got visibility?
 Most devs has no idea what their production app looks like.
 Find out how fast your code is with AppDynamics Lite.
 http://ad.doubleclick.net/clk;262219671;13503038;y?
 http://info.appdynamics.com/FreeJavaPerformanceDownload.html

 ___
 Ipmitool-devel mailing list
 Ipmitool-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ipmitool-devel




 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Ipmitool-devel mailing list
 Ipmitool-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ipmitool-devel


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel


Re: [Ipmitool-devel] 'Sel set time' off by an hour if executed from an exec file.

2012-09-24 Thread Zdenek Styblik
On Tue, Sep 25, 2012 at 5:15 AM, Zdenek Styblik
zdenek.styb...@gmail.com wrote:
 On Mon, Sep 24, 2012 at 11:06 PM, Jim Mankovich jm...@hp.com wrote:

 All,
 I've attached a fix for this based on what was reported in Bug #3568976 and 
 I verified
 this fix resolved the reported problem.

 If no one has an problem with this fix, I'll commit the change to TOB at the 
 end of this
 week.

 Thanks in Advance,
 Jim

 -- Jim Mankovich | jm...@hp.com (MST) --

 ACK.

 Z.


Jim, please, see attached.

Thanks,
Z.


 On 9/21/2012 7:51 AM, Jon Bamber wrote:

 Dick

   I agree with a Zdenek, we use tm.tm_isdst = (-1); in the patch “3497103  
 Settable and shared sensor sdr” , but you can alos use the option “now” to 
 send the current time which is useful but undocumented in the help.

 Jon





 Jonathan Bamber





 __
 For additional information including the registered office and the treatment 
 of Xyratex confidential information please visit www.xyratex.com
 __




 --
 Got visibility?
 Most devs has no idea what their production app looks like.
 Find out how fast your code is with AppDynamics Lite.
 http://ad.doubleclick.net/clk;262219671;13503038;y?
 http://info.appdynamics.com/FreeJavaPerformanceDownload.html

 ___
 Ipmitool-devel mailing list
 Ipmitool-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ipmitool-devel




 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Ipmitool-devel mailing list
 Ipmitool-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ipmitool-devel



0001-Init-is-daylight-savings-time-to-unavailable-sty.patch
Description: Binary data
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel


Re: [Ipmitool-devel] 'Sel set time' off by an hour if executed from an exec file.

2012-09-24 Thread Zdenek Styblik
On Tue, Sep 25, 2012 at 5:37 AM, Zdenek Styblik
zdenek.styb...@gmail.com wrote:
 On Tue, Sep 25, 2012 at 5:15 AM, Zdenek Styblik
 zdenek.styb...@gmail.com wrote:
 On Mon, Sep 24, 2012 at 11:06 PM, Jim Mankovich jm...@hp.com wrote:

 All,
 I've attached a fix for this based on what was reported in Bug #3568976 and 
 I verified
 this fix resolved the reported problem.

 If no one has an problem with this fix, I'll commit the change to TOB at 
 the end of this
 week.

 Thanks in Advance,
 Jim

 -- Jim Mankovich | jm...@hp.com (MST) --

 ACK.

 Z.


 Jim, please, see attached.

 Thanks,
 Z.


I'm sorry for a spam. Here is updated version. Please, ignore previous
attachment.

What is different in my patches is structures are zero-ed before
they're used anywhere. This way, it should mitigate the problem of
random values in structures, which was the problem in the first place.

I think I could commit this by myself, eventually. ;)

Thanks,
Z.


 On 9/21/2012 7:51 AM, Jon Bamber wrote:

 Dick

   I agree with a Zdenek, we use tm.tm_isdst = (-1); in the patch “3497103  
 Settable and shared sensor sdr” , but you can alos use the option “now” to 
 send the current time which is useful but undocumented in the help.

 Jon





 Jonathan Bamber





 __
 For additional information including the registered office and the 
 treatment of Xyratex confidential information please visit www.xyratex.com
 __




 --
 Got visibility?
 Most devs has no idea what their production app looks like.
 Find out how fast your code is with AppDynamics Lite.
 http://ad.doubleclick.net/clk;262219671;13503038;y?
 http://info.appdynamics.com/FreeJavaPerformanceDownload.html

 ___
 Ipmitool-devel mailing list
 Ipmitool-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ipmitool-devel




 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Ipmitool-devel mailing list
 Ipmitool-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ipmitool-devel



0001-Init-is-daylight-savings-time-to-unavailable-sty.patch
Description: Binary data
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel


Re: [Ipmitool-devel] 'Sel set time' off by an hour if executed from an exec file.

2012-09-18 Thread Zdenek Styblik
On Mon, Sep 17, 2012 at 3:46 PM, dick.detwei...@emerson.com wrote:

 Hello all,

 I lead a group that uses ipmitool in server control software we write and 
 maintain.  We have uncovered a curious issue with ipmitool's 'sel set time' 
 and 'exec' commands.  This is using ipmitool version 1.8.10.  I have looked 
 through the change logs for 1.8.11 and 12 and not seen this problem addressed.

 If we issue 'sel set time' from the command line, and then put the exact same 
 command into a file and use exec to execute it, we get an hour's difference 
 in the commands.  Here is a screen shot:

 Is this a known issue?

 Thanks,
 Dick


Hello Dick,

to tell you whether it is known issue or not; it is hard when people
refuse to use SF.net bug tracker. I don't remember seeing this one in
there, so I'd say it is not a known issue.

Anyway, here is what I got and what I got to:

~~~ debug output
[root@host ~]# /tmp/package-ipmitool/usr/local/bin/ipmitool sel time
set 09/14/2012 18:30:00
TM before mktime()
hour: 18
min: 30
isdst: 3
tz1: 'GMT'
tz2: 'GMT'
---
TM after mktime()
hour: 18
min: 30
isdst: 1
tz1: 'CET'
tz2: 'CEST'
---
Leaving time alone.

Delta is '2'

09/14/2012 18:30:00
[root@host ~]# /tmp/package-ipmitool/usr/local/bin/ipmitool exec time
TM before mktime()
hour: 18
min: 30
isdst: 0
tz1: 'GMT'
tz2: 'GMT'
---
TM after mktime()
hour: 19
min: 30
isdst: 1
tz1: 'CET'
tz2: 'CEST'
---
Leaving time alone.

Delta is '2'

09/14/2012 19:30:00
~~~ debug output

The reason, as you can see, is tm.tm_isdst being set to random value.
And once it is set to value 0, other time it is set to  0. Setting
tm.tm_isdst to (-1) prior calling mktime() gives, at least,
deterministic behaviour.

From mktime() man page:
``The value specified in the tm_isdst field informs mktime() whether
or not daylight saving time (DST) is in effect for the time supplied
in the tm  structure:  a  positive  value means  DST is in effect;
zero means that DST is not in effect; and a negative value means that
mktime() should (use timezone information and system databases to)
attempt to determine whether DST is in effect at the specified time.''

In other words and short, the following change will force mktime() to
*always* check whether DST is in use or not instead of using random
value. One way or another, use of random value set in/to tm.tm_isdst
should be eliminated!

~~~ snip lib/ipmi_sel.c
if (strptime(time_string, time_format, tm) == 0) {
lprintf(LOG_ERR, Specified time could not be parsed);
return -1;
}
tm.tm_isdst = (-1);
t = mktime(tm);
if (t  0) {
lprintf(LOG_ERR, Specified time could not be parsed);
return -1;
}
~~~ snip lib/ipmi_sel.c

I can't put more time into this right now, but debug above should give
enough clues what's wrong. And actually, patch/fix seems to be solid
to me. Please note, however, that Host's timezone is used and that
might not be what you intended. In such case another parameter that
specifies timezone should be added.

Please fill SF.net ticket(or tickets, because these are two separate
things!) for this. If you don't have SF.net account/access, please,
say so.

Thanks and regards,
Z.


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Ipmitool-devel mailing list
 Ipmitool-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ipmitool-devel


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel


Re: [Ipmitool-devel] 'Sel set time' off by an hour if executed from an exec file.

2012-09-18 Thread Zdenek Styblik
On Tue, Sep 18, 2012 at 1:21 PM, Zdenek Styblik
zdenek.styb...@gmail.com wrote:
 On Mon, Sep 17, 2012 at 3:46 PM, dick.detwei...@emerson.com wrote:

 Hello all,

 I lead a group that uses ipmitool in server control software we write and 
 maintain.  We have uncovered a curious issue with ipmitool's 'sel set time' 
 and 'exec' commands.  This is using ipmitool version 1.8.10.  I have looked 
 through the change logs for 1.8.11 and 12 and not seen this problem 
 addressed.

 If we issue 'sel set time' from the command line, and then put the exact 
 same command into a file and use exec to execute it, we get an hour's 
 difference in the commands.  Here is a screen shot:

 Is this a known issue?

 Thanks,
 Dick


 Hello Dick,

 to tell you whether it is known issue or not; it is hard when people
 refuse to use SF.net bug tracker. I don't remember seeing this one in
 there, so I'd say it is not a known issue.

 Anyway, here is what I got and what I got to:

 ~~~ debug output
 [root@host ~]# /tmp/package-ipmitool/usr/local/bin/ipmitool sel time
 set 09/14/2012 18:30:00
 TM before mktime()
 hour: 18
 min: 30
 isdst: 3
 tz1: 'GMT'
 tz2: 'GMT'
 ---
 TM after mktime()
 hour: 18
 min: 30
 isdst: 1
 tz1: 'CET'
 tz2: 'CEST'
 ---
 Leaving time alone.

 Delta is '2'

 09/14/2012 18:30:00
 [root@host ~]# /tmp/package-ipmitool/usr/local/bin/ipmitool exec time
 TM before mktime()
 hour: 18
 min: 30
 isdst: 0
 tz1: 'GMT'
 tz2: 'GMT'
 ---
 TM after mktime()
 hour: 19
 min: 30
 isdst: 1
 tz1: 'CET'
 tz2: 'CEST'
 ---
 Leaving time alone.

 Delta is '2'

 09/14/2012 19:30:00
 ~~~ debug output

 The reason, as you can see, is tm.tm_isdst being set to random value.
 And once it is set to value 0, other time it is set to  0. Setting
 tm.tm_isdst to (-1) prior calling mktime() gives, at least,
 deterministic behaviour.

 From mktime() man page:
 ``The value specified in the tm_isdst field informs mktime() whether
 or not daylight saving time (DST) is in effect for the time supplied
 in the tm  structure:  a  positive  value means  DST is in effect;
 zero means that DST is not in effect; and a negative value means that
 mktime() should (use timezone information and system databases to)
 attempt to determine whether DST is in effect at the specified time.''


Ok, should is not always as written below. I'm wondering whether
it means it is not going to work (reliably) for some platforms(meaning
OS).

 In other words and short, the following change will force mktime() to
 *always* check whether DST is in use or not instead of using random
 value. One way or another, use of random value set in/to tm.tm_isdst
 should be eliminated!

 ~~~ snip lib/ipmi_sel.c
 if (strptime(time_string, time_format, tm) == 0) {
 lprintf(LOG_ERR, Specified time could not be 
 parsed);
 return -1;
 }
 tm.tm_isdst = (-1);
 t = mktime(tm);
 if (t  0) {
 lprintf(LOG_ERR, Specified time could not be 
 parsed);
 return -1;
 }
 ~~~ snip lib/ipmi_sel.c

 I can't put more time into this right now, but debug above should give
 enough clues what's wrong. And actually, patch/fix seems to be solid
 to me. Please note, however, that Host's timezone is used and that
 might not be what you intended. In such case another parameter that
 specifies timezone should be added.

 Please fill SF.net ticket(or tickets, because these are two separate
 things!) for this. If you don't have SF.net account/access, please,
 say so.

 Thanks and regards,
 Z.


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Ipmitool-devel mailing list
 Ipmitool-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ipmitool-devel


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel


Re: [Ipmitool-devel] 'Sel set time' off by an hour if executed from an exec file.

2012-09-18 Thread Dick.Detweiler
Bug 3568976 set sel time acts differently between command line and exec 
opened at sf.net.

Richard Detweiler |  T 256-261-6550


-Original Message-
From: Zdenek Styblik [mailto:zdenek.styb...@gmail.com] 
Sent: Tuesday, September 18, 2012 6:22 AM
To: Detweiler, Dick [NETPWR/AVOCENT/AL]
Cc: ipmitool-devel@lists.sourceforge.net
Subject: Re: [Ipmitool-devel] 'Sel set time' off by an hour if executed from an 
exec file.

On Mon, Sep 17, 2012 at 3:46 PM, dick.detwei...@emerson.com wrote:

 Hello all,

 I lead a group that uses ipmitool in server control software we write and 
 maintain.  We have uncovered a curious issue with ipmitool's 'sel set time' 
 and 'exec' commands.  This is using ipmitool version 1.8.10.  I have looked 
 through the change logs for 1.8.11 and 12 and not seen this problem addressed.

 If we issue 'sel set time' from the command line, and then put the exact same 
 command into a file and use exec to execute it, we get an hour's difference 
 in the commands.  Here is a screen shot:

 Is this a known issue?

 Thanks,
 Dick


Hello Dick,

to tell you whether it is known issue or not; it is hard when people refuse to 
use SF.net bug tracker. I don't remember seeing this one in there, so I'd say 
it is not a known issue.

Anyway, here is what I got and what I got to:

~~~ debug output
[root@host ~]# /tmp/package-ipmitool/usr/local/bin/ipmitool sel time set 
09/14/2012 18:30:00
TM before mktime()
hour: 18
min: 30
isdst: 3
tz1: 'GMT'
tz2: 'GMT'
---
TM after mktime()
hour: 18
min: 30
isdst: 1
tz1: 'CET'
tz2: 'CEST'
---
Leaving time alone.

Delta is '2'

09/14/2012 18:30:00
[root@host ~]# /tmp/package-ipmitool/usr/local/bin/ipmitool exec time TM before 
mktime()
hour: 18
min: 30
isdst: 0
tz1: 'GMT'
tz2: 'GMT'
---
TM after mktime()
hour: 19
min: 30
isdst: 1
tz1: 'CET'
tz2: 'CEST'
---
Leaving time alone.

Delta is '2'

09/14/2012 19:30:00
~~~ debug output

The reason, as you can see, is tm.tm_isdst being set to random value.
And once it is set to value 0, other time it is set to  0. Setting tm.tm_isdst 
to (-1) prior calling mktime() gives, at least, deterministic behaviour.

From mktime() man page:
``The value specified in the tm_isdst field informs mktime() whether or not 
daylight saving time (DST) is in effect for the time supplied in the tm  
structure:  a  positive  value means  DST is in effect; zero means that DST is 
not in effect; and a negative value means that
mktime() should (use timezone information and system databases to) attempt to 
determine whether DST is in effect at the specified time.''

In other words and short, the following change will force mktime() to
*always* check whether DST is in use or not instead of using random value. One 
way or another, use of random value set in/to tm.tm_isdst should be eliminated!

~~~ snip lib/ipmi_sel.c
if (strptime(time_string, time_format, tm) == 0) {
lprintf(LOG_ERR, Specified time could not be parsed);
return -1;
}
tm.tm_isdst = (-1);
t = mktime(tm);
if (t  0) {
lprintf(LOG_ERR, Specified time could not be parsed);
return -1;
}
~~~ snip lib/ipmi_sel.c

I can't put more time into this right now, but debug above should give enough 
clues what's wrong. And actually, patch/fix seems to be solid to me. Please 
note, however, that Host's timezone is used and that might not be what you 
intended. In such case another parameter that specifies timezone should be 
added.

Please fill SF.net ticket(or tickets, because these are two separate
things!) for this. If you don't have SF.net account/access, please, say so.

Thanks and regards,
Z.


 --
 
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and 
 threat landscape has changed and how IT managers can respond. 
 Discussions will include endpoint security, mobile security and the 
 latest in malware threats. 
 http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Ipmitool-devel mailing list
 Ipmitool-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel