सवाल Red Hat और CentOS के प्रमुख संस्करणों के बीच अपग्रेड करना इतना मुश्किल क्यों है?


"क्या हम अपने मौजूदा उत्पादन ईएल 5 सर्वर को ईएल 6 में अपग्रेड कर सकते हैं?"

दो ग्राहकों से एक सरल ध्वनि अनुरोध पूरी तरह विभिन्न वातावरण ने "हां" के अपने सामान्य सर्वोत्तम प्रथाओं के उत्तर को प्रेरित किया, लेकिन इसके लिए समन्वय की आवश्यकता होगी अपने सभी सिस्टम का पुनर्निर्माण"...

दोनों क्लाइंट महसूस करते हैं कि डाउनटाइम और संसाधन कारणों के लिए उनके सिस्टम का एक पूर्ण पुनर्निर्माण एक अस्वीकार्य विकल्प है ... जब पूछा गया कि सिस्टम को पूरी तरह से पुनर्स्थापित करने के लिए क्यों जरूरी था, तो मेरे पास कोई अच्छा जवाब नहीं था, "यही तरीका है ... "

मैं विन्यास प्रबंधन के बारे में प्रतिक्रियाओं को पूरा करने की कोशिश नहीं कर रहा हूं ("Puppetize सब कुछ" हमेशा लागू नहीं होता है) या कैसे ग्राहकों को बेहतर योजना बनाई जानी चाहिए। यह उन वातावरणों का एक वास्तविक दुनिया का उदाहरण है जो उत्पादन क्षमता में उगाए और बढ़े हैं, लेकिन उनके ओएस के अगले संस्करण में जाने के लिए एक साफ रास्ता नहीं दिख रहा है।

पर्यावरण ए:
गैर लाभकारी संगठन के साथ 40 एक्स Red Hat Enterprise Linux 5.4 और 5.5 वेब, डेटाबेस सर्वर और मेल सर्वर, जावा वेब अनुप्रयोग स्टैक, सॉफ़्टवेयर लोड बैलेंसर्स और पोस्टग्रेस डेटाबेस चला रहे हैं। सभी प्रणालियों को विभिन्न स्थानों में दो वीएमवेयर वीएसपीयर क्लस्टर्स पर वर्चुअलाइज्ड किया जाता है, प्रत्येक एचए, डीआरएस, आदि के साथ।

पर्यावरण बी:
उच्च आवृत्ति वित्तीय व्यापार फर्म के साथ 200 एक्स सेंटोस 5.x कई सह-स्थान सुविधाओं में सिस्टम उत्पादन व्यापार संचालन चला रहे हैं, इन-हाउस डेवलपमेंट और बैक ऑफिस फ़ंक्शंस का समर्थन करते हैं। ट्रेडिंग सर्वर बेयर-मेटल कमोडिटी सर्वर हार्डवेयर पर चल रहे हैं। उनके पास कई हैं sysctl.conf, rtctl, मैसेजिंग विलंबता को कम करने के लिए बाध्यकारी और ड्राइवर tweaks को बाधित करें। कुछ में कस्टम और / या रीयलटाइम कर्नेल होते हैं। डेवलपर वर्कस्टेशन सेंटोस के समान संस्करण (ओं) भी चला रहे हैं।


दोनों मामलों में, वातावरण अच्छी तरह से चल रहे हैं। उन्नयन की इच्छा ईएल 6 में उपलब्ध एक नए आवेदन या सुविधा की आवश्यकता से आता है।

  • गैर-लाभकारी फर्म के लिए, यह अपाचे, कर्नेल और कुछ चीजों से जुड़ा हुआ है जो डेवलपर्स को खुश कर देगा।
  • ट्रेडिंग फर्म में, यह कर्नेल, नेटवर्किंग स्टैक और जीएलबीबीसी में कुछ संवर्द्धन के बारे में है, जो डेवलपर्स को खुश कर देगा।

दोनों ऐसी चीजें हैं जिन्हें आसानी से पैक या अपडेट नहीं किया जा सकता है ऑपरेटिंग सिस्टम में भारी बदलाव

एक सिस्टम इंजीनियर के रूप में, मैं सराहना करता हूं कि प्रमुख संस्करण रिलीज के बीच चलते समय Red Hat पूर्ण पुनर्निर्माण की सिफारिश करता है। एक साफ शुरुआत आपको रिफैक्टर करने और रास्ते में कॉन्फ़िगरेशन पर ध्यान देने के लिए मजबूर करती है।

