Neue Platte automatisch entschlüsseln lassen

Posted on 9. März 2020 by marius

Ich hab eine neue Platte im PC und die soll sich natürlich beim Hochfahren automatisch ins System integrieren, wenn ich das Passwort kenne. Leider klappt das mit den Automatiken nicht so ganz, daher müssen wir da kurz Hand anlegen.

Automatisch LUKS-Platten beim Boot einbinden

Zunächst brauchen wir mal eine mit LUKS verschlüsselte Platte. Um eine Platte mit LUKS zu verschlüsseln eignet sich das Laufwerketool. Die zu formatierende Partition auswählen und auf „Partition formatieren“ klicken:

Ihr geht den neuen Namen für die Platte an, damit meldet die sich dann später im System, und wählt „Passwortgeschützter Datenträger (LUKS)“ aus. Ggf. habt Ihr die Wahl zwischen LUKS und LUKS2, aber F30 hat die noch nicht. Wenn ja, nehmt ruhig LUKS2.

Ein ordentlich langes Passwort ist Pflicht. Danach dürft Ihr das noch einmal bestätigen und ein paar Sekunden später die Platte mit Hilfe des Lazy-Inits bereits bereit. „Lazy-Init“ meint, daß die Platte dort formatiert wird, wo Daten geschrieben werden sollen und nicht jetzt gleich die ganze Platte von Vorn bis Hinten formatiert wird. Das hätte nämlich bei 8TB 23 Stunden gedauert, da hatte ich wirklich keine Lust zu 😉

Die UUID ermitteln

Zwei Möglichkeiten eröffnen sich Euch: Ihr fragt das Laufwerkstool nach der UUID der neuen Platte ( Luks-Teil ) oder Ihr bemüht „blkid“ in der Konsole. Da wir diese eh gleich brauchen, bietet sich das an:

Erstmal ROOT werden:

$ su

dann suchen wir uns die UUID raus:

# blkid|grep sdd
/dev/sdd: UUID=“c16596bf-b40d-4c57-a46d-93b98d4bac47“ TYPE=“crypto_LUKS“

„sdd“ ist hier meine Platte. Eine UUID ist eine einmalige ID ( daher das zweite U ) die aufgrund eines einheitlichen Verfahrens ( das erste U ) erzeugt wird. Mehr müßt ihr darüber eigentlich nicht wissen.

Nun nehmen wir die UUID und tragen das passend in /etc/crypttab und /etc/fstab ein:

$ echo „/dev/mapper/luks-c16596bf-b40d-4c57-a46d-93b98d4bac47 /media/Huge ext4 defaults,x-systemd.device-timeout=0 1 2″ >>/etc/fstab

Da es sich um ein LUKS Laufwerk handelt und Devmapper das für uns managen wird, tragen wir den Devmapperpräfix und die UUID als Laufwerkspfad ein. „/media/Huge“ ist der Mountpoint, den Ihr bei Euch ggf. vorher noch anlegen müßt. Natürlich könnt Ihr auch einen anderen Pfad dafür nehmen, müßt Ihr wissen. Für alle Einsteiger: Der Mountpoint ist nichts weiter als ein leeres Verzeichnis. Das kann liegen wo Ihr wollt, aber /mnt/directory oder /media/directory bieten sich an. Wichtig ist, daß da nichts anderes gemountet ist und der Pfad nicht in einem anderen Mountpoint ist.

Beispiel:

/media/Small
/media/Bigger
/media/Huge

„ext4“ ist das Filesystem. Ihr werdet gemerkt haben, daß nach dem Formatieren der LUKS Partition ein weitere Partition unter der LUKS-Partition aufgetaucht ist. Da liegen Eure Daten dann wirklich drin. Das sieht so aus:

Diese Partition muß von Euch jetzt auch erst noch formatiert werden, dann natürlich passend zu dem Eintrag in der /etc/fstab, den wir gerade besprochen haben. Nehmt einfach Ext4, könnt Ihr praktisch nichts falsch machen. Wie Ihr sehen könnt, bekommt diese Partition eine eigene neue UUID. Aber das muß Euch jetzt nicht weiter belasten.

Damit die Platte jetzt auch beim Booten entschlüsselt wird und damit das Mounten/Einhängen des Laufwerks überhaupt erst möglich wird, tragt Ihr die UUID noch in die /etc/crypttab ein:

echo „luks-c16596bf-b40d-4c57-a46d-93b98d4bac47 UUID=c16596bf-b40d-4c57-a46d-93b98d4bac47 none“ >> /etc/crypttab

Das wars schon. Beim nächsten Booten ist die Platte dann sofort verfügbar.

„Keine Panik!“

Ok, eine freundliche Schriftart habe ich jetzt auf die Schnelle nicht zur Hand und großer geht es auch nicht, aber falls Ihr mal etwas vergessen oder Euch vertippt habt und Euer System nicht bootet.. KEINE PANIK!

Das löst sich ganz einfach:

1. den PC von einer USB-LIVE Disk booten.
2. Das Laufwerketool starten.
3. Eure Systempartition ggf. erst entschlüsseln und dann direkt im Tool mounten/einhängen.
4. TERMINAL öffnen
5. „su“ eingeben
6. „blkid“ eingeben
7. UUID in /etc/fstab und /etc/crypttab vergleichen
8. Tippfehler beheben und Rechner neu booten.

99% aller Fehler in dem Bereich sind Vertipper oder man hat es schlicht und ergreifend nicht abgespeichert 🙂

MySQL Workbench 8

Posted on 5. März 2020 by marius

Kleines Ratespiel: Wurde für diese Meldung eine SQL-Datenbank benutzt oder nicht? 🙂 Wenig überraschend lautet die Antwort: „Ja“. Das könnte an der weiten Verbreitung und den vielfältigen Anwendungsmöglichkeiten liegen. Es folgt übrigens keine SQL Einführung oder gar ein SQL Lehrgang 😉

Desktop-App: MySQL Workbench 8

Wenn man mit einer SQL-Datenbank arbeiten möchte, braucht man i.d.R. drei Dinge: Einen SQL-Server, einen SQL-Clienten und ein Programm, daß mit den Daten in der SQL-Datenbank etwas machen möchte.

Der im FOSS vermutlich am häufigsten eingesetzt wird, ist MariaDB. Dieser Fork von MySQL entstand, weil Oracle, die die Firma hinter MySQL gekauft hatten, der Meinung war, mal die Regel zu ändern. Das hat einem Teil der Gemeinde, die bislang MySQL mit entwickelt hatten nicht gefallen und so zogen/forkten Sie in eine eigene Trägergesellschaft „The MariaDB Foundation“ um. Zu den größten Sponsoren zählen Booking.com ( die mit den dicken Spamproblem ), Alibaba Cloud und Microsoft (die mit dem eigenen Closed Source MSQL-Server {Wieso eigentlich Microsoft!?!?!?!}), aber auch WordPress Hersteller Automattic, IBM und ein paar Andere.

Bei MariaDB handelt es sich also um den Serverteil, der verschiedene Datenbank Engines unter ein Dach bringt, so daß man diese mit dem SQL-Clienten der Wahl ansprechen kann. Im MariaDB Paket ist ein einfacher Kommandozeilen Client namens „mysql“ mit dabei. Ja, der heißt nicht „mariadb“ sondern „mysql“, weil das ein Fork von MySQL ist, der eine möglichst große Rückwärtskompatibilität anstrebt. Mit anderen Worten, für den Endbenutzer sollte sich nichts ändern. Möglich ist das, weil MySQL eine FOSS Entwicklung ist, die jeder clonen und weiterentwicklen kann, solange er sich an die Lizenzregeln hält.

Jetzt mag nicht jeder in der Konsole rumschrauben, auch wenn das nicht wirklich schwierig ist, und möchte vielleicht eine Desktop-Anwendung benutzen. Hier kommt die MySQL Workbench ins Spiel:

Wenn man das Fedora Paket MariaDB-Server installiert ( dnf install mariadb-server mariadb ), dann kann man direkt mit der Workbench mit der Arbeit anfangen, da der ROOT Zugang zu dem Datenbankserver nicht beschränkt ist. Das ist natürlich auf Dauer eine völlig untragbare Situation, aber irgendwie muß man erstmal in den Datenbankserver rein kommen, um dann dort die Zugangsdaten für den Rootzugang zusetzen 🙂 In meinem Beispiel ist das erst einmal kein Problem, da die spätere App auf einem abgesicherten Server neu aufgesetzt wird. Aber sobald Eurer Server übers Netz erreichbar ist, ist ein Passwortschutz unumgänglich.

Mein drittes Problem, das welches mit den Daten arbeiten soll, gibts noch nicht, aber das wird dann in PHP oder JAVA geschrieben sein. Beide Sprachen bringen einen kompletten Support für MySQL(und Forks) Datenbankserver mit.

Mit dem SQL-Clienten kann man jetzt die eigentlichen Datenbanken, Tabellen, Views, Indexe und in letzter Konsequenz auch die Datensätze anlegen und bearbeiten:

Im Beispiel oben die Datenbank namens „census“ und darin die Datenbanktabelle „users“.

