canonical / cloud-init

Official upstream for the cloud-init: cloud instance initialization
https://cloud-init.io/
Other
2.99k stars 880 forks source link

Azure data source assumes use of dhclient #3891

Open ubuntu-server-builder opened 1 year ago

ubuntu-server-builder commented 1 year ago

This bug was originally filed in Launchpad as LP: #1936823

Launchpad details
affected_projects = []
assignee = None
assignee_name = None
date_closed = None
date_created = 2021-07-19T11:57:08.529823+00:00
date_fix_committed = None
date_fix_released = None
id = 1936823
importance = medium
is_complete = False
lp_url = https://bugs.launchpad.net/cloud-init/+bug/1936823
milestone = None
owner = rjschwei
owner_name = Robert Schweikert
private = False
status = triaged
submitter = rjschwei
submitter_name = Robert Schweikert
tags = []
duplicates = []

Launchpad user Robert Schweikert(rjschwei) wrote on 2021-07-19T11:57:08.529823+00:00

The Azure data source assumes that all Linux distros use dhclient. Location of a lease file is hard coded to

""" LEASE_FILE = '/var/lib/dhcp/dhclient.eth0.leases' """

and if the file is not found the data source reports errors:

""" Failed to read /var/lib/dhcp/dhclient.eth0.leases: [Errno 2] No such file or directory: '/var/lib/dhcp/dhclient.eth0.leases' """

Further, during the cloud-init local stage cloud-init establishes a temporary dhclient connect but the lease file is written to a temporray location such as:

""" /var/tmp/cloud-init/cloud-init-dhcp-sbhredt8/dhcp.leases """

The Azure data source should check if the network is up rather than depending on specific markers in the file system left by specific implementations for dhcp connections. The kernel sysfs provides more reliable methods to detect network connection precense.

holmanb commented 1 year ago

@rjschwei It looks like nobody ever responded with questions to this bug, and now it's been migrated to Github issues. I have a couple of questions to ask.

Further, during the cloud-init local stage cloud-init establishes a temporary dhclient connect but the lease file is written to a temporray location such as

Note that since the time that this bug was filed, this behavior is no longer exhibited in upstream cloud-init.

The Azure data source assumes that all Linux distros use dhclient.

All supported linux distros currently do this, right?

The Azure data source should check if the network is up rather than depending on specific markers in the file system left by specific implementations for dhcp connections. The kernel sysfs provides more reliable methods to detect network connection precense.

Anything specific you propose?

I'm not sure that I see this issue as an actual bug right now. Is there some behavior that is broken because of the current implementation?

pemensik commented 1 year ago

dhclient were obsoleted by its upstream, as reported in issue #4077. It does not really matter that distributions still keep it present. It should not be relied on and should be just optional.