OVAL Board Minutes
Linux Notes - 20 May 2003
The following is a summary of some of the discussion surrounding Linux support (specifically Red Hat and Debian distributions) which happened during the OVAL Board Teleconference on May 20th, 2003 (2003-05-20).
Comparing Package Versions
Issues regarding version comparisons for various packages (RPM, dpkg) were the main topic of the Linux discussion. Matthew Wojcik shared some concerns about apparent shortcomings in the accuracy of the PL/SQL code Mark Cox graciously shared with the OVAL list. Cox made clear that the algorithm used by the PL/SQL is the same as in the C code for rpm itself; any package with a version which the PL/SQL can't handle, the rpm command line utility would not be able to install (without a force). Javier Fernandez-Sanguino shared his experience that Debian has similarly well-defined restrictions on what package version styles dpkg can handle.
Wojcik thinks this makes a clear and reasonable cut-off for OVAL: what the vendor doesn't support, OVAL cannot necessarily support (at least for a first cut). People seemed to agree that this is a problem with the real world and not just with OVAL. Clearly there are still challenges for how OVAL will deal with package versions.
Jay Beale suggested that librpm functions could be used for version comparisons for specific packages of interest, and the OVAL schema could have a place to hold those results. Cox mentioned that that interface may be made available directly to the user via the rpm command-line utility in the future, as there have been requests for that functionality. [It's unclear to me what the analogue is under Debian, but presumably there is one. --Wojcik]
Cox mentioned the RPM database present on Red Hat systems which holds information on installed packages, and said he has been uncomfortable with the idea of OVAL inventing a new name-space to hold essentially the same information. Wojcik hadn't fully realised the existence of the database, and suggested the OVAL Red Hat schema should include the RPM database structure rather than the output of the rpm command line utility. This is directly in line with OVAL's stated goal of keeping schema design as close as possible to the way vendors actually represent configuration information. (There may of course be a need for additional information, such as the results of version comparisons difficult to accomplish in SQL, as discussed above.)
After this discussion, Wojcik feels more confident about finding a satisfactory solution to this issue for OVAL. There are a number of workable approaches apparent:
- Using some kind of stored SQL procedure (though likely this would not be portable even between DBMS systems)
- Developing a purely declarative approach based on the PL/SQL code (almost certainly possible, but could be very ugly SQL)
- Simply making available the results of a version comparison API call to librpm or similar (has the drawback of hiding some of the logic, but the advantage of exactly reflecting the vendor's reality)
This issue will be pursued on the OVAL Community Forum, as will the other Linux issues.
Other Linux Issues
There was some discussion regarding some of the other Linux issues that have come up on the OVAL Community Forum. It was broadly agreed to continue addressing them in that arena, with the possibility of additional teleconferences with interested parties. Topics mentioned included xinetd/inetd/running services questions, and checking for anomalous machine state such as patches which may not have taken effect because the machine wasn't rebooted.
Page Last Updated: February 07, 2008
