매일 밤 apt-get 업데이트를 실행하는 것이 안전합니까?

apt-get update -y프로덕션 서버에서 cron 을 실행하는 것이 안전 합니까?

안전 할 수도 있고,보다 정확하게는 위험 수준이 편안 범위 내에있을 수도 있습니다. 수용 가능한 위험 수준은 몇 가지 요인에 따라 다릅니다.

문제가 발생했을 때 신속하게 되돌릴 수있는 좋은 백업 시스템이 있습니까?

서버 로그 오프를 원격 시스템에 전달하여 상자가 엉망이 되어도 여전히 무슨 일이 있었는지 알 수 있습니까?

문제가 생겼을 가능성을 기꺼이 받아들이고 있으며 무언가 실패한 경우 시스템에서 빠른 복원 / 복원을 수행해야합니까?

직접 수동으로 컴파일했거나 시스템에 설치된 모든 것이 공식 저장소에서 온 것입니까? 로컬로 무언가를 설치 한 경우 업스트림 변경으로 인해 로컬 유지 관리 / 설치 소프트웨어가 손상 될 수 있습니다.

이 시스템의 역할은 무엇입니까? 2 차 DNS 서버와 같이 사망하거나 간신히 놓친 것이거나 인프라 (예 : LDAP 서버 또는 1 차 파일 서버)의 핵심 부분입니까?

서버를 담당하는 사람이 보안 패치를 유지할 시간이 없기 때문에이 설정을 원하십니까? 패치되지 않은 취약성으로 인해 손상 될 수있는 잠재적 위험은 나쁜 업데이트 가능성보다 높을 수 있습니다.

당신이 정말로 이것을하고 싶다고 생각한다면, 나는 이미이 목적을 위해 이미 존재하는 도구 중 하나를 사용하는 것이 좋습니다 cron-apt. 그들은 단지 눈먼 사람보다 안전 할 논리가 있습니다 apt-get -y update.

예, 업 그레 이드가 아닌 업데이트 에 대해 이야기하는 한 . 당신이 라인을 넣으면 Apt는 당신을 위해 그것을 할 것입니다 :

APT::Periodic::Update-Package-Lists "1";

아래 파일에 /etc/apt/apt.conf.d/

일반적으로 안전하지만 간단한 이유로 권장하지는 않습니다.

• 알려진 상태를 잃습니다.

프로덕션 환경에서는 그 위에 무엇이 있거나 무엇이 있어야하는지 정확히 알고 있어야하며 해당 상태를 쉽게 재현 할 수 있어야합니다.

모든 변경 사항은 변경 관리 프로세스를 통해 수행해야합니다. 변경 관리 프로세스는 회사가 진행중인 작업을 완전히 인식하여 나중에 무엇이 잘못되었는지 분석 할 수 있습니다.

야간 업데이트는 이러한 종류의 분석을 불가능하게하거나 어렵게 만듭니다.

안정적인 또는 우분투에서 할 수 있지만 불안정한 지점이나 테스트 지점에서는 할 수 없습니다.

sysadmin 모자를 착용하면 서버 간의 일관성을 유지할 수 있도록 모든 업데이트를 수동으로 적용해야한다고 생각합니다. 또한 하루 동안 서비스가 중단되면 마지막으로 업데이트 한 시간을 알 수 있습니다. 서비스. 업데이트가 자동으로 진행되고 있는지 확인하지 못할 수도 있습니다.

우리는 대부분의 데비안 시스템 (Microsoft "패치 화요일"업데이트와 함께 제공됨)에서 화요일 저녁 안정 및 일정 apt-get 업그레이드를 사용합니다. 잘 작동합니다. 또한 모든 업그레이드 이벤트가 Nagios에 기록되므로 모든 서버에서 업그레이드가 마지막으로 수행 된 기록을 볼 수 있습니다.

이것이 "프로덕션"서버임을 지정하면 개발 및 테스트 서버도 있다는 의미입니까? 그러한 경우 프로덕션 시스템에 설치하기 전에 해당 시스템에서 패치를 테스트해야합니다.

나는 그것을하지 않을 것입니다. 나쁜 패치가 발생하고 한밤중에 또는 다른 방법으로 사용할 수없는 동안 시스템이 실패하는 것을 원하지 않습니다. 관리자가 업데이트를 모니터링 할 수있는 경우 유지 관리 기간에 푸시해야합니다.

전 직장에서 그 일을했던 것을 기억합니다. 업데이트가 구성 파일을 자동으로 다시 작성했기 때문에 프로덕션 서버에서 문제가 발생했습니다.

따라서 업데이트를 감독하는 것이 좋습니다.

대안이 업데이트를 불규칙적으로 적용하는 경우 보안 업데이트를 적극적으로 따르지 않고 바닐라 안정적인 Lenny를 실행하는 경우 자동 업데이트는 알려진 보안 허점을 더 빨리 업데이트하므로 시스템의 보안을 향상시킬 수 있습니다.

Ubuntu Server에는 보안 업데이트를 자동으로 업데이트 할 수있는 패키지가 있습니다. 특정 앱을 블랙리스트에 올릴 수도 있습니다. 또한 서버에 사용 가능한 업데이트가있을 때 이메일을 보내는 apticron에 대해서도 설명합니다.

실행중인 Ubuntu 서버 버전에 따라 다음 페이지에서 자세한 내용을 확인할 수 있습니다.

• 8.10
• 9.04
• 9.10

편집 : 당신이 우분투를 실행한다고 가정합니다. 비록 데비안에서 동일한 패키지와 솔루션을 사용할 수 있습니다.

cron-apt를보십시오. 기본적으로 목록과 패키지 파일 만 다운로드하지만 메일을 보내거나 시스템을 업그레이드하도록 조정할 수 있습니다.

인프라에 따라 다릅니다. 단일 컴퓨터가있는 경우 일반적으로 업데이트를 검토하고 필요한 내용이나 피할 수있는 내용을 확인합니다. 클러스터를 사용하는 경우 한 시스템에서 변경 사항을 롤아웃하고 변경 사항을 확인한 다음 모든 것이 정상인 경우 다른 시스템으로 롤아웃합니다.

데이터베이스 업그레이드 필자는 항상주의를 기울입니다.

스냅 샷을 지원하는 파일 시스템이있는 경우 시스템 스냅 샷을 작성하고 업데이트를 적용한 다음 끔찍한 일이 발생할 경우 변경 사항을 롤백 할 수 있습니다.

패키지가 업그레이드되는 이유를 찾으십니까? 버그 수정입니까? 보안 수정? 로컬 명령입니까 아니면 원격 네트워크 서비스입니까? 소프트웨어가 새로운 업데이트로 테스트 되었습니까?

보다 신중하게 커널 업데이트에 접근해야합니다. 커널이 왜 업그레이드되고 있는지 알아보십시오. 정말로 그러한 변화가 필요합니까? 응용 프로그램에 영향을 미칩니다. 보안을 위해 이것을 적용해야합니까?

10 번의 소프트웨어 업데이트 중 9 번이 원활하게 진행되지만 드문 경우이지만 컴퓨터를 정크 파일로 남겨 두거나 롤백 또는 시스템 복구 계획을 세우는 경우는 드 rare니다.