Score:2

How do I clean up legacy networking on a production server, after a decade of upgrades?

in flag

TL;DR: Is there any good way to bring my networking configuration/operation up to the present, without borking my docker and lxc bridges, and keeping my custom lan (static)/wan(dhcp) stuff?

Details:

I run a bunch of web-servers in lxc containers for of some of my hobbies (that actually are used a fair bit) on an ubuntu server on my home connection, as well as local NAS, some docker containers (homeassistant!) and so-on. There is so so much legacy stuff on it. Networking is one of these, naturally.

The host server was originally Ubuntu 12.04 when that was brand new; I upgraded probably around 2017 to 16.04; and probably in 2021 to 20.04; and more recently to 22.04. As you are undoubtedly aware, networking underwent many changes during this time period...

I recently decided to install pi-Hole, in a docker container, for my home network, which is behind an appliance router (EdgeRouterX). It works great for that. But I had to disable dnsmasq - because installation instructions - and that broke the host DNS. I fixed it by manually editing resolv.conf

The server has a connection to the lan, as well as directly to the wan, so that it is kind-of outside the home network, and has a different external IP, but can still talk to the devices on the lan.

My problem is basically thus: Whenever I go to do anything new, all the instructions are assuming either NetworkManager.service, or the older service network-manager, but I'm still back in service networking days, and editing my /etc/network/interfaces, despite all the upgrades, and it becomes quite difficult to manage when all the things I have to do are different than all the newer guides. I've poked at this long enough that I can generally get it working, but there has to be a better way!?

Really, the /etc/network/interfaces is quite simple (though I can't remember how I aliased the ethernet ports):

auto lo
iface lo inet loopback

auto wan
iface wan inet dhcp

auto lan
iface lan inet static
        address 192.168.2.88
        netmask 255.255.255.0
        network 192.168.2.0

Docker appears to use the NetworkManager service, since systemctl is-active NetworkManager.service returns active and nmcli lists all the docker containers and bridge; but everything else is "unmanaged", and LXC seems to handle itself some other way, and its ip's are all configured within the individual container configs. I'm using shorewall as a firewall, which seems to handle some amount of the magic.

And at this point I don't know how my dns resolution will happen if I ever restart, or if I'll have to manually edit resolv.conf every time.

I also generally just remote into the server, though I can plug monitors into it, and use gnome-fallback.

So the question is thus:

Is there any good way to bring my networking configuration/operation up to the present, without borking my docker and lxc bridges, and keeping my custom lan (static)/wan(dhcp) stuff, and fix however my dns resolution occurs? Or, is it better to just keep legacy-ing on?

user10489 avatar
in flag
I'd be tempted to convert interfaces to netplan. Network manager you can take or leave but netplan will mostly override it either way. Not sure how to port your container networks, but netplan should work with that too.
user535733 avatar
cn flag
if you are stuck with X-breaks-Y legacy because you cannot recall how something was set up or because something new has come along, then you are in fetters. Advice: Break the cycle and start over. Create a VM, build up all the services again from scratch, and rebuild your notes at the same time. Once you have built it again, you will be able to answer your own question and decide between repair and replace.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.