Решил я всё же добить возможность копирования rsync-ом из-под винды на линукс. Не, ну в самом деле, что за издевательство - такой удобный способ и недоступен!
За основу взял DeltaCopy - cygwin-порт самого rsync и нескольких дополнительных утилит плюс графическая обвязка как для клиента, так и для сервера. GUI-вая часть меня пока не интересует, а вот rsync/win решил испытать. Сразу уточню: есть и другие порты, но их я не проверял и не пробовал.
Задавать имя входного каталога на системе с windows лучше в формате /cygdrive/БУКВА/путь, где "буква" - буква диска без двоеточия, например: /cygrive/c/windows.
Windows имеет дурную привычку хранить имена файлов в разных кодировках - и юникод и 1251 и 866, в общем, полный бардак. Юниксы давно перебрались на utf-8 и не заставляют своих пользователей париться по этому поводу.
Rsync из DeltaCopy не поддерживает копирование виндовых ACL и есть какие-то странности с копированием других расширенных атрибутов. Но в моем конкретном случае это не критично, потому не заморачивался уточнениями.
"код_из" - из какой кодировки преобразуем, "код_в" - в какую. Для копирования с windows на linux получаем --iconv=cp866,utf-8.
Вторая грабля - неожиданное прекращение копирования при указании параметра iconv. Сообщение на отправляющей стороне было совсем невразумительным. А вот в протоколе на самом сервере ситуация немного прояснилась: "rsync: The server is configured to refuse --iconv". Вот те на! Что за нафиг такой?
Вылечилось, опять же, по советам из этих ваших интернетов, добавлением строки charset=utf-8 в /etc/rsyncd.conf.
[media]
path = /media
use chroot = yes
lock file = /var/lock/media-restore.lock
read only = no
timeout = 600
auth users = восстановитель
uid=root
[media] - это имя модуля. Оно указывается в команде отправки:
... пользователь@сервер_rsync::media/путь
Пользователи вместе с их паролями задаются в файле, описанном в конфиге параметром
secrets file = /etc/rsyncd.secrets
Формат файла: каждый пользователь на отдельной строке в виде логин:пароль, например "восстановитель:пароль_восстановления". В конце файла желательна пустая строка.
path - путь в файловой системе сервера
use chroot - крайне желательно во избежание злоупотреблений с путями типа модуль/путь/../../запретная_зона
lock file - служебный файл, создаваемый при обработке операций в этом модуле.
auth users - можно задать не только глобальный список разрешенных пользователей, но и для каждого модуля указывать отдельные разрешения. В примере я не хочу, чтобы к модулю [media] получил доступ какой-нибудь другой пользователь
uid - идентификатор пользователя, от имени которого выполняются операции. Сам демон rsync обычно запускается от рута, поэтому проблем с мимикрированием быть не должно. Дополнительно см. описание параметра --super.
За основу взял DeltaCopy - cygwin-порт самого rsync и нескольких дополнительных утилит плюс графическая обвязка как для клиента, так и для сервера. GUI-вая часть меня пока не интересует, а вот rsync/win решил испытать. Сразу уточню: есть и другие порты, но их я не проверял и не пробовал.
Особенности
Задавать имя входного каталога на системе с windows лучше в формате /cygdrive/БУКВА/путь, где "буква" - буква диска без двоеточия, например: /cygrive/c/windows.
Windows имеет дурную привычку хранить имена файлов в разных кодировках - и юникод и 1251 и 866, в общем, полный бардак. Юниксы давно перебрались на utf-8 и не заставляют своих пользователей париться по этому поводу.
Rsync из DeltaCopy не поддерживает копирование виндовых ACL и есть какие-то странности с копированием других расширенных атрибутов. Но в моем конкретном случае это не критично, потому не заморачивался уточнениями.
Грабли
Первые грабли, на которые я наступил, это трансляция имён файлов, написанных не латиницей. Порылся в интернетах, где мне напомнили, что есть параметр --iconv=код_из,код_в, позволяющий указать характеристики трансляции"код_из" - из какой кодировки преобразуем, "код_в" - в какую. Для копирования с windows на linux получаем --iconv=cp866,utf-8.
Вторая грабля - неожиданное прекращение копирования при указании параметра iconv. Сообщение на отправляющей стороне было совсем невразумительным. А вот в протоколе на самом сервере ситуация немного прояснилась: "rsync: The server is configured to refuse --iconv". Вот те на! Что за нафиг такой?
Вылечилось, опять же, по советам из этих ваших интернетов, добавлением строки charset=utf-8 в /etc/rsyncd.conf.
Всякое разное
Для большей безопасности, я создал в конфиге rsync-а несколько "модулей" - секций, описывающих разные места для копирования и доступы к ним. Пример такого модуля:[media]
path = /media
use chroot = yes
lock file = /var/lock/media-restore.lock
read only = no
timeout = 600
auth users = восстановитель
uid=root
[media] - это имя модуля. Оно указывается в команде отправки:
... пользователь@сервер_rsync::media/путь
Пользователи вместе с их паролями задаются в файле, описанном в конфиге параметром
secrets file = /etc/rsyncd.secrets
Формат файла: каждый пользователь на отдельной строке в виде логин:пароль, например "восстановитель:пароль_восстановления". В конце файла желательна пустая строка.
path - путь в файловой системе сервера
use chroot - крайне желательно во избежание злоупотреблений с путями типа модуль/путь/../../запретная_зона
lock file - служебный файл, создаваемый при обработке операций в этом модуле.
auth users - можно задать не только глобальный список разрешенных пользователей, но и для каждого модуля указывать отдельные разрешения. В примере я не хочу, чтобы к модулю [media] получил доступ какой-нибудь другой пользователь
uid - идентификатор пользователя, от имени которого выполняются операции. Сам демон rsync обычно запускается от рута, поэтому проблем с мимикрированием быть не должно. Дополнительно см. описание параметра --super.
Комментариев нет:
Отправить комментарий
Пожалуйста, воздержитесь от грубостей и персональных нападок.
Я не против матерщины, но она должна быть уместной и использоваться для выражения эмоций, а не в качестве основного средства выражения мыслей.