• Что необходимо чтобы развернуть своей почты?

    Для начала 3 полезных сайта: 24whois.ru для проверки записей, если не хочется возиться с nslookup, mxtoolbox.com для проверки настроек smtp сервера и pdd.yandex.ru бесплатный DNS сервер.
    Предположим, у Вас есть белый IP 50.100.150.200, по которому доступен будущий почтовый сервер и домен homepage.ru.

    1. Создайте A запись для данного IP адреса. Например, это может быть так:
    Хост: mail.homepage.ru
    Тип: A
    Значение: 50.100.150.200

    2. Создайте для @ MX запись с меньшим приоритетом, чем уже существующие (например, для серверов с приоритетом 10 и 20 основным будет 10) и впишите в неё созданный поддомен:
    Хост: @
    Тип: MX
    Значение: mail.homepage.ru
    Приоритет: 5

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

    3. Обратитесь к хостеру, у которого стоит сервер или провайдеру, если сервер дома, чтобы он сделал следующую PTR запись (IP должен быть "перевёрнут"):
    200.150.100.50.in-addr.arpa IN PTR mail.homepage.ru

    4. Настройте SPF на DNS сервере. Например, если у Вас 1 IP - можно указать только его, а почту с остальных объявить недоверенной (~all) или вообще советовать сразу отклонять её (-all).
    Хост: @
    Тип: TXT
    Значение: v=spf1 ip4:50.100.150.200 ~all

    Вот как это выглядит у яндекса: 24whois.ru/?data=_spf.yandex.ru&t=nslookup&dns_type=txt и с раскрытыми IP адресами: 24whois.ru/?data=_spf-ipv4.yandex.ru&t=nslookup&dn...

    5. При помощи mxtoolbox или другого сайта проверьте свой IP на нахождение в чёрных списках и подайте заявки на исключения из них. Вы 99,9% будете хотя бы в одном списке, как минимум надо проверить spamhaus - им многие пользуются.

    6. Желательно на сервере настроить правильный ответ HELO/EHLO: mail.homepage.ru
    Ответ написан
  • Как правильно реализовать вычисляемое поле для Entity (Symfony/Doctrine)?

    lexxpavlov
    @lexxpavlov
    Программист, преподаватель
    Есть несколько вариантов решения.

    1) грязным хаком получать контейнер и извлекать из него нужные сервисы и параметры. Если нужно решить очень быстро, то можно сделать и так, но тогда потом не забыть прибрать за собой, как появится время на рефакторинг.
    2) сделать фабрику для создания сущности (как вы и говорили)
    Эти два варианта можно посмотреть вот в этом вопросе.

    3) Передать шаблон через параметр метода:
    class User
    {
        // ...
    
        public function getFullDomain($template)
        {
            return str_replace("{subdomain}", $this->subdomain, $template);
        }
    }

    Но код, который использует эту сущность, должен сам получать шаблон, чтобы передать в метод getFullDomain().

    4) Сделать расширение для Twig. Решение в зависимости от назначения этого метода - если полное имя домена выводится только в представлении, то это хороший выход. В приведённой странице документации приведён способ построения фильтра user|fullDomain, но не сложнее сделать и функцию - fullDomain(user), кому что больше нравится.

    5) Сделать сервис, который будет строить полное имя домена. Это самый универсальный способ, ведь во всех остальных случая можно вызвать этот сервис и использовать его метод для построения имени.
    Ответ написан
  • Почему в логах nginx мне пишет (13: Permission denied) при выполнение php-скриптов?

    @Blumfontein
    Пусть my_user - тот, юзер, в директории которого работает сайт.

    1) В nginx.conf ставьте

    user my_user; # вместо user nginx;

    2) В php5/fpm/pool.d/www.conf

    # Найдите и исправьте на
    user = my_user
    group = my_user
    listen.owner = my_user
    listen.group = my_user


    3) Перезапуск nginx и fpm. Далее на папку /var/lib/nginx/tmp руками ставьте права 0700 на пользователя my_user

    chown -R my_user:my_user 0700 /var/lib/nginx/tmp

    4) PROFIT
    Ответ написан
  • Как правильно организовать деплой приложения?

    shebanoff
    @shebanoff
    Я увидел в Вашем вопросе две части.

    Как правильно организовать деплой (выкладку работоспособного кода на сервер)?


    В самом простом случае Вам подойдет связка ssh + git pull на сервере. В этом случае на сервер будут доставлены патчи коммитов, которые есть в репозитории, но еще не появились на сервере, т.е. «только обновления файлов, которые сейчас существуют». Этот метод довольно подробно обсудили в ответах на другой вопрос.

    Если хочется автоматизировать процесс, что похвально, то я вижу три доступных инструмента для этого: Capistrano, Mina (мой персональный фаворит) и Vlad the Deployer. Все три проекта схожи по сути. Принцип их работы таков:
    1. Подключиться к целевому серверу.
    2. Залить обновление кода из репозитория.
    3. Выполнить предписанные Вами инструкции (перезапуск демонов, сброс индексов, обновление структуры БД и прочее).
    4. ...
    5. PROFIT!


    Инструменты просты, переход на них — дело одного выходного дня, и может быть сопряжен со сложностями только в связи с новизной.

    Как организовать процесс тестирования?


    Если Вы еще не определились с методикой тестирования (Test Driven Development, Behavior Driven Development, Лень-Driven Development), то Вам следует для начала заняться именно этим.

    Скорее всего, тесты будут выполняться на Вашей локальной машине, пока Вы пишете код. Используя RSpec, я держу открытым Guard. Guard отслеживает изменения в коде и запускает набор юнит-тестов, которые покрывают измененный код. Весь процесс занимает не больше минуты-двух, и особо не напрягает. Как только я вижу провалившийся тест, я меняю код до тех пор, пока он не станет зеленым. Пока тестов мало (это не самый лучший знак, к слову), Вы работаете один, локального запуска перед деплоем может оказаться достаточно — например, чтобы проверить релиз на доступность критического функционала: регистрации, покупки, создание постов и т.п.

    В какой-то момент речь может зайти о Continious Integration. Это возможность иметь стабильный билд в любой отрезок времени, а так же принимать решение о годности каждого отдельного коммита. Сопряжено с деплоем кода на integration-сервер и запуском на нем тестов. Скорее всего, это Вас не интересует, если Вы не работаете в команде. Но, для полноты картины, Вы можете понаблюдать за билдами на Travis CI известных Open Source проектов: Symfony 2 и Ruby on Rails.

    Таким образом


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

    Приведите в порядок Ваш репозиторий с кодом, используйте mina для деплоя и запускайте тесты на Вашей локальной рабочей машине. Как только Вы почувствуете, что этого не достаточно — Вы наверняка уже будете знать, куда шагать дальше.
    Ответ написан