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

[Bjoern Kaufmann <bjoern.kaufmann.s@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 6009 bytes --]



Thanks for your clarification, that explains it.

 

Meanwhile I also found 
https://github.com/ilbers/isar/blob/master/bitbake/lib/bb/utils.py#L1630 
which is most probably the function responsible for disabling the network 
for tasks. But I was still wondering because the isar commit 
(d26660b724b034b602f3889f55a23cd9be2e87bd) I though I was referencing in my 
build doesn't contain that function yet and also the whole [network] 
functionality is missing. Turns out that I made a mistake when backtracking 
the commits of dependent layers of my build and I am actually using a 
different isar commit (93cc388638336997a7c00b6ef8a58ee349407a54), which 
already contains that functionality.

 

I tried it out again with do_testtask[network] = "1" and now the network 
interfaces are indeed available.

Thank you all for your help.


 

Best regards,

Bjoern

On Friday, March 15, 2024 at 10:28:34 AM UTC+1 Schmidt, Adriaan wrote:

> 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+...@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.
>

[-- Attachment #1.2: Type: text/html, Size: 9514 bytes --]