Oracle kondigt Oracle Autonomous Linux aan

Oracle heeft tijdens zijn Code One 2019-conferentie Oracle Autonomous Linux aangekondigd, een besturingssysteem dat patches, updates en configuraties doorvoert zonder menselijke tussenkomst en zonder enige downtime.

Oracle Autonomous Linux is gebaseerd op vooraf geconfigureerde Oracle Linux-images en het doel is om handmatig OS-beheer tot iets van het verleden te maken. De software ontvangt onder andere automatisch beveiligingsupdates voor de Linux-kernel en user space libraries zonder dat rebooten nodig is. Voor de kernelupdates zonder downtime zet Oracle zijn KSplice-techniek in.

Ook diagnostiek en het configureren en optimaliseren van het OS moeten automatisch verlopen. Oracle claimt patches voorafgaand aan de verspreiding grondig te testen op basis van ontvangen diagnostische gegevens om te voorkomen dat een update de compatibiliteit van applicaties ongedaan maakt.

Onder andere Red Hat-applicaties moeten ongewijzigd kunnen draaien op Oracle Autonomous Linux. Het OS is in combinatie met Oracle Premier Support gratis voor klanten die Oracle Cloud Infrastructure-diensten afnemen.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (88)

Volgens mij wordt er vergeten dat sommige patches alsnog een reboot van het systeem vereisen. Het fixen van veel recente CPU bugs (zoals de Spectre varianten) vereist een update in de microcode en dan kun je niet anders dan een reboot doen.Je zult dus altijd soms downtime hebben. Om dat op te lossen kun je natuurlijk redundantie in je systemen maken, bijv. een hot-standby situatie, maar dan kun je sowieso al je servers zonder downtime updaten door altijd de inactieve server te updaten. Dus op dat punt zie ik maar weinig voordelen.

Wie anno 2019 reboot als een issue ziet voor de uptime van zijn platform heeft me dunkt de afgelopen 10 jaar toch onder een steen gelegen. No offence maar er zijn legio mogelijkheden om dit vlot en transparant te laten verlopen zonder grote issues. Servers = cattle not pets / Ik heb al omgevingen gebouwd waar we zelfs servers niet updaten. We rolden gewoon nieuwe uit en schoten de oude af.

Ah, ik leef al 10 jaar onder een steen.

En ik maar denken dat die steen realiteit heette en veelal gevoed werd door beperkt budget en niet schaalbare software.

Doe mij een kaartje naar dat Utopia waar je zit.

Gelukkig wordt die Utopia gecreëerd in de cloud. Nee, het is niet allemaal fantastisch maar veel cloud producten worden gemaakt met de "pets & cattle" mentaliteit. Denk je dat Microsoft servers patched? Nee, rollen ook gewoon geheel nieuwe servers uit. Of Google? Of Amazon? Denk je dat die oude software daar goed draait?

Gebruikers pikken die oude shit ook niet meer. Thuis hebben ze het nog beter voor elkaar dan "op de zaak". Schaduw IT overheerst en op een gegeven moment knapt de boel. Dan moet er wel vernieuwd worden en gooien ze de oude bende eruit.

Heel eerlijk, als je IT baan gevoed wordt door beperkt budget en niet schaalbare software dan zou ik weg gaan. Je bent een IT-er, een automatiseerder, geen historicus... Jouw carrière leid nu ook alleen maar onder de tekortkomingen van een ander.

Tsja dat zijn keuzes, maar er zijn genoeg bedrijven waar er geen budget is om alles volgens de letter te doen. En dikwijls is het idee, we gaan het zo doen ... en tegen dat we daar zijn is het budget op, of is er een andere prioriteit (omdat een 3de partij dingen wijzigt) en dan wordt het originele doel vergeten of op de lange baan geschoven (lees nooit uitgevoerd). En dan moet je ook maar denken aan wat jij denkt dat belangrijk is ... Ik werk al meer dan 20 jaar ... Heb al vanalles gezien en gedaan, van kleine bedrijven tot fortune 500 companies en (r)overheid .. Nu werk ik voor een kmo op 5km van de deur ... Het is hier soms huilen met de pet op vanwege te weinig budget ... Maar het duurt gemiddeld 8 minuten van het moment dat ik de laptop afzet tot ik de voordeur opendoe ... Dit is overdag en pays the bills. Als freelancer kies ik zelf wt ik doe. IK heb ook nog een paar saas projecten lopende. Daar doe ik wat ik wil ens is alles zoals het zou moeten. Maar overdag kan het mij echt niet meer schelen. Ik zeg het nog 2-3x en leg uit waarom dit een slecht idee is. Je weet toch dat het zal fout lopen dus na een tijdje mag je dan toch je zin doen en zal het wel goed zijn. Want je kan nadien altijd zeggen: weet je nog dat ik zei dat dit een slecht idee was... nu weet je waarom. Na een tijdje snappen de meesten echt wel dat het zo niet verder kan. Snappen ze het niet kan je nog altijd verder gaan. Maar zomaar switchen is niet voor iedereen mogelijk. En dit is niet alleen maar bij een KMO, bijvoorbeeld bij overheidsdiensten verander je ook niet zomaar even iets.

Euh, @dycell en @BitJager brengen het wat rot. Maar ongelijk hebben ze niet. Als je geen budget hebt om zelf een cloud infra op te tuigen dan is het altijd goedkoper om het in azure of aws te deployen.

Yes, komt omdat we waarschijnlijk in hetzelfde bootje (richting de waterval) hebben gezeten. Dan kun je beter uitstappen en zwaaien naar de vertrekkende boot dan steeds maar blijven roepen dat er een waterval aan komt

Wie anno 2019 reboot als een issue ziet voor de uptime van zijn platform heeft me dunkt de afgelopen 10 jaar toch onder een steen gelegen.

Dat zijn er stiekem best wel veel. Of het nu "onder een steen liggen" is, een gebrek aan geld/tijd, geen realistisch alternatief voor antieke software, of gewoon een ander inzicht is. Volgens mij is het nog zo dat de meeste bedrijven die zelf software hosten dat nog steeds doen op een min of meer klassiek systeem. Tegenwoodig vaak een VM, maar containers zijn nog geen gemeengoed.

Als je over pets & cattle begint impliceer je dat er meerdere systemen aanwezig zijn en ruim voldoende capaciteit en redundantie. Tal van organisaties hebben precies één server waar alles op draait. Dat is geen goed ontwerp, maar wel de realiteit. Oracle zou Oracle niet zijn als ze geen kans zagen om geld te verdienen aan de ellende van een ander.

Dat is inderdaad een goed punt, Oracle en hun agressief business model is gewoon een no-go om voor die club te kiezen.

Ik heb horror verhalen gehoord over extra moeten betalen per gebruikte core, opeens gewijzigde volumes en daardoor gebeld worden door iemand van sales, duur support, etc. Nee, dan is misschien zelf deze techniek uitrollen of kiezen voor een alternatief, mij een betere oplossing.

Het kan aan mij liggen, maar thepiratebay bediende de gehele wereld en was ooit verantwoordelijk voor 75% van het internetverkeer met een serverpark van slechts 4 servers.

Bij een fatsoenlijk ontwerp zijn allerlei containers en het behandelen van servers alsof het vee is, gewoon compleet overbodig...

Alle applicaties die 200 servers of minder nodig hebben, kan men het nog aan met de hand. Als dat niet meer gaat is er altijd nog PXE-boot en het puur vanuit ram draaien i.c.m. een fatsoenlijke SAN waarmee men een heel eind kan komen (lees enkele honderdduizenden servers). Pas als ook dit geen optie meer is, dan worden containers een vereiste. Ik vraag mij echter af of een bestaande partij zich dan inmiddels geen eigen serverpark met custom hardware kan veroorloven.

ooit verantwoordelijk voor 75% van het internetverkeer met een serverpark van slechts 4 servers.

Sowieso was het niet alleen The Pirate Bay, waarschijnlijk was het niet 75% van al het internetverkeer, maar boven alles: dat is niet hoe BitTorrent werkt. Waarschijnlijk ging minder dan een miljoenste van het internetverkeer dat ‘via’ The Pirate Bay liep via hun eigen servers. De rest was allemaal peer-to-peer. Dit is een erg slechte vergelijking.

Sowieso was het niet alleen The Pirate Bay, waarschijnlijk was het niet 75% van al het internetverkeer, maar boven alles: dat is niet hoe BitTorrent werkt. Waarschijnlijk ging minder dan een miljoenste van het internetverkeer dat ‘via’ The Pirate Bay liep via hun eigen servers. De rest was allemaal peer-to-peer. Dit is een erg slechte vergelijking.

Dit klopt, gedeeltelijk....
The piratebay had/heeft ook trackers staan die wel degelijk een behoorlijke belasting krijgen bij dergelijke aantallen.
Daarnaast moet u de belasting op de database en de webservers ook niet onderschatten bij een dergelijke website.

[Reactie gewijzigd door vliegendekat op 18 september 2019 21:27]

No offence maar er zijn legio mogelijkheden om dit vlot en transparant te laten verlopen zonder grote issues. Servers = cattle not pets / Ik heb al omgevingen gebouwd waar we zelfs servers niet updaten. We rolden gewoon nieuwe uit en schoten de oude af.

Dan moeten de applicaties wel een dergelijke infrastructuur ondersteunen. Voor organisaties die houden van het nu schrijven van software die over tien jaar "legacy crap" genoemd wordt is dat geen oplossing.

[Reactie gewijzigd door The Zep Man op 18 september 2019 06:55]

Precies, snap ook niet helemaal wat hier zo bijzonder aan is...

Zat databases die kritisch genoeg zijn dat je niet wil rebooten. daarnaast zijn de licenties van Oracle niet mals en als je een hogere uptime Kan garanderen op deze manier met een goedkoper licentie model kan dat maar zo eens interessant zijn

Oracle Database zonder RAC?
Dan kan dit handig zijn.

Ah je reboot dus wel. Echter laat je andere hardware opkomen met de update of update je de oude server en voeg je die later weer toe.

Ik zie het verschil niet. Je reboot voor updates. Echter je software draait waarschijnlijk door en merkt er weinig van.

Volgens mij wordt er vergeten dat sommige patches alsnog een reboot van het systeem vereisen. Het fixen van veel recente CPU bugs (zoals de Spectre varianten) vereist een update in de microcode en dan kun je niet anders dan een reboot doen.

Je kan de microcode updaten zonder reboot.
Uit het (Debian) pakket 'intel-microcode':

Microcode updates are ephemeral: they will be lost after a processor hard
reset or after the processor is powered off. They must be reapplied at
every boot, as well as after the system wakes up from suspend to RAM or
disk.

Overigens is dit niet het hele verhaal, als het goed is bevat je moederbord ook een module om de microcode van je processor te updaten voordat er een besturingsyteem geboot wordt.

Overigens is dit niet het hele verhaal, als het goed is bevat je moederbord ook een module om de microcode van je processor te updaten voordat er een besturingsyteem geboot wordt.

Dat is gewoon onderdeel van UEFI/de BIOS. Daar kan een microcode update inzitten, maar dat hoeft niet. Tevens kan het besturingssysteem deze microcode update overschrijven, bijvoorbeeld als er een nieuwere beschikbaar is.

Het feit dat microcode-updates bij elke boot opnieuw moeten worden uitgevoerd, wil niet zeggen dat ze ook tijdens het draaien van een besturingssysteem en applicaties kunnen worden gedaan.

Ik snap je niet.
Wat je zegt klopt in theorie, maar in praktijk is het volgens mij nog nooit een probleem geweest.
Heb je een voorbeeld van een patch voor een Intel/AMD-processor uit de afgelopen 10 jaar die niet online kon worden toegepast maar wel offline?

Dat is precies de kracht van Ksplice volgens Oracle dus; ze claimen dat een reboot nooit nodig is.

Oracle Ksplice updates select, critical components of your Oracle Linux installation with all of the important security patches without needing to reboot.

Mjah, een update aan de cpu microcode verandert dus niets aan je Linux installatie (maw, Ksplice gaat je daar niet helpen), ik denk dat dat juist precies het punt van @Cybje is

KSplice past de updates toe aan draaiende in memory kernel.

Ik lees deze quote toch echt anders, imo zeggen ze dat bepaalde kritike delen van je installatie gepatched kunnen worden zonder reboot. Er zijn dus ook delen waar dat niet van toepassing is

Je zult dit altijd behouden denk ik, tevens reboot ik ook af en toe om de caches en ook de /tmp folder even te legen.

Zelf ben ik geen pro server beheerder, maar genoeg die een cluster zitten en dus zonder problemen kunnen worden gereboot.

Ik kan prima de microcode updaten zonder een reboot. Dat is niet bij alle patches nodig.


echo 1 > /sys/devices/system/cpu/microcode/reload

[Reactie gewijzigd door borft op 17 september 2019 15:43]

Niet elke microcode wijziging kun je door middel van late loading toepassen. Dit gaat dacht ik o.a. om wijzigingen waarbij de processor features wijzigen, wat o.a. gebeurde bij sommige patches rondom alle Spectre en Meltdown dingen.

CPU microcode heeft niks met het OS te maken.

Orakel claimt geen autonoom systeem, ze claimen dat ze een autonoom OS hebben ontwikkeld. Da's een klein maar belangrijk verschil.

CPU microcode heeft niks met het OS te maken.

Onwaar. Het is vaak het besturingssysteem die een microcode update zal inladen (vaak tijdens het booten), zeker als de fabrikant niet (op tijd) een BIOS update aanbiedt. In Linux-gebaseerde besturingssystemen is dat de kernel die dit als één van de eerste taken zal doen, mits de bootloader een microcode update image heeft ingeladen.

[Reactie gewijzigd door The Zep Man op 17 september 2019 17:28]

Correct. Ksplice zorgt voor patchen van running kernelonderdelen, niet voor de kernel op disk. Die moet in een later stadium op disk worden gepatcht, zodat een reboot niet meteen geKspliced hoeft te worden.
De patches zijn dan ook bedoeld voor kritieke security patches die geen uitstel dulden en meteen "een gat dichten" in de lopende kernel.
Die patch komt uiteraard van Oracle wat meteen ook het zwakke punt is: je moet zelf een OTAP structuur opzetten voor Ksplice, je wilt echt niet ongetest rechtstreeks vanuit Oracle jouw productiesystemen unattended laten patchen. Maar dan heb je weer een niet gedicht gat ...

Jaja en als het fout gaat of er zit een bug in de patch wat dan?

Ik ben meer benieuwd naar de oplossing voor openstaande handles.

Gaan services/applicaties verplicht hun handles met andere processen opnieuw starten? Gaan de services die op zo'n apparaat draaien gewoon down?

MS is tijdens Windows 7 ook bezig geweest om dat live patchen toe te passen, ik kan het MSDN blogje zo niet terug vinden. Maar die hadden er voor gekozen om de Windows systemen maar te laten herstarten. Want het bleek dat als een process zo'n handle met een gepatchde service open heeft staan, dat een security exploit maanden na patchen via dat process nog steeds exploitbaar bleek te wezen. Of dat een systeem maanden later alsnog onderuit klapt door een process voor het uitvoeren van een functie, dat dus al gepatched bleek te zijn. Ze kwamen tot de conclusie dat de gepatchde onderdelen toch herstart moesten worden, de daarbij horende processen ook. En dat het er eigenlijk op neer kwam, dat je dan beter gewoon het OS maar even kan herstarten.

Bedoel je dat een service waar een exploit in staat open bleef staan? Of dat iets wat in de lagere lagen misging door MS werd gepatched, maar dat een service die daar gebruik van maakte effectief de relevante code in geheugen hield en daardoor alsnog open bleef?

Dat eerste zullen ze wel op de ouderwetse manier oplossen door de specifieke service te herstarten na een update, veel services kunnen er toch niet tegen dat ze 'seamless' over gaan (maar daar is de clustering dan natuurlijk weer voor bedoeld om het transparant te maken).
Dat tweede is inderdaad een interessante vraag. Ook daar kunnen ze inderdaad een voor een elke service op elke node herstarten; maar of ze dat doen?

Dat 2de inderdaad. Een proces zal niet zo snel uit zichzelf een handle heropenen. Tenminste, dat moet in de design keuze van het hele OS en app bouwers meegenomen worden, wil je dat effectief kunnen inzetten. De service zal de oude handles open moeten laten, want zo maar sluiten kan problemen veroorzaken bij de achterliggende processen, tenminste daar is waar MS tegen aan liep. Want dat kwam de stabiliteit van het systeem niet ten goede. Het openhouden komt de security weer niet ten goede.

De handle open houden betekend inderdaad dat de ongepatchde code nog in het geheugen blijft zitten. Terwijl elke nieuw geopende handle wel gepatchde code geserveert krijgt.

MS kwam tot de conclusie "Het is het risico niet waard, geen systeem is belangrijk genoeg dat het nooit down kan, want daar heb je er dan minstens 2 van". Daarom best wel benieuwd hoe Oracle dit aangepakt heeft, of ze dit uberhaupt aangepakt hebben.

Sowieso werkt Linux op dit vlak natuurlijk niet exact hetzelfde als Windows. Wat jij/MS 'handle' noemt, is denkt ik wat men bij Linux 'socket'. Vziw zit daar een vrij scherpe scheiding tussen wat het OS doet en wat de applicatie doet.

Maar het komt sowieso ook voor dat een centrale bibliotheek als libc problemen bevatten. En dat wordt (vziw tegenwoordig gedeeld) in het geheugen van applicaties gedraaid. Ik weet eigenlijk niet eens zeker of applicaties wel opnieuw gestart moeten worden als daar fouten in opgelost worden, maar waarschijnlijk wel...
In het geval van Linux weet het systeem sowieso welke file pointers allemaal in gebruik zijn bij een applicatie en het package management systeem weet welke dependencies er zijn. Dus ze zouden aan de hand van (een combinatie van) die twee kunnen bekijken welke applicaties herstart moeten worden na een update van een service.

Het genoemde KSplice gaat overigens om Kernel-patches. En dat zou ik eerlijk gezegd van verwachten dat dat wel goed gaat. Zolang uiteraard de socket die open is op kernel-niveau netjes omgezet wordt naar de nieuwe kernelcode; maar bij de paar keer dat ik naar die techniek keek gebeurde dat inderdaad.

Maar het komt sowieso ook voor dat een centrale bibliotheek als libc problemen bevatten. En dat wordt (vziw tegenwoordig gedeeld) in het geheugen van applicaties gedraaid. Ik weet eigenlijk niet eens zeker of applicaties wel opnieuw gestart moeten worden als daar fouten in opgelost worden, maar waarschijnlijk wel...

Op het moment dat een applicatie gestart wordt maakt het OS een kopie van alle relevantie libraries naar RAM. Als er meerdere applicaties zijn die dezelfde libraries delen kunnen ze hetzelfde stukje RAM gebruiken, maar ze kunnen die libraries niet veranderen. Die blijven hetzelfde tot de applicatie herstart wordt.

In het geval van Linux weet het systeem sowieso welke file pointers allemaal in gebruik zijn bij een applicatie en het package management systeem weet welke dependencies er zijn. Dus ze zouden aan de hand van (een combinatie van) die twee kunnen bekijken welke applicaties herstart moeten worden na een update van een service.

Dat gebeurt dan ook. Als mijn Debian-systeem upgrades draait krijg ik een overzichtje te zien van applicaties die herstart moeten worden (en het aanbod om dat automatisch te doen).

Nee, een Windows handle is geen Linux socket. Ja, Linux sockets zijn onder Windows wel handles, maar Linux filedescriptors zijn dat ook. En mutexen zijn ook handles. Windows (NT) heeft een behoorlijke OO basis, waardoor je nogal wat verschillende soorten objecten met een handle kun beschrijven. En je kun dan met WaitForMultipleObjects op een mix van handles wachten.

Om het iets complexer te maken, de UI heeft ook handles, en die komen uit Win16, niet uit de NT kernel. Die dingen heten voluit "GDI handles", en daarmee is het probleem zo mogelijk nog erger. Een handle naar file kun je heropenen. Een handle naar een window heropenen kan niet zomaar, dan is je window weg.

Al met al bevestig je wel mijn suggestie dat het in Linux eenvoudiger is en daarmee waarschijnlijker dat ze het goed kunnen oplossen

Ik ben meer benieuwd naar de oplossing voor openstaande handles.

Gaan services/applicaties verplicht hun handles met andere processen opnieuw starten? Gaan de services die op zo'n apparaat draaien gewoon down?

Ze kwamen tot de conclusie dat de gepatchde onderdelen toch herstart moesten worden, de daarbij horende processen ook. En dat het er eigenlijk op neer kwam, dat je dan beter gewoon het OS maar even kan herstarten.

