Так интернет он общий для всех, у нас стоят сервера в датацентрах США, Англии, Нидерландов — проблемы(атаки) везде одинаковые, неповерю что в Франции или где либо еще в Европе интернет другой и таких проблем там нет.
CrowdSec
Вы серьйозно думаете что администраторы провайдеров и телекомов у которых сотни тысяч абонентов в крупных городах будут ходить по квартирам абонентов и чистить их компы от вирусов? как вы это себе представляете?
Я восемь лет работаю в хостинге, я вижу откуда ддосят/брутфорсят/атакуют наши сервисы — это 90% диапазоны сетей телекомов с домашними пользователями. Мы не баним подсетями, мы по возможности использем IDP чтобы защищать свои сервисы, если мы баним адреса то на время — часы, сутки, но не месяцы.
Обратный пример — у нас тысячи VPS и Dedicated серверов, мы реагируем на абузы, мониторим аномалии трафика(исхоядщие от нас ддосы) мы мониторим диапазоны наших сетей на предмет попадания в блеклисты, по возможности партнеримся с блеклистами и тд — это большая команда как сисадминов так и просто клиентской поддержки работающая 24/7, для такойже оперативной работы при хотябы на порядок большем количистве пользователей — нужны уже сотни если не тысячи человек. Ессно этого в обчных телекомах нигде нет и не будет.
Пользуясь шаредным(общим) ип адресом вам придется нести ответственность и последствия за любые плохие действия этого ип — ип общий и ответственность тоже, помойму все логично. Пользование этим адресом услуга которую вы купили (у хостера, или интернет провайдера) не нравится — не покупайте!
Если для вас это важно — то вы найдете способы обеспечить себе доступ, от всяких прокси и впнов если вы частное лицо, до аренды внешних ип адресов вашей организацией.
Владельцы сервисов и серверов в интернете ограничивают доступ к своим сервисам и серверам так как они считают нужными, если сервис/сервер вас забанил то вы можете жаловаться владельцу или уходить к конкуренту, выбор за вами.
Если ваша почтовый ип попал в блек-лист а вы об этом не знаете — значит это для вас не критично, после пары таких инцидентов вы уже будете вкурсе об сервисах типа mxtoolbox и аналогичных, поьзоватся там бесплатным планом или может даже платным с алертами и тд.
Хостеры которые дорожат репутацией своих ип строят/покупают целые системы агрегации данных с разных блеклистов, всяких «гугл сейф бровзинг» и тд, тратят время и деньги чтобы мониторить и пресекать зловредную активность со своих ип адресов и тем самым обеспечить качественный сервис своим клиентам.
Описанный автором ужас зависит только от компетентности работников (в первую очередь админов), в некоторых местах в 2012ом году было автоматизировано почти все что только можно для того времени:
CI/CD — коммит в SVN или Mercurial приводил к автоматическому сбору RPM пакетов, потом создавалась Xen VPS из шаблона, в которой после старта устанавиливался необходимый набор RPM пакетов, запускались тесты, слались отчеты на почту.
Автоматический сетап физических серверов — загрузка по сети при помощи PXE, запускалась кик-старт инсталяция(анакондой), ОС устанавливалась, и много чего еще могло происходить автоматически.
Если процессы налажены, предсказуемы и отднотипны то автоматизировать их можно без проблем.
Еще во времена когда небыло Ansible и Puppet (или они небыли еще так популярны) все настройки заворачивали в rpm пакеты, исходники которых хранились в репозиториях.
И никто не называл это DevOps это была просто автоматизация.
Меня смущает то что вы почемуто решили что TRIM нужен на серверных SSD.
«Redhat не даром её из кодовой базы выпил к чертям.» я лично считаю что это решение было политическим ради того чтобы не уменьшалась доля xfs.
Чтото я не могу нагуглить «эпичный тред на IXBT про btrfs», поделитесь ссылкой пожалуста.
Спасибо за проделанный труд и интересное сравнение, правда ОС обычно выбирается исключительно под задачи.
Так как я работаю восновном с веб и почтовым хостингом то в этих прикладных областях доля FreeBSD ничтожно мала.
Также отмечу что для СХД FreeBSD (FreeNAS и аналоги) встречается часто благодаря zfs.
Если есть ниши где FreeBSD также используется широко — расскажите об этом, думаю всем будет интересно узнать.
Я предполагаю что мы говорим про администрирование серверов, и возможно СХД и странно читать что:
«Поддержка TRIM появилась лишь в прошлом году, по сути не позволяв достойно использовать ZFS на SSD.»
Вас не смущает что в большинстве RAID контроллеров нет поддержки TRIM?
И это нисколько не мешает использовать SSD.
TRIM имеет смысл только на десктопных SSD, для серверных он не нужен.
И немножко про zfs:
zfs является бесспорно отличной ФС, также в линуксе уже давно есть btrfs кторая сейчас является достойной альтернативой zfs.
У крупных хостеров и регистраторов доменов часто есть страничка статусов где видно бывшие, текущие аварии и тех работы и извещения о планируемых тех работах. Если хостер большой и есть такая страничка то там можно найти много полезной инфы. На что стоит обратить внимание:
1 Колво информации, у понастоящему крупных компаний в месяц может быть больше десятка разных меропрятий — тех работы на разных сервисах и аварии/незапланированные тех работы, если же инфы мало то хостер: или не крупный, или скрывает свои проблемы.
2 Количество аварий — можно почитать у каких сервисов и как часто бывают аварии или «незапланированные тех работы»
3 Скорость рещения проблем.
Полностью устраивает — всегда интересно узнать чужие use-case и точку зрения, временами позволяет взглянуть на собственные задачи и проблемы с новой стороны.
Вы серьйозно думаете что администраторы провайдеров и телекомов у которых сотни тысяч абонентов в крупных городах будут ходить по квартирам абонентов и чистить их компы от вирусов? как вы это себе представляете?
Я восемь лет работаю в хостинге, я вижу откуда ддосят/брутфорсят/атакуют наши сервисы — это 90% диапазоны сетей телекомов с домашними пользователями. Мы не баним подсетями, мы по возможности использем IDP чтобы защищать свои сервисы, если мы баним адреса то на время — часы, сутки, но не месяцы.
Обратный пример — у нас тысячи VPS и Dedicated серверов, мы реагируем на абузы, мониторим аномалии трафика(исхоядщие от нас ддосы) мы мониторим диапазоны наших сетей на предмет попадания в блеклисты, по возможности партнеримся с блеклистами и тд — это большая команда как сисадминов так и просто клиентской поддержки работающая 24/7, для такойже оперативной работы при хотябы на порядок большем количистве пользователей — нужны уже сотни если не тысячи человек. Ессно этого в обчных телекомах нигде нет и не будет.
Если для вас это важно — то вы найдете способы обеспечить себе доступ, от всяких прокси и впнов если вы частное лицо, до аренды внешних ип адресов вашей организацией.
Владельцы сервисов и серверов в интернете ограничивают доступ к своим сервисам и серверам так как они считают нужными, если сервис/сервер вас забанил то вы можете жаловаться владельцу или уходить к конкуренту, выбор за вами.
Если ваша почтовый ип попал в блек-лист а вы об этом не знаете — значит это для вас не критично, после пары таких инцидентов вы уже будете вкурсе об сервисах типа mxtoolbox и аналогичных, поьзоватся там бесплатным планом или может даже платным с алертами и тд.
Хостеры которые дорожат репутацией своих ип строят/покупают целые системы агрегации данных с разных блеклистов, всяких «гугл сейф бровзинг» и тд, тратят время и деньги чтобы мониторить и пресекать зловредную активность со своих ип адресов и тем самым обеспечить качественный сервис своим клиентам.
CI/CD — коммит в SVN или Mercurial приводил к автоматическому сбору RPM пакетов, потом создавалась Xen VPS из шаблона, в которой после старта устанавиливался необходимый набор RPM пакетов, запускались тесты, слались отчеты на почту.
Автоматический сетап физических серверов — загрузка по сети при помощи PXE, запускалась кик-старт инсталяция(анакондой), ОС устанавливалась, и много чего еще могло происходить автоматически.
Если процессы налажены, предсказуемы и отднотипны то автоматизировать их можно без проблем.
Еще во времена когда небыло Ansible и Puppet (или они небыли еще так популярны) все настройки заворачивали в rpm пакеты, исходники которых хранились в репозиториях.
И никто не называл это DevOps это была просто автоматизация.
«Redhat не даром её из кодовой базы выпил к чертям.» я лично считаю что это решение было политическим ради того чтобы не уменьшалась доля xfs.
Чтото я не могу нагуглить «эпичный тред на IXBT про btrfs», поделитесь ссылкой пожалуста.
Так как я работаю восновном с веб и почтовым хостингом то в этих прикладных областях доля FreeBSD ничтожно мала.
Также отмечу что для СХД FreeBSD (FreeNAS и аналоги) встречается часто благодаря zfs.
Если есть ниши где FreeBSD также используется широко — расскажите об этом, думаю всем будет интересно узнать.
Я предполагаю что мы говорим про администрирование серверов, и возможно СХД и странно читать что:
«Поддержка TRIM появилась лишь в прошлом году, по сути не позволяв достойно использовать ZFS на SSD.»
Вас не смущает что в большинстве RAID контроллеров нет поддержки TRIM?
И это нисколько не мешает использовать SSD.
TRIM имеет смысл только на десктопных SSD, для серверных он не нужен.
И немножко про zfs:
zfs является бесспорно отличной ФС, также в линуксе уже давно есть btrfs кторая сейчас является достойной альтернативой zfs.
У крупных хостеров и регистраторов доменов часто есть страничка статусов где видно бывшие, текущие аварии и тех работы и извещения о планируемых тех работах. Если хостер большой и есть такая страничка то там можно найти много полезной инфы. На что стоит обратить внимание:
1 Колво информации, у понастоящему крупных компаний в месяц может быть больше десятка разных меропрятий — тех работы на разных сервисах и аварии/незапланированные тех работы, если же инфы мало то хостер: или не крупный, или скрывает свои проблемы.
2 Количество аварий — можно почитать у каких сервисов и как часто бывают аварии или «незапланированные тех работы»
3 Скорость рещения проблем.
Спасибо за ответ.