Eine der häufigsten Fragen des Lebens.

Ich nutze seit Ewigkeiten https://heise.de/ip

Damit geht es aber auch via shell:

$ curl http://ifconfig.co
$ http -b http://ifconfig.co
$ wget -qO http://ifconfig.co
$ fetch -qo https://ifconfig.co

Da gibt es sicherlich noch 1-2 andere Möglichkeiten.

via  Herrn Grube

Link:

https://ifconfig.co/

Da sich bei Ubuntu 16.04 auch die Namen der NICs ändern (z.B. von eth0 zu ens192) muss man auch die Konfiguration der Ressourcen anpassen. Das kann man sicherlich innerhalb der Konfiguration via crm anpassen, aber löschen der Ressource und neu anlegen geht natürlich auch. Was dann in etwa so ausieht:

crm resource stop FAILOVER-ADDR
crm configure delete FAILOVER-ADDR
crm configure primitive FAILOVER-ADDR ocf:heartbeat:IPaddr2 params ip="1.2.3.4" nic="ens192" op monitor interval="10s" meta is-managed="true" 

Calibre-web ist eine Software um seine Ebooks via Webinterface zu verwalten. Als Grundlage dient dabei die bereits vorhandene Calibre Datenbank. Vor einiger Zeit hatte ich kurz etwas zu bicbucstriim und cops geschrieben. Wobei beide Projekte gut sind aber noch viel Luft nach oben lassen. Ein fehlendes Feature ist z. B. das Erstellen von eigenen Buchsammlungen, was beide Projekte nicht können. Bei calibre-web können Benutzer solche Buchsammlungen anlegen und verwalten. Zu dem hat man auch die Möglichkeit Metadaten im Webinterface zu verändern. Es empfiehlt sich calibre-web hinter einem reverse proxy wie nginx oder Apache laufen zu lassen, Beispiele dazu finden sich auf der Projektseite. Die Suche und generelle Performance ist bei cops deutlich besser, aber die Sache mit den eigenen Buchsammlungen ist ein fast unschlagbarer Pluspunkt für calibre-web. Man kann natürlich auch problemlos cops, calibre-web und bicbucstriim parallel laufen lassen.

Mirko Lindner hat zu calibre-web einen guten Artikel auf pro-linux geschrieben.

Nur ein kleiner Hinweis für mich

/etc/munin/plugin-conf.d/mysql_innodb

[mysql_innodb]
env.warning 0
env.critical 0

Steht im error.log von MySQL 5.7 etwas in der Art wie:

2018-02-02T13:30:24.539046Z 0 [Warning] Changed limits: max_open_files: 1024 (requested 5000)
2018-02-02T13:30:24.539087Z 0 [Warning] Changed limits: max_connections: 214 (requested 800)
2018-02-02T13:30:24.539091Z 0 [Warning] Changed limits: table_open_cache: 400 (requested 1024)

auch diverse Einträge mit „Too many open files“ sind ein Hinweis,

hilft (vielleicht) folgendes

systemctl edit mysql

eintragen:

[Service]
LimitNOFILE=8000

Dadurch wurde nun die Datei /etc/systemd/system/mysql.service.d/override.conf angelegt

systemctl daemon-reload
systemctl restart mysql

Nun sollten die Werte aus der mysqld.conf übernommen werden.

Eventuell nochmal mit

mysql> show variables like '%connections%';

usw. prüfen.

Warum weshalb wieso findet man unter:

https://dev.mysql.com/doc/refman/5.7/en/using-systemd.html

https://stackoverflow.com/questions/39976756/the-max-connections-in-mysql-5-7

https://stackoverflow.com/questions/32760202/buffered-warning-changed-limits-max-connections-214-requested-800/33464069

Der Reverse Proxy (Nginx) cached eine ganze Menge. Ein bestimmter Vhost (Apache) soll aber kein Caching machen. Einfach in die jeweilige .htaccess folgendes eintragen:

Header set Cache-Control "no-cache"

Nun wird für den Auftritt kein Caching mehr genutzt. Einfach mal mit einer Bilddatei testen.

Das wurde nur mal kurz getestet, eventuell ist das noch ausbaufähig.

Wer wie ich Hardware (VMs  sind je nach Konfiguration auch betroffen, siehe Link) mit mehreren Sockets benutzt wird eventuell in diesen Bug gelaufen sein:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883938

Im Bugreport stehen ein paar Workarounds (Kernelparam: maxcpus=1, nosmp oder numa=off), damit die Maschine wenigstens wieder bootet. Falls noch nicht geupdatet wurde am besten den momentanen Kernel pinnen oder einfach auf ein Update warten.

Bei Debian Derivaten läuft der Apache in der Regel mit www-data Benutzerrechten. Will man aber, dass der Apache unter verschiedenen Benutzern läuft wird es schon schwieriger. Da gibt es Lösungen wie zum Beispiel  mod_fcgid, PHP-FPM oder mpm-itk. Besonders das itk Modul fand ich im Vergleich zu PHP-FPM, sehr einfach zu konfigurieren. Getestet mit Debian 8 und Ubuntu 14.04.
Ein kleiness Beispiel:

apt-get install libapache2-mpm-itk

und in der jeweiligen Vhost Konfiguration trägt man folgendes ein:

<IfModule mpm_itk_module>
AssignUserId henry www-data
</IfModule>

Wobei henry der Benutzer und www-data die Gruppe ist.

Will man testen ob alles funktioniert, kann man einfach folgendes Skript ausprobieren:

<?php
$processUser = posix_getpwuid(posix_geteuid());
print $processUser['name'];
?>

Da sollte dann bei meinem Beispiel „henry“ angezeigt werden. Ansonsten einfach mal eine Datei via Webinterface hochladen und schauen wem Sie gehört.

Wichtig dabei ist, dass die jeweiligen Benutzer und Gruppen existieren müssen. Existiert z .B. kein henry oder keine Gruppe www-data, startet auch der Apache nicht. Bedeutet auch, falls man mit einer LDAP Benutzerverwaltung arbeitet und der LDAP läuft nicht stabil, sollte man die Benutzer aus dem LDAP auf den jeweiligen Webserver syncen. Auf der MPM ITK Seite findet man noch diverse andere Parameter wie z.B. MaxClientsVHost, AssignUserIDExpr, LimitUIDRange usw.

Die Anpassungen am System sind minimal, daher kann man das ITK Modul ohne großen Aufwand testen. Hat man sehr viele Vhost und arbeitet nicht mit Puppet&Co kann man auch  mit Apache Macros arbeiten, dann würde der Eintrag in etwa so aussehen:

in der vhost.conf:

Use itkmodul henry www-data

in der jeweiligen macro.conf

<Macro itkmodul $username $group>
<IfModule mpm_itk_module>
AssignUserID $username $group
</IfModule>
</Macro> 

Inwieweit das ITK Modul zusätzliche Sicherheitsprobleme mit sich bringen kann, hängt vom jeweiligen System ab und wie es konfiguriert ist. Da kann man sicherlich schnell etwas konstruieren.

Update: Anscheinend funktioniert das Modul nur für userids < 65535. (link). Eventuell besteht das Problem bei Ubuntu 16.04 nicht mehr (Test folgt).

Dies betrifft alle Betreiber eines x86 Gluon Systems. Das sind die Futros und Verwandte.

Ich nutze aus diversen Gründen ab und an XFCE in einer VNC Session unter Debian 8. Dabei fehlte mir aber die Tab Completion, was extrem nervig sein kann. Die Lösung für mein Problem war:

in der

~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml

folgendes editieren

<property name="&lt;Super&gt;Tab" type="string" value="switch_window_key"/>

wird zu

<property name="&lt;Super&gt;Tab" type="empty"/>

danach die VNC Session killen und neu starten.

Kein häufiges Problem nehme ich mal an ;-).

Ein tolles Plugin für Thunderbird um größere Dateien nicht via email verschicken zu müssen, sondern direkt über Nextcloud bereitzustellen zu können. Funktioniert auf den ersten Blick relativ problemlos. Man kann leider nicht pro mail ein neues Passwort definieren, ansonsten aber eine feine Sache.

https://addons.mozilla.org/de/thunderbird/addon/nextcloud-filelink/

Gibt es auch für Outlook. Kann ich aber  mangels Outlook nicht testen.

Chrome versteckt mittlerweile die Zertifikatsinformationen etwas.
Finden tut man sie durch aktivieren der Developer tools (F12) und dort unter Security.

Warum man die „versteckt“ ist mir aber schleierhaft. Damit wird der trust level eines Zertifikats auch immer unwichtiger, Hauptsache der Browser beschwert sich nicht. Mag man darüber denken was man will.

During the emergence of electronic communication, the two scientists/engineers Carl Friedrich Gauss and Wilhelm Eduard Weber built the first electrical communications line in Goettingen, Germany. They set up a two kilometer two wire copper line between Gauss’ workplace – the Astronomical Observatory – and Weber’s laboratory in the physics department of the Goettingen University.

It is unknown what the content of the first telegram sent was but one story goes like this: Gauss sent the message: “Michelmann kömmt” or “Michelmann is on his way” to Weber. While the message was transmitted, Michelmann, an assistant of both Gauss and Weber traveled the distance between the two sites, allowing the scientists to confirm the accuracy of the message ⁰.

Michelmann is a messenger or courier in this story. He helps Gauss and Weber demonstrate that their system works and that messengers can be replaced by electronic communication. I find it amusing and somewhat ironic that Michelmann played the role of verifying a technology that would take over some of his own responsibilities – relaying messages between Gauss and Weber.

Today technology is again taking over responsibilities previously held by humans: it trades stocks, drives cars and diagnoses and treats diseases. Sometimes I like to put myself in the shoes of those modern-day Michelmanns: humans that participate in handing over parts of their responsibilities to machines. Stock-brokers and data scientists that feed their knowledge into automated trading systems, ride sharing drivers that seed the offline maps for autonomous cars, medical doctors that train expert systems and image recognition algorithms to automate diagnosis and treatment.

Are these people aware of what they are doing? And how long until my job (software architect) can be replaced by a machine? Am I already doing what Michelmann did in 1832 by writing and fixing code and committing it to public repositories? I want to say: I hope so. But then again I’m only 97% convinced it is a good thing.

^{1. Another version of the story has Gauss send the message “Wissen vor meinen, Sein vor scheinen” which roughly translates to “Knowing is more important than believing, being is more important than appearance”. It is possible that they sent both messages, one test message and one message for posterity.↩}

Der V13 hat leider komplett andere Hardware als seine Vorgänger und wird auf absehbare Zeit vermutlich nicht von unserer Software unterstützt werden, da das Gerät einen völlig anderen WLAN-Chipsatz hat. Wir empfehlen derzeit lieber auf ein anderes Modell wie den WR842, WR940 und WR1043ND umzuschwenken. Sobald der V13 unterstützt wird, werden wir auch eine Firmware für das Gerät bauen.

(Text schamlos in Münster ctrl-c ctrl-v’t. Danke)

Lsyncd hatte ich mir schon mal vor Jahren angeschaut. Damals wurde aber ssh als Transport noch nicht unterstützt.  Nun habe ich mir das nochmal kurz (wirklich kurz) unter Debian 8 angeschaut (Version 2.1.5). Lsyncd überwacht Verzeichnisse via inotify und überträgt alle geänderten Dateien automatisch auf die angegebenen Zielhosts.  Lsyncd bietet eine große Anzahl an Optionen, daher schadet ein Blick auf die Homepage nicht. Zum schnellen testen kann man einfach folgendes ausprobieren:

apt install lsyncd

Auf der Konsole:

lsyncd -rsyncssh /home/thomas/hallo zielhost /home/thomas/test

Dabei wird der Inhalt des Ordners hallo in den Zielordner test Übertragen. Default werden Änderungen alle 15 Sekunden übertragen. Der Zielordner wird dabei automatisch angelegt.

Konfigurationsdateien lassen sich auch „problemlos“ nutzen, z.B.:

$ cat /etc/lsyncd/lsyncd.conf.lua                                                                       
settings  {
        logfile = "/var/log/lsyncd/lsyncd.log",
                statusFile = "/var/log/lsyncd/lsyncd.status"
                }

sync {
        default.rsyncssh,
        source = "/home/thomas/hallo",
        host = "thomas@zielhost",
        targetdir = "/home/thomas/test",
      }

