CoronaChroniken: Sterbezahlen nicht mehr veröffentlicht

Liebe Maskierte,

das RKI hat sich am 12.9. dazu entschlossen, im täglichen Situationsbericht keine Sterbekurve mehr veröffentlichen.

UPDATE 17:00 Uhr: RKI antwortet auf Anfrage

CoronaChroniken: Sterbezahlen nicht mehr veröffentlicht

Damit ist es natürlich nicht mehr möglich einen zeitlichen Graphen zu erstellen. Einen zeitlichen Zusammenhang zwischen Anstieg der Infektionszahlen und Anstieg der Todeszahlen abzubilden, ist somit ab dem 12.9. nicht mehr möglich. Eine weitere Darstellung in diesem Blog ist daher leider unmöglich.

Im Situationsbericht des RKI vom 12.9. findet sich leider kein Hinweis, warum auf diese Darstellung verzichtet wird. Es werden zwar weiterhin +- Veränderungen bei den Todeszahlen angegeben, aber wann die genau waren, und hier finden genauso Anpassungen/Korrekturen statt wie bei den Infektionszahlen, kann man nicht mehr ableiten. Damit ist diese Zahl nutzlos geworden.

Ich denke, daß dies kein wirklich smarter Move der Verantwortlichen war, da die Verschwörungsfans hier gleich wieder neues Futter bekommen. Transparenz sieht halt anders aus.

Eine Anfrage an die Pressestelle des RKI ist raus.

Der KW 33 Peak

Wie im Artikel Prognose: in KW 32/33 2020 werden ca. 3.000 Menschen zusätzlich sterben angedroht und am 11.9. im Situationsbericht des RKI abgedruckt .. da isser:

KW 33 Speak im Statistischen Bundesamtgrafen zur Sterblichkeit in DeutschlandQuelle: RKI, aber man könnte ihn auch direkt von Destatis bekommen.

Update 17:00 Uhr

Die Anfrage:

Guten Tag,

uns ist aufgefallen, daß seit dem 12.9. die Grafik „Sterbefälle nach Datum“ nicht mehr im Situationsbericht enthalten ist.

Können Sie uns einen Grund dafür nennen?

Antwort vom RKI:

[Anrede]…

vielen Dank für Ihre Anfrage. Das RKI hat seit dem 14.9.2020 den täglichen Situationsbericht (Lagebericht) in einer gekürzten Fassung veröffentlicht (das entspricht etwa der Wochenendfassung). Der Bericht fokussiert stärker auf die aktuelle Situation. Demografische und klinische Aspekte, die sich von Tag zu Tag kaum oder nur wenig ändern, werden künftig – wie andere Themen auch – nur noch einmal wöchentliche und im Wochenvergleich dargestellt. Diese ausführlichen Auswertungen sind weiterhin Dienstags verfügbar.

Also wird es wieder die unnützen „in Woche 10 waren es 10, in Woche 11 waren es 900, in Woche 12 waren es 13“ Tabellen geben. Da kann man nur ganz grob etwas ablesen und schon gar keine echten Zusammenhänge zwischen den Peaks bei Infizierten und Verstorbenen erkennen. Ein echter Rückschritt.

LUKS: Wie man einen Cloud-Container erstellt.

Wer kennt das Bedürfnis nach Synchronisation des Dateibestandes von verschiedenen Geräten über einen Cloudanbieter aka Webhoster nicht? Ok, Ihr könnt jetzt zur nächsten OSBN News wechseln, außer Ihr möchtet an einem Zweitstandort eine sicher aufgehobene Kopie Eurer Daten haben, auf die nur Ihr Zugriff habt, dann lest jetzt weiter …

LUKS: Wie man einen Cloud-Container erstellt.

Verschlüsselungssysteme gibt es ja viele, aber nicht alle sind bei jeder Distro onboard und osübergreifend verfügbar, LUKS schon. Deswegen heute ein kleiner Beitrag wie man seine Daten bei einem Webhoster so parkt, daß man sie von überall aus einbinden kann.

ACHTUNG: Bei einer Cloud-Container-Lösung auf Basis von Luks oder Truecrypt darf nur ein PC das System aktiv einbinden, sonst Datenverlust! Möglich ist aber ein READ-ONLY-Einbinden mehrerer Rechner gleichzeitig. Ich warne ausdrücklich davor so etwas zu versuchen und es dann zu versemmeln!

Der Hintergrund für die Warnung ist ganz einfach der, daß Eurer PC der Meinung ist, daß er den Datenträger exklusiv hat und daher Sachen im RAM vorhält, die nicht auf den Datenträger synchronisiert sind um die Leistung zu steigern. Wenn zwei Rechner das machen und dann vermeidliche freie, aber vom anderen PC schon im RAM anvisierte Blöcke beschreibt, kommt es unweigerlich zum Datenverlust. Wer schon einmal mit SSHFS gearbeitet hat, das einen entfernten PC als Laufwerk einmountet, der wird bemerken, daß da keine lokale Pufferung stattfindet, weil der PC hier nicht wissen kann, ob und wer sonst noch so auf die Datenquelle zugegriffen hat. SSH greift auf der  anderen Seite auch nicht als Filesystem, sondern über die OS API auf Dateien zu und simuliert Euch nur ein Laufwerk.

Anders ist das, wenn zwar der Container per SSHFS verfügbar gemacht wird, aber das Einbinden des entschlüsselten Filesystems dann lokal stattfindet. Das findet dann wieder mit den OS eigenen IO-Steigerungsamethoden statt. Beim Mounten von Datenträgern kann man über die Mount-Options noch einiges abändern, da geht vielleicht sogar was, aber empfehlen kann ich das definitiv nicht.

Die Ausgangslage

Wir behandeln daher einen PC der auf einen Webserver zugreift, dort seinen Container lagert und die ganze Ent- und Verschlüsselung auf dem eigenen PC auflaufen lässt.

Wir brauchen: CryptSetup, einen Webserver, schnelles Internet ( ist von Vorteil )

Der Webserver

Der Webserver muß eine der folgenden Anbindungen unterstützen: SSH, SAMBA oder NFS und zwar genau in der Reihenfolge sollte man das auswählen. Für diesen Artikel nehme ich SSH, da das auf jedem LinuxPC vorhanden ist und der Transportweg so zusätzlich verschlüsselt ist. Da sieht man dann auch nicht, was da eigentlich auf dem Webserver gemacht wird.

Samba ist zwar mittlerweile auch im Datentransport verschlüsselt, aber viele Router halten das auf, damit die Windowskisten nicht das Providernetz vollspammen, die sind sehr mitteilungsbedürftig 😉

NFS kennt keine Authentifizierung außer IPs, ist unverschlüsselt und ist im allgemeinen bestenfalls zwischen Servern einzusetzen.

Das PRE-SETUP

Wir machen das alles als ROOT, weil CryptSetup und mount das gern so möchten. Da hier FUSE nur sekundär im Einsatz ist, weil es sich um normale Filesysteme des Kernels handelt (kommt gleich),  kommt mount zum Einsatz, welches zwingend als ROOT laufen möchte. Das Ergebnis der Aktion kann aber dann von jedem User benutzt werden. Wenn man sich da nicht besonders blöd im Rechtemanagement anstellt, dann ist das auch auf einem Mehrbenutzersystem kein Problem.  Kommen wir zu …

Schritt 1: Einen Mountpoint für den Container erstellen

mkdir -p /media/container/server

Der Ort ist in der Regel für jeden Benutzer erreichbar, was z.b. beim Mounten im eigenen Home nur für den aktuellen Benutzer gelten würde.

Schritt 2: Der Server als Laufwerk einbinden

sshfs demo@meine.demo.de:/home/demo /media/container/server -o allow_other

Je nachdem was man als Authmechnismus eingestellt hat ( KEY oder PASSWORD )  macht da der SSH-AGENT, der hoffentlich in irgendeiner Form bei Euch läuft ( gpg-agent, ssh-agent, gnome-keyring-daemon ) das mit dem Schlüssel automatisch für Euch, oder Ihr müßt ein Passwort eingeben.

Schritt 3: Das Containerfile anlegen

Hier im Beispiel benutze ich jetzt ein 100MB File ( 1M * 100 ) :

# dd if=/dev/zero of=/media/container/server/container.luks bs=1M count=100
100+0 Datensätze ein
100+0 Datensätze aus
104857600 bytes (105 MB, 100 MiB) copied, 29,0354 s, 3,6 MB/s

Wer da übers Netz GBweise Dateien anlegt, der sollte sich fragen, ob er verstanden hat, was er da gerade tut, denn das dauert Stunden und man könnte es ja auch auf dem Webserver erledigen lassen, daß dauert nur Sekunden, denn noch ist da weder Crypto noch ein Filesystem dran beteiligt, es wird nur ein BLOCK mit NULLEN erzeugt.

Schritt 4: Den Container mit LUKS formatieren

Der nächste Schritt sollte allerdings zwingend vom PC aus erledigt werden, da dazu ein Passwort nötig ist, welches, solange der Vorgang dauert, auch im Speicher des Webservers verfügbar wäre, würde man es dort tun. Das Formatieren dauert dann auch ein gutes Weilchen.

# cryptsetup -y luksFormat /media/container/server/container.luks

WARNING!
========
Hiermit werden die Daten auf »/media/container/server/container.luks« unwiderruflich überschrieben.

Are you sure? (Type ‚yes‘ in capital letters): YES
Geben Sie die Passphrase für »/media/container/server/container.luks« ein: ***********************
Passphrase bestätigen: ***********************

Ein sinnvoll langes Passwort > 20 Zeichen ist angeraten! Es sollte nicht 123456789… lauten 😉

Schritt 5: Den Container öffnen und zum Mounten bereitstellen

Dieser Schritt geht dann recht zügig von statten. Ihr müßt nicht zwangsweise den gleichen Cryptocontainernamen benutzen wie ich, da seid Ihr flexibel.

# cryptsetup luksOpen /media/container/server/container.luks cryptocontainer
Geben Sie die Passphrase für »/media/container/server/container.luks« ein: ***********************

Schritt 6: Das Filesystem erstellen

Beim ersten mal muß man jetzt das Filesystem einrichten:

# mkfs.ext4 -j /dev/mapper/cryptocontainer
mke2fs 1.45.5 (07-Jan-2020)
Ein Dateisystem mit 86016 (1k) Blöcken und 21560 Inodes wird erzeugt.
UUID des Dateisystems: bcbccb1b-794e-4700-bd64-cd021a42bf32
Superblock-Sicherungskopien gespeichert in den Blöcken:
8193, 24577, 40961, 57345, 73729

beim Anfordern von Speicher für die Gruppentabellen: erledigt
Inode-Tabellen werden geschrieben: erledigt
Das Journal (4096 Blöcke) wird angelegt: erledigt
Die Superblöcke und die Informationen über die Dateisystemnutzung werden geschrieben: erledigt

ich habe jetzt EXT4 ausgewählt, weil das in jedem Kernel vorkommt und als Journalingfilesystem keine ellenlangen Reparaturen vor dem Mounten braucht, was gerade bei einem Netzwerkcontainer ein wichtiger Entscheidungsgrund ist, sonst wartet Ihr da auch schon mal Stunden auf den Mount.

Schritt 7: Den Containerinhalt ins System einbinden

Das Einbinden in das System ist dann denkbar einfach:

# mount /dev/mapper/cryptocontainer /mnt
# df -h | grep mnt
/dev/mapper/cryptocontainer 78M 1,6M 70M 3% /mnt

Das wärs schon, wenn da nicht das Zugriffsproblem wäre. Also muß Root da jetzt z.B. noch ein Verzeichnis anlegen, weil die User keine Schreibrechte haben:

# ls -ls /mnt/
insgesamt 12
12 drwx——. 2 root root 12288 13. Sep 12:01 lost+found
# ls -lad /mnt/
drwxr-xr-x. 3 root root 1024 13. Sep 12:01 /mnt/
# mkdir /mnt/demo
# chown demo:demo /mnt/demo
# chmod 700 /mnt/demo/
# ls -ls /mnt
insgesamt 14
2 drwx——. 2 demo demo 1024 13. Sep 12:10 demo
12 drwx——. 2 root root 12288 13. Sep 12:01 lost+found

Nun kann der Benutzer „demo“ da machen was auch immer er möchte.

Einbinden beim System-Boot

Das ist nicht ganz ohne. Man könnte dem Cron sagen, daß er das nach dem Boot machen soll, indem man da ein kleines Script benutzt, daß alle Schritte als Root macht, aber wer sagt uns, daß das auch passiert, wenn ein Netzwerk vorhanden ist? Niemand, also müssen wir das wohl oder übel an den Systemd übergeben. D.b. Ihr schreibt einfach ein kleines Start/Stop Script nach /etc/init.d/ oder direkt eine Unit für Systemd direkt, in dem die Anhängigkeiten zum erfolgreichen Netzwerkstart angegeben sind z.b. wie hier:

xl2tpd.service:After=network.target

So ist sichergestellt, daß es auch klappen kann, sofern alles mit dem Netzwerk und dem Server ok ist.

Sicherheitsanalyse

Wo liegen hier die Vorteile zu einem USB Stick? Zum Einen macht der Hoster normalerweise ein Backup von dem Server oder bietet Euch zumindest an, daß Ihr eins machen könnt. Dann ist das von überall aus erreichbar und i.d.R. kann man das nicht verlieren. Auch ein „Diebstahl“ wäre nicht tragisch, da der Dieb nicht an den Inhalt kommt, außer Eurer Passwort war „123456“ 😀

Die gesamte Ver- und Entschlüsselung der Daten findet zur Laufzeit auf Eurem PC statt, d.b. jemand muß sich Zugang zu Eurem PC verschaffen und dann auf die Daten zugreifen, wenn diese lokal verfügbar sind. Das könnt Ihr mit Updates und Festplattenvollverschlüsselung leicht kontern, denn dann können Euch lokale Angreifer mal am ….. . Auf diese Sicherheit müßt Ihr sowieso bauen, da ansonsten der Aufwand die Daten verschlüsselt im Netz zu speichern kompletter Unfug wäre. Also ganz klar: Entweder alles oder nichts verschlüsseln, sonst nützt es im Zweifel nichts.

VeraCrypt vs LUKS

Aus Benutzersicht ein klares Ja zu VeraCrypt: Kommt mit GUI und bindet sich ohne Root auch beim Login automatisch per FUSE ein.. 1a!

Der LUKS Container hat aber den Vorteil, daß man damit nur den Leuten vertrauen muß, die sowieso schon Eurer OS zusammenbauen. Wenn man denen nicht trauen würde, könnte man auch VeraCrypt nicht einsetzen, weil wenn das OS unsicher ist, wozu dann noch Verschlüsseln?

Über die /etc/crypttab kann LUKS Medien auch automatisch ins System einbinden lassen, allerdings muß zu dem Zeitpunkt das Netzlaufwerk mit dem Container verfügbar sein, sonst ist Essig. Hat also alles Vor- und Nachteile. Welche davon für Euch interessant sind, müßt Ihr entscheiden.

Wie bekomme ich den Container wieder zu?

Wichtige Frage, einfache Antworten:

umount /media/container/server
cryptsetup luksClose cryptocontainer
fusermount -u /media/container/server

CoronaChroniken: Masken – Fakten gegen Meinungen

Liebe Maskierte,

heute kursiert in verschiedenen Medien ein sehr fahrlässiger Artikel zu Mund-Nase-Bedeckungen. Daher ist das Thema für heute klar:

CoronaChroniken: Masken – Fakten gegen Meinungen

Achtung: bei dem hier verlinkten Artikel handelt es sich nur um eine Meinungsäußerung, nicht um gesicherte Fakten:

Pharmazeutische Zeitung – Womöglich mildere Verläufe durch Masken

Der spekulative Inhalt wird hier wenigstens im Titel sichtbar gemacht, bei anderen Presseartikeln, die ich gesehen habe, war das nicht der Fall, weswegen ich auch diesen ausgewählt habe.

Eine Kurzfassung: „Zwei Professoren aus Kalifornien sind der Meinung, daß Masken den Verlauf von Infektionen abmildern würden, weil sie die Viruslast reduzieren würden. Dafür gäbe es ja Anzeichen in den USA.“

Eher zufällig habe ich Euch ja jüngst die Australisch-Chinesisch-Viatnamesische Studie zum dauerhaften Tragen von Masken und der Steigerung der Ansteckung mit Infektionskrankheiten vor denen die Masken eigentlich schützen sollen, durch die Masken selbst aufgezeigt: Die lange gesuchten Nebenwirkungen von Masken. Damit wäre ein „Erfolg“ damit erkauft, daß  viel mehr Menschen infiziert und in Folge krank werden, weil die Masken nachweislich das Risiko steigern, nicht vermindern. Ich denke, daß würde, so es denn überhaupt funktioniert, niemand ernsthaft wollen.

Die Pocken

Die Arbeitsthese der Beiden ist auch nicht direkt eine geringere Ansteckung, sondern ein milderer Verlauf. Die Basis dafür geht auf die Pockenbekämpfung mit Lebendvakzinen zurück. Damals, bevor es wirksame Impfstoffe gab, machte man sich einer eher fragwürdigen Praxis schuldig: Man infizierte einen gesunden Menschen mit der Flüssigkeit aus den Pockenblasen eines genesenen Pockenpatienten. Die Annahme war, daß der Prozess der Heilung die Viren so abgeschwächt hat, daß sie keine große Gefahr mehr darstellen und gesunde so eine Immunabwehr aufbauen können, ohne an den Pocken selbst zu erkanken.

Wichtige Anmerkung: Infizierte und Erkrankte sind zwei verschiedene paar Schuhe. 95% aller Menschen sind mit Herpes infiziert, aber nur eine Handvoll erkranken oder sterben daran.

Ich tippe auch eher darauf, daß hier (ohne es zu wissen) Antikörper transplantiert wurden, denn diesen Ansatz verfolgt man heute ja auch noch. Der Plan mit der aktiven Pocken zu impfen, ging dann auch regelmäßig in die Hose, weil die Virusmenge in den Proben nicht genau bestimmt werden konnte und dann gabs doch erkrankte, statt immuner Menschen. Die Idee an sich hat in einer Adaption tatsächlich zum Erfolg geführt: animalresearch.info – Pocken durch Impfung ausgerottet Das „Vaccinia“ Latein für Kuh ist, wußte ich auch noch nicht 😉

Verringerte Virenlast

Also, Theorie der Beiden: „Masken verringern die Virenlast, so daß der Körper besser damit zurecht kommt“, weil homöopathische Dosis verabreicht. Da sind also keine abgeschwächten Viren von Genesenen im Spiel und genau das ist das Problem. Sogenannte Lebendimpfstoffe, die früher eingesetzt wurden, waren nicht vermehrungsfähige Exemplare, sei es durch eine Strahlenbehandlung oder gezielte Mutation des Virus zu einer ungefährlichen Form. Diese Lebendimpfstoffe konnten also keine Erkrankung auslösen, dem Immunsystem aber als Blaupause dienen, für den unveränderten Virus. Damit reagiert die Immunabwehr bei einer echten Infektion dann sehr viel schneller, so daß es nicht zu einer Erkrankung kommt. Soll erfüllt.

Wenn man aber eine geringe Menge vermehrungsfähiger Viren verabreicht, dann ist das keine Blaupause mehr, sondern ein echter Angriff. Überschreitet der eine bestimmte Virusmenge, kommt es zur unkontrollierten Vermehrung mit den bekannten Folgen. Ist die Grenze unterschritten, eskaliert die Sache gar nicht erst, weil die Viren schon von der ersten Immunantwort (quasi im Vorbeigehen) ausgerottet werden, was keine Antikörperproduktion vor Folge hat (afaik).

Nun hat die Charité dazu erst letzte Woche eine Studie publiziert, in der sie eine Ursache für schwere Verläufe bei der Risikogruppe glaubt gefunden zu haben: ein Mangel an Interferon-Gamma der die Immunantwort ausbremst. Patienten der Risikogruppe haben mehr als genug T-Helferzellen, aber die arbeiten nur auf Sparflamme, was dann einen schweren Verlauf ermöglicht. (Hinweis: Referenz#5  in der NEJM Publikation der beiden Professoren enthält einen Aufsatz zu genau dem Punkt, die könnten also schon gewußt haben, daß die schweren Verläufe mit den T-Helferzellen zusammenhängen.)

Die Situation in den USA

Jetzt geben die beiden Professoren an, daß sie in den USA ja Anzeichen sähen, die Ihre Meinung bestätigen würden, denn die Anzahl der schweren Fälle nimmt „seit Einführung der Maskenpflicht“ ab, bezogen auf die Menge der Infizierten. Genau hier liegt natürlich der Fehler, denn die Anzahl der schweren Verläufe ist konstant bezogen auf die Bevölkerung, die Anzahl der Tests und damit der „Infizierten“ die von Ihrem Covid-19 Virus wissen ist gestiegen. Das Thema hatten wir ja erst in dem Artikel: Die Ausgrenzung, wo das „Nichtsehen“ der Dunkelziffer zu der irrigen Annahme führt, daß die Ausnahme die Regel ist. Je weiter man aber das Dunkelfeld ausleuchtet, desto greifbarer wird der Normalzustand und die Ausnahme wird wieder zur Ausnahme.

Die Professoren greifen auf ein Experiment zurück, daß systematisch fragwürdig war, denn Hamstern wurden verschiedenen Viruslasten ausgesetzt und eine geringe Virenlast führte zu einem milderen Verlauf. Dies ist ja klar, weil weniger Ärger machende Viren die Körperfunktionen gestört haben, bis sie erledigt wurden. Das den armen Tieren dabei Virenlasten jenseits von Gut und Böse verabreicht wurden, fehlt in dem Artikel. Selbstverständlich könnte man einen Menschen mit einer Ladung Covid-19 Viren direkt ins Blut verabreicht in wenigen Minuten umbringen, dies entspricht aber zu keiner Zeit einer reellen Infektion. Und, bevor jemand einen Master-Erbschaftsplan entwickelt, Affen mit denen man das auch gemacht hat, haben sogar eine heftige Überdosis überlebt. So todsicher ist diese Methode zu Erben gar nicht 😉

Deutschland als Beweis

Nun führen die Beiden Deutschland als anekdotischen Beweis an:

„Die von ihnen aufgestellte Hypothese könnte auch eine mögliche Erklärung dafür sein, dass derzeit in einigen Ländern, darunter Deutschland, die Infektionszahlen wieder ansteigen, aber keine Zunahme der Fälle von Covid-19-Patienten in den Kliniken zu beobachten ist.“

„offiziell“ weiß hier niemand, wieso kaum noch schwere Verläufe kommen. „Man“ geht von zwei Dingen aus: „Mutation des Virus zu schwächerer Form“ und „Die, die konnten, sind schon schwer erkrankt oder Tod“, denn eins steht fest: Die Maskenpflicht kam erst, als die Wellen (Infektion und Sterbewelle) bereits lange durch waren. Was das stärkste Indiz für die These „Masken haben gar keinen Effekt“ ist 🙂

Auch der Vergleich zweiter Kreuzfahrtschiffe, eins mit Masken an Infizierte und Personal, eins ohne Masken, beweist nur eins: schlechte Auswahl von Testsubjekten führt zu schlechtem Ergebnis.

„In an outbreak on a closed Argentinian cruise ship, for example, where passengers were provided with surgical masks and staff with N95 masks, the rate of asymptomatic infection was 81% (as compared with 20% in earlier cruise ship outbreaks without universal masking).“

Übersetzung:
„Bei einem Ausbruch auf einem geschlossenen argentinischen Kreuzfahrtschiff zum Beispiel, auf dem die Passagiere mit chirurgischen Masken und das Personal mit N95-Masken ausgestattet waren, lag die Rate der asymptomatischen Infektion bei 81% (im Vergleich zu 20% bei früheren Ausbrüchen auf Kreuzfahrtschiffen ohne Universalmaske). “ (deepl.com)

Die 81% sind von welcher Bezugsmenge? Was wurde asymptomatisch eingestuft? haben die Leute dauerhaft Maske getragen, oder nicht? Wie war die Gruppenzusammensetzung? Alle Risikopatienten oder war es alles durchmischt? Rahmenbedingungen, die man nicht kennt, weil keine Quelle angegeben wurde.

Das außerdem Äpfel mit Birnen verglichen wurden, nämlich Covid-19 und „irgendwas“ anderes auf früheren Kreuzfahrten, braucht man fast nicht mehr erwähnen. Das „irgendwas“ ist nicht mal exemplarisch benannt und ein Quellenhinweis fehlt auch. Ein anekdotische Beweis ist nun mal kein Beweis im wissenschaftlichen Sinn sind.

Alles in allem ist diese Meinungsäußerung https://www.nejm.org/doi/full/10.1056/NEJMp2026913 nichts belastbares, wenn ich da schon inhaltliche Mängel finde.