Які ваші найкращі практики та майбутні плани щодо розгортання робочих столів unixoid? [зачинено]


9

Я налаштовував настільні комп’ютери Linux для неприбуткової радіообсерваторії. Для мене це був перший раз, коли мені довелося думати про «розгортання» декількох однакових машин, централізацію входу, домашніх каталогів тощо. Мені швидко стало зрозуміло, що, можливо, всупереч інтуїції, філософія «все є текстуальною» не обов'язково робить це легким завданням, і я задумався, що досвідчені адміністратори роблять з цього приводу.

У моєму випадку я встановлював Ubuntu 10.04 LTS на кожній машині. Після встановлення я запустив спеціальний сценарій, який змінює конфігураційні файли, видаляє та встановлює програмне забезпечення та копіює деякі файли, наприклад фонові зображення чи закладки браузера, із сервера. Я думаю, однак, що мої запитання не залежать від дистрибуції.

Проблеми

В основному я стикався з двома проблемами: по-перше, непослідовними інструментами та конфігураційними файлами як у дистрибутивах, так і в різних версіях, по-друге, якесь важливе програмне забезпечення, яке не відкриває налаштування для налаштування файлів легко та інтуїтивно.

Дозвольте навести два короткі приклади того, що я маю на увазі:

ifconfigІнструмент замінюється ip. Усі сценарії, які покладаються на наявність колишнього, будуть порушені, якщо, наприклад, працювати у поточному вікні ArchLinux. Отже, мені потрібно було б перевірити, які інструменти, в яких версіях є на машині, на якій я запускаю сценарій ... це якось відчуває, як винаходити autoconf в невеликому масштабі.

Щодо другої проблеми, врахуйте, що я хотів надати настільним комп'ютерам якусь "спільну ідентичність". У своєму post-install-config-script я використовую наступні рядки для досягнення цього:

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

Я припускаю, що створення КІ є загальним завданням для адміністративних організацій. Отже, як же не існує центральної установки конфігурації, можливо, навіть перехресного робочого столу? Необхідність встановлення двох (однакових!) Недокументованих значень у двох різних конфігураційних файлах вважає мене дивним.

Запитання

Як в організаційному середовищі ви обробляєте центральну, єдину конфігурацію для кількох клієнтів?

Чи пропонують такі системи, як FAI Debian, значні переваги (окрім того, що не потрібно міняти компакт-диски) над моїм методом "встановити спочатку, запустити сценарій потім"?

Які хороші практики для переходу між основними версіями вашого розповсюдження? І, крім технічних речей: чи існує середовище робочого столу, яке обіцяє довгострокову стабільність, що стосується досвіду користувача? Я не думаю, що я можу перенести своїх користувачів на KDE 4 або GNOME 3, але XFCE все ще має деякі функціональні недоліки ...

Чи існує система * nix, яка вирішує такі проблеми з конфігурацією? Наприклад, я припускаю, що є системи, які запитують вас про деякі зображення вашої організації (логотипи, фонові зображення, набори кольорів і шрифтів тощо) і застосовують їх до менеджера входу, настільних користувачів, веб-додатків (!) Тощо на. Примітка. У нашому випадку мені доводиться працювати з товстими клієнтами, тому суто тонкий клієнт не допоможе.

Відповіді:


3

Використання Puppet або Cfengine або Chef є правильним рішенням для вашої проблеми. Звичайно, для написання сценарію ляльок, який просто працює, буде потрібен певний час та підхід проб і помилок. Ці інструменти широко використовуються для автоматизації складних установок на хмарі та спростили життя адміністраторів, як ми. :)


Дякую за підказку! Як я вже запитував MaxMackie раніше, чи Puppet надає якісь "централізовані розбірливі розвідки" щодо правил переписування при переключенні між основними версіями мого дистрибутива? Наприклад, якщо я знаю, що $ DISTRO перемикається з GNOME 2 на 3, чи буде напівавтоматичний шлях міграції?
jstarek

Ви можете написати файл для, скажімо, конфігурації Gnome3 і включити його в конфігурацію хостів, на яких потрібно встановити Gnome3. але це також залежить від того, як ви створите конфігурацію ляльок. Якщо ви будете дотримуватися модульного підходу, тоді буде простіше. Сама лялька не зможе визначити Gnome3 або 2. (сподіваюся, я правильно поставив ваше запитання)
Abhishek

3

По-перше, не сподівайтеся, що це буде легко працювати з декількома дистрибутивами.

Я не запускав великих розгортань на робочому столі. Для мене найкращим компромісом було використання завантажувальної мережі / tftp локальної мережі для завантаження системи, а потім запуску встановлення через NFS. Більшість дистрибутивів Linux запитує вас про всі початкові конфігурації передньої панелі - тоді ви можете залишити програму запуску, скажімо, 40 хвилин без нагляду (ніяких запитів "Ви дійсно хочете запустити цю програму?" У цей момент я доглядав за машинами Redhat і Suse - і мав RPM, підготовлений з усіма призначеними для користувача налаштуваннями, які я встановив після завершення стандартної установки. Однак цілком можливо автоматизувати все це на різноманітних дистрибутивах.

Я не є великим прихильником дистрибуції Ubuntu з різних причин, але Lanscape Canonical є дуже вражаючим інструментом. І якщо ви збираєтеся робити багато масштабних установок Ubuntu / керувати кількома настільними комп'ютерами Ubuntu, це, безумовно, варто детальніше ознайомитись.


Переглядаючи сайт Landscape, у мене складається враження, що він не обробляє записи конфігураційних файлів - тож я б створив локальні пакети, які вносять необхідні зміни під час встановлення?
jstarek

1

Я багато працював із програмним забезпеченням CFEngine . Це менеджер конфігурації з відкритим кодом, який читає встановлені вами "правила" і гарантує, що кожна машина, до якої прив'язана, і дотримується цих правил. Це повністю відкритий код і настільки корисна наша компанія вирішила використовувати підтримувану версію програмного забезпечення під назвою Nova.

Це широке уявлення про те, як це працює. Скажімо, у вашій керованій мережі є 4 комп’ютери. Всі вони повинні мати файл /etc/syslog.conf, що належить root, все ті ж (за словами майстра) та chmod 777. Ви створили б це правило у файлі конфігурації CFEngine. З вашого центрального комп'ютера у вас є "головний" /etc/syslog.confфайл. Кожен X час версія CFEngine на вашому комп’ютері проходитиме через мережу і запитує кожне поле про /etc/syslog.confфайл. Локальна копія CFEngine, що працює на кожному клієнті, запитає відповідний файл і повідомить про його вміст, дозволи тощо. Якщо вони НЕ РОЗПОВІДАЮТЬСЯ відповідності вашій копії, CFEngine відправить вашу копію клієнту та перевірить файли ще раз. Вони збігаються, і він перейде до вашого наступного правила.

Що стосується простоти, то синтаксис, який використовується у "правилах" CFEngine (які вони називають обіцянками), може зайняти трохи звикання, але вони цілком варті того, щоб навчитися (додає ще один чудовий навик вашому набору навичок).


Дякую за підказку, я погляну на CFEngine. Однак, з того, що я читав про це до цих пір, здається, що це не врятує мене від переписування правил при переході на нову основну версію мого дистрибутива, правда?
jstarek

1

Отже, як там немає центрального об'єкта конфігурації,

У Gnome є GConf, який може виконувати всі такі незначні завдання:

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 - це майже єдиний варіант довгострокової підтримки на робочому столі.

Розгортання декількох машин майже можливе за допомогою простого dd, розповсюдження настільних комп'ютерів повільно робить це менш привабливим маршрутом.

Також зараз розглянемо варіант - так званий жировий клієнт .


Я вже використовую товстих клієнтів, але це не полегшує конфігурацію само по собі - вони просто отримують інформацію про hededir та passwd з центрального сервера. Якщо GNOME не використовував GConf і не ставив важливі конфігураційні файли в / usr / share / gconf / defaults /, можна просто зберегти центральний / etc / десь на сервері і встановити його товсті клієнти, але ні, хлопці GNOME здається, знаю краще.
Зітхніть

@jstarek жирні клієнти гору /, GConf відміни жити в/etc/gconf/gconf.xml.*/
Стів-о
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.