*** - priority for future major release
XXX - priority for future minor release
ooo - priority code cleanup that should be done
branches to merge
-----------------
dellr720
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 (XXX)
- treat more like network busy than error?
- option for alternate behavior?
- update text documents to texinfo (***)
- OEM extensions generalized
- generalize "+" syntax in ipmipower to all FreeIPMI tools?
- or use extra option?
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 (***)
- dcmi (***)
- 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.
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
---------------
- checksum/something to ensure no disk corruption
libfreeipmi-sel
---------------
- split vendor files into motherboard files? Is getting big.
- 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
- support 'discretereading' workaround (XXX)
- need a mobo to play with to test, lots of a breakage possibilities
- 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 (XXX)
- 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 (XXX)
- 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 (XXX)
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
config tools
------------
- collapse into one allmighty tool (***)
- user must pick section
- bmc, pef, sensor, chassis, all
- makes more extensible in the future
- oem, dcmi, intel node manager, system info, firmware firewall, etc.
- --category option (bmc, sensors, chassis, pef, oem, dcmi, intel)
- 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
bmc-config
----------
- support ipv4 mapped ipv6 addresses?
- until in spec, no point, maybe deal in ipmi-oem?
ipmi-chassis-config
-------------------
* conf.5 manpage
(NEVER TESTED) panel button config - need hardware w/ this
(NEVER TESTED) device instance selector
ipmi-pef-config
-----------
* conf.5 manpage
ipmi-sensors-config
-------------------
* conf.5 manpage
* instructions for each section??
ipmi-oem
--------
dell poweredge lcd support?
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.
