Развертывание компьютерного класса
Постановка проблемы
Развертывание компьютерного класса требует решения следующих задач:
Организация автоматической сетевой установки. Современный компьютерный класс обычно состоит из десяти и более компьютеров, объединенных в локальную сеть. Выполнение ручной установки операционной системы на каждом из этих компьютеров может занять значительное время, поэтому разумно, с одной стороны, использовать механизм установки по сети и, с другой стороны, минимизировать количество производящихся вручную операций.
Возможность оперативной перенастройки. Это подразумевает изменение конфигурации системы на всех машинах, в том числе установку и удаление программ, модификацию системных конфигурационных файлов и пр. Количество производящихся вручную операций, необходимых в случае таких изменений, также должно быть минимизировано. Тем не менее, должна быть сохранена возможность индивидуальной настройки той или иной машины.
Обеспечение концепции "мобильного рабочего места". Существенным требованием, предъявляемым к способу организации класса, является организация персонифицированного пользовательского окружения. Каждый пользователь, обладающий учетной записью в компьютерном классе, должен иметь возможность сесть за любое рабочее место и, зарегистрировавшись в системе, получить доступ к своему собственному окружению. В это окружение входит установленный администратором либо оператором набор ПО и пользовательский домашний каталог с документами и персональными настройками.
При решении этих задач считается, что аппаратное обеспечение эксплуатируемых компьютеров обладает достаточными для функционирования ОС Linux характеристиками, однако не позволяет организовать выделенный сервер для обеспечения работы "тонких клиентов". Кроме того, предполагается, что однажды развернутый компьютерный класс не должен требовать внимания администратора: все изменения в уже установленной системе должны выполняться оператором (учителем, преподавателем) и потому не могут требовать специальных знаний.
Краткое описание решения
Предлагаемое решение организует работу класса следующим образом. Из всех компьютеров класса выбирается особый (операторский), называемый в дальнейшем сервером. При развертывании класса на этот сервер устанавливается один из дистрибутивов ПСПО, после чего этот сервер настраивается вручную. Он будет обеспечивать возможность автоматической сетевой установки для остальных компьютеров класса (решение задачи 1) и предоставлять доступ по сети к данным, необходимым для решения задач 2 и 3. После настройки сервера оператору достаточно включить на каждом из остальных компьютеров режим загрузки по сети, загрузиться "с сервера" и дождаться окончания автоматической установки.
Решение задачи 2 и, частично, 3 обеспечивается специально разработанной для этих целей утилитой synchrone. Программная конфигурация "обычного" (клиентского) компьютера в классе (называемая в дальнейшем профилем) представляет собой, с точки зрения этой утилиты, дерево каталогов, растущее из корня файловой системы / (с некоторыми исключениями). Утилита synchrone обеспечивает синхронизацию дерева каталогов каждого из клиентских компьютеров с расположенной в специальном хранилище на сервере копией нужного профиля.
При загрузке клиентского компьютера утилита synchrone запускается автоматически и выполняет необходимые для синхронизации с сервером действия. Пользовательские домашние каталоги и специфичные для локального компьютера файлы в профиль не включаются, поэтому любые изменения профиля могут происходить только при выполнении операторских и, реже, административных задач.
Настройка клиентских компьютеров осуществляется оператором по следующей схеме. Оператор садится за любое рабочее место и, зарегистрировавшись в системе, выполняет необходимые модификации: установку и удаление ПО, изменение конфигурационных файлов и пр. (для выполнения этих действий, вообще говоря, требуются права суперпользователя). Закончив действия по настройке, оператор (с помощью утилиты synchrone) отправляет актуальную копию профиля на сервер (для этого требуется знание специального пароля) и, если отправка завершается успешно, "подписывает" эту копию как актуальную. После этого для синхронизации остальных клиентских компьютеров с сервером их достаточно перезагрузить (или воспользоваться утилитой synchrone вручную).
Для решения задачи 3 доступ к домашним каталогам пользователей обеспечивается по сети: используется сетевая файловая система NFS. Такой подход дает каждому пользователю возможность работать с расположенными в его домашнем каталоге документами и конфигурационными файлами с использованием любого из рабочих мест в классе. С учетом того, что программная конфигурация клиентских компьютеров поддерживается идентичной, можно говорить о реализации с помощью описанной схемы концепции "мобильного рабочего места".
Развертывание сервера
Общая установка и настройка
Установка системы на серверную машину производится любым из доступных способов, например с CD- или DVD-носителя. Опуская специфичные для каждого конкретного класса (и каждого конкретного дистрибутива) подробности этого процесса, обратим внимание на некоторые детали.
Во-первых, при разметке диска рекомендуется учитывать следующие факторы:
Поскольку на сервере будут храниться данные одного или, что более вероятно, нескольких профилей (необходимость хранить более одного профиля возникнает как при организации разнородного класса, так и при конфигурировании "на лету"), а также домашние каталоги всех пользователей, разумно выделить достаточно большой объем дискового пространства под раздел с /srv, в подкаталогах которого все эти данные и будут храниться. Отметим, что для повышения уровня безопасности сервера монтирование этого раздела разумно осуществлять с опциями nosuid и nodev.
С учетом того, что процесс эксплуатации класса предполагает активное использование сетевых служб (в том числе необходимых для синхронизации), разумно выделить значительный объем под раздел подкачки (swap).
В случае, если предполагается активное использования сервера как операторского рабочего места, имеет смысл отвести достаточный объем дискового пространства под корневой раздел / (или, в случае более тонкой настройки, под раздел /usr и, возможно, /var).
Приведем простейшую схему разбиения жесткого диска объемом в 28 гигабайт (примерно 30 миллиардов байт):
1 GB swap 10 GB / 17 GB /srv (nosuid,nodev)
Во-вторых, при настройке сети рекомендуется привязать имена сетевых интерфейсов в системе к MAC-адресам физических устройств. В дистрибутивах ПСПО это можно осуществить либо выбором соответствующей опции при установке, либо с помощью ручного редактирования конфигурационного файла /etc/iftab (за справкой отошлем к странице руководства iftab(5)). Ручная настройка в простейшем случае может свестись к выполнению следующей команды:
# ip -o link show | sed -nr '/link\/ether/s+^[[:digit:]]*: ([[:alnum:]]*):.*link/ether ([[:alnum:]:]*).*$+\1\tmac \2+p' > /etc/iftab
В большинстве случаев сервер разумно использовать в качестве маршрутизатора, если для его клиентов планируется доступ во внешнюю сеть.
В простейшем случае достаточно присвоить параметру net.ipv4.ip_forward в файле /etc/net/sysctl.conf значение 1. Тогда при настроенной маршрутизации на сервере подключенные к нему клиенты получат через него доступ во внешнюю сеть. При значении 0 сервер перестаёт работать как маршрутизатор и у клиентов остаётся только локальная сеть.
Установка и конфигурирование сетевых служб
Предварительные действия
Будем теперь считать, что первичная настройка системы, включая конфигурирование сети, выполнена. Подключим необходимые хранилища (рекомендуется использование Sisyphus school branch) и обновим локальные индексы диспетчера пакетов:
# apt-get update
Установим необходимые для функционирования класса сетевые службы:
# apt-get install rsync-server nfs-server dhcp-server tftp-server apt-utils pdnsd rdate
(Заметим, что rdate непосредственно использоваться не будет.)
Займемся теперь конфигурированием этих служб.
Службы, поддерживаемые метадемоном xinetd
Вначале откроем файл /etc/xinetd.conf и закомментируем строку с параметром only_from, поставив в ее начале символ решетки:
#only_from = 127.0.0.1
Сохраним изменения и отредактируем конфигурационный файл rsync-сервера --- /etc/rsyncd.conf. Впишем в его конец следующие строки:
uid = root
gid = root
[profiles]
path = /srv/profiles
[update-profiles]
path = /srv/profiles
read only = no
auth users = updater
list = no
secrets file = /etc/rsyncd.secretsКак видим, здесь мы ссылаемся на файл /etc/rsyncd.secrets, который должен содержать базу данных пользователей службы rsync. Создадим этот файл и впишем в него единственную строку:
updater:updpassword
Здесь updater --- имя пользователя, которому будет разрешено обновлять данные профилей в нашем классе. Его можно оставить без изменений, а можно задать и иным (но тогда нужно будет вносить изменения в инициальные настройки synchrone). Что же касается строки updpassword, то она задает пароль для этого пользователя --- этот пароль обязательно следует заменить на другой; лучше --- более сложный. Сохранив файл /etc/rsyncd.secrets, ограничим права доступа к нему:
# chmod 600 /etc/rsyncd.secrets
Теперь правом на чтение и изменение этого файла обладает лишь суперпользователь нашего сервера.
В основном конфигурационном файле службы rsync упоминался также каталог /srv/profiles --- это место, где будут храниться данные профилей. Создадим этот каталог уже сейчас:
# mkdir /srv/profiles
Помимо этих изменений, нам нужно внести изменения в конфигурационный файл метадемона xinetd, отвечающий за обслуживание rsync-сервера. Этот файл называется /etc/xinetd.d/rsync. Откроем его и отредактируем строку с параметром rlimit_as, отвечающую за накладываемые на rsync ограничения по объему адресного пространства. В нашем случае она должна выглядеть так:
rlimit_as = UNLIMITED
На этом настройку службы rsync можно считать завершенной. Задействуем ее по умолчанию:
# chkconfig rsync on
Нам также необходимо включить запуск при старте системы двух других служб, поддерживаемых метадемоном xinetd: это tftp и time-tcp.
# chkconfig tftp on # chkconfig time-tcp on
Чтобы эти службы (и, кроме них, rsync-сервер) запустились прямо сейчас, дадим следующую команду:
# for i in rsync tftp time-tcp; do service $i start; done
На всякий случай дадим команду для включения самого демона xinetd:
# service xinetd start
Служба DHCP
Для функционирования класса нам пригодится служба DHCP. Поскольку пакет dhcp-server был нами установлен, то для настройки осталось создать корректный конфигурационный файл /etc/dhcp/dhcpd.conf. Его содержимое должно выглядеть примерно так:
# See dhcpd.conf(5) for further configuration
ddns-update-style none;
subnet 192.168.201.0 netmask 255.255.255.0 {}
subnet 10.30.5.0 netmask 255.255.255.0 {
option routers 10.30.5.1;
option subnet-mask 255.255.255.0;
#option nis-domain "domain.org";
option domain-name "class305.mpgu.edu.ru";
option domain-name-servers 10.30.5.1;
range dynamic-bootp 10.30.5.101 10.30.5.199;
default-lease-time 21600;
max-lease-time 43200;
filename "pxelinux.0";
next-server 10.30.5.1;
}Обратим внимание на используемые IP-адреса. 10.30.5.1 следует заменить на внутренний IP-адрес нашего сервера (обратим внимание, что он встречается в тексте нашего файла трижды), 10.30.5.101 и 10.30.5.199 --- на границы диапазона выдаваемых клиентским компьютерам адресов. Строку subnet 10.30.5.0 netmask 255.255.255.0 следует привести в соответствие с используемыми в классе сетевыми адресами, а строку subnet 192.168.201.0 netmask 255.255.255.0 {} --- с "внешним" IP-адресом настраиваемого нами сервера (заметим, что для каждой непосредственно доступной нашему серверу сети в dhcpd.conf должна содержаться строка данного вида).
Сохранив конфигурационный файл на диск, включим запуск DHCP-сервера при старте системы:
# chkconfig dhcpd on
Для включения же его прямо сейчас воспользуемся другой командой:
# service dhcpd start
Служба доменных имен
Сконфигурируем установленный нами простейший сервер доменных имен --- pdnsd. Откроем его конфигурационный файл /etc/pdnsd.conf и внесем в него два изменения. Во-первых, закомментируем параметр server_ip в разделе global --- соответствующая строка должна выглядеть примерно так:
# server_ip="127.0.0.1";
Во-вторых, в первом из разделов server заменим в строке с параметром ip используемый по умолчанию IP-адрес одного из корневых серверов службы DNS на IP-адрес сервера DNS, предоставляемого нашим провайдером. Сохраним внесенные в файл изменения и организуем запуск демона pdnsd при старте системы:
# chkconfig pdnsd on
Перед включением pdnsd полезно сгенерировать разумный файл /etc/hosts. В простейшем случае это достигается двумя командами:
# echo "127.0.0.1 localhost.localdomain localhost" > /etc/hosts
# for i in `seq 254`; do echo "10.30.5.${i} host${i}.class305.mpgu.edu.ru host${i}"; done >> /etc/hostsСтроку 10.30.5. следует при этом заменить на используемый в нашем классе адрес сети без последнего байта, а строку class305.mpgu.edu.ru --- на имя внутреннего домена (оно может быть и фиктивным, таким как class15.school123.zhukovsky.moscow-region.ru). После этого можно заменить адрес используемого сервера DNS на 127.0.0.1 в файле /etc/resolv.conf (можно воспользоваться также "Центром управления системой" --- конфигуратором Alterator).
Чтобы запустить pdnsd, дадим следующую команду:
# service pdnsd start
Сетевая файловая система
Организуем теперь на нашем сервере раздачу посредством сетевой файловой системы NFS нужных для функционирования класса каталогов: клиентских /home (он будет соответствовать каталогу /srv/home на сервере) и каталога для сетевой загрузки (его мы поместим в /srv/boot). Вначале создадим их:
# mkdir /srv/home /srv/boot
Теперь составим корректный конфигурационный файл для службы NFS со списком раздаваемых каталогов. Он должен называться /etc/exports и содержать следующие строки (адрес 10.30.5.0/24 следует заменить на используемый в классе адрес сети)::
/srv/boot *(ro,no_subtree_check,no_root_squash) /srv/home 10.30.5.0/24(rw,no_subtree_check,no_root_squash)
Сохраним этот файл на диск и организуем службы NFS при старте системы:
# chkconfig nfs on # chkconfig nfslock on
Непосредственный же запуск NFS отложим до разворачивания всех необходимых нам данных.
Организация сетевой установки: предварительные действия
Осталось организовать сетевую загрузку и установку. Во-первых, нам понадобятся данные с загрузочного диска дистрибутива ПСПО "Легкий Линукс" (возможно, подойдет и какой-либо другой дистрибутив из семейства ALT Linux). Будем считать, что соответствующая файловая система уже примонтирована к каталогу /media/cdrom. Скопируем все содержимое диска в подкаталог каталога /srv/boot:
# cp -a /media/cdrom /srv/boot/lite
Теперь зайдем в системный каталог, который отвечает за этап загрузки, поддерживаемый уже настроенным нами tftp-сервером:
# cd /var/lib/tftpboot
Создадим в нем подкаталог, соответствующий установке по сети:
# mkdir install
Скопируем нужные для загрузки файлы:
# cp /srv/boot/lite/syslinux/alt0/* install/ # cp /usr/lib/syslinux/pxelinux.0 .
Создадим теперь еще один необходимый для нас каталог:
# mkdir pxelinux.cfg
В нем нужно создать файл с именем default (полным путем к нему будет, естественно, /var/lib/tftpboot/pxelinux.cfg/default) со следующим содержимым:
timeout 10 prompt 1 default install label install kernel install/vmlinuz append initrd=install/full.cz fastboot automatic=method:nfs,network:dhcp,server:10.30.5.1,directory:/srv/boot/lite ai live stagename=altinst
Осталось внести нужные нам модификации в установщик.
Организация сетевой установки: модификация установщика
Для внесения изменений в установщик нам понадобится архив со всеми необходимыми файлами (прикладывается к инструкции). Будем производить все действия из домашнего каталога суперпользователя /root:
# cd
Пусть имя файла с архивом --- hack-pkg.tgz. Распакуем его:
# tar xvvzf hack-pkg.tgz
Все файлы из архива будут помещены в каталог hack. Перейдем в него:
# cd hack
Вначале следует отредактировать файл options, содержащий общие настройки. В нашем случае он должен выглядеть примерно так:
# NFS server name SERVER=host1 # NFS home export NFS_HOME=/srv/home # server-side directories: # hack home HACK_HOME=/root/hack SOURCE="$HACK_HOME"/src BIN="$HACK_HOME"/bin # installer DEST=/srv/boot/lite # installer subdirectory names: REPO=ALTLinux META=Metadata # absolute paths: REPODIR="$DEST/$REPO" METADIR="$DEST/$META"
Если значения каких-либо переменных не соответствуют действительности, то в options следует внести соответствующие изменения. host1 --- это имя нашего сервера с точки зрения службы NFS, /srv/home --- расположение домашних каталогов пользователей клиентских компьютеров. /root/hack --- наше текущее "местонахождение", /srv/boot/lite --- каталог с содержимым диска выбранного нами дистрибутива ПСПО.
После сохранения изменений нужно модифицировать также файл src/synchrone-src/etc/synchrone/config/global. Этот файл содержит основные настройки утилиты synchrone и будет при установке распространен по всем клиентским компьютерам. Следует привести его содержимое примерно к такому виду:
# Configuration file for synchrone (simply sourced)
# Server-related options
SERVER_ADDRESS=10.30.5.1
SERVER_PORT=873
SERVER_PUB=/profiles
SERVER_UPLOAD=/update-profiles
UPLOAD_USER=updater
# Local destination
TARGET=/
# End of configuration settings
# (you should NOT probably change any line below this
# unless you know exactly what you are doing!)
# Local settings are kept in a seperate file
# so they shall not be syncronized
CONFIG_LOCAL=/etc/synchrone/config/local
if [ -r "$CONFIG_LOCAL" ]; then
. "$CONFIG_LOCAL"
fiЗдесь нужно вписать IP-адрес нашего сервера вместо 10.30.5.1, а также задать имя пользователя из базы данных rsync (/etc/rsyncd.secrets), который будет отвечать за сохранение профилей клиентских компьютеров на нашем сервере (в нашем случае это updater, что соответствует сделанной нами ранее записи в /etc/rsyncd.secrets).
Сохраним изменения и отредактируем еще один файл --- им будет src/synchrone-src/etc/rc.d/init.d/synchrone. Чтобы обеспечить автоматическую (при загрузке) синхронизацию времени на клиентских компьютерах со временем на нашем сервере, раскомментируем несколько строк в ветке start) в данном сценарии, удалив пять стоящих столбцом символов решетки # (один должен остаться). Содержимое файла должно выглядеть так:
# Init file for synchrone
#
# chkconfig: 2345 12 88
# description: synchrone is a simple wrapper for rsync(1)
#
# config: /etc/synchrone/config/global
# config: /etc/synchrone/config/local
# config: /etc/synchrone/rules/main
# config: /etc/synchrone/rules/local
# config: /etc/synchrone/rules/upgrade
WITHOUT_RC_COMPAT=1
SYNCHRONE=/usr/bin/synchrone
case "$1" in
start)
# synchonize time
if which rdate > /dev/null 2>&1; then
rdate -s host1
hwclock --systohc
fi
"$SYNCHRONE" --upgrade
"$SYNCHRONE" --get
;;
stop)
;;
restart)
#"$SYNCHRONE" --get
;;
reload)
;;
status)
;;
*)
;;
esac
exit 0Сохраним изменения и в этом файле. Последнее изменение, которое нам необходимо внести, касается сценария автоматической установки, находящегося в файле src/metadata-mod/autoinstall.scm. В нем следует заменить строку pass1word на пароль суперпользователя клиентских компьютеров (обратим внимание, что данная строка встречается в файле четырежды). Заметим также, что в данном сценарии задаются также регистрационное имя и пароль "резервного" пользователя (гостя): по умолчанию это guest и guest.
После записи сценария автоматической установки на диск запустим собственно модификатор установщика, передав ему в качестве параметра имя файла с основными настройками:
# ./modify-installer.sh options
Когда модификатор завершит свою работу, в нашем классе появится возможность выполнять установку ОС на клиентские компьютеры по сети в автоматическом режиме. Единственное действие (отложенное нами ранее), которое необходимо выполнить для включения данной возможности, --- это включение службы NFS:
# service nfs start # service nfslock start
После это действия по разворачиванию сервера можно считать оконченными.
Использование профилей
Начальная настройка. После окончания установки операционной системы на клиентские компьютеры необходимо выполнить действия по начальной настройке. Оператор садится за любой из клиентских компьютеров, производит установку дополнительного ПО и настраивает рабочее пользовательское окружение. После сохранения всех изменений в файловой системе он получает права суперпользователя и отправляет текущий профиль на сервер следующей командой:
# synchrone --put
Сразу же после этого следует отправить на сервер "печать" ("штамп") с помощью другой команды:
# synchrone --stamp
В результате этих действий на сервере будет создан корректный профиль с именем по умолчанию defprofile. Для окончания настройки достаточно перезагрузить остальные клиентские машины, что приведет к распространению настроенного оператором окружения. В случае возникновения проблем с каким-либо конкретным компьютером (или в иной ситуации, делающей перезагрузку нежелательной) следует выполнить обновление его профиля вручную. Для этого нужно получить в его терминале права суперпользователя и дать последовательность команд для ручного обновления:
# synchrone --upgrade # synchrone --get
На этом начальную настройку можно считать завершенной. Отметим, что в случае ручного обновления и внесения масштабных изменений в конфигурацию могут возникнуть проблемы, связанные с несоответствием функционирующего в операционной системе ПО и набора файлов на диске. В таких случаях настоятельно рекомендуется все же перезагрузить машину для решения этих проблем.
Внесение изменений. Ясно, что в процессе работы может возникнуть необходимость изменить конфигурацию системы на клиентских компьютерах. Эти изменения могут касаться как системных настроечных файлов, так и набора установленного ПО. При возникновении такой необходимости предлагается придерживаться следующих правил. Первым делом нужно выбрать любую из клиентских машин, на которой и будут производиться действия по настройке. Перед процессом конфигурирования состояние этой (эталонной) машины должно соответствовать рабочему профилю, хранящемуся на сервере, --- иными словами, в системе нет следов "нештатных" изменений. Если уверенности в такой "чистоте" окружения нет, следует от имени суперпользователя этой машины выполнить ручное обновление:
# synchrone --upgrade # synchrone --get
После того, как на машине получено "чистое" рабочее окружение, можно приступать к действиям по настройке --- редактированию конфигурационных файлов, установке и удалению ПО и пр. После внесения необходимых изменений следует аккуратно протестировать полученное окружение на работоспособность. Если проблем при функционировании системы не возникает, нужно отправить текущий профиль на сервер в качестве актуального:
# synchrone --put
После этого, как и в случае начальной настройки, нужно "проштамповать" отправленный профиль:
# synchrone --stamp
Чтобы изменения корректно распространились на все клиентские машины, достаточно, как и ранее, их перезагрузить. Точности ради отметим, что сделанные выше замечания, касающиеся ручного обновления, также остаются в силе.
Отмена изменений. При внесении изменений в конфигурацию клиентских машин по описанной выше схеме может понадобиться эти изменения отменить. Если после выполнения тех или иных действий по конфигурированию оказывается, что они были ошибочны или не дали нужного результата, следует, не отправляя результат на сервер, вернуть прежнее состояние пользовательского окружения на настроенной ошибочно машине. Для этого необходимо от имени суперпользователя (на этой машине) выполнить последовательность команд:
# synchrone --upgrade # synchrone --get
Конфигурация этой машины будет заново загружена с сервера.
Возможна и более неприятная ситуация, когда внесенные в профиль ошибочные изменения уже отправлены на сервер. Решением в такой ситуации может стать использование одной из еще не "обновленных" машин в качестве эталонной. Следует загрузить такую машину без сетевого доступа к серверу (простейший вариант --- выдернуть на время ее загрузки кабель из сетевой платы), чтобы на ней сохранилось "правильное" окружение, после чего обеспечить доступ к сети и отправить корректный профиль на сервер:
# synchrone --put # synchrone --stamp
Ошибочный профиль на сервере будет заменен профилем этой эталонной машины. Для восстановления корректной конфигурации всех клиентских машин достаточно, как и ранее, их перезагрузки или ручных действий по обновлению.
Отметим, что если внесенные однажды ошибочные изменения были распространены на все компьютеры, то отменить их таким способом невозможно (без специальных предварительных действий). Будьте внимательны при конфигурировании клиентских машин!
Сложные изменения. Описанные выше сценарии, очевидно, не исчерпывают всего многообразия ситуаций, с которыми можно столкнуться при настройке. Не исключены, к примеру, случаи, в которых те или иные изменения не доводятся до конца (и, следовательно, не должны распространяться на все компьютеры), однако нуждаются в сохранении для дальнейшей доработки. Здесь возможны несколько различных вариантов действий.
Временный профиль. Если компьютер, в конфигурацию которого вносились изменения, должен функционировать в штатном режиме (то есть как если бы никаких изменений не вносилось вовсе), рекомендуется сохранить изменения в качестве нового, "временного" профиля. Для этого, во-первых, нужно выбрать новое имя для создаваемого профиля: в нашем примере это будет tempprofile. Во-вторых, следует отправить конфигурацию на сервер под этим именем с помощью следующих команд (имя tempprofile следует заменить на выбранное имя нового профиля):
# synchrone --put --profile=tempprofile # synchrone --stamp --profile=tempprofile
Это приведет к тому, что конфигурация компьютера, с которого были выполнены эти команды, будет сохранена на сервере под выбранным именем. После этого следует восстановить "рабочую" конфигурацию вручную, выполнив команды:
# synchrone --upgrade # synchrone --get
Конфигурация компьютера будет приведена в соответствие с основным "рабочим" профилем. Когда понадобится продолжить последовательность сохраненных данным способом изменений, следует вновь выбрать эталонный компьютер (возможно, другой) и выполнить на нем следующие команды (снова с заменой tempprofile на выбранное ранее имя):
# synchrone --upgrade --profile=tempprofile # synchrone --get --profile=tempprofile
После этого настройку следует продолжать так, как если бы она не прерывалась. Возможно вновь сохранить результат во "временный" профиль и восстановить на эталонной машине основную рабочую конфигурацию --- последовательность необходимых для этого действий совпадает с описанной в этом пункте выше, при этом можно использовать как использованное ранее имя "временного" профиля (тогда старая конфигурация на сервере будет замещена новой), так и новое, ранее не использовавшееся имя. Возможно также завершить "многоэтапную" настройку, отправив окончательный вариант профиля на сервер стандартным способом и распространив изменения на все компьютеры.
Особый профиль. Если компьютер, в конфигурацию которого вносились изменения, должен выступать в роли "особого" (то есть на него не должны распространяться изменения, касающиеся других компьютеров), рекомендуется перевести его в режим использования отдельного профиля. Для этого, как и в предыдущем случае, следует выбрать для этого профиля новое имя: в нашем примере это будет specprofile. Это имя следует вписать в конфигурационный файл /etc/synchrone/config/local вместо имени общего (стандартного) профиля. Данный файл нужно открыть с помощью любого текстового редактора и заменить строку с именем используемого профиля на такую (естественно, имя specprofile следует заменить на выбранное имя для нового профиля):
PROFILE_NAME=specprofile
После этого следует сохранить изменения в данном файле и выполнить отправку конфигурации на сервер способом, описанным в пункте "Начальная настройка":
# synchrone --put # synchrone --stamp
Профиль будет отправлен на сервер под указанным в файле /etc/synchrone/config/local именем. Его использование на "выделенном" компьютере не будет "перемешиваться" с работой других компьютеров, поэтому изменения в разные профили могут вноситься независимо (стандартным образом). Заметим, что любой компьютер можно перевести на использование любого из существующих профилей. Для этого достаточно указать соответствующее имя в файле /etc/synchrone/config/local и выполнить обновление любым из описанных способов: перезагрузить компьютер или дать стандартную последовательность команд для обновления:
# synchrone --upgrade # synchrone --get