GNU Screen и bash-скрипты: непонятности

юзай tmux :)

юзай tmux

Чтобы костыли стали с неопреновыми наконечниками?

Спасибо! Не знал про существование tmux.
Но всё же хотелось бы узнать, ЧЯДНТ со скрином, хотя бы из любопытства.

чё с tmux не так? Возможностей больше, управление гораздо более очевидное, недостаток я пока только один заметил: не умеет различные кодировки для разных окон. Но мне это уже давно не актуально.

К тмуксу претензий никаких нет. Просто не покидает ощущение, что ТС сильно окольным путем решает проблему.

Ну, собственно могу изложить проблему.

Есть два сервера, например С1 и С2.
На С1 по крону срабатывает скрипт - делание бекапа.
Делается бекап в виде zip-файла, кладётся в расшаренную по http-папку.
После этого С1 выполняет вегет: http://C2/downloadbackup.php
На С2 выполняется downloadbackup.php (суть его - просто запустить баш-скрипт)
Он создаёт сессию скрина (чтоб я мог зайти и поглядеть сколько % скачано, по идее, это необязательно) и в ней вегетом же выкачивает бекап с С1.
После этого вегетом делает http://C1/removebackup.php
На С1 выполняется removebackup.php, который удаляет архив с бекапом.

Если предложите менее костыльное решение, буду только рад.
Суть - заставить С2 скачать backup.zip с С1 и потом чтоб С1 удалил backup.zip.

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

По-моему, любой другой способ будет менее костыльным. Rsync, ftp, scp, smb. Тысячи их.

А какая разница по какому протоколу гонять файлы? Тем более что http уже есть, а всё остальное ещё надо настраивать непонятно ради чего.
Кроме того, ну, хорошо, стал я, например, скачивать вторым сервером с первого по ftp. Стало менее костыльно?

> Кроме того, ну, хорошо, стал я, например, скачивать вторым сервером с первого по ftp.

Зачем скачивать? ftp, в отличии от http, может нормально закачивать большие файлы. В случае с фтп не нужно будет такой черезжопной синхронизации между серверами.

1) man ssh-keygen; создать ключи на C2
2) скопировать публичный ключ на C1
3) по крону на C2 запускать:

ssh user@C1 'zip /path/to/zipfile.zip ...'
scp user@C1:/path/to/zipfile.zip
ssh user@C1 'rm /path/to/zipfile.zip'

вместо scp можно и wget с сохранением логов в определённом месте - тоже будет видно, сколько процентов скачалось

Спасибо! Вот это дельно.
Но не станет ли расшаривание ssh-доступа на С2 потенциальной дырой в безопасности?

Я имел в виду, в случае чего, с С2 можно будет творить что взбредёт и на С1.

> Я имел в виду, в случае чего, с С2 можно будет творить что взбредёт и на С1.

ну если нет доверия между хостами, то всегда можно усилить безопасность через SeLinux, LIDS, AppArmor. Либо просто написать свой исполняемый файл, который будет принимать ровно два аргумента: archive и remove; указать этот файл в качестве login shell'а для пользователя. По этим командам будет собран zip-файл в определённом месте либо удалён из этого определённого места. Тогда вызова на C2 будут примерно такими:

ssh user@C1 'archive'
scp user@C1:/path/to/zipfile.zip
ssh user@C1 'remove'

Я такое не делал, но если бы стояла подобная задача (и под рукой не было бы SeLinux), то сделал бы примерно такой свой 'shell' :)

да, scp вероятно при самопальном шелле не сработает. wget вместо него.

Для каждой сессии screen создаёт unix-сокет (файл). Посмотрите, может у вас прав на него не хватает.

Всем спасибо, наладил! Самое простое оказалось сделать всё же через FTP. Не сразу догнал, что заливать по FTP очень удобно.
Поднял proftpd на С2 и создал отдельный FTP-аккаунт только для этих целей. Проверил - всё делает как надо, за собой «подтирает» архив.
Осталось только в кронтаб прописать.