Where Free Software Meets Free Infrastructure
A community-powered Linux distribution mirror with fully transparent operations - featuring open-source management, public metrics, and CI/CD deployment. Proudly hosted at the Federal University of São Carlos in partnership with PATOS and GELOS.
🌐 Mirror URL: https://mirror.ufscar.br
This mirror is maintained through the joint effort of:
Join our communities to contribute to free software infrastructure!
- Operating System: NixOS for reproducible, declarative infrastructure
- Hardware: Physical server hosted at UFSCar's datacenter
- Location: Secretaria Geral de Informática building, São Carlos
- Connectivity: See https://bgp.tools/as/52888
- Management: Fully automated via GitHub CI/CD
- Transparency: All configuration and management code is public
We believe in operational transparency:
Track real-time performance including:
- CPU/RAM usage & I/O wait
- Network traffic (packets/s, errors)
- Nginx connections & HTTP requests
- Disk usage/latency with future projections
- Storage read/write operations
Receive immediate notifications for system events
- Source Code: PATOS/mirror-monitoring
- Deployment: Automated CI/CD to Google CloudRun
We welcome community contributions!
- Submit pull requests for mirror configuration
- Improve monitoring in PATOS/mirror-monitoring
- Join PATOS/GELOS meetings
- Suggest new metrics or visualizations
Execute nix run .#deploy na raiz do repositório. Para usar outra conta SSH,
execute nix run .#deploy -- matias@mirror.ufscar.br. O destino precisa permitir
sudo -n; a configuração SSH deve disponibilizar o túnel wstunnel, como no CI.
O Nix compila o sistema e o worker antes de iniciar a implantação. O cliente
copia os resultados e inicia uma unidade mirror-deploy-<identificador> no
systemd do servidor, com logs no journal. O worker serializa as implantações,
protege as duas configurações contra coleta de lixo e executa a ativação.
Ele verifica nginx, Syncthing, Datadog e rsync, incluindo a API do Syncthing.
O cliente reconecta por SSH e confirma a transação somente após essas verificações.
Se a ativação falhar ou a confirmação não chegar em 120 segundos após a verificação de saúde, o worker reativa a configuração anterior e verifica os serviços novamente. A queda do túnel ou o cancelamento do CI não interrompe esse processo. Falhas de tarefas periódicas continuam sendo reportadas pela ativação; elas não são convertidas silenciosamente em sucesso.
O cliente imprime o nome da unidade e o diretório da transação. Para diagnosticar:
sudo journalctl -u mirror-deploy-<identificador>
sudo cat /run/mirror-deploy/<identificador>/statusOs estados finais são committed, rolled-back e rollback-failed. Nos dois
últimos casos, o cliente retorna erro. Se ele perder acesso ao servidor, o estado
remoto é a referência; não inicie outra implantação antes de verificá-lo.
O limite de espera do cliente é 65 minutos e não encerra a unidade remota.
Uma transação travada durante a própria ativação exige diagnóstico pelo journal;
o prazo de confirmação começa depois da ativação, não limita sua duração.
- Free Software: We mirror only Free Software distributions
- Free Infrastructure: Entire stack is Free Software
- Free Access: Public metrics and management
- Free Community: Jointly maintained with PATOS & GELOS
