Den frie kafeen

[rockPaperScissors()]

.. Ville du brukt Debian Sid som OS til viktige produksjonsoppgaver? Etter mitt syn egner RHEL/CentOS seg langt bedre til serverdrift enn eks. Debian. Og ja, jeg har flere års erfaring innen dette feltet.

Nei, jeg ville nok ikke brukt rullende OS for viktige produksjonsoppgaver. Men mange bruker Arch og Debian Sid som rullende distribusjoner, og det er overraskende lite problemer med Sid (Arch har jeg ikke erfaring med). Etter at man har oppgradert til Sid, kan man f.eks. bruke debsecan til å installere sikkerhetsoppdateringer for å minske sjansen for overraskelser, og utsette full oppdatering til en gang man har bedre tid. Jeg har brukt Sid på utviklermaskin i jobbsammenheng uten problemer.

 

# apt-get update
# apt-get install $(debsecan --suite sid --format packages --only-fixed)

Men jeg foretrekker Debian stable eller Ubuntu LTS fordi de nesten ikke krever vedlikehold i det hele tatt.

 

Hva er galt med Debian på server? Jeg synes RHEL/CentOS har litt få og utdaterte pakker, det er av og til ett problem. Det er heller ikke noen ulempe at flere bruker Debian Sid da det burde i teorien minske sjansen for at alvorlige feil blir stående åpne lenge.

[stigfjel]

Nei, jeg ville nok ikke brukt rullende OS for viktige produksjonsoppgaver. Men mange bruker Arch og Debian Sid som rullende distribusjoner, og det er overraskende lite problemer med Sid (Arch har jeg ikke erfaring med). Etter at man har oppgradert til Sid, kan man f.eks. bruke debsecan til å installere sikkerhetsoppdateringer for å minske sjansen for overraskelser, og utsette full oppdatering til en gang man har bedre tid. Jeg har brukt Sid på utviklermaskin i jobbsammenheng uten problemer.

 

# apt-get update
# apt-get install $(debsecan --suite sid --format packages --only-fixed)

Men jeg foretrekker Debian stable eller Ubuntu LTS fordi de nesten ikke krever vedlikehold i det hele tatt.

 

Hva er galt med Debian på server? Jeg synes RHEL/CentOS har litt få og utdaterte pakker, det er av og til ett problem. Det er heller ikke noen ulempe at flere bruker Debian Sid da det burde i teorien minske sjansen for at alvorlige feil blir stående åpne lenge.

 

En vesentlig ting som har vært galt med Debian på servere er den korte levetiden til en major release. Siden Debian de siste årene har klart å få til en release-sykel på 2 år for hver major har levetiden til en major bare vært på 3 år. Til sammenligning har RHEL/CentOS hatt en levetid på 7 år for en major. For et par år siden ble denne levetiden utvidet til 10 år, slik at RHEL 5 når EoL i 2017, og RHEL 6 i 2020. For produksjonssystemer som er ment å leve en stund er en levetid på 3 år for kort (ja, jeg vet at Debian 6.0 har fått LTS-status, men før det var det slik jeg påpeker). Dessuten, mange applikasjoner er fullt ut supportert på RHEL, samme tilfelle er det ikke nødvendigvis på Debian. Dessuten, jeg har driftet servere basert på både RHEL/CentOS og Debian, og jeg merker godt at RHEL/CentOS går mer "smooth". Det er mange småting, som f.eks. å kunne restarte nettverket på en effektiv måte som går veldig fint på RHEL/CentOS, men som ikke er like strømlinjeformet og velegnet for stordrift. Er vant til å jobbe i store miljøer med hundrevis, kanskje tusenvis av servere. RHEL/CentOS egner seg godt til dette. Kickstart-regimet på RHEL/CentOS er godt etablert, dette er et annet eksempel. Et skrekkeksempel på hvordan Debian lot ideologi gå foran strømlinjeforming var da de nektet såkalte "binære blobs" i standardinstallasjonen. Dette gikk også utover bnx2-driveren, som var nødvendig for å kunne kickstart-installere en haug av servere (Dell PowerEdge og HP ProLiant) med integrerte nettverkskort som nettopp trengte bnx2. Dette gjorde det umulig å kickstart-installere Debian på en slik server, som er MYE brukt. Red Hat har en langt mer pragmatisk holdning til dette enn Debian, som er veldig ideologiske. I enterprise-segmentet kan man ikke ri for mye på ideologi/religion-kjepphesten, der bør fokuset være å løse oppgaver.

 

At pakkene virker utdaterte er en ting. Men du skal huske på at Red Hat backporter hauger av funksjonalitet på viktige pakker, slik at du kan ikke la deg lure av versjonsnr. Dette gjelder i hvert fall linux-kjernen, apache og andre viktige pakker, og er et tiltak for å bevare kompatibilitet med enterprise-applikasjoner. Dessuten, på en RHEL/CentOS-installasjon tar man selvfølgelig også i bruk EPEL-pakkebrønnen som gir tilgang til en haug av ekstra pakker. i tillegg til standard-repoene fra RHEL/CentOS. Og EPEL er spesifikt tilpasset RHEL/CentOS slik at pakker fra EPEL ikke skaper konflikter, noe man kan oppleve med andre pakkebrønner som rpmforge.

[rockPaperScissors()]

Men når du er nødt å ta i bruk community-repositories og installerer ting sideveien så er det vel akkurat like mye arbeid å sørge for at programvaren til enhver tid er patchet. Visst de driftsansvarlige ikke bare overlater det til utvikleren, for da vet vi at det ikke blir vedlikeholdt. Med Debian får jeg som regel behovene dekket med det som kommer fra offisielle repos, og Debian takler også en oppdatering fra en versjon til den neste på en svært god måte.

 

RH er definitivt mer enterprise-orientert, og dessverre ikke uten kompromisser i den enden av skalaen heller.

[stigfjel]

Men når du er nødt å ta i bruk community-repositories og installerer ting sideveien så er det vel akkurat like mye arbeid å sørge for at programvaren til enhver tid er patchet. Visst de driftsansvarlige ikke bare overlater det til utvikleren, for da vet vi at det ikke blir vedlikeholdt. Med Debian får jeg som regel behovene dekket med det som kommer fra offisielle repos, og Debian takler også en oppdatering fra en versjon til den neste på en svært god måte.

 

RH er definitivt mer enterprise-orientert, og dessverre ikke uten kompromisser i den enden av skalaen heller.

EPEL kan ikke akkurat kalles en vanlig community-drevet pakkebrønn. Det er Fedora som står bak, og hvor får Fedora finansiering, tro? Selvfølgelig fra Red Hat. Og Red Hat gjør det veldig bra økonomisk, så da er ikke økonomi et stort tema. EPEL regnes som trygt for bruk i enterprise-sammenheng, og følgelig behøver ikke Red Hat gjøre dobbeltarbeid for å tilby samme utvalg. EPEL står tross alt for Extra Packages Enterprise Linux.

 

Et RHEL/CentOS miljø er faktisk ganske enkelt å forholde seg til gjennom hele livssyklusen til systemet, fra installasjon til dekommisjonering. Red Hat er nøye med å sørge for kontinuitet fra en major til en annen. Og det er viktig. Nå i RHEL 7 kommer det riktignok en del nytt, men de sørger for at overgangen ikke blir unødvendig brå.

[rockPaperScissors()]

Ja, men RHEL 6.6 leveres blant annet med PHP 5.3, Zend endte sin community-støtte for PHP 5.3 i fjor. RH leverer riktignok sikkerhetsoppdateringer på sine egne pakker, men PHP 5.3 eller bedre er minstekrav for en rekke webrammeverk blant annet. Symfony: 5.3, CakePHP: PHP 5.4, Laravel: PHP 5.4, FuelPHP: PHP 5.3, Phalcon: PHP 5.3... Debian kommer med PHP 5.4 i Wheezy, som snart erstattes av Jessie som kommer med PHP 5.6. PHP versjonen i RHEL 5 er for utdatert til å kjøre WordPress til og med.

 

Mulig alt dette løses med oppdateringer fra EPEL, men det vet jeg ikke.

 

Utenom dette så forstår jeg at RHEL har sin plass, og jeg har ikke noe i mot RHEL/CentOS/Fedora bortsett fra at jeg synes Debian/Ubuntu passer meg litt bedre.

[kpolberg]

RedHat software collections gir deg supportert(tror jeg) PHP 5.4 på RHEL 6

[stigfjel]

Ja, men RHEL 6.6 leveres blant annet med PHP 5.3, Zend endte sin community-støtte for PHP 5.3 i fjor. RH leverer riktignok sikkerhetsoppdateringer på sine egne pakker, men PHP 5.3 eller bedre er minstekrav for en rekke webrammeverk blant annet. Symfony: 5.3, CakePHP: PHP 5.4, Laravel: PHP 5.4, FuelPHP: PHP 5.3, Phalcon: PHP 5.3... Debian kommer med PHP 5.4 i Wheezy, som snart erstattes av Jessie som kommer med PHP 5.6. PHP versjonen i RHEL 5 er for utdatert til å kjøre WordPress til og med.

 

Mulig alt dette løses med oppdateringer fra EPEL, men det vet jeg ikke.

 

Utenom dette så forstår jeg at RHEL har sin plass, og jeg har ikke noe i mot RHEL/CentOS/Fedora bortsett fra at jeg synes Debian/Ubuntu passer meg litt bedre.

Det er ikke helt riktig. PHP 5.4 kan leveres også til RHEL 6, ta en titt her. Og støtten er offisiell fra Red Hat (Edit: ja, kpolberg, Red Hat Software Collections). Tilgang til dette avhenger av hvilket abonnement man har hos Red Hat. Og dette er noe som skiller RHEL fra CentOS. Men skal man installere noe nytt er det åpenbart at man bør velge RHEL/CentOS 7.

 

Edit: og PEAR/PECL biblioteker er inkludert.

 

Hva RHEL 5 angår, det er mulig å få PHP 5.3 på RHEL 5 (var vel i 5.5 at PHP 5.3 ble sluppet). Jeg har selv installert dette, da vi kjørte applikasjoner på RHEL 5 som krevde PHP 5.3. Men denne var ikke optimal, da mange PECL og PEAR biblioteker manglet i denne implementasjonen. Så vi migrerte denne serveren etter hvert til RHEL 6.

 

Edit: I dag er jo RHEL 5 i production level 3, dvs at det kun blir sluppet sikkerhetsoppdateringer. Det er ikke meningen å kjøre nye, ferske applikasjoner på RHEL 5, men legacy applikasjoner som fortsatt må kjøre. Da er det viktig at man fortsatt kan få sikkerhetsoppdateringer. Altså, RHEL 5 ble sluppet i 2007, det er 8 år siden. Og RHEL 5 er fortsatt supportert fra Red Hat. Hvilke andre releaser av linux-distroer sluppet i 2007 har fortsatt support den dag i dag?

Endret 28. mars 2015 av stigfjel

[Lycantrophe]

Ja, men RHEL 6.6 leveres blant annet med PHP 5.3, Zend endte sin community-støtte for PHP 5.3 i fjor. RH leverer riktignok sikkerhetsoppdateringer på sine egne pakker, men PHP 5.3 eller bedre er minstekrav for en rekke webrammeverk blant annet. Symfony: 5.3, CakePHP: PHP 5.4, Laravel: PHP 5.4, FuelPHP: PHP 5.3, Phalcon: PHP 5.3... Debian kommer med PHP 5.4 i Wheezy, som snart erstattes av Jessie som kommer med PHP 5.6. PHP versjonen i RHEL 5 er for utdatert til å kjøre WordPress til og med.

 

Mulig alt dette løses med oppdateringer fra EPEL, men det vet jeg ikke.

 

Utenom dette så forstår jeg at RHEL har sin plass, og jeg har ikke noe i mot RHEL/CentOS/Fedora bortsett fra at jeg synes Debian/Ubuntu passer meg litt bedre.

>php

[rockPaperScissors()]

Ah, det er positivt at RH bidrar med "Software Collections" med mer oppdaterte pakker, det gjør RHEL litt lettere å bruke. Jeg ser også at "Software Collections" støttes i tre år for produksjon, og to år for utviklerversjon (link). Da ender man med omtrent samme livssyklus som med Debian ser det ut til.

[stigfjel]

Ah, det er positivt at RH bidrar med "Software Collections" med mer oppdaterte pakker, det gjør RHEL litt lettere å bruke. Jeg ser også at "Software Collections" støttes i tre år for produksjon, og to år for utviklerversjon (link). Da ender man med omtrent samme livssyklus som med Debian ser det ut til.

Men det er for Software Collections. En major release i seg selv har 10 års levetid etter release (edit: man kan kjøpe support for ytterligere 3 år oppå de 10). Det er det ingen andre linux-distroer som slår. Og CentOS følger RHEL (edit: bortsett fra kjøp av ekstra 3 års support). Dessuten, Red Hat sponser nå også CentOS ved at de har et par core-utviklere for CentOS på sin lønningsliste. Det trygger fremtiden til CentOS på en helt annen måte enn før. Skrekkeksemplet på sånn det kunne være i CentOS var fra desember 2010 til juni/juli 2011 da det ikke ble sluppet en eneste sikkerhetsoppdatering til CentOS grunnet interne stridigheter. Red Hat rakk å slippe RHEL 6.0 og 6.1, en minor release av RHEL 5 og RHEL 4 samt mengder av oppdateringer før CentOS fikk ut fingeren.

Endret 28. mars 2015 av stigfjel

[rockPaperScissors()]

Hvordan fungerer det, kan man oppgradere "Software Collection" etter tre år eller må man oppgradere til senere versjon av RHEL?

[stigfjel]

Hvordan fungerer det, kan man oppgradere "Software Collection" etter tre år eller må man oppgradere til senere versjon av RHEL?

Det er jeg faktisk ikke helt sikker på. Men, Software Collection er en "channel", eller repository, på samme måte som base, optional, supplementary osv. Gitt at det er tilfelle kan man i så fall bytte eller legge til en ny software channel på eksisterende system.

 

Edit: gitt at repoet er støttet for den enkelte major release.

Endret 28. mars 2015 av stigfjel

[rockPaperScissors()]

>php

 

> php > Windows && proprietary

 

 

wq!

[Lycantrophe]

disgusting

[rockPaperScissors()]

disgusting

 

Det kommer veldig an på arbeidsplassen også, kan ikke bare tenke på språket som brukes i isolasjon.

 

PHP 7 kommer med støtte for scalar type hinting som gjør det akkurat innenfor. Selvfølgelig ikke uten kompromisser, som at PHP bruker svak type sjekking (slik som PHP ellers hånderer det) med mindre "strict mode" er aktivert øverst i filen. Det er for ett språk hvor type hinting er valgfritt i utgangspunktet.

[Lycantrophe]

Selvfølgelig kan man det og det er fortsatt en vederstyggelighet.

[rockPaperScissors()]

Bra for deg om du har så spesifikke behov for det gjør jo valg av arbeidsgiver enklere.

Endret 29. mars 2015 av rockPaperScissors()

[Lycantrophe]

Ja.

[rockPaperScissors()]

Etter min erfaring gir programmeringsspråket som brukes ingen garanti for at man unngår å måtte lappe på gammel cowboy-kode, at man må forholde seg til ett team på én, eller at de eksisterende utviklerne ikke kjenner til smidige teknikker. Det har fjernet både en og to illusjoner for min del.

[Lycantrophe]

Nei, men det er bedre å forholde seg til folk som er 70% cowboy enn 100% cowboy.