Debian brengt versie 6.0 'Squeeze' uit
Na een ontwikkeltijd van twee jaar is Debian 6.0 uitgebracht. De Linux-distributie, die codenaam 'Squeeze' draagt, bevat onder andere een preview van Debian GNU/kFreeBSD, waarbij Debian-code gecombineerd wordt met de FreeBSD-kernel.
Debian 6.0 draait op een groot aantal platformen, waaronder 32bit- en 64bit-x86, PowerPC, Sparc, MIPS, Intel Itanium en ARM. Ook worden diverse desktopomgevingen ondersteund, zoals KDE 4.4, Gnome 2.30 en Xfce 4.6. Squeeze bevat onder andere OpenOffice.org 3.2.1, Iceweasel 3.5 en Icedove 3.0.11 - versies van respectievelijk Firefox en Thunderbird - en GIMP 2.6.11. Als Linux-kernel is gekozen voor versie 2.6.32, terwijl als bootmanager voor Grub 2 is gekozen.
Nieuw bij de Squeeze-release zijn de 32bit- en 64bit-versie van Debian GNU/kFreeBSD, waarbij Debian-code gecombineerd wordt met de FreeBSD-kernel. Hoewel deze previewversies nog niet volledig functioneel zijn - met name de desktopomgeving zou nog beperkingen kennen - stellen de Debian-ontwikkelaars dat serverbeheerders met kFreeBSD kunnen profiteren van de specifieke netwerkkwaliteiten van FreeBSD in combinatie met de 'vertrouwde' toolset van Debian. Bovendien ondersteunt kFreeBSD het zfs-bestandssysteem.
De Debian-ontwikkelaars, die streven naar geheel open broncode in Linux, laten ook weten dat de Linux-kernel is ontdaan van 'problematische' firmware-bestanden. Deze zijn voortaan ondergebracht in een non-free-archief. Gebruikers kunnen tijdens de installatie van het OS zelf aangeven of zij al dan niet gebruik willen maken van deze propriëtaire firmware-bestanden.
In navolging op ondere andere Ubuntu heeft Debian gewerkt aan het verkorten van de opstarttijden van het besturingssysteem. Door het parallel starten van bootscripts zou een aanzienlijke tijdswinst zijn geboekt. Debian claimt dan ook dat Squeeze prima geschikt is om op bijvoorbeeld relatief trage netbooks te installeren, ondanks dat de Linux-distro vooralsnog blijft vasthouden aan het gebruik van het verouderde init daemon-systeem.
Squeeze heeft volgens de ontwikkelaars ook een sterk verbeterde installer gekregen. Zo zou het aanmaken van partities, het opbouwen van raid-configuraties en het toepassen van encryptie op een partitie zijn vereenvoudigd. Ook kunnen ext4- en btrfs-bestandssystemen toegepast worden.
Afgeleiden van de reguliere Debian 6-versies zullen niet langer custom Debian distributions worden genoemd, maar door het leven gaan als Debian Pure Blends. Daaronder vallen onder andere Debian Accessibility, DebiChem, Debian EzGo en Debian Multimedia.
Reacties (100)
Damn, ik heb net twee dagen geleden Lenny geinstalleerd om mijn server 
Dan had je iets beter research kunnen doen, het is al een behoorlijke tijd bekend dat Squeeze waarschijnlijk dit weekend gereleased zou worden.
Kan je geen update uitvoeren. In weet niet hoe het bij Debian is, maar bij ubuntu en fedora doe ik gewoon een update uitvoeren. en aangezien ubuntu een afgeleide is van Debian zou ook moeten kunnen.
apt-get update && apt-get dist-upgrade. Geen centje pijn :-)
De beta installer van squeeze was wat mij betreft al een tijdje te prefereren boven de stable lenny installer. Laatst nog een paar servers daarmee geinstalleerd; lvm2 ext4 out of the box. Werkt als een zonnetje. Debian is een prachtig server OS.
De beta installer van squeeze was wat mij betreft al een tijdje te prefereren boven de stable lenny installer. Laatst nog een paar servers daarmee geinstalleerd; lvm2 ext4 out of the box. Werkt als een zonnetje. Debian is een prachtig server OS.
[Reactie gewijzigd door d3vlin op zondag 6 februari 2011 13:33]
Yah! Ext4! Dat wil ook wel, maarja, dat had Lenny nog niet. Volgens mij kun je dit niet meer achteraf fixen, helaas.
Je kunt nu wel je ext3 partitie mounten als ext4 en een graantje meepikken van de performance boost die er in zit. Extents en dergelijke werken volgens mij niet automagisch op die manier, maar ik geloof wel dat er een manier is om ext3 in-place naar ext4 te converteren.
Oh jawel, in fstab ext3 vervangen door ext4, dan
# tune2fs -O extents,uninit_bg,dir_index /dev/device
En dan in single user mode met die partitie ge-umount (of via een live cd in geval van je /-partitie):
# fsck -pDf /dev/device
Grootste nadeel van nu nog Lenny te gebruiken is dat je partities niet correct gealigeerd kunnen zijn. fdisk en parted in squeeze zullen proberen om de ideale alignering te detecteren en zullen die automatisch gebruiken. Dat kan behoorlijk wat diskperformantie schelen.
# tune2fs -O extents,uninit_bg,dir_index /dev/device
En dan in single user mode met die partitie ge-umount (of via een live cd in geval van je /-partitie):
# fsck -pDf /dev/device
Grootste nadeel van nu nog Lenny te gebruiken is dat je partities niet correct gealigeerd kunnen zijn. fdisk en parted in squeeze zullen proberen om de ideale alignering te detecteren en zullen die automatisch gebruiken. Dat kan behoorlijk wat diskperformantie schelen.
[Reactie gewijzigd door freggy op zondag 6 februari 2011 13:56]
Die alignment van schijven had ik ook gevonden na aanschaf van een nieuwe schijf laatst. Dat had ik daarbij opgelost door gewoon de laatste parted even te downloaden en zelf te compileren. Opzich ook een klusje van een paar minuten.
Bedoel je niet 'diskperformance'? Of komt u toevallig uit Belgie?
Deprecated, aptitude full-upgrade is the way.
Volgensmij niet hoor:
Bron: http://debian.org/release...en.html#upgradingpackagesThe recommended way to upgrade from previous Debian GNU/Linux releases is to use the package management tool apt-get. In previous releases, aptitude was recommended for this purpose, but recent versions of apt-get provide equivalent functionality and also have shown to more consistently give the desired upgrade results.
Ok, dan loop ik achter en hebben ze het weer omgedraaid.
Daarom wacht ik altijd met upgraden tot de eerste reviews uitkomen. Staan weer ladingen met comments bij etc. waar veel info uit te halen is. Zoals deze review dus.
Daarom wacht ik altijd met upgraden tot de eerste reviews uitkomen. Staan weer ladingen met comments bij etc. waar veel info uit te halen is. Zoals deze review dus.
Nou, dit document is gewoon officiële documentatie van Debian 
Daar staat een hele boel nuttige informatie in, echt een aanrader om door te lezen. Ik houd dit document in ieder geval achter de hand als ik ga upgraden, mocht er iets onverwachts gebeuren.
Daar staat een hele boel nuttige informatie in, echt een aanrader om door te lezen. Ik houd dit document in ieder geval achter de hand als ik ga upgraden, mocht er iets onverwachts gebeuren.
Aptitude = front-end van apt, oftewel het maakt uiteindelijk niks uit.
Toch wel hoor: iirc wordt het afgeraden door Debian om beide door elkaar te gebruiken. Dus je gebruikt best ofwel apt-get, ofwel aptitude. Zie ook comment van cschutijser hierboven.
Aptitude is behalve een front-end voor apt ook een eigen dependency solver die vaak met andere oplossingen komt.
Troost je. Bij nieuwe software releases kun je beter altijd een maandje wachten. Dan komen namelijk problemen en ontwikkelfouten naar boven. Kijk maar naar Windows Vista.
Bovendien bied Lenny nu nog volledige support voor alle applicaties. Bij Squeeze moet die nog op gang komen.
Bovendien bied Lenny nu nog volledige support voor alle applicaties. Bij Squeeze moet die nog op gang komen.
Debian staat echter bekend om de erg trage releasecycle en dat heeft één reden, omdat stabiliteit of beter gezegd betrouwbaarheid de #1 prioriteit zijn. Vergelijken met een commercieel product en zeker Vista waar een hoop functionaliteit niet eens is in geïmplementeerd door een naderende deadline is dus niet logisch.
Dat gaat misschien op voor Windows, maar bij Debian doen ze het testen vóór de release. Je kunt er van op aan dat Squeeze rock solid is.
MBT nieuwe releases en maand(en) wachten is mijn ervaring dat het bij Debian het omgekeerde het geval is.
Meestal is de nieuwe versie al zo stabiel dat je maanden voor de officiële release gebruik kan maken van de nieuwe versie zonder enige vorm van problemen.
De 3 maanden voor de release van een nieuwe versie zou ik altijd de nieuwe versie pakken tenzij je 3rd party software hebt die nog niet ondersteund wordt.
Meestal is de nieuwe versie al zo stabiel dat je maanden voor de officiële release gebruik kan maken van de nieuwe versie zonder enige vorm van problemen.
De 3 maanden voor de release van een nieuwe versie zou ik altijd de nieuwe versie pakken tenzij je 3rd party software hebt die nog niet ondersteund wordt.
Waar heb je het over? Er is echt niks anders met support voor Squeeze of Lenny. Het zijn dezelfde mensen die de support doen.Bovendien bied Lenny nu nog volledige support voor alle applicaties. Bij Squeeze moet die nog op gang komen.
De applicaties voor Squeeze zijn al een tijdje uit ontwikkeld. nieuws: Ontwikkelaars geven Debian 6.0 de status 'frozen' Ze zijn al die tijd bezig geweest we kwaltijd van Squeeze en de applicaties te verbeteren.Bovendien bied Lenny nu nog volledige support voor alle applicaties. Bij Squeeze moet die nog op gang komen.
Security support werd gewaarborgd door testing-security Lijkt mij dat de overdracht minimaal is.
documentatie geen issue met een handleiding van 10 jaar terug kom je (voor de console) nog uit de voeten. (oke devices gaan automatisch, ipchains wordt moeilijk maar vergelijk het met andere producten van 10 jaar geleden)
IMHO is Debian een van de meest consistente instituten in OS land.
[Reactie gewijzigd door daft_dutch op zondag 6 februari 2011 15:05]
Dat is dan mooi want dan kan je deze dus op je Server installeren, in plaats om je ServerDamn, ik heb net twee dagen geleden Lenny geinstalleerd om mijn server
[Reactie gewijzigd door AmigaWolf op zondag 6 februari 2011 18:30]
Ik moet zeggen dat Debian/kFreeBSD mij wel interessant lijkt voor mijn server. Door de FreeBSD- kernel heb je dan de fijne geom raid stack en ZFS tot je beschikking.
En persoonlijk vind ik dpkg/ aptitude fijner werken dan het ports- systeem van FreeBSD, dus die twee samen vind ik wel een fijne basis voor een server.
Eerst maar eens een dist-upgrade geven naar Squeeze en dan zien we wel verder.
En persoonlijk vind ik dpkg/ aptitude fijner werken dan het ports- systeem van FreeBSD, dus die twee samen vind ik wel een fijne basis voor een server.
Eerst maar eens een dist-upgrade geven naar Squeeze en dan zien we wel verder.
[Reactie gewijzigd door Jaap-Jan op zondag 6 februari 2011 13:21]
@KaptKoek: apt-get update, apt-get upgrade en dan apt-get dist-upgrade 
problem solved.
Zorg wel dat je in je /etc/apt/sources.list dingen als "stable main" hebt staan en niet "lenny main"
problem solved.Zorg wel dat je in je /etc/apt/sources.list dingen als "stable main" hebt staan en niet "lenny main"
Twee opmerkingen:
1) géén apt-get of aptitude upgrade doen, maar alleen update & dist-upgrade
2) In plaats van stable kun je lenny ook vervangen voor squeeze.
1) géén apt-get of aptitude upgrade doen, maar alleen update & dist-upgrade
2) In plaats van stable kun je lenny ook vervangen voor squeeze.
Twee opmerkingen:
1. dist-upgrade is vervangen door full-upgrade. Al tijdens de release van Lenny.
2. Apt-get is deprecated en vervangen door aptitude
Beide werken op zich prima, maar tijdens een upgrade loop je grotere risico's op broken dependencies, afgebroken installs, etc.
Zelf weten.
Is weer teruggedraaid dus..
1. dist-upgrade is vervangen door full-upgrade. Al tijdens de release van Lenny.
2. Apt-get is deprecated en vervangen door aptitude
Beide werken op zich prima, maar tijdens een upgrade loop je grotere risico's op broken dependencies, afgebroken installs, etc.
Zelf weten.
Is weer teruggedraaid dus..
[Reactie gewijzigd door Vinzz op zondag 6 februari 2011 15:24]
Niet meer. Zie eerder in deze thread.
http://debian.org/release...en.html#upgradingpackages vanaf 4.4.5 Gewoon apt-get dus, en niet aptitude.
Met deze release hebben ze de aangeraden tools om te updaten weer verandert van aptitude in apt-get, mede omdat is gebleken dat aptitude meer dingen wilt verwijderen dan apt-get en op complexe systemen het halve systeem wil uninstalleren, wat niet geheel wenselijk is Zie o.a. de release notes, die ook aanraden om het in 2 stappen te doen:
Verder is het risico op broken dependencies bij beide manier praktisch 0, aangezien voordat de update begint hij alles al gaat doorrekenen en je waarschuwt als het upgraden gaat mislukken.
Zie o.a. de release notes, die ook aanraden om het in 2 stappen te doen:- (apt-get update om de nieuwe software lijsten binnen te halen)
- apt-get upgrade om eerst het basissysteem te upgraden
- apt-get dist-upgrade om de rest van het systeem te upgraden.
Verder is het risico op broken dependencies bij beide manier praktisch 0, aangezien voordat de update begint hij alles al gaat doorrekenen en je waarschuwt als het upgraden gaat mislukken.
[Reactie gewijzigd door hostname op zondag 6 februari 2011 15:11]
Op zich sta ik erachter om niet-free firmware niet zomaar meer te bundelen, maar damn wat was dat irritant als de netwerkkaart niet wil werken omdat ie de firmware niet heeft. Ja je kunt deze gewoon downloaden, maar zonder netwerkkaart is dat niet vanzelfsprekend.
Ik heb nu een USB stick met daarop de firmware van mijn meestgebruikte kaarten staan, dat is erg handig bij het installeren.
Natuurlijk 100% de schuld van de fabrikant, breng die firmware gewoon free uit. Hoeft van mij echt niet open-source te zijn, maar laat de distributie wel gewoon zonder grenzen plaatsvinden.
Ik heb nu een USB stick met daarop de firmware van mijn meestgebruikte kaarten staan, dat is erg handig bij het installeren.
Natuurlijk 100% de schuld van de fabrikant, breng die firmware gewoon free uit. Hoeft van mij echt niet open-source te zijn, maar laat de distributie wel gewoon zonder grenzen plaatsvinden.
[Reactie gewijzigd door TRRoads op zondag 6 februari 2011 13:22]
Met hem. Dit is echt werkelijk heel hinderlijk als je een nieuwe server binnen hebt en daarin zit een broadcom kaart waar dit probleem voor geldt. Dit is vooral een probleem als je via PXE installeert.Op zich sta ik erachter om niet-free firmware niet zomaar meer te bundelen, maar damn wat was dat irritant als de netwerkkaart niet wil werken omdat ie de firmware niet heeft. Ja je kunt deze gewoon downloaden, maar zonder netwerkkaart is dat niet vanzelfsprekend.
Ik neem aan dat je de hw specs voordat je besteld controleert en de leverancier laat weten dat de koop niet door kan gaan als er geen opensource driver beschikbaar is? Anders lost het probleem zich nooit op.
Er is een open source driver. Het probleem is de firmware file die Debian (specifiek) weigert op de goede manier mee te leveren.
En bovendien: ik kan wel lekker principieel gaan zitten doen, maar daar gaat HP echt niet van onder de indruk zijn en ik heb toch servers nodig dus veel verder komen we dan niet.
En bovendien: ik kan wel lekker principieel gaan zitten doen, maar daar gaat HP echt niet van onder de indruk zijn en ik heb toch servers nodig dus veel verder komen we dan niet.
[Reactie gewijzigd door CyBeR op zondag 6 februari 2011 13:38]
extra netwerkkaart kopen met intel chips op, zit volgens mij gewoon in het HP gamma
Beetje zonde van het geld en de beschikbare ruimte binnenin de server.
Beetje kort door de bocht.Er is een open source driver. Het probleem is de firmware file die Debian (specifiek) weigert op de goede manier mee te leveren.
Debian levert uitsluitend volledig open-source zaken mee, tenzij je aangeeft ook closed source-firmware erbij wilt, dan krijg je die ook zonder problemen.
Vanuit de Debian-filosofie is dit IMHO een zeer nette manier van werken.
Fout, closed of open source heeft er niets mee te maken. We hebben het hier over free VS non-free.
Zo lang de fabrikant geen grenzen stelt aan de distributie en het gebruik van de firmware maakt het niets uit dat deze niet open-source is, ze kunnen hem dan gewoon bundelen.
Zo lang de fabrikant geen grenzen stelt aan de distributie en het gebruik van de firmware maakt het niets uit dat deze niet open-source is, ze kunnen hem dan gewoon bundelen.
Voor de Debian maakt het wel uit dat deze niet open-source is, daarmee dat ze hem niet bundelen.
Dat is hetzelfde (leg voor de grap maar eens de Debian Free Software Guidelines naast de Open Source Definition).Fout, closed of open source heeft er niets mee te maken. We hebben het hier over free VS non-free.
Nee, dat kunnen ze niet, aangezien dat breekt met het eerste punt uit de Debian Social Contract:Zo lang de fabrikant geen grenzen stelt aan de distributie en het gebruik van de firmware maakt het niets uit dat deze niet open-source is, ze kunnen hem dan gewoon bundelen.
Iets dat niet Open Source is voldoet niet aan de DFSG en mag dus niet in het main repository. Daarom dat die firmware blobs dus ook afgesplitst zijn naar packages welke in de non-free repository gehost worden.1. Debian will remain 100% free
[...] The Debian Free Software Guidelines. We promise that the Debian system and all its components will be free according to these guidelines. [...]
Maar het kan inderdaad vervelend zijn tijdens de installatie, en losse media met de non-free firmware blobs zijn ook niet altijd de handigste oplossing. Misschien kunnen ze de geschiedenis herhalen, en van de eerste CD een iso maken mèt en zonder firmware blobs...
Dat is een van de dingen die juist is verbeterd met deze release. Je kan gewoon een USB stick of CD met firmware images in de server stoppen en dan laad hij deze automatisch tijdens de installatie. Hij kan ze ook van het netwerk afhalen, maar dat gaat met netwerkdrivers wat lastiger. Verder is het ook makkelijker gemaakt om zelf een eigen CD met andere firmware te creeren (de .iso van debian downloaden, uitpakken, op de 2e partitie de firmware zetten en weer een .iso van maken, zijn tooltjes voor ).
)." Dat is een van de dingen die juist is verbeterd met deze release. Je kan gewoon een USB stick of CD met firmware images in de server stoppen en dan laad hij deze automatisch tijdens de installatie. "
dat ging met Lenny ook al
dat ging met Lenny ook al
Hmm, het nieuwe was kennelijk dat je de firmware images nu ook op de installatie CD kan zetten in plaats van daar een 2e CD voor te hoeven gebruiken. Verder heeft de installer ook support voor isohybrid images met firmware partities, dus je kan gewoon een CD downloaden, die naar USB wegschrijven, de firmware erop zetten en booten, dat is toch een stuk makkelijker dan met Lenny
Vertel me maar 's hoe ik dat met een PXE install ga regelen voor, inderdaad, nic drivers 
Da's een lastige, niet?
(Nouja 't kan wel, maar dan moet ik opeens zelf een pxe image gaan maken waar ik die anders gewoon kan downloaden en gebruiken).
Da's een lastige, niet?(Nouja 't kan wel, maar dan moet ik opeens zelf een pxe image gaan maken waar ik die anders gewoon kan downloaden en gebruiken).
[Reactie gewijzigd door CyBeR op zondag 6 februari 2011 18:30]
He, er zijn gewoon scriptjes die precies dat doen
Het is wat omslachtig, maar het is al een stuk makkelijker dan in eerdere releases
Het is wat omslachtig, maar het is al een stuk makkelijker dan in eerdere releases
Als je de moeite neemt om een PXE server te bouwen kan je net zo goed nog even een eigen (mirror) repository maken inclusief non-free.
Hoe is de PXE install van debian overigens? Ik baal er bij ubuntu een beetje van dat ik handmatig de menu's door moet om de nieuwe kernel(s) toe te voegen.
Hoe is de PXE install van debian overigens? Ik baal er bij ubuntu een beetje van dat ik handmatig de menu's door moet om de nieuwe kernel(s) toe te voegen.
Nee dus, want in de PXE image zit de firmware voor je netwerkkaart niet waardoor je heel die repository niet kunt benaderenAls je de moeite neemt om een PXE server te bouwen kan je net zo goed nog even een eigen (mirror) repository maken inclusief non-free.
Je moet dan dus de PXE-image aanpassen* zodat die firmware er wel bijzit. En daarna kun je weer gewoon de repos op het internet gebruiken.*) Heeft intussen vast al iemand gedaan en online gezet.
Dus Debian is nu al met 3 kernels beschikbaar, Linux, kFreeBSD en Hurd. Het is dus eigenlijk niet meer een echte Linux distributie. Langzamerhand de motor van de Opensource core, aangezien Ubuntu een polisched version van Debian is en en het merendeel van de anderen weer op Ubuntu is gebaseerd ...
toch een grote verdienste
toch een grote verdienste
Let wel op de de kFreeBSD en vooral de Hurd port lang niet alle software beschikbaar hebben of stabiel werken. kFreeBSD heeft dan ook het label "technology preview" gekregen en de Hurd port is niet eens meegereleased.
Hurd is nog niet eens "gold". Laten we die dus voorlopig maar niet meetellen.
"Debian GNU/kFreeBSD"
Hierin zit dus nog steeds GNU userland.
Is het niet logisch om misschien de GNU tools voor de BSD equivalenten in te ruilen waar mogelijk?
Het zou uiteindelijk grappig zijn als Debian BSD als basis krijgt en er dus geen sprake meer is van "Linux" als het gaat om Debian.
Wat doet de meest populaire distro die Debian als input gebruikt (ubuntu) dan en wat heeft dat voor effect op de "Linux" markt in zijn geheel en op de "low-profile" aandacht die BSD (onterecht) krijgt in het bijzonder?
Stel je eens voor in 2015: Ubuntu en Debian zijn BSD-based.
Waarschijnlijk gaat dat niet gebeuren en blijft de "BSD Debian" een dingetje in de marge.
Maar toch leuk om erover na te denken.
Hierin zit dus nog steeds GNU userland.
Is het niet logisch om misschien de GNU tools voor de BSD equivalenten in te ruilen waar mogelijk?
Het zou uiteindelijk grappig zijn als Debian BSD als basis krijgt en er dus geen sprake meer is van "Linux" als het gaat om Debian.
Wat doet de meest populaire distro die Debian als input gebruikt (ubuntu) dan en wat heeft dat voor effect op de "Linux" markt in zijn geheel en op de "low-profile" aandacht die BSD (onterecht) krijgt in het bijzonder?
Stel je eens voor in 2015: Ubuntu en Debian zijn BSD-based.
Waarschijnlijk gaat dat niet gebeuren en blijft de "BSD Debian" een dingetje in de marge.
Maar toch leuk om erover na te denken.
Debian GNU/kFreeBSD is al geen Linux.
En Debian is juist de GNU userland, met verschillende Kernels. GNU uit Debian halen is dus alles behalve logisch.
En Debian is juist de GNU userland, met verschillende Kernels. GNU uit Debian halen is dus alles behalve logisch.
Dat zeg ik ook niet.Debian GNU/kFreeBSD is al geen Linux
Nee hoor.En Debian is juist de GNU userland
Debian is Linux plus de "GNU tools" plus alles wat "daarna" voor debian is gemaakt of een implementatie heeft gekregen. Dat is zeker niet per definitie GNU.
Als je de userland ook omwisseld dan is het toch gewoon weer freebsd? Het hele idee is dat het een alternatief is voor mensen die graag de BSD kernel willen gebruiken maar juist erg happy zijn mijn de gnu userland tools. Beetje best of both worlds.Hierin zit dus nog steeds GNU userland.
Is het niet logisch om misschien de GNU tools voor de BSD equivalenten in te ruilen waar mogelijk?
Technisch gezien is GNU/kFreeBSD al geen linux meer, de kernel is namelijk hetgene dat linux heet. Niet de rest van het OS. Hier zijn al verschillende heilige oorlogen over gevoerd tussen opensource/free software fanaten in het verleden.Het zou uiteindelijk grappig zijn als Debian BSD als basis krijgt en er dus geen sprake meer is van "Linux" als het gaat om Debian.
Al met al is dit een positieve ontwikkeling. Een tweede goed bruikbare kernel is goed voor de concurentie en houd iedereen scherp. Er zal toch weer een groepje mensen BSD gaan uitproberen. Het levert ook weer een aantal testcases op en wie weet een paar extra drivers.
Nee GNU userland.Als je de userland ook omwisseld dan is het toch gewoon weer freebsd?
De "GNU tools" is een grote collectie van de meest basale tools die je gebruikt (ls, mv, cat, etc) en waren destijds bedoeld om de UNIX equivalenten te vervangen.
Daarbij zijn er ook vele nieuwe tools bijgekomen.
Echter Debian heeft ZELF OOK tools.
Denk aan apt. Dat is geen originele GNU tooling, maar geschreven door het Debian team.
Indien je dus een BSD kernel gebruikt, kan je ook de BSD tools gebruiken ipv de GNU equivalenten. Dan heb je geen freebsd.... maar wel meer BSD.
Zoals ik het zie heb je een laag kernel, een laag low-level en basale tools (nu GNU) en daarop specifieke distro OS delen.
BSD heeft eenzelfde toolset als GNU heeft en daar de kernel BSD kan zijn, is deze toolset ook uitwisselbaar.
Debians functionaliteit blijft dan gewoon dezelfde maar een "mv" commando is de BSD variant.
[Reactie gewijzigd door lenny_z op zondag 6 februari 2011 17:31]
Al met al ben ik juist vooral in deze build geïnteresseerd vanwege het gebruik van de GNU tools, liever niet de bsd varianten. Op andere unixen installeer ik ook de gnu tools en verander mijn standaard path zodat die eerst komen (/usr/local/gnu/bin).
Als debian helemaal bsd zou worden is er veel minder reden reden om debian te kiezen boven een andere bsd.
Als debian helemaal bsd zou worden is er veel minder reden reden om debian te kiezen boven een andere bsd.
[Reactie gewijzigd door cibrhusk op maandag 14 februari 2011 10:47]
Deze ga ik binnenkort ff downloaden en op mijn server knallen
Dit is wel heel jammer.ondanks dat de Linux-distro vooralsnog blijft vasthouden aan het gebruik van het verouderde init daemon-systeem
Het is niet verouderd.
Het is bejaard.
Ubuntu is al sinds versie 6 bezig met Upstart en ook Red Hat heeft dit (sinds Fedora 9) opgenomen. En alhoewel -ten behoeve van backwards compatibility- de systen V init scripts nog steeds worden gebruikt is onderwater al tijden upstart in gebruik en kan men als de tijd er rijp voor is (en dat is imho al JAREN, Linux had AL LANG event-based services moeten hebben) heel snel over naar event-driven services.
Dat event-driven services nog steeds niet standaard zijn binnen Linux is een voorbeeld hoe Linux als "community" ontwikkel model zichzelf juist tegenwerkt. Want deze verandering is zo ingrijpend dat niemand dit wilde veranderen enkel om de reden dat je niet de compatibilteit wil breken met "de rest van de Linux wereld".
De enorme voorzichtigheid waarmee upstart zijn intrede doet is hier inherent aan.
Wat dat aangaat mogen Linux beheerders jaloers kijken naar Windows.
Het services model wat Windows al jaren heeft is simpelweg moderner, flexibeler en stabieler dan die eeuwige init scripts.
Ik ben behoorlijk Linux fanboy, maar die init scripts zijn me al heel lang een doorn in het oog: een lange lint van statische scriptjes die elkaar moeten triggeren en met veel gekunstel parallel worden gemaakt. Het is gewoon lelijk.
insserv lost een groot deel van de door jou genoemde problematiek gewoon op hoor.
Upstart is leuk, (en er was ook iets als kickstarter ofzo), maar kijk eens naar Darwin's launchd, vele malen beter.
Upstart is leuk, (en er was ook iets als kickstarter ofzo), maar kijk eens naar Darwin's launchd, vele malen beter.
Ondanks dat ze het oude init proces houden wordt wel "makefile style" event starting ondersteund. Ik meen zelfs dat het standaard aan staat. Hiermee worden services ook parralel gestart net als bij upstart.
Ubuntu heeft naar even-driven services nog wel een aantal extra features zodat ze bij kunnen houden welke harddisk blokken gelezen worden bij het booten, deze gemakkelijk beschikbaar maken voor snellere toekomstige boots, etc.
Het is idd misschien wat jammer, zeker als je bedenkt dat deze distro zeker nog weer twee jaar mee zal gaan tot de volgende versie. Aan de andere kant is debian natuurlijk vooral een server platform en als we upstart nog even twee jaar aankijken op ubuntu, zijn alle bugs er uit, en hebben we wederom een superstabiele debian. Prima plan toch?
Ubuntu heeft naar even-driven services nog wel een aantal extra features zodat ze bij kunnen houden welke harddisk blokken gelezen worden bij het booten, deze gemakkelijk beschikbaar maken voor snellere toekomstige boots, etc.
Het is idd misschien wat jammer, zeker als je bedenkt dat deze distro zeker nog weer twee jaar mee zal gaan tot de volgende versie. Aan de andere kant is debian natuurlijk vooral een server platform en als we upstart nog even twee jaar aankijken op ubuntu, zijn alle bugs er uit, en hebben we wederom een superstabiele debian. Prima plan toch?
Dat is niet het belangrijkste punt en ik zeg ook nergens dat services niet parallel gestart kunnen worden met het huidige model. Ik geef aan dat het kunst en vliegwerk is.Hiermee worden services ook parallel gestart net als bij upstart.
Alhoewel services als upstart beter parallel services kunnen starten.
Het grote nadeel van die init scripts is dat ze statisch zijn.
Als ik mijn netwerk kabel uit de machine trek en dan boot dan zullen script m.b.t. netwerk niet gestart worden: logisch, er is geen netwerk.
Services op basis van netwerken zullen niet gestart worden want er is geen netwerk. ook logsich.
Als ik eenmaal opgestart mijn netwerk kabel weer aansluit dan mis ik services daar services niet "event based" zijn. (ik sluit de netwerk kabel aan)
Overigens snap ik de kritiek op upstart niet zo...
Ubuntu start razendsnel, voor een groot deel mogelijk door upstart.
Bedenk a.u.b. wel dat het langzame booten op *NIX machines 90% veroorzaakt is door die init scripts. De kernel is al lang geladen maar het ploegen door al die scripts is zo langzaam.
Ik vind het juist goed dat er niet meteen door iedereen op the next best bandwagon gesprongen wordt en direct overal upstart op gezet wordt.
Ikzelf ben trouwens redelijk onder de indruk van systemd, dat mijns inziens meer de toekomst is dan upstart.
Ikzelf ben trouwens redelijk onder de indruk van systemd, dat mijns inziens meer de toekomst is dan upstart.
Event-driven services bestaan al jaren en iedereen is het er over eens dat dit concept beter is dan het system V init model.
Of dit uiteindelijk systemd is of upstart zal worden of een merge hiervan of nog iets anders dat zal me werkelijk jeuken.
Uiteraard moet de implementatie van event-driven services behoedzaam gebeuren.
Maar mijn "het zal nu toch wel een keer tijd worden" afdoen als springen op "the next best bandwagon" is wel heel conservatief.
Dat Linux nog steeds init scripts gebruikt anno 2011 is bijna een genant gegeven imho, er had al lang een solide services model moeten zijn.
Of dit uiteindelijk systemd is of upstart zal worden of een merge hiervan of nog iets anders dat zal me werkelijk jeuken.
Uiteraard moet de implementatie van event-driven services behoedzaam gebeuren.
Maar mijn "het zal nu toch wel een keer tijd worden" afdoen als springen op "the next best bandwagon" is wel heel conservatief.
Dat Linux nog steeds init scripts gebruikt anno 2011 is bijna een genant gegeven imho, er had al lang een solide services model moeten zijn.
Een van de plannen voor Wheezy, de volgende versie en opvolger van Squeeze, is om meerdere init systemen te ondersteunen. Een hiervan is de inderdaad Upstart, maar ook bijvoorbeeld systemd en de klassieke init scripts. Voordeel hiervan is dat de keuze aan de system admin is voor wat er gebuikt moet worden: op servers kiezen mensen liever voor de oude bekende, betrouwbare init-scripts, aangezien bootperformance daar niet belangerijk is. Op desktops daarentegen ga je liever voor de het beste en snelste.
Je roept dan wel..
Maar bootperformance is nauwelijks het belangrijkste pluspunt van event-driven services.
Je noemt init-scripts "betrouwbaar" ik zou je willen vragen het system V init concept naast het event-driven services model te leggen. Ik kan je zeggen dat je er maar heel even naar hoeft te kijken om per definitie het system V model als minder flexibel en onbetrouwbaarder te bestempelen.
DEFAULT blijven we wij het oude.
Dit is met veel zaken zo.
ACL's zijn onder Linux beschikbaar. Maar DEFAULT gebruikt alles nog dat hopeloos oude CHMOD systeem. gevolg: iedereen gebruikt chmod.
En over ACL's kan je precies hetzelfde verhaal vertellen als over system V init en upstart of systemd.... dat had al lang standaard moeten zijn.
Het is dat eeuwige "tools not policy" wat niet zo zeer uit ideologisch perspectief blijft hangen als wel uit bittere noodzaak: Het aanbod aan Linux distro's die toch enigzins compatible met elkaar moeten zijn.
Echter: Als een belangrijke distro besluit iets "default" anders te doen dan "de rest" dan is dat wel degelijk "policy".
Zoals Red Hat nu Xen laat vallen voor KVM: het heeft effect.
Hou aub op met "oud en vertrouwd" want veelal is het "oud en inferieur" waar fanboys steevast blijven herhalen dat het "oud en stabiel is" en dat is zo'n beetje het meest gebruikte misplaatste excuus voor alle achterhaalde zooi in unix-like systemen.
En dat klopt ook.aangezien bootperformance daar niet belangerijk is
Maar bootperformance is nauwelijks het belangrijkste pluspunt van event-driven services.
Je noemt init-scripts "betrouwbaar" ik zou je willen vragen het system V init concept naast het event-driven services model te leggen. Ik kan je zeggen dat je er maar heel even naar hoeft te kijken om per definitie het system V model als minder flexibel en onbetrouwbaarder te bestempelen.
En dat is nou precies wat me niet bevalt aan veel innovaties onder Linux distro's.Voordeel hiervan is dat de keuze aan de system admin is voor wat er gebuikt moet worden: op servers kiezen mensen liever voor de oude bekende, betrouwbare init-scripts
DEFAULT blijven we wij het oude.
Dit is met veel zaken zo.
ACL's zijn onder Linux beschikbaar. Maar DEFAULT gebruikt alles nog dat hopeloos oude CHMOD systeem. gevolg: iedereen gebruikt chmod.
En over ACL's kan je precies hetzelfde verhaal vertellen als over system V init en upstart of systemd.... dat had al lang standaard moeten zijn.
Het is dat eeuwige "tools not policy" wat niet zo zeer uit ideologisch perspectief blijft hangen als wel uit bittere noodzaak: Het aanbod aan Linux distro's die toch enigzins compatible met elkaar moeten zijn.
Echter: Als een belangrijke distro besluit iets "default" anders te doen dan "de rest" dan is dat wel degelijk "policy".
Zoals Red Hat nu Xen laat vallen voor KVM: het heeft effect.
Hou aub op met "oud en vertrouwd" want veelal is het "oud en inferieur" waar fanboys steevast blijven herhalen dat het "oud en stabiel is" en dat is zo'n beetje het meest gebruikte misplaatste excuus voor alle achterhaalde zooi in unix-like systemen.
[Reactie gewijzigd door lenny_z op zondag 6 februari 2011 16:44]
Dat klopt; maar het oude System V model is al 10+ jaar in gebruik in Debian en dat werkt ook gewoon altijd. Als je alles gaat omzetten naar event-based booten dan introduceer je daarmee onvermijdelijk ook bugs, en daarom is het goed om ook de oude mogelijkheid te behouden. Begrijp me niet verkeerd; ik ben ook een voorstander van vooruitgang en heb op m'n desktop al geexperimenteert met systemd (veel belovend!) en ik heb liever ook dat alles vandaag al op die manier werkt dan gisteren, maar je moet realistisch blijven: een foutloze introductie is niet snel te doen. Vandaar dat er de keuze komt; wat imho altijd goed is, zolang er een goede default is, die waarschijnlijk relatief laat in de development cycle besloten gaat worden. Dus als iemand (dat kan jij) zorgt dat over 1,5 jaar alles in Debian goed omgaat met Upstart en het betrouwbaar werkt, dan kan het heel goed zijn dat we in Wheezy zien dat Upstart de default is.Je noemt init-scripts "betrouwbaar" ik zou je willen vragen het system V init concept naast het event-driven services model te leggen. Ik kan je zeggen dat je er maar heel even naar hoeft te kijken om per definitie het system V model als minder flexibel en onbetrouwbaarder te bestempelen.
Hmm, het kan aan mij liggen, maar ik vind het ouderwetse chmod systeem veel lekkerder werken dan het ACL systeem. Bij mij gaat het altijd mis met de masks en ACLs van nieuwe bestanden en kreeg ik bestanden met hele rare ACLs. Alles omgezet naar Unix-groupen en met setgid werkte het in een keer. Verder is ACL puur een uitbreiding op het chmod systeem.Dit is met veel zaken zo.
ACL's zijn onder Linux beschikbaar. Maar DEFAULT gebruikt alles nog dat hopeloos oude CHMOD systeem. gevolg: iedereen gebruikt chmod.
En over ACL's kan je precies hetzelfde verhaal vertellen als over system V init en upstart of systemd.... dat had al lang standaard moeten zijn.
offtopic, maar..Hmm, het kan aan mij liggen, maar ik vind het ouderwetse chmod systeem veel lekkerder werken dan het ACL systeem. Bij mij gaat het altijd mis met de masks en ACLs van nieuwe bestanden en kreeg ik bestanden met hele rare ACLs. Alles omgezet naar Unix-groupen en met setgid werkte het in een keer. Verder is ACL puur een uitbreiding op het chmod systeem.
Dat zegt dan meer over de implementatie van ACL's binnen Unix dan over ACL's in het algemeen.
Over het algemeen heb ik vooral Linux machines gebruikt voor webservers en applicaties waarvan veel databases en waren de rechten die gezet moesten worden niet zo spannend.
Als ik echter bedenk wat voor uitgebreide rechtenstructuur ik in Windows omgevingen heb moeten toepassen dan moet ik er niet aan denken zoiets met CHMOD te moeten doen...
Ik kan niet anders zeggen (zonder Windows fanboy te zijn) dan dat de ACL's onder Windows prettiger, sneller en flexibeler werken dan CHMOD en ik het eigenlijk alleen maar prachtig zou vinden als een soortgelijk systeem makkelijk toe te passen was binnen Linux, liefst via een GUI en dat dan default.
Misschien is de implementatie wel de reden dat het nog niet default is?
Maar het chmod systeem is helemaal niet zo moeilijk: je maakt een groep aan, je geeft deze groep schrijfrechten tot de map en vervolgens maak je deze map setgid (chmod g+ws). Iedereen die schrijfrechten tot die map moet hebben voeg je vervolgens toe aan de groep en je bent klaar. Als je andere mensen het ook mogen lezen doe je een chmod chmod o+rx, anders een chmod o-rx op de map en je bent klaar. Met de goede tooltjes en LDAP is dat ook makkelijk grafisch te doen. Nu weet ik niet hoe de ACLs onder Windows werken, maar het lijkt me niet heel veel eenvoudiger?
Overigens heeft Dolphin al een GUI implementatie van ACLs.
Maar het chmod systeem is helemaal niet zo moeilijk: je maakt een groep aan, je geeft deze groep schrijfrechten tot de map en vervolgens maak je deze map setgid (chmod g+ws). Iedereen die schrijfrechten tot die map moet hebben voeg je vervolgens toe aan de groep en je bent klaar. Als je andere mensen het ook mogen lezen doe je een chmod chmod o+rx, anders een chmod o-rx op de map en je bent klaar. Met de goede tooltjes en LDAP is dat ook makkelijk grafisch te doen. Nu weet ik niet hoe de ACLs onder Windows werken, maar het lijkt me niet heel veel eenvoudiger?
Overigens heeft Dolphin al een GUI implementatie van ACLs.
[Reactie gewijzigd door hostname op zondag 6 februari 2011 17:48]
Ja, of andersom.Misschien is de implementatie wel de reden dat het nog niet default is?
Halve implementatie OMDAT het niet default is.
Beetje kip en ei verhaal.
Maar ik wil onder Gnome of KDE gewoon rechten kunnen zetten via de GUI.
Het zijn van die dingen die je via een GUI gewoon prettiger kan doen.
Lief dat je chmod gaat uitleggen, maar ik weet wel hoe chmod werkt hoor.Maar het chmod systeem is helemaal niet zo moeilijk
...
en je bent klaar.
chmod is een stuk simpeler in opzet dan de ACL onder windows.
Normaal gesproken zou ik de eerste zijn om te roepen: simpel is beter !
Maar is dit geval is het TE simpel.
De rechten die je via NTFS kan zetten zijn als het moet heel fijnmazig te maken en in combinatie met de groepen structuren (met uitgebreidere scopes dan binnen UNIX) en overerfbaarheid behoorlijk efficient en flexibel.
Als we het over share rechten zouden hebben (in het pre-ntfs tijdperk) dan zou ik direct voor CHMOD kiezen boven de beperkte share rechten.
Echter NTFS ACL's zijn baas boven CHMOD.
Volgens mij heb jij te lang op het windows platfrom gezeten om echt een solide mening te hebben.
Het standaard rechten systeem van unix is nagenoeg altijd flexibel genoeg geweest voor 95% van de doeleinden, het is simpel overzichtelijk en daarmee veiliger (minder human error). Voor die plaatsen waar jij dan ACLs wil gebruiken, be my guest, het kan ook, maar wat mij betreft hoe minder hoe beter.
Windows NTFS acl's zijn lang niet zo duidelijk en bieden geen goede ownership mogelijkheden, of een group is eigenaar, of een user, maar niet beiden.
Vervolgens krijg je bij de standaard ACL een authenticated users group, (lid van de users group) een system, een administrator en de administrators. Erg druk, maar ok.
Dan komen nog de deny rechten, best aardig voor de flexibiliteit, maar wel weer een punt waar je de fout in kan schieten, zelfs zo erg dat niemand, de system nog een administrator de rechten nog kan resetten en ik een Linux boot cd erin moet gooien om ntfs acl's te herstellen (ownership resetten help ook al niet). Mooi systeem hoor. Maar geef mij maar eenvoud.
Overigens hebben we dan nog niet gesproken over de veranderlijkheid van microsoft - zoals de anyone group (nu volkomen gelijk aan de authenticated users group).
Als ik kijk naar wat sys admins bij windows doen dan komt veelal het neer op de acl's zo simpel mogelijk maken en de ownership aan administrators geven. Ze gebruiken met opzet zo min mogelijk van de acl mogelijkheden en zorgen ervoor dat er geen wijzigingen kunnen worden gemaakt anders door henzelf.
Punt 1 is dus dat de ntfs acl's misschien flexibel zijn (minder flexibel dan die van unix acl's imho) maar dat al die flexibiliteit het overzicht verkleint en de human error vergroot.
Punt 2 is dus dat de NTFS acl's bij windows veel meer afhankelijk zijn van de buildin users en dat die veranderelijke eigenschappen hebben. Bij Unix kies ik wel of niet om others rechten te geven, de rest is volledig afhankelijk van ownership die ik zelf gekozen heb.
Enfin, ik ken wel meer mensen die hoog opgeven over de flexibiliteit van ntfs acls en de deny mogelijkheden, en onder windows zie ik tal van oplossingen hiermee, maar ik blijf erbij dat het beter was geweest als ze meer naar unix hadden gekeken.
Een oplossing waarin de default zonder acl's is maar elke gebruiker de mogelijkheid heeft om een file of directory op acl's te laten draaien vind ik het mooist.
Het standaard rechten systeem van unix is nagenoeg altijd flexibel genoeg geweest voor 95% van de doeleinden, het is simpel overzichtelijk en daarmee veiliger (minder human error). Voor die plaatsen waar jij dan ACLs wil gebruiken, be my guest, het kan ook, maar wat mij betreft hoe minder hoe beter.
Windows NTFS acl's zijn lang niet zo duidelijk en bieden geen goede ownership mogelijkheden, of een group is eigenaar, of een user, maar niet beiden.
Vervolgens krijg je bij de standaard ACL een authenticated users group, (lid van de users group) een system, een administrator en de administrators. Erg druk, maar ok.
Dan komen nog de deny rechten, best aardig voor de flexibiliteit, maar wel weer een punt waar je de fout in kan schieten, zelfs zo erg dat niemand, de system nog een administrator de rechten nog kan resetten en ik een Linux boot cd erin moet gooien om ntfs acl's te herstellen (ownership resetten help ook al niet). Mooi systeem hoor. Maar geef mij maar eenvoud.
Overigens hebben we dan nog niet gesproken over de veranderlijkheid van microsoft - zoals de anyone group (nu volkomen gelijk aan de authenticated users group).
Als ik kijk naar wat sys admins bij windows doen dan komt veelal het neer op de acl's zo simpel mogelijk maken en de ownership aan administrators geven. Ze gebruiken met opzet zo min mogelijk van de acl mogelijkheden en zorgen ervoor dat er geen wijzigingen kunnen worden gemaakt anders door henzelf.
Punt 1 is dus dat de ntfs acl's misschien flexibel zijn (minder flexibel dan die van unix acl's imho) maar dat al die flexibiliteit het overzicht verkleint en de human error vergroot.
Punt 2 is dus dat de NTFS acl's bij windows veel meer afhankelijk zijn van de buildin users en dat die veranderelijke eigenschappen hebben. Bij Unix kies ik wel of niet om others rechten te geven, de rest is volledig afhankelijk van ownership die ik zelf gekozen heb.
Enfin, ik ken wel meer mensen die hoog opgeven over de flexibiliteit van ntfs acls en de deny mogelijkheden, en onder windows zie ik tal van oplossingen hiermee, maar ik blijf erbij dat het beter was geweest als ze meer naar unix hadden gekeken.
Een oplossing waarin de default zonder acl's is maar elke gebruiker de mogelijkheid heeft om een file of directory op acl's te laten draaien vind ik het mooist.
[Reactie gewijzigd door cibrhusk op maandag 14 februari 2011 11:15]
Beter gezegd: het is veel te simpel. Bijvoorbeeld:Maar het chmod systeem is helemaal niet zo moeilijk:
user u0: rwx
user u1: rwx
user www-data: rx
Probeer dat maar eens met chmod. Nee, other is niet hetzelfde als www-data.
Goed punt. Het is wel mogelijk met twee groepen en de permissies van de parent directory, maar dat is vreselijk omslachtig inderdaad.
Das toch niet zo moeilijk?
group www-write
group www-data
Maak www-data owner van de bestanden/directories en www-write de group, maak www-data geen lid van de group www-write.
chmod u=rx,g=rwx some_file_or_directory
klaar.
Bij toegangsrechten is het imho heel eenvoudig: minder franje = meer security.
group www-write
group www-data
Maak www-data owner van de bestanden/directories en www-write de group, maak www-data geen lid van de group www-write.
chmod u=rx,g=rwx some_file_or_directory
klaar.
Bij toegangsrechten is het imho heel eenvoudig: minder franje = meer security.
@ Danny.
Wat jij doet in je oplossing is al weer kunst en vliegwerk:
(omslachtig inderdaad)
ACL's bieden het zetten van permissies voor groepen of gebruikers ook als die niet corresponderen met de eigenaar of de groep die eigenaar is.
Bit permissies zijn beperkt t.o.v. ACL's.
Ga aub niet beweren dat je met bit permissies hetzelfde kan.
Dat is gewoon niet zo.
Wat jij doet in je oplossing is al weer kunst en vliegwerk:
(omslachtig inderdaad)
ACL's bieden het zetten van permissies voor groepen of gebruikers ook als die niet corresponderen met de eigenaar of de groep die eigenaar is.
Bit permissies zijn beperkt t.o.v. ACL's.
Ga aub niet beweren dat je met bit permissies hetzelfde kan.
Dat is gewoon niet zo.
[Reactie gewijzigd door lenny_z op maandag 7 februari 2011 10:46]
1. Als non-root is chown geen optieMaak www-data owner van de bestanden/directorie
2. Owner (www-data) heeft chmod permissie wat niet de bedoeling was
Ik wacht even met upgrade totdat de nodige upgrade reviews en howto's zijn verschenen met de gebruikelijke pitfalls.
Misschien doe ik wel een clean install..
Misschien doe ik wel een clean install..
Leuk nieuws en verder niets ten kwade van Debian, maar het gedoe met de open/closed firmware van netwerk kaarten zoals aanwezig in veel HP en Dell servers is gewoon rot.
Het toont aan dat je eigenlijk niets meer met hardware te maken wilt hebben en er in 9/10 gevallen gewoon een virtualisatie laag tussen wilt zodat je je niet meer druk hoeft te maken of hardware wel ondersteund wordt.
Het toont aan dat je eigenlijk niets meer met hardware te maken wilt hebben en er in 9/10 gevallen gewoon een virtualisatie laag tussen wilt zodat je je niet meer druk hoeft te maken of hardware wel ondersteund wordt.
Daarom installeer je dan ook Xen. Oh wacht, dan moet je je hardware nog steeds installeren
Ik heb een vrij eenvoudige oplossing, gewoon dynamic boot images maken, dat wil zeggen, bij elke boot een hostname aannemen van bijv. base board UUID, en dan via DHCP een ip krijgen, verbinding maken met de provisioning server, die van volgens je hostname (=uuid) een image opstuurt die klaar is gemaakt met de juiste setup, drivers, configs enz. Dan reboot ie en na dat de SSH keys gemaakt zijn kan je inloggen op je splinternieuwe server met alle hardware direct ondersteund. Daar heb je dan Xen draaien, die je dan weer met dynamic boot images laat booten die op hun beurt DomU's downloaden en installen. Enz enz. Handig toch?
Ik heb een vrij eenvoudige oplossing, gewoon dynamic boot images maken, dat wil zeggen, bij elke boot een hostname aannemen van bijv. base board UUID, en dan via DHCP een ip krijgen, verbinding maken met de provisioning server, die van volgens je hostname (=uuid) een image opstuurt die klaar is gemaakt met de juiste setup, drivers, configs enz. Dan reboot ie en na dat de SSH keys gemaakt zijn kan je inloggen op je splinternieuwe server met alle hardware direct ondersteund. Daar heb je dan Xen draaien, die je dan weer met dynamic boot images laat booten die op hun beurt DomU's downloaden en installen. Enz enz. Handig toch?
You are kidding right?
Uiteraard doe je een netinstall maar dan moet je weer kloten om ook die firwares mee te gaan streamen. Tijdverspilling.
Flikker gewoon vmware oid op het metaal en je bent van het gezeur af.
Uiteraard doe je een netinstall maar dan moet je weer kloten om ook die firwares mee te gaan streamen. Tijdverspilling.
Flikker gewoon vmware oid op het metaal en je bent van het gezeur af.
[Reactie gewijzigd door Q op zondag 6 februari 2011 14:24]
Totdat je de server als database-server (of andere disk-i/o intensieve omgeving) wilt gebruiken. Dan loop je tegen de beperking van een virtuele omgeving aan.Flikker gewoon vmware oid op het metaal en je bent van het gezeur af.
Conclusie: Voor iedere omgeving dien je de beste oplossing te kiezen.
Databases zijn heel goed te virtualiseren. Jouw opmerking is zo achterhaalt door hedendaagse techniek.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Politiek en recht Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
