Develop/spapadop#28
Conversation
… UID/GID lookups and conditional rename/create logic for the dev account.
…tall to prevent breakage from stale UID/GID ownership
…tup failure on missing directory
…tion and remove conflicting filepath tag so valid absolute paths pass consistently
… shell quoting for user/group and path arguments
…h is used and venv python is missing
… setup to prevent stale-dotfile permission failures (e.g. .bashrc)
…v-startup-script-so-generated-devenvs-boot Spapadop/plt 859 stabilize devenv startup script so generated devenvs boot
…h-validation-incorrectly-uses-filepath Spapadop/plt 881 volumemount path validation incorrectly uses filepath
…sage-in-rendered-manifest-files spapadop/plt-862-fix-namespace-usage-in-rendered-manifest-files
…match StatefulSet serviceName while preserving existing SSH/HTTP services
…vicename-does-not-match-any-generated-service Spapadop/plt 849 statefulset servicename does not match any generated service
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
eywalker
left a comment
There was a problem hiding this comment.
Looks great -- thanks for catching all those subtle bugs
| @@ -1,7 +1,26 @@ | |||
| apiVersion: v1 | |||
| kind: Service | |||
| metadata: | |||
There was a problem hiding this comment.
What's this extra SSH port for?
There was a problem hiding this comment.
This was the reply I got when I asked ChatGPT at the time:
Great question. Practical implications are:
- With the port (22) on the headless governing Service:
- Service is clearly valid/standard and reliably accepted by Kubernetes API.
- EndpointSlices include a named port (ssh), so SRV-based discovery can work.
- You get no extra external exposure by itself, because it is still headless (clusterIP: None) and not NodePort/LoadBalancer.
- Without any port on that Service:
- You still get the main StatefulSet DNS identity behavior (pod hostnames) in many setups.
- But Service definitions without ports are less standard and can be rejected depending on API validation/version/config.
- You lose explicit service-port metadata (and SRV records tied to named ports).
- Bottom line:
- The port is mostly low-risk structural correctness and compatibility.
- It does not replace or affect external SSH access; that still comes from devenv-ssh-{{.Name}} NodePort service.
| if id -g ${TARGET_GID} &>/dev/null; then | ||
| echo "Renaming group ${TARGET_GID} to ${DEV_USERNAME}" | ||
| groupmod -n ${DEV_USERNAME} $(id -gn ${TARGET_GID}) | ||
| if GROUP_ENTRY="$(getent group "${TARGET_GID}")"; then |
There was a problem hiding this comment.
Curious to learn what was the problem with id -g?
There was a problem hiding this comment.
getent is better here because you’re checking numeric UID/GID existence, not “user by name”.
Why id was wrong in this context:
- id -u ARG / id -g ARG interpret ARG as a username, not a UID/GID lookup key.
- So with TARGET_UID=10000, id -u 10000 means “user literally named 10000”, not “does UID 10000 exist?”
That can send logic down the wrong branch (try useradd/groupadd when entries already exist).
Why getent fits:
-
getent passwd does NSS lookup by UID key.
-
getent group does NSS lookup by GID key.
-
It works across configured identity sources (/etc/passwd, LDAP, etc.) through NSS, same source of truth account tools use.
Practical impact in your script:
- Correctly detects existing UID/GID mappings.
- Makes create/rename logic truly idempotent.
- Avoids false negatives and collision failures from mis-detection.
| else | ||
| echo "Adding user ${DEV_USERNAME} with UID ${TARGET_UID}" | ||
| useradd -u ${TARGET_UID} -m -s /bin/bash ${DEV_USERNAME} | ||
| useradd -u "${TARGET_UID}" -g "${TARGET_GID}" -m -s /bin/bash "${DEV_USERNAME}" |
Closes PLT-859 #24
Closes PLT-881 #25
Closes PLT-862 #26
Closes PLT-849 #27