Hallo Leute!
Seit der Aktualisierung auf Debian 9 habe ich ein komisches Problem, das ich noch nicht lösen konnte...
Ich habe auf dem Server die "eth0" in "isp0" umbenannt. Beim Booten wird die IPv4-Adresse korrekt zugewiesen und die andere IPv4 an "isp0:1" und "isp0:2" werden auch korrekt hochgefahren. Allerdings kein IPv6...
In /etc/network/interfaces habe ich folgendes:
auto isp0 iface isp0 inet static address 185.242.112.224 netmask 255.255.255.0 network 185.242.112.0 broadcast 185.242.112.255 gateway 185.242.112.1 bridge_ports eth0 bridge_stp off bridge_fd 5 bridge_hello 2 bridge_maxage 12 bridge_maxwait 4 post-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-arptables post-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables post-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
iface isp0 inet6 static pre-up modprobe ipv6 # Hauptadresse: mail.lucabert.de address 2a0a:51c0:0:52:1::1 netmask 64 gateway 2a0a:51c0:0:52::1 # ns.lucabert.de post-up ip -6 addr add 2a0a:51c0:0:52:2::1/64 dev isp0 pre-down ip -6 addr del 2a0a:51c0:0:52:2::1/64 dev isp0
Hat jemand eine Idee, warum seit der Aktualisierung auf Debian 9 nicht mehr geht und wie ich das Problem lösen kann?
Danke Luca Bertoncello (lucabert@lucabert.de)
Am 15.08.2019 um 10:12 teilte Luca Bertoncello mit:
Moin,
Seit der Aktualisierung auf Debian 9 habe ich ein komisches Problem, das ich noch nicht lösen konnte...
Zuerst die dumme Frage: sicher, daß Du *auf* Debian 9 upgegraded hast?
H.
Am 15.08.2019 11:08, schrieb Hilmar Preuße:
Hallo
Zuerst die dumme Frage: sicher, daß Du *auf* Debian 9 upgegraded hast?
Mmmm... ist es eine Frage über deutsche Grammatik oder was? Also, vorher hatte ich Debian 8 installiert, dann habe ich eine Aktualisierung durchgeführt (per apt-get) und jetzt läuft:
lucabert@ns:~$ cat /etc/debian_version 9.9
Grüße Luca Bertoncello (lucabert@lucabert.de)
Am 15.08.2019 um 11:13 teilte Luca Bertoncello mit:
Am 15.08.2019 11:08, schrieb Hilmar Preuße:
Moin,
Zuerst die dumme Frage: sicher, daß Du *auf* Debian 9 upgegraded hast?
Mmmm... ist es eine Frage über deutsche Grammatik oder was? Also, vorher hatte ich Debian 8 installiert, dann habe ich eine Aktualisierung durchgeführt (per apt-get) und jetzt läuft:
lucabert@ns:~$ cat /etc/debian_version 9.9
Nein, alles gut. Mich hatte nur gewundert, daß man /auf/ Debian 9 upgraded, mehr als 1 Monat nachdem es vom Status stable auf oldstable geschwenkt ist. Insofern vermutete ich ein Versehen und dachte Du hast auf 10.0 hochgezogen.
Hilmar
Am 15.08.2019 11:18, schrieb Hilmar Preuße:
Nein, alles gut. Mich hatte nur gewundert, daß man /auf/ Debian 9 upgraded, mehr als 1 Monat nachdem es vom Status stable auf oldstable geschwenkt ist. Insofern vermutete ich ein Versehen und dachte Du hast auf 10.0 hochgezogen.
Ach so! Nein, das war genau so gewollt... Debian 10 ist zwar neu, aber:
1) ich will kein Sprung machen (8 -> 10) 2) ich habe noch keine Erfahrung mit Debian 10 3) Debian 9 ist noch 'ne Weile unterstützt... ;)
Sonst Idee wie ich das Problem lösen kann? Ich habe auch probiert ein post-up Skript zu schreiben, aber anscheinend wird das nicht ausgeführt... :(
Grüße Luca Bertoncello (lucabert@lucabert.de)
Am 15.08.2019 um 11:22 teilte Luca Bertoncello mit:
Moin,
Ach so! Nein, das war genau so gewollt... Debian 10 ist zwar neu, aber:
- ich will kein Sprung machen (8 -> 10)
Geht eh nicht, bzw. ist laut Release Notes nicht supported.
- ich habe noch keine Erfahrung mit Debian 10
Hat wohl keiner, der es noch nicht ausprobiert hat.
Sonst Idee wie ich das Problem lösen kann? Ich habe auch probiert ein post-up Skript zu schreiben, aber anscheinend wird das nicht ausgeführt... :(
Mich wundert etwas, wieso Du das IPv6 Modul erst im pre-up lädst. Brauchen wirst Du es ja immer, darum würde ich es direkt in /etc/modules eintragen und den pre-up Eintrag entfernen.
Hilmar
Am 16.08.2019 11:08, schrieb Hilmar Preuße:
Mich wundert etwas, wieso Du das IPv6 Modul erst im pre-up lädst. Brauchen wirst Du es ja immer, darum würde ich es direkt in /etc/modules eintragen und den pre-up Eintrag entfernen.
Der Eintrag in /etc/network/interfaces war so noch in Debian 8 und ich habe es aktuell nicht geändert. Eigentlich sollte das Modul sowieso schon geladen sein, daher sollte das ignoriert werden...
Das Problem sollte also irgendwo anderes sein. Ideen?
Danke Luca Bertoncello (lucabert@lucabert.de)
Hat jemand eine Idee, warum seit der Aktualisierung auf Debian 9 nicht mehr geht und wie ich das Problem lösen kann?
Vielleicht gleich auf Debian 10 upgraden und systemd-networkd verwenden? Ich habe damit bisher nur gute Erfahrungen gemacht.
Grüße
Liebe Fachleute,
ich bekommen gerade eine ganz und gar unterwartete Fehlermeldung, wenn ich "ls" im Terminal aufrufe.
Im Verzeichnis befinden sich vier Verzeichnisse und ca. 140 Dateien. Beim Aufruf von "ls -al *.tex" ist alles wie erwartet, auch "ls -al *.tex | wc -l" gibt ein plausibles Ergebnis. Beim Aufruf von "ls -al *.doc" erhalte ich folgende Fehlermeldung: ls: Ungültige Option -- e „ls --help“ liefert weitere Informationen. Dieselbe Fehlermeldung gibt es beim Aufruf von "ls *.doc", "ls -a *.doc" und "ls -l *.doc". Der Aufruf von "ls -al ./*.doc" funktioniert dagegen wie erwartet. In einem anderen Verzeichnis mit .tex- und .doc-Dateien funktioniert "ls -al *.doc" wie erwartet.
Es laufen: Xubuntu 18.04 (4.15.0-58-generic #64-Ubuntu), bash 4.4.20(1)-release (x86_64-pc-linux-gnu), ls (GNU coreutils) 8.28, US-Tastaturbelegung.
Weiß jemand Rat?
Vielen Dank Jakob
P.S. In dem fraglichen Verzeichnis führt "ls [-a|-l|-al] *" zu derselben Fehlermeldung.
Gesendet: Donnerstag, 15. August 2019 um 17:51 Uhr Von: jm.2009@web.de An: lug-dd@mailman.schlittermann.de Betreff: Fehlermeldung beim Aufruf von ls
Liebe Fachleute,
ich bekommen gerade eine ganz und gar unterwartete Fehlermeldung, wenn ich "ls" im Terminal aufrufe.
Im Verzeichnis befinden sich vier Verzeichnisse und ca. 140 Dateien. Beim Aufruf von "ls -al *.tex" ist alles wie erwartet, auch "ls -al *.tex | wc -l" gibt ein plausibles Ergebnis. Beim Aufruf von "ls -al *.doc" erhalte ich folgende Fehlermeldung: ls: Ungültige Option -- e „ls --help“ liefert weitere Informationen. Dieselbe Fehlermeldung gibt es beim Aufruf von "ls *.doc", "ls -a *.doc" und "ls -l *.doc". Der Aufruf von "ls -al ./*.doc" funktioniert dagegen wie erwartet. In einem anderen Verzeichnis mit .tex- und .doc-Dateien funktioniert "ls -al *.doc" wie erwartet.
Es laufen: Xubuntu 18.04 (4.15.0-58-generic #64-Ubuntu), bash 4.4.20(1)-release (x86_64-pc-linux-gnu), ls (GNU coreutils) 8.28, US-Tastaturbelegung.
Weiß jemand Rat?
Vielen Dank Jakob
jm.2009@web.de jm.2009@web.de (Do 15 Aug 2019 17:51:16 CEST):
Im Verzeichnis befinden sich vier Verzeichnisse und ca. 140 Dateien. Beim Aufruf von "ls -al *.tex" ist alles wie erwartet, auch "ls -al *.tex | wc -l" gibt ein plausibles Ergebnis. Beim Aufruf von "ls -al *.doc" erhalte ich folgende Fehlermeldung: ls: Ungültige Option -- e Dieselbe Fehlermeldung gibt es beim Aufruf von "ls *.doc", "ls -a *.doc" und "ls -l *.doc". Der Aufruf von "ls -al ./*.doc" funktioniert dagegen wie erwartet. In einem anderen Verzeichnis mit .tex- und .doc-Dateien funktioniert "ls -al *.doc" wie erwartet.
Du willst etwas über die Shell lernen. Nicht über „ls“.
Wenn Du eine Datei „-e foo.doc“ und vielleicht noch „x.doc“ in Deinem Verzeichnis hast und dann
ls *.doc
aufrufst, wird die Shell Dir daraus
ls '-efeu.doc' 'x.doc'
machen. „ls“ hat keine Ahnung, daß das „-e“ keine Option sein soll. Du müssstest das im Tracemodus der Shell gut beobachten können:
set -x ls *.doc set +x
Was tut man dagegen? Eine Lösung hast Du schon gefunden
ls ./*.doc
Denn dann wird daraus
ls './-efeu.doc' 'x.doc'
und „ls“ ist glücklich. Das ist der generische Weg. Ein Weg, der bei *vielen* Tools funktioniert, wäre:
ls -- *.doc
Die Option „--“ wird von *vielen* Tools verstanden als „jetzt kommen keine Optionen mehr, auch wenn die weiteren Argumente so aussehen wie Optionen“.
Best regards from Dresden/Germany Viele Grüße aus Dresden Heiko Schlittermann -- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
Am 15.08.19 um 18:15 schrieb Heiko Schlittermann:
jm.2009@web.de jm.2009@web.de (Do 15 Aug 2019 17:51:16 CEST):
Im Verzeichnis befinden sich vier Verzeichnisse und ca. 140 Dateien. [...]
Du willst etwas über die Shell lernen. Nicht über „ls“.
Du (jm.2009) willst vor allem etwas über die Benutzung von Email lernen. Einen Thread mit einem völlig anderen Thema zu kapern ist extrem unhöflich (um's mal nett zu formulieren).
Uwe
Uwe Koloska ml@koloro.de (Fr 16 Aug 2019 10:50:24 CEST):
Du (jm.2009) willst vor allem etwas über die Benutzung von Email lernen. Einen Thread mit einem völlig anderen Thema zu kapern ist extrem unhöflich (um's mal nett zu formulieren).
Ich hatte es ihm in einer PM schon geschrieben. Und *ich* hätte die References-Header entfernen können. Habe *ich* verpaßt.
-- Heiko
Luca Bertoncello lucabert@lucabert.de (Do 15 Aug 2019 10:12:34 CEST):
iface isp0 inet6 static pre-up modprobe ipv6 # Hauptadresse: mail.lucabert.de
Haben wir nicht hier ein Henne-Ei-Problem? Wird sie die Bootsequenz um inet6 Interfaces nur kümmern, wenn ipv6 überhaupt verfügbar ist? Wenn Du das dann aber erst verfügbar machen möchtest … ich weiß nicht.
Aber warum überhaupt das modprobe? Ich würde ja behaupten, daß bei den aktuellen Linuxen ipv6 eigentlich immer an ist. (Ob als Modul oder fest eingebaut.)
Hm. Ich sehe gerade bei mir, es ist gar kein ipv?6 Modul geladen:
Linux blade 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux
ip6_udp_tunnel 16384 1 vxlan nft_chain_nat_ipv6 16384 4 nf_nat_ipv6 16384 1 nft_chain_nat_ipv6 ip6t_REJECT 16384 1 nf_reject_ipv6 16384 1 ip6t_REJECT nf_nat 36864 3 nf_nat_ipv6,nf_nat_ipv4,xt_nat nf_tables 143360 222 nft_chain_route_ipv4,nft_compat,nft_chain_nat_ipv6,nft_chain_nat_ipv4,nft_counter nf_conntrack 163840 10 xt_conntrack,nf_nat,xt_state,nf_conntrack_pptp,nf_nat_ipv6,ipt_MASQUERADE,nf_nat_ipv4,xt_nat,nf_conntrack_netlink,nf_conntrack_proto_gre nf_defrag_ipv6 20480 1 nf_conntrack x_tables 45056 14 xt_conntrack,nft_compat,xt_state,xt_tcpudp,ipt_MASQUERADE,xt_addrtype,xt_CHECKSUM,xt_nat,xt_policy,xt_u32,ipt_REJECT,ip_tables,ip6t_REJECT,xt_mark
Gleichwohl ipv6 zur Verfügung steht. Wenn es bei Dir ebenso ist, dann wäre aber meine obige Vermutung hinfällig.
Ach, ich weiß doch auch nicht…
-- Heiko
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Am 16.08.2019 um 17:14 schrieb Heiko Schlittermann:
Hallo Heiko
Haben wir nicht hier ein Henne-Ei-Problem? Wird sie die Bootsequenz um inet6 Interfaces nur kümmern, wenn ipv6 überhaupt verfügbar ist? Wenn Du das dann aber erst verfügbar machen möchtest … ich weiß nicht.
Nein, IPv6 ist immer verfügbar, die modprobe ist definitiv ein Relikt der alten Sachen und ich habe es entfernt.
Grüße Luca Bertoncello (lucabert@lucabert.de)
Am 16.08.2019 um 17:14 schrieb Heiko Schlittermann:
Luca Bertoncello lucabert@lucabert.de (Do 15 Aug 2019 10:12:34 CEST):
iface isp0 inet6 static pre-up modprobe ipv6 # Hauptadresse: mail.lucabert.de
Haben wir nicht hier ein Henne-Ei-Problem? Wird sie die Bootsequenz um inet6 Interfaces nur kümmern, wenn ipv6 überhaupt verfügbar ist? Wenn Du das dann aber erst verfügbar machen möchtest … ich weiß nicht.
Mir ist übrigens eine Sache gerade eingefallen und zwar, bei einem anderen Server, mit der gleichen Installation, habe ich auch die selbe Konfiguration in /etc/network/interfaces, aber IPv6 wird sofort geladen. Der einzige Unterschied ist, dass die Schnittstelle eth0 nicht in isp0 umbenannt worden ist...
Vielleicht ist es ein Anfangspunkt?
Danke Luca Bertoncello (lucabert@lucabert.de)
lug-dd@mailman.schlittermann.de
-
Heiko Schlittermann -
Henri Wahl -
Hilmar Preuße -
jm.2009＠web.de -
Luca Bertoncello -
Uwe Koloska