Moin,
keyhelp habe ich seit gut fünf Jahren im Dauereinsatz. Eignet sich gut wenn man mit Kunden arbeitet und nicht viel selber machen will. Bei kleineren Projekten setze ich gerne HestiaCP ein. HestiaCP kommt sogar ganz ohne Apache2 aus und läuft auf Wunsch nur mit nginx. MySQL, MariaDB und PostgreSQL werden unterstützt: https://hestiacp.com/
Hallo sla,
danke für das Feedback. Es ist nun möglich, beim ISO und UserImage eine presigned URL für den Upload außerhalb des Browsers zu generieren. Die Funktionalität findet sich ganz unten auf den jeweiligen Seiten unter "Upload URL generieren".
Wir denken, das deckt den Usecase ab.
Ohne Mist, diese Funktion ist wirklich super geil. Einfach mit einem simplen Befehl die ISOs hochschieben - und ohne nerviges ftp!
Ich bin verwirrt... 
Ich habe gerade einen heruntergeladenen snapshot mit zstd entpackt, um das raw-Image zu erhalten, welches ich dann wieder hochladen kann. (Siehe diesen Thread)
Das hat zstd auch anstandslos gemacht.
Allerdings zeigt mir ls -lh:
-rw-r--r-- 1 root root 640G Jan 23 20:36 image.raw
Also eine 640GB große Imagedatei (So groß wie die disks des Servers, von dem der snapshot stammt) 
Was irritierend ist, da der Server auf dem die Dateien liegen, nur 320GB Platz hat. 
Kann also nicht sein.
du -h * zeigt mir auch nur 15 GB an:
15G image.raw
Das ist nicht sehr viel mehr als die gepackte Datei und das wird wohl stimmen.
Warum zeigt mir hier ls sowas an?
(Ich sehe, es gibt Dinge in Linux, die sind mir neu)
Alles anzeigenIch bin verwirrt...
Ich habe gerade einen heruntergeladenen snapshot mit zstd entpackt, um das raw-Image zu erhalten, welches ich dann wieder hochladen kann. (Siehe diesen Thread)
Das hat zstd auch anstandslos gemacht.
Allerdings zeigt mir ls -lh:
-rw-r--r-- 1 root root 640G Jan 23 20:36 image.raw
Also eine 640GB große Imagedatei (So groß wie die disks des Servers, von dem der snapshot stammt)
Was irritierend ist, da der Server auf dem die Dateien liegen, nur 320GB Platz hat.
Kann also nicht sein.
du -h * zeigt mir auch nur 15 GB an:
15G image.raw
Das ist nicht sehr viel mehr als die gepackte Datei und das wird wohl stimmen.
Warum zeigt mir hier ls sowas an?
(Ich sehe, es gibt Dinge in Linux, die sind mir neu)
Schon mal mit fallocate rumgrespielt? 
ls zeigt dir halt den "reservierten" Platz an, während du den tatsächlich genutzten/verbrauchten zählt.
Könnte sich um ein sparse file handeln, da eben nur 15GB von den 640GB belegt sind.
Probier mal folgendes:
du -h --apparent-size *
--apparent-size
print apparent sizes rather than device usage; although the apparent size is usually smaller, it may be larger due to holes in ('sparse') files, internal fragmentation, indirect blocks, and the like
Man findet ja auch:
One of the main characteristics of qcow disk images is that files with this format can grow as data is added. This allows for smaller file sizes than raw disk images, which allocate the whole image space to a file, even if parts of it are empty. This is particularly useful for file systems that do not support sparse files, such as FAT32.
Siehe auch:
Könnte sich um ein sparse file handeln
Ja. Das ist wohl so.
Wusste nicht, dass ls die "apparent size" anzeigt.
Wieder was gelernt.
Tipp: ls -hls
ignoriert bei folgendem Artikel mal das was der gemacht hat ...
Scherz von Teenager führte zu Kampfjet-Einsatz (futurezone.at)
SSL everywhere ist nett;
und bringt es was, kann jedes Stück Software damit korrekt umgehen?
Geht es dir darum dass in einem Public WIFI Nachrichten abgefangen wurden?
Das würde aber implizieren, dass Snapchat tatsächlich plain HTTP spricht und das Flughafen WiFi aktiv mitgeschnitten und ausgewertet wird. Letzteres ist zwar gar nicht mal so unwahrscheinlich, ersteres allerdings umso mehr.
Ich meine - wir können hier in jedem Falle nur mutmaßen. Aber ich bin mir ziemlich sicher, dass Snapchat kein E2EE verwendet und es hinsichtlich Datenschutz/-souveränität der Nutzenden sowieso nicht so genau nimmt. Ich vermute eher mal, dass das ganze dort serverseitig aufgelaufen ist und irgendein Algorithmus das rausgefiltert und der Moderation vorgelegt hat. Aber nichts genaues weiß man nicht...
Fakt ist eigentlich, dass die Tatsache, dass er Snapchat nutzt (und dabei glaubt, dass das alles safe wäre und die Daten tatsächlich nach x Stunden gelöscht werden) und so einen Müll schreibt schon gut zusammen passen - der Bodensatz der Gesellschaft halt, der absolut null über die Folgen seines eigenen Handelns nachdenkt.
whoami0501 nicht uinbedingt; darum ja meine Frage ob denn jedes Stück Software damit umgehen kann;
nachdem was ich vor 3 Wochen od. so beobachtet hatte ...
meine SSL-Zertifikate wurden wegen einem "Issue" (außerhalb meiner Sphäre) revoked;
und wer/was war dieses Faktum egal?
richtig der Flosse;
und von daher stell ich mir halt schon die Frage, wie einfach es ist SSL-interception den Nutzern unterzujubeln ...
ich kenn die Snapchat-App nicht, aber wenn die Verschlüsselung zwischen App und Server veranstaltet,
ist es unerheblich ob da SSL als Transportverschlüsselung zum Tragen kommt od. nicht,
und wenn doch mit Transportverschlüsselung ist es wahrscheinlich dann auch egal ob da wer mit SSL-interception 'reinfunkt;
ich vermute auch fast, dass da serverseitig was getriggert wurde,
und des automatisiert an die Verantwortlichen der IP in Echtzeit mitgeteilt wurde;
ignoriert bei folgendem Artikel mal das was der gemacht hat ...
Scherz von Teenager führte zu Kampfjet-Einsatz (futurezone.at)
SSL everywhere ist nett;
und bringt es was, kann jedes Stück Software damit korrekt umgehen?
Futurezone scheint wohl eher History-Repeatin' Archive-Artikel weil auf einer Website das Datum leicht gefälscht werden kann,
LE freundlich war SnapChat schon immer und "Bomb" kommt am Flughafen nie gut (auch wenns in einem Bild war) Diskussion hier
docker compose config --dry-run | wc -lwm
242 439 7915Hat einen Moment gedauert, war es aber wert.
sowas im Log vom Mailserver läßt einem wieder mal grinsen ...
Jan 27 02:17:44 mailhost postfix/smtpd[29090]: NOQUEUE: reject: MAIL from mail.mobizone.com.pk[202.147.177.186]: 554 5.7.1 <test@devolka.pl>: Sender address rejected; from=<test@devolka.pl> proto=ESMTP helo=<mail.mobizone.com.pk>des glaubt doch wohl niemand, dass jemand aus Polen ein Mail über Pakistan schickt ...
darüber bin ich vor kurzem gestolpert
ein netter Vergleich
Scheint so als hätte der Praktikant pünktlich zum Jahreswechsel aufgehört 
Es stimmt aber, dass Google und Yahoo die Anforderungen ab Februar weiter anziehen werden: https://sendgrid.com/en-us/blog/new…for-gmail-yahoo
ich hätte Google und Yahoo dafür eigentlich schon auf die Fahrleitung gehängt, wenn sie was anderes akzeptieren;
Am 30.01. ab 10:00
Damn, das hab ich überlesen. War das vorher nicht immer 08:00 Uhr? Ich hab mir extra den Wecker auf 07:50 gestellt 
Damn, das hab ich überlesen. War das vorher nicht immer 08:00 Uhr? Ich hab mir extra den Wecker auf 07:50 gestellt
Hier geht's schon früher los: https://anx.io/PEkR9
Hier geht's schon früher los: https://anx.io/PEkR9
Ja is ja gut, tritt gern noch weiter auf einen übermüdeten am Boden liegenden Mann ein! 
De-Domain für 13Cent / Monat + 2 € Einrichtung = ID 3617
Aber geht auch nicht früher los 
