ADPNet Configuration Management

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 purpose of ADPNet and the LOCKSS software functional 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.

• http://www.adpn.org/wiki/Main_Page
• https://www.metaarchive.org/documentation

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. While several of the LOCKSS ancillary services are specific to e-journal preservation, the core crawling, polling and repair functionality is platform and type agnostic making LOCKSS suitable for preservation in many different domains.

• 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.

• http://documents.clockss.org/index.php/LOCKSS:_Property_Server_Operations

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 of LOCKSS staff time and attention left ADPNet concerns in direct competition with LOCKSS' commercial interests, which in part led to member dissatisfaction with the network.

The vendor-consumer configuration model employed by LOCKSS also had unintended consequences. The dependency of ADPNet members on LOCKSS support for server bring-up and configuration and software administration resulted in a reality where the ADPNet nodes were "locally outsourced" to LOCKSS. The lack of necessity in investigative and administrative control over the servers and software resulted in a lack of application specific knowledge in the network and a generalized complacency towards acquiring that knowledge.

The LOCKSS preservation network is designed to be node-independent. With distributed, potentially heterogeneous, hardware containing full copies of data and operating independently in the network, there is no node that supersedes or has a greater magnitude of precedence than the other network nodes. The same assertion cannot be made for the vendor-consumer configuration model with a centralized service passing configuration values and a dependency on LOCKSS support. The disruption of that link with LOCKSS would significantly impair ADPNet's ability to offer continuous service. Any new configuration management model should be network driven, node-independent, and the onus put squarely on ADPNet membership.

The Vendor-Consumer Administrative Model

ADPNet in the vendor-consumer administrative model : http://bpldb.bplonline.org/images/adpn/currentnetwork.png

A disruption in the network : http://bpldb.bplonline.org/images/adpn/currentnetworka.png