Slackware 14.1 best solution for non-standard Kernel needs....

OK, long time lurker, new poster, please bear with me!

We're in the process of migrating our Firewall server from (so old I don't want to admit to it) to Slackware64 14.1, and I've hit a problem:

Since we're intending to run Snort inline as an IPS, using NF_QUEUE, we need a specific feature of NF_QUEUE (--queue-bypass) which was buggy in kernels 3.10 -> 3.12.

We don't want to go to 14.2 (many reasons, but trust me, they're good ones) and none of the stock kernels for 14.1 have the fix (3.10.xxxx).

One of the reasons for the upgrade is that the previous server depended on a custom kernel build that made it very difficult to support, so we're wary about going down the same route again...

So, what is the "Slackware way" of doing this?

I've considered trying the 14.2 kernel, but I'm concerned about issues from it being built with the 14.2 libraries....

Even if I do a custom kernel build, I'm not really sure which kernel to pick - though anything later than 3.12 should be OK, I'm aware from past experience that some of the kernel versions are real dogs, and may well cause more problems than they solve...

We're really trying to make things more supportable and upgradeable, so we're trying to use packages for everything, but there seems little advice over how to build *and package* a custom kernel, and, of course, we'd still. effectively, be managing our own kernel build that way...

Suggestions?

Thanks!

If you need a kernel feature that the stock Slackware kernels don't include then there's no choice, you'll have to build a custom one. There's no way around that.

As for quality of various kernel branches, it's a crapshoot. Owing to the nature of the upstream development model the so called 'stable' and 'long-term' branches are just as likely to be a victim of regression as the most recent branch (and arguably even more so).

Only advice I can give is script the process. There's no reason a kernel build/upgrade has to be an onerous task.


Final thought: Have you considered OpenBSD? That's a common and well respected platform for use as a firewall.

Originally Posted by SlackBear I've considered trying the 14.2 kernel, but I'm concerned about issues from it being built with the 14.2 libraries....

You're worried about nothing. Kernels have no library dependencies of any kind.

Empirically, you can use the official Slackware 14.2 kernels fine in 14.1. I seem to remember someone even successfully using the -current kernel with 13.37 or 13.1 or something but can't find the linkie atm

I'm using a -current kernel on my 14.1 box without any issues. Just make sure you also install the companion packages like kernel-modules and kernel-source. There is some debate on whether you should upgrade your kernel-headers package, but I tend to just leave mine alone (because that used to be the recommendation and I'm stuck in my old ways). However, I believe Pat, semi-recently, posted that he doesn't see any reason why you couldn't upgrade the kernel-headers package... but I'm too lazy to search for it to back up my claim

Originally Posted by 55020 You're worried about nothing. Kernels have no library dependencies of any kind. Empirically, you can use the official Slackware 14.2 kernels fine in 14.1. I seem to remember someone even successfully using the -current kernel with 13.37 or 13.1 or something but can't find the linkie atm

I guess my concern wasn't so much the libraries themselves, as the glibc headers, which, in my simplistic mind, I assumed probably defined some of the data structures that were passed from userland to kernelspace - but I'll be honest, I'm only vaguely familiar with how the syscall interface works in Linux, though I guess it has to be some variation of the System-V "one software interrupt plus a magic number in a register" that all the other systems seem to use.

If people have successfully mixed kernel versions in this way, then that looks like a good option, as we'd get a supported kernel, ability to install as a package, and security updates without having to type "make menuconfig", which is sort of where we are trying to get to!

Originally Posted by bassmadrigal I'm using a -current kernel on my 14.1 box without any issues. Just make sure you also install the companion packages like kernel-modules and kernel-source. There is some debate on whether you should upgrade your kernel-headers package, but I tend to just leave mine alone (because that used to be the recommendation and I'm stuck in my old ways). However, I believe Pat, semi-recently, posted that he doesn't see any reason why you couldn't upgrade the kernel-headers package... but I'm too lazy to search for it to back up my claim

That's a good data point! My instinct would be to install the kernel-headers package too, but then again, I need to build things like xtables-addons, libvirt and strongswan too, and all my instincts tell me that they are likely to need the right versions of the headers to build effectively!

Originally Posted by GazL Final thought: Have you considered OpenBSD? That's a common and well respected platform for use as a firewall.

All my low-level experience is with SysV or Linux, closest I've come to BSD is SunOS (and I very quickly learnt to "set UNIVERSE=SYSV"), also, whilst I know that bpf is pretty cool, I've got too much effort invested in netfilter to want to change our huge blob of firewall rules out line-by-line!

Thanks very much indeed for all the good advice!

W.B.

Originally Posted by SlackBear That's a good data point! My instinct would be to install the kernel-headers package too, but then again, I need to build things like xtables-addons, libvirt and strongswan too, and all my instincts tell me that they are likely to need the right versions of the headers to build effectively!

Almost all programs that need to build against the kernel headers will use the ones in the kernel source under /usr/src/$KERNEL/include/, which is unaffected by the kernel-headers package. There's been talk that kernel-headers may not be the best name for it because it makes some people think that the kernel-source doesn't include the headers, but some have posited that glibc-headers would be a better name for it (but I don't know enough about them to say whether one or the other is better).

If it's any consolation, I'm still running the 3.10.17 kernel headers package on my 14.1 install with a 4.9.26 kernel. I have compiled several 3rd-party kernel modules without issue.

The kernel-headers package hasn't made a difference for me on x86_64 14.2. I am running a 4.9.x kernel with the kernel-headers-4.4.38-x86-1 package installed, and have been for some months now. Just today I started using the kernel packages from Slackware-current instead of compiling my own kernel from source. A few other people have said they do this and I wanted to try it out for myself. Usually I build the latest LTS release from kernel.org sources as they are updated. Anyway, everything works as expected.

This is what is installed on my system:

$ ls /var/log/packages/ | grep kernel
kernel-firmware-20170504git-noarch-1
kernel-generic-4.4.38-x86_64-1
kernel-generic-4.9.31-x86_64-1
kernel-headers-4.4.38-x86-1
kernel-modules-4.4.38-x86_64-1
kernel-modules-4.9.31-x86_64-1
kernel-source-4.4.38-noarch-1
kernel-source-4.9.31-noarch-1

I am also using the kernel-firmware-20170504git-noarch-1 package from Slackware-current. I upgraded this when I noticed I was getting messages from mkinitrd that files were missing for the i915 kernel module to build my initrd for the 4.9.x kernel series.

I am using full disk encryption with LUKS and LVM, which is why I use the generic kernels and a initrd.