From e375cd08b6adf2c2f0d2538c6928e4a140781925 Mon Sep 17 00:00:00 2001 From: Aaron Klingaman Date: Thu, 10 Mar 2005 19:58:59 +0000 Subject: [PATCH] tech docs for boot manager --- documentation/boot-manager-tech-doc.xml | 260 ++++++++++++++++++++++++ 1 file changed, 260 insertions(+) create mode 100644 documentation/boot-manager-tech-doc.xml diff --git a/documentation/boot-manager-tech-doc.xml b/documentation/boot-manager-tech-doc.xml new file mode 100644 index 0000000..554ce8f --- /dev/null +++ b/documentation/boot-manager-tech-doc.xml @@ -0,0 +1,260 @@ + + +
+ + Boot Manager Technical Documentation + + + Aaron + + Klingaman + + alk@cs.princeton.edu + + + + Princeton University + + + + + 1.0 + + March 10, 2005 + + AK + + + Initial draft. + + + + + +
+ Components + + The entire Boot Manager system consists of several components that + are designed to work together to provide the functionality outline in the + Boot Manager PlanetLab Design Note. These consist of: + + + + A set of API calls available at PlanetLab Central + + + + A package to be run in the boot cd environment on nodes + + + + A set of API calls and an appropriate user interface allowing + administrators to create node configuration files + + +
+ +
+ API Calls + +
+ Authentication + + The Boot PLC API calls handle authentication in a different manner + that other API calls, which typically require a username and password, + and are called by users of the system, not nodes. + + The authentication structure consists of two named fields: + + + + method + + The authentication method, only hmac is currently + supported + + + + node_id + + The node id, contained on the configuration file. + + + + value + + An hmac hash for the call, made from the parameters of the + call the key contained on the configuration file. + + +
+ +
+ PLC API Calls + + For full documentation of these functions can be found in the + PlanetLab API documentation. + + + + BootUpdateNode( authentication, update_values ) + + Update a node record, currenly only allowing the boot state + to change. + + + + BootCheckAuthentication( authentication ) + + Simply check to see if the node is recognized by the system + and is authorized + + + + BootGetNodeDetails( authentication ) + + Return details about a node, including its state, what + networks the PLC database has configured for the node. + + + + BootNotifyOwners( authentication, message, include_pi, + include_tech, include_support ) + + Notify someone about an event that happened on the machine, + and optionally include the site PIs, technical contacts, and + PlanetLab Support + + +
+
+ +
+ Core Package + + The Boot Manager core package, which is run on the nodes and + contacts the Boot API as necessary, is responsible for the follow major + functional units: + + Installing nodes with alpina, the PlanetLab installer + + + + Putting a node into a debug state + + + + Reconfiguring an already installed node to reflect new + hardware, or changed network settings + + + + Booting an already installed node + + + + Below is a high level flow chart of the boot manager, from the time + it is executed to when it exits. + +
+ Boot Manager Flow Chart + + + + + + +
+
+ +
+ User Interface Items + + Nodes are now added to the system by administrators of the site, and + technical contacts. +
+ +
+ Node Management + +
+ Adding Nodes + + New nodes are added to the system explicitly by either a PI or a + tech contact, either directly through the API calls, or by using the + appropriate interfaces on the website. As nodes are added, only their + hostname and ip address are required to be entered. When the node is + brought online, the records at PLC will be updated with the remaining + information. + + After a node is added, the user has the option of creating a + configuration file for that node. This is done automatically, and the + user is prompted to download and save the file. This file contains only + the primary network interface information (necessary to contact PLC), + and the per-node key. + + The default boot state of a new node is 'new', which requires the + user to confirm the installation at the node, by typing yes on the + console. If this is not desired, as is the case with nodes in a + colocation site, or for a large number of nodes being setup at the same + time, the administrator can change the node state, after the entry is in + the PLC records, from 'new' to 'reinstall'. This will bypass the + confirmation screen, and proceed directly to reinstall the machine (even + if it already had a node installation on it). +
+ +
+ Updating Node Network Settings + + If the primary node network address must be updated, if the node + is moved to a new network for example, then two steps must be performed + to successfully complete the move: + + + + The node network will need to be updated at PLC, either + through the API directly or via the website. + + + + Either the floppy file regenerated and put into the machine, + or, update the existing floppy to match the new settings. + + If the node ip address on the floppy does not mach the + record at PLC, then the node will not boot until they do match. The + intention here is to prevent a malicious user from taking the floppy + disk, altering the network settings, and trying to bring up a new + machine with the new settings. + + On the other hand, if a non-primary network address needs to be + updated, then simply updating the records at PLC will suffice. The boot + manager, at next restart, will reconfigure the machine to match the PLC + records. +
+ +
+ Removing Nodes + + Nodes are removed from the system by: + + + + Deleting the record of the node at PLC + + + + Shutting down the machine. + + Once this is done, even if the machine attempts to come + back online, it cannot be authorized with PLC and will not boot. +
+
+ +
+ + + +
+
\ No newline at end of file -- 2.43.0