Re: [systemd-devel] How to add a second bridge to a nspawn container?

[Mantas Mikulėnas]

On Thu, Jan 3, 2019 at 6:26 PM Wojtek Swiatek  wrote:

> Hello everyone,
>
> I have an nspawn container which is currently connected to a bridge on the
> host:
>
> root@srv /e/s/nspawn# cat domotique.nspawn
> [Exec]
> Boot=yes
> [Network]
> Bridge=br0
> #Bridge=wlx00c0ca384bd9
>
> This results in a host0 interface being present in the container.
> Everything works.
>
> I now would like to add another interface in the container, which would be
> bridged with a wireless card on the host. The commented out line above is
> my attempt to add another bridge but it failed with
>
> -- Subject: Unit systemd-nspawn@domotique.service has begun start-up
> -- Defined-By: systemd
> -- Support: http://www.ubuntu.com/support
> --
> -- Unit systemd-nspawn@domotique.service has begun starting up.
> Jan 03 17:02:17 srv systemd-nspawn[17264]: Selected user namespace base
> 119472128 and range 65536.
> Jan 03 17:02:17 srv systemd-nspawn[17264]: Failed to add interface
> vb-domotique to bridge wlx00c0ca384bd9: Operation not supported
>

That's because the specified interface is not a bridge...

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to add a second bridge to a nspawn container?

[Alexander E. Patrakov]

Wojtek Swiatek :
>
> Hello everyone,
>
> I have an nspawn container which is currently connected to a bridge on the 
> host:
>
> root@srv /e/s/nspawn# cat domotique.nspawn
> [Exec]
> Boot=yes
> [Network]
> Bridge=br0
> #Bridge=wlx00c0ca384bd9
>
> This results in a host0 interface being present in the container. Everything 
> works.
>
> I now would like to add another interface in the container, which would be 
> bridged with a wireless card on the host. The commented out line above is my 
> attempt to add another bridge but it failed with
>
> -- Subject: Unit systemd-nspawn@domotique.service has begun start-up
> -- Defined-By: systemd
> -- Support: http://www.ubuntu.com/support
> --
> -- Unit systemd-nspawn@domotique.service has begun starting up.
> Jan 03 17:02:17 srv systemd-nspawn[17264]: Selected user namespace base 
> 119472128 and range 65536.
> Jan 03 17:02:17 srv systemd-nspawn[17264]: Failed to add interface 
> vb-domotique to bridge wlx00c0ca384bd9: Operation not supported
> Jan 03 17:02:17 srv systemd-udevd[17279]: link_config: autonegotiation is 
> unset or enabled, the speed and duplex are not writable.
> Jan 03 17:02:17 srv systemd-timesyncd[791]: Network configuration changed, 
> trying to establish connection.
> Jan 03 17:02:17 srv networkd-dispatcher[906]: WARNING:Unknown index 26 seen, 
> reloading interface list
> Jan 03 17:02:17 srv systemd-timesyncd[791]: Synchronized to time server 
> 145.238.203.10:123 (ntp.obspm.fr).
> Jan 03 17:02:17 srv systemd[1]: systemd-nspawn@domotique.service: Main 
> process exited, code=exited, status=1/FAILURE
> Jan 03 17:02:17 srv systemd[1]: systemd-nspawn@domotique.service: Failed with 
> result 'exit-code'.
> Jan 03 17:02:17 srv systemd[1]: Failed to start Container domotique.
>
> I am not sure whether "Operation not supported" means that there is something 
> wrong with that config? or that it is not possible to create a bridge to a 
> wireless NIC?

To be able to participate in a bridge, the wireless card must act as
an access point. This restriction comes from the fact that, generally,
there are 4 MAC addresses that one needs to be concerned about: Access
Point, Station, Source and Destination, but a wireless packet can
contain only three distinct ones. Being an access point helps, because
one knows that there are no bridges on the far end, i.e. all incoming
packets have Station = Source, and all outgoing packets except
multicast have Station = Destination.

To sidestep this limitation, use something like parprouted instead of a bridge.

-- 
Alexander E. Patrakov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How to add a second bridge to a nspawn container?

[Wojtek Swiatek]

Hello everyone,

I have an nspawn container which is currently connected to a bridge on the
host:

root@srv /e/s/nspawn# cat domotique.nspawn
[Exec]
Boot=yes
[Network]
Bridge=br0
#Bridge=wlx00c0ca384bd9

This results in a host0 interface being present in the container.
Everything works.

I now would like to add another interface in the container, which would be
bridged with a wireless card on the host. The commented out line above is
my attempt to add another bridge but it failed with

-- Subject: Unit systemd-nspawn@domotique.service has begun start-up
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- Unit systemd-nspawn@domotique.service has begun starting up.
Jan 03 17:02:17 srv systemd-nspawn[17264]: Selected user namespace base
119472128 and range 65536.
Jan 03 17:02:17 srv systemd-nspawn[17264]: Failed to add interface
vb-domotique to bridge wlx00c0ca384bd9: Operation not supported
Jan 03 17:02:17 srv systemd-udevd[17279]: link_config: autonegotiation is
unset or enabled, the speed and duplex are not writable.
Jan 03 17:02:17 srv systemd-timesyncd[791]: Network configuration changed,
trying to establish connection.
Jan 03 17:02:17 srv networkd-dispatcher[906]: WARNING:Unknown index 26
seen, reloading interface list
Jan 03 17:02:17 srv systemd-timesyncd[791]: Synchronized to time server
145.238.203.10:123 (ntp.obspm.fr).
Jan 03 17:02:17 srv systemd[1]: systemd-nspawn@domotique.service: Main
process exited, code=exited, status=1/FAILURE
Jan 03 17:02:17 srv systemd[1]: systemd-nspawn@domotique.service: Failed
with result 'exit-code'.
Jan 03 17:02:17 srv systemd[1]: Failed to start Container domotique.

I am not sure whether "Operation not supported" means that there is
something wrong with that config? or that it is not possible to create a
bridge to a wireless NIC?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Jonathon Kowalski]

a.service will just not stop after it gets activated, and b.service fails.
Otherwise, the start job is cancelled with a JOB_DEPENDENCY job result. If
you need those semantics (and people often do), use After=, so that the
start job for a waits for the running job of b to complete (note that if
you have other things it needs to wait on, it will infact wait on them and
may even produce results you get with After=).

There may be a case made about installing a job of type JOB_STOP if and
ever b.service's *activation* fails, even after a.service activates
successfully, but I wonder if people are already using Requires= alone to
just cause the explicit stop requests (which is why they might not be usinf
PartOf=) of the required unit to take down their service, and startup
dependencies don't really matter. With this change, you'd break that then.

On Thursday, January 3, 2019, Jérémy Rosen  wrote:

>
> Make of that what you will. I was expecting a.service to stop because
> b.service failed, but apparently my understanding of this isn't quite
> right.
>
>
> And that's kinda my point... most people (me included until recently)
> expect that behaviour
>
> I think the overall conclusion of that conversation is that... everything
> is very confusing and everybody is very confused.
>
>
> I'll try to clarify the docs and create a PR for that... It seems to be
> severely needed.
>
> --
> [image: SMILE] 
>
> 20 rue des Jardins
> 92600 Asnières-sur-Seine
> *Jérémy ROSEN*
> Architecte technique
> Responsable de l'expertise Smile-ECS
>
> [image: email] jeremy.ro...@smile.fr
> [image: phone] +33141402967
> [image: url] http://www.smile.eu
>
> [image: Twitter]  [image: Facebook]
>  [image: LinkedIn]
>  [image: Github]
> 
>
> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu]
> 
>
> [image: eco] Pour la planète, n'imprimez ce mail que si c'est nécessaire
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Jérémy Rosen]

Make of that what you will. I was expecting a.service to stop because
b.service failed, but apparently my understanding of this isn't quite
right.


And that's kinda my point... most people (me included until recently) 
expect that behaviour


I think the overall conclusion of that conversation is that... 
everything is very confusing and everybody is very confused.



I'll try to clarify the docs and create a PR for that... It seems to be 
severely needed.


--
SMILE 

20 rue des Jardins
92600 Asnières-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.ro...@smile.fr 
phone +33141402967
url http://www.smile.eu

Twitter  Facebook 
 LinkedIn 
 Github 




Découvrez l’univers Smile, rendez-vous sur smile.eu 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Olaf van der Spek]

On Thu, Jan 3, 2019 at 4:23 AM James Feeney  wrote:
> > What Reindl Harald was saying was that "Requires" should have an
> > implicit "After" because it wouldn't make sense for a.service to
> > require b.service but to start before b.service.
>
> I understand that Reindl has said that.  But, just because Reindl does not 
> have a use case in which a.service requires b.service *and* also starts 
> before b.service, is no reason to prohibit other people from configuring such 
> a use case.  That would be the purview of religious zealots and political 
> fundamentalists.
>
> Reindl might be uncomfortable with other people being "insane" and acting 
> with "wild and crazy abandon", but, ... well, it's a big world out there.
>
> In my case, for instance, I have a service unit which I use, in combination, 
> to configure hot-plug network interfaces.  The service unit makes use of a 
> target unit to sequence stages in the configuration process.  This service 
> unit Requires the target unit *and* must be run *Before* the target unit.
>
> With accumulated experience, people will learn new ways to use their tools.  
> It's just going to take time.

Use or abuse?
I don't know the details, are you sure your way is the best way to use
dependencies for your case?


-- 
Olaf
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel