Вопрос на скорую руку: можно ли использовать Discourse только внутри моей сети, без выхода в интернет?
Допустим, мой домашний домен называется testlabs.local. Я хочу, чтобы все пользователи этого домена могли получать доступ к Discourse. Я могу открыть его через порт 80, но при регистрации учетной записи, когда я ввожу имя пользователя и пароль и нажимаю «Продолжить», появляется ошибка 404 от nginx, страница пустая. Странно, что, несмотря на ошибку, я всё равно получаю письмо, но при переходе по ссылке снова получаю ошибку 404.
Так можно ли использовать его внутренне, как я хочу? Или он предназначен только для внешнего использования?
Если да, есть ли руководства по настройке для внутреннего использования, так как я вижу только руководство по облачной версии?
В yaml-файле я настроил параметры SMTP, письма приходят. Я не уверен насчёт полей «имя пользователя SMTP» и «пароль SMTP». Я просто закомментировал их. Нужно ли их настраивать? Если да, почему я всё равно получаю письма без этой настройки?
Я просто не хочу вставлять пароль от почты в открытом виде.
Любой из этих способов позволит использовать Discourse через http://localhost:4200/. Все эти варианты используют MailHog для тестирования SMTP без фактической отправки писем.
Обновление: Я перечитал вопрос и понял, что вы хотите, чтобы другие люди могли им пользоваться. Не уверен, что этот ответ действительно поможет.
Discourse в основном не будет работать без HTTPS, что сложно настроить в локальной сети. Вы можете присоединиться посмотреть руководства, в которых используется обратный прокси-сервер, но это не поддерживаемая конфигурация.
Спасибо за ответ. Да, я действительно хочу разрешить другим людям использовать это. Я лишь хочу уточнить, что эти люди находятся в моей локальной сети, и доступ к системе будет осуществляться только внутри здания, без публичного доступа.
Сработает ли включение параметров «только по приглашениям» и «требуется вход», чтобы разместить Discourse в интернете, но ограничить круг лиц, которые могут его видеть? Или, возможно, использовать «требовать одобрения пользователей» (возможно, с функцией «автоодобрение по доменам электронной почты»), чтобы разрешить присоединение только пользователям вашей организации?
Думаю, вопрос в том, какую проблему вы пытаетесь решить?
Спасибо за ваш ответ. Я сейчас настроил это на дистрибутиве Red Hat в рамках моей внутренней сети, исключительно для внутреннего использования. Попробую поэкспериментировать. Что именно вы имеете в виду, когда говорите, что это не будет работать без HTTPS? Получается, оно предназначено только для внешнего использования, для доступа через публичный интернет?
Могли бы вы подробнее рассказать о руководстве по обратному прокси? Я не совсем понял, что вы имеете в виду под «присоединиться в руководствах».
В данный момент мы просто приостановили работу над продуктом. Мы хотим использовать его как внутренний форум для нашей компании, чтобы разработчики и ИТ-специалисты могли публиковать сообщения и взаимодействовать друг с другом. Мы хотим, чтобы доступ был только внутренний, без публичного доступа.
Это решение, на котором они настаивают. Я не могу это изменить.
Думаю, настройка «требовать одобрения пользователей» полностью удовлетворяет этому требованию. Многие «внутренние» инструменты (Slack, Google Suite, Microsoft Office 360, GitHub Enterprise и др.) размещены в интернете, но ограничены только пользователями, которых утверждает администратор клиента.
Если размещение во внутренней сети является требованием ИТ-отдела, они также должны помочь настроить сеть для Discourse.
Понял, я спрашиваю, каков процесс настройки для работы только с внутренним доступом? Для этого нет руководства по настройке, и пользователи сообщают, что без HTTPS оно работает плохо.
Я как раз настроил локальную сеть в своей лаборатории и протестирую её, но по предыдущим тестам оно не работало во внутренней сети. Попробую ещё раз.
Я имею в виду, что значительная часть кода фронтенда предполагает использование HTTPS. Стандартная установка также рассчитывает на то, что ваш сайт сможет получить сертификат от Let’s Encrypt.
Вот одно из них. Чтобы это работало, вам нужно настроить Apache с валидным сертификатом, а затем настроить его как обратный прокси для Discourse.
Это не поддерживаемая конфигурация. Если требованием является нахождение за брандмауэром/NAT, то наличие специалиста, который умеет настраивать внутренний обратный прокси с валидным сертификатом и может следовать одному из руководств, например, приведённому выше, — это цена такого требования.
Это более вежливая формулировка того, что я сказал.
У вас есть специалисты по ИТ. Они могут создать сертификат, так как в вашей интрасети в любом случае используются веб-серверы. Единственная проблема — получить сертификат, который будет признан браузерами.
