WordPress: Upload-Limit erhöhen

In einer neuen WordPress-Umgebung mit podPress stand ich vor dem Problem, dass das vom Hoster vorgegebene Limit von Uploads per PHP-Funktionen – 8 MB – zu klein war (meine Podcast-Audiodateien sind bei Weitem größer). Auf der Medien-Upload-Seite in WordPress nervte schon die warnende Fußzeile „Maximale Dateigröße für Upload: 8 MB.“ Auf die php.ini meines Webpacks habe ich keinen Zugriff, somit konnte ich so ohne Weiteres dieses Limit nicht erhöhen.

Aber es gibt eine einfache Lösung, wie man dieses Limit aushebeln kann: wieder einmal htaccess. Man schreibt einfach eine Datei „.htaccess“ mit folgendem Inhalt:

<IfModule php5_module>
php_value upload_max_filesize 60M
php_value post_max_size 60M
php_value max_execution_time 1200
php_value max_input_time 1200
</IfModule>

Diese .htaccess lädt man dann per FTP in das WordPress-Unterverzeichnis „wp-admin“ hoch, und schon ist das Upload-Limit auf 60 MB heraufgesetzt. Außerdem hat man nun 1.200 Sekunden (20 Minuten) Zeit für den Upload größerer Dateien. Natürlich könnte ich vorab große Audiofiles auch per FTP uploaden und den entsprechenden Path dann im Blogbeitrag in WordPress einbinden. Aber is doch schöner so, nä?

Ich hoffe, dass Ihr Webhoster solche .htaccess-Spielchen ebenfalls zulässt. Wie ich hörte, funktioniert das nicht überall. Also: Ausprobieren.

Verzeichnisinhalte auf dem Webserver verstecken

Heute mal ein Thema aus der Kategorie „Wie war das nochmal?“ – es gibt halt Dinge, die macht man nicht jeden Tag und muss man immer wieder nachlesen. Und jetzt auch wieder sowas. Wovon spricht der Mann? Also: Häufig stößt man beim Surfen auf Webseiten, bei denen eine HTML-Seite nicht mehr vorhanden ist und stattdessen die Dateien eines Ordners auf dem Webserver angezeigt werden. Das ist nicht nur unprofessionell, sondern möglicherweise auch eine Sicherheitslücke, denn die Inhalte der angezeigten Dateien können u. U. viel über die Server- und Websitekonfiguration verraten (insbesondere bei PHP-basierten Sites).

Verzeichnis des Webservers

Sowas sollte man NIE sehen können!

Wenn ich also einen Unterordner auf einem Server à la „http://www.ihredomain.de/verzeichnis“ ansurfe, in dem z. B. keine index.html liegt, kann es passieren, dass mir die Dateien angezeigt werden, die in diesem Verzeichnis liegen. Da hat sich der Administrator wohl wenig um Sicherheit gekümmert – oder schlicht und einfach gepennt. Wie kann man das also verhindern? Mehrere Möglichkeiten:

1. Wenn man selber den Webserver betreibt (bei mir ein Apache2 unter Linux), trägt man in der Konfigurationsdatei des Apache – früher war das mal „httpd.conf“, in aktuellen Distris findet man diese meist als „/etc/apache2/sites-available/default“ – Folgendes ein:

<Directory „/var/www“>
Options -Indexes
Order allow,deny
Allow from all

</Directory>

Wenn man nach einem Apache-Neustart o. g. Ordner ansurft, erhält man eine Fehlermeldung „403 – Forbidden“. Dies betrifft übrigens alle Ordner der Website, in denen keine index.html o. ä. vorhanden ist. Für einzelne Ordner kann man, so gewünscht, diesen Zugriff wieder einschalten, z. B. für einen Downloadordner:

<Directory „/var/www/downloads“>
Options +Indexes
Order allow,deny
Allow from all
</Directory>

2. Diese Möglichkeit habe ich eigentlich schon verraten: wenn in einem Verzeichnis keine index.html vorhanden ist, legt man dort ganz einfach eine solche ab. Diese kann auch leer sein. Ruft man mit dem Browser ein solches Verzeichnis auf, erscheint schlicht eine weiße Seite – eben die leere index.html. Das ist natürlich nicht sehr benutzerfreundlich, denn der geneigte User weiß nicht, warum er nur eine leere Seite bekommt. Daher sollte in dieser index.html z. B. drinstehen, warum hier nichts angezeigt wird. Oder man leitet per Meta-Refresh gleich auf die Startseite weiter.

3. Legen Sie in das Hauptverzeichnis Ihres Webservers eine Datei .htaccess ab und schreiben Sie in diese folgende Zeile hinein: Options -Indexes Dies hat den selben Effekt wie unter Punkt 1 beschrieben: in sämtlichen Unterverzeichnissen werden keine Dateien im Browser mehr angezeigt (Spezialisten wissen, wie man auch hier mittels .htaccess-Steuerung gleich auf die Startseite weiterleitet). Ausnahmen mit Verzeichnis-Zugriffserlaubnis kann man im jeweiligen Ordner einrichten, wenn man dort eine eigene .htaccess-Datei speichert und dort die Zeile Oprion +Indexes hinzufügt. Voraussetzung ist natürlich, dass Ihr Webserver (oder Ihr Hoster) .htaccess unterstützt. Wie man .htaccess – so denn notwendig – auf dem Apache2 aktiviert, habe ich in einem früheren Beitrag schon einmal beschrieben. Wenn man es nun noch ein wenig weitertreibt, kann man sich auch noch eine schicke Standard-Fehlermeldung-403-Seite basteln.

Grub2 passend machen (oder reparieren)

Mir passiert es immer wieder, dass bei Testinstallationen und LiveCDs verschiedener Linux-Distributionen (LinuxMint 15 und 16, ubuntu 13.04 und 13.10) insbesondere bei Notebooks nach dem Start aus dem Grub2-Menü der Bildschirm schwarz (also richtig dunkel) wird und das ganze System festhängt – es bleibt nur noch langes Drücken auf den PowerOff-Knopf. Grund ist, dass der Kernel beim Initialisieren der Grafik verschiedene Auflösungen „ausprobiert“, was bei manchen Grafikchips dann eben schief geht. Über den Recovery-Modus kann man das System in der Regel aber immer noch irgendwie starten, was ja aber keine Dauerlösung sein kann.

Hier gibt es zwei Lösungsschritte. Man kann versuchen, mittels Grub dem Linux-Kernel den Startparameter „nomodeset“ auf den Weg zu geben. Wenn man also das Grub-Startmenü vor sich sieht und auf dem ersten Listeneintrag steht, drückt man ‚e‘, um den Menüeintrag zu editieren. Nun fügt man in der Zeile mit „splash quiet“ das besagte „nomodeset“ hinzu. Jetzt drückt man Strg-X oder F10, um mit den geänderten Parametern das Betriebssystem zu starten. Jetzt sollte das Starten in den Grafikmodus zum Login-Bildschirm funktionieren.

Nun wäre es natürlich lästig, jedesmal in Grub herumzueditieren, wenn man sein ubuntu oder LinuxMint hochfahren will. Den besagten Parameter „nomodeset“ muss noch dauerhaft in Grub2 gespeichert werden. Und das macht man so:

Man öffnet mit root-Rechten die Datei /etc/default/grub – ob mit „sudo nano“ im Terminal oder mit gedit, überlasse ich dem geneigten User. In dieser Datei sucht man dann die Zeile ‚“GRUB_CMDLINE_LINUX_DEFAULT=“quiet splash“‚ und schreibt hinter dem „splash“ noch „nomodeset“. Die ganze Zeile sollte also so aussehen:

GRUB_CMDLINE_LINUX_DEFAULT=“quiet splash nomodeset“

