Re: Advising in packages to load new module or reboot
On Wed 2017-08-09 13:16:45 +0200, Egbert Verhage wrote: > Ow, that it is a common problem. > I think your patch is a nice updated. > > So I got some time left and build a patch (pull request) on github > here: https://github.com/EggieCode/wireguard-ppa/pull/24 thanks for writing this notification, Jason, and for including it in your ubuntu ppa, Egbert. I'm wondering whether the advice it gives is correct and thorough enough for non-gentoo users, though. If i "rmmod wireguard && modprobe wireguard" won't my configuration be lost? You point out that you might want to tear them down gracefully first. But then no mention of needing to bring them up again later? Aren't there additional commands that the admin will have to do to have a *functional* wireguard implementation, and those commands might differe based on their userspace layout/configuration/policy? The simplest instruction for the upgrade (which is probably offensive to all of us here) is to say "you should reboot your machine for the wireguard upgrade to take effect" -- that gets us the benefit of any userspace wireguard configuration that happens during system initialization to happen, without having to guess/poke/prod at the user's networking config while live. Also, for an administrator doing this over ssh, we might want to warn them that taking these steps will lock them out if they're connecting via ssh on top of wireguard, right? --dkg ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Advising in packages to load new module or reboot
Hey Jason, Ow, that it is a common problem. I think your patch is a nice updated. So I got some time left and build a patch (pull request) on github here: https://github.com/EggieCode/wireguard-ppa/pull/24 Let me known what you think. Greetz, Egbert On Wed, 2017-08-09 at 01:16 +0200, Jason A. Donenfeld wrote: > Hey guys, > > I've noticed that around 60% of emails and IRC messages I get about > WireGuard issues are due to: > > 1) forgetting to `rmmod wireguard && modprobe wireguard` after > updating > 2) installing new kernel headers, removing old kernel headers, > updating >wireguard, and then having the module built for the newer kernel > and >forgetting to reboot > 3) not having any headers installed > > I don't really know the best generic solution for (3), since > different > distros and distro-derivatives (armbian,raspian,archlinuxarm,etc) > seem > to express these dependencies in different ways, or not at all. But I > do > have an idea to pretty easily address (1) and (2). I've just added > the > below to the Gentoo ebuild: > > + if [[ $(uname -r) != "${KV_FULL}" ]]; then > + ewarn > + ewarn "You have just built WireGuard for kernel ${KV_FULL}, > yet the currently running" > + ewarn "kernel is $(uname -r). If you intend to use this > WireGuard module on the currently" > + ewarn "running machine, you will first need to reboot it > into the kernel ${KV_FULL}, for" > + ewarn "which this module was built." > + ewarn > + elif [[ -f /sys/module/wireguard/version ]] && \ > + old="$(< /sys/module/wireguard/version)" && \ > + new="$(modinfo -F version > "${ROOT}/lib/modules/${KV_FULL}/net/wireguard.ko" 2>/dev/null)" && \ > + [[ $old != "$new" ]]; then > + ewarn > + ewarn "You appear to have just upgraded WireGuard from > version v$old to v$new." > + ewarn "However, the old version is still running on your > system. In order to use the" > + ewarn "new version, you will need to remove the old module > and load the new one. As" > + ewarn "root, you can accomplish this with the following > commands:" > + ewarn > + ewarn "# rmmod wireguard" > + ewarn "# modprobe wireguard" > + ewarn > + ewarn "Do note that doing this will remove current > WireGuard interfaces, so you may want" > + ewarn "to gracefully remove them yourself prior." > + ewarn > + fi > > There's a bit of Gentoo-specific stuff in there, but the general idea > is > that I first check to see if the module is being built for the > current > kernel or a different one, and then I check whether an older module > is > loaded than the one just built. It might be slightly trickier to > accomplish this with DKMS, but I think still it's possible. > > Any thoughts on this pattern? > > Jason ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Advising in packages to load new module or reboot
On Wed, 9 Aug 2017 01:30:50 +0200 "Jason A. Donenfeld"wrote: > That might mean printing nice messages if the correct dependency isn't > obvious. > > For (1) and (2), though, what do you think of the warning I've added > to Gentoo? That's what I meant by asking for thoughts on "this > pattern" -- the whole thing with comparing running kernel and > compiled-for-kernel and comparing loaded-module-version and > compiled-module-version. I found something that _may_ help you, it's an old bug report on DKMS. As far as I understand it, it is DKMS' work to issue a warning: https://github.com/dell/dkms/issues/14 Jean-Yves ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Advising in packages to load new module or reboot
On Wed, Aug 9, 2017 at 1:27 AM, Jonathon Fernyhoughwrote: > On 09/08/17 00:16, Jason A. Donenfeld wrote: >> 3) not having any headers installed >> > ... >> >> Any thoughts on this pattern? >> > > I suspect this would be a packaging issue - packages that build modules > should depend on whatever headers (etc.) that are necessary for building > the module. I can't think of any distro where that isn't the norm, and > it's not normally up to the upstream developers to check those things > (they provide the software source, packagers provide something that > works specifically with the distro). Right. So this is all item (3) stuff. I agree with you there -- packages need to express the dependencies in whatever way they can. That might mean printing nice messages if the correct dependency isn't obvious. For (1) and (2), though, what do you think of the warning I've added to Gentoo? That's what I meant by asking for thoughts on "this pattern" -- the whole thing with comparing running kernel and compiled-for-kernel and comparing loaded-module-version and compiled-module-version. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Advising in packages to load new module or reboot
On 09/08/17 00:16, Jason A. Donenfeld wrote: > 3) not having any headers installed > ... > > Any thoughts on this pattern? > I suspect this would be a packaging issue - packages that build modules should depend on whatever headers (etc.) that are necessary for building the module. I can't think of any distro where that isn't the norm, and it's not normally up to the upstream developers to check those things (they provide the software source, packagers provide something that works specifically with the distro). OTOH, if people are installing from source and expecting to be able to build a kernel module without kernel headers... that's a user-education issue. J signature.asc Description: OpenPGP digital signature ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard