Frage Sperrt eine Entwicklermaschine mehr Aufwand als es wert ist? [geschlossen]


Nachdem ich als Entwickler und IT-Administrator für ein Entwicklungsteam gearbeitet habe, bin ich auf viele verschiedene Arten von Umgebungen gestoßen, von komplett gesperrten bis hin zu komplett nicht. In meiner begrenzten Support-Erfahrung war es meiner Meinung nach weniger Aufwand, mit einer weniger abgesperrten Maschine zu arbeiten, und ich hielt das sicher für einfacher, aber natürlich könnte das eine Voreingenommenheit sein. Ich würde gerne wissen, was die Ansicht aus der Perspektive eines IT-Supports ist. Ist es wirklich schwieriger, Entwickler zu unterstützen, die nicht gesperrte Maschinen haben?


19
2018-05-27 12:57


Ursprung


Angesichts des großen Programmierersegments der Server Fault-Population von Stack Overflow wette ich, dass dies unter Selektionsverzerrungen leidet. Welcher Entwickler wird wirklich sagen: "Schließ mich bitte ab!" - romandas


Antworten:


Das größte Problem beim Sperren eines Entwicklungscomputers besteht darin, dass jede von ihnen entwickelte Software zum Ausführen vollständige Administratorrechte erfordert. Der Zugriff der Entwickler sollte derselbe sein wie die Umgebung, in der sie ausgeführt werden müssen. Wenn sie "selbstunterstützend" oder "selbst installierbar" sein müssen, geben Sie ihnen einen anderen Administrator-Account, z. Bruce.admin, die sie brauchen, wenn sie Admin-Sachen machen, aber nicht jeden Tag benutzt werden.

Genau wie kein vernünftiger UNIX-Administrator, der sein Geld wert ist, wird er für seine tägliche, nicht-administrative Arbeit immer ein root-Konto verwenden.


11
2018-05-27 13:31



Ich nehme Anstoß an "wird verlangen". Du machst es wie eine ausgemachte Sache, dass Entwickler natürlich das Falsche tun werden. Obwohl ich zustimme, dass die Entwicklung von Software, die nur mit unnötig hohen Privilegien läuft, weniger als wünschenswert ist, denke ich nicht, dass die IT versuchen sollte, bestimmte Entwicklungspraktiken mit harten Maßnahmen wie Maschinensperre durchzusetzen. Wenn die IT ein Interessensvertreter bei der Festlegung von Anwendungsanforderungen ist - und dies sollte für interne Apps gelten - dann sollten Anwendungen entwickelt und getestet werden, damit sie mit geringeren Berechtigungen ausgeführt werden können. - Chris W. Rea
Aber ich denke, dass die Idee eines separaten Accounts von Vorteil ist. Aber zwing es mir nicht, das ist alles. - Chris W. Rea
Unter Windows ist es besser, das anders herum zu machen. Erstellen Sie Testkonten, die sich mit den Berechtigungen eines Standardbenutzers verhalten. Anwendungen können getestet werden, indem Sie sich als Testbenutzerkonto beim Computer (oder einer VM) anmelden. - ConcernedOfTunbridgeWells
Aufgrund meiner 15-jährigen Erfahrung in der technischen Prüfung habe ich das "Willenserfordernis" formuliert. Sicher, es gibt Ausnahmen, aber die Mehrheit der Anwendungen auf Windows sind nicht für die wenigsten Privilegien entwickelt, und das liegt nicht daran, dass Entwickler natürlich das Falsche tun, weil es wirklich schwer ist, richtig zu tun. - Bruce McLeod
Nachdem ich mehrere Tausend verschiedene Apps verwendet hatte, brauchten nur 5% Adminrechte ohne wirklichen Grund. - Mircea Chirea


Die meisten Entwickler sind technisch versiert und wissen, was sie tun. Sie müssen oft viele spezialisierte Apps installieren, müssen dafür die Erlaubnis bekommen und die IT dazu bringen, herunter zu kommen und es hinzuzufügen, kann sehr frustrierend sein, besonders in größeren Unternehmen, für beide Seiten.

Ich habe herausgefunden, was am besten funktioniert, wenn man ihnen erlaubt, das zu tun, was sie wollen, wenn es darum geht, Software auf ihren Maschinen zu installieren, aber wenn sie Probleme mit etwas bekommen, das wir nicht unterstützen, dann sind sie auf sich gestellt. Die meisten Entwickler sind damit zufrieden und bevorzugen es trotzdem, sich um ihre eigene Maschine kümmern zu können.

Sperren Sie jemanden in der Buchhaltung, nur IE zu verwenden und zu öffnen Wort ist in Ordnung, aber wenn Sie ein Entwickler, der 4 verschiedene Arten von Browser installieren muss und schnell eine App installieren müssen, um ein Problem zu lösen, kann es lästig sein.

Meine Erfahrung ist, dass Unternehmen, die viel technisches Wissen haben, also Entwicklungsläden, IT-Lieferanten usw., die ihren Angestellten vertrauen und sie entscheiden lassen, was sie installieren wollen, viel glücklicher sind und IT weniger belästigen


55
2018-05-27 13:06



Wenn ich mehrmals für diese Antwort stimmen könnte, würde ich es tun. Ich bin Entwickler und stimme 110% zu. +1 - Chris W. Rea
@ cwrea: Was könnte der 10% Überschuss sein? - setzamora
Ich stimme zu, aber Unternehmen, die in Bezug auf Informationssicherheit sehr streng sind, werden niemals Anwendungen zulassen, die keine "Unternehmensstandards" sind. - setzamora
Nachdem mir gerade meine Admin-Rechte entzogen wurden, stehe ich jede halbe Stunde per E-Mail beim Support, um dies oder jenes zu bekommen oder um diese Einstellung oder diese Einstellung zu ändern. Ein häufiges Thema für die Überprüfung von Bereitstellungsdaten war das Doppelklicken auf die Uhrzeit im Benachrichtigungsbereich. Etwas, dass ich jetzt "nicht die richtige Berechtigungsebene habe" für ... Es macht mich verrückt!
Wenn man sagt, dass "wenn man es deinstalliert, wird es nicht unterstützt" ist alles gut und gut, praktisch wird es zu einem Entwickler, der sich bei seinem Chef beschwert, dass Software xyz nicht funktioniert und Systems / Helpdesk mir nicht helfen wird. Boss wird von seinem Kollegen abgeschossen, und das nächste, was Sie wissen, ist, dass ein Manager / Director / VP jemandem den Atem räuspert und sich nicht darum kümmert, dass es nicht unterstützt wird, sondern reparieren Sie es jetzt. Jetzt muss Systems / Helpdesk das zufällige Programm xyz für den Entwickler a und das zufällige Programm abc für den Entwickler b unterstützen. Wenn Sie es wirklich brauchen, legen Sie es durch die Kanäle. - Zypher


Sehen diese Stackoverflow-Buchung für eine lebhafte Debatte über die Vorteile der Sperrung von Entwicklungsmaschinen. (Disclaimer: Ich habe die akzeptierte Antwort geschrieben).

Aus der Sysadmin-Perspektive ist der Zugriff auf Produktionssysteme sensibel und Sie sollten diesen Zugriff auf Personen beschränken, die diese für ihre Arbeit benötigen (dies können Entwickler sein, die Tier-3-Support-Verantwortlichkeiten für die Anwendung haben). Lokale Administratorrechte über einen Entwicklungs-PC oder Entwicklungsserver beeinträchtigen die Sicherheit Ihrer Produktionssysteme nicht wesentlich.

Erstellen Sie ein Image, mit dem Sie die Maschinen ggf. neu erstellen können. Manuelles Installieren der SQL Server-Entwickleredition, Visual Studio, Cygwin und MikTex plus eine Reihe anderer Apps ist ziemlich zeitaufwendig. Ein Bild mit diesen großen Apps wird einigermaßen wertvoll sein, wenn Sie die Maschinen viel neu abbilden müssen.

Aus Entwicklungsperspektive finde ich, dass ich die meisten Probleme mit der Maschine beheben kann und in der Regel nur selten Hilfe von Netzwerkunterstützungspersonal benötige. Übermäßig restriktive Umgebungen erzeugen tendenziell einen fehlerhaften Entwickler-Support-Verkehr, um Arbeit zu leisten, die die Entwickler selbst in der Lage sind.

Ein anderer Ort, an dem Entwickler dazu neigen, viel Verwaltungsarbeit zu leisten, sind Datenbankserver, die Entwicklungsumgebungen hosten. Die meisten Entwickler sind in der Lage, routinemäßige DBA-Aufgaben einfach zu erlernen, und sollten dies ohnehin wissen (IMHO grundsätzlich). Zu restriktive Administratorzugriffsrichtlinien auf Entwicklungsservern können auf viele Arten unterlaufen.

