Kategorie: Informatik

Fehlermeldung

Bei der Installation einer meiner Anwendungen bin ich auf die folgende Fehlermeldung gestoßen:

PDOStatement: Specified key was too long; max key length is 767 bytes

Lag schlussendlich daran, dass meine Standartkodierung der Datenbank utf8mb4 war, und ich bei dieser Kodierung andere Limits habe, als unter utf8. Das ist im Nachhinein auch logisch.

Die Erklärung fand ich in diesem Stackoverflow-Thread.

When you hit the limit. Set the following.

  • INNODB utf8VARCHAR(255)
  • INNODB utf8mb4VARCHAR(191)

Anschließend habe ich mich ein wenig mit utf8 beschäftigt, um den genauen unterschied zwischen utf8_general_ci utf8_binary und utf8_unicode_ci herauszufinden.

Die Antwort dafür ist hier:

In general, utf8_general_ci is faster than utf8_unicode_ci, but less correct.

Here is the difference:

For any Unicode character set, operations performed using the _general_ci collation are faster than those for the _unicode_ci collation. For example, comparisons for the utf8_general_ci collation are faster, but slightly less correct, than comparisons for utf8_unicode_ci. The reason for this is that utf8_unicode_ci supports mappings such as expansions; that is, when one character compares as equal to combinations of other characters. For example, in German and some other languages “ß” is equal to “ss”. utf8_unicode_ci also supports contractions and ignorable characters. utf8_general_ci is a legacy collation that does not support expansions, contractions, or ignorable characters. It can make only one-to-one comparisons between characters.

Quoted from: http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html

For more detailed explanation, please read the following post from MySQL forums: http://forums.mysql.com/read.php?103,187048,188748

As for utf8_bin: Both utf8_general_ci and utf8_unicode_ci perform case-insensitive comparison. In constrast, utf8_bin is case-sensitive (among other differences), because it compares the binary values of the characters.

Entwicklung eines eigenen „CMS“

In diesem Post werde ich ein wenig über mein eigenes „CMS“ schreiben. Ja, trotz zahlreicher Meinungen, die gegen eigene CMS-Lösungen sprechen, habe ich beschlossen, ein eigenes System aufzustellen.

Warum?
Ich nutze selber ziemlich gerne WordPress und Joomla, habe für beide auch (einfache) Componenten/Plugins entwickelt. Genau genommen, basiert Proxer bekanntlich auf Joomla und alles außer das Forum sind selbstentwickelte Komponenten. Dennoch habe ich im Laufe der Zeit festgestellt, dass ich von Systemen wie WordPress und Joomla nur sehr weniges brauche und dass die Kosten für die „unbenutzten“ Elemente dieser Systeme zu hoch sind. Ich bin ein minimalistischer Mensch: Ich möchte nicht mehr haben, als ich brauche.
Was ich für mein CMS alles brauche:

  • Datenbankverwaltung
  • Benutzerverwaltung
  • Sessionverwaltung
  • Unterschiedliche Schnittstellen für Seite, Administration und API
  • Templates für Seite und Administration
  • Model/View/Controller-Ähnliche Architektur für alle Schnittstellen

Da diese Sachen ziemlich einfache Sachen sind, hatte ich auch in einem Tag mein „CMS“ zur Hand. Verwendet habe ich ein Framework namens „Fatfree“, welches meine Anforderungen perfekt erfüllt hat. Ich kann benötigte Funktionen (z.B. ein Blogsystem) jederzeit Entwickeln und dranschalten. Besonders erfreulich ist für mich die API-Schnittstelle: Hiermit möchte ich zukünftig viele tolle neue Anwendungen basteln 🙂

Proxer Serverumzug 10.08.17

In diesem Sommer haben sich ein zwei Probleme auf Proxer angehäuft:

  • Der Speicher vom Datenbank-Server ist voll
  • Es gibt eine neue Debian-Version

Aus diesem Grund habe ich beschlossen, neue Server zu bestellen und mal eine vollständige Neuinstallation der zwei Hauptserver durchzuführen. Ich habe mich für den folgenden Server für Proxer entschieden:

Fujitsu PRIMERGY RX2510 M2 1U Rack
2x Intel Xeon E5-2620v4 2.4GHz
32GB ECC DDR4 RAM
Drive 1 :240GB SSD
Drive 2 :1TB HDD
Drive 3: 1TB HDD

Auf der SSD läuft das Betriebssystem, die 2 HDDs sind in einem Raid 1-Verbund (Hardware) und dienen dazu, regelmäßig die Backups zwischenzuspeichern, aber auch um größere Daten zu lagern, die immer wieder mal auftreten.

Welche Software kommt bei diesen Proxer-Servern ins Spiel?

  • nginx + php: Für den Webserver
  • htop, iftop, vnstat, screen: kleinere Tools
  • rsync: Zum Synchronisieren von Daten mit dem Backup-Server
  • git: Versionsverwaltung
  • munin-node: Monitoring
  • mysql-server: Für die Datenbank.
  • gd3: Bildverarbeitung.
  • zip, unzip: (Ent-)Packen von Zip-Dateien.

Um keine Angriffsfläche zu bieten, ist es von Nöten, dass man den Server möglichst minimal belässt. Die oben genannten Pakete inklusive der bereits bei Debian 9 enthaltenen Pakete (und abhängige) reichen für Proxer vollkommen aus. Alles weitere findet auf der Webserver-Anwendungsebene statt, die im Grunde durch das Deaktivieren vieler PHP-Funktionen wie eine Sandbox ist. Meine Techniker-Kollegen beschweren sich deswegen, weil ich für Git beispielsweise aus diesem Grund keine Web-Oberfläche zur Verfügung stellen kann, mit der sie bei Änderungen einfach git-pull machen können 😀 Die Sicherheit wiegt für mich jedoch an dieser Stelle mehr als der Nutzen einer PHP-Funktion, die Systemfunktionen ausführen kann.

Durch den Wechsel auf Debian 9 (Stretch) kamen ein paar Änderungen. Seit heute nutzt Proxer nicht mehr Mysql, sondern MariaDB. Es sollte keine große Änderung darstellen, ich bin gespannt, wie sich der Wechsel auf die Performance auswirken wird.

Am Meisten Zeit nimmt das Einspielen des Datenbank-Dumpes ein. Dies ist 35GB groß und nimmt eingespielt unter Mysql um die 100GB an Speicherplatz ein (wegen den ganzen Indexen usw). Es gibt hier durchaus viel Freiraum für Verbesserungen, doch ich bekomme es noch nicht so richtig auf die Reihe aufgrund der großen Datenbank-Größe. Demnächst werde ich mal Optimierungsarbeiten daran durchführen.

Sonst ist es das gleiche Spiel: Konfigurationen prüfen, und in dem neuen Server einbauen. Es gibt bei neuen Betriebssystem-Versionen oft Änderungen an Einstellungen. Hier müssen ehemalige Änderungen nachgeschlagen werden. Gibt es eine Änderung des Variablennamen? Gibt es die Variable überhaupt? Gabs diesbezüglich intern Änderungen?

Alles in allem macht mir jeder Serverumzug sehr viel Spaß. Ich lerne mit der Zeit immer neues, und ich habe hier die Möglichkeit dieses Wissen sauber einzubauen.

Proxer Datenschutz

Wusstet ihr schon?
Wenn man auf Proxer registriert ist und die Proxer-Streams nutzt, dann werden KEINERLEI Daten an Dritte weitergeleitet. Wir blenden keine externe Werbung ein. Es macht also keinen Unterschied, ob man den Adblocker an hat oder aus. Es gibt keine „Premium“-Funktionen. Wir finanzieren unsere Streams größtenteils durch Spenden und der Werbung bei Gästen.
Ist das nicht irgendwie erfreulich? Wie viele andere Betreiber von Webseiten können das von sich behaupten?
 
Aus diesem Grund kann ich euch als Informatiker mit bestem Gewissen den folgenden Adblocker ans Herz legen: uBlock Origin für Chrome/Firefox. Damit könnt ihr euren Datenschutz auch außerhalb von Proxer gewährleisten 🙂