kubernetes/repo

Repositorio Privado openSUSE

Este despliegue en Kubernetes crea un mirror interno de repositorios de openSUSE (y de terceros opcionales, como NVIDIA o Kubernetes). Sirve para que los servidores de nuestra red se actualicen desde dentro, sin depender de internet.

El sistema funciona con:

• Servidor HTTP/HTTPS → los clientes SUSE acceden vía http://repo.c2et.net/... o https://repo.c2et.net/... para descargar paquetes y metadatos.
• Servidor Samba (SMB) → expone la misma carpeta por red. Esto nos permite que el “diodo de datos” copie los repos de manera unidireccional hacia la red clasificada. Así aseguramos que las máquinas en la red sensible reciben actualizaciones sin conectividad exterior.

La carpeta de repos se actualiza automáticamente cada día mediante un CronJob, que sincroniza contra los repos oficiales de openSUSE y de terceros.

---

Cómo desplegarlo

1. Ajusta dominio en el Ingress y (si quieres) IP fija en el Service de Samba.
2. Revisa tamaño de PVC (mínimo 300 GB recomendado).
3. (Opcional) Cambia o amplía la lista en sources.txt (por ejemplo, usando mirrors con rsync://).
4. Despliega todo de una vez con Kustomize:

kubectl apply -k repo/

(Si prefieres, aún puedes aplicar los manifiestos uno por uno en el orden indicado en la carpeta repo/.)

5. Para lanzar una sincronización inicial manual (sin esperar al cron):

kubectl create job --from=cronjob/repo-sync repo-sync-now -n repo
kubectl logs -f job/repo-sync-now -n repo

---

Configuración en los clientes SUSE

En los clientes no hace falta configurar repos manualmente. Basta con ejecutar el script de cliente incluido en este repo (configure-local-repos.sh). Este script:

• Importa las claves GPG desde http://repo.c2et.net/keys/.
• Crea los .repo apuntando al mirror interno.
• Deshabilita los repos externos para que solo se usen los -local.

Uso del script en el cliente

chmod +x configure-local-repos.sh
sudo ./configure-local-repos.sh

Esto deja el sistema listo para trabajar solo con los repos locales.

---

Ventajas de esta arquitectura

• Seguridad: los clientes nunca salen a internet, solo acceden al repo interno.
• Control: el mirror se actualiza de forma programada (p. ej. de madrugada). Siempre sabemos qué versiones están disponibles.
• Simplicidad: los clientes usan HTTP/HTTPS estándar; el Ingress se encarga del TLS si hace falta.
• Integración con el diodo: gracias a Samba, la carpeta puede replicarse unidireccionalmente hacia la red clasificada.
• Verificación: zypper siempre valida las firmas GPG de los paquetes, aunque se distribuyan por HTTP.

---

Sugerencias y mejoras

• Usar mirrors oficiales con rsync para ahorrar ancho de banda y tiempo de sincronización.
• Añadir --bwlimit en el sync.sh si queremos limitar consumo nocturno de ancho de banda.
• Sustituir httpd por nginx si se busca mayor rendimiento en descargas masivas.
• Proteger el Ingress con autenticación si se expone fuera de la red de confianza.
• Mantener el script de cliente actualizado para simplificar el alta de repos en todos los servidores SUSE.