Skip to content

Ubuntu Bionic - IP Adresse ändern

Angeheftet Verschoben Linux
1 1 2.4k
  • Ich habe mich gestern Abend ziemlich darüber aufgeregt, wie man unter Ubuntu 18.04 die Interfaces einstellen muss. Mal von dem Zeitverlust abgesehen. Ich spiele zwar gerne an Headless Servern rum, aber so was sinnloses hatte ich schon lange nicht mehr. 😞

    Hardware

    ROCKPro64

    Software

     rock64@rockpro64:/$ uname -a
     Linux rockpro64 4.17.0-rc6-1019-ayufan-gfafc3e1c913f #1 SMP PREEMPT Tue Jun 12 19:06:59 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
    

    Wie man die IP-Adresse unter Linux einstellt werden die meisten von Euch sicherlich sehr gut kennen, da das zum täglichen Geschäft gehört wenn man mit den kleinen Platinen arbeitet.

    Warum man nicht dauerhaft das einfach auf DHCP lässt, denke ich brauche ich hier in dieser Runde nicht erklären.

    Unter Ubuntu 18.04 hat man jetzt was Neues eingeführt. Das Ganze nennt sich Netplan. Netplan findet man unter /etc/netplan Dort liegt ein File eth0.yaml zu der Dateiendung .yaml komme ich später noch zu sprechen.

     rock64@rockpro64:/$ ls -la /etc/netplan
     total 16
     drwxr-xr-x  2 root root 4096 Jun 17 05:39 .
     drwxr-xr-x 86 root root 4096 Jun 16 12:22 ..
     -rw-r--r--  1 root root  333 Jun 16 20:39 eth0.yaml
     -rw-r--r--  1 root root  329 Jun 16 20:38 eth0.yaml_bak
    

    Macht Euch vorher eine Kopie, man weiß ja nie 😉 Der Inhalt der Datei sieht ungefähr so aus, ich hatte vergessen vorher eine Kopie zu machen 🙂

     network: 
     	version: 2 
     	renderer: networkd
     	ethernets:
     		eth0: #object name
     			dhcp4: yes # dhcp v4 enable
     			dhcp6: yes # dhcp v6 enable (if you want)
    

    Die Schnittstelle eth0 zieht sich mittels DHCP die Daten vom DHCP-Server. Alle meine Server haben hier feste IP-Adressen, da der Mainline aktuell sehr stabil läuft, bekommt der jetzt ne feste IP. So weit mein Plan.

    YAML

    Nachdem ich eine Stunde rumgedockert hatte und nichts klappte, habe ich mal vorne angefangen. Was ist YAML? Dazu der WIKI-Link. Gut, eigentlich nicht zu schwer zu verstehen. Aber trotzdem bekam ich andauernd nur Fehlermeldungen. So was in der Art hier.

    Invalid YAML at //etc/netplan/01-netcfg.yaml line 9 column 5: did not find expected key
    

    Wieder suchen, suchen usw. Dann bekommt man raus, das es entscheidend wichtig ist, wie die Einrückung aufgebaut ist. WTF? Der dumme Parser erkennt das als einen Fehler an ob ich jetzt 2 Leerstellen vor dem Eintrag habe, er aber gerne 3 Leerstellen dort hätte!? Geht es noch komplizierter? Das ist in meinen Augen völlig benutzerunfreundlich! Macht Debian das auch? Später nachschauen...

    Also hatte ich vieles ausprobiert, aber nur dieses Beispiel habe ich dann zum Laufen bekommen.

    Beispiel Datei

    # This file describes the network interfaces available on your system
    # For more information, see netplan(5).
     network:
      version: 2
      renderer: networkd
      ethernets:
        eth0:
          dhcp4: no
          dhcp6: no
          addresses: [192.168.3.206/24]
          gateway4: 192.168.3.1
          nameservers:
            addresses: [192.168.3.1,1.1.1.1]
    

    Diese Datei kann man also ganz gewöhnlich mit einem Texteditor deiner Wahl bearbeiten, danach abspeichern. Dann kommt der YAML Parser zum Einsatz. Dieser checkt das File auf Fehler, was ja auch eigentlich eine gute Sache ist. Der Befehl dafür.

    sudo netplan apply
    

    Dabei sollte man folgendes beachten, das File wird geprüft, wenn erfolgreich werden die Netzwerkeinstellungen sofort aktiviert. Man verliert also eine evt. bestehende SSH-Verbindung sofort. Also Vorsicht, vorher kurz nachdenken 😉

    Ganz ehrlich, braucht man das so? Ich muss mich wohl dran gewöhnen....

    Noch ein Tipp, die Netzwerkmaske ändert man über /24

    Das sieht dann jetzt so aus

     rock64@rockpro64:/$ ip a
     1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
         link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
         inet 127.0.0.1/8 scope host lo
            valid_lft forever preferred_lft forever
         inet6 ::1/128 scope host 
            valid_lft forever preferred_lft forever
     2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
         link/ether e2:15:d9:4c:26:11 brd ff:ff:ff:ff:ff:ff
     3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
         link/ether aa:41:29:23:dc:d1 brd ff:ff:ff:ff:ff:ff
         inet 192.168.3.206/24 brd 192.168.3.255 scope global eth0
            valid_lft forever preferred_lft forever
         inet6 fe80::a841:29ff:fe23:dcd1/64 scope link 
            valid_lft forever preferred_lft forever
     4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
         link/sit 0.0.0.0 brd 0.0.0.0
    

    Was das mit dem dummy0 und sit@NONE auf sich hat muss ich mir mal in einer ruhigen Stunde ansehen.

    Das dummy0 und sit@NONE sind Interfaces die von Kernel-modulen erzeugt werden. Man kann beide Module aber nicht entladen, weil beide Module in den Kernel eingebaut sind!

    rock64@rockpro64v_2_1:~$ sudo modprobe -r sit
    [sudo] password for rock64: 
    modprobe: FATAL: Module sit is builtin.
    rock64@rockpro64v_2_1:~$ sudo modprobe -r dummy
    modprobe: FATAL: Module dummy is builtin.
    

    Das ist nur im Mainline so!

    rock64@rockpro64v_2_1:~$ uname -a
    Linux rockpro64v_2_1 4.18.0-rc8-1060-ayufan-g45828c4db727 #1 SMP PREEMPT Thu Aug 9 19:41:21 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
    

    Im 4.4x

    rock64@rockpro64v2_0:~$ ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host 
           valid_lft forever preferred_lft forever
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
        link/ether aa:41:29:23:dc:d1 brd ff:ff:ff:ff:ff:ff
        inet 192.168.3.206/24 brd 192.168.3.255 scope global eth0
           valid_lft forever preferred_lft forever
        inet6 fe80::a841:29ff:fe23:dcd1/64 scope link 
           valid_lft forever preferred_lft forever
    
  • Update 1.33.0 - Security Fixes!

    Vaultwarden vaultwarden linux
    1
    0 Stimmen
    1 Beiträge
    154 Aufrufe
    Niemand hat geantwortet
  • Debian Installer Bookworm RC3 released

    Linux debian linux
    2
    0 Stimmen
    2 Beiträge
    181 Aufrufe
    FrankMF
    Und da sind wir schon bei RC4 https://lists.debian.org/debian-devel-announce/2023/05/msg00003.html
  • Debian 11 Bullseye released!

    Linux debian linux
    4
    0 Stimmen
    4 Beiträge
    384 Aufrufe
    FrankMF
    Mein Systemadmin auf der Arbeit meinte heute, angesprochen auf das Problem, läuft der Network-Manager? Ok, gute Frage...... Schauen wir mal. Ich bin mir leider nicht 100% sicher, ob er vor meinem Eingreifen lief, ich denke aber schon. Warum ich unsicher bin? root@debian:~# systemctl enable systemd-networkd.service Created symlink /etc/systemd/system/dbus-org.freedesktop.network1.service → /lib/systemd/system/systemd-networkd.service. Created symlink /etc/systemd/system/multi-user.target.wants/systemd-networkd.service → /lib/systemd/system/systemd-networkd.service. Created symlink /etc/systemd/system/sockets.target.wants/systemd-networkd.socket → /lib/systemd/system/systemd-networkd.socket. Created symlink /etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service → /lib/systemd/system/systemd-networkd-wait-online.service. Ok, danach root@debian:~# systemctl start systemd-networkd.service root@debian:~# systemctl status systemd-networkd.service ● systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; ven> Active: active (running) since Tue 2021-08-17 17:36:38 CEST; 6s ago TriggeredBy: ● systemd-networkd.socket Docs: man:systemd-networkd.service(8) Main PID: 1288 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 19087) Memory: 3.9M CPU: 39ms CGroup: /system.slice/systemd-networkd.service └─1288 /lib/systemd/systemd-networkd Aug 17 17:36:38 debian systemd[1]: Starting Network Service... Aug 17 17:36:38 debian systemd-networkd[1288]: enp25s0: Gained IPv6LL Aug 17 17:36:38 debian systemd-networkd[1288]: Enumeration completed Aug 17 17:36:38 debian systemd[1]: Started Network Service. Danach ging immer noch nix. root@debian:/etc/network# ^C root@debian:/etc/network# nmcli device show GENERAL.DEVICE: wlx7cdd907cbec2 GENERAL.TYPE: wifi GENERAL.HWADDR: BA:59:C0:76:C7:F5 GENERAL.MTU: 1500 GENERAL.STATE: 20 (nicht verfügbar) GENERAL.CONNECTION: -- GENERAL.CON-PATH: -- GENERAL.DEVICE: enp25s0 GENERAL.TYPE: ethernet GENERAL.HWADDR: 30:9C:23:60:C6:8E GENERAL.MTU: 1500 GENERAL.STATE: 10 (nicht verwaltet) GENERAL.CONNECTION: -- GENERAL.CON-PATH: -- WIRED-PROPERTIES.CARRIER: an IP4.ADDRESS[1]: 192.168.3.169/24 IP4.GATEWAY: 192.168.3.1 IP4.ROUTE[1]: dst = 192.168.3.0/24, nh = 0.0.0.0, mt = 0 IP4.ROUTE[2]: dst = 0.0.0.0/0, nh = 192.168.3.1, mt = 0 IP6.ADDRESS[1]: 2a02:908:1260:13bc:329c:23ff:xxxx:xxxx/64 IP6.ADDRESS[2]: fd8a:6ff:2880:0:329c:23ff:fe60:c68e/64 IP6.ADDRESS[3]: fe80::329c:23ff:fe60:c68e/64 IP6.GATEWAY: fe80::e4d3:f0ff:fe8f:2354 IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 256 IP6.ROUTE[2]: dst = ::/0, nh = fe80::e4d3:f0ff:fe8f:2354, mt = 1024 IP6.ROUTE[3]: dst = 2a02:908:xxxx:xxxx::/64, nh = ::, mt = 256 IP6.ROUTE[4]: dst = fd8a:6ff:2880::/64, nh = ::, mt = 256 Jetzt hatte ich das erste Mal einen Ansatz, wonach ich suchen musste. GENERAL.STATE: 10 (nicht verwaltet) Etwas Suche im Netz und dann das nano /etc/NetworkManager/NetworkManager.conf Inhalt der Datei [main] plugins=ifupdown,keyfile [ifupdown] managed=false Das false in true geändert. Danach ein systemctl restart NetworkManager und ich konnte den Network-Manager auf dem Desktop benutzen!?!?!? [image: 1629216580219-bildschirmfoto-vom-2021-08-17-18-07-25.png] Irgendwas ist da durcheinander im Bullseye
  • Portainer - NodeBB Container erstellen

    Linux nodebb portainer linux redis
    1
    5
    0 Stimmen
    1 Beiträge
    349 Aufrufe
    Niemand hat geantwortet
  • NanoPi R2S - Firewall mit VLan und DHCP-Server

    Verschoben NanoPi R2S nanopir2s linux
    2
    2
    0 Stimmen
    2 Beiträge
    855 Aufrufe
    FrankMF
    Nachdem ich die Tage feststellen musste, das irgendwas mit dem Gerät nicht stimmte, bekam keine DNS Auflösung über die Konsole, habe ich das heute mal eben neuinstalliert. Armbian ist ja immer was spezielles Hat sich bis heute nix dran geändert..... Ok, dann heute mal eben ein neues Image erstellt. Download Gewählt habe ich das Armbian Buster. Image auf die SD-Karte, eingeloggt. Alles wie oben erstellt und abgespeichert. Neustart, geht wieder alles. root@192.168.3.15's password: _ _ _ ____ ____ ____ | \ | | __ _ _ __ ___ _ __ (_) | _ \|___ \/ ___| | \| |/ _` | '_ \ / _ \| '_ \| | | |_) | __) \___ \ | |\ | (_| | | | | (_) | |_) | | | _ < / __/ ___) | |_| \_|\__,_|_| |_|\___/| .__/|_| |_| \_\_____|____/ |_| Welcome to Debian GNU/Linux 10 (buster) with Linux 5.9.11-rockchip64 System load: 2% Up time: 11 min Memory usage: 10% of 978M IP: 192.168.3.15 192.168.1.1 192.168.2.1 CPU temp: 61°C Usage of /: 5% of 29G Last login: Sun Dec 6 12:28:10 2020 from 192.168.3.213 Kernelversion root@nanopi-r2s:~# uname -a Linux nanopi-r2s 5.9.11-rockchip64 #20.11.1 SMP PREEMPT Fri Nov 27 21:59:08 CET 2020 aarch64 GNU/Linux ip a oot@nanopi-r2s:~# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether b2:b5:10:38:9e:76 brd ff:ff:ff:ff:ff:ff inet 192.168.3.15/24 brd 192.168.3.255 scope global dynamic eth0 valid_lft 6360sec preferred_lft 6360sec inet6 2a02:908:xxxxxx/64 scope global dynamic mngtmpaddr valid_lft 7196sec preferred_lft 596sec inet6 fe80::b0b5:10ff:fe38:9e76/64 scope link valid_lft forever preferred_lft forever 3: lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether b2:b5:10:38:9e:96 brd ff:ff:ff:ff:ff:ff 4: lan0.100@lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether b2:b5:10:38:9e:96 brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global lan0.100 valid_lft forever preferred_lft forever inet6 fe80::b0b5:10ff:fe38:9e96/64 scope link valid_lft forever preferred_lft forever 5: lan0.200@lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether b2:b5:10:38:9e:96 brd ff:ff:ff:ff:ff:ff inet 192.168.2.1/24 brd 192.168.2.255 scope global lan0.200 valid_lft forever preferred_lft forever inet6 fe80::b0b5:10ff:fe38:9e96/64 scope link valid_lft forever preferred_lft forever Vom Notebook aus funktioniert auch alles. So weit bin ich zufrieden. Jetzt mal langsam anfangen, der Kiste IPv6 beizubringen. Oje, nicht gerade mein Lieblingsthema... Bis der NanoPi R4S hier ankommt und ein vernünftiges Image hat, vergeht ja noch was Zeit...
  • ROCKPro64 - Kernel 5.6 und Wireguard 1.0

    ROCKPro64 linux rockpro64 wireguard
    1
    0 Stimmen
    1 Beiträge
    350 Aufrufe
    Niemand hat geantwortet
  • SSHFS

    Linux linux
    1
    0 Stimmen
    1 Beiträge
    354 Aufrufe
    Niemand hat geantwortet
  • Restic - Ein Backupkonzept - Wiederherstellung

    Verschoben Restic linux restic
    1
    0 Stimmen
    1 Beiträge
    770 Aufrufe
    Niemand hat geantwortet