Какими мини-апами в tg вы пользуетесь?
Вот какой удобный Mini App появился недавно: Calendar for Telegram
Это:
💫 Быстрый доступ к расписанию, которое теперь всегда под рукой;
💫 Лёгкий шэринг событий – без e-mail! Просто отправьте приглашение другу/коллеге в чат или сразу добавьте в событие людей по их Telegram-имени или нику;
💫 Афиши – общее расписания для работы, мероприятий, совместных путешествий или спорта;
💫 Слоты – отражают доступность вашего свободного времени для назначения встреч (это как Calendly, только в вашем tCalendar);
💫 Моментальный видео-звонок – возможность создавать Google Meet сразу в tCalendar;
💫 Синхронизация с Google Календарем – все события всегда актуальны в обоих календарях;
⭐️ Ai-функции – можно назначать встречи просто отправив сообщение боту календаря с данными по предстоящему мероприятию — и всё! Событие само появится в расписании.
Самое приятное, что всё это бесплатно и незаменимо в обычной жизни👌
Юзкейс такой: поняли, что нужна встреча -> создали её тут же в тг -> пригласили участников. В Гугл календарь само придет. 🪄✨
erid: 2W5zFJBpTpU
Вот какой удобный Mini App появился недавно: Calendar for Telegram
Это:
💫 Быстрый доступ к расписанию, которое теперь всегда под рукой;
💫 Лёгкий шэринг событий – без e-mail! Просто отправьте приглашение другу/коллеге в чат или сразу добавьте в событие людей по их Telegram-имени или нику;
💫 Афиши – общее расписания для работы, мероприятий, совместных путешествий или спорта;
💫 Слоты – отражают доступность вашего свободного времени для назначения встреч (это как Calendly, только в вашем tCalendar);
💫 Моментальный видео-звонок – возможность создавать Google Meet сразу в tCalendar;
💫 Синхронизация с Google Календарем – все события всегда актуальны в обоих календарях;
⭐️ Ai-функции – можно назначать встречи просто отправив сообщение боту календаря с данными по предстоящему мероприятию — и всё! Событие само появится в расписании.
Самое приятное, что всё это бесплатно и незаменимо в обычной жизни👌
Юзкейс такой: поняли, что нужна встреча -> создали её тут же в тг -> пригласили участников. В Гугл календарь само придет. 🪄✨
erid: 2W5zFJBpTpU
👍1
Деградация данных
Деградация данных (bitrot, битовое гниение) – это достаточно актуальный в настоящее время тип разрушения цифровых данных вследствие накопления некритичных ошибок на запоминающем устройстве.
К сожалению, многие коллеги путают деградацию с выходом из строя ячеек накопителя (бед-блоки) и не придают этому вопросу серьезного значения. А зря.
С бед-блоками достаточно эффективно позволяет справляться RAID, когда в случае ошибки чтения блок заменяется резервным, а его содержимое считывается с исправной копии. Да, возможен эффект появления скрытых бед-блоков, но он решается периодическом перечитыванием содержимого массива.
Проблема битового гниения лежит глубже и именно этот термин представляется нам наиболее удачным. Как и обычное гниение он медленно и незаметно повреждает данные до тех пор, пока разрушения не перейдут в критическую фазу.
Причинами битового гниения становятся ошибки в процессе записи, не связанные с повреждением непосредственно ячеек, они могут даже произойти в оперативной памяти и при отсутствии ECC ваши данные также могут быть незаметно повреждены.
Чаще всего деградация данных происходит при длительном хранении, вследствие деградации заряда ячейки или уровня намагниченности сектора. Ошибок чтения с накопителя это не вызывает, но приводит к нарушению целостности данных.
Как правило большинство современных форматов данных имеют избыточность и изменение одного бита может быть откорректировано встроенными средствами, но для этого эти данные нужно хотя бы открыть.
В противном случае подобные ошибки могут накапливаться и в определенный момент привести к невосстановимому повреждению данных. При этом процесс битового гниения не сопровождается ошибками чтения с накопителя и может происходить на полностью исправном диске.
А так как нет никаких ошибок, то и RAID вам ничем не поможет, особенно уровни без четности. Так, например, в случае зеркала у нас могут оказаться изменены биты в произвольных местах обоих копий. И чем больше по размеру файл и реже обращения к нему – тем вероятнее такое развитие событий.
Некоторую защиту могут предоставлять массивы с четностью (RAID 5 и 6), но здесь многое зависит от контроллера или программной реализации, главное у которых – уметь производить такую проверку в фоновом режиме.
В таком случае имея одну правильную копию и целые данные четности массив может проверить целостность данных и автоматически восстановить их.
Но оптимальным решением проблемы будет вынос таких проверок на уровень файловой системы, так как это позволяет действовать наиболее эффективно и с наименьшей нагрузкой на систему.
Современные системы с контролем целостности – это ZFS, btrfs и ReFS – и именно они рекомендуются для систем хранения больших объемов информации. Каждая из них умеет в фоновом режиме проверять целостность файлов и восстанавливать поврежденные фрагменты используя контрольные суммы (при наличии избыточности, разумеется).
И именно по этой причине тот же Proxmox категорически не рекомендует использование mdadm для хранилищ виртуальных машин в производственных средах.
Деградация данных (bitrot, битовое гниение) – это достаточно актуальный в настоящее время тип разрушения цифровых данных вследствие накопления некритичных ошибок на запоминающем устройстве.
К сожалению, многие коллеги путают деградацию с выходом из строя ячеек накопителя (бед-блоки) и не придают этому вопросу серьезного значения. А зря.
С бед-блоками достаточно эффективно позволяет справляться RAID, когда в случае ошибки чтения блок заменяется резервным, а его содержимое считывается с исправной копии. Да, возможен эффект появления скрытых бед-блоков, но он решается периодическом перечитыванием содержимого массива.
Проблема битового гниения лежит глубже и именно этот термин представляется нам наиболее удачным. Как и обычное гниение он медленно и незаметно повреждает данные до тех пор, пока разрушения не перейдут в критическую фазу.
Причинами битового гниения становятся ошибки в процессе записи, не связанные с повреждением непосредственно ячеек, они могут даже произойти в оперативной памяти и при отсутствии ECC ваши данные также могут быть незаметно повреждены.
Чаще всего деградация данных происходит при длительном хранении, вследствие деградации заряда ячейки или уровня намагниченности сектора. Ошибок чтения с накопителя это не вызывает, но приводит к нарушению целостности данных.
Как правило большинство современных форматов данных имеют избыточность и изменение одного бита может быть откорректировано встроенными средствами, но для этого эти данные нужно хотя бы открыть.
В противном случае подобные ошибки могут накапливаться и в определенный момент привести к невосстановимому повреждению данных. При этом процесс битового гниения не сопровождается ошибками чтения с накопителя и может происходить на полностью исправном диске.
А так как нет никаких ошибок, то и RAID вам ничем не поможет, особенно уровни без четности. Так, например, в случае зеркала у нас могут оказаться изменены биты в произвольных местах обоих копий. И чем больше по размеру файл и реже обращения к нему – тем вероятнее такое развитие событий.
Некоторую защиту могут предоставлять массивы с четностью (RAID 5 и 6), но здесь многое зависит от контроллера или программной реализации, главное у которых – уметь производить такую проверку в фоновом режиме.
В таком случае имея одну правильную копию и целые данные четности массив может проверить целостность данных и автоматически восстановить их.
Но оптимальным решением проблемы будет вынос таких проверок на уровень файловой системы, так как это позволяет действовать наиболее эффективно и с наименьшей нагрузкой на систему.
Современные системы с контролем целостности – это ZFS, btrfs и ReFS – и именно они рекомендуются для систем хранения больших объемов информации. Каждая из них умеет в фоновом режиме проверять целостность файлов и восстанавливать поврежденные фрагменты используя контрольные суммы (при наличии избыточности, разумеется).
И именно по этой причине тот же Proxmox категорически не рекомендует использование mdadm для хранилищ виртуальных машин в производственных средах.
👍47❤5
Спрашивают – отвечаем
Вопрос вот в чем: есть энтерпрайз SSD за очень много денег, там все ок. А как быть бедным, кто ставит nvme в лучшем случае из топа потребительских? Что выбрать, на что смотреть?
Начнем с того, что выбрать можно все что угодно, даже не из топа, все зависит от доступного бюджета. Но перед выбором нужно внимательно посмотреть.
Начнем с того, что пишут в спецификациях. А именно с ресурса. Это основной показатель, от которого зависит как часто вы будете менять диски. Соизмеряем его с текущей нагрузкой и прикидываем затраты. Может оказаться так, что взять более дорогой диск будет выгоднее.
А может произойти ровно наоборот. Иногда выгоднее чаще менять дешевые диски, чем дорогие, но реже.
При этом следует понимать, что никакой серебряной пули в потребительском сегменте нет. Все упирается в ресурс. Это для настольного компьютера вы покупаете топовый Samsung и несколько лет радуетесь жизни.
В случае серверного применения ресурс дорого Samsung будет тратиться также быстро, как и ресурс более дешевого аналога. А если все равно через год менять, то можно не выпендриваться и взять что-нибудь попроще.
Дальше смотрим на еще один важный параметр: модель работы SLC-кеша. В описаниях его нет, тут помогут только обзоры. Например, есть полностью аппаратно одинаковые диски, но с разными вариантами кеширования и разным поведением под нагрузками.
Грубо говоря, есть два основных варианта. В первом под кеш отдается все свободное место (33% от свободной емкости накопителя TLC), который пишется на максимальной скорости. А вот потом наступает самый плохой для диска сценарий – контроллер одновременно пишет и уплотняет данные и скорость там может упасть до неприлично низких значений.
Второй вариант – небольшой кеш и потом достаточно высокая и стабильная скорость записи, но далеко уже не та, что указана в спецификациях диска.
Тут нельзя однозначно сказать, что хорошо, а что плохо, смотрите по своим задачам и нагрузкам. Где-то лучше себя покажет одна модель кеширования, где-то другая.
Определились, хорошо. Теперь обращаем внимание на потребительские характеристики. В частности, на теплоотвод и возможность его снять без потери гарантии. Лучше всего брать модели, где теплоотвод сразу не приклеен, ну или понимать, что гарантии на диск у вас не будет.
Почему? Да потому что серверная нагрузка сильно отличается от настольной и вашему диску в обязательном порядке нужен хороший теплоотвод, иначе он постоянно будет находится в состоянии перегрева или близкого к нему.
Чтобы оградить себя от внезапного отказа в обязательном порядке собираем RAID. И в этом случае нам важно добиться идентичных режимов работы у обоих дисков.
Если вы используете разъемы на материнской плате – убедитесь, что к ним подведено одинаковое количество линий PCIe и одинакового поколения.
Иначе ваш массив будет работать на скорости самого медленного диска и это в лучшем случае.
Также очень важно еще и соблюдать идентичность скоростных характеристик дисков, в частности режимов кеширования. Если один диск продолжает принимать данные на полной скорости, а второй ее резко снизил, то есть ненулевые шансы, что такой диск выкинет из массива, хотя он будет полностью исправен.
Либо мы получим резкую деградацию производительности, иногда буквально «на ровном месте».
Это условие важно соблюдать и при замене дисков в массиве. Если купить точно такой же диск нет возможности, то приобретайте максимально похожий, желательно на контроллере того же производителя.
Если это невозможно – меняйте оба диска. Также не следует сочетать в одном массиве диски на разных поколениях шины PCIe, итоговая скорость записи может упасть ниже скорости самого медленного диска.
Ну и постоянный мониторинг. Температуры, ресурса и свободного места на массиве. Не допускайте заполнения более 60-70%, лучше всего иметь запас примерно на 50%, иначе задумайтесь о приобретении более емких моделей.
Также заведите за правило менять диски раз в три года (средний срок гарантии) даже если с ними все в порядке. Кстати это касается не только NVMe.
Вопрос вот в чем: есть энтерпрайз SSD за очень много денег, там все ок. А как быть бедным, кто ставит nvme в лучшем случае из топа потребительских? Что выбрать, на что смотреть?
Начнем с того, что выбрать можно все что угодно, даже не из топа, все зависит от доступного бюджета. Но перед выбором нужно внимательно посмотреть.
Начнем с того, что пишут в спецификациях. А именно с ресурса. Это основной показатель, от которого зависит как часто вы будете менять диски. Соизмеряем его с текущей нагрузкой и прикидываем затраты. Может оказаться так, что взять более дорогой диск будет выгоднее.
А может произойти ровно наоборот. Иногда выгоднее чаще менять дешевые диски, чем дорогие, но реже.
При этом следует понимать, что никакой серебряной пули в потребительском сегменте нет. Все упирается в ресурс. Это для настольного компьютера вы покупаете топовый Samsung и несколько лет радуетесь жизни.
В случае серверного применения ресурс дорого Samsung будет тратиться также быстро, как и ресурс более дешевого аналога. А если все равно через год менять, то можно не выпендриваться и взять что-нибудь попроще.
Дальше смотрим на еще один важный параметр: модель работы SLC-кеша. В описаниях его нет, тут помогут только обзоры. Например, есть полностью аппаратно одинаковые диски, но с разными вариантами кеширования и разным поведением под нагрузками.
Грубо говоря, есть два основных варианта. В первом под кеш отдается все свободное место (33% от свободной емкости накопителя TLC), который пишется на максимальной скорости. А вот потом наступает самый плохой для диска сценарий – контроллер одновременно пишет и уплотняет данные и скорость там может упасть до неприлично низких значений.
Второй вариант – небольшой кеш и потом достаточно высокая и стабильная скорость записи, но далеко уже не та, что указана в спецификациях диска.
Тут нельзя однозначно сказать, что хорошо, а что плохо, смотрите по своим задачам и нагрузкам. Где-то лучше себя покажет одна модель кеширования, где-то другая.
Определились, хорошо. Теперь обращаем внимание на потребительские характеристики. В частности, на теплоотвод и возможность его снять без потери гарантии. Лучше всего брать модели, где теплоотвод сразу не приклеен, ну или понимать, что гарантии на диск у вас не будет.
Почему? Да потому что серверная нагрузка сильно отличается от настольной и вашему диску в обязательном порядке нужен хороший теплоотвод, иначе он постоянно будет находится в состоянии перегрева или близкого к нему.
Чтобы оградить себя от внезапного отказа в обязательном порядке собираем RAID. И в этом случае нам важно добиться идентичных режимов работы у обоих дисков.
Если вы используете разъемы на материнской плате – убедитесь, что к ним подведено одинаковое количество линий PCIe и одинакового поколения.
Иначе ваш массив будет работать на скорости самого медленного диска и это в лучшем случае.
Также очень важно еще и соблюдать идентичность скоростных характеристик дисков, в частности режимов кеширования. Если один диск продолжает принимать данные на полной скорости, а второй ее резко снизил, то есть ненулевые шансы, что такой диск выкинет из массива, хотя он будет полностью исправен.
Либо мы получим резкую деградацию производительности, иногда буквально «на ровном месте».
Это условие важно соблюдать и при замене дисков в массиве. Если купить точно такой же диск нет возможности, то приобретайте максимально похожий, желательно на контроллере того же производителя.
Если это невозможно – меняйте оба диска. Также не следует сочетать в одном массиве диски на разных поколениях шины PCIe, итоговая скорость записи может упасть ниже скорости самого медленного диска.
Ну и постоянный мониторинг. Температуры, ресурса и свободного места на массиве. Не допускайте заполнения более 60-70%, лучше всего иметь запас примерно на 50%, иначе задумайтесь о приобретении более емких моделей.
Также заведите за правило менять диски раз в три года (средний срок гарантии) даже если с ними все в порядке. Кстати это касается не только NVMe.
👍51❤4
Их нравы, да и наши тоже…
Исследование уязвимостей в программном обеспечении – тема тонкая, особенно в той ее части, которая касается обнародования результатов исследований. Здесь нужно действовать аналогично докторам, в первую очередь руководствуясь принципом «не навреди».
Действительно, не вовремя опубликованная информация об уязвимости может быть использована злоумышленниками и нанесет серьезный вред законопослушным пользователям.
В тоже время полное замалчивание проблем тоже не является правильной стратегией, уязвимость может быть обнаружена разными исследователями и не все из них играют на светлой стороне.
Поэтому сложилась определенная практика, когда данные об уязвимостях публикуются, но без лишних технических подробностей, особенно если для них еще нет официальных исправлений.
Но последнее время в данной отрасли творится что-то непонятное, если не сказать – беспредельное.
Не так давно в Windows Server 2025 была обнаружена уязвимость под названием BadSuccessor, которая позволяет получить полномочия администратора домена располагая в нем минимальными правами.
Атака достаточно непростая технически и Microsoft классифицировала ее как уязвимость «умеренной серьезности» и пока не выпустила оперативного исправления.
И все бы ничего, но некий шустрый Гонсалес - Логан Гоинс – написал эксплойт эксплуатирующий уязвимость и опубликовал его на GitHub с подробной инструкцией с картинками.
Т.е. перевел теоретический сценарий атаки в практическую плоскость, сделав ее доступной каждому сельскому пионеру и самому последнему сявке на «раёне». После чего можем ждать вала атак куда только смогут дотянуться юные и не очень пионеры.
С одной стороны – это не первый случай и не последний. Но публикация рабочего эксплойта к серверному продукту Microsoft на ресурсе контролируемом Microsoft, причем от собственного имени – это что-то новенькое.
Там или совсем мышей не ловят или что-то поменялось в консерватории и теперь такие действия вполне допустимы под видом «исследований».
Хотя с точки зрения российского законодательства тут явный состав уголовного преступления:
Статья 273. Создание, использование и распространение вредоносных компьютерных программ
1. Создание, распространение или использование компьютерных программ либо иной компьютерной информации, заведомо предназначенных для несанкционированного уничтожения, блокирования, модификации, копирования компьютерной информации или нейтрализации средств защиты компьютерной информации, -
наказываются ограничением свободы на срок до четырех лет, либо принудительными работами на срок до четырех лет, либо лишением свободы на тот же срок со штрафом в размере до двухсот тысяч рублей или в размере заработной платы или иного дохода осужденного за период до восемнадцати месяцев.
И подобные нормы есть в законодательстве любой развитой (и не очень) страны. Потому как публикация эксплойта для незакрытой уязвимости – это именно создание и распространение вредоносного ПО.
Но что-то подсказывает мне, что попробуй сейчас тронуть этого шустрого Гонсалеса – как поднимется шум до небес по теме преследования «свободных исследователей», ущемления и прищемления, а также прочего угнетения темными силами всего светлого и толерантного.
В такие вот времена живем…
Исследование уязвимостей в программном обеспечении – тема тонкая, особенно в той ее части, которая касается обнародования результатов исследований. Здесь нужно действовать аналогично докторам, в первую очередь руководствуясь принципом «не навреди».
Действительно, не вовремя опубликованная информация об уязвимости может быть использована злоумышленниками и нанесет серьезный вред законопослушным пользователям.
В тоже время полное замалчивание проблем тоже не является правильной стратегией, уязвимость может быть обнаружена разными исследователями и не все из них играют на светлой стороне.
Поэтому сложилась определенная практика, когда данные об уязвимостях публикуются, но без лишних технических подробностей, особенно если для них еще нет официальных исправлений.
Но последнее время в данной отрасли творится что-то непонятное, если не сказать – беспредельное.
Не так давно в Windows Server 2025 была обнаружена уязвимость под названием BadSuccessor, которая позволяет получить полномочия администратора домена располагая в нем минимальными правами.
Атака достаточно непростая технически и Microsoft классифицировала ее как уязвимость «умеренной серьезности» и пока не выпустила оперативного исправления.
И все бы ничего, но некий шустрый Гонсалес - Логан Гоинс – написал эксплойт эксплуатирующий уязвимость и опубликовал его на GitHub с подробной инструкцией с картинками.
Т.е. перевел теоретический сценарий атаки в практическую плоскость, сделав ее доступной каждому сельскому пионеру и самому последнему сявке на «раёне». После чего можем ждать вала атак куда только смогут дотянуться юные и не очень пионеры.
С одной стороны – это не первый случай и не последний. Но публикация рабочего эксплойта к серверному продукту Microsoft на ресурсе контролируемом Microsoft, причем от собственного имени – это что-то новенькое.
Там или совсем мышей не ловят или что-то поменялось в консерватории и теперь такие действия вполне допустимы под видом «исследований».
Хотя с точки зрения российского законодательства тут явный состав уголовного преступления:
Статья 273. Создание, использование и распространение вредоносных компьютерных программ
1. Создание, распространение или использование компьютерных программ либо иной компьютерной информации, заведомо предназначенных для несанкционированного уничтожения, блокирования, модификации, копирования компьютерной информации или нейтрализации средств защиты компьютерной информации, -
наказываются ограничением свободы на срок до четырех лет, либо принудительными работами на срок до четырех лет, либо лишением свободы на тот же срок со штрафом в размере до двухсот тысяч рублей или в размере заработной платы или иного дохода осужденного за период до восемнадцати месяцев.
И подобные нормы есть в законодательстве любой развитой (и не очень) страны. Потому как публикация эксплойта для незакрытой уязвимости – это именно создание и распространение вредоносного ПО.
Но что-то подсказывает мне, что попробуй сейчас тронуть этого шустрого Гонсалеса – как поднимется шум до небес по теме преследования «свободных исследователей», ущемления и прищемления, а также прочего угнетения темными силами всего светлого и толерантного.
В такие вот времена живем…
👍25👀4🤡2❤1💯1
Режимы кеширования виртуальных дисков KVM в Proxmox VE
Производительность дисковой подсистемы очень часто является узким местом многих вычислительных систем, и каждый системный администратор сталкивался и сталкивается с необходимостью оптимизации процессов обмена с накопителями.
Одним из эффективных решений, позволяющих ускорить операции ввода - вывода является кеширование. Proxmox предлагает для виртуальных дисков KVM несколько режимов кеширования, в данной статье мы рассмотрим, как они работают, а также их достоинства и недостатки.
https://interface31.ru/tech_it/2023/01/rezhimy-keshirovaniya-virtual-nyh-diskov-kvm-v-proxmox-ve.html
Производительность дисковой подсистемы очень часто является узким местом многих вычислительных систем, и каждый системный администратор сталкивался и сталкивается с необходимостью оптимизации процессов обмена с накопителями.
Одним из эффективных решений, позволяющих ускорить операции ввода - вывода является кеширование. Proxmox предлагает для виртуальных дисков KVM несколько режимов кеширования, в данной статье мы рассмотрим, как они работают, а также их достоинства и недостатки.
https://interface31.ru/tech_it/2023/01/rezhimy-keshirovaniya-virtual-nyh-diskov-kvm-v-proxmox-ve.html
👍31
Ваш Zabbix напрасно поднимает панику, у нас еще много памяти
Не столь давно, после внедрения Zabbix один из заказчиков пожаловался, что Zabbix начал присылать сообщения о том, что недостаточно оперативной памяти, но на самом деле памяти еще достаточно.
На вопрос откуда такая уверенность нам кивнули на веб-интерфейс Proxmox из которого выходило, что памяти действительно еще хватает.
Так что, Zabbix неправильно считает память или напрасно нагнетает панику? Вовсе нет, давайте разбираться.
Давайте возьмем еще один хост с Proxmox и посмотрим, судя по графику у нас в запасе еще около 10 ГБ свободной памяти, неплохо.
Но если запустим команду:
При этом у нас 3,8 ГБ разделяемой памяти и 8,3 ГБ буферной/кеша.
Внимательный читатель, вооружившись калькулятором, скажет: стоп, что-то не сходятся у вас доходы с расходами.
Но в Linux есть некоторая особенность. Неактивные страницы памяти считаются занятыми, так как содержат некоторые полезные данные. В тоже время они считаются доступными, так как могут быть немедленно освобождены и переданы нуждающемуся в памяти процессу.
Т.е. если мы сложим вместе
Теперь давайте разберемся что значит каждый вид памяти:
▫️ used – использованная, память которая напрямую используется рабочими процессами в системе
▫️ free – свободная, это память которая не используется ни одним процессом и может быть выделена незамедлительно.
▫️ shared – разделяемая, используется для ускорения межпроцессного взаимодействия, что позволяет исключить передачу информации между процессами через ядро.
▫️ buff/cache – буфер ввода-вывода и кеш VFS (виртуальной файловой системы), играет очень важную роль, так как позволяет разместить в памяти наиболее часто запрашиваемые данные, системные библиотеки и т.п.
▫️ available – доступная, память которая может быть выделена процессу без обращения к пространствам подкачки.
И именно доступная (available) память наиболее точно отображает положение дел с наличием памяти в системе, и именно она используется в триггерах Zabbix.
Proxmox же просто показывает нам used, а остальное помечает свободным. Исходя из этого у нас имеется 10 ГБ «свободной» памяти, на самом деле нам доступно только 6 ГБ, где остальное?
А дело в том, что кеш тоже имеет важное значение для производительности системы и его сброс может привести к обратному эффекту – начнется интенсивное обращение к диску и общая производительность системы резко упадет.
Поэтому разные участки кеша и буферов тоже имеют собственный вес и этот вес может давать им преимущество над запущенными процессами.
В некоторых случаях система может решить, что освобождать кеш дорого и дешевле будет отправить некоторые страницы памяти в подкачку или вовсе позвать OOM Killer и пристрелить какой-нибудь жирный процесс. 🔫🔫🔫
Собственно, это мы и видим в данном случае - 4.7 ГБ памяти содержит «дорогой» кеш и не сможет быть быстро освобождена. Точнее, система будет держаться за этот кеш до последнего, потому что после его очистки плохо станет всем, а пристрелят или отправят в своп только некоторых.
Поэтому в данном случае Zabbix прав, с чем наши заказчики скоро столкнулись, когда OOM Killer начал выключать одну из малоактивных виртуалок.
Поэтому при любых непонятках с памятью ориентируйтесь не на графики и показания различных консолей, а проанализируйте ее использование при помощи команды
Не столь давно, после внедрения Zabbix один из заказчиков пожаловался, что Zabbix начал присылать сообщения о том, что недостаточно оперативной памяти, но на самом деле памяти еще достаточно.
На вопрос откуда такая уверенность нам кивнули на веб-интерфейс Proxmox из которого выходило, что памяти действительно еще хватает.
Так что, Zabbix неправильно считает память или напрасно нагнетает панику? Вовсе нет, давайте разбираться.
Давайте возьмем еще один хост с Proxmox и посмотрим, судя по графику у нас в запасе еще около 10 ГБ свободной памяти, неплохо.
Но если запустим команду:
free -h
То картина существенно изменится, как оказывается свободной памяти у нас всего 2,2 ГБ, а доступной 6,3 ГБ.При этом у нас 3,8 ГБ разделяемой памяти и 8,3 ГБ буферной/кеша.
Внимательный читатель, вооружившись калькулятором, скажет: стоп, что-то не сходятся у вас доходы с расходами.
Но в Linux есть некоторая особенность. Неактивные страницы памяти считаются занятыми, так как содержат некоторые полезные данные. В тоже время они считаются доступными, так как могут быть немедленно освобождены и переданы нуждающемуся в памяти процессу.
Т.е. если мы сложим вместе
used + shared + buff/cache то полученное значение не будет соответствовать total – free. Теперь давайте разберемся что значит каждый вид памяти:
▫️ used – использованная, память которая напрямую используется рабочими процессами в системе
▫️ free – свободная, это память которая не используется ни одним процессом и может быть выделена незамедлительно.
▫️ shared – разделяемая, используется для ускорения межпроцессного взаимодействия, что позволяет исключить передачу информации между процессами через ядро.
▫️ buff/cache – буфер ввода-вывода и кеш VFS (виртуальной файловой системы), играет очень важную роль, так как позволяет разместить в памяти наиболее часто запрашиваемые данные, системные библиотеки и т.п.
▫️ available – доступная, память которая может быть выделена процессу без обращения к пространствам подкачки.
И именно доступная (available) память наиболее точно отображает положение дел с наличием памяти в системе, и именно она используется в триггерах Zabbix.
Proxmox же просто показывает нам used, а остальное помечает свободным. Исходя из этого у нас имеется 10 ГБ «свободной» памяти, на самом деле нам доступно только 6 ГБ, где остальное?
А дело в том, что кеш тоже имеет важное значение для производительности системы и его сброс может привести к обратному эффекту – начнется интенсивное обращение к диску и общая производительность системы резко упадет.
Поэтому разные участки кеша и буферов тоже имеют собственный вес и этот вес может давать им преимущество над запущенными процессами.
В некоторых случаях система может решить, что освобождать кеш дорого и дешевле будет отправить некоторые страницы памяти в подкачку или вовсе позвать OOM Killer и пристрелить какой-нибудь жирный процесс. 🔫🔫🔫
Собственно, это мы и видим в данном случае - 4.7 ГБ памяти содержит «дорогой» кеш и не сможет быть быстро освобождена. Точнее, система будет держаться за этот кеш до последнего, потому что после его очистки плохо станет всем, а пристрелят или отправят в своп только некоторых.
Поэтому в данном случае Zabbix прав, с чем наши заказчики скоро столкнулись, когда OOM Killer начал выключать одну из малоактивных виртуалок.
Поэтому при любых непонятках с памятью ориентируйтесь не на графики и показания различных консолей, а проанализируйте ее использование при помощи команды
free.
👍63
Некоторые особенности расхода ресурса SSD или кому верить?
Сегодня один наш коллега обратил наше внимание на значение счетчиков отдаваемых S.M.A.R.T., а точнее на их несоответствие.
Есть два диска Kingston KC600 на 1024 ГБ с заявленным ресурсом записи 600 ТБ. Данные диски отдают в S.M.A.R.T. не только процент оставшегося ресурса, но и количество записанных данных блоками по 32 МБ.
Что привлекло внимание и насторожило? Согласно полученным данным износ первого диска составил 14%, а второго 18%. При заявленном ресурсе это должно соответствовать 84 ТБ и 108ТБ записанных данных.
Однако реально диски записали 53 ТБ и 52 ТБ, причем больший износ оказался у того диска, что записал меньше.
Странно…
Но внизу есть у нас еще один показатель - TLCWrites32MiB – который показывает количество блоков по 32 МБ, реально записанных в TLC. Здесь мы как раз можем оценить такой параметр как усиление записи (write amplification).
Путем несложных вычислений для первого диска получим 465 ТБ, что соответствует коэффициенту WA 8,7. Это говорит о том, что фактически на один записанный логический блок диск делает примерно 9 записей. Данный коэффициент не является постоянным и зависит от характера записи, единовременного объема, прошивки диска, параметров кеширования и т.д. и т.п.
У второго диска этот параметр оказался еще выше, при меньшем количестве логических записей – 566 ТБ. И это как раз соответствует показанному самим диском износу. Что касается усиления записи, то этот коэффициент для второго диска еще выше – 10,9, т.е. 11 физических записей на 1 логическую.
Сами абсолютные цифры записи в TLC никакого практического интереса не представляют, так как мы не знаем верхнего порога по этому параметру. Нет, зная процент износа и абсолютное значение мы можем рассчитать верхний порог, но зачем?
В отрыве от процентов это просто сферические цифры в вакууме. Поэтому счетчика в процентах нам достаточно, а запись в TLC без процентов лишена практического смысла.
И вот тут мы подходим к вопросу: а кому верить?
В первую очередь надо верить счетчику диска в процентах износа. Он рассчитывается на основе реального количества записи в TLC, где ресурс измеряется не в единицах объема данных, а в количестве перезаписей ячеек.
Заявленный в описании диска ресурс – TBW – это некое среднее по больнице количество записанных данных с учетом некого среднего коэффициента усиления WA. Ориентироваться на него можно, брать за некую константу нельзя.
Потому что даже если вы знаете ресурс и знаете средний объем ежедневно записываемых данных, то вы все равно не знаете для какого WA рассчитан этот ресурс и какой у вас фактический WA.
Что касается наших дисков, то для них можно попробовать рассчитать реальный ресурс по логической записи. Для первого диска он получится 378 ТБ, для второго 288 ТБ. Т.е. фактически вдвое меньше заявленного.
Это, кстати, объясняет и различные заявления в духе «диск А – отстой, помер, не выработав и половины ресурса», или «диски В – круть, работают вдвое больше заявленного».
На самом деле и тот и другой диск работают в рамках доступного ресурса перезаписи ячеек памяти, который в среднем по больнице одинаковый, а вот WA у каждого разный и поэтому итоговый результат, выраженный в объеме логической записи, может сильно различаться.
Как быть? Если диск предоставляет данные в износе в процентах – ориентируемся только на них. Если таких данных нет, то берем в расчет логическую запись, но ставим триггер далеко от пороговых значений.
Где именно начинать бить тревогу? Сложный вопрос, но при отсутствии в S.M.A.R.T. иных показателей о замене диска следует начинать задумываться после того, как ресурс снизится более чем на 50%.
Сегодня один наш коллега обратил наше внимание на значение счетчиков отдаваемых S.M.A.R.T., а точнее на их несоответствие.
Есть два диска Kingston KC600 на 1024 ГБ с заявленным ресурсом записи 600 ТБ. Данные диски отдают в S.M.A.R.T. не только процент оставшегося ресурса, но и количество записанных данных блоками по 32 МБ.
Что привлекло внимание и насторожило? Согласно полученным данным износ первого диска составил 14%, а второго 18%. При заявленном ресурсе это должно соответствовать 84 ТБ и 108ТБ записанных данных.
Однако реально диски записали 53 ТБ и 52 ТБ, причем больший износ оказался у того диска, что записал меньше.
Странно…
Но внизу есть у нас еще один показатель - TLCWrites32MiB – который показывает количество блоков по 32 МБ, реально записанных в TLC. Здесь мы как раз можем оценить такой параметр как усиление записи (write amplification).
Путем несложных вычислений для первого диска получим 465 ТБ, что соответствует коэффициенту WA 8,7. Это говорит о том, что фактически на один записанный логический блок диск делает примерно 9 записей. Данный коэффициент не является постоянным и зависит от характера записи, единовременного объема, прошивки диска, параметров кеширования и т.д. и т.п.
У второго диска этот параметр оказался еще выше, при меньшем количестве логических записей – 566 ТБ. И это как раз соответствует показанному самим диском износу. Что касается усиления записи, то этот коэффициент для второго диска еще выше – 10,9, т.е. 11 физических записей на 1 логическую.
Сами абсолютные цифры записи в TLC никакого практического интереса не представляют, так как мы не знаем верхнего порога по этому параметру. Нет, зная процент износа и абсолютное значение мы можем рассчитать верхний порог, но зачем?
В отрыве от процентов это просто сферические цифры в вакууме. Поэтому счетчика в процентах нам достаточно, а запись в TLC без процентов лишена практического смысла.
И вот тут мы подходим к вопросу: а кому верить?
В первую очередь надо верить счетчику диска в процентах износа. Он рассчитывается на основе реального количества записи в TLC, где ресурс измеряется не в единицах объема данных, а в количестве перезаписей ячеек.
Заявленный в описании диска ресурс – TBW – это некое среднее по больнице количество записанных данных с учетом некого среднего коэффициента усиления WA. Ориентироваться на него можно, брать за некую константу нельзя.
Потому что даже если вы знаете ресурс и знаете средний объем ежедневно записываемых данных, то вы все равно не знаете для какого WA рассчитан этот ресурс и какой у вас фактический WA.
Что касается наших дисков, то для них можно попробовать рассчитать реальный ресурс по логической записи. Для первого диска он получится 378 ТБ, для второго 288 ТБ. Т.е. фактически вдвое меньше заявленного.
Это, кстати, объясняет и различные заявления в духе «диск А – отстой, помер, не выработав и половины ресурса», или «диски В – круть, работают вдвое больше заявленного».
На самом деле и тот и другой диск работают в рамках доступного ресурса перезаписи ячеек памяти, который в среднем по больнице одинаковый, а вот WA у каждого разный и поэтому итоговый результат, выраженный в объеме логической записи, может сильно различаться.
Как быть? Если диск предоставляет данные в износе в процентах – ориентируемся только на них. Если таких данных нет, то берем в расчет логическую запись, но ставим триггер далеко от пороговых значений.
Где именно начинать бить тревогу? Сложный вопрос, но при отсутствии в S.M.A.R.T. иных показателей о замене диска следует начинать задумываться после того, как ресурс снизится более чем на 50%.
👍36🔥5❤2🤔1🥱1
VPN и сетевое окружение
Самый часто задаваемый вопрос в комментариях к статьям о VPN звучит примерно так: я настроил VPN, настроил маршрутизацию, компьютеры в удаленной сети пингуются, но в сетевом окружении их не видно, что я сделал не так?
Когда поясняешь, что все так и сетевое обнаружение компьютеров за VPN не видит, то сразу спрашивают, а как сделать так, чтобы увидела.
Здесь мы подходим к принципу работы сетевого окружения. Каким образом компьютер в одноранговой сети может найти своих соседей?
Примерно также, как человек в лесу ищет другого человека.
Компьютер, если проводить аналогию, громко кричит на всю сеть: «эй, есть здесь кто-нибудь?»
А ему каждый активный узел отвечает: «есть, меня зовут Имярек»
Если говорить сетевым языком, то ПК отправляет широковещательный пакет, на который активные узлы отправляют ответы.
Фактически, каждый раз открывая сетевое окружение вы устраиваете такую перекличку. И кроме вас таких участников сети хватает.
Ну ладно, это мы поняли, но в чем же проблема? Сколько там того трафика? Тем более в наш век, когда гигабит как норма жизни.
Но давайте спустимся с этих сияющих высот на уровень L2 модели OSI, называемый также канальным, так как именно он отвечает за работу сети.
Каждый порт коммутатора, а на L2 мы работаем именно с коммутаторами, может передавать кадр только от одного узла сети. Также обратим ваше внимание, что здесь у нас кадры, а не пакеты.
Реальная скорость коммутатора определяется не мегабитами и мегабайтами в секунду, а количеством кадров в единицу времени. Скорость же будет зависеть от размера кадров.
Здесь можно провести аналогию с лифтом. Вот вам надо поднять на этаж шкаф, и вы стоите ждете грузовой лифт, а на лифте катаются мальчики и он практически пустой ездит между этажами, а вы с грузом стоите и ждете.
Вот так и широковещание, сами широковещательные кадры небольшие, но они как эти мальчики, фактически гоняют сеть впустую, а важные данные вынуждены ожидать своей очереди. И чем больше широковещания, тем больше у нас таких мальчиков.
Благо, широковещание ограничено широковещательным доменом, читай физической сетью, так как выполняется на канальном уровне, а широковещательный домен, по сути, совокупность портов всех коммутаторов сети.
Современные протоколы сетевого окружения, в отличии от NETBIOS работавшего на броадкасте, используют мультикаст, что немного снижает нагрузку на сеть, но принципиально вопроса не решает.
Если пояснять на пальцах, то сетевые устройства теперь уже не орут на всю сеть «есть тут кто-нибудь?», а сначала вступают в группу в мессенджере и устраивают переклички уже там.
Это снижает объем широковещания, но целиком проблему не снижает.
А причем тут VPN, спросите вы? А при том, что желание видеть устройства за VPN в сетевом окружении аналогично желанию устраивать подобные переклички не только в своей, но и в удаленных сетях.
А теперь представьте, к чему это может привести, ведь ваш ПК не один такой и VPN может связывать самые разные сети в самой разной топологии. По факту в сети будет стоять сплошной ор и для полезного трафика там останется совсем мало места.
Поэтому все широковещательные протоколы сетевого обнаружения работают только в пределах своей сети.
А для доступа к удаленным узлам используйте IP-адреса или доменные имена.
И даже в локальной сети не следует лишний раз использовать сетевое окружение, потому что пользователь, желая просто попасть в общую папку на файловом сервере будет устраивать никому не нужные переклички.
Поэтому подключайте сетевые диски, используйте ярлыки и вообще старайтесь следовать прямыми путями, накричаться еще успеете.
Самый часто задаваемый вопрос в комментариях к статьям о VPN звучит примерно так: я настроил VPN, настроил маршрутизацию, компьютеры в удаленной сети пингуются, но в сетевом окружении их не видно, что я сделал не так?
Когда поясняешь, что все так и сетевое обнаружение компьютеров за VPN не видит, то сразу спрашивают, а как сделать так, чтобы увидела.
Здесь мы подходим к принципу работы сетевого окружения. Каким образом компьютер в одноранговой сети может найти своих соседей?
Примерно также, как человек в лесу ищет другого человека.
Компьютер, если проводить аналогию, громко кричит на всю сеть: «эй, есть здесь кто-нибудь?»
А ему каждый активный узел отвечает: «есть, меня зовут Имярек»
Если говорить сетевым языком, то ПК отправляет широковещательный пакет, на который активные узлы отправляют ответы.
Фактически, каждый раз открывая сетевое окружение вы устраиваете такую перекличку. И кроме вас таких участников сети хватает.
Ну ладно, это мы поняли, но в чем же проблема? Сколько там того трафика? Тем более в наш век, когда гигабит как норма жизни.
Но давайте спустимся с этих сияющих высот на уровень L2 модели OSI, называемый также канальным, так как именно он отвечает за работу сети.
Каждый порт коммутатора, а на L2 мы работаем именно с коммутаторами, может передавать кадр только от одного узла сети. Также обратим ваше внимание, что здесь у нас кадры, а не пакеты.
Реальная скорость коммутатора определяется не мегабитами и мегабайтами в секунду, а количеством кадров в единицу времени. Скорость же будет зависеть от размера кадров.
Здесь можно провести аналогию с лифтом. Вот вам надо поднять на этаж шкаф, и вы стоите ждете грузовой лифт, а на лифте катаются мальчики и он практически пустой ездит между этажами, а вы с грузом стоите и ждете.
Вот так и широковещание, сами широковещательные кадры небольшие, но они как эти мальчики, фактически гоняют сеть впустую, а важные данные вынуждены ожидать своей очереди. И чем больше широковещания, тем больше у нас таких мальчиков.
Благо, широковещание ограничено широковещательным доменом, читай физической сетью, так как выполняется на канальном уровне, а широковещательный домен, по сути, совокупность портов всех коммутаторов сети.
Современные протоколы сетевого окружения, в отличии от NETBIOS работавшего на броадкасте, используют мультикаст, что немного снижает нагрузку на сеть, но принципиально вопроса не решает.
Если пояснять на пальцах, то сетевые устройства теперь уже не орут на всю сеть «есть тут кто-нибудь?», а сначала вступают в группу в мессенджере и устраивают переклички уже там.
Это снижает объем широковещания, но целиком проблему не снижает.
А причем тут VPN, спросите вы? А при том, что желание видеть устройства за VPN в сетевом окружении аналогично желанию устраивать подобные переклички не только в своей, но и в удаленных сетях.
А теперь представьте, к чему это может привести, ведь ваш ПК не один такой и VPN может связывать самые разные сети в самой разной топологии. По факту в сети будет стоять сплошной ор и для полезного трафика там останется совсем мало места.
Поэтому все широковещательные протоколы сетевого обнаружения работают только в пределах своей сети.
А для доступа к удаленным узлам используйте IP-адреса или доменные имена.
И даже в локальной сети не следует лишний раз использовать сетевое окружение, потому что пользователь, желая просто попасть в общую папку на файловом сервере будет устраивать никому не нужные переклички.
Поэтому подключайте сетевые диски, используйте ярлыки и вообще старайтесь следовать прямыми путями, накричаться еще успеете.
👍74🔥6❤4🥱3💯1
О пользе систем управление конфигурациями или тайная жизнь ваших сетевых устройств
Не так давно мы рассказывали о том, как установить и настроить свободную систему управления конфигурациями Oxidized.
🔹 Устанавливаем и настраиваем систему управления конфигурациями сетевого оборудования Oxidized
И тогда в комментариях многие писали, мол зачем так все сложно, я скриптами быстрее бекап сделаю.
Но дело в том, что Oxidized – это не бекап, резервное копирование только одна из его функций. Гораздо более ценная и полезная – это система контроля изменений, основанная на Git.
Она позволяет быстро и эффективно выявлять все внесенные в конфигурацию изменения и при необходимости также быстро их сравнивать, объединять или откатывать.
При этом анализ внесенных в конфигурацию изменений помогает выявить разные скрытые от глаз процессы.
Чтобы не быть голословными расскажем одну реальную историю.
Не так давно мы внедрили новому заказчику Oxidized и через некоторое время обнаружили что конфигурация некоторых роутеров меняется.
Мы никаких изменений не вносили, персонал заказчика тоже, поэтому мысли возникли всякие, во многом нехорошие.
Но нет, роутеры никто не взломал, оказалось они тоже могут жить своей жизнью. В частности, на некоторых роутерах самопроизвольно переключался часовой пояс. С Москвы на Самару и обратно.
Таким вот образом почему-то работало автоматическое обнаружение часового пояса.
На первый взгляд довольно незначительная ерунда, особо ни на что не влияющая. И это действительно так. При общении между собой устройства используют время UTC и серьезных проблем быть не должно.
Но могут быть проблемы с анализом логов, когда вы будете искать там события по московскому времени, а они окажутся по самарскому, т.е. на час больше.
И вряд ли кто-то, не находя в логе нужных событий пойдет первым делом проверять часовой пояс.
Но речь совершенно не об этом. Вместо часового пояса там могло быть все что угодно. Речь здесь о другом, что именно благодаря системе управления конфигурациями нам открылась тайная жизнь сетевых устройств, о которой мы даже не догадывались.
Поэтому регулярный контроль изменений, особенно если вы их не вносили, дает администратору возможность выявить и устранить нестандартное поведение устройства, либо на ранних стадиях обнаружить несанкционированный доступ.
Ни одна система резервного копирования таких возможностей не предоставляет, а сравнивать конфигурации в бекапах тем более никто руками не будет.
Не так давно мы рассказывали о том, как установить и настроить свободную систему управления конфигурациями Oxidized.
🔹 Устанавливаем и настраиваем систему управления конфигурациями сетевого оборудования Oxidized
И тогда в комментариях многие писали, мол зачем так все сложно, я скриптами быстрее бекап сделаю.
Но дело в том, что Oxidized – это не бекап, резервное копирование только одна из его функций. Гораздо более ценная и полезная – это система контроля изменений, основанная на Git.
Она позволяет быстро и эффективно выявлять все внесенные в конфигурацию изменения и при необходимости также быстро их сравнивать, объединять или откатывать.
При этом анализ внесенных в конфигурацию изменений помогает выявить разные скрытые от глаз процессы.
Чтобы не быть голословными расскажем одну реальную историю.
Не так давно мы внедрили новому заказчику Oxidized и через некоторое время обнаружили что конфигурация некоторых роутеров меняется.
Мы никаких изменений не вносили, персонал заказчика тоже, поэтому мысли возникли всякие, во многом нехорошие.
Но нет, роутеры никто не взломал, оказалось они тоже могут жить своей жизнью. В частности, на некоторых роутерах самопроизвольно переключался часовой пояс. С Москвы на Самару и обратно.
Таким вот образом почему-то работало автоматическое обнаружение часового пояса.
На первый взгляд довольно незначительная ерунда, особо ни на что не влияющая. И это действительно так. При общении между собой устройства используют время UTC и серьезных проблем быть не должно.
Но могут быть проблемы с анализом логов, когда вы будете искать там события по московскому времени, а они окажутся по самарскому, т.е. на час больше.
И вряд ли кто-то, не находя в логе нужных событий пойдет первым делом проверять часовой пояс.
Но речь совершенно не об этом. Вместо часового пояса там могло быть все что угодно. Речь здесь о другом, что именно благодаря системе управления конфигурациями нам открылась тайная жизнь сетевых устройств, о которой мы даже не догадывались.
Поэтому регулярный контроль изменений, особенно если вы их не вносили, дает администратору возможность выявить и устранить нестандартное поведение устройства, либо на ранних стадиях обнаружить несанкционированный доступ.
Ни одна система резервного копирования таких возможностей не предоставляет, а сравнивать конфигурации в бекапах тем более никто руками не будет.
👍41❤3👌1
Самодеятельность, художественная и не очень
Скрипты, как много в этом слове. Я думаю, что у каждого сисадмина в жизни был период, когда он на каждый чих сочинял собственный скрипт.
Как будто это что-то плохое, скажет иной читатель. Ну да как посмотреть, с какой точки зрения.
Начнем с точки зрения самого админа, если админ постоянный, на зарплате, то ему может показаться что ничего страшного в этом нет. Инфраструктура моя, скрипты мои, я все знаю, что может пойти не так?
Мы уже промолчим о том, что все скрипты должны быть документированы. По факту это очень и очень больной вопрос. Даже если изначальная версия скрипта таки прокомментирована и задокументирована, то последующие правки в него этого часто не удостаиваются, особенно мелкие и срочные. Потом это все копится и накладывается, ну вы поняли…
Так в чем же проблема собственных скриптов? Основная проблема в «эффекте автобуса», да да, это про того самого разработчика, который попал под автобус. Причем понимать это надо не буквально, а в том смысле, что неожиданный уход разработчика из проекта делает все эти скрипты бомбой замедленного действия.
Почему так? Про неполноту документации мы уже писали. К этому накладывается еще и дополнительный эффект «это все знают». Разработчик мог вполне сознательно опустить в документации некоторые, очевидные для него, моменты. Которые могут оказаться непонятны окружающим.
Далее сами скрипты. Очень многие скриптовые языки позволяют писать двумя способами: быстро, рационально, но нечитаемо или долго, неоптимально, но читаемо. Надо ли говорить, что чаще всего превалирует первый подход, особенно среди админов-«староверов», которые не используют современные среды разработки с синтаксис-помощниками и автодополнением, а ваяют скрипты буквально на коленках.
Мы, как аутсорсеры, очень часто встречались с такими скриптами, про которые никто ничего не знает и трогать откровенно боится, а написавший их товарищ давно растворился в тумане.
Ничего хорошего в этом нет, равно как и разобраться с ними за разумное время и деньги не представляется возможным. Но самая «мякотка» состоит в том, что они дублируют те возможности и функции, которые могут быть получены штатными пакетами или распространенным и широко известным сторонним софтом.
Да ладно, снова скажет кто-то, зачем тащить целый пакет, когда тут можно десятком другим строк обойтись.
А вот и нет, пакет тащить нужно, потому что ожидаемая конфигурация и ожидаемое поведение системы, в отличие от скрипта. И не важно, что это не красиво, не оптимально, не эффективно, не соответствуем вашим религиозным воззрениями (нужное подчеркнуть).
Причем наступить на эти грабли можно совершенно случайно. Для этого не нужно даже попадать под автобус. Достаточно уехать в отпуск и оказаться на некоторое время без связи.
Если в это время возникнет некоторая нештатная ситуация и коллеги не смогут разобраться в вашем творчестве, то по возвращению вас ждет достаточно неприятный разговор.
Потому что платят вам не за смелые эксперименты и самовыражение, а за поддержание инфраструктуры в стабильном, управляемом и предсказуемом виде, что подразумевает максимальную стандартизацию.
Любое нестандартное решение – это дополнительные затраты на поддержу (часто косвенные) и дополнительные риски, связанные с нестандартностью. Во многих случаях абсолютно неуместные.
А желание отдельных сотрудников использовать собственные костыли к месту и не к месту заставляет серьезно задуматься в плане их профпригодности, причем не в техническом плане (тут обычно все в порядке), а в социальном, в способности работать в коллективе и ставить общественные интересы выше собственных.
Ну а мораль сей басни проста: если есть стандартные и общепринятые решения – то следует их использовать, даже если вы можете за пять минут левым задним копытом набросать скрипт «в 1000 раз лучше».
Ну или пишите и выкладывайте его на GitHub и когда его начнут включать в дистрибутивы и использовать массы – тогда можно будет использовать его как стандартное решение.
Скрипты, как много в этом слове. Я думаю, что у каждого сисадмина в жизни был период, когда он на каждый чих сочинял собственный скрипт.
Как будто это что-то плохое, скажет иной читатель. Ну да как посмотреть, с какой точки зрения.
Начнем с точки зрения самого админа, если админ постоянный, на зарплате, то ему может показаться что ничего страшного в этом нет. Инфраструктура моя, скрипты мои, я все знаю, что может пойти не так?
Мы уже промолчим о том, что все скрипты должны быть документированы. По факту это очень и очень больной вопрос. Даже если изначальная версия скрипта таки прокомментирована и задокументирована, то последующие правки в него этого часто не удостаиваются, особенно мелкие и срочные. Потом это все копится и накладывается, ну вы поняли…
Так в чем же проблема собственных скриптов? Основная проблема в «эффекте автобуса», да да, это про того самого разработчика, который попал под автобус. Причем понимать это надо не буквально, а в том смысле, что неожиданный уход разработчика из проекта делает все эти скрипты бомбой замедленного действия.
Почему так? Про неполноту документации мы уже писали. К этому накладывается еще и дополнительный эффект «это все знают». Разработчик мог вполне сознательно опустить в документации некоторые, очевидные для него, моменты. Которые могут оказаться непонятны окружающим.
Далее сами скрипты. Очень многие скриптовые языки позволяют писать двумя способами: быстро, рационально, но нечитаемо или долго, неоптимально, но читаемо. Надо ли говорить, что чаще всего превалирует первый подход, особенно среди админов-«староверов», которые не используют современные среды разработки с синтаксис-помощниками и автодополнением, а ваяют скрипты буквально на коленках.
Мы, как аутсорсеры, очень часто встречались с такими скриптами, про которые никто ничего не знает и трогать откровенно боится, а написавший их товарищ давно растворился в тумане.
Ничего хорошего в этом нет, равно как и разобраться с ними за разумное время и деньги не представляется возможным. Но самая «мякотка» состоит в том, что они дублируют те возможности и функции, которые могут быть получены штатными пакетами или распространенным и широко известным сторонним софтом.
Да ладно, снова скажет кто-то, зачем тащить целый пакет, когда тут можно десятком другим строк обойтись.
А вот и нет, пакет тащить нужно, потому что ожидаемая конфигурация и ожидаемое поведение системы, в отличие от скрипта. И не важно, что это не красиво, не оптимально, не эффективно, не соответствуем вашим религиозным воззрениями (нужное подчеркнуть).
Причем наступить на эти грабли можно совершенно случайно. Для этого не нужно даже попадать под автобус. Достаточно уехать в отпуск и оказаться на некоторое время без связи.
Если в это время возникнет некоторая нештатная ситуация и коллеги не смогут разобраться в вашем творчестве, то по возвращению вас ждет достаточно неприятный разговор.
Потому что платят вам не за смелые эксперименты и самовыражение, а за поддержание инфраструктуры в стабильном, управляемом и предсказуемом виде, что подразумевает максимальную стандартизацию.
Любое нестандартное решение – это дополнительные затраты на поддержу (часто косвенные) и дополнительные риски, связанные с нестандартностью. Во многих случаях абсолютно неуместные.
А желание отдельных сотрудников использовать собственные костыли к месту и не к месту заставляет серьезно задуматься в плане их профпригодности, причем не в техническом плане (тут обычно все в порядке), а в социальном, в способности работать в коллективе и ставить общественные интересы выше собственных.
Ну а мораль сей басни проста: если есть стандартные и общепринятые решения – то следует их использовать, даже если вы можете за пять минут левым задним копытом набросать скрипт «в 1000 раз лучше».
Ну или пишите и выкладывайте его на GitHub и когда его начнут включать в дистрибутивы и использовать массы – тогда можно будет использовать его как стандартное решение.
👍32🤮6❤4💯4🔥2
Ремесло или магия?
Все, кто в школе хоть немного учил историю должны знать историю ремесленничества, когда люди, обладающие определенными знаниями и умениями, объединялись в цеха как для защиты от конкуренции, так и для сохранения и преумножения знаний.
Цеха имели трехуровневую структуру: ученик – подмастерье – мастер. Причем чтобы стать последним, нужно было пройти своеобразный экзамен: собственноручно выполнить работу, которая будет одобрена цехом.
Через какое-то время конкурировать с цехами стало сложно, да, мастер-одиночка тоже мог достигнуть определенных высот, но доходя до всего своим умом и методом проб и ошибок, тогда как цех располагал накопленным объемом знаний и системой их передачи от мастера к ученику.
Причем знания передавались дозировано, более сложные знания передавались после того, как ученик усвоил и научился применять на практике более простые.
Этот принцип перешел в образование, там тоже знания передаются дозированно, чтобы более сложные ложились на базис более простых.
А производственные отношения в целом продолжали цеховые традиции, когда более опытные специалисты передавали свои знания и умения молодым, помогая постигнуть все тонкости профессии.
Но наш век информационной доступности спутал все карты. Сейчас ученик, даже не подмастерье, может спокойно получить рецепты мастера и даже попытаться применить их на практике. Только вот станет ли он от этого мастером? Вряд-ли…
Что отличает мастера от ученика или подмастерья? Знания и опыт. Он знает не только как сделать, но и почему нужно делать именно так, а не иначе. И также он знает в каких случаях надо делать именно так, а в каких случаях делать так, наоборот не надо. Не говоря уже о том, что простые пути не всегда самые верные.
Сегодня сеть дает возможность найти большое количество инструкций «от мастеров» и выбор часто делается по принципу: вот эта инструкция проще и мне больше нравится. Ну а то, что писал эту инструкцию совсем не мастер, а захудалый подмастерье, большинству берущих подобные инструкции неведомо.
Главное, что все быстро, просто и дает желаемый результат. На первый взгляд дает. Потому как уровня знаний, дающих возможность всесторонне оценить решение нет. А настоящий мастер, предлагающий правильное, но излишне сложное решение, представляется некоторым занудой.
Ну что ты там нудишь? Видишь, чего я нашел, тяп-ляп и в продакшен. Дешево и практично.
Прозрение наступает поздно и, иногда, с очень неприятными побочными «эффектами».
И иногда думаешь, что правы были цеховые мастера прошлых лет, ибо известно, что многие знания – многие печали, особенно если они достались неокрепшим умам.
Может кто-то посчитает это за профессиональный снобизм, но знания не должны опережать текущий уровень подготовки.
Раньше с этим было попроще, неподготовленного специалиста никто бы не пустил на участок, явно превышающий его квалификацию.
Теперь же есть сеть, в которой можно найти пошаговое описание обрядов и заклинаний, которые, при их тщательном исполнении дадут желаемый результат.
Ну, и как положено настоящей магии, начали появляться различные волшебные артефакты, которые активируются волшебным словом
Таким образом ремесло начинает деградировать до волшебства. А далее знания незаметно уступят обрядам и поклонениям высшим силам. И возникнет новая каста жрецов – редких представителей рода человеческого, которые знают, как это все работает и умеющих находит общий язык с «высшими силами», ну или диктовать их волю «простым смертным» к собственной выгоде.
Возможно, я где-то сгустил краски, но в целом тенденция именно такая. Сегодня уже каждый может стать «мастером» найдя и повторив дословно нужный рецепт. А так как знаний от этого не прибавится, то система будет восприниматься некоторым «волшебным» черным ящиком.
Откуда уже недалеко до настоящих черных ящиков – готовых контейнеров. Да и пес его знает, что там внутри, главное же - слушаются заклинаний...
Все, кто в школе хоть немного учил историю должны знать историю ремесленничества, когда люди, обладающие определенными знаниями и умениями, объединялись в цеха как для защиты от конкуренции, так и для сохранения и преумножения знаний.
Цеха имели трехуровневую структуру: ученик – подмастерье – мастер. Причем чтобы стать последним, нужно было пройти своеобразный экзамен: собственноручно выполнить работу, которая будет одобрена цехом.
Через какое-то время конкурировать с цехами стало сложно, да, мастер-одиночка тоже мог достигнуть определенных высот, но доходя до всего своим умом и методом проб и ошибок, тогда как цех располагал накопленным объемом знаний и системой их передачи от мастера к ученику.
Причем знания передавались дозировано, более сложные знания передавались после того, как ученик усвоил и научился применять на практике более простые.
Этот принцип перешел в образование, там тоже знания передаются дозированно, чтобы более сложные ложились на базис более простых.
А производственные отношения в целом продолжали цеховые традиции, когда более опытные специалисты передавали свои знания и умения молодым, помогая постигнуть все тонкости профессии.
Но наш век информационной доступности спутал все карты. Сейчас ученик, даже не подмастерье, может спокойно получить рецепты мастера и даже попытаться применить их на практике. Только вот станет ли он от этого мастером? Вряд-ли…
Что отличает мастера от ученика или подмастерья? Знания и опыт. Он знает не только как сделать, но и почему нужно делать именно так, а не иначе. И также он знает в каких случаях надо делать именно так, а в каких случаях делать так, наоборот не надо. Не говоря уже о том, что простые пути не всегда самые верные.
Сегодня сеть дает возможность найти большое количество инструкций «от мастеров» и выбор часто делается по принципу: вот эта инструкция проще и мне больше нравится. Ну а то, что писал эту инструкцию совсем не мастер, а захудалый подмастерье, большинству берущих подобные инструкции неведомо.
Главное, что все быстро, просто и дает желаемый результат. На первый взгляд дает. Потому как уровня знаний, дающих возможность всесторонне оценить решение нет. А настоящий мастер, предлагающий правильное, но излишне сложное решение, представляется некоторым занудой.
Ну что ты там нудишь? Видишь, чего я нашел, тяп-ляп и в продакшен. Дешево и практично.
Прозрение наступает поздно и, иногда, с очень неприятными побочными «эффектами».
И иногда думаешь, что правы были цеховые мастера прошлых лет, ибо известно, что многие знания – многие печали, особенно если они достались неокрепшим умам.
Может кто-то посчитает это за профессиональный снобизм, но знания не должны опережать текущий уровень подготовки.
Раньше с этим было попроще, неподготовленного специалиста никто бы не пустил на участок, явно превышающий его квалификацию.
Теперь же есть сеть, в которой можно найти пошаговое описание обрядов и заклинаний, которые, при их тщательном исполнении дадут желаемый результат.
Ну, и как положено настоящей магии, начали появляться различные волшебные артефакты, которые активируются волшебным словом
docker run. Как они работают – неизвестно, да и не нужно. Что-то пошло не так? Убиваем артефакт и активируем новый. Таким образом ремесло начинает деградировать до волшебства. А далее знания незаметно уступят обрядам и поклонениям высшим силам. И возникнет новая каста жрецов – редких представителей рода человеческого, которые знают, как это все работает и умеющих находит общий язык с «высшими силами», ну или диктовать их волю «простым смертным» к собственной выгоде.
Возможно, я где-то сгустил краски, но в целом тенденция именно такая. Сегодня уже каждый может стать «мастером» найдя и повторив дословно нужный рецепт. А так как знаний от этого не прибавится, то система будет восприниматься некоторым «волшебным» черным ящиком.
Откуда уже недалеко до настоящих черных ящиков – готовых контейнеров. Да и пес его знает, что там внутри, главное же - слушаются заклинаний...
💯40👍12🔥9🤮2👎1
Аппаратные часы и системное время
Время – важный параметр современных систем, так как временная метка является одной из переменных в криптографических преобразованиях и отклонение системного времени от точного может привести к различным проблемам.
Но есть и еще один тонкий момент – аппаратные часы – RTC (Real Time Clock), они же часы CMOS / BIOS.
Они отличаются от системных часов, полностью программных, тем, что являются аппаратными и идут даже тогда, когда компьютер выключен. При загрузке система считывает данные аппаратных часов и принимает их за системное время, после чего начинают работать системные часы.
Системные часы мы можем подвести от часов точного времени благодаря протоколу NTP, тем самым обеспечив соответствие системного времени точному. Затем, при выключении (либо можно выполнить эту операцию вручную), система подводит аппаратные часы на материнской плате.
И вот тут возникает ряд тонкостей. Linux считает, что аппаратные часы показывают время UTC (универсальное время, оно же по Гринвичу). Т.е. если в системе мы установили часовой пояс UTC +3 (Москва) и на часах у нас 15:00, то система установит аппаратные часы на 12:00.
Windows же считает что аппаратные часы идут в поясном времени, т.е. если у нас в системе стоит тот же часовой пояс UTC +3 и на часах 15:00, то и в аппаратные часы будет записано такое-же время.
Это вызывало многочисленные приключения при использовании двойной загрузки Linux и Windows на ПК. Но, казалось бы, те времена давно прошли.
Да, сегодня двойная загрузка проходит по разряду экзотики, но на смену ей пришла виртуализация. Многие системы виртуализации поддерживают синхронизацию времени между виртуальной машиной и гипервизором, а службы синхронизации внутри виртуальной машины отключаются, обнаружив себя в виртуалке.
И вот тут начинаются чудеса. Хост отдает виртуалке время как RTC, при этом отдает согласно собственному пониманию. Т.е. хост на Linux отдаст UTC, а хост Windows – поясное время.
В первом случае Linux-гость правильно прибавит к этому значению поясное время и получит правильное значение, а вот Windows будет считать время локальным и будет отставать (или спешить) на разницу между часовым поясом и UTC.
Во втором Windows-гость покажет правильное время, а Linux добавит к нему смещение часового пояса и будет спешить или отставать.
В большинстве случаев это решается в настройках параметров виртуальной машины, но иногда может потребоваться и ручное вмешательство.
Для того чтобы Windows использовал аппаратные часы как UTC выполните:
В Linux для переключения на поясное время и обратно используйте:
Время – важный параметр современных систем, так как временная метка является одной из переменных в криптографических преобразованиях и отклонение системного времени от точного может привести к различным проблемам.
Но есть и еще один тонкий момент – аппаратные часы – RTC (Real Time Clock), они же часы CMOS / BIOS.
Они отличаются от системных часов, полностью программных, тем, что являются аппаратными и идут даже тогда, когда компьютер выключен. При загрузке система считывает данные аппаратных часов и принимает их за системное время, после чего начинают работать системные часы.
Системные часы мы можем подвести от часов точного времени благодаря протоколу NTP, тем самым обеспечив соответствие системного времени точному. Затем, при выключении (либо можно выполнить эту операцию вручную), система подводит аппаратные часы на материнской плате.
И вот тут возникает ряд тонкостей. Linux считает, что аппаратные часы показывают время UTC (универсальное время, оно же по Гринвичу). Т.е. если в системе мы установили часовой пояс UTC +3 (Москва) и на часах у нас 15:00, то система установит аппаратные часы на 12:00.
Windows же считает что аппаратные часы идут в поясном времени, т.е. если у нас в системе стоит тот же часовой пояс UTC +3 и на часах 15:00, то и в аппаратные часы будет записано такое-же время.
Это вызывало многочисленные приключения при использовании двойной загрузки Linux и Windows на ПК. Но, казалось бы, те времена давно прошли.
Да, сегодня двойная загрузка проходит по разряду экзотики, но на смену ей пришла виртуализация. Многие системы виртуализации поддерживают синхронизацию времени между виртуальной машиной и гипервизором, а службы синхронизации внутри виртуальной машины отключаются, обнаружив себя в виртуалке.
И вот тут начинаются чудеса. Хост отдает виртуалке время как RTC, при этом отдает согласно собственному пониманию. Т.е. хост на Linux отдаст UTC, а хост Windows – поясное время.
В первом случае Linux-гость правильно прибавит к этому значению поясное время и получит правильное значение, а вот Windows будет считать время локальным и будет отставать (или спешить) на разницу между часовым поясом и UTC.
Во втором Windows-гость покажет правильное время, а Linux добавит к нему смещение часового пояса и будет спешить или отставать.
В большинстве случаев это решается в настройках параметров виртуальной машины, но иногда может потребоваться и ручное вмешательство.
Для того чтобы Windows использовал аппаратные часы как UTC выполните:
reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /d 1 /t REG_DWORD /f
Чтобы переключиться назад просто удалите этот ключ в реестре.В Linux для переключения на поясное время и обратно используйте:
timedatectl set-local-rtc 1
и timedatectl set-local-rtc 0
Ну и в любом непонятном случае с часами всегда начинайте с того, в каком режиме идут RTC и в каком режиме его воспринимает система.
👍51❤10🔥4
Как скачать DEB-пакет со всеми зависимостями
Необходимость скачать DEB-пакет со всеми зависимостями для дальнейшей локальной установки возникает не так уж и редко. Это могут быть закрытые системы или системы с невысокой скоростью связи или лимитированным трафиком.
Сделать это весьма просто, причем без всякой особой консольной магии, с использованием штатных возможностей apt.
Все скачанные пакеты система размещает в каталоге
После чего перейдем к скачиванию:
Почему именно
Если вам нужны пакеты другой архитектуры, то ее сначала нужно включить и обновить список пакетов:
После чего точно также делаем:
После чего переходим в
Необходимость скачать DEB-пакет со всеми зависимостями для дальнейшей локальной установки возникает не так уж и редко. Это могут быть закрытые системы или системы с невысокой скоростью связи или лимитированным трафиком.
Сделать это весьма просто, причем без всякой особой консольной магии, с использованием штатных возможностей apt.
Все скачанные пакеты система размещает в каталоге
/var/cache/apt/archives и там, кроме интересующих нас пакетов могут быть и разные другие, поэтому перед скачиванием нужно будет очистить кеш пакетов.apt clean
После чего перейдем к скачиванию:
apt reinstall --download-only package_name
Почему именно
reinstall? Потому что install будет работать только для неустановленных пакетов, а если пакет уже установлен в системе, то она сообщит об этом и не будет производить установку (в нашем случае скачивание, а reinstall скачает пакеты в любом случае.Если вам нужны пакеты другой архитектуры, то ее сначала нужно включить и обновить список пакетов:
dpkg --add-architecture i386
apt update
После чего точно также делаем:
apt reinstall --download-only package_name:i386
После чего переходим в
/var/cache/apt/archives и копируем скачанные пакеты на любой съемный носитель и может передать их любым удобным способом в нужную систему для установки.
👍56❤7
Субботнее, о «братьях» наших меньших
Читаю тут время от времени соседские новости и наблюдаю привычную многим картину: террор (а по-другому я тут не скажу) бродячих собак по отношению к местному населению и их питомцам.
Выше два ролика из города Курска, где стая агрессивно атакует домашних питомцев и их хозяев. Но это еще не беда, это ее половина, настоящая беда в отношении местной власти к данной проблеме. Ответ администрации просто убивает, выделение мое:
«28.05.2025г. по адресу: г. Курск, ул. Майский бульвар, д. 27 был осуществлен выезд сотрудников подрядной организации. Отловлена одна собака, а так же установлено наличие собак с метками. В соответствии с действующим Федеральным законом от 27.12.2018г. № 498-ФЗ, животные имеющие, метки отлову не подлежат».
Отлично? Да просто зашибись! Поймали, стерилизовали, повесили бирку и отпустили, где взяли. А бирка, по мнению данных товарищей, сразу сделает собаку доброй и пушистой.
Но собака, как бы не хотелось некоторым отрицать данный факт – стайный хищник, с многовековыми инстинктами на подкорке, которые не вытравливаются оттуда не стерилизацией, ни биркой.
И если собака с биркой в единственном экземпляре может быть доброй, ласковой и пушистой, то в стае – это хищник, машина для убийства. Но на это старательно закрывают глаза.
А если человек, исключительно в целях самообороны, возьмет хороший дрын и нанесет собаченьке увечья несовместимые с нормальной жизнедеятельностью организма, то ему грозит вполне реальное административное или даже уголовное наказание.
И вот здесь логика происходящего от меня полностью ускользает. Бродячая собака может изувечить или вообще убить вашего домашнего питомца, и никто за это отвечать не будет. Может нанести увечья и даже убить человека, ответственность за это снова никто не понесет. Проверено неоднократными случаями. Особенно если у собак есть метка.
Если же человек нанесет увечья или, не приведи Господь, прибьет собаченьку – то проблемы ему гарантированы.
Хотя, по логике вещей, если собака – дикий зверь, а бродячая собака – это именно дикий зверь, угрожает жизни и здоровью человека, то такая собака должна быть ликвидирована, просто и без затей.
Представителям зоошизы, у которых все собаченьки добрые и пушистые, а нападают они только в ответ на агрессию человека, могу предложить забрать таких собак себе домой или просто заткнуть рты и помолчать.
Так вот любой дикий зверь, проявляющий агрессию на человека в его естественной среде обитания (городе, селе – не важно), должен быть быстро и без затей ликвидирован.
Бродячая собака – это именно дикий зверь, далеко не в первом поколении. Выброшенные собаки долго на улице не живут они или не переживают зиму, или становятся жертвами бродячих стай. Так что перекладывать ответственность на человека тут тоже не следует.
Но у нас почему-то существует необъяснимый перекос, когда жизнь и здоровье человека ничего не значит против жизни и здоровья собаки, которая оказывается защищена законом гораздо лучше гражданина и налогоплательщика.
Такой вот парадокс, а вы что думаете по этому поводу?
Читаю тут время от времени соседские новости и наблюдаю привычную многим картину: террор (а по-другому я тут не скажу) бродячих собак по отношению к местному населению и их питомцам.
Выше два ролика из города Курска, где стая агрессивно атакует домашних питомцев и их хозяев. Но это еще не беда, это ее половина, настоящая беда в отношении местной власти к данной проблеме. Ответ администрации просто убивает, выделение мое:
«28.05.2025г. по адресу: г. Курск, ул. Майский бульвар, д. 27 был осуществлен выезд сотрудников подрядной организации. Отловлена одна собака, а так же установлено наличие собак с метками. В соответствии с действующим Федеральным законом от 27.12.2018г. № 498-ФЗ, животные имеющие, метки отлову не подлежат».
Отлично? Да просто зашибись! Поймали, стерилизовали, повесили бирку и отпустили, где взяли. А бирка, по мнению данных товарищей, сразу сделает собаку доброй и пушистой.
Но собака, как бы не хотелось некоторым отрицать данный факт – стайный хищник, с многовековыми инстинктами на подкорке, которые не вытравливаются оттуда не стерилизацией, ни биркой.
И если собака с биркой в единственном экземпляре может быть доброй, ласковой и пушистой, то в стае – это хищник, машина для убийства. Но на это старательно закрывают глаза.
А если человек, исключительно в целях самообороны, возьмет хороший дрын и нанесет собаченьке увечья несовместимые с нормальной жизнедеятельностью организма, то ему грозит вполне реальное административное или даже уголовное наказание.
И вот здесь логика происходящего от меня полностью ускользает. Бродячая собака может изувечить или вообще убить вашего домашнего питомца, и никто за это отвечать не будет. Может нанести увечья и даже убить человека, ответственность за это снова никто не понесет. Проверено неоднократными случаями. Особенно если у собак есть метка.
Если же человек нанесет увечья или, не приведи Господь, прибьет собаченьку – то проблемы ему гарантированы.
Хотя, по логике вещей, если собака – дикий зверь, а бродячая собака – это именно дикий зверь, угрожает жизни и здоровью человека, то такая собака должна быть ликвидирована, просто и без затей.
Представителям зоошизы, у которых все собаченьки добрые и пушистые, а нападают они только в ответ на агрессию человека, могу предложить забрать таких собак себе домой или просто заткнуть рты и помолчать.
Так вот любой дикий зверь, проявляющий агрессию на человека в его естественной среде обитания (городе, селе – не важно), должен быть быстро и без затей ликвидирован.
Бродячая собака – это именно дикий зверь, далеко не в первом поколении. Выброшенные собаки долго на улице не живут они или не переживают зиму, или становятся жертвами бродячих стай. Так что перекладывать ответственность на человека тут тоже не следует.
Но у нас почему-то существует необъяснимый перекос, когда жизнь и здоровье человека ничего не значит против жизни и здоровья собаки, которая оказывается защищена законом гораздо лучше гражданина и налогоплательщика.
Такой вот парадокс, а вы что думаете по этому поводу?
💯74👍12👎6🤡5🤔3
Версии PowerShell
PowerShell активно используется Windows-администраторами для автоматизации и написания скриптов, но далеко не все правильно ориентируются в версиях и выпусках PowerShell, поэтому сегодня разберем этот вопрос подробнее.
На сегодняшний день существуют две версии PowerShell:
🔹 Windows PowerShell – основан на .NET Framework, существует только для Windows, предустановлен начиная с Windows Server 2008 R2 и Windows 7. В настоящий момент не развивается, последний выпуск – 5.1
🔹 PowerShell Core – основан на .NET Core, является кроссплатформенным ПО с открытым исходным кодом, может быть установлен в Windows, Linux и macOS. В PowerShell Core нет полной совместимости с Windows PowerShell, однако для выпуска PowerShell Core 7.х разработчиками заявлена максимальная совместимость.
Windows PowerShell имеет следующие выпуски:
▫️ PowerShell 1.0 – предназначен для ручной установки начиная с Windows Server 2003 SP1 и Windows XP
▫️ PowerShell 2.0 – предустановлен в Windows Server 2008 R2 и Windows 7
▫️ PowerShell 3.0 – предустановлен в Windows Server 2012 и Windows 8
▫️ PowerShell 4.0 – предустановлен в Windows Server 2012 R2 и Windows 8.1
▫️ PowerShell 5.0 – предустановлен в Windows 10 ранних выпусков, автоматически обновляется до 5.1
▫️ PowerShell 5.1 – предустановлен начиная с Windows Server 2016 и Windows 10 1709
В настоящий момент Windows PowerShell не развивается и рекомендуется переход на PowerShell Core.
PowerShell Core имеет следующие выпуски:
▫️ PowerShell Core 6.х на базе .NET Core 2.x, имеет неполную обратную совместимость с Windows PowerShell
▫️ PowerShell Core 7.х на базе .NET Core 3.x, заявлена максимальная обратная совместимость, при этом рекомендуется протестировать работу старых скриптов.
PowerShell Core можно получить с официальной страницы на Github, через WinGet или из магазина Windows.
Для обновления Windows PowerShell вам потребуется установить Windows Management Framework (WMF) соответствующей версии и связанный с ним пакет .NET Framework. Если вы обновите WMF, но не установите новый .NET Framework, то часть функций PowerShell может отказаться работать.
Также следует помнить, что среда разработки PowerShell ISE предназначена только для Windows PowerShell, для работы с PowerShell Core следует использовать Visual Studio Code.
PowerShell активно используется Windows-администраторами для автоматизации и написания скриптов, но далеко не все правильно ориентируются в версиях и выпусках PowerShell, поэтому сегодня разберем этот вопрос подробнее.
На сегодняшний день существуют две версии PowerShell:
🔹 Windows PowerShell – основан на .NET Framework, существует только для Windows, предустановлен начиная с Windows Server 2008 R2 и Windows 7. В настоящий момент не развивается, последний выпуск – 5.1
🔹 PowerShell Core – основан на .NET Core, является кроссплатформенным ПО с открытым исходным кодом, может быть установлен в Windows, Linux и macOS. В PowerShell Core нет полной совместимости с Windows PowerShell, однако для выпуска PowerShell Core 7.х разработчиками заявлена максимальная совместимость.
Windows PowerShell имеет следующие выпуски:
▫️ PowerShell 1.0 – предназначен для ручной установки начиная с Windows Server 2003 SP1 и Windows XP
▫️ PowerShell 2.0 – предустановлен в Windows Server 2008 R2 и Windows 7
▫️ PowerShell 3.0 – предустановлен в Windows Server 2012 и Windows 8
▫️ PowerShell 4.0 – предустановлен в Windows Server 2012 R2 и Windows 8.1
▫️ PowerShell 5.0 – предустановлен в Windows 10 ранних выпусков, автоматически обновляется до 5.1
▫️ PowerShell 5.1 – предустановлен начиная с Windows Server 2016 и Windows 10 1709
В настоящий момент Windows PowerShell не развивается и рекомендуется переход на PowerShell Core.
PowerShell Core имеет следующие выпуски:
▫️ PowerShell Core 6.х на базе .NET Core 2.x, имеет неполную обратную совместимость с Windows PowerShell
▫️ PowerShell Core 7.х на базе .NET Core 3.x, заявлена максимальная обратная совместимость, при этом рекомендуется протестировать работу старых скриптов.
PowerShell Core можно получить с официальной страницы на Github, через WinGet или из магазина Windows.
Для обновления Windows PowerShell вам потребуется установить Windows Management Framework (WMF) соответствующей версии и связанный с ним пакет .NET Framework. Если вы обновите WMF, но не установите новый .NET Framework, то часть функций PowerShell может отказаться работать.
Также следует помнить, что среда разработки PowerShell ISE предназначена только для Windows PowerShell, для работы с PowerShell Core следует использовать Visual Studio Code.
❤18🫡9🥱4👀4🔥2
SMART атрибуты NVMe дисков
Если SATA SSD имели набор атрибутов SMART унаследованный от жестких дисков, многие из которых были бесполезны и не отражали реального состояния устройства, то NVMe диски получили обновленный набор атрибутов, разработанный как раз с учетом специфики устройств.
Ниже будем указывать атрибуты в форме ID Наименование RU (Наименование EN)
🔹 01 Критические предупреждения (Critical Warning) – флаг, указывающий на критические состояния накопителя, не является статическим, может изменять состояние динамически, возможные значения:
▫️
▫️
▫️
▫️
▫️
🔹 02 Температура всего устройства (Composite Temperature) – средняя температура накопителя в градусах Кельвина, для перевода в градусы Цельсия необходимо вычесть из значения 273.15. Рекомендации о порогах температур задаются именно для этого значения.
🔹 03 Доступно резервных блоков (Available Spare) – процент оставшихся резервных блоков, в норме 100 и это значение будет уменьшаться
🔹 04 Критический остаток резервных блоков (Available Spare Threshold) - при падении запаса ниже указанного значения для этого поля контроллером будет сформировано событие.
🔹 05 Процент износа (Percentage Used) - показывает процент износа устройства согласно указанного производителем ресурса, 100% обозначает полный износ, значение может превышать 100, максимальное значение 255.
🔹 06 Всего прочитано данных (Data Units Read) - количество прочитанных блоков по 512 байт, единица означает тысячу прочитанных блоков.
🔹 07 Всего записано данных (Data Units Written) - количество записанных блоков по 512 байт, единица означает тысячу записанных блоков.
🔹 08 Количество команд чтения (Host Read Commands) – количество команд чтения, выполненных контролером.
🔹 09 Количество команд записи (Host Write Commands) – количество команд записи, выполненных контроллером
🔹 10 Время занятости контроллера (Controller Busy Time) – время, которое контроллер обрабатывал команды ввода-вывода или когда в очереди находились запросы. Значение представлены в минутах.
🔹 11 Количество включений питания (Power Cycles) – счетчик включений накопителя
🔹 12 Количество отработанных часов (Power On Hours) – общее время работы накопителя в часах, учитывается также время нахождения в режимах энергосбережения
🔹 13 Небезопасных выключений (Unsafe Shutdowns) – количество выключений, когда питания накопителя было отключено прежде, чем он получил от системы уведомление о выключении питания
🔹 14 Количество неисправимых ошибок (Media and Data Integrity Errors) – счетчик неисправимых ошибок ECC, вычисления контрольных сумм CRC или несоответствия LBA
🔹 15 Записей об ошибках в журнал (Number of Error Information Log Entries) – количество записей об ошибках, произведенных в журнал контроллера
🔹 16 Время работы при высокой температуре (Warning Composite Temperature Time) – время, в минутах, которое накопитель работал с превышением порога температуры
🔹 17 Время работы при критической температуре (Critical Composite Temperature Time) - время, в минутах, которое накопитель работал с превышением критического порога температуры
🔹 18 Термодатчик 1 (Temperature Sensor 1) – первый сенсор температуры, точно узнать размещение сенсора можно только из описания диска, чаще всего контроллер.
🔹 19 Термодатчик 2 (Temperature Sensor 2) – второй сенсор температуры, точно узнать размещение сенсора можно только из описания диска, чаще всего NAND.
Если SATA SSD имели набор атрибутов SMART унаследованный от жестких дисков, многие из которых были бесполезны и не отражали реального состояния устройства, то NVMe диски получили обновленный набор атрибутов, разработанный как раз с учетом специфики устройств.
Ниже будем указывать атрибуты в форме ID Наименование RU (Наименование EN)
🔹 01 Критические предупреждения (Critical Warning) – флаг, указывающий на критические состояния накопителя, не является статическим, может изменять состояние динамически, возможные значения:
▫️
0x01 – доступное свободное пространство упало ниже порогового значения▫️
0x02 – температура вышла за пороговые значения (как вверх, так и вниз)▫️
0x03 - надежность подсистемы NVM ухудшилась из-за значительных проблем, связанных со средой передачи данных, включая ошибки, снижающие надежность подсистемы NVM ▫️
0x04 – накопитель перешел в режим только чтения▫️
0x08 – устройство энергозависимой памяти (DRAM) вышло из строя 🔹 02 Температура всего устройства (Composite Temperature) – средняя температура накопителя в градусах Кельвина, для перевода в градусы Цельсия необходимо вычесть из значения 273.15. Рекомендации о порогах температур задаются именно для этого значения.
🔹 03 Доступно резервных блоков (Available Spare) – процент оставшихся резервных блоков, в норме 100 и это значение будет уменьшаться
🔹 04 Критический остаток резервных блоков (Available Spare Threshold) - при падении запаса ниже указанного значения для этого поля контроллером будет сформировано событие.
🔹 05 Процент износа (Percentage Used) - показывает процент износа устройства согласно указанного производителем ресурса, 100% обозначает полный износ, значение может превышать 100, максимальное значение 255.
🔹 06 Всего прочитано данных (Data Units Read) - количество прочитанных блоков по 512 байт, единица означает тысячу прочитанных блоков.
🔹 07 Всего записано данных (Data Units Written) - количество записанных блоков по 512 байт, единица означает тысячу записанных блоков.
🔹 08 Количество команд чтения (Host Read Commands) – количество команд чтения, выполненных контролером.
🔹 09 Количество команд записи (Host Write Commands) – количество команд записи, выполненных контроллером
🔹 10 Время занятости контроллера (Controller Busy Time) – время, которое контроллер обрабатывал команды ввода-вывода или когда в очереди находились запросы. Значение представлены в минутах.
🔹 11 Количество включений питания (Power Cycles) – счетчик включений накопителя
🔹 12 Количество отработанных часов (Power On Hours) – общее время работы накопителя в часах, учитывается также время нахождения в режимах энергосбережения
🔹 13 Небезопасных выключений (Unsafe Shutdowns) – количество выключений, когда питания накопителя было отключено прежде, чем он получил от системы уведомление о выключении питания
🔹 14 Количество неисправимых ошибок (Media and Data Integrity Errors) – счетчик неисправимых ошибок ECC, вычисления контрольных сумм CRC или несоответствия LBA
🔹 15 Записей об ошибках в журнал (Number of Error Information Log Entries) – количество записей об ошибках, произведенных в журнал контроллера
🔹 16 Время работы при высокой температуре (Warning Composite Temperature Time) – время, в минутах, которое накопитель работал с превышением порога температуры
🔹 17 Время работы при критической температуре (Critical Composite Temperature Time) - время, в минутах, которое накопитель работал с превышением критического порога температуры
🔹 18 Термодатчик 1 (Temperature Sensor 1) – первый сенсор температуры, точно узнать размещение сенсора можно только из описания диска, чаще всего контроллер.
🔹 19 Термодатчик 2 (Temperature Sensor 2) – второй сенсор температуры, точно узнать размещение сенсора можно только из описания диска, чаще всего NAND.
👍55🔥13❤7
Что такое PowerShell и чем он отличается от своих аналогов
Практически после каждой нашей публикации PowerShell появлются негативные комментарии или вообще агрессивное отрицание данного продукта. Что довольно неожиданно, игнорировать столь мощный инструмент – идея далеко не самая лучшая.
Возможно, что не все до конца представляют, чем является из себе PowerShell и чем он отличается от своих аналогов.
Начнем с небольшого экскурса в историю. Для обеспечения интерфейса командной строки были придуманы командные интерпретаторы, которые представляли собой скриптовые языки с определенным набором возможностей.
Впервые они были заданы в стандарте POSIX (ISO/IEC 9945) (Том 3. Оболочка и утилиты) , который предписывал языкам оболочки иметь конструкции последовательного, условного и циклического исполнения команд, а также оператор присваивания.
К таким языкам до сих пор относятся bash и аналоги, а также CMD. Несмотря на различные возможности – это все типичные скриптовые языки оболочки. Со своими типичными возможностями и ограничениями.
Одной из характерных особенностей этих языков является текстовый интерфейс взаимодействия, что вынуждает при анализе и обработке результата прибегать к сериализации или парсингу.
Я думаю, что любой, кто писал сложные скрипты на том же bash с этим сталкивался. Поэтому при определенном уровне сложности многие начинают переходить на скриптовые языки общего назначения с объектной моделью, например, Python.
Основное отличие объекта от текста в том, что объект имеет свои свойства и методы, к которым мы можем обращаться без всякого парсинга просто зная их наименование. Например, чтобы посмотреть условный статус объекта нам достаточно прочитать свойство Объект.Статус.
Это весьма грубая и упрощенная модель, но достаточная для базового понимания сути.
Так вот, при разработке PowerShell было принято решение реализовать в нем объектную модель. Таким образом PowerShell, хоть и является языком оболочки, но по функциональным возможностям гораздо ближе к скриптовым языкам общего назначения, таким как Python.
Это же наложило отпечаток и на его синтаксис, он также сильно отличается от синтаксиса языков оболочек и гораздо ближе к обычным языкам программирования.
И этот момент вызывает у многих недоумение, так как PowerShell является одной из оболочек командной строки и языком этой оболочки. А отличительная особенность языков оболочек – это короткие команды, которые легко запомнить и быстро вводить.
Но у этой медали есть и обратная сторона. Скрипты на таких языках очень трудно читаются, особенно если вы не помните наизусть всех команд и их ключей. Очень часто код приходится читать буквально «со словарем».
В PowerShell решили подойти с другой стороны и его синтаксис позволяет читать скрипты буквально налету, понимая, что они делают без обращения к документации. При написании скриптов это также не вызывает сложности благодаря возможностям сред разработки.
При этом мы согласимся с тем, что для повседневного администрирования синтаксис PowerShell неудобен и многословен, однако он поддерживает алиасы, позволяющие работать в привычном коротком, но практически нечитабельном, синтаксисе.
Что касается порога входа в PowerShell, то он тоже гораздо выше, на уровне скриптовых языков, но его изучение того стоит, так как открывает гораздо более широкие возможности по взаимодействию с системой, особенно учитывая глубокую интеграцию в нее посредством .NET.
Практически после каждой нашей публикации PowerShell появлются негативные комментарии или вообще агрессивное отрицание данного продукта. Что довольно неожиданно, игнорировать столь мощный инструмент – идея далеко не самая лучшая.
Возможно, что не все до конца представляют, чем является из себе PowerShell и чем он отличается от своих аналогов.
Начнем с небольшого экскурса в историю. Для обеспечения интерфейса командной строки были придуманы командные интерпретаторы, которые представляли собой скриптовые языки с определенным набором возможностей.
Впервые они были заданы в стандарте POSIX (ISO/IEC 9945) (Том 3. Оболочка и утилиты) , который предписывал языкам оболочки иметь конструкции последовательного, условного и циклического исполнения команд, а также оператор присваивания.
К таким языкам до сих пор относятся bash и аналоги, а также CMD. Несмотря на различные возможности – это все типичные скриптовые языки оболочки. Со своими типичными возможностями и ограничениями.
Одной из характерных особенностей этих языков является текстовый интерфейс взаимодействия, что вынуждает при анализе и обработке результата прибегать к сериализации или парсингу.
Я думаю, что любой, кто писал сложные скрипты на том же bash с этим сталкивался. Поэтому при определенном уровне сложности многие начинают переходить на скриптовые языки общего назначения с объектной моделью, например, Python.
Основное отличие объекта от текста в том, что объект имеет свои свойства и методы, к которым мы можем обращаться без всякого парсинга просто зная их наименование. Например, чтобы посмотреть условный статус объекта нам достаточно прочитать свойство Объект.Статус.
Это весьма грубая и упрощенная модель, но достаточная для базового понимания сути.
Так вот, при разработке PowerShell было принято решение реализовать в нем объектную модель. Таким образом PowerShell, хоть и является языком оболочки, но по функциональным возможностям гораздо ближе к скриптовым языкам общего назначения, таким как Python.
Это же наложило отпечаток и на его синтаксис, он также сильно отличается от синтаксиса языков оболочек и гораздо ближе к обычным языкам программирования.
И этот момент вызывает у многих недоумение, так как PowerShell является одной из оболочек командной строки и языком этой оболочки. А отличительная особенность языков оболочек – это короткие команды, которые легко запомнить и быстро вводить.
Но у этой медали есть и обратная сторона. Скрипты на таких языках очень трудно читаются, особенно если вы не помните наизусть всех команд и их ключей. Очень часто код приходится читать буквально «со словарем».
В PowerShell решили подойти с другой стороны и его синтаксис позволяет читать скрипты буквально налету, понимая, что они делают без обращения к документации. При написании скриптов это также не вызывает сложности благодаря возможностям сред разработки.
При этом мы согласимся с тем, что для повседневного администрирования синтаксис PowerShell неудобен и многословен, однако он поддерживает алиасы, позволяющие работать в привычном коротком, но практически нечитабельном, синтаксисе.
Что касается порога входа в PowerShell, то он тоже гораздо выше, на уровне скриптовых языков, но его изучение того стоит, так как открывает гораздо более широкие возможности по взаимодействию с системой, особенно учитывая глубокую интеграцию в нее посредством .NET.
👍30👀3🔥2❤1😱1
Как создать копию драйверов текущего ПК не прибегая к сторонним инструментам
Задача по сохранению текущего набора драйверов является достаточно актуальной, скажем при переустановке системы, особенно если у вас портативное устройство с многочисленным количеством датчиков и дополнительных устройств.
Для этих задач есть специализированные утилиты, которые можно найти на просторах сети интернет, но не нужно ничего искать, система сама прекрасно справляется с данным вопросом.
Начнем с PowerShell, для выполнения данной задачи выполните с правами Администратора:
Кроме PowerShell вы также можете использовать DISM:
Или pnputil, что актуально для старых систем, начиная с Windows 7:
Все три команды дадут одинаковый результат, все драйвера текущей машины будут скопированы в указанную папку (должна существовать на момент экспорта) с разбитием по подпапкам по числу драйверов.
Далее можете делать с ними все что хотите: использовать как резервную копию, внедрить в образ или выборочно забрать нужные драйвера.
Задача по сохранению текущего набора драйверов является достаточно актуальной, скажем при переустановке системы, особенно если у вас портативное устройство с многочисленным количеством датчиков и дополнительных устройств.
Для этих задач есть специализированные утилиты, которые можно найти на просторах сети интернет, но не нужно ничего искать, система сама прекрасно справляется с данным вопросом.
Начнем с PowerShell, для выполнения данной задачи выполните с правами Администратора:
Export-WindowsDriver —Online —Destination F:\Drivers
Кроме PowerShell вы также можете использовать DISM:
dism /online /export-driver /destination: F:\Drivers
Или pnputil, что актуально для старых систем, начиная с Windows 7:
pnputil.exe /export-driver * F:\Drivers
Все три команды дадут одинаковый результат, все драйвера текущей машины будут скопированы в указанную папку (должна существовать на момент экспорта) с разбитием по подпапкам по числу драйверов.
Далее можете делать с ними все что хотите: использовать как резервную копию, внедрить в образ или выборочно забрать нужные драйвера.
👍101❤10⚡5🔥2
Используем ImDisk для эмуляции флешек и других типов накопителей
Современный мир все больше и больше переходит к использованию онлайн-хранилищ и привычные типы физических накопителей потихоньку становятся историей.
При этом необходимость их использования все еще остается, а некоторый специализированный софт может прямо требовать наличие физического накопителя. Но это не всегда возможно, например, в виртуальных средах или на удаленных системах. В этом случае нам на помощь придут эмуляторы.
В данной статье мы рассмотрим работу с ImDisk - простым и мощным решением для работы с виртуальными накопителями.
https://interface31.ru/tech_it/2024/05/ispol-zuem-imdisk-dlya-emulyacii-fleshek-i-drugih-tipov-nakopiteley.html
Современный мир все больше и больше переходит к использованию онлайн-хранилищ и привычные типы физических накопителей потихоньку становятся историей.
При этом необходимость их использования все еще остается, а некоторый специализированный софт может прямо требовать наличие физического накопителя. Но это не всегда возможно, например, в виртуальных средах или на удаленных системах. В этом случае нам на помощь придут эмуляторы.
В данной статье мы рассмотрим работу с ImDisk - простым и мощным решением для работы с виртуальными накопителями.
https://interface31.ru/tech_it/2024/05/ispol-zuem-imdisk-dlya-emulyacii-fleshek-i-drugih-tipov-nakopiteley.html
1👍38🔥2❤1