From EGIWiki
Revision as of 16:42, 17 June 2010 by Ljocha (talk | contribs) (Created page with 'This page contains technical details on the services of [ EGI intranet] provided by [ CESNET]. == Technical background == ==…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This page contains technical details on the services of EGI intranet provided by CESNET.

Technical background


There are two identical servers:

Both the machines are connected to the same disk array:

  • FlexySTOR 162SS
  • 16x 450 GB SAS, 15 krpm disks
  • RAID controller, 2 GB cache
  • the disks are arranged into 2 RAID-10 partitions, yielding 2x 1.8 TB effective capacity

The system is covered with Next-Business-Day On-Site warranty agreement.

In normal operation each of the machine works in one of the disk array partition, The actual services are implemented in virtual machines, and they are distributed between the physical machines, in order to optimize load.

In case of failure of any of the physical machines the other one takes over hosting the affected virtual machines. Due to the dual connection of the disk array this can be done without the need of any cable switching. Eventually, an automatic failover mechanism can be deployed.

The machines are situated in the computer room of Institute of Computer Science of Masaryk University, Brno, CZ.

Status: done

Network connectivity

The computer room where the machines are located is in the same building as the Point of Presence of the CESNET network backbone. The LAN segment of the servers is directly attached to the backbone router port currently, planned final connection is via Masaryk University 10 GE backbone (still short connection within adjacent computer rooms in the same building).

Status: done


Besides the redundancy provided of hot-swappable RAID-10 disk arrays all the systems are backed up with the CESNET tape systems.

Status: to be configured by each virtual machine once its main configuration is finished.

Operating system and software environment

The servers above run Debian 5.0, Xen Dom0. Otherwise there are virtually no services installed.

The virtual servers described bellow are run as Xen DomU, running Debian 5.0 as the guest OS as well. Debian was chosen because of stability; among free Linux distributions it has the longest lifetime of stable major releases. We do not expect the need for bleeding edge functionalities in these services therefore stability is prefered.

As a rule of thumb, the EGI services do not depend on any external services outside of this system, apart of DNS and email.

Server certificates

The policy of TERENA SSL CA (used by CESNET servers) does not allow issuing a certificate for servers in the domain to CESNET, we have to receive it via EGI.EU organization and/or NIKHEF.

Status: done

Software customization

Common authentication and authorization

Due to the nature of the services, the primary authentication method will be username/password. Over the time we will investigate possibilities to integrate Shibboleth and X509 certificate based AuthN, however, the username/password will remain as the fallback method.

The goal is having a single username/password for all the services. Candidate technical solution is LDAP.


  • LDAP server installed and running
  • user accounts created from mailing lists' members, username were manually invented
  • groups for lists created, marked with attribute "businessCategory: mailman", users assigned to groups
  • Mailman list members and their passwords are synchronized (daily) with LDAP
  • Mediawiki has LDAP extension installed, all users from LDAP can log in
  • DocDB authentication is based on LDAP
  • web application for editing passwords and registration is at
  • group owners can manage group members thru the same
  • group owners can ask new people to become users and specify groups for them


  • Mediawiki needs exntension for page protrection based on LDAP groups
  • OpenCMS needs LDAP plugin
  • Indico LDAP support is not known, but there are some remarks about CERN lightweight account in the documentation

Mailing lists

Status: Done.

Disk partitions

For the purpose of mutual isolation, separate partitions are used:

The sizes are minimalistic, and the filesystems (using XFS) can be extended as needed.
/ 5 GB root filesystem
/var/logs 2 GB all logs
/var/lib/mailman/archives 2 GB mailman archives

HTTP server

Apache2, out of the Debian distribution. Its purpose is administrative Mailman interface and access to the mailist archives only.

Because most of traffic is expected to be authenticated, port 80 (HTTP default) is redirected to 443 (HTTPS).

Status: done

Mailman software

Out of Debian distribution.

Individual mailing lists will be created and removed by the server admins (the set is expected to be semi-static).

Management of the individual lists can be delageted to any of the system users. Technically done by access control in Apache configuration (each Mailman list has a unique URL prefix).

Status: done.

Incoming email

The only MX DNS record for points to the Masaryk University mail relay (located in the same building, serving in the same way for several other domains). The relay forwards all mail to via special rule in its config.

In this way we gain additional reliability and advanced features of the relay (spam and virus protection).

Status: done

Outgoing email

Using "smart host" for all outgoing email. The relay admin accepts it, and the symmetric setup may have benefits in case of paranoid recipients.

Status: done

Spam and virus protection (our MX) implements Grey listing technique to ban naive spam attacks.

In addition, spam detection will be set up locally on with Spamassassin, using combination of reliable black lists, static rules for well-known spam patterns (Viagra, Nigerian spam, ...), and dynamic Bayes filters tuned with real trafic gradually.

Exact strategy what to do with spam positives has still to be defined, and it may vary among different lists. In general, as long as it's possible with the amount of the traffic, I'm in favour of moderating to let false positives pass rather than discarding automatically.

Viruses are detected at with Kaspersky Antivirus, and positives are bounced back to the sender.


  • Spamassassin to be deployed and configured
  • Spam handling strategies to be defined

Web server

WWW front-end for all the services.

Apache2 from Debian distribution.


  • Installation of OpenCMS done.
  • Accounts for content maintainers created.
  • page template created from pages
  • menu and breadcrumbs implemented
  • Google Analytics deployed
  • news and their RSS feed created
  •  administration interface is at
  • real SSL certificate installed


  • install LDAP plugin for CMS

Document server

Basic setup of DocDB done here (requires authentication) but not fully working yet.


  • broken help
  • accents in names
  • manually introduced institutions

Status: done except LDAP authentication in OpenCMS

Meeting planner


Virtual host (in terms of Apache, not Xen), on


  • select and install some extension for restricting access to selected pages


  • webserver running
  • MediaWiki installed
  • LDAP plugin installed
  • google analytics activated
  • real SSL certificate installed

Request tracker


Other and auxiliary services

Virtual host (in terms of Apache, not Xen), on

Status: webserver running with a self-signed SSL certificate, CMS configured, page template finished


  • get a real SSL certificate

Service machine (invisible from outside) hosting database backends of the services.

A separate Xen host, so that we are able to move it to other hardware for performance tuning.