Categoria: Homelab

  • Mais um passo na evolução do meu homelab

    Hoje foi mais um daqueles dias em que o meu homelab deu um salto importante.

    Talvez a alteração mais visível de hoje tenha sido a criação de um novo hostname no No-IP: explicacoes.ddns.net

    A ideia é simples: quem escrever este endereço no navegador será encaminhado diretamente para a página das minhas Explicações de Matemática, sem precisar de navegar pelo restante site.

    É uma solução prática para colocar em cartões de visita, folhetos ou anúncios.

    Foi mais um dia de aprendizagem, de testes, de alguns erros pelo caminho e, claro, da satisfação de ver tudo a funcionar no final. É precisamente este tipo de desafios que torna um homelab tão interessante: estamos sempre a aprender algo novo.

  • Reforçando a privacidade do Homelab com Unbound e Tailscale Exit Node

    Nos últimos dias decidi dar mais um passo na segurança e privacidade do meu homelab.

    O objetivo era simples: deixar de depender de serviços públicos de DNS e garantir que todos os meus dispositivos, mesmo quando estão fora de casa, utilizam a mesma infraestrutura de rede.

    Instalação do Unbound

    O primeiro passo foi instalar o Unbound na máquina alexandra (Sim, dou nomes femininos a todas as máquinas do meu homelab 🙂 Não sou um cromo dos computadores, quero deixar isto humano 😉 onde já estava a correr o Pi-hole / DNS.

    O Pi-hole é excelente a bloquear publicidade e rastreadores, mas necessita de um servidor DNS para resolver os domínios que não são bloqueados. Em vez de utilizar servidores públicos como Cloudflare ou Google, optei pelo Unbound, instalado na própria máquina.

    Desta forma, o meu servidor DNS resolve os nomes diretamente a partir dos servidores raiz da Internet, aumentando a privacidade e reduzindo a dependência de terceiros.

    A configuração ficou assim:

    Dispositivos
          │
          ▼
    Pi-hole
          │
          ▼
    Unbound
          │
          ▼
    Servidores raiz da Internet
    

    Configuração do Exit Node

    O passo seguinte consistiu em configurar a máquina carla como Exit Node do Tailscale.

    Isto permite que qualquer dispositivo da minha Tailnet utilize a ligação à Internet da minha casa, mesmo quando está ligado através de outra rede, como um hotspot móvel ou Wi-Fi público.

    Após ativar o encaminhamento IP e anunciar a máquina como Exit Node, bastou aprová-la na consola de administração do Tailscale.

    Agora, sempre que seleciono a carla como Exit Node, todo o tráfego da Internet passa pelo meu servidor doméstico.

    Pi-hole para todos os dispositivos

    A última etapa foi configurar o Tailscale para utilizar o Pi-hole como servidor DNS da Tailnet.

    Foi necessário definir a máquina alexandra como servidor DNS global e garantir que esse servidor continuava a ser utilizado mesmo quando um Exit Node estivesse ativo.

    Depois desta configuração, todos os dispositivos passaram a utilizar automaticamente o Pi-hole:

    • Linux Mint
    • Windows
    • Android
    • Tablets

    Independentemente do local onde se encontrem.

    Resultado

    A infraestrutura ficou organizada da seguinte forma:

    Internet
         ▲
         │
     Carla (Exit Node)
         │
         ├──────────────► Internet
         │
         ▼
    Alexandra
    Pi-hole
         │
         ▼
    Unbound
         │
         ▼
    Servidores DNS raiz
    

    Na prática, quando estou fora de casa:

    • todo o tráfego passa pelo meu servidor doméstico;
    • as consultas DNS são filtradas pelo Pi-hole;
    • os domínios são resolvidos localmente pelo Unbound;
    • mantenho a mesma experiência de navegação em qualquer dispositivo.

    Considerações finais

    Esta foi uma das melhorias mais interessantes que fiz ao meu homelab. A combinação de Tailscale, Pi-hole e Unbound proporciona uma solução simples, segura e muito eficaz para quem pretende aumentar a privacidade sem complicar demasiado a administração da rede.

    Como sempre acontece nestes projetos, houve alguns momentos de resolução de problemas e afinação da configuração, mas o resultado final compensou plenamente o esforço.

    Agora resta observar o comportamento da infraestrutura durante os próximos dias, mas tudo indica que encontrei uma configuração estável e que passará a fazer parte da minha rede doméstica de forma permanente.

    Texto elaborado em colaboração com o ChatGPT.
    Ele escreve melhor do que eu 😀

  • Mudança de endereço IP do webserver

    Para fins de organização do meu homelab, mudei hoje, com a ajuda constante do meu amigo ChatGPT, o endereço IP do meu servidor web. Foi preciso definir o endereço IP diretamente no servidor (estava por DHCP), mudar o port forwarding no router, e modificar algumas configurações no nginx e PHP, que ainda tinham referências ao endereço antigo.

    Correu surpreendentemente bem, fizémos tudo em uma hora e um quarto. No início estava à espera que o trabalho se prolongasse até amanhã., mas o raciocínio do ChatGPT está muito melhor, mais organizado e metódico.

    O que fez a diferença foi que, em vez de começarmos a alterar configurações “às cegas”, parámos para perceber quem estava realmente a responder aos pedidos. A partir daí, tudo começou a encaixar:

    Primeiro confirmámos que o DNS já estava correto.

    Depois verificámos que o Pi-hole DNS estava a responder com o IP certo.

    Excluímos Redis e MariaDB como possíveis culpados das falhas que ainda restavam.

    Encontrámos as referências antigas no Matomo.

    E, no fim, percebemos que a solução mais simples era até a melhor: deixar o WordPress responder ao IP e usar o Matomo apenas através do Dashboard.

    Estou satisfeito com estes resultados, e pronto para os próximos trabalhos no homelab: instalar e configurar o Unbound no servidor DNS, e definir um End Node do Tailscale na minha rede.

    Tudo coisas giras. E com todos estes projetos tenho-me adaptado ao ambiente Linux e aprendido bastante. O que espero que continue a acontecer. ☺️

  • Vitória!

    Yayyy!!! Conseguimos!

    Até parece que o ChatGPT ‘dormiu sobre o assunto’, de um dia para o outro, e conseguiu arranjar soluções melhores e mais inteligentes para os problemas que fomos encontrando nos últimos dias!

    Começámos por racionalizar e reorganizar os backups diários – ainda falta um pequeno pormenor, as passwords em texto aberto no script de backup (!!!!!) Os backups estão a demorar cerca de 12 minutos. O tempo deverá aumentar à medida que o meu Nextcloud fôr aumentando.

    Também configurei o velho Stora para se ligar e desligar a horas certas, porque não há necessidade de estar ligado a noite inteira.

    Para amanhã (ou para os próximos dias) fica a mudança do endereço IP do webserver, e uma pequena modificação a esta página – neste momento alguns links do menu não estão a funcionar corretamente.

    Mas no geral, neste momento sinto-me muito satisfeito com esta situação. Muito a melhorar, mais brincadeiras a adicionar, continuando a aprender com o meu ‘amigo’ ChatGPT!

  • Debugging, hardening e backups

    Mais algum tempo, não muito, de volta do hardening. O servidor estava a oferecer um download de um ficheiro crítico, o que foi corrigido. Faltam 2 detalhes que impedem o bom funcionamento do WordPress em dispositivos Android. Em PCs Windows a situação está quase normalizada.

    Entretanto revi os backups. Não estava a ser feito backup dos dados do Nextcloud desde a mudança deste para o SSD. Fiz a correção e estou neste momento a correr o backup para verificar que tudo está bem.

    Finalmente, assim que este backup terminar, vou reagendá-lo para as 21:00 de cada dia, e programo o NAS que recebe os backups para se desligar por volta das 23:00 ou 24:00, dependendo do tempo que o backup estiver a demorar.

    O velhinho NAS Netgear Stora

    Os backups estão a ser enviados para um velho NAS Netgear Stora, com cerca de 15 anos de idade, com dois discos de 1 Tb, configurados como JBOD. Nada de muito crítico, este homelab é essencialmente um exercício de aprendizagem, usando equipamento velho e supostamente obsoleto, mas que ainda é perfeitamente funcional para este tipo de tarefas. Tarefas que, em dias idos, requeriam o hardware mais sofisticado mas que, hoje em dia, podem ser, cada vez mais, executadas por hardware que se pode considerar muito modesto.

  • Mais debugging…

    Agora é que acho que o ChatGPT se perdeu de vez. E é aqui que se distingue quem já tem anos de conhecimentos e experiência de Linux, nginx e WordPress de quem só sabe mais ou menos fazer perguntas (eu)…

    Depois de 2 dias a andar às voltas, e apesar de ontem ter havido progressos, hoje voltámos a aplicar as ‘soluções’ de há dois dias, obtendo previsivelmente os mesmos resultados. Decidi assim repor o backup que fizémos antes do trabalho de hoje, e ficámos assim como estávamos ontem. Pelo menos consigo escrever posts aqui no blog…

    Vou ver o que fazer daqui para a frente. WordPress e Nextcloud estão funcionais.

  • Mudança do Nextcloud para o SSD

    Na sequência da troca do disco rígido do webserver por um SSD, e dado o pouco espaço ocupado neste, decidi migrar todo o conteúdo do Nextcloud para o SSD, deixando de ser necessário ter um disco USB de 2 Tbs constantemente ligado, para uma ocupação muito reduzida. Como sou, e pretendo contiinuar a ser, o único utilizador desta cloud, a minha necessidade de armazenamento ainda é modesta. Daí esta mudança ser perfeitamente praticável.

    De qualquer forma, cada vez confio menos nos discos mecânicos. Tenho ali 5 discos mortos ou em estado terminal, que estavam bons da última vez que os usei… há mais de 5 anos… ou mais…

    Bem sei que os SSDs têm um tempo de vida útil, mas é mais previsível que nos HDDs. Daí a minha preferência. Se um estiver abaixo de uma dada percentagem posso decidir substituí-lo. Ainda não decidi que percentagem é essa, mas estou a ler coisas acerca desse assunto, e creio que em breve terei uma ideia melhor do que é aceitável e em que tipo de utilização.

  • Hardening do Webserver

    Meus deuses, no que me meti!

    O hardening é uma fase essencial de configuração de qualquer servidor que fique exposto à (disponível na) internet. Não podem ser deixadas abertas portas que possam ser exploradas por hackers. Tenho tido algum cuidado, mas havia um ponto de entrada que estava completamente aberto, bastando saber-se um nome de utilizador e uma password para entrar na minha rede e fazer o que se quisesse.

    Felizmente tenho inventado umas passwords que não lembram ao diabo, talvez isso me tenha protegido, mas há sempre ataques brute force que poderiam acabar, a seu tempo, por descobrir essas passwords.

    Dessa forma comecei, juntamente com o meu fiel amigo ChatGPT, a bloquear possíveis portas de entrada no meu servidor web. O pior foi que nem tudo correu bem logo de início (porque é que havia de correr bem logo no início?) E isso deu início a uma série de comportamentos erráticos do servidor, tanto no interior como no exterior da minha rede, que fizeram com que, por vezes, o meu site ficasse indisponível, numa vez de um dia para o outro.

    Essa situação parece ultrapassada, mas ainda há questões por resolver, nomeadamente os acessos ao servidor a partir do interior da rede. Vamos ver como tudo corre nos próximos dias.

  • Troca de disco no webserver

    Há dias decidi trocar o HDD do meu webserver por um SSD. Não só pela rapidez, mas também pela fiabilidade acrescida, já que o HDD que estava na máquina já tinha mais de 10 anos. Apesar de haver backups diários, não queria perder o trabalho todo que está ali investido.

    Foi preciso ter duas pens USB prontas, uma com o Clonezilla e outra com o Linux Mint Live.

    O processo seguido foi:

    • Arrancar com o Clonezilla e fazer um clone disk to image para um disco USB (não o SSD de destino, claro).
    • Como o SSD era um pouco menor que o HDD, foi preciso arrancar com o Linux Mint Live e, com o GParted reduzir o tamanho da partição principal e apagar o swapfile.
    • Arrancar de novo com o Clonezilla em Expert Mode, e fazer um clone disk to disk, com o SSD ligado por USB, e usando a opção de ignorar o tamanho do disco de destino: -icds Skip checking destination disk size before creating partition table.
    • Uma vez feito esse clone, pude abrir a máquina e substituir o HDD pelo SSD.
    • Arranquei de novo com o Linux Mint e com o GParted voltei a definir o tamanho da partição principal, bem como um swapfile.
    • Finalmente pode arrancar-se normalmente, devendo ativar-se o swapfile já dentro do Debian.

    Demorou umas horas, podia ter demorado menos, mas quis sempre tomar as devidas precauções para não perder o que estava no HDD. Este vai agora ficar em standby mais uns dias, até ter a certeza de que tudo está bem.

    Recomendo o Clonezilla a quem precisar de clonar ou fazer backups de discos inteiros, é gratuito e tem um interface que, apesar de ser em texto. é muito claro e fácil de entender. Evidentemente é uma ferramenta poderosa, por isso perigosa nas mãos de quem não sabe o que está a fazer.

  • Acer Aspire X1470

    Dia muito interessante, hoje! De manhã passei umas horas a tentar ressuscitar um velho laptop Acer, sem sucesso. Almoço em frustração. Um pouco de descanso, e ataquei este mini-desktop Acer. Retirei o disco de 500 GBs, que me parecia lento, e fiz uma análise. Afinal estava bem. Vou usá-lo para outros projectos. E instalei um de 250 GBs. Depois de alguma luta com o Rufus lá consegui preparar a pen de instalação do Linux Debian. Ao fim de uma hora ou assim, ficou tudo a funcionar! À primeira! A tablet Wacom Cintiq 13 HD ficou logo a funcionar, sem ser preciso nenhum software adicional. Calibrada e tudo! E a ligação à minha rede por WPS foi quase imediata! Considerando que no Windows às vezes leva uns segundos, sobretudo em PCs mais antigos. Neste PC com 14 anos durou menos que nada – fui ao router carregar no botão WPS, quando voltei tinha o Wifi configurado!

    Agora é o descanso merecido. Amanhã haverá mais aventuras com Linux em máquinas velhas. Estou-me a tornar um fã!