Debian sources.list
Da ich das immer wieder suchen muss ...
http://wiki.debianforum.de/Sources.list
testing:/etc/apt# cat /etc/apt/sources.list deb http://ftp.de.debian.org/debian/ stable main contrib non-free deb http://security.debian.org/ stable/updates main contrib non-free deb http://ftp.de.debian.org/debian squeeze-updates main contrib non-free
Diese sources.list bindet die aktuellen Pakete ein. Ein Release-Wechsel ist damit ebenfalls möglich (wenn testing zu stable wird). Wer lieber in der Version bleiben möchte, ersetzt einfach main durch "squeeze" oder ähnliches.
Finanzakrobatik kurz erklärt …
Icinga und Lighttpd
Die offizielle Icinga Dokumentation beschreibt den Einsatz von Icinga ausschließlich mit Apache2. Wer Apache nicht betreiben möchte, kann z.B. auf Lighty (Lighttpd) zurück greifen.
Damit Icinga Classic dort funktioniert, muss die Datei lighttpd.conf entsprechend angepasst werden:
# icinga config $HTTP["host"] == "icinga.domain.de" { server.document-root = "/usr/local/icinga/share" alias.url += ( "/icinga/cgi-bin" => "/usr/local/icinga/sbin", "/icinga" => "/usr/local/icinga/share" ) $HTTP["url"] =~ "^/icinga/cgi-bin" { cgi.assign = ( "" => "" ) } auth.backend = "htpasswd" auth.backend.htpasswd.userfile = "/usr/local/icinga/etc/htpasswd.users" auth.require = ( "" => ( "method" => "basic", "realm" => "Welcome to Icinga", "require" => "valid-user" ) ) }
Diese Version funktioniert so ausschließlich mit der per tar.gz selbst kompilierten Variante. Werden Pakete aus den Paketquellen verwendet, müssen evetuell die Pfade entsprechend angepasst werden.
Lighty ruleZ 
OSMC 2011 in Nürnberg
Morgen gehts auf nach Nürnberg zur OSMC 2011. Nachdem ich die letzten Jahre aufmerksamer Zuhörer war, halte ich dieses mal selbst einen Vortrag. Bernd Erk hat mich gebeten als Vertretung einzuspringen, was ich an dieser Stelle gerne mache.
Der Vortrag wird im Großen und Ganzen eine kurze Vorstellung der Integration von Nagios und Icinga bei der Müller Ltd. geben.
“Input-/Output-Error” oder “Ein-/Ausgabe-Fehler” bei Webdav
Webdav verfolgt mich hartnäckig und verursacht bei mir regelmäßig Schmerzen. Nachdem ich letztens erst mit Webdav unter Microsofts IIS konfrontiert wurde und mich einigermaßen erholt hatte, war nun heute box.net und Webdav an der Reihe.
Nachdem der Mount mit
sudo mount -t davfs -o uid=1000,gid=100 https://www.box.net/dav /mnt/box.net
schnell hergestellt war, scheiterte das schreiben von Daten mit einem Ein-/Ausgabefehler.
user@server /mnt $ touch box.net/test touch: kann „box.net/test“ nicht berühren: Eingabe-/Ausgabefehler
Logisch war das nicht ... Die Erklärung noch weniger.
Damit das alles funktioniert, muss in der Datei /etc/davfs2/davfs2.conf folgende Zeile "korrigiert" werden.
- # use_locks 1 + use_locks 0
Warum das Protokoll sowas selbst nicht erkennt, wissen vermutlich nur die Entwickler selbst.
Bleibt festzuhalten, dass jeder Webdav-Server seine eigenen Einstellungen benötigt.
VMWare-Sphere Perl SDK 5.0
Properitärer Mist ... Anders kann man es nicht nennen.
Ich versuche gerade unser Icinga dazu zu bewegen, Kontakt mit einem VMWare-Server aufzunehmen. Es gibt dazu mittlerweile zwar sehr viele schicke und nützlich Plugins, leider basieren diese alle auf der Perl-API von VMware. Mal abgesehen davon, dass ich mich für den Download registrieren muss, ist die Installation eine ziemliche Qual. Glücklicherweise lassen sich alle Abhängigkeiten über CPAN auflösen.
Nach der Installation klappt der Verbindungaufbau zum VMWare-Server leider nicht, da das installierte LWP::Protocol::https das "fehlerhafte" Zertifikat nicht mag und mit folgendem Fehler terminiert:
UNKNOWN: ERRORMSG: Server version unavailable at 'https://localhost:443/sdk/vimService.wsdl' at /usr/share/perl/5.10/VMware/VICommon.pm line 545.
Damit das doch funktioniert, muss in dem Perl-Modul SSL_verify_mode von 1 nach 0 umgestellt werden. Damit werden dann auch ungültige Zertifikate akzeptiert.
/usr/local/share/perl/5.10.1/LWP/Protocol/https.pm
my %ssl_opts = %{$self->{ua}{ssl_opts} || {}};
if (delete $ssl_opts{verify_hostname}) {
$ssl_opts{SSL_verify_mode} ||= 0;
$ssl_opts{SSL_verifycn_scheme} = 'www';
}SWU Telenet und FritzBox 7390
So ... Nun ist es geschafft. Nachdem 1und1 zu faul, zu bequem oder einfach nur zu dämlich war, unsere DSL-Leitung wieder auf Stand zu bringen, haben wir nun Internet von den Stadtwerken Ulm (SWU). Die SWU hat letztes Jahr jede Menge Geld in die Hand genommen und bei uns im Ort lauter Outdoor-DSLAMs gesetzt. Eine feine Sache. Reduziert sich doch dadurch die Leitungslänge vom DSLAM zu uns nach Haus von 4,9km auf knapp 200m
Im Zuge dieses Ausbaus konnte man bei der SWU nun VDSL mit bis zu 50 MBit/s über KVZ-Anbindung und 100 MBit/s über Glasfaser bestellen.
Da wir seit März 2011 immense Probleme mit unserem 1und1-DSL-Anschluß hatten - die Bandbreite reduzierte sich mit jeder Synchronisation von ursprünglich 4,5 MBit/s auf jetzt 1,9 MBit/s - habe ich mich nun für einen 17 MBit/s-Leitung der SWU entschlossen.
Die SWU bietet anders als die großen Anbieter nicht ganz soviel Auswahl bei der Bestellung und Beauftragung des Anschlusses. Ist die Bestellung durch, trudelt einige Tage vor Schaltung der Leitung ein etwas seltsam anmutender Router mit dem Name Cell Pipe 7130 ein. Der Router bietet, abgesehen davon, dass er kreuzhässlich ist, nicht mal annähernd den gewohneten Komfort einer FritzBox. Die Einstellungen sind zwar sehr umfangreich, verlieren sich aber oft in technischen Details und muten stellenweise sehr kryptisch an. Wer von QoS, TOS, VPI, VCI noch nie etwas gehört hat, für den erschließen sich die Einstellungen des Routers in keiner Weise. Zusätzlich ist der "Standard-Zugang" mit dem Benutzer "user" nur eine abgespeckte Variante der Bedieneroberfläche. Die Login-Daten für den "admin"-Account kann man übrigens aus der Konfigurationsdatei - so man sie über die Weboberfläche herunterlädt - auslesen. Wer an dem Router etwas mehr rumfummeln will, kann sich also mit "admin" und "telenet" anmelden.
Aber zurück zum Thema Komfort ... Auch am SWU-Telenet-Anschluss möchte ich weiterhin den Komfort meiner FritzBox mit iPhone-App, Sipgate-Account, VPN, etc. nutzen. Da es sich beim Anschluß aber, unabhängig von der Bandbreite, um einen VDSL-Anschluß handelt, werden im Willkommens-Schreiben keine Login-Daten mehr mitgeliefert. Der Login in der FritzBox erfolgt gemäß RFC1483/RFC2684 ohne Login-Daten dafür mit VPI- (1) und VCI-Kennung (32). Als Kapselung wird "Bridged (Routed Bridge Encapsulation)" verwendet. Zusätzlich sind, laut Auskunft des SWU-Technikers, auch noch die MAC-Adressen der Router an die DSLAM-Ports gekoppelt. Theoretisch wird die Zuordnung nach 24-Stunden (DHCP-Lease-Time) gelöscht und ein neuer Router kann verwendet werden. Da dies aber wohl nicht in allen Fällen klappt, ist ein Anruf im SWU-Servicecenter hilfreich. Dort spielt sich der Vorteil eines "kleinen" Unternehmens wieder voll aus ... 1A SUPPORT ... und die MAC-Adresse wird gelöscht.
Was ist also zu tun, um eine eigene FritzBox 7390 am SWU-Telenet-Anschluß zu betreiben?
1. Zurücksetzen
Am besten setzen man die FritzBox komplett auf Werkseinstellungen zurück. Sollte das nicht funktionieren, kann auch von der AVM-Homepage ein Recovery-Tool geladen werden:
http://www.avm.de/de/Service/FAQs/FAQ_Sammlung/12798.php3
2. Konfiguration
Sollte ein DSL-Link bestehen und in der FritzBox eine Verbindung zum DSLAM angezeigt werden, ist bereits die Hälfte geschafft.
Weiter gehts ...
a) Man besorgt sich über das SWU-Telenet-Servicecenter eine vorkonfigurierte Konfigurationsdatei für die FritzBox und packt diese auf einen USB-Stick und flasht damit die Box. Dies ist wohl die einfachste Variante.
b) Man versucht die notwendigen Einstellungen allein in die Box zu bekommen:
Nach einem Reboot der Box sollte nun eine Verbindung hergestellt werden können. Tritt an dieser Stelle nun ein Problem auf UND der Zugang ist weiterhin über die Cell Pipe 7130 möglich, dann blockt der DSLAM die Verbindung, da eine falsche MAC-Adresse gespeichert ist. Wer sich damit auskennt und das Problem nach 18:00 Uhr noch beheben will, kann sich auch testweise in die FritzBox einloggen und die MAC-Adresse der FritzBox faken.
z.B.
ifconfig eth0 down ifconfig eth0 hw ether [MAC-ADRESSE Cell Pipe] ifconfig eth0 up
Dies sollte jedoch nur eine Notlösung sein, vom ausprobieren rate ich dringend ab, da der SWU-Support kostenlos, sehr hilfreich und kompetent ist.
3. VOIP (Sipgate) einbinden
Irgendwas läuft schief in der Default-Konfiguration. Die SWU konfiguriert in der Box ein 2.VLAN (200) für den VOIP-Verkehr. Leider scheinen die DNS-Server in diesem Netz zum einen ein bisschen eingeschränkt zu sein, zum anderen vermute ich eine ebenfalls eingeschränkte Routing-Fähigkeitm da z.B. keine Verbindung zu einem anderen VOIP-Server aufgebaut werden kann, als den SWU-VOIP-Server.
Das Problem lässt sich in der Fitzbox damit lösen, indem unter dem Punkt "Telefonie" -> "Internet Telefonie" -> "Erweiterte Einstellungen" der Punkt "weitere Verbindung für die Internettelefonie über DSL nutzen (PVC)" ausgeschaltet wird. Zusätzlich muss auf der selben Seite der Punkt "VLAN für Internettelefonie verwenden" ebenfalls deaktiviert werden.
Damit geht der komplette VOIP-Verkehr nun über das primäre Interface.