Der eine oder andere könnte an der Tabellenbeschreibung erkennen, um was für ein Projekt es sich handelt, aber laßt Euch sagen, es funktioniert leider nicht sauber…{ PAM_MYSQL Frustanflug niederkämpf}.. Wie man hier sehen kann, ist die Ansicht der Datenzeile(n) reicht ansehnlich. Für einfache Bearbeitungen ist der Client gut zu benutzen, aber ehrlich gesagt ist PHPMyAdmin weitaus besser!

Also wenn Ihr mal ein Desktopprogramm sucht, mit dem Ihr in einer SQL Datenbank arbeiten könnte, das wäre ein brauchbares.

Für Fedora herunterladen könnt Ihr das hier: https://dev.mysql.com/downloads/workbench/#downloads Ihr müßt aber erstmal das passende OS ( hier Fedora ) auswählen, damit Euch die Downloadlinks angeboten werden. Das klappt sogar erfreulicherweise ohne Javascript 🙂 Die Fedora RPM-Pakete gibt es nur für 64Bit Versionen, aber das dürfte einen heutzutage nicht mehr wirklich stören.

Linux: Mehr Tester für Fedora!

Posted on 16. Februar 2020 by marius

Das Wort zum Sonntag

„Moin, Moin liebes Fedoravolk,

Schämt Euch! Ja…schämt Euch in Grund und Boden!
Ihr wollt alles immer für lau, aber so läuft das nicht!
Eure Taten sollen für Euch die Rechnung bezahlen,
deswegen TESTET! TESTET! TESTET! “
(Zitat: von Manager Bodhi, 20-20 )

So, oder so ähnlich, hätte das wohl geklungen, wenn Linux eine Religion wäre und der örtliche Glaubensvertreter Euch in den Allerwertesten treten wollte. Glück für Euch, Linux ist keine Religion. Nichts desto trotz, könntet Ihr ruhig mehr für Euch selbst tun und öfters mal zumindest bei sicherheitskritischen Sachen neue Updates testen!

Das Firefox 73.0-2 Update für Fedora 30 hing bis heute morgen 9.35 Uhr immer noch im Testbereich rum, wohingegen das gleiche Paket für F31 schon nach Minuten genug Testergebnisse zusammen hatte und bereits ins Stable gerutscht ist.

Koji and Bodhi in a Nutshell

Damit sich mehr Benutzer finden, die Tests mit Auswirkungen machen, sei am Beispiel von Firefox erklärt, wie man da als normaler Benutzer helfen kann:

Das ist der Testfall für Firefox 73.0-2 für Fedora 30 im BODHI System:

https://bodhi.fedoraproject.org/updates/FEDORA-2020-4e1ba1a692

Wenn man die Seite aufruft, sieht man als erstes die Installationsanleitung:

Die spannende Frage ist jetzt natürlich, wie kommt man überhaupt an den Links zu den Updates ran?

Dazu ruft man die Webseite ohne irgendetwas auf, z.b. so:

https://bodhi.fedoraproject.org/updates/

Ihr findet eine Suchmaske rechts oben:

Einfach „Firefox“ eingeben oder durch die Liste scrollen(aber das dauert etwas).

Updates sind intern eingeteilt in normale Programme und welche, die zum CritPath, also den kritischen Programmen, zählen. Firefox als „der“ Browser ist ein CritPath Programm, das Genologie Programm dagegen, ist nicht kritisch für den täglichen Betrieb beim Enduser, also ein normales Programm.

Testfälle

Entsprechend gibt es diverse Testfälle, die für solche Updates neben dem obligatorischen „Es startet überhaupt“ gibt. Für Firefox wären das diese drei:

Es gibt bei anderen Programmen auch welche mit deutlich mehr Testfällen. Der Maintainer kann auch spezielle Testfälle hinzufügen, wenn bestimmte Neuerungen das erfordern sollten um die Kompatibilität mit dem bisherigen Datenbestand zu sichern.

Die drei Fälle hier sind also „Addons: funktioniert die Addonseite, sind alle Addons da, kann man welche installieren“, „Browser: Kann man damit Webseiten aufrufen, gibts Probleme bei der Darstellung usw.“ und „Media: kann man Filme, Musik, Bilder ansehen und anhören.“

Wie man oben sehen kann, hat der Tester für alle drei grünes Licht gegeben, aber einiges anzumerken gehabt. Offensichtlich hat er den Test ernster genommen als Andere, die diese Testfälle nicht geprüft haben. Wenn man hier Tests macht, sollte man auf keinen Fall Testergebnisse fälschen, das bringt rein gar nichts, für niemanden.

Insgesamt sind min. 3 positive „Karma+1“ Wertungen nötig um ein Update als lauffähig zu markieren. Schauen wir uns mal an, wie die anderen Tester gewertet haben:

Nur einer der zwei Anderen hat den Browsertest gemacht und gewertet, daß er funktioniert ( der Firefox ). Die anderen Tests haben sich die zwei einfach erspart. Rechts oben auf dem Bild seht Ihr noch die automatisch durchgeführten Funktionstests und da hat das Update 3 nicht bestanden. Jetzt darf der Maintainer entscheiden, ob das missionskritische Fehler sind oder nur formale Fehler, und diese dann überstimmen.

Die Auswertung

Wenn keine automatischen Fehlerergebnisse vorliegen und das Karma +3 erreicht hat, wird dem Maintainer geraten und erlaubt, das Update ins Stable zu schieben. Das kann in Notfällen auch überstimmt werden durch den Maintainer, wenn z.b. die Hütte schon brennt, sollte man das Feuerwehrauto vielleicht nicht erst noch testen, sondern nur zusehen, daß Wasser im Tank ist. Das Äquivalent bei Software ist ein Remote-Exploit, der in der Wildnis (Internet) bereits zu der Lücke kursiert und PCs infiziert. Da ist es natürlich besser, wenn das aktualisierte Programm gar nicht mehr geht, statt die Leute weiter der Gefahr auszusetzen gehackt zu werden.

Ihr könnt mir glauben, wenn ich Euch sage, daß sich da keiner eine leichte Entscheidung macht. Desöfteren brauchte es massives Schubsen, daß Updates ins Stable gepusht wurden, um schlimmeres zu verhindern.

Karma +3

Ihr habt jetzt gelernt, daß es nur 3 positiver Tests bedarf um ein Update an die User raus zuschicken ( Umschreibung für „ins Stable schieben“ ).

Es hat bei FF73 für F30 satte 2 Tage gebraucht, bis 3 Leute einen Test gemacht hatten. Wenn man bedenkt, daß es sich um ein kritisches Sicherheitsproblem in Firefox gehandelt hat, ist das eher armseelig(für die Menschheit). 3 Menschen von 8.000.000.000 oder auch 0,000000037% der Menschheit.

Dafür das Fedora in den Jahren 2016-2018 4 Millionen Abrufe von Updates pro Monat hatte, Spiegelserver bei Unis nicht miteinbezogen, sollte man doch annehmen, daß es ein paar mehr Benutzer gibt, die da mal 3 Minuten für einen Test übrig haben, besonders, wenn es um Ihre persönliche Sicherheit geht, oder?

Wie wird man jetzt überhaupt Tester?

Jetzt der Teil, der für Mensch Nr. 4 aufwärts gedacht ist, die Antwort auf die Frage, wie man denn Tester werden kann. Ihr braucht: das passende OS für Euren Test ( Fedora 30/31 ) und ein Emailprogramm.

Die Emailaddresse braucht es zum Anmelden bei Fedora, denn Tester bekommen auch Emails mit Updates zu dem, was sie da testen ins Haus. Das ist schon daher wichtig, weil man so sieht, ob man etwas vergessen hat zu testen. Sollte einem da ein Fehler unterlaufen sein, kann man sein Testergebnis auch nachbessern, selbst wenn das Update dann zurückgezogen wird: Karma < -2 .

Wenn man sich hier angemeldet hat:

kann man schon loslegen. „Sign up now“ ist der Knopf für Euch, wenn Ihr noch keinen Login zum Fedora Authentication System „FAS“ habt. Mit so einem FAS Login kann man auch bei ASKFEDORA mitmachen, also der Plattform, die Fragen von Benutzern an Benutzer unterstützt. Und das wars schon. Mehr Aufwand ist nicht nötig um zu helfen.

Und was ist jetzt Koji?

Das ist i.d.R. meine Quelle, wenn ich wissen will, ob da schon eine Testversion unterwegs ist, oder nicht. Selbst wenn die Testversion den Test nicht bestanden hat oder aus anderen Gründen zurückgestellt wurde, kann man dort alle bekannten Versionen finden und downloaden.

Koji findet Ihr unter dieser Adresse: https://koji.fedoraproject.org/

Für Firefox sieht das derzeit so aus:

Wie man leicht erkennen kann, kommt das selbst bei renommierten Programmen vor, das man die nicht gebaut bekommt ( rot ). Jeden der Builds oben könnt Ihr dort passend für Euren PC ( OS+Architektur) runterladen.

Da kann man z.b. auch so Sachen machen, wie „mit FF 69 liefs noch, aber ich habe meine Daten nicht exportiert vor dem Update“ schon zieht man sich die alte Version, installiert diese, macht noch alle nötigen Anpassungen an seinen Daten zum Export und updated dann wieder auf die aktuelle Version hoch.

Auf welchem anderen OS kann man das schon machen? 😉

Marius Welt

Tag Archives: fedora