Тонкая настройка systemd-journald
Классическая ситуация – все место на диске занято логами, либо логи создают излишнюю нагрузку на систему ввода вывода.
Чтобы этого не случилось – логирование нужно настроить в соответствии с реальными потребностями и сегодня мы посмотрим, как это сделать для systemd-journald.
Прежде всего посмотрим текущие настройки, это можно сделать командой:
По умолчанию все значение в нем закомментированы и представляют настройки службы по умолчанию. Для изменения вы можете использовать данный файл, но официально рекомендуется использовать технологию "drop-ins" и хранить настройки в отдельных файлах.
Создадим для этого директорию:
А в нем один или несколько файлов с изменениями конфигурации, в нашем случае это будет
Начнем с места хранения логов. Для сохранения на диск используйте:
Это более надежно, чем auto, которое может иногда приводить к сюрпризам. Если же вам не нужна запись логов на диск, но вы хотите иметь их для диагностики и отладки используйте хранение в оперативной памяти. Такой метод рекомендуется для виртуальных машин и контейнеров, а также встраиваемых устройств и мини-ПК.
Затем проверьте опции:
Первая из них включает сжатие логов, вторая – криптографическую защиту, обычно обе включены по умолчанию.
Хранить логи – это хорошо, но не ограничивать размер – очень плохо, поэтому сразу озаботимся этим:
Первая опция задает максимальный размер хранилища логов, а второй нижний предел свободного места. Таким образом мы будем хранить не более одного гигабайта логов, но при условии, что в системе остается не менее 2 ГБ свободного места.
Если вы храните данные в ОЗУ, то используйте следующие опции аналогичного назначения:
Опции
Задают максимальный размер одного файла журнала и их общее количество, по умолчанию systemd-journald создает файлы размером 8 МБ.
Для хранения в оперативной памяти аналогичные опции:
Следующие важные настройки – это уровни логирования, в продуктивных средах нет необходимости хранить логи уровня debug, будет вполне достаточно info или notice. Поэтому замените debug на более низкий уровень логирования в этих трех опциях:
Данный набор опций отвечает за пересылку логов в syslog, kernel buffer, консоль и отправку сообщения пользователям.
Настройки по умолчанию (указаны выше) оптимальны и без необходимости пересылку включать не следует. Единственная включенная пересылка – это отправка пользователям сообщений уровня emerg (катастрофический сбой).
Еще одна важная опция – это лимиты, позволяющие избегать засорения логов однотипными сообщениями. По умолчанию имеет следующие значения:
Это означает, что в течении 30 секунд можно отправить в лог не более 10 000 сообщений. Обратите внимание, что данный лимит действует для каждого источника событий, а не для всей системы.
В высоконагруженных системах лимит можно повысить, например, для гипервизоров, где виртуалки при старте могут быть достаточно «разговорчивы». В виртуальных средах, наоборот, имеет смысл понизить этот лимит, чтобы избежать массового спама логов сбойным сервисом.
Классическая ситуация – все место на диске занято логами, либо логи создают излишнюю нагрузку на систему ввода вывода.
Чтобы этого не случилось – логирование нужно настроить в соответствии с реальными потребностями и сегодня мы посмотрим, как это сделать для systemd-journald.
Прежде всего посмотрим текущие настройки, это можно сделать командой:
cat /etc/systemd/journald.conf
По умолчанию все значение в нем закомментированы и представляют настройки службы по умолчанию. Для изменения вы можете использовать данный файл, но официально рекомендуется использовать технологию "drop-ins" и хранить настройки в отдельных файлах.
Создадим для этого директорию:
mkdir -p /etc/systemd/journald.conf.d
А в нем один или несколько файлов с изменениями конфигурации, в нашем случае это будет
00-journal.conf куда мы будем вносить изменившиеся опции.Начнем с места хранения логов. Для сохранения на диск используйте:
Storage=persistent
Это более надежно, чем auto, которое может иногда приводить к сюрпризам. Если же вам не нужна запись логов на диск, но вы хотите иметь их для диагностики и отладки используйте хранение в оперативной памяти. Такой метод рекомендуется для виртуальных машин и контейнеров, а также встраиваемых устройств и мини-ПК.
Storage=volatile
Затем проверьте опции:
Compress=yes
Seal=yes
Первая из них включает сжатие логов, вторая – криптографическую защиту, обычно обе включены по умолчанию.
Хранить логи – это хорошо, но не ограничивать размер – очень плохо, поэтому сразу озаботимся этим:
SystemMaxUse=1G
SystemKeepFree=2G
Первая опция задает максимальный размер хранилища логов, а второй нижний предел свободного места. Таким образом мы будем хранить не более одного гигабайта логов, но при условии, что в системе остается не менее 2 ГБ свободного места.
Если вы храните данные в ОЗУ, то используйте следующие опции аналогичного назначения:
RuntimeMaxUse=64M
RuntimeKeepFree=256M
Опции
SystemMaxFileSize=
SystemMaxFiles=100
Задают максимальный размер одного файла журнала и их общее количество, по умолчанию systemd-journald создает файлы размером 8 МБ.
Для хранения в оперативной памяти аналогичные опции:
RuntimeMaxFileSize=
RuntimeMaxFiles=100
Следующие важные настройки – это уровни логирования, в продуктивных средах нет необходимости хранить логи уровня debug, будет вполне достаточно info или notice. Поэтому замените debug на более низкий уровень логирования в этих трех опциях:
MaxLevelStore=debug
MaxLevelSyslog=debug
MaxLevelSocket=debug
Данный набор опций отвечает за пересылку логов в syslog, kernel buffer, консоль и отправку сообщения пользователям.
ForwardToSyslog=no
ForwardToKMsg=no
ForwardToConsole=no
ForwardToWall=yes
Настройки по умолчанию (указаны выше) оптимальны и без необходимости пересылку включать не следует. Единственная включенная пересылка – это отправка пользователям сообщений уровня emerg (катастрофический сбой).
Еще одна важная опция – это лимиты, позволяющие избегать засорения логов однотипными сообщениями. По умолчанию имеет следующие значения:
RateLimitIntervalSec=30s
RateLimitBurst=10000
Это означает, что в течении 30 секунд можно отправить в лог не более 10 000 сообщений. Обратите внимание, что данный лимит действует для каждого источника событий, а не для всей системы.
В высоконагруженных системах лимит можно повысить, например, для гипервизоров, где виртуалки при старте могут быть достаточно «разговорчивы». В виртуальных средах, наоборот, имеет смысл понизить этот лимит, чтобы избежать массового спама логов сбойным сервисом.
👍12🔥5❤1
AppArmor-шум или тонкие настройки логов в LXC-контейнерах Proxmox
Изучая системный журнал Proxmox, вы можете обнаружить целые блоки записей вида:
Они не свидетельствуют о каких-либо проблемах и могут быть проигнорированы, однако таких записей может быть много, что серьезно засоряет лог и затрудняет его чтение.
Но что это вообще за записи? Давайте разберемся. Как мы можем видеть источником записи является служба rsyslogd контейнера, которая хочет получить доступ к dev-log хоста, чтобы что-то записать в системный лог, но AppArmor ей в этом препятствует.
В общем и целом, в rsyslogd для контейнеров нет особой нужны, она только дублирует работу systemd-journald, поэтому его можно отключить, это полностью решит проблему AppArmor-шума.
Но мы пойдем немного дальше и подумаем, а нужны ли нам вообще системные логи в контейнерах? Чтобы посмотреть, что systemd-journald туда пишет запустите:
Ситуация дополнительно усугубляется тем, что такие логи пишет каждый контейнер, создавая дополнительную нагрузку на диск, хотя данные логи фактически бесполезны.
Радикальное решение – отключить логирование вообще, но это может затруднить отладку и диагностику в контейнере. Поэтому мы пойдем другим путем и настроим логирование.
Так как нам нет необходимости хранить системные логи, то мы разместим их в оперативной памяти, тем самым снизив нагрузку на дисковую подсистему хоста.
Такое решение позволит нам иметь логи для диагностики и отладки, но не засорять ими память и не создавать лишнюю нагрузку. Также отключим службу rsyslogd за ненадобностью.
Начнем:
Затем создадим директорию
А в ней создадим и откроем на редактирование файл:
В который внесем следующее содержимое:
Первые две строки предписывают использовать для логов оперативную память и задают доступный размер (в нашем случае 64 МБ).
Последняя строка запрещает перенаправлять события в syslog, несмотря на то что мы отключили rsyslog данная опция не будет лишней, потому что по умолчанию systemd-journald перенаправляет туда каждое событие.
Да, они будут перенаправляться в никуда, но зачем вообще тратить на это ресурсы? А в некоторых конфигурациях это может стать дополнительным источником сообщений в логах.
Сохраняем содержимое файла и перезапускаем службу:
Проверяем, AppArmor-шум должен полностью прекратиться, а логи теперь собираются в оперативную память и не расходуют ресурсы хоста.
Изучая системный журнал Proxmox, вы можете обнаружить целые блоки записей вида:
apparmor="DENIED" operation="sendmsg" class="file" namespace="root//lxc-803_<-var-lib-lxc>" profile="rsyslogd" name="/run/systemd/journal/dev-log"
Они не свидетельствуют о каких-либо проблемах и могут быть проигнорированы, однако таких записей может быть много, что серьезно засоряет лог и затрудняет его чтение.
Но что это вообще за записи? Давайте разберемся. Как мы можем видеть источником записи является служба rsyslogd контейнера, которая хочет получить доступ к dev-log хоста, чтобы что-то записать в системный лог, но AppArmor ей в этом препятствует.
В общем и целом, в rsyslogd для контейнеров нет особой нужны, она только дублирует работу systemd-journald, поэтому его можно отключить, это полностью решит проблему AppArmor-шума.
Но мы пойдем немного дальше и подумаем, а нужны ли нам вообще системные логи в контейнерах? Чтобы посмотреть, что systemd-journald туда пишет запустите:
journalctl -f
Ситуация дополнительно усугубляется тем, что такие логи пишет каждый контейнер, создавая дополнительную нагрузку на диск, хотя данные логи фактически бесполезны.
Радикальное решение – отключить логирование вообще, но это может затруднить отладку и диагностику в контейнере. Поэтому мы пойдем другим путем и настроим логирование.
Так как нам нет необходимости хранить системные логи, то мы разместим их в оперативной памяти, тем самым снизив нагрузку на дисковую подсистему хоста.
Такое решение позволит нам иметь логи для диагностики и отладки, но не засорять ими память и не создавать лишнюю нагрузку. Также отключим службу rsyslogd за ненадобностью.
Начнем:
systemctl stop rsyslog
systemctl mask rsyslog
Затем создадим директорию
mkdir -p /etc/systemd/journald.conf.d
А в ней создадим и откроем на редактирование файл:
nano /etc/systemd/journald.conf.d/00-journal.conf
В который внесем следующее содержимое:
[Journal]
Storage=volatile
RuntimeMaxUse=64M
ForwardToSyslog=no
Первые две строки предписывают использовать для логов оперативную память и задают доступный размер (в нашем случае 64 МБ).
Последняя строка запрещает перенаправлять события в syslog, несмотря на то что мы отключили rsyslog данная опция не будет лишней, потому что по умолчанию systemd-journald перенаправляет туда каждое событие.
Да, они будут перенаправляться в никуда, но зачем вообще тратить на это ресурсы? А в некоторых конфигурациях это может стать дополнительным источником сообщений в логах.
Сохраняем содержимое файла и перезапускаем службу:
systemctl restart systemd-journald
Проверяем, AppArmor-шум должен полностью прекратиться, а логи теперь собираются в оперативную память и не расходуют ресурсы хоста.
👍10❤1🔥1🤮1
Принцип Питера
Принцип Питера сформулирован в 1969 году канадским педагогом и психологом Лоуренсом Дж. Питером, у нас он известен как часть Законов Мерфи.
Принцип Питера гласит:
Следствия принципа Питера:
Многие считают это всего лишь шуткой, но на самом деле подобные тенденции имеют место быть и гораздо шире, нежели этого бы хотелось.
Причина в современной корпоративной культуре, не важно – нашей или западной – вся она завязана на некоторую «эффективность» сотрудника, которая является одним из проявлений «успешного успеха».
«Эффективный» сотрудник просто не может сказать – я не готов к повышению, я что-то не знаю и не умею, мне нужно подучиться. Потому что в этом случае он остановился, когда другие продолжают бежать вперед, он теперь просто неудачник.
При этом реальной компетентности на новой должности уже не хватает. Но если можно заменить работу красивыми отчетами и плавно делегировать ее вниз – то проблемы нет.
А показав «успехи» и на этой должности можно и дальше пробиваться вверх по карьерной лестнице, до тех пор, пока выше вы не сможете вообще ничего, даже писать красивые отчеты.
В этой точке сотрудник поднялся до своего уровня некомпетентности и занял соответствующую ей должность.
Тут может быть смешно, но часто именно так оно и происходит. Потому что руководителю не обязательно знать современные технологии, языки программирования и вообще разбираться в предмете. Ведь у него есть опыт, он лоялен фирме и т.д. и т.п.
В результате должность занимает абсолютно некомпетентный человек, который хорошо, если просто не мешает остальным работать, а не тормозит развитие на своем уровне представления о прекрасном.
И хорошо, если на этом все заканчивается, практика показывает, что нет, особенно явно это проявляется в госах. Осознавая собственный уровень некомпетентности, такой руководитель никогда не будет повышать компетентных сотрудников.
Почему? Потому что они будут представлять непосредственную угрозу его должности, потому что их потолок некомпетентности выше и могут еще расти, а он уже нет. А место теплое и хлебное, рынок труда для него – это какой-то восточный базар в арабской стране: прикольно, интересно, но абсолютно ничего не понятно, что они там лопочут.
И на нижестоящие должности также ставятся некомпетентные сотрудники, зато лояльные и безопасные, обладающие ценными навыками рисовать красивые отчеты и не менее красиво наводить тень на плетень.
Вы думаете им нужны толковые заместители? Вовсе нет. Ну вы поняли. Система самоцементируется сверху вниз, заполняя все уровни некомпетентными сотрудниками.
Погодите, а кто же будет работать? Если это гос, то возможно даже никто, гос не обанкротится, его финансирует бюджет, а все остальное они нарисуют. И такое, к сожалению, имеет место быть, когда элементарные вопросы решаются с огромным скрипом и очень долго.
Если же работать все-таки надо, то работают линейные сотрудники, тоже невысокой компетенции, чтобы даже не думали прыгать выше головы, потому что прыгать в такой системе некуда.
Получаем типичную «потогонку» или «галеру» и пока такой бизнес приносит средства для кормления всей этой руководящей пирамиды – никто ничего менять не будет.
А сегодня для принципа Питера открылось второе дыхание – нейросети, которые помогают поддерживать и даже повышать свой уровень некомпетентности, причем на всех уровнях.
Что с этим делать? Ничего, принимать как данное, ибо нейросеть просто инструмент, а поведение человека складывалось веками. Но умение распознавать подобные организации и стараться обходить их стороной – навык полезный.
Принцип Питера сформулирован в 1969 году канадским педагогом и психологом Лоуренсом Дж. Питером, у нас он известен как часть Законов Мерфи.
Принцип Питера гласит:
В иерархии каждый сотрудник имеет тенденцию подниматься до своего уровня некомпетентности.
Следствия принципа Питера:
🔸С течением времени каждая должность будет занята сотрудником, который некомпетентен в выполнении своих обязанностей.
🔸Работа выполняется теми работниками, которые ещё не достигли своего уровня некомпетентности.
Многие считают это всего лишь шуткой, но на самом деле подобные тенденции имеют место быть и гораздо шире, нежели этого бы хотелось.
Причина в современной корпоративной культуре, не важно – нашей или западной – вся она завязана на некоторую «эффективность» сотрудника, которая является одним из проявлений «успешного успеха».
«Эффективный» сотрудник просто не может сказать – я не готов к повышению, я что-то не знаю и не умею, мне нужно подучиться. Потому что в этом случае он остановился, когда другие продолжают бежать вперед, он теперь просто неудачник.
При этом реальной компетентности на новой должности уже не хватает. Но если можно заменить работу красивыми отчетами и плавно делегировать ее вниз – то проблемы нет.
А показав «успехи» и на этой должности можно и дальше пробиваться вверх по карьерной лестнице, до тех пор, пока выше вы не сможете вообще ничего, даже писать красивые отчеты.
В этой точке сотрудник поднялся до своего уровня некомпетентности и занял соответствующую ей должность.
Тут может быть смешно, но часто именно так оно и происходит. Потому что руководителю не обязательно знать современные технологии, языки программирования и вообще разбираться в предмете. Ведь у него есть опыт, он лоялен фирме и т.д. и т.п.
В результате должность занимает абсолютно некомпетентный человек, который хорошо, если просто не мешает остальным работать, а не тормозит развитие на своем уровне представления о прекрасном.
И хорошо, если на этом все заканчивается, практика показывает, что нет, особенно явно это проявляется в госах. Осознавая собственный уровень некомпетентности, такой руководитель никогда не будет повышать компетентных сотрудников.
Почему? Потому что они будут представлять непосредственную угрозу его должности, потому что их потолок некомпетентности выше и могут еще расти, а он уже нет. А место теплое и хлебное, рынок труда для него – это какой-то восточный базар в арабской стране: прикольно, интересно, но абсолютно ничего не понятно, что они там лопочут.
И на нижестоящие должности также ставятся некомпетентные сотрудники, зато лояльные и безопасные, обладающие ценными навыками рисовать красивые отчеты и не менее красиво наводить тень на плетень.
Вы думаете им нужны толковые заместители? Вовсе нет. Ну вы поняли. Система самоцементируется сверху вниз, заполняя все уровни некомпетентными сотрудниками.
Погодите, а кто же будет работать? Если это гос, то возможно даже никто, гос не обанкротится, его финансирует бюджет, а все остальное они нарисуют. И такое, к сожалению, имеет место быть, когда элементарные вопросы решаются с огромным скрипом и очень долго.
Если же работать все-таки надо, то работают линейные сотрудники, тоже невысокой компетенции, чтобы даже не думали прыгать выше головы, потому что прыгать в такой системе некуда.
Получаем типичную «потогонку» или «галеру» и пока такой бизнес приносит средства для кормления всей этой руководящей пирамиды – никто ничего менять не будет.
А сегодня для принципа Питера открылось второе дыхание – нейросети, которые помогают поддерживать и даже повышать свой уровень некомпетентности, причем на всех уровнях.
Что с этим делать? Ничего, принимать как данное, ибо нейросеть просто инструмент, а поведение человека складывалось веками. Но умение распознавать подобные организации и стараться обходить их стороной – навык полезный.
🔥17👍13🤷♂5😁2
PHP2Shell
Второй день все сообщество гудит как растревоженный улей по поводу уязвимости PHP2Shell. Кто-то в панике обновляется, кто-то патчится, кто-то прикручивает костыли и судорожно прикидывает как жить дальше.
Под именем PHP2Shell скрываются две связанные уязвимости - CVE-2026-109618 и CVE-2026-109619, затрагивающие непосредственно сам интерпретатор PHP. Эксплуатация этих брешей позволяет неаутентифицированному удалённому злоумышленнику с сетевым доступом выполнить произвольный код (RCE) в контексте любого уязвимого PHP-приложения.
Не важно, насколько хорошо написан код вашего приложения, если оно работает на уязвимой версии интерпретатора, то под угрозой даже элементарный «Hello World».
Основная проблема в том, что уязвимыми оказались все версии начиная с PHP 5.4 и этот скриптовый язык используется примерно на 70% сайтов в интернете, т.е. касается буквально каждого.
Хотя, если посмотреть на ситуацию со стороны, то в наш век развитого ИИ ничего удивительного в этом нет, подобные уязвимости находят практически каждый день везде, начиная от ядра Linux и заканчивая какими-нибудь библиотеками.
Но в данном случае попадание пришлось в крайне уязвимое место и теперь главное трезво оценить ситуацию и сделать правильные выводы.
А именно проанализировать реакцию на это событие. Разработчики PHP оперативно выпустили патчи для версии 8.2 – 8.5, для версий 7.4 – 8.1 патч доступен только в виде исходного кода.
Фактически разработчики оставили поддержку только актуальных версий, которые будут поддерживать и собирать. Для не сильно устаревших патч в сорцах, собирайте сами. Ну а старые версии полностью списаны в расход.
В Ubuntu сами пропатчили все пакеты до 5.х включительно и обновления получат все дистрибутивы на официальной поддержке, включая промежуточный 26.10. Пользователи 14.04 LTS, 16.04 LTS, 18.04 LTS и 20.04 LTS получат патчи при наличии подписки Ubuntu Pro (ESM).
В Debian патчи получат пользователи Debian 12 и Debian 13. Для Debian 11, чей пятилетний цикл завершился в августе 2026 года, обновлений нет, закрытие бреши ложится исключительно на плечи команды Extended LTS (ELTS) от Freexian, если на пакет PHP найдутся спонсоры.
В экосистеме RHEL-совместимых дистрибутивов (AlmaLinux и Rocky Linux) ситуация решается через AppStream-модули и оперативную пересборку апстрим-исправлений. Пропатчены стримы в релизах EL8, а также ветки PHP в EL9 и EL10. Для EL7 обновлений нет и не будет.
Что касается популярных репозиториев отдельных энтузиастов, то тут все зависит от них самих, так Ондрей Сури (Debian/Ubuntu) пакеты оперативно пропатчил, а вот Реми Колле (RHEL) уехал в отпуск как раз перед обнаружением уязвимости и все, кто использовал его репозитории в продакшене будут под ударом пока автор не вернется с отдыха.
А так как таких ситуаций с каждым днем будет все больше и больше, то ставить в продуктовые среды продукты одиночек-энтузиастов становится неоправданным риском и, по сути, ставит крест на небольших проектах, авторы которых просто перестанут успевать патчить свои сборки.
Также надо гораздо более тщательно подходить к выбору ОС, хороший пример – это Debian и Ubuntu, хотя и там, и там, казалось бы, по «5 лет» поддержки.
Второй день все сообщество гудит как растревоженный улей по поводу уязвимости PHP2Shell. Кто-то в панике обновляется, кто-то патчится, кто-то прикручивает костыли и судорожно прикидывает как жить дальше.
Под именем PHP2Shell скрываются две связанные уязвимости - CVE-2026-109618 и CVE-2026-109619, затрагивающие непосредственно сам интерпретатор PHP. Эксплуатация этих брешей позволяет неаутентифицированному удалённому злоумышленнику с сетевым доступом выполнить произвольный код (RCE) в контексте любого уязвимого PHP-приложения.
Не важно, насколько хорошо написан код вашего приложения, если оно работает на уязвимой версии интерпретатора, то под угрозой даже элементарный «Hello World».
Основная проблема в том, что уязвимыми оказались все версии начиная с PHP 5.4 и этот скриптовый язык используется примерно на 70% сайтов в интернете, т.е. касается буквально каждого.
Хотя, если посмотреть на ситуацию со стороны, то в наш век развитого ИИ ничего удивительного в этом нет, подобные уязвимости находят практически каждый день везде, начиная от ядра Linux и заканчивая какими-нибудь библиотеками.
Но в данном случае попадание пришлось в крайне уязвимое место и теперь главное трезво оценить ситуацию и сделать правильные выводы.
А именно проанализировать реакцию на это событие. Разработчики PHP оперативно выпустили патчи для версии 8.2 – 8.5, для версий 7.4 – 8.1 патч доступен только в виде исходного кода.
Фактически разработчики оставили поддержку только актуальных версий, которые будут поддерживать и собирать. Для не сильно устаревших патч в сорцах, собирайте сами. Ну а старые версии полностью списаны в расход.
В Ubuntu сами пропатчили все пакеты до 5.х включительно и обновления получат все дистрибутивы на официальной поддержке, включая промежуточный 26.10. Пользователи 14.04 LTS, 16.04 LTS, 18.04 LTS и 20.04 LTS получат патчи при наличии подписки Ubuntu Pro (ESM).
В Debian патчи получат пользователи Debian 12 и Debian 13. Для Debian 11, чей пятилетний цикл завершился в августе 2026 года, обновлений нет, закрытие бреши ложится исключительно на плечи команды Extended LTS (ELTS) от Freexian, если на пакет PHP найдутся спонсоры.
В экосистеме RHEL-совместимых дистрибутивов (AlmaLinux и Rocky Linux) ситуация решается через AppStream-модули и оперативную пересборку апстрим-исправлений. Пропатчены стримы в релизах EL8, а также ветки PHP в EL9 и EL10. Для EL7 обновлений нет и не будет.
Что касается популярных репозиториев отдельных энтузиастов, то тут все зависит от них самих, так Ондрей Сури (Debian/Ubuntu) пакеты оперативно пропатчил, а вот Реми Колле (RHEL) уехал в отпуск как раз перед обнаружением уязвимости и все, кто использовал его репозитории в продакшене будут под ударом пока автор не вернется с отдыха.
А так как таких ситуаций с каждым днем будет все больше и больше, то ставить в продуктовые среды продукты одиночек-энтузиастов становится неоправданным риском и, по сути, ставит крест на небольших проектах, авторы которых просто перестанут успевать патчить свои сборки.
Также надо гораздо более тщательно подходить к выбору ОС, хороший пример – это Debian и Ubuntu, хотя и там, и там, казалось бы, по «5 лет» поддержки.
👍12❤4🥱2👀1
Про помогаторов
На фоне последних событий рассмотрим еще один феномен – помогаторство.
Суть его сводится к тому, что коллеги начинают ошибочно путать процесс зарабатывания денег с помощью клиенту, даже если он об этом не просил и денег за это не предлагал.
В чем это проявляется? Обычно берут подряд на один вид работ, но в процессе всплывают некоторые сложности и вместо того, чтобы озадачить этим клиента, они начинают решать вопрос самостоятельно, либо пытаются решить задачу наличными средствами.
Например, аппаратные средства заказчика явно не соответствуют решаемой задаче. Правильно – это сделать стоп и довести до заказчика реальные требования. А не соглашаться «ну сделать пока как-то так, а там решим».
Потому что ничего «там» не решат, а будут тянуть полудохлую систему до последнего, постоянно прося вас «что-то» сделать. И если вначале просить будут вежливо и даже давать денег, то потом начнут просто требовать и возмущаться, потому как мы тебе столько денег заплатили, а ты нормально ничего сделать не можешь.
А попытка таки вернуть ситуацию на стартовую позицию с покупкой адекватного железа обернется тем «а почему ты мне сразу не сказал» и вряд ли вы снова что-то нормально заработаете. Плюс вам заказчик будет постоянно внушать чувство вины за ваш прошлый «прокол».
Следует понимать, что у вас свой бизнес, у него свой и каждый из вас преследует цель заработать денег, а не взять на себя проблемы и головняки контрагента.
Ему нужно работать? Ну так пусть покупает адекватное железо или ищет неадекватного исполнителя, которому потом будет выносить мозги тем, как у него всё плохо, и это все потому, что исполнитель не может ничего нормально наладить.
Еще раз – это его бизнес и его проблемы. А не ваши. Ваша проблема – заработать указанную сумму денег без лишних проблем и заморочек. Пытаясь решить проблему заказчика подобным образом, вы только перекладываете чужие проблемы на себя.
При этом проблема никуда не денется, ее придется решать, только уже не заказчику, а вам. Так как голова начнет болеть не у него, а у вас. Потому что это вы ему пообещали сделать хоть как-нибудь, и он с вас будет требовать обещанное.
А то, что обещанное не решается наличными средствами, так заказчику это неведомо, он и знать ничего такого не обязан, но как рачительный собственник он, конечно же, попытался у вас узнать, можно ли как-то пока поработать так, вы сказали можно.
Вторая крайность - это создание для заказчика дополнительных сервисов и услуг, которые он не заказывал. Тот же мониторинг, резервные копии и т.д. и т.п.
Возможно, это связано с профдеформацией при работе в крупных организациях, где специалист знает, что при сбоях с него в первую очередь спросят про то, где был мониторинг и откуда взять резервные копии.
Здесь все гораздо проще. Доступно объясняете заказчику, на понятном ему языке, что может произойти и какие варианты вы предлагаете на этот случай. Отказывается – объясняем еще раз. Предельно понятно. Вот это сервер, он сгорел, нафиг, совсем, ничего нет. Что делать будешь?
Снова отказывается? Ну это его проблемы. Спокойно уходим, а если он таки прибегает с такой проблемой, то разводим руками и говорим, что мы его предупреждали. И никаких угрызений совести тут быть не должно. Это его бизнес, его риски. Вы сделали ровно то, что вас просили, остальное не ваши проблемы.
И здесь мы плавно подходим к тому, что нужно уметь твердо, но корректно говорить заказчику нет, когда он пытается попутно нагрузить вас другой проблемой. Следует пояснить, что выполнили вы один объем работ, то, что он хочет – это другое, это другой объем услуг и другая оплата.
Хороший пример был в комментариях, мол вы настроили нам обмен, а теперь у нас не идут остатки. Тут все просто, обмен – это обмен. Работает? Ну прекрасно, вот акт, вот счет.
Надо что-то решать с остатками? Это другая услуга, стоить будет примерно столько. Устраивает? Работаем.
Иначе вы так и останетесь помогатором, который будет тратить собственное время и решать при этом чужие проблемы за собственный счет.
На фоне последних событий рассмотрим еще один феномен – помогаторство.
Суть его сводится к тому, что коллеги начинают ошибочно путать процесс зарабатывания денег с помощью клиенту, даже если он об этом не просил и денег за это не предлагал.
В чем это проявляется? Обычно берут подряд на один вид работ, но в процессе всплывают некоторые сложности и вместо того, чтобы озадачить этим клиента, они начинают решать вопрос самостоятельно, либо пытаются решить задачу наличными средствами.
Например, аппаратные средства заказчика явно не соответствуют решаемой задаче. Правильно – это сделать стоп и довести до заказчика реальные требования. А не соглашаться «ну сделать пока как-то так, а там решим».
Потому что ничего «там» не решат, а будут тянуть полудохлую систему до последнего, постоянно прося вас «что-то» сделать. И если вначале просить будут вежливо и даже давать денег, то потом начнут просто требовать и возмущаться, потому как мы тебе столько денег заплатили, а ты нормально ничего сделать не можешь.
А попытка таки вернуть ситуацию на стартовую позицию с покупкой адекватного железа обернется тем «а почему ты мне сразу не сказал» и вряд ли вы снова что-то нормально заработаете. Плюс вам заказчик будет постоянно внушать чувство вины за ваш прошлый «прокол».
Следует понимать, что у вас свой бизнес, у него свой и каждый из вас преследует цель заработать денег, а не взять на себя проблемы и головняки контрагента.
Ему нужно работать? Ну так пусть покупает адекватное железо или ищет неадекватного исполнителя, которому потом будет выносить мозги тем, как у него всё плохо, и это все потому, что исполнитель не может ничего нормально наладить.
Еще раз – это его бизнес и его проблемы. А не ваши. Ваша проблема – заработать указанную сумму денег без лишних проблем и заморочек. Пытаясь решить проблему заказчика подобным образом, вы только перекладываете чужие проблемы на себя.
При этом проблема никуда не денется, ее придется решать, только уже не заказчику, а вам. Так как голова начнет болеть не у него, а у вас. Потому что это вы ему пообещали сделать хоть как-нибудь, и он с вас будет требовать обещанное.
А то, что обещанное не решается наличными средствами, так заказчику это неведомо, он и знать ничего такого не обязан, но как рачительный собственник он, конечно же, попытался у вас узнать, можно ли как-то пока поработать так, вы сказали можно.
Вторая крайность - это создание для заказчика дополнительных сервисов и услуг, которые он не заказывал. Тот же мониторинг, резервные копии и т.д. и т.п.
Возможно, это связано с профдеформацией при работе в крупных организациях, где специалист знает, что при сбоях с него в первую очередь спросят про то, где был мониторинг и откуда взять резервные копии.
Здесь все гораздо проще. Доступно объясняете заказчику, на понятном ему языке, что может произойти и какие варианты вы предлагаете на этот случай. Отказывается – объясняем еще раз. Предельно понятно. Вот это сервер, он сгорел, нафиг, совсем, ничего нет. Что делать будешь?
Снова отказывается? Ну это его проблемы. Спокойно уходим, а если он таки прибегает с такой проблемой, то разводим руками и говорим, что мы его предупреждали. И никаких угрызений совести тут быть не должно. Это его бизнес, его риски. Вы сделали ровно то, что вас просили, остальное не ваши проблемы.
И здесь мы плавно подходим к тому, что нужно уметь твердо, но корректно говорить заказчику нет, когда он пытается попутно нагрузить вас другой проблемой. Следует пояснить, что выполнили вы один объем работ, то, что он хочет – это другое, это другой объем услуг и другая оплата.
Хороший пример был в комментариях, мол вы настроили нам обмен, а теперь у нас не идут остатки. Тут все просто, обмен – это обмен. Работает? Ну прекрасно, вот акт, вот счет.
Надо что-то решать с остатками? Это другая услуга, стоить будет примерно столько. Устраивает? Работаем.
Иначе вы так и останетесь помогатором, который будет тратить собственное время и решать при этом чужие проблемы за собственный счет.
👍39💯16🥱4❤1
Наташ, ты спишь? Мы там все уронили и мониторинг твой не сработал…
Мониторинг – тема сложная, гораздо сложнее чем кажется на первый взгляд и главное в ней правильно настроить объект мониторинга, чтобы получать нужное и не получать ненужное.
А еще хуже, когда мы мониторим вообще не то, что надо. В результате о случившемся нас оповестит не мониторинг, а разгневанные пользователи.
На днях обновляли 1С:Предприятие в одной подопечной организации и местный админ попросил что-нибудь простое и современное для мониторинга доступности основных сервисов, чтобы просто видеть, что живо, а что упало.
Показали ему Uptime Kuma, понравилось, запустили. Он пошел добавлять узлы, а мы принялись за свою работу, а потом все-таки заглянули посмотреть, что он там сделал и сильно удивились.
В общем это классика жанра. В нашем случае это был веб-сервер с опубликованными на нем базами 1С:Предприятие, скажем 1с.example.com, ну вот наш коллега ничтоже сумняшеся взял и добавил в монитор именно этот узел.
После чего мы предложили ему сесть и подумать, что именно будет контролировать такой монитор? Чтобы активировать мыслительный процесс мы предложили перейти по этой ссылке и полюбоваться на стандартную заглушку IIS/Apache.
Да, такой монитор покажет нам жив ли веб-сервер в принципе, но никакого контроля над опубликованными на нем сервисах у нас не будет. В данном случае хуже будет только Ping, хотя и так многие делают, а потом сильно удивляются, когда их будят рано утром.
А вот здесь самое время подумать, что именно нам нужно мониторить. Веб-сервер? Его статус в вакууме нам не даст никакой полезной информации. Веб-приложения? Именно, вот именно их состояние нам и интересно.
Мы вполне можем получить ситуацию, когда веб-сервер работает нормально, а веб-приложение или сайт вдруг начали выдавать коды 4хх или 5хх и наша задача узнать об этом своевременно, а не тогда, когда найдут и разбудят.
Поэтому добавляем в мониторинг не один узел, а три, по количеству опубликованных веб-сервисов (понятно, что у вас может быть любое количество) и теперь мы будем видеть состояние каждого из них в отдельности.
Теперь вы можете своевременно реагировать на происходящее и четко понимать, что и с кем случилось.
Этот подход следует применять для любых систем мониторинга и сервисов. Помните, что нас интересует не состояние узла, а работоспособность развернутых на нем сервисов, поэтому мониторить нам нужно именно их, а потом уже все остальное.
Кстати, состоянием узла тоже пренебрегать не стоит. Особенно если есть возможность настраивать зависимости. Скажем в Zabbix вы можете настроить зависимости триггеров сервисов от состояния узла и если он полностью выключен, то Zabbix не будет спамить вас десятком сообщений о недоступности каждого сервиса в отдельности, а просто скажет, что узел такой-то не в сети.
Но первичны у нас именно сервисы, помните об этом!
Мониторинг – тема сложная, гораздо сложнее чем кажется на первый взгляд и главное в ней правильно настроить объект мониторинга, чтобы получать нужное и не получать ненужное.
А еще хуже, когда мы мониторим вообще не то, что надо. В результате о случившемся нас оповестит не мониторинг, а разгневанные пользователи.
На днях обновляли 1С:Предприятие в одной подопечной организации и местный админ попросил что-нибудь простое и современное для мониторинга доступности основных сервисов, чтобы просто видеть, что живо, а что упало.
Показали ему Uptime Kuma, понравилось, запустили. Он пошел добавлять узлы, а мы принялись за свою работу, а потом все-таки заглянули посмотреть, что он там сделал и сильно удивились.
В общем это классика жанра. В нашем случае это был веб-сервер с опубликованными на нем базами 1С:Предприятие, скажем 1с.example.com, ну вот наш коллега ничтоже сумняшеся взял и добавил в монитор именно этот узел.
После чего мы предложили ему сесть и подумать, что именно будет контролировать такой монитор? Чтобы активировать мыслительный процесс мы предложили перейти по этой ссылке и полюбоваться на стандартную заглушку IIS/Apache.
Да, такой монитор покажет нам жив ли веб-сервер в принципе, но никакого контроля над опубликованными на нем сервисах у нас не будет. В данном случае хуже будет только Ping, хотя и так многие делают, а потом сильно удивляются, когда их будят рано утром.
А вот здесь самое время подумать, что именно нам нужно мониторить. Веб-сервер? Его статус в вакууме нам не даст никакой полезной информации. Веб-приложения? Именно, вот именно их состояние нам и интересно.
Мы вполне можем получить ситуацию, когда веб-сервер работает нормально, а веб-приложение или сайт вдруг начали выдавать коды 4хх или 5хх и наша задача узнать об этом своевременно, а не тогда, когда найдут и разбудят.
Поэтому добавляем в мониторинг не один узел, а три, по количеству опубликованных веб-сервисов (понятно, что у вас может быть любое количество) и теперь мы будем видеть состояние каждого из них в отдельности.
Теперь вы можете своевременно реагировать на происходящее и четко понимать, что и с кем случилось.
Этот подход следует применять для любых систем мониторинга и сервисов. Помните, что нас интересует не состояние узла, а работоспособность развернутых на нем сервисов, поэтому мониторить нам нужно именно их, а потом уже все остальное.
Кстати, состоянием узла тоже пренебрегать не стоит. Особенно если есть возможность настраивать зависимости. Скажем в Zabbix вы можете настроить зависимости триггеров сервисов от состояния узла и если он полностью выключен, то Zabbix не будет спамить вас десятком сообщений о недоступности каждого сервиса в отдельности, а просто скажет, что узел такой-то не в сети.
Но первичны у нас именно сервисы, помните об этом!
👍11❤2
ZFS на скромном сервере
ZFS привыкли воспринимать как тяжеловесный enterprise-комбайн. Но если спуститься на землю — в реалии небольшого продакшна (один сервер, Proxmox/LXC, связка из 1С с PostgreSQL и потребительские NVMe), возможности ZFS раскрываются с сугубо прикладной стороны.
Главное — сразу отбросить старые догмы.
1️⃣ Почему ZFS идеальна для LXC и баз данных
В отличие от классического LVM или жестких разделов, ZFS дает единый пул (zpool), поверх которого нарезаются датасеты — легкие логические файловые системы. Никаких фиксированных гигабайт: каждый датасет видит весь свободный пул, но управляется индивидуально.
🔸 recordsize под задачу. По умолчанию в ZFS блок равен 128 КБ. Для СУБД со случайной записью страницами по 8 КБ это верная смерть накопителя из-за дикого Write Amplification (WAF). Датасет базы с
🔸 Встроенное сжатие (LZ4/ZSTD). Это не про экономию диска, это про ресурс потребительского флеша. Сжатие уменьшает физический объем, который контроллер SSD пишет в ячейки. Меньше физической записи - ниже WAF и дольше живет TBW.
🔸 ARC вместо page cache. Умный двухфакторный кэш в оперативной памяти (ARC) отслеживает не просто недавние обращения (MRU), но и их частоту (MFU). Случайный тяжелый отчет в 1С не вымоет из памяти горячие индексы живой базы.
2️⃣ L2ARC: почему вторичный кэш здесь вреден
L2ARC создавался 15 лет назад для гибридных хранилищ, чтобы прикрыть медленные «холодные» HDD быстрыми SSD. Ставить его в NVMe-сервер - грубейшая ошибка.
🔸 Кража оперативной памяти. Чтобы адресовать блоки в L2ARC, ZFS держит таблицу указателей прямо в RAM. Выделяя SSD под L2ARC, вы отбираете мегабайты и гигабайты памяти у ARC.
🔸 Бессмысленность шины. Чтение блока с соседнего бытового NVMe идет с теми же задержками PCIe, что и с основного пула. Профита по задержкам - ноль.
🔸 Сжигание ячеек мусором. В L2ARC вытесняется в основном MRU-хвост. Туда потоком летят одноразовые блоки от бэкапов и квартальных проводок. Вы просто тупо стираете ресурс записью «мусора», который больше никогда не будет прочитан
3️⃣ SLOG на копеечном Optane 16 ГБ: громоотвод для СУБД
Базы данных требуют строгой фиксации транзакций (fsync). У потребительских NVMe нет аппаратной защиты от потери питания (PLP). При каждом вызове fsync бытовой контроллер сбрасывает буферы прямо во флеш-память, вызывая провалы по задержкам и раздувая WAF двойной записью в ZIL.
Спасение — отдельный лог записи (SLOG) на стареньком Intel Optane на 16 ГБ (серия M10), купленном за копейки:
🔸 Нам не нужны терабайты: SLOG держит данные только до сброса транзакционной группы (раз в 5 секунд).
🔸 Линейная скорость не важна (у 16 ГБ Optane она всего ~150 МБ/с). Главное — физика памяти 3D XPoint: у нее нет блоков стирания, нет падения скорости после SLC-кэша и микросекундные задержки.
🔸 Optane спокойно живет даже на переходнике в одной линии PCIe x1. Его задача — быстро подтвердить транзакцию СУБД за микросекунды и избавить основной NVMe-пул от мелкоблочной случайной записи.
4️⃣ Special VDEV: когда он нужен, а когда создает риски
Special Allocation Class выносит метаданные (а опционально и мелкие блоки) на выделенные накопители.
🔸В чем риск? Special VDEV — это не кэш, а часть структуры данных пула. Смерть special хоронит zpool целиком. Поэтому сюда допустимо ставить строго зеркало (Mirror). На чисто твердотельном NVMe-сервере под 1С от него мало толку - задержки метаданных на основном пуле и так микросекундные.
🔸 Где он идеален? В сценариях сегрегации нагрузки. Например, у вас есть холодный архив на HDD (почта, файлопомойка): пара небольших NVMe под special заставит поиск и листинг миллионов файлов летать без дерганья шпинделей.
👉 Резюме: ZFS на потребительском железе требует не слепого следования мануалам, а понимания физики накопителей. Выравнивайте recordsize, включайте сжатие, забывайте про L2ARC как про страшный сон, а на сдачу поставьте копеечный Optane под журнал ZIL.
ZFS привыкли воспринимать как тяжеловесный enterprise-комбайн. Но если спуститься на землю — в реалии небольшого продакшна (один сервер, Proxmox/LXC, связка из 1С с PostgreSQL и потребительские NVMe), возможности ZFS раскрываются с сугубо прикладной стороны.
Главное — сразу отбросить старые догмы.
1️⃣ Почему ZFS идеальна для LXC и баз данных
В отличие от классического LVM или жестких разделов, ZFS дает единый пул (zpool), поверх которого нарезаются датасеты — легкие логические файловые системы. Никаких фиксированных гигабайт: каждый датасет видит весь свободный пул, но управляется индивидуально.
🔸 recordsize под задачу. По умолчанию в ZFS блок равен 128 КБ. Для СУБД со случайной записью страницами по 8 КБ это верная смерть накопителя из-за дикого Write Amplification (WAF). Датасет базы с
recordsize=8k сразу убирает оверхед. Датасет под бэкапы или логи при этом спокойно живет со стандартными 128 КБ.🔸 Встроенное сжатие (LZ4/ZSTD). Это не про экономию диска, это про ресурс потребительского флеша. Сжатие уменьшает физический объем, который контроллер SSD пишет в ячейки. Меньше физической записи - ниже WAF и дольше живет TBW.
🔸 ARC вместо page cache. Умный двухфакторный кэш в оперативной памяти (ARC) отслеживает не просто недавние обращения (MRU), но и их частоту (MFU). Случайный тяжелый отчет в 1С не вымоет из памяти горячие индексы живой базы.
2️⃣ L2ARC: почему вторичный кэш здесь вреден
L2ARC создавался 15 лет назад для гибридных хранилищ, чтобы прикрыть медленные «холодные» HDD быстрыми SSD. Ставить его в NVMe-сервер - грубейшая ошибка.
🔸 Кража оперативной памяти. Чтобы адресовать блоки в L2ARC, ZFS держит таблицу указателей прямо в RAM. Выделяя SSD под L2ARC, вы отбираете мегабайты и гигабайты памяти у ARC.
🔸 Бессмысленность шины. Чтение блока с соседнего бытового NVMe идет с теми же задержками PCIe, что и с основного пула. Профита по задержкам - ноль.
🔸 Сжигание ячеек мусором. В L2ARC вытесняется в основном MRU-хвост. Туда потоком летят одноразовые блоки от бэкапов и квартальных проводок. Вы просто тупо стираете ресурс записью «мусора», который больше никогда не будет прочитан
3️⃣ SLOG на копеечном Optane 16 ГБ: громоотвод для СУБД
Базы данных требуют строгой фиксации транзакций (fsync). У потребительских NVMe нет аппаратной защиты от потери питания (PLP). При каждом вызове fsync бытовой контроллер сбрасывает буферы прямо во флеш-память, вызывая провалы по задержкам и раздувая WAF двойной записью в ZIL.
Спасение — отдельный лог записи (SLOG) на стареньком Intel Optane на 16 ГБ (серия M10), купленном за копейки:
🔸 Нам не нужны терабайты: SLOG держит данные только до сброса транзакционной группы (раз в 5 секунд).
🔸 Линейная скорость не важна (у 16 ГБ Optane она всего ~150 МБ/с). Главное — физика памяти 3D XPoint: у нее нет блоков стирания, нет падения скорости после SLC-кэша и микросекундные задержки.
🔸 Optane спокойно живет даже на переходнике в одной линии PCIe x1. Его задача — быстро подтвердить транзакцию СУБД за микросекунды и избавить основной NVMe-пул от мелкоблочной случайной записи.
4️⃣ Special VDEV: когда он нужен, а когда создает риски
Special Allocation Class выносит метаданные (а опционально и мелкие блоки) на выделенные накопители.
🔸В чем риск? Special VDEV — это не кэш, а часть структуры данных пула. Смерть special хоронит zpool целиком. Поэтому сюда допустимо ставить строго зеркало (Mirror). На чисто твердотельном NVMe-сервере под 1С от него мало толку - задержки метаданных на основном пуле и так микросекундные.
🔸 Где он идеален? В сценариях сегрегации нагрузки. Например, у вас есть холодный архив на HDD (почта, файлопомойка): пара небольших NVMe под special заставит поиск и листинг миллионов файлов летать без дерганья шпинделей.
👉 Резюме: ZFS на потребительском железе требует не слепого следования мануалам, а понимания физики накопителей. Выравнивайте recordsize, включайте сжатие, забывайте про L2ARC как про страшный сон, а на сдачу поставьте копеечный Optane под журнал ZIL.
10👍15🔥6❤2🤯1🤮1
Про эффективный менеджмент
Сегодня суббота, а поэтому будет одна поучительная история из жизни. Середина нулевых, один местечковый районный провайдер, тогда таких было много.
Мы одно время работали в одном здании с ними, а поэтому хорошо друг друга знали. Потом у них дела пошли в гору, и они переехали в отдельное здание и наши пути потихоньку разошлись.
Ребята там были неплохие, кроме директора, был он, мягко скажем, немного скуповатым, хотя если честно, то далеко не немного. Но была у него еще вторая негативная черта характера. Все, кто имел сомнительное удовольствие с ним долго общаться не именовали его иначе чем чудак на букву М.
Я тоже жил в том районе и пользовался их интернетом и вскоре начал замечать, что проблемы только растут и множатся. То скорости нет, то связь пропала, то еще что-нибудь.
Хотя были иногда и приятные моменты, скажем, на майские праздники отключился биллинг и каждый качал-закачивался. А интернет в ту пору тарифицировался, если кто не помнит или не знает, помегабайтно.
Потом я как-то спросил ребят провайдера, а что это за аттракцион невиданной щедрости был?
Выяснилось, что шеф расплевался с их давним сисадмином, который стоял еще у истоков конторы и тот ушел, хлопнув дверью и назвав шефа чудаком. За серверами с диковинной FreeBSD никто не следил, так как не понимал, как следить, и в один прекрасный день место на дисках просто закончилось.
Биллинг прилег и народ все праздники резвился, попутно загоняя контору в долги. После чего из конторы ушел второй человек, который также стоял у ее основания и понимал в сетях.
Но шефа ничего не смутило, подумаешь, сисадмин, ну и подумаешь сетевой инженер. Больно нужны, у нас же все хорошо. Были приглашены специалисты со стороны и был внедрен новый биллинг, уже на Linux.
Между тем качество услуг стремительно падало, но во всем оказались виноваты пользователи, мол это они положили сеть широковещательными чатами и DC++ обменом. После чего эти приложения попытались просто запретить. Мол у кого обнаружим – отключим.
Но отключить пришлось бы решительно всех, поэтому такая инициатива сошла на нет. Лучше, естественно, не стало. Да и как оно станет в отсутствие сетевого инженера.
Прошло еще года полтора, звонит мне их шеф, мол ты же в Linux понимаешь? Понимаю. Приезжай, дело есть.
Приехал. Новый биллинг лежит. Начинаю разбираться. В наличии неплохой по тем временам сервер и RAID 5 с запасным диском. В RAID 5 выпали два диска из трех, а запасной кто-то свистнул, поставив вместо него неисправный диск бытовой серии.
Ну что тут было сказать? Только похлопать по плечу и сообщить, что медицина бессильна. Особенно если в штате не было ни одного следящего за инфраструктурой сотрудника.
Пошарившись по серверной нашли сервер с бекапами, но там был только бекап БД биллинга.
Ну вот, не все так плохо, можно восстановить.
Он спрашивает меня, смогу ли я это сделать. Отвечаю, что нет, я этот биллинг первый раз в жизни вижу и лучше всего обратиться к его разработчикам.
Выяснилось, что это не вариант, так как он им денег должен и за поддержку не платил два года. А зачем, ведь все работало.
В общем, принес ему свои соболезнования и сказал, что мне пора и было бы неплохо дать мне денег.
На что услышал, а за что тебе денег, ты же ничем мне не помог. В итоге, пояснил ему, что он чудак, развернулся и ушел.
Провайдеру тут же настал карачун, народ разбежался. А шеф? Шеф продал сети одному из федеральных провайдеров.
А что же теперь? А он теперь начальник в местном отделении федерального провайдера. До чего-то важного его не допускают, но теплое кресло выделили. Ну и репутация чудака на букву М за ним числится до сих пор.
Он же, в свою очередь, особенно после пары рюмок, любит поучать молодежь и рассказывать как у него давно был свой бизнес и как он его удачно продал, поняв, что не может тягаться на равных с федералами.
Сегодня суббота, а поэтому будет одна поучительная история из жизни. Середина нулевых, один местечковый районный провайдер, тогда таких было много.
Мы одно время работали в одном здании с ними, а поэтому хорошо друг друга знали. Потом у них дела пошли в гору, и они переехали в отдельное здание и наши пути потихоньку разошлись.
Ребята там были неплохие, кроме директора, был он, мягко скажем, немного скуповатым, хотя если честно, то далеко не немного. Но была у него еще вторая негативная черта характера. Все, кто имел сомнительное удовольствие с ним долго общаться не именовали его иначе чем чудак на букву М.
Я тоже жил в том районе и пользовался их интернетом и вскоре начал замечать, что проблемы только растут и множатся. То скорости нет, то связь пропала, то еще что-нибудь.
Хотя были иногда и приятные моменты, скажем, на майские праздники отключился биллинг и каждый качал-закачивался. А интернет в ту пору тарифицировался, если кто не помнит или не знает, помегабайтно.
Потом я как-то спросил ребят провайдера, а что это за аттракцион невиданной щедрости был?
Выяснилось, что шеф расплевался с их давним сисадмином, который стоял еще у истоков конторы и тот ушел, хлопнув дверью и назвав шефа чудаком. За серверами с диковинной FreeBSD никто не следил, так как не понимал, как следить, и в один прекрасный день место на дисках просто закончилось.
Биллинг прилег и народ все праздники резвился, попутно загоняя контору в долги. После чего из конторы ушел второй человек, который также стоял у ее основания и понимал в сетях.
Но шефа ничего не смутило, подумаешь, сисадмин, ну и подумаешь сетевой инженер. Больно нужны, у нас же все хорошо. Были приглашены специалисты со стороны и был внедрен новый биллинг, уже на Linux.
Между тем качество услуг стремительно падало, но во всем оказались виноваты пользователи, мол это они положили сеть широковещательными чатами и DC++ обменом. После чего эти приложения попытались просто запретить. Мол у кого обнаружим – отключим.
Но отключить пришлось бы решительно всех, поэтому такая инициатива сошла на нет. Лучше, естественно, не стало. Да и как оно станет в отсутствие сетевого инженера.
Прошло еще года полтора, звонит мне их шеф, мол ты же в Linux понимаешь? Понимаю. Приезжай, дело есть.
Приехал. Новый биллинг лежит. Начинаю разбираться. В наличии неплохой по тем временам сервер и RAID 5 с запасным диском. В RAID 5 выпали два диска из трех, а запасной кто-то свистнул, поставив вместо него неисправный диск бытовой серии.
Ну что тут было сказать? Только похлопать по плечу и сообщить, что медицина бессильна. Особенно если в штате не было ни одного следящего за инфраструктурой сотрудника.
Пошарившись по серверной нашли сервер с бекапами, но там был только бекап БД биллинга.
Ну вот, не все так плохо, можно восстановить.
Он спрашивает меня, смогу ли я это сделать. Отвечаю, что нет, я этот биллинг первый раз в жизни вижу и лучше всего обратиться к его разработчикам.
Выяснилось, что это не вариант, так как он им денег должен и за поддержку не платил два года. А зачем, ведь все работало.
В общем, принес ему свои соболезнования и сказал, что мне пора и было бы неплохо дать мне денег.
На что услышал, а за что тебе денег, ты же ничем мне не помог. В итоге, пояснил ему, что он чудак, развернулся и ушел.
Провайдеру тут же настал карачун, народ разбежался. А шеф? Шеф продал сети одному из федеральных провайдеров.
А что же теперь? А он теперь начальник в местном отделении федерального провайдера. До чего-то важного его не допускают, но теплое кресло выделили. Ну и репутация чудака на букву М за ним числится до сих пор.
Он же, в свою очередь, особенно после пары рюмок, любит поучать молодежь и рассказывать как у него давно был свой бизнес и как он его удачно продал, поняв, что не может тягаться на равных с федералами.
🔥11👍6😁4❤1🤮1
Кошмар на улице Вязов
Сегодня мне приснился страшный сон, от которого я проснулся буквально в холодном поту. На его фоне любые киношные монстры, маньяки и прочие ужастики кажутся невинным детским утренником.
Сон пересказывать не буду: местами он иррациональный, как и положено сновидениям. Но суть свелась к простой фабуле: в чужом городе у меня украли телефон, и я остался в незнакомом месте — без связи, без денег и без навигации.
И ведь это реальный кошмар современного мира. Сегодня смартфон — не просто средство связи, а цифровой центр человека, в котором сосредоточено практически всё. Оказавшись без него, чувствуешь себя буквально голым.
Начнём со связи. Сколько номеров помнит наизусть современный человек? Хорошо, если один — свой собственный. Люди старой закалки, возможно, удержат в памяти два-три номера самых близких. Но и то вряд ли: мы видим цифры один раз при сохранении, а дальше просто тапаем по записи в адресной книге.
К тому же основным средством общения давно стали мессенджеры. Они хоть и привязаны к номеру, но просто попросить телефон у прохожего и «быстро черкнуть в телегу» не выйдет. В итоге, даже если добрый человек протянет вам свой аппарат, звонить будет попросту некому. Память пуста. Но это лишь верхушка айсберга.
Деньги. Многие уже много лет назад отказались от наличных, а некоторые — и от физического пластика. Зачем носить с собой карты, если их можно потерять или забыть, когда всё и так в телефоне?
Тем более что у большинства карт больше одной: повседневная, для онлайн-покупок, для регулярных автосписаний. Деньги между ними перекидываются за секунду в банковском приложении.
Без смартфона вы рискуете остаться либо без копейки вообще, либо без доступа к основной части своих средств. А это уже проблема принципиально другого масштаба.
Третий момент — навигация. Мы намертво привыкли ориентироваться по экрану. Вбил адрес — тебе проложили маршрут или сразу вызвали такси. Причем можно даже без точного адреса: просто ткни «метро такое-то» или название торгового центра.
Спросить дорогу у прохожих? Большинство знает свой дом и пару соседних дворов. Если это не центральный вокзал, вам просто неопределенно махнут рукой: мол, идите вон до того угла, а там еще у кого-нибудь спросите. Да и до того же вокзала без денег и такси еще попробуй доберись.
Но и это не всё. Цифровизация окончательно поглотила сервисы: билеты, бронирования, документы. Недавно покупал билеты на поезд: на почту упало несколько PDF, в приложении РЖД всё подтянулось.
На посадку пустят по паспорту, но номер поезда, вагон и место надо где-то подсмотреть. Ладно, вокзал — полбеды: пришел пораньше, сел и жди, проводник через любой вагон разберется.
А как быть с арендой жилья? Сейчас повсеместно внедряют бесконтактное заселение. К моменту заезда вам в мессенджер просто скидывают код от кодового замка или сейфа с ключом.
Нет телефона — нет кода. И хоть головой в дверь бейся — никто не откроет, потому что на месте никого нет, а служба поддержки сидит в чате. Имея на руках полностью оплаченную бронь, вы запросто останетесь ночевать на лавочке.
Добавьте сюда страховки, справки, медицинский полис, который давно никто не носит на бумаге, — всё лежит на «Госуслугах». А ключ к ним — опять в кармане.
Конечно, можно по старинке распечатывать стопку бумаг, возить с собой заначку наличных и выбирать отели исключительно с круглосуточным ресепшеном. Но тренд неумолим: мы всё глубже уходим в стопроцентную цифру.
И смартфон в этой реальности стал единственной точкой присутствия человека. Потерял, разбил, украли или просто сел аккумулятор — и ты в ту же секунду выброшен на обочину жизни.
Сегодня мне приснился страшный сон, от которого я проснулся буквально в холодном поту. На его фоне любые киношные монстры, маньяки и прочие ужастики кажутся невинным детским утренником.
Сон пересказывать не буду: местами он иррациональный, как и положено сновидениям. Но суть свелась к простой фабуле: в чужом городе у меня украли телефон, и я остался в незнакомом месте — без связи, без денег и без навигации.
И ведь это реальный кошмар современного мира. Сегодня смартфон — не просто средство связи, а цифровой центр человека, в котором сосредоточено практически всё. Оказавшись без него, чувствуешь себя буквально голым.
Начнём со связи. Сколько номеров помнит наизусть современный человек? Хорошо, если один — свой собственный. Люди старой закалки, возможно, удержат в памяти два-три номера самых близких. Но и то вряд ли: мы видим цифры один раз при сохранении, а дальше просто тапаем по записи в адресной книге.
К тому же основным средством общения давно стали мессенджеры. Они хоть и привязаны к номеру, но просто попросить телефон у прохожего и «быстро черкнуть в телегу» не выйдет. В итоге, даже если добрый человек протянет вам свой аппарат, звонить будет попросту некому. Память пуста. Но это лишь верхушка айсберга.
Деньги. Многие уже много лет назад отказались от наличных, а некоторые — и от физического пластика. Зачем носить с собой карты, если их можно потерять или забыть, когда всё и так в телефоне?
Тем более что у большинства карт больше одной: повседневная, для онлайн-покупок, для регулярных автосписаний. Деньги между ними перекидываются за секунду в банковском приложении.
Без смартфона вы рискуете остаться либо без копейки вообще, либо без доступа к основной части своих средств. А это уже проблема принципиально другого масштаба.
Третий момент — навигация. Мы намертво привыкли ориентироваться по экрану. Вбил адрес — тебе проложили маршрут или сразу вызвали такси. Причем можно даже без точного адреса: просто ткни «метро такое-то» или название торгового центра.
Спросить дорогу у прохожих? Большинство знает свой дом и пару соседних дворов. Если это не центральный вокзал, вам просто неопределенно махнут рукой: мол, идите вон до того угла, а там еще у кого-нибудь спросите. Да и до того же вокзала без денег и такси еще попробуй доберись.
Но и это не всё. Цифровизация окончательно поглотила сервисы: билеты, бронирования, документы. Недавно покупал билеты на поезд: на почту упало несколько PDF, в приложении РЖД всё подтянулось.
На посадку пустят по паспорту, но номер поезда, вагон и место надо где-то подсмотреть. Ладно, вокзал — полбеды: пришел пораньше, сел и жди, проводник через любой вагон разберется.
А как быть с арендой жилья? Сейчас повсеместно внедряют бесконтактное заселение. К моменту заезда вам в мессенджер просто скидывают код от кодового замка или сейфа с ключом.
Нет телефона — нет кода. И хоть головой в дверь бейся — никто не откроет, потому что на месте никого нет, а служба поддержки сидит в чате. Имея на руках полностью оплаченную бронь, вы запросто останетесь ночевать на лавочке.
Добавьте сюда страховки, справки, медицинский полис, который давно никто не носит на бумаге, — всё лежит на «Госуслугах». А ключ к ним — опять в кармане.
Конечно, можно по старинке распечатывать стопку бумаг, возить с собой заначку наличных и выбирать отели исключительно с круглосуточным ресепшеном. Но тренд неумолим: мы всё глубже уходим в стопроцентную цифру.
И смартфон в этой реальности стал единственной точкой присутствия человека. Потерял, разбил, украли или просто сел аккумулятор — и ты в ту же секунду выброшен на обочину жизни.
😁15👍7❤4👀4🤮3
Современные файловые системы Linux
Выбор файловой системы в Linux может оказаться сложной задачей для новичка. На что смотреть? На тесты и бенчмарки, которые проводятся на пустом SSD и не отражают реальность?
Сегодня мы коротко разберем актуальный квартет: ext4, XFS, Btrfs и ZFS, подсветив все их основные плюсы и минусы.
1️⃣ ext4: Проверенная временем классика
Это классическая блочная журналируемая ФС с записью «на месте» (In-place update). Максимальная стабильность, предсказуемость и надежность, минимальное потребление ресурсов CPU и RAM. Все это проверено десятилетиями.
Но это именно классическая ФС и если вы хотите снапшоты, пулы, сжатие и проверку целостности – ничего этого нет.
Есть еще «родовая травма» - таблица индексных дескрипторов (inodes) размечается один раз на этапе форматирования и впоследствии изменена быть не может.
Если диск используется под сценарии с миллионами крошечных файлов (почтовый сервер с Maildir, кэш аватарок веб-сервера, мелкие сессии, очереди задач), наступает классический парадокс: свободное место есть , а записать файл нельзя.
2️⃣ XFS: Enterprise-стандарт
XFS - 64-битная высокомасштабируемая журналируемая ФС с аллокацией по экстентам (extents) и разделением пространства на независимые группы размещения (Allocation Groups).
Обеспечивает высокую производительность при параллельной многопоточной записи/чтении и работе с крупными файлами (видео, дампы, медиа).
Дефолтная ФС в enterprise-дистрибутивах (RHEL / Rocky / AlmaLinux).
Но есть и достаточно серьезные недостатки - раздел XFS нельзя уменьшить, вообще никак: система XFS умеет расти (xfs_growfs), но архитектурно не умеет уменьшаться.
А далее имеем классический случай, на смену одним дискам на 1 ТБ (честный двоичный байт 2^40 = 1024 ГБ) купили маркетинговый «терабайт» (10^12 байт ~ 931 ГиБ). И что? И все, приехали.
3️⃣ Btrfs: «Спасение» силами гигантов индустрии
На заре своего появления (конец 2000-х / начало 2010-х) Btrfs имела репутацию крайне нестабильной, «сырой» и опасной системы. Она регулярно теряла данные при падениях питания, страдала от критических багов в аллокаторе свободного места, а алгоритмы RAID5/6 были в целом неработоспособные.
Red Hat со временем и вовсе официально признала Btrfs устаревшей (deprecated в RHEL 7.4) и полностью вырезала её поддержку в RHEL 8, сделав будущее этой ФС очень туманным.
Поворотным моментом стал приход в Meta* новой команды инженеров (Крис Мейсон, Йозеф Бачик и прочие). Они переписали и довели до ума самые проблемные места, код работы со свободным пространством, асинхронную очистку, сжатие ZSTD и интеграцию с механизмами ядра Linux.
В итоге это превратило вечную «бета» в надежную систему, которая используется по умолчанию для SUSE и Fedora.
4️⃣ ZFS: Монолитная СХД в одном флаконе
Это не просто ФС, а связка: файловая система + менеджер томов + RAID с пулом накопителей и легкими датасетами. Полный сквозной контроль целостности: контрольные суммы на каждый блок, самовосстановление, снапшоты, репликация и собственный кэш ARC в RAM.
Но за это все приходится платить, в первую очередь высокими требованиями к RAM и высоким коэффициентом WAF (что характерно для всех CoW систем).
Хотя в грамотных руках это того стоит, вы получаете очень гибкое, настраиваемое и масштабируемое хранилище корпоративного уровня.
Выводы:
🔹Нужна железобетонная стабильность «поставил и забыл»? ext4.
🔹Высокие параллельные нагрузки, базы или огромные файлы без нужды сжимать раздел? XFS.
🔹Десктоп, снапшоты системы перед апдейтом и сжатие на лету? Btrfs.
🔹СХД, отказоустойчивые пулы, виртуализация и контроль целостности? ZFS.
* Meta признана экстремистской организацией в России.
Выбор файловой системы в Linux может оказаться сложной задачей для новичка. На что смотреть? На тесты и бенчмарки, которые проводятся на пустом SSD и не отражают реальность?
Сегодня мы коротко разберем актуальный квартет: ext4, XFS, Btrfs и ZFS, подсветив все их основные плюсы и минусы.
1️⃣ ext4: Проверенная временем классика
Это классическая блочная журналируемая ФС с записью «на месте» (In-place update). Максимальная стабильность, предсказуемость и надежность, минимальное потребление ресурсов CPU и RAM. Все это проверено десятилетиями.
Но это именно классическая ФС и если вы хотите снапшоты, пулы, сжатие и проверку целостности – ничего этого нет.
Есть еще «родовая травма» - таблица индексных дескрипторов (inodes) размечается один раз на этапе форматирования и впоследствии изменена быть не может.
Если диск используется под сценарии с миллионами крошечных файлов (почтовый сервер с Maildir, кэш аватарок веб-сервера, мелкие сессии, очереди задач), наступает классический парадокс: свободное место есть , а записать файл нельзя.
2️⃣ XFS: Enterprise-стандарт
XFS - 64-битная высокомасштабируемая журналируемая ФС с аллокацией по экстентам (extents) и разделением пространства на независимые группы размещения (Allocation Groups).
Обеспечивает высокую производительность при параллельной многопоточной записи/чтении и работе с крупными файлами (видео, дампы, медиа).
Дефолтная ФС в enterprise-дистрибутивах (RHEL / Rocky / AlmaLinux).
Но есть и достаточно серьезные недостатки - раздел XFS нельзя уменьшить, вообще никак: система XFS умеет расти (xfs_growfs), но архитектурно не умеет уменьшаться.
А далее имеем классический случай, на смену одним дискам на 1 ТБ (честный двоичный байт 2^40 = 1024 ГБ) купили маркетинговый «терабайт» (10^12 байт ~ 931 ГиБ). И что? И все, приехали.
3️⃣ Btrfs: «Спасение» силами гигантов индустрии
На заре своего появления (конец 2000-х / начало 2010-х) Btrfs имела репутацию крайне нестабильной, «сырой» и опасной системы. Она регулярно теряла данные при падениях питания, страдала от критических багов в аллокаторе свободного места, а алгоритмы RAID5/6 были в целом неработоспособные.
Red Hat со временем и вовсе официально признала Btrfs устаревшей (deprecated в RHEL 7.4) и полностью вырезала её поддержку в RHEL 8, сделав будущее этой ФС очень туманным.
Поворотным моментом стал приход в Meta* новой команды инженеров (Крис Мейсон, Йозеф Бачик и прочие). Они переписали и довели до ума самые проблемные места, код работы со свободным пространством, асинхронную очистку, сжатие ZSTD и интеграцию с механизмами ядра Linux.
В итоге это превратило вечную «бета» в надежную систему, которая используется по умолчанию для SUSE и Fedora.
4️⃣ ZFS: Монолитная СХД в одном флаконе
Это не просто ФС, а связка: файловая система + менеджер томов + RAID с пулом накопителей и легкими датасетами. Полный сквозной контроль целостности: контрольные суммы на каждый блок, самовосстановление, снапшоты, репликация и собственный кэш ARC в RAM.
Но за это все приходится платить, в первую очередь высокими требованиями к RAM и высоким коэффициентом WAF (что характерно для всех CoW систем).
Хотя в грамотных руках это того стоит, вы получаете очень гибкое, настраиваемое и масштабируемое хранилище корпоративного уровня.
Выводы:
🔹Нужна железобетонная стабильность «поставил и забыл»? ext4.
🔹Высокие параллельные нагрузки, базы или огромные файлы без нужды сжимать раздел? XFS.
🔹Десктоп, снапшоты системы перед апдейтом и сжатие на лету? Btrfs.
🔹СХД, отказоустойчивые пулы, виртуализация и контроль целостности? ZFS.
* Meta признана экстремистской организацией в России.
1👍18❤6🥱2
Какую ФС на серверах с Linux вы используете? (Можно выбрать несколько значений)
Anonymous Poll
78%
ext4
15%
XFS
12%
BtrFS
31%
ZFS
0%
Свой вариант (в комментариях)
13%
Просто посмотреть ответы
👍3
Подключаем диск из NAS в Linux, или монтирование RAID и LVM разделов
Всем нам знакомы и привычны аппаратные NAS, они используются дома и на работе для хранения самых различных данных. Но любое оборудование может выходить из строя, обычно неожиданно и перед администратором может встать задача копирования данных с дисков NAS.
На первый взгляд в ней нет ничего сложного: в основе прошивки Linux, а значит берем любую Linux систему, подключаем, монтируем, сливаем...
Однако не все так просто и для выполнения этой задачи могут потребоваться достаточно глубокие знания систем хранения Linux и навыков работы с ними.
Разбирать подобные ситуации лучше на примерах, тем более в нашем случае он как будто специально, достаточно показательный.
На днях к нам обратился коллега с просьбой помочь достать информацию с диска, вышедшего из строя NAS Synology DS216. На наш вопрос в чем там проблема он уклончиво ответил, что как-то все сложно и он боится сделать что-нибудь не так и испортить данные.
Ну что же, давайте разбираться. Итак, перед нами следующие вводные: есть диск из двухдискового NAS, работавшего с зеркальным RAID-массивом, в качестве файловой системы использовалась ext4.
✅ Читать далее: https://interface31.ru/post/podklyuchaem-disk-iz-nas-v-linux-ili-montirovanie-raid-i-lvm-razdelov/
Всем нам знакомы и привычны аппаратные NAS, они используются дома и на работе для хранения самых различных данных. Но любое оборудование может выходить из строя, обычно неожиданно и перед администратором может встать задача копирования данных с дисков NAS.
На первый взгляд в ней нет ничего сложного: в основе прошивки Linux, а значит берем любую Linux систему, подключаем, монтируем, сливаем...
Однако не все так просто и для выполнения этой задачи могут потребоваться достаточно глубокие знания систем хранения Linux и навыков работы с ними.
Разбирать подобные ситуации лучше на примерах, тем более в нашем случае он как будто специально, достаточно показательный.
На днях к нам обратился коллега с просьбой помочь достать информацию с диска, вышедшего из строя NAS Synology DS216. На наш вопрос в чем там проблема он уклончиво ответил, что как-то все сложно и он боится сделать что-нибудь не так и испортить данные.
Ну что же, давайте разбираться. Итак, перед нами следующие вводные: есть диск из двухдискового NAS, работавшего с зеркальным RAID-массивом, в качестве файловой системы использовалась ext4.
✅ Читать далее: https://interface31.ru/post/podklyuchaem-disk-iz-nas-v-linux-ili-montirovanie-raid-i-lvm-razdelov/
👍9🔥3
Как изменить SID в Windows 10/11 и Server 2025
О проблеме дублирующихся SID мы писали в нашей прошлой заметке, сегодня расскажем о том, как изменить его без переустановки системы.
❗️Важно! Данный способ является неофициальным и потенциально может привести к нарушению работы системы и/или потере информации. Поэтому все действия вы производите исключительно на свой страх и риск!
Для работы мы будем использовать утилиту SIDCHG, которую следует скачать с официального сайта, там же расположен лицензионный ключ пробной версии, который представлен в качестве изображения и меняется каждый месяц, на октябрь 2026 года ключ такой:
После чего узнайте текущий SID машины, например, при помощи PsGetsid64 от Sysinternals.
‼️ Если система использует BitLocker (а Windows 11 использует его по умолчанию), то шифрование нужно отключить, а диски расшифровать.
Статус можно узнать командой:
Отключить:
Если дисков несколько – повторить для каждого, после чего следует дождаться процесса расшифровки и перезагрузить ПК.
‼️ Если вы используете EFS, то скопируйте зашифрованные файлы в другое место, а также не забудьте экспортировать сертификат с ключами.
Будьте готовы к тому, что некоторое программное обеспечение может потребовать повторной активации.
🔹 Затем отключите службу UCPD — это User Choice Protection Driver
Перезагрузитесь, иначе защита полноценно отключена не будет.
Выключите онлайн-защиту антивируса, включая Defender и запустите скачанную утилиту с ключом R:
Введите лицензионный ключ и подтвердите свои действия, утилита завершит сеанс, и вы окажетесь на экране блокировки. Не входите в систему до завершения ее работы, особенно это важно для сервера, где могут быть удаленные сеансы.
По завершении работы компьютер автоматически перезагрузится. После чего первым делом включаем обратно службу UCPD и снова перезагружаемся.
После чего убедитесь, что SID действительно изменился.
👉 В некоторых случаях могут начать нестабильно работать современные приложения и меню Пуск, в этом случае нужно выполнить сброс их настроек, для этого снова запустите утилиту:
Данная команда сбросит все современные приложения, либо, если хотите действовать точечно:
Где App_1 – имя современного приложения, можно перечислить несколько значений через запятую.
При соблюдении всех указанных подготовительных мер данный способ работает, но не нужно забывать, что он не является официальным и Microsoft такой сценарий не поддерживает. Поэтому обязательно делайте бекапы, а по возможности лучше переустановите систему.
О проблеме дублирующихся SID мы писали в нашей прошлой заметке, сегодня расскажем о том, как изменить его без переустановки системы.
❗️Важно! Данный способ является неофициальным и потенциально может привести к нарушению работы системы и/или потере информации. Поэтому все действия вы производите исключительно на свой страх и риск!
Для работы мы будем использовать утилиту SIDCHG, которую следует скачать с официального сайта, там же расположен лицензионный ключ пробной версии, который представлен в качестве изображения и меняется каждый месяц, на октябрь 2026 года ключ такой:
77JAY-XcFfv-2OiLw-2f
После чего узнайте текущий SID машины, например, при помощи PsGetsid64 от Sysinternals.
‼️ Если система использует BitLocker (а Windows 11 использует его по умолчанию), то шифрование нужно отключить, а диски расшифровать.
Статус можно узнать командой:
manage-bde -status C:
Отключить:
manage-bde -off C:
Если дисков несколько – повторить для каждого, после чего следует дождаться процесса расшифровки и перезагрузить ПК.
‼️ Если вы используете EFS, то скопируйте зашифрованные файлы в другое место, а также не забудьте экспортировать сертификат с ключами.
Будьте готовы к тому, что некоторое программное обеспечение может потребовать повторной активации.
🔹 Затем отключите службу UCPD — это User Choice Protection Driver
sc config UCPD start=disabled
schtasks.exe /change /Disable /TN "\Microsoft\Windows\AppxDeploymentClient\UCPD velocity"
Перезагрузитесь, иначе защита полноценно отключена не будет.
Выключите онлайн-защиту антивируса, включая Defender и запустите скачанную утилиту с ключом R:
SIDCHG64.exe /R
Введите лицензионный ключ и подтвердите свои действия, утилита завершит сеанс, и вы окажетесь на экране блокировки. Не входите в систему до завершения ее работы, особенно это важно для сервера, где могут быть удаленные сеансы.
По завершении работы компьютер автоматически перезагрузится. После чего первым делом включаем обратно службу UCPD и снова перезагружаемся.
schtasks.exe /change /Enable /TN "\Microsoft\Windows\AppxDeploymentClient\UCPD velocity"
sc config UCPD start=auto
После чего убедитесь, что SID действительно изменился.
👉 В некоторых случаях могут начать нестабильно работать современные приложения и меню Пуск, в этом случае нужно выполнить сброс их настроек, для этого снова запустите утилиту:
SIDCHG64.exe / RESETALLAPPS
Данная команда сбросит все современные приложения, либо, если хотите действовать точечно:
SIDCHG64.exe /RESETAPPS=App_1
Где App_1 – имя современного приложения, можно перечислить несколько значений через запятую.
При соблюдении всех указанных подготовительных мер данный способ работает, но не нужно забывать, что он не является официальным и Microsoft такой сценарий не поддерживает. Поэтому обязательно делайте бекапы, а по возможности лучше переустановите систему.
👍10🤔2🤮1
Режимы выделения виртуальной памяти в Linux
Еще один вопрос, который вызывает ряд неверных толкований и ошибок в применении – это режим выделения виртуальной памяти в Linux. А именно политика overcommitment – избыточного выделения памяти процессам, чем есть в системе на самом деле.
Постойте, но зачем выделять памяти больше, чем ее есть на самом деле? Может быть надо жить по средствам? Но не все так просто. Многие процессы запрашивают памяти больше, чем используют на самом деле.
Объем заметки не позволяет углубиться в суть происходящих процессов, поэтому допустим определенные упрощения. Во-первых, процесс может резервировать память «на всякий случай», во-вторых – в память могут отображаться разреженные структуры, например, файл 1 ГБ, у которого реально занято 250 МБ, остальное нули (виртуальный диск).
И, наконец, процессы могут использовать память совместно. Скажем если материнский процесс порождает потомка, то он тоже запрашивает выделение памяти как у материнского процесса, но на самом деле использует общую с ним память до тех пор, пока не изменит одну из страниц и только тогда измененная страница будет скопирована в выделенное пространство памяти процесса.
Таким образом выделение памяти процессу не означает ее обязательного использования. Реальное использование физической памяти начинается только после обращения к ней. При этом для процесса не делается разницы между оперативной памятью и подкачкой, и то и другое – физическая память.
Выделение памяти – это, по сути, обещание ядра такую память предоставить, а не ее жесткое резервирование. В результате может сложиться ситуация, что сразу несколько процессов потребуют предоставить зарезервированную память, но ее не окажется в наличии. В этом случае на сцену выходит OOM-killer и убивает самый «негодный» процесс.
Режим работы этого механизма можно задать при помощи опции
Которая может принимать одно из трех значений: 0, 1 и 2
🔹vm.overcommit_memory = 0 – значение по умолчанию, лимит выделения памяти рассчитывается ядром эвристически, с учетом реального ее использования. Такая стратегия позволяет наиболее эффективно использовать всю наличную память.
В таком режиме ядро обычно допускает умеренный overcommit на основе объема свободной памяти, swap и освобождаемого дискового кэша.
Из минусов мы имеем некоторую неопределенность. Один и тот же запрос на выделение памяти, может быть, как одобрен ядром, так и отклонен. Также имеется возможность неожиданного срабатывания OOM-killer.
Несмотря на это данный режим наилучшим образом подходит для рабочих станций и универсальных серверов с разноплановой нагрузкой.
🔹 vm.overcommit_memory = 1 – выделение памяти происходит всегда, все лимиты отключены. Очень специфический режим, который тем не менее может оказаться полезным для процессов активно использующих порождение потомков и общую память (веб-сервера).
Но включая данный режим нужно очень четко представлять, что вы делаете, так как очень высокий риск привести систему в нестабильное состояние из-за реального недостатка памяти, плюс крайне высок риск непредсказуемого срабатывания OOM-killer.
🔹 vm.overcommit_memory = 2 – жесткий лимит на выделение памяти, для этого режима используется еще одна опция:
Которая обозначает какой процент памяти используется для вычисления лимита, который производится по формуле:
По умолчанию vm.overcommit_ratio = 50 и поэтому если вы его не зададите явно, то лимит будет меньше имеющейся в наличии физической памяти.
Данный режим рекомендуется использовать вместе с приложениями, которые сами управляют выделением памяти, например, СУБД. В документации PostgreSQL такая настройка указана явно.
Причина здесь проста. В случае тяжелого запроса лучше получить явный отказ в выделении памяти и выдать пользователю ошибку «недостаточно памяти», нежели процесс СУБД окажется завершен OOM-killer и потребует аварийного перезапуска.
В ряде систем с высокими требованиями к стабильности рекомендуется уменьшить лимит выделения до 70-80%.
Еще один вопрос, который вызывает ряд неверных толкований и ошибок в применении – это режим выделения виртуальной памяти в Linux. А именно политика overcommitment – избыточного выделения памяти процессам, чем есть в системе на самом деле.
Постойте, но зачем выделять памяти больше, чем ее есть на самом деле? Может быть надо жить по средствам? Но не все так просто. Многие процессы запрашивают памяти больше, чем используют на самом деле.
Объем заметки не позволяет углубиться в суть происходящих процессов, поэтому допустим определенные упрощения. Во-первых, процесс может резервировать память «на всякий случай», во-вторых – в память могут отображаться разреженные структуры, например, файл 1 ГБ, у которого реально занято 250 МБ, остальное нули (виртуальный диск).
И, наконец, процессы могут использовать память совместно. Скажем если материнский процесс порождает потомка, то он тоже запрашивает выделение памяти как у материнского процесса, но на самом деле использует общую с ним память до тех пор, пока не изменит одну из страниц и только тогда измененная страница будет скопирована в выделенное пространство памяти процесса.
Таким образом выделение памяти процессу не означает ее обязательного использования. Реальное использование физической памяти начинается только после обращения к ней. При этом для процесса не делается разницы между оперативной памятью и подкачкой, и то и другое – физическая память.
Выделение памяти – это, по сути, обещание ядра такую память предоставить, а не ее жесткое резервирование. В результате может сложиться ситуация, что сразу несколько процессов потребуют предоставить зарезервированную память, но ее не окажется в наличии. В этом случае на сцену выходит OOM-killer и убивает самый «негодный» процесс.
Режим работы этого механизма можно задать при помощи опции
vm.overcommit_memory
Которая может принимать одно из трех значений: 0, 1 и 2
🔹vm.overcommit_memory = 0 – значение по умолчанию, лимит выделения памяти рассчитывается ядром эвристически, с учетом реального ее использования. Такая стратегия позволяет наиболее эффективно использовать всю наличную память.
В таком режиме ядро обычно допускает умеренный overcommit на основе объема свободной памяти, swap и освобождаемого дискового кэша.
Из минусов мы имеем некоторую неопределенность. Один и тот же запрос на выделение памяти, может быть, как одобрен ядром, так и отклонен. Также имеется возможность неожиданного срабатывания OOM-killer.
Несмотря на это данный режим наилучшим образом подходит для рабочих станций и универсальных серверов с разноплановой нагрузкой.
🔹 vm.overcommit_memory = 1 – выделение памяти происходит всегда, все лимиты отключены. Очень специфический режим, который тем не менее может оказаться полезным для процессов активно использующих порождение потомков и общую память (веб-сервера).
Но включая данный режим нужно очень четко представлять, что вы делаете, так как очень высокий риск привести систему в нестабильное состояние из-за реального недостатка памяти, плюс крайне высок риск непредсказуемого срабатывания OOM-killer.
🔹 vm.overcommit_memory = 2 – жесткий лимит на выделение памяти, для этого режима используется еще одна опция:
vm.overcommit_ratio = 100
Которая обозначает какой процент памяти используется для вычисления лимита, который производится по формуле:
CommitLimit = swap_total + (RAM_total × vm.overcommit_ratio / 100)
По умолчанию vm.overcommit_ratio = 50 и поэтому если вы его не зададите явно, то лимит будет меньше имеющейся в наличии физической памяти.
Данный режим рекомендуется использовать вместе с приложениями, которые сами управляют выделением памяти, например, СУБД. В документации PostgreSQL такая настройка указана явно.
Причина здесь проста. В случае тяжелого запроса лучше получить явный отказ в выделении памяти и выдать пользователю ошибку «недостаточно памяти», нежели процесс СУБД окажется завершен OOM-killer и потребует аварийного перезапуска.
В ряде систем с высокими требованиями к стабильности рекомендуется уменьшить лимит выделения до 70-80%.
👍8❤1
Как в Linux узнать скорость USB-портов и их текущий режим работы
Вопрос достаточно интересный и непраздный, очень часто нужно определить наиболее быстрый USB-порт устройства, чтобы, например, перекинуть большой объем данных.
Воткнуть в синий порт давно уже не вариант, так как разновидностей стандарта USB 3.x сегодня несколько и скорость работы там может существенно отличаться.
Первый приходящий на ум вариант – заглянуть в документацию, но это не всегда возможно, тем более документация не покажет нам реальный режим работы устройства.
Но в Linux указанную информацию получить не просто, а очень просто, достаточно выполнить команду:
Которая покажет номинальные скорости концентраторов и режимы работы подключенных к ним устройств.
Расшифровать значения также не сложно, они соответствуют значениям скорости в МБ/с, а именно:
▫️12М - USB 1.0
▫️480M – USB 2.0
▫️5000M - USB 3.2 Gen 1 (USB 3.0)
▫️10000M - USB 3.2 Gen 2 (USB 3.1)
▫️20000M/x2 - USB 3.2 Gen 2x2
Реальный вывод команды показан на скриншоте из которого четко видны режимы работы концентраторов и портов.
Вопрос достаточно интересный и непраздный, очень часто нужно определить наиболее быстрый USB-порт устройства, чтобы, например, перекинуть большой объем данных.
Воткнуть в синий порт давно уже не вариант, так как разновидностей стандарта USB 3.x сегодня несколько и скорость работы там может существенно отличаться.
Первый приходящий на ум вариант – заглянуть в документацию, но это не всегда возможно, тем более документация не покажет нам реальный режим работы устройства.
Но в Linux указанную информацию получить не просто, а очень просто, достаточно выполнить команду:
lsusb -t
Которая покажет номинальные скорости концентраторов и режимы работы подключенных к ним устройств.
Расшифровать значения также не сложно, они соответствуют значениям скорости в МБ/с, а именно:
▫️12М - USB 1.0
▫️480M – USB 2.0
▫️5000M - USB 3.2 Gen 1 (USB 3.0)
▫️10000M - USB 3.2 Gen 2 (USB 3.1)
▫️20000M/x2 - USB 3.2 Gen 2x2
Реальный вывод команды показан на скриншоте из которого четко видны режимы работы концентраторов и портов.
👍7🔥4