Jump to: navigation, search

Άτομα: ~9
Ώρα έναρξης: 13:00
Διάρκεια: 6 ώρες
Τόπος: Ίδρυμα Καλοκαιρινού


These people are willing to help with the setup and maintenance of the servers:

  • gKiagia
  • zakkak
  • DaKnOb (penetration testing / security advice)
  • gKaklas
  • dimitriZ
  • zeptomoon
  • sque (probably)


Before we started discussing the technical subjects, we had a small discussion about the purpose of setting up community-maintained web services.

DaKnOb made the point that if we use services from Google (for example) then we can rely on their sophisticated security team, while we don't have such expertise in security. So our servers will be less secure, which would mean that mails on Google's servers can be read by Google (and Nat. Sec. Agencies), while mails on our servers could be read by any (malicious) hacker/cracker.

Jann replied, that although he may not be a security expert, he believes that running one's own servers with frequent security updates and a reasonable effort in hardening would result in servers, which are hard enough to crack, so that effectively only very targeted attacks would succeed. Such targeted attacks can never be 100% avoided, but our servers are highly unlikely to become a valuable target of a dedicated cracker. I.e. they are 'secure enough'. [Additionally I (Jann) want to point out that mass data collection and 'profiling' by "security agencies" is possible on Ggl/fb/etc but not on private servers.]

[Others have made further comments on that subject, I think. Please add here if I forgot something.]

Trust Issues[edit]

We pointed out that trust is an issue. (Who has access to which data?)

We suggested the following:

  • Different services / VMs / containers could be maintained by different people / teams for shared / divided responsibility
  • Admins should provide the maximum possible transparency, by keeping logs of what they do for example.
  • Distributed, encrypted systems are interesting (eg. red matrix)

The Services[edit]

We quickly went through the list of useful web services, we did not analyse the options deeply just we agreed that XMPP is better for us than IRC as a chat solution.

The services we mostly discussed about was the following:

  • e-mail: It should be easy for us, but we have to fix the problem we have with being marked as spam
  • owncloud: It is a very useful service and, according to Dimitris, people in the commonsfest do not use dropbox or googledrive so it is a good chance to introduce owncloud to them.
  • gitlab: We discussed that it makes sense only if we expect our users to setup private repositories. For open source projects there are many great alternatives out there, e.g., github, sourceforge etc.
  • etherpad: We concluded that it is a nice and useful service that we would like to provide. However, according to Dimitris to get private pads to work we need to put some hacking effort, since the corresponding plugin is not working properly. Commonslab has already a setup of etherpad which is not public however and Dimitris suggested that they could create a copy of their setup on their server to also provide a public etherpad. Again from my point of view there are public etherpads available out there so it would make sense to provide one only if we are going to support private pads.
  • dudle: Open source alternative to doodle. One can use the deployed instance on tu-dresden (https://dudle.inf.tu-dresden.de/). Should be light and easy to deploy if we decide that we want to setup an instance.
  • Online-Forms: Useful for getting feedback especially inside collaborative teams.
  • Social networking: (Friendica, Diaspora, etc.) Should be useful to collaborative communities, however Dimitris claims that they usually fallback to facebook and not use it.


The main idea behind the online-forms service is that (as dimitris proposed) it is probably better to ask our users what they need/want. At first, our users will be probably people from the commonsfest community, so if we can get a (digital) form ready we could circulate it through Dimitris and Jann to get some feedback.


We decided that a bare-bone with hypervisor and VMs would be the best solution, but we have to see if we can get enough money (users) to support that. Otherwise upgrading the LeaseWeb server with more ram and IPs could be an option (...if that is possible.)

About the software we decided to look into Docker as a solution to separate privileges and separate/ease maintenance, since using a large number (>6) of VMs eventually results in consumption of too much RAM.

Other virtualization and automation solutions have been mentioned (ansible), but we don't know which are realistically learnable/deployable by us. Docker seems to be a viable solution with a soft learning curve.

We suggested to use Squid as reverse proxy solution to save IPs and handle web-sockets and other advanced web technologies more reliably.

Behind the proxy we can set up services on their own sub-domains within containers or VMs based on Apache, node.js, nginX, Python or whatever.

We mentioned that OwnCloud and SpamAssasin (and gitlab) use a lot of RAM memory.

We need to look into the number of users that we can / want to support and the amount of money we can raise (every year) in order to finance the hardware.


We suggested to run a fund-raiser inside the CommonsLab DonationBox at the CommonsFest in Athens next month.


We agreed, that a firewall and a simple fail2ban can be easily installed, but do not provide a lot of protection/mitigation against security-relevant software bugs.

SElinux or AppArmor seem have stronger effect, but we don't have the knowledge to use them effectively.

[Backups, even off-site, are not a big problem, I think. But still we must find solutions :)]

Hands On[edit]

Later after the lunch break, dimitriZ, gKaklas and Jann decided that we would like to get some experience in setting up a VM and some Docker containers for practice, for example with OwnCloud and RoundCube, which are easy targets, but eventually the CommonsFest finished and it was postponed for probably the next HackDay.