Ein Scratch-Entwicklungsnetzwerk ist eine gute Idee, wenn es arrangiert werden kann - Sie können dies bei Bedarf von Ihren Produktionsservern aus sichern.

  • Wenn Entwickler die Struktur einer Produktionsumgebung leicht reproduzieren können, fördert dies eine Kultur der Bereitstellungstests, bei der ein Integrationstest synthetisiert werden kann, ohne durch Ringe springen zu müssen. Dies wird tendenziell die Qualität der Produktionsfreigabe und -bereitstellung verbessern.

  • Die Fähigkeit, eine Produktionsumgebung zu emulieren, erhöht auch das Bewusstsein für Produktionsbereitstellung und Supportprobleme. Es ermutigt Entwicklungspersonal, darüber nachzudenken, wie eine Anwendung in der Produktion unterstützt werden könnte, was wahrscheinlich Architekturen ermutigen wird, die in diesem Sinne entwickelt wurden.

  • Wenn dieses Netzwerk über einen Domänencontroller verfügt, können Sie eine Vertrauensstellung einrichten, sodass es Ihrem Hauptdomänencontroller und seinen Konten vertraut. Diese Vertrauensbeziehung muss nicht gegenseitig sein, damit die Sicherheit Ihrer Produktionsnetzwerkinfrastruktur nicht beeinträchtigt wird. Dadurch können Sie ein nicht vertrauenswürdiges Entwicklungsnetzwerk haben, aber Entwicklern weiterhin Zugriff auf domänenautorisierte Ressourcen wie Exchange-Konten oder Dateiserver gewähren.

  • Sie möchten Entwicklern eine angemessene Menge an Experimentiermöglichkeiten zur Verfügung stellen, ohne durch die Ringe springen zu müssen. Wenn politische Hindernisse in den Weg dieser Arbeit gerückt werden, besteht die Tendenz, dass politisch haftende Putzlösungen gefördert werden, die aber langfristige (und oft nicht erkannte) technische Schulden erzeugen. Erraten Sie als Systemadministrator oder Support-Analyst, wer die Stücke abholen darf ...

Ich füge hinzu, dass dies in einer Unix- oder Linux-Umgebung viel weniger ein Problem ist; Benutzer können ihre eigene Umgebung ziemlich stark von ihren anpassen .profile. Sie können Dinge selbst kompilieren und installieren /home/bloggsj/bin Verzeichnis nach Herzenslust. 'Lokale Admin-Rechte' sind meist ein Windows-Problem, obwohl es unter Unix noch ein paar Dinge gibt, die Root-Zugriff benötigen.


14
2018-05-27 13:06



Ich wollte deinen letzten Aufzählungspunkt kommentieren. Sie erwähnen "politische Hindernisse" - denken Sie daran, dass die ursprüngliche Absicht von Sicherheitspraktiken alles ist aber politisch. Es kann sich später in etwas anderes verwandeln, denn alle Orgs erwerben schließlich Menschen, die dem Brief folgen, aber nicht der Absicht der Regel - oder schlimmer noch, einstmals noble Politik in Feifdoms zu verwandeln. Aber gute Sicherheit und gute Politik können Hand in Hand gehen. Es bedarf jedoch Bemühungen von allen Beteiligten in gutem Glauben. - quux
Im Allgemeinen wird eine vernünftig verwaltete Politik diese Art von politischem Hindernis nicht erzeugen oder zumindest nicht unüberwindbar machen. IT-Richtlinien werden jedoch tendenziell von Fall zu Fall entwickelt und sind nicht immer "vernünftig". - ConcernedOfTunbridgeWells


Die vernünftigste Option, die ich je gesehen habe (war auf beiden Seiten - und immer noch-) ist einfach entriegeltes Zeug und nicht unterstützt auch. Gib ihnen die Freiheit, und wenn sie es vermasseln, können sie nur eine Wiederherstellung mit einem Standardbild bekommen .... In dieser Situation finde ich es gut, sie in irgendeine Form von "nicht vertrauenswürdigem" Netzwerk zu bringen.

Was das (Nicht-) Gefühl der Sperrung von Entwickler-Desktops angeht: Ich bin mir ziemlich sicher, dass die gesamte Verriegelung die Produktivität ohnehin behindert, außerdem wird jeder einigermaßen qualifizierte Entwickler leicht die Löcher finden ....


8
2018-05-27 13:07



Ich bekomme ca. 20 Minuten Support dann das Angebot eines neuen Images. Funktioniert gut für uns. - Preet Sangha


Die Antwort ist wirklich: Es gibt keine einfache Ja oder Nein Antwort. Aber Sicherheit ist für Ihre Entwickler genauso wichtig wie für jeden anderen.

Auf der einen Seite neigen ja devs dazu, technisch versierter zu sein. Auf der anderen Seite sind sie oft ein stressiger Job und ihre Dev-Meilensteine ​​werden wahrscheinlich Vorrang vor der zusätzlichen Sorgfalt haben, die benötigt wird, um das eigene System als sichere Umgebung zu erhalten. Dies ist keine Kritik der Entwickler; es ist eine offene Betrachtung ihrer täglichen Pflichten.

Wenn Sie Entwicklern vollen, uneingeschränkten Zugriff auf ihre Systeme gewähren wollen, sollten Sie folgende zusätzliche Maßnahmen in Betracht ziehen:

  • Stellen Sie ein anderes System zur Verfügung, das so weit gesperrt ist, wie normale Benutzersysteme gesperrt sind, für normale Nicht-Entwickler-Nutzung.
    • Die Full-Access-Dev-Maschinen werden in ein spezielles VLAN gestellt, mit Zugriff nur auf Dev-Ressourcen.
  • Fragen Sie, ob etwas verhindern würde, dass ein infiziertes System die Codebasis gefährdet. Könnte eine Backdoor-Maschine bösartigen Code einchecken oder die Codebasis in den Händen eines feindlichen Hackers auslöschen? Ergreifen Sie geeignete Maßnahmen, um dieses Risiko zu mindern.
  • Fragen Sie auch, ob die Geschäftsdaten in Systemen, auf die die Entwickler Zugriff haben, geschützt sind.
  • Führen Sie regelmäßig Software-Inventarisierung und Sicherheitsüberprüfung von Entwicklungssystemen durch.
    • Machen Sie sich ein Bild von dem, was sie gerade tun, und verwenden Sie diese Informationen, um Ihre Images für die Neuverteilung von Dev-Systemen zu erstellen.
    • Früher oder später wirst du einen Entwickler haben, der unvorsichtig wird und Dinge installiert, die eindeutig gefährlich oder völlig arbeitslos sind. Wenn Sie in diesem Fall schnell Warnungen senden, werden Sie die Dev-Community darüber informieren, dass ja jemand zusieht, und sie haben die Verantwortung, angemessene Standards einzuhalten.
  • Machst du regelmäßige Malware-Scans? In einigen Fällen werden sich Entwickler zu Recht über die Leistungsteuer beschweren, die von On-Access-AV-Systemen erhoben wird (jene AV-Systeme, die immer eingeschaltet sind und immer mit jedem Dateizugriff scannen). Es ist möglicherweise vorzuziehen, zu einer nächtlichen Scan-Strategie zu wechseln und / oder Datei- / Ordnerausschlüsse für Ihre On-Access-Scans zu erstellen. Stellen Sie sicher, dass ausgeschlossene Dateien auf andere Weise gescannt werden.
    • Können Ihre admin-fähigen Entwickler alle AV-Scans ausschalten? Wie würden Sie das erkennen und beheben?

Wenn Sie Dev-Systeme sperren wollen, sollten Sie Folgendes beachten:

  • Haben Sie die Support-Fähigkeit, um Ihre Support-Anfragen schnell zu beantworten? Berücksichtigen Sie die durchschnittliche Pay-Rate Ihrer Entwickler und fragen Sie, ob sie ein schnelleres Antwortzeit-SLA verdienen. Es macht wahrscheinlich keinen Sinn, Ihren $ 120.000 Entwickler (der der Schlüssel zu einem Multimillionen-Dollar-Projekt ist) auf sich warten zu lassen, während Sie Support-Anfragen von $ 60.000 / Jahr Mitarbeitern bearbeiten.
  • Haben Sie klare und unmissverständliche Richtlinien, welche Supportanfragen Sie für Ihre Entwickler ausführen und welche nicht? Wenn sie das Gefühl bekommen, dass Unterstützung willkürlich ist, dann werden schließlich den Schmerz fühlen.

In jedem Fall müssen Sie zugeben, dass Entwickler ein spezieller Fall sind und sie zusätzliche Unterstützung benötigen. Wenn Sie dies nicht planen, werden die Probleme wahrscheinlich jetzt schwächen ... oder werden in der Zukunft sein.

Als Nebenbemerkung habe ich gesehen, dass sehr ähnliche Argumente mit Sysadmins auftreten. Bei mindestens zwei verschiedenen Jobs habe ich gesehen, dass Sysadmins recht widerspenstig argumentieren, wenn man ihnen vorschlug, dass sie selbst gesperrte Systeme haben sollten, oder zumindest zwei Logins benutzen sollten (eines mit root / admin privs; eines ohne root). Viele Systemadministratoren waren der Meinung, dass sie in keiner Weise blockiert werden sollten, und argumentierten energisch gegen solche Maßnahmen. Früher oder später würde ein Lockdown-averner Admin einen Sicherheitsvorfall haben und das Beispiel hätte eine pädagogische Wirkung auf uns alle.

Ich war einer dieser Systemadministratoren, die ständig mit Admin-Privilegien zusammenarbeiteten. Als ich die Umstellung auf zwei Konten vornahm und nur nach Bedarf erhöhte, gebe ich zu, dass es in den ersten Monaten ziemlich frustrierend war. Aber der Silberstreif in der Cloud war, dass ich viel mehr über die Sicherheit der Systeme lernte, die ich verwaltete, als mein normaler Account unter den gleichen Einschränkungen lebte, die ich den Nutzern auferlegte. Es hat mich zu einem besseren Admin gemacht! Ich vermute, das gilt auch für Entwickler. Und glücklicherweise haben wir jetzt in der Windows-Welt UAC, was es einfacher macht, als eingeschränkter Benutzer zu laufen und nur bei Bedarf zu erhöhen.

Persönlich glaube ich nicht, dass irgendjemand über irgendeiner Form von Sicherheitspraktiken stehen sollte. Jeder (Systemadministratoren, Entwickler, oberes Management eingeschlossen) sollte genügend Sicherheitsverfahren und -aufsicht haben, um sie auf Trab zu halten. Anders gesagt, Unternehmenssysteme und -daten sind den Aufwand zum Schutz nicht wert.

Sagen wir es anders. Wenn Mark Russinovich sein kann von einem Rootkit aufgenommenkann jeder!


6
2018-06-04 22:56





Wenn Sie ein paar Entwickler haben, ist der Ansatz, sie Entwicklungsservern zu geben, eine Möglichkeit, aber wenn Sie eine ganze Etage von Entwicklern haben, dann bin ich sehr dagegen, ihnen irgendwelche Administratorrechte zu geben.

Das Problem ist, dass Sie mit einer ganzen Entwicklerschicht konfrontiert werden, von denen jeder tut, was sie tun. Normalerweise sind die meisten nicht einmal sicherheitsbewusst und wollen nur, dass ihre App funktioniert. Dann werden Sie gefragt: "Wir haben die Entwicklungsphase abgeschlossen, bitte replizieren Sie unsere Entwicklungsumgebung auf Test, Pre-Prod und Prod".

Sie haben auch die Angewohnheit, zufälligen Junk (schlecht gepackte Software) zu installieren, und dann delegieren Sie Sie, um es auf dem Dutzend oder so Servern in den anderen Schichten zu installieren.

Ich mache die Politik ziemlich einfach:

  • Entwickler erhalten KEINE Root-Zugriffe - für die Entwicklungsumgebung.
  • Die Entwickler erhalten Root-Zugriff auf VMware-Server vor der Entwicklung, aber KEINE Unterstützung.
  • Entwickler müssen entweder RPM-Pakete bereitstellen, die zu der Betriebssystem-Distribution gehören, auf der die App ausgeführt wird, ODER RPM-Pakete, die FHS und LSB entsprechen.
  • Keine ihrer Anwendungen kann unter allen Umständen als root ausgeführt werden
  • Die haben keinen Zugriff auf su oder sudo für den Benutzer der Anwendung, der gesperrt wird, um KEINE Shell-Zugriffe zu haben. (Dies ist für Buchhaltung / Audit).
  • Alle Befehle, die mit privilegiertem Zugriff ausgeführt werden müssen, müssen explizit angefordert und genehmigt werden - zu diesem Zeitpunkt wird es dem Server hinzugefügt sudoers Datei.
    • Keiner dieser Befehle / Skripts kann von ihnen beschreibbar sein.
    • Kein Skript (direkt oder indirekt), auf das diese Befehle verweisen, ist schreibbar.

