Der Anbieter meines Virtual Private Server (VPS) führt Wartungsarbeiten durch, wodurch es in genanntem Zeitraum zu einer Downtime von ca. 45 Minuten kommen wird.
Bis neulich.
Im März 2023 wechselte ich von Flex-Work in eine neue Rolle, in der ich 100 % remote arbeite. Heute möchte ich meine Erfahrungen mit euch teilen, die ich bisher damit gemacht habe.
Bevor es richtig losgeht, schreibe ich etwas zur Terminologie der Remote-Arbeit. Denn hier geht es mit den Begrifflichkeiten teilweise ganz schön durcheinander. Daher möchte ich sicherstellen, dass ihr versteht, was ich mit bestimmten Begriffen meine.
Von allen verwendeten Begriffen ist dies der Einzige, welcher in Deutschland in der Arbeitsstättenverordnung definiert ist:
Telearbeitsplätze sind vom Arbeitgeber fest eingerichtete Bildschirmarbeitsplätze im Privatbereich der Beschäftigten, für die der Arbeitgeber eine mit den Beschäftigten vereinbarte wöchentliche Arbeitszeit und die Dauer der Einrichtung festgelegt hat. Ein Telearbeitsplatz ist vom Arbeitgeber erst dann eingerichtet, wenn Arbeitgeber und Beschäftigte die Bedingungen der Telearbeit arbeitsvertraglich oder im Rahmen einer Vereinbarung festgelegt haben und die benötigte Ausstattung des Telearbeitsplatzes mit Mobiliar, Arbeitsmitteln einschließlich der Kommunikationseinrichtungen durch den Arbeitgeber oder eine von ihm beauftragte Person im Privatbereich des Beschäftigten bereitgestellt und installiert ist.
ArbStättV §2 Abs.7
Erbringen Arbeitnehmende die geschuldete Arbeitsleistung zum Teil am Telearbeitsplatz und zum Teil in einem Büro des Arbeitgebers, wird von alternierender Telearbeit gesprochen.
Bei dieser Form ist der Arbeitgebende für die vollständige Ausstattung des Arbeitsplatzes mit Mobiliar und Arbeitsmitteln sowie der Einhaltung arbeitsrechtlicher Vorschriften (z.B. Ergonomie, UVV, Prüfung ortsveränderlicher Elektrogeräte, etc.) verantwortlich.
Diese Begriffe werden häufig verwendet, wenn Arbeitnehmende die geschuldete Arbeitsleistung teilweise außerhalb der Büroräume des Arbeitgebers erbringen und es sich nicht um Telearbeit handelt.
Angestellte erhalten hierbei häufig keine komplette Büroeinrichtung für den Telearbeitsplatz im privaten Raum, sondern lediglich die notwendigen Arbeitsmittel, wie z.B. Laptop und Telefon. Dafür dürfen sie häufig auch außerhalb der eigenen vier Wände bzw. des Büros z.B. aus einer Ferienwohnung arbeiten.
In manchen Fällen werden voll ausgestattete Büroarbeitsplätze für die Angestellten vorgehalten. In anderen Fällen existiert eine Form von Desksharing.
Details werden in Arbeitsverträgen, Betriebsvereinbarungen und Tarifverträgen geregelt.
Der Duden definiert das Wort Homeoffice wie folgt:
[mit Kommunikationstechnik ausgestatteter] Arbeitsplatz im privaten Wohnraum
URL: https://www.duden.de/rechtschreibung/Homeoffice
Der Begriff wird jedoch nicht einheitlich verwendet. Betrachtet man die Quellen [1]-[5], so wird er sowohl als Synonym für Telearbeit als auch als Oberbegriff für alle Formen von Arbeit verwendet, die nicht in Büroräumen des Arbeitgebers ausgeführt werden.
Wenn ich in diesem Text den Begriff Homeoffice verwende, meine ich damit mobile Arbeit, wie sie im folgenden Abschnitt beschrieben wird.
Bei der mobilen Arbeit sind Angestellte keinem Büro zugeordnet und nicht an einen Teleheimarbeitsplatz gebunden. Die geschuldete Arbeitsleitung kann von einem beliebigen Ort wie z.B. dem Auto, Café, Hotel oder dem Strand erbracht werden. Dies schließt die eigenen vier Wände jedoch explizit mit ein.
Dem Arbeitnehmenden werden bei dieser Form häufig nur die zwingend benötigten Arbeitsmittel wie Laptop, Mobiltelefon und ggf. Headset gestellt. Bring you own device ist ebenso möglich. Häufig erhalten Angestellte eine Pauschale, mit der sie benötigte Arbeitsmittel selbst beschaffen können.
Details werden auch hierbei im Arbeitsvertrag, in Betriebsvereinbarungen oder Tarifverträgen geregelt.
Nicht jede Tätigkeit ist dazu geeignet, im Homeoffice ausgeführt zu werden. Pflegepersonal kann den Beruf meist ebensowenig aus den eigenen vier Wänden ausüben wie Bus-, LKW-, Zug-Fahrer und Kapitäne. Auch Berufe mit Laufkundschaft eignen sich in der Regel schlecht für Arbeit außerhalb eines festen Büros.
Ich gehöre hingegen zu den glücklichen Menschen, deren Job von einem fast beliebigen Ort aus erfüllt werden kann. Die einzige Bedingung ist eine gute Daten- und Kommunikations-Verbindung. Meine berufliche Tätigkeit lässt sich dabei mit folgenden Stichpunkten beschreiben:
Mit diesen Merkmalen habe ich die besten Voraussetzungen, um nicht auf einen festen Arbeitsplatz beschränkt bzw. angewiesen zu sein.
Zu Beginn meines Arbeitsverhältnisses wurde ich mit folgenden Arbeitsmitteln ausgestattet:
Ausgeliefert wurde das System mit einem RHEL 8 Corporate Standard Build (CSB). Die Installation wird also von unserer internen IT verwaltet. Ich selbst habe sudo-Rechte auf dem System und fühle mich in keinster Weise eingeschränkt. Ich bin fasziniert, wie gut die Inbetriebnahme ablief und es so gut wie keine Probleme gab, wegen denen ich den IT-Support bemühen musste.
Bei dem Laptop handelte es sich nicht um ein topaktuelles Modell, doch ist es für meine tägliche Arbeit sehr gut geeignet. Ich nutze es täglich für die Arbeit mit:
Im Vergleich mit meinem privaten ThinkPad T14s ist das Gerät nach einigen Videokonferenzen deutlich lauter. Die Effizienz der CPU und Lüftersteuerung sind beim P1 nicht so gut wie beim T14s.
Das Thunderbold-Dock hingegen ist das schlechteste Dock, das ich je selbst benutzen musste. Dass für diesen elektronischen Briefbeschwerer im Online-Versandhandel zwischen 250,- und 300,- EUR aufgerufen werden, macht mich fassungslos. Hier funktioniert nichts, wie es soll. Und auch nach einer Firmware-Update-Orgie ändern sich die Fehler, in Summe bleiben sie jedoch gleich. Ich musste mich jedoch nicht lange damit ärgern. Da die Probleme bekannt sind, konnte ich mir ein Dock meiner Wahl beschaffen und die Kosten dafür erstatten lassen.
Zusätzlich zu diesen Arbeitsmitteln bekam ich noch ein Budget, für das ich mir weitere notwendige Arbeitsmittel kaufen konnte, plus ein separates Budget für ein Mobiltelefon. Von diesen Mitteln habe ich beschafft:
Zum Telefon gehört ein Vertrag. Ich konnte beides aus einer Liste auswählen. Zur Auswahl standen auch diverse Geräte von Apple, Samsung und weiteren Herstellern.
Mein Arbeitsplatz sieht in der Regel sehr aufgeräumt und unaufgeregt aus.
Ich besaß bereits vor meinem Jobwechsel einen höhenverstellbaren Schreibtisch, den ich mir für meinen Rücken gegönnt habe. Aus privater Tasche habe ich mir dann noch Bürostuhl Tailwind 2 mit Pending-System und Ponso-Sitzfläche beim lokalen Händler https://www.fair-kauf.net/ gekauft.
Wenn während der Zeit etwas kaputtgeht oder ich feststelle, dass mir doch noch etwas fehlt, bespreche ich dies mit meinem Manager. Bisher war es kein Problem, die Ausgaben für Anschaffungen, die ich sinnvoll begründen konnte, erstattet zu bekommen.
Ich bin mit meinen Arbeitsmitteln sehr zufrieden und kann meine Arbeit damit gut erledigen. Neben der Technik betrachte ich es als unschlagbaren Vorteil, ein eigenes Arbeitszimmer zu besitzen, welches nur von mir zum Zweck der Arbeit genutzt wird. Dies hat für mich folgende unschlagbare Vorteile:
Hinsichtlich Raum und Arbeitsmittel kann ich aktuell nichts bemängeln und fühle mich gut ausgestattet.
Kommunikation ist wichtig und findet statt, sobald sich mindestens zwei Menschen eine Situation teilen, sich am gleichen Ort oder in der gleichen Videokonferenz befinden. Die Kommunikation findet dabei auf unterschiedlichen Ebenen statt, der Sach- und der Beziehungsebene, wobei die Beziehungsebene die Sachebene bestimmt.
Eine Nachricht, die von Mensch zu Mensch übertragen wird, hat mehrere Seiten und muss vom Empfänger nicht so verstanden werden, wie der Sender sie gemeint hat.
Bei diesen Aussagen handelt es sich um Erkenntnisse von Paul Watzlawick und Friedemann Schulz von Thun aus der Kommunikationswissenschaft (siehe [7]-[10] in den Quellen unten). Kommunikation stellt einen sehr wichtigen Faktor bei der Arbeit dar und beeinflusst in hohem Maße die Produktivität sowie die Motivation der Angestellten.
Viele Artikel und Blogs verkürzen dieses Thema auf Aussagen wie:
Mich stört, wenn so getan wird, als wäre die Realität schwarz oder weiß. Ist sie doch in Wirklichkeit grau (ein Blick aus dem Fenster bestätigt dies aktuell) und liegt die Wahrheit doch meist in der Mitte.
Ich möchte hier die Kommunikationskultur in der Firma und dem Team beschreiben, wo ich aktuell beruflich zu Hause bin. Da ich zu 100 % remote arbeite, finden für mich, von wenigen Kundenbesuchen im Jahr abgesehen, fast alle Meetings per Videokonferenz oder Telefon statt. Die einzige Bewertung, die ich dabei vornehme ist, dass es mir persönlich gut gefällt.
Wie in vermutlich jeder Firma gibt es auch bei uns regelmäßig wiederkehrende Meetings. Dazu gehören unter anderem:
Kurz gesagt, die 40-Stunden-Woche bietet nicht genug Zeit, um an allen möglichen Meetings teilzunehmen. Doch das erwartet auch niemand.
Was mir gut gefällt:
Benötigt man ein paar zusätzliche Augen bzw. Ideen beim Troubleshooting bzw. der Suche nach Informationen, öffnet man ein virtuelles Meeting und lädt Kolleg*innen via Chat ein. Entweder wählt man einen Kanal mit vielen Mitgliedern und hofft, dass jemand kommt oder man schreibt Teilnehmer gezielt an. Dabei gebietet die Etikette, dass man vorher prüft, ob die entsprechende Person auch frei ist. Möglich ist dies mithilfe unserer Kalender oder des Status im Chat.
Dabei ähneln diese Meetings den Störungen im Büro, wo die Tür aufgeht und Kollegen mit ihren Sorgen, Nöten und Anträgen plötzlich vor dem eigenen Schreibtisch stehen. Vorteil der Remote-Arbeit ist in meinen Augen, dass die Hemmschwelle sich diesen Störungen zu entziehen geringer ist. Eine Meetinganfrage lehnt man schneller ab oder verlässt ein Meeting schneller, als jemanden aus dem Büro hinauszubitten.
Für mich ist wichtig, vorher zu überlegen, ob der synchrone Austausch einen Vorteil über asynchrone Kommunikation bietet. Dies ist zum Beispiel der Fall, wenn sich ein Sachverhalt nur umständlich in einer E-Mail erklären lässt, oder das Risiko eines Missverständnisses hoch ist. Grundsätzlich gebe ich der asynchronen Kommunikation den Vorzug, da ich Kollegen so nicht in ihrer Arbeit störe, sie in ihrer eigenen Zeit antworten können und E-Mails Beweise generieren.
Obwohl ich ausschließlich aus dem Homeoffice arbeite, habe ich das Gefühl, weniger Zeit in Meetings zu verbringen als zuvor. Gemessen habe ich dies jedoch nicht.
Kaffeeküchengespräche, Gesabbel beim Mittagessen und Flurfunk sterben bei mobiler Arbeit aus. Das stimmt in meiner Erfahrung so nicht.
Wir treffen uns sporadisch zum Kaffeetrinken in einer Videokonferenz und sprechen darüber, wie unser Tag so läuft, was es Neues gibt. Dabei werden sowohl dienstliche wie private Themen diskutiert.
Manche Kollegen treffen sich sogar in einer Videokonferenz, ohne aktiv miteinander zu sprechen. Man könnte auch sagen: „Sie schweigen sich konstruktiv an.“ Dies kann das Gefühl reduzieren, allein zu sein. Es ist jemand in der Nähe, der zuhört und in aller Regel auf geräuschvolle Äußerungen reagiert.
„Vermisse ich regelmäßige persönliche Treffen in der realen Welt? Nein.“
„Weiß ich diese Treffen dennoch zu schätzen? Ja.“
In meinen Augen ist dies kein Widerspruch in sich. Ich habe mich schnell daran gewöhnt, dass mein Team verteilt sitzt und die meisten Kontakte durch Chat, E-Mail und Videokonferenz stattfinden. Dennoch freue ich mich, diese Menschen am Rande von Veranstaltungen auch mal persönlich zu treffen. Besonders gern, wenn dies ungezwungen außerhalb formal organisierter Teambildungsmaßnahmen passiert.
Dies sind definitiv zwei meiner Hauptarbeitsmittel. Beide sind Werkzeuge zur asynchronen Kommunikation. Chat ist dabei in der Regel schneller als E-Mail, wobei ich persönlich E-Mails besser strukturieren kann und Dinge leichter in E-Mails wiederfinde.
Aus Gesprächen mit Menschen aus verschiedenen Unternehmen weiß ich, dass Chat Fluch und Segen sein kann. Dies ist jedoch kein technisches Problem, sondern hängt von der Unternehmenskultur und der persönlichen Disziplin ab. Wird erwartet, dass jeder zu jederzeit erreichbar ist und prompt reagiert, kann das die Produktivität ziemlich in den Keller drücken.
Setzt man einen Status wie verfügbar, beschäftigt, im Termin u.ä. und wird dies respektiert, kann Chat die Kommunikation wunderbar unterstützen. Das klappt selbst dann, wenn es mehrere Chats-Werkzeuge gibt.
Zum Glück werde ich nur sehr selten angerufen und ich rufe auch nur selten jemanden an. Warum? Ich empfinde unangekündigte Anrufe als Störung, denn sie unterbrechen meine Arbeit. Und was ich selbst nicht will, das man mir tu, das füge ich niemand anderem zu.
Das Telefon ist für mich ein Kommunikationsmittel für den Fall, wenn es etwas sehr Dringendes zu bereden gibt. Oder wenn ich weiß, dass es das bevorzugte Kommunikationsmittel der Person ist, von der ich etwas möchte.
Es gibt Dinge, die kann man am Telefon oder in einer Videokonferenz schneller bzw. einfacher klären als in einer langen Chat- oder E-Mail-Diskussion. Ich empfinde es dann allerdings als höflich, wenn man für das Telefonat einen Termin vereinbart, statt ohne Vorwarnung durchzuklingeln.
Mich freut es sehr, dass ich nicht ständig von eingehenden Anrufen und Video-Calls gestört werde.
Aktuell passt die Form der mobilen Arbeit, wie sie in meinem Team bei Red Hat gelebt wird, sehr gut zu meinen persönlichen Vorlieben und meiner Lebenssituation.
Mir gefällt es, dass ich in Ruhe und allein arbeiten kann, gleichzeitig aber ein guter Kontakt zu Kolleg*innen existiert, mit denen ich mich austauschen kann. Ich bin sehr zufrieden und hoffe, dass es noch lange so weitergeht.
Herausforderungen in der Zusammenarbeit und Kommunikation liegen in meiner Erfahrung meist in der Unternehmenskultur begründet und nur selten in der Technik. Daher empfehle ich allen, bei denen es nicht optimal läuft, über Anforderungen zu sprechen und erst danach über mögliche Programme zur Lösung derselben.
Euch wünsche ich, dass ihr ein Arbeits(zeit)modell findet, das gut zu euch passt. Wenn ihr Lust habt, teilt doch gern eure Erfahrungen mit eurer Arbeit im Büro, hybrid oder remote hier. Ich freue mich zu erfahren, wie ihr heute arbeitet und wie zufrieden ihr damit seid.
Das Jahr 2023 neigt sich langsam dem Ende zu. In diesem Monat for 25 Jahren wurde das IPv6-Protokoll in RFC 2460 beschrieben, bevor es 2017 in RFC 8200 als Internet-Standard von der Internet Engineering Task Force (IETF) veröffentlicht wurde.
Seit immerhin sechs Jahren ist dieses IP-Protokoll also schon standardisiert. Da sollte man doch meinen, dass man im Jahr 2023 problemlos ein vernetztes System betreiben kann, welches nur mit einer IPv6-Adresse mit dem Internet verbunden ist. Leider ist dem nicht so.
In den folgenden kurzen Abschnitten schreibe ich mir meinen Frust von der Seele und dokumentiere, was heute alles mit IPv6 noch nicht geht. Falls ihr weitere Fälle ergänzen möchtet, nutzt gerne die Kommentare, um eurem IPv6-Frust Luft zu machen.
Bei der Planung einer Red Hat Satellite 6.14 Installation bin ich über folgenden Satz in der Dokumentation gestolpert:
You can install Satellite and Capsules in IPv6-only systems, dual-stack installation is not supported.
URL: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.14/html/installing_satellite_server_in_a_connected_network_environment/preparing-environment-for-installation-in-ipv6-network_satellite
Das ist schade. Betreibt man Server in IPv4- und IPv6-Netzwerken und möchte eine vollständig unterstützte Lösung, muss man aktuell zwei Satellite installieren.
Ich wollte jedoch einen Satellite in einer reinen IPv6-Umgebung installieren, daher sollte mich diese Anmerkung nicht weiter stören. Da störten mich folgende Stellen im gleichen Kapitel der Dokumentation schon mehr:
You must deploy an external IPv4 HTTP proxy server. This is required because Red Hat Content Delivery Network distributes content only over IPv4 networks, therefore you must use this proxy to pull content into the Satellite on your IPv6 network.
You must configure Satellite to use this IPv4 HTTP proxy server as the default proxy. For more information, see Adding a Default HTTP Proxy to Satellite.
URL: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.14/html/installing_satellite_server_in_a_connected_network_environment/preparing-environment-for-installation-in-ipv6-network_satellite#requirements-for-installation-in-an-ipv6-network_satellite
Zuerst wollte ich dies nicht glauben, habe einen Fehler in der Dokumentation vermutet. Es ist 2023 und Content Delivery Network (CDN) von Red Hat unterstützt kein IPv6? Das kann doch nicht sein! Kann es doch:
Der zweite Link in obiger Liste führt ausschließlich IPv4-Adressen auf. Einzelne Kommentare lassen darauf schließen, dass es jedoch durchaus Interesse an IPv6-Konnektivität gibt. Also installiere ich erstmal einen Proxy-Server mit Dual-Stack, damit ich Hosts aus einem reinen IPv6-Netzwerk via subscription-manager register beim Red Hat Subscription Management (RHSM) registrieren kann.
Nachzulesen in:
Die gute Nachricht, es sind gefixte Versionen für RHEL 9 und RHEL 8 in Aussicht. Auf einen Fix für RHEL 7 würde ich nicht warten und diese Systeme lieber migrieren oder aktualisieren, ist das Support-Ende doch bereits nah.
Also lege ich mein Vorhaben erstmal beiseite und wende mich anderen Wochenendprojekten zu, die vielleicht mehr Erfolg versprechen.
Nun guck an, da ist mein Kollege Andreas also schon im Jahr 2022 in den Ansible-Issue #77308 gelaufen. Ihr interessiert euch für den aktuellen Stand dieser Geschichte? Siehe:
So langsam komme ich mir vor wie ein bekannter spanischer Junker, welcher gegen Windmühlen pardon Riesen anritt. Aber es ist ja nicht so, dass mir die Themen ausgehen. Klone ich mir halt ein Repo von Github und trage ein bisschen zu Open Source bei…
Ich spare mir viele Worte und präsentiere nur folgenden Code-Block:
Anmelden
$ host -t AAAA github.com
github.com has no AAAA recordURL zur Diskussion: https://github.com/orgs/community/discussions/10539
Auch hier kein Anschluss unter dieser Nummer.
Ich möchte meine jüngsten Erfahrungen umschreiben mit: „An manchen Tagen hat man kein Glück und an anderen kommt auch noch Pech dazu.“
Für Red Hat möchte ich sagen, ist es ein Priorisierungs-Thema. Wenn der Wunsch nach IPv6 auf Kundenseite hinreichend groß wird, wird man hier handeln. Bei Github wird es ähnlich sein. Ich muss vielleicht nur nochmal 25 Jahre warten.
Ich kann nicht für alle TAMs bei Red Hat sprechen, denn wir arbeiten sehr selbstständig und haben nur wenige feste Vorgaben. Doch möchte ich euch einen Einblick geben, wie eine Woche in meinem aktuellen Job aussehen kann.
Bitte bedenkt, dass nicht jede Woche gleich aussieht. Das wäre ja auch schrecklich eintönig und langweilig. Dennoch habe ich eine gewisse Routine, mit der ich den Alltag bewältige.
Ich wünsche euch viel Spaß bei diesem Wochenrückblick.
Hinweis: Die hier beschriebene Woche liegt schon etwas zurück. Der Bericht wurde erst kürzlich fertiggestellt.
Die Woche begann mit einem etwas ungewöhnlichen Montag. Denn mein Sohn hatte schulfrei und brachte meine Morgenroutine gehörig durcheinander.
Statt vor dem Monitor begann mein Arbeitstag daher mit dem Diensthandy. Hierauf habe ich mir einen Überblick über Chat und E-Mail verschafft, um zu sehen, ob über das Wochenende irgendetwas eskaliert ist oder es Themen gibt, denen ich mich zuerst widmen muss. Bei dieser Gelegenheit habe ich direkt alle E-Mails, die ich ob ihres Betreffs als unwichtig klassifiziert habe, direkt gelöscht.
Beim Üerfliegen verschiedener Newsletter ist mir aufgefallen, dass mein Name im letzten TGIF Newsletter auftaucht. Denn ich habe letzte Woche KCS2 erreicht. KCS ist die Abkürzung für Knowledge-centered support. Level 2 bedeutet, dass ich mein Training abgeschlossen habe und zukünftig Lösungs-Artikel selbst veröffentlichen darf. Bisher hat dies mein KCS-Coach nach einem Review der jeweiligen Artikel getan. Ich habe mich über diese kleine Anerkennung gefreut. :-)
Wie fast jeden Morgen habe ich einen Blick in unser Support-Tool geworfen, um mir einen Überblick über mir zugewiesene Cases und ggf. neue Cases meiner Kunden zu verschaffen. Heute sah es hier sehr ruhig aus und es gab nichts zu tun.
Als TAMs arbeiten wir an strategischen und wichtigen Cases unserer Kunden. Damit ihr euch ein bisschen besser vorstellen könnt, was damit gemeint ist, beschreibe ich euch, wie ich Support-Cases handhabe.
Exkurs: Case Work
Als TAM arbeite ich auf Kundenseite mit einem Team zusammen, welches in der Regel aus 4-6 Personen besteht. Dies sind meine TAM-Kontakte. Wenn ein TAM-Kontakt einen Support-Case öffnet, wird dieser mit einem TAM-Flag versehen und wird in meiner View des Support-Tools sichtbar.
Üblicherweise wird der TAM Eigentümer dieser Tickets und bearbeitet sie, bis sie mit dem Einverständnis des Kunden als gelöst geschlossen werden. Die folgende Liste bietet einen kleinen Auszug aus den Themen, die ich überlichweise selbst bearbeite:
Allerdings bearbeite ich nicht alle Support-Fälle selbst. In folgenden Fällen überlasse ich dies unseren Spezialisten aus den unterschiedlichen Support-Bereichen:
Kunden haben bereits mit ihrer RHEL-Subskription den Support erworben, der ihnen im Fehlerfall hilft. Als TAM bin ich bestrebt, Support-Fälle dann zu bearbeiten, wenn ich für den Kunden dadurch einen Mehrwert bieten kann. Dies ist nicht der Fall, wenn ich nur als Durchlauferhitzer oder zusätzliches Glied in der Stille-Post-Kette beteiligt bin. Jedoch habe ich auch ein Auge auf die Cases meiner TAM-Kontakte, die ich nicht selbst bearbeite. Ich teile in diesen Fällen häufig Informationen über die Umgebung des Kunden und den Einfluss des Problems auf die Geschäftsprozesse, welche ich in meinen Abstimmungsterminen mit dem Kunden gesammelt habe.
TL;DR: Ich bearbeite Support-Fälle dann, wenn ich dadurch einen Mehrwert für meine Kunden bieten kann.
Exkurs Ende.
Der Montag Vormittag ist in aller Regel eher ruhig. Daher nutze ich die Zeit für Themen, die ich in Ruhe bearbeiten möchte. Darunter fallen Dinge wie:
Diese Woche war es wirklich ein sehr ruhiger Montag. Ich habe eine Übergabe an meine Vertretung für einen Kunden organisiert und Account-Informationen aktualisiert. Mein Posteingang, ToDo-Liste und Check-Status sind bearbeitet und bei den Kontakten in der WaitingOnReply-Box habe ich um ein Update ersucht. Heute war ein schöner Tag. :-)
Der Dienstag begann mit einem TAM-Team-Meeting. Vorbildlich mit Agedna, Moderator, Protokollant und Zeitwächter. Dies haben wir alle zwei Wochen, wenn es Themen gibt. Die Stimmung war gut. So bin ich gut gelaunt in den Tag gestartet.
Mit dem Daily Stand-up und einem Abstimmungsmeeting zu unserem Vortrag auf dem Summit Connect Darmstadt hatte ich noch zwei weitere Meetings am Vormittag.
Daneben standen heute insgesamt 3,5 Stunden Focus Time in meinem Kalender. Dabei handelt es sich um Zeiten, die ich mir reserviere, um konzentriert an Themen zu arbeiten. Heute habe ich die Zeit genutzt, um:
Das besondere an Focus Time ist bei uns, dass weitere Termineinladungen, die in die Focus Time fallen, automatisch abgelehnt werden und man im Chat als beschäftigt markiert ist. Dies wird von den allermeisten Kollegen respektiert und man kann in Ruhe arbeiten.
Zwischendurch habe ich nach offenen Support-Cases geschaut und Informationen ergänzt. Manchmal reagieren Kunden nicht auf Updates im Support-Portal. Wenn ich dies feststelle, kontaktiere ich sie per E-Mail und informiere über Updates und stelle sicher, dass auf beiden Seiten die gleiche Erwartungshaltung zum Verlauf der Bearbeitung existiert.
Der Tag begann um Punkt 09:00 Uhr einem Quarterly Service Review für einen unserer Kunden. Hier präsentieren meine TAM-Kollegen und ich, was wir im letzten Quartal für unseren Kunden geleistet haben und gleichen dies mit der Wahrnehmung unseres Kunden ab. Der Termin endete mit einer Aussicht auf das laufende Quartal.
Danach hieß es für mich meine Sachen zu packen, denn heute stand noch die Reise nach Darmstadt auf dem Programm. Ich bin mit der Bahn gereist, da ich so im Zug arbeiten konnte.
Damit meinen Kunden während meiner Reise und Teilnahme am Summit Connect der TAM-Service in gewohnter Weise zur Verfügung steht, habe ich mir im Vorfeld Vertretungen für meine Kunden organisiert.
Während der Bahnfahrt habe ich einen TAM-Call durchgeführt. Dies war nicht optimal, aber besser, als den Termin ausfallen zu lassen. Während eines TAM-Call bespreche ich mit Kunden aktuelle Themen wie offene Support-Cases, anstehende Changes und Projekte, Trainingsbedarf, etc. Er dient der Abstimmung untereinander und Planung der nächsten Schritte.
Mit 45 Minuten Verspätung erreichte ich am Abend Darmstadt Hbf. Nun hieß es schnell im Hotel einchecken und zum Abendessen eilen.
Den Abend verbrachte ich in angenehmer Atmosphäre mit tollen Kollegen. Es war schön, sie mal wieder persönlich zu treffen.
Heute gab es den ganzen Tag nur ein Thema: Red Hat Summit: Connect Darmstadt
Vier Stichpunkte, die mich von 08:00-23:00 Uhr beschäftigt haben. Es hat sich aus meiner Sicht gelohnt. Unser Vortrag kam trotz der Kürze der Zeit gut an und ich habe einige Kunden das erste Mal in der Realität getroffen (und erst gar nicht wiedererkannt).
Heimreise mit der Bahn. Während der Fahrt in verschiedenen Zügen habe ich mit einem Support-Engineer und meinem Kunden zusammen an einem kniffligen Case gearbeitet, Life-Cycle- und Support-Dokumente geprüft, die Folien zum Quarterly Service Review vom Mittwoch an den betreffenden Empfängerkreis verteilt sowie abgelegt und an diesem Blog-Post geschrieben.
Die Kunden bekommen meist gar nicht mit, wie viel hinter dem Support-Ticket kommuniziert wird. Mir macht es Spaß auch mal über knifflige Problem zusammen mit Kollegen nachzudenken, nach Lösungen und Workarounds zu suchen.
Die ungeplante Verlängerung der Reisezeit nutzte ich, um mein Compliance & Ethics Training abzuschließen. Damit ist dieser Punkt auch erledigt.
Mit 3 Stunden Verspätung, was mich tierisch genervt hat, bin ich daheim bei meiner Familie angekommen, was mich dann sehr gefreut hat.
Eine spannende und anstrengende Woche ist vorbei. Ich hoffe ich konnte euch einen kleinen Einblick in eine nicht ganz normale Woche meiner Arbeit geben.
In diesem Artikel stelle ich euch die RHEL System Role nbde_client vor, mit welcher sich Hosts für Network Bound Disk Encryption (NBDE) installieren lassen. Er ist Bestandteil einer losen Serie, in der ich eine Reihe von System Roles vorstelle, mit denen häufig anfallende Aufgaben in der Systemadministration erledigt werden können.
Wer sich zuerst über die genannten Begriffe informieren möchte, lese:
Für das folgende Beispiel verwende ich eine Umgebung, bestehend aus:
ansible-corerhel-system-roles/dev/sdc in den Beispielen in diesem Text)Die Installation von RHEL sowie der genannten Pakete sind nicht Bestandteil dieses Artikels. Wer hierzu einen Einstieg sucht, findet entsprechende Dokumentation unter:
Durch die Installation des Pakets rhel-system-roles existiert diese Rolle bereits auf meinem System und muss nur noch konfiguriert werden. Die Rolle selbst findet man im Pfad /usr/share/ansible/roles/rhel-system-roles.nbde_client/ und die Dokumentation in /usr/share/doc/rhel-system-roles/nbde_client/README.md. Letztere enthält verschiedene Beispiele für häufige Anwendungsfälle.
In meinem Labor betreibe ich zwei NBDE-Server (TANG-Server) rhel-hetz-tang1 und rhel-hetz-tang2 sowie zwei NBDE-Clients (Clevis-Clients) rhel-hetz-clevis1 und rhel-hetz-clevis2. Die beiden NBDE-Clients besitzen jeweils ein LUKS-Device /dev/sdc, welches aktuell durch eine LUKS-Passphrase gesichert ist.
Zukünftig sollen diese LUKS-Devices durch die Kommunikation mit einem NBDE-Server entschlüsselt werden. Die LUKS-Passphrase soll entfernt werden.
Damit wird zukünftig ein Neustart der Clients aus der Ferne ermöglicht. Gleichzeitig bleibt das verschlüsselte Gerät bei Diebstahl vor unbefugtem Zugriff geschützt.
Hinweis: Das folgende Playbook ist nicht idempotent. Um dies zu ändern, ist dem ersten Task eine Bedingung hinzuzufügen, damit dieser nur dann ausgeführt werden, wenn die Bedingung erfüllt ist.
Für dieses Beispiel ist die fehlende Idempotenz des Playbooks jedoch kein Problem, da grubby das Argument nur dann hinzufügt, wenn es nicht bereits vorhanden ist.
---
- hosts: clevis
tasks:
- name: Configure ip address for interface during early boot
ansible.builtin.command:
cmd: grubby --update-kernel=ALL --args='GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 biosdevname=0 ip={{ ansible_default_ipv4.address }}::{{ ansible_default_ipv4.gateway }}:{{ ansible_default_ipv4.netmask }}::{{ ansible_default_ipv4.alias }}:none"'
- name: Enroll Clevis clients
include_role:
name: rhel-system-roles.nbde_client
vars:
nbde_client_bindings:
- device: /dev/sdc
encryption_password: "{{ luks_password }}"
password_temporary: true
slot: 2
servers:
- http://rhel-hetz-tang1.example.com
- http://rhel-hetz-tang2.example.comluks_password stecktluks_password mit ansible-vault vor neugierigen Blicken zu schützenpassword_temporary: true wird die LUKS-Passphrase aus dem jeweiligen Key-Slot gelöscht, nachdem das LUKS-Device für NBDE konfiguriert wurdeAchtung (I know, the warning comes after the spell): Wenn zur Laufzeit ein Fehler auftritt und der Key-Slot mit der LUKS-Passphrase bereits gelöscht wurde, die NBDE-Konfiguration jedoch nicht erfolgreich war, verliert man Zugriff auf das LUKS-Device. In meiner Labor-Umgebung bin ich das Risiko eingegangen. In der echten Welt, müsst ihr selbst entscheiden, ob ihr mehr Vorsicht walten lasst.
Zur Erstellung des Playbooks habe ich die Informationen aus /usr/share/doc/rhel-system-roles/nbde_client/README.md und dem Kapitel 12.18. Using the nbde_client System Role for setting up multiple Clevis clients genutzt. Bis ich festgestellt habe, dass ich auch noch den Task „Configure ip address for interface during early boot“ benötige, hat es ein wenig gedauert. Nun habe ich allerdings ein Playbook, dass ich zukünftig wiederverwenden kann.
In der erstellten Konfiguration, können die LUKS-Devices nur entschlüsselt werden, wenn mindestens einer der beiden Tang-Server im Netzwerk erreichbar ist. Wird ein so gesicherter Server gestohlen und sind die Tang-Server nicht aus dem Internet erreichbar, bleiben die Daten in der verschlüsselten Partition wie gewohnt geschützt. Es ist jedoch möglich den Server neuzustarten, ohne manuell die LUKS-Passphrase an der Konsole eingeben zu müssen.
In diesem Artikel stelle ich euch die RHEL System Role nbde_server vor, mit welcher sich Tang-Server für Network Bound Disk Encryption (NBDE) installieren lassen. Er ist Bestandteil einer losen Serie, in der ich eine Reihe von System Roles vorstelle, mit denen häufig anfallende Aufgaben in der Systemadministration erledigt werden können.
Wer sich zuerst über die genannten Begriffe informieren möchte, lese zuerst:
Im folgenden Text verwende ich die Begriffe NBDE-Server und Tang-Server synonym. Bitte lasst euch dadurch nicht verwirren.
Für das folgende Beispiel verwende ich eine Umgebung, bestehend aus:
ansible-corerhel-system-rolesDie Installation von RHEL sowie der genannten Pakete sind nicht Bestandteil dieses Artikels. Wer hierzu einen Einstieg sucht, findet entsprechende Dokumentation unter:
Durch die Installation des Pakets rhel-system-roles existiert diese Rolle bereits auf meinem System und muss nur noch konfiguriert werden. Die Rolle selbst findet man im Pfad /usr/share/ansible/roles/rhel-system-roles.nbde_server/ und die Dokumentation in /usr/share/doc/rhel-system-roles/nbde_server/README.md. Letztere enthält verschiedene Beispiele für häufige Anwendungsfälle.
Ich möchte mit dieser Rolle Folgendes erreichen:
enforcingDas Playbook ist recht übersichtlich. tang bezeichnet eine Gruppe aus meinem Ansible-Inventory, welche die Systeme enthält, die ich als NBDE-Server konfigurieren möchte.
---
- name: Manage nbde server with selinux and firewall
hosts: tang
vars:
nbde_server_manage_firewall: true
nbde_server_manage_selinux: true
roles:
- rhel-system-roles.nbde_serverNach der Anwendung der Rolle lauscht der Tang-Service auf Port 80/tcp der Zielsysteme und ist aus dem Netzwerk erreichbar.
Leider läuft es dieses Mal nicht ganz so rund wie üblich. Der Task [redhat.rhel_system_roles.selinux : Set an SELinux label on a port] schlägt auf dem RHEL 8 Host mit folgender Fehlermeldung fehl: „Failed to import the required Python library (libselinux-python)“
Das Problem und die Lösung beschreibt Red Hat in dem Solution Article: Ansible playbook fails with libselinux-python aren’t installed on RHEL8 (Login required)
Diesmal lief es nicht ganz so reibungslos wie gewohnt.
Letztendlich konnten die beiden NBDE-Server dennoch schneller konfiguriert werden, als wäre ich der manuellen Prozedur in Chapter 12. Configuring automated unlocking of encrypted volumes using policy-based decryption gefolgt.
Die Server sind damit aufgesetzt, nächste Woche beschreibe ich, wie die Clients konfiguriert werden.
Diese Einführung gibt Antworten auf die folgenden Fragen:
In dieser Einführung verwendete Betriebssysteme:
Um dieser Einleitung folgen zu können, solltet ihr mit den Grundlagen der Linux-Systemadministration vertraut sein und zumindest mit den folgenden Begriffen etwas anfangen können:
Ein Intrusion Detection System (englisch intrusion „Eindringen“, IDS) bzw. Angriffserkennungssystem ist ein System zur Erkennung von Angriffen, die gegen ein Computersystem oder Rechnernetz gerichtet sind. Das IDS kann eine Firewall ergänzen oder auch direkt auf dem zu überwachenden Computersystem laufen und so die Sicherheit von Netzwerken und Computersystemen erhöhen. Erkannte Angriffe werden meistens in Log-Dateien gesammelt und Benutzern oder Administratoren mitgeteilt; hier grenzt sich der Begriff von Intrusion Prevention System (englisch prevention „Verhindern“, IPS) ab, welches ein System beschreibt, das Angriffe automatisiert und aktiv verhindert.
Quelle: https://de.wikipedia.org/wiki/Intrusion_Detection_System (Letzter Abruf: 2023-09-08)
Die Gruppe der Intrusion Detection Systems (IDS) untergliedert sich in:
Beim AIDE handelt es sich um ein Host-basiertes IDS. Es ist unter der GPL-2.0 lizenziert.
Aus dem vorhergehenden Abschnitt ist bekannt, dass es sich bei AIDE um ein Host-basiertes System zur Angriffs- bzw. Einbruchserkennung für Linux-Systeme handelt. Es stellt ein kostengünstiges Werkzeug dar, mit dem die Integrität eines Systems überprüft werden kann.
Es soll dem Administrator helfen, zu erkennen, ob Dateien oder Verzeichnisse eines Systems hinsichtlich ihres Inhalts und bzw. oder ihrer Eigenschaften wie z.B. Berechtigungen, SELinx-Kontext, erweiterte Attribute, etc. verändert wurden.
/var/log/aide/aide.log protokolliertUm diese Schwäche zu minimieren, sind folgende Maßnahmen durch Administratoren in Erwägung zu ziehen:
Wie diese Maßnahmen umgesetzt werden können, beschreibe ich in einem folgenden Beitrag.
Werden beispielsweise Konfigurationsdateien unterhalb von /etc auf Änderungen hin überwacht, wird auch jede beabsichtige Änderung protokolliert. Das Programm kann zwischen legitimen und unautorisierten Änderungen nicht unterscheiden.
Daher ist nach jeder legitimen Änderungen die Referenzdatenbank zu aktualisieren. Ich empfehle, dies als einen Schritt in den Konfiguration-Management-Workflow zu integrieren und diese Aufgabe einen Automaten wie Ansible, Chef, Puppet o.ä. erledigen zu lassen. Dies erscheint mir weniger fehleranfällig zu sein als bei einer manuellen Durchführung, wo dieser Schritt sicher gern einmal vergessen wird.
AIDE ist in den Paketquellen der meisten Distributionen vorhanden und kann wie folgt installiert werden.
$ sudo dnf in aide
[sudo] password for tronde:
Updating Subscription Management repositories.
Last metadata expiration check: 2:26:44 ago on Fri 08 Sep 2023 08:16:28 PM CEST.
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
aide x86_64 0.16-100.el9 rhel-9-for-x86_64-appstream-rpms 154 k
Transaction Summary
================================================================================
Install 1 Package
Total download size: 154 k
Installed size: 354 k
Is this ok [y/N]:
/etc/aide.conf besitzt im Auslieferungszustand bereits 303 Zeilen; ohne Kommentare und Leerzeilen sind es immerhin noch 161aide.conf(5)/etc/aide.conf vertraut machen; oder würdet ihr einem Firewall-Regelwerk vertrauen, das ihr nicht kennt?$ sudo apt install aide
[sudo] password for jkastning:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
aide-common liblockfile-bin liblockfile1 libmhash2
Suggested packages:
figlet
The following NEW packages will be installed:
aide aide-common liblockfile-bin liblockfile1 libmhash2
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 372 kB of archives.
After this operation, 1064 kB of additional disk space will be used.
Do you want to continue? [Y/n]aide werden noch die Pakete aide-common, liblockfile-bin, liblockfile1 und `libmhash2` installiert
/etc/aide/aide.conf installiert Debian auch das Verzeichnis /etc/aide/aide.conf.d, in welchem sich direkt nach der Installation schon etliche Konfigurationsdateien befinden:$ ls -l /etc/aide/aide.conf.d/ | wc -l
212Während AIDE in RHEL über eine einzige Datei (/etc/aide.conf) konfiguriert wird, gibt es in Debian eine Konfigurationsdatei (/etc/aide/aide.conf) und die Verzeichnisse /etc/aide/aide.conf.d sowie /etc/aide/aide.settings.d, welche weitere Dateien zur Konfiguration und Einstellungen beinhalten.
Eine AIDE-Konfigurationsdatei aide.conf besteht aus drei verschiedenen Arten von Zeilen:
Parameter = Wert bzw. Gruppenname = Wert@@define foo bar die Variable foo mit dem Wert barAIDE kann die folgenden Attribute bzw. Elemente von Dateien auf Änderungen hin überwachen:
#p: permissions
#i: inode
#n: number of links
#u: user
#g: group
#s: size
#b: block count
#m: mtime
#a: atime
#c: ctime
#S: check for growing size
#acl: Access Control Lists
#selinux SELinux security context
#xattrs: Extended file attributes
#md5: md5 checksum
#sha1: sha1 checksum
#sha256: sha256 checksum
#sha512: sha512 checksum
#rmd160: rmd160 checksum
#tiger: tiger checksumDer folgende Code-Block zeigt die Definition der beiden Gruppen NORMAL und DIR (aus der /etc/aide.conf in RHEL 9), welche spezifizieren, welche Attribute überwacht werden sollen, wenn die jeweilige Gruppe in einer Regel verwendet wird.
NORMAL = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha512
# For directories, don't bother doing hashes
DIR = p+i+n+u+g+acl+selinux+xattrsWelche Dateien und Verzeichnisse in die AIDE-Datenbank aufzunehmen bzw. auszuschließen sind durch reguläre Ausdrücke bestimmt. Der nächste Code-Block zeigt drei Beispiele, die anschließend erläutert werden:
/etc NORMAL
=/var/log/ DIR
=/home DIR
!/dev/etc und alle darunterliegenden Dateien und Verzeichnisse werden in die AIDE-Datenbank aufgenommen und mit den Regeln aus der Gruppe NORMAL verknüpft/var/log/ und die direkt darunter befindlichen Dateien und Verzeichnisse werden in die AIDE-Datenbank aufgenommen und mit der Gruppe DIR verknüpft; der Inhalt der Unterverzeichnisse wird nicht in die Datenbank aufgenommen/home wird aufgenommen; nicht jedoch der Inhalt davon/dev und alle darunterliegenden Dateien und Verzeichnisse werden nicht in die AIDE-Datenbank aufgenommenMit Sicherheit und Vertrauen ist das immer so eine Sache. Am besten ist es stets, wenn Vertrauen für Sicherheit nicht erforderlich ist. Daher rate ich an dieser Stelle nochmals ausdrücklich, die AIDE-Konfiguration zu überprüfen und ggf. den eigenen Bedürfnissen anzupassen… Nur um direkt gegen meinen eigenen Rat zu verstoßen.
Der Umfang an Regeln ist in beiden Systemen so groß, dass ich in dieser Einführung nicht alle einzeln erläutern kann. Ich vertraue für diese Einführung daher darauf, dass die Distributionen eine sinnvolle Konfiguration ausliefern.
Initialisiert wird die Datenbank je nach Distribution mit einem leicht abgewandelten Befehl.
$ sudo time aide --init
Start timestamp: 2023-09-18 20:50:06 +0200 (AIDE 0.16)
AIDE initialized database at /var/lib/aide/aide.db.new.gz
Number of entries: 54290
---------------------------------------------------
The attributes of the (uncompressed) database(s):
---------------------------------------------------
/var/lib/aide/aide.db.new.gz
MD5 : xOf5Bs/Hb2Caa5i2K41fbg==
SHA1 : KoCkqwfe+oZ2rlQTAU+AWQBrt2I=
RMD160 : eM6IC68wq1VRhDbyHhRqy+63ldI=
TIGER : lQC+UTBqUm0iEDdKA0u7THqAPLNQxegH
SHA256 : vdzjqIr/m7FgjXdZLQG+D1Pvf75WlF17
WYiA6gU+4Pg=
SHA512 : EdMB0I92j05zlfjXHcJFasZCAvkrK9br
6zQEcDfD4IDM8D9c1Sz0r7A5tJTKGXVZ
AFCOJR65j66ihKB0suFS6w==
End timestamp: 2023-09-18 20:50:19 +0200 (run time: 0m 13s)Die erzeugte Datenbank wird umbenannt, indem das new aus dem Dateinamen entfernt wird.
$ sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gzDie umbenannte Datei stellt die Referenzdatenbank dar, gegen die mit dem Befehl aide --check geprüft werden kann, ob es Änderungen im Dateisystem gab.
In diesem Artikel gebe ich mich damit zufrieden, dass die Datenbank auf dem zu überwachenden Host liegt und damit dem Risiko unterliegt, von einem Angreifer manipuliert zu werden (siehe zu den Schwächen oben). Ich gehe in einem Folgeartikel darauf ein.
Unter Debian wird die AIDE-Datenbank mit dem Wrapper-Script aideinit (siehe aideinit(8)) initialisiert. Das README unter /usr/share/doc/aide-common/README.Debian.gz warnt bereits davor, dass Debian mit zu restriktiven Einstellungen daherkommt:
Configuring AIDE the Debian way
/usr/share/doc/aide-common/README.Debian.gz
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AIDE’s Debian default configuration takes a very paranoid stance and
is likely to report more changes than you will need to focus your
attention on.
Lassen wir uns überraschen…
$ sudo time aideinit
Running aide --init...
7044.57user 54.97system 2:00:40elapsed 98%CPU (0avgtext+0avgdata 132408maxresident)k
231120192inputs+88320outputs (12major+66397minor)pagefaults 0swapsDas hat deutlich länger gedauert und endete mit einer deutlich kürzeren Ausgabe. Die erzeugte Datenbank ist jedoch wie bei RHEL im Verzeichnis /var/lib/aide/ zu finden.
:~# ls -l /var/lib/aide/
total 43536
-rw------- 1 root root 22286930 Sep 19 15:13 aide.db
-rw------- 1 _aide _aide 22286930 Sep 19 15:13 aide.db.new
:~# qm start 102
:~# file /var/lib/aide/aide.db.new
/var/lib/aide/aide.db.new: gzip compressed data, max compression, from Unix, original size modulo 2^32 44239215
:~# file /var/lib/aide/aide.db
/var/lib/aide/aide.db: gzip compressed data, max compression, from Unix, original size modulo 2^32 44239215Warum die Erstellung so viel länger gedauert hat, weiß ich nicht. Ich habe keine Idee dazu. Auch Debian erzeugt eine gzip-komprimierte Datenbank, auch wenn hier keine Dateiendung darauf hinweist. Ich finde das etwas seltsam, behalte die Standardeinstellung für diese Einführung jedoch bei. Dafür muss die Datei nicht manuell umbenannt werden, da direkt eine Kopie erstellt wird, die als Referenzdatenbank genutzt werden kann.
Im Gegensatz zu RHEL wird unter Debian auch ein Timer namens dailyaidecheck.timer installiert, welcher täglich einen automatischen Check auf Veränderungen durchführt. Allerdings ist es für einen Angreifer ein Leichtes, diese Timer-Unit zu deaktivieren.
Unter Debian und RHEL werden die in der Referenzdatenbank enthaltenen Elemente mit folgendem Befehl auf Änderungen überprüft:
:~# aide --check # unter RHEL
:~# aide --check --config /etc/aide/aide.conf # unter DebianIch habe meine Testsysteme ein paar Tage laufen lassen und einen AIDE-Integritätscheck durchgeführt. Hier das Ergebnis für ein RHEL 9 System:
$ sudo aide --check
Start timestamp: 2023-09-26 19:54:59 +0200 (AIDE 0.16)
AIDE found differences between database and filesystem!!
Summary:
Total number of entries: 54290
Added entries: 0
Removed entries: 0
Changed entries: 3
---------------------------------------------------
Changed entries:
---------------------------------------------------
f = ... . ..S : /var/log/insights-client/insights-client.log.3
f < ... . ... : /var/log/rhsm/rhsmcertd.log
f < ... . ... : /var/log/squid/cache.log
---------------------------------------------------
Detailed information about changes:
---------------------------------------------------
File: /var/log/insights-client/insights-client.log.3
SELinux : system_u:object_r:insights_clien | unconfined_u:object_r:insights_c
t_var_log_t:s0 | lient_var_log_t:s0
File: /var/log/rhsm/rhsmcertd.log
Size : 1426 | 1343
File: /var/log/squid/cache.log
Size : 6230 | 334
---------------------------------------------------
The attributes of the (uncompressed) database(s):
---------------------------------------------------
/var/lib/aide/aide.db.gz
MD5 : xOf5Bs/Hb2Caa5i2K41fbg==
SHA1 : KoCkqwfe+oZ2rlQTAU+AWQBrt2I=
RMD160 : eM6IC68wq1VRhDbyHhRqy+63ldI=
TIGER : lQC+UTBqUm0iEDdKA0u7THqAPLNQxegH
SHA256 : vdzjqIr/m7FgjXdZLQG+D1Pvf75WlF17
WYiA6gU+4Pg=
SHA512 : EdMB0I92j05zlfjXHcJFasZCAvkrK9br
6zQEcDfD4IDM8D9c1Sz0r7A5tJTKGXVZ
AFCOJR65j66ihKB0suFS6w==
End timestamp: 2023-09-26 19:55:12 +0200 (run time: 0m 13s)Die Integritätsprüfung in obigen Code-Block führt Änderungen an drei Dateien auf:
summarize_changes in aide.conf(5).Abbruch meiner Tests unter Debian 12 (Bookworm)
Unter Debian hat die Integritätsprüfung über Stunden einen CPU-Kern blockiert. Der Prozess ist in einem futex Syscall hängen geblieben.
Ob es an meinem System liegt oder AIDE unter Debian generell ein Problem hat, kann ich nicht sagen. Ich bin der Sache nicht weiter nachgegangen.
Falls jemand von euch AIDE unter Debian einsetzt und dies liest, freue ich mich, wenn ihr eure Erfahrungen mit mir teilt.
Mit dem Befehl aide --update wird die Datenbank-Integrität geprüft und eine neue Datenbank /var/lib/aide/aide.db.new.gz erzeugt. Die bestehende Referenzdatenbank /var/lib/aide/aide.db.gz wird dabei nicht überschrieben und bleibt zunächst erhalten. Möchte man diese länger aufbewahren, kann man sie umbenennen und bspw. einen Zeitstempel anhängen. Anschließend erzeugt man mit mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz eine neue Referenzdatenbank.
Der folgende Code-Block zeigt die Ausgabe von aide --update unter RHEL 9.
~]# aide --update
Start timestamp: 2023-09-26 20:13:52 +0200 (AIDE 0.16)
AIDE found differences between database and filesystem!!
New AIDE database written to /var/lib/aide/aide.db.new.gz
Summary:
Total number of entries: 54290
Added entries: 0
Removed entries: 0
Changed entries: 3
---------------------------------------------------
Changed entries:
---------------------------------------------------
f = ... . ..S : /var/log/insights-client/insights-client.log.3
f < ... . ... : /var/log/rhsm/rhsmcertd.log
f < ... . ... : /var/log/squid/cache.log
---------------------------------------------------
Detailed information about changes:
---------------------------------------------------
File: /var/log/insights-client/insights-client.log.3 [0/100]
SELinux : system_u:object_r:insights_clien | unconfined_u:object_r:insights_c
t_var_log_t:s0 | lient_var_log_t:s0
File: /var/log/rhsm/rhsmcertd.log
Size : 1426 | 1343
File: /var/log/squid/cache.log
Size : 6230 | 334
---------------------------------------------------
The attributes of the (uncompressed) database(s):
---------------------------------------------------
/var/lib/aide/aide.db.gz
MD5 : xOf5Bs/Hb2Caa5i2K41fbg==
SHA1 : KoCkqwfe+oZ2rlQTAU+AWQBrt2I=
RMD160 : eM6IC68wq1VRhDbyHhRqy+63ldI=
TIGER : lQC+UTBqUm0iEDdKA0u7THqAPLNQxegH
SHA256 : vdzjqIr/m7FgjXdZLQG+D1Pvf75WlF17
WYiA6gU+4Pg=
SHA512 : EdMB0I92j05zlfjXHcJFasZCAvkrK9br
6zQEcDfD4IDM8D9c1Sz0r7A5tJTKGXVZ
AFCOJR65j66ihKB0suFS6w==
/var/lib/aide/aide.db.new.gz
MD5 : Dgoc1/L5F1UfXPAQRvMdTg==
SHA1 : 23RFwEBIh0kw/3TiiVAh39Fzx0Q=
RMD160 : 1szie2CW1dyLmaKFg01j48Fr+Us=
TIGER : TgdG3zNAOSZH2D9jkyvBves8PtjC0lCR
SHA256 : hjn9vxFxg4KoVwT3YvgU347EhvTCg5ey
lfktpr/OrcA=
SHA512 : x6E3YPa0eILD3nZqDt6N755KSmPRFOz8
lhKD9CimYScSpxyoVxJAVWiozR8KUwkt
Ao7mgy3BgtUA0MZuNMv43w==
End timestamp: 2023-09-26 20:14:03 +0200 (run time: 0m 11s)
~]# ls -l /var/lib/aide
total 6184
-rw-------. 1 root root 3163359 Sep 18 20:50 aide.db.gz
-rw-------. 1 root root 3163384 Sep 26 20:14 aide.db.new.gzAn dieser Stelle endet die Einführung in das Advanced Intrusion Detection Environment (AIDE). Kommt das Ende für euch abrupt? Ist es ein Ende mit Schrecken? Lasst es mich gern wissen.
In dieser Einführung habe ich beschrieben, was Intrusion-Detection-Systeme im Allgemeinen und AIDE im Speziellen sind. Ich bin auf deren Nutzen eingegangen und habe die Schwächen von AIDE als Host-basiertem IDS benannt. Installation, Konfiguration, Integritäts-Check und Aktualisierung der Datenbank wurden erklärt und mit Beispielen belegt.
Was ist nun von AIDE zu halten?
Nun, es ist besser als nichts. Man besitzt damit ein Werkzeug, mit dem sich Änderungen im Dateisystem erkennen lassen. Man muss sich jedoch der Schwächen Host-basierter IDS bewusst sein. Ein Angreifer mit lokalen root-Rechten kann dieses Werkzeug mit wenig Aufwand unschädlich machen bzw. die eigenen Änderungen verschleiern.
Sicher kann man einen Integritätscheck automatisiert alle 5 Minuten durchführen und für Änderungen eine E-Mail-Benachrichtigung einrichten. Doch wirkt dies etwas hemdsärmelig. Daher werde ich dieses Thema in einem späteren Artikel aufgreifen und zeigen, wie man AIDE in einen Automations- bzw. Konfigurations-Management-Prozess einbinden kann.
Heute berichte ich euch von meinem Wochenendprojekt „Aufbau und Einrichtung Serverschrank“. Anlass dazu gaben vier Gründe:
Transparenzhinweis: Von den im Text genannten Herstellern erhalte ich keinerlei Vergünstigungen, Werbekostenzuschüsse oder andere Vorteile, noch habe ich diese erhalten.
Aus dem Datacenter kennt man die meist 42 HE hohen, 800 mm breiten und 1000 mm tiefen Schränke. So ein Modell ist für meinen heimischen Keller allerdings völlig überdimensioniert. Darüber hinaus ist mir ein solcher Schrank zu teuer.
Also habe ich mir zuerst Gedanken gemacht, was ich alles in den neuen Schrank einbauen möchte und wie viele HE ich dafür benötige. Mit etwas Reserve bin ich auf 22 HE gekommen.
Nach etwas Recherche habe ich mir bei IT-Budget einen 22 HE Schrank mit BxT 600×800 mm, Sicht-/Vollblechtür, 4 Aktiv-Lüfter, 3 Fachböden, 1x 6-fach 19-Zoll-Steckdosenleiste, 120 Korbmuttern und M6-Schrauben im Flatpak gekauft. Dazu habe ich noch 10 Kabelbügel aus Kunststoff gekauft, um dem Kabelwust im Inneren von Beginn an Einhalt gebieten zu können.
Wer noch nie einen Schrank aufgebaut hat, für den gibt es von IT-Budget ein schönes Youtube-Video, in welchem die einzelnen Schritte erklärt werden. Die folgenden Bilder zeigen ein paar Bauabschnitte:
Mir gefällt, dass alle Teile sauber entgratet sind und qualitativ hochwertig wirken. Dies ist, glaube ich, der erste Schrank, nach dessen Aufbau ich nicht aus dutzenden Kratzern blutete.
Die 600 mm Breite lassen nur wenig Platz für die Kabelführung im Inneren. Ich kann dies verschmerzen, da ich den Schrank nicht komplett bestücken werde und noch ausreichend Platz ist. Alle vier Seiten lassen sich öffnen, sodass man gut an die zu montierenden Elemente herankommt. Zudem verfügt der Schrank über Rollen. Werden die Standfüße eingeschraubt, lässt sich der Standort leicht verändern.
Das einzige, was mir fehlte, war eine Kabelbürste für die Kabelzuführung. Diese verhindert, dass neben den Kabeln auch Staub einen Weg in den Schrank findet. Diese habe ich nachträglich im Versandhandel bestellt.
Gekostet hat das Ganze bis hierhin ca. 640,- Euro/brutto. Das ist nicht wenig, doch empfinde ich den Preis der Qualität angemessen.
Meinen PC habe ich detailliert in Meine privaten Arbeitsmittel Anfang 2022 beschrieben. Dieser hing bisher unter meiner Schreibtischplatte.
Ich wollte das Desktop-Gehäuse nicht einfach unten in den Schrank hinein stellen. Dies triggerte einfach zu sehr meinen inneren Monk. Daher habe ich mir das Inter-Tech Servergehäuse IPC 4U-4088-S für unter 80,- Euro/brutto bestellt und meinen PC umgebaut. Die folgenden Bilder illustrieren dies:
Der Umbau war in ca. 45 Minuten erledigt und der PC konnte einziehen:
Ich habe vergessen Teleskop-Gleitschienen und Kabelmanagementarm für das PC-Gehäuse mitzubestellen. Daher habe ich das Gehäuse auf einen Fachboden gelegt. Dies ist für mich akzeptabel, da ich den PC für Arbeiten eh an einen besser beleuchteten Ort bringen würde.
Staubschutzhauben für Monitor und Tastatur dürfen natürlich nicht fehlen, möchte ich doch möglichst lange Freude daran haben.
Den Schrank selbst fülle ich von oben nach unten. Sollte der Keller mal mit Wasser volllaufen, habe ich ca. 70 cm Luft, bevor mein PC im Wasser steht. Deshalb habe ich auch Strom und alle weiteren Kabel von oben in den Schrank hinein geführt.
Auf den letzten Bildern ist zu sehen, dass mein NAS sich ebenfalls schon im Schrank befindet. In den Kartons befinden sich noch Kabel und ein Protectli Vault VP2410. Letzterer wird zukünftig als Gateway/Firewall für die beiden Internetanschlüsse dienen.
Nicht im Bild sind ein Raspberry Pi 2 mit Pi-Hole und ein Netgear GS108e, welcher die Komponenten untereinander verbindet.
Mich freut es, nun nicht mehr unter Tische oder hinter TV-Schränke kriechen zu müssen, wenn ich mal physischen Zugriff auf meine Komponenten benötige. Jetzt findet alles seinen Platz in einem schicken Schrank.
So stand es an einem Freitag auf Mastodon geschrieben. Nach einem Schmunzeln fragte ich mich: „Ja warum eigentlich nicht?“ Dieser Frage möchte ich heute nachgehen.
Der englischsprachige Satz aus dem Titel ist eine Aufforderung, an einem Freitag keine Änderungen an produktiven Systemen vorzunehmen, um das Wochenende nicht zu gefährden. Viele von euch kennen vermutlich berühmte letzte Worte wie:
Nicht selten hat sich der Feierabend oder das Wochenende nach diesen Sätzen erheblich verzögert oder sind ganz ausgefallen, weil eben doch etwas schiefgegangen ist. In der Folge waren wichtige Dienste nicht mehr verfügbar und Systemadministratoren haben das Abendessen mit ihrer Familie versäumt, weil sie den Klump wieder zum Laufen bringen mussten. Solche Erlebnisse führen zu Aussagen wie:
Die Logik dahinter ist bestechend einfach. Wenn etwas funktioniert und man nichts daran ändert, wird wohl auch nichts kaputt gehen. Allerdings stehen diese Aussagen dem DevOps-Mantra von Continuous Integration and Continuous Delivery (CI/CD) entgegen, welches fordert, dass Änderungen zu jeder Zeit möglich sein müssen.
Und wer hat nun recht? Ich denke, die Wahrheit liegt wie so oft irgendwo in der Mitte.
Ob Änderungen durchgeführt werden können, hängt in meinen Augen nicht vom Wochentag ab, sondern vielmehr von den Antworten auf die folgenden Fragen:
Sind zum Beispiel alle 37 Key-User, 8 Abteilungsleiterinnen und das 20-köpfige Betriebs-Team für die Personal- und Buchhaltungsanwendung Freitag nach 18:00 bis voraussichtlich 21:00 Uhr alle verfügbar und können im Fehlerfall mit offenem Ende verfügbar bleiben, steht einer Änderung bzw. einem Deployment nichts im Wege. Ist dies jedoch nicht der Fall und man stellt Fehler möglicherweise erst im Laufe des kommenden Montags fest, wo ein Rollback evtl. schon nicht mehr möglich ist, sollte man den Change vielleicht lieber Montagmorgen starten?
In einem anderen Fall ist das Team nicht sicher, ob sie das System im Fehlerfall ohne Hilfe des Herstellers wiederherstellen können. Der Support-Vertrag deckt jedoch nur die Zeiten Mo-Fr von jeweils 08:00-17:00 Uhr mit 4 Stunden Reaktionszeit ab. Hier ist es vielleicht ebenfalls besser, das Wartungsfenster in den frühen Morgen als in den Freitagabend zu legen.
Habe ich hingegen einen 24/7-Supportvertrag und meine IT-Betriebsabteilung darf auch am Wochenende arbeiten, bietet sich ein Change mit langer Dauer am Wochenende an, um die Betriebsabläufe möglichst wenig zu beeinträchtigen.
Sind Änderungen nur von kurzer Dauer und man möchte möglichst viele User verfügbar haben, die sofort testen und mögliche Fehler finden, ist vermutlich auch Dienstag Vormittag 10:00 Uhr eine gute Zeit.
Es hängt also nicht primär vom Wochentag, sondern vielmehr von einigen anderen Faktoren ab, wann Änderungen in Produktion ausgerollt werden sollten.
Wie seht ihr das? Nach welchen Kriterien werden bei euch Deployments geplant und durchgeführt?
PS: Ich finde jedoch absolut nichts Verwerfliches daran, wenn man sich den Freitag für die Pflege und Aktualisierung der Dokumentation reservieren kann und nicht mit aller Gewalt noch etwas kaputtfuckeln muss. ;-)
Im siebten Teil meiner losen Reihe über die RHEL System Roles stelle ich die Rolle rhc vor, mit welcher sich RHEL-Systeme (Version >= 8.6) in der Hybrid Cloud Console, Insights und dem RHSM registrieren lassen.
Das Tool rhc selbst habe ich bereits im Artikel Red Hat Remote Host Configuration ausführlich vorgestellt.
Möchte man ein oder mehrere RHEL-Systeme in der Hybrid Cloud Console registrieren, kann man dazu die RHEL System Role rhc verwenden.
Durch die Installation des Pakets rhel-system-roles existiert die Rolle rhc bereits auf meinem System und muss nur noch konfiguriert werden. Die Rolle selbst findet man im Pfad /usr/share/ansible/roles/rhel-system-roles.rhc/ und die Dokumentation in /usr/share/doc/rhel-system-roles/rhc/README.md.
- name: Register systems
hosts: all
vars:
rhc_auth:
activation_keys:
keys: ["key-1", ...]
rhc_organization: "your-organization"
roles:
- rhel-system-roles.rhckey-1 ist durch den eigenen Activation Key zu ersetzenyour-organization ist durch die eigene Org-ID zu ersetzenMit dieser System Role ist es einfach möglich, eine große Anzahl Systeme in die Hybrid Cloud Console aufzunehmen. Dabei lässt sich konfigurieren, ob Funktionen wie Insights und Remediation Playbooks genutzt werden können.
Eine weitere tolle Rolle aus dem Paket rhel-system-roles, die sich einfach zur Anwendung bringen lässt.
Auf Mobiltelefonen, Tablets, Laptops, Netzwerkspeichern und in diversen Anwendungen in unserem Heimnetzwerk befinden sich Daten, welche wir schmerzlich vermissen würden, wenn sie dauerhaft verloren gingen.
Im Folgenden beschreibe ich, wie ich z.B. Fotos, Videos, Zeugnisse, Verträge, Urkunden, Versicherungspolicen, etc. vor Verlust schütze.
Der Artikel behandelt nicht:
Sie sind unsere ständigen Begleiter, verfügen über große Speicher und beinhalten häufig jede Menge an Fotos und Videos. Diese werden mit DS-Apps auf eine Synology Diskstation im heimischen Netzwerk gesichert.
Für Threema benutze ich Threema Safe. Ein Datenbackup führe ich nicht durch. Der Inhalt der Nachrichten ist mir nicht so wichtig, als dass mich ein Verlust schmerzen würde.
E-Mails, Kalender und Kontakte werden zwischen Mailbox.org und diversen Geräten synchronisiert, jedoch nicht gesichert. Wenn jemand z.B. das Adressbuch löscht, müsste ich das Netzwerk vom PC trennen, um das Adressbuch ohne Netzwerkverbindung zu starten, um den letzten Stand von dort wiederherstellen zu können. Für mich ist das ausreichend, da ich bei einem GAU meine wichtigsten Kontakte auch ohne Adressbuch zu erreichen weiß und sich Kontaktinformationen von Handwerkern und sonstigen Unternehmen wieder recherchieren lassen.
Sollte ich Zugriff auf die App Aegis Authenticater verlieren, muss ich auf die Backup-Codes zurückgreifen, welche in einer KeePass-Datenbank lagern.
Falls ihr einfache Lösungen kennt, um sämtliche Apps samt deren Inhalte sichern und auf abweichenden Telefonen wiederherstellen zu können, freue ich mich, wenn ihr mir davon berichtet.
Meine Synology Diskstation ist:
Ausgewählte Daten werden wöchentlich mit Hyper Backup (Backup-Anwendung der Diskstation) auf eine angeschlossene USB-Festplatte gesichert. Darüber hinaus habe ich mir ein Offsite-Backup gebastelt, welches ich in diesem Artikel beschrieben habe.
Über Erfolg und Misserfolg der Sicherungen werde ich per E-Mail benachrichtigt.
Die größte Herausforderung für mich ist es, die Wiederherstellbarkeit der gesicherten Daten zu kontrollieren. Dies mache ich bisher sporadisch und manuell. Und vermutlich viel zu selten.
Daten meiner Laptops synchronisiere ich teilweise mit Nextcloud, welche ich auf einem virtuellen Server betreibe. Gehostet wird dieser bei Contabo in Deutschland.
Darüber hinaus nutze ich Déjà Dup Backups für eine wöchentliche Datensicherung meines HOME-Verzeichnisses in die Nextcloud mit 180 Tagen Vorhaltezeit. Auch hier teste dich die Wiederherstellbarkeit sporadisch.
Das HOME-Verzeichnis meines Dienstlaptops wird täglich mit Déjà Dup in das Google Drive meines Arbeitgebers gesichert.
Auch wir haben jede Menge totes Holz im Schrank stehen, dessen Wiederbeschaffung bei Verlust mit viel Zeit und Mühe verbunden ist.
Meine Lösung für diese Herausforderung habe ich in Mein Paperless-NGX-Mini-Konzept niedergeschrieben.
Hier möchte ich die Wiederherstellung noch verbessern, indem ich auf meinem Laptop ein Ansible-Playbook ablege, welches die Paperless-NGX-Instanz auf meinem Laptop wiederherstellt. So teste ich die Wiederherstellbarkeit und habe immer eine relativ aktuelle Kopie auf der verschlüsselten Festplatte meines Laptops bei mir.
Auf einem virtuellen Server in der Cloud möchte ich diese Daten aktuell nicht so gerne hosten. Dazu muss ich mir zuvor in Ruhe Gedanken über mögliche Risiken für die Integrität und Vertraulichkeit der Daten machen.
Meine produktive Paperless-NGX-Instanz steht mit dem Papier im gleichen Haus. Das Backup beinhaltet alle PDF-Dateien und liegt verschlüsselt in der Cloud. Da die Dateinamen halbwegs sinnvoll benannt sind, scheint im Falle eines GAU die Suche im Heuhaufen nicht hoffnungslos.
Für beide Dienste, welche auf einem virtuellen Server bei Contabo laufen, wird zur Datensicherung wöchentlich ein Datenbank-Dump und ein Archiv der Verzeichnisstruktur mit Ordnern und Dateien erstellt. Dieses Backup wird lokal auf dem Server abgelegt und für 30 Tage vorgehalten. Ich nutze dafür selbstgeschriebene Bash-Skripte, welche durch Cron ausgeführt werden.
Auf meinem NAS läuft ein Skript, welches die Backups vom Server auf das NAS synchronisiert.
Über Erfolg und Misserfolg der einzelnen Jobs werde ich per E-Mail benachrichtigt.
Die Wiederherstellbarkeit teste ich sporadisch und sollte dies mutmaßlich häufiger tun. Ein Automat dafür befindet sich aktuell in Arbeit. Den aktuellen Stand kann man in folgenden Artikeln nachlesen:
Ruhende Daten werden verschlüsselt, bevor sie in die Cloud hochgeladen werden. Das Restrisiko, dass der fremde Betreiber prinzipiell die Kontrolle über meinen virtuellen Server übernehmen kann, bleibt.
Betreibe ich Server oder Dienst nicht im eigenen Heimnetzwerk, nutze ich für den Betrieb deutsche Anbieter mit Standorten in Deutschland. Zu diesen habe ich einfach das größte Vertrauen, dass sie sich an geltende Gesetze halten, die Hoffnung, dass sie den Datenschutz ernst nehmen und meine Daten dort gut aufbewahrt sind.
Wie sichert ihr eure Daten außer Haus? Welche Dienste verwendet ihr dazu? Ich freue mich, wenn ihr eure Erfahrungen in den Kommentaren teilt.
Ich habe mir zumindest mal Gedanken gemacht, welche Daten so wichtig sind, dass ich sie vor Verlust schützen möchte. Zum Schutz vor Verlust kommen verschiedene Verfahren zum Einsatz, die auf der Schaffung von Redundanz durch Synchronisierung oder der Datensicherung mit Versionierung beruhen.
Die Wiederherstellbarkeit wird zumindest sporadisch getestet. Dieser Punkt ist sicherlich ausbaufähig.
Wer die einzelnen Abschnitte gelesen hat, stellt jedoch auch fest, dass es schnell ein wenig unübersichtlich wird. Zumindest hilft dieser Artikel etwas, den Überblick zu behalten.
Für die Zukunft wünsche ich mir eine dedizierte Backup-Senke im Keller, in der sich ausschließlich Backups befinden und eine Offsite-Senke, auf welche die Daten der Backup-Senke gesichert werden. Bis ich da hinkomme, wird sicherlich noch etwas Zeit vergehen.
sudo dnf in <linux-treiber-name.rpm>http://localhost:631/printersAppSocket/HP JetDirect für Deviceipp://<IP-Adresse-des-Druckers>/ipp/port1 für Device URIDa es mich mal wieder tierisch genervt hat, bis das Höllengerät endlich druckte, habe ich die Installationsschritte kurz aufgeschrieben.
Quellen:
