вот бы что-нить вроде "gear --hasher -- hsh user@remotehost:~/hasher -v" сделать, что б tar создавался локально, а потом вместе со спеком передавался на удаленную машину и там компилился, а результат забирался обратно
причем еще хотелось бы, чтобы как можно меньший обьем данных между машинами ездил (отсутствие компрессии + rsync)?
Подумаем ...
nbr - пользователь удаленной машины hasher64 - имя удаленной машины bat.sh: === cut here == scp $1 nbr@hasher64:/home/nbr/tarfile.tar && ssh -l nbr hasher64 hsh -v /home/nbr/hasher /home/nbr/tarfile.tar ssh -l nbr rm -f /home/nbr/tarfile.tar == cut here == и вызов gear --hasher -- ./bat.sh более-менее решают проблему
(In reply to comment #3) > === cut here == > scp $1 nbr@hasher64:/home/nbr/tarfile.tar && ssh -l nbr hasher64 hsh -v > /home/nbr/hasher /home/nbr/tarfile.tar > ssh -l nbr rm -f /home/nbr/tarfile.tar > == cut here == тогда INVALID ?
Ну, доделать и дополнительным скриптом в gear положить - было бы полезно.
(In reply to comment #5) > Ну, доделать и дополнительным скриптом в gear положить - было бы полезно. Можно положить в пакет пример.
Created attachment 2341 [details] hsh-remote Вот такая утилита у меня нарисовалась. Вас она устраивает ?
$opts и $args плохо передаются. Посмотри на gear-hsh-build. При этом немного изменится синтаксис: hsh-remote [--hsh-remote-opts...] -- [--hasher-opts...] package
(In reply to comment #8) > $opts и $args плохо передаются. Посмотри на gear-hsh-build. При этом немного > изменится синтаксис: > > hsh-remote [--hsh-remote-opts...] -- [--hasher-opts...] package Я знаю такой подход, но неприменим из-за --repo*. Эту группу опций нужно исключать.
Created attachment 2342 [details] hsh-remote version 2 Вот более корректный вариант
Created attachment 2343 [details] hsh-remote version 3 Вот теперь, мне кажется, всё по правилам получилось. review? (ldv)
Created attachment 2344 [details] cleanup-fix.patch
http://git.altlinux.org/people/legion/packages/gear.git?p=gear.git;a=commit;h=f328a730d4cd6edf3b4fce0273e21b13eefee530
(In reply to comment #13) > http://git.altlinux.org/people/legion/packages/gear.git?p=gear.git;a=commit;h=f328a730d4cd6edf3b4fce0273e21b13eefee530 Только не healper а helper :) Большое спасибо за полезную фичу!
(In reply to comment #13) > http://git.altlinux.org/people/legion/packages/gear.git?p=gear.git;a=commit;h=f328a730d4cd6edf3b4fce0273e21b13eefee530 В таком виде это действительно FR на пакет hasher. :)
(In reply to comment #15) > В таком виде это действительно FR на пакет hasher. :) Я сознательно поместил его именно в gear. Сейчас gear может работать без hasher и не имеет на него зависимости. Я хотел добавить возможность работать с удалённым "hasher сервером" без установки hasher к себе на локальную машину. Если коротко, то мне кажется неправильно требовать установки hasher для получения возможности его удалённого запуска.
Рука дрогнула ... случайно закрыл.
(In reply to comment #14) > Только не healper а helper :) Бессоница дала о себе знать только под утро :( > Большое спасибо за полезную фичу! Мне эта фича самому очень понравилась.
(In reply to comment #16) > Если коротко, то мне кажется неправильно требовать установки hasher для > получения возможности его удалённого запуска. В таком случае, мне кажется противоестественным требовать установки пакета gear для получения возможности удалённого запуска hasher без использования gear. Из того, что удобно выполнять gear --ha -- hsh-remote ещё не следует того, что hsh-remote логично помещать в один пакет с gear. Что будем делать? :)
(In reply to comment #19) > Что будем делать? :) Ух. Я сделал утилиту, я высказал соображения об месте её размещения. Куда её будет помещать мантейнер ... :)
(In reply to comment #19) > Что будем делать? :) hasher-utils? :)
(In reply to comment #21) > hasher-utils? :) Мне кажется, что эта бага уже исправлена. См. gear-remote-hsh(1) в gear.
(In reply to comment #22) > Мне кажется, что эта бага уже исправлена. См. gear-remote-hsh(1) в gear. Исправлено.
