​​Критические уязвимости в Mailcow

17 июня компания SonarSource опубликовала данные об обнаруженных в популярном почтовом сервере Mailcow двух серьезных уязвимостях.

‼️ CVE-2024-31204: XSS Vulnerability via Exception Handler (6,7 балла по шкале CVSS)
‼️ CVE-2024-30270: Path Traversal and Arbitrary Code Execution Vulnerability (6,8 балла по шкале CVSS)

Данные уязвимости существовали около трех лет и были исправлены в выпуске mailcow 2024-04.

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

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

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

Т.е. для угона админки нужно просто открыть письмо. Все остальное будет сделано вредоносным ПО. Технические подробности можно прочитать в первоисточнике: https://www.sonarsource.com/blog/remote-code-execution-in-mailcow-always-sanitize-error-messages/

Пользователям – проверять свои версии и обновляться, а также своевременно изучать новости от разработчиков, потому что в релизе от 4 апреля исправление этих уязвимостей было указано.

❓ Как подготовить приложение к запуску в Kubernetes?

Привет! Мы — команда Слёрма, учебный центр для айти-специалистов middle+ и фанаты k8s 😎 

И 27 июня в 18:00 мы приглашаем вас на вебинар «Адаптация приложения под Kubernetes». 

На встрече обсудим:

✔ где разворачивать базу данных, и можно ли это делать в кубе;
✔ concurrence;
✔ disruption budget;
✔ конфигурации, хранение секретов, интеграции с волтом;
✔ зависимости, кодовые базы.

Спикеры:

➡️ Кирилл Борисов, SRE Lead в MTS Digital
➡️ Виталий Лихачёв, Ex-avito Senior Software Engineer, SRE в booking.com
➡️ Виктор Попов, ecom.tech, единственный в мире малыш-девопёс

Зарегистрироваться на вебинар можно с помощью нашего бота-помощника. Подключайтесь!

🔗 ХОЧУ НА ВЕБИНАР

erid: LjN8KTFRP

​​Я спросил у ясеня…

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

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

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

Пузырьки быстро исчезли, но сомнения продолжали терзать нашего героя, и он отправился за знаниями в поисковик Google. Который и просветил его, что он только что вырастил культуру ботулизма и был буквально в шаге от получения премии Дарвина.

Причем это не я злословлю, так написал сам непосредственный участник событий: https://old.reddit.com/r/ChatGPT/comments/1diljf2/google_gemini_tried_to_kill_me

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

Потому что одно дело получить неработающую инструкцию, а другое дело своими руками приготовить один из сильнейших нейротоксинов. Хотя и положить прод по кривой инструкции – хорошего мало.

А кто будет за это отвечать? Да никто. Потому что нейросеть просто генератор некоего осмысленного текста. Ну и добавят еще пару строк в лицензионное соглашение, которое и так никто не читает, что все что вы получите не более чем художественный свист.

Поэтому спрашивать у «ясеня», конечно, можно, но надо понимать, что нейросеть не умеет говорить «я не в курсе» и спокойно выдаст вам бред разной степени правдоподобности. В общем, семь раз проверь – один отрежь!

Картинку к данному сообщению тоже нарисовала нейросеть.И я ее просил в банке нарисовать чеснок, а не картошку.

​​Гарантия по другую сторону баррикад. Разгон

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

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

Выбор железа тоже обусловлен только двумя факторами: ценой и заверениями пацанов с района о том, что оно отлично гонится.

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

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

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

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

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

Разговор с такой публикой тоже короткий, особенно если процессор прикипел к сокету, текстолит поменял цвет от нагрева, а ряд элементов выпустили волшебный дым, на котором, говорят, они работают.

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

Вторая категория – это более прошаренные товарищи, которые покупают «оверклокерское» железо и процессоры с разблокированным множителем.

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

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

Например, в руководстве к материнской плате B550M AORUS ELITE к разделу Tweaker есть следующее предупреждение (машинный перевод):

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

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

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

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

У Intel c 2012 по 2021 год существовала программа Performance Tuning Protection Plan (PTPP), которая за $20-$30 предоставляла возможность однократно заменить вышедший из строя после разгона процессор по гарантии. Но потом была тихо свернута. В наших же краях о ней вообще особо никто и не слышал.

Есть и дополнительная подлянка, материнские платы с «оверклокерскими» функциями часто при изменении соответствующих параметров BIOS предлагают согласиться с отказом от ответственности и записывают это согласие в CMOS. Таким образом отмазаться, что я не разгонял, оно само уже не прокатит.

В общем – будьте благоразумны. А разгон – это личный и осознанный риск.

Разыгрываем 5 ноутбуков! 

Роман Сакутин, известный айтишник, разыгрывает среди подписчиков своего канала ноутбуки. 

Розыгрыш через официальную функцию телеграма так, что всё честно! 

Переходите по ссылке и принимайте участие - https://t.iss.one/sakutin_csharp/2325

Обязательно подпишитесь на его канал ☝

erid: LjN8KVcFP

​​Районные сети, нулевые…

Сегодня летние выходные и серьезных тем поднимать не хочется, поэтому поговорим о делах давно минувших дней.

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

После модема это был совершенно новый мир, омрачала его только плата за трафик, а не за время. На первых порах 1 МБ трафика стоил 3,5 руб. Был я тогда молодой и холостой и сравнивать могу только с пивом. Бутылка недорого пива стоила ровно столько, пиво поприличнее стоило 6 руб. за бутылку.

На сегодня это примерно эквивалентно 50 руб. за 1 МБ. Неслабо. Это вызывало множество проблемных ситуаций с клиентами, которые привыкли к модемному доступу и недоумевали, как так, никуда не ходили и уже попали на деньги.

Ситуация осложнялась тем, что все эти районные провайдеры были мелкими фирмами или ИП, крупные конторы не горели желанием бегать и таскать витуху по квартирам, потом принимать платежи и т.д. и т.п.

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

Обычно старшие товарищи продавали не входящий трафик, а предусматривали оплату того, что больше. Из младших товарищей мало кто этим заморачивался, обычно соотношение входящего и исходящего было 1:10 и больше и клиентам продавался именно входящий трафик.

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

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

А как же борьба за клиента? А ее в те времена не было. Каждая контора монопольно владела своим районом и или к ним, или снова на модем. Вот такое богатство выбора.

А дальше там были всякие чудеса. Как-то на майские праздники на сервере биллинга закончилось место и биллинг просто перестал считать трафик, но доступ не ограничил. В тот же вечер тот факт разбежался по чатам и в сети начался «праздник скачивания».

Качали все кто хотели и все что хотели, в результате районный «провайдер» снова крепко попал на деньги.

И такая ситуация была в порядке вещей. Крупные провайдеры занимались «оптом», а интернет в дома несли местные конторки, которые явно переоценили прибыльность этого бизнеса.

Что взять с абонента? Да ничего, особенно с теми договорами что были. Авансовая схема оплаты, а если он чего сверх потребил, то просто мог уйти в туман и перестать платить. А провайдер выше своего не упустит и сдерет с такого «партнера» три шкуры.

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

Да, тут ты не сам себе хозяин, но кормят сытно и все вопросы можно куда-то вверх переправить. А что получили мы? Контроль рынка со стороны Ростелекома и большой тройки операторов. Хорошо это или плохо трудно сказать. Но в любом случае интернет сегодня – это как электричество или вода, просто должен быть.

​​Никогда такого не было и вот опять…

В свежем выпуске systemd 256.1 исправили, нет, не баг, а фичу…

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

А потом, в релизе 256 в systemd-tmpfiles добавили команду --purge, которая удаляла все файлы и каталоги, созданные через настройки systemd-tmpfiles, но забыли явно указать в документации, что это касается не только временных файлов.

В результате выполнение команды:

systemd-tmpfiles –purge

Приводило к удалению всего, что было описано в конфигурационных файлах в директории /usr/lib/tmpfiles.d, а так как там присутствовал файл home.conf, то сносило всю домашнюю директорию с папками всех пользователей.

Разработчик данной функции Лука Боккасси (Luca Boccassi) вначале не хотел признавать такое поведение ошибкой, ответив:

Таким образом, функция, которая буквально задокументирована как «все файлы и каталоги, созданные записью tmpfiles.d/, будут удалены», о чём вы ничего не знали, звучала как «хорошая идея»? Вы хотя бы пошли и посмотрели, какие записи tmpfiles.d у вас были заранее?

Может быть, не стоит просто запускать случайные команды, о которых вы ничего не знаете, игнорируя при этом то, что вам говорит документация? Просто мысль, ага.

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

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

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

​​И все-таки должен ли Linux становиться похожим на Windows?

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

Ну и мотивировку этого нововведения многие назвали притянутой. Мол сколько раз обновлялись и никогда такой ерунды не было.

Но раз в год и палка стреляет. Не так давно один молодой знакомый решил ступить на путь освоения Linux и выбрал для этого Manjaro, который почти как Ubuntu и даже лучше и т.д. и т.п.

Поставлена система была на старый ноут и время от времени он уделял ей внимание. На этот раз он решил наконец-то поставить все обновления, в которых на смену KDE 5 пришла шестая версия.

Качать было много, качать было долго, поэтому он оставил ноутбук и пошел заниматься своими делами.

Ноутбук заснул и больше не проснулся… А индикаторы активности на них перестали ставить уже давно. SSD тоже не шуршат при работе. В общем дал он ему постоять еще полчасика и перезагрузил.

И получил ошибку при запуске системы «сначала вам нужно загрузить ядро», ладно, не первый день в Linux, выбрал другое ядро – и тоже самое. В общем ни одного доступного ядра в системе не осталось.

Выяснилось, что в Arch такое бывает, особенно если прервать процесс обновления, но можно починить, выполнив следующую инструкцию…

В общем он починил. Мы решили воспроизвести проблему, взяли виртуалку с Manjaro и накатили свежих обновлений, как раз те, где пришли новые «кеды». Запустили родную утилиту из графической оболочки…

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

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

Ладно, тут все-таки полное обновление графической оболочки, скажут некоторые… А вот и нет, для сравнения мы взяли KDE Neon того релиза, где он еще на KDE 5 и также обновили его с получением новых «кед».

Но все прошло совсем по-другому, система просто скачала обновления и сказала, что нужна перезагрузка, а только потом начала их устанавливать. Да, это заняло какое-то время, 10-15 минут. Но в итоге мы корректно обновились до KDE 6 без разных нежелательных эффектов.

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

А потом не надо рассуждать почему Linux все еще с трудом входит в массы, ведь в нем почти все есть. Ключевое слово здесь – почти. Пользователь не хочет становиться специалистом в области ОС, он даже не хочет приобретать базовые навыки администрирования. Ему нужно включить и работать, у него своих дел хватает.

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

🔆 Приглашаем вас на вебинар "Знакомство с MySQL InnoDB Cluster"! 🚀
 
🧠 Мы разберём все отличия кластерного решения InnoDB Cluster от обычной репликации. Вы узнаете, как настроить и запустить рабочий кластер, получите полное представление о возможностях и ограничениях этого решения.

👍 Наш вебинар станет находкой для системных администраторов Linux, администраторов баз данных (DBA) и всех, кто хочет познакомиться с InnoDB Cluster. Вебинар откроет новые горизонты в администрировании баз данных, позволив понять основные различия архитектуры кластера и традиционной репликации.

🏆 Спикер Николай Лавлинский — технический директор в Метод Лаб, PhD Economic Science, опытный руководитель разработки и преподаватель.

⏰ Занятие пройдёт 04 июля 2024 года в 19:00 по мск в рамках курса «Инфраструктура высоконагруженных систем». Доступна рассрочка на обучение!

👉 Зарегистрируйтесь для участия https://otus.pw/83iR/ 

​​Используем команду sed для работы с текстом

Утилита sed - потоковый текстовый редактор. Широко используется для работы с потоками данных в скриптах и консольных командах. Владение данной утилитой относится к основам администрирования Linux.

В общем случае работа sed задается конструкцией:

команда/вхождение/замена/флаги

Например, результатом работы команды:

echo "Сегодня 1 апреля"  | sed 's/апреля/мая/'

Будет строка “Сегодня 1 мая” , в данном случае s – обозначает действие замены, далее идет вхождение и замена.

Если нужно выполнить несколько действий, то разделяем их точкой с запятой и добавляем ключ -e:

 "Сегодня 1 апреля"  | sed -e 's/сегодня/Завтра/i; s/апреля/мая/'

Так как мы не уверены, как именно может быть написано слово «Сегодня», то мы добавили к первому действию флаг i, который предписывает игнорировать реестр.

Пока что мы работали с потоками стандартного ввода-вывода, но также на вход можно подать файл:

 's/апреля/мая/' file.txt

Тогда будут прочитаны все строки файла и в каждой из них, при совпадении будет выполнена замена. Результат будет выведен в стандартный поток вывода, исходный файл изменен не будет.

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

Другой вариант – использовать флаг w с указанием файла, но в этом случае в него будут записаны только те строки, где была произведена замена:

sed 's/апреля/мая/w out.txt' file.txt

Если нам нужно редактировать непосредственно исходный файл, то следует запустить команду с ключом -i (не следует путать с командой i):

sed -i 's/апреля/мая/' file.txt

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

При работе с файлом можно указывать строки или диапазоны строк для замены, например только вторую строку:

sed '2s/апреля/мая/' file.txt

Или со 2 строки по 5:

sed '2,5s/апреля/мая/' file.txt

Для указания последней строки используйте символ $:

sed '5,$s/апреля/мая/' file.txt

Данная конструкция заменит вхождения с 5 строки по последнюю.

Если не указано иного, то sed заменят только первое вхождение в строке, номер вхождения можно указать при помощи флага или использовать флаг глобальной замены – g, при использовании данного флага с номером будут заменены все вхождения начиная с указанного, например, с третьего:

sed 's/апреля/мая/3g' file.txt

Кроме изменения строк sed можно использовать для удаления строк из потока, для этого просто укажите их номер или диапазон номеров:

sed '2,5d' file.txt

Также можно использовать вхождения, например, удалим все строки со словом «апреля»:

sed '/апреля/ d' file.txt

Можно использовать и несколько вхождений, но будьте осторожны, sed удалит все строки между ними:

sed '/апреля/,/мая/3d' file.txt

Также sed можно использовать для добавления строк в поток, в начало или конец потока, для добавления в начало используйте:

sed 'i\Это первая строка' file.txt

В конец:

sed 'a\Это последняя строка' file.txt

Или явно укажите номер строки от начала или конца:

sed '2i\Это вторая строка' file.txt

Команда с полностью заменит содержимое указанной строки:

sed '3c\Это новое содержимое третьей строки' file.txt

Еще одна возможность sed – замена символов, но при этом область замены нельзя ограничить, будет выполнена обработка всего потока, например заменим a на b, с на d и e на f:

sed 'y/ace/bdf/' file.txt

Это не полный набор приемов и возможностей sed, Телеграм накладывает ограничения на размер заметки, но уже этого достаточно для эффективного применения утилиты и получения новых навыков работы с текстом.

Попробовать себя в новой IT-профессии? На раз-два!

Где «раз» – вы записываетесь на подготовительный курс по Python-разработке.

А «два» – завершаете его через две недели с сертификатом и собственным проектом на руках.

С нас:
– 72 урока прямо в браузере в онлайн-тренажере;
– 3 встречи с наставником в режиме реального времени;
– 1 встреча для лайвкодинг-сессии, где вы напишете свою первую программу.

И все это за 990 рублей!

⏰ Старт уже 2 июля!

​​Критическая уязвимость в VMWare vCenter

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

Начнем с VMware vCenter Server multiple heap-overflow vulnerabilities (CVE-2024-37079, CVE-2024-37080), данной уязвимости сами разработчики присвоили уровень 9,8 по шкале CVSSv3, т.е. критический.

Она использует ошибки в реализации протокола DCERPC и позволяет злоумышленнику, сформировав специальный пакет, выполнить произвольный код на устройстве.

Обходных путей для купирования данной уязвимости нет, только установка обновлений. Без них система становится уязвима к удаленным атакам.

Вторая уязвимость VMware vCenter multiple local privilege escalation vulnerabilities (CVE-2024-37081) связана с некорректной реализацией механизма sudo, которая позволяет пользователю, не имеющему административных прав поднять их до уровня суперпользователя. Важность по шкале CVSSv3 – 7,8 (высокая).

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

А самым неприятным в данной ситуации является то, что закрываются уязвимости только обновлениями, которые требуют перехода на новую подписную модель лицензирования. Про любителей «лицензий с торрентов» мы вообще не говорим.

Причем это далеко не первый серьезный инцидент с VMWare, есть информация что недавняя атака на СДЭК, приведшая к полной остановке деятельности предприятия на несколько дней, также была осуществлена через уязвимости в данном продукте.

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

​​Песенка про дятлов

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

В частности, это касается накопителей, так как они сейчас активно развиваются и как говорится, находятся на острие прогресса.

Основным типом современного накопителя является NVMe, т.е. диск работающий с использованием указанного протокола по шине PCIe, вне зависимости от форм-фактора и разъема.

Емкости таких дисков, как и скорости постоянно растут, при этом, естественно, появляются различные проблемы и сложности которых раньше не существовало и можно подумать, что вот раньше…

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

Именно в это время IBM выпустил новаторские модели жестких дисков Deskstar 75GXP и 40GV (DTLA) прозванных в народе «дятлами». Диски использовали стеклянные пластины с плотностью записи 20 Гбайт, скорость вращения 7200 оборотов/мин и интерфейс Ultra ATA/100.

IBM в те годы была одним из признанных лидеров рынка, а «дятлы» по совокупности характеристик были одними из лучших моделей дисков, равно как и самыми дорогими. Но ведь это топ от признанного лидера, это примерно, как сегодня SSD от Samsung.

В общем, продажи шли хорошо, но… Все чаще и чаще стали поступать сообщения об отказах DTLA. Диски могли начать издавать странные звуки, стучать головами или просто стремительно сыпаться.

Поначалу серьезного значения этому никто не придал, ну бракованная партия, бывает. Но отказов было все больше и больше и стало понятно, что это не просто производственный брак.

Но сама фирма IBM попыталась сделать хорошую мину при плохой игре и обвинила в этом «неправильную» работу чипсетов Intel 440BX, AMD 751 и VIA KT133A. И если последний действительно имел кое-какие проблемы при работе с накопителями, то вносить в список массовый и популярный 440BX явно было опрометчивым действием.

Тем более что проблемы возникали и с другими чипсетами, и с аппаратными RAID-контроллерами.

Вскоре был найден еще один «виноватый», им назначили ОС семейства Windows 9х/Me, они «слишком быстро» выключали жесткий диск, что он не успевал завершить отложенную запись, что могло привести к порче данных, а в некоторых случаях и самой пластины.

Microsoft в ответ выпустила специальные исправления, но уже практически всем становилось очевидно, что проблема в конструктивных ошибках заложенных на этапе разработки дисков.

Косвенно это подтверждалось и тем, что IBM по гарантии меняла «дятлов» не на новые диски такой же модели, а на винчестеры совсем другой серии 60GXP.

Попутно предлагались совсем беспомощные решения этой проблемы, например, понизить режим с Ultra ATA/100 на Ultra ATA/33, т.е. понизить производительность в три раза и это для топовой модели диска!

А позже стало известно о том, что в апреле 2001 IBM полностью прекратила производство серии DTLA.

Итоги этой истории оказались далеко не радостными. Компания серьезно подорвала свою репутацию и по большому счету так и не оправилась после провала. Вскоре подразделение по производству жестких дисков перешло к Hitachi, а сегодня им владеет Toshiba.

Пользователи не простили компании отказ сразу признать свою ошибку и постоянное вранье с поиском и назначением «виноватых» вместо того, чтобы принять меры к исправлению ситуации. Вот так вот в одночасье жесткие диски IBM из признанных топов превратились в жупел, от которого все шарахались достаточно долгое время.

Освойте популярные подходы к мониторингу СУБД PostgreSQL в Zabbix!
 
✨ Приглашаем 27 июня в 20:00 мск на бесплатный вебинар «Мониторинг PostgreSQL в Zabbix»
 
Вебинар является частью полноценного онлайн-курса "Observability: мониторинг, логирование, трейсинг от Отус".
 
➡️ Записаться на вебинар: https://otus.pw/QGDu/?erid=LjN8KTDu8
 
На вебинаре мы разберем:
✅ основные метрики, за которыми нужно наблюдать;
✅ процессы, которые обеспечивают работоспособность кластера PostgreSQL;
✅ каким образом можно мониторить реплики и бэкапы данной СУБД;
✅ ответы на все возникающие вопросы.
 
🎙 Спикер Иван Федоров — опытный технический директор и капитан команды IBI Solutions.
 
Записывайтесь сейчас, а мы потом напомним. Участие бесплатно.