slideshow 1 slideshow 2 slideshow 3

Xen randomly crashing server

It's a long story... an oddessey of almost two years...

But to start from the beginning: Back then I rented a server at Hetzner until they decided to bill for every IP address you got from them. I got a /26 in the past and so I would have to pay for every IP address of that subnet in addition to the server rent of 79.- EUR/month. That would have meant nearly doubling the monthly costs. So I moved with my server from Hetzner to rrbone Net, which offered me a /26 on a rented Cisco C200 M2 server for a competitve price.

After migrating the VMs from Hetzner to rrbone with the same setup that was running just fine at Hetzner I experienced spontaneous reboots of the server, sometimes several times per day and in short time frame. The hosting provider was very, very helpful in debugging this like exchanging the memory, setting up a remote logging service for the CIMC and such. But in the end we found no root cause for this. The CIMC logs showed that the OS was rebooting the machine.

Anyway, I then bought my own server and exchanged the Cisco C200 by my own hardware, but the reboots still happen as before. Sometimes the servers runs for weeks, sometimes the server crashes 4-6 times a day, but usually it's like a pattern: when it crashes and reboots, it will do that again within a few hours and after the second reboot the chances are high that the server will run for several days without a reboot - or even weeks.

The strange thing is, that there are absolutely no hints in the logs, neither syslog or in the Xen logs, so I assume that's something quite deep in the kernel that causes the reboot. Another hint is, that the reboots fairly often happened, when I used my Squid proxy on one of the VMs to access the net. I'm connecting for example by SSH with portforwarding to one VM, whereas the proxy runs on another VM, which led to network traffic between the VMs. Sometimes the server crashed on the very firsts proxy requests. So, I exchanged Squid by tinyproxy or other proxies, moved the proxy from one VM to that VM I connect to using SSH, because I thought that the inter-VM traffic may cause the machine to reboot. Moving the proxy to another virtual server I rented at another hosting provider to host my secondary nameserver did help a little bit, but with no real hard proof and statistics, just an impression of mine.

I moved from xm toolstack to xl toolstack as well, but didn't help either. The reboots are still happening and in the last few days very frequent. Even with the new server I exchanged the memory, used memory mirroring as well, because I thought that it might be a faulty memory module or something, but still rebooting out of the blue.

During the last weekend I configured grub to include "noreboot" command line and then got my first proof that somehow the Xen network stack is causing the reboots: 

This is a screenshot of the IPMI console, so it's not showing the full information of that kernel oops, but as you can see, there are most likely such parts involved like bridge, netif, xenvif and the physical igb NIC.

Here's another screenshot of a crash from this night: 

Slightly different information, but still somehow network involved as you can see in the first line (net_rx_action).

So the big question is: is this a bug Xen or with my setup? I'm using xl toolstack, the xl.conf is basically the default, I think: 

## Global XL config file ##

# automatically balloon down dom0 when xen doesn't have enough free
# memory to create a domain

# full path of the lockfile used by xl during domain creation

# default vif script

With this the default network scripts of the distribution (i.e. Debian stable) should be used. The network setup consists of two brdiges: 

auto xenbr0
iface xenbr0 inet static
        bridge_ports eth0
        pre-up brctl addbr xenbr0

auto xenbr1
iface xenbr1 inet static
        pre-up brctl addbr xenbr1

There are some more lines to that config like setting up some iptables rules with up commands and such. But as you can see my eth0 NIC is part of the "main" xen bridge with all the IP addresses that are reachable from the outside. The second bridge is used for internal networking like database connections and such.

I would rather like to use a netconsole to capture the full debug output in case of a new crash, but unfortunately this only works until the bridge is brought up and in place: 

[    0.000000] Command line: placeholder root=UUID=c3....22 ro debug ignore_loglevel loglevel=7 netconsole=port@,514@5.45.x.y/e0:ac:f1:4c:y:x
[   32.565624] netpoll: netconsole: local port $port
[   32.565683] netpoll: netconsole: local IPv4 address
[   32.565742] netpoll: netconsole: interface 'eth0'
[   32.565799] netpoll: netconsole: remote port 514
[   32.565855] netpoll: netconsole: remote IPv4 address 5.45.x.y
[   32.565914] netpoll: netconsole: remote ethernet address e0:ac:f1:4c:y:x
[   32.565982] netpoll: netconsole: device eth0 not up yet, forcing it
[   36.126294] netconsole: network logging started
[   49.802600] netconsole: network logging stopped on interface eth0 as it is joining a master device

So, the first question is: how to use netconsole with an interface that is used on a bridge?

The second question is: is the setup with two bridges with Xen ok? I've been using this setup for years now and it worked fairly well on the Hetzner server as well, although I used there xm toolstack with a mix of bridge and routed setup, because Hetzner didn't like to see the MAC addresses of the other VMs on the switch and shut the port down if that happens.


Letsencrypt: challenging challenges solved

A few weeks ago I was wondering in Letsencrypt: challenging challenges about how to setup Letsencrypt when a domain is spread across several virtual machines (VM). One of the possible solutions would be to consolidate everything on one single VM, which is nothing I would like to do. The second option would need to generate the Letsencrypt certs on the webserver and copy over the certs to the appropriate VM on a regular basis or event driven. The third option is to use a network share - and this is what I'm using right now.

So, my setup is as following after I solved the GlusterFS issue with rpcbind binding to all interfaces, although it has been configured to only listen to certain interfaces (solution was: simply remove all NFS related stuff):

On Dom0 (or the host machine) I run GlusterFS as a server on a small 1 GB LVM as part of a replicate with the VM that will do the actual Letsencrypt work: 

Volume Name: le
Type: Replicate
Status: Started
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Brick1: 192.168.x.254:/srv/gfs/le
Brick2: 192.168.x.1:/srv/gfs/le

This is to ensure that on reboot of the machine every other VM using Letsencrypt certs can mount the GlusterFS share, because the host machine will be there for sure whereas the other VM generating the certs with the script might still be booting. And when the GlusterFS share is missing services will not start on the other VMs because of the missing certs, of course. So, the replica on the virtualization host (Dom0) is only acting as some kind of always-being-available network share, because, well, the other VM will not always be there... for example during a kernel update when a reboot is required.

The same setup is on my mailserver, acting as the second GlusterFS brick of that replica drive. The mailserver hosts the bind9 nameserver as well and I might do something that new domains with Letsencrypt certs get added to my DNSSEC setup as well. Of course, when the script creates or updates the certs, it needs the certs being mounted in that configured location, so I needed to add a line to /etc/fstab: 

192.168.x.254:/le /etc/ glusterfs noexec,nodev,_netdev 0 0

Basically the same needs to be done on the other VMs where you want to use the certs as well, but you may want to mount the share as read-only there.

The next step was a little more tricky. When generates new certs, Letsencrypt will contact the webserver for that domain to respond to the ACME challenge. This requires that on each VM you want to use letsencrypt you have to run a webserver. Well, actually at least that there is somewhere a webserver that can answer these requests for that specific domain...

Now, the setup of the webserver (Apache in my case) is like this: 

I'm using the Apache macro module to make it more easy, so I generated two small configs in /etc/apache/conf-available and enabled them bei a2enconf: letsencrypt-proxy.conf to do some setup for proxying the ACME challenges to a common website called And then letsencrypt-sslredir.conf to setup SSL redirection when everything is in place and the domain can be switched over to HTTPS-only.


<Macro le_proxy>
     ProxyRequests Off
     <Proxy *>
            Order deny,allow
            Allow from all
     ProxyPass /.well-known/acme-challenge/
     ProxyPassReverse / http://%{HTTP_HOST}/.well-known/acme-challenge/


<Macro le_sslredir>
    RewriteEngine on
    RewriteCond %{HTTPS} !=on
    RewriteRule . https://%{HTTP_HOST}%{REQUEST_URI}  [L]

So, after all the setup of a virtual host for Apache looks like this: 

(lots of setup stuff)
<VirtualHost 31.172.31.x:443 [2a01:a700:4629:x::1]:443>
        Header always set Strict-Transport-Security "max-age=31556926; includeSubDomains"
        SSLEngine on
        # letsencrypt certs:
        SSLCertificateFile /etc/
        SSLCertificateKeyFile /etc/
        SSLHonorCipherOrder On
    Use le_proxy
<VirtualHost 31.172.31.x:80 [2a01:a700:4629:x::1]:80>
    Use le_proxy
    Use le_sslredir

le_sslredir is only needed when you are sure that you want all traffic being redirected to HTTPS. For example when your blog is listed on or other Planets you might want to omit this from your HTTP config because bug #813313 is not yet solved. 

