Cannot login despite pods being healthy (when creating a user with superuser.existingSecret)

[abctaylor]

My only diff to the official values.yaml is:

• I'm defining superuser.existingSecret as netbox-superuser
• ingress class is nginx and a hostname is specified
• a TLS cert is present for the ingress too
• clusterDomain is specified for the redis and postgres subcharts because I don't use cluster.local
• media persistence disabled

The secret I'm using looks like this:

[root@kube2-lon netbox]# k get secret netbox-superuser -o jsonpath="{.data}" | jq
{
  "api_token": "Zk1INVUzb1JGU2NIUGVWYnNESGlWNzdvCg==",
  "email": "<base64-encoded email, redacted>",
  "password": "ZXZVJm5maWVRbWQ2WVB5IUxaI3B3OFpMCg==",
  "username": "bC1hZG1pbgo="
}

These are real creds, which I'll rotate when this is resolved. Every time I re-deploy to test, I also delete all PVCs to avoid getting stung on that.

I'm out of luck when trying to login. If I drop into the container and make a user with ./manage.py createsuperuser I can login. When in the GUI, I do not see the account l-admin that should have been created with the above creds.

Thanks.

[LeoColomb]

Thanks for opening this issue @abctaylor. Few additional questions:

• Would it be possible to share your values?
• On a freshly created pod, if you drop into the container, what are the environment variables defined? (printenv)
• During container initialization, the container following container startup script is run. Does it print anything on the pod log? https://github.com/netbox-community/netbox-docker/blob/0c99ff8b5663db3e0db5a45660cebda9f917508b/docker/docker-entrypoint.sh#L53-L82

[abctaylor]

Hi @LeoColomb - thanks for the reply.

I don't see my expected l-admin and the corresponding email when dropping into the pod. Instead I see the defaults from printenv:

...
SUPERUSER_NAME=admin
...
SUPERUSER_EMAIL=admin@example.com
...

So that looks like something messed up in the values, below:

...
# You can also use an existing secret for the superuser password and API token
# See `existingSecret` for details
superuser:
  existingSecret: "netbox-superuser"

# This is a list of valid fully-qualified domain names (FQDNs) for the NetBox
# server. NetBox will not permit write access to the server via any other
...

For te last question about whether I see lines like "skip creating super user", I don't have the logs anymore but I recall from memory seeing these lines correctly print that it is creating the super user shown above (admin/admin@example.com), further suggesting to something wrong I'm doing rather than a bug.

I hacked this by just dropping into the pod and making a user with ./manage.py createsuperuser which was a quick/dirty fix that should survive reboots.

[abctaylor]

I wonder if it was due to some invalid syntax in the API token secret I (sometimes) specified, also using the password gen eg above. In the source code we are using 0123456789abcdef0123456789abcdef01234567 so perhaps next time if I wish to fix this particular bug I might specify this exact API token (base-64-encoded) unless this is a waste of time (I guess yes because it looks like it generates it for you if absent... unless I messed something else up when also omitting this).

[LeoColomb]

I tried to replicate unsuccessfully. Your secret was well available in the same namespace of the deployment, right? If so, have you tried with a completely fresh deployment?

In the coming version (#330), the check for the password will be much more rigorous, hopefully reducing this kind of issues.