[ISSUE] "waagent -deprovision+user -force" not working as expected
See original GitHub issueWhen using the waagent -deprovision+user
command, the user re-appears when imaged
Building a CentOS v7.x VM to be used as a source image for future builds. One of the last steps before shutting down the VM is to run the above command. It works as expected for that instance, and the user is removed, but when I build from the new image, my VM contains the user (as defined in /var/lib/waagent/ovf-env.xml
). How do I prevent the user from being re-created on every new instance that is based on my image? From what I’ve read, the cloud-init daemon is responsible for re-populating the file, which in turn is used by the agent to reprovision the new instance. But I haven’t found how/where to fix it so the user isn’t recreated.
Here’s the output of the deprovision command. How do I ensure ‘azadmin’ is not created on every instance built from this image? I confirmed that the user has been removed, as had the /var/lib/waagent/ovf-env.xml
file.
[admin@centos-v7-node ~]$ sudo waagent -deprovision+user
WARNING! The waagent service will be stopped.
WARNING! All SSH host key pairs will be deleted.
WARNING! Cached DHCP leases will be deleted.
WARNING! root password will be disabled. You will not be able to login as root.
WARNING! /etc/resolv.conf will be deleted.
WARNING! azadmin account and entire home directory will be deleted.
Do you want to proceed (y/n)y
2020/07/15 15:15:50.111345 INFO Examine /proc/net/route for primary interface
2020/07/15 15:15:50.116477 INFO Primary interface is [eth0]
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (3 by maintainers)
Top GitHub Comments
@andybacka thanks for reporting this. As for the agent versions, you are on the latest one (2.2.49.2). The 2.2.45 version is the daemon that is preinstalled on this image. For more info, check out this doc: https://github.com/Azure/WALinuxAgent/wiki/FAQ#what-does-goal-state-agent-mean-in-waagent---version-output
@trstringer could you comment on the question related to deprovisioning? Thanks!
The log file is the best place to troubleshoot with logging, but if you do have a repro you can always do some local patching to dump additional data to help diagnose or prove theories. Or likewise, if you have a repro feel free to reopen this issue and we can troubleshoot further together.
Thanks!