[00:01] <oerheks> https://serverfault.com/a/987753
[00:02] <sarnold> configuring the cloud-init datasource probably wouldn't disable the google guest agent from creating an ubuntu user
[00:02] <FurretUber> I get the user I want right. However, it creates the extra ubuntu user (it exists on default image, then is remove by the runcmd I defined, then is recreated later).
[00:05] <sarnold> there's something kinda funny / cute about google-guest-agent getting an "update whenever" exception and never actually updating the thing in any release https://launchpad.net/ubuntu/+source/google-guest-agent
[00:09] <oerheks> set it up right?
[00:24] <blackboxsw> FurretUber: do you have example userdata that is safe for us to read that you can paste to us to confirm behavior from cloud-init side? From reading google-guest-agent code, it looks like GGA pulls usernames out of /var/lib/google/google_users
[00:27] <blackboxsw> which may shed light on why GGA is creating that user itself instead of cloud-init. And GGA runs in the init stage at the same time as cloud-init's runcmd, so there also may be races that GGA runs after cloud-init's runcmd finishes .
[00:28] <blackboxsw> to check cloud-init userdata on your system `sudo cloud-init query userdata` (but I presume you have a "users:" in your #cloud-config  that specifically omits `- default`  which is what cloud-init would have used to create the default "ubuntu" user
[00:34] <FurretUber> Ok, this seems to show the relevant bits: https://paste.ubuntu.com/p/FkBr9mNs8y/ veryrandomusername does exist in the end of the process, but ubuntu is there too. Looking it again, maybe it's the SSH key?
[00:34] <blackboxsw> given your journalctl -b 0 output it does look like you've already found the culprit as google-guest-agent there w/ it's default google_users list. https://git.launchpad.net/ubuntu/+source/google-guest-agent/tree/google_guest_agent/non_windows_accounts.go?h=ubuntu/jammy#n125
[00:35] <sarnold> oho, I didn't expect a code browser..
[00:35] <blackboxsw> +1 your users: values indicate as you said already, ubuntu (default) user won't be created by cloud-init, this is purely contained in google-guest-agent working
[00:37] <blackboxsw> google's guest agent does their own provisioning of users outside of cloud-init and neither communicate with each other. so while your runcmd is "good" it still will only be run once, and GGA will continue to recreat users based on the contents of /var/lib/google/google_users I **think**
[00:38] <blackboxsw> I don't know offhand what delivers that file contents.
[00:39] <FurretUber> I was grepping the source code and got to that part  now
[00:39] <FurretUber> Well, I can try to create a file there with the username I want
[00:41] <FurretUber> If it runs after userdata, then write_files should finish first
[00:41] <blackboxsw> shoot sorry I have to bail for the weekend. will peek later
[00:41] <blackboxsw> will checkin later and respond when I can. take care all
[00:41] <FurretUber> You helped me a lot here, thank you
[00:50] <blackboxsw> also yeah quick check on source code is easily available via `snap install git-ubuntu; git-ubuntu clone google-guest-agent; cd google-guest-agent git checkout pkg/ubuntu/jammy`  or any other series folks are on if folks hadn't used git-ubuntu before
[00:51] <blackboxsw> saw some old references to image processes that seeded that /var/lib file with contents https://github.com/GoogleCloudPlatform/compute-image-packages/issues/381. not sure if relevant. ok promise I'm gone now
[00:51] <ubottu> Issue 381 in GoogleCloudPlatform/compute-image-packages "New python3 google-accounts-daemon removes ssh key from ubuntu user" [Closed]
[02:00] <FurretUber> I found what happened: there is a project-wide metadata SSH key which is from a container with gcloud where the user is called ubuntu
[02:01] <FurretUber> So it was transferring that key. I'm sorry
[02:01] <sarnold> \o/
[02:01] <sarnold> thanks for reporting back :)
=== xispita_ is now known as xispita