Вопросы Теги

Основной автор для приложения Tomcat (JIRA) с Nginx как обратный прокси

Обновление: По-видимому, RHEL 5.6 включает PHP 5.3, таким образом, это будет собираться исходно для CentOS скоро.

file /usr/bin/php from install of php53u-cli-5.3.4-3.ius.el5.x86_64 conflicts with file from package php-cli-5.1.6-27.el5_5.3.x86_64
file /usr/bin/php-cgi from install of php53u-cli-5.3.4-3.ius.el5.x86_64 conflicts with file from package php-cli-5.1.6-27.el5_5.3.x86_64
file /usr/share/man/man1/php.1.gz from install of php53u-cli-5.3.4-3.ius.el5.x86_64 conflicts with file from package php-cli-5.1.6-27.el5_5.3.x86_64
file /etc/php.ini from install of php53u-common-5.3.4-3.ius.el5.x86_64 conflicts with file from package php-common-5.1.6-27.el5_5.3.x86_64

Проблема здесь состоит в том, что пакеты, которые Вы устанавливаете, имеют другое имя (php53 вместо php), но они пытаются установить те же файлы... следовательно конфликты. Это - не обязательно лучший способ соединить пакеты, но я не знаю, существуют ли лучшие пакеты, доступные, таким образом, мы проигнорируем это.

Удалить Ваши в настоящее время устанавливаемые пакеты:

# yum remove php-cli php-common php

Так, в целом, yum remove удалит пакеты. И конечно, yum list installed видеть список установленных пакетов (или rpm -qa).

5
задан 21 October 2019 в 22:49
3 ответа

Хорошо, только что нашел решение в списке рассылки nginx . Мне просто пришлось сказать nginx, чтобы он не пересылал заголовки auth в tomcat. Добавление пары строк в блоки местоположения в nginx.conf помогло: 

  location / {
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://127.0.0.1:8090/;
        proxy_redirect off;

        # Password
        auth_basic "Restricted";
        auth_basic_user_file /home/passwd/.htpasswd;

        # Don't forward auth to Tomcat
        proxy_set_header   Authorization "";
    }

Теперь мне просто нужно выяснить, как запретить nginx запрашивать авторизацию на каждом поддомене (jira, confluence, stash , так далее). Было бы идеально ввести учетные данные только один раз для всех, но это уже другая проблема.

Надеюсь, это поможет!

Ура.

11
ответ дан 3 December 2019 в 01:06

У меня была такая же проблема с Confluence. Это было очень полезно (как обновленный вопрос, так и ответ SDude). У меня есть параметры прокси на каждом уровне подпути ("/ jira", "/ wiki" для Confluence и т. Д.), Поэтому я добавил proxy_set_header Authorization ""; в каждый контейнер местоположения в конфигурации nginx, который исправил проблему. Это также вылечило странную проблему со Stash, когда Stash запрашивал пароль для входа в систему через окно авторизации браузера, а не через собственный экран входа в систему. С учетом вышесказанного теперь отображается фактический экран входа в систему.

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

Это работает до тех пор, пока вы не нажмете на аутентифицированные ресурсы, которые отправят клиенту заголовок 401 через прокси-сервер, который вызывает всплывающее окно.

Ниже приведено сообщение From https: // answers.atlassian.com/questions/2515/answers/39133735?flashId=366096075

Это чертовски старая ветка, но для всех, кто пришел сюда с этой проблемой. Решение состоит в том, чтобы отключить заголовок авторизации при использовании Apache2 в качестве обратного прокси. 

RequestHeader unset Authorization

То же самое можно сделать с NGiNX 

proxy_set_header Authorization "";

Это отлично работает и решает проблему.

Однако, если ваша установка слияния разрешает анонимный доступ , а аутентификация, используемая с NGiNX / Apache2, отличается от Confluence. Вы увидите всплывающие окна для определенных элементов.

Например, следующая ссылка «rest / mywork / latest / status / notification / new» 

<status>
<status-code>401</status-code>
<message>
Client must be authenticated to access this resource.
</message>
</status>
-2
ответ дан 3 December 2019 в 01:06

Теги

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