Nun diese Datei speichern. Damit Grub2 diese Änderung auch annimmt, schießt man im Terminal noch ein „sudo update-grub“ ab.

Nach einem Neustart wird der Listeneintrag im Grub-Menü wie gewünscht funktionieren. Übrigens kann man in der Datei /etc/default/grub sein Startmenü auch optisch noch ein wenig aufhübschen (Auflösung, Hintergrundfarbe). Mehr dazu hier.

IPv6 und Firefox unter Linux

Ich habe auf einem neuen Notebook ein frisches LinuxMint 15 aufgesetzt und verschiedene Browser eingespielt, wie man das so als Webdeveloper macht. Ich habe in meinem Intranet eine Webseite, auf der angezeigt wird, ob man mit IPv4 oder IPv6 ankommt (auch hier auf der Blogseite unten links gibt es sowas). Nun fiel mir auf, dass der Firefox mir an der Stelle ansagt, ich käme lediglich mit IPv4 an. Die anderen Browser (SRWIron, Opera) zeigten mir hingegen an: alles ok mit IPv6. Wat is dat dann???

Die Lösung: bei der Firefox-Installation in Linuxmint ist standardmäßig die Suche nach einem IPv6-DNS abgeschaltet – warum auch immer. Ändern kann man das wie folgt: in der Adresszeile vom FF „about:config“ eingeben. Die Warnung „Hier erlischt eventuell die Garantie“ ignorieren wir geflissentlich. Nun geben wir in der Suchzeile den Begriff „ipv6“ ein. Nun landen wir auf einer einzigen Zeile „network.dns.disableIPv6“. Der Wert steht mit Sicherheit auf „true“. Doppelklick drauf – dann steht der Wert auf „false“. Browser neu starten – und nun kann der Feuerfuchs auch IPv6. Echt jetzt!

Älteres jQuery, fadeIn/fadeOut und der Internet Explorer

Kinners, nee! Was habe ich mich heute mal wieder über den Internet Explorer geärgert! Aber was soll man machen – es gibt ja immer noch unbedarfte Mitmenschen, die nur diesen so genannten Browser kennen, und auf die muss man auch eingehen. Und das kostet – vor allem Zeit.

Was ist passiert? Ich arbeite mitunter gern mal mit den Animationsfunktionen der JavaScript-Bibliothek jQuery. So habe ich schon vor fast einem Jahr für eine Freundin eine Seite gebastelt, in der unsere gemeinsamen Urlaubsfotos in Form einer Diashow mit Überblendeffekten ablaufen sollten. jQuery-Funktionen der Wahl waren ‚fadeIn‘ und ‚fadeOut‘. Hat auch alles wunderbar funktioniert – einmal mit Opera, Firefox und Co. getestet, der Freundin den „geheimen“ Link geschickt zum Anschauen – abgehakt und vergessen. War ja nur für uns so …

Nun habe ich dieser Tage eine Seite für ein etwas größeres Publikum entwickelt, in der ich eine ähnliche Diashow meinen Vereinsfreunden präsentieren wollte. Und da ich das Rad nicht neu erfinden wollte, habe ich eben besagte Webseite von damals als Vorlage genommen. Hat auch alles soweit funktioniert – bis ich dann mal auf die glorreiche Idee kam, auch mal mit dem Internet Explorer draufzusehen. Und erst da sah ich: im IE blendet nichts über – die Bilder werden einfach nacheinander übereinander gelegt. Ganz normale IE-Bugs eben :-/

Ich habe dann eine Reihe von CSS-Workarounds ausprobiert mit „filter:inherit“, „opacity: inherit“, mit verschachtelten divs als nachzuladendem Hintergrundbild usw. Krampf eben. Dabei ist die Lösung soooooo einfach:

Ich benutzte vor einem Jahr die jQuery-Version 1.2.6, die solche typischen Fehler im Internet Explorer noch nicht berücksichtigte. Ich habe dann eine etwas neuere Version eingespielt (1.7.2) – im HTML-Code im <head>-Bereich entsprechend angepasst, und siehe da: jetzt spielt auch der zickige IE die Diashows flüssig ab – siehe http://meikelcam.bplaced.net/dk7lj .

Scannen mit Gimp 2.8 unter Linux

Schon seit Ewigkeiten scanne ich mit einem All-in-one-WLAN-Scanner/-Drucker mit dem ubuntu-Tool „Simple Scan“, um das so entstandene Bild anschließend mit Gimp zu bearbeiten. Nun wollte ich mir diesen einen Zwischenschritt sparen – es muss doch möglich sein, direkt in Gimp zu scannen.

Geht natürlich. Mit Sane bzw xsaneimage. Falls noch nicht geschehen, mit dem entsprechenden Installationstool nachinstallieren (synaptic oder sudo apt-get install sane). Zunächst überprüft man mit scanimage –list-device, ob der Scanner korrekt im System vorhanden und erreichbar ist. Da sollte dann etwa sowas in der Art rauskommen wie „device ‚hpaio:/net/Deskjet_3050_J610_series?zc=HP025B5A‘ is a Hewlett-Packard Deskjet_3050_J610_series all-in-one“ – oder so ähnlich.

Nun erzeugt man im Verzeichnis „~/.gimp-2.8/plug-ins“ einen Symlink mit ln -s /usr/bin/xscanimage xscanimage .

Gimp - Scannen mit xscanimage (Sane)

Jetzt kann man endlich in Gimp scannen, und zwar über „Datei > Erstellen > xscanimage > Device Dialog…“ (vorher sollte man natürlich mit „Neu…“ eine neue Bildfläche erstellen). Hier öffnet sich dann der xscanimage-Dialog mit den Voreinstellungen und der Scan-Vorschau. Das Ergebnis lässt sich hier dann als XCF oder jedem beliebigen anderen Bildformat speichern.

Java-Plugin für alle Browser in ubuntu 13.04

Hin und wieder besuche ich immer wieder mal Webseiten, die ein Java-Plugin benötigen (z. B. das Online-Magnetometer DK0WCY in Scheggerott). In ubuntu-Linux hatte jedoch keiner meiner benutzten Browser – als da wären Epiphany, Opera, SRW Iron und Firefox – ein Java-Plugin aktiviert. Nun wusste ich aus früheren Versionen, dass man da z. T. mit lib*.so-Dateien in verschiedenen Verzeichnissen hantieren musste, die sich bei Updates auch immer wieder mal änderten.

Das ist nun vorbei. Standardmäßig ist bei ubuntu13.04 OpenJDK 6 (weitestgehend kompatibel mit Sun-Java JRE 7) bereits an Bord, nur das jeweilige Browser-Plugin (icedtea6) fehlte. Diesen habe ich nachinstalliert wie folgt:

sudo apt-get install openjdk-6-jre icedtea6-plugin

Danach funktionierten Java-Applets in all meinen Browsern.

Über die Diskussion rund um immer wieder auftretende Sicherheitslücken der Java-Plugins will ich mich an dieser Stelle nicht auslassen 😉

Rauschen in Fotos entfernen mit Photoshop CS5

Wer kennt das nicht? Da hat jemand mit einem Fotohandy ohne Blitz abends in der Kneipe ein paar gelungene Schnappschüsse gemacht. Was massiv stört ist das gewaltige Farbrauschen insbesondere in den dunklen Bereichen der Bilder. Ich habe heute einen Weg gefunden, wie man solche Bilder mit Photoshop ansehnlich zurechtzaubert, und zwar ohne die gängigen Filter, die man so kennt.

Camera Raw - DetailsDas Zauberwort lautet Camera Raw. Nun könnte man meinen, das sei ein Werkzeug ausschließlich für hochprofessionelle Kameras mit Fotos im Raw-Format, aber man kann Camera Raw auch für einfache JPG-Bilder nutzen.

