Recommendations from the EaaSI Team for Creating Environments

In Emulation-as-a-Service, Environment resources can be created and chained off one another, allowing different configurations and combinations of software to be re-used broadly across collections (or tailored to suit specific digital objects and use cases). In this chain model, the starting link is generally referred to as a base Environment, while the next/successive link in the chain is referred to as a derivative Environment.

“Derivatives” is therefore a catch-all term that can be used to encompass several specific types of Environment that might be built on top of a base, including (but not necessarily limited to):

  • Content Environments

  • “revisions” (a derivative Environment with some adjustments or improvements made, intended to supersede or replace its base in the EaaSI UI)

  • “forked” Environments (created when a user wants to intentionally create a new, stand-alone Environment branching off from a specific point in an Environment’s derivative history)

Given the branching and highly variable nature of these derivative chains, it’s particularly imported for EaaSI-related workflows to start as much as possible from well-defined and replicable base Environments. However, the definition and requirements for a base environment may vary between organizations or even collections - access to the live internet, for instance, might be of critical important to base environments in one workflow, while completely undesirable in another.

Though the EaaSI team can not dictate what makes an appropriate “base Environment” in all scenarios for all users, certain features, functionality, or even current limitations of the platform should be used to guide creation, configuration, and publishing of bases. This page is an attempt to provide this context and appropriate recommendations for potentially crucial decision-points in Environment creation, with the hope of encouraging more efficient workflows for EaaSI users everywhere.

These are intended only as guidelines and should be adapted or changed as necessary into specific local workflows.

Recommendations are divided into sections, categorized into particular “types” of computing environment that tend to have shared concerns for emulator/hardware settings and OS or software configuration. These categories are neither hard-and-fast nor mutually exclusive - setting up an Ubuntu server base, for example, one might to consult recommendations for both “Web Server Environments” and “Open Source Environments”.

Desktop Environments

Definition, Scope, Examples:

“Desktop” computing environments generally refer to personal computer workstations from approximately the late 1970s to the present (i.e. beginning with the widespread use of microprocessors, overtaking mainframe and minicomputers). They encompass hardware, operating systems, and software commonly associated with mass office/work/lab settings or home computing.

Desktop environments are also commonly graphical/GUI computing systems (Windows, MacOS) but not exclusively, as the term also can encompass early terminal/command-line-based personal computing systems like DOS, the Apple II, the Commodore 64 line, etc.

Due to the overwhelming popularity of such systems, the EaaSI platform and workflows have largely been designed with desktop environments as its primary use case, as most of the inaccessible, software-dependent data and born-digital materials collected by cultural heritage and scientific archives have (at least up to this point in time) been generated by desktop systems and software from the personal computing era.

Desktop environments have historically served as both clients and servers in computing networks. Since the EaaSI platform does not yet support the creation and configuration of emulated networks, particular guidance is offered in a separate section for recreating server-client relationships between software programs in an EaaSI desktop environment. Otherwise, these recommendations assume that a desktop environment is self-contained with, at most, a client relationship to the live internet.

Examples of desktop environments:

  • IBM PC running MS-DOS 6.22

  • Commodore PET

  • generic 32-bit x86 PC running Windows XP

  • PowerMac G3 running Mac OSX 10.4

  • Generic 64-bit PC running Ubuntu 18.04

Environment Option Recommendations:

  • Relative Mouse (Pointerlock)

    • Relative Mouse (Pointerlock) behavior is extremely variable depending on emulated system

    • Generally, users prefer not to have their mouse input captured by a web application; however, with some older guest systems (particularly older GUI-based systems that are NOT compatible with absoute pointing devices such as an emulated USB tablet), it may be the only way to make the system tolerably usable

    • Relative Mouse input can be greatly affected by network latency, so lag will be variable depending on the user’s internet connection and physical proximity to their EaaSI node

  • Virtualize CPU

    • If emulated system is KVM compatible, enable Virtualize CPU

    • If emulated system is not KVM compatible, disable Virtualize CPU

    • Please note that KVM compatibility and the Virtualize CPU function may silently fail or even eventually break, depending on configuration of the EaaSI node and future updates to the KVM project; see KVM Support

  • WebRTC Audio

    • Enable WebRTC Audio

  • XPRA Video

    • Enable XPRA Video

  • Requires Clean Shutdown

    • If emulated system is ACPI compatible, enable Requires Clean Shutdown

    • If emulated system is not ACPI compatible, disable Requires Clean Shutdown

  • Configured Drives

    • Configure at least one each of “CDROM” and “Floppy” drives (up to 7 total)

    • At least one “Disk” type drive is required by EaaS Environments to function and the system will automatically enforce this without the need for user input

  • Image size

    • When creating new Image resources to use in the creation of new Environments from scratch, try to maximize drive size (to allow for the most possible space for Software or Content data to be copied to the drive if need be in derivative Environments) while staying within the realm of operating system and filesystem compatibility (for example, the FAT16 filesystem used for many DOS systems did not allow for drive sizes greater than 2GB)

  • Emulator Configuration

    • Attempt to maximize the amount of RAM available to the emulated machine while, again, staying within the compatibilty limits of the emulated operating system or hardware

Operating System and Software Configuration:

  • Pop-up windows

    • Remove any and all pop-up windows that appear when a user first boots the emulated Environment (including welcome messages, trivial errors, etc.)

  • PostScript printing

    • If possible, install a PostScript-compatible printer driver; otherwise the “Environment Can Print” feature will not work whether or not the Environment Option is enabled

  • Setting up user accounts

    • In multi-user systems, set up both at least one “root” (or admin) and one non-“root” (admin)-level user account

    • Record account credentials and passwords used during configuration and store them in a convenient external location for consulting or sharing

    • While it is in the roadmap to include user account credentials in EaaSI Environment metadata, this feature is not yet implemented; use an external site or method for description, recording the relevant Environment name and/or UUID for tracking purposes

    • It is strongly encouraged to configure the Environment to automaticlly log-in to the lower-permission (non-admin/non-“root”) user account on boot; this will avoid the need to redundantly enter credentials

  • Display resolution

    • 4:3 display ratios (e.g. 1024x768 or 800x600) generally look best if primary interaction will be via the Emulation Access interface of the EaaSI UI

  • Virtual CD-ROM drives

    • Install compatible CD-ROM drivers in the emulated Environment when at all possible; otherwise only Floppy-type Software and Content resources will be able to mount in the Environment, even if a “CDROM” drive is added to the Enviornment’s Configured Drives

  • Operating system upgrades, service packs, and/or point releases

    • The rule of thumb is that later/more-updated operating systems are likely more stable and feature-rich; ergo it is best to install as many service packs, upgrades, and/or point releases as are available for any given operating system

    • However, even if available, upgrades or service packs can unintentionally break compatibility with applications (or in the worst-case scenario, actually be less stable than a previous version!)

    • Perform research on your desired/target emulated system to find a recommended state that matches your use cases

  • Automatic updates

    • DISABLE AUTOMATIC UPDATES everywhere and anywhere they are offered by an operating system or individual applications, if possible.

    • At best, automatic updates often cause annoying pop-up messages. At worst (if the “Internet Enabled” Environment Option is turned on), they can result in unintended changes and errors in the Environment.

Open Source Environments

Definition, Scope, Examples:

Environments running open source operating systems likely share many of the same setup concerns as commercial/proprietary desktop environments, but may also have unique installation or configuration concerns, given significantly different historical patterns and methods of software distribution in the open source community.

Primary distribution of many legacy open source software applications and systems occurred over the internet rather than via boxed/commercialized physical media. Package managers became essential for open source system users to control the installation and configuration of software components from a variety of online repositories rather than a single source company. This relationship is difficult to replicate in emulated/EaaSI Environments, given changes over time to both the content and the very structure of the internet. These recommendations attempt to account for that.

Examples of open source environments:

  • Linux distributions (Debian, Ubuntu, openSUSE, Arch Linux, Red Hat/Fedora, etc.)

  • BSD distributions (FreeBSD, OpenBSD, NetBSD, etc.)

  • FreeDOS

  • Haiku

  • OpenSolaris

  • Raspbian/Raspberry Pi OS

Environment Option Recommendations:

See: all the same recommendations made for Desktop Environments above.

Operating System and Software Configuration:

  • Selecting installation media

    • When sourcing installation media (ISOs) for open source operating systems, try to find the most complete/comprehensive option available, i.e. where the most approved software packages for the OS are contained on the ISO(s) themselves

    • Many open source distributions have offered “light” or “net” installation media as an alternative to complete ISOs. These were intended to minimize the amount of time + data needed to download and install a basic version of the system, but assumed you would be able to supplement your system by fetching much more software from the internet later. Depending on the age of the system, this is no longer a safe assumption, and installing from known/provided media like an ISO file is a much more stable and convenient option in EaaSI.

    • AVOID “light”, “net”, or similar installation media offered by open source projects; associate as much of the software you actually intend to use/run in EaaSI with a dedicated Software resource as possible.

  • Connecting to the EaaSI Open Source Archive

    • Work is ongoing in the EaaSI program to address issues related to legacy open source package management.

    • Please see open-source-repo for details and instructions on how you may be able to configure your open source system to install legacy versions of open source packages from EaaSI’s repository rather than the default (often defunct) sites on legacy systems.

  • Sudo

    • Many common open source distribution systems, such as Linux and BSD systems, contain a “sudo” permission that allows a non-root/admin user account to temporarily gain root power, e.g. to install a piece of software.

    • As with desktop environments, EaaSI recommends that open source environments are initially set up with at least one root/admin and one non-root/admin user account; however, we can not comprehensively recommend whether the/a non-root user should be set up with “sudo” rights.

    • We can recommend that an EaaSI user setting up a base environment should/must consider and evaluate whether to give the non-root account “sudo” rights during initial setup of a base Environment, based on expected use cases.

Server Environments

Definition, Scope, Examples:

While support for emulated networks (connecting one running Environment to another Environment in a virtual LAN) has not yet been tested and approved for the EaaSI stack, that does not mean client/server-based applications and platforms can not be addressed or accessed using an EaaSI Environment.

It does mean that some light manipulation or counter-intuitive configuration of an Environment may be recommended, in order to replicate the traditional relationship between client and server applications - which are usually assumed to be run on separate computers connected to each other over a network - within a single Environment.

This is particularly/notably true in the case of emulating web servers, where it is likely necessary to emulate both the original web application hosting/serving a site AND the legacy browser intended to run or view the site.

Examples of server environments to which these recommendations may apply: - Ubuntu Server 16.04 - Windows Server 2012 - Mac OS X Server - Red Hat Enterprise Linux

Environment Option Recommendations:

Since EaaSI team recommends setting up graphical desktops for most server environments (see below), all of the Environment Option recommendations above for Desktop Environments apply.

Operating System and Software Configuration:

  • Installation media

    • Use explicitly defined/labeled “Server” installation media and/or installation profiles during operating system setup

    • Such profiles or editions usually install sensible default utilities and settings for setting up server-based applications, reducing the amount of time needed to track down dependencies.

    • Server editions also generally result in a smaller, less data-heavy base Image, requiring less caching and the likelihood of a smoother experience running the Environment in EaaSI down the line.

  • Desktop environments (DEs)

    • However, it is recommended to install a Graphic User Interface or desktop environment on top of the server operating system if not already included.

    • This is particularly notable or unusual in the case of Linux or BSD-based server systems, which in real-world scenarios frequently assume they will be accessed via the command line and eschew a graphic environment in order to cut down further on the amount of data and software needed to install.

    • In EaaSI use cases, the limitation to a single Environment for setting up both server and client applications on the same computer means that a GUI or DE is likely necessary for setting up the desired client application (such as a web browser).

  • Domain name resolution

    • When installing or configuring your target server-based application, make sure to configure all relveant domains and addresses to point to “localhost” or an equivalent local IP address (e.g. 127.0.0.1)

    • External access to/from a virtual LAN, as stated previously, is not supported and domain name resolution will fail in any case. The server will only be able to find/locate itself or possibly (if the Environment Option is enabled) the internet, via a pre-defined/tunneled virtual LAN set up by EaaS.

  • Remote assets

    • As with domain name resolution and automatic OS updates, EaaSI users cannot assume that assets referenced on any remote/online machine outside of the server environment itself (embedded video, images, audio, text, JavaScript, etc.) will be reachable by the server application running in an EaaSI Environment.

    • When creating a server-based Image or collection object for import into EaaSI, inspect the defined application/object to ensure it is as self-contained as possible. This may require downloading, restructuring, and/or rewriting the application or object to point to local assets rather than remote ones; this process can also be completed within EaaSI but will likely be more conveniently done outside of EaaSI unless there is a specific software dependency that itself requires emulation and precludes this option.

  • Credentials

    • Setting up a server-based application will almost certainly require multiple sets of user account credentials, such as an admin user for a database program (like MySQL, MS Access, etc). Record and store the credentials used in an external location, outside of EaaSI.

  • “Kiosk mode”

    • EaaSI users interested in setting up server Environments to address and provide access to obsolete web sites (by installing a browser that then points to a web site configured to be served at “localhost”) may particularly wish to investigate whether a compatible browser has a “kiosk mode” setting, which generally defaults the browser to run in full screen and prevent the user from exiting the browser and accessing the rest of the system without a series of (obscured) inputs.

    • “Kiosk mode” generally became common in the late 2000s.

Android Environments

Definition, Scope, Examples:

The open source mobile operating system Android can be run in EaaSI, but has very specific requirements for installation media, Environment Options, and configuration to function as expected (compared to the much wider range of emulated hardware options and configuration settings potentially available to create desktop environments).

Specifically, at this point in time Android environments and software can only be used thanks to the Android-x86 project, which is a community-drive (not officially supported by Google) effort to port the operating system, which is originally designed for mobile processors using the ARM architecture, to the standard desktop PC Intel x86 architecture. Using installation media from the Android-x86 project, EaaSI users can set up Android environments compatible with the standard/generic x86 processors emulated by QEMU.

The following options are recommended (or, where noted, required) in order to build Android-x86-based EaaSI Environments.

Environment Options

  • CD-ROM drive

    • At least one “CDROM”-type drive MUST be assigned in the Environment’s Configured Drives.

    • Android can read the ISO filesystem but can NOT read/understand “Floppy”-type media, so “CDROM”-type Software and Content objects are one of the only practical options in EaaSI for loading software into an Android environment (including installation media).

  • Essential QEMU Emulator Configuration

    • To all intents and purposes, EaaSI users should/must include the following in their Emulator Configuration for Android environments: -soundhw es1370 -vga vmware -net nic -device usb-tablet

    • These options configure QEMU’s emulated sound card, graphics card, network adapter and user input device, respectively; at this point in time none of QEMU’s other emulated device options have allowed for a stable experience with audio, video, internet connection, or user input in Android environments.

  • Environment Can Print

    • It is currently unknown whether there is any circumstance in which the Environment Can Print feature in EaaSI is compatible with any Android system configuration, even if enabled.

Operating System and Software Configuration

  • WiFi setup

    • Always skip any attempt to setup WiFi or internet connection offered during an Android installation. The Environment will not be able to connect to the internet properly until the Android-x86 installation is complete.

    • Once installation is complete, you should be able to configure and connect to the internet (assuming that Environment Option is enabled) using the “VirtWifi” network offered under network/wifi settings.

  • Enable “Native Bridge”

    • Most Android-x86 installation media adds a “Native Bridge” setting to the operating system that allows for automatic background translation of ARM applications to x86. It is highly recommended to enable this feature to allow for installing Android apps down the line without needing to consider whether they were written with ARM/x86 compatibility in mind.

    • If available, this setting will be under Settings -> Android-x86 options

  • Automatic updates

    • As with desktop Environments, disable or opt out of automatic updates to Android and installed apps.

    • The location for these settings can be variable depending on Android version but can usually be found under Settings -> Software, Settings -> System, and/or in the settings for the Google Play Store app.