❓ Хотите научиться запускать сайты на Linux с нуля?
На открытом уроке «Запускаем CMS Wordpress на Ubuntu 24.04» вы освоите настройку полного окружения для работы сайта.
💪 Что вы узнаете:
— Как установить и настроить веб-сервер Angie, PHP-FPM и MySQL.
— Как развернуть WordPress на чистой системе Ubuntu 24.04.
— Как создать полнофункциональный сайт с минимальными ресурсами.
⭐ Спикер Николай Лавлинский — технический директор в Метод Лаб, PhD Economic Science, опытный руководитель разработки и преподаватель.
⏰ Встречаемся 12 февраля в 19:00 мск. Урок проходит в преддверии старта курса «Administrator Linux. Basic», а участники получат скидку на обучение.
👉 Сделайте первый шаг к профессии администратора Linux или запустите свой веб-проект: https://otus.pw/cYLN/?erid=2W5zFJhhwcU
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
На открытом уроке «Запускаем CMS Wordpress на Ubuntu 24.04» вы освоите настройку полного окружения для работы сайта.
💪 Что вы узнаете:
— Как установить и настроить веб-сервер Angie, PHP-FPM и MySQL.
— Как развернуть WordPress на чистой системе Ubuntu 24.04.
— Как создать полнофункциональный сайт с минимальными ресурсами.
⭐ Спикер Николай Лавлинский — технический директор в Метод Лаб, PhD Economic Science, опытный руководитель разработки и преподаватель.
⏰ Встречаемся 12 февраля в 19:00 мск. Урок проходит в преддверии старта курса «Administrator Linux. Basic», а участники получат скидку на обучение.
👉 Сделайте первый шаг к профессии администратора Linux или запустите свой веб-проект: https://otus.pw/cYLN/?erid=2W5zFJhhwcU
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
🤡6🤮4❤2
Б/у диски Seagate массово продаются под видом новых.
Еще с января не утихает скандал с массовой продажей в розницу б/у серверных дисков Seagate под видом новых.
Первыми о таких случаях сообщили продавцы из Германии, а на настоящий момент поддельная продукция была обнаружена и в других странах Европы, Австралии, Тайланде, Японии.
Диски имеют сброшенный SMART, что создает иллюзию нового, но если сделать запрос к счетчику продолжительности использования FARM, то будет виден реальный пробег диска, который составляет от 15 000 до 50 000 часов.
Продавцы уверяют, что не имели понятия о том, что торгуют поддельными дисками. Компания Seagate также утверждает о своей непричастности к произошедшему и обещала начать собственное расследование.
Его предварительные результаты ведут к китайским майнинговым фермам, которые добывали монету Chia. Теперь, после падения рентабельности многие фермы закрылись и на рынок выплеснулось большое количество бывших в интенсивном употреблении дисков.
Дальше кто-то из ушлых китайских товарищей подсуетился, а кто-то из дистрибьюторов польстился на низкую цену не проверив происхождение товара. Теперь же, когда подлог вскрылся, под ударом оказались и продавцы, и производитель.
Также стоит ожидать появления такой продукции как на китайских площадках, так и на вторичном рынке, в т.ч. и в мелкой рознице, которая может сама не знать, что продает.
Поэтому крайне внимательно относитесь к покупке такой продукции и обязательно проверяйте реальную наработку, это можно сделать официальной утилитой с сайта производителя.
Еще с января не утихает скандал с массовой продажей в розницу б/у серверных дисков Seagate под видом новых.
Первыми о таких случаях сообщили продавцы из Германии, а на настоящий момент поддельная продукция была обнаружена и в других странах Европы, Австралии, Тайланде, Японии.
Диски имеют сброшенный SMART, что создает иллюзию нового, но если сделать запрос к счетчику продолжительности использования FARM, то будет виден реальный пробег диска, который составляет от 15 000 до 50 000 часов.
Продавцы уверяют, что не имели понятия о том, что торгуют поддельными дисками. Компания Seagate также утверждает о своей непричастности к произошедшему и обещала начать собственное расследование.
Его предварительные результаты ведут к китайским майнинговым фермам, которые добывали монету Chia. Теперь, после падения рентабельности многие фермы закрылись и на рынок выплеснулось большое количество бывших в интенсивном употреблении дисков.
Дальше кто-то из ушлых китайских товарищей подсуетился, а кто-то из дистрибьюторов польстился на низкую цену не проверив происхождение товара. Теперь же, когда подлог вскрылся, под ударом оказались и продавцы, и производитель.
Также стоит ожидать появления такой продукции как на китайских площадках, так и на вторичном рынке, в т.ч. и в мелкой рознице, которая может сама не знать, что продает.
Поэтому крайне внимательно относитесь к покупке такой продукции и обязательно проверяйте реальную наработку, это можно сделать официальной утилитой с сайта производителя.
👌25👍14❤1😱1
Lithnet Password Protection for Active Directory (LPP)
Lithnet Password Protection for Active Directory (LPP) – приложение с открытым исходным кодом, который добавляет в Active Directory дополнительный фильтр паролей, который позволяет контролировать соответствие паролей пользователей расширенным требованиям.
Для чего это нужно? Стандартная политика паролей Windows позволяет задавать лишь общие требования к паролям и не позволяет выполнять их дополнительную проверку, например, политике будет полностью соответствовать такой пароль: Pa$$word1
Это позволяет пользователям обходить формальные требования и использовать фактически слабые пароли. LPP позволяет решить эту проблему используя внутреннюю базу запрещенных слов, при этом будут учитываться все типовые замены и обфускации.
Например, если мы добавим в базу слово password то программа заблокирует такие варианты как Pa$$word1, P@ssw0rd, pa55word! Или password123456!'
Для тех, кто хочет большего, можно подключить внешнюю базу Have I Been Pwned (HIBP), которая содержит скомпрометированные пароли, для этого вам понадобится около 8 ГБ свободного места.
После чего вы можете проверить уже имеющиеся пароли на их компрометацию, для этой проверки не требуется интернет и хеш пароля не покидает контроллер домена. Для параноиков поясняем – вся работа со скачанной базой производится сугубо локально.
Любите использовать регулярные выражения? Здесь тоже есть широкое поле, укажите регулярки под которые должен или наоборот не должен попадать пароль.
Также вы можете установить разные требования для паролей разной длинны, скажем требовать для коротких паролей обязательного наличия специальных символов, а для более длинных достаточно будет только цифр и букв.
Можно также использовать бальную систему, когда за определенные символы и комбинации присваивается некоторое количество баллов и пользователь должен получить не менее некоторого минимального значения.
Продукт полностью интегрирован с PowerShell и удобно управляется с его помощью, а также поставляется с набором собственных групповых политик, позволяющих гибко применять его возможности в домене.
И все это, как мы уже говорили – бесплатно, по лицензии MIT.
✅ Страница проекта: https://github.com/lithnet/ad-password-protection
Lithnet Password Protection for Active Directory (LPP) – приложение с открытым исходным кодом, который добавляет в Active Directory дополнительный фильтр паролей, который позволяет контролировать соответствие паролей пользователей расширенным требованиям.
Для чего это нужно? Стандартная политика паролей Windows позволяет задавать лишь общие требования к паролям и не позволяет выполнять их дополнительную проверку, например, политике будет полностью соответствовать такой пароль: Pa$$word1
Это позволяет пользователям обходить формальные требования и использовать фактически слабые пароли. LPP позволяет решить эту проблему используя внутреннюю базу запрещенных слов, при этом будут учитываться все типовые замены и обфускации.
Например, если мы добавим в базу слово password то программа заблокирует такие варианты как Pa$$word1, P@ssw0rd, pa55word! Или password123456!'
Для тех, кто хочет большего, можно подключить внешнюю базу Have I Been Pwned (HIBP), которая содержит скомпрометированные пароли, для этого вам понадобится около 8 ГБ свободного места.
После чего вы можете проверить уже имеющиеся пароли на их компрометацию, для этой проверки не требуется интернет и хеш пароля не покидает контроллер домена. Для параноиков поясняем – вся работа со скачанной базой производится сугубо локально.
Любите использовать регулярные выражения? Здесь тоже есть широкое поле, укажите регулярки под которые должен или наоборот не должен попадать пароль.
Также вы можете установить разные требования для паролей разной длинны, скажем требовать для коротких паролей обязательного наличия специальных символов, а для более длинных достаточно будет только цифр и букв.
Можно также использовать бальную систему, когда за определенные символы и комбинации присваивается некоторое количество баллов и пользователь должен получить не менее некоторого минимального значения.
Продукт полностью интегрирован с PowerShell и удобно управляется с его помощью, а также поставляется с набором собственных групповых политик, позволяющих гибко применять его возможности в домене.
И все это, как мы уже говорили – бесплатно, по лицензии MIT.
✅ Страница проекта: https://github.com/lithnet/ad-password-protection
👍54🔥7
❗️Освойте новые инструменты DevOps и администрирования со скидкой до 15 000₽
Хотите вырасти как специалист и работать на более сложных проектах?
▶️Собрали курсы, которые охватывают весь спектр необходимых знаний и инструментов для профессионального роста 一 от контейнеризации с Docker и оркестрации с Kubernetes, до автоматизации CI/CD и управления облачной инфраструктурой.
▶️Вы научитесь мониторить и логировать системы, строить надежные CI/CD пайплайны, предоставлять и поддерживать вычислительную инфраструктуру с помощью кода, балансировать нагрузку БД и многое другое.
🎁А чтобы учиться было еще приятнее, всем инженерам, администраторам и DevOps дарим промокод FEB25 на скидку 15000₽
*ввести его можно в окне оплаты, оно откроется после заполнения формы контактов
Переходите по ссылке и расширяйте свой стек технологий, чтобы с легкостью управлять сложными проектами и стать незаменимым в любой IT-команде.
#реклама
О рекламодателе
Хотите вырасти как специалист и работать на более сложных проектах?
▶️Собрали курсы, которые охватывают весь спектр необходимых знаний и инструментов для профессионального роста 一 от контейнеризации с Docker и оркестрации с Kubernetes, до автоматизации CI/CD и управления облачной инфраструктурой.
▶️Вы научитесь мониторить и логировать системы, строить надежные CI/CD пайплайны, предоставлять и поддерживать вычислительную инфраструктуру с помощью кода, балансировать нагрузку БД и многое другое.
🎁А чтобы учиться было еще приятнее, всем инженерам, администраторам и DevOps дарим промокод FEB25 на скидку 15000₽
*ввести его можно в окне оплаты, оно откроется после заполнения формы контактов
Переходите по ссылке и расширяйте свой стек технологий, чтобы с легкостью управлять сложными проектами и стать незаменимым в любой IT-команде.
#реклама
О рекламодателе
😢1
Резервные копии Active Direcitory
Вынесенная в заголовок тема давно служит предметом споров, в частности многих смущают противоречивые, я бы даже сказал – взаимоисключающие рекомендации, которые звучат примерно так: резервные копии контроллеров домена делать надо, но восстанавливать их из резервных копий не следует!
В чем причина? А причина в USN Rollback – главной страшилке системных администраторов былых времён. Сейчас получить USN Rollback все так же можно, но никаких особых последствий у вас не будет.
Чтобы понять, что такое USN Rollback нужно немного углубиться в работу репликации базы данных AD. Для того, чтобы не гонять каждый раз по сети всю базу контроллеры передают только измененные объекты.
Каждое изменение метаданных AD снабжается специальным идентификатором контроллера домена - Invocation ID - и последовательным номером – USN.
Другие контроллеры, выполнив репликацию, запоминают этот идентификатор и USN, после чего при следующей репликации будут запрашивать объекты с USN указанного номера.
При USN Rollback у контролера уменьшается текущий максимальный номер USN, и он начинает создавать изменения, которые никогда не будут реплицированы, чем переводит базу AD в рассогласованное состояние.
Чем это чревато? Различными тяжелыми глюками и ошибками работы AD, вплоть до ситуации полного хаоса в сети, когда пользователи аутентифицируются через раз, политики работают не так как следует и т.д. и т.п.
Начиная с 2012 Microsoft добавила ряд функций препятствующих такому развитию событий, в частности обнаружение USN Rollback, когда контроллер перед началом репликации запрашивает сохраненные USN с других контролеров в сети.
Если полученное значение превышает собственный максимальный USN, то на контроллере полностью блокируется репликация, а службы Active Directory переводятся в приостановленное состояние.
Но если у контроллера долгое время не было связи с AD и на нем активно вносились изменения, то может оказаться, что максимальный USN контроллера окажется выше и обнаружения USN Rollback не произойдет, после чего мы снова получим весь спектр чудес в одном флаконе.
Ситуацию осложняет еще и то, что современные администраторы скорее всего никогда не сталкивались с этой бедой, не знают ее симптомов и будут искать не там, где нужно, а там, где светлее.
Что касается восстановления контроллера через родной режим службы восстановления каталогов (вам понадобится резервная копия, сделанная службой Windows Server Backup), то в конце восстановления контроллеру меняют Invocation ID, что заставляет остальные контроллеры считать его новым контроллером в AD и начать репликацию с ним «с чистого листа».
Поэтому мы не видим насущной необходимости восстанавливать сбойный КД, в лучшем случае вы потратите на восстановление столько же времени, сколько на настройку нового КД, а то и гораздо больше, так как настройка КД – задача привычная, а восстановление – новая и не совсем понятная.
В худшем, если бекап был сделан программой не умеющей восстанавливать KД (а именно менять Invocation ID), то вы потеряете контроллер и вам все равно придется настраивать его заново.
Так для чего же нужна резервная копия контроллеров AD? А нужна она на случай, если вы серьезно нарушите текущую структуру AD или внесете туда несовместимые с нормальной работой изменения.
В этом случае вам придется понизить все контроллеры кроме одного, восстановить его из резервной копии, а затем снова добавить нужное количество контроллеров.
Но мы надеемся, что данной ситуации у вас не возникнет.
Вынесенная в заголовок тема давно служит предметом споров, в частности многих смущают противоречивые, я бы даже сказал – взаимоисключающие рекомендации, которые звучат примерно так: резервные копии контроллеров домена делать надо, но восстанавливать их из резервных копий не следует!
В чем причина? А причина в USN Rollback – главной страшилке системных администраторов былых времён. Сейчас получить USN Rollback все так же можно, но никаких особых последствий у вас не будет.
Чтобы понять, что такое USN Rollback нужно немного углубиться в работу репликации базы данных AD. Для того, чтобы не гонять каждый раз по сети всю базу контроллеры передают только измененные объекты.
Каждое изменение метаданных AD снабжается специальным идентификатором контроллера домена - Invocation ID - и последовательным номером – USN.
Другие контроллеры, выполнив репликацию, запоминают этот идентификатор и USN, после чего при следующей репликации будут запрашивать объекты с USN указанного номера.
При USN Rollback у контролера уменьшается текущий максимальный номер USN, и он начинает создавать изменения, которые никогда не будут реплицированы, чем переводит базу AD в рассогласованное состояние.
Чем это чревато? Различными тяжелыми глюками и ошибками работы AD, вплоть до ситуации полного хаоса в сети, когда пользователи аутентифицируются через раз, политики работают не так как следует и т.д. и т.п.
Начиная с 2012 Microsoft добавила ряд функций препятствующих такому развитию событий, в частности обнаружение USN Rollback, когда контроллер перед началом репликации запрашивает сохраненные USN с других контролеров в сети.
Если полученное значение превышает собственный максимальный USN, то на контроллере полностью блокируется репликация, а службы Active Directory переводятся в приостановленное состояние.
Но если у контроллера долгое время не было связи с AD и на нем активно вносились изменения, то может оказаться, что максимальный USN контроллера окажется выше и обнаружения USN Rollback не произойдет, после чего мы снова получим весь спектр чудес в одном флаконе.
Ситуацию осложняет еще и то, что современные администраторы скорее всего никогда не сталкивались с этой бедой, не знают ее симптомов и будут искать не там, где нужно, а там, где светлее.
Что касается восстановления контроллера через родной режим службы восстановления каталогов (вам понадобится резервная копия, сделанная службой Windows Server Backup), то в конце восстановления контроллеру меняют Invocation ID, что заставляет остальные контроллеры считать его новым контроллером в AD и начать репликацию с ним «с чистого листа».
Поэтому мы не видим насущной необходимости восстанавливать сбойный КД, в лучшем случае вы потратите на восстановление столько же времени, сколько на настройку нового КД, а то и гораздо больше, так как настройка КД – задача привычная, а восстановление – новая и не совсем понятная.
В худшем, если бекап был сделан программой не умеющей восстанавливать KД (а именно менять Invocation ID), то вы потеряете контроллер и вам все равно придется настраивать его заново.
Так для чего же нужна резервная копия контроллеров AD? А нужна она на случай, если вы серьезно нарушите текущую структуру AD или внесете туда несовместимые с нормальной работой изменения.
В этом случае вам придется понизить все контроллеры кроме одного, восстановить его из резервной копии, а затем снова добавить нужное количество контроллеров.
Но мы надеемся, что данной ситуации у вас не возникнет.
👍65
И снова нестареющая классика, ибо в очередной раз сегодня слушали про первичные контроллеры и прочую ересь.
Мифы и легенды Active Directory. Хозяева ролей FSMO
Active Directory, как и любая серьезная система с долгой историей успела приобрести свой фольклор, неотъемлемой частью которого являются мифы и легенды.
А одной из самых мифологизированных тем являются хозяева операций, они же роли FSMO, большее количество фантазий и суеверий существует разве что на тему равноправия контроллеров домена, но о них мы поговорим в другой раз.
Сегодня же попытаемся понять, что делают и чего не делают хозяева операций, для чего они вообще нужны и можно ли жить без них.
https://interface31.ru/tech_it/2022/06/mify-i-legendy-active-directory-hozyaeva-roley-fsmo.html
Мифы и легенды Active Directory. Хозяева ролей FSMO
Active Directory, как и любая серьезная система с долгой историей успела приобрести свой фольклор, неотъемлемой частью которого являются мифы и легенды.
А одной из самых мифологизированных тем являются хозяева операций, они же роли FSMO, большее количество фантазий и суеверий существует разве что на тему равноправия контроллеров домена, но о них мы поговорим в другой раз.
Сегодня же попытаемся понять, что делают и чего не делают хозяева операций, для чего они вообще нужны и можно ли жить без них.
https://interface31.ru/tech_it/2022/06/mify-i-legendy-active-directory-hozyaeva-roley-fsmo.html
👍35🌭3
Мифы и легенды Active Directory – откуда ноги растут
Как мы уже неоднократно говорили, администраторы Active Directory очень часто подвержены множественным заблуждениям, из которых уже сформировался устойчивый набор мифов и легенд.
Как водится, происхождение всего этого мифотворчества уходит своими корнями в далекие времена Windows NT, т.е. до 2000 года. Фактически уже выросло второе поколение специалистов, которые эту самую NT в глаза не видели, но тем не менее подвержены распространенным заблуждениям.
Поэтому предлагаем вам немного окунуться в историю и понять, чем являлся домен NT и что изменилось с приходом Active Directory.
Домен NT (NTDS) являлся реализаций службы каталогов от Microsoft доступный в серверной операционной системе Windows NT Server. И состоял из одного первичного контроллера домена – PDC (Primary Domain Controller) и неограниченного количества резервных – BDC (Backup Domain Controllers).
Именно на первичном контроллере хранилась основная база домена и все изменения в нее могли вноситься только на нем. Затем эта база реплицировалась на остальные резервные контроллеры, после чего они тоже могли начать обрабатывать клиентские запросы.
Если первичный контроллер выходил из строя, то домен фактически переходил в режим «только чтение». При его окончательной утере первичным можно было сделать один из резервных контроллеров.
Но это была достаточно непростая задача, учитывая, что выбор роли определялся только на этапе установки и его нельзя было изменить без переустановки системы. Т.е. мы не могли добавить уже существующему серверу роль контроллера или понизить его до рядового. Также сделав резервный контроллер основным, нельзя было снова изменить его роль на резервный.
Чтобы понять все сложности, с которыми сталкивались администраторы тех лет следует вспомнить, что виртуализация в те времена была чем-то из области научной фантастики и сервера были железными. И было их обычно не очень много, поэтому кроме роли контроллера они совмещали в себе еще множество функций и переустановка такого сервера была крайне непростой задачей.
А при появлении нового сервера приходилось крепко думать, будет ли он контроллером домена или нет. Так как изменить его назначение без переустановки было невозможно.
Также схема один PDC – много BDC имела серьезные проблемы с репликацией, особенно для удаленных филиалов с учетом скоростей и качества каналов связи того времени. При том, что удаленный филиал сам не мог внести необходимые данные в домен, так как для этого требовался первичный контроллер.
Поэтому с приходом Windows 2000 и Active Directory от данной схемы отказались, с этого момента все контроллеры домена стали равнозначны и каждый из них мог вносить изменения в базу домена, потом обмениваясь измененными данными. А для контроля целостности и уникальности данных были созданы хозяева операций.
Также теперь любой сервер мог стать контроллером домена или перестать им быть без переустановки, что значительно облегчило администрирование и планирование инфраструктуры.
Но несмотря на то, что Active Directory скоро разменяет четверть века многие коллеги все еще продолжают оперировать устаревшими терминами и понятиями системы, которую никогда в глаза не видели.
Как мы уже неоднократно говорили, администраторы Active Directory очень часто подвержены множественным заблуждениям, из которых уже сформировался устойчивый набор мифов и легенд.
Как водится, происхождение всего этого мифотворчества уходит своими корнями в далекие времена Windows NT, т.е. до 2000 года. Фактически уже выросло второе поколение специалистов, которые эту самую NT в глаза не видели, но тем не менее подвержены распространенным заблуждениям.
Поэтому предлагаем вам немного окунуться в историю и понять, чем являлся домен NT и что изменилось с приходом Active Directory.
Домен NT (NTDS) являлся реализаций службы каталогов от Microsoft доступный в серверной операционной системе Windows NT Server. И состоял из одного первичного контроллера домена – PDC (Primary Domain Controller) и неограниченного количества резервных – BDC (Backup Domain Controllers).
Именно на первичном контроллере хранилась основная база домена и все изменения в нее могли вноситься только на нем. Затем эта база реплицировалась на остальные резервные контроллеры, после чего они тоже могли начать обрабатывать клиентские запросы.
Если первичный контроллер выходил из строя, то домен фактически переходил в режим «только чтение». При его окончательной утере первичным можно было сделать один из резервных контроллеров.
Но это была достаточно непростая задача, учитывая, что выбор роли определялся только на этапе установки и его нельзя было изменить без переустановки системы. Т.е. мы не могли добавить уже существующему серверу роль контроллера или понизить его до рядового. Также сделав резервный контроллер основным, нельзя было снова изменить его роль на резервный.
Чтобы понять все сложности, с которыми сталкивались администраторы тех лет следует вспомнить, что виртуализация в те времена была чем-то из области научной фантастики и сервера были железными. И было их обычно не очень много, поэтому кроме роли контроллера они совмещали в себе еще множество функций и переустановка такого сервера была крайне непростой задачей.
А при появлении нового сервера приходилось крепко думать, будет ли он контроллером домена или нет. Так как изменить его назначение без переустановки было невозможно.
Также схема один PDC – много BDC имела серьезные проблемы с репликацией, особенно для удаленных филиалов с учетом скоростей и качества каналов связи того времени. При том, что удаленный филиал сам не мог внести необходимые данные в домен, так как для этого требовался первичный контроллер.
Поэтому с приходом Windows 2000 и Active Directory от данной схемы отказались, с этого момента все контроллеры домена стали равнозначны и каждый из них мог вносить изменения в базу домена, потом обмениваясь измененными данными. А для контроля целостности и уникальности данных были созданы хозяева операций.
Также теперь любой сервер мог стать контроллером домена или перестать им быть без переустановки, что значительно облегчило администрирование и планирование инфраструктуры.
Но несмотря на то, что Active Directory скоро разменяет четверть века многие коллеги все еще продолжают оперировать устаревшими терминами и понятиями системы, которую никогда в глаза не видели.
👍42
Почему иногда лучше не выпендриваться
Третьего дня попросил меня заехать знакомый, сын которого забрал у меня старый процессор R7 2700X. Мол что-то греется сильно.
Ну хорошо, посмотрим. Симптомы классические: в простое температура 50-65 градусов, при любой, даже минимальной нагрузке сразу улетает за 70 С с выходом кулера на 100% оборотов.
Второй симптом – буст практически не работает, процессор пасет задних не переходя планку в 4 ГГц. Открываем, проверяем подошву кулера – теплая, хотя датчик показывает на процессоре 71 градус.
В общем – явно термопаста. Но процессор то поставлен недавно, может вообще пасту забыл? Или пленку с подошвы не снял?
Снимаем кулер, паста есть, полностью засохшая, консистенции жевательной резинки. Кое как стерли с крышки процессора и основания радиатора.
Спрашиваю, мол что за экскременты мамонта намазаны? В ответ сын знакомого обижается, мол никакие это не экскременты, а Arctic MX-5.
Да ну, не поверил я, покажи. Показывает. Похожа на оригинал, коробочку выкинул, но вроде тоже была как надо, со всеми наклейками и сертификатами.
Консистенция вроде нормальная, но какая-то не такая, неоднородная, вместе с пастой выходит маслянистая жидкость. В общем рисковать не стали, взяли в ближайшем DNS DEEPCOOL Z3, паста без особых претензий, крепкий середнячок.
Намазали, собрали. Итог – температура простоя вернулась на 40-45 градусов, появился буст до 4,3 ГГц, а за 70 температура стала выходить уже при работе с высокой нагрузкой.
Проблема решена, но вопрос с пастой все же не давал покоя, подделка? Брак? Стал читать отзывы и выяснил, что Arctic MX-5 снята с производства, так как подвел кто-то из поставщиков (или OEM-производитель) и качество пасты стало сильно неоднородным.
Симптомы точно такие же – расслоение, высыхание. Не у всех, а как повезет. Вполне возможно, что даже в пределах одной партии качество неоднородное, потому что даже за короткий промежуток времени можно найти полярные отзывы, у кого-то все хорошо, у кого-то паста быстро засохла.
Но сей прискорбный факт сильно не афишируется, а паста продолжает продаваться как продукт топового сегмента. Хотя, на самом деле, если вы не энтузиаст и не пытаетесь выжать из железа все что можно и нельзя, то проще не выпендриваться и взять пасту среднего ценового диапазона.
Результат будет плюс-минус тем же, пару градусов в обычных сценариях эксплуатации погоду не делают, а в случае чего и выбросить будет не так жалко.
Третьего дня попросил меня заехать знакомый, сын которого забрал у меня старый процессор R7 2700X. Мол что-то греется сильно.
Ну хорошо, посмотрим. Симптомы классические: в простое температура 50-65 градусов, при любой, даже минимальной нагрузке сразу улетает за 70 С с выходом кулера на 100% оборотов.
Второй симптом – буст практически не работает, процессор пасет задних не переходя планку в 4 ГГц. Открываем, проверяем подошву кулера – теплая, хотя датчик показывает на процессоре 71 градус.
В общем – явно термопаста. Но процессор то поставлен недавно, может вообще пасту забыл? Или пленку с подошвы не снял?
Снимаем кулер, паста есть, полностью засохшая, консистенции жевательной резинки. Кое как стерли с крышки процессора и основания радиатора.
Спрашиваю, мол что за экскременты мамонта намазаны? В ответ сын знакомого обижается, мол никакие это не экскременты, а Arctic MX-5.
Да ну, не поверил я, покажи. Показывает. Похожа на оригинал, коробочку выкинул, но вроде тоже была как надо, со всеми наклейками и сертификатами.
Консистенция вроде нормальная, но какая-то не такая, неоднородная, вместе с пастой выходит маслянистая жидкость. В общем рисковать не стали, взяли в ближайшем DNS DEEPCOOL Z3, паста без особых претензий, крепкий середнячок.
Намазали, собрали. Итог – температура простоя вернулась на 40-45 градусов, появился буст до 4,3 ГГц, а за 70 температура стала выходить уже при работе с высокой нагрузкой.
Проблема решена, но вопрос с пастой все же не давал покоя, подделка? Брак? Стал читать отзывы и выяснил, что Arctic MX-5 снята с производства, так как подвел кто-то из поставщиков (или OEM-производитель) и качество пасты стало сильно неоднородным.
Симптомы точно такие же – расслоение, высыхание. Не у всех, а как повезет. Вполне возможно, что даже в пределах одной партии качество неоднородное, потому что даже за короткий промежуток времени можно найти полярные отзывы, у кого-то все хорошо, у кого-то паста быстро засохла.
Но сей прискорбный факт сильно не афишируется, а паста продолжает продаваться как продукт топового сегмента. Хотя, на самом деле, если вы не энтузиаст и не пытаетесь выжать из железа все что можно и нельзя, то проще не выпендриваться и взять пасту среднего ценового диапазона.
Результат будет плюс-минус тем же, пару градусов в обычных сценариях эксплуатации погоду не делают, а в случае чего и выбросить будет не так жалко.
👍54👀13🤝4
AMD Ryzen Master – полный контроль над вашим процессором Ryzen
Решил я на прошлых выходных поиграться с искусственным интеллектом от компании MSI, а именно запустить MSI AI Engine которая пообещала мне тщательно проанализировать мою работу и согласно полученным результатам наилучшим образом настроить производительность системы.
Ну ОК, только кто же знал, что понимание лучшего у нас с искусственным интеллектом, мягко говоря, расходятся. Но пока ничего не предвещало беды, несколько дней сей интеллект усиленно что-то там анализировал и сказал, что мой профиль – Производительность.
Хорошо, применяем, перезагружаемся и найдите десять отличий, да и не найдете, потому что текущего Ryzen 9 5900X выше крыши для любых задач.
Первые звоночки, что что-то пошло не так прозвучали вечером. Именно прозвучали. Днем фоновый шум и множество запущенных приложений и виртуалок, которые что-то да делали не давали понять, что система охлаждения стала работать по-другому.
А вот вечером, когда я вместо основного компьютера решил поработать с бухгалтерией на ноутбуке сразу стало понятно, что компьютер живет своей жизнью.
У меня система охлаждения представлена достаточно производительной башней и в простое ее не слышно вообще, то, что ПК включен и работает можно обнаружить по миганию индикаторов. При средней нагрузке слышен легкий шелест и только при тяжелой ПК начинает быть отчетливо слышен.
Но чем он занят? А ничем. Короткое исследование показало, что процессор начал агрессивно бустить частоту даже при минимальной нагрузке. До этого 4,8 ГГц я видел только на тяжелых задачах, вроде сборки проекта, рендеринга и т.п.
Теперь подобная частота легко достигалась при запуске видео в браузере. Плюс в простое процессор перестал сбрасывать частоту ниже номинальной 3,7 ГГц. Оно вроде бы и ничего, температуры оставались в пределах нормы, не выбираясь за пределы 70-72 градусов, но постоянный шум вентилятора по малейшему чиху действовал на нервы.
В общем, дооптимизировался ты дядя, работало ведь все нормально, чего ты лез?
Отключении ИИ результата не дало, ну да он свое дело сделал, записал нужное в BIOS, а вы теперь тут живите.
Сбрасывать BIOS тоже не хотелось, так как там много ручных настроек под себя и было просто лень все их возвращать обратно.
Ну должен же быть какой-то иной выход? Должен, беглый поиск показал родную утилиту AMD Ryzen Master, которая способна помочь вам выполнить как максимальный разгон процессора, так и оптимизировать его энергопотребление.
Скачиваем, запускаем и не удивляемся, увидев установленный режим Precision Boost Overdrive, который снимает лимиты на тепловой пакет и процессор начинает буститься без ограничений с оглядкой только на температуру, при достаточно эффективной системе охлаждения буститься он будет сильно, а значит и шуметь, что и произошло.
Вернув данную настройку в Auto OC, удалось без лишнего шума и пыли полностью решить проблему и вернуть работу системы в комфортные для меня рамки.
Вторая интересная опция - Curve Optimizer, которая позволяет оптимизировать кривую, по которой процессор выполняет разгон с учетом особенностей именно вашей системы. Если Intel в подобных расчетах берет только мощность и частоту, то AMD учитывает еще и фактор температуры.
Данная настройка требует обязательной предварительной калибровки, которая длится более часа, включает несколько перезагрузок и представляет собой определенный стресс-тест, в ходе которого утилита будет повышать частоту до достижения лимита по температуре (для данного процессора это 90 градусов, которые были достигнуты при частоте 5 050 МГц).
Т.е. таким образом вы можете тонко настроить автоматический разгон именно с учетом вашей системы охлаждения. Я не стал его калибровать, текущий режим меня вполне устраивает.
В расширенном режиме доступно еще больше настроек, но тут уже надо вникать в тему, зато можно настроить все именно так, как того хочется.
В общем всем владельцам Ryzen есть смысл поработать с данной утилитой даже в базовом режиме.
✅ Официальная ссылка
Решил я на прошлых выходных поиграться с искусственным интеллектом от компании MSI, а именно запустить MSI AI Engine которая пообещала мне тщательно проанализировать мою работу и согласно полученным результатам наилучшим образом настроить производительность системы.
Ну ОК, только кто же знал, что понимание лучшего у нас с искусственным интеллектом, мягко говоря, расходятся. Но пока ничего не предвещало беды, несколько дней сей интеллект усиленно что-то там анализировал и сказал, что мой профиль – Производительность.
Хорошо, применяем, перезагружаемся и найдите десять отличий, да и не найдете, потому что текущего Ryzen 9 5900X выше крыши для любых задач.
Первые звоночки, что что-то пошло не так прозвучали вечером. Именно прозвучали. Днем фоновый шум и множество запущенных приложений и виртуалок, которые что-то да делали не давали понять, что система охлаждения стала работать по-другому.
А вот вечером, когда я вместо основного компьютера решил поработать с бухгалтерией на ноутбуке сразу стало понятно, что компьютер живет своей жизнью.
У меня система охлаждения представлена достаточно производительной башней и в простое ее не слышно вообще, то, что ПК включен и работает можно обнаружить по миганию индикаторов. При средней нагрузке слышен легкий шелест и только при тяжелой ПК начинает быть отчетливо слышен.
Но чем он занят? А ничем. Короткое исследование показало, что процессор начал агрессивно бустить частоту даже при минимальной нагрузке. До этого 4,8 ГГц я видел только на тяжелых задачах, вроде сборки проекта, рендеринга и т.п.
Теперь подобная частота легко достигалась при запуске видео в браузере. Плюс в простое процессор перестал сбрасывать частоту ниже номинальной 3,7 ГГц. Оно вроде бы и ничего, температуры оставались в пределах нормы, не выбираясь за пределы 70-72 градусов, но постоянный шум вентилятора по малейшему чиху действовал на нервы.
В общем, дооптимизировался ты дядя, работало ведь все нормально, чего ты лез?
Отключении ИИ результата не дало, ну да он свое дело сделал, записал нужное в BIOS, а вы теперь тут живите.
Сбрасывать BIOS тоже не хотелось, так как там много ручных настроек под себя и было просто лень все их возвращать обратно.
Ну должен же быть какой-то иной выход? Должен, беглый поиск показал родную утилиту AMD Ryzen Master, которая способна помочь вам выполнить как максимальный разгон процессора, так и оптимизировать его энергопотребление.
Скачиваем, запускаем и не удивляемся, увидев установленный режим Precision Boost Overdrive, который снимает лимиты на тепловой пакет и процессор начинает буститься без ограничений с оглядкой только на температуру, при достаточно эффективной системе охлаждения буститься он будет сильно, а значит и шуметь, что и произошло.
Вернув данную настройку в Auto OC, удалось без лишнего шума и пыли полностью решить проблему и вернуть работу системы в комфортные для меня рамки.
Вторая интересная опция - Curve Optimizer, которая позволяет оптимизировать кривую, по которой процессор выполняет разгон с учетом особенностей именно вашей системы. Если Intel в подобных расчетах берет только мощность и частоту, то AMD учитывает еще и фактор температуры.
Данная настройка требует обязательной предварительной калибровки, которая длится более часа, включает несколько перезагрузок и представляет собой определенный стресс-тест, в ходе которого утилита будет повышать частоту до достижения лимита по температуре (для данного процессора это 90 градусов, которые были достигнуты при частоте 5 050 МГц).
Т.е. таким образом вы можете тонко настроить автоматический разгон именно с учетом вашей системы охлаждения. Я не стал его калибровать, текущий режим меня вполне устраивает.
В расширенном режиме доступно еще больше настроек, но тут уже надо вникать в тему, зато можно настроить все именно так, как того хочется.
В общем всем владельцам Ryzen есть смысл поработать с данной утилитой даже в базовом режиме.
✅ Официальная ссылка
👍53
Service mesh: тренд, необходимость или хайп?
Приглашаем обсудить это на бесплатном вебинаре от учебного центра Слёрм.
Что будет на вебинаре:
➡️ посмотрим на service mesh с разных точек зрения: эксплуатации и разработки;
➡️ обсудим, какие преимущества дает service mesh и какие у него особенности;
➡️ определим основные понятия и посмотрим на примеры реализации service mesh.
И еще, кстати, разберём, бесплатен ли service mesh и какова его реальная цена.
Эксперты встречи — спикеры курсов Слёрма:
— Павел Лакосников, TeamLead SLA в Авито
— Георг Гаал, CTO, Aenix
Когда: 19 февраля в 19:00
👉 Занять место на вебинаре — через бота.
Реклама. ООО "СЛЁРМ". ИНН 3652901451.
Приглашаем обсудить это на бесплатном вебинаре от учебного центра Слёрм.
Что будет на вебинаре:
➡️ посмотрим на service mesh с разных точек зрения: эксплуатации и разработки;
➡️ обсудим, какие преимущества дает service mesh и какие у него особенности;
➡️ определим основные понятия и посмотрим на примеры реализации service mesh.
И еще, кстати, разберём, бесплатен ли service mesh и какова его реальная цена.
Эксперты встречи — спикеры курсов Слёрма:
— Павел Лакосников, TeamLead SLA в Авито
— Георг Гаал, CTO, Aenix
Когда: 19 февраля в 19:00
👉 Занять место на вебинаре — через бота.
Реклама. ООО "СЛЁРМ". ИНН 3652901451.
Прогнозирования выхода твердотельных накопителей из строя
Данный материал основан сугубо на собственных эмпирических наблюдениях и не является официальной информацией. Сугубо собственные наблюдения и логические выводы основанные на анализе статистики отказов.
Как известно любое оборудование имеет свойство отказывать, диски SSD не исключение и основная задача – вовремя понять, что устройство пора менять, не дожидаясь его отхода в страну вечной охоты.
Традиционные показатели, такие как SMART или счетчики износа здесь помогают мало, поэтому мы проанализировали наши случаи отказов и сделали некоторые выводы, которые не претендуют на истину, но могут оказаться полезны. Выводы применимы как к SSD, так и NVMe дискам.
Есть два параметра, сочетание которых указывает на то, что диск работает не нормально и может в ближайшее время выйти из строя.
1️⃣ Первый – это процент использования активного времени диска, в Zabbix это метрика Disk Utilization, в Windows – активное время. Если данная метрика на достаточное время залипает на уровне 100% без заметной дисковой активности или сопровождается активным чтением с небольшой скоростью – то это первый сигнал неблагополучия.
Да, мы можем нагрузить диск на 100%, но при этом будем видеть реальную адекватную нагрузку на чтение или на запись, либо и то и другое вместе.
Если же диск загружен на 100% в отсутствие видимой активности – то это сигнал о том, что он занят какими-то своими делами и на внешние раздражители не реагирует. В целом такого можно добиться на недорогих дисках удалив сразу большой объем данных и когда диск займется уборкой мусора эффект может быть схожим.
Но, повторимся, продолжительное нахождение диска в 100% нагрузке без видимых на то причин – первый и очень характерный симптом выхода из строя.
2️⃣ Второй симптом – это продолжительное интенсивное чтение, не несущее никакого логического смысла или вовсе противоречащее характеру производимой операции.
Скажем вы открываете закладку в браузере и процесс начинает что-то активно и продолжительно читать с диска, подвисая на некоторое время или полностью. Но объем и характер прочитанных данных никак не соответствует выполняемой задаче.
Либо мы пытаемся записать документ в 1С:Предприятие, но процесс вместо того, чтобы выполнить запись начинает интенсивно читать.
Попытка выяснить, что именно читает процесс успеха не приносит. Он может читать что угодно: свой бинарник, свою базу, своп, кеш.
А может и вообще ничего не читать. Т.е. у нас нет активно читающего процесса, а диск показывает, что его активно кто-то читает. Система или процесс, вызвавший такое поведение или подвисают, или существенно тормозят.
Попутно все это сопровождается 100% загрузкой диска. В Zabbix это можно отследить по увеличению метрике Disk read time (rate), в Windows мы просто видим продолжительное чтение.
👆 Еще раз повторим, что каждая из указанных метрик может вырастать по различным причинам, но их устойчивое сочетание в совокупности с «непонятным» чтением «непонятных» данных – это характерный признак скорого выхода из строя.
Данный материал основан сугубо на собственных эмпирических наблюдениях и не является официальной информацией. Сугубо собственные наблюдения и логические выводы основанные на анализе статистики отказов.
Как известно любое оборудование имеет свойство отказывать, диски SSD не исключение и основная задача – вовремя понять, что устройство пора менять, не дожидаясь его отхода в страну вечной охоты.
Традиционные показатели, такие как SMART или счетчики износа здесь помогают мало, поэтому мы проанализировали наши случаи отказов и сделали некоторые выводы, которые не претендуют на истину, но могут оказаться полезны. Выводы применимы как к SSD, так и NVMe дискам.
Есть два параметра, сочетание которых указывает на то, что диск работает не нормально и может в ближайшее время выйти из строя.
1️⃣ Первый – это процент использования активного времени диска, в Zabbix это метрика Disk Utilization, в Windows – активное время. Если данная метрика на достаточное время залипает на уровне 100% без заметной дисковой активности или сопровождается активным чтением с небольшой скоростью – то это первый сигнал неблагополучия.
Да, мы можем нагрузить диск на 100%, но при этом будем видеть реальную адекватную нагрузку на чтение или на запись, либо и то и другое вместе.
Если же диск загружен на 100% в отсутствие видимой активности – то это сигнал о том, что он занят какими-то своими делами и на внешние раздражители не реагирует. В целом такого можно добиться на недорогих дисках удалив сразу большой объем данных и когда диск займется уборкой мусора эффект может быть схожим.
Но, повторимся, продолжительное нахождение диска в 100% нагрузке без видимых на то причин – первый и очень характерный симптом выхода из строя.
2️⃣ Второй симптом – это продолжительное интенсивное чтение, не несущее никакого логического смысла или вовсе противоречащее характеру производимой операции.
Скажем вы открываете закладку в браузере и процесс начинает что-то активно и продолжительно читать с диска, подвисая на некоторое время или полностью. Но объем и характер прочитанных данных никак не соответствует выполняемой задаче.
Либо мы пытаемся записать документ в 1С:Предприятие, но процесс вместо того, чтобы выполнить запись начинает интенсивно читать.
Попытка выяснить, что именно читает процесс успеха не приносит. Он может читать что угодно: свой бинарник, свою базу, своп, кеш.
А может и вообще ничего не читать. Т.е. у нас нет активно читающего процесса, а диск показывает, что его активно кто-то читает. Система или процесс, вызвавший такое поведение или подвисают, или существенно тормозят.
Попутно все это сопровождается 100% загрузкой диска. В Zabbix это можно отследить по увеличению метрике Disk read time (rate), в Windows мы просто видим продолжительное чтение.
👆 Еще раз повторим, что каждая из указанных метрик может вырастать по различным причинам, но их устойчивое сочетание в совокупности с «непонятным» чтением «непонятных» данных – это характерный признак скорого выхода из строя.
👍53🤔7👀1
This media is not supported in your browser
VIEW IN TELEGRAM
Забавный видосик в Клубе ДНС на странице с ошибками 500. Еще более забавно присмотреться какую именно команду вводит гусь.
🔥42😁33👍9
Авгиевы конюшни
Случилась тут на днях беда – неожиданно и скоропостижно скончался, немного подергавшись твердотельный накопитель в рабочем ПК.
Вместе с накопителем в страну вечной охоты отправилось свыше 700 ГБ данных. Я специально не написал ценных – ничего ценного там не было.
Данный накопитель изначально использовался в целях разработки и тестирования. На нем находились дорабатываемые базы 1С, исходники проектов и скриптов, базы для тестирования и т.д. и т.п.
Конечный результат работ в виде бинарников и релизов хранился на другом диске с обязательной синхронизацией в облако, а вся разработка синхронизировалась с git и внешними репозиториями.
Т.е. ценного не пропало ничего, ну кроме тестовых баз. Но их наплодить не проблема, ну и актуальные проекты заново разместить надо было, что неспеша с перерывами на кофе было сделано за полдня.
Но заметка не о том, а о хранимом там объеме данных, свыше 700 ГБ чего? А непонятно чего. У меня давно чесались руки навести там порядок, но сделать это никогда не удавалось.
Почему? Потому что каждый раз возникали отговорки, мол может пригодится, мол сильно есть не просит. Мол не помню, что это, надо или не надо ( с учетом что последнее изменение было несколько лет назад – точно не надо). И т.д. и т.п.
Год от года все это росло и пухло, занимало все больше места, под это дело покупался более емкий диск и так бы оно и шло, но случай кардинально изменил ситуацию.
Восстановив все рабочие проекты, мы с удивлением обнаружили, что рабочий объем информации составляет всего 106 ГБ, ну со всякими промежуточными сборками, тестовыми релизами и т.п. раздуется до 200 ГБ, может быть.
Фактически ½ терабайта хлама заботливо хранилось годами. Не нужное, так как, напомню, и результаты работы и код хранятся в другом месте. И по-хорошему сделать это надо было давно, просто все грохнуть и заново создать рабочие проекты.
Но у кого же рука поднимется… Вот так и живем.
Случилась тут на днях беда – неожиданно и скоропостижно скончался, немного подергавшись твердотельный накопитель в рабочем ПК.
Вместе с накопителем в страну вечной охоты отправилось свыше 700 ГБ данных. Я специально не написал ценных – ничего ценного там не было.
Данный накопитель изначально использовался в целях разработки и тестирования. На нем находились дорабатываемые базы 1С, исходники проектов и скриптов, базы для тестирования и т.д. и т.п.
Конечный результат работ в виде бинарников и релизов хранился на другом диске с обязательной синхронизацией в облако, а вся разработка синхронизировалась с git и внешними репозиториями.
Т.е. ценного не пропало ничего, ну кроме тестовых баз. Но их наплодить не проблема, ну и актуальные проекты заново разместить надо было, что неспеша с перерывами на кофе было сделано за полдня.
Но заметка не о том, а о хранимом там объеме данных, свыше 700 ГБ чего? А непонятно чего. У меня давно чесались руки навести там порядок, но сделать это никогда не удавалось.
Почему? Потому что каждый раз возникали отговорки, мол может пригодится, мол сильно есть не просит. Мол не помню, что это, надо или не надо ( с учетом что последнее изменение было несколько лет назад – точно не надо). И т.д. и т.п.
Год от года все это росло и пухло, занимало все больше места, под это дело покупался более емкий диск и так бы оно и шло, но случай кардинально изменил ситуацию.
Восстановив все рабочие проекты, мы с удивлением обнаружили, что рабочий объем информации составляет всего 106 ГБ, ну со всякими промежуточными сборками, тестовыми релизами и т.п. раздуется до 200 ГБ, может быть.
Фактически ½ терабайта хлама заботливо хранилось годами. Не нужное, так как, напомню, и результаты работы и код хранятся в другом месте. И по-хорошему сделать это надо было давно, просто все грохнуть и заново создать рабочие проекты.
Но у кого же рука поднимется… Вот так и живем.
👍43💯15😁6
А есть ли у вас подобные "Авгиевы конюшни"
Anonymous Poll
55%
Есть, как не быть
15%
Иногда нахожу силы немного разгрести
16%
Время от времени разгребаю
4%
Постоянно поддерживаю порядок
4%
Забей, купи еще один диск
0%
Никогда такого не допускаю
6%
Я Авгий, мне результат посмотреть
👍2
❓ Хотите работать в VK, но не знаете, с чего начать?
Слёрм запускает крутой проект: серия онлайн-встреч с лидами из бигтеха!
Мы встречаемся с руководителями VK, чтобы выяснить, как проходят отборы на позицию DevOps Middle и помочь вам успешно пройти собеседование.
📅 Встречаемся с коллегами из VK Cloud – 17 февраля в 17:00!
На встрече разберём:
✔️ Какие задачи решает DevOps Middle в команде VK Cloud
✔️ Топ-3 ключевые компетенции DevOps-инженера
✔️ Разбор технических знаний: от critical до nice to have
✔️ Red flags при найме
✔️ Чему готовы обучать в процессе работы
Ведущий — Вячеслав Федосеев, TeamLead DevOps в «Честном знаке», автор канала «DevOps Bootcamp с Федосеевым»
В гостях:
Иван Дудко — руководитель команды автоматизации разработки VK Cloud, VK Tech
Мария Турунова — HR-бизнес-партнёр, VK Tech
Приходите 17 февраля в 17:00, чтобы понять, как попасть в VK и прокачать свои навыки!
📌 Ссылка на трансляцию – в боте!
#реклама
О рекламодателе
erid: 2W5zFG6WDma
Слёрм запускает крутой проект: серия онлайн-встреч с лидами из бигтеха!
Мы встречаемся с руководителями VK, чтобы выяснить, как проходят отборы на позицию DevOps Middle и помочь вам успешно пройти собеседование.
📅 Встречаемся с коллегами из VK Cloud – 17 февраля в 17:00!
На встрече разберём:
✔️ Какие задачи решает DevOps Middle в команде VK Cloud
✔️ Топ-3 ключевые компетенции DevOps-инженера
✔️ Разбор технических знаний: от critical до nice to have
✔️ Red flags при найме
✔️ Чему готовы обучать в процессе работы
Ведущий — Вячеслав Федосеев, TeamLead DevOps в «Честном знаке», автор канала «DevOps Bootcamp с Федосеевым»
В гостях:
Иван Дудко — руководитель команды автоматизации разработки VK Cloud, VK Tech
Мария Турунова — HR-бизнес-партнёр, VK Tech
Приходите 17 февраля в 17:00, чтобы понять, как попасть в VK и прокачать свои навыки!
📌 Ссылка на трансляцию – в боте!
#реклама
О рекламодателе
erid: 2W5zFG6WDma
🤡6👎1
Некоторые, неочевидные особенности связки DNS и DHCP в Active Directory
Вчера, в обсуждении возник вопрос, а зачем нужна связка из MS DNS и MS DHCP, ведь можно использовать любой другой DHCP сервер.
Вроде бы очевидный ответ: для того, чтобы DHCP мог динамически изменять DNS-записи в AD.
В ответ можно услышать, мол у меня DHCP на роутере и записи прекрасно добавляются. И на первый взгляд это действительно так.
Но, на самом деле, это называется «вроде бы работает», именно «вроде бы».
Почему? Правильная работа Active Directory серьезно завязана на правильную работу DNS. Поэтому важно, чтобы DHCP-сервер мог своевременно динамически менять записи, но это может делать не абы кто, а только авторизованный сервер.
При отсутствии авторизованного сервера Active Directory может сама внести нужную запись в момент входа в домен. Но только в прямую зону. В обратную зону никаких записей добавлено не будет.
Если устройство не входит в домен, то никаких записей о нем также добавлено не будет. А таких устройств может быть много: принтеры, гипервизоры, промышленные контроллеры и т.д. и т.п.
Первая проистекающая отсюда проблема – это сложности администрирования, так как вам, чтобы подключиться к принтеру в 216 кабинете вместо
Но все это ерунда, когда вопрос коснется обратной зоны. Обратная зона нужна для правильной работы очень многих интеграций сторонних приложений в AD и без нее ситуация превращается в «жизнь – боль» или «какая гадость эта ваша Active Directory».
Как живой пример подобной интеграции можно привести взаимодействие Squid и AD через Kerberos.
И заканчивается это все для администратора довольно плохо. К нам не раз приходили читатели, мол сделал все по статье, ничего не работает. И случайный кусок лога.
Хорошо, если кусок верный и ошибка в нем сразу видна.
В противном случае заниматься дебагом Kerberos по переписке у автора, как и других читателей нет никакого желания, а квалификации вопрошающего явно недостаточно для самостоятельного решения проблемы.
Хотя львиная их часть кроется как раз в неправильной работе DNS и обратная зона только частный случай.
Поэтому нужно сразу настраивать работу ключевых компонентов правильно, а не оставлять в состоянии «вроде работает».
Вчера, в обсуждении возник вопрос, а зачем нужна связка из MS DNS и MS DHCP, ведь можно использовать любой другой DHCP сервер.
Вроде бы очевидный ответ: для того, чтобы DHCP мог динамически изменять DNS-записи в AD.
В ответ можно услышать, мол у меня DHCP на роутере и записи прекрасно добавляются. И на первый взгляд это действительно так.
Но, на самом деле, это называется «вроде бы работает», именно «вроде бы».
Почему? Правильная работа Active Directory серьезно завязана на правильную работу DNS. Поэтому важно, чтобы DHCP-сервер мог своевременно динамически менять записи, но это может делать не абы кто, а только авторизованный сервер.
При отсутствии авторизованного сервера Active Directory может сама внести нужную запись в момент входа в домен. Но только в прямую зону. В обратную зону никаких записей добавлено не будет.
Если устройство не входит в домен, то никаких записей о нем также добавлено не будет. А таких устройств может быть много: принтеры, гипервизоры, промышленные контроллеры и т.д. и т.п.
Первая проистекающая отсюда проблема – это сложности администрирования, так как вам, чтобы подключиться к принтеру в 216 кабинете вместо
printer-216 надо сначала где-то найти его текущий IP-адрес. Но все это ерунда, когда вопрос коснется обратной зоны. Обратная зона нужна для правильной работы очень многих интеграций сторонних приложений в AD и без нее ситуация превращается в «жизнь – боль» или «какая гадость эта ваша Active Directory».
Как живой пример подобной интеграции можно привести взаимодействие Squid и AD через Kerberos.
И заканчивается это все для администратора довольно плохо. К нам не раз приходили читатели, мол сделал все по статье, ничего не работает. И случайный кусок лога.
Хорошо, если кусок верный и ошибка в нем сразу видна.
В противном случае заниматься дебагом Kerberos по переписке у автора, как и других читателей нет никакого желания, а квалификации вопрошающего явно недостаточно для самостоятельного решения проблемы.
Хотя львиная их часть кроется как раз в неправильной работе DNS и обратная зона только частный случай.
Поэтому нужно сразу настраивать работу ключевых компонентов правильно, а не оставлять в состоянии «вроде работает».
👍38💯2
PassFiltEx by Joseph Ryan Ries
Несколько дней назад мы рассказывали о Lithnet Password Protection for Active Directory (LPP), мощном открытом инструменте, который позволяет гибко управлять политикой паролей в Active Directory.
Сегодня мы расскажем о проекте попроще, но тем не менее достаточно мощном и если вам не нужны интеграции с внешними сервисами и нужно просто управлять политиками паролей не делая упор именно на черные списки, то PassFiltEx вполне подойдет ко двору.
Весь продукт состоит из библиотеки DLL и файла черного списка паролей. Подключение и управление производится путем изменения реестра.
По умолчанию утилита не налагает дополнительных требований к стандартной политике паролей и позволяет только блокировать указанные вами комбинации по списку. Но делает это не в лоб, а с учетом вхождения указанной фразы в пароль, по умолчанию блокировка происходит, если указанная фраза занимает более чем 60% общей длины пароля.
Например, если мы указали фразу password, то пароль MyPassworD будет отвергнут, а пароль MyMostSecretPasswordAndLong будет принят, потому что вхождение указанной фразы в него составляет менее 60%.
Но в отличие от более продвинутого аналога PassFiltEx не умеет различать типовые замены и простые обсфукации. Поэтому если мы вместо MyPassworD напишем MyPa$$worD, то такой пароль пройдет.
Если вначале строки в файле поставить !, то процент вхождения учитываться не будет и будут заблокированы все пароли с таким вхождением. Например !word – заблокирует и MyPassworD, и MyPa$$worD, и даже MyMostSecretPasswordAndLong.
Также мы можем гибко регулировать количество цифр и символов в пароле, отдельно, через реестр, задавая количество требуемых прописных и строчных букв, цифр и спецсимволов.
Отдельно можно заблокировать последовательности символов более определенной длины, скажем ABC или 123, либо повторения одного и тоже символа: 111 или AAA.
Несмотря на свою простоту основные вопросы защиты паролей во внутреннем контуре с минимальным доступом извне она закрывает и позволяет как гибко настроить политику паролей, так и закрыть основные типовые слабые комбинации.
✅ Страница проекта: https://github.com/ryanries/PassFiltEx
Несколько дней назад мы рассказывали о Lithnet Password Protection for Active Directory (LPP), мощном открытом инструменте, который позволяет гибко управлять политикой паролей в Active Directory.
Сегодня мы расскажем о проекте попроще, но тем не менее достаточно мощном и если вам не нужны интеграции с внешними сервисами и нужно просто управлять политиками паролей не делая упор именно на черные списки, то PassFiltEx вполне подойдет ко двору.
Весь продукт состоит из библиотеки DLL и файла черного списка паролей. Подключение и управление производится путем изменения реестра.
По умолчанию утилита не налагает дополнительных требований к стандартной политике паролей и позволяет только блокировать указанные вами комбинации по списку. Но делает это не в лоб, а с учетом вхождения указанной фразы в пароль, по умолчанию блокировка происходит, если указанная фраза занимает более чем 60% общей длины пароля.
Например, если мы указали фразу password, то пароль MyPassworD будет отвергнут, а пароль MyMostSecretPasswordAndLong будет принят, потому что вхождение указанной фразы в него составляет менее 60%.
Но в отличие от более продвинутого аналога PassFiltEx не умеет различать типовые замены и простые обсфукации. Поэтому если мы вместо MyPassworD напишем MyPa$$worD, то такой пароль пройдет.
Если вначале строки в файле поставить !, то процент вхождения учитываться не будет и будут заблокированы все пароли с таким вхождением. Например !word – заблокирует и MyPassworD, и MyPa$$worD, и даже MyMostSecretPasswordAndLong.
Также мы можем гибко регулировать количество цифр и символов в пароле, отдельно, через реестр, задавая количество требуемых прописных и строчных букв, цифр и спецсимволов.
Отдельно можно заблокировать последовательности символов более определенной длины, скажем ABC или 123, либо повторения одного и тоже символа: 111 или AAA.
Несмотря на свою простоту основные вопросы защиты паролей во внутреннем контуре с минимальным доступом извне она закрывает и позволяет как гибко настроить политику паролей, так и закрыть основные типовые слабые комбинации.
✅ Страница проекта: https://github.com/ryanries/PassFiltEx
👍27❤1
В заключение темы про Active Directory две инструкции как поднять домен под ключ со всеми современными плюшками, включая отказоустойчивый DHCP как на системе с графикой, так и на Core версиях.
🔹 Быстрое развертывание Active Directory с отказоустойчивой конфигурацией DHCP
🔹 Быстрое развертывание Active Directory с отказоустойчивой конфигурацией DHCP на базе Windows Server Core
🔹 Быстрое развертывание Active Directory с отказоустойчивой конфигурацией DHCP
🔹 Быстрое развертывание Active Directory с отказоустойчивой конфигурацией DHCP на базе Windows Server Core
👍58🤝4🔥1👨💻1
❓ Хотите приручить SSH и стать экспертом удаленного администрирования?
На открытом уроке «Работа с SSH в Linux» вы освоите все ключевые техники, необходимые для работы с протоколом SSH.
Что вы узнаете:
— Как настроить SSH-сервер и клиент.
— Как использовать аутентификацию по ключам для максимальной безопасности.
— Как синхронизировать файлы с помощью rsync и повысить эффективность администрирования.
⭐ Спикер Николай Лавлинский — технический директор в Метод Лаб, PhD Economic Science, опытный руководитель разработки и преподаватель.
⏰ Встречаемся 20 февраля в 19:00 мск. Урок проводится в преддверии старта курса «Administrator Linux. Basic», а участники получат скидку на обучение.
👉 Настройте свои навыки на новый уровень — регистрируйтесь прямо сейчас: https://otus.pw/1AZB/?erid=2W5zFGj3Lqe
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
На открытом уроке «Работа с SSH в Linux» вы освоите все ключевые техники, необходимые для работы с протоколом SSH.
Что вы узнаете:
— Как настроить SSH-сервер и клиент.
— Как использовать аутентификацию по ключам для максимальной безопасности.
— Как синхронизировать файлы с помощью rsync и повысить эффективность администрирования.
⭐ Спикер Николай Лавлинский — технический директор в Метод Лаб, PhD Economic Science, опытный руководитель разработки и преподаватель.
⏰ Встречаемся 20 февраля в 19:00 мск. Урок проводится в преддверии старта курса «Administrator Linux. Basic», а участники получат скидку на обучение.
👉 Настройте свои навыки на новый уровень — регистрируйтесь прямо сейчас: https://otus.pw/1AZB/?erid=2W5zFGj3Lqe
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
🥱5👀2
Леса, домены и их хозяева
В обсуждении отдельные участники стали высказывать мнение, что утверждение о том, что все доменные контроллеры равнозначны неверно и есть мол самые-самые главные. В подтверждение приводя одну частную, можно даже сказать вырожденную ситуацию.
Но о ней позже. А пока что вспомним структуру AD, многие сразу ассоциируют ее со словом домен, однако это неверно. Верхним уровнем иерархии AD является лес, в котором уже располагаются домены. Первый созданный в лесу домен является корневым.
Что это значит? Что именно он содержит двух хозяев уровня леса: хозяина схемы и хозяина именования доменов. И если потеря всех контроллеров домена ведет к утере домена, то потеря всех контроллеров корневого домена ведет к утере леса.
В тоже время не один из хозяев не хранит уникальные данные и хозяин схемы не исключение, копия схемы присутствует на любом контроллере домена, в т.ч. и в доменах не являющихся корневыми, но вносить в нее изменения может лишь хозяин.
Почему мы не можем захватить роль хозяина схемы произвольным контроллером? А потому что в лесу может быть только один хозяин и иерархию леса обслуживает корневой домен. Поэтому «лесные» хозяева ограничены пропиской только в пределах корневого домена.
Что касается остальных хозяев, то они в каждом домене свои, в лице целых трех штук, правда один из них фактически бесполезен, если мы в соответствии с фактическими рекомендациями делаем каждый контроллер глобальным каталогом.
Глобальный каталог, напоминаем, хранит все объекты леса и реплицирует их с другими глобальными каталогами. Контроллер, не являющийся глобальным каталогом, хранит и реплицирует объекты только своего домена.
А теперь про «вывод» отдельного домена, не являющегося корневым, из леса. Сразу говорим, что так делать нельзя. Архитектура Active Directory этого не позволяет. Именно архитектура, а не отсутствие пресловутого хозяина схемы.
Потому что если мы технически отключим от общей инфраструктуры такой домен, то копия схемы у нас все равно будет, она есть на любом контроллере. И технически мы можем назначить нового хозяина.
Но хозяин схемы – уровень леса, а домен не является корневым. Т.е. уже на этом этапе возникает понимание, что мы в лесу не самые главные и сделать такого не можем. Но не потому, что контроллерам не хватает каких-то данных, а потому что нельзя. Нет таких полномочий.
Но допустим, мы это ограничение как-то обойдем и при наличии хоть одного глобального каталога мы можем вообще поднять копию леса и назначить себя в нем самыми главными.
Чем это чревато – объяснять не нужно. Потому что будь такое возможно, то каждый поверивший в себя суслик в самом задрипанном филиале мог бы натворить таких дел, что мама не горюй.
Поэтому заведовать операциями уровня леса – привилегия корневого домена и его утрата приводит к утрате леса, хотя другие глобальные каталоги будут содержать всю полноту информации. Но в данном случае речь идет не о наличии информации, а о сохранении целостности и области доверия уровня леса, что при отсутствии корневого домена не может быть реализовано.
Проще говоря, если отойти от этого подхода, то, как мы показали выше, никто не мешает бесконтрольно наплодить клоны лесов со всеми вытекающими. Ровно по той же причине мы теряем домен при утрате всех его контроллеров, хотя все данные этого домена есть на любом глобальном каталоге в лесу.
В обсуждении отдельные участники стали высказывать мнение, что утверждение о том, что все доменные контроллеры равнозначны неверно и есть мол самые-самые главные. В подтверждение приводя одну частную, можно даже сказать вырожденную ситуацию.
Но о ней позже. А пока что вспомним структуру AD, многие сразу ассоциируют ее со словом домен, однако это неверно. Верхним уровнем иерархии AD является лес, в котором уже располагаются домены. Первый созданный в лесу домен является корневым.
Что это значит? Что именно он содержит двух хозяев уровня леса: хозяина схемы и хозяина именования доменов. И если потеря всех контроллеров домена ведет к утере домена, то потеря всех контроллеров корневого домена ведет к утере леса.
В тоже время не один из хозяев не хранит уникальные данные и хозяин схемы не исключение, копия схемы присутствует на любом контроллере домена, в т.ч. и в доменах не являющихся корневыми, но вносить в нее изменения может лишь хозяин.
Почему мы не можем захватить роль хозяина схемы произвольным контроллером? А потому что в лесу может быть только один хозяин и иерархию леса обслуживает корневой домен. Поэтому «лесные» хозяева ограничены пропиской только в пределах корневого домена.
Что касается остальных хозяев, то они в каждом домене свои, в лице целых трех штук, правда один из них фактически бесполезен, если мы в соответствии с фактическими рекомендациями делаем каждый контроллер глобальным каталогом.
Глобальный каталог, напоминаем, хранит все объекты леса и реплицирует их с другими глобальными каталогами. Контроллер, не являющийся глобальным каталогом, хранит и реплицирует объекты только своего домена.
А теперь про «вывод» отдельного домена, не являющегося корневым, из леса. Сразу говорим, что так делать нельзя. Архитектура Active Directory этого не позволяет. Именно архитектура, а не отсутствие пресловутого хозяина схемы.
Потому что если мы технически отключим от общей инфраструктуры такой домен, то копия схемы у нас все равно будет, она есть на любом контроллере. И технически мы можем назначить нового хозяина.
Но хозяин схемы – уровень леса, а домен не является корневым. Т.е. уже на этом этапе возникает понимание, что мы в лесу не самые главные и сделать такого не можем. Но не потому, что контроллерам не хватает каких-то данных, а потому что нельзя. Нет таких полномочий.
Но допустим, мы это ограничение как-то обойдем и при наличии хоть одного глобального каталога мы можем вообще поднять копию леса и назначить себя в нем самыми главными.
Чем это чревато – объяснять не нужно. Потому что будь такое возможно, то каждый поверивший в себя суслик в самом задрипанном филиале мог бы натворить таких дел, что мама не горюй.
Поэтому заведовать операциями уровня леса – привилегия корневого домена и его утрата приводит к утрате леса, хотя другие глобальные каталоги будут содержать всю полноту информации. Но в данном случае речь идет не о наличии информации, а о сохранении целостности и области доверия уровня леса, что при отсутствии корневого домена не может быть реализовано.
Проще говоря, если отойти от этого подхода, то, как мы показали выше, никто не мешает бесконтрольно наплодить клоны лесов со всеми вытекающими. Ровно по той же причине мы теряем домен при утрате всех его контроллеров, хотя все данные этого домена есть на любом глобальном каталоге в лесу.
👍33