Microsoft Word Hardware Reconfiguration Methodology V final2

particularly true for critical libraries such as the libc library (C library) which provides most of the operating system’s and applications’ C calls and functionality. Discovering which applications and services would have been affected by a change to a core library is a cumbersome and time consuming. Therefore, it is important to decide if and under which conditions this analysis is to be conducted.

14. Reconfiguration and migration

Once all of the tests have been conducted and it has been determined that the overall outcome thus far has been successful, then if appropriate, it is time to proceed with an operating system hardware reconfiguration or hardware migration. This step should only be conducted if new hardware has been introduced onto one or more of the test systems. For systems that have not experienced a change in hardware then this step should be altogether skipped. In certain circumstances where the kernel and/or libraries have not been changed a reconfiguration or migration can still be done in so long as the kernel supports the newer hardware or that a third- party device driver be available.

Unfortunately, due to the proliferation of many diverse incarnations of the Linux operating system there is no generic approach to performing a reconfiguration or migration. Most modern Linux distributions have their own particular method for detecting hardware changes and making the appropriate operating system changes and configuration file changes. This topic has been thoroughly examined in Report [1].

15. Documentation

The importance of documentation cannot be overstated. It is important that at least one individual, preferably the system administrator (or other similar person) document information about the various changes and tests carried out. Documentation should be written in a clear and understandable language that is objective. The documentation should include but not be limited to versioning and change control information, changes and other information relevant to library, application, and system interdependencies. It is also important to include listings of changed files and packages, configuration file modifications, as well as kernel and driver changes. Equally important are the various tests that have been performed: impact and outcome, benchmarking, behaviour testing, and system administrator and user-based tests.

The documentation should be able to convey to any technically qualified person all the required and necessary information about the changes experienced by a system including the various results obtained from benchmarking, behaviour and user-related tests, as well as performance evaluations. The information collected for documentation purposes will be vital to system reaccredidation and recertification as every system change, modification, and overall impact will already have been conducted and detailed. Therefore, if the changes made by an update or upgrade are successful and are thoroughly documented then deployment of approved changes will be more seamless. Documentation will of course be a requirement in order to gain approval for deploying a set of changes onto operational systems.

Documentation should also consist of problem resolution and other successful troubleshooting techniques that managed to resolve problems caused by an update or upgrade. These problems

are likely to occur again when the changes are deployed onto operational systems; thus, without this information the process will be both more cumbersome and time consuming.

All results, whether good or bad, should be documented. A case should then be made and available in the documentation detailing the reasons why an update or upgrade should be allowed to proceed. An objective analysis of all tests, changes, and documentation will facilitate the approval process. It is likely that many organizations will have their own procedures and policies for writing technical documentation and approval must have been given be proceeding with any deployment.

16.