Abstract

This reports records our experience and understanding towards the upgradation of
institute's network and services. The work broadly captures

a)study and documentation of the existing institute networks and services,

b)redesign of the networks and services,

c)implementation and commissioning of the network and services according to the new
design.

The first major task for us was to document, how each service in the institute was
conffigured and to collect an inventory of the present hardware resources of the
institute. We also created forums documented communication of system issues and
brought out processes for documenting about the future systems.

After we had a fair idea of how present systems works and realizing some of the
drawbacks of present system we built a new network plan and redesigned the
configuration and usage policies of the network.

We rebuilt the gateway for the institute network and reconfigured services for version
control, learning management system, VOIP solution and mail solution. We also
introduced services like OTRS for ticketing. All these configuration and policies are well
documented and versioned.
Contents
1 Introduction 1

2 Network in the Institute 2

2.1 Existing network infrastructure in the institute . . . . . . . . . 2

2.2 Rebuilding and Restructuring of networks . . . . . . . . . . . 4

2.2.1 Proposed plans for the implementation of the network . 4

2.2.2 Execution of network restructuring . . . . . . . . . . . 6

3 Design and deployment of institute service application 7

3.1 Conffiguration of server machines for the services . . . . . . . . 7

3.1.1 XEN virtualization . . . . . . . . . . . . . . . . . . . . 7

3.1.2 OpenVZ virtualization . . . . . . . . . . . . . . . . . . 8

3.2 Mail server for the services . . . . . . . . . . . . . . . . . . . 9

3.3 VOIP Solution: Asterisk . . . . . . . . . . . . . . . . . . . . . 9

3.4 Ticketing System - OTRS . . . . . . . . . . . . . . . . . . . . 10

3.5 Learning Managment System: Moodle . . . . . . . . . . . . . 10

3.6 Version Control: Subversion . . . . . . . . . . . . . . . . . . . 11

3.6.1 Existing SVN service in the institute . . . . . . . . . . 12

3.6.2 New architecture of SVN service . . . . . . . . . . . . . 12

3.6.3 HTTP access for SVN service . . . . . . . . . . . . . . 13

4 Conclusions and Scope for future developments 14

5 Appendices 15

5.1 APPENDIX : Plan I proposed . . . . . . . . . . . . . . . . . . 15

5.2 APPENDIX: Plan II proposed . . . . . . . . . . . . . . . . . . 16

5.3 APPENDIX: Asterisk Installation on OpenVZ VPS . . . . . . 18

5.4 APPENDIX: Xen Virtualization . . . . . . . . . . . . . . . . . 19

5.5 APPENDIX: OpenVZ Virtualization . . . . . . . . . . . . . . 20

5.6 APPENDIX: Installation of Asterisk . . . . . . . . . . . . . . 21

5.7 Conffiguration of the server . . . . . . . . . . . . . . . . . . . . 23

5.8 APPENDIX: Mail Server Installation on VPS . . . . . . . . . 25

5.9 APPENDIX: Experiment on CISCO 3560G series switch . . . 27

5.10 Conffiguration steps . . . . . . . . . . . . . . . . . . . . . . . . 27

5.11 APPENDIX: Installation of OTRS . . . . . . . . . . . . . . . 29

5.12 Appendix: Installation of Moodle . . . . . . . . . . . . . . . . 29

5.13 Appendix: Securing Moodle . . . . . . . . . . . . . . . . . . . 32

5.14 APPENDIX: Installation of SVN . . . . . . . . . . . . . . . . 36

Bibliography 38
List of Figures
2.1 CACTI Screenshot : Screenshot of suspicious traffic . . . . . . 3

5.1 Plan with VLANs . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.2 Plan II : IP address distribution . . . . . . . . . . . . . . . . . 17

5.3 Plan using IP ranges . . . . . . . . . . . . . . . . . . . . . . . 18

5.4 Experiment using VLAN Switch . . . . . . . . . . . . . . . . . 27

Chapter 1

Introduction
Network and services are one of the important elements of any institute. Our institute
IIITM-K is an IT institute which promotes technology facilitated education programs and
learning. As cited in the institute website IIITM-K acts as a "networking institute of
institutions" that promotes both IT and its applications in diverse fields. So the networks
and systems is a critical element in an institute like IIITM-K.

We found that the existing networks and services were not efficient enough to meet the
institute requirements. The externally hosted services like mail, moodle and wiki were
found to be inaccessible from outside. The internal network and services in the institute
were not maintained and managed efficiently.

We worked with Dr Venkatesh Choppella, Dr Rene Ejury and Mr Amarnath Raja to

achieve an efficient and reliable network in IIITM-K. During the course of this work, we
deployed several services including Asterisk,OTRS,Virtual Servers and Subversion.
Chapter 2

Network in the Institute

2.1 Existing network infrastructure in the institute

With Dr.Rene Ejury and systems team, the institute's network infrastructure was
analyzed which brought out several problems in the system. The analysis revealed the
following problems with the current set up.

Suspicious traffic in the network An investigation done analyzing the table log on the
gateway machine revealed some suspicious traffic on the network. Hence CACTI, a
monitoring tool, was installed to monitor the traffic. The bandwidth analysis graph of
CACTI, revealed unexpected peaks in the network traffic.

In the ffigure 2.1, on 10th of March a peak was occured. The normal traffic is 54k. But
on that time the peak was seemed to be more than 100k which was unexpected.
Further investigation through the system logs proved that a malicious software, is
installed in the gateway machine. This lead to the analysis of all the servers and most of
the servers are found to be infected.

This software was initiating a "Denial Of Service" attack or DOS attack which was
chocking the bandwidth in the institute. A temporary solution is achieved by removing
that software. But we cannot completely rely on this solution as such softwares usually
installs a "root-kit", which can give administrative powers to the attackers.
Figure 2.1: CACTI Screenshot : Screenshot of suspicious traffic

Insufficient Bandwidth Most of the web-servers of institution, which are accessible from
outside the institution network, are found to be very slow.

At present the institute has a 512kbps (1:4) broadband connection for the internal
browsing usage and for the external servers. On further analysis, it is found that the
current available bandwidth is not sufficient for the proper functioning of an institution
where the bandwidth is shared for browsing and running the web-servers. More over the
suspicious traffic mentioned above was also adding to the cause.

DoS Attack, installed Rootkits Malicious software has been identified on the servers
running on the institute. These so called 'root kits' have inffiltrated the servers and have
been generating unwanted traffic in the network, bringing to standstill all network related
services. The problems were diagnosed successfully and the full correction of the
problem is possible when we decommission the contaminated machines and reinstall
them cleanly.
Lack of documentation and communication It has come to our notice that the present
network and services lack documentation. There are no documents explaining the
reasons which led to decisions taken among the administrative group. There are also no
adequate documents available explaining the present network setup in the institute. The
services in the institute also lacks information on how it was installed, who installed
it,what are the policies used for that services and how to maintain the service. These
makes the running of the service completely dependent on a single person who has
installed the service and it becomes difficult to transfer the responsibilities.

To develop the culture of documented communication, a Systems and Network

Administration Group (SNAG) has been formed among the systems and network
administrative personnel. The group has decided to meet twice every week to discuss
on improving the IT infrastructure of the institute. A mailing list has been created for this
group and it has been taken care that all the discussions and decisions taken by the
SNAG get documented in the mailing list.

2.2 Rebuilding and Restructuring of networks

2.2.1 Proposed plans for the implementation of the network

Considering all the issues in the existing system mentioned above, we had several
discussions and brainstorming sessions about restructuring of the network and services.
The restructuring plan has to be full proof, avoiding the present defects in the system
and it should also take into consideration the future needs of the institute. To develop
the culture of documentation, all communications and discussions among the group
members is being documented in the snag mailing list. All the justifications for the
acceptance or rejection of proposed plans are also well documented in the mailing list.

After a series of discussions two alternative plans came out which are discussed below.

VLAN based separation of user groups According to this plan the whole institution will
come under a single network. Different user groups will be separated within the network
through VLANs. A VLAN is a virtual LAN and will behave exactly like a LAN. User
groups in IIITM-K are geographically separated. For example the sta_ user group spans
across NILA and Park Center. VLAN is a good solution in these scenarios. VLAN helps
to group a set of users spanning across different buildings under one virtual LAN.

The detailed plan is described on APPENDIX 5.1. We experimented the VLAN

con_guration setup with CISCO 3560G series layer3 switch. The details of the
experiment can be found in APPENDIX 5.9. Issues with plan 1 : The issues that came
across with this plan are listed below.

1. As per the plan 1 some of the institution hosted servers will be running from the Park
Center. But Park Center lacks enough power backup to support these servers in case of
a power failure.

2. The current infrastructure of Park Center is not good enough to keep the server class
machines.

3. VLAN con_guration is found to be di_cult due to the lack of expertise on CISCO

switches.

4. Number of lines from ISPs will be more if some servers are kept in Park Center and
some are in Nila as the servers are planned to use a different ISP from that of browsing.

Considering all the issues that came across, reached a second plan . IP based
separation of user groups As Nila has better infrastructure than Park Center for
maintaining the servers all the external services will be moved to Nila. Tra_c intensive
services like Wiki, Moodle and Mail are planned to be hosted on external servers. Rest
of the external services will be hosted from NILA servers.

Also with this plan, all the user groups will be separated with IP subnets instead of
VLANs. Di_erent IP subnets communicate through the router.

The detailed plan is described on Appendix 5.2.

2.2.2 Execution of network restructuring

From the switch level diagram of the network in park center and Nila, we verified the
feasibility of VLAN on both places. It was found that VLAN was possible without any
change in the existing physical network layout. So we planned to shift to the VLAN
solution in a number of phases. The execution will be achieved in different phases. In
phase one we will not disturb the existing system but establish gateways on Park
Centre and Nila and connect them. In the next phase we decided to move all the
services to Nila. In the third phase VLAN solution will be achieved.

Configuration of Gateway The firewall rules in the institute were broken and that had
lead to the performance degradation of the network. We put up new gateway system
with a concrete firewall. In the present system all the firewall rules are included in a shell
script which could be run to put up the firewall. The external connections end up in this
firewall and all the packets are filtered at this machine.

The gateway systems acts as a router between two networks in the institute, the
parkcenter network and the Nila network. The linux routing table is used for routing the
packets to and from Parkcentre and Nila.
Chapter 3

Design and deployment of institute

service application
3.1 Configuration of server machines for the services

We assisted Dr.Rene Ejury in setting up the HP ProLiant G4p Server for running the
services. The server was setup as software RAID machine with Logical Volume
Manager (LVM) above it. While installing with RAID, only one disk was available. The
second disk can be added later. The system is virtualized and each virtual server is
used for running di_erent services. As suggested by Dr.Rene Ejury, we tried with two
virtualization methods, XEN virtualization and OpenVZ virtualization.

3.1.1 XEN virtualization

The Xen virtualization can run many virtual servers on the same machine.

The virtual severs running on the xen virtualization will have separate kernels dedicated
and separate memory space allocated for each server.

The installation is very simple. First the kernel is to be installed to run the virtualization.
After the installation of the Xen virtualization, different virtual servers can be created and
run. The scheme chosen for naming the virtual servers is the zodiac or sun signs.
Available reserved IP addresses were used for the virtual servers. The table explains
the virtual servers, IP addresses, applications running on them. The detailed installation
steps are described in APPENDIX 5.4.
IP Name Location Services

192.168.0.50 xen In the Lab II Xend

192.168.0.51 base domU on xen CACTI

192.168.0.52 leo domU on xen OTRS

192.168.0.53 gemini domU on xen Asterisk

3.1.1 Xen Virtualization

3.1.2 OpenVZ virtualization

OpenVZ is another virtualization in which only one kernel will be there, which will be
used by all the VPSs. The installation steps are described in APPENDIX 5.5.

IP Name Services

92.168.0.50 OpenVZ1 OpenVZ

192.168.0.51 libra CACTI

192.168.0.52 scorpio Wiki

192.168.0.53 Taurus Asterisk

192.168.0.54 Capricon III TMK-Moodle

192.168.0.107 svn SVN

192.168.0.108 aries OTRS

Comparison

1. In the case of the xen virtualization each virtual servers will have its own kernel. So if
some applications need kernel modifications, it might be difficult to achieve.

2. From the references, it was found that networking and disk performance is better in
openVZ than in Xen. So OpenVZ virtualization is used to run the servers.

3.2 Mail server for the services

For all the services a mail server was required to send mails to all the people within the
group. This was installed on Debian with the help of package manager and configured.

The type of mail configuration chosen was : mail sent by smarthost; received via SMTP
or fetchmail. A smarthost can relay outgoing mails. The smarthost selected was :
mail.iiitmk.ac.in.

So whenever a mail is to be sent to some email-id it will go to the Institution mail server
from where it will be relayed to the destination address. Installation steps are can be
found in APPENDIX 5.8. Issues faced

The institution mail server was configured to block any outgoing mails. The relaying was
enabled only to the institution mail-ids. So it was not possible to implement the mail
server to send mail to external mail-ids.

3.3 VOIP Solution: Asterisk

Asterisk is an open-source PBX (Private Branch Exchange) under dual license. As it is

open-source you can add new applications to it by modifying the code. Both soft phones
and hard phones can be attached to asterisk.

The software for soft phones can be downloaded from the websites and for attaching
the hard phones you may need a zaptel card in your system. Many built in features are
there with asterisk. IVR(interactive voice response), conference calling, automatic call
distribution are a few examples of the features. You can even configure your asterisk
server for voicemail options.

Three main protocols can be used in asterisk : IAX2, SIP and H323. I have configured
the server to run between both IAX2 and SIP. Installation can be done in two ways,
either from the compiled flles or from the source code. In the first method already
compiled file will be available and you need only to install it from those _les. And in the
second method, first you have to get the source code and then compile it. After
compilation you have to install it.

An Asterisk server is installed in the Nila with the second method which is the
compilation of the source code. This method is chosen because the Institution requires
features like conference call. For configuring the Asterisk server to make conference
calls, a timing device is needed to synchronize the voices from di_erent persons. One
method is to get the zaptel device, and the other method is to install the zaptel package
and get the ztdummy which is a kernel module which will provide the same functionality
for the timing.

3.4 Ticketing System - OTRS

In the institution no ticketing system were available. All the user queries were done
manually. Even though the mailing list was used for this, it was not possible to track who
is doing what. With OTRS this can be solved.

Open Ticket Request System(OTRS) is a web based issue tracking system which is
open source and free. With OTRS installed in the institution it will be easier to handle
user queries and management tasks. User queries may include some malfunctioning
hardwares or servers. These queries can be handled by assigning tasks to relevant
sta_s and each assigning task is called ticket creation. Each ticket will have an owner
and a group of OTRS users who can handle that ticket. Tickets have a history from
which the life cycle of each ticket is visible. After the successful completion of the
request the ticket can be closed by the owner.
The detailed description of how OTRS is installed in the institution can be found in
APPENDIX 5.11.

3.5 Learning Managment System: Moodle

Moodle is the learning managment system used in the institute. We learned and
documented the steps for the installation ,configuration and management of Moodle.
We also found in the existing moodle the username and password credentials of users
were owing as unencrypted packets in the network which could be easily sni_ed. And
the problem was critical because it was the same authentication credentials used for the
mail service in the institute.

For making Moodle secure it needs a secure HTTPS connection just for the login page
and then afterwards revert back to the normal HTTP URL for general speed. This option
is available in Moodle. This setting requires HTTPS to be speci_cally enabled on the
web server. Moodle uses Apache webserver and it has a module called modifies which
has the ability to encrypt communications. Enabling the ssl module on Apache and
secure login option in Moodle makes the login page of Moodle secure. Thus, when the
browser is communicating using SSL encryption, the HTTPS pre_x is used at the
beginning of the Uniform Resource Locator (URL) in the browser navigation bar.

Secure server set up uses public key cryptography to create a public and private key
pair. It needs a key and a certificate to operate a secure server. Web server can either
purchase a Certificate Authority-signed certificate or a

self-signed certificate.

A CA-signed certificate provides two important capabilities for your server:

_ Browsers automatically recognize the certificate and allow a secure connection to be

made without prompting the user.

_ When a CA issues a signed certificate, it is guaranteeing the identity of the

organization that is providing the web pages to the browser.
To get a certificate from CA, the requesting company has to send a certificate request
which includes the public key, proof of the company identity, and payment to the
Certi_cate Authority(CA).

We are using a self-signed certi_cate and the procedure for generating the self signed
certi_cate is given in the APPENDIX 5.13.

3.6 Version Control: Subversion

Subversion(SVN) is a free/open-source version control system. SVN manages our data

and keep track of the changes made to the data over time.

This helps us to track the history of changes to our data and even enable us to get back
to the older versions of the file.

SVN can be thought as a centralized _le server. The files in the central repository could
be managed and modified by a group of people. This helps to work collaboratively over
a piece of data. The system would keep track of the changes made to the data and also
who made the change.

The principle of programming course would be using SVN for versioning the course
contents, source codes of scripts and programs used for the automation of the course.
The students would be using SVN for versioning their assignments and other course
works.

3.6.1 Existing SVN service in the institute

There was an svn service running in the institute. The service had the following defects.

_ The svn service was running in the gateway machine of the institute which made it
difficult for the management of SVN service as anything done in that machine for
management of SVN service may possible

e_ect the gateway con_gurations.

_ The svnserve process was running from the root which could invite
security threats.

_ Each and every repository in the institute was manged by the SVN

administrator which made the life of the SVN administrator di_cult.

It also denied the opportunity for the users to manage or create their

own repository.

_ All the repository were categorized according to the context such as

courses, projects, events etc rather than according to the repository

owners.This made it di_cult to give permissions to them according to

the repo owners.

3.6.2 New architecture of SVN service

According to the new architecture the SVN service runs on a virtual Server.

Individual users have home directories on this machine. Users create and

manage their svn repositories under their home directories.

To make the access to the svn server secure, users should be allowed only

ssh certi_cate access. Users manage their own repositories and svn-user au-

thentication and authorization. This extends access to the SVN repositories

to those not having user accounts on SVNSERVER. This is very useful, for

example, if some users want to use repositories to collaborate with people

outside the institute.

The svnserve process is invoked by user svn and not root which makes it

secure. The svn group is given read/write permissions to all the user reposi-
tories so that svnserve process have access to those repositories.

3.6.3 HTTP access for SVN service

The existing SVN server was not accessible to users in other organizations

because most organizations do not allow generic tra_c from inside an organi-

zation to outside the world. SVN server uses its own custom protocol which

the organizations _rewall may block and most organizations allow HTTP

and HTTPS access. We con_gured SVN server with Apache so that HTTP

access was possible for SVN repositories.

The details of installation can be found in APPENDIX 5.14.

Chapter 4

Conclusions and Scope for

future developments
Considering all the requirements of the institution, a better plan for the

network was made. Most of the servers and systems are installed or re-

installed according to the new plan.

The gateways in the institution were con_gured. The new gateways have

scipts explaining each rule. The SVn service was con_gured for http access.

Asterisk was con_gured in the Park Center to create accounts for users,
voicemail box. A workshop was conducted on "How to Use Asterisk" to

the sta_ and students of the institution. Experiments on new technologies

Conducted which are going to be implemented in the institution.

Suggestions

_ Presently, managing the Asterisk server is very di_cult as the adminis-

trator need to modify the con_guration _les manually. So a web based

system can be implemented by which the administrators can manage

the server, add new users etc.

_ Right now the server is available within the Institution only. It can be

con_gured to make external calls too.

_ The OTRS system installed in the institution can be made to have

external access.

Chapter 5

Appendices
5.1 APPENDIX : Plan I proposed

According to this plan the whole institution will come under a single network.

Di_erent user groups will be separated within the network using virtualiza-

tion . This can be achieved through VLANs. A VLAN is a virtual LAN and
will behave exactly like a LAN which will form a broadcast domain. Even

though the users are span across two buildings, user of same group can come

under the same VLAN. In order to achieve the communication between two

VLANs, router con_guration might be required.

According to this plan the following VLAN categories will be there: Sta_,

Faculty, Labs, WLAN and Servers.

In the Figure 5.1 with the help of ISPs the institution network will be con-

nected to the Internet through routers.

Park Center : In Park Center router, _rewall and proxy will be con_gured

on a Linux box. The Linux box is nothing but a machine which has Linux

installed in it. The Linux box is then connected to a CISCO switch which

can be con_gured to have VLANs. Using VLAN con_guration the above

listed user groups are formed.

In Park Center all the servers will be run in di_erent virtual servers. An HP

Proliant server class machine is used for virtualization.

Nila : In Nila through a router the network is connected to another ISP.

Then the router is connected to the switch which can be con_gured to have

VLANs. Here also di_erent VLANs are formed as in Park Center.

 Figure 5.1: Plan with VLANs

5.2 APPENDIX: Plan II proposed

To overcome all the stated issues of Plan I, decided to go for Plan II. As the
idea of hosting services from the Park Center is found to be bad, all the servers

are decided to move to Nila. Also with this plan, all the user groups will be

separated into di_erent networks rather than using VLANs. The communi-

cation between the networks can be achieved through router con_guration.

The chosen IP address ranges are shown in Figure 5.2 Maintaining the mail

server, moodle and wiki is found to be di_cult for the system admins. The

suggestion of outsourcing the services came up. The services which are not

outsourced will be hosted from Nila which has better infrastructure. The servers will be
run from virtual servers.
Figure 5.2: Plan II : IP address distribution

5.2 APPENDIX: Plan II proposed

To overcome all the stated issues of Plan I, decided to go for Plan II. As the

idea of hosting services from the Park Center is found to be bad, all the servers

are decided to move to Nila. Also with this plan, all the user groups will be

separated into di_erent networks rather than using VLANs. The communi-

cation between the networks can be achieved through router con_guration.

The chosen IP address ranges are shown in Figure 5.2 Maintaining the mail

server, moodle and wiki is found to be di_cult for the system admins. The

suggestion of outsourcing the services came up. The services which are not

outsourced will be hosted from Nila which has better infrastructure. The servers will be
run from virtual servers.
Services

As per this plan the following services will be outsourced : Mail Server

and Wiki

The following services will be shifted to Nila: Moodle, IIITM website,

OTRS and SVN.

Figure 5.3: Plan using IP ranges

5.3 APPENDIX: Asterisk Installation on OpenVZ

VPS

In the case of OpenVZ virtualization all the VPSs(Virtual Private Servers)

use the same kernel. When you try to install the zaptel it will try to modify

the kernel. As the source of the kernel will be found only in the HN (Host

Node), it will return error if you try to install the zaptel in one of the Guest

system. So you have to install the zaptel in the Host system. Then load the

devices using

# modprobe zaptel

# modprobe ztdummy

Follow the same steps as described in APPENDIX 5.6. Then loaded the

zaptel devices into the guest system do the following :

vzctl set 104 devnodes zap/pseudo:rw save

This should be done from the HN. After that installed libpri and Asterisk in

the guest system.

18

5.4 APPENDIX: Xen Virtualization

For the Xen virtualization _rst we have to install the xen kernel and xen

packages. This is done using the command

# aptitude install xen-linux-system-2.6.18-6-xen-686 libc6-xen

bridge-utils xen-tools

After installing rebooted the system with the new kernel which is installed.

The xen con_guration _le xen-tools.conf can be found in the directory /etc/xen-

tools/. In the con_guration _le the lvm should be the name of volume group.
According to networking setup in the institution gave the networking param-

eters which are the following :

gateway : 192.168.0.2

subnetmask : 255.255.255.0

The default kernel and memory to use for the virtual servers is to be edited

accordingly in the con_guration _le.

After that created the VPS(Virtual Private Server). When a VPS is created

for the _rst time used the default con_guration _le. Using this command the

VPS can be created.

# xen-create-image --hostname=<name of the host>

This will create the image for the virtual server. The con_guration _le for

the VPS is created which can be found in /etc/xen/hostname.cfg. Now for

running the server :

# xm create /etc/xen/hostname.cfg -c

and

#xm list

will show all the VPSs running with the xen virtualization. After running

entered the VPS and set the required parameters, like IP, subnet etc.

19

5.5 APPENDIX: OpenVZ Virtualization

Downloaded the openvz-kernel and installed the kernel in the machine. Then
rebooted the machine with the new kernel. The command

# uname -a

showed the new kernel. After that installed the user level tools for OpenVZ.

The tools installed are:

_ vzctl

_ vzquota

The command used for the installation :

# aptitude install vzctl vzquota

The system is ready to run the VPSs. For running the VPSs OS templates

are required. Two option were available, download from the website or create

a template. So a template is downloaded from the website using :

wget http://download.openvz.org/template/precreated/

debian-4.0-i386-minimal.tar.gz

to the location /var/lib/viz/template/cache/.Now the VPS is to be installed.

A VPS is created with an ID. Along with the creation of the VPS a con_g-

uration _le is also created in the location /etc/vz/conf. For running a VPS

did the following.

_ Created a VPS using : vzctl create 101

_ Then set the parameters for the VPS :

1. onboot : vzctl set 101 {onboot yes {save . This is required if you

want the VPS is to be up whenever you restart the machine.

2. hostname : vzctl set 101 {hostname test.example.com {save The

test.example.com will be the hostname of the VPS.

3. IP address: vzctl set 101 {ipadd 192.168.0.53 {save A static IP

address is given to the VPS.

20

_ Started the VPS : vzctl start 101.

_ Set the password : vzctl exec 101 passwd.

_ Enter the VPS : vzctl enter 101 Also can enter the system using ssh.

_ To list all the VPSs : vzlist

5.6 APPENDIX: Installation of Asterisk

For installing from the source code, _rst got the source code from the digium

website. The version of the server installed in the institution is 1.2.3.Three

major packages are required for the installation. Those are

1. Zaptel : provides some of the kernel modules required for some of the

features

2. Liberia : This package is a prerequisite of asterisk as it is being detected

while the compilation of asterisk.

3. Asterisk : This package installs the Asterisk server.

After getting the listed packages compiled them in the given order.

zaptel compilation Moved the packages to a folder /usr/src. All the

downloaded _les are tar _les. So made a untar of all the _les. Then changed
directory to /zaptel-1.2. Followed the steps given below for the zaptel instal-

lation

1. Build requirements A matching kernel source tree and a working

Linux build system are needed before the compilation. Some of the

programs require some additional libraries. The script

install_prereq

helped to install the required packages.

_ The following command will show the suggestions:

./install_prereq test

_ The prerequisites got installed by running this command:

21

./install_prereq install

2. Installation The following commands installed the zaptel package in

the machine.

_ To con_gure the machine according to the installation : ./con_g-

ure

_ To make the _les for producing the binaries : make

_ Installation using : make install

Compilation and installation of Libpri Now for the compilation and

installation of libpri changed the directory to the libpri folder. Followed these
steps in order to install libpri in the machine.

1. To get the binaries : make

2. To install from the binaries : make install

Compilation and Installation of Asterisk Moved to the corresponding

directory and did the following things.

1. Prepared the system for installation : ./con_gure

2. Got the binaries : make

3. Installed from the binaries : make install

4. Made some samples : make samples

Error during Installations Got this error while installing the asterisk

package :

(error: *** termcap support not found).

The issue is solved by installing libncurses-dev package which was done by,

sudo aptitude install libncurses-dev.

After installing the server, ran the server using : asterisk -vvvc which opened

a command line interface like this :

CLI>

Typing help will show all the possible commands for the server.

5.7 Con_guration of the server

There are lots of con_guration _les coming with the asterisk installation. All

those _les are located in /etc/asterisk. cd /etc/asterisk will lead you there.
The main four con_guration _les used for the con_guration are :

1. sip.con_g

2. extensions.conf

3. voicemail.conf

4. meetme.conf

All these con_guration _les use a scripting language. Editing these _les will

make you add more functionalities for your server.

iax.conf

Registration of di_erent users on the server is done through this _le. An

example is given below :

[asha]

type = friend

host = dynamic

context=friends

secret=333

callerid=asha

qualify = yes

permit=192.168.0.0/255.255.255.0

In the above example :

type : Type can be friend, peer or user. By setting type you can set up

whether the user must be able to receive calls or make calls or both.
friend: both inbound and outbound calls.

Considering the above example asha's type is friend. So she can make calls

to others and she can receive calls from others.

peer : outbound calls Suppose asha is a peer and in that case she can only

make calls. But she cannot receive any calls.

user : inbound calls

Now when asha is a user, she can only receive calls. No calls can be made

23

by her.

host : Host is made dynamic in the above example. Otherwise we can give

a particular IP address.

context : You have to mention the context of each users. The users can call

within the contexts, but if the user from context-1 want to make a call to a

user in context-2 then, context-2 has to include context-1.

secret : Secret is the password given to the user to register in the asterisk

server.

caller ID : Caller ID is the name given to the user.

qualify : qualify is set to "yes" if the users need to be monitored by the

server. By default it will be no.

permit : By this you are permitting the users to make calls within the LAN.

extensions.conf
Here you will edit your dial plan. It is through this Dial Plan, you will be

telling your server what all actions the server has to do when a call is made

from one phone to another. This again uses a script which you can edit. This

can be explained with an example.

exten => 100,1,Dial(IAX2/asha,50)

exten => 100,2,VoiceMail(100@voicemail)

exten => 8100,1,VoicemailMain(100@voicemail)

exten => 8100,n,Goto(s,6)

Consider the case of asha who is using the IAX protocol with number as 100.

When some other person dials the number 100, then asha's phone will ring

for 50 seconds. If she is not picking up the phone then the caller will enter the

voicemail box where he/she can leave a message and hang up. Otherwise (if

asha is attending the call) that person can talk to her and then the connection

can be hanged.

Now in the given example a second part is given which is the voicemail dial

plan. By dialing 8100 asha can access her voicemail box. When she dials

the number she will be asked for a password which is being con_gured in the

voicemail.conf. If the password given by her is right she can listen to the

IVR (interactive voice response) where she can choose the right option and

listen to the voicemails. Also she will receive a mail noti_cation in her mail

which is being con_gured in the voicemail.conf .

24

voicemail.conf

Here the voicemail options are con_gured. You can listen to your voicemail,

you can have a password for your voicemail box, you can receive e-mail about

the voicemails you are receiving etc. Consider the following example :

100 => 333,asha,asha-pg6@iiitmk.ac.in

In the example you are con_guring for asha. Her number is 100 and her

voicemail box number is 8101 which is speci_ed in extensions.conf. Her pass-

word is 333 which she has to respond to the Interactive Voice Response(IVR)

when she dials to 8101. And an e-mail noti_cation will be sent to the e-mail

address which is mentioned. Now for the e-mail to be sent, you have to install

a mail server.

meetme.conf

Here in this _le, server is con_gured for making conference calls. Inside

rooms, you can have di_erent rooms where many people can participate in

conference. An example is shown over here.

[rooms]

conf => 1234

conf => 2345

Here in the server there are two rooms, 1234 and 2345. An entry should

also be made in the extensions.conf for the conference room. Suppose three
people want to participate in a conference. So dialing that number will reach

the conference room. So all those who want to be in the conference have to

dial the same number.

5.8 APPENDIX: Mail Server Installation on

VPS

Install the exim4 mail server :

# aptitude install exim4

After installation did the con_guration :

# dpkg-reconfigure exim4-confg

This prompted some questions and gave the following answers:

Split configuration into small files? :

Yes

General type of mail configuration:

mail sent by smarthost;received via SMTP or fetchmail

System mail name:

otrs.iiitmk.ac.in

IP-addresses to listen on for incoming SMTP connections:

127.0.0.1

Other destinations for which mail is accepted:

(empty)

Machines to relay mail for:

(empty)

IP address or host name of the outgoing smarthost:

mail.iiitmk.ac.in

Hide local mail name in outgoing mail? :

Yes

Visible domain name for local users:

otrs.iiitmk.ac.in

Keep number of DNS-queries minimal (Dial-on-Demand)? :

No

Delivery method for local mail:

mbox format in /var/mail/

5.9 APPENDIX: Experiment on CISCO 3560G

series switch

Did some experiments with the CISCO router.

 Figure 5.4: Experiment using VLAN Switch

As you can see in the _gure 5.4 with the CISCO router formed three VLANs.

The IP address given to the switch is 172.16.0.10. The IP address of the

machine which is used to access the terminal of the switch is 172.16.0.20

Connected three machines to the VLAN switch one directly and the other

two through a switch. The machine's IP address are set to 172.16.0.21,

172.16.0.22 and 172.16.0.23 respectively. Whenever a machine is connected

to the switch, that will be in the default VLAN which is VLAN1. So machine

with IP 172.16.0.20 is in VLAN1.

Then con_gured the switch so that machine with IP address 172.16.0.21

comes under VLAN2 and the other two machines come under VLAN3.

5.10 Con_guration steps

Accessed the switch using :

# telnet 172.168.0.10

which will asked for the password. By giving the password entered the switch.

After that moved to the privileged mode by:

Switch# enable

which asked for the switch password and then reached the privileged mode.

Then for the con_guration entered the con_guration mode by this :

switch# configure terminal

switch(config)# vlan vlan-id

switch(config)# name name-of-vlan

switch(config)# end

(here the vlan-id was given as 2 and name as faculty) Thus reached the

privileged mode and repeated the same for VLAN 3 too.

Now con_gured the interfaces in order to make come under the VLAN. The

VLAN switch that we used is having 24 gigabitethernet ports. We connected

the machine with IP 172.168.0.21 to the port gigabitethernet0/3 and the

switch which is having the other two machines to gigabitethernet0/5.

Entered the con_gure mode from privileged mode by,

Switch# configure terminal

Now this command will show all your interfaces and their state.

Switch(config)# show ip interface brief

Now we saw the interfaces gigabitethernet0/3 and gigabitethernet0/5. So

chose the _rst interface to con_gure it as VLAN2 by,

switch(config)# interface gigabitethernet0/3

This lead to interface con_guration mode. After that chose access as the

mode.

Switch(config-if)# switchport mode access

Switch(config-if)# switchport access vlan 2

Switch(config-if)# end

Thus con_gured the gigabitethernet0/5 interface for vlan 3. After that tried

some pings which proved that experiment is successful. After the con_gura-

tion the two machine coming under VLAN3 is found to be reachable (pinging

succeeded) each other.

5.11 APPENDIX: Installation of OTRS

The prerequisites of OTRS installation are :

1. Apache2

2. Mysql

Debian is the system system chosen for the installation of OTRS. Both the
prerequisites were available in the aptitude package manager of Debian. Us-

ing the following commands installed both of them :

aptitude install Apache2

aptitude install mysql-server-5.0

Then installed otrs using : aptitude install otrs2 This installed otrs2 and

during the installation it prompted to give the mysql database administra-

tor password. By giving them the installation automatically created the

database for otrs.

A mail server is also con_gured on the machine in order to send mails to

external email id's. The mail server used was exim4. The con_guration of

exim mail server is being described in the APPENDIX VII.

5.12 Appendix: Installation of Moodle

Moodle is a stand alone package that can run on a single machine in a

home network or from a Dedicated Web Server. It needs certain additional

components to work.

These are:

_ Apache2

_ Mysql

_ PHP5

These need to be installed before Moodle.

Steps:
INSTALL APACHE2

sudo aptitude install apache2

INSTALL PHP5

sudo aptitude install php5

sudo aptitude install libapache2-mod-php5

Now restart apache

sudo /etc/init.d/apache2 restart

For testing PHP ,create a _le.

sudo gedit /var/www/test.php - a window will open with a blank sheet.

type <? phpinfo(); ?> - then save and close

In a browser open the page test.php

http://<ipaddress>/test.php

Browser will display a PHP page with informations about PHP. INSTALL

MYSQL

sudo aptitude install mysql-server-5.0

sudo aptitude install php5-mysql

sudo /etc/init.d/apache2 restart to restart the server.

INSTALL MOODLE

Moodle can be installed either from aptitude or

from http://download.moodle.org/. On the command line, type

Moodle download package can be downloaded from the site or get it using
wget from command line. Installation from aptitude:

sudo aptitude install moodle

Installation will ask for the Webserver, Database etc. After that modify the

_le /etc/moodle/con_g.php.

CFG->wwwroot = 'http://ipaddress/moodle'

Then modify /etc/apache2/conf.d. Comment 'deny from all' and Uncom-

ment 'allow from all'.

Restart apache Access http://ipaddress/moodle, then accept following for

DATABASE creation.

Installation from Tar _le:

Get the moodle tar _le from http://download.moodle.org/. Copy moodle

installable tar _le to apache document root (i.e. /var/www/)

cd /var/www

sudo cp moodle-latest-18.tgz /var/www

cd /var/www

sudo tar -zxf moodle-latest-18.tgz

sudo chown www-data:www-data moodle

sudo mkdir moodledata

sudo chown www-data:www-data moodledata

Now create the Moodle database and Moodle user in MySQL.

Create Database
sudo mysql -u root -p

> CREATE DATABASE moodle;

> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,INDEX,ALTER ON

moodle.*

TO moodle IDENTIFIED BY 'moodle';

> quit

sudo mysqladmin -p reload

Now access moodle http://ipaddress/moodle it will automatically opens in-

stall.php followed by a series of pages. Providing the necessary information

like database name , database password etc, on this pages creates con_g.php

_le. Finally Moodle home page will be displayed and the administrator user

can login and perform the rest of the con_guration. Now enjoy Moodling.

5.13 Appendix: Securing Moodle

Apache2 has a modular structure. The module mod_ssl is the

module which adds the encrypted communication feature to it.

This is available in apache2-common package.

To enable this module:

sudo a2enmod ssl

Generating a Certi_cate Signing Request (CSR)

To generate the Certi_cate Signing Request (CSR),the requesting person

has to create his own key. Running following command on the terminal will
creates the key.

openssl genrsa -des3 -out server.key 1024

Creation will be like this: It will ask for passphrase:

Generating RSA private key, 1024 bit long modulus

.....................++++++

.................++++++

unable to write 'random state'

e is 65537 (0x10001)

Enter pass phrase for server.key:

Now you can enter the passphrase for the server.

To create the CSR, run the following command at a terminal prompt:

openssl req -new -key server.key -out server.csr

It will prompt to enter the passphrase. If the passphrase is correct, it will

prompt to enter Company Name, Site Name, Email Id, etc. Once entering

of details is complete, CSR will be created and stored in the server.csr _le.

To create the self-signed certi_cate, run the following command at a terminal

prompt:

openssl x509 -req -days 365 -in server.csr -signkey

server.key -out server.crt

The above command will prompt to enter the passphrase. On entering the

correct passphrase, certi_cate will be created and stored in server.crt _le

Next step is installation of the key _le server.key and certi_cate _le server.crt

or the certi_cate.

sudo cp server.crt /etc/ssl/certs

sudo cp server.key /etc/ssl/private

HTTPS should listen on port number 443. For that add the following line

to the /etc/apache2/ports.conf _le:

Listen 443

Create a copy of /etc/apache2/sites-available/default

sudo cp /etc/apache2/sites-available/default /etc/apache2/sites-available/ssl

Make following change /etc/apache2/sites-available/default _le:

NameVirtualHost *:80

<Virtualhost *:80>

ServerAdmin webmaster@localhost

DocumentRoot /var/www/

<Directory />

Options FollowSymLinks

AllowOverride None

</Directory>

-----------

-----------

</Virtualhost>
Then add following changes to /etc/apache2/sites-available/ssl

NameVirtualHost *:443

<VirtualHost *:443>

ServerAdmin webmaster@localhost

DocumentRoot /var/www/

SSLEngine on

SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire

SSLCertificateFile /etc/ssl/certs/server.crt

SSLCertificateKeyFile /etc/ssl/private/server.key

<Directory />

Options FollowSymLinks

AllowOverride None

</Directory>

-----------

-----------

</Virtualhost>

Now enable ssl:

sudo a2ensite ssl

Reload apache:

sudo /etc/init.d/apache2 force-reload

Restart Apache:
sudo /etc/init.d/apache2 restart

Now access your moodle http://ipaddress/moodle

For secure login:

Goto Site Administration->Security->HTTP

security and enable HTTPS for logins by ticking it.

Logout and login into Moodle. Now secure https connection is enabled for

login page. All the other pages will be on normal http Now enjoy Secure

moodling...

How to remove passphrase from apache2:

The passphrase will be asked each time when the apache starts. It causes

problems when the machine boots up after some reason like the power failure.

That means there should be someone to enter the passphrase.so removing the

passphrase is good.

To remove _rst create a copy of original.

cp server.key server.key.org

Then,

openssl rsa -in server.key.org -out server.key

chmod 400 server.key

Then copy this server.key to /etc/ssl/private

sudo cp server.key /etc/ssl/private

Now restart apache.It wont ask for passphrase.

sudo /etc/init.d/apache2 restart

5.14 APPENDIX: Installation of SVN

First thing we did was the installation of Apache,Subversion and the module

libapache2-svn.

aptitude install apache2

aptitude install subversion

aptitude install libapache2-svn

To use svn with apache installed libapache2-svn module. A repository is an

svn created mini _le system that is versioned. Project and Repository are

used as synonyms.

http://www.iiitmk.ac.in/svn

maps to the directory

/var/www/svn

This is the root of svn. Under this there are either repositories or sub-

directories. Each repository comes with its own access controls.

Currently, we have the following layout:

svn/

proj1 (svn repository)

projects/ for research projects

project1/ (svn repository)

project2/ (svn repository)

project3/ (svn repository)

courses/ for course development

verification-short-course (svn repository)

events/ for events in the institute

svn-admin/ for svn administration

admin/ for system administration scripts etc.

Only repositories can be checked out.

Steps for starting a new project :

1. create a new repository under (a sub-directory of) /var/www/svn. Ex-

ample:

svnadmin create /var/www/svn/projects/project1

2. Give the ownership permission :

chown -R apache.apache /var/www/svn/projects/project1

3. If the project needs authenticated users:

htpasswd -cb /var/www/svn/projects/project1/passwd <user-name> <password>

4. For adding new users:

htpasswd -b /var/www/svn/projects/project1/passwd <user-name> <password>

5. Edit the subversion.conf _le

emacs /etc/http/conf.d/subversion.conf

con_guration setup for repository without authentication

# /projects/project1
# --------

<Location /svn/projects/project1>

DAV svn

SVNPath /var/www/svn//projects/project1

</Location>

con_guration setup for repository with authentication

# /projects/project1

# -------------------

<Location /svn/projects/project1>

DAV svn

SVNPath /var/www/svn//projects/project1

AuthType Basic

AuthName "Authorization for project1"

AuthUserFile /var/www/svn//projects/project1/passwd

Require valid-user

</Location>

6. Restart apache

/etc/init.d/restart

Steps for adding a new user If you want to add a user to project :

As per the current system layout if authenticated users are there it will be

maintained at _le called 'passwd'. so you can add a user with these command
htpasswd -b <project repo path>/passwd <username> <password>

or

htpasswd <project repo path>/passwd <username>

which will prompt to enter a new password.Used when the password should

not be revealed. Example:

htpasswd -b /var/www/svn/projects/project1/passwd user1 secret

(where username=user1 and password = secret)

Word of caution : While using htpasswd don't use -c(create)option it will

create a new passwd _le.So you may lose all the old users.

If a user want to change the password

htpasswd -b <project repo path>/passwd <username> <new password>

or

htpasswd <project repo path>/passwd <username>

Example:

htpasswd -b /var/www/svn/projects/project1/passwd user1 newsecret

(where newsecret is the new password for user1)

Bibliography
[1] Larson, E Robert: CCNA 3.0, Dreamtech Press, 2003 .

[2] Meggelen, Jim Van; Madsen Leif and Smith, Jared: Asterisk The Future

of Telephony, O'Reilly Media, 2005.

[3] OpenVZ Wiki, OpenVZ

http://wiki.openvz.org/Main_Page

[4] Shabeerali, A.V: Systematic Approaches Taken To Apply Software En-

gineering And Applications In Assisting With The Principles Of Pro-

gramming Course, 2007.

[5] Smith, W.Roderick: Advanced Linux Networking, Dreamtech Press,

2003.

[6] Kuruvilla, Mithu; Menon.R, Meenu : Moodle Installation.

http://www.iiitmk.ac.in/wiki/index.php/IIITM-K_How-to_

Knowledge_Base/Moodle_Installation

[7] Rose.V, Asha; S.V, Bhanuparakash: Installation of Asterisk on Debian.

http://www.iiitmk.ac.in/wiki/index.php/Asterisk_:_The_Voip/

Installation_On_Debian_asterisk

[8] Schpplein, Christian; Kammermeyer, Richard; Rother, Stefan; Raith,

Thomas; Steinbild, Burchard; Mindermann, Andr; Edenhofer, Martin;

Kuhn, Christopher; Oschwald, Henning; Hecht, Manuel; Bakker, Ren;

Bodo Bauer, Bttcher, Hauke; Bothe, Jens: OTRS 2.2 - Admin Manual

http://doc.otrs.org/2.2/en/html/

[9] Rose.V, Asha; Gopal.N, Girish; Kuruvilla, Mithu; Ejury, Rene: How to

setup a server with RAID,LVM and Virtualization

http://www.iiitmk.ac.in/wiki/index.php/IIITM-K_How-to_

Knowledge_Base/How_to_setup_a_server_with_RAID%2CLVM_and_

Virtualization

[10] Asteriskguru: Asterisk forum

http://asteriskguru.org/board/

[11] OpenVZ: Openvz forum.

http://forum.openvz.org/

[12] Ubuntu Documentation: HTTPS Con_guration

https://help.ubuntu.com/7.10/server/C/httpd.html#

https-configuration

[13] Kuruvilla, Mithu; Menon.R, Meenu : Secure Moodle

http://www.iiitmk.ac.in/wiki/index.php/IIITM-K_How-to_

Knowledge_Base/Secure_Moodle