Das obige wird vor allem dazu führen, dass sie darüber nachdenken, was wann und wo nicht erlaubt sein wird, um das Projekt auf den Test und über die Server zu bringen.


3
2018-05-31 04:51





Das Sperren von Entwicklern erfordert mehr Aufwand als es wert ist. Es schadet der Produktivität, da man ohne administrative Rechte nicht viel tun kann. Natürlich wird das System irgendwann durcheinander geraten, aber Ihre IT-Abteilung bietet keine Unterstützung für all diese Drittanbieter-Tools, die in der Entwicklung verwendet werden?

Wie Vincent De Baere vorgeschlagen hat, wäre es das beste Vorgehen, das System nur aus einem Image wiederherzustellen. Natürlich muss die Umgebung danach wiederhergestellt werden, aber das sollte nicht das Problem der IT sein. Wenn es N mal passiert, kannst du eine Person auf eine Art "schwarze Liste" setzen und, ja, seine administrativen Rechte für eine Weile fallen lassen.

In jedem Fall sollte die Umgebung so eingerichtet werden, dass sichergestellt wird, dass ein infizierter (oder anderweitig durcheinander gerateter) Computer keine anderen Computer beeinflusst oder, zum Beispiel, keinen Spam oder etwas sendet (ok, jetzt) Ich sage nur offensichtliche Dinge, sorry).


2
2018-05-27 13:25





Nun, es kann teilweise davon abhängen, in welcher Umgebung Sie laufen (z. B. Linux vs. Windows); Unter der Annahme einer Windows-Umgebung ist es jedoch normalerweise problematischer, als es sich lohnt, da einige der Entwicklungssoftware erforderlich sind, um erhöhte Berechtigungen zu haben. Zum Beispiel, Visual Studio benötigt bekanntermaßen AdministratorberechtigungenAls solche sehe ich keinen Vorteil darin, jemanden dazu zu bringen, für einen bestimmten Teil seiner Arbeit durch Reifen zu springen.

Allerdings, wenn das Unternehmen verlangt, dass Dinge gesperrt werden, ist Ihre beste Wette wahrscheinlich, alle Entwickler virtuelle Maschinen auf ihren Systemen zu geben, dass sie verrückt werden können. Während einige nicht so viel mögen, wird es wahrscheinlich das Beste aus beiden geben Welten (zB restriktiver normaler Desktop und eine vollständig anpassbare Umgebung).

Aktualisieren - Auf der Windows-Seite der Dinge gibt es ein bisschen mehr Wert, offensichtlich ist das Visual Studio, das Administratorrechte benötigt, ein bisschen veraltet und es gibt jetzt explizite Möglichkeiten, die erforderlichen Berechtigungen festzulegen (PDF Datei). Allerdings glaube ich nicht, dass dies meine Option so sehr ändert, dass die meisten Entwickler, die ich kenne, dazu neigen, zusätzliche Tools zu verwenden, die über Visual Studio hinausgehen, und zu wissen, was sie in Bezug auf Berechtigungen alles brauchen.


1
2018-05-27 13:56



Es stimmt, dass MS empfiehlt, VS2005 als Administrator auszuführen. Aber Michael Howard, einer der führenden Software-Sicherheitsleute bei MS, sagt, dass es in 99% der Fälle als nonadmin gut läuft: blogs.msdn.com/michael_howard/archiv/2007/01/04/...   ... Wenn Ihnen Sicherheit wichtig ist, können Sie versuchen, nonadmin auszuführen. Eine angenehme Überraschung erwartet Sie wahrscheinlich! - quux


Ich stimme dem Gedanken zu, virtuelle Maschinen auf einem eingeschränkten Desktop zu verwenden.

Wenn nicht anders notwendig, denke ich, dass das beste Setup ein eingeschränkter Linux-Desktop mit einem Free-for-All-VM ist. Linux verringert den Overhead für mich, ein VM kann nicht nur sein, was auch immer die Hölle OS sie wollen, sondern auch in Snapshots oder Backups wiederhergestellt werden, und im Allgemeinen sieht die Welt ein bisschen heller aus, wenn es nicht eine ganze Reihe von verschiedenen Setups benötigt Unterstützung.


1
2018-05-29 10:35



+1 .. Ich verstehe nicht, warum VMs so wenig genutzt werden. Nicht nur für den von Ihnen genannten Zweck, sondern auch für die Softwareverteilung mit VMs.