Systemd kaputt?

[Tim Ritberg]

Hallo again :-)

Ich hätte es ja im allgemeinen systemd-nörgel-Thread posten können, aber
ich kann noch nicht genau sagen, ob systemd wirklich schuld ist.

Ich habe hier zwei Server mit Ubuntu 18 und syslog-ng. Beide haben die
selbe Config.
Vor ein paar Tagen fing einer der Server an, nicht mehr Logs zu
schreiben. Die Verbindung zwischen systemd und syslog-ng scheint gestört.

Die Logs sind alle fast leer, er mag nur seinen eigenen Reload loggen.

Neustart hilft nicht, Neuinstallation systemd ebenso wenig. Mir gehen
die Ideen aus.

Tim

[Marcel Mueller]

Am 19.03.21 um 18:11 schrieb Tim Ritberg:

> Die Logs sind alle fast leer, er mag nur seinen eigenen Reload loggen.

Schreibt systemd noch seine kryptischen Binärlogs?


Marcel

[Tim Ritberg]

Am 19.03.21 um 18:54 schrieb Marcel Mueller:

> Am 19.03.21 um 18:11 schrieb Tim Ritberg:
>> Die Logs sind alle fast leer, er mag nur seinen eigenen Reload loggen.
>
> Schreibt systemd noch seine kryptischen Binärlogs?
>

Ja. Logger schreibt da auch rein, hatte ich extra getestet.

Tim

[Marc Haber]

Wie "herum" ist das logging in deinem Ubuntu konfiguriert? Zuerst
systemd-journal, dann rsyslog, oder andersrum? Wem gehört /dev/log?

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Tim Ritberg]

Am 20.03.21 um 09:16 schrieb Marc Haber:

> Wie "herum" ist das logging in deinem Ubuntu konfiguriert? Zuerst
> systemd-journal, dann rsyslog, oder andersrum? Wem gehört /dev/log?

Ubuntu-Standard, Systemd zuerst.

root root 28 Mär 19 16:10 /dev/log -> /run/systemd/journal/dev-log


Tim

[Tim Ritberg]

Am 20.03.21 um 10:54 schrieb Tim Ritberg:

Ich habe mal einen Debugversuch gemacht:
socat -t100 -x -v UNIX-LISTEN:syslog-ng.ctl,mode=777,reuseaddr,fork
UNIX-CONNECT:syslog-ng.ctl.org

kommt nichts an. Somit würde ich mal sagen, systemd verkackt es.

Tim

[Marc Haber]

Tim Ritberg <t...@server.invalid> wrote:
>Somit würde ich mal sagen, systemd verkackt es.

So sieht es aus. Ursache dürfte ein Paketierungsfehler seitens Ubuntu
sein.

[Tim Ritberg]

Am 21.03.21 um 19:04 schrieb Marc Haber:

> Tim Ritberg <t...@server.invalid> wrote:
>> Somit würde ich mal sagen, systemd verkackt es.
>
> So sieht es aus. Ursache dürfte ein Paketierungsfehler seitens Ubuntu
> sein.

Könnte, aber sehr unwahrscheinlich, weil ich einen Klon vom System habe,
der kein Problem hat.

Tim

[Tim Ritberg]

Am 21.03.21 um 19:22 schrieb Tim Ritberg:

Ich hab jetzt die Maschine neu installiert. Die Config ist wie vorher
und jetzt läuft es. Was auch immer da vorher kaputt war, es ließ sich
nicht ordentlich debuggen :-(

Tim

[Tim Ritberg]

Am 24.03.21 um 11:19 schrieb Michael Bäuerle:

>
> - Retry
> - Reboot
> - Reinstall

ja, mit purem syslog-ng wäre das nicht passiert....

Tim

[Marc Haber]

Tim Ritberg <t...@server.invalid> wrote:
>Ich hab jetzt die Maschine neu installiert. Die Config ist wie vorher
>und jetzt läuft es. Was auch immer da vorher kaputt war, es ließ sich
>nicht ordentlich debuggen :-(

Komplett /etc vergeichen hätte vielleicht geholfen und Wissen
aufgebaut.

[Tim Ritberg]

Am 24.03.21 um 19:01 schrieb Marc Haber:

> Tim Ritberg <t...@server.invalid> wrote:
>> Ich hab jetzt die Maschine neu installiert. Die Config ist wie vorher
>> und jetzt läuft es. Was auch immer da vorher kaputt war, es ließ sich
>> nicht ordentlich debuggen :-(
>
> Komplett /etc vergeichen hätte vielleicht geholfen und Wissen
> aufgebaut.
>

find keine Änderungen gezeigt. Und man weiß jetzt schon, dass systemd
eine sinnlose ABM ist.

Tim

[Kay Martinen]

Am 24.03.21 um 19:29 schrieb Tim Ritberg:

Oha, das gibt Mecker von Marc (die ich auch schon kassierte). ;-)

Definiere "man" == Teppichetage von $Firma?


Kay

--
Posted via leafnode

[Tim Ritberg]

Am 24.03.21 um 21:04 schrieb Kay Martinen:

>
> Oha, das gibt Mecker von Marc (die ich auch schon kassierte). ;-)
>
> Definiere "man" == Teppichetage von $Firma?

Der informierte Linuxadmin.

Tim

[Marc Haber]

Tim Ritberg <t...@server.invalid> wrote:
>Und man weiß jetzt schon, dass systemd
>eine sinnlose ABM ist.

Für mich ist es eine Arbeitsreduktion. Und das ist gut so.

[Marc Haber]

Tim Ritberg <t...@server.invalid> wrote:
>Der informierte Linuxadmin.

Lall.

[Tim Ritberg]

Am 25.03.21 um 08:16 schrieb Marc Haber:

> Tim Ritberg <t...@server.invalid> wrote:
>> Und man weiß jetzt schon, dass systemd
>> eine sinnlose ABM ist.
>
> Für mich ist es eine Arbeitsreduktion. Und das ist gut so.
>

Wo ist da eine Reduktion, wenn man mit systemd mehr Probleme hat als vorher?

Systemd hat Linux Stabilität genommen, eindeutig.

Tim

[Marc Haber]

Tim Ritberg <t...@server.invalid> wrote:
>Systemd hat Linux Stabilität genommen, eindeutig.

Das sehe ich anders. Du hast noch nicht genug Lebenszeit mit
Initscripten verschwendet. Aber wir werden hier nicht über ein "agree
to disagree" hinweg kommen. Hast Du die Größe dazu?

[Tim Ritberg]

Am 25.03.21 um 13:43 schrieb Marc Haber:

> Tim Ritberg <t...@server.invalid> wrote:
>> Systemd hat Linux Stabilität genommen, eindeutig.
>
> Das sehe ich anders. Du hast noch nicht genug Lebenszeit mit
> Initscripten verschwendet. Aber wir werden hier nicht über ein "agree
> to disagree" hinweg kommen. Hast Du die Größe dazu?
>

"Nicht genug"...ich nutze Linux seit 1996. 20 Jahre hat das super
funktioniert und dann kam systemd.

Tim

[Kay Martinen]

Am 25.03.21 um 13:43 schrieb Marc Haber:

> Tim Ritberg <t...@server.invalid> wrote:
>> Systemd hat Linux Stabilität genommen, eindeutig.
>
> Das sehe ich anders. Du hast noch nicht genug Lebenszeit mit
> Initscripten verschwendet.

Was mich angeht: Stimmt! Schreibend 0,0x-irgendwas (skeleton-copy/edit
:) Lesend: Etliche male bei Fehlersuchen.

Aber ich Programmiere nicht, ich benutze nur Linux. Und das ungefähr
seit 1991 (davor anderes).

Und auch wenn das manchmal nicht hörbar wird oder ich mit etwas nicht
einverstanden bin, so bin ich doch Dankbar für die Geleistete Arbeit all
jener die sich schreibend dran beteiligt haben. Ohne diese Investition
wäre es nicht das was es heute ist.

Ja Marc, damit meine ich auch dich. Danke!

> Aber wir werden hier nicht über ein "agree
> to disagree" hinweg kommen. Hast Du die Größe dazu?

Wenn du damit meinst das wir darin übereinstimmen das wir anderer
Meinung sind, dann ja. Zustimmung!

Falls es nicht klar war. Ich hab keine Feste meinung zu systemd. Ich
sehe für mich (noch) keine Vorteile aber Nachteile. Daher meine
Ablehnung. Ich benutze es aber weil's nun mal da und drauf ist. Ebenso
benutze ich andere Systeme (EISFAIR) die SysV nutzen.

EoT, wenn du magst.

[Christian Garbs]

Mahlzeit!

Marcus Jodorf <tr...@killfile.de> wrote:

> Aber letztlich finde ich das schon etwas traurig. Jedenfalls war systemd
> zumindest keinerlei Zugewinn an Stabilität und ich hab auch einfach mehr
> weggeknallte Systeme in den letzten Jahren erlebt als im Jahrzehnt
> davor.

Dass systemd mal beim Booten[1] oder Runterfahren hakt und hängt, habe
ich auch schon erlebt, aber das klingt jetzt so wie "im laufenden
Betrieb abgestürzt". Wie hat systemd denn da die Finger drin?

Gruß
Christian

[1] Debian hier.

Ich benutze ZFS aus den Backports - ein System, das nur ZFS hat, lief
problemlos, aber das andere System, auf dem ich nur ein paar
Partitionen auf ZFS umgestellt hatte, kam mit den gemischten Mounts
vorne und hinten nicht zurecht. Da musste ich erstmal eigene Units
schreiben, damit z.B. der inn erst startet, wenn auch /var/spool/news
(ZFS) gemounted ist. Das normale lokal-fs-Target funktionierte nicht.
Das scheint mit den ZFS 2.0-Paketen besser geworden zu sein, meine
Unit konnte ich wieder löschen. Demnach war es vielleicht auch nur
eine unsaubere systemd-Konfiguration in den ZFS-0.8-Paketen.

Und seit ich in meiner /etc/network/interfaces alle Netzwerkkarten auf
allow-hotplug umgestellt habe, wartet systemd nicht mehr bei jedem
Boot eine Minute in der Gegend rum. Mit systemd-networking wäre das
vielleicht nicht passiert, aber ich verteile die dynamischen IPv6-Präfixe
von der FritzBox intern weiter, das geht glaube ich mit
systemd-networking nicht.
Auch da bin ich seit "allow-hotplug" glücklich.
--
....Christian.Garbs....................................https://www.cgarbs.de
Windows 98 doesn't support b/w displays -
they can't display the blue screen.

[Sebastian Suchanek]

Am 26.03.2021 um 09:46 schrieb Christian Garbs:

> [...]

> Und seit ich in meiner /etc/network/interfaces alle Netzwerkkarten auf
> allow-hotplug umgestellt habe, wartet systemd nicht mehr bei jedem
> Boot eine Minute in der Gegend rum. Mit systemd-networking wäre das
> vielleicht nicht passiert, aber ich verteile die dynamischen IPv6-Präfixe

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> von der FritzBox intern weiter, das geht glaube ich mit

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> systemd-networking nicht.
> Auch da bin ich seit "allow-hotplug" glücklich.

Kannst Du das 'mal näher beschreiben?
Wenn Du das meinst, von dem ich denke, das Du es meinst ;-) wäre das für
mich auch interessant.


Tschüs,

Sebastian

[Marc Haber]

Das Schlüsselwort ist Prefix Delegation und findet sich oft zusammen
mit DHCPv6.

Grüße
Marc

[Christian Garbs]

Mahlzeit!

Aus dem Effeff nicht, mir fiel heute morgen beim Posten schon der
Fachbegriff nicht mehr ein ;-) Marcs Stichworte Prefix Delegation und
dhcpv6 sind richtig.

Ich kann nächste Woche mal raussuchen, was ich da genau gemacht habe.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
You may be sure that when a man begins to call himself a "realist," he
is preparing to do something he is secretly ashamed of doing.
(Sydney Harris)

[Marc Haber]

Christian Garbs <mi...@cgarbs.de> wrote:
>Und seit ich in meiner /etc/network/interfaces alle Netzwerkkarten auf
>allow-hotplug umgestellt habe, wartet systemd nicht mehr bei jedem
>Boot eine Minute in der Gegend rum. Mit systemd-networking wäre das
>vielleicht nicht passiert, aber ich verteile die dynamischen IPv6-Präfixe
>von der FritzBox intern weiter, das geht glaube ich mit
>systemd-networking nicht.

Neuerer systemd-networkd kann Prefix Delegation. Mich würde
intressieren, wie Du das "klassisch" machst, da systemd-networkd
bestimmt noch ein paar Debian-Releases braucht bis das brauchbar
funktioniert (ich extrapoliere hier von den Erfahrungen mit dem
'normalen' IPv6-Support in systemd-networkd, der anfänglich an
etlichen Stellen wirklich grotesk kaputt war).

Grüße
Marc

[Juergen Ilse]

Hallo,

Marc Haber <mh+usene...@zugschl.us> wrote:
> Sebastian Suchanek <sebastian...@gmx.de> wrote:
>>Am 26.03.2021 um 09:46 schrieb Christian Garbs:
>>
>>> [...]
>>> Und seit ich in meiner /etc/network/interfaces alle Netzwerkkarten auf
>>> allow-hotplug umgestellt habe, wartet systemd nicht mehr bei jedem
>>> Boot eine Minute in der Gegend rum. Mit systemd-networking wäre das
>>> vielleicht nicht passiert, aber ich verteile die dynamischen IPv6-Präfixe
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> von der FritzBox intern weiter, das geht glaube ich mit
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> systemd-networking nicht.
>>> Auch da bin ich seit "allow-hotplug" glücklich.
>>
>>Kannst Du das 'mal näher beschreiben?
>>Wenn Du das meinst, von dem ich denke, das Du es meinst ;-) wäre das für
>>mich auch interessant.
>
> Das Schlüsselwort ist Prefix Delegation und findet sich oft zusammen
> mit DHCPv6.

Prefix Delegation ist Teil von DHCPv6. Bei IPv4 gibt es dafuer keine
Entsprechende im DHCP. Die Idee ist, dass ein Router per DHCPv6 einen
ganzen Bereich von Prefixen fuer die Weiterverteilung (auf andere Netz-
werkinterfaces oder wiederum per Prefix Delegation an weitere Router)
anfordern kann.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Kay Martinen]

Am 27.03.21 um 15:56 schrieb Juergen Ilse:

>
> Marc Haber <mh+usene...@zugschl.us> wrote:
>> Sebastian Suchanek <sebastian...@gmx.de> wrote:
>>> Am 26.03.2021 um 09:46 schrieb Christian Garbs:
>>>
>>>> [...]

>>>> vielleicht nicht passiert, aber ich verteile die dynamischen IPv6-Präfixe
>>>

>>> Kannst Du das 'mal näher beschreiben?
>>> Wenn Du das meinst, von dem ich denke, das Du es meinst ;-) wäre das für
>>> mich auch interessant.

Dito aber bei mir vermutlich eh nicht möglich. Speedport Hybrid!

>> Das Schlüsselwort ist Prefix Delegation und findet sich oft zusammen
>> mit DHCPv6.
>
> Prefix Delegation ist Teil von DHCPv6. Bei IPv4 gibt es dafuer keine
> Entsprechende im DHCP. Die Idee ist, dass ein Router per DHCPv6 einen
> ganzen Bereich von Prefixen fuer die Weiterverteilung (auf andere Netz-
> werkinterfaces oder wiederum per Prefix Delegation an weitere Router)
> anfordern kann.

So wie du's beschreibst klingt es ein wenig nach "Magie".

Aber: Nötig wären AFAIK

1. Ein (WAN)Router der mehr als ein Präfix zugleich raus rückt.
Muß der darüber eigentlich buch führen?

2. Ein Router mit dhcp6 der bei 1. ein /64 anfordert und es dann auf
seinem inneren Interface verteilt (RA mit radvd oder stateful dhcp?) an
3. Heißt dann auch das alle IPv6 Adressen mit der Net-ID dieses Präfixes
von dem Router einfach durchgeleitet werden zu 1. oder? Ein Paketfilter
dort muß also mit diesen IPv6 Adressen arbeiten - die sich außerdem auch
mal ändern können. Wie soll das sinnvoll gehen?

3. Clients die IPv6 "richtig" können sollten *Alle* sein (heute)?

Mein Problem ist der Zwangsläufig einzig mögliche Router - der zwar ein
/56 bezieht, intern aber offensichtlich nur ein Einzelnes /64 raus
rückt. UND: Kleiner als ein /64 darf es nicht sein weil sonst die ganzen
Automatismen, Regularien o.a. nicht richtig funktionieren, auf die
Fresse fallen oder sonst was. So heißt es!

Geht's wirklich nicht mit kleineren Präfixen und IPv6 im Internen LAN?
Liegt das an einer tieferen Implementation dieser Grenze im Protokoll -
bei Linux (und anderen)?

[Juergen Ilse]

Hallo,

Kay Martinen <use...@martinen.de> wrote:
> Am 27.03.21 um 15:56 schrieb Juergen Ilse:
>>
>> Marc Haber <mh+usene...@zugschl.us> wrote:
>>> Sebastian Suchanek <sebastian...@gmx.de> wrote:
>>>> Am 26.03.2021 um 09:46 schrieb Christian Garbs:
>>>>
>>>>> [...]
>>>>> vielleicht nicht passiert, aber ich verteile die dynamischen IPv6-Präfixe
>>>>
>>>> Kannst Du das 'mal näher beschreiben?
>>>> Wenn Du das meinst, von dem ich denke, das Du es meinst ;-) wäre das für
>>>> mich auch interessant.
>
> Dito aber bei mir vermutlich eh nicht möglich. Speedport Hybrid!

Richtig. Die Speedports beherrschen das leider alles nicht. Sie bekommen
zwar einen Range von 256 aufeinander folgenden Prefixen per Prefix Delegation
bereitgestellt, nutzen dieses aber nur, um *eines* davon anzufordern und
auf das Ethernet zu routen ... Sie haben auch auf dem Ethernet immer die
link local Adresse fe80::1 (nicht konfigurierbar), weshalb man keine zwei
Speedports im selben Ethernet-Segment als IPv6 Router betreiben kann ...
Es ist halt die "Sparversion" eines IPv6 Routers ...

>>> Das Schlüsselwort ist Prefix Delegation und findet sich oft zusammen
>>> mit DHCPv6.
>>
>> Prefix Delegation ist Teil von DHCPv6. Bei IPv4 gibt es dafuer keine
>> Entsprechende im DHCP. Die Idee ist, dass ein Router per DHCPv6 einen
>> ganzen Bereich von Prefixen fuer die Weiterverteilung (auf andere Netz-
>> werkinterfaces oder wiederum per Prefix Delegation an weitere Router)
>> anfordern kann.
>
> So wie du's beschreibst klingt es ein wenig nach "Magie".

Ist es aber nicht. In der Konfiguration der Prefix Delegation wird fest-
gelegt, aus welchem Pool von Prefixen Prefixe vergeben werden, und wie
gross die Prefixe sind. So ist es moeglich, statt /64 Prefixe (die sich
nicht weiter subnettieren kann) z.B. /56 Prefixe zu verteilen, und ein
Router, der ein solches empfangen hat, kann dieses (oder einen Teil
davon) wieder als Pool fuer eine weitere Prefix Delegation verwenden
(auch das muss dann aber im jeweiligen Router konfiguriert werden).
Angeblich sollen die Fritzboxen (zumindest mit haalbwegs aktueller
Firmware) Prefix Delegation unterstuetzen, aber ich hatte noch nie
eine Fritzbox unter den Fingern, solange ich mich mit naeher mit IPv6
beschaeftigt habe ...

> - die sich außerdem auch
> mal ändern können. Wie soll das sinnvoll gehen?

Ueblicherweise unterstuetzen Router, die prefix Delegation unterstuetzen,
auch eine Art von "Benennung" der zugewiesenen Prefixe, und die Ziel-
Adressen, mit denen der Paketfilter arbeiten soll, werden anhand des
"Namens" als "Offset zum zugewiesenen Prefix" angegeben. Wie das genau
in der Konfiguration aussieht, kann sich je nach Hersteller unterscheiden.

> 3. Clients die IPv6 "richtig" können sollten *Alle* sein (heute)?

So ziemlich (laut RFC6540 muss ein Geraet, das als IP faehig deklariert ist,
auch IPv6 koennen, ansonsten sollte es nur als "IPv4 faehig" bezeichnet sein).

> Mein Problem ist der Zwangsläufig einzig mögliche Router - der zwar ein
> /56 bezieht, intern aber offensichtlich nur ein Einzelnes /64 raus
> rückt.

Ja, das ist ein Problem. Eine Moeglichkeit waere es, den Router als reines
PPPoE Modem zu verwenden, und einen anderen Router mit ´den benoetigtwen
Eigenschaften dahinter zu betreiben. Das koennte z.B. ein OpenWRT Router
sein (der kann mit PRefix Delegation umgehen). Allerdings beherrscht ein
OpenWRT Router keine Telefonie (man koennte aber z.B. IP-Telefone dahinter
betreiben).

> UND: Kleiner als ein /64 darf es nicht sein weil sonst die ganzen
> Automatismen, Regularien o.a. nicht richtig funktionieren, auf die
> Fresse fallen oder sonst was. So heißt es!

Ja. /64 ist quasi die "minimal verwendbare Netzgroesse" (ausser fuer
reine Point-to-Point Links, daa kann man auch /127 verwenden).

> Geht's wirklich nicht mit kleineren Präfixen und IPv6 im Internen LAN?

Theoretisch ja, aber das entspricht nicht dem standard und es gibt evt.
mit diversen Endgeraeten Probleme, weil die nicht damit umgehen koennen.
Wenn es funktioniert, waere das eher Zufall ...

> Liegt das an einer tieferen Implementation dieser Grenze im Protokoll -
> bei Linux (und anderen)?

Bestimmte Teile dees Standards (z.B. SLAAC) setzen voraus, dass das lokale
Netz mindestens diese Groesse hat.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Diedrich Ehlerding]

Juergen Ilse meinte:

> Angeblich sollen die Fritzboxen (zumindest mit haalbwegs aktueller
> Firmware) Prefix Delegation unterstuetzen,

Ja (sagen sie jedenfalls in ihrer Admin-GUI).
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

[Marc Haber]

Juergen Ilse <ne...@usenet-verwaltung.de> wrote:

>Kay Martinen <use...@martinen.de> wrote:
>> Mein Problem ist der Zwangsläufig einzig mögliche Router - der zwar ein
>> /56 bezieht, intern aber offensichtlich nur ein Einzelnes /64 raus
>> rückt.
>
>Ja, das ist ein Problem. Eine Moeglichkeit waere es, den Router als reines
>PPPoE Modem zu verwenden, und einen anderen Router mit ´den benoetigtwen
>Eigenschaften dahinter zu betreiben.

Du weißt nicht so genau, was ein Hybrid-Anschluss ist, oder?

[Marcel Logen]

Diedrich Ehlerding in de.comp.os.unix.linux.misc:

>Juergen Ilse meinte:

>> Angeblich sollen die Fritzboxen (zumindest mit haalbwegs aktueller
>> Firmware) Prefix Delegation unterstuetzen,
>
>Ja (sagen sie jedenfalls in ihrer Admin-GUI).

Hat jetzt AFAICS nicht direkt mit "prefix delegation" zu tun,
da es bei mir nicht um einen nachgelagerten Router geht, son-
dern um angeschlossene PC:

Meine FRITZ!Box 7590 (mit FRITZ!OS 07.25) vergibt an die
angeschlossenen Rechner offenbar immer nur das /64-Netz
"00", Beispiel:

| inet6 2003:e6:702:c200:7d7c:f0aa:7b26:5b6e prefixlen 64 autoconf temporary pltime 1508 vltime 6908
^^

Ich habe an dieser Stelle (mit der FRITZ!Box) noch nie
etwas anderes als "00" gesehen, außer als ich einmal im
FRITZ!Box-WLAN-Gastnetz eingeloggt war. Da stand dann
dort eine "01".

Ob diese 'Netz-ID' in der FRITZ!Box konfigurierbar ist,
habe ich noch nicht herausgefunden.

Seltsamerweise wird mir in der Admin-Oberfläche unter
"Heimnetz | Netzwerk | Netzwerkeinstellungen | IPv6-
Einstellungen" (alles in der erweiterten Ansicht) ganz
unten nichts angezeigt:

| Verwendete IPv6 Präfixe:
| Heimnetz - / -
| Gastnetz - / -

Marcel
--
╭────╮ ╭───╮ ╭───────╮ ╭──╮ ╭─────────╮ ╭─╮ ╭───
╰──╮ │ ╰─╮ │ │ ╭─╯ ╭───╮ │ ╰─╮ ╰──────╮ ╰─╯ ╰──╮ ╰──╮
╮ │ ╰──╮ │ ╰─────╯ ╭─╯ ╰─╮ │ ╭────╯ │ ╭──╮ │ ╭─────╯ ╭──╯
╰───╯ ╰─╯ ╰───────╯ ╰─╯ ╰───╯ ╰──╯ ╰────────╯

[Diedrich Ehlerding]

Marcel Logen meinte:

>>> Angeblich sollen die Fritzboxen (zumindest mit haalbwegs aktueller
>>> Firmware) Prefix Delegation unterstuetzen,
>>
>>Ja (sagen sie jedenfalls in ihrer Admin-GUI).
>
> Hat jetzt AFAICS nicht direkt mit "prefix delegation" zu tun,
> da es bei mir nicht um einen nachgelagerten Router geht, son-
> dern um angeschlossene PC:
>
> Meine FRITZ!Box 7590 (mit FRITZ!OS 07.25) vergibt an die
> angeschlossenen Rechner offenbar immer nur das /64-Netz
> "00", Beispiel:
>
> | inet6 2003:e6:702:c200:7d7c:f0aa:7b26:5b6e prefixlen 64 autoconf
> | temporary pltime 1508 vltime 6908

Ja, im normalen Netz benutzen sie nur eiones ihrer /64-Netze. aind ja
auch genug Adressen.

Du jkannst aber, statt eines Repeaters, eine zweite Fritzbox in den
lokales Netz hängen und die nicht als Repeater, sondern als weiteren
Router betreiben - dann bekommt die über irgendein IPv6-Protokoll von
der ersten Fritzbox ein Präfix delegiert.

Vielleicht musst du deinen PC selbst als Router konfigurieren (ich habe
aber keine Ahnung, wie das mit IPv6 geht. Dann kann dein PC als
nachgelagerter Router selber ein weiteres Subnetz abfrühstücken,falls in
deinem Haushalt ein /64-Netz tatsächlich zu klein sein sollte ...

[Marcel Logen]

Diedrich Ehlerding in de.comp.os.unix.linux.misc:

>Marcel Logen meinte:

>> Meine FRITZ!Box 7590 (mit FRITZ!OS 07.25) vergibt an die
>> angeschlossenen Rechner offenbar immer nur das /64-Netz
>> "00", Beispiel:
>>
>> | inet6 2003:e6:702:c200:7d7c:f0aa:7b26:5b6e prefixlen 64 autoconf
>> | temporary pltime 1508 vltime 6908
>
>Ja, im normalen Netz benutzen sie nur eiones ihrer /64-Netze. aind ja
>auch genug Adressen.

Klar, aber Adressen brauche ich nur ein paar wenige. Mir geht
es eher darum, die "00" da wegzubekommen. (Ja, ich weiß, das
ist ein 'Luxus-Problem'. ;-)

Ich hatte kürzlich einen Speedport W 724V Typ C in den Fin-
gern. Bei dem war es IIRC so, daß er auch von der Telekom
ein /56 bezog und dann ein /64 für das interne Netz nutzte,
aber diese (ich sage mal) 'Netz-ID' des /64 war nicht "00",
sondern irgend etwas anderes (z. B. "3f").

Marcel
--
╭──╮ ╭────╮ ╭──────────╮ ╭─╮ ╭─╮ ╭────╮ ╭─────╮
│ ╰──╮ ╭────╮ ╰─╮ ╰──╮ ╰───────╮ ╰─╯ ╰──╯ ╰─╯ ╭─╯ ╭──╯ ╰─╮
╯ ╭──╯ │ ╰─╮ ╰──╮ ╰──╮ ╭─╮ ╰─────╮ ╰─────╯ ╭───────╯
╰─────╯ ╰─────╯ ╰──╯ ╰────────╯ ╰─────────

[Diedrich Ehlerding]

Marcel Logen meinte:

> Klar, aber Adressen brauche ich nur ein paar wenige. Mir geht
> es eher darum, die "00" da wegzubekommen. (Ja, ich weiß, das
> ist ein 'Luxus-Problem'. ;-)
>
> Ich hatte kürzlich einen Speedport W 724V Typ C in den Fin-
> gern. Bei dem war es IIRC so, daß er auch von der Telekom
> ein /56 bezog und dann ein /64 für das interne Netz nutzte,
> aber diese (ich sage mal) 'Netz-ID' des /64 war nicht "00",
> sondern irgend etwas anderes (z. B. "3f").

Je nun, dann hat der Speedport eben woanders angefangen. Aber er benutzt
auch nur ein /64-Subnetz. Ich kann mir nicht vorstellen, dass die
Telekom an ihren abgespeckten Routern zulässt, dass die Kunden IPv6-
Einstellungen ändern ...

Die Fritzbox sagt ganz klar (Heimnetz / Netzwerk / Netzwerkeinstellungen
/ (ganz unten) IP-Adressen + IPv6-Einstellungen / (ganz unten)
vertwedndete Netzzsegmente, dass sie fürs Heimnetz die 00 und fürs
Gastnetz die 01 verwendet (klar, muss ne andere sein, damit die nicht
miteinander reden können; sie verwendet ja auch ein anderes (privates)
Subnetz fürs IPv4-Gastnetz).

[Marc Haber]

Thomas Noll <-_tn...@web.de> wrote:

>Am Wed, 31 Mar 2021 10:32:20 +0200 schrieb Marc Haber:
>
>> Juergen Ilse <ne...@usenet-verwaltung.de> wrote:
>>>Kay Martinen <use...@martinen.de> wrote:
>>>> Mein Problem ist der Zwangsläufig einzig mögliche Router - der zwar ein
>>>> /56 bezieht, intern aber offensichtlich nur ein Einzelnes /64 raus
>>>> rückt.
>>>
>>>Ja, das ist ein Problem. Eine Moeglichkeit waere es, den Router als reines
>>>PPPoE Modem zu verwenden, und einen anderen Router mit ´den benoetigtwen
>>>Eigenschaften dahinter zu betreiben.
>>
>> Du weißt nicht so genau, was ein Hybrid-Anschluss ist, oder?
>

>Ein Hybrid-Anschluss ist das Rückfallthema, falls Kay grad nichts besseres
>findet, worüber er sich ärgern kann ;)

Das liegt an dem bescheidenen Zwangsrouter, den sein Internetprovider
ihm aufdrückt, dieses Gerät ist halt telekomtypisch fabrikneuer
unbrauchbarer Sondermüll.

[Kay Martinen]

Am 31.03.21 um 19:43 schrieb Diedrich Ehlerding:

> Marcel Logen meinte:
>
>> Klar, aber Adressen brauche ich nur ein paar wenige. Mir geht
>> es eher darum, die "00" da wegzubekommen. (Ja, ich weiß, das
>> ist ein 'Luxus-Problem'. ;-)
>>
>> Ich hatte kürzlich einen Speedport W 724V Typ C in den Fin-
>> gern. Bei dem war es IIRC so, daß er auch von der Telekom
>> ein /56 bezog und dann ein /64 für das interne Netz nutzte,
>> aber diese (ich sage mal) 'Netz-ID' des /64 war nicht "00",
>> sondern irgend etwas anderes (z. B. "3f").
>
> Je nun, dann hat der Speedport eben woanders angefangen. Aber er benutzt
> auch nur ein /64-Subnetz. Ich kann mir nicht vorstellen, dass die
> Telekom an ihren abgespeckten Routern zulässt, dass die Kunden IPv6-
> Einstellungen ändern ...

Tun sie nicht. Du kannst beim Speedport Hybrid nur die ULA einschalten
und einen 4-stelligen Wert im 4. Zahlenblock selbst wählen. Danach kommt
nur noch :::1 Und die drei Blöcke davor sind nicht änderbar. Hier
fd50:1549:xxxx

Alles weitere ist nur Anzeige und nicht änderbar. Dhcp ist überhaup nur
für IPv4 Einstellbar.

Ich denke die zusätzlichen Prefixe werden vom "Telekom Datenschutz"
verwendet um die Adressen nach Zeit X durch zu wechseln. Das wird sich
wohl auch oben bei Marcel in der höheren Zahl niederschlagen, denke ich.

Steht als info auch im Online-Hilfetext meines Gerätes.

-snip-
Für Interessierte:
Diese Funktion wechselt alle 24 Stunden einen Teil Ihrer IPv6-Adresse,
ohne die Internetverbindung zu unterbrechen. Die Telekom weist Ihnen ein
IPv6-Präfix zu, aus dem 256 unterschiedliche Netz-Präfixe gebildet
werden können. Die Funktion wählt zufällig ein Netz-Präfix für die
Bildung der IPv6-Adresse aus.
-snap-

Man kann diesen Adress-wechsel auch Ausschalten. Dann sollen die
Adressen immer gleich bleiben. Aber an zu nehmen das man dann mehr als
ein Präfix von einem Speedport (Hybrid?) bekäme erscheint mir zu kühn.

Zumindest Theoretisch sollten dann aber 255 Präfixe brach liegen -
dauerhaft. Bis zum Reboot oder neuverbinden des Gerätes!

[Kay Martinen]

Am 31.03.21 um 20:09 schrieb Marc Haber:

> Thomas Noll <-_tn...@web.de> wrote:
>> Am Wed, 31 Mar 2021 10:32:20 +0200 schrieb Marc Haber:
>>
>>> Juergen Ilse <ne...@usenet-verwaltung.de> wrote:
>>>> Kay Martinen <use...@martinen.de> wrote:
>>>>> Mein Problem ist der Zwangsläufig einzig mögliche Router - der zwar ein
>>>>> /56 bezieht, intern aber offensichtlich nur ein Einzelnes /64 raus
>>>>> rückt.
>>>>
>>>> Ja, das ist ein Problem. Eine Moeglichkeit waere es, den Router als reines
>>>> PPPoE Modem zu verwenden, und einen anderen Router mit ´den benoetigtwen
>>>> Eigenschaften dahinter zu betreiben.
>>>
>>> Du weißt nicht so genau, was ein Hybrid-Anschluss ist, oder?
>>
>> Ein Hybrid-Anschluss ist das Rückfallthema, falls Kay grad nichts besseres
>> findet, worüber er sich ärgern kann ;)
>
> Das liegt an dem bescheidenen Zwangsrouter, den sein Internetprovider
> ihm aufdrückt, dieses Gerät ist halt telekomtypisch fabrikneuer
> unbrauchbarer Sondermüll.

Nun, es liegt *auch* an mir, der die Entscheidung dafür traf. Die aber
von verschiedenen Praktischen Erwägungen beeinflußt wurde. Das ist dann
halt so lange ein "Locked-In" bis es Hybrid-Router von anderen Firmen
geben würde - und diese Kompatibel dazu wären.

AVM hatte mal einen angekündigt. Daraus ist aber offenbar nichts
geworden. Ich hatte ja anfangs drauf gehofft das es mehr Geräte geben
würde und welche die mehr können. Tja! :-)

[Diedrich Ehlerding]

Kay Martinen meinte:

> Zumindest Theoretisch sollten dann aber 255 Präfixe brach liegen -
> dauerhaft. Bis zum Reboot oder neuverbinden des Gerätes!

Angesichts des exorbitanten IPv6-Adressraums ist das Brachliegen
verschmerzbar. Wenn nur ein /64-Netz verwendet wird, hat der User die
srausame Einschränkung zu trage, dass er nur 2³²mal so viele Rechner in
seinem Heimnetz haben darf, wie es insgesamt auf der ganzen Welt IPv4-
Adressen gibt ... wie soll er damit nur zurechtkommen ..,

[Marcel Logen]

Diedrich Ehlerding in de.comp.os.unix.linux.misc:

>Marcel Logen meinte:

>> Klar, aber Adressen brauche ich nur ein paar wenige. Mir geht
>> es eher darum, die "00" da wegzubekommen. (Ja, ich weiß, das
>> ist ein 'Luxus-Problem'. ;-)

[...]

>Die Fritzbox sagt ganz klar (Heimnetz / Netzwerk / Netzwerkeinstellungen
>/ (ganz unten) IP-Adressen + IPv6-Einstellungen / (ganz unten)
>vertwedndete Netzzsegmente, dass sie fürs Heimnetz die 00 und fürs
>Gastnetz die 01 verwendet (klar, muss ne andere sein, damit die nicht
>miteinander reden können; sie verwendet ja auch ein anderes (privates)
>Subnetz fürs IPv4-Gastnetz).

Bei mir steht da - wie gesagt - jeweils nur "- / -".

Vielleicht liegt das aber auch daran, daß ich darüber
folgendes eingestellt habe:

| DHCPv6-Server im Heimnetz
|
| (o) DHCPv6-Server in der FRITZ!Box für das Heimnetz aktivieren:
|
| Wählen Sie aus, welche Informationen der DHCPv6-Server im
| Heimnetz bereitstellen soll.
|
| (o) Nur DNS-Server zuweisen
|
| FRITZ!Box wird als DNS-Server via DHCPv6 bekannt gegeben.
|
| ( ) DNS-Server und IPv6-Präfix (IA_PD) zuweisen
|
| FRITZ!Box wird als DNS-Server via DHCPv6 bekannt gegeben.
| Teile des vom Internetanbieter zugewiesenen IPv6-Netzes
| werden an nachgelagerte Router weitergeben.
^^^^^^^^^^^^^^^^^^^^
habe ich hier nicht, nur nachgelagerte PC
|
| ( ) DNS-Server, Präfix (IA_PD) und IPv6-Adresse (IA_NA) zuweisen
[...]

Ich meine, daß aber trotzdem bei mir die 'Netz-IDs' "00"
und "01" angezeigt werden müßten. (Ach so, das Gastnetz
ist bei mir derzeit nicht aktiv, weder für LAN noch für
WLAN.)

Marcel
--
╭─────╮ ╭────╮ ╭──╮ ╭────────╮ ╭───╮ ╭─╮ ╭─╮ ╭─╮ │
───╮ ╰─╮ ╰──╯ ╰─╯ │ ╰────╮ ╰─╮ ╰─╮ ╰─╯ │ │ ╰─╯ ╰─╮ ╭──╯
╭─╯ ╭─╯ ╭────────╯ ╭───╯ ╭──╯ ╭──╯ ╭──╯ ╰───╮ ╰─╯
╰─────╯ ╰────────────╯ ╰────────╯ ╰─────────╯

[Diedrich Ehlerding]

Marcel Logen meinte:

> |werden an nachgelagerte Router weitergeben.
> ^^^^^^^^^^^^^^^^^^^^
> habe ich hier nicht, nur nachgelagerte PC

Eben. Du hast also keinen Bedarf für prefix delegation.

Ich habe auch habe halt auch keinen
nachgelagertenRouter)nachgelagerten Router, habe aber

| [x] DNS-Server, Präfix (IA_PD) und IPv6-Adresse (IA_NA) zuweisen

angekreuzt (warum auch immer - vermutlich weil ich sehen wollte, was
dann passiert; aber ich sehe nichts (ich ggf. hätte ich an meinem PC
IPV6 wieder ausgeschaltet, wenns Probleme gemacht hätte).

Hmmm ... könnte da eine Ursache liegen, warum bei mir beim Booten die
Netzwerkkarte erst nach ca 12 sek fertig ist?

[Hermann Riemann]

https://wiki.archlinux.de/title/Systemd-boot

Hermann
der in c't Linux Seite 132
Linux booten ohne grub
gelesen hat.

--
http://www.hermann-riemann.de

[Marc Haber]

Kay Martinen <use...@martinen.de> wrote:
>Am 25.03.21 um 13:43 schrieb Marc Haber:
>> Tim Ritberg <t...@server.invalid> wrote:
>>> Systemd hat Linux Stabilität genommen, eindeutig.
>>
>> Das sehe ich anders. Du hast noch nicht genug Lebenszeit mit
>> Initscripten verschwendet.
>
>Was mich angeht: Stimmt! Schreibend 0,0x-irgendwas (skeleton-copy/edit
>:)

Die wirkliche Arbeit beginnt danach.

> Lesend: Etliche male bei Fehlersuchen.

Siehste.

>Aber ich Programmiere nicht, ich benutze nur Linux. Und das ungefähr
>seit 1991 (davor anderes).

Ich habe erst 1998 mit Linux angefangen, und besonders viel
programmiere ich auch nicht.

>> Aber wir werden hier nicht über ein "agree
>> to disagree" hinweg kommen. Hast Du die Größe dazu?
>
>Wenn du damit meinst das wir darin übereinstimmen das wir anderer
>Meinung sind, dann ja. Zustimmung!

Ja, obwohl ich Dich damit ja gar nicht gemeint habe, sondern Tim.

>EoT, wenn du magst.

Von mir aus.

Grüße
Marc

[Marc Haber]

Marcus Jodorf <tr...@killfile.de> wrote:
>Ich weiß nicht, ob man da groß philosophieren muß -- aber was mir
>aufgefallen ist, ist daß ungefähr parallel zum Aufkommen von systemd
>es begonnen hat, daß plötzlich Windowsserver stabiler laufen als so
>manches Linux (reboots wegen Updates außen vor).

Das ist IMO hauptsächlich Windows' Verdienst, das muss man Microsoft
einfach zugestehen. Ich kann bei meinen Linuxen keine Neigung zur
Instabilität entdecken.

>Das mag daran liegen, daß MS dafür ja auch ein paar Jahrzehnte Anlauf
>gebraucht und es vielleicht dann endlich mal geschafft hat...

So sehe ich das, ja.

>Aber letztlich finde ich das schon etwas traurig. Jedenfalls war systemd
>zumindest keinerlei Zugewinn an Stabilität und ich hab auch einfach mehr
>weggeknallte Systeme in den letzten Jahren erlebt als im Jahrzehnt
>davor.

Ich sehe systemd langfristig als einen Gewinn und eine Zeitersparnis,
hauptsächlich weil systemd-units einfacher zu debuggen sind als
Initscripts und mit systemd etliche hanebüchene Heuristiken oder
archaische Mechanismen wie pidfiles nicht mehr notwendig sind. Und es
ist massivst einfacher geworden, Features wie Capabilities und
Namespaces zu benutzen (das hat vor systemd nicht ohne Grund kaum
jemand gemacht).

>Das mag empirisch keine Bedeutung haben, aber mir persönlich fällt es
>schon auf. Ich hab mich tatsächlich schon mal dabei erwischt, zu
>überlegen, ob es nicht sinnvoller wäre, eine kritische Sache auf einen
>aktuellen Windows- statt einen Linuxserver zu packen.

Das ist inzwischen im Wesentlichen eine Stilfrage. Unter Windows kann
man halt immer noch erheblich schlechter debuggen als in einem
systemd-Linux.

Grüße
Marc

[Christian Garbs]

Mahlzeit!

Sebastian Suchanek <sebastian...@gmx.de> wrote:

> Am 26.03.2021 um 09:46 schrieb Christian Garbs:

>> ich verteile die dynamischen IPv6-Präfixe von der FritzBox intern
>> weiter

> Kannst Du das 'mal näher beschreiben?
> Wenn Du das meinst, von dem ich denke, das Du es meinst ;-) wäre das für
> mich auch interessant.

Hat etwas gedauert und ist etwas länger geworden. Ich warte mal
Kommentare und Korrekturen ab und kippe es dann auch in mein Blog,
daher die etwas Usenet-untypische Formatierung.

Gruß
Christian


- - - - - - >8 - - - - - -


Table of Contents
_________________

1 IPv6 Prefix-Delegation
.. 1.1 Umfeld
.. 1.2 Adressen
.. 1.3 Konfiguration der Fritz!Box
.. 1.4 Konfiguration des Linux-Servers als Router
..... 1.4.1 Netzwerk-Devices
..... 1.4.2 Netzwerk-Adressen
..... 1.4.3 Netzwerk-Konfiguration
..... 1.4.4 radvd
..... 1.4.5 DNS
..... 1.4.6 Firewall auf dem Server
.. 1.5 Ende


1 IPv6 Prefix-Delegation
========================

Ziel: Im Hausnetz dynamisch zugeordnete IPv6-Adressen aus dem
Dialup-Internetzugang bereitstellen. Die Fritz!Box bekommt bei der
Einwahl ein /56 und reicht daraus ein /64 über den internen
Router/Server an das dahinterliegende Hausnetz weiter. Alle paar
Stunden wird das ausgewählte /64 gewechselt, ebenso bei einem
Reconnect (denn dann gibt es ein neues /56).


1.1 Umfeld
~~~~~~~~~~

- Ich mache das sowohl mit einer FritzBox 7490 als auch einer
FRITZ!Box WLAN 3370, jeweils aktuelle Firmware.
- Internet ist jeweils Magenta 50 von der Telekom.
- Der Linux-Server/Router läuft jeweils unter Debian 10 (Buster).
- Das Netzwerk-Setup ist beide Male so:

,----
| __________
| ( Internet )
| """"""""""
| |
| [FritzBox]
| |
| | DMZ
| |
| [Linux-Server]
| |
| | Hausnetz
| |
| |- Client 1
| |- Client 2
| …
`----

Je nach Netz ist die DMZ mal komplett leer (Ethernetkabel vom Server
direkt zur Fritz!Box) oder sie umfasst das Haus-WLAN und dort tummeln
sich Drucker, Fernseher, Laptops, Smartphones etc. – alles, was nicht
an das „wichtige“ interne Hausnetz ran muss.

(DISCLAIMER: der Rechnerzoo schrumpft zusammen und teilweise ist das
Hausnetz inzwischen leer – ich bin mir aber 100% sicher, dass die
Prefix-Delegation dort früher, als es noch mehr Geräte gab, korrekt
funktioniert hat.)


1.2 Adressen
~~~~~~~~~~~~

Als lokalen IPv6-Adressraum nehme ich `fdXX/64', der Server kriegt
dort jeweils Adresse `1'. Das ist leicht zu merken und
dementsprechend ist seine IPv6-Adresse kürzer als unter IPv4:
`fdXX:1/64' vs. `192.168.XX.1/24' :)

`XX' ist für IPv4 und IPv6 gleich, so muss ich mir nur merken „ah, das
13er Netz“ und der Rest ergibt soch von alleine.


1.3 Konfiguration der Fritz!Box
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Ich weiß nicht, ob alles davon relevant ist. Das wichtigste dürfte
die Einstellung /DNS-Server und IPv6-Präfix (IA_PD) zuweisen/ sein.
Ich benutze in der Weboberfläche die _Erweiterte Ansicht_.

- Internet
- Zugangsdaten
- IPv6
- IPv6-Unterstützung
- Unterstützung für IPv6 aktiv
- IPv6-Anbindung
- (x) Immer eine native IPv5-Anbindung nutzen (empfohlen)
- Heimnetz
- Heimnetzübersicht / Netzwerk (je nach FritzOS-Version)
- Netzwerkeinstellungen
- IP-Adressen
- IPv6-Adressen / IPv6-Konfiguration
- Unique Local Adresses
- (x) Unique Local Addresses (ULA) zuweisen, solange keine
IPv6-Internetverbindung besteht (empfohlen)
- Weitere IPv6-Router im Heimnetz
- Diese Fritz!Box stellt die Standard Internetverbindung
zur Verfügung
- DHCPv6-Server im Heimnetz
- (x) DHCPv6-Server in der FRITZ!Box für das Heimnetz
aktivieren
- (x) DNS-Server und IPv6-Präfix (IA_PD) zuweisen


1.4 Konfiguration des Linux-Servers als Router
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1.4.1 Netzwerk-Devices
----------------------

Ich habe gerne sprechende Namen, bin mit `eth0', `tr0' usw. groß
geworden und möchte auf allen Servern direkt die logische Funktion
eines Devices erkennen. Daher benenne ich die Devices manuell um:

- `dmz0' geht nach außen Richtung Fritz!Box
- `eth0' geht nach innen ins Hausnetz

Folgendes habe ich dafür in der
`/etc/udev/rules.d/70-persistent-net.rules' stehen (MACs changed to
protect the innocent):

,----
| SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="80:ee:73:a1:a1:a1", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="eth0"
| SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="80:ee:73:a3:a3:a3", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="dmz0"
`----


1.4.2 Netzwerk-Adressen
-----------------------

Für die weitere Konfiguration benutze ich klassisch `ifupdown'.
Obacht, da steht wieder `XX':

- `etc/network/interfaces.d/eth0' ist sehr minimal:

,----
| allow-hotplug eth0
|
| iface eth0 inet static
| address 192.168.XX.1/24
|
| iface eth0 inet6 static
| address fdXX::1/64
`----

- `/etc/network/interfaces.d/dmz0' wird schon interessanter:

,----
| allow-hotplug dmz0
|
| iface dmz0 inet static
| address 192.168.YY.2/24
| gateway 192.168.YY.1
|
| iface dmz0 inet6 auto
| dhcp 1
| request_prefix 1
| accept_ra 2
| pre-down /sbin/start-stop-daemon -s USR1 --stop --pidfile /run/dhclient6.dmz0.pid --exec /sbin/dhclient
| pre-down rm /run/dhclient6.dmz0.pid
|
`----

- `YY' ist das kürzel für den IPv4-DMZ-Adressraum Das ginge auch
einfacher über DHCP, aber wenn sich in der DMZ noch andere Geräte
tummeln und ich den Server ansprechen will, habe ich gerne eine
feste Adresse. (Gut, die Fritz!Box kann auch feste Adressen per
DHCP vergeben. Ich ziehe die „historisch gewachsen“-Karte.) Für
IPv6 kommen wir in der DMZ auf jeden Fall ohne feste Adresse aus,
daher steht da nichts.

- `dhcp 1', `request_prefix 1' und `accept_ra 2' sind die magischen
Schlüsselwörter, die ich irgendwann mal ausgependelt habe, siehe
_interfaces(5)_.

- Der `dhclient6' stoppt(e) nicht ganz sauber, wenn das Interface
runterfährt. Um es wieder hochfahren zu können, muss man as
PID-File manuell entfernen.


1.4.3 Netzwerk-Konfiguration
----------------------------

In der `/etc/sysctl.conf' habe ich unter anderem folgendes stehen.
Sieht wichtig aus:

,----
| # EXPERIMENTAL
| # ipv6 privacy extension ONLY on external device
| # https://wiki.ubuntuusers.de/IPv6/Privacy_Extensions/
| net.ipv6.conf.dmz0.use_tempaddr = 2
| net.ipv6.conf.dmz0.temp_prefered_lft = 14400
|
| # Uncomment the next line to enable packet forwarding for IPv6
| # Enabling this option disables Stateless Address Autoconfiguration
| # based on Router Advertisements for this host
| net.ipv6.conf.all.forwarding=1
|
| ### enable SLAAC autoconfiguration for IPv6 even when we are forwarding:
| net.ipv6.conf.all.accept_ra=2
`----


1.4.4 radvd
-----------

Mit der bisherigen Konfiguration sollte der Server die von der
Fritz!Box delegierten Präfixe bereits sehen und benutzen. Allerdings
leitet er sie nicht an die Clients im Hausnetz weiter. Dafür nehmen
wir `radvd'. Hier ist der entscheidende Knackpunkt, dass die
dynamische Konfiguration des delegierten Prefixes nur mit /64
funktioniert. Wenn uns der Internetprovider nur ein /64 gibt, können
wir das nicht einfach kleinschneiden und weiterverteilen. Größer als
/64 geht wohl auch nicht. (Ist länger her, dass ich das
zusammengebaut habe, ich kann jetzt nur nach Aktenlage – also den
Kommentaren im Configfile – berichten.)

Hier die `/etc/radvd.conf':

,----
| interface eth0
| {
| AdvSendAdvert on;
|
| # special prefix for prefix delegation ("grab current IP address from that interface")
| prefix ::/64
| {
| DeprecatePrefix on;
| DecrementLifetimes on;
| };
| RDNSS fdXX::1 {
| };
| DNSSL interne.dns.domsain.foo {
| };
| };
`----

Wie üblich ist da ein `XX' für den Server und hier kann sogar das
interne DNS (Server + Domain) gesetzt werden.


1.4.5 DNS
---------

Nur ganz kurz:

- Als Resolver nehme ich `unbound'. Der hat zwei
`interface:'-Statements in der Config, so dass er im Hausnetz einmal
auf IPv4 (`192.168.XX.1') und einmal auf IPv6 (`fdXX:1') lauscht.

- Der eigentliche DNS-Server ist `nsd'. Da ich noch nicht
rausgefunden habe, wie ich im `unbound' eine `stub-zone'
gleichzeitig auf IPv4 und IPv6 binden kann, wird der DNS-Server
tatsächlich /nur/ über IPv4 angesprochen (er liefert aber natürlich
sowohl A- als auch auch AAAA-Records aus). Falls da noch jemand
Ideen hat: nur zu!


1.4.6 Firewall auf dem Server
-----------------------------

Ist ein eigenes Kapitel :-) Gleichlautende Regeln für IPv4/IPv6 lassen
sich ganz wunderbar über `nftables' erledigen, die Config ist viel
einfacher und übersichtlicher als mit `iptables'. Für IPv6 muss man
diverse ICMP-Pakete durchlassen, ansonsten habe ich da nur eine Liste
von Ports, die aus der DMZ heraus erreichbar sein sollen (sowohl über
IPv4 als auch IPv6) wie z.B. für den MediaServer (`minidlna') oder
SSH.


1.5 Ende
~~~~~~~~

Wenn ich nichts vergessen habe, ist das alles.



--
....Christian.Garbs....................................https://www.cgarbs.de
Proofread carefully to see if you any words out.

[Ulli Horlacher]

Marc Haber <mh+usene...@zugschl.us> wrote:

> Ich sehe systemd langfristig als einen Gewinn und eine Zeitersparnis,

Meine Systeme brauchen mit systemd bis zu 10 mal so lange zum booten und
der shutdown bzw reboot geht manchmal gar nicht mehr, weil systemd sich da
aufhaengt. TOLLER Fortschritt ist das.


--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

[Andreas Kohlbach]

On Fri, 2 Apr 2021 23:30:28 +0000 (UTC), Ulli Horlacher wrote:
>
> Marc Haber <mh+usene...@zugschl.us> wrote:
>
>> Ich sehe systemd langfristig als einen Gewinn und eine Zeitersparnis,
>
> Meine Systeme brauchen mit systemd bis zu 10 mal so lange zum booten und
> der shutdown bzw reboot geht manchmal gar nicht mehr, weil systemd sich da
> aufhaengt. TOLLER Fortschritt ist das.

Damit dürftest Du zu einer Ausnahme gehören.

Vielleicht war es nur ein kaputter Kernel. Ich hatte vor mehr als einem
Jahr nach dem Booten eines neu installierten Kernels das Problem, dass
einige Dinge sich nicht starten wollten. In den (systemd-) Meldungen
konnte ich beobachten, dass die Zeit, bis ein Prozess beendet werden
soll, als unendlich eingeschätzt wurde. Ein Reboot half nichts. Google
wusste aber von einem Kernel-Bug. Ich habe dann einen älteren Kernel
gebootet, und er bootete wieder.

Das wäre vermutlich ohne systemd auch passiert.
--
Andreas

[Hermann Riemann]

Am 03.04.21 um 03:57 schrieb Andreas Kohlbach:

Wenn ich beim booten auf Protokoll anzeigen umstelle,
sehe ich dass viele Programme doppelt aufgerufen werden.

Hermann
der momentan kein Bedarf hat, nach Ursachen zu suchen.

--
http://www.hermann-riemann.de

[Christian Garbs]

Mahlzeit!

Marc Haber <mh+usene...@zugschl.us> wrote:

> Christian Garbs <mi...@cgarbs.de> wrote:

>> Mit systemd-networking wäre das vielleicht nicht passiert, aber ich
>> verteile die dynamischen IPv6-Präfixe von der FritzBox intern
>> weiter, das geht glaube ich mit systemd-networking nicht.

> Neuerer systemd-networkd kann Prefix Delegation. Mich würde
> intressieren, wie Du das "klassisch" machst,

Siehe "weiter oben" <s47qek$j401$1...@yggdrasil.dn.cgarbs.de> :-)
Letztendlich ist wohl radvd das nötige Extra-Zahnrad.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Q: Why do firemen wear red suspenders?
A: To conform with departmental regulations concerning uniform dress.

[Andreas Kohlbach]

On Sat, 3 Apr 2021 05:39:14 +0200, Hermann Riemann wrote:
>
> Am 03.04.21 um 03:57 schrieb Andreas Kohlbach:
>> On Fri, 2 Apr 2021 23:30:28 +0000 (UTC), Ulli Horlacher wrote:
>>>
>>>
>>> Meine Systeme brauchen mit systemd bis zu 10 mal so lange zum booten und
>>> der shutdown bzw reboot geht manchmal gar nicht mehr, weil systemd sich da
>>> aufhaengt. TOLLER Fortschritt ist das.
>> Damit dürftest Du zu einer Ausnahme gehören.
>> Vielleicht war es nur ein kaputter Kernel. Ich hatte vor mehr als
>> einem
>> Jahr nach dem Booten eines neu installierten Kernels das Problem, dass
>> einige Dinge sich nicht starten wollten. In den (systemd-) Meldungen
>> konnte ich beobachten, dass die Zeit, bis ein Prozess beendet werden
>> soll, als unendlich eingeschätzt wurde. Ein Reboot half nichts. Google
>> wusste aber von einem Kernel-Bug. Ich habe dann einen älteren Kernel
>> gebootet, und er bootete wieder.
>> Das wäre vermutlich ohne systemd auch passiert.
>>
> Wenn ich beim booten auf Protokoll anzeigen umstelle,

Wie machst Du das? "ps"?

> sehe ich dass viele Programme doppelt aufgerufen werden.

Vielleicht sind das Threads *eines* Programms?

Chromium hat hier gerade mit mehreren offenen TABS fünf. Das sind auch
mal mehr oder weniger.
--
Andreas

[Ulli Horlacher]

Andreas Kohlbach <a...@spamfence.net> wrote:

> > Meine Systeme brauchen mit systemd bis zu 10 mal so lange zum booten und
> > der shutdown bzw reboot geht manchmal gar nicht mehr, weil systemd sich da
> > aufhaengt. TOLLER Fortschritt ist das.
>
> Damit dürftest Du zu einer Ausnahme gehören.

Alle Admins in meinem Umfeld berichten aehnliches.

> Vielleicht war es nur ein kaputter Kernel.

Kernel 3.x bis 5.x alle kaputt?
Ich halte da die Wahrscheinlichkeit dass systemd kaputt ist also fuer viel
hoeher ein.

[Kay Martinen]

Am 03.04.21 um 05:39 schrieb Hermann Riemann:

> Am 03.04.21 um 03:57 schrieb Andreas Kohlbach:

>>

>> Das wäre vermutlich ohne systemd auch passiert.
>>
> Wenn ich beim booten auf Protokoll anzeigen umstelle,
> sehe ich dass viele Programme doppelt aufgerufen werden.

Meinst du vielleicht Bootmeldungen wie

...Starting Start-Network...
...Stopping Start-Network...

oder sinngemäß gleiches?

Das werden dann nur die Units/scripte sein die ihren Anfang und Ende
mitteilen. = Normal, Nicht interessant - außer für debugging.

Heißt: Zwei Meldungen für EINEN Vorgang.

> Hermann
>    der momentan kein Bedarf hat, nach Ursachen zu suchen.

Wenn es eine Ursache gibt! Kausalität ist manchmal eine Fiese Sache...

[Arno Welzel]

Ulli Horlacher:

> Marc Haber <mh+usene...@zugschl.us> wrote:
>
>> Ich sehe systemd langfristig als einen Gewinn und eine Zeitersparnis,
>
> Meine Systeme brauchen mit systemd bis zu 10 mal so lange zum booten und
> der shutdown bzw reboot geht manchmal gar nicht mehr, weil systemd sich da
> aufhaengt. TOLLER Fortschritt ist das.

Passiert hier nicht - mit keinem System. Weder dauert es länger als mit
SysV init noch hängt ein System bei shutdown/reboot.


--
Arno Welzel
https://arnowelzel.de

[Ulli Horlacher]

Ich hab auch nicht behauptet, dass es IMMER so ist.
Wenn aber 1/4 von mehreren hundert Systemen massive boot/shutdown Probleme
haben, dann laeuft was GEWALTIG falsch.
Vor systemd gabs diese Probleme nicht.

[Marc Haber]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>
>> Ich sehe systemd langfristig als einen Gewinn und eine Zeitersparnis,
>
>Meine Systeme brauchen mit systemd bis zu 10 mal so lange zum booten und
>der shutdown bzw reboot geht manchmal gar nicht mehr, weil systemd sich da
>aufhaengt. TOLLER Fortschritt ist das.

Da ist irgendwas an Euren Systemen kaputt. Ich habe tausende von
systemd-Installationen gesehen und mir ist das Verhalten völlig
unbekannt.

[Marc Haber]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>Andreas Kohlbach <a...@spamfence.net> wrote:
>
>> > Meine Systeme brauchen mit systemd bis zu 10 mal so lange zum booten und
>> > der shutdown bzw reboot geht manchmal gar nicht mehr, weil systemd sich da
>> > aufhaengt. TOLLER Fortschritt ist das.
>>
>> Damit dürftest Du zu einer Ausnahme gehören.
>
>Alle Admins in meinem Umfeld berichten aehnliches.

Bin ich nicht in Deinem Umfeld?

[Ulli Horlacher]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> >Marc Haber <mh+usene...@zugschl.us> wrote:
> >
> >> Ich sehe systemd langfristig als einen Gewinn und eine Zeitersparnis,
> >
> >Meine Systeme brauchen mit systemd bis zu 10 mal so lange zum booten und
> >der shutdown bzw reboot geht manchmal gar nicht mehr, weil systemd sich da
> >aufhaengt. TOLLER Fortschritt ist das.
>
> Da ist irgendwas an Euren Systemen kaputt.

Dann sind Ubuntu, RHEL und SLES kaputt.

[Thomas Hochstein]

Marc Haber schrieb:

> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> >Alle Admins in meinem Umfeld berichten aehnliches.
>
> Bin ich nicht in Deinem Umfeld?

Oder Du bist kein Admin. *eg*

[Thomas Dorner]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:
> Marc Haber <mh+usene...@zugschl.us> wrote:
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>> >Marc Haber <mh+usene...@zugschl.us> wrote:
>> >
>> >> Ich sehe systemd langfristig als einen Gewinn und eine Zeitersparnis,
>> >
>> >Meine Systeme brauchen mit systemd bis zu 10 mal so lange zum booten und
>> >der shutdown bzw reboot geht manchmal gar nicht mehr, weil systemd sich da
>> >aufhaengt. TOLLER Fortschritt ist das.
>>
>> Da ist irgendwas an Euren Systemen kaputt.
>
> Dann sind Ubuntu, RHEL und SLES kaputt.

Mein Ubuntu hatte ein paarmal beim Booten oder Runterfahren gezickt, als
ich einen Service falsch konfiguriert habe. Und ganz am Anfang gab es
auch ein paar Services, die auf Seiten Ubuntu noch Fehler in der
Konfiguration hatten. Daran ist aber nicht SystemD Schuld. Seitdem die
Fehler korrigiert sind, hatte ich keine Probleme mehr.

Viele Grüße, Thomas
--
Adresse gilt nur kurzzeitig!

[Kay Martinen]

Am 03.04.21 um 17:04 schrieb Thomas Hochstein:

Marc ist der der dem Admin rät "Nimm doch lieber XYZ". :-)

SCNR

Womit ich jetzt mal definitiv NICHT ein bestimmtes init-System meine!

[Kay Martinen]

Am 03.04.21 um 14:30 schrieb Arno Welzel:

Ich hab es nach updates von Proxmox schon erlebt das der beim shutdown
einen stop-job meldet der mit mehreren Minuten wartezeit das
runterfahren sehr verzögert. Das war vor allem bei PromoxVE 5.4.x auf
einem HP Pavilon mit quadcore der fall. Welcher Job das war weiß ich
nicht mehr. Und ein mal ist das auch auf meinem Proliant Server
passiert, da waren aber noch andere umstände beteiligt so das es nicht
unbedingt vergleichbar ist.

[Marcel Logen]

Kay Martinen in de.comp.os.unix.linux.misc:

>Ich hab es nach updates von Proxmox schon erlebt das der beim shutdown
>einen stop-job meldet der mit mehreren Minuten wartezeit das
>runterfahren sehr verzögert. Das war vor allem bei PromoxVE 5.4.x auf
>einem HP Pavilon mit quadcore der fall. Welcher Job das war weiß ich
>nicht mehr.

Einen stop job, der das Herunterfahren um 1 min 30 sec ver-
zögert, habe ich ca. jedes fünfte Mal auf einem FUJITSU-Notebook
von 2015 mit Debian 10 "buster".

Ich hatte mal versucht, per journalctl der Sache auf den Grund
zu gehen, aber das war vergeblich. Inzwischen habe ich mich
fast daran gewöhnt. ;-)

Marcel
--
╭──╮ ╭─────╮ ╭───────╮ ╭───╮ ╭─╮ ╭──╮ ╭───╮ ╭
│ │ ╰──╮ ╰─╮ ╰─╮ ╭──╯ │ ╰─╯ │ ╭──╮ │ ╰───────╯ ╰──╮ │
│ ╰──╮ ╰──╮ ╰─╮ │ ╰─╮ │ │ ╭─╯ │ ╰─╮ ╰─╯
╯ ╰─────╯ ╰────╯ ╰───╯ ╰────╯ ╰────╯

[Paul Muster]

On 03.04.21 15:42, Ulli Horlacher wrote:
> Marc Haber <mh+usene...@zugschl.us> wrote:
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>>> Marc Haber <mh+usene...@zugschl.us> wrote:

>>>> Ich sehe systemd langfristig als einen Gewinn und eine Zeitersparnis,
>>>
>>> Meine Systeme brauchen mit systemd bis zu 10 mal so lange zum booten und
>>> der shutdown bzw reboot geht manchmal gar nicht mehr, weil systemd sich da
>>> aufhaengt. TOLLER Fortschritt ist das.
>>
>> Da ist irgendwas an Euren Systemen kaputt.
>
> Dann sind Ubuntu, RHEL und SLES kaputt.

Na klar. Am Administrator (dir) und dessen Verweigerungshaltung
jeglicher Modernisierung gegenüber kann es nicht liegen.

Alter Mann, mit deinen Aussagen diskreditierst du alle seriösen
systemd-Kritiker. Und das ist echt übel.


mfG Paul

[Christian Garbs]

Mahlzeit!

Thomas Noll <-_tn...@web.de> wrote:

> Am Fri, 02 Apr 2021 21:14:28 +0200 schrieb Christian Garbs:

>> Hat etwas gedauert und ist etwas länger geworden. Ich warte mal
>> Kommentare und Korrekturen ab und kippe es dann auch in mein Blog,
>> daher die etwas Usenet-untypische Formatierung.
>

> Kannst du da mal den output von ip -6 a l von deinem Server und einem Client
> im Hausnetz zeigen? Ich finde die radvd Konfiguration etwas merkwürdig,
> kann aber mangels praktischer Erfahrung damit nicht sagen, ob das an der
> Konfiguration oder an mir liegt.

Du hast Recht, das läuft nicht (mehr). Entweder ich habe mich geirrt
und das lief die ganze Zeit nur bis zum Server oder irgendwas ist
kaputtgegangen.

Der soeben entstaubte Client (der macht erstmal einen Ubuntu-
Releasewechsel…) kriegt keine IPv6-Adresse aus dem von der Fritz!Box
delegierten Pool.

radvd meckert im Journal über folgendes:

| radvd[88566]: invalid all-zeros prefix in /etc/radvd.conf, line 6

Hat sich das im Laufe der Zeit mal geändert? Auf die Schnelle habe
ich nichts passendes googeln können, aber einen Treffer für genau das
gefunden, was ich da gemacht habe:

https://wiki.debian.org/IPv6PrefixDelegation#Assigning_the_prefix_to_another_interface

| radvd (on the inside interface, to enable SLAAC and automatic router
| setup on the clients) can be set up such that it works regardless of
| the assigned prefix, by using “prefix ::/64”.

Das stimmt dann wohl nicht (mehr).

Aber in der Manpage wird der Prefix ::/64 auch erwähnt:

https://manpages.debian.org/buster/radvd/radvd.conf.5.en.html

Die Crux scheint dieser Satz zu sein:

| When configured, radvd picks all non-link-local prefix assigned to
| the interface and starts advertising it.

Das würde bedeuten, dass radvd nicht die Prefixe von dmz0 auf eth0
announced, sondern die von eth0 auf eth0. Auf eth0 sind aber noch
keine Prefixe, weil der dhcpv6-Client sie ja auf dmz0 empfangen hat.

Hrmpf. Im Wiki steht direkt darüber eine "große" Lösung mit einem
Haufen Skripting, da habe ich keine Lust drauf ;-) Dadrunter steht
eine Config für wide-dhcpv6, die klingt schon eher interessant. Der
würde wohl Prefixe von dmz0 auf eth0 rüberschaufeln können und dann
kommt radvd zum Zug (wenn er dann nicht wieder über den Spezial-Prefix
meckert). Da muss ich beizeiten mal mit rumspielen.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Do not believe in miracles -- rely on them.

[Hermann Riemann]

Am 03.04.21 um 12:22 schrieb Andreas Kohlbach:

> On Sat, 3 Apr 2021 05:39:14 +0200, Hermann Riemann wrote:
>>
>> Am 03.04.21 um 03:57 schrieb Andreas Kohlbach:
>>> On Fri, 2 Apr 2021 23:30:28 +0000 (UTC), Ulli Horlacher wrote:
>>>>
>>>>
>>>> Meine Systeme brauchen mit systemd bis zu 10 mal so lange zum booten und
>>>> der shutdown bzw reboot geht manchmal gar nicht mehr, weil systemd sich da
>>>> aufhaengt. TOLLER Fortschritt ist das.
>>> Damit dürftest Du zu einer Ausnahme gehören.
>>> Vielleicht war es nur ein kaputter Kernel. Ich hatte vor mehr als
>>> einem
>>> Jahr nach dem Booten eines neu installierten Kernels das Problem, dass
>>> einige Dinge sich nicht starten wollten. In den (systemd-) Meldungen
>>> konnte ich beobachten, dass die Zeit, bis ein Prozess beendet werden
>>> soll, als unendlich eingeschätzt wurde. Ein Reboot half nichts. Google
>>> wusste aber von einem Kernel-Bug. Ich habe dann einen älteren Kernel
>>> gebootet, und er bootete wieder.
>>> Das wäre vermutlich ohne systemd auch passiert.
>>>
>> Wenn ich beim booten auf Protokoll anzeigen umstelle,
>
> Wie machst Du das? "ps"?

Wenn bei SuSE zwischen nach ? Sekunden und vor der Anmeldung
das Rechteck angezeigt wir,
drücke ist Esc um die Boot Befehle zu sehen.

>> sehe ich dass viele Programme doppelt aufgerufen werden.

> Vielleicht sind das Threads *eines* Programms?

Selbe Befehle erscheinen doppelt.
. Start Security Audit nochwas.

Passiert auch beim Herunterfahren

> Chromium hat hier gerade mit mehreren offenen TABS fünf. Das sind auch
> mal mehr oder weniger.

Browser kommen nach der Anmeldung mit passworteingabe.

Hermann
fragend wer der andere root user ist

--
http://www.hermann-riemann.de

[Hermann Riemann]

Am 03.04.21 um 13:34 schrieb Kay Martinen:

> Am 03.04.21 um 05:39 schrieb Hermann Riemann:
>> Am 03.04.21 um 03:57 schrieb Andreas Kohlbach:
>
>>>
>>> Das wäre vermutlich ohne systemd auch passiert.
>>>
>> Wenn ich beim booten auf Protokoll anzeigen umstelle,
>> sehe ich dass viele Programme doppelt aufgerufen werden.
>
> Meinst du vielleicht Bootmeldungen wie
>
> ...Starting Start-Network...
> ...Stopping Start-Network...

Es ist sind gleiche Buchstaben in jeweils 2 Zeilen.

Die Verdoppelung geht irgendwann los.

In /var/log/boot.log
habe ich keine Verdoppelung gesehen.

Daher halte ich es für wahrscheinlich,
dass gleiche Meldungen einfach nur doppelt ausgegeben werden.

Hermann
mit einer Restunsicherheit.

--
http://www.hermann-riemann.de

[Kay Martinen]

Am 03.04.21 um 15:42 schrieb Ulli Horlacher:

> Marc Haber <mh+usene...@zugschl.us> wrote:
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>>> Marc Haber <mh+usene...@zugschl.us> wrote:
>>>
>>>> Ich sehe systemd langfristig als einen Gewinn und eine Zeitersparnis,
>>>
>>> Meine Systeme brauchen mit systemd bis zu 10 mal so lange zum booten und
>>> der shutdown bzw reboot geht manchmal gar nicht mehr, weil systemd sich da
>>> aufhaengt. TOLLER Fortschritt ist das.
>>
>> Da ist irgendwas an Euren Systemen kaputt.
>
> Dann sind Ubuntu, RHEL und SLES kaputt.
>

Please send bugreports... :)

[Paul Muster]

On 04.04.21 00:07, Marcus Jodorf wrote:

> Ich hoffe, jemand repariert den Mist, bevor es in Debian 11 landet -
> ansonsten dürften da einige Leute nach dem Upgrade eine kleine
> Überraschung erleben.

Bitte mach' doch einen entsprechenden, release-critical Bug auf, um die
anderen Debian-Nutzer vor diesem Verhalten zu schützen.


mfG Paul

[Marc Haber]

*pffrt*

[Marc Haber]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>Wenn aber 1/4 von mehreren hundert Systemen massive boot/shutdown Probleme
>haben, dann laeuft was GEWALTIG falsch.

Richtig, und zwar lokal.

>Vor systemd gabs diese Probleme nicht.

Innovation erfordert Anpassung.

[Marc Haber]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>> >Marc Haber <mh+usene...@zugschl.us> wrote:
>> >
>> >> Ich sehe systemd langfristig als einen Gewinn und eine Zeitersparnis,
>> >
>> >Meine Systeme brauchen mit systemd bis zu 10 mal so lange zum booten und
>> >der shutdown bzw reboot geht manchmal gar nicht mehr, weil systemd sich da
>> >aufhaengt. TOLLER Fortschritt ist das.
>>
>> Da ist irgendwas an Euren Systemen kaputt.
>
>Dann sind Ubuntu, RHEL und SLES kaputt.

Für RHEL und SLES dürftet Ihr Support gekauft haben, was sagt denn der
Support dazu?

Grüße
Marc

[Kay Martinen]

Am 04.04.21 um 13:07 schrieb Marc Haber:

> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>> Marc Haber <mh+usene...@zugschl.us> wrote:
>>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>>>> Marc Haber <mh+usene...@zugschl.us> wrote:
>>>>
>>>>> Ich sehe systemd langfristig als einen Gewinn und eine Zeitersparnis,
>>>>
>>>> Meine Systeme brauchen mit systemd bis zu 10 mal so lange zum booten und
>>>> der shutdown bzw reboot geht manchmal gar nicht mehr, weil systemd sich da
>>>> aufhaengt. TOLLER Fortschritt ist das.
>>>
>>> Da ist irgendwas an Euren Systemen kaputt.
>>
>> Dann sind Ubuntu, RHEL und SLES kaputt.
>
> Für RHEL und SLES dürftet Ihr Support gekauft haben, was sagt denn der
> Support dazu?

Da Ulli damit hier wiederholt postet vermute ich

- SLA Limit überschritten. NiH.
- Ticket closed. NotaBug It's a Feature. (O-Microsoft-J) :)
- System too Old = Out of Service go to d.a.f.c.

Irgend was davon wird's vermutlich sein.

Und dazu kommt ja [Service-devil from Hell spielend] verzögerungen beim
reboot werden bestimmt nicht als systemkritisch angesehen. So lange der
reboot selbst nicht das problem ist, man den also bewust auslöste.

Ich meine, ein Server sollte nur durch einen NMI (ggf. vom BMC
gesteuert) automatisch gestoppt oder neu gestartet werden. Ansonsten nur
durch den Admin. Oder einem Tool das der Admin bewusst dafür
einrichtete. (cronjob @reboot: reboot) ??? :-)

[Ulli Horlacher]

Marc Haber <mh+usene...@zugschl.us> wrote:

> >Vor systemd gabs diese Probleme nicht.
>
> Innovation erfordert Anpassung.

Innovation bedeutet Fortschritt. Und nicht "VIEL mehr (unnoetige) Probleme"

[Kay Martinen]

Am 04.04.21 um 20:18 schrieb Ulli Horlacher:

> Marc Haber <mh+usene...@zugschl.us> wrote:
>
>>> Vor systemd gabs diese Probleme nicht.
>>
>> Innovation erfordert Anpassung.
>
> Innovation bedeutet Fortschritt. Und nicht "VIEL mehr (unnoetige) Probleme"
>

Sinngemäß aus einem Alten Buch "Der Laser war eine Lösung für die es
noch keine Probleme/Anwendungen gab"

VOR der Erfindung des Lasers gab es das "Problem" 3D-Hologramm auch
nicht, oder die Möglichkeit damit einen Fusionsreaktor zu zünden.

Funktionieren Fusionsreaktoren denn schon? Willst du sie deswegen nicht
haben?

Nix FÜR systemd, aber es ist nun mal da. Und vielleicht funktioniert es
irgendwann ebenso gut... wie SysVInit, spätere Fusionsreaktoren oder...
Windows 10. :-/

Du kannst es entfernen, Devuan benutzen oder... EISFAIR. Den gibt es in
32 und 64 Bit und immer mit SysVInit. Der Name steht für "Easy" und
modular. Siehe <www.eisfair.org>

[Ulli Horlacher]

Marc Haber <mh+usene...@zugschl.us> wrote:

> >> Da ist irgendwas an Euren Systemen kaputt.
> >
> >Dann sind Ubuntu, RHEL und SLES kaputt.
>
> Für RHEL und SLES dürftet Ihr Support gekauft haben

Nein.

[Marc Haber]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>
>> >> Da ist irgendwas an Euren Systemen kaputt.
>> >
>> >Dann sind Ubuntu, RHEL und SLES kaputt.
>>
>> Für RHEL und SLES dürftet Ihr Support gekauft haben
>
>Nein.

Dein Arbeitgeber steht auf Schmerzen, nehme ich an? Enterprise-Linxe
betreibt man doch NUR weil es Support dafür gibt, sonst nimmt man was
anständiges?

[Ulli Horlacher]

Marc Haber <mh+usene...@zugschl.us> wrote:

> >> Für RHEL und SLES dürftet Ihr Support gekauft haben
> >
> >Nein.
>
> Dein Arbeitgeber steht auf Schmerzen, nehme ich an? Enterprise-Linxe
> betreibt man doch NUR weil es Support dafür gibt, sonst nimmt man was
> anständiges?

Nein.
Es gibt diverse andere Gruende.
Und Kommerz-Support gibt es zb auch fuer Debian oder Ubuntu.

[Kay Martinen]

Am 05.04.21 um 10:49 schrieb Ulli Horlacher:

> Marc Haber <mh+usene...@zugschl.us> wrote:
>
>>>> Für RHEL und SLES dürftet Ihr Support gekauft haben
>>>
>>> Nein.
>>
>> Dein Arbeitgeber steht auf Schmerzen, nehme ich an? Enterprise-Linxe
>> betreibt man doch NUR weil es Support dafür gibt, sonst nimmt man was
>> anständiges?
>
> Nein.
> Es gibt diverse andere Gruende.
> Und Kommerz-Support gibt es zb auch fuer Debian oder Ubuntu.

Oh!

Und wer klingelt dann aus wer den Leisten muß wenn dann auch noch
Kommerz-Software auf den Debian/Ubuntu läuft - mit zugekauftem Support?

Ich dachte z.B. immer das Hersteller von Linux-Kaufsoft auf einer
bestimmten Plattform mit Support bestünden. Ansonsten kein oder
eingeschränkter Support/Haftung.

Von Debian glaube ich nicht das direkt support verkauft wird. Bei Ubuntu
schon. Aber das einer/beide da eigene Distros für Pflegen eher nicht.

RHEL/SLES zeichnen sich doch bisher dadurch aus das ihre
Enterprise-Linuxe eine "bessere" Codebasis haben sollten. Zumindest als
die Community-Versionen.

Wenn das nur "gut abgehangen" wäre könnte man auch Debian nehmen. Das
ist ja bekanntermaßen eher konservativ.

[Sieghard Schicktanz]

Hallo Kay,

Du schriebst am Sun, 4 Apr 2021 21:22:45 +0200:

> > Innovation bedeutet Fortschritt. Und nicht "VIEL mehr (unnoetige)
> > Probleme"
>
> Sinngemäß aus einem Alten Buch "Der Laser war eine Lösung für die es
> noch keine Probleme/Anwendungen gab"

Was schon zum Zeitpunkt des Schreibens falsch war.

> VOR der Erfindung des Lasers gab es das "Problem" 3D-Hologramm auch
> nicht, oder die Möglichkeit damit einen Fusionsreaktor zu zünden.

Doch, das '"Problem" 3D-Hologramm' gab es schon länger zuvor, es gab "nur"
keine recht geeignete Lichtquelle dafür. Und für die Möglichkeit. einen
Fusionsreaktor zu zünden, gab es durchaus viele Ansätze, aber eben noch
keine Möglichkeit, das mit Licht zu machen. Zudem war der Laser einfach
"nur" eine Weiterentwicklung des schon länger bekannten MASER, der dasselbe
Prinzip bei den viel längerwelligen und deshalb demit leichter zu nutzenden
Mikrowellen realisierte. _Das_ war eigentlich die prinzipielle Innovation,
basierend auf der schon Jahrzehnte theoretisch bekannten stimulierten
Emission.
Nur um mal den Entwicklungsgang klarzzustellen.

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[Marc Haber]

Kay Martinen <use...@martinen.de> wrote:
>Von Debian glaube ich nicht das direkt support verkauft wird.

Nein, freilich nicht, aber es gibt genug sehr kompetente Firmen, die
durch die Beschäftigung von Debian Developern hinreichende Nähe zum
Projekt haben, dass ich jederzeit an höchst kompetenten Support zu
glauben bereit bin.

Leider reicht das vielen kommerziellen Anwendern nicht.

Grüße
Marc

[Kay Martinen]

Am 05.04.21 um 13:27 schrieb Marc Haber:

> Kay Martinen <use...@martinen.de> wrote:
>> Von Debian glaube ich nicht das direkt support verkauft wird.
>
> Nein, freilich nicht, aber es gibt genug sehr kompetente Firmen, die
> durch die Beschäftigung von Debian Developern hinreichende Nähe zum
> Projekt haben, dass ich jederzeit an höchst kompetenten Support zu
> glauben bereit bin.

Sicherlich gibt es die. Ist Suse nicht auch so ähnlich entstanden?

Du machst doch im grunde das gleiche, nur als One-Man Show.

> Leider reicht das vielen kommerziellen Anwendern nicht.

Du meinst damit jetzt so Stereotype "Denken" wie
- Niemand wurde je gefeuert weil er IBM kaufte
- Wenn etwas kostenlos ist dann taugt es nichts.

?

Was ja dann unweigerlich wieder in die Richtung Freak-OS für Freaks
führen dürfte weil man sich ja auf keinerlei zentral gesteuerte
Stabilität verlassen könne... weswegen man vielleicht auch die
LTS-Versionen einführte.

[Ulli Horlacher]

Kay Martinen <use...@martinen.de> wrote:

> > Es gibt diverse andere Gruende.
> > Und Kommerz-Support gibt es zb auch fuer Debian oder Ubuntu.
>

> Und wer klingelt dann aus wer den Leisten muß wenn dann auch noch
> Kommerz-Software auf den Debian/Ubuntu läuft - mit zugekauftem Support?

Dieser Satz kein Sinn.

> Ich dachte z.B. immer das Hersteller von Linux-Kaufsoft auf einer
> bestimmten Plattform mit Support bestünden. Ansonsten kein oder
> eingeschränkter Support/Haftung.

Ja.

> Von Debian glaube ich nicht das direkt support verkauft wird. Bei Ubuntu
> schon. Aber das einer/beide da eigene Distros für Pflegen eher nicht.

Trotzdem kann man FUER Debian Support einkaufen.

> RHEL/SLES zeichnen sich doch bisher dadurch aus das ihre
> Enterprise-Linuxe eine "bessere" Codebasis haben sollten.

Das erzaehlen dir die Krawatten. Glaubst du denen?

[Marc Haber]

Kay Martinen <use...@martinen.de> wrote:
>Am 05.04.21 um 13:27 schrieb Marc Haber:

>> Leider reicht das vielen kommerziellen Anwendern nicht.
>
>Du meinst damit jetzt so Stereotype "Denken" wie
>- Niemand wurde je gefeuert weil er IBM kaufte
>- Wenn etwas kostenlos ist dann taugt es nichts.

Ja, oder "wenn auf der Supportrechnung nicht der Name steht den das
Betriebssytem beim Booten ausgibt UND der entscheidende Manager den
Namen nicht aus der Computerwoche kennt, können wir das nicht
verargumentieren".

[Kay Martinen]

Am 05.04.21 um 15:01 schrieb Ulli Horlacher:

> Kay Martinen <use...@martinen.de> wrote:
>
>>> Es gibt diverse andere Gruende.
>>> Und Kommerz-Support gibt es zb auch fuer Debian oder Ubuntu.
>>
>> Und wer klingelt dann aus wer den Leisten muß wenn dann auch noch
>> Kommerz-Software auf den Debian/Ubuntu läuft - mit zugekauftem Support?
>
> Dieser Satz kein Sinn.

Welchen Teil von "Wer hat's erfunden" hast du nicht verstanden? :-)

>> Ich dachte z.B. immer das Hersteller von Linux-Kaufsoft auf einer
>> bestimmten Plattform mit Support bestünden. Ansonsten kein oder
>> eingeschränkter Support/Haftung.
>
> Ja.

Schön. Oder auch nicht. Kommt drauf an.

>> Von Debian glaube ich nicht das direkt support verkauft wird. Bei Ubuntu
>> schon. Aber das einer/beide da eigene Distros für Pflegen eher nicht.
>
> Trotzdem kann man FUER Debian Support einkaufen.

Glaube ich dir.

>> RHEL/SLES zeichnen sich doch bisher dadurch aus das ihre
>> Enterprise-Linuxe eine "bessere" Codebasis haben sollten.
>
> Das erzaehlen dir die Krawatten. Glaubst du denen?

Einem Krawattenträger (Business-Droid) glaube ich überhaupt nix.

Welche Rechtfertigung sollte es denn sonst geben für den gleichen Eimer
Eintopf mal nix und mal x Tausend $/€ (pro Sockel?) zu verlangen? Nur
der mit gekaufte Support? Das fände ich zu dünn.

[Andreas Kohlbach]

On Mon, 5 Apr 2021 20:26:09 +0200, Kay Martinen wrote:
>
> Welchen Teil von "Wer hat's erfunden" hast du nicht verstanden? :-)

Die Schweizer. Das war jetzt wieder einfach. ;-)
--
Andreas

https://news-commentaries.blogspot.com/

[Ulli Horlacher]

Kay Martinen <use...@martinen.de> wrote:
> Am 05.04.21 um 15:01 schrieb Ulli Horlacher:
> > Kay Martinen <use...@martinen.de> wrote:
> >
> >>> Es gibt diverse andere Gruende.
> >>> Und Kommerz-Support gibt es zb auch fuer Debian oder Ubuntu.
> >>
> >> Und wer klingelt dann aus wer den Leisten muß wenn dann auch noch
> >> Kommerz-Software auf den Debian/Ubuntu läuft - mit zugekauftem Support?
> >
> > Dieser Satz kein Sinn.
>
> Welchen Teil von "Wer hat's erfunden" hast du nicht verstanden? :-)

Das macht nun noch weniger Sinn.
WAS willst du damit sagen/wissen?

> Welche Rechtfertigung sollte es denn sonst geben für den gleichen Eimer
> Eintopf mal nix und mal x Tausend $/€ (pro Sockel?) zu verlangen? Nur
> der mit gekaufte Support? Das fände ich zu dünn.

SLES und RHEL gibts nicht kostenlos (fuer Produktionseinsatz).
Man muss auf jeden Fall dafuer bezahlen. Die Preise schwanken allerdings
je nach Organisation.

[Marc Haber]

Christian Garbs <mi...@cgarbs.de> wrote:
>Hat etwas gedauert und ist etwas länger geworden. Ich warte mal
>Kommentare und Korrekturen ab und kippe es dann auch in mein Blog,
>daher die etwas Usenet-untypische Formatierung.

Vielen Dank dafür, dass Du Dir diese Arbeit gemacht hast! Ich weiß das
sehr zu schätzen. Kommentare besonders zu meiner Konfiguration sind
inline. Meine IPv6-Adressen hole ich mir per OpenVPN von einem Server
im Rechenzentrum, deswegen sind sie komplett statisch und ich habe
keine Erfahrungen mit Dynamik. Das Bedürfnis, das IPv6 von meinem
Provider 1&1 zu benutzen, ist über Ostern stärker geworden, weil
Google meine RZ-IP-Adressen zunehmend nicht mag und ich ständig statt
Suchergebnisse zu bekommen erstmal Captchas ausfüllen muss.

> Ziel: Im Hausnetz dynamisch zugeordnete IPv6-Adressen aus dem

s/Adressen/Netze/

> Dialup-Internetzugang bereitstellen. Die Fritz!Box bekommt bei der

... in Deutschland ... bei den großen Providern, z.B. Telekom und 1&1
...

> Einwahl ein /56 und reicht daraus ein /64 über den internen
> Router/Server an das dahinterliegende Hausnetz weiter. Alle paar
> Stunden wird das ausgewählte /64 gewechselt, ebenso bei einem
> Reconnect (denn dann gibt es ein neues /56).

PPP-Reconnect, damit das niemand mit dem DSL-Reconnect verwechselt. Es
gibt ja immer noch Provider mit 24h-Zwangstrennung.

> ,----
> | __________
> | ( Internet )
> | """"""""""
> | |
> | [FritzBox]
> | |
> | | DMZ
> | |
> | [Linux-Server]
> | |
> | | Hausnetz
> | |
> | |- Client 1
> | |- Client 2
> | …
> `----

Können wir uns auf "Transfernetz" statt "DMZ" einigen? Das ist aber
eine Stilfrage.

> Je nach Netz ist die DMZ mal komplett leer (Ethernetkabel vom Server
> direkt zur Fritz!Box) oder sie umfasst das Haus-WLAN und dort tummeln
> sich Drucker, Fernseher, Laptops, Smartphones etc. – alles, was nicht
> an das „wichtige“ interne Hausnetz ran muss.
>
> (DISCLAIMER: der Rechnerzoo schrumpft zusammen und teilweise ist das
> Hausnetz inzwischen leer – ich bin mir aber 100% sicher, dass die
> Prefix-Delegation dort früher, als es noch mehr Geräte gab, korrekt
> funktioniert hat.)

Man könnte natürlich auch dem Linux-Server mehrere (ggf virtuelle)
Imterfaces verpassen und jeweils ein /64 dorthin verteilen, ggf. mit
einem VLAN-fähigen Switch.

> Als lokalen IPv6-Adressraum nehme ich `fdXX/64', der Server kriegt
> dort jeweils Adresse `1'. Das ist leicht zu merken und
> dementsprechend ist seine IPv6-Adresse kürzer als unter IPv4:
> `fdXX:1/64' vs. `192.168.XX.1/24' :)
>
> `XX' ist für IPv4 und IPv6 gleich, so muss ich mir nur merken „ah, das
> 13er Netz“ und der Rest ergibt soch von alleine.

Das für Demo und Dokumentationszwecke vorgesehene IPv6-Netz ist
2001:db8::/32, ein /56 könnte z.B. 2001:db8:1111:11xx::/56 sein.

> Ich weiß nicht, ob alles davon relevant ist. Das wichtigste dürfte
> die Einstellung /DNS-Server und IPv6-Präfix (IA_PD) zuweisen/ sein.
> Ich benutze in der Weboberfläche die _Erweiterte Ansicht_.
>
> - Internet
> - Zugangsdaten
> - IPv6
> - IPv6-Unterstützung
> - Unterstützung für IPv6 aktiv
> - IPv6-Anbindung
> - (x) Immer eine native IPv5-Anbindung nutzen (empfohlen)
> - Heimnetz
> - Heimnetzübersicht / Netzwerk (je nach FritzOS-Version)
> - Netzwerkeinstellungen
> - IP-Adressen
> - IPv6-Adressen / IPv6-Konfiguration
> - Unique Local Adresses
> - (x) Unique Local Addresses (ULA) zuweisen, solange keine
> IPv6-Internetverbindung besteht (empfohlen)
> - Weitere IPv6-Router im Heimnetz
> - Diese Fritz!Box stellt die Standard Internetverbindung
> zur Verfügung
> - DHCPv6-Server im Heimnetz
> - (x) DHCPv6-Server in der FRITZ!Box für das Heimnetz
> aktivieren
> - (x) DNS-Server und IPv6-Präfix (IA_PD) zuweisen

Zieht die Fritzbox nach einem Prefixwechsel bzw. beim Nichtbestehen
einer Netzverbindung das zugewiesene Präfix zuverlässig, sofort und
korrekt zurück, oder sind Dir da irgendwelche Ungereimtheiten
aufgefallen? Kommt es vor, dass beim Prefixwechsel seitens des
Providers zwischendurch ULA-Adressen verteilt und direkt wieder
zurückgezogen werden? Oder lässt die Fritzbox das Announcement für die
ULA-Adressen einfach die ganze Zeit "draußen"?

> Ich habe gerne sprechende Namen, bin mit `eth0', `tr0' usw. groß
> geworden und möchte auf allen Servern direkt die logische Funktion
> eines Devices erkennen. Daher benenne ich die Devices manuell um:
>
> - `dmz0' geht nach außen Richtung Fritz!Box
> - `eth0' geht nach innen ins Hausnetz

Ja, so mache ich das auch, allerdings sind bei mir da noch VLANs
dazwischen (mein Linux-Router hat keinen Link ohne VLAN-Tags, da war
ich ganz konsequent), da kann man die Interfacenamen sowieso frei
belegen. Bei Interesse kann ich dazu noch etwas mehr sagen.

> Für die weitere Konfiguration benutze ich klassisch `ifupdown'.

Ich benutze systemd-networkd.

> | iface dmz0 inet6 auto
> | dhcp 1
> | request_prefix 1
> | accept_ra 2
> | pre-down /sbin/start-stop-daemon -s USR1 --stop --pidfile /run/dhclient6.dmz0.pid --exec /sbin/dhclient
> | pre-down rm /run/dhclient6.dmz0.pid

Ok, da wird also viel Magie aus ifupdown-Skripten benutzt. Da muss ich
mal wieder in das Paket reinschauen.

> - `YY' ist das kürzel für den IPv4-DMZ-Adressraum Das ginge auch
> einfacher über DHCP, aber wenn sich in der DMZ noch andere Geräte
> tummeln und ich den Server ansprechen will, habe ich gerne eine
> feste Adresse. (Gut, die Fritz!Box kann auch feste Adressen per
> DHCP vergeben. Ich ziehe die „historisch gewachsen“-Karte.) Für
> IPv6 kommen wir in der DMZ auf jeden Fall ohne feste Adresse aus,
> daher steht da nichts.

Das mache ich genauso. Die Fritzbox ist zwar der Meister über die
IPv4-Adressen in "ihrem" LAN und hat einen kleinen DHCP-Range, der
Linux-Router hat aber eine fest konfigurierte statische Adresse
außerhalb des DHCP-Ranges.

> - `dhcp 1', `request_prefix 1' und `accept_ra 2' sind die magischen
> Schlüsselwörter, die ich irgendwann mal ausgependelt habe, siehe
> _interfaces(5)_.
>
> - Der `dhclient6' stoppt(e) nicht ganz sauber, wenn das Interface
> runterfährt. Um es wieder hochfahren zu können, muss man as
> PID-File manuell entfernen.

Ok, das wird also der Bereich, wo mir mein systemd-networkd weh tun
wird. Eventuell doch erst mal den Router nach Bullseye updaten, der
systemd dort ist halt doch erheblichst frischer.

>1.4.3 Netzwerk-Konfiguration
>----------------------------
>
> In der `/etc/sysctl.conf' habe ich unter anderem folgendes stehen.
> Sieht wichtig aus:
>
> ,----
> | # EXPERIMENTAL
> | # ipv6 privacy extension ONLY on external device
> | # https://wiki.ubuntuusers.de/IPv6/Privacy_Extensions/
> | net.ipv6.conf.dmz0.use_tempaddr = 2
> | net.ipv6.conf.dmz0.temp_prefered_lft = 14400

Auf dem Router halte ich das für unnötig, es sei denn, Du hast auch
Benutzer dort. Der Transport von Nutztraffic läuft nach meiner
Erwartung sowieso über die Link-Local-Adressen; ich wäre überrascht
wenn das bei Prefix Delegation anders wäre.

Möchtest Du Systeme im Hausnetz über IPv6 aus dem Internet adressieren
können, d.h. hat die Fritzbox eine Route für die delegierten Prefixe
angelegt?

> | # Uncomment the next line to enable packet forwarding for IPv6
> | # Enabling this option disables Stateless Address Autoconfiguration
> | # based on Router Advertisements for this host
> | net.ipv6.conf.all.forwarding=1
> |
> | ### enable SLAAC autoconfiguration for IPv6 even when we are forwarding:
> | net.ipv6.conf.all.accept_ra=2
> `----

Ja, wichtig, beides. accept_ra=2 ist eine Linux-Spezialität.

> Mit der bisherigen Konfiguration sollte der Server die von der
> Fritz!Box delegierten Präfixe bereits sehen und benutzen. Allerdings
> leitet er sie nicht an die Clients im Hausnetz weiter. Dafür nehmen
> wir `radvd'. Hier ist der entscheidende Knackpunkt, dass die
> dynamische Konfiguration des delegierten Prefixes nur mit /64
> funktioniert. Wenn uns der Internetprovider nur ein /64 gibt, können
> wir das nicht einfach kleinschneiden und weiterverteilen. Größer als
> /64 geht wohl auch nicht. (Ist länger her, dass ich das
> zusammengebaut habe, ich kann jetzt nur nach Aktenlage – also den
> Kommentaren im Configfile – berichten.)

Ja, das ist richitg, SLAAC braucht zwingend ein /64. Offensichtlicher
Grund: Innerhalb des Prefix nimmt jeder Client ein EUI-64 (bzw. eine
ähnlich gebildete privacy-extension-Adresse) und die ist nun mal 64
Bits lang.

Ich persönlich finde radvd nicht so toll, das ist voller Fallstricke -
und das, obwohl es im September 2020 das letzte Release gab. So ganz
tot ist der Upstream also nicht, aber ein Release alle drei Jahre
finde ich nicht toll.

> ,----
> | interface eth0
> | {
> | AdvSendAdvert on;
> |
> | # special prefix for prefix delegation ("grab current IP address from that interface")
> | prefix ::/64
> | {
> | DeprecatePrefix on;
> | DecrementLifetimes on;
> | };
> | RDNSS fdXX::1 {
> | };
> | DNSSL interne.dns.domsain.foo {
> | };
> | };
> `----
>
> Wie üblich ist da ein `XX' für den Server und hier kann sogar das
> interne DNS (Server + Domain) gesetzt werden.

RDNSS ist leider nicht besonders gut und breit unterstützt, es gibt
haufenweise Systeme die das nicht können. Ich liefere den DNS-Server
noch zusätzlich per stateless DHCPv6 dazu und prügle den internen
Servern ihre Service-Adressen ebenfalls per stateless DHCPv6
hinterher. Statische Adressen werden bei IPv6 mit einem DUID
konfiguriert; ich kratze mir den mit Wireshark aus der Leitung und
ärgere mich jedes Mal dass der ISC DHCPv6 den DUID nicht einfach
loggt. Zum Mäusemelken.

Im Zweifel nehmen die Clients eh den IPv4-DNS-Server :-( wenn man
sich nicht getraut hat ein IPv6-only-Netz zu definieren (das scheitert
bei mir regelmäßig an github).

>1.4.6 Firewall auf dem Server
>-----------------------------
>
> Ist ein eigenes Kapitel :-) Gleichlautende Regeln für IPv4/IPv6 lassen
> sich ganz wunderbar über `nftables' erledigen, die Config ist viel
> einfacher und übersichtlicher als mit `iptables'.

Das würde mich auch etwas detaillierter interessieren, ich hänge da
immer noch bei iptables über ferm fest (ein cooles Tool, leider auch
nur noch so barely alive).

> Wenn ich nichts vergessen habe, ist das alles.

DANKE!

[Stefan Froehlich]

On Tue, 06 Apr 2021 12:53:25 Marc Haber wrote:
> >1.4.6 Firewall auf dem Server
> >-----------------------------
> >
> > Ist ein eigenes Kapitel :-) Gleichlautende Regeln für IPv4/IPv6 lassen
> > sich ganz wunderbar über `nftables' erledigen, die Config ist viel
> > einfacher und übersichtlicher als mit `iptables'.
>
> Das würde mich auch etwas detaillierter interessieren, ich hänge
> da immer noch bei iptables über ferm fest (ein cooles Tool, leider
> auch nur noch so barely alive).

IPv6 gibt's hier (bereits providerseitig) leider nicht, aber
nftables sind trotzdem praktisch - es ist zwar ein etwas zäher
Umstieg, aber IMO schon ein lohnender.

Am angenehmsten daran war für mich die Einführung von "sets",
z.B. auf Port-Ebene für WhatsApp:

#v+
$NFT add set inet filter whatsapp_tcp { type inet_service \; }
$NFT add element inet filter whatsapp_tcp { 4244, 5222, 5223, 5228, 50318, 59234 }
$NFT add set inet filter whatsapp_udp { type inet_service \; }
$NFT add element inet filter whatsapp_udp { 3478, 45395, 50318, 59234 }
#v-

Es ist dann nur noch eine einzige Regel erforderlich, die sich auf
das Set bezieht, um alle darin enthaltenen Ports zu erschlagen. Ganz
ähnlich wird das vermutlich auch mit IPv4/IPv6 funktionieren.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan. Pummelig und ferklig!
(Sloganizer)

[Marc Haber]

Stefan...@Froehlich.Priv.at (Stefan Froehlich) wrote:
>On Tue, 06 Apr 2021 12:53:25 Marc Haber wrote:
>IPv6 gibt's hier (bereits providerseitig) leider nicht, aber
>nftables sind trotzdem praktisch - es ist zwar ein etwas zäher
>Umstieg, aber IMO schon ein lohnender.
>
>Am angenehmsten daran war für mich die Einführung von "sets",
>z.B. auf Port-Ebene für WhatsApp:

ipsets gibt es für iptables aber auch. In ferm braucht man das
allerdings, das kann Variablen. ipsets sind wohl innerhalb des Kernels
auch krass effizienter, aber das tut meiner Firewall hier nicht weh.
Kommerziell eingesetzte Linux-Firewalls "unter Last" betreue ich im
Moment nicht.

Das, was ich vor Jahren mal auf einer Konferenz von nftables sah, war
ferm nicht unähnlich, ich brauche nur den Einstieg und etwas Ruhe.

[Kay Martinen]

Am 06.04.21 um 00:50 schrieb Ulli Horlacher:

> Kay Martinen <use...@martinen.de> wrote:
>> Am 05.04.21 um 15:01 schrieb Ulli Horlacher:
>>> Kay Martinen <use...@martinen.de> wrote:
>>>
>>>>> Es gibt diverse andere Gruende.
>>>>> Und Kommerz-Support gibt es zb auch fuer Debian oder Ubuntu.
>>>>
>>>> Und wer klingelt dann aus wer den Leisten muß wenn dann auch noch
>>>> Kommerz-Software auf den Debian/Ubuntu läuft - mit zugekauftem Support?

> WAS willst du damit sagen/wissen?

Das ich annehme ihr hättet neben Debian mit Kommerz-Support auch
Kommerzielle Software mit Support die da drauf läuft. Und da wir hier im
linux.misc und im thread 'systemd kaputt' sind frage ich mich wie man da
bei Fehlern auseinander klamüsern will ob das ein System oder
Anwendungs-Fehler ist. Damit man den richtigen Supporter anspricht.
Denkbar ist ja auch das ein Systemfehler die Anwendung stört und dies
wieder ein System problem verursacht.

Was dann: Support-Ping-Pong? Hotline-Bingo?

>> Welche Rechtfertigung sollte es denn sonst geben für den gleichen Eimer
>> Eintopf mal nix und mal x Tausend $/€ (pro Sockel?) zu verlangen? Nur
>> der mit gekaufte Support? Das fände ich zu dünn.
>
> SLES und RHEL gibts nicht kostenlos (fuer Produktionseinsatz).
> Man muss auf jeden Fall dafuer bezahlen. Die Preise schwanken allerdings
> je nach Organisation.

Also Nasenfaktor! dann bleibt der einzige Unterschied doch nur der
Support-einkauf, der SLA Level und ???

[Stefan Froehlich]

On Tue, 06 Apr 2021 14:42:58 Marc Haber wrote:
> Stefan...@Froehlich.Priv.at (Stefan Froehlich) wrote:
> >IPv6 gibt's hier (bereits providerseitig) leider nicht, aber
> >nftables sind trotzdem praktisch - es ist zwar ein etwas zäher
> >Umstieg, aber IMO schon ein lohnender.

> >Am angenehmsten daran war für mich die Einführung von "sets",
> >z.B. auf Port-Ebene für WhatsApp:

> ipsets gibt es für iptables aber auch. In ferm braucht man das
> allerdings, das kann Variablen.

Ok, das ist (wie vieles) an mir vorbeigegangen, ich habe meine
Regeln immer nur händisch und direkt in iptables codiert - ist ja
auch eine sehr überschaubare Infrastruktur; die sets kommen auch
noch als (besserer) Ersatz für xt_recent zum Einsatz.

> Das, was ich vor Jahren mal auf einer Konferenz von nftables sah,
> war ferm nicht unähnlich, ich brauche nur den Einstieg und etwas
> Ruhe.

Das mit der Ruhe ist immer das Problem. Was bei mir nicht alles auf
der Liste der zu aktualisierenden Dinge stünde...

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan, so glanzvoll wie die Gier. Glaube das Unglaubliche!!
(Sloganizer)

[Ulli Horlacher]

Kay Martinen <use...@martinen.de> wrote:

> Das ich annehme ihr hättet neben Debian mit Kommerz-Support auch
> Kommerzielle Software mit Support die da drauf läuft. Und da wir hier im
> linux.misc und im thread 'systemd kaputt' sind frage ich mich wie man da
> bei Fehlern auseinander klamüsern will ob das ein System oder
> Anwendungs-Fehler ist. Damit man den richtigen Supporter anspricht.
> Denkbar ist ja auch das ein Systemfehler die Anwendung stört und dies
> wieder ein System problem verursacht.

Wenn die Anwendungssoftware nicht (richtig) funktioniert, ist deren
Support dran. Ganz einfach. Ob das dann ein OS-basiertes Problem ist, ist
UNS erstmal egal. Die muessen das loesen.

> > SLES und RHEL gibts nicht kostenlos (fuer Produktionseinsatz).
> > Man muss auf jeden Fall dafuer bezahlen. Die Preise schwanken allerdings
> > je nach Organisation.
>
> Also Nasenfaktor! dann bleibt der einzige Unterschied doch nur der
> Support-einkauf, der SLA Level und ???

Nein. Nochmal: man kann SLES und RHEL nur kaufen. Kostenlos gibts das
nicht. Also kein Unterschied weil es mangels Alternative keinen
Unterschied gibt.

[Kay Martinen]

Am 06.04.21 um 16:30 schrieb Ulli Horlacher:

> Kay Martinen <use...@martinen.de> wrote:
>
>> Also Nasenfaktor! dann bleibt der einzige Unterschied doch nur der
>> Support-einkauf, der SLA Level und ???
>
> Nein. Nochmal: man kann SLES und RHEL nur kaufen. Kostenlos gibts das
> nicht. Also kein Unterschied weil es mangels Alternative keinen
> Unterschied gibt.

Schon wieder ein nein...

Du fragst nach dem Unterschied? Hier vielleicht...

Ich schrieb kürzlich meine Annahme:

>> RHEL/SLES zeichnen sich doch bisher dadurch aus das ihre
>> Enterprise-Linuxe eine "bessere" Codebasis haben sollten.

und deine Antwort...

> Das erzaehlen dir die Krawatten. Glaubst du denen?

,,, kann ich nur als krasse NEIN verstehen.

Ergo: Gleiche "Distribution", gleich Codebasis = Kein Unterschied.

Nur ein Anderer name und ein Preisschild vor dem "du willst Support,
dann Zahl mal"

Und DAS bezeichne ich als DÜNN. Oder als Mogelpackung. :-)

Oder hast du eine Krawatte getragen als du obiges behauptet hast?

Wirklich, ich hab eigentlich bisher angenommen das die Fedora als
Betatest für ihr RHEL nehmen. Das bedingt m.E. das es unterschiede geben
MUSS. Und wenn die nur so wären wie bei Debian Testing vs. Debian Stable.

Aber du willst mir jetzt erzählen das die alle den gleichen Code benutzen?

Ohhh! Oder liegt das mißverständnis darin das ich mit "codebasis" den
Gesamt-block (Distribution Vx, Versionsstände Vy, Paketumfang Z)
meinte... und du das evtl. im Quellkode-sinne (ein Source, div. Commits
für A oder B oder auch mal ein Fork)?

Dann hab ich mich evtl. unglücklich ausgedrückt.

[Marc Haber]

Marc Haber <mh+usene...@zugschl.us> wrote:
>> - DHCPv6-Server im Heimnetz
>> - (x) DHCPv6-Server in der FRITZ!Box für das Heimnetz
>> aktivieren
>> - (x) DNS-Server und IPv6-Präfix (IA_PD) zuweisen

Nicht die dritte Option, die zusätzlich noch IA_NA spielt?

>> | iface dmz0 inet6 auto
>> | dhcp 1
>> | request_prefix 1
>> | accept_ra 2
>> | pre-down /sbin/start-stop-daemon -s USR1 --stop --pidfile /run/dhclient6.dmz0.pid --exec /sbin/dhclient
>> | pre-down rm /run/dhclient6.dmz0.pid
>
>Ok, da wird also viel Magie aus ifupdown-Skripten benutzt. Da muss ich
>mal wieder in das Paket reinschauen.

ifupdown benutzt intern eine seltsame Pseudonotation, wenn das
wirklich diejenige ist, die verwendet wird und nicht eine Art der
Dokumentation darstellt, ist inet6.defn im Source-Paket einschlägig;
im Binärpaket landet die Datei nicht. Da wird im entsprechenden Fall
dhclient -6 -P -I aufgerufen.

Wenn ich auf einem Testystem dhclient -v -d -P -N aufrufe, lässt sich
die Kiste von der Fritzbox eine IP-Adresse zuweisen und erfragt einen
/62 prefix, wobei mir völlig unklar ist, wie der dhclient zu einem /62
kommt. Die Maschine hat jedenfalls mehr als vier Interfaces; entweder
ist das ein statischer Default, oder die Heuristik zur Ermittlung
wieviele Netze hinter dem System liegen ist mindestens mal seltsam.

Auch mit --prefix-len-hint 60 wird weiterhin ein /62 angefordert. Erst
als ich die Datei mit der Lease, /var/lib/dhcp/dhclient6.leases,
lösche, erfragt der dhclient ein /60 von der Fritzbox und bekommt das
auch.

An diesem Punkt wird vielleicht auch
https://wiki.debian.org/IPv6PrefixDelegation interessant, da steht
nämlich, dass man noch ein DHCP-Client-Hook-Script braucht, das die
IP-Adressen auf die Interfaces konfiguriert. Das habe ich dann nicht
mehr probiert, weil das auf mein Setup eh nicht mehr passt.

[Christian Garbs]

Mahlzeit!

Thomas Noll <-_tn...@web.de> wrote:
> Am Sat, 03 Apr 2021 20:48:48 +0200 schrieb Christian Garbs:

>> Die Crux scheint dieser Satz zu sein:
>>
>> | When configured, radvd picks all non-link-local prefix assigned to
>> | the interface and starts advertising it.
>>
>> Das würde bedeuten, dass radvd nicht die Prefixe von dmz0 auf eth0
>> announced, sondern die von eth0 auf eth0. Auf eth0 sind aber noch
>> keine Prefixe, weil der dhcpv6-Client sie ja auf dmz0 empfangen hat.
>
> Jepp.
>
>> Hrmpf.
>
> Jepp. ;)
>
>> Im Wiki steht direkt darüber eine "große" Lösung mit einem
>> Haufen Skripting, da habe ich keine Lust drauf ;-) Dadrunter steht
>> eine Config für wide-dhcpv6, die klingt schon eher interessant. Der
>> würde wohl Prefixe von dmz0 auf eth0 rüberschaufeln können und dann
>> kommt radvd zum Zug (wenn er dann nicht wieder über den Spezial-Prefix
>> meckert). Da muss ich beizeiten mal mit rumspielen.

Nachdem ich mit tcpdump herausgefunden hatte, dass die Fritz!Box immer
ein /62 delegiert (das scheint nicht verhandel- oder konfigurierbar zu
sein), war die Konfiguration von wide-dhcpv6 (aus dem Paket
wide-dhcpv6-client) einfach und straight-forward.

Meine /etc/wide-dhcpv6/dhcp6c.conf:

+v
# request a Prefix Delegation on dmz0 (which itself is configured by SLAAC)
# and add the received Prefix to eth0

# calculations:
# - our ISP gives a /56 on connect
# - the Fritz!Box delegates a /62 (this seems to be fixed)
# - we want to announce a /64 (because SLAAC), so we have 2 bits of sla-id (sla-len=2)

interface dmz0 {
send ia-pd 0;
send rapid-commit;
};

id-assoc pd 0 {
prefix-interface eth0 {
sla-id 1;
sla-len 2;
};
};
-v

In /etc/network/interfaces.d/dmz0 ist die IPv6-Konfiguration auf die
eine Zeile

+v
iface dmz0 inet6 auto
-v

zusammengeschrumpft. Die Optionen dhcp, request_prefix und accept_ra
werden nicht mehr benötigt, das übernimmt der wide-dhcpv6.

Der fordert jetzt also einen Präfix auf dmz0 an und setzt ihn dann auf
eth0, woraufhin radvd ihn weiterverteilen kann.

Zumindest dann, wenn er Lust drauf hat:

- wenn radvd gestartet wird, nachdem wide-dhcpv6 den delegierten
Präfix auf eth0 gesetzt hat, verteilt er den Präfix weiter

- wenn ich einen Tag später draufgucke, dann announced radvd nicht
mehr!

Vermutung: Der delegierte Präfix läuft irgendwann ab, darum nimm radvd
ihn runter. Er kriegt aber nicht mit, dass wide-dhcpv6 (nach Ablauf
oder bei Reconnect der Fritz!Box) einen neuen Präfix draufsetzt.

Das ist blöd.

Ein einfaches "service radvd restart" reicht aus, um den delegierten
Präfix instantan an den vorher prefixlosen Client weiterzuverteilen.

Da werde ich nochmal mit der /etc/wide-dhcpv6/dhcp6c.conf rumspielen,
dort sollten sich auch Skripte starten lassen, wenn bestimmte Sachen
passieren. Unschön, aber wohl lösbar.

> Dann schaff dir aber noch ein paar Geräte an, damit sich das lohnt.
> Und du auch z.B ein /60 zum weiteren routen verwenden kannst, und nicht
> nur direkte Clients bedienst.

Ein durchgehendes /60 scheint wegen des delegierten /62 gar nicht
möglich zu sein, außer ich requeste mir vier Präfixe und hoffe, dass
sie nebeneinanderliegen…

Für meinen Anwendungsfall (effektiv gar keine Clients und leeres Netz)
komme ich mit dem /62 aber erstmal hin ;-)


Auf jeden Fall Danke - radvd ist doof (daserwähnte Marc ja auch
schon), aber generell funktioniert es jetzt schon mal.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Ein Systemadministrator ist nur so gut wie sein letztes Backup.

[Christian Garbs]

Mahlzeit!

Marc Haber <mh+usene...@zugschl.us> wrote:

> Wenn ich auf einem Testystem dhclient -v -d -P -N aufrufe, lässt sich
> die Kiste von der Fritzbox eine IP-Adresse zuweisen und erfragt einen
> /62 prefix, wobei mir völlig unklar ist, wie der dhclient zu einem /62
> kommt. Die Maschine hat jedenfalls mehr als vier Interfaces; entweder
> ist das ein statischer Default, oder die Heuristik zur Ermittlung
> wieviele Netze hinter dem System liegen ist mindestens mal seltsam.

Genau das Verhalten habe ich hier auch - es gibt immer ein /62.

> Auch mit --prefix-len-hint 60 wird weiterhin ein /62 angefordert. Erst
> als ich die Datei mit der Lease, /var/lib/dhcp/dhclient6.leases,
> lösche, erfragt der dhclient ein /60 von der Fritzbox und bekommt das
> auch.

Das wollte ich jetzt auch mal ausprobieren – ich habe ja den
wide-dhcpv6 genommen und bin mir unsicher, ob der sich auch von der
alten /var/lib/dhcp/dhclient6.leases hat leiten lassen. Allerdings
scheint der gar keinen Prefix Length Hint zu können. Die "Doku" gibt
nichts weiteres her.

(Es gibt nur eine kommentierte Beispieldatei, keine Manpage, kein
Readme, keine Homepage, das Projekt lebt auf SourceForge (örks) und
der letzte Commit ist von 2015. Was hab ich mir da angelacht?
Immerhin funktioniert es… Ich glaube, ich freue mich auch drauf,
dass systemd das bald in hoffentlich funktionierend in einem Tool
vereint, statt wie jetzt mit wide-dhcpd (siehe Anfang des Absatzes),
dem ISC DHCP-Client (Skriptingorgie) und radvd (zickig)
herumzujonglieren. Oder muss ich mal NetworkManager ausprobieren,
kann der das?)

> An diesem Punkt wird vielleicht auch
> https://wiki.debian.org/IPv6PrefixDelegation interessant, da steht
> nämlich, dass man noch ein DHCP-Client-Hook-Script braucht, das die
> IP-Adressen auf die Interfaces konfiguriert. Das habe ich dann nicht
> mehr probiert, weil das auf mein Setup eh nicht mehr passt.

Mir war das auch zu kompliziert - ich habe es mit wide-dhcpv6 gelöst,
das sind eher so 10 Zeilen, die Hälfte davon Klammern :)
Siehe anderer Teilthread.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Von meinem iPhone gesendet

[Christian Garbs]

Mahlzeit!
Marc Haber <mh+usene...@zugschl.us> wrote:

>>1.4.6 Firewall auf dem Server
>>-----------------------------
>>
>> Ist ein eigenes Kapitel :-) Gleichlautende Regeln für IPv4/IPv6 lassen
>> sich ganz wunderbar über `nftables' erledigen, die Config ist viel
>> einfacher und übersichtlicher als mit `iptables'.
>
> Das würde mich auch etwas detaillierter interessieren, ich hänge da
> immer noch bei iptables über ferm fest (ein cooles Tool, leider auch
> nur noch so barely alive).

Ich hatte anderthalb Jahrzehnte lang ein wildes Shellskript mit >1000
Zeilen, das anhand einer Konfigurationsdatei iptables-Regeln erzeugt
hat (anfangs sogar noch ipchains). Das war zeitweise sogar auf
drei(!) verschiedenen Rechnern im Einsatz. Totaler Overkill und wild
gewachsen.

IPv6 habe ich mich nie getraut, weil ich dann dieses Monster hätte
komplett umschreiben müssen.

Mit nftables ist die Firewall bei gleicher Funktionalität viel
übersichtlicher als das Skript geworden. Außerdem kann ich die Regeln
direkt in nftables-Syntax konfigurieren, statt ein Skript zu
benötigen, dass mir die Konfiguration generiert. Die Regeln sind
dadurch atomar austauschbar und wenn irgendwo ein Syntaxfehler ist,
passiert einfach gar nichts, statt dass wie früher die alten Regeln
schon gelöscht sind, die neuen aber nie auftauchen. Und
/etc/nftables.conf ist direkt executable, das ist nett ;-)

Inhaltlich ist das total Consumer-Grade, das macht ungefähr das
gleiche wie die Fritz!Box-Firewall:

- von drinnen darf alles raus (eth0->dmz0)
- Antworten darauf dürfen von draußen wieder rein (dmz0->eth0)
- für IPv4 macht es NAT für das interne Netz (eth0)
- von außen sind bestimmte Ports zugänglich (dmz0->eth0)
(einige der Ports sind in der Fritz!Box freigeschaltet und
weitergeleitet und damit „richtig“ von außen erreichbar;
die anderen Port sind nur aus der DMZ erreichbar, z.B. aus dem
WLAN im Wohnzimmer)

Also eigentlich eher simpel.

Die VPN-Endpunkte, die ich hier habe, laufen unter „internes Netz“ und
haben keine eigenen Firewall-Regeln (bis auf das Öffnen der Wireguard-
bzw. OpenVPN-Ports), das reicht für mich aus. (In meinem alten Skript
musste ich noch jedes VPN-Device einzeln konfigurieren.) Da das
interne Netz sehr leer geworden ist, dient die Firewall größtenteils
noch dazu, das WLAN von den VPNs zu trennen.

Bevor ich jetzt frage, ob Du daran Interesse hast, kipp ich es einfach
hier rein ;-)

Die ganze „table inet“ gilt gleichzeitig für IPv4 und IPv6, nur ganz
vereinzelt wird darin explizit nochmal nach der Version unterschieden.

+v
#!/usr/sbin/nft -f

flush ruleset

# TODO: sprinkle with "comment" and "counter"

define dmz_if = dmz0

# Auth SSH Portmap NFS mountd uucpS_____ minidlna syncthing OpenVPN
define accept_tcp_ports = { auth, 443, 111, 2049, 2050, 4012, 4013, 8200, 22000, 58005 }
# Portmap ssdp NFS mountd syncthing WireGuard
define accept_udp_ports = { 111, 1900, 2049, 2050, 21027, 58006 }

define icmp_v4_types_global_ok = { echo-request, destination-unreachable, time-exceeded, parameter-problem, source-quench }
define icmp_v6_types_global_ok = { echo-request, destination-unreachable, time-exceeded, parameter-problem, packet-too-big }
define icmp_v6_types_local_ok = { nd-neighbor-advert, nd-neighbor-solicit, nd-router-advert, nd-router-solicit, mld-listener-query }

table inet filter {
chain input {
type filter hook input priority 0; policy drop;

# accept related, drop invalid
jump connection_state

# drop loopback traffic not from loopback
iif != lo ip daddr 127.0.0.1/8 counter drop comment "dropped loopback v4"
iif != lo ip6 daddr ::1/128 counter drop comment "dropped loopback v6"

# carte blanche for everything not coming from the DMZ
iifname != $dmz_if accept

# allow icmp
jump accept_icmp

# open external ports
tcp dport $accept_tcp_ports accept
udp dport $accept_udp_ports accept

# allow DHCPv6
ip6 nexthdr udp udp dport dhcpv6-client udp sport dhcpv6-server accept

# Email direkt von der Fritzbox annehmen
tcp dport { smtp } ip saddr 192.168.YY.1 accept

# reject statt drop
jump reject_if_possible
}
chain forward {
type filter hook forward priority 0; policy drop;

# loopback should not be here
iifname lo counter drop comment "dropped loopback forward"

# accept related, drop invalid
jump connection_state

# carte blanche for everything not coming from the DMZ
iifname != $dmz_if accept

# allow icmp
jump accept_icmp

# reject statt drop
jump reject_if_possible
}
chain connection_state {
# drop invalid connections
ct state invalid counter drop comment "dropped invalid"

# established/related connections
ct state established,related counter accept
}
chain accept_icmp {
# allow global icmp
icmp type $icmp_v4_types_global_ok accept
ip6 nexthdr icmpv6 icmpv6 type $icmp_v6_types_global_ok accept

# IPv6 ICMP routing stuff / local icmp
ip6 nexthdr icmpv6 icmpv6 type $icmp_v6_types_local_ok ip6 hoplimit 1 accept
ip6 nexthdr icmpv6 icmpv6 type $icmp_v6_types_local_ok ip6 hoplimit 255 counter accept
}
chain reject_if_possible {
counter reject with tcp reset comment "reject/tcp"
counter reject with icmpx type port-unreachable comment "reject/icmp unreachable"
counter comment "reject/drop"
}

}

table ip nat {
chain prerouting {
type nat hook prerouting priority 0; policy accept;
}
chain postrouting {
type nat hook postrouting priority 100; policy accept;
oifname $dmz_if masquerade
}
}
-v

Nagelt mich nicht auf die Details für IPv6 und ICMP fest, ich habe mir
das seinerzeit aus verschiedenen Anleitungen zusammengekramt, mich
soweit ich konnte aufgeschlaut und das ganze um „funktioniert auch
ohne diese Regel“ entschlackt. Das ist vermutlich einer
Revisionsabteilung nicht compliant genug, aber hier bei mir mache ich
die (Firewall-)Regeln ;-)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Nicht die Schere! NICHT DIE SCH... NO CARRIER

[Andreas Kohlbach]

On Mon, 12 Apr 2021 21:51:08 +0200 (CEST), Christian Garbs wrote:
>
> Marc Haber <mh+usene...@zugschl.us> wrote:
>
>>>1.4.6 Firewall auf dem Server
>>>-----------------------------
>>>
>>> Ist ein eigenes Kapitel :-) Gleichlautende Regeln für IPv4/IPv6 lassen
>>> sich ganz wunderbar über `nftables' erledigen, die Config ist viel
>>> einfacher und übersichtlicher als mit `iptables'.
>>
>> Das würde mich auch etwas detaillierter interessieren, ich hänge da
>> immer noch bei iptables über ferm fest (ein cooles Tool, leider auch
>> nur noch so barely alive).
>
> Ich hatte anderthalb Jahrzehnte lang ein wildes Shellskript mit >1000
> Zeilen, das anhand einer Konfigurationsdatei iptables-Regeln erzeugt
> hat (anfangs sogar noch ipchains). Das war zeitweise sogar auf
> drei(!) verschiedenen Rechnern im Einsatz. Totaler Overkill und wild
> gewachsen.
>
> IPv6 habe ich mich nie getraut, weil ich dann dieses Monster hätte
> komplett umschreiben müssen.
>
> Mit nftables ist die Firewall bei gleicher Funktionalität viel
> übersichtlicher als das Skript geworden.

Der Fall scheint ähnlich zu ip VS ifconfig und iw VS iwconfig zu
liegen. ip und iw sind lange verfügbar. Und vor einem Jahrzehnt las ich
schon, dass ifconfig und iwconfig "bald" obsolet sein werden. Ist nicht
wirklich (flächendeckend) passiert. So wie nftables seit 2014 verfügbar
IMO auch abstrakter als iptables ist, wie es ip und iw schon sind. Man
scheint aber an Bewährtem festhalten zu wollen, dass die alten Versionen
nicht "stillgelegt" werden.

Ich werde mal ipchains installieren. ;-)
--
Andreas

PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0

[Marc Haber]

Christian Garbs <mi...@cgarbs.de> wrote:
>Nachdem ich mit tcpdump herausgefunden hatte, dass die Fritz!Box immer
>ein /62 delegiert (das scheint nicht verhandel- oder konfigurierbar zu
>sein),

Ich könnte mir vorstellen, dass das auch vom ISP abhängt. Meine
Fritzbox gibt dem systemd-networkd (dazu schreibe ich später) ohne mit
der Wimper zu zucken ein /58, wenn man sie darum bittet.

Beim ISC dhclient muss man das mit --prefix-len-hint angeben UND es
darf keine Zuteilung eines kleineren Netzes bereits erfolgt sein. Man
muss die leases-Datei vom dhclient entfernen, damit es funktioniert.

[Marc Haber]

Christian Garbs <mi...@cgarbs.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:

>> Auch mit --prefix-len-hint 60 wird weiterhin ein /62 angefordert. Erst
>> als ich die Datei mit der Lease, /var/lib/dhcp/dhclient6.leases,
>> lösche, erfragt der dhclient ein /60 von der Fritzbox und bekommt das
>> auch.
>
>Das wollte ich jetzt auch mal ausprobieren – ich habe ja den
>wide-dhcpv6 genommen und bin mir unsicher, ob der sich auch von der
>alten /var/lib/dhcp/dhclient6.leases hat leiten lassen. Allerdings
>scheint der gar keinen Prefix Length Hint zu können. Die "Doku" gibt
>nichts weiteres her.
>
>(Es gibt nur eine kommentierte Beispieldatei, keine Manpage, kein
> Readme, keine Homepage, das Projekt lebt auf SourceForge (örks) und
> der letzte Commit ist von 2015. Was hab ich mir da angelacht?
> Immerhin funktioniert es… Ich glaube, ich freue mich auch drauf,
> dass systemd das bald in hoffentlich funktionierend in einem Tool
> vereint, statt wie jetzt mit wide-dhcpd (siehe Anfang des Absatzes),
> dem ISC DHCP-Client (Skriptingorgie) und radvd (zickig)
> herumzujonglieren. Oder muss ich mal NetworkManager ausprobieren,
> kann der das?)

Ich benutze auf meinen Servern schon seit Jahren systemd-networkd, das
tut, und kann in der Version 247, die in Debian bullseye verwendet
wird, selbst mit DHCPv6 und Prefix Delegation umgehen, ganz ohne
dedizierten DHCP-Client und ganz ohne radvd. Auf den
Arbeitsplatzrechnern habe ich network-manager, was aber daran liegt,
dass systemd-networkd eher statisch ist, es kein Frontend gibt und
auch Wifi nicht unterstützt wird. systemd-networkd ist was für Server,
und was man auf dem Server braucht, kann networkd gut und hat
inzwischen auch eine gewisse Reife.

Ich habe das auf einer Testmaschine implementiert, einen Prefixwechsel
habe ich noch nicht mitgemacht, und trotzdem zuckt es mir in den
Fingern, meinen Heimrouter noch vor dem Release auf bullseye
upzugraden um den neuen systemd-networkd zu bekommen.

[Christian Garbs]

Mahlzeit!

Christian Garbs <mi...@cgarbs.de> wrote:

> ich habe ja den
> wide-dhcpv6 genommen und bin mir unsicher, ob der sich auch von der
> alten /var/lib/dhcp/dhclient6.leases hat leiten lassen. Allerdings
> scheint der gar keinen Prefix Length Hint zu können. Die "Doku" gibt
> nichts weiteres her.
>

> (Es gibt nur eine kommentierte Beispieldatei, keine Manpage, …

"Keine Manpage" nehme ich zurück, ich habe falsch gesucht.
Die Manpage fängt nicht mit "w" an:

$ dpkg -L wide-dhcpv6-client | grep man.*z$
/usr/share/man/man5/dhcp6c.conf.5.gz
/usr/share/man/man8/dhcp6c.8.gz
/usr/share/man/man8/dhcp6ctl.8.gz

Da steht aber definitiv nichts von "hint" drinnen.
Auch strings(1) auf das Binary zeigt nichts mit "hint".

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Verdauung ist nicht etwa die zwanghafte Umfunktionierung normaler
Usenet-Benutzer zu Netzidioten.