REBUILDING THE INSTITUTE NETWORK AND SERVICES

Asha Rose V Girish N Gopal Mithu Mary Kuruvilla

Project Report

Submitted in partial fulllment of the requirements for the award of Master of Science in Information Technology

Indian Institute of Information Technology and Management-Kerala Park Centre, Technopark, Trivandrum-695 581 Trivandrum-695 581 2008

Abstract This reports records our experience and understanding towards the upgradation of institutes 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 rst major task for us was to document, how each service in the institute was congured 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 conguration and usage policies of the network. We rebuilt the gateway for the institute network and recongured services for version control,learning management system, VOIP solution and mail solution. We also introduced services like OTRS for ticketing. All these conguration and policies are well documented and versioned.

Contents
1 Introduction 2 Network in the Institute 2.1 Existing network infrastructure in the institute . . . . . . . . . 2.2 Rebuilding and Restructuring of networks . . . . . . . . . . . 2.2.1 Proposed plans for the implementation of the network . 2.2.2 Execution of network restructuring . . . . . . . . . . . 3 Design and deployment of institute service application 3.1 Conguration of server machines for the services . . . . . 3.1.1 XEN virtualization . . . . . . . . . . . . . . . . . 3.1.2 OpenVZ virtualization . . . . . . . . . . . . . . . 3.2 Mail server for the services . . . . . . . . . . . . . . . . 3.3 VOIP Solution: Asterisk . . . . . . . . . . . . . . . . . . 3.4 Ticketing System - OTRS . . . . . . . . . . . . . . . . . 3.5 Learning Managment System: Moodle . . . . . . . . . . 3.6 Version Control: Subversion . . . . . . . . . . . . . . . . 3.6.1 Existing SVN service in the institute . . . . . . . 3.6.2 New architecture of SVN service . . . . . . . . . . 3.6.3 HTTP access for SVN service . . . . . . . . . . . 4 Conclusions and Scope for future developments 5 Appendices 5.1 APPENDIX : Plan I proposed . . . . . . . . . . . . 5.2 APPENDIX: Plan II proposed . . . . . . . . . . . . 5.3 APPENDIX: Asterisk Installation on OpenVZ VPS 5.4 APPENDIX: Xen Virtualization . . . . . . . . . . . 5.5 APPENDIX: OpenVZ Virtualization . . . . . . . . 5.6 APPENDIX: Installation of Asterisk . . . . . . . . 5.7 Conguration of the server . . . . . . . . . . . . . . i 1 2 2 4 4 6 7 7 7 8 9 9 10 10 11 12 12 13 14 15 15 16 18 19 20 21 23

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

5.8 5.9 5.10 5.11 5.12 5.13 5.14

APPENDIX: Mail Server Installation on VPS . . . . . . APPENDIX: Experiment on CISCO 3560G series switch Conguration steps . . . . . . . . . . . . . . . . . . . . . APPENDIX: Installation of OTRS . . . . . . . . . . . . Appendix: Installation of Moodle . . . . . . . . . . . . . Appendix: Securing Moodle . . . . . . . . . . . . . . . . APPENDIX: Installation of SVN . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

25 27 27 29 29 32 36 38

Bibliography

ii

List of Figures
2.1 5.1 5.2 5.3 5.4 CACTI Screenshot : Screenshot of suspicious trac . . . . . . Plan with VLANs . . . . . . . . Plan II : IP address distribution Plan using IP ranges . . . . . . Experiment using VLAN Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 16 17 18 27

iii

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 elds. 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 ecient 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 eciently. We worked with Dr Venkatesh Choppella, Dr Rene Ejury and Mr Amarnath Raja to achieve an ecient 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 institutes network infrastructure was analyzed which brought out several problems in the system. The analysis revealed the following problems with the current set up.

Suspicious trac in the network An investigation done analyzing the IPtable log on the gateway machine revealed some suspicious trac on the network. Hence CACTI, a monitoring tool, was installed to monitor the trac. The bandwidth analysis graph of CACTI, revealed unexpected peaks in the network trac. In the gure 2.1, on 10th of March a peak was occured. The normal trac 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 trac

Insucient 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 sucient for the proper functioning of an institution where the bandwidth is shared for browsing and running the web-servers. More over the suspicious trac mentioned above was also adding to the cause.

DoS Attack, installed Rootkits Malicious software has been identied on the servers running on the institute. These so called root kits have inltrated the servers and have been generating unwanted trac 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. 3

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 dicult 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
2.2.1

Rebuilding and Restructuring of networks

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 justications 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. Dierent 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 dierent buildings under one virtual LAN. The detailed plan is described on APPENDIX 5.1. We experimented the VLAN conguration 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 conguration is found to be dicult 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 dierent 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. Trac 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. Dierent 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 veried 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 dierent 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.

Conguration of Gateway The rewall 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 rewall. In the present system all the rewall rules are included in a shell script which could be run to put up the rewall. The external connections end up in this rewall and all the packets are ltered 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 Conguration 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 dierent 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, dierent 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. 7

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 192.168.0.50 OpenVZ1 192.168.0.51 libra 192.168.0.52 scorpio 192.168.0.53 Taurus 192.168.0.54 Capricon 192.168.0.107 svn 192.168.0.108 aries 3.1.2 OpenVZ Virtualization Comparison

Services OpenVZ CACTI Wiki Asterisk IIITMK-Moodle SVN OTRS

1. In the case of the xen virtualization each virtual servers will have its own kernel. So if some applications need kernel modications, it might be dicult 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 congured. The type of mail conguration 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 congured 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 congure your asterisk server for voicemail options. Three main protocols can be used in asterisk : IAX2, SIP and H323. I have congured the server to run between both IAX2 and SIP. Installation can be done in two ways, either from the compiled les or from the source code. In the rst method already compiled le will be available and you need only to install it from those les. And in the second method, rst 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 conguring the Asterisk server to make conference calls, a timing device is needed to synchronize the 9

voices from dierent 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. The detailed description of the installation can be found in APPENDIX 5.3. This has been documented in wiki [7] also.

3.4

Ticketing System - OTRS

In the institution no ticketing system were available. All the user queries were done manually. Eventhough 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 stas 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 ,conguration and managment 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 snied. 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 specically enabled on the web server. Moodle uses Apache webserver and it has a module called mod_ssl 10

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 prex 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 certicate to operate a secure server. Webserver can either purchase a Certicate Authority-signed certicate or a self-signed certicate. A CA-signed certicate provides two important capabilities for your server: Browsers automatically recognize the certicate and allow a secure connection to be made without prompting the user. When a CA issues a signed certicate, it is guaranteeing the identity of the organization that is providing the web pages to the browser. To get a certicate from CA, the requesting company has to send a certicate request which includes the public key, proof of the company identity, and payment to the Certicate Authority(CA). We are using a self-signed certicate and the procedure for generating the self signed certicate 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 le. SVN can be thought as a centralized le server. The les in the central repository could be managed and modied 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.

11

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 dicult for the management of SVN service as anything done in that machine for management of SVN service may possible eect the gateway congurations. 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 dicult. 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 dicult 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 certicate access. Users manage their own repositories and svn-user authentication 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 repositories so that svnserve process have access to those repositories.

12

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 trac from inside an organization 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 congured SVN server with Apache so that HTTP access was possible for SVN repositories. The details of installation can be found in APPENDIX 5.14.

13

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 reinstalled according to the new plan. The gateways in the institution were congured. The new gateways have scipts explaining each rule. The SVn service was congured for http access. Asterisk was congured 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 dicult as the administrator need to modify the conguration 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 congured to make external calls too. The OTRS system installed in the institution can be made to have external access.

14

Chapter 5 Appendices
5.1 APPENDIX : Plan I proposed

According to this plan the whole institution will come under a single network. Dierent user groups will be separated within the network using virtualization . 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 conguration 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 connected to the Internet through routers. Park Center : In Park Center router, rewall and proxy will be congured 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 congured to have VLANs. Using VLAN conguration the above listed user groups are formed. In Park Center all the servers will be run in dierent 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 congured to have VLANs. Here also dierent VLANs are formed as in Park Center. 15

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 dierent networks rather than using VLANs. The communication between the networks can be achieved through router conguration. The chosen IP address ranges are shown in Figure 5.2 Maintaining the mail server, moodle and wiki is found to be dicult 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

16

Figure 5.2: Plan II : IP address distribution

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.

17

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 conguration le xen-tools.conf can be found in the directory /etc/xentools/. In the conguration le the lvm should be the name of volume group. According to networking setup in the institution gave the networking parameters 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 conguration le. After that created the VPS(Virtual Private Server). When a VPS is created for the rst time used the default conguration 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 conguration 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 conguration 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 installation 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 congure the machine according to the installation : ./congure 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 : ./congure 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. 22

5.7

Conguration of the server

There are lots of conguration les coming with the asterisk installation. All those les are located in /etc/asterisk. cd /etc/asterisk will lead you there. The main four conguration les used for the conguration are : 1. sip.cong 2. extensions.conf 3. voicemail.conf 4. meetme.conf All these conguration les use a scripting language. Editing these les will make you add more functionalities for your server. iax.conf Registration of dierent 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 ashas 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 exten exten exten => => => => 100,1,Dial(IAX2/asha,50) 100,2,VoiceMail(100@voicemail) 8100,1,VoicemailMain(100@voicemail) 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 ashas 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 congured 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 notication in her mail which is being congured in the voicemail.conf .

24

voicemail.conf Here the voicemail options are congured. 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 conguring for asha. Her number is 100 and her voicemail box number is 8101 which is specied in extensions.conf. Her password is 333 which she has to respond to the Interactive Voice Response(IVR) when she dials to 8101. And an e-mail notication 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 congured for making conference calls. Inside rooms, you can have dierent 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 conguration : 25

# dpkg-reconfigure exim4-config 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/ 26 :

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 machines 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 congured 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

Conguration steps

Accessed the switch using : # telnet 172.168.0.10 27

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 conguration entered the conguration 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 congured 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 congure 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 congure it as VLAN2 by, switch(config)# interface gigabitethernet0/3 This lead to interface conguration 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 congured the gigabitethernet0/5 interface for vlan 3. After that tried some pings which proved that experiment is successful. After the conguration the two machine coming under VLAN3 is found to be reachable (pinging succeeded) each other. 28

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. Using 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 administrator password. By giving them the installation automatically created the database for otrs. A mail server is also congured on the machine in order to send mails to external email ids. The mail server used was exim4. The conguration 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 29

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/cong.php. CFG->wwwroot = http://ipaddress/moodle 30

Then modify /etc/apache2/conf.d. Comment deny from all and Uncomment 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 install.php followed by a series of pages. Providing the necessary information like database name , database password etc, on this pages creates cong.php le. Finally Moodle home page will be displayed and the administrator user can login and perform the rest of the conguration. Now enjoy Moodling.

31

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 Certicate Signing Request (CSR) To generate the Certicate 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 certicate, run the following command at a terminal prompt: openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

32

The above command will prompt to enter the passphrase. On entering the correct passphrase, certicate will be created and stored in server.crt le Next step is installation of the key le server.key and certicate le server.crt or the certicate. 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 33

<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

34

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

35

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 subdirectories. 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/ admin/ for svn administration for system administration scripts etc.

Only repositories can be checked out.

36

Steps for starting a new project : 1. create a new repository under (a sub-directory of) /var/www/svn. Example: 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 conguration setup for repository without authentication # /projects/project1 # -------<Location /svn/projects/project1> DAV svn SVNPath /var/www/svn//projects/project1 </Location> conguration 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> 37

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 dont 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)

38

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, OReilly Media, 2005. [3] OpenVZ Wiki, OpenVZ http://wiki.openvz.org/Main_Page [4] Shabeerali, A.V: Systematic Approaches Taken To Apply Software Engineering And Applications In Assisting With The Principles Of Programming 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 39

[10] Asteriskguru: Asterisk forum http://asteriskguru.org/board/ [11] OpenVZ: Openvz forum. http://forum.openvz.org/ [12] Ubuntu Documentation: HTTPS Conguration 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

40