Jakie są najlepsze praktyki i plany na przyszłość dotyczące wdrażania komputerów z systemem Unixoid? [Zamknięte]


9

Konfigurowałem komputery z systemem Linux dla obserwatorium radiowego non-profit. Dla mnie to był pierwszy raz, kiedy pomyślałem o „wdrożeniu” kilku identycznych komputerów, centralizacji logowania, katalogów domowych i tak dalej. Szybko stało się dla mnie jasne, że filozofia „wszystko jest tekstowe” niekoniecznie intuicyjnie niekoniecznie sprawia, że ​​jest to łatwe zadanie, i zastanawiałem się, co z tym robią doświadczeni administratorzy.

W moim przypadku instalowałem Ubuntu 10.04 LTS na każdym komputerze. Po instalacji uruchomiłem niestandardowy skrypt, który zmienia pliki konfiguracyjne, usuwa i instaluje oprogramowanie oraz kopiuje niektóre pliki, takie jak obrazy tła lub zakładki przeglądarki, z serwera. Myślę jednak, że moje pytania są niezależne od dystrybucji.

Problemy

Miałem przede wszystkim dwa problemy: po pierwsze niespójne narzędzia i pliki konfiguracyjne, zarówno w dystrybucji, jak i w różnych wersjach, a po drugie niektóre kluczowe oprogramowanie, które nie ujawnia ustawień plików konfiguracyjnych w łatwy i intuicyjny sposób.

Podam dwa krótkie przykłady tego, co mam na myśli:

ifconfigNarzędzie jest zastąpiona ip. Wszystkie skrypty bazujące na obecności tego pierwszego ulegną awarii, jeśli na przykład zostaną uruchomione na bieżącym komputerze ArchLinux. Musiałbym więc sprawdzić, które narzędzia, w których wersjach są obecne na komputerze, na którym uruchamiam skrypt ... to w jakiś sposób przypomina wynalezienie autoconf na małą skalę.

W przypadku drugiego problemu rozważmy, że chciałem nadać komputerom coś w rodzaju „wspólnej tożsamości”. W moim skrypcie po instalacji-konfiguracji używam następujących wierszy:

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

Podejrzewam, że tworzenie CI jest częstym zadaniem dla administratorów organizacji. Dlaczego więc nie ma centralnej konfiguracji, może nawet na wielu komputerach? Konieczność ustawienia dwóch (identycznych!) Nieudokumentowanych wartości w dwóch różnych plikach konfiguracyjnych wydaje mi się dziwna.

pytania

W jaki sposób w środowisku organizacyjnym radzisz sobie z centralną, ujednoliconą konfiguracją wielu klientów?

Czy systemy takie jak FAI Debiana oferują znaczące zalety (poza tym, że nie trzeba zmieniać płyt CD) w porównaniu z moją metodą „najpierw zainstaluj, potem uruchom skrypt”?

Jakie są dobre praktyki przejścia między głównymi wersjami Twojej dystrybucji? Poza kwestiami technicznymi: czy istnieje środowisko komputerowe, które zapewnia długoterminową stabilność pod względem komfortu użytkowania? Nie sądzę, że mogę migrować moich użytkowników do KDE 4 lub GNOME 3, ale XFCE wciąż ma pewne wady funkcjonalne ...

Czy istnieje system * nix, który rozwiązuje tego typu problemy z konfiguracją? Załóżmy na przykład, że istnieją systemy, które proszą Cię o zdjęcia Twojej organizacji (logo, obrazy tła, zestawy kolorów i czcionek itp.) I stosują je do menedżera logowania, komputerów użytkowników, aplikacji internetowych (!) Itd. na. Uwaga: W naszym przypadku muszę pracować z grubymi klientami, więc rozwiązanie oparte na cienkich klientach nie pomoże.

Odpowiedzi:


3

Korzystanie ze Puppet, CFEngine lub Chef jest właściwym rozwiązaniem dla twojego problemu. Oczywiście napisanie skryptu lalkowego, który po prostu działa, zajmie trochę czasu oraz podejście prób i błędów. Narzędzia te są szeroko stosowane do automatyzacji złożonych instalacji w chmurze i uprościły życie administratorom takim jak my. :)


Dzięki za podpowiedź! Jak już wcześniej pytałem MaxMackie, czy Puppet zapewnia jakąkolwiek „scentralizowaną, crowdsourcingową inteligencję” w odniesieniu do reguł przepisywania przy przełączaniu między głównymi wersjami mojej dystrybucji? Na przykład, jeśli wiem, że $ DISTRO przełącza się z GNOME 2 na 3, czy będzie półautomatyczna ścieżka migracji?
jstarek

