https://ns.opennet.ru/openforum/vsluhforumID1/90026.html Доброго времени суток!<br>Имею вопрос, так что не знаю как подступиться для его решения:<br><br>есть в моем ведении 2 сервера: Server и Backup. Необходимо еженощно бекапить rsync'om кучу директорий с Server'a. кынтс работает через ssh.<br>Мне удалось настроить беспарольный вход от имени юзера с ограниченными правами work (входит в группу Wheel, могу от имени work запускать sudo bash и я уже с root-правами)<br>Теперь задача эту кучу директорий забирать по rsync на Backup.<br>Список директорий для бэкапа:<br>/data - сюда по пользователь work имеет доступ чтобы синхронизировать файлы и директории с Backup.<br>На остальные директории он прав не имеет:<br>/etc<br>/usr/etc<br>/usr/local/etc<br>/usr/home<br>/usr/local/www<br>/usr/local/services<br><br>На Backup запускается команда(скрипт), которая rsync'ом копирует файлы с сервера:<br>что-то вроде rsync -e ssh --progress -lzuogthvr work@site.com:/data /data/site/<br>Но на системных директориях rsync выпадает с ошибкой "нет такого файла"или "файл не найден".<br><br>вопрос: как выкрутиться из этой ситуации? https://ns.opennet.ru/openforum/vsluhforumID1/90026.html#13 Thu, 14 Oct 2010 14:49:14 GMT &gt;&gt;&gt;[оверквотинг удален]<br>&gt; нет. Это не подойдет - разработчики ходят на сервак с кучи айпи<br>&gt; адресов, кто-то с динамического пулла... дохлый номер всех отлавливать - ибо<br>&gt; всегда будут обделенные :-)<br><br>Это тоже решается. опять же preshared keys.<br><br><br><br>&gt; вот почему спросил:<br>&gt; логин на Server (смотри первый пост) по ssh делается от имени work<br>&gt; (состоит в группе wheel). следовательно, если заходишь как work надо получить<br>&gt; рутовые права. Это можно сделать интерактивно - sudo bash, например. А<br>&gt; вот как в пакетном режиме?<br><br>Нужно курить маны в эту сторону:<br>rsync -av --rsync-path='sudo rsync' remote:dir .<br>но sudo должно быть NOPASSWORD<br><br> https://ns.opennet.ru/openforum/vsluhforumID1/90026.html#12 Thu, 14 Oct 2010 07:58:12 GMT &gt;&gt;[оверквотинг удален]<br>&gt;&gt; вот тут мне не понятно: с одной стороны рутом на удаленный сервер<br>&gt;&gt; нежелательно<br>&gt;&gt; предоставлять доступ по ssh (у нас он отключен).<br>&gt;&gt; С другой - вроде как надо.<br>&gt; Тут можно разрешить ходить рутом только с определенного хоста, и ключ залочить<br>&gt; на определенный хост. ну можно еще firewall-ом зафильтровать.<br><br>нет. Это не подойдет - разработчики ходят на сервак с кучи айпи адресов, кто-то с динамического пулла... дохлый номер всех отлавливать - ибо всегда будут обделенные :-)<br><br>&gt;&gt; Да и вопрос о правах пользователя группы wheel на системные директории остается<br>&gt;&gt; повисшим.<br>&gt; Объясни, что ты имеешь ввиду. если ты на удаленный хост заходишь root-ом,<br>&gt; то автоматом и в группе wheel.<br><br>вот почему спросил: <br>логин на Server (смотри первый пост) по ssh делается от имени work (состоит в группе wheel). следовательно, если заходишь как work надо получить рутовые права. Это можно сделать интерактивно - sudo bash, например. А вот как в пакетном режиме?<br><br><br> https://ns.opennet.ru/openforum/vsluhforumID1/90026.html#11 Thu, 14 Oct 2010 05:43:36 GMT &gt;&gt; Не вижу проблемы со входом под рутом по ключу.<br>&gt;&gt; PermitRootLogin without-password или как-то так опция зовется, не помню, по памяти пишу.<br>&gt; Если я правильно понял, вы говорите о настройках sshd? можно поподробнее?<br>&gt;&gt; Смотрю в сторону dirvish-а, как он организован....<br>&gt;&gt; В нем есть то, о чем я размышлял когда-то... В настоящее время<br>&gt;&gt; - bontmia, несколько "пропатченная", но pre и post скриптов еще не<br>&gt;&gt; изобрел. буду смотреть как сделан дирвиш.<br>&gt; да занятная штучка... вот только сомневаюсь подойдет ли она в моем случае...<br>&gt; Server находится в Питере, Backup в Новосибирске...<br><br>debian:~# cat /etc/ssh/sshd_config &#124;grep oot<br>PermitRootLogin without-password<br><br><br>Содержимое authorized_keys:<br>from="1.2.3.4" no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAB3Nz....[продолжение ключа]<br><br><br> https://ns.opennet.ru/openforum/vsluhforumID1/90026.html#10 Thu, 14 Oct 2010 05:26:37 GMT &gt;[оверквотинг удален]<br>&gt;&gt; Specifies whether the root can log in using ssh(1). The<br>&gt;&gt; argument must be yes, without-password, forced-<br>&gt;&gt; commands-only, or no. without-password means that root<br>&gt;&gt; cannot be authenticated using the "password" <br>&gt;&gt; or "keyboard-interactive" methods (see description <br>&gt;&gt; of KbdInteractiveAuthentication above).<br>&gt; вот тут мне не понятно: с одной стороны рутом на удаленный сервер<br>&gt; нежелательно<br>&gt; предоставлять доступ по ssh (у нас он отключен).<br>&gt; С другой - вроде как надо.<br><br>Тут можно разрешить ходить рутом только с определенного хоста, и ключ залочить на определенный хост. ну можно еще firewall-ом зафильтровать.<br><br>&gt; вопрос: а можно ли обойти этот скользкий момент с помощью sudoers?<br><br>теоретически да, но практически будет тяжело и смысла иметь не будет.<br><br>&gt;&gt; Дирвиш умеет бекапить только измененные файлы. Этим оно и отличается от полного<br>&gt;&gt; пофайлового бекапа. Если initial бэкап у нас занимал 4 https://ns.opennet.ru/openforum/vsluhforumID1/90026.html#9 Thu, 14 Oct 2010 04:44:28 GMT &gt; PermitRootLogin<br>&gt; Specifies whether the root can log in using ssh(1). The<br>&gt; argument must be yes, without-password, forced-<br>&gt; commands-only, or no. without-password means that root<br>&gt; cannot be authenticated using the "password" <br>&gt; or "keyboard-interactive" methods (see description <br>&gt; of KbdInteractiveAuthentication above).<br><br>вот тут мне не понятно: с одной стороны рутом на удаленный сервер нежелательно <br>предоставлять доступ по ssh (у нас он отключен). <br>С другой - вроде как надо.<br><br>вопрос: а можно ли обойти этот скользкий момент с помощью sudoers?<br><br>&gt; Дирвиш умеет бекапить только измененные файлы. Этим оно и отличается от полного<br>&gt; пофайлового бекапа. Если initial бэкап у нас занимал 4 часа, то<br>&gt; второй -- 20-30 минут.<br><br>если я правильно понимаю, то любая rsync-based утилита будет так работать, если без наворотов.<br>Да и вопрос о правах пользователя группы wheel на системные директории остается повисшим.<br>Пока чт https://ns.opennet.ru/openforum/vsluhforumID1/90026.html#8 Thu, 14 Oct 2010 03:25:14 GMT &gt;&gt; Не вижу проблемы со входом под рутом по ключу.<br>&gt;&gt; PermitRootLogin without-password или как-то так опция зовется, не помню, по памяти пишу.<br>&gt; Если я правильно понял, вы говорите о настройках sshd? можно поподробнее?<br><br> PermitRootLogin<br><br> Specifies whether the root can log in using ssh(1). The<br> argument must be yes, without-password, forced-<br> commands-only, or no. without-password means that root<br> cannot be authenticated using the "password" or<br> "keyboard-interactive" methods (see description of<br> KbdInteractiveAuthentication above). <br><br><br>&gt;&gt; Смотрю в сторону dirvish-а, как он организован....<br>&gt;&gt; В нем есть то, о чем я размышлял когда-то... В настоящее время<br>&gt;&gt; - bontmia, несколько "пропатченная", но pre и post скриптов еще не<br>&gt;&gt; изобрел. буду смотреть как сделан дирвиш.<br>&gt; да занятная штучка... вот только сомневаюсь подойдет ли она в моем случае...<br>&gt; Server находится в Питере, Backup в Новосибирске...<br><br>Дирвиш умеет б https://ns.opennet.ru/openforum/vsluhforumID1/90026.html#7 Thu, 14 Oct 2010 03:17:54 GMT &gt;&gt; А почему нельзя запускать не на Backup, а на Server что-нибудь типа<br>&gt;&gt; rsync -e ssh -ztr.... /data user@Backup:/data ?<br>&gt;&gt; Тогда вроде бы проблемы такой и не возникнет.<br>&gt; Потому что:<br>&gt; 1. Идеологически бэкап-задачи выполняются на резервном хосте. Да и продакшн сервер не<br>&gt; хотелось бы грузить лишним функционалом.<br>&gt; 2. организовано так, что Server - находится на арендуемом сервере у хостера.<br>&gt; Backup - в серверной, в офисе. Чтобы заставить Server отправлять бэкапы<br>&gt; на Backup, надо будет использовать нестандартные порты для работы rsync, ssh<br>&gt; (так как стандартые уже заняты). А лишние действия - они лишние.<br><br>Поддерживаю.<br><br>Любой бэкап -- это дырка в безопасности. Тут выгоднее делать pull (инициировать бекап с бекапного сервера). Да и не продакшен хосте держать ключи для доступа куда-то внутрь идеологически неверно. <br>Но можно и rsync-ом (over ssh+preshared keys) делать то-же самое.<br>rsync -zavHessh host:/fs /localdir/<br>Дирвиш еще умеет бекапить только измененные файлы и делать хардлинки на уже суще https://ns.opennet.ru/openforum/vsluhforumID1/90026.html#6 Thu, 14 Oct 2010 03:10:19 GMT &gt; Не вижу проблемы со входом под рутом по ключу.<br>&gt; PermitRootLogin without-password или как-то так опция зовется, не помню, по памяти пишу.<br><br>Если я правильно понял, вы говорите о настройках sshd? можно поподробнее?<br><br>&gt; Смотрю в сторону dirvish-а, как он организован....<br>&gt; В нем есть то, о чем я размышлял когда-то... В настоящее время<br>&gt; - bontmia, несколько "пропатченная", но pre и post скриптов еще не<br>&gt; изобрел. буду смотреть как сделан дирвиш.<br><br>да занятная штучка... вот только сомневаюсь подойдет ли она в моем случае...<br>Server находится в Питере, Backup в Новосибирске...<br> https://ns.opennet.ru/openforum/vsluhforumID1/90026.html#5 Thu, 14 Oct 2010 03:07:44 GMT &gt; А почему нельзя запускать не на Backup, а на Server что-нибудь типа<br>&gt; rsync -e ssh -ztr.... /data user@Backup:/data ?<br>&gt; Тогда вроде бы проблемы такой и не возникнет.<br><br>Потому что:<br>1. Идеологически бэкап-задачи выполняются на резервном хосте. Да и продакшн сервер не хотелось бы грузить лишним функционалом.<br>2. организовано так, что Server - находится на арендуемом сервере у хостера. Backup - в серверной, в офисе. Чтобы заставить Server отправлять бэкапы на Backup, надо будет использовать нестандартные порты для работы rsync, ssh (так как стандартые уже заняты). А лишние действия - они лишние.<br><br><br>