208.1 Implementando um Web Server (Apache)

Instalação e Comandos Básicos

Vamos ver como implementar um Servidor Web, nesse caso vamos usar o Apache versão 2. O Apache é na verdade uma fundação e o que costumamos chamar de Servidor Web Apache é oficialmente descrito como Servidor HTTP do projeto Apache.

Vamos fazer a instalação do servidor web:

## Redhat like:
$ sudo dnf install httpd

## Debian like:
$ sudo apt install apache2

No Debian like os processos sobem com o nome apache2 e no padrão Redhat é httpd.

ATENÇÃO

Muitas vezes vou citar o termo Redhat Like para me referir a distros baseadas na Redhat, acontece que em algumas versões de distros Redhat existem alterações que não são iguais para todas as distros dessa mesma família, nesse caso vou usar o CentOS 7.

O comando para gerenciar o Apache se chama apachectl para o padrão Redhat e apache2ctl para Debian like, mas mesmo no Debian like existe um link simbólico que se chama apachectl como pode ver abaixo:

$ ls -l /usr/sbin/apachectl
lrwxrwxrwx 1 root root 10 Jun 14 13:30 /usr/sbin/apachectl -> apache2ctl

Esse comando serve para trabalhar com certas funcionalidades do servidor Web Apache, uma dessas é a verificação dos arquivos de configuração, verificar o status do serviço, reiniciar o serviço de modo a não impactar a disponibilidade do servidor Web e alguns outros.

Ao invés de usar esse comando (apachectl) também podemos usar o comando apache2 para Debian like ou httpd para Redhat like.

Processos do Apache

O Apache trabalha com o que chamado de server clients, onde o serviço possui um processo que será o main (ou processo Pai) e ele pode ter vários subprocessos (esses são os processos filhos).

Existe uma diferença entre Redhat e Debian, em ambos o comportamento descrito acima é o mesmo, mas no Debian temos uma forma diferente no funcionamento, cada processo trabalha com threads, isso acontece pela forma que os requests são processados, também chamado de MPM (Multi Process Modules).

Normalmente em Debian like o Apache trabalha no modo event e na Redhat like é prefork:

# Em Debian like:
$ sudo apachectl -V | grep -i mpm
Server MPM:     event

# Em Redhat like:
$ sudo httpd -V | grep -i mpm
Server MPM:     prefork

Vamos ver uma preve explicação sobre isso:

Prefork
É o mais tradicional, aqui temos o processo Pai e os processos Filhos. O processo Pai cuida do gerenciamento dos processos Filhos (abre novos caso precise, fecha etc). Já os processos Filhos tratam as requests que chegam no servidor Web.

Event e Worker
Ambos são muito semelhantes. A diferença entre eles para o Prefork é que o processo Filho possui threads dentro dele, é como um subprocesso do processo filho. A função da thread é a mesma do processo Filho no modo Prefork, aqui é como se o processo filho delegasse o trabalho dele para subprocessos.

Para mais detalhes vá na sessão Fontes e veja os links que começam com ¹.

Podemos ver isso com o comando abaixo:

# Em Debian like:
$ pstree -p | grep apache
           |-apache2(2300)-+-apache2(2302)-+-{apache2}(2305)
           |               |               |-{apache2}(2306)
           |               |               |-{apache2}(2307)
           |               |               |-{apache2}(2308)
           |               |               |-{apache2}(2309)
           |               |               |-{apache2}(2310)
           |               |               |-{apache2}(2311)
           |               |               |-{apache2}(2312)
           |               |               |-{apache2}(2313)
           |               |               |-{apache2}(2314)
           |               |               |-{apache2}(2315)
           |               |               |-{apache2}(2316)
           |               |               |-{apache2}(2317)
           |               |               |-{apache2}(2318)
           |               |               |-{apache2}(2319)
           |               |               |-{apache2}(2320)
           |               |               |-{apache2}(2321)
           |               |               |-{apache2}(2322)
           |               |               |-{apache2}(2323)
           |               |               |-{apache2}(2324)
           |               |               |-{apache2}(2325)
           |               |               |-{apache2}(2326)
           |               |               |-{apache2}(2327)
           |               |               |-{apache2}(2328)
           |               |               |-{apache2}(2329)
           |               |               `-{apache2}(2330)
           |               `-apache2(2303)-+-{apache2}(2332)
           |                               |-{apache2}(2333)
           |                               |-{apache2}(2334)
           |                               |-{apache2}(2335)
           |                               |-{apache2}(2336)
           |                               |-{apache2}(2337)
           |                               |-{apache2}(2338)
           |                               |-{apache2}(2339)
           |                               |-{apache2}(2340)
           |                               |-{apache2}(2341)
           |                               |-{apache2}(2342)
           |                               |-{apache2}(2343)
           |                               |-{apache2}(2344)
           |                               |-{apache2}(2345)
           |                               |-{apache2}(2346)
           |                               |-{apache2}(2347)
           |                               |-{apache2}(2348)
           |                               |-{apache2}(2349)
           |                               |-{apache2}(2350)
           |                               |-{apache2}(2351)
           |                               |-{apache2}(2352)
           |                               |-{apache2}(2353)
           |                               |-{apache2}(2354)
           |                               |-{apache2}(2355)
           |                               |-{apache2}(2356)
           |                               `-{apache2}(2357)

# Em Redhat like:
$ pstree -p | grep httpd
           |-httpd(2331)-+-httpd(2332)
           |             |-httpd(2333)
           |             |-httpd(2334)
           |             |-httpd(2335)
           |             `-httpd(2336)

