모든 bin 및 sbin 폴더를 명확하게 살펴 보겠습니다 (파일 시스템 계층 표준).

• /bin 시스템 레벨 바이너리 용
• /sbin 주로 부트 로더와 시스템 관리자를위한 다른 시스템 레벨 바이너리 용
• /usr/bin 필수 바이너리가 아닙니다.
• /usr/sbin-시스템 관리자를위한 필수 도구가 아닌 혼란이 시작되는 곳? 무슨 뜻이에요? 실험을 위해?
• /usr/local/bin -이 폴더에 대한 말이 없습니다
• /usr/local/sbin-로컬로 설치된 시스템 관리 프로그램. 다시? 어때요 /usr/sbin?

그래서 질문은 : 거기에 너무 많은 디렉토리이며,의 의미가 무엇 왜 /usr/sbin, /usr/local/sbin그리고 /usr/local/bin?

많은 프로그램이 아카이브를 통해 배포되며 소스 코드에서 빌드해야합니다. 일반적으로 makefile이 있으므로 매우 쉽습니다. 이 프로세스에는 주어진 프로그램에 대한 특정 폴더를 만들지 않고 usr / local / lib, usr / local / bin ... usr / local / what에 파일을 만드는 과정이 포함됩니다.

왜 그래야만하지?

프로그램을 제거 해야하는 경우 프로그램 작성자가 처리하지 않으면 모든 파일을 수동으로 삭제해야하기 때문에 그것이 옳지 않다고 생각합니다.

1. 디렉토리 구조

이것은 파일 시스템 계층 표준 ( 2.3 PDF ) 에서 다루어야합니다.

/ bin / 단일 사용자 모드에서 사용할 수 있어야하는 필수 명령 바이너리.
            모든 사용자 (예 : cat, ls, cp)

/ sbin / 필수 시스템 바이너리 (예 : init, ip, mount).

/ usr / bin / 필수적이지 않은 명령 바이너리 (단일 사용자 모드에서는 필요하지 않음); 
            모든 사용자를 위해

/ usr / sbin / 비 필수 시스템 바이너리 (예 : 다양한 네트워크 서비스 용 데몬)

/ usr / local /이 호스트에 특정한 로컬 데이터의 3 차 계층. 
            일반적으로 bin /, lib /, share /와 같은 추가 하위 디렉토리가 있습니다.

2. 설치

가능한 경우 패키지 관리자를 사용합니다 (예 : yum 또는 apt-get). 이는 매우 많은 수의 응용 프로그램에서 가능하며 경우에 따라 리포지토리를 추가해야 할 수도 있습니다. 두 번째 선택은 RPM과 같은 하위 레벨 패키지이며 소스에서 컴파일하는 것이 최후의 수단입니다 (그러나 일부 사람들은 이것을 선호합니다)

일부 패키지 관리자 (예 : RPM을에서 설치할 수 있습니다 yum install oddity.rpm)

소스에서 컴파일하는 경우 시스템 설치 관리자가 수행 한 작업을 알 수 있도록 자체 패키지를 만드는 큰 단계가 아닐 수 있습니다.

그런 다음 문제는 예를 들어 yum remove packagename

대안은 수행 된 모든 sysadmin 활동에 대한 좋은 문서를 유지하는 것입니다 (어쨌든 텍스트 파일에 저널을 보관합니다)

모든 * / sbin 디렉토리의 내용은 시스템 관리자에게만 유용한 경향이 있습니다. 일반 사용자 인 경우 PATH에서 벗어날 수 있습니다.

단일 디스크에 단일 유닉스 머신이 있으면 다른 디렉토리는 의미가 없지만 큰 시스템과 다른 파티션이 있으면 더 합리적입니다. 이러한 습관은 시스템이 약간 다른 80 년대와 90 년대에 만들어 졌다는 것을 기억하십시오.

/sbin매우 작은 경향이 있습니다 . 이들은 실제로 호스를 쳤을 때 필요한 유틸리티입니다. 이것을 / root 및 / lib를 사용하여 최소 루트 파티션에 넣습니다. / sbin에있는 것들은 정적으로 연결되어있었습니다. / usr 파티션에 호스가 있으면 동적으로 연결된 앱은 쓸모가 없기 때문입니다. fsck가 여기 있고 정적으로 링크되어 있습니다. / usr에 종속되어 있다면 분명히 / usr /을 fsck 할 수 없습니다. 물론 루트 파티션이 호스로 연결되어 있다면 나사가 매우 조여져있는 것입니다. 이것이 이것이 작은 파티션 인 이유입니다. 여기서 아주 적은 블록을 사용하여 불량 디스크 블록의 가능성을 낮추십시오.

/usr/sbin바이너리는 최소한 단일 사용자 모드로 전환하여 모든 볼륨을 마운트 할 수있는 일반적인 sysadmin 도구입니다. 그것들은 동적으로 연결될 수 있습니다.

/ sbin (웰, / sbin on / 파티션) 및 / usr에 대한 별도의 파티션은 백업이 시간과 테이프 모두에서 매우 비싸다는 것을 기억할 때 더 의미가 있습니다. 별도의 파티션에있는 경우 다르게 예약 할 수 있습니다.

/usr/local네트워크 파일 시스템이 될 수 있습니다. 따라서 여러 컴퓨터에서 공유 할 수있는 로컬로 작성된 sysadmin 도구는 때때로 / usr / local / sbin으로 이동합니다. 분명히 네트워크 고정 유틸리티는 갈 수 없습니다.

다시 말하지만, 단일 볼륨 파티션에있는 하나의 Linux 시스템에서는 볼륨이 여러 개인 관리되는 시스템의 네트워크 환경에서 큰 시스템에 많은 의미가 있습니다.

여기서 슈퍼 유저에 대한 두 번째 질문은 별도의 질문이어야합니다. 첫 번째와 관련이 없습니다.

그렇습니다. 이것이 많은 패키징 솔루션이있는 이유입니다. RedHat은 모든 곳에서 사용되는 RPM을 만들었습니다. 솔라리스는 패키지 형식을 가졌습니다. HP / UX에는 자체 패키지가 있으며 다양한 패키지 형식이 있습니다. 적절한 장소 (/ usr / bin, / usr / lib)에 물건을 보관하되 쉽게 추가하고 제거 할 수 있습니다.

소스의 경우 / usr / local의 하위 디렉토리에 구성하고 설치할 수있는 도구가 있었으며 / usr / local / bin에 대한 심볼릭 링크를 처리합니다. 패키지 도구가 널리 확산되었으므로 덜 필요하며 이름을 잊어 버렸습니다.

어떤 사람들은 / opt / packagename 에 설치 하고 모든 것을 함께 유지하는 것을 좋아합니다 . 좋은 점은 모든 것이 하나의 디렉토리에 있고 제거는 rm -rf /opt/packagename입니다. 이것의 단점은 모든 사람의 PATH에 / opt / packagename / bin을 추가하고 사람들이 일반적으로 별도의 파티션에 / opt를 넣지 않고 루트 파티션을 채우는 사실입니다.

디렉토리의 의미에 대한 나의 취향은 (Debian GNU Linux 경험에서) 다음과 같습니다.

첫 번째 차이점 s은 수퍼 유저를위한 것입니다

sbin디렉토리 앞에는 일반적으로 관리자에게만 유용한 도구가 포함되어 있음을 나타냅니다. 예 ifconfig를 들어이 범주에도 속하며 ifconfig일반 사용자 (IP 주소 / 네트워크 연결이 있는지 확인 하기 위해)를 호출 하여이 구별을 어렵지 않게 만드는 것을 좋아합니다.

두 번째 구별 : local"로컬 데이터"

실제로 여기서 가장 중요한 차이점은 APT와 같은 OS 패키지 관리자가 패키지를 일반 /usr구조에 설치 하고 /usr/local영향을받지 않는다는 것입니다. 이를 통해 시스템 관리자가 제공 한 로컬로 컴파일 된 패키지 또는 회사 내부 스크립트를 /usr/local제대로 패키지 된 파일을 방해하지 않는 위치에 둘 수 있습니다.

/usr/local기존 /usr구조 에서 기존 파일을 대체 해야하는지 여부에 대해서는 논란의 여지 가 있습니다. PATH에서 / usr / bin보다 / usr / local / bin을 갖는 것이 위험합니까?를 참조하십시오. 이에 대한 자세한 내용은.

세 번째 구별 : 최상위 레벨 /bin및 /sbin디렉토리.

데비안에는 실제로 소위 UsrMerge가 있습니다. 그 차이가있을 사용 /bin하고 /sbin부팅 프로세스 이전에 사용할 수 있었던 (생각 /usr네트워크 장치 또는 다른 파티션, RAID 등에있는)하지만, nowdays는 몇 리눅스 시스템은없이 잘 부팅 /usr내가 리면의 차이를 고려할 이유가 레벨과 /usr디렉토리는 리눅스에서 역사적으로 중요한 관심사가되었습니다.

마지막으로 : "산란"파일의 장점과 문제점.

이에 대한 "하나의 진실한"답변은 실제로 없습니다. Linux의 흩어진 파일 시스템의 장점은 다음과 같습니다.

• 모든 바이너리는 몇 개의 디렉토리에 있습니다. 즉, 쉘에서 모든 프로그램을 호출 할 수 있습니다. %PATH%관심있는 프로그램을 추가 하기 위해 항상 환경 변수를 편집해야하는 Windows를 비교하십시오 . Windows에서 매우 긴 경로 환경을 보았습니다.

• 모든 도서관은 중앙에 있습니다. 이는 여러 응용 프로그램에서 사용될 때 두 번 설치할 필요가 없음을 의미합니다.

• Linux는 대부분의 시스템 파일을 패키지 관리자 가 추적하도록 설계되었으므로 사용자 관점에서 파일의 개요를 유지할 필요가 없습니다.

• FHS 표준화로 인해 설명서는 중앙 위치 man에 info있으며 지원되는 README 파일과 같은 시스템이 예상대로 작동합니다.

• 고정 된 장소에 설치되는 프로그램에 의존하는 것이 더 쉽습니다. 모든 사람은 #!/bin/sh -e스크립트의 시작 부분에 글을 쓰거나 비슷하게 작동합니다 . 쉘이 다른 디렉토리로 이동하는 시스템을 생각해보십시오. 어떤 이름을 사용할지 어떻게 알 수 있습니까? 관심이 있다면 Windows에 Perl 또는 LaTeX를 설치하는 다양한 방법을 확인하여 이것이 얼마나 복잡한 지 확인하십시오.

지금까지 내가 찾은 단점은 다음과 같습니다.

• 일반적으로 "휴대용 응용 프로그램"이라는 의미에서 "휴대용"응용 프로그램을 실행하기가 더 어렵습니다. Linux에서 프로그램을 다른 컴퓨터로 복사하는 것만 큼 쉽지는 않습니다. 루트 권한이 필요한 패키지가 있거나 LD_LIBRARY_PATH응용 프로그램이 필요한 라이브러리의 다른 검색 경로를 가리 키도록 처리해야합니다 .

• 동일한 프로그램의 여러 버전 설치는 명시 적으로 지원되어야하지만 "프로그램 당 하나의 디렉토리"가있는 시스템에서는 문제가되지 않는 경우가 많습니다.

• 패키지 관리자없이 파일을 관리하면 오류가 발생하기 쉽습니다 (이미 언급 한 바와 같이).

두 번째 질문에 대답하려면 :
일반적으로 프로그램은 소위 패키지 관리자 와 함께 배포됩니다 . 패키지 관리자는 일반적으로 바이너리 패키지 (특정 플랫폼 용으로 컴파일 된 소프트웨어)를 가져 와서 디렉토리 주위로 던집니다 (소스 코드를 다운로드하여 컴퓨터에서 컴파일하여 설치하는 사람이 있습니다). 따라서 패키지 관리자는 특정 "프로그램"(패키지)에 속하는 파일이 어디에 있는지 알고 있으며 패키지를 제거 할 때 패키지 관리자가 모든 것을 정리합니다.
소스 코드를 직접 컴파일 할 때도

make

와 함께 설치

make install

당신은 보통 할 수 있습니다

make uninstall

파일 시스템에서 파일을 삭제합니다.