One place for hosting & domains

      servidor

      Como Fazer o Benchmark de um Servidor Redis no Ubuntu 18.04


      Introdução

      O Benchmarking é uma prática importante quando se trata de analisar o desempenho geral dos servidores de banco de dados. É útil para identificar gargalos e oportunidades de melhoria nesses sistemas.

      O Redis é um armazenamento de estrutura dados em memória que pode ser usado como banco de dados, cache e intermediador de mensagens ou message broker. Ele suporta desde estruturas de dados simples a complexas, incluindo hashes, strings, conjuntos classificados, bitmaps, dados geoespaciais, entre outros tipos. Neste guia, demonstraremos como fazer o benchmark de um servidor Redis em execução no Ubuntu 18.04, usando algumas ferramentas e métodos distintos.

      Pré-requisitos

      Para seguir este guia, você precisará de:

      Nota: Os comandos demonstrados neste tutorial foram executados em um servidor Redis dedicado rodando em um Droplet da DigitalOcean de 4 GB.

      Usando a ferramenta incluída redis-benchmark

      O Redis vem com uma ferramenta de benchmark chamada redis-benchmark. Este programa pode ser usado para simular um número arbitrário de clientes se conectando ao mesmo tempo e executando ações no servidor, medindo quanto tempo leva para que as solicitações sejam concluídas. Os dados resultantes vão lhe fornecer uma ideia do número médio de solicitações que o seu servidor Redis é capaz de processar por segundo.

      A lista a seguir detalha algumas das opções de comando comuns usadas com o redis-benchmark:

      • -h: Host do Redis. O padrão é 127.0.0.1.
      • -p: Porta do Redis. O padrão é 6379.
      • -a: Se o seu servidor exigir autenticação, você poderá usar esta opção para fornecer a senha.
      • -c: Número de clientes (conexões paralelas) a serem simulados. O valor padrão é 50.
      • -n: Quantas requisições a fazer. O padrão é 100000.
      • -d: Tamanho dos dados para os valores de SET e GET, medidos em bytes. O padrão é 3.
      • -t: Execute apenas um subconjunto de testes. Por exemplo, você pode usar -t get,set para fazer o benchmark dos comandos GET e SET.
      • -q: Modo silencioso, mostra apenas a informação sobre média de requisições por segundo.

      Por exemplo, se você deseja verificar o número médio de solicitações por segundo que o seu servidor Redis local pode suportar, você pode usar:

      Você obterá resultados semelhantes a este, mas com números diferentes:

      Output

      PING_INLINE: 85178.88 requests per second PING_BULK: 83056.48 requests per second SET: 72202.16 requests per second GET: 94607.38 requests per second INCR: 84961.77 requests per second LPUSH: 78988.94 requests per second RPUSH: 88652.48 requests per second LPOP: 87950.75 requests per second RPOP: 80971.66 requests per second SADD: 80192.46 requests per second HSET: 84317.03 requests per second SPOP: 78125.00 requests per second LPUSH (needed to benchmark LRANGE): 84175.09 requests per second LRANGE_100 (first 100 elements): 52383.45 requests per second LRANGE_300 (first 300 elements): 21547.08 requests per second LRANGE_500 (first 450 elements): 14471.78 requests per second LRANGE_600 (first 600 elements): 9383.50 requests per second MSET (10 keys): 71225.07 requests per second

      Você também pode limitar os testes a um subconjunto de comandos de sua escolha usando o parâmetro -t. O comando a seguir mostra as médias apenas dos comandos GET eSET:

      • redis-benchmark -t set,get -q

      Output

      SET: 76687.12 requests per second GET: 82576.38 requests per second

      As opções padrão usarão 50 conexões paralelas para criar 100000 requisições ao servidor Redis. Se você deseja aumentar o número de conexões paralelas para simular um pico de uso, pode usar a opção -c para isso:

      • redis-benchmark -t set,get -q -c 1000

      Como isso usará 1000 conexões simultâneas em vez das 50 padrão, você deve esperar uma diminuição no desempenho:

      Output

      SET: 69444.45 requests per second GET: 70821.53 requests per second

      Se você quiser informações detalhadas na saída, poderá remover a opção -q. O comando a seguir usará 100 conexões paralelas para executar 1000000 requisições SET no servidor:

      • redis-benchmark -t set -c 100 -n 1000000

      Você obterá uma saída semelhante a esta:

      Output

      ====== SET ====== 1000000 requests completed in 11.29 seconds 100 parallel clients 3 bytes payload keep alive: 1 95.22% <= 1 milliseconds 98.97% <= 2 milliseconds 99.86% <= 3 milliseconds 99.95% <= 4 milliseconds 99.99% <= 5 milliseconds 99.99% <= 6 milliseconds 100.00% <= 7 milliseconds 100.00% <= 8 milliseconds 100.00% <= 8 milliseconds 88605.35 requests per second

      As configurações padrão usam 3 bytes para valores de chave. Você pode mudar isso com a opção -d. O comando a seguir fará o benchmark dos comandos GET e SET usando valores de chave de 1 MB:

      • redis-benchmark -t set,get -d 1000000 -n 1000 -q

      Como o servidor está trabalhando com um payload muito maior dessa vez, espera-se uma diminuição significativa do desempenho:

      Output

      SET: 1642.04 requests per second GET: 822.37 requests per second

      É importante perceber que, embora esses números sejam úteis como uma maneira rápida de avaliar o desempenho de uma instância Redis, eles não representam a taxa de transferência máxima que uma instância Redis pode suportar. Usando pipelining, as aplicações podem enviar vários comandos ao mesmo tempo para melhorar o número de requisições por segundo que o servidor pode manipular. Com o redis-benchmark, você pode usar a opção -P para simular aplicações do mundo real que fazem uso desse recurso do Redis.

      Para comparar a diferença, primeiro execute o comando redis-benchmark com valores padrão e sem pipelining, para os testes GET e SET:

      • redis-benchmark -t get,set -q

      Output

      SET: 86281.27 requests per second GET: 89847.26 requests per second

      O próximo comando executará os mesmos testes, mas fará o pipeline de 8 comandos juntos:

      • redis-benchmark -t get,set -q -P 8

      Output

      SET: 653594.81 requests per second GET: 793650.75 requests per second

      Como você pode ver na saída, há uma melhoria substancial no desempenho com o uso de pipelining.

      Se você deseja uma medição simples do tempo médio que uma requisição leva para receber uma resposta, você pode usar o cliente Redis para verificar a latência média do servidor. No contexto do Redis, latência é uma medida de quanto tempo um comando ping leva para receber uma resposta do servidor.

      O comando a seguir mostrará estatísticas de latência em tempo real para seu servidor Redis:

      Você obterá uma saída semelhante a esta, mostrando um número crescente de amostras e uma latência média variável:

      Output

      min: 0, max: 1, avg: 0.18 (970 samples)

      Este comando continuará sendo executado indefinidamente. Você pode pará-lo com um CTRL+C.

      Para monitorar a latência por um determinado período, você pode usar:

      • redis-cli --latency-history

      Isso irá acompanhar as médias de latência ao longo do tempo, com um intervalo configurável definido como 15 segundos por padrão. Você obterá uma saída semelhante a esta:

      Output

      min: 0, max: 1, avg: 0.18 (1449 samples) -- 15.01 seconds range min: 0, max: 1, avg: 0.16 (1449 samples) -- 15.00 seconds range min: 0, max: 1, avg: 0.17 (1449 samples) -- 15.00 seconds range min: 0, max: 1, avg: 0.17 (1444 samples) -- 15.01 seconds range min: 0, max: 1, avg: 0.17 (1446 samples) -- 15.01 seconds range min: 0, max: 1, avg: 0.17 (1449 samples) -- 15.00 seconds range min: 0, max: 1, avg: 0.16 (1444 samples) -- 15.00 seconds range min: 0, max: 1, avg: 0.17 (1445 samples) -- 15.01 seconds range min: 0, max: 1, avg: 0.16 (1445 samples) -- 15.01 seconds range …

      Como o servidor Redis em nosso exemplo está ocioso, não há muita variação entre as amostras de latência. Se você tem um pico de uso, no entanto, isso deve ser refletido como um aumento na latência dentro dos resultados.

      Se você deseja medir apenas a latência do sistema, pode usar --intrinsic-latency para isso. A latência intrínseca é inerente ao ambiente, dependendo de fatores como hardware, kernel, vizinhança do servidor e outros fatores que não são controlados pelo Redis.

      Você pode ver a latência intrínseca como uma linha de base para o desempenho geral do Redis. O comando a seguir verificará a latência intrínseca do sistema, executando um teste por 30 segundos:

      • redis-cli --intrinsic-latency 30

      Você deve obter uma saída semelhante a esta:

      Output

      … 498723744 total runs (avg latency: 0.0602 microseconds / 60.15 nanoseconds per run). Worst run took 22975x longer than the average latency.

      Comparar os dois testes de latência pode ser útil para identificar gargalos de hardware ou sistema que podem afetar o desempenho do seu servidor Redis. Considerando que a latência total de uma requisição para o nosso servidor de exemplo tem uma média de 0,18 microssegundos para concluir, uma latência intrínseca de 0,06 microssegundos significa que um terço do tempo total da requisição é gasto pelo sistema em processos que não são controlados pelo Redis.

      Usando a Ferramenta Memtier Benchmark

      O Memtier é uma ferramenta de benchmark de alto rendimento para Redis e Memcached criada pelo Redis Labs. Embora muito parecido com o redis-benchmark em vários aspectos, o Memtier possui várias opções de configuração que podem ser ajustadas para emular melhor o tipo de carga que você pode esperar no seu servidor Redis, além de oferecer suporte a cluster.

      Para instalar o Memtier em seu servidor, você precisará compilar o software a partir do código-fonte. Primeiro, instale as dependências necessárias para compilar o código:

      • sudo apt-get install build-essential autoconf automake libpcre3-dev libevent-dev pkg-config zlib1g-dev

      Em seguida, vá para o seu diretório home e clone o projeto memtier_benchmark do repositório Github:

      • cd
      • git clone https://github.com/RedisLabs/memtier_benchmark.git

      Navegue para o diretório do projeto e execute o comando autoreconf para gerar os scripts de configuração do aplicativo:

      • cd memtier_benchmark
      • autoreconf -ivf

      Execute o script configure para gerar os artefatos do aplicativo necessários para a compilação:

      Agora execute make para compilar o aplicativo:

      Após a conclusão da compilação, você pode testar o executável com:

      • ./memtier_benchmark --version

      Isso lhe fornecerá a seguinte saída:

      Output

      memtier_benchmark 1.2.17 Copyright (C) 2011-2017 Redis Labs Ltd. This is free software. You may redistribute copies of it under the terms of the GNU General Public License <http://www.gnu.org/licenses/gpl.html>. There is NO WARRANTY, to the extent permitted by law.

      A lista a seguir contém algumas das opções mais comuns usadas com o comando memtier_benchmark:

      • -s: Host do Servidor. O padrão é localhost.
      • -p: Porta do Servidor. O padrão é 6379.
      • -a: Autentica requisições usando a senha fornecida.
      • -n: Número de requisições por cliente (o padrão é 10000).
      • -c: Número de clientes (o padrão é 50).
      • -t: Número de threads (o padrão é 4).
      • --pipeline: Ativar pipelining.
      • --ratio: Relação entre os comandos SET e GET, o padrão é 1:10.
      • --hide-histogram: Oculta informações detalhadas de saída.

      A maioria dessas opções é muito semelhante às opções presentes no redis-benchmark, mas o Memtier testa o desempenho de uma maneira diferente. Para simular melhor os ambientes comuns do mundo real, o benchmark padrão realizado pelo memtier_benchmark testará apenas as solicitações GET e SET, na proporção de 1 a 10. Com 10 operações GET para cada operação SET no teste, esse arranjo é mais representativo de uma aplicação web comum usando o Redis como banco de dados ou cache. Você pode ajustar o valor da taxa com a opção --ratio.

      O comando a seguir executa o memtier_benchmark com as configurações padrão, fornecendo apenas informações de saída de alto nível:

      • ./memtier_benchmark --hide-histogram

      Nota: se você configurou seu servidor Redis para exigir autenticação, você deve fornecer a opção -a junto com sua senha Redis ao comando memtier_benchmark:

      • ./memtier_benchmark --hide-histogram -a sua_senha_redis

      Você verá resultados semelhantes a este:

      Output

      … 4 Threads 50 Connections per thread 10000 Requests per client ALL STATS ========================================================================= Type Ops/sec Hits/sec Misses/sec Latency KB/sec ------------------------------------------------------------------------- Sets 8258.50 --- --- 2.19800 636.05 Gets 82494.28 41483.10 41011.18 2.19800 4590.88 Waits 0.00 --- --- 0.00000 --- Totals 90752.78 41483.10 41011.18 2.19800 5226.93

      De acordo com esta execução do memtier_benchmark, nosso servidor Redis pode executar cerca de 90 mil operações por segundo na proporção 1:10 SET/GET.

      É importante observar que cada ferramenta de benchmark possui seu próprio algoritmo para teste de desempenho e apresentação de dados. Por esse motivo, é normal ter resultados ligeiramente diferentes no mesmo servidor, mesmo utilizando configurações semelhantes.

      Conclusão

      Neste guia, demonstramos como executar testes de benchmark em um servidor Redis usando duas ferramentas distintas: o redis-benchmark incluído e a ferramenta memtier_benchmark desenvolvida pelo Redis Labs. Também vimos como verificar a latência do servidor usando redis-cli. Com base nos dados obtidos com esses testes, você entenderá melhor o que esperar do servidor Redis em termos de desempenho e quais são os gargalos da sua configuração atual.



      Source link

      Como Instalar o Servidor Web Apache no CentOS 7


      Introdução

      O servidor HTTP Apache é o servidor web mais utilizado no mundo. Ele fornece muitos recursos poderosos incluindo módulos dinamicamente carregáveis, suporte robusto a mídia, e integração extensiva com outros softwares populares.

      Neste guia, você instalará um servidor web Apache com virtual hosts em seu servidor CentOS 7.

      Pré-requisitos

      Você precisará do seguinte para concluir este guia:

      Passo 1 — Instalando o Apache

      O Apache está disponível nos repositórios de software padrão do CentOS, o que significa que você pode instalá-lo com o gerenciador de pacotes yum.

      Agindo como o usuário não-root, com privilégios sudo configurado nos pré-requisitos, atualize o índice de pacotes local httpd do Apache para refletir as alterações mais recentes do upstream:

      Depois que os pacotes forem atualizados, instale o pacote Apache:

      Após confirmar a instalação, o yum instalará o Apache e todas as dependências necessárias. Quando a instalação estiver concluída, você estará pronto para iniciar o serviço.

      Passo 2 — Verificando seu Servidor Web

      O Apache não inicia automaticamente no CentOS depois que a instalação é concluída. Você precisará iniciar o processo do Apache manualmente:

      • sudo systemctl start httpd

      Verifique se o serviço está sendo executado com o seguinte comando:

      • sudo systemctl status httpd

      Você verá um status active quando o serviço estiver em execução:

      Output

      Redirecting to /bin/systemctl status httpd.service ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2019-02-20 01:29:08 UTC; 5s ago Docs: man:httpd(8) man:apachectl(8) Main PID: 1290 (httpd) Status: "Processing requests..." CGroup: /system.slice/httpd.service ├─1290 /usr/sbin/httpd -DFOREGROUND ├─1291 /usr/sbin/httpd -DFOREGROUND ├─1292 /usr/sbin/httpd -DFOREGROUND ├─1293 /usr/sbin/httpd -DFOREGROUND ├─1294 /usr/sbin/httpd -DFOREGROUND └─1295 /usr/sbin/httpd -DFOREGROUND ...

      Como você pode ver nesta saída, o serviço parece ter sido iniciado com sucesso. No entanto, a melhor maneira de testar isso é solicitar uma página do Apache.

      Você pode acessar a página inicial padrão do Apache para confirmar que o software está sendo executado corretamente através do seu endereço IP. Se você não souber o endereço IP do seu servidor, poderá obtê-lo de algumas maneiras diferentes a partir da linha de comando.

      Digite isto no prompt de comando do seu servidor:

      Esse comando exibirá todos os endereços de rede do host, assim você receberá um retorno com alguns endereços IP separados por espaços. Você pode experimentar cada um em seu navegador para ver se eles funcionam.

      Alternativamente, você pode usar o curl para solicitar seu IP através do icanhazip.com, que lhe dará seu endereço IPv4 público como visto de outro local na internet:

      Quando você tiver o endereço IP do seu servidor, insira-o na barra de endereços do seu navegador:

      http://ip_do_seu_servidor
      

      Você verá a página padrão do Apache do CentOS 7:

      Default Apache page for CentOS 7

      Esta página indica que o Apache está funcionando corretamente. Ela também inclui algumas informações básicas sobre arquivos importantes do Apache e sobre localizações de diretórios. Agora que o serviço está instalado e em execução, você pode usar diferentes comandos systemctl para gerenciar o serviço.

      Passo 3 — Gerenciando o Processo do Apache

      Agora que você tem seu servidor web funcionando, vamos passar por alguns comandos básicos de gerenciamento.

      Para parar seu servidor web, digite:

      • sudo systemctl stop httpd

      Para iniciar o servidor web quando ele estiver parado, digite:

      • sudo systemctl start httpd

      Para parar e iniciar o serviço novamente, digite:

      • sudo systemctl restart httpd

      Se você estiver simplesmente fazendo alterações de configuração, o Apache pode muita vezes recarregar sem perder conexões. Para fazer isso, use este comando:

      • sudo systemctl reload httpd

      Por padrão, o Apache é configurado para iniciar automaticamente quando o servidor é inicializado. Se isso não é o que você deseja, desabilite esse comportamento digitando:

      • sudo systemctl disable httpd

      Para reativar o serviço para iniciar na inicialização, digite:

      • sudo systemctl enable httpd

      O Apache agora será iniciado automaticamente quando o servidor inicializar novamente.

      A configuração padrão do Apache permitirá que seu servidor hospede um único site. Se você planeja hospedar vários domínios em seu servidor, precisará configurar virtual hosts em seu servidor Apache.

      Passo 4 — Configurando Virtual Hosts (Recomendado)

      Ao utilizar o servidor web Apache, você pode usar virtual hosts (similares aos blocos do servidor no Nginx) para encapsular detalhes de configuração e hospedar mais de um domínio a partir de um único servidor. Neste passo você irá configurar um domínio chamado example.com, mas você deve substituí-lo por seu próprio nome de domínio. Para aprender mais sobre a configuração de um nome de domínio com a DigitalOcean, veja nossa Introdução ao DNS da DigitalOcean.

      O Apache no CentOS 7 tem um bloco de servidor ativado por padrão que é configurado para servir documentos a partir do diretório /var/www/html. Apesar disso funcionar bem para um único site, pode ficar difícil se você estiver hospedando vários sites. Em vez de modificar /var/www/html, você irá criar uma estrutura de diretórios dentro de /var/www para o site example.com, deixando /var/www/html no lugar como o diretório padrão a ser servido se uma requisição de cliente não corresponder a nenhum outro site.

      Crie o diretório html para example.com como segue, usando a flag -p para criar qualquer diretório pai que for necessário:

      • sudo mkdir -p /var/www/example.com/html

      Crie um diretório adicional para armazenar arquivos de log para o site:

      • sudo mkdir -p /var/www/example.com/log

      Em seguida, atribua a propriedade do diretório html com a variável de ambiente $USER:

      • sudo chown -R $USER:$USER /var/www/example.com/html

      Certifique-se de que seu web root ou pasta raiz para web tenha o conjunto de permissões padrão:

      • sudo chmod -R 755 /var/www

      Em seguida, crie uma página de exemplo index.html usando o vi ou seu editor favorito:

      • sudo vi /var/www/example.com/html/index.html

      Pressione i para alternar para o modo INSERT e adicione o seguinte exemplo de HTML ao arquivo:

      /var/www/example.com/html/index.html

      <html>
        <head>
          <title>Welcome to Example.com!</title>
        </head>
        <body>
          <h1>Success! The example.com virtual host is working!</h1>
        </body>
      </html>
      

      Salve e feche o arquivo pressionando ESC, digitando :wq e pressionando ENTER.

      Com o diretório do seu site e o arquivo de index de exemplo no lugar, você está quase pronto para criar os arquivos do virtual host. Os arquivos do virtual host especificam a configuração de seus sites independentes e informam ao servidor Apache como responder a várias solicitações de domínio.

      Antes de criar seus virtual hosts, você precisará criar um diretório sites-available para armazená-los. Você também criará o diretório sites-enabled que informa ao Apache que um virtual host está pronto para servir aos visitantes. O diretório sites-enabled conterá links simbólicos para os virtual hosts que queremos publicar. Crie ambos os diretórios com o seguinte comando:

      • sudo mkdir /etc/httpd/sites-available /etc/httpd/sites-enabled

      Em seguida, você dirá ao Apache para procurar por virtual hosts no diretório sites-enabled. Para fazer isso, edite o arquivo de configuração principal do Apache e adicione uma linha declarando um diretório opcional para arquivos de configuração adicionais:

      • sudo vi /etc/httpd/conf/httpd.conf

      Adicione esta linha ao final do arquivo:

      IncludeOptional sites-enabled/*.conf
      

      Salve e feche o arquivo quando terminar de adicionar essa linha. Agora que você tem seus diretórios de virtual host no lugar, você criará seu arquivo de virtual host.

      Comece criando um novo arquivo no diretório sites-available:

      • sudo vi /etc/httpd/sites-available/example.com.conf

      Adicione o seguinte bloco de configuração e altere o domínio example.com para o seu nome de domínio:

      /etc/httpd/sites-available/example.com.conf

      <VirtualHost *:80>
          ServerName www.example.com
          ServerAlias example.com
          DocumentRoot /var/www/example.com/html
          ErrorLog /var/www/example.com/log/error.log
          CustomLog /var/www/example.com/log/requests.log combined
      </VirtualHost>
      

      Isso dirá ao Apache onde encontrar diretamente a raiz que contém os documentos web publicamente acessíveis. Ele também informa ao Apache onde armazenar logs de erros e de solicitações para esse site específico.

      Salve e feche o arquivo quando terminar.

      Agora que você criou os arquivos do virtual host, você os habilitará para que o Apache saiba como servi-los aos visitantes. Para fazer isso, crie um link simbólico para cada virtual host no diretório sites-enabled:

      • sudo ln -s /etc/httpd/sites-available/example.com.conf /etc/httpd/sites-enabled/example.com.conf

      Seu virtual host agora está configurado e pronto para servir conteúdo. Antes de reiniciar o serviço Apache, vamos garantir que o SELinux tenha as políticas corretas em vigor para seus virtual hosts.

      Passo 5 — Ajustando Permissões do SELinux para Virtual Hosts (Recomendado)

      O SELinux está configurado para funcionar com a configuração padrão do Apache. Como você configurou um diretório de log personalizado no arquivo de configuração de virtual hosts, você receberá um erro se tentar iniciar o serviço Apache. Para resolver isso, você precisa atualizar as políticas do SELinux para permitir que o Apache grave nos arquivos necessários. O SELinux traz maior segurança ao seu ambiente CentOS 7, portanto, não é recomendado desativar completamente o módulo do kernel.

      Existem diferentes maneiras de definir políticas com base nas necessidades do seu ambiente, pois o SELinux permite que você personalize seu nível de segurança. Esta etapa abordará dois métodos de ajuste das políticas do Apache: universalmente e em um diretório específico. Ajustar políticas em diretórios é mais seguro e, portanto, é a abordagem recomendada.

      Ajustando Políticas do Apache Universalmente

      Definir a política do Apache universalmente dirá ao SELinux para tratar todos os processos do Apache de forma idêntica usando o booleano httpd_unified. Embora essa abordagem seja mais conveniente, ela não fornecerá o mesmo nível de controle que uma abordagem centrada em uma diretiva de arquivo ou diretório.

      Execute o seguinte comando para definir uma política universal para o Apache:

      • sudo setsebool -P httpd_unified 1

      O comando setsebool altera os valores booleanos do SELinux. A flag -P atualizará o valor de tempo de inicialização, fazendo com que essa mudança persista durante as reinicializações. httpd_unified é o booleano que irá dizer ao SELinux para tratar todos os processos do Apache como do mesmo tipo, então você habilitou-o com um valor de 1.

      Ajustando as Políticas do Apache em um Diretório

      Configurar individualmente as permissões do SELinux para o diretório /var/www/example.com/log lhe dará mais controle sobre suas políticas do Apache, mas também pode exigir mais manutenção. Como essa opção não está definindo políticas universalmente, você precisará definir manualmente o tipo de contexto para todos os novos diretórios de log especificados em suas configurações de virtual host.

      Primeiro, verifique o tipo de contexto que o SELinux deu ao diretório /var/www/example.com/log:

      • sudo ls -dZ /var/www/example.com/log/

      Este comando lista e imprime o contexto do SELinux do diretório. Você verá uma saída semelhante à seguinte:

      Output

      drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/example.com/log/

      O contexto atual é httpd_sys_content_t, que informa ao SELinux que o processo do Apache só pode ler arquivos criados neste diretório. Neste tutorial, você irá alterar o tipo de contexto do diretório /var/www/example.com/log para httpd_log_t. Esse tipo permitirá ao Apache gerar e agregar arquivos de log da aplicação web:

      • sudo semanage fcontext -a -t httpd_log_t "/var/www/example.com/log(/.*)?"

      Em seguida, use o comando restorecon para aplicar essas mudanças e fazer com que elas persistam durante as reinicializações:

      • sudo restorecon -R -v /var/www/example.com/log

      A flag -R executa este comando recursivamente, o que significa que ele atualizará quaisquer arquivos existentes para usar o novo contexto. A flag -v imprimirá as mudanças de contexto feitas pelo comando. Você verá a seguinte saída confirmando as alterações:

      Output

      restorecon reset /var/www/example.com/log context unconfined_u:object_r:httpd_sys_content_t:s0->unconfined_u:object_r:httpd_log_t:s0

      Você pode listar os contextos mais uma vez para ver as alterações:

      • sudo ls -dZ /var/www/example.com/log/

      A saída reflete o tipo de contexto atualizado:

      Output

      drwxr-xr-x. root root unconfined_u:object_r:httpd_log_t:s0 /var/www/example.com/log

      Agora que o diretório /var/www/example.com/log está usando o tipo httpd_log_t, você está pronto para testar sua configuração de virtual host.

      Passo 6 — Testando o Virtual Host (Recomendado)

      Uma vez que o contexto do SELinux tenha sido atualizado com quaisquer dos métodos, o Apache poderá gravar no diretório /var/www/example.com/log. Agora você pode reiniciar o serviço Apache com sucesso:

      • sudo systemctl restart httpd

      Liste o conteúdo do diretório /var/www/example.com/log para ver se o Apache criou os arquivos de log:

      • ls -lZ /var/www/example.com/log

      Você verá que o Apache foi capaz de criar os arquivos error.log e requests.log especificados na configuração do virtual host:

      Output

      -rw-r--r--. 1 root root 0 Feb 26 22:54 error.log -rw-r--r--. 1 root root 0 Feb 26 22:54 requests.log

      Agora que você tem seu virtual host configurado e as permissões do SELinux atualizadas, o Apache agora servirá seu nome de domínio. Você pode testar isso navegando até http://example.com, onde você deve ver algo assim:

      Success! The example.com virtual host is working!

      Isso confirma que seu virtual host foi configurado e está servindo o conteúdo com êxito. Repita os Passos 4 e 5 para criar novos virtual hosts com permissões do SELinux para domínios adicionais.

      Conclusão

      Neste tutorial, você instalou e gerenciou o servidor web Apache. Agora que você tem seu servidor web instalado, você tem muitas opções para o tipo de conteúdo que você pode servir e as tecnologias que você pode usar para criar uma experiência mais rica.

      Se você quiser criar uma pilha ou stack de aplicação mais completa, consulte este artigo sobre como configurar uma pilha LAMP no CentOS 7.



      Source link

      Configuração Inicial do Servidor com o CentOS 7


      Introdução

      Quando você cria inicialmente um novo servidor, existem alguns passos de configuração que você deve tomar no início como parte da configuração básica. Isto aumentará a segurança e a usabilidade do seu servidor e dará uma sólida fundação para as ações subsequentes.

      Passo Um — Efetuando login como Root

      Para fazer login em seu servidor, você precisará saber o endereço IP público dele e a senha da conta do usuário “root”. Se você ainda não fez login no seu servidor, talvez queira seguir o primeiro tutorial desta série, Como se Conectar ao seu Drolet com SSH, que cobre este processo detalhadamente.

      Se você ainda não está conectado ao seu servidor, vá em frente e faça login como o usuário root usando o seguinte comando (substitua a palavra realçada pelo endereço IP público do seu servidor):

      • ssh root@ENDEREÇO_IP_DO_SERVIDOR

      Conclua o processo de login aceitando o aviso sobre a autenticidade do host, se ele aparecer, e em seguida, fornecendo sua autenticação para o root (senha ou chave privada). Se esta for a primeira vez que você efetua login no servidor com uma senha, você também será solicitado a alterar a senha do root.

      Sobre o Root

      O usuário root é o usuário administrativo em um ambiente Linux que possui privilégios muito amplos. Devido aos privilégios elevados da conta root, na verdade você é desencorajado de utilizá-la regularmente. Isto é porque parte do poder inerente à conta root é a capacidade de realizar alterações muito destrutivas, mesmo por acidente.

      O próximo passo é configurar uma conta de usuário alternativa com um escopo reduzido de poderes para o trabalho diário. Vamos ensiná-lo como obter aumento de privilégios durante os momentos em que você precisar deles.

      Passo Dois — Criando um Novo Usuário

      Uma vez conectado como root, estamos preparados para adicionar uma nova conta de usuário que utilizaremos para efetuar logon de agora em diante.

      Este exemplo cria um novo usuário chamado “demo”, mas você deve substituí-lo por um nome de usuário de sua escolha:

      Em seguida, atribua uma senha ao novo usuário (novamente, substitua "demo" pelo nome de usuário que você acabou de criar):

      Digite uma senha forte e repita-a novamente para verificá-la.

      Passo Três — Privilégios de Root

      Agora, temos uma nova conta de usuário com privilégios regulares de conta. No entanto, às vezes podemos precisar fazer tarefas administrativas.

      Para evitar de ter que desconectar nosso usuário regular e efetuar logon novamente com a conta de root, podemos configurar o que é conhecido como "super usuário" ou privilégios de root para nossa conta regular. Isso irá permitir nosso usuário regular executar comandos com privilégios administrativos colocando a palavra sudo antes de cada comando.

      Para adicionar esses privilégios para o nosso novo usuário, precisamos adicionar o novo usuário ao grupo "wheel". Por padrão, no CentOS 7, os usuários que pertencem ao grupo "wheel" estão autorizados a utilizar o comando sudo.

      Como root, execute este comando para adicionar seu novo usuário ao grupo wheel (substitua a palavra em destaque pelo seu novo usuário):

      Agora seu usuário pode executar comandos com privilégios de super usuário! Para mais informações sobre como isso funciona, confira nosso tutorial sobre sudoers.

      Passo Quatro — Adicionar Autenticação de Chave Pública (Recomendado)

      O próximo passo para proteger seu servidor é configurar a autenticação de chave pública para o novo usuário. Configurar isso aumentará a segurança do seu servidor, exigindo uma chave SSH privada para efetuar logon.

      Gerar um Par de Chaves

      Se você ainda não tem um par de chaves SSH, que consiste em uma chave pública e uma privada, você precisa gerar um. Se você já tiver uma chave que deseje usar, vá para o passo Copiar a Chave Pública.

      Para gerar um novo par de chaves, digite o seguinte comando no terminal da sua máquina local:

      Supondo que seu usuário local chame-se "localuser", você verá uma saída parecida com a seguinte:

      ssh-keygen output

      Generating public/private rsa key pair. Enter file in which to save the key (/Users/localuser/.ssh/id_rsa):

      Pressione Enter para aceitar este nome de arquivo e o caminho (ou digite um novo nome).

      Em seguida, você será solicitado a inserir uma senha para proteger a chave. Você pode inserir uma senha ou deixar a senha em branco.

      Nota: Se você deixar a senha em branco, poderá usar a chave privada para autenticação sem inserir uma senha. Se você inserir uma senha, precisará da chave privada e da senha para efetuar logon. Proteger suas chaves com senhas é mais seguro, mas ambos os métodos têm seus usos e são mais seguros do que a autenticação básica de senha.

      Isto gera uma chave privada, id_rsa, e uma chave pública, id_rsa.pub, no diretório .ssh do diretório home do localuser. Lembre-se de que a chave privada não deve ser compartilhada com ninguém que não deva ter acesso aos seus servidores!

      Copiar a Chave Pública

      Depois de gerar um par de chaves SSH, você deverá copiar sua chave pública para o novo servidor. Vamos cobrir duas maneiras fáceis de fazer isso.

      Nota: O método ssh-copy-id não funcionará na DigitalOcean se uma chave SSH for selecionada durante a criação do Droplet. Isso ocorre porque a DigitalOcean desativa a autenticação por senha se uma chave SSH estiver presente, e o ssh-copy-id depende da autenticação por senha para copiar a chave.

      Se você estiver usando a DigitalOcean e selecionou uma chave SSH durante a criação do Droplet, use a opção 2.

      Opção 1: Usar ssh-copy-id

      Se a sua máquina local tiver o script ssh-copy-id instalado, você poderá usá-lo para instalar sua chave pública para qualquer usuário para o qual tenha credenciais de logon.

      Execute o script ssh-copy-id especificando o usuário e o endereço IP do servidor no qual você deseja instalar a chave, desta forma:

      • ssh-copy-id demo@ENDEREÇO_IP_DO_SERVIDOR

      Depois de fornecer sua senha no prompt, sua chave pública será adicionada ao arquivo .ssh/authorized_keys do usuário remoto. A chave privada correspondente agora pode ser usada para efetuar logon no servidor.

      Opção 2: Instalar Manualmente a Chave

      Supondo que você gerou um par de chaves SSH usando o passo anterior, use o seguinte comando no terminal da sua máquina local para imprimir sua chave pública (id_rsa.pub):

      Isso deve imprimir sua chave SSH pública, que deve ser algo como o seguinte:

      id_rsa.pub contents

      ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBGTO0tsVejssuaYR5R3Y/i73SppJAhme1dH7W2c47d4gOqB4izP0+fRLfvbz/tnXFz4iOP/H6eCV05hqUhF+KYRxt9Y8tVMrpDZR2l75o6+xSbUOMu6xN+uVF0T9XzKcxmzTmnV7Na5up3QM3DoSRYX/EP3utr2+zAqpJIfKPLdA74w7g56oYWI9blpnpzxkEd3edVJOivUkpZ4JoenWManvIaSdMTJXMy3MtlQhva+j9CgguyVbUkdzK9KKEuah+pFZvaugtebsU+bllPTB0nlXGIJk98Ie9ZtxuY3nCKneB+KjKiXrAvXUPCI9mWkYS/1rggpFmu3HbXBnWSUdf localuser@machine.local

      Selecione a chave pública e copie-a para a sua área de transferência.

      Adicionar Chave Pública ao Novo Usuário Remoto

      Para habilitar o uso da chave SSH para autenticação usando o novo usuário remoto, você deve adicionar a chave pública a um arquivo especial no diretório home do usuário.

      No servidor, como usuário root, digite o seguinte comando para alternar para o novo usuário (substitua pelo seu próprio nome de usuário):

      Agora você estará no diretório home do seu novo usuário.

      Crie um novo diretório chamado .ssh e restrinja suas permissões com os seguintes comandos:

      • mkdir .ssh
      • chmod 700 .ssh

      Agora abra um arquivo em .ssh chamado authorized_keys com um editor de texto. Vamos uilizar o vi para editar o arquivo:

      Entre no modo de insersão, pressionando i, em seguida insira sua chave pública (que deve estar em sua área de transferência) colando-a no editor. Agora pressione ESC para sair do modo de inserção.

      Digite :x e depois ENTER para salvar e sair do arquivo.

      Agora, restrinja as permissões do arquivo authorized_keys com este comando:

      • chmod 600 .ssh/authorized_keys

      Digite este comando uma vez para retornar ao usuário root:

      Agora você pode fazer logon SSH como seu novo usuário, usando a chave privada como autenticação.

      Para ler mais sobre como funciona a autenticação de chaves, leia este tutorial: Como Configurar a Autenticação Baseada em Chave SSH em um Servidor Linux.

      Passo Cinco — Configurar o Daemon SSH

      Agora que temos nossa nova conta, podemos proteger um pouco mais o nosso servidor modificando sua configuração do daemon SSH (o programa que nos permite efetuar logon remotamente) para proibir o acesso SSH remoto à conta root.

      Comece abrindo o arquivo de configuração com o seu editor de texto como root:

      Aqui, temos a opção de desativar o logon de root via SSH. Esta é geralmente uma configuração mais segura, já que agora podemos acessar nosso servidor através de nossa conta de usuário normal e escalar privilégios quando necessário.

      Para desabilitar os logons remotos com o root, precisamos encontrar uma linha que se parece com essa:

      /etc/ssh/sshd_config (before)

      #PermitRootLogin yes
      

      Dica: Para procurar por esta linha, digite /PermitRoot e depois ENTER. Isso deve trazer o cursor para o caractere "P" nessa linha.

      Descomente a linha excluindo o símbolo "#" (pressione Shift-x).

      Agora mova o cursor para o "yes" pressionando c.

      Então, substitua "yes" pressionando cw e, em seguida, digite "no". Pressione ESC quando tiver terminado de editar. Deve ficar assim:

      /etc/ssh/sshd_config (after)

      PermitRootLogin no
      

      Desativar o logon remoto pelo root é altamente recomendado em todos os servidores!

      Digite :x e depois ENTER para salvar e sair do arquivo.

      Recarregue o SSH

      Agora que fizemos nossas alterações, precisamos reiniciar o serviço SSH para que ele use nossa nova configuração.

      Digite isto para reiniciar o SSH:

      Agora, antes de sairmos do servidor, devemos testar nossa nova configuração. Não devemos desconectar até que possamos confirmar que novas conexões podem ser estabelecidas com sucesso.

      Abra uma nova janela de terminal. Na nova janela, precisamos iniciar uma nova conexão com nosso servidor. Desta vez, em vez de usar a conta root, queremos usar a nova conta que criamos.

      Para o servidor que configuramos acima, conecte-se usando este comando. Substitua sua própria informação onde for apropriado:

      • ssh demo@SERVER_IP_ADDRESS

      Nota: Se você estiver usando o PuTTY para se conectar aos seus servidores, certifique-se de atualizar o número da porta da sessão para corresponder à configuração atual do seu servidor.

      Você será solicitado a informar a senha do novo usuário que você configurou. Depois disso, você estará logado como seu novo usuário.

      Lembre-se, se você precisar executar um comando com privilégios de root, digite "sudo" antes dele, desta forma:

      Se tudo estiver bem, você pode sair de suas sessões digitando:

      Para Onde ir a partir daqui?

      Neste ponto, você tem uma base sólida para seu servidor. Você pode instalar qualquer software que você precisar em seu servidor agora.

      Se você não tiver certeza do que deseja fazer com seu servidor, confira o próximo tutorial desta série para Etapas Adicionais Recomendadas para Novos Servidores CentOS 7. Ele cobre coisas como habilitar o fail2ban para reduzir a eficácia de ataques de força bruta, configurações básicas de firewall, NTP e arquivos de swap. Ele também fornece links para tutoriais que mostram como configurar aplicações web comuns.

      Se você quer apenas explorar, dê uma olhada no restante da nossa comunidade para encontrar mais tutoriais. Algumas ideias populares são Configurando uma pilha LAMP ou uma pilha LEMP, que permitirá que você hospede websites.



      Source link