VPN-მა თქვენი Mac-ის სახელი შეცვალა? შეადარეთ ჰოსტის სახელის სამი მნიშვნელობა
შეცვლილი Terminal-ის მოთხოვნა სახელის შეცვლა არ არის. ComputerName, LocalHostName და HostName სხვადასხვა მნიშვნელობას ინახავს და ერთი მათგანი ხშირად უბრალოდ დაყენებული არ არის.
მოთხოვნა, რომელიც ადრე ერთ რამეს აჩვენებდა, ახლა სხვას აჩვენებს, და კავშირი, რომელიც შეიცვალა, VPN იყო. ეს არის მთელი ის მტკიცებულება, რაც უმეტესობას აქვს სანამ დაასკვნის, რომ Mac-ს სახელი შეეცვალა, და ეს არ არის საკმარისი. macOS ინახავს სულ მცირე სამ ცალკეულ სახელის მნიშვნელობას, თითოეულს განსხვავებული დანიშნულება აქვს, და shell-ის მოთხოვნა აჩვენებს მათგან მაქსიმუმ ერთს იმგვარად, რომ შეცდომით წაკითხვა ადვილია.
მათი შედარება სამ ბრძანებას მოითხოვს და კითხვას წყვეტს სანამ ვინმე რამეს შეცვლის.
სამი მნიშვნელობა, სამი დანიშნულება
სამივე ისეთი სტრიქონია, რომელსაც სისტემა სიამოვნებით შეატყობინებს, და ცდუნება ის არის, რომ პირველივე ნაპოვნი ავტორიტეტულად ჩათვალოთ. ასე მთავრდება მომხმარებელი არასწორი ველის „შესწორებით“ და სიმპტომის გადარჩენის ყურებით.
| 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 |
მესამე სტრიქონია ის ადგილი, სადაც არეულობის უმეტესობა იწყება. დაუყენებელი HostName ნორმალური მდგომარეობაა და არა დაზიანება, და ეს ნიშნავს, რომ სისტემა სხვა წყაროებს მიმართავს, როცა ჰოსტის სახელი სჭირდება. ამ სიცარიელის დაზიანებად წაკითხვა იწვევს შესწორებას, რომელიც არასოდეს ყოფილა საჭირო. ის ასევე მალავს ნამდვილ კითხვას, რომელიც არ არის ის, რა ჰქვია მანქანას, არამედ ის, რომელ სახელს იყენებს მოცემული ძებნა ან მოთხოვნა იმ მომენტში. უპასუხეთ ამას და ცარიელი მნიშვნელობა შეწყვეტს ხარვეზად ჩვენებას.
წაიკითხეთ სანამ დაწერთ
ეს სამი ბრძანება მხოლოდ მნიშვნელობებს აცხადებს. ისინი არაფერს ცვლიან, რაც მათ გამოძიების დროს გაშვებას უსაფრთხოს ხდის.
scutil --get ComputerName
scutil --get LocalHostName
scutil --get HostNameგაუშვით ისინი იმავე ლოკალურ სესიაში ნებადართული VPN კავშირის წინ და შემდეგ, და დააფიქსირეთ რომელი მნიშვნელობა განსხვავდება რეალურად. თუ არაფერი არ განსხვავდება და მოთხოვნა მაინც არასწორად გამოიყურება, სახელი არასოდეს ყოფილა პრობლემა: რაღაც shell-ის კონფიგურაციაში ან დისტანციურ სესიაში სხვა სტრიქონს აჩვენებს.
Apple-ის სახელმძღვანელო კომპიუტერის სახელებისა და ლოკალური ჰოსტის სახელების შესახებ მეგობრულ სახელს General-ისა და About-ის ქვეშ ათავსებს, ხოლო ლოკალურ სახელს General-ისა და Sharing-ის ქვეშ. ის ასევე აღწერს იმ ავტომატურ სუფიქსს, რომელიც ემატება მაშინ, როცა იმავე კავშირზე სხვა Mac უკვე იყენებს სახელს, რაც ღირს იცოდეთ სანამ მოულოდნელ რიცხვს გარე ჩარევის მტკიცებულებად ჩათვლით.
რას ამტკიცებს სინამდვილეში shell-ის მოთხოვნა
მოთხოვნა არის სტრიქონი, რომელსაც shell აგებს, და მისი ჰოსტის სახელის ელემენტი შეიძლება მოვიდეს გაფართოებული ჰოსტის სახელიდან, მისი შემოკლებული ფორმიდან ან პროფილის ფაილში ხისტად ჩაწერილი მნიშვნელობიდან. ის ასევე შეიძლება ეკუთვნოდეს სრულიად სხვა მანქანაზე SSH სესიას, რაც ყველაზე ნაკლებად ბრწყინვალე ახსნაა და ყველაზე გავრცელებული მოთხოვნისთვის, რომელიც VPN-ის ჩართვის მომენტში შეიცვალა.
შეამოწმეთ სად ხართ სანამ შეამოწმებთ რა გქვიათ. გაუშვით hostname და შეადარეთ ის სამ შენახულ მნიშვნელობას, შემდეგ შეხედეთ shell-ის მოთხოვნის პარამეტრს, რომ ნახოთ ჰოსტს საერთოდ აჩვენებს თუ არა. თუ მოთხოვნა შეიცავს ლიტერალურ სტრიქონს, რომელიც ვიღაცამ წლების წინ კონფიგურაციის ფაილში აკრიფა, ვერც ერთი სისტემური ცვლილება ვერასოდეს დაამთხვევს მას.
შედარება მნიშვნელოვანია ანგარიშისთვისაც. განსხვავებულად მოჩვენებული მოთხოვნა და ნამდვილად შეცვლილი შენახული ComputerName ორი განსხვავებული მფლობელის მქონე ორი აღმოჩენაა, და მათი ერთ წინადადებაში გაერთიანება შემდეგ ინჟინერს არასწორ ადგილას აგზავნის.
სად შეიძლება VPN-მა ლეგიტიმურად შეეხოს სახელდებას
VPN ცვლის, რომელი რეზოლვერები და ძებნის დომენებია შესაბამისი, და თუ კლიენტი მზადაა ერთის მიღებისთვის, მას DHCP-ის მეშვეობით ჰოსტის სახელი შეიძლება მისცეს. ეს რეალური მექანიზმია და უფრო ვიწროა, ვიდრე „VPN-მა ჩემი Mac-ი გადაარქვა“. რეზოლვერის მიერ იმის შეცვლა, რომელი სახელი იხსნება მოცემული მისამართისთვის, არ გადაწერს შენახულ ლოკალურ მნიშვნელობებს.
ამიტომ გამოყავით ორი კითხვა. განსხვავებულია თუ არა თავად მანქანის იდენტობა, ან განსხვავებულია სახელი, რომელსაც ის სხვა რამეზე მისასვლელად იყენებს? პირველზე პასუხობს სამი შენახული მნიშვნელობა; მეორეზე — DNS მოთხოვნები და გამოყენებული კავშირის პროფილი. მათ როგორც ერთ კითხვად განხილვა იწვევს იდენტობის პარამეტრების ცვლილებას სახელების გადაწყვეტის პრობლემის საპასუხოდ.
თუ ნამდვილად საჭიროა მუდმივი ჰოსტის სახელი
მნიშვნელობის დაყენება განზრახ ადმინისტრაციული ქმედებაა და არა კოსმეტიკური უპირატესობა, და მნიშვნელობა უნდა მოვიდეს მისგან, ვინც მანქანის სახელდების პოლიტიკას ფლობს. მართული სახელის გადაწერამ, რომ მოთხოვნა ნაცნობად გამოიყურებოდეს, შეიძლება დაარღვიოს სერთიფიკატების შემოწმება, მონიტორინგი და ყველაფერი, რაც ჰოსტს იდენტიფიცირებს.
სადაც ცვლილება ნამდვილად საჭიროა, იგივე ხელსაწყო, რომელმაც მნიშვნელობები წაიკითხა, წერს მათ, და HostName იღებს სრულად კვალიფიცირებულ სახელს, ხოლო დანარჩენი ორი ლოკალურ ფორმებს ელოდება. ჩაწერეთ რა შეცვალეთ და რატომ, რადგან ეს ზუსტად ისეთი რედაქტირებაა, რომელიც მანქანაზე შემდეგ შემხედვარეს აკვირვებს.
უმეტესი ანგარიშისთვის სწორი პასუხი უფრო მცირეა, ვიდრე კითხვა გვთავაზობს: წაიკითხეთ სამივე მნიშვნელობა, დაადგინეთ რომელი განსხვავდება და შეასწორეთ მხოლოდ ის. მოთხოვნა რაღაცის სიმპტომი იყო, და სამი ბრძანება გეუბნებათ რომლის.