Уже было, но вопросы как были, так и остаются, поэтому повторим.
Почему именно systemd?
Практически после каждой нашей заметки о возможностях systemd в комментариях появляются читатели, которые пишут, что мол, а не проще ли это сделать … и далее идет перечисление простых утилит или скриптов.
С одной стороны, они могут показаться в чем-то правы. Зачем нужны все эти юниты, когда можно просто дернуть утилиту, получить результат и обернуть все это в скрипт.
Но это очень узкий и односторонний взгляд. Современные системы очень сложны и требуют стандартизации и унификации средств администрирования.
Вы можете мастерски владеть скриптами и автоматизировать все с их помощью, но ваши коллеги не сильно обрадуются этому факту, если им придется принять у вас обслуживание этой системы. Да и самому элементарно можно забыть, где лежит и для чего нужен тот или иной скрипт, особенно если подробного документирования не производилось.
Поэтому первый плюс systemd – это унификация и стандартизация. Теперь у нас есть юниты: юниты служб, юниты таймеров, юниты путей, юниты монтирования и т.д. и т.п.
Все юниты стандартизованы и научившись работать с одним типом вы без труда освоите другой. Кроме этого, юниты просты, очень просты и не идут ни в какое сравнение со скриптами.
Списки юнитов и их состояние также можно получить централизованно, одной простой командой. А чтобы проверить все возможные задания того же cron вам придется пробежать несколько каталогов, а также проверить crontab.
Второй плюс – это углубленная интеграция в систему, systemd предоставляет множество удобных инструментов, начиная от управления автозагрузкой и заканчивая средствами логирования.
Чтобы посмотреть результат работы скрипта – вам придется самому позаботиться о ведении лога. В systemd все это можно посмотреть «не отходя от кассы», стандартными инструментами. При этом никаких особых усилий к этому прикладывать не придется.
Из этого вытекает еще одно большое преимущество юнитов – их гораздо проще отлаживать. Во-первых, у вас уже есть лог, который ведется автоматически. Во-вторых, юниты предсказуемы и работают одинаково, вне зависимости от того, запущены они вручную или другим юнитом.
В тоже время отлично работающий при интерактивном запуске скрипт может оказаться неработоспособным при вызове через cron или из другого скрипта просто потому, что оказался запущен в другом контексте, с другими переменными окружения.
До сих пор нами были перечислены простые задачи, на которых преимущества systemd, конечно, видны, но еще не раскрыли всех своих возможностей.
Начнем с зависимостей. Как мы уже говорили – современные системы сложны. Многие их компоненты и службы зависят от других служб или предоставляемых ими ресурсов. Например, нам нужно выполнить какое-то задание, но только после того, как поднимется сеть и будут доступны некоторые сетевые ресурсы.
Для традиционного решения этой задачи придется немало поломать голову, выполнить кучу проверок или, как делается чаще всего, пойти по пути костылей и синей изоленты. Скажем, просто поставить задержку, в надежде что за это время сервис, от которого зависит работа успеет подняться. Ну а нет, так нет…
Systemd предоставляет простой и удобный способ работы с зависимостями. При этом вы можете указывать как отдельные службы, так и цели (таргеты), которые составляют группы служб, объединенные по некоторому признаку. Нужна сеть? Просто указываем в зависимостях network.target.
Еще одна важная задача – обработка отказа. Если служба упала – вы можете ее автоматически перезапустить. Но это можно сделать и без systemd, а вот systemd позволяет сделать это грамотно, указав частоту и количество попыток.
Если проблема приняла системный характер или находится на другой стороне, то systemd попробует несколько раз перезапустить службу и прекратит это делать, не получив результата. И это гораздо лучше, чем тупо долбить скриптом, вызывая повышенную нагрузку на систему и сеть.
Размер заметки не дает углубиться в подробности, но даже перечисленное дает исчерпывающий ответ на вопрос: почему именно systemd?
Почему именно systemd?
Практически после каждой нашей заметки о возможностях systemd в комментариях появляются читатели, которые пишут, что мол, а не проще ли это сделать … и далее идет перечисление простых утилит или скриптов.
С одной стороны, они могут показаться в чем-то правы. Зачем нужны все эти юниты, когда можно просто дернуть утилиту, получить результат и обернуть все это в скрипт.
Но это очень узкий и односторонний взгляд. Современные системы очень сложны и требуют стандартизации и унификации средств администрирования.
Вы можете мастерски владеть скриптами и автоматизировать все с их помощью, но ваши коллеги не сильно обрадуются этому факту, если им придется принять у вас обслуживание этой системы. Да и самому элементарно можно забыть, где лежит и для чего нужен тот или иной скрипт, особенно если подробного документирования не производилось.
Поэтому первый плюс systemd – это унификация и стандартизация. Теперь у нас есть юниты: юниты служб, юниты таймеров, юниты путей, юниты монтирования и т.д. и т.п.
Все юниты стандартизованы и научившись работать с одним типом вы без труда освоите другой. Кроме этого, юниты просты, очень просты и не идут ни в какое сравнение со скриптами.
Списки юнитов и их состояние также можно получить централизованно, одной простой командой. А чтобы проверить все возможные задания того же cron вам придется пробежать несколько каталогов, а также проверить crontab.
Второй плюс – это углубленная интеграция в систему, systemd предоставляет множество удобных инструментов, начиная от управления автозагрузкой и заканчивая средствами логирования.
Чтобы посмотреть результат работы скрипта – вам придется самому позаботиться о ведении лога. В systemd все это можно посмотреть «не отходя от кассы», стандартными инструментами. При этом никаких особых усилий к этому прикладывать не придется.
Из этого вытекает еще одно большое преимущество юнитов – их гораздо проще отлаживать. Во-первых, у вас уже есть лог, который ведется автоматически. Во-вторых, юниты предсказуемы и работают одинаково, вне зависимости от того, запущены они вручную или другим юнитом.
В тоже время отлично работающий при интерактивном запуске скрипт может оказаться неработоспособным при вызове через cron или из другого скрипта просто потому, что оказался запущен в другом контексте, с другими переменными окружения.
До сих пор нами были перечислены простые задачи, на которых преимущества systemd, конечно, видны, но еще не раскрыли всех своих возможностей.
Начнем с зависимостей. Как мы уже говорили – современные системы сложны. Многие их компоненты и службы зависят от других служб или предоставляемых ими ресурсов. Например, нам нужно выполнить какое-то задание, но только после того, как поднимется сеть и будут доступны некоторые сетевые ресурсы.
Для традиционного решения этой задачи придется немало поломать голову, выполнить кучу проверок или, как делается чаще всего, пойти по пути костылей и синей изоленты. Скажем, просто поставить задержку, в надежде что за это время сервис, от которого зависит работа успеет подняться. Ну а нет, так нет…
Systemd предоставляет простой и удобный способ работы с зависимостями. При этом вы можете указывать как отдельные службы, так и цели (таргеты), которые составляют группы служб, объединенные по некоторому признаку. Нужна сеть? Просто указываем в зависимостях network.target.
Еще одна важная задача – обработка отказа. Если служба упала – вы можете ее автоматически перезапустить. Но это можно сделать и без systemd, а вот systemd позволяет сделать это грамотно, указав частоту и количество попыток.
Если проблема приняла системный характер или находится на другой стороне, то systemd попробует несколько раз перезапустить службу и прекратит это делать, не получив результата. И это гораздо лучше, чем тупо долбить скриптом, вызывая повышенную нагрузку на систему и сеть.
Размер заметки не дает углубиться в подробности, но даже перечисленное дает исчерпывающий ответ на вопрос: почему именно systemd?
👍24👎3⚡2❤2🤮1
systemd.path – реагируем на события файловой системы
Как мы уже рассказывали systemd предоставляет администраторам простые, но в тоже время мощные инструменты на все случаи жизни.
Сегодня мы рассмотрим еще один тип юнита – path, который предназначен для контроля событий файловой системы. Сейчас он позволяет реагировать на создание, изменение или модификацию файлов или на появление файлов в директории.
Создадим для примера юнит
И внесем в него следующие строки:
В общем и целом, стандартный юнит, ничего необычного, кроме секции
Если секция Path не содержит директивы
Если требуется запуск другой службы, то ее требуется указать явно, т.е.:
Для начала работы юнит нужно запустить и добавить в автозагрузку:
Или одной командой:
В секции
Для отслеживания событий можно использовать следующие директивы:
▫️
▫️
▫️
▫️
▫️
Дополнительно с последней можно использовать:
▫️
Еще две опции позволяют задать временные лимиты срабатывания.
▫️
Отдельно следует отметить, что systemd.path работает только с локальными файловыми системами и не будет работать с SMB или NFS.
Как мы уже рассказывали systemd предоставляет администраторам простые, но в тоже время мощные инструменты на все случаи жизни.
Сегодня мы рассмотрим еще один тип юнита – path, который предназначен для контроля событий файловой системы. Сейчас он позволяет реагировать на создание, изменение или модификацию файлов или на появление файлов в директории.
Создадим для примера юнит
/etc/systemd/system/my_name.pathИ внесем в него следующие строки:
[Unit]
Description= Path test
[Path]
PathExists=/a/b/c/filename
[Install]
WantedBy=multi-user.target
В общем и целом, стандартный юнит, ничего необычного, кроме секции
Path, в директиве PathExists – путь, который мы отслеживаем.Если секция Path не содержит директивы
Unit, то будет найден и запушен одноименный сервис, т.е. my_name.service.Если требуется запуск другой службы, то ее требуется указать явно, т.е.:
[Path]
PathExists=/a/b/c/filename
Unit=123.service
Для начала работы юнит нужно запустить и добавить в автозагрузку:
systemctl start my_name.path
systemctl enable my_name.path
Или одной командой:
systemctl enable --now my_name.path
В секции
[Path] можно одновременно отслеживать несколько путей, запуск юнита произойдет при выполнении любого условия. Однако если хоть одно условие содержит пустую строку, то все директивы будут проигнорированы и юнит работать не будет.Для отслеживания событий можно использовать следующие директивы:
▫️
PathExists= проверяет существование файла▫️
PathExistsGlob= тоже самое, но позволяет использовать шаблоны подстановки▫️
PathChanged= проверяет изменение файла, срабатывает по окончанию редактирования▫️
PathModified= проверяет модификацию файла, срабатывает сразу, не дожидаясь окончания редактирования.▫️
DirectoryNotEmpty= проверяет появление файлов в директорииДополнительно с последней можно использовать:
▫️
MakeDirectory= при указании true каталог для отслеживания будет автоматически создан▫️ DirectoryMode= права на созданный каталог, по умолчанию 0755Еще две опции позволяют задать временные лимиты срабатывания.
▫️ TriggerLimitIntervalSec= юнит будет срабатывать не чаще указанного промежутка времени, по умолчанию 2 секунды.▫️
TriggerLimitBurst= количество активаций за указанное время, по умолчанию 200. Таким образом если произойдет более 200 срабатываний за 2 секунды, то юнит перейдет в режим сбоя не будет работать до перезапуска. Отдельно следует отметить, что systemd.path работает только с локальными файловыми системами и не будет работать с SMB или NFS.
👍14❤4👌2🔥1
Куда шагает отечественное информационное IT-сообщество сегодня
Над этим вопросом я задумался после вопроса по поводу будущего нашего сайта от одного из подписчиков. Вопрос не праздный, потому как формат статьи на сайте и формат заметки в Телеграм с лимитом в 4000 символов – вещи принципиально разные.
Да, есть определенные технические сложности, но этот фактор в том или ином виде был всегда, это я могу сказать совершенно точно, как человек, который крутится в этой сфере без малого 20 лет.
Сейчас, например, это ИИ, которые перехватывают значительную долю трафика, особенно к статьям из которой можно сделать краткую выжимку на один-два абзаца. Но они не первые и не последние, кто за все это время отравлял жизнь создателей контента.
При том, что ведение информационного ресурса на регулярной основе – это не хобби, а еще одна работа на половину или четверть ставки. И поэтому или ресурс находит свою экономическую модель, либо тихо загибается.
Иного не дано, энтузиазмом сыт не будешь и семью не обеспечишь. Есть расхожее выражение: любовная лодка разбилась о быт. Тут ровно тоже самое.
Но, до последнего времени, были вполне неплохие альтернативы, позволяющие и волков накормить, и овец сберечь. Речь в первую очередь идет о Телеграм и каналах в нем, которые сегодня стали реальной альтернативой СМИ.
А где есть аудитория, там будут рекламодатели, там будет выручка, которая позволяла тянуть даже убыточный сайт и дополнять короткие посты в Телеге емкими материалами, и перекачивать пользователей с сайта в Телегу, с Телеги на сайт.
Модель получилась достаточно стабильная и позволяла многим авторам спокойно заниматься производством контента как деятельностью, приносящей реальный доход.
Но в последнее время все изменилось. И это лежит уже не в технической области, а в законодательной. Мне до сих пор кажется, то регуляторы сами не понимают, что именно они регулируют, но легче не становится.
С каждым днем все больше и больше информации проходит у нас по рангу нежелательной, которую нельзя публиковать, на которую нельзя ссылаться, или надо обязательно ставить сноски, что данная информация распространена нежелательным элементом и все такое прочее.
Но, позвольте, закон обратной силы не имеет! Еще как имеет. Если ваша веб-страница с материалами, нарушающими действующее законодательство доступна здесь и сейчас, хотя и написана была далеко до, то у вас длящееся правонарушение, которое возникло в момент признания этих материалов противоправными.
А много кто помнит, что именно от писал 10 лет назад и нет ли там состава противоправного деяния?
Ну да ладно, мы отвлеклись. Текущая модель предусматривала Телеграм как основной финансовый поток, за счет которого тянулись остальные части проекта. Но с 2027 года реклама в ТГ объявлена вне закона.
Это чувствуется уже сейчас, рекламные доходы существенно просели. Но это не о деньгах, а о мотивации к созданию контента.
Сегодня даже в порядке хобби это крайне сомнительная инициатива. С учетом того, что некоторое известное ведомство из трех букв приравняло IP-адрес к персональным данным.
Т.е. создал сайт – получил проблемы на ровном месте, а если еще что-то там опубликовал, то постоянно смотри, не нарушаешь ли ты чего там, ибо правило обратной силы тут не действует.
И что скажет молодой потенциальный автор? Да нафига оно ему надо, если эта деятельность вместо пары десятков тысяч рублей в семейный бюджет подведет его к куда более крупным штрафам.
Да и о чем писать? Если половину тем под запретом, а остальная половина не будет работать без запретного слова КВН.
Фактически отрасль или выдавливается из страны, или вгоняется в стагнацию, копайтесь в местном болоте и не отсвечивайте.
Но это мы уже проходили и программируемые калькуляторы, при всей моей ностальгии к ним, СССР не спасли.
Над этим вопросом я задумался после вопроса по поводу будущего нашего сайта от одного из подписчиков. Вопрос не праздный, потому как формат статьи на сайте и формат заметки в Телеграм с лимитом в 4000 символов – вещи принципиально разные.
Да, есть определенные технические сложности, но этот фактор в том или ином виде был всегда, это я могу сказать совершенно точно, как человек, который крутится в этой сфере без малого 20 лет.
Сейчас, например, это ИИ, которые перехватывают значительную долю трафика, особенно к статьям из которой можно сделать краткую выжимку на один-два абзаца. Но они не первые и не последние, кто за все это время отравлял жизнь создателей контента.
При том, что ведение информационного ресурса на регулярной основе – это не хобби, а еще одна работа на половину или четверть ставки. И поэтому или ресурс находит свою экономическую модель, либо тихо загибается.
Иного не дано, энтузиазмом сыт не будешь и семью не обеспечишь. Есть расхожее выражение: любовная лодка разбилась о быт. Тут ровно тоже самое.
Но, до последнего времени, были вполне неплохие альтернативы, позволяющие и волков накормить, и овец сберечь. Речь в первую очередь идет о Телеграм и каналах в нем, которые сегодня стали реальной альтернативой СМИ.
А где есть аудитория, там будут рекламодатели, там будет выручка, которая позволяла тянуть даже убыточный сайт и дополнять короткие посты в Телеге емкими материалами, и перекачивать пользователей с сайта в Телегу, с Телеги на сайт.
Модель получилась достаточно стабильная и позволяла многим авторам спокойно заниматься производством контента как деятельностью, приносящей реальный доход.
Но в последнее время все изменилось. И это лежит уже не в технической области, а в законодательной. Мне до сих пор кажется, то регуляторы сами не понимают, что именно они регулируют, но легче не становится.
С каждым днем все больше и больше информации проходит у нас по рангу нежелательной, которую нельзя публиковать, на которую нельзя ссылаться, или надо обязательно ставить сноски, что данная информация распространена нежелательным элементом и все такое прочее.
Но, позвольте, закон обратной силы не имеет! Еще как имеет. Если ваша веб-страница с материалами, нарушающими действующее законодательство доступна здесь и сейчас, хотя и написана была далеко до, то у вас длящееся правонарушение, которое возникло в момент признания этих материалов противоправными.
А много кто помнит, что именно от писал 10 лет назад и нет ли там состава противоправного деяния?
Ну да ладно, мы отвлеклись. Текущая модель предусматривала Телеграм как основной финансовый поток, за счет которого тянулись остальные части проекта. Но с 2027 года реклама в ТГ объявлена вне закона.
Это чувствуется уже сейчас, рекламные доходы существенно просели. Но это не о деньгах, а о мотивации к созданию контента.
Сегодня даже в порядке хобби это крайне сомнительная инициатива. С учетом того, что некоторое известное ведомство из трех букв приравняло IP-адрес к персональным данным.
Т.е. создал сайт – получил проблемы на ровном месте, а если еще что-то там опубликовал, то постоянно смотри, не нарушаешь ли ты чего там, ибо правило обратной силы тут не действует.
И что скажет молодой потенциальный автор? Да нафига оно ему надо, если эта деятельность вместо пары десятков тысяч рублей в семейный бюджет подведет его к куда более крупным штрафам.
Да и о чем писать? Если половину тем под запретом, а остальная половина не будет работать без запретного слова КВН.
Фактически отрасль или выдавливается из страны, или вгоняется в стагнацию, копайтесь в местном болоте и не отсвечивайте.
Но это мы уже проходили и программируемые калькуляторы, при всей моей ностальгии к ним, СССР не спасли.
👍46❤5⚡3🤔3🤮1
Особенности директории /etc/pve
Не все знают, что
Поэтому если вы загрузитесь с диска восстановления или подключите диск к другому ПК с целью скопировать конфигурацию гипервизора, то вас ждет неприятный сюрприз – папка окажется пуста.
В этом случае вам понадобится файл базы данных SQLite в котором реально хранятся данные:
Поэтому, если вам нужно сохранить настройки гипервизора, в который вы не можете загрузиться нормальным образом – вам нужно скопировать именно этот файл и потом заменить им базу на новом экземпляре гипервизора.
Если вы хотите просмотреть содержимое базы данных, то выполните запрос:
В выводе вы получите следующую структуру: номер inode, имя объекта и его тип (4 – директория, 8 – файл).
Если хотите получить список объектов директории выполните запрос с указанием ее inode, в нашем случае 12:
Прочитать содержимое файла из базы вы можете запросом (в данном случае мы читаем файл с inode 6):
При необходимости можем сохранить вывод в файл:
Это дает нам возможность не заменять базу целиком, а скопировать из нее только нужные файлы, скажем – конфигурации виртуальных машин и контейнеров.
Не все знают, что
/etc/pve – это не просто директория на диске, а точка монтирования распределённой файловой системы pmxcfs (Proxmox Cluster File System). Данная система монтируется через FUSE при запуске службы pve-cluster и отражает текущую конфигурацию кластера в реальном времени.Поэтому если вы загрузитесь с диска восстановления или подключите диск к другому ПК с целью скопировать конфигурацию гипервизора, то вас ждет неприятный сюрприз – папка окажется пуста.
В этом случае вам понадобится файл базы данных SQLite в котором реально хранятся данные:
/var/lib/pve-cluster/config.dbПоэтому, если вам нужно сохранить настройки гипервизора, в который вы не можете загрузиться нормальным образом – вам нужно скопировать именно этот файл и потом заменить им базу на новом экземпляре гипервизора.
Если вы хотите просмотреть содержимое базы данных, то выполните запрос:
sqlite3 /var/lib/pve-cluster/config.db "SELECT inode, name, type FROM tree WHERE parent = 1;"
В выводе вы получите следующую структуру: номер inode, имя объекта и его тип (4 – директория, 8 – файл).
Если хотите получить список объектов директории выполните запрос с указанием ее inode, в нашем случае 12:
sqlite3 /var/lib/pve-cluster/config.db "SELECT inode, name, type FROM tree WHERE parent = 12;"
Прочитать содержимое файла из базы вы можете запросом (в данном случае мы читаем файл с inode 6):
sqlite3 /var/lib/pve-cluster/config.db "SELECT CAST(data AS TEXT) FROM tree WHERE inode = 6;"
При необходимости можем сохранить вывод в файл:
sqlite3 /var/lib/pve-cluster/config.db "SELECT CAST(data AS TEXT) FROM tree WHERE inode = 6;" > filename
Это дает нам возможность не заменять базу целиком, а скопировать из нее только нужные файлы, скажем – конфигурации виртуальных машин и контейнеров.
👍26🔥7❤3
Веселая иллюминация на Mikrotik
Сегодня коллега из одного филиала прислал эту фотографию с вопросом: а нормально ли это, что роутер сияет всеми цветами как новогодняя елка?
Начнем с пятого порта, это нормально, на этой модели данный порт имеет функцию PoE-out и в данной конфигурации включена подача питания на порт.
А вот почему светится желтым четвертый порт? Документация не содержит четкого описания цветов и режимов для каждой модели, но найденная в сети информация сбила коллегу с толку, намекая на то, что порт работает в нестандартном режиме (например, 10 Мбит/с).
Но изучение режимов работы порта не выявило никаких отклонений от своих соседей. Почему же тогда он желтый?
Для правильного ответа на этот вопрос я предложил ему временно выключить светодиод на пятом порте. После чего все сразу вернулось на круги своя.
Дело в том, что в данной модели Mikrotik индикаторы распаяны прямо на плате, а рассеиватель физически устроен так, что более яркий красный может спокойно «слепить» соседние зеленые.
В результате мы на месте индикатора четвертого порта и видим желтый цвет, также обратите внимание на средний (третий) индикатор – он немного более желтого оттенка, чем первые два.
Эту особенность хорошо знают те, кто много работает с Mikrotik и подвержены ей все модели в аналогичных корпусах. Если вас все же терзают сомнения, то попробуйте выключить соседние светодиоды в System – LEDs и проверить реальный цвет «подозрительного индикатора».
Сегодня коллега из одного филиала прислал эту фотографию с вопросом: а нормально ли это, что роутер сияет всеми цветами как новогодняя елка?
Начнем с пятого порта, это нормально, на этой модели данный порт имеет функцию PoE-out и в данной конфигурации включена подача питания на порт.
А вот почему светится желтым четвертый порт? Документация не содержит четкого описания цветов и режимов для каждой модели, но найденная в сети информация сбила коллегу с толку, намекая на то, что порт работает в нестандартном режиме (например, 10 Мбит/с).
Но изучение режимов работы порта не выявило никаких отклонений от своих соседей. Почему же тогда он желтый?
Для правильного ответа на этот вопрос я предложил ему временно выключить светодиод на пятом порте. После чего все сразу вернулось на круги своя.
Дело в том, что в данной модели Mikrotik индикаторы распаяны прямо на плате, а рассеиватель физически устроен так, что более яркий красный может спокойно «слепить» соседние зеленые.
В результате мы на месте индикатора четвертого порта и видим желтый цвет, также обратите внимание на средний (третий) индикатор – он немного более желтого оттенка, чем первые два.
Эту особенность хорошо знают те, кто много работает с Mikrotik и подвержены ей все модели в аналогичных корпусах. Если вас все же терзают сомнения, то попробуйте выключить соседние светодиоды в System – LEDs и проверить реальный цвет «подозрительного индикатора».
👍36😁17❤3
Как получить список подключенных USB-устройств в Windows
Возникла необходимость просмотреть список подключенных устройств на удаленном ПК с Windows. Задача не самая простая, ну не бегать же глазами по диспетчеру устройств. В Linux для этого есть команда
Для этой цели будем использовать командлет
Кроме идентификатора мы можем использовать в отборе класс, но в этом случае в вывод не попадут такие устройства как камеры или смарт-карты (токены), но может попасть совсем не USB-устройство, например, контроллер USB на PCIe шине:
При желании можем оба отбора скомбинировать и получить только устройства класса USB подключенные именно как USB:
Как видим, PowerShell дает не меньше возможностей и позволяет легко выполнять отборы по требуемым параметрам.
Возникла необходимость просмотреть список подключенных устройств на удаленном ПК с Windows. Задача не самая простая, ну не бегать же глазами по диспетчеру устройств. В Linux для этого есть команда
lsusb, посмотрим, что может нам предложить PowerShell.Для этой цели будем использовать командлет
Get-PnpDevice, для начала отберем устройства по идентификатору в котором присутствует USB, опция Status OK покажет только активные устройства:Get-PnpDevice -InstanceId 'USB*' -Status OK
Кроме идентификатора мы можем использовать в отборе класс, но в этом случае в вывод не попадут такие устройства как камеры или смарт-карты (токены), но может попасть совсем не USB-устройство, например, контроллер USB на PCIe шине:
Get-PnpDevice -Class 'USB' -Status OK
При желании можем оба отбора скомбинировать и получить только устройства класса USB подключенные именно как USB:
Get-PnpDevice -InstanceId 'USB*' -Class USB -Status OK
Как видим, PowerShell дает не меньше возможностей и позволяет легко выполнять отборы по требуемым параметрам.
👍17🤝4❤3⚡2
Установка и настройка сервера лицензирования 1С:Предприятие
Управление лицензиями 1С:Предприятия - задача не простая, особенно если у вас в эксплуатации несколько серверов или используется виртуализация.
Основные проблемы - это оптимизация распределения лицензий и привязка лицензий к параметрам оборудования, что создает трудности в виртуальной среде.
Облегчить работу и централизовать управление лицензиями вам поможет выделенный сервер лицензирования, как его установить и настроить мы расскажем в этой статье.
https://interface31.ru/tech_it/2024/11/ustanovka-i-nastroyka-servera-licenzirovaniya-1spredpriyatie.html
Управление лицензиями 1С:Предприятия - задача не простая, особенно если у вас в эксплуатации несколько серверов или используется виртуализация.
Основные проблемы - это оптимизация распределения лицензий и привязка лицензий к параметрам оборудования, что создает трудности в виртуальной среде.
Облегчить работу и централизовать управление лицензиями вам поможет выделенный сервер лицензирования, как его установить и настроить мы расскажем в этой статье.
https://interface31.ru/tech_it/2024/11/ustanovka-i-nastroyka-servera-licenzirovaniya-1spredpriyatie.html
👍14
Роден нанял бы себе ИИ-агента 💯
Ещё пару лет назад ценность инженера была в технических навыках. Сейчас — в том, как он выстраивает систему, которая работает за него или даже целую команду.
Примерно как Роден 😅 Да, тот самый скульптор XIX века. Он не вырезал каждую скульптуру сам, а строил мастерскую, где идея остаётся за ним, а исполнение масштабируется.
С ИИ происходит то же самое.
Лучшие команды собирают процессы, где агенты подхватывают задачи, делают работу и возвращают результат — остаётся только проверить.
Вот вам простой тест (подсмотрел у Дмитрия Бороздина):
— у вас есть документация, где хранится весь контекст?
— проводите тесты ИИ-агентов?
— работаете с логами и метриками, чтобы отслеживать ошибки?
Если хотя бы на один вопрос ответили «нет» — ваша мастерская, скорее всего, работает некорректно.
Я периодически читаю Дмитрия — он много пишет об ИИ в ритейле: как влияет на продажи, клиентский опыт и экономику интернет-магазинов.
Если тема откликается, вот канал:
https://t.me/+e0WMXuHoHOBjZWIy?erid=2W5zFHoXwDb 👈
Ещё пару лет назад ценность инженера была в технических навыках. Сейчас — в том, как он выстраивает систему, которая работает за него или даже целую команду.
Примерно как Роден 😅 Да, тот самый скульптор XIX века. Он не вырезал каждую скульптуру сам, а строил мастерскую, где идея остаётся за ним, а исполнение масштабируется.
С ИИ происходит то же самое.
Лучшие команды собирают процессы, где агенты подхватывают задачи, делают работу и возвращают результат — остаётся только проверить.
Вот вам простой тест (подсмотрел у Дмитрия Бороздина):
— у вас есть документация, где хранится весь контекст?
— проводите тесты ИИ-агентов?
— работаете с логами и метриками, чтобы отслеживать ошибки?
Если хотя бы на один вопрос ответили «нет» — ваша мастерская, скорее всего, работает некорректно.
Я периодически читаю Дмитрия — он много пишет об ИИ в ритейле: как влияет на продажи, клиентский опыт и экономику интернет-магазинов.
Если тема откликается, вот канал:
https://t.me/+e0WMXuHoHOBjZWIy?erid=2W5zFHoXwDb 👈
🤡3