Bug#924575: systemd-networkd doesn't process IPv6 RA properly
> On 15 Mar 2019, at 08:37, Johan Wassberg wrote: > >> (would be great if you cant test this version and report back) > > Will see what we can accomplish in the lab! systemd(-networkd) 241-1~bpo9+1 from stretch-backports seems to work better. The expiration is now present in the output from `ip -6 r` and the route is discarded when the timer runs out: ``` 2001:dead:5:1219::/64 dev ens33 proto ra metric 1024 expires 2591574sec pref medium fe80::/64 dev ens33 proto kernel metric 256 pref medium default via fe80::209:fff:fe09:5 dev ens33 proto ra metric 1024 expires 1374sec mtu 1500 pref medium ``` But both the new version of systemd-networkd and the default network service "networking" (not sure of the official name is) will add more then one default route if the router advertise this. Is this a feature or a bug? It is not possible to and another default route via `ip -6 route`: ``` # ip -6 route add default via default via fe80::dead:beef:dead:beef dev ens33 RTNETLINK answers: File exists ``` Still curious, is systemd-networkd in stretch-backports considered stable? -- jocar signature.asc Description: Message signed with OpenPGP
Bug#924575: systemd-networkd doesn't process IPv6 RA properly
Thanks for a fast reply! > On 14 Mar 2019, at 15:31, Michael Biebl wrote: > > Hi > > Am 14.03.19 um 15:16 schrieb Johan Wassberg: >> Package: systemd >> Version: 232-25+deb9u9 >> Severity: important >> >> Dear Maintainer, >> this issue is a bit outside my confort zone but I still want to try to >> report this bug. >> >> It is probably the same as Launchpad#1800836[0] and according to that >> ticket the issue fixed in a new version of systemd. But for all of us >> that are stuck with Stretch for some years to come it would be great if >> someone could look in to the issue and backport the fix. > > networkd in stretch I would cosider a tech-preview. > It will probably work for simple cases, but is known to have limitations. > If you want to rely on networkd for more complex setups in stretch, Wish we known this back in Xenial when we for some reason I can't remember decided to switch to networkd… > I > would actually recommend that you use the backport of v241 that we > provide via stretch-backports. Is version 241 of networkd considered stable or is it still a tech-preview? > (would be great if you cant test this version and report back) Will see what we can accomplish in the lab! -- jocar signature.asc Description: Message signed with OpenPGP
Bug#924575: systemd-networkd doesn't process IPv6 RA properly
Package: systemd Version: 232-25+deb9u9 Severity: important Dear Maintainer, this issue is a bit outside my confort zone but I still want to try to report this bug. It is probably the same as Launchpad#1800836[0] and according to that ticket the issue fixed in a new version of systemd. But for all of us that are stuck with Stretch for some years to come it would be great if someone could look in to the issue and backport the fix. The problem seems to be that systemd-networkd doesn't expire or take note of the RA Default Lifetime. In older OSes (or Stretch without systemd-networkd) you could see the expiration of the default route: ``` $ ip -6 r 2001:6b0:5:1568::/64 dev ens192 proto kernel metric 256 expires 2591756sec pref medium fe80::/64 dev ens192 proto kernel metric 256 pref medium default via fe80::209:fff:fe09:5 dev ens192 proto ra metric 1024 expires 1556sec pref medium ``` but with systemd-networkd that information is lost: ``` ip -6 r 2001:6b0:5:1219::/64 dev ens33 proto ra metric 1024 pref medium fe80::/64 dev ens33 proto kernel metric 256 pref medium default via fe80::209:fff:fe09:5 dev ens33 proto ra metric 1024 mtu 1500 pref medium ``` My quess is that this is not an display issue since we can reproduce the same behavior as in Launchpad#1800836[0]: Multiple default routes after a firewall failover. Multiple default routes causes strange connection errors. After failover with systemd-networkd: ``` ip -6 r 2001:6b0:5:1219::/64 dev ens33 proto ra metric 1024 pref medium fe80::/64 dev ens33 proto kernel metric 256 pref medium default via fe80::209:fff:fe09:5 dev ens33 proto ra metric 1024 mtu 1500 pref medium default via fe80::724c:a5ff:fe58:42a2 dev ens33 proto ra metric 1024 mtu 1500 pref medium ``` After failover without systemd-networkd: ``` ip -6 r 2001:6b0:5:1568::/64 dev ens192 proto kernel metric 256 expires 2591536sec pref medium fe80::/64 dev ens192 proto kernel metric 256 pref medium default via fe80::209:fff:fe09:5 dev ens192 proto ra metric 1024 expires 1336sec pref medium ``` Let me know if there is any other information I can provide to help out. [0] https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1800836 -- Package-specific info: -- System Information: Debian Release: 9.8 APT prefers stretch-updates-test APT policy: (500, 'stretch-updates-test'), (500, 'stretch-security-test'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.115 ii libacl1 2.2.52-3+b1 ii libapparmor12.11.0-3+deb9u2 ii libaudit1 1:2.6.7-2 ii libblkid1 2.29.2-1+deb9u1 ii libc6 2.24-11+deb9u4 ii libcap2 1:2.25-1 ii libcryptsetup4 2:1.7.3-4 ii libgcrypt20 1.7.6-2+deb9u3 ii libgpg-error0 1.26-2 ii libidn111.33-1 ii libip4tc0 1.6.0+snapshot20161117-6 ii libkmod223-2 ii liblz4-10.0~r131-2+b1 ii liblzma55.2.2-1.2+b1 ii libmount1 2.29.2-1+deb9u1 ii libpam0g1.1.8-3.6 ii libseccomp2 2.3.1-2.1+deb9u1 ii libselinux1 2.6-3+b3 ii libsystemd0 232-25+deb9u9 ii mount 2.29.2-1+deb9u1 ii procps 2:3.3.12-3+deb9u1 ii util-linux 2.29.2-1+deb9u1 Versions of packages systemd recommends: ii dbus1.10.26-0+deb9u1 ii libpam-systemd 232-25+deb9u9 Versions of packages systemd suggests: pn policykit-1 pn systemd-container pn systemd-ui Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.130 ii udev 232-25+deb9u9 -- no debconf information
Bug#880393: libsasl2-modules-gssapi-heimdal seems built against MIT - Buster?
Hi again! Will the patch from Helmut be included in Buster and make this library useful again? -- jocar
Bug#878162: fixed in systemd 232-25+deb9u2
Seems like it has been fixed in #892794 - great! -- jocar > On 13 Mar 2018, at 09:42, Johan Wassberg wrote: > > On Sat, 10 Mar 2018 23:13:21 -0800 Rob Leslie wrote: >> The fix for this bug broke the IPv6 networking on one of my systems. >> >> When the RA does not include any MTU information, this patch causes no IPv6 >> default route to be added at all, leaving the system without IPv6 >> connectivity. The journal in this case shows: >> >> systemd-networkd[397]: eno1: Failed to get default router MTU from RA: No >> data available >> >> A workaround is to add MTU information to the RA from the router, but I >> don’t think this should be necessary. > > We can confirm that the change broke IPv6 on all our updated Stretch > machines: > > 2018-03-13T08:25:24.671634+01:00 machine.example.com systemd-networkd[286]: > ens192: Failed to get default router MTU from RA: No data available > > ``` > $ sysctl -a |grep "accept_ra = " > net.ipv6.conf.all.accept_ra = 1 > net.ipv6.conf.default.accept_ra = 1 > net.ipv6.conf.ens192.accept_ra = 0 > net.ipv6.conf.lo.accept_ra = 1 > ``` > > The sysctl output shows that "accept_ra" is enabled for all entries except > for the first physical interface. > > Manually setting "accept_ra" to "1" allows us to get a default route, > but restarting systemd-networkd changes it back to 0. > > -- > jocar
Bug#878162: fixed in systemd 232-25+deb9u2
On Sat, 10 Mar 2018 23:13:21 -0800 Rob Leslie wrote: > The fix for this bug broke the IPv6 networking on one of my systems. > > When the RA does not include any MTU information, this patch causes no IPv6 > default route to be added at all, leaving the system without IPv6 > connectivity. The journal in this case shows: > > systemd-networkd[397]: eno1: Failed to get default router MTU from RA: No > data available > > A workaround is to add MTU information to the RA from the router, but I don’t > think this should be necessary. We can confirm that the change broke IPv6 on all our updated Stretch machines: 2018-03-13T08:25:24.671634+01:00 machine.example.com systemd-networkd[286]: ens192: Failed to get default router MTU from RA: No data available ``` $ sysctl -a |grep "accept_ra = " net.ipv6.conf.all.accept_ra = 1 net.ipv6.conf.default.accept_ra = 1 net.ipv6.conf.ens192.accept_ra = 0 net.ipv6.conf.lo.accept_ra = 1 ``` The sysctl output shows that "accept_ra" is enabled for all entries except for the first physical interface. Manually setting "accept_ra" to "1" allows us to get a default route, but restarting systemd-networkd changes it back to 0. -- jocar
Bug#781100: libpam-modules: pam_exec.so quiet still logging errors to syslog
On Tue, 24 Mar 2015 14:40:36 +0100 Simon Ruderich wrote: > Package: libpam-modules > Version: 1.1.8-3.1 > Severity: normal > > Dear Maintainer, > > I'm using pam_exec.so with the quiet option (/bin/false is just > an example of a program with exit code 1): > > session [system_err=ignore default=1] pam_exec.so quiet /bin/false > > The man page says the following about quiet: > > quiet > Per default pam_exec.so will echo the exit status of the > external command if it fails. Specifying this option will > suppress the message. > > However the following is still logged: > > Mar 24 14:34:32 host kdm: :1[4351]: pam_exec(kdm:session): /bin/false > failed: exit code 1 > > I'd expect no error to be logged as mentioned in the man page. > This issue still exists in Stretch, libpam-modules 1.1.8-3.6. Has anyone looked in to this? -- jocar
Bug#879916: Debian mirror debian.mirror.su.se: inconsistent view between backends - SRQ-1283517
> On 31 Oct 2017, at 12:17, Bastian Blank wrote: > > Hi Johan > > On Mon, Oct 30, 2017 at 01:27:50PM +, Johan Wassberg wrote: >>> If you load balance behind a single name, is there any way you can >>> ensure that all instances provide the same content? >> Yes, the service is load balanced between two hosts. I didn't thought >> that should be a problem. > > It's no problem. We just flag that as irregularities as the contents > are not the same, even if almost the same. > >> How do you normally handle this kind of issues? > > Each backend system gets it's own mirror name configured in > ftpsync.conf. The backends can be reached directly. How they can be > reached is not important; we have the following mechanisms in the wild: > - The mirrors have public IP on their own and can be reached using it, > - the load balancer exposes the systems directly by name, and > - the load balancer exposes the systems by using different ports. > > We will add entries for each backend to our internal mirror list and > make the public name an alias. We then check each system seperately, so > we can asses the health of each one. For examples see: > https://mirror-master.debian.org/status/mirror-status.html#&sort[results]=0-0&filter[results]=azure.com > https://mirror-master.debian.org/status/mirror-status.html#&sort[results]=0-0&filter[results]=kernel.org > > Depending on the importance of the mirror we have a bunch of other > things we use to make sure they are in sync, but this does not need to > concern you. > >> 2. Allow http access directly to the machines without the load balancer. > > For now we would like to start with this one. You have to select names > for both mirrors and ways to access them. Currently the backends are > named mirror-prod-debian0[12].it.su.se and are published in DNS with > public IP. So you could set MIRRORNAME in ftpsync.conf to that hostname > and allow access to the IP from the outside. Done. The two hosts that serves "debian.mirror.it.su.se" is now accessable from anywhere and the MIRRORNAME is set correctly. mirror-prod-debian01.it.su.se mirror-prod-debian02.it.su.se Please updated your internal tools. -- jocar
Bug#880393: libsasl2-modules-gssapi-heimdal seems built against MIT
Package: libsasl2-modules-gssapi-heimdal Version: 2.1.27~101-g0780600+dfsg-3 Severity: important Dear Maintainer, I think something is fishy with the package "libsasl2-modules-gssapi-heimdal". I suspect that the package is built against MIT instead of Heimdal. Trying to migrate a Xenial machine to Stretch I noticed a difference in behavior when using `saslauthd` in a Postfix chroot - configs that haven't been required before was now required and `saslauthd` is complaing about settings that I have never seen with our previous setup. We have always used the Heimdal Kerberos libraries and therefore always used "libsasl2-modules-gssapi-heimdal" for `saslauthd`. Couldn't find any upstream changes in either Heimdal or Cyrus SASL which would explain my issuses so I went digging in the Debian package instead. Found that Heimdal was ripped out from the package(s) in October 24 2016: * 004977091b89363daa04301e89a045e7e2ffbad8 * b9158ab7d2bc71a026d417982fee61bc854935f4 * b334c34bce70f20d85ef0e86e79c6310b69f7345 And added again on Dec 31: * f382638d18a1e1e75560076d0cb1482e0b4dc613 Unfortunately the package(s) has moved a lot between removal and reinstatement so I can't get a clean diff over the changes. But I suspect that the reinstatement didn't go as planned. >From Jessie: ``` # dpkg -S /usr/lib/x86_64-linux-gnu/sasl2/libgssapiv2.so.2.0.25 libsasl2-modules-gssapi-heimdal:amd64: /usr/lib/x86_64-linux-gnu/sasl2/libgssapiv2.so.2.0.25 # ldd /usr/lib/x86_64-linux-gnu/sasl2/libgssapiv2.so.2.0.25 linux-vdso.so.1 (0x7fffc877e000) libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 (0x7fd5b206a000) libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 (0x7fd5b1ddb000) libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 (0x7fd5b1b2b000) libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 (0x7fd5b1915000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x7fd5b16de000) libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x7fd5b12e1000) libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x7fd5b10dd000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7fd5b0ec6000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fd5b0b1a000) libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 (0x7fd5b0911000) libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 (0x7fd5b06dc000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fd5b04be000) libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 (0x7fd5b0295000) libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 (0x7fd5b0086000) libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 (0x7fd5afe39000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7fd5afb7) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fd5af96c000) /lib64/ld-linux-x86-64.so.2 (0x7fd5b24ba000) # strings /usr/lib/x86_64-linux-gnu/sasl2/libgssapiv2.so.2.0.25 | egrep "MIT|HEIM" HEIMDAL_GSS_2.0 ``` >From Ubuntu Xenial: ``` # dpkg -S /usr/lib/x86_64-linux-gnu/sasl2/libgssapiv2.so.2.0.25 libsasl2-modules-gssapi-heimdal:amd64: /usr/lib/x86_64-linux-gnu/sasl2/libgssapiv2.so.2.0.25 # ldd /usr/lib/x86_64-linux-gnu/sasl2/libgssapiv2.so.2.0.25 linux-vdso.so.1 => (0x7ffd967d4000) libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 (0x7f818c61c000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f818c252000) libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 (0x7f818c048000) libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 (0x7f818bdbe000) libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 (0x7f818bb1c000) libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x7f818b917000) libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 (0x7f818b6e4000) libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 (0x7f818b4ce000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f818b2b) /lib64/ld-linux-x86-64.so.2 (0x559426341000) libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 (0x7f818b087000) libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 (0x7f818ae78000) libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 (0x7f818ac2c000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f818a957000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x7f818a71f000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f818a51a000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f818a2ff000) # strings /usr/lib/x86_64-linux-gnu/sasl2/libgssap
Bug#879916: Debian mirror debian.mirror.su.se: inconsistent view between backends - SRQ-1283517
> If you look at our monitoring result page for your mirror right now: > > https://mirror-master.debian.org/status/mirror-info/debian.mirror.su.se.html > > you'll notice that our script sees two different trace files from your > mirror, alternatingly. > > One from 2017-10-27 04:21:39 and one from 2017-10-27 04:21:40. > > If you load balance behind a single name, is there any way you can > ensure that all instances provide the same content? Yes, the service is load balanced between two hosts. I didn't thought that should be a problem. > > Alternatively, is there a way we can access the backends indivually for > our checks? We can go either way, which ever you prefer. 1. Set up a master-slave senario where we only sync upstream from one of our machines and only front machines that are up to date. 2. Allow http access directly to the machines without the load balancer. How do you normally handle this kind of issues? -- jocar
Bug#878727: mirror submission for debian.mirror.su.se
> On 17 Oct 2017, at 15:42, Peter Palfrader wrote: > > On Tue, 17 Oct 2017, Johan Wassberg wrote: > >> >> >>> On 16 Oct 2017, at 13:28, Peter Palfrader wrote: >>> >>> On Mon, 16 Oct 2017, Johan Wassberg wrote: >>> >>>> Maintainer: Johan Wassberg >>> >>> Is there a role account we should also put on record? >> >> I'm not sure what that means. Could you please explain? > > jocar@ is presumably your personal email address? We wonder if there is > an address like ftpadm@ or mirrors@ that will always be responsible for > the mirror, even after you move on to other responsibilities. > Yes that's correct. I have now arranged a role account, debian-mir...@it.su.se. Please add it to our record. Sorry about the delay (internal politics)… -- jocar
Bug#878727: mirror submission for debian.mirror.su.se
> On 16 Oct 2017, at 13:28, Peter Palfrader wrote: > > On Mon, 16 Oct 2017, Johan Wassberg wrote: > >> Maintainer: Johan Wassberg > > Is there a role account we should also put on record? I'm not sure what that means. Could you please explain? -- jocar
Bug#878727: mirror submission for debian.mirror.su.se
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: debian.mirror.su.se Type: leaf Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x Archive-http: /debian/ Maintainer: Johan Wassberg Country: SE Sweden Location: Stockholm Sponsor: Stockholm University https://www.su.se Trace Url: http://debian.mirror.su.se/debian/project/trace/ Trace Url: http://debian.mirror.su.se/debian/project/trace/ftp-master.debian.org Trace Url: http://debian.mirror.su.se/debian/project/trace/debian.mirror.su.se
