호스트 이름을 검색하려는 sudo 명령

최근에 sudoers 파일과 호스트 이름을 / etc / hostname을 통해 변경했습니다. 이 파일을 변경 한 후 sudo 명령에 많은 시간이 걸립니다. 또한 sudo는 호스트 kaagini (내 컴퓨터의 호스트 이름)를 확인할 수 없다고 말합니다.

sudo가 무언가에 권한을 제공하기 위해 호스트 이름을 알아야하는 이유는 무엇입니까 ??

내 sudoers 파일에는 "Defaults env_reset"명령이 있습니다. 비슷한 질문이 있지만 컨텍스트는 원격 로그인이 아닙니다. 로컬 호스트에 오류가 표시됩니다.

문제에 대한 초기 인터넷 검색 결과 / etc / hosts 파일의 실제 호스트 이름은 127.0.0.1이어야합니다. 이것은 내 문제를 해결했습니다. 그러나 내 실제 질문은 : 왜 우리는 sudo에 이것을 요구합니까 ?? 로그인 장소에 관계없이 sudo가 작동해야합니다.

이 /etc/sudoers파일은 여러 서버에 분산 될 수 있도록 설계되었습니다. 이를 위해 파일의 각 권한에는 호스트 부분이 있습니다.

일반적으로이 설정 ALL=은 모든 서버에 대해 권한이 유효하지만 특정 호스트로 설정할 수 있음을 의미합니다.

%sudo    kaagini=(ALL) ALL

sudo가이 규칙을 적용해야한다는 것을 알기 위해서는 실행중인 호스트를 찾아야합니다. /etc/hosts올바른 것에 의존하는 호출을 사용하므로 옳지 않으면 실패합니다.

그 주장 할 수있는 sudo호스트 부분이 설정되어있는 경우 이름 조회를 수행 귀찮게 할 필요가 없습니다 ALL=모든 사용 권한에 대한,하지만 그냥 그런 식으로 작동하지 않습니다 - 실행 규칙을 처리하기 전에 여기서 해결하기 위해 나타납니다 .

sudo는 사용자가 현재 시스템에서 수행 할 수있는 작업을보기 위해 / etc / sudoers 만 읽으므로 유지 관리가 용이합니다. 그러나 서버가 100 개인 관리자는 유지 관리하기 위해 100 개의 서로 다른 / etc / sudoers 파일이 필요할 수 있습니다. sudoers는 권한에 호스트 부분이 있으므로 단일 sudoers 파일을 유지 관리하고이를 모든 시스템에 분배 할 수는 있지만 각 시스템에서 사용자가 수행 할 수있는 작업을 세분화 할 수 있습니다.

Matthias Urlichs가 다른 의견으로 제출 한 링크 된 버그 보고서 덕분에 다음 명령으로 문제가 해결되었습니다.

Defaults !fqdn

이 줄을 /etc/sudoers파일 에 넣으십시오.

Puppet 은 Puppet Manifests 파일을 읽어 서버를 자동으로 구성 할 수있는 구성 관리 소프트웨어입니다. 이러한 파일에는 / etc / sudoers 파일의 정의가 포함될 수 있으며,이 파일은 꼭두각시 "마스터"에서 모든 퍼펫 "에이전트"로 푸시 될 수 있습니다. 그런 다음 모든 호스트는 / etc / sudoers 파일의 동일한 사본을 가져옵니다.이 파일에는 HOST 정의가 포함될 수 있으며 일부 호스트에는 일부 명령을 부여 할 수 있습니다 (다른 호스트는 제외).