Soporte para FQDN #76

Merged
Numerica merged 26 commits from issue42 into master 2025-12-16 15:00:07 +00:00
Owner

Closes #42

Closes #42
Numerica added 3 commits 2025-11-25 17:40:01 +00:00
debido a que para este hay que arreglar la obtencion de certificados de DNS externos,
es necesario en HTTP (80) pasar la variable  a proxy_ssl_name ya que  viene vacia y esto
genera el error 500 responde tlsv1 unrecognized name (alert 112)
Añade soporte completo para usar dominios FQDN externos (ejemplo.com,
kipu.latina.red, etc.) además de subdominios .abyaya.la.

Cambios principales:
- Generación automática de subdominio .abyaya.la como alias
- Detección automática de TLDs compuestos (.com.ar, .co.uk, etc.)
- Actualización DNS multi-zona en Knot
- Procesamiento de múltiples dominios por servicio
- Certificados SSL para todos los dominios + wildcards

La detección de tipo de dominio (FQDN vs subdominio) es completamente
automática basada en el sufijo .abyaya.la.

Ver FQDN_AUTHORITATIVE.md para documentación completa.
Numerica added 1 commit 2025-11-25 17:58:07 +00:00
Numerica requested review from fauno 2025-11-27 13:27:57 +00:00
Numerica added the
testear
label 2025-11-27 13:28:09 +00:00
fauno requested changes 2025-11-27 14:08:29 +00:00
fauno left a comment
Owner

me parece que te complicaste la vida @Numerica jaja

me parece que te complicaste la vida @Numerica jaja
@ -0,0 +66,4 @@
domains:
- miapp.com.ar
- miapp.latina.red
- miapp.abyaya.la
Owner

creo que es confuso en la documentación decir que el dominio HUERTA.abyaya.la es automático y luego usar de ejemplo un subdominio de abyaya.la específico. creo que tendríamos que dejar los subdominios de abyaya.la reservados solo para huertas

creo que es confuso en la documentación decir que el dominio HUERTA.abyaya.la es automático y luego usar de ejemplo un subdominio de abyaya.la específico. creo que tendríamos que dejar los subdominios de abyaya.la reservados solo para huertas
Author
Owner

Ah ok, aunque esa documentación es interna para nos, la eliminaremos en el merge

Los dominios* son para huertas, de hecho son el default, es opcional mencionarlos para retrocompatibilidad. en realidad ahora domains: servirá más para agregar dominios fqdn

Ah ok, aunque esa documentación es interna para nos, la eliminaremos en el merge Los dominios* son para huertas, de hecho son el default, es opcional mencionarlos para retrocompatibilidad. en realidad ahora domains: servirá más para agregar dominios fqdn
fauno marked this conversation as resolved
@ -0,0 +104,4 @@
Certbot obtiene certificados para **todos** los dominios listados más sus wildcards:
```bash
certbot certonly -d ejemplo.com.ar -d *.ejemplo.com.ar -d ejemplo.abyaya.la -d *.ejemplo.abyaya.la
Owner

no veo dónde sucede esto, ya lo hacía certbot? me preocupa en términos de privacidad hacer público que dos o más dominios están relacionados con la misma huerta, y que certbot haga cualquiera cuando agreguemos un dominio más. haría que certbot genere un certificado para cada dominio. si eso es muy complicado, usaría la flag --expand para aclarar que queres que se agreguen dominios a un certificado que ya existía. sino creo que hace la gilada esa de poner -0001 al final del archivo

no veo dónde sucede esto, ya lo hacía certbot? me preocupa en términos de privacidad hacer público que dos o más dominios están relacionados con la misma huerta, y que certbot haga cualquiera cuando agreguemos un dominio más. haría que certbot genere un certificado para cada dominio. si eso es muy complicado, usaría la flag `--expand` para aclarar que queres que se agreguen dominios a un certificado que ya existía. sino creo que hace la gilada esa de poner -0001 al final del archivo
Owner

en el primer caso, hay que generar un archivo de configuración de nginx por cada dominio o hacer que el certificado se cargue desde la variable $ssl_server_name

en el primer caso, hay que generar un archivo de configuración de nginx por cada dominio o hacer que el certificado se cargue desde la variable `$ssl_server_name`
Author
Owner

interesante..

  • si, ya lo hacía certbot, estaba comentando desde que cambiamos a standalone. lo deja en un cron
  • si, toma para todos los dominios. efectivamente es un problema cuando agregamos posteriormente dominios (en mi experiencia en Numérica). si lo podemos resolver con --expand creo que sería fácil y limpio, es lo que estamos haciendo.
  • dominios independiente resolverían el tema que planteas de privacidad, lo evaluaremos
interesante.. - si, ya lo hacía certbot, estaba comentando desde que cambiamos a standalone. lo deja en un cron - si, toma para todos los dominios. efectivamente es un problema cuando agregamos posteriormente dominios (en mi experiencia en Numérica). si lo podemos resolver con --expand creo que sería fácil y limpio, es lo que estamos haciendo. - dominios independiente resolverían el tema que planteas de privacidad, lo evaluaremos
Owner

ok le agregás el --expand por ahora?

ok le agregás el --expand por ahora?
Numerica marked this conversation as resolved
@ -0,0 +107,4 @@
certbot certonly -d ejemplo.com.ar -d *.ejemplo.com.ar -d ejemplo.abyaya.la -d *.ejemplo.abyaya.la
```
Usa el método `dns-standalone` que requiere que el proxy controle el DNS autoritativo. Esto funciona porque knsupdate actualiza Knot con todos los dominios.
Owner

guarda que esto implica que haya un subdominio _acme-challenge para todos los dominios solicitados

guarda que esto implica que haya un subdominio `_acme-challenge` para todos los dominios solicitados
Author
Owner

si, se estarían agregando más abajo en knsupdate

si, se estarían agregando más abajo en knsupdate
Numerica marked this conversation as resolved
@ -3,2 +3,2 @@
zone abyaya.la.
origin abyaya.la.
zone {{ zone }}
origin {{ zone }}
Owner

no habria que agregar el punto al final?

no habria que agregar el punto al final?
Owner

ah, el punto se lo agrega la extracción de la zona

ah, el punto se lo agrega la extracción de la zona
Numerica marked this conversation as resolved
@ -12,0 +13,4 @@
add *.{{ domain }} a {{ host_ip }}
{% endif %}
add _acme-challenge.{{ hostname }} a {{ host_ip }}
add _acme-challenge.{{ hostname }} ns _acme-challenge
Owner

ok, todo esto asume que todos los dominios estan gestionados por el mismo dns, cierto?

ok, todo esto asume que todos los dominios estan gestionados por el mismo dns, cierto?
Author
Owner

si, por ej el dominio kipu.latina.red lo delegué, puede hacerle

dig kipu.latina.red NS
dig kipu.latina.red CNAME

mas, relacionado a esto quizas falte arreglar algo, que crea estar publicando estos registros en knsupdate tambien? en realidad debe escupirlos como una instruccion: "Copia esto en tu servidor DNS"

si, por ej el dominio kipu.latina.red lo delegué, puede hacerle ``` dig kipu.latina.red NS dig kipu.latina.red CNAME ``` mas, relacionado a esto quizas falte arreglar algo, que crea estar publicando estos registros en knsupdate tambien? en realidad debe escupirlos como una instruccion: "Copia esto en tu servidor DNS"
Owner

a donde lo delegaste? lo que digo es que la delegación y el knsupdate a los knot de sutty solo es necesaria para HUERTA.abyaya.la, pero no para otros dominios

a donde lo delegaste? lo que digo es que la delegación y el knsupdate a los knot de sutty solo es necesaria para HUERTA.abyaya.la, pero no para otros dominios
Numerica marked this conversation as resolved
@ -0,0 +28,4 @@
set_fact:
zone: "{{ domain_parts[-2:] | join('.') }}."
hostname: "{{ domain_parts[:-2] | join('.') if domain_parts | length > 2 else '@' }}"
when: not is_abyayala_subdomain and not uses_compound_tld
Owner

no entiendo para qué hacer todo esto, si le paso un dominio sutty.coop.ar o sutty.nl va a pensar que la zona es .coop.ar. y .nl.?

no entiendo para qué hacer todo esto, si le paso un dominio `sutty.coop.ar` o `sutty.nl` va a pensar que la zona es `.coop.ar.` y `.nl.`?
Owner

o entiendo que pasandolo por la lista compound_tlds obtiene que la zona es sutty.coop.ar siempre y cuando .coop.ar esté incluido en compound_tlds?

o entiendo que pasandolo por la lista `compound_tlds` obtiene que la zona es `sutty.coop.ar` siempre y cuando `.coop.ar` esté incluido en `compound_tlds`?
Owner

en cualquier caso me parece raro tener que hacer todo esto, porque...

  • no podemos asumir que el dominio es la zona? entonces el fqdn sutty.coop.ar es una zona en knot que ya acepta actualizaciones desde el proxy.
  • en el caso de huerta.abyaya.la, ya sabemos que la zona es abyaya.la.
  • con eso, no haría falta tener una lista de tlds admitidos (tarea extra, confusión frente a dominios nuevos, configuraciones potencialmente rotas)
  • de hecho, los dominios externos no necesitan knot para nada, porque esa configuración se puede hacer estáticamente. usamos knot para dar de alta huertas automáticamente, pero un dominio nuevo se configura una sola vez y ya.
en cualquier caso me parece raro tener que hacer todo esto, porque... * no podemos asumir que el dominio es la zona? entonces el fqdn `sutty.coop.ar` es una zona en knot que ya acepta actualizaciones desde el proxy. * en el caso de `huerta.abyaya.la`, ya sabemos que la zona es `abyaya.la`. * con eso, no haría falta tener una lista de tlds admitidos (tarea extra, confusión frente a dominios nuevos, configuraciones potencialmente rotas) * de hecho, los dominios externos no necesitan knot para nada, porque esa configuración se puede hacer estáticamente. usamos knot para dar de alta huertas automáticamente, pero un dominio nuevo se configura una sola vez y ya.
Author
Owner

la idea aqui era soportar fqdn que puedan ser compuestos, previendo que pasará con nuevaradio.org.ar y así

está bien que esto no pase por knsupdate, pero es soporte para estos dominios a lo largo del código (las regex cachan si es fqdn o compuesto y ajustan las variables acorde)

la idea aqui era soportar fqdn que puedan ser compuestos, previendo que pasará con __nuevaradio.org.ar__ y así está bien que esto no pase por knsupdate, pero es soporte para estos dominios a lo largo del código (las regex cachan si es fqdn o compuesto y ajustan las variables acorde)
Owner

entonces no entiendo la diferenciación que hacés entre fqdn y compuesto. para mi fqdn es cualquier dominio completo incluyendo (g)tld. sutty.comun es un fqdn, porque es un hostname dentro de un dominio, aunque su resolución no sea por dns publico.

la pregunta es por qué es necesario hacer todo esto si no es necesario hacer knsupdate para estos dominios

entonces no entiendo la diferenciación que hacés entre fqdn y compuesto. para mi fqdn es cualquier dominio completo incluyendo (g)tld. `sutty.comun` es un fqdn, porque es un hostname dentro de un dominio, aunque su resolución no sea por dns publico. la pregunta es por qué es necesario hacer todo esto si no es necesario hacer knsupdate para estos dominios
Author
Owner

si. yo estoy mal con la nomenlclatura. me rediero a dominios externos (.org .com ...)

si. yo estoy mal con la nomenlclatura. me rediero a dominios externos (.org .com ...)
@ -6,0 +11,4 @@
- com.br
- gov.ar
- org.ar
- gob.ar
Owner

miedo

miedo
Author
Owner

fue la pinche IA

fue la pinche IA
Numerica marked this conversation as resolved
@ -6,0 +13,4 @@
- org.ar
- gob.ar
- net.ar
- mil.ar
Owner

horror

horror
fauno marked this conversation as resolved
@ -6,0 +14,4 @@
- gob.ar
- net.ar
- mil.ar
- edu.ar
Owner

bueno jaja

bueno jaja
Author
Owner

jaja estos los habia eliminado justamente. edu puede ser

jaja estos los habia eliminado justamente. edu puede ser
fauno marked this conversation as resolved
@ -45,6 +45,21 @@
loop_control:
loop_var: domino
- name: add default abyaya.la subdomain if not present
Owner

me pregunto si es necesario agregar todo esto en vez de documentar y hacer explicito que hay que listar todos los dominios de una huerta

me pregunto si es necesario agregar todo esto en vez de documentar y hacer explicito que hay que listar todos los dominios de una huerta
Author
Owner

bueno digamos que ya está hecho y simplifica. tambien es retro-compatible entonces podes dejarlos si querés

de hecho hice otra rama para unificar la definicio de nodo (que ahora siempre repetimos 3 veces llamandole igual 99.9% de las veces NODO.comun NODO.abayaya.la service_name: nodo, se reducen a una sola variable nodo #80

bueno digamos que ya está hecho y simplifica. tambien es retro-compatible entonces podes dejarlos si querés de hecho hice otra rama para unificar la definicio de nodo (que ahora siempre repetimos 3 veces llamandole igual 99.9% de las veces NODO.comun NODO.abayaya.la service_name: nodo, se reducen a una sola variable nodo #80
fauno marked this conversation as resolved
@ -16,3 +16,3 @@
proxy_ssl_verify off;
proxy_ssl_server_name on;
proxy_ssl_name $ssl_server_name;
proxy_ssl_name $host;
Owner

por que esto?

por que esto?
Author
Owner

Esto si que me dejó cachudo

Esto si que me dejó cachudo
Author
Owner

Esto responde la autora
Respuesta final: Usar $host en issue42 probablemente está mal o es temporal. Debería ser:

  • $ssl_server_name (original) - Funciona si solo hay .abyaya.la
  • O mejor: una variable que mapee al dominio del backend correcto
    Pero como proxy_ssl_verify off (línea 16), el proxy NO verifica certificados del backend, así que da igual qué
    SNI envíe.
    ya está reviertiendo tu errorcito
Esto responde la autora Respuesta final: Usar $host en issue42 probablemente está mal o es temporal. Debería ser: - $ssl_server_name (original) - Funciona si solo hay .abyaya.la - O mejor: una variable que mapee al dominio del backend correcto Pero como proxy_ssl_verify off (línea 16), el proxy NO verifica certificados del backend, así que da igual qué SNI envíe. ya está reviertiendo tu errorcito
Owner

no entendí

no entendí
Author
Owner

que ya se revirtió esto

que ya se revirtió esto
Numerica marked this conversation as resolved
@ -6,3 +6,3 @@
listen {{ vhost.ports[0] }};
server_name .{{ vhost.domains | join(' .') }};
server_name {{ vhost.service_name }}.abyaya.la;
Owner

me da miedo que estemos hardcodeando .abyaya.la por todos lados

me da miedo que estemos hardcodeando `.abyaya.la` por todos lados
Owner

ademas al eliminar el . atrás del dominio en nginx dejamos de servir los subdominios

ademas al eliminar el . atrás del dominio en nginx dejamos de servir los subdominios
Author
Owner

Ah pero esto es en el proxy SSH, entonces quedaría habilitado sólo en el dominio default, que siempre está disponible

ssh huerta.abyaya.la -p 3333

Es una propuesta igual. Quedaría fancy usar el fqdn tambien, cuando esta disponible, se puede evaluar

Ah pero esto es en el proxy SSH, entonces quedaría habilitado sólo en el dominio default, que siempre está disponible ``` ssh huerta.abyaya.la -p 3333 ``` Es una propuesta igual. Quedaría fancy usar el fqdn tambien, cuando esta disponible, se puede evaluar
fauno marked this conversation as resolved
Numerica requested review from fauno 2025-11-27 16:16:28 +00:00
Author
Owner

Esto significa que knsupdate no tiene autorización para actualizar la zona DNS abyaya.la.
Causa: Falta la configuración de autenticación (TSIG key) para Knot DNS. O El servidor DNS debe confiar en la IP del host
Creo que es el segundo lo caso, lo tiene que autorizar Sutty

Esto significa que knsupdate no tiene autorización para actualizar la zona DNS abyaya.la. Causa: Falta la configuración de autenticación (TSIG key) para Knot DNS. O El servidor DNS debe confiar en la IP del host Creo que es el segundo lo caso, lo tiene que autorizar Sutty
Numerica added the
no pasó el test
label 2025-12-01 17:41:39 +00:00
Numerica added 2 commits 2025-12-01 19:02:18 +00:00
y le saco el no a ssl para otra cosa
El uso de $host en lugar de $ssl_server_name no es correcto ya que:
- proxy_ssl_verify está deshabilitado, por lo que el SNI no importa
- $ssl_server_name es el valor correcto para SNI en proxies SSL
- $host causaba confusión innecesaria

Revierte a la configuración estándar y correcta.
Owner

Esto significa que knsupdate no tiene autorización para actualizar la zona DNS abyaya.la.
Causa: Falta la configuración de autenticación (TSIG key) para Knot DNS. O El servidor DNS debe confiar en la IP del host
Creo que es el segundo lo caso, lo tiene que autorizar Sutty

esto es corriendo en el servidor de testing o de producción? el servidor de testing no tiene permiso para modificar los registros del servidor de produccion

> Esto significa que knsupdate no tiene autorización para actualizar la zona DNS abyaya.la. > Causa: Falta la configuración de autenticación (TSIG key) para Knot DNS. O El servidor DNS debe confiar en la IP del host > Creo que es el segundo lo caso, lo tiene que autorizar Sutty esto es corriendo en el servidor de testing o de producción? el servidor de testing no tiene permiso para modificar los registros del servidor de produccion
Numerica added 1 commit 2025-12-02 20:44:58 +00:00
Author
Owner

Lo mismo, hay que decidir cómo delegamos los DNS

Lo mismo, hay que decidir cómo delegamos los DNS
Numerica added 1 commit 2025-12-02 22:16:51 +00:00
Modifica la lógica para garantizar que el dominio .abyaya.la siempre
sea el primero en la lista de dominios, independientemente del orden
definido en abyayala.yml. Esto es crítico para certificados SSL y
configuraciones vhost que dependen de domains[0].
fauno added 1 commit 2025-12-06 15:09:25 +00:00
Owner

@Numerica necesito saber cómo estás corriendo ansible para poder reproducir

@Numerica necesito saber cómo estás corriendo ansible para poder reproducir
Owner

te decía ayer que en https://0xacab.org/sutty/suttyns.git puedo hacer que para un dominio proxeado siempre responda la ip del proxy aunque el dominio no exista, se compartaría como esto:

sutty.abyaya.la. A 5.161.236.18
verdura.sutty.abyaya.la. A 5.161.236.18
_acme-challenge.sutty.abyaya.la A 5.161.236.18

o sea que resolvería *.abyaya.la. y *.*.abyaya.la. sacandonos de encima la necesidad de correr knsupdate.

para los dominios que no estén delegados al dns de sutty, podemos asumir que el dominio, los subdominios que apuntan a servicios y el _acme-challenge están delegados como corresponde.

te decía ayer que en https://0xacab.org/sutty/suttyns.git puedo hacer que para un dominio proxeado siempre responda la ip del proxy aunque el dominio no exista, se compartaría como esto: ``` sutty.abyaya.la. A 5.161.236.18 verdura.sutty.abyaya.la. A 5.161.236.18 _acme-challenge.sutty.abyaya.la A 5.161.236.18 ``` o sea que resolvería `*.abyaya.la.` y `*.*.abyaya.la.` sacandonos de encima la necesidad de correr `knsupdate`. para los dominios que no estén delegados al dns de sutty, podemos asumir que el dominio, los subdominios que apuntan a servicios y el `_acme-challenge` están delegados como corresponde.
Numerica added 14 commits 2025-12-15 22:56:10 +00:00
roles/knsupdate/files/dns_extras
Soluciona conflicto APT causado por configuraciones de repositorio Docker
duplicadas con valores Signed-By contradictorios. Ahora se eliminan los
archivos de repositorio antiguos antes de agregar la configuración deb822.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
La limpieza de repositorios Docker antiguos debe ejecutarse SIEMPRE,
incluso cuando se usa --skip-tags=installation, para evitar conflictos
APT antes de que knsupdate u otros roles intenten usar apt.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Ansible requiere que las condicionales resulten en booleanos.
Agregado filtro | bool para convertir explícitamente strings a booleanos
en las evaluaciones de needs_cert, needs_vhost y obtain_cert.
Aplicar | bool al resultado final de cada expresión y envolver
en sintaxis {{ }} para forzar evaluación correcta como booleanos.
En Ansible 2.15+ las variables en el mismo set_fact se evalúan
simultáneamente, no secuencialmente. Separar needs_cert en su propio
set_fact antes de usarlo en needs_vhost y obtain_cert.
Add capability to route root domain (abyaya.la and www.abyaya.la)
to sutty.comun while maintaining all existing subdomain routes.

Changes:
- Add no_wildcard flag support in certbot certificate generation
- Split certificate obtention into two conditional paths:
  * Standard mode (with wildcard) for subdomains
  * No-wildcard mode for root domains
- Add abyaya_root service in matrix routing to sutty.comun
- Include implementation plan as README-root-domain.md

Technical details:
- Certificates for root domain will only include abyaya.la and
  www.abyaya.la (no *.abyaya.la wildcard)
- Prevents certificate confusion between root and subdomains
- Maintains clean separation of responsibilities
- All existing subdomain certificates remain unchanged

Generated with Claude Code
Rename the flag from `no_wildcard` to `root` throughout the codebase
for better semantics, and fix nginx configuration generation for root
domains.

Changes:
1. Renamed `no_wildcard` → `root` flag in:
   - abyayala.yml (abyaya_root service)
   - roles/certbot/tasks/certbot.yml (uses is_root_domain internally)
   - README-root-domain.md (documentation)

2. Fixed nginx vhost generation in roles/proxy/templates/:
   - vhost.conf: Handle root domains without leading dot in server_name
     * root: yes → `server_name abyaya.la www.abyaya.la;` (exact match)
     * root: no  → `server_name .comun.abyaya.la;` (wildcard match)
   - stream.conf: Same logic for SSH proxy streams

Problem fixed:
- Previous: `.abyaya.la` matched all subdomains, conflicting with
  other vhosts (comun.abyaya.la, sutty.abyaya.la, etc.)
- Now: `abyaya.la www.abyaya.la` matches only root domain exactly

🤖 Generated with Claude Code

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Replace dns-standalone with HTTP-01 webroot validation for root domains
(when root: yes flag is set). This change improves reliability by avoiding
DNS conflicts and simplifies the certificate obtention process.

Changes:
- Add acme_challenge.conf to serve .well-known/acme-challenge directory
- Update certbot.yml to use --webroot for root domains instead of dns-standalone
- Use official certbot/certbot:latest image for webroot (lighter, no DNS needed)
- Add certbot_webroot volume shared between nginx and certbot containers
- Configure vhost.conf to include ACME challenge location for root domains
- Add certbot_webroot variable (/var/www/certbot) to proxy vars

Benefits for root domains:
- No port 53 conflicts with Knot DNS
- Faster validation (HTTP vs DNS propagation)
- More reliable and simpler error handling
- Works with nginx already running on port 80

Wildcard domains continue using DNS-01 challenge as HTTP-01 does not
support wildcard certificates.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Author
Owner

Testeando en prod con kipu.latina.red ...
No está autorizada latina.red en Knot?

Testeando en prod con kipu.latina.red ... No está autorizada latina.red en Knot?
Numerica removed the
no pasó el test
testear
labels 2025-12-16 03:15:22 +00:00
Author
Owner

Testeado
Notese que tuve que saltearme esta restriccion porque kipu.abyaya.la ya habia existido, ahora tiene --expand, pero aqui se lo salta cuando va a expandir

     - set_fact:
         needs_vhost: "{{ (needs_cert | bool and not vhost_stat.stat.exists) | bool }}"
-        obtain_cert: "{{ (needs_cert | bool and not ssl_cert.stat.exists) | bool }}"
+        obtain_cert: "{{ needs_cert | bool }}"
 

Tambien tuve que saltearme Knsupdate asi

ansible-playbook deploy.yml -D -e "alt=abyayala host=hetzner service=kipu" --skip-tags=installation,knot

Y puse los registros DNS directo en el Bind9 de latina.red

; ABYAYA.LA
kipu    IN A 5.161.236.18
*.kipu    IN A 5.161.236.18

_acme-challenge.kipu IN NS ns-acme.kipu.latina.red.
ns-acme.kipu IN A 5.161.236.18
Testeado Notese que tuve que saltearme esta restriccion porque kipu.abyaya.la ya habia existido, ahora tiene --expand, pero aqui se lo salta cuando va a expandir ``` - set_fact: needs_vhost: "{{ (needs_cert | bool and not vhost_stat.stat.exists) | bool }}" - obtain_cert: "{{ (needs_cert | bool and not ssl_cert.stat.exists) | bool }}" + obtain_cert: "{{ needs_cert | bool }}" ``` Tambien tuve que saltearme Knsupdate asi ``` ansible-playbook deploy.yml -D -e "alt=abyayala host=hetzner service=kipu" --skip-tags=installation,knot ``` Y puse los registros DNS directo en el Bind9 de latina.red ``` ; ABYAYA.LA kipu IN A 5.161.236.18 *.kipu IN A 5.161.236.18 _acme-challenge.kipu IN NS ns-acme.kipu.latina.red. ns-acme.kipu IN A 5.161.236.18 ```
Numerica referenced this issue from a commit 2025-12-16 03:46:35 +00:00
Numerica added 3 commits 2025-12-16 03:46:35 +00:00
en la amtriz testeando en prod
- knsupdate now only executes when is_abyayala_subdomain is true
- For external domains, display DNS configuration instructions in console
- Created dns_info.j2 template to show required DNS records for manual configuration
- External domains now show: A records, wildcard A records, and ACME challenge NS delegation

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
closes #76
Author
Owner

Me meti al abra local de kipu y habian dos traefik, para kipu.abyaya.la y para kipu.latina.red, undeployé ambos y redeployé el último (en modo Chaos, no sé por qué esto es necesario)

Funcionando: https://traefik.kipu.latina.red/dashboard/

Con esto puedo confirmar que el soporte para FQDN está funcionando

Pero, cómo configurar traefik para que responda a ambos dominios?

Me meti al abra local de kipu y habian dos traefik, para kipu.abyaya.la y para kipu.latina.red, undeployé ambos y redeployé el último (en modo Chaos, no sé por qué esto es necesario) Funcionando: https://traefik.kipu.latina.red/dashboard/ Con esto puedo confirmar que el soporte para FQDN está funcionando Pero, cómo configurar traefik para que responda a ambos dominios?
Numerica closed this pull request 2025-12-16 14:57:58 +00:00
Numerica reopened this pull request 2025-12-16 14:59:50 +00:00
Numerica merged commit 090c397e24 into master 2025-12-16 15:00:07 +00:00
Sign in to join this conversation.
No description provided.