You can subscribe to this list here.
2000 |
Jan
(2) |
Feb
(16) |
Mar
(66) |
Apr
(85) |
May
(50) |
Jun
(55) |
Jul
(44) |
Aug
(67) |
Sep
(27) |
Oct
(34) |
Nov
(34) |
Dec
(14) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(26) |
Feb
(20) |
Mar
(28) |
Apr
(45) |
May
(5) |
Jun
(4) |
Jul
(2) |
Aug
|
Sep
(18) |
Oct
(9) |
Nov
(1) |
Dec
|
2002 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Terry C. <he...@ma...> - 2007-10-12 16:53:33
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <!-- Hello, why are you reading my HTML? --> <!-- Copyright 2005-2006 Socializr, Inc. --> <html> <body> <div style="font-size: 80%; font-family: verdana, arial, helvetica, sans-serif;"> <table align=center cellspacing="0" cellpadding=5 width="80%"> <tr valign=bottom> <td style="color: #777; font-size: 85%;"> To ensure you receive invitations, add he...@ma... to your address book. </td> <td align=right> <img title="Socializr" border=0 src="http://static.socializr.com/images/logo_small.gif"> </td> </tr> </table> <table align=center cellspacing="0" cellpadding=5 width="80%" style="border: 1px solid #F59168;"> <tr style="background: #FFFFFF; background-image: url('http://photos8.socializr.com/87/90/48/879048719l.jpg');"> <td> <div style="font-size: 85%; text-align: right; display: block; padding-bottom: 5px;"> <a style="color: #009694; font-weight: normal; text-decoration: underline;" href="http://www.socializr.com/invite/248950268">Invite More People</a> </div> <div align=center style="padding-bottom: 5px;"> <img border=0 src="http://photos6.socializr.com/60/19/96/601996361t.jpg"> </div> <div align=center style="color: #CB5B2D; padding-bottom: 5px;"> Terry Chay has invited you to: </div> <div align=center style="padding-bottom: 10px;"> <a style="color: #E17041; font-weight: bold; font-size: 140%; text-decoration: underline;" href="http://www.socializr.com/event/248950268/2069706504">Lunch 2.0 @ Tagged/Netvibes</a> </div> <div align=center style="color: #009694; font-weight: bold; padding-bottom: 5px;"> Friday, October 12, 2007, 12:00 PM to 2:00 PM </div> <div align=center style="color: #CB5B2D; padding-bottom: 5px;"> Hosted by Lunch 2.0 </div> <div align=center style="color: #CB5B2D; padding-bottom: 5px;"> Tagged and NetVibes </div> <div align=center style="font-size: 85%; color: #CB5B2D; padding-bottom: 5px;"> 840 Battery, 2nd Floor, San Francisco, CA, 94111 </div> <div align=center style="padding-top: 10px; padding-bottom: 10px;"> <a href="http://www.socializr.com/event/248950268/2069706504" style="border: 1px solid #F59168; padding: 4px 8px; background: #FEF3BB; color: #009694; font-weight: bold; text-decoration: underline;">View Guest List and RSVP</a> </div> <div align=center style="padding: 8px 10px 5px 6px; "> <a href="http://www.socializr.com/event/248950268/2069706504"><img border=0 xwidth="200" src="http://photos9.socializr.com/90/16/29/901629885l.jpg"></a> </div> <div align=center style="color: #CB5B2D; padding-top: 10px; padding-bottom: 10px;"> You are one of the first people to be invited. </div> <div align=center style="padding-top: 5px; padding-bottom: 10px;"> <a href="http://www.socializr.com/event/248950268/2069706504" style="border: 1px solid #F59168; padding: 4px 8px; background: #FEF3BB; color: #009694; font-weight: bold; text-decoration: underline;">View Guest List and RSVP</a> </div> </td> </tr> </table> </div> <div align=center style="padding-top: 3px; padding-bottom: 3px; font-size: 60%; font-family: verdana, arial, helvetica, sans-serif;"> Sent on behalf of Terry Chay <ty...@ph...> at 10/12/07 9:51 AM </div> <div align=center style="padding-top: 5px; font-size: 70%; font-family: verdana, arial, helvetica, sans-serif;"> <a href="http://www.socializr.com/block/248950268/2069706504" style="color: black; font-weight: normal; text-decoration: underline;">Block emails from Terry Chay or Socializr</a> </div> <div align=center style="padding-top: 8px; font-size: 60%; font-family: verdana, arial, helvetica, sans-serif;"> ©2007 Socializr, Inc. All Rights Reserved. “Don't be boring.” <br> 660 4th Street, Suite 240, San Francisco, California 94107 </div> <!-- app3.prod.socializr.com - 385 --> <p> </body> </html> |
From: Bernhard M. E. <bm...@mi...> - 2002-04-24 10:27:30
|
Hello We have a server that provides an EMP port and a client that runs FreeBSD. As VACM includes an EMP client interface I figured that it is possible to make the EMP module a standalone executable. I have looked a bit at the VACM source (and it compiles fine on a Linux box) but I find the source too big for me to alter. FreeBSD has the possibility to execute Linux executables, but making VACM itself work on FreeBSD is not my skill. So is it possible to create a standalone linux emp command line tool from the VACM EMP module and if so, has anyone tried or can anyone tell me how difficult that would be? I could settle for something less; after all, what I probably need most is a way to remotely reset our server. EMP should provide this but if this proves too difficult, I guess I can just extend the reset wires and access them via the FreeBSD serial or parallel port... regards, Bernhard Ege |
From: Adam L. <ad...@la...> - 2001-11-04 23:41:10
|
Adam Lazur (ad...@la...) said: > I have vacm 2.0.5 running on a small cluster of 4 rhat 7.1 machines. I > downloaded and got vacm-perl to compile and install, but I get segfaults > when running very simple vacm-perl code. > > Is vacm-perl compatible with vacm 2.0.5? Are they both functional on > redhat 7.1? In case anyone else is encountering this problem... it is fixed by pulling vacm-perl from cvs and playing with the specfile a little bit (brp-compress breaks the auto filelist generation stuff). -- Adam Lazur, Cluster Monkey |
From: Rob L. <rl...@pl...> - 2001-10-31 01:05:14
|
On Tue, Oct 30, 2001 at 04:03:54PM -0500, Zac 'zacs' Sprackett wrote: > What patch version do you have? What 2.4 kernel are you trying to patch > against. I'm doing KCS work under 2.4 using sans driver. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/ipmitools/ipmitools/kernel/kcs/patches/2.4.x/2.4.0.ipmi_kcs_2.0.patch A patch dated 26 January, and one which was claimed on this mailing list to do stuff like chew up an entire cpu on smp systems. When i last asked, someone hinted that there might be a new version of that patch floating around somewhere... but i haven't seen it. The above patch applies with a minor reject to 2.4.13, but i haven't had an intel server board handy to test it on. ==rob -- [ Rob Latham <rl...@pl...> Developer, Admin, Alchemist ] [ Paralogic Inc. - www.plogic.com ] [ ] [ EAE8 DE90 85BB 526F 3181 1FCF 51C4 B6CB 08CC 0897 ] |
From: Zac 'z. S. <za...@sp...> - 2001-10-30 21:03:22
|
* Rob Latham scribbled: > So san... > > find that "better" version of the impi patch for 2.4 yet? What patch version do you have? What 2.4 kernel are you trying to patch against. I'm doing KCS work under 2.4 using sans driver. -z -- Zac Sprackett Contract Engineer Sprackett Holdings, Ltd. za...@sp... (613)270-8128 http://sprackett.com 1024D/E1F06C16 0CED 5CC6 69EB FC49 0EB8 15C6 0D38 FAF1 E1F0 6C16 |
From: Rob L. <rl...@pl...> - 2001-10-30 20:49:59
|
So san... find that "better" version of the impi patch for 2.4 yet? ==rob -- [ Rob Latham <rl...@pl...> Developer, Admin, Alchemist ] [ Paralogic Inc. - www.plogic.com ] [ ] [ EAE8 DE90 85BB 526F 3181 1FCF 51C4 B6CB 08CC 0897 ] |
From: Dirk W. <di...@re...> - 2001-10-17 16:50:13
|
Hi, is there anyway to deconfigure EMP support for a node which only has serial console access? the resulting GUI in hoover is somewhat confusing, because all those nodes are listed as dead. the entries in vacm_configuration look like this: #Definition for node 'my_node' NODE:my_node MODMAP: VAR:EMP:SERIAL_PORT:NONE VAR:EMP:PASSWORD:NONE VAR:SERCON:BAUDRATE:9600 VAR:SERCON:DEVICE_ADDRESS:xxx.xx.xxx.xx-port END_NODE #Definition for node 'another_node' NODE:another_node MODMAP: VAR:GLOBAL:IP_ADDRESS:xxx.xx.xx.xx VAR:EMP:SERIAL_PORT:NONE VAR:EMP:PASSWORD:NONE VAR:SERCON:BAUDRATE:38400 VAR:SERCON:DEVICE_ADDRESS:/dev/ttyRxx VAR:SYSSTAT:AUTH_PASSWORD:XXXXXX VAR:RSH:AGENT:RSH VAR:RSH:USER:root END_NODE all emp relevant entries were according to the docu created with "ipc localhost EMP:CONFIGURATION:node_name:NONE:NONE". another issue i worry about: i have only 4 machines speaking and configured EMP, but 147 emp.loose processes! lsof'ing those emp.loose processes, it appears to me like every process is only talking to my 4 emp capable nodes, i only see /dev/ttyX connections to those machines (and each ~500 pipes, they are a shared amongst the emp.loose processes). pstree output is like: -nexxus-+-apcups.loose---apcups.loose---apcups.loose---48*[apcups.loose] |-baytech.loose---baytech.loose---baytech.loose---48*[baytech.loose] |-emp.loose---emp.loose---emp.loose---144*[emp.loose] |-icmp_echo.loose |-msc.loose---msc.loose---msc.loose---48*[msc.loose] |-rsh.loose---rsh.loose---rsh.loose---48*[rsh.loose] |-sbt2.loose---sbt2.loose---sbt2.loose---48*[sbt2.loose] |-sercon.loose---sercon.loose---sercon.loose---48*[sercon.loose] |-sys_stat.loose |-va1000.loose `-vasenet.loose---vasenet.loose---vasenet.loose---48*[vasenet.loose] if there's somebody still listening here, i would be happy if somebody could tell me how to get rid of the confusing "dead" entries in hoover. also i would like to know, how to restrict the number of "*-loose" processes. i am afraid if i hook up the next 100 node cluster i am running out of resources on my management node. thx, ~dirkw ----------- Dirk Wetter Renaissance Technologies/NY |
From: Dale H. <ro...@ma...> - 2001-10-14 00:18:55
|
Hey folks, Heard that the APC additions to VACM are being put aside, a casuality of VA laying off it's Software Engineering team. Any idea if APC is planning to look for someone to do some better support outside of VACM? Linux could still use it, despite VA's problems. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dale Harris <ro...@ma...> GPG key: 372FBD57 http://www.maybe.org/ |
From: Tony K. <to...@ma...> - 2001-10-10 13:26:41
|
Hi... just a quick question - if you have a tarball distribution of VACM, what do you need to do to make your own RPMs (src and i386)? Thanks in advance for your assistance. -- ------------------------------------------------------------------------ Tony Kavadias <to...@ma...> |
From: Tony K. <to...@op...> - 2001-10-07 01:04:34
|
I am really sorry that you have this point of view on open source software... But in short... what use is publishing a piece of code with any kind of license if you can't use it? OK, choosing to publish your work with an open-source license is one thing, but in my point of view, I don't have the resources to go and implement a new version of a piece of hardware and firmware developed by another company, and the collateral to fight off any copyright charges or royalties charged against me for re-developing that hardware or firmware, just so that VACM can be used with it. And in many of not most cases, the hardware/firmware I could want VACM to work with is either embedded (I can't reproduce it myself even if I wanted to) or comes in a library which is licensed in such a manner that it can no way be GPL'd. I very often get licenses from developer SDKs for device driver software which boil down to "the enclosed software is so close to non-disclosure that I'd be put in very serious trouble if any of this code is exposed in any form other than the one it is presented to the developer when shipped". And reverse engineering and re-implementation is also out of the question as far as the licenses and copyright that is shipped with the SDK are concerned. There's no way that developers can use VACM with such resources if there is severe limits to what hardware-related software products are available as open-source anything. So, given such a severe requirement for VACM to adhere to, what is the point in publishing the software in that manner if its license prohibits its use beyond being a toy for PC users?! -- Tony Kavadias <to...@ma...> > From: Mike Snitzer <msn...@pl...> > Date: Fri, 5 Oct 2001 09:37:24 -0400 > To: to...@ma... > Cc: vac...@li... > Subject: Re: Relicensing of VACM components > > I hope the remaining vacm project developers (are there any?) take a very > strong stance against Tony's request to LGPL portions of vacm. Reason > being; _all_ of VACM has been made available under the GPL for public > consumption and scrutiny, and as such many of us (much like Tony) have > been able to make use of this monitoring framework. I realize that > ultimately Tony (and his company?) just want to protect the intellectual > property that is their proprietary hardware solution but asking for vacm > to be LGPL'd is like asking for any number of companies to use VACM for > their personal/commercial gain without helping contribute to the > intellectual property that gave them the ability to make use of libloose > et. al. in the first place; namely the intellectual property of those > developers who made VACM freely available (GPL'd) to the open source > community. > > The VACM project, and any GPL'd project for that matter, should make every > attempt to encourage open standards in _both_ hardware and software. If > some developer/company doesn't like this; tell them to go else where for a > solution! If they have been able to engineer proprietary hardware that > needs to be so highly guarded by means of closed source solutions; then > they should have the know-how to be able to monitor their closed hardware > with closed software that originates from within their company! > > In short, you can't have your cake and eat it too.. and I hope others feel > the same way. > > Mike > > > Tony Kavadias (to...@op...) said: > >> Hi! >> >> I would like to ask for your comments in LGPL'ing the following >> pieces of VACM: >> >> - libloose, the library used to interface loosely coupled VACM >> modules to nexxus, >> - libvacmclient, the library required by VACM clients to communicate >> with nexxus. >> >> Also, the following ought to be re-licensed to allow complete >> freedom in the use of the following code which would otherwise >> not serve its intended purpose: >> >> - skel, the sample code recommended for use with libloose in building >> loosely coupled VACM modules. >> >> The re-licensing of these components will help VACM: >> >> - be useful in the deployment of control solutions where the >> components or devices that need to be controlled include the use >> of >> >> - be useful in the development of VACM clients, where these clients >> may require the use of proprietary software, or allow people to >> customize existing proprietary clients to allow them to become >> VACM clients. >> >> I would like to see VACM incorporate the use of the LGPL and/or >> some other open-source license that does not enforce you to apply >> that license to other code. This is the very reason why I am seeing >> VACM become difficult to deploy on projects outside the open source >> development community. >> >> I understand the GPL's role in providing free software to the computing >> community at large, but I find that VACM's licensing as it currently >> stands does not allow it to enter the environments which would other- >> wise make it useful for its intended purpose in hardware control and >> management. >> >> I would like to see these licensing changes applied to VACM, and >> I hope that other developers see my point of view in extending the >> usefulness of VACM to areas that the GPL otherwise does not allow. >> >> Thanks. >> >> -- >> ------------------------------------------------------------------------ >> Tony Kavadias <to...@ma...> >> >> _______________________________________________ >> Vacm-develop mailing list >> Vac...@li... >> https://lists.sourceforge.net/lists/listinfo/vacm-develop |
From: Mike S. <msn...@pl...> - 2001-10-05 13:37:58
|
I hope the remaining vacm project developers (are there any?) take a very strong stance against Tony's request to LGPL portions of vacm. Reason being; _all_ of VACM has been made available under the GPL for public consumption and scrutiny, and as such many of us (much like Tony) have been able to make use of this monitoring framework. I realize that ultimately Tony (and his company?) just want to protect the intellectual property that is their proprietary hardware solution but asking for vacm to be LGPL'd is like asking for any number of companies to use VACM for their personal/commercial gain without helping contribute to the intellectual property that gave them the ability to make use of libloose et. al. in the first place; namely the intellectual property of those developers who made VACM freely available (GPL'd) to the open source community. The VACM project, and any GPL'd project for that matter, should make every attempt to encourage open standards in _both_ hardware and software. If some developer/company doesn't like this; tell them to go else where for a solution! If they have been able to engineer proprietary hardware that needs to be so highly guarded by means of closed source solutions; then they should have the know-how to be able to monitor their closed hardware with closed software that originates from within their company! In short, you can't have your cake and eat it too.. and I hope others feel the same way. Mike Tony Kavadias (to...@op...) said: > Hi! > > I would like to ask for your comments in LGPL'ing the following > pieces of VACM: > > - libloose, the library used to interface loosely coupled VACM > modules to nexxus, > - libvacmclient, the library required by VACM clients to communicate > with nexxus. > > Also, the following ought to be re-licensed to allow complete > freedom in the use of the following code which would otherwise > not serve its intended purpose: > > - skel, the sample code recommended for use with libloose in building > loosely coupled VACM modules. > > The re-licensing of these components will help VACM: > > - be useful in the deployment of control solutions where the > components or devices that need to be controlled include the use > of > > - be useful in the development of VACM clients, where these clients > may require the use of proprietary software, or allow people to > customize existing proprietary clients to allow them to become > VACM clients. > > I would like to see VACM incorporate the use of the LGPL and/or > some other open-source license that does not enforce you to apply > that license to other code. This is the very reason why I am seeing > VACM become difficult to deploy on projects outside the open source > development community. > > I understand the GPL's role in providing free software to the computing > community at large, but I find that VACM's licensing as it currently > stands does not allow it to enter the environments which would other- > wise make it useful for its intended purpose in hardware control and > management. > > I would like to see these licensing changes applied to VACM, and > I hope that other developers see my point of view in extending the > usefulness of VACM to areas that the GPL otherwise does not allow. > > Thanks. > > -- > ------------------------------------------------------------------------ > Tony Kavadias <to...@ma...> > > _______________________________________________ > Vacm-develop mailing list > Vac...@li... > https://lists.sourceforge.net/lists/listinfo/vacm-develop |
From: Tony K. <to...@op...> - 2001-10-05 01:46:24
|
Hi! I would like to ask for your comments in LGPL'ing the following pieces of VACM: - libloose, the library used to interface loosely coupled VACM modules to nexxus, - libvacmclient, the library required by VACM clients to communicate with nexxus. Also, the following ought to be re-licensed to allow complete freedom in the use of the following code which would otherwise not serve its intended purpose: - skel, the sample code recommended for use with libloose in building loosely coupled VACM modules. The re-licensing of these components will help VACM: - be useful in the deployment of control solutions where the components or devices that need to be controlled include the use of - be useful in the development of VACM clients, where these clients may require the use of proprietary software, or allow people to customize existing proprietary clients to allow them to become VACM clients. I would like to see VACM incorporate the use of the LGPL and/or some other open-source license that does not enforce you to apply that license to other code. This is the very reason why I am seeing VACM become difficult to deploy on projects outside the open source development community. I understand the GPL's role in providing free software to the computing community at large, but I find that VACM's licensing as it currently stands does not allow it to enter the environments which would other- wise make it useful for its intended purpose in hardware control and management. I would like to see these licensing changes applied to VACM, and I hope that other developers see my point of view in extending the usefulness of VACM to areas that the GPL otherwise does not allow. Thanks. -- ------------------------------------------------------------------------ Tony Kavadias <to...@ma...> |
From: San M. <net...@va...> - 2001-09-18 18:10:12
|
Oh yes.. sorry bout that. Nexxus has no problems with simultaneous connections... The new architecture will not only support multiple connections.. but will also be more event driven.. so polling wouldn't be required.. this of course is still far far away.. but we're working on the new framework which will be in cvs at some point in the future.. -san -----Original Message----- From: msn...@ma... [mailto:msn...@ma...] On Behalf Of 'Mike Snitzer' Sent: Tuesday, September 18, 2001 11:07 AM To: San Mehat Cc: vac...@li... Subject: Re: PATCH: vacm_sys_statd and flim enhancements San, I take it you didn't see my question nested in my ramblings; here it is again: I now plan to make systat.p in flim have a threaded poll_timeout() (1 data collection thread for each node). This seems like a logical way to achieve increased scalability during data collection. SAN, WILL THE NEXXUS SUPPORT MULTIPLE SIMULTANEOUS CONNECTIONS? At first glance/trial the nexxus seemed to be ok, but what if I had 128 or 256 data collection threads hitting it? please advise. Mike San Mehat (net...@va...) said: > Heh.. all and any help is appreciated... > > Zac and I are actually preparing a 'statement' as to the future of > vacm... without elaborating ill just say that we plan to keep developing > the new architecture even though VA has decided not to participate... > |
From: 'Mike S. <msn...@pl...> - 2001-09-18 18:07:37
|
San, I take it you didn't see my question nested in my ramblings; here it is again: I now plan to make systat.p in flim have a threaded poll_timeout() (1 data collection thread for each node). This seems like a logical way to achieve increased scalability during data collection. SAN, WILL THE NEXXUS SUPPORT MULTIPLE SIMULTANEOUS CONNECTIONS? At first glance/trial the nexxus seemed to be ok, but what if I had 128 or 256 data collection threads hitting it? please advise. Mike San Mehat (net...@va...) said: > Heh.. all and any help is appreciated... > > Zac and I are actually preparing a 'statement' as to the future of > vacm... without elaborating ill just say that we plan to keep developing > the new architecture even though VA has decided not to participate... > |
From: San M. <net...@va...> - 2001-09-18 17:57:12
|
Heh.. all and any help is appreciated... Zac and I are actually preparing a 'statement' as to the future of vacm... without elaborating ill just say that we plan to keep developing the new architecture even though VA has decided not to participate... -----Original Message----- From: vac...@li... [mailto:vac...@li...] On Behalf Of Mike Snitzer Sent: Tuesday, September 18, 2001 10:51 AM To: vac...@li... Subject: [Vacm-develop] PATCH: vacm_sys_statd and flim enhancements Hello, I work for Paralogic, Inc and have added some useful features to vacm_sys_statd and flim. I have attached the patch (112K) that applies cleanly to vacm-2.0.5 (patch details listed below), there are also RPMS and SRPMS at: ftp://ftp.plogic.com/pub/vacm/ I figured the greater vacm community (what's left of it) would appreciate these new features, please email me with any feedback/bug fixes/recommendations you might have. I now plan to make systat.p in flim have a threaded poll_timeout() (1 data collection thread for each node). This seems like a logical way to achieve increased scalability during data collection. SAN, will the nexxus support multiple simultaneous connections? At first glance/trial the nexxus seemed to be ok; please advise. I also will be adding alarm status monitoring. That is, establish the desired threshold for a particular statistic; and if exceeded notify the configured contact with information regarding the alarm. I'd like to make use of vacm::perl coupled with mon and just have flim have a plugin to facilitate alarm threshold configuration. ZAC, care to fix vacm::perl so that it actually works with vacm-2.0.5? Again if anyone has other suggestions please advise. I also plan on making the flim interface and certain functionality of its plugins suck less, and I'd appreciate it if any of you helped me out. Thanks, Mike ----- Paralogic PATCH - overview of changes: vacm_sys_statd: SYSSTAT:SENSORS:<nodename> - support for cpu temp and fans data collection via lm_sensors (libsensors), supported chips include: w83781d, w83627hf, lm75, lm78, lm87 (serverworks), adm1025 (via) SYSSTAT:NET:<nodename> - support for network statistics data collection, provides the ip address for each network interface, a data collection time stamp, and all data in /proc/net/dev SYSSTAT:ECC:<nodename> - support for ECC Single and Multi bit errors, bank number, and memory size is available if ECC kernel module is loaded (/proc/ram) SYSSTAT:FS:<nodename> - support for devfs filesystems I've also added some configure flags; --without-sensors do not build with lm_sensors support --without-plogic do not build reduced paralogic vacm (use this flag to build emp, baytech, msc, va1000, vasenet, sbt2, quanta) Flim: - node state is now monitored via src/node.c:node_state_timeout(), and uses flim_plugin_broadcast() to send "node_up" or "node_down" to all plugins only when a node changes state, the default timeout for pinging each node is 60 seconds. - when a plugin sends the "ready" message back to the client, it now gets the state of all nodes (UP or DOWN, on first pass nodes are initialized to UP) in addition to what "ready" originally did. - icon for node in "Nexxus & Node" tree is now displayed according to nodes' availability; red icon for a node that is down, normal 1u node icon if up. - conf.c: moved nexxus startup to before plugins, makes more sense systat.p: - Added notebook pages for lm_sensors, ecc, and network usage. ECC and lm_sensors are only collected on nodes that support them, as determined on the first pass of data collection on all nodes - Misc now displays Linux Version information - if a node is not reachable (via icmp_echo:ping:<nodename>) the whole frame for <nodename> is hidden, when it becomes available again so will the frame. - systat.p.c will react to a node's sys_statd dying by hiding the data presentation box; and changing the label to be: "No Sysstat support on <node>" - when a node or sys_statd of a node returns to an UP state, the graphical display changes accordingly |
From: Mike S. <msn...@pl...> - 2001-09-18 17:51:25
|
Hello, I work for Paralogic, Inc and have added some useful features to vacm_sys_statd and flim. I have attached the patch (112K) that applies cleanly to vacm-2.0.5 (patch details listed below), there are also RPMS and SRPMS at: ftp://ftp.plogic.com/pub/vacm/ I figured the greater vacm community (what's left of it) would appreciate these new features, please email me with any feedback/bug fixes/recommendations you might have. I now plan to make systat.p in flim have a threaded poll_timeout() (1 data collection thread for each node). This seems like a logical way to achieve increased scalability during data collection. SAN, will the nexxus support multiple simultaneous connections? At first glance/trial the nexxus seemed to be ok; please advise. I also will be adding alarm status monitoring. That is, establish the desired threshold for a particular statistic; and if exceeded notify the configured contact with information regarding the alarm. I'd like to make use of vacm::perl coupled with mon and just have flim have a plugin to facilitate alarm threshold configuration. ZAC, care to fix vacm::perl so that it actually works with vacm-2.0.5? Again if anyone has other suggestions please advise. I also plan on making the flim interface and certain functionality of its plugins suck less, and I'd appreciate it if any of you helped me out. Thanks, Mike ----- Paralogic PATCH - overview of changes: vacm_sys_statd: SYSSTAT:SENSORS:<nodename> - support for cpu temp and fans data collection via lm_sensors (libsensors), supported chips include: w83781d, w83627hf, lm75, lm78, lm87 (serverworks), adm1025 (via) SYSSTAT:NET:<nodename> - support for network statistics data collection, provides the ip address for each network interface, a data collection time stamp, and all data in /proc/net/dev SYSSTAT:ECC:<nodename> - support for ECC Single and Multi bit errors, bank number, and memory size is available if ECC kernel module is loaded (/proc/ram) SYSSTAT:FS:<nodename> - support for devfs filesystems I've also added some configure flags; --without-sensors do not build with lm_sensors support --without-plogic do not build reduced paralogic vacm (use this flag to build emp, baytech, msc, va1000, vasenet, sbt2, quanta) Flim: - node state is now monitored via src/node.c:node_state_timeout(), and uses flim_plugin_broadcast() to send "node_up" or "node_down" to all plugins only when a node changes state, the default timeout for pinging each node is 60 seconds. - when a plugin sends the "ready" message back to the client, it now gets the state of all nodes (UP or DOWN, on first pass nodes are initialized to UP) in addition to what "ready" originally did. - icon for node in "Nexxus & Node" tree is now displayed according to nodes' availability; red icon for a node that is down, normal 1u node icon if up. - conf.c: moved nexxus startup to before plugins, makes more sense systat.p: - Added notebook pages for lm_sensors, ecc, and network usage. ECC and lm_sensors are only collected on nodes that support them, as determined on the first pass of data collection on all nodes - Misc now displays Linux Version information - if a node is not reachable (via icmp_echo:ping:<nodename>) the whole frame for <nodename> is hidden, when it becomes available again so will the frame. - systat.p.c will react to a node's sys_statd dying by hiding the data presentation box; and changing the label to be: "No Sysstat support on <node>" - when a node or sys_statd of a node returns to an UP state, the graphical display changes accordingly |
From: Dirk W. <di...@re...> - 2001-09-14 15:23:16
|
Hi, this is not my observation. i am running it on a couple of 2.4 vacm clients and one server since a while. i see odd effects, which means, sometimes it's working and sometimes it's not. but other than that those SMP systems are fine... ~dirkw On Fri, 14 Sep 2001, San Mehat wrote: > Heh. Which is why there is a note indicating the driver should not be > used with 2.4 > > > -----Original Message----- > From: Ard van Breemen [mailto:ar...@te...] > Sent: Friday, September 14, 2001 4:31 AM > To: San Mehat > Cc: 'Rob Latham'; vac...@li... > Subject: Re: [Vacm-develop] IPMI and 2.4 kernels > > On Thu, Sep 13, 2001 at 11:27:50AM -0700, San Mehat wrote: > > X-Mailer: Microsoft Outlook, Build 10.0.2627 > Fix that! > > I believe that driver is not smp safe and as such using the watchdog > > functionality can cause spontaneous hardware watchdog resets.. > > undesirable enough? :) > The biggest undesirable behaviour is that it uses 100%cpu time of one > cpy in SMP systems. You don't want to have a driver that eats up a > single > cpu on a production system. > > The cullprit is in the busy-waiting for the data that takes too long. > > -- > <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl > http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html > Let your government know you value your freedom. Sign the petition: > http://petition.eurolinux.org/ > > > _______________________________________________ > Vacm-develop mailing list > Vac...@li... > https://lists.sourceforge.net/lists/listinfo/vacm-develop > |
From: San M. <net...@va...> - 2001-09-14 15:06:26
|
Heh. Which is why there is a note indicating the driver should not be used with 2.4 -----Original Message----- From: Ard van Breemen [mailto:ar...@te...] Sent: Friday, September 14, 2001 4:31 AM To: San Mehat Cc: 'Rob Latham'; vac...@li... Subject: Re: [Vacm-develop] IPMI and 2.4 kernels On Thu, Sep 13, 2001 at 11:27:50AM -0700, San Mehat wrote: > X-Mailer: Microsoft Outlook, Build 10.0.2627 Fix that! > I believe that driver is not smp safe and as such using the watchdog > functionality can cause spontaneous hardware watchdog resets.. > undesirable enough? :) The biggest undesirable behaviour is that it uses 100%cpu time of one cpy in SMP systems. You don't want to have a driver that eats up a single cpu on a production system. The cullprit is in the busy-waiting for the data that takes too long. -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ |
From: Ard v. B. <ar...@te...> - 2001-09-14 11:31:23
|
On Thu, Sep 13, 2001 at 11:27:50AM -0700, San Mehat wrote: > X-Mailer: Microsoft Outlook, Build 10.0.2627 Fix that! > I believe that driver is not smp safe and as such using the watchdog > functionality can cause spontaneous hardware watchdog resets.. > undesirable enough? :) The biggest undesirable behaviour is that it uses 100%cpu time of one cpy in SMP systems. You don't want to have a driver that eats up a single cpu on a production system. The cullprit is in the busy-waiting for the data that takes too long. -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ |
From: San M. <net...@va...> - 2001-09-13 19:11:33
|
Hmm... sounds like the upgrade toasted... contact your intel representative for the special 'bios recovery floppy' and instructions on how to recover your toasted bios -san -----Original Message----- From: vac...@li... [mailto:vac...@li...] On Behalf Of Martin, St=E9phane Sent: Thursday, September 13, 2001 11:56 AM To: vac...@li... Subject: [Vacm-develop] BMC upgrade Hi, I want to run VACM on an Intel L440GX+. I have tried to upgrade the BMC firmware on the motherboard from 0.9? to 1.14 as stated on the VACM Users and Programmers Manual (section 5.2.27). The upgrade seems to run correctly, however it freezes at the end and now there is no more activity on the motherboard. Even the BIOS doesn't start. The whole setup was running perfectly with Red-Hat 6.2 prior the upgrade. Does anyone enconter this problem and did you find a solution?=20 ------------------------------------------------------------------------ ---- --------- Stephane Martin, ing. Kontron Communications Low Level Software Engineer 616 Cure-Boivin Tel (450) 437-4661 ext: 2349 Boisbriand, Quebec Fax (450) 437-8053 Canada, J7G 2A7 mailto:ste...@ca... http://www.teknor.com _______________________________________________ Vacm-develop mailing list Vac...@li... https://lists.sourceforge.net/lists/listinfo/vacm-develop |
From: San M. <net...@va...> - 2001-09-13 19:10:29
|
Oh yes and dean too :) -----Original Message----- From: Dean Johnson [mailto:dt...@ub...] Sent: Thursday, September 13, 2001 11:55 AM To: Zac 'zacs' Sprackett Cc: San Mehat; 'Rob Latham'; vac...@li... Subject: Re: [Vacm-develop] IPMI and 2.4 kernels On Thu, 2001-09-13 at 13:22, Zac 'zacs' Sprackett wrote: > * San Mehat scribbled: > > Heh thanks.. hopefully the vacm-develop mailing list wont turn into a > > 'help-find-san-a-job' list ;) > > Feel free to help zac find a job though :) > And Dean too! -Dean |
From:
<ste...@ca...> - 2001-09-13 18:56:05
|
Hi, I want to run VACM on an Intel L440GX+. I have tried to upgrade the BMC firmware on the motherboard from 0.9? to 1.14 as stated on the VACM Users and Programmers Manual (section 5.2.27). The upgrade seems to run correctly, however it freezes at the end and now there is no more activity on the motherboard. Even the BIOS doesn't start. The whole setup was running perfectly with Red-Hat 6.2 prior the upgrade. Does anyone enconter this problem and did you find a solution? ---------------------------------------------------------------------------- --------- Stephane Martin, ing. Kontron Communications Low Level Software Engineer 616 Cure-Boivin Tel (450) 437-4661 ext: 2349 Boisbriand, Quebec Fax (450) 437-8053 Canada, J7G 2A7 mailto:ste...@ca... http://www.teknor.com |
From: Dean J. <dt...@ub...> - 2001-09-13 18:55:35
|
On Thu, 2001-09-13 at 13:22, Zac 'zacs' Sprackett wrote: > * San Mehat scribbled: > > Heh thanks.. hopefully the vacm-develop mailing list wont turn into a > > 'help-find-san-a-job' list ;) >=20 > Feel free to help zac find a job though :) >=20 And Dean too! -Dean |
From: Zac 'z. S. <za...@sp...> - 2001-09-13 18:23:38
|
* San Mehat scribbled: > Heh thanks.. hopefully the vacm-develop mailing list wont turn into a > 'help-find-san-a-job' list ;) Feel free to help zac find a job though :) -z -- Zac Sprackett Software Engineer VA Linux Systems za...@va... (613)270-8128 http://www.valinux.com 1024D/E1F06C16 0CED 5CC6 69EB FC49 0EB8 15C6 0D38 FAF1 E1F0 6C16 |
From: San M. <net...@va...> - 2001-09-13 18:13:29
|
I believe that driver is not smp safe and as such using the watchdog functionality can cause spontaneous hardware watchdog resets.. undesirable enough? :) -san (still digging) -----Original Message----- From: Rob Latham [mailto:rl...@pl...] Sent: Thursday, September 13, 2001 11:12 AM To: San Mehat Cc: 'Rob Latham'; vac...@li... Subject: Re: [Vacm-develop] IPMI and 2.4 kernels On Thu, Sep 13, 2001 at 11:02:46AM -0700, San Mehat wrote: > There is a 2.4 driver.. ill dig it up Ok, so i found one in cvs for impitools. But in http://www.geocrawler.com/archives/3/1160/2001/5/0/5749716/ you say this patch causes "undesired behavior" , and that a new one is in the works. All the timestamps in the cvs patch are january 26, and since your message is mid-may, i'm hoping there's a working patch "somewhere" :> if you could post that patch when you find it, that'd be great. or just clarify what "undesired behavior" means, and maybe i can live with that :> ==rob -- [ Rob Latham <rl...@pl...> Developer, Admin, Alchemist ] [ Paralogic Inc. - www.plogic.com ] [ ] [ EAE8 DE90 85BB 526F 3181 1FCF 51C4 B6CB 08CC 0897 ] |