und mit

service lsyncd start

den daemon starten. Danach eventuell noch ein

update-rc.d lsyncd defaults

für den Autostart des daemons.

Dabei muss auf dem Zielhost ssh login ohne Passwort erlaubt sein. Man kann aber auch rsyncd zur Übertragung nutzen. Zu beachten ist das lsyncd default „delete“ als Option hat. Das merkst Du daran, dass plötzlich vielleicht Dein gesamtes home directory gelöscht wurde…nicht das es mir passiert wäre. Die Syntax im Bezug auf „/“ bei Verzeichnissen ist anders als bei rsync.

Lsyncd ist eventuell  interessant wenn man einfach nur ein paar Konfigurationen, ohne Puppet & Co zu nutzen, syncen will oder  man eine überschaubare Menge an Dateien auf verschiedenen hosts verteilen will. Ab einer gewissen Anzahl von Dateien stößt man an auf diverse Probleme (inotify&co). Am besten man testet lsyncd auf Testmaschinen bevor man es produktiv einsetzt.

Klingt eigentlich ganz leicht, ist aber aber tatsächlich umständlich einzurichten. Ich nutze Fluxbox bei einigen Maschinen als Windowmanager. Dort die Proxy Einstellungen für den Chrome Browser zu ändern ist etwas nervig, da man dies nicht einfach über die Einstellungen des Browsers machen kann. Der geringste Aufwand ist einfach ein Proxy Addon zu installieren. Also einfach Proxy SwitchyOmega installieren, die Proxydaten eintragen und den Proxy auswählen.
Sollte man mit ssh Forward arbeiten, nicht vergessen socks5 statt http als Protokoll zu wählen.

Um beim Login via ssh sofort in einer tmux Session zu landen habe ich folgendes in meine .bashrc auf dem Zielhost eingefügt:

case $- in
    *i*)
    if command -v tmux>/dev/null; then
        if [[ ! $TERM =~ screen ]] && [[ -z $TMUX ]]; then
          if tmux ls 2> /dev/null | grep -q -v attached; then
            exec tmux attach -t $(tmux ls 2> /dev/null | grep -v attached | head -1 | cut -d : -f 1)
          else
            exec tmux
          fi
        fi
    fi
    ;;
esac

Sehr praktisch falls die Verbindung nicht stabil oder die bash_history deaktiviert ist.

Man kann auch

ssh 123.123.123.123 -t tmux a

nutzen, falls eine tmux Session vorhanden ist bzw. „tmux“ falls keine.
Die .bashrc Lösung ist aber natürlich etwas eleganter.

Link:  https://stackoverflow.com/a/42351698

Jeder der sich irgendwie für ebooks interessiert kommt eigentlich nicht an Calibre vorbei. Die Software ist mittlerweile in der der 3.0er Version erschienen. Der „Content server“ ist deutlich performanter und bietet nun endlich auch eine Funktion zum online lesen an.
Bisher, dank Cops und Bicbucstriim, zwar von mir kaum genutzt, aber dennoch eine sehr praktische Funktion. Dabei hat Cops, dank des integrierten Readers, aber die Nase vorn.

Wirft Pydio in der 8.0.0 Version den Fehler

<message type="ERROR">You are not allowed to access this resource.</message>

beim Update via Webinterface auf die 8.0.1er. Einfach mal einen anderen Browser probieren. Bei mir hat das Update dann mit Chrome funktioniert

Link: https://pydio.com/forum/f/topic/solved-not-allowed-to-access-this-resource/

Maldet ist ein Malware Scanner. Ideal für jegliche Art von Webhosting.

Maldet legt automatisch einen cronjob an und verschickt je nach Wunsch täglich mails.

Mails sehen dann in etwa so aus:

HOST:      web01
SCAN ID:   170610-0654.14910
STARTED:   Jun 10 2017 06:54:15 +0200
COMPLETED: Jun 10 2017 07:07:34 +0200
ELAPSED:   799s [find: 450s]

PATH:          
RANGE:         1 days
TOTAL FILES:   24202
TOTAL HITS:    2
TOTAL CLEANED: 0

WARNING: Automatic quarantine is currently disabled, detected threats are still accessible to users!
To enable, set quarantine_hits=1 and/or to quarantine hits from this scan run:
/usr/local/sbin/maldet -q 170610-0654.14910

FILE HIT LIST:
{HEX}php.cmdshell.unclassed.365 : /pfad/zum/docroot/phpshells/844-4873-1-SM.phtml
{HEX}gzbase64.inject.unclassed.15 : /pfad/zum/docroot2/c.php

Maldet bietet etliche Einstellungsmöglichkeiten.  Man kann es auch in Echtzeit im monitoring mode laufen lassen. Je nach Umfang der docroots stößt man dabei aber an diverse Limits (ulimit &co).

Auf Github findet man Maldet unter https://github.com/rfxn/linux-malware-detect. Debian Pakete gibt es unter https://github.com/waja/maldetect.

Nur ein paar Notizen für mich für ein Update von Ubuntu 12.04 zu 14.04 und von MySQL 5.5 zu 5.6.

MySQL
table_cache gibt es bei MySQL 5.6 nicht mehr, das heißt nun table_open_cache.  Am besten vorher in der my.cnf ändern

ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable
invoke-rc.d apparmor restart
schadet auch nicht.

Pacemaker
apt-get install haveged
braucht man
Pacemaker komplett löschen. Purgen reicht nicht
rm -rf /var/lib/pacemaker
rm -rf /var/lib/heartbeat
rm -rf /var/lib/pengine

Nachdem Update Pacemaker einfach neu installieren. Das sollte inklusive Konfiguration maximal 5 Minuten dauern. Eventuell kurz  root via key zwischen den Nodes erlauben.

update-rc.d pacemaker defaults
kann auch nicht schaden

ssh
Match Blocks werden nicht mehr mit „Match“ geschlossen und müssen immer am Ende der sshd_config  stehen. Eventuell hilft „Match all“

So, das Update ist dann durch. Bei so einer Aktion kann man auch immer ganz gut abschätzen wieviele normale Nodes (also keine Bastel- Experimentier etc.) in unserem Netz sind. Das sind zur Zeit 867, was auch ganz interessant ist, denn davon sind eigentlich immer mindesten 50 aus, wenn man das mal mit der Nodestatistik vergleicht.

Wir starten morgen ein Update der Firmware im Göttinger Freifunk-Netz.

Nodes, die auf Autoupdate stehen, werden im Laufe der nächsten zwei Wochen das Update automatisch installieren.

Das ist ein Sprung von
“ffgoe-0.8.2 basierend auf Gluon 2016.1.5 vom März 2016” auf
“ffgoe-0.8.7 Basierend auf Gluon 2016.2.3 vom Februar 2017”.

Es steckt also ein Jahr Entwicklungsarbeit in der Firmware, es gibt viele Bugfixes und Support für neue Hardware. Wir haben die Firmware in Version 0.8.7 seit Februar als Beta-Version zur Verfügung gestellt und sie läuft seitdem erfolgreich auf 67 Nodes.

Hier sind sämtliche Änderungen verzeichnet:
v2016.1.6.html
v2016.2.html
v2016.2.1.html
v2016.2.2.html
v2016.2.3.html

Unsere Konfiguration befindet sich hier:
https://github.com/freifunk-goettingen/site-ffgoe/tree/v0.8.7

Da gibt es einige Angebote an Open Source Softwarelösungen. Früher hatte ich  gallery im Einsatz, dass wurde dann irgendwann mal gehackt und wird auch seit einigen Jahren nicht mehr weiter entwickelt. Generell scheinen Webgalerien ein beliebtes Ziel für Einbrüche zu sein. Als Ablösung kam dann ganz einfach google Fotos bei mir/uns.  Das funktioniert, ist extrem praktisch wenn man eh 99,9% der Fotos mit dem Handy macht. Da aber Fotos von Handys immer noch schrottig gegenüber Fotos einer richtigen Kamera aussehen, haben wir uns eine Systemkamera zugelegt. Erst etwas skeptisch ob das Geld auch gut angelegt ist,  war ich bereits nach dem ersten Spaziergang mit Kamera & Co vom Nutzen der Kamera überzeugt.  Mit einer Kamera hat man halt Fotos und mit einem Handy Schnappschüsse. Nun stellte sich die Frage wohin mit den Fotos? Irgendwo auf Platte, Dropbox, Nextcloud, Google Photos?

Google Photos ist ungünstig, weil bei Bildern über 16 MP die Qualität auf 16 MP reduziert wird, jedenfalls wenn man unbegrenzt Bilder ablegen will und die Daten nicht auf den Quota angerechnet werden sollen. Da ich eh schon immer ein Freund von Wasduselbsthostenkannsthosteselbst bin, habe ich mir piwigo angeschaut. Vorher noch kurz nextcloud als Galerie ausprobiert, das ist aber leider komplett unbrauchbar dafür. Erst hatte ich die Daten noch via nextcloud client gesynct und einfach einen symlink in den galleries Ordner von piwigo gelegt. Fand ich aber nervig und ist überflüssig. Einfach die Fotodaten via rsync in den galleries Ordner und via Webinterface syncen lassen und fertig. Natürlich liegen die Fotos nochmal auf dem NAS.

Die Lösung gefällt mir ausgesprochen gut und funktioniert wunderbar. Sollte jemand eine gute andere  Webgalerie Software kennen, immer her damit.  Optimal wäre es natürlich wenn die Kamera (die natürlich heute alle WLAN haben) direkt syncen könnte, ohne den Weg über den PC  zu gehen.

Wir haben eine Datei, die wir einfach nur leeren wollen. Die Dateirechte sollen so bleiben und wir wollen nicht mit rm&touch&chown&chmod arbeiten.

$ l machmichleer.txt
-rw-rw-r-- 1 thomas thomas 27K Apr 21 10:06 machmichleer.txt

$ > machmichleer.txt

$ l machmichleer.txt
-rw-rw-r-- 1 thomas thomas 0 Apr 21 10:07 machmichleer.txt

Nach einem Update von Debian 7 auf 8 ging das Anmelden am System extrem langsam, zudem lief clamav nicht mehr.  UsePAM yes auf no hat zwar geholfen aber man will ldpap nutzen. Da gab es noch mehr, aber das spare ich  mir alles.

Die Lösung hat etwas gedauert. Geholfen hat:

1. Debug von pamd aktivieren
   $ touch /etc/pam_debug
   *.debug /var/log/debug.log in die rsyslog.conf und rsyslog restart
2. darüber auf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798522 aufmerksam geworden

3. $ ldd /usr/sbin/console-kit-daemon
   libgobject-2.0.so.0 => /opt/tivoli/tsm/client/ba/bin/libgobject-2.0.so.0 (0x00007f20f34ef000)
   libglib-2.0.so.0 => /opt/tivoli/tsm/client/ba/bin/libglib-2.0.so.0 (0x00007f20f32fe000)

4. Die Einträge für tsm aus der

   /etc/ld.so.conf.d/tsm.conf

   löschen bzw. wo auch immer man das damals für TSM Client eingetragen hat.

5. $ ldconfig

   fertig. Mittlerweile gibt es einen von IBM unterstützen 7er Client für Debian/Ubuntu (eigentlich nur Ubuntu aber egal).

I don’t like to have daemons listening on the systems I am responsible for. This is the reason why I check periodically all systems with netstat -tulpen to see what processes are actually listening, look if they are needed and may be bound to localhost only.

I used to set the system time via ntpd, but many years ago I switched to a simple cron job that runs ntpdate. This is good enough for all systems that don’t depend on milliseconds and smooth time shift etc. I was able to remove ntpd from almost all servers. My cron job looks like this:

## ntpdate Cron Job

# Environment Settings
MAILTO=root
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Job Definition
*/30 * * * *  root  /usr/sbin/ntpdate 0.pool.ntp.org > /tmp/ntpdate.prt 2>&1

I often need to work in a database on the command line. Booleans are not displayed in an intuitive way. I mean this:

There is a simple trick that helps me to read it much better: cast it to an integer. This is done by adding +0 to the boolean column:

mod_macro ist dufte, besonders wenn man nicht nur Apache Vhosts für 10-20 Leute verwaltet.  Da gibt es etliche sinnvolle Einsätze für.

Das Modul mod_macro ist default bei apache 2.4 dabei.

$a2enmod macro

Nun kann man sich eine einfache macro.conf anlegen:

<Macro VHost $name $domain>
<VirtualHost *:80>
    ServerName $domain
    ServerAlias www.$domain
    DocumentRoot "/var/www/vhosts/$name"
    ErrorLog "/var/log/httpd/$name.error_log"
    CustomLog "/var/log/httpd/$name.access_log" combined
</VirtualHost>
</Macro>

Wir haben damit ein Macro namens VHost angelegt. Dieses Macro kann mit folgenden Werten gefüttert werden:

$name $domain

Wollen wir das Nacro nun in unserer vhost.conf nutzen, schreiben wir dort einfach nur:

Use VHost example example.com
...
Use VHost montag baldistfruehling.org

Wir übergeben also den Wert example und example.com an das Macro mit dem Namen VHost. Dabei ist die Reihenfolge der Werte durch das Macro vorgegeben. Der Apache baut uns damit unsere Vhost.conf zusammen.

Fertig  sind unsere Vhosts. Einfach den Apache neu starten und das war es.  In der Dokumentation wird aus verständlichen Gründen noch vorgeschlagen die Macro Definition wieder zu entfernen wenn sie nicht mehr gebraucht wird.
Dies geschieht einfach  mit

UndefMacro VHost

Besonders bei größere Konfigurationen, vermeidet man damit Konflikte.

Will man mehrere Werte übergeben z. B.  IP Listen, kann man einfach diese einfach in Anführungszeichen setzen.

Use RestrictedAccessPolicy "192.54.172.0/24 192.54.148.0/24"

Hinweise:

Die macro.conf kann natürlich in beliebig viele Dateien auf gesplittet werden. Optimalerweise sollten die Namen der Macro Dateien Aufschluss über deren Funktion geben.  Das Include  der macro.conf muss vor dem Include der vhost.conf stehen.

Eine Dokumentation zu mod_macro findet man unter

https://httpd.apache.org/docs/2.4/mod/mod_macro.html

Die ist sehr gut, daher habe ich auch auf eigene Beispiele verzichtet.

NetworkManager provides connectivity checking to test for captive portals since GNOME 3.14. This performs recurring checks on a configurable URL. In case this does not deliver the expected response, NetworkManager knows we are very probably behind a captive portal and opens the corresponding login page.

This connectivity checking is an optional feature and not enabled by default in Debian Jessie or Squeeze. To enable this we can simple add a configuration file in /etc/NetworkManager/conf.d containing three settings:

[connectivity]
uri=http://network-test.debian.org/nm
response=NetworkManager is online
interval=300

This will check http://network-test.debian.org/nm every 300 seconds and expects to find the string “NetworkManager is online” in the HTML response.

For privacy reasons you might not want to test a public URL though. We could however simply host the URL to be checked ourselves. The NetworkManager documentation gives a few more details about the three settings. We mainly need to set the URI to a web site that either returns the header “X-NetworkManager-Status” with a value of “online” or returns the string specified using “response” in its body.

Given a running Apache web server with mod_headers enabled we can simply define a vhost like this:

<VirtualHost *:80>
  ServerName connectivity-check.example.net

  ## Vhost docroot
  DocumentRoot "/var/www/empty"

  ## Directories, there should at least be a declaration for /var/www/empty

  <Directory "/var/www/empty">
    Header Set X-NetworkManager-Status "online"
    AllowOverride None
    Require all granted
  </Directory>

  ## Logging
  ErrorLog "/var/log/apache2/connectivity-check.example.net_error.log"
  ServerSignature Off
  CustomLog "/var/log/apache2/connectivity-check.example.net_access.log" combined
</VirtualHost>

and configure NetworkManager using the following in /etc/NetworkManager/conf.d/10-connectivity.conf:

[connectivity]
uri=http://connectivity-check.example.net
interval=300

Sources:

Genauere Informationen zu ProxySQL mit Galera findet man hier. Dort ist auch erklärt wie man das Skript bei proxysql nutzen kann. Das Skript wird vorzugsweise vom ProxySQL Scheduler aufgerufen. Man kann es aber natürlich auch einfach mal auf der Commandline testen.
Meiner Meinung nach wird sich das eh im Laufe der nächsten Versionen nochmal grundlegend ändern. Das ist alles relativ umfangreich,  daher nur ein paar Hinweise.

Das Skript  liegt unter
/usr/share/proxysql/tools/proxysql_galera_checker.sh

Ein Aufruf sieht in etwa so aus

$ ./proxysql_galera_checker.sh 1 0 2 0 /var/lib/proxysql/galerachecker.log

Das erste Parameter gibt die Hostgroup für der Writer an, das zweite die Reader Hostgroup. Die 2  ist die Anzahl der genutzten Writers und die letzte 0 gibt an ob Writer auch als Reader agieren sollen wenn sie in der gleichen Hostgroup wie die Reader sind und als letztes Argument der Pfad zum Log.

Schaut man nun in das Logfile findet man folgendes:

Fr 3. Mär 13:22:10 CET 2017 ###### proxysql_galera_checker.sh SUMMARY ######
Fr 3. Mär 13:22:10 CET 2017 Hostgroup writers 1
Fr 3. Mär 13:22:10 CET 2017 Hostgroup readers 0
Fr 3. Mär 13:22:10 CET 2017 Number of writers 2
Fr 3. Mär 13:22:10 CET 2017 Writers are readers 0
Fr 3. Mär 13:22:10 CET 2017 log file /var/lib/proxysql/proxysql_galera_checker.log
Fr 3. Mär 13:22:10 CET 2017 ###### HANDLE WRITER NODES ######
Fr 3. Mär 13:22:10 CET 2017 --> Checking WRITE server 1:galera3:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 server 1:galera3:3306 is already ONLINE: 1 of 2 write nodes
Fr 3. Mär 13:22:10 CET 2017 --> Checking WRITE server 1:galera4:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 server 1:galera4:3306 is already ONLINE: 2 of 2 write nodes
Fr 3. Mär 13:22:10 CET 2017 ###### HANDLE READER NODES ######
Fr 3. Mär 13:22:10 CET 2017 --> Checking READ server 0:galera1:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 server 0:galera1:3306 is already ONLINE
Fr 3. Mär 13:22:10 CET 2017 --> Checking READ server 0:galera2:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 server 0:galera2:3306 is already ONLINE
Fr 3. Mär 13:22:10 CET 2017 --> Checking READ server 0:galera3:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 Changing server 0:galera3:3306 to status OFFLINE_SOFT. Reason: making ONLINE writer node as read OFFLINE_SOFT as well because writers should not be readers
Fr 3. Mär 13:22:10 CET 2017 --> Checking READ server 0:galera4:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 Changing server 0:galera4:3306 to status OFFLINE_SOFT. Reason: making ONLINE writer node as read OFFLINE_SOFT as well because writers should not be readers
Fr 3. Mär 13:22:10 CET 2017 ###### SUMMARY ######
Fr 3. Mär 13:22:10 CET 2017 --> Number of writers that are 'ONLINE': 2 : hostgroup: 1
Fr 3. Mär 13:22:10 CET 2017 --> Number of readers that are 'ONLINE': 2 : hostgroup: 0
Fr 3. Mär 13:22:10 CET 2017 ###### Loading mysql_servers config into runtime ######

Wir haben also 4 Nodes,  Galera3  und 4 aus Hostgroup 1 werden zu Writern und Galera1 und 2 aus Hostgroup 0 werden zu Readern. Galera3 und 4 sind auch in Hostgroup 1, dort werden sie aber Aufgrund des “writes should not be readers” Arguments deaktiviert.

Wichtig dabei ist:

“…ProxySQL uses a chain of query rules to figure out the routing. If none of the rules apply to a query, query will be routed to the default hostgroup for the user, which created the connection.”

https://severalnines.com/blog/how-proxysql-adds-failover-and-query-control-your-mysql-replication-setup

Das ganze Konstrukt ergibt quasi nur Sinn wenn man auch mit query rules arbeitet.  So kann man aber “bequem” read/write Anfragen skalieren und die volle Kapazität des Clusters nutzen.

So eine richtige Meinung zu ProxySQL habe ich noch nicht. Diese Sache mit den Hostgruppen finde ich jedenfalls ziemlich gut.  Ob  nun MaxScale oder ProxySQL die bessere Lösung ist kann ich nicht ohne weiteres sagen, sondern das hängt sicherlich von der jeweiligen Anforderung ab.  Für genauere Aussagen müsste man sich das mal in einer Produktivumgebung anschauen und sich ausführlicher mit den beiden Tools beschäftigen. Die Lizenz von ProxySQL ist natürlich deutlich sympathischer.

Link:
http://www.proxysql.com/compare

Pustekuchen!

Eigentlich ist es ja sonnenklar: Freifunk ist eine zivilgesellschaftliche Initiative, die der Allgemeinheit zugutekommt – also müssten Freifunk-Vereine doch gemeinnützig sein. Damit könnten dann Spenden an Freifunk-Vereine von der Steuer abgesetzt werden, und entsprechend könnten die Vereine mit höheren Spenden rechnen.

Doch leider stimmt das in der Rechtswirklichkeit bisher nicht. Der Anwendungserlass zur Abgabenordnung des Bundes (AEAO) schreibt vor:

“Internetvereine können wegen Förderung der Volksbildung als gemeinnützig anerkannt werden, sofern ihr Zweck nicht der Förderung der (privat betriebenen) Datenkommunikation durch Zurverfügungstellung von Zugängen zu Kommunikationsnetzwerken sowie durch den Aufbau, die Förderung und den Unterhalt entsprechender Netze zur privaten und geschäftlichen Nutzung durch die Mitglieder oder andere Personen dient.”

Doch Rettung naht!

Darüber kam unter Freifunkern im ganzen Land Unmut auf, den wir auch in die Politik getragen haben. Und dort bewegt sich etwas: die Landesregierungen von Nordrhein-Westfalen und Thüringen haben einen Gesetzantrag in den Bundesrat eingebracht (der WDR berichtete vorab). Die Abgabenordnung soll so geändert werden, dass explizit Gemeinnützigkeit festgeschrieben wird für

“die Einrichtung und Unterhaltung von Kommunikationsnetzwerken, die der Allgemeinheit ohne Gegenleistung offenstehen (Freifunk-Netze). Als Gegenleistung in diesem Sinne gilt insbesondere die Erlaubnis zur Verwendung oder Weitergabe der Nutzerdaten für gewerbliche Zwecke.“

Auch die Niedersächsische rot-grüne Regierungskoalition möchte diesen Antrag unterstützen (Pressemitteilung der Göttinger Landtagsabgeordneten Gabriele Andretta, das Göttinger Tageblatt berichtet kurz).

Wie wir dazu stehen

Wie man sich denken kann, unterstützen wir die Gesetzesinitiative vorbehaltlos. Da offensichtlich ist, dass Freifunk im besten Wortsinne gemeinnützig ist, hoffen wir auf eine Unterstützung durch alle demokratischen Parteien. Wir bedanken uns bei den beteiligten Personen und Parteien für die Unterstützung.

Wir freuen uns auch besonders, dass der Gesetzantrag dadurch datenschutzfreundlich ist, dass er ausdrücklich eine Gemeinnützigkeit für Netze mit gewerblicher Datennutzung verbietet.

Tauchen bei ProxySQL in der Logdatei immer wieder Einträge in der Art

...MySQL_Monitor.cpp:1126:monitor_ping(): [ERROR] Server db7:3306 missed 3 heartbeats, shunning it and killing all the connections

auf, liegt es eventuell daran, dass kein mysql-monitor_username mit dem mysql-monitor_password auf den Nodes eingerichtet ist.  Als Folge davon unterbricht ProxySQL die Verbindung zu den Nodes. Einfach mal bei ProxySQL schauen was dort eingetragen ist. Default ist monitor/monitor (jedenfalls in der 1.3.3er).

mysql> SELECT * FROM global_variables WHERE variable_name IN ('mysql-monitor_username','mysql-monitor_password','mysql-monitor_connect_interval','mysql-monitor_ping_interval','mysql-monitor_history');

