Also Grundlage für diese Einrichtung ist, dass ihr Euch einwählen könnt. Das habe ich schon vor ein paar Monaten hier im Blog dokumentiert: http://claus.freakempire.de/2007/04/15/t-home-iptv-ohne-speedport-unter-linux-vdsl/ – Eventuell werde ich demnächst auch mein Wiki dazu updaten. Wenn Ihr online seid, braucht ihr jetzt nur ein paar kleine Zeilen ausführen und eine Datei vom IGMP Proxy bearbeiten:

# vconfig add eth1 8
# dhclient3 eth1.8

In der /etc/igmpproxy.conf nun noch eine Zeile geändert:

#phyint ppp0 upstream  ratelimit 0  threshold 1 (Diese Zeile wird nicht mehr benötigt)
phyint eth1.8 upstream  ratelimit 0  threshold 1

Den IGMP Proxy neu gestartet und schon funktioniert es wieder. Das ganze kann man nun noch unter /etc/network/interfaces (Debian) unterbringen, oder in irgendwelchen ip-up.d Skripts unterbringen. Wenn wer noch Anregungen oder Verbesserungswünsche hat, bitte melden. Ach noch was: Laut Telekom sollte das Fernsehen jetzt nicht mehr getrennt werden. Deshalb glaube ich, dass meine Lösung suboptimal ist, da beim Trennen vom ppp/pppoe auch die eth1.8 Schnittstelle vom Saft abgetrennt wird. Die IP bleibt zwar nach Reconnect erhalten, aber das Fernsehbild ist für wenige Sekunden aus. Das lässt mich vermuten, dass es noch eine bessere Lösung gibt.

Der Vorteil für den Kunden bei dieser Umstellung ist mir unklar. Außer evtl., dass eine Trennung das IPTV nicht mehr beeinflussen soll. Bisher habe ich aber keine anderen Beobachtungen gemacht. Für Statistiker ist es nett, weil IPTV Traffic und Internet Traffic jetzt getrennt ist. Bei Fragen im T-Home Forum vorbei schauen: http://thome.freakempire.de

[1] http://claus.freakempire.de/2009/02/16/t-home-iptv-vlan-8-bei-t-online/

Anleitung folgt in den nächsten 16 Stunden. Muss nun eine Klausur schreiben

“Ausnahmsweise” wieder was aus der Technik-Schublade Folgendes mag eventuell als völlig unsinnig erscheinen, aber dennoch hat mich gestern ein Blitz getroffen und ich wollte das unbedingt umsetzen. Ich hoffe es gibt in Zukunft einen wirklichen Jabber Bouncer. Denn ich finde folgendes Problem sollte schon Mal bedacht werden:

Jabber zeichnet sich dadurch aus, dass es ein offenes Protokoll ist und dass man Jabber auch von mehreren PCs gleichzeitig nutzen kann. Außerdem werden Transporte zu MSN,ICQ und AIM unterstützt. Man bekommt die Nachrichten immer zu dem Rechner gesendet, wo man sich als letztes eingeloggt oder aktiv war oder man definiert Prioritäten bei den Clients und anhand dieser Zahlenwerte wird die Nachricht zugestellt. So, nehmen wir an ich bin morgens zu Hause, schalte den PC und Jabber ein. Den PC lasse ich an und fahre in die Uni. In der Zeit, in der ich in der Sbahn sitze schreibt mir wer. In der Uni schalte ich meinen Laptop an und gehe online. Von den Nachrichten daheim sehe ich nichts. Das XMPP Protokoll sieht eine Lösung für ein solches Problem schon vor [1] aber kein mir bekannter Client hat dies bisher implementiert.

Nun habe ich einen Work-Around gebastelt auf Linux-Basis mit mcabber [2]. mcabber läuft auf meiner Linux-Kiste rund um die Uhr und ist dauerhaft im Status NA (Not Available). Die Priorität von mcabber ist 0. Die Prio meiner übrigen Clients > 0. Wenn nun kein anderer Client “an” ist, bekommt mcabber alle Nachrichten zugestellt. Die werden protokolliert mit der mcabber eigenen “event”-Funktion. Darüber können kleine Shell-Skripte eingebunden werden, die dann das übrige Vorgehen definieren. Also praktisch gesprochen: mcabber schreibt alle Nachrichten, die ich erhalte während kein PC eingeschaltet ist, in eine Datei. So bald ein PC mit Jabber online geht, sendet mcabber eine Email an mich und löscht die Protokoll Datei. Ich sagte ja: Ein Work-Around So schaut das Skript aus:

event=$1
arg1=$2
arg2=$3
filename=$4
date=$(date ‘+%d%m%y-%H%M%S:’)
# Note that the 4th argument is only provided for incoming messages
# and when ‘event_log_files’ is set.

if [ $event = "MSG" ]; then
case “$arg1″ in
IN)
# Incoming message from buddy $arg2
echo $date $(/bin/cat $filename) >> ~/.mcabber/msg/$arg2
if [ -n "$filename" -a -f "$filename" ]; then
/bin/rm $filename
fi
;;
esac
elif [ $event = "STATUS" ]; then
# Buddy $arg2 status is $arg1 (_, O, I, F, D, N, A)
if [ $arg2 = "meineJID@server.de" -a $arg1 = "O" ]; then
cd ~/.mcabber/msg/
for i in `/bin/ls ~/.mcabber/msg/`; do /bin/cat $i | mail -s “Jabber: $i” meineEMAIL@google.de; done
/bin/rm ~/.mcabber/msg/*
fi
fi

mcabber ist übrignes ein wirklich nett anzusehender Jabber Client, der rein auf Konsole basiert. Sehr witzig und sogar gut zu bedienen.

[1] http://www.xmpp.org/extensions/xep-0146.html
[2] http://www.lilotux.net/~mikael/mcabber/

Torrentflux ist eine PHP/Python/Ajax/MySQL Anwendung, mit der man über Apache einen Bittorrent starten kann. Es braucht keine Einrichtung, außer das Setup über Torrentflux und die Einrichtung einer MySQL-Tabelle.

Link: http://tf-b4rt.berlios.de/

Leider ist der Syntax anders und so war es eine Menge Arbeit bis all meine Dokumentationen portiert waren. Das neue Wiki ist unter http://wiki.freakempire.de/ erreichbar.

Das alte Wiki (http://wiki.sprayen.de) ist ab sofort nur noch eine Weiterleitung zum Neuen.

Das ist natürlich nicht meine Meinung. Ich meine, dass Solaris eins der besten Betriebssysteme ist, dass man für professionelle Server nutzen kann. Auch mit der Annäherung an die i386-Technologie hat man sicher einen richtigen Schritt gemacht. Jedoch kann ich mir persönlich nicht vorstellen, je selbst Solaris zu nutzen. Um zum Beispiel meinen Server zu betreiben.
In meiner Ausbildung hatte ich nicht viel mit Solaris zu tun, aber die wenigen Stunden, die ich damit verbracht habe, waren einfach viel zu viel Umgewöhnung. Es sind die simplen Sachen, wie auch in dem Zdnet-Beitrag beschrieben wird; ein einfaches ‘ls’ gibt es nicht. Wobei ich Zdnet nicht zustimmen kann, was den Installer von Software betrifft. Der kann sicher mit Debians apt-get mithalten. Aber was solls… vielleicht macht ja Sun einen zweiten Solaris Branch und entwickelt parallel Linux. Rein schnuppern würde ich auf jeden Fall

1. Muss das Java Binary geladen werden:
http://www.java.com/de/download/manual.jsp

2. Unter Debian müssen die Pakete ‘fakeroot’ und ‘java-package’ installiert sein:

apt-get install fakeroot java-package

3. Dann geht man unter /usr/share/java-package und kopiert das Verzeichnis von Version 5:

cp -a sun-j2re1.5 sun-j2re1.6

4. Dann muss die Datei sun-j2re1.6/install bearbeiten werden und folgende Variable (in der ersten Zeile) geändert werden:

suffix=j2re1.6-sun

5. Nun noch das Skript ‘sun-j2re.sh’ angepasst und folgende Zeilen in die case-Bedingung eingefügt:

"jre-6u1-linux-i586.bin")
j2se_version=1.6
j2se_expected_min_size=16
found=true
;;

6. Und nun kann man das Java .deb bauen mit dem Befehl:

fakeroot make-jpkg jre-6u1-linux-i586.bin

Und das wars dann auch schon. Man kann nun das .deb, wie gewohnt, mit ‘dpkg -i’ installieren.

(17.02.2009: UPDATE – Telekom stellt derzeit ihre Technik auf zwei VLANs um. In Zukunft wird es vlan id 7 und 8 geben. Wie man das unter Linux/Debian einrichtet findet ihr hier: /2009/02/17/t-home-vdsl-unter-debian-linux-einrichten-vlan-id-7-und-8/)

(14.12.2009: UPDATE – Die MTU für ppp0 scheint doch besser 1454 zu sein. 1492 ist definitiv falsch. Einstellen mit ‘ifconfig ppp0 mtu 1454′ oder in den entsprechenden Debian Konfigurationen)

Nach langem basteln habe ich es nun geschafft. Ich habe endlich den billigen mitgelieferten Router in die Tonne getreten und mein Debian System wieder zum Router gemacht. Das ist mir schon deshalb lieber, weil ich viel mehr Kontrolle über Firewall, Proxy und alles andere habe.

Netter Nebeneffekt ist, dass man bei vollem Upload keine Bildprobleme bekommt. Auch wenn manch einer nun sagen mag, dass man dann den Router einfach den priorisierten Port hängen soll. Das ist defintiv falsch. Fakt ist, dass der Telekom Router einfach Mist baut. Der Reciever hängt nun in meinem Netz und Daten werden alle über iptables ins Internet geroutet und zurück. Es läuft perfekt.

Leicht war die Sache allerdings nicht. Vor allem weil man bis dato kaum Informationen dazu findet (das hat ja nun ein Ende *g*). Und für alle, die sich auch an dem T-Com Router stören berichte ich nun wie ich es gemacht habe. In meinem Blog zuvor hatte ich ein Verkabelungsbild gezeichnet. Das ist Vergangenheit. Man kann mit 0815-Switches einfach keine Netze von einander trennen.

Beginnen tut die Geschichte damit, dass man seine pppoe Verbindung modifizieren muss. Außerdem wird eine Netzwerkkarte benötigt, die VLAN unterstützt. Diese Karte wird mit dem VDSL2 Modem verbunden. Wie man heraus findet ob die Karte es unterstützt, weiß ich nicht. Das werde ich noch in Erfahrung bringen. Aber meine beiden ur-alten Karten (Realtek, 3com) unterstützen es. Also denke ich, dass die meisten mithalten können.

Der Kernel muss mit VLAN Unterstützung kompiliert werden (modular oder
monolithisch). eth1 ist im folgenden die NIC, die mit dem Modem
verbunden ist.

Man braucht noch aus apt folgendes Paket:

vlan - user mode programs to enable VLANs on your ethernet devices

Und diese Einstellungen in den interfaces. Die ID ’7′ ist scheinbar
zwingend notwendig für (Telekom) VDSL:

# /etc/network/interfaces
auto eth1
iface eth1 inet manual
post-up vconfig add eth1 7
post-down vconfig rem eth1.7

Nun muss man dem pppoe nur noch sagen, dass eth1.7 das zu verwendende
Device ist:

# /etc/ppp/pppoe.conf
# Ethernet card connected to DSL modem
ETH='eth1.7'

Damit müsste man sich nun einwählen können. Natürlich müssen die Benutzerdaten usw. stimmen (/etc/ppp).

Jetzt zum IPTV, was mich die meiste Arbeit gekostet hat. Der Kernel braucht hierfür Multicasting und Multicasting Routing Support. Und ohne folgendes kleines Programm hat man das Problem, dass man nach 10 Sekunden immer ein Standbild bekommt. Hierfür wird ein igmpproxy installiert:

http://sourceforge.net/projects/igmpproxy

Entpacken, in ‘src’ wechseln und mit make kompilieren und mit make install installieren.

Nun muss die /etc/igmpproxy.conf konfiguriert werden:

quickleave
# upstream = Internet Device
phyint ppp0 upstream ratelimit 0 threshold 1
altnet 217.0.119.194/24
altnet 193.158.35.0/24;
# IP der TV-Box
altnet 192.168.1.5/32;

# eth0 ist das LAN-Interface
phyint eth0 downstream ratelimit 0 threshold 1

# andere Devices werden deaktiviert

phyint eth1 disabled
phyint eth1.7 disabled
hyint lo disabled

Gestartet wird das ganze dann mit:

igmpproxy -d -c /etc/igmpproxy.conf > /dev/null 2>&1 &

Die Umleitung ins Nirvana kann man für Debug Zwecke vielleicht erst Mal nicht verwenden. Aber in der Syslog wird auch nochmal alles protokolliert, was ich später dann aber deaktiviert habe, weil es zu viel zu großen Log-Dateien führt und nicht wirklich informativ ist, wenn es mal läuft. Das muss über den syslog-ng (oder alternativ ksyslogd) gelöst werden.

Als letztes müssen noch ein paar iptables Regeln hinzugefügt werden. Und zwar müssen alle Multicast Pakete durchgelassen werden (dafür haben wir den Kernel neu kompiliert):

iptables -I FORWARD -s 217.0.119.0/24 -d 224.0.0.0/4 -j ACCEPT
iptables -I FORWARD -s 193.158.35.0/24 -d 224.0.0.0/4 -j ACCEPT
iptables -I INPUT -d 224.0.0.0/4 -j ACCEPT
iptables -I FORWARD -d 224.0.0.0/4 -j ACCEPT

Und damit hat man dann einen super Zugang zu VDSL und IPTV mit dem netten Nebeneffekt, dass das Umschalten durch den igmpproxy in Windeseile funktioniert.

Viel Spass

 .------. 2.0    1.0     .----.
 | iptv |------. .-------| PC |
 '------'      | |       '----'
               | |
             .-----.
             | SW2 |
             '-----'
              |          RO=Router
              |          SW=Switch
              |          SERV=Server
           .-----.
           | SW1 |
           '-----'
       2.0   | |  1.0
       ------' '------
       |             |
    .----.          .------.
    | RO |----------| SERV |
    '----'   2.0    '------'

Ohne “manage-baren” Switch scheint es mir unmöglich die beiden Netze vernünftig zu trennen. Die einzige Möglichkeit, die mir nun noch durch den Kopf geht, ist den Server als Router in Rente zu schicken und den Telekom Router als Firewall agieren zu lassen. Aber die Firewall im Router bietet mir viel zu wenig Funktionen.

Dennoch dachte ich mir ein Organizer wäre nicht schlecht. Sowas in der Art, was Outlook bietet. Nur leider habe ich kein Outlook, sondern Thundebird. In meinem alten Blog habe ich schon mal von Lightning [1] berichtet gehabt. Eine Extension für Thunderbird [2], die auf Sunbird [3] basiert. Für normal kann man einen Kalender ganz leicht einrichten. Aber wenn man von mehreren Rechnern und von überall aus, auf einen Kalender zugreifen möchte, dann bedarf es z.B. eines WebDAV Servers. Wie man einen solchen einrichtet, erkläre ich weiter unten (auf das Knöpfchen “Weiterlesen…” drücken).

Einen DAV Server kann man z.B. wie ein Laufwerk in Windows einbinden, ist aber ein Dateisystem auf einem Webserver. Sundbird/Lightning legen dort ihre .ics Dateien ab, die die Termine und Aufgaben vom Kalender enthalten. Mit Apache2 ist ein WebDAV ganz schnell eingerichtet.

[1] http://www.mozilla.org/projects/calendar/lightning/
[2] http://www.mozilla-europe.org/de/products/thunderbird/
[3] http://www.mozilla.org/projects/calendar/sunbird/

Als erstes muss das “DAV-Modul” im Apache2 aktiviert werden:

# a2enmod dav_fs
# a2enmod auth_digest

Nun ist es natürlich zu empfehlen, dass man seine Daten verschlüsselt. Mein DAV habe ich deshalb in einen SSL verschlüsselten Bereich gelegt (darauf gehe ich nicht näher ein). Selbstverständlich ist das nicht zwingend notwendig. Man suchst sich den vhost, bzw. die Konfiguration zur Seite aus und fügt folgendes hinzu:

SSLEngine on
SSLCertificateFile /etc/apache2/ssl/certificate
ServerName dav.domain.tld
DocumentRoot /var/wwws/
ErrorLog /var/log/apache2/ssl.error.log
TransferLog /var/log/apache2/ssl.access.log

Alias /caldav /var/wwws/caldav

        DAV On
        AuthType Digest
        AuthName "privdav"
        AuthUserFile /var/wwws/caldav/.passwd
        Require valid-user

Nun muss noch die Passwort-Datei angelegt werden:

# cd /var/wwws/caldav/
# htdigest -c .passwd privdav benutzername

Nun den Apache2 neu gestartet und der WebDAV sollte funktionieren