HOSTBLOGGER.de

Augen auf bei der Klammerung (beim Programmieren):

FreeBSD stopft Pufferüberlauf in wichtiger Systembibliothek

Ich predige es ja immer wieder: Auch bei einzeiligen Statements immer vollständige Klammerung!

if (irgendwas) { return false; };

Auch wenn das in diesem Fall eine zu triviale Betrachtung des obigen Problems ist, aber ein konsequentes Nutzen führt in meinen Augen zu weniger Problemen.

Blogleser Andreas fragte mich in einer persönlichen E-Mail, ob ich nicht vielleicht mal ein kleines Howto zur Verwendung von dm-crypt / LUKS posten möchte.

Ich bin heute mal faul und verweise auf das manitu Wiki:

Verschlüsseltes Device mit dm-crypt (cryptsetup, LUKS) anlegen

Ein kleiner Hinweis aus dem Maschinenraum. Wer seine upload_max_filesize in PHP auf 1G setzt, riskiert, dass Joomla daraus 1 MB macht.

Grund dafür ist dieser Code:

$max_upload_size = (int)ini_get('upload_max_filesize')

Besser ist es also, 1024M in der php.ini anzugeben.

Nachtrag 22.10.2014 08:45 Uhr
Der Bug ist in der Datei com_attachments/helper.php eines Add-On.

Wer bei mod_auth_mysql auch Probleme mit Fehlern wie

MySQL ERROR: MySQL server has gone away

oder

MySQL ERROR: Lost connection to MySQL server

hat, sollte möglicherweise auf Prefork statt auf Worker als Apache-MPM setzen.

Zumindest unter Gentoo hilft's

Ein Kunde, den ich persönlich kenne, hatte um eine kleine Hilfestellung gefragt, er kam bei einem Problem nicht weiter. Einziges System: Unerklärliche Permission denied-Meldungen.

Ein kleiner Blick auf die Rechte von / zeigte, dass da die Ausführungs-Rechte gefehlt haben. Ein chmod +x und alles war wieder in Butter - und der Kunde überrascht bis glücklich.

Wenn man nicht gerade erfahren ist, sucht man sich da wirklich bis zum Apfelkörbchen

Seit gestern sind manitu.de und hostblogger.de nur noch via https erreichbar. Den passenden HSTS-Header haben wir natürlich auch gesetzt.

Wer es nachmachen möchte, hier ein passender Ausschnitt für eine .htaccess-Datei:

<IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] </IfModule> <IfModule mod_headers.c> Header always set Strict-Transport-Security "max-age=86400;" </IfModule>

Wer den HSTS-Header auch für Subdomains möchte:

Header always set Strict-Transport-Security "max-age=86400; includeSubDomains"

Nachtrag 12:51 Uhr
Ich habe soeben alle Links zu manitu.de in diesem Blog auf https:// korrigiert.

Abuse-Meldungen als HTML-E-Mail zu verschicken, mag ja für den Versender auf den ersten Blick hilfreich sein - vor allem, wenn er/sie sich die Arbeit macht, relevante Passagen farblich (ja in rosa!) hervorzuheben.

Allerdings erschwert es vermutlich den meisten Abuse-Desks die Arbeit - vor allem macht es eine automatische Vor-Verarbeitung je nach HTML-Formatierung praktisch unmöglich. Da darf der Absender sich dann nicht wundern, wenn es etwas länger dauert :-/

Kleine Meldung aus dem Maschinenraum: Seit heute gibt es bei uns im Webhosting zwei aktualisierte "1-Klick-Anwendungen":

• WordPress in Version 3.9.2 (deutsch und englisch)
• ownCloud in Version 7.0.1.1 (mehrsprachig)

Ein erneutes Update: Davon ausgehend, dass sich der E-Mail-Abruf und -Versand weiterhin relativ konstant verhält, haben weitere 10% der von uns angeschriebenen Kunden (genauer: Postfächer ) auf verschlüsselten Abruf bzw. Versand umgestellt.

Ich fürchte allerdings, dass es nicht jeden Tag 10% weniger werden

Ab heute werden auch unsere Mailings, z.B. bei Wartungsankündigungen, Störungen oder Hinweisen, signiert.

Soweit ich das sehen kann, fehlt nun praktisch nichts mehr - wir werden das aber sicherheitshalber nochmals überprüfen.

Mal eine Frage in den Raum: Wer von Euch nutzte seinerzeit truecrypt unter Linux bzw. nutzt es immer noch? Was waren Eure Beweggründe? Was sprach gegen das bordeigene dm-crypt?

Ein kleines Update: Davon ausgehend, dass sich der E-Mail-Abruf und -Versand halbwegs konstant verhält, haben bereits 20% der von uns angeschriebenen Kunden (genauer: Postfächer ) auf verschlüsselten Abruf bzw. Versand umgestellt.

Wow Damit hätte ich nach nur 24 Stunden nicht gerechnet. Und selbst, wenn die obige Annahme nicht stimmt, und es nur 10% wären, wäre das ein Erfolg!

Ab heute beginnen wir damit, unsere Webhosting-Kunden aktiv darum zu bitten, zum Versenden und Abrufen von E-Mails nur noch verschlüsselte Verbindungen zu verwenden. Ein entsprechendes Mailing ist heute an die Kunden rausgegangen (technisch bedingt können wir dazu nur auf den heutigen Datenbestand an Logfiles zugreifen).

Wir werden uns die Entwicklung anschauen und (vermutlich) weitere Mailings hinterherschicken, optimalerweise bis kaum jemand mehr unverschlüsselte Verbindungen nutzt. Erst dann werden wir wirklich hart "deaktivieren". Einen fixen Zeitpunkt haben wir uns bewusst nicht vorgenommen - eben um hier unsere Kunden nicht zu bedrängen.

Ab sofort werden bei uns (fast) alle (ausgehenden) E-Mails standardmäßig GnuPG-signiert. Das "fast" bezieht sich dabei auf einen minimalen Teil unserer automatischen Systeme, die technisch bedingt noch angepasst werden müssen.

Eine standardmäßige Verschlüsselung der ausgehenden E-Mails steht folgerichtig auch in unserer To-Do-Liste, das wird aber - wie Ihr vermuten könnt - noch etwas längern dauern, da die Hürden bezogen auf die Anpassung diverser Systeme und Berechtigungen durchaus größer sind.

Bevor ich es vergesse: Wer heute noch un-signierte E-Mails aus Vertrieb, Support oder Buchhaltung bekommen hat: Das war vor der Umstellung

AcceptEnv in OpenSSH ist 'was Feines - wenn man es gewollt hat und sich dessen bewusst ist.

Ansonsten wundert man sich, warum auf einem Server plötzlich deutsche Fehlerausgaben erscheinen, wobei doch unser interner Standard besagt, nur die englischen Locales zu haben