[Libguestfs] [v2v PATCH 4/4] convert_linux: install the QEMU guest agent with a firstboot script

Laszlo Ersek lersek at redhat.com
Fri Jun 10 07:11:25 UTC 2022


On 06/09/22 16:11, Richard W.M. Jones wrote:
> On Thu, Jun 09, 2022 at 03:53:39PM +0200, Laszlo Ersek wrote:
>> On 06/09/22 15:10, Laszlo Ersek wrote:
>>
>>> nm-online -x -q ||
>>> (
>>>   systemctl -q is-active systemd-networkd &&
>>>   /usr/lib/systemd/systemd-networkd-wait-online -q --timeout=30
>>> )
>>>
>>> If the final exit status is nonzero, I think that's not a problem for
>>> the firstboot script.
>>>
>>> The whole command seems to make sense also when nm-online, systemctl, or
>>> both, are missing (a missing command results in exit status 127).
>>
>> Unfortunately, this does not work. Even though the command succeeds very
>> quickly (implying network is available), the DNF throws a CURL error
>> that it cannot access the repo (DNS resolution failure). So basically
>> "nm-online" lies.
> 
> That's annoying.
> 
> Thinking through this - it's a real guest boot (not libguestfs
> appliance).  The network is up at some point possibly early in the
> boot.  Could be some DNS resolver not yet started?  (systemd-resolved,
> nscd, unbound, ...)

Very possible, but for all practical intents and purposes, we consider
an OS to be "online" once name resolution works as well. It's extremely
rare that applications connect to hosts directly by numerical IP
addresses. There is no separate tool to check for DNS functionality
(that I know of) similar to nm-online, so it should absolutely be
nm-online's responsibility.

Meanwhile, independently, on tech-list, I've found mention of the
following two files:

https://fedoraproject.org/static/hotspot.txt
http://static.redhat.com/test/rhel-networkmanager.txt

and a reference:

https://git.centos.org/rpms/NetworkManager/blob/c9/f/SOURCES/20-connectivity-redhat.conf

I have no idea how this factors (if at all) into "nm-online". Should we
try to access these files with "curl -I" directly?

I've run a web search for
"https://fedoraproject.org/static/hotspot.txt", some results:

https://ask.fedoraproject.org/t/networkmanager-sends-packets-when-idle-mode/9631
https://www.reddit.com/r/Fedora/comments/6jk62f/how_can_i_stop_fedora_from_contacting/
https://forums.whonix.org/t/disable-sys-net-pings-to-fedoraproject-org/1952

It looks like NetworkManager keeps (infrequently) pinging
"https://fedoraproject.org/static/hotspot.txt" in the background, and
then (at best!) "nm-online" *could* (I guess!) fetch the result of the
latest access. IOW, if nm-online is associated at all with this URL, it
is a very indirect association (both spatially, i.e., it's not nm-online
itself doing the access, and in time, i.e. nm-online relies on a
potentially stale result; TOCTTOU).

However valid or reliable this URL could be, it's still one central URL,
and (as the above example shows) users do consider it "phoning home".

Thanks,
Laszlo

> 
>> Compare:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1482476#c4
>>
>>> My current workaround is to use "/usr/bin/sleep 60" instead of the
>>> "/usr/bin/nm-online -s -q --timeout=30" command in the service unit
>>> file.
>>
>> :/
>>
>> NB, when I log in at the root prompt of the just-firstbooted-guest (on
>> tty1), and run "nm-online -x -q", it succeeds alright, and I can even
>> ssh into the guest... (more precisely, I get an ssh password prompt; I
>> can't actually log in as root via ssh due to the default sshd config not
>> permitting that).
>>
>> We can't rely on "nm-online" if it doesn't do its advertized job!
> 
> Rich.
> 



More information about the Libguestfs mailing list