Linux в корпоративной среде

Немного о Linux в корпоративной среде

Недавние эксперименты, и последовавшее обсуждение натолкнули меня на мысль попробовать Linux на своём рабочем месте, т.е. посмотреть на него глазами корпоративного пользователя, работавшего ранее с Windows или Mac OS.

Для начала, не самое главное для работы, но первое, что бросается в глаза. Загрузив любой линукс и полазив по разным меню и настройкам, мы неизбежно сталкиваемся с небрежностью в оформлении интерфейса. В коммерческих ОС встретить в нём кнопки, на которых не помещается надпись, практически нереально. В Linux это иногда встречается. Я понимаю, что это огрехи перевода интерфейса на разные языки, но всё же кто-то должен проверять и модерировать эти переводы и элементы интерфейса.
Второе — это шрифты. MS и Apple как-то умудряются так подобрать системные шрифты, что они приятны для восприятия. В Linux шрифты какие-то не такие. В чём тут конкретно дело, сказать не могу, но чисто субъективно и у меня, и у многих, кого я спрашивал есть какое-то ощущение дискомфорта при восприятии шрифтов графических интерфейсов Linux.

Почему это вообще имеет значение для корпоративной работы? А потому, что пользователю на его рабочем месте должно быть максимально комфортно, и если его что-то раздражает, то и работа будет идти не с максимальной эффективностью.

А теперь основное. Для того, чтобы ОС нормально работала в корпоративной среде, она должна эту среду уметь создавать или легко интегрироваться в чужую среду. Со своей средой всё плохо. Бесплатные линуксы не имеют ничего даже отдалённо напоминающего службу каталогов. Ну, т.е. я, конечно, слышал о том, что можно собрать нечто на основе OpenLDAP, но ни разу не видел работающего решения. И уж тем более, такого решения нет прямо «из коробки».
А самой распространённой корпоративной средой на данный момент является Windows domain. Вот примерно, что это такое и зачем это нужно:

Домен Windows — это способ организации компьютерной сети, в которой все аккаунты пользователей, компьютеры, принтеры и прочие объекты безопасности хранятся в единой базе банных, находящейся на одном или более центральных серверов, именуемых контроллерами домена. Аутентификация пользователей проходит через контроллеры домена. Каждый пользователь, использующий компьютер внутри домена Windows получает уникальный аккаунт, который даёт ему доступ к ресурсам внутри этого домена. Также пользователи и компьютеры централизовано управляются едиными групповыми политиками, имеют единые параметры безопасности, имеют возможность использовать перемещаемые профили, чтобы работать со своим рабочим окружением с любого компьютера домена и т.п. Есть также возможность централизованной установки, настройки и контроля прикладного ПО.

Всё это значительно упрощает администрирование системы. Каждому, кто хоть раз администрировал корпоративную локальную сеть, состоящую из более чем 10 компьютеров, очевидно, что без всего этого трудозатраты и сложность администрирования возрастают в разы.

Так вот. Ни о каких групповых политиках, перемещаемых профилях, управлении ПО и т.п. удобствах стандартными средствами, на бесплатных линуксах можно даже и не мечтать. Можно что-то нагородить скриптами, но это уже совсем другая история. (Есть также какое-то коммерческое решение для реализации групповых политик на линуксовых рабочих станциях, но оно стоит денег). Остаётся хотя бы воспользоваться централизованным хранением аккаунтов и доступом к сетевым ресурсам. А для этого нужно подключить компьютер к домену Windows. (Скажу сразу, что на Windows и Mac OS эта процедура занимает не больше минуты). Как это происходит на разных линуксах, я и решил проверить.

Для экспериментов я выбрал следующие системы: Debian-8.8.0, CentOS-7 и OpenSUSE-Leap-42.2. Ну, и до кучи, решил попробовать коммерческий Red Hat Enterprise Linux Workstation 7.3. Вдруг там всё будет хорошо.

Вот результаты тестов:

1. Debian: специального средства для подключения к домену Windows нет. Всё нужно делать вручную, устанавливая необходимые пакеты, правя конфигурационные файлы и работая из консоли. Если всё сделать правильно и не словить какой-нибудь глюк, то работает без нареканий. (Аналогичная ситуация, кстати, в Linux Mint и Ubuntu последних версий). Что характерно, в прошлых версиях Debian-подобных систем в репозитории был такой пакет Likewise Open, как раз для подключения к домену Windows, и он даже иногда работал, но сейчас его нет и нельзя поставить.

2. CentOS: подключение к домену Windows есть, но какое-то неполноценное. В систему можно вручную добавить доменного пользователя, после чего под ним можно войти в систему и получать доступ к доменным ресурсам. Каждого нового доменного пользователя нужно сначала вручную добавить.

3. OpenSUSE: единственная система, где прямо из коробки есть средство подключения к домену Windows, и оно даже работает. Введя Suse в домен, потом можно входить в систему под любым доменным пользователем, при этом автоматически создаются домашние каталоги и появляется доступ к ресурсам файловых серверов. Узрев такое чудо, я решил немного расширить эксперимент и подключиться к принтеру на виндовом принт-сервере. Тут меня ждал облом. Система сама на принт-сервере принтеров не видит, хотя компьютер и подключен к домену, и их имена нужно вводить вручную. Драйверы есть не все. Где брать недостающие, непонятно. Но даже там, где есть драйвер и удалось безошибочно ввести имя очереди, печать у меня почему-то не заработала — всё время вылезали какие-то ошибки аутентификации. Поковырявшись минут 15, я сдался и закончил эксперимент. Наверняка, если почитать форумы, мануалы и советы всевозможных гуру, проблему решить бы удалось, но задача была проверить, насколько это просто. Выяснилось, что не просто. (На других дистрибутивах не проверял, но подозреваю, что ситуация аналогичная, т.к. система печати на всех линуксах одинаковая — CUPS).

(Справедливости ради, хочу заметить, что на Mac OS подключение к виндовому принтеру делается тоже не двумя нажатиями кнопок, но там это по крайней мере делается относительно быстро и сразу работает).

4. RHEL: ситуация полностью аналогична CentOS, чего и следовало ожидать, т.к. системы по исходникам идентичны. Была надежда, что в коммерческом продукте будет какой-то дополнительный компонент, но его там не оказалось.

Что в итоге? А вот что. Чтобы пользователям работать на бесплатных линкусах в корпоративной среде, нужно либо эту среду с нуля создавать прямо средствами Linux (с серьёзными трудозатратами, изменением всего принципа работы и неясным результатом), либо интегрировать рабочие станции в домен Windows, поимев при этом нешуточные танцы с бубном. И это только на этапе первоначальной настройки. Что там вылезет дальше в процессе эксплуатации, предположить не берусь. Если не сделать ни то, ни другое, затраты на администрирование возрастут в разы. Грамотные администраторы Linux и так стоят дороже виндовых, а тут ещё и придётся расширять штат. При всём при этом, в конторе, где сидит 5 человек, Linux вполне работоспособное решение.

В своих экспериментах, я намеренно абстрагировался от проблемы прикладного ПО, которое часто под Linux либо отсутствует, либо работает ~~через задницу~~ не так, как хотелось бы. Но это уже совсем другая история.

В общем, вывод лично мой не утешительный. Для коммерческой эксплуатации, Linux пока подходит плохо. Естественно, если речь не идёт о серверах, где он заслуженно занимает своё подчас ведущее место. Если же доводить Linux до ума в качестве корпоративной ОС, опять встаёт вопрос заказчика. Коммерсанты за это платить не будут. Зачем им это нужно, если уже есть платная винда, которая прекрасно работает? Остаётся государство, для которого сидеть на чужой коммерческой ОС накладно, как с экономической точки зрения, так и с точки зрения безопасности. А значит нужно ставить задачу и разрабатывать такую систему своими силами на средства государства. Причём разрабатывать сразу всю рабочую среду, а не просто отдельную ОС для разных нужд. Иного пути нет.

Источник

Развертывание различных дистрибутивов Linux в корпоративной среде

Содержание статьи

Способов развертывания Linux-систем существует достаточно много — начиная от простого клонирования и заканчивая установкой по сети. Для каждого семейства дистрибутивов также существуют свои способы, которые заметно облегчают установку на множество машин.

Введение

Как правило, на один-два компьютера Linux устанавливают вручную. Однако для большего числа компьютеров это неэффективно — слишком уж много времени уходит на развертывание и настройку необходимых параметров. Есть несколько способов, которые помогут эту процедуру упростить.

Клонирование итоговой установки одного компьютера на несколько дисков с помощью dd/Clonezilla. Плюс у этого метода очевиден — он универсален и не надо заморачиваться с изучением дистроспецифичных методов развертывания. Минусы, тем не менее, тоже имеют место. Во-первых, конфигурация железа должна совпадать. Во-вторых, при клонировании мы получаем абсолютно точную копию системы — копируются в том числе пароли/SSH-ключи. В случае компрометации одной системы будут скомпрометированы и все остальные.
Клонирование по сети. Преимущество перед первым методом — не надо отключать и подключать жесткие диски к клонируемой системе или бегать с флешкой, содержащей клонируемый образ, что для большого числа компьютеров довольно монотонно и смысла не имеет. Минус же, помимо тех, что у предыдущего способа, — сеть может отвалиться, что приведет к простою в развертывании. Впрочем, время простоя всяко меньше, чем если бы устанавливали вручную.
Наконец, дистроспецифичные методы. Плюсы — возможно установить по сети, в том числе используя PXE, возможность гибкой конфигурации (в случае разных классов компьютеров, например компы для офиса, компы разработчиков, сервер) — для этого необходимо указать другой файл конфигурации, различие данных, которые клонироваться не должны. Минусы — для каждого дистрибутива способ развертывания свой и синтаксис конфигурационных файлов, соответственно, разный.

В этой статье мы рассмотрим третий метод для RHEL/Fedora и Debian/Ubuntu — эти дистрибутивы, в общем-то, самые распространенные в корпоративной среде, и в них предусмотрены средства автоматизации развертывания.

Развертывание Fedora/RHEL с помощью Kickstart

Средство автоматической установки Kickstart в Red Hat появилось очень давно — во всяком случае, в Red Hat Linux 6.2 (не Enterprise!) оно уже присутствовало. Существует три способа создания конфигурационного файла, и их можно комбинировать:

Использовать готовый файл, который создается по завершении каждой установки дистрибутивов, основанных на RHEL/Debian.
Использовать графический инструмент system-config-kickstart.
Наконец, написать ручками.

Самым правильным будет комбинирование всех трех способов, но далее я опишу только структуру и конфиг — не весь, конечно, а только наиболее важные его части.

Структура конфигурационного файла kickstart и пример

Условно можно выделить следующие части конфигурационного файла kickstart:

тип инсталляции: установка или обновление;
выбор языка и раскладки клавиатуры;
аутентификация;
конфигурация загрузчика;
разбиение на разделы;
наборы пакетов;
постинсталляционные действия.

Вот и пример конфига kickstart (anaconda-ks.cfg) с комментариями:

Графическая утилита для создания файлов kickstart

Хакер #178. Mesh-сети или строим свой интернет

Еще раз хочу отметить, что это всего лишь простейший пример, — в файлах kickstart можно использовать целые сценарии, которые будут выполняться перед установкой и после нее — %pre и %post. В %pre-скрипте, к примеру, можно разметить диск более гибко, чем это позволяют делать штатные методы kickstart, а в %post — совершить некоторые действия по конфигурированию.

Создание хешей паролей

Для хеширования паролей можно использовать несколько методов. Наиболее универсальный из них — применение следующего скрипта-однострочника:

Вместо password необходимо задать свой пароль, а вместо salt — случайный набор символов. Результатом будет хеш по алгоритму SHA-512, о чем говорит цифра 6 между знаками доллара (если хочется использовать SHA-256 — используй 5, если MD5 — 1).

Сложная разбивка дисков в kickstart

Для разбиения на разделы используются следующие команды kickstart: autopart, part, raid, volgroup и logvol. Если требуется автоматическая разметка, воспользуйся autopart — к тому же ты можешь выправить размеры разделов ручками с помощью команды part. Однако я бы предпочел полностью ручное разбиение. Порядок создания разделов LVM такой: сперва создаем раздел /boot (обязательно вне LVM), затем с помощью part физический том, потом уже поверх него группу томов, для чего применяем volgroup, и, наконец, используем logvol для создания логических томов с файловыми системами. Программный RAID-массив создается примерно по такой же схеме.

Поскольку разбиение дисков довольно сложная тема, имеет смысл привести фрагмент файла kickstart, где описан вариант создания массива RAID5 с одним запасным устройством, поверх которого создан LVM:

Итоговый конфиг ks.cfg

Запуск автоматической установки

Для того чтобы передать установщику, что процедура установки должна производиться с помощью kickstart, нужно указать местонахождение файла kickstart. Для этого используется опция ks= , передаваемая при загрузке с установочного носителя. Варианты местоположения могут быть следующими:

Какой-либо накопитель. Указывается так: hd: :/ks.cfg . Например, ks=hd:sda1:/ks.cfg . Также допустимо размещение на CD/DVD ks=cdrom:/ks.cfg , что, впрочем, имеет смысл только в случае самосборного образа.
NFS. В данном случае указывается через nfs: :/ .
HTTP/HTTPS. ks=http://192.168.0.1/ks.cfg .

Инфраструктура для развертывания виртуальных машин

Kickstart можно использовать и для развертывания ВМ. Далее я опишу их развертывание на примере VirtualBox и Scientific Linux. Создаем VM из командной строки:

512 Мб — минимальный объем памяти, необходимый для установки Scientific Linux:

Изменяем тип сетевого адаптера — тот адаптер, который стоит по умолчанию, не поддерживает загрузку по сети:

Установим порядок загрузки:

Не станем рассматривать процесс конфигурирования TFTP. Конфиг pxelinux.cfg/default будет выглядеть следующим образом:

Изменения в файле ks-vm.cfg минимальны:

Установка пакета debconf-utils для получения файла ответов на свежеустановленной системе

Preseed в Ubuntu

В системах на основе Debian есть свое средство автоматизации установки под названием preseed. Существует три способа загрузки файла с заданными параметрами установки:

файл в initrd (наиболее сложный способ);
файл на самосборном CD или флешке;
по сети.

В последнем случае необходимо указать как файл, так и его MD5-сумму. Опишем кратко, как грузить файл по сети, а затем создадим самосборный CD со своим файлом preseed. Для загрузки файла по сети в параметрах загрузчика необходимо указать параметр preseed/url= , который можно сократить до url= . Файл рекомендую размещать на внутреннем веб-сервере. Конечный набор параметров будет выглядеть примерно так:

А вот для загрузки файла preseed с локального установочного носителя необходимо, во-первых, чтобы он там присутствовал. Во-вторых, нужно опять же указать путь к файлу. И если второе проще простого — для этого используем опцию file=/cdrom/seed/oem.seed в случае установки с CD или file=/media-hd/preseed.cfg в случае установки с флеш-накопителя, — то первое требует более подробного описания. Расскажу, как подготовить ISO-образ с файлом автоматической установки.

Для того чтобы это сделать, нужно перепаковать уже готовый ISO-образ.

Ну а теперь самое время перейти к описанию файла preseed.cfg .

preseed.cfg — структура и пример

Технология preseed основана на debconf — то есть фактически можно управлять не только процессом установки, но и некоторыми другими вещами. Каждая инструкция preseed вмещается, как правило, в одну строку и состоит обычно из четырех частей, разделенных пробелами: владельца параметра, его имени, типа параметра и его значения. В большинстве случаев в первой части будет стоять d-i, то есть debian installer. А вот вторая часть, собственно, и является, в терминологии debconf, «вопросом», на который в четвертой части задается ответ. Третья же часть инструкции указывает тип вопроса/ответа:

string — самый распространенный тип вопроса; строка, содержащая (относительно) произвольные данные;
boolean — ответ может быть либо true, либо false;
select и multiselect — поскольку вопросы фактически те же самые, что задает программа установки, то среди них могут быть вопросы на выбор одного или нескольких вариантов. Ответ в случае multiselect разделяется запятой и пробелом;
password — используется для паролей;
note — предупреждение пользователя. Установщик иногда выводит информационные сообщения данного типа. В общем-то, это некритичные предупреждения, но если их проигнорировать в файле ответов, то на них придется отвечать ручками. В данном типе параметра ответа не предусмотрено.

Необходимо учесть также, что стандартный live-дистрибутив для создания своего образа не подходит, поскольку в нем запускается графический установщик ubiquity, а нам необходим Debian Installer. Для этой цели необходимо использовать ISO-образ с постфиксом alternate. Я использовал Xubuntu 12.04.3.

Переупаковываем содержимое ISO-образа

Далее будет приведен урезанный пример файла preseed.cfg с комментариями (файл должен быть в кодировке UTF-8):

Для проверки соответствия формату можно использовать команду

Чтобы установка была полностью автоматической, необходимо также задать некоторые параметры загрузки — поскольку не все параметры debconf могут быть прочтены установщиком из preseed-файла на ранних стадиях загрузки. Параметры могут дублировать аналогичные строки в файле preseed. Для этого необходимо в распакованном ISO-образе отредактировать файл isolinux/txt.cfg , добавив в него новый пункт меню. У меня получилось примерно следующее:

В случае если тебе нужна полностью автоматическая загрузка, измени default install на default oem-install.

Запаковываем образ и, по необходимости записав его на диск, загружаемся с него.

Конфиг isolinux для preseed-установки Ubuntu

Обновление Debian до новой версии с помощью preseed

Существует возможность обновить свежеустановленный дистрибутив со старой ветки до новой, используя firstboot-скрипт. Для этого необходимо иметь, во-первых, в локальной сети веб-сервер, с которого скрипты будут загружаться, а во-вторых, сами скрипты и немного подправленный файл preseed. В последнем необходима примерно такая строка:

Скрипт же postinstall содержит следующее:

А вот, собственно, и сам скрипт firstboot — в него можно записать что угодно, но ниже будет рассмотрен только скрипт обновления до Wheezy.

Preseed и виртуальные машины

Можно установить Debian с помощью virt-install, при этом полностью автоматически:

Данная команда, хоть и выглядит устрашающе, делает следующее: грузит инсталлятор, инжектит файл preseed.cfg (он должен называться именно так) в initrd и передает аргумент auto инсталлятору. Остальные опции в описании не нуждаются.

К слову, можно легко клонировать уже существующую ВМ KVM, используя следующую команду:

Она создает точный клон (за исключением MAC-адреса) машины vm1, именует ее vm2 и копирует образ диска. Замечу, что, во-первых, гостевая система должна быть остановлена, а во-вторых (и это крайне важно!), на гостевой системе нужно перегенерировать SSH-ключи.

Развертывание SUSE Linux Enterprise

Как корпоративный дистрибутив, SUSE также поддерживает автоматическое развертывание. Кратко опишу процесс.

В самом простом случае нужно создать профиль autoyast и при загрузке с помощью PXE указать в файле MARKDOWN_HASHf16a93e4b496631740212f97e1926536MARKDOWN_HASH примерно следующее:

В более сложных случаях, например для развертывания в гетерогенной сети, нужно создать файл правил MARKDOWN_HASHdf8349fb8855426b967bf1c00a5dbf80MARKDOWN_HASH с описанием условий выбора профиля. Файл этот позволяет очень гибко конфигурировать те или иные условия, но именно эта гибкость и делает развертывание SUSE достаточно сложным.

UDPCast — рассылаем файлы по сети

Утилита UDPCast предназначена для одновременной рассылки файлов в локальной сети, для чего используется multicast-рассылка. Эта утилита может быть использована для клонирования систем. Вкратце опишу основные шаги для клонирования:

На один компьютер устанавливаем ОС, которая затем будет клонирована.
Подготавливаем флешку с UDPCast.
Все компьютеры — и клонируемый, и чистые — подключаем к сети. Рекомендуется использовать DHCP.
Загружаем клонируемый компьютер с флешки. При этом выбираем клонируемое устройство, а UDPCast переводим в режим передатчика (sender).
С этой же флешки загружаются все остальные машины, но вместо режима передатчика нужно выбрать режим приемника (receiver) — при этом на экране машины-передатчика видно, как к ней подключаются приемники.
После загрузки всех приемников для запуска процесса клонирования нужно нажать пробел на передатчике.

Заключение

В статье были рассмотрены два средства развертывания дистрибутивов Linux. Оба этих инструмента позволяют гибко настраивать итоговую систему, оба практически полностью автоматизируют процесс. Выбор за тобой.