Cada um desses processos filhos irão tratar as requisições que chegam no servidor Web, enquanto que o processo Pai vai gerenciar os subprocessos (os filhos).

Arquivos de configuração

Os arquivos de configuração mudam de acordo com o Sistema Operacional, em Debian like ficam em /etc/apache2. Já em Redhat like ficam em /etc/httpd.

Dentro desses diretórios temos o arquivo principal da configuração, seu nome também muda de acordo com o sistema. Para Debian like ele fica em /etc/apache2/apache2.conf e para Redhat like está em /etc/httpd/conf/httpd.conf.

Porém nem tudo se concentra nesse diretório principal, isso depende da distribuição também.

# Em Redhat like:
$ ls -lh /etc/httpd/
total 0
drwxr-xr-x. 2 root root  37 Nov 16 20:41 conf
drwxr-xr-x. 2 root root  82 Nov 16 20:41 conf.d
drwxr-xr-x. 2 root root 146 Nov 16 20:41 conf.modules.d
lrwxrwxrwx. 1 root root  19 Nov 16 20:41 logs -> ../../var/log/httpd
lrwxrwxrwx. 1 root root  29 Nov 16 20:41 modules -> ../../usr/lib64/httpd/modules
lrwxrwxrwx. 1 root root  10 Nov 16 20:41 run -> /run/httpd

# Em Debian like:
$ ls -l /etc/apache2/
total 80
-rw-r--r-- 1 root root  7224 Jun 14 13:30 apache2.conf
drwxr-xr-x 2 root root  4096 Nov 16 19:08 conf-available
drwxr-xr-x 2 root root  4096 Nov 16 19:08 conf-enabled
-rw-r--r-- 1 root root  1782 Feb 23  2021 envvars
-rw-r--r-- 1 root root 31063 Feb 23  2021 magic
drwxr-xr-x 2 root root 12288 Nov 16 19:08 mods-available
drwxr-xr-x 2 root root  4096 Nov 16 19:08 mods-enabled
-rw-r--r-- 1 root root   320 Feb 23  2021 ports.conf
drwxr-xr-x 2 root root  4096 Nov 16 19:08 sites-available
drwxr-xr-x 2 root root  4096 Nov 16 19:08 sites-enabled

Com esse resultado acima, podemos ver a diferença entre os dois sistemas operacionais. Além disso, podemos ver também que existe uma parte do nome em pastas com o descritivo de modules ou mods (para Debian).

Isso acontece porque o Apache é um sistema modular, então podemos adicionar ou remover módulo e com isso podemos ativar ou desativar o uso de certos módulos. O padrão de arquitetura para a Redhat é modular, mas não tanto se comparada com o padrão do Debian, do resto é igual.

Segue uma breve descrição sobre as pastas no padrão Redhat:

Arquivo/Diretório	Descrição
conf	Ficam os arquivos de configuração principais, não é recomendado adicionar nenhum arquivo aqui.
httpd	Arquivo de configuração principal.
conf.d	Aqui ficam outros arquivos de configuração que são complementos ao arquivo principal. Aqui sim podemos adicionar novos arquivos.
conf.modules.d	Aqui temos arquivos de configuração específicos para os módulos ativos.

Segue uma breve descrição sobre as pastas no padrão Debian:

Arquivo/Diretório	Descrição
apache2.conf	Arquivo de configuração principal.
conf-available	Arquivos de configuração que temos disponíveis para uso.
conf-enable	Arquivos de configuração que estão em uso.
mods-available	Módulos que temos disponíveis para uso.
mods-enable	Módulos que estão para uso.
sites-available	Sites que temos disponíveis para usar, são arquivos de configuração de sites que vão ser acessados.
sites-enable	Sites que estão em uso, são arquivos de configuração de sites que vão ser acessados.

Com isso o padrão Debian like trás consigo um utilitário chamado a2en alguma coisa, esse utilitário é usado para ativar/desativar algum módulo/configuração.

Utilitário	Descrição
a2enconf	Usado para ativar/desativar configuração.
a2enmod	Usado para ativar/desativar módulos.
a2ensite	Usado para ativar/desativar sites.

Acontece que esses utilitários basicamente criam link simbólicos de arquivos de configuração que estão em pastas que tem no nome available para pastas que tem no nome enable:

# Sites:
$ ls -l /etc/apache2/sites-enabled/
total 0
lrwxrwxrwx 1 root root 35 Nov 16 19:08 000-default.conf -> ../sites-available/000-default.conf

# Confs:
$ ls -l /etc/apache2/conf-enabled/
total 0
lrwxrwxrwx 1 root root 30 Nov 16 19:08 charset.conf -> ../conf-available/charset.conf
lrwxrwxrwx 1 root root 44 Nov 16 19:08 localized-error-pages.conf -> ../conf-available/localized-error-pages.conf
lrwxrwxrwx 1 root root 46 Nov 16 19:08 other-vhosts-access-log.conf -> ../conf-available/other-vhosts-access-log.conf
lrwxrwxrwx 1 root root 31 Nov 16 19:08 security.conf -> ../conf-available/security.conf
lrwxrwxrwx 1 root root 36 Nov 16 19:08 serve-cgi-bin.conf -> ../conf-available/serve-cgi-bin.conf

# Módulos:
$ ls -l /etc/apache2/mods-enabled/ | head -n5
total 0
lrwxrwxrwx 1 root root 36 Nov 16 19:08 access_compat.load -> ../mods-available/access_compat.load
lrwxrwxrwx 1 root root 28 Nov 16 19:08 alias.conf -> ../mods-available/alias.conf
lrwxrwxrwx 1 root root 28 Nov 16 19:08 alias.load -> ../mods-available/alias.load
lrwxrwxrwx 1 root root 33 Nov 16 19:08 auth_basic.load -> ../mods-available/auth_basic.load

Sendo assim podemos usar ou não esses utilitários.

Principais Configurações

As principais configurações ficam no arquivo chamado apache2.conf ou httpd.conf (dependendo do sistema usado). Esse arquivo carrega a maior parte das configurações do servidor Web.

Opção	Descrição
ServerRoot	Localização dos arquivos de configuração.
Listen	Permite especificar a porta ou as portas e IP em que o servidor web vai ficar escutando.
Include	Usado para incluir a configuração de algum arquivo.
User	Usuário que vai ser usado para executar os processos do servidor Web.
Group	Grupo que vai ser usado para executar os processos do servidor Web.
ServerRoot	Específica o e-mail do administrador do servidor Web. Normalmente isso fica comentado e é específicado no arquivo de cada site quando usamos Virtual Hosts.
ServerName	Nome padrão do servidor Web. Normalmente isso fica comentado e é específicado no arquivo de cada site quando usamos Virtual Hosts.
`<Directory DIR_NAME>`	Quando vir isto, é uma forma de fazer com que o servidor Web consiga fornecer o conteúdo desse diretório.
DocumentRoot	Localização dos arquivos que vão ser servidos pelo servidor Web. Existe uma configuração padrão, mas normalmente é específicado no arquivo de cada site quando usamos Virtual Hosts e essa configuração "padrão" pode ser comentada.
`<IfModule MODULE_NAME>`	É um IF para o Apache, se determinado módulo estiver ativo, faça alguma coisa.
Configurações do MPM	As configurações abaixo podem ser adicionadas ao arquivo principal do Apache, mas normalmente ficam no arquivo de configuração do MPM que está em uso.
MaxClients N	Quantos clientes o servidor Web vai tratar simultaneamente.
ThreadsPerChild	Quantas Threads que vamos ter em cada processo filho. Serve apenas nos MPM: `Event`, `Worker` e `Winnt`.
MaxRequestsPerChild ou MaxConnectionsPerChild	Qual é o número máximo de requisições que um processo filho vai poder tratar, após esse limite o processo é eliminado. Definir um valor diferente de zero limita a quantidade de memória que um processo pode consumir por vazamento de memória (algo acidental). Serve nos MPM: `Event`, `Worker` e `Prefork`. O nome `MaxRequestsPerChild` é antigo, mas ainda é suportado.

Sobre a opção Listen, no padrão Debian não fica localizado no arquivo principal, o arquivo principal carrega um outro arquivo contendo essas configurações:
# Include list of ports to listen on
Include ports.conf
Portanto, a configuração de portas fica no arquivo /etc/apache2/ports.conf.

No Debian você pode ver algumas das configurações acimas no arquivo mods-available/mpm_event.conf ou específicar o MPM que estiver usando.

Vejamos algumas configurações que são iguais e existem em diferentes tipos de MPM com diferentes nomes, vale ressaltar que a configuração padrão pode variar do que está na documentação oficial e você deve olhar o que está em /etc/apache2/mods-available/, aqui dentro temos arquivos que começam com mpm_ e temos os principais (Event, Worker e Prefork).

StartServers
Específica quantos processos iniciais o servidor Web vai ter ao ser iniciado, é quantos filhos vão ser iniciados.
Essa mesma opção é usada para os MPM: Event, Worker e Prefork.
MinSpareServers
Se houver menos processos filhos em relação ao que foi específicado e estiverem ociosos, o processo pai criará novos filhos; Ele gerará um, aguardará um segundo, depois gerará dois, aguardará um segundo, depois gerará quatro, e continuará exponencialmente até gerar 32 filhos por segundo.
Ele irá parar sempre que satisfizer a configuração de MinSpareServers.
Essa mesma opção possui outros nomes para os MPM abaixo:
- Worker e Event = MinSpareThreads;
  Número mínimo de threads inativos para lidar com picos de solicitação. Se não houver threads ociosos suficientes no servidor, os processos filhos serão criados até que o número de threads ociosos seja maior que o número específicado.
  Processos/threads adicionais podem ser criados se ListenCoresBucketsRatio estiver habilitado.
- Prefork = MinSpareServers;
MaxSpareServers
Define o número máximo de processos filhos que podem ficar ociosos.
O servidor ainda vai poder abrir mais processos filhos do que o específicado aqui, porém, o servidor vai eliminar os processos mais rapidamente quando eles excederem esse limite e vieram a ficar ociosos.
Essa mesma opção possui outros nomes para os MPM abaixo:
- Worker e Event = MaxSpareThreads;
  Se houver muitos encadeamentos ociosos no servidor, os processos filhos serão eliminados até que o número de encadeamentos ociosos seja menor que o número específicado. Processos/threads adicionais podem ser criados se ListenCoresBucketsRatio estiver habilitado.
- Prefork = MaxSpareServers;

Módulos (php/perl)

Como foi dito mais acima, o Apache trabalha com módulos, então quando queremos determinada funcionalidade temos que ativar o módulo caso já esteja instalado ou seja Builtin do Apache, se não temos que instalar o pacote que fornece suporte e depois ativar.

Basicamente é via instalação de pacotes, mas podemos compilar também caso não tenha a opção de pacotes.

## Redhat like:
$ sudo yum install php

## Debian like:
$ sudo apt install php

Com a instalação desse pacote ele já vai instalar a última versão do PHP disponível no repositório:
$ apt-cache depends php
php
  Depends: php7.4

$ apt-cache depends php7.4
php7.4
 |Depends: libapache2-mod-php7.4
 |Depends: php7.4-fpm
  Depends: php7.4-cgi
  Depends: php7.4-common
Com isso a versão mais recente vai ser instalada. Já a versão mais nova, além de instalar o PHP no servidor, ele instala uma biblioteca como um módulo que provê a compatibilidade entre o PHP e o Apache (libapache2-mod-php7.4).

Outros módulo que normalmente são instalados:

############
### Perl ###
############

## Redhat like:
# Primeiro instale o repositório abaixo:
$ sudo yum install epel-release

# Agora instale o pacote abaixo:
$ sudo yum install mod_perl


## Debian like:
$ sudo apt install libapache2-mod-perl2

Com isso agora temos a compatibilidade com o PHP e podemos ativar o módulo, vejamos os módulos reconhecidos pelo servidor Web:

# Debian like:
$ ls -l /etc/apache2/mods-available/{php7.4.conf,php7.4.load}
-rw-r--r-- 1 root root 855 Nov  2 09:53 /etc/apache2/mods-available/php7.4.conf
-rw-r--r-- 1 root root 102 Nov  2 09:53 /etc/apache2/mods-available/php7.4.load

# Redhat like:
# Arquivo de configuração:
$ ls /etc/httpd/conf.d/php.conf 
/etc/httpd/conf.d/php.conf

# Arquivo similar ao '.Load' no Debian:
$ ls /etc/httpd/conf.modules.d/10-php.conf
/etc/httpd/conf.modules.d/10-php.conf

Analisando o php.conf

Vamos analisar o arquivo de configuração do módulo para entender algumas coisas, vou separar por partes:

## Redhat:
<FilesMatch \.php$>
    SetHandler application/x-httpd-php
</FilesMatch>

## Debian:
<FilesMatch ".+\.ph(ar|p|tml)$">
    SetHandler application/x-httpd-php
</FilesMatch>

FilesMatch
Usado para dar match com um arquivo, se o arquivo tiver o final sendo .php (para Redhat) ou sendo: .phar, .php, .phtml para o Debian. Caso seja algum desses ele vai executar o que está dentro do FilesMatch.
SetHandler application/x-httpd-php
Configura o MIME para application/x-httpd-php. Isso significa que o MIME é do tipo aplicativo (application) e o tipo do arquivo é x-httpd-php.
Os tipos MIME do Apache são usados para informar aos navegadores como lidar com certos tipos de arquivos. Os tipos MIME são uma forma de um conjunto de instruções que informa aos navegadores da Web sobre o tipo de arquivo e como o arquivo será servido ao usuário.
Então se for um arquivo *.php ele é enviado para o navegador e então o tipo MIME application/x-httpd-php também é enviado para o navegador e informa que é um arquivo PHP. Os tipos MIME gerais são adicionados automaticamente ao servidor web.

## Redhat:
AddType text/html .php

AddType
Este módulo é usado para atribuir metadados de conteúdo ao conteúdo selecionado para uma resposta HTTP mapeando padrões no URI ou nomes de arquivos para os valores de metadados.
Em outras palavras, informa que o .php faz parte do MIME Type text/html ou simplificando, é do tipo text/html.

## Redhat:
DirectoryIndex index.php

DirectoryIndex
Informa que o arquivo de index do PHP se chama index.php. Arquivos Index são aqueles que são buscados ao se acessar uma página. Por exemplo, o arquivo Index do html se chama html.index, e ao acessar um site sem específicar nenhum arquivo, por padrão o sistema vai buscar pelo arquivo index.html.

Analisando o load.conf

O método de importar um módulo é igual, o que muda é a forma como isso é feita, se vamos colocar um IF para que o módulo seja importado somente se satisfazer alguma coisa ou não e etc.

Basicamente nós temos: LoadModule Nome do módulo Onde está o módulo.

Numa declaração ficaria assim:

LoadModule php7_module /usr/lib/apache2/modules/libphp7.4.so

Somente isso no padrão Redhat já deve funcionar, mas no Ubuntu ainda temos que fazer um processo além.

Instale e ative o módulo do Python no apache:

$ sudo apt install libapache2-mod-wsgi

Para ativar o módulo modemos fazer assim:

$ sudo a2enmod wsgi

Ou criando o link manualmente:

# Entre na pasta abaixo:
$ cd /etc/apache2/mods-available/

# Crie os links:
$ sudo ln -s /etc/apache2/mods-available/wsgi.conf  ../mods-enabled/
$ sudo ln -s /etc/apache2/mods-available/wsgi.load  ../mods-enabled/

Depois é só reiniciar o serviço do Apache!

Arquivos de Log

Vamos começar vendo onde o Apache armazena os logs:

# Debian:
$ grep -i errorlog /etc/apache2/apache2.conf 
ErrorLog ${APACHE_LOG_DIR}/error.log

