Danke: Ganz schriller Effekt...

Miki salzmagazin at michelaweb.eu
Mo Nov 1 12:46:41 CET 2021


Hallo Robert,

vielen Dank für die Tiefenbohrung, jetzt kann auch ich verstehen, was da
passiert ist.
Das neue Verhalten ist also kein Bug, sondern ein Feature. Mit den
geänderten ID's geht es jetzt auch bei gleichen Interface-Namen wieder.

Es war der erste Clone meines Lebens, wo ich den Ursprungsrechner noch
weiter betreibe. Bisher waren meine Restores immer auf den selben
Rechner oder einen Ersatzrechner. Sonst wäre ich vielleicht selber auf
die Idee gekommen, dass irgendwo auch wichtige Identifier dupliziert
werden...

Für Mitleser, die eventuell auch mal ein bereits installiertes Linux
vervielfältigen wollen:

rm -f /etc/machine-id
dbus-uuidgen --ensure=/etc/machine-id
rm -f /var/lib/dbus/machine-id
dbus-uuidgen --ensure
rm -f /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server

(Die letzten beiden Zeilen sorgen für neue SSH-Keys. Hostname und
IP-Adresse(n) des Rechners müssen natürlich auch angepasst werden, wenn
das nicht das Rechenzentrum automatisch macht.)

Viele Grüße,
Miki

Am 01.11.21 um 10:03 schrieb Robert Langhammer:
>
> Hallo Zusammen,
>
> ich fand das auch spannend, da ich es erst nicht nachstellen konnte.
> Mein systemd ist zu alt.
>
> Ab 242 hat sich das geaendert:
>
> https://github.com/systemd/systemd-stable/blob/5193b40cebe30e6297ba8d1e8cf888ab25cea2ae/NEWS#L3367
>
> Die mac wird aus der machine-id
>
> https://manpages.debian.org/testing/manpages-de/machine-id.5.de.html
>
> und dem interface name gebildet.
>
> Beim Clonen sollte man also darauf achten. Moechte man einen echten
> Clone, dann nimmt man die machine-id mit, oder eben nicht.
>
> @miki: machine-id aendern ist die Loesung. s. manpage oben.
>
> Viele Grüße
> Robert
>
>
> Am 31.10.21 um 22:55 schrieb Miki:
>> Hallo Fabian,
>>
>>> Die Frage ist jetzt, warum das bei dir über mehrere Maschinen hinweg
>>> identisch ist.
>>> Hast du die in irgendeiner Form geklont und sind /etc/machine-id
>>> bzw. /var/lib/dbus/machine-id entsprechend identisch?
>>
>> Ja, die zweite Maschine ist von der ersten geklont, und danach hatte
>> ich alle Unterschiede (also secret keys, ggf. Hoodnamen) geändert.
>> Entsprechend sind auch die beiden von dir erwähnten IDs identisch.
>> Eigentlich sollte alles identisch sein, außer was Hetzner im Rahmen
>> ihres "cloud-init" scriptes beim Klonen ändern. Zum Beispiel eth0 und
>> das Root-Passwort wurden geändert.
>>
>> Trotzdem hätte ich erwartet, dass zumindest bei einem _/neu
>> erstellten/_ gleichnamigen Interface nicht die selbe MAC Adresse raus
>> kommt, egal was vorher war.
>>
>> (Es läuft jetzt wieder, aber eben nachdem ich alles umbenannt habe.)
>>
>> Viele Grüße,
>> Miki
>>
>>
>>
>> Am 31.10.21 um 22:36 schrieb Fabian Bläse:
>>> Tatsächlich bleiben die Adressen auch bei mir über Reboots
>>> identisch. udevd kann über reboots hinweg persistente MAC Adressen
>>> pro Device und Maschine erzeugen [1], was an sich erstmal gar keine
>>> so blöde Idee ist. Bisher hat dies wohl für batman und tuntap
>>> Interfaces nicht funktioniert, weil diese das ID_NET_NAME Attribut
>>> nicht gesetzt hatten [2].
>>>
>>> Die Frage ist jetzt, warum das bei dir über mehrere Maschinen hinweg
>>> identisch ist.
>>> Hast du die in irgendeiner Form geklont und sind /etc/machine-id
>>> bzw. /var/lib/dbus/machine-id entsprechend identisch?
>>>
>>> Gruß
>>> Fabian
>>>
>>> [1]
>>> https://www.freedesktop.org/software/systemd/man/systemd.link.html#MACAddressPolicy=
>>> [2] Hier bin ich mir nicht ganz sicher und hab grade keine
>>> ordentliche Quelle dafür gefunden
>>>
>>> On 31.10.21 21:52, Miki wrote:
>>>> Hallo,
>>>>
>>>> jetzt habe ich der Ordnung und Symmetrie halber auch Rohan an die
>>>> neuen
>>>> Namen angepasst:
>>>>
>>>> => und jetzt sind die MAC-Adressen überall dort gleich, wo die
>>>> Interface-Namen gleich sind!!!!
>>>>
>>>> Und ja, beide Interfaces habe ich unabhängig voneinander erstmalig
>>>> manuell neu angelegt. Gerade eben, also viele Tage nach dem Klonen des
>>>> Images. Demnach scheint die Option 3 "set using
>>>> dev_set_mac_address" zur
>>>> Erzeugung der MAC-Adresse nur Daten zu verwenden, die beim
>>>> ursprünglichen Aufsetzen des Betriebssystems entstehen, und den
>>>> Interface-Namen. Für eine generisch zu erzeugende zufällige Adresse
>>>> finde ich das sehr wenig Entropie, zumindest die aktuelle Uhrzeit oder
>>>> ähnliches einzuarbeiten hätte ich jetzt doch erwartet. :-(
>>>>
>>>> Viele Grüße,
>>>> Miki
>>>>
>>>> Am 31.10.21 um 18:55 schrieb Miki:
>>>>> Hallo,
>>>>>
>>>>> mein Betriebssystem (sollte eigentlich ein normales Debian 11 sein)
>>>>> verhält sich anders als erwartet.
>>>>>
>>>>> Zitat Roland: "Das System speichert die mac von virtuellen Devices
>>>>> nicht. Die werden bei jedem Up des Interfaces neu gewürfelt. Da
>>>>> sollte
>>>>> auch z.B. in /sys/class/net/<interface>/addr_assign_type eine 1 drin
>>>>> stehen."
>>>>>
>>>>> Bei mir steht jeweils eine "3" drin. Zitat aus Manual: "Indicates the
>>>>> address assignment type. Possible values are:
>>>>> 0 permanent address
>>>>> 1 randomly generated
>>>>> 2 stolen from another device
>>>>> 3 set using dev_set_mac_address"
>>>>>
>>>>> Workaround: Ich habe alle Batman-Interfaces und alle FastD-Interfaces
>>>>> umbenannt. Neue Namen => neue MAC-Adressen.
>>>>>
>>>>> Danke Fabian, Roland und allen Lesern! Diese "Lösung" behebt jetzt
>>>>> leider nicht die Ursache, sondern war eher die Fleißkärtchen-Methode.
>>>>> Aber mit verdoppelten MAC-Adressen kann ich nicht stunden- oder
>>>>> tagelang
>>>>> beide Gateways gleichzeitig online lassen.
>>>>>
>>>>> Viele Grüße,
>>>>> Miki
>>>>>
>>>>
>>

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://lists.freifunk.net/pipermail/franken-freifunk.net/attachments/20211101/6431f249/attachment-0001.htm>


Mehr Informationen über die Mailingliste franken