Arch Linux User Repository

MANJARO USERS, READ ME

Manjaro does not create the /usr/src/linux symlink, which should point to the current kernel headers and is required for this package to build properly. If you wish to use this package, your options are to:

1. Manually edit the PKGBUILD before building and change the KDIR variable in build() to point to your kernel headers.

2. Create a pacman hook for the kernel header package which creates the symbolic link automatically. An example can be seen in this comment: https://aur.archlinux.org/packages/opensnitch-ebpf-module?O=30#comment-919081

This is the latest RELEASE version of opensnitch's eBPF module. It is meant to be used with the regular opensnitch package, not the -git version in the AUR. If you're using the -git version of opensnitch, you're looking for this version of the eBPF module package instead.

I intend to keep this up to date with the OpenSnitch releases (as soon as the main package updates).

Right, that makes sense. Since I'm depending on linux-headers anyways, I can modify the PKGBUILD to use that specifically and not the symlink. Although the symlink is by far the easiest method to build against the current kernel headers (especially if the kernel package has been upgraded but the system is still running on an older kernel), I guess it would be possible to use some heuristics to build against the latest headers.

It does work OK, but I think it uses linux-lts-headers (due to KERNEL_DIR="$KDIR" KERNEL_HEADERS="$KDIR") which I also have. The problem is that currently either having or forcing not to have linux-headers installed can both be problematic in linux-lts systems. Thinking about it the issue could actually be in linux-lts not providing linux.

Does the eBPF module not work on the LTS kernel when compiled against linux-headers?

This package works with linux-lts, but it should depend on linux-lts-headers in this case. Everything else works fine.

Yeah I get that so do I. Thanks for maintaining the PKGBUILD.

Regards, Mark.

I do actually have a notifier bot set up to let me know when the main repo package updates, but since opensnitch is updated so rarely, I had forgotten about it. I haven't fully automated the updating of this package because I like manually ensuring it builds and functions as expected.

Oh right yeah. I knew pinning was generally a "bad idea" but didn't think it through. Those scenarios do indeed make it problematic, especially with one in the AUR and the other in the main repos... As I perform upgrades with paru I always have everything updated together, but that can't be assumed for sure. I guess the only way to go really is for you to closely watch when opensnitch arch packages is actually updated and only do your own version bump them. Could be automated if you want too, with github actions or something like that.

marcool04: Whoops, updating it was my bad. Someone flagged this package out of date since 1.6.5 was released upstream - I forgot to check whether the Arch package had been updated before bumping this package's version.

I don't think pinning it is a good idea, as I think it will break upgrades for people who try updating their system when a new version of the opensnitch package is released but I haven't had a chance to bump this package yet. Also, I'm unsure how this would affect upgrades even if both are updated - pacman isn't aware that this package would be upgraded alongside opensnitch and I think would complain about breaking dependencies when trying to upgrade opensnitch. Maybe someone can correct me on this.

Just a note that as you have updated the pkgver here but the opensnitch package is still on 1.6.4 there are issues when performing a full system upgrade as that leaves you with a mismatch in versions. See here: https://github.com/evilsocket/opensnitch/issues/1099. Is it possible to pin this to the same version of opensnitch with a depends=(opensnitch=$pkgver), would that be safe?

The new kernel doesn't seem to be supported, received an error message stating that.

Edit: But it seems to be still working, strange.