Difference between revisions of "ADPNet Configuration Management"
| Line 23: | Line 23: | ||
== ADPNet Historic Configuration Model == | == ADPNet Historic Configuration Model == | ||
| − | While founding members of ADPNet had experience with LOCKSS through MetaArchive, functional experience did not extend to the depth of knowledge requisite to build and run and preservation network. As a result, LOCKSS was enlisted to provide administrative and technical support. The resulting configuration management model mimicked the commercial GLN and CLOCKSS hierarchical vendor-consumer support topology; a LOCKSS-controlled configuration server passed directives to the ADPNet preservation nodes. | + | While founding members of ADPNet had experience with LOCKSS through MetaArchive, functional experience did not extend to the depth of knowledge requisite to build and run and preservation network. As a result, LOCKSS was enlisted to provide administrative and technical support. The resulting configuration management model mimicked the commercial GLN and CLOCKSS hierarchical vendor-consumer support topology; a LOCKSS-controlled configuration server passed directives to the ADPNet preservation nodes. While ADPNet members have local administrative control over the preservation node, the shared configuration files, necessary for proper network communications, were controlled by LOCKSS. |
* http://documents.clockss.org/index.php/LOCKSS:_Property_Server_Operations | * http://documents.clockss.org/index.php/LOCKSS:_Property_Server_Operations | ||
Revision as of 12:44, 2 February 2016
ADPNet Configuration Management
Overview
This document describes the configuration management model for ADPNet. The configuration management model should be understood in the larger context of the historical purpose of ADPNet and the LOCKSS software function design.
ADPNet In Brief
ADPNet is a collaborative agreement of various Alabama institutions to implement and maintain a distributed digital preservation network. In the original implementation, ADPNet members borrowed heavily from the MetaArchive model of re-purposing LOCKSS for general preservation use.
LOCKSS In Brief
LOCKSS is a Java software appliance running well on the CentOS Linux distribution. LOCKSS nodes are typically installed and updated via RPMs on a repository maintained by LOCKSS. LOCKSS was originally designed for the preservation of e-journals and much of the functionality reflects that.
- http://www.lockss.org/
- http://documents.clockss.org/index.php/LOCKSS:_Basic_Concepts
- https://github.com/lockss/lockss-daemon
ADPNet Historic Configuration Model
While founding members of ADPNet had experience with LOCKSS through MetaArchive, functional experience did not extend to the depth of knowledge requisite to build and run and preservation network. As a result, LOCKSS was enlisted to provide administrative and technical support. The resulting configuration management model mimicked the commercial GLN and CLOCKSS hierarchical vendor-consumer support topology; a LOCKSS-controlled configuration server passed directives to the ADPNet preservation nodes. While ADPNet members have local administrative control over the preservation node, the shared configuration files, necessary for proper network communications, were controlled by LOCKSS.
The Impetus for Change
The established vendor-consumer configuration model and the discrete nature of ADPNet nodes resulted in a dependency on LOCKSS for all network-wide tasks. Finite availability left ADPNet concerns in direct competition with LOCKSS' commercial interests, which in part led to member dissatisfaction with the network.