Categoria: Debian

  • Laravel/Vite Remote Development Setup With NGINX

    ⚙️ Laravel/Vite Remote Development Setup
    This guide provides the necessary steps to configure your remote Nginx server and your Laravel/Vite application to enable Hot Module Replacement (HMR) for a seamless remote development experience over HTTPS.

    1. Configure Vite for Remote HMR

    You must tell Vite to use your public domain and the secure WebSocket protocol (wss) for HMR, and to listen on all interfaces.

    Edit your project’s vite.config.js file:

    JavaScript

    // vite.config.js

    import { defineConfig } from 'vite';
    import laravel from 'laravel-vite-plugin';
    
    export default defineConfig({
        plugins: [
            laravel([
                'resources/css/app.css',
                'resources/js/app.js',
            ]),
        ],
        server: {
            // 1. Listen on all interfaces so the outside world can connect
            host: '0.0.0.0', 
            port: 5173,
            // 2. CRUCIAL: Tell the browser the public address for HMR
            hmr: {
                // Replace with your actual remote domain (e.g., saladeformacao.pt)
                host: 'yourdomain.com',  //neste caso saladeformacao.pt
                // Use WSS because your Nginx is serving over HTTPS
                protocol: 'wss',        
            },
        }
    });
    

    2. Start Vite Dev Server and Clean Up

    On your remote server, run these commands via SSH:

    Remove the development marker file (if it exists). This forces Laravel to use the new HMR configuration when it creates the file again.

    Bash

    rm -f public/hot
    Start the development server. Keep this terminal window open while you are developing.

    Bash

    npm run dev

    3. Configure Nginx Reverse Proxy

    Nginx must be configured to act as a reverse proxy, redirecting all requests for Vite assets and WebSockets (HMR) from the public port 443 to the internal Vite server on port 5173.

    Add the following location block inside your Nginx server block that listens on 443 ssl:

    Nginx

    server {
        listen 443 ssl;
        server_name yourdomain.com;
        # ... other SSL/root configuration ...
    
        # ----------------------------------------------------
        # NGINX PROXY FOR VITE DEVELOPMENT ASSETS AND HMR (PORT 5173)
        # ----------------------------------------------------
        location ~ ^/(resources/|@vite/|node_modules/) {
            # The internal address where Vite is running
            proxy_pass http://localhost:5173; 
    
            # Standard headers
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-Proto $scheme;
    
            # **CRITICAL: WebSocket headers for HMR**
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
        }
    
        # ... Your existing PHP/Laravel root location ...
        location / {
            try_files $uri $uri/ /index.php?$query_string;
        }
    }
    

    Apply Nginx Changes
    Test and reload the Nginx configuration:

    Bash

    sudo nginx -t
    sudo systemctl reload nginx
    

    4. Firewall Check (Important)

    Ensure your server’s firewall (e.g., UFW) or cloud security settings (e.g., AWS Security Groups) allows incoming connections on port 5173. If this port is closed, the browser cannot connect to the Vite server.

    Bash

    #  Example for UFW to allow access from any IP
    sudo ufw allow 5173
    
  • Pureftpd Instalação no Debian

    Resumo

    Instalar:
    apt-get install pure-ftpd-common pure-ftpd

    Criar grupo local:
    groupadd ftpgroup

    Criar utilizador local com o grupo criado no passo anterior:
    useradd -g ftpgroup -d /dev/null -s /etc ftpuser

    Criar utilizador teste1:
    pure-pw useradd test1 -u ftpuser -d /home/ftpusers/test1

    Sempre que houver alteração nos utilizadores atualizar a base de dados:
    pure-pw mkdb

    Alterar pass do utilizador teste1:
    pure-pw passwd test1
    pure-pw mkdb

    Remover utilizador teste1:
    pure-pw userdel test1
    pure-pw mkdb

    Desenvolvimento

    Fonte: https://www.debianhelp.co.uk/pureftp.htm

  • CPU – Escala de frequências

    cpupower

    Verificar se o software está instalado

    cpupower

    Se aparecer:

    -bash: cpupower: command not found

    É porque é necessário instalar o cpupower:

    apt install linux-cpupower

    Verificar informalçao:

    cpupower frequency-info
    
    analyzing CPU 0:
    driver: intel_pstate
    CPUs which run at the same hardware frequency: 0
    CPUs which need to have their frequency coordinated by software: 0
    maximum transition latency: Cannot determine or is not supported.
    hardware limits: 1.60 GHz - 3.40 GHz
    available cpufreq governors: performance powersave
    current policy: frequency should be within 1.60 GHz and 3.40 GHz.
    The governor "powersave" may decide which speed to use
    within this range.
    current CPU frequency: Unable to call hardware
    current CPU frequency: 3.04 GHz (asserted by call to kernel)
    boost state support:
    Supported: yes
    Active: yes
    3200 MHz max turbo 4 active cores
    3300 MHz max turbo 3 active cores
    3300 MHz max turbo 2 active cores
    3400 MHz max turbo 1 active cores

    Em available cpufreq governors temos: performance e powersave.

    Para alterar para performance, usamos o comando:

    cpupower frequency-set -g performance

    Ou para economia de energia:

    cpupower frequency-set -g powersave

    Fonte: https://wiki.debian.org/CpuFrequencyScaling

  • Debian 10 como servidor Time Machine

    Configurar o Debian 10 (buster) para atuar como um servidor Apple Time Machine:

    Instale pacotes necessários:

    sudo apt install netatalk avahi-daemon

    Editar o ficheiro de configuração netatalk:

    sudo nano /etc/netatalk/afp.conf

    Adicionar uma secção para o Time Machine:

    [Time Machine]
      path = /pastaDeBackup/TimeMachine
      time machine = yes
      spotlight = no

    Criar uma diretoria para atuar como unidade do Time Machine:

    sudo mkdir -p /pastaDeBackup/TimeMachine
    sudo chown nobody:nogroup /pastaDeBackup/TimeMachine
    sudo chmod 777 /pastaDeBackup/TimeMachine

    É necessário uma conta de utilizador no servidor. Para melhorar a segurança, criar um grupo “timemachine” adicionar os utilizadores a este grupo “usermod -a -G timemachine <utilizador>”.

    Fazer alteração nas permissões da pasta TimeMachine:

    sudo chown root:timemachine /pastaDeBackup/TimeMachine

    Iniciar netatalk:

    sudo systemctl restart netatalk

    No MacOs, abrir as configurações do Time Machine nas Preferências do Sistema. Ir a “Selecionar Disco … ” para escolher a unidade de backup do Time Machine.

  • Protejer o Nginx com o Let’s Encrypt no Debian 10

    Let’s Encrypt é uma autoridade de certificação (CA) que fornece uma maneira direta de obter e instalar certificados TLS / SSL gratuitos, possibilitando HTTPS criptografado em servidores da de páginas web.

    Pré-requisitos

    • Debian 10 server. (tutorial pendente)
    • Um nome de domínio registado. Podem fazê-lo em registrars como o dns.pt. (tutorial pendente)
    • Registos dos DNS configurados para o teu servidor. (tutorial pendente)
    • Nginx instalado. Segui a primeira parte da instalação no link a seguir (Instalar Linux, Nginx, MariaDB, PHP (LEMP stack) no Debian 10).

    1 – Instalar o Certbot

    Atualizar a lista de pacotes entes de qualquer instalação:

    sudo apt update

    Instalar o pacote python3-certbot-nginx, se tudo correr normal, os pacotes dependentes também serão instalados:

    sudo apt install python3-certbot-nginx

    Pergunta se queremos instalar o pacote e dependencias, clicamos em <enter>.

    O Certbot está pronto para ser usado, mas para configurar o SSL no Nginx, precisamos verificar algumas das configurações do Nginx.

    2 – Verificar configuraçães do Nginx

    Se o nginx estiver configurado como diz no tutorial colocado em pré-requisitos, devemos ter a configuração com caminho “/etc/nginx/sites-available/o.teu.dominio“. Para verificar e se necessário alterar, fazer:

    sudo nano /etc/nginx/sites-available/o.teu.dominio

    É apresentado o editor de ficheiros “nano” com o conteúdo do caminho colocado à frente do nome do editor.

    Encontrar a linha com a diretiva “server_name” e verificar se tem os domínios corrects que queremos usar como nomes comuns nos certificados.

    #...outras diretivas e programas antes
    server_name o.teu.dominio www.o.teu.dominio;
    #...outras diretivas e programas depois

    Se está correto só é necessário fechar com “ctrl+x” no teclado. Caso os domínios não forem os corretos, proceder com as alterações e guardar e fechar com “ctrl+x” carregar em “Y” ou “S” (depende da configuração da linguagem) e então carregar em <enter> para guardar no caminho apresentado.

    Testar a configuração:

    sudo nginx -t

    Se as mensagens apresentarem erros, fazer verificação do ficheiro de configuração. Caso apresente configuração com sucesso proceder ao reinício do serviço nginx:

    sudo systemctl reload nginx

    Com esta configuração o Certbot pode encontrar o bloco de servidor correto e atualizá-lo. Que será o próximo passo.

    Nota: a esta altura já deveríamos ter a firewall do servidor configurada para permitir tráfego seguro, porta 443. Caso não esteja, fazer as alterações necessárias que podem ver na ligação que está em pré.requisitos na instalação do nginx.

    3 – Obter o certificado SSL

    O Certbot tem a possibilidade de obter certificados através de plugins (software adicional). O plugin do nginx “--nginx” toma conta da configuração dos certificados no(s) servidor(s) que correspondem aos domínios colocados em argumento (“-d“) e faz o reinício do servidor, se necessário, como vamos poder ver a seguir:

    sudo certbot --nginx -d o.teu.dominio -d www.o.teu.dominio -d outros.dominios.se.necessario

    Se tivermos sucesso, o Certbot perguntará como desejamos definir as configurações de HTTPS.

    Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    1: No redirect - Make no further changes to the webserver configuration.
    2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
    new sites, or if you're confident your site works on HTTPS. You can undo this
    change by editing your web server's configuration.
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

    Se estamos aqui é porque não estamos muito acostumados com a criação de certificados ou porque o queremos fazer de forma mais rápida. Sendo assim a resposta será a “2” e pressionamos <enter> . Se tudo funcionar bem iremos obter algo como:

    Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/o.teu.dominio
    Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/o.teu.dominio
    Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/o.teu.dominio
    nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/etc/ssl/certs/nginx-selfsigned.crt"
    
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Congratulations! You have successfully enabled https://o.teu.dominio,
    https://www.o.teu.dominio, and https://outros.dominios.se.necessario
    
    You should test your configuration at:
    https://www.ssllabs.com/ssltest/analyze.html?d=o.teu.dominio
    https://www.ssllabs.com/ssltest/analyze.html?d=www.o.teu.dominio
    https://www.ssllabs.com/ssltest/analyze.html?d=outros.dominios.se.necessario
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    
    IMPORTANT NOTES:
     - Congratulations! Your certificate and chain have been saved at:
       /etc/letsencrypt/live/o.teu.dominio/fullchain.pem
       Your key file has been saved at:
       /etc/letsencrypt/live/o.teu.dominio/privkey.pem
       Your cert will expire on 2020-03-05. To obtain a new or tweaked
       version of this certificate in the future, simply run certbot again
       with the "certonly" option. To non-interactively renew *all* of
       your certificates, run "certbot renew"
     - Your account credentials have been saved in your Certbot
       configuration directory at /etc/letsencrypt. You should make a
       secure backup of this folder now. This configuration directory will
       also contain certificates and private keys obtained by Certbot so
       making regular backups of this folder is ideal.
     - If you like Certbot, please consider supporting our work by:
    
       Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
       Donating to EFF:                    https://eff.org/donate-le

    Nota: Se o nosso servidor estiver com um certificado auto-assinado, pode aparecer uma aviso que será ignorado mas devemos comentá-las:

    sudo nano /etc/nginx/sites-available/o.teu.dominio

    Colocar um “#” antes das linhas “include snippets/auto-assinado.conf;”  e  “include snippets/ssl-params.conf;” e passam a ser ignoradas:

    #...    
    #include snippets/auto-assinado.conf;
    #include snippets/ssl-params.conf;
    #...

    Guardar e fechar com “ctrl+x” carregar em “Y” ou “S” (depende da configuração da linguagem) e carregar em <enter> para guardar no caminho apresentado. Testar com:

    sudo nginx -t

    Reiniciar o servidor:

    sudo systemctl reload nginx

    Neste momento já devemos ter uma página com certificado Let’s Encrypt válido por 90 días e com o programados de tarefas “cron” configurado para que seja feita a renovação. Para verificar , fazer:

    cat /etc/cron.d/certbot

    Até à próxima…

  • Criar um certificado SSL auto-assinado para Nginx no Debian 10

    TLS, ou transport layer security (segurança da camada de transporte), e seu antecessor SSL, que significa secure sockets layer (camada de soquetes seguros), são protocolos da internet usados ​​para encriptar o tráfego normal num invólucro protegido.

    Pré-requisitos:

    • Servidor Debian 10 “buster”, utilizador que não seja root mas que tenha privilégios de sudo. E para melhor segurança com uma Firewall ativa. No Debian 10 o pacote ufw vem instalado mas desativado.
    • O nginx instalado. Seguir a parte do tutorial em “Instalar Linux, Nginx, MariaDB, PHP (LEMP stack) no Debian 10“.
    (mais…)
  • Instalar Linux, Nginx, MariaDB, PHP (LEMP stack) no Debian 10

    Tutorial otimizado para Debian 10 “buster”.

    Pré-requisitos: Servidor Debian 10,

    Introdução

    “LEMP” é o acrónimo de Linux operating system, com o servidor web (E)Nginx . Os dados são armazenado na MariaDB e o processamento dinâmico é tratado pelo PHP.

    Instalar Nginx

    Atualizar a lista de pacotes

    sudo apt update

    Instalar Nginx

    sudo apt install nginx

    Depois de instalado, por norma, o servidor web fica funcional. Para testar abrimos um browser e verificamos com o ip do Servidor abre a página. Caso não abra pode ser de alguma firewall que possa estar a impedir. Em seguida vamos configurar a firewall para permitir ligações na porta 80.

    (mais…)
  • Adicionar módulo Nginx ao Webmin

    Tutorial optimizador para a versão Debian 10 (buster).

    Pré-requisitos: Debian 10, pacote Nginx e webmin instalados.

    1. Instalar no debian “libhtml-parser-perl” com o comando no terminal: “sudo apt install libhtml-parser-perl“.
    2. No Webmin clicar no painel do lado esquerdo (tema original) em “Webmin-> Webmin Configuration” -> quadro com o nome “Webmin Modules“.
    3. Clicar em “Third party module from” e clicar no botão, com aspeto de globo ao lado direito do formulário e da opção “Third party module from“.
    4. Aparece janela. Na parte superior está uma caixa de introdução (formulário) que podemos usar para filtrar e escrevemos “Nginx“. Clicar na em Nginx na lista das opções possíveis.
    5. Fim da instalação do módulo. Para configurar: ir a “Servers” e clicar em “Nginx webserver“.