Voor zover ik weet bestaan "handles" zoals windows die gebruikt niet onder Linux, maar het principe van applicaties die samenwerken natuurlijk wel. Een jaar of 10 geleden had Linux er inderdaad ook last van dat applicaties niet om konden gaan met veranderingen in dependencies. Sindsdien is dat probleem grotendeels opgelost, enerzijds door de communicatie tussen applicaties slimmer te laten lopen, anderzijds door goed bij te houden hoe de afhankelijkheden lopen, zodat je gericht de software kan herstarten, en alleen als het echt niet anders kan de gebruiker adviseren om te rebooten.

En de laatste W10 updates niks anders dan problemen.

Ik heb het nog niet gered om een Linux installatie te doen binnen een minuut, het downloaden en maken van een installatie usb duurt al langer. Als je het over de grote updates hebt, dan is dat nogal logisch dat die wat langer duren (bij mij +- een half uurtje), dat is een nieuwe build, en dus praktisch een nieuwe Windows versie.

Ik heb het nog niet gered om een Linux installatie te doen binnen een minuut

Een Windows installatie doe je ook niet binnen een minuut. Ik vind Linux op dat vlak toch ook beter dan Windows met zo'n geforceerde updates. Ook het installatieprocess vind ik bij Windows met z'n first account setup ook zo omslachtig lijken, maar dat is alleen omdat het niet transparant is waarmee het nu eigenlijk bezig is.

Maar er werd gezegd dat een Linux install sneller te doen was dan een Windows update. Daar reageerde ik op.

Mijn updates duren in ieder geval niet 1 minuut, als je dan toch "correct" wil zijn? Ik neem er geen stopwatch bij, maar ik zit soms toch een tijdje met m'n duimen te draaien wanneer Windows een update wil doen.

Hoezo fanboy? Windows updates duren over het algemeen minder lang dan het downloaden van een Linux iso, bootable usb maken, dan de installatie, en daarna nog eventueel updates. Waar je weghaalt dat ik een fanboy ben weet ik niet, maar als ik de keuze had op mijn werk laptop, had ik Linux geïnstalleerd. Privé heb ik nog liever Mac os. Maar zeggen dat je sneller een complete Linux installatie kan doen dan een Windows update klopt gewoon niet in veel gevallen.

Simpelgestelde vraag, maar in essentie klopt dat wel. Waar komt de verantwoordelijkheid te liggen als er blijkt dat door deze auto-patching de boel omkiepert?

Gezien het om Oracle gaat, zullen ze dit wel juridisch afdekken op een of andere manier.

Het lijkt me sterk dat een gratis besturingssysteem niet met een of andere afwijzing van alle verantwoordelijkheid in hun EULA zou komen opdraven. En dat is hun volste recht natuurlijk.

Maar dan zie ik meteen een zeer grote reden om dit nooit te gebruiken. Je hebt geen controle over je systeem en Oracle neemt de verantwoordelijkheid niet. Daar zit je dan als er iets fout gaat en je data kwijt bent of je toepassing werken niet meer.

En welk OS geeft dan wel een garantie dat een bug je niets kost?

Bij enige andere server software test je zelf eerst elke patch of die geen effect heeft op de geïnstalleerde applicaties. Hier is dat niet mogelijk zover ik het begrijp.

Het lijkt me sterk dat een gratis besturingssysteem niet met een of andere afwijzing van alle verantwoordelijkheid in hun EULA zou komen opdraven. En dat is hun volste recht natuurlijk.

Ga er maar van uit, want alle commerciele OS'en doen hetzelfde. Als er bv een kras op je Windows CD zit dan krijg je daar garantie op, op bugs in de software zit geen garantie.

Jaja en als het fout gaat of er zit een bug in de patch wat dan?

Je doet alsof het met handmatig patchen nooit fout gaat...

De vraag is gaat met minder of vaker fout, wat zijn daar de gevolgen en dus kosten aan, wat gaat dit kosten en wat bespaart het (qua kosten). Dat is een rekensommetje welke niet gelijk zal zijn voor elk bedrijf...

Dan crasht het en moet je herstarten.
Hoe is dat anders dan ieder ander stuk software?
Alle software bevat fouten. Alle software gaat af en toe stuk.
Ik neem aan dat Oracle nergens beloofd dat een systeem nooit meer stuk gaat, alleen dat je voor reguliere patches niet meer hoeft te rebooten.

Oracle brengt volgens mij nog steeds hun 'Unbreakable Linux" versie aan. En voor zover ik weet ook helemaal gratis, zelfs voor commercieel gebruik.

