Re: Проблемы протокола ssh (Re: и об облаках)
Mon, 3 Mar 2014 20:12:41 +0400 Иван Лох wrote: > On Mon, Mar 03, 2014 at 07:56:21PM +0400, Alexander GQ Gerasiov wrote: > > > Какие именно, можно озвучить? > > Терминал подвисает и всё. Если не озаботился использованием screen > > заранее, то бывает очень больно. Особенно, если там работает уже > > который час fsck =) > > retty? Это если успел заметить пока оно не отвалилось с другого конца =) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140305182842.28c20956@snail
Re: Проблемы протокола ssh (Re: и об облаках)
Mon, 3 Mar 2014 22:29:41 +0400 Eugene Berdnikov wrote: > On Mon, Mar 03, 2014 at 08:21:51PM +0400, yuri.nefe...@gmail.com > wrote: > > On Mon, 3 Mar 2014, Alexander GQ Gerasiov wrote: > > > > >Mon, 3 Mar 2014 18:49:34 +0400 > > >Eugene Berdnikov wrote: > > > > > >>On Mon, Mar 03, 2014 at 06:30:19PM +0400, yuri.nefe...@gmail.com > > >>wrote: > > >>> Протокол ssh действительно имеет проблемы на нестабильных > > >>> сетях. > > >> > > >> Какие именно, можно озвучить? > > >Терминал подвисает и всё. > > Нетехнический вздор. При чём тут _протокол_ ssh? При том, что протокол ssh использует в качестве "идентификатора сессии" tcp-соединение, которое склонно протухать и портиться. И для решения этих проблем в реализации добавляют всякие keep-alive и т.п. Конечно "протокол ssh" это совершенно неконкретная отсылка, можно было бы на RFC 4253 и 793&Co, например, сослаться и было бы чуть более корректно, хотя и тоже вопрос проблема это стандарта, интерпретации или реализации. Но твои придирки некорректны, просто потому, что для пользователя есть протокол ssh для удаленного терминального доступа, а какая там иерархия стандартов за этим словом кроется, его не волнует. Как-то так, да. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140305185045.754b25aa@snail
Re: и об облаках
Tue, 04 Mar 2014 00:45:22 +0200 Alex Kuklin wrote: > On 03.03.2014 23:16, Artem Chuprina wrote: > > Alexander GQ Gerasiov -> debian-russian@lists.debian.org @ Mon, 3 > > Mar 2014 16:38:54 +0400: > > > > >> Ну и чтобы виртуальная сетевая подсистема работала в полный > > >> рост, а не как у OpenVZ, или, не к ночи будь помянуты, LXC. > > >> На VLAN я не настаиваю ;), все-таки виртуальная система, а вот > > >> необходимость перезапускать весь OpenVZ на хосте, чтобы > > >> заработала еще одна строка в конфигурации iptables (и иметь > > >> там для этого рута) - это не дело. > > > > AGG> Артём, это ты о чем сейчас? Я сейчас на openvz как раз > > AGG> переполз с xen, как раз столкнулся с iptables, так вроде > > AGG> ничего не пришлось перезапускать на хосте. Добавлять модули > > AGG> ядра iptablers в список автозагрузки openvz - да, но > > AGG> рестартовать для этого openvz не надо, в рантайме их просто > > AGG> загрузить на хосте, после чего в контейнере использовать. > > > > AGG> Модель сети в openvz - bridge. > совершенно не обязательно > в openvz есть L3-интерфейс (venet), которого для большей части задач > достаточно, и в котором нет кучи проблем L2-бриджей (veth). А вот с ходу я не совсем врубаюсь, с venet разве можно как-то миграцию между узлами делать? > за все время L2 потребовался считанное количество раз - для netboot и > для лицензий модулей астериска (которые привязываются к mac) OpenVPN с tap, сервера разработки, которые должны быть виртуально в том же сегменте, что и некоторое спец-железо (там отрываемо, но со слёзами), последовательное развитие довольно разнородной инфраструктуры, где некоторые узлы аппаратные, некоторые KVM, некоторые openvz и одни в другие по какой-то причине превращаются. В общем я могу назвать причин. Для одинокой машины, где контейнеры нужны просто для тонкого разделения ПО и делегирования полномочий - да, venet вполне рабочее решение. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140305185858.1c8c1f39@snail
Re: и об облаках
Tue, 04 Mar 2014 01:16:35 +0400 Artem Chuprina wrote: > Alexander GQ Gerasiov -> debian-russian@lists.debian.org @ Mon, 3 > Mar 2014 16:38:54 +0400: > > >> Ну и чтобы виртуальная сетевая подсистема работала в полный рост, > >> а не как у OpenVZ, или, не к ночи будь помянуты, LXC. На VLAN я > >> не настаиваю ;), все-таки виртуальная система, а вот необходимость > >> перезапускать весь OpenVZ на хосте, чтобы заработала еще одна > >> строка в конфигурации iptables (и иметь там для этого рута) - это > >> не дело. > > AGG> Артём, это ты о чем сейчас? Я сейчас на openvz как раз переполз > AGG> с xen, как раз столкнулся с iptables, так вроде ничего не > AGG> пришлось перезапускать на хосте. Добавлять модули ядра > AGG> iptablers в список автозагрузки openvz - да, но рестартовать > AGG> для этого openvz не надо, в рантайме их просто загрузить на > AGG> хосте, после чего в контейнере использовать. > > AGG> Модель сети в openvz - bridge. > > Я помню, что было надо. Я, правда, в последний раз это настраивал два > дистрибутива назад, ну так в текущем stable OpenVZ-ядра вообще > отсутствуют как класс. Там надо было не только модули загрузить, но и > OpenVZ объяснить, что этой машинке их можно. > > Ну вот, может, я вру про ВЕСЬ OpenVZ, но для какой-то настройки, > помнится, пришлось и ВЕСЬ перезапустить. А в норме - виртуалку после > правки конфига. Эти разрешения оно на ходу жрать не могло, а там > что-то про каждый потребный модуль приходилось объяснять. Вот всё что мне потребовалось сделать на днях, это поправить /etc/vz/vz.conf (две строчки) IPTABLES="ipt_REJECT ipt_tos ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length iptable_nat" IPTABLES_MODULES="$IPTABLES nf_conntrack xt_state" И после этого перезапустить _контейнер_, да. Всё. > > Короче, там, где у тебя нет рута на HN, нереально. Ну скажем так, там, где у тебя нет совсем никакого влияния на админа хоста =) > > И еще чего-то там, помнится, на ровном месте не работало даже при > этом. А, multiport. У меня до сих пор в конфиге iptables комментарий > на эту тему при нескольких почти одинаковых строках... > > А если я же и админ HN, то в общем, и OpenVZ хорош. Хотя тоже свои > тараканы. И главный, если вспомнить о тематике рассылки - что ядра в > дистрибутиве больше нет. Ну это особенности политики Debian и некоторой "нестабильности" OpenVZ. Ядро вполне можно использовать из репозитория openvz или pve. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140305191224.467a62c3@snail
Re: и об облаках
On 05.03.2014 16:58, Alexander GQ Gerasiov wrote: Tue, 04 Mar 2014 00:45:22 +0200 Alex Kuklin wrote: On 03.03.2014 23:16, Artem Chuprina wrote: Alexander GQ Gerasiov -> debian-russian@lists.debian.org @ Mon, 3 Mar 2014 16:38:54 +0400: >> Ну и чтобы виртуальная сетевая подсистема работала в полный >> рост, а не как у OpenVZ, или, не к ночи будь помянуты, LXC. >> На VLAN я не настаиваю ;), все-таки виртуальная система, а вот >> необходимость перезапускать весь OpenVZ на хосте, чтобы >> заработала еще одна строка в конфигурации iptables (и иметь >> там для этого рута) - это не дело. AGG> Артём, это ты о чем сейчас? Я сейчас на openvz как раз AGG> переполз с xen, как раз столкнулся с iptables, так вроде AGG> ничего не пришлось перезапускать на хосте. Добавлять модули AGG> ядра iptablers в список автозагрузки openvz - да, но AGG> рестартовать для этого openvz не надо, в рантайме их просто AGG> загрузить на хосте, после чего в контейнере использовать. AGG> Модель сети в openvz - bridge. совершенно не обязательно в openvz есть L3-интерфейс (venet), которого для большей части задач достаточно, и в котором нет кучи проблем L2-бриджей (veth). А вот с ходу я не совсем врубаюсь, с venet разве можно как-то миграцию между узлами делать? Да, в чем проблема? ip меняет mac, но это фиксится анонсом по arp за все время L2 потребовался считанное количество раз - для netboot и для лицензий модулей астериска (которые привязываются к mac) OpenVPN с tap, сервера разработки, которые должны быть виртуально в том же сегменте, что и некоторое спец-железо (там отрываемо, но со слёзами), последовательное развитие довольно разнородной инфраструктуры, где некоторые узлы аппаратные, некоторые KVM, некоторые openvz и одни в другие по какой-то причине превращаются. В общем я могу назвать причин. OpenVPN с tap - это следствие других требований, а не причина. спецжелезо - да, но это как раз те самые "счетные случаи". Для одинокой машины, где контейнеры нужны просто для тонкого разделения ПО и делегирования полномочий - да, venet вполне рабочее решение. достаточно отсутствия достаточно экзотических требований, см. выше. для всяких веб/инет задач L3 более чем достаточно. -- Alex -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53174ce9.7010...@kuklin.ru
Re: и об облаках
Alexander GQ Gerasiov -> debian-russian@lists.debian.org @ Wed, 5 Mar 2014 19:12:24 +0400: >> Короче, там, где у тебя нет рута на HN, нереально. AGG> Ну скажем так, там, где у тебя нет совсем никакого влияния на админа хоста =) Скажем так, реально (за осмысленное время) только если админ хоста - твой хороший знакомый. Но он тоже человек и ночью хочет спать, со всеми вытекающими. А на каком-нибудь мастерхосте ради моего OpenVPN никто не будет перенастраивать HN (а с учетом возможной миграции - _все_ HN в датацентре). А в том, что у них сразу все включено, сразу загружены _все_ модули iptables, и главное, с раздачи прописан NET_ADMIN, я не верю. >> И еще чего-то там, помнится, на ровном месте не работало даже при >> этом. А, multiport. У меня до сих пор в конфиге iptables комментарий >> на эту тему при нескольких почти одинаковых строках... >> >> А если я же и админ HN, то в общем, и OpenVZ хорош. Хотя тоже свои >> тараканы. И главный, если вспомнить о тематике рассылки - что ядра в >> дистрибутиве больше нет. AGG> Ну это особенности политики Debian и некоторой "нестабильности" OpenVZ. AGG> Ядро вполне можно использовать из репозитория openvz или pve. А как у нас в ядрах "из репозитория openvz или pve" с security updates? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ob1ktuc7@wizzle.ran.pp.ru
Re: Проблемы протокола ssh (Re: и об облаках)
On Wed, Mar 05, 2014 at 06:50:45PM +0400, Alexander GQ Gerasiov wrote: > Но твои придирки некорректны, просто потому, что для пользователя есть > протокол ssh для удаленного терминального доступа, а какая там иерархия > стандартов за этим словом кроется, его не волнует. Мои придирки предметны, их суть не зависит от того, переписываюсь я со специалистом по сетям или же с чайником. Мы выяснили, что под "проблемами протокола ssh" пользователь имел в виду проблемы tcp как протокола нижнего уровня, и на этом вопрос исчерпан. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140305191302.go15...@sie.protva.ru
Обнаружить воткнутый девайс и xinput его
Привет. Может, кто тут разбирается, и даст умный совет? Есть девайс. Мышка (надевается на палец, но это не суть) с двумя кнопками. USB, ноутбук, т.е. она в него воткнута существенно не всегда. Я хочу на ней (и именно на ней, и без залезания в отсутствующий у меня в системе за ненадобностью xorg.conf) при ее втыкании включать эмуляцию средней кнопки. Я умею: сказать $ xinput --list ⎡ Virtual core pointer id=2[master pointer (3)] ⎜ ↳ Virtual core XTEST pointerid=4[slave pointer (2)] ⎜ ↳ SynPS/2 Synaptics TouchPadid=14 [slave pointer (2)] ⎜ ↳ USB OPTICAL MOUSEid=10 [slave pointer (2)] ... (ну, клавиатура неинтересна) и на основании этой информации $ xinput --set-prop 10 'Evdev Middle Button Emulation' 1 и мне не сложно заскриптовать комбинацию. Хотя называется она, конечно, офигительно информативно, блин. Но хочется это делать при втыкании, а не непонятно когда. А вот как правильно обнаружить втыкание? Предупреждаю сразу: исходя из того, что оно мне надо в иксах, вариант udev-правила получается кривым, поскольку xinput запускается, вообще говоря, на одном хосте, а мышка втыкается в другой. Впрочем, если в этой ситуации Xinput extension отваливается сам по себе, то этот вопрос отпадает. Но чисто по логике-то не с чего, это все же не shared memory. Раз сам X-сервер втыкание определяет, то где-то оно у него должно бы появляться-то... Но на худой конец сойдет и решение, где терминал и сессия на одном хосте. Нет, я даже могу придумать схему в духе "udev кидает событие в dbus, скрипт его ждет, и если видит, то дергает xinput", но как-то это кривовато, очень хочется верить, что существует какой-то более прямой путь получить нужную информацию, непосредственно из X-сервера. Однако, сходу не удалось задать гуглу правильный вопрос. Я даже выяснил методом Мана и Тыка, что можно попросить xinput слушать Core Pointer, и из его вывода отфильтровать добавление девайса, но более избирательно в нем не предусмотрено, а вывода там - на каждое движение мышки. Это, прямо скажем, перебор. И кроме того, xinput для этого окно создает, хотя, в отличие от xev, реагирует на движения мышки и вне этого окна. Нет, опять же, отсюда понятно, что можно взять библиотеку, почитать хедера, документацию на расширение я как раз сумел нагуглить, и вперед. Но может, этот велосипед уже изобрели? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87k3c8tp1w@wizzle.ran.pp.ru
Re: Проблемы протокола ssh (Re: и об облаках)
Это не проблемы tcp, и не проблемы ssh. Это проблемы пользователя. И вопрос как их решить только начинается. Eugene Berdnikov writes: > On Wed, Mar 05, 2014 at 06:50:45PM +0400, Alexander GQ Gerasiov wrote: >> Но твои придирки некорректны, просто потому, что для пользователя есть >> протокол ssh для удаленного терминального доступа, а какая там иерархия >> стандартов за этим словом кроется, его не волнует. > > Мои придирки предметны, их суть не зависит от того, переписываюсь я > со специалистом по сетям или же с чайником. Мы выяснили, что под > "проблемами протокола ssh" пользователь имел в виду проблемы tcp > как протокола нижнего уровня, и на этом вопрос исчерпан. > -- > Eugene Berdnikov -- Игорь Гайсин Email: igor.gaj...@tts.tv Телефон: 8-499-967-77-97 (4096) Должность: Системный администратор ООО "Бриллианит" -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bnxjc3d0@ws-it-19-15.tts.loc
Патчи debian/pathces в openssl
Доброго дня. Встала задача взять пропатченные исходники openssl наложить свой патч и сборать deb пакет. Подскажите, все ли патчи в дирректории debian/pathces УЖЕ наложены на исходники, после их получения командой apt-get source mypackage/stable ? Я поcтмотрел патчи и соответсвующие файлы исходнников и сделал вывод, что наложены только отделные патчи. Может я ошибаюсь?
Re: Патчи debian/pathces в openssl
Сергей С. writes: > Подскажите, все ли патчи в дирректории debian/pathces УЖЕ наложены на > исходники, после их получения командой apt-get source mypackage/stable ? Патчи вообще не наложены. Они лежат отдельно от исходников. pgpZAFQh5wGYA.pgp Description: PGP signature
Re: Патчи debian/pathces в openssl
Спасибо. Есть ли способ одной командой наложить все патчи? 6 марта 2014 г., 6:12 пользователь Dmitrii Kashin написал: > Сергей С. writes: > > > Подскажите, все ли патчи в дирректории debian/pathces УЖЕ наложены на > > исходники, после их получения командой apt-get source mypackage/stable ? > > Патчи вообще не наложены. Они лежат отдельно от исходников. >
Re: Патчи debian/pathces в openssl
Сергей С. writes: > Есть ли способ одной командой наложить все патчи? Да, команда называется patch. pgpTpvrCYb_mA.pgp Description: PGP signature
Re: Патчи debian/pathces в openssl
6 марта 2014 г., 13:16 пользователь Сергей С. написал: > Есть ли способ одной командой наложить все патчи? dpkg-source -x пакет.dsc # Извлекает и накладывает. cd пакет ./debian/rules build # строит fakeroot ./debian/rules binary # собирает конечный пакет
Re: Патчи debian/pathces в openssl
"dm.fedorov" writes: > 6 марта 2014 г., 13:16 пользователь Сергей С. написал: >> Есть ли способ одной командой наложить все патчи? > > dpkg-source -x пакет.dsc # Извлекает и накладывает. > > cd пакет > > ./debian/rules build # строит > > fakeroot ./debian/rules binary # собирает конечный пакет Ну Вы ему ещё про apt-get source и pbuilder расскажите... =/ pgpyfgNekgqhE.pgp Description: PGP signature
Kredyt bez Zus
Witam Chciałbym Państwu zaproponować możliwość pozyskania kredytu firmowego bądź indywdualnego na dowolny cel. Jeżeli są Państwo zainteresowani szczegółami prosimy o informację zwrotną o treści "TaK" z poważaniem Przemysław Janowski 533-884-747 ( Play ) bi...@ecentrumfinansowe24.pl *Powyższa informacja jest jedynie zapytaniem i nie stanowi oferty kredytowej .Osoby nie zainteresowane nie otrzymają ponownego zapytania. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/F2524FC970FEDE250BBC170E8EB4B56A@giada
Re: Патчи debian/pathces в openssl
6 марта 2014 г., 13:37 пользователь Dmitrii Kashin написал: > "dm.fedorov" writes: > >> 6 марта 2014 г., 13:16 пользователь Сергей С. написал: >>> Есть ли способ одной командой наложить все патчи? >> >> dpkg-source -x пакет.dsc # Извлекает и накладывает. > > Ну Вы ему ещё про apt-get source и pbuilder расскажите... =/ Не расскажу - не знаю.
Re: Проблемы протокола ssh (Re: и об облаках)
(Топ-постинг в данном случае намеренный) Что-то я глянул на описание autossh, который упоминался в начале, и... Это проблемы модели использования. autossh - это не просто костыль, это костыль для увеличения устойчивости функциональности, которая вообще не укладывается в изначальную модель работы ssh. С самим ssh, в смысле, с выполнением команд на удаленном хосте, в т.ч. интерактивно, хитрее. Он, конечно, менее устойчив, чем sh. В модели использования sh все-таки подразумевается, что ситуация, когда выполнение команды прервано по вторичным причинам, ненормальна. У самого sh, кстати, и "по первичным" тоже. В смысле, его модель не замечает неудачного завершения непоследней команды в пайпе, в результате в bash, zsh и пр. встраивают для этого, опять же, костыли. При этом в нем предусмотрено, что такая ситуация _бывает_ - для выполнения работ, которые могут длиться дольше, чем сеанс связи, еще с доисторических времен есть nohup. Если я правильно ошибаюсь, в иксах с этим гораздо хуже, xlib при обрыве соединения с сервером тупо дергает abort(). SIGHUP хоть перехватить можно и вежливо завершиться... И тут я считаю, что правильный подход - это UNIX way. Отдельно выполнение команды на удаленном хосте через зашифрованный канал, отдельно защита от обрыва. Конечно, в качестве минимальной защиты от обрыва для терминального соединения screen или tmux представляется некоторым overkill'ом, но если подумать, то почти нет. С одной стороны, защита от обрыва терминальному мультиплексору дается практически даром - все необходимое для этого все равно реализуешь для мультиплексирования, осталось только SIGHUP перехватить. С другой - для восстановления интерактивного сеанса после обрыва нужна почти вся та же функциональность, что для мультиплексирования, потому что воссоединиться могут совершенно с другого терминала. То есть для удаленного шелла в ssh бессмысленно встраивать механизм реконнектов - либо не встраивать вообще, либо встраивать функциональность хотя бы tmux почти целиком. Я предпочту первый вариант. А вот когда в ssh появились туннели, тут-то и появилась совершенно другая модель. OpenVPN, разумеется, сам занимается реконнектами :) autossh, по сути, непригоден для функциональности remote shell, если на том конце нету screen, и крайне слабо осмыслен, если screen на том конце есть. А вот для туннелей - да. Но тоже, кстати, большой вопрос. Про OpenVPN я практически уверен (хотя честно скажу - документацию не читал...), что при обрыве соединения сервер тоже не кладет туннель, во всяком случае, довольно долго. А как с этим у ssh, я не знаю... Все-таки механизм туннелей ssh - это VPN либо для бедных, либо для "вот сейчас на коленке". Когда требуется быстро, а не надежно. ИГ> Это не проблемы tcp, и не проблемы ssh. Это проблемы пользователя. И ИГ> вопрос как их решить только начинается. >>> Но твои придирки некорректны, просто потому, что для пользователя есть >>> протокол ssh для удаленного терминального доступа, а какая там иерархия >>> стандартов за этим словом кроется, его не волнует. >> >> Мои придирки предметны, их суть не зависит от того, переписываюсь я >> со специалистом по сетям или же с чайником. Мы выяснили, что под >> "проблемами протокола ssh" пользователь имел в виду проблемы tcp >> как протокола нижнего уровня, и на этом вопрос исчерпан. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fvmvu685@wizzle.ran.pp.ru
