Фокс Йовович, это один из вариантов решения. К сожалению он не может быть использован из-за ряда административных ограничений с точки зрения безопасности и имеющейся архитектуры.
Очень надеюсь, что спустя год или два удастся все это заменить на PowerShell DSC или Puppet, но проблему необходимо решать сейчас.
Фокс Йовович, Сейчас это называется GitOps))))
В целом да. Есть парк на 5000 клиентских машин. Бинарные файлы меняются редко 1-2 раза в год, а вот файлы конфигурации достаточно часто и существенно влияют на логику работы ПО.
Идея в том, чтобы планировщик регулярно выполнял Git clone depth=1, заданной директории и версия была гарантированно актуальной. При этом если ПК долго не был активен, то он гарантировано подтянет все изменения. А если кто-то вручную изменил файл, или он был поврежден - изменения затрутся.
Это да. Оба варианта тянут с собой все дерево GIT из зависимого репозитория.
Предположим у нас есть 3 версии программы 1, 2 и 3. Для конкретной конфигурации нам нужна 2 версия бинарных файлов.
При выполнении git submodule -update в репозиторий будут подтянуты все 3 версии.
Не хотелось бы хранить все в целевом репозитории, чтобы у клиентов просто не было возможности скачать не верное сочетание версии и конфигурации.
Этот вопрос, по сути последняя попытка найти готовое решение, перед тем как начать писать самому.
Проблема в том, что я не уверен в своей способности написать сервер, который обработает хотя бы 1-2 тыс. обращений в пике. Идея переложить обязанности обслуживания запросов на web-сервер весьма интересная.
Я пока смотрю в сторону MQTT и ему подобных. Тэги сообщений позволят сделать разделение на группы, а существующие реализации брокеров - возьмут на себя вопросы коммуникации. Останется написать интерфейс и клиентов.
Сейчас все реализовано как раз через почту, и как это не печально "никто не читает почту". В случае проблем, все просто начинают плодить заявки "у меня не работает...", "срочно почините..." и т.д.
По итогу после инцидента остается гора заявок, по которым нужно выяснить решилась она или нет.
Поэтому основные критерии:
1) Оповещение должно появляться перед пользователем, без активных действий с его стороны.
2) Оно не должно требовать операций по его отключению (вроде кнопки ОК или Закрыть)
3) В идеале иметь возможность обратной связи (Проверить наличие проблемы Актуальна\решена)
blantcat, Тогда опять же вопрос почему нет Hyper-V? Он в Win10 ставится в программах и компонентах в пару кликов.
Я на своем i7 M620 его как раз под Win10, использую для тестов.
iMaximus, если админ один на всю контору, он может себя хоть DevSecQAOps называть, и добавлять к этому еще кучу аббревиатур. Если все работает, то ему все простят, а если нет - красивые слова не помогут.
Да, не так понял вопрос.
Судя по тому, что этот вопрос первый раз возник в 2015 году, и до сих пор нет решения, то вероятно никак.
Есть вероятность найти нужный параметр в реестре, согласно инструкции в ветке
Нет такого разделения как "настоящий" и "не настоящий" командлет. Есть компилированный BLOB и специально оформленные скрипты. Отличия только в целесообразности - какие-то вещи проще написать на C#, с какими-то заморочки того не стоят.
Чтобы не приходилось импортировать модуль каждый раз, его нужно положить в указанные выше папки - тогда PS будет их импортировать автоматически.
Можете еще оформить комментарии функций как в примере, тогда при вводе команды get-help Get-NProcesses, вы получите описание, указанное в Synopsys
kinton, PowerShell это скриптовый язык, который очень тесно связан с .NET Framework. Писать программы на PowerShell не самая лучшая идея.
Так что или пишете скрипт, с запуском сторонних программ, или пишите программу на C# привязывая PS Module каким-либо стандартным для C# образом
Ну в общем-то как раз дело в кавычках.
В первую очередь попробуйте выполнить скрипт, с уже сформированной строкой, чтобы убедиться что проблема не в базе данных.
Затем пробуйте разобраться в кавычках. SQL не нравится сочетание \n, поэтому его нужно экранировать. А вот какой из вариантов сработает сказать не могу: '\n'\n'
Вы пришли с вопросом как создать промышленную систему, на коленке.
Если у вас 40 ПК с 40 приводами, то это не хилая распределенная система. Вам необходимы:
1) Работник - скрипт, который будет выполнять непосредственно скачивание и запись дисков на каждом ПК.
2) Контролер - скрипт, который будет формировать задания для работников и контролировать их выполнение.
Это полноценная разработка которую за 5 минут не сделаешь, а тратить 2-3 дня за "спасибо" естественно никто не будет.
Вопрос не в выборе системы мониторинга. Zabbix сейчас стоит, и практически захлебывается из-за раздувшейся базы данных, не собирая даже половины требуемых метрик.
Очень надеюсь, что спустя год или два удастся все это заменить на PowerShell DSC или Puppet, но проблему необходимо решать сейчас.