Debian – How to reliable re-install nf_conntrack module after removal

debiankernel-modulesmodprobe

I want to remove the nf_conntrack module from debian. However I don't want to do this until I know how to get it back (if I have to), and currently am not confident about this. The steps another user took to remove the module are listed in this answer (step 4). Specifically:

sudo modprobe -r xt_NOTRACK nf_conntrack_netbios_ns nf_conntrack_ipv4 xt_state
sudo modprobe -r nf_conntrack

Can I just run the modprobe add commands (in reverse order) to get these back as it was? E.g. (updated based on wurtel's feedback):

sudo modprobe nf_conntrack
sudo modprobe xt_NOTRACK
sudo modprobe xt_state
sudo modprobe nf_conntrack_netbios_ns
sudo modprobe nf_conntrack_ipv4

Or are the other considerations I need to rake into account?

EDIT: Just to clarify I believe I've removed any IPTables rules that use these modules.

Best Answer

You can only safely remove these modules if they are not being used in any iptables rules.

Loading them again will happen automatically when needed (i.e. when loading iptables rules) so there's no need to load them manually. That said, you can't supply a list of modules to load to modprobe.

Related Solutions

Debian – Running Stable and Installing Packages from Testing

Many people seem to be afraid of mixing stable with testing, but frankly, testing is fairly stable in its own right, and with proper preferences and solution checking, you can avoid the "stability drift" that puts your core packages on the unstable path.

"Testing is fairly stable??", you ask. Yes. In order for a package to migrate from unstable to testing, it has to have zero open bugs for 10 consecutive days. Chances are that, especially for the more popular packages, somebody is going to submit a bug report for an unstable version if something is wrong.

Even if you don't want to mix the environments, it's still nice to have the option there in case you run into something that requires a newer version than what is in stable.

Here's what I recommend for setting this up:

First, create the following files in /etc/apt/preferences.d:

stable.pref:

# 500 <= P < 990: causes a version to be installed unless there is a
# version available belonging to the target release or the installed
# version is more recent

Package: *
Pin: release a=stable
Pin-Priority: 900

testing.pref:

# 100 <= P < 500: causes a version to be installed unless there is a
# version available belonging to some other distribution or the installed
# version is more recent

Package: *
Pin: release a=testing
Pin-Priority: 400

unstable.pref:

# 0 < P < 100: causes a version to be installed only if there is no
# installed version of the package

Package: *
Pin: release a=unstable
Pin-Priority: 50

experimental.pref:

# 0 < P < 100: causes a version to be installed only if there is no
# installed version of the package

Package: *
Pin: release a=experimental
Pin-Priority: 1

(Don't be afraid of the unstable/experimental stuff here. The priorities are low enough that it's never going to automatically install any of that stuff. Even the testing branch will behave, as it's only going to install the packages you want to be in testing.)

Now, creating a matching set for /etc/apt/sources.list.d:

stable.list: Copy from your original /etc/apt/sources.list. Rename the old file to something like sources.list.orig.

testing.list: Same as stable.list, except with testing.

unstable.list: Same as stable.list, except with unstable, and remove the security lists.

experimental.list: Same as unstable.list, except with experimental.

You can also add a oldstable in sources.lists.d and preferences.d (use a priority of 1), though this moniker will tend to expire and disappear before the next stable cycle. In cases like that, you can use http://archive.debian.org/debian/ and "hardcode" the Debian version (etch, lenny, etc.).

To install the testing version of a package, simply use aptitude install lib-foobar-package/testing, or just jump into aptitude's GUI and select the version inside of the package details (hit enter on the package you're looking at).

If you get complaints of package conflicts, look at the solutions first. In most cases, the first one is going to be "don't install this version". Learn to use the per-package accept/reject resolver choices. For example, if you're installing foobar-package/testing, and the first solution is "don't install foobar-package/testing", then mark that choice as rejected, and the other solutions will never veer to that path again. In cases like these, you'll probably have to install a few other testing packages.

If it's getting too hairy (like it's trying to upgrade libc or the kernel or some other huge core system), then you can either reject those upgrade paths or just back out of the initial upgrade altogether. Remember that it's only going to upgrade stuff to testing/unstable if you allow it to.

EDIT: Fixed some priority pins, and updated the list.

Linux – how to disable the nf_conntrack kernel module in CentOS 5.3 without recompiling the kernel

remove any reference to the state module in iptables. So, no rules like

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

the state module requires the nf_conntrack (ip_conntrack) module
remove the following line (if it exists) in /etc/sysconfig/iptables-config

IPTABLES_MODULES="ip_conntrack_netbios_ns"

That module requires ip_conntrack which we are trying to ditch.
reload iptables without your state rules.

sudo iptables -F

# add your real rules
drop the modules. I had to use:

sudo modprobe -r xt_NOTRACK nf_conntrack_netbios_ns nf_conntrack_ipv4 xt_state

sudo modprobe -r nf_conntrack
confirm you don't have a reference to /proc/net/nf_conntrack

Best Answer

Related Solutions

Debian – Running Stable and Installing Packages from Testing

Linux – how to disable the nf_conntrack kernel module in CentOS 5.3 without recompiling the kernel

Related Topic