URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 90026
[ Назад ]

Исходное сообщение
"Права на папки для работы rsync"

Отправлено Meddina , 13-Окт-10 17:29 
Доброго времени суток!
Имею вопрос, так что не знаю как подступиться для его решения:

есть в моем ведении 2 сервера: Server и Backup. Необходимо еженощно бекапить rsync'om кучу директорий с Server'a. кынтс работает через ssh.
Мне удалось настроить беспарольный вход от имени юзера с ограниченными правами work (входит в группу Wheel, могу от имени work запускать sudo bash и я уже с root-правами)
Теперь задача эту кучу директорий забирать по rsync на Backup.
Список директорий для бэкапа:
/data - сюда по пользователь work имеет доступ чтобы синхронизировать файлы и директории с Backup.
На остальные директории он прав не имеет:
/etc
/usr/etc
/usr/local/etc
/usr/home
/usr/local/www
/usr/local/services

На Backup запускается команда(скрипт), которая rsync'ом копирует файлы с сервера:
что-то вроде rsync -e ssh --progress -lzuogthvr work@site.com:/data /data/site/
Но на системных директориях rsync выпадает с ошибкой "нет такого файла"или "файл не найден".

вопрос: как выкрутиться из этой ситуации? Как сделать так чтобы rsync работал в пакетном режиме, не интерактивно?
не прописывать же по всем директориям доступ для юзера work?
И не заходить по ssh от root - это тоже  приемлемо.

Надеюсь я доступно изложил мой вопрос, если что не понятно, готов прояснить.

спасибо.


Содержание

Сообщения в этом обсуждении
"Права на папки для работы rsync"
Отправлено apl , 13-Окт-10 18:13 
> Доброго времени суток!
> Имею вопрос, так что не знаю как подступиться для его решения:
> есть в моем ведении 2 сервера: Server и Backup. Необходимо еженощно бекапить
> rsync'om кучу директорий с Server'a. кынтс работает через ssh.

Посмотри на Dirvish. Это Rsync basded backup solution. Используем в продакшене уже больше 5 лет.



"Права на папки для работы rsync"
Отправлено PavelR , 13-Окт-10 19:50 
>> Доброго времени суток!
>> Имею вопрос, так что не знаю как подступиться для его решения:
>> есть в моем ведении 2 сервера: Server и Backup. Необходимо еженощно бекапить
>> rsync'om кучу директорий с Server'a. кынтс работает через ssh.
> Посмотри на Dirvish. Это Rsync basded backup solution. Используем в продакшене уже
> больше 5 лет.

о, что-то новое и rsync-based. надо заценить тех возможности.


"Права на папки для работы rsync"
Отправлено Nettank , 13-Окт-10 18:20 
А почему нельзя запускать не на Backup, а на Server что-нибудь типа
rsync -e ssh -ztr.... /data user@Backup:/data ?
Тогда вроде бы проблемы такой и не возникнет.

"Права на папки для работы rsync"
Отправлено PavelR , 13-Окт-10 20:35 
> А почему нельзя запускать не на Backup, а на Server что-нибудь типа
> rsync -e ssh -ztr.... /data user@Backup:/data ?
> Тогда вроде бы проблемы такой и не возникнет.

Мое имхо говорит мне что более правильно таки такие скрипты запускать на бэкап-машине а не на бэкапируемом хосте.


Не вижу проблемы со входом под рутом по ключу.

PermitRootLogin without-password или как-то так опция зовется, не помню, по памяти пишу.
Смотрю в сторону dirvish-а, как он организован....
В нем есть то, о чем я размышлял когда-то... В настоящее время - bontmia, несколько "пропатченная", но pre и post скриптов еще не изобрел. буду смотреть как сделан дирвиш.


"Права на папки для работы rsync"
Отправлено Meddina , 14-Окт-10 07:10 
> Не вижу проблемы со входом под рутом по ключу.
> PermitRootLogin without-password или как-то так опция зовется, не помню, по памяти пишу.

Если я правильно понял, вы говорите о настройках sshd? можно поподробнее?

> Смотрю в сторону dirvish-а, как он организован....
> В нем есть то, о чем я размышлял когда-то... В настоящее время
> - bontmia, несколько "пропатченная", но pre и post скриптов еще не
> изобрел. буду смотреть как сделан дирвиш.

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


"Права на папки для работы rsync"
Отправлено apl , 14-Окт-10 07:25 
>> Не вижу проблемы со входом под рутом по ключу.
>> PermitRootLogin without-password или как-то так опция зовется, не помню, по памяти пишу.
> Если я правильно понял, вы говорите о настройках sshd? можно поподробнее?

     PermitRootLogin

         Specifies whether the root can log in using ssh(1).  The
         argument   must   be   yes,   without-password,  forced-
         commands-only, or no. without-password means  that  root
         cannot   be   authenticated   using  the  "password"  or
         "keyboard-interactive"  methods  (see   description   of
         KbdInteractiveAuthentication   above).


>> Смотрю в сторону dirvish-а, как он организован....
>> В нем есть то, о чем я размышлял когда-то... В настоящее время
>> - bontmia, несколько "пропатченная", но pre и post скриптов еще не
>> изобрел. буду смотреть как сделан дирвиш.
> да занятная штучка... вот только сомневаюсь подойдет ли она в моем случае...
> Server находится в Питере, Backup в Новосибирске...

Дирвиш умеет бекапить только измененные файлы. Этим оно и отличается от полного пофайлового бекапа. Если initial бэкап у нас занимал 4 часа, то второй -- 20-30 минут.
У меня сервер находится в питере, а бекап в Калифорнии. :-)



"Права на папки для работы rsync"
Отправлено Meddina , 14-Окт-10 08:44 
>      PermitRootLogin
>          Specifies whether the  root can log in using ssh(1).  The
>          argument   must   be   yes,   without-password,  forced-
>          commands-only, or no. without-password means  that  root
>          cannot  be   authenticated   using  the  "password"  
>          or  "keyboard-interactive"  methods (see   description  
>          of KbdInteractiveAuthentication above).

вот тут мне не понятно: с одной стороны рутом на удаленный сервер нежелательно
предоставлять доступ по ssh (у нас он отключен).
С другой - вроде как надо.

вопрос: а можно ли обойти этот скользкий момент с помощью sudoers?

> Дирвиш умеет бекапить только измененные файлы. Этим оно и отличается от полного
> пофайлового бекапа. Если initial бэкап у нас занимал 4 часа, то
> второй -- 20-30 минут.

если я правильно понимаю, то любая rsync-based утилита будет так работать, если без наворотов.
Да и вопрос о правах пользователя группы wheel на системные директории остается повисшим.
Пока что-то не представляю как Dirvish решит этот вопрос...



"Права на папки для работы rsync"
Отправлено apl , 14-Окт-10 09:26 
>[оверквотинг удален]
>>          Specifies whether the  root can log in using ssh(1).  The
>>          argument   must   be   yes,   without-password,  forced-
>>          commands-only, or no. without-password means  that  root
>>          cannot  be   authenticated   using  the  "password"  
>>          or  "keyboard-interactive"  methods (see   description  
>>          of KbdInteractiveAuthentication above).
> вот тут мне не понятно: с одной стороны рутом на удаленный сервер
> нежелательно
> предоставлять доступ по ssh (у нас он отключен).
> С другой - вроде как надо.

Тут можно разрешить ходить рутом только с определенного хоста, и ключ залочить на определенный хост. ну можно еще firewall-ом зафильтровать.

> вопрос: а можно ли обойти этот скользкий момент с помощью sudoers?

теоретически да, но практически будет тяжело и смысла иметь не будет.

>> Дирвиш умеет бекапить только измененные файлы. Этим оно и отличается от полного
>> пофайлового бекапа. Если initial бэкап у нас занимал 4 часа, то
>> второй -- 20-30 минут.
> если я правильно понимаю, то любая rsync-based утилита будет так работать, если
> без наворотов.

Да. Дирвиш -- это просто фрэмворк вокруг rsync.

> Да и вопрос о правах пользователя группы wheel на системные директории остается
> повисшим.

Объясни, что ты имеешь ввиду. если ты на удаленный хост заходишь root-ом, то автоматом и в группе wheel.



"Права на папки для работы rsync"
Отправлено Meddina , 14-Окт-10 11:58 
>>[оверквотинг удален]
>> вот тут мне не понятно: с одной стороны рутом на удаленный сервер
>> нежелательно
>> предоставлять доступ по ssh (у нас он отключен).
>> С другой - вроде как надо.
> Тут можно разрешить ходить рутом только с определенного хоста, и ключ залочить
> на определенный хост. ну можно еще firewall-ом зафильтровать.

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

>> Да и вопрос о правах пользователя группы wheel на системные директории остается
>> повисшим.
> Объясни, что ты имеешь ввиду. если ты на удаленный хост заходишь root-ом,
> то автоматом и в группе wheel.

вот почему спросил:
логин на Server (смотри первый пост) по ssh делается от имени work (состоит в группе wheel). следовательно, если заходишь как work надо получить рутовые права. Это можно сделать интерактивно - sudo bash, например. А вот как в пакетном режиме?



"Права на папки для работы rsync"
Отправлено apl , 14-Окт-10 18:49 
>>>[оверквотинг удален]
> нет. Это не подойдет - разработчики ходят на сервак с кучи айпи
> адресов, кто-то с динамического пулла... дохлый номер всех отлавливать - ибо
> всегда будут обделенные :-)

Это тоже решается. опять же preshared keys.

> вот почему спросил:
> логин на Server (смотри первый пост) по ssh делается от имени work
> (состоит в группе wheel). следовательно, если заходишь как work надо получить
> рутовые права. Это можно сделать интерактивно - sudo bash, например. А
> вот как в пакетном режиме?

Нужно курить маны в эту сторону:
rsync -av --rsync-path='sudo rsync' remote:dir .
но sudo должно быть NOPASSWORD


"Права на папки для работы rsync"
Отправлено PavelR , 14-Окт-10 09:43 
>> Не вижу проблемы со входом под рутом по ключу.
>> PermitRootLogin without-password или как-то так опция зовется, не помню, по памяти пишу.
> Если я правильно понял, вы говорите о настройках sshd? можно поподробнее?
>> Смотрю в сторону dirvish-а, как он организован....
>> В нем есть то, о чем я размышлял когда-то... В настоящее время
>> - bontmia, несколько "пропатченная", но pre и post скриптов еще не
>> изобрел. буду смотреть как сделан дирвиш.
> да занятная штучка... вот только сомневаюсь подойдет ли она в моем случае...
> Server находится в Питере, Backup в Новосибирске...

debian:~# cat /etc/ssh/sshd_config |grep oot
PermitRootLogin without-password


Содержимое authorized_keys:
from="1.2.3.4" no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAB3Nz....[продолжение ключа]



"Права на папки для работы rsync"
Отправлено Meddina , 14-Окт-10 07:07 
> А почему нельзя запускать не на Backup, а на Server что-нибудь типа
> rsync -e ssh -ztr.... /data user@Backup:/data ?
> Тогда вроде бы проблемы такой и не возникнет.

Потому что:
1. Идеологически бэкап-задачи выполняются на резервном хосте. Да и продакшн сервер не хотелось бы грузить лишним функционалом.
2. организовано так, что Server - находится на арендуемом сервере у хостера. Backup - в серверной, в офисе. Чтобы заставить Server отправлять бэкапы на Backup, надо будет использовать нестандартные порты для работы rsync, ssh (так как стандартые уже заняты). А лишние действия - они лишние.



"Права на папки для работы rsync"
Отправлено apl , 14-Окт-10 07:17 
>> А почему нельзя запускать не на Backup, а на Server что-нибудь типа
>> rsync -e ssh -ztr.... /data user@Backup:/data ?
>> Тогда вроде бы проблемы такой и не возникнет.
> Потому что:
> 1. Идеологически бэкап-задачи выполняются на резервном хосте. Да и продакшн сервер не
> хотелось бы грузить лишним функционалом.
> 2. организовано так, что Server - находится на арендуемом сервере у хостера.
> Backup - в серверной, в офисе. Чтобы заставить Server отправлять бэкапы
> на Backup, надо будет использовать нестандартные порты для работы rsync, ssh
> (так как стандартые уже заняты). А лишние действия - они лишние.

Поддерживаю.

Любой бэкап -- это дырка в безопасности. Тут выгоднее делать pull (инициировать бекап с бекапного сервера). Да и не продакшен хосте держать ключи для доступа куда-то внутрь идеологически неверно.
Но можно и rsync-ом (over ssh+preshared keys) делать то-же самое.
rsync -zavHessh host:/fs /localdir/
Дирвиш еще умеет бекапить только измененные файлы и делать хардлинки на уже существующие файлы если они не менялись.
вот примерно такой командой:
ACTION: rsync -vrltH --delete -pgo --stats -S -D --numeric-ids -x --exclude-from=/backup/bank0/root/2010-10-13/exclude --link-dest=/backup/bank0/root/2010-10-12
/tree /snapshot/root/ /backup/bank0/root/2010-10-13/tree