Копирование файлов
Категория: Совместное использование конфигов | Автор: admin | 13-05-2010, 03:18 | Просмотров: 4582

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

В руководствах (в соответствии с общими принципами UNIX-культуры) предполагается, что администраторы будут использовать систему типа NIS или NIS+, если таковая имеется. Однако если в организации не решаются сложные задачи, то и в сложных решениях нет необходимости. Иногда самое "лобовое", самое тривиальное решение оказывается наилучшим.

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

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

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

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

 

Утилита rdist: принудительная рассылка

 

В большинстве случаев наилучшим способом распространения файлов с центрального сервера считается использование утилиты rdist. В ней есть сходство с программой make: вначале пользователь в текстовом редакторе составляет описание (спецификацию) файлов, подлежащих рассылке, а затем утилита rdist осуществляет операции копирования в соответствии с описанием. Утилита копирует файлы, если их локальные копии устарели, поэтому в спецификации можно задать копирование всех файлов, а утилита rdist самостоятельно определит, какие из них подлежат этой операции.

Утилита rdist сохраняет информацию о владельце, группе, правах доступа и времени модификации файла. Когда утилита обновляет существующий файл, то перед инсталляцией нового она удаляет старую версию. Это позволяет использовать данную программу для пересылки исполняемых файлов, которые могут оказаться запущенными во время обновления.

К сожалению, утилита rdist имеет ряд слабых мест с точки зрения безопасности. Она работает поверх программы rsh и использует ее средства аутентификации для получения доступа к удаленным системам. При этом доступ от имени суперпользователя возможен с любого узла, указанного в файле /.rhosts удаленной системы. В прошлом такая схема еще была приемлема в изолированных или малодоступных сетях. Сегодня, учитывая распространение Internet, она слишком опасна. Если один компьютер взломан, все остальные компьютеры, слепо доверяющие ему, также становятся небезопасными.

Поскольку распространяются административные файлы, например /etc/passwd, понятно, что привилегированный доступ к главному серверу может быть использован для получения аналогичного доступа к клиентским машинам. Но проблема не в этом, а в том, что, выполняя демон rlogind (сервер для программы rsh, а также rlogin и rcp), клиенты могут подвергаться другим видам атак.

В общем случае наш совет таков: откажитесь от демона rlogind. Если без утилиты rdist нельзя обойтись, нужно, по крайней мере, использовать пакет tcpd, который позволит задать, каким узлам разрешен доступ к демону rlogind каждого конкретного клиента. Этот пакет можно получить по адресу ftp.porcupine.org.

Утилита rdist может выполняться не только от имени суперпользователя, но демон rlogind все равно должен работать на каждом удаленном узле. Кроме того, в данной конфигурации требуется, чтобы на каждом клиенте была программа, принимающая копируемые файлы и инсталлирующая их в требуемые каталоги. Данная операция доступна только пользователю root. Но все равно, ничего не мешает непривилегированному взломщику передать в удаленную систему фальсифицированный файл /etc/passwd. Так что мы не считаем, что возможность выполнения утилиты rdist от имени непривилегированного пользователя повышает безопасность системы.

Утилита rdist в Red Hat и FreeBSD позволяет заменять программу rsh любой другой, понимающей аналогичный синтаксис. Таковой может быть программа ssh, имеющая два основных преимущества. Во-первых, она может использовать шифрование с открытым ключом для проверки подлинности сигнатуры главного узла. Во-вторых, она шифрует весь диалог, не давая возможности шпионам, прослушивающим сеть, получать копии системных файлов. Недостаток заключается в том, что удаленные серверы ssh должны выполняться в режиме, позволяющем не указывать пароль, а это менее безопасный режим, чем требуется в обычных условиях. 

Итак, разобравшись с тем, какую угрозу таит в себе утилита rdist, рассмотрим подробно, как она функционирует. Как и программа make, утилита rdist ищет в текущем каталоге управляющий файл (distfile или Distfile). Команда rdist -f файл задает путевое имя управляющего файла явно. В качестве разделителей в этом файле используются знаки табуляции, пробелы и признаки новой строки. Комментарии предваряются знаком решетки (#).

Тело управляющего файла состоит из операторов, имеющих следующий синтаксис:

метка: путевые_имена -> адресаты команды

 

Поле метка является именем данного оператора. Из командной строки можно дать команду rdist метка, которая обеспечит рассылку только тех файлов, что описаны в указанном операторе.

Поля путевые_имена и адресаты содержат соответственно список файлов, подлежащих копированию, и список компьютеров, куда их нужно переслать. Если в списке больше одного элемента, его нужно заключить в круглые скобки, а элементы — разделить пробелами. Список путевые_имена может включать метасимволы, допустимые в интерпретаторе команд (например, /usr/lib/* или /usr/man/man[123]). Приемлема также запись ~пользователь, но соответствующие ей значения на машине-отправителе и машине-адресате могут не совпадать.

По умолчанию утилита rdist копирует файлы и каталоги, перечисленные в списке путевые_имена, в эквивалентные каталоги на каждой машине-адресате. Этот порядок можно изменить, указав последовательность команды. Каждую команду следует завершать точкой с запятой.

Можно использовать такие команды:

 

install опции [каталог-адресат];

notify список_имен;

except список_путей;

except_pat список_шаблонов;

special  [список_путейстрока;

 

 

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

Имя команды install слегка вводит в заблуждение, так как файлы копируются вне зависимости от того, присутствует эта команда или нет. Опции задаются так, как они задавались бы в командной строке утилиты rdist, но при включении в управляющий файл они действуют только на совокупность файлов, указанную в данном операторе.

Необязательный аргумент католог-адресат задает каталог, в который инсталлируются файлы на машинах-адресатах. По умолчанию утилита rdist использует исходные путевые имена.

В команде notify в качестве аргумента задается список адресов электронной почты. При каждом обновлении очередного файла утилита rdist посылает по этим адресам почтовое сообщение. Имя машины-адресата добавляется ко всем адресам, не содержащим знак @. Например, при выдаче списка файлов, откорректированных на компьютере anchor, компьютер pete превратится в pete@anchor.

Команды except и except_pat служат для удаления путевых имен из списка файлов, подлежащих копированию. Аргументы команды except трактуются буквально, а аргументы команды except_pat интерпретируются как регулярные выражения. Эти команды весьма полезны, поскольку утилита rdist, как и make, позволяет задавать в начале управляющего файла макроконстанты. Можно использовать один список с несколькими операторами, указывая для каждого компьютера только те имена, которые нужно удалить или добавить.

Команда special запускает интерпретатор sh (аргумент строка которого нужно брать в кавычки) на всех удаленных компьютерах. Если есть аргумент список_путей, утилита rdist запускает интерпретатор один раз после копирования каждого из указанных файлов. В противном случае интерпретатор активизируется после копирования каждого файла в пределах текущего оператора. К сожалению, интерпретатор нельзя запустить один раз после копирования всех файлов

Приведем пример файла Distfile:

 

SYS_FILES   =  (/etc/passwd /etc/group /etc/mail/aliases)

GET_ALL     =  (chimchim lollipop barkadon)

GET_SOME    =  (whammo spiff)

 

all:  ${SYS_FILES} -> ${GET_ALL)

notify barb;

special /etc/mail/aliases "/usr/bin/newaliases";

some:  ${SYS_FILES}  -> ${GET_SOME)

except /etc/mail/aliases;

notify eddie@spiff;

 

 

В данной конфигурации три указанных системных файла копируются на компьютеры chimchim, lollipop и barkadon, а по адресу barb@адресат посылается сообщение с описанием всех изменений и замеченных ошибок. После копирования файла /etc/mail/aliases утилита rdist запускает на каждой машине-адресате программу newaliases. На компьютеры whammo и spiff копируются только два файла, а отчет отправляется по адресу eddie@spiff. Программа newaliases на этих двух компьютерах не запускается.

 

Программа rsync: более безопасная рассылка файлов

 

Программа rsync, написанная Эндрю Триджеллом (Andrew Tridgell) и Полом Макеррасом (Paul Mackerras), близка по духу утилите rdist, но по-другому реализована. Она напоминает улучшенную версию программы rcp, пытающуюся сохранить ссылки, информацию о времени модификации и правах доступа. Программа rsync более эффективна, чем rdist, поскольку способна анализировать отдельные файлы и пытается передавать только различия между версиями

 

С нашей точки зрения, основным преимуществом программы rsync является то, что на принимающих компьютерах серверный процесс может запускаться из демона inetd. Сервер (на самом деле это та же программа rsync, но работающая в другом режиме; она должна быть инсталлирована как на главном компьютере, так и на клиентах) допускает гибкую настройку: он может предоставлять удаленный доступ лишь к заданному набору каталогов и требовать, чтобы главный компьютер подтвердил свою подлинность паролем. Поскольку доступ на уровне программы rsh не требуется, можно организовать распространение системных файлов посредством программы rsync, не жертвуя безопасностью. (Тем не менее, программа rsync разрешает пользоваться программами rsh и ssh, а не серверным процессом, работающим под управлением демона inetd.)

Так как у программы rsync нет конфигурационного файла на отправляющей стороне, она должна запускаться многократно для передачи набора файлов нескольким узлам. Например, команда

# rsync -gopt —password-file=/etc/rsync.pwd /etc/passwd

      lollipop::/sysfiles

 

посыпает файл /etc/passwd на компьютер lollipop. Флаг -gopt указывает на необходимость сохранения прав доступа, идентификаторов принадлежности и времени модификации файла. Два двоеточия в выражении lollipop::/sysfiles заставляют программу rsync связаться с удаленным сервером rsync непосредственно через порт 873, не используя для этого программу rsh. Для аутентификации соединения берется пароль из файла /etc/rsync.pwd .

Чтобы сконфигурировать сервер rsync на каждом клиентском компьютере (т.е. на каждом компьютере, принимающем файлы; с точки зрения самойс программы такие "клиенты", скорее, являются серверами), требуется выполнить несколько действий:

  • добавить номер порта программы rsync в файл /etc/services;
  • добавить строку вызова сервера (rsync --daemon) в файл /etc/inetd.conf;
  • сохранить аутентификационные пароли в файле /etc/rsyncd.secrets;
  • сконфигурировать сервер в файле /etc/rsyncd.conf.

 

Записи в файлах services и inetd.conf достаточно просты. В первом случае это

rsync        873/tcp

 

во втором —

rsync stream tcp nowait root     /local/bin/rsync rsyncd --daemon

 

Если используется пакет tcpd, можно сконфигурировать его таким образом, чтобы блокировать доступ всем узлам, за исключением того, который будет распространять системные файлы. Аналогичную установку можно сделать и в файле rsyncd.conf: никогда не помешает воздвигнуть несколько барьеров.

Файл rsyncd.secrets должен содержать единственную запись:

root:пароль

 

Необходимо, чтобы пароль, используемый программой rsync, отличался от реального пароля суперпользователя. Поскольку пароль отображается в незашифрованном виде, файл должен быть доступен для чтения только пользователю root.

Наконец, следует модифицировать файл /etc/rsyncd.conf, который сообщает серверу rsync (принимающей стороне) о том, как себя вести. Разумная конфигурация выглядит примерно так:

 

[sysfiles]

path = /etc

secrets file = /etc/rsyncd.secrets

read only – false

uid = root

gid = root

hosts allow = главный_сервер

 

Существует масса других опций, но установки по умолчанию вполне приемлемы. В данной конфигурации все операции локализованы в каталоге /etc, а доступ разрешен только указанному узлу.

Программа rsync входит в дистрибутив Red Hat. Исходный код (общий для всех систем) можно загрузить с узла rsync.samba.org.

 

Система expect: рассылка файлов по запросу

 

Существует несколько способов реализации системы рассылки файлов по запросу. Один из них, который нам нравится и который, оказывается, полезен и для решения других задач, заключается в том, чтобы сделать системные файлы доступными на центральном сервере по протоколу FTP и осуществлять последующую их выборку и инсталляцию с помощью системы expect.

 

 

Система expect представляет собой набор расширений языка Tcl (Tool Command Language — инструментальный командный язык), разработанного Джоном Оустерхаутом (John Ousterhout). Эти расширения позволяют писать управляющие сценарии для интерактивных программ. Автором системы expect является Дон Либис (Don Libes) из Национального института стандартов и технологий (National Institute of Standards and Technology, NIST). Система expect отличается от обычного языка сценариев (например, от принятого в большинстве интерпретаторов команд) тем, что обеспечивает пошаговое управление подпроцессами. Можно проверять результат каждой операции и определять, какие входные данные необходимо посылать дальше. Кроме того, язык expect устойчив к недружелюбным действиям, которые способна предпринять программа, считающая, что работает с реальным терминалом.

Tcl сам по себе — это функционально полный язык сценариев. Формально сценарии expect являются просто сценариями Tcl, в которых используются дополнительные команды, определенные в расширениях expect. Тем не менее для написания простейших сценариев expect не требуется глубокое знание языка Tcl.

Язык Tcl синтаксически прост. Большинство команд задается аналогично командам системного интерпретатора: команда и ее аргументы просто разделяются пробелами. Фигурные скобки объединяют групповые элементы в отдельные "слова" и позволяют продлевать операторы на несколько строк. В качестве разделителя команд используется точка с запятой; в конце строки и перед закрывающей фигурной скобкой разделитель не обязателен.

Вот основные команды системы expect:

  • spawn — запускает подпроцесс;
  • send — посылает подпроцессу входную информацию;
  • expect — выполняет действие в зависимости от выходной информации подпроцесса.

 

Четвертая команда, interact, также может оказаться полезной, если нужно, чтобы система expect выполнила часть задачи, а затем передала управление пользовательской программе.

Прежде чем рассматривать команды по отдельности, разберем простой пример. Следующий сценарий пересылает с компьютера сервер (посредством программы ftp) файл /etc/passwd:

 

spawn /usr/bin/ftp сервер

while 1  { expect {

   "Name*: "     {send "клиентr"}

   "Password:"   {send "клиентский_парольr"}

   "ftp> "       {break}

   "failed"      {send_user "Can't log in.r"; exit 1}

   timeout       {send_user "Timeout problem.r"; exit 2)

} }

send "lcd /etcr"

expect "ftp> "  {send "cd pub/sysfilesr"}

expect "ftp> "  {send "get passwdr"}

expect "ftp> "  {send "quitr"; send_user "r"}

exit 0

 

 

Последовательность выполнения операций здесь очевидна. Рассматриваемый сценарий сначала запускает команду ftp сервер, а затем ожидает приглашения на ввод имени и пароля в цикле while (базовая конструкция языка TcI). После получения основного приглашения ftp> программа выходит из цикла while, и в программу ftp подается простая серия команд. Перед отправкой каждой команды сценарий ожидает, пока завершится выполнение предыдущей команды; это не строго обязательно, но делает вывод информации очень удобным.

Начальный цикл регистрации предназначен для решения двух проблем. Во-первых, производится проверка строки "failed", позволяющая выявить ситуацию, когда удаленный компьютер отклоняет указанное имя и пароль и программа ftp выводит сообщение "Login failed". Во-вторых, условие timeout позволяет обнаружить случаи, когда в течение десяти секунд ничего не происходит, возможно, потому, что сервер отключен. Если возникает одна из описанных выше ситуаций, сценарий выводит сообщение об ошибке и завершает свое выполнение.

Данный сценарий предполагает, что после успешного входа в систему ошибок быть не может; реальные сценарии обычно включают дополнительные проверки. В этом примере благодаря циклу wnile для нескольких пересылок задается одна процедура обработки ошибок. Есть несколько специальных версий команды expect, предназначенных для решения этой проблемы более элегантным способом.

Команда send посылает на вход подпроцесса строку, указанную в качестве аргумента. При желании можно явно включить в эту строку символ возврата каретки (обозначается как r). Строку без пробелов и специальных символов не нужно брать в кавычки. Команда send_user аналогична команде send, за исключением того, что строка записывается в стандартный выходной поток сценария.

В команде expect в качестве аргументов задаются группы пар шаблон/действие. Если аргументы занимают несколько строк, как в приведенном выше примере, их следует заключать в фигурные скобки. Каждый аргумент действие также необходимо брать в фигурные скобки.

Шаблон — это то, что нужно искать в выходной информации команды; как только появляется эта строка, инициируется соответствующее ей действие. Поиск по шаблону осуществляется, как правило, в соответствии с синтаксисом интерпретатора команд, но можно использовать и регулярные выражения. Действия, указанные для условий timeout и eof, запускаются соответственно после некоторого (задаваемого) периода бездействия и по достижении конца входного потока.

Исходный код системы expect можно загрузить с узла expect.nist.gov.



 (голосов: 0)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page