View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006239||Kali Linux||[All Projects] General Bug||public||2020-03-30 15:13||2020-04-22 14:33|
|Target Version||Fixed in Version||2020.2|
|Summary||0006239: cloud-init in Kali AWS image persists in 'running' state|
We're trying to leverage cloud-init's ability to report whether a given EC2 instance is running and all configuration changes took place. However, both Kali 2019.03 and 2020.01 are displaying the same behavior: 'cloud-init status' shows 'running' state, so 'cloud-init status --wait' never completes.
|Steps To Reproduce||1. Start a new Kali 2020.01 ec2 instance|
2. Wait until SSH service is accessible, connect to the system
3. Run 'cloud-init status'. Normal boot should result in: 'status: done', Kali returns 'status: running'
|Additional Information||First Kali boot also results in a long timeout:|
root@kali:~# cloud-init analyze blame
-- Boot Record 01 --
The 'running' status may be related to cloud-init waiting for 'network-online.target' to complete.
Thank you in advance!
||More information: it appears that both cloud-config.service and cloud-final.service are disabled, thus rendering cloud-init half usable. That's likely the root cause here, which begs the question: why are those disabled in the official AMIs?|
I updated the default systemd presets in base-files to allow for the cloud-init service to run by default.
This is in base-files 1:2020.2.0. Hopefully this will help. But I'm not sure if cloud-init has a good default behaviour on Kali.
Thanks! Cloud-init is de-facto the standard approach for all distributions on AWS, so having it configured and running properly would be a good idea. Ubuntu, Debian, CentOS, and other major have good examples of working cloud-init in their official AMIs. There are other problems that we've been able to identify with the assistance of cloud-init developers, which probably should be addressed at this point:
1) There are three services that need to be enabled:
2) Currently cloud-init support for apt assumes presence of 'security' repository, which Kali doesn't have. As a result, starting cloud-config.service breaks because /etc/cloud/cloud.cfg has the following:
- arches: [default]
Cloud-init developers suggested the following workaround, which we've tested and it works:
- arches: [default]
3) This one is less important, but it appears that during the build stage Kali creates user 'kali'. With cloud-init that's typically accomplished via the existing /etc/cloud/cloud.cfg section:
# This will affect which distro class gets used
# Default user name + that default users groups (if added/used)
groups: [adm, audio, cdrom, dialout, dip, floppy, netdev, plugdev, sudo, video]
sudo: ["ALL=(ALL) NOPASSWD:ALL"]
The existing current setup means the user 'kali' is present at uid 1000, so cloud-init creates another user 'ec2-user' with uid 1001. To follow the convention of the rest of AWS AMIs, there would be no need to create the user 'kali', and just letting cloud-init create an appropriate user. This way consumers can override it easily with user-data.
Thank you so much for your help with this!
I have added a new /etc/cloud/cloud.cfg.d/20_kali.cfg with the appropriate configuration and this package will be installed in the next AMI so that should fix this.
|2020-03-30 15:13||ananke||New Issue|
|2020-03-30 16:39||ananke||Note Added: 0012569|
|2020-03-30 20:26||rhertzog||Note Added: 0012570|
|2020-03-30 20:26||rhertzog||Assigned To||=> rhertzog|
|2020-03-30 20:26||rhertzog||Status||new => assigned|
|2020-03-30 20:39||ananke||Note Added: 0012571|
|2020-04-22 14:33||rhertzog||Status||assigned => resolved|
|2020-04-22 14:33||rhertzog||Resolution||open => fixed|
|2020-04-22 14:33||rhertzog||Fixed in Version||=> 2020.2|
|2020-04-22 14:33||rhertzog||Note Added: 0012664|