In the end, when creating a new Letsencrypt cert, you need to add the le_proxy macro to your website, add the domain to config in /etc/ and then the scripts will request a new cert from Letsencrypt, handling the ACME challenge stuff via the URL redirection in le_proxy being redirected to your site and finally writes your new cert to the GlusterFS share. From that share you can then use the new cert on all needed VMs, be it your mailserver, webserver or XMPP/SIP server VMs. 

At least this works for me.

Of course you should be careful about your file permissions on that GlusterFS share, so that the automatic key renewal works, but also without too many permissions granted that everyone can obtain your private keys.


Letsencrypt - when your blog entries don't show up on Planet Debian

Recently there is much talk on Planet Debian about LetsEncrypt certs. This is great, because using HTTPS everywhere improves security and gives the NSA some more work to decrypt the traffic.

However, when you enabled your blog with a LetsEncrypt cert, you might run into the same problem as I: your new article won't show up on Planet Debian after changing your feed URI to HTTPS. The reason seems to be quite simple: planet-venus, which is the software behind Planet Debian seems to have problems with SNI enabled websites.

When following the steps outlined in the Debian Wiki, you can check this by yourself: 

INFO:planet.runner:Fetching via 5
ERROR:planet.runner:HttpLib2Error: Server presented certificate that does not match host {'subjectAltName': (('DNS', ''), ('DNS', '')), 'notBefore': u'Jan 26 18:05:00 2016 GMT', 'caIssuers': (u'',), 'OCSP': (u'',), 'serialNumber': u'01839A051BF9D2873C0A3BAA9FD0227C54D1', 'notAfter': 'Apr 25 18:05:00 2016 GMT', 'version': 3L, 'subject': ((('commonName', u''),),), 'issuer': ((('countryName', u'US'),), (('organizationName', u"Let's Encrypt"),), (('commonName', u"Let's Encrypt Authority X1"),))} via 5

I've filed bug #813313 for this. So, this might explain why your blog post doesn't appear on Planet Debian. Currently there seem 18 sites to be affected by this cert mismatch.


AKtiVCongrEZ 2016 in Hattingen

Letzte Woche war es wieder soweit: der AKtiVCongrEZ in Hattingen fand statt. Das ist eine Veranstaltung, die von Digitalcourage veranstaltet und von der Bundeszentrale für politische Bildung und dem DGB Bildungswerk gefördert wird und bei der sich viele tolle Menschen, die sich rund um Datenschutz und Menschenrechte engagieren, zusammenkommen und Akionen planen.

Auch dieses Mal war die Veranstaltung ausgebucht, was ungefähr ca. 60 Leute bedeutet, die von Donnerstag abends bis Sonntag nachmittags selber ein volles Programm fertigstellen und abarbeiten. Auf Einzelheiten kann und werde ich natürlich nicht eingehen, aber ein paar Sachen fielen mir dennoch auf, die ich hier gerne ansprechen möchte: 

  • Es ist fast wie ein Familientreffen. Viele der Anwesenden sind altbekannte Aktivisten und jedes Jahr in Hattingen, auch wenn ab und zu natürlich jemand mal verhindert ist, ist es eine große Freude und Ehre, diese außergewöhnlichen Menschen zu treffen.
  • Auch wenn so viele Teilnehmer jedes Jahr wiederkommen, waren dieses Jahr ungewöhnlich viele Neue dabei. Es stimmt zuversichtlich, daß soviele Menschen den Bedarf sehen, aktiv zu werden und etwas gegen den ausufernden Überwachungsstaat zu unternehmen.
  • Auch wenn in den vielen Workshops sehr produktive Arbeit geleistet wird, sind eigentlich die Pausen und die Abende das eigentlich Wichtige an der ganzen Veranstaltung: das Kennenlernen der Aktivisten untereinander und der Austausch mit ihnen miteinander in vielen tollen und interessanten Diskussionen, die häufig bis in die späte Nacht bei einem Bier oder anderem Getränk stattfinden.

rpcbind listening on all interfaces

Currently I'm testing GlusterFS as a replicating network filesystem. GlusterFS depends on rpcbind package. No problem with that, but I usually want to have the services that run on my machines to only listen on those addresses/interfaces that are needed to fulfill the task. This is especially important, because rpcbind can be abused by remote attackers for rpc amplification attacks (dDoS). So, the rpcbind man page states: 

