This document describes a senior project submitted by Wongsarun Chatamornwong and Ronnakrit Kunaviriyasiri to Mahidol University International College in partial fulfillment of a Bachelor of Science degree in Computer Science. The project, called Meka Code, aims to develop an online integrated development environment (IDE) that allows instructors and students to have a shared coding environment and tools. Key features of Meka Code include providing Linux containers to users, a graphical user interface within containers, and functionality for instructors to create courses and assign work and for students to enroll in courses and submit assignments.

1. Online Integrated Development Environment for multiple users
WONGSARUN CHATAMORNWONG
RONNAKRIT KUNAVIRIYASIRI
A SENIOR PROJECT SUBMITTED IN PARTIAL
FULFILLMENT OF THE REQUIREMENT FOR THE DEGREE
OF BACHELOR OF SCIENCE (COMPUTER SCIENCE)
MAHIDOL UNIVERSITY INTERNATIONAL COLLEGE
MAHIDOL UNIVERSITY
2014
COPYRIGHT OF MAHIDOL UNIVERSITY

2. Senior Project
entitled
Online Integrated Development Environment for multiple users
was submitted to the Mahidol University International College, Mahidol University
for the degree of Bachelor of Science (Computer Science)
on
December 12, 2014
.................................................................
Wongsarun Chatamornwong
Candidate
.................................................................
Ronnakrit Kunaviriyasiri
Candidate
.................................................................
Boonyanit Mathayomchan, Ph.D.
Advisor
.................................................................
Kanat Tangwongsan, Ph.D.
Advisor
.................................................................
Assoc. Prof. Saovanee Chancharoensin,
Ph.D.
Chair of Science Division
Mahidol University International College
Mahidol University
.................................................................
Boonyanit Mathayomchan, Ph.D.
Program Director
Bachelor of Science in Computer Science
Mahidol University International College
Mahidol University

3. Abstract
This project; Meka Code; is a cloud Integrated Development Environment
(IDE) that is especially designed to be used in programming classes. Meka Code al-
lows instructors and students to have the same working environment and tools, which
allow them to focus more on the class contents and spend less time configuring tools or
troubleshooting students’ machines. Meka Code provides users with Linux containers,
which acts like a standard Linux installation but without the need for a separate kernel.
Inside the containers, users will be provided with Graphical User Interface (GUI) that
includes a code editor, a terminal, and a GUI directory tree. Additionally, instructors in
the system can create courses and assign works to each courses they created. Students
can enroll any courses and submit works to the courses they have enrolled. The system
allows users to access their work anywhere on any platform, users just need an access to
the Internet and web browser.

4. Acknowledgement
We would like to thank Dr. Boonyanit Mathayomchan and Dr. Kanat Tang-
wongsan, our project advisors, for their support in this thesis process.
In addition, a thank you to Dr. Piti Ongmongkolkul and Mr. Pawit Khid-arn
for suggestions and guidance throughout the project.
Lastly, we would like to thank all of those who supported us during the
project.
Wongsarun Chatamornwong
& Ronnakrit Kunaviriyasiri
ii

5. Contents
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Project Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Development Process and Project Schedule . . . . . . . . . . . . . . . 2
2 Literature Review 5
2.1 Other online Integrated Development Environment . . . . . . . . . . . 5
2.2 Codeacademy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 System Analysis and Design 7
3.1 Architecture Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1 Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Design of Server Side . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.4 Failure Handling . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.5 Ruby on Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Design of Node.js application . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
iii

6. 3.3.2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4 Design of Ruby on Rails Client Side . . . . . . . . . . . . . . . . . . . 17
3.4.1 User pages work flow . . . . . . . . . . . . . . . . . . . . . . 19
3.4.2 GUI Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4 System Implementation 24
4.1 Front End Implementation . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.1 Ruby on Rails UI . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.2 IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Back End Implementation . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1 Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.2 Bash Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.3 Container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.4 Redis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.5 Rails API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.6 Nginx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5 Testing 56
5.1 UI Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6 Summary 58
6.1 Future Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.1.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.1.2 System Admin . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.1.3 Mailing System . . . . . . . . . . . . . . . . . . . . . . . . . . 58
iv

7. 6.1.4 Course Status . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.1.5 Access container from other client . . . . . . . . . . . . . . . . 59
6.1.6 Different platform containers . . . . . . . . . . . . . . . . . . . 60
Appendices 62
A Course table 63
B Hand In Work table 64
C Hand In Work Question table 65
D Public Key table 66
E User table 67
F User Enroll table 69
G Container table 70
H Work table 71
v

8. List of Figures
1.1 Project development process. . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Overall architecture of server side. . . . . . . . . . . . . . . . . . . . . 8
3.2 Example of routing from outside source. . . . . . . . . . . . . . . . . . 9
3.3 Internal routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 LXC network diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5 This is the diagram of how Amazon EC2 worked and how to scale up
Meka Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.6 Class and ER diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.7 System use case diagram. . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.8 Creating new IDE container. . . . . . . . . . . . . . . . . . . . . . . . 19
3.9 Downloading student work. . . . . . . . . . . . . . . . . . . . . . . . . 20
3.10 Enroll into course. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.11 Submitting work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.12 IDE layout design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1 Log in process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Start and shut down container . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Adding public key to be able to SSH to the environment with their own
devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4 List of public keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.5 Creating new course. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
vi

9. 4.6 Managing course. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.7 Instructors can download individual student work and download all stu-
dent works. They can also update the score on this page. . . . . . . . . 30
4.8 Enroll courses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.9 Selecting file to submit for assignment question. . . . . . . . . . . . . . 32
4.10 JSON returned from file content request. . . . . . . . . . . . . . . . . . 32
4.11 The students can re-submit their works as many time as they want. . . . 33
4.12 Example of IDE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.13 Changing syntax of the editor . . . . . . . . . . . . . . . . . . . . . . . 36
4.14 Changing theme of the editor . . . . . . . . . . . . . . . . . . . . . . . 37
4.15 Example of returned JSON. . . . . . . . . . . . . . . . . . . . . . . . . 38
4.16 Right click on the tree node will show a context menu with pre-defined
options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.17 Switching directory tree left/right . . . . . . . . . . . . . . . . . . . . . 40
4.18 Renaming file or folder . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.19 Deleting file or folder . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.20 Download file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.21 Example of network interface setup for bridging. . . . . . . . . . . . . 45
4.22 This is the example of port forwarding with bash script. . . . . . . . . . 46
4.23 Example of addsshrule command. . . . . . . . . . . . . . . . . . . . . 46
4.24 Example of removing rule. . . . . . . . . . . . . . . . . . . . . . . . . 47
4.25 Rulelist result example. . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.26 Result of lxc-info -n container-name . . . . . . . . . . . . . . . . . . . 49
4.27 Example of user.json . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
vii

10. 5.1 Example of input form for creating a new work. . . . . . . . . . . . . . 56
5.2 Warning the user before deleting. . . . . . . . . . . . . . . . . . . . . . 57
5.3 Save button is not clickable. . . . . . . . . . . . . . . . . . . . . . . . 57
6.1 An idea of possible expansion. . . . . . . . . . . . . . . . . . . . . . . 59
viii

11. List of Example Codes
4.1 Change the config file of the main container with bridge network that
was set in the previous step. This config file will be in .local/share/lxc/-
containername/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2 Setting up the network interface in the main container. . . . . . . . . . 45
4.3 This is the command that needed to be called in order to bind Node.js port. 46
4.4 This is the command that needed to be called in order to bind SSH port. 46
4.5 Bash example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.6 Bash example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.7 Listing all rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.8 Example of creating container. . . . . . . . . . . . . . . . . . . . . . . 48
4.9 Starting container. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.10 Shutdown container. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.11 Example of system admin’s commands. . . . . . . . . . . . . . . . . . 49
4.12 Steps for unprivileged container. . . . . . . . . . . . . . . . . . . . . . 50
4.13 Creating and adding default config to container. . . . . . . . . . . . . . 50
4.14 Located at /etc/lxc/lxc-usernet . . . . . . . . . . . . . . . . . . . . . . 50
4.15 Create template container. . . . . . . . . . . . . . . . . . . . . . . . . 50
4.16 Location of upstart file in containers and log file. . . . . . . . . . . . . 51
4.17 All commands for app-starter. . . . . . . . . . . . . . . . . . . . . . . 51
4.18 User information location. . . . . . . . . . . . . . . . . . . . . . . . . 51
4.19 Installation steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
ix

12. 4.20 These are all API that can be called via get request. . . . . . . . . . . . 53
x

13. Chapter 1
INTRODUCTION
More people are interested in programming around the world. However,
some may not know where to start since the learning curve of computer programming is
quite high. There are not many tools that allow them to start coding right away without
the installation and configuration, which can be very complicated. There are tools such
as Nitrous.io, a website that allows users to create their own Integrated Development
Environment (IDE), but there are still some functions that can be specifically added for
instructor and student use.
Meka Code is a website that allows instructors and students to register and
create their own IDE. Instructors can create a course and let students enroll into the
course. The students who are enrolled into courses can see the assignments of those
courses the instructors created. Students can choose files from their cloud IDE or upload
files from their own computer to submit the assignments. Instructor of that course can
then download the submitted assignments into his computer for testing and grading.
Meka Code provides a code editor, a GUI directory tree that shows the files
in the server, and a terminal. Users can write their code and save their code on the cloud.
They can also download the files into their own computer.
1.1 Motivation
• Coding skill is very important in the future but there are not many tools that allow
the beginner start right away without spending a lot of time with configurations.
• There are many online IDEs but none those online IDEs have specific functions
for instructors and students.
• To gain knowledge of networking and multilayer architecture within the Internet.
• To gain knowledge on server and Virtual Machine management.
1

14. 1.2 Objectives
• To provide an environment that people can start coding without having to deal
with tool installation and configuration.
• To provide functions that allow students to submit their code in the IDE for as-
signments.
• To provide functions that allow instructors to download and grade the students’
submitted code for each assignment.
1.3 Project Scope
Meka Code is a online IDE that allows beginners to start learning to code
easily without having to install tools on their computers. Meka Code is not meant for
production projects that require higher performance computers. There are two types of
user, instructors and students. Both types of users have identical IDE functions. Instruc-
tors can create courses and course works for students to enroll and submit their works.
Students can search and enroll into any course. They can also submit their code from the
IDE or their own computer for each course work.
1.4 Development Process and Project Schedule
The development process of Meka Code project, as shown in figure 1.1,
started with analysis phase where we started to research libraries and tools to fit for
this project. First of all, we decided to use Vagrant (virtual development environment)
to manage virtual machines with VirtualBox for each user to interact with. However,
Vagrant did not go that well since Vagrant creates a separate system of virtual machine
that requires great amount of memory and great amount of time to run Vagrant. We
decided later on that Vagrant is not suitable and too slow for this project, so we continued
researching until we found LXC (Linux Container) and that took us one to one and half
month.
The design phase included IDE UI design, Network design, Ruby on Rails
design, and architecture design. The design phase is difficult phrase where the design
2

15. is not fix for each part and we had to redo many times to get the right design. The
architecture is the most difficult design, we spent so much time on this part to make this
project work. We also make some changes over the implementation period in order to
fix unforeseeable factors. However, we spent time on this phrase the least time since the
design needed to adapt over time.
The implementation phase included, Linux configuration, LXC setup, Node.js
and IDE page, Rails project, authentication part, and server installation. We divided into
two parts in order to work as fast as we can to finish this project. For configuration, we
tried to use tools to accomplish this project, such as Dnsmasq and iptables. Dnsmasq
”provides network infrastructure for small networks”.[4] Iptables is ”a firewall, installed
by default on all official Ubuntu distributions”.[6] We spent a lot of time on Node.js
since Node.js was very new to us, and we needed to studied how to use libraries to cope
with Meka Code. Ruby on Rails part was quite quick since we are used to Ruby on Rails.
Integration part was not that hard due to the fact that Nginx and Node.js were very easy
to deploy with ruby gems and libraries that are provided. Authentication was also easy
since Redis provided us all the components to be in this project. Redis is a good open
source for checking cookie and authenticating token keys between servers.[9]
The testing phase was quite difficult because we ran out of time and we did
not have enough time to do the unit testing. In addition, we spent most of our time
checking whether the system contains bug or not. We spent five weeks to polish our
project and finalized Meka Code to meet our objective.
3

16. Figure 1.1: Project development process.
4

17. Chapter 2
LITERATURE REVIEW
2.1 Other online Integrated Development Environment
There are two popular online IDEs, which are Nitrous.io and Cloud9. Ni-
trous.io is a online IDE that provides users with a free working environment with options
to purchase multiple working environment.[8] In Nitrous.io, there is a collaboration func-
tion for the users that let multiple users edit the same file in one of the provided work-
ing environment. Cloud9 is another website that provides working environment in the
cloud.[1] Cloud9 also provides collaboration mode for the users to maximize the ben-
efits of working on the cloud. Furthermore, Cloud9 allow users to have more freedom
in the environment, including super user permission. Users can also purchase upgrades
to increase the performance of each environment. The main difference between the two
online IDEs and Meka Code is that Meka Code doesn’t focus purely on providing IDE
for the users but Meka Code also focus on extra functions for specific users such as
instructors can create courses and assign works to each course, while the students can
enroll courses and submit works that were assigned to the particular course.
2.2 Codeacademy
Codeacademy is a website that gives coding classes to users.[2] Codeacademy
also provides slides and videos that contain steps to begin coding. Codeacedemy teaches
up to 6 languages, which are Python, PHP, jQuery, JavaScript, Ruby, HTML, and CSS.
Codeacademy also provides users with a compiler for each exercise but the compiler will
only run the valid code, unlike those provided by Nitrous.io and Cloud9. The purpose
of Codeacademy is very similar to Meka Code that both system was made for educa-
tional purpose. However, the two systems have very different approach. Meka Code
provides users with a working environment, where the users can create and run codes
like in a any environment. Meka Code also provides specific functions such as assign-
5

18. ing works and submitting works for instructors and students. Meka Code educational
contents rely purely on instructors of each courses. On the other hand, Codeacademy
focuses on giving digital classes to the users and let them do exercises in a very limiting
environment.
6

19. Chapter 3
SYSTEM ANALYSIS AND DESIGN
3.1 Architecture Design
3.1.1 Infrastructure
This project architecture is designed to be flexible and reusable. Meka Code
is designed to have multilayer, such as client layer, API layer, security layer, and con-
tainer layer. There will be Node.js running inside each container, and users will be
authorized using cookies from security layer which is Redis server. Client server will be
using Devise that is one of the Ruby gems to authenticate users, and Devise will keep
login session as cookies inside users’ computer. Client server will communicate directly
to the API server since API server will be used internally. API server is used to provide
RESTful API so this server is easiest to manage these API calls in one place.
7

20. Figure 3.1: Overall architecture of server side.
8

21. 3.2 Design of Server Side
3.2.1 Networking
Figure 3.2: Example of routing from outside source.
User can connect to server by sending HTTP request to the server URL, i.e.,
www.mekacode.com:11764. Domain Name System (DNS) will redirect mekacode.com
to public IP address of host1. User will be able to connect to his/her allocated container
through a specific port, such as port 11764, given to the user as shown in figure 3.2. The
router will forward all ports to host1 if there is router between host1 and the Internet,
i.e, host1:11764, and user will be able to access container through host1. Host1 will
map and forward port 11764 to container IP address which is 192.168.100.16 oh port
8080 using iptables. The advantage of this design is that host1 will be able to keep log
of the network so that every move of users will be kept in a log file for the purpose of
debugging later on.
9

22. Figure 3.3: Internal routing
Internal network will need the host that binds port to container in order to
access to specific container. Each container will have internal IP address that is provided
by Dynamic Host Configuration Protocol (DHCP) in order to communicate with other
containers. This internal IP address can be used to study networking, sending file, FTP,
or SSH, etc.
10

23. LXC Networking
Figure 3.4: LXC network diagram.
According to LXC system, c1 is a container that connects to bridge network,
bridging is an action that links two or more network together in order to work as one,
which is br0 as shown in figure 3.4. Bridging will help c1 to route the data package
through subnetwork 192.168.100.0/24 in order to communicate to the Internet. LXC
will automatically generate IP address of c1 and also create a bridge with Ethernet. The
default bridhe of LXC is called lxcbr0.[7]
3.2.2 Security
Security is a big issue in this project where users have their own environment
in the host system. If the security is easily compromised, the hole of security might cause
the system to be taken down by hackers. This project security will divided into two parts:
server side security and client side security.
11

24. Client side
Client side security depends on Ruby on Rails most of time since Ruby on
Rails will be the first door to interact with the server. Ruby on Rails is already very
secure with the strong parameter, sanitized string, and active record. However, the main
authentication in order to see which user is allowed is Devise authentication.[3] Devise
authentication is mainly focused on user authentication with encrypted password and
email, and Devise will keep hashed password and email in the cookies so that autho-
rized users do not need to do authentication again. Additionally, Nginx will limit Ruby
on Rails resource so hackers could not do much if they can access the server through
Ruby on Rails. The resource that Nginx limited could be amount of process, amount
of memory, or user permission. The next challenge is Node.js security because Node.js
interacts with the kernel directly through tty.js which is web-based terminal emulator.
Node.js is needed to be careful of file permission setting so user cannot do anything that
involved with changing the system config or changing file permission. The system will
be disaster to let user has permission in order to grant higher access that might increase
security holes.
Server side
Server side security will be based on file permission and operating system.
This project has to strictly grant file permission only if the user really need this file
permission. Also, the operating system has to be regularly updated to the latest version
in order to prevent issues that might compromise the system.
3.2.3 Scalability
There are many ways to scale up this project. As shown in figure 3.5, one is
to use Amazon EC2. Amazon EC2 is an elastic web-scale computing which is used to
scale up a project. There will be multiple servers which contain unique public IP address
where Amazon EC2 will distribute equally to those servers. Amazon EC2 will bind with
the main domain with is mekacode.com. If user requested to mekacode.com, The request
will direct to Amazon EC2, and Amazon EC2 will send the request to one of the servers
that has least work or closest server at that time. Amazon EC2 might not be the best way
to scale up this way for this project. However, this is definitely one of the easiest way to
12

25. scale up this project, Meka Code.
Figure 3.5: This is the diagram of how Amazon EC2 worked and how to scale up Meka
Code.
3.2.4 Failure Handling
Failure handling will be done by Nginx since Nginx is widely used in mant
websites, and Nginx is very good at handling failure, and the error will be logged into the
log file. For container, Node.js will restart server again after Node.js stopped. Never-
theless, if container crashed, user or system admin will need to restart container by shut
the server down and restart the container. Rails API server uses Thin as web server. As
of right now, there is no failure handling in case of server down yet. There could be a
system admin pages in the future where the admin could handle the failure properly in
each layer.
3.2.5 Ruby on Rails
We designed the database in the way that Meka Code will be easy to scale.
The main table is User table which contains all the information of the user. There are
two types of Users, instructor, and student. The next table is Container table, which
contains information of the containers such as status and URL. All User objects can
13

26. have as many Container objects as they want. Another table is Public Key table. Public
Key table stores the SSH keys of the user’s computers. In addition, User Enroll table
belongs to User objects who are student. User Enroll table links student User objects
to Course objects they enrolled. Moreover, Course table will store information of the
course and also belongs to User objects that are instructor. Users who are instructors
can have many courses. Additionally, Work table belongs to Course object. Work table
contains information of each work of the course. Hand In Work table is the table that
contain information of each student works. Hand In Work table belongs to User objects,
which are student, and Work objects. Each Work object can have many Hand In Work
objects as each Work object depends on the number of students who have enrolled into
the course. Hand In Work Question table is where the file submitted by students is stored
in text form. Hand In Work Question object belongs to Hand In Work object. Hand
In Work object can have as many Hand In Work Question objects as the instructors
specified to the Work object.
14

27. Figure 3.6: Class and ER diagram.
3.3 Design of Node.js application
The Node.js application is the part that provides the IDE inside each con-
tainer. Each container will have a Node.js server running in the background using Up-
15

28. start.
3.3.1 Server
The server provides the IDE page and all the required data for the GUI di-
rectory tree in form of JSON. In the server, there will be a terminal running inside the
server background that will do any actions on the terminal emulator to the container. The
server also provides the data of all files inside the containers. The data will be requested
by the Ruby on Rails client server once the user who own the container wants to use the
files inside his container for assignment submission. File manipulations such as reading,
writing, editing, and deleting are also done by the server when the client side requested.
3.3.2 Client
The client side will provide users with an javascript editor, a GUI directory
tree, and a terminal emulator.
Editor
The editor uses a Javascipt plugin called Ace. Ace provides users the ability
to type in their codes the same way as any editor, such as syntax highlighting and tabbing.
Users can also change theme of the editor to the one they preferred. Initially, the syntax
is set to Python as Python is the language currently used in ICCS101 course. When the
user save the file and type in the file name with its extension, the syntax of the editor will
change according to inserted extension of file name. Furthermore, the client will send
the data in the file and file name to the server in order to create a new file ora override
the existing file.
GUI directory tree
The GUI directory tree uses a Javascript plugin, called FancyTree. Fan-
cyTree will constructs a GUI directory tree from JSON provided by the server. The tree
will show all files and directories in the user’s container. User can create a new direc-
tory, rename files and directories, download files, and delete files and directories using
16

29. the tree.
Terminal emulator
The IDE page also provides a terminal emulator that uses tty.js for users to
run codes and do anything in the container as users own computer. Once the terminal on
the IDE page is selected and the user type something, the events of every keys pressed
will be stream to the server through the socket that was established when the terminal
was initialized, and the output will be streamed back to the client.
3.4 Design of Ruby on Rails Client Side
There are two types of user in the system which are students and instruc-
tors. Both students and instructors can create and terminate their own IDE containers.
Users can add and manage their SSH keys that are used for SSH directly from their own
computer.
Instructors can create and manage courses of their own. They can create
and manage work for the course. After a student has submitted his work, the instructor
could download the submitted files to check on his computer. The instructors can also
un-enroll students from their course.
Students can enroll courses that were created by any instructor. Students
need to search course with course name or course code before enroll a particular course.
Students can also withdraw themselves if students no longer need to see information and
works of the course. Students can submit files for each course work by uploading from
students’ computer or from their containers.
17

30. Figure 3.7: System use case diagram.
18

31. 3.4.1 User pages work flow
User pages are provided using Rails. These pages are where users can create
and manage their IDE containers and public keys. Instructors can create and manage
courses. Students can enroll course and submit course works.
Managing containers
All users can create and manage IDE containers of their own. All processes
are straight forward, just one click and the system will show whether the process is suc-
cessful or not. Only creating container requires user to fill in the name of the container.
The steps of creating new container is shown in figure 3.8.
Figure 3.8: Creating new IDE container.
19

32. Instructors
Instructors can create new course and add work toto allow student of that
course to submit their work. Instructor can un-enroll students, who accidentally join the
course. After the students had submitted their work, the instructor could download the
work to their own computer. The steps of downloading files is shown in figure 3.9.
Figure 3.9: Downloading student work.
20

33. Students
Students can search for courses and enroll into course. After they had en-
rolled into a course, they could submit their work to each course work. The steps of
enroll into a class is shown in figure 3.10 and 3.11.
Figure 3.10: Enroll into course.
21

34. Figure 3.11: Submitting work.
22

35. 3.4.2 GUI Design
There are three main parts in the IDE page. In the middle, there is a code
editor which will be the main part of the IDE page, and the size of the editor is according
to the users’ browser window size. Next to the editor, there is a directory tree that shows
the list of files in the container. The directory tree simulates all the directories and files
into a GUI that is similar to file browsers that most users will be familiar with. At the
bottom, there is a terminal emulator that has the same width with the browser window
size to maximize the line length, so most of the command can fit into a single line.
Directory tree has a fixed width and terminal has fixed height. All the remaining spaces
will be taken by the editor. A rough layout of the IDE page is shown in figure 3.12
Figure 3.12: IDE layout design.
23

36. Chapter 4
SYSTEM IMPLEMENTATION
4.1 Front End Implementation
4.1.1 Ruby on Rails UI
User page is generated by Ruby on Rails. Once users enter the website, they
will see login page if they are not log in to the system. Login page is shown in figure
4.1a. After login, users will see the page that lists all of their IDE containers as shown
in figure 4.1b. Every user can create as many containers as they want, and can be started
and shutted down independently. The process of start and shut down a container is shown
in figure 4.2. If the users prefer to access the terminal by SSH from their own computer,
they can add SSH key to the system (figure 4.3) and SSH to the system by using the user
and SSH link of the container. Users can add as many devices as they want and the list
of devices’ public key will be shown in public keys page as shown in figure 4.4.
24

37. (a) Log in page.
(b) Successfully signed in.
Figure 4.1: Log in process
25

38. (a) Starting container.
(b) Shutting down container.
Figure 4.2: Start and shut down container
26

39. Figure 4.3: Adding public key to be able to SSH to the environment with their own
devices.
Figure 4.4: List of public keys.
27

40. Instructor
Instructors can create new courses for students to enroll and submit their
work as shown in figure 4.5. They can manage courses that they created (figure 4.6).
Each course can have many assignments or course works. After the students had up-
loaded their work, the instructor could choose to download the work of individual stu-
dent or the work of all students into a zip file (figure 4.7). Instructors can update the
score of each student work by clicking on the score on the table on the same page.
Figure 4.5: Creating new course.
28

41. (a) Drop down course listing for quick access.
(b) Detailed list of manageable courses with available options.
(c) Managing options in course info page.
Figure 4.6: Managing course.
29

42. Figure 4.7: Instructors can download individual student work and download all student
works. They can also update the score on this page.
Student
Students can enroll any courses they want and see all the assignments of
that course (figure 4.8), but the instructor of the course can un-enroll them any time.
To submit work to each assignment, the users can choose the file from their containers
or upload the file from their computer. If the user choose file from his container, the
Javascript will request to the Node.js server of the container for the content of the file.
The cookies called _validation_token_key and file path will be attached to the request
for checking authorization and specifying path. The returned JSON will be as shown in
figure 4.10. The JSON contain string data of the file. Once the use click submit, the
string data will be saved into the database as content of the file. Users can resubmit their
works as many times as they want (figure 4.11), but only the latest file will be kept.
30

43. (a) Students can search and enroll into any courses.
(b) Students can see the course information and all assignments. If they enrolled into the wrong
course, they could withdraw from the course.
Figure 4.8: Enroll courses.
31

44. (a) Choosing file from containers to submit for the question.
(b) Upload files from computer for the question.
Figure 4.9: Selecting file to submit for assignment question.
(a) Example of successful request.
(b) Example of fail request.
Figure 4.10: JSON returned from file content request.
32

45. Figure 4.11: The students can re-submit their works as many time as they want.
33

46. 4.1.2 IDE
The IDE page is motivated by Nitrous.io as the tool that is currently used in
current ICCS100 and ICCS101 classes, which most users have already got familiar with
Nitrous.io. The IDE page includes a code editor, a GUI directory tree of all the files in
their containers, and a terminal emulator as shown in figure 4.12. The only way users
can access this page is through the user page meaning they would need to log in to the
system first. If anyone try to access this container IDE without the cookies generated by
Ruby on Rails, they wouldn’t be able to use the IDE of this container, and they will be
redirected back to the home page.
Figure 4.12: Example of IDE.
Editor
Users can type in their codes onto the editor. The editor can be opened in
multiple tabs. At the top of screen will be a menu bar that included Save, Save As, and
View button. Save button will be deactivated when the current editor tab is a new file.
Save button will be activated again when a file was opened from the directory tree. Also,
the user could press Save button or ctrl/cmd + S to save the updated content to the existing
file. If the content in the current tab was newly typed into the new tab or the user would
like save the old content into a new file in different path, user would need to press Save
34

47. As button and a modal will appear for the user to type in the path and file name that they
want. Saved files and directories in the container will be shown in the GUI directory tree
next to the editor. The view button will allow user to change the syntax and theme of the
current editor tab. The syntax highlighting of the editor can be changed. An example of
different syntax highlighting is shown in figure 4.13. The theme changing is shown in
figure 4.14.
35

48. (a) Python syntax.
(b) Ruby syntax.
Figure 4.13: Changing syntax of the editor
36

49. (a) Default theme of the editor.
(b) Set new theme as text mate.
Figure 4.14: Changing theme of the editor
37

50. GUI directory tree
The GUI directory tree is generated by JSON provided by the Node.js server.
The request will attach the cookies called validation_token_key with this key so the
server can check the authorization of that request. The returned JSON is shown in the
figure 4.15. By default, the tree will be placed at the right of the editor. In addition,
users can choose whether they want to put the directory tree on the left or right of the
editor by using the ↔ button on top of the tree as shown in figure 4.17. To open files
that is in the server, the user simply need to double click on the file name, and the file
will appear as new tab on the editor. As shown in figure 4.16, there will be many options
available for users when they right click on a node in the directory tree including rename,
delete, download, and new file and folder. Figure 4.18 shows the steps of renaming file
or folder. Deleting file or folder process is shown in figure 4.19. Only empty folders can
be deleted. If the user want to delete the directory, they will need to delete all the files in
that directory first, to prevent users from accidentally deleting the files if they still need
those files. Figure 4.20 shows the steps of downloading the file from the server into the
user’s own computer.
Figure 4.15: Example of returned JSON.
38

51. Figure 4.16: Right click on the tree node will show a context menu with pre-defined
options.
39

52. (a) Showing directory tree on right side.
(b) Showing directory tree on left side.
Figure 4.17: Switching directory tree left/right
40

53. (a) Select rename.
(b) Insert new name and save.
(c) Directory tree reloaded with updated name.
Figure 4.18: Renaming file or folder
41

54. (a) Select delete.
(b) Directory tree reloaded with updated list of files.
(c) Deletion aborted for trying to delete non-empty folder.
Figure 4.19: Deleting file or folder
42

55. (a) Select download.
(b) Browser starts downloading.
Figure 4.20: Download file
43

56. Terminal emulator
The terminal emulator is placed at the bottom of the page. Code files that
are saved on the server can be run by using the command in the terminal emulator. Cur-
rently, the only programming language that installed in each container is Python. When-
ever the user create a new terminal window, the terminal will be created according to
the configurations in the JSON file that placed in ∼/.tty.js/config.json. Currently, the
only configuration is the geometry of the terminal to make the terminal window fits the
browser size.
4.2 Back End Implementation
4.2.1 Networking
Users should be able to connect to container via port that mapped static IP
address of the host with public IP address, and the host will act as a router that map
container’s IP address with host static IP address from container’s point of view. There
are few steps to setup network. If the system have public IP address, port forwarding
from internal IP address to public IP address port will be necessary for this project to
work.
1. Set static IP address for host server with the standard network interface(eth0) or
custom network interface in /etc/network/interfaces. Check if the network working
right or not.
2. Change to the bridge network(virbr0) and connect the bridge to the previous net-
work interface(eth0), and also set the static IP address.[5]
3. Set LXC to use bridge network by going to the config file of master of container.
$ lxc . network . l i n k = v i r b r 0
Listing 4.1: Change the config file of the main container with bridge
network that was set in the previous step. This config file will be in
.local/share/lxc/containername/
44

57. Figure 4.21: Example of network interface setup for bridging.
4. Set the main container to ask for DHCP to get dynamic IP address that routed out
through the bridge that was set in the host’s network.
$ i f a c e eth0 i n e t dhcp
Listing 4.2: Setting up the network interface in the main container.
5. The last step is to start container and forward port of container with bash script in
the host kernel.
4.2.2 Bash Script
This section is about bash script that will be used in this project at the ap-
plication level.[10] Bash script is important to this project since Bash script is used for
application to communicate with the kernel and to hide low level coding from applica-
tion. All of the scripts below will be in the bin folder in order to use the command.
Node.js port management
It is very simple to manage port for Node.js application in each container
since all containers will launch Node.js application with upstart script. After Node.js
had setup, the host bound port 8080 of container IP address with random generated port.
This process is called port forwarding.
45

58. Figure 4.22: This is the example of port forwarding with bash script.
This bash script will get the argument from the kernel and generate random
port number. This program will check whether this random port number is taken by
other or not. If the port number is taken, the program will generate a new port number
until the script finds the untaken port number. Then, the script will use the untaken port
number to use as port to forward in the iptables.[6]
$ addnoderule 192.168.100.56
Listing 4.3: This is the command that needed to be called in order to bind Node.js port.
This command will directly call iptables command in order to bind port and
IP address. If this port binding failed, the program would display on the kernel to let
system admin noticed. If port forwarding is successful, the program will display success.
Port forwarding could be checked with rulelist command
SSH port management
This is port management for SSH port(22) of each container so that user
with the public key can Secure Shell(SSH) directly to the container without accessing a
browser. This program is very similar to Node.js port management.
Figure 4.23: Example of addsshrule command.
This bash script will get the argument from the kernel and generate random
port number. This program will check whether this random port number is taken by
other or not. If the port number is taken, the program will generate a new port number
until the script finds the untaken port number. Then, the script will use the untaken port
number to use as port to forward in the iptables.[6]
$ a d d s s h r u l e 192.168.100.56
46

59. Listing 4.4: This is the command that needed to be called in order to bind SSH port.
Remove port
Port management cannot be completed with only port forwarding but Port
management must be able to remove the port that binds to the IP address of specific
container.
Figure 4.24: Example of removing rule.
This is bash script to remove 192.168.100.56 port by calling:
$ d r u l e 192.168.100.56
Listing 4.5: Bash example
This command can remove all the rules in the iptable by just calling:
$ d r u l e
Listing 4.6: Bash example
It is very useful to reset all the rules without going through one by one IP
address.
Rule lists
Listing all rules is basically listing all rules in iptables. The script will filter
all the DNAT network types and list all the rules out. The script is very convenient
for system admin to check which port and which IP address is already taken. System
admin could use this information to do various things, such as checking port, checking
IP address, or even checking the security of the system with just this simple command.
47

60. $ r u l e l i s t
Listing 4.7: Listing all rules
The result of calling this command will be shown as a list of information that
will be used in the application level.
Figure 4.25: Rulelist result example.
4.2.3 Container
Container is mostly done by LXC API. For example, If user clicks create
container, container will be cloned from the master container through a LXC command.
First container will be called template or master, and the template can be used to clone
the exact same container as the template. LXC provided all APIs to manage container
including clone, create, destroy, freeze, snapshot, etc. Inside each container will consist
of several components such as, authentication part, or Node.js.
$ lxc−clone −o master −n c o n t a i n e r −name
Listing 4.8: Example of creating container.
Right after user click create, Ruby on Rails will start container right away.
$ lxc−s t a r t −n c o n t a i n e r −name
Listing 4.9: Starting container.
User can shutdown whenever they want. The command of shutting down
container is similar to starting container.
$ lxc−stop −n c o n t a i n e r −name
48

61. Listing 4.10: Shutdown container.
There is another command that often used in this project which shows partic-
ular container’s information. This command provided whether the container is running
or stopped, and The command also provided the IP address, memory use, network link,
Program ID, and CPU use.
Figure 4.26: Result of lxc-info -n container-name
These commands are mostly used by user through Rails API server, however,
there are commands that can be used only for system admin.
$ lxc−a t t a c h −n c o n t a i n e r −name
$ lxc−l s −f
$ lxc−c r e a t e −n c o n t a i n e r −name
$ lxc−monitor −n c o n t a i n e r −name
Listing 4.11: Example of system admin’s commands.
Unprivileged Container
After installing LXC, there are few problems with the container userspace
since LXC run as root user by default and that is not good due to the security reason.
49

62. The expected result is to run container as normal user, and this is called unprivileged
container. There are steps to do unprivileged container.
1. Assign a user set of uids and gids.
$ sudo usermod −−add−subuids 100000−165536 $USER
$ sudo usermod −−add−subgids 100000−165536 $USER
$ sudo chmod +x $HOME
Listing 4.12: Steps for unprivileged container.
2. Create a default config file in order for the template to follow the network config.
$ mkdir −p ~ / . c onfig / lxc
$ echo ” lxc . id_map = u 0 100000 65536 ” > ~ / .
config / lxc / d e f a u l t . conf
$ echo ” lxc . id_map = g 0 100000 65536 ” >> ~ / .
config / lxc / d e f a u l t . conf
$ echo ” lxc . network . type = veth ” >> ~ / . co nfig / lxc
/ d e f a u l t . conf
$ echo ” lxc . network . l i n k = lxc br0 ” >> ~ / . c onf ig /
lxc / d e f a u l t . conf
Listing 4.13: Creating and adding default config to container.
3. Add network link to lxc-usernet file
$ <your username > veth l xcb r0 10
Listing 4.14: Located at /etc/lxc/lxc-usernet
4. Last step is creating template by downloading the template container from Internet.
$ lxc−c r e a t e −t download −n c o n t a i n e r −name −− −d ubuntu −
r t r u s t y −a amd64
Listing 4.15: Create template container.
50

63. Upstart
Upstart is a bash script that runs itself during the start of system. Upstart will
run Node.js in each container. Upstart script will also keep log file in var/log/upstart for
the emergency of error and for debugging purpose.
$ / e t c / i n i t / app−s t a r t e r . conf
$ / var / log / u p s t a r t / app−s t a r t e r . log
Listing 4.16: Location of upstart file in containers and log file.
There are few commands that can be used to start, stop, or check status of
upstart process whether Node.js is running or not. This upstart file is called app-starter.
However, These commands need to be run as superuser(sudo) in order to call app-starter
command properly.
$ sudo s t a r t app−s t a r t e r
$ sudo stop app−s t a r t e r
$ sudo s t a t u s app−s t a r t e r
Listing 4.17: All commands for app-starter.
User Information
In each container, there is a file called user.json. This is a file that contains the
user’s information that will allow the only user to access this container through Node.js.
User’s information will be added right after the container created.
$ / var / opt / a c t i o n / user . json
Listing 4.18: User information location.
Figure 4.27: Example of user.json
51

64. There will be two fields in this file. This file contains the information of
encrypted user email and the Identifier of user from Ruby on Rails.
4.2.4 Redis
Redis for back-end implementation is nothing much but to install Redis into
the system. Redis will automatically create service and automatically start Redis server.
Redis server is running on port 6379. The installation process is pretty simple.
$ wget h t t p : / / download . r e d i s . io / r e l e a s e s / r e d i s −2.8.17. t a r . gz
$ t a r xzf r e di s −2.8.17. t a r . gz
$ cd r ed i s −2.8.17
$ make
Listing 4.19: Installation steps.
After installation, there is an instruction on redis.io that leads to running Re-
dis in background. Follow the instruction until Redis server runs in background through
port 6379. This is a crucial step where Rails Client and Node.js need to communicate
with Redis server. After that Redis server will be running on the system automatically
and waiting for polling.
4.2.5 Rails API
Rails API is an internal server and a layer that interacts with the kernel di-
rectly to provide RESTful API for many client servers to interact with this layer instead of
kernel. As Rails API is named, this API is based on Ruby on Rails project that will only
return JSON on RESTful method. There are many APIs provided for client server to re-
52

65. quest.
’/ s t a r t _ c o n t a i n e r / : name ’
’/ s t o p _ c o n t a i n e r / : name ’
’/ d e s t r o y _ c o n t a i n e r / : name ’
’/ c r e a t e _ c o n t a i n e r / : name ’
’/ g e t _ p o r t / : name ’
’/ g e t _ i p / : name ’
’/ bind_ip / : ip ’
’/ g e t _ s t a t u s / : name ’
’/ d r u l e / : ip ’
’/ append_user_info_to_vm / : name / : hash_email / : userid ’
’/ add_ssh_key / : name / : key ’
’/ c r e a t e _ c o n t a i n e r _ b u n d l e / : name / : hash_email / : userid ’
’/ s t a r t _ c o n t a i n e r _ b u n d l e / : name ’
’/ i s _ c o n t a i n e r _ e x i s t / : name ’
Listing 4.20: These are all API that can be called via get request.
The purpose of this layer is to provide RESTful API that can connect to many
client servers without knowing about server side and container. Also, there is a chance
that outsider could hack into this system via client server. However, the outsider could
not have any access to kernel directly since this Rails API server is siting between the
client server and kernel.
• start_container is starting container with the name of container. The server will
response error if the container does not exist.
• stop_container is to shutdown container with the name of container. The server
will response error if the container does not exist.
• destroy_container is to destroy container completely. The server will response
error if the container does not exist.
• create_container is to create container from the given name. The server will return
whether the request is successful or not.
• get_port is to return port of particular container from the given name. Port will not
return if the container is not existed.
• get_ip is to return IP address of particular container from the given name. IP ad-
dress will not return if the container is not existed instead the response will return
error message.
53

66. • bind_ip is to bind IP address with a random port from the given IP address. The
server will return port that bind with the the IP address.
• get_status is to get status of particular container from the given name. The status
is either running or stopped.
• drule is to remove rule from iptables with the given IP address. However, if the IP
address is left empty, all rules in iptables will be removed.
• append_user_info_to_vm is used when container is created but providing this get
request might help this API to have more flexibility on client side too. This func-
tion will append user information in the container so container knows who is au-
thorized or not.
• add_ssh_key is to add public key to authorized keys in particular container from
the given name of container. The response will return success or error.
• create_container_bundle is the combination of API to provide the easiest way to
create container for the first time without calling other functions. There are few
steps for this function.
1. Create a container.
2. Append user information into container.
3. Start container.
4. Get IP address from the container.
5. Bind IP address with a random generated port.
6. Get port from container name.
• start_container_bundle is the combination of API to provide the simplest way to
start container when the container is already existed. There are few steps for this
function.
1. Start a container.
2. Check status of the container.
3. Get IP address.
4. Check if port is already bound or not. If not, bind a random port with the IP
address.
54

67. 5. Get port from container.
• is_container_exist is to check whether container existed or not.
4.2.6 Nginx
Nginx is a web server that is used with passenger to work with Ruby on Rails
project. Normal configuration would work for this project. Ruby on Rails is special
where the system admin need to point to the location of project to public folder in Ruby
on Rails project. Ruby on Rails will keep log in the production.log and nginx will keep
log file in opt/nginx/log folder. Nginx will limit resource of what Ruby on Rails can do
in order to provide security.
55

68. Chapter 5
TESTING
5.1 UI Testing
Figure 5.1: Example of input form for creating a new work.
• Required fields - all required fields are marked with red asterisks as shown in figure
5.1
• Data type validation - all fields accept only the valid data type. As shown in figure
5.1, the date inputs are entered using date selectors and the number of question
input only accept numbers.
• Cosmetic consistencies - the application use light brown color and bootstrap forms
and buttons on all screens.
56

69. • Delete confirmations - whenever the user click destroy a record, the page will let
the user confirm again before actually deleting the record as shown in figure 5.2.
Figure 5.2: Warning the user before deleting.
• Invalid Choices - Save button in IDE page is deactivated when the current file on
the editor is a new file.
Figure 5.3: Save button is not clickable.
• Screen font type and sizes - all screens have the same font family and have the
same font sizes for similar contents
57

70. Chapter 6
SUMMARY
6.1 Future Works
6.1.1 Architecture
NAT Layer
Adding one more layer in the network architecture would be a good idea to
manage container ports since adding more layers will allow user to use more port rather
than 8080 and 22 which mean this new layer will allow user to host a web development
server such as, Ruby on Rails server, SimpleHTTPServer for Python, or even FTP.
6.1.2 System Admin
Currently there are only two user types, which are instructors and students.
Super user could add admin user to the system and adding admin process would not be
complicated as we already have admin field in user table. Moreover, adding ability for
system admin would be straight forward as we use CanCan ruby gem.
6.1.3 Mailing System
Mail Validation
User registration may require validation email.
Mail Invitation
Instructors can invite students to join the course.
58

71. Notification email
Instructors can set notification email for their courses so that whenever there
is a new work or score update for a student work, the students would be notified.
6.1.4 Course Status
Adding status field to the course table in Rails database. All course statuses
will be set to inactive at the end of the term, and all inactive courses will be hidden from
course search results for enrollment to avoid confusion.
6.1.5 Access container from other client
The container could be accessed through multiple client account that has
been linked to the container.
Figure 6.1: An idea of possible expansion.
59

72. 6.1.6 Different platform containers
Providing containers that run on other platforms than Linux, such as Win-
dows. Since many of commercial automated trading systems only run on Windows.
60

73. References
[1] Cloud9 - your development environment, in the cloud, [Online]. Available:
https://c9.io/.
[2] Codeacademy, [Online]. Available: http://www.codecademy.com/.
[3] Devise, [Online]. Available: https://github.com/plataformatec/devise.
[4] Dnsmasq, [Online]. Available: http://www.thekelleys.org.uk/dnsmasq/
doc.html.
[5] How can i access all my vms using one public ip (nat)? [Online]. Available:
https://okeanos.grnet.gr/support/user-guide/cyclades-how-can- i-access-all-my-
vms-using-one-public-ip-nat/.
[6] Iptableshowto, [Online]. Available: https://help.ubuntu.com/community/
IptablesHowTo.
[7] Lxc, [Online]. Available: https://help.ubuntu.com/12.04/serverguide/ lxc.html.
[8] Nitrous, [Online]. Available: https://www.nitrous.io/.
[9] Redis, [Online]. Available: http://redis.io/.
[10] Writing a simple bash script, [Online]. Available: http://www.linux.com/
learn/tutorials/284789-writing-a-simple-bash-script.
61

74. Appendices
62

75. Appendix A
COURSE TABLE
Attributes Data Type Description
id INT Course identification (Pri-
mary key)
uid INT Instructor identification
(Foreign key)
name TEXT Name of course
description TEXT Course description
63

76. Appendix B
HAND IN WORK TABLE
Attributes Data Type Description
id INT Hand In Work identifica-
tion (Primary key)
wid INT Work identification (For-
eign key)
uid INT User identification (For-
eign key)
total score FLOAT Student works score
64

77. Appendix C
HAND IN WORK QUESTION TABLE
Attributes Data Type Description
id INT Hand In Work Question
identification (Primary
key)
hiwid INT Hand In Work identifica-
tion (Foreign key)
file name TEXT Name of file
data content TEXT Content of the uploaded
file
path name TEXT Path of the file stored for
later use
question number INT Identify the question num-
ber of the work
65

78. Appendix D
PUBLIC KEY TABLE
Attributes Data Type Description
id INT Public key identification
(Primary key)
uid INT User identification (For-
eign key)
ssh key TEXT SSH key from user’s com-
puter
device name TEXT Name of the device
66

79. Appendix E
USER TABLE
Attributes Data Type Description
id INT User identification (Pri-
mary key)
email STRING(255) Email use for sign in
first name TEXT First name of user
last name TEXT Last name of user
instructor BOOLEAN Identify if the user is a in-
structor or not
admin BOOLEAN Identify if the user is an ad-
min or not (for future use)
encrypted password STRING(255) Encrypted password use
for authentication
reset password token STRING(255) Generated by Devise for
resetting password if the
email function is activated
(for future use)
reset password sent at DATETIME Generated by Devise for
resetting password if the
email function is activated
(for future use)
remember created at DATETIME Generated by Devise for
session expiration
sign in count INT Generated by Devise for
sign in count
67

80. Attributes Data Type Description
current sign in at DATETIME Generated by Devise for
built-in functions
last sign in at DATETIME Generated by Devise for
built-in functions
current sign in ip STRING(255) Generated by Devise for
built-in functions
last sign in ip STRING(255) Generated by Devise for
built-in functions
68

81. Appendix F
USER ENROLL TABLE
Attributes Data Type Description
id INT Course identification (Pri-
mary key)
uid INT User identification (For-
eign key)
cid INT Course identification (For-
eign key)
69

82. Appendix G
CONTAINER TABLE
Attributes Data Type Description
id INT Container identification
(Primary key)
uid INT User identification (For-
eign key)
ip TEXT Internal IP address of the
container
name TEXT Name of container
status TEXT Status of the container
url TEXT URL of of the IDE
ssh port TEXT Internal port of the con-
tainer to access via SSH
70

83. Appendix H
WORK TABLE
Attributes Data Type Description
id INT Work identification (Pri-
mary key)
cid INT Course identification (For-
eign key)
name TEXT Name of work
description TEXT Work description
due date DATE Date that the work is due
late date DATE Late date that the work is
due
maximum score FLOAT Maximum score of the
work
number question INT Number of questions in the
work
71