Containerized MOPAC Deployment

In this repository is a somewhat modified version of MOPAC. You will package this version of MOPAC and build a containerized server to distribute it.

Note this problem is moving us towards a strategy that is similar to how many web servers work. Some important differences are that (1) you won't need to worry about GPG keys in this problem, which would be essential if you were to actually distribute via this approach, and (2) we won't make the host machine accessible to remote clients.

Task 1

Modify the code in the repository to enable it to be packaged through CMake as a Debian package that follows Debian package naming conventions. Ensure that the package indicates appropriate dependencies for MOPAC.

Task 2

Create a GitHub Action, running on an ubuntu runner (such as ubuntu-latest), that does the following:

1. Builds MOPAC as a Debian package, within a Docker container. This container must also serve MOPAC in a way that allows MOPAC to be installed via apt-get on the host machine (i.e., the GitHub runner). Note that this container is not intended for distribution, so its size is largely irrelevant.
2. Uses apt-get on the host machine to install MOPAC.
3. Runs a simple MOPAC calculation on the host machine and prints the results. You may use the input file input/formic_acid.mop, if you wish.

Note that there is already a mopac APT repository. To be sure you don't accidentally install from an official repository, I've changed the CPACK_PACKAGE_NAME parameter in the CMakeLists.txt file to openmopac. When installing through apt-get, you should use openmopac as your package name.

Hints

In the lectures, we saw that you can run a server (or any other command) in the background by appending an ampersand (&) to the end of the command. This allows the terminal to remain responsive to new commands, while the server continues to run in the background. In this problem, you'll instead need to make sure that the container runs in the background, so that it can listen for requests without blocking the terminal. You may find the Docker --detach flag (alternatively, -d) to be useful for this purpose. Note that within the container, there is not necessarily any need for the server to run in the background (and running in the background might lead to certain complications, such as the container terminating prematurely).

Of course, the server will take a finite amount of time to start running, and you may need to do something to force the host to wait for it to start up. A simple approach might be to use the sleep command. If you use this approach, note that it might take a couple minutes for the server to be available.

You will also need to ensure that the server, which is running inside the container, is accessible from the host machine. This can be accomplished through the -p host_port:container_port flag, which allows you to "publish" the container port to a port on the host machine.

You will need sudo access to update files inside /etc/apt/sources.list.d on the GitHub runner. This sort of task is often accomplished using pipes and the tee command. For example, the following line is recommended when installing Kubernetes:

echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.34/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list