예전에는 한 가지를 보여 주던 프롬프트가 이제 다른 것을 보여 주고, 바뀐 연결은 VPN이었습니다. Mac 이름이 바뀌었다고 결론 내리기 전에 대부분이 가진 증거는 이것뿐이며, 그것으로는 부족합니다. macOS는 적어도 세 개의 별도 이름 값을 저장하고 각각 하는 일이 다르며, 셸 프롬프트는 그중 최대 하나만 잘못 읽기 쉬운 방식으로 보여 줍니다.

값을 비교하는 데는 명령 세 개면 충분하고, 누군가 무언가를 편집하기 전에 문제가 정리됩니다.

값 세 개, 역할 세 가지

셋 다 시스템이 흔쾌히 보고할 문자열이고, 유혹은 처음 찾은 값을 권위 있는 것으로 여기는 것입니다. 그래서 사용자는 잘못된 필드를 «고치고» 증상이 살아남는 것을 지켜보게 됩니다.

ValueWhat it is responsible for
ComputerNameThe friendly name a person sees in About and on the network browser; this is the one users mean by "my Mac's name"
LocalHostNameThe Bonjour name used on the local link, usually shown with a .local suffix in Sharing
HostNameAn explicitly configured host name that may simply not be set at all

셋째 줄이 바로 대부분의 혼란이 시작되는 곳입니다. 설정되지 않은 HostName은 손상이 아니라 정상 상태이며, 호스트 이름이 필요할 때 시스템이 다른 출처로 물러난다는 뜻입니다. 이 빈자리를 손상으로 읽으면 애초에 필요하지 않았던 수정으로 이어집니다. 그것은 진짜 질문도 가립니다. 질문은 기계의 이름이 아니라, 그 시점에 특정 조회나 프롬프트가 어느 이름을 쓰고 있느냐이며, 그 답을 하면 빈 값은 더 이상 결함처럼 보이지 않습니다.

쓰기 전에 읽기

이 세 명령은 값을 보고할 뿐입니다. 아무것도 바꾸지 않으므로 조사 중에 실행해도 안전합니다.

scutil --get ComputerName
scutil --get LocalHostName
scutil --get HostName

허용된 VPN 연결 전후에 같은 로컬 세션에서 실행하고, 어떤 값이 실제로 다른지 적어 두십시오. 아무것도 다르지 않은데 프롬프트가 여전히 잘못 보인다면 이름은 애초에 문제가 아니며, 셸 설정이나 원격 세션 어딘가가 다른 문자열을 보여 주고 있습니다.

컴퓨터 이름과 로컬 호스트 이름에 관한 Apple 안내서는 친숙한 이름을 General과 About 아래에, 로컬 이름을 General과 Sharing 아래에 둡니다. 같은 링크의 다른 Mac이 이미 이름을 쓰고 있을 때 자동으로 붙는 접미사도 설명하는데, 예상치 못한 숫자를 변조의 증거로 보기 전에 알아 둘 만합니다.

셸 프롬프트가 실제로 증명하는 것

프롬프트는 셸이 만드는 문자열이며, 그 호스트 이름 요소는 확장된 호스트 이름, 그 축약형, 또는 프로필 파일에 하드코딩된 값에서 올 수 있습니다. 완전히 다른 기계의 SSH 세션에 속할 수도 있는데, 이것은 가장 덜 화려한 설명이면서 VPN을 연결한 순간 프롬프트가 바뀐 경우에 압도적으로 흔한 설명입니다.

무엇이라 불리는지 확인하기 전에 어디에 있는지 확인하십시오. hostname을 실행해 저장된 세 값과 비교하고, 다음으로 셸의 프롬프트 설정을 보고 호스트를 표시하는지 확인합니다. 프롬프트에 누군가 몇 년 전 설정 파일에 입력한 리터럴 문자열이 들어 있다면, 어떤 시스템 변경도 그것을 일치시키지 못합니다.

비교는 보고에도 중요합니다. 다르게 보이는 프롬프트와 실제로 바뀐 저장된 ComputerName은 소유자가 다른 두 가지 발견이며, 이를 한 문장으로 합치면 다음 엔지니어를 잘못된 곳으로 보냅니다.

VPN이 정당하게 이름 짓기에 관여할 수 있는 곳

VPN은 어떤 리졸버와 검색 도메인이 관련 있는지를 바꾸고, 클라이언트가 하나를 받도록 설정되어 있으면 DHCP를 통해 호스트 이름을 넘겨줄 수 있습니다. 그것은 실제 메커니즘이며 «VPN이 내 Mac 이름을 바꿨다»보다 좁은 이야기입니다. 리졸버가 특정 주소에 대해 어떤 이름이 확인되는지를 바꾸는 것은 저장된 로컬 값을 다시 쓰지 않습니다.

그러니 두 질문을 분리하십시오. 기계 자체의 정체성이 다른가, 아니면 다른 무언가에 도달하기 위해 쓰는 이름이 다른가? 전자는 저장된 세 값이 답하고, 후자는 DNS 조회와 사용 중인 연결 프로필이 답합니다. 둘을 같은 질문으로 다루면 이름 확인 문제에 대한 응답으로 정체성 설정을 바꾸게 됩니다.

영구적인 호스트 이름이 정말 필요하다면

값을 설정하는 것은 의도적인 관리 작업이지 미관상의 선호가 아니며, 값은 기계의 이름 짓기 정책을 가진 쪽에서 와야 합니다. 프롬프트가 익숙해 보이도록 관리되는 이름을 덮어쓰면 인증서 검사, 모니터링, 호스트를 식별하는 모든 것이 깨질 수 있습니다.

변경이 정말 필요한 곳에서는 값을 읽은 바로 그 도구가 값을 쓰며, HostName은 완전히 정규화된 이름을 받아들이고 나머지 둘은 로컬 형식을 기대합니다. 무엇을 왜 바꿨는지, 그리고 이것이 다음에 기계를 들여다보는 사람을 놀라게 하는 종류의 편집이라는 점을 기록하십시오.

대부분의 보고서에서 정답은 질문이 암시하는 것보다 작으며, 세 값을 모두 읽고 어느 것이 다른지 확인하고 그것만 고치면 됩니다. 프롬프트는 무언가의 증상이었고, 세 명령은 그것이 무엇의 증상인지 알려 줍니다.

관련 글