# Redhat:
$ grep -i errorlog /etc/httpd/conf/httpd.conf 
ErrorLog "logs/error_log"

Para Redhat é armazenado em /etc/httpd/logs/error_log, isso acontece porque o sistema guarda sempre dentro de ServerRoot. Isso só acontece caso você não adicione a opção de Log no arquivo de VirtualHosts, o padrão serve para Debian e Redhat.

Além disso ainda temos o LogLevel que controla o nível de detalhes que o Log vai ter. Com isso podemos usar o LogFormat para definir o formato dos Logs.

Se você ver um log começando com Pipe | indica que vai ser executado um comando, veja um exemplo:
CustomLog "|/usr/bin/mail -s Apache Log email@exemplo.com.br" combined

Controle de Acesso – Usuário

O Apache permite vários tipos de controle de acesso através de módulos, podemos ver algum deles na saída abaixo:

[root@centos7 ~]# ls -l /etc/httpd/modules/*auth*
-rwxr-xr-x. 1 root root 15336 Mar 24  2022 /etc/httpd/modules/mod_auth_basic.so
-rwxr-xr-x. 1 root root 36088 Mar 24  2022 /etc/httpd/modules/mod_auth_digest.so
-rwxr-xr-x. 1 root root 11160 Mar 24  2022 /etc/httpd/modules/mod_authn_anon.so
-rwxr-xr-x. 1 root root 15376 Mar 24  2022 /etc/httpd/modules/mod_authn_core.so
-rwxr-xr-x. 1 root root 15280 Mar 24  2022 /etc/httpd/modules/mod_authn_dbd.so
-rwxr-xr-x. 1 root root 11200 Mar 24  2022 /etc/httpd/modules/mod_authn_dbm.so
-rwxr-xr-x. 1 root root 11176 Mar 24  2022 /etc/httpd/modules/mod_authn_file.so
-rwxr-xr-x. 1 root root 19552 Mar 24  2022 /etc/httpd/modules/mod_authn_socache.so
-rwxr-xr-x. 1 root root 23752 Mar 24  2022 /etc/httpd/modules/mod_authz_core.so
-rwxr-xr-x. 1 root root 15304 Mar 24  2022 /etc/httpd/modules/mod_authz_dbd.so
-rwxr-xr-x. 1 root root 11216 Mar 24  2022 /etc/httpd/modules/mod_authz_dbm.so
-rwxr-xr-x. 1 root root 11200 Mar 24  2022 /etc/httpd/modules/mod_authz_groupfile.so
-rwxr-xr-x. 1 root root 11192 Mar 24  2022 /etc/httpd/modules/mod_authz_host.so
-rwxr-xr-x. 1 root root 11144 Mar 24  2022 /etc/httpd/modules/mod_authz_owner.so
-rwxr-xr-x. 1 root root  7040 Mar 24  2022 /etc/httpd/modules/mod_authz_user.so

O principal método é via usuário e senha, mas podemos usar LDAP, liberação por IP/Rede e diversos outros métodos.

Na saída acima, quando vemos authn são módulos para autenticação e quando vemos authz são módulos para autorização.

Autenticação verifica se determinada credencial pode ter acesso, enquanto que autorização verifica se uma credencial com acesso pode ter autorização para ver determinado conteúdo por exemplo.

Vamos criar uma página no Apache e colocar autenticação por usuário e senha.

# Entre no diretório abaixo:
$ cd /etc/apache2/sites-available/

# Crie o arquivo com o conteúdo abaixo:
$ sudo cat vagranthome.conf
<VirtualHost *:80>
        ServerAdmin fulano@gmail.com
        DocumentRoot /home/vagrant/
    ServerName test.com.ze

        ErrorLog /var/log/apache2/vagranthome-error.log
        CustomLog /var/log/apache2/vagranthome-access.log combined

    <Directory /home>
        Options Indexes FollowSymLinks
        AllowOverride all
        Require all granted
        </Directory>

    <Directory /home/vagrant>
        AuthType Basic
        AuthName "Home particular"
        AuthUserFile /etc/apache2/.htpasswd
        #AuthGroupFile /etc/apache2/.htgroup
        #Require group suporte
        Require valid-user
        # Require user fulano test
    </Directory>
# FollowSymLinks é para seguir links simbólicos dentro do diretório.
# Indexes mostra o arquivo 'index.html' e quando ele não existir apenas mostra os arquivos que estão no diretório.
</VirtualHost>


# Agora crie o arquivo com a senha:
$ sudo htpasswd -s -c /etc/apache2/.htpasswd fulano

# -s = SHA1 (o padrão é MD5).
# -c = Cria o arquivo.

AllowOverride é usado quando o servidor encontra um arquivo .htaccess, ele precisa saber quais diretivas declaradas nesse arquivo podem substituir diretivas de configuração anteriores.

Quando esta diretiva é definida como All, qualquer diretiva que tenha o Contexto .htaccess é permitida em arquivos .htaccess.

Ao invés de usar Require all grantes podemos usar:
# Fora de uso em versões mais recentes:
Order allow,deny
Allow from all

Agora vamos habilitar a configuração criada e então reiniciar o Apache:

# Habilite a conf:
$ sudo a2ensite vagranthome
Enabling site vagranthome.
To activate the new configuration, you need to run:
  systemctl reload apache2

# Primeiro verifique se existe erro na configuração:
$ sudo apachectl configtest
Syntax OK

# Agora reiniciar o serviço do Apache:
$ sudo systemctl restart apache2

Agora acesse http://test.com.ze e faça um teste (primeiro coloque test.com.ze no seu arquivo hosts).

Controle de Acesso – IP

Vamos ver como fazer o controle de acesso por IP. O método abaixo não será usado por muito tempo, já que é sinalizado como deprecated na documentação oficial.

# Entre no diretório abaixo:
$ cd /etc/apache2/sites-available/

# Crie o arquivo com o conteúdo abaixo:
$ sudo cat vagranthome.conf
<VirtualHost *:80>
        ServerAdmin fulano@gmail.com
        DocumentRoot /home/vagrant/
    ServerName test.com.ze

        ErrorLog /var/log/apache2/vagranthome-error.log
        CustomLog /var/log/apache2/vagranthome-access.log combined

    <Directory /home>
        Options Indexes FollowSymLinks
        AllowOverride all
        Require all granted
        </Directory>

    <Directory /home/vagrant>
        Order deny,allow
        Deny from all
        Allow from 192.168.121.1
    </Directory>
# FollowSymLinks é para seguir links simbólicos dentro do diretório.
# Indexes mostra o arquivo 'index.html' e quando ele não existir apenas mostra os arquivos que estão no diretório.
</VirtualHost>


# Primeiro verifique se existe erro na configuração:
$ sudo apachectl configtest
Syntax OK

# Agora reiniciar o serviço do Apache:
$ sudo systemctl restart apache2

Curiosidades, erros 4XX são erros na origem (cliente) e erros 5XX são erros no servidor.

A nova forma que utilizar é usando os módulos mod_authz_core em conjunto com mod_authz_host.

# Entre no diretório abaixo:
$ cd /etc/apache2/sites-available/

# Crie o arquivo com o conteúdo abaixo:
$ sudo cat vagranthome.conf
<VirtualHost *:80>
        ServerAdmin fulano@gmail.com
        DocumentRoot /home/vagrant/
    ServerName test.com.ze

        ErrorLog /var/log/apache2/vagranthome-error.log
        CustomLog /var/log/apache2/vagranthome-access.log combined

    <Directory /home>
        Options Indexes FollowSymLinks
        AllowOverride all
        Require all granted
        </Directory>

    <Directory /home/vagrant>
        Require ip 192.168.121.1
        Require ip 192.168.121.10
        #Require ip 192.168.121
        #Require ip 192.168.121/24
    </Directory>
# FollowSymLinks é para seguir links simbólicos dentro do diretório.
# Indexes mostra o arquivo 'index.html' e quando ele não existir apenas mostra os arquivos que estão no diretório.
</VirtualHost>


# Primeiro verifique se existe erro na configuração:
$ sudo apachectl configtest
Syntax OK

# Agora reiniciar o serviço do Apache:
$ sudo systemctl restart apache2

Além disso ainda podemos usar o Require host, veja abaixo:

Require host domain.examplo.com

Dessa forma o servidor Web verifica o reverso do IP e se bater com o domínio informado ele vai liberar.

Uma outra técnica interessante é criar um bloco liberando todo mundo menos alguns IPs:

<RequireAll>
  Require all granted
  Require not ip 192.168.200.110
</RequireAll>

VirtualHost

O VirtualHost é uma técnica para fornecer mais de um site no mesmo servidor Web. Existem duas formas de fazer isso, a primeira é via IP e a segunda é via nome de domínio.

Lembrando que por IP o servidor precisará ter mais de um endereço IP.

Já foi usado VirtualHost nos exemplos acima, portanto, não colocarei exemplos aqui.

Caso seja preciso utilizar mais de um endereço no mesmo VirtualHost, isso não pode ser feito via ServerName, que deve ser único dentro do VirtualHost, e sim utilizando o ServerAlias, como no exemplo abaixo:

<VirtualHost *:80>
    ServerName www.example.com
    ServerAlias example.com 
    DocumentRoot "/www/domain"
</VirtualHost>

Mais detalhes na documentação oficial: https://httpd.apache.org/docs/2.4/vhosts/name-based.html

UserDir e Redirecionamentos

O UserDir permite que o Apache crie uma área Web para cada usuário do sistema. Já o redirecionamento é para redirecionar requisições para outro endereço.

O UserDir fica em:

# No CentOS 7:
/etc/httd/conf.d/userdir.conf

# No Debian:
/etc/apache2/mods-available/userdir.conf

Para habilitar basta comentar a opção UserDir disabled e descomentar a opção UserDir public_html. Após aplicar e reiniciar o daemon, cada usuário vai poder ter o diretório chamado public_html que será exibido pelo Apache.

# No Debian:
$ sudo a2enmod userdir

# Reinicie o daemon:
$ sudo systemctl restart apache2

# Não se esqueça de criar a pasta na home do usuário!
# Depois aplique as permissões abaixo:
$ sudo chmod 755 public_html

# Mude também as permissões da Home do usuário:
$ sudo chmod 711 /home/vagrant/

Agora acesse o IP do servidor colocando o ~user, veja um exemplo: http://192.168.121.36/~vagrant

Já o redirecionamento existem duas formas que são as mais simples de fazer, uma com redirect e outra com alias:

# Redirecionar um domínio com alias:
<VirtualHost *:80>
        ServerAdmin fulano@gmail.com
        DocumentRoot /home/vagrant/
    ServerName test.com.ze
    alias /doc /var/www

    <Directory /var/www/>
            Options Indexes FollowSymLinks
            AllowOverride None
            Require all granted
    </Directory>

</VirtualHost>

Dessa forma podemos acessar alguma coisa depois do / que quisermos configurar, para testar faça http://test.com.ze/doc/

Agora vamos fazer um redirecionamento no lado do cliente, quando acessar será automaticamente redirecionado para outro lugar.

Usando RedirectMatch, com ele podemos usar expressão regular.

<VirtualHost *:80>
    ServerAdmin fulano@gmail.com
    DocumentRoot /home/vagrant/
    ServerName test.com.ze
    alias /doc /var/www

    RedirectMatch "^/doc/(.*)$" "https://www.sysnetbr.eng.br/docs/Certificacao/LPIC-2/intro/$1"

</VirtualHost>

Usando Redirect:

<VirtualHost *:80>
    ServerAdmin fulano@gmail.com
    DocumentRoot /home/vagrant/
    ServerName test.com.ze
    
    Redirect /doc "https://www.sysnetbr.eng.br/docs/Certificacao/LPIC-2/intro"

</VirtualHost>

Podemos redirecionar arquivos dentro do site:
Redirect /index.html /index.php
Apenas um exemplo.

O Arquivo .htaccess

As configurações do servidor Web também podem ser realizadas através do arquivo .htaccess. Esse arquivo (Conhecido como "arquivos de configuração distribuídos") fornecem uma maneira de se realizar alterações específicas na configuração por diretório.

Um arquivo contendo uma ou mais diretivas de configuração é colocado em um diretório de documentos específico, e as diretivas se aplicam a esse diretório e a todos os seus subdiretórios.

O nome .htaccess é o nome padrão, mas isso pode ser alterado pela diretiva AccessFileName. É um arquivo muito utilizado por exemplo em hospedagens compartilhadas, quando o administrador de um domínio não tem acesso à administração de todo o servidor web.

As configurações que poderão ser realizadas via arquivos .htaccess serão determinadas pelo que for definido na diretiva AllowOverride. Mais detalhes na documentação oficial: https://httpd.apache.org/docs/2.4/en/howto/htaccess.html