tokra

@vop Зачем вы так делаете в линуксах в 2018 году? ^^^ Это был, больше, риторический вопрос

Зачем разводить треп бессмысленный? https://www.ssl.com/faqs/common-name/

В конфиге виртуалки поменяли тип образа с raw на qcow?

Автору тонны нефти! Но одна просьба - можно немного комментариев к примеру, для тех кто не нок)

Толстые каналы, обычно, и берут для того, что бы, когда надо, что-то быстро скачать, да и придет время видео 360 - вот тогда будет весело

А никто тут не делал оценку ценника на тарифы, что многие люди выбирают тариф по признаку - что могу оплачивать, куда правильнее сделать по другому: взять пилотный район или просто отобрать 1000 пользователей и снять им ограничения по трафику на неделю, и посмотреть как изменится потребление этих пользователей

ЧТо ceph, что glusterfs, да и все похожие проекты есть смысл, если вам нужен большой кластер, на много много много дисков, при чем строить надо не так, что к одному серваку подцепим полку из 30 дисков и ***ись, а один-два диска - один сервер, что бы при выпадении сервера, кластер не ребалансил его 30 дисков по 2-3 тера. Вообще в тестах под нагрузкой добились того, что ceph кластер не собрался, ибо когда выпал сервак, на котором было дисков суммарным объемом в 40 терабайт (данных было 70% где-то), при ребелансе большого объема данных начали сыпаться диски в других серверах, ибо диски уже имели наработку. Короче проблемы все те же, что и в рейд массивах, только не локально, а размазано по серверам) Там у каждого решения столько своих подводных камней, что жопой жуй. Вон ceph блюстор пилят, они замахнулись на то, что хранить данные в диске они будут сами, минуя фс системы. Тыц glusterfs libgfapi + qemu/kvm очень неплохо работает, с десяток нод в виртуалками, их диски собраны в пул, с репликой, сеть 10Г между нодами. Пока сплитбрейн не ловили, хотя люди грешат на гластер именно по этой проблеме.

Патч в lisg? Я вроде к нему не имею отношения, в этом треде обсуждается ipt-ratelimit как бы. ***к я, ночью спать надо

Атор был не прав, автор ***к

Элементарно - портирование на свежие вресии ядра.

Честно сказать, под линукс, я лучше не находил, жаль, что оно затухло, активно в офисе использую, даже обвязку кое какую написали)

VLAN_PLUS_VID_NO_PAD, на сколько я помню, оно из vconfig, вроде как сейчас бессмысленно

Типа рабочий вариант, сделайте по аналогии VLAN=yes TYPE=Vlan DEVICE=vlan10 PHYSDEV=ens34 VLAN_ID=10 REORDER_HDR=0 DEFROUTE=yes PEERDNS=yes PEERROUTES=yes IPV4_FAILURE_FATAL=no IPV6INIT=no IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes IPV6_FAILURE_FATAL=no NAME=inside-vlan10 UUID=6c1d0445-a440-4755-97df-c8c071458e5b ONBOOT=yes Лично меня смыщает, в вашем конфиге, отсутствие vlan id. И уберите VLAN_NAME_TYPE=VLAN_PLUS_VID_NO_PAD данную строку

Честно, я пытался все прочесть...

Ну толсто же

Очень давно была попытка договориться с майнтейнерами netfilter пропихнуть ipt_netflow, обсуждение растянулось на пару недель. Тот кто активно занимался майнтейнерством в этот момент параллельно делал ulog2, другой агрументировал что все что сделано не через conntrack не верно. Слушать о том что сделано без conntrack именно для скорости они не захотели. Делать тесты и что-то доказывать не захотели мы. Кому все это может потребоваться, соберут модуль и самостоятельно. ) Я где-то уже описывал всю эту эпопею... нашел https://habrahabr.ru/sandbox/21426/ Если кто-то захочет проявить красноречие и вести переговоры, то может себя проявить. Это будет уже 3я попытка. ) А что косается ratelimit, так он по сути еще не доделан и тащить его в таком вот виде как он есть сейчас, смысла большого нет. p.s. К примеру я изначально хотел маски и абстрактные идентификаторы для биллинга (я не заказчик). Но так как это усложняет код, то на первом этапе было сделано упрощение, а второго этапа пока не наступило. Да я читал эту эпопею, если память не подводит, ipset тоже живет отдельным проектом из-за упоротости некоторых ответственных ментейнеров, думал, со временем что-то поменялось... А вопрос к автору, был больше на будущее, хотя, если там все по прежнему с приемкой патчей, то можно даже не пытаться. Отходя от темы, читая на забугорных сайтах рассказы людей, как они пытались что-то пропихнуть в апстрим, сложилось мнение, что там "кумовство и взяточничество" помноженное на невменяемость и завышенное ЧСВ ментейнеров.

Прошу прощения, а Вы не пробовали свой модуль пропихнуть в апстрим, через тот же xtables-addons? Я уверен ваш модуль будет востребован

tc в помощь. Окей, я перефразирую, полисинг который более дружественный к настройке чем в tc

Как по мне - это вообще первый полисер в линукс

Акстись! 1. У меня лично он собирается с libressl. 2. Заявление человека не понимающего в крипте :) ссш использует криптоалгоритмы и не более, а все проблемы были с TLS. Более того, последние версии опенссш могут быть собраны вообще без *ssl либы, тогда там будет только чача20 и ед25519. У Вас, лично, может собираться с чем угодно, но никто не отменял тот факт, что есть дистрибутивы в которых, по дефолту, он собирается с библиотеками от openssl. В том же gentoo, который у меня под рукой, в дефолте он юзает dev-libs/openssl:0[static-libs(+) Я не говорю, что я специалист в безопасности, но, я сделал акцент, что openssh собирается с библиотками от openssl, в котором в последнее время находили много уязвимостей, это как бы куда важнее, чем проблема с доступностью публичных ключей

Если пошла такая пьянка, куда серьезнее проблема в том, что opeтssh юзает libcrypto при сборке, который часть openssl, а в последнем дыр понаходили за последний год - мама не горюй. Так что, если будут эксплуатировать уязвимость, то явно не в игры с открытым ключем и решением обратного преобразования односторонних функций. Хотя да, никто не отменял что генерировтаь надо связку с как можно более длинным ключом ( выше я уже писал), ну и плюс паранойя с доступ только с разрешенных ip. Ну и вообще по красоте - это запертить доступ в рута с публичных ip. Мда, если с 2008 года ничего не изменилось там и никто не перегененрировал свои ключи, то это печально.

Продемонстрируйте на практике. Следующие, те кто, последние пару лет как, не генерят связку ssh-keygen -t rsa -b 2048 ( а сейчас и 4096) с заданием пароля - сами себе злобные буратино. Ну и никто не отменял привязку доступа только с разрешенных ip, вот такая параноя.

Вот интересно, откуда пошел такой вой на счет публичных ключей в общем доступе, если они на то и публичные, что бы их можно было передать незащищенным каналом, потом этим ключем зашифровать данные, передать обратно, а вот расшифровать сможет только обладатель закрытого ключа. В чем проблема то.

Может кому будет интересно, https://bitbucket.org/sysoleg/lisg/pull-requests/2/master/diff добрый человек поправил модуль, что бы он собирался на ядрах выше 3.17. Протестировал у себя в тестовой лабе, на свежем 4.0.5-gentoo ядре - пока работает без нареканий.

EMATCH_U32 ?