Apr 23

node.js ist nett. Vor allem, wenn man auf WebRTC/Sockets setzt. Komplex wird es, wenn man das ganze hinter einem Apache betreibt. Habe jetzt 2h damit verbracht die WS irgendwie an den internen node prozess weiterzuleiten, ohne dass socket.io sich verschluckt. Damit nicht der Nächste vor dem selben Problemchen steht und Stunden versenkt, hier der relevante Teil der apache-conf:

Annahmen:

  • Der interne node.js-prozess horcht auf Port 6543
  • Alles was Websocket ist, wird via /socket.io abgewickelt und hat auch den Transportheader auf „websocket“

<IfModule mod_proxy.c>
  RewriteEngine On
  ProxyVia On
  ProxyRequests Off
  ProxyPreserveHost on
  
  RewriteCond %{REQUEST_URI}  ^/socket.io            [NC]
  RewriteCond %{QUERY_STRING} transport=websocket    [NC]
  RewriteRule /(.*)           ws://internal.etherpad.ip:6543/$1 [P,L]
  ProxyPassReverse /socket.io ws://internal.etherpad.ip:6543/socket.io
  
  RewriteCond %{REQUEST_URI} !^/p/
  RewriteCond %{REQUEST_URI} !^/static/
  RewriteCond %{REQUEST_URI} !^/ep/
  RewriteCond %{REQUEST_URI} !^/minified/
  RewriteCond %{REQUEST_URI} !^/api/
  RewriteCond %{REQUEST_URI} !^/ro/
  RewriteCond %{REQUEST_URI} !^/error/
  RewriteCond %{REQUEST_URI} !^/jserror
  RewriteCond %{REQUEST_URI} !/favicon.ico
  RewriteCond %{REQUEST_URI} !/robots.txt
  
  ProxyPass / http://internal.etherpad.ip:6543/ 
  ProxyPassReverse / http://internal.etherpad.ip:6543/
  <Proxy *>
    Options +FollowSymLinks -MultiViews
    AllowOverride All
    Order allow,deny
    allow from all
  <Proxy>
<IfModule>

									

Tagged with:
Dez 13

Hat man zwei ipv6-uplinks ist es wichtig, dass Connections die über Provider „A“ reinkommen, auch über Provider „A“ wieder rausgehen. Mit den default-settings ist das nicht der Fall. Wenn dort etwas via „A“ reinkommt, die default-route aber „B“ ist, versucht der Router die Antwortpakete via „B“ rauszurouten. Das geht idR schief, da der ISP meint man würde die IP faken. Aber es gibt Abhilfe:

Folgendes SetUp nehmen wir mal an:

ppp0 (Telekom): 2003:1::2 mit aktiver default gw ppp0
eth0 (sixxs): 2001:2::2 mit NICHT aktiver default-GW 2001:2::1
									

Alles was nun via eth0 (hinter dem der sixxrouter irgendwo hängt) reinkommt, will linux via ppp0 beantworten.

Lösung: Eine rule anlegen:

echo "100 sixxs" >> /etc/iproute2/rt_tables
/sbin/ip -6 rule add from 2001:2::/64 lookup sixxs
/sbin/ip -6 route add default via 2001:2::1 dev eth0 table sixxs

									

Der Output von route und rule sollte am Ende dann wie folgt aussehen:

router:~# ip -6 rule
0:  from all lookup local 
16383:  from 2001:2::/64 lookup sixxs 
32766:  from all lookup main

router:~# ip -6 route
2001:2::/64 dev eth0  proto kernel  metric 256 
2003:1::2 dev ppp0  proto kernel  metric 256 
default via fe80::10ca dev ppp0  metric 1024  initcwnd 10 initrwnd 10

router:~# ip -6 route list table sixxs
default via 2001:2::1 dev eth0  metric 1024
									

 

Tagged with:
Mai 31

ipv6 ist nett. Aber der User bekommt halt jedes mal idR ein /64 Subnet. Für so Tools wie fail2ban, die einzelne IPs blocken, wenn irgendetwas komisches auftaucht irgendwie schlecht. Der Angreifer schnappt sich halt irgendeine neue IP, denn die unteren 64bit stehen ja voll zu seiner Verfügung.

Jetzt verhält es sich mit dem originalen fail2ban so, dass das nicht mal ipv6 kann. Zeit sich auf die Suche zu machen. In einem github-Repo bin ich fündig geworden. Der gute Mensch hat fail2ban so erweitert, dass es v6-fähig wird. Also flugs mal installiert, um direkt die Ernüchterung zu spüren: Es blockt mit /128 🙁

Also erweitern:

Die /etc/fail2ban/action.d/iptables-46-multiport-log.conf passen wir wie hier in diesem gist sichtbar an. Hinzugekommen ist lediglich <mask> bei der ban und unban-Regel sowie unter init. Das bedeutet, dass – sofern nicht anders angegeben – immer eine /32er CIDR-Mask gelegt wird, also die gesamte v4-IP (bei v6 halt ebenfalls /32 – aber dazu später mehr) geblockt wird.

Da die fail2ban-Variante von „usrweiss“ im Wrapperscript nicht so granular zwischen v4 und v6 differenzieren kann, als dass wir da andere cidr-Masken drauflegen könnten, legen wir einfach in der /etc/fail2ban/jail.conf ZWEI Jails an:

[web_v4]
enabled = true
filter  = web_v4
action = ip64tables-multiport-log[name=web_v4, protocol="tcp", port="80,443", mask=32]
logpath = /var/log/apache2/web_f2b/fails.log
maxretry= 5
bantime = 60
findtime= 60

[web_v6]
enabled = true
filter  = web_v6
action = ip64tables-multiport-log[name=web_v6, protocol="tcp", port="80,443", mask=64]
logpath = /var/log/apache2/web_f2b/fails.log
maxretry= 5
bantime = 60
findtime= 60

									

Die benötigen wiederrum auch 2 Configs in der /etc/fail2ban/filter.d:

/etc/fail2ban/filter.d/web_v4.conf:

# Fail2Ban configuration file
#
#
# $Revision: 250 $
#

[INCLUDES]

[Definition]

failregex = Applikation: v4 (<HOST>) Detaillierte Fehlermeldung .*

									

/etc/fail2ban/filter.d/web_v6.conf:

# Fail2Ban configuration file
#
#
# $Revision: 250 $
#

[INCLUDES]

[Definition]

failregex = Applikation: v6 (<HOST>) Detaillierte Fehlermeldung .*

									

Der Haken ist, dass unsere Applikation, die die Events auslöst (hier eine Loginseite, die die Fehlversuche nach /var/log/apache2/web_f2b/fail.log wegschreibt) an die Zeile dranschreiben muss, ob es sich um v4 oder v6 handelt. Bezogen auf die o.g. Configs sieht das in dem fail.log der App so aus (Von der Applikation generierte Einträge. Erster: v6, zweiter v4)

[May 31 10:08:12] Applikation: v6 (2a03:2880:2130:cf05:face:b00c:0:1) fehlerhafter Loginversuch blabla
[May 31 10:09:12] Applikation: v4 (173.252.120.6) fehlerhafter Loginversuch blabla
									

Von nun an blockt fail2ban die Ports 80 und 443 sobald in der Logdatei der Applikation (/var/log/apache2/web_f2b/fail.log) 5 mal innerhalb von 60 Sekunden die selbe IP mit einem Fehler aufschlägt für 60 Sekunden. Und zwar bei einer v4 halt die v4, bei einer v6 das /64er Subnet der v6. Die gerade greifende Netzmaske wird in der/etc/fail2ban/jail.conf als Variable „mask“ in der action mit angegeben – sollte dort nichts stehen, gilt der Defaultwert von /32 aus der iptables-46-multiport-log.conf

 

Wie üblich, geht das sicherlich noch eleganter. Bin gespannt, wann fail2ban endlich eine v6-Variante releast.

Tagged with:
Mai 24

Wie hier im Blog schon beschrieben, habe ich mir mit einem Pi A einen kleinen Statusscreen gebastelt, der sich immer dann anschaltet, wenn jemand in die nähe des Pi’s kommt. Realisiert wurde das mit der PiCam – basierend auf Helligkeitsänderungen beim Snapshot. Soweit so gut. Seit 2 Monaten hängt sich der olle Pi jedoch regelmässig auf. So schlimm, dass ich Ihm einen crontab-Eintrag verpasst habe, mit dem er jede Nacht neu bootet.

Zeit der Sache mal auf den Grund zu gehen. Das Problem war: Zu wenig RAM. Der Pi A hat gerade 256MB davon (eigentlich mehr als genug, für soetwas). Dummerweise hängt in PiCam direkt an der GPU des kleinen Rechners. Was bedeutet, dass man dem Ding in der /boot/config.txt den Parameter gpu_mem=128 mitgeben muss. Heisst: 128MB für die GPU (drunter funktioniert die cam nicht) und 128MB für das OS. Sofern man nun nicht eine extraschlanke Distribution mit busybox und dem ganzen Small-Mem-Footprint-gedönse nutzt, ist das verdammt mau. Erst recht mit der extrem aufgeblasenen Raspianedition.

Also mussten Lösungsansätze her. Die Cam mit weniger als 128MB GPU-RAM zu betreiben funktioniert also schon mal nicht. Dann halt komplett anders.  Für gerade mal 1,10 Euro/Stück gibt es bei Amazon PIR-Sensoren. PIR steht für Pyroelektrische Passive Infrarot Sensoren. Die Dinger, die man aus den Bewegungsmeldern an Aussenlampen kennt. Das besondere an diesen PIRs ist, dass sie out-of-the-box mit dem Pi über GPIO spielen können.

Obwohl das Chinaware ist, ist es relativ gut dokumentiert. In dieser Grafik findet sich alles, was man wissen muss:

Wir sehen zwei Potentiometer, mit denen man die Empfindlichkeit und eine Art „Nachlaufwert“ einstellen kann. Den Timer stellt man am besten auf „0“ (Anschlag ganz links), das „Distanz“-Poti nach Gusto. Nun zum elektrischen:

  • VCC bei dem Ding ist 5V – der kommt also an PIN2 des GPIO’s (+5V OUT)
  • GND auf GND – PIN 6
  • OUT ist der PIN, der „HIGH“ wird, wenn sich was vor dem Sensor bewegt. Und coolerweise spuckt das Ding ca. 3,3V aus – also genau richtig für den GPIO. Den hängen wir an GPIO18 (PIN 12)

Hier eine Übersicht der GPIO-PINs des raspis:

Nach dem das nun alles Erledigt ist, geht es zum simpleren Teil. Der Software. Ich habe das ganze, wie bereits beim Cam-Script in Python realisiert:

#!/usr/bin/python
import subprocess
import os
import time
import RPi.GPIO as io
from datetime import datetime
delay=60
monitor='on'
pir_pin = 18
io.setmode(io.BCM)
io.setup(pir_pin, io.IN)         # activate input

def turnMonitorOn(extrarg):
  global monitor
  monitor='on'
  subprocess.call("/usr/bin/screen.sh on "+extrarg, shell=True)

def turnMonitorOff(extrarg):
  global monitor
  monitor='off'
  subprocess.call("/usr/bin/screen.sh off "+extrarg, shell=True)
   
# Reset last capture time
lastCapture = time.time()
# added this to give visual feedback of camera motion capture activity.  Can be removed as required

while True:
  time.sleep(0.5)
  if io.input(pir_pin):
    lastCapture = time.time()
    if (monitor == 'off'):
      turnMonitorOn("y")

  if (time.time()-lastCapture > delay):
    if (monitor == 'on'):
      turnMonitorOff('x')

									

In der Variable „delay“ kann man einstellen, wie lange der Screen nach einer Bewegungserkennung angeschaltet bleiben soll. Es sind natürlich auch andere Pins als GPIO18 möglich (bspw. GPIO4 / Pin7)

Das Shellscript, „screen.sh“ ist dasselbe, wie im Cam-Post:

#!/bin/bash
tvstat=$(tvservice -s |grep off)
if [[ $tvstat == *off* ]]; then
TV=OFF
else
TV=ON
fi

if [ "$1" == 'on' ] && [ "$TV" == "OFF" ]; then
/usr/bin/tvservice -p;
#fbset -depth 8;
#fbset -depth 16;
chvt 2;
sleep 1
chvt 1;
chvt 2;
chvt 1;
#echo 'Switched Screen ON!'
fi
if [ "$1" == 'off' ] && [ "$TV" == "ON" ]; then
/usr/bin/tvservice -o
echo 'Switched Screen OFF!'
fi

									

Nun noch in der /boot/config.txt den Wert gpu_mem auf 32 oder gar 16 stellen, rebooten, und wir haben wieder mehr als genug RAM. Dass die CAM nun nicht mehr funktioniert, sollte jedem klar sein – aber das war ja auch Sinn und Zweck der Sache.

Tagged with:
Apr 26

Ich betreibe hier seit über einem Jahrzehnt ein paar von diesen netten günstigen Dallas-1-Wire Dingern (DS1820) an einer Linuxkiste mit samt USB-Host-Adapter im sog. „Parasite-Mode“ (Ausser GND und Data benötigt man da nichts, und kann ein paar von den Sensoren – an bspw. im Haus liegenden Telefonkabeln – abfragen).

Der USB-Host-Adapter ist eigentlich überflüssig, da der Pi das mit seinen GPIO’s von Haus aus kann. Und das ganze ist derartig trivial, dass ich es hier kurz erklären will. Man nehme:

  • den o.g. DS1820 (da gibts div. Variationen von, die sich in der Präzision unterscheiden – kosten ca. 2 Euro)
  • Einen Pi – mit Linux drauf.

 

Den 1820 wie folgt mit dem Pi verbinden:

GND auf GND // Vdd auf 3,3V // VDQ (Data) auf GPIO 4

(Hier eine Ansicht des 1820, und hier eine des GPIO-Ports vom Pi)

Dann ab auf die Shell und kurz 2 Kernel-Module nachladen:

 pi@rasbberrypi ~ $ sudo modprobe w1-gpio pullup=1
 pi@rasbberrypi ~ $ sudo modprobe w1-therm
									

Wenn alles richtig gelaufen ist, gibt es unter /sys/bus/w1/devices nun ein neues Verzeichnis mit der Unique-ID des 1820 (Die haben alle eine Art Mac-Adresse, die die einmalig macht) in dem wiederum eine Datei mit dem Namen „w1_slave“ liegt. Angenommen der 1820 hat die ID „28-0000041234567“ so heisst unsere Datei : „/sys/bus/w1/devices/28-000004593386/w1_slave“. Wenn man sich diese anzeigen lässt (zB via cat), kommt (etwas unsexy) der platte Temperaturwert als ASCII zum Vorschein.

Den hübschen wir nun noch auf, und schon haben wir einen Wert, den man weiterverarbeiten kann (snmp, website, wo auch immer):

cat /sys/bus/w1/devices/28-000004593386/w1_slave |\
grep -e 't=' | \
awk -F't=' '{print $2}'
									

Günstiger kann man keine Temperaturen messen – und erweiterbar und flexibel ist es auch noch. (Es sei denn man will unbedingt 100 Euro für das neueste, hippe, bunte Temperaturmessdevice, dass nur mit App läuft, ausgeben und die Werte alle Nasen lang in die Cloud pumpen…)

Tagged with:
Dez 26

In einem der tmux-Fenster des letzten Beitrags läuft ein tail auf das squid-access.log.
Dummerweise zeigt das tail nach einem logrotate nichts mehr an, da das Filehandle vom tail ja auf das „rotierte“ log zugreift.
Fein wäre doch ein kleines Script, dass, sobald im geöffnet Filehandle nichts mehr kommt, die Datei „reopened“ und dann weiter anzeigt.

Bitte sehr (Perl // Modul File::Tail vorrausgesetzt):

#!/usr/bin/perl
use File::Tail;
use Socket;
use strict;
$|=1;
my $logfile="/var/log/squid-access.log";
my $file=File::Tail->new(name=>$logfile, maxinterval=>300, adjustafter=>7);
while (defined(my $line=$file->read)) {
        my @liner=split(' ',$line,-1);
        my $host='';
        $host=gethostbyaddr(inet_aton($liner[8]), AF_INET) or $host=$liner[8];
        my @hostname=split(/./,$host); # Split FQDN at dots
        $host=$hostname[0];             # Get Lowest Domainname
        my @hosts=split(/./,$liner[8]);# Split IP at dots
        my $loctet=$hosts[3];           # Get last Octet
        printf "%s %3s %st%sn",$liner[2],$loctet,$host,$liner[12];
}
									

Das Ding zieht gleichzeitig die wichtigsten Infos aus dem Log. Nämlich den Timestamp, das letzte Octet der IP, sowie den ersten Part des Reverse-DNS-Namens.

Tagged with:
Dez 23

Es ist mal wieder Zeit für ein kleines Urlaubsprojekt.
Hier lag seit 3 Jahren, neben einem RaspberryPi und nem alten 17″ Eizo-Screen, so ein Wandhalter für TFT-Screens herum. Da kann man doch was raus machen.

Also fix den Wandhalter an die Wand gedübelt und den Pi mit NFS-Root (siehe Eintrag hier) aufgesetzt.
Der Pi selbst ist mit dem Cam-Modul ausgestattet, und hängt per HDMI 2 DVI an dem o.g. Eizo.

Folgende Ziele habe ich verfolgt (und umgesetzt):
– Autologin nach reboot, sowie automatisches einloggen auf nem Server und attachen an tmux
– Sobald sich was vor der Cam bewegt, soll der Monitor „aufwachen“, nach 60s. wieder ausgehen.

Ist an sich recht einfach. Fangen wir mal mit dem Autologin an:
via /etc/inittab sagen wir dem Pi, dass er sich – anstelle des logins – auf dem tty1 als „pi“ einloggen soll:

#1:2345:respawn:/sbin/getty --noclear 38400 tty1
1:2345:respawn:/bin/login -f pi tty1 /dev/tty1 2>&1

Dazu die obere Zeile auskommentieren, und die untere einfügen.
Nach einem reboot sollte der pi nun direkt auf der Shell als User „pi“ landen.
Alles weitere (ssh-login) und Co. machen wir in der ~pi/.bashrc (letzte Zeile einfach anfügen)

ssh -t [user]@[machine wo tmux rennt] "tmux att"

Nun sollte nach dem Reboot (ssh-keys und laufender tmux auf „machine“ vorrausgesetzt) direkt der tmux erscheinen. Den kann man dann vom „normalen“ Rechner aus mit content bestücken (top, iftop, tail aufs log, etc.)

Wer noch Hintergrundbild und höhere Auflösung auf dem pi haben möchte, dem seit fbterm ans Herz gelegt.

Weiter gehts mit der „Motiondetection“. Dazu habe ich mir erstmal ein kleines Shellscript gebaut, welches den Monitor an/ausschalten kann, und dieses unter /usr/bin/screen.sh abgelegt:

#!/bin/bash
tvstat=$(tvservice -s |grep off)
if [[ $tvstat == *off* ]]; then
TV=OFF
else
TV=ON
fi

if [ "$1" == 'on' ] && [ "$TV" == "OFF" ]; then
/usr/bin/tvservice -p;
#fbset -depth 8;
#fbset -depth 16;
chvt 2;
sleep 1
chvt 1;
chvt 2;
chvt 1;
#echo 'Switched Screen ON!'
fi
if [ "$1" == 'off' ] && [ "$TV" == "ON" ]; then
/usr/bin/tvservice -o
echo 'Switched Screen OFF!'
fi

Nicht von den chvt verwirren lassen. mit tvservice wird der Monitor an/ausgeschaltet, mit chvt auf das entsprechende (Virtuelle) Terminal umgeschaltet. Quasi das Shell-pendant zu „ALT-F1 bis ALT-F10“ zum Console wechseln. Ohne das hin- und herschalten via chvt geht der Moni zwar an, aber es wird nichts angezeigt.

Die eigentlich Motiondetection ist in Python gebastelt (wie üblich: Kurz und schmutzig):

#!/usr/bin/python
import StringIO
import subprocess
import os
import time
from datetime import datetime
from PIL import Image
threshold = 10
sensitivity = 180
monitor='on'

# Capture a small test image (for motion detection)
def captureTestImage():
    command = "raspistill -n -w %s -h %s -t 1 -e bmp -o -" % (100, 75)
    imageData = StringIO.StringIO()
    imageData.write(subprocess.check_output(command, shell=True))
    imageData.seek(0)
    im = Image.open(imageData)
    buffer = im.load()
    imageData.close()
    return im, buffer

def turnMonitorOn():
  global monitor
  monitor='on'
  subprocess.call("/usr/bin/screen.sh on", shell=True)

def turnMonitorOff():
  global monitor
  monitor='off'
  subprocess.call("/usr/bin/screen.sh off", shell=True)

# Get first image
image1, buffer1 = captureTestImage()
# Reset last capture time
lastCapture = time.time()
# added this to give visual feedback of camera motion capture activity.  Can be removed as required
while (True):
    # Get comparison image
    image2, buffer2 = captureTestImage()
    # Count changed pixels
    changedPixels = 0
    for x in xrange(0, 100):
        # Scan one line of image then check sensitivity for movement
        for y in xrange(0, 75):
            # Just check green channel as it's the highest quality channel
            pixdiff = abs(buffer1[x,y][1] - buffer2[x,y][1])
            if pixdiff > threshold:
                changedPixels += 1
        # Changed logic - If movement sensitivity exceeded then
        # Save image and Exit before full image scan complete
        if changedPixels > sensitivity:   
            print "change "+monitor
            lastCapture = time.time()
            if (monitor == 'off'):
                turnMonitorOn()
            break
        continue
    if (time.time()-lastCapture > 60):
  if (monitor == 'on'):
          turnMonitorOff()

    # Swap comparison buffers
    image1  = image2
    buffer1 = buffer2

									

Wenn man das Ding nun laufen lässt, macht es im dauerloop ein Bild in niedriger Auflösung von der Cam, und vergleicht die Helligkeitswerte mit denen des vorherigen Pics. Ist der Unterschied grösser als „threshold“, dann macht das Script den Monitor an. Nach 60s ohne Bewegung wird er wieder ausgeschaltet.
Jetzt nur noch das Script mit „start-daemon“ in ein init.d Script packen und beim booten automatisch starten, und fertig.

Wie immer gibt es zig Wege dahin, dies ist nur einer von vielen. Das ganze kann man sicher noch immens optimieren. Für hier ist es mehr als in Ordnung.

Tagged with:
Jun 10

Schreibe hier mal nach und nach ein paar hilfreiche Erfahrungen auf, wenn man – wie ich – den Schritt von IOS nach Android wagt, und von der ganzen Cloud-Struktur nicht so viel hält.

Ein wenig eigene Infrastruktur je nach Geschmack (Mailserver, CAL-/CARDDAV-Server, Proxy mit adblocker nach gusto, eigener DNS) sollte es jedoch schon sein, wenn man die wichtigsten Daten von der Cloud fernhalten möchte. Das war unter ios so, und gilt unter Android mehr denn je. Also los gehts mit den Basics:

  • Mails: Da eignet sich K9-Mail ganz gut – ist etwas anders als Mail.App zu bedienen, kann aber nach meinen Vertestungen am meisten
  • Kalendersync: CalDAV-Sync integriert den eigenen CalDAV zu 100% in die Android-Welt, und das ganz ohne gmail-Kalender. Reminder und Co. funktionieren sauber!
  • Telefonbuch: CardDAV-Syncfree synct wunderfein die Kontakte mit dem heimischen CardDAV-Server (zum einsatz kommt hier übrigens davical)
  • Notizen: Werden bei ios/osx als „spezielle Mail“ in einem Subfolder mit Namen „Notes“ abgelegt. Da gibts was günstiges für den Droiden: iNotes – nicht von der Beschreibung im Store verwirren lassen, der spielt echt mit jedem imap (hier ist der gute alte cyrus im Einsatz)
  • Twitter: Tja. Da bin ich noch nicht so ganz weiter. Tweetbot gilt nach wie vor als ungeschlagen. Aber Tweetveo kommt zumindest schon mal etwas dran. [Update 10.06.14] Plume isses ! Tweetmarker-Support. Suchen nach Antworten – also all das was Tweetbot auch kann – zumindest auf den ersten Blick. Danke an @bridgerdier [Update 05.12.2014] Fenix ist der Twitterclient der Wahl
  • Newsreader: Original tt-rss Client für tinytiny – geht doch 🙂

Nun bringt das alles herzlich wenig, wenn man die Äpps auf dem Device, sowie das OS nicht einigermassen abschotten kann. Und an dem Punkt kommt Cyanogenmod – das mich überhaupt bewegt hat, von IOS nach Android zu wechseln – ins Spiel. Nicht ganz trivial zu installieren (Grobe Vorgehensweise: Bootloader unlocken, CWM/TWM aufspielen, Image installieren) aber in der Version 11 (Analog KitKat) sehr empfehlenswert. So lässt sich jede Äpp beliebig kastrieren (Bis hin zu: „Darf die App vibrieren?“ und so). Ein Feature das google seit 4.4.2 wieder ausgebaut hatte. Hier isses drin. Und das ganze CM11 ist echt stabil.

Wer dann den Droiden noch weiter abschotten möchte, dem sei (CM11 bzw. root vorrausgesetzt) noch Droidwall ans Herz gelegt. Ganz platt gesagt ist Droidwall ein Frontend für iptables mit dem man pro Äpp sagen kann, ob diese überhaupt ins Netz darf. Heisst: Wenn ich bspw. ne Taschenlampe installiere, dann braucht die mal definitiv keinen Netzzugriff… Logging gibts gratis obendrauf.

Ansonsten macht AdFree von BigTinCan noch den solidesten Eindruck. Warum das Teil von einer sehr dubiosen Website kommt, nicht im Playstore verfügbar ist und überhaupt, weiss wohl niemand. Habe dieses Ding ausgewählt, weil es ganz simpel die /etc/hosts um einschlägige Werber ergänzt, und echt nicht mehr anstellt. Alles andere wollte direkt Nutzungsdaten und Co. nach Hause funken. Dieses schicke kleine APK macht genau das was es soll (Werbung fernhalten – und das auch noch relativ elegant).

[Update 11.06.14] Mit IOS8 soll es ein Update geben, bei dem das iPhone die Mac-Adresse des WLAN-Interfaces randomisiert während es keinerlei Connect zu einem WLAN hat. Löbliches Feature. Geht mit dem Droiden natürlich auch. Guckst du Pry-Fi im Playstore. Das das Teil root-Rechte benötigt, liegt auf der Hand.

Am meisten weggetan hat das Messaging. Kenne ich doch recht viele ios-iMessage Menschen. Da gibt es leider nur Pest oder Cholera als Ersatz. Facebook möchte ich nun nicht gerade in Form von WhatsApp beglücken, also hab ich mich neben SMS für Google-Hangouts entschieden. Ob bei Kurznachrichten jetzt Apple oder google mitliest ist da relativ. (Nur FB sollte es halt nicht sein). Das ganze Thema Messaging ist extremst unbefriedigend, sowohl unter ios als auch unter Android. Diesen ganzen Placeboteile wie Threema und wie sie nicht alle heissen kann man auch nicht trauen (ist halt kein opensource). Daher gibts hier halt einen Kompromiss.

Wenn jemand noch weitere Tips hat, immer gern her damit.

Gesucht wird bspw. noch:

  • PodFetcher
  • FeedReader (Gut, Feeds lese ich hauptsächlich auf dem iPad – aber wer weiss: Vielleicht kommt da ja auch irgendwann mal ein Droide hin)
Tagged with:
Jan 25

Gaaaanz kurze knackige Anleitung, wie man einen PGP/GPG Key beglaubigt  bzw. signiert (unvollständig, und OHNE Anleitung, wie man den Key auf korrektheit prüft – idealerweise signiert Ihr nur Keys, bei denen Ihr 100%ig sicher seid, dass diese auch vom passenden Keyowner kommen 🙂 )

Shell:

[gpg –list-keys] Pub-Key-ID des zu signierenden keys merken

[gpg –sign-key <pubkeyid>] Das eigentliche Signieren

[gpg –send-keys <pubkeyid>] Signieren dem Keyserver bekanntmachen

OSX / GPGTools:

  • GPG Schlüsselbund (GPG Keychain) starten.
  • Rechte Maustaste auf den zu signierenden Key
  • Beglaubigen anclicken, Details entsprechend wählen und OK drücken
  • Wieder rechte Maustaste, diesesmal „Öffentlichen Schlüssel an Schlüsselserver senden“

Der letzte Punkt – also das Veröffentlichen der Beglaubigung, wird gern vergessen. Ohne diesen Schritt ist das ganze jedoch recht witzlos.

[UPDATE]

Bei mehreren uids (Identitäten) pro Key:

  • Doppelclick auf den Key in der Keychain-GUI
  • Wechsel auf den „Benutzer-ID“-Tab
  • Zu bestätigende Identität OBEN auswählen
  • Unten auf das Plus clicken und beglaubigen
  • Anschliessend wieder raus, und „Öffentlichen Schlüssel an Schlüsselserver senden“ (s.o.)
Tagged with:
Jan 12

TT-RSS an sich ist ja eine feine Sache. Das Ding hat allerdings ein/zwei Haken, wenn man es für mehrere Leute hosted. Ich nutze das hier mit dem Fever-Plugin, damit man die Feeds auch einigermassen elegant auf mobilen Endgeräten nutzen kann.

Meist ist es ja so, dass $user sich eine Feedliste zusammenstellt, und sich dann Wochenlang nicht mehr ins Frontend einloggt (Hab ich beim Google-Reader damals™ auch so gemacht). Das nimmt einem ttrss aber übel. Denn nach 30 Tagen (Einstellbar in der ./include/rssfuncs.php // Zeile 2) sagt sich ttrss: Nee, der User hat sich seit 30 Tagen nicht mehr eingeloggt, dann update ich halt nicht mehr. Pikanterweise zählt der Fever-Login nicht (Plugins verwalten Ihre Daten „irgendwie“ anders – PHP-Magic halt).

Also merken: Wenn tt-rss nicht mehr updatet, entweder:

  • Zeile 2 der ./include/rssfuncs.php anpassen und hochdrehen (Halte ich für nicht so super)
  • Den/Die User/in anhalten, sich von Zeit zu Zeit mal ins Frontend einzuloggen
  • Oder (superschmutzig), per Hand das Feld last_login in der tabelle ttrss_users auf „NOW()“ updaten.

 

Tagged with:
Mai 19

Eigentlich hab ich mich ja immer gewehrt den schönen „Experimentiercomputer“ RaspberryPi zum „MediaCenter“ zu degradieren. Andererseits hatte ich ein wenig Not hier. Bis vor 2 Jahren hatte ich ’nen MacMini am TV-Gerät. Der ist dann irgendwann rausgeflogen und musste einem AppleTV (3) weichen.

Dummerweise kann das ATV3 sich nur bei Apple bedienen. Sprich alle fein säuberlich gekauften Filme und MP3s auf dem Fileserver konnten nur umständlich abgespielt werden, in dem immer irgendein olles iTunes auf dem Arbeitsplatzrechner lief. Zeit das zu ändern. Also Pi bestellt und RaspBMC draufgeknallt. Erster Begeisterung folgte direkt die Ernüchterung. Zu langsam, und zu buggy. Wenn bspw. der Pi hängt, hilft nur noch Strom raus und wieder rein, was die SD-Karte mit „Could not mount Root-FS“ oder so quittiert. Blöd alles. Doch es gibt eine Lösung für alles.

Ziel sollte es sein im Raspberry nur noch den Bootloader auf der SD-Karte zu haben (den braucht der leider, da der Pi kein Bootp/PXE beherrscht), und diese am besten auch noch mit ’nem Schreibschutz zu versehen. Gesagt getan. Was ist also notwendig?

  • 2GB SD-Karte fürs erste Setup
  • 32MB SD-Karte für den späteren Betrieb
  • Fileserver mit NFS-fähigkeit
  • Irgend ’ne Linux-Büchse um die Karten entsprechend zu präparieren (Mit OSX oder Windows ist das echt Schmerz)

Vorgehensweise:

  1. RaspBMC ganz normal auf der 2GB Karte installieren (dd if=[imagefile] of=/dev/sdz bsize=16M) wobei sdz das SD-Kartendevice ist.
  2. Rasbperry ans Netz hängen und booten/Erstkonfig durchführen.
  3. Während der konfiguriert setzen wir den NFS-Server auf (gehe mal davon aus, dass die Grundlagen zu NFS dem Leser bekannt sind)
    1. Directory, in dem das Rasberry-Rootfs wohnen soll erstellen (mkdir /rasberryrootfs)
    2. Directory in die /etc/exports aufnehmen:/rasberryrootfs          IP.VOM.RASP.BERRY(rw,async,no_root_squash,no_subtree_check,anonuid=65534,anongid=65534,insecure)
    3. exportfs -rv aufrufen
  4. Wenn Raspberry fertig, dann:
    1. per ssh einloggen (pi/raspberry)
    2. xbmc stoppen: sudo sudo initctl xbmc stop
    3. NFS-Filesystem mounten: mount IP.VOM.FILE.SERVER:/raspberryrootfs /mnt
    4. Kram umkopieren (sudo cp -axv /. /mnt/.
      sudo cp -axv /dev/. /mnt/dev/.
      )
    5. In der /mnt/etc/fstab folgende Zeile AUSkommentieren (also ein „#“ davorschreiben):
      /dev/mmcblk0p2  /               ext4    defaults,noatime 0       0
    6. NFS-Filesystem umounten (sudo umount /mnt)
    7. Raspberry herunterfahren (sudo init 0)
    8. Karte entnehmen und in die o.g. Linuxbüchse stecken, sowie das vfat-Filesystem der Karte mounten.
    9. Kram aus dem vfat-Filesystem irgend wo auf die Platte kopieren.
    10. Karte umounten / Brauchen wir jetzt nicht mehr.
    11. Jetzt die 32MB Karte in die o.g. Linuxbüchse stecken und ein vfat-Dateisystem auf einer Primären Partition vom Typ „MSDOS/VFAT“ erstellen.
    12. Den Krempel aus 9 auf die Karte kopieren.
    13. Jetzt noch die Datei cmdline.txt auf der 32MB Karte wie folgt anpassen:
      dwc_otg.lpm_enable=0 root=/dev/nfs rootfstype=nfs nfsroot=192.168.1.100:/raspberryrootfs,v3 ip=192.168.1.49:192.168.1.1:192.168.1.0:255.255.255.0:rpi:eth0:off smsc95xx.turbo_mode=N noatime rootwait loglevel=1 zram.num_devices=2
      Wobei folgendes gilt:

      1. Anstelle der 192.168.1.49 die IP des Raspberrys eintragen
      2. Anstelle der 192.168.1.100 die IP des NFS-Servers eintragen
      3. Anstelle der 192.168.1.1 die IP des Routers eintragen
      4. Anstelle der 192.168.1.0 die Netztadresse des Heimnetzes eintragen
    14. Karte umounten
    15. In den Pi stecken, und freuen 🙂

Wenn alles klappt, noch den nupsi für den Schreibschutz an der 32MB Karte aktivieren, und dann geht das Filesystem dort garantiert nicht mehr kaputt. Noch ein paar Tipps/Anmerkungen zur Performance von dem XBMC:

  • Alle überflüssigen Visualisierung sollten (so schick sie auch sein mögen) deaktiviert werden.
  • Krimskrams wie Samba-Server, Avahi, ftp auf dem Pi auch deaktivieren.

Viel Spass damit.

Tagged with:
Dez 13

Seit 4 Tagen bin ich den lästigen reconnect der Telekom los. Keine Zwangstrennung mehr nach 24h. Yes !

Wie das geht ? Ziemlich simpel. Man wechselt den Tarif beim rosa Riesen. „Call & Surf Comfort IP“ heisst das Ding. Einher mit dem Tarif geht ein SIP-Account, über den man von dort per VoIP erreichbar ist (Besonderheiten der Telekom inclusive – verfasse dazu noch einen Blogeintrag). Aufgrund dessen fällt dann nämlich die Zwangstrennung weg. Nun gut, genug Marketinggedönse. Zum eigentlichen: Wie ich ja schon gebloggt habe, bin ich zufriedener sixxs Kunde, was meine ipv6-Welt angeht. Schön statische Prefixe, soviel /56er subnetze (statisch!) wie man haben will. Eigentlich genau das, was man als Betreiber von ein paar unwichtigen Diensten im Netz so benötigt.

Ganz gegensätzlich ipv6 bei der Telekom. Man bekommt ein /64er /56er Prefix, und das ist zu allem übel auch noch dynamisch. Sprich bei jedem Reconnect (der zwar, s.o., nur noch alle Jubelmonate kommt) gibts wieder einen neuen Prefix. Ist jetzt nicht der ultimative Brüller, denn der Sinn von ipv6 war ja genau dieses Dilemma zu lösen. – Wir erinnern uns: in den 90ern gab es die dynamische Vergabe nur, weil die ganzen ISPs mehr Kunden als ipv4-Addressen hatten – also mit ipv6 eigentlich kein Grund mehr für sowas. Die Gründe mögen vielfältig sein. Paranoide Menschen sind der Meinung, dass man mit dyn.IP’s einen Datenschutzzugewinn hat (Bullshit !), die Telekom meint, dass man statische IPs besser hochpreisig vermarkten sollte, und so on.

Nun, was tun mit dem schwankenden ipv6-Prefix, bei dem man nichtmal ’ne DNS-Reversedelegation setzen kann ? Folgende Dinge sind mir so eingefallen:

  • Testen des sixxs.net oder HurricaneElectric-Tunnels von „aussen“ 🙂
  • Backup-Routing, falls sixxs/HE mal down sind (wobei das vermutlich tricky wird)
  • Den „User“ Kram aus dem Heimnetz über das /64 /56er routen. Alle Dienste über die statischen Netze

Naja, wie auch immer man sich entscheidet, das ganze unter linux auf einem „Selbstbaurouter“ einzubinden bedarf ein wenig Bastelei. Was haben wir ?

  • Ein Standard DSL-Modem (Speedport 221) / kein Router (an dieser Stelle sei erwähnt, dass, entgegen irgendwelchen Aussagen, ein Modem vollkommen ausreicht (sowohl für VoIP, als auch für Entertain, sowie für ipv6) – „pppoe-Passthrough“ in einem Speedportrouter kann funktionieren, muss es aber nicht. Je puristischer, desto besser.
  • Ein lauffähiges Linux, mit dem wir schon in der Vergangenheit pppoe gemacht haben und welches die öffentliche ipv4 bekommt. – Ich nehm‘ hier Debian. Ein vorkonfektioniertes pfSense, ipcop, und wie die Distributionen so alle heissen, sollte auch gehen.
  • pppoe über rp-pppoe wie gewohnt. Hier in die /etc/ppp/options ein „+ipv6“ eintragen

Jetzt gibts beim Reconnect zusätzlich zur ipv4 eine ipv6-LinkLocal-Adresse. Mit der kann man noch nicht so viel anfangen, denn die ist ja linklocal und damit nicht gerouted. An dieser Stelle hab ich echt am längsten (im wahrsten Sinne des Wortes) gehangen. Wie kommt man nun an die ipv6-IP ? Im Normalfall über zwei Wege. Entweder Router-Advertising, oder DHCPv6 (wobei letzteres nur bedingt empfehlenswert ist). Die Telekom announced die Prefixe per RA. Und zwar in 10 Minuten Intervallen. Was zum debuggen recht schmerzhaft ist (immer 10min. warten). Um dem geneigten Leser die Wartezeit (und das debuggen) zu verkürzen hier die Einstellungen die man am ppp0 vornehmen sollte (am besten in irgendein /etc/ppp/ip-up.d/file zur Firewall packen):

echo 0 > /proc/sys/net/ipv6/conf/ppp0/forwarding
echo 1 > /proc/sys/net/ipv6/conf/ppp0/autoconf 
									

Sodann wirds beim nächsten RA (wie gesagt: Nur alle 10 min. !) eine öffentliche IP geben, die dann über die, oben erwähnte, LinkLocal-Adresse raus/reingerouted wird. Routen sollten automatisch gesetzt werden.

ip6tables kann man dann nach gusto anpassen. Bei mir bekommt nur der „router“ die Dynamische-V6, da dort der (Zwangs-)Proxy mit adblocker & Co. läuft – reicht dort also. Wer das v6 im LAN nutzen möchte, dem sei der radvd (Router Advertising Daemon) ans Herz gelegt.

Ein Grundsetup an ip6tables-Rules finden wir hier:

/sbin/ip6tables -P INPUT DROP
/sbin/ip6tables -A INPUT -i lo -j ACCEPT              #allow everything out
/sbin/ip6tables -A INPUT -p icmpv6 -j ACCEPT
/sbin/ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/ip6tables -A INPUT -i $LAN -j ACCEPT       # allow GRE
/sbin/ip6tables -A INPUT -i $WAN -j LOG --log-prefix "INP6:End "
/sbin/ip6tables -A INPUT -i $WAN -j DROP

### OUTPUT
### (connections with the router as source)
echo "BASE OUTPUT"

  # base case
/sbin/ip6tables -A OUTPUT -o $WAN -j ACCEPT              #allow everything out
/sbin/ip6tables -A OUTPUT -o $LAN -j ACCEPT              #allow everything out
									

Happy v6ing !

 

[Update 26.02.2014] Es gibt ein /56er Prefix bei der Telekom, keine /64er – löst das Problem aber nicht. Danke an den Hinweisgeber.

Tagged with:
Jun 23

Die Konfig hier zu Haus sagt, gehe über den Proxy – egal was passiert. Per iptables ist es den Workstations verboten, direkte HTTP-Requests nach draussen abzusetzen. Die werden einfach gedroppt. Damit man jedoch nicht bei jedem neuen Client erst den Proxy eintragen muss, gibt es so schöne Erfindungen wie wpad.dat (aka proxy.pac).

Der DHCP Server im Netz announced also, bei Vergabe einer ip, gleich die URL fuer die Proxy-Autoconf mit. In der Regel klappt das auch alles super. Hätte nicht jeder Browserhersteller wieder seinen eigenen Kram gebastelt. So interpretiert der Safari auf dem Mac diverse Dinge anders als der Chrome oder der IE. Eine schöne Matrix, mit dem was geht, und was nicht geht, gibt es bspw. bei pacwpad.com.

Die Herausforderung bestand/besteht am Ende darin, den Browsern zu sagen: Hey, du willst was im LAN, dann brauchst Du den Proxy nicht zu fragen. Ansonsten bitte Proxy nehmen. Mit ipv4 kein Thema. Bei ipv6 verschluckt sich der Safari jedoch massivst.

In der folgenden Config bin ich nun soweit, dass Chrome brav das macht was er soll, Safari jedoch bei jeglichen (auch LAN) ipv6-only Websites immer über den Proxy geht. Das liegt daran, dass der Safari scheinbar die javascript-Funktion „dnsResolveEx“ nicht kennt. Ohne try/exception macht der immer einen auf „direct“ bei ipv6. Mit diesem Konstrukt geht er zumindest immer auf den Proxy. Bin mal gespannt, wie lange es dauert bis sich die Browserhersteller da geeinigt haben…

Hier also die Config:

  • LANv4 ist 10.0.0.0/24
  • LANv6 ist 2001:999:999:8888/64

function FindProxyForURL(url, host)
{
        if (isInNet(host, "10.0.0.0", "255.255.255.0")) { // ipv4 im LAN ? Dann direct
                return "DIRECT";
        }
        if (host.substring(0, 4) == "127.") { // Localhost ? dann DIRECT
                return "DIRECT";
        }
        if (host.substring(0,16) == "2001:999:999:8888") { // IPv6 Adresse in den Browser eingegeben, und die ist im LAN ? Dann DIRECT
                return "DIRECT";
        }
        try {
            var resolved_ip = dnsResolveEx(host);
            if (resolved_ip.indexOf("2001:999:999:8888")>-1 ) { // Hostname löst auf eine IPv6 auf, die im LAN ist ? Dann DIRECT
                    return "DIRECT";
            }
        } catch(e) { // Funktion "dnsResolveEx" nicht vorhanden ? Dann Fallback proxy
            return "PROXY 10.0.0.2:3128";
        } 
        return "PROXY 10.0.0.2:3128"; // Default: Proxy
}

									

Update: Es empfiehlt sich anstelle der IP (10.0.0.2:3128) den FQDN des Proxies einzutragen. Einige Geräte machen scheinbar einen lookup bevor sie den Proxy fragen. Wenn beim lookup eine V6 Adresse herauskommt, dann läuft die wpad.dat ins leere, da kein V6-Proxy gefunden wird. Wichtig: der FQDN des Proxies sollte sowohl über einen V4-Eintrag (A), als auch über einen V6-Eintrag (AAAA) verfügen, und auch zusätzlich auf dem V6-Port lauschen…

Tagged with:
Jun 17

So, es ist vollbracht. Die ganzen Consumer-Provider in good ‚ol Germany wollen ja irgendwie nicht so richtig mit ipv6 an den Start kommen. Also habe ich mal selbst Hand angelegt. Einen Provider hat man schnell gefunden. Ich habe mich für sixxs.net entschieden.

Bei sixxs.net bekommt man zunächst einen /64er Block für lau zugewiesen, den man hinterher auf /48 upgraden kann (Vorraussetzung: der 64er Tunnel läuft eine Woche durch / Downtimes, bspw. zum basteln, sind nicht tragisch). Einfach anmelden, „aiccu“ herunterladen, konfigurieren, starten und glücklich sein. Achtung: Aiccu / sixxs.net prüft die Systemzeit – Ein NTP-Client auf dem lokalen Endpunkt hilft da ungemein !

Das 48er-Subnet benötigt man aber nicht wirklich für den Heimgebrauch. Mit dem 64er kann man die restlichen 2^64 Adressen munter im Netz verteilen. Genau da war Anfangs auch mein Denkfehler. Mir war nicht aufgefallen, dass sixxs.net ein Transfernetz zur Vefügung stellt, durch das dass /64er gerouted werden kann. Konkret sieht das ganze nach dem ersten Start wie folgt aus:

  • PtP-Adresse (Da gehts also zu sixxs): 2001:6f8:100:fea::1/128 (Die beiden :: sind die Platzhalter für gaaanz viele Nullen – ausgeschrieben sähe das ganze so aus: 2001:6f8:100:fea:0000:0000:0000:1/128)
  • Lokale Adresse des ersten „ipv6“-Interfaces: 2001:6f8:100:fea::2/64
  • Und jetzt wird’s spannend. Im Webinterface bei sixxs.net kann man sehen, dass das zur Verfügung stehende Netz 2001:6f8:100:dfea::/64 lautet (Man beachte das „d“ bei Octet 7)

Mit dem dfea-Netz (die Adressen sind für den Blogeintrag gefaked) können wir nun intern loslurchen und die Rechner ausstatten. Im simpelsten Falle installiert man sich den radvd (Router Advertising Daemon) und konfiguriert sowie startet ihn. Der verteilt die Dinger dann im LAN. Achtung: Dem LAN-Interface muss man selbst eine (v6-)IP aus dem dfea-Netz verpassen (/etc/network/interfaces) – das macht der radvd nicht. Jetzt noch das ipv6-Fowarding enablen (echo 1 >/proc/sys/net/ipv6/conf/all/forwarding) und schon können alle anderen Rechner per ipv6 mit der Welt in Verbindung treten (oder auch angesprochen werden !!)

Was uns zu einem kleinen Schönheitsfehler bringt. Ich will ipv6, weil ich das genNATte und diese ewige dynamische IP-Vergabe leid bin. Dummerweise vergibt der radvd die IP’s aber höchstdynamisch. Statisch verfügbar wäre in diesem Szenario also allenfalls der Router. Schuld (- Die Diskussion will ich hier nicht führen -) sind die sog. „privacy extensions“ die irgendwelche paranoiden Mitmenschen entworfen haben. Ich war schon bei v4 kein Freund von „Würfel“-DHCP. Ganz abgesehen davon möchte ICH, und nicht irgendein Billo-Router regeln, wer wann wie worüber ins Netz geht. Bei IP’s die man nicht kennt, ist das ein grausames Unterfangen.

Jetzt gibt es zwei Möglichkeiten aus dem Dilemma herauszukommen.

  1. DHCP-V6 aufsetzen (hab ich noch nicht ausprobiert) und die IP’s statisch den Mac-Adressen im LAN zuordnen.
  2. Den Servern händisch statische IP’s verpassen.
  3. Mischbetrieb aus 2 und radvd

Habe mich erstmal für Variante 3 entschieden. Also jeden Server abgrasen und eine IP aus dem dfea-Netz eintragen, Default(-v6-)Route setzen und testen. Die Arbeitsplatzrechner bekommen die IP’s per radvd, die Server sind statisch verdrahtet. Fein, funktioniert.

Jetzt kommt der fieseste Teil, an dem ich zwei Stunden versenkt habe:

Das ganze ist bei Debian nämlich leider nicht Bootfest, da Linux ganz jeck auf Route-Advertisments ist, und sich dort auch eine IP „ziehen“, wenn sie schon statisch eine abbekommen haben. Hier helft eine Kernel-Einstellung in /etc/sysctl.conf:

net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.default.autoconf=0

Die alleine macht aber auch noch nicht glücklich, da die sysctls beim booten eingelesen werden sollen. Zu diesem Zwecke linkt man sich die /etc/init.d/procps in die runtimelevel-Dirs (/etc/rcX.d/). Hilft auch noch nicht, weil: Die Einstellungen greifen nur, wenn auch das ipv6-Kernel Modul schon geladen ist – sonst laufen die ins leere 🙁 Hierzu ipv6 in die /etc/modules eintragen. Anschliessend booten – et voila: Es läuft !

Jetzt fehlt eigentlich nur noch eins: Eine ordentliche Firewall mit Connection-Tracking. Gibts wohl demnächst mal einen Blogeintrag drüber. Soviel sei gesagt: Connectiontracking geht erst ab Kernel 2.6.26, redirect (bspw. für transparente Proxies) erst ab 2.6.36…

Somit wäre dieses Blog nun auch via ipv6 erreichbar !

Tagged with:
Apr 11

Das Kind hat doch derbe Defizite mit dem kleinen 1×1. Macht sich jetzt so richtig bemerkbar, weil im Unterricht Division mit REST durchgenommen wird. Nun habe ich allerdings wenig Lust, mir alle Nasenlang neue Aufgaben aus den Fingern zu saugen. Also mal flux ein Perl-Script geschrieben, welches die Ergebnisse gleich mitliefert. Auf Excel-Output hatte ich gerade keine Lust, sollte aber mit „Spreadsheet::WriteExcel“ (gibts beim CPAN Ihres Vertrauens) auch kein Thema sein.

Das folgende Script wirft also 60 Aufgaben mit 60 Ergebnissen aus. Wenn man den Output (Tab-getrennt) in Excel guttenbergt (CopyPaste), dann hat man auf dem „linken“ Blatt, bei einem 18er Font, die Aufgaben, und auf dem rechten Blatt die Ergebnisse. Die machen es dann etwas leichter, den Kram den der Nachwuchs da hingepinselt hat, zu kontrollieren.

#!/usr/bin/perl
my $i=100;
my @erg,@aufg;
my $sollaufgaben=60;
while ($aufgaben<$sollaufgaben) {
  $i++;
  my $a=int(rand($i)%100);
  my $b=int(rand($i)%10);
  $b=1 if int($b)==0;
  $a=1 if int($a)==0;
  if (int($a/$b)<12) {
    $aufgaben++;
    push @aufg,$aufgaben."\t".$a."\t:\t".$b;
    push @erg,int($a/$b)." R ".($a % $b);
  }
}

for (my $i=0;$i<int($sollaufgaben/2);$i++) {
  print $aufg[$i*2]."\t\t".$aufg[$i*2+1]."\t\t";
  print $erg[$i*2]."\t".$erg[$i*2+1]."\n";
}
									

Tagged with:
preload preload preload