Wie wahrscheinlich jeder verlasse ich mich bei Servern nicht gerne auf die Funktionsf\u00e4higkeit des DHCP-Servers, sondern vergebe manuell eine feste IP-Adresse. Diese trage ich zus\u00e4tzlich noch als statische Zuordnung im DHCP-Server ein (doppelt gemoppelt und nicht notwendig, ich wei\u00df…).<\/p>\n\n\n\n
Umso gr\u00f6\u00dfer war meine \u00dcberraschung als ich bei einem frisch installierten Ubuntu 18.04 LTS Server nach einem \u00fcblichen<\/p>\n\n\n
\nsudo nano \/etc\/network\/interfaces\n<\/pre><\/div>\n\n\nmit folgender Datei konfrontiert wurde:<\/p>\n\n\n\n\n\n\n
\n# ifupdown has been replaced by netplan(5) on this system. See\n# \/etc\/netplan for current configuration. \n# To re-enable ifupdown on this system, you can run:\n# sudo apt install ifupdown\n<\/pre><\/div>\n\n\nIn meiner Naivit\u00e4t dachte ich noch, okay, dann liegt die Datei jetzt eben woanders, bl\u00f6d, aber gew\u00f6hnt man sich schon dran. In \/etc\/netplan<\/code> liegt genau eine Datei namens 50-cloud-init.yaml<\/code> und wenn man dort nun die feste IP konfigurieren will, wartet die n\u00e4chste \u00dcberraschung auf einen.<\/p>\n\n\n\n# This file is generated from information provided by\n# the datasource. Changes to it will not persist across an instance.\n# To disable cloud-init's network configuration capabilities, write a file\n# \/etc\/cloud\/cloud.cfg.d\/99-disable-network-config.cfg with the following:\n# network: {config: disabled}\nnetwork:\nethernets:\nens160:\naddresses: []\ndhcp4: true\noptional: true\nversion: 2\n<\/pre><\/div>\n\n\nAuch diese Datei taugt nicht zum editieren, da sie aus einer Datenquelle erstellt wird. Wenn sie jetzt noch verraten w\u00fcrde welche Datenquelle das denn nun genau ist, w\u00e4re das super und echt benutzerfreundlich. Aber geht nat\u00fcrlich auch so.<\/p>\n\n\n\n
In meinem Fall m\u00f6chte ich dem Server wie gesagt eine feste IP (192.168.178.88 in einem 24er-Subnet, also 255.255.255.0 als Netzwerkmaske) vergeben, sein Gateway (192.168.178.1) mitteilen und die DNS-Server (192.168.178.83 und 192.168.178.1) konfigurieren. Also wirklich nichts wildes.<\/p>\n\n\n\n
Auf geht’s!<\/p>\n\n\n
\nsudo nano \/etc\/netplan\/01-network-eth.yaml\n<\/pre><\/div>\n\n\nIn dieser Datei trage ich nun folgendes ein (sollte selbsterkl\u00e4rend sein, ansonsten ist „man netplan<\/code>“ gar nicht so \u00fcbel).<\/p>\n\n\n\nnetwork:\nethernets:\nens160:\naddresses: [192.168.178.88\/24]\ngateway4: 192.168.178.1\nnameservers:\naddresses: [192.168.178.83,192.168.178.1]\nversion: 2\n<\/pre><\/div>\n\n\nUm die Syntax der Datei zu pr\u00fcfen, empfehle ich dringend ein<\/p>\n\n\n
\nsudo netplan --debug generate\n<\/pre><\/div>\n\n\nEventuelle Syntaxfehler sieht man damit sofort, in unserem Fall ist aber alles ok.<\/p>\n\n\n
\nDEBUG:command generate: running ['\/lib\/netplan\/generate']\n** (generate:3408): DEBUG: 12:48:33.405: Processing input file \/\/etc\/netplan\/01-network-eth.yaml..\n** (generate:3408): DEBUG: 12:48:33.406: starting new processing pass\n** (generate:3408): DEBUG: 12:48:33.406: ens160: setting default backend to 1\n** (generate:3408): DEBUG: 12:48:33.406: Generating output files..\n** (generate:3408): DEBUG: 12:48:33.406: NetworkManager: definition ens160 is not for us (backend 1)\n<\/pre><\/div>\n\n\nNach einem Neustart ist dann alles wie gehabt und der Server unter seiner festen IP erreichbar.<\/p>\n","protected":false},"excerpt":{"rendered":"
Wie wahrscheinlich jeder verlasse ich mich bei Servern nicht gerne auf die Funktionsf\u00e4higkeit des DHCP-Servers, sondern vergebe manuell eine feste IP-Adresse. Diese trage ich zus\u00e4tzlich noch als statische Zuordnung im DHCP-Server ein (doppelt gemoppelt und nicht notwendig, ich wei\u00df…). Umso gr\u00f6\u00dfer war meine \u00dcberraschung als ich bei einem frisch installierten Ubuntu 18.04 LTS Server nach …<\/p>\n