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.

Red Hat Satellite 6.14

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:

• Unable to register system using subscription-manager over IPv6 interface
• Public CIDR Lists for Red Hat (IP Addresses for cdn.redhat.com)

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.

subscription-manager cli command does not support IPv6 proxy

Nachzulesen in:

• RHEL-7209
• BZ 2225403
• candlepin/subscription-manager #3302

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.

ansible-galaxy does not work on IPv6 only hosts

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:

• Ansible-galaxy (galaxy.ansible.com) is not usable for ipv6-only hosts #3002
• Missing IPv6 DNS/IP for S3 bucket used for ansible-galaxy

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…

IPv6 support for cloning Git repositories #10539

Ich spare mir viele Worte und präsentiere nur folgenden Code-Block:

$ host -t AAAA github.com
github.com has no AAAA record

URL zur Diskussion: https://github.com/orgs/community/discussions/10539

Auch hier kein Anschluss unter dieser Nummer.

Fazit

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.

• Welche Erfahrungen habt ihr mit IPv6 gemacht?
• Habt ihr es schon an den Nagel gehängt; oder bleibt ihr hartnäckig und gebt nicht auf?
• Ich freue mich auf eure schönsten Fehlschläge und Erfolgsmomente.

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.

Montag

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:

• Requests for Enhancements (RFE) zu Bestandteilen von RHEL
• Bereitstellung von Informationen zur Zertifizierung von Anwendungen Dritter für RHEL
• Beantwortung allgemeiner Fragen zu unseren Produkten, deren Life Cycle und zur Roadmap
• Anfragen, die sich zu Beginn nicht richtig einordnen lassen und wo Ziel und Umgebung erst näher bestimmt werden müssen
• Fälle, wo ich der Meinung bin, dazu beitragen zu können, dass die Bearbeitung besser verläuft
• Break&Fix-Fälle, bei denen ich mir zutraue, das Problem in angemessener Zeit selbst lösen zu können

Allerdings bearbeite ich nicht alle Support-Fälle selbst. In folgenden Fällen überlasse ich dies unseren Spezialisten aus den unterschiedlichen Support-Bereichen:

• Es handelt es sich um ein Thema, von dem ich selbst so gar keine Ahnung habe
• Ich bin ausgelastet und kann mich nicht in angemessener Zeit und notwendigen Umfang um den Fall kümmern

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:

• Erstellen von Laborumgebungen
• Durchführung verschiedener Use Cases im Labor
• Erstellung von Demos
• Arbeit ein Vorträgen und Dokumenten
• Persönliche Fort- und Weiterbildung
• Arbeit an Themen von meiner ToDo-Liste

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. :-)

Dienstag

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:

• Die Agenda für einen TAM-Call zu erstellen und die Themen für diesen vorzubereiten
• Die Demo für den Summit Connect vorzubereiten und zu testen
• Am Ende des Tages die Out-of-Office-Procedure durchzugehen, ohne wichtige Schritte zu vergessen

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.

Mittwoch

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.

Donnerstag

Heute gab es den ganzen Tag nur ein Thema: Red Hat Summit: Connect Darmstadt

• Vortag halten
• Vorträge lauschen
• Partner und Kunden treffen
• Kollegen kennenlernen

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).

Freitag

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.

Fazit

Eine spannende und anstrengende Woche ist vorbei. Ich hoffe ich konnte euch einen kleinen Einblick in eine nicht ganz normale Woche meiner Arbeit geben.