프로덕션 서버 (메일, 웹, 데이터베이스는 모두 하나의 서버에 있음)와 테스트 서버를 모두 관리해야합니다. 둘 다 데비안을 기반으로합니다. 그러나 시스템 관리를 처음 접했을 때 최신 기능을 사용하고 버그를 수정하기 위해 업데이트해야 할 사항을 발견했을 때만 업데이트를 설치했습니다. 지금은 매우 특별한 프로세스이며, 덜 덜하고 싶습니다.
그래서 나는 그들이 무엇을하고 있는지 아는 사람들이 이것을 어떻게 처리하는지 궁금합니다. 서버에서 얼마나 자주 업그레이드를 수행합니까? 테스트와 프로덕션간에 업그레이드 프로세스가 다른가요? 항상 테스트 서버를 먼저 업그레이드합니까? 그리고 모든 소프트웨어의 전체 업데이트를 수행합니까, 아니면 선택한 업데이트 만 설치합니까?
답변
apt-get update -qq를 실행합니다 . apt-get upgrade -duyq 매일. 업데이트를 확인하지만 자동으로 업데이트하지는 않습니다.
그런 다음보고있는 동안 업그레이드를 수동으로 실행하고 잘못 될 수있는 모든 사항을 수정할 수 있습니다.
패치 된 시스템을 유지 관리하는 데 대한 보안 문제 외에도 패치 사이에 시스템을 너무 오래두면 업그레이드하려는 패키지 가 많아 져서 업그레이드하거나 업그레이드하는 것보다 더 많은 것을 두려워합니다. 매주 2 번 정도 요 따라서 업그레이드를 매주 또는 우선 순위가 높은 경우 매일 업그레이드하는 경향이 있습니다. 이것은 어떤 패키지가 시스템을 고장 났는지 아는 추가적인 이점이 있습니다 (예 : 한 번에 한 쌍만 업그레이드하는 경우)
항상 덜 중요한 시스템을 먼저 업그레이드합니다. 시스템을 고칠 수없는 경우를 대비하여 “롤백 계획”도 있습니다. (대부분의 서버가 가상이기 때문에이 롤백 계획은 일반적으로 업그레이드 전에 스냅 샷 을 작성하여 필요한 경우 되돌릴 수 있음)
즉, 지난 4 년 동안 업그레이드가 한두 번만 고장 났으며 고도로 맞춤화 된 시스템에 있다고 생각합니다. 따라서 너무 편집증이 될 필요는 없습니다. 🙂
답변
이전 답변 외에도 몇 가지 구체적으로 데비안 관련 사항 : debian-security-announce 및 debian-announce를 구독 하거나 데비안 보안 페이지를 확인 하십시오 .
답변
데비안의 안정된 릴리스를 실행한다고 가정하면, 대부분의 패치는 보안 또는 버그와 관련이 있으므로 특정 패키지의 버전간에 큰 변화가 없을 것입니다. 데비안 패치 정책에 따르면 패치는 또한 관리자에 의해 안정적인 지점으로 이동하기 전에 일정 시간 동안 테스트 중이어야합니다. 분명히 이것은 패치 할 때 파손을 멈추지 않지만 대부분의 경우 파손을 방지해야합니다.
테스트 서버를 최신 상태로 유지하고 사용자와 서버에 영향을 미치는 버그가있는 패키지는 최신 상태로 유지해야합니다. 패치가 안정적임을 알면 보안 권고가있는 모든 패키지를 업데이트해야합니다.
데비안은 일반적으로 매우 안정적인 OS이며, 파손에 대해 지나치게 염려해야 할 것은 아니지만 업데이트되기 전에 항상 업데이트 될 내용을 읽고 이상한 것으로 보이는 것을 주시하십시오. / etc / dir에서 VCS를 사용하여 ‘git diff’명령으로 구성 파일 변경 사항을 볼 수 있습니다.
답변
나는 무엇을 업데이트 할 것인지보기 위해 드라이 런 (먼저)을한다. 때로는 라이브러리 (이 예제에서는 libfoo라고 함)가 API를 변경하여 직접 작성하거나 설치 한 프로그램을 중단시킵니다. 중요한 라이브러리가 업데이트되면 소스를 가져 와서 업데이트하기 전에 소스를 다시 작성하십시오.
또한 우리가 아파치 등과 같은 일부 공공 서비스의 중간 버전으로 점프하지 않는지 확인합니다. 업데이트가 중요하지 않은 한 1 년 뒤에 머물러 있고 임의의 손상이 발생하지 않습니다.
시스템 관리자 인 경우 Secunia 와 같은 사이트에서 RSS 피드를 가져와야 합니다. 그러면 배포판에서 일부 패치를 적용 할 예정인지 미리 알려야합니다.
맹목적으로 업그레이드 / 업데이트하지 마십시오. 불행히도, 시스템이 프로그래머를 지원하는 경우 배포판 패키지 관리자가 아닌 깨진 부분을 아는 작업이 당신에게 달려 있습니다.
답변
내가 일하는 곳에서는 PatchLink라는 소프트웨어를 사용하여 가장 중요한 보안 관련 업데이트를 알려주고 테스트 후 패키지별로 적용하는 매우 광범위한 프로세스가 있습니다. 그래도 수천 대의 서버가 있습니다.
서버가 두 대 뿐인 경우 프로세스가 훨씬 간단해야합니다. “apt-get update / upgrade”를하는 것이 최선의 방법이라고 생각하지는 않습니다.
실행중인 소프트웨어에 대한 패치를 모니터링하고 업그레이드시기에 대한 해당 릴리스의 수정 사항에 따라 결정합니다.
테스트 서버가 있으므로 반드시 업데이트를 적용하기 전에 항상 테스트하십시오.
답변
수동 업데이트는 현재 상황을 확인할 수 있다는 점에서 여기에 언급 된대로 가장 좋습니다. 그러나 실용적이지 않을 수있는 매우 많은 서버의 경우. 드라 이런은 표준 관행이며, 사실 대부분의 패키지 관리자가 진행하기 전에 물어볼 것입니다.
약간의 균형 조정 작업이 될 수 있지만 정기적으로 업데이트하는 것이 가장 좋습니다. 빈번한 업데이트는 한 번에 적은 수와 한 번에 잘못되는 수가 적음을 의미합니다. 문제가 발생하면 조사 할 후보자가 적습니다. 패키지는 작은 단계로 업데이트하는 데 약간 더 좋습니다. 일반적으로 프로그래머가 마지막 버전에서 다음 버전으로 갈 때 업데이트 할 때 마지막 버전 이후에주의를 기울 일지 여부는 다양 할 수 있습니다. 대부분 빠르게 진화하는 소프트웨어에 적합합니다.
모든 업데이트가 중단되지는 않습니다. 이것을 조심해야 할 것입니다. 일부는 다운 타임을 초래하는 서비스를 다시 시작합니다.
이상적인 설정에서는 다음이있을 수 있습니다.
- 겉보기에는 서버를 전환하는 수단 (A / B 또는 틱톡). 즉, 벤치에있는 동안 업데이트 한 다음 현재 트래픽을 새 트래픽으로 간단히 전환하면됩니다. 데이터베이스와 같은 서비스에서는 더 복잡 할 수 있습니다.
- 업데이트 테스트 기능. 실제로 프로덕션 복제 본인 테스트 서버가 있어야하지만 프로덕션 서비스에 연결하지 않아도됩니다. 업데이트를 먼저 테스트 할 수 있습니다.
- 좋은 백업 전략, 증분이 이상적입니다. 당신은 몰라요 항상 미안보다 안전하는 것이 좋습니다.
- 가장 활동적인 시간과 허용 가능한 다운 타임 레벨을 알고 있어야합니다.
- 업데이트 또는 특정 패키지를 롤백하는 방법을 알고 있어야합니다.
- 서버간에 업데이트가 일관되고 예측 가능하도록 자체 패키지 미러를 사용하십시오. 이것은 신뢰할 수있는 적절한 무인 시스템을 향한 첫 번째 단계입니다. 즉, 미러를 업데이트하고 하나 이상의 테스트 시스템에서 업데이트를 실행 한 다음 자동으로 내보내도록 할 수 있습니다. 나는 약 800 대의 EPOS 기계를 적절하게 관리하면서 훌륭한 시간을 보냈습니다.
- 일관된 수준의 일관성을 통해 여기에서 무언가가 작동하면 작동 할 것임을 알 수 있습니다.
이들 중 일부는 소규모 설정의 경우 다양한 정도로 과도 할 수 있지만 명심해야합니다.
일반적으로 업데이트는 일반적으로 서버 배포판에서 비교적 고통스럽지 않습니다. 거의 항상 버그 수정 및 보안 업데이트 만 고수하기 때문입니다. 그러나 사람들이 시스템에 이상한 일을하거나 추가 패키지 소스를 추가하면 문제가 발생할 수 있습니다.
비록 드물기는하지만 때때로 실수를하여 마이너 패키지 버전 사이의 호환성을 손상시킵니다.
답변
나는이 프로세스를 자동화하기 위해 cron-apt를 좋아하지만 @dinomite가 업데이트에 관한 또 다른 질문을 지적했듯이 보안 관련 업데이트를 자동화하도록 특별히 구성하는 것은 매우 현명한 아이디어입니다. 그러면 필요한 것을 수동으로 업데이트 할 수 있습니다. 나는 모든 업데이트에 cron-apt를 사용했지만 실제로 그의 대답에 따라 이것을 변경했습니다. 당신이 그것을 좋아한다면, 아마도 이것보다 그의 대답에 투표 해야 할 것입니다 .