/usr 디렉터리

저번 글에서 언급한 /usr 디렉터리에 대해서 글을 마저 쓰려고 한다.

/usr 디렉토리는 앞서 언급했던 디렉토리와 달리, 구조 자체가 복잡하다.

대략적인 지도는 이렇게 제시하고 있다. 그럼 /usr의 의미는 무엇이길래 이런 구조로 되어 있는 것일까?

 

man hier를 입력해보면, /usr의 의미를 이렇게 말하고 있다.

 

‘ 이 디렉터리는 일반적으로 별도의 파티션에서 마운트됩니다. 리눅스를 실행하는 다양한 컴퓨터에서 마운트 할 수 있도록 공유 가능한 읽기 전용 데이터만 저장해야 한다. '

 

말이 뭔가 어렵다. linux foundation에선 /usr를 길게 말하고 있지만 일부 내용을 편집해서 가져 왔다.

 

’ /usr은 일반적으로 시스템에서 가장 큰 데이터 공유를 포함합니다. 따라서, 이것은 모든 사용자 바이너리, 문서, 라이브러리, 헤더 파일 등을 포함하고 있기 때문에 시스템에서 가장 중요한 디렉토리 중 하나이다. 텔넷, ftp 등의 사용자 프로그램도 배치되어 있습니다. 옛날에는 '사용자와 관련된 모든 것'이었지만, 언제부턴가 '사용자가 사용할 수 있는 프로그램과
데이터'로 의미가 좁혀지고 길어졌다. 따라서 일부 사용자는 이 디렉터리를 원래 의도한 대로 '사용자'가 아닌
'사용자의 시스템 리소스'를 의미하는 것으로 나타낼 수 있습니다. ‘

 

즉, 사용자의 자원들이 있는 곳이 /usr 이다. 이 디렉터리의 모든 파일, 내부 디렉터리는 ls를 이용해서 목록을 확인할 수
있다. 그럼 /usr 바로 밑에는 뭐가 있는지 확인해보자.

마지막에 있는 x86_64-suse-linux를 제외하면, 다들 어디서 본 디렉토리이다.
특히, bin, lib, lib64, sbin은 앞선 시간에 있었던 디렉터리이고 어디서 많이 본 local이란 것도 보인다.

일단 /usr/bin과 /bin과의 차이를 알아보도록 하자.

linux foundation에서는 /usr/bin을 이렇게 설명한다.

’ 이 디렉터리는 시스템에 있는 대부분의 이진 파일을 포함합니다. 이 디렉터리의 실행 파일은 매우 다양합니다. 예를 들어 vi, gcc, gnome-session 및 mozilla는 모두 여기에 있습니다. ‘

 

저번 시간에 필자는 /bin을 사용자가 기본적으로 사용 할 수 있는 명령어들이 들어있다고 했었다.

 

가장 큰 차이는 ’기본적으로‘ 인 것 같다. 그럼 이 단어로 인해 오는 차이는 얼마나 될까? 수치로 판단 할 수 있는 것은
디렉토리의 들어있는 파일의 개수라고 생각한다. 한번 비교해보도록 하자.

’기본적으로‘에서 오는 차이가 이렇게 컸다. 그럼 /bin과 /usr/bin은 완전히 독립된 디렉토리인가라고 물어보면 아니라고
말할 것이다. 이유는 아래와 같다. 아래는 ll /bin을 입력한 결과다.

/bin/rm이 /usr/bin/rm을 가르키고 있고, sed 역시 /usr/bin을 가르키고 있다. 즉, 필자는 /usr/bin에서 꼭 필요한 명령어들만 따로 모아둔 곳이 /bin이다 라고 생각한다.

 

그럼 ’기본적으로‘ 사용할 수 있는 명령어들만 있는 곳이 /bin이라고 했다. 그럼 ’기본적으로‘를 수치 말고
예시로 체감해보자 한다. 아주 알맞은 예시가 있다. 바로 ’zypper’ 이다.

 

zypper는 redhat의 yum, dnf처럼 패키지를 다운로드 할 수 있는 명령어이다.

그럼 zypper는 꼭 필요한 존재인가?

 

이처럼, /usr/bin에는 사용자가 사용할 수 있는 명령어들이 있지만, 이 중에서 꼭 필요한 명령어들이 있는 곳이

/bin 이다.

/usr/lib은 /lib과의 관계를 알아보자. 일단 /usr/lib의 정의를 보도록 하자.

‘ 이 디렉터리에는 프로그램 라이브러리가 있습니다. 라이브러리는 자주 사용되는 프로그램 루틴의 모음입니다.

동적 라이브러리를 포함한 객체 라이브러리와 일반적으로 직접 호출되지 않는 일부 실행 파일.
더 복잡한 프로그램에는 전체 하위 디렉터리가 있을 수 있습니다. ’

 

말이 복잡하니, 간단하게 이해하고 싶으면

‘자주 실행되는 프로그램 라이브러리가 있습니다. 안에는 더 복잡한 게 있을 수 있습니다.’
요약하자면 이런 설명이 되겠다.

 

정적 라이브러리는 외부 라이브러리에 의존하지 않는 완전한 프로그램을 말함. 그렇기에, 필수 구성 요소가 없어도 작동이 된다는 것이다. 객체 라이브러리는 앱에 의해 호출되는 함수들을 위한 컴파일 된 객체 코드를 포함하는 파일이다.

 저번 글에선 /lib를 단순하게 명령어 동작에 필요한 라이브러리들이 있는 곳 이라고 칭했다.

그럼 마찬가지로 ‘자주’를 체감해보자 한다.

개수는 약 10배 이상이 차이가 난다.

그럼 이번에도 의존성을 확인해보자 한다. 이때 명령어의 의존성을 확인해주는 ldd라는 명령어를 이용할 것이다.

이 명령어를 사용할 때는 라이브러리를 확인할 대상이 존재하는 디렉토리의 위치에서 실행해야 한다는 것이다.

 

다양한 의존성을 보인다. 그럼 이 의존성을 가지는 라이브러리들은 어디에 있을지를 살펴보자.

일단, 의존성을 가지지 않는 linux-vdso.so.1의 위치를 찾아보자.

없다고 나온다. 이것만 설명해도 한 블로그 글을 또 써야 하기에 다음으로 미루겠다.

찾아보고 싶으면 man 7 vdso를 읽어보자.

 

윗 사진에서도 유추할 수 있듯이, /lib역시 /usr/lib에서 ‘기본적으로’ 필요한 것만 가져온 것이라고 생가할 수 있겠다.

그럼 나머지 /usr/lib64와 /usr/sbin 역시 똑같은 맥락이겠다.

 

/usr/share

동일한 OS의 서로 다른 아키텍처 간에 공유할 수 있는 특정 응용 프로그램 데이터가 있는 하위 디렉터리가 포함되어 있습니다. 그러나 '/usr/share'는 일반적으로 서로 다른 운영 체제나 동일한 운영 체제의 서로 다른 릴리스에서 공유할 수 없습니다. 수정할 필요가 없는 데이터를 포함하거나 필요로 하는 모든 프로그램 또는 패키지는 '/usr/share'(또는 로컬로 설치된 경우 '/usr/local/share')에 저장해야 합니다.

이를 위해 /usr/share에서 하위 디렉터리를 사용하는 것이 좋습니다."

 

즉, 동일한 os 간에는 안에 있는 파일들을 공유할 수 있는 디렉터리이다.

( 단 같은 os라도 서로 다른 버전 간에는 공유가 불가능하다 )

여기서 굉장히 막연한 표현이 나왔다. 바로 ‘공유할 수 있는 디렉터리’이다.

공유는 누구랑 할 것이고, 어떻게 이루어지는지는 ls로 확인이 불가능하다,
단, 공유할 내용들은 확인할 수 있다.

 

( 가독성을 위해, 모든 내용을 다 캡처하지는 못했음 )
이 파일들이 나중에 공유할 파일이라는데, 그럼 어떻게 공유가 이루어질까?
바로 nfs를 이용하면 된다. 이 링크는 nfs와 /usr/share를 이용해서 man 페이지를 공유하는 과정을 담은 글이다.
https://m.blog.naver.com/gkdisakdmaqk/221187491802

 

글을 보면, /usr/share/man이라는 경로를 적어주는 내용이 나온다. 여기서 포커스를 두어야 할 점은 /usr/share이 아니라 경로를 적어준다는 것이다. /usr/share는 동일 os간 공유할 수 있는 파일을 모아둔 곳이지, 특별한 설정이 들어가서 이 디렉토리만 공유가 되는 것이 아니다. /home/<계정>/share 같이 임의의 디렉토리 안에 있는 파일을 공유 할 수 있다. 단지, 이 디렉토리는 사용자 편의를 위해 만들어진 디렉토리일 뿐이다.

 

마지막으로 /usr/local을 알아보자.

'/usr'의 구조를 복사합니다.

오늘날 '/usr/local'은 자체 컴파일된 프로그램이나 타사 프로그램을 보관하기에 좋은 장소로 널리 간주되고 있습니다.

/usr/local 계층은 소프트웨어를 로컬로 설치할 때 시스템 관리자가 사용합니다.

시스템 소프트웨어가 업데이트될 때 덮어쓰기되지 않도록 안전해야 합니다.

호스트 그룹 간에 공유할 수 있지만 /usr에서 찾을 수 없는 프로그램 및 데이터에 사용할 수 있습니다.

로컬로 설치된 소프트웨어는 /usr에서 소프트웨어를 교체하거나 업그레이드하는 경우를 제외하고는 /usr이 아닌 /usr/local 내에 배치해야 합니다.

‘ 이곳은 일반적으로 사이트에 로컬인 프로그램이 가는 곳이다. ’

 

정의를 번역하면 이런 문장이다만, 이해하기가 좀 복잡하다.
그래서 stackexchange에서 좋은 글이 있길래 번역해서 가져왔다.

 

즉, 기본 os 시스템이 사용하지 않는 파일이 위치

/usr/local은 일반적으로 make 명령어(예: ./configure; make; make install)를 사용하여 관리자가 빌드한 파일을 설치하는
장소입니다.

이 방법은 운영 체제의 일부인 파일과의 충돌을 피하기 위한 것으로, 그렇지 않으면 로컬 파일을 덮어쓰거나 덮어쓰게 된다

 

반면 /opt는 번들되지 않은 패키지(즉, 운영 체제 배포의 일부가 아니지만 독립적인 소스에 의해 제공되는 패키지)를 설치하기 위한 디렉토리 /usr/local과 달리 이 패키지들은 디렉터리 규칙을 따른다.

예를 들어 일부 앱은 /opt/someapp/bin/foo 명령 중 하나이며

구성 파일은 /etc/opt/someapp/foo.conf에 있고

로그 파일은 /var/opt/someapp/logs/foo.access에 있습니다. ( 수세는 아마 /var/opt가 아니라 /var/log 이다. )

https://unix.stackexchange.com/questions/11544/what-is-the-difference-between-opt-and-usr-local

 

 

구성은 이렇게 되어 있다.

 

/usr/local/bin은 직접 컴파일한 바이너리 형식의 파일들이 위치한다. 만약에 본인이 직접 컴파일을 한 파일을 /usr/bin에
넣었다면, 나중에 업그레이드가 될 때 직접 만든 파일이 사라질 수도 있다. 그렇기에 꼭 local 밑에 넣도록 하자. 나머지 lib, lib64, sbin도 그럴 것이다.