RE: No network available during task do_install on debian bullseye/5.10 host - but on a debian buster/4.19 host network is available

["Schmidt, Adriaan" <adriaan.schmidt@siemens.com>]

Anton Mikanovich, Sent: Friday, March 15, 2024 10:17 AM:
> 15/03/2024 11:06, Bjoern Kaufmann wrote:
> > I did what you proposed, but there is still no eth0.
> > What I also tested and what might be interesting:
> >
> > def print_ifs():
> >     import subprocess
> >     import socket
> >
> >     output = subprocess.check_output("ip a", shell=True)
> >     print(f'Output of ip a: "{str(output)}"')
> >
> >     print(socket.if_nameindex())
> >     return ''
> >
> > do_testtask() {
> >     ${@ print_ifs()}
> >     ip a
> > }
> > addtask testtask
> >
> >
> > I executed it inside kas shell by 'bitbake -c testtask my-recipe'
> > again and the log looks as follows:
> >
> > DEBUG: Executing shell function do_testtask
> > Output of ip a: "b'1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc
> > noqueue state UNKNOWN group default qlen 1000\n  link/loopback
> > 00:00:00:00:00:00 brd 00:00:00:00:00:00\n    inet 127.0.0.1/8 scope
> > host lo\n       valid_lft forever preferred_lft forever\n4: eth0@if5:
> > <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
> > group default \n    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
> > link-netnsid 0\n    inet 172.17.0.2/16 brd 172.17.255.255 scope global
> > eth0\n       valid_lft forever preferred_lft forever\n'"
> > [(1, 'lo'), (4, 'eth0')]
> > Output of ip a: "b'1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN
> > group default qlen 1000\n    link/loopback 00:00:00:00:00:00 brd
> > 00:00:00:00:00:00\n'"
> > [(1, 'lo')]
> > 1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
> >     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> > DEBUG: Shell function do_testtask finished
> >
> >
> > So as you can see
> > 1. The python function is printed twice in a row, most probably in two
> > different contexts? I guess you know more about it
> > 2. During the first execution of the python function, eth0 interfaces
> > are available
> > 3. During the second execution of the python function, no eth0
> > interface is available
> >
> >
> > Also Jan Kiszka told me that to his knowledge the newer bitbake
> > isolates tasks from networks by default. If this is the case it still
> > doesn't really explain the behavior show in the log above and it
> > doesn't explain why this doesn't happen on the buster host VMs.
> >
> > Best regards,
> > Bjoern
> 
> Hello Bjoern,
> 
> The first print_ifs execution was done during recipe parsing, the second one
> was done during task execution.
> It happens because you've used inline python call.
> 
> For bitbake 2.0+ you can enable network access for your task by setting:
> do_testtask[network] = "1"

Just to expand on this: In general, there is no networking in Bitbake tasks.

From the Bitbake manual (https://docs.yoctoproject.org/bitbake/2.6/bitbake-user-manual/bitbake-user-manual-metadata.html#variable-flags):
===
Variable Flags
[...]
[network]: When set to “1”, allows a task to access the network. By default, only the do_fetch task is granted network access. Recipes shouldn’t access the network outside of do_fetch as it usually undermines fetcher source mirroring, image and licence manifests, software auditing and supply chain security.
===

Yocto changelog (https://docs.yoctoproject.org/singleindex.html, grep for "[network]"):
===
Network access from tasks is now disabled by default on kernels which support this feature (on most recent distros such as CentOS 8 and Debian 11 onwards). This means that tasks accessing the network need to be marked as such with the network flag. For example:

do_mytask[network] = "1"
This is allowed by default from do_fetch but not from any of our other standard tasks. Recipes shouldn’t be accessing the network outside of do_fetch as it usually undermines fetcher source mirroring, image and licence manifests, software auditing and supply chain security.
===

Note that the changelog mentions "Debian 11 onwards", which is why you may be seeing a different behavior on buster.

In addition for Isar:
The way the Bitbake feature is implemented has a side-effect that also disables sudo. So in Isar, "network" is also enabled for tasks that need sudo.

Adriaan


> On my side even without it 'ip a' was showing eth0, but there maybe some
> other
> permissions configuration.
> 
> --
> You received this message because you are subscribed to the Google Groups
> "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to isar-users+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/isar-users/2cb96a28-8df6-47c2-b16f-
> a8379d4ae6dc%40ilbers.de.