Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-64462

Debian 10.7 image always ends with "Failure to in post-provisioning for XXX"

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      We have successfully been using an debian 9 image for some time, but want to upgrade to 10.7
      we are basing our image on 
      publisher: "Debian"
      offer: "debian-10"
      sku: "10"
      version: "latest"

      This image is using cloud-init for some tasks in favour of waagent (I think this might be the cause of our issues)
      So when the vm provissions, it al goes fine, it shows up in azure, but the part where jenkins connects to the vm and updates credentials for the user to use for ssh newer completes.

      and after some time jenkins gives up and deletes the vm.

      So by using delete lock on the vm in aure, I have been abel to capture a VM, and i have been able to verify that the jenkins user on the vm have not yet gotten his login/ssh password set. If i swithc back to the old debian 9.x image it all works fine again.
      So I could set the jenkins password in the packer image that we are creating, but it both would be a bad idea, and I think it would only solve the issue that jenkins cannot ssh, but all the init scripts will not be able to run anyway..
      is there some way one can increase debug output from the plugin?

        Attachments

          Activity

          Hide
          fvissing Frank Vissing added a comment -

          So I have attached the logoutput that the is related to a single node provissioning 

          Show
          fvissing Frank Vissing added a comment - So I have attached the logoutput that the is related to a single node provissioning 
          Hide
          fvissing Frank Vissing added a comment -

          So I found out that the issue is that when the VM is provissioned using cloud-init (as debian buster is) the set password does not work if the user already exists

          2020-12-21 12:56:52,036 - __init__.py[INFO]: User jenkins already exists, skipping.
          

          According to cloud-init

          the only properties that can be used to alter an user is  'plain_text_passwd', 'hashed_passwd', 'lock_passwd', 'sudo', 'ssh_authorized_keys', 'ssh_redirect_user'.
          i tried to change the user and got this output

          2020-12-21 14:34:47,023 - util.py[DEBUG]: Running hidden command to protect sensitive input/output logstring: ['useradd', 'testuser', '--comment', 'Debian', '--groups', 'adm,audio,cdrom,dialout,dip,floppy,netdev,plugdev,sudo,video', '--password', 'REDACTED', '--shell', '/bin/bash', '-m']

          and now jenkins is able to login..
          this is however a bit frustrating that the user cannot be added to the base image before jenkins provissioning is done. We do a lot of configuration changes on our baseimage. I guess one work. arround would be to prepare the image with the userpassword set.. this makes frequent password updates cumbersome. If the provisioning would do both a create full user and an update with the password allone then cloudinit would fail the first , but succeed the last in our case (and the slave would launch just fine)

          Show
          fvissing Frank Vissing added a comment - So I found out that the issue is that when the VM is provissioned using cloud-init (as debian buster is) the set password does not work if the user already exists 2020-12-21 12:56:52,036 - __init__.py[INFO]: User jenkins already exists, skipping. According to cloud-init the only properties that can be used to alter an user is  'plain_text_passwd', 'hashed_passwd', 'lock_passwd', 'sudo', 'ssh_authorized_keys', 'ssh_redirect_user'. i tried to change the user and got this output 2020-12-21 14:34:47,023 - util.py [DEBUG] : Running hidden command to protect sensitive input/output logstring: ['useradd', 'testuser', '--comment', 'Debian', '--groups', 'adm,audio,cdrom,dialout,dip,floppy,netdev,plugdev,sudo,video', '--password', 'REDACTED', '--shell', '/bin/bash', '-m'] and now jenkins is able to login.. this is however a bit frustrating that the user cannot be added to the base image before jenkins provissioning is done. We do a lot of configuration changes on our baseimage. I guess one work. arround would be to prepare the image with the userpassword set.. this makes frequent password updates cumbersome. If the provisioning would do both a create full user and an update with the password allone then cloudinit would fail the first , but succeed the last in our case (and the slave would launch just fine)

            People

            Assignee:
            azure_devops Azure DevOps
            Reporter:
            fvissing Frank Vissing
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated: