ผลิต ksplice พร้อมหรือยัง

ฉันสนใจที่จะรับฟังประสบการณ์ของชุมชน serverfault กับKspliceในการผลิต

ประกาศอย่างรวดเร็วจากวิกิพีเดีย:

Ksplice เป็นส่วนขยายโอเพ่นซอร์สฟรีของเคอร์เนล Linux ซึ่งช่วยให้ผู้ดูแลระบบใช้แพตช์รักษาความปลอดภัยกับเคอร์เนลที่กำลังรันอยู่โดยไม่ต้องรีบูตระบบปฏิบัติการ

และ

Ksplice สามารถโดยไม่ต้องรีสตาร์ทเคอร์เนลใช้แพตช์โค้ดใด ๆ ที่ต้องการแก้ไขโค้ดเคอร์เนลเท่านั้น แตกต่างจากระบบอัพเดทฮอตอื่น ๆ Ksplice ใช้เป็นอินพุตเพียงส่วนต่างแบบรวมและซอร์สโค้ดเคอร์เนลดั้งเดิมและอัพเดตเคอร์เนลที่รันอยู่อย่างถูกต้องโดยไม่ต้องการความช่วยเหลือจากมนุษย์เพิ่มเติม นอกจากนี้การใช้ประโยชน์จาก Ksplice ไม่จำเป็นต้องมีการเตรียมการใด ๆ ก่อนที่ระบบจะถูกบูตในตอนแรก (เคอร์เนลที่ทำงานอยู่ไม่จำเป็นต้องได้รับการรวบรวมเป็นพิเศษเช่น) ในการสร้างการอัปเดต Ksplice ต้องกำหนดรหัสภายในเคอร์เนลที่มีการเปลี่ยนแปลงโดยแพทช์รหัสที่มา

ดังนั้นคำถามสองสามข้อ:

ความเสถียรเป็นอย่างไร? มีปัญหาแปลก ๆ อะไรบ้างที่คุณพบกับ 'rebootless live patching' ของเคอร์เนล? เคอร์เนลตกใจหรือเรื่องราวสยองขวัญ?

ฉันใช้มันในระบบทดสอบไม่กี่ครั้งและจนถึงตอนนี้มันทำงานได้ตามที่โฆษณาไว้ แต่ฉันสนใจในสิ่งที่ซิสดมินส์อื่น ๆ เคยใช้กับ Ksplice ก่อนที่จะ 'เข้า' และปรับใช้เซิร์ฟเวอร์การผลิตของเรา

ดังนั้นใครก็ตามที่ใช้ Kspice ในการผลิต

อัปเดต:อืมไม่เห็นกิจกรรมจริงในคำถามนี้หลังจากผ่านไปสองสามชั่วโมง (นอกเหนือจาก upvotes และ favs บางประเภท) อาจจะจุดประกายกิจกรรมบางอย่างฉันจะถามคำถามอีกสองสามข้อและดูว่าเราจะทำให้การสนทนานี้ดำเนินต่อไป ...

"หากคุณรู้ Ksplice มีเหตุผลที่คุณไม่ได้ใช้หรือไม่"

"คุณรู้สึกว่ามันยังมีเลือดไหลออกมามากเกินไปไม่ผ่านการพิสูจน์หรือยังไม่ทดลอง?"

"Ksplice ไม่เหมาะสมกับระบบจัดการแพทช์ในปัจจุบันของคุณหรือไม่"

"คุณเกลียดการมีระบบที่มีความปลอดภัย (และปลอดภัย) เป็นเวลานานหรือไม่?" ;-)

(ข้อแรกข้อจำกัดความรับผิดชอบ: ฉันทำงานให้ Ksplice)

เราใช้มันในโครงสร้างพื้นฐานการผลิตของเราเอง แต่ที่สำคัญกว่านั้นคือลูกค้าองค์กรของเรามากกว่า 500 ราย (จำนวน ณ วันที่ 10 ธ.ค. 53)

