# Hacer `entrypoint.sh` agnóstico de UID/GID (soporte `HOST_UID`/`HOST_GID`)

## Fix post-implementación: resync espurio con GID 0

**Síntoma observado:** al correr el contenedor aparece, repetido muchas veces,
`groupmod: GID '0' already exists`, además de la advertencia normal de
`adduser` sobre que el home dir ya existe.

**Causa raíz:** `entrypoint.sh` se re-ejecuta más de una vez en el ciclo de
arranque (el propio script hace `exec sudo -u $HOME_USER bash -c "...
/usr/bin/entrypoint.sh"` para re-lanzarse como el usuario destino, y además el
contenedor puede reiniciar el entrypoint). En cada ejecución se vuelve a
calcular `DETECTED_UID`/`DETECTED_GID` con `stat` sobre `/home/${HOME_USER}`.
En este entorno (bind mount vía WSL2/Docker Desktop), el `stat` del volumen
reporta GID `0` (root) — es un artefacto de metadata del mount, no el GID real
del usuario del host. Como la rama de "usuario ya existe" recalcula
`TARGET_GID` de la misma manera que la de creación, en cada re-arranque
posterior a la creación intenta `groupmod -g 0 aleleba`, lo cual falla siempre
porque el GID 0 ya pertenece a `root`.

**Fix acordado con el usuario:** para un usuario que **ya existe**, solo se
resincroniza UID/GID si `HOST_UID`/`HOST_GID` vienen seteados **explícitamente**
por variable de entorno. La auto-detección vía `stat` del volumen montado se
usa **únicamente** en la rama de creación de un usuario nuevo (para heredar la
propiedad de un home pre-existente), no en cada reinicio de un usuario que ya
existe. Además, se descarta cualquier UID/GID detectado que sea `0` (root)
como no confiable, cayendo al default `1000` en ese caso, tanto en creación
como al calcular el target explícito.

Esto preserva el caso de uso principal (`HOST_UID=502 HOST_GID=502` fija el
usuario a 502:502 tanto en la creación como en reinicios posteriores, sin
error) y elimina el crash cuando no se pasa override y el mount reporta
metadata espuria.

### Cambios concretos sobre el bloque ya implementado

1. Guardar contra UID/GID `0` al calcular `DETECTED_UID`/`DETECTED_GID` (cerca
   de la línea 10-13 actual de `entrypoint.sh`):
   ```bash
   DETECTED_UID=$(stat -c '%u' "/home/${HOME_USER}" 2>/dev/null || echo 1000)
   DETECTED_GID=$(stat -c '%g' "/home/${HOME_USER}" 2>/dev/null || echo 1000)
   [ "$DETECTED_UID" = "0" ] && DETECTED_UID=1000
   [ "$DETECTED_GID" = "0" ] && DETECTED_GID=1000
   TARGET_UID="${HOST_UID:-$DETECTED_UID}"
   TARGET_GID="${HOST_GID:-$DETECTED_GID}"
   ```
   (Si `HOST_UID`/`HOST_GID` se pasan explícitos, siguen ganando siempre,
   incluso si son `0` — esa sería una elección deliberada del operador, no un
   artefacto de mount.)

2. En la rama `else` (usuario ya existe) del bloque en `entrypoint.sh` (~línea
   88 actual), solo intentar el resync si hay override explícito:
   ```bash
   else
     # Usuario ya existe (imagen/volumen reusado) — resincronizar UID/GID
     # SOLO si el operador lo pidió explícitamente vía HOST_UID/HOST_GID.
     # No usar la detección automática del mount acá: en reinicios repetidos
     # es una señal poco confiable (ver metadata GID 0 de bind mounts en
     # WSL2/Docker Desktop) y causaba un groupmod fallido en cada arranque.
     if [[ -n "${HOST_UID-}" || -n "${HOST_GID-}" ]]; then
       CURRENT_UID=$(id -u "${HOME_USER}")
       CURRENT_GID=$(id -g "${HOME_USER}")
       CURRENT_GROUP=$(id -gn "${HOME_USER}")

       if [ "$CURRENT_UID" != "$TARGET_UID" ] || [ "$CURRENT_GID" != "$TARGET_GID" ]; then
         if [ "$CURRENT_GID" != "$TARGET_GID" ]; then
           sudo groupmod -g "${TARGET_GID}" "${CURRENT_GROUP}"
         fi
         if [ "$CURRENT_UID" != "$TARGET_UID" ]; then
           sudo usermod -u "${TARGET_UID}" "${HOME_USER}"
         fi
         sudo find / -xdev \( -user "${CURRENT_UID}" -o -group "${CURRENT_GID}" \) \
           -exec chown -h "${TARGET_UID}:${TARGET_GID}" {} + 2>/dev/null || true
       fi
     fi
   fi
   ```

3. Actualizar la sección de `readme.md` sobre `HOST_UID`/`HOST_GID` para
   aclarar que, para un usuario ya existente (contenedor reiniciado/reusado),
   el resync solo ocurre si se pasan `HOST_UID`/`HOST_GID` explícitos — la
   auto-detección desde el volumen montado solo aplica la primera vez que se
   crea el usuario.

### Verificación del fix
1. `bash -n entrypoint.sh`.
2. Reiniciar el contenedor sin `HOST_UID`/`HOST_GID` sobre un volumen ya
   existente (el mismo que dio el error) → no debe aparecer más
   `groupmod: GID '0' already exists`, ni ningún intento de resync.
3. Reiniciar el contenedor con `-e HOST_UID=502 -e HOST_GID=502` sobre un
   usuario ya creado con otro UID/GID → debe correr `usermod`/`groupmod` una
   vez y quedar en 502:502, sin error.
4. Repetir el arranque una tercera vez con el mismo `HOST_UID=502
   HOST_GID=502` → no debe intentar `usermod`/`groupmod` de nuevo (ya
   coincide), y no debe haber errores.

## Contexto

Hoy `entrypoint.sh` crea el usuario `HOME_USER` (default `vscode`) siempre con
`--uid 1000` hardcodeado (línea 70). Esto rompe cuando el `/home/${HOME_USER}`
se monta desde un volumen del host cuyo dueño real tiene otro UID/GID (por
ejemplo un usuario Linux del host distinto de 1000), generando problemas de
permisos entre el contenedor y los archivos montados.

El objetivo es que el UID/GID del usuario dentro del contenedor:
1. Se pueda fijar explícitamente vía `HOST_UID` / `HOST_GID`.
2. Si no se fijan, se detecte automáticamente a partir del dueño real de
   `/home/${HOME_USER}` (cuando ya existe por venir de un volumen montado).
3. Si tampoco se puede detectar, caiga al comportamiento actual (UID/GID 1000),
   preservando compatibilidad con quien no use esta variable.
4. Si el contenedor se reinicia/reusa y el usuario del sistema ya existía con
   otro UID/GID, se resincronice (`usermod -u`, `groupmod -g`) y se re-asignen
   los archivos que quedaron con el UID/GID viejo, para no dejar huérfanos.

## Cambio 1 — detección de UID/GID (nueva, antes de tocar `/home`)

Insertar justo después de resolver `HOME_USER` (después de la línea 6 actual,
antes de que cualquier otra parte del script toque `/home/${HOME_USER}`).

Es importante hacerlo **ahí y no más abajo**: el loop de `USER_ENV_` (líneas
~48-56 actuales) puede crear `/home/${HOME_USER}` con dueño `root:root` *antes*
de llegar al bloque de creación de usuario, si hay variables `USER_ENV_*`
seteadas y el directorio no viene de un bind mount. Si la detección corriera
después de ese loop, leería `root:root` en vez de caer al default 1000.

```bash
DETECTED_UID=$(stat -c '%u' "/home/${HOME_USER}" 2>/dev/null || echo 1000)
DETECTED_GID=$(stat -c '%g' "/home/${HOME_USER}" 2>/dev/null || echo 1000)
TARGET_UID="${HOST_UID:-$DETECTED_UID}"
TARGET_GID="${HOST_GID:-$DETECTED_GID}"
```

Compatible con `set -eu`: `${VAR:-default}` no dispara `set -u`, y el `|| echo
1000` garantiza que la sustitución de `stat` nunca falle bajo `set -e`.

## Cambio 2 — reemplazar el bloque de creación de usuario (líneas 68-80 actuales)

```bash
USER="$HOME_USER"
if ! id -u "$HOME_USER" > /dev/null 2>&1; then
  sudo groupadd -g "${TARGET_GID}" "${HOME_USER}" 2>/dev/null || true
  sudo adduser --disabled-password --gecos "" --uid "${TARGET_UID}" --gid "${TARGET_GID}" "${HOME_USER}"
  sudo echo "$HOME_USER ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers.d/nopasswd > /dev/null

  # Creating .vscode folder if it doesn't exist
  if [ ! -d "/home/${HOME_USER}/.vscode" ]; then
    sudo mkdir -p "/home/${HOME_USER}/.vscode"
  fi

  # Changing the property of the directory /home/${HOME_USER}/.vscode
  sudo chown -R "${HOME_USER}" "/home/${HOME_USER}/.vscode"
else
  # Usuario ya existe (imagen/volumen reusado) — resincronizar UID/GID si cambiaron
  CURRENT_UID=$(id -u "${HOME_USER}")
  CURRENT_GID=$(id -g "${HOME_USER}")
  CURRENT_GROUP=$(id -gn "${HOME_USER}")

  if [ "$CURRENT_UID" != "$TARGET_UID" ] || [ "$CURRENT_GID" != "$TARGET_GID" ]; then
    if [ "$CURRENT_GID" != "$TARGET_GID" ]; then
      sudo groupmod -g "${TARGET_GID}" "${CURRENT_GROUP}"
    fi
    if [ "$CURRENT_UID" != "$TARGET_UID" ]; then
      sudo usermod -u "${TARGET_UID}" "${HOME_USER}"
    fi
    sudo find / -xdev \( -user "${CURRENT_UID}" -o -group "${CURRENT_GID}" \) \
      -exec chown -h "${TARGET_UID}:${TARGET_GID}" {} + 2>/dev/null || true
  fi
fi
```

Notas de diseño:
- `groupadd -g "${TARGET_GID}" "${HOME_USER}"` corre siempre (con `|| true`)
  antes del `adduser`, porque `adduser --gid <numérico>` requiere que ya
  exista un grupo con ese GID.
- A diferencia del borrador original (que solo comparaba UID), también se
  compara GID y se resincroniza con `groupmod` si cambió — si no, un volumen
  cuyo GID cambió quedaría con archivos "group-orphan".
- `id -gn` resuelve el nombre real del grupo primario actual (por si no
  coincide con `${HOME_USER}`), en vez de asumirlo.
- El resync de archivos hace un solo `find` con `-user X -o -group Y` y
  `chown -h uid:gid`, cubriendo tanto el caso de UID como de GID en un solo
  pase.
- Se mantiene sin cambios el `sudo find "/home/${HOME_USER}" -xdev -exec chown
  "${HOME_USER}" {} +` que ya existe más abajo (línea ~86, en la rama donde el
  script ya corre como el usuario objetivo) — no es redundante, es una red de
  seguridad adicional sobre `/home`, y sigue siendo válida tanto si el usuario
  se creó de cero como si se resincronizó.

### Riesgos conocidos (documentar, no bloquean el cambio)
- Si `TARGET_UID`/`TARGET_GID` ya están tomados por otra cuenta/grupo del
  sistema, `usermod -u` / `groupmod -g` fallarán (comportamiento actual de
  esas herramientas; no se agrega manejo especial).
- El `find / -xdev` de resincronización recorre todo el filesystem del
  contenedor (limitado por `-xdev` a no cruzar de montaje) — tiene un costo de
  arranque en imágenes con muchos archivos, pero es el mismo patrón que ya usa
  el script en la línea 86.

## Cambio 3 — actualizar `readme.md` para documentar las nuevas env vars

- En la sección "Environment Variables" (líneas 13-18), agregar `HOST_UID` y
  `HOST_GID` junto a `HOME_USER`/`VSCODE_TUNNEL_NAME`, explicando que son
  opcionales y que si no se setean se autodetectan desde el volumen montado o
  caen a 1000.
- En la sección "Using this image as a base image in a Dockerfile" (líneas
  148-172), agregar una nota breve indicando que el UID `1000` de ese ejemplo
  es solo ilustrativo y que en runtime `entrypoint.sh` puede resincronizarlo
  vía `HOST_UID`/`HOST_GID` si se pasan al contenedor final.

No se toca el `Dockerfile` (el `fixuid` hardcodeado a `vscode` en la línea 22
es código muerto hoy — no se invoca en `entrypoint.sh` — y está fuera del
alcance de este cambio).

## Verificación

1. `bash -n entrypoint.sh` para chequeo de sintaxis.
2. Levantar el contenedor sin `HOST_UID`/`HOST_GID` y sin volumen montado en
   `/home/vscode` → debe crear el usuario con UID/GID 1000 (comportamiento
   actual preservado).
3. Levantar el contenedor con `-e HOST_UID=1500 -e HOST_GID=1500` → el usuario
   creado debe tener ese UID/GID (`id vscode` dentro del contenedor).
4. Montar un volumen en `/home/vscode` cuyo contenido pertenezca a un UID/GID
   distinto de 1000 (sin pasar `HOST_UID`/`HOST_GID`) → el usuario creado debe
   tomar ese UID/GID detectado (`stat -c '%u:%g' /home/vscode`).
5. Simular "imagen reusada": crear el usuario una vez, luego reiniciar el
   contenedor con un `HOST_UID`/`HOST_GID` distinto → verificar que
   `usermod`/`groupmod` corrieron y que archivos de prueba en `/home/vscode`
   quedaron con el nuevo dueño (`ls -n /home/vscode`).
