Preparation of the Server I

Warning: This manual is no longer up to date!

!

Important: These recommendations are intended for people who install SoSci Survey on a virtual server (V-Server, VPS) or a root server. If you have only rented web space, you usually do not have to worry about the server settings.

If the data is transmitted unencrypted, it can be intercepted at many points on its way through the internet. A plausible scenario here would be the IT department taking a look at the responses in a company survey.

To solve this problem reliably, the data transmission can be encrypted by means of HTTPS or SSL. The data is then encrypted directly by the browser and only decrypted again on the server. An SSL certificate is available from 50 euros per year. You can also create certificates yourself, but as long as they are not certified, the browser displays a warning on every page.

To transfer data to the server, you will usually use an FTP program (e.g., FileZilla). For access to the database, maybe a convenient SQL frontend (e.g., HeidiSQL). However, if these are used without encryption, the passwords can be intercepted. Even if it probably happens rather rarely: The idea of criminals distributing spam or illegal content via your own server, or tapping data, is rather unpleasant.

If you can access the server encrypted via SSH, a lot of security can be achieved quickly: Simply select the encrypted variant SFTP instead of the transfer method FTP, and use PuTTY (which you probably use for shell access to the server anyway) to establish an encrypted SSH tunnel for MySQL. This also offers the security benefit that MySQL access can generally be restricted to the server (localhost), i.e., for example, a MySQL user admin@localhost instead of admin@%.

Detailed instructions (in German) for encrypted MySQL access are provided by Tsunamihost.

Web servers are only secure as long as they are up to date. If the hosting provider does not take care of the updates, you can conveniently do this yourself every few weeks. Log in to the shell via PuTTY, then enter the following commands:

apt-get update   (updates the software lists)
apt-get upgrade  (installs the updates)

Of course, there remains a residual risk that SoSci Survey might cause some problems on the new Apache or PHP version. But this risk is considerably lower than the danger posed by security holes in outdated software.

Even if a project manager disables the recording of IP addresses, it is possible in principle to reconstruct the IP address from the time of the survey and the entry in the server logfile. The practical risk of identifying individual persons this way certainly exists under certain circumstances, especially in company surveys. Identifying individual internet users, in contrast, is rather a hypothetical risk.

• A simple way to solve the problem is to disable the logfiles entirely. The disadvantage, however, is that no more information on the usage of the server is available either.
• It is much more elegant to anonymize the IP addresses themselves by storing only the first two bytes (digits) of the address. A Perl script that takes over this task on an Apache web server, and which you can install on your own server with a few clicks, is provided by ZENDAS.

To prevent emails from the server from ending up in spam filters or being blocked entirely (“connection refused”), some settings are required on the mail server:

• First of all, it is important that the From address (not the sender!) matches the mail server. This address is specified in the Apache configuration. Normally, this address should already be set correctly.
• It is advisable to create an SPF record in the DNS settings of the domain, which specifies who may send emails from the domain.
• The mail server requires a PTR record (reverse DNS), which should correspond to the host name that is transmitted when sending mails (e.g., /etc/mailname).
• Furthermore, you have to make sure that the IP address of the server does not get into trouble with blacklists (RBL). One possible cause is that the reverse DNS (rDNS) record is not correct. A problem that only the internet service provider can solve. Numerous RBLs can be checked on the following websites:
  • Blacklistalert.org
  • multirbl.valli.org
• Send a mailing to the service mail tester to quickly check essential settings of the mail server.

To store the data (Data in SoSci Survey), SoSci Survey uses the database engine InnoDB in a MySQL database (MySQL: Overview of InnoDB tables). Among other things, this has the advantage that various consistency checks are already performed by the database, e.g., questions or responses cannot accidentally be stored for a deleted project.

However, there are some differences between the default engine MyISAM and InnoDB. These may require a separate configuration:

• The InnoDB engine is enabled in MySQL by default, but may have been disabled to save RAM (MySQL: InnoDB: startup options). The SoSci Survey installation routine will indicate this problem, if applicable.
• All data that MySQL stores by means of InnoDB is stored in one (!) large file by default. Where this file is located is configured by means of innodb_data_file_path (MySQL: InnoDB configuration). This usually makes sense for the server performance. However, if other software besides SoSci Survey uses the InnoDB engine, you have to be aware that the data is inseparably merged in the file system – a separate backup by file backup is not possible then. With the option innodb_file_per_table, you can enforce the separation into individual files, should this be desired (MySQL: Using Per-Table Tablespaces).
• By default, InnoDB is configured to use only a small part of the RAM for caching indexes. If you keep a very large number of interviews (approximately 500,000 or more) in your database, adjusting the options innodb_buffer_pool_size and, accordingly, innodb_log_file_size is advisable so that the server can access the data quickly (MySQL Performance Blog).