+--------------------------------+------------------+
| variable_name                  | variable_value   |
+--------------------------------+------------------+
| mysql-monitor_connect_interval | 60000            |
| mysql-monitor_history          | 600000           |
| mysql-monitor_password         | monitor          |
| mysql-monitor_ping_interval    | 10000            |
| mysql-monitor_username         | monitor          |
+--------------------------------+------------------+
5 rows in set (0.01 sec)

Ändern kann man das Passwort einfach mit

mysql> UPDATE global_variables SET variable_value="GEHIRNSABOTAGE" WHERE variable_name="mysql-monitor_password";
Query OK, 1 row affected (0.00 sec)

mysql> LOAD MYSQL VARIABLES TO RUNTIME;
Query OK, 0 rows affected (0.00 sec)

mysql> SAVE MYSQL VARIABLES TO DISK;
Query OK, 46 rows affected (0.00 sec)

und fertig. Der Monitoraccount muss natürlich auch auf den Nodes eingetragen werden. Dann sollten auch Tests mit Sysbench & Co funktionieren.

Über

http://proxysql.blogspot.de/2015/09/proxysql-tutorial-setup-in-mysql.html

bin ich drauf gekommen.

Das Göttinger Freifunk-Netz sieht im Moment ungefähr so aus:

Vielleicht hat sich der eine oder die andere schon mal gefragt, wie diese langen Linien auf der Karte zu Stande kommen. Für die zwischen Geismar und Rosdorf gibt es seit ein paar Wochen eine schöne Erklärung. Um die anderen zu erklären, muss man sich vor Augen führen, wie die Router auf der Karte platziert werden. Die Router ermitteln ihren Standort nicht selbst, stattdessen gibt es bei der Einrichtung eines Freifunk-Routers die Möglichkeit, Geo-Koordinaten anzugeben. Diese Daten werden dann im Freifunk-Netz bekannt gegeben und von der Kartensoftware genutzt. Wenn jetzt also ein Router seinen Standort wechselt, werden die Koordinaten nicht automatisch aktualisiert. Und wenn dann noch andere Freifunk-Router in der Nähe sind, werden eben diese langen Linien gezeichnet.

Die Koordinaten (und auch andere Einstellungen) zu ändern ist nicht schwer, hier gibt es eine Anleitung dafür.

Nach 5 Jahren Katzenabstinenz tauchte imSeptember in unserer Filterblase>/del> unserem Freundeskreis ein kleiner Kater auf. Gestrandet in einem Garten, kein Muttertier weit und breit auffindbar, das Kitten hatten noch nicht mal die Augen auf. E. hat dem Kater das Leben gerettet, indem sie ihn rund um die Uhr mit der Flasche gefüttert hat. Wir stellten uns in die Reihe der Interessenten und plötzlich waren alle abgesprungen und es wurde ernst. Am 29. Oktober kam er zu uns – immer noch Flaschenkater. Von da an ging es stetig aufwärts:

/Users/krischan/Desktop/screenshot_1576.png

Die optimalen Ergebnisse bei der ersten Freifunkfernverbindung von Rosdorf nach Geismar haben wir auf 5Ghz erreicht. An beiden Standorten kam dabei jeweils eine Ubiquiti Nanostation M5 mit 12 dbi Antennengewinn zum Einsatz. Wie man auf dem Screenshot sehen kann, wurde dabei eine Linkqualität von bis zu 98% erzielt. Wir experiementieren weiter…

Der Kirchturm in Rosdorf als Freifunkstandort bietet uns nun sehr gute Möglichkeiten, um die möglichen Reichweiten im Freifunk experimentell zu ermitteln. Dabei ist nun erstmal eine Strecke von 4578m bis nach Geismar überbrückt worden. Nun werden wir auf dieser Strecke unterschiedliche Router zum Einsatz bringen, um die Streckenqualität, den Datendurchsatz aber auch die Unterschiede zwischen den Geräten zu testen und zu vergleichen. Teilweise wurde bisher bei schwacher Linkstrecke ein Datendurchsatz von 2MB/s erzielt.

Wir sind weiter auf der Suche nach hohen Routerstandorten, um die Testreihe fortzusetzen.

Update 14.1.2016:

Die optimalen Ergebnisse bei der ersten Freifunkfernverbindung von Rosdorf nach Geismar haben wir auf 5Ghz erreicht. An beiden Standorten kam dabei jeweils eine Ubiquiti Nanostation M5 mit 12 dbi Antennengewinn zum Einsatz. Wie man auf dem Screenshot sehen kann, wurde dabei eine Linkqualität von bis zu 98% erzielt. Wir experimentieren weiter…

Über mein kleines Projekt Goetemp habe ich hier schon öfter geschrieben. Seit nunmehr über sieben Jahren sammle ich Wetterdaten aus Göttingen und spiele damit herum.

In den vergangenen Tagen habe ich das Backend für die Simple JSON Datasource für Grafana implementiert. Damit ist es nun möglich die Daten auch in Grafana zu visualisieren. Zuerst hatte ich überlegt die Daten auch gleich in eine InfluxDB zu schreiben, aber die Implementierung des Backends für die Datasource war erheblich schneller realisiert.

Mehr dazu habe ich auf der Goetemp Webseite geschrieben. Hier kann auch das Dashboard heruntergeladen werden. Zum spielen mit dem Datenbestand habe ich einen Snapshot freigegeben:

• https://monitor02.pregos.info/grafana/dashboard/snapshot/rM3mdMXtVP2sppC211WEBRJni05AR974?from=now-30d&to=now

Leider ist unser Freund Alex letztes Wochenende gestorben. Alex war ein äusserst talentierter Hard- und Softwareentwickler, dem wir mehr zu verdanken haben, als man hier aufzählen kann. Unter anderem war er massgeblich am Aufbau des Göttinger Chaos Computer Clubs und Hackerspaces Neotopia in Göttingen beteiligt. Viele kennen ihn auch aus dem Freifunk Projekt und seinem Engagement bei den Funkamateuren und dem Arbeiter Samariter Bund. In letzter Zeit hat seine Arbeit am md380 Projekt weltweit Aufsehen erregt. Er hat sich immer dafür interessiert, was seine Freunde machen, sich alles zeigen lassen und neue Ideen und Motivation geliefert. Wenn man irgendwas für unsere Gemeinschaft getan hat, war meistens er es, der daran gedacht hat auch mal Danke dafür zu sagen. Er hat überall und vor allem in unseren Herzen seine Spuren hinterlassen. Wir vermissen Dich sehr und werden Dich nie vergessen.

When attempting to solve computational problems using accelerators (for example graphics processing units) a central challenge is to decompose the computation into many small identical problems. These small problems are then mapped to execution units of a given accelerator and solved in parallel.

The three household low level accelerator frameworks are CUDA, OpenCL and Metal. Next to mapping sub-problems to execution units they also allow for sub-problems to be grouped together. Groups of sub-problems have certain interesting properties:

• they can be synchronized and
• they can share data.

Accelerator frameworks thus ask developers to define two layers of data decomposition: (1) the overall size of the problem space and (2) the size of a group of sub-problems.

Moving a problem from one accelerator framework to another or implementing a solution using multiple accelerator frameworks can be interesting. Frameworks are very similar but the devil is in the detail. There is no standard of mapping sub-problems to execution units. Both the naming conventions and the semantics are different:

I added to this table the naming convention and semantics for for the Aura library that is under development. The library wraps the three standard accelerator frameworks and exposes a single API for all three.

Vielen Dank für die vielen Einsendungen. Alle Antworten waren richtig, bis auf zwei: Nein, die Lampen sind wirklich so. Nein, der Ring gehört wirklich genau an den Finger.

Das Rätsel sollte der Aufhänger dafür sein, über eine Netzweite Störung des Göttinger Freifunknetzes zu berichten, die uns vom 18.11 bis 25.11. beschäftigt hat. Alle paar Stunden meldete unser Monitoring, dass auf den Supernodes Dienste ausgefallen seien, aber wenn man nachgeguckt hat waren die da. Wir entwickelten etliche Theorien, was los war. Überlastung der Server, rätselhafte UDP-Drops, suboptimale Konfiguration der DHCP Server, der neue Kernel ist kaputt. Und so weiter und so fort. Nichts davon liess sich beweisen. Und gleichzeitig hörten wir von Nutzern, dass es Probleme im Netz gab. Wir hören sonst fast nie etwas von Nutzern – da war also wahrscheinlich was dran.

Des Rätsels Lösung fand sich schliesslich am 7. Tag im Mesh-Netz, in der Global Translation Table. Es gab einen Node, der Adressen von Supernodes in seinem lokalen Netz meldete. Eine denkbare Erklärung für dieses Verhalten wäre die Verkabelung die auf unserem Rätselfoto zu sehen ist:

Das ist tatsächlich nichts weiter als ein Kabel von einem gelben Port von Router A zu einem gelben Port zu Router B. Zum Glück hatte der Freifunker dem die Router gehörten eine E-Mail Adresse hinterlegt, so dass wir ihn fragen konnten, ob er seit einer Woche so ein Kabel gesteckt hat. Hatte er – und nachdem er das entfernt hat, gab es auch keine Störungen mehr.

Immerhin sind wir nun um einige Stunden Mesh-Debuggen erfahrener, haben eine bessere DHCP Konfiguration als vorher, eine ordentliche Konfiguration der GRE Tunnel und Mac Adressen der Supernodes und einen Monitor der den Verkabelungsfehler erkennt und uns bescheid sagt, wenn sowas noch mal passiert

Um zu verstehen, was bei dieser Killer-Verkabelung passiert muss man tief in die Funktionsweise des Freifunknetzes hineinschauen.

Und das wollen wir jetzt mal machen:

Das Freifunk-Netz wird von zwei Sorten von Teilnehmern gebildet.

1. Freifunk-Router
2. Clients

Die Freifunk-Router sind für den Aufbau des Mesh-Netzes zuständig und heissen deshalb auch Nodes (Knoten in einem Maschen-Netz). Zur Zeit sind rund um die Uhr ca. 750 Nodes eingeschaltet.

Die Clients sind z.B. Smartphones, Notebooks, und sämtliche andere Geräte die vom Mesh-Netz nichts wissen, aber das Mesh-Netz nutzen um darüber ins Internet zu kommen. Zur Zeit sind abhängig nach Tageszeit 550 bis 2500 Clients im Netz.

Unsere Freifunk-Router müssen also in der Lage sein, sowohl mit dem Mesh-Netz zu kommunizieren, als auch den Clients. Dazu haben sie vier Netzwerkschnittstellen:

Die Luftschnittstellen sind die Antennen. Das WLAN “Freifunk” ist bekannt. Weniger bekannt ist das Ad-Hoc WLAN “mesh.ffgoe”, über das die Nodes das Mesh-Netz bilden. Aber man kann es sehen, z.B. hier in der WLAN Suche eines Macs:

Die Kupferschnittstellen befinden sich auf der Rückseite der Freifunk-Router, beim TP-Link 841 sind die LAN “Freifunk” Dosen Gelb und in die meisten Freifunker nutzen die Dosen nicht.
Die VPN Mesh Dose ist blau, sie muss ins Internet kommen um sich mit den VPN-Gateways und darüber dem Mesh-Netz zu verbinden.

Wie funktioniert das in der Praxis

Wir haben ein Testnetz mit vier Nodes aufgebaut. Sie haben sich untereinander per Ad-Hoc WLAN Mesh vernetzt. Einer der Nodes hat eine Internetverbindung und verbindet unser kleines Mesh-Netz per VPN Tunnel mit dem grossen Göttinger Mesh-Netz.
Und es sind zwei Nicht-Mesh Smartphones per WLAN verbunden.

Solche Mini-Mesh Netze gibt es tatsächlich. Zum Beispiel hier in Duderstadt. Und zufällig sind auch genau wie im Testnetz zwei Nicht-Mesh Clients verbunden (die blauen Punkte). Einer der vier Node – der gelbe – hat eine VPN Verbindung. Das zeigt der kleine Pfeil mit der 1 an.

Fortsetzung folgt.

Ich hab ja rein maltechnisch null Talent. Ich schaffe grad mal so mit meiner Tochter ein Haus und Bäume mit Kreide auf unseren Bürgersteig zu malen. Seit kurzer Zeit versuche ich mich an diversen Brettspielminiaturen. Das schöne daran ist, dass man auch talentlos zufriedenstellende Ergebnisse erzielen kann. Zombicide zum starten kann ich nur empfehlen auch wenn die Miniaturen nicht besonders gut sind. Zombies sind sehr kritiklos wenn es ums Anmalen geht.

Meine ersten beiden Versuche. Sieht auf jeden Fall besser als das olle grau aus.

Heute gibt es ein Bilderrätsel.

Die Aufgabe: Finde alle Fehler im Bild und schreib sie in den Kommentar. Die Lösung gibt es in ein paar Tagen. Die Gewinner bekommen kostenlosen Zutritt zum wöchentlichen Freifunktreffen.

Vergrössern

Freifunk-Router mögen es bekanntlich luftig und hohe Gebäude üben auf viele Freifunker eine starke Anziehungskraft aus. Daher haben wir uns sehr gefreut, als wir das Angebot bekamen, auf dem Turm der Johanniskirche in Rosdorf Freifunkrouter aufstellen zu dürfen.
Seit heute Mittag ist dort in der „Laterne“ eine Testinstallation in Betrieb. Damit wurden die beiden größeren Meshnetze in Rosdorf zu einem großen verbunden, das jetzt aktuell 37 Router verbindet. Da es noch Optimierungsbedarf und Ideen für den weiteren Ausbau gibt, wird es dabei aber sicherlich nicht bleiben. Und schon jetzt ist es das größte Meshnetz im ganzen Freifunk Göttingen.

Wir beginnen mit einem leeren Java-Projekt. Für die Klassifikation werden wir eine Support Vector Machine (SVM) aus dem Smile framework benutzen.
Dafür laden wir zunächst die smile-core Komponenten herunter. Dies kann man ganz einfach über maven machen:

<dependencies>
    <dependency>
        <groupId>com.github.haifengl</groupId>
        <artifactId>smile-core</artifactId>
        <version>1.2.0</version>
    </dependency>
</dependencies>

Wenn man maven nicht mag, kann man sich die jars auch einzeln besorgen. Wir werden folgende jars benötigen:

• smile-core-1.2.0.jar
• smile-math-1.2.0.jar
• slf4j-api-1.7.21.jar

Trainingsdaten

Als Trainingsdaten nehmen wir das wine-Datenset aus dem UCI Machine Learning Repository: Wine-Daten. Dieses Datenset enthält Informationen von Weinen, die alle in der gleichen Region in Italien gewachsen sind, jedoch von drei verschiedenen Rebsorten abstammen. Die Daten liegen im CSV-Format vor und enthalten als ersten Wert die Klasse (sozusagen die Rebsorte) des jeweiligen Beispiels. Die restlichen 13 Werte sind Werte aus einer chemischen Analyse der Weine. Unser Klassifikator soll nun anhand der Features vorhersagen, welche Rebsorte der jeweilige Wein hat.

Einlesen der Daten

Die Klassifikatoren in Smile haben alle ein ähnliches Eingabeformat. Wir benötigen die Klassen als Integer und die Features als double-Array. Da wir (normalerweise) vorher nicht wissen, wie viele Beispiele wir haben, bietet sich hier eine Liste an, die später in ein Array umgewandelt wird:

List<Integer> classes = new ArrayList<>();
List<double[]> features = new ArrayList<>();

Die features unserer Weine lassen sich dann mit etwas Java 8 Syntax recht einfach auslesen:

try (Stream<String> stream = Files.lines(Paths.get("/some/path/to/wine.data"))) {
    stream.forEach((s) -> {
        String[] vals = s.split(",");
        classes.add(Integer.parseInt(vals[0])-1);
        double[] instanceFeatures = new double[vals.length-1];
        for(int i=1; i<vals.length;i++) {
            instanceFeatures[i-1] = Double.parseDouble(vals[i]);
        }
        features.add(instanceFeatures);
    });
}

Nun noch schnell in das gewünschte Input-Format unseres Classifiers umwandeln:

double[][] featureArray = features.stream().toArray(double[][]::new);
int[] classArray = classes.stream().mapToInt(i->i).toArray();

Klassifikation

Die eigentliche Klassifikation geht dann wenn man die Features erst mal hat dank des frameworks recht leicht von der Hand. Da wir direkt eine Cross-Validation durchführen wollen, benötigen wir einen ClassifierTrainer, der die SVMs für die Cross-Validation trainiert:

ClassifierTrainer<double[]> trainer = new SVM.Trainer<>(new GaussianKernel(3), 10, 3, Multiclass.ONE_VS_ALL);

Da unsere Daten drei Klassen enthalten, müssen wir eine MultiClass SVM benutzen. Ich habe mich hier für die Variante one vs all entschieden, da diese schneller klassifiziert (weniger Durchgänge als bei one vs one).
Damit wir bei unserer Cross-Validation auch Ergebnisse sehen, müssen wir ein array aus ClassificationMeasure-Instanzen erstellen. Dieses wird dann an die Cross-Validation Methode als Parameter übergeben:

ClassificationMeasure[] measures = new ClassificationMeasure[]{new Accuracy(), new Precision(), new Recall(), new Fallout(), new FMeasure()};
double[] results = Validation.cv(10, trainer, featureArray, classArray, measures);
for(int i=0;i<results.length;i++) {
    System.out.println(measures[i].getClass().getSimpleName() + ": " + results[i]);
}

Und schon haben wir klassifiziert! Die Ergebnisse sind allerdings recht ernüchternd:

Accuracy: 0.398876404494382
Precision: 0.398876404494382
Recall: 1.0
Fallout: 1.0
FMeasure: 0.570281124497992

Normalisierung

Das liegt daran, dass wir vergessen haben zu normalisieren. SVMs (und auch einige andere Klassifikatoren), erwarten Werte im Intervall [0;1]. Wir normalisieren allerdings nicht hart in dieses Intervall, sondern wählen eine andere Variante der Normalisierung:
Wir ziehen von jedem Feature den Mittelwert ab und teilen dann durch die Standardabweichung. Das Ganze muss per Feature geschehen, über alle Instanzen hinweg. Hier der Code:

//berechnen der Mittelwerte
double[] means = new double[13];

for(double[] fInstance : features) {
    for(int i=0;i<fInstance.length;i++) {
        means[i] += fInstance[i];
    }
}
for(int i=0;i<means.length;i++) {
    means[i] = means[i] / features.size();
}

//berechnen der Varianzen
double[] variances = new double[13];
for(double[] fInstance : features) {
    for(int i=0;i<fInstance.length;i++) {
        variances[i] += Math.pow(fInstance[i]-means[i], 2);
    }
}
for(int i=0;i<variances.length;i++) {
    variances[i] = variances[i] / features.size();
}

//die eigentliche Normalisierung
double[][] featureArray = new double[features.size()][];
for(int i=0;i<features.size();i++) {
    double[] toNormalize = features.get(i);
    double[] normalized = new double[features.get(i).length];
    for(int k=0;k<features.get(i).length;k++) {
        normalized[k] = (toNormalize[k]-means[k])/Math.sqrt(variances[k]);
    }
    featureArray[i] = normalized;
}

Hier gibt es elegantere Möglichkeiten zur Berechnung, im Sinne der Verständlichkeit habe ich hier aber einfach die Schulformeln im Code umgesetzt.

Mit den normalisierten Werten sind die Ergebnisse nun um einiges erbaulicher:

Accuracy: 0.9887640449438202
Precision: 0.9859154929577465
Recall: 0.9859154929577465
Fallout: 0.009345794392523366
FMeasure: 0.9859154929577465

Kernel und Parameter

Damit eine SVM im realen Einsatz gute Ergebnisse liefert, müssen immer der Parameter C und die jeweiligen Parameter im Kernel optimiert werden. Das geschieht meist durch ausprobieren in 10er-Potenzen (also z.B. 0.001->0.01->0.1->1->10->100).
Der meist genutzte Kernel ist hier sicher der Gauß-Kernel, den wir auch oben benutzt haben. Ein linearer Kernel bietet jedoch den Vorteil, dass man leichter (bzw. überhaupt) visualisieren kann was gelernt wurde.

Die optimierte SVM trainieren und ausliefern

Wenn alle Parameter optimiert und wir mit den Ergebnissen zufrieden sind, wird es Zeit die SVM auf allen Trainingsdaten zu trainieren und auszuliefern. Dafür benutzen wir nun direkt die Klasse SVM:

SVM<double[]> svm = new SVM<>(new GaussianKernel(3), 10, 3, Multiclass.ONE_VS_ALL);

Als Parameter nehmen wir hier natürlich die vorher optimierten Werte. Trainiert wird die SVM dann folgendermaßen:

svm.learn(featureArray, classArray);

Dieses Objekt kann man dann serialisieren (z.B. mit xstream oder Gson), und später wieder einlesen.
Wenn man das SVM-Objekt dann erst mal hat, kann man mit ihm Vorhersagen für andere Datensätze treffen. Die Datensätze, für die die Klasse dann vorhergesagt werden soll, müssen vorher auf jeden Fall mit den gleichen Werten normalisiert werden, mit denen auch die Trainingsdaten normalisiert wurden:

double[] newExample = new double[]{12.77,2.39,2.28,19.5,86,1.39,.51,.48,.64,9.899999,.57,1.63,470};
for(int k=0;k<newExample.length;k++) {
    newExample[k] = (newExample[k]-means[k])/Math.sqrt(variances[k]);
}
svm.predict(newExample); //Ergebnis: 2

Die Werte für die Mittelwerte und die Varianzen sollten also gemeinsam mit dem SVM-Objekt serialisiert werden.

Neulich auf unserem Anrufbeantworter:

Ja, Hallo <gelöscht> ist mein Name. Ich wohne in <gelöscht> und habe mal eine Frage zu Freifunk und so weiter. Und zwar habe ich bis vor einiger Zeit immer hier in <gelöscht> Freifunk empfangen und seit ein paar Tagen ist absolut tote Hose. Gibt’s da irgendeinen Grund, oder war das nur ein Feldversuch, oder wie auch immer? Ich bin kein Computerexperte, ich hab das für mein Tablet halt genutzt.
Vielleicht kann mich ja mal jemand zurückrufen… Vielen Dank für die Mühe im Voraus. Dankeschön!

Solche Anrufe haben wir öfters. Leute freuen sich, dass sie einfach so ins Internet kommen, wissen aber gar nicht was Freifunk ist und wenn es dann wieder weg ist fängt man an zu recherchieren und landet evtl. auf unserer Webseite und findet dort unsere Telefonnummer.

Wir beantworten Telefonanrufe ziemlich ungerne, weil sie grossen Aufwand bedeuten. Aber wir antworten gerne per Mail oder heute auch mal im Blog.

Wahrscheinlich hat ein freundlicher Nachbar warum auch immer seinen Freifunkrouter wieder abgeschaltet. Vielleicht ist es ihm noch gar nicht aufgefallen. Wo der ausgefallene Router stand kann man oft auf der Freifunkkarte sehen. Aber nicht immer, tragen Nachbarn ihren Router auch auf der Karte ein. Freifunk ist ein Selber-Machen-Netz, jeder kann einen Router aufstellen und seinen Internetanschluss teilen, aber natürlich hören Leute auch wieder damit auf. z.B. weil sie wegziehen.

Da kann die Göttinger Freifunkinitiative wenig machen. Wir stellen nur die Infrastruktur bereit (nur mit ganz wenigen Ausnahmen stellen wir auch Access Points auf, z.B. in Flüchtlingsunterkünften), aber die hunderte von Zugangspunkten in der ganzen Stadt kommen von Anwohnern, die wir meistens überhaupt nicht persönlich kennen.

Die Hilfsbereitschaft, Gastfreundschaft und Nachbarschaftshilfe die die Göttinger hier zeigen finden wir absolut überwältigend. Niemand hätte am Anfang gedacht, dass dieses Freifunk Netz solche Ausmaße annehmen würde.

Im Göttinger Freifunknetz werden nach 1,5 Jahren Wachstum so ungeheure Datenmengen bewegt, dass wir vor allem damit beschäftigt sind, die glühenden Supernodes am laufen zu halten und das damit verbundene Datenvolumen zu finanzieren.

Als ich eine der SQL-Queries für das e-learning Portal geschrieben habe, kam darin auch ein JOIN-Statement vor. Ich habe mich also innerlich auf das 'manuelle' zusammenfassen der Ergebnisse im Code mittels einer map[string]string vorbereitet, da ist mir durch Zufall die postgresql json_agg aggregate function begegnet (postgresql aggregate functions). Die query würde dann folgendermaßen aussehen:

SELECT units.*, json_agg(pages.page_id) AS pages_arr FROM units LEFT OUTER JOIN pages ON ... GROUP BY units.unit_id

Der pages_arr-Wert wird dann als JSON-Array zurückgeliefert, das einfach mit einem beliebigen JSON-Parser in der jeweiligen Programmiersprache in ein Array oder eine Liste verwandelt werden kann.
Sehr praktisch wie ich finde!

Für ein Uni-Projekt habe ich die Aufgabe, eine E-Learning Applikation zu entwerfen. Diese soll zunächst als Web-App realisiert werden, die Möglichkeit native Apps für mobile Endgeräte nachzuentwickeln, soll allerdings auch vorhanden sein.

Für diese Anforderungen eignet sich ganz besonders die Kombination (REST)-api im backend und JavaScript MVC Framework für das frontend. Da ich normalerweise Web-Anwendungen mit Java/MySQL/JSF entwickle, wäre zumindest schon mal das frontend neu für mich gewesen. Um das Ganze noch interessanter zu machen, habe ich zusätzlich noch die Programmiersprache im Backend und die Datenbank geändert.

Als Programmiersprache für das backend werde ich go von Google benutzen und als Datenbank postgresql. Interessant an go ist vor allem die Art des deployens: Es wird eine komplett eigenständige binary mit Runtime und Garbage Collector erstellt. Beim jetzigen Projektstand ist diese lediglich 7,3MB groß (kompiliert mit go 1.7rc6). Es gibt noch viele weitere Dinge, die go anders macht als andere Programmiersprachen, doch für mich ist dies der interessanteste Unterschied zu Java, wo die "fat-WARs" schon mal 30-40 MB groß sein können mit allen Abhängigkeiten.

Für das frontend habe ich mich zunächst für emberjs entschieden. Da ich noch nicht mit der frontend-Entwicklung begonnen habe, kann ich hierzu noch nicht so viel schreiben, außer dass mir die Tutorials besser gefallen haben als die von Angular. Bei emberjs scheint mir alles etwas klarer und die Struktur der Applikation mehr vorgegeben zu sein.

Die Blog-Serie soll keine minutiöse Beschreibung der Entwicklung werden, sondern vielmehr interessante Entdeckungen und Entscheidungen festhalten.

Gestern Abend fiel bei Kabel Deutschland das Netz aus und wir wissen jetzt wieviel Prozent der Göttinger Freifunker dort Kunde sind.

Göttingen. Während England über den Austritt aus der EU abstimmt, spielen sich die wirklich staatstragenden Ereignisse mal wieder im Göttinger Freifunknetz ab. Wir entlassen heute eine neue Firmware in die Freiheit.

Kurzfassung

Ab heute gibt es eine neue Firmware, sie wird im Laufe der nächsten zwei Wochen automatisch auf allen Routern installiert. Wir haben nun Support für den TP-Link 841v11. Und eine geile neue Router Statusseite, die man unter http://10.109.0.1 anschauen kann (wenn man im Freifunk ist).

Langfassung

Die neue stabile Firmware 0.8.2 löst ab heute die alte 0.7.3 ab, die wir im Januar 2016 ausgerollt haben. Die 0.8.2 ist ein unmodifiziertes Gluon 2016.1.5. Router die auf autoupdate stehen, also fast alle, installieren die Firmware innerhalb der nächsten zwei Wochen. Wann genau entscheidet jeder Router selber nach dem Zufallsprinzip. Damit verringern wir das Risiko, dass das ganze Netz evtl. mit einem Schlag kaputtgeht falls uns beim Betatesten doch irgendein schlimmer Bug nicht aufgefallen sein sollte.

Neue Hardware

Buffalo

WZR-HP-G300NH

D-Link

DIR-505 (A1)

TP-Link

CPE210/220/510/520 v1.1
TL-WA901N/ND v1
TL-WR710N v2
TL-WR801N/ND v1, v2
TL-WR841N/ND v11
TL-WR843N/ND v1
TL-WR940N v1, v2, v3
TL-WR941ND v6
TP-Link TL-MR13U v1
TP-Link TL-WA7510N

Ubiquiti

airGateway
airRouter
UniFi AP Outdoor+
Rocket M XW

Western Digital

My Net N600
My Net N750

Devices on Chips

Onion Omega
ALFA Hornet UB / AP121 / AP121U
8devices Carambola 2

Cisco

Meraki MR12/MR62/MR16/MR66

OpenMesh

MR600 (v1, v2)
MR900 (v1, v2)
OM2P (v1, v2)
OM2P-HS (v1, v2)
OM2P-LC
OM5P
OM5P-AN

x86-xen_domu

Eigentlich auch neu, hatten wir aber schon in die vorherige Firmware reingepatcht:

TL-WR841N/ND v10, TL-WR1043N/ND v3, Futro Support im x86-generic Image (PATA Treiber).

Ubiquity AirOS 5.6.x

Es ist nicht mehr nötig auf AirOs 5.5.x downzugraden, um Gluon installieren zu können. Das betrifft Airmax M XM/XW Geräte, also NanoStation, Bullet und Co.

x86-generic

Die 64bit version von x86-generic enthält jetzt auch den VirtIO Treiber.

Kernel Module

Bisher konnte man Kernelmodule aus den offiziellen OpenWRT Repos installieren. Ab dieser Firmware müssen die Kernelmodule aus dem Göttinger Repository kommen, da sie signiert sind. Der Pfad ist in opkg vorkonfiguriert.

Freifunkrouter Status Seite

Die Statusseite ist informativer und sehr sehr viel hübscher geworden.

802.11s mesh support

Prinizipiell unterstützt die Firmware 802.11s mesh, wir haben das aber nicht konfiguriert.

Multicast filter

Die Router filtern ab dieser Firmware multicast ICMP and ICMPv6 Echo Requests (ping) und Node Information Queries (RFC4620) raus. Früher war es möglich sämtliche 760 Nodes gleichzeitig anzupingen.

27.6.: Nachtrag zum Changelog der 0.8.2 Firmware

Auf der neuen Statusseite der Router ist die Kontaktinfo zu sehen. Und die Router funken HT20.

Unsere nächste Firmware, Gluon 2016.1.5, ist im Betatest und kann hier runtergeladen werden:

https://cccgoe.de/freifunk/beta/factory/

Unter anderem enthält diese Firmware Support für den TP-Link 841 v11. Für eine vollständige Featureliste gibt es die Doku auf http://gluon.readthedocs.io/en/v2016.1.5/

Sehr geehrte netzpolitische Sprecher der Bundestagsfraktionen,
sehr geehrte Mitglieder des Bundestags,

wir, die Göttinger Freifunk-Initiative, haben die Bemühungen der Bundesregierung, das Telemediengesetz so zu novellieren, dass das Öffnen privater Netzzugänge nicht mehr durch die Störerhaftung bedroht wird, enthusiastisch aber kritisch begleitet.Unter anderem haben wir hierzu nacheinander Gespräche und Diskussionsrunden mit den Bundestagsabgeordneten Lars Klingbeil und Thomas Oppermann, Jürgen Trittin sowie Fritz Güntzler initiiert.

Wir haben uns sehr über die Nachricht gefreut, die Regierungsfraktionen hätten sich darauf geeinigt, die Störerhaftung für Betreiber von WLANs endlich endgültig abzuschaffen. Sollte dies tatsächlich gelingen, wäre dies ein – wenn auch lange überfälliger – großer Wurf für die Entwicklung der digitalen Zivilgesellschaft in Deutschland.

Noch liegt uns kein konkreter Gesetzentwurf vor, aber leider müssen wir befürchten, dass das Erreichen dieses Zieles durch eine unzureichende gesetzliche Umsetzung gefährdet ist.

Die fragmentarischen Informationen, die bislang an die Öffentlichkeit gelangt sind, lassen die Vermutung zu, dass die von den Regierungsfraktionen gefundene Einigung vorsieht, Betreiber privater offener WLANs explizit als Telekommunikationsdiensteanbieter im Sinne von §8 TMG festzuschreiben, ohne hierfür zusätzliche Bedingungen zu fordern, wie sie noch aus dem Regierungsentwurf von Juni 2015 hervorgingen.
Dies haben wir von Anfang an gefordert und begrüßen es dementsprechend sehr.
Allerdings – so vermuten wir – sollen in §8 TMG Unterlassungsansprüche gegen Telekommunikationsdiensteanbieter nicht explizit ausgeschlossen werden. Lassen Sie mich kurz ausholen, um zu erklären, wieso sich dies als sehr problematisch erweisen könnte.

Die Störerhaftung verhindert deshalb die Verbreitung offener WLANs, weil Betreiber befürchten müssen, für Rechtsverletzungen ihrer Nutzer abgemahnt zu werden und hierfür mit erheblichen Kosten und Mühen belastet zu werden.
Entscheidend hierbei ist die Rechtsunsicherheit – sie allein reicht schon aus, um eine Privatperson oder ein kleines Unternehmen davon abzuschrecken, ein offenes WLAN anzubieten. Selbst wenn tatsächlich ein offenes WLAN existiert und es zu einer Abmahnung kommt, besteht die Rechtsunsichherheit in der Regel weiter. Die Abmahnkanzleien sind nämlich gar nicht daran interessiert, dass ihre Abmahnungen gerichtlich überprüft werden, weil für sie das Risiko einer folgenschweren Niederlage schwerer wiegt als eine Person, die die geforderten Abmahngebühren nicht zahlt.
Wenn das Ziel ist, die Verbreitung offener WLANs zu fördern, ist es also zwingend notwendig, die Rechtsunsicherheit zu beseitigen

Die Rechtsunsicherheit bezieht sich im Wesentlichen auf zwei Fragen:

1. Ist ein privater Netzbetreiber Telekommunikationsdiensteanbieter im Sinne von §8 TMG, gilt also für ihn das Providerprivileg?
   Die geplante Gesetzesänderung würde die jüngste Rechtsprechung, die diese Frage ohnehin tendenziell bejaht hat, festschreiben. Das würde dieses Teilproblem lösen. Da aber die Gerichte in jüngster Zeit sowieso zu dieser Meinung neigen, wäre die positive Wirkung allerdings auch beschränkt.
2. Treffen den Access Provider Unterlassungsansprüche trotz des Providerprivilegs?
   Leider ist die Rechtslage hierzu äußerst unklar. Die Rechtsprechung hat teilweise den Haftungsausschluss des Providerprivilegs sehr eng ausgelegt und Unterlassungsansprüche zugelassen. Gemeint sind Ansprüche etwaiger Geschädigter gegen den Netzbetreiber, zu unterlassen, weiterhin „adäquat-kausal“ an einer Rechtsverletzung mitzuwirken, hier konkret dadurch, dass einem Rechtsverletzer (oder einem offenen Personenkreis) weiterhin Zugang zum Netzwerk verschafft wird.
   Dies ist eine reale und aktuelle Gefahr: ein Beispiel hierfür sind zwei BGH-Urteile vom November 2015 in den Fällen „goldesel.to“ und „3dl.am“, nach denen klassische Internetprovider unter Umständen ein Unterlassungsanspruch in der Form einer Pflicht zur Sperrung des Zugangs ihrer Kunden zu von Dritten angebotenen illegalen Inhalten treffen würde. Diese Firmen kommen eindeutig in den Genuss des Providerprivilegs. Der BGH hat hier also eine Ausnahme vom Providerprivileg geschaffen und damit das Abmahnrisiko erhöht.
   Es sprechen andererseits auch gewichtige Rechtsgründe gegen ähnliche Unterlassungsansprüche, darunter der Wille des deutschen Gesetzgebers, der §8 TMG ja gerade geschaffen hatte, um Provider vor solchen Rechtsrisiken zu schützen (und nach dessen Wortlaut Telekommunikationsdiensteanbieter „nicht verantwortlich“ sind, ohne Einschränkung), die europäische E-Commerce-Richtlinie von 2000, die durch das TMG im Deutschen Recht realisiert wird und ebenfalls eine solche Haftung von Access Providern ausschließt, und das nach dem Schlussantrag des europäischen Generalanwalts zu erwartende Urteil des EuGH zum Fall einer Abmahnung, die ein Betreiber eines offenen WLANs in seinem Geschäft nach einem illegalen Musikdownload erhalten hatte.

Wenn allerdings selbst der BGH zu den angesprochenen Urteilen kommen kann, kann nicht davon die Rede sein, dass durch die jüngste Einigung der Regierungsfraktionen die Rechtsunsicherheit und damit das Hemmnis für den Ausbau offener WLANs beseitigt würde.

Im Gegenteil: durch eine voreilige Gesetzesänderung könnte der günstige Zeitpunkt der schon bestehenden fortlaufenden Diskussion, die gerade durch das ausstehende EuGH-Urteil befeuert wird, ungenutzt verstreichen, ohne dass es zu der angestrebten Weichenstellung kommt. Damit würde sich die Erreichung des proklamierten Zieles einer Förderung offerer WLANs weiter um Jahre verzögern und die Deutsche digitale Zivilgesellschaft um weitere Jahre zurückfallen.

Für die Regierungskoalition besteht darin eine besondere realpolitische Gefahr: die letzte Woche kommunizierte Einigung wurde von den Medien und allen wesentlichen netzpolitischen Akteuren (außer der Urheberrechtslobby, die die Idee offener Netze stets bekämpft hat) bereits gefeiert. Da noch kein Gesetzentwurf vorliegt, muss man von Vorschusslorbeeren sprechen. Sollte die letztlich resultierende Gesetzesänderung nicht zum gewünschten Erfolg führen – und das dürfte sich schnell herauskristallisieren – wird die Koalition an ihren Ankündigungen gemessen werden und nicht positiv abschneiden.

Als Argument gegen den Ausschluss von Unterlassungsansprüchen wurde vorgebracht, dass im Schlussantrag des europäischen Generalanwalts gefordert wird, dass gerichtliche Anordnungen in gewissen Fällen möglich sein müssen.
Dies ist jedoch auch ohne materielle Unterlassungsansprüche möglich. Wie die Digitale Gesellschaft schreibt, ist dies auch in anderen Rechtsgebieten wie §1 des Gewaltschutzgesetzes realisiert.

Außerdem fordert der Generalanwalt, dass die Kosten der gerichtlichen oder außergerichtlichen Rechtsverfolgung nicht den Access Provider treffen dürfen. Dies ist ebenfalls in Deutsches Recht umzusetzen.

Lassen Sie mich zum Abschluss – nicht zuletzt als Argumentationshilfe – noch kurz politische Gründe anführen, die für einen expliziten Ausschluss von Unterlassungsansprüchen in der Neufassung des §8 TMG sprechen:

• er entspricht dem Vorschlag, den der Bundesrat am 6.11.2015 vorlegte (Drucksache 440/1/15).
• er entspricht dem Abschlussantrag des europäischen Generalanwalts Maciej Szpunar vor dem EuGH und damit vermutlich dessen kommendem Urteil
• er entspricht auch dem Vorschlag des Vereins Digitale Gesellschaft aus dem Jahr 2012, der maßgeblich an der Entstehung der gesamten Diskussion um ein Ende der Störerhaftung beteiligt war. Dieser Vorschlag, den wir unterstützen, besteht in der Ergänzung von §8 TMG um:
  „(4) Der Ausschluss der Verantwortlichkeit (Absatz 1) umfasst auch Ansprüche auf Unterlassung.“
• wie oben ausführlich ausgeführt, ist er dringend notwendig, um die Rechtsunsicherheiten für die Betreiber offener WLANs zu beseitigen und damit das von der Bundesregierung ausgegebene Ziel der Förderung solcher Netze umzusetzen

Außerdem bestehen unabhängig von der Problematik offener WLANs weitere wichtige Belange, die allgemein dafür sprechen, dass Access Provider von Unterlassungsansprüchen freigestellt werden sollten:

• die Bundesrepublik ist durch Artikel 12 der Europäische E-Commerce-Richtlinie ohnehin seit 2000 (!) verpflichtet, dies in unmittelbar geltendes Deutsches Recht umzusetzen.
  Dies ist dem Wortlaut nach zwar bereits durch den existierenden §8 TMG realisiert, die Rechtsprechung zeigt hier aber, dass Nachbesserungsbedarf besteht, um das Ziel, dass Access Provider „nicht für die übermittelten Informationen verantwortlich“ sind, tatsächlich zu realisieren.
• Es besteht die ernstzunehmende Gefahr, dass Access Provider, im Wesentlichen also eine kleine Gruppe von privaten Unternehmen, durch Abmahnungen dazu gebracht wird, den Zugang ihrer Kunden zu Inhalten zu sperren, die nur möglicherweise rechtsverletzend sind. In der Regel hätten sie kein Interesse, dagegen gerichtlich vorzugehen, sondern würden nach eigenem Profitinteresse handeln. Das würde für ihre Kunden, eine große Bevölkerungsmehrheit, auf eine privatisierte Zensur in vorauseilendem Gehorsam ohne rechtsstaatliche Verfahren hinauslaufen. Ein expliziter Ausschluss von Unterlassungsansprüchen würde dies verhindern.

Wir bitten Sie aus den genannten Gründen dringend, dass Sie den Gesetzentwurf zur Änderung des Telemediengesetzes vor der Beschlussfassung so ändern, dass Unterlassungsansprüche gegen Access Provider ausgeschlossen werden und Rechtsverfolgungskosten nicht von diesen zu tragen sind. Sollte dies schon in der von Ihnen angedachten Gesetzesnovelle enthalten sein, betrachten Sie diesen Brief bitte nur als Lob.
Mit freundlichen Grüßen

Freifunk Göttingen

Nachtrag

Halina Wawzyniak, netzpolitische Sprecherin der Linksfraktion im Bundestag, hat uns auf einen gemeinsamen Gesetzentwurf der Linken und Grünen vom 5.11.2014 hingewiesen.

Er nimmt den Hauptpunkt dieses Schreibens, nämlich den expliziten Ausschluss von Unterlassungsansprüchen gegen Access Provider, schon vorweg.

Wir freuen uns, dass die Linken und Grünen hier schon (knapp) länger unsere politischen Forderungen vertreten als es Freifunk Göttingen überhaupt gibt und hoffen, dass sie sich über unsere Unterstützung ebenfalls freuen.

Gestern erreichte uns die Meldung, die Regierungskoalition habe sich darauf geeinigt, die Störerhaftung für offene WLANs endlich zu beseitigen. Was heißt das, und was bedeutet das für Freifunk?

Die Störerhaftung

Störerhaftung bedeutet hier, dass der Inhaber eines Internetanschlusses abgemahnt werden kann, falls Andere, denen er Zugang zum Netz verschafft hat, beispielsweise Urheberrechtsverletzungen begehen. Dahinter steht die Vorstellung, dass Zugang zum Internet grundsätzlich statt einer Chance zur Kommunikation als Risiko einer Rechtsverletzung zu bewerten wäre. Diese Rechtsauffassung Deutscher Gerichte ist weltweit einzigartig und hat dafür gesorgt, dass es in Deutschland ein Haftungsrisiko ist, als Privatperson ohne Absicherung, wie sie Freifunk bietet, ein offenes WLAN zu betreiben.
Die Folge war traurig für die Entwicklung eines solidarischen digitalen Gemeinwesens: die Anzahl offener WLANs blieb weit hinter denen anderer Industrienationen zurück. Ende 2014 gab es beispielsweise in Südkorea 20 mal so viele offene WLANs pro Einwohner wie in Deutschland, in Grossbritannien 15 mal so viele.

Das Providerprivileg

Dabei ist im Telemediengesetz schon seit langem geregelt, dass Telekommunikationsdiensteanbieter nicht von der Störerhaftung betroffen sind. Das ist sinnvoll: wer Anderen einen Internetzugang zur Verfügung stellt, hat keine Kontrolle darüber, was diese damit tun – aus Datenschutzgründen darf er auch gar nicht kontrollieren. Ihn für die Handlungen des Nutzers verantwortlich zu machen wäre also höchst ungerecht.
Hauptsächlich für Internetprovider gedacht (deshalb heißt diese Regelung auch Providerprivileg), schützt der Wortlaut des Gesetzes eigentlich auch Privatpersonen, die Anderen Zugang zum Netz verschaffen und damit als Miniatur-Internetprovider agieren. Das haben die Deutschen Gerichte leider lange nicht zur Kenntnis genommen.

Der Regierungsentwurf von 2015

Gerade als sich in einigen Gerichtsentscheidungen abzeichnete, dass die Rechtsprechung dieses Argument in Zukunft endlich berücksichtigen würde, preschte die Bundesregierung im März 2015 mit einem desaströsen Gesetzentwurf vor, der angeblich das Ziel hatte, die Verbreitung offener WLANs in Deutschland zu fördern.
Er stellte zwar klar, dass Anbieter offener WLANs definitiv von der Störerhaftung ausgenommen sein sollten – aber nur wenn das Netz verschlüsselt ist und außerdem auf einer Vorschaltseite alle Nutzer erklären, nichts Böses zu tun. Beides hilft überhaupt nicht gegen das Problem des Missbrauchs, schränkt die Nutzer aber entscheidend ein. Zudem sollten ursprünglich private WLAN-Betreiber gegenüber kommerziellen dadurch schlechtergestellt werden, dass sie die Namen der Nutzer kennen sollten. Dies hätte private offene WLANs letztlich unmöglich gemacht, wurde aber nach drei Monaten zurückgezogen, weil es gegen EU-Recht verstoßen hätte.
Entsprechend vernichtend fiel die Kritik aus. Der Professor für Internetrecht Thomas Hoeren bezeichnete den Gesetzentwurf als “eine Unverschämtheit“.
Auch wir haben versucht, in Gesprächen mit Bundestagsabgeordneten, darunter Thomas Oppermann, Lars Klingbeil (beide SPD), Jürgen Trittin (Grüne) und Fritz Güntzler (CDU) unsere Argumente vorzubringen, um den Gesetzentwurf durch die Streichung dieser Einschränkungen so zu verbessern, dass das angestrebte Ziel, offene WLANs in Deutschland alltäglich zu machen, auch tatsächlich erreicht werden kann.
Leider konnte sich unsere Ansicht in der Regierungskoalition nur teilweise gegen die Befürchtung durchsetzen, man würde mit einer de-facto-Angleichung der Rechtslage an den Stand, wie er in allen anderen industrialisierten Staaten immer schon der Fall war, dem Verbrechen Tür und Tor öffnen. Die SPD schien deutlich aufgeschlossener als die CDU/CSU, aber nach über einem Jahr Stillstand konnte man den Eindruck gewinnen, hier wäre von der Regierungskoalition nichts mehr zu erwarten.

Das EuGH-Verfahren

Schließlich kam durch ein Gerichtsverfahren Bewegung in die Sache. Das Mitglied der Piratenpartei Tobias McFadden war abgemahnt worden, weil jemand über ein offenes WLAN in seinem Laden illegales Filesharing betrieben hatte. Er zog vor Gericht und argumentierte vor dem Landgericht München, dass unter anderem eine Störerhaftung in dieser Situation durch EU-Recht ausgeschlossen sei. Das Landgericht gab diesen Punkt daraufhin zur Entscheidung an den Europäischen Gerichtshof ab.
Im März gab der Generalanwalt am Europäischen Gerichtshof seinen Schlussantrag zu diesem Fall ab – die Störerhaftung sei unverhältnismäßig. Der EuGH ist zwar nicht an die Anträge des Generalanwalts gebunden, folgt dessen Argumentation aber in einer großen Mehrheit der Fälle.
Ein Urteil steht zwar noch aus, aber es schien, dass das EuGH der Störerhaftung ein Ende machen würde.
Wohl nicht zuletzt, um der Bundesregierung die Peinlichkeit zu ersparen, dass ihr Gesetzesvorhaben vom EuGH gekippt werden könnte, bevor es je in Kraft treten würde, ermahnte Bundeskanzlerin Angela Merkel in dieser Situation die Regierungsparteien, endlich zu einer Einigung zu kommen.
Unter diesem Druck dauerte es nur eine Woche – anscheinend war die Argumentation der Befürworter der Störerhaftung vom EuGH so unterminiert, dass sie ihren Widerstand nicht aufrechterhalten konnten.

Ein greifbares Ende?

Wie aus den Regierungsfraktionen zu hören war, gab es gestern die Einigung, dass das Providerprivileg für WLAN-Betreiber im Telemediengesetz explizit festgeschrieben werden soll.
Man hört, das Gesetzgebunsverfahren solle nur noch wenige Wochen in Anspruch nehmen.

Sollte dies tatsächlich so geschehen, freuen wir uns sehr über diese längst überfällige Entwicklung. Nach einigen Enttäuschungen über Anläufe von Teilen der Politik, das Abmahnunwesen zu bekämpfen, ist unser Enthusiasmus allerdings vorerst noch gedämpft. Letztlich wird es auf den Wortlaut des neuen Gesetzes ankommen, ob der Störerhaftung nicht doch noch ein Schlupfloch geboten wird.

Beispielweise könnten WLAN-Betreiber im Falle von Missbrauch Unterlassungsansprüche treffen, die wieder zu Abmahnungen führen könnten. Sollte dies nicht explizit im zu schaffenden Gesetz, ausgeschlossen werden, steht uns eine weitere langwierige politische Auseinandersetzung bevor. Es ist daher nur zu hoffen, dass dieser Punkt bereits Eingang in den zu erarbeitenden Gesetzentwurf findet oder gefunden hat.

Was bedeutet das für Freifunk?

Sollte die Störerhaftung für offene WLANs tatsächlich fallen, wäre das für Freifunk sehr positiv. Ist die Abmahngefahr gebannt, könnten wir den Betreibern von Freifunk-Knoten beispielsweise eine Option anbieten, Internetverkehr statt durch unsere VPNs (die hauptsächlich der legalen Umgehung der Störerhaftung dienen) direkt ins Internet zu leiten. Das hätte vier entscheidende Vorteile:

1. sind die VPNs ein Flaschenhals von Freifunk, ohne sie dürfte sich die Geschwindigkeit der Verbindung also in vielen Fällen stark erhöhen
2. bedeutet das Bereitstellen der VPNs für uns und unsere Freunde von Freifunk Rheinland Kosten und Arbeit für Server und Bandbreite, die sich deutlich reduzieren würde
3. wären besonders leistungsfähige Freifunk-Zugänge, wie sie beispielsweise in Geflüchtetenunterkünften oder Freibädern benötigt werden, einfacher und billiger zu realisieren.
4. Das Freifunk-Netz würde dezentraler, was der ursprünglichen Idee von Freifunk besser entspricht

Und nicht zuletzt können Privatpersonen in Zukunft ein WLAN auch ohne Freifunk öffnen, ohne Angst vor Abmahnungen zu haben. Dabei müssten sie zwar auf nette Features wie unser automatisches Mesh-Netz verzichten, aber es entfallen (die geringen) Kosten und Arbeit (vor allem der Informationsaufwand) der Einrichtung eines eigenen Freifunk-Knotens. Und mehr offene Netze sind ja etwas Tolles für alle!

Dieses Wochenende ziehen wir um! In die neuen Räume des Chaos Computer Clubs Göttingen in der Von-Bar-Strasse 2-4.

Das Gebäude ist vielen noch als ESG (Evangelische Studierende und Hochschulgemeinde) bekannt. Heute ziert das Dach des Hauses ein grosser MLP Schriftzug. Wir vermuten, das steht für My Little Pony.

Freifunk ist schon drin. Wir folgen in Kürze:

Der DARC Verlag gibt uns am Samstag, den 23. April die Gelegenheit Freifunk auf der neuen Messe “FUNK.TAG” in Kassel zu präsentieren.

Wir erwarten natürlich, dass ihr alle bei uns vorbeischaut und Euch mit uns über Dinge unterhaltet. Z.B. Freifunk, den drohenden Router Lockdown, unsere Enttäuschung über die Art wie Freifunk in Niedersachsen gefördert werden soll (okay… Kassel ist nicht direkt in Niedersachsen, aber fast). Vielleicht möchte ja auch jemand einen Router mit Freifunk Software bespielen.

Und neue T-Shirts haben wir auch gemacht. Nicht mit dem Liesel drauf, sondern dem anderen Göttinger Wahrzeichen, dem Kragenbären.

Bis dann.

Einmal an die eigene Notizwand gekritzelt:

1. MySQL Verbindungen + weitere Verbindungsrelevante Infos anzeigen:

   root@localhost [(none)]> show status like '%onn%';
   +--------------------------+--------+
   | Variable_name            | Value  |
   +--------------------------+--------+
   | Aborted_connects         | 0      |
   | Connections              | 440921 |
   | Max_used_connections     | 67     |
   | Ssl_client_connects      | 0      |
   | Ssl_connect_renegotiates | 0      |
   | Ssl_finished_connects    | 0      |
   | Threads_connected        | 2      |
   +--------------------------+--------+
   7 rows in set (0.00 sec)
   

2. MySQL Prozessliste anzeigen:

   root@localhost [(none)]> show processlist;
   +--------+-------+-----------+-------+---------+------+-------+------------------+
   | Id     | User  | Host      | db    | Command | Time | State | Info             |
   +--------+-------+-----------+-------+---------+------+-------+------------------+
   | 440912 | ttrss | localhost | ttrss | Sleep   |    0 |       | NULL             |
   | 440919 | root  | localhost | NULL  | Query   |    0 | NULL  | show processlist |
   +--------+-------+-----------+-------+---------+------+-------+------------------+
   2 rows in set (0.00 sec)
   

3. Der status Parameter der mysqladmin Binary auf der Kommandozeile:

   root@host ~ $ mysqladmin status
   Uptime: 1621495  Threads: 2  Questions: 18982236  Slow queries: 6  Opens: 83474  Flush tables: 1  Open tables: 400  Queries per second avg: 11.706
   

4. Und last but not least auch noch einmal die Prompt-Einstellung aus der /etc/mysql/my.cnf festgehalten:

   [mysql]
   prompt = \u@\h [\d]>\_
   

Die MySQL Befehle habe ich von dieser Webseite kopiert. Die Prompt Einstellungen weiß ich nicht mehr woher…

Der 31. März ist WorldBackupDay. Hab ich dieses Jahr das erste mal von gehört, aber es direkt zum Anlass genommen endlich mal das zu machen was ich sowieso schon lange machen wollte:

1. Speicher gekauft
2. Backup auf neues Puppet-Modul umgestellt
3. Alle verbliebenen Maschinen ins Backup eingepflegt

Guter Tag!

Und zur Überraschung nach langer Funkstille in diesem Blog mal wieder ein Wechsel der Blogsoftware. Bisher lief hier seit geraumer Zeit ein Wordpress. Allerdings ist es mir inzwischen zu lästig das ständig aktuell zu halten und auf die nächste Lücke zu warten, während ich gelegentlich den Kommentarspam lösche.

Und weil ich schon länger neugierig auf pelican war, habe ich nun umgestellt. Bei pelican handelt es sich um einen Generator für statische Seiten (i. d. R. mit ein wenig JavaScript). Also keine php-Seiten mehr, die erst aus der Datenbank zusammengesucht werden müssen. Und damit deutlich mehr Tempo und weniger Angriffsfläche. Und dass ich zum schreiben der Seiten jetzt nicht mehr den Wordpresseditor, sondern einen vi verwenden kann ist für mich ein großes Plus. Negativ fällt auf, dass die Kommentare damit erstmal weg sind, was andererseits aber auch den Kommentarspam drastisch reduziert :-).

Es gibt verschiedene Möglichkeiten Kommentare hier einzubauen und am liebsten wären mir Kommentare über Google Plus. Mal sehen.

Wir brauchen noch sehr viel mehr Unterzeichner, für die Abschaffung der Störerhaftung!

Dies ist die letzte Stufe einer jahrelangen Kampagne und unendlicher Stunden Lobbyarbeit… jetzt heißt es noch mal deutlich zu machen, das nicht nur Verbände, sondern auch die $Menschen nicht länger warten wollen, endlich Rechtssicherheit für offene WLAN-Netze zu bekommen.

Bitte nutzt Eure Reichweite in Newslettern und sozialen Kanälen, um den Druck zu erhöhen und diese Petition erfolgreich zu machen. Damit wir endlich die WLAN-Störerhaftung abschaffen!

» Petition unterschreiben

Ich habe früher fast alle meine Zertifikate von CAcert bezogen. Ich habe sie regelmäßig aktualisiert und für das deployen habe ich ein Puppet Modul, dass die Zertifikate verteilt.

Nach und nach bin ich auf Let’s Encrypt Zertifikate umgestiegen. Da ein hoher Grad an Automatisierung bei Let’s Encrypt immer wieder propagiert wird dachte ich mir, dass sollte auch mit Puppet dann kein zu großes Problem sein. Hier die Lösung, die bei mir nun in Betrieb ist:

Als erstes habe ich das Puppet Modul bzed/letsencrypt installiert. Das Modul benötigt eine PuppetDB. Über exported resources  transportiert es die CSRs auf den puppetmaster, macht dort die gesamte Abwicklung und transferiert dann die Ergebnisse wieder zurück auf den Node. Das funktioniert auch sehr gut.

Auf dem Puppetmaster habe ich die Klasse eingebunden und einige wenige Einstellungen gesetzt (hiera). Bei dem Hook handelt sich m übrigen um einen letsencrypt.sh Hook:

---
classes:
  - letsencrypt

letsencrypt::challengetype: 'http-01'
letsencrypt::hook_source: 'puppet:///modules/helper/%{::fqdn}/le_hook.sh'

Auf den Nodes habe ich die Klasse eingebunden und die Domains definiert für die ein Zertifikat bezogen werden soll:

---
classes:
- letsencrypt

letsencrypt::domains:
- 'foo.example.net'
- 'bar.example.net'
- 'baz.example.net'

In meinem recht simplen Szenario ist es so, dass ich einen Gate-Server habe, hinter dem sich alle anderen Maschinen „verstecken“. Dort läuft ein Apache Server als Proxy, der Anfragen über HTTP nach hinten weiterreicht. Die Konfiguration von Apache erfolgt ebenfalls über Puppet. Eine Authentifizierung über DNS für ACME klappt bei mir leider nicht, weswegen ich HTTP nehmen muss. Das habe ich so gelöst, dass ich für die Apache vhosts einfach über ProxyPassMatch den .well-known/acme-challenge/ auf einen Apache Vhost auf dem Puppetmaster weiterreiche. Auf dem Gate-Server sieht das für einen Vhost wie folgt aus:

apache::vhost:
  'proxy-foo.example.net':
    servername: 'foo.example.net'
    serveradmin: 'webmaster@example.net'
    port: '80'
    docroot: '/var/www/empty'
    proxy_dest: 'http://10.20.30.1'
    proxy_pass_match:
      -
        path: '^/.well-known/acme-challenge/(.*)$'
        url: 'http://10.20.30.2/$1'
        params:
          retry: '0'
    headers:
      - 'unset X-Powered-By'
    proxy_preserve_host: true

Auf dem Puppetmaster wiederum läuft ein Vhost, der einfach alle Domains als ServerAlias eingetragen hat.

Nun kommt noch der Hook für letsencrypt.sh ins Spiel den ich oben bereits erwähnt habe. Das Skript schreibt die ACME-Challenge in eine Textdatei in den DocRoot und löscht sie nach dem Erfolg wieder:

#!/bin/bash

#
# http-01 hook
#

CHALLENGEDIR="/var/www/example.net/letsencrypt"

done="no"
if [[ "$1" = "deploy_challenge" ]]; then
    echo "${4}" > "${CHALLENGEDIR}/${3}"
    chmod 644 "${CHALLENGEDIR}/${3}"
    done="yes"
fi

if [[ "$1" = "clean_challenge" ]]; then
    rm "${CHALLENGEDIR}/${3}"
    done="yes"
fi

if [[ "${1}" = "deploy_cert" ]]; then
    # do nothing for now
    done="yes"
fi

if [[ ! "${done}" = "yes" ]]; then
    echo Unkown hook "${1}"
    exit 1
fi

exit 0

Voila! Es braucht ein paar Durchläufe bis alles über die Puppetdb jeweils transportiert wurde, aber alles läuft vollautomatisch ab. Sehr cool!