I was reading that doc yesterday… I tried to create a new file called “curtin_userdata_ubuntu” with my #cloud-init block, then, the deployments started to fail.
I also tried to write a file, /etc/cloud/cloud.cfg.d/default_user.cfg but that file never appeared…
I tried to change the default user for about 5~6 hours yesterday without success…
You can add a section like the following to /etc/maas/preseeds/curtin_userdata
write_files:
# Create cloud-init config that configures the 'root' user as the
# default user instead of 'centos'.
# Additionally, enables password authentication for this user.
userconfig:
path: /etc/cloud/cloud.cfg.d/00-user.cfg
content: |
ssh_pwauth: yes
disable_root: false
system_info:
default_user:
name: root
lock_passwd: false
plain_text_passwd: 'test'
@andreserl where is the curtin documentation that covers the userconfig object you’re using in the curtin_preseed file there? I need to create an additional default user (along with the usual login user) and I need to add a public key to that account and I need to add a sudo entry for said user. Given those and a few other things I need to do, I’d really like to view the documentation so I can know all my options. Unfortunately, my searched in the curtin documentation have been futile.
@snafuxnj The curtin configuration stanza I’m using is not ‘userconfig’, it is write_files. The ‘userconfig’ word is just a descriptive name/word that describes the section that write_files will write on the target.
The content of the file that write_files will write, is cloud-init user data. In other words, what my code snippet does is to write cloud-init configuration into the installed filesystem (under /etc/cloud/cloud.cfg.d/00-user.cfg), which is then read by cloud-init on first boot post-deployment.
I added the user to the /etc/maas/preseeds/curtin_userdata_custom file so that the configuration we’re adding applies to the custom images we’re using vs everything.
At first it failed. Completely. I checked the cloud-init logs on the ephemeral test host and found no references to the stuff I placed in my config. In fact, the file I told it to write out did not exist on the test machine. I was very confused.
I decided to run a linter on the altered curtin_userdata_custom file and I found and fixed a couple of mildly innocuous things, so I thought. The only thing I really ignored was the line-length warnings. Saved and ran another test.
Bang! Progress. I wasn’t completely out of the woods yet. I needed to polish. A few things I took away for lessons learned:
Make sure the file you intended to write out on the finally-booted ephemeral host is there IE /etc/cloud/cloud.cfg.d/<file>. If it’s not, something is likely wrong with your stuff you changed in the preseeds config template(s).
If the finally-booted ephemeral machine is writing the config but you’re not seeing the user(s) you intended to add, check the cloud-init logs IE /var/log/cloud*log and search for username. Pay attention to errors for useradd. My initial user addition failed because I specified an selinux group on an image where selinux was disabled. The useradd failed because of that.
