Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Just stumbled upon this on upgrade to Buster on a IPsec gateway, where the dummy interface is as tunnel source IP. My solution was to let systemd-networkd manage the device by adding /etc/systemd/network/00-dummy.netdev with [NetDev] Name=dummy0 Kind=dummy and then the standard /etc/network/interfaces stanza for dummy0, followed by `systemctl restart systemd-networkd` and `ifup dummy0`. Everything is back without overriding /lib/modprobe.d/systemd.conf I thing the note should suggest the systemd-networkd solution first, as Debian adopted systemd. Thanks Petr
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
On Sb, 29 iun 19, 21:06:31, Michael Biebl wrote: > > - systemd.conf, such as > > - /etc/modprobe.d/zz-local.conf. > > + Admins who were depending on different values will need to ensure > > they are > > + set in the correct way to take precedence. A file in > > + /etc/modprobe.d will override one with the same > > name > > + under /lib/modprobe.d, but the names are Somehow /etc and /lib ended up reversed, fixed in 32d6bf4c. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Am 29.06.2019 um 19:52 schrieb Justin B Rye: > diff --git a/en/issues.dbk b/en/issues.dbk > index 2edb9838..bf007277 100644 > --- a/en/issues.dbk > +++ b/en/issues.dbk > @@ -203,33 +203,28 @@ $ sudo update-initramfs -u > > Module configuration for bonding and dummy interfaces > > - Administrators who are using channel bonding and/or dummy > - interfaces (for instance to configure a machine as a router), and > - who have set up module parameters in a file under > - /etc/modprobe.d, may need to change the name > - of the local configuration file used, to avoid these parameters > - being ignored after the upgrade to buster. > - > - > - In buster, udev ships a > - file /lib/modprobe.d/systemd.conf designed to > - make it easier to configure such interfaces using > - systemd-networkd. This contains the lines > + Systems using channel bonding and/or dummy interfaces, for instance to > + configure a machine as a router, may encounter problems upgrading to > buster. > + New versions of systemd > install a > + file /lib/modprobe.d/systemd.conf (intended to > + simplify configuration via systemd-networkd) which > + contains the lines > > > options bonding max_bonds=0 > options dummy numdummies=0 > > > - A file in /lib/modprobe.d can be overridden by > - one with the same name under /etc/modprobe.d, > - but the names are processed in alphabetical order, so > - /lib/modprobe.d/systemd.conf follows and > - overrides (for instance) > - /etc/modprobe.d/dummy.conf. Make sure that any > - local configuration file has a name that sorts after > - systemd.conf, such as > - /etc/modprobe.d/zz-local.conf. > + Admins who were depending on different values will need to ensure they > are > + set in the correct way to take precedence. A file in > + /etc/modprobe.d will override one with the same > name > + under /lib/modprobe.d, but the names are > + processed in alphabetical order, so > + /lib/modprobe.d/systemd.conf follows and overrides > + (for instance) /etc/modprobe.d/dummy.conf. Make > sure > + that any local configuration file has a name that sorts after > + systemd.conf, such as > + /etc/modprobe.d/zz-local.conf. > > lgtm, fwiw. Thanks Justin. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Back from my walk in the lovely warm pouring rain... Justin B Rye wrote: > Michael Biebl wrote: >> Am 29.06.19 um 15:09 schrieb Justin B Rye: >>> [...] A file in >>> + /lib/modprobe.d can be overridden by one with >>> the >>> + same name under /etc/modprobe.d, but the names >>> are >>> + processed in alphabetical order, so >> >> That sentence is a bit confusing: files with the same name are >> overridden. period. there is no but. Okay, coming back to it, it can't be helping that this is a useless use of passive voice. Swapping it around: [...] A file in /etc/modprobe.d will override one with the same name under /lib/modprobe.d, but the names are processed in alphabetical order, so [...] This way we start off with the focus in the right place: on the existing dummy.conf in /etc. It's not a problem if an upstream /lib/modprobe.d/dummy.conf turns up, *but*... -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package diff --git a/en/issues.dbk b/en/issues.dbk index 2edb9838..bf007277 100644 --- a/en/issues.dbk +++ b/en/issues.dbk @@ -203,33 +203,28 @@ $ sudo update-initramfs -u Module configuration for bonding and dummy interfaces - Administrators who are using channel bonding and/or dummy - interfaces (for instance to configure a machine as a router), and - who have set up module parameters in a file under - /etc/modprobe.d, may need to change the name - of the local configuration file used, to avoid these parameters - being ignored after the upgrade to buster. - - - In buster, udev ships a - file /lib/modprobe.d/systemd.conf designed to - make it easier to configure such interfaces using - systemd-networkd. This contains the lines + Systems using channel bonding and/or dummy interfaces, for instance to + configure a machine as a router, may encounter problems upgrading to buster. + New versions of systemd install a + file /lib/modprobe.d/systemd.conf (intended to + simplify configuration via systemd-networkd) which + contains the lines options bonding max_bonds=0 options dummy numdummies=0 - A file in /lib/modprobe.d can be overridden by - one with the same name under /etc/modprobe.d, - but the names are processed in alphabetical order, so - /lib/modprobe.d/systemd.conf follows and - overrides (for instance) - /etc/modprobe.d/dummy.conf. Make sure that any - local configuration file has a name that sorts after - systemd.conf, such as - /etc/modprobe.d/zz-local.conf. + Admins who were depending on different values will need to ensure they are + set in the correct way to take precedence. A file in + /etc/modprobe.d will override one with the same name + under /lib/modprobe.d, but the names are + processed in alphabetical order, so + /lib/modprobe.d/systemd.conf follows and overrides + (for instance) /etc/modprobe.d/dummy.conf. Make sure + that any local configuration file has a name that sorts after + systemd.conf, such as + /etc/modprobe.d/zz-local.conf.
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Michael Biebl wrote: > Am 29.06.19 um 15:09 schrieb Justin B Rye: >> + configure a machine as a router, may encounter problems upgrading to >> buster. >> + New versions of udev install a > > That modprobe config file is shipped by the systemd package, not by udev. Ah, thanks. >> A file in >> + /lib/modprobe.d can be overridden by one with the >> + same name under /etc/modprobe.d, but the names >> are >> + processed in alphabetical order, so > > That sentence is a bit confusing: files with the same name are > overridden. period. there is no but. If there wasn't a "but", people wouldn't have been caught out! It's true that if you create a file in /etc then you don't need to worry about the one it masks in /lib, but you do still need to worry about others that might turn up in /lib with names that sort later. > Are you trying to say that files can be overridden as a whole but > usually its better to only override specific settings in a local > configuration file which doesn not have the same name? No, I *could* have added a paragraph explaining the drawbacks of using the filename /etc/modprobe.d/systemd.conf, but it seemed simpler just to not mention the suboptimal solution. After all, who knows what might turn up in bullseye's /etc/modprobe.d/udev.conf? > (which is indeed a useful recommendation because future updates of > systemd.conf might be missed if you name the file > /etc/modprobe.d/systemd.conf). The simplest way of looking at this bug is that the old approach (as recommended in legacy HOWTOs) of using filenames like "/etc/modprobe.d/dummy.conf" needs to be updated to using something like "/etc/modprobe.d/zz-local.conf". My explanation covers things in what I hoped was just enough detail to make it clear why that change is needed. I've stared at it quite a bit and can't find a clearer way of saying it. Here's a patch with just the s/udev/systemd/ change; I'll go for a walk and then try looking at it again. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package diff --git a/en/issues.dbk b/en/issues.dbk index 2edb9838..9d7ae1ae 100644 --- a/en/issues.dbk +++ b/en/issues.dbk @@ -203,33 +203,28 @@ $ sudo update-initramfs -u Module configuration for bonding and dummy interfaces - Administrators who are using channel bonding and/or dummy - interfaces (for instance to configure a machine as a router), and - who have set up module parameters in a file under - /etc/modprobe.d, may need to change the name - of the local configuration file used, to avoid these parameters - being ignored after the upgrade to buster. - - - In buster, udev ships a - file /lib/modprobe.d/systemd.conf designed to - make it easier to configure such interfaces using - systemd-networkd. This contains the lines + Systems using channel bonding and/or dummy interfaces, for instance to + configure a machine as a router, may encounter problems upgrading to buster. + New versions of systemd install a + file /lib/modprobe.d/systemd.conf (intended to + simplify configuration via systemd-networkd) which + contains the lines options bonding max_bonds=0 options dummy numdummies=0 - A file in /lib/modprobe.d can be overridden by - one with the same name under /etc/modprobe.d, - but the names are processed in alphabetical order, so - /lib/modprobe.d/systemd.conf follows and - overrides (for instance) - /etc/modprobe.d/dummy.conf. Make sure that any - local configuration file has a name that sorts after - systemd.conf, such as - /etc/modprobe.d/zz-local.conf. + Admins who were depending on different values will need to ensure they are + set in the correct way to take precedence. A file in + /lib/modprobe.d can be overridden by one with the + same name under /etc/modprobe.d, but the names are + processed in alphabetical order, so + /lib/modprobe.d/systemd.conf follows and overrides + (for instance) /etc/modprobe.d/dummy.conf. Make sure + that any local configuration file has a name that sorts after + systemd.conf, such as + /etc/modprobe.d/zz-local.conf.
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Am 29.06.19 um 15:09 schrieb Justin B Rye: > + configure a machine as a router, may encounter problems upgrading to > buster. > + New versions of udev install a That modprobe config file is shipped by the systemd package, not by udev. > A file in > + /lib/modprobe.d can be overridden by one with the > + same name under /etc/modprobe.d, but the names are > + processed in alphabetical order, so That sentence is a bit confusing: files with the same name are overridden. period. there is no but. Are you trying to say that files can be overridden as a whole but usually its better to only override specific settings in a local configuration file which doesn not have the same name? (which is indeed a useful recommendation because future updates of systemd.conf might be missed if you name the file /etc/modprobe.d/systemd.conf). -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Justin B Rye wrote: > Okay, back to the drawing board: I attach a slightly rephrased version with markup. > [...] > > It sounds as if we should also be adding something to the effect that > > With systemd it may be simpler to configure virtual network devices > using a .netdev file - see > "https://www.freedesktop.org/software/systemd/man/systemd.netdev.html#[Bond] > Section Options". I left this out. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package diff --git a/en/issues.dbk b/en/issues.dbk index 2edb9838..d837b921 100644 --- a/en/issues.dbk +++ b/en/issues.dbk @@ -203,33 +203,28 @@ $ sudo update-initramfs -u Module configuration for bonding and dummy interfaces - Administrators who are using channel bonding and/or dummy - interfaces (for instance to configure a machine as a router), and - who have set up module parameters in a file under - /etc/modprobe.d, may need to change the name - of the local configuration file used, to avoid these parameters - being ignored after the upgrade to buster. - - - In buster, udev ships a - file /lib/modprobe.d/systemd.conf designed to - make it easier to configure such interfaces using - systemd-networkd. This contains the lines + Systems using channel bonding and/or dummy interfaces, for instance to + configure a machine as a router, may encounter problems upgrading to buster. + New versions of udev install a + file /lib/modprobe.d/systemd.conf (intended to + simplify configuration via systemd-networkd) which + contains the lines options bonding max_bonds=0 options dummy numdummies=0 - A file in /lib/modprobe.d can be overridden by - one with the same name under /etc/modprobe.d, - but the names are processed in alphabetical order, so - /lib/modprobe.d/systemd.conf follows and - overrides (for instance) - /etc/modprobe.d/dummy.conf. Make sure that any - local configuration file has a name that sorts after - systemd.conf, such as - /etc/modprobe.d/zz-local.conf. + Admins who were depending on different values will need to ensure they are + set in the correct way to take precedence. A file in + /lib/modprobe.d can be overridden by one with the + same name under /etc/modprobe.d, but the names are + processed in alphabetical order, so + /lib/modprobe.d/systemd.conf follows and overrides + (for instance) /etc/modprobe.d/dummy.conf. Make sure + that any local configuration file has a name that sorts after + systemd.conf, such as + /etc/modprobe.d/zz-local.conf.
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
On Vi, 28 iun 19, 14:46:15, Baptiste BEAUPLAT wrote: > On 6/28/19 2:39 PM, Michael Biebl wrote: > > > Would be good to know how Baptiste is setting up those devices. If he is > > doing it manually via some scripting of low level tool or uses a higher > > level network management tool > > Fwiw, with "ip link add dummy0 type dummy" (or "ip link add bond0 type > > bond") I was e.g. able to create such a device manually as well. > > I wonder whether such an approach isn't better then statically setting > > the number of devices via a kernel module option. > > My original setup was: > > echo "dummy" > /etc/modules > > cat << EOF >> /etc/network/interfaces > auto dummy0 > iface dummy0 inet static > address 192.168.64.1 > netmask 24 > EOF > > The interface would pop up configured at boot time (by ifup). Then, I > had services binding on 192.168.64.1. A (quick) look at interfaces(5) doesn't reveal any specific method to create dummy or bond interfaces. In order to keep things within one configuration file it would make sense to use a pre-up with ip commands as suggested above. Would this work *without* overriding the systemd.conf file? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Baptiste BEAUPLAT wrote:
>> Do we have any idea what their use case would be? Apparently a
>> different one from Baptiste's, if it's true that he needed to
>> explicitly configure "numdummies=1"...
>
> In my case, I didn't need to specify the "numdummies=1" as it is the
> default (when systemd override is not installed).
>
> Someone that needed only one interface with bonding or dummy would have
> to just load the module while someone that required more interfaces
> would have to explicitly set numdummies.
Okay, back to the drawing board:
_Module configuration for bonding and dummy interfaces_
Systems using channel bonding and/or dummy interfaces (for instance to
configure a machine as a router) may encounter problems upgrading to buster
due to the file /lib/modprobe.d/systemd.conf now shipped by udev (intended
to simplify configuration via systemd-networkd). This file contains the lines
options bonding max_bonds=0
options dummy numdummies=0
Admins who were depending on different values will need to ensure they are
set in the correct way to take precedence. A file in /lib/modprobe.d can be
overridden by one with the same name under /etc/modprobe.d, but the names
are processed in alphabetical order, so /lib/modprobe.d/systemd.conf follows
and overrides (for instance) /etc/modprobe.d/dummy.conf. Make sure that any
local configuration file has a name that sorts after "systemd.conf", such
as "/etc/modprobe.d/zz-local.conf".
It sounds as if we should also be adding something to the effect that
With systemd it may be simpler to configure virtual network devices
using a .netdev file - see
"https://www.freedesktop.org/software/systemd/man/systemd.netdev.html#[Bond]
Section Options".
but (a) is that odd #fragment-id going to choke docbook? and (b) does
it need any hedging ("using an appropriately de-frobularised version
of systemd-networkd and a .netdev file")?
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
On 6/28/19 2:39 PM, Michael Biebl wrote: > Am 28.06.19 um 12:58 schrieb Justin B Rye: >> Michael Biebl wrote: >>> Afaiu, the kernel default is to create one dummy device by default when >>> the module is loaded. > > .. or bond device, for that matter. > >>> I assume there might be cases where users rely on that default behaviour >>> without having explicitly configured anything. >> >> Do we have any idea what their use case would be? Apparently a >> different one from Baptiste's, if it's true that he needed to >> explicitly configure "numdummies=1"... > > Dunno why Baptiste had to do that. I ended up creating the file to explicitly configure numdummies=1 when I saw that my interfaces disappeared after the upgrade to buster. This "customization" is only necessary when multiple interfaces are required to show on boot. > I just verified that by removing /lib/modprobe.d/systemd.conf, I got the > following when running "modprobe dummy" and "modprobe bonding": > > 6: bond0: mtu 1500 qdisc noop state DOWN > group default qlen 1000 > link/ether 82:e5:b3:41:67:17 brd ff:ff:ff:ff:ff:ff > 7: dummy0: mtu 1500 qdisc noop state DOWN group > default qlen 1000 > link/ether 5e:eb:30:64:69:ef brd ff:ff:ff:ff:ff:ff > > With the modprobe.d config file installed, there obviously was neither a > dummy0 nor bond0 device. > > Fwiw, I know too little about those dummy and bonding devices and how > they are usually used. > E.g. network-manager and networkd seem to create them on the fly as > needed. So I'm not sure, which users will actually be affected by that > change. All users not using networkd and network-manager. Usually servers, just with ifup/ifdown. > Would be good to know how Baptiste is setting up those devices. If he is > doing it manually via some scripting of low level tool or uses a higher > level network management tool > Fwiw, with "ip link add dummy0 type dummy" (or "ip link add bond0 type > bond") I was e.g. able to create such a device manually as well. > I wonder whether such an approach isn't better then statically setting > the number of devices via a kernel module option. My original setup was: echo "dummy" > /etc/modules cat << EOF >> /etc/network/interfaces auto dummy0 iface dummy0 inet static address 192.168.64.1 netmask 24 EOF The interface would pop up configured at boot time (by ifup). Then, I had services binding on 192.168.64.1. I hope this info helps. Best, -- Baptiste BEAUPLAT - lyknode signature.asc Description: OpenPGP digital signature
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Am 28.06.19 um 12:58 schrieb Justin B Rye: > Michael Biebl wrote: >> Afaiu, the kernel default is to create one dummy device by default when >> the module is loaded. .. or bond device, for that matter. >> I assume there might be cases where users rely on that default behaviour >> without having explicitly configured anything. > > Do we have any idea what their use case would be? Apparently a > different one from Baptiste's, if it's true that he needed to > explicitly configure "numdummies=1"... Dunno why Baptiste had to do that. I just verified that by removing /lib/modprobe.d/systemd.conf, I got the following when running "modprobe dummy" and "modprobe bonding": 6: bond0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 82:e5:b3:41:67:17 brd ff:ff:ff:ff:ff:ff 7: dummy0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:eb:30:64:69:ef brd ff:ff:ff:ff:ff:ff With the modprobe.d config file installed, there obviously was neither a dummy0 nor bond0 device. Fwiw, I know too little about those dummy and bonding devices and how they are usually used. E.g. network-manager and networkd seem to create them on the fly as needed. So I'm not sure, which users will actually be affected by that change. Would be good to know how Baptiste is setting up those devices. If he is doing it manually via some scripting of low level tool or uses a higher level network management tool Fwiw, with "ip link add dummy0 type dummy" (or "ip link add bond0 type bond") I was e.g. able to create such a device manually as well. I wonder whether such an approach isn't better then statically setting the number of devices via a kernel module option. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
On 6/28/19 12:58 PM, Justin B Rye wrote: > Michael Biebl wrote: >> Afaiu, the kernel default is to create one dummy device by default when >> the module is loaded. >> I assume there might be cases where users rely on that default behaviour >> without having explicitly configured anything. > > Do we have any idea what their use case would be? Apparently a > different one from Baptiste's, if it's true that he needed to > explicitly configure "numdummies=1"... In my case, I didn't need to specify the "numdummies=1" as it is the default (when systemd override is not installed). Someone that needed only one interface with bonding or dummy would have to just load the module while someone that required more interfaces would have to explicitly set numdummies. -- Baptiste BEAUPLAT - lyknode signature.asc Description: OpenPGP digital signature
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Michael Biebl wrote: > Afaiu, the kernel default is to create one dummy device by default when > the module is loaded. > I assume there might be cases where users rely on that default behaviour > without having explicitly configured anything. Do we have any idea what their use case would be? Apparently a different one from Baptiste's, if it's true that he needed to explicitly configure "numdummies=1"... > Atm, the release note entry reads like only admins who have a modprobe.d > config are possibly affected. That's true. I can't immediately see any way of rephrasing it without making it much more complicated. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Am 27.06.19 um 20:02 schrieb Justin B Rye: > Justin B Rye wrote: >> Okay, so here's a first rough idea of what the release-notes might >> say. > > Properly formatted patch attached. > Afaiu, the kernel default is to create one dummy device by default when the module is loaded. I assume there might be cases where users rely on that default behaviour without having explicitly configured anything. Atm, the release note entry reads like only admins who have a modprobe.d config are possibly affected. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Justin B Rye wrote: > Okay, so here's a first rough idea of what the release-notes might > say. Properly formatted patch attached. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package diff --git a/en/issues.dbk b/en/issues.dbk index 2baac7df..2fdcf7d9 100644 --- a/en/issues.dbk +++ b/en/issues.dbk @@ -199,6 +199,40 @@ $ sudo update-initramfs -u + + +Module configuration for bonding and dummy interfaces/title> + + Administrators who are using channel bonding and/or dummy + interfaces (for instance to configure a machine as a router), and + who have set up module parameters in a file under + /etc/modprobe.d, may need to change the name + of the local configuration file used, to avoid these parameters + being ignored after the upgrade to buster. + + + In buster, udev ships a + file /lib/modprobe.d/systemd.conf designed to + make it easier to configure such interfaces using + systemd-networkd. This contains the lines + + + options bonding max_bonds=0 + options dummy numdummies=0 + + + A file in /lib/modprobe.d can be overridden by + one with the same name under /etc/modprobe.d, + but the names are processed in alphabetical order, so + /lib/modprobe.d/systemd.conf follows and + overrides (for instance) + /etc/modprobe.d/dummy.conf. Make sure that any + local configuration file has a name that sorts after + systemd.conf, such as + /etc/modprobe.d/zz-local.conf. + + + OpenSSL default version and security level raised
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
On 6/27/19 9:20 AM, andreimpope...@gmail.com wrote: > On Jo, 27 iun 19, 00:37:01, Justin B Rye wrote: >> >> Okay, so here's a first rough idea of what the release-notes might >> say. It would make sense to put the new section after the existing >> one on deprecating old-style interface names. Something like: >> >> >> _Module configuration for bonding and dummy interfaces_ >> >> Administrators who are using channel bonding and/or dummy interfaces >> (for instance to configure a machine as a router), and who have set >> up module parameters in a file under /etc/modprobe.d, may need to >> change the name of the local configuration file used, to avoid these >> parameters being ignored after the upgrade to buster. >> >> In buster, udev ships a file /lib/modprobe.d/systemd.conf designed to >> make it easier to configure such interfaces using systemd-networkd.[?] >> This contains the lines >> >> options bonding max_bonds=0 >> options dummy numdummies=0 >> >> A file in /lib/modprobe.d can be overridden by one with the same name >> under /etc/modprobe.d, but the names are processed in alphabetical >> order, so /lib/modprobe.d/systemd.conf follows and overrides (for >> instance) /etc/modprobe.d/dummy.conf. Make sure that any local >> configuration file has a name that sorts after "systemd.conf", such >> as "/etc/modprobe.d/zz-local.conf". > > LGTM FWIW :) > > Kind regards, > Andrei > Looks very nice indeed. The problem is described precisely and the solution is clear. Thanks a lot Justin. Best, -- Baptiste BEAUPLAT - lyknode signature.asc Description: OpenPGP digital signature
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
On Jo, 27 iun 19, 00:37:01, Justin B Rye wrote: > > Okay, so here's a first rough idea of what the release-notes might > say. It would make sense to put the new section after the existing > one on deprecating old-style interface names. Something like: > > > _Module configuration for bonding and dummy interfaces_ > > Administrators who are using channel bonding and/or dummy interfaces > (for instance to configure a machine as a router), and who have set > up module parameters in a file under /etc/modprobe.d, may need to > change the name of the local configuration file used, to avoid these > parameters being ignored after the upgrade to buster. > > In buster, udev ships a file /lib/modprobe.d/systemd.conf designed to > make it easier to configure such interfaces using systemd-networkd.[?] > This contains the lines > > options bonding max_bonds=0 > options dummy numdummies=0 > > A file in /lib/modprobe.d can be overridden by one with the same name > under /etc/modprobe.d, but the names are processed in alphabetical > order, so /lib/modprobe.d/systemd.conf follows and overrides (for > instance) /etc/modprobe.d/dummy.conf. Make sure that any local > configuration file has a name that sorts after "systemd.conf", such > as "/etc/modprobe.d/zz-local.conf". LGTM FWIW :) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Michael Biebl wrote: > Am 26.06.19 um 21:39 schrieb andreimpope...@gmail.com: >> On Mi, 26 iun 19, 20:23:59, Baptiste BEAUPLAT wrote: >>> The only way to force modprobe to use local configuration is to rename >>> the /etc/modprobe.d/dummy.conf file to /etc/modprobe.d/systemd.conf. >> >> Is this documented anywhere else? > > According to the docs in man 5 modules-load.d it should be sufficient to > name the local config so that is sorted after systemd.conf. Okay, so here's a first rough idea of what the release-notes might say. It would make sense to put the new section after the existing one on deprecating old-style interface names. Something like: _Module configuration for bonding and dummy interfaces_ Administrators who are using channel bonding and/or dummy interfaces (for instance to configure a machine as a router), and who have set up module parameters in a file under /etc/modprobe.d, may need to change the name of the local configuration file used, to avoid these parameters being ignored after the upgrade to buster. In buster, udev ships a file /lib/modprobe.d/systemd.conf designed to make it easier to configure such interfaces using systemd-networkd.[?] This contains the lines options bonding max_bonds=0 options dummy numdummies=0 A file in /lib/modprobe.d can be overridden by one with the same name under /etc/modprobe.d, but the names are processed in alphabetical order, so /lib/modprobe.d/systemd.conf follows and overrides (for instance) /etc/modprobe.d/dummy.conf. Make sure that any local configuration file has a name that sorts after "systemd.conf", such as "/etc/modprobe.d/zz-local.conf". -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
On 6/26/19 11:04 PM, Michael Biebl wrote: > Am 26.06.19 um 21:39 schrieb andreimpope...@gmail.com: >> >> On Mi, 26 iun 19, 20:23:59, Baptiste BEAUPLAT wrote: > >>> The only way to force modprobe to use local configuration is to rename >>> the /etc/modprobe.d/dummy.conf file to /etc/modprobe.d/systemd.conf. >> >> Is this documented anywhere else? > > According to the docs in man 5 modules-load.d it should be sufficient to > name the local config so that is sorted after systemd.conf. > > I've opened the bug #931137 [1] directly against kmod. Following the prompt reply from the maintainer, it would appear that it's the only way to go. This is what I'm going to apply to fix the actual issue on my systems. I'll let you decided if this new override from systemd to dummy and bonding modules should be mentioned in the release notes. I would advocate for it since unaware sysadmins (like me) could easly break their network configuration because of that. Best, [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931137 -- Baptiste BEAUPLAT - lyknode signature.asc Description: OpenPGP digital signature
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Am 26.06.19 um 21:39 schrieb andreimpope...@gmail.com: > > On Mi, 26 iun 19, 20:23:59, Baptiste BEAUPLAT wrote: >> The only way to force modprobe to use local configuration is to rename >> the /etc/modprobe.d/dummy.conf file to /etc/modprobe.d/systemd.conf. > > Is this documented anywhere else? According to the docs in man 5 modules-load.d it should be sufficient to name the local config so that is sorted after systemd.conf. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Am 26.06.19 um 21:39 schrieb andreimpope...@gmail.com: > Control: tags -1 moreinfo > > On Mi, 26 iun 19, 20:23:59, Baptiste BEAUPLAT wrote: >> Package: release-notes >> >> Dear maintainers, >> >> Systemd, in buster, will ship the file /lib/modprobe.d/systemd.conf, >> which contains the following: >> >> options bonding max_bonds=0 >> >> # Do the same for dummy0. >> >> options dummy numdummies=0 >> >> This breaks any configuration that an administrator could have added to >> /etc/modprobe.d regarding the dummy and bonding modules. > > Would you have background information on why this is done? > What would be the impact on local configuration (networking unusable, > degraded, etc.)? Assuming this was targeted at pkg-systemd-maintainers, I assume xnox can tell you more. See https://github.com/systemd/systemd/pull/6448 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Hi all, On 6/26/19 9:23 PM, Justin B Rye wrote: > Baptiste BEAUPLAT wrote: >> Systemd, in buster, will ship the file /lib/modprobe.d/systemd.conf, >> which contains the following: >> >> options bonding max_bonds=0 >> >> # Do the same for dummy0. >> >> options dummy numdummies=0 >> >> This breaks any configuration that an administrator could have added to >> /etc/modprobe.d regarding the dummy and bonding modules. > > We need more information about why an administrator might have done > this, since otherwise for a start it's impossible to guess what would > go wrong as a result. VMs with sabotaged networking, or what? Is > there some other bugreport where we could read about these symptoms? The dummy module can be used to create virtual interfaces, that can then be configured for a particular use. I've seen it a couple of times, usually for router or vpn box. It would allow to bind some services especially for that virtual interface. I stumble across this bug just as of today, while testing the upgrade to buster. I don't think there is yet other bug report on it. If you think that release-notes is not the place and that I should report it to another package, I don't mind at all reassigning it. > >> For instance, a file in /etc/modprobe.d/dummy.conf containing: >> >> options dummy numdummies=1 >> >> Will result in the following being executed by modprobe: >> >> insmod /lib/modules/4.19.0-5-amd64/kernel/drivers/net/dummy.ko >> numdummies=1 numdummies=0 >> >> And the original configuration will be overridden. >> >> The only way to force modprobe to use local configuration is to rename >> the /etc/modprobe.d/dummy.conf file to /etc/modprobe.d/systemd.conf. > > This overrides the /lib/modprobe.d/systemd.conf entirely, doesn't it? > In which case you'd lose any other things in that file that systemd > might be depending on. Checking on a Buster box I see it also defines > "options bonding max_bonds=0" - if I want to avoid overriding that, > would it be better to use a name like /etc/modprobe.d/zz-local.conf? The current problem is the actual processing order of modprobe. It should be /lib/modprobe.d then /etc/modprobe.d. Currently, it merges both directories and then do the sorting. The 'ill' effect is that it processes /lib/modprobe.d/systemd.conf _after_ /etc/aa-systemd.conf, overwritting its content. I now realize that I should have reported the issue directly against modprobe. I don't think it will be fixed in time for buster release, so it might be still useful to have the info on the release notes. >> I thinks this should be documented in the release notes as admins would >> need to be aware of that. > > And/or quite possibly about max_bonds=0? I'm afraid I know even less > about what symptoms that might have. > I'll open a new bug against modprobe with a better explaining of the problem. I'll wait for maintainers' reply and see then. Thanks for your quick replies, Best, -- Baptiste BEAUPLAT - lyknode signature.asc Description: OpenPGP digital signature
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Control: tags -1 moreinfo On Mi, 26 iun 19, 20:23:59, Baptiste BEAUPLAT wrote: > Package: release-notes > > Dear maintainers, > > Systemd, in buster, will ship the file /lib/modprobe.d/systemd.conf, > which contains the following: > > options bonding max_bonds=0 > > # Do the same for dummy0. > > options dummy numdummies=0 > > This breaks any configuration that an administrator could have added to > /etc/modprobe.d regarding the dummy and bonding modules. Would you have background information on why this is done? What would be the impact on local configuration (networking unusable, degraded, etc.)? > For instance, a file in /etc/modprobe.d/dummy.conf containing: > > options dummy numdummies=1 > > Will result in the following being executed by modprobe: > > insmod /lib/modules/4.19.0-5-amd64/kernel/drivers/net/dummy.ko > numdummies=1 numdummies=0 > > And the original configuration will be overridden. > > The only way to force modprobe to use local configuration is to rename > the /etc/modprobe.d/dummy.conf file to /etc/modprobe.d/systemd.conf. Is this documented anywhere else? > I thinks this should be documented in the release notes as admins would > need to be aware of that. Thanks, Andrei - not a Release Notes Maintainer, just anticipating what information might be necessary to write a useful entry. -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Baptiste BEAUPLAT wrote: > Systemd, in buster, will ship the file /lib/modprobe.d/systemd.conf, > which contains the following: > > options bonding max_bonds=0 > > # Do the same for dummy0. > > options dummy numdummies=0 > > This breaks any configuration that an administrator could have added to > /etc/modprobe.d regarding the dummy and bonding modules. We need more information about why an administrator might have done this, since otherwise for a start it's impossible to guess what would go wrong as a result. VMs with sabotaged networking, or what? Is there some other bugreport where we could read about these symptoms? > For instance, a file in /etc/modprobe.d/dummy.conf containing: > > options dummy numdummies=1 > > Will result in the following being executed by modprobe: > > insmod /lib/modules/4.19.0-5-amd64/kernel/drivers/net/dummy.ko > numdummies=1 numdummies=0 > > And the original configuration will be overridden. > > The only way to force modprobe to use local configuration is to rename > the /etc/modprobe.d/dummy.conf file to /etc/modprobe.d/systemd.conf. This overrides the /lib/modprobe.d/systemd.conf entirely, doesn't it? In which case you'd lose any other things in that file that systemd might be depending on. Checking on a Buster box I see it also defines "options bonding max_bonds=0" - if I want to avoid overriding that, would it be better to use a name like /etc/modprobe.d/zz-local.conf? > I thinks this should be documented in the release notes as admins would > need to be aware of that. And/or quite possibly about max_bonds=0? I'm afraid I know even less about what symptoms that might have. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Justin B Rye wrote: > Checking on a Buster box I see it also defines > "options bonding max_bonds=0" Oh, yes, you already said that! But anyway: what are the ill effects? -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd
Package: release-notes Dear maintainers, Systemd, in buster, will ship the file /lib/modprobe.d/systemd.conf, which contains the following: options bonding max_bonds=0 # Do the same for dummy0. options dummy numdummies=0 This breaks any configuration that an administrator could have added to /etc/modprobe.d regarding the dummy and bonding modules. For instance, a file in /etc/modprobe.d/dummy.conf containing: options dummy numdummies=1 Will result in the following being executed by modprobe: insmod /lib/modules/4.19.0-5-amd64/kernel/drivers/net/dummy.ko numdummies=1 numdummies=0 And the original configuration will be overridden. The only way to force modprobe to use local configuration is to rename the /etc/modprobe.d/dummy.conf file to /etc/modprobe.d/systemd.conf. I thinks this should be documented in the release notes as admins would need to be aware of that. Best, -- Baptiste BEAUPLAT - lyknode signature.asc Description: OpenPGP digital signature
