Bekijk Volledige Versie : beheerder managed hosting wil geen standaard library installeren
ik weet niet of het hier thuis hoort, maar ik heb een vraag over managed hosting policies.
Voor een klant heb ik een stukje software geschreven dat gebruik maakt van enkele standaard libraries in de Debian stable repositories. Het is getest op een VM met dezelfde versie van debian als mijn klant heeft op zijn managed server. De beheerder van deze managed server weigert echter de benodigde standaard libraries installeren op de managed server omdat wellicht in de toekomst mijn software dan niet meer werkt bij een update. In mijn ogen is dat waanzin omdat de klant altijd de source code opnieuw zou kunnen compileren tegen wat tzt debian stable is.
Het gevolg is dat we nu moeten klooien met static binaries en meegeleverde libraries die uiteraard niet aan security updates onderhevig zijn via het normale update proces. we hebben het over libs als libblas-common en libjpeg. niks spannends dus.
Is dit een normale gang van zaken bij managed servers? Hoe zouden jullie het oplossen?
systemdeveloper
07/11/14, 00:30
Nou ja, normaal... je hebt management van 10 euro per maand tot xxx per maand.
De 1 geeft je alleen updates van standaard setups (om vanwege heb bedrag zo min mogelijk werk te hebben), de ander rekent meer per maand, maar installeert je wel wat je wilt hebben. (En is daar ook bij toekomstige updates meer tijd aan kwijt, moet meer documenteren e.d. dus logisch dat het duurder is)
Het kan zijn dat de standaard libs zich ergens bijten met wat al op je systeem staat en wat je erbij wilt hebben en dat de hoster een goede reden heeft om het te weigeren. Maar dat kan alleen je hoster je vertellen.
De reden, die gegeven wordt is inderdaad vreemd. Voor security upgrades is het in het geval van debian nooit zo dat er libraries van werking veranderen. Er wordt security ge-backport.
De enige goede reden die ik kan bedenken is dat die lib botst met een controlpanel dat op de server staat.
Overigens wordt wel eens vaker een library en een php-module door elkaar gehaald, wellicht heeft de hoster een panel dat niet gebruik maakt van de systeem php en zou php dan handmatig gerecompiled moeten worden bij elke update......
Hmm, de managed server is zo'n duur ding met onbeperkte support en wat betreft PHP, dat draaien we niet eens. (python based backend). Inmiddels hebben we nu ook een probleem met het installeren van numpy dat gebruik maakt van o.a. gfortran (ook al een standaard debian package dat gewijgerd wordt). Nou vraag ik me toch serieus af wie er nou voor wie werkt? Als klant interesseert het me eerlijk gezegd geen zier als de hoster een backend gebruikt dat niet standaard is, zijn probleem. We weten door het testen dat onze hele setup enkel en alleen afhankelijk is van default debian packages en dat willen we graag zo houden, maar dan moeten ze wel te installeren zijn natuurlijk.
systemdeveloper
07/11/14, 13:37
Ik snap wat je zegt, maar dan had je een unmaged server moeten pakken, waar je alles op kunt gooien wat je wilt. Of eventueel zelfs de hoster vragen om het te installeren of iemand telkens even in te huren om het voor je te doen.
In een managed omgeving vraag je aan de ene kant van de hoster om te garanderen dat de boel blijft draaien en niet 2 dagen plat ligt wegens een update, aan de andere kant wil je dat de hoster 'mogelijk vreemde' dingen in zijn omgeving installeert/ toestaat.
Dat bijt elkaar een beetje natuurlijk.
dat is nou net het punt. We vragen niet om 'mogelijk vreemde dingen' te installeren, slechts om enkele standaard libraries te installeren. Zeg nou zelf, als je managed hosting van debian stable aanbiedt dan is het toch niet meer dan normaal dat een klant kan vragen om een bepaalde library uit diezelfde debian stable te installeren om een stukje third party software te kunnen draaien? Zeker niet als dat getest is en alleen in userspace draait. Uiteindelijk hoeft de hoster niet onze software te installeren, te testen of te updaten. Wat ze nu voorstellen is dat we b.v. zelf openssl statisch meecompileren. We hebben nog niet zo lang geleden gezien wat voor gevolgen dat kan hebben. Is dat dan wat je wil met een managed host? Lijkt me niet.
dat is nou net het punt. We vragen niet om 'mogelijk vreemde dingen' te installeren, slechts om enkele standaard libraries te installeren. Zeg nou zelf, als je managed hosting van debian stable aanbiedt dan is het toch niet meer dan normaal dat een klant kan vragen om een bepaalde library uit diezelfde debian stable te installeren om een stukje third party software te kunnen draaien? Zeker niet als dat getest is en alleen in userspace draait. Uiteindelijk hoeft de hoster niet onze software te installeren, te testen of te updaten. Wat ze nu voorstellen is dat we b.v. zelf openssl statisch meecompileren. We hebben nog niet zo lang geleden gezien wat voor gevolgen dat kan hebben. Is dat dan wat je wil met een managed host? Lijkt me niet.
Ik weet niet wat de managed host wil bereiken, maar in andere situaties is het hoofddoel van een beheerder
_geen specials_ .
Bijvoorbeeld omdat ze een standaard image uitrollen, en (alleen) die dingen die daarin zitten beheren/bewaken etc.
En dat is natuurlijk jammer voor gebruikers/klanten die 'gewoon een simpel dingetje' erbij willen, of "dat is niet moeilijk, kan ik op mijn thuisserver ook' .
En dan is het punt niet of de specifieke vraag moeilijk is, of in een standaard repo zit, of " zo logisch" is, maar dat de beheerder geen extra verantwoordelijk erbij wil nemen . Soms mede omdat update/validatie testen e.d. gericht zijn op het standaard image, en ja, als de special kapot is roept de klant natuurlijk wel "maar het is managed ".
(Hetzelfde soort discussie kun je als kantoorgebruiker hebben over wat er in 'standaard werkplekken' zit )
Natuurlijk kun je best managed hosting krijgen in de vorm van een dedicated beheerder die bouwt wat je vraagt. Tegen het juiste tarief.
systemdeveloper
07/11/14, 14:22
Wij zijn managed hoster en installeren wel gekker dingen dan een standaardlib, dat is het punt ook niet.
Wat ik uit je verhaal begrijp is het volgende:
Je klant zit bij hoster X die een managed contract heeft met klant mbt. het functioneren van zijn server.
Jij als derde maakt een tooltje met een x aantal dependencies en wilt dat de hoster dat installeert.
Wat als de hoster over een jaar een update doet, jouw tooltje doet het niet meer en whatever er nog allemaal kan gebeuren, maar jij bent niet meer te vinden en de klant krijgt het allemaal niet gecompileerd?
Dan is het voor de klant en de hoster in het beste belang om met static libs te werken. Mocht daar dan een lek in zitten, dan is het aan de leverancier van het tooltje om een nieuwe versie uit te brengen.
Het alternatief is dat de hoster eventueel een lek in een lib dus juist niet kan patchen omdat bv. de klant zijn website afhankelijk is van dat tooltje.
Wij hebben ook klanten die gebruik willen maken van 'dingen' die niet meer geupgrade kunnen worden omdat ze software afhankelijkheden hebben. Vanuit een 'managed' contract gezien, krijg je dan wel een paar andere voorwaarden met je klant.
Ik snap zeker het standpunt vanuit de managed hoster gezien, maar mijn klant wil gewoon verder met zijn business, en dat gaat nu niet. In deze specifieke situatie hebben we intussen gekozen voor een alternatieve oplossing voor deze specifieke tool.
Door deze problematiek is echter wel een discussie ontstaan in het management of de setup met enkele managed hosts nog wel voldoet voor de toekomst.
Voor security upgrades is het in het geval van debian nooit zo dat er libraries van werking veranderen. Er wordt security ge-backport.
Bedenk wel dat het beleid van Debian is om slechts een jaar lang security updates uit te brengen voor oude Debian releases, op het moment dat een nieuwe stable release uitkomt.
En de kans is wel degelijk aanwezig dat upgraden naar een nieuwe Debian release niet zondermeer gaat lukken zonder het bouwsel van de TS opnieuw te compileren.
Libraries als het genoemde OpenSSL bieden geen binary compatibility tussen major releases aan.
Kan best begrijpen dat een managed hoster daar niet op zit te wachten.
Je kan wel zeggen dat het het probleem van de klant is om de eigen software terzijner tijd opnieuw te compileren.
Maar gezien de klant voor managed hosting heeft gekozen, zou het goed kunnen dat deze technisch minder goed onderlegd is, en alsnog bij de hoster aan gaat kloppen...
Dat ze dit nu al aan zien komen, en aangeven om libraries statisch te compileren vindt ik eigenlijk wel netjes.
De TS zou wel een punt hebben als het om een distro zou gaan waar wel langdurige ondersteuning op zit. Denk aan RHEL en Suse die 13 jaar updates adverteren.
Ik kan me dan ook voorstellen dat je als managed hoster niet zomaar nee zegt, maar dat er een dialoog ontstaat wat wel en niet kan.
Een vaste regel is bij ons, is de klant afhankelijk van de software? En kan dat problemen geven bij calamiteiten, dan wil ik diegene uit haar of zijn bed kunnen bellen.
Inclusief garanties op response.
Custom setups opzetten voor managed klanten doen we wel vaker. Echter leggen wij wel vast welke software wij onderhouden en bijwerken en dat de klant verantwoordelijk is voor overige software en dat deze altijd met de gebruikte en laatste versie moet werken. Op Debian hoeft dit verder geen enkel probleem te zijn. Squeeze LTS is overigens nog t/m 2016 ondersteund terwijl Wheezy al weer enige tijd beschikbaar is.
Squeeze LTS is overigens nog t/m 2016 ondersteund terwijl Wheezy al weer enige tijd beschikbaar is.
Je laat het klinken alsof "Squeeze LTS" een officiele Debian versie is.
Leuk dat een groepje vrijwilligers een aparte lts repo opgetuigd heeft om security updates uit te brengen voor een deel van de packages van de niet meer ondersteunde Squeeze release.
Maar dat is niet vergelijkbaar met officiele ondersteuning.
Je laat het klinken alsof "Squeeze LTS" een officiele Debian versie is.
Leuk dat een groepje vrijwilligers een aparte lts repo opgetuigd heeft om security updates uit te brengen voor een deel van de packages van de niet meer ondersteunde Squeeze release.
Maar dat is niet vergelijkbaar met officiele ondersteuning.
De officiële versie was Squeeze, ik zeg nergens dat Squeeze LTS een officiële versie is. Overigens heb ik begrepen dat er partijen zijn die security audits doen die het wel als zodanig beschouwen... Als het goed gaat bestaat overigens de kans dat ze in de toekomst wel met een officiële LTS versie gaan komen (enkel security updates).
Ondanks wat afwijkende omgeving waren er 0,0 problemen met de upgrade naar Wheezy.
Bedenk wel dat het beleid van Debian is om slechts een jaar lang security updates uit te brengen voor oude Debian releases, op het moment dat een nieuwe stable release uitkomt.
En de kans is wel degelijk aanwezig dat upgraden naar een nieuwe Debian release niet zondermeer gaat lukken zonder het bouwsel van de TS opnieuw te compileren.
Libraries als het genoemde OpenSSL bieden geen binary compatibility tussen major releases aan.
Kan best begrijpen dat een managed hoster daar niet op zit te wachten.
Je kan wel zeggen dat het het probleem van de klant is om de eigen software terzijner tijd opnieuw te compileren.
Maar gezien de klant voor managed hosting heeft gekozen, zou het goed kunnen dat deze technisch minder goed onderlegd is, en alsnog bij de hoster aan gaat kloppen...
Dat ze dit nu al aan zien komen, en aangeven om libraries statisch te compileren vindt ik eigenlijk wel netjes.
De TS zou wel een punt hebben als het om een distro zou gaan waar wel langdurige ondersteuning op zit. Denk aan RHEL en Suse die 13 jaar updates adverteren.
Helaas werkt een major versie upgraden in combinatie met controlpanels niet. Om een debian release om hoog te gaan moeten alle websites naar een nieuwe server, waar de klant ze voor het omzetten test. Ik mis in dat scenario even waarom dit een issue is.
Helaas werkt een major versie upgraden in combinatie met controlpanels niet. Om een debian release om hoog te gaan moeten alle websites naar een nieuwe server, waar de klant ze voor het omzetten test. Ik mis in dat scenario even waarom dit een issue is.
Ervaring met voornamelijk DirectAdmin is dat je Debian rustig van 3.1 -> 4 -> 5 -> 6 -> 7 kunt doen (tussen door wel even DirectAdmin updaten natuurlijk + OS versie wijzigen op directadmin.com). Migraties van de sites zijn dan niet nodig, overigens kan het wel aan te raden zijn als je de PHP versie bij wilt werken (aanrader).
overigens kan het wel aan te raden zijn als je de PHP versie bij wilt werken (aanrader).
Eigenlijk wat ik op zo'n moment ook gelijk doe. Is gelijk ook een mooie kans om vernieuwde inzichten toe te passen op de nieuwe servers.