Omdøbte VPN'en din Mac? Sammenlign tre værtsnavnværdier
En ændret Terminal-prompt er ikke en omdøbning. ComputerName, LocalHostName og HostName holder forskellige værdier, og en af dem er ofte ganske enkelt ikke sat.
Prompten, der før viste én ting, viser nu noget andet, og forbindelsen, der ændrede sig, var en VPN. Det er hele det bevis, de fleste har, før de konkluderer, at Mac'en blev omdøbt, og det er ikke nok. macOS gemmer mindst tre separate navneværdier, hver med en forskellig opgave, og en shell-prompt viser højst én af dem på en måde, der let kan læses forkert.
At sammenligne dem kræver tre kommandoer og afgør spørgsmålet, før nogen redigerer noget.
Tre værdier, tre opgaver
Alle tre er strenge, som systemet gerne rapporterer, og fristelsen er at betragte den første, du finder, som autoritativ. Sådan ender en bruger med at „rette“ det forkerte felt og se symptomet overleve.
| Value | What it is responsible for |
|---|---|
ComputerName | The friendly name a person sees in About and on the network browser; this is the one users mean by "my Mac's name" |
LocalHostName | The Bonjour name used on the local link, usually shown with a .local suffix in Sharing |
HostName | An explicitly configured host name that may simply not be set at all |
Den tredje række er, hvor det meste forvirring begynder. En ikke-sat HostName er en normal tilstand, ikke korruption, og det betyder, at systemet falder tilbage på andre kilder, når det har brug for et værtsnavn. At læse den tomhed som skade fører til en rettelse, der aldrig var nødvendig. Det skjuler også det egentlige spørgsmål, som ikke er, hvad maskinen hedder, men hvilket navn et givet opslag eller en prompt bruger i det øjeblik. Svar på det, og den tomme værdi holder op med at se ud som en fejl.
Læs, før du skriver
Disse tre kommandoer rapporterer kun værdier. De ændrer intet, hvilket gør dem sikre at køre under en undersøgelse.
scutil --get ComputerName
scutil --get LocalHostName
scutil --get HostName
Kør dem i samme lokale session før og efter en tilladt VPN-forbindelse, og noter, hvilken værdi der faktisk afviger. Hvis intet afviger, og prompten stadig ser forkert ud, var navnet aldrig problemet: noget i shell-konfigurationen eller i fjernsessionen viser en anden streng.
Apples vejledning til computernavne og lokale værtsnavne placerer det venlige navn under General og About og det lokale navn under General og Sharing. Den dokumenterer også det automatiske suffiks, der tilføjes, når en anden Mac på samme link allerede bruger et navn, hvilket er værd at vide, før du tager et uventet tal som bevis på manipulation.
Hvad en shell-prompt egentlig beviser
En prompt er en streng, som shellen bygger, og dens værtsnavneelement kan komme fra det udvidede værtsnavn, en forkortet form af det eller en værdi, der er hardcodet i en profilfil. Den kan også tilhøre en SSH-session på en helt anden maskine, hvilket er den mindst glamourøse forklaring og langt den mest almindelige på en prompt, der ændrede sig i det øjeblik, du tilsluttede en VPN.
Kontroller, hvor du er, før du kontrollerer, hvad du hedder. Kør hostname og sammenlign det med de tre gemte værdier, og se derefter på shellens promptindstilling for at se, om den overhovedet viser værten. Hvis prompten indeholder en bogstavelig streng, som nogen skrev i en konfigurationsfil for år tilbage, vil ingen systemændring nogensinde få den til at passe.
Sammenligningen er også vigtig for rapporteringen. En prompt, der ser anderledes ud, og et gemt ComputerName, der reelt ændrede sig, er to fund med to forskellige ejere, og at slå dem sammen i én sætning sender den næste ingeniør det forkerte sted hen.
Hvor en VPN lovligt kan røre ved navngivning
En VPN ændrer, hvilke resolvere og søgedomæner der er relevante, og den kan give klienten et værtsnavn via DHCP, hvis klienten er konfigureret til at acceptere et. Det er en reel mekanisme, og den er også snævrere end „VPN'en omdøbte min Mac“. At en resolver ændrer, hvilket navn der opløses for en given adresse, omskriver ikke de gemte lokale værdier.
Så adskil to spørgsmål. Er maskinens egen identitet anderledes, eller er det navn, den bruger for at nå noget andet, anderledes? Det første besvares af de tre gemte værdier; det andet besvares af DNS-opslag og af den anvendte forbindelsesprofil. At behandle dem som samme spørgsmål fører til ændringer i identitetsindstillinger som svar på et navneopløsningsproblem.
Hvis et permanent værtsnavn virkelig er påkrævet
At sætte en værdi er en bevidst administrativ handling, ikke en kosmetisk præference, og værdien bør komme fra den, der ejer maskinens navngivningspolitik. At overskrive et administreret navn, så prompten ser velkendt ud, kan ødelægge certifikatkontroller, overvågning og alt andet, der identificerer værten.
Hvor ændringen virkelig er påkrævet, skriver det samme værktøj, der læste værdierne, dem, og HostName accepterer et fuldt kvalificeret navn, mens de to andre forventer de lokale former. Noter, hvad du ændrede og hvorfor, for det er netop den slags redigering, der overrasker den næste, der kigger på maskinen.
For de fleste rapporter er det korrekte svar mindre, end spørgsmålet antyder: læs alle tre værdier, find ud af, hvilken der afviger, og ret kun den. Prompten var et symptom på noget, og de tre kommandoer fortæller dig hvilket.