-h : Specify specific IP addresses to bind to for UDP requests. This option may be specified multiple times and is typically necessary when running on a multi-homed host. If no -h option is specified, rpcbind will bind to INADDR_ANY, which could lead to problems on a multi-homed host due to rpcbind returning a UDP packet from a different IP address than it was sent to. Note that when specifying IP addresses with -h, rpcbind will automatically add and if IPv6 is enabled, ::1 to the list.

Ok, although there is neither a /etc/default/rpcbind.conf nor a /etc/rpcbind.conf nor a sample-rpcbind.conf under /usr/share/doc/rpcbind, some quick websearch revealed a sample config file. I'm using this one: 

# /etc/init.d/rpcbind

# Cause rpcbind to do a "warm start" utilizing a state file (default)
# OPTIONS="-w "

# Uncomment the following line to restrict rpcbind to localhost only for UDP requests
# -h ::1"

# Uncomment the following line to enable libwrap TCP-Wrapper connection logging

As you can see, I want to bind to After a /etc/init.d/rpcbind restart verifying that everything works as desired with netstat is showing...

tcp 0 0* LISTEN 0 2084266 30777/rpcbind
tcp6 0 0 :::111 :::* LISTEN 0 2084272 30777/rpcbind
udp 0 0* 0 2084265 30777/rpcbind
udp 0 0* 0 2084264 30777/rpcbind
udp 0 0* 0 2084260 30777/rpcbind
udp6 0 0 :::848 :::* 0 2084271 30777/rpcbind
udp6 0 0 ::1:111 :::* 0 2084267 30777/rpcbind

Whoooops! Although I've specified that rpcbind should only listen to (and localhost as described by the man page) rpcbind is still listening on all addresses. Quick check if the process is using the correct options: 

root     30777  0.0  0.0  37228  2360 ?        Ss   16:11   0:00 /sbin/rpcbind -h -l

Hmmm, yes, -h is specified. Ok, something is going wrong here...

According to an entry in Ubuntus Launchpad I'm not the only one that experienced this problem. However this Launchpad entry mentioned that upstream seems to have a fix in version 0.2.3, but I experienced the same behaviour in stable as well as in unstable, where the package version is 0.2.3-0.2. Apparently the problem still exists in Debian unstable.

I'm somewhat undecided whether to file a normal bug against rpcbind or if I should label it as a security bug, because it opens a service to the public that can be abused for amplification attacks, although you might have configured rpcbind to just listen on internal addresses.


Diskussion um Obergrenzen

In Medien und Politik wird derzeit hitzig über etwaige Obergrenzen für Flüchtlinge diskutiert.

Was soll ich sagen? 

Die Diskussion ist reiner Populismus, der nur den Parteien am äußeren rechten Rand nutzt. Die Diskussion schürt zudem den Haß auf Fremde. Und alle, die sich für Obergrenzen stark machen, sei es nun von der CDU, CSU, SPD oder anderen Parteien, machen sich im Prinzip mitschuldig, wenn irgendwo in Deutschland Flüchtlingsheime brennen.

Das Grundrecht auf Asyl ist ein persönliches Grundrecht, d.h. es steht jedem Menschen zu. Das läßt sich nicht regelmentieren oder ignorieren. Es ist ein ganz einfacher Fakt. Alles andere ist bloß widerlicher rechtsgerichteter Populismus.

Flüchtlinge, die oftmals lebensbedrohliche Strapazen auf sich nehmen, um in Deutschland oder der EU ihre Grundrecht auf Asyl ausüben zu können, verdienen unsere Hilfe und nicht diese grundrechtswidrige und menschenunwürdige Diskussion um Obergrenzen für Flüchtlinge. Wenn man die Anzahl der Flüchtlinge reduzieren will, dann muss man die Ursache der Flucht beheben: Krieg.

Doch genau da haben wir Deutschen als einer der weltweit größten Waffenexporteure eine enorme Mitschuld zu tragen. Wir beteiligen uns mit der Bundeswehr an fragwürdigen Kriegseinsätzen und wundern uns dann trotzdem noch, daß letztes Jahr nach offiziellen des UNHCR weltweit 60 Mio. Menschen auf der Flucht waren?

Bevor man nach Obergrenzen bei Flüchtlingen schreit, sollte man vielleicht mal in seiner eigenen Familiengeschichte nachforschen. Nach dem 2. Weltkrieg waren auch Millionen Deutsche auf der Flucht, so daß es nicht unwahrscheinlich ist, daß ein Großteil der Bevölkerung selber mittelbar von Flüchtlingen abstammen. Was wäre gewesen, wenn es schon damals Obergrenzen gegeben hätte? Welche Familienmitglieder, Nachbarn oder Kollegen gäbe es dann heute wohl nicht?

