Значит «великий китайский файрволл» не причем…
Не знаю чем помочь больше…
Разве что включить трейсы в логах или на худой конец проснифить трафик.
Видимо ocsp6.wosign.com выдает какую-то ошибку, надо бы посмотреть что ему отправлялось и что он ответил.
Естественно, как мне кажется, каждый должен применять голову к тому или иному материалу изложенному на Хабре.
Согласен. И надеюсь, что все-таки мои комментарии будут служить не критикой вашего материала, а скорее дополнением.
Например в документации на SaltStack есть, на мой взгляд, большой пробел в том, что *_in параметры вводятся как дополнительные, не смотря на их семантику (видимо, это исторически обусловлено)… Также сложно сразу раскопать список всех стейтов с описанием.
Приведенный в этой статье подход прекрасно демонстрирует гибкость Salt, которая с лихвой окупает его недостатки. Также хотелось бы отметить вашу третью статью на эту тему, которая демонстрирует подход к управлению кластером.
От себя хочу сказать что имея опыт управления небольшим кластером серверов при помощи Puppet, сейчас внедряю в очередной проект Salt и не могу не нарадоваться его гибкости и удобству использования по сравнению с Puppet.
На тему Salt, наверное, сложно написать что-то большее чем уже существует. У меня скорее зреет мысль по поводу статьи о некоторых нетривиальных аспектах PHP, которые не всплывали из-за основного способа его использования, но становятся более актуальными в связи с переходом к более долгоживущим процессам. Надеюсь у меня получится оформить это в виде статьи. (:
но, по сути, делают то же самое, что и собственно реквизиты описанные в самих зависимых стейтах
На мой взгляд есть некоторая путаница в этих реквизитах… по крайней мере в некотором не соответствии их названий тому что же они делают на самом деле.
require — используется в том стейте, которому необходим другой стейт, при этом другой стейт ничего не знает об этом.
watch_in — используется так же, но при этом еще и вызывает перезагрузку службы (или что-то еще) если состояние текущего стейта изменилось.
require_in и watch указывают на ровно противоположные отношения между стейтами.
Т.е. если у нас есть некоторое дерево состояний, то require и watch_in используются в дочерних элементах и эти элементы очевидно знают своих родителей. А require_in и watch — в родительских, которые в свою очередь не обязательно знают всех своих детей.
{% for cnf in ['vhost1.conf', 'vhost2.conf', 'vhost3.conf', 'vhost4.conf', 'vhost5.conf'] %}
В вашем примере как раз и показано то, через что приходится проходить, чтобы заставить родителей знать своих детей (:
Небольшое замечание: странно что вы используете параметр watch у nginx-service отдельно для каждого конфигурационного файла. На мой взгляд, гораздо более логично использовать watch_in: — service: nginx-service для каждого конфигурационного файла.
Кстати, на мой взгляд, гораздо удобнее использовать состояние file.recurse для управления некоторой дирректорией конфигураций.
И можно ли что-то сделать с Mozilla (Ошибка: К сертификату нет доверия, так как отсутствует цепочка сертификатов издателя. (Код ошибки: sec_error_unknown_issuer)), или это своеобразная «плата» за «бесплатность»?
Видимо вы что-то не так настроили. У меня все работает во всех браузерах без проблем.
Да и кстати, WoSign отправляет цепочки доверия вместе с сертификатом. Также там есть уже подготовленные файлы цепочек для различных серверов, в т. ч. и nginx.
Сказать вам точно что делать не могу, так как настраивал на апаче, но OСSP Stappling на нем определенно работает.
Я имею в виду, что Go не хватает чего-то подобного Rails или Django или Yii как это не назови. Своей популярностью Ruby или Python в среде веб-разработки обязаны по большей части этим фреймворкам.
Для веб-сокетов Go, по всей видимости, неплох. Но разрабатывать на нем какой-нибудь веб портал пока совсем не тянет.
В общем, и автор этих статей говорит об этом, существует два понятия: MVC архитектура и MVC фреймворк (автор использует кавычки для MVC). Думаю, что из контекста должно быть понятно какое из понятий используется в конкретном моменте.
Хорошо, тогда, если мы пропустим диспуты по поводу наличия или отсутствия подходящих библиотек, то в сухом остатке придем к выводу, что выбор ЯП (и соответствующего стека технологий) должен быть обусловлен в большей степени характером решаемой задачи.
В данной статье обсуждается способ расширения возможностей стека PHP по решению специфических задач связанных с веб и длинные обсуждения того, хорош или плох ЯП в данном случае не являются конструктивными.
Своим замечанием я и хотел это продемонстрировать.
Безусловно, но если речь идет, например, об использовании инструкции процессора, о которой оптимизатор еще не знает.
Думаю, что можно изобрести еще примеры. Опять же ассемблерные вставки в C код не просто так там появляются.
Ситуация с пошаговой инструкцией несколько изменилась.
Теперь после проверки электронной почты надо зайти на страничку buy.wosign.com/free/freessl.html?lan=en и уже на ней подтверждать владение доменом и вводить свой CSR
Не знаю чем помочь больше…
Разве что включить трейсы в логах или на худой конец проснифить трафик.
Видимо ocsp6.wosign.com выдает какую-то ошибку, надо бы посмотреть что ему отправлялось и что он ответил.
(судя по сертификату он именно на 80 должен отвечать)
Все настройки стандартные… Думаю проблема либо в настройках nginx либо в самом nignx.
Согласен. И надеюсь, что все-таки мои комментарии будут служить не критикой вашего материала, а скорее дополнением.
Например в документации на SaltStack есть, на мой взгляд, большой пробел в том, что *_in параметры вводятся как дополнительные, не смотря на их семантику (видимо, это исторически обусловлено)… Также сложно сразу раскопать список всех стейтов с описанием.
Приведенный в этой статье подход прекрасно демонстрирует гибкость Salt, которая с лихвой окупает его недостатки. Также хотелось бы отметить вашу третью статью на эту тему, которая демонстрирует подход к управлению кластером.
От себя хочу сказать что имея опыт управления небольшим кластером серверов при помощи Puppet, сейчас внедряю в очередной проект Salt и не могу не нарадоваться его гибкости и удобству использования по сравнению с Puppet.
На тему Salt, наверное, сложно написать что-то большее чем уже существует. У меня скорее зреет мысль по поводу статьи о некоторых нетривиальных аспектах PHP, которые не всплывали из-за основного способа его использования, но становятся более актуальными в связи с переходом к более долгоживущим процессам. Надеюсь у меня получится оформить это в виде статьи. (:
На мой взгляд есть некоторая путаница в этих реквизитах… по крайней мере в некотором не соответствии их названий тому что же они делают на самом деле.
require — используется в том стейте, которому необходим другой стейт, при этом другой стейт ничего не знает об этом.
watch_in — используется так же, но при этом еще и вызывает перезагрузку службы (или что-то еще) если состояние текущего стейта изменилось.
require_in и watch указывают на ровно противоположные отношения между стейтами.
Т.е. если у нас есть некоторое дерево состояний, то require и watch_in используются в дочерних элементах и эти элементы очевидно знают своих родителей. А require_in и watch — в родительских, которые в свою очередь не обязательно знают всех своих детей.
В вашем примере как раз и показано то, через что приходится проходить, чтобы заставить родителей знать своих детей (:
Это не совсем так. Это состояние появилось начиная с версии 0.10.0 а она вышла в июне 2012 года.
Кстати, на мой взгляд, гораздо удобнее использовать состояние file.recurse для управления некоторой дирректорией конфигураций.
Видимо вы что-то не так настроили. У меня все работает во всех браузерах без проблем.
Да и кстати, WoSign отправляет цепочки доверия вместе с сертификатом. Также там есть уже подготовленные файлы цепочек для различных серверов, в т. ч. и nginx.
Сказать вам точно что делать не могу, так как настраивал на апаче, но OСSP Stappling на нем определенно работает.
Я имею в виду, что Go не хватает чего-то подобного Rails или Django или Yii как это не назови. Своей популярностью Ruby или Python в среде веб-разработки обязаны по большей части этим фреймворкам.
Для веб-сокетов Go, по всей видимости, неплох. Но разрабатывать на нем какой-нибудь веб портал пока совсем не тянет.
В общем, и автор этих статей говорит об этом, существует два понятия: MVC архитектура и MVC фреймворк (автор использует кавычки для MVC). Думаю, что из контекста должно быть понятно какое из понятий используется в конкретном моменте.
То есть веб сайт — не имеет UI я так понимаю?
Да, это возможно. На мой взгляд для широкого применения Go в массах в нем очень не хватает MVC фреймворка.
В данной статье обсуждается способ расширения возможностей стека PHP по решению специфических задач связанных с веб и длинные обсуждения того, хорош или плох ЯП в данном случае не являются конструктивными.
Своим замечанием я и хотел это продемонстрировать.
Думаю, что можно изобрести еще примеры. Опять же ассемблерные вставки в C код не просто так там появляются.
Я знаю способ писать программы, которые могут работать еще быстрее аналогов, написанных на C++.
Это написание программ на ассемблере!
Но почему-то даже системные программисты не часто выбирают такой подход для написания своих приложений.
Так так ли важна скорость работы программы в контексте выбора ЯП для какой-либо задачи?
Теперь после проверки электронной почты надо зайти на страничку buy.wosign.com/free/freessl.html?lan=en и уже на ней подтверждать владение доменом и вводить свой CSR