Re: tmux на локальной машине
*** Ivan Shmakov [2017-07-16 09:25]:
> Что понимается под «vi-like клавишами для поиска»? Поскольку
> Screen вроде бы умеет как «наращиваемый» Emacs-like поиск
> (C-r, C-s), так и «традиционный» (/, ?). Равно как и hjkl.
В дополнении к "/", "?" ещё клавиши типа "%", "{", "}", "f", итд. Хотя
это уже скорее просто перемещение, а не поиск.
> Я так понимаю, здесь запускается окно с Shell, в которое затем
> вводится $ su -? Честно говоря, я обычно $ screen 10 su -, без
> каких-либо промежуточных интерпретаторов.
Плюс оно бъётся по pane-ам, переходит в директории. Когда-то я сразу и
mutt и mocp запускал.
>$ cat < setup-slogin.screen
Тут вроде всё выглядит так, что запускается только ровно одна команда? В
tmux-е я делаю именно вставку каких-либо символов/клавиш и прочего? На
самом деле кроме "su -" ещё и его пароль вставляется (загруженный с
зашифрованного диска -- мол если диск подключен, то это уж точно
авторизованный пользователь).
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: tmux на локальной машине
*** Tim Sattarov [2017-07-16 04:59]: >У меня тоже был вопрос про разницу в предпочтениях, я в своё время начал >пользоваться screen и как то с tmux после не пошло... Я когда-то пользовался screen, но всегда, мягко говоря, ненавидел все их сочетания клавиш и вообще подходы к конфигурации. А с tmux-ом вздохнул спокойно. Но это личные предпочтения. >На что только люди не идут, чтобы не пользоваться docker-compose >(Продолжаю мощные вбросы :) ) Да уж, учитывая то, что я когда-то владел boycottdocker.org доменом :-) -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: tmux на локальной машине
Опять же, не знаю как в screen, но в tmux я активно использую штуку когда по нажатию сочетания клавиш, он мне во временный файл сохраняет содержимое текущего pane, открывает ещё один pane, а в нём команду натравленную на временный файл: bind-key u capture-pane -J \; save-buffer /tmp/tmux-buffer \; split-window 'urlview /tmp/tmux-buffer' \; delete-buffer bind-key y capture-pane -J \; save-buffer /tmp/tmux-buffer \; split-window 'vim /tmp/tmux-buffer' \; delete-buffer например я в терминале вижу ссылку и мне хочется её открыть в броузере. Нажимаю Prefix-u и мне открывается новое окно (pane) в котором urlview позволяет выбрать ссылку и нажать enter, закрыв это окно. Или хочется как-то вырезать/обработать текст который вижу на экране, но удобно сразу же в текстовом редакторе -- нажимаю Prefix-y и у меня новый pane, в котором vim с уже вставленным содержанием pane на котором я нажал сочетание. Видел use-case у пользователя с Gvim-ом: обычно всякие сообщения об ошибках компиляции в формате "filename:lineno:colno". Так вот, опять же, простое сочетание запускает sed/whatever который готовит вывод для диалога предлагающего открыть обнаруженные на экране строчки, выбрав нужную, он посылает команду ":e filename +lineno" в Gvim (он же, как бы, клиент-серверный). У меня когда-то был use-case чтобы всякие "#666" открывать в броузере как ссылку для Redmine. Я точно знаю что выбор ссылок или вот что-то сделать с отпарсенными значениями можно и в urxvt, в котором на Perl можно скриптовать, но я не понимаю зачем. Наверняка в любой системе есть screen/tmux, так почему бы это не сделать в них? Терминал может поменяться от системы к системе, а tmux всегда будет точно такой же родной с собой. Лично я вот люблю не монстров типа gnome-terminal, а что-то очень простое, suckless, типа st (st.suckless.org). А без tmux/whatever все эти хотелки требуют прожорливых огромных монстров терминалов. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: tmux на локальной машине
> Sergey Matveev writes:
> *** Ivan Shmakov [2017-07-16 09:25]:
>> Что понимается под «vi-like клавишами для поиска»? Поскольку Screen
>> вроде бы умеет как «наращиваемый» Emacs-like поиск (C-r, C-s), так и
>> «традиционный» (/, ?). Равно как и hjkl.
> В дополнении к "/", "?" ещё клавиши типа "%", "{", "}", "f", итд.
> Хотя это уже скорее просто перемещение, а не поиск.
Команды перемещения у Screen, разумеется, тоже есть; Less-like,
если угодно; % — в начало буфера; G — в конец; etc.
Мне не приходилось участвовать в разработке GNU Screen, но не
вижу причин считать, что предложения «добавить Vi-клавиш» будут
заведомо отвергнуты разработчиками. Разве что из соображений
«обратной совместимости».
>> Я так понимаю, здесь запускается окно с Shell, в которое затем
>> вводится $ su -? Честно говоря, я обычно $ screen 10 su -, без
>> каких-либо промежуточных интерпретаторов.
> Плюс оно бьётся по pane-ам,
Не вижу препятствий для неинтерактивного использования split и в
Screen. Я, однако, редко использую «многооконность» самого
Screen (куда чаще — запущенного в нем Emacs.)
> переходит в директории.
Я бы решил это так:
### my.screen
chdir /foo
screen -t foo 3
chdir /bar
screen -t bar 8
chdir /baz
screen -t baz 17 qux --quux
chdir
### my.screen ends here
> Когда-то я сразу и mutt и mocp запускал.
Это может составить какую-либо проблему для Screen?
>> $ cat < setup-slogin.screen
> Тут вроде всё выглядит так, что запускается только ровно одна
> команда?
Именно. Никакой «имитации интерактивности» — исключительно
«штатные» интерфейсы.
В общем случае, это кажется куда как более надежным. Мало ли о
чем запущенное приложение захочет спросить пользователя сразу
после запуска? SSH-клиент, например, может предупреждение о
возможном MitM выдать — и попросить подтвердить доступ. Или, в
отсутствие ключа у агента — пароль спросить.
> В tmux-е я делаю именно вставку каких-либо символов/клавиш и прочего?
? Это вопрос?
> На самом деле кроме "su -" ещё и его пароль вставляется (загруженный
> с зашифрованного диска — мол если диск подключен, то это уж точно
> авторизованный пользователь).
… Любопытно, а умеет ли sudo(8) учитывать факт наличия
произвольных файлов при выполнении авторизации?
--
FSF associate member #7257 58F8 0F47 53F5 2EB2 F6A5 8916 3013 B6A0 230E 334A
Re: tmux на локальной машине
*** Ivan Shmakov [2017-07-16 11:49]: > Команды перемещения у Screen, разумеется, тоже есть; Less-like, > если угодно; % — в начало буфера; G — в конец; etc. > > Мне не приходилось участвовать в разработке GNU Screen, но не > вижу причин считать, что предложения «добавить Vi-клавиш» будут > заведомо отвергнуты разработчиками. Разве что из соображений > «обратной совместимости». Повторюсь: тут вопрос субъективный похоже. Я не вижу смысла (для себя) что-то добавлять или как-то улучшать GNU screen когда есть Tmux. Как минимум я наслышан о качестве кода последнего, но не о качестве первого. Ища информация по поводу screen vs tmux, постоянно натыкался на то что в tmux-е раньше стало всё хорошо с Unicode-ом, итд, итд. Я не считаю screen плохим, он имеет право на существование, но если есть выбор то мой падёт не на него чисто потому-что многое субъективное не нравится. > > Когда-то я сразу и mutt и mocp запускал. > Это может составить какую-либо проблему для Screen? Насколько понимаю, если запустить screen mutt, то после выхода из mutt-а и screen завершит свою работу? Очень часто проще выйти из mutt чтобы например зайти в default почтовый ящик. Поэтому тут нужно именно shell запустить, а в нём как бы вызвать mutt команду, чтобы при выходе из неё я снова попал в shell. >chdir /foo >screen -t foo 3 >[...] > Именно. Никакой «имитации интерактивности» — исключительно > «штатные» интерфейсы. > > В общем случае, это кажется куда как более надежным. Мало ли о > чем запущенное приложение захочет спросить пользователя сразу > после запуска? SSH-клиент, например, может предупреждение о > возможном MitM выдать — и попросить подтвердить доступ. Или, в > отсутствие ключа у агента — пароль спросить. Вот именно под этим я и подразумевал что tmux удобнее (субъективно). Отчасти я согласен что это *потенциально* менее безопаснее -- но я считаю что нечего запускать ПО которому не доверяете, от которого ждёте такого подвоха. И когда речь заходит о "человеческом" удобстве, то тут не всегда до безопасности. Я хочу *именно*, как вы выразились, имитации интерактивности -- я хочу буквально заменить себя, причём меньшей болью. Я согласен что многое можно заменить shell-скриптами, то если я вот каждый раз когда занимаюсь проектом XXX делаю: cd ~/work/xxx venv workon xxx cat todo.txt export PS="..." то исключительно удобно вот как всё написано -- взять и обернуть в tmux команды, без создания shell-скрипта который правильно включит virtualenv-ы, выставит переменные окружения, итд. > > В tmux-е я делаю именно вставку каких-либо символов/клавиш и прочего? > ? Это вопрос? Не, это я нечаянно поставил вопросительный знак. > > На самом деле кроме "su -" ещё и его пароль вставляется (загруженный > > с зашифрованного диска — мол если диск подключен, то это уж точно > > авторизованный пользователь). > > … Любопытно, а умеет ли sudo(8) учитывать факт наличия > произвольных файлов при выполнении авторизации? Хочу заметить что пароль вставляется "имитацией интерактивности" -- то есть tmux туда пихает сам пароль, прочитанный из файла, дальше лупит enter. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: tmux на локальной машине
> Sergey Matveev writes: > *** Ivan Shmakov [2017-07-16 11:49]: >> Команды перемещения у Screen, разумеется, тоже есть; Less-like, если >> угодно; % — в начало буфера; G — в конец; etc. >> Мне не приходилось участвовать в разработке GNU Screen, но не вижу >> причин считать, что предложения «добавить Vi-клавиш» будут заведомо >> отвергнуты разработчиками. Разве что из соображений «обратной >> совместимости». > Повторюсь: тут вопрос субъективный похоже. Я не вижу смысла (для > себя) что-то добавлять или как-то улучшать GNU screen когда есть > Tmux. Не исключено, что кто-то из читающих рассылку заинтересуется. Вопрос подписчиков был ведь в том, чтобы сравнить Screen и Tmux? Вот мы этим и занимаемся, не так ли? Сам я, единолично, сравнить их не могу, коль скоро имею опыт использования лишь одного, и ознакомление с другим не является для меня, на текущий момент, приоритетной задачей. > Как минимум я наслышан о качестве кода последнего, но не о качестве > первого. Вполне возможно. AIUI, GNU Screen в этом году празднует свое тридцатилетие. За такой срок в коде имеют свойство накапливаться «особенности.» Если этому активно не противодействовать, во всяком случае. > Ища информация по поводу screen vs tmux, постоянно натыкался на то > что в tmux-е раньше стало всё хорошо с Unicode-ом, итд, итд. А вот это слегка сомнительно. Tmux появился в 2007 г., и на тот момент, IIRC, GNU Screen у меня с UTF-8 работал вполне адекватно. Впрочем, те же символы двойной ширины мне были без особой надобности, так что… […] > Насколько понимаю, если запустить screen mutt, то после выхода из > mutt-а и screen завершит свою работу? Если запустить Screen и в нем создать ($ screen mutt) окно с Mutt, то по завершению Mutt окно действительно будет закрыто. Или станет «зомби» — в зависимости от настроек. > Очень часто проще выйти из mutt чтобы например зайти в default > почтовый ящик. Поэтому тут нужно именно shell запустить, а в нём как > бы вызвать mutt команду, чтобы при выходе из неё я снова попал в > shell. Э, нет, мне проще запустить два Mutt — каждый в своем окне. $ ps -o pid,lstart,cmd -C mutt PID STARTED CMD 12148 Wed Jul 5 04:40:13 2017 mutt XXX 15184 Sun Jul 2 12:26:51 2017 mutt YYY […] >> Никакой «имитации интерактивности» — исключительно «штатные» >> интерфейсы. >> В общем случае, это кажется куда как более надежным. Мало ли о чем >> запущенное приложение захочет спросить пользователя сразу после >> запуска? SSH-клиент, например, может предупреждение о возможном >> MitM выдать — и попросить подтвердить доступ. Или, в отсутствие >> ключа у агента — пароль спросить. > Вот именно под этим я и подразумевал что tmux удобнее (субъективно). На самом деле, здесь нет различия между Screen и Tmux: первый также имеет команду (stuff) для имитации ввода в окно. E. g.: ### my.screen ## Usage: $ screen -X source my.screen screen -t mutt 27 stuff mutt\n ### my.screen ends here Другое дело, что я этой возможностью пользуюсь крайне редко (если вообще пользуюсь), и если у Screen есть дефекты в ее реализации — я с ними не сталкивался. > Отчасти я согласен что это *потенциально* менее безопаснее — но я > считаю что нечего запускать ПО которому не доверяете, от которого > ждёте такого подвоха. Причем здесь доверие? Я уже привел один пример: $ ssh REMOTE может дать доступ к Shell на удаленной машине; а может — предупреждение о том, что ключ REMOTE не соответствует сохраненному в ~/.ssh/known_hosts. Ни stuff, ни set-buffer + paste-buffer адекватно эту ситуацию обработать, IIUC, не позволяют. Еще одна возможная ситуация — «внезапное» изменение умолчаний. Так, традиционно, Home и End в Emacs перемещали точку в начало и конец буфера, соответственно. Затем разработчики решили «быть как все» и с выходом 21.1 в 2001 г. эти клавиши были по умолчанию переназначены на перемещение в начало и конец /строки./ При непосредственном взаимодействии с программой я могу надеяться уследить за отличной от ожидаемой реакцией и либо начать выяснять причины, либо «подстроиться». Из кода? Я определенно предпочту более стабильные «командные» интерфейсы. Вроде $ emacs --eval='(beginning-of-buffer)', или $ bash --rcfile=XXX. > И когда речь заходит о «человеческом» удобстве, то тут не всегда до > безопасности. Я хочу *именно*, как вы выразились, имитации > интерактивности — я хочу буквально заменить себя, причём меньшей > болью. Я согласен что многое можно заменить shell-скриптами, то если > я вот каждый раз когда занимаюсь проектом XXX делаю: > cd ~/work/xxx > venv > workon xxx > cat todo.txt > export PS="..." > то исключительно удобно
Re: tmux на локальной машине
*** Ivan Shmakov [2017-07-16 18:04]: > Причем здесь доверие? Я уже привел один пример: $ ssh REMOTE > может дать доступ к Shell на удаленной машине; а может — > предупреждение о том, что ключ REMOTE не соответствует > сохраненному в ~/.ssh/known_hosts. Ни stuff, ни set-buffer + > paste-buffer адекватно эту ситуацию обработать, IIUC, не > позволяют. Тогда я не так понял что вы имели в виду прежде. Да, хороший пример. Просто никогда такие "опасные" команды в tmux не автоматизировал. > Еще одна возможная ситуация — «внезапное» изменение умолчаний. Ну для меня это "болезнь" людей которые любят bleeding edge. Обновляться надо аккуратно, читая changelog-и софта. Хотя по ним не всегда понятно затронет ли оно "меня" или нет. В любом случае всё это настолько редкие для меня ситуации, что о них даже не собираюсь думать. > А если так, то в чем преимущество set-buffer + paste-buffer > перед, например, $ bash --rcfile=? (Предполагая, что > используется именно Bash. Думаю, иные реализации Shell > предоставляют схожие возможности.) (bash не использую, но это мелочи) Тут rcfile будет для одного интерпретатора. Если мне нужно открыть несколько окон (pane-ов в tmux) и в каждом из них что-то сделать своё, не одинаковое для всех окон, то тогда нужно написать несколько rc-файлов. Вместо ровно одного, где всё сконсолидировано -- нужно иметь и скрипт с tmux/screen обёрткой и отдельные rc-файлы. Да, можно их поместить и в один, который их сохранит во временные файлы, натравливая на них shell, но... это уже не удобно, это уже костыли. Мне надо думать как делать --rcfile, а мне хочется просто ручные действия "заскриптовать". > /Цель/ работы данного кода, как я ее понял, — дать пользователю > root-доступ, если «подключен зашифрованный диск». Нет, просто ввести "su -" и пароль взятый с диска. Если пароля нет, то он введёт пустоту и su меня пошлёт. Просто ввести su и пароль -- мне не надо никаких проверок. > Я не вижу причины, по которой некий «шлюз привилегий» не может > проверить факт /наличия/ файла — и дать root-доступ без > необходимости ввода какого-либо пароля. (Или хранения оного.) Для этого мне надо открыть документацию su/sudo/doas/whatever и смотреть может ли он это сделать. Мне этого не надо -- мне надо просто повторить мои ручные действия. Есть разница между "делать всё правильно" и сделать всё очень быстро, наколеночные макросы и простые скрипты которые экономят время, пускай даже которые упадут или не сработают. Время настройки автоматически запускаемого рабочего окружения с "правильными" подходами в виде rc-файлов, проверок на ошибки и прочего существенно больше чем просто сказать что надо интерактивно ввести. Если что-то пошло не так, то проще поправить скрипт. Тут точно так же как при работе в Vim редакторе: не всегда "делать правильно" эффективно по времени -- иногда надо делать менее эффективно, но зато с меньшими усилиями, если что, если например макрос "испорчен", то с нуля его повторить. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: tmux на локальной машине
On Sun, 16 Jul 2017 18:24:27 +0300 Sergey Matveev wrote: > *** Ivan Shmakov [2017-07-16 18:04]: > > Причем здесь доверие? Я уже привел один пример: $ ssh REMOTE > > может дать доступ к Shell на удаленной машине; а может — > > предупреждение о том, что ключ REMOTE не соответствует > > сохраненному в ~/.ssh/known_hosts. Ни stuff, ни set-buffer + > > paste-buffer адекватно эту ситуацию обработать, IIUC, не > > позволяют. > > Тогда я не так понял что вы имели в виду прежде. Да, хороший пример. > Просто никогда такие "опасные" команды в tmux не автоматизировал. > Опасной может быть даже команда cd. Когда-то давно один мой знакоймый налетел на такую ситуацию: У него был некоторый скрипт, который перегенерировал некоторое дерево каталогов. Скрипт начиланся с cd something; rm -rf * Вот это something было расположено в его $HOME и являлось симлинком на каталог на втором физическом диске (не помню уж куда этот диск был смонтирован. На /srv какой-нибудь). Скрипт запускался по крону. И вот однажды этот большой диск немножко умер. Поскольку это был сервер, на нем как могли переконфигуировали сервисы и подняли с одним диском. Про этот скрипт, бывший частным делом одного из сотрудников компании, который в офисе в момент неприятности не случился, естественно забыли. Скрипт запустился, перейти по висячему симлинку не смог и выполнил rm -rf прямо в $HOME этого товарища. Мораль - всегда проверяйте exit code команды cd, а лучше в начале любого скрипта пишите set -e. > Ну для меня это "болезнь" людей которые любят bleeding edge. > Обновляться надо аккуратно, читая changelog-и софта. Хотя по ним не > всегда понятно затронет ли оно "меня" или нет. В любом случае всё это > настолько редкие для меня ситуации, что о них даже не собираюсь > думать. Вот делаешь dist-upgrade, обновляются пара тысяч пакетов, а ты потом разбирайся, где оно поехало, а где нет. > Есть разница между "делать всё правильно" и сделать всё очень быстро, > наколеночные макросы и простые скрипты которые экономят время, пускай > даже которые упадут или не сработают. Время настройки автоматически Вот нужно делать даже наколеночные скрипты правильно. Чтобы они упали, не успев навредить.
зеркальный бэкап ZFS
Hi Вопрос адресован к тем, кто давно работает с ZFS (наверное, неважно, на какой платформе) и хорошо в ней разбирается. Просьба оценить (не)жизнеспособность такого экстравагантного способа бэкапа пула, состоящего из одного диска: 1) в первый раз подсоединяем бэкапный диск по USB и говорим zpool attach, в результате чего пул становится зеркальным и начинается ресилверинг основного диска на резервный; 2) дожидаемся окончания ресилвера, однократно делаем этот диск загрузочным, говорим ему zpool offline и отсоединяем его; пул остается в degraded state, но полностью работоспособный (в этом моменте я уверен не до конца, и хотелось бы выслушать его подтверждение или опровержение); 3) с определенной периодичностью подключаем резервный диск, говорим ему zpool online, дожидаемся окончания ресилвера, говорим zpool offline и отключаем обратно. Цель этих нетривиальных действий: если в процессе эксплуатации основного диска (когда резервный отключен) на нем возникнет checksum error, есть предположение (в котором я как раз совершенно не уверен), что когда вечером будет подключен резервный и окажется, что поврежденные данные есть в неповрежденном виде на резервном, zfs поправит их на основном, как он поступает в случае, если в момент обнаружения ошибки доступны оба зеркала. Если мое предположение неправильно, то, разумеется, такие неочевидные действия совершенно не нужны, достаточно zfs send (-I) -R. Но вдруг?..
Re: tmux на локальной машине
*** Victor Wagner [2017-07-16 21:00]: >Опасной может быть даже команда cd. >cd something; rm -rf * >Мораль - всегда проверяйте exit code команды cd, а лучше >в начале любого скрипта пишите set -e. Если делать скрипт, то я всеми руками за set -e. Опасна в вашем примере не команда cd, а rm -rf, а дальше уже действительно аккуратная проверка всего вокруг неё. >Вот нужно делать даже наколеночные скрипты правильно. Чтобы они упали, >не успев навредить. Если речь про tmux и screen, то повторюсь: нужно думать что писать, думать что автоматизируется путём интерактивного ввода. Не нужно делать из мухи слона и страдать из-за тучи shell файлов. Не нужно делать то, что может навредить. Если в tmux скриптах только cd, workon (virtualenv для python), export, su, запуск mutt/mocp/cmus/dnetc/whatever -- они не навредят, даже если что-то пошло не так. Не нужно сравнивать general purpose скрипты, и особые простые для запуска сред в tmux. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: зеркальный бэкап ZFS
Уравнение со слишком многими неизвестными и слишком большим количеством если. так с данными лучше не поступать - проще использовать рсинк, и лучше складывать на ехт4, ибо инструментов рекавери с зфс-а нет, а один раз я уже был в ситуации, когда очень бы они пригодились 16 июля 2017 г., 21:00 пользователь Alex Kicelew написал: > Hi > > Вопрос адресован к тем, кто давно работает с ZFS (наверное, неважно, на > какой платформе) и хорошо в ней разбирается. > > Просьба оценить (не)жизнеспособность такого экстравагантного способа > бэкапа пула, состоящего из одного диска: > > 1) в первый раз подсоединяем бэкапный диск по USB и говорим zpool > attach, в результате чего пул становится зеркальным и начинается > ресилверинг основного диска на резервный; > > 2) дожидаемся окончания ресилвера, однократно делаем этот диск > загрузочным, говорим ему zpool offline и отсоединяем его; пул остается в > degraded state, но полностью работоспособный (в этом моменте я уверен не > до конца, и хотелось бы выслушать его подтверждение или опровержение); > > 3) с определенной периодичностью подключаем резервный диск, говорим ему > zpool online, дожидаемся окончания ресилвера, говорим zpool offline и > отключаем обратно. > > Цель этих нетривиальных действий: если в процессе эксплуатации основного > диска (когда резервный отключен) на нем возникнет checksum error, есть > предположение (в котором я как раз совершенно не уверен), что когда > вечером будет подключен резервный и окажется, что поврежденные данные > есть в неповрежденном виде на резервном, zfs поправит их на основном, > как он поступает в случае, если в момент обнаружения ошибки доступны оба > зеркала. Если мое предположение неправильно, то, разумеется, такие > неочевидные действия совершенно не нужны, достаточно zfs send (-I) -R. > Но вдруг?.. > >
Re: зеркальный бэкап ZFS
*** Alex Kicelew [2017-07-16 21:02]: >2) дожидаемся окончания ресилвера, однократно делаем этот диск >загрузочным, говорим ему zpool offline и отсоединяем его; пул остается в >degraded state, но полностью работоспособный (в этом моменте я уверен не >до конца, и хотелось бы выслушать его подтверждение или опровержение); Да, всё верно. >Цель этих нетривиальных действий: если в процессе эксплуатации основного >диска (когда резервный отключен) на нем возникнет checksum error, есть >предположение (в котором я как раз совершенно не уверен), что когда >вечером будет подключен резервный и окажется, что поврежденные данные >есть в неповрежденном виде на резервном, zfs поправит их на основном, >как он поступает в случае, если в момент обнаружения ошибки доступны оба >зеркала. Тоже всё верно. Но есть засада. Время от времени ZFS делает checkpoint -- обновляет überblock ссылающийся на самое свежее дерево метаданных. У этого checkpoint есть, грубо говоря, timestamp, который только увеличивается. Во время вставки диска для resilvering он пытается понять не был ли он частью этого пула и если был, то он понимает насколько checkpoint-ов он "отстал" от основного. Найдя в основном поле старый checkpoint, он может создать "diff", который будет заresilverен. Но если прошло достаточно большое время, то настолько старого checkpoint-а не будет и он вынужден будет делать resilvering полностью всех данных с нуля, ведь он же не может "вечно" хранить все прошлые известные ему checkpoint-ы/überblock-и. Я точно не уверен, но вот терзают смутные сомнения что он будет хоть как-то смотреть на данные которые там всё же были -- поэтому такой старый диск для него будет как пустой. Кол-во checkpoint-ов на пуле вроде как фиксировано и что-то порядка полутысячи (где-то слышал). То есть минуты отключенного состояния он конечно переживёт спокойно, но вот часы уже навряд ли. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: зеркальный бэкап ZFS
*** Alex Kicelew [2017-07-16 21:02]: >2) дожидаемся окончания ресилвера, однократно делаем этот диск >загрузочным, говорим ему zpool offline и отсоединяем его; пул остается в >degraded state, но полностью работоспособный (в этом моменте я уверен не >до конца, и хотелось бы выслушать его подтверждение или опровержение); Но похожий хак можно например использовать для дефрагментации диска. Вообще с ней проблем быть не должно если всегда имеется запас достаточного количества свободного места (которое можно зарезервировать например как-то так: zfs set reservation=XXXG mypool/reserved), но всякое может быть. Так вот resilvering делается не как в RAID-е байт-в-байт, а записывая на диск сериализованное представление diff-а/данных: поэтому в зеркале на дисках данные могут лежать очень по разному и с очень разной степень фрагментации. Добавляем диск-зеркало: zpool attach mypool mydisk-first mydisk-second, ждём resilvering, потом делаем *detach* основного диска: zpool detach mypool mydisk-first -- массив не будет в degraded состоянии и в нём будет хорошо дефрагментированный диск. Процедуру можно повторить чтобы всё же оригинальный диск был в pool-е. В отличии от zfs send/recv -- не нужно систему переводить в offline, всё прозрачно работает. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: зеркальный бэкап ZFS
*** Vasiliy P. Melnik [2017-07-16 21:45]: >так с данными лучше не поступать - проще использовать рсинк Как минимум, zpool scrub может сообщить какие именно файлы повреждены и из бэкапа их взять можно будет. Один раз у меня, когда внешний жёсткий диск начал сыпаться, как-раз scrub показал что вот такой и такой файлы биты -- взял из прошлого бэкапа. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: зеркальный бэкап ZFS
> > Но похожий хак можно например использовать для дефрагментации диска. далась вам эта фрагментация, сказали держать 20% свободного места и все будет хорошо.
Re: зеркальный бэкап ZFS
On 07/16/17 21:43, Vasiliy P. Melnik wrote: > Уравнение со слишком многими неизвестными и слишком большим количеством > если. > > так с данными лучше не поступать - проще использовать рсинк, и лучше > складывать на ехт4, ибо инструментов рекавери с зфс-а нет, а один раз я уже > был в ситуации, когда очень бы они пригодились А что имеется в виду под инструментами рекавери? Боюсь, что в случае одновременной смерти как основного, так и бэкапного дисков я навряд ли смогу что-либо сделать, даже если они оба будут под extN. Что касается риска... Я допускаю, что у zfs он выше. Но раз уж я в качестве эксперимента на нее перешел, то хотелось бы получить от этого эксперимента максимум экспириенса. :) Все же бОльшая часть (хотя и не все) данных у меня автоматически синхронизируется между всеми доступными машинами (две домашние и две рабочие), а бэкап нужен в 75% для того, чтобы не возиться с ручным сбором этих данных со всех машин. И как раз в случае ноута -- чтобы было можно просто загрузиться с бэкапного винта, и все.
Re: зеркальный бэкап ZFS
> > Как минимум, zpool scrub может сообщить какие именно файлы повреждены и > из бэкапа их взять можно будет. Один раз у меня, когда внешний жёсткий > диск начал сыпаться, как-раз scrub показал что вот такой и такой файлы > биты -- взял из прошлого бэкапа. > У нас наверное просто разный подход к резервированию критично важных данных: как показала недавняя у нас ситуация с шифровальщиком - бекапов много не бывает. И лучше разных и в разных местах
Re: зеркальный бэкап ZFS
*** Vasiliy P. Melnik [2017-07-16 21:59]: >> Как минимум, zpool scrub может сообщить какие именно файлы повреждены и >> из бэкапа их взять можно будет. Один раз у меня, когда внешний жёсткий >> диск начал сыпаться, как-раз scrub показал что вот такой и такой файлы >> биты -- взял из прошлого бэкапа. > >У нас наверное просто разный подход к резервированию критично важных >данных: как показала недавняя у нас ситуация с шифровальщиком - бекапов >много не бывает. И лучше разных и в разных местах Я не понял в чём она у нас разная и какой у вас подход. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: зеркальный бэкап ZFS
On 07/16/17 21:43, Sergey Matveev wrote: > Тоже всё верно. Но есть засада. Время от времени ZFS делает checkpoint > -- обновляет überblock ссылающийся на самое свежее дерево метаданных. У > этого checkpoint есть, грубо говоря, timestamp, который только > увеличивается. Во время вставки диска для resilvering он пытается понять > не был ли он частью этого пула и если был, то он понимает насколько > checkpoint-ов он "отстал" от основного. Найдя в основном поле старый > checkpoint, он может создать "diff", который будет заresilverен. Но если > прошло достаточно большое время, то настолько старого checkpoint-а не > будет и он вынужден будет делать resilvering полностью всех данных с > нуля, ведь он же не может "вечно" хранить все прошлые известные ему > checkpoint-ы/überblock-и. Я точно не уверен, но вот терзают смутные > сомнения что он будет хоть как-то смотреть на данные которые там всё же > были -- поэтому такой старый диск для него будет как пустой. > > Кол-во checkpoint-ов на пуле вроде как фиксировано и что-то порядка > полутысячи (где-то слышал). То есть минуты отключенного состояния он > конечно переживёт спокойно, но вот часы уже навряд ли. > Ага, спасибо. Об этом я не знал. На самом деле такой способ уже был проверен (перед тем, как спрашивать о его безопасности я хотел убедиться хотя бы в том, что он осуществим физически), и на сутки чекпойнтов явно хватает (первичный ресилверинг был около 4х часов, последующие -- 5-10 минут), но правильно ли я понимаю, что худшее, что я получу при превышении количества имеющихся чекпойнтов -- это необходимость снова ресилверить 4 часа вместо 5 минут?
Re: зеркальный бэкап ZFS
*** Alex Kicelew [2017-07-16 22:11]: >правильно ли я понимаю, что худшее, что я получу при >превышении количества имеющихся чекпойнтов -- это необходимость снова >ресилверить 4 часа вместо 5 минут? Да, всё верно. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: зеркальный бэкап ZFS
*** Vasiliy P. Melnik [2017-07-16 21:55]: >далась вам эта фрагментация, сказали держать 20% свободного места и все будет >хорошо. В ZFS её легко можно получить просто медленно записывая файл. Да, можно потом сделать cp file file_ && mv file_ file, но а если файлов много и мало ли какие ещё режимы работы будут? Всякое может быть, и медленная запись файла не позволит его быстро прочитать это факт. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: tmux на локальной машине (was Xfce Terminal Emulator)
On Fri, Jul 14, 2017 at 12:02:21PM -0400, Tim Sattarov wrote: > On 14/07/17 01:15 AM, Jurgen V. Uzbekoff wrote: > > Свои пять копеек. Про screen, но не суть: > Привет ! давно тебя здесь не видел :) Ну так я в режиме Read-Only обычно :) Тут за выходные умные люди столько всего написали хорошего, чем я никогда даже и не думал пользоваться… Но ты спросил — я рассказываю про личный опыт. > > 1. Есть несколько конкретных табов с конкретными задачами — переключаюсь в > > нужный на автопилоте; > > 2. Очень полезен большой scrollback и поиск/копирование в нём; > А разве в эмуляторе этого нет ? Зачем screen ? Может в каком-то эмуляторе это и есть. В моём текущем я не обнаружил (а до сегодняшнего дня даже и не пытался искать). И то, что я не пытался искать эту функцию не только в этом terminal-emulator, но и в других, в которых я запускал screen, мне очень нравится — мне в любом эмуляторе было достаточно привычного функционала screen. > > 3. В terminal-emulator есть и свои табы — их по числу постоянных удалённых > > соединений, плюс один локальный; а в каждом из них свой набор > > мультиплексированных терминалов (не совсем локальный сценарий, каюсь); > я в своих скриптах, когда нужно заходить на машину(ы) за бастионом > (jump-server, bastion) открываю локальную сессию screen с подключением к > бастиону и подключением к остальным серверам из списка. Удобно да. Плюс > журналированине сессии в файл и портирование скрипта на другие платформы > становится немного легче. > Ну и стандартное использование: открыть screen для критичной/долгой > операции на удалённом сервере, "штоб не порвалось посередине" > > Мой вопрос больше, про: какая разница > - запустить терминал с кучей вкладок и перейти в нужные папки/запустить > нужную программу > или > - запустить локальный screen/tmux всё с теми же программами ? В screen автомагически имеешь набор табов, где за меня уже перешли в нужные папки и запустили нужные программы. Кроме того, всё-таки, очень полезно иметь возможность подключиться к этому набору откуда угодно и чувствовать себя как дома :) > (это наверное подразумевает, графический терминал, в то же время > tmux/screen менее требовательны) И это тоже. Тут даже бОльшее преимущество в том, что собственно от терминала не требуется практически ничего — он всего лишь должен иметь возможность запустить screen. -- IOpuk.
