Como inverter um subdomínio de proxy para outro computador na minha LAN, no OS X Server?

Question

Visualize este resultado:

1. site1.example.com - > meu único IP público - > Encaminhamento de porta 80 e 443 para a LAN 192.168.1.10 Mac executando OS X Server 4.1 no OS X 10.10 Yosemite
2. site2.example.com - > meu único IP público - > LAN 192.168.1.10 - > proxy reverso? - > : 80 e: 443 na LAN 192.168.1.15

Isso está em uma rede na qual não tenho opção de adicionar outro IP público.

# 1 já está funcionando perfeitamente.

# 2 é a parte difícil, principalmente porque estou executando o OS X Server em # 1, e a configuração de proxy não parece ser a relativamente direto do Apache , por exemplo :

<VirtualHost *:80 *:443>
     ServerName site2.example.com

     ProxyRequests off
     ProxyPass / http://192.168.1.15/
     ProxyPassReverse / http://192.168.1.15/
</VirtualHost>

Ou seja, o OS X Server tem os arquivos de configuração do Apache em lugares estranhos, e meu entendimento é que ele gosta de sobrescrevê-los com novas alterações feitas na GUI, então estou tentando descobrir o caminho "certo" para faça isso no OS X Server.

Um amigo meu sugeriu que poderia haver uma maneira de fazer isso com o comando webappctl do OS X Server e escrever um webapp.plist apropriado, embora o Work with web apps dos documentos do OS X Server quase não contém detalhes. Olhando para as páginas man que a Apple sugere e seu exemplo de arquivo .plist, parece-me que a idéia de um "aplicativo da web" realmente deseja ser anexada a um diretório (ou seja, site1.exemplo .com / webapp), e não como um subdomínio (como em # 2 , acima). Talvez eu ainda não tenha descoberto a formatação do .plist ainda?

Qual é a maneira "certa" de fazer isso no OS X Server?

    

Answer 1

Esta questão foi originalmente perguntada sobre o Mac OS X Server 4.1, mas como os números de versão do software mudaram, e agora estou trabalhando, esta resposta está escrita a partir do macOS Server 5.2. O Servidor 5 aparentemente muda um pouco as coisas em que todo todo serviço no Servidor está agora atrás de um proxy reverso mestre, então estas instruções não funcionarão com o Servidor 4.1.

Arquivos de configuração

Faça o arquivo de configuração do aplicativo da web na máquina do servidor do macOS, em /Library/Server/Web/Config/apache2/httpd_site2webapp.conf , apontando para o endereço IP do servidor site2 .

ProxyPreserveHost On
ProxyPassReverse / http://192.168.1.15:80/
ProxyPass / http://192.168.1.15:80/
ServerName site2.example.com

Em seguida, em /Library/Server/Web/Config/apache2/webapps/com.example.site2webapp.plist , adicione o seguinte, fazendo referência ao local do arquivo .conf acima:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<!-- See man pages for webapp.plist(5) and webappctl(8) for information about this example webapp.plist -->

<plist version="1.0">
    <dict>
        <key>includeFiles</key>
            <array> <!-- Include files are activated in virtual host when webapp is started -->
                <string>/Library/Server/Web/Config/apache2/httpd_site2webapp.conf</string>
            </array>
        <key>name</key>
            <string>com.example.site2webapp</string>
        <key>displayName</key> <!-- Name shown in Server app -->
            <string>site2WebApp</string>
        <key>installationIndicatorFilePath</key> <!-- The presence of this file indicates web app is installed -->
            <string>/Library/Server/Web/Config/apache2/httpd_site2webapp.conf</string>
        <key>sslPolicy</key><!-- Determines webapp SSL behavior -->
            <integer>0</integer> <!-- 0: default, UseSSLWhenEnabled -->
                                 <!-- 1: UseSSLAlways -->
                                 <!-- 2: UseSSLOnlyWhenCertificateIsTrustable -->
                                 <!-- 3: UseSSLNever -->
                                 <!-- 4: UseSSLAndNonSSL -->
    </dict>
</plist>

Se você também precisar de SSL, coloque também o seguinte em /Library/Server/Web/Config/apache2/httpd_site2SSLwebapp.conf . A configuração difere em que o tráfego de LAN entre os servidores será descriptografado por padrão (esta configuração essencialmente diz ao Servidor para não verificar se existe um certificado válido), mas o tráfego da WAN será criptografado. Acredito que você possa instalar um certificado autoassinado no servidor site2 para o tráfego local criptografado, mas essa configuração ainda ativará o proxy reverso sem precisar ter certificados correspondentes. (Eu admito que há uma maneira mais correta de proteger o tráfego local, mas isso funcionou para mim.)

SSLProxyEngine on
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
ProxyPreserveHost On
ProxyPassReverse / http://192.168.1.15:80/
ProxyPass / http://192.168.1.15:80/
ServerName site2.example.com

E o plist do aplicativo da web SSL correspondente, /Library/Server/Web/Config/apache2/webapps/com.example.site2SSLwebapp.plist , o mesmo que acima:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<!-- See man pages for webapp.plist(5) and webappctl(8) for information about this example webapp.plist -->

<plist version="1.0">
    <dict>
        <key>includeFiles</key>
            <array> <!-- Include files are activated in virtual host when webapp is started -->
                <string>/Library/Server/Web/Config/apache2/httpd_site2SSLwebapp.conf</string>
            </array>
        <key>name</key>
            <string>com.example.site2SSLwebapp</string>
        <key>displayName</key> <!-- Name shown in Server app -->
            <string>site2SSLWebApp</string>
        <key>installationIndicatorFilePath</key> <!-- The presence of this file indicates web app is installed -->
            <string>/Library/Server/Web/Config/apache2/httpd_site2SSLwebapp.conf</string>
        <key>sslPolicy</key><!-- Determines webapp SSL behavior -->
            <integer>0</integer> <!-- 0: default, UseSSLWhenEnabled -->
                                 <!-- 1: UseSSLAlways -->
                                 <!-- 2: UseSSLOnlyWhenCertificateIsTrustable -->
                                 <!-- 3: UseSSLNever -->
                                 <!-- 4: UseSSLAndNonSSL -->
    </dict>
</plist>

Para cada um desses quatro arquivos, as permissões precisam ser owner: root e group: wheel, 644:

$ sudo chown -R root:wheel /path/to/file
$ sudo chmod -R 644 /path/to/file

Configurando o Server.app

Adicione o aplicativo da web aos sites

• Na guia Sites da interface Server.app, clique no + abaixo da listagem de sites para adicionar um novo site
• Insira site2.example.com para o nome de domínio
• Deixar tudo nas configurações padrão
• Clique em Editar configurações avançadas…
• Na seção "Disponibilizar esses aplicativos da web neste site:" marque Ativar para site2WebApp
• Clique em OK
• Clique em Criar

SSL

Se você precisar de SSL na WAN, instale um certificado no Servidor que cubra o novo domínio. Eu usei Vamos criptografar para criar um certificado único que seja bom para os meus site1 e site2 domínios.

• Na guia Certificados do Server.app, clique em + na parte inferior da janela e, em seguida, em Importar uma identidade de certificado…
• Arraste e solte os arquivos .pem que você recebeu de Let's Encrypt (ou quaisquer arquivos de certificado que você tenha) e clique em Importar
• Na guia Sites , crie o novo site quase como antes, mas altere a porta para 443 e, em Certificado SSL, escolha o certificado que você acabou de importar
• Em Editar configurações avançadas… , marque Ativar para site2SSLWebApp

Minha resposta acima foi adaptada das instruções encontradas no link . Aviso: este link faz download de um arquivo zip com PDF e exemplos de arquivos de configuração do aplicativo da Web do servidor. O zip deles também inclui instruções históricas para fazer isso com o Servidor 4.1.

    

Answer 2

Acho que seu amigo pode estar em algo com o caminho webappctl . Mas vamos começar pelo Apache: ao usar o OS X Server, o Apache extrai sua configuração de /Library/Server/Web/Config/apache2 . Esse diretório contém um arquivo ReadMe.txt , que diz em parte:

sites/

This directory contains a file for each enabled virtual host configured for Websites Service by the Server application. Its contents are read by Apache due to several "Include" directives in httpd_server_app.conf.

...

These files are modified by the server-resident part of the Server application and by webappctl(8). Administrators may make changes directly to this file, and to custom virtual host files, but it's strongly recommended that administrator put changes in separate "Include" files and use the webapp.plist(8) mechanism in conjunction with the webappctl(8) command-line tool to manage them. See the editing guidelines at the top of those files.

OK, parece razoável. Olhando mais para dentro desse diretório de configuração do Apache, está o subdiretório sites referenciado, bem como webapps . O último contém um monte de plists descrevendo os serviços da Web do OS X Server, além de um chamado com.example.mywebapp.plist . Bem no topo desse arquivo, há alguns pontos de interesse:

• A chave includeFiles , que parece ter uma matriz de caminhos para personalizar, inclui .conf arquivos que o webapp deseja
• A chave proxies , que mapeia para o Apache ProxyPass / ProxyPassReverse diretivas para outro aplicativo

Embora eu mesmo não tenha testado isso, minha sugestão é tentar adicionar um plist ao diretório usando o mesmo esquema de nomenclatura de DNS reverso: copie com.example.mywebapp.plist para com.example.site2.plist . Depois de ter sua própria cópia, você pode cortar a maioria dos bits desnecessários e, em seguida, ajustar o valor de proxies para se referir a sua própria URL, em vez do caminho de exemplo que eles têm.

Se isso não funcionar, você poderia aplicar um martelo um pouco maior e criar um arquivo .conf includable que tenha suas diretivas Apache diretas a partir da pergunta nele, colocando-o dentro do diretório de configuração Apache do Server. Uma vez feito isso, elimine a chave proxies do seu aplicativo web, e use a tecla includeFiles para extrair o arquivo .conf .

De qualquer forma, assim que o aplicativo da web estiver pronto, use webappctl (como root) para iniciar o aplicativo recém-criado:

$ sudo webappctl start com.example.site2

Isso deve ser bem-sucedido (retornar o código de saída 0) ou - esperançosamente - falhar com algumas informações com as quais você pode refinar o aplicativo da web. (Novamente, isso é tudo não testado, e é apenas um ponto para começar.)

Se você acabar usando um arquivo .conf customizado que você referenciou da aplicação web, também não é uma má ideia manter um backup desse arquivo em algum lugar, para que o futuro OS X ou Server.app não seja atualizado não apague. Enquanto o Apache do servidor ReadMe.txt não diz explicitamente que eles irão apagar configurações geradas pelo usuário, ele também não diz que eles não . É melhor prevenir do que remediar.

Boa sorte!