Re: Как переносить настройки / мигрировать на другой сервер?
On 2016-02-06, Sergey B Kirpichev wrote:
> On Sat, Feb 06, 2016 at 05:32:02PM +0200, Oleksandr Gavenko wrote:
>> * Иерархию /srv/ можно было перенести rsync.
>> Проблему вижу в перенесении прав доступа. Некторых пользователей отдельно
>> создавал и давал каталог...
>
> В принципе, rsync, запущаемый (от рута) б-м стандартным образом (ключик -a,
> например) должен был перенести в точности все права доступа, uid/gid файлов.
>
>> А если делает - то он должен запускаться от root. Не ясно как пользоваться
>> от root.
>
> А что конкретно неясно?
>
>> При обновлении с Debian 7.0 до 8.0 - я выключил возможность ssh
>> для root: rsync -e 'ssh -l root' user@vps/...
>
> А sudo вы тоже выключили?
>
> Как-то так вот:
> rsync -av --rsync-path="sudo rsync" ...
>
> Ну а если лень разбираться - просто включите временно "ssh для root" взад.
>
Итого вот рабочие команды:
$ ssh user@vps "sudo tar cf - /etc" | sudo tar xf - -C ~/tmp
$ sudo rsync -av --rsync-path="sudo rsync" --rsh=ssh user@vps:/etc/ ~/tmp/etc/
С обоих концов :NOPASSWD для sudo. Без этого не представляю как ввести пароль
в sudo на удаленный хост.
Вспомнил, когда-то спрашивал:
https://lists.debian.org/debian-russian/2012/11/msg00131.html
Как реализован "in place upgrade" в Дебиан?
Если на рабочей системе менять /etc, то желательно:
* к rsync НЕ добавлять ключик --inplace:
--inplace
This option changes how rsync transfers a file when its data needs to
be updated: instead of the default method of creating a new copy of
the file and moving it into place when it is complete, rsync instead
writes the updated data directly to the destination file.
* к tar добавить опцию
-U, --unlink-first
remove each file prior to extracting over it
Как то не очень сильно документация на утилиты осчещает вопрос извлечения
файлов которые in-use.
Стоит учесть также метаинформацию о правах:
* Для rsync:
-p, --perms
-A, --acls
-X, --xattrs
* У GNU tar нет поддержки ACL, только:
-p, --preserve-permissions, --same-permissions
Потому нужно играться с bsdtar. Или до запаковки:
sudo getfacl -R /srv > srv.acl
и после распаковки:
sudo setfacl --restore=srv.acl
>> rsync же не делает adduser?
>
> adduser можете ручками потом сделать. Или тупо скопировать (sed/awk)
> нестандартные вещи из passwd, shadow - так легше не перепутать
> uid/gid'ы пользователей и групп.
>
На 2 разных хостах (чистая VPS и многолетняя домашняя):
bash# sudo find /etc -type d -print0 | xargs -0 -n 100 sudo stat -c "%U" | sort -u
postgres
root
bash# sudo find /etc -type d -print0 | xargs -0 -n 100 sudo stat -c "%G" | sort -u
dip
list
lp
postgres
root
ssl-cert
tomcat7
user
Согласно /usr/share/doc/debian-policy/policy.txt.gz:
Some user ids (UIDs) and group ids (GIDs) are reserved globally for
use by certain packages. Because some packages need to include files
which are owned by these users or groups, or need the ids compiled
into binaries, these ids must be used on any Debian system only for
the purpose for which they are allocated.
The UID and GID numbers are divided into classes as follows:
Packages other than `base-passwd' must not modify `/etc/passwd',
`/etc/shadow', `/etc/group' or `/etc/gshadow'.
0-99:
Globally allocated by the Debian project, the same on every
Debian system. These ids will appear in the `passwd' and `group'
files of all Debian systems, new ids in this range being added
automatically as the `base-passwd' package is updated.
Packages which need a single statically allocated uid or gid
should use one of these; their maintainers should ask the
`base-passwd' maintainer for ids.
"base-passwd" содержит предопределенные группы и пользователей:
/usr/share/base-passwd/group.master
/usr/share/base-passwd/passwd.master
Т.е. все системные группы и пользователи в Debian - будут иметь одинаковые
соответствия между номерами / именами.
Может показаться что на чистом Debian не буде сторонних польщователей/групп.
Но даже у моей досашней машинки - пользователь mysql / tomcat7 - нестандартный
и от порядка установки пакетов будет другой номер у пользователя ((
Аналогично можно пройтись по /srv
bash# sudo find /srv/ -type d -print0 | xargs -0 -n 100 sudo stat -c "%U" | sort -u
mysql
user
www-data
bash# sudo find /etc/ -type d -print0 | xargs -0 -n 100 sudo stat -c "%G" | sort -u
mysql
user
www-data
Потому на голую систему следует предварительно собрать нужные группы/пользователей и:
$ addgroup --gid $ID $NAME
$ adduser --uid $ID -gid $ID $NAME
А затем можно уже и rsync / tar. Иначе придется либо менять права на файлах:
$ sudo find /srv -gid 110 -print0 | sudo xargs -0 -n 100 chgrp mysql
Либо ковырять номерки в /etc/passwd и /etc/groups.
>> * Иерархию /etc/ стремно переносить по rsync.
>
> А что тут может быть стремного? (Пакетики, конечно, установить надо
> нужные сперва.) Разве вот IP поменялись, но это уж вы там просто
> разберитесь куда их напонаписали. Теоретически, кроме /etc/network они
> особо нигде не должны быть.
>
Выше я написал возможные проблемы с не-дефолтными групами/пользователями.
Конешно /etc/network.
Понятно что /etc/shadow тоже будет другой. И возможно другие файлы с паролями.
Понимание проблемы пришло только чейчас.
И еще нужно собрать версии пакетов:
$ aptitude search --disable-columns -F "%p %v" ~i >pkg.list
и установить точно такие (или прято/обратно совместимые - но в сотнях пакетов
не разберешся - потому точно такие). Как установить пакет по именя - я
понимаю, а как всесте с версией - не очень. Итого дабовая система должна быть
на стабильной ветке (по крайней мере не rolling-релизы типа testing/sid).
================================================================
Пока такой инфой располагаю.
--
http://defun.work/
Reply to: