저는 2010년부터 공식적으로 Linux를 접하기 시작했습니다. 보급형 배포판은 Ubuntu 10.10이었고 나중에 Ubunu 11.04로 전환했습니다. 이 기간 동안 저는 다른 주류 배포판도 많이 시도했습니다. 실습에 들어간 후 CentOS 5를 사용하기 시작했고, 그 다음에는 CentOS 6을 사용했고, 이제는 CentOS 7로 발전했습니다.
저는 4년 동안 Linux를 사용해 왔습니다. 처음 3년은 여기저기서 많은 시간을 낭비하고 많은 경험과 교훈을 얻었습니다. 어쩌면 나는 이제 너무 늙어서 더 이상 귀찮게 하고 싶지 않을 수도 있습니다. 시스템을 구성한 후에는 계속 사용할 수 있기를 바랍니다.
이 글을 쓰거나 읽는 이유
Linux, 특히 CentOS를 사용할 때 몇 가지 함정에 직면하게 되거나 결벽증이 있는 사람들이 용납할 수 없는 몇 가지 문제에 직면하게 됩니다.
공식 소스의 소프트웨어 패키지 버전이 너무 오래되어 기능 요구 사항을 충족할 수 없습니다. 여러 소스의 소프트웨어 패키지에는 버전 충돌이 있습니다. 소프트웨어를 수동으로 컴파일하면 기본적으로 다른 파일이 /usr/local 아래의 다른 하위 디렉터리에 배치됩니다. 소프트웨어 업데이트 및 삭제가 번거롭습니다. 잠깐...
CentOS를 여러 번 재설치한 후, 현재 시스템의 안정성과 청결성을 최대한 보장하고 시스템 히스테리로 인한 재설치 충동을 최대한 줄이기 위해 다음과 같은 소프트웨어 설치 방법과 원칙을 정리했습니다.
다음은 CentOS7에 국한되며 다른 배포판을 참조할 수 있습니다.
공식 출처
CentOS와 함께 제공되는 4가지 공식 소스 중 기본, 업데이트, 추가 기능은 기본적으로 열려 있습니다. 이 3가지 소스에는 약 9,000개의 소프트웨어 패키지가 포함되어 있으며 가장 안정적이고 신뢰할 수 있는 소스입니다.
따라서 패키지가 공식 소스에 있는 경우 공식 소스에서 설치해야 합니다.
sudo yum install PackageName
제3자 소스
공식 소스에는 많은 소프트웨어 패키지가 포함되어 있지만 일상적인 요구 사항을 충족할 수는 없습니다. 다행히 공식 소스를 보완할 수 있는 타사 소스가 있습니다.
제3자 소스를 사용하는 과정에서 우리는 다음 두 가지 문제에 직면할 것을 가장 두려워합니다:
타사 소스와 공식 소스에 동일한 패키지가 존재하여 공식 소스 패키지가 타사 소스로 대체되고 동일한 소프트웨어 패키지가 여러 타사 소스에 존재하며 버전이 일치하지 않고 충돌합니다.
이 두 가지 문제는 종종 치명적이며 다양한 예상치 못한 결과를 초래하므로 타사 소스를 선택할 때는 다음 원칙을 따라야 합니다.
신뢰할 수 있는 제3자 소스만 선택하고 제3자 소스가 공식 소스의 패키지를 대체하지 않도록 하세요. 제3자 소스 간에 충돌이 발생하지 않도록 가능한 한 적은 수의 제3자 소스를 사용하세요.
CentOS의 경우
에 따르면대규모 타사 소스, 공식 소스 패키지를 대체하지 않으며 이들 사이에 충돌이 없는 것으로 확인되었습니다. EPEL: 과학 연구에 필수적인 6500개 이상의 소프트웨어가 포함되어 있습니다. ELRepo: 다양한 하드웨어 Nux를 위한 수십 개의 드라이버가 포함되어 있습니다. Dextop: 멀티미디어 관련 소프트웨어 패키지(개별 EPEL 소프트웨어와 충돌하므로 무시할 수 있음)
일부 소규모 타사 소스에는 몇 가지 소프트웨어만 포함되어 있으며 공식 소스 및 EPEL 소스와 충돌하지 않는지 확인하고 Google Chrome을 추가할 수도 있습니다. Google Chrome이 포함되어 있으며 공식 소스 및 EPEL 소스와 충돌하지 않습니다. : 플래시 플러그인만 포함되어 있으며 충돌이 없는 것으로 확인되었습니다. dropbox: dropbox 소프트웨어만 포함되어 있으며 충돌이 없는 것으로 확인되었습니다.
따라서 소프트웨어 패키지가 EPEL, ELRepo 또는 일부 소규모 타사 소스에 있는 경우 타사 소스를 추가하고 yum 명령을 사용하여 설치하세요.sudo yum install PackageName
공식 rpm 패키지
오픈 소스가 아닌 대부분의 소프트웨어는 CentOS 공식 소스 또는 EPEL에서 사용할 수 없습니다. 일부 소프트웨어의 공식 웹사이트에서는 공식 rpm 패키지를 제공합니다. 이때, 공식 홈페이지에서 현재 시스템에 해당하는 rpm 패키지를 다운로드 후, 다음 명령어로 직접 설치하시면 됩니다.sudo rpm -i PackageName.rpm
예를 들어 Linux용 WPS도 그 중 하나입니다. 설치 프로세스 중에 rpm 명령은 소프트웨어가 의존하는 패키지를 공식 소스 및 EPEL 소스에서 찾을 수 있으면 자동으로 설치됩니다.
rpm 패키지를 직접 설치하는 것은 꽤 쉽지만 yum으로 소프트웨어를 업데이트할 수 없어 조금 번거롭습니다. 앞서 언급한 Google, Dropbox, Adobe와 같은 일부 소프트웨어는 실제로 이 방법을 통해 설치할 수 있으며 설치 중에 소스가 시스템에 추가되며 이러한 소프트웨어는 여전히 쉽게 업데이트 및 삭제할 수 있습니다.
압축을 풀고 사용하세요
일부 소프트웨어는 공식적으로 압축된 패키지를 제공하며, Java로 작성된 많은 소프트웨어와 같이 해당 패키지에 포함된 바이너리 파일은 압축을 푼 후 바로 실행할 수 있습니다. 이러한 유형의 소프트웨어는 소스 코드를 제공하지 않지만 현재 플랫폼에서 직접 실행할 수 있는 바이너리 파일을 제공합니다. 오픈 소스가 아닌 대부분의 상용 소프트웨어는 이러한 접근 방식을 취합니다.예를 들어 sublime_text, pycharm, mendeley, TauP, sac 등은 직접 압축을 푼 다음 압축이 풀린 폴더를 /opt 디렉터리에 복사한 다음 소프트웨어의 bin 디렉터리를 PATH에 추가합니다. 예를 들어 Mathematics, Matlab, intel studio의 경우 소프트웨어 패키지에 설치 스크립트가 제공되며 스크립트를 실행하여 설치할 수 있습니다.
Linux에서는 상용 소프트웨어나 타사 소프트웨어가 /opt 디렉터리에 설치되는 습관이 있습니다. 이는 대부분의 상용 소프트웨어 패키지의 기본 설치 경로이기도 합니다.
타사 rpm 패키지 CentOS 소스 및 EPEL 소스에서 일부 소프트웨어를 찾을 수 없습니다. 공식 rpm 패키지는 제공되지 않지만 다른 타사 소스에서는 rpm 패키지를 제공합니다. 사례별로 토론하세요. 타사 소스에 소수의 패키지만 포함되어 있고 해당 패키지가 공식 소스 및 기타 사용된 타사 소스와 충돌하지 않는다고 확신하는 경우 타사 소스를 추가할 수 있습니다. 타사 소스에 많은 소프트웨어가 포함되어 있고 공식 소스 또는 EPEL 소스와 충돌할 가능성이 있는 경우 소스가 추가되지 않습니다. 소프트웨어 패키지에 복잡한 종속성이 없으면 소스에 rpm 패키지를 직접 설치하세요. 소프트웨어 패키지가 타사 소스의 다른 패키지에 의존하는 경우 포기하고 다른 방법을 찾으세요 타사 패키지 관리자 다른 배포판은 다른 패키지 관리자를 사용하고, CentOS는 yum을 사용하고, Ubuntu는 apt-get을 사용합니다. 최근 몇 년 동안 Linuxbrew, Gentoo Prefix 및 pkgsrc와 같은 일부 배포 독립적인 타사 패키지 관리자가 등장했습니다. Linuxbrew Linuxbrew는 OS X 플랫폼에서 매우 인기 있는 Homebrew에서 Linux로 포팅되었습니다. Linuxbrew는 시스템과 함께 제공되는 패키지 관리자에 대한 보충 자료로 사용할 수 있습니다. 그 기능은 다음과 같습니다: 모든 소프트웨어는 ${HOME}/.linuxbrew 디렉토리에 설치됩니다. 설치, 제거, 정보, 목록, 업데이트, 업그레이드 및 기타 기능에 필요한 소프트웨어 패키지가 없는 경우 소프트웨어 버전은 비교적 새로운 것입니다. 도서관에서 직접 쉽게 할 수 있습니다. 수식 만들기 시험해 본 후 함정 중 하나는 linuxbrew가 종속성 문제를 내부적으로 해결한다는 것입니다. 예를 들어, linuxbrew를 통해 터미네이터를 설치하려고 시도한 후 터미네이터가 Python에 의존한다는 것을 발견했습니다. Python이 이미 시스템에 설치되어 있지만 linuxbrew는 여전히 Python의 복사본을 설치하며 Python은 더 많은 것에 의존하기 때문에 더 많은 소프트웨어 패키지가 필요합니다. 집 아래에 설치되었습니다. 게다가 linuxbrew는 소스 코드에서 소프트웨어를 컴파일하므로 상대적으로 느립니다. 소스 코드 컴파일 대부분의 소프트웨어는 이전 방법을 사용하여 설치할 수 있습니다. 설치되어 있지 않으면 이 소프트웨어를 정말로 설치해야 하는지 스스로에게 물어봐야 합니다. 꼭 필요한 것이 아니라면 설치하지 마세요. 필요한 소프트웨어인 경우 수동으로 컴파일해야 합니다. 일반적인 소스 코드 컴파일에는 일반적으로 다음 단계가 포함됩니다. 물론 구체적인 상황은 사례별로 처리됩니다. tar -xvf xxxx.tgz ./configure --prefix=/opt/xxxx make sudo make install 일반적으로 이러한 유형의 소프트웨어의 기본 설치 디렉터리는 /usr/local이며 최종 파일은 /usr/local의 bin, lib, share 및 man 디렉터리에 배치됩니다. 저는 개인적으로 이 방법을 별로 좋아하지 않습니다. 왜냐하면 소스 코드에서 컴파일된 소프트웨어로서 컴파일러가 소프트웨어를 관리할 의무를 완전히 져야 한다는 것을 의미하기 때문입니다. 이 배치 방법은 업데이트나 제거 시 많은 문제를 야기할 것입니다. 소프트웨어. 그래서 구성할 때 설치 경로를 수동으로 지정하기 위해 항상 접두사를 추가합니다. 소프트웨어를 제거하려면 /opt에서 해당 디렉터리를 삭제하면 됩니다. 업데이트하려면 해당 디렉터리를 먼저 삭제한 다음 다시 컴파일할 수도 있습니다. 이 작업에서 약간 번거로운 점은 소프트웨어의 bin 디렉터리를 PATH에 수동으로 추가해야 하고 LD_LIBRARY_PATH를 수정해야 할 수도 있다는 것입니다. 하지만 일반적으로 소스 코드를 컴파일해야 하는 소프트웨어는 거의 없기 때문에 큰 문제는 발생하지 않습니다. 컴파일 코드 알겠습니다. 사실 제목을 어떻게 정해야 할지 모르겠습니다. . 이전 섹션 "소스 코드 컴파일"은 주로 일부 대규모 소프트웨어 패키지에 중점을 둡니다. 이 섹션 "코드 컴파일"은 일부 고도로 전문적인 소규모 코드 패키지 처리를 나타냅니다. 예를 들어, 일부 소프트웨어 패키지가 컴파일된 후 실제로 필요한 것은 바이너리 파일뿐입니다. 현재로서는 이를 /opt에 설치할 필요가 없습니다. 적절한 방법은 자신의 HOME 아래에 bin 디렉토리를 만들고 해당 패키지를 추가하는 것입니다. .bashrc 경로를 추가한 다음 컴파일된 바이너리 파일을 이 디렉터리에 복사하세요. mkdir ${HOME}/bin echo 'export PATH=${HOME}/bin:$PATH'>> ~/.bashrc 예를 들어, 내 ${HOME}/bin 디렉토리에 다음 파일이 있습니다: distaz: 지구상 두 지점의 경도와 위도를 주고, 진원거리와 방위각을 계산합니다. pssac: GMT로 SAC 파일을 그립니다. rdseed: SEED 형식을 SAC 형식으로 변환 win2sac_32, catwin32: Hi-net 웹사이트에서 제공 Hi-net 데이터 처리 프로그램 st: sublime_text는 /opt 디렉토리에 설치되며 명령줄에서 sublime text 호출을 용이하게 하기 위해 여기에 소프트 링크가 설정됩니다. wlt.pl: 네트워크에 로그인하기 위한 학교 스크립트, 네트워크 수정. fk, fk.pl, syn, trav: Lupei Zhu 교수의 합성 지진계 계산 프로그램입니다. 실제로 필요한 소스 코드는 이 세 개의 실행 파일과 Perl 스크립트뿐입니다. matlab: matlab을 가리키는 소프트 연결 바이너리 파일을 bin에 넣지 마세요. 일반적으로 사용되는 일부 명령이나 매우 일반적인 도구만 여기에 넣어야 합니다. 자체 포함 소프트웨어 여러 모듈이나 패키지로 구성된 소프트웨어 유형이 있습니다. 이렇게 많은 모듈을 관리하려면 자체 모듈/패키지 관리자가 필요합니다. 그 중에는 TeX, Perl, Python이 있습니다. 이러한 유형의 소프트웨어의 경우 수많은 모듈이 가장 큰 장점이자 가장 가치 있는 리소스이므로 일반적으로 다음과 같은 이유로 수동으로 설치하도록 선택합니다. 시스템 소스에 소프트웨어의 모든 모듈이 포함되는 것은 불가능합니다. 시스템 소스의 소프트웨어 모듈 업데이트는 최신 버전보다 훨씬 뒤떨어집니다.
이로 인해 모듈 관리에 혼란이 생길 수 있습니다. 반면, 소프트웨어 자체 패키지 관리를 사용하여 모듈을 설치할 경우 해당 모듈이 설치된 다른 모듈의 최신 버전에 따라 달라질 수 있습니다. 시스템 yum을 통해 모듈 설치에 실패할 수 있습니다. 따라서 이러한 유형의 소프트웨어의 경우 일반적으로 별도로 설치되며 자체 패키지 관리자를 사용하여 모듈을 관리합니다. TeXLive: TeXLive iso 이미지 파일을 통해 설치, 자체 tlmgr 관리 패키지 사용 Perl: plenv를 통해 최신 버전의 Perl 설치, plenv와 함께 제공되는 cpanm을 사용하여 모듈 설치 Python: pyenv를 통해 최신 버전의 Python 설치, Python pip 설치 모듈과 함께 제공되는 것을 사용하세요 예외 규칙에는 항상 예외가 있습니다.
mosquito-myrepo는 중국어 입력 방법, QQ, Fetion, Weizhi Notes, Youdao Dictionary, Baidu Cloud 및 여러 오디오 및 비디오 플레이어를 포함하는 비공개로 유지 관리되는 소스입니다. 나는 이 소스에 대해 애증의 태도를 가지고 있습니다. 이 소스는 중국 사람들에게 필요한 많은 소프트웨어를 제공하지만 EPEL이 아닌 타사 소프트웨어 소스에 의존하기 때문에 패키지 충돌이 발생할 수 있습니다. 따라서 이 소스를 주의해서 사용하세요.
간단한 요약: EPEL 소스, Nux Dextop, ELRepo 소스 및 기타 소규모 타사 소스를 시스템에 추가하세요. 소스에서 설치할 수 있으면 소스에서 설치하세요. rpm 패키지를 찾을 수 없다면, linuxbrew가 수동으로 컴파일할 수 있다면, 수동으로 컴파일하지 마세요
위 내용은 CentOS7 소프트웨어 설치 단계 및 전략에 대한 전체 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
