Android Kontakte und Kalender ohne Google syncen mit Horde 4
Ich wollte meine persönlichen Daten nie Google geben und habe deswegen unter Android bisher auf das Syncen von Kalender und Adressbuch verzichtet. Als Notlösung habe ich regelmässige Backups mit My Backup Pro angefertigt. Schön war das allerdings nicht. Da ich inzwischen auch ein Android-Tablet besitze wurde syncen noch wichtiger. Zum Glück lässt sich das inzwischen komplett mit Open Source Software bewerkstelligen, falls die Android-Geräte "Microsoft Active Sync" unterstützen. Mit dieser Sync-Methode kann man seinen Androiden normalerweise an ein Exchange-Konto anbinden. Die kostenlose Groupware Horde bietet seit Version 4 allerdings auch einen kompatiblen ActiveSync-Server an. Damit steht der Android Synchronisation über mehrere Devices mit dem eigenen Server nichts mehr im Wege.
Grundvoraussetung ist ein eigener Linux-Server mit Apache und MySQL.
Zunächst muss Horde 4 installiert werden:
# Die Paketierung von Horde 4 läuft über PEAR apt-get install pear # PEAR auf den neuesten Stand bringen pear upgrade pear # Den Horde-Channel dem lokalen Pear bekannt machen pear channel-discover pear.horde.org # Horde Installationsverzeichnis konfigurieren pear install horde/horde_role pear run-scripts horde/horde_role # Hier wird nach einem Installationsverzeichnis für Horde 4 gefragt. # In meinem Beispiel ist es /var/www/horde4 # Horde installieren pear install -a -B horde/webmail # Horde Konfiguration umbenennen, um Horde zu aktivieren cd /var/www/horde4/config cp ./conf.php.dist ./conf.php # Dem Webserver Rechte auf alle Horde-Files geben chown -R www-data /var/www/horde4
Datenbank für Horde in MySQL anlegen:
Horde benötigt eine Datenbank in MySQL. In meinem Beispiel habe ich für Horde mit PHPMyAdmin den Benutzer "horde4" und die Datenbank "horde4" angelegt.
Horde über den Webbrowser konfigurieren:
Horde kann nun über den Webbrowser konfiguriert werden. Dazu öffnet man im Browser http://www.meinserver.de/horde4 . Da noch nicht konfiguriert wurde, welche Authentifizierung Horde nutzt, wird man direkt als Administrator der Installation eingeloggt.
Datenbank konfigurieren:
(Administration -> Konfiguration -> Horde -> Database)
Hier die Daten zur angelegten MySQL Datenbank eintragen:
Horde Authentifizierung konfigurieren:
Horde benötigt ein Backend um den Benutzernamen und das Passwort zu überprüfen. Horde bietet dafür viele verschiedene Möglichkeiten an. Der Einfachheit halber kann man hier das Password-File benutzen (/etc/passwd). Der User muss dann nur im lokalen System angelegt werden:
adduser horde_user
(Administration -> Konfiguration -> Horde -> Authentication)
Datenbanktabellen für Horde anlegen:
Horde konnte bisher die eigenen Datenbanktabellen in MySQL noch nicht anlegen, da wir ihm eben erst die MySQL-Benutzerdaten mitgeteilt haben. Um die Tabellen anzulegen besucht man die Hauptseite der Konfiguration und wählt "Alle DB-Schemata aktualisieren", bis das Ganze so aussieht:
(Administration -> Konfiguration)
Ab sofort sollte man sich in Horde mit dem Benutzer "horde_user" und dem beim adduser-Kommando gewählten Passwort einloggen können.
Apache konfigurieren
Damit Android an Horde syncen kann, muss noch ein Alias in die Apache-Konfiguration eingetragen werden:
#/etc/apache2/httpd.conf Alias /Microsoft-Server-ActiveSync /var/www/horde4/rpc.php
Das ist notwendig, da Active-Sync Clients automatisiert die URL /Microsoft-Server-ActiveSync aufrufen, wenn sie mit ihrem Server connecten. Horde händelt die Synchronisation allerdings über die Datei rpc.php
Danach muss Apache seine Konfiguration neu laden lassen:
/etc/init.d apache2 reload
Wenn alles geklappt hat, sollte man nun auf seinem Androiden Sync-Konten einrichten können:
Mit diesem Setup Synce ich erfolgreich zwischen Horde, einem Sony Ericsson Xperia Mini Pro und einem Samsung Galaxy Tab.
Fallstricke:
- Ich hatte zunächst mit doppelten Kontakten und Kalendereinträgen zu kämpfen. Am Besten exportiert man zunächst alle Kontakte und den Kalender aus dem Handy und importiert sie in Horde. Danach löscht man alle Daten auf dem Handy und lässt sie von Horde wieder in das angelegte Active-Sync-Konto auf dem handy schieben. Horde bietet viele verschiedene Möglichkeiten an Daten zu importieren. (Organisieren -> Kalender -> Import/Export) und (Organisieren -> Adressbuch -> Import/Export). Den Kalender bekommt man zum Beispiel aus Android gut mit der App "iCal Import/Export" heraus. Mein SONY bot für den Export der Kontakte selbst die Möglichkeit an, diese in ein VCard-File zu exportieren. Aber auch hier gibt es sicher eine geeignete Lösung bei Google Play.
- Die Horde Authentifizierung per /etc/passwd sollte wie oben beschrieben funktionieren. Ich habe sie allerdings nur der Einfachheit halber für dieses Howto gewählt und nicht getestet, da ich selbst Horde an meinem IMAP-Server authentifiziere.
- Als ich angefangen habe die Syncerei zu testen, funktionierte es zuerst nur mit meinem Tablet und nicht mit dem Handy. Nach 1 Stunde frickeln war der Fehler gefunden: Android synct nicht, wenn der interne Speicher zu voll ist. Nachdem ich ein paar Apps auf die SD-Karte verschoben hatte, ging es sofort.
Vertragskündigung bei Blau.de mit Rufnummernmitnahme
Ich war bisher bei BLAU als Mobilfunkanbieter, da es das günstigste Angebot ohne Vertragsbindung für Vieltelefonierer war. Ich habe für alle SMS, alle Gespräche in alle deutschen Netze und für Internet EUR 39,95 / Monat gezahlt.
Da es seit gestern einen neuen Kampfpreis bei Yourfone für EUR 24,90 ohne Vertragsbindung gibt, war es mal wieder an der Zeit zu wechseln. Zwar sind in dem Preis SMS nicht inklusive, aber da ich ohnehin kaum über 10 SMS im Monat komme, war auch das kein Hindernis.
Hätte ich meine Rufnummer nicht portieren wollen, hätte ich gar nichts tun müssen. Die SIM-Karte wird nach Ende des Aktivitätszeitraumes automatisch deaktiviert.
Da ich meine Handynummer jedoch mitnehmen wollte zum neuen Anbieter, war folgendes Vorgehen notwendig:
- Blau.de Hotline anrufen und um Zusendung des Formulares "Verzichtserklärung zur Rufnummernmitnahme" bitten.
- Formular ausfüllen und an BLAU faxen
- EUR 24,95 Mitnahmegbühr (bekommt man vom neuen Anbieter zurück) an BLAU überweisen
- Auf Bestätigung der Freigabe der eigenen Rufnummer von BLAU per E-Mail warten
- Beim neuen Anbieter mit Rufnummernmitnahme anmelden
Ich war sehr zufrieden mit BLAU, jedoch sind die EUR 15 Ersparnis / Monat ein Argument, dem ich mich nicht verschließen konnte 🙂 Ich hoffe der Service bei Yourfone ist gut, ansonsten ist die Auswahl ja zur Zeit sehr groß.
03.05.2012
Erste Ernüchterungen. Ich habe bisher weder eine Nachricht von BLAU, noch eine von Yourfone erhalten. Beim Anruf auf der Yourfone 0800er Hotline erfuhr ich, dass meine Portierung fehlgeschlagen sei. BLAU hat die Portierung abgelehnt, da nicht die gleichen Daten bei BLAU und Yourfone hinterlegt worden sind, was definitiv nicht korrekt ist. Hätte ich mich nicht persönlich gemeldet, wäre die Sache wohl im Sande verlaufen. Der Hotliner bat mich die Daten noch einmal zu überprüfen und die Portierung dann erneut anzustoßen. Nach Überprüfung ging dann leider der bekannte Hotline-Terror los. Bei einem erneuten Anruf auf der 0800er-Hotline wollte mir die Hotlinerin nicht bei meinem Problem helfen, da sie nur Neubestellungen aufnehmen könne. Für mein Problem sollte ich die 0900er Hotline anrufen. Sie wollte mir allerdings eine erneute Bestellung entlocken, die ich abgelehnt habe, da ich nicht mit zwei SIM-Karten zuhause sitzen wollte. Ich bin inzwischen sehr vorsichtig damit bei Telcos internes Verwaltungschaos zu generieren. Die sehr widerwillig angewählte 0900er Hotline war über mein Sipgate-VoiP-Festnetz nicht erreichbar.
Also habe ich erneut eine Mail an kundenbetreuung@yourfone.de und portierung@yourfone.de geschrieben und darum gebeten meine Portierung erneut zu überprüfen. Die Portierungs-Adresse wurde extra für Portierungsprobleme eingerichtet.
07.05.2012
Antwort von Yourfone, dass die Portierung erneut versucht wurde.
11.05.2012
Mail von Yourfone, dass die Portierung erfolgreich angestossen wurde und dass ich ab dem 14.05. über Yourfone geschaltet sein werde.
Versandbestätigung meiner SIM-Karte.
14.05.2012
Morgens funktioniert mein Handy nicht mehr. Meine BLAU-Karte darf sich nicht mehr einbuchen.
Im Briefkasten liegt meine neue Yourfone-SIM. Sie muss online oder telefonisch aktiviert werden. Ich wähle die Online-Aktivierung. Ca. 30 Minuten später ist meine Yourfone-SIM aktiv. Ich bekomme sofort Konfigurationsnachrichten für Daten und MMS. Ich bin online im (alten) neuen Netz. Geschafft!
Ein erster Test der Internetverbindung war erschreckend. Ein Newsartikel benötigte ca. 30 Sekunden um zu laden. Glücklicherweise lag das nicht an Yourfone sondern an meinem Android-Handy. Durch die Konfigurationsnachricht von Yourfone wurde auch ein WAP-Zugangspunkt im Handy hinterlegt, den mein Android als default genommen hatte. Nach Entfernen des WAP-Zugangspunktes hatte ich mit dem Internet-Profil eine (gefühlt) bessere Performance als mit BLAU.
yourfone APN Einstellungen:
Internet über GPRS/UMTS
APN: internet.eplus.de
Username: eplus
Passwort: internet
Authentifizierungstyp: PAP
Erster DNS: 212.023.097.002
Zweiter DNS: 212.023.097.003
WAP über GPRS/UMTS
APN: wap.eplus.de
Username: mms
Passwort: wap
Gateway: 212.23.97.9
Startseite: http://wap.eplus.de
Authentifizierungstyp: aus
MMS
APN: mms.eplus.de
Username: mms
Passwort: eplus
Authentifizierungstyp: aus
MMSC URL: http://mms/eplus
Gateway: 212.23.97.153
WAP 1.x proxy port: 9201
WAP 2.0 proxy port: 5080
Max. Nachrichtengröße: 300 kb
Beliebige Videodateien mit ffmpeg für die PS3 in H264 konvertieren
Nach viel Sucherei und Ausprobiererei habe ich jetzt endlich herausgefunden, wie ich in möglichst guter Qualität und möglichst kleiner Dateigröße Dateien für den Mediaplayer der PS3 mit ffmpeg konvertieren kann. Die Videodateien jedes beliebigen Formates das ffmpeg unterstützt kommen in das konfigurierbare INDIR. Die konvertierten, auf der PS3 abspielbaren, Dateien landen in OUTDIR.
#!/bin/bash
# Eingangs und Ausgangsverzeichnis konfigurieren
INDIR=/home/user/vid_in
OUTDIR=/home/user/vid_out
# Eventuellen Whitespace aus den Dateinamen entfernen
find $INDIR -name "* *" -type f | rename 's/ /_/g'
for f in $(ls $INDIR)
do
# Mit ffmpeg in H264 und AAC konvertieren (Achtung, der ffmpeg-Befehl muss in EINE Zeile)
ffmpeg -y -i $INDIR/$f -vcodec libx264 -level 41 -crf 24 -threads 2 -acodec libfaac -ab 128k -ac 2 -ar 48000 $OUTDIR/$f.mp4
# Ende ffmpeg Befehl
# Die folgende Zeile kann auskommentiert werden, wenn die Originaldateien
# gelöscht werden sollen.
#rm $INDIR/$f
done
Das in den Ubuntu-Repos vorhandene ffmpeg unterstützt leider kein H264, man muss ffmpeg selbst kompilieren um in den Genuß zu kommen. Das geht mit diesem Script hier ganz leicht:
http://pasindudps.blogspot.de/2011/10/install-ffmpeg-in-ubuntu-1110-oneiric.html
Vorwahlbot – Einfach die Vorwahl einer Rufnummer herausfinden
Als Abfallprodukt eines Projektes von mir ist Vorwahlbot entstanden. Er findet heraus zu welchem Orts- oder Mobilfunknetz eine beliebige Rufnummer gehört (keine Portierungsinfos). Wenn Vorwahl und Rufnummer nur ohne Trennzeichen vorliegen, ist es oft schwierig die Vorwahl manuell herauszufinden, da Ortsvorwahlen in Deutschland zwischen 3 und 6 Stellen haben können. Vorwalbot erwartet als Eingabe eine Vorwahl oder eine komplette Rufnummer und wirft im besten Falle das richtige Netz raus.
Vorwahlbot
Out of the box Gigabit PCI Express Netzwerkkarte für Ubuntu und Debian
no images were found
Nach Problemen mit einer Onboard-Netzwerkkarte habe ich problemlos funktionierenden aktuellen Ersatz gesucht und bin auf folgende Karte gestossen:
Intel EXPI9301CTBLK PRO1000 Netzwerkkarte CT PCIex bulk
Sie funktioniert direkt Out of the Box unter Ubuntu und Debian mit aktuellem Kernel und dem Kernelmodul e1000e.
Ins PXE-Setup gelangt man beim booten des Rechners durch drücken von CTRL-S.
ww-ww-13:05:10 ~ -> uname -a Linux ww 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:44:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
ww-ww-13:05:41 ~ -> lspci | grep Intel 02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
ww-ww-13:05:48 ~ -> dmesg | grep Intel [ 0.000000] Intel GenuineIntel [ 1.426119] e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2 [ 1.426121] e1000e: Copyright(c) 1999 - 2011 Intel Corporation. [ 1.543197] e1000e 0000:02:00.0: eth1: Intel(R) PRO/1000 Network Connection
ww-root-13:15:13 /home/ww -> ethtool eth1 Settings for eth1: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: off Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000001 (1) drv Link detected: yes
ww-root-13:17:30 /home/ww -> ethtool -i eth1 driver: e1000e version: 1.3.10-k2 firmware-version: 1.8-0 bus-info: 0000:02:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes
Den Firexfox-Cache auf die Ramdisk auslagern unter Ubuntu
Um den Firefox ein wenig zu beschleunigen kann man den Cache auf die RAM-Disk auslagern.
Unter Ubuntu ist diese Standardmässig schon unter /dev/shm vorhanden und kann direkt benutzt werden. Sie wird je nach verfügbaren RAM im Rechner automatisch angelegt.
box-root-16:32:35 / -> df -h /dev/shm Dateisystem Größe Benut Verf Ben%% Eingehängt auf none 7,9G 11M 7,9G 1% /run/shm
Man muss Firefox lediglich so konfigurieren, dass /dev/shm als Cache-Verzeichnis genutzt wird. Leider ist dies nicht mehr über die grafischen Einstellungen möglich, man muss selbst Hand anlegen. Dazu öffnet man Firefox und gibt in der Adressleiste about:config ein.
Mit einem Rechtsklick legt man im Konfigurationsinterface einen neuen String-Wert mit dem Namen browser.cache.disk.parent_directory an und gibt diesem den Wert /dev/shm.
Ab sofort speichert Firefox auf der RAM-Disk zwischen. Vor- und Zurückblättern im Browser wird einen Tick schneller.
Je nach Betrachtungsweise ist der Vorteil oder Nachteil an dieser Einstellung, dass der Cache verloren geht, wenn man den Rechner ausschaltet, da die zwischengespeicherten Webseiten und Bilder nur noch im RAM laden und nicht mehr auf der Platte.
Online mit Alice DSL unter Debian via pppd ohne Alice Router mit eigenem DSL-Modem
Ich habe mich auf das Wagnis Alice eingelassen, trotz sehr schlechter Forenbeiträge im ganzen Web hat mich der zur Zeit extrem günstige Preis gelockt.
Leider vermietet Alice zwangsweise seine kombinierte Anschlußbox mit Router, WLAN und vorkonfiguriertem VoIP mit. Das mag für die meisten User in Ordnung sein, ich habe meinen Server lieber direkt als Firewall und Router an der Leitung.
Falls man Alice auch zum telefonieren benutzen möchte benötigt man leider zwingend die Alice-Box, da hier die Telefonie Zugangsdaten versteckt von Alice hinterlegt sind. Ohne sie kann man nicht telefonieren, die Hotline nennt diese bei Nachfrage angeblich nicht.
Da ich die Alice-Telefonie zum Glück nicht brauche und die Leitung nur für Internet benutzen will, stand meinem gewünschten Setup nichts mehr im Wege, ausser ein wenig pppd-Frickelei.
Nach Alice-Angabe muss man die Leitung zunächst "aktivieren". Dafür liegt dem Modem eine CD bei, die mit einem (verbuggten) Assistenten durch die Inbetriebnahme führt. Ich vermute, dass dieser Schritt nicht wirklich nötig ist, aber ich habe ihn zur Sicherheit ausgeführt.
Dafür habe ich ein Windows-Notebook an die original Alice-Box geklemmt und die "Aktivierung" durchgeführt.
Danach benötigt man die Alice-Box nicht mehr.
Ich habe mein altes Congstar-Box DSL-Modem ohne Splitter an die Leitung gehängt und per Ethernet mit meinem Server verbunden.
Danach müssen nur noch ein paar Configdateien angepasst werden:
#/etc/ppp/peers/alice # Interface zum DSL-Modem auswählen und MTU setzen pty "pppoe -I eth1 -m 1452" connect /bin/true ipcp-accept-remote ipcp-accept-local usepeerdns noipdefault defaultroute #Hier eigenen Usernamen eintragen user "0123456789@alice-dsl.de" hide-password noaccomp nopcomp novj novjccomp nobsdcomp nodeflate noccp nocrtscts local noauth lcp-echo-interval 10 lcp-echo-failure 3 lock # Die beiden Nachfolgenden Optionen sind nützlich zum Debuggen #debug #nodetach
#/etc/ppp/pap-secrets "0123456789@alice-dsl.de" * "passwort" *
Danach ist mit pon alice eine Anwahl möglich
gbn-root-21:40:15 /etc/ppp -> pon alice
Die Konfig funktioniert gut und ist ganz dreist geklaut von http://www.alice-wiki.de/Debian Dort findet man auch Erklärungen zu allen Optionen und eine Menge weitere gute Infos über die DSL-Einwahl im Allgemeinen und bei Alice im Besondern.
Online per UMTS mit Surfstick unter Debian mit wvdial und O2 Mobile Flat
Da mein neuer DSL-Anschluss erst in einigen Wochen geschaltet wird, habe ich bei Alice die Option "Quickstart" gewählt. Hier erhält man eine SIM-Karte, mit der man 3 Monate lang kostenlos surfen kann, als Überbrückung, bis der DSL-Anschluss geschaltet wurde.
Natürlich wollte ich die Internetverbindung nicht über einen Client herstellen, sondern wie gewohnt über meinen Homeserver, der für das ganze Heimnetz als Router fungiert.
Die größten Probleme hatte ich mit der Alice Hotline. Mit der SIMkarte kam eine Kurzanleitung, wie man diese über das Alice-Portal aktivieren könne. Leider hat das Portal weder in Firefox, Chrome oder Opera richtig funktioniert. Ich bin nicht bis zur Aktivierung der SIMkarte vorgedrungen.
Also leider Anrufe auf der 01805 Hotline. Sehr ärgerlich für 42ct./Min.
Über die Hotline war die Akivierung der Karte zum Glück schnell erledigt, leider konnte man mir dort zunächst nicht den notwendigen APN für die Konfiguration von wvdial nennen. Ich wollte hier sicher gehen, da ich etwas Angst vor exorbitanten Rechnungen hatte bei falscher Konfiguration des Wertes. Hier konnte mir die Technik zum Glück weiterhelfen. Für die Alice / O2 Quickstart Mobile Internet Flat lautet der APN nach Angaben der Hotline "internet.partner1". Bei der Vergabe des Namens war wohl niemand vom Marketing beteiligt 😉
Als nächsten Schritt habe ich die SIMkarte in ein Handy eingelegt um auf die Aktivierung zu warten und diese mitzubekommen. Das ging recht schnell, nach ca. 30 Minuten war meine SIM bereits aktiv und konnte sich ins Netz einbuchen. Erstaunlich schnell, da die Aktivierung von Alice zunächst zu O2 propagiert wird. Um das Handy zu zwingen sich neu ins Netz einzubuchen, kann man es aus- und wieder einschalten. Ich habe nun mit dem Handy noch die PIN-Abfrage der SIM deaktiviert, da ich vor einiger Zeit schon einmal üble Probleme mit wvdial und einer PIN hatte.
Der Rest funktionierte erstaunlich gut.
Ich habe die SIM in meinen Huawei Surfstick (T-Mobile Surfstick III)
Bus 001 Device 004: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA Modem / E270 HSDPA/HSUPA Modem
eingelegt. Nach dem Einstecken in einen USB-Port stellt Debian mit einem aktuellen Kernel das Device /dev/ttyUSB0 zur Verfügung.
Dieses kann man mit wvdial ansprechen
#/etc/wvdial.conf [Dialer Defaults] Init1 = ATZ Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 Init3 = AT+CGDCONT=1,"IP","internet.partner1" Phone = *99***1# Password = blank Username = blank New PPPD = yes Modem = /dev/ttyUSB0 Baud = 460800 Modem Type = USB Modem Auto Reconnect = on
Danach kann mit einem "wvdial" die Verbindung hergestellt werden:
gbn-root-00:19:27 ~ -> wvdial --> WvDial: Internet dialer version 1.60 --> Cannot get information for serial port. --> Initializing modem. --> Sending: ATZ ATZ OK --> Sending: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 OK --> Sending: AT+CGDCONT=1,"IP","internet.partner1" AT+CGDCONT=1,"IP","internet.partner1" OK --> Modem initialized. --> Sending: ATDT*99***1# --> Waiting for carrier. ATDT*99***1# CONNECT --> Carrier detected. Waiting for prompt. --> Don't know what to do! Starting pppd and hoping for the best. --> Starting pppd at Sun Jan 29 00:19:58 2012 --> Pid of pppd: 3749 --> Using interface ppp0 --> pppd: ��� ��� ȧ� --> pppd: ��� ��� ȧ� --> pppd: ��� ��� ȧ� --> pppd: ��� ��� ȧ� --> pppd: ��� ��� ȧ� --> pppd: ��� ��� ȧ� --> local IP address 10.43.145.228 --> pppd: ��� ��� ȧ� --> remote IP address 10.64.64.64 --> pppd: ��� ��� ȧ� --> primary DNS address 193.189.244.225 --> pppd: ��� ��� ȧ� --> secondary DNS address 193.189.244.206 --> pppd: ��� ��� ȧ�
Danach steht über die Luftschnittstelle das Internet an Device PPP0 zur Verfügung, das man nun für Routing und Firewallregeln benutzen kann.
Der Downstream ist im Zentrum von Düsseldorf ganz in Ordnung, der Upstream lässt allerdings SEHR zu wünschen übrig:
Download-Geschwindigkeit: 2.082 kbit/s (260 kByte/s) Upload-Geschwindigkeit: 71 kbit/s (9 kByte/s)
Aber... Einem geschenkten Gaul schaut man nicht ins Maul. Bezahlen würde ich für diese Performance allerdings nicht.
Nachtrag
Leider ist die Verbindung nicht stabil. Nach weniger als einer Stunde fliessen keine Daten mehr über PPP0, wvdial bekommt davon leider nichts mit und denkt die Verbindung sei noch aktiv, wählt also auch nicht selbstständig neu ein. Dieses Problem zu debuggen war mir zu kompliziert, da diese Notlösung ohnehin nur einige Wochen bis zur Schaltung des DSLers funktionieren muss. Das folgende kleine Skript überprüft ob die Verbindung noch steht. Falls nicht, wird wvdial gekillt und neu gestartet.
#!/bin/bash ping -c1 www.google.de > /dev/null if [ $? -ne 0 ]; then killall wvdial echo `date` >> /var/log/connection_lost.log wvdial & fi
Dieses Skript rufe ich automatisch über einen Cronjob auf und bin jetzt always on:
#/etc/crontab # REDIAL CRAPPY O2 line * * * * * root /root/scripts/redial_ppp
Fallstricke:
- PIN-Schutz der SIM nicht deaktiviert
- Die Verbindung über Mobilfunkprovider ist leider geNATtet. Der eigene Server ist von Außen nicht direkt erreichbar. Serverdienste können nur schwierig angeboten werden.
Online Melderegisterauskunft in Düsseldorf macht schlechten Eindruck
Mir war nicht ganz klar, welche persönlichen Daten das Einwohnermeldeamt an wen weitergeben darf. Ich bin nach etwas Recherche auf diese Aktion der PIRATEN gestoßen, die dazu auffordern, der Weitergabe der eigenen Daten bei den Meldeämtern zu widersprechen. Viele Meldeämter geben die Daten nämlich inzwischen jedem! der zahlt. Dem kann man nur durch einen Widerspruch entgehen.
Daten von den Meldeämtern werden weitergegeben an:
Staatliche Behörden, bei berechtigtem Interesse im Rahmen der Amtshilfe
Also z.B. Polizei, Staatsanwaltschaft, statistische Ämter, etc.
die GEZ
Die Brüder kennen wir ja schon zur Genüge.
Parteien, Wählergruppen und anderen Trägern von Wahlvorschlägen im Zusammenhang mit Parlaments- und Kommunalwahlen; § 35 Abs.1 MG NRW
Um die hübsche Hochglanz-Wahlwerbung zu erhalten.
an Antragsteller und Parteien im Zusammenhang mit Volksbegehren und Volksentscheiden sowie mit Bürgerentscheiden; § 35 Abs.2 MG NRW
Um Hochglanz-Entscheidungshilfen bei den häufigen Volksabstimmungen zu erhalten.
im Wege des automatisierten Abrufs über das Internet; § 34 Abs.1b MG NRW
Das ist der Punkt, der mir bisher nicht bekannt war. Über ein Internetportal kann
jeder, der einige Kenndaten einer Person kennt automatisiert über das Internet
Meldeauskünfte einholen. Die Abfrage kostet zur Zeit 4 Euro pro Datensatz in Düsseldorf.
Das Meldegesetz NRW sagt an dieser Stelle:
https://recht.nrw.de/lmi/owa/br_bes_text?anw_nr=2&gld_nr=2&ugl_nr=210&bes_id=4655&aufgehoben=N&menu=1&sg= § 34 Abs.1b MG NRW (1b) Soll der Abruf über das Internet ermöglicht werden, ist sicherzustellen, dass das Antragsverfahren und die Auskunftserteilung in verschlüsselter Form erfolgen. Die Eröffnung des Zugangs ist öffentlich bekannt zu machen. Ein Abruf ist nicht zulässig, wenn der Betroffene dieser Form der Auskunftserteilung widersprochen hat. Die Meldebehörde hat spätestens einen Monat vor der Eröffnung des Internetzugangs durch öffentliche Bekanntmachung auf das Widerspruchsrecht hinzuweisen. Im Übrigen gilt § 35 Abs. 6 Satz 2 entsprechend.
Ein Widerspruch gegen die Weitergabe der Daten ist durch das Ausfüllen eines Formulars möglich. Für Düsseldorf findet sich dieses hier: https://formulare.duesseldorf.de/forms/frm/7PRPfAZH5gQA8Ja8AkNGaH1rNpDcHR3 Dieses kann kostenlos in Bürgerämtern abgegeben werden. Danach ist kein Onlinezugriff auf die eigenen Daten mehr möglich. Anscheinend werden die Datenzugriffe regional von den jeweiligen Städten und Kreisen organisiert.
Auf meine Nachfrage bei der (sehr freundlichen) Sachbearbeiterin im Bürgerbüro hin, konnte
man mir leider nicht die URL des Abfrageportals mitteilen. Eine kurze Recherche hat mich dann aber schnell auf diese Seite der Stadt Düsseldorf geführt:
https://www.duesseldorf.de/emra/emra.jsp?stadt=D%FCsseldorf&art=Stadt
Das Portal machte technisch gelinde gesagt einen sehr zweifelhaften Eindruck.
Zunächst einmal scheint es keinerlei Captcha oder ähnliches zu geben. Eine Massenabfrage scheint also mit entsprechenden Skripten möglich zu sein.
Außerdem verabschiedete sich die Webapplikation bei meiner Testabfrage mit folgender Tomcat Fehlermeldung, da ich keine Cookies aktiviert hatte:
Dies lies mich dann doch zunehmend an der Professionalität einer Anwendung zweifeln, die Zugriff auf die Daten aller Bürger der Stadt bietet. Ein Skript sollte nicht abstürzen, wenn Voraussetzungen am Rechner des Benutzers nicht gegeben sind (in diesem Fall mein fehlender Cookie). Skript-Fehlermeldungen von Webservern, die sich im produktiven Einsatz befinden nicht zu deaktivieren ist fahrlässig, da sie viel über die verwendete Systemumgebung verraten können. Zumal man bei jsp (wie im Screenshot oben) je nach Konfiguration des Servers auch noch Kommentare des Programmierers und Quelltextschnippsel dazu bekommt. Hier wurde geschlampt. An einer Schnittstelle zu persönlichen Daten sollte das nicht passieren.
Aufhorchen ließ mich auch die benutze Tomcat Version, welche in der Fehlermeldung auch unten auftaucht. (Apache Tomcat/6.0.24) Dies ist eine ältere Version des Webservers vom 21.01.2010. Aktuell ist die Version 6.0.33. Der Melderegister-Server wurde 4 Versionen lang nicht aktualisiert. Schaut man sich die Sicherheitslücken an, die in diesen letzten Versionen behoben wurden, wird es langsam ungemütlich. Der Server befindet sich offensichtlich nicht im bestmöglichen Zustand:
http://tomcat.apache.org/security-6.html Fixed in Apache Tomcat 6.0.33 released 18 Aug 2011 Moderate: Multiple weaknesses in HTTP DIGEST authentication CVE-2011-1184 The implementation of HTTP DIGEST authentication was discovered to have several weaknesses: replay attacks were permitted server nonces were not checked client nonce counts were not checked qop values were not checked realm values were not checked the server secret was hard-coded to a known string The result of these weaknesses is that DIGEST authentication was only as secure as BASIC authentication. This was fixed in revision 1158180. This was identified by the Tomcat security team on 16 March 2011 and made public on 26 September 2011. Affects: 6.0.0-6.0.32 Low: Information disclosure CVE-2011-2204 When using the MemoryUserDatabase (based on tomcat-users.xml) and creating users via JMX, an exception during the user creation process may trigger an error message in the JMX client that includes the user's password. This error message is also written to the Tomcat logs. User passwords are visible to administrators with JMX access and/or administrators with read access to the tomcat-users.xml file. Users that do not have these permissions but are able to read log files may be able to discover a user's password. This was fixed in revision 1140071. This was identified by Polina Genova on 14 June 2011 and made public on 27 June 2011. Affects: 6.0.0-6.0.32 Low: Information disclosure CVE-2011-2526 Tomcat provides support for sendfile with the HTTP NIO and HTTP APR connectors. sendfile is used automatically for content served via the DefaultServlet and deployed web applications may use it directly via setting request attributes. These request attributes were not validated. When running under a security manager, this lack of validation allowed a malicious web application to do one or more of the following that would normally be prevented by a security manager: return files to users that the security manager should make inaccessible terminate (via a crash) the JVM Additionally, these vulnerabilities only occur when all of the following are true: untrusted web applications are being used the SecurityManager is used to limit the untrusted web applications the HTTP NIO or HTTP APR connector is used sendfile is enabled for the connector (this is the default) This was fixed in revision 1146703. This was identified by the Tomcat security team on 7 July 2011 and made public on 13 July 2011. Affects: 6.0.0-6.0.32 Important: Information disclosure CVE-2011-2729 Due to a bug in the capabilities code, jsvc (the service wrapper for Linux that is part of the Commons Daemon project) does not drop capabilities allowing the application to access files and directories owned by superuser. This vulnerability only occurs when all of the following are true: Tomcat is running on a Linux operating system jsvc was compiled with libcap -user parameter is used Affected Tomcat versions shipped with source files for jsvc that included this vulnerability. This was fixed in revision 1153824. This was identified by Wilfried Weissmann on 20 July 2011 and made public on 12 August 2011. Affects: 6.0.30-6.0.32 Fixed in Apache Tomcat 6.0.32 released 03 Feb 2011 Note: The issue below was fixed in Apache Tomcat 6.0.31 but the release vote for the 6.0.31 release candidate did not pass. Therefore, although users must download 6.0.32 to obtain a version that includes a fix for this issue, version 6.0.31 is not included in the list of affected versions. Important: Remote Denial Of Service CVE-2011-0534 The NIO connector expands its buffer endlessly during request line processing. That behaviour can be used for a denial of service attack using a carefully crafted request. This was fixed in revision 1066313. This was identified by the Tomcat security team on 27 Jan 2011 and made public on 5 Feb 2011. Affects: 6.0.0-6.0.30 Fixed in Apache Tomcat 6.0.30 released 13 Jan 2011 Low: Cross-site scripting CVE-2011-0013 The HTML Manager interface displayed web application provided data, such as display names, without filtering. A malicious web application could trigger script execution by an administrative user when viewing the manager pages. This was fixed in revision 1057270. This was identified by the Tomcat security team on 12 Nov 2010 and made public on 5 Feb 2011. Affects: 6.0.0-6.0.29 Moderate: Cross-site scripting CVE-2010-4172 The Manager application used the user provided parameters sort and orderBy directly without filtering thereby permitting cross-site scripting. This was fixed in revision 1037779. This was first reported to the Tomcat security team on 15 Nov 2010 and made public on 22 Nov 2010. Affects: 6.0.12-6.0.29 Low: SecurityManager file permission bypass CVE-2010-3718 When running under a SecurityManager, access to the file system is limited but web applications are granted read/write permissions to the work directory. This directory is used for a variety of temporary files such as the intermediate files generated when compiling JSPs to Servlets. The location of the work directory is specified by a ServletContect attribute that is meant to be read-only to web applications. However, due to a coding error, the read-only setting was not applied. Therefore, a malicious web application may modify the attribute before Tomcat applies the file permissions. This can be used to grant read/write permissions to any area on the file system which a malicious web application may then take advantage of. This vulnerability is only applicable when hosting web applications from untrusted sources such as shared hosting environments. This was fixed in revision 1022560. This was discovered by the Tomcat security team on 12 Oct 2010 and made public on 5 Feb 2011. Affects: 6.0.0-6.0.29 Fixed in Apache Tomcat 6.0.28 released 9 Jul 2010 Important: Remote Denial Of Service and Information Disclosure Vulnerability CVE-2010-2227 Several flaws in the handling of the 'Transfer-Encoding' header were found that prevented the recycling of a buffer. A remote attacker could trigger this flaw which would cause subsequent requests to fail and/or information to leak between requests. This flaw is mitigated if Tomcat is behind a reverse proxy (such as Apache httpd 2.2) as the proxy should reject the invalid transfer encoding header. This was fixed in revision 958977. This was first reported to the Tomcat security team on 14 Jun 2010 and made public on 9 Jul 2010. Affects: 6.0.0-6.0.27 Note: The issue below was fixed in Apache Tomcat 6.0.27 but the release vote for the 6.0.27 release candidate did not pass. Therefore, although users must download 6.0.28 to obtain a version that includes a fix for this issue, version 6.0.27 is not included in the list of affected versions. Low: Information disclosure in authentication headers CVE-2010-1157 The WWW-Authenticate HTTP header for BASIC and DIGEST authentication includes a realm name. If aelement is specified for the application in web.xml it will be used. However, a is not specified then Tomcat will generate realm name using the code snippet request.getServerName() + ":" + request.getServerPort(). In some circumstances this can expose the local host name or IP address of the machine running Tomcat. This was fixed in revision 936540. This was first reported to the Tomcat security team on 31 Dec 2009 and made public on 21 Apr 2010. Affects: 6.0.0-6.0.26
Das alles wirkt sehr unsicher und steht für mich exemplarisch für den gelebten Datenschutzwillen des Staates. Die Daten werden verkauft und es ist kaum jemandem bekannt. Die technische Umsetzung lässt sehr zu Wünschen übrig und läuft über technische Systeme, die bekanntermaßen fehlerhaft sind und dringend aktualisiert werden müssten. Auch scheint eine Endkontrolle und qualifizierte Abnahme bei IT-Projekten (die bekanntermaßen für den Staat meistens recht teuer sind) nicht immer stattzufinden.
Als einzigen Pluspunkt kann ich vermerken, dass es kein zentrales bundesweites Portal mit Online-Fernabfrage für alle Meldedaten zu geben scheint. Dann wären wir sicherlich nicht mehr weit entfernt von dem, was den Israelis vor Kurzem geschehen ist.
Ich bin froh, dass ich mich ausgetragen habe, aber ob jemand mit etwas krimineller Energie und technischem Verständnis nicht trotzdem (kostenlos) an meine Daten (und alle anderen) kommen könnte, halte ich zumindest für fragwürdig. Auf den ersten Blick wirkt das Düsseldorfer System nicht abgehärtet gegen Angriffe.
Tweet Neglector. A small PHP script to delete old Tweets from Twitter
Tweet Neglector automates the process of deleting old tweets from your Twitter account. Basicly it provides an "expire" functionality for your tweets. It is useful for people who want to use Twitter but don't want a history of their tweets to stay online for decades.
HISTORY: Nov 20 2011 | Version 0.1 Initial release. Deletes Tweets Dez 28 2011 | Version 0.2 Small bug fixes. Now deletes Retweets as well. Nov 05 2012 | Version 0.3 Twitter changed it's API and TweetNeglector was affected by it. With a quick and dirty hack I made it work again. Much of the code is obsolete now and TN should be rewritten, but it's working fine. Jul 26 2013 | Version 0.4 Twitter changed it's API once again. This is a complete rewrite of Tweet Neglector. It can now remove up to 3200 old Tweets and Retweets per run. Aug 1 2013 | Version 0.5 Small cosmetic fix.
Tweet Neglector uses the Twitter API to delete all your tweets that were posted before a given number of days from now. This way you could configure the script to delete all tweets that are older than a week or a month for example. The script should be automatically run from a cronjob or another automation mechanism on a regular base.
This script can't protect you from external Tweet archives like the Library of Congress. Also it is unknown if deleted Tweets are still archived by Twitter (I bet they are). It can clean up your timeline though, so people can't see your old tweets on Twitter anymore. So (as always) think before tweeting.
Tweet Neglector uses PHP as scripting language and bundles the Twitter-API-PHP library by James Mallison for API-Access.
Installation
- Unzip the archive into a directory of your choice. - Register your Twitter API-Keys at https://dev.twitter.com/apps - Edit the configuration of the script to suit your needs in tweetneglector.php - Run the script manually from browser, console or automatically by cronjob /usr/bin/php /var/www/tweetneglector/tweetneglector.php
Download Tweet Neglector 0.5 here
Howto: Quick and dirty DHCP-Server und DNS-Cache mit dnsmasq unter Debian
DHCP im LAN ist praktisch. Man muss nicht mehr die Netzwerkkonfiguration jedes einzelnen Rechners im Netzwerk an den Clients selbst verwalten, sondern hat alles schön zentral auf dem Server. Durch DNS-Caching sparen die Clients ein wenig Zeit beim Auflösen von Hostnames, da die Anfragen für bekannte Hostnames vom lokalen Cache übernommen werden können und nicht mehr an einen Server im Internet gestellt werden müssen.
Ein kleiner DHCP-Server ist mit dnsmasq sehr schnell eingerichtet.
# dnsmasq installieren apt-get install dnsmasq
Die Konfiguration findet zentral in der Datei /etc/dnsmasq.conf statt. Man sollte sich vor den geballten Konfigurationsoptionen in der Datei nicht abschrecken lassen. So gut wie alles dient nur als Beispiel und ist per default auskommentiert. Eine sehr kurze Konfig reicht bereits für ein funktionierendes Setup:
DHCP
# DHCP netmask # Clients bekommen 255.255.255.0 als Netmask dhcp-option=1,255.255.255.0 # default gateway # Clients bekommen als Gateway 192.168.1.251 dhcp-option=3,192.168.1.251 # dns # Clients bekommen als Nameserver 192.168.1.4 # Falls man dnsmasq auch als DNS-Cache benutzen möchte, sollte dies die # IP des Servers sein, auf dem dnsmasq läuft dhcp-option=6,192.168.1.4 # Für bekannte Rechner immer dieselbe IP anhand der MAC-Adresse vergeben: # Hier bekommt der Rechner mit der MAC 00:11:22:33:44:55 die IP 192,168.1.1 für 12 Stunden dhcp-host=00:11:22:33:44:55,lobby,192.168.1.1,12h dhcp-host=00:11:22:33:44:66,lobby2,192.168.1.2,12h # Alle Rechner, die nicht per MAC identifiziert werden können, erhalten IPs # aus dem Pool 192.168.1.120 bis 150 dhcp-range=192.168.1.120,192.168.1.150,12h
DNS
Die DNS-Funktionalität von dnsmasq benötigt eigentlich keine Konfiguration.
dnsmasq besorgt sich seine Nameserver aus /etc/resolv.conf . Hier sollten die
bekannten Nameserver des Providers eingetragen werden und evtl noch als Fallback
die 8.8.8.8 für Googles DNS-Server.
Weitere Hostnames, die im lokalen Netz gelten sollen, können dnsmasq in der Datei
/etc/hosts bekannt gemacht werden. Hier eingetragene Hostnames stehen allen Rechnern
im LAN zur Verfügung.
Fallstricke
dnsmasq muss nach Konfigänderungen seine Konfigurationsdateien neu einlesen
/etc/init.d/dnsmasq restart
Falls Clients noch eine Lease vom alten DHCP-Server haben, kann man sie manuell dazu bringen, einen neuen DHCP-request zu starten.
#Linux dhclient eth0 #Windows ipconfig /RELEASE ipconfig /RENEW
Dringend muss man darauf achten, den bisher genutzen DHCP-Server (meistens im Router zum Internet) zu deaktivieren. 2 DHCP-Server im LAN können viel Chaos generieren.