If you can see this check that
This page discusses the technical aspects of the linuxzoo site. It is partially a guide to people simply interested in how the site works.
This site was designed to provide virtual computing resources to people interested in learning about operating systems. It uses a number of servers to supply virtual machines on demand to users, and can be completely controlled via a normal web browser over an internet connection. First set up in August 2004, it is probably one of the first cloud-based virtual systems to be built.
In parallel to the virtual machine platform, it has a tutorial environment integrated within it. The tutorials ask questions, then offer "check" buttons which log into your virtual machine and see if you have answered the questions. In this way you can run a practical lab and give learners immediate and automated feedback on their progress.
As the site is geared to learners, it is not designed to just offer general virtual machines for regular computing purposes. Firstly, the machines are sandboxed from the internet, so no outgoing traffic is supported. Secondly the machines only stay running when you are logged into them and logged into linuxzoo. If the system thinks you are not interacting with a machine it will be closed down. This saves on resources, and thus cost.
Originally the virtualised machines offered ran only using a Linux virtualisation system known as User Mode Linux. However since then the virtualisation world has moved on, and many virtual platforms are now available. Linuxzoo has also been updated, and now runs a large variety of backends, including kvm/qemu. The site was originally written in Perl using CGI, but in 2025 refactoring was started replatforming the system in Python and Jinja using WSGI.
When a user books and runs a virtual computer, that machine is known as a GUEST. The guest runs on one of a number of backend servers, which are known as SERVER NODES. This is all co-ordinated from a frontend server known as the GATEWAY.
The gateway server just handles management and communications. Server nodes are linked together using a virtual network build using tunneling software or private routers. Each guest is controlled by a daemon, which starts up and stops the guests on that node. Each time you connect to the server, it speaks to your node daemon, and controls you guest remotely.
The guest machines each seem to have disk space to run from, but actually this is just some special files in the node. The daemon sets these files up for you, and deletes them as and when required. In this way you can start with a freshly-installed system at the touch of a button, which is perfect for system administration tutorials where it is all to easy to mess your system up!
The nice thing about this architecture is the reliability and self-managing factors which is has. Machines can go down, guest or node machines can crash, networks can fail, but the system (should) regenerate itself quickly. It is self monitoring, and problems can usually be detected within a minute and corrective action completed within 3 minutes. If things get really bad nodes become isolated from the network, and the affected users are requeued for the next available guest on a different node.
The architecture was designed to be scalable. As of 2025 we have 7 active server nodes, each with 192GB of RAM and 1TB of disk. The system is modelled on supporting around a maximum of 140 users at a time.
The site was designed with security in mind. Typically in cloud computing systems there is a high degree of trust in the operator of each virtual machine. The operator's identity is known, and has been validated using their payment method. In this site virtual machines can be booked by anyone, without validation, so great care has been taken to avoid malicious users causing problems. Free users are basically sandboxed to the virtual network.
The site is currently based at Edinburgh Napier University. Here we have two hardware firewalls between us and the real world. One of these firewalls has full packet logging which gives us perfect network logging. On the gateway we also have significant logging capabilities. The gateway logs are sufficient to link a user's IP with any network action which leaves or enters the gateway. If a user tries to hide the browser IP, then the system will not recognise that user when they try to log into their machine. The system will also handle NAT firewall users, although when multiple users connect from a single NAT trackability is reduced slightly under some circumstances. We also track web server requests and login requests. These logs are processed automatically and are accessible by the user in question through their login.
Plans for the future
Having a disaster
Centos 7 intro | Paths | BasicShell | Search |
Linux tutorials | intro1 | intro2 | wildcard | permission | pipe | vi | essential | admin | net | SELinux1 | SELinux2 | fwall | DNS | diag | Apache1 | Apache2 | log | Mail |
Caine 10.0 | Essentials | Basic | Search | Acquisition | SysIntro | grep | MBR | GPT | FAT | NTFS | FRMeta | FRTools | Browser | Mock Exam |
Caine 13.0 | Essentials | Basic | Search | |
Kali 2020-4 | 1a | 1b | 1c | 2 | 3 | 4a | 4b | 5 | 6 | 7 | 8a | 8b | 9 | 10 |
Kali 2024-4 | 1a | 1b | 1c | 2 | 3 | 4a | 4b | 5 | 6 | 7 | 8a | 8b | 9 | 10 |
Useful | Privacy Policy | Terms and Conditions |
Linuxzoo created by Gordon Russell.
@ Copyright 2004-2025 Edinburgh Napier University