Beiträge von m_ueberall

    Zum Thema ZFS: Ich bin auf den Maschinen bei netcup von ZFS auf BTRFS gewechselt. Bei ZFS fehlt mir die fstrim/discard-Unterstützung. Dadurch läuft die Platte des Servers im SCP immer weiter voll und man kann keine Snapshots mehr machen. Bei BTRFS funktioniert das ohne Probleme.

    Hm... Fehlendes TRIM kann nicht dazu führen, dass die Platte vollläuft; es hat allenfalls Auswirkungen auf die Performanz (und indirekt ggf. auf die Lebenserwartung einer SSD).

    Mir ist auch noch kein Fehlerbericht oder eine Situation untergekommen, in welcher es nicht mehr möglich war, Snapshots zu erstellen (die im Moment der Erstellung ja eigentlich "keinen" Platz wegnehmen – erst Änderungen führen dazu, dass ggf. Speicher nicht mehr freigegeben werden kann). Konzeptuell wüßte ich auch nicht, wie das bei BTRFS anders gelöst sein sollte, es sind ja beides CoW-Dateisysteme.

    (Was man bei beiden Dateisystemen nicht machen darf, ist, den verfügbaren Speicherplatz fast vollständig zu belegen. Bei ZFS reserviere ich generell 15% des Pools vor Erstnutzung.)

    Bei Ubuntu gab es damals ja Ärger als die ZFS und den Kernel in einem Repo als Binaries angeboten haben, weil die Lizenzen inkompatibel sind.

    Also, der heute für Ubuntu 18.04LTS selbst-kompilierte Kernel 4.18.0-8-generic aus dem "(bald)18.10"-Repository hat im Paket auch ZFS/SPL v0.7.9 als Module 'drin. Sofern keine neueren externen ZFS/SPL-DKMS-Pakete installiert/gefunden werden, wird da beim Einspielen der Kernel-Pakete nichts rekompiliert/ersetzt. Mir gefällt das so. ^^

    H6G: Was ist denn so schlimm an DKMS?

    [netcup] Johannes B. : Auch beim Test der SSHFP-Einträge liefert "dig +vc sshfp example.org" nicht die Ergebnisse zurück, welche man erwarten würde und im CCP sieht. Ich habe die (anonymisierten) dig-Ausgaben einer im CCP verwalteten Domäne (.org) und einer Fremdomäne (.ch) angehängt. Zum Vergleich: RFC4255-Beispiel


    ccp-sshfp.png

    wieso nicht gleich SHA2-224, der hat genau diese 28 bytes od. 224 bits?;)

    Das ist nicht dasselbe! Die Kürzung des Bezeichners trägt in der Regel älteren Beschränkungen Rechnung, aber ein SHA2-224-Hash ist nun einmal weniger sicher als ein SHA2-256-Hash (sonst könnte man ja auch CRC32 nehmen und die Binärdarstellung als Bezeichner eintragen o.ä.). Dasselbe Prinzip (Kürzung des Bezeichners aus Restriktionsgründen/Bequemlichkeit, solange Eindeutigkeit gewahrt bleibt) findet man ja auch bei git o.ä.

    [netcup] Johannes B. : Bei den OPENPGPKEY-Einträgen, bei welchen man die (öffentlichen!) Schlüssel im Base64-Format in das CCP hineinkopiert – wie es das Bildschirmfoto der heutigen Pressemitteilung suggeriert – erfolgt derzeit vor Abspeicherung wohl eine zweite Base64-Konvertierung? (Dies ist IMHO daran zu erkennen, dass die (um Füllzeichen gefilterte) "dig +vc openpgp [...]"-Ausgabe mittels "base64 -d" mit der Originaleingabe im CCP übereinstimmt.)


    Infolgedessen schlägt ein "gpg --verbose --auto-key-locate clear,dane --locate-keys info@example.org" fehl.

    Liebe Kundinnen und Kunden,

    Hallo m_ueberall  Saalbuerger  thomas303,

    Ihre Wünsche wurden wahr. Herzlichen Dank für Ihre Geduld.

    :love:


    Kurze Nachfrage: Wie lange dürfen entsprechende Einträge denn sein? Mein Test-Minimal-GPG-Schlüssel-Export hat (im Binärformat) 19268 Bytes[*], und in Hexadezimalformat gemäß RFC7929 wird's doppelt so lang. Via CCP läßt sich das so nicht hineinkopieren.


    [*] Es gibt sicherlich kürzere, aber der Schlüssel wurde seinerzeit absichtlich zur Abdeckung mehrerer Domains erstellt, um die öffentlichen PGP-Schlüssel-Server nicht mit Schlüsseln/"redundanten Attributen" zu "fluten".

    Das ist eigentlich nicht typisch Debian, so wie ich Debian vor paar Jahren kannte.

    Seitdem die Meltdown/Spectre Sicherheitslücken bekannt wurden, bin ich mit Debian nur am Patchen und rebooten.

    So habe ich das Gefühl, kann auch sein, dass es mir eingebildet habe.

    Naja… man kann einer Linux-Distribution eigentlich nicht anlasten, dass sie sich aktiv um die Bereinigung von Fehlern kümmert; Pech, wenn es wiederholt den Kernel selbst betrifft. Niemand ist gezwungen, den Rechner neu zu booten.

    Wenn die aktuelle Problematik dazu führt, dass die "Livepatch"-Funkionalität in allen Distributionen (stark) aufgewertet wird – diese schützt bei Ubuntu auch nicht immer vor Reboots –, mag das langfristig(!) sogar vorteilhaft sein. (Man-wird-ja-wohl-noch-träumen-dürfen…)

    leider nicht, das wäre mein absoluter Favorit. Erst vorgestern recherchiert für tinc 2.0 ist das geplant aber es entwickelt halt keiner dran :(

    Ein sehr interessant aussehendes Projekt, welches auch aktuelle Commits "sieht", ist https://github.com/freelan-developers/freelan (http://www.freelan.org/) – bin erst heute darüber gestolpert, aber wenn's jemand ausprobieren möchte…

    (https://github.com/freelan-developers/freelan/issues/34 diskutiert übrigens die "Nachteile" von X.509)

    Der Dienst nennt sich piri.

    Sagt mir jetzt nichts (ein Link wär' praktisch!)


    Grundsätzlich sind zwei Fragen zu klären:

    1. Muss server-seitig etwas zwischen den Instanzen synchronisiert werden (Sitzungs-Verwaltung)?
    2. Unterstützt der/die verwendete(n) Client(s) Round-Robin, d.h. wird er bei einem Versuch, zuerst mit einer nicht-erreichbaren Instanz zu kommunizieren, alternative Zugriffsmöglichkeiten (nächste bekannte IP-Adresse) durchprobieren?
      • wenn nicht, hilft nur, mittels eines Proxies/Load-Balancers mit "Eigenlogik" sicherzustellen, dass die Anfrage an eine funktionsfähige Instanz weitergeleitet wird (das spräche u.U. gegen die Verwendung von Round-Robin/mehreren DNS-Einträgen, es sei denn, der Dienst sitzt üblicherweise sowieso hinter einem Proxy, dann könnte man einen solchen vor jede Instanz des Dienstes setzen).

    @m_ueberall: Wie testest du bei einem Serverumzug ob deine Webseiten auf dem neuen Server auch sauber funktionieren?

    Gerade, indem ich durch Kontrolle der/des DNS-Server(s) dafür sorge, dass bei (back-to-back-)Testläufen wie gewünscht entweder die alten oder die neuen Server von einer/mehreren Testmaschine(n) auf der Client-Seite angesprochen werden.


    Im "einfachsten" Fall bei entsprechender vorhandener Konfiguration sind hierzu weder bei den neuen Servern noch bei den dedizierten Maschinen irgendwelche Änderungen vorzunehmen (sofern etwa BIND Views o.ä. zum Einsatz kommen, vgl. diese Diskussion) – d.h. man definiert Server-Zonen und/oder Gruppen von Clients zu Testzwecken, die von denselben im Einsatz befindlichen DNS-Servern bei identischen Anfragen zu unterschiedlichen Auflösungen führen (aber wirklich nur kontrolliert bei den Test-Clients); nachdem die Tests erfolgreich absolviert wurden, werden die Testeinträge die neuen global gültigen.


    Alternativ kann man aber auch einfach auf Testmaschinen einen temporären, zusätzlichen DNS-Server ansprechen, welcher einfach die alten mit den zu testenden Einträgen überschreibt und alle anderen Anfragen einfach an bestehende DNS-Server weiterreicht. Das ist nicht wirklich komplexer in der Konfiguration, aber "robuster" (nicht alle Anwendungen scheren sich unbedingt um Einträge in der /etc/hosts) und IMHO weniger fehleranfällig, weil man hierbei nur den Eintrag des DNS-Servers oder die Suchdomäne (letztere Modifikation nur bei vereinfachter Umsetzung des o.g. Ansatzes; mit Einschränkungen verbunden, IMHO nicht zu empfehlen) o.ä. anpassen muss, je nach gewählter Strategie der Identifikation von Testmaschinen. (Wie gesagt, bei entsprechender Planung/Aufsetzung der Infrastruktur wie im vorherigen Absatz muss man Client-seitig gar nichts ändern.)


    Eine weitere Alternative wäre das Vorsehen von "floating IPs" für die Dienste über welche man Back-to-back-Tests laufen lässt (oder man definiert grundsätzlich parallele Test-Präfixe, etwa "www-test" statt "www", welche von den Servern gleich behandelt werden, aber durch DNS-Eintragsänderung eben gesteuert bei den alten/neuen Servern landen und möglichst nicht von aussen zugänglich sind – also bspw. nur bei Zugriff über ein VPN bedient werden –, um Fehler zu vermeiden). Man muss wiederum nur sicherstellen, dass während der Testphase ausschließlich die internen Testmaschinen über diese "floating references" zugreifen.

    long lines in /etc/hosts breaks all dns lookups

    Wer oder was erzeugt denn in der Praxis lange Zeilen in /etc/hosts, anstatt die Einträge dort zu minimieren und redundante/einheitliche DNS-Server einzusetzen?

    Sind solche Ereignisse nicht willkommene Steilvorlagen, damit ein für allemal aufzuräumen?

    Hab das so gebaut: https://hüpf.net/nc-kunden

    Die Seite /imprint.php wird aber nicht ausgeliefert… ich glaube, das ist in dem Fall erforderlich für eine DSGVO-Konformität. 8o


    Wobei ich mich ernsthaft frage, ob die entsprechenden Verweise auf Impressum/Datenschutzerklärung im Browser nicht auch funktionieren müssen, wenn JavaScript deaktiviert ist (auch eine Opt-In-Abfrage funktioniert ohne eher selten). Bei vielen Seiten finden sich jedoch gerade keine "Fallback-Hyperlinks" bzw. Warnungen, die auf eine erforderliche JavaScript-Unterstützung hinweisen.

    Kennt jemand hier eine Möglichkeit, um den Text (komplett) innerhalb der PDF neu zu färben (schwarz) um danach entweder Zeilen oder nur die Textstelle selber, die einen entsprechenden Kurs von mir enthält, farbig sowie fett hervorzuheben?

    Hierzu muss die Struktur der PDF-Datei einmalig analysiert werden, man muss hoffen, dass sich diese nicht ändert, und dann sind entsprechende PDF-Befehle einzufügen. Diesen Ansatz halte ich für viel zu aufwendig/fragil.

    Alternativer Vorschlag (unter Anwendung des KISS-Prinzips): Nutze ein Hilfswerkzeug, welches speziell für die Extraktion von Tabellen aus PDFs geschaffen wurde (Tabula), und manipuliere/reformatiere die extrahierten Daten. Danach lässt sich, wenn gewünscht, auch wieder ein PDF vom Ergebnis erzeugen.

    Das geht ganz leicht auf der entsprechenden Profilseite.

    Ich meine dadurch bekommt man auch keine Benachrichtigung mehr bei Posts

    [...]

    Und für Threads geht es hier:

    [...]

    Danke, aber alle bisherigen Benachrichtigungen kamen bislang zu "Das längste Thema"… und wenn es einen Thread gibt, welchen ich nicht stummschalten will, dann ist es dieser hier. Ich bezweifle, dass ich Benachrichtigungen bei Antworten auf einen Post innerhalb dieses Threads ("Subthread") blockieren kann; werde mir das aber nochmal ansehen, man lernt ja nie aus. :)


    Personen blockiere ich persönlich grundsätzlich nicht (selbst die offensichtlichsten Twitter-Trolle nicht, denn die lernen irgendwann, dass sie eine fortgesetzte Interaktion mit mir mehr Zeit o.ä. kostet, als es mich kostet, mich wahlweise über ihre Auslassungen zu amüsieren, sie zu piesacken oder sie zu ignorieren; und verglichen mit einigen Meinungsaustauschen auf Twitter geht es hier deutlich gesitteter zu!)

    dies steht im Widerspruch zur verpflichteten Datensparsamkeit; lies die ganze DSGVO; und vergiß Deine Quelle, die authentische Quelle ist diese hier:

    https://ec.europa.eu/commissio…-data-protection-rules_de

    Ich glaube, da hat jemand die zitierte Quelle immer noch nicht gelesen; diese bezieht sich nämlich explizit auf einzelne Paragraphen der DSGVO und enthält entsprechende Abwägungen ("Datensparsamkeit" ist eben kein Totschlagsargument, vgl. "berechtigtes Interesse" – sollte jedem einleuchten, der bereits eine eigene Datenschutzerklärung angepasst/eingekauft und hoffentlich wirklich durchgelesen hat).

    Und "authentisch" (das ist in diesem Kontext sowieso der falsche Begriff, weil es hier letztlich um Vorschriften/Gesetze geht, die aus einer EU-Richtlinie abgeleitet wurden) ist nicht o.g. Quelle mit einem Sammelsurium an Beiträgen, sondern allein der erste Link darin (die DSGVO selbst) im Kontext mit der jeweiligen nationalen Umsetzung (in Deutschland: dieses Gesetz) sowie verabschiedeten und damit rechtsgültigen Nachbesserungen (x. DSAnpUG-EU), welche sich national de-facto unterscheiden können (u.a. solange kein abschließendes, EU-weit einheitlich gültiges Urteil darüber vorliegt, aber auch aufgrund von nationalen "Seiteneffekten").


    Da ich mich nicht wiederholen mag und den "Das längste Thema"-Diskussionsfaden (oder-wie-man-es-nennen-will) auch ungern mit irgendwelchen halbgaren simplifizierenden Behauptungen zu diesem komplexen Thema vollgemüllt sehe (welche sich nicht auf Urteile stützen können – ich bin da ganz bei Cictani, vgl. vorletzten Beitrag – und einer Vielzahl von Ausführungen von Personen widersprechen, welche sich als spezialisierte Juristen tagein/-aus mit nichts/viel anderem beschäftigen), werde ich mich nicht länger darüber auslassen.


    Ich würde es darüberhinaus jedoch explizit begrüßen, wenn Posts zu diesem Unterthema von einem Moderator hierzu woandershin verschoben/gebündelt werden, wenn sich jemand partout fortgesetzt darüber äußern will (Benachrichtigungen lassen sich nämlich nicht selektiv ausblenden, soweit ich gesehen habe). Das kommt sicherlich auch all denjenigen zugute, welche bestehende Posts zum Thema DSGVO querlesen wollen; und es strafft eben zugleich diesen "Diskussionsfaden", dessen durchschnittlicher Gehalt an belastbaren(!) Informationen, kurz(!) andiskutiert, erfreulich hoch ist.

    Ich gebe mal folgende Frage zurück, denn wer die von mir zitierte Quelle vollständig liest, sieht, dass die im letzten Posting genannten Fälle mit dem vorgenannten gar nichts zu tun haben (Orangen/Birnen, aber keine Äpfel). Es geht hier nicht um eine Banküberweisung oder um den Einkauf in einem Online-Shop oder das einmalige Anfordern eines Whitepapers, es geht um die fortgesetzte Nutzung eines (Kommunikations-)Dienstes für "Daten/Informationen/nicht-monetäre Beiträge gegen Dienstleistung".

    […] bist Du der Typ, der nur Anfang und Ende liest, aber nicht das dazwischen, denn der von Dir markierte Teil juckt keinen,

    Unter dem Abschnitt "Denkbare Lösungen" steht der Punkt "2. Integrieren", und genau das wird im vorliegenden Fall verfolgt, Punkt.