Отправить снимок ZFS на удаленную машину
Редактировать :
Этот вопрос первоначально был сосредоточен на проблеме изменения направления соединения ssh при передаче, но я понял, что это не было причиной проблем. Я столкнулся, поэтому я упростил его.
Хотя документация Ubuntu из zfs обсуждает только отправку-получение через файл, такой подход невозможен для больших наборов данных. Документация Oracle рекомендует использовать ssh в конвейере, т. Е.
# zfs send tank/dana@snap1 | ssh sys2 zfs recv newtank/dana
Однако, пытаясь выполнить эту процедуру с созданным мной тестовым набором данных, содержащим один файл 10M, я столкнуться с проблемой реализации Ubuntu Xenial zfs (ZFS-on-Linux), требующей привилегий суперпользователя (на принимающей стороне):
$ sudo -i
# zfs send tank/dana@snap1 | ssh sys2 zfs recv newtank/dana
Permission denied the ZFS utilities must be run as root.
warning: cannot send 'tank/dana@snap1': Broken pipe
Я попытался решить эту проблему, передав ssh Флаг -t, т. Е. Выдача
# zfs send tank/dana@snap1 | ssh -t sys2 "sudo zfs recv newtank/dana"
, который завершается ошибкой с
Pseudo-terminal will not be allocated because stdin is not a terminal.
до запроса учетных данных sys2, после чего принимаются следующие сообщения:
sudo: no tty present and no askpass program specified
warning: cannot send 'tank/dana@snap1': Broken pipe
Попытка выполнить тестовую передачу с использованием другого направления с использованием
# ssh -t sys2 "sudo zfs send newtank/dana2@snap1" | zfs recv tank/dana2
просто зависает после запроса учетных данных sys2. (Напомним, что каждый снимок содержит только 10M файл, поэтому я считаю, что на самом деле он ничего не пытается сделать, но я не уверен, почему он зависает.)
2 ответа
sudo zfs send tank/dana@snap1 | ssh sys2Root zfs recv newtank/dana
, где sys2root является записью в ~/.ssh/config, т.е.:
host sys2Root
HostName 192.168.0.x
User root
-
1You' ре не неправильно [приблизительно 110] являющиеся опасным, однако существует меры защиты, которые помогают препятствовать тому, чтобы Вы удалили свою файловую систему, и необходимо было бы быть активно злонамеренными для обеспечения надлежащих аргументов, необходимых для стирания каталога корневой системы. – Thomas Ward♦ 29 September 2017 в 11:44
Учитывая, что обычно считается плохой идеей разрешать вход root через ssh, альтернативой может быть то, что целевой пользователь, скажем foo, будет sudoer на целевом хосте, назовите его remote . Кроме того, вход без пароля является плюсом.
Тогда будет достаточно следующей команды
$ sudo zfs send <dataset1> | ssh foo@remote "sudo zfs recv <dataset2>"