0% found this document useful (0 votes)
9 views

Lab2 InstallingAVM

Uploaded by

coucou
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as ODT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views

Lab2 InstallingAVM

Uploaded by

coucou
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as ODT, PDF, TXT or read online on Scribd
You are on page 1/ 5

Lab 2 – Creating a Virtual Private Server

CMSC 240
Fall 2024 Due Wednesday, Oct. 2nd by 12:00 noon

Introduction

Note: For this lab (and this lab only), feel free to work in groups of two or three students. Grading will be done
by a “demonstration” instead of submitting through the course web site.

Congratulations on your new job!

Longwood Gaming Systems is a new startup company that plans to monetize access to
open source games. They will provide custom multiplayer servers for the incredibly successful and popular
games wesnoth, megaglest, minetest, bzflag, and openttd. Working with experts in graphic design, story
planning, and software development they plan to create mods for all these games that will attract a huge user
base willing to shell out big bucks to access their premium content.

The good news is that you will be a key part of this exciting new business. Your team has been hired as system
administrators for this new start up. Your task is to set up and configure a private virtual server that can host all
of these games, set up dedicated game servers for each game, and test that users can connect to it from the
workstations in the Stevens Lab. The bad news is that they have no revenue and can’t pay you….

However, if you are able to get all five game servers up and running, there will be an opportunity to earn an
extra slip day at the end of the lab.

On a more serious note:

Installing an operating system is a basic, but very important skill for any system administrator. One of a
system administrator's tasks is “imaging” a new system – installing the operating system and a default
set of applications that users of his organization need. Often, this is done by setting up a prototype
system and then copying all the files from its hard drive to new systems. There are many commercial
products for distributing these images over a network, but it turns out that it's also fairly easy to roll your
own solution in Linux using SSH, tar, and a little Bash magic.

Unfortunately, I don’t have an unused computer system I can share for you to get Linux set up. However, I do
have a Proxmox Virtual Machine server that will let me create a bunch of virtual private servers. You won’t be
able to carry out the entire install process because you won’t have physical access to a hardware device, but you
can carry out most of the meaningful steps of setting up Linux.

Before an image can be distributed, though, a prototype system needs to be configured. In this lab, we will be
setting up a basic image which contains a fairly minimal Linux base system with a web server, a database, and a
development environment (including a C++ compiler) installed and configured. Then we will install a whole
bunch of game servers.

Warning: Some of the steps of this lab involve compilations that may take several minutes or even hours
to complete in your virtual machine. This depends heavily on the hardware, how heavily the Proxmox server
is under load, how much network bandwidth is available on campus, and many other external factors I can’t
control. You may want to pick a time that you can do other work while you wait for those steps to complete.
Also, the Proxmox server I use to manage the virtual machines is isolated from the campus network and can
only be accessed from the Computer Science network. This means that if you want to work remotely, you will
need to make two SSH connections. You may also need to use “tunneling” to forward ports from your server to
your local system, so spend some time reading through http://www.cs.longwood.edu/RemoteLogin.html to see
some helpful tips on how to make all this work.

Many of you have probably used a graphical installer to set up dual-boot on your personal computers or
installed Linux in a Virtual Machine within some inferior operating system. The installer takes care of many of
the low level steps for you, such as partitioning, formatting the drives, compiling the kernel. In this lab, I am
going to ask you to do many of those steps by hand.

Step 0. Setting Up

I have created a virtual machine for each of you on “melkor”, the Advanced Computing Lab VM server. The
VM has one single-core processor, 1Gb of RAM, and a 32Gb “disk”. By default, the system boots from a
virtual DVD drive that contains an Arch Linux installation disk. That installation disk is running an SSH server
which you can use to connect to your VM and begin the installation process.

The IP address of your virtual system has the form 192.168.50.XX

where XX is 60 more than the number at the end of your submit system username. For example, if you are
student21, since 21 + 60 is 81, your IP address would be 192.168.50.81.

You may use ANY of your groups virtual hosts to complete this lab. If you happen to get one system in
into an unbootable state and can’t get it to come back up, feel free to switch to a different host.

In order to authenticate, I have set up “passwordless SSH”. I have created an SSH private key/public key pair
and registered the public key in the “authorized_keys” file on the installation disk’s “root” account. You can
connect to your virtual machine by downloading the private key into your .ssh folder, setting its permissions to
600 with chmod, and using the following command:

ssh -i private_key root@IP_ADDRESS

where you replace “private_key” with the path to your private key file and “IP_ADDRESS” with the correct IP
address for your virtual machine. I will distribute IP addresses and private keys using Slack, so be sure to check
your slack channel for these credentials.

You can save yourself a bit of hassle by adding a section to your ~/.ssh/config file that looks something like
this:

Host vm
User root
Hostname IP_ADDRESS
StrictHostKeyChecking no
IdentityFile PATH_TO_PRIVATE_KEY

Replace IP_ADDRESS with the IP address of your virtual machine and PATH_TO_PRIVATE_KEY with the
correct path and filename. If you save and quit, you should be able to just type:

ssh vm

And log into your system automatically.


Step 1. Installing Linux

Right now, your VM is running off a live disk image of the Arch Linux installer. All the files and services on
this disk are temporary – every time the machine reboots, they will be deleted. To make permanent changes,
you need to install Linux to the virtual “hard drive” I have provisioned to your machine.

Follow the installation instructions at https://wiki.archlinux.org/index.php/installation_guide to install and


configure a complete working Linux system. Since we are installed in a virtual private server, some of the steps
have been already done for you. For example, you do not need to download an .iso image and burn it on to
installation media.

I recommend starting somewhere near the section that begins “Update the system clock”.

Make sure that your installation process includes setting up an SSH server (such as openssh) so that you can get
back in to your system once you reboot! That means both installing it and configuring it to start at boot time!

Among other tasks, this guide will teach you how to:

1. Partition the disk drive into several partitions.


2. Format the partitions by creating filesystems on them.
3. Install software packages using the archlinux bootstrap script and the “pacman” package manager.
4. Configure networking to use DHCP for automatic configuration on the computer science network.
5. Configure services to start using the “systemctl” command and systemd init script system.
6. Create user accounts.

Set the root password to “CMSC240” and create a non-administrative account named “student” with password
“Stevens118”.

7. Configure a boot loader that can launch the operating system when it reboots.

Note: You may use ANY online or print resources to accomplish this task. You may watch videos, read web
sites, ask questions on IRC or Slack, post questions in the Archlinux Facebook page (please follow proper
netiquette when interacting with busy professionals and community members) and talk with each other about
what works and what doesn’t.

Researching how to do these kinds of tasks is a system administrator’s MOST important skill. Learning how to
learn new systems and tasks is more important than almost anything else we do in this class.

Step 2. Installing and configuring virtual servers

Install and configure the following open-source multiplayer games. Set them up to run in “dedicated server”
mode and test that you can connect to them from the systems in the Advanced Computing Lab.

Your servers must all survive a reboot of the system. Within a few minutes of rebooting, I should be able to log
in with any of the game clients and connect to a game.

Note: You may NOT use LinuxGSM or other “Game Server Managers” that automate all of these tasks for you.
However, you MAY use Docker, Flatpak, AppImage, and Systemd unit files.
OpenTTD

OpenTTD is an open source game of the 90s smash hit “Transport Tycoon Deluxe” (the prequel to
“Rollercoaster Tycoon”). OpenTTD is a simulation game that allows players to build complex transport
systems that deliver goods from producing industries to consuming industries in an attempt to maximize profit.
In addition to single player mode, OpenTTD allows you to create multiplayer games.
There are several ways to create a dedicated OpenTTD server, some of which are described here:

https://wiki.openttd.org/Dedicated_server

Note: Using the docker container may be the best way to set this up and make sure it comes up on boot.
However, it requires some custom VM settings that may or may not be enabled. You may find that creating a
custom systemd script is easier:

http://code-faff.blogspot.com/2017/12/openttd-under-systemd.html

A slightly easier to follow guide is here:

https://dev.to/mrsoundso/setting-up-a-openttd-server-2ie9

but it assume you are using Debian or Ubuntu, not Arch Linux, so you will have to adapt the instructions to
work on your VM.

Armagetron Advanced

Armagetron is an open-source clone of the “light cycles” game from the movie 1982 Disney movie “Tron”. It
supports multi-player play over the network.

The official web site is at:

https://www.armagetronad.org/

Wesnoth

Wesnoth is an open-source turn-based strategy game with an enormous cult following. It has fantastic graphics,
several excellently scripted campaigns, and an extremely well balanced combat mechanic. Wesnoth supports
multiplayer servers that, by default, run on port 15000. You can set up a dedicated headless server using the
“wesnothd” service.

See https://wiki.wesnoth.org/MultiplayerServers for more information.

Bzflag

Bzflag is a tank-based first-person shooter with some unique game dynamics. The graphics are a bit dated, but
it has excellent playability and replay value. It also comes bundled with “bzfs” a dedicated server. You can
download bzflag from its web site:

https://www.bzflag.org/

or (better) using pacman.

Minetest
Minetest is an open-source voxel game engine that, like Minecraft, is loosely based on Infiniminer. Players can
mine different resources, craft items, and interact with MOBs and other players. However, the Minetest engine
is designed to be a flexible platform that can also serve other voxel-based games. It has an extensive player
community that develops mods (mostly in Lua) and contributes new content including gameplay enhancements
and texture packs.

The Minetest wiki (https://wiki.minetest.net/Setting_up_a_server) has good instructions for setting up a


dedicated minetest server. Keep in mind that you only need to allow access from the workstations in the
Advanced Computing Lab. You don’t need (or want) to allow external access. In fact, granting external access
has security implications, so it’s not a good idea.

Step 3. [Optional] For an extra slip day, try to also get one of the following games working in headless mode:

freecol
hedgewars
megaglest

This slip day can only be earned if you are ALSO successful at getting ALL the game servers from step 2
working.

Step 4. Setting up a web site

Now install and configure an Apache web server. It should run on the default ports (port 80 and 443) and serve
a single web page that displays a list of the games available on your system and instructions for connecting to
them.

Hint: The default web page for apache is usually located at:

/var/www/localhost/htdocs/index.html

You don’t need to know any HTML to replace the contents of this file with simple text (though feel free to show
off if you have some web programming skills).

Submitting

Instead of submitting this project, I will have you do an in-class demo showing that you were able to get all the
parts working correctly.

Note about Megaglest

Megaglest is an open-source real-time strategy game with a heavy combat focus and a complex system of
factions with different advantages and buildings. Since version 3.6.0, it has supported a “headless server” mode
that can be used to install a dedicated server. There is good information about that here:

https://docs.megaglest.org/MG/Dedicated_Server

Past student have struggled to get this one working. You may want to skip it and move on to others.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy