WP3Semivirtual Campus

Technical Infrastructure Architecture Design

Petr GrygarekVSB-CZ

“Political” Design Goals• Minimize changes of existing partners' lab

settings– encapsulation of existing solutions and remote

management interfaces• Minimize cost of additional hardware and

software licences – 1 additional PC/lab, opensource technologies used

• By default, we will allow equal access of users of all partners to resources of other partners (tasks and lab equipment) – OER principle– However, there should exist some technical solution

which will disallow some users to access some resources

• Technically all access will be disallowed unless explicitly permitted

SVC Components

• Common Portal

• Local AAA Servers– authenticate users of respective partner– maintain user database

• and provide GUI to administer user database by local administrator/teacher

• VPN Gateways to Lab Management Network of individual partners’ labs

Common Portal

• Main WWW Edinet Portal– Task Database– Reservation Database– User Group Database– Lab Device Database– VPN CA for generation of one-time passwords

for VPN access to labs

Local AAA/User Database Servers

• Maintain user databases of individual partners

• Provide user authentication and potential integration with existing local AAA systems

• May be hosted on the same PC as local lab’s VPN gateway

Remote Access

General Goals of Remote Access Solution• Support of all kinds of management interfaces of lab network

devices– RS-232 network device consoles,– Telnet/SSH/Remote Desktop to lab PCs– WWW management interface and proprietary management applications

• VPN-based remote access to Lab Management Network– Either management interfaces of lab PCs and Terminal servers to

manage network devices’ consoles will be accessible from Lab Management Network

• VPN access allowed only to lab devices belonging to previously reserved task (student also cannot access other student’s remote PC)– during the reserved timeslot only

• There should exist a manual backup method to allow local users to access local lab devices in case of unexpected fatal temporary failure of SVC infrastructure

Remote Management of Lab Devices

Incorporation of Virtualized PCs

•Simplifies and allows to automatize lab management

•Reduces cost

•Reduces power consumption and required space

•Easier to reset configurations to known state

Multiple (Preconfigured) Lab Pods Offered in Parallel in Single Lab

Interconnection of Multiple Partners’ Labs

• Manual preconfiguration of distributed virtual topology for some time period– using point-to-point L2 tunnelling technology– Linux-based OpenVPN SSL VPN gateways

recommended• see WP3 Wiki for detailed explanation of this

recommendation

General Interconnection Scheme

•Multiple point-to-point virtual links may be implemented using multiple L2 tunnels•Full mesh of VPN tunnels or more sophisticated routed structure may be implemented between Lab Management Networks (L3 connectivity)•Results to location-independent access to management interfaces of lab devices

Example of Implementation of Distributed Virtual Topology (1)

Example of Implementation of Distributed Virtual Topology (2)

VPN AccessInteractions between System Components

Unification of Remote Desktop Solutions

• It is desirable do unify methods of lab PC access to be able to integrate remote desktop clients into remote user’s GUI

• VNC was selected as preferred solution– see WP3 Edinet Wiki for detailed explanation

• There is still an (unrecommended) option for partners to keep their current existing remote desktop solution– or operate both the current and recommended

solutions in parallel

User Roles and Use Cases

Use Cases

• User interaction with Common Portal

• User interaction with local User Database management GUI

User Roles (1)• Student

– browses task available for reservation– reserves lab pods to solve tasks (for himself/herself or for

colleague group created by him/her)• may delete his/her reservations

– creates/manages his own colleague user groups– accesses labs

• Task Manager– browses and manages descriptions of tasks

• Teacher– browses available task descriptions– creates/updates student user groups– reserves lab pods to solve tasks (for student group created by

him/her or for himself/herself or )• may delete his/her reservations

– accesses labs to evaluate students configurations– Manage accounts of users from his/her home site

User Roles (2)• Local Lab Admins

– Inserts/Modifies information about schedule of offering preconfigured lab pods of particular local lab to the global Noticeboard

– May delete reservation on local lab equipment reserved by any user

– May delete user groups created by users from his home site– Performs technical support (is informed via email when anything

goes wrong)– Manages local user accounts

• SVC Admin– configures SVC global parameters:

Student is considered a "basic" (less privileged) role; every other role has the rights of Student role implicitly (for verification purposes).

Reservation System

Reservation System Design Goals

• Develop a system which allows to share resources (lab equipment) with reasonable level of flexibility

• It has to be as simple as possible at first version to ensure reliability

• It has to be designed with regard of good extensibility for later improvements

• Lab pod topologies may vary over time. Possibility to offer lab pods with (manually) preconfigured devices taken into account

Usage of Reservation System• Group-based reservation approach

– timeslots are reserved by groups of user, not by users as individuals• User may create groups by listing other users

– group creator becomes group's owner and may modify it– there may be users from multiple sites in the same group

• Group owner may make reservation for his group– timeslots of arbitrary length

• User may also reserve timeslot exclusively for himself/herself as a special case of group-based reservation– Separate group is automatically created for every single user

• Members of group which reserved timeslot may access any device of reserved task– We will try to let users of group to see in their GUI who currently

occupies individual devices' consoles• Reservations are maintained in Reservation Database (MySQL) on

Common Portal

User Groups

• For purpose of lab reservation for group of students to work together– students from multiple partners may belong to the same group

• During lab access attempt, SVC checks whether student belongs to group for which particular lab pod was reserved

• Groups are created/modified/deleted by SVC users– i.e. students and teachers, not administrators

• Teacher creates student user group• Any student may create colleague user group

– creator the group is its “owner” and may modify/delete it• Group database is maintained on Common Portal

– groups have expiration times to limit number of outdated groups

Reservation System Architecture

• Partner’s Lab Administrators advertise lab pods with various topologies and preconfiguations as available for some time period on the global Noticeboard

• Description of every Task specifies requirements of lab pod on which it can be solved

• When student selects a task to reserve, Common Portal offers him those lab pods which can be used to solve required task and times when they are available

• Students reserved a timeslot on particular lab pod

Relation between Tasks

and Preconfigured

Lab Pods

Task Descriptions

• Task Documents– lab guide and optional links to auxiliary study

literature (internal or external)

• System-oriented task information

• Reference to Preconfiguration Description

Preconfiguration Description

• Defines requirements for lab pod on which one or more tasks may be solved– Structured logical description (written in XML) which

defines – required topology– optional devices' preconfigurations– optional additional requirements for lab devices which

may be utilized to implement lab pod specified by PreconfigDescr (e.g. platform, firmware version etc.)

– optional additional restrictions on individual network interfaces used to interconnect lab devices into the required topology (e.g. speed, special features etc).

Preconfiguration Implementation

• specification of physical lab devices which were utilized in place of individual logical lab devices of Preconfiguration Description– plus information about physical interface

names utilized to interconnect the toplogy

• start and end time

AAA

What has to be Authenticated/Authorized ?

• Login to the Common Portal (WWW application)• Establishment of VPN tunnels to Lab Management

Networks– We plan to use our own OTP system integrated with Reservation

system and rest of AAA for this purpose

• Login to management GUI of local user databases

Authorization to perform particular operations is based on the user roles stored in user databases and provided as user attributes by local AAA servers to the entity which required to authenticate the user

AAA Mechanics

• username/password authentication credentials– username@partner-designation– possibility of integration with local authentication systems

• Each partner is responsible for maintaining a database of his users

• Local AAA server will authenticate users and provide user’s attributes from local user database– Shibboleth assessed as implementation platform

• we guess it will be able to implement interfaces between AAA components that we defined

– System of access permissions (categorization of users) may be built later based on user attributes approach

Evaluation of Students

Evaluation of Students (1)

• SVC will be used by groups of students with different grading requirements and strictness– local teacher will use his/her own local

grading criteria

• General fully-automated evaluation is almost impossible because of lab device diversity– out-of-scope of Edinet timeline and budget

Evaluation of Students (2)• After end of the exercise, students will take

configurations from lab devices by themselves and send them via e-mail to the teacher. – further processing may be either manual or semi-

automated

• SVC will allow teacher who reserved particular timeslot for his/her group to reserve additional time after end of each task reservation during which he/she may access and manually check configurations of every device– Students' access will be denied during checking time

System Capabilities Deferred to Later Stages

(but considered now)• User quotas• Automated clearing of devices’ configuration at

beginning of reserved timeslots• Modular system, each partner will write his own

module to clear configs by local technology-dependent clearance method– example module for clearing by powering the device

off and on using power switch will be provided

Compliance of SVC with Suggested Pedagogical Principles

• 4.1 1) Group of students from either one or multiple partners may cooperate on task solutions– More advanced students may cooperate with less advanced – Teacher may participate on task solution

• 4.1 3) Students may work remotely from their favorite working environment and time suitable for them

• 4.1 4) Students will share lab devices with other students which should improve their communication abilities, sense of responsibility and other collaborative abilities

• …

Implementation Platform

• No budget allocated in Edinet to buy commercial software, operating system nor powerful hardware

• Free opensource technologies will be used both on server and client side– Linux, OpenVPN, Apache, PHP, MySQL,

Java Webstart

• Advantage of flexibility and extensibility

Questions ?

Management of Task-Related Documents

• Only author will download and upgrade task documentation– Need of document versioning system (only last version will be

stored) + store dates of last update

• PDF document format• Task assignment should focus on single topic. In case of

multiple consecutive assignments, they should be separated into multiple PDFs (even under the same task). Every PDF should state time required to complete the task– There should also be an option to store references (URLs) either

to external or internal resources

• Will be stored on Common Portal