mac
Man ahnt förmlich, wie PC-Hardware entworfen und hergestellt wird:
einfach Scheiße durch's Sieb drücken und Intel inside drüber hauchen
-- lässt sich garantiert verkaufen ...
- lars@elbe.desy.de
16.6.2024
Das ist schon bemerkenswert: bei meinem VPN Tunnel zum nach Hause telefonieren hatte ich von Anfang an das Problem, das irgendwie das Routing nicht so wollte wie ich dachte, das es zu funktionieren hätte. Der Tunnel wurde aufgebaut, alles sauber, nur Pakete wollten nicht durch den Tunnel fliessen.
Letztendlich habe ich mir dann lange Jahre so geholfen, das ich per "sudo route add x.y.z.0/16 a.b.c.d" eine Route gesetzt habe und alles funktionierte dann so, wie es sollte. Aber wie sollte damit ein "normaler" Benutzer klarkommen ? Es musste einfacher gehen.
Nach langem Probieren und Suchen bin ich dann drauf gekommen, die "Reihenfolge" der Dienste (das Icon unten mit dem Kreis und den drei Punkten drinnen) so zu ändern, das der VPN Tunnel oberhalb der (W)LAN Verbindungen steht - und siehe, es funktioniert ohne "sudo route . . .".
Meine Bemühungen Doku zu diesem Thema zu finden: ohne Ergebnis bis jetzt.
1.6.2024
Vor einigen Monaten hab' ich meinen Musik-Mac auf ein neues Mac OS upgegradet, lief alles soweit. Nur - iTunes war nicht mehr da! Bis ich geschnallt habe, das jetzt "Music" übernommen hatte und es kein iTunes mehr gab, dauerte es ein wenig. Nach dem erstmaligen Aufruf dauerte es etwas und dann war alles wieder da. Alles ? Nein, viel mehr als vorher. Doppelte Platten, in den Platten doppelte oder drei- oder vierfache Anzahl der Stücke. Im Filesystem sah das noch schlimmer aus. Es gab keine 1:1 Beziehung zwischen Musik und Filesystem mehr. Obwohl ich in Music Stücke sah, waren sie im Filesystem nicht da. Generve hoch drei.
Wie gut, das es Backups der alten Maschine gab. Ich habe dann verschiedene Strategien ausprobiert, um der Unordnung wieder Herr zu werden. Im Internet gesucht, es gibt viele Leute, die ähnliche oder größere Probleme haben. Mein größtes Problem ist die schiere Menge: 220 GByte, knapp 18.000 Stücke, 52 Tage Musik. Es ist nun so, das ich diese Situation irgendwie kommen sah: angefangen mit iTunes auf dem ersten Mac auf einem Mac OS Extended Filesystem, da rein habe ich alle meine LP's digitalisiert und importiert. Die Musik Library wanderte dann über mehrere Mac's mit, bis ich mich entschloß, sie auf ein NFS gemountetes Filesystem zu legen. Das gab im Laufe der Jahre jede Menge Probleme, das Mac OS Extended Filesystem hat Strukturen, um Metadaten zu speichern, die u.a. von iTunes genutzt wurden - das gibts bei NFS Mounts nicht, so das diese Metadaten in speziellen Files im Filesystem gespeichert werden. Je komplexer desto fehleranfälliger. Ein paar Jahre später dachte ich, das man die Library ja auch auf ein AFP gemountetes Filesystem speichern könnte, da müsste es besser gehen. Gesagt getan. Aber ich denke, das da schon zu viel kaputt war und wenn so ein NAS mal abstürzt und wild läuft, passiert ein Übriges. Also, wieder auf eine SSD kopiert, auf der ein APFS läuft, UND an einem völlig anderen Ort (das das ein Problem werden würde, hätte ich nicht gedacht . . ) - nein, das man seine Musik mal wo anders haben möchte, daran hatte Apple nun gar nicht gedacht, echte Scheisse. Ich hatte nun schon fast ein halbes Jahr keine Musik mehr und mir wurde langsam traurig.
Letzte Woche war es dann so weit, ich entdeckte ein "Tuul", das in solchen Situationen helfen sollte: TuneSweeper. Die einen priesen das wie geschnitten Brot an, die anderen fanden das Ding zum Kotzen, der Demo Modus war auch wenig hilfreich. Also 30 Euronen investiert und selbst getestet: nach dem Start brauchte das Ding gut einen Tag, um meine Library mit ihm bekannt zu machen. Mit dem Mut der Verzweiflung (und vielen guten Backups) klickte ich auf "Duplikate entfernen" und wartete, was nun passieren würde: nichts. Das Ding lief mehr als anderthalb Tage durch, ehe es fertig wurde damit. Danach sah ich mir meine Music Library an und dann das Filesystem und entschied, das es automatisiert kaum besser werden würde. Ich schätze, Tunesweeper hatte ca. 70-75% der Arbeit durchgeführt und das Ganze sah wesentlich aufgeräumter aus. Anschliessend bin ich mehrmals händisch durch die Library durch: alle Dubletten löschen, alle Konflikte hervorgerufen durch den iTunes Store aufgelöst, alle fälschlich gelöschen Stücke bzw. Platten wieder zugreifbar gemacht und eingeordnet, alles Verschwundene aus den Backups restauriert, alle nicht mehr vorhandene Bilder der Plattencover wieder gesucht und eingefügt und zuletzt alle iTunes Käufe wieder tatsächlich ins Filesystem geladen.
Dann zwei verifizierte Backups, schreibschützen und ab in den Safe. Nie wieder.
7.1.2024
Signal beschwerte sich als erster über ein nicht mehr supportetes Betriebssystem, dann folgte Teamviewer und dann andere . . . Es war Zeit, sich von seiner gewohnten Umgebung zu verabschieden und mac OS upzugraden. Ich weiss genau, welchen Ärger und Generve solche Aktionen mit sich bringen, deshalb habe ich erstmal ein paar Backups gemacht und dann noch eine VM mit dem aktuellen Stand erstellt. Für alle Fälle.
Wider Erwarten ging es eigentlich ganz gut mit der Umstellung auf Monterey. Zumindest kann ich arbeiten und die Dezember Buchhaltung ist auch erledigt. Alles scheint soweit zu laufen mit den folgenden Ausnahmen:
- Musik ist da und iTunes ist weg. In der Oberfläche von Musik fehlen auch alle Platten/CD's, die als MP3 den Weg ins iTunes gefunden haben. Warum das so ist habe ich noch nicht rausgefunden, das wird schon noch.
- Mein geliebter TotalSpaces 2 Windowmanger läuft nicht mehr, weil Apple das Betriebssystem immer mehr dichtgerammelt hat (SIP). Für aktuelle mac OS'se gibt es eine beta-Version TotalSpaces 3, die ganz ordentlich auf meinem letzten x86 Mac Mini läuft. Einiges ist anders und man merkt den beta Status - aber das Ding ist benutzbar.
- Totalspaces 2 konnte man aufrufen, indem man die aktiven Ecken für Mission Control benutzt hat - das geht nicht (mehr ?). Dafür habe ich BetterTouchTool entdeckt, mit dem man wirklich allen möglichen Triggern (hier: Maus wird in die obere rechte Ecke geschoben) alle möglichen Aktionen zuordnen kann. Ein Wahnsinnstool.
Unter Ventura und Sonoma gibt es offenbar Probleme mit dem GPG Plugin für Mail und TotalSpaces soll dort auch spinnen, also lass' ich das lieber erstmal.
27.12.2023
Macs haben immer schon mal die Prozessoren gewechselt, 68K, MIPS, 80x86 und nun ARM. Ich benutze hier die letzen x86 in Notebook und stationär weil es für mich essentiell ist, alle möglichen x86er Betriebssysteme (Windows, Linux, xBSD etc) an Bord zu haben, hier via VMware Fusion. Sehr zufrieden damit. Nur gibt es keine neuen x86er Macs mehr zu kaufen. Auf einem ARM Mac kann kein x86er OS via VMware emuliert werden.
Jetzt bin ich auf UTM gestossen ( siehe: https://mac.getutm.app/ ) offenbar ein QEMU Fork nur für Apple. Das Ding virtualisiert nicht nur, es emuliert auch. Wie gut und genau die Emulation ist, gilt es zu untersuchen.
5.1.2022
Erstellen von ISO Files aus den Apple Mac OS Installations dmg's bzw app's: Der Prozess via command line wird hier "Startfähiges Installationsprogramm für macOS erstellen" kurz und knapp erklärt und durchgespielt. Und anschliessend konvertieren eines Mac OS Installations-ISO Files in ein USB Stick Image:
hdiutil convert -format UDRW -o USB-Stick-Image.img CD-oder-DVD-ISO-Image.iso
Schliesslich per dd oder mit soetwas wie balenaEtcher auf den USB Stick kopieren.
IPv6 DHCP - oder die Suche nach der DUID (Juni 2014)
Zur Konfiguration eines Mac's per DHCPv6 benötigt man auf der Server-Seite die DUID dieses MAC's. (siehe unten ...)
Es gibt mehrere Möglichkeiten, an diese DUID zu kommen:
Möglichkeit 1:
Im Terminal auf dem Mac ausführen:
ipconfig getv6packet en0
und man findet (nach einer erfolgreichen Transaktion mit einem DHCPv6 Server) im Output eine Zeile wie diese (Ethernet Mac Adressen geändert):
CLIENTID (1) Length 14 DUID LLT HW 1 Time 455105088 Addr 00:25:4b:xx:yy:zz
Dort ist die DUID schon vorhanden ("Time 455105088 Addr 00:25:4b:xx:yy:zz") aber noch nicht nutzbar (siehe unten).
Möglichkeit 2:
Aufruf von:
tcpdump -lvi <interface-name> ip6 or icmp6
und den DHCPv6 Handshake aufzeichnen. Dort fird man dan ähnliches wie dieses finden:
12:42:37.318870 IP6 (flowlabel 0x91d82, hlim 1, next-header UDP (17) payload length: 106) fe80::225:nnnn:oooo:pppp.dhcpv6-client > ff02::1:2.dhcpv6-server:
[udp sum ok] dhcp6 request (xid=a869cc (client-ID hwaddr/time type 1 time 455105088 00254bxxyyzz) (option-request DNS-server DNS-search-list) (elapsed-time 0)
(server-ID hwaddr/time type 1 time 418558931 001b21aabbcc) (IA_NA IAID:0 T1:0 T2:0 (IA_ADDR 2001:uuuu:vvvv:wwww::1234 pltime:0 vltime:0)))
Auch dort kann man die DUID schon sehen ("time 455105088 00254bxxyyzz").
Möglichkeit 3:
Man benutze wireshark um sich die DHCPv6 Transaktion anzuschauen, dort findet man dann in den DHCPv6 Paketen unter "Client Identifier":
[....]
DUID: 00:01:00:01:1b:20:5a:40:00:25:4b:xx:yy:zz
DUID Type: link-layer address plus time (1)
Hardware type: Ethernet (1)
[....]
Der Wert hinter "DUID:" ist direkt in der isc-dhcpv6 Konfigurationsdatei benutzbar.
Was bedeuten nun die Werte aus Möglichkeit 1 und 2 ?
Laut RFC3315 setzt sich die DUID zusammen aus:
9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT] This type of DUID consists of a two octet type field containing the value 1, a two octet hardware type code, four octets containing a time value, followed by link-layer address of any one network interface that is connected to the DHCP device at the time that the DUID is generated. The time value is the time that the DUID is generated represented in seconds since midnight (UTC), January 1, 2000, modulo 2^32. The hardware type MUST be a valid hardware type assigned by the IANA as described in RFC 826 [14]. Both the time and the hardware type are stored in network byte order. The link-layer address is stored in canonical form, as described in RFC 2464 [2]. The following diagram illustrates the format of a DUID-LLT: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | hardware type (16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . link-layer address (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Das heisst also in diesem Fall (00:01:00:01:1b:20:5a:40:00:25:4b:xx:yy:zz):
00:01 = DUID Type (DUID-LLT)
00:01 = Hardware Type nach RFC826 (Type 1 = Ethernet)
1b:20:5a:40 = Zeitstempel, oben in 1 und 2 jeweils dezimal 455105088, ergibt hexadezimal 1b 20 5a 40 und
00:25:4b:xx:yy:zz = die mac Adresse des Client Interfaces
Fertig!
Die Zeile in der isc-dhcpv6 Konfigurationsdatei sieht dann folgendermassen aus:
host-identifier option dhcp6.client-id 00:01:00:01:1b:20:5a:40:00:25:4b:xx:yy:zz;
... und der Client bekommt "seine" v6 Adresse.
Samhain host-based intrusion detection system (Januar 2014)
Auf der Suche nach einer Software zur Intrusion Detection bin ich auf Samhain gestossen und wollte das mal ausprobieren. Unter Mac OS 10.8 und 10.9 gibt es aber offenbar Probleme mit dem in Xcode enthaltenen Compiler, das Kompilieren der Datei sh_tiger1_64.c triggert offenbar einen Bug im llvm/clang Backend: "ran out of registers during register allocation".
Nach einigem Suchen kam ich auf den Workaround, das man das gute Stück dadurch kompiliert bekommt, das man aus der "configure"-generierten Datei config_xor.h die Zeile "#define TIGER_OPT_ASM 1" auskommentiert.
IPv6 DHCP mit MAC OS X 10.8.5 als Client (September 2013)
Um einen MAC per DHCPv6 mit einer oder mehreren IPv6 Adresse(n) zu betanken benötigt man auf der Server-Seite die DUID dieses MAC's.
Diese - von OS X vergebene DUID - findet man in der Datei /private/var/db/dhcpclient/DUID_IA.plist
Vorsicht: beim Restore eines Image-Backups auf einen anderen Mac wandert diese Datei mit! Einfach löschen, dann wird automatisch eine neue DUID erstellt. Der gesamte Client Mechanismus unter MAC OS ist wenig dokumentiert, allerdings funktioniert das ganz hervorrangend und zuverlässig. Demnächst hier mehr zu diesem Thema.
PS: Solle man mal in die Verlegenheit kommen, sich eine DUID selbst generieren zu müssen, gibt es hier ein perl-script dafür.
WLAN Diagnose unter MAC OS X 10.8.4 (Juli 2013)
[ Update 01/2014: Das funktioniert genauso unter OS X 10.9.1 Maverics. ]
MAC OS besitzt eine eingebaute WLAN Diagnosemöglichkeit in Mountain Lion. Für diese Zwecke habe ich bisher immer KisMAC benutzt, aber die letzte Version ist von 2011 und ich habe den EIndruck, das das nicht so richtig läuft unter ML.
Für die eingebauten Diagnose Tools gibt es offenbar je nach OS Version unterschiedliche Wege, um die Tools aufzurufen, für 10.8.4 funktionierten diese Wege nicht und deshalb hab' ich's hier einmal dokumentiert:
1. Bei gedrückter ALT/Option Taste das WLAN Symbol in der Statusleiste anklicken
Jetzt gibt's schon eine Menge mehr Informationen als ohne ALT zu klicken ! Unten ist der Auswahlpunkt "Diagnose für drahtlose Umgebungen öffnen ..." - dort bitte klicken.
2. Anschliessend muss man sich einmal als Administrator durch Passworteingabe authorisieren und weiter gehts danach hiermit:
3. Oben links in der Statuszeile erscheint jetzt "Diagnose für drahtlose Umgebungen" - hier jetzt bei "Fenster -> Dienstprogramme" klicken:
4. ... und schon ist man im Startfenster der WLAN Diagnose:
Im oberen Teil sind die weiteren Wahlmöglichkeiten des Diagnoseprogramms erreichbar: Informationen, Netzverkehr aufzeichnen, Protokollieren WLAN Suche und Leistung. Das "Informationen" Fenster haben wir schon oben gesehen, hier kommen noch Beispiele für das Fenster "WLAN Suche":
und "Leistung":