Możesz napisać plik dla, powiedzmy, konfiguracji Gnome3 i dołączyć go do konfiguracji hostów, na których chcesz zainstalować Gnome3. ale zależy to również od tego, jak utworzysz konfigurację marionetek. Jeśli zastosujesz podejście modułowe, będzie to łatwiejsze. Sama kukiełka nie będzie w stanie zidentyfikować Gnome3 lub 2. (mam nadzieję, że dobrze zadałem twoje pytanie)
Abhishek A

3

Po pierwsze, nie oczekuj, że będzie to łatwe w przypadku wielu dystrybucji.

Nie uruchomiłem dużych wdrożeń pulpitu. Dla mnie najlepszym kompromisem było użycie bootowania / tftp LAN do ładowania systemu, a następnie uruchomienie instalacji przez NFS. Większość dystrybucji Linuksa prosi o wstępną konfigurację z góry - wtedy możesz zostawić instalator na działanie, powiedzmy 40 minut, bez nadzoru (nie pojawia się monit „Czy na pewno chcesz uruchomić ten program?”). W tym momencie opiekowałem się maszynami Redhat i Suse - i przygotowałem RPM ze wszystkimi niestandardowymi konfiguracjami, które zainstalowałem po zakończeniu standardowej instalacji. Jednak całkiem możliwe jest zautomatyzowanie tego wszystkiego na różnych dystrybucjach.

Z różnych powodów nie jestem wielkim fanem dystrybucji Ubuntu, ale Lanscape firmy Canonical to bardzo imponujące narzędzie. A jeśli zamierzasz wykonywać wiele dużych instalacji Ubuntu / zarządzać wieloma pulpitami Ubuntu, zdecydowanie warto się temu przyjrzeć.


Patrząc na stronę Landscape, mam wrażenie, że nie obsługuje wpisów plików konfiguracyjnych - więc czy stworzyłbym lokalne pakiety, które dokonują zmian potrzebnych podczas instalacji?
jstarek

1

Dużo pracuję z oprogramowaniem o nazwie CFEngine . Jest to menedżer konfiguracji open source, który czyta „reguły”, które ustawiłeś i zapewnia, że ​​każdy komputer, do którego jest podłączony, i przestrzega tych reguł. Jest to oprogramowanie całkowicie otwarte i bardzo przydatne, dlatego nasza firma zdecydowała się na obsługiwaną wersję oprogramowania o nazwie Nova.

To jest szerokie spojrzenie na to, jak to działa. Załóżmy, że masz 4 komputery w zarządzanej sieci. Wszystkie muszą mieć plik /etc/syslog.conf, którego właścicielem jest root, wszystkie takie same (według mistrza) i chmod 777. Utworzyłbyś tę regułę w pliku konfiguracyjnym CFEngine. Z komputera centralnego masz /etc/syslog.confplik „główny” . Co X okres czasu, wersja CFEngine twojego komputera będzie przechodzić przez sieć i pytać każde pole o jego /etc/syslog.confplik. Lokalna kopia CFEngine działająca na każdym kliencie będzie pytać o dany plik i zgłaszać jego zawartość, uprawnienia itp. Jeśli nie są DOKŁADNIE zgodne z twoją kopią rzucającą, CFEngine popchnie twoją kopię do klienta i sprawdzi pliki ponownie. Będą pasować, a on przejdzie do następnej reguły.

Jeśli chodzi o prostotę, składnia zastosowana w „regułach” CFEngine (które nazywają obietnicami) może trochę przyzwyczaić się, ale warto je się nauczyć (dodaje kolejną wielką umiejętność do zestawu umiejętności).


Dzięki za podpowiedź, spojrzę na CFEngine. Jednak z tego, co przeczytałem do tej pory, wydaje się, że nie uratuje mnie to od przepisywania reguł po przejściu na nową główną wersję mojej dystrybucji, prawda?
jstarek

1

Dlaczego więc nie ma centralnej konfiguracji,

Gnome ma GConf, który może wykonywać wszystkie takie drobne zadania:

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

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

Ubuntu LTS to prawie jedyna opcja długoterminowego wsparcia na komputerze.

Wdrażanie wielu maszyn jest prawie możliwe za pomocą prostej dd, dystrybucji komputerów stacjonarnych powoli czyni to mniej atrakcyjną trasę.

Rozważ także teraz opcję tak zwanego grubego klienta .


Już używam grubych klientów, ale to nie ułatwia konfiguracji - po prostu pobierają informacje o homedir i passwd z centralnego serwera. Jeśli GNOME nie użyje GConf i nie umieści ważnych plików konfiguracyjnych w / usr / share / gconf / defaults /, można po prostu zatrzymać centralne / etc / gdzieś na serwerze i mieć grubych klientów, którzy go zamontują, ale nie, faceci GNOME wydaje się wiedzieć lepiej. Westchnienie ...
jstarek

@jstarek grubych klientów zamontować /, GConf zastępuje na żywo w/etc/gconf/gconf.xml.*/
Steve-o
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.