ग्राहकों की व्यावसायिक जरूरतों के प्रति संवेदनशील होने के नाते, मुझे आश्चर्य है कि इसे ऐसा क्यों होना चाहिए कठिन काम। आरपीएम पैकेजिंग सिस्टम इन-प्लेस अपग्रेड को संभालने में सक्षम है, लेकिन यह आपको थोड़ा सा विवरण देता है जो आपको प्राप्त करता है: /boot अधिक जगह की आवश्यकता है, नई डिफ़ॉल्ट फाइल सिस्टम, आरपीएम संभवतः मिड-अपग्रेड तोड़ रहा है, हटा दिया गया है और पैकेज को निष्क्रिय कर रहा है ...

यहां जवाब क्या है? अन्य वितरण (.deb- आधारित, आर्क और जेनेटू) में यह क्षमता या बेहतर पथ प्रतीत होता है। आइए मान लें कि हम इस कार्य को पूरा करने के लिए डाउनटाइम पाते हैं सही मार्ग:

  • ईएल 7 जारी होने और स्थिर होने पर इन ग्राहकों को एक ही समस्या से बचने के लिए क्या करना चाहिए?
  • या यह एक ऐसा मामला है जहां लोगों को हर कुछ वर्षों में पूर्ण पुनर्निर्माण के लिए खुद को इस्तीफा देने की जरूरत है?
  • ऐसा लगता है कि एंटरप्राइज़ लिनक्स विकसित हुआ है ... या क्या मैं बस कल्पना कर रहा हूं?
  • क्या इसने किसी को Red Hat और व्युत्पन्न ऑपरेटिंग सिस्टम का उपयोग करने से मना कर दिया है?

मुझे लगता है कि कॉन्फ़िगरेशन प्रबंधन कोण है, लेकिन अधिकांश कठपुतली प्रतिष्ठानों को मैं उच्च-अनुकूलित अनुप्रयोग सर्वर के साथ वातावरण में अच्छी तरह से अनुवाद नहीं करता हूं (पर्यावरण बी एक सर्वर हो सकता है जिसका ifconfig उत्पादन इस तरह दिखता है)। संगठनों को आरएचईएल प्रमुख संस्करण टक्कर में आने में मदद करने के लिए कॉन्फ़िगरेशन प्रबंधन का उपयोग कैसे किया जा सकता है, इस बारे में सुझाव सुनने में दिलचस्प होगा।


70
2017-11-15 15:14


मूल


मैं इसे बंद करने के लिए "रचनात्मक नहीं" के रूप में चिह्नित करने वाला था, जब मैंने लेखक का नाम और प्रतिनिधि देखा, और सम्मान से मैं ऐसा नहीं करूँगा। मुझे अभी भी लगता है कि यह एक मूर्ख सवाल है, क्योंकि जवाब यह है कि "रेड हैट ने फैसला किया कि यह ऐसा होना चाहिए"। 4-> डीवीडी बूट के माध्यम से 5 अपग्रेड पूरी तरह से संभव थे, और इसका उपयोग कर लाइव ओएस में करने के लिए प्रक्रियाएं थीं yum, जो मेरे लिए ज्यादातर समय काम करता था। मेरी एकमात्र उम्मीद यह है कि आरएच ने एक लिया है विशाल उनके भुगतान करने वाले ग्राहकों से दर्द छड़ी का हिट उनके समर्थन के लिए अपग्रेड पथ 5-> 6 का समर्थन करने का निर्णय नहीं है, और यह 6-> 7 के लिए पुनर्विचार करेगा। - MadHatter
उस ने कहा, आप जानते हैं कि डीवीडी बूट के माध्यम से सी 5-> सी 6 का उपयोग कर एक असमर्थित अपग्रेड पथ है upgradeany बूट-टाइम पैरामीटर, हां? मैंने इसे दो बार परीक्षण किया है, एक बार एक साफ सी 5 इंस्टॉल पर जहां यह ठीक काम करता है; एक बार (ए की परीक्षण प्रति) क्रॉफ्टी पुरानी "सी 4 होने के लिए प्रयोग की जाती थी और इसे अपग्रेड किया गया था" इंस्टॉल करें जहां यह नाटकीय रूप से विफल रहा। - MadHatter
मैं अपग्रेड विकल्पों के बारे में अच्छी तरह से जानता हूं, और निश्चित रूप से लाइव आरपीएम दृष्टिकोण का उपयोग करके इंस्टॉलेशन को मजबूर कर दिया है (रेपो बदल रहा है, *-release files और सभी)। लेकिन इस हफ्ते ग्राहकों के सवालों ने मुझे इस बारे में और अधिक सोचा कि पर्यावरण एक विशिष्ट संस्करण के साथ कैसे बन सकता है, और इसका कोई रास्ता नहीं है। - ewwhite


जवाब:


(लेखक का नोट: यह उत्तर आरएचईएल 6 और पूर्व संस्करणों को संदर्भित करता है। आरएचईएल 7 में अब आरएचईएल 6 से पूरी तरह से समर्थित अपग्रेड पथ है, जिसका विवरण अंत में है।)


शुरू करने के लिए, मुझे ध्यान रखना चाहिए कि वहां हैं दो तरीके इन-प्लेस अपग्रेड करने के लिए:

  1. इंस्टॉलेशन डीवीडी में ड्रॉप करें (या आईएलओ / आईडीआरएसी के माध्यम से डीवीडी छवि का उपयोग करें), इससे बूट करें और अपग्रेड चुनें, उदा। linux upgradeany
  2. अद्यतन करें redhat-release आरपीएम मैन्युअल रूप से, चलाएं yum distro-sync (यह थोड़ा बढ़ाया गया है) और रीबूट करें।

विधि 1 केवल असमर्थित है। विधि 2 असली काउबॉय के लिए है। अनुशंसित ताजा इंस्टॉल के अलावा, मैंने इन दोनों को किया है ...


क्या मुझे समर्थन चाहिए?

समर्थन हमारी दुनिया में दो पूरक अर्थ हैं। पहला यह है कि किसी उत्पाद में एक दी गई सुविधा होती है (उदा। "पोस्टफिक्स एसएमटीपी का समर्थन करता है")। दूसरा यह है कि विक्रेता इसके बारे में आपसे बात करेगा। कौन सी परिभाषा का मतलब संदर्भ से हमेशा स्पष्ट नहीं होता है।

एक कार्य पूरा करने के लिए, आपको स्पष्ट रूप से पहले अर्थ में समर्थन की आवश्यकता है। जहां विक्रेताओं का समर्थन आता है, मुद्दों को हल करने और विक्रेताओं को प्रतिक्रिया देने में सहायता करने के लिए कि कौन सी विशेषताओं को अस्तित्व में होना चाहिए या सुधार किया जाना चाहिए। कई साइट विक्रेताओं के समर्थन के लिए एक भाग्य का भुगतान करती हैं जब उनके पास घर के किसी भी मुद्दे को हल करने के लिए घर की विशेषज्ञता होती है जो विक्रेता के मुकाबले तेजी से और सस्ता भी हो सकती है। विक्रेता समर्थन खरीदने के लिए आखिरकार एक व्यावसायिक निर्णय है जिसे आपको बनाना होगा (या प्रबंधन को सलाह देना)।


इन-प्लेस अपग्रेड क्यों नहीं करते?

ये है रेड हैट इसके बारे में क्या कहता है:

Red Hat Red Hat Enterprise Linux के किसी भी प्रमुख संस्करण के बीच इन-प्लेस अपग्रेड का समर्थन नहीं करता है। एक बड़ा संस्करण एक पूर्ण संख्या संस्करण परिवर्तन द्वारा दर्शाया गया है। उदाहरण के लिए, Red Hat Enterprise Linux 5 और Red Hat Enterprise Linux 6 Red Hat Enterprise Linux के दोनों प्रमुख संस्करण हैं।

प्रमुख रिलीज में इन-प्लेस अपग्रेड सभी सिस्टम सेटिंग्स, सेवाओं या कस्टम कॉन्फ़िगरेशन को सुरक्षित नहीं करते हैं। नतीजतन, एक प्रमुख संस्करण से दूसरे में अपग्रेड करते समय, Red Hat ताजा इंस्टॉलेशन की दृढ़ता से अनुशंसा करता है।

वे आगे चेतावनी देते हैं:

हालांकि, अपने सिस्टम को अपग्रेड करना चुनने से पहले निम्नलिखित सीमाएं नोट करें:

  • व्यक्तिगत कॉन्फ़िगरेशन फ़ाइल स्वरूप या कॉन्फ़िगरेशन में परिवर्तनों के कारण अपग्रेड करने के बाद व्यक्तिगत पैकेज कॉन्फ़िगरेशन फ़ाइलें काम कर सकती हैं या नहीं।
  • यदि आपके पास Red Hat के स्तरित उत्पादों (जैसे क्लस्टर सूट) स्थापित है, तो Red Hat Enterprise Linux अपग्रेड पूरा होने के बाद इसे मैन्युअल रूप से अपग्रेड करने की आवश्यकता हो सकती है।
  • अपग्रेड के बाद तीसरे पक्ष या आईएसवी अनुप्रयोग सही ढंग से काम नहीं कर सकते हैं।

बेशक, वे वर्णन करते हैं कि विधि 1 के माध्यम से इन-प्लेस अपग्रेड कैसे करें, बस अगर आप वास्तव में ऐसा करना चाहते हैं। सुविधा मौजूद है और Red Hat इसमें विकास का समय रखता है, इसलिए यह समर्थित है कि सुविधा मौजूद है। लेकिन अगर कुछ गलत हो जाता है, तो Red Hat आपको ताजा स्थापित करने के लिए कहेंगे; वे अपग्रेड के परिणामस्वरूप टूटने वाली चीज़ों के लिए विक्रेता समर्थन प्रदान नहीं करेंगे।

रिकॉर्ड के लिए, मुझे कभी भी आरएचईएल / सेंटोस या फेडोरा सिस्टम के इन-प्लेस अपग्रेड के साथ कोई समस्या नहीं हुई है जिसे मैं स्वयं हल नहीं कर सका। सामान्य समस्याएं नामित पैकेज, तृतीय पक्ष भंडारों और पैकेज के i386 और x86_64 आर्किटेक्चर के बीच कभी-कभी संस्करण विसंगति से आती हैं। इनसे निपटने में इंस्टॉलर थोड़ा बेहतर है yum, मुझे लगता है।


मुझे अपग्रेड कैसे करना चाहिए?

मैं आम तौर पर लोगों को चेतावनी देता हूं कि उन्हें चाहिए योजना आरएचईएल सिस्टम को एक प्रमुख संस्करण से अगले तक अपडेट करने के लिए हर 3-4 साल रखरखाव खिड़की पर। जबकि उन्नयन आम तौर पर आसानी से जाते हैं, अप्रत्याशित हमेशा होता है।

आपके दोनों वातावरणों के लिए, मुझे उम्मीद है कि एक इन-प्लेस अपग्रेड काम करेगा, हालांकि मैं दृढ़तापूर्वक इसे पहले परीक्षण करने की सलाह देता हूं। P2V सर्वर का एक प्रतिनिधि नमूना है और वर्चुअल सिस्टम पर इन-प्लेस अपग्रेड के माध्यम से चलाता है यह देखने के लिए कि आप किन समस्याओं को चलाने जा रहे हैं। इसके बाद आप क्या करेंगे इसके बेहतर ज्ञान के आधार पर वास्तविक उत्पादन अपग्रेड की योजना बना सकते हैं।

आपके यहां एक बड़ी तैनाती के लिए, लिमोनसेलि के "एक-कुछ-कई" दृष्टिकोण का उपयोग करने पर विचार करें। एक मशीन को अपग्रेड करें, देखें कि कौन सी समस्याएं होती हैं, उन्हें हल करें, फिर मशीनों के छोटे बैच को अपग्रेड करते समय सीखे गए पाठों का उपयोग करें, सीखने वाले पाठों को दोहराएं, फिर जब आप मानते हैं कि आपके पास सभी कंक काम करते हैं, तो उनमें से बड़े बैचों को अपग्रेड करें।

इस तरह के समय में, मैं आपके आवेदन परिनियोजन प्रक्रिया पर एक लंबा कड़ी नजर डालने की भी सिफारिश करता हूं। यदि यह पर्याप्त रूप से स्वचालित नहीं है कि आप इसे एक ही कमांड से निकाल सकते हैं और उचित रूप से सुनिश्चित कर सकते हैं कि ऐप सही तरीके से तैनात किया जाएगा, तो शायद डेवलपर्स को उस पर काम करने की आवश्यकता है। ऐसी तैनाती प्रक्रिया होने से ईएल के नए संस्करण की ताजा स्थापना करना और फिर उस पर तैनाती करना आसान हो जाएगा।


वितरण स्विचिंग मदद करेगा?

डेबियन-आधारित वितरण में एक समर्थित इन-प्लेस अपग्रेड विधि है, और यह ज्यादातर काम करता है, लेकिन यह समस्याओं से प्रतिरक्षा नहीं है। लोगों के लिए बहुत सारी चीजें तोड़ दीं उबंटू 10.04 एलटीएस से 12.04 एलटीएस तक अपग्रेड करना उदाहरण के लिए, समर्थित विधि के माध्यम से। यह स्पष्ट नहीं है कि डेबियन या कैनोनिक इस सुविधा को "समर्थन" में पर्याप्त मात्रा में विकास का समय दे रहे हैं, यानी यह सुनिश्चित करना कि यह काम करता है। और यदि आप चाहते हैं कि कोई व्यक्ति अपना हाथ पकड़ ले, तो आपको वास्तव में इस वितरण के लिए विक्रेता समर्थन खरीदना होगा। तो मुझे संदेह है कि आपको इस तरह के वितरण में स्विच करने से ज्यादा फायदा होगा।

आप जेंटू या आर्क जैसे रोलिंग-रिलीज वितरण पर स्विच करके लाभ प्राप्त कर सकते हैं। हालांकि, यह आपको समस्याओं से प्रतिरक्षा नहीं बनाता है; इसका मतलब यह है कि आपको सर्वर के जीवन पर निरंतर अपग्रेड समस्याओं का सामना करना पड़ता है (उदाहरण के लिए जब भी आप या डेवलपर्स सिस्टम पर कुछ अपडेट करने का निर्णय लेते हैं), बजाय एक बार अच्छी तरह से योजनाबद्ध वितरण अपग्रेड समय पर। आपके पास समर्थन प्रदान करने के लिए कोई विक्रेता नहीं है।


भविष्य में क्या है?

फेडोरा प्रोजेक्ट इन-प्लेस अपग्रेड को बेहतर बनाने के लिए एक टूल पर काम कर रहा है। उनके पास एक उपकरण था preupgrade जिसे छोड़ दिया गया था और एक नए उपकरण के साथ बदल दिया फेडोरा 18 से शुरू होने वाला फेडअप। इसे आरएचईएल 7 में जोड़ा गया था और अब इन-प्लेस अपग्रेड के पास पूर्ण समर्थन है, कम से कम आरएचईएल 6 से आरएचईएल 7 तक। अपने अनुभव से मैं कह सकता हूं कि जबकि fedup अभी भी कुछ कंक हैं, यह एक बहुत उपयोगी उपकरण होने के लिए आकार दे रहा है।

CentOS भी प्रयोग कर रहा है एक रोलिंग रिलीज प्रकार भंडार, लेकिन यह केवल मामूली संस्करणों (जैसे 6.3-6.4) के बीच लागू होता है।


41
2017-11-15 17:09



नया फेडोरा अपग्रेड टूल कहा जाता है परेशान। बड़े उन्नयन के लिए तीन से चार साल भी आक्रामक लगता है, मुझे स्थापित करना होगा कि मैं आरएचईएल के 10+ साल के जीवन चक्र की ओर आखिरी बार देखता हूं, इसलिए मैं अधिक नियमित मामूली उन्नयन को प्रोत्साहित करता हूं। - Dominic Cleal
जिन लोगों को निरंतर आधार पर नई सुविधाओं की आवश्यकता है, उनके लिए 3-4 साल लगभग बहुत लंबा है। - Michael Hampton♦
PHP, अपाचे, कर्नेल संशोधन और जीएलबीबीसी जैसी सरल चीजें ... लोग उन परिवर्तनों को अधिक बार चाहते हैं। - ewwhite
डेबियन / उबंटू की अपग्रेड प्रक्रिया सही नहीं है, लेकिन तथ्य यह है कि यह पसंदीदा अपग्रेड तंत्र और रेड हैट का कोई आधिकारिक रूप से समर्थित अपग्रेड तंत्र नहीं है, जो मुझे वॉल्यूम बोलता है। - Paul Gear
यह उतना ही नहीं है कि इन-प्लेस अपग्रेड मौजूद हैं, जैसा कि वे स्पष्ट रूप से करते हैं, लेकिन क्या संबंधित विक्रेता उनके लिए समर्थन प्रदान करते हैं। - Michael Hampton♦


मेरा अंतिम पैराग्राफ पर मेरा लेना:

मुझे लगता है कि कॉन्फ़िगरेशन प्रबंधन कोण है, लेकिन अधिकांश कठपुतली इंस्टॉलेशन जो मैं देखता हूं, उच्च-अनुकूलित अनुप्रयोग सर्वरों के साथ वातावरण में अच्छी तरह से अनुवाद नहीं करता है (पर्यावरण बी में एक सर्वर हो सकता है जिसका ifconfig आउटपुट इस तरह दिखता है)। संगठनों को आरएचईएल प्रमुख संस्करण टक्कर में आने में मदद करने के लिए कॉन्फ़िगरेशन प्रबंधन का उपयोग कैसे किया जा सकता है, इस बारे में सुझाव सुनने में दिलचस्प होगा।

मुझे लगता है कि विशेष रूप से पर्यावरण बी के संदर्भ में कॉन्फ़िगरेशन प्रबंधन प्रणालियों का वास्तविक मूल्य यह है कि वे इसे चलाने वाले सर्वरों से स्वतंत्र रूप से सेवा बनाने के लिए टूल प्रदान करते हैं। यदि मौजूदा सेवाओं को बनाने के लिए सीएमएस का उपयोग नहीं किया गया था, तो शायद यह सेवाओं को पुनर्निर्माण में बहुत मदद नहीं करेगा।

मुझे पता है कि यह आपकी तत्काल समस्या का समाधान नहीं करता है, लेकिन मेरे लिए यह सेवाओं के बजाय सर्वर के संदर्भ में संगठन से उत्पन्न होता है। सेवा-केंद्रित सोच में, व्यक्तिगत सर्वर के व्यक्तित्व को तब तक बनाए रखने की आवश्यकता नहीं है जब तक कि सेवा कार्य जारी रहे। यदि पूरी सेवा बनाने के लिए अनुशासित तरीके से एक सीएमएस का उपयोग किया जाता है, तो उस सेवा को किसी अन्य सिस्टम में ले जाना अपेक्षाकृत सरल होना चाहिए, क्योंकि मशीन के सभी व्यक्तित्व सीएमएस द्वारा बनाए जाएंगे।

अनुलेख मुझे बिल्कुल यकीन नहीं है कि इस संदर्भ में ifconfig आउटपुट के बारे में क्या महत्वपूर्ण है - यह एक कॉन्फ़िगरेशन फ़ाइल और कुछ स्क्रिप्ट्स द्वारा उत्पादित होता है (अन्यथा यह बूट पर नहीं होगा), और यदि आवश्यक हो तो उनको सीएमएस द्वारा प्रबंधित किया जा सकता है।


5
2017-11-20 22:28



आप सामान्य ज्ञान में सर्वर बनाम सर्वर के बारे में सही हैं। पर्यावरण बी में कुछ विशेष सर्वर हार्डवेयर (10 जीबीई एनआईसी, ऑफलोड पुस्तकालय) हैं जो अपस्ट्रीम प्रदाताओं के साथ इंटरफेस करते हैं। यह ऐसा कुछ है जो लोड-संतुलित नहीं हो सकता है या डाउनटाइम के बिना आसानी से स्थानांतरित नहीं किया जा सकता है। एक गैर-वित्त उदाहरण कुछ शामिल उत्पादन मशीनरी के लिए एक नियंत्रक के रूप में संलग्न सर्वर की तरह कुछ होगा। विशेष पीसी, शायद समर्पित पीसीआई इंटरफ़ेस कार्ड के साथ। सर्वर के लिए अद्वितीय एक बहुत ही ऑफ सेटअप है। कठपुतली में, क्या आप बस कहेंगे, "यहां इस होस्ट / भूमिका के लिए कॉन्फ़िगर है" और इसके साथ रहें? - ewwhite
सहमत हैं, कुछ मामलों को सामान्य मामलों में फिट करना आसान नहीं है, खासकर यदि आपके पास विशिष्ट हार्डवेयर आवश्यकताओं के साथ वातावरण है। कठपुतली के साथ, जितना संभव हो उतना भूमिका में धक्का देना अच्छी समझ में आता है। लेकिन अंत में इसे काम करना है, इसलिए यदि कुछ सुंदर नहीं है तो यह काम करता है, तो मैं बस इसके साथ रहना चाहता हूं। ज्यादातर समय, हमें बस चीजों के साथ आराम से रहना पड़ता है क्योंकि हमारे पास उन्हें "सही" बनाने का समय नहीं है। - Paul Gear