Настройка с использованием Центра управления

В Альт-Линукс (то есть и в ПСПО) конфигуратор по имени Alterator используется как при установке системы, так и при пост-установочной настройке, что сливает задачи написания конфигуратора и инсталлятора в одну.

Alterator, ввиду модульности, един в лице Qt-морды и Web-морды. Иллюстрации --- от Qt-морды.

Первый пункт --- скорее информация для администратора.

../01_distro_info.png

Следующий пункт --- свободная лицензия (специально написанная). Это проверенная юристами лицензия, которая улаживает и в том числе проблемы со множественными лицензиями внутри дистрибутива (например, лицензии на некоторые несвободные драйверы). Эта бумажка замечательна с точки зрения указания прав, передаваемых пользователям. Снимает очень много юридических вопросов.

../02_license.png

Системные объекты (система control, которая в /etc/control.d/). Этот пункт конфигуратора --- практически морда-редактор к данной системе, специфической в альте и OWL. Ткнём, например, в сhange.

../03_sysobjects_chage.png

В каждом пункте есть переключатель на несколько положений (которые описываются в соответствующем скрипте в /etc/control.d/facilities), например, им пользоваться могут только члены cdwriter или только root, аналогично cups может быть сервером или локальным. Если переключиться в консоль и сказать control, то можно увидеть то же самое.

[root@demo ~]# control
at              public          (public restricted atdaemon)
cdrdao          public          (public restricted)
cdrecord-classic public          (public restricted)
chage           restricted      (public restricted)
chfn            restricted      (public restricted)
chsh            restricted      (public restricted)
cifsmount       wheelonly       (public wheelonly restricted)
cifsumount      wheelonly       (public wheelonly restricted)
consolehelper   public          (public wheelonly restricted)
crontab         public          (public restricted)
cups            server          (server local)
<...>

Как это выглядит изнутри: предположим, как в случае купса, есть два способа функционирования сервера. Предположим, вы знаете, какие действия произвести над купсом (раскомментировать или закомментировать некую строку в конфиге), чтобы привести в одно состояние или другое. Это можно увидеть в /etc/control.d/facilities/cups.

. /etc/control.d/functions

CONFIG=/etc/cups/cupsd.conf

new_subst server \
        '^Listen[[:space:]]+localhost:631[[:space:]]*$' \
        's/^#\(Listen[[:space:]]\+localhost:631\)[[:space:]]*$/\1/g'
new_subst local \
        '^#Listen[[:space:]]+localhost:631[[:space:]]*$' \
        's/^\(Listen[[:space:]]\+localhost:631\)[[:space:]]*$/#\1/g'

new_summary "Common Unix Printing System"
new_help local "Only local utilities can work with cups"
new_help server "External IPP interface are available for user"


control_subst "$CONFIG" "$*"

Как можно реализовать подобного рода функциональность: написать файл readme, в котором доходчиво объяснено, какие строки надо комментировать. Второй вариант: делаете две группы конфигов, в одном одни настройки, в другом другие. Третий способ --- пишете некий скрипт, который будет производить изменения. Чем последний способ плох --- плох тем, что такую строчку можно и не найти (допустим, автоматически созданный конфиг, который рассчитывает найти скрипт, был исправлен руками). Как это исправить --- писать вокруг функции, есть там такое, нет там такого. Ещё один способ --- можете изменить файл, подложив конфиг. Заархивировать его. Подложить дифф. В случае с разными группами, которые могут запускать программы, мы всего лишь меняем права файла. Это уже невозможно засунуть в дифф, более того, нельзя сохранить в виде какого-то файла. Разве что шеллскрипт написать, вот это оно и есть. Система control, по сути --- api на шелле, которая реализует различные функции такого рода, как-то: поиск с заменой в конфигах, изменение прав на файлы, исполнение произвольных шелл-функций, экспорт хэлпов об изменяемых опциях наверх по уровням конфигуратора. Это же решает вопрос свёртки множественных действи в атомарное. Этот api не полный, например, нельзя задать множественные изменения в файле. Но, тем не менее, довольно много случаев оно покрывает. После создания альтератора выяснилось, что это имеет довольно приличный вид даже на верхнем уровне. Тем не менее, штука довольно удобная, и позволяет администратору выключать по умолчанию все службы. Мы вполне себе можем позволить закручивать ручки по безопасности, поскольку откручиваются они достаточно просто.

В системе control множество объектов. Их можно посмотреть, они достаточно нормально описаны. Из полезных:

Настройка загрузчика.

../04_bootloader.png

Что это такое. В лекциях несколько раз говорилось про последовательность загрузки. Речь идёт о установке начального загрузчика, который LI+LO. Загрузчик этот по умолчанию устанавливается в MBR с тем, чтобы загрузчик lilo умел управлять загрузкой разных ОС сам. Есть там некая хитрость при подготовке системы с двойной загрузкой с Windows. Когда вы это делаете, вам нужно сжать раздел с виндовсом. Если вы это делаете с помощью программы проприетарной, то с большой вероятностью всё будет нормально. Если же вы делаете это программой свободной, то возможно, что последовательность загрузки испортится, потому что карта загрузки ntldr поедет. Лечится это просто: перед установкой виндовса нужно создать диск с recovery console и сказать fixboot. Зачем бывает нужно установить загрузчик в раздел диска --- если у вас уже есть многосистемная машина и вы можете настроить загрузку ещё одной ОС, то достаточно поставить lilo в другой раздел, например, в /. После чего надо настроить свой загрузчик, чтобы он загружал ещё и линукс.

Экспертный конфигуратор --- конфигуратор lilo. Чем он плох --- надо знать конфиг lilo, чтобы её пользоваться.

../04_bootloader_expert_1.png

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

../05_datetime.png

Часовой пояс. Та же картина, кроме кнопочки "хранить время bios по гринвичу", то есть внутренние часы самого компьютера (которые хранит батарейка на материнской плате) устанавливают по гринвичу, потому что так устроены линух-системы. В чём преимущество --- у вас, когда смена зимнего и летнего времени, единственное, что надо сделать --- прибавлять не 3 часа, а 4 (внутри ОС). В отличие от всяких операционных систем, которые считают, что в биосе локальное время.

../06_timezone.png

Системный администратор. Предлагается только задать пароль, можно его сгенерировать. Такой пароль считается надёжным, поскольку его проблемно подобрать, кроме того между ними стоят произвольные символы.

../07_rootpassword.png

Учётные записи. Очень долго пытались правильно перевести login name --- в итоге "системное имя", правда, непонятно, как бы сделать очевидным вписывание полного имени. Общий совет пользоваться этим окном, а не adduser или useradd по одной причине --- пользователь добавляется ещё в кучу разных групп.

../08_accounts_user.png


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

20

1

1

1

1

MaximByshevskiKonopko, VladimirLysikov