Проверьте свои локальные правила netfilter:
iptables -L -n
Если нет никаких правил, влияющих на ICMP, и он иначе направляет, как это, кажется, происходит из-за разрешения DNS, там вероятно некоторая фильтрация, происходящая или в 10.254.2.5 или в ее следующий транзитный участок.
Править
На основе Вашего обновления похоже, что у Вас есть локальные правила брандмауэра о сервере Linux, предотвращающем ping.
Удалить все правила:
iptables -F
iptables -X
Они, вероятно, возвратятся на перезагрузке. Я подозреваю, что ими управляет init сценарий. Я предполагаю для отключения init сценария:
/sbin/chkconfig iptables off
Это варьируется между дистрибутивами. Я записал краткое введение в iptables в предыдущем ответе:
Можно ли рекомендовать хорошее введение iptables?
Как правило, просто отключение брандмауэра не благоразумно. Однако действительно выглядит, что Вы используете интранет routable обращение, и Ваше описание указывает, что у Вас, вероятно, уже есть брандмауэр далее маршрут. Будьте осторожны относительно своих действий, если Вы не понимаете потенциальные риски того, что Вы предпринимаете.
моя конфигурация имеет следующий вид ...
path /facts
auth any
allow *
path /fact
auth any
allow *
path /facts_search
allow *
Думаю, мне также пришлось создать пустой файл с именем namespaceauth.conf
вот так;
touch /etc/puppet/namespaceauth.conf
У меня была такая же проблема, и я обнаружил, что строка 99 в /etc/puppet/auth.conf
соответствует следующему:
# this one is not stricly necessary, but it has the merit
# to show the default policy which is deny everything else
path /
auth any
Комментарий к ] path /
и auth any
разрешили Dashboard доступ к инвентарю, используя следующую конфигурацию:
path /facts
auth yes
method find, search
allow dashboard
... как взято из http://docs.puppetlabs.com/dashboard/manual/1.2/configuring.html .
namespace.conf
и другие пути мне не нужны.
Это проблема с заказом - убедитесь, что раздел:
path /facts
method find
auth any
allow *
находится ПЕРЕД разделом по умолчанию:
# this one is not stricly necessary, but it has the merit
# to show the default policy which is deny everything else
path /
auth any
Это сработало + проблема решила для меня. Или, как указано выше, вы можете просто прокомментировать это!
Проблема, с которой вы столкнулись, двоякая. Во-первых, ваш файл auth.conf должен иметь правильный доступ. Многие из упомянутых здесь решений достигают этого, но с большим риском! Используя следующее:
path /facts
auth any
allow *
path /fact
auth any
allow *
path /facts_search
allow *
... вы разрешаете * доступ
«звездочка» означает ВСЕМ !!!
Чтобы решить эту проблему, у вас должен быть auth.conf:
path /facts
auth yes
method find, search
allow dashboard
Затем вам нужно создавать сертификаты для пользователя «приборной панели», как и для узлов. порт для вашего марионеточного мастера
2) сгенерируйте вашу пару ключей для приборной панели:
sudo -u puppet-dashboard rake cert:create_key_pair
3) сгенерируйте запрос сертификата для приборной панели:
sudo -u puppet-dashboard rake cert:request
4) на марионеточном мастере подпишите сертификат:
puppet cert sign dashboard
5) получите сертификат от puppetmaster
sudo -u puppet-dashboard rake cert:retrieve
6) перезапустите приборную панель
Все это позволит приборной панели получить доступ к фактам вашего марионеточного мастера с аутентификацией сертификата.
Наслаждайтесь!