Dirk von Suchodoletz

About Dirk von Suchodoletz

Posts by :

October 10 2013

Software Museums (Archives)

Dirk von Suchodoletz Characterisation, Emulation, Migration 2

During and around this year's iPRES a couple of discussions sprung up around the topic of proper software archiving and it was part of the DP challenges workshop discussions. With services emerging around emulation as e.g. developed in the bwFLA project (see e.g. the blog post on EaaS demo or Digital Art curation) proper measures need to be taken to make them sustainable from the software side. There are hardware museums around; similar might be desirable too.

Research data, business processes, digital art and generic digital artefacts can often not be viewed or handled simply by themselves, instead they require a specific software and hardware environment to be accessed or executed properly. Software is a necessary mediator for humans to deal with and understand digital objects of any kind. In particular, artefacts based on any one of the many complex and domain specific formats are often best handled by the matching them with the application they were created with. Software can be seen as the ground truth for any file format. It is the software that creates files that truly defines how those files are formatted.

To make old software environments available on an automatable and scalable basis (for example, via Emulation-as-a-Service) proper enterprise-scale software archiving is required. At first look the task appears to be huge because of the large amount of software that has been produced in the past. Nevertheless, much of the software that has been created is standard software, and more or less used all over the world; and there are a lot of low hanging fruit to pick off that would be highly beneficial to preserve and make avaialble. If components of software can be uniquely described, deduplication should also reduce the overall workload significantly. For at least a significant proportion of the software to be covered, licensing might complicate the whole issue a fair amount as different software licensing variants were deployed in different domains and different parts of the world, and current copyright and patent law differs in different jurisdictions in how it applies to older software.

Types of Software

Institutions and users have to decide which software needs to preserved, how and by whom. The answers to these questions will depend on the intended use cases. In simpler cases all that may be needed to render preserved artefacts in emulated original environments could be a few standard office or business environments with standard software. Complex use cases may require very special non-standard, custom-made software components from non-standard sources, like use cases involving development systems or use cases involving the preservation of complex business processes.

Software components required to reproduce original environments for certain (complex) digital objects can be classified in several ways. Firstly, there are the standard software packages like operating systems and off-the-shelf applications sold in (significant) numbers to customers. And secondly there can be different releases and various localized versions (the user interaction part of a software application is often translated to different languages such as in Microsoft Windows or Adobe products) but otherwise the copies are often exactly the same. In general it does not really matter if it is a French, English, or German Word Perfect version being used to interact with a document. But for the user dealing with it or an automated process like the process used for migration-through-emulation the different labeling of menu entries and error messages matters.

The concept of versions is somewhat different for Open Source or Shareware-like software. Often there are many more "releases" available than with commercial software as the software usually gets updated regularly and does not necessarily have a distinct release cycle. Also, different to commercial software, the open source packages feature full localization, as they did not need to distinguish different markets.

In many domains custom made software and user programming plays a significant role. This can be scripts or applications written by scientists to run their analysis on gathered data, run specific computations, or extend existing standard software packages. Or it could be software tools written for governmental offices or companies to produce certain forms or implement and configure certain business processes. Such software needs to be taken care of and stored alongside the preserved base-files of an object in order to ensure they can be accessed and interacted with in the future. The same applies for complex setups of standard components with lots of very specific configurations.

If such standard software is required, it would make sense to be able to assign each instance a unique identifier. This would help to de-duplicate efforts to store copies. Even if a memory institution or commercial service maintains its own copy, it does not necessarily need to replicate the actual bits if other copies are already available somewhere. It may simply be able to manage it’s own licenses and use the bits/software copies provided by a central service. Additionally, it would simplify efforts to reproduce environments in an efficient way.

What Should be Identified?

Some ideas about how to identify and describe software have already been discussed for the upcoming PREMIS 3.0 standard, in particular for the section regarding environments. Suitable persistent identifiers would definitely be helpful for tagging software. Something like ISBNs or the ISSNs that describe books and other media (or DOIs that are becoming ubiquitous for digital artefacts). These tags would be useful for tool registries like TOTEM as well or coudl match to PREMIS PUIDs. There could be three layers of IDing that could become relevant:

On the most abstract layer a software instance is described as a complete package, e.g. Windows 3.11 US Edition, Adobe Page Maker Version X or Command & Conquer II containing all the relevant installation media, license keys etc. The ID of such a package could be the official product code or derived from it. However when using such an approach it might be difficult to distinguish between hidden updates, for example, during the software archiving experiment at Archives New Zealand we acquired and identified two different package sets of Word Perfect 6.0. So a more nuanced approach may be required.
At the layer of the different media (relevant only if it is not just one downloaded installation package) each floppy disk or each optical medium (or USB media) could be distinguished. E.g. Windows 3.11 as well as applications like Word Perfect came with specific disks for just the printer drivers, and the CD (1 or 2) in the Command & Conquer game differentiated which adversary in the game you were assigned to.
At the individual file layer executables, libraries, helper files like font-sets etc. could be distinguished. The number of items in this set is the largest. An approach centered on running a collection of digital signatures of known, traceable software applications is followed e.g. by the NSRL (National Software Reference Library) and may be the most appropriate option for these types of applications.

Usually it is not trivial to map the installed files in an environment to files on the installation medium, as the files typically get packed (compressed in ‘archive’ files) on the medium and a some files get created from scratch during the installation procedure.

Depending on the actual goal, the focus of the IDs will be different. To actually derive what kind of application or operating system is installed on a machine, file level identifiers will be needed. To just reproduce a particular original environment (for e.g. emulation) package level identifiers are more relevant. In some cases it may be useful to address a single carrier, e.g. to automate installation processes of standard environments consisting of an operating system and a couple of applications.

For the description of software and environments it might be useful to investigate what can be learned from commercial software installation handling and lifecycle management. Large institutions and companies have well-defined workflows to create software environments for certain purposes and their approaches may be directly applicable to the long term preservation use case(s).

Software Museum or Archive

What should be archived, who are the stakeholders and users and how can the archive be supported?

A model for nearly full-archiving of a domain is the Computer Games Museum in Berlin which receives every piece of computer game which requires an USK, which is the German abbreviation for the Entertainment Software Self-Regulation Body, an organisation which has been voluntarily established by the computer games industry to classify computer games, classification. The collection is supplemented by donations of a wide range of software (operating systems, popular non-gaming applications) and hardware items (computers, gaming consoles, controllers). Thus, the museum has acquired a nearly complete collection of the domain. An upcoming problem is the rising number of browser and online games which never get a representation on a physical medium. Another unresolved issue is the maintenance of the collection. At the moment the museum does not even have enough funds for bitstream preservation and proper cataloguing the collection.

Archiving (of standard software) already takes place, for example, at the Computer History Museum, the Australian National Library, the National Archives of New Zealand or the Internet Archive to mention a few. Unfortunately, the activities are not coordinated. Both the mostly "dark archives" of memory institutions and the online sites for deprecated software of questionable origin are not sufficient for a sustainable strategy. Nevertheless, landmark institutions like national libraries and archives could be a good place to archive software in a general way. Nevertheless, the archived software is only of any use if it is properly described with standard metadata. Ideally, the software repositories would provide APIs to communicate with a central software archive and attach services to it. The service levels could differ from just offering metadata information to offering access to complete software packages. As an addition to the basic services museums could offer interactive access to selected original environments, as there is a significant difference between having a software package just bit-stream preserved and have it available to explore and test it for a particular purpose interactively. Often, specific, implicit knowledge is required to get some software item up and running. So keeping instances running permanently would have a great benefit. Archiving institutions like museums could try to build online communities around platforms and software packages. Live ‘’exhibition'' of software helps community exchange and can attract users with knowledge who would be otherwise difficult to find.

Software museums can help to reduce duplicated effort to archive and describe standard software. It can at least help that not every archive needs to store multiple copies of standard software but simply can refer to other repositories. Software museums or archives could become brokers for (obsolete) software licenses. They could serve as a place to donate software (from public, private entities), firmware and platform documentation. Such institutions could simplify the proceedings for a software company to take care of their digital legacy. A one-stop institution might be much more attractive to software vendors and archival institutions than the possible alternative of having multiple parties negotiating license terms of legacy packages with multiple stakeholders (Software companies might have a positive attitude towards such a platform or lawmakers could be persuaded to push it a bit). Software escrow services (discussed e.g. within the TIMBUS EU project) can complement these activities. A museum can operate in different modes like in a non-for-profit branch for public presentation, community building, education etc. and commercial branch to lend/lease out software to actually reproduce environments in emulators for commercial customers.

The situation could be totally different for research institutions and users of custom made software. Such packages do not necessarily make sense in a (public) repository. In such cases the question of, how the licensing will be handled arises. If obsolete, they could be handed over to the archive managing the research primary data.

Another issue is the handling of software versions. Products are updated until announced end-of-live. Would it be necessary to keep every intermediate version or concentrate on general milestones. An operating system like ''Windows XP'' (32bit) was officially available in several flavors (like ''Home'' or ''Professional'') from 2001 till 2014. In many cases a ''fuzzy matching'' would be acceptable as a certain software package runs properly in all versions. Other software might require a very specific version to function properly. This needs to be addressable (and could be matched to the appropriate PRONOM environment identifiers). Plus, there are a couple of preservation challenges in the software lifecylce.

Discussion

There are a number of questions which arise when creating or running a software archive or museum:

On which level should a software archive be run: Institutional (e.g. for larger (national) research institutions, state or federal or global level or should a federated approach be favoured)?
Does it make sense (at all) to run a centralized software archive in a relevant size, assuming that for modern, complex scientific environments, the software components are much too individual? What kind of software would be useful in such an archive? Which versions should be kept?
Would it be possible to establish a PRONOM-like identifier system (agreed upon and shared among the relevant memory institutions)? Or use the DOI system to provide access to the base objects?
How, through which APIs should software and/or metadata be offered (or ingested)?
How should the software archive adapt to the ever changing form of installation media from tapes, floppies to optical media of different types to solely network based installations?
Would it be possible to run the software archive as a backend, where locally ingested software is stored in the end?
Is the advantage gain of centralizing knowledge and storage of standard software components big enough to outweigh the efforts required to run such an archive?
Do proper software license and handling models exist for such an archive, like donation of licenses, taking over abandoned packages, escrow services? Would it be possible to bridge the diverse interests of diverse users of a diverse range of software and software producers?
Would there be advantages in running such an archive as/in a non-profit organisation?/What business model would make most sense for such an organisation?

July 4 2013

Networking in EaaS (virtual networks)

Dirk von Suchodoletz Emulation 0

Emulation-as-a-Service (EaaS) can simplify the provisioning of emulation for end-users' needs without requiring them to install and configure complex toolchains on their devices. Beside single machine instances the user is directly interacting with, more complex setups for networked services as in preserved business processes or research environments are required. This involves computer networking between nodes and machines which are accessiblenot directly, but over network links. Depending on the users' requirements the networking is just internal, and unlinked to the rest of the world or it can be required that access is possible from within the original, emulated environment to (parts of) the outside world or vice versa.

Computer Networking

To illustrate the different requirements for EaaS networking a couple of use cases can help to understand the problem set. Starting from the early days of computing, many services especially in business environments are networked. Like for instance for databases there is a (single) server running the Database Management System (DBMS) and clients connecting to it over a network protocol. With the raising popularity of TCP/IP, networking spread to applications like email, file transfer protocols, network drives, or the world wide web. Modern WWW sites may provide additional features which use a database or other services in the back-end such as found for content management services or electronic shops. Other use cases include computer games either played in a LAN setup or over the internet. Early games depended on IPX/SPX networking, all newer ones switched to TCP/IP. Later on new services emerged like Voice over IP. The requirements of the various services regarding bandwidth and latency may differ significantly.

Different higher layer protocols depend on certain physical networks. Nevertheless, the underlying physical transport medium is usually only relevant as different computer platforms might provide different options like virtual Ethernet connections of various speeds or serial line interfaces (for modem connections). Operating system drivers might be needed for the hardware layer and for the higher layer protocols as they were not provided with all operating systems. While the case is comparably easy with Unix and Linux systems dating from 20 years ago, Microsoft and Apple OS added networking later on. The hardware drivers were usually provided by the manufacturers of the devices. Popular TCP/IP stacks for DOS and Windows 3.11 were NCSA Telnet and Trumpet Winsock. Later on Microsoft provided a fully functional TCP/IP stack for Windows 3.11 including fully operational DHCP client. Another challenge is the network configuration. Not all TCP/IP stacks implement BOOTP or DHCP for dynamic IP configuration. A future problem emerges with the switch from IPv4 to IPv6.

Networking in Emulators

Emulators implement hardware components in software which mimic the behavior of their physical counterparts. Modern, modular emulators like QEMU provide a couple of popular Ethernet cards like NE2000, NE2K, PCnet featuring 10Mbps, E100, E1000 (i82551, i82557b, i82559er) for faster connections up to Gigabit. Some aspects of network access require privileged operation executed by the emulator as it might need to modify the network routing table or bridging functionality of the host system. X86 virtualization software usually links quite directly to the host system via bridged, NATed or host-only networking, often providing the feature of more than one network interface provided to a guest. Some emulators offer just user mode networking, where the emulator acts as a normal network client within the host environment, which might limit the available protocols and functionality. In this case the emulator usually provides routing and NATing functionality on the IP layer. Often, the emulator or virtual machine provides higher layer network configuration like BOOTP/DHCP directly built-in into QEMU or VirtualBox. This prevents the use of non-IP higher layer protocols like IPX/SPX or AppleTalk.

Original environments with networking can be connected to each other either on the virtual hardware layer by bridging network interfaces to each other or routed networking on a higher layer protocol like TCP/IP. When directly bridged to each other on the same host system the virtual machines usually provide the software network stack. In cases of accessing the host networking via protocol routing (e.g. for NAT or host-only networking) special virtual network interfaces are required. Those are either provided by the virtual machine frameworks like from VMware, or they use available technology like TUN/TAP deployed by QEMU.

Networking in EaaS

The fundamental building block of an EaaS architecture are abstract emulation-components used to standardize deployment and to hide individual system complexity. An EC encapsulates various emulators, available either as open source or commercial products, into an abstract component with a unified set of software interfaces (API). Beside control interfaces for standard emulator features in combination with node- and user-management a networking control is needed. The task of configuring and providing networking in EaaS is somewhat more challenging. Different objectives need to be met, depending on the actual task. A general software network layer should be provided, which should be able to fulfill the following requirements:

Bridge distributed running systems to each other (on a virtual Data Link Layer)
Allow lower layer packet exchange (Data Link Layer, e.g. for Ethernet, TokenRing, … frames) to provide service for different higher layer protocols like NetBEUI, IPX, AppleTalk, IPv4, IPv6, …
Connect to different system emulators in a standardized way
Allow for network tunneling between EaaS instances and to end users
Provide (controlled) break-out into today's networks (via NAT, proxy, …)

Idially, no privileged access to host resources is required to prevent security issues and simplify configuration.

The base for such a software network layer can be provided, e.g. with Virtual Distributed Ethernet (VDE). VDE, part of the virtualsquare research project, is an Ethernet compliant virtual network/softswitch that can span over a distributed set of physical machines connected through the Internet. The actual needed functionality depends on the use case.

Database Server and Clients

A typical use case depending on the availability of network connects are databases. Usually databases are deployed on a dedicated server and accessed over the network from (numerous) clients. For preservation and access through EaaS several scenarios are possible. Some setups may allow that server and clients are merged into one machine avoiding the need to create a network connection at all. This approach was used for the LINZ database preservation described in Euan's post. The server machine already provided all necessary components (web browser) to access the database. For large scale databases and complex setups, like different operating systems on the server and clients, at least two machines need to be preserved. Then, an appropriate network connection is to be provided and brought up, when a user wants to interact with the client. The bandwidth requirements depend on the actual database application but should usuallybe low. As the database server usually runs permanently, the client expects it to be running. Thus, it needs to be started or resumed before the client is started. In EaaS the user would get only a presentation of the client. Functions need to be implemented which automatically enable the server, when a user requests access to the preserved client. Depending on the user requirements as regards data re-use, the data might need to be extracted into today's user environments. Client implementations exist for many databases, which still run in today's working environments. For these scenarios only the database machine (running the DBMS) needs to be started and a direct network connection to the end user needs to be provided. Ideally, the connection is tunneled to the end user, which avoids open data connections between both sides. The client on the user side directly connects to the local end of the network connection, provided together with the EaaS access. Such a setup avoids creating a specific network tunnel between the EaaS provider and the user.

Computer Games

Networked computer games usually require at least two user instances running. Depending on the type of game one of the clients or a dedicated machine will provide server functionality. While early network games were content with dial-up network link speeds, newer games expect higher bandwidth and lower latencies provided by Ethernet links. Early games were using IPX/SPX over LAN connections, later on IPv4 took over. Different higher layer protocols (expecting broadcast functionality) need to be supported by the virtual network link. The latencies provided by today's WAN connections should be fast enough to suffice for early network games. Network games offer different numbers of simultaneous players. Beside minimal network and user configuration differences all clients are pretty much the same. Thus, ideally every client should be cloned and configured from a single instance to avoid keeping numerous client instances (full machine images and configuration) just for that purpose. The Eaas needs to provide the means to start and configure the server if required and to fire up the needed number of clients upon user request. Here, the users somehow should be able to join the same game.

Business processes

Another use case involving networking between multiple machines are business processes or scientific research environments. Such configurations might have external dependencies like third party services accessed over the network. Either these services can be internalized to keep the original environment functional, or it could be tried to emulate the necessary features of the service. This could be very complex and thus impossible, if e.g. cryptographically secured connections are used. For simpler services it might be feasible to monitor and record the data exchange over the network for certain situations and play-back the answers of the service later on.

April 1 2013

Software Archiving for EaaS

Dirk von Suchodoletz Corpora 3

The typical digital artefact or complex object does not function (render, execute, …) without a certain software environment. Emulation-as-a-Service (EaaS) provides original environments running in platform emulators. Depending on the (complex) object to be handled, several software components are required to reproduce an original environment. Often, these components are proprietary and require a software license. The software itself and the licenses need to be preserved to enable the reproduction of the original environments. There are a couple of issues linked to software licenses. The issue can change over time definitely influence EaaS as licenses (and software "patents") expire or local and remote license servers become unavailable. Another interesting point, masively disputed by some software vendors, is the development of a second hand software market.

Software Archive of Standard Components

Software components required to reproduce original environments for certain (complex) digital objects can be classified in several ways. There is standard software such as operating systems and off-the-shelf applications sold in (significant) numbers to customers. There might exist different releases and various localized versions (the user interaction part translated to different languages as is the case for Microsoft Windows or Adobe products) but otherwise the copies were exactly the same. Such software should be described uniquely and kept in a software archive of standard components.

There are several ideas on software identification and description already discussed in this blog (e.g. by Andrew Jackson). DOIs would definitely be helpful to tag software like ISBNs, describe books and other media. These tags would be useful for tool registries like TOTEM, too. Optimally, such software archives are managed by the relevant (national) memory institutions. As the archive's content is comparably small and well described by the tags, the workload can easily be shared (federated) among several institutions. Different ways could be envisioned to stock these archives. Legal deposit, as is well established for books and other media, is one option. Or, software components could be collected on-demand upon object ingest. This option is discussed and demonstrated e.g. by the bwFLA project. It provides necessary interfaces to a software archive, so that all required software components can be collected and described. This is done via observed installation processes which records all the required user interaction to install a certain component. Such additional information is to be stored alongside the standard metadata such as license keys. The successful rendering of the object can be directly validated by the user to verify the complete capture of all relevant components.

Unfortunately, a general, coordinated software archiving is still a partially unresolved issue. There are a several activities going on at the National Archives of New Zealand or the National Library of Australia. These activities are very valuable to the whole community as some of the software producers often do not archive their products very long. Additionally, some companies leave the market and not all assets are maintained. There exist initiatives like vetusware.com which try to tackle this problem but operate in a legally problematic domain. They might go down because of take-down or simply because of running out of funding. Other sources are specialized archives like browsers.evolt.org for web browsers. The drive-by software archiving as run by the Internet Archive might not capture all relevant software as many components were not freely and openly available for download. Especially for older and less popular platforms it becomes more difficult to get hold of obsolete software. Nevertheless, storing and maintaining software components is a prerequisite of the deal. Nevertheless, memory institutions should have special rights to archive software.

Licensing

Every actually running instance of an original environment requires a certain set of licenses depending on the installed or used software. If e.g. a set of presentation slides with embedded audio, video and spreadsheets needs to be rendered, the licenses for the operating system and the presentation software are required. Additionally, audio and video codecs as well as an appropriate spreadsheet renderer needs to be obtained and installed to make the presentation of the object complete. For EaaS a license management component is required to match the number of available licenses to the requested original environments to run. The sources of the licenses could be different and could depend on the user (and institution) requiring access to a certain digital object in its original environment. In a federated EaaS environment run by different institutions, the sharing and handling of licenses becomes an interesting topic, especially if national borders are crossed (e.g. because software vendors try to maintain seperated markets with different pricing).

Within the realm of (national) libraries and archives the licenses of the legal deposit might suffice. For a more open and general service other ways of licensing are required. Either, the software producers offer a specific type of license for that purpose or specifically acquired licenses (e.g. pre-owned license market) are used. Another option is that licenses are obtained (from the original user/producer of the object) when ingesting the particular object. This might be the case for finished (scientific) projects or end-of-life office environments in companies or government organizations. At the moment, licenses are often just thrown away like used IT equipment. For the future a more elaborate digital lifecycle management should be put in place. With the planning and beginning of a project the licensing of all required components should be secured for the complete intended lifecycle of a particular object.

Custom Made Software Components

Not for all software components a (federated) software archive of standard components makes sense. In many domains custom made software and user programming plays a significant role. This could be scripts or applications written by scientists to run their analysis on gathered data, run specific computations or extend existing standard software packages. Other examples are software tools written for governmental offices or companies to produce certain forms or implement and configure business processes. Such software is to be taken care of and stored alongside the preserved object. The same applies for complex setups of standard components with lots of very specific configurations. In these cases it could make sense to preserve the system as a whole (see blog post on that topic for full system preservation).

Pre-Produced and On-Demand Original Environments

EaaS allows to centralize services and share the efforts. This could be especially useful to re-use pre-produced original environments of standard components. Depending on the type of user – if rendering the object within the premises of the memory institution or being from some commercial entity or a private person – different ways of the (re)production of original environments could be chosen:

Complete environments together with the required metadata to run it in the chosen virtual machine or emulator. This would be the method to deploy for imaged complete systems.
Reproduce the complete environment from standard components using the license information delivered by the user together with the object to render. This may take a while as the setup procedure needs to be completed. The bwFLA project started to implement workflows to gather all the required metadata and user interaction to automatically reproduce such steps.
Re-use existing environments from a "cache" (pre-produced environments). This should be possible for in-house use or as an external service if the required type and number of licenses is available. Here a couple of legal concerns might prove problematic as many licenses may not explicitly allow software lending.
Partially re-use pre-configured environments if licenses are less problematic and just add the problematic/proprietary component.

Several ways were described to automatically re-produce certain environments e.g. for Windows operating systems (link) or as researched within the bwFLA context. Nevertheless, these procedures take time to complete and extend the time span till an artefact or original environment can be presented to the user.

March 20 2013

Challenges of Dumping/Imaging old IDE Disks

Dirk von Suchodoletz Preservation Risks, Preservation strategies 0

A couple of preservation workflows (such as full system preservation through imaging) or processing in digital forensics depend on reliable hardware-software stacks for identity system disk migrations. As especially the x86 platform is moving forward very fast, the hardware and software changes rapidly. Even if the standard suggests compatibility, there are a number of pitfalls which might prevent authentic copies of the original components to an image file.

Despite the formerly wide spread use of (parallel) port IDE disks in x86 computers, there are a couple of compatibility issues with these devices. These issues might prevent the full system preservation (as e.g. described in Full Disk Preservation of a MS-SQL database) to fail partially or completely. While e.g. the 40pin the physical interface did not change, the logical layer did. In the early days limitations of the system BIOS prevented older machines to properly "see" larger disks. For full system preservation the situation is usually reverted: The IDE port implementation might be significantly newer than the disk to be dumped.

Experimental Setup

Parallel port IDE was gradually phased out and replaced by SATA in the mid 2000. Thus, this kind of connector is not found in new x86 machines, which illustrates just another problem of hardware obsolescence. Older machines were found that still had this kind of connection. In the experiments several different IDE implementations (out of the stock of hardware available) were used:

Intel 865 chipset with a BIOS from 2005 (compact PC with Pentium processor)
Intel 875 chipset with a BIOS from 2004 (device not available any more because of died hardware)
Two port onboard controller (Silicon Image parallel port adaptor, same mainboard with Intel 875)
NVidia nForce chipset of 2005 (AMD CPU system)
Lindy cable multi (physical) IDE port to USB 2.0 adaptor
Davicontrol PCI dual-port IDE adaptor (external PCI card, Silicon Image PCI0680 Ultra ATA 133/166)

The identical IDE disks primariy considered where 240 MByte Quantum disks of an experiment to preserve a digital research environment featuring a DB2 database as a core component. The disks, taken from five client machines (the server was equipped with a SCSI disk which did not produce any hassles and identity of the imaging was easily proven), where numbered 1 … 5. Other disks tested where 13, 30, 40 GByte disks dating from around the last turn of the century. For the system imaging procedure a fairly recent 3.2 Linux kernel (Ubuntu 12.04.2 LTS) was used.

Fortunately we got a set of identical (regarding production date and size) IDE disks to test. The partition layout was roughly the same with some variance. The installed operating system was OS/2 version 2.1 on OS/2 HPFS, a filesystem which is directly mountable in Linux.

First Step – Disk Recognition

A preliminary requirement to disk reading is the proper recognition of the device with the controller. This got checked with the various Gigabyte disks without any problems, but produced partly "interesting" results for the 20 year old disks:

The USB adaptor "saw" the disk, but was unable to produce a proper capacity reading (guessed on 2 TByte)
Newer IDE adaptors, like e.g. the onboard controller did not recognize the disk at all
Several disks were recognized by the Intel 865, 875 controllers, but two failed (#2, #4) in some earlier experiment
The failed disk 4 was properly recognized on the nForce and Davicontrol ports

Nevertheless, the old disks were not properly recognized in every boot-up cycle. They needed a certain time to spin up to answer the BIOS/operating system requests properly. Sometimes they "hung", which is indicated by a permanent lighted on-disk activity LED. To see, if the disks were recognized by the operating system (Linux), the kernel messages give the information on which disks are visible to the system. Later on, run with administrator privileges, the fdisk command
should give a proper listing of the contained partitions. The recognition was somewhat tricky:

Disk 2 spins up but does not get detected on any
Disk 3 is only detected on the Davicontrol
Most of the disks were not detected with every bootup. Pausing the machine, rebooting usually helps to get it finally done.
If a diskis not properly recognized during bootup, then the
unloading and loading of the IDE controller kernel module triggers the recognition. This usually helps.
The detection rate on the Davicontrol adaptor was different in different machines. The BIOS and succession of devices in the bus (different order of initialization) seems to influence the process (significantly)

Second Step – Disk Reading

The tool of choice to produce identical copies of block devices in Linux/Unix systems is dd. In standard configuration it reads the block device 512 Byte-wise and writes this to a file (if asked to). After proper recognition the disk was present through the high-level device, e.g. /dev/sda and through the device for each partition e.g. /dev/sda1…5 (numbering depending on the partitions detected).

Every disk aside disk 3 was read from beginning to end with dd if=/dev/sda of=image-file. This procedure copies every thing including the master boot record as well as the partition table. dd finished the process without any errors in every run on every machine. The machine log did not show any errors either. Thus, it was concluded, that the process ran flawlessly. Unfortunately, the simple partition check on the image file fdisk -l image-file did not necessary produce the proper partition listing. This was assumed to be a deficiency of the tool. After trying to boot the resulted system image in emulator or virtual machine, severe mounting problems with the contained filesystems occured (especially with the system partition). Investigating into that revealed that different dd runs (with different blocksize settings tested) produced different image files (using the diff utility and md5sum). Unfortunately no errors were reported from the system at all. Fortunately, by chance the fdisk run on the original medium produced different listings, including incomplete or corrupted partition tables, looking like:

Disk /dev/sda: 245 MB, 245426688 bytes
13 heads, 51 sectors/track, 723 cylinders, total 479349 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sda1 204867 476033 135583+ 5 Extended
/dev/sda2 * 51 204866 102408 7 HPFS/NTFS/exFAT
/dev/sdb3 * 476034 478685 1326 a OS/2 Bootmanager
/dev/sdb5 ? 4143585081 3991997998 2071690107 f6 Unknown

Partition table entries are not in disk order
omitting empty partition (6)

The original reading should have produced:

Disk /dev/sda: 245 MB, 245426688 bytes
13 heads, 51 sectors/track, 723 cylinders, total 479349 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sda1 204867 476033 135583+ 5 Extended
/dev/sda2 * 51 204866 102408 7 HPFS/NTFS/exFAT
/dev/sdb3 * 476034 478685 1326 a OS/2 Bootmanager
/dev/sdb5 * 204918 426308 110695+ 7 HPFS/NTFS/exFAT
/dev/sdb6 * 426360 476033 24837 7 HPFS/NTFS/exFAT

Partition table entries are not in disk order

Other examples of exactly the same disk showed different patterns for the /dev/sdb5 entry line.

This can be cross-checked with hexdump. Different readings produce different results already in the first couple of Kilobytes. Unfortunately the failures are not easy to be distinguished from proper ones. A proper partition table listing from the image file does not necessarily ensure a complete success. Without the proper tools and insight into the reading results a proper proof is difficult to produce as any non-failed dd reading looks correct. The experiences from numerous other tests never hinted on problems to be expected. The dumped images behaved as expected (booted in the emulator without any block device specific errors). As many of the test used non-intrusive dumping, it at least ensured that hardware specific errors could be ruled out (because the machine worked properly with the original operating system). The only source of errors could be the dumping mini Linux in these cases.

The only disk with real reading errors (because of hardware defects, not just producing wrong output) was disk 3:

[ 457.107249] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 457.107275] ata3.00: failed command: READ SECTOR(S)
[ 457.107293] ata3.00: cmd 20/00:03:2d:08:00/00:00:00:00:00/a3 tag 0 pio 1536 in
[ 457.107295] res 51/40:02:2d:08:00/00:00:00:00:00/a3 Emask 0x9 (media error)
[ 457.107317] ata3.00: status: { DRDY ERR }
[ 457.107328] ata3.00: error: { UNC }
[ 457.152340] ata3.00: configured for PIO2
[ 457.152362] sd 2:0:0:0: [sda] Unhandled sense code
[ 457.152366] sd 2:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 457.152372] sd 2:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 457.152378] Descriptor sense data with sense descriptors (in hex):
[ 457.152382] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
[ 457.152396] 00 00 15 7d
[ 457.152402] sd 2:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 457.152410] sd 2:0:0:0: [sda] CDB: Read(10): 28 00 00 00 15 7d 00 00 03 00
[ 457.152424] end_request: I/O error, dev sda, sector 5501
[ 457.152445] Buffer I/O error on device sda, logical block 5501
[ 457.152460] Buffer I/O error on device sda, logical block 5502
[ 457.152472] Buffer I/O error on device sda, logical block 5503

The error listing clearly states problem reading sector 5501+. Such error messages usually coincide with getting an error with dd or problems reading the filesystem in a partition.

To rule out a faulty version of the used Linux kernel, the experiments were repeated with similar results on a three year older kernel with similar results. To check for implementation flaws in the IDE driver even older versions were booted, but then the hardware did not get fully recognized and a disk dump was impossible.

Image Verification

After getting repeatedly different results from reading the disks with the i865 chip set, other devices were looked at for dumping. The AMD/nForce system from about the same era as the i865 system behaved pretty much the same but was able to read disk 4 which was un-accessible on the i865 (reason not totally clear: We may not have tried hard enough to register the disk to the machine by restarting, delaying bootup or reloading the required kernel modules). After a couple of runs, fdisk produced different results (which indicated an early error at the very beginning of the disk) for the same disk, same for the dd runs. The produced images were different again from the images produced on the i865 system. The Davicontrol adaptor was a recent addition to the hardware pool and was used next. Up to now it has never failed to produce a proper partition table reading of different disks. The test was repeated regularly. The produced images were exactly the same in different runs, tested with diff and md5sum. The partition listing of the resulted image files looked as expected (identical to the reading from the original source). The same was true for mounting the partitions (none of the previous filesystem errors encountered from the other images). Thus, it should be pretty obvious that the setup is producing the expected results and has none of the hardware issues of the setups used before. Nevertheless, there might be still hidden errors around.

Conclusions

dd does exactly the job it is expected to, imaging block devices block wise to image files. If the input is corrupted for some reason (but not reported as an error detected by the operating system), dd (or similarly dd_rescue) has no means to detect such an issue. The verification process of the system imaging is to be done thoroughly using different tools and methods to ensure correctness. Rerunning, and comparing the results is one of the available options. The encountered errors highlight once again the importance of a hardware archive offering various options to try on the device to be imaged. Adaptors and system buses get out of use and result in device obsolescence which might prevent the proper preservation of a system. Non-intrusive disk dumping, which requires a suitable dumping OS paired with proper hardware available, at least circumvents the problems detected in this case study.

January 8 2013

Emulation-as-a-Service

Dirk von Suchodoletz Database, Emulation, Preservation strategies 2

Remote access to emulation, remote emulation and the emergence of a wide range of different cloud services, and end users interacting with them remotely through standardized (web-)client applications on their various devices offers the chance to combine both into an integrated access system to various obsolete computer environments. In order to provide a wide range of services, especially in combination with authentic performance and user-experience, a distributed system model and architecture is helpful. It can be run as a cloud service allowing for the specialization both of memory institutions and third party service providers. Such offerings could help to shift the usually non-trivial task of the emulation of obsolete software environments from the end user to specialized providers. Optimally, instead of installing a huge number of software packages which are difficult to maintain even for a small number of relevant platforms, the user should be able to install a simple access application made available for a wide range of today’s and future platforms.

Towards Emulation-as-a-Service

Trying to use several different emulators or the KEEP emulation framework, it becomes clear that it is challenging to provide various hardware emulators and framework services on diverse computer architectures for several, mostly technical, reasons. Architectural and technical differences between powerful desktop machines, netbooks, laptops, thin clients, tablets or even next generation TV screens are significant and thus difficult to be bridged with a one-fits-all solution. Especially, end user devices are a fast moving target as they are replaced quite regularly. Additionally, often secondary software components (like operation systems, ROMs, firmwares, drivers, etc.) are required at the user’s side. A similar problem arises from access-restricted digital artefacts. If a user is interested in such an object, a memory institution may not be able to hand over the complete object e.g. due to legal reasons (IPR, copyrights, regulations, …) or privacy issues.

Emulation-as-a-Service (EaaS, a term originally coined by J. van der Hoeven) can provide a convenient solution for both, reducing the variance of host systems for original environments and solving IPR compliance. Development and maintenance of emulators and their according digital preservation frameworks can be focused on only a few current architectures, leading to a controlled and well understood environment. This avoids a couple of complexities of cross-platform development and allows easier testing as fewer targets with less variety are to be considered. Original environments and their various software components as well as the requested artefacts are not getting outside the controlled systems of service providers. EaaS can offer users of memory institutions the various contents from their digital collections like digital art, encyclopedias, primary scientific data, teaching material or famous persons’ original working environments without giving them direct access to the primary data itself. The access to certain digital artefacts or complete environments can be controlled in a more effective fashion, hindering the user to copy material or analyse it in an undesired way.

Remote access application and protocol are to be defined (like Guakamole, OnLive) to abstract from and translate the actual capabilities of the chosen local platform to the remote running service interfaces. This is not a particular challenge as the same base principles are valid for accessing recent environments over computer networks like for the different virtual machine platforms. Emulated original environments then could “blend” in seamlessly with actual services. Such considerations could provide a solution which allows the access to various 1985 home computer games running in MESS, early 1990ies art work running in some Motorola 68k powered Apple Macintosh, various Windows or Linux desktops and some early electronic arcade games just through the same application representing a front-end interface to emulation service backends. The use of standardized and well-established remote access applications and protocols to link front and backends gains platform independence. This allows also to adapt to different input/output methods used by the end user devices and required by the original environments.

The separation of the service from the user interface allows a distributed environment. Services like emulation components, software archives and authentication services can be shared and split among several institutions and 3rd party providers to enable specialization following the division of labour principle. While EaaS does not primarily require large computing power or storage capacity the model very well benefits from cloud technology in terms of remote access, distribution of services or established authentication and accounting frameworks. The EaaS model can help to leverage typical cloud advantages for better user-centered access services in digital preservation: scalable, on-demand services, less waste of compute resources, optimization of costs or solving IPR related challenges. Resources can be scaled to the actual needs of the organization and thus provide great flexibility, e.g. pay-per-use business models are usually targeted short-term contracts.

Emulation in EaaS

Of course emulators are at the core of EaaS as they bridge the outdated computer platforms to actual software and hardware. With EaaS their operation and maintenance can be simplified as the provisioning of emulators takes place in well-controlled environment which is easier to define and to maintain compared to end user systems. It focuses the available resources and allows the specialization and division of labour among the involved institutions and service providers. The amount of emulators required depends on the artefacts or original environments to be accessed or to be rendered. In EaaS they provide both the base layer for the original system environment and the user interfaces. Special functionality might be required for (large scale) framework integration and automation, like the proper configuration of the emulators and workflows to prepare and transport the original artefacts to be used in and extracted from the emulated environments. While a cloud approach to emulation simplifies a number of issues, several challenges of the emulation strategy still need to be solved. For example, appropriate hardware emulators need to be available to support that original environments are compatible to the host system of the cloud service. Additional components are required, like original software applications, operating systems, firmwares, drivers including the appropriate rights to use them within EaaS. As the original environments are meant to be available to users on their actual devices, access components to emulators also need to translate machine in- and output concepts (as discussed in some previous post). Not only screen resolution and color depth have increased over time, but also keyboard layouts have changed and different other types of inputs like a wide range of mice, joysticks or recently, position sensors have been added to the rather new class of mobile devices like tablets and smart phones.

Acquiring new Audiences through EaaS

Emulation-as-a-Service offers several advantages. It allows new stakeholders to enter the market as services can be offered to a wide range of different customers remotely. Memory institutions can use their knowledge and advantage in the field of digital preservation and access to provide paid services to commercial entities requiring authentic reproduction of digital objects and processes for e.g. legal reasons.

Additionally, to merely provide access to deprecated computer systems new types of services might be established. Running systems can be frozen and resumed by different users or offered to be run from a certain execution state. Furthermore, parallel access of several users to the same system is possible, e.g. for performance measures, scientific, guidance or teaching purposes.

The bwFLA project for functional long-term archival and access, has started implementing and integrating EaaS as part of a state-wide initiative. Currently bwFLA EaaS supports 8 different emulators being able to run 15 distinct legacy computer platforms. The platforms range from MacOS 7 running on a MK68 system emulator, PPC based platforms to various x86-based platforms. Each emulation component is available to be used in various archival workflows through a common web service interface. Remote interaction is provided via VNC at the moment when it will get replaced by a more general and versatile HTML5 component. The project implemented a first prototype of an authentication and authorization component using the existing state-wide Shibboleth infrastructure deployed by universities and libraries. Some of the bwFLA EaaS components will be made available through OPF for testing in the near future.

December 27 2012

The state-of-the-art in System Preservation

Dirk von Suchodoletz Migration, Preservation strategies 0

System imaging – dumping the permanent storage of a computer system to re-run it in an emulator – is a viable option to preserve complete digital environments. These include complex digital artefacts, famous persons machines, electronic lab books of natural sciences research or software and hardware development environments of software companies, to mention just a few. These artefacts or complex environments – further on “preservation targets” – are typically customized for special purposes and often include highly customised configuration or (unique) user programming. Thus, they often cannot be easily migrated into a preservable format without risking the loss of significant information and/or the context provided by the look and feel and user interaction with the system. When migration is needed, e.g. because of system obsolescence or organizational changes, significant resources and associated costs are often required to confirm that all information and context is preserved post-migration.

With the ongoing development in emulation as a preservation and access strategy, the number of success stories of complete systems preserved is rising. After a couple of simple feasibility studies more advanced systems were tackled and more knowledge on the required pre-/post imaging processes was acquired. There are some curational challenges involved in the process, but together with a tailored set of tools, system preservation can be executed by normal archivists and practitioners in the field.

The series of experiments started in Freiburg during the PLANETS project with the preservation of a Linux database system which was a back-end for a CMS of an universities web-site. Another, by now famous example is the preserved Apple Macintosh of Salman Rushdie done by MARBL. During a research stay at Archives New Zealand, the strategy was tested and extended to several Windows systems stemming from between the early 1990ies and mid 2000. Further experiments widened the scope and included systems like a SUN Sparc Station Classic, a networked IBM DB2 system running on OS/2 2.1 or a late 1990ies Apple iMac. Some of the experiments were straight forward, resulting in directly useable results, while others needed more tweaking.

The Imaging Process

The procedure to image the permanent storage (usually harddisk) of a machine to re-run it in a virtual machine was implemented for several commercial virtual machines like VMware, with the VMware converter. It is limited to some popular systems. However, it demonstrates the steps to prepare the to be imaged system for the transfer into a virtualized hardware environment. More generally, this approach was outlined during the Archives NZ experiments, published at last years iPres. Depending on the actual machine, several methods are available to dump the harddisk: In-system, non-intrusive method, which means to boot a networked Mini Linux operating system on the preservation target. Or an intrusive method, which involves removing the harddisk for dumping and connecting it to a suitable imaging system. Such a system would provide the appropriate connectors like SCSI or IDE if the disk cannot be connected to some USB or other external connector for dumping. The involved steps were formalized in a first approach during the Archives NZ Windows system preservation experiments and were refined during a bachelor project jointly run at Victoria University and the Archives. At the same time the bwFLA project is developing workflows to automate system imaging workflows for different hardware architectures.

Success and Partial Success Stories

The first experiment run during the PLANETS project in 2007 looked at a MySQL database system running on a SuSE Linux 8.0 on 32bit X86 hardware using a RAID over three SCSI disks. The system was brought into a special state to avoid disturbing filesystem IO during dumping by re-mounting the filesystem read-only. The dump run straight-forward from the machine over the network onto some receiving machine. Thus, the actual RAID configuration was used to generate a single blockdevice image from it. The resulting image was converted to the VMware image format using the qemu-img tool. The VMDK image did only partially boot loaded to the virtual machine as the virtual SCSI subsystem was using a different controller. To fix this, the install CD of the original operating system was booted and the Initial RamFS was reproduced using a different controller and omitting any RAID setups. Finally, the system was successfully running virtualized.

Another famous case was the reproduction of the real Apple Macintosh, a Performa 5400 all-in-one machine, equipped with a PowerPC 603e processor used by famous author Salman Rushdie. The MARBL at Emory University acquired the archives of Rushdie and wanted to make the author’s desktop as completely as possible available to researchers.

The Archive NZ experiments on Windows preservation targets were comparably easy. Some mid 1990ies to mid 2000nd computers were set up with Windows 3.11 to Windows 98. The disks were imaged both using a separate dumping machine, using an USB adaptor if appropriate, or booting a Mini Linux to dump the disk content over the local network. All resulting images were perfectly bootable, except for the Windows 98 image. The latter required to write a new MBR and re-sys (sys c:) the image for it to become bootable again. All images required to exchange the relevant driver setups for graphics, networking and audio in order to get higher screen resolutions than 640 by 480 pixels, audio output and the machines re-connected to the network. Windows 95 and 98 required to re-initialize a couple of standard drivers for mainboard and IDE too. The required driver sets depend on the emulator or virtual machines used.

The X86 emulator QEMU e.g. offers Cirrus Logic and other types of VGA, different types of audio cards, including the famous Soundblaster series, and a couple of different network cards emulating AMD PCnet, RTL8029, RTL 8139 or NE2000. The Windows 3.11 system was too old for VMware and VirtualBox, thus a generic SVGA driver (the original Microsoft SVGA patched to support the VESA specification) was to be used to obtain a 1024×768 resolution with 256 color palette. No higher resolutions or more color depth is possible in these setups. The driver produces a partial crash during Windows boot with full Microsoft networking in VMware, but not in VirtualBox. Another problem occurs after installing the SoundBlaster 16 audio driver, replacing the original ESS hardware. All works well in Windows but prevents it from proper shutdown.

To widen the list of architectures later on it was tried to preserve a Sparc Station Classic, featuring a SCSI disk, running Solaris 5.5.1. The dumping of the disk connected to an Adaptec controller attached to some Linux host run smoothly and the system successful started to produce a couple of lines output in the Sparc variant of QEMU on an Ubuntu 10.04. But after it was possible to read the actual version message of the Solaris operating system the emulator crashed because of some illegal CPU instruction. The emulator itself was successfully running with a Linux variant compiled for Sparc Stations. Unfortunately, Sparc is not a very popular platform anymore and thus the support for the architecture is poorer compared to the more popular ones. But fixing the emulator should fix the boot process of the imaged system.

A larger project, because it concerns another less popular system running in a client-server configuration, was the reproduction of a networked OS/2 database server connected with a couple of clients via TCP/IP over TokenRing. The server featured a SCSI disk, the client machines were equipped with IDE disks. All machines were installed in 1994. An intrusive method was used to dump the disks as no Ethernet adaptors and no easyly bootable device like a CD-ROM were available. The SCSI disk got easily dumped using the procedure deployed for the Sparc disk.

Another experiment at the Archive NZ was the virtualization of a Windows 2000 machine running a MS-SQL database. It was part of a research project at the Archives to investigate the best approaches for appraising, transferring (where relevant) and preserving databases. The machine held an MS-SQL database with a custom HTML front-end. The database consisted of a digital index to a couple of paper records transferred earlier from an agency. The migrated and virtualised (or emulated) database may now be used in our reading room(s) to aid users in discovering and accessing the transferred paper records.

IDE Disk Challenges for Older Drives

In a couple of experiments the machines needed to be disassembled to remove the drives as they were not bootable with a suitable Mini Linux or there was no suitable network connection available. Different to expectations as most people would assume IDE to be more wide-spread and compatible, the dumping of parallel port IDE disks was more challenging compared to the SCSI counterparts. Usually, an USB IDE adaptor, either from an external disk case or as a special “adaptor cable” which usually comes with an external power adaptor, is a convenient method. In this case, the disk can directly be attached to the imaging machine.

If the disk is really old, which means before the mid-1990s, the USB adaptor does not properly talk to the disks to gather the capacity information. In the NZ Archive experiments a couple of older laptop disks failed as well as the 240MByte disks of the OS/2 clients. Even directly attached IDE channels on system motherboards did not properly recognize these disks. A typical sign of a reading failure is the report of 2TByte capacity on USB or undetected disks in BIOS on mainboard channels. Finally, an older Intel 865 chipset was able to properly detect it. There seem to be firmware issues, as all newer disks (usually of a Gigabyte upwards) are properly detected both on USB and internal IDE channels. Unfortunately, there was no IDE adaptor card, comparable to the SCSI adaptor, available to circumvent the problem to preserve a complete machine for early IDE dumping.

OS/2 Imaging Oddness

For some not yet understood reason the system imaging of OS/2 2.1 IDE disks did not completely work as expected. We got several rather similar clients to test with, but interestingly the problem was exactly the same with the other client disks dumped too. The issue of the dumped disk image seems to be a structural one as different partition layouts resulted in the same kind of problems (the partition table did not read completely, especially extended partition information was garbled). A couple of experiments were run like copying the disk 1:1 to a much larger IDE disk (of 13GByte of size). The results were as expected: The partition table listed exactly the same layout and every partition was mountable in the Linux system used, but reporting some filesystem errors for the first partition, which shouldn’t be there. To investigate into the imaging problem the procedure was re-run with dd_rescue (without giving a blocksize). It resulted in exactly the same image as the dd with a blocksize of 512Byte (as could be expected). A test-run with a blocksize of just 1Byte resulted in an image containing a readable partition table and behaving in exactly the same way as the image taken the normal (512Byte blocksize) way from the 13GByte disk. The image differed from the other ones (using the diff utility). The results are a bit disturbing: Usually you would expect a proper image from the usual dd(_rescue) process. Nevertheless, there was no similar problem when imaging the SCSI disk of the same operating system.

Emulator Hardware Issues

The 16bit version of the early 1990ies Windows version running on top of DOS is just 25 years old, but already gets neglected by the major virtual machines like VirtualBox and VMware. Both feature a custom made VGA and thus there is no direct driver support for the OS available. The only option to get beyond 640 by 480 resolution in 16 colors, which might not enough for a couple of artefacts, is to binary patch the Microsoft SVGA driver for that system. It adds VESA 2.0 support for a range of graphic adaptors and allows resolutions up to 1024 by 768 resolution allowing 256 colors. Interestingly, the SVGA driver interferes with Microsoft networking (SMB) if enabled in VMware and prevents the machine to boot into Windows normally. This problem is not visible in VirtualBox, though. The situation is much better in QEMU or DOSbox as both machines replicate real hardware like a Cirrus or an S7 video adaptor.

As both types of machines still offer Soundblaster 16 and an AMD PCnet network adaptor, direct driver support is still available. For some reason the installation of the SB16 sound drivers into the imaged Windows 3.11 installation from then on prevents the system to properly shut down. It got ESS drivers installed when running on real hardware. There was no issue when adding SB16 to a fresh install.

A similar VGA problem popped up with an imaged OS/2 2.1 installation. The originally installed SVGA driver prevented the machine to start properly. It was to be reset to standard VGA to display the graphical user interface and boot up. This operating system has networking issues in QEMU, as the interrupt handling of the network card does not cooperate properly with the OS driver. But, it works in VirtualBox. VMware does not support OS/2 at all.

Hardware Replication

The original hardware replication pretty much depends on the preservation target’s architecture. Platforms like the various homecomputers, Apple Macintoshs or SUN Sparcs were rather limited regarding the hardware variance. Thus, it was comparably easy for well defined hardware with limited variability to provide an emulator matching the original system. If the emulation is complete like for Apple PPC, the system directly ran in the emulator without modification. An open issue is the incomplete emulation for instance for the Sparc architecture. QEMU is able to run a Linux compiled for Sparc but an imaged version of an original Solaris installation crashes in early stages. The varying popularity of platforms often results in varying quality of emulation.

A direct hardware replication for X86 will be impossible in most cases, as the variety of hardware is much wider than the supported one. X86 is one of the longest living architecture evolving over more than 30 years by now. Step by step new components got introduced and components improved over the time. Thus, an X86 of the early 1990ies is kind-of compatible to a today’s machine, but a Windows 3.11 or Windows 9X will most probably not execute properly any more on it. The drivers are only part of the problem.

In general there might be specifically challenging setups which required lots of CPU power and RAM when originally running. But, for many large systems the future access requirements usually lower than of actually running systems. Usually it would be acceptable to wait longer for a query to complete on a preserved database than one running in production. Nevertheless, CPU and memory resources for original environments are less of a problem and could be often generously applied.

Preliminary Conclusions

The range of experiments created lots of knowledge on the different systems regarding setup and configuration particularities. Much of it should be re-usable on similar tasks, simplifying the imaging of systems of the same type. The preservation hardware environment is usually fixed and limited in most cases, as often only one emulator is available, like for the SUN Sparc or the iMac. Especially for certain hardware architectures the bandwidth of sold hardware components was very limited making it much easier and more predictable for emulator programmers. Nevertheless, usually the target emulator is well defined. The preservation target can be prepared for the transfer in advance to make the transition process more smooth, by e.g. adding drivers for the emulated hardware (and removing conflicting drivers from the original setup), resetting screen resolution, … At Victoria University a student project was run as well as in the bwFLA project in Freiburg to define standard workflows for preparation of preservation targets. This includes the gathering of metadata on the original system.

Beside to automatically collectible metadata information like software licenses and account’s passwords are to be acquired if the access restrictions are not removed (e.g. passwords cracked, reset).

From the wide range of experiments run can be concluded that there are better and less well preservable systems. Operating systems prepared and supported in virtual machines should be preferred where possible. Generally, the procedure can be expected to get easier with newer systems as they are all network capable. Nevertheless, heavily secured and proprietary platforms like the Apple iPad may pose new problems here.

Open Research Questions

Even if the above issues such as incomplete emulation are solved, there are still several open research questions. What kind of modifications on the preservation target are allowed for the emulated result to be still authentic? How would it be possible to measure success of such a preservation workflow? For migration scenarios the research has produced a couple of answers like the concept of significant properties or object description languages to compare the result against the original.

As the object considered for system imaging is much more complex, the measurement of success and completeness of the workflows is not completely clear yet. The process can be seen as a kind of migration affecting certain parts and aspects of the object. Usually, lower layer components of the hardware-software-stack like the CPU or drivers are affected. These should not but definitely can affect the object of interest, which is usually a certain application like a piece of digital art, computer game, scientific workflow or business process. As most probably the concepts of traditional migration can only be partly applied, new metrics are to be found to describe complete systems in a way which allows proper (automatic) verification. A subset of questions would include acceptable transformations to the original filesystems regarding the cleanup of privacy related content or changes made to configuration files.

< 1 2 3 4 5 >»