Dat is zo'n beetje de enige uitzondering op hun software-aanbod, waar je zo'n beetje alleen met de ziel
van je net geboren zoon/dochter kunt betalen (op jaarlijkse basis). Maar goed, je krijgt als afnemer een speciale "bonus" wanneer je met de 7e ziel betaald, in het jaar dat je bedrijf 7 jaar bestaat...of zoiets.

Jaja en als het fout gaat of er zit een bug in de patch wat dan?

Dan werkt het niet goed. Zullen we dan maar niets meer proberen te verbeteren omdat het toch nooit perfect wordt?

Zullen we alle RI&E's dan maar afschaffen? Natuurlijk niet

Ik zou niet de eerste en niet de 100ste willen zijn om dit te implementeren. Het risico is ondanks grondig testen gewoon best groot. Een lab is geen echte wereld tenslotte.

Oracle kennende zal er wel weer een enorm complexe en dure licentiemechanisme achter zitten.

Dat lijkt deze keer mee te vallen. Het wordt zonder kosten aangeboden als je al klant van de oracle cloud bent.

... wat het punt van bovenstaande bewijst: Oracle Cloud: een enorm complex en duur licentiemechanisme

Hahaha. Is er iets wel betaalbaar bij ze? En kom niet met de OSS projecten die ze van Sun geerft hebben, volgens mij zijn ze allemaal geforked omdat ze allemaal zo gelukkig waren met Oracle.

MySQL -> MariaDB
OpenOffice -> LibreOffice

Nu ja goed, Java komt nog vandaar, maar sinds de overname is het gebruik van OpenJDK volgens mij ook redelijk toegenomen.

En ZFS terug naar proprietary code (voor nwe ontwikkelingen van uit Oracle iig).

Oracle JDK is al niet meer gratis

Oracle JDK is nog steeds gratis alleen op productie voor commercieel gebruik niet meer.

En die 26 euro of minder per jaar voor 1 licentie. Dat kan een bedrijf gemakkelijk opbrengen. Als je dat niet kan opbrengen dan is er iets mis met de prijs die je vraagt aan de klant.

https://shop.oracle.com/a...,123775488249871532594385
Quantity
List Price/Term

1+
€26.94

1000+
€21.55

3000+
€18.86

10000+
€16.17

20000+
€13.47

[Reactie gewijzigd door Cobalt op 17 september 2019 20:11]

Ja, natuurlijk

Oracle wil voor iedere core op je cluster een licentie ook al is er maar 1 applicatie op een vm met 2 cores die de JDK gebruikt. Bij oracle rekent men namelijk het gezamenlijke cluster af want dat zorgt voor de performance. Dus als je een bescheiden oracle cluster hebt met 256 cores, betaal je 256 x die 27 euro voor 1 applicatie die gebruik maakt van dat onderdeel.

Dat is het licentiemodel van Oracle: Je betaalt voor de alle plekken in de parkeergarage omdat je potentieel op alle plekken kunt parkeren.

Totdat je een keer een restore wil uitvoeren. Dan gaat de teller enorm omhoog... Oracle heeft heel slim de kosten zo verwerkt dat het niet veel lijkt, maar uiteindelijk ben je zeker niet goedkoper uit in vergelijk met onpremise. Vooral managers zijn erg gevoelig om deze kosten niet op te merken.

Verder is het niet bijzonder om patches door te voeren zonder downtime. Het is maar net hoe de automation is opgezet en uitgevoerd wordt. Liefst rol je eigenlijk liever een nieuwe uit en wordt de oude uitgefaseerd.

[Reactie gewijzigd door vali op 17 september 2019 17:10]

Zelfde kun je prima voor elkaar krijgen met CentOS. Die heeft na updates ook geen reboot nodig - in tegenstelling tot Ubuntu Server.

Dit gaat niet enkel om updates zonder reboot. Het gaat om net iets meer dan dat, volgens het artikel.

Mijn Ubuntu Server heeft al een tijd LivePatches aanstaan. Wat gewoon dit is: kernel updaten terwijl die draait. https://ubuntu.com/livepatch

Blijkbaar heeft Oracle inderdaad het bedrijf ksplice ooit gekocht: https://en.wikipedia.org/wiki/Ksplice
Dat wist ik nog niet. Interessant!

Het wordt nergens echt hard genoemd, volgens mij is dit alleen beschikbaar op de Oracle Cloud infrastructuur.
Je kan het dus niet zelf on-premise gaan draaien op je eigen stuk ijzer of virtualisatie platform.

En dat maakt de boel natuurlijk al een heel stuk eenvoudiger.
Het draait namelijk niet meer direct op fysieke hardware, dus een heleboel hardware afhankelijkheden (microcode bijvoorbeeld) kun je al direct wegstrepen.
Vervolgens hoeft je geen rekening te houden met allerlei vormen van virtualisatie omdat er maar 1 soort bestaat: degene die Oracle zelf beheert.

In feite hou je dus maar één super specifiek platform over waar je kernelupdates uitvoert.
En die zijn uiteraard uitvoerig getest, wat weer snel kan omdat er maar 1 platform is......

Dus eigenlijk vindt ik het dan niet zo knap dat men dat kan.
Ik zou het zelfs ongelooflijk slecht vinden als ze dat NIET zouden kunnen.

En toch zal het waarschijnlijk wel een keer kapot gaan tijdens het upgraden. Want hoe grondig je het ook test, we zijn en blijven mensen

Op een aantal on premise systemen met Oracle x86 draait de Ksplice daemon al een aantal jaren, Oracle Linux heeft dat standaard aan boord. Wle moet je rekening houden dat je simpelweg de running kernel zit te patchen in memory, op disk moet de normale patch procedure nog volgen. Feitelijk is het een extraatje om in een running kernel zero day gaten te dichten en daarna in een maintenance window de kernel on disk te patchen en te rebooten.

Blijf me verbazen over de arrogantie die ook weer in deze productnaam schuilt. Het doel is vast dat er minder beheer op nodig is, maar dat maakt het nog niet autonoom. Net als dat "Unbreakable Linux" een paar beveiligings features toevoegde aan hun fork van Red Hat, maar zeker niet unbreakable was. Ach... als je ooit te maken hebt gehad met Oracle verkopers dan valt die arrogantie wel weer op zijn plaats.

Fedora Silverblue is eigenlijk al wat Oracle Autonomous Linux pretendeert te zijn.

Oracle zegt RHEL te ondersteunen (geen idee wat ze daar mee bedoelen) maar even zwart-wit gezien zou het verstandiger te zijn voor de upstream van RedHat (Fedora Silverblue) te kiezen zodat je zeker bent van superieure stabiliteit tegen 0 kosten.
Mocht je support willen dan kun je altijd nog een licentie nemen bij RedHat.

Het probleem van Fedora is niet dat het OS niet 'stabiel' zou zijn om op te draaien, maar je eigenlijk verplicht bent elk jaar een grote update te doen en ook minor upgrades redelijk heftige wijzigingen kunnen bevatten. In die zin is het systeem niet 'stabiel' als het een eis is dat software die je erop deployed het jaren probleemloos doet (wat met RHEL of CentOS wel het geval is).

In dat geval is Fedora SilverBlue ideaal voor je aangezien die het OS zelf in een container plaatst. Eigenlijk worden er geen wijzigingen meer gedaan aan de core.
Als je niet wil updaten kun je inderdaad beter op RHEL gaan zitten maar dan mis je ook een hoop gave ontwikkelingen.
Op wat wifi drivers na heb ik nooit issues gehad met grote updates. Ik werk als developer en het heeft verschillende voordelen om op Fedora te werken. Het is gewoon RHEL wat betekent dat er bij releases naar productie (CentOS) nooit compatibiliteitsproblemen zijn.

Goede ontwikkeling. Ik heb de details nog niet gelezen, maar vraag me gelijk al af hoe ksplice afvangt dat tijdens updates regelmatig wordt gevraagd of je de nieuwe versie of de bestaande versie van een conf bestand wil gebruiken.

Oracle heeft KSplice opgekocht, en zoals vaker met door Oracle overgenomen producten, ze willen er dik aan verdienen.
Enige positieve wat ik nog kan vermelden hierover is dat ze voor desktop users wel een gratis versie ter beschikking stellen.
Er is ook een alternatief, genaamd KernelCare https://patches.kernelcare.com/

Dus er is meer keuze gelukkig voor het live patchen van je systeem zonder te rebooten.

[Reactie gewijzigd door Cynosure op 18 september 2019 08:33]