Tag: web

  • Integração de suíte office a Nextcloud

    Nextcloud tem um ecossistema com muitas possibilidades de aplicativos e funcionalidades adicionais que podem ser integradas. Uma das integrações mais comuns de serem feitas é com uma suíte office, permitindo edição e colaboração em documentos, planilhas e apresentações, como também é feito através do Google Workspace.

    Essa integração é feita conectando o Nextcloud a uma plataforma de colaboração e edição de documentos acessível via web. Existem duas principais plataformas como opções: ONLYOFFICE Docs Community e Collabora Online Developer Edition (CODE).

    Ambos têm uma UI familiar para usuários do Microsoft Office, ambos são compatíveis com o padrão Open Document Format (ODF), que engloba os formatos de arquivos .ods e .odt, e também com o Office Open XML (OOXML) da Microsoft, que engloba os formatos .xlsx e .docx.

    Enquanto o ONLYOFFICE é um projeto independente, o Collabora é um projeto baseado no LibreOffice, mas construído com uma UI diferente. Ambos também são distribuídos em formato Docker, o que permite uma facilidade de instalação e instruções independem do sistema operacional anfitrião.

    Eu já usei tanto o LibreOffice quanto o ONLYOFFICE Desktop Editors, versões offline das suítes e, enquanto um grande ponto forte do ONLYOFFICE é a compatibilidade com o padrão OOXML criado pela Microsoft, acabei aderindo ao LibreOffice por questão de desempenho.

    Como já me deparei com pequenas inconsistências de formatação ao criar um documento em uma suíte e abrir em outra, seguir com o Collabora foi mais adequado para manter uma boa compatibilidade com meus documentos existentes.

    A instalação foi feita com Docker através da minha instalação do Portainer. Ao criar um contêiner, defina o nome, a imagem a ser usada para a implantação e o mapeamento de portas.

    Nas configurações avançadas, defina as variáveis de ambiente:

    • domain – endereço do Nextcloud que irá utilizar a plataforma CODE, expresso como regex.
    • server_name – nome do servidor que hospeda o CODE e a porta exposta. A porta pode ser diferente da 9980 mapeada pelo docker, dependendo da regra de encaminhamento de porta no firewall OU do proxy reverso utilizado.
    • username e password – usuário e senha para o painel de administrador.

    Observações:

    O servidor precisa ter o mesmo domínio que o Nextcloud – nesse caso exemplo.com, caso contrário o Collabora retorna erros 403.

    Além disso, o Nextcloud precisa estar exposto na porta padrão HTTPS. Quando exposto em portas alternativas, essa porta é passada para o servidor CODE como parte da URL na requisição HTTP e o Collabora não identifica, recusando a conexão com código 403.

    Defina a política de reinicialização.

    E então, basta implantar o contêiner. Alternativamente, utilizando o Docker por linha de comando em vez do Portainer:

    docker run -t -d \
      -p 9980:9980 \
      -e "domain=nextcloud\\.exemplo\\.com" \
      -e "server_name=code.exemplo.com:2345" \
      --restart on-failure \
      --name CODE \
      collabora/code:latest

    A configuração do proxy reverso, além de necessária para minha infraestrutura, é recomendada e a configuração para o nginx é fornecida no próprio site do projeto. Adaptando para esse caso:

    server {
    
      listen 2345 ssl;
      listen [::]:2345 ssl;
      ssl_certificate /etc/letsencrypt/live/code.exemplo.com/fullchain.pem;
      ssl_certificate_key /etc/letsencrypt/live/code.exemplo.com/privkey.pem;
      server_name code.exemplo.com;
      
      location ^~ /browser {
        proxy_pass https://10.8.0.6:9980;
        proxy_set_header Host $host;
      }
     
      location ^~ /hosting/discovery {
        proxy_pass https://10.8.0.6:9980;
        proxy_set_header Host $host;
      }
      
      location ^~ /hosting/capabilities {
        proxy_pass https://10.8.0.6:9980;
        proxy_set_header Host $host;
      }
      
      location ~ ^/cool/(.*)/ws$ {
        proxy_pass https://10.8.0.6:9980;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Host $host;
        proxy_read_timeout 36000s;
      }
      
      location ~ ^/cool {
        proxy_pass https://10.8.0.6:9980;
        proxy_set_header Host $host;
      }
      
      location ^~ /cool/adminws {
        proxy_pass https://10.8.0.6:9980;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Host $host;
        proxy_read_timeout 36000s;
      }
    }

    No Nextcloud, basta habilitar o aplicativo Nextcloud Office e, nas configurações de administrador, adicionar a URL e porta do servidor CODE.

    Também é recomendado restringir a origem das requisições WOPI aceitas pelo Nextcloud ao IP do servidor CODE.

    Finalmente, o Nextcloud já deve estar pronto para abrir e editar documentos via web utilizando o Collabora.

    Você pode acompanhar informações de uso do servidor no painel de administrador com seu usuário e senha definidos anteriormente em:

    https://code.exemplo.com:2345/browser/dist/admin/admin.html

  • Configuração do nginx como proxy reverso para WordPress, Nextcloud e Proxmox

    Nenhuma das publicações sobre instalação de WordPress ou Nextcloud aborda acesso via HTTPS ou certificados SSL, apenas HTTP.

    Acontece que, na minha infraestrutura, isso é centralizado em uma instalação do nginx, atuando como proxy reverso. O servidor que hospeda o nginx e o servidor de OpenVPN são a mesma máquina: um VPS com 512 MB de RAM e 1vCPU.

    O nginx recebe as requisições em HTTPS e as encaminha em HTTP* de forma segura para os outros servidores – clientes da VPN: WordPress, Nextcloud e Proxmox – 3 máquinas diferentes.

    * Proxmox usa HTTPS por padrão mas com um certificado verificado por uma CA interna

    Vantagens:

    • só é necessário gerenciar os certificados em um servidor, independente de quantos sites são.
    • as 3 máquinas diferentes poderiam estar em qualquer rede, qualquer lugar – isso é, se não fossem virtualizadas dentro do Proxmox, podendo até ser uma rede residencial que bloqueia tráfego de entrada (muito obrigado, Claro), basta se conectar na VPN.

    Desvantagem:

    • existe um pouco de latência devido à distância entre as máquinas (Rio de Janeiro) e o VPS (São Paulo).

    Ainda que fosse possível abrir as portas para a rede e o OpenVPN não fosse necessário, usar o nginx como um proxy reverso na mesma LAN ainda poderia ser vantajoso pelo o gerenciamento centralizado dos certificados SSL e monitoramento de logs de acesso.

    Os arquivos de configuração do nginx para cada site devem ficar localizados em /etc/nginx/sites-available e para habilitá-los basta criar um symlink em /etc/nginx/sites-enabled com:

    # ln -s /etc/nginx/sites-available/sua_config /etc/nginx/sites-enabled/

    A primeira configuração recomendada é redirecionar todo o tráfego de entrada em HTTP para a porta segura HTTPS. No arquivo /etc/nginx/sites-enabled/default, configure o servidor padrão da seguinte forma:

    server {
        listen 80 default_server;
        server_name _;
        return 301 https://$host$request_uri;
    }

    Em todos os exemplos de configuração abaixo, substitua o nome do servidor (FQDN), o caminho para o certificado e chave SSL e o IP privado para onde deve ser encaminhada a solicitação.

    Como mencionado, é possível usar a mesma porta para todos os servidores, como a porta padrão HTTPS, desde que cada um tenha o parâmetro server_name diferente, cada um com um nome de domínio (FQDN).

    Configuração para o Proxmox:

    upstream proxmox {
        server "seuproxmox.dominio.com";
    }
    
    server {
        listen 443 ssl;
        listen [::]:443 ssl;
        server_name seuproxmox.dominio.com;
        ssl_certificate /etc/letsencrypt/live/seu.dominio.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/seu.dominio.com/privkey.pem;
        proxy_redirect off;
        location / {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_pass https://10.8.0.2:8006;
            proxy_buffering off;
            client_max_body_size 0;
            proxy_connect_timeout  3600s;
            proxy_read_timeout  3600s;
            proxy_send_timeout  3600s;
            send_timeout  3600s;
        }
    }

    Para o Nextcloud:

    server {
        listen 443 ssl;
        listen [::]:443 ssl;
        ssl_certificate /etc/letsencrypt/live/seu.dominio.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/seu.dominio.com/privkey.pem;
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
        add_header X-Content-Type-Options "nosniff";
        server_name seunextcloud.dominio.com;
        location / {
            proxy_pass http://10.8.0.3;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_redirect off;
        }
        send_timeout 1800;
    }

    Configurações adicionais são recomendadas no lado do servidor Nextcloud, no arquivo /var/www/nextcloud/config/config.php

      'trusted_proxies' =>
      array (
        0 => '10.8.0.1',
      ),
      'overwritehost' => 'seunextcloud.dominio.com',
      'overwriteprotocol' => 'https',
      'overwritecondaddr' => '^10\\.8\\.0\\.1$',
      'overwritewebroot' => '/',
      'overwrite.cli.url' => 'https://seunextcloud.dominio.com',

    O nginx limita por padrão o corpo das requisições HTTP a 1 MB de tamanho, retornando o erro 413 para tentativas de upload de arquivos maiores que isso.

    Essa configuração pode ser ajustada com os parâmetros a seguir no arquivo /etc/nginx/nginx.conf, devendo ser ajustada de acordo com a sua necessidade e a capacidade do seu servidor.

    http {
    	client_max_body_size 30M;
    	client_body_buffer_size 30M;
    }

    Os aplicativos do Nextcloud, tanto para smartphone quanto desktop, usam o protocolo WebDAV, uma extensão do HTTP, que divide os arquivos em pedaços que são enviados em cada requisição. Ou seja, arquivos maiores que 30M podem ser enviados através dos aplicativos. Navegadores web, no entanto, não usam o mesmo protocolo, e podem acabar enviando os arquivos sem fragmentá-los.

    Para o WordPress:

    server {
        listen 443 ssl;
        listen [::]:443 ssl;
        ssl_certificate /etc/letsencrypt/live/seu.dominio.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/seu.dominio.com/privkey.pem;
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
        add_header X-Content-Type-Options "nosniff";
        server_name seuwordpress.dominio.com;
        location / {
            proxy_pass http://10.8.0.4;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_redirect off;
        }
        send_timeout 1800;
    }

    Configurações adicionais são requeridas no lado do servidor do WordPress, no arquivo /var/www/html/wp-config.php:

    define('WP_HOME', 'https://seuwordpress.dominio.com');
    define('WP_SITEURL', 'https://seuwordpress.dominio.com');
    
    if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
        $_SERVER['HTTPS'] = 'on';
    }
    
    if (isset($_SERVER['HTTP_X_FORWARDED_HOST'])) {
        $_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
    }

    Sugestão de configuração adicional para o WordPress – o WordPress não tem um mecanismo de proteção contra tentativas de acesso por força bruta. Para mitigar isso, além de usar boas senhas, você pode limitar o acesso por IP às localizações /wp-admin, /wp-login.php e /xmlrpc.php na configuração do proxy reverso adicionando essa configuração:

    server {
        location ~* ^/(wp-admin|wp-login.php) {
            allow 186.205.1.165;    # seu IP de casa
            allow 191.252.110.50;    # seu IP do trabalho
            deny all;
            proxy_pass http://10.8.0.4;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    
        location /xmlrpc.php {
            deny all;
        }
    }

    Após configurado, reinicie o serviço.

    # systemctl restart nginx

    Caso ainda não tenha certificados SSL válidos, eles podem ser obtidos gratuitamente com a Let’s Encrypt, uma organização sem fins lucrativos, com o comando certbot. Primeiro, pare o serviço nginx, já que o certbot vai criar um processo que também vai escutar na porta 80. Então, use o comando nesse formato:

    # certbot certonly --standalone -d seu.dominio.com -d seunextcloud.dominio.com -d seuproxmox.dominio.com -d seuwordpress.dominio.com

    Siga os prompts do programa e, ao terminar, reinicie o nginx.service mais uma vez.

    Caso esteja usando o proxy reverso para servidores dentro de uma VPN, você pode querer ver isso aqui.

  • Instalação e configuração de servidor Nextcloud

    Nextcloud é uma solução de armazenamento de arquivos acessível via web, como Google Drive, que conta também com aplicativos de calendário, contatos, mensagens e chamadas de vídeo, cliente de e-mail e suporte a compartilhamento de arquivos. Também tem suporte a integração de suíte office, através do ONLYOFFICE ou Nextcloud Office (baseado no LibreOffice).

    Além disso, Nextcloud trás também o conceito de federação: instâncias distintas do Nextcloud podem se comunicar se assim os administradores quiserem, permitindo uma rede descentralizada de servidores, onde um usuário de uma instância pode se comunicar e compartilhar arquivos com um usuário de outra.

    É software livre e aberto, licenciado sob a AGPLv3, e conta também com planos empresariais.

    No momento os sistemas recomendados para o Nextcloud são Ubuntu 24.04 e RHEL 9, mas tem suporte também a outros como OpenSUSE, Debian e Alpine. Aqui vamos usar o Ubuntu 24.04.

    O Nextcloud precisa de: um servidor web, um banco de dados e PHP. Eu segui a instalação com Apache pro servidor web e PostgreSQL pro banco de dados.

    Outras alternativas suportadas são Nginx para o servidor web e MySQL e MariaDB para o banco de dados.

    Instalação e configuração do Apache com PHP:

    # apt install apache2 php

    Caso tenha habilitado o firewall (Ubuntu traz o UFW desabilitado por padrão), permita o acesso por http:

    # ufw allow http

    Visite o seu servidor web via http e verifique que o Apache funciona. Coloque um arquivo como index.php na pasta do servidor web /var/www/html com o conteúdo

    <?php phpinfo() ?>

    e visite sua página no local /index.php para verificar que o Apache está processando PHP.

    Instalando e configurando o banco de dados:

    # apt install postgresql
    # sudo -u postgres psql

    Isso vai te levar à linha de comando do PostgreSQL, onde você pode criar o usuário e o banco de dados a ser usado no Nextcloud:

    > CREATE USER nextcloud_operator WITH PASSWORD 'senhaNoPost-it';
    > CREATE DATABASE nextcloud_db WITH OWNER nextcloud_operator TEMPLATE template0 ENCODING 'UTF8';
    > \q

    Baixe o arquivo do servidor em https://nextcloud.com/install/

    Instale o utilitário unzip com

    # apt install unzip

    Extraia o arquivo .zip na pasta /var/www. Você vai ver uma pasta nextcloud. Mude o proprietário dela e dos arquivos e subpastas para o usuário www-data, que executa o Apache:

    # chown -hR www-data:www-data /var/www/nextcloud

    Edite o arquivo de configuração do Apache,
    /etc/apache2/sites-enabled/000-default.conf
    para alterar/adicionar as seguintes configurações:

    	DocumentRoot /var/www/nextcloud
    
    	<Directory /var/www/nextcloud/>
    	Require all granted
    	AllowOverride All
    	Options Indexes FollowSymLinks MultiViews
    		<IfModule mod_dav.c>
    			Dav off
    		</IfModule>
    	</Directory>

    Instale outros módulos PHP necessário para o Nextcloud:

    # apt install php-curl php-xml php-gd php-mbstring php-zip php-pgsql 

    Reinicie seu servidor web

    # systemctl restart apache2.service

    e dê sequência à instalação pela página web. O básico já está funcionando.

    Agora existem alguns ajustes que podem ser feitos e você pode vê-los na seção de Configurações de administração > Visão geral

    Um dos principais é o limite de memória usada na execução de scripts PHP. O recomendado é pelo menos 512mb mas a configuração padrão usa 128mb.

    Outro é o limite do buffer do módulo OPcache, para o qual é sugerido um valor acima de 8mb.

    Ajuste os seguintes valores no arquivo
    /etc/php/8.3/apache2/php.ini

    memory_limit = 512M
    opcache.interned_strings_buffer=32

    E no arquivo /etc/php/8.3/cli/php.ini

    opcache.interned_strings_buffer=32

    e reinicie o Apache.

    Algumas mensagens de erro vão sugerir que você execute um script occ com algum argumento. Você pode fazer isso com

    # sudo -u www-data php /var/www/nextcloud/occ argumento_sugerido

    Sugestão de configuração adicional: os arquivos de usuários ficam na pasta /var/www/nextcloud/data, dentro da pasta raiz do Nextcloud. No caso de um bug num dos scripts PHP ou no servidor web, arquivos privados poderiam ser expostos. Então você pode querer configurar a pasta data em outro local, fora da raiz /var/www do servidor web, como por exemplo /var/nextcloud_data.

    Essas e outras questões menos críticas de configuração são abordadas também na documentação oficial do Nextcloud.

    O acesso via HTTPS será feito utilizando o servidor web Nginx atuando como proxy reverso, abordado em outra postagem.

  • Instalação e configuração do WordPress

    WordPress é um sistema livre e aberto de gestão de conteúdo para a web, baseado em PHP e banco de dados compatíveis com MySQL. É comumente usado para criação de blogs, lojas virtuais e landing pages. O WordPress é distribuído gratuitamente sob a licença GPL-2.0, contando também com a opção de plugins e temas pagos que podem ser distribuídos sob outras licenças.

    Antes de começar o processo de instalação, é bom verificar os requisitos do WordPress pra determinar em qual versão de qual sistema operacional instalar, já que ele tem requisitos de versão mínima recomendada do interpretador PHP e dos bancos de dados MySQL e MariDB.

    Eu optei pelo CentOS Stream 10, mas as instruções podem se aplicar também a diferentes versões, bem como sistemas da mesma “família”: Fedora, RHEL, Alma Linux e Rocky Linux.

    O WordPress pode ser baixado em: https://br.wordpress.org/download/

    Comece instalando os pacotes necessários – servidor web, PHP e banco de dados:

    # dnf install httpd php php-mysqlnd php-gd mariadb-server

    Habilite e inicie os serviços.

    # systemctl enable --now httpd mariadb php-fpm

    Configure o firewall:

    # firewall-cmd --permanent --add-service=http
    # firewall-cmd --reload

    Você pode testar se o servidor web está ativo e processando PHP criando um arquivo /var/www/html/index.php com o seguinte conteúdo:

    <?php phpinfo() ?>

    Após verificar que está tudo funcionando, hora de configurar o banco de dados. Comece com o comando:

    # mysql_secure_installation

    E siga os prompts com o que for recomendado:

    NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
          SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!
    
    In order to log into MariaDB to secure it, we'll need the current
    password for the root user. If you've just installed MariaDB, and
    haven't set the root password yet, you should just press enter here.
    
    Enter current password for root (enter for none):
    OK, successfully used password, moving on...
    
    Setting the root password or using the unix_socket ensures that nobody
    can log into the MariaDB root user without the proper authorisation.
    
    You already have your root account protected, so you can safely answer 'n'.
    
    Switch to unix_socket authentication [Y/n] n
     ... skipping.
    
    You already have your root account protected, so you can safely answer 'n'.
    
    Change the root password? [Y/n] n
     ... skipping.
    
    By default, a MariaDB installation has an anonymous user, allowing anyone
    to log into MariaDB without having to have a user account created for
    them.  This is intended only for testing, and to make the installation
    go a bit smoother.  You should remove them before moving into a
    production environment.
    
    Remove anonymous users? [Y/n] Y
     ... Success!
    
    Normally, root should only be allowed to connect from 'localhost'.  This
    ensures that someone cannot guess at the root password from the network.
    
    Disallow root login remotely? [Y/n] Y
     ... Success!
    
    By default, MariaDB comes with a database named 'test' that anyone can
    access.  This is also intended only for testing, and should be removed
    before moving into a production environment.
    
    Remove test database and access to it? [Y/n] Y
     - Dropping test database...
     ... Success!
     - Removing privileges on test database...
     ... Success!
    
    Reloading the privilege tables will ensure that all changes made so far
    will take effect immediately.
    
    Reload privilege tables now? [Y/n] Y
     ... Success!
    
    Cleaning up...
    
    All done!  If you've completed all of the above steps, your MariaDB
    installation should now be secure.
    
    Thanks for using MariaDB!

    Depois entre no shell do MariaDB com:

    # mysql

    E crie o banco de dados e usuário que serão usados pelo WordPress e configure as devidas permissões:

    > CREATE DATABASE wordpress_db COLLATE = 'utf8mb4_unicode_ci';
    
    > CREATE USER 'wordpress_user'@'localhost' IDENTIFIED BY 'uma_senha_segura';
    
    > GRANT ALL PRIVILEGES ON wordpress_db.* TO 'wordpress_user'@'localhost';
    
    > FLUSH PRIVILEGES;
    
    > \q

    Com isso pronto, extraia o zip baixado do WordPress na raiz do seu servidor web, /var/www/html, ou em uma subpasta. Então acesse sua página e configure seu WordPress.

    Detalhe adicional: você provavelmente vai se deparar com um “Erro desconhecido” ao tentar adicionar outros temas ou plugins. Isso acontece porque o módulo de segurança SELinux restringe o acesso dos processos do httpd à rede.

    Para permitir o acesso de forma permanente:

    # setsebool -PV httpd_can_network_connect true

    Dicas:

    • Ajuste a permissão do arquivo wp-config.php para 400 e mova-o para fora da raiz do diretório do WordPress. Ex: WordPress está em /var/www/html, mova o arquivo para /var/www. Nenhuma configuração é requerida o WordPress funciona.
    • O WordPress não tem nenhuma proteção contra ataques de força bruta na página wp-admin. Limite o acesso por IP. No meu caso, isso foi configurado no Nginx que atua como proxy reverso, o que vai ser abordado em outro post.