<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Hallo Robert,<br>
<br>
vielen Dank für die Tiefenbohrung, jetzt kann auch ich verstehen,
was da passiert ist.<br>
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.<br>
<br>
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...<br>
<br>
Für Mitleser, die eventuell auch mal ein bereits installiertes Linux
vervielfältigen wollen:<br>
<br>
rm -f /etc/machine-id<br>
dbus-uuidgen --ensure=/etc/machine-id<br>
rm -f /var/lib/dbus/machine-id<br>
dbus-uuidgen --ensure<br>
rm -f /etc/ssh/ssh_host_*<br>
dpkg-reconfigure openssh-server<br>
<br>
(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.)<br>
<br>
Viele Grüße,<br>
Miki<br>
<br>
<div class="moz-cite-prefix">Am 01.11.21 um 10:03 schrieb Robert
Langhammer:<br>
</div>
<blockquote type="cite"
cite="mid:877cd20f-89cb-6841-69a5-af55e6049d4d@web.de">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hallo Zusammen,</p>
<p>ich fand das auch spannend, da ich es erst nicht nachstellen
konnte. Mein systemd ist zu alt.</p>
<p>Ab 242 hat sich das geaendert:</p>
<p><a class="moz-txt-link-freetext"
href="https://github.com/systemd/systemd-stable/blob/5193b40cebe30e6297ba8d1e8cf888ab25cea2ae/NEWS#L3367"
moz-do-not-send="true">https://github.com/systemd/systemd-stable/blob/5193b40cebe30e6297ba8d1e8cf888ab25cea2ae/NEWS#L3367</a></p>
<p>Die mac wird aus der machine-id <br>
</p>
<p><a class="moz-txt-link-freetext"
href="https://manpages.debian.org/testing/manpages-de/machine-id.5.de.html"
moz-do-not-send="true">https://manpages.debian.org/testing/manpages-de/machine-id.5.de.html</a></p>
<p>und dem interface name gebildet. <br>
</p>
<p>Beim Clonen sollte man also darauf achten. Moechte man einen
echten Clone, dann nimmt man die machine-id mit, oder eben
nicht.</p>
<p>@miki: machine-id aendern ist die Loesung. s. manpage oben. <br>
</p>
<p>Viele Grüße<br>
Robert<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">Am 31.10.21 um 22:55 schrieb Miki:<br>
</div>
<blockquote type="cite"
cite="mid:951da729-a12b-a2b6-97fd-a256a09c8284@michelaweb.eu">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
Hallo Fabian,<br>
<br>
<blockquote type="cite"
cite="mid:9b1c053b-050f-f156-2496-3e6797ea2221@blaese.de">Die
Frage ist jetzt, warum das bei dir über mehrere Maschinen
hinweg identisch ist. <br>
Hast du die in irgendeiner Form geklont und sind
/etc/machine-id bzw. /var/lib/dbus/machine-id entsprechend
identisch? <br>
</blockquote>
<br>
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.<br>
<br>
Trotzdem hätte ich erwartet, dass zumindest bei einem <u><i>neu
erstellten</i></u> gleichnamigen Interface nicht die selbe
MAC Adresse raus kommt, egal was vorher war.<br>
<br>
(Es läuft jetzt wieder, aber eben nachdem ich alles umbenannt
habe.)<br>
<br>
Viele Grüße,<br>
Miki<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">Am 31.10.21 um 22:36 schrieb Fabian
Bläse:<br>
</div>
<blockquote type="cite"
cite="mid:9b1c053b-050f-f156-2496-3e6797ea2221@blaese.de">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]. <br>
<br>
Die Frage ist jetzt, warum das bei dir über mehrere Maschinen
hinweg identisch ist. <br>
Hast du die in irgendeiner Form geklont und sind
/etc/machine-id bzw. /var/lib/dbus/machine-id entsprechend
identisch? <br>
<br>
Gruß <br>
Fabian <br>
<br>
[1] <a class="moz-txt-link-freetext"
href="https://www.freedesktop.org/software/systemd/man/systemd.link.html#MACAddressPolicy="
moz-do-not-send="true">https://www.freedesktop.org/software/systemd/man/systemd.link.html#MACAddressPolicy=</a><br>
[2] Hier bin ich mir nicht ganz sicher und hab grade keine
ordentliche Quelle dafür gefunden <br>
<br>
On 31.10.21 21:52, Miki wrote: <br>
<blockquote type="cite">Hallo, <br>
<br>
jetzt habe ich der Ordnung und Symmetrie halber auch Rohan
an die neuen <br>
Namen angepasst: <br>
<br>
=> und jetzt sind die MAC-Adressen überall dort gleich,
wo die <br>
Interface-Namen gleich sind!!!! <br>
<br>
Und ja, beide Interfaces habe ich unabhängig voneinander
erstmalig <br>
manuell neu angelegt. Gerade eben, also viele Tage nach dem
Klonen des <br>
Images. Demnach scheint die Option 3 "set using
dev_set_mac_address" zur <br>
Erzeugung der MAC-Adresse nur Daten zu verwenden, die beim <br>
ursprünglichen Aufsetzen des Betriebssystems entstehen, und
den <br>
Interface-Namen. Für eine generisch zu erzeugende zufällige
Adresse <br>
finde ich das sehr wenig Entropie, zumindest die aktuelle
Uhrzeit oder <br>
ähnliches einzuarbeiten hätte ich jetzt doch erwartet. :-( <br>
<br>
Viele Grüße, <br>
Miki <br>
<br>
Am 31.10.21 um 18:55 schrieb Miki: <br>
<blockquote type="cite">Hallo, <br>
<br>
mein Betriebssystem (sollte eigentlich ein normales Debian
11 sein) <br>
verhält sich anders als erwartet. <br>
<br>
Zitat Roland: "Das System speichert die mac von virtuellen
Devices <br>
nicht. Die werden bei jedem Up des Interfaces neu
gewürfelt. Da sollte <br>
auch z.B. in
/sys/class/net/<interface>/addr_assign_type eine 1
drin <br>
stehen." <br>
<br>
Bei mir steht jeweils eine "3" drin. Zitat aus Manual:
"Indicates the <br>
address assignment type. Possible values are: <br>
0 permanent address <br>
1 randomly generated <br>
2 stolen from another device <br>
3 set using dev_set_mac_address" <br>
<br>
Workaround: Ich habe alle Batman-Interfaces und alle
FastD-Interfaces <br>
umbenannt. Neue Namen => neue MAC-Adressen. <br>
<br>
Danke Fabian, Roland und allen Lesern! Diese "Lösung"
behebt jetzt <br>
leider nicht die Ursache, sondern war eher die
Fleißkärtchen-Methode. <br>
Aber mit verdoppelten MAC-Adressen kann ich nicht stunden-
oder tagelang <br>
beide Gateways gleichzeitig online lassen. <br>
<br>
Viele Grüße, <br>
Miki <br>
<br>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>