Nachdem man Photoshop (ab CS5) gestartet hat, öffnet man das verrauschte Bild unter „Datei – Öffnen als…“ (Tasten-Shortcut „Alt-Shift-Strg-O“). Wichtig: unten unter „Öffnen als…“ aus der Liste „Camera Raw“ auswählen.

Nun öffnet sich das Bild mit einem Bedienfeld rechts. Hier schauen wir uns „Details“ an. Die zwei wichtigsten Regler sind „Farbe“ und „Luminanz“. Die ziehen wir als erstes ganz nach rechts auf 100 %. Die grandiose Bildverbesserung wird sofort augenscheinlich! Nun kann man auch noch ein wenig mit den anderen Reglern unter „Rauschreduzierung“ vorsichtig spielen – aber Achtung: z. B. bei zuviel Luminanzkontrast kann man auch wieder Rauschen hinzufügen!

Schaden kann es nicht, sobald man mit dem Ergebnis zufrieden ist, darüber unter „Schärfen“ den Betrag etwa auf 70 zu stellen. Zum Schluss kann es noch Wunder wirken, wenn man oben auf den Reiter „Grundeinstellungen“ geht (das Symbol ganz links in der Leiste mit der Kamerablende) und den Regler „Klarheit“ ins rechte Drittel bewegt.

Ich habe auf die Art die pixeligen Hochzeitsbilder retten können, die ein Freund im Standesamt mit einem 50-Euro-Apparat gemacht hat.

Ein hervorragendes Video-Tutorial zu diesem Thema gibt es hier.

Apache und .htaccess auf dem Raspberry Pi

Ich habe auf meinem Raspberry Pi einen Apache2 laufen, der auch meistens per WLAN über den Router ans Netz angebunden ist. Nun ist der Apache in der Standardinstallation eine höchst unsichere Kiste. Verzeichnisse unter /var/www sind offen einsehbar, was natürlich nicht so lustig ist. Also ist hier das Anlegen einer .htaccess-Datei die erste Wahl. Dazu muss die Nutzung der .htaccess erst einmal aktiviert werden.

Man öffnet dazu mit nano, vi oder dem Editor Ihrer Wahl die Datei ‚/etc/apache2/sites-available/default‘. Dort findet man eine Zeile „AllowOverride None“. Die ändert man zu „AllowOverride All“. Zu beachten ist hier, dass man diese Zeile mehrfach findet. Wir bearbeiten hier den Bereich „<Directory /var/www“.

Jetzt können wir im Web-Hauptverzeichnis eine leere Datei .htaccess anlegen. Um Verzeichnisse unsichtbar zu machen (403 – Forbidden), schreiben wir die Zeile „Options -Indexes“ hinein.

Jetzt die Änderungen speichern und den Apache neu starten (sudo service apache2 restart). Ab jetzt sind die Dateien in den Unterverzeichnissen mit dem Browser nicht mehr einsehbar.

Eine nette Übersicht aller .htaccess-Funktionen auf Deutsch findet man unter http://www.trash.net/faq/htaccess.shtml .

PuTTY und der Ziffernblock

Wenn ich mal mit Windows 7 arbeite (kommt selten genug vor 😉 ) und per SSH auf meinen Raspberry Pi zugreifen möchte, nutze ich PuTTY. Seit langem ärgert es mich ein wenig, dass ich auf dem Ziffernblock der Tastatur keine Ziffern im Terminalfenster erhalte, sondern die alternativen Steuerzeichen (so als ob NumLock off wäre).

Abhilfe ist ganz einfach: in den PuTTY-Einstellungen unter „Terminal > Features“ die Option „Disable Application Keypad mode“ aktivieren. Am besten gleich diese Änderung unter „Session“ bei den Saved Sessions dauerhaft speichern.

Dann klappts auch mit den Zahlen.