Jeder Mensch kann früher oder später zur Flucht gezwungen sein. Auch Du, lieber Leser. Oder ich. Das kann manchmal schneller gehen als man denkt. Würde man dann wollen, daß man an einer Grenze zu einem sicheren Land, in dem man Zuflucht suchen und Asyl beantragen möchte, abgewiesen zu werden, weil eine aus reinem rechtsgerichteten Populismus gezogene Obergrenze erreicht worden ist?

Nein, als Deutsche haben wir den Anspruch, quasi überall ungehindert einreisen zu können. Aber wir sind offenbar auch so egoistisch, daß wir das, was wir für uns selber einfordern, anderen nicht zugestehen wollen. Das ist nicht nur falsch oder peinlich, sondern auch in höchstem Maße unmoralisch und Unrecht.



Letsencrypt: challenging challenges

On December 3rd 2015 the Letsencrypt project went to public beta and this is a good thing! Having more and more websites running on good and valid SSL certificates for their HTTPS is a good thing, especially because Letsencrypt takes care of renewing the certs every now and then. But there are still some issues with Letsencrypt. Some people criticize the Python client needing root priviledges and such. Others complain that Letsencrypt currently only supports webservers.

Well, I think for a public beta this is what we could have expected from the start: the Letsencrypt project focussed on a reference implementation and there are already other implementations being available. But one thing seems to a problem within the design of how Letsencrypt works as it uses a challenge response method to verify that the requesting user is controlling the domain for which the certificate shall be issued. This might work well in simple deployments, but what about a little more complex setups like multiple virtual machines and different protocols involved.

For example: you're using domain A for your communication like for your mail, XMPP and SIP. Your mailserver runs on one virtual machine, whereas the webserver is running on a different virtual machine. The same for XMPP and SIP: a seperate VM as well. 

Usually the Letsencrypt approach would be that you configure your webserver (by configure /.well-known/acme-challenge/* location or use a standalone server on port 443) to handle the challenge response requests. This would give you a SSL cert for your webserver Of course you could copy this cert to your mail-, XMPP- and SIP-server, but then again you have to do this everytime the SSL cert gets renewed.

Another challenge is of course that you are not only have one or two domains, but a bunch of domains. In my case I host approximately >60 domains. Basically the mail for all domains are handled by my mailserver running on its own virtual machine. The webserver is located on a different VM. For some domains I offer XMPP accounts on a third VM.

What is the best way to solve this problem? Moving everything to just one virtual machine? Naaah! Writing some scripts to copy the certs as needed? Not very smart as well. Using a network share for the certs between all VMs? Hmmm... would that work?

And what about TLSA entries of your DNSSEC setup? When a SSL cert is renewed than the fingerprint might need an update in your DNS zone - for several protocols like mail, XMPP, SIP and HTTPS. At least the Bash implementation of Letsencrypt offers a "hook" which is called after the SSL cert has been issued.

What are you ways to deal with this kind of handling the ACME protocol challenges and multi-domain, multi-VM setup?


Guerillero vs. Terrorist

Der Guerillero besetzt das Land,
der Terrorist besetzt das Denken.

aus: "Verdächtig" von Heribert Prantl, S. 19.

'nuff said...


Was man nicht hören möchte...

Dieser Tage hört man Töne aus MV, die aus längst vergangenen Tagen stammen könnten: 

  • "Deutschland sei ein deutsches Land"
  • "die Herausforderungen dürften nicht auf dem Rücken der eigenen Bevölkerung ausgetragen werden"
  • "die Flüchtlingskrise dürfe nicht zu einem Leistungsabbau für die Einheimischen führen"
  • "Deutschland sei nicht das Job-Center des Westbalkan"
  • man müsse "Verständnis für Teilnehmer der aktuellen ausländerfeindlichen Demonstrationen" haben, denn...
  • "Nicht jeder, der dort mitmarschiere, sei ein Ewiggestriger oder Rechtsradikaler"

Diese Aussagen stammen nicht von der NPD oder der AfD, sondern vom neuen, wiedergewählten Landesvorsitzenden der CDU in Mecklenburg-Vorpommern und derzeitigem Landesinnenminister in MV Laurenz Caffier. Der NDR berichtet auf seiner Webseite über die Wiederwahl Caffiers

Nationale Töne in Caffiers Rede

Caffier schlug aber auch nationale Töne an: Deutschland sei ein deutsches Land, die Herausforderungen dürften nicht auf dem Rücken der eigenen Bevölkerung ausgetragen werden, die Flüchtlingskrise dürfe nicht zu einem Leistungsabbau für die Einheimischen führen. Deutschland sei nicht das Job-Center des Westbalkan. Caffier warb um Verständnis für Teilnehmer der aktuellen ausländerfeindlichen Demonstrationen. Nicht jeder, der dort mitmarschiere, sei ein Ewiggestriger oder Rechtsradikaler.

Caffier betreibt damit Stimmenfang am äußerten rechten Rand. Eigentlich übernimmt er sogar deren Vokabular, so daß man attestieren muss, daß er sich faktisch mit diesen Aussagen genau auf die gleiche Stufe stellt wie NPD und AfD.

Ich finde das erschreckend und für unsere Demokratie beschämend, daß jemand mit solchen Aussagen von einer eigentlich anerkannten großen Partei, wie es die CDU nunmal ist, zu deren Landesvorsitzenden gewählt wird. Im Grunde müsste Caffier aufgrund dieser Aussagen sowohl als Landesvorsitzender als auch als Innenminister in MV zurücktreten müsste. Solche Aussagen sind einfach unhaltbar. Unglaublich.


Anschläge von Paris

Jeder war wohl fassungslos, als bekannt wurde, daß es am Freitag mehrere Anschläge in Paris gegeben hat, bei denen wohl über 100 Menschen starben. Das ist zweifelslos eine schreckliche Tat, die es aufzuklären und bei der es gilt, die Täter rechtsstaatlich zu verurteilen, soweit das noch möglich ist. Inzwischen soll sich auch der sogenannte "Islamische Staat" zu diesen Anschlägen bekannt haben.

Was mich aber auch fassungslos macht, ist wieder die Demagogie nach den Anschlägen, bei der die Anschläge zur Durchsetzung der eigenen politischen Agenda zu Lasten der Allgemeinheit dient. Es hatte keine 24 Stunden gedauert, bis Jörg Radek, der Vizechef der Gewerkschaft der Polizei (GdP) lauthals nach mehr Überwachung und mehr Befugnissen für die Polizei und die Geheimdienste gerufen hatte:

Die Ordnungshüter müssten in der Lage sein, derart blutige Taten "unter allen Umständen zu verhindern", erläuterte der GdP-Vize. Dazu sei es nötig in Erfahrung bringen zu können, wo terroristische Zellen seien, welche Personen darin verstrickt seien, mit wem diese Kontakt hätten und was sie planten. Die "Aufklärung" der Kommunikation solcher Kreise sei daher von entscheidender Bedeutung. Dem dürfe die immer wieder auflebende "unsinnige Debatte" über den "sogenannten Überwachungsstaat" nicht im Wege stehen. Nötig sei eine "intensive nachrichtendienstliche und polizeiliche Überwachung potenzieller Gefährder".

Arnold Plickert, der GdP-Chef Nordrhein-Westfalens, unterstützt den Appell seines Kollegen nach einer ausgeweiteten Vorratsdatenspeicherung: "Wir können damit möglicherweise zukünftige Terroranschläge verhindern, weil wir so an Informationen über die Terroristen kommen, an die wir sonst nicht gelangen". Die Speicherfristen müssten dafür aber bei mindestens einem Jahr liegen.

Beide GdP-Chefs übersehen jedoch, daß es in Frankreich exakt diese Vorratsdatenspeicherung über 1 Jahr bereits seit längerem gibt. Geholfen hat sie bei der Vermeidung dieser Anschläge natürlich wieder einmal rein gar nichts. Und offenbar bringt sie auch im Nachhinein nichts, da bereits jetzt dann eigentlich die Hintermänner und andere Kontakte der Attentäter bekannt sein sollten. Aber auch das ist genau das, was die Befürworter einer Vorratsdatenspeicherung immer ins Feld führen: Die VDS helfe dabei, Anschläge zu verhindern und wenn sie es schon nicht verhindern kann, dann helfe sie wenigstens bei der raschen Aufklärung. Doch wieder einmal ist außer heißer Luft und dem Abbau von Grundrechten nichts dabei herausgekommen. Zumindest keine Verhinderung noch Aufklärung der Anschläge.

Schlimmer noch sind Überlegungen von Frankreichs Präsidenten Hollande, dem NATO Generalsekretär Jens Stoltenberg und anderen: 

"Es ist ein Akt der absoluten Barbarei", begangen durch "eine Armee von Terroristen", erklärte François Hollande nach dem Treffen des Nationalen Verteidigungsrats während einer kurzen TV-Ansprache. "Es ist ein Angriff des 'Islamischen Staates', wir werden gnadenlos reagieren - auf allen Ebenen, in Abstimmung mit unseren Partnern", so der Staatschef. Später sagte er direkt, was er meint: "Konfrontiert mit Krieg muss die Nation angemessene Maßnahmen ergreifen."

Hollande sieht sich im Krieg, Frankreichs Presse sieht die Nation im Krieg, der Papst spricht gar vom Dritten Weltkrieg.

Von Krieg zu sprechen ist natürlich absoluter Quatsch. Die Anschläge wurden nach derzeitigem Stand von einer "Armee" von ca. 8 Leuten verübt. Der sogenannte "Islamische Staat" ist kein Staat. Dazu müsste dieses undefinierte Gebilde, das zwar viele Teile des Landes in Syrien und im Irak kontrolliert, aber weder über ein definiertes Staatsgebiet noch entsprechender staatlicher Strukturen in unserem Sinn verfügt, als Staat anerkannt sein. Ist es aber nicht. Es ist eine paramilitärische Gruppierung, die einer religiösen Weltanschauung anhängt, der die meisten anderen gläubigen Muslime aus guten Gründen nicht folgen.

Aus diesem Grunde kann es schon gar kein Krieg sein. Es fehlt einfach an den Voraussetzungen dafür, daß man da einen formalen Krieg führen kann. Aber diese Art der Kriegsführung ist ja sowieso in den letzten Jahrzehnten aus der Mode gekommen, spätestens seitdem auch die USA nach 9/11 ihren Krieg gegen den Terror erklärt haben - und damit eigentlich nur für noch mehr Terror in der Welt gesorgt haben. Unter anderem dürfte die Politik der USA im Irak, in Afghanistan und generell im Nahen Osten auch das Entstehen des "Islamischen Staats" begünstigt haben. Ein direkter Zusammenhang besteht da sicherlich nun nicht, aber vermutlich ein indirekter.

Die schlimmste Reaktion ist aber, daß nun wieder Politiker (insbesondere aus dem konservativen und rechten Lagern) die Anschläge mit einer Verschärfung der Einwanderungs- und Asylpolitik verknüpfen. Zwar sollen auch zwei der Attentäter über die Balkanroute nach Europa gekommen sein, aber diese wurden wohl ordnungsgemäß in Griechenland registriert. Außerdem steht das in keinem Verhältnis: jeden Tag fliehen Tausende aus Syrien vor dem Krieg und genau den Leuten, die nun in Paris die Anschläge verübt haben. Es ist widerlich, wie manche Politiker in diesen Tagen agieren. 

Europa braucht weder ein verschärftes Asylrecht noch neue Sicherheitsgesetze und auch keine anlaßlose Massenüberwachung aller EU-Bürger etwa durch eine Vorratsdatenspeicherung, Passenger Name Records oder einen Ausbau der Kompetenzen von Polizei und Geheimdienste. Und ganz sicher braucht Europa auch keine Rückkehr zu abgeschotteten Nationalstaaten und neu errichteten Grenzzäunen.

Europa braucht jetzt mehr denn je das Bekenntnis zu unseren Grundwerten wie Freiheit und Bürgerrechte. Diese jeden Tag aufs Neue auszuleben ist eine weitaus bessere Reaktion auf die Bedrohungen durch jedwede Art von Terror als all die Vorhaben, die unsere Politiker in den nächsten Wochen und Monaten durch die Parlamente peitschen werden. Laßt uns die Flüchtlinge aus den Kriegsgebieten weiterhin willkommen heißen und ihnen zeigen, daß sie hier gerade wegen unserer Freiheits- und Grundrechten sicher sind, auf daß sie dann irgendwann in ihre Länder zurückkehren können und dort ebenfalls ihre Grundrechte ausleben und einfordern. Nur so können wir auch weiterhin dem Terror die Stirn bieten.



Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer