-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DNS woes with Debian Bookworm #300
DNS woes with Debian Bookworm #300
Comments
Please note I ran into issues while testing Debian Bookworm with the images used in the CyHy environment. I have not done any testing with Bookworm images used in a COOL assessment environment or similar. |
I have identified the source of the problem. I'd prefer to modify the |
See also canonical/cloud-init#4764. |
The Netplan config is created by cloud-init, but it needs to be slightly modified and reapplied. This script takes care of the modification. See these issues for more details: - cisagov/skeleton-packer#300 - canonical/cloud-init#4764
The Netplan config is created by cloud-init, but it needs to be slightly modified and reapplied. There is a Python script that fixes the DHCP4 options in the netplan configuration already generated by cloud-init. This cloud-init fragment simply reapplies the Netplan configuration after the modification. See these issues for more details: - cisagov/skeleton-packer#300 - canonical/cloud-init#4764
The Netplan config is created by cloud-init, but it needs to be slightly modified and reapplied. See these issues for more details: - cisagov/skeleton-packer#300 - canonical/cloud-init#4764
See this branch, which together with this branch demonstrates and fixes the problem. A Debian Desktop instance created via these branches has been deployed to the COOL staging environment @mcdonnnj - Can you make similar changes in CyHy and verify that you can safely move to Bookworm now? If so then I'd like to do a mini-Kraken that includes #242. |
I suspect this was already an issue for our Kali instances, but we didn't notice because they don't rely on getting search domains from DHCP; however, our Guacamole instance may rely on such functionality. We certainly rely on it in CyHy. |
…onfiguration See these issues for more information: - #300 - canonical/cloud-init#4764
The Netplan config is created by cloud-init, but it needs to be slightly modified and reapplied. See these issues for more details: - cisagov/skeleton-packer#300 - canonical/cloud-init#4764
This is not the case after all. Kali does not use Netplan. |
The Netplan config is created by cloud-init, but it needs to be slightly modified and reapplied. This script takes care of the modification. See these issues for more details: - cisagov/skeleton-packer#300 - canonical/cloud-init#4764
The Netplan config is created by cloud-init, but it needs to be slightly modified and reapplied. There is a Python script that fixes the DHCP4 options in the netplan configuration already generated by cloud-init. This cloud-init fragment simply reapplies the Netplan configuration after the modification. See these issues for more details: - cisagov/skeleton-packer#300 - canonical/cloud-init#4764
The Netplan config is created by cloud-init, but it needs to be slightly modified and reapplied. See these issues for more details: - cisagov/skeleton-packer#300 - canonical/cloud-init#4764
After copying the changes in #242 I verified functionality in my testing deployment of the CyHy environment. I confirmed that the cyhy-commander was able to push work and retrieve results. I also verified that I was able to access all of the instances as expected: $ for host in bastion vulnscan1 portscan1 portscan2 portscan3 portscan4; do ssh "$host".mcdonnnj.cyhy "hostname; lsb_release -d"; done
bastion
Description: Debian GNU/Linux 12 (bookworm)
vulnscan1
Description: Debian GNU/Linux 12 (bookworm)
portscan1
Description: Debian GNU/Linux 12 (bookworm)
portscan2
Description: Debian GNU/Linux 12 (bookworm)
portscan3
Description: Debian GNU/Linux 12 (bookworm)
portscan4
Description: Debian GNU/Linux 12 (bookworm)
$ for host in bastion docker; do ssh "$host".mcdonnnj.bod "hostname; lsb_release -d"; done
bastion
Description: Debian GNU/Linux 12 (bookworm)
docker
Description: Debian GNU/Linux 12 (bookworm) Please see cisagov/cyhy_amis#746. |
The Netplan config is created by cloud-init, but it needs to be slightly modified and reapplied. This script takes care of the modification. See these issues for more details: - cisagov/skeleton-packer#300 - canonical/cloud-init#4764
The Netplan config is created by cloud-init, but it needs to be slightly modified and reapplied. There is a Python script that fixes the DHCP4 options in the netplan configuration already generated by cloud-init. This cloud-init fragment simply reapplies the Netplan configuration after the modification. See these issues for more details: - cisagov/skeleton-packer#300 - canonical/cloud-init#4764
The Netplan config is created by cloud-init, but it needs to be slightly modified and reapplied. See these issues for more details: - cisagov/skeleton-packer#300 - canonical/cloud-init#4764
…onfiguration See these issues for more information: - #300 - canonical/cloud-init#4764
…onfiguration See these issues for more information: - #300 - canonical/cloud-init#4764
There are still some PRs around this issue that need to be merged before it can be closed. |
The Netplan config is created by cloud-init, but it needs to be slightly modified and reapplied. This script takes care of the modification. See these issues for more details: - cisagov/skeleton-packer#300 - canonical/cloud-init#4764
The Netplan config is created by cloud-init, but it needs to be slightly modified and reapplied. There is a Python script that fixes the DHCP4 options in the netplan configuration already generated by cloud-init. This cloud-init fragment simply reapplies the Netplan configuration after the modification. See these issues for more details: - cisagov/skeleton-packer#300 - canonical/cloud-init#4764
The Netplan config is created by cloud-init, but it needs to be slightly modified and reapplied. See these issues for more details: - cisagov/skeleton-packer#300 - canonical/cloud-init#4764
There are still one more PR around this issue that needs to be merged before it can be closed. |
🐛 Summary
@mcdonnnj has reported DNS woes when using a Debian Bookworm base AMI. He says that DNS resolution requires the FQDN (e.g.,
kali1.envX.cool.cyber.dhs.gov
); simply using the hostname (e.g.,kali1
) does not work.The reason for the difference appears to be that Bookworm uses
systemd-resolved
whereas previous Debian releases usedresolvconf
.To reproduce
Expected behavior
The DNS behavior should remain the same, regardless of whether
systemd-resolved
orresolvconf
is used.The text was updated successfully, but these errors were encountered: