Вопросы Теги

То, как зафиксировать Марионетку, полностью определило ошибку пути параметра?

Существует много возможностей, мог быть кто-то подключенный к Вашей сети Wi-Fi, или вирусу, червю, троянцу или другому выполнению вредоносного кода. Я попытался бы устранить устройства путем разъединения один за другим и сравнения журналов. Аутентификационные ключи Wi-Fi изменения, пароли один за другим, пока Вы не обнаруживаете источник..

Если бы это - один из Ваших собственных компьютеров, я переформатировал бы и переустановил бы, если вообще возможный, поскольку это почти невозможно, чтобы быть уверенным, что Вы получаете все из там.

3
задан 7 April 2015 в 06:44
4 ответа

[Отвечая на собственный вопрос после возвращения для подталкивания в конфигурации некоторое время]

Мне удалось разыскать это к одному из модулей, которые я записал (конечно), но это происходило из-за использования переменной, которая не разрабатывала, как я ожидал.

То, что произошло, было:

$variable_dir = "/etc/puppet/bar"

class foo {
  file { $variable_dir:
    ensure => directory
  }
}

define some-define() {
   # Trimmed for brevity
   exec { "some-$name":
     # command, creates, timeout etc here
     require => File[$variable_dir],
   }
}

.. который в основном вызвал некоторый беспорядок с Файлом [] использование переменной. Я заменил их явным значением переменной на данный момент, и все это хорошо работает, но это было что-то вроде удивления! Я предполагаю, что мое понимание объема и когда переменные могут определяться/использоваться, несколько в неисправном состоянии с Марионеткой, таким образом, я собираюсь изучить это намного лучше...

Это, кажется, вызвало то же поведение, как использование неполностью определенных путей на файле представляет в виде строки, не удаваясь найти переменную или не получая значение? Довольно нечетный, так или иначе.

Редактирование: довольно возможно, что переменная не была найдена в объеме и так была пуста и определенно не полностью определенный путь. Не объясняет, почему это не было последовательно, однако...

2
ответ дан 3 December 2019 в 06:52

При тестировании марионеточной конфигурации можно сделать это путем выполнения

puppetd --test

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

Если Вы хотите пойти, заглядывая Ваш .pp файлы необходимо искать a

file { "path/to/file":
    ...
}

который имеет отсутствие / (т.е. это должно читать /path/to/file вместо этого)

1
ответ дан 3 December 2019 в 06:52
  • 1
    К сожалению, I' ve не когда-либо имел его, делают это при использовании - отладка переключается, чтобы видеть, могу ли я больше получать подсказки из него... Я думаю I' ll должны перерыть .pp файлы и функции для любого использования без полных путей (хотя некоторые создаются от блоков так, чтобы было неловким также :) –  David Gardner 19 July 2009 в 12:55

Вы можете указать фактический путь к свойству пути, и тогда оно будет работать. У меня это работает: 

$variable_dir = "/etc/puppet/bar"

class foo {
  file { 'variable_dir':
    path => ${variable_dir},
    ensure => directory
  }
}

define some-define() {
   # Trimmed for brevity
   exec { "some-$name":
     # command, creates, timeout etc here
     require => File['variable_dir'],
   }
}
0
ответ дан 3 December 2019 в 06:52

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

Например: 

file { '/full/path':
  ensure => directory,
  recurse => true,
}

или: 

file { 'my name':
  path => "/full/path",
  ensure => directory,
  recurse => true,
}

Если вы используете переменную, убедитесь, что она определена. Если он в другом классе, используйте стандартный синтаксис $ class :: variable . Для получения дополнительной информации запустите puppet с параметром -vd (подробный + отладка).

0
ответ дан 3 December 2019 в 06:52

Теги

Похожие вопросы