https://ssl.opennet.dev/openforum/vsluhforumID3/89208.html В дерево исходных текстов OpenBSD интегрирован (http://permalink.gmane.org/gmane.os.openbsd.cvs/118371) код нового демона identd с реализацией протокола IDENT (http://ru.wikipedia.org/wiki/Ident) (RFC 1413 (http://tools.ietf.org/html/rfc1413)), предназначенного для организации идентификации пользователя, устанавливающего TCP-соединение. Новый identd разработан в недрах проекта OpenBSD в качестве безопасной и высокопроизводительной замены штатного (http://www.openbsd.org/cgi-bin/man.cgi?query=identd) BSD identd, вызываемого через inetd. <br><br><br>Новая реализация сама обрабатывает соединения и запускается в форме фонового процесса, при этом соединения обрабатываются в неблокирующем режиме с использованием libevent. За счёт грамотной организации обработки сетевых соединений и ухода от дополнительной нагрузки, связанной с запуском нового процесса на каждый запрос при использовании inetd, новая реализация позволяет кардинально увеличить производительность работы сервиса IDENT. Кроме того, в новом identd обеспечена воз https://ssl.opennet.dev/openforum/vsluhforumID3/89208.html#30 Tue, 26 Mar 2013 12:00:22 GMT Но зачем, Ватсон?..<br><br>Идея распределенного файрвола, когда пользовательские машины сообщают на центральный пункт сведения о том, кто какие соединения открыл, уже однажды была реализована (клиентская кроссплатформенна, серверная под линукс). В протокол ident, однако, эта задача не укладывается.<br><br>В общем, картинка про троллейбус из буханки. Другие проекты хоть какую-то полезность имели.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/89208.html#29 Mon, 25 Mar 2013 20:20:10 GMT &gt;[оверквотинг удален]<br>&gt;&gt; ...<br>&gt;&gt;&gt; Что будем делать, митрофаныч?<br>&gt;&gt; А, забыл сказать.<br>&gt;&gt; [code] <br>&gt;&gt; paexec -t 'ssh -t' ...<br>&gt;&gt; [/code] <br>&gt;&gt; не пойдет, во-первых, stdin занят, во-вторых, 'ssh -t' -- это overkill.<br>&gt; Я обычно такие вещи пишу на tcl + expect. Писать просто, контроллировать <br>&gt; ход выполнения - еще проще, особенно, если знать про расширенные возможности <br>&gt; expect, типа interact.<br><br>В моем случае есть специальная строка-терминатор, которую "клиент"<br>должен напечатать и сбросить буфер stdout. Эта строка -- признак того,<br>что обработка задачи завершена и можно приступать к следующей.<br>expect можно использовать, если утила сбрасывать буфер не умеет, т.е.<br>использовать в качестве "обертки".<br><br>Но сути вопроса это не меняет.<br>Древний небезопасный rsh работает, ssh -- увы.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/89208.html#28 Mon, 25 Mar 2013 17:42:40 GMT &gt;&gt;&gt; И, кстати, я где-то слышал, что telnet: не безопасен.<br>&gt; ...<br>&gt;&gt; Что будем делать, митрофаныч?<br>&gt; А, забыл сказать.<br>&gt; [code] <br>&gt; paexec -t 'ssh -t' ...<br>&gt; [/code] <br>&gt; не пойдет, во-первых, stdin занят, во-вторых, 'ssh -t' -- это overkill.<br><br>Я обычно такие вещи пишу на tcl + expect. Писать просто, контроллировать ход выполнения - еще проще, особенно, если знать про расширенные возможности expect, типа interact.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/89208.html#27 Sat, 23 Mar 2013 15:41:16 GMT И что это меняет?<br> https://ssl.opennet.dev/openforum/vsluhforumID3/89208.html#26 Fri, 22 Mar 2013 05:55:24 GMT &gt;&gt; И, кстати, я где-то слышал, что telnet: не безопасен.<br>&gt; Вот тебе, митрофаныч, задача.<br>&gt; Что будем делать, митрофаныч?<br><br>Приятно проводить досуг.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/89208.html#25 Thu, 21 Mar 2013 20:27:11 GMT &gt;&gt; И, кстати, я где-то слышал, что telnet: не безопасен.<br><br>...<br>&gt; Что будем делать, митрофаныч?<br><br>А, забыл сказать.<br><br>[code]<br>paexec -t 'ssh -t' ...<br>[/code]<br><br>не пойдет, во-первых, stdin занят, во-вторых, 'ssh -t' -- это overkill.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/89208.html#24 Thu, 21 Mar 2013 20:25:06 GMT &gt; И, кстати, я где-то слышал, что telnet: не безопасен.<br><br>Вот тебе, митрофаныч, задача.<br>Есть у нас некий "кластер на проводах", состоящий, скажем, из<br>десятка хостов с UNIX-like системой, скажем, Linux.<br><br>Есть у нас десятки тысячи задач, которые нужно равномерным слоем<br>размазать по этому кластеру. Да, кстати, кластер внутри<br>небольшого езернет фрагмента большой "корпорастии",<br>так что за безопасность трафика можно не беспокоиться.<br><br>Решаем мы ее так:<br>[code]<br>paexec -x -n 'host1 ... host10' -c remote_command -t transport &lt; tasks<br>[/code]<br><br>paexec -- это моя поделка, но сути ведь это меняет, правда?<br>remote_command принимает задачу (одну) в качестве своего<br>единственного аргумента. В качестве транспорта мы можем<br>использовать любую ssh-like утилиту, скажем, ssh или rsh.<br><br>Проблема вот в чем. В случае транспорта ssh, если мы жмем C-c или C-\,<br>локальные ssh-ы прибиваются, а вот remote_command-ы на хостах -- нет.<br>В случае rsh -- прибивается все, включая удаленные процессы,<br>т.е. remote_command-ы получают https://ssl.opennet.dev/openforum/vsluhforumID3/89208.html#23 Thu, 21 Mar 2013 16:51:24 GMT Обойдется общественность! Осведомленные особи огромные объемы обрабатывают Ораклом!<br> https://ssl.opennet.dev/openforum/vsluhforumID3/89208.html#22 Thu, 21 Mar 2013 13:42:59 GMT &gt; [...] OpenSSH, больше тебе нет необходимости пользоваться телнетом.<br><br>Надеюсь, помните, что openssh не на пустом месте вырос?<br>