а. да. ты прав наверно ) запутался )

я имел ввиду source конечно

Я уже ноут убрал в локер, завтра тестить буду, если память не отшибёт

вопроc, если написать сначала exec { "mkdir_recurse_${name}": path => ['/bin', '/usr/bin'], command => "mkdir -p ${name}", unless => "test -d ${name}", } а потом сделать file { $my_dir: ensure => directory, mode => $mode, owner => $owner, group => $group, } то второй вызов просто проверит что папка существует с нужными правами, если права не те, выставит нужные верно?

а если сделать так define nfs::function::mkdir () { exec { "mkdir_recurse_${name}": path => ['/bin', '/usr/bin'], command => "mkdir -p ${name}", unless => "test -d ${name}", } } а потом file { $myfile: ensure => directory, require => [ Nfs::Function::Mkdir[$myfile] ], } это будет верно? чет не работает так(

нормально. но это же реквайр и описание дефйна.

ты ж его ещё вызвать должен

nfs::function::mkdir{$myfile: }

вот так точнее

nfs::function::mkdir{$myfile: }

написал это перед file и не заводится чет всеравно(

я сам дурак, не ту функцию вызываю соре

а если сделать так define nfs::function::mkdir () { exec { "mkdir_recurse_${name}": path => ['/bin', '/usr/bin'], command => "mkdir -p ${name}", unless => "test -d ${name}", } } а потом file { $myfile: ensure => directory, require => [ Nfs::Function::Mkdir[$myfile] ], } это будет верно? чет не работает так(

Ты делаешь что-то странное

Ты делаешь что-то странное

почему?

Ну, сам процесс создания директории странный и нет описания зависимостей

А, с дефайном уже есть

Но вообще, вроде, должно сработать exec { "mkdir $myfile": creates => $myfile, command => "mkdir -p $myfile", } -> file { $myfile: mode => 777, }

Уже работает ) спасибо

Стрелки зло

а можно средствами puppet запустить выполнение не из-под прав root, а текущего пользователя? Для сравнения у SCCM при публикации программы пакета есть режим выполнения с правами пользователя, где для запуска и установки используется сеанс текущего активного пользователя. Вроде в puppet я такого не нашёл в явном виде, но а вдруг.... Цель: скопировать директорию с файлами на $HOME пользователя. При этом на клиентах могут быть разные пользователи (те я их список заранее не знаю)

а можно средствами puppet запустить выполнение не из-под прав root, а текущего пользователя? Для сравнения у SCCM при публикации программы пакета есть режим выполнения с правами пользователя, где для запуска и установки используется сеанс текущего активного пользователя. Вроде в puppet я такого не нашёл в явном виде, но а вдруг.... Цель: скопировать директорию с файлами на $HOME пользователя. При этом на клиентах могут быть разные пользователи (те я их список заранее не знаю)

Я чем вас экзек от указанного пользователя не устравает?

Я чем вас экзек от указанного пользователя не устравает?

Тогда я не понимаю. Можно пример кода, при условии, что я не знаю что за пользователь сейчас активен на данной машине?

Тогда я не понимаю. Можно пример кода, при условии, что я не знаю что за пользователь сейчас активен на данной машине?

это как? запустить скрипт от пользователя кто зашел в систему через папет? )))

exec { "script by some user": command => "some_script.sh", user => $user, group => $group, cwd => $dir, path => $path, timeout => 0, }

это как? запустить скрипт от пользователя кто зашел в систему через папет? )))

я тоже ничего кроме костылей не придумал

я задачи не понял не много - если запустить от пользователя то через exec как советуют

user укажи пользователя и окружение path

user укажи пользователя и окружение path

user мне заранее не известен. те смысл в том, что бы выполенние скрипта было из-под залогиненного на текущий момент в системе пользователя.

Интерактивный скрипт получается? ))

Через whoami делай. Передавай значение переменной и потом папету

Изврат такой ?

Через whoami делай. Передавай значение переменной и потом папету

да, в эту сторону велосипеда и смотрю)))

ок, спс

Люди тут тебе скажут что не тот инструмент у тебя

вероятно да, но лучше нет:)

Нет лучших инструментов

Через whoami делай. Передавай значение переменной и потом папету

Упрлс

user мне заранее не известен. те смысл в том, что бы выполенние скрипта было из-под залогиненного на текущий момент в системе пользователя.

А смысл это делать паппетом?

А смысл это делать паппетом?

а какие альтернативы централизованного выполнения на N машинах?

а какие альтернативы централизованного выполнения на N машинах?

Чо за скрипт?

Суть действий какая?

скопировать директорию с файлами на $HOME пользователя. При этом на клиентах (их много) могут быть разные активные пользователи (те я их список заранее не знаю)

А обязательно копировать в активные только?

в целом можно копировать и на всех пользователей. Можно копировать во все подпапки /home/ в цикле , но как то не хочется мусорить

в целом можно копировать и на всех пользователей. Можно копировать во все подпапки /home/ в цикле , но как то не хочется мусорить

Ну короче

Мое предложение

Берешь пуппит

Натравливаешь его на профайл

Кладешь в баш логин что тебе надо

Юзер заходит у него стартует сш скрипт

Готово вы восхитительны

Можно если повторный запуск не нужен чекать паппетом выполнение и дропать башлогин

Так не катит?

вариант. спасибо.

Так не катит?

странный вариант для использования пуппета )))

ансибл берешься для того или pssh чтобы скрипт скопировать 1 раз

паппет вей в этом кейсе это сделать custom fact который будет возвращать список пользователей. а в классе сделать описание стейта с содержимым папок, итерируясь как раз по этому факту

странный вариант для использования пуппета )))

Ну просто первое что в голову пришло

И наиболее простое

паппет вей в этом кейсе это сделать custom fact который будет возвращать список пользователей. а в классе сделать описание стейта с содержимым папок, итерируясь как раз по этому факту

Просто паппет вей тут будет создавать папки по всем юзерам в том числе и незалогиненным

а причём тут залогиненый или нет ?

паппет вей в этом кейсе это сделать custom fact который будет возвращать список пользователей. а в классе сделать описание стейта с содержимым папок, итерируясь как раз по этому факту

звучит неплохо. кстати о кастомных фактах: как писать новый и распространить его на ноды?

а причём тут залогиненый или нет ?

Человек не хочет не логиненым раздавать файло

звучит неплохо. кстати о кастомных фактах: как писать новый и распространить его на ноды?

паппетом ) по факту же кастом факт может представлять собой тупо баш скрипт который просто в результате работы на консоль выдаст значение в опредленном формате.

просто это складывается в некоторый common который везде распространяется и всё

паппетом ) по факту же кастом факт может представлять собой тупо баш скрипт который просто в результате работы на консоль выдаст значение в опредленном формате.

ну что паппетом распространить - это понятно))) можно пример рабочего кастомного факта и пример в манифесте как его распространить

https://puppet.com/docs/facter/3.12/custom_facts.html#executable-facts-----unix https://puppet.com/docs/facter/3.12/custom_facts.html#fact-locations ну а как файлик скопировать объяснять наверно не нужно ?

ну а как файлик скопировать объяснять наверно не нужно ? - нет, не нужно) спасибо

ну а как файлик скопировать объяснять наверно не нужно ? - нет, не нужно) спасибо

только пишите с учётом того что как бы этот shell будет прогоняться агентом при каждом ране, хорошо бы чтобы он долго не бегал

да, я понимаю что пока существующие факты будут не сданы puppet-master манифест на ноде не отработает + нагрузка выполняемая на ноде будет выше

те: используя руби я создаю факт, на puppet-master складирую сюда: <MODULEPATH>/<MODULE>/facts.d/, затем его же распространяю на клиенты по пути ниже и он заработает? Или нужно кастомный факт ещё где то прописывать? путь на клиентах: On Unix/Linux/OS X, there are three directories: /opt/puppetlabs/facter/facts.d/ /etc/puppetlabs/facter/facts.d/ /etc/facter/facts.d/

те: используя руби я создаю факт, на puppet-master складирую сюда: <MODULEPATH>/<MODULE>/facts.d/, затем его же распространяю на клиенты по пути ниже и он заработает? Или нужно кастомный факт ещё где то прописывать? путь на клиентах: On Unix/Linux/OS X, there are three directories: /opt/puppetlabs/facter/facts.d/ /etc/puppetlabs/facter/facts.d/ /etc/facter/facts.d/

Заработать должен. Просто там одно дело факты которые складываются в либс, там всякие штуки типа кеширования доступны, другое дело кастом, они примитивные как бы

Заработать должен. Просто там одно дело факты которые складываются в либс, там всякие штуки типа кеширования доступны, другое дело кастом, они примитивные как бы

иными словами кастомные факты ограничены в возможностях по их использованию и чем проще кастомный факт тем лучше?

иными словами кастомные факты ограничены в возможностях по их использованию и чем проще кастомный факт тем лучше?

Да

Да

спасибо! завтра попробую применить на практике

Надо спам бот фильтра написать

На телеграм и на канал его повесить

Телеграммный аддблок

пацане

https://www.jetbrains.com/research/devecosystem-2018/devops/

ansible дает жару )

Еще бы, он же простой

не думал что докеры так распростронены

почитал в этом чате про докеры как то даже не захотелось пробывтаь

))

ты просто хейтеров почитал которые рассказывают про докер трехлетней давности ) это всё равно что сейчас какой нить паппет 3.4 хейтить

ты просто хейтеров почитал которые рассказывают про докер трехлетней давности ) это всё равно что сейчас какой нить паппет 3.4 хейтить

сейчас контейнеры не падают? ведут себя стабильно?)

даже не смешно

даже не смешно

а я и не шучу. Мне тут по бонусу на digital ocean 80$ упало и вижу что там можно контейнеры поднимать. призадумался, а может быть ...

DO уже куб как сервис части народу выдало

Добрый день подскажите пожалуйста как можно сделать валидацию входных данных

Нужны подробности

прописать типы значений у параметров класса \ дефайна

а можно как-то обойти вот такую ошибку? export is a metaparameter; оч хотят именно такое название переменной

нет