| | 1 | [[PageOutline]] |
| | 2 | |
| | 3 | = Detailed test plan for IG-MON-1: Control Network Software and VLAN Inspection Test = |
| | 4 | |
| | 5 | ''This page is GPO's working page for performing IG-MON-1. It is public for informational purposes, but it is not an official status report. See [wiki:GENIRacksHome/InstageniRacks/AcceptanceTestStatus] for the current status of InstaGENI acceptance tests.'' |
| | 6 | |
| | 7 | ''Last substantive edit of this page: 2012-05-08'' |
| | 8 | |
| | 9 | == Page format == |
| | 10 | |
| | 11 | * The status chart summarizes the state of this test |
| | 12 | * The high-level description from test plan contains text copied exactly from the public test plan and acceptance criteria pages. |
| | 13 | * The steps contain things i will actually do/verify: |
| | 14 | * Steps may be composed of related substeps where i find this useful for clarity |
| | 15 | * Each step is either a preparatory step (identified by "(prep)") or a verification step (the default): |
| | 16 | * Preparatory steps are just things we have to do. They're not tests of the rack, but are prerequisites for subsequent verification steps |
| | 17 | * Verification steps are steps in which we will actually look at rack output and make sure it is as expected. They contain a '''Using:''' block, which lists the steps to run the verification, and an '''Expect:''' block which lists what outcome is expected for the test to pass. |
| | 18 | |
| | 19 | == Status of test == |
| | 20 | |
| | 21 | Meaning of states: |
| | 22 | * [[Color(green,Pass)]]: Step is completed and passed (for a verification step), or is completed (for a prep step) |
| | 23 | * [[Color(red,Fail)]]: Step is completed and failed, and is not being revisited |
| | 24 | * in progress: We are currently testing or iterating on this step |
| | 25 | * [[Color(orange,Blocked)]]: Step is blocked by some other step or activity |
| | 26 | |
| | 27 | || '''Step''' || '''State''' || '''Date completed''' || '''Tickets''' || '''Comments''' || |
| | 28 | || 1 || [[Color(orange,Blocked)]] || || || blocked on sudo access to boss || |
| | 29 | || 2 || [[Color(orange,Blocked)]] || || || blocked on sudo access to ops || |
| | 30 | || 3 || [[Color(orange,Blocked)]] || || || blocked on sudo access to foam VM || |
| | 31 | || 4 || [[Color(orange,Blocked)]] || || || blocked on sudo access to the control host || |
| | 32 | || 5 || [[Color(orange,Blocked)]] || || || blocked on access to an allocated OpenVZ host (e.g. via boss) || |
| | 33 | || 6 || [[Color(orange,Blocked)]] || || || blocked on access to the control switch || |
| | 34 | |
| | 35 | == High-level description from test plan == |
| | 36 | |
| | 37 | This test inspects the state of the rack control network, infrastructure nodes, and system software. |
| | 38 | |
| | 39 | ==== Procedure ==== |
| | 40 | |
| | 41 | * A site administrator enumerates processes on each of the server host, the boss VM, the ops VM, the FOAM VM, and an experimental node configured for OpenVZ, which listen for network connections from other nodes, identifies what version of what software package is in use for each, and verifies that we know the source of each piece of software and could get access to its source code. |
| | 42 | * A site administrator reviews the configuration of the rack control plane switch and verifies that each experimental node's control and iLO interfaces are on the expected VLANs. |
| | 43 | * A site administrator reviews the MAC address table on the control plane switch, and verifies that all entries are identifiable and expected. |
| | 44 | |
| | 45 | === Criteria to verify as part of this test === |
| | 46 | |
| | 47 | * VI.09. A public document explains how to identify the software versions and system file configurations running on the rack, and how to get information about recent changes to the rack software and configuration. (F.5) |
| | 48 | * VI.11. A public document describes the GENI software running on the rack, and explains how to get access to the source code of each piece of GENI software. (F.6) |
| | 49 | * VII.03. Site administrators can understand the expected control and dataplane network behavior of their rack. (F.2) |
| | 50 | * VII.04. Site administrators can view and investigate current system and network activity on their rack. (F.2) |
| | 51 | * VII.06. A site administrator can verify the control software and configurations on the rack at some point in time. (F.5) |
| | 52 | * VII.08. A site administrator can get access to source code for the version of each piece of GENI code installed on their site rack at some point in time. (F.6) |
| | 53 | * VII.09. A site administrator can determine the MAC addresses of all physical host interfaces, all network device interfaces, all active experimental VMs, and all recently-terminated experimental VMs. (C.3.f) |
| | 54 | * VII.10. A site administrator can locate current and recent CPU and memory utilization for each rack network device, and can find recent changes or errors in a log. (D.6.a) |
| | 55 | * VII.12. For each infrastructure and experimental host, a site administrator can locate current and recent uptime, CPU, disk, and memory utilization, interface traffic counters, process counts, and active user counts. (D.6.b) |
| | 56 | * VII.13. A site administrator can locate recent syslogs for all infrastructure and experimental hosts. (D.6.b) |
| | 57 | |
| | 58 | == Step 1: identify network-listening software on the boss node == |
| | 59 | |
| | 60 | '''Using:''' |
| | 61 | * Using netstat, enumerate processes on boss which listen for network connections from outside the node |
| | 62 | * For each process found: |
| | 63 | * Use the command-line to determine what executable file is running |
| | 64 | * Use pkg_info to determine whether the executable file is part of a FreeBSD package/port |
| | 65 | * Otherwise, use documentation or iterate with the InstaGENI team to determine the origin of the software |
| | 66 | * For each FreeBSD package found, identify a location from which the port source can be obtained |
| | 67 | * For each non-FreeBSD software source found, identify a location from which the source code for that version can be obtained. |
| | 68 | |
| | 69 | '''Verify:''' |
| | 70 | * The source of each network-listening file can be identified |
| | 71 | * FreeBSD ports can be identified for each FreeBSD-sourced package |
| | 72 | * The source code and identifiable version (e.g. a git tag) can be found for each non-FreeBSD software source |
| | 73 | |
| | 74 | == Step 2: identify network-listening software on the ops node == |
| | 75 | |
| | 76 | '''Using:''' |
| | 77 | * Using netstat, enumerate processes on ops which listen for network connections from outside the node |
| | 78 | * For each process found: |
| | 79 | * Use the command-line to determine what executable file is running |
| | 80 | * Use pkg_info to determine whether the executable file is part of a FreeBSD package/port |
| | 81 | * Otherwise, use documentation or iterate with the InstaGENI team to determine the origin of the software |
| | 82 | * For each FreeBSD package found, identify a location from which the port source can be obtained |
| | 83 | * For each non-FreeBSD software source found, identify a location from which the source code for that version can be obtained. |
| | 84 | |
| | 85 | '''Verify:''' |
| | 86 | * The source of each network-listening file can be identified |
| | 87 | * FreeBSD ports can be identified for each FreeBSD-sourced package |
| | 88 | * The source code and identifiable version (e.g. a git tag) can be found for each non-FreeBSD software source |
| | 89 | |
| | 90 | == Step 3: identify network-listening software on the foam node == |
| | 91 | |
| | 92 | '''Using:''' |
| | 93 | * Using netstat, enumerate processes on foam which listen for network connections from outside the node |
| | 94 | * For each process found: |
| | 95 | * Use the command-line to determine what executable file is running |
| | 96 | * Use dpkg commands to determine whether the executable file is part of a Debian package |
| | 97 | * Otherwise, use documentation or iterate with the InstaGENI team to determine the origin of the software |
| | 98 | * For each Debian package found, identify a location from which the source package can be obtained |
| | 99 | * For each non-Debian package found, identify a location from which the source code for that version can be obtained. |
| | 100 | |
| | 101 | '''Verify:''' |
| | 102 | * The source of each network-listening file can be identified |
| | 103 | * Source code or a source package can be identified for each Debian-sourced package |
| | 104 | * The source code and identifiable version (e.g. a git tag) can be found for each non-Debian software source |
| | 105 | |
| | 106 | == Step 4: identify network-listening software on the control host == |
| | 107 | |
| | 108 | '''Using:''' |
| | 109 | * Using netstat, enumerate processes on the control host which listen for network connections from outside the node |
| | 110 | * For each process found: |
| | 111 | * Use the command-line to determine what executable file is running |
| | 112 | * Use dpkg commands to determine whether the executable file is part of a Debian package |
| | 113 | * Otherwise, use documentation or iterate with the InstaGENI team to determine the origin of the software |
| | 114 | * For each Debian package found, identify a location from which the source package can be obtained |
| | 115 | * For each non-Debian package found, identify a location from which the source code for that version can be obtained. |
| | 116 | |
| | 117 | '''Verify:''' |
| | 118 | * The source of each network-listening file can be identified |
| | 119 | * Source code or a source package can be identified for each Debian-sourced package |
| | 120 | * The source code and identifiable version (e.g. a git tag) can be found for each non-Debian software source |
| | 121 | |
| | 122 | == Step 5: identify network-listening software on an OpenVZ experimental node == |
| | 123 | |
| | 124 | '''Using:''' |
| | 125 | * Using netstat, enumerate processes on an allocated node running the OpenVZ image which listen for network connections from outside the node |
| | 126 | * For each process found: |
| | 127 | * Use the command-line or `/proc` to determine what executable file is running |
| | 128 | * Use RPM tools to determine whether the executable file is part of an RPM |
| | 129 | * Otherwise, use documentation or iterate with the InstaGENI team to determine the origin of the software |
| | 130 | * For each RPM found, identify a location from which a source RPM for that package can be obtained |
| | 131 | * For each non-RPM software source found, identify a location from which the source code for that version can be obtained. |
| | 132 | |
| | 133 | '''Verify:''' |
| | 134 | * The source of each network-listening file can be identified |
| | 135 | * RPM source packages can be found for each RPM-sourced package |
| | 136 | * The source code and identifiable version (e.g. a git tag) can be found for each non-RPM software source |
| | 137 | |
| | 138 | == Step 6: verify VLANs on the rack management switch == |
| | 139 | |
| | 140 | '''Using:''' |
| | 141 | * Establish a privileged login to the control plane switch |
| | 142 | * Obtain the list of all VLAN mappings for all interfaces |
| | 143 | * Determine which interfaces connect to experimental nodes |
| | 144 | * Obtain a list of the full MAC address table of the switch |
| | 145 | * Use interface listings on hosts and devices to determine the identities of all MAC addresses |
| | 146 | |
| | 147 | '''Verify:''' |
| | 148 | * All experimental node control interfaces are on an expected VLAN |
| | 149 | * It is possible to identify and classify every MAC address visible on the control switch |
| | 150 | |
