OpenBSD 7.4

ну так как бы основную цель системы никто и не скрывает, поэтому странно называть «проактивную безопасность» заявленную как корень - параноей)

РКН уже заблокировал доступ к этому:

http://openlsd.free.fr/en/OpenLSD.html

?

Паренькам поставили задачу заработать для Амазона бабла. Пареньки с задачей справились. :)

Да и были ли деньги у того стартапа на собственную инфраструктуру? Может им надо было где-то пайплайн обкатать, а потом уже тратиться на свои сервера?

С юмором туго, да?

Да и были ли деньги у того стартапа на собственную инфраструктуру?

Сейчас расскажу, благо лично присутствовал и участвовал.

Допустим есть молодой стартап, пилящий очередной SaaS-проект из говна и палок. В какой-то момент приходят ребята из AWS и предлагают бесплатный «ваучер на пользование их инфраструктурой», на сумму в 20-30к виртуальных долларов. На полгода.

Типа вы делаете нужное и полезное дело, да и вообще мы тут стартапам помогаем.

За такой ваучер поднимается вся «королевская рать»: мощные виртуалки, SNS, балансировщики с https и генерацией сертификатов - все радости больших ребят из кровавого энтерпрайза.

Проходит полгода и сказка заканчивается - либо плати по 30к в месяц за облачную инфраструктуру (которая несмотря на все навороты простому стартапу нахер не нужна для выживания) либо идешь на хер.

А за это время уже наделаны сервисы и написан код, завязанный на инфраструктуру AWS.

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

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

Что-то подобное и предполагается, конечно. Но, как бы, гендиры и финансисты стартапов не пальцем же деланы, как-то общаются. Должны же знать судьбы товарищей через дорогу, которые попадались уже в такую мышеловку. Да и политика Амазона уже притча во язытцех. Их, как я понимаю, сейчас в корпоративном IT-мире любят «нежнее» чем IBM когда-то. Такой нежной любви даже Микрософту не досталось.

Какой-нибудь Y-combinator должен делать стойку при выделении финансирования на заявления стартаперов типа «а инфраструктуру свою мы поместим на Амазоне».

Но, как бы, гендиры и финансисты стартапов не пальцем же деланы, как-то общаются

Кому-то просто пофиг, поскольку мыслят сразу миллионами, кто-то не разбирается совсем и считает что все это слишком сложно, много откровенных «эльфов» из нового поколения, ничего не знающих о жизни вообще.

Ну и CEO/CFO в стартапе это не тоже самое что и в нормальной компании ) Это легко может быть 20-летний паренек с нулевым жизненным опытом.

Их, как я понимаю, сейчас в корпоративном IT-мире любят «нежнее» чем IBM когда-то.

Для меня (и не только меня) стало откровением когда банки начали массово переносить свою инфраструктуру в облака. Помню в 2012м разговор с директором компании-аутсорсера для банковского сектора, который был убежден что ни один банк ни при каких условиях не двинет свою инфраструктуру в «какое-то там облако».

А сейчас даже Goldman Sachs в полный рост там сидит. И Амазон был и остается главным паровозом этого движа.

Какой-нибудь Y-combinator должен делать стойку при выделении финансирования на заявления стартаперов типа «а инфраструктуру свою мы поместим на Амазоне».

Чаще всего наоборот: финансирование как раз и выделяют с конкретными требованиями по технологиям и инфраструктуре.

сейчас даже Goldman Sachs в полный рост там сидит. И Амазон был и остается главным паровозом этого движа.

Ну, некое рацио тут есть. Я вот о чем подумал. Что если альтернативой является поддерживать собственный парк каких-нибудь Z-System (в прошлом IBM 390), то еще непонятно что дешевле. Крах таких столпов как DEC и SUN и отказ того же HP от серверов на своей архитектуре много кого чему-то научил. В банках считать умеют, чай не стартап. Работа у них такая: бабло считать. Если Амазон и накернится как юрлицо (что вряд ли, но про Римскую и все прочие империи тоже так думали), то те же банки смогут откусить какую-то часть его инфраструктуры в личное пользование. А если вложились в Амазон много кто, то это скорее уже не только продажа инфраструктуры Амазоном, но и симбиоз какой-то образовался.

Вот, как бы, тот же TSMC покупает оборудование у ASML вместе с постоянным штатом инженеров из Голландии, которые на Тайване в режиме 24/7 находятся. Это что — покупка оборудования или уже симбиоз TSMC и ASML?

Вот, кстати, фото 2007года. На заднем плане развалины офиса SUN Microsystems. :)

https://photos.app.goo.gl/mL89jqariXR7Ye1t5

А каждая прослойка при обращении к базе,

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

А вот когда у тебя бегают финансовые транзакции

Бегают они в майнфреймах, весь софт обрабатывающий которые виртуализирован в этих самых майнфреймах тамошними виртуализациями вдоль и поперек. И работает все это 50 лет без проблем.

Но, как я понимаю, от данных материй «модно-молодежные» товарищи - крайне далеки

Бро, ты назвав что-то модно-молодежным, сам спецом не станешь.

Нормальные люди думают как уменьшить задержки при работе с бд и схд, а люди с докером головного мозга предлагают все засунуть в контейнеры

Нормальные люди и с докером деплоят базы без проблем, и только у специализдов немодно-немолодежных всегда докер виноват.

Ты с темы то не соскакивай, расскажи про рекомендации по деплою баз.

Я ничего в этом не понимаю,

Наверно, только прикидываешься, что не понимаешь ? ;)

позвольте поинтересоваться, каким способом РСУБД можно горизонтально масштабировать средствами кластера kubernetes ну или чего там еще?

Контейнеры позволяют масштабировать только деплой, легко добавляя новые инстансы СУБД. А кластер у СУБД при этом есть ещё и свой СУБДшный :)

Крах таких столпов как DEC и SUN и отказ того же HP от серверов на своей архитектуре много кого чему-то научил.

Удивительно, что IBM до сих пор умудряется тащить на себе как софтовую часть и z/OS, и AIX, и AS/400, и даже их уникальную аппаратную часть.

С другой стороны Sun's first major Intel/Xeon-based server product line launched in 2004, though their full transition from SPARC to Intel took several more years., а потом разорились …

Нет, с нее приходы мощнее стали :)

Не являюсь разработчиком OpenBSD, да и постоянным пользователем тоже, в основном юзаю FreeBSD или Linux, но на одном компе у стоит коллекция *BSD. OpenBSD самая юзабельная после FreeBSD, но всё же тормознутая и файловая система ненадёжная.

P.S. Обновился до 7.4 и пишу с неё, всех её пользователей поздравляю.

OpenBSD самая юзабельная после FreeBSD, но всё же тормознутая и файловая система ненадёжная.

IMHO всё же предназначение OpenBSD - это не совсем универсальная ось, а ось для запуска безопасных фрагментов инфры: шлюзы, фаерволы в т.ч. уровня приложения (L7), X11 смотрелка X приложений, запущенных на других серверах приложений (обычно Linux в виртуалках) и т.п.

Ну у IBM сервиса дофига и консалтинга. Они бы, может быть, и бросили бы z/OS из-за падения спроса, но у них штрафы за нарушение SLA такие прописаны, что дешевле тянуть. :) А клиентов в ассортименте имеется, со времен 360х, наверное, еще есть.

Мое личное наблюдение. Прилетаем в Штаты. Берем в Сан-Франциско в аэропорте машину напрокат (название прокатчика не помню, но известная какая-то), благо, контора оплачивает такие командировочные расходы. Сидят два парня за IBMовским терминалом и матричным принтером, к этому терминалу подцепленному. Ну понятно, почему матричный, квитанцию c Carbon Copy сразу печатают.

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

С другой стороны Sun's first major Intel/Xeon-based server product line launched in 2004, though their full transition from SPARC to Intel took several more years., а потом разорились …

Где-то месяц назад встречался за пивом с бывшими коллегами-DECабристами по «Анкею», так наш главный тогда ваксовый системщик сейчас в Форсе работает. Админит там все подряд. А мужику под 60. Говорит сейчас в Москве есть бешеный спрос на Сановских инжнеров. Причем не по интелям, а именно по Спаркам.... Почему? Откуда?...

Видать один мейнфрейм на всю контору этими всеми заказами и ведает. А телефонной линии с модемом достаточно.

Чем это отличается от одного Amazon на всю контору. А интернет линии достаточно. :)

Говорит сейчас в Москве есть бешеный спрос на Сановских инжнеров. Причем не по интелям, а именно по Спаркам…. Почему? Откуда?…

IMHO из той же области, что и спрос на коболистов. Сегодня есть, завтра портировали на другое, и уже нет. Всё-таки IMHO лучше оставаться в трендах современных проверенных технологий, последние лет 5-10 - это cloud native.

Бегают они в майнфреймах, весь софт обрабатывающий которые виртуализирован в этих самых майнфреймах тамошними виртуализациями вдоль и поперек. И работает все это 50 лет без проблем.

Че??? Ты реалии российской банковской системы знаешь вообще? Какие в детородный орган «майнфреймы»?

После такого, гхм «утверждения», смысла даже в дальнейшем общении - не вижу. Потому как ты даже близко не подходил к реалиям :)

С учётными. Там основную нагрузку давали относительно длительные транзакции и никто не считал секунды при выполнении запросов.

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

И вот тогда, все твои красивые цифры и так далее пойдут таким живописным лесом-полем, что сам удивишься.

5 миллионов скачиваний образа контейнера!

да-да. 5 миллионов лемингов - не могут ошибаться :) офигеть гигантская цифра :)

не рекомендуется даже виртуализировать, а не то, что в контейнер пихать

Гммм… судя по «даже», ты уверяешь, что виртуализация влечёт меньшие накладные расходы, чем контейнеризация?

Чем это отличается от одного Amazon на всю контору. А интернет линии достаточно. :)

cobol я думаю за этим всем стоит.

Гммм… судя по «даже», ты уверяешь, что виртуализация влечёт меньшие накладные расходы, чем контейнеризация?

Наоборот - накладные расходы по доступу - больше. Но и защищенность больше, чем у контейнеров.

У одного клиента как-то был заказ - сделать именно виртуализированный кластер mssql по разным цод. По итогу решили ставить выделенные сервера, а не заниматься виртуализацией.

Но на все эти эксперименты у них примерно год ушел.

И насколько будет просадка производительности в контейнерах, ты замерял? 1%?

Там не 1%, если там MS SQL, там дедлоки пойдут, транзакцию возобновлять надо и прочие прелести.

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

Почему Диасофт сам не попытался это сделать? Не было необходимости масштабировать кластер мелкобанков, состоящий в лучшем случае из двух узлов master и slave? LOL

да-да. 5 миллионов лемингов - не могут ошибаться :) офигеть гигантская цифра :)

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

Паравиртуализация сильно отличается по накладным расходам?

И кто-то использует контейнеризацию прямо на bare-metal вне виртуалок?

Там не 1%, если там MS SQL, там дедлоки пойдут, транзакцию возобновлять надо и прочие прелести.

Почему ? Чем Linux контейнеры не угодили MS SQL (Linux edition)?

https://hub.docker.com/_/microsoft-mssql-server

Я конечно не фанат бабуинты.

Но что мешает собрать аналогичный образ на базе Debian?

Почему Диасофт сам не попытался это сделать? Не было необходимости масштабировать кластер мелкобанков, состоящий в лучшем случае из двух узлов master и slave? LOL

2500 таблиц (Diasoft 5NT) и своя транзакционная логика, работающая через кучу процедур. Ты действительно просто не сталкивался с АБС.

Ну и да, они (Диасофт) пытались, получилось не очень.

Ну и да, они (Диасофт) пытались, получилось не очень.

В чём проявилось? На какой СУБД?

Тем, что в высоконагруженных системах, где идёт орда маленьких INSERTов (например, биллинг), малейшая задержка может привести к тому, что система не справится. Поэтому, если изготовитель системы не рассчитывал на контейнеризацию СУБД - сразу полезут проблемы.

Разве маленькие порции новых данных биллинга, особенно тех, которые не являются частью большой транзакции, не кладут сначала в скоростную очередь?

Из которой потом неспешно выгребают уже в СУБД большими более редкими порциями.

Зависит от реализации. Лепят кто во что горазд. Биллинг на MS Sql своими глазами видел.

Зависит от реализации. Лепят кто во что горазд.

Может быть, проблема в этом, что забыли спросить, как лучше, у архитектора?

Биллинг на MS Sql своими глазами видел.

IMHO очень удобная СУБД, наверно, самая удобная, которая мне встречалась за всё время.

Но с точки зрения надежности, производительности и т.п. hard skills IMHO IBM Db2 покруче будет.

Может быть, проблема в этом, что забыли спросить, как лучше, у архитектора?

Может. Просто, фирма чаще всего покупает готовый продукт. Что там под капотом -

Зависит от реализации. Лепят кто во что горазд.

Оракл конечно же, еще вроде были попытки на DB2. Но все это было достаточно давно, что там и как сейчас уже не представляю.

Вообще АБС это жестко централизованная система, где одна платежка может генерировать записи в таблиц так 50.

Не знаю даже есть ли вообще реализации без централизации.

Интересно, использовали ли хотя бы volume контейнера для tablespaces :)

А вообще интересно, какой контейнерный storage драйвер обычно используют для баз данных?

Я бы, наверно, замонтировал 10 гигабитный iSCSI прямо внутрь контейнера.

И если пул хранилки выдаёт сотни тысяч IOPs, то что мешает работать такому контейнеру со скоростью почти обычного bare-metal?

Что если альтернативой является поддерживать собственный парк каких-нибудь Z-System (в прошлом IBM 390), то еще непонятно что дешевле. Крах таких столпов как DEC и SUN и отказ того же HP от серверов на своей архитектуре много кого чему-то научил. В банках считать умеют, чай не стартап.

Главный аргумент против облаков был в том что фактически ключевая часть инфраструктуры отдается на аутсорс. А банки очень хорошо знают про отношение к ним аутсорсеров как к мешку с деньгами.

SLA, NDA это все конечно хорошо но если чужая теперь инфраструктура встает колом - уже не прибежишь в серверную с плеткой и не заставишь админов ночевать на рабочем месте до момента починки.

Потом безопасность. Если произойдет утечка из-за сотрудника работающего в облачном провайдере то ничего этому сотруднику сделать не получится - даже судиться с ним нереально. Да, разумеется банк получит компенсацию от провайдера, но не более. Виновник торжества свалит в закат.

Когда ты для того чтобы устроиться в банк проходишь полиграф и психологические тесты а затем еще за тобой смотрит СБ банка - согласись что желание чего-то украсть резко снижается.

Прикинься потенциальным клиентом и напиши в Диасофт, они там привыкшие к всякой дичи - перешлют своим разработчикам, те ответят.

Прикинься потенциальным клиентом и напиши в Диасофт, они там привыкшие к всякой дичи - перешлют своим разработчикам, те ответят.

Зачем мне это? Я не интересуюсь банковскими системами.

Потому что на такие вопросы может только вендор решения ответить, я не он.

Потом безопасность. Если произойдет утечка из-за сотрудника работающего в облачном провайдере то ничего этому сотруднику сделать не получится - даже судиться с ним нереально. Да, разумеется банк получит компенсацию от провайдера, но не более. Виновник торжества свалит в закат.

Сомневаюсь, что СБ банков более квалифицированные, чем СБ уровня Amazon (без учёта того, что размещать надо в РФ). Теоретически Yandex, наверно, тоже когда-нибудь сделают своё облако достаточно безопасным, куда вход осуществляется не только по SMS, LOL

Когда ты для того чтобы устроиться в банк проходишь полиграф и психологические тесты а затем еще за тобой смотрит СБ банка - согласись что желание чего-то украсть резко снижается.

Можно подумать, что если топовые хакеры из топовых спецслужб захотят (теоретически) ломануть какой-нибудь мелкий банчок, то его локальная инфра окажется безопаснее того же Amazon, к примеру ? :)

Потому что на такие вопросы может только вендор решения ответить, я не он.

Мне вообщем-то их ответ неинтересен на данный момент времени.

Сомневаюсь, что СБ банков более квалифицированные, чем СБ уровня Amazon

Ты можешь написать в Амазон или позвонить? Нет, потому что все формы обратной связи они давно убрали. И в реальности при использовании это будет каменная стена между тобой и вендором. Даже если случится утечка - ни тебе о ней не скажут ни ты сам связаться не сможешь.

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

А не надо думать про «топовых хакеров и спецслужбы». Они далеко а «мелкий банк» с своими мелкими (в масштабах Амазона) проблемами - близко.

Ты можешь написать в Амазон или позвонить? Нет, потому что все формы обратной связи они давно убрали.

Даже в Linode могу написать и вероятно позвонить (у меня English B1).

Уверен, что у Amazon не хуже, иначе бы они разорились.

Here are a few ways to contact AWS support:

    AWS Support Center: Log into your AWS account and click 'Support' at the top to access the support center. You can open a new support case here.
    Email: Send an email to aws-support@amazon.com. Make sure to include your AWS account number or account name.
    Phone: Call AWS support at +1.206.266.4064 (US toll free) or international toll numbers listed on the AWS site.
    Forums: Post questions on AWS discussion forums for the specific service you need help with.
    Developer Forums: For technical questions, post to AWS Developer Forums like forums.aws.amazon.com.
    Chat: Certain account types allow chatting with support or scheduling a call from the AWS console.
    Support Plans: Accounts with Business or Enterprise support plans allow more channels like chat, phone, etc.

Things to note when contacting AWS support:

    Make sure to have your account credentials or account number ready.
    Understand if your account has Developer, Business or Enterprise support. This affects response time and channels.
    For technical issues, prepare steps to reproduce the problem, relevant logs, code, etc.
    Check the AWS service health dashboard and forums first in case it's a known issue.
    For billing issues, know your account name, number and details of the charges.

I hope these tips help you get the AWS support you need! Let me know if you have any other questions.

И в реальности при использовании это будет каменная стена между тобой и вендором. Даже если случится утечка - ни тебе о ней не скажут ни ты сам связаться не сможешь.

Я не спец. по безопасности, но местным бумажным безопасникам я доверяю не больше Amazon. В ПФР в конце 2019-го года они не смогли уберечь даже локальный почтовый сервер от глушения Ethernet интерфейса. О чём тут еще говорить, LOL

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

А не надо думать про «топовых хакеров и спецслужбы».

Мне дома пришлось сооружать защиту от их РЭБ, сейчас уже неуязвима для применяемых до сегодняшнего дня их глушилок.

Они далеко а «мелкий банк» с своими мелкими (в масштабах Амазона) проблемами - близко.

Мелкому банку неинтересны мои проблемы, с чего бы мне внезапно стали интересны проблемы банка, LOL Эти паразиты меня одно время сильно достали своими звонками с предложениями своих кредитов.

Единственно полезный банк в РФ для получения платежей в рублях - это IMHO Авангард (причём в нём кредитов как раз почти и не предоставляют), единственно полезный банк для оплаты коммуналки - это IMHO Сбер.

Зачем нужны остальные банки - для меня большая загадка (кроме иностранных неподсанкционных свифтовых типа Кредит Европа, ОТП и т.п.). Хотя для конкуренции и поддержания Авангарда в тонусе, да пусть будут и остальные :)

… нет понятного пути для апгрейда (речь про постгрес)… одновременно новые и старые бинарники. Как это делать не собирая свои контейнеры - я не знаю…

Контейнеры-то зачем? Вторую СУБД на другом порту запустил и pg_dump –port=ПОРТ_СТАРОЙ | pg_restore –port=ПОРТ_НОВОЙ.

Главный аргумент против облаков был в том что фактически ключевая часть инфраструктуры отдается на аутсорс. А банки очень хорошо знают про отношение к ним аутсорсеров как к мешку с деньгами.

Да сам бы привел этот аргумент, но я же писал про симбиозы.

SLA, NDA это все конечно хорошо но если чужая теперь инфраструктура встает колом - уже не прибежишь в серверную с плеткой и не заставишь админов ночевать на рабочем месте до момента починки.

SLA бывает разный. Даже вон Jet Infosystems имел когда-то круглосуточный саппорт. И ребята действительно по ночам дежурили. Может и сейчас так, я не знаю. У HP был SLA, предусматривающий замену оборудования за сутки в любой точке мира.

Потом безопасность.

Я имел некий опыт общения с американскими безопасниками по работе. На удивление похожи на моих бывших коллег, пришедших из той-же гебухи в коммерческие структуры. Ну чуть не прослезился :) Их всех, походу, из одной бочки наливают. Ну, в самом деле, надо же куда-то отставников из NSA девать :)

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

Ну вот мне тоже так показалось, что это все из области портирования OpenVMS на х86. :) Типа закупил «кровавый Ынтерпрайз» санов в ассортименте в начале 2000х, а инженеры сейчас кто уехал, кто на пенсию ушел, кто на вольные хлеба.

Ну разумно, чо. Может и финансирование проекта OpenBSD какое-то есть от них. Teo тоже надо что-то кушать и детей кормить.

Даже не могу представить варианта, когда опёнок будет безальтернативным на каком-нибудь более менее свежем железе, то есть вариант когда ни фряха ни линукс там не применим, а именно опёнок. Хотя от души поздравляю фантиков этого замечательного дистрибутива BSD.