우리는 무료/오픈 소스 프로젝트입니다. 웹사이트와 위키용으로 CentOS 7 x86_64 VM을 임대합니다. 우리는 가상 머신을 완전히 패치했습니다. 우리는 yum update최신 장비가 있는지 확인하기 위해 일주일에 한 번씩 로그인하고 실행합니다 .
배포판이 오래됨에 따라 일부 패키지가 문제를 일으키기 시작합니다. 예를 들어 PHP 버전은 5.4이고,2015년에 중단됨:
$ php --version
PHP 5.4.16 (cli) (built: Nov 15 2017 16:33:54)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
with XCache v3.1.1, Copyright (c) 2005-2014, by mOo
with XCache Optimizer v3.1.1, Copyright (c) 2005-2014, by mOo
with XCache Cacher v3.1.1, Copyright (c) 2005-2014, by mOo
with XCache Coverager v3.1.1, Copyright (c) 2005-2014, by mOo
PHP를 다운그레이드한다는 것은 동반 MediaWiki 소프트웨어가 더 이상 유지 관리되지 않음을 의미합니다. 우리는 MediaWiki 1.26에 갇혀있습니다.
~에 따르면CentOS 7에서 지원되는 최고 PHP 버전가능성 중 하나는 타사 저장소를 활성화하는 것입니다. 추가 저장소를 활성화하는 데 동의하지만 외국 저장소를 활성화하는 것은 마음에 들지 않습니다.
~에 따르면CentOS FAQCentOS는 Red Hat 소스 코드를 기반으로 구축된 Red Hat 커뮤니티 개발 플랫폼입니다. RHEL이 고객에게 더 이상 사용되지 않는 소프트웨어만을 제공하는지 심각하게 의심됩니다.
CentOS 위키에 따르면추가 리소스 |활성화할 수 있는 CentOS-Plus 저장소가 있습니다. 나레포를 확인했습니다그리고 업데이트된 PHP가 없습니다.
첫 번째 질문은 왜 CentOS를 사용하는가입니다.아니요업데이트된 PHP를 사용할 수 있나요?
두 번째 질문은 '우리에게는 항상 신뢰가 필요한가'입니다.<일부 임의 소스>CentOS를 사용할 때?
세 번째 질문은 파트타임 시스템 관리자가 타사 저장소를 피할 수 있는 실행 가능한 전략이 있습니까?입니다.
질문 (1)은 우리 경우의 예시 질문입니다. 다른 사람들도 다른 CentOS 소프트웨어에서 동일한 문제를 겪은 것 같습니다.
질문 (2)는 장기 계획입니다. CentOS가 시간이 지남에 따라 지속적으로 이 문제를 발생시키는 경우 다른 배포판을 찾아야 하는지 평가해야 합니다.
질문 (3)은 주로 (a) 최신 소프트웨어 및 (b) 신뢰할 수 있는 소스 및 저장소에 관한 것입니다. 추가 구성 작업은 괜찮지만 최소한으로 유지하고 싶습니다. 우리는 신뢰할 수 없는 출처를 피하고 싶습니다.
더 큰 그림을 보면 뭔가 [명백한] 것을 놓치고 있는 것 같은 느낌이 들었습니다. 하지만 지금은 그게 뭔지 모르겠어요.
답변1
첫 번째 질문은 CentOS가 업데이트된 PHP를 제공하지 않는 이유는 무엇입니까?
이는 Red Hat의 결정입니다. 이는 그들이 제공하는 내용이 이전 버전에 의존하기 때문일 가능성이 높습니다. 그러나 이에 대한 증거를 찾을 수 없습니다.
최신 PHP가 필요한 경우 다음과 같은 수많은 리소스를 사용할 수 있습니다.자궁내 피임 시스템심지어SCLCentOS에서 제공합니다. IUS는 기존 패키지를 덮어쓰지 않지만 먼저 패키지에 있는 모든 항목을 제거해야 합니다(php 측). CentOS 6에서 Python 2.7과 함께 IUS를 사용하고 있으므로 솔트를 올바르게 설치할 수 있습니다.
참고: 안정성 관점에서 Red Hat은 배포판에 포함될 패키지와 버전을 궁극적으로 결정합니다. CentOS는 소스 코드를 가져와 CentOS로 다시 빌드합니다.
우리는 항상 신뢰해야 합니까?임의의 소스CentOS를 사용할 때?
불필요한. 세상에는 좋은 저장소와 나쁜 저장소가 많이 있습니다. 실제로 일부 사람들은 기본 저장소에 쉽게 의존할 수 있습니다.
그것은 실제로 귀하의 필요에 달려 있습니다. 가다이 페이지는 여기입니다커뮤니티에서 승인한 저장소를 확인하세요. 이 페이지에 나열된 모든 저장소는 승인되었으며신뢰할 수 있다.
파트타임 시스템 관리자가 타사 저장소를 피할 수 있는 실행 가능한 전략이 있습니까?
최선의 전략은 사용자나 회사의 사용 사례에 따라 다릅니다. 특정 사용 사례에는 타사 저장소가 필요합니다. 특히 MediaWiki를 더 높은 버전으로 업그레이드할 수 없는 경우에는 선택의 여지가 없습니다. 이전 답변에서 지적했듯이 일부 사람들은 기본 저장소를 사용하여 벗어날 수 있습니다. 어떤 사람들은 EPEL만 사용하기도 합니다. 다시 말하지만 이는 사용 사례와 실행 또는 유지 관리하는 항목에 따라 다릅니다. 예를 들어 EPEL 또는 IUS에서 제공되는 모든 콘텐츠는 일반적으로 배포 기반에서 제공되는 콘텐츠만큼 유지 관리되고 안정적이며 안전합니다.
그래도 가보시길 추천드려요여기커뮤니티가 승인한 저장소의 경우.
답변2
배포판이 오래됨에 따라 일부 패키지가 문제를 일으키기 시작합니다. 예를 들어 PHP 버전은 5.4이며 2015년에 수명 주기가 종료되었습니다.
예, 하지만 보안 패치는백포트. 최신 버전의 PHP로 업그레이드해야 하는 유일한 실제 이유는 언어 기능이나 응용 프로그램에 필요한 경우 보안(또는 기타 배포판별) 패치를 놓칠 수 있기 때문입니다.
우리는 무료/오픈 소스 프로젝트입니다. 웹사이트와 위키용으로 CentOS 7 x86_64 VM을 임대합니다. 우리는 가상 머신을 완전히 패치했습니다.
이것이 정말로 필요한가? 저렴한 솔루션은 Github Pages로 웹사이트를 호스팅하고 Github를 위키로 사용하거나 Sphinx와 같은 정적 웹 페이지 생성기를 사용하는 것입니다. 한 단계 더 나아가고 싶다면 Cloudflare를 사용하여 GH Pages 사이트를 가리킬 수 있습니다. 아래 질문에 대한 답변을 확인하세요.비영리 단체를 위한 해킹 방지 호스팅 솔루션이 있습니까?이에 대한 추가 정보.
이점:
완전 무료
MediaWiki 구문 대신 더 간단한 언어(마크다운/재구조화된 텍스트)
서버 측 작업을 처리할 필요가 없으므로 유지 관리가 더 간단합니다.
이는 많은 오픈 소스 프로젝트(예: readthedocs.org)에서 이미 사용하고 있는 솔루션이므로 진입 장벽을 낮추고 Github에서 수많은 예제를 찾아보세요.
서버 측 기술을 실행하지 않으면 공격 표면이 크게 줄어듭니다. 공격자는 Github 페이지를 활용해야 하며 Cloudflare는 적절한 보호를 제공하는 반면 DIY의 경우 가상 머신을 강화하는 모든 노력을 기울여야 합니다.