Судя по всему действительно она видится как обычный диск в проводнике, то можно и расшарить конечно. Но лентой в pbs она обратно не станет.
Там все равно остается последовательная запись, удаленные только помечаются, записать туда ничего нельзя, т.е. очистка от лишних бэкапов не будет работать с точки зрения объема данных.
Да в том то и дело, что написать скрипт для тех целей о которых вы говорите недолго совсем, например вы говорите о создании паспорта:
for ws in $list_ws
salt "$ws" cmd.run 'lscpu | grep "Model name:"' >> и т.д.
Через несколько секунд вы получите все модели процессоров на ваших включенных в данный момент сколько угодно клиентов (количество клиентов вообще не на что особенно не влияет).
А, еще софт, мы же не умеем без АСM: salt "$ws-*" cmd.run "apt update && apt install lshw" или через state.
Заносите это в базу, скрипт сам будет её наполнять по мере включения клиентов. А затем обрабатываете как хотите этот массив, а не так как хочет это разработчик ACM. Глядя на вообще реализацию, дизайн и прочее у разработчиков Астры с этим там плохо.
Делается свой софт под такую задачу один раз (еще web морда нужна) и очень надолго, дальше только адаптируй под какие-то принципиальные изменения.
Да! В ALDpro 2.4 с выпиленным salt-master надо искать другой подход. Поэтому будешь вынужден кушать что дали... пока лучше явно отказаться от такого и еще сильно платного. freeIPA (samba ad) + salt (ansible) и хватит.
Я уж не знаю кто их надоумил, но похоже я :). В момент перехода на 2-ю версию ALDpro у них был полной ужас с salt-master`ом, он действительно был перегружен, всё отваливалось. Устаканилось это к 2.2.1 (2.3.0), но именно тогда из недр техподдержки прозвучала странная фраза, что они меняют концепцию и вместо того, чтобы вполне рабочую классическую схему salt довести до ума, они её фактически превратили в MS GPO.
А что сильно изменилось? Мастер кидал задачу на шину, клиенты её слушали и выполняли локально. Разве, что мастер ждал ответа о выполнении. У них вообще проблема то заключалась в том, что обработка выключенных клиентов происходила безумно долго. Например, при обновлении парка машин salt-key они получали при запуске, а обновление шло последовательно и временами очень долго. Да и вообще было похоже, что делали одни, а пытались исправить другие. В результате вместо того чтобы исправить, просто поломали нормальную систему управления большим парком линукс клиентов.
Должен заработать, последнее что подключали HP MSL2024 и бакула.
Другое дело у меня есть сомнения по поводу бэкапа ВМ на ленту. У PBS две классные фичи это дедупликация и автоматическая очистка лишних копий. Лента со своим последовательным доступом тут по-моему не пригодна совсем.
Все-таки лента это в первую очередь - записал и в сейф.
В этом случае приходилось либо вручную опрашивать машины, либо писать скрипты «на коленке». Согласитесь, не самая весёлая затея, особенно когда начальник срочно требует от тебя подготовки отчета для бюджетирования ИТ-инфраструктуры, или когда решения активно развиваются и приходится адаптировать свои наработки под новые версии.
/скрипты пишутся не для срочного отчета, а для ИТ-отдела для текущей работы, не спеша и один раз, под новые версии они плавно исправляются или дополняются.
Установка или обновление софта это вообще не та задача, чтобы платить деньги за "странный" продукт ALDpro.
smb к pbs конечно можно, но стример работает с кассетами. Надо к pbs подключать стример напрямую (fbchanel например) и настраивать, чтобы система его увидела как ленточный накопитель.
Так и не понял радости от перехода на 2.4, раньше ты мог через salt-master легко что-то делать с "убитым" клиентом, сейчас получается, что minion инициатор.
Я помню их мучения с загрузкой event шины, но она все-таки к 2.2.1 ожила, но они решили вот так радикально.
На давно вышедшей 1.8 все так и не работает нормально. Предыдущий автор прав - проще freeipa или samba ad допилить.
Судя по всему действительно она видится как обычный диск в проводнике, то можно и расшарить конечно. Но лентой в pbs она обратно не станет.
Там все равно остается последовательная запись, удаленные только помечаются, записать туда ничего нельзя, т.е. очистка от лишних бэкапов не будет работать с точки зрения объема данных.
Пункт 2 нереализуем.
По другому никак.
Я не понимаю, вы хотите увидеть на удаленной машине стример? Так?
Это невозможно.
Да в том то и дело, что написать скрипт для тех целей о которых вы говорите недолго совсем, например вы говорите о создании паспорта:
for ws in $list_ws
salt "$ws" cmd.run 'lscpu | grep "Model name:"' >> и т.д.
Через несколько секунд вы получите все модели процессоров на ваших включенных в данный момент сколько угодно клиентов (количество клиентов вообще не на что особенно не влияет).
А, еще софт, мы же не умеем без АСM: salt "$ws-*" cmd.run "apt update && apt install lshw" или через state.
Заносите это в базу, скрипт сам будет её наполнять по мере включения клиентов. А затем обрабатываете как хотите этот массив, а не так как хочет это разработчик ACM. Глядя на вообще реализацию, дизайн и прочее у разработчиков Астры с этим там плохо.
Делается свой софт под такую задачу один раз (еще web морда нужна) и очень надолго, дальше только адаптируй под какие-то принципиальные изменения.
Да! В ALDpro 2.4 с выпиленным salt-master надо искать другой подход. Поэтому будешь вынужден кушать что дали... пока лучше явно отказаться от такого и еще сильно платного. freeIPA (samba ad) + salt (ansible) и хватит.
Не туда
Я уж не знаю кто их надоумил, но похоже я :). В момент перехода на 2-ю версию ALDpro у них был полной ужас с salt-master`ом, он действительно был перегружен, всё отваливалось. Устаканилось это к 2.2.1 (2.3.0), но именно тогда из недр техподдержки прозвучала странная фраза, что они меняют концепцию и вместо того, чтобы вполне рабочую классическую схему salt довести до ума, они её фактически превратили в MS GPO.
А что сильно изменилось? Мастер кидал задачу на шину, клиенты её слушали и выполняли локально. Разве, что мастер ждал ответа о выполнении. У них вообще проблема то заключалась в том, что обработка выключенных клиентов происходила безумно долго. Например, при обновлении парка машин salt-key они получали при запуске, а обновление шло последовательно и временами очень долго. Да и вообще было похоже, что делали одни, а пытались исправить другие. В результате вместо того чтобы исправить, просто поломали нормальную систему управления большим парком линукс клиентов.
И получили мы не минусы, а огромный МИНУС.
Должен заработать, последнее что подключали HP MSL2024 и бакула.
Другое дело у меня есть сомнения по поводу бэкапа ВМ на ленту. У PBS две классные фичи это дедупликация и автоматическая очистка лишних копий. Лента со своим последовательным доступом тут по-моему не пригодна совсем.
Все-таки лента это в первую очередь - записал и в сейф.
Вы поете любимую песню власти - не трогайте нас остальные как минимум не лучше.
/скрипты пишутся не для срочного отчета, а для ИТ-отдела для текущей работы, не спеша и один раз, под новые версии они плавно исправляются или дополняются.
Установка или обновление софта это вообще не та задача, чтобы платить деньги за "странный" продукт ALDpro.
smb к pbs конечно можно, но стример работает с кассетами. Надо к pbs подключать стример напрямую (fbchanel например) и настраивать, чтобы система его увидела как ленточный накопитель.
Так и не понял радости от перехода на 2.4, раньше ты мог через salt-master легко что-то делать с "убитым" клиентом, сейчас получается, что minion инициатор.
Я помню их мучения с загрузкой event шины, но она все-таки к 2.2.1 ожила, но они решили вот так радикально.
На давно вышедшей 1.8 все так и не работает нормально. Предыдущий автор прав - проще freeipa или samba ad допилить.
PBS будет складывать бэкапы на абсолютно любой примонтированный ресурс.
У нас в контуре для ДСП все на Астре, так что и сервер и клиент линуксовые. Планируется потихоньку и остальное туда переводить.