Software-update: Debian GNU/Linux 10.4

Debian is een opensource-besturingssysteem, dat zowel voor desktops als servers gebruikt kan worden en waarbij de nadruk op stabiliteit en veiligheid ligt. Het wordt dan ook als basis voor diverse Linux-distributies gebruikt, waaronder Ubuntu en Linux Mint. Versie 10.x, die als codenaam 'Buster' meegekregen heeft, is een zogenaamde Long Term Support-uitgave en zal de komende vijf jaar van updates worden voorzien. De release notes voor deze update kunnen hieronder worden gevonden.

Debian 10.4 buster released

The Debian project is pleased to announce the fourth update of its stable distribution Debian 10 (codename buster). This point release mainly adds corrections for security issues, along with a few adjustments for serious problems. Security advisories have already been published separately and are referenced where available.

Please note that the point release does not constitute a new version of Debian 10 but only updates some of the packages included. There is no need to throw away old buster media. After installation, packages can be upgraded to the current versions using an up-to-date Debian mirror.

Those who frequently install updates from security.debian.org won't have to update many packages, and most such updates are included in the point release.

New installation images will be available soon at the regular locations.

Upgrading an existing installation to this revision can be achieved by pointing the package management system at one of Debian's many HTTP mirrors. A comprehensive list of mirrors is available here.

Versienummer	10.4
Releasestatus	Final
Besturingssystemen	Linux
Website	Debian
Download	https://www.debian.org/releases/stable/
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (123)

[UPPERKEES]

waarbij de nadruk op stabiliteit en veiligheid ligt

Ik vind dit zo'n rare beschrijving. Men associeert Debian vaak met deze eigenschappen. Maar andere distributies hebben ook gewoon deze kwaliteitseisen. Als een distributie tijdens zijn release geen APIs en ABIs sloopt, dan is die stable. Als die security en functional updates snel doorvoert, dan is het functioneel stabiel en veilig. Fedora bijvoorbeeld ook, released relatief bleeding edge, maar is ook gewoon stable en veilig. Met SELinux misschien wel een van de veiligste distro's. En omdat het in sync is met upstream patches ook een functioneel stabieler.

Maar neem PHP bijvoorbeeld in Stretch. Daar draai je PHP 7.0, die is sinds januari 2019 end-of-life. Debian zegt zelf al dat het lastig is om deze oude versies veilig te houden in samenwerking met upstream.

Vergelijk dat met CentOS bijvoorbeeld. Je kan gewoon upgraden naar verschillende supported PHP versies. Geen PPA of 3rd party crap, gewoon van je distro zelf. Zoals het hoort.

Ook als je een bug hebt in bijvoorbeeld GNOME, en je wil Debian Stable voor 2-5 jaar gebruiken. Dan moet je daar gewoon mee leven. Want je krijgt in die lifecycle geen upgrade meer...

Vergelijk dat maar weer eens met CentOS 7, released in 2014 en draait momenteel GNOME 3.28 (2018). Het loopt niet in sync met upstream. Maar Red Hat is een heavy GNOME contributor, dat dus in combinatie met upgrades tijdens de release, dan geeft dat toch een stuk meer vertrouwen in stability en security.

En dan hebben we het nog niet eens gehad over de kernel... Daar zou ik Red Hat ook meer in vertrouwen. Aangezien Red Hat op Intel na de grootste code contributor is.

[Reactie gewijzigd door UPPERKEES op 25 juli 2024 12:33]

[Verwijderd]

Ik vind dit zo'n rare comment. Je klaagt dat een oude versie van debian (9.0, release uit 2017 ipv 10.0 waar dit artikel over gaat) in de standaard repo's niet PHP upgraded van 7.0 naar 7.3.

Als je serieus bezig bent met een webserver dan compile je je software zelf met features naar smaak ipv dat je de software uit de repo's gebruikt. En laat het voor de nieuwkomers onder ons duidelijk zijn dat je de laatste versie van PHP zonder problemen kan compilen voor Debian (10.0, 9.0, ...)

De meeste systeembeheerders zullen niet blij zijn dat de commands

sudo apt update && sudo apt upgrade

PHP van 7.X naar 7.Y upgraden,

Debian is dus ideaal als je precies weet wat je nodig hebt en ook weet hoe je dit configureerd. De dstro's die jij aanhaalt werken prettiger als je gewoon wilt gebruiken wat je wordt aangeboden en niet bezig wilt zijn met het vooruitplannen van je IT infrastructuur. (thuisgebruiker vs business processen). Vandaar dat Debian (terecht) door tweakers als stabiel wordt aangemerkt. Juist omdat dit soort zaken zo zijn geregeld.

Ik gebruik Debian zelf niet eens maar moest dit toch even commenten op een +2 post geschreven door een leek.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 12:33]

[UPPERKEES]

Debian 9 is nog steeds supported en dezelfde community pronkt met dezelfde termen zoals stabiel en secure. Terwijl dat helemaal niet uniek is. Ik vergelijk inderdaad met een oude Debian versie, met een oude CentOS versie. Waar een oude CentOS wel de mogelijkheid geeft om een upstream supported en current pentested versie te draaien van bijvoorbeeld PHP. Wanneer je dat niet hebt, gaat je stability en security support verloren.

Je update overigens nooit van 7.0 naar 7.3 door een `yum upgrade` in bijvoorbeeld CentOS. Dat dat is een andere package en is dus een bewuste keuze om die upgrade te doen. In CentOS 8/RHEL 8/Fedora is dit nog beter, met modularity.

Je wil verder absoluut niet als system engineer je eigen distributie managen door je eigen software te gaan beheren. Daar heb je een distributie voor, die voor jou de juiste software distribueert met de eventuele juiste upstream patches en security fixes. Zodra je zelf moet compilen is er iets fouts aan de hand. Zoiets is optioneel en dat is in sommige gevallen een voorkeur. Maar dat moet echt niet de enige keuze zijn. Dan heb je geen goede distributie.

[Reactie gewijzigd door UPPERKEES op 25 juli 2024 12:33]

[Verwijderd]

Jij wilt dat misschien niet maar als je business process in bijvoorbeeld PHP draait (of welke applicatie dan ook) dan compile je dat toch echt wel zelf. Repositories zijn er zodat thuisgebruikers kant en klare binaries kunnen downloaden zonder keuze welke compile flags je wel of niet meeneemt. Dat is echt geen optie in kritieke processen waar je de verantwoordelijkheid draagt over de bereikbaarheid.

Iedereen mag natuurlijk kiezen waar een distributie voor is en waarom een distributie voor jou de juiste is. Maar ik kan je vertellen dat voor mij en vele anderen distributies er zeker niet zijn om pre comipled binaries van open source software te verspreiden.

Ook je verhaal van support vanuit de distributie is een beetje een vaag verhaal, als jou webserver problemen ondervindt dan klop je aan bij je distributie en zij gaan het voor je fixen? Of bedoel je met ondersteuning dat er iemand is die bij iedere update van PHP de code download, compiled & upload naar de repository? Super chill dat iemand dat doet maar de gebruikers van Debian hebben nou eenmaal weinig interesse in pre compiled binaries, ongeacht hoe up-to-date ze ook zijn simpelweg omdat deze ongetwijfeld zijn compiled met andere opties dan optimaal is voor de situatie.

[UPPERKEES]

Again, dat is dan een keuze. Maar Debian dwingt je tot die keuze. Dat is een fout teken. Je moet op je distributie kunnen bouwen. Je zou packages moeten kunnen installeren en erop moeten kunnen vertrouwen dat je distro security patches tijdig beschikbaar maakt zodra upstream ze beschikbaar maakt. Als je PHP geen upstream support heeft en je geen optie geeft om dat wel te gebruiken. Dan gaat dat hele motto van "Debian is stable en secure" gewoon verloren. Dat is het enige punt dat ik aankaart. Debian is daar niet speciaal in. Ik gebruikte Debian 9 als voorbeeld, maar hetzelfde probleem ga je straks zien met Debian 10. En dat is alleen nog maar op PHP gebied.

Wat je verder zegt doet mij eigenlijk twijfelen aan je ervaring als system engineer.

Repositories zijn voor thuisgebruikers? Kritieke processen waar je verantwoordelijk voor bent ga je per definitie zelf compileren in plaats van de hard tested packages van je distro? Een distro is er niet om pre compiled binaries te verspreiden? Je aannames kunnen bijna niet verder van de praktijk zijn.

Zeg eens eerlijk, wat is je exacte achtergrond als system engineer? Want je zegt rare dingen met volle overtuiging. Ik kan je vertellen als HPC engineer met bijna 10 jaar ervaring, en met een MSc in system engineering, dat het niet zo werkt. Je compiled dingen, wanneer het echt nodig is. Maar dan moet je zelf daar de verantwoordelijkheid dragen dat het goed werkt met de distributie, goed gepatched is en goed getest is. Als je distro dat al voor je kan doen, dan neem je dat voor lief en besteed je je tijd in echt werk in plaats van je eigen distro te starten. Daar is een distro voor. Zodra je zelf moet compilen of 3rd party repos moet gebruiken om niet in gevaar te komen in de zin van security of stability, dan is het tijd om van distro te hoppen.

[Xander2]

Debian is actief met patchen gedurende LTS periode, voor b.v. PHP7.0 https://security-tracker....ker/source-package/php7.0 ongeacht upstream support.

[UPPERKEES]

True, maar ze geven zelf ook toe dat het een struggle is om alles bij te houden. Verder als je upstream source de stekker eruit trekt verlies je gewoon de dedicated resource voor security en functional updates. Zelf meuk fixen is natuurlijk een optie, maar het is niet de meest ideale optie. Helemaal niet als je geen eigen grote resource pool hebt. Red Hat zie ik het nog wel goed doen, Canonical zie ik het nog wel doen. Maar Debian heeft niet dezelfde backing. Wel kunnen ze misschien terugvallen op Canonical developers.

[Xander2]

Er zit wel enige kruisbestuiving tussen RHEL, Debian en Ubuntu qua security issues.

Package management van populaire programmeertalen als PHP, Ruby en NodeJS is niet te doen bij korte release cycles waar current eigenlijk de enige supported is.

Ik weet niet exact hoe het werkt sinds Murdock's overlijden, daarvoor werden stable packages door security gemanaged en liep Debian vooraan met hotfixes.

[JustRoy]

Met stability wordt soms ook bedoeld: weinig grote veranderingen, zodat niets (custom) "stuk" gaat. Dingen blijven vaak heel lang hetzelfde werken. Maar, inderdaad, heel veel distributies hebben deze eigenschap, zoals Centos/RHEL. Ik denk dat Ubuntu hier meer een uitzondering. Het loopt wel stabiel, dwz geen crashes, maar er verandert wel een en ander. Voor systeembeheerders kan dit lastiger zijn, omdat nieuwe features makkelijker (menselijke) fouten introduceert.

[UPPERKEES]

De definitie stable is dat je geen APIs en ABIs breekt door de lifetime van een release.

[beerse]

Dat is jou definitie van stabiel. Wat als er software bug-driven gebruik maakt van de api en de bug wordt er uit gehaald? Is het dan de beveiliging die de patch er uit mag halen? Of ga je klagen omdat jou applicatie niet meer werkt terwijl die applicatie juist gebruik maakte van de bug?

[UPPERKEES]

Dat is niet mijn definitie. Dat is de definitie. Een bug in een API of ABI moet gewoon gefixed worden natuurlijk.

[beerse]

Ooit 'de' definitie gehoord van een stabiel operating syteem: "Als/zodra er geen patches meer voor uit komen, dan is het stabiel genoeg om te gebruiken."

Voor veel linux distributies is het vast houden aan de versies van de gebruikte onderdelen 'stabiel'. Dat is de reden voor veel back-ports van updates uit hogere versies naar de in distributies gebruikte versies.

Aan de andere kant van het spectrum beschouw ik Kali linux en Windows 10 ook als stabiels; De leveranciers beloven dat er geen echt nieuwe grote versies meer van uit komen, alleen nog maar 'roling releases' en kleinere updates van de gebruikte onderdelen.

Oracle had ooit (1999) een mooie definitie van de versie nummers die uit 5 delen bestaat:
- 1 voor build-nummers
- 1 voor patches (bugs er uit)
- 1 voor updates (extra parameters, eventueel een uitbreiding maar behoud van bestaand)
- 1 voor upgrades (uitbreidingen en opruimen van parameters)
en de hoogste voor echt nieuwe functionaliteit.

[Reactie gewijzigd door beerse op 25 juli 2024 12:33]

[TrekVogel]

Wat je zegt klopt helemaal. Ik vind Debian based systemen prettig, maar kom keer op keer tot de conclusie dat je beter Ubuntu (of iets anders als dat je voorkeur heeft) kunt nemen. Voor desktop was dat al duidelijk, bijvoorbeeld de Gnome issues die je aanhaalt. Laatst toch nog een keer Debian geprobeerd voor een server, maar ook daar bleek Ubuntu Server de betere keus (voor mij). Hoewel Debian op stabiliteit gericht is voelt het vaak minder "af" dan sommige andere distro's.

[mkools24]

Nog steeds mijn distro bij voorkeur Hoewel ik enterprise sneller CentOS zou gebruiken.

[scholtnp]

Vanwege de binary compatibility met Redhat, of om een andere reden?

[Htbaa]

Aangezien de LTS van Debian maar 5 jaar support krijgt en CentOS zo'n 10 jaar hoef je minder snel te upgraden of migreren naar een server met de nieuwe versie van het OS.

[elmuerte]

Debian is al decennia te upgraden naar nieuwere versies. CentOS niet. Leuk dat je 10 jaar niet hoef te upgraden, maar je hebt dat ook geen toegang tot nieuwere managed packages.

[sfranken]

Uh, kun je die wat meer uitleggen? Bij CentOS komen gewoon nieuwere pacakges mee met upgrades, dus snap ik niet wat je bedoelt met 'geen toegang tot nieuwere managed packages'

[ninjazx9r98]

Ik heb nog niet zo lang geleden letterlijk het beheer van een Centos 7 server geërfd, daar is dus geen upgrade pad voor beschikbaar.

[UPPERKEES]

`dnf -y --releasever=8 --allowerasing --setopt=deltarpm=false distro-sync` en done. Je klinkt wel erg zelfverzekerd over iets wat je heel makkelijk online kan vinden.

[ninjazx9r98]

Daar denkt men bij Centos anders over, er is geen upgrade pad van 7 naar 8.
Is ook heel makkelijk online te vinden....
https://forums.centos.org/viewtopic.php?t=71848
Staat ook leuk in een changeplan, een upgrade uitvoeren die niet bestaat en dus niet gesupport wordt. Gaat em niet worden tenzij ik dat wil negeren en graag op zoek wil naar een andere baan.

[sfranken]

Van major naar major niet nee, maar van package naar package is in CentOS prima te doen anders. Een 'yum update' of 'dnf update' levert je gewoon de nieuwste versie(s) van alle pacakges op je systeem op.

Dat was mijn verwarring. Nieuwere managed packages heeft een hele andere betekenis.

[UPPERKEES]

Het is juist andersom, zie mijn reactie.

[mkools24]

Dat inderdaad. Plus dat zaken voor CentOS/Redhat altijd net wat beter zijn gedocumenteerd en/of ondersteund heb ik het idee.

[Crim]

Laatste tijd moet je wel voor bijna alle documentatie een subscription hebben bij Red Hat.

[sfranken]

Niet helemaal. Je moet een RHEL account hebben. Dat kost niks en is binnen 2 minuten aangemaakt. De kwaliteit van de documentatie is het in mijn ogen ook wel waard.

[UPPERKEES]

Inderdaad, en met een Red Hat developers account (gratis), kan je als bonus ook gewoon pure Red Hat gebruiken met access tot de repo's.

[sfranken]

Weet ik, met als enige gotcha dat je ze niet in productie mag inzetten. Ter test, prima.

[bandidoloco]

Maar hoe belangrijk is de levensduur van een OS nog in tijden waarin meer en meer zaken in een container (kort) leven?

[Crim]

Nog belangrijker aangezien de containers ook een host OS nodig hebben.

[_eXistenZ_]

Niet toch? Want ook hosts worden als cattle behandeld, kijk naar Kubernetes met autoscaling. Zo is de host er nog, zo issie weg. En zo zijn er weer 3 terug.

[Crim]

Ja dat zijn echt hele mooie oplossingen maar dat ga je meestal niet zelf opzetten voor minder dan 5 servers.

[_eXistenZ_]

Ehm jawel eigenlijk, Google Cloud maakt het zo makkelijk...

[Crim]

Ja en Digitalocean ook maar dan doe je het dus niet zelf op eigen (dedicated) servers

[_eXistenZ_]

Nee idd, want waarom zou je?

[jabwd]

Extreme kosten van cloud, controle over waar je spul draait, minder afhankelijk van een 3e partij. Zat redenenen te bedenken.

[_eXistenZ_]

Wat mij betreft alle drie non-argumenten.

[lezzmeister]

Als je Google Cloud draait of andere buitenlandse cloudservers dan moet je wel goed kijken dat er geen probleem kan onstaan met AVG regels en dergelijke.
Afhankelijk van je werkgever kan het ook zijn dat ze strenger beveiligde netwerken willen en dan kan het controle en afhankelijk deel zeker een grote rol spelen.

[Hellboy!]

Daar heb je wel een punt, daarvoor zijn distro's als CoreOS en Atomic host meer geschikt voor.

[tormentor1985]

Dat is meer bedoeld voor het mee groeien van een on premise infrastructuur en niet zo zeer voor autoscaling. Als je autoscaling wilt gebruiken doe je dat gewoon bij 1 van de grote cloud providers. Het voordeel van autoscaling valt immers erg als je alsnog alle hardware in huis moet hebben om piekbelasting op te kunnen vangen en eerlijk gezegd kan je het dan net zo goed 24x7 laten draaien.

[Gomez12]

Gewoon maar even een vraag, maar waarom zou je niet gewoon on premise een basis kunnen hebben en dan met autoscaling bursten naar de cloud?

[tormentor1985]

Dat zou inderdaad prima kunnen al zou het nooit mijn voorkeur hebben omgevingen te mixen. Het is juist fijn dat je de infrastructuur van de cloud kan gebruiken VPC's, security groups, WAF, cloudfront of soortgelijke alternatieven en ga zo maar door. De voordelen vallen mijns inziens weg als je ook on prem een andere omgeving moet onderhouden voor dezelfde applicatie en security technisch gezien is het ook een uitdaging.

Overigens misschien leuk om over na te denken, ik begin de laatste tijd zelfs meer nadelen dan voordelen in container en orgestration te zien. Het onderhouden van een cluster kost immers ook tijd en geld en een ec2 instance is mits goed opgezet ook gewoon stateless en disposable. Sterker nog de gehele productie environment kan gewoon ergens (anders) deployed worden met cloudformation en vervolgens met wat DNS trucjes gescript en gefaseerd in productie genomen worden. Ook microservices kunnen gewoon in een autoscaling group geplaatst worden. Wat zijn dan eigenlijk nog de voordelen van kubernetes als je in de cloud werkt? On prem kan ik het begrijpen maar in de cloud?

[Archcry]

Juist minder belangrijk lijkt mij. In principe hoeft er maar een package goed ondersteund te worden vanuit je host os en dat is je container runtime. Waar je vroeger grotendeels afhankelijk was van je host os qua packages en het daarom lastiger was om te upgraden of te switchen kan je nu naar mijn idee juist makkelijk upgraden / switchen omdat je containers toch host os onafhankelijk werken.

[Crim]

Het is maar net hoe het bekijkt inderdaad, aan de ene kant is het minder belangrijk wat voor OS het precies is zolang er maar Docker of iets vergelijkbaars op draait. Aan de andere kant is het ook niet echt handig als je vrij snel achter elkaar grote OS upgrades moet doen. Hier komen toch vaak wat problemen uit en zorgt voor downtime van de containers die er op draaien of tijdelijk minder capaciteit.

[Crim]

Inderdaad, vaak installeer je een nieuw OS ook niet binnen een jaar na release en dan is 5 jaar opeens wel heel kort. Ik gebruik zelf een combi van CentOS (vanwege oudere versies van packages die vaak nodig zijn) en Ubuntu LTS met ook ongeveer 10 jaar support momenteel.

[divvid]

Hmm, nooit last van gehad. Ik heb een server lopen die ik gestart ben op ubuntu 8.04 en via 10.04, 12.04, 14.04 en 16.04 zit nu op 18.04. Binnenkort gaat ie naar 20.04. Nog steeds dezelfde hardware, loopt als een zonnetje.

[Htbaa]

Hangt er ook wel een beetje van af wat je op zo’n server draait. Bepaalde software verandert niet zo hard, bijvoorbeeld een Postfix o.i.d. en dan is een upgrade van een productie server misschien minder spannend. Ik zelf zou het nooit (meer) doen. Destijds een Ubuntu 7.04 naar 8.04 LTS moeten upgraden. Daarvoor moest ik eerst naar 7.10, dus twee upgrades uitvoeren. Dat was nog op dedicated hardware, maar het gehele upgrade proces stap voor stap moeten testen (en ook of alle programmatuur nog werkte) zodat bij de uiteindelijke upgrade dit zo vlekkeloos mogelijk ging.

Sindsdien hou ik het bij migraties naar een nieuwe server :-).

Tot nog toe draai ik enkel Ubuntu, maar die lifespan van 5 jaar is toch wel wat kort, zeker ook omdat je niet direct na het uitkomen van een nieuwe LTS niet direct een nieuwe server de lucht in gooit. Wat ik wel fijner vind aan Ubuntu (en ik denk ook Debian) is dat ze een stukje actueler zijn met software versies en wat fijnere defaults hanteren bij het installeren van software. CentOS 8 heeft out of the box bijvoorbeeld PHP 7.2, en dat OS is pas afgelopen september uitgekomen. Gelukkig zijn er wel alternatieve repositories, maar toch. Die PHP is als ik me niet vergis al bijna end of life, en als je over 4 jaar een CentOS 8 server de lucht in gooit zit je dus nog steeds ‘vast’ aan een eol PHP.

Maar door de langere ondersteuning ga ik nu wel voor CentOS 8. Voor bijvoorbeeld PHP kan je Remi’s repository gebruiken en voor de rest ben ik erg blij met Docker :-).

[Crim]

Red Hat blijft PHP 7.2 dan wel voorzien van patches zolang CentOS 8 nog niet EOL is. Kan soms wel weer handig zijn als software alleen op PHP 7.2 (goed) draait.

Ik ben er altijd wel blij mee dat ik zeker weet dat de software uit de standaard CentOS repo's gegarandeerd geen grote updates krijgt. Ik heb echt nog nooit problemen gehad na een yum update.

[Reactie gewijzigd door Crim op 25 juli 2024 12:33]

[UPPERKEES]

Je vergist je wat je zegt over PHP in RHEL/CentOS. Je krijgt gewoon upgrades. CentOS 7 (2014), kan ook gewoon PHP 7.3 uit de officiële supported "software collections" repo halen. Daarbij heeft RHEL 8 ook Streams (wat in Fedora Modules heet). Daar kan je zelf je software versie kiezen en tracken.

Meer info in mijn comment hier.

[Reactie gewijzigd door UPPERKEES op 25 juli 2024 12:33]

[mrmrmr]

Dist-upgraden is eenvoudig bij Debian. Tenzij je speciale dingen doet is het meestal probleemloos. Hier en daar wat applicatieaanpassingen.

Een oude Linux versie moet niet zo lang blijven draaien. Dat levert problemen op met de beveiliging. Encryptie bijvoorbeeld moet up to date zijn.

[sfranken]

Een oude Linux versie moet niet zo lang blijven draaien. Dat levert problemen op met de beveiliging. Encryptie bijvoorbeeld moet up to date zijn.

Dat is een kwestie van je security updates draaien. Tenminste, zo is het bij CentOS en RHEL. Debian heb ik als proef VM draaien om de desktop kant mee te bekijken, dus echt diep zit ik daar niet in, maar het lijkt me toch dat ook Debian dit gewoon zo aanpakt?

[N8w8]

Debian stable updates verhelpen vooral bugs, of hier en daar wat kleine "ongevaarlijke" veranderingen.
Er zijn uitzonderingen, bijv zodra Mozilla stopt met de Firefox ondersteuning, upgraden ze wel naar de nieuwe ESR, omdat het ondoenlijk is dat in hun eentje te maintainen voor Debian.
Maar nieuwe ssl ciphers bijvoorbeeld, als daar een nieuwe OpenSSL versie voor nodig is (of patches), dat doen ze niet in stable als de noodzaak ontbreekt.
Er is daarnaast nog wel een backports repo, maar daar vind je geen updates van zulke "core" libs (waar vanalles van afhankelijk is), maar meer specifieke pakketten die je kan cherrypicken als je net even iets te kort komt.
Ik had (van de andere kant ) begrepen dat CentOS/RHEL idd meer/dieper vernieuwen wat dat betreft.

[Reactie gewijzigd door N8w8 op 25 juli 2024 12:33]

[sfranken]

Ik had (van de andere kant ) begrepen dat CentOS/RHEL idd meer/dieper vernieuwen wat dat betreft.

Dat klopt, daar komen dat soort zaken gewoon met de security updates mee. Als een applicatie kapot gaat is dat jammer, je krijgt een flinke tijd van te voren namelijk bericht wat er gaat wijzigen, en kun je dus als applicatiebouwer rekening mee houden.

Dat moet je, in mijn ogen, met zaken als bijvoorbeeld SSL cyphers, sowieso doen.

[TheVivaldi]

Klopt, maar daarvoor hoef je niet per se naar Red Hat als je liever Debian gebruikt. Ubuntu 18.04 (ook de server-editie) wordt namelijk ook 10 jaar ondersteund, en dan heb je toch een Debian-basis als je dat prettiger vindt

[Htbaa]

Ja, die wordt 10 jaar ondersteund als je voor extended support wil betalen :-).

[TheVivaldi]

Je hebt gelijk, ik had het even verkeerd begrepen. Ik dacht dat we het over Red Hat hadden, maar je had het over CentOS. Red Hat of Ubuntu zou niets uitgemaakt hebben, want voor beiden betaal je voor langdurige ondersteuning, maar CentOS is gratis, dus dat maakt wel een verschil. Mijn excuses

[Muncher]

“Maar” 5 jaar? Dat lijkt mij toch vrij lang. En loop je niet tegen allerlei problemen aan bij een OS wat 10 jaar support krijgt, in de zin van “die kan nog wel mee, net als de applicatie die erop draait. Zorg voor later”. In 2030: iemand enig idee wat dit ding doet?

Het slot van 5 jaar zorgt ervoor dat je nog redelijk op tijd een keer je stack bekijkt.

[Htbaa]

Hangt natuurlijk ook heel erg van ‘t doel van de server af natuurlijk. Een mailserver is wel erg fijn als die 10 jaar kan draaien met enkel uitvoeren van onderhoud. Idem voor loadbalancers, databases of iets als een Docker swarm.

[djwice]

Of Amazon Linux 2 in je Enterprise wellicht?
ChromeOS Crostini is ook gebaseerd op Debian Buster.

[Reactie gewijzigd door djwice op 25 juli 2024 12:33]

[Verwijderd]

Hoe outdated zijn de packages

[BushWhacker]

Van Debian Buster of van CentOS ?

[Yarisken]

Sinds centos 8 geen deftige support voor docker ben ik overgeschaleld naar ubuntu server.

[sfranken]

Hoezo niet? Kwestie van de repo van de docker site toevoegen en installeren. Zelf gebruik ik geen docker, of buildah of podman maar zo te zien is het niet veel werk docker te installeren op centos 8.x

[bandidoloco]

Kunnen installeren is nog iets anders dan support krijgen natuurlijk.

[Hydranet]

Over wat voor support heb jij het? Als je support wil dan neem je een RHEL subscriptie of Ubuntu Enterprise heb je volgens mij ook nog, als je RHEL wil maar zonder support dan neem je de binary compatible daar van, CentOS.

[Reactie gewijzigd door Hydranet op 25 juli 2024 12:33]

[sfranken]

We hadden het over support vanuit Docker, niet vanuit RHEL.

[Htbaa]

Docker raadt zelfs enkel CentOS 7 aan. Hopelijk komen ze snel met ondersteuning voor CentOS 8.

[sfranken]

De eisen zeggen dit:

...
Use CentOS 64-bit 7.1 and higher on x86_64.
...

Dus 8.x word ook ondersteund, immers is 8.x > 7.1.
Bovendien staag er nergens op de pagina dat 8.x niet supported is. Dat had er dan wel bijgestaan, lijkt mij.

[Htbaa]

Tot nog toe heb ik weinig succes gehad met Docker in CentOS 8, vreemde foutmeldingen.

[sfranken]

Zover ik kan zien is het op CentOS sowieso de CE versie, dus geen support. Wil je de EE versie dan zul je die moeten kopen (zie ook https://docs.docker.com/ee/docker-ee/centos/). Zover ik kan achterhalen is CentOS 8.x gewoon ondersteund door Docker, en krijg je dus support op je EE versie als je die installeert.

Dat het niet standaard in de repo's zit... tsja...

[Hydranet]

Volgens dit overzicht worden CentOS, Debian, Fedora, Raspian en Ubuntu ondersteund. Er worden ook geen versie nummers genoemd dus lijkt mij dat CentOS 8 gewoon ondersteund word anders hadden ze er wel OS versie nummers bij vermeld.

[Htbaa]

https://docs.docker.com/engine/install/centos/

Enkel CentOS 7 voor nu.

[wimdebok]

Precies wat je zegt, fluitje van een cent. Repo toevoegen, installeren maar.

[jaapstobbe]

Ik vind Debian 10 heerlijk om mee te werken. Zelfs een nvdia driver installeren is een piece of cake tegenwoordig.

Ik zie alleen de meerwaarde van Wayland vs X11 nog altijd niet.

[Reactie gewijzigd door jaapstobbe op 25 juli 2024 12:33]

[westlym]

Wel, ik heb hier wel moeite om de nvidia driver voor mijn videokaart te installeren. hoe doe jij dat?

[jaapstobbe]

sudo gedit /etc/apt/sources.list
deb http://deb.debian.org/debian buster main contrib non-free
sudo apt update
sudo apt install nvidia-driver

[Aardbol_23564]

Wat ik o.a. leuk vindt aan debian 10 is dat het als enige distro nu echt gebruik maakt van nftables en iptables eindelijk overbodig maakt. Door een compatibiliteitslaag, kunnen applicaties zoals docker ook nog gewoon blijven werken.

Nftables is zoveel handiger dan iptables, al is het soms wat zoeken omdat documentatie niet altijd gemakkelijk te vinden is

[Reactie gewijzigd door Aardbol_23564 op 25 juli 2024 12:33]

[UPPERKEES]

Net zoals Red Hat (Fedora/CentOS) bedoel je? firewalld van Red Hat wordt wellicht straks ook de default in Debian

[Aardbol_23564]

Ik heb testen uitgevoerd maar die distros implenteren het niet compleet en maken nog standaard gebruik van iptables hier en daar. Voor docker bijvoorbeeld, omdat docker rechtstreeks met iptables praat en niet via firewalld (en red hat enz enkel op die manier gebruik maken van de nftables backend).

Firewalld is maar een wrapper en naar mijn mening een pain in the ass (veel typwerk) in vergelijking met direct nft rules te gebruiken. Het is ook logisch dat debian hiervan gebruik zal maken, zo kunnen ze werk besparen in het onderhouden van hun eigen wrappers en zou later een upgrade naar een andere backend simpeler zijn.

[sfranken]

Firewalld is maar een wrapper en naar mijn mening een pain in the ass (veel typwerk) in vergelijking met direct nft rules te gebruiken.

Kun je me daar wat meer info over geven eventueel? Wat ik kan vinden op Google is niet echt veel, en het spreekt elkaar tegen.

MIjn kennis van NFT is heel weinig. firewall-cmd en iptables ken ik redelijk, vandaar dat ik me gefronste wenkbrauwen zat. Immers:

firewall-cmd --add-service=https --permanent

In vergelijking met

iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

Dan is firewall-cmd toch wat minder tikwerk. De NFT versie van die regel ken ik niet, dus kan ik helaas niet beoordelen. Misschien kun je 'm in je reactie bijvoegen, vind ik wel interessant.

[Reactie gewijzigd door sfranken op 25 juli 2024 12:33]

[Aardbol_23564]

Met nftables zou het alternatief zijn:

Via een ruleset file (mijn voorkeur):

tcp dport https accept

Dit is voor beide IPv4 en IPv6. Wil je er http bij?

tcp dport {https,http} accept

Voor IPv4:

ip tcp dport https accept

IPv6:

ip6 tcp dport https accept

Als je het via CLI doet, dat kost het enkele toetsen meer om de rule toe te voegen.

[sfranken]

Dat ziet er inderdaad best goed te doen uit, dankje voor de info!

[Raven]

"Nftables is zoveel handiger dan iptables, al is het soms wat zoeken omdat documentatie niet altijd gemakkelijk te vinden is "
Inderdaad, daar is nog flink wat verbetering nodig, de informatie die ik heb gebruikt komt overal en nergens vandaan. Sommige info, over hoe een port redirect werkend te krijgen, heb ik iemand van een blog voor zitten mailen.

Maar nftables werkt wel mooi, vooral het combineren van regels is verdomd handig, wordt de firewall een stuk korter van . Het is mij alleen nog niet gelukt om een regel met sets van poort/protocol a la https://wiki.nftables.org...ncatenations#Literal_sets aan te maken, het is mij niet eens duidelijk of dat wel kan (Dus bijv. port A tcp en port B udp in één regel).

[Aardbol_23564]

Kan je niet gewoon l4proto aanspreken om een generieke regel te maken?

Wat betreft de documentatie, dacht ik daar binnenkort wat over te bloggen om daar verbetering in te brengen. Is wel spijtig dat het nog teveel zoeken is nu.

[Raven]

Dus i.p.v. per poort een specifiek protocol op te geven

meta l4proto { tcp, udp } @th,16,16

voor alle poorten in die regel doen? Hmm...

"Wat betreft de documentatie, dacht ik daar binnenkort wat over te bloggen om daar verbetering in te brengen."

[Reactie gewijzigd door Raven op 25 juli 2024 12:33]

[VincentvdBergh]

Ik zet Debian na installatie altijd met de software bronnen op unstable (did niet de cover naam van de release). Gaat altijd vrolijk door. Als ik dan na 6 maanden een nieuwe kernel heb dan is de boel na 20 seconde downtime weer up and running.

Nog nooit problemen mee gehad.

[avdr2]

Hoe werkt dat precies?

[jbhc]

Je sources.list aanpssen.

[Verwijderd]

Fijne distro om mee te werken. Ik gebruik het zowel op mijn desktop, als op diverse servers. Van Windows XP stapte ik destijds over naar Linux Mandrake om vervolgens Fedora en Debian te proberen. Ik bleef bij Debian hangen en daar heb ik nog geen spijt van. Voorlopig blijf ik het nog wel draaien.

[Verwijderd]

Ik gebruik nu een half jaar Linux. En sinds 3 maanden PopOS. Ik moet zeggen tot nu toe de fijnste distributie, vooral omdat ik er op game.

Debian was voor mij voornamelijk veel gedoe. Ubuntu was al beter, maar PopOS werkte alles out-of-the-box.

[avdr2]

Kun je iets vertellen over (zegmaar) running upgrades voor apps (zelfs zoals Firefox) ? Zowel Synaptic als Mint zijn hier niet goed in.

Maar je lofprijzing maakt wel nieuwsgierig. Me gaan het proberen op een VirtualBox.

[Reactie gewijzigd door avdr2 op 25 juli 2024 12:33]

[Verwijderd]

Ik draai normaal de updates en upgrades via de Popstore en anders via APT en tot dusver nog geen issues gehad met Firefox.

Ook de beta van Steam nog geen problemen mee gehad. The Elder Scrolls: Skyrim en Online werken naar behoren.

Het is mijn main OS en ik doe geen dual boot meer.

[jbhc]

Ik weet niet wat je bedoelt met running upgrades maar Mint is in mijn ogen best actief met de updates van Firefox.

[sfranken]

Kun je iets vertellen over (zegmaar) running upgrades voor apps (zelfs zoals Firefox) ? Zowel Synaptic als Mint zijn hier niet goed in.

Sorry als ik nu super bot overkom, maar dan doe jij volgens mij iets fout. Zowel Ubuntu (Synaptics, gok ik?), als Mint, als Debian (En Arch, Fedora, etc..) kun je het leeuwendeel van de applicaties gewoon updaten zonder gedoe en gezeik. Ik doe dat namelijk al jaren zo...

[avdr2]

Ik kom problemen tegen bij apps die in het echt al verder zijn ontwikkeld maar waar Synaptic geen weet van heeft...

[sfranken]

Kun je dat wat beter uitleggen? Nu komt het over alsof je software buiten je package manager hebt geïnstalleerd en dan moppert dat je package manager deze niet bij kan werken, of dat je vergeet dat het soms even kan duren voordat een update doorkomt omdat de source opnieuw gepatcht moet worden vanuit upstream door je package manager of distro (Ubuntu is hier met bepaalde packages heel goed in...not..)

En onthoud ook (als ik je reactie goed lees) dat een versienummer niet altijd iets zegt. Sommige fabrikanten (Canonical is hier heel goed in, RHEL ook met kernelnummers) passen patches in hun eigen builds toe die van upstream afkomen. RHEL doet dat met kernel patches bijvoorbeeld, Canonical met o.a. GNOME zaken zoals Nautilus, en Firefox geloof ik ook.

[Reactie gewijzigd door sfranken op 25 juli 2024 12:33]

[avdr2]

Je legt de diverse problemen al beter bloot dan ik zou kunnen.

[sfranken]

Als jij 'last' hebt van de zaken die ik opnoem (en dan vooral het 1e, buiten je package manager om iets installeren) dan is het dus geen (ontwerp)fout van de distro in kwestie he, dan is het PEBCAC.

Kun je dus, nogmaals, uitleggen waar je last van hebt?

[Reactie gewijzigd door sfranken op 25 juli 2024 12:33]

[avdr2]

Ik wil dat niet en ik zeg je waarom:

ik heb totaal genoeg van inmiddels het gewicht van een paar honderd hacks die de kutlinuxen in al die jaren op mijn pad hebben gebracht.

Neem nu eens dit pop!-os. Hier werd gezegd dat het andere thema zo leuk is. In dat OS is dat niet te doen zonder dat je eerst GNOME-tools of zoiets installeert. Van zulke "oplossingen" heb ik - ik herhaal mezelf inderdaad - meer dan genoeg. Geen "hulp" nodig als die.

[sfranken]

Zo te zien aan je instelling is het inderdaad maar beter dat je het gewoon bij Windows of macOS houd ja. Je gaat van het ene item hop naar het andere item, zonder enige logica lijkt het wel.

Je weet dat er andere DE's zijn dan GNOME he? GNOME is gebouwd op het principe 'sane defaults'. Wil je alles aan kunnen passen naar hartenlust tot je een ons weegt? Dan is KDE meer voor je (of MATE), maar ga dan niet je eigen frustraties en onkunde projecteren op een heel OS ("kutlinuxen").

Omdat jij er niet mee kan werken wil niet zeggen dat iets "kut" is he..

ik heb totaal genoeg van inmiddels het gewicht van een paar honderd hacks die de kutlinuxen in al die jaren op mijn pad hebben gebracht.

Wie weet, misschien zijn die niet nodig. Maar goed, dat weet je pas als je je openstelt om wat te leren. Zo komt het nu niet over, sorry als ik bot ben, maar zo is het.

[Reactie gewijzigd door sfranken op 25 juli 2024 12:33]

[mutley69]

Debian is wat lastiger dan anderen - maar 't is een heel betrouwbare distro. Sedert ik Ubuntu heb vervangen door Debian heb ik niet meer achterom gekeken. De betalende OS-en of de hypedure oplichting - daar moet ik niet meer aan meedoen - wat een opluchting is dat.

[mk1311]

Debian +1, om de zoveel tijd weer een andere distro proberen en elke keer weer terug op Debian, het is niet altijd de makkelijkste maar wel de meest betrouwbare
Huidige set-up in Hyper V op Win 10 box, Debian + ZFS + Samba, alle foto's veilig op een ZFS schijf makkelijk bereikbaar als netwerk Share, SSH via de Win10UbuntuApp voor makkelijk knippen plakken van code, Life is Good