Никогда такого не было и вот опять…
В свежем выпуске systemd 256.1 исправили, нет, не баг, а фичу…
Все началось со службы systemd-tmpfiles, которая изначально предназначалась для создания, удаления и очистки временных файлов. Но по мере ее использования к ней добавили автоматическое создание разных других файлов и директорий, например, таких как /home.
А потом, в релизе 256 в systemd-tmpfiles добавили команду
В результате выполнение команды:
Приводило к удалению всего, что было описано в конфигурационных файлах в директории /usr/lib/tmpfiles.d, а так как там присутствовал файл home.conf, то сносило всю домашнюю директорию с папками всех пользователей.
Разработчик данной функции Лука Боккасси (Luca Boccassi) вначале не хотел признавать такое поведение ошибкой, ответив:
Таким образом, функция, которая буквально задокументирована как «все файлы и каталоги, созданные записью tmpfiles.d/, будут удалены», о чём вы ничего не знали, звучала как «хорошая идея»? Вы хотя бы пошли и посмотрели, какие записи tmpfiles.d у вас были заранее?
Может быть, не стоит просто запускать случайные команды, о которых вы ничего не знаете, игнорируя при этом то, что вам говорит документация? Просто мысль, ага.
В чем-то он, конечно, прав. Не стоит запускать незнакомые команды, особенно те, которые что-то удаляют, не прочитав документацию. Но и в документации такие моменты надо описывать явно, что также не было сделано.
В итоге разработчик пошел на компромисс и теперь команда работает только с явным указанием файла конфигурации и очищает только указанные в нем локации.
А мораль сей басни проста: семь раз подумай, потом проверь на виртуалке и уже после этого запускай на рабочей системе команды в работе которых ты не уверен.
В свежем выпуске 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 у вас были заранее?
Может быть, не стоит просто запускать случайные команды, о которых вы ничего не знаете, игнорируя при этом то, что вам говорит документация? Просто мысль, ага.
В чем-то он, конечно, прав. Не стоит запускать незнакомые команды, особенно те, которые что-то удаляют, не прочитав документацию. Но и в документации такие моменты надо описывать явно, что также не было сделано.
В итоге разработчик пошел на компромисс и теперь команда работает только с явным указанием файла конфигурации и очищает только указанные в нем локации.
А мораль сей басни проста: семь раз подумай, потом проверь на виртуалке и уже после этого запускай на рабочей системе команды в работе которых ты не уверен.
Я и потенциально деструктивные команды
Anonymous Poll
11%
Смело запускаю не читая
11%
Запускаю с опаской, не более
12%
Не запускаю, ну их нафиг
20%
Не запускаю, не прочитав документацию
25%
Не запускаю, пока не проверю на стенде
6%
Я вообще ничего не запускаю, только мышка, только GUI
4%
Зову системного администратора, пусть он запускает
11%
Ничего не понятно, но очень интересно
И все-таки должен ли Linux становиться похожим на Windows?
В нашей прошлой заметке, где мы рассказывали о новой автономной системе обновления Linux, было много отзывов, что это все на самом деле не нужно. Это только делает Linux больше похожим на Windows и чуть ли не покушается на свободу и неприкосновенность пользователя.
Ну и мотивировку этого нововведения многие назвали притянутой. Мол сколько раз обновлялись и никогда такой ерунды не было.
Но раз в год и палка стреляет. Не так давно один молодой знакомый решил ступить на путь освоения Linux и выбрал для этого Manjaro, который почти как Ubuntu и даже лучше и т.д. и т.п.
Поставлена система была на старый ноут и время от времени он уделял ей внимание. На этот раз он решил наконец-то поставить все обновления, в которых на смену KDE 5 пришла шестая версия.
Качать было много, качать было долго, поэтому он оставил ноутбук и пошел заниматься своими делами.
Ноутбук заснул и больше не проснулся… А индикаторы активности на них перестали ставить уже давно. SSD тоже не шуршат при работе. В общем дал он ему постоять еще полчасика и перезагрузил.
И получил ошибку при запуске системы «сначала вам нужно загрузить ядро», ладно, не первый день в Linux, выбрал другое ядро – и тоже самое. В общем ни одного доступного ядра в системе не осталось.
Выяснилось, что в Arch такое бывает, особенно если прервать процесс обновления, но можно починить, выполнив следующую инструкцию…
В общем он починил. Мы решили воспроизвести проблему, взяли виртуалку с Manjaro и накатили свежих обновлений, как раз те, где пришли новые «кеды». Запустили родную утилиту из графической оболочки…
И действительно, к концу обновления практически вся графическая часть системы сломалась. Не работала даже перезагрузка через стартовое меню, только кнопка в утилите обновления. Все запущенные приложения также побелели и отказались работать.
Не удивительно что заснувший ноутбук проснуться уже не смог. Но даже без этого ситуация для пользователя непонятная и непривычная. И риск что он принудительно перезагрузит систему, со всеми вытекающими тут велик.
Ладно, тут все-таки полное обновление графической оболочки, скажут некоторые… А вот и нет, для сравнения мы взяли KDE Neon того релиза, где он еще на KDE 5 и также обновили его с получением новых «кед».
Но все прошло совсем по-другому, система просто скачала обновления и сказала, что нужна перезагрузка, а только потом начала их устанавливать. Да, это заняло какое-то время, 10-15 минут. Но в итоге мы корректно обновились до KDE 6 без разных нежелательных эффектов.
Тем более что к такой схеме обновлений современный пользователь уже давно привык. Может она в чем-то и менее удобна, но гарантирует практически полную защиту от человеческого фактора и форс-мажора при обновлениях, в отличие от классической схемы.
А потом не надо рассуждать почему Linux все еще с трудом входит в массы, ведь в нем почти все есть. Ключевое слово здесь – почти. Пользователь не хочет становиться специалистом в области ОС, он даже не хочет приобретать базовые навыки администрирования. Ему нужно включить и работать, у него своих дел хватает.
Причем действительно хватает, на самом деле. Вот пришли вы на прием к доктору, с острой болью, а он и говорит, мол извините, принять не могу, тут после перезагрузки ядро пропало. Сейчас попробую починить по инструкции, целый час гуглил, держи таблетку аспирина, посиди вон там в коридоре, я позову…
В нашей прошлой заметке, где мы рассказывали о новой автономной системе обновления 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/
🧠 Мы разберём все отличия кластерного решения InnoDB Cluster от обычной репликации. Вы узнаете, как настроить и запустить рабочий кластер, получите полное представление о возможностях и ограничениях этого решения.
👍 Наш вебинар станет находкой для системных администраторов Linux, администраторов баз данных (DBA) и всех, кто хочет познакомиться с InnoDB Cluster. Вебинар откроет новые горизонты в администрировании баз данных, позволив понять основные различия архитектуры кластера и традиционной репликации.
🏆 Спикер Николай Лавлинский — технический директор в Метод Лаб, PhD Economic Science, опытный руководитель разработки и преподаватель.
⏰ Занятие пройдёт 04 июля 2024 года в 19:00 по мск в рамках курса «Инфраструктура высоконагруженных систем». Доступна рассрочка на обучение!
👉 Зарегистрируйтесь для участия https://otus.pw/83iR/
Используем команду sed для работы с текстом
Утилита sed - потоковый текстовый редактор. Широко используется для работы с потоками данных в скриптах и консольных командах. Владение данной утилитой относится к основам администрирования Linux.
В общем случае работа sed задается конструкцией:
Например, результатом работы команды:
Будет строка “Сегодня 1 мая” , в данном случае s – обозначает действие замены, далее идет вхождение и замена.
Если нужно выполнить несколько действий, то разделяем их точкой с запятой и добавляем ключ -e:
Так как мы не уверены, как именно может быть написано слово «Сегодня», то мы добавили к первому действию флаг i, который предписывает игнорировать реестр.
Пока что мы работали с потоками стандартного ввода-вывода, но также на вход можно подать файл:
Тогда будут прочитаны все строки файла и в каждой из них, при совпадении будет выполнена замена. Результат будет выведен в стандартный поток вывода, исходный файл изменен не будет.
В поток вывода добавляются все строки, а не только те, которые были заменены. При необходимости можете сохранить его в отдельный файл используя перенаправление.
Другой вариант – использовать флаг w с указанием файла, но в этом случае в него будут записаны только те строки, где была произведена замена:
Если нам нужно редактировать непосредственно исходный файл, то следует запустить команду с ключом -i (не следует путать с командой i):
В этом случае все замены будут произведены внутри файла, в стандартный поток вывода ничего отправляться не будет.
При работе с файлом можно указывать строки или диапазоны строк для замены, например только вторую строку:
Или со 2 строки по 5:
Для указания последней строки используйте символ $:
Данная конструкция заменит вхождения с 5 строки по последнюю.
Если не указано иного, то sed заменят только первое вхождение в строке, номер вхождения можно указать при помощи флага или использовать флаг глобальной замены – g, при использовании данного флага с номером будут заменены все вхождения начиная с указанного, например, с третьего:
Кроме изменения строк sed можно использовать для удаления строк из потока, для этого просто укажите их номер или диапазон номеров:
Также можно использовать вхождения, например, удалим все строки со словом «апреля»:
Можно использовать и несколько вхождений, но будьте осторожны, sed удалит все строки между ними:
Также sed можно использовать для добавления строк в поток, в начало или конец потока, для добавления в начало используйте:
В конец:
Или явно укажите номер строки от начала или конца:
Команда с полностью заменит содержимое указанной строки:
Еще одна возможность sed – замена символов, но при этом область замены нельзя ограничить, будет выполнена обработка всего потока, например заменим a на b, с на d и e на f:
Это не полный набор приемов и возможностей 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, Телеграм накладывает ограничения на размер заметки, но уже этого достаточно для эффективного применения утилиты и получения новых навыков работы с текстом.
РЕД ОС 8 теперь и с KDE
РЕД ОС – третья по распространению ОС на рынке импортозамещения и единственная из серьезных игроков, кто предлагает RHEL-совместимую платформу.
Причем именно RHEL-совместимую, дистрибутив не является клоном ни RHEL, ни Centos/EL. Система использует собственные репозитории со своим набором пакетов.
В прошлых версиях в качестве графической оболочки использовалась исключительно Mate, хоть и сильно кастомизированная. Но Mate – это все-таки оболочка второго эшелона, да нетребовательная, но и выглядящая непритязательно. Словом – эконом класс.
Для рабочей офисной лошадки, в общем и целом, сойдет, но есть и более требовательные пользователи.
Поэтому прочно став на ноги и получив свою долю рынка в РЕД СОФТ задумались об этом и добавили в набор оболочек KDE и GNOME.
Вариант с KDE 5 получился симпатичным, по умолчанию темная тема, выдержанная в фирменных оттенках красного, но можно легко переключиться на светлую.
Теперь не стыдно и взыскательным пользователям товар лицом показать.
РЕД ОС – третья по распространению ОС на рынке импортозамещения и единственная из серьезных игроков, кто предлагает RHEL-совместимую платформу.
Причем именно RHEL-совместимую, дистрибутив не является клоном ни RHEL, ни Centos/EL. Система использует собственные репозитории со своим набором пакетов.
В прошлых версиях в качестве графической оболочки использовалась исключительно Mate, хоть и сильно кастомизированная. Но Mate – это все-таки оболочка второго эшелона, да нетребовательная, но и выглядящая непритязательно. Словом – эконом класс.
Для рабочей офисной лошадки, в общем и целом, сойдет, но есть и более требовательные пользователи.
Поэтому прочно став на ноги и получив свою долю рынка в РЕД СОФТ задумались об этом и добавили в набор оболочек KDE и GNOME.
Вариант с KDE 5 получился симпатичным, по умолчанию темная тема, выдержанная в фирменных оттенках красного, но можно легко переключиться на светлую.
Теперь не стыдно и взыскательным пользователям товар лицом показать.
Попробовать себя в новой IT-профессии? На раз-два!
Где «раз» – вы записываетесь на подготовительный курс по Python-разработке.
А «два» – завершаете его через две недели с сертификатом и собственным проектом на руках.
С нас:
– 72 урока прямо в браузере в онлайн-тренажере;
– 3 встречи с наставником в режиме реального времени;
– 1 встреча для лайвкодинг-сессии, где вы напишете свою первую программу.
И все это за 990 рублей!
⏰ Старт уже 2 июля!
Где «раз» – вы записываетесь на подготовительный курс по 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, есть информация что недавняя атака на СДЭК, приведшая к полной остановке деятельности предприятия на несколько дней, также была осуществлена через уязвимости в данном продукте.
Ну а при невозможности своевременно установить обновления следует принять все меры по серьезному ограничению сетевого доступа к уязвимым системам.
Очередная критическая уязвимость, точнее даже несколько в популярной коммерческой системе виртуализации.
Начнем с 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 из признанных топов превратились в жупел, от которого все шарахались достаточно долгое время.
В обсуждениях ни раз и ни два поднимается вопрос «ненадежности» современной техники с ностальгическими отсылками, что раньше было лучше и что старые добрые модели до сих пор работают.
В частности, это касается накопителей, так как они сейчас активно развиваются и как говорится, находятся на острие прогресса.
Основным типом современного накопителя является 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.
Записывайтесь сейчас, а мы потом напомним. Участие бесплатно.
✨ Приглашаем 27 июня в 20:00 мск на бесплатный вебинар «Мониторинг PostgreSQL в Zabbix»
Вебинар является частью полноценного онлайн-курса "Observability: мониторинг, логирование, трейсинг от Отус".
➡️ Записаться на вебинар: https://otus.pw/QGDu/?erid=LjN8KTDu8
На вебинаре мы разберем:
✅ основные метрики, за которыми нужно наблюдать;
✅ процессы, которые обеспечивают работоспособность кластера PostgreSQL;
✅ каким образом можно мониторить реплики и бэкапы данной СУБД;
✅ ответы на все возникающие вопросы.
🎙 Спикер Иван Федоров — опытный технический директор и капитан команды IBI Solutions.
Записывайтесь сейчас, а мы потом напомним. Участие бесплатно.
Обязательное подписывание SMB-пакетов в Windows 11
С выходом Windows 11 24H2 многие пользователи столкнулись с проблемами доступа к сетевым ресурсам при помощи SMB. Виной тому изменение политики подписывания SMB-пакетов, которая по умолчанию стала обязательной.
SMB Signing - это одно из средств безопасности средств протокола общего доступа к файлам SMB/CIFS. Когда оно включено, каждое SMB сообщение подписывается в заголовке цифровой подписью.
Такая подпись позволяет гарантировать, что содержимое сообщение не было изменено и проверить подлинность отправителя. Это позволяет предотвратить реализацию SMB атак типа man-in-the-middle и NTLM relay.
Ранее SMB подписывание требовалось только при доступе к сетевым папкам SYSVOL и NETLOGON на контроллерах домена AD.
В дальнейшем данную политику обещают распространить и на другие версии Windows.
При обращении такого клиента к серверу не использующему подписывание пакетов будет появляться ошибка:
Поэтому самое время разобраться с действующими в системе политиками, для этого выполним в консоли PowerShell две команды, которые покажут настройки клиента и сервера SMB:
Например, в версии Windows 11 23H2 для клиента установлены следующие политики:
Политика EnableSecuritySignature для клиента и сервера SMB2+ игнорируется, а так как SMB1 везде по умолчанию отключен, то можем не обращать на нее внимание.
В современных системах для подписывания используется политика RequireSecuritySignature, которая определяет необходимость подписи по принципу логического ИЛИ. Т.е. если хоть одна сторона будет требовать подписывания (клиент или сервер) – пакет будет подписан.
Таким образом, чтобы отключит подписывание, мы должны отключить его и на клиенте, и на сервере.
Для этого можно использовать команды:
Если политику нужно включить, то замените $false на $true.
При этом не следует бежать и отключать требование подписи везде где только можно, потому что это довольно важное средство обеспечения безопасности, а только там, где использование подписи невозможно по техническим причинам.
Так если весь парк ПК состоит из современных систем, то имеет смысл отключать требование подписи только на клиенте, чтобы они могли работать с не умеющими подписывать пакеты серверами и оставлять ее включенной для серверов, что обеспечит использование подписи при наличии такой возможности.
С выходом Windows 11 24H2 многие пользователи столкнулись с проблемами доступа к сетевым ресурсам при помощи SMB. Виной тому изменение политики подписывания SMB-пакетов, которая по умолчанию стала обязательной.
SMB Signing - это одно из средств безопасности средств протокола общего доступа к файлам SMB/CIFS. Когда оно включено, каждое SMB сообщение подписывается в заголовке цифровой подписью.
Такая подпись позволяет гарантировать, что содержимое сообщение не было изменено и проверить подлинность отправителя. Это позволяет предотвратить реализацию SMB атак типа man-in-the-middle и NTLM relay.
Ранее SMB подписывание требовалось только при доступе к сетевым папкам SYSVOL и NETLOGON на контроллерах домена AD.
В дальнейшем данную политику обещают распространить и на другие версии Windows.
При обращении такого клиента к серверу не использующему подписывание пакетов будет появляться ошибка:
0xc000a000 The cryptographic signature is invalid
Поэтому самое время разобраться с действующими в системе политиками, для этого выполним в консоли PowerShell две команды, которые покажут настройки клиента и сервера SMB:
Get-SmbClientconfiguration | fl *sign*
Get-SmbServerconfiguration | fl *sign*
Например, в версии Windows 11 23H2 для клиента установлены следующие политики:
EnableSecuritySignature : True
RequireSecuritySignature : False
Политика EnableSecuritySignature для клиента и сервера SMB2+ игнорируется, а так как SMB1 везде по умолчанию отключен, то можем не обращать на нее внимание.
В современных системах для подписывания используется политика RequireSecuritySignature, которая определяет необходимость подписи по принципу логического ИЛИ. Т.е. если хоть одна сторона будет требовать подписывания (клиент или сервер) – пакет будет подписан.
Таким образом, чтобы отключит подписывание, мы должны отключить его и на клиенте, и на сервере.
Для этого можно использовать команды:
Set-SmbClientConfiguration -RequireSecuritySignature $false
Set-SmbServerConfiguration -RequireSecuritySignature $false
Если политику нужно включить, то замените $false на $true.
При этом не следует бежать и отключать требование подписи везде где только можно, потому что это довольно важное средство обеспечения безопасности, а только там, где использование подписи невозможно по техническим причинам.
Так если весь парк ПК состоит из современных систем, то имеет смысл отключать требование подписи только на клиенте, чтобы они могли работать с не умеющими подписывать пакеты серверами и оставлять ее включенной для серверов, что обеспечит использование подписи при наличии такой возможности.
Подписывание SMB-пакетов в Samba
В нашей предыдущей заметке мы говорили о подписывании SMB пакетов в Windows.
SMB Signing это одно из средств безопасности средств протокола общего доступа к файлам SMB/CIFS. Когда оно включено, каждое SMB сообщение подписывается в заголовке цифровой подписью. Это позволяет предотвратить реализацию SMB атак типа MitM и NTLM relay.
Начиная с Windows 11 24H2 клиент будет требовать обязательного подписывания пакетов, в дальнейшем эту политику обещают распространить на все поддерживаемые ОС.
В Linux также не трудно настроить подписывание пакетов, для этого в секции
Для сервера это
▫️ auto - подписывание SMB предлагается
▫️ mandatory - подписывание SMB обязательно
▫️ disabled - подписывание SMB отключено
По умолчанию применяется значение disabled.
Для клиента используется опция
▫️ auto - подписывание SMB предлагается
▫️ mandatory - подписывание SMB обязательно
▫️ disabled - подписывание SMB отключено
Значение по умолчанию: auto.
В современных условиях оптимальными настройками будет изменение режима сервера также на auto:
Это позволит работать с современными клиентами, не снижая уровня защиты, но при этом сохраняя совместимость с клиентами не поддерживающими подписывание.
В этом плане Samba позволяет более гибко управлять настройками чем SMB в Windows, там сторона может либо требовать подписывание для всех, либо нет, режим согласования отсутствует.
В нашей предыдущей заметке мы говорили о подписывании SMB пакетов в Windows.
SMB Signing это одно из средств безопасности средств протокола общего доступа к файлам SMB/CIFS. Когда оно включено, каждое SMB сообщение подписывается в заголовке цифровой подписью. Это позволяет предотвратить реализацию SMB атак типа MitM и NTLM relay.
Начиная с Windows 11 24H2 клиент будет требовать обязательного подписывания пакетов, в дальнейшем эту политику обещают распространить на все поддерживаемые ОС.
В Linux также не трудно настроить подписывание пакетов, для этого в секции
[global] файла smb.conf потребуется указать две опции.Для сервера это
server signing, которая может принимать следующие значения:▫️ auto - подписывание SMB предлагается
▫️ mandatory - подписывание SMB обязательно
▫️ disabled - подписывание SMB отключено
По умолчанию применяется значение disabled.
Для клиента используется опция
client signing с доступными значениями:▫️ auto - подписывание SMB предлагается
▫️ mandatory - подписывание SMB обязательно
▫️ disabled - подписывание SMB отключено
Значение по умолчанию: auto.
В современных условиях оптимальными настройками будет изменение режима сервера также на auto:
[global]
server signing = auto
Это позволит работать с современными клиентами, не снижая уровня защиты, но при этом сохраняя совместимость с клиентами не поддерживающими подписывание.
В этом плане Samba позволяет более гибко управлять настройками чем SMB в Windows, там сторона может либо требовать подписывание для всех, либо нет, режим согласования отсутствует.
Курс по нейросетям. Получите самые востребованные скиллы в 2024 году.
“Основы нейронных сетей: создание и настройка" от Академии Кодебай:
- разработка продвинутых архитектур нейронных сетей и их применение в Data Science
- решение типичных проблем при обучении сетей
Курс будет полезен, если вы:
- Аналитик данных и хотите освоить продвинутые инструменты, чтобы выйти на новый уровень
- Разработчик с опытом программирования и хотите применить свои знания в новой области
- Руководитель IT-проектов и хотите лидировать современные бизнес-процессы
Старт потока: 1 июля
Пишите нам @Codeby_Academy
Подробнее о курсе
“Основы нейронных сетей: создание и настройка" от Академии Кодебай:
- разработка продвинутых архитектур нейронных сетей и их применение в Data Science
- решение типичных проблем при обучении сетей
Курс будет полезен, если вы:
- Аналитик данных и хотите освоить продвинутые инструменты, чтобы выйти на новый уровень
- Разработчик с опытом программирования и хотите применить свои знания в новой области
- Руководитель IT-проектов и хотите лидировать современные бизнес-процессы
Старт потока: 1 июля
Пишите нам @Codeby_Academy
Подробнее о курсе
Деградация данных
Деградация данных (bitrot, битовое гниение) – это достаточно актуальный в настоящее время тип разрушения цифровых данных вследствие накопления некритичных ошибок на запоминающем устройстве.
К сожалению, многие коллеги путают деградацию с выходом из строя ячеек накопителя (бед-блоки) и не придают этому вопросу серьезного значения. А зря.
С бед-блоками достаточно эффективно позволяет справляться RAID, когда в случае ошибки чтения блок заменяется резервным, а его содержимое считывается с исправной копии. Да, возможен эффект появления скрытых бед-блоков, но он решается периодическом перечитыванием содержимого массива.
Проблема битового гниения лежит глубже и именно этот термин представляется нам наиболее удачным. Как и обычное гниение он медленно и незаметно повреждает данные до тех пор, пока разрушения не перейдут в критическую фазу.
Причинами битового гниения становятся ошибки в процессе записи, не связанные с повреждением непосредственно ячеек, они могут даже произойти в оперативной памяти и при отсутствии ECC ваши данные также могут быть незаметно повреждены.
Чаще всего деградация данных происходит при длительном хранении, вследствие деградации заряда ячейки или уровня намагниченности сектора. Ошибок чтения с накопителя это не вызывает, но приводит к нарушению целостности данных.
Как правило большинство современных форматов данных имеют избыточность и изменение одного бита может быть откорректировано встроенными средствами, но для этого эти данные нужно хотя бы открыть.
В противном случае подобные ошибки могут накапливаться и в определенный момент привести к невосстановимому повреждению данных. При этом процесс битового гниения не сопровождается ошибками чтения с накопителя и может происходить на полностью исправном диске.
А так как нет никаких ошибок, то и RAID вам ничем не поможет, особенно уровни без четности. Так, например, в случае зеркала у нас могут оказаться изменены биты в произвольных местах обоих копий. И чем больше по размеру файл и реже обращения к нему – тем вероятнее такое развитие событий.
Некоторую защиту могут предоставлять массивы с четностью (RAID 5 и 6), но здесь многое зависит от контроллера или программной реализации, главное у которых – уметь производить такую проверку в фоновом режиме.
В таком случае имея одну правильную копию и целые данные четности массив может проверить целостность данных и автоматически восстановить их.
Но оптимальным решением проблемы будет вынос таких проверок на уровень файловой системы, так как это позволяет действовать наиболее эффективно и с наименьшей нагрузкой на систему.
Современные системы с контролем целостности – это ZFS, btrfs и ReFS – и именно они рекомендуются для систем хранения больших объемов информации. Каждая из них умеет в фоновом режиме проверять целостность файлов и восстанавливать поврежденные фрагменты используя контрольные суммы (при наличии избыточности, разумеется).
И именно по этой причине тот же Proxmox категорически не рекомендует использование mdadm для хранилищ виртуальных машин в производственных средах.
Деградация данных (bitrot, битовое гниение) – это достаточно актуальный в настоящее время тип разрушения цифровых данных вследствие накопления некритичных ошибок на запоминающем устройстве.
К сожалению, многие коллеги путают деградацию с выходом из строя ячеек накопителя (бед-блоки) и не придают этому вопросу серьезного значения. А зря.
С бед-блоками достаточно эффективно позволяет справляться RAID, когда в случае ошибки чтения блок заменяется резервным, а его содержимое считывается с исправной копии. Да, возможен эффект появления скрытых бед-блоков, но он решается периодическом перечитыванием содержимого массива.
Проблема битового гниения лежит глубже и именно этот термин представляется нам наиболее удачным. Как и обычное гниение он медленно и незаметно повреждает данные до тех пор, пока разрушения не перейдут в критическую фазу.
Причинами битового гниения становятся ошибки в процессе записи, не связанные с повреждением непосредственно ячеек, они могут даже произойти в оперативной памяти и при отсутствии ECC ваши данные также могут быть незаметно повреждены.
Чаще всего деградация данных происходит при длительном хранении, вследствие деградации заряда ячейки или уровня намагниченности сектора. Ошибок чтения с накопителя это не вызывает, но приводит к нарушению целостности данных.
Как правило большинство современных форматов данных имеют избыточность и изменение одного бита может быть откорректировано встроенными средствами, но для этого эти данные нужно хотя бы открыть.
В противном случае подобные ошибки могут накапливаться и в определенный момент привести к невосстановимому повреждению данных. При этом процесс битового гниения не сопровождается ошибками чтения с накопителя и может происходить на полностью исправном диске.
А так как нет никаких ошибок, то и RAID вам ничем не поможет, особенно уровни без четности. Так, например, в случае зеркала у нас могут оказаться изменены биты в произвольных местах обоих копий. И чем больше по размеру файл и реже обращения к нему – тем вероятнее такое развитие событий.
Некоторую защиту могут предоставлять массивы с четностью (RAID 5 и 6), но здесь многое зависит от контроллера или программной реализации, главное у которых – уметь производить такую проверку в фоновом режиме.
В таком случае имея одну правильную копию и целые данные четности массив может проверить целостность данных и автоматически восстановить их.
Но оптимальным решением проблемы будет вынос таких проверок на уровень файловой системы, так как это позволяет действовать наиболее эффективно и с наименьшей нагрузкой на систему.
Современные системы с контролем целостности – это ZFS, btrfs и ReFS – и именно они рекомендуются для систем хранения больших объемов информации. Каждая из них умеет в фоновом режиме проверять целостность файлов и восстанавливать поврежденные фрагменты используя контрольные суммы (при наличии избыточности, разумеется).
И именно по этой причине тот же Proxmox категорически не рекомендует использование mdadm для хранилищ виртуальных машин в производственных средах.
Доверять мало, надо еще и проверять, причем постоянно
Все мы используем различные проекты с открытым исходным кодом, которые, в теории, более безопасны чем закрытое ПО, но в любом случае наши отношения с авторами строятся на доверии.
Но доверие – вещь такая, что ее нужно постоянно контролировать, особенно в случае смены владельца. Так и произошло с библиотекой Polyfill, это открытая JavaScript-библиотека, предназначенная для обеспечения совместимости для старых версий браузеров.
Особенность данного скрипта, что он динамически генерируется на основании User Agent и генерирует функции с реализацией недостающих методов, свойств и API в зависимости от типа и версии браузера. Поэтому его невозможно было использовать в виде локальной версии и он всегда подгружался с официального CDN разработчика.
В феврале этого года проект Polyfill был продан китайской компании Funnull. Через несколько месяцев новый владелец решил альтернативно модернизировать проект и начал выполнять при помощи библиотеки автоматическое перенаправление пользователей на сомнительные сайты, такие как букмекерские конторы или казино.
При этом библиотека отслеживала куки и если обнаруживала сессию администратора сайта, то редирект не выполнялся, при обнаружении систем веб-аналитики переход задерживался, чтобы не попадать в статистику.
Таким образом реальный владелец сайта мог долгое время находиться в неведении, а пользователи могли подумать, что перенаправление инициативой именно владельца сайта.
Также новый владелец старательно удаляет из GitHub жалобы на подобное поведение, чтобы дольше создавать у пользователей видимость непричастности библиотеки к нежелательному поведению сайта.
По предварительным оценкам пострадало более 110 тыс. сайтов, но на самом деле их может быть значительно больше.
Как быть в такой ситуации? Никакого разумного выхода здесь нет, вы или доверяете владельцу проекта или не доверяете. Но вы никак не застрахованы от его деструктивных действий (либо его преемника).
Небольшую страховку дает использование открытых проектов через посредников, например, получать пакет не из репозитория разработчика, а из репозитория дистрибутива, желательно LTS. Что оставляет вас на более старых версиях, но в тоже время страхует от подобных угроз. Как пример – недавняя уязвимость в XZ Utils.
При использовании же динамически подключаемых библиотек вам только остается доверять разработчику и время от времени контролировать состояние дел проекта, по мере сил и возможностей.
Все мы используем различные проекты с открытым исходным кодом, которые, в теории, более безопасны чем закрытое ПО, но в любом случае наши отношения с авторами строятся на доверии.
Но доверие – вещь такая, что ее нужно постоянно контролировать, особенно в случае смены владельца. Так и произошло с библиотекой Polyfill, это открытая JavaScript-библиотека, предназначенная для обеспечения совместимости для старых версий браузеров.
Особенность данного скрипта, что он динамически генерируется на основании User Agent и генерирует функции с реализацией недостающих методов, свойств и API в зависимости от типа и версии браузера. Поэтому его невозможно было использовать в виде локальной версии и он всегда подгружался с официального CDN разработчика.
В феврале этого года проект Polyfill был продан китайской компании Funnull. Через несколько месяцев новый владелец решил альтернативно модернизировать проект и начал выполнять при помощи библиотеки автоматическое перенаправление пользователей на сомнительные сайты, такие как букмекерские конторы или казино.
При этом библиотека отслеживала куки и если обнаруживала сессию администратора сайта, то редирект не выполнялся, при обнаружении систем веб-аналитики переход задерживался, чтобы не попадать в статистику.
Таким образом реальный владелец сайта мог долгое время находиться в неведении, а пользователи могли подумать, что перенаправление инициативой именно владельца сайта.
Также новый владелец старательно удаляет из GitHub жалобы на подобное поведение, чтобы дольше создавать у пользователей видимость непричастности библиотеки к нежелательному поведению сайта.
По предварительным оценкам пострадало более 110 тыс. сайтов, но на самом деле их может быть значительно больше.
Как быть в такой ситуации? Никакого разумного выхода здесь нет, вы или доверяете владельцу проекта или не доверяете. Но вы никак не застрахованы от его деструктивных действий (либо его преемника).
Небольшую страховку дает использование открытых проектов через посредников, например, получать пакет не из репозитория разработчика, а из репозитория дистрибутива, желательно LTS. Что оставляет вас на более старых версиях, но в тоже время страхует от подобных угроз. Как пример – недавняя уязвимость в XZ Utils.
При использовании же динамически подключаемых библиотек вам только остается доверять разработчику и время от времени контролировать состояние дел проекта, по мере сил и возможностей.
Хотите быстро улучшить свой английский? Актуальная лексика, понятные разборы грамматики, квизы и другие полезные материалы на канале «Гапонова и её английский»:
🔹Планы на выходные: подборка бесплатных материалов, чтобы заняться английским уже сейчас
🔹Что посмотреть и послушать на youtube
🔹Что делать, если застрял на среднем уровне и не видишь результатов?
Ещё больше английского для жизни и работы на канале Лены Гапоновой — преподавателя английского и автора курсов Gaponova School.
✅Подписывайтесь на @gaponova
erid: LjN8JyLdD
🔹Планы на выходные: подборка бесплатных материалов, чтобы заняться английским уже сейчас
🔹Что посмотреть и послушать на youtube
🔹Что делать, если застрял на среднем уровне и не видишь результатов?
Ещё больше английского для жизни и работы на канале Лены Гапоновой — преподавателя английского и автора курсов Gaponova School.
✅Подписывайтесь на @gaponova
erid: LjN8JyLdD
Можно ли восстановить данные с SSD
Несмотря на то, что твердотельные накопители давно используются в качестве основных среди пользователей и коллег до сих пор присутствуют неверные взгляды на возможность восстановления данных с таких дисков.
Поэтому предлагаем вам освежить знания на основе нашего практического материала, материал не новый, но свой актуальности он не потерял, так как заблуждений меньше не становится.
https://interface31.ru/tech_it/2022/05/mozhno-li-vosstanovit-dannye-s-tverdotel-nogo-nakopitelya-ssd.html
Несмотря на то, что твердотельные накопители давно используются в качестве основных среди пользователей и коллег до сих пор присутствуют неверные взгляды на возможность восстановления данных с таких дисков.
Поэтому предлагаем вам освежить знания на основе нашего практического материала, материал не новый, но свой актуальности он не потерял, так как заблуждений меньше не становится.
https://interface31.ru/tech_it/2022/05/mozhno-li-vosstanovit-dannye-s-tverdotel-nogo-nakopitelya-ssd.html
Настраиваем динамическое обновление DNS-сервера BIND 9 при помощи Kea DHCP
По мере роста любой сети возникает необходимость перехода от обращения к узлам с IP адресов на FQDN, что позволяет полностью отвязаться от IP-адресации и использовать постоянные и удобные для запоминания доменные имена.
А задачу преобразования доменных имен в IP-адреса берет на себя DNS-сервер.
Но как быть с узлами, которые получают IP-адрес по DHCP?
Все просто - необходимо настроить динамическое обновление записей DNS-сервера и сегодня мы расскажем, как сделать это для DHCP-сервера Kea.
https://interface31.ru/tech_it/2024/06/nastraivaem-dinamicheskoe-obnovlenie-dns-servera-bind-9-pri-pomoshhi-kea-dhcp.html
По мере роста любой сети возникает необходимость перехода от обращения к узлам с IP адресов на FQDN, что позволяет полностью отвязаться от IP-адресации и использовать постоянные и удобные для запоминания доменные имена.
А задачу преобразования доменных имен в IP-адреса берет на себя DNS-сервер.
Но как быть с узлами, которые получают IP-адрес по DHCP?
Все просто - необходимо настроить динамическое обновление записей DNS-сервера и сегодня мы расскажем, как сделать это для DHCP-сервера Kea.
https://interface31.ru/tech_it/2024/06/nastraivaem-dinamicheskoe-obnovlenie-dns-servera-bind-9-pri-pomoshhi-kea-dhcp.html
