Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Erstmal großes Lob und vielen Dank für die Einblicke. Beim Überfliegen der Dell-spezifischen Pakete kam ich 1-2 Male ins Grübeln. Ebenfalls bei:
BlackPanther87 schrieb:
Dells eigene Dokumentation gibt dazu nichts her. Im Übrigen scheint MLK für "Mid Life Kicker" zu stehen - Referenzthread in Dells eigenem Forum. "Whitehaven" wäre dementsprechend vermutlich ein Dell-interner Codename für was auch immer (die Precision-Serie ist es nicht).
Der Reim den ich mir darauf mache ist:
MLK = Medialess License Kit
Whitehaven = AMDs Threadripper der ersten Generation
Das Paket könnte also das Überbleibsel einer Lizenz für irgendeine auf Threadripper optimierte Anwendung sein.
Vielleicht liege ich auch komplett daneben 😅
Das Paket könnte also das Überbleibsel einer Lizenz für irgendeine auf Threadripper optimierte Anwendung sein.
Vielleicht liege ich auch komplett daneben 😅
Macht für mich zwar wenig Sinn in einem Repository für Dell (deren AMD-Systeme sich wohl an einer Hand abzählen lassen - nicht drauf festnageln^^). Ist am Ende aber auch ziemlich egal. Ich habe die Ursprungsinstallation ja auf dem Originallaufwerk noch hier und werde im Laufe der nächsten Einträge mit Sicherheit nochmal einen genaueren Blick auf die Unterschiede werfen (mir ist z.B. noch mehr nebenbei aufgefallen, dass in der Ursprungsinstallation Hibernation deaktiviert war). Dazu wird diese dann in ein externes Gehäuse verpflanzt und eben davon gebootet.
also Deine bessere Hälfte benutzt dann auch das Notebook, auf dem Du Deine ach so hochwichtigen und schützenswerten Daten hast. Als wichtiger und hochbezahlter Spezialist müsstest Du doch eigentlich über die finanziellen Möglichkeiten verfügen, Ihr ein Notebook oder einen PC zu kaufen. Ich hatte während meiner Tätigkeit als IB-Ing. auch auf Reisen immer zwei Notebooks mit, eins für dienstliches und eins für privates.
also Deine bessere Hälfte benutzt dann auch das Notebook, auf dem Du Deine ach so hochwichtigen und schützenswerten Daten hast. Als wichtiger und hochbezahlter Spezialist müsstest Du doch eigentlich über die finanziellen Möglichkeiten verfügen, Ihr ein Notebook oder einen PC zu kaufen. Ich hatte während meiner Tätigkeit als IB-Ing. auch auf Reisen immer zwei Notebooks mit, eins für dienstliches und eins für privates.
Ohne allzu ausführlich zu werden als kurze Erläuterung:
Zunächst einmal ist der Einwand als solches natürlich valide und auch wichtig.
Allerdings haben sich die Umstände, unter denen ich dieses System nutzen werde, im Laufe des letzten Jahres doch recht deutlich verändert.
Ich bin - wie im Eintrag 5 (unter Eintrittswahrscheinlichkeit kurz) beschrieben - nicht mehr länger "klassischer" Berater. Stattdessen im Grunde zunächst mal "regulärer" Angesteller.
Früher hatte ich sehr wohl getrennte Systeme, was prinzipbedingt schon sicherer ist als meine Struktur.
Allerdings obliegt es natürlich zunächst mal meinem Arbeitgeber, für entsprechende Arbeitsmittel zu sorgen. Und man mag es kaum glauben, aber Siemens vertreibt tatsächlich spezielle Notebooks (die ich preislich gesehen für die meisten Anwendungen ziemlich überzogen finde, aber das nur am Rande).
Jedenfalls muss es für mich dennoch möglich sein, von zu Hause etwa ad-hoc-Analysen durchzuführen. Für die Hardware bin ich hier jedenfalls verantwortlich (Lizenzen ist was anderes).
Selbst wenn ich das wohl finanziell stemmen könnte, warum sollte ich? Von der Firma sehe ich nicht wirklich was dafür, mehr als 50% absetzen ist auch nicht drin (und wäre ja auch nicht fair und realistisch).
Trotz alledem versuche ich das, was ich im Rahmen meiner Möglichkeiten als sinnvoll erachte.
Die "ach so wichtigen" Daten werden im geplanten Setup zu keinem Zeitpunkt direkt auf dem System gespeichert. Alles geschieht über entsprechend gesicherte Medien, auf die ich ja auch schon einen Ausblick gegeben hatte.
Nur um das nochmal klarzustellen: Mir gefällt die Arbeit - und auch über meinen Arbeitgeber kann ich im Grunde nicht klagen. Knirschen tut's überall und ich brauche das wohl auch zu einem guten Teil.
Sicherlich mein treuester Begleiter in all den Jahren und funktioniert in Anbetracht des Alters nach wie vor hervorragend (gemessen an den Komponenten). Auf diesem schreibe ich diesen einleitenden Teil und führe den Großteil meiner aktuellen produktiven Arbeit aus (sofern nicht hohe Leistung gefordert ist).
Weder Fisch noch Fleisch - "Das verlorene Kind"
Gigabyte Aero 15xV8
Gekauft 2018
i7-8750H
GTX1070Max-Q
15" FHD IPS
32GB RAM (aufgerüstet von 16GB)
2x 2TB Samsung 970EVO (umgerüstet)
Realtek Gaming Ethernet
Intel Wireless-AC 8265
1x TB3
Hallo,
irgendwie verstehe ich es nicht mehr so ganz, Du hast doch noch zwei "alte" Notebooks.
Richtig, über das Aero schreibe ich im folgenden Abschnitt des gleichen Eintrages aber auch:
BlackPanther87 schrieb:
Für richtig grafikintensive Sachen benötige ich das noch, plane aber einen Verkauf, sobald das Dell einsatzbereit konfiguriert ist (aktuell laufen dort die meisten Anwendungen direkt auf dem gleichen Hostsystem).
Zudem ist das Clevo nun wirklich nicht mehr das jüngste (Sommer 2012 müsste das gewesen sein). Auch ist das Aero bereits "entkernt" (die SSDs sind ja ins Dell transferiert, ich habe dort nur noch das nötigste laufen). Zuletzt noch würde es mir unplausibel erscheinen, meiner Frau die Nutzung des Dells zu "verweigern", wenn ich dort meine eigenen privaten Sachen ja auch drauf laufen habe. Dazu müsste ich dann schon (wie von dir absolut richtig angemerkt) auf tatsächliche physikalische Trennung setzen.
Kurzum: Ich verstehe deine Gedanken, sehe aber bei mir nicht die Notwendigkeit, um meine Top-Priorität (Vermeidung der persönlichen Haftung bei Arbeitsdingen) zu erfüllen. Wenn ich selbstständig wäre, würde das jedenfalls anders aussehen.
Privat und professionell zu trennen ist ein einfacher sowie effektiver Ansatz. Am einfachsten zu erfüllen in deinem Fall (Frau und du selbst, welche ein Notebook/PC sowie du für private Dinge braucht) mit einem separaten, privaten Gerät.
Das die Firma bei welcher du als Angestellte arbeitest,ein solches selbst verwaltetes Gerät zulässt, lässt auch Fragen offen. KMU/Kleinbetrieb?
Für den obigen Schluss braucht es übrigens auch keine Risikoanalyse nach ISO 27001.
"na ja, über den Acount meiner Frau ist mein Kurzer an die Daten des Sortenspeichers der Anlage xy bei der Firma uv rangekommen und hat diese ins Internet hochgeladen". Das wären dann Gespräche, die man weder als Angestellter, noch als Freiberufler gern führen würde. Also irgendwie kann ich Deine Risikoanalyse und Dein Sicherheitskonzept nicht so richtig ernst nehmen, ich vergleiche das mal damit:
Man baut drei Türschlösser in der Haustür ein und legt die Schlüssel unter den Blumentopf der neben der Haustür steht. Ich würde jedenfalls niemals wg. ca. 400€ die zwei M2-SSDs kosten das Risiko eingehen, oben geschildertes Gespräch führen zu müssen.
@M. Linux
Ich bin da voll bei dir. Einige ergänzende Anmerkungen unten. Und ja, KMU.
@rgbs Anmerkung: Da zuvor Missverständnisse aufkamen - es geht hier um meinen Arbeitgeber. Auf dessen Anweisung sollen Dinge auf dem Privatsystem geschehen. Nun gäbe es hier natürlich verschiedene Vorgehensweisen:
Mach ich einfach nicht: Möglich, sicher. Aber da wäre die nächste Möglichkeit sehr viel passender und auch wahrscheinlicher für mich.
Kündigung: Könnte ich tun. Es gibt aber durchaus Gründe interner Natur, die mich glauben lassen, dass das sich mittelfristig bessern wird. Wenn nicht, kann ich das immer noch nachholen.
Wird gemacht, aber mir wird klar beschrieben, wie sich mein Arbeitgeber die Realisierung denn dann vorstellt.
Typischerweise würde man ja nun erwarten, dass das von der IT kommt. Gibts aber aus internen Gründen nicht, GF ist aber weiterhin der Ansicht, dass man "einfach machen" soll. Nun bin ich ja kein Unmensch, also lege ich die weiter unten beschriebenen Regeln zur Unterschrift vor.
IHR (die IT/GF, wer auch immer) legt fest, wie die Daten auf mein Privatsystem kommen.
IHR legt fest, wie ich die Daten an euch wieder übermittle nach Analyseende
ICH lege keine Backups in irgendeiner Art und Weise ab. Die Daten werden nach Abschluss der Analyse auf dem definierten Weg gesendet, das wars. Sollte irgendwas schief gehen (weil Mail-Server/Firewall/whatever) und Daten verloren gehen - nicht mein Problem.
Zu absolut keinem Zeitpunkt erfolgt eine Verbindung mit einer kundenseitigen Anlage in irgendeiner Art und Weise. Die Analyse erfolgt rein "offline" und wird über Signatur/Zeitstempel eindeutig einem Programmstand zugeordnet.
Sollte ich aus welchem Gründen auch immer mit angesprochenen System beim Kunden sein, erfolgt auch hier unter keinen Umständen eine Verbindung mit den Anlagen und/oder dem Kundennetzwerk.
Es wird eine Enthaftungserklärung erstellt, die mich im Falle von Fehlern, die nicht in meiner unmittelbaren Verantwortung liegen von jeglicher Schadensersatzforderung befreit. Dazu gehören insbesondere auch nicht definierte Bestandteile.
Das Ganze selbstverständlich unterschrieben (mind. GF) und notariell beglaubigt.
Wie schonmal geschrieben: Ich hätte das gerne auch anders. Irgendwie muss hier dann aber auch etwas Druck aufgebaut werden. Eventuell ist das im Rahmen meines (neuen) Systems ja auch zu gegebenem Zeitpunkt gar nicht mehr interessant.
Zweiter Punkt des Missverständnisses, da zugegebenermaßen recht unglücklich geschrieben. Auch hier Änderungen wieder in Kursiv:
Zudem sei gesagt, dass Sicherheit (im IT-Sinne) in KMU-Unternehmen im Automatisierungsumfeld immer noch in weiten Teilen Neuland ist. Aus meiner Erfahrung heraus sind sehr kleine Unternehmen hier oftmals gar nicht so schlecht aufgestellt (da der einzelne hier oft mehr Verantwortung hat). Auch größere Unternehmen (zahlenmäßig eben schwer zu sagen) haben prinzipbedingt oft schon ganz andere Strukturen. Aber die "irgendwo dazwischen" haben oft Probleme mit Abteilungsdenken und sehen das ganze nicht als Prozess. Da sagt dann die IT schonmal "geht mich nichts an" und der Programmierer auf Baustelle weiß nicht, wie er seine Arbeit erledigen soll. Das kann dann schonmal dazu führen, dass man Sachen erklären muss, die im Grunde zwar irgendwo jeder weiß, aber doch irgendwie sich eingeschliffen haben, wie z.B:
Whatsapp kein besonders gut geeigneter Weg zum Austausch von Sicherheitsprogrammen ist.
Passwörter für Sicherheitsprogramme, die Auftragsnummern im Klartext beinhalten vielleicht überdacht werden sollten.
VPNs auch durchaus im Automatisierungsfeld Anwendung finden können.
Aber nunja, ich bin an dieser Stelle dann auch raus für den Moment. Ich hoffe, ich konnte das ganze nochmal etwas klären und würde mich dann mal daran machen, das zu tun, wofür der Thread hauptsächlich gedacht war: Einträge schreiben.
ist schon klar, dass ich mit 35 Jahren Berufserfahrung als IB-Ing. keine Ahnung von IT Sicherheit habe und in den IT Abteilungen von z.B. VW oder TKS nur Dilettanten sitzen.
Aber schreib schön weiter Deine Einträge, sorgt ja auch irgendwie für Erheiterung bei denen, die wissen wo das Gewicht mit dem Stiel dran hängt.
@rgbs
Hast du etwas in den falschen Hals gekriegt? So eine unflätige Antwort ist zumindest nicht gerade das Passende zu seinen Posts.
Es klingt für mich, als ob sein AG aus Gründen möchte, dass er sein privates NB nutzt um dienstliche Dinge zu erledigen, aber er ihm kein Gerät dafür stellen möchte. Zu 100% habe ich es auch nicht durchschaut, so viel sei gesagt.
@rgbs
Hast du etwas in den falschen Hals gekriegt? So eine unflätige Antwort ist zumindest nicht gerade das Passende zu seinen Posts.
Es klingt für mich, als ob sein AG aus Gründen möchte, dass er sein privates NB nutzt um dienstliche Dinge zu erledigen, aber er ihm kein Gerät dafür stellen möchte. Zu 100% habe ich es auch nicht durchschaut, so viel sei gesagt.
Vielen Dank für diesen Kommentar. So sieht's nämlich aus. Ich bin aktuell nur am Handy. Habe aber schon gemerkt, dass ich an der ein oder anderen Stelle wohl nochmal editieren sollte, um Missverständnisse diesbezüglich zu klären. Wird dann in kursiv geschehen die nächsten Tage und entsprechend vermerkt.
Sorry, aber ich reagiere halt etwas "gallig", wenn mein Berufsstand pauschal angegriffen wird.
Den "Sprung" von drei auf null Notebooks verstehe ich jetzt auch nicht so ganz, aber da will der TE ja noch für Klarheit sorgen.
Am nähesten wird wohl irgendwann die Umstellung meiner VirtualBox-VMs auf KVM kommen. Aber wie schon geschrieben, brauchts da viele (viele) Tests und Übung, bevor ich mich traue, das für irgendwas kritisches zu nutzen.
Wenn der Umstieg etwas leichter fallen soll: Kannst dir ja mal virt-manager und libvirtd anschauen. Das macht die Bedienung vergleichbar einfach - und ist, wie Virtual Box, auch in Vagrant integrierbar.
Was meinst du eigentlich mit USB Dongle? HSMs? Also z.B. einen Yubikey?
@rgbs
Ich habe meinen letzten Kommentar nochmal etwas angepasst, da zugegebenermaßen ein Eindruck entstehen konnte, den ich nicht vermitteln wollte. Dafür Entschuldigung. Änderungen zur Nachverfolgung oben kursiv, im Spoiler als Vergleich.
Vielleicht hätte ich das irgendwo nochmal klarer rausstellen sollen, aber gut - irgendwie hab ich jedenfalls das Gefühl, dass irgendwie ein oft verklärtes Bild von Sicherheit im Automationsumfeld vorherrscht - im Folgenden mal die Bedingungen, die ICH gestellt hatte (EDITH meint, da anscheinend ja weiterhin nicht klar: an MEINEN Arbeitgeber... nicht etwa die IT, nein, wäre ja noch schöner), um überhaupt irgendwas arbeitstechnisches hier auf einem Privatsystem zu machen (auszugsweise):
Anmerkung: Da zuvor Missverständnisse aufkamen - es geht hier um meinen Arbeitgeber. Auf dessen Anweisung sollen Dinge auf dem Privatsystem geschehen. Nun gäbe es hier natürlich verschiedene Vorgehensweisen:
Mach ich einfach nicht: Möglich, sicher. Aber da wäre die nächste Möglichkeit sehr viel passender und auch wahrscheinlicher für mich.
Kündigung: Könnte ich tun. Es gibt aber durchaus Gründe interner Natur, die mich glauben lassen, dass das sich mittelfristig bessern wird. Wenn nicht, kann ich das immer noch nachholen.
Wird gemacht, aber mir wird klar beschrieben, wie sich mein Arbeitgeber die Realisierung denn dann vorstellt.
Typischerweise würde man ja nun erwarten, dass das von der IT kommt. Gibts aber aus internen Gründen nicht, GF ist aber weiterhin der Ansicht, dass man "einfach machen" soll. Nun bin ich ja kein Unmensch, also lege ich die weiter unten beschriebenen Regeln zur Unterschrift vor.
Zudem sei gesagt, dass Sicherheit (im IT-Sinne) in KMU-Unternehmen im Automatisierungsumfeld immer noch in weiten Teilen Neuland ist. Aus meiner Erfahrung heraus sind sehr kleine Unternehmen hier oftmals gar nicht so schlecht aufgestellt (da der einzelne hier oft mehr Verantwortung hat). Auch größere Unternehmen (zahlenmäßig eben schwer zu sagen) haben prinzipbedingt oft schon ganz andere Strukturen. Aber die "irgendwo dazwischen" haben oft Probleme mit Abteilungsdenken und sehen das ganze nicht als Prozess. Da sagt dann die IT schonmal "geht mich nichts an" und der Programmierer auf Baustelle weiß nicht, wie er seine Arbeit erledigen soll. Das kann dann schonmal dazu führen, dass man Sachen erklären muss, die im Grunde zwar irgendwo jeder weiß, aber doch irgendwie sich eingeschliffen haben, wie z.B:Nicht umsonst ist die Normenreihe 62443 ja gerade mal halb fertig. Und selbst wenn alle Teile erschienen sind, wird diese noch lange nicht angewandt (selbst bei Harmonisierung dauerts dann oft noch einige Jahre). Man muss auch sehen, dass der typische SPS-Programmierer oft keinen richtigen IT-Hintergrund (typischerweise mehr E-Technik) hat. Das im Zusammenhang mit oft jahrzehntelang eingefahrenen Prozessen lässt mich schon froh sein, wenn ich nicht erklären muss, dass z.B.:
Zur Frage mit Notebooks von "drei auf null Notebooks". Keine Ahnung, ob ich da jetzt wieder was falsch verstehe, aber:
Das Aero will ich verkaufen mittelfristig (bleiben 2).
Das Clevo ist ja schon betagt, ein simpler Austausch steht also sowieso an, auch aus simplen Performancegründen (würde 1 bleiben, bei Defekt).
Das Dell soll somit effektiv das Clevo ersetzen und mir nebenbei auch wieder die Möglichkeit (über EGPU) geben, ein wenig aktuellere Sachen zu spielen.
Nochmal: Das Thema Arbeit ist mehr ein "guter Wille" von mir gegenüber meinem Arbeitgeber. Dachte eigentlich, ich hätte im OP mal einen Absatz dazu vorbereitet, der ist aber wohl untergegangen. Wird dort nochmal klar gestellt.
dunkelmut schrieb:
Wenn der Umstieg etwas leichter fallen soll: Kannst dir ja mal virt-manager und libvirtd anschauen. Das macht die Bedienung vergleichbar einfach - und ist, wie Virtual Box, auch in Vagrant integrierbar.
Was meinst du eigentlich mit USB Dongle? HSMs? Also z.B. einen Yubikey?
Ist bereits in Planung mit virt-manager. Danke für die Anmerkung!
Und ja, sowas in der Art schwebt mir vor. Ob das jetzt am Ende Yubikey, NitroKey (persönlich eher mein Favorit) oder vielleicht auch die SmartCard direkt ist, werd ich dann aber sehen.
@BlackPanther87 Gute Klarstellung. Ich persönlich glaube zwar, dass die von dir beschriebenen Effekte (Abteilungsdenken, persönliche Verantwortung) weniger abhängig von der "Größe"/MA Anzahl ist als vielmehr mit der Unternehmenskultur zusammenhängt. Natürlich kann sich die auch mit der Größe ändern, aber es gibt doch sicherlich auch KMU, wo derlei Dinge einigermaßen klappen?
Letztendlich unerheblich. Das ist deine Erfahrung und ich danke dir für das Teilen der Erfahrung.
Ist bereits in Planung mit virt-manager. Danke für die Anmerkung!
Und ja, sowas in der Art schwebt mir vor. Ob das jetzt am Ende Yubikey, NitroKey (persönlich eher mein Favorit) oder vielleicht auch die SmartCard direkt ist, werd ich dann aber sehen.
Ach den Nitrokey hab ich mir angeschafft und war dann so enttäuscht von der Verarbeitung das er ausschließlich Backup Keys beeinhaltet. Das Case ist nur zumsammengesteckt und nur mit Fingernägeln kann ich den Stick zerlegen und wieder zusammen bauen. Alles andere als ein mobiler sicherer Ort für Schlüssel. Mein Yubikey 2 hingegen ist komplett zerschrammt, funktioniert aber wie am ersten Tag (rund 4 Jahre alt)
Natürlich kann sich die auch mit der Größe ändern, aber es gibt doch sicherlich auch KMU, wo derlei Dinge einigermaßen klappen?
Letztendlich unerheblich. Das ist deine Erfahrung und ich danke dir für das Teilen der Erfahrung.
Absolut richtig. Nur fällt es glaube ich manchmal relativ schwer zu erkennen, dass es ein Problem mit der Unternehmenskultur gibt.
Im Übrigen an dieser Stelle ein kurzes Update zum nächsten Eintrag: Dieser wird wohl eher nach dem Motto "etwas holprig" laufen. Ich habe gleich mal zwei fehlerhafte Installationsversuche mit meinem Debian-(Testing)-Host hingelegt, der ja zunächst mal ohnehin schon nur im Terminal laufen soll. Dazu komme ich im Eintrag an sich dann aber.
Im Übrigen hatte ich mir vom ersten Versuch alles schön Screenshots gemacht (gibt im Installer eine nette Funktion dafür). Diese aber aus lauter Dusseligkeit vor dem zweiten Versuch nicht runter gezogen (den ich dann mehr fix "hingeschludert" hatte, also auch nicht wirklich repräsentativ).
Dementsprechend habe ich heute selbstverständlich absichtlich noch eine fehlerhafte Installation durchgeführt, um die Screenshots diesmal "in ordentlich" zu haben.
Im nächsten Eintrag gibts dann somit eine Bilderstrecke, wo geraten werden kann, was eigentlich schief gelaufen ist. Die Erklärungen dazu werden noch ein paar Tage dauern.
Anmerkung: Entgegen erster Planungen musste ich diesen Teil - mal wieder - aufteilen. Insbesondere, da ich sonst im Zusammenhang mit dem folgenden und den ganzen Screenshots die anvisierte typische Länge von 2000 Wörtern je Eintrag vermutlich verdoppelt hätte (sind ja jetzt schon mehr). Dafür dauert der folgende
Bevor wir mit der eigentlichen Installation starten können, braucht es selbstverständlich ein entsprechendes Medium. Wenn ich ein neues System aufsetze, stelle ich mir aber die folgende Frage:
Vertraue ich dem Host, der das Installationsmedium vorbereitet?
Auf irgendeinem System muss das Medium ja beschrieben werden. Viele Leute wollen ihr System neu aufsetzen, weil es vielleicht nicht mehr sauber läuft. Vielleicht weiß man auch, dass das eigene Windows-System kompromittiert ist und will deshalb direkt zu Linux wechseln. Wo irgendwie möglich, sollte aber immer ein System genutzt werden, dass nicht (natürlich soweit bekannt) kompromittiert ist, wenn man eine sofortige Kompromittierung des Installationsmediums verhindern will. Am Ende kommt es auch hier wieder auf die gute alte Risikoanalyse an1, 2.
Neben sonstigen allgemeinen Dingen, die man natürlich bedenken sollte (Größe, Form des Mediums usw), gibt es bezüglich Debian im Speziellen noch die folgende wichtige:
Welches Installationsimage ist denn das richtige für mich?
Leider ist Debian eine Ausgeburt der Hölle hinsichtlich der Benutzerfreundlichkeit beim Finden des richtigen Installationimages für die eigene Hardware. Dies liegt (meiner Meinung nach) teils an Debians Konzept, standardmäßig nur freie Firmware mitzuliefern, teils auch an Debians offizieller Website3. Einige Beispiele:
Debians "Hauptseite" - https://www.debian.org/
Zugegebenermaßen wird oben rechts im Header versucht, den Download-Link für den "Netzwerk-Installer" zu platzieren. Dumm nur, dass einem zunächst mal keiner wirklich erklärt, um was es sich bei diesem "netinst"-Image bezüglich enthaltener Treiber eigentlich handelt. Siehe dazu Punkt 2.
Suche "Debian Download" - https://www.debian.org/distrib/
Fast zwangsläufig wird man auf dieser Seite landen, wenn man in den üblichen Suchmaschinen nach "Debian Download" sucht. Aber was ist denn nun das "richtige" hier? Ein kleines Image, das vollständige, Live-Images? Zudem wird auch hier mit keinem Wort etwas davon erwähnt, dass die Images nur freie Firmware beinhalten, eine Installation damit also unter Umständen gar nicht möglich ist.
Verifizierung des heruntergeladenen Images
Warum mir Debian auf der vorherigen Seite keinen effizienten und eindeutigen Weg gibt, an die Prüfsummen für die Downloads zu kommen, erschließt sich mir nicht. Ich hab mich ja daran gewöhnt, stattdessen einfach direkt die Image-Verzeichnisstruktur aufzurufen und darüber zu ermitteln, was ich eigentlich herunterladen muss.
Non-free Images eingegraben wie im Bunker
Wieso müssen Hinweise auf Images mit non-free Packages so vergraben sein? Ich kann den Hintergrund der Separation ja durchaus verstehen. Sucht man nicht speziell danach, wirds jedenfalls schwer. Im Einsteiger-Guide für Debian ist kurz mal was "inoffiziellen Images" die Rede. Jedenfalls verlinkt dieser auf diese Seite, in der ich dann wieder Images über Images in verschiedenen Ordnern herunterladen kann...
Nun die obige Liste bitte nicht falsch verstehen: Es hat schon seinen Grund, warum ich Debian für meine "Haupt"-Hostsysteme (gemessen an der Nutzungszeit) nutze. Mir ist auch bewusst, dass ein bedeutender Teil der Arbeit an Debian in der Freizeit durchgeführt wird. Und trotzdem bin ich jemand, der (vielleicht auch berufsdedingt) gerne mit dem Finger auf Sachen zeigt, die persönlich als verbesserungswürdig angesehen werden. Als Gegenbeispiel sei hier tatsächlich mal Ubuntu genannt: Download erstes Ergebnis in Google (wenn ich nur nach "Ubuntu" suche). Downloadinfo prominent auf der Startseite. Nach Starten des Downloads auch direkt die Infos zur Verifizierung auf der selben Seite.
Aber um nun auf die Frage zu antworten, welches Image ICH herunterlade:
Das "reguläre" netinst-Image, welches man auch über die Startseite von Debian bekommt, wie ich zuvor beschrieben hatte. Ich weis, dass meine Hardware mit dem "regulären" Image klarkommt - zumindest so weit, dass ich eine bootbare Installation erhalte, auf der ich aufbauen kann4, 5. Dabei nutze ich aber das navigierbare Verzeichnis. Dort habe ich dann auch gleich die Dateien zum Verifizieren.
Schlüssel ermitteln, den ich importieren muss (zuvor auf dem entsprechenden Rechner noch nicht geschehen).
Code:
$ gpg --verify SHA512SUMS.sign SHA512SUMS
gpg: Signatur vom Sun 09 Feb 2020 03:01:05 AM CET
gpg: mittels RSA-Schlüssel DF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: Signatur kann nicht geprüft werden: No public key
$ gpg --verify SHA512SUMS.sign SHA512SUMS
gpg: Signatur vom Sun 09 Feb 2020 03:01:05 AM CET
gpg: mittels RSA-Schlüssel DF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: Korrekte Signatur von "Debian CD signing key <debian-cd@lists.debian.org>" [unbekannt]
gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur!
gpg: Es gibt keinen Hinweis, daß die Signatur wirklich dem vorgeblichen Besitzer gehört.
Haupt-Fingerabdruck = DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B
Schlussendlich kann nun die Prüfsumme der ISO-Datei berechnet und mit der dokumentierten Referenz verglichen werden.
Code:
$ sha512sum -c SHA512SUMS 2>/dev/null | grep debian-10.3.0-amd64-netinst.iso
debian-10.3.0-amd64-netinst.iso: OK
Nicht ganz selbsterklärend, daher:
sha512sum liest den Inhalt der Datei SHA512SUMS und vergleicht die Prüfsummen mit -c der dort gelisteten Dateien gegen die der tatsächlich vorhandenen.
Es wird standardmäßig davon ausgegangen, dass sich die in SHA512SUMS aufgelisteten Dateien im gleichen (aktuellen) Verzeichnis befinden.
In SHA512SUMS sind mehrere Dateien aufgeführt. Für diejenigen, die nicht gefunden werden können (weil ich sie nicht heruntergeladen habe), werden entsprechende Fehler ausgegeben. Diese verwerfe ich mit 2>/dev/null. Die Zahl steht hierbei für stderr7.
Um nicht dennoch Nachrichten für nicht vorhandene Dateien nach Art %FEHLSCHLAG bei open oder read zu erhalten, begrenze ich die Ausgabe weiter auf das von mir tatsächlich heruntergeladene Image. Anmerkung: Dabei wird aber dennoch die Prüfung für alle in der Prüfsummendatei aufgeführten Dateien durchgeführt (ausgegeben wird eben nur das einzelne Resultat). Sollten also (warum auch immer) mehrere Image-Versionen heruntergeladen worden sein, kann eine Rückmeldung durchaus auch einige Zeit benötigen.
Wie man an obiger Ausgabe erkennt, konnte das heruntergeladene Image erfolgreich verifiziert werden.
Dass das funktioniert, kann natürlich relativ einfach geprüft werden. Dazu etwa die Prüfsummendatei mit einem beliebigen Texteditor öffnen und die letzte Stelle der Prüfsumme für die gewünschte Datei abändern (Länge muss gleich bleiben). Eine erneute Prüfung sollte dann FEHLSCHLAG melden.
Was nun natürlich noch verbleibt, ist das Übertragen der ISO-Datei auf ein USB-Medium. Hier gibt es nun ja verschiedenste Möglichkeiten. Guides empfehlen hier oft entsprechend spezielle Software wie Etcher. Ich persönlich greife hier wie vermutlich zu erwarten auf das Terminal und das gute alte dd zurück. Für das Erstellen "einfacher" Installationsmedien oder allgemein bootbarer USBs von einem Image nutze ich praktisch nur das. Keine zusätzliche Software notwendig und hat mich noch nie im Stich gelassen.
Ich persönlich prüfe in solchen Fällen VOR dem Verbinden des Zielmediums meine aktuell sichtbaren Laufwerke8.
Code:
$lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 232.9G 0 disk
├─sda1 8:1 0 10G 0 part /
├─sda2 8:2 0 208.1G 0 part /home/han/daten
└─sda3 8:3 0 14.8G 0 part
sr0 11:0 1 1024M 0 rom
Danach das Zielmedium anstecken und nochmal prüfen. Durch die Differenz zwischen beiden Ausgaben sollte sich eindeutig bestimmen lassen, welche Bezeichnung das Medium hat.
Code:
$lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 232.9G 0 disk
├─sda1 8:1 0 10G 0 part /
├─sda2 8:2 0 208.1G 0 part /home/han/daten
└─sda3 8:3 0 14.8G 0 part
sdb 8:16 1 14.7G 0 disk
sr0 11:0 1 1024M 0 rom
Somit weiß ich nun, dass das Zielmedium die Bezeichnung sdb hat. Also wird im Folgenden das Image direkt darauf geschrieben.
WICHTIG: Man sollte bei der Eingabe lieber doppelt prüfen, dass auch das richtige Medium angegeben ist. Sonst kann es schonmal geschehen, dass unbewusst eine Systempartition beschrieben wird! Ebenso sollte bedacht werden, dass zuvor auf dem Medium vorhandene Daten danach praktisch "weg" sind (zumindest nicht ohne weiteres wiederherstellbar und auch nicht klar, was). Zugegebenerweise ist dies im Falle von installierten NVME-Laufwerken weniger wahrscheinlich, da die Bezeichnungen dort anders gestaltet sind9.
if=debian-10.3.0-amd64-netinst.iso
Kurz für "input file" und offensichtlich das Image, welches auf den USB-Stick geschrieben werden soll.
of=/dev/sdb
Kurz für "output file" - da in Linux ja alles eine Datei ist, eigentlich auch logisch. WICHTIG:ddfrisst hier potenziell alles - Dateien, Partitionen, ganze Laufwerke. Mit den entsprechenden Berechtigungen (wie durch sudo üblicherweise gegeben) auch OHNE Rückfrage10. Man sollte sich also absolut sicher sein, wo das hin geht!
BS=1M
Gibt an, dass dd in Blöcken von 1MB kopieren soll. Hat entsprechend Auswirkung auf die Kopiergeschwindigkeit und unter Umständen auch auf die Lebensdauer des Speichermediums. Mehr als 1M bringen in aller Regel keine wirklichen Vorteile mehr.
&&
Erlaubt die Verkettung von Befehlen. Im vorliegenden Fall würde der nachfolgende Befehl nur ausgeführt, wenn der erste Teil erfolgreich war.
sync
Stellt sicher, dass nach Beendigung des Kopiervorgangs keine Daten mehr im Schreibpuffer des Arbeitsspeichers befinden. Sollte üblicherweise nicht notwendig sein, wenn das Medium ordnungsgemäß ausgehängt wird (dann wird nämlich genau das ausgeführt), aber ist für mich dennoch einfach eine entsprechende Angewohnheit.
Bevor ich nun von meinem soeben erstellten Installationsmedium boote, verbleibt nch eine wichtige Sache zu tun: das BIOS abzusichern. Dabei gehe ich persönlich eher nach dem Motto "weniger ist mehr". Das nötigste sollte eingestellt sein und man sollte sich mit Sicherheit auch alle verfügbaren Optionen mal anschauen. Aber oftmals bringt hier "Rumspielen" mehr Schlechtes als Gutes.
Zur Absicherung gehört natürlich auch die entsprechende Aktualisierung. Bei meinem Precision 7540 ist die Treiberseite schnell gefunden, das zum Zeitpunkt dieses Beitrags aktuelle BIOS ist vom 08.04.2020 (also augenscheinlich durchaus aktuell gepflegt). Bei Dell sind BIOS-Updates jedenfalls "einfache" exe-Dateien. Herunterladen und ganz gewöhnlich auf einen beliebigen USB-Stick kopieren. Dieser muss explizit (bei meinem Modell zumindest) nicht bootfähig sein.
Also angesteckt und ins Bootmenü gewechselt (F12). Dort gibt's dann einen separaten Punkt mit "BIOS Update". Daraufhin startet die Dialogauswahl der exe-Datei. Nach kurzer Prüfung, kann man auch gleich loslegen11. Das eigentliche Update dauert eine gute halbe Stunde. Danach nochmal ins BIOS zur Kontrolle booten, sieht soweit zunächst einmal alles in Ordnung aus. Ich hatte im Vorfeld meines Updates einige (halbwegs aktuelle - Mitte März) Berichte mit nicht funktionierendem Bootvorgang unter Linux im Akkubetrieb gelesen. Natürlich dann sogleich getestet - und glücklicherweise nicht zu bestätigen12.
Jedenfalls wechselte ich nun nochmals zurück ins BIOS. Es war an der Zeit, ein entsprechendes Administratorpasswort zu setzen, dass unerwünschte Änderungen an meinen BIOS-Einstellungen verhindert. Es bringt nämlich das schönste LUKS nichts, wenn einfach ohne Gegenwehr im BIOS herumgeändert wird. Ebenso sollte das Booten von einem externen Laufwerk nicht ohne weiteres möglich sein. Dells BIOS ist hier im Grunde selbsterklärend. Es gibt auch noch weiterführende Optionen, mit denen man Einfluss auf die Passwortqualität nehmen kann. Ebenso kann ein Systempasswort gesetzt werden (dass dann aber bei jedem Bootvorgang eingegeben werden muss). Von Interesse ist hier für mich auch die Option "UEFI Boot Path Security", da hiermit bestimmt wird, dass bei einem Start von einem externen Laufwerk das Administratorkennwort eingegeben werden muss (in der Standardeinstellung zumindest). Von internen Laufwerken hingegen kann ohne Passwort gebootet werden.
Es hat schon seinen Grund, warum ich das immer wieder so penetrant erwähne... und ich werde es weiter tun^^.
Eine mögliche Alternative (die ich in der Vergangenheit auch schon genutzt habe):
Zunächst einmal Erstellen des Mediums auf dem unsicheren Host.
Entfernen aller internen Speicherlaufwerke.
Booten vom externen Medium, sodass eine Live-Session genutzt wird.
Erstellen des eigentlichen Mediums aus dieser Live-Umgebung heraus.
Vernichten der alten Laufwerke wäre hier aber (je nach Risikoappetit) empfohlen.
In jedem Fall bleibt hier eine gewisse Unsicherheit, da Sachen wie kompromittierte Firmware, BIOS usw. nicht abgedeckt werden.
Zugegebenermaßen ist Debian keine wirklich einsteigerfreundliche Distribution bzw. gibt sich auch nicht als solche aus. Wirkliche Neulinge sind bei Ubuntu oder Manjaro (je nach Vorlieben, persönlich würde ich ja - trotz aller Abneigung - ersteres empfehlen) wohl besser aufgehoben.
Viele Benutzer werden eben nicht wissen, dass ihre eigene Hardware vielleicht das non-free Image benötigen würde, um überhaupt eine erfolgreiche Installation durchführen zu können. Gerade in Zeiten, in denen (leider) immer weniger Notebooks einen dedizierten Ethernet-Port besitzen, wird das wohl zunehmen. Als Beispiel sei hier nur mal das relativ populäre Dell XPS 13 (Debian-Guide dazu) genannt.
Dennoch sei gesagt, dass das netinst-Image bei meinem Systemaufbau nur von eingeschränktem Nutzen ist. Konkret geht es darum, dass ich damit faktisch nur das erste Hostsystem einer LUKS-Partition installieren kann. Ist bereits ein anderes System auf dieser Partition installiert, müsste ich das LUKS-Volume während der Installation über das Terminal manuell entriegeln. Etwas, das über das netinst-Image nicht geht.
Man mag sich die Frage stellen, ob die hier dargestellte Warnung denn ein Problem darstellt. Kurz gesagt: Nein, tut sie nicht. Sie besagt lediglich, dass dem entsprechenden Schlüssel nicht explizit vertraut wurde (auf dem lokalen System). Wer dazu mehr wissen will, dem kann ich diese exzellente "Einführung" ans Herz legen, für die vorliegende Warnung dabei insbesondere den Abschnitt zur Schlüsselbeglaubigung.
Mehr Infos zu solchen und ähnlichen Umleitungen zum Beispiel in Ubuntus Wiki.
Nachdem ich den entsprechenden Abschnitt auf meinem Dell mit ParrotOS in der Live-Umgebung geschrieben habe und nicht schon hier auf das eigentliche Layout spoilern wollte, kommt die Ausgabe von Ubuntus Wiki.
Und genau hier zeigt sich dann doch ein Vorteil von spezieller Software für diesen Zweck: Dort ist es in der Regel natürlich nicht möglich, ein Systemlaufwerk so ohne weiteres zu überschreiben. Am Ende kommt die Universalität eben doch mit einer gewissen Verantwortung.
Es sei angemerkt, dass sogar der umgekehrte Weg funktioniert. Es ist sehr wohl möglich, aus einer Partition ein Image zu erstellen. Dazu kann für if etwa eine Partition definiert werden, für of dann eben die Zieldatei.
Dabei fällt mir im Übrigen auf, dass ich anscheinend doch eine relativ alte BIOS-Version vom August letzten Jahres drauf habe. Das Update von 1.2.3 auf 1.8.2 ist doch ein recht großer Schritt und wieso es Dell bei meiner BTO-Konfiguration nicht geschafft hatte, direkt ein aktuelleres aufzuspielen, weis ich nicht.
Ich vermute eine Fehlerbehebung durch das neuere BIOS. Alternativ auch eine Verbindung mit NVIDIA GPUs, da von einigen berichtet wurde, das gebootet werden kann, wenn diese deaktiviert ist. Das Hinzufügen des Kernel-Parameters dis_ucode_ldr war wohl auch eine Art Workaround.
Anmerkung: Nun geht's mit diesem Eintrag also endlich mal ans Eingemachte - das erste Hostsystem wird aufgesetzt. Regelmäßige Leser sollten in diesem Zusammenhang die Anmerkungen beachten, die ich in den Eröffnungspost hinein editiert habe. Zudem ist dieser Beitrag dann auch gleich als kleines "Negativbeispiel" gedacht, da es zunächst ja nicht so gelaufen ist wie gedacht.
Auch deshalb hier wieder wichtig: Gewisse Teile dieses Beitrags zeigen Fehler in den Screenshots. Für Spezialisten wird es relativ schnell klar, wo der Fehler passiert. Anfänger sollten sich aber vielleicht doch etwas mehr Zeit zum Lesen nehmen, um zu verstehen, warum die zunächst genutzte Installationsweise nicht funktionieren kann.
Zunächst einmal ist dieser Eintrag der mit Abstand längste bisher (damit meine ich nicht aufgrund der Screenshots). Ich war ernsthaft am Überlegen, das nochmal zu splitten. Allerdings hätte etwa die alleinige Darstellung der fehlerhaften Installation thematisch nicht gepasst. Außerdem deutet der (Unter)Titel des Beitrags es schon an: Ich habe für diesen Eintrag 4 Installationen meines ersten Debian-Hosts durchgeführt. Um das zu verstehen, die folgende Auflistung.
Der erste Versuch war "einfach so" fehlerhaft. Zunächst einmal kein tieferer Sinn dahinter, ich beschreibe das ja weiter unten. Zu erwähnen ist hier vielleicht, dass ich bei dieser Installation mein tatsächlich geplantes LVM-Layout genutzt hatte.
Die zweite Installation war dann zum Testen schnell dahin "geschludert" (nicht das vorgesehene LVM-Layout). Nachdem der Fehler dann erneut auftrat, fiel tatsächlich das berühmte "Brett vorm Kopf"...
Ich war ja so clever, von der ersten Installation mit der (hervorragenden) Screenshot-Funktion des Debian-Installers entsprechende Bilder zu machen. Nur wurde dieser Geniestreich dann von meinem Kurzzeitgedächtnis getilgt und natürlich war nach der zweiten fehlerhaften Installation alles futsch. Also musste es selbstverständlich noch mal eine dritte absichtlich gleich fehlerhaft gestaltete Installation wie Nummer 1 sein. Hiervon stammt auch die Screenshot-Serie zur Fehlersuche.
Nachdem mir klar war, warum die Installation zuvor nicht funktionieren konnte, musste natürlich die schlussendlich richtige folgen. Diese ist dann nun auch grundsätzlich wie geplant bootbar (nur Terminal, dazu unten noch mehr).
Die zwei Testinstallationen, die ich zusätzlich in einer VM für noch fehlende Screenshots durchgeführt habe, unterschlage ich mal. Jedenfalls ergab sich aus dem Gedanken eines Tagebuchs nach dem ersten fehlerhaften Versuch dann eben der Gedanke, dass auch so darzustellen. Deshalb findet ihr im folgenden Abschnitt zunächst relativ viele Screenshots, die den grundsätzlichen Installationsprozess dokumentieren sollen. Dazu auch entsprechende Kommentare, was ich mir beim einzelnen Punkt so denke. Denjenigen, die etwas mehr Erfahrung mit Linux besitzen (ich sage absichtlich nicht Debian), wird der Fehler wohl relativ schnell auffallen.
Selbstverständlich wird es viele Leute geben, denen der Fehler sofort auffallen wird: /boot kann nicht ohne weiteres auf einem verschlüsselten Volume liegen (etwas, das ich auch gar nicht anwenden will, davon abgesehen).
Also starten wir das System mit unserem vorbereiteten USB-Stick und greifen auf das Einmal-Bootmenü zu (F12 bei meinem Dell). Hier muss ich zunächst einmal kein Passwort eingeben1. Der USB-Stick taucht wie erwartet als Boot-Option auf, gekennzeichnet mit einem Stern links davon. Das Booten von diesem erfordert dann die Eingabe des BIOS-Administratorpassworts. Beim Start-Bildschirm von Debians Installer wähle ich dann jedenfalls "Graphical Installer"2 und lande bei...
Ich denke nicht, dass ich hier groß was dazu schreiben muss. Von Interesse ist vielleicht wie schon angedeutet die Screenshot-Funktion unten links, mit der der aktuelle Bildschirm in /var/log/installer der finalen Installation geschrieben wird. Was mir hier aber auffällt: das integrierte Touchpad funktioniert nicht. Hatte ich ehrlich gesagt vorher nie so auf dem Schirm bzw. auch nie wirklich wahr genommen. Eine externe Maus ist aber jedenfalls hilfreich, wenn man schon das graphische Frontend nutzen will. Unabhängig davon ist die Bedienbarkeit des Installers auch über die Tastatur jedenfalls exzellent. Springen wir nun jedenfalls einige Bildschirme vorwärts3.
Ich definiere, wie auf dem Screenshot gezeigt entgegen Debians Empfehlung in der Tat kein Passwort für den Root-Account. Damit erhält der erste Benutzer (der in den nächsten, nicht gezeigten Bildschirmen erstellt wird) die notwendigen Berechtigungen, um Root-Rechte zu erlangen. Dazu sei allerdings gesagt, dass dieser erste Benutzer nicht mein Account für die tägliche Nutzung sein wird. Die Deaktivierung des Root-Accounts und stattdessen die Nutzung von sudo bringt für mich vor allem auch die Nachvollziehbarkeit durch entsprechendes Logging4. Die folgenden Bildschirme zur Definition des sudo-Nutzers überspringe ich hier.
Aufgrund meines geplanten Partitions- und LVM-Layouts bleibt mir nur die manuelle Partition. Für die meisten Nutzer wäre hier stattdessen wohl eine der anderen Optionen zu empfehlen5.
Dazu gibts nicht allzu viel zu sagen, man sieht aber, dass bereits auf beiden Laufwerken GPT-Partitionstabellen vorhanden sind.
Zuerst erstelle ich die EFI-Partition, die für das Booten eines UEFI-Systems eben notwendig ist. Vielmehr gibts auch hier nicht zu sagen.
Die zweite Partition wird selbstverständlich für das verschlüsselte Volume genutzt. Ich belasse die weiteren Parameter hier auf den Standardeinstellungen.
Zurück in der Übersicht nach dem Erstellen der beiden zuvor genannten Partitionen, unmittelbar vor Initialisierung des verschlüsselten Volumes.
Wie man sieht, könnte man auch direkt mehrere Partition und/oder Geräte verschlüsseln. In meinem Fall wird wie zu sehen, zunächst einmal nur die eine Partition verschlüsselt6.
An dieser Stelle muss dann nochmal die eigentliche Verschlüsselung des Volumes bestätigt werden. Das könnte man mit der Festlegung der entsprechenden Option bei der Definition der Partition zuvor unterbinden (falls man etwa bereits zuvor das komplette Laufwerk mit Zufallsdaten überschrieben hat). Den Bildschirm zur Definition des Verschlüsselung-Passworts überspringe ich an dieser Stelle.
Interessanter ist vielleicht die Nachfrage von Debian bei (sehr) schwachen Passwörtern für die Verschlüsselung.
Zurück in der Partitionsübersicht sehen wir nun das verschlüsselte Volume. Allerdings mit ext4 als Dateisystem, was natürlich nicht passt.
Also setze ich die Verwendung des verschlüsselten Volumes entsprechend.
Schon besser und bereit zur Konfiguration meiner LVM-Struktur (über "Logical Volume Manager konfigurieren", in Screenshot nicht angewählt). Den Bildschirm zur Bestätigung der notwendigen Änderungen an den Partitionstabellen überspringe ich hier.
Wie zu sehen ist, wird das verschlüsselte Volume nun als verfügbares physikalische Volume gelistet. Die Screenshots zum Erstellen der entsprechenden Volume Group überspringe ich hier wieder.
Die erstellte Volume Group wird mir wie erwartet für die Erstellung meiner logischen Volumes zur Verfügung gestellt. Die einzelnen Screenshots zur Erstellung der LVs sind hier wohl recht uninteressant, daher übersprungen.
Das hier ist dann das schlussendlich vorbereitete LVM-Layout für den ersten Host in meiner Testumgebung7.
Zurück in der Partitionsübersicht sieht das zunächst einmal recht verwirrend aus. Die einzelnen Volumes sind aber ja bereits so benannt, dass klar werden sollte, was für was gedacht ist. Zu diesem Zeitpunkt ist aber noch kein einziges Volume wirklich eingerichtet.
Nur beispielhaft die Definition des root-Volumes. Dies unterscheidet sich hier im Grunde nicht von einer "regulären" Partition. Im folgenden überspringe ich die Einrichtung der anderen Volumes.
Hier sieht man nun die schlussendliche Vorbereitung der einzelnen Volumes. Bevor es weiter geht, sollte dies natürlich nochmals geprüft werden8.
Die schlussendliche Aufforderung zur nochmaligen Bestätigung der durchzuführenden Partitionierung. Ich springe wieder einige Bildschirme weiter.
Auch wenn's mit der Installation an sich jetzt wohl nur am Rande zu tun hat. So sollten Fehlerberichte gehandhabt werden (Opt-In, hallo Ubuntu...)9!
Wie man sieht, installiere ich zunächst keine Desktopumgebung. Selbst wenn ich hier KDE mit dem entsprechenden Eintrag direkt nutzen könnte, entspricht die Paketauswahl dann ganz und gar nicht meinen Vorstellungen. Ich will ja zunächst eben einen Virtualisierungshost, auf dem nur ein minimale Selektion von für mich unentbehrlichen Tools läuft10.
Somit sind wir also fertig mit der Installation und nun geht's ans Booten. Na dann schauen wir mal...
Ähmja, so war das aber jedenfalls nicht gedacht. Was ist passiert11? Nun, zunächst mal habe ich den (praktisch gesehen) gleichen Fehler nochmal gemacht. Beim zweiten Erblicken dieses Bildschirms war dann der Moment gekommen...
YouTube
An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.
Anmerkung: Es liegt mir fern, hier einen kompletten Guide zum Bootprozess in Linux zu schreiben. Ich stelle nur die für mich wichtigen Punkte zusammen, um eine Herleitung zu zeigen, warum die oben gezeigte Installationsweise fehlschlagen muss. Dabei stütze ich mich unter anderem auf den (auch hier wieder hervorragenden, leider aber nicht auf Deutsch) Eintrag des Arch-Wikis.
Technische Vorüberlegungen
Wie im vorherigen Abschnitt beschrieben, war mir die Ursache für den Fehler dann doch mit einem Mal klar. Es ist mir persönlich aber sehr wichtig, bei Sachen, die zu Fehlern führten, einen Schritt zurück zu machen und zu schauen, wieso das passieren konnte - und meine Schlussfolgerungen entsprechend zu dokumentieren. Seht diesen Abschnitt also als Dokumentation auch für mich an12.
Wenn wir von der technischen Seite überlegen, läuft ein Bootvorgang (unter UEFI) grob wie folgt ab.
Power ein durch den Benutzer
Nach der grundlegenden Funktionsprüfung (Power-On-Self-Test) liest das System die in der Firmware definierten Boot-Einträge. Dies lässt sich auch daran erkennen, dass bei den meisten Systemen während des POST-Bildschirms entsprechende Tasten gedrückt werden müssen, um das einmalige Bootmenü zu erreichen.
Das System bootet den gewünschten Eintrag mit der hinterlegten EFI-Anwendung. Ob es sich hierbei um GRUB oder einen anderen Bootloader handelt, ist erst einmal zweitrangig. Ich beschränke mich im Folgenden verständlicherweise auf GRUB.
GRUB übernimmt und liest die entsprechende Konfiguration aus /boot/grub/grub.cfg.
Das GRUB-Menü mit den dem Bootloader zugeordneten verschiedenen Einträgen wird angezeigt. Das können dann entsprechend Einträge für verschiedene Distros, jede unter Umständen wieder mit verschiedenen Kerneln usw. sein. Unter Umständen aber auch komplett benutzerdefinierte Einträge.
Das Root-Dateisystem wird gemountet und der Kernel geladen.
Das Init-System übernimmt (oftmals Systemd, es gibt aber natürlich auch Alternativen).
Anhand der individuellen Konfiguration werden notwendige Programme, Services, usw. gestartet (dazu gehört auch der Desktop, siehe auch Runlevel - wieder Arch).
Für die Beurteilung des Fehlers ist es nun wichtig, zu verstehen, an welchem Punkt des Bootvorgangs wir uns befinden.
Es wird relativ schnell klar, dass die ersten beiden Punkte durchlaufen sind, da wir ja eine Liste an entsprechend zu bootenden UEFI-Einträgen zur Auswahl haben.
Auch Punkt drei sollte durchlaufen sein, da wir ja zumindest mal in einem GRUB-Terminal landen, die Applikation an sich also grundsätzlich erstmal gestartet werden konnte.
Danach scheint Punkt 4 aber nicht mehr durchgeführt worden zu sein, denn sonst... ja, sonst müssten wir irgendwann ja nach unserem LUKS-Passwort gefragt werden.
Moment, irgendwie muss GRUB ja wissen, wo das Root-Dateisystem abgelegt ist (bei Nutzung von LVM eben in welchem logischen Volume. Dies ist in /boot/grub/grub.cfg definiert.
Schauen wir uns an dieser Stelle doch nochmal die Partitionsübersicht aus der Installation an.
Ähmja... Nachdem aber /boot ja innerhalb meines Volumes 19000_debian liegt, welches sich wiederrum innerhalb des verschlüsselten Volumes befindet, kann GRUB dieses ja gar nicht finden.
Nach kurzer Überlegung fällt mir auch ein, das Debian in seinen geführten Installationen /boot auf eine separate (standardmäßig unverschlüsselte) Partition packt.
An dieser Stelle war nun eigentlich ein kleiner Test geplant: Innerhalb der VM müsste es ja möglich sein, die fehlerhafte Installation dennoch zu booten, sofern das entsprechende Volume bereits entschlüsselt ist und damit die GRUB-Konfiguration gefunden werden kann. Aus mir unerfindlichen Gründen scheint das im vorliegenden Fall mit cryptomount im GRUB-Terminal nicht zu funktionieren (nicht das klassische Rettungsterminal). Ein Blog-Post, der das im Prinzip recht gut beschreibt, ist zum Beispiel hier (englisch) zu finden.
Dabei gibt cryptomount macht cryptomount anhand der folgenden Befehle einfach... nix. Wichtig dabei nochmals: NICHT das Rettungs-Terminal.
Verfügbare Geräte listen
Code:
grub> ls
(proc) (hd0) (hd1) (hd1,gpt2) (hd1,gpt1)
Dateisystem der Devices prüfen.
Code:
grub> ls (hd1,gpt2)
Partition hd1, gpt2: No known filesystem detected - Partition start at 976896KiB - Total size 19993600KiB
Zwar wird kein Dateisystem erkannt, allerdings erkenne ich an der Größe, dass es sich um das verschlüsselte Volume handeln muss - (hd1,gpt1) ist deutlich kleiner. Also lade ich das entsprechende Modul und versuche das Volume zu öffnen (ohne Klammern).
Code:
grub> insmod luks
grub> cryptomount hd1,gpt2
Normalerweise sollte da ein Passwortprompt erscheinen - tuts jedenfalls nicht. Hab das auch mit einigen anderen Befehlen, Devices, mit Klammern usw. probiert. Bringt alles nichts. Ob das jetzt an der VM-Umgebung (inkl. VirtualBox), Debian an sich, fehlerhafter Bedienung meinerseits oder sonst was liegt, kann ich nicht sagen. In der Praxis ist das aber auch relativ egal und definitiv ein "Nischenproblem". Dort würde ich nämlich immer direkt ein Live-System nutzen, dass mir von Haus aus schon sehr viel mehr Möglichkeiten bietet. Dementsprechend gibt es auch sogut wie keine Resourcen, die sich überhaupt mit dieser Situation beschäftigen. Davon abgesehen war's mir dann doch zu doof, nochmal eine absichtlich fehlerhafte Installation (als tatsächliches System) nur dafür zu erstellen. Vielleicht hole ich das ja aber nochmal nach, wenn mir langweilig werden sollte^^
Nachdem nun klar ist, woran es zuvor gescheitert ist, im Folgenden die entscheidenden Unterschiede. Ich zeige hier verständlicherweise nicht alle Screenshots, sondern nur die wichtigen.
Änderungen im Detail
Auffallend hier ist, dass ich eine zweite - unverschlüsselte - Partition für LVM erstelle (dazu gleich mehr). Das verschlüsselte Volume für die Testumgebungen wandert zudem ans "Ende" der SSD (kein funktioneller Hintergrund, rein persönliche Präferenz). Die ESP-Partition ist außerdem noch etwas vergrößert.
Hier sollte man nun prinzipiell einschätzen können, wo die Reise hingeht. Ich habe eine Volume Group für verschiedene Bootloader erstellt. Ich nutze dann unterschiedliche Volumes, um diese besser zu separieren, da ich zu gegebenen Zeitpunkt gerne Chainloading nutzen würde. Somit sind auf dem "regulären" Bootloader z.B. nur meine "Standard-Systeme" (Privat, wohl auch Gaming) verfügbar. Die Testumgebungen etwa sollen später in einem eigenen Bootloader gelistet sein, der über den regulären aufgerufen wird (Chainloading). Somit sollte das im regulären Loader besser aufgeräumt bleiben. Auch das Risiko, durch Updates im Rescue-Terminal zu landen, sollte mit einer solchen Separation sinken.
Anmerkung: Ja, da fehlt Swap - ich lege unabhängig des Arbeitsspeichers persönlich immer etwas dafür auf die Seite (ja, auch bei 128GB). In der schlussendlichen Installation ist das vorhanden, siehe lsblk weiter unten.
Wie man sieht, ist das die Definition des Volumes, dass für /boot genutzt werden soll. Viel mehr gibts dazu eigentlich nicht zu sagen.
Das schlussendliche (neue) Partitionslayout, diesmal auch mit Swap13. Davon abgesehen (und natürlich /boot) hat sich nicht wirklich was geändert.
Somit wäre ja ein erstes Hostsystem prinzipiell installiert. Nutzbar ist das natürlich nicht wirklich (auch wenn ich es grundsätzlich interessant fände, einige Zeit mal "terminal-only" zu probieren). Mit diesem "Testsystem" werde mich wohl für einige (mehr) Einträge beschäftigen, in denen ich viele Konfigurationsmöglichkeiten teste, bevor das im späteren Verlauf dann "einfach" auf den "Produktionshost" per Blaupause übertragen wird.
Im nächsten Eintrag werde ich mich jedenfalls zunächst mit meiner persönlichen Prozedur zum Backup meiner Host-Systeme beschäftigen. Dazu werde ich (wie schonmal angedeutet) nicht auf Clonezilla zurückgreifen. Auch Timeshift werde ich für reguläre Hosts nicht nutzen (für Testumgebungen siehts da etwas anders aus, aber ich will am Anfang ja ein "nacktes" Backup). Daher werde ich auf eine angepasste Live-Version von ParrotOS setzen (dazu gibts unten im Bonus-Teil ja schon eine kleine Vorschau). Dabei werde ich am Anfang auch darauf eingehen, warum ich das überhaupt für meine Backups nutze und wie sich damit ein "teil-persistentes" Medium schaffen lässt.
Bonus: Screenshots aus nicht bootbarer (Debian-)Installation ziehen
Nachdem ich für die fehlerhafte Installation sowieso die Screenshots ziehen wollte, dachte ich mir: Warum das nicht direkt als kleinen zusätzlichen Teil zur Verfügung stellen?
Anmerkung: Das folgende bezieht sich zwar konkret auf den Debian-Installer und wie man eben dennoch an die erstellten Screenshots kommt. Ein Großteil davon sollte aber unabhängig von der Distribution sein und sich auch für andere Teile (wie etwa das manuelle Mounten verschlüsselter Volumes) nutzen lassen15.
Zunächst mal benötigt ihr ein Live-Medium, von dem gebootet werden kann. Welches ist relativ egal, im Zweifel sollte jedes halbweg bekannte wie Ubuntu und Derivate funktionieren. Ich persönlich nutze hier ParrotOS (konkret die Security-KDE-ISO).
Nachdem wir also in unserer Live-Umgebung sind, prüfe ich zunächst einmal die vorhandenen Block Devices.
Code:
$lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 3.6G 1 loop /usr/lib/live/mount/rootfs/filesystem.squashfs
sda 8:0 1 14.7G 0 disk
`-sda1 8:1 1 14.7G 0 part /media/user/AAC2-634A
nvme0n1 259:0 0 1.8T 0 disk
|-nvme0n1p1 259:1 0 1.9G 0 part
`-nvme0n1p2 259:2 0 186.3G 0 part
nvme1n1 259:3 0 1.8T 0 disk
Nachdem ich weiß, das nvme0n1p2 mein verschlüsseltes enthält, versuche ich dieses doch einfach mal, entsprechend zu öffnen16.
Code:
$sudo cryptsetup luksOpen /dev/nvme0n1p2 host-testing
Enter passphrase for /dev/nvme0n1p2:
Es erfolgt an dieser Stelle keine explizite Bestätigung für ein erfolgreiches Öffnen. Ein fehlerhaftes Passwort oder eine fehlende Option würde gemeldet. Hierbei ist ein (grundsätzlich beliebiger, hier eben host-testing) Name für das Volume notwendig, da es zum Ansprechend mit cryptsetup danach benötigt wird.
Nachdem das nun erledigt ist, schauen wir nochmal nach lsblk.
Wir sehen, dass host-testing erfolgreich geöffnet werden konnte.
Zudem wird offensichtlich, dass die auf dem verschlüsselten Volume befindlichen logischem Volumes automatisch erkannt und aktiviert wurden.
Ist das crypt-Volume vorhanden, die logischen Volumes aber (aus welchem Grund auch immer) würde ich zunächst versuchen, die entsprechende Volume Group manuell mit sudo vgchange -a y [I]volume-group_name[/I]
Unter Umständen ist dann eine genauere Fehlersuche notwendig (pvscan, vgscan usw.). Das soll hier jetzt auch kein LVM-Guide werden.
Da ich weiß, dass die Screenshots unter /var/log liegen sollte, mounte ich also das entsprechende logische Volume.
Code:
$sudo mount /dev/mapper/vg19_hosts_testing-19061_var_log /mnt
Nachdem wir den Ablageort der Screenshots theoretisch kennen, schauen wir doch mal, was so vorhanden ist.
Nun kann man den installer-Ordner theoretisch komplett kopieren, um etwa die Fehlersuche durch andere Nutzer zu unterstützen. In meinem Fall bin ich aber nur an den Screenshots interessiert, somit schränke ich den Umfang etwas ein und kopiere auf meine zuvor genannten separaten USB.
In der Tat, die logischen Volumes werden noch als aktiv/verfügbar angezeigt (das a-flag weist darauf hin). Als ändern wir das doch mal für alle Volumes von vg19_hosts_testing.
$sudo vgchange -an vg19_hosts_testing
0 logical volume(s) in volume group "vg19_hosts_testing" now active
Nachdem das nun erledigt ist, kann das LUKS-Volume ohne Probleme geschlossen werden. In der Anzeige der Block-Devices taucht es danach wie erwartet nicht mehr auf.
Code:
$sudo cryptsetup luksClose host-testing
$lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 3.6G 1 loop /usr/lib/live/mount/rootfs/filesystem.squashfs
sda 8:0 1 14.7G 0 disk
`-sda1 8:1 1 14.7G 0 part /media/user/AAC2-634A
nvme0n1 259:0 0 1.8T 0 disk
|-nvme0n1p1 259:1 0 1.9G 0 part
`-nvme0n1p2 259:2 0 186.3G 0 part
nvme1n1 259:3 0 1.8T 0 disk
Das mag zunächst einmal wie ein Sicherheitsproblem wirken. Selbst auf das BIOS kann zugegriffen werden. Bei genauerem Blick ist es das nicht wirklich. Das BIOS wird nur lesend geöffnet. Und auch im Einmalbootmenü können (ohne weiteres) nur Boot-Optionen gewählt werden, die von internen Laufwerken starten. Außerdem ist auch der Zugriff auf die Diagnosesoftware ohne Passwort möglich (was ja erstmal je nach Umständen durchaus sinnvoll sein kann). Das Wichtigste aber - das Booten von externen USB-Laufwerken - benötigt immer zwingend das Administratorkennwort. Und am Ende muss eins doch klar sein: Effektiven Schutz bei unerwünschtem physischen Zugriff gibt's am Ende nicht.
An dieser Stelle sei gesagt, dass das GUI in Debians Installer eigentlich nur ein Overlay ist. Die Menüpunkte in der einfachen "Install"-Option sind praktisch identisch benannt und strukturiert. Mit Ausnahme der Screenshot-Funktion gibt es keine nennenswerten Unterschiede. Etwas mehr ins Detail geht hier Debians offizielle Doku (englisch).
Auch hier wieder: Ich will den Installationsprozess gar nicht bis ins kleinste Detail dokumentieren. Dafür gibt's genug andere (richtige) Guides.
Manch einer mag hier argumentieren, dass das Deaktivieren des Deaktivieren des Root-Accounts ja Sicherheit durch Obskurität ist. Selbstverständlich stellt diese Maßnahme allein keinen wirklichen Schutz vor einer gezielten Attacke dar. Und ein entsprechend fähiger Angreifer weiß in der Regel, dass der Nutzer mit der ID 1001 in aller Regel per sudo root-Rechte erlangen kann (die eigene ID kann man übrigens einfach mit id im Terminal abfragen). Das Wichtige hier ist jedenfalls, dass ich mich nicht auf diese Maßnahme verlasse. Vielmehr interessieren mich die bessere Nachvollziehbarkeit aufgrund vollständigem Logging, sodass ich später auch eigene Fehler aufdecken kann (auch das Logging kann natürlich mit sudo wieder umgangen werden, darum geht's hier aber auch nicht).
Wie man es erwarten würde, wäre der bei mir auftretende Fehler bei einer Nutzung der "Geführt"-Optionen nicht passiert.
Bei Interesse über die Implikationen von unpartionierten Bereichen in Zusammenhang mit Laufwerksverschlüsselung (mit SSDs) empfehle ich diesen Blog-Post (englisch). Für mich persönlich ist das Risiko jedenfalls überschaubar und akzeptabel. Davon abgesehen denke ich auch, dass diejenigen, die sich Gedanken über so etwas machen sollten, über die entsprechenden Auswirkungen bereits Kenntnis besitzen.
Aufmerksame Leser mögen vielleicht bemerken, dass das Layout nicht ganz dem gezeigten Konzept in Beitrag #5 entspricht. Natürlich kann (und sollte bei Bedarf) ein solches Konzept sich auch ändern, wenn für notwendig befunden. Am Ende mag das aussehen, wie es will - ich persönlich versuche aber immer Dokumentation und Konsistenz im Auge zu behalten.
Als Dateisystem nutze ich durchgehend ext4, wie man sieht. Meiner Ansicht ist dies nach wie vor das stabilste und insbesondere bei meiner Multiboot-Umgebung würde ich ungern mit unterschiedlichen Dateisystemen hantieren. Außerdem sind (zu diesem Zeitpunkt) auch keine individuellen Mount-Optionen definiert.
Der Punkt ist, dass ich gerne individuell entscheide, ob ich bei einer bestimmten Installation das Senden von (wenn auch anonymisierten) Daten zulassen will oder nicht. Und diese Entscheidung sollte vorzugsweise immer als "explizite Zustimmung" gewertet werden, nicht umgekehrt.
Wer wissen will, was hier eigentlich im Detail installiert wird, dem empfehle ich die (leider nur englische) offizielle Wiki-Seite zu KDE. Die Selektion der "Standard-Systemwerkzeuge" ist dann im Übrigen für mich wirklich von Belang, da entweder durch andere Pakete oft benötigt oder durch mich ohnehin manuell installiert (apt-listchanges z.B.)
Wie man am Screenshot vielleicht erkennt, stammt dieser nicht von meinem eigentlichen System sondern aus einer (absichtlich) fehlerhaft installierten VM mit funktionell gleicher Konfiguration (UEFI, LVM-Konfig usw., Größen selbstverständlich reduziert). Im Übrigen sei hier angemerkt, das (U)EFI mit VBox nicht für die tägliche Nutzung empfohlen ist. Siehe dazu auch das offizielle Debian-Wiki.
An dieser Stelle wieder mal meine Einschätzung aus dem Maschinenbau. Ob man das ganze nun "Projektabschlussgespräch", "Lessons learned" oder wie auch immer nennt, ist erstmal relativ egal. Ich denke, wir alle sind uns einig, dass eine grundsätzliche Besprechung nach Projektabschluss sehr sinnvoll ist. Bei Problemen in KMUs wird in solchen Besprechungen leider oft Leuten der berühmte "schwarze Peter" zugeschoben, die sich entweder nicht wehren können (weil sie nicht anwesend sind, sehr gut) oder im Grunde nicht isoliert etwas dafür können. Nehmen wir zum Beispiel an, "der Programmierer" hat es auf Baustelle nicht hinbekommen, den Taktzeitnachweis zu liefern. Ist das nun der Fehler des Programmierers oder vielleicht der Projektplanung, die einen ohnehin straffen Zeitplan definiert hat. Vielleicht waren auch andere Sachen zu tun (Sicherheitsabnahme, für die keine wirkliche Zeit eingeplant wird, ist ein Klassiker). Am Ende ist es jedenfalls nicht schwarz und weiß.
In älteren Guides ist hier oft von "RAM mal 2" die Rede. Wie viel man wirklich braucht, hängt hierbei aber von der individuell geplanten Nutzung ab. Ist etwa der Ruhezustand gewünscht, benötigt man im Maximalfall schon den gesamten Arbeitsspeicher + 1GB. Anhand der von mir definierten Größe merkt man schon, dass ich das nicht nutzen werde. Vielmehr hat es für mich den Grund, zumindest zu merken, wenn der Arbeitsspeicher aus welchen Gründen auch immer volllaufen sollte. Das merkt man nämlich in der Tat unmittelbar. Mag bei 128GB unrealistisch sein, dennoch ist das für mich mehr eine gute Angewohnheit denn absolute Notwendigkeit. Ein recht guter Blog-Post dazu ist etwa hier zu finden (englisch).
Wer sich über die Fehler der nicht gefundenen Volume Group wundert: Kein wirkliches Problem. Wie dieser (fast schon uralte, aber der neueste Kommentar ist gar nicht soo alt) Bug-Report von Debian zeigt, ist das eine lang bekannte Eigenschaft von Systemen, die auf LVM on LUKS setzen. Das war meinen eigenen Beobachtungen bisher auch absolut stabil (immer zwei mal, bevor die Aufforderung fürs Passwort kommt), selbst in der VM. Man könnte das wohl durch Anpassung der initramfs-Skripte versuchen zu beheben. Allerdings fällt das für mich eher unter die Kategorie "ohne wirkliche Not kaputt basteln".
Außerdem ist zu erwähnen, das beim Debian-Installer im Speziellen die Option "Save debug logs" sich nur auf die Speicherung weiterführender Logs zum eigentlichen Installationsvorgang auswirkt (allgemein wird all dies unter /var/log/installer abgelegt). Die Screenshots werden unabhängig davon abgelegt, sobald die entsprechende Schaltfläche betätigt wird.
In der Terminalausgabe ist sda ein separater USB-Stick, auf dem ich die Screenshots ablegen will. Der Live-USB für ParrotOS ist hier schon nicht mehr zu sehen, da er zuvor entfernt wurde.
