Beiträge von KB19

    Da upload_max_filesize & post_max_size auf PHP_INI_PERDIR stehen, sollte das problemlos möglich sein:

    Bedenke aber bitte, dass Du die maximale Uploadgröße Deines Tarifs nicht überschreiten kannst! Da wird der Webserver vorher wahrscheinlich abbrechen.

    allerdings finde ich keinen ordner /vserver in dem die daten eigentlich liegen sollten!?

    Wo auch immer Du das gefunden hast: Das war bei den alten Linux-VServer Produkte und nicht bei KVM so. Bei KVM kann man die virtuelle Festplatte komplett selbst verwalten (Partitionen/Dateisystem/Verschlüsselung/…), da wäre ein Automount im Rettungssystem gar nicht möglich. Bei Linux-VServer hingegen hatte man nur einen Ordner auf der Festplatte des Hostsystems.

    Ja, ich wollte nur (eigentlich) die geringste Downtime. Sprich: Snapshort machen, exportieren und importieren. Wollte nicht wieder bei 0 anfangen.

    Wozu vorher unnötigerweise neu installieren, wenn Du danach sowieso einen Snapshot importierst? Oder habe ich das falsch verstanden?

    Willst noch einen RS Ostern M OST21 - der wird bei mir frei xD

    Danke, kein (akuter) Bedarf. ^^

    Zu lange Laufzeit und zu viel RAM. Die Notreserve ist eh ein RS X-Mas 2016, der reicht für kleinere Spielereien. Notfalls wird ein VPS 200/500 spontan dazu geholt…

    Natürlich hat diese VM dann theoretisch Vollzugriff auf alle konfigurierten Systeme. Wobei man das mit einem eigenen SSH-User, weiteren Scripts und sudo entschärfen könnte. Habe ich bei mir aber nicht gemacht. Wenn mir jemand diese VM knackt, habe ich sowieso ganz andere Probleme.

    Steini Ich hatte jetzt doch erstmals echten Bedarf an so einer Lösung. Das Zielsystem ist nämlich ein Backupsystem, da will ich der VM doch nicht Vollzugriff geben…

    https://gist.github.com/24d4e82e6c00f70c4bc4870220c094c7

    Ist nur zur Inspiration gedacht, bitte selbst einen eigenen User und Keyfile anlegen. Dass letsencrypt.sh nur von root beschreibbar sein darf (genauso wie der Ordner!) sollte selbstverständlich sein. Ich habe solche sudo-Scripts normalerweise in /usr/local/sbin oder in /root liegen.

    Seit ca. Donnerstag habe ich eine deutliche Häufung von Abrufproblemen über IMAP bei GMX. Kann das zufällig noch jemand bestätigen?

    credential/login error (authentication failed)

    Das betrifft nicht nur einen GMX-Account.

    Wenn ich das richtig im Kopf habe, kann der Cache einem solche Tests ebenfalls vermiesen. Verwende beim SELECT unbedingt mal ein SQL_NO_CACHE. Und teste es keinesfalls mit einer Dummy-Tabelle, die nur ein paar Testeinträge enthält, da werden Indizes Dank dem Optimizer oft gar nicht verwendet.

    (Dass auch das Dateisystem theoretisch einen Cache hat, lasse ich mal außen vor. Das spielt bei SSDs eher eine untergeordnete Rolle.)

    Naja Handys sind ja tweilweise auch nutzlos Play Protec oder allgemein Konto Schutz (nach Reset nur gleiche Google Konto), dann noch die Sache mit Reset bei nicht entspeerten Boot Loader auch nicht das leichteste.

    Stimmt, auf diesen proprietären "Mist" habe ich an dieser Stelle nicht gedacht. Und das dürfte auf gefühlt 99% der User zutreffen.

    Wobei es dann mit den diversen Sicherheitslücken in irgendwelchen Hardware-Komponenten schnell wieder anders aussehen kann. Aber dieses Wissen wird der übliche Dieb oder dessen Hehler kaum haben? ^^

    mainziman Spätestens seit der Zwangsumstellung auf Debit-Karten gibt es aus technischer Sicht doch keine wirklichen Unterschiede mehr zu einer KK?

    Nein wieso, nach dem 3ten Fehlversuch ist sie dann dort eingezogen; und zwischen 2 Geldautomaten hin- und herzuwechseln, da würde ich meine Hand nicht ins Feuer legen, ob da nicht die Logik des Geldautomaten die Karte instant direkt einzieht ...

    Ich meinte, dass Du jeweils nach dem ersten Fehlversuch weiter ziehst und niemals das gleiche Gerät nochmals besuchst. Gerade in Großstädten ist das kein Problem, weil es genügend Kastln gibt. :D

    Aber ich muss zugeben, dass ich eine Sache nicht bedacht habe, da ich das Szenario von eingezogenen Karten nur von Anderen kenne: Die Karte ist dann ja nicht gesperrt/ungültig, wie es bei einer SIM-Karte der Fall wäre. Man bekommt somit keine neue ausgestellt, die wird einfach wieder ausgehändigt. Früher direkt bei der jeweiligen Bank, wo sie eingezogen wurde, mittlerweile wohl maximal noch über die eigene Filiale, meistens jedoch per Post.

    Insofern wäre ein Offline-Brute-Force Angriff mit der richtigen Hard-/Software wahrscheinlich wirklich kein Problem. Vorausgesetzt die Karten unterstützen Offline-PINs noch. Trotzdem bezweifle ich, dass der typische Handtaschlzieher über dieses Wissen verfügt oder überhaupt ein Interesse daran hat. Die meisten dieser Typen interessiert nur Bargeld und maximal ein (teures) Smartphone, die restlichen Beweismittel werden schnellstens entsorgt.

    es ist nun mittlerweile bereits ein paar Jahre her, ereignete sich so um 2018 herum; da wurde einer Frau in Wien in der Straßenbahn die Handtasche entwendet;

    und die Frau hatte damals alles richtig gemacht, sie ist nach dem sie dies bemerkte unverzüglich zur nächsten Filiale ihrer Bank gefahren und hat die Karten sperren lassen; Staub hatte dies in den Medien dahingehend aufgewirbelt, weil bis die Karten effektiv gesperrt waren, der Unbekannte in Summe an die 2000 EUR behoben hatte - der PIN Code war nicht mit in der Handtasche; und die Bank sich weigerte ihr den Schaden zu ersetzen; in Summe wurde bei der Berichterstattung zu dieser Causa die Konsumenten im Dunkeln gelassen;

    Behauptete sie halt, wer weiß, ob es stimmt? ;)

    (Und sie wäre strohdumm, wenn sie das Gegenteil zugeben würde.)

    Vielleicht wurde der PIN auch zuvor ausgespäht, durch Beobachten oder manipulierte Terminals?

    (Dass die Bank den Schaden trotzdem übernehmen müsste/sollte ist eine andere Geschichte. Da sind wir uns durchaus einig.)

    Ich habe meine Bankkarte sowieso fast nie mit. Genauso wenig wie einen Ausweis, da wir keine Ausweispflicht haben und die Polizei sowieso Meldedaten und Ausweisfoto direkt am Dienst-Smartphone abrufen kann. Was ich nicht bei mir habe, kann mir unterwegs nicht gestohlen werden. Ein versuchter Raubüberfall (mit Messer) reicht mir, bei dem zum Glück nichts entwendet wurde. Da brauche ich dann nicht auch noch an Ausweis-/Kartensperren zu denken und mich mit Neuaustellungen rumzuärgern.

    Von wie vielen Datensätzen sprechen wir hier eigentlich? Und wie groß sind Daten bzw. Index?

    Da Du sowieso immer (nur) id und ts im WHERE hast, sehe ich keinen Grund für einen weiteren Index. Das ist sowieso schon im primären Index enthalten. Anders würde es natürlich aussehen, wenn Du nur nach ts suchen willst, da der Index mit id anfängt und dadurch nicht verwendet werden kann. Wenn das aber nur bei phpMyAdmin der Fall ist und Du dort nicht jeden Tag ran musst, würde ich es bleiben lassen. Ob der Query in phpMyAdmin nun eine halbe oder drei Sekunden braucht, ist meiner Meinung nach kaum der Rede wert.

    ich weiß zwar nicht was Du mit EMV-Karten meinst […]

    https://de.wikipedia.org/wiki/Contact_EMV

    (Sollte derzeit etwas Anderes eingesetzt werden, bitte um Korrektur.)

    […]

    die Logik dass nach dem 3ten Fehlversuch die Bankomatkarte eingezogen wird, ist in den Geldautomaten implementiert, nicht in den Karten selbst;

    wobei hier die Frage: blockiert der Chip auf der Karte nach 3 Fehlversuchen und ist damit unwiderbringlich 'zerstört' od. bleibt sie intakt ...

    Bei SIM-Karten kümmert sich darum der Chip. Ohne (8-stelligen) PUK geht dann gar nichts mehr. Wie viele Falscheingaben der zulässt weiß ich ad-hoc nicht.

    Würde mich jedenfalls wundern, wenn das bei Bankkarten nicht ebenfalls direkt durch den Chip gelöst wurde. Sonst kann ich ja einfach zum nächsten Terminal gehen und es im Endeffekt unendlich probieren… (Gut, durch die Online-Anbindung in der Realität wahrscheinlich eher nicht.)

    […] dass sie immer noch einen Magnetstreifen haben, und dieser in einigen Regionen der Welt immer noch notwendig ist;

    und dort liest man den PIN aus; und nein er ist nicht 1:1 gespeichert, sondern als Hash; aber bei 10 000 Möglichkeiten ist das im Handumdrehen

    erledigt; […]

    Am Magnetstreifen (sofern überhaupt noch einer vorhanden ist), wird meines Wissens keine PIN (mehr?) gespeichert. Der ist ausschließlich im Chip enthalten.

    Ansonsten bitte: Quellenangabe! :whistling: