11. Appendix: Instructions for Administrators of LOCKSS Networks

This guide is primarily aimed at operators of individual LOCKSS nodes; this appendix is aimed at administrators of LOCKSS networks, describing actions taken through the transitional period of migration of the network's nodes from LOCKSS 1.x to 2.x:

• There are network-wide tasks to perform Before the First Migration and After the Last Migration.

• Additionally, there are node-specific tasks to perform Before Each Migration and After Each Migration.

11.1. Before the First Migration

LOCKSS 2.x poll compatibility mode before migration

Before any LOCKSS 1.x node in your network migrates to LOCKSS 2.x, you will need to set org.lockss.poll.2.0Compatible to true in LOCKSS 1.79.1 or later in the network configuration file [2]. For example in a typical XML network configuration file where the prefix org.lockss is enclosed in a file-wide <property name="org.lockss"> block, this would look like this:

<if daemonVersionMin="1.79.1">
  <then>
    <property name="poll.2.0Compatible" value="true" />
  </then>
</if>

11.2. Before Each Migration

1. Access control before migration

   new-host migration only When a node in the network is slated to begin a New-Host Migration, add the new IP address of the LOCKSS 2.x host to your network configuration server [1] firewall rules and Web server access control, so it can access resources like the network configuration file [2] and plugin registries. See the New-Host Migration portion of Chapter 3 (Preparing the LOCKSS 2.x Host).

2. Initial peer list before migration

   When a node in the network is slated to begin migration (in any Migration Scenario), do not add an LCAP identity to the initial peer list (org.lockss.id.initialV3PeerList); simply leave the existing LCAP identity of the migrating node alone during its migration.

11.3. After Each Migration

1. Access control after migration

   new-host migration only When a node in the network finishes a New-Host Migration, you need to adjust your network configuration server [1] firewall rules and Web server access control accordingly:

   • If the LOCKSS 2.x host adopts the IP address previously associated with the corresponding LOCKSS 1.x host, which is recommended, you can remove the new IP address of the LOCKSS 2.x host which had been added in Access control before migration in Section 11.2 (Before Each Migration).

   • If adopting the IP address previously associated with the corresponding LOCKSS 1.x host is not possible, instead you will need to remove the old IP address of the LOCKSS 1.x host which had been present prior to the migration.

   See the New-Host Migration portion of Chapter 8 (Reconfiguring LOCKSS 2.x for Normal Operation) for context.

2. Change of Hostname

   new-host migration only If the node finishing a New-Host Migration does not retain the hostname previously used by its LOCKSS 1.x instance, you may need to update the hostname in monitoring tools you utilize in the network. See the New-Host Migration portion of Chapter 8 (Reconfiguring LOCKSS 2.x for Normal Operation) for context.

3. Change of LCAP identity

   If the node finishing a migration does not retain both the IP address and LCAP port previously used by its LOCKSS 1.x instance, its LCAP (LOCKSS audit and repair) identity in the network has changed and action is needed. See Chapter 8 (Reconfiguring LOCKSS 2.x for Normal Operation) for context. Follow these steps:

   1. Initial peer list after migration

      You will need to update from the old LCAP identity to the new LCAP identity in the initial peer list (org.lockss.id.initialV3PeerList) in the network configuration file [2].

   2. Poll transfer map

      You will need to add the new LCAP identity to the poll transfer map (org.lockss.poll.v3.reputationTransferMap) in the network configuration file [2]:

      • If the node already has a chain in the poll transfer map, append the new LCAP identity to the end of the node's chain (after a comma), which currently ends with the LCAP identity that just changed as a result of the migration, symbolically:

        <value>list_of_prior_identities,most_recent_identity,brand_new_identity</value>

      • If this is the node's first change of LCAP identity, add a chain for it, consisting of the old identity, a comma, and the new identity, symbolically:

        <value>old_identity,new_identity</value>

        This might be the first change of LCAP identity in the network, in which case you will be adding the poll transfer map to the network configuration file [2] for the poll transfer map for the first time. For example in a typical XML network configuration file where the prefix org.lockss is enclosed in a file-wide <property name="org.lockss"> block, this would look like this:

        <property name="poll.v3.reputationTransferMap">
          <list>
            <value>...</value>
          </list>
        </property>
        

11.4. After the Last Migration

LOCKSS 2.x poll compatibility mode after migration

After all nodes in your network are running LOCKSS 2.x, unset the org.lockss.poll.2.0Compatible parameter in the network configuration file [2].

---

Footnotes

[1]

The network configuration server is also often referred to as the props server.

[2]

The network configuration file is also often referred to as the props file.