399 lines
14 KiB
Plaintext
399 lines
14 KiB
Plaintext
*** - priority for future major release
|
|
XXX - priority for future minor release
|
|
ooo - priority code cleanup that should be done
|
|
|
|
branches to merge
|
|
-----------------
|
|
|
|
to test
|
|
-------
|
|
ipmi-oem get/set bmc services for intels2600jf
|
|
|
|
FreeIPMI FAQ/documentation
|
|
--------------------------
|
|
|
|
FreeIPMI general
|
|
----------------
|
|
- oem extensions
|
|
- test/check handle firmware versions
|
|
- document firmware versions in docs/ or mans/?
|
|
- build system
|
|
- single Makefile, so parallel build faster?
|
|
- consider moving #defines to #enums globally for easier debugging w/
|
|
gdb
|
|
- event handling api/mechanism
|
|
- loop/try again on NODE_BUSY errors (***)
|
|
- treat more like network busy than error?
|
|
- option for alternate behavior?
|
|
- update text documents to texinfo (ooo)
|
|
- OEM extensions generalized
|
|
- generalize "+" syntax in ipmipower to all FreeIPMI tools?
|
|
- or use extra option?
|
|
- audit/cleanup memsets, use sizeof() when appropriate
|
|
|
|
FreeIPMI new stuff
|
|
------------------
|
|
- ASF - maybe support base protocol stuff like rmcp?
|
|
- picmg hpm/hpmi.1 standard - defines ipmi firmware update stuff
|
|
- http://www.picmg.org/v2internal/specifications.htm
|
|
- pmbus.org
|
|
- doable via FreeIPMI? Can pass through Smbus to PmBus to do power control monitoring?
|
|
- server simulator
|
|
- support testing at scale
|
|
- test larger set of corner cases, possibilities, workarounds, etc.
|
|
- different SDR combos
|
|
- different SEL entries
|
|
- all permutations of sensors, etc.
|
|
- config tools for (***)
|
|
- intel node manager (***)
|
|
- maybe not? Intel NM does not configure via a standard
|
|
checkout/commit fashion. Policies are created, then removed.
|
|
In addition, policies must be disabled before they can be
|
|
reconfigured.
|
|
|
|
some of these mechanisms could be hidden (i.e. if user changed
|
|
any configuration, disable policy, then re-configure it, then
|
|
re-enable it), but some would require blatant assumptions, such
|
|
as number of policies to output into the --checkout .conf file.
|
|
- firmware firewall
|
|
- other config options in ipmi-oem
|
|
- inventec mac/shared nic stuff
|
|
- will reboot BMC, is big problem
|
|
- fru library like libipmimonitoring
|
|
- ipmi proxy
|
|
- capture lan and do inband, maybe useful if you have dedicated port
|
|
that can't be seen by the network, and you don't have enough switch
|
|
ports to have both plugged up to the network.
|
|
- OCP IPMI extensions
|
|
- FRU record
|
|
- command extensions
|
|
|
|
FreeIPMI maybe stuff
|
|
--------------------
|
|
redo ipmipower/ipmiconole using phi accrual failure detector algorithm?
|
|
|
|
library general
|
|
---------------
|
|
- merge all libs into one? would aid debian packaging.
|
|
- make package layout simpler?
|
|
- make .so-naming consistent?
|
|
- merge all except libipmidetect?
|
|
|
|
libfreeipmi
|
|
-----------
|
|
- forwarded command support (errata 35b)
|
|
- support serial interface?
|
|
- have funcs that return buflen return ssize_t?, input should be
|
|
size_t and void *? like read(), write()?
|
|
- xRC4
|
|
- on Quanta S99Q/Dell FS12-TY
|
|
- Began on branches/xrc, from the branch ChangeLog
|
|
- xRC has been dropped for the time being. After researching xRC,
|
|
ultimately the current architecture of all of FreeIPMI is
|
|
ill-suited for it. As a stream based encryption, too much
|
|
architecture of FreeIPMI has been based on individual packets
|
|
being sent/recved/encrypted/decrypted independently of each other.
|
|
Most of xRC implementation is doable with some hacks. For
|
|
example, the initialization vector and data offsets could be
|
|
passed as in/out parameters to the assemble/disassemble packet
|
|
functions. The Krc could be re-generated as needed if the
|
|
initialization vector had been noticed to change (or data offset
|
|
== 0). However, the deal break was an "out-of-band" requirement
|
|
for implementation of the suspend/resume payload encryption. In
|
|
particular, if a packet from the BMC that had a new initialization
|
|
vector was dropped on the network, the client would need to send a
|
|
"suspend/resume payload encryption" packet to tell the BMC to
|
|
start over again before doing a resend. Architecturally, this was
|
|
the part that would have been VERY difficult to implement across
|
|
FreeIPMI as the client would suddenly be required to understand
|
|
the assemble/disassemble subtleties underneath and send the packet
|
|
on its own.
|
|
|
|
libfreeipmi-fiid
|
|
----------------
|
|
- rearch for speed to not use strings, use macros + strings in internal. So something like:
|
|
{1, FOO_MACRO, "FIELD_NAME", FLAGS}
|
|
so avoid string compares for get/set/compare/etc., but have available for debug output.
|
|
|
|
libfreeipmi-driver
|
|
------------------
|
|
- kcs/ssif/etc
|
|
- how to deal with servers w/ multiple BMCs (***)
|
|
- need knew inband option on tools?
|
|
- ssif userspace implementation
|
|
- see ipmiutil for example
|
|
|
|
|
|
libfreeipmi-api
|
|
---------------
|
|
--fail-if-ipmi-not-detected
|
|
- would need inband flag - discover vs. not-discover on locate
|
|
- Ultimately impossible to do correctly, vendor need not store
|
|
anything in acpi/smbios/etc.
|
|
- User can use ipmi-locate if they really want to probe?
|
|
|
|
libfreeipmi-interpret
|
|
---------------------
|
|
- handle sensor/sel events outside of spec - configurable in some way?
|
|
- some vendors have extra bits not in spec
|
|
- handle sensor/sel events differently for different sensors on same
|
|
motherboard
|
|
- e.g.
|
|
SENSORFAULT | State Deasserted
|
|
SENSOROK | State Asserted
|
|
- need mechanism to specify record ids/sensor number/entity/generator?
|
|
- some sensor interpretations dependent on sensor number, way to add?
|
|
- QSSCS4R SMI Timeout & Power Throttled sensors
|
|
- same event-type/sensor-type/etc., but different interpretation??
|
|
|
|
libfreeipmi-sdr
|
|
---------------
|
|
|
|
libfreeipmi-fru
|
|
---------------
|
|
|
|
libfreeipmi-sel
|
|
---------------
|
|
- cleanup parsing functions
|
|
|
|
libipmiconsole
|
|
--------------
|
|
- "learn" workarounds function - to figure out workaround flags for user support simultaneous SOL sessions
|
|
- very hard, almost impossible to do??
|
|
- "check" function, to see if session currently running
|
|
- engine_submit() - try and move initialization/setup code into engine
|
|
to reduce time spent in engine_submit(), this is the core loop used by
|
|
conman and other console software. (***)
|
|
- use conditional signals w/ garbage collector
|
|
- should work, it's not like the poll loop from before
|
|
- buffer character input chars and send in chunks as necessary (nagle like)
|
|
- perhaps ~100ms of character data to reduce packets send?
|
|
- as far as I can tell, most ssh implementations send 1 char at a time,
|
|
to most users that libipmiconsole will get similar interaction.
|
|
|
|
libipmimonitoring
|
|
-----------------
|
|
- select sensors via sensor name?
|
|
- deal w/ motherboards with slightly different SDRs
|
|
- but some mobos have sensor name == each other, so what is the purpose?
|
|
- would need to also add sensor number with it??
|
|
- also to deal w/ probability SDR's change on some mobos
|
|
- how specify record ids w/ sharing
|
|
- entity sensor names
|
|
|
|
tools common
|
|
------------
|
|
- entity ids 0x41, 0x42, are "identical" to other entries
|
|
- should map them together for --entity-id-names output in
|
|
ipmi-sensors and ipmi-sel?
|
|
- hostrange exclude hosts option
|
|
- not really necessary in FreeIPMI? in pdsh, the reason you really
|
|
need this is because you can do -a (all) or -g (genders
|
|
attribute/netgroups attribute).
|
|
- if user inputs hostname of localhost, do inband not outofband?
|
|
- config via environment variables too - like config file?
|
|
- config file - support workarounds/etc. for heterogenous clusters
|
|
- maybe?
|
|
- workaround-flags BLAH hosts[1-3]
|
|
- workaround-flags FOO hosts[5-9]
|
|
- read/store username/password/k_g out of file encrypted so it's not
|
|
sitting there in the clear
|
|
- convenience function to loop infinite times necessary to expand (***)
|
|
hostrange until done.
|
|
- i.e. node[0-4]-[3-10]
|
|
- hack is in ipmipower right now for 2s, no where else supported
|
|
|
|
ipmi-sensors
|
|
------------
|
|
- split vendor files into motherboard files? Is getting big.
|
|
- option to check sensor thresholds manually instead of event bitmask
|
|
- some mobos seem to set flags incorrectly
|
|
- column for sensor number?
|
|
- useful for shared sensor output?
|
|
- how to select specific shared sensor on commad line, can't do normally (***)
|
|
- i.e. perhaps need to do record-id and something else, like
|
|
-r 5.2 to indicate record id 5 and offset 2.
|
|
- issue for libipmimonitoring too?
|
|
- remove shared sensor option
|
|
- make default like it should be
|
|
- this really ties to many other shared sensor issues
|
|
- do not error out on unexpected sensor_read errors, move on? (***)
|
|
- i.e. unexpected completion code error?
|
|
- require rework of sensor-read lib? How detect session timeout, etc.
|
|
- make 'discretereading' on by default?
|
|
- it does not appear that to be illegal by IPMI spec.
|
|
|
|
ipmi-sel
|
|
--------
|
|
- binary search like mechanism to make --display faster
|
|
- support kernel panic OEM event 0xF0
|
|
- can't make work, is just my motherboard? Or perhaps specific panics, not test panics?
|
|
- redhat doesn't enable by default, probably don't need to worry about this much
|
|
- see http://cateee.net/lkddb/web-lkddb/IPMI_PANIC_STRING.html
|
|
- see http://www.cyberciti.biz/tips/compiling-linux-kernel-module.html
|
|
- non-uncommon for motherboards to output events both directions of
|
|
crossing threshold. Can be confusing b/c assert/deassert not output
|
|
by default. Should alter output in these cases?
|
|
- --delete-date-range (***)
|
|
- ganglia plugin?
|
|
- nagios plugin?
|
|
|
|
ipmipower
|
|
--------
|
|
- mechanism to parallelize oem extension options ranges. (***)
|
|
- i.e. on myhost+[0-3]. Simultaneous power off slots 0-3.
|
|
- perhaps --serialize-same-host option
|
|
- Will require larger re-architecture, create additional sockets per
|
|
power control attempt. The constant sockets created in the
|
|
ipmipower_connection structs limit this for the time being.
|
|
|
|
ipmi-fru
|
|
--------
|
|
- write FRU data option
|
|
- for OEM integrators
|
|
- or should be in bmc-device?
|
|
|
|
bmc-device
|
|
--------
|
|
- set bmc global enables
|
|
- really should be done by firmware or distro
|
|
- or only as needed in ipmi-oem per vendor need?
|
|
- (NOT CONFIRMED) get auxiliary log status
|
|
- set sensor reading (***)
|
|
|
|
bmc-watchdog
|
|
------------
|
|
Log to normal syslog, not to bmc log
|
|
- legacy from when bmc-wachdog in cron, not daemon, and would log
|
|
every bmc reset
|
|
cleanup to finally use libfreeipmi or common tool functions
|
|
|
|
ipmiconsole
|
|
-----------
|
|
- support other escape codes like w/ &D
|
|
- support F1-F12 suggested by user
|
|
|
|
ipmi-config
|
|
------------
|
|
- make tools prefix sections w/ appropriate prefixes to allow
|
|
for checking of what sections should be used??
|
|
- i.e. BMC, CHASSIS, PEF, etc.
|
|
- probably not, too much backwords compatability crap to handle.
|
|
Also would make code ugly as hell to make all duplicate sections.
|
|
should do database of what sections go to what categories
|
|
- core: support ipv4 mapped ipv6 addresses?
|
|
- until in spec, no point, maybe deal in ipmi-oem?
|
|
- chassis, pef & sensors: conf.5 manpage
|
|
- chassis: (NEVER TESTED) panel button config - need hardware w/ this
|
|
- chassis: (NEVER TESTED) device instance selector
|
|
- sensors: instructions for each section??
|
|
- sensors: when value cannot be encodd accurately, report numbers that can work
|
|
|
|
ipmi-oem
|
|
--------
|
|
dell poweredge lcd support?
|
|
|
|
ipmiseld
|
|
--------
|
|
send e-mail on alert noticed/received?
|
|
|
|
contributions
|
|
-------------
|
|
- perl extensions
|
|
- api support?
|
|
- raw support?
|
|
- python extensions
|
|
- api support?
|
|
- raw support?
|
|
- zenoss plugin
|
|
- powerman
|
|
- let ipmipower return error messages to user in some way
|
|
- intead of "command completed successfully" all the time
|
|
|
|
RELEASE TODOS - Do on every release
|
|
-----------------------------------
|
|
Email freeipmi-users && freeipmi-devel
|
|
Email info-gnu@gnu.org
|
|
Update savannah announcements
|
|
Update freshmeat.net
|
|
Update freeipmi webpage
|
|
Update opendesktop.org page
|
|
Update ohloh page
|
|
Update to softpedia??
|
|
Update fsf directory info.
|
|
Upload to ftp.gluster.com
|
|
Upload to ftp.gnu.org
|
|
|
|
Workaround for CVE
|
|
|
|
perl -pe 's/perm -777 -exec chmod a\+rwx/perm -755 -exec chmod 755 /' Makefile.in > Makefile.in.new
|
|
|
|
Workaround for CVE 2012-3386
|
|
|
|
perl -pe 's/chmod a\+w \$\(distdir\)/chmod u\+w \$\(distdir\)/' Makefile.in > Makefile.in.new
|
|
|
|
info-gnu@gnu.org template e-mail
|
|
|
|
FreeIPMI X.X.X has been released. It can be downloaded at:
|
|
|
|
http://www.gnu.org/software/freeipmi/download.html
|
|
|
|
What is IPMI?
|
|
|
|
The Intelligent Platform Management Interface (IPMI) specification
|
|
defines a set of interfaces for platform management. It is
|
|
implemented by a large number of hardware manufacturers to support
|
|
system management on motherboards. The features of IPMI that most
|
|
users will be interested in are sensor monitoring (e.g. CPU
|
|
temperatures, fan speeds), remote power control, and serial-over-LAN
|
|
(SOL).
|
|
|
|
What is FreeIPMI?
|
|
|
|
FreeIPMI provides in-band and out-of-band IPMI software based on the
|
|
IPMI v1.5/2.0 specification. FreeIPMI provides tools and libraries
|
|
for users to access and read IPMI sensor readings, system event log
|
|
(SEL) entries, serial-over-LAN (SOL), remote power control functions,
|
|
field replaceable unit (FRU) device information, and more. More
|
|
information about FreeIPMI can be found at the FreeIPMI webpage at:
|
|
|
|
http://www.gnu.org/software/freeipmi/index.html
|
|
|
|
Release X.X.X Changes
|
|
---------------------
|
|
|
|
To do this:
|
|
|
|
1. The file to be distributed (for example, foo.tar.gz).
|
|
|
|
2. Detached GPG binary signature for (1), (for example, foo.tar.gz.sig).
|
|
|
|
gpg -b foo.tar.gz
|
|
|
|
3. A clearsigned directive file, (for example, foo.tar.gz.directive.asc).
|
|
|
|
Format is:
|
|
|
|
version: 1.1
|
|
directory: freeipmi
|
|
filename: freeipmi-0.X.X.tar.gz
|
|
comment: FreeIPMI 0.X.X
|
|
|
|
gpg --clearsign foo.tar.gz.directive
|
|
|
|
4. Upload the file(s) via anonymous ftp to ftp-upload.gnu.org. If the
|
|
upload is destined for ftp.gnu.org, place the file(s) in the
|
|
/incoming/ftp directory. If the upload is destined for alpha.gnu.org,
|
|
place the file(s) in the /incoming/alpha directory.
|
|
|
|
Uploads are processed every five minutes. Uploads that are in progress
|
|
while the upload processing script is running are handled properly, so
|
|
do not worry about the timing of your upload. Uploaded files that
|
|
belong to an incomplete triplet are deleted automatically after 24
|
|
hours.
|
|
|
|
Your designated upload email addresses (see Automated Upload
|
|
Registration) are sent a message if there are any problems processing
|
|
an upload for your package. You also receive a message when your
|
|
upload has been successfully processed.
|