Beiträge von KB19

    Hier auch kein Super Sonderzeichen zu sehen, welches die Speicherung in die Tabelle unterbrechen sollte.

    Womit schaust Du Dir das an? Ich denke da nämlich an unsichtbare (Unicode) Steuerzeichen. Die zeigt nicht jeder Editor an. Manche auch nur, wenn man sie explizit so konfiguriert. Zur Sicherheit den ganzen String mal unverändert 1:1 mit PHP in einer Datei abspeichern, dann mit einem Hex-Editor öffnen und zur Problemstelle scrollen.

    Wenn man ewig ein IMAP/TLS Problem einer Webanwendung debuggt…

    AUF PORT 995! :pinch:

    Mit POP3 habe ich es natürlich auch probiert…

    AUF PORT 993! :wacko:

    Aber es geht weiter: Dann nimmt man zum Test mal den Mailserver vom Webhosting…

    MIT DEM HOSTNAMEN MXXXXX.WEBHOSTING.SYSTEMS! :pinch:

    Um dann endlich zu bemerken, dass da ein kleiner Unterschied ist…

    ZUM RICHTIGEN HOSTNAMEN MXXXXX.NETCUP.NET! :wacko:

    Um dann endlich zu bemerken, dass man die ganze Zeit die IMAP/POP3 TLS-Ports verwechselt.

    Ende. PC aus. :sleeping:

    Zitat

    […] informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail.

    Ok, ich schreibe dem Absender, dass ich nicht der Empfänger bin. Die Mail aus dem Posteingang lösche ich natürlich sofort.

    Ups, jetzt ist die Mail aber als Zitat in meinen gesendeten Objekten für alle Ewigkeiten archiviert… :S

    m_ueberall Du kannst stattdessen auch gleich APT-Pinning verwenden. Bei Updates von bereits installierten Paketen ist das afaik nicht mehr explizit notwendig, es ist aber trotzdem ganz praktisch und meiner Meinung nach übersichtlicher.

    https://wiki.debian.org/de/AptPreferences#Pinning

    Und sei vorsichtig, ob die Pakete in Backports wirklich zeitnah Updates bekommen, vor allem auf Security-Fixes bezogen. Mit LTS ist sowieso Schluss bei Backports, aber teilweise musste ich feststellen, dass die Pakete auch während der Oldstable-Zeit etwas lieblos behandelt werden.

    bei allen anderen Dingen geht kein Überbuchen

    Warum? Bezogen auf die HDD der VMs geht das definitiv schon und ist bei ordentlichem Monitoring prinzipiell kein Problem. Solange eine handvoll Kunden mit ihren Produkten nicht alles innerhalb weniger Minuten belegen können, sehe ich da kein Problem. Selbst beim RAM könnte man spekulieren, dass niemals 100% aller VMs gestartet sind. Notfalls migriert man sie beim Start halt auf einen anderen Host.

    Spoiler anzeigen

    Optimierung der HDD, (afaik) fstrim als Cronjob in den Images, … – ich wage mal zu behaupten, dass man das nicht nur wegen der Performance oder für die Snapshots macht. Die günstigen Preise schafft man wohl kaum, wenn man 100% aller Ressourcen fix für jeden Kunden brach liegen lässt ;)

    Ob es so zum Einsatz kommt, ist eine andere Frage. Ist mir ehrlich gesagt aber auch egal. Solange ich als Kunde keinen Nachteil dadurch habe und meine vereinbarte Leistung erhalte, darf jedes Unternehmen intern gerne so kalkulieren und arbeiten, wie es das für richtig hält. :thumbup:

    Ich würde mal schätzen, dass "überbuchte" Ressourcen nicht mehrfach eingerechnet sind. ;)

    Also wirklich nur das, was physisch zur Verfügung steht oder eventuell sogar benutzt wird. Oder was einer VM zugewiesen ist. Die Webhostingsysteme sind ja auch nur VM-Gäste auf KVM-Hostsystemen.

    Mit dem 5-Byte Index dürfte die Tabelle jetzt auf ca. 33GB Speicherplatzbedarf kommen.

    Letztes Update zu dieser Geschichte: Nur noch 22GB mit ROW_FORMAT=COMPRESSED 8o (Index auf 50%, Rest auf 75% geschrumpft)

    Statt teilweise 100 Millisekunden am VPS braucht der DB-Server am RS übrigens nur noch maximal 5 Millisekunden, um einen Hashwert zu prüfen.

    SQL
    CREATE TABLE `passwords` (
      `hash` binary(20) NOT NULL,
      KEY `5b` (`hash`(5))
    ) ENGINE=InnoDB DEFAULT CHARSET=ascii COLLATE=ascii_bin ROW_FORMAT=COMPRESSED COMMENT='v5'

    Das Ding läuft nun deutlich schneller, da nur alle 100k Zeilen ein COMMIT erfolgt. Normalerweise schafft der Import nur ca. 1k Zeilen pro Sekunde, jetzt sind es auf dem gleichen System ca. 6k Zeilen pro Sekunde. Mit dem netten Nebeneffekt, dass die I/O-Last beim Import deutlich gesunken ist, obwohl bereits ein Index existiert! (Nur 20-30 IOPS anstatt über 2k.)

    Ich habe die HIBP-PW-DB-v5 jetzt mal auf meinen richtigen DB-Server (RS Spring 2019) verschoben: Der Import des SQL-Dumps läuft dort mit 27-70k Datensätzen pro Sekunde :love: :thumbup:

    Mit dem 5-Byte Index dürfte die Tabelle jetzt auf ca. 33GB Speicherplatzbedarf kommen. Die DB ist aber von der Replikation ausgenommen. Wenn die weg ist, kann ich sie ja leicht neu erstellen lassen.

    Und bedenke, dass die geänderten DNS-Einträge erst dann "live" sind, wenn bei der Gültig-Spalte YES steht. Erst dann wurde die Zone neu geladen.

    Danach kann es je nach eingestellter TTL nochmals 24-48 Stunden dauern, bis sich der neue Eintrag weltweit rumgesprochen hat.

    Sobald ich einen anderen path angebe, bekomme ich einen Error, da dies anscheinend nicht erlaubt ist.

    Und der wäre? Der Pfad muss logischerweise innerhalb Deiner gewählten open_basedir Einstellung liegen.

    Bei mir funktioniert dieses Beispiel einwandfrei: https://wh-nclabs.fnx.li/session-test/ (Quellcode; Wayback Machine)

    Zum Löschen der alten Sessions sollte sich z.B. folgendes Bashscript als Cronjob eignen, das ist aber ungetestet!

    Bash
    #!/bin/bash
    
    # Nach frühestens 61 Minuten werden alte Sessiondateien gelöscht...
    # Wenn Du es erst einmal nur testen willst, ersetze -delete durch -print.
    find /path/to/your/sessions/ -maxdepth 1 -type f -name 'sess_*' -mmin +61 -delete
    
    exit $?

    Wegen solch bekloppten Dingen mag ich NGINX:

    Ich habe mir erst kürzlich gedacht: Ich probiere halt mal wieder Lighttpd aus für ein bestimmtes Mini-Setup. Den habe ich seit 5-8 Jahren nicht mehr verwendet. Warum eigentlich, der ist doch auch ulkig und mächtig? :/

    Nach 2-3 Stunden habe ich genervt aufgegeben und Nginx genommen. Ich glaube ich weiß wieder, warum ich Lighttpd (und Apache) irgendwann auf meinen Systemen ausgemustert habe :D