miiplog

Seit einer ganzen Weile versuche ich eine Tevii S480 mit TVHeadend zum laufen zu bekommen und bin fast verzweifelt. Im Syslog stand immer die Frequenz sei nicht im Bereich den die Karte unterstützt. Vorgestern bin ich dann zufällig auf die Lösung gestoßen.

Und zwar tritt das Problem nur auf, wenn man ein Mainboard mit NVidia Chipsatz mehr als 3GB RAM und einen 64bit-Kernel einsetzt. Genauere Hintergründe hab ich jetzt nicht recherchiert aber man kann das Problem mit dem Kernelparameter „iommu=soft“ umgehen. Dann findet die Karte auch Sender. 🙂

Tags: 64bit, Linux, S480, Tevii

Beastie Boys – Make Some Noise (YooRonYaa Revisited dnb Rework) from YooRonYaa on Vimeo.

von Nerdcore…

Tags: beastie boys, dnb

Seit gestern läuft mein XMPP-Server auf einem neuen vServer. Eigentlich bin ich mit Netcup zufrieden, aber die benutzen Linux-VServer, was manchmal ein paar Nachteile hat. So kann ich z.B. kein Fuse nutzen und hab keinen Zugriff auf iptables. Synth hat mir dann Proplay empfohlen. Die setzen auf OpenVZ, das dieses Probleme nicht hat. Und ausserdem bekommt man dort für nur 2€/Monat einen vServer, der sich Perfekt als XMPP-Server eignet.

Zum Einsatz kommt Prosody, der in LUA geschrieben ist. Ejabberd oder jabberd2 wären sicher auch nett, aber man will ja mal was neues versuchen. 🙂 Die Transports werden von Spectrum gestellt (der braucht dann auch Fuse). Das Ganze läuft jetzt seit gestern und bisher kann ich nicht klagen. Da ich die Domain von Netcup zu Domainfactory umziehen musste, um die nötigen SRV-Records setzen zu können, sind manche Server noch nicht erreichbar. Das sollte sich aber in 24-48h erledigt haben.

Der Umstieg von Openfire wurde nötig, da Openfire ziemlich verschwenderisch mit Ressourcen umgeht und neuerdings einen Bug im SSL-Handling hat, der nicht gefixt wird und verhindert dass man mit verschiedenen Servern kommunizieren kann. Schade eigentlich, mit der Ressourcenverschwendung hätte ich leben können.

Tags: boxxy, proplay, prosody, spectrum, xmpp

Tags: o'reilly, ssds

Gestern hab ich festgestellt, dass OSX etwas zickig ist, wenn es um DNS geht.

Problem: Das Macbook kann keine Hosts im LAN mehr auflösen. Nach etwa einer Stunde und mit viel Hilfe von #macintosh.de auf freenode konnte ich dann aber den Fehler eingrenzen.
Und zwar nutzt OSX den mDNSResponder Dienst. Es gibt zwar eine /etc/resolv.conf, aber die wird nur von Tools wie dig oder nslookup genutzt, die übrigens ohne Problem die Hosts auflösen konnten. Naja, jedenfalls verwirft dieser mDNSResponder Antworten mit zu langer oder zu kurzer TTL (und tut noch ein paar andere Dinge, die man nicht erwarten würde, aber das kann man alles in den Apple Support Foren nachlesen 😉 ).

Lösung: pfSense nutzt nun dnsmasq und gibt keine TTL an, dnsmasq deutet das als TTL von 0. Umgehen kann man das Problem, indem man wie hier beschrieben die TTL in „/etc/inc/services.inc“ durch „–local-ttl 1“ auf eine Sekunde setzt. OSX braucht dann noch eine Weile, bis es wieder versucht, die Namen aufzulösen, aber dann funktioniert alles, wie man es von anderen Betriebssystemen gewohnt ist. In pfSense 2.0 sollte schon eine TTL von 1 gesetzt sein.

Tags: mdnsresponder, osx, pfsense, ttl

Da openwrt genauso wie dd-wrt (sogar das neue Build) versagt haben, teste ich nun pfsense in einer VM als Ersatz für meinen sehr sehr alten IPCop Router. Bisher funktioniert das ganz gut. PPPoE ging auf Anhieb. pfsense ist auch ähnlich gut zu erweitern wie IPCop und scheint mir ein gutes Stück ausgereifter zu sein. Derzeit teste ich Version 1.2.3, werde aber auch noch die 2.0beta anschauen. An netstat -r statt route muss man sicher aber erstmal gewöhnen.

Den Buffalo Router werd ich entweder zurückgeben oder doch noch als AccessPoint nutzen aber dafür ist er eigentlich zu schade. Eigentlich wärs mir lieber, wenn der Router auf eigener Hardware laufen würde… evtl. kommt doch noch so eine Alix-Kiste ins Haus, die kann ja mit der VM CARPen… 😉

Tags: dd-wrt, openwrt, pfsense