Запуск jira в jira. [Мой домен] .com

Эта интерпретация разрешений восходит к ранним файловым системам Unix. Вначале были только файлы. (Ну, и устройства, и трубы, и ... но я пытаюсь рассказать историю здесь, не быть на 100% точным; кроме того, это все верно для устройств, каналов и всего остального, потому что все является файлом, даже каталоги).

Каталоги - это просто файлы, которые файловая система использует для хранения метаданных, описывающих дерево каталогов, и файлы, которые оно содержит. Каждый файл в каталоге описывался простой структурой данных, которая содержала место для имени файла (изначально 14 символов, IIRC) вместе с номером inode, в котором были сохранены данные, размером файла, отметками времени и словом разрешений. Каждый каталог начинается с двух записей с именами . и .. , первый указывает на индексный дескриптор этого самого каталога, а второй - на индексный дескриптор его родительского каталога.

Слово разрешений имело девять битов для описания обращения с владельцем, другие члены одной группы и мира. Три бита для каждого флага того, может ли соответствующий пользователь читать, писать или выполнять файл. (Вы могли заметить, что в 16-битном слове разрешений есть еще пять битов, которые я игнорирую. В конечном итоге им были присвоены значения, но это не имеет отношения к этой части истории.) (Кроме того, эта интерпретация девяти биты остались практически такими же во всех потомках раннего Unix, включая Linux.)

Итак, если каталог на самом деле представляет собой файл особого типа и описывается записью в каком-то каталоге, очевидно, что он также имеет биты прав доступа, и эти биты, вероятно, что-то означают. Но вопрос в том, что именно. Самый простой способ придать значение этим битам - это вообще не менять то, что они означают. По сути, именно это и было сделано.

Итак, бит чтения означает, что пользователь может читать сам каталог. Это обычно дает читателю доступ к имени файла, отметкам времени, размеру и номеру inode данных каждого файла. В частности, с установленным r вы можете использовать ls , чтобы увидеть имена всех файлов в каталоге, но этого недостаточно для открытия (или использования каким-либо образом) любого из перечисленные файлы.

Бит выполнения означает, что пользователь может «выполнять» каталог. Поскольку каталоги особенные, выполнение на самом деле означает поиск записи по имени и ее использование. Это означает, что вы можете попытаться открыть файлы, если задано значение x , но без r вы не сможете узнать их имена. Конечно, права доступа к запрошенному файлу также влияют на доступ, поэтому даже с x в каталоге вы не сможете читать файл, если он также не предлагает вам r .

Бит записи означает, что пользователь может писать в каталог, но, естественно, только через саму файловую систему. Это означает, что с установленным параметром w вы можете создавать новые файлы в этом каталоге или редактировать записи каталога существующих файлов. Но без установки x вы фактически не можете использовать какие-либо файлы, а без r вы их также не увидите.

По мере того, как в Unix и ее потомках развивались более сложные модели идентификации пользователей, эти же базовые описания смогли остаться неизменными.

Короче говоря, r означает, что вы можете видеть его содержимое, x означает, что вы можете его использовать, а w означает, что вы можете изменять его даже для каталогов.

Я упомянул, что вы слушаете порт 80 для имени хоста jira, но я предполагаю, что это Apache.

Ниже приведена конфигурация Apache, которую я использую для своего экземпляра JIRA:

<VirtualHost *:80>
    ServerName jira.example.net

        ErrorLog ${APACHE_LOG_DIR}/jira-error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/jira-access.log combined

    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>

    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

    # ProxyRequests Off
    # ProxyPreserveHost on
    # ProxyPass / http://jira.internal.host:8080/ connectiontimeout=5 timeout=300
    # ProxyPassReverse / http://jira.internal.host:8080/
</VirtualHost>
<VirtualHost *:443>
    ServerName jira.undergrid.net

        ErrorLog ${APACHE_LOG_DIR}/jira-error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/jira-access.log combined

    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>

    SSLEngine on
    SSLProxyEngine on
    SSLCertificateFile    /etc/ssl/certs/jira.example.net.crt
    SSLCertificateKeyFile /etc/ssl/private/jira.example.net.key
    SSLCACertificatePath  /etc/ssl/certs/

    ProxyRequests Off
    ProxyPreserveHost on
    ProxyPass / http://jira.internal.host:8080/ connectiontimeout=5 timeout=300
    ProxyPassReverse / http://jira.internal.host:8080/
</VirtualHost>

В моем случае серверы Apache и JIRA работают на двух разных машины, но конфиг может работать независимо от этого. После этого я обновил jira / conf / server.xml , включив в него следующее:

    <Connector port="8080"

               maxThreads="150"
               minSpareThreads="25"
               maxSpareThreads="75"
               connectionTimeout="20000"

               scheme="https"
               proxyName="jira.example.net"
               proxyPort="443"

               enableLookups="false"
               maxHttpHeaderSize="8192"
               protocol="HTTP/1.1"
               useBodyEncodingForURI="true"
               redirectPort="8443"
               acceptCount="100"
               disableUploadTimeout="true"/>

        <Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"
          maxHttpHeaderSize="8192" SSLEnabled="true"
          maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
          enableLookups="false" disableUploadTimeout="true"
          acceptCount="100" scheme="https" secure="true"
          keystoreFile="${user.home}/.keystore" keyAlias="jira.example.net"
          clientAuth="false" sslProtocol="TLS" useBodyEncodingForURI="true"/>

          <Connector port="8009" redirectPort="8443" enableLookups="false" protocol="AJP/1.3" URIEncoding="UTF-8"/>

Последним шагом было обновление базового URL путем входа в JIRA как Администратор JIRA и переходим к Администрирование -> Система -> Общая конфигурация и редактируем Базовый URL до готовности https: / /jira.example.net[12127ght