모든 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/whatever에 파일을 만드는 작업이 포함됩니다.
왜 그래야만하지?
프로그램을 제거해야 하는 경우 프로그램 작성자가 처리하지 않으면 모든 파일을 수동으로 삭제해야 하기 때문에 옳지 않다고 생각합니다.
답변1
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
대안은 수행된 모든 시스템 관리자 활동에 대한 좋은 문서를 보관하는 것입니다(어쨌든 나는 일지를 텍스트 파일로 보관합니다).
답변2
모든 */sbin 디렉토리에 있는 내용은 시스템 관리자에게만 유용한 경향이 있습니다. 일반 사용자라면 PATH에서 제외할 수 있습니다.
단일 디스크에 단일 Unix 시스템이 있는 경우 다른 디렉토리는 그다지 의미가 없지만, 큰 시스템과 다른 파티션이 있는 경우 더 의미가 있습니다. 이러한 습관 중 상당수는 시스템이 약간 달랐던 80년대와 90년대에 만들어졌다는 점을 기억하세요.
/sbin경향이 있다매우작은. 이것들은 정말 힘들 때 필요한 유틸리티입니다. /root 및 /lib를 사용하여 최소 루트 파티션에 이를 배치합니다. /sbin에 있는 항목은 모두 정적으로 연결되어 있었습니다. /usr 파티션이 호스로 연결된 경우 동적으로 연결된 모든 앱은 쓸모가 없기 때문입니다. fsck는 여기에 정적으로 연결되어 있습니다. /usr에 대한 종속성이 있는 경우 당연히 /usr/을 fsck할 수 없습니다. 물론 루트 파티션이 호스로 연결되어 있으면 매우 망가집니다. 이것이 바로 이것이 작은 파티션인 이유입니다. 여기서는 아주 적은 블록을 사용하여 불량 디스크 블록의 확률을 낮추십시오.
/usr/sbin바이너리는 최소한 단일 사용자 모드로 전환하여 모든 볼륨을 마운트할 수 있는 일반 시스템 관리 도구입니다. 동적으로 연결될 수 있습니다.
/sbin(음, /파티션의 /sbin)과 /usr에 대한 별도의 파티션도 백업에 시간과 테이프 측면에서 매우 많은 비용이 든다는 점을 기억할 때 더 의미가 있습니다. 별도의 파티션에 있는 경우 다르게 예약할 수 있습니다.
/usr/local네트워크 파일 시스템일 수 있습니다. 따라서 여러 시스템에서 공유할 수 있는 로컬로 작성된 sysadmin 도구는 때때로 /usr/local/sbin에 저장됩니다. 분명히 어떤 네트워크 수정 유틸리티도 거기에 갈 수 없습니다.
다시 말하지만, 여러 볼륨이 있는 관리되는 컴퓨터의 네트워크 환경에 있는 대형 컴퓨터에서는 많은 것이 더 의미가 있지만 단일 루트 파티션에 있는 하나의 Linux 컴퓨터에서는 그렇지 않습니다.
답변3
두 번째 질문은 여기 슈퍼유저에 대한 별도의 질문이어야 합니다. 첫 번째와 관련이 없습니다.
예, 여기저기에 파일이 있으면 짜증납니다. 이것이 바로 많은 포장 솔루션이 존재하는 이유입니다. RedHat은 어디에서나 사용되는 RPM을 만들었습니다. Solaris에는 패키지 형식이 있었습니다. HP/UX에는 자체 패키지가 있었고 적절한 패키지 형식과 기타 다양한 패키지 형식이 있습니다. 적절한 위치(/usr/bin, /usr/lib)에 항목을 보관하되 쉽게 추가하고 제거할 수 있도록 하십시오.
소스의 경우 /usr/local의 하위 디렉터리에 구성 및 설치하고 /usr/local/bin에 대한 심볼릭 링크를 처리할 수 있는 도구가 있었습니다. 패키지 도구가 널리 확산되면서 덜 필요하게 되었고 그 이름을 잊어버렸습니다.
어떤 사람들은 /opt/에 설치하는 것을 좋아합니다.패키지 이름거기에 모든 것을 함께 보관하십시오. 장점: 모든 것이 하나의 디렉토리에 있고 제거는 rm -rf /opt/packagename. 단점은 모든 사람의 PATH에 /opt/packagename/bin을 추가해야 한다는 점과 사람들이 일반적으로 /opt를 별도의 파티션에 넣지 않아 루트 파티션을 채우게 된다는 점입니다.
답변4
두 번째 질문에 대답하려면:
일반적으로 프로그램은 소위 말하는 것과 함께 배포됩니다.패키지 관리자. 패키지 관리자는 일반적으로 바이너리 패키지(특정 플랫폼용으로 컴파일된 소프트웨어)를 가져와서 디렉터리 주위에 버립니다(소스 코드를 다운로드하여 컴퓨터에서 컴파일하고 설치하는 사람도 있습니다). 따라서 패키지 관리자는 특정 "프로그램"(패키지)에 속한 파일이 어디에 있는지 알고 있으며, 패키지를 제거하려는 경우 패키지 관리자가 모든 것을 정리합니다.
소스코드를 직접 컴파일하더라도
make
그리고 그것을 설치하십시오
make install
넌 보통 할 수 있어
make uninstall
파일 시스템에서 파일을 삭제합니다.