Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Проект OpenBSD представил собственную реализацию identd"	+/–
Сообщение от opennews (ok), 20-Мрт-13, 09:36
В дерево исходных текстов 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. Новая реализация сама обрабатывает соединения и запускается в форме фонового процесса, при этом соединения обрабатываются в неблокирующем режиме с использованием libevent. За счёт грамотной организации обработки сетевых соединений и ухода от дополнительной нагрузки, связанной с запуском нового процесса на каждый запрос при использовании inetd, новая реализация позволяет кардинально увеличить производительность работы сервиса IDENT. Кроме того, в новом identd обеспечена возможность параллельной обработки клиентских соединений. Для обеспечения безопасности в новом identd поддерживаются такие дополнительные механизмы, как разделение и аннулирование привилегий. Обработка запроса производится после перехода в изолированное chroot-окружение и сброса привилегий. Для проверки наличия пользователя используется непривилегированный процесс, при этом выполнение проверки не блокирует обработку других запросов. Из пока не реализованных возможностей старого identd отмечается отсутствие поддержки загрузки информации об идентификаторе пользователя из размещённых в домашней директории файлов ".ident". Кроме того пока недостаточно полно обрабатываются ошибки. В настоящее время новый identd доступен только для использования в OpenBSD, но можно рассчитывать на скорое появление переносимых версий, поддерживаемых для других популярных проектов OpenBSD, таких как  OpenSSH (http://www.openssh.org/), пакетный фильтр PF (http://www.openbsd.org/faq/pf/index.html), демоны маршрутизации OpenBGPD и OpenOSPFD (http://www.openbgpd.org/), NTP-сервер OpenNTPD (http://www.openntpd.org/), почтовый сервер OpenSMTPD (http://www.opensmtpd.org/), мультиплексор текстового терминала (аналог GNU screen) tmux (http://tmux.sourceforge.net/), BSDL-альтернатива пакету GNU groff - mandoc (http://mdocml.bsd.lv/), протокол для организации отказоустойчивых систем CARP (Common Address Redundancy Protocol). URL: http://permalink.gmane.org/gmane.os.openbsd.cvs/118371 Новость: http://www.opennet.dev/opennews/art.shtml?num=36442
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Клыкастый (ok), 20-Мрт-13, 09:36	+4 +/–
ident кроме как в роле некоей необязательности на IRC ещё где-то используется?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #5

2. Сообщение от YetAnotherOnanym (ok), 20-Мрт-13, 10:00	+1 +/–
Мало ли, какой-нибудь корпорастический софт, бегающий в доверяемой среде в интранете, где бухши и манагеры работают на огороженных персоналках с опёнком. Сложно представить, какие преимущества могут быть у такого решения, но мало ли у кого какие обстоятельства.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #7

5. Сообщение от saNdro (?), 20-Мрт-13, 12:40	+/–
Может штатно использоваться postgresql для идентификации конектящихся пользователей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

7. Сообщение от Михрютка (ok), 20-Мрт-13, 15:16	+17 +/–
> бухши и манагеры работают на огороженных персоналках с опёнком. Сложно однажды осенью, обходя окрестности офиса, одмин Онуфрий обнаружил OpenBSD
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #9

9. Сообщение от YetAnotherOnanym (ok), 20-Мрт-13, 17:26	+10 +/–
"Однако, откуда окаянная операционка оказалась?" - ошеломлённо озадачился одмин Онуфрий :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #10

10. Сообщение от Михрютка (ok), 20-Мрт-13, 18:04	+11 +/–
"Опенсорсный оазис!" - остолбенел Онуфрий. "Окончательно обнаглели, охальники!"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #13

13. Сообщение от YetAnotherOnanym (ok), 21-Мрт-13, 00:01	+4 +/–
"Однако, отключать опасно," - осёкся осторожный одмин, - "обрабатывает огромные объёмы оцифровки. Отказ обслуживания обозлит общественность."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #23

14. Сообщение от Zulu (?), 21-Мрт-13, 00:19	+6 +/–
Главное вовремя. Ждем собственной имплементации gopher, причем обязательно разработанной _В НЕДРАХ_
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16

16. Сообщение от Andrey Mitrofanov (?), 21-Мрт-13, 09:36	+/–
> Главное вовремя. > Ждем собственной имплементации gopher, причем обязательно разработанной _В НЕДРАХ_ И, кстати, я где-то слышал, что telnet: не безопасен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #18, #19, #20, #24

18. Сообщение от Аноним (-), 21-Мрт-13, 11:44	+/–
openBSD и так для тебя уже написали OpenSSH, больше тебе нет необходимости пользоваться телнетом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #22

19. Сообщение от Grammar Nazi (?), 21-Мрт-13, 14:22	+/–
небезопасен
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #21

20. Сообщение от Аноним (-), 21-Мрт-13, 14:24	+/–
А если с керберосом?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

21. Сообщение от YetAnotherOnanym (ok), 21-Мрт-13, 15:54	+/–
Гоняйте внутри ESP, если не доверяете :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

22. Сообщение от Michael Shigorin (ok), 21-Мрт-13, 17:42	+1 +/–
> [...] OpenSSH, больше тебе нет необходимости пользоваться телнетом. Надеюсь, помните, что openssh не на пустом месте вырос?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #27

23. Сообщение от Михрютка (ok), 21-Мрт-13, 20:51	+1 +/–
Обойдется общественность! Осведомленные особи огромные объемы обрабатывают Ораклом!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

24. Сообщение от vle (ok), 22-Мрт-13, 00:25	–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 "на потом", когда появится время. Что будем делать, митрофаныч?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #25, #26

25. Сообщение от vle (ok), 22-Мрт-13, 00:27	–1 +/–
>> И, кстати, я где-то слышал, что telnet: не безопасен. ... > Что будем делать, митрофаныч? А, забыл сказать. paexec -t 'ssh -t' ... не пойдет, во-первых, stdin занят, во-вторых, 'ssh -t' -- это overkill.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #28

26. Сообщение от Andrey Mitrofanov (?), 22-Мрт-13, 09:55	+/–
>> И, кстати, я где-то слышал, что telnet: не безопасен. > Вот тебе, митрофаныч, задача. > Что будем делать, митрофаныч? Приятно проводить досуг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

27. Сообщение от ooo (?), 23-Мрт-13, 19:41	–1 +/–
И что это меняет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

28. Сообщение от anonymous (??), 25-Мрт-13, 21:42	+1 +/–
>>> И, кстати, я где-то слышал, что telnet: не безопасен. > ... >> Что будем делать, митрофаныч? > А, забыл сказать. > > paexec -t 'ssh -t' ... > > не пойдет, во-первых, stdin занят, во-вторых, 'ssh -t' -- это overkill. Я обычно такие вещи пишу на tcl + expect. Писать просто, контроллировать ход выполнения - еще проще, особенно, если знать про расширенные возможности expect, типа interact.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #29

29. Сообщение от vle (ok), 26-Мрт-13, 00:20	–1 +/–
>[оверквотинг удален] >> ... >>> Что будем делать, митрофаныч? >> А, забыл сказать. >> >> paexec -t 'ssh -t' ... >> >> не пойдет, во-первых, stdin занят, во-вторых, 'ssh -t' -- это overkill. > Я обычно такие вещи пишу на tcl + expect. Писать просто, контроллировать > ход выполнения - еще проще, особенно, если знать про расширенные возможности > expect, типа interact. В моем случае есть специальная строка-терминатор, которую "клиент" должен напечатать и сбросить буфер stdout. Эта строка -- признак того, что обработка задачи завершена и можно приступать к следующей. expect можно использовать, если утила сбрасывать буфер не умеет, т.е. использовать в качестве "обертки". Но сути вопроса это не меняет. Древний небезопасный rsh работает, ssh -- увы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

30. Сообщение от nuclight (??), 26-Мрт-13, 16:00	+/–
Но зачем, Ватсон?.. Идея распределенного файрвола, когда пользовательские машины сообщают на центральный пункт сведения о том, кто какие соединения открыл, уже однажды была реализована (клиентская кроссплатформенна, серверная под линукс). В протокол ident, однако, эта задача не укладывается. В общем, картинка про троллейбус из буханки. Другие проекты хоть какую-то полезность имели.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема