EaaS support scripts
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.
README.md Create README.md Oct 16, 2015
setup-bwfla-repo.sh add bwfla deb repo setup May 18, 2016


EaaS support scripts

Before running any of the bwFLA client scripts a corresponding docker container has to be downloaded. Assuming that client has installed "docker" application (tested against v1.8.1) only image pulling is required, e.g.:

docker pull eaas/bwfla:demo-august-15

After the operation finishes, client is able to run desired module by executing corresponding script. It is possible to run multiple containers (max. 1 per module) with the same public ip. However, if IP addresses are identical for one or more containers on the same node, then client needs to specify different ports for each such container. E.g.

./run-flavor-emucomp.sh --docker eaas/bwfla:demo-august-15 --public-ip-port
./run-flavor-imagearchive.sh --docker eaas/bwfla:demo-august-15 --public-ip-port \
    --archive-dir /mnt/data/image-archive 

When docker boots-up, the internally running application server will be accessible for the outside world via public IP and Port (in the above example '' and '' correspondingly) Docker takes care of temporary setting of 'iptables' rules such that client doesn't need to perform mapping of 'host <---> guest' ports (i.e. NAT). Make sure that your Firewall doesn't interfere with the rules set-up by Docker application.

NOTE: In the following, explanation of the two mandatory parameters (--docker & --public-ip-port) will be omitted.



./run-flavor-emucomp.sh --docker eaas/bwfla:demo-august-15 --public-ip-port

This script starts 'emucomp' module, which is responsible for running individual emulators on dedicated compute nodes (possibly in a cluster/cloud environment). As of now emulators supported in the docker are the following: Qemu, SheepShaver, Basilisk, DosBox, Hatari.

EaaS Gateway


./run-flavor-eaas.sh --public-ip-port --docker eaas/bwfla:demo-august-15 \
    --emucomp,4 --emucomp,8

This module serves as a scheduler/proxy node for individual 'emucomp' modules deployed in the cloud/cluster. When starting the module at least one --emucomp <VALUE> has to be specified on the command line. Repeat the argument if multiple 'emucomp' modules have to be connected to this 'eaas' module. Value of the arguments is composed of the IP:PORT of the 'emucomp' to be connected and the number of sessions it should supports (usually set to the node's CPU-count) coming after comma.



./run-flavor-imagearchive.sh --docker eaas/bwfla:demo-august-15 --public-ip-port \
     --archive-dir /mnt/data/image-archive

This script run the 'imagearchive' module. It requires the location of the image archive directory as a parameter. The 'nbd-export' directory should not contain any symbolic links that point to locations outside of the image-archive directory (i.e. only relative paths). NOTE: This is due to the fact that the image-archive is mounted inside the docker container, which in turn has no access to the host's file-system.



./run-flavor-workflows.sh --docker eaas/bwfla:demo-august-15 --public-ip-port 
                               [--object-files test/object-files --base-uri http://object.store/objects/]
                               [--object-metadata test/object-metadata]
                               [--swarchive-incoming test/swarchive/incoming]
                               [--swarchive-storage test/swarchive/storage]

This script starts the 'Workflows' module, which represents a reference implementation of bwFLA usage by a client. It contains sample preservation workflows which include archival "ingest/access" of digital objects, full disk images, any accompanying software/libraries.

--image-archive should point to a location of an image-archive, which contains base image of emulated systems, their derivatives, etc.

--eaas-gateway should point to a location of an EAAS module, which will serve as a main 'facade' for accepting and performing emulation tasks by using one or more 'emucomp' modules on dedicated compute-nodes.

--object-files should point to a directory containing user-objects that will appear in the 'ingest' workflow. The directory should contain objects in the form "OBJECT_NAME/OBJECT_NAME.iso". E.g. 'test/object-files/OBJECT1/OBJECT1.iso'.

--base-uri must be specified iff. --object-files was specified previously. This argument defines the URL-prefix for the location of the objects via which the object can be download through HTTP protocol ('emucomp' module needs to be able to download the object to inject it into the environment).

--object-metadata argument is specified the the metadata for ingested objects will be kept permanently on the host inside the corresponding directory. This metadata results from the ingest workflow and describes the object's rendering environment, which can be tested via 'access' workflow.

--swarchive-incoming is specified, then it must point to the location of the directory which contains software subject to 'Software Archive' workflow.

--swarchive-storage is specified, then it must point to a directory which will keep the content and the metadata of the software ingested by the 'Software Archive' workflow.