Was sind Ihre Best Practices und zukünftigen Pläne für die Bereitstellung von Unixoid-Desktops? [geschlossen]

Ich habe Linux-Desktops für ein gemeinnütziges Funkobservatorium eingerichtet. Für mich war dies das erste Mal, dass ich darüber nachdenken musste, mehrere identische Computer "bereitzustellen", Login, Home-Verzeichnisse usw. zu zentralisieren. Mir wurde schnell klar, dass die Philosophie "Alles ist Text", vielleicht entgegen der Intuition, dies nicht unbedingt zu einer einfachen Aufgabe macht, und ich fragte mich, was erfahrene Administratoren dagegen tun.

In meinem Fall habe ich Ubuntu 10.04 LTS auf jedem Computer installiert. Nach der Installation habe ich ein benutzerdefiniertes Skript ausgeführt, das Konfigurationsdateien ändert, Software entfernt und installiert und einige Dateien wie Hintergrundbilder oder Browser-Lesezeichen vom Server kopiert. Ich denke jedoch, dass meine Fragen distro-unabhängig sind.

Probleme

Ich hatte hauptsächlich zwei Probleme: Erstens inkonsistente Tools und Konfigurationsdateien, sowohl über Distributionen als auch über Versionen hinweg, und zweitens einige wichtige Software, die Einstellungen nicht auf einfache und intuitive Weise für Konfigurationsdateien verfügbar macht.

Lassen Sie mich zwei kurze Beispiele für das geben, was ich meine:

Das ifconfigWerkzeug wird ersetzt durch ip. Alle Skripte, die auf dem Vorhandensein des ersteren beruhen, werden unterbrochen, wenn sie beispielsweise auf einer aktuellen ArchLinux-Box ausgeführt werden. Also müsste ich überprüfen, welche Tools in welchen Versionen auf einem Computer vorhanden sind, auf dem ich ein Skript ausführe ... das fühlt sich irgendwie so an, als würde man Autoconf in kleinem Maßstab neu erfinden.

Denken Sie beim zweiten Problem daran, dass ich den Desktops eine Art "gemeinsame Identität" geben wollte. In meinem Post-Install-Config-Skript verwende ich die folgenden Zeilen, um dies zu erreichen:

