m 업데이트? 아님?

이 간단한 질문을 용서하십시오.

우선, 나는 sysadmin이 아니며 Linux에 대한 나의 경험은 다소 제한적입니다.

약 3-4 개월 전에 다양한 이유로 CentOS 서버를 설치했습니다. 우리는 웹 사이트 (고객이 액세스 할 수있는), 서브 버전 서버를위한 개발 서버로 사용하고 있으며 내부 통신을 위해 위키를 호스팅하고 있기 때문에 우리에게 매우 중요한 도구가되었습니다. (아마도 내가 설정할 때 생각했던 것보다 더 중요합니다!)

Yum은 약 250 개의 패키지를 저장소의 최신 버전으로 업데이트하려고합니다.

서버가 제대로 작동하므로 이러한 패키지를 업데이트 할 위험이 있습니까? 모든 것을 업데이트 할 때 보안 위험이 서버 중단 위험보다 중요합니까?

나는 모든 것을 백업하는 동안 모든 것을 지금 당장 설정하는 데 시간이 걸리고, 현재 직장에서 많은 자유 시간이 없다는 것을 지적해야합니다!

조언을 업데이트해야한다면 프로세스를 최대한 안전하게 만들기 위해 전달할 수있는 모범 사례가 있습니까?

조언을 미리 주셔서 감사합니다.

업데이트-귀하의 답변에 감사드립니다. 내가 모든 사람을 찬성하기 위해 충분한 담당자를 가지고 있다면, 그렇게 할 것입니다. ;) 하드 드라이브를 고스트하고 업데이트하기로 결정했습니다. 불행히도, 전체 또는 파트 타임 sysadmin을 얻는 것은 현재 선택 사항이 아니므로 가능한 한 문제를 처리해야합니다!

빠르고 더러운 (즉, Battlefield Administrator) 솔루션 :

1. 시스템을 오프라인 상태로 만들고 (가능한 경우) NortonGhost 백업 (또는 이와 유사한 것)을 두 번째 하드 드라이브에 수행하십시오.

2. 두 번째 하드 드라이브를 부팅하고 (백업이 실제로 작동하는지 확인) THAT 드라이브에서 yum 업데이트를 수행하십시오.

3. 모두 작동한다면 ... 축하합니다!

4. 무언가를 조이는 경우 ... 계속 진행하여 ORIGINAL 드라이브에 "Blan B"계획을 세우십시오.

최신 정보:

여기서 실제 문제는 "내 구식 시스템을 업데이트하여 엉망으로 만들 위험이 있습니까?"라고 언급 한 것 같습니다. 또는 "완전히 잘 작동하는 시스템을 패치하지 않고 해킹 / 손상 위험이 있습니까?"

대답은 ... 일단 위의 단계를 통해 시스템을 패치하면 ... 자주 백업하고 자주 패치하여 시스템을 최신 상태로 유지하십시오.

그럼 당신은 두 세계의 최고를 얻을 것입니다. ;-)

예, 업데이트하십시오.

RHEL (및 CentOS)은 호환되지 않는 버전으로 버전을 업데이트하지 않도록주의하고 대신 버그 수정 및 보안 수정 사항을 백 포트하므로 패키지의 실제 변경 사항은 최소화되며 호환성 문제가 발생할 가능성은 거의 없습니다.

구성 파일이 변경된 경우 패키지는 생성되는 .rpmorig 또는 .rpmnew 파일에 대해 알려줍니다. RPM 자체의 구성에 따라 다릅니다. 작성중인 구성 요소에 대한 경고를 찾고 이전 구성 ( " cp foo foo.bak; cp foo.rpmorig foo")을 다시 넣거나 .rpmnew 파일을보고 구성에 변경 사항을 통합 할 수 있습니다.

정기적으로 업데이트하면 문제가 눈에 띄지 않습니다.

분기마다 (3 개월마다) 업데이트되는 많은 시스템이 있습니다. 패키지 업데이트로 인한 문제는 거의 없습니다. (이상한 커널 작업을 수행하여 SAN에서 LUN에 액세스하는 시스템은 제외)

예, 업그레이드하는 데 시간이 걸리고 같은 매너에서 문제가 발생한 경우 복원하는 데 시간이 걸립니다. 해당 시스템의 데이터가 익스플로잇 / 해킹을 통해 삭제 된 경우 얼마나 고통 스럽습니까?

CentOS 기본 리포지토리에서 대부분의 업그레이드를 설치해도 안전합니다. CentOS에 대한 업데이트 문제가 발생한 유일한 시간은 외부 리포지토리 (DAG, RPMForge, 요법 등)를 시작하거나 사용해야 할 때입니다.

최고의 당신이 라이브 서버에 배포하기 전에의 업데이트를 테스트 할 수 있도록 이런 종류의 일에 대한 설치, 핫 스왑 서버가 준비하는 것입니다.

실제 시스템 관리자가 시스템을 살펴보고 업데이트하고 모든 것이 다시 실행되도록하는 데 몇 시간이 걸리는 것처럼 들립니다. 이상적으로는,이 사람이 와서 한 달에 몇 번이 일을하게 할 것입니다. 서버는 하지 것을 잊지-에 대해 - 그것 한 번 설치 - 및 -; 정기적 인 서비스가 필요합니다.

이 시스템이 매우 중요한 경우 보안 업데이트가 더욱 중요해집니다. 오래된 패키지로 인해 시스템이 손상 될 수있는 경우 재 구축을 위해 해당 시스템을 중단해야 할 경우의 영향을 고려하십시오. 이상적으로, 먼저 업데이트 할 수있는 것과 비슷한 방식으로 테스트 서버를 구성하고 고장이 있는지 확인하십시오.

업데이트를 적용 할 때는 몇 가지 사항을 확인해야합니다.

1. 업데이트 시간은 시스템을 사용하는 모든 사람에게 공개됩니다
2. 각 응용 프로그램을 업데이트하고 테스트하는 방법에 대한 계획이 있습니다.
3. 업데이트로 인해 앱이 중단되는 경우 업데이트를 실행 취소하는 방법에 대한 계획이 있습니다.
4. 그리고 실제로 문제가 발생할 경우를 대비하여 현재 백업이 존재합니다.

좋은 sysadmin은 이런 종류의 작업에 경험이있을 것입니다. 조직에 시스템이 있으면 시스템 관리를 덤프해야 할 때입니다. 또는 스스로이 일을하는 것이 불안하다면, 이런 종류의 일상적인 유지 보수를 위해 계약직 직원을 고용하십시오. 어느 쪽이든, 당신은 훨씬 더 나쁜 상황에 처해 있기 때문에 업데이트 가 필요 합니다.

이것이 오늘날 실제 하드웨어에서 프로덕션 시스템을 거의 실행하지 않는 이유입니다. 가상 머신에서 실행합니다. 그런 다음 짧은 다운 타임 (5 분) 동안 ESX 자체에서 스냅 샷을 실행하거나 사용자 정의 Xen / Solaris / OpenVZ 설정을 사용하는 경우 서버 이미지의 LVM 스냅 샷을 수행합니다. 그런 다음 원래 백업을 부팅하면 원하는대로 사본을 만들 수 있습니다.

즉, 커널을 업데이트하고 아파치를 시작한 다음 거꾸로 작업하십시오. yum이보고하는 전체 패키지 목록을 취할 필요는 없지만 가장 빠른 공격 경로는 가장 빠른 패치입니다.

리눅스 시스템이 해킹 당했을 때마다 아파치, openssh 또는 커널 자체가 패치되지 않았기 때문입니다.

보안 관련 패키지 만 업데이트하겠습니다.

1 년 전쯤에 그와 같은 일이 일어났습니다. CentOS 상자에서 yum 업데이트를했으며 Dell 하드웨어에서 실행되었으며 부팅되지 않는 커널을 설치했습니다. 상자에 아직 아무것도 적재되지 않았습니다 (그렇지 않으면 더 조심해야합니다). 많은 시간을 보냈는데 CentOS / Linux 최신 커널과 Dell 상자 사이에 약간의 비 호환성이있는 것 같습니다. 업데이트에 매우주의하십시오. 나는 그것이 옳은 일이기 때문에 여전히 업데이트를 권장하지만, 휴지통 시스템에서 복구 할 준비를하십시오!