Прощай, FreeBSD

[slonik_v_domene]

Рампочта начинает миграцию на Linux. В качестве дистрибутива волевым решением выбран Debian GNU/Linux. Основная архитектура - 64 бит. Все 32-битные сервера постараемся как можно быстрее списать в утиль, новая система на них сетапиться не будет

Comments

Re: А если в конструктивное русло?

[alexclear]

А без перехода на личности никак?

А Вы думали, я наверное такой сейчас начну объяснять, что я конкретно имел в виду в том комментарии, к которому Вы вопрос задали?
Нет, мне неинтересно общаться с людьми, которые с первого раза прочесть и понять не могут.

Сложно с людьми, которые самоутверждаются, похоже, только за счет спорных утверждений касательно таких тонких материй, как ОС, высказанных безаппеляционным менторским тоном .)

С людьми, которые самоутверждаются за счет спорных утверждений про ОС весьма сложно, Вы правы. Надеюсь, Вы не такой. У меня мотивы еще проще - я просто хочу, чтобы присутствие FreeBSD на рынке свелось до минимума. Если Вы думаете, что мне в наследство достаются отлично настроенные FreeBSD-коробки, то это не так - обычно приходят машины, которые настраивали безумные школьники. Надоело разгребать это дерьмо в 2011-м году.

Re: А если в конструктивное русло?

[samuel_smith]

По поводу винды-линукса - это правда. Хотя бывает что и не так, куча сканеров до сих пор не работает или работает криво. 8 Фря на моем домашнем железе работает вообще-без-проблем, включая вебкамеру, esata, звук. все плюшки nvidia и прочую периферию. Как, впрочем, и линукс. Причем специально железо не выбирал. Ну и да, то, что не поддерживается - одинаково не поддерживается обеими ос - включая "очень нужный" мне фингерпринт сенсор и чуть более нужный мне мультитач на тачпаде (работает в режиме унылой эмуляции пс2 мышки).

Re: А если в конструктивное русло?

[ra_ga]

>mpd и ng_netflow

accel-pptpd & ipt_netflow(пока, правда, в ванилле его нет).

Еще примеры на netgraph?

Re: А если в конструктивное русло?

[samuel_smith]

хихи. accel-pptd это лишь pppd часть которого вынесли в ring0. MPD это несколько другое. Netgraph - это фреймворк, на котором можно реализовать все, что угодно (включая стек протоколов, см ng_bluetooth) и гибкость которую он представляет сложно переоценить. Например я использовал ng_one2many чтобы сливать часть трафика в систему мониторинга не изменяя его прохождения.

Re: А если в конструктивное русло?

[ra_ga]

>Netgraph - это фреймворк, на котором можно реализовать все, что угодно

я знаю что такое Netgraph ;) Очень многие рассказывают про его невероятную крутость и первым делом приводят mpd. Иногда вспоминают ng_netflow. А дальше примеры заканчиваются(да, есть всякая экзотика с инкапсуляцией ethernet в UDP). Думал, что вы mpd & ng_netflow не ограничитесь.

>Например я использовал ng_one2many чтобы сливать часть трафика в систему мониторинга не изменяя его прохождения.

И кому вы сливали из кернелспейса? другой ноде? Или просто на другой интерфейс? В Linux это можно делать на гигабитных скоростях через libpcap.

Re: А если в конструктивное русло?

[dadv]

netgraph можно сливать куда угодно. Хоть в UDP-сокет на удаленной машине.

Re: А если в конструктивное русло?

[ra_ga]

>netgraph можно сливать куда угодно.
это скорее из разряда экзотики. интересно куда более простая задача: сливать userspace-демону _очень быстро_. например, snort'у.

Re: А если в конструктивное русло?

[samuel_smith]

Другой ноде. Libpcap, подозреваю, даст дропы да и одним libpcap тут не обойтись, да и r0->r3->r0 скорости точно не добавит. Кроме того - я не писал, что это никак, принципиально, невозможно в Linux.

Да много для чего использовал - когда-то потребовалось много независимых nat`ов для вланов. Или вот с помощью ng_tty прокидывал сериал в другую серверную (для старой атс-ки).

Re: А если в конструктивное русло?

[ra_ga]

>Другой ноде. Libpcap, подозреваю, даст дропы да и одним libpcap тут не обойтись, да и r0->r3->r0 скорости точно не добавит.

http://www.ntop.org/PF_RING.html
А смысл сливать другой ноде таким образом? не проще спанпорт настроить? На другой ноде всё равно надо будет тащить данные в userspace для анализа.

>когда-то потребовалось много независимых nat`ов для вланов.
для этого netgraph не нужен :)

>Или вот с помощью ng_tty прокидывал сериал в другую серверную (для старой атс-ки).

аналогично. Задачка не требует какой-то фантастической производительности и решается в userspace.

Вот USB over IP - куда более полезно. Умеет это netgraph?

Re: А если в конструктивное русло?

[samuel_smith]

usb over ip на сервере? Не представляю зачем, если честно. Первая мысль - флешку примаунтить (poor man kvm), дык оно же сдохнет при ребуте ))) А модем усб и так даст нормальный ком порт при наличии дров.

В целом, думаю что если бы мне это потребовалось - написал бы ноду. "Но зачем?" ...

Re: А если в конструктивное русло?

[samuel_smith]

а, ну и по вопросам. спанпорт не проще, трафик туда уходил не весь именно потому, что железка от "всего" трафика дохла. По поводу "нетграф для этого не нужен" - ну во первых, это мне решать, во вторых - он вовсе не обязательно нужен для чего-то высокоскоростного. Это удобный фреймворк (о чем я уже писал) и попытка переосмыслить концепцию сетевого стека. Тот же блутуз точно не требует такой скорости и "мог бы работать в юзерспейс", а тем не менее его интеграция с netgraph добавила множество плюшек и выглядит (на мой субьективный взгляд) более красиво чем bluez.

Re: А если в конструктивное русло?

[_slw]

С людьми, которые самоутверждаются за счет спорных утверждений про ОС весьма сложно, Вы правы. Надеюсь, Вы не такой. У меня мотивы еще проще - я просто хочу, чтобы присутствие FreeBSD на рынке свелось до минимума. Если Вы думаете, что мне в наследство достаются отлично настроенные FreeBSD-коробки, то это не так - обычно приходят машины, которые настраивали безумные школьники. Надоело разгребать это дерьмо в 2011-м году.
а что, с другими системами (линух, виндуз) это не так?

Re: А если в конструктивное русло?

[pixtep]

Насчет freebsd я пожалуй даже соглашусь. Непонятно мне, что вы имеете против centos.

Re: А если в конструктивное русло?

[alexclear]

Я ничего не имею против CentOS.