ksplice 생산이 준비 되었습니까?

프로덕션 환경에서 Ksplice 에 대한 serverfault 커뮤니티의 경험을 듣고 싶습니다 .

Wikipedia의 빠른 설명 :

Ksplice는 Linux 커널의 무료 오픈 소스 확장으로 시스템 관리자는 운영 체제를 재부팅하지 않고도 실행중인 커널에 보안 패치를 적용 할 수 있습니다.

과

Ksplice는 커널을 다시 시작하지 않고도 커널 코드 만 수정하면되는 모든 소스 코드 패치를 적용 할 수 있습니다. 다른 핫 업데이트 시스템과 달리 Ksplice는 통합 된 diff와 원래 커널 소스 코드 만 입력으로 사용하며 추가적인 사람의 도움 없이도 실행중인 커널을 올바르게 업데이트합니다. 또한 Ksplice를 활용하기 위해 시스템을 처음 부팅하기 전에 준비 할 필요가 없습니다 (예 : 실행중인 커널은 특별히 컴파일 할 필요가 없습니다). 업데이트를 생성하려면 Ksplice가 소스 코드 패치에 의해 커널 내에서 어떤 코드가 변경되었는지 확인해야합니다.

몇 가지 질문이 있습니다.

안정성은 어땠습니까? 커널의 '재부트없는 라이브 패치'에서 발생하는 이상한 문제가 있습니까? 커널 패닉이나 공포 이야기?

나는 몇 가지 테스트 시스템에서 그것을 실행 해 왔으며 지금까지 광고 된대로 작동했지만 다른 모든 sysadmins가 Ksplice와 함께 경험 한 내용에 관심이있어서 '올인'하고 프로덕션 서버에 배포하기 전에 Ksplice와 관련했습니다.

생산에 Kspice를 사용하는 사람이 있습니까?

업데이트 : 흠, 몇 시간 후에이 질문에 대한 실제 활동을 보지 못했습니다 (어떤 종류의 공감대와 즐겨 찾기 제외). 아마도 어떤 활동을 시작하기 위해 몇 가지 질문을 더하고이 토론을 진행할 수 있는지 알아볼 것입니다 ...

"Ksplice에 대해 알고 있다면 사용 하지 않는 이유가 있습니까?"

"여전히 입증되지 않았거나 테스트를 거치지 않은 상태라고 생각하십니까?"

"Ksplice가 현재 패치 관리 시스템에 적합하지 않습니까?"

"가동 시간이 길고 안전한 시스템을 원하십니까?" ;-)

(첫째, 면책 조항 : 나는 Ksplice에서 일합니다.)

우리는 당연히 자체 생산 인프라에서 사용하지만 더 중요하게는 500 개 이상의 기업 고객들 (12 월 10 일 기준)도 사용합니다.

한 sysadmin이 Red Hat Enterprise Linux 사용자 메일 링리스트에서 동일한 질문을 했으며, 여러 가지 답변이 있으며 그 중 일부는 아래에서 발췌됩니다.

우리는 12 개월 정도의 호스트에서 몇 달 동안 프로덕션 환경에서 Ksplice를 운영하고 있습니다. 지금까지는 광고 된대로 작동합니다.

과

내 통제하에 500 대가 넘는 기계가 있는데 그 중 445 대가 업 트랙에 연결되어 있습니다 (rhel 4 & 5). 컴퓨터를 재부팅하기 전에 ksplice를 사용하여 몇 가지 루트 악용을 차단했습니다. 우리는 여전히 테스트 중이므로 어쨌든 새로운 커널을 출시했지만 몇 주 동안 문제없이 ksplice'd를 실행했습니다.

사람들이 표현한 한 가지 우려는 안정성이 아니라 기존 감사 및 모니터링 도구와의 통합에 관한 것입니다.

ksplice 사용에 대한 유일한 "gotcha"는 아직 사용 가능한 "ksplice-aware"감사 도구가 없다는 것입니다.

예상 한대로이 영역은 우리가 많이 투자하는 영역입니다.

나는 Ksplice에 대해 들었고 그 당시 좋은 생각이라고 생각했습니다. 가동 중지 시간, 재부팅 없음. 그러나 나는 그것을 조금 더 살펴 보았고 그것을 시도하는 것이 무서워졌습니다.

그것을 피하는 나의 이유는 다음과 같습니다.

• 리눅스 커널은 이미 매우 복잡합니다. Ksplice는 복잡성을 더합니다. 더 많은 복잡성 = 더 많은 실패.

• 고장으로 인해 다운 타임이 길고 비용이 많이 드는 원격 서버에서 Ksplice를 시험해 보는 것은 무모 할 것입니다.

• 필자의 경우 유일한 이점은 가동 시간 통계가 더 높다는 것입니다.

홈 서버에서 Ksplice를 사용하고 있습니다 (가동 시간은 중요하지 않지만 사용하기 편리한 곳임). 전혀 문제가 없었습니다-Apt를 통해 클라이언트에 가끔 업데이트, 커널 업데이트 자체에 아무런 문제가없고 (눈에 띄는) 불안정성이 없습니다.

그러나 일반적인 "YMMV"고지 사항이 적용됩니다! ;-)

Ksplice는 오픈 소스 커널 확장 프로그램이지만 소프트웨어는 무료이며 누구나 사용할 수 있지만 Linux 패치 관리 ( "Ksplice"라고도 함)를 수행하는 회사와 회사가 특별히 개발 한 것임을 명심하십시오. Ksplice (커널 모드)는 커널에 ksplice-usable 패치가있는 경우에만 유용하며 Ksplice (회사)와 지원 계약을 맺지 않는 한 절대로 보지 못할 것입니다.

따라서 ksplice (도구)는 상당히 성숙하지만 패치 관리에 Ksplice (회사)를 사용하려는 경우에만 관련이 있습니다.

좋은 질문. 내 초기 응답의 라인을 따라 뭔가 될 것 "왜 합니까 나는이 필요합니까?"

아마 필요하지 않을 것입니다. 5 분의 9 설정에서도 "예약 된 유지 보수"는 종종 이러한 종류의 다운 타임을 허용하는 SLA의 조항입니다. HA 설정이있는 경우 장애 조치로 전환하고 한 상자에 커널을 설치하고 재부팅 한 후 다른 상자에 반복하십시오. 상자에서 5 분의 가동 중지 시간을 감당할 수없는 경우에도 장애 조치 설정이 필요합니다.

이 기술은 참신한 기술이지만 아직 실용적이지는 않습니다. 물론 커널 보안 업데이트가 필요하며 최대한 빨리 패치해야하지만 새 커널을 설치하고 재부팅하는 것보다 시간 / 노력 / 걱정이 얼마나 절약됩니까? 문제가 발생하면 어떻게합니까? PXE 유형 복구 옵션이 충분하다고 가정하면 시스템을 다시 이미징하여 얼마나 많은 시간을 허비하고 있습니까?

또한 위에서 언급했듯이 이와 같은 기술을 원격으로 실험하면 여러 서버에서 잘못되면 재앙이 될 수 있습니다. 테스트에서 DC와 동일한 하드웨어를 사용하고 있습니까? 한 기계에서 잘 재생되는 것은 다른 기계에서 잘 재생되지 않을 수 있습니다.

그냥 내 $ 0.02.

오래 전이지만 Ksplice가 할 수있는 일은 많이 있습니다 ....

• 가동 중지 시간없이 즉시 패치를 적용 할 수 있으므로 보안이 향상되며, 이는 매우 민감한 환경에서 매우 중요합니다.

• 가동 중지 시간없이 즉시 패치를 적용 할 수 있으므로 안정성이 향상되어 재부팅 할 시간이없는 동안 상황이 개선 될 수 있습니다.

• 다운 타임없이 즉시 패치 적용이 가능하여 필요한 작업에 필요한 기능 만 적용함으로써 성능이 향상되었습니다.

• 다운 타임없이 즉시 패치를 적용 할 수있어 사전 대응 성이 향상되어 새로운 팜에 대한 테스트 팜을 설정하는 것은 물론 이전 상태로 쉽게 되돌릴 수 있습니다.