Cloudinit issue with legacy CentOS Stream 8

[jmauto]

Problem:
Does anyone encounter the issue with Centos Stream 8? For some reasons, I have to working with the EOL OS.
It keeps trying to create the default user ‘admin’ where those parameters assigned to the user are in the wrong object type. For example,

Invalid user-data /var/lib/cloud/instances/i-bdf3f54642b2d80f8e/cloud-config.txt
Error: Cloud config schema errors: users.1.passwd: None is not of type ‘string’, users.1.sudo: [‘ALL=(ALL) ALL’] is not of type ‘boolean’, users.1.sudo: [‘ALL=(ALL) ALL’] is not of type ‘string’, ‘null’

It has this part in my cloud-config.txt
users:

• default
• groups: users
  lock-passwd: false
  name: admin
  passwd: null
  primary-group: admin
  shell: /bin/bash
  sudo:
  • ALL=(ALL) ALL
    …

which I think it comes from nowhere. I checked the cloud-init template for this VM in foreman, it does not have this section created

for my cloud.cfg in ks.cfg, I did not create any users. Here is the sample of my ks.cfg

cat << EOM > /etc/cloud/cloud.cfg.d/01_network.cfg
network:
config: disabled
EOM

cat << EOM > /etc/cloud/cloud.cfg.d/10_datasource.cfg
datasource_list: [NoCloud]
datasource:
NoCloud:
seedfrom: http://foremanvan01.abc.ca/userdata/
EOM

update-ca-trust enable

cat << EOM > /etc/cloud/cloud.cfg
#cloud-config
cloud_init_modules:

• bootcmd
• ssh

users: {}

cloud_config_modules:

• runcmd

cloud_final_modules:

• scripts-per-once
• scripts-per-boot
• scripts-per-instance
• phone-home

system_info:
distro: centos
paths:
cloud_dir: /var/lib/cloud
templates_dir: /etc/cloud/templates
ssh_svcname: sshd

EOM

I have no idea why it keeps creating the weird default user and break my VM to retrieve the cloud-init template from Foreman.

Please let me know if there is any info you would like to trace.
Expected outcome:
It should run smoothly as CentOS Stream 9 or Rocky 9

Foreman and Proxy versions:
3.10 ,4.12

[dodo]

can’t help you with that
could be some bug in the cloud-init Version in CentOS Stream8

i would advise against of using cloud-init in foreman like you do

just setup a simple VM template with all steps from the docs
i’ve set up a really small cloud-init userdata template in katello like here

Cloud-init Issue with VMware

i just tested it again and build a Host The CloudInit Template is applied before the reboot, so theres the culprit seems like i ran into the same issue as you i had many issues setting this up also i even created a new cloudInit Template with only the following #cloud-config hostname: <%= @host.name %> fqdn: <%= @host %> manage_etc_hosts: true users: {} # use runcmd to grow the VG, LV and root filesystem, as cloud-init # doesn't handle LVM resizing natively runcmd: - cloud-init-per once g…

every other bit of configuration is doing Ansible, never had any problems with that

cloud-init just got so many issue for me, i don’t know if it’s because of the NoCloud Datasource, or if cloud-init just acts really strange sometimes

troubleshooting cloud-init issues is also not fun

[dodo]

i assume you using the same userdata from this post?

Cloud-init Issue with VMware

Problem: I used HashiCorp Packer and ks.cfg to build a gold image from CentOS 8/9 DVD iso. It has cloud-init baked and I followed the insturction from the doc (11.7. Using VMware cloud-init and userdata templates for provisioning) as well. Once the vm has been converted to the vm template in vsphere. I go to Compute resource → Image → Link the VM template. Everything was fine and working great during the image-based provisioning. However, what I noticed was my VM will reboot after 30 seconds …

try a new simple userdata template like

#cloud-config
hostname: <%= @host.name %>
fqdn: <%= @host %>
manage_etc_hosts: true
users: {}
runcmd:
- touch ~/test.txt

phone_home:
  url: <%= foreman_url('built') %>
  post: []
tries: 10
EOF

[jmauto]

I am using the default UserData open-vm-tools from foreman. I followed the doc for cloudinit. I add some snippet into the Cloud-init template

Associating the Userdata and Cloud-init templates with the operating system

1. In the Foreman web UI, navigate to Hosts > Templates > Provisioning Templates.
2. Search for the CloudInit default template and click its name.
3. Click the Association tab.
4. Select all operating systems to which the template applies and click Submit.
5. Repeat the steps above for the UserData open-vm-tools template.
6. Navigate to Hosts > Provisioning Setup > Operating Systems.
7. Select the operating system that you want to use for provisioning.
8. Click the Templates tab.
9. From the Cloud-init template list, select CloudInit default.
10. From the User data template list, select UserData open-vm-tools.
11. Click Submit to save the changes.

<%#
kind: user_data
name: UserData open-vm-tools testing
model: ProvisioningTemplate
oses:

• AlmaLinux

• CentOS

• CentOS_Stream

• Fedora

• Rocky

• Debian

• Ubuntu
  description: |
  Template for VMWare customization via open-vm-tools during user-data image based provisioning.

  Comparing to other user-data templates, e.g. those based on cloud-init, this template defines a Customization Specifications that is evaluated by vSphere while cloning a VM from a Template. When the Template that should be cloned has open-vm-tools installed, this allows to configure certain aspects, e.g. networking of the VM, prior boot, so no DHCP configuration is required.
  Cloud-init is typically used for a stage 2 configuration. In order for this to work, the VMware
  template must have open-vm-tools installed.
  The example below is for Linux only, Windows is supported by this mechanism via Sysprep as well, though.

  This needs to he a hash in YAML format with these keys:

  • encryptionKey (array)
  • globalIPSettings (hash), REQUIRED
  • identity (hash), REQUIRED
  • nicSettingMap (array)
  • options (hash)
  • extraConfig (hash)

  See https://docs.theforeman.org/nightly/Provisioning_Guide/index-foreman-el.html#Provisioning_Virtual_Machines_in_VMware_vSphere-Provisioning_with_cloudinit_and_userdata_templates
  -%>

identity:
LinuxPrep:
domain: <%= @host.domain %>
hostName: <%= @host.shortname %>
hwClockUTC: true
timeZone: <%= host_param(‘time-zone’) || ‘UTC’ %>

globalIPSettings:
dnsSuffixList: [<%= @host.domain %>]
<%- @host.interfaces.each do |interface| -%>
<%- next unless interface.subnet -%>
dnsServerList: [<%= interface.subnet.dns_servers.join(', ') %>]
<%- end -%>

nicSettingMap:
<%- @host.interfaces.each do |interface| -%>
<%- next unless interface.subnet -%>

• adapter:
  dnsDomain: <%= interface.domain %>
  dnsServerList: [<%= interface.subnet.dns_servers.join(', ') %>]
  gateway: [<%= interface.subnet.gateway %>]
  ip: <%= interface.ip %>
  subnetMask: <%= interface.subnet.mask %>
  <%- end -%>

I can see that the Userdata is applied to the host like hostname, IP and DNS. But I think the cloud-init is the main part applying the config to the VM.

[lstejska]

@Shimon_Shtein @gtalreja We had some problems with cloud-init on older versions, if I remember correctly

[Shimon_Shtein]

Not that I am aware of.

The original issue that was described looks like a different schema for the cloudinit file. I am not sure if it was wrong from the get go, or changed between different cloud-init versions (and OS base version that hosts the cloud-init framework).