Авторское право – не пустой звук. Часть 2
Сегодня мы посмотрим на этот вопрос с другой стороны, потому что многие авторы и блогеры один раз столкнувшись с фототроллями начинают дуть на воду и бояться каждой тени.
Поэтому начнем с базы:
Т.е. для появления объекта авторского права нужен результат творческого труда некоторого гражданина. Уже исходя из этой нормы результат генерации нейросетей объектом авторского права не является и автора не имеет.
А вот это тот самый спасательный круг, который держит на плаву весь блогинг и журналистику, авторов обучающих материалов и т.д. и т.п. Но учтите – вы обязаны указать имя автора и ссылку на источник.
Что это значит? А это значит, что вы можете использовать чужое, защищенное авторским правом изображение в информационных целях абсолютно законно, но в объеме, оправданном целью цитирования.
Если говорить просто, то вы, в процессе написания обзора на мини-ПК вполне можете взять чужое фото, чтобы показать его внутри, потому что не хотите разбирать свой гарантийный экземпляр. Это как раз оправданный объем и понятная цель.
Но когда вы построите свой материал на чужом фото и добавите от себя два дежурных абзаца, то цитированием тут уже не пахнет, чужой объект стал ключевым элементом вашей публикации, а это нарушение.
А теперь пройдемся по самым частым случаям. Скриншоты интерфейса программ. Несмотря на то, что сами программы – объект авторского права их интерфейс таковым не является (исключая шрифты, иконки и т.п.), иначе авторы того же MS Office давно бы засудили альтернативные пакеты, которые повторяют интерфейс практически один в один.
Поэтому скриншоты можно публиковать смело, никто никаких претензий вам не предъявит. Исключение – чужой обработанный скриншот, на который нанесены надписи, стрелочки, рамочки – это уже результат чужого творческого труда и использовать его вы можете только в части цитирования.
Изображения комплектующих и готовых устройств. Здесь ситуация еще тоньше. Многие юристы вполне обоснованно считают, что если у нас есть вид устройства с некоторого стандартного ракурса (спереди, сзади, сверху, вид на разъемы), то результатом творческого труда это изображение не является.
Эта позиция находит поддержку в судах, но мы не будем лишний раз дергать тигра за усы, а снова возьмем 1274 ГК РФ. Если вы пишете статью об устройстве или в тексте используете это устройство как пример, то будет абсолютно правомерно привести тут его изображение.
Чужие логотипы и прочие элементы брендирования. Самая сложная тема, так как она учитывает множество факторов, в частности коммерческое применение. Так в условиях партнерских программ многие бренды прямо запрещают использование официальной символики.
Но это касается именно коммерческой деятельности. В информационных, научных или учебных целях вы полностью в праве использовать чужие логотипы и элементы корпоративного стиля, тем более что практически все производители публикуют брендбуки и на этом настаивают.
Если вы пишете статью про Ubuntu или RHEL, то абсолютно логично проиллюстрировать ее официальным логотипом. Это нормально и не является нарушением. Но если вы разместите в этой статье некоторые партнерские ссылки, ситуация может тут же развернуться на 180 градусов.
Объем заметки не позволяет разобрать все ситуации, поэтому к этой теме мы еще вернемся.
Сегодня мы посмотрим на этот вопрос с другой стороны, потому что многие авторы и блогеры один раз столкнувшись с фототроллями начинают дуть на воду и бояться каждой тени.
Поэтому начнем с базы:
Статья 1257. Автор произведения
Автором произведения науки, литературы или искусства признается гражданин, творческим трудом которого оно создано.
Т.е. для появления объекта авторского права нужен результат творческого труда некоторого гражданина. Уже исходя из этой нормы результат генерации нейросетей объектом авторского права не является и автора не имеет.
Статья 1274. Свободное использование произведения в информационных, научных, учебных или культурных целях
1. Допускается без согласия автора или иного правообладателя и без выплаты вознаграждения, но с обязательным указанием имени автора, произведение которого используется, и источника заимствования:
1) цитирование в оригинале и в переводе в научных, полемических, критических, информационных, учебных целях, в целях раскрытия творческого замысла автора правомерно обнародованных произведений в объеме, оправданном целью цитирования…
А вот это тот самый спасательный круг, который держит на плаву весь блогинг и журналистику, авторов обучающих материалов и т.д. и т.п. Но учтите – вы обязаны указать имя автора и ссылку на источник.
Что это значит? А это значит, что вы можете использовать чужое, защищенное авторским правом изображение в информационных целях абсолютно законно, но в объеме, оправданном целью цитирования.
Если говорить просто, то вы, в процессе написания обзора на мини-ПК вполне можете взять чужое фото, чтобы показать его внутри, потому что не хотите разбирать свой гарантийный экземпляр. Это как раз оправданный объем и понятная цель.
Но когда вы построите свой материал на чужом фото и добавите от себя два дежурных абзаца, то цитированием тут уже не пахнет, чужой объект стал ключевым элементом вашей публикации, а это нарушение.
А теперь пройдемся по самым частым случаям. Скриншоты интерфейса программ. Несмотря на то, что сами программы – объект авторского права их интерфейс таковым не является (исключая шрифты, иконки и т.п.), иначе авторы того же MS Office давно бы засудили альтернативные пакеты, которые повторяют интерфейс практически один в один.
Поэтому скриншоты можно публиковать смело, никто никаких претензий вам не предъявит. Исключение – чужой обработанный скриншот, на который нанесены надписи, стрелочки, рамочки – это уже результат чужого творческого труда и использовать его вы можете только в части цитирования.
Изображения комплектующих и готовых устройств. Здесь ситуация еще тоньше. Многие юристы вполне обоснованно считают, что если у нас есть вид устройства с некоторого стандартного ракурса (спереди, сзади, сверху, вид на разъемы), то результатом творческого труда это изображение не является.
Эта позиция находит поддержку в судах, но мы не будем лишний раз дергать тигра за усы, а снова возьмем 1274 ГК РФ. Если вы пишете статью об устройстве или в тексте используете это устройство как пример, то будет абсолютно правомерно привести тут его изображение.
Чужие логотипы и прочие элементы брендирования. Самая сложная тема, так как она учитывает множество факторов, в частности коммерческое применение. Так в условиях партнерских программ многие бренды прямо запрещают использование официальной символики.
Но это касается именно коммерческой деятельности. В информационных, научных или учебных целях вы полностью в праве использовать чужие логотипы и элементы корпоративного стиля, тем более что практически все производители публикуют брендбуки и на этом настаивают.
Если вы пишете статью про Ubuntu или RHEL, то абсолютно логично проиллюстрировать ее официальным логотипом. Это нормально и не является нарушением. Но если вы разместите в этой статье некоторые партнерские ссылки, ситуация может тут же развернуться на 180 градусов.
Объем заметки не позволяет разобрать все ситуации, поэтому к этой теме мы еще вернемся.
👍8🥱5
Как получить полный дистрибутив конфигурации 1С:Предприятие
Многие коллеги активно пользуются Порталом 1C:Обновление программ для получения обновлений. Но когда требуется скачать полный дистрибутив начинаются определенные сложности.
Обычно в этом случае рекомендуют обратиться к обслуживающему франчайзи, некоторые начинают искать дистрибутивы в широко известных «злачных местах», но на самом деле все гораздо проще.
Достаточно просто скопировать ссылку на дистрибутив обновления и в самом ее конце заменить:
На
B результате вы получите ссылку на скачивание полного дистрибутива и это не какой-нибудь лайфхак, а штатная, документированная возможность.
Для подтверждения скачивания вам потребуется дополнительная аутентификация с помощью одноразового пароля, который будет выслан на номер телефона указанный в профиле.
Многие коллеги активно пользуются Порталом 1C:Обновление программ для получения обновлений. Но когда требуется скачать полный дистрибутив начинаются определенные сложности.
Обычно в этом случае рекомендуют обратиться к обслуживающему франчайзи, некоторые начинают искать дистрибутивы в широко известных «злачных местах», но на самом деле все гораздо проще.
Достаточно просто скопировать ссылку на дистрибутив обновления и в самом ее конце заменить:
_updsetup.zip
На
_setup1c.zip
B результате вы получите ссылку на скачивание полного дистрибутива и это не какой-нибудь лайфхак, а штатная, документированная возможность.
Для подтверждения скачивания вам потребуется дополнительная аутентификация с помощью одноразового пароля, который будет выслан на номер телефона указанный в профиле.
🔥21👍7
Авторское право – не пустой звук. Часть 3
В прошлой части мы разобрали, какие объекты авторского права можно использовать и на каких основаниях, но остались некоторые тонкости, которые мы сегодня рассмотрим.
Статья 1274 ГК РФ прямо говорит, что допустимо использование:
А где и как искать этот объем? Начнем с цели. Какая цель вашего произведения? Именно от этого будет исходить объем. Допустим, вы описываете некоторую материнскую плату – тогда для достижения поставленной цели вы правомерно можете использовать общий вид, фото со стороны разъёмов и т.д.
Но если вы пишете общую статью, скажем об оперативной памяти и поставили на КДПВ (картинка для привлечения внимания) какую-нибудь художественную фотографию с планкой ОЗУ, где не только сама планка, но еще и сюжет, фон, модель – это однозначно нарушение.
А вообще общий принцип прост – если данный объект авторского права можно исключить из вашего произведения, и оно не пострадает – то его нужно исключить, так как его применение не оправдано поставленной целью.
Потому что когда у вас в тексте «посмотрим на скриншот и увидим» или «вот фото устройства в разобранном виде, обратите внимание», то изображения становятся неотъемлемой частью произведения, если их убрать, то станет непонятно, о чем идет речь.
С целью поняли, а что с объемами? Тут тоже следует исходить из того, то заимствованный материал не должен составлять основную часть вашего произведения. В журналистской и редакторской среде действует эмпирическое правило 30%.
Т.е. вы не должны заимствовать более 30% исходного произведения и общий процент заимствований в вашем произведении не должен превышать 30%.
Но это общее эмпирическое правило, в реальности объем всегда зависит от поставленной цели. Скажем, вы пишете статью про историю вычислительной техники. Тематика не позволяет вам самостоятельно создать иллюстрации и поэтому заимствование чужих изображений в полном объеме оправданно заявленной целью.
Следующий момент, демонстрация чужих объектов авторского права на скриншотах, например, обоев рабочего стола. Тема тоже очень скользкая, которая в итоге сводится к правомерности воспроизведения объекта в определенном окружении.
Скажем, в дистрибутиве Simply Linux от Альт есть отличные авторские обои. Показывать их на скриншотах дистрибутива полностью допустимо, правообладатель сам разрешил их использование в составе ОС, а вы показываете внешний вид ОС.
Но стоит вам выложить этот файл изображения отдельно – вы нарушили чужое право, автор не разрешал использовать это изображение отдельно от дистрибутива.
Или, скажем, вы использовали известное изображение Bliss (Безмятежность) из Windows XP как фон рабочего стола Linux и наделали там скриншотов. Поздравляем, вы только что грубо нарушили авторское право.
Статья 1273 ГК РФ разрешает свободное воспроизведение произведения в личных целях, т.е. вы имеете полное право поставить такое изображение на рабочий стол вашей Linux-системы. Но вот публично демонстрировать вы его права не имеете.
Это же касается любых изображений, защищенных авторским правом, поставить на рабочий стол можно, публично демонстрировать нельзя. Поэтому если вы снимаете скриншоты какой-либо системы, то поставьте туда стандартные обои.
Ну и не забывайте, что даже свободно распространяемые изображения имеют своего автора и лицензию, с которыми бывает полезно ознакомиться.
Потому что свободно не означает бесплатно и на такое использование могут быть наложены некоторые ограничения.
В прошлой части мы разобрали, какие объекты авторского права можно использовать и на каких основаниях, но остались некоторые тонкости, которые мы сегодня рассмотрим.
Статья 1274 ГК РФ прямо говорит, что допустимо использование:
правомерно обнародованных произведений и отрывков из них в качестве иллюстраций … в объеме, оправданном поставленной целью
А где и как искать этот объем? Начнем с цели. Какая цель вашего произведения? Именно от этого будет исходить объем. Допустим, вы описываете некоторую материнскую плату – тогда для достижения поставленной цели вы правомерно можете использовать общий вид, фото со стороны разъёмов и т.д.
Но если вы пишете общую статью, скажем об оперативной памяти и поставили на КДПВ (картинка для привлечения внимания) какую-нибудь художественную фотографию с планкой ОЗУ, где не только сама планка, но еще и сюжет, фон, модель – это однозначно нарушение.
А вообще общий принцип прост – если данный объект авторского права можно исключить из вашего произведения, и оно не пострадает – то его нужно исключить, так как его применение не оправдано поставленной целью.
Потому что когда у вас в тексте «посмотрим на скриншот и увидим» или «вот фото устройства в разобранном виде, обратите внимание», то изображения становятся неотъемлемой частью произведения, если их убрать, то станет непонятно, о чем идет речь.
С целью поняли, а что с объемами? Тут тоже следует исходить из того, то заимствованный материал не должен составлять основную часть вашего произведения. В журналистской и редакторской среде действует эмпирическое правило 30%.
Т.е. вы не должны заимствовать более 30% исходного произведения и общий процент заимствований в вашем произведении не должен превышать 30%.
Но это общее эмпирическое правило, в реальности объем всегда зависит от поставленной цели. Скажем, вы пишете статью про историю вычислительной техники. Тематика не позволяет вам самостоятельно создать иллюстрации и поэтому заимствование чужих изображений в полном объеме оправданно заявленной целью.
Следующий момент, демонстрация чужих объектов авторского права на скриншотах, например, обоев рабочего стола. Тема тоже очень скользкая, которая в итоге сводится к правомерности воспроизведения объекта в определенном окружении.
Скажем, в дистрибутиве Simply Linux от Альт есть отличные авторские обои. Показывать их на скриншотах дистрибутива полностью допустимо, правообладатель сам разрешил их использование в составе ОС, а вы показываете внешний вид ОС.
Но стоит вам выложить этот файл изображения отдельно – вы нарушили чужое право, автор не разрешал использовать это изображение отдельно от дистрибутива.
Или, скажем, вы использовали известное изображение Bliss (Безмятежность) из Windows XP как фон рабочего стола Linux и наделали там скриншотов. Поздравляем, вы только что грубо нарушили авторское право.
Статья 1273 ГК РФ разрешает свободное воспроизведение произведения в личных целях, т.е. вы имеете полное право поставить такое изображение на рабочий стол вашей Linux-системы. Но вот публично демонстрировать вы его права не имеете.
Это же касается любых изображений, защищенных авторским правом, поставить на рабочий стол можно, публично демонстрировать нельзя. Поэтому если вы снимаете скриншоты какой-либо системы, то поставьте туда стандартные обои.
Ну и не забывайте, что даже свободно распространяемые изображения имеют своего автора и лицензию, с которыми бывает полезно ознакомиться.
Потому что свободно не означает бесплатно и на такое использование могут быть наложены некоторые ограничения.
👍6👌1🥱1
Тонкая настройка 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 сообщений. Обратите внимание, что данный лимит действует для каждого источника событий, а не для всей системы.
В высоконагруженных системах лимит можно повысить, например, для гипервизоров, где виртуалки при старте могут быть достаточно «разговорчивы». В виртуальных средах, наоборот, имеет смысл понизить этот лимит, чтобы избежать массового спама логов сбойным сервисом.
👍9🔥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 году канадским педагогом и психологом Лоуренсом Дж. Питером, у нас он известен как часть Законов Мерфи.
Принцип Питера гласит:
В иерархии каждый сотрудник имеет тенденцию подниматься до своего уровня некомпетентности.
Следствия принципа Питера:
🔸С течением времени каждая должность будет занята сотрудником, который некомпетентен в выполнении своих обязанностей.
🔸Работа выполняется теми работниками, которые ещё не достигли своего уровня некомпетентности.
Многие считают это всего лишь шуткой, но на самом деле подобные тенденции имеют место быть и гораздо шире, нежели этого бы хотелось.
Причина в современной корпоративной культуре, не важно – нашей или западной – вся она завязана на некоторую «эффективность» сотрудника, которая является одним из проявлений «успешного успеха».
«Эффективный» сотрудник просто не может сказать – я не готов к повышению, я что-то не знаю и не умею, мне нужно подучиться. Потому что в этом случае он остановился, когда другие продолжают бежать вперед, он теперь просто неудачник.
При этом реальной компетентности на новой должности уже не хватает. Но если можно заменить работу красивыми отчетами и плавно делегировать ее вниз – то проблемы нет.
А показав «успехи» и на этой должности можно и дальше пробиваться вверх по карьерной лестнице, до тех пор, пока выше вы не сможете вообще ничего, даже писать красивые отчеты.
В этой точке сотрудник поднялся до своего уровня некомпетентности и занял соответствующую ей должность.
Тут может быть смешно, но часто именно так оно и происходит. Потому что руководителю не обязательно знать современные технологии, языки программирования и вообще разбираться в предмете. Ведь у него есть опыт, он лоялен фирме и т.д. и т.п.
В результате должность занимает абсолютно некомпетентный человек, который хорошо, если просто не мешает остальным работать, а не тормозит развитие на своем уровне представления о прекрасном.
И хорошо, если на этом все заканчивается, практика показывает, что нет, особенно явно это проявляется в госах. Осознавая собственный уровень некомпетентности, такой руководитель никогда не будет повышать компетентных сотрудников.
Почему? Потому что они будут представлять непосредственную угрозу его должности, потому что их потолок некомпетентности выше и могут еще расти, а он уже нет. А место теплое и хлебное, рынок труда для него – это какой-то восточный базар в арабской стране: прикольно, интересно, но абсолютно ничего не понятно, что они там лопочут.
И на нижестоящие должности также ставятся некомпетентные сотрудники, зато лояльные и безопасные, обладающие ценными навыками рисовать красивые отчеты и не менее красиво наводить тень на плетень.
Вы думаете им нужны толковые заместители? Вовсе нет. Ну вы поняли. Система самоцементируется сверху вниз, заполняя все уровни некомпетентными сотрудниками.
Погодите, а кто же будет работать? Если это гос, то возможно даже никто, гос не обанкротится, его финансирует бюджет, а все остальное они нарисуют. И такое, к сожалению, имеет место быть, когда элементарные вопросы решаются с огромным скрипом и очень долго.
Если же работать все-таки надо, то работают линейные сотрудники, тоже невысокой компетенции, чтобы даже не думали прыгать выше головы, потому что прыгать в такой системе некуда.
Получаем типичную «потогонку» или «галеру» и пока такой бизнес приносит средства для кормления всей этой руководящей пирамиды – никто ничего менять не будет.
А сегодня для принципа Питера открылось второе дыхание – нейросети, которые помогают поддерживать и даже повышать свой уровень некомпетентности, причем на всех уровнях.
Что с этим делать? Ничего, принимать как данное, ибо нейросеть просто инструмент, а поведение человека складывалось веками. Но умение распознавать подобные организации и стараться обходить их стороной – навык полезный.
🔥16👍11🤷♂5😁1
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 лет» поддержки.
👍10❤3🥱2
Про помогаторов
На фоне последних событий рассмотрим еще один феномен – помогаторство.
Суть его сводится к тому, что коллеги начинают ошибочно путать процесс зарабатывания денег с помощью клиенту, даже если он об этом не просил и денег за это не предлагал.
В чем это проявляется? Обычно берут подряд на один вид работ, но в процессе всплывают некоторые сложности и вместо того, чтобы озадачить этим клиента, они начинают решать вопрос самостоятельно, либо пытаются решить задачу наличными средствами.
Например, аппаратные средства заказчика явно не соответствуют решаемой задаче. Правильно – это сделать стоп и довести до заказчика реальные требования. А не соглашаться «ну сделать пока как-то так, а там решим».
Потому что ничего «там» не решат, а будут тянуть полудохлую систему до последнего, постоянно прося вас «что-то» сделать. И если вначале просить будут вежливо и даже давать денег, то потом начнут просто требовать и возмущаться, потому как мы тебе столько денег заплатили, а ты нормально ничего сделать не можешь.
А попытка таки вернуть ситуацию на стартовую позицию с покупкой адекватного железа обернется тем «а почему ты мне сразу не сказал» и вряд ли вы снова что-то нормально заработаете. Плюс вам заказчик будет постоянно внушать чувство вины за ваш прошлый «прокол».
Следует понимать, что у вас свой бизнес, у него свой и каждый из вас преследует цель заработать денег, а не взять на себя проблемы и головняки контрагента.
Ему нужно работать? Ну так пусть покупает адекватное железо или ищет неадекватного исполнителя, которому потом будет выносить мозги тем, как у него всё плохо, и это все потому, что исполнитель не может ничего нормально наладить.
Еще раз – это его бизнес и его проблемы. А не ваши. Ваша проблема – заработать указанную сумму денег без лишних проблем и заморочек. Пытаясь решить проблему заказчика подобным образом, вы только перекладываете чужие проблемы на себя.
При этом проблема никуда не денется, ее придется решать, только уже не заказчику, а вам. Так как голова начнет болеть не у него, а у вас. Потому что это вы ему пообещали сделать хоть как-нибудь, и он с вас будет требовать обещанное.
А то, что обещанное не решается наличными средствами, так заказчику это неведомо, он и знать ничего такого не обязан, но как рачительный собственник он, конечно же, попытался у вас узнать, можно ли как-то пока поработать так, вы сказали можно.
Вторая крайность - это создание для заказчика дополнительных сервисов и услуг, которые он не заказывал. Тот же мониторинг, резервные копии и т.д. и т.п.
Возможно, это связано с профдеформацией при работе в крупных организациях, где специалист знает, что при сбоях с него в первую очередь спросят про то, где был мониторинг и откуда взять резервные копии.
Здесь все гораздо проще. Доступно объясняете заказчику, на понятном ему языке, что может произойти и какие варианты вы предлагаете на этот случай. Отказывается – объясняем еще раз. Предельно понятно. Вот это сервер, он сгорел, нафиг, совсем, ничего нет. Что делать будешь?
Снова отказывается? Ну это его проблемы. Спокойно уходим, а если он таки прибегает с такой проблемой, то разводим руками и говорим, что мы его предупреждали. И никаких угрызений совести тут быть не должно. Это его бизнес, его риски. Вы сделали ровно то, что вас просили, остальное не ваши проблемы.
И здесь мы плавно подходим к тому, что нужно уметь твердо, но корректно говорить заказчику нет, когда он пытается попутно нагрузить вас другой проблемой. Следует пояснить, что выполнили вы один объем работ, то, что он хочет – это другое, это другой объем услуг и другая оплата.
Хороший пример был в комментариях, мол вы настроили нам обмен, а теперь у нас не идут остатки. Тут все просто, обмен – это обмен. Работает? Ну прекрасно, вот акт, вот счет.
Надо что-то решать с остатками? Это другая услуга, стоить будет примерно столько. Устраивает? Работаем.
Иначе вы так и останетесь помогатором, который будет тратить собственное время и решать при этом чужие проблемы за собственный счет.
На фоне последних событий рассмотрим еще один феномен – помогаторство.
Суть его сводится к тому, что коллеги начинают ошибочно путать процесс зарабатывания денег с помощью клиенту, даже если он об этом не просил и денег за это не предлагал.
В чем это проявляется? Обычно берут подряд на один вид работ, но в процессе всплывают некоторые сложности и вместо того, чтобы озадачить этим клиента, они начинают решать вопрос самостоятельно, либо пытаются решить задачу наличными средствами.
Например, аппаратные средства заказчика явно не соответствуют решаемой задаче. Правильно – это сделать стоп и довести до заказчика реальные требования. А не соглашаться «ну сделать пока как-то так, а там решим».
Потому что ничего «там» не решат, а будут тянуть полудохлую систему до последнего, постоянно прося вас «что-то» сделать. И если вначале просить будут вежливо и даже давать денег, то потом начнут просто требовать и возмущаться, потому как мы тебе столько денег заплатили, а ты нормально ничего сделать не можешь.
А попытка таки вернуть ситуацию на стартовую позицию с покупкой адекватного железа обернется тем «а почему ты мне сразу не сказал» и вряд ли вы снова что-то нормально заработаете. Плюс вам заказчик будет постоянно внушать чувство вины за ваш прошлый «прокол».
Следует понимать, что у вас свой бизнес, у него свой и каждый из вас преследует цель заработать денег, а не взять на себя проблемы и головняки контрагента.
Ему нужно работать? Ну так пусть покупает адекватное железо или ищет неадекватного исполнителя, которому потом будет выносить мозги тем, как у него всё плохо, и это все потому, что исполнитель не может ничего нормально наладить.
Еще раз – это его бизнес и его проблемы. А не ваши. Ваша проблема – заработать указанную сумму денег без лишних проблем и заморочек. Пытаясь решить проблему заказчика подобным образом, вы только перекладываете чужие проблемы на себя.
При этом проблема никуда не денется, ее придется решать, только уже не заказчику, а вам. Так как голова начнет болеть не у него, а у вас. Потому что это вы ему пообещали сделать хоть как-нибудь, и он с вас будет требовать обещанное.
А то, что обещанное не решается наличными средствами, так заказчику это неведомо, он и знать ничего такого не обязан, но как рачительный собственник он, конечно же, попытался у вас узнать, можно ли как-то пока поработать так, вы сказали можно.
Вторая крайность - это создание для заказчика дополнительных сервисов и услуг, которые он не заказывал. Тот же мониторинг, резервные копии и т.д. и т.п.
Возможно, это связано с профдеформацией при работе в крупных организациях, где специалист знает, что при сбоях с него в первую очередь спросят про то, где был мониторинг и откуда взять резервные копии.
Здесь все гораздо проще. Доступно объясняете заказчику, на понятном ему языке, что может произойти и какие варианты вы предлагаете на этот случай. Отказывается – объясняем еще раз. Предельно понятно. Вот это сервер, он сгорел, нафиг, совсем, ничего нет. Что делать будешь?
Снова отказывается? Ну это его проблемы. Спокойно уходим, а если он таки прибегает с такой проблемой, то разводим руками и говорим, что мы его предупреждали. И никаких угрызений совести тут быть не должно. Это его бизнес, его риски. Вы сделали ровно то, что вас просили, остальное не ваши проблемы.
И здесь мы плавно подходим к тому, что нужно уметь твердо, но корректно говорить заказчику нет, когда он пытается попутно нагрузить вас другой проблемой. Следует пояснить, что выполнили вы один объем работ, то, что он хочет – это другое, это другой объем услуг и другая оплата.
Хороший пример был в комментариях, мол вы настроили нам обмен, а теперь у нас не идут остатки. Тут все просто, обмен – это обмен. Работает? Ну прекрасно, вот акт, вот счет.
Надо что-то решать с остатками? Это другая услуга, стоить будет примерно столько. Устраивает? Работаем.
Иначе вы так и останетесь помогатором, который будет тратить собственное время и решать при этом чужие проблемы за собственный счет.
👍37💯16🥱3
AI меняет IT. Но какие технологии действительно заслуживают внимания?
Новые модели, AI-агенты и инструменты автоматизации появляются ежедневно. Важно не просто следить за новостями, а понимать их реальную ценность.
⚡ AI News Engine — технологическое медиа, где мы отбираем значимые события и объясняем, что изменится, почему это важно и где можно применить новые технологии.
Без информационного шума. Только факты, контекст и практическая польза.
AI News Engine — меньше шума, больше смысла.
Новые модели, AI-агенты и инструменты автоматизации появляются ежедневно. Важно не просто следить за новостями, а понимать их реальную ценность.
⚡ AI News Engine — технологическое медиа, где мы отбираем значимые события и объясняем, что изменится, почему это важно и где можно применить новые технологии.
Без информационного шума. Только факты, контекст и практическая польза.
AI News Engine — меньше шума, больше смысла.
👍3🔥2🤮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 не будет спамить вас десятком сообщений о недоступности каждого сервиса в отдельности, а просто скажет, что узел такой-то не в сети.
Но первичны у нас именно сервисы, помните об этом!
👍7❤1
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.
👍5🔥4❤2🤯1