| 1.1, Клыкастый (ok), 09:36, 20/03/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
 ident кроме как в роле некоей необязательности на IRC ещё где-то используется?
| | |
| |
| 2.2, YetAnotherOnanym (ok), 10:00, 20/03/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Мало ли, какой-нибудь корпорастический софт, бегающий в доверяемой среде в интранете, где бухши и манагеры работают на огороженных персоналках с опёнком. Сложно представить, какие преимущества могут быть у такого решения, но мало ли у кого какие обстоятельства.
| | |
| |
| 3.7, Михрютка (ok), 15:16, 20/03/2013 [^] [^^] [^^^] [ответить]
| +15 +/– |
 > бухши и манагеры работают на огороженных персоналках с опёнком. Сложно
однажды осенью, обходя окрестности офиса, одмин Онуфрий обнаружил OpenBSD
| | |
| |
| |
| 5.10, Михрютка (ok), 18:04, 20/03/2013 [^] [^^] [^^^] [ответить]
| +10 +/– | |
"Опенсорсный оазис!" - остолбенел Онуфрий. "Окончательно обнаглели, охальники!"
| | |
| |
| 6.13, YetAnotherOnanym (ok), 00:01, 21/03/2013 [^] [^^] [^^^] [ответить]
| +4 +/– |
"Однако, отключать опасно," - осёкся осторожный одмин, - "обрабатывает огромные объёмы оцифровки. Отказ обслуживания обозлит общественность."
| | |
| |
| 7.23, Михрютка (ok), 20:51, 21/03/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
Обойдется общественность! Осведомленные особи огромные объемы обрабатывают Ораклом!
| | |
|
|
|
|
|
| 2.5, saNdro (?), 12:40, 20/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
Может штатно использоваться postgresql для идентификации конектящихся пользователей.
| | |
|
| 1.14, Zulu (?), 00:19, 21/03/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +6 +/– |
Главное вовремя.
Ждем собственной имплементации gopher, причем обязательно разработанной _В НЕДРАХ_
| | |
| |
| 2.16, Andrey Mitrofanov (?), 09:36, 21/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Главное вовремя.
> Ждем собственной имплементации gopher, причем обязательно разработанной _В НЕДРАХ_
И, кстати, я где-то слышал, что telnet: не безопасен.
| | |
| |
| 3.18, Аноним (-), 11:44, 21/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
openBSD и так для тебя уже написали OpenSSH, больше тебе нет необходимости пользоваться телнетом.
| | |
| |
| 4.22, Michael Shigorin (ok), 17:42, 21/03/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > [...] OpenSSH, больше тебе нет необходимости пользоваться телнетом.
Надеюсь, помните, что openssh не на пустом месте вырос?
| | |
|
| 3.24, vle (ok), 00:25, 22/03/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > И, кстати, я где-то слышал, что telnet: не безопасен.
Вот тебе, митрофаныч, задача.
Есть у нас некий "кластер на проводах", состоящий, скажем, из
десятка хостов с UNIX-like системой, скажем, Linux.
Есть у нас десятки тысячи задач, которые нужно равномерным слоем
размазать по этому кластеру. Да, кстати, кластер внутри
небольшого езернет фрагмента большой "корпорастии",
так что за безопасность трафика можно не беспокоиться.
Решаем мы ее так:
paexec -x -n 'host1 ... host10' -c remote_command -t transport < tasks
paexec -- это моя поделка, но сути ведь это меняет, правда?
remote_command принимает задачу (одну) в качестве своего
единственного аргумента. В качестве транспорта мы можем
использовать любую ssh-like утилиту, скажем, ssh или rsh.
Проблема вот в чем. В случае транспорта ssh, если мы жмем C-c или C-\,
локальные ssh-ы прибиваются, а вот remote_command-ы на хостах -- нет.
В случае rsh -- прибивается все, включая удаленные процессы,
т.е. remote_command-ы получают
свои SIGINT/SIGQUIT и честно умирают, и именно это
поведение мне кажется единственно верным.
Болтающиеся часами не понятно зачем процессы никому не нужны,
как мне представляется.
В man-е NetBSD (пардон) на rsh сказано следующее:
Interrupt, quit and terminate
signals are propagated to the remote command
В мане на rsh в Debian-е ничего подобного нет, но работает он
так же, т.е. с моей точки зрения правильно.
Итого, варианты наших действий:
1) читаем код ssh/sshd и выясняем, в чем причина такого поведения, пишем патч,
отсылаем его апстриму;
2) пинаем апстрим (OpenBSD-шников) на предмет, фича это или баг, и в чем причина
такого поведения, далее запрашиваем фичу в случае, если бага;
3) быстро решаем проблему, заменяя привчный ssh на "устаревший" rsh
и откладываем пункты 1 и 2 "на потом", когда появится время.
Что будем делать, митрофаныч?
| | |
| |
| 4.25, vle (ok), 00:27, 22/03/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>> И, кстати, я где-то слышал, что telnet: не безопасен.
...
> Что будем делать, митрофаныч?
А, забыл сказать.
paexec -t 'ssh -t' ...
не пойдет, во-первых, stdin занят, во-вторых, 'ssh -t' -- это overkill.
| | |
| |
| 5.28, anonymous (??), 21:42, 25/03/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>> И, кстати, я где-то слышал, что telnet: не безопасен.
> ...
>> Что будем делать, митрофаныч?
> А, забыл сказать.
>
> paexec -t 'ssh -t' ...
>
> не пойдет, во-первых, stdin занят, во-вторых, 'ssh -t' -- это overkill.
Я обычно такие вещи пишу на tcl + expect. Писать просто, контроллировать ход выполнения - еще проще, особенно, если знать про расширенные возможности expect, типа interact.
| | |
| |
| 6.29, vle (ok), 00:20, 26/03/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
>[оверквотинг удален]
>> ...
>>> Что будем делать, митрофаныч?
>> А, забыл сказать.
>>
>> paexec -t 'ssh -t' ...
>>
>> не пойдет, во-первых, stdin занят, во-вторых, 'ssh -t' -- это overkill.
> Я обычно такие вещи пишу на tcl + expect. Писать просто, контроллировать
> ход выполнения - еще проще, особенно, если знать про расширенные возможности
> expect, типа interact.
В моем случае есть специальная строка-терминатор, которую "клиент"
должен напечатать и сбросить буфер stdout. Эта строка -- признак того,
что обработка задачи завершена и можно приступать к следующей.
expect можно использовать, если утила сбрасывать буфер не умеет, т.е.
использовать в качестве "обертки".
Но сути вопроса это не меняет.
Древний небезопасный rsh работает, ssh -- увы.
| | |
|
|
| 4.26, Andrey Mitrofanov (?), 09:55, 22/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> И, кстати, я где-то слышал, что telnet: не безопасен.
> Вот тебе, митрофаныч, задача.
> Что будем делать, митрофаныч?
Приятно проводить досуг.
| | |
|
|
|
| 1.30, nuclight (??), 16:00, 26/03/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Но зачем, Ватсон?..
Идея распределенного файрвола, когда пользовательские машины сообщают на центральный пункт сведения о том, кто какие соединения открыл, уже однажды была реализована (клиентская кроссплатформенна, серверная под линукс). В протокол ident, однако, эта задача не укладывается.
В общем, картинка про троллейбус из буханки. Другие проекты хоть какую-то полезность имели.
| | |
|
