One place for hosting & domains

      Configurar

      Cómo instalar y configurar ownCloud en Ubuntu 18.04


      Introducción

      ownCloud es un servidor de intercambio de archivos de código abierto y una plataforma de colaboración que puede almacenar su contenido personal, como documentos e imágenes, en una ubicación centralizada. Esto le permite tener el control de su contenido y de la seguridad, al no tener que depender de servicios de alojamiento de contenido externos como Dropbox.

      En este tutorial, instalaremos y configuraremos una instancia de ownCloud en un servidor Ubuntu 18.04.

      Requisitos previos

      Para completar los pasos de esta guía, necesitará lo siguiente:

      • Un usuario sudo y un firewall en su servidor: puede crear un usuario con privilegios sudo y configurar un firewall básico siguiendo la guía de configuración inicial para servidores de Ubuntu 18.04.
      • Una pila LAMP: ownCloud requiere un servidor web, una base de datos y PHP para funcionar correctamente. La configuración de un servidor con pila LAMP (Linux, Apache, MySQL y PHP) cumple con todos estos requisitos: Siga esta guía para instalar y configurar este software.
      • Un certificado SSL: la manera de configurar esto depende de que tenga o no un nombre de dominio que se resuelva en su servidor.
        • Si dispone de un nombre de dominio, la alternativa más sencilla para proteger su sitio es Let’s Encrypt, que proporciona certificados de confianza gratuitos. Para la configuración, siga nuestra guía de Let’s Encrypt para Apache.
        • Si no cuenta con un dominio y solo utiliza esta configuración para pruebas o cuestiones personales, puede emplear en su lugar un certificado autofirmado. Le proporciona el mismo tipo de cifrado, aunque sin la validación de dominio. Para la configuración, siga la guía de certificados SSL autofirmados para Apache.

      Paso 1: Instalar ownCloud

      El paquete de servidor de ownCloud no existe dentro de los repositorios predeterminados de Ubuntu. Sin embargo, ownCloud ofrece un repositorio dedicado para la distribución que podemos añadir a nuestro servidor.

      Para comenzar, descargue la clave de versión usando el comando curl e impórtela con la utilidad apt-key mediante el comando add:

      • curl https://download.owncloud.org/download/repositories/10.0/Ubuntu_18.04/Release.key | sudo apt-key add -

      El archivo “Release.key” contiene una clave pública PGP (Pretty Good Privacy) que apt usará para verificar que el paquete de ownCloud sea auténtico.

      Además de importar la clave, cree un archivo llamado owncloud.list en el directorio sources.list.d para apt. El archivo contiene la dirección del repositorio de ownCloud.

      • echo 'deb http://download.owncloud.org/download/repositories/10.0/Ubuntu_18.04/ /' | sudo tee /etc/apt/sources.list.d/owncloud.list

      Ahora, podemos usar el administrador de paquetes para buscar e instalar ownCloud. Junto con el paquete principal, también instalaremos algunas bibliotecas de PHP adicionales que ownCloud utiliza para añadir más funciones. Actualice su índice local de paquetes e instale todo escribiendo lo siguiente:

      • sudo apt update
      • sudo apt install php-bz2 php-curl php-gd php-imagick php-intl php-mbstring php-xml php-zip owncloud-files

      Todo lo que necesitamos está ahora instalado en el servidor, Por ello, a continuación podemos finalizar la configuración para comenzar a usar el servicio.

      Paso 2: Ajustar la raíz del documento

      El paquete de ownCloud que instalamos copia los archivos web a /var/www/owncloud en el servidor. Actualmente, los ajustes del host virtual de Apache están configurados para mostrar los archivos desde un directorio diferente. Debemos cambiar el ajuste de DocumentRoot en nuestra configuración para apuntar al nuevo directorio.

      Encontrará los archivos del host virtual a los que hace referencia su nombre de dominio o dirección IP usando la utilidad apache2ctl con la opción DUMP_VHOSTS. Filtre el resultado con el nombre de dominio o la dirección IP de su servidor para saber qué archivos debe editar en los siguientes comandos:

      • sudo apache2ctl -t -D DUMP_VHOSTS | grep server_domain_or_IP

      El resultado probablemente tenga un aspecto similar a este:

      Output

      *:443 server_domain_or_IP (/etc/apache2/sites-enabled/server_domain_or_IP-le-ssl.conf:2) port 80 namevhost server_domain_or_IP (/etc/apache2/sites-enabled/server_domain_or_IP.conf:1)

      En los paréntesis, puede ver cada uno de los archivos que hacen referencia al nombre del dominio o a la dirección IP que usaremos para acceder a ownCloud. Estos son los archivos que deberá editar.

      Para cada coincidencia, abra el archivo en un editor de texto con privilegios sudo:

      • sudo nano /etc/apache2/sites-enabled/server_domain_or_IP.conf

      En su interior, busque la directiva DocumentRoot. Cambie la línea de modo que apunte al directorio /var/www/owncloud:

      Example DocumentRoot edit

      <VirtualHost *:80>
          . . .
          DocumentRoot /var/www/owncloud
          . . .
      </VirtualHost>
      

      Guarde y cierre el archivo cuando termine. Complete este proceso para cada uno de los archivos que hace referencia a su nombre de dominio (o dirección IP, si no configuró un dominio para su servidor).

      Cuando termine, compruebe la sintaxis de sus archivos de Apache para asegurarse de que no haya errores de escritura detectables en su configuración:

      • sudo apache2ctl configtest

      Output

      Syntax OK

      Según su configuración, es posible que una advertencia sobre la configuración de ServerName a nivel global. Siempre que el resultado termine con Syntax OK, puede ignorar esa advertencia. Si ve errores adicionales, regrese y compruebe los archivos que acaba de editar en busca de errores.

      Si se supera con éxito la verificación de su sintaxis, vuelva a cargar el servicio de Apache para activar los nuevos cambios:

      • sudo systemctl reload apache2

      Con esto, Apache debería poder presentar sus archivos ownCloud.

      Paso 3: Configurar la base de datos de MySQL

      Antes de pasar a la configuración web, debemos configurar la base de datos. Durante el proceso de configuración basado en la web, debemos proporcionar para la base de datos un nombre, un nombre de usuario y una contraseña a fin de que ownCloud pueda conectarse y administrar su información en MySQL.

      Comience iniciando sesión en su base de datos con la cuenta administrativa de MySQL.

      Si configura la autenticación con contraseña para la cuenta root de MySQL, es posible que deba usar esta sintaxis:

      Cree una base de datos dedicada para su uso por parte de ownCloud. Daremos a esta base de datos el nombre owncloud:

      • CREATE DATABASE owncloud;

      Nota: Cada instrucción de MySQL debe terminar en punto y coma (;). Asegúrese de comprobar que esto exista si experimenta un problema.

      A continuación, cree una cuenta de usuario de MySQL independiente para administrar la base de datos recién creada. Desde el punto de vista de la administración y la seguridad, crear bases de datos y cuentas de una función es una idea recomendable. Como en el caso del nombre de la base de datos, seleccione el nombre de usuario que prefiera. Para esta guía, optamos por el nombre owncloud.

      • GRANT ALL ON owncloud.* to 'owncloud'@'localhost' IDENTIFIED BY 'owncloud_database_password';

      Advertencia: Asegúrese de usar una contraseña real cuando el comando indique lo siguiente: owncloud_database_password

      Una vez asignado el acceso del usuario a la base de datos, realice la operación flush privileges para garantizar que la instancia en ejecución de MySQL conozca la asignación reciente de privilegios:

      Ahora puede cerrar la sesión en MySQL escribiendo lo siguiente:

      Una vez que se instale el servidor de ownCloud y se configure la base de datos, estaremos listos para enfocar la atención en la configuración de la aplicación de ownCloud.

      Paso 4: Configurar ownCloud

      Para acceder a la interfaz web de ownCloud, abra un navegador web y diríjase a la siguiente dirección:

      https://server_domain_or_IP
      

      Nota: Si utiliza un certificado SSL autofirmado, es probable que se le presente una advertencia porque el certificado no está firmado por una de las autoridades de confianza de su navegador. Esto está previsto y es normal. Haga clic en el botón o enlace correspondientes para continuar con la página de administración de ownCloud.

      Debería ver la página de configuración web de ownCloud en su navegador.

      Cree una cuenta de administrador seleccionando un nombre de usuario y una contraseña. Por seguridad, no se recomienda usar opciones como “admin” para el nombre de usuario:

      Cuenta de administrador de ownCloud

      A continuación, deje la configuración de la carpeta de datos como está y desplácese hasta la sección de configuración de la base de datos.

      Complete los datos con nombre de la base de datos, el nombre de usuario de la base de datos y la contraseña de la base de datos que creó en la sección anterior. Si utilizó la configuración de esta guía, tanto el nombre de la base de datos como el nombre de usuario serán owncloud. Deje localhost como host de la base de datos:

      Configuración de la base de datos de ownCloud

      Haga clic en Finish setup para terminar de configurar ownCloud usando la información que proporcionó. Accederá a una pantalla de inicio de sesión en la que podrá iniciar sesión usando su cuenta nueva:

      Pantalla de inicio de sesión de ownCloud

      La primera vez que inicie sesión, aparecerá una pantalla en la que podrá descargar aplicaciones para sincronizar sus archivos entre varios dispositivos. Puede descargarlas y configurarlas ahora o hacerlo más adelante. Cuando termine, haga clic en la x de la esquina superior derecha de la pantalla de presentación para acceder a la interfaz principal:

      Interfaz principal de ownCloud

      Aquí, podrá crear o cargar archivos en su nube personal.

      Conclusión

      ownCloud puede replicar las capacidades de servicios externos populares de almacenamiento en la nube. El contenido puede compartirse entre usuarios o de forma externa con URL públicas. La ventaja de ownCloud es que la información se guarda en un lugar que usted controla y administra sin intervención de terceros.

      Explore la interfaz y, para obtener funciones adicionales, instale complementos usando la tienda de aplicaciones de ownCloud.



      Source link

      Como Configurar um Servidor de Armazenamento de Objeto Usando o Minio no Ubuntu 18.04


      O autor escolheu o Open Internet/Free Speech Fund para receber uma doação como parte do programa Write for DOnations.

      Introdução

      De soluções de backup baseadas na nuvem até a alta disponibilidade redes de entrega de conteúdo (CDNs), a capacidade de armazenar blobs não estruturados de dados de objetos e torná-los acessíveis por meio de APIs HTTP, conhecidas como armazenamento de objeto ou object storage, tornou-se parte integrante do cenário da tecnologia moderna.

      O Minio é um popular servidor de armazenamento de objetos open-source compatível com o Serviço de armazenamento em nuvem Amazon S3. As aplicações que foram configuradas para conversar com o Amazon S3 também podem ser configuradas para conversar com o Minio, permitindo que o Minio seja uma alternativa viável ao S3 se você quiser ter mais controle sobre o servidor de armazenamento de objetos. O serviço armazena dados não estruturados como fotos, vídeos, arquivos de log, backups e imagens de container/VM, e pode até mesmo fornecer um servidor de armazenamento de objeto único que agrupa várias unidades espalhadas por muitos servidores.

      O Minio é escrito em Go, vem com um cliente de linha de comando mais uma interface web, e suporta serviço de enfileiramento simples para alvos com o protocolo Advanced Message Queuing (AMQP), Elasticsearch, Redis, NATS. Por todos esses motivos, aprender a configurar um servidor de armazenamento de objetos Minio pode adicionar uma ampla variedade de flexibilidade e utilidade ao seu projeto.

      Neste tutorial, você irá:

      • Instalar o servidor Minio no seu servidor Ubuntu 18.04 e configurá-lo como um serviço systemd.

      • Configurar um certificado SSL/TLS usando o Let’s Encrypt para proteger a comunicação entre o servidor e o cliente.

      • Acessar a interface web do Minio via HTTPS para usar e administrar o servidor.

      Pré-requisitos

      Para concluir este tutorial, você precisará de:

      • Um servidor Ubuntu 18.04 configurado seguindo nosso tutorial de Configuração Inicial de servidor com Ubuntu 18.04, incluindo um usuário sudo não-root e um firewall.

      • Um nome de domínio totalmente qualificado. Você pode comprar um em Namecheap ou obter um gratuitamente em Freenom. Neste tutorial, seu domínio será representado como seu_domínio.

      • Os seguintes registros DNS configurados para o seu servidor Minio. Você pode seguir nossa documentação sobre registros DNS para obter detalhes sobre como adicioná-los a um Droplet da DigitalOcean.

        • Um registro A com o nome do servidor (exemplo: minio-server.seu_domínio) apontando para o endereço IPv4 do servidor de objetos.
        • (Opcional) Se você deseja que seu servidor seja acessível via IPv6, será necessário um registro AAAA com o nome do seu servidor apontando para o endereço IPv6 do servidor de objetos.

      Passo 1 — Instalando e Configurando o Servidor Minio

      Você pode instalar o servidor Minio compilando o código fonte ou através de um arquivo binário. Para instalá-lo a partir da fonte, você precisa ter pelo menos o Go 1.12 instalado em seu sistema.

      Neste passo, você instalará o servidor através do binário pré-compilado e configurará o servidor Minio posteriormente.

      Primeiro, efetue login no seu servidor, substituindo sammy pelo seu nome de usuário e ip_do_seu_servidor pelo endereço IP do seu servidor Ubuntu 18.04:

      • ssh sammy@ip_do_seu_servidor

      Se você não atualizou o banco de dados de pacotes recentemente, atualize-o agora:

      Em seguida, baixe o arquivo binário do servidor Minio do site oficial:

      • wget https://dl.min.io/server/minio/release/linux-amd64/minio

      Você receberá uma saída semelhante à seguinte:

      Output

      --2019-08-27 15:08:49-- https://dl.min.io/server/minio/release/linux-amd64/minio Resolving dl.min.io (dl.min.io)... 178.128.69.202 Connecting to dl.min.io (dl.min.io)|178.128.69.202|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 44511616 (42M) [application/octet-stream] Saving to: ‘minio’ minio 100%[===================>] 42.45M 21.9MB/s in 1.9s 2019-08-27 15:08:51 (21.9 MB/s) - ‘minio’ saved [44511616/44511616]

      Depois que o download terminar, um arquivo chamado minio estará no seu diretório de trabalho. Use o seguinte comando para torná-lo executável:

      Agora, mova o arquivo para o diretório /usr/local/bin, onde o script de inicialização systemd do Minio espera encontrá-lo:

      • sudo mv minio /usr/local/bin

      Isso nos permitirá escrever um arquivo de unidade de serviço posteriormente neste tutorial para executar automaticamente o Minio na inicialização.

      Por motivos de segurança, é melhor evitar a execução do servidor Minio como root. Isso limitará os danos que podem ser causados ao seu sistema se ele for comprometido. Como o script systemd que você usará no Passo 2 procura uma conta de usuário e um grupo chamado minio-user, crie um novo usuário com este nome:

      • sudo useradd -r minio-user -s /sbin/nologin

      Neste comando, você usou a flag -s para definir /sbin/nologin como o shell para minio-user. Este é um shell que não permite o login do usuário, o que não é necessário para o minio-user.

      Em seguida, altere a propriedade do binário do Minio para minio-user:

      • sudo chown minio-user:minio-user /usr/local/bin/minio

      Em seguida, você criará um diretório onde o Minio armazenará arquivos. Este será o local de armazenamento para os buckets que você usará posteriormente para organizar os objetos que você armazena no servidor Minio. Este tutorial nomeará o diretório como minio:

      • sudo mkdir /usr/local/share/minio

      Dê a propriedade desse diretório para o minio-user:

      • sudo chown minio-user:minio-user /usr/local/share/minio

      A maioria dos arquivos de configuração do servidor é armazenada no diretório /etc, então crie seu arquivo de configuração do Minio lá:

      Dê a propriedade desse diretório para o minio-user também:

      • sudo chown minio-user:minio-user /etc/minio

      Use o Nano ou seu editor de texto favorito para criar o arquivo de ambiente necessário para modificar a configuração padrão:

      • sudo nano /etc/default/minio

      Depois que o arquivo estiver aberto, adicione as seguintes linhas para definir algumas variáveis de ambiente importantes no seu arquivo de ambiente:

      /etc/default/minio

      MINIO_ACCESS_KEY="minio"
      MINIO_VOLUMES="/usr/local/share/minio/"
      MINIO_OPTS="-C /etc/minio --address ip_do_seu_servidor:9000"
      MINIO_SECRET_KEY="miniostorage"
      

      Vamos dar uma olhada nessas variáveis e nos valores que você define:

      • MINIO_ACCESS_KEY: Isso define a access key que você usará para acessar a interface web de usuário do Minio.
      • MINIO_SECRET_KEY: Isso define a chave privada que você usará para completar suas credenciais de login na interface do Minio. Este tutorial configurou o valor para miniostorage, mas recomendamos que você escolha uma senha diferente e mais complexa para proteger seu servidor.
      • MINIO_VOLUMES: Isso identifica o diretório de armazenamento que você criou para seus buckets.
      • MINIO_OPTS: Isso muda onde e como o servidor serve os dados. A flag -C aponta o Minio para o diretório de configuração que ele deve usar, enquanto a flag --address informa ao Minio o endereço IP e a porta na qual se conectar. Se o endereço IP não for especificado, o Minio será vinculado a todos os endereços configurados no servidor, incluindo localhost e quaisquer endereços IP relacionados ao Docker, portanto, é recomendável especificar diretamente o endereço IP aqui. A porta padrão 9000 pode ser alterada se você desejar.

      Por fim, salve e feche o arquivo de ambiente quando terminar de fazer as alterações.

      Agora você instalou o Minio e definiu algumas variáveis de ambiente importantes. Em seguida, você configurará o servidor para ser executado como um serviço do sistema.

      Passo 2 — Instalando o Script de Inicialização Systemd do Minio

      Neste passo, você configurará o servidor Minio para ser gerenciado como um serviço systemd.

      Primeiro, faça o download do arquivo descritor de serviço oficial do Minio usando o seguinte comando.

      • curl -O https://raw.githubusercontent.com/minio/minio-service/master/linux-systemd/minio.service

      Você receberá uma saída semelhante à seguinte:

      Output

      % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 835 100 835 0 0 6139 0 --:--:-- --:--:-- --:--:-- 6139

      Após o término do download, um arquivo chamado minio.service estará no seu diretório de trabalho.

      Para auditar o conteúdo do arquivo minio.service antes de aplicá-lo, abra-o em um editor de texto para visualizar seu conteúdo:

      Isso mostrará o seguinte:

      /etc/systemd/system/minio.service

      [Unit]
      Description=MinIO
      Documentation=https://docs.min.io
      Wants=network-online.target
      After=network-online.target
      AssertFileIsExecutable=/usr/local/bin/minio
      
      [Service]
      WorkingDirectory=/usr/local/
      
      User=minio-user
      Group=minio-user
      
      EnvironmentFile=/etc/default/minio
      ExecStartPre=/bin/bash -c "if [ -z "${MINIO_VOLUMES}" ]; then echo "Variable MINIO_VOLUMES not set in /etc/default/minio"; exit 1; fi"
      
      ExecStart=/usr/local/bin/minio server $MINIO_OPTS $MINIO_VOLUMES
      
      # Let systemd restart this service always
      Restart=always
      
      # Specifies the maximum file descriptor number that can be opened by this process
      LimitNOFILE=65536
      
      # Disable timeout logic and wait until process is stopped
      TimeoutStopSec=infinity
      SendSIGKILL=no
      
      [Install]
      WantedBy=multi-user.target
      
      # Built for ${project.name}-${project.version} (${project.name})
      

      Este arquivo de unidade de serviço inicia o servidor Minio usando o usuário minio-user que você criou anteriormente. Ele também implementa as variáveis de ambiente definidas no último passo e faz o servidor executar automaticamente na inicialização. Para mais informações sobre arquivos de unidades do systemd, consulte nosso guia Understanding Systemd Units and Unit Files.

      Depois de examinar o conteúdo do script, feche o seu editor de texto.

      O Systemd requer que os arquivos de unidade sejam armazenados no diretório de configuração systemd, então mova o minio.service para lá:

      • sudo mv minio.service /etc/systemd/system

      Em seguida, execute o seguinte comando para recarregar todas as unidades systemd:

      • sudo systemctl daemon-reload

      Por fim, habilite o Minio para iniciar na inicialização:

      • sudo systemctl enable minio

      Isso dará a seguinte saída:

      Output

      Created symlink from /etc/systemd/system/multi-user.target.wants/minio.service to /etc/systemd/system/minio.service.

      Agora que o script systemd está instalado e configurado, é hora de iniciar o servidor.

      Passo 3 — Iniciando o Servidor Minio

      Neste passo, você iniciará o servidor e modificará o firewall para permitir o acesso através da interface web.

      Primeiro, inicie o servidor Minio:

      • sudo systemctl start minio

      Em seguida, verifique o status do Minio, o endereço IP ao qual está vinculado, seu uso de memória e muito mais executando este comando:

      • sudo systemctl status minio

      Você obterá a seguinte saída:

      Output

      ● minio.service - MinIO Loaded: loaded (/etc/systemd/system/minio.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2019-12-09 21:54:02 UTC; 46s ago Docs: https://docs.min.io Process: 3405 ExecStartPre=/bin/bash -c if [ -z "${MINIO_VOLUMES}" ]; then echo "Variable MINIO_VOLUMES not set in /etc/default/minio"; exit 1; fi (code=exited, status=0/SUCCES Main PID: 3407 (minio) Tasks: 7 (limit: 1152) CGroup: /system.slice/minio.service └─3407 /usr/local/bin/minio server -C /etc/minio --address your_server_IP:9000 /usr/local/share/minio/ Dec 09 21:54:02 cart-Minion-Object-1804-1 systemd[1]: Started MinIO. Dec 09 21:54:03 cart-Minion-Object-1804-1 minio[3407]: Endpoint: http://your_server_IP:9000 Dec 09 21:54:03 cart-Minion-Object-1804-1 minio[3407]: Browser Access: Dec 09 21:54:03 cart-Minion-Object-1804-1 minio[3407]: http://your_server_IP:9000 ...

      Em seguida, habilite o acesso através do firewall ao servidor Minio na porta configurada. Neste tutorial, essa é a porta 9000.

      Primeiro adicione a regra:

      Em seguida, ative o firewall:

      Você receberá o seguinte prompt:

      Output

      Command may disrupt existing ssh connections. Proceed with operation (y|n)?

      Pressione y e ENTER para confirmar. Você obterá a seguinte saída:

      Output

      Firewall is active and enabled on system startup

      O Minio agora está pronto para aceitar tráfego, mas antes de se conectar ao servidor, você protegerá a comunicação instalando um certificado SSL/TLS.

      Neste passo, você protegerá o acesso ao seu servidor Minio usando uma chave privada e um certificado público que foram obtidos de uma autoridade de certificação (CA), neste caso Let’s Encrypt. Para obter um certificado SSL gratuito, você usará o Certbot.

      Primeiro, permita o acesso HTTP e HTTPS através do seu firewall. Para fazer isso, abra a porta 80, que é a porta para HTTP:

      Em seguida, abra a porta 443 para HTTPS:

      Depois de adicionar essas regras, verifique o status do seu firewall com o seguinte comando:

      Você receberá uma saída semelhante à seguinte:

      Output

      Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- 22/tcp (OpenSSH) ALLOW IN Anywhere 9000 ALLOW IN Anywhere 443 ALLOW IN Anywhere 80 ALLOW IN Anywhere 22/tcp (OpenSSH (v6)) ALLOW IN Anywhere (v6) 9000 (v6) ALLOW IN Anywhere (v6) 443 (v6) ALLOW IN Anywhere (v6) 80 (v6) ALLOW IN Anywhere (v6)

      Isso confirma que as portas 80 e 443 estão abertas, garantindo que o servidor aceite solicitações da Internet.

      Em seguida, você instalará o Certbot. Como o Certbot mantém um repositório PPA separado, você primeiro precisará adicioná-lo à sua lista de repositórios antes de instalar o Certbot, como mostrado:

      Para se preparar para adicionar o repositório PPA, primeiro instale software-properties-common, um pacote para o gerenciamento de PPAs:

      • sudo apt install software-properties-common

      Este pacote fornece alguns scripts úteis para adicionar e remover PPAs em vez de fazê-lo manualmente.

      Agora adicione o repositório Universe:

      • sudo add-apt-repository universe

      Este repositório contém software livre e de código aberto mantido pela comunidade Ubuntu, mas não é oficialmente mantido pela Canonical, os desenvolvedores do Ubuntu. É aqui que encontraremos o repositório do Certbot.

      Em seguida, adicione o repositório do Certbot:

      • sudo add-apt-repository ppa:certbot/certbot

      Você receberá a seguinte saída:

      Output

      This is the PPA for packages prepared by Debian Let's Encrypt Team and backported for Ubuntu(s). More info: https://launchpad.net/~certbot/+archive/ubuntu/certbot Press [ENTER] to continue or ctrl-c to cancel adding it

      Pressione ENTER para aceitar.

      Atualize a lista de pacotes:

      Finalmente, instale o certbot:

      Em seguida, você usará o certbot para gerar um novo certificado SSL.

      Como o Ubuntu 18.04 ainda não suporta a instalação automática, você usará o comando certonly e --standalone para obter o certificado:

      • sudo certbot certonly --standalone -d minio-server.seu_domínio

      --standalone significa que este certificado é para um servidor web interno independente. Para mais informações sobre isso, consulte nosso tutorial How To Use Certbot Standalone Mode to Retrieve Let’s Encrypt SSL Certificates on Ubuntu 18.04.

      Você receberá a seguinte saída:

      Output

      Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator standalone, Installer None Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel):

      Adicione seu email e pressione ENTER.

      O Certbot solicitará que você se registre no Let’s Encrypt:

      Output

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must agree in order to register with the ACME server at https://acme-v02.api.letsencrypt.org/directory - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (A)gree/(C)ancel:

      Digite A e pressione ENTER para concordar.

      Em seguida, você será perguntado se deseja compartilhar seu e-mail com a Electronic Frontier Foundation:

      Output

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Would you be willing to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about our work encrypting the web, EFF news, campaigns, and ways to support digital freedom. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o:

      Depois de responder Y ou N, suas chaves públicas e privadas serão geradas e salvas no diretório /etc/letsencrypt/live/minio-server.seu_domínio.

      Em seguida, copie esses dois arquivos (privkey.pem e fullchain.pem) para o diretório certs na pasta de configuração do servidor Minio, que é /etc/minio para este tutorial. Use o seguinte para copiar privkey.pem e renomear o arquivo private.key:

      • sudo cp /etc/letsencrypt/live/minio-server.seu_domínio/privkey.pem /etc/minio/certs/private.key

      Em seguida, faça o mesmo para fullchain.pem, nomeando o resultado como public.crt:

      • sudo cp /etc/letsencrypt/live/minio-server.seu_domínio/fullchain.pem /etc/minio/certs/public.crt

      Agora, altere a propriedade dos arquivos para minio-user. Primeiro, faça isso para private.key:

      • sudo chown minio-user:minio-user /etc/minio/certs/private.key

      Em seguida, public.crt:

      • sudo chown minio-user:minio-user /etc/minio/certs/public.crt

      Reinicie o servidor Minio, para que ele fique ciente do certificado e comece a usar HTTPS:

      • sudo systemctl restart minio

      Os certificados Let’s Encrypt são válidos apenas por noventa dias. Isso é para incentivar os usuários a automatizar seu processo de renovação de certificado. O pacote Certbot que você instalou adiciona automaticamente um script novo ao /etc/cron.d. Esse script é executado duas vezes por dia e renova automaticamente qualquer certificado que esteja dentro de trinta dias da expiração.

      Com isso, a conexão do Minio agora está segura e o certificado SSL/TLS será renovado automaticamente para você. No próximo passo, você se conectará ao Minio através do navegador para usar o servidor.

      Passo 5 — Conexão Segura à Interface Web do Minio Usando HTTPS

      Neste passo, você se conectará com segurança à interface web do Minio via HTTPS e, em seguida, criará buckets e fará o upload de objetos para eles.

      Acesse a interface web apontando o navegador para https://minio-server.seu_domínio:9000.

      Você verá a tela de login do servidor Minio:

      Minio login screen

      Agora, faça login na interface principal inserindo suas credenciais. Para Access Key, digite a MINIO_ACCESS_KEY que você definiu no arquivo de ambiente /etc/default/minio no Passo 1. Para Secret Key, digite a MINIO_SECRET_KEY que você definiu nesse mesmo arquivo. Depois de inserir as credenciais, clique no botão redondo com a seta, diretamente abaixo dos campos de entrada.

      Você será apresentado à interface de usuário do Minio. Para criar um novo bucket no qual você pode armazenar objetos, clique no botão vermelho claro + no canto inferior direito da interface principal para exibir dois botões amarelos adicionais.

      Minio's main interface

      Clique no botão amarelo do meio e digite um nome para o seu novo bucket no prompt, pressionando a tecla ENTER para salvar sua resposta. Seu novo bucket está pronto para ser usado para armazenamento.

      Nota: Ao nomear seu bucket no Minio, verifique se o seu nome contém apenas letras minúsculas, números ou hífens. O Minio limita as convenções de nomenclatura de buckets para ser compatível com os padrões do AWS S3.

      Quando você quiser adicionar objetos ao seu bucket, clique no mesmo botão vermelho claro de antes e clique no botão amarelo superior para abrir um prompt de upload de arquivo.

      Neste ponto, você trabalhou em toda a interface web básica para criar buckets e fazer upload de objetos.

      Conclusão

      Agora você tem seu próprio servidor Minio de armazenamento de objetos ao qual pode se conectar com segurança a partir da interface web usando um certificado Let’s Encrypt SSL/TLS. Opcionalmente, você pode querer olhar para o Minio desktop clients para FreeBSD, Linux, Mac, e Windows como uma maneira alternativa de usar e administrar seu servidor de armazenamento de objetos.

      Além disso, se você quiser aumentar a capacidade de armazenamento da sua instalação do Minio para além do tamanho do disco do servidor, use o Serviço de armazenamento em bloco da DigitalOcean para anexar um volume ao seu servidor, estendendo a capacidade de armazenamento em até 80 TB.

      Mais informações sobre o Minio estão disponíveis no site de documentação do projeto. Se você quiser saber mais sobre armazenamento de objetos, navegue em Tutoriais sobre armazenamento de objetos.



      Source link

      Cómo configurar BIND como servidor DNS de red privada en Ubuntu 18.04


      Introducción

      Una parte importante de la administración de la configuración e infraestructura de servidores incluye el uso sostenido de un método sencillo para buscar las interfaces de red y direcciones IP por nombre mediante la configuración de un sistema de nombres de dominio (DNS) adecuado. El empleo de nombres de dominio completos (FQDN), en vez de direcciones IP, para especificar las direcciones de red puede facilitar la configuración de servicios y aplicaciones, y aumenta la capacidad de mantenimiento de los archivos de configuración. Configurar su propio DNS para su red privada es una excelente opción para mejorar la administración de sus servidores.

      En este tutorial, veremos la manera de configurar un servidor DNS interno usando el software de servidor de nombres BIND (BIND9) en Ubuntu 18.04, que sus servidores pueden usar para resolver direcciones IP y nombres de hosts privados. Esto ofrece una alternativa centralizada para administrar sus nombres de hosts internos y direcciones IP privadas, lo cual es indispensable cuando su entorno abarca más de unos pocos hosts.

      Puede encontrar la versión de CentOS de este tutorial aquí.

      Requisitos previos

      Para completar este tutorial, necesitará la infraestructura siguiente. Cree cada servidor en el mismo centro de datos con red privada habilitada:

      • Un servidor de Ubuntu 18.04 nuevo que servirá como el servidor DNS primario, ns1.
      • (Recomendado) Un segundo servidor Ubuntu 18.04 que servirá como servidor DNS secundario, ns2.
      • Servidores adicionales en el mismo centro de datos que usarán sus servidores DNS.

      En cada uno de estos servidores, configure un acceso administrativo mediante un usuario sudo y un firewall siguiendo nuestra guía de configuración inicial para servidores de Ubuntu 18.04.

      Si no está familiarizado con los conceptos de DNS, se recomienda que lea al menos las tres primeras partes de nuestra Introducción a la administración de DNS.

      Ejemplo e infraestructura y objetivos

      A efectos de este artículo, supondremos lo siguiente:

      • Tenemos dos servidores que se designarán como nuestros servidores de nombres DNS. En esta guía, nos referiremos a estos como ns1 y ns2.
      • Disponemos de dos servidores clientes adicionales que usarán la infraestructura DNS que creemos. En esta guía, los llamaremos host1 y host2. Puede añadir tantos como desee en su infraestructura.
      • Todos estos servidores existen en el mismo centro de datos. Supondremos que este es el centro de datos nyc3.
      • Todos estos servidores tienen habilitada una red privada y están en la subred 10.128.0.0/16. Probablemente deba ajustar esto para sus servidores.
      • Todos los servidores se conectan a un proyecto que se ejecuta en “example.com”. Ya que nuestro sistema DNS será totalmente interno y privado, no es necesario que compre un nombre de dominio. Sin embargo, el uso de un dominio propio puede evitar conflictos con dominios públicos enrutables.

      Con estas suposiciones, decidimos que tiene sentido usar un esquema de nomenclatura que emplee “nyc3.example.com” para hacer referencia a nuestra subred o zona privada. Por tanto, el nombre de dominio completo (FQDN) privado de host1, será host1.ny3.example.com. Consulte la siguiente tabla que contiene la información pertinente:

      host Rol FQDN privada Dirección IP privada
      ns1 Servidor DNS primario ns1.nyc3.example.com 10.128.10.11
      ns2 Servidor DNS secundario ns2.nyc3.example.com 10.128.20.12
      host1 Host genérico 1 host1.nyc3.example.com 10.128.100.101
      host2 Host genérico 2 host2.nyc3.example.com 10.128.200.102

      Nota: Su configuración existente será diferente, pero los nombres de ejemplo y las direcciones IP se utilizarán para demostrar la forma de configurar un servidor DNS para que proporcione un DNS interno funcional. Debería poder adaptar fácilmente esta configuración para su propio entorno sustituyendo los nombres de hosts y direcciones IP privadas por los suyos. No es necesario usar el nombre de la región del centro de datos en su esquema de nomenclatura, pero lo utilizaremos aquí para denotar que estos hosts pertenecen a la red privada de un centro de datos concreto. Si utiliza varios centros de datos, puede configurar un DNS interno con cada centro de datos respectivo.

      Al final de este tutorial, dispondremos de un servidor DNS primario, ns1, y de forma opcional uno secundario, ns2, que servirá como respaldo.

      Comenzaremos instalando nuestro servidor DNS primario, ns1.

      Instalar BIND en servidores DNS

      Nota: El texto resaltado en rojo es importante. A menudo se usará para indicar algo que debe sustituirse por sus propios ajustes o que debería modificarse o añadirse a un archivo de configuración. Por ejemplo, si ve algo similar a host1.nyc3.example.com, sustitúyalo por el FQDN de su servidor. Asimismo, si ve host1_private_IP, sustitúyalo por la dirección IP privada de su propio servidor.

      En ambos servidores DNS, ns1 y ns2, actualice la caché del paquete apt escribiendo lo siguiente:

      Ahora instale BIND:

      • sudo apt-get install bind9 bind9utils bind9-doc

      Configurar Bind para el modo IPv4

      Antes de continuar, configuraremos BIND para el modo IPv4, ya que nuestra red privada utiliza IPv4 exclusivamente. En ambos servidores, edite la configuración predeterminada de bind9 escribiendo lo siguiente:

      • sudo nano /etc/default/bind9

      Añada “-4” al final del parámetro OPTIONS. Debería tener el siguiente aspecto:

      /etc/default/bind9

      . . .
      OPTIONS="-u bind -4"
      

      Guarde y cierre el archivo cuando haya terminado.

      Reinicie BIND para implementar los cambios:

      • sudo systemctl restart bind9

      Ahora que BIND está instalado, configuraremos el servidor DNS primario.

      Configurar el servidor DNS primario

      La configuración de BIND consta de varios archivos que se incluyen desde el archivo de configuración principal, named.conf. Estos nombres de archivos comienzan con named porque ese es el nombre del proceso que BIND ejecuta (abreviatura de “domain name daemon”). Comenzaremos configurando el archivo de opciones.

      Configurar el archivo de opciones

      En ns1, abra el archivo named.conf.options para editarlo:

      • sudo nano /etc/bind/named.conf.options

      Sobre el bloque options existente, cree un nuevo bloque ACL (lista de control de acceso) llamado “trusted”. Aquí definiremos una lista de clientes desde los que permitiremos consultas de DNS recurrentes (es decir, sus servidores que están en el mismo centro de datos que ns1). Usando nuestras direcciones IP privadas de ejemplo, añadiremos ns1, ns2, host1 y host2 a nuestra lista de clientes de confianza:

      /etc/bind/named.conf.options — 1 of 3

      acl "trusted" {
              10.128.10.11;    # ns1 - can be set to localhost
              10.128.20.12;    # ns2
              10.128.100.101;  # host1
              10.128.200.102;  # host2
      };
      
      options {
      
              . . .
      

      Ahora que tenemos nuestra lista de clientes DNS de confianza, nos convendrá editar el bloque options. En este momento, el inicio del bloque tiene el siguiente aspecto:

      /etc/bind/named.conf.options — 2 of 3

              . . .
      };
      
      options {
              directory "/var/cache/bind";
              . . .
      }
      

      Debajo de la directiva directory, añada las líneas de configuración resaltadas (y realice la sustitución en la dirección IP adecuada de ns1) para que tenga un aspecto similar a este:

      /etc/bind/named.conf.options — 3 of 3

              . . .
      
      };
      
      options {
              directory "/var/cache/bind";
      
              recursion yes;                 # enables resursive queries
              allow-recursion { trusted; };  # allows recursive queries from "trusted" clients
              listen-on { 10.128.10.11; };   # ns1 private IP address - listen on private network only
              allow-transfer { none; };      # disable zone transfers by default
      
              forwarders {
                      8.8.8.8;
                      8.8.4.4;
              };
      
              . . .
      };
      

      Cuando termine, guarde y cierre el archivo named.conf.options. En la configuración anterior se especifica que solo sus propios servidores (los “trusted”) podrán consultar su servidor DNS en busca de dominios externos.

      A continuación, configuraremos el archivo local para especificar nuestras zonas de DNS.

      Configurar el archivo local

      En ns1, abra el archivo named.conf.options para editarlo:

      • sudo nano /etc/bind/named.conf.local

      Aparte de algunos contener algunos comentarios, el archivo debería estar vacío. Aquí especificaremos nuestras zonas de reenvío e inversas. Las zonas DNS designan un alcance específico para administrar y definir registros DNS. Debido a que todos nuestros dominios estarán en el subdominio “nyc3.example.com”, usaremos eso como nuestra zona de reenvío. Debido a que las direcciones IP privadas de nuestros servidores están en el espacio IP 10.128.0.0/16, configuraremos una zona inversa para poder definir búsquedas inversas en ese intervalo.

      Añada la zona de reenvío con las siguientes líneas, sustituyendo el nombre de la zona por el suyo y la dirección IP privada del servidor DNS secundario en la directiva allow-transfer:

      /etc/bind/named.conf.local — 1 of 2

      zone "nyc3.example.com" {
          type master;
          file "/etc/bind/zones/db.nyc3.example.com"; # zone file path
          allow-transfer { 10.128.20.12; };           # ns2 private IP address - secondary
      };
      

      Suponiendo que nuestra subred privada es 10.128.0.0/16, agregue la zona inversa con las siguientes líneas (tenga en cuenta que el nombre de nuestra zona inversa comienza con “128.10”, que es el octeto inverso de “10.128”):

      /etc/bind/named.conf.local — 2 of 2

          . . .
      };
      
      zone "128.10.in-addr.arpa" {
          type master;
          file "/etc/bind/zones/db.10.128";  # 10.128.0.0/16 subnet
          allow-transfer { 10.128.20.12; };  # ns2 private IP address - secondary
      };
      

      Si sus servidores abarcan varias subredes privadas, pero están en el mismo centro de datos, asegúrese de especificar una zona adicional y un archivo de zona para cada subred distinta. Cuando termine de añadir todas las zonas deseadas, guarde el archivo named.conf.local y ciérrelo.

      Ahora que nuestras zonas están especificadas en BIND, debemos crear los archivos correspondientes de la zona de reenvío e inversa.

      Crear el archivo de la zona de reenvío

      El archivo de la zona de reenvío representa el punto en el que definimos los registros DNS para reenviar búsquedas DNS. Es decir, cuando el DNS reciba una consulta de nombre, “host1.nyc3.example.com”, por ejemplo, realizará en el archivo de la zona de reenvío para resolver la dirección IP privada correspondiente de host1.

      Crearemos el directorio en el que se alojarán nuestros archivos de zona. Según nuestra configuración de named.conf.local, esa ubicación debería ser /etc/bind/zones:

      • sudo mkdir /etc/bind/zones

      Basaremos nuestro archivo de la zona de reenvío en el archivo de zona db.local de muestra. Cópielo a la ubicación adecuada con los siguientes comandos:

      • sudo cp /etc/bind/db.local /etc/bind/zones/db.nyc3.example.com

      Ahora, editaremos nuestro archivo de la zona de reenvío:

      • sudo nano /etc/bind/zones/db.nyc3.example.com

      Inicialmente, tendrá un aspecto similar al siguiente:

      /etc/bind/zones/db.nyc3.example.com — original

      $TTL    604800
      @       IN      SOA     localhost. root.localhost. (
                                    2         ; Serial
                               604800         ; Refresh
                                86400         ; Retry
                              2419200         ; Expire
                               604800 )       ; Negative Cache TTL
      ;
      @       IN      NS      localhost.      ; delete this line
      @       IN      A       127.0.0.1       ; delete this line
      @       IN      AAAA    ::1             ; delete this line
      

      Primero, deberá editar el registro SOA. Sustituya el primer “localhost” por el FQDN de ns1 y luego “root.localhost” por “admin.nyc3.example.com”. Cada vez que edite un archivo de zona, deberá incrementar el valor serial antes de reiniciar el proceso named. Lo incrementaremos a “3”. Ahora debería tener un aspecto similar a este:

      /etc/bind/zones/db.nyc3.example.com — updated 1 of 3

      @       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                                    3         ; Serial
      
                                    . . .
      

      A continuación, elimine los tres registros al final del archivo (después del registro SOA). Si no está seguro de las líneas que debe eliminar, estas se marcan con un comentario “delete this line” (eliminar esta línea) encima.

      Al final del archivo, añada los registros de su servidor de nombres con las siguientes líneas (sustituya los nombres por los suyos). Observe que en la segunda columna se especifica que estos son registros “NS”:

      /etc/bind/zones/db.nyc3.example.com — updated 2 of 3

      . . .
      
      ; name servers - NS records
          IN      NS      ns1.nyc3.example.com.
          IN      NS      ns2.nyc3.example.com.
      

      Ahora, añada los registros A para sus hosts que pertenecen a esta zona. Esto incluye cualquier servidor cuyo nombre deseemos que termine con “.nyc3.example.com” (sustituya los nombres y las direcciones IP privadas). Usando nuestros nombres de ejemplo y las direcciones IP privadas, añadiremos registros A para ns1, ns2, host1 y host2:

      /etc/bind/zones/db.nyc3.example.com — updated 3 of 3

      . . .
      
      ; name servers - A records
      ns1.nyc3.example.com.          IN      A       10.128.10.11
      ns2.nyc3.example.com.          IN      A       10.128.20.12
      
      ; 10.128.0.0/16 - A records
      host1.nyc3.example.com.        IN      A      10.128.100.101
      host2.nyc3.example.com.        IN      A      10.128.200.102
      

      Guarde y cierre el archivo db.nyc3.example.com.

      Nuestra zona de reenvío de ejemplo final tendrá el siguiente aspecto:

      /etc/bind/zones/db.nyc3.example.com — updated

      $TTL    604800
      @       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                        3     ; Serial
                   604800     ; Refresh
                    86400     ; Retry
                  2419200     ; Expire
                   604800 )   ; Negative Cache TTL
      ;
      ; name servers - NS records
           IN      NS      ns1.nyc3.example.com.
           IN      NS      ns2.nyc3.example.com.
      
      ; name servers - A records
      ns1.nyc3.example.com.          IN      A       10.128.10.11
      ns2.nyc3.example.com.          IN      A       10.128.20.12
      
      ; 10.128.0.0/16 - A records
      host1.nyc3.example.com.        IN      A      10.128.100.101
      host2.nyc3.example.com.        IN      A      10.128.200.102
      

      Ahora, prosigamos con los archivos de la zona inversa.

      Crear los archivos de la zona inversa

      En los archivos de la zona inversa definimos los registros DNS PTR para las búsquedas de DNS inversas. Es decir, cuando el DNS reciba una consulta por dirección IP, “10.128.100.101”, por ejemplo, buscará el los archivos de la zona inversa para resolver el FQDN corespondiente, “host1.nyc3.example.com” en este caso.

      En ns1, para cada zona inversa especificada en el archivo named.conf.local, cree un archivo de zona inversa. Basaremos nuestros archivos de zona inversa en el archivo de zona db.127 de muestra. Cópielo en la ubicación adecuada con los siguientes comandos (sustituyendo el nombre de archivo de destino para que coincida con la definición de su zona inversa):

      • sudo cp /etc/bind/db.127 /etc/bind/zones/db.10.128

      Edite el archivo de la zona inversa que se corresponda con la zona o las zonas inversas definidas en named.conf.local:

      • sudo nano /etc/bind/zones/db.10.128

      Inicialmente, tendrá un aspecto similar al siguiente:

      /etc/bind/zones/db.10.128 — original

      $TTL    604800
      @       IN      SOA     localhost. root.localhost. (
                                    1         ; Serial
                               604800         ; Refresh
                                86400         ; Retry
                              2419200         ; Expire
                               604800 )       ; Negative Cache TTL
      ;
      @       IN      NS      localhost.      ; delete this line
      1.0.0   IN      PTR     localhost.      ; delete this line
      

      Como en el caso del archivo de la zona de reenvío, deberá editar el registro SOA e incrementar el valor serial. Debería tener un aspecto similar a esto:

      /etc/bind/zones/db.10.128 — updated 1 of 3

      @       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                                    3         ; Serial
      
                                    . . .
      

      A continuación, elimine los dos registros al final del archivo (después del registro SOA). Si no está seguro de las líneas que eliminará, se marcan con un comentario “delete this line” (elimine esta línea) encima.

      Al final del archivo, añada los registros de su servidor de nombres con las siguientes líneas (sustituya los nombres por los suyos). Observe que en la segunda columna se especifica que estos son registros “NS”:

      /etc/bind/zones/db.10.128 — updated 2 of 3

      . . .
      
      ; name servers - NS records
            IN      NS      ns1.nyc3.example.com.
            IN      NS      ns2.nyc3.example.com.
      

      Luego añada registros PTR para todos sus servidores cuyas direcciones IP estén en la subred del archivo de zona que está editando. En nuestro ejemplo, esto incluye todos nuestros hosts, porque todos están en la subred 10.128.0.0/16. Tenga en cuenta que la primera columna consiste en los dos últimos octetos de las direcciones IP privadas de sus servidores en orden inverso. Asegúrese de sustituir los nombres y las direcciones IP privadas para que coincidan con sus servidores:

      /etc/bind/zones/db.10.128 — updated 3 of 3

      . . .
      
      ; PTR Records
      11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
      12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
      101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101
      102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102
      

      Guarde y cierre el archivo de la zona inversa (repita los pasos de esta sección si debe añadir más archivos de zona inversa).

      Nuestro archivo de zona inversa de ejemplo tiene el siguiente aspecto:

      /etc/bind/zones/db.10.128 — updated

      $TTL    604800
      @       IN      SOA     nyc3.example.com. admin.nyc3.example.com. (
                                    3         ; Serial
                               604800         ; Refresh
                                86400         ; Retry
                              2419200         ; Expire
                               604800 )       ; Negative Cache TTL
      ; name servers
            IN      NS      ns1.nyc3.example.com.
            IN      NS      ns2.nyc3.example.com.
      
      ; PTR Records
      11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
      12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
      101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101
      102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102
      

      Terminamos de editar nuestros archivos. Ahora podemos comprobar si hay errores en nuestros archivos.

      Comprobar la sintaxis de la configuración BIND

      Ejecute el siguiente comando para comprobar la sintaxis de los archivos named.conf*:

      Si sus archivos de configuración named no tienen errores de sintaxis, volverá a su intérprete de comandos de shell y no verá mensajes de error. Si existen problemas en sus archivos de configuración, revise los mensajes de error y la sección “Configurar un servidor DNS primario”, y luego pruebe named-checkconf una vez más.

      El comando named-checkzone se puede utilizar para verificar que sus archivos de zona sean correctos. En el primer argumento de este se especifica el nombre de la zona y en el segundo el archivo de zona correspondiente, que están definidos en named.conf.local.

      Por ejemplo, para comprobar la configuración de la zona de reenvío “nyc3.example.com”, ejecute el siguiente comando (cambie los nombres para que coincidan con su zona y archivo de reenvío).

      • sudo named-checkzone nyc3.example.com db.nyc3.example.com

      Para omprobar la configuración de la zona inversa “128.10.in-addr.arpa”, ejecute el siguiente comando (cambie los números para que coincidan con su zona y archivo inversos):

      • sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

      Cuando no haya errores en sus archivos de configuración y zona, debería estar listo para reiniciar el servicio BIND.

      Reiniciar BIND

      Reinicie BIND:

      • sudo systemctl restart bind9

      Si configuró el firewall UFW, abra el acceso a BIND escribiendo lo siguiente:

      Con esto, servidor DNS primario quedará configurado y listo para responder a las consultas DNS. Ahora, crearemos el servidor DNS secundario.

      Configurar el servidor DNS secundario

      En la mayoría de los entornos, se recomienda configurar un servidor DNS secundario que responda a las solicitudes si el primario deja de estar disponible. Afortunadamente, el servidor DNS secundario se puede configurar de una manera mucho más sencilla.

      En ns2, edite el archivo named.conf.options:

      • sudo nano /etc/bind/named.conf.options

      En la parte superior del archivo, añada el ACL con las direcciones IP privadas de todos sus servidores de confianza:

      /etc/bind/named.conf.options — updated 1 of 2 (secondary)

      acl "trusted" {
              10.128.10.11;   # ns1
              10.128.20.12;   # ns2 - can be set to localhost
              10.128.100.101;  # host1
              10.128.200.102;  # host2
      };
      
      options {
      
              . . .
      

      Debajo de la directiva directory, añada las siguientes líneas:

      /etc/bind/named.conf.options — updated 2 of 2 (secondary)

              recursion yes;
              allow-recursion { trusted; };
              listen-on { 10.128.20.12; };      # ns2 private IP address
              allow-transfer { none; };          # disable zone transfers by default
      
              forwarders {
                      8.8.8.8;
                      8.8.4.4;
              };
      

      Guarde y cierre el archivo named.conf.options. El archivo debería ser exactamente igual al archivo named.conf.options de ns1, excepto porque debería estar configurado para escuchar en la dirección IP privada de ns2.

      Ahora, edite el archivo named.conf.local:

      • sudo nano /etc/bind/named.conf.local

      Defina las zonas esclavas que se corresponden con las zonas maestras en el servidor DNS primario. Observe que el tipo es “slave”, el archivo no contiene una ruta y hay una directiva masters que debería fijarse en la dirección IP privada del servidor DNS primario. Si definió varias zonas inversas en el servidor DNS primario, asegúrese de añadirlas en su totalidad aquí:

      /etc/bind/named.conf.local — updated (secondary)

      zone "nyc3.example.com" {
          type slave;
          file "db.nyc3.example.com";
          masters { 10.128.10.11; };  # ns1 private IP
      };
      
      zone "128.10.in-addr.arpa" {
          type slave;
          file "db.10.128";
          masters { 10.128.10.11; };  # ns1 private IP
      };
      

      Ahora, guarde y cierre el archivo named.conf.local.

      Ejecute el siguiente comando para comprobar la validez de sus archivos de configuración:

      Una vez comprobado esto, reinicie BIND:

      • sudo systemctl restart bind9

      Permita conexiones DNS al servidor alterando las reglas del firewall UFW:

      Ahora, tiene servidores DNS primario y secundario para la resolución de nombres y direcciones IP de la red privada. Ahora debe configurar sus servidores clientes para usar sus servidores DNS privados.

      Configurar clientes DNS

      A fin de que todos sus servidores en el ACL “trusted” puedan consultar sus servidores DNS, debe configurar cada uno de ellos para que utilicen ns1 y ns2 como servidores de nombres. Este proceso varía dependiendo de su sistema operativo, pero para la mayoría de distribuciones Linux implica añadir sus servidores de nombres al archivo /etc/resolv.conf.

      Clientes de Ubuntu 18.04

      En Ubuntu 18.04, la red se configura con Netplan, una abstracción que le permite escribir una configuración de red estandarizada y aplicarla a software de redes de backend no compatible. Para configurar el DNS, debemos escribir un archivo de configuración de Netplan.

      Primero, encuentre el dispositivo asociado con su red privada consultando la subred privada con el comando ip address:

      • ip address show to 10.128.0.0/16

      Output

      3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1 valid_lft forever preferred_lft forever

      En este ejemplo, la interfaz privada es eth1.

      A continuación, cree un nuevo archivo en /etc/netplan llamado 00-private-nameservers.yaml:

      • sudo nano /etc/netplan/00-private-nameservers.yaml

      Dentro de este, pegue el contenido siguiente. Deberá modificar la interfaz de la red privada, las direcciones de sus servidores DNS ns1 y ns2, y la zona DNS.

      Nota: Netplan usa el formato de serialización de datos YAML para sus archivos de configuración. Debido a que YAML utiliza sangría y espacios en blanco para definir la estructura de sus datos, asegúrese de que en su definición se utilice una sangría uniforme para evitar errores.

      /etc/netplan 00-private-nameservers.yaml

      network:
          version: 2
          ethernets:
              eth1:                                 # Private network interface
                  nameservers:
                      addresses:
                      - 10.128.10.11                # Private IP for ns1
                      - 10.132.20.12                # Private IP for ns2
                      search: [ nyc3.example.com ]  # DNS zone
      
      

      Guarde y cierre el archivo cuando haya terminado.

      A continuación, indique a Netplan que intente usar el nuevo archivo de configuración con netplan try. Si existen problemas que ocasionen una pérdida de redes, Netplan cancelará los cambios tras un tiempo de espera:

      Output

      Warning: Stopping systemd-networkd.service, but it can still be activated by: systemd-networkd.socket Do you want to keep these settings? Press ENTER before the timeout to accept the new configuration Changes will revert in 120 seconds

      Si la cuenta regresiva se actualiza correctamente en la parte inferior, la nueva configuración es al menos suficientemente funcional como para no interrumpir su conexión SSH. Pulse ENTER para aceptar la nueva configuración.

      Ahora, verifique la resolución DNS del sistema para determinar si se plicó su configuración de DNS:

      • sudo systemd-resolve --status

      Desplácese hasta ver la sección de la interfaz de su red privada. Debería ver las direcciones IP privadas de sus servidores DNS enumeradas primero, seguidas de algunos valores alternativos. Su dominio debería figurar en “DNS Domain”:

      Output

      . . . Link 3 (eth1) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 10.128.10.11 10.128.20.12 67.207.67.2 67.207.67.3 DNS Domain: nyc3.example.com . . .

      Con esto, su cliente debería quedar configurado para usar sus servidores DNS internos.

      Clientes de Ubuntu 16.04 y Debian

      En servidores de Ubuntu 16.04 y Debian Linux, puede editar el archivo /etc/network/interfaces:

      • sudo nano /etc/network/interfaces

      En su interior, encuentre la línea dns-nameservers y anteponga sus propios servidores de nombres a la lista que se encuentra allí. Debajo de esa línea, añada una opción dns-search orientada al dominio base de su infraestructura. En nuestro caso, esto sería “nyc3.example.com”:

      /etc/network/interfaces

          . . .
      
          dns-nameservers 10.128.10.11 10.128.20.12 8.8.8.8
          dns-search nyc3.example.com
      
          . . .
      

      Guarde y cierre el archivo cuando haya terminado.

      Ahora, reinicie sus servicios de red y aplique los nuevos cambios con los comandos siguientes. Asegúrese de sustituir eth0 por el nombre de su interfaz de red:

      • sudo ifdown --force eth0 && sudo ip addr flush dev eth0 && sudo ifup --force eth0

      Con esto debería reiniciarse su red sin que se desactive su conexión actual. Si funcionó correctamente, debería ver algo como esto:

      Output

      RTNETLINK answers: No such process Waiting for DAD... Done

      Compruebe que sus ajustes se hayan aplicado escribiendo lo siguiente:

      Debería ver sus servidores de nombres en el archivo /etc/resolv.conf, además de su dominio de búsqueda:

      Output

      # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 10.128.10.11 nameserver 10.128.20.12 nameserver 8.8.8.8 search nyc3.example.com

      Con esto, su cliente quedará configurado para usar sus servidores DNS.

      Clientes CentOS

      En CentOS, RedHat y Fedora Linux, edite el archivo /etc/sysconfig/network-scripts/ifcfg-eth0. Es posible que deba sustituir eth0 por el nombre de su interfaz de red primaria:

      • sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0

      Busque las opciones DNS1 y DNS2, y fije para ellas las direcciones IP privadas de sus servidores de nombres primario y secundario. Añada un parámetro DOMAIN que será el dominio básico de su infraestructura. En esta guía, sería “nyc3.example.com”:

      /etc/sysconfig/network-scripts/ifcfg-eth0

      . . .
      DNS1=10.128.10.11
      DNS2=10.128.20.12
      DOMAIN='nyc3.example.com'
      . . .
      

      Guarde y cierre el archivo cuando haya terminado.

      Ahora, reinicie el servicio de red escribiendo lo siguiente:

      • sudo systemctl restart network

      El comando puede demorarse unos segundos, pero debería hacer que regrese a la línea de comandos pronto.

      Compruebe que sus cambios se hayan aplicado escribiendo lo siguiente:

      Debería ver sus servidores de nombres y el dominio de búsqueda en la lista:

      /etc/resolv.conf

      nameserver 10.128.10.11
      nameserver 10.128.20.12
      search nyc3.example.com
      

      Su cliente ahora debería poder conectarse a sus servidores DNS y usarlos.

      Probar clientes

      Utilice nslookup para comprobar si sus clientes pueden enviar consultas a sus servidores de nombres. Debería poder hacer esto en todos los clientes que haya configurado y estén en el ACL “trusted”.

      Para los clientes de CentOS, es posible que deba instalar la utilidad con lo siguiente:

      • sudo yum install bind-utils

      Podemos comenzar realizando una búsqueda directa.

      Búsqueda directa

      Por ejemplo, podemos realizar una búsqueda directa para obtener la dirección IP de host1.nyc3.example.com ejecutando el siguiente comando:

      La consulta de “host1” se expande a “host1.nyc3.example.com” porque la opción search se fijó en su subdominio privado y las consultas de DNS intentarán realizar búsquedas en ese subdominio antes de buscar el host en otra parte. El resultado del comando anterior debería tener este aspecto:

      Output

      Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: host1.nyc3.example.com Address: 10.128.100.101

      A continuación, podemos comprobar búsquedas inversas.

      Búsqueda inversa

      Para probar la búsqueda inversa, consulte el servidor DNS con la dirección IP privada de host1:

      El resultado debería tener el siguiente aspecto:

      Output

      11.10.128.10.in-addr.arpa name = host1.nyc3.example.com. Authoritative answers can be found from:

      Si los nombres y las direcciones IP se resuelven a los valores correctos, eso significa que sus archivos de zona se configuraron correctamente. Si recibe valores inesperados, asegúrese de revisar los archivos de zona en su servidor DNS primario (por ejemplo, db.nyc3.example.com y db.10.128).

      ¡Felicitaciones! Sus servidores DNS internos ahora estarán correctamente configurados. A continuación, abordaremos el mantenimiento de sus registros de zona.

      Mantener registros DNS

      Ahora que dispone de un DNS interno activo, deberá mantener sus registros DNS para que se reflejen de forma precisa en su entorno de servidor.

      Añadir un host a un DNS

      Siempre que añada un host a su entorno (en el mismo centro de datos), le convendrá añadirlo al DNS. A continuación, se ofrece una lista de los pasos que debe seguir:

      Servidor de nombres primario

      • Archivo de zona de reenvío: añada un registro “A” para el nuevo host e incremente el valor de “Serial”.
      • Archivo de zona inversa: añada un registro “PTR” para el nuevo host e incremente el valor de “Serial”.
      • Añada la dirección IP privada del nuevo host al ACL “trusted” (named.conf.options).

      Pruebe sus archivos de configuración:

      • sudo named-checkconf
      • sudo named-checkzone nyc3.example.com db.nyc3.example.com
      • sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

      A continuación, vuelva a cargar BIND:

      • sudo systemctl reload bind9

      Con esto, su servidor primario debería estar configurado para el nuevo host.

      Servidor de nombres secundarios

      • Añada la dirección IP privada del nuevo host al ACL “trusted” (named.conf.options).

      Compruebe la sintaxis de la configuración:

      A continuación, vuelva a cargar BIND:

      • sudo systemctl reload bind9

      Su servidor secundario ahora aceptará conexiones del nuevo host.

      Configure el nuevo host para que use su DNS

      • Configure /etc/resolv.conf para que use sus servidores DNS.
      • Realice una prueba usando nslookup.

      Eliminar el host del DNS

      Si elimina un host de su entorno, o quiere quitarlo del DNS, simplemente quite todo lo que se añadió cuando agregó el servidor al DNS (es decir, el procedimiento inverso de los pasos anteriores).

      Conclusión

      Ahora puede consultar las interfaces de red privada de sus servidores por nombre, en lugar de hacerlo por dirección IP. Esto hace que la configuración de los servicios y aplicaciones sea más fácil porque ya no tendrá que recordar las direcciones IP privadas, y será más fácil leer y comprender los archivos. Además, ahora podrá cambiar sus configuraciones para que apunten a un nuevo servidor en un único lugar, su servidor DNS primario, en vez de tener que editar una variedad de archivos de configuración distribuidos, lo cual facilita el mantenimiento.

      Una vez que complete su configuración de DNS interna, y que sus archivos de configuración usen FQDN privados para especificar las conexiones de red, será esencial que se realice un mantenimiento correcto de sus servidores DNS. Si los dos dejan de estar disponibles, aquellos de sus servicios y aplicaciones que dependan de ellos dejarán de funcionar correctamente. Por ello, se recomienda configurar su DNS con al menos un servidor secundario y realizar copias de seguridad funcionales de todos ellos.



      Source link