scp user@server:/export/admin/*.jpg /usr/share/backgrounds/
scp user@server:/export/admin/ubuntu-wallpapers.xml /usr/share/gnome-background-properties/
sed 's/warty-final-ubuntu\.png/MyBackground\.jpg/' -i /usr/share/gconf/defaults/10_libgnome2-common
sed 's/warty\-final\-ubuntu\.png/MyBackground\.jpg/' -i /usr/share/gconf/defaults/16_ubuntu-wallpapers
sed 's/ubuntu-mono-dark/ubuntu-mono-light/' -i /usr/share/gconf/defaults/16_ubuntu-artwork
sed 's/Ambiance/Clearlooks/' -i /usr/share/gconf/defaults/16_ubuntu-artwork

Ich nehme an, dass das Erstellen eines CI eine häufige Aufgabe für Organisationsadministratoren ist. Wie kommt es, dass es keine zentrale Konfigurationsfunktion gibt, vielleicht sogar Cross-Desktop? Es erscheint mir seltsam, zwei (identische!) Undokumentierte Werte in zwei unterschiedlichen Konfigurationsdateien festlegen zu müssen.

Fragen

Wie gehen Sie in einer organisatorischen Umgebung mit der zentralen, einheitlichen Konfiguration über mehrere Clients hinweg um?

Bieten Systeme wie Debians FAI erhebliche Vorteile (abgesehen davon, dass keine CDs gewechselt werden müssen) gegenüber meiner Methode "Zuerst installieren, danach Skript ausführen"?

Was sind bewährte Methoden für den Übergang zwischen Hauptversionen Ihrer Distribution? Und abgesehen von den technischen Dingen: Gibt es eine Desktop-Umgebung, die langfristige Stabilität in Bezug auf die Benutzererfahrung verspricht? Ich glaube nicht, dass ich meine Benutzer auf KDE 4 oder GNOME 3 migrieren kann, aber XFCE hat immer noch einige funktionale Nachteile ...

Gibt es ein * nix-System, das diese Art von Konfigurationsproblemen behebt? Ich würde beispielsweise annehmen, dass es Systeme gibt, die Sie nach Bildern Ihrer Organisation fragen (Logos, Hintergrundbilder, Farb- und Schriftarten usw.) und diese auf den Anmeldemanager, die Desktops der Benutzer, Webanwendungen (!) Usw. anwenden auf. Hinweis: In unserem Fall muss ich mit fetten Kunden arbeiten, sodass eine reine Thin-Client-Lösung nicht hilft.

Die Verwendung von Puppet oder CFEngine oder Chef ist die richtige Lösung für Ihr Problem. Natürlich wird es einige Zeit und einen Versuch und Irrtum-Ansatz erfordern, um das Puppet-Skript zu schreiben, das einfach funktioniert. Diese Tools werden häufig zur Automatisierung komplexer Installationen in der Cloud verwendet und haben das Leben von Administratoren wie uns vereinfacht. :) :)

Erwarten Sie zunächst nicht, dass die Arbeit mit mehreren Distributionen einfach sein wird.

Ich habe keine großen Desktop-Rollouts ausgeführt. Für mich war der beste Kompromiss, ein LAN-Boot / TFTP zu verwenden, um das System zu booten und dann die Installation über NFS auszuführen. Die meisten Linux-Distributionen fragen Sie nach der ersten Konfiguration im Voraus - dann können Sie das Installationsprogramm beispielsweise 40 Minuten lang unbeaufsichtigt ausführen lassen (keine Eingabeaufforderung "Möchten Sie dieses Programm wirklich ausführen?"). Zu diesem Zeitpunkt kümmerte ich mich um Redhat- und Suse-Maschinen - und ließ eine Drehzahl mit allen benutzerdefinierten Konfigurationen vorbereiten, die ich nach Abschluss der Standardinstallation installiert hatte. Es ist jedoch durchaus möglich, all dies in einer Vielzahl von Distributionen zu automatisieren .

Ich bin aus verschiedenen Gründen kein großer Fan der Ubuntu-Distribution, aber Canonicals Lanscape ist ein sehr beeindruckendes Tool. Und wenn Sie viele umfangreiche Ubuntu-Installationen / -Verwaltungen für mehrere Ubuntu-Desktops durchführen möchten, ist es definitiv einen genaueren Blick wert.

Ich habe viel mit Software namens CFEngine gearbeitet . Es ist ein Open-Source-Konfigurationsmanager, der die von Ihnen festgelegten "Regeln" liest und sicherstellt, dass jeder Computer, an den er gebunden ist, diese Regeln einhält und respektiert. Es ist vollständig Open Source und so nützlich, dass unser Unternehmen beschlossen hat, die unterstützte Version der Software namens Nova zu verwenden.

Dies ist eine umfassende Ansicht der Funktionsweise. Angenommen, Sie haben 4 Computer in Ihrem verwalteten Netzwerk. Sie alle müssen eine Datei haben /etc/syslog.conf, die root gehört, egal (laut einem Master) und chmod 777. Sie würden diese Regel in der Konfigurationsdatei von CFEngine erstellen. Von Ihrem zentralen Computer aus haben Sie die "Master" /etc/syslog.conf-Datei. Alle X Zeiträume durchläuft die CFEngine-Version Ihres Computers das Netzwerk und fragt jede Box nach ihrer /etc/syslog.confDatei. Die lokale Kopie von CFEngine, die auf jedem Client ausgeführt wird, fragt die betreffende Datei ab und meldet deren Inhalt, Berechtigungen usw. zurück. Wenn sie nicht GENAU mit Ihrer Caster-Kopie übereinstimmen, sendet CFEngine Ihre Kopie an den Client und überprüft die Dateien erneut. Sie werden übereinstimmen und er wird zu Ihrer nächsten Regel übergehen.

Der Einfachheit halber ist die in den "Regeln" von CFEngine verwendete Syntax (die sie als Versprechen bezeichnen) zwar etwas gewöhnungsbedürftig, aber es lohnt sich, sie zu lernen (erweitert Ihre Fähigkeiten um eine weitere großartige Fähigkeit).

Wie kommt es, dass es keine zentrale Konfigurationsfunktion gibt?

Gnome hat GConf, das alle diese kleinen Aufgaben ausführen kann:

http://wiki.novell.com/index.php/Locking_Down_the_GNOME_Desktop

http://library.gnome.org/admin/system-admin-guide/stable/gconf-9.html.de

Ubuntu LTS ist fast die einzige Option für die langfristige Unterstützung auf dem Desktop.

Die Bereitstellung mehrerer Computer ist mit nur einer einfachen Funktion fast möglich. ddDie Desktops-Verteilungen machen diese Route langsam weniger attraktiv.

Eine Option ist jetzt auch der sogenannte Fat Client .