/dev/blog/ID10T

Advertisement

OT: Meine momentane Situation

• Offtopic • Comments

Diesen Strip habe ich über Reddit gefunden und kann mich hervorragend damit identifizieren.

2013-04-19-distraction-comic

Momentan könnte ich haufenweise Blogposts schreiben oder an meinen diversen Projekten arbeiten, aber mein Spieler #3 (und natürlich auch meine Spielerin #2) geht mir dann doch einfach vor. Vielleicht finde ich ja irgendwann die Zeit, um mal was über PHP-FPM zu schreiben oder über meine Erfahrungen mit Groupware-Installationen oder meine neusten Spinnereien. Vielleicht aber auch nicht, Familie geht eben vor. :-)

(Quelle: lunarbaboon.com)

Perl: CPAN durch Squid-Proxy mit HTTP nutzen

• Administration and Linux • Comments

Das Problem, dass ich keine Module über CPAN nachinstallieren konnte, weil ich hinter einem Squid-Proxy war, der kein FTP durchließ, hatte ich jetzt schon öfters. Weil ich jedes Mal wieder überlegen muss, wie man diese Problematik nun behebt, hier eine fixe Erklärung.

Dazu bearbeiten wir die Konfigurationsdatei von CPAN, die überaschenderweise Config.pm heißt. Wo diese Datei zu finden ist, hängt unter anderem von der verwendeten Distribution ab. Bei meinem SLES11SP2 Testsystem liegt die Datei unter /usr/lib/perl5/5.10.0/CPAN/. In diese Datei fügen wir nun folgenden Eintrag ein:

'dontload_hash' => { q[Net::FTP]=>q[1], q[LWP]=>q[1] },

und bearbeiten wenn nicht schon bei der Ersteinrichtung geschehen den Eintrag für den HTTP-Proxy, um unseren Proxy-Server mitsamt Port dort zu hinterlegen.

