Untotes
Ich möchte auf ein neues “Projekt” von mir und einem guten Freund hinweisen. Zusammen schreiben wir bei www.zombie-blog.info über Untote und Zombies. Man sollte sich früh genug fragen, was man bei einer Zombie-Apocalypse macht.
Ich möchte auf ein neues “Projekt” von mir und einem guten Freund hinweisen. Zusammen schreiben wir bei www.zombie-blog.info über Untote und Zombies. Man sollte sich früh genug fragen, was man bei einer Zombie-Apocalypse macht.
Die Fehlermeldung “Fehlercode: ssl_error_rx_record_too_long“ bekommt man bei Firefox zu gesicht, wenn man über https eine Seite erreichen will, aber der Webserver Lighttpd mod ssl noch nicht aktiviert hat. Dies macht man mit
lighty-enable-mod ssl
Natürlich muss man dazu auch ein passendes Zertifikat erstellt haben.
Ich habe grade einige Sachen mit dem schlanken Webserver Lighttpd ausprobiert und war u.A. auf der Suche nach einer Alternative zum .htaccess Zugriff, den man von Apache gewohnt ist. Ich bastelte mir dann eine recht elegante Lösung zusammen.
Zuerst wird mittels
lighty-enable-mod auth
Das mod_auth Modul von Lighttpd aktiviert. Danach fürgen wir in /etc/lighttpd/lighttpd.conf ans Ende folgenden Code:
auth.backend = “htpasswd”
auth.backend.htpasswd.userfile = “/etc/lighttpd/htpasswd”
auth.require = ( “/Pfad/” =>
(
“method” => “basic”,
“realm” => “Nur mit gültigen Benutzer”,
“require” => “user=tim”
)
)
/etc/lighttpd/htpasswd bezieht sich auf die htpasswd-Datei, die wir noch nicht erstellt haben. /Pfad/ steht dort als Platzhalter für die relative Angabe des Pfads, der zu schützen ist. Nach “require” kann man entweder, wie ich es machte, einen vorhandenen Benutzer stellen oder mit der Option “valid-user” irgendeinen, in der htpasswd-Datei vorhandene, Nutzer vorraussetzen. Danach widmen wir uns der htpasswd-Datei und erstellen diese mit dem Befehl
htpasswd -c /etc/lighttpd/htpasswd Benutzername
Das Argument -c steht in diesem Fall für “create”. Wenn man im Nachhinein weitere Benutzer hinzufügen will, kann man einfach den Befehl ohne Argument ausführen. Nachdem wir den Webserver neustarten, sollten die Änderungen wirksam geworden sein und das gewünschte Verzeichnis ist geschützt.
Memo an mich selbst: Baudrate für das Alixboard in Verbindung mit OpenWRT beträgt 38400.
Nach einigen Eskapaden mit meinem MacBook Pro, die ich bereits andeutete: “(…)Ein Sturz auf dem OmasTeich Festival während des Aufbaus verzog das Gehäuse ein wenig und sorgte für Probleme mit Arbeitsspeicher und Hintergrundbeleuchtung.(…)“, hatte ich schon wieder ein Problem mit meinem Mac. Weniger die mangelnde Qualität von Apple bei der Verarbeitung und Auswahl der Komponenten, sondern mein eigenes Verschulden, verursachte dies.
Das SuperDrive las und, folglich auch, brannte keine CDs/DVDs mehr. Anfangs nahm ich an, dass mein Laufwerk wirklich kaputt sei. Doch nach einiger Recherche fand ich den Tipp, dass man das SuperDrive zu erst einmal reinigen sollte.
Von einer Reinigungs-CD würde ich in dem Fall eher abraten. Es besteht die Möglichkeit, dass man die Linse verkratzt. Meine Lösung war da eher etwas unorthodoxer. Ich beschloss, das SuperDrive zu zerlegen…
Langsam schein ich mich noch zu einem richtigen Lighttpd-Fan zu entwickeln. Am Dienstag beschrieb ich ja bereits, wie man mit den VHost Einträgen in der Lighttpd.conf SEO freundliche URLs erstellen kann. Am Mittwoch war ein wenig Debugging dran und ich zeigte, wie man einen PhpMyAdmin Fehler unter Lighty beheben kann.
Doch während der erste Part der VHost Einträge nur “duplicate Content” also doppelten oder mehrfachen Inhalt vermeidet, hilft es ja nich bei der Linkstruktur. Da ich gerne WordPress sowohl als Conten Management System (CMS), als auch als eigentliche Blogsoftware, einsetze, werde ich heute zeigen, wie man die Permalinks ähnlich schön, wie unter Apache hinbekommt.
Lighttpd hat ja den Nachteil (oder auch Vorteil), dass es keine .htaccess Datein nutzt. Also braucht man für das Rewriting eine Alternative. Die ist auch in den VHost Einträgen in der Lighttpd.conf verankert. Das ganze sieht bei mir folgendermaßen aus:
$HTTP["host"] =~ “^www\.tuxonauten\.de” {
server.document-root = “/var/www/tuxonauten/”
server.error-handler-404 = “/error_handler.php”url.rewrite = (
“^/(wp-.+).*/?” => “$0″,
“^/(sitemap.xml)” => “$0″,
“^/(xmlrpc.php)” => “$0″,
“^/(.+)/?$” => “/index.php/$1″
)
}$HTTP["host"] =~ “^tuxonauten\.de” {
url.redirect-code = 301
url.redirect = (
“^/(.*)$” => “http://www.tuxonauten.de/$1″,
)}$HTTP["host"] =~ “^tuxonaut\.de” {
url.redirect-code = 301
url.redirect = (
“^/(.*)$” => “http://www.tuxonauten.de/$1″,
)}$HTTP["host"] =~ “^www\.tuxonaut\.de” {
url.redirect-code = 301
url.redirect = (
“^/(.*)$” => “http://www.tuxonauten.de/$1″,
)}
Wirklich relevant ist aber nur folgender Eintrag:
url.rewrite = (
“^/(wp-.+).*/?” => “$0″,
“^/(sitemap.xml)” => “$0″,
“^/(xmlrpc.php)” => “$0″,
“^/(.+)/?$” => “/index.php/$1″
)
Dieser lässt sich natürlich auch auf Unterordner anwenden. Gefunden habe ich das ganze Hier.
Wenn man Lighttpd (lighty) als Webserver nutzt und dann PhpMyAdmin installiert kann es vorkommen, dass, nach Aufruf der PhpMyAdmin URL, der 403-Forbidden-Fehler auftaucht und euch daran hindert auf PhpMyAdmin zuzugreifen. Das ganze kann unter Umständen daran liegen, dass FastCGI in Lighttpd nicht aktiviert ist. Dies kann man dann ganz einfach mit
lighty-enable-mod fastcgi
beheben.
Für ein neues Projekt musste ich grade die VHosts von Lighttpd anpassen. Das ganze soll unter mehreren URLs erreichbar sein, aber auf die Hauptdomain Tuxonauten.de verweisen. Die entsprechenden Einträge sehen so aus:
$HTTP["host"] =~ “^www\.tuxonauten\.de” {
server.document-root = “/var/www/”
server.error-handler-404 = “/error_handler.php”
}$HTTP["host"] =~ “^tuxonauten\.de” {
url.redirect-code = 301
url.redirect = (
“^/(.*)$” => “http://www.tuxonauten.de/$1″,
)}$HTTP["host"] =~ “^www\.tuxonaut\.de” {
url.redirect-code = 301
url.redirect = (
“^/(.*)$” => “http://www.tuxonauten.de/$1″,
)}$HTTP["host"] =~ “^tuxonaut\.de” {
url.redirect-code = 301
url.redirect = (
“^/(.*)$” => “http://www.tuxonauten.de/$1″,
)}
Das ganze habe ich nach einer Vorlage von Sebastian Constapel geschrieben.
Als ich mich gestern Abend mit Mac Adressen und dem Sinn und Zweck dieser beschäftigte, fragte ich mich “Wie kann ich meine Mac Adresse eigentlich unter Mac OS X ändern?”. Unter Linux ist mir die temporäre Änderung geläufig, aber unter Mac OS X fehlte mir dieses Wissen noch. Nach einer kurzen Suche im Internet, kam ich auch recht schnell an eine Lösung, die ich euch nicht vorenthalten möchte:
Zuerst aber noch eine Warnung: Alles geschieht auf eigene Gefahr!
Da das gesagt ist gehts nun los. Wir wählen das Lan – Interface. In meinem Falle die Ethernetschnittstelle. Wir lassen uns mit
ifconfig en0
Alle Informationen, die derzeit über die Schnittstelle verfügbar sind, anzeigen. Dort steht unter Anderem die aktuelle Mac Adresse, die sich aus 48 Bit zusammensetzt. Von den 48 Bit sind die ersten 24 für die Herstellerkennung, auch OUI (= Organizationally Unique Identifier) genannt, reserviert. Eine Liste mit derzeitigen Herstellerkennungen findet ihr hier. Solange keine Netzwerkverbindung besteht, kann man nun die eigene Mac Adresse ändern. Dies geschieht mit dem Befehl
sudo ifconfig en0 lladdr $die_neue_mac_adresse
Mit
ifconfig en0
kann man nun überprüfen, ob die Änderung übernommen wurden.
Bereits seit einiger Zeit sind mir Personensuchmaschinen wie zB. 123People (ein Backlink bekommen die ganz bestimmt nicht von mir) sehr suspekt. Auf der einen Seite sind die dort zusammengetrangenen Informationen oft fehlerhaft und über Google und ähnlichen Suchmaschinen besser zu finden. Auf der anderen Seite ist das Geschäftskonzept, mit fremden Daten Geld zu verdienen, in meinen Augen höchst fraglich. Dazu kommen Datenschutzaspekte und der, ehrlich gesagt, doch vorhandene Ärger darüber, dass sie besser bei Google gerankt sind als meine eigene Homepage bzw. meine Homepage und mein Blog.
Copyright © 2004–2010. All rights reserved.
RSS Feed. This blog is proudly powered by Wordpress and uses Modern Clix, a theme by Rodrigo Galindez.