F
foo_1337
Gast
Ja, ansible runs, terraform etc. über Windows auszuführen ist ein PITA. Mit WSL(2) geht es einigermaßen, aber schön ist anders. Insbesondere dann wenn man es eh gewohnt ist, eine unixoide Workstation zu haben.
Es tut mir leid, das zu sagen: Aber wenn mir jemand im Bewerbungsgespräch sagen würde, dass er eine Windows Workstation möchte, wäre das ein starkes Gewicht auf der Kontra seite wenn nicht gar ein Ausschlusskriterium. Hört sich blöd an, aber es ist eh schwierig, gute Leute zu finden. Und das Arbeiten mit Windows in diesem Kontext bringt eine gewisse Arbeitsmethotik, die nicht zu uns passt. Hört sich erst mal blöd an, aber ist nunmal so bzw. die Erfahrung hat das gelehrt. Aber in der Regel ist es eh umgekehrt: Viele Bewerber fragen tatsächlich, ob sie bei uns mit Windows arbeiten müssten.
Und damit es nicht ganz off topic ist: Wir hatten früher alle Linux Workstations. Wir konnten aber vor über 5 Jahren die Geschäftsleitung davon überzeugen, dass man zum einen mit Macs produktiver ist (wir müssen auch o365 nutzen) sowie auch in Richtung potentieller Mitarbeiter sowie Kunden etwas anderes ausstrahlt. Und funktioniert tatsächlich. Du gewinnst zwar keinen Kundenpitch, weil du dich da mit nem Mac hinstellst und du bekommst somit auch nicht automatisch neue Leute. Aber du vermittelst beim Kunden einen professionelleren Eindruck und der Bewerber bekommt in der Regel schon einen kleinen "habenwill" Effekt. Wie gesagt: Ganz sicher nicht ausschlaggebend aber ein wenig richtungsweisend
Dein privater key ist selbstverständlich in der macOS keychain und via ssh-agent direkt verfügbar. Auch wenn jump hosts zu verschiedenen Kundensystemen verwendet werden, kann man das ganz einfach via agent forwarding realisieren.
Es tut mir leid, das zu sagen: Aber wenn mir jemand im Bewerbungsgespräch sagen würde, dass er eine Windows Workstation möchte, wäre das ein starkes Gewicht auf der Kontra seite wenn nicht gar ein Ausschlusskriterium. Hört sich blöd an, aber es ist eh schwierig, gute Leute zu finden. Und das Arbeiten mit Windows in diesem Kontext bringt eine gewisse Arbeitsmethotik, die nicht zu uns passt. Hört sich erst mal blöd an, aber ist nunmal so bzw. die Erfahrung hat das gelehrt. Aber in der Regel ist es eh umgekehrt: Viele Bewerber fragen tatsächlich, ob sie bei uns mit Windows arbeiten müssten.
Und damit es nicht ganz off topic ist: Wir hatten früher alle Linux Workstations. Wir konnten aber vor über 5 Jahren die Geschäftsleitung davon überzeugen, dass man zum einen mit Macs produktiver ist (wir müssen auch o365 nutzen) sowie auch in Richtung potentieller Mitarbeiter sowie Kunden etwas anderes ausstrahlt. Und funktioniert tatsächlich. Du gewinnst zwar keinen Kundenpitch, weil du dich da mit nem Mac hinstellst und du bekommst somit auch nicht automatisch neue Leute. Aber du vermittelst beim Kunden einen professionelleren Eindruck und der Bewerber bekommt in der Regel schon einen kleinen "habenwill" Effekt. Wie gesagt: Ganz sicher nicht ausschlaggebend aber ein wenig richtungsweisend
Ergänzung ()
Das ist gelinde gesagt völliger Blödsinn. Selbst wenn du Windows Kisten für Single Sign On nutzt, konfigurierst du auf Linux seite den sssd so, dass er den AD als Backend nimmt. Die User im AD brauchen halt Unix Attribute und als custom field hinterlgest du den ssh key. Letzteren fragt der sshd direkt via AuthorizedKeysCommand (sss_ssh_authorizedkeys) ab.PHuV schrieb:Und was machst Du, wenn Du - wie ich - hunderte von Servern hast, mit unterschiedlichen Kundensystemen, SSH-Keys, Zugangsdaten etc? Das hast Du doch nicht mehr im Kopf geschweige denn gescheit verwaltet. Und dann bist Du hier mit simplen SSH auch beim MacOS vollkommen überfordert und benötigst sehr wohl auch wieder ein Tool bzw gescheiten SSH-Client wie Putty und Co., weshalb ich sogar von einem Mac wieder zu Windows gewechselt hatte, weil bei MacOS so ein Tool damals nicht existierte bzw. zu teuer war in der Anschaffung für die Firma, wo ich tätig war.
Dein privater key ist selbstverständlich in der macOS keychain und via ssh-agent direkt verfügbar. Auch wenn jump hosts zu verschiedenen Kundensystemen verwendet werden, kann man das ganz einfach via agent forwarding realisieren.