'http_proxy' => q[http://proxy.foobar.org:3128],

Das war's eigentlich schon, damit sollte sich CPAN verbinden können. Doch was haben wir genau getan?
Wir haben CPAN angewiesen, die für FTP verwendeten Module nicht mehr zu laden. Dadurch gibt es ein Fallback auf WGET oder CURL, welche sich über HTTP verbinden und die dafür benutzten Proxyeinstellungen nutzen.

2013-04-05-config.pm

Es kann sein, dass je nach Proxykonfiguration nicht beide Module deaktiviert werden müssen. Allerdings bin ich mit dieser Einstellungen bisher immer gut gefahren.

Warum liebe Mainboardhersteller?

• Hardware and Rants • Comments

Mal wieder ein Rant. Da sich mein Geburtstag langsam nähert und ich eigentlich keine großen Wünsche habe, dachte ich mir, dass ich mir einen vernünftigen Testrechner aufbaue. Der Dell Optiplex 740, den ich hier rumstehen habe, ist in sämtlichen Kategorien durchgefallen, weswegen ich mir jetzt lieber einen eigenen zusammenstellen möchte. Mein Fokus liegt dabei auf bestmöglicher Unterstützung von Virtualisierung - speziell ESXi - und guter Aufrüstbarkeit. Ich dachte an ein Sockel 1155 Mainboard mit einem entsprechenden Intel-Prozessor, das bis zu 32GB RAM aufgerüstet werden kann. Und hier fängt das Problem an. Intel bietet zwei Technologien für Virtualisierung an, das allseits bekannte und fast überall unterstützte VT-x und das weniger bekannte und weniger genutzte VT-d. Um VT-d nutzen zu können, muss das Mainboard VT-d Unterstützung anbieten. Auch wenn ich vorerst nicht vorhabe, VT-d zu nutzen, würde ich mir diese Möglichkeit gerne offenhalten, also ein Mainboard einbauen, welches VT-d unterstützt. Aber das machen einem die Mainboardhersteller so schwer wie möglich. Bisher habe ich auf keiner Herstellerwebsite direkt Angaben gefunden, ob das Mainboard VT-d unterstützt oder nicht. Bei ASRock habe ich es im Handbuch finden können, aber auch nur, weil dort der UEFI-Eintrag dafür beschrieben wird.

Liebe Hardwarehersteller, warum macht ihr es uns so schwer, an solche "Randgruppeninformationen" zu kommen?

Als Fazit werde ich mich wohl für ein Mainboard von ASRock mit Z77-Chipsatz* entscheiden, diese unterstützen offenbar alle VT-d. Mein Favorit momentan ist das Z77 Pro 3.

*=Affiliatelink

 

VMware: Marktführer, aber...

• Rants • Comments

...für eine Internetanbindung jenseits von DSL reicht es dann wohl doch nicht.

Hintergrund der Geschichte: Wir haben momentan einige Supportcalls bei VMware geöffnet. Essentieller Bestandteil davon ist die Übermittelung von Coredumps und Logbundles zu VMware, damit deren Techniker eine tiefergehende Analyse vornehmen können. Gerade die Coredumps können schnell ein paar Gigabyte groß werden. Das scheint die Firma VMware, deren Marktwert so um die 30 Milliarden US-Dollar beträgt und deren Umsatz jenseits von 3,5 Milliarden US-Dollar pro Jahr liegt, nicht davon abzuhalten, die Uploadgeschwindigkeit von FTP-Accounts zu begrenzen. Dass die Geschwindigkeit VMware seitig begrenzt wird, wurde uns von einem Supportmitarbeitet bestätigt. Es scheint, als wäre die Uploadgeschwindigkeit pro FTP-Account auf ca. 180 KB/s begrenzt. Und wie man sieht, kann die VMware-Leitung nichtmal diese "Geschwindigkeit" beibehalten.

2013-03-26-vmware-highspeed-ftp

Hier mal als Vergleich ein banaler Speedtest:

2013-03-26-speedtest

Das Problem liegt also sicher nicht bei uns.

Dass eine IT-Firma solche steinzeitlichen Begrenzungen bei Diensten konfiguriert, die man sowieso nur mit bezahltem Support nutzen wird, empfinde ich als ein ziemliches Armutszeugnis.

NTP-Client in Debian einrichten

• Linux • Comments

Eine der ersten Aktionen auf einem frisch installierten Linux Server ist sicherlich das Einrichten von NTP. Dass eine synchronisierte Systemzeit extrem wichtig ist, sollte den meisten Usern und Admins einleuchten. Jeder, der deswegen schonmal mit Datenbankinkonsistenzen zu kämpfen hatte, weiß wovon ich rede. Da ich die Schritte immer wieder vergesse, werde ich sie hier für die Nachwelt dokumentieren.

  1. Falls gewünscht sollte die Zeitzone eingestellt werden. Das geht auf zwei Arten. Mit manueller Eingabe:
    dpkg-reconfigure tzdata

    oder indem man die entsprechende zonedate kopiert:

    cp /usr/share/zoneinfo/Europe/Berlin /etc/localtime

    Europe und Berlin solltet ihr dann natürlich durch eure entsprechenden Pendants ersetzen.

  2. Den ntp-Dienst installieren, falls noch nicht vorhanden.
    aptitude -y install ntp
  3. Anschließend ersetzen wir die Poolserver in der ntp.conf noch mit denen des jeweiligen regionalen ntp-Pools.
    sed -i 's/debian.pool.ntp.org/de.pool.ntp.org/g' /etc/ntp.conf
  4. Dann noch den NTP-Dienst neustarten und alles ist fein.
    service ntp restart

Ein Oneliner für Copy & Paste oder Skripte würde dann so aussehen:

cp /usr/share/zoneinfo/Europe/Berlin /etc/localtime && aptitude -y install ntp && sed -i 's/debian.pool.ntp.org/de.pool.ntp.org/g' /etc/ntp.conf && service ntp restart

Die ganze Chose kann man dann entweder testen, indem man mal ein

ntpq -p

eingibt, um die NTP-Server des Systems herauszubekommen oder - wenn man ein bisschen paranoid ist, so wie ich - indem man den NTP-Dienst beendet, die Zeit ändert und ihn dann mit dem -gq Parameter startet.

service ntp stop && date -s 12:00 && ntpd -gq && service ntp start && date

Wenn die Ausgabe dann etwa so aussieht:
2013-03-15-ntp-client und der Eintrag "ntpd: time set" erscheint, läuft alles korrekt.
Falls ihr auf eurem Server iptables einsetzt und standardmäßig alle ausgehenden Verbindungen dropt, solltet ihr noch zwei Regeln in euer iptables-Skript aufnehmen:

iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
iptables -A INPUT -p udp --sport 123 -j ACCEPT

Damit sollte dann wirklich alles laufen.

Advertisement