Amazon Web Services Question posted in
The official Amazon Web Services documentation can be found here.

Amazon web services – Starting with the latest Debian 12 ami (ami-04d8e65bd49d048bd), sudo: unable to resolve host ip-x-x-x-x: Name or service not known

With

aws ssm get-parameters-by-path --path /aws/service/debian/release/bookworm/ --recursive

I was able to list all official Debian 12 AMIs and I am only interested in amd64 AMIs.

My VPC and subnet have enableDnsSupport set to true.

All my tests are made in the same VPC, same subnet and same security group.
The only thing that changes is the AMIs (all of them from the official Debian account).
I don’t do any config in the EC2 instances. I just start then and try to run a sudo command (ex: sudo ls)

With the following AMIs : ami-087da76081e7685da, ami-058a645884552df66 and ami-07254a4b88b1dc88d I can sudo without any issues

$ sudo ls => my current folder is empty
$ hostname -f
ip-10-0-3-203

if I run an sudo apt update && sudo apt full-upgrade -y, everything looks great and I have the same result with sudo ls and hostname -f

With the latest AMI (ami-04d8e65bd49d048bd) when I run any sudo command (ex : sudo ls) I am getting the following error

$ sudo ls
sudo: unable to resolve host ip-10-0-3-101: Name or service not known
$ hostname -f
hostname: Name or service not known

cat /etc/hosts on all ami have the same pattern

127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

Same for cat /etc/hostname

ip-10-0-3-203

How could I fix the issues on instances using the latest Debian 12 ami (ami-04d8e65bd49d048bd) ?

PS: I have also opened a ticket on the https://salsa.debian.org/cloud-team/debian-cloud-images/-/issues/84 and if someone could help me figuring out what the root cause of the issue is, I would be glad to report it to the Debian Salsa too.

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    I have opened a ticket at https://salsa.debian.org/cloud-team/debian-cloud-images/-/issues/84 and the ticket has been addressed : A new AMI that fixes the issue has been published (ami-088a888e9b38f5006 for eu-west-3, cf. https://wiki.debian.org/Cloud/AmazonEC2Image/Bookworm for other regions).

    Noah Meyerhans explained : "We had originally launched the Debian 12 cloud images with libnss-resolve packages installed, which caused systemd-resolved to handle DNS resolution and caching of results. However, there have been a number of issues reported with this configuration (e.g. https://github.com/systemd/systemd/issues/29069). So we removed libnss-resolved, but in doing so neglected to replace it with libnss-myhostname, which is needed to synthesize results for local hostnames. The current release fixes that oversight."


  2. 0

    To test your situation, I did the following:

    • Went to the eu-west-3 (Paris) region
    • Launched an instance using ami-04d8e65bd49d048bd Debian 12 (20240415-1718)
    • Connected via SSH
    • Entered the command: sudo -i

    I received a similar response:

    admin@ip-172-31-39-60:~$ sudo -i
sudo: unable to resolve host ip-172-31-39-60: Name or service not known

    The reference to ip-172-31-39-60 is significant because the EC2 instance was assigned a private IP address of 172.31.39.60 and a DNS name of ip-172-31-39-60.eu-west-3.compute.internal.

    This suggests that the instance was attempting to resolve a partial domain name, but the default domain name was not eu-west-3.compute.internal.

    I then added an entry to /etc/hosts:

    echo "172.31.39.60 ip-172-31-39-60" >>/etc/hosts

    This then allowed sudo -i to work:

    root@ip-172-31-39-60:~# sudo -i
root@ip-172-31-39-60:~# whoami
root
root@ip-172-31-39-60:~# sudo -l -U admin
Matching Defaults entries for admin on ip-172-31-39-60:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin,
    use_pty

User admin may run the following commands on ip-172-31-39-60:
    (ALL : ALL) ALL
    (ALL) NOPASSWD: ALL

    Summary

    I’m not sure what is causing the problem, but adding an entry to /etc/hosts is a simple workaround for the problem.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search