I yaml’d my network: netplan and the new world order

Comments

8 Responses to “I yaml’d my network: netplan and the new world order”

1. Mathieu Trudel-Lapierre

   2018-05-17

   Feedback noted.

   Please, don’t hesitate to share more feedback, we’re working actively on fixing things that are missing in netplan.

   Reply
2. Dan

   2018-07-17

   This reinventing of the wheel drives me insane. For one, yaml sucks as far as human readability/writability. Secondly, by using netplan you actually sacrifice functionality – it also can’t do promiscuous mode, fyi, and goodness knows what else. It’s systemd all over again – less functionality and control for the sake of “ease of configurability” or something (which is not even real if you want to do anything at all which the developer didn’t think you might want to do in the typical “it suits my needs” fashion)

   Reply
3. Michael

   2018-08-21

   Linux used to be about the beauty of simplicity. And about choice.
   Now its some bloody hipsters forcefeeding you unnecessary “solutions” to problems you don’t have, and integrating these “solutions” so deeply in the system that it’s a royal PITA _not_to use them. And they don’t give a damn about the Unix philosophy (https://en.wikipedia.org/wiki/Unix_philosophy). Rule of Simplicity? Rule of Robustness? Hah – who needs human readable config files when you can have complex yamlised, daemonised stuff?!
   At least for some of us there’s still some choice left: don’t use Redhat, don’t use Ubuntu.
   My sympathy goes out to all those poor people whose job forces them to use “hip”, “professional” distros.

   Reply
   1. mark

      2019-06-19

      It’s not the hipsters that kill Linux, though. Systemd is an IBM Red Hat project, so of course you have selfish corporate hackers create all that code.

      The community needs to transition into a model where they can maintain and develop software without the saboteurs from Red Hat and co causing harm.

      > At least for some of us there’s still some choice left: don’t use Redhat,
      > don’t use Ubuntu.

      Quite true. I use a modified slackware variant (absolute linux with custom stuff
      done through ruby, including compiling everything from source). But what is still
      missing is that the community of mostly individuals gets organized. And ideally
      not with a “another distribution”, but with a distribution agnostic manner. A bit
      like the LFS/BLFS project does.

      Reply
4. Dave Sill

   2019-07-11

   Mainstream Linux has jumped the shark. Come to think of it, almost everything computing-related is disappointing these days.

   Reply
5. Simon Rostron

   2019-09-12

   Is it just me, or does networking in Ubuntu 18.04 feel like multiple network providers have been chained together? Like you mentioned, I’m seeing the names NetworkManager, systemd-networkd, and netplan all intertwined — a symlink here, an override of another there.

   The fuck? I expect to be able to edit a familiar file in /etc/ and consider it an administrative decision — not have my console filled with commented lines saying “# WARNING DO NOT EDIT WILL BE OVERWRITTEN BY $Culprit”.

   I have an Ubuntu 18.04 VM spun up in Azure, and I’m trying to implement a PoC for Squid Proxy (which, for the record, behaves predictably, and doesn’t require me revisiting Google results several times wondering if I missed a nugget of hope in the information provided). I’ve dug through a score of StackExchange threads, and found various bits of help from an answer or comment here or there.

   While I want to get this working sooner rather than later in the interest of time and productivity, especially considering this is a work project, I also care about learning the right way to do things. While it might delay or frustrate me, it’s good to learn the ropes. But this is insane. Why is there such a variety of answers for what is basically the same question: “How do I ensure my DNS servers are predictable?”

   “Disable the symlink.”

   “Use resolvconf.”

   “Use dnsmasq.”

   “Use resolved, and embrace the DNSStub. It’s forwarding to the server that you’re trying to configure in the first place — which I won’t tell you how to do.”

   “Edit this netplan file.”

   I figured out — through what has basically been a night of academic research — that netplan is the new networker on the block. Cool, I’ll try to follow best practice, and edit the netplan config for the interface. Hey, kinda clever to be able to specify configurations based on interface, matching on MAC address and such. Could offer some nice functionality. netplan apply, and…wow! I’m resolving internal DNS now! It worked!

   …until I rebooted. Also, really nice insult to injury to cat the config file I had previously edited, only to see that it had been reverted.

   One of the shortcuts/hacks suggested was to install resolvconf.

   “Place the override in ‘resolve.conf.d/head’”

   “No, place the override in ‘resolve.conf.d/base’”

   “Only ‘resolve.conf.d/tail’ will make it in”

   “I tried it in these locations and only /head worked”

   Who to believe? Upvoted answers, upvoted comments, the man page, or varied testimonies of the results?

   I had a similar issue somewhat recently, but after some research — which included reading an article in which the author compared the various options for achieving this very goal — I was able to determine the most best-practice approach, and give it a shot. And, it worked. I was rewarded for my efforts and time with a functional configuration — and more knowledge.

   I’m not anything beyond intermediate when it comes to GNU/Linux. I tried out many a distro on my laptop during my nerd-budding years, back around 2006-2008. While I was enthralled by the options for desktop environments and window managers (and likely the indie feel it provided at that age), I remember how significant it was to discover package mangers such as apt, yum, and zypper. While I liked the fact that I could rotate my desktop like a cube (Compiz) and had multiple workspaces, astounding my friends, I realized that Linux had some very significant benefits at its foundation.

   Throughout my years of experience in enterprise IT, mostly in a Microsoft setting, I’ve never lost appreciation for GNU/Linux. While Microsoft does things such as Active Directory, SQL, and IIS well, there is always a time and a place where Linux can meet the need with more reliability, security, and simplicity, and at a better cost. I’ve grown to consider it a solid platform on which to build certain solutions, and it hasn’t failed me.

   …until now. These days, a quick edit of a file in /etc/ and a service restart after consulting a few results on Google doesn’t put me in business.

   And, screw you, Canonical. Your Azure marketplace VM picks up the IP I set for it, but doesn’t apply the VNet DNS addresses. Last I checked, both should be good to go thanks to DHCP. It’d be one thing if I had to fiddle around with the search suffixes or whatever, but you’re providing me a product that is clearly non-functional. (My organization’s Ubuntu 16.04 systems are working fine, which is interesting, because netplan seems to be the outlier…)

   Next step is to try the Debian image on the marketplace. My guess is it will either just work (you know, actually apply DNS settings the DHCP response sends) or will be fixed with research spanning a fraction of the time I spent tonight.

   Anyway…I enjoyed the post. Good thoughts!

   Reply
   1. Jayme Snyder

      2019-09-18

      I’ve always been a BSD/Solaris/HP-UX at heart for this exact reason… though a fresh egocentric BSD developer doesn’t see the instant gratification of their slop finding it’s way into the main distribution – so where is no reward for developing for BSD? As a user, you have stale ports and much not working if you tolerated the steaming piles of shit included in most distributions now. Maybe you can use a “better” distribution like Gentoo and slowly, through dependency hell, find yourself in the same situation.

      Reply
      1. Simon Rostron

         2019-09-25

         FreeBSD/BSDs in general have terrific documentation, with the added benefit of the forum post from 5 years ago usually providing helpful information for the situation at hand.

         This benefit may be due to stagnation, one may argue. And, one may be right. But when it comes to running servers, I see little reason to focus on ensuring that an end user’s desktop picks up appropriate DNS when moving from home->work->Starbucks->the airport Wi-Fi.

         I installed Ubuntu “Server” 18.04. If Canonical wants to use the latest-greatest network client for a desktop distro based on evidence and feedback that suggests it will provide a better experience for those with it installed as the primary OS on a roaming laptop, that’s great, and I hope it serves everyone well. But I installed the “server” version. I just want it to pick up the hints provided in the DHCP response, and this seems to be the first OS/distro that doesn’t do it.

         I want to do things the RIGHT way. I don’t want to hack the good ol’ /etc/resolv.conf file to deny access to what seems to be an army of daemons that are responsible for generating it. I embrace the new way, and I want to follow best practices. So why make it so damn hard?

         For the record, in my original post, I said I was going to give the Debian image on the Azure marketplace a shot. Guess what? I didn’t spend hours pulling my hair out trying to find the right best-practice override. I didn’t spin my wheels in a confused daze wondering how to respond to the rugs slipped out from under me. Things just WORKED (you know, like DHCP client behavior); when I needed to tweak behavior, a few minutes on Google would answer it.

         It doesn’t have to be /etc/resolv.conf, but it has to be documented, predictable, and reliable. If we have to play hide-and-seek with Google results to get the new solution to work, the first thing myself and others are going to do is fall back to that which is. We love to hack and get our hands dirty, but in the context of the solution we are trying to deploy in the first place — not core networking components.

         Reply