~azzar1/unity/add-show-desktop-key : revision 1164.2.33

1

.. IVLE - Informatics Virtual Learning Environment

2

3

4

.. This program is free software; you can redistribute it and/or modify

5

it under the terms of the GNU General Public License as published by

6

the Free Software Foundation; either version 2 of the License, or

7

(at your option) any later version.

8

9

.. This program is distributed in the hope that it will be useful,

10

but WITHOUT ANY WARRANTY; without even the implied warranty of

11

MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the

12

GNU General Public License for more details.

13

14

.. You should have received a copy of the GNU General Public License

15

along with this program; if not, write to the Free Software

16

Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA

17

18

*******************

19

System Architecture

20

*******************

21

22

IVLE is a complex piece of software that integrates closely with the

23

underlying system. It can be considered part web service and part local system

24

daemon. Due to the implementation of these parts it is tied to Apache Web

25

Server (mainly due to the use of mod_python) and Linux.

26

27

28

Jail System

29

===========

30

31

One of the main features of IVLE is it's ability to execute user's code in a

32

customised environment that prevents access to other users files or underlying

33

file system as well as placing basic resource limits to prevent users from

34

accidentally exhausting shared resources such as CPU time and memory.

35

36

To each user, it appears that they have their own private Unix filesystem

37

containing software, libraries and a home directory to do with what they

38

please. This is mainly done by the setuid root program ``trampoline`` (See

39

:file:`bin/trampoline/trampoline.c`) which mounts the users home directory,

40

sets up the users environment, jumps into the user's jail using the

41

:manpage:`chroot(2)` system call and finally drops privileges to the desired

42

user and group.

43

44

To prevent abuse, ``trampoline`` can only be used by root or one of the uids

45

specified when trampoline is built by ``setup.py build`` (defaults to 33,

46

Debian's www-data user which Apache runs as).

47

48

Base Generation

49

---------------

50

51

All user jails share a common base image that contains the files required for

52

both IVLE's operation and for executing user code. This base image is

53

generated automatically by the ``ivle-buildjail`` script. This then calls the

54

distribution dependant details in :mod:`ivle.jailbuilder` module. At present

55

we only support building jails for Debian derived systems using

56

:program:`debootstrap`.

57

58

The contents of the base image contains a few core packages required for the

59

operation of IVLE - Python and the Python CJSON and SVN libraries. Other

60

options that can be configured in :file:`/etc/ivle/ivle.conf` are the file

61

mirror that debootstrap should use, the suite to build (such as hardy or

62

jaunty), extra apt-sources, extra apt keys and any additional packages to

63

install.

64

65

To prevent users from altering files in the base image we change the

66

permissions of :file:`/tmp`, :file:`/var/tmp` and :file:`/var/lock` to not be

67

world writeable and check that no other files are world writeable.

68

69

Finally we make the user dependent :file:`/etc/passwd` and

70

:file:`/etc/ivle/ivle.conf` symlinks to files in the :file:`/home` directory

71

so that they will be used when we mount a user's home directory.

72

73

Mounting Home Directories

74

-------------------------

75

76

To give the appearance of a private file system we need to merge together a

77

user's local home directory with the base image. In the first release of IVLE

78

this was done off-line by hardlinking all the files into the target directory,

79

but for more than a handful of users this process could take several hours and

80

also ran the risk of exhausting inodes on the underlying file system.

81

82

The first solution was to use `AUFS <http://aufs.sourceforge.net/>`_ to mount

83

the user's home directory over a read-only version of the base on demand. This

84

was implemented as part of ``trampoline`` and used a secondary program

85

``timount`` (see :file:`bin/timount/timount.c`) run at regular intervals to

86

unmount unused jails. This uses the :const:`MNT_EXPIRE` flag from

87

:manpage:`umount(2)` that only unmounts a directory if it hasn't been accessed

88

since the previous call with :const:`MNT_EXPIRE`.

89

90

While quite effective, AUFS appears to cause NFS caching issues when IVLE is

91

run as a cluster. The current system uses the much older *bind mount* feature

92

which allows directories to be accessible from another location in the file

93

system. By carefully read-only bind mounting the jail image and then bind

94

mounting the user's :file:`/home` and :file:`/tmp` directory data over the top

95

we can create a jail with only three bind mounts and at virtually no

96

filesystem overhead.

97

98

Entering the Jail

99

-----------------

100

101

Before running the specified program in the users jail we need to

102

:manpage:`chroot(2)` into the users jail and update the processes environment

103

so that we have the correct environment variables and user/group ids.

104

105

At this stage we also may apply a number of resource limits (see

106

:manpage:`setrlimit`) to prevent run away processes (such as those containing

107

infinite loops or "fork bombs") from exhausting all system resources. The

108

default limits are on maximum address space (:const:`RLIMIT_AS`), process data

109

space (:const:`RLIMIT_DATA`), core dump size (:const:`RLIMIT_CORE`), CPU time

110

(:const:`RLIMIT_CPU`), file size (:const:`RLIMIT_FSIZE`) and number of

111

processes that may be spawned (:const:`RLIMIT_NPROC`).

112

113

Unfortunately due to glibc's :manpage:`malloc(2)` implementation being able to

114

allocate memory using :manpage:`mmap(2)`, :const:`RLIMIT_DATA` does not

115

provide an effective limit on the amount of memory that a process can allocate

116

(short of applying a kernel patch). Thus the only way to limit memory

117

allocations is by placing limits on the address space, but this can cause

118

problems with certain applications that allocate far larger address spaces

119

than the real memory used. For this reason :const:`RLIMIT_AS` is currently set

120

very large.

121

122

Console

123

=======

124

125

Version Control

126

===============

127

128

Worksheets

129

==========

130

131

Database

132

========

133

134

Template

135

========

136

137

.. TODO: Not yet merged

138

Object Publishing

139

=================