ผู้ดูแลระบบคนหนึ่งถามคำถามเดียวกันในรายชื่อผู้รับจดหมายของ Red Hat Enterprise Linuxและพบกับคำตอบจำนวนหนึ่งซึ่งบางส่วนถูกคัดลอกมาด้านล่าง:

เราใช้งาน Ksplice ในการผลิตเป็นเวลาสองสามเดือนกับโฮสต์ประมาณโหล จนถึงตอนนี้ทำงานตามที่โฆษณาไว้

และ

ฉันมีเครื่องจักรมากกว่า 500 เครื่องภายใต้การควบคุมของฉันประมาณ 445 เครื่องเชื่อมต่อกับ uptrack (rhel 4 & 5) เราใช้ ksplice เพื่อบล็อกการหาช่องโหว่เล็กน้อยก่อนที่เราจะมีโอกาสรีบูตเครื่อง เนื่องจากเรายังคงทำการทดสอบเราจึงได้เปิดตัวเคอร์เนลใหม่ แต่ฉันก็ใช้งานได้หลายสัปดาห์ที่ ksplice ไม่มีปัญหา

ข้อกังวลอย่างหนึ่งที่แสดงโดยคนไม่ได้เกี่ยวกับความมั่นคง แต่เป็นการรวมเข้ากับเครื่องมือตรวจสอบและตรวจสอบที่มีอยู่:

"gotcha" เพียงอย่างเดียวเกี่ยวกับการใช้ ksplice คือยังไม่มีเครื่องมือตรวจสอบ "ksplice-aware" ที่ใช้งานได้

อย่างที่คุณคาดหวังตอนนี้เป็นพื้นที่ที่เราลงทุนอย่างหนัก

ฉันได้ยินเกี่ยวกับ Ksplice และในเวลานั้นฉันคิดว่ามันเป็นความคิดที่ดี ไม่เสียเวลาไม่มีการรีบูต แต่จากนั้นฉันก็มองดูอีกเล็กน้อยและฉันก็กลัวที่จะลอง

เหตุผลของฉันสำหรับการหลีกเลี่ยงคือ:

• เคอร์เนล Linux นั้นซับซ้อนมากอยู่แล้ว Ksplice เพิ่มความซับซ้อน ความซับซ้อนมากขึ้น = มากขึ้นที่จะล้มเหลว

• มันจะประมาทในการทดสอบกับ Ksplice บนเซิร์ฟเวอร์ระยะไกลซึ่งความล้มเหลวจะทำให้การหยุดทำงานที่ยาวนานและการซ่อมแซมค่าใช้จ่ายสูง

• ประโยชน์เฉพาะในกรณีของฉันจะสถิติ uptime ที่สูงขึ้น

ฉันใช้ Ksplice บนเซิร์ฟเวอร์ที่บ้านของฉัน (ซึ่งสถานะการออนไลน์ไม่สำคัญ แต่เป็นเรื่องดีที่ต้องมี) ไม่เคยมีปัญหาใด ๆ กับมันเลย - อัปเดตเป็นครั้งคราวผ่าน Apt ไปยังไคลเอนต์ไม่เคยมีปัญหาใด ๆ กับเคอร์เนลที่อัพเดตตัวเองและไม่มีความไม่แน่นอน (สังเกตได้)

ข้อจำกัดความรับผิดชอบ "YMMV" ปกติใช้! ;-)

Ksplice เป็นส่วนขยายเคอร์เนลโอเพนซอร์ซ แต่โปรดจำไว้ว่าในขณะที่ซอฟต์แวร์นั้นฟรีและพร้อมให้ทุกคนใช้มันถูกสร้างขึ้นโดยเฉพาะสำหรับ บริษัท ที่ใช้การจัดการแพตช์ Linux (หรือที่เรียกว่า "Ksplice") Ksplice (เคอร์เนล mod) มีประโยชน์จริงๆถ้าคุณมีแพตช์ ksplice ที่ใช้งานได้สำหรับเคอร์เนลของคุณซึ่งคุณอาจไม่เคยเห็นจนกว่าคุณจะมีสัญญาการสนับสนุนกับ Ksplice (บริษัท )

ดังนั้นในขณะที่ ksplice (เครื่องมือ) นั้นมีความเป็นผู้ใหญ่พอสมควร แต่ก็มีความเกี่ยวข้องถ้าคุณกำลังพิจารณาใช้ Ksplice (บริษัท ) สำหรับการจัดการแพตช์ของคุณ

คำถามที่ดี. การตอบสนองแรกของฉันจะเป็นสิ่งที่ตามสายของ"ทำไมไม่ฉันต้องนี้หรือไม่?"

ส่วนใหญ่อาจไม่ต้องการมัน แม้ในการตั้งค่าห้าเก้า "การบำรุงรักษาตามกำหนดเวลา" มักจะเป็นข้อใน SLA ที่ช่วยให้การหยุดทำงานประเภทนี้ หากคุณมีการตั้งค่า HA ให้สลับไปที่การเฟลโอเวอร์ติดตั้งเคอร์เนลในหนึ่งกล่องรีบู๊ตและทำซ้ำอีกอัน หากคุณไม่สามารถเสียเวลาหยุดงานได้นานถึงห้านาทีคุณต้องทำการติดตั้ง failover อีกครั้ง

แม้ว่ามันจะเป็นเทคโนโลยีที่แปลกใหม่ แต่ฉันก็ยังไม่เห็นประโยชน์ในทางปฏิบัติมากนัก แน่นอนว่าต้องมีการอัพเดทความปลอดภัยของเคอร์เนลและควรได้รับการแก้ไขโดยเร็ว แต่สิ่งนี้ช่วยประหยัดเวลาและความพยายาม / ความกังวลของคุณในการติดตั้งเคอร์เนลและรีบูตเครื่องใหม่หรือไม่? เกิดอะไรขึ้นถ้ามีอะไรผิดพลาด? คุณเสียเวลาไปมากแค่ไหนในการถ่ายภาพระบบใหม่โดยสมมติว่าคุณโชคดีพอที่มีตัวเลือกการกู้คืน PXE-type?

นอกจากนี้ตามที่กล่าวข้างต้นการทดลองทางไกลด้วยเทคโนโลยีเช่นนี้อาจเป็นความหายนะหากเกิดข้อผิดพลาดบนเซิร์ฟเวอร์หลายเครื่อง ในการทดสอบคุณใช้ฮาร์ดแวร์เดียวกันกับที่อยู่ใน DC หรือไม่? สิ่งที่เล่นได้ดีบนเครื่องหนึ่งอาจเล่นได้ไม่ดีในเครื่อง

แค่ $ 0.02 ของฉัน

เมื่อนานมาแล้ว แต่สิ่งที่ Ksplice สามารถทำเพื่อคุณเป็นจำนวนมาก ....

• ความปลอดภัยที่ได้รับการปรับปรุงเนื่องจากอนุญาตให้ใช้การแพทช์แบบทันทีโดยไม่ต้องหยุดทำงานนี่เป็นสิ่งสำคัญอย่างยิ่งในสภาพแวดล้อมที่มีความอ่อนไหวสูง

• ความเสถียรที่ได้รับการปรับปรุงตามที่อนุญาตในการแก้ไขการบินโดยไม่ต้องหยุดทำงานสิ่งต่าง ๆ สามารถปรับปรุงได้ในขณะที่ไม่มีเวลาสำหรับการรีบูต

• ประสิทธิภาพที่ได้รับการปรับปรุงตามที่อนุญาตในการแก้ไขการบินโดยไม่ต้องหยุดทำงานใช้สิ่งที่คุณต้องการสำหรับสิ่งที่คุณต้องทำ

• ปรับปรุงกิจกรรมมืออาชีพตามที่อนุญาตในการแพทช์การบินโดยไม่ต้องหยุดทำงานดังนั้นการตั้งค่าฟาร์มทดสอบสำหรับแพทช์ใหม่ที่ร้อนเป็นไปได้ในขณะที่ย้อนกลับไปยังสถานะก่อนหน้าได้อย่างง่ายดาย