Каковы ваши лучшие практики и планы на будущее для развертывания 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

Я полагаю, что создание CI является обычной задачей для администраторов организаций. Итак, почему же нет централизованного конфигурационного устройства, возможно, даже кросс-рабочего стола? Необходимость установить два (одинаковых!) Недокументированных значения в двух разных конфигурационных файлах кажется мне странным.

Вопросов

В организационной среде, как вы обрабатываете централизованную унифицированную конфигурацию для нескольких клиентов?

Могут ли такие системы, как FAI Debian, предложить значительные преимущества (помимо необходимости менять CD) по сравнению с моим методом «сначала установи, потом запусти скрипт»?

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

Существует ли система * nix, которая решает проблемы такого типа? Например, я предполагаю, что существуют системы, которые запрашивают у вас некоторые изображения вашей организации (логотипы, фоновые изображения, наборы цветов и шрифтов и т. Д.) И применяют их к диспетчеру входа в систему, рабочим столам пользователей, веб-приложениям (!) И т. Д. на. Примечание. В нашем случае мне приходится работать с толстыми клиентами, поэтому решение для тонких клиентов не поможет.

Ответы:


3

Использование Puppet, CFEngine или Chef - правильное решение вашей проблемы. Конечно, на написание сценария Puppet, который просто работает, потребуется некоторое время и метод проб и ошибок. Эти инструменты широко используются для автоматизации сложных установок в облаке и упростили жизнь администраторам, таким как мы. :)


Спасибо за подсказку! Как я уже спрашивал у MaxMackie, предоставляет ли Puppet какой-либо «централизованный, краудсорсинговый интеллект» в отношении переписывания правил при переключении между основными версиями моего дистрибутива? Например, если я знаю, что $ DISTRO переключается с GNOME 2 на 3, будет ли полуавтоматический путь миграции?
Jstarek

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

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, дистрибутивы настольных компьютеров постепенно делают этот маршрут менее привлекательным.

Также рассмотрим вариант теперь так называемого толстого клиента .


Я уже использую толстые клиенты, но это само по себе не упрощает настройку - они просто получают информацию homedir и passwd с центрального сервера. Если GNOME не использовал GConf и не поместил важные файлы конфигурации в / usr / share / gconf / defaults /, можно просто сохранить центральный файл / etc / где-нибудь на сервере и заставить его смонтировать толстые клиенты, но нет, ребята из GNOME кажется, знает лучше. Вздох ...
Jstarek

@jstarek толстые клиенты монтируются /, GConf переопределяет жизнь/etc/gconf/gconf.xml.*/
Steve-o
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.