Microsoft Word Hardware Reconfiguration Methodology V final2

Versioning and change control

Versioning control is rather simple to carryout in so long as the proper preparations have been made (i.e. versioning control software has been installed). Many software packages are available that can perform versioning control for various UNIX and Linux-based operating systems. This software allows for the analysis and determination of which files have been changed, by whom, and when; some can even go as far as comparing changes against archived copies. This information is important in order to assess which process has made changes (i.e. update or upgrade) and the nature of the change.

However, before versioning control can be implemented, a baseline must be established. Almost all (if not all) versioning control software requires a baseline to be established. A baseline can be used to establish information about a system’s files such as size, ownership, permissions, creation date, access date, modification date, etc. It is generally possible to specify which files or sets of files should be taken into account while creating the baseline (i.e. specific configuration files, directories, binaries and libraries, etc). With this information it becomes possible to determine which files have changed.

Versioning control information is generally stored in a database file; this file tends to text-based. The baseline data file should always be considered as an important starting point for any documentation that is to be written up. In addition, through thorough versioning control and documentation it will be possible to maintain an established list of known changes that can be used to help track down software and configuration errors as a troubleshooting aid.

13. Library and kernel modifications

Most updates and upgrades will affect multiple libraries as well as the kernel. Depending on the type of system maintenance utilized, system changes may be minor or widespread. Generally, library and kernel changes tend to provide additional functionality, improved security, and feature and bug fixes. It is generally rare that required features such as API’s and system calls will be removed, although it is always a possibility. When time and resources permit, it is always best to ascertain the specifics to changes in these files. Using a versioning control system it will possible to isolate changed files from unscathed ones with relative ease (assuming the files have been baselined). While it is not often necessary to examine these files in-depth, if problems or other issues should arise as a direct result of an update or upgrade, then the changed files will have to be examined.

Changes to system calls are rather easy to determine if kernel source code is readily available, otherwise specific tools will be required to extract this information. Libraries on the other hand are generally more difficult and time-intensive to analyze, although there are tools directly designed for this purpose. It may be appropriate to analyze libraries only if as a direct result of their modification one or more applications or services malfunctions or fails. A full listing of these tools is available in Section 2.4.5.3.

However, determining when if it is worthwhile to proceed with an analysis is of great importance, as is the specific use of which tools to use, particularly if resources are scarce. Unfortunately, large library-based changes (more common with upgrades than updates) is considerably more difficult investigate thoroughly because of the far-reaching changes have been imparted. This is