eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
By the end of the year, it managers will start to see the first wave of hardware devices that can be uniformly managed before the operating system slogs through the boot-up process, thanks to the new Alert Standard Forum specification from the Distributed Management Task Force.
This is good news: Because the ASF specification covers any IP- capable device—not just PCs and servers—while also establishing a uniform standard for alerting, monitoring and controlling remote systems, most sites should be able to whittle down the number of management consoles currently needed to just one or two.
Released last month as a preliminary standard, the ASF specification (details are available at www.eweek.com/links) could become an official DMTF standard as early as this summer. At that time, eWeek Labs believes administrators should place ASF compliance at the top of their list of requirements for any new server, router, appliance or other infrastructure device.
The latest iteration of the standard proposal defines the message formats and transmission protocols for alerting and corrective action for various hardware products, including add-in cards, SMBIOS (SMB Internetwork Operating System, a local interface to reach system management information) sensors, system servers, operating systems and management platforms.
If it becomes widely adopted, ASF should promote the interoperable management of these devices and software products.
ASF uses bit-based transmission protocols, including SNMP and User Datagram Protocol, all tried and true in the management arena. This should make ASF fit comfortably amid the network and system management products that IT managers are already using.
In addition, because ASF was developed by the DMTF, it interoperates with Common Information Model; this means that basic ASF information could also be abstracted to operating-system-present Extensible Markup Language formats, which would allow managers detailed access to remote systems.
And now the bad news: With this power and convenience come new avenues for attacks.
Based on our reading of the specification, ASF is built with an overly large reliance on trust that operators and machines are who and what they say they are. This is especially true when it comes to issuing maintenance commands, which can force devices to reboot or shut down altogether. Managers should keep these weaknesses in mind when rolling out systems that contain active ASF elements.
PET Sounds
ASF defines alert messages that are sent from the client system to the management console, remote maintenance requests that are sent to the client, data descriptions of client-specific capabilities, and an interface to software that is used to configure or control the client when the operating system is present.
When an ASF-capable device, such as an Ethernet card or sensor, is added to a system, the specification currently requires that the system perform at least one normal boot. This reboot allows the device configuration software to run and store system information in nonvolatile memory. Future versions will likely overcome this limitation by permitting configuration data to be stored without cycling the system.
ASF alerts are sent as a PET (Platform Event Trap) that is presumed to be sent on an IP network. IPX is supported as an option, as are other network transport protocols. However, ASF is also IP-centric and requires that the device sending the alert always support the IP address scheme.
The DMTF appears to have worked out a way for ASF to provide enough specific management information without falling into the trap of being a Trojan horse for one or another vendor. A healthy cross-section of interested parties—including 3Com Corp., Cisco Systems Inc. and Tivoli Systems Inc.—seems to be playing nicely together to ensure that the specification will be widely used.