In unserem Experimentalverzeichnis liegt die neueste und finale Version von Gluon 2018. Danach geht’s mit 2019 weiter und das Update wird dann etwas abenteuerlicher. Aber erstmal müssen wir die 2018.2.4 alias 0.10.6 ausprobieren und evtl. sogar bis zu stable hochziehen.
Bitte ausprobieren. Danke :-)
Hier die Neuerungen
https://gluon.readthedocs.io/en/v2019.1.x/releases/v2018.2.3.html
https://gluon.readthedocs.io/en/v2019.1.x/releases/v2018.2.4.html
Hier der Download
Eine neue experimentelle Firmware 0.10.3 (gluon 2018.2) ist fertig und bereit zum testen.
Sie ist zu finden unter https://cccgoe.de/freifunk/experimental
Die Knotenposition kann man jetzt direkt bei der Installation in einer Map auswählen
Wenn ein Knoten mal keine Verbindung zum Internet hat wechselt er die SSID in FFGOffline_$nodename
In der ersten Runde haben wir das Netz von 0.8.7 auf 0.9.3 und 0.10.1 (die experimental Nodes) angehoben:
Das ist nebenbei auch immer ein schöner Test, wieviele Nodes tatsächlich aktiv sind.die 72 verbliebenen sind zumindest in den letzten Wochen nicht online gewesen.
Wir starten heute das Update auf 0.10.1 auf den Beta-Nodes und wenn dabei keine Probleme auftreten bekommen das alle anderen auch.
Unser Göttinger Freifunk-Netz verwendet (Stand Oktober 2018, mit sehr wenigen Ausnahmen) zwei Firmware-Versionen:
Die Betaversion sollte eigentlich auch mal zur stable werden, aber das Projekt haben wir einschlafen lassen. Wir sehen sie daher nur auf Nodes, die von der stable Version nicht unterstützt werden.
Durch unsere Faulheit haben wir zwar ein sehr stabiles Netz, das wenig durch mit Technik spielende Administratoren belästigt wird, aber die Bitten um neuere Firmware zwecks Einsatz neuerer Hardware werden häufiger.
Das Netz produziert (leider) immer noch immer mehr Traffic, obwohl die Anzahl der Nodes ziemlich stabil um die 800 schwankt. Damit sind wir gerade noch in der Lage weiterzumachen, ohne den großen Aufwand einer Aufteilung des Netzes durchführen zu müssen.
Das Wachstum des Netzes über die problematische Grenze hinaus haben wir halbwegs erfolgreich gebremst, in dem wir z.B. Werbemaßnahmen eingestellt haben und befreundete Freifunk-Projekte im Landkreis ermuntert haben, anstatt das Göttinger Netz immer größer zu machen, eigenständige Netze aufzubauen. Die besten Beispiele sind die großen Projekte in Hann-Münden und Einbeck. Von der Anzahl der Nodes her wäre das ganz offensichtlich auch in Osterode und Duderstadt denkbar.
Und seit Abschaffung der Störerhaftung beraten wir Interessenten, die dafür in Frage kommen, immer in die Richtung, doch einfach ein offenes WLAN bereitzustellen, und das gerne auch “Freifunk” zu nennen.
Dennoch ist unser letztes Firmware-Update lange her und die Router-Hersteller nehmen bewährte Hardware vom Markt um immer neue hinterherzuschieben. Die Schornsteine müssen rauchen. Also dann…
Das Gluon-Team hat Updates herausgebracht, mit 29 (!) neuen Hardware Plattformen. Das Update erfolgt in zwei Schritten, weil die TP-Link CPE 210/510 für den Sprung auf die aktuellste Version eine Zwischenversion benötigen.
In den nächsten Wochen werdet Ihr daher zwei Upgrades erleben:
Wer einen VPN-Beschleuniger einsetzt, lese bitte baldmöglichst:
https://gluon.readthedocs.io/en/v2018.1.x/releases/v2017.1.htm
Die allermeisten von Euch haben ihre Freifunk-Router auf “stable” und “autoupdate” stehen und müssen daher nichts machen. Alle anderen sollten die neuen Firmwareversionen von Hand einspielen (oder die Router umstellen).
Wir haben Euch die neuen Plattformen aus den Release-Notes zusammengeschrieben. Neben sehr vielen, teilweise sicherheitsrelevanten Bugfixes wird wie gesagt, ganz viel neue Hardware unterstützt.
Drückt uns allen die Daumen
Eure Göttinger Freifunker
(Gluon 2016.2.6)
ar71xx-generic
(Gluon 2017.1)
ar71xx-generic
ar71xx-tiny
x86-generic
The x86-kvm and x86-xen_domu targets have been removed; the x86-generic images now support these usecases as well, so no separate targets are needed anymore.
x86-geode
The new x86-geode target for hardware based on Geode CPUs has been added.
(Gluon 2017.1.4)
ar71xx-generic
(Gluon 2017.1.5)
ar71xx-generic
ramips-mt7621
(Gluon 2017.1.8)
ar71xx-generic
ar71xx-tiny
(Gluon 2018.1)
ar71xx-generic
ar71xx-nand
ar71xx-tiny
ipq806x
ramips-mt7620
ramips-mt7628
ramips-rt305x
sunxi
Dies betrifft alle Betreiber eines x86 Gluon Systems. Das sind die Futros und Verwandte.
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 0.
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“
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:
$ 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)
/etc/ld.so.conf.d/tsm.conf
löschen bzw. wo auch immer man das damals für TSM Client eingetragen hat.
$ 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.”
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
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.”
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 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 im September in unserer Filterblase 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.
+49 4643-38(764)27
67426532
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:
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:
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:
| CUDA | OpenCL | Metal | Aura | |
|---|---|---|---|---|
| level 1 | grid | global work | threads per group | mesh |
| level 2 | block | local work | thread groups | bundle |
| overall | grid * block | global work | threads per group * thread groups |
mesh * bundle |
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.
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:
| Mesh | Nicht-Mesh | |
| Luft | Ad-Hoc WLAN “mesh.ffgoe” | WLAN “Freifunk |
| Kupfer | VPN Mesh | LAN “Freifunk” |
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.
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:
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.
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();
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
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
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.
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.
/me... prego!
Bitte keine heiße Asche einwerfen
Dorfdisco
Echelon Blog
Freifunk Göttingen
GeekShow
Olivers Blog
Vorlon's Blog
einfach-orange.de
exdc
patzi.de
Last updated:
January 20, 2020 06:44 PM
All times are UTC.
Powered by:
