Evaluation of virtual servers for use incomputer science education : Utvardering av virtuella servrar f ör användning inom undervisning i datateknik

(1)

Final thesis

Evaluation of virtual servers for use in

computer science education

by

Johan Jernl˚as

LIU-IDA/LITH-EX-A--11/049--SE December 15, 2011

(2)

(3)

Final thesis

Evaluation of virtual servers for use in

computer science education

by

Johan Jernl˚as

LIU-IDA/LITH-EX-A--11/049--SE

Supervisor : M.Sc., Anders Fr¨oberg

Dept. of Computer and Information Science at Link¨opings universitet

Examiner : Ass. professor, Ph.D., Erik Berglund Dept. of Computer and Information Science at Link¨opings universitet

(4)

(5)

Avdelning, Institution Division, Department Datum Date Spr˚ak Language 2 Svenska/Swedish 4 Engelska/English 2 Rapporttyp Report category 2 Licentiatavhandling 4 Examensarbete 2 C-uppsats 2 D-uppsats 2 ¨Ovrig rapport 2

URL f¨or elektronisk version

ISBN

ISRN

Serietitel och serienummer Title of series, numbering

ISSN Titel Title F¨orfattare Author Sammanfattning Abstract Nyckelord Keywords

Virtual servers are being increasingly utilized in higher education for client computers, this thesis investigates if virtualization could also be beneficial for servers. By providing three general models (the first being the current situation and the two latter leveraging virtualization) and evaluating each, a broad sense of the applicability, possibilities and remaining problems of introducing server virtualization is provided.

For one specific course, TDDD27 - Advanced web programming, a more concrete analysis is done and specific recommendations are pro-vided.

The conclusion is that there are still more work to be done, but both of the proposed models are possible and suitable for some courses. Their introduction should have several positive effects, for instance fairer courses and more focus on the subject at hand.

HCS,

Dept. of Computer and Information Science 581 83 LINK ¨OPING December 15, 2011 — LIU-IDA/LITH-EX-A--11/049--SE — http://www.ep.liu.se/exjobb/ida/2011/dd-d/ 049/ December 15, 2011

Evaluation of virtual servers for use in computer science education

Utvärdering av virtuella servrar för användning inom undervisning i datateknik

Johan Jernl˚as

virtualization, web programming, virtual server, vSphere, virtual labo-ratories, student administered server

(6)

(7)

Abstract

Virtual servers are being increasingly utilized in higher education for client computers, this thesis investigates if virtualization could also be beneficial for servers. By providing three general models (the first being the current situation and the two latter leveraging virtualization) and evaluating each, a broad sense of the applicability, possibilities and remaining problems of introducing server virtualization is provided.

For one specific course, TDDD27 - Advanced web programming, a more concrete analysis is done and specific recommendations are provided.

The conclusion is that there are still more work to be done, but both of the proposed models are possible and suitable for some courses. Their introduction should have several positive effects, for instance fairer courses and more focus on the subject at hand.

Keywords : virtualization, web programming, virtual server, vSphere, virtual laboratories, student administered server

(8)

(9)

Acknowledgements

Thank you Erik Berglund and Anders Fr¨oberg, for great ideas and discus-sions throughout the project. Thank you Dejan Ilic, for always being ready to help with the technical platform and for always doing so with a smile.

Also I would like to thank all the rest of you that have supported me during the time i wrote this thesis, you know who you are.

(10)

(11)

Introduction

This chapter gives an introduction to the subject by briefly touching on it’s main parts. For those unfamiliar with the field, the background section contains short primers on the necessary foundations for understanding this thesis. In the Goals and Limitations sections a more formal definition of the project goals are given.

1.1 Background

The department of computer and information science (IDA) at Link¨oping University gives several courses that require students to install and con-figure software. Most courses are straight-forward programming courses and require nothing extraordinary in terms of configurability or individual customization. There are however some courses that have needs beyond the mere basics.

1.1.1 Advanced web-programming

One of the courses with very specific needs is the course TDDD27, Ad-vanced web-programming, a course that is centered around development and deployment of a larger web-project. The student (groups) may decide

(16)

what technologies to use, and how to deploy the project. This freedom seems to make the students more motivated, but also gives rise to major technological problems. About 200 students take this course every year, making it one of the bigger courses in the institution, all expecting excel-lent support for whatever technology they are using. Unfortunately the standard student web-hosting does not support more than a select few of these technologies.

This lack of comprehensive support results in a number of negative ef-fects for the students. The most obvious is that students that have their own web server have a much easier task developing and deploying their projects, while students without their own server might not even find a free hosting solution for deploying some projects. This also makes some (normally newer) technologies much more of a challenge than others (nor-mally older), which is not fair to the students. Actually it is the very opposite message from what is desired. Students should be encouraged to use the latest technologies, not implicitly dissuaded.

The student projects can usually with few exceptions be divided into groups of reasonably homogeneous technology configurations.

1.1.2 Use of servers in computer science at IDA today

This section is specific for Link¨oping university, however it is likely that much of our setup is similar to some, if not most, computer systems in use in higher education today. The image painted here mainly concerns the students’ part of the systems, since that is the only part relevant for this discussion.

The main computer system is Solaris-based, and users log on to servers using thin clients. This setup generally works well, but there is one big problem. Since several thin clients share one server, they are not always permitted to open the ports that they require (since they might already be in use).

Users may publish web content through Apache running mod userdir, serving all content present in ~/www-pub/. There are however several se-curity restrictions, obstructing the students’ progress. Most of these can be overcome with enough knowledge, unfortunately the required knowledge and time are well beyond the scope of some of the courses in which they

(17)

Introduction 3

are needed.

1.1.3 Virtual servers

A virtual server is server software running on a simulated software com-puter. In this manner one computer might independently run several op-erating systems, and application programs, each one unaware of the oth-ers. Basically this is multiplexing of operating systems on one hardware computer, one could say that virtualization is to operating systems what context switching is to processes.

For some time the university’s IT-department has been running VM-ware’s software for hosting virtual servers, vSphere. Mostly these virtual servers have been used internally by the IT-department, however there is nothing that prevents the selling of capacity to other parts of the university. The vSphere server is only accessible on LiU-IT’s local network. In order to connect remotely Cisco’s VPN solution is used, the client interface is shown in figure 1.1.3.

Once the connection is made one can use the regular vSphere client to connect to the server. Figure 1.1.3 illustrates the vSphere client, dis-playing the console (comparable to a hardware computer monitor) of a running guest system on the server. Since the console is accessed through the vSphere system, it can be used even if no networking or operating system is present in the guest operating system.

1.2 Previous work

The use of virtualization of client computers in academic settings is widespread and well documented. The virtualization of servers however is not as well documented. This could possibly stem from the fact that most servers are administered by technical - as opposed to academic - staff, that do not adhere to the custom of publishing their accomplishments. Most of the previous work thus focuses on virtualization of lab environments.

There has been earlier work done concerning virtualization of computer laboratories at Link¨oping University by Denis Moret, however he focused on implications for distance education[1].

(18)

Figure 1.1: The interface of the Cisco VPN client

Stackpole et. al. claim that ”time consuming management, low mobil-ity, and inefficient resource utilization” are some of the known problems in connection with computer and network maintenance for laboratory systems that can be solved by virtualization. The authors also succinctly infer that providing students with preconfigured machines increases the time available for whatever the lab session is supposed to teach[2].

One of the major differences between using virtualization in the indus-try (usually servers) and in education (usually clients) is the requirements concerning the disk image. For clients it is commonplace to reuse disk images even trying to share them. Servers on the other hand are usually only deployed once per image, making efficient sharing of image data less interesting[3].

On the server side there are still some material available, however it is usually commercial rather than academic information[4]. This seems natural when observed in the light of the ”educational market”[5].

1.3 Goals

This thesis aims to:

(19)

Introduction 5

Figure 1.2: The vSphere interface

TDDD27, and make preliminary assessments from a technical per-spective.

• Evaluate how other courses the computer science program may ben-efit from the use of virtual servers based on the different models. • Suggest avenues of continued inquiry in the area.

1.4 Limitations

There are a few important limitations:

• Pedagogical aspects, though important, are not the main focus of this thesis and will only be briefly considered.

(20)

• The proposed server models are only implemented for exploratory purposes, they are not intended to be production grade.

1.5 Method

In order to produce usable results in the short time available, the research method chosen is iterative exploration of representative models. This allows for deeply exploring the parts that prove interesting and leaving the ones that does not appear to hold any interest.

This method could be compared to a greedy algorithm, it should con-verge on a good solution quickly but might sometimes miss the optimum solution. This trade-off was deemed acceptable, as this was intended as a coarse-grained exploration of the design space.

1.5.1 Representative models

To make the process more efficient three distinct models that have been evaluated. Using the analogy from the previous section, this could be seen as choosing different starting points for the algorithm.

Model one is the currently used one since that is the obvious bench-mark. Any proposed new solution should be an improvement compared to the current one. The other two models are each others’ complete oppo-sites. The shared model supposes faculty managed servers, shared between students. The individual model supposes one server per student, installed and managed by the student.

Model 1, the current solution

The current solution is based on one single web server for all students. Each student also have access to one database on a shared MySQL server. Since all students at the university shares the server, security needs to be restrictive.

In this model all clients share the same server and there is virtually no possibility of individual adaptation. All possibilities and limitations of the server applies to all clients.

(21)

Introduction 7

Model 2, shared virtual servers

The second model uses virtual servers that are shared between several stu-dents, one server per technology/language.

This model is a compromise between the first and the second. Virtual servers are used to create several servers like the one in model 1, only each server is running different types of applications.

All clients using the same technologies share a server, implying that server configuration is done beforehand. There is still little or no possibility of individual configuration, but since each server is configured to support it’s particular class of applications this should mitigate the problems with model one, without going so far as model three.

Model 3, individual virtual servers

Lastly, model three is based on the notion of individual virtual servers for every student. Each server may run software tailored for it’s application. Even the operating system may be chosen as to simplify deployment.

Only one client uses the server.

1.5.2 Iterative design space exploration

Each of the models are explored iteratively. First a bare minimum plementation is produced, and then this implementation is iteratively im-proved upon by addressing observed problems and exploring perceived pos-sibilities.

1.5.3 Litterature

Firstly a broad but cursory litterature study was used to identify the three models. After that, much of the required litterature is manuals and other documentation only available in electronic form.

1.5.4 Interviews

Informal interviews have been used between iterations to help deciding on the next iteration. After completing final iteration for the three models

(22)

a few more extensive yet informal, interviews were conducted in order to gauge the models’ applicability in different courses.

(23)

Chapter 2

Evaluation of models

All three models from section 1.5.1 are elaborated and analyzed in this chapter.

Each model is broken down into the same basic parts in order to aid comparison between them. The ”Specifics” sections are elaborations on precisely what technical possibilities exist or can be achieved. ”Adminis-tration” contains information about how the model would be set-up and run. The model’s potential to adapt to new requirements are addressed in the ”Adaptability” section. Lastly there is a section called ”Pedagogical aspects” where a short reflection on how the model affects teaching and learning in the course can be found.

2.1 Model 1, the current solution

This model means keeping the current configuration. It is mainly intended as a baseline for comparing the second and third models.

2.1.1 Specifics

The currently available system is almost a classical LAMP (Linux, Apache, MySQL and PHP) configuration. The only difference is that Solaris is

(24)

substituted for Linux. Storage

By default students are limited to a few megabytes of storage. The exact number depends on what courses the student is taking at the time. This also means that the amount of available storage may well decrease in the future, when the student is taking different courses.

It is possible to request extra space for students taking a certain course, however this space is lost the moment that the course is over irregardless of whether the student actually finished the course.

Software configuration

Most software is reasonably recent, however never the newest version. At the time of writing (2011-07-20) what is available is basically this:

• Apache 2.0.59 • PHP 5.2.3 • MySQL 5.0.22

There are some important limitations due to the way the system is configured. Some are easy to circumvent for someone knowing what is wrong, others can not be mitigated at all.

Since Apache is running one instance for all users, the only way for users to serve web content is through mod_userdir[6], i.e. any software not working with mod_userdir will not be usable. Some configuration options can be set in .htaccess, however only trial and error will tell you which ones. Furthermore, the Apache log files are not available in the default /var/log/... directory but rather in /info/logs-und/www/und/, meaning that most students never even find them.

The default PHP session_save_path is not writable, which means that students must set it manually in order to use sessions. The php_value directive is not allowed in .htaccess, so MySQL credentials must be given in clear text in all PHP-scripts.

(25)

Evaluation of models 11

For MySQL access each student get one database which can be confus-ing. Also, triggers do not work for some reason.

2.1.2 Administration

Administration is centrally managed. Accounts are automatically created for each student registered on one or more courses given by IDA, and that is all that is required for using the system.

Most things that can go wrong can be corrected by contacting TUS (Technical services and support). However they are usually not willing to make changes to the common configuration since this would affect many users in a way that only one user desires.

2.1.3 Adaptability

For non-PHP technologies there is, in practice, limited or no support. Even if it is theoretically possible to manually compile and run whatever software is needed, the exotic system (Solaris) and limited student storage effectively prevents any real solutions. Also since students may not open network ports at will, all courses that require network programming are severely limited. This is not likely to be addressed centrally in the near future since it does not affect the majority of courses.

2.1.4 Pedagogical aspects

Model one encourages the students to learn about Solaris in order to cir-cumvent the shortcomings of the local system. The problem is that this pulls focus from the actual subjects, thus reducing the amount of time spent learning about the subject.

Since many students are limited by this model, they tend to run local servers on their laptops instead. This has two major drawbacks. Firstly, the servers are not accessible via the Internet, which prevents the use of some techniques. Secondly, it makes debugging and evaluation harder for the course staff (since they do not have access to the computer where the student’s project is deployed).

(26)

2.2 Model 2, shared virtual servers

In this model a small number of virtual servers are used to create a ”web hotel” for each technology. The servers are configured by the faculty.

Still, it is preferred to leave as much flexibility as possible to the stu-dents. This might introduce security vulnerabilities, but as the server is only meant for development this should not pose a big problem.

2.2.1 Set-up

All servers need a reasonable multi-user setup. This is usually a simple task, but might in some instances be troublesome. Most of these problems tended to manifest when multiple technologies were supported on the same system, and should be easily solvable in this model by separating incompatible technologies into different servers.

Every time a new technology is introduced a new server must be set up. Thus model 2 increases the workload on the faculty.

Per project set-up

There are also significant differences in required work for adding users de-pending on technology. Some play projects nice with mod userdir and their users do not require much configuration. Others need per-user setup, either by complicated .htaccess files or plain Apache virtual hosts[7].

One of the most commonly required configuration directives is RewriteBase in Apache’s mod_rewrite[8]. However, even though using it tends to be confusing in .htaccess-files this is probably the best solution if one takes into account the problems with ”special requests” discussed in section 2.2.2. User management

The servers can use the university’s active directory user database, however, this database does not contain information about what courses the students are taking. This means that in order to limit access to only students taking the course one would have to list the students manually.

One could of course use a special group that the course leader controls. This would limit unauthorized use, and allow for easy manual addition of

(27)

students even before they have managed to properly register for the course. The adding of students to such a group can be automated as seen in listing 2.1.

Listing 2.1: Adding users from a text file to an AD-group

Import - M o d u l e A c t i v e D i r e c t o r y

Get - C o n t e n t .\ s t u d e n t s . txt | % { Add - A D G r o u p M e m b e r - I d e n t i t y " CN = WebLab - S t u d e n t s , OU = Groups , OU = WebLab , OU = IDA , OU = Student - C o m p u t e r s , OU = H a r d w a r e , DC = ad , DC = liu , DC = se " - M e m b e r s $_ }

Tests were performed to ensure that linux machines could actually be connected to the university’s active directory in order to use the centrally managed user accounts. In order to set this up, a lot of configuration is required.

The configuration needed is shown in appendixes A, B and C. Once these are in place, one only needs to start the correct services (shown in listing 2.2) and tell the server to join the AD (listing 2.3).

Listing 2.2: Starting the services needed to connect to the active directory.

/ etc / i n i t . d / w i n b i n d s t o p / etc / i n i t . d / s a m b a r e s t a r t / etc / i n i t . d / w i n b i n d s t a r t

Listing 2.3: Joining a linux host to an AD-domain.

r o o t @ I D A - c r u x :~# net ads j o i n - U a d m _ j o h j e 5 2 E n t e r a d m _ j o h j e 5 2 ’ s p a s s w o r d :

U s i n g s h o r t d o m a i n n a m e - - AD

J o i n e d ’ IDA - CRUX ’ to r e a l m ’ ad . liu . se ’ DNS u p d a t e f a i l e d !

2.2.2 Special requests

Many of the students’ projects require ”tinkering” with server settings that could be harmful to other users. One example of this is access to Apaches virtual hosts configuration (for one’s own project), the only problem is that there is nothing to stop someone to screw up someone else’s setup.

Most of these settings may be delegated to .htaccess files. These files may only operate on the folders where they are placed which means that users should be prevented form creating problems for each other.

(28)

2.2.3 Security

There are two major kinds of security concerns that have been identified in the course. One is running on a shared, possibly vulnerable, development system and the other is that normal security mechanisms should be usable so that the students learn to build in reasonable security measures.

Firewall

One security measure that one usually wants in a production system is some kind of firewall. A common software firewall on Unix systems is netfilter/IPtables[9]. Using a firewall for the development system would probably introduce unnecessary complexity though and is ignored through-out this thesis.

Backup

The first concern, about the actual system not being safe has been almost ignored. The thinking here is that the if the development system is com-promised, one just re-installs it from system image, the users restore their files and go back to work. One could say that Backup of files is used instead of proper (possibly restricting) security measures.

Exactly how these backups should be made is not important, but it could be an opportunity to introduce version control software like SVN[10] or Git[11].

Learning about security measures

Having a relaxed system security policy would allow users to leverage most technology specific security measures on the application level.

This is of course not a feasible solution in a production environment, where one would need to combine application level security with system and network level security. However it does seem to fit a development environment well.

(29)

2.2.4 Adaptability

Though much more adaptable than the first model, there are some limita-tions to how this solution may be adapted to new technologies. The most important ones are that there needs to be a multi-user deployment option for each technology or framework, and that the teacher must have time to set up the new servers.

2.2.5 Pedagogical aspects

Correctly executed, this model would provide a straight forward, ready-to-run environment, well suited for both predetermined and reasonably open problems. Much of the configuration and ”back end” issues are hidden from the student.

Also, this approach would provide an excellent opportunity to empha-size the importance of data backup.

2.3 Model 3, individual virtual servers

By giving each student a personal virtual server, they are able to configure everything from the operating system to the caching of web-pages to their own specifications.

2.3.1 Set-up

Aside from creating a virtual server for each student, there is virtually no administration required.

Initializing virtual machines

At present students are not allowed in the virtual server management sys-tem. This means that all virtual machines must be created and put on-line by a faculty member. This process entails the entering of network settings which can appear intimidating to a teacher not familiar with the technol-ogy.

(30)

It is also error prone. During the testing phase the settings in listing 2.4 were provided.

Listing 2.4: Networking particulars

IP r a n g e : 1 3 0 . 2 3 6 . 1 3 . 1 9 5 - - 1 3 0 . 2 3 6 . 1 3 . 2 2 2 S u b n e t m a s k : 2 5 5 . 2 5 5 . 2 5 5 . 2 2 4

D e f a u l t g a t e w a y : 1 3 0 . 1 2 6 . 1 3 . 1 9 3 D e f a u l t DNS - s e r v e r : 1 3 0 . 2 3 6 . 1 . 9

More than once, a subtle errors were made while inputting IP-addresses and netmasks which resulted in the system not working. Extrapolated to a system with 200 virtual servers this becomes a real problem.

Individual configurations

Since every system is configured by it’s ”owner”, they will all be different. In most cases this is good. The student can use whatever settings he/she sees fit. There is however a possibility that the student breaks something, and as a result is unable to login.

2.3.2 Adaptability

Everything is set up to the specifications of each student, and the student can change the configuration at will. The only problem is that since stu-dents are not allowed to access the LiU-IT LAN, they can not access the console of their virtual servers. This means that there could still be sit-uations where they are ”locked out” from remote login and need help by faculty to get back in.

One could argue that this model would require more work from the students, however these servers could still be loaded from pre-configured standard templates. Such a solution would effectively reduce the incurred overhead.

Despite of these potential problems, this is the most flexible solution.

2.3.3 Pedagogical aspects

There are a few things to consider from a pedagogical standpoint. On the plus side, the student gets a holistic view of the development process.

(31)

The extra adaptability is likely good for already strong students, but could possibly be a negative factor for weaker ones.

(32)

TDDD27 specific analysis

This chapter contains more a more specific analysis of the problems and so-lutions that are relevant for the course TDDD27. The first section contains an overview of what specific requirements need to be added for this course, the following sections present what problems and solutions were found to exist for the two newly proposed models, and the last section compares the results.

3.1 Requirements for TDDD27

The Advanced web programming course, TDDD27, was found to have the following big picture requirements:

1. Possibility of using the most common frameworks and technologies. 2. Simple project configuration with few imposed restrictions.

3. Hosting the projects on the Internet, allowing use of third party ser-vices.

4. Simple user management.

5. File storage and backup/version control. 18

(33)

TDDD27 specific analysis 19

The last three requirements (number 3-5) are rather general. As such they have already been addressed in the previous chapter and will only be cursorily analyzed here.

The first and second requirement are actually intimately connected since the configuration options depend greatly on the frameworks, technologies and web-server used. The first item is left intentionally vague since the specific technologies and frameworks are likely to change from year to year.

3.1.1 Frameworks and technologies

As previously stated, the frameworks and technologies are likely to change over time. However, in order to perform any actual tests some needed to be specified. This generated the following target configurations:

MySQL

Most technologies of interest here can use most of the common database managers, and does not require a local database.

Therefore MySQL was selected since it is free to use, and it is taught in other courses at LiU, increasing the probability that the students are already familiar with it.

File storage

The file storage could preferably be central, however should be accessed through their mount points on the various servers. The main reason for this is that some technologies utilize userspace programs to configure and even launch projects. If these were to run on the computer hosting the storage rather than the computer hosting the web server it won’t work as expected.

ASP.NET

Since ASP.NET is a Microsoft product, it runs best with Microsoft software. This implies that ASP.NET projects should be deployed on a Windows operating system running IIS.

(34)

ASP.NET can be run in a GNU/Linux environment by using the mono project[12]. This solution was not considered since it is considered non standard, which is a bad thing when trying to teach students how things normally work (should work), it is also not completely compatible with the original.

ASP.NET applications should be developed in Visual Studio which also provides the possibility of running a local development server for testing applications. Deployment to IIS is similar to deployment to Apache for the other projects, and should be done on a per project basis.

Visual studio would have to be run on individual virtual servers (or locally on the students’ laptops) since there is a cap on how many remote users can be logged in to one windows installation before having to buy a more expensive license.

PHP

PHP runs on most operating systems and servers but the most common solution is probably GNU/Linux running an Apache web server. Apache is commonly configured to use mod_userdir to serve many pages for many users or vhosts to serve many pages for the same user.

Two of the most common frameworks have been chosen to represent all, Code Igniter and Cake PHP. Both can be easily deployed and configured.

Ruby

Ruby on Rails (RoR) provides it’s own server for quickly deploying a project during the development phase. By issuing a simple command in the project folder (script/server -p port -b bind-address) a new server is spawned that serves the current project. One can run the script without specifying any parameters, but then the server binds to port 4000 on localhost. Binding to localhost is bad, since it is much easier to run a web browser on the student’s local computer ant point it to some Internet address than running a browser on the server and pointing it to localhost (i.e. the server). Port 4000 is great for one user, but should probably be changed to something more individual in a multi user setting.

(35)

Python

For python, Django was chosen as a representative framework. Like Ruby on rails, Django provides it’s own development server. The only differ-ence is a slightly different launching syntax (python manage.py runserver port :bind-address).

Java

GWT is normally run through the graphical interface of eclipse, but has the possibility of running a command line development server by running the ant target devmode.

3.2 A ”web hotel” like solution (model 2)

The cleanest way of configuring projects is normally through Apache vhosts, they are however part of Apache’s static configuration and misconfigura-tions may prevent the server from even starting. This is not desirable in a learning environment.

The other option is mod_userdir in combination with .htaccess files. This option has less potential to crash the server, but on the other hand get really messy when trying to configure ruby or python projects. The problem is basically that each user needs to set individual url-rewrite settings in order to make page routing work as desired, often ending up in non working configurations.

Some modules (like wsgi, the interface of choice for running Python scripts in Apache) also need additional configuration directives set per project. Some of these are configurable in .htaccess files, some are not.

There is also an interference problem when using Apache for hosting multiple technologies. During the tests performed, all attempts to host Ruby and Python projects on the same Apache instance failed miserably.

3.2.1 Solution

The conclusion is that for model two, the most sane solution is to separate the development server from deployment server(s).

(36)

For development purposes a very openly configured Apache (for PHP) and the command line tools for running the development servers available for the remaining technologies seem superior. This provides a very flexible solution, in addition it contains very few components that the students con not control, thus allowing them to experiment and problem-solve on their own. The downside is that the projects are only on-line when they are actively running the development server, this is considered a minor problem.

Deployment by nature needs to be more permanent. The most realistic solution is probably using Apache vhosts for each group. This solution will not work for all technologies on the same virtual server, but it will work using one virtual server per technology. One of the major drawbacks is that the students are not privileged users, and thus cannot change the required configuration files themselves. This can be solved by either referencing files in the students’ home directories, or by requiring the students to submit their proposed configurations to the teacher. The latter solution is prob-ably preferable since it allows the teacher to easily remove misbehaving configurations.

3.2.2 Analysis

Economically, this solution is probably superior to model three, since it would only require one windows server (the only software that is not free). There is also the problem with visual studio and ASP.NET projects. The only reasonable solution seems to be running one server each for these students.

From a student perspective most of the software and configuration is done beforehand. Arriving at an already working system, allows the stu-dent to just generate a default project and start coding. The only real system configuration required is the Apache vhost configuration required for deployment. This means that model two would have very low overhead for the students.

Faculty would be required to set up the different servers, and of course to fiddle a bit with the Apache vhosts in the end. This is still not a very big problem. Also each server can be managed by the teacher designated to that technology-group, making it easier to provide competent help as

(37)

well as technology specific software updates.

3.3 A solution using personal servers (model

3)

Providing each student with a personal virtual server would help bridging the gap between development hosting and deployment hosting by allowing the student to try out the deployment hosting early in the development process. The student would also be allowed administrative privileges, thus making it possible to change the server configuration as required.

There could still be pre-configured server-images for each technology available, however some settings would need to be made by hand using the vSphere console (networking and user account setup). Since this would need to be done by faculty it would probably mean increased time spent on setting up student environments compared to model two.

There is also a monetary side to this, creating individual servers for the ASP.NET groups would multiply costs by the number of groups. Further-more, additional virtual servers probably implies more load on the physical server, which would also make this solution more expensive.

3.4 What solution to use?

For TDDD27, a combined approach seems most appropriate. The main solution would be model two, with one server for each technology. Each such server could be used for both developmental hosting by using the servers shipped with the different technologies for development and using Apache configured for that particular technology, and one vhost per project for deployment.

Should there be someone requiring more freedom, resources or just wanting to use a technology not supported by the standard setups, it would still be possible to provide individual servers according to model three for those particular instances. Apparently ASP.NET projects would seem to fall under this category if one needs a virtual server to run visual studio.

(38)

If the students can run visual studio locally on their laptop, that would of course be preferable both from an economical and performance standpoint.

(39)

Chapter 4

Discussion and

conclusions

The discussion chapter contains an attempt at answering the questions about what model is more suitable as well as a section that suggest further work.

The low adaptability is the main problem with the current solution. It works very well with standard PHP and MySQL, but some PHP features that are needed are disabled for security reasons. The other models have increasingly better adaptability, but introduce other problems instead.

4.1 The best solution

Picking the best solution is not a trivial task. There are many factors that need to be taken into account, also they are weighted differently depending on the course.

In order to make the answer more generally applicable, it will be an-swered in two parts. The first part is specific to the course TDDD27, and then the answer is generalized to all CS courses. Hopefully this will allow both depth and breadth to be conveyed.

(40)

4.1.1 CS courses in general

Most courses do not need a server, these should probably keep using model one.

Some courses do need servers though. There are a number of courses in the areas of web programming, databases, computer networks and dis-tributed systems that might make good use of virtual servers. These should migrate to either model two, model three or a combination.

Some of these areas are more suited for model two, for instance basic web programming courses where the software requirements are homogeneous, but does not match the standard setup in model one.

There are also courses that could benefit from model three, for instance courses concerning computer networks or distributed systems. The upside is that the correct setup could be used, instead of emulation.

4.1.2 TDDD27 - Advanced web programming

If you only consider the programming part of the course, models two and three would both be sufficient. However, model two would be very limiting for some projects, since configuration is centrally managed. Also, model three provides a great opportunity to discover the art of configuring a web-server and deploying a project, but may require previous knowledge that some students do not possess.

The best solution would probably be a combined approach, where most students used model two, and those who want to do more complicated projects are upgraded to model three.

4.1.3 Software frozen in time

Another application of virtual servers with pedagogical implications is to keep really old systems running as is, even though there is no hardware left to support them. The software can be horribly outdated and riddled with security vulnerabilities, as long as one can just shut it down and start a new copy next year none of this matters.

(41)

Discussion and conclusions 27

4.2 Pedagogical impact

Introducing virtual servers in an education setting could have direct ped-agogical implications. According to the SOLO-taxonomy[13], one way of assessing student learning outcomes is by looking at how knowledge and facts are integrated into larger concepts. Students need to overcome the pre-structural and unistructural levels before being able to properly address the multistructural and relational levels. The obvoius implication here is that in courses aiming to teach advanced concepts on the multistructural and relational levels it should be possible to boost student progress by pro-viding a preconfigured server with all the necessary tools set up and ready to be used, thus bypassing the first levels of the SOLO-taxonomy.

One example of this could be a course teaching programming method-ology, traditionally it has been the responsibility of the students to identify and set up the tools to aid their progress through the course. This requires a lot of nuts and bolts knowledge of each tool that is not strictly necessary, or even connected to, the subject in question. By just launching a precon-figured server with some preconprecon-figured tools the students can bypass this step and move on to actually using the tools.

4.3 Further work

A summary of what questions still need answering. Most of these concern technical and economical issues.

4.3.1 Reusable parts

If virtual servers are to reach their full potential, a reasonable system for reusing server configurations is required. The ideal would be to just clone an image of an already configured system.

Network setup

One of the most problematic points in setting up new virtual servers (ac-tually completely impossible without access to the vSphere back-end) is

(42)

setting up the network settings. For virtual servers to be usable in practice this process must be simplified, or if possible automated.

User management

There needs to be a standardized way of managing users in model 2 in order to make it usable. Preliminary tests indicate that this is possible for both windows and Linux servers, but the process must be formalized. Preferably it should also be automated.

A big question here is student groups. It would be really helpful if there were preconfigured groups containing all students for a particular course.

4.3.2 Cost

The service is provided by the IT-department. The tests run for purposes of writing this thesis were free, but if usage grows there will be need for compensation. Since nobody can readily answer what the magnitude of this compensation would be, that will have to be properly investigated.

(43)

Appendix A

common-auth

Listing A.1: The common-auth file controls how the system can verify users.

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = === / etc / pam . d / common - a u t h = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = #

# / etc / pam . d / common - a u t h - a u t h e n t i c a t i o n s e t t i n g s c o m m o n to all s e r v i c e s #

# T h i s f i l e is i n c l u d e d f r o m o t h e r service - s p e c i f i c PAM c o n f i g files , # and s h o u l d c o n t a i n a l i s t of the a u t h e n t i c a t i o n m o d u l e s t h a t d e f i n e # the c e n t r a l a u t h e n t i c a t i o n s c h e m e for use on the s y s t e m

# ( e . g . , / etc / shadow , LDAP , K e r b e r o s , etc .) . The d e f a u l t is to use the # t r a d i t i o n a l U n i x a u t h e n t i c a t i o n m e c h a n i s m s .

#

# As of pam 1.0.1 -6 , t h i s f i l e is m a n a g e d by pam - auth - u p d a t e by d e f a u l t . # To t a k e a d v a n t a g e of this , it is r e c o m m e n d e d t h a t you c o n f i g u r e any # l o c a l m o d u l e s e i t h e r b e f o r e or a f t e r the d e f a u l t block , and use # pam - auth - u p d a t e to m a n a g e s e l e c t i o n of o t h e r m o d u l e s . See # pam - auth - u p d a t e (8) for d e t a i l s .

# h e r e are the per - p a c k a g e m o d u l e s ( the " P r i m a r y " b l o c k )

# a u t h [ s u c c e s s =3 d e f a u l t = i g n o r e ] p a m _ k r b 5 . so m i n i m u m _ u i d = 1 0 0 0 a u t h [ s u c c e s s =2 d e f a u l t = i g n o r e ] p a m _ u n i x . so n u l l o k _ s e c u r e # try - first - p a s s a u t h [ s u c c e s s =1 d e f a u l t = i g n o r e ] p a m _ w i n b i n d . so k r b 5 _ a u t h k r b 5 _ c c a c h e _ t y p e = F I L E c a c h e d _ l o g i n r e q u i r e _ m e m b e r s h i p _ o f = WebLab - S t u d e n t s t r y _ f i r s t _ p a s s # here ’ s the f a l l b a c k if no m o d u l e s u c c e e d s a u t h r e q u i s i t e p a m _ d e n y . so

# p r i m e the s t a c k w i t h a p o s i t i v e r e t u r n v a l u e if t h e r e isn ’ t one a l r e a d y ; # t h i s a v o i d s us r e t u r n i n g an e r r o r j u s t b e c a u s e n o t h i n g s e t s a s u c c e s s c o d e # s i n c e the m o d u l e s a b o v e w i l l e a c h j u s t j u m p a r o u n d

a u t h r e q u i r e d p a m _ p e r m i t . so

# and h e r e are m o r e per - p a c k a g e m o d u l e s ( the " A d d i t i o n a l " b l o c k ) # end of pam - auth - u p d a t e c o n f i g

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = === end common - a u t h = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

(44)

krb5.conf

Listing B.1: The krb5.conf file controls kerberos interaction.

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = === / etc / k r b 5 . c o n f = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = [ l o g g i n g ]

d e f a u l t = F I L E :/ var / log / k r b 5 . log [ l i b d e f a u l t s ] d e f a u l t _ r e a l m = AD . LIU . SE k d c _ t i m e s y n c = 1 c c a c h e _ t y p e = 4 f o r w a r d a b l e = t r u e p r o x i a b l e = t r u e [ r e a l m s ] AD . LIU . SE = { kdc = ad . liu . se a d m i n _ s e r v e r = ad . liu . se d e f a u l t _ d o m a i n = LIU . SE } [ d o m a i n _ r e a l m ] . liu . se = AD . LIU . SE liu . se = AD . LIU . SE = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = === end k r b 5 . c o n f = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 30

(45)

Appendix C

smb.conf

Listing C.1: The smb.conf file configures samba.

[ g l o b a l ] ## B r o w s i n g / I d e n t i f i c a t i o n ### w o r k g r o u p = ad r e a l m = ad . liu . se p a s s w o r d s e r v e r = ad . liu . se c l i e n t n t l m v 2 a u t h = yes e n c r y p t p a s s w o r d s = t r u e c l i e n t use s p n e g o = yes w i n b i n d use d e f a u l t d o m a i n = yes w i n b i n d s e p a r a t o r = + # s e r v e r s t r i n g is the e q u i v a l e n t of the NT D e s c r i p t i o n f i e l d s e r v e r s t r i n g = % h s e r v e r ( Samba , U b u n t u ) # T h i s w i l l p r e v e n t n m b d to s e a r c h for N e t B I O S n a m e s t h r o u g h DNS . dns p r o x y = no # W h a t n a m i n g s e r v i c e and in w h a t o r d e r s h o u l d we use to r e s o l v e h o s t n a m e s # to IP a d d r e s s e s n a m e r e s o l v e o r d e r = l m h o s t s h o s t w i n s b c a s t # # # # # # # A u t h e n t i c a t i o n # # # # # # # s e c u r i t y = ads e n c r y p t p a s s w o r d s = t r u e p a s s d b b a c k e n d = t d b s a m o b e y pam r e s t r i c t i o n s = yes i d m a p uid = 1 0 0 0 0 - 5 0 0 0 0 i d m a p gid = 1 0 0 0 0 - 5 0 0 0 0 t e m p l a t e s h e l l = / bin / b a s h 31

(46)

w i n b i n d e n u m g r o u p s = yes w i n b i n d e n u m u s e r s = yes

(47)

Bibliography

[1] Denis Moret. Livelab : What are the requirements of a virtual labo-ratory?, 2008.

[2] Bill Stackpole, Jason Koppe, Thomas Haskell, Laura Guay, and Yin Pan. Decentralized virtualization in systems administration educa-tion. In Proceedings of the 9th ACM SIGITE conference on Informa-tion technology educaInforma-tion, SIGITE ’08, pages 249–254, New York, NY, USA, 2008. ACM.

[3] Alessio Gaspar, Sarah Langevin, William D. Armitage, and Matt Ride-out. March of the (virtual) machines: past, present, and future mile-stones in the adoption of virtualization in computing education. J. Comput. Sci. Coll., 23:123–132, May 2008.

[4] The Greaves Group (for IBM). Virtualization in education. Technical report, IBM, 2007.

[5] J. Gerhard and P. Mayr. Competing in the e-learning environment– strategies for universities. Hawaii International Conference on System Sciences, 8:262, 2002.

[6] The Apache Software Foundation. Apache module mod userdir. http://httpd.apache.org/docs/current/mod/mod_userdir.html. fetched 2011-07-27.

[7] The Apache Software Foundation. Virtualhost examples. http:// 33

(48)

[8] The Apache Software Foundation. Apache module mod rewrite. http://httpd.apache.org/docs/current/mod/mod_rewrite.html. fetched 2011-07-27.

[9] Pablo Neira Ayuso. Netfilter/iptables project homepage - the netfil-ter.org project. http://www.netfilnetfil-ter.org/. fetched 2011-07-27. [10] The Apache Software Foundation. Apache subversion. http://

subversion.apache.org/. fetched 2011-07-27.

[11] Scott Chacon. Git - fast version control system. http://git-scm. com/. fetched 2011-07-27.

[12] The Mono project team. Mono. http://mono-framework.com/Main_ Page. fetched 2011-01-10.

[13] K. E. Collis and J. B. Biggs. Evaluating the Quality of Learning: The SOLO Taxonomy. Academic press, 1982.

(49)

LINKÖPING UNIVERSITY ELECTRONIC PRESS

Copyright

Svenska

Detta dokument h˚alls tillgängligt p˚a Internet - eller dess framtida ersättare - under 25 ˚ar fr˚an publiceringsdatum under förutsättning att inga extraordinära omständigheter uppst˚ar.

Tillg˚ang till dokumentet innebär tillst˚and för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillst˚and. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfat-tning som god sed kräver vid användning av dokumentet p˚a ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i s˚adan form eller i s˚adant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hem-sida http://www.ep.liu.se/

English

The publishers will keep this document online on the Internet or its possible replacement -for a period of 25 years from the date of publication barring exceptional circumstances.

The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Link¨oping University Electronic Press and its pro-cedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/

c

Johan Jernl˚as

Evaluation of virtual servers for use incomputer science education : Utvardering av virtuella servrar f ör användning inom undervisning i datateknik

Evaluation of virtual servers for use in

computer science education

Evaluation of virtual servers for use in

computer science education

Abstract

Acknowledgements

Contents

Chapter 1

Introduction

1.1

Background

1.1.1

Advanced web-programming

1.1.2

Use of servers in computer science at IDA today

1.1.3

Virtual servers

1.2

Previous work

1.3

Goals

1.4

Limitations

1.5

Method

1.5.1

Representative models

1.5.2

Iterative design space exploration

1.5.3

Litterature

1.5.4

Interviews

Chapter 2

Evaluation of models

2.1

Model 1, the current solution

2.1.1

Specifics

2.1.2

Administration

2.1.3

Adaptability

2.1.4

Pedagogical aspects

2.2

Model 2, shared virtual servers

2.2.1

Set-up

2.2.2

Special requests

2.2.3

Security

2.2.4

Adaptability

2.2.5

Pedagogical aspects

2.3

Model 3, individual virtual servers

2.3.1

Set-up

2.3.2

Adaptability

2.3.3

Pedagogical aspects

TDDD27 specific analysis

3.1

Requirements for TDDD27

3.1.1

Frameworks and technologies

3.2

A ”web hotel” like solution (model 2)

3.2.1

Solution

3.2.2

Analysis

3.3

A solution using personal servers (model

3)