[Disc]Kan elke distributie als server-dist dienen....

[Zwerver]

N.a.v. verschillende opmerkingen in het Het grote welk OS (bijvoorbeeld linux distro) topic deel 5 topic de volgende stelling.

Elke distributie die secure omgaat met updates en upgrades kan als bedrijfsserver-dist dienen.

Dat er voorkeuren zijn m.b.t. welke dist je gebruikt is logisch, maar doet hier niet terzake. Ken jij distributies waar jij (gefundeerd en onderbouwt) van vindt dat ze echt niet als bedrijfsserver-dist kunnen beiden? En wat zijn dan je redenen?

Even een paar spelregels

Gewoon zeggen dat een dist zuigt, niet voldoet etc. is niet de bedoeling. Ik ga er vanuit dat iedereen hier een redelijk portie verstand heeft, anders dan post je hier niet, dus dan kan je ook onderbouwen waarom je iets vindt. Verder wil ik bepaalde personen vragen (en zij die de schoen passen trekken hem aan) om hun flames over bepaalde dist's, software etc. voor zich te houden.



Mijn mening

Oke, om maar te beginnen met een mooi standpunt.
Ik vind consumenten-dist's als Ubuntu, gentoo en archlinux niet geschikt voor server gebruik. Deze dist's doen hun best om zo up2date mogelijk te zijn waardoor software minder goed getest is (ja, ik ken de ~arch bladieblatags) en in het geval van gentoo is de enige reden om deze te gebruiken het (al dan niet behalen van) performance winst. Maar ik wil mijn servers niet laten compilen, in een productieomgeving wil ik helemaal geen gcc e.d. aanwezig hebben.

Wat vind ik wel goede server dist's?
Afhankelijk van het al dan niet certified zijn door externe leveranciers:

- Debian
- RHEL
- SuSE (Enterprise en groupware oplossingen)
- niet helemaal Linux maar wel NOS: alle commerciële unices (OpenVMS, AIX, Solaris e.d.) en Novell's OS's uiteraard

[ Voor 9% gewijzigd door Zwerver op 08-10-2005 11:36 ]

[Flapp]

Hoe zit het dan met fedora ?
Ik heb er goeie dingen over gehoord.

Zelf gebruik ik voor server APACHE onder WinXP
en ubuntu op mijn klooipc

[ Voor 38% gewijzigd door Flapp op 08-10-2005 00:16 ]

[frim]

Het ligt er maar net aan wat voor een server je wilt.

Heb je het over een server binnen een bedrijf, die misschien kritieke functies vervult, dan zou ik alleen een distributie gebruiken waarvan ik zeker weet dat er support voor te krijgen is, en die gebruikt wordt door veel mensen die in hetzelfde schuitje zitten; zo kun je sneller een oplossing vinden voor een probleem.

Heb je het over een servertje die thuis staat als hobby-projecte en waar een ftp-, http- en smpt-daemon op draaien, dan kun je het beste de distributie gebruiken die je het beste kent. Zeker als je er niet al te veel tijd aan wilt besteden is het makkelijker om iets bekends te gebruiken - Zolang het werkt werkt het, en als er eens iets mis gaat, nou dan los je dat terzijnertijd wel op. Mijn eigen server draait op archlinux, en doet het best goed. Hij is al een paar maanden niet meer geupdate, en er zijn wat dingetjes kapot, zoals nfs-support dat niet goed werkt, maar ik heb geen zin om er nu meer tijd in te steken.. Of ik nu fout bezig ben? Nee, vind ik niet, maar als ik een server zou moeten inrichten die een hoger doel heeft dan warez binnenhalen van torrentsites, zou ik geen arch nemen

[Zwerver]

Laten we het hebben over bedrijfsservers, dat zal ik ook even aanpassen in de SP. Dus niet de h-t-k-severs, maar "echte"-servers.

Fedora:

Dat is de ontwikkelversie van RHEL RH zegt er zelf van dat ze daar dingen uit overnemen, zodra ze getest zijn in Fedora.

[Kanarie]

Flapietoetoe schreef op zaterdag 08 oktober 2005 @ 00:14:
Hoe zit het dan met fedora ?
Ik heb er goeie dingen over gehoord.

Zelf gebruik ik voor server APACHE onder WinXP
en ubuntu op mijn klooipc

Fedora zie je verbazingwekkend vaak langskomen op allerlei servers, terwijl het toch duidelijk de 'unstable' speeltuin is van Red Hat.

Persoonlijk vind ik Fedora Core, Mandriva, openSuSe, Ubuntu (te verschillend van Debian) niet geschikt.
Maar het KAN wel.

Dus kan elke distributie als server-dist dienen? Afhankelijk van je eisen wel.

edit:
Sneller op "Verstuur bericht" drukken

[ Voor 6% gewijzigd door Kanarie op 08-10-2005 00:28 ]

[deepbass909]

Ik gebruik zelf nu een half jaar Gentoo op mijn servertje, en de flexibiliteit hiervan vind ik persoonlijk een erg groot voordeel. Je installeerd alleen de packages die je echt wilt gebruiken. Daarnaast is met een paar kleine aanpassingen je hele installatie hardend te maken.
Vooral de volledige controlle over wat er geïnstalleerd wordt spreekt mij erg aan. Mijn proces lijst is meer dan gehalveerd ten opzichte van een eerdere RH9 installatie.

Het grote nadeel is wel dat je niet even snel een installatie in elkaar zet en je er dus echt een paar dagen voor uit moet trekken voor alles goed draait (is wel sterk afhankelijk van de snelheid waarmee alles gecompileerd wordt natuurlijk).

[Zwerver]

THW Arie schreef op zaterdag 08 oktober 2005 @ 00:28:
[...]


Fedora zie je verbazingwekkend vaak langskomen op allerlei servers, terwijl het toch duidelijk de 'unstable' speeltuin is van Red Hat.

Persoonlijk vind ik Fedora Core, Mandriva, openSuSe, Ubuntu (te verschillend van Debian) niet geschikt.
Maar het KAN wel.

Dus kan elke distributie als server-dist dienen? Afhankelijk van je eisen wel.

edit:
Sneller op "Verstuur bericht" drukken

Mjah, to be honest, ik vind het wel heel erg fijn als ik er redelijk van uit kan gaan dat zaken als security updates, stable == stable etc. goed geregeld zijn op een bedrijfsserver. Ik moet er niet aandenken dat ik bij onze 25 servers elke keer met de hand moet gaan bekijken of een update wel stable genoeg is voor me Dus, imho heb je dus geen gelijk :_

[ChaserBoZ_]

deepbass909 schreef op zaterdag 08 oktober 2005 @ 00:28:
Ik gebruik zelf nu een half jaar Gentoo op mijn servertje, en de flexibiliteit hiervan vind ik persoonlijk een erg groot voordeel. Je installeerd alleen de packages die je echt wilt gebruiken. Daarnaast is met een paar kleine aanpassingen je hele installatie hardend te maken.
Vooral de volledige controlle over wat er geïnstalleerd wordt spreekt mij erg aan. Mijn proces lijst is meer dan gehalveerd ten opzichte van een eerdere RH9 installatie.

Het grote nadeel is wel dat je niet even snel een installatie in elkaar zet en je er dus echt een paar dagen voor uit moet trekken voor alles goed draait (is wel sterk afhankelijk van de snelheid waarmee alles gecompileerd wordt natuurlijk).

Is op te lossen door alle pakketten gecompileerd klaar te hebben

[Kanarie]

Zwerver schreef op zaterdag 08 oktober 2005 @ 00:30:
[...]


Mjah, to be honest, ik vind het wel heel erg fijn als ik er redelijk van uit kan gaan dat zaken als security updates, stable == stable etc. goed geregeld zijn op een bedrijfsserver. Ik moet er niet aandenken dat ik bij onze 25 servers elke keer met de hand moet gaan bekijken of een update wel stable genoeg is voor me Dus, imho heb je dus geen gelijk :_

Ik had in mijn post ook nog huis tuin en keukenservers meegenomen.

Voor bedrijfsservers vallen wat mij betreft die distro's dus af, want zoals je al zegt, stable betekent niet altijd hetzelfde. Zie Ubuntu versus Debian.

[Zwerver]

deepbass909 schreef op zaterdag 08 oktober 2005 @ 00:28:
Ik gebruik zelf nu een half jaar Gentoo op mijn servertje, en de flexibiliteit hiervan vind ik persoonlijk een erg groot voordeel. Je installeerd alleen de packages die je echt wilt gebruiken. Daarnaast is met een paar kleine aanpassingen je hele installatie hardend te maken.
Vooral de volledige controlle over wat er geïnstalleerd wordt spreekt mij erg aan. Mijn proces lijst is meer dan gehalveerd ten opzichte van een eerdere RH9 installatie.

Het grote nadeel is wel dat je niet even snel een installatie in elkaar zet en je er dus echt een paar dagen voor uit moet trekken voor alles goed draait (is wel sterk afhankelijk van de snelheid waarmee alles gecompileerd wordt natuurlijk).

Nah, sorry, maar een installatie met gentoo (om maar even aan te geven waarom ik die niet meereken) is echt niet gestripter dan een standaard debian install Je moet alleen bij de installatie wat beter opletten, maar je kan een kickstart bestandje aanmaken, dan loopt die install zo door naar het moment dat je wel packages moet bijinstalleren.

ChaserBoZ_ schreef op zaterdag 08 oktober 2005 @ 00:31:
[...]


Is op te lossen door alle pakketten gecompileerd klaar te hebben

En wanneer moet dat gedaan worden in een bedrijfsomgeving? Juist, onder werktijd. Dus echt geen argument in het voordeel van gentoo naar mijn mening

[Wirehead]

-Debian (het excellente apt-get en software die uitvoerig getest is, goed gedocumenteerd...)
-RHEL (de super-support die je erbij hebt)
-Solaris (tjah, niet zo snel en closed source (ja, nu ook opensolaris), maar enorm stabiel)
-Suse / Novell (tjah, dit hoeft geen introductie denk ik)

Verder ben ik idd niet zo te spreken over distro's als ubuntu, mandriva,.. Gewoonweg het feit dat deze distributies te "bloated" zijn, je verliest er als het ware de controle over.
Onnodige services die standaard geïnstalleerd worden, totaal gehackte scripts waar gewoonweg niks in terug te vinden is.. unstable zeg maar.

Ook gentoo is imho niet geschikt als productie-server os, ja, je kan well cross-compilen, etc.. Maar het probleem zit hem gewoon (zoals eerder aangehaald) in TE nieuwe packages: dwz. minder getest, je kan voor onverwachte problemen komen te staan, noem het maar op. Als admin kan je die tijd goed genoeg aan iets anders spenderen.

(Persoonlijk gaat mijn voorkeur nog altijd uit naar Debian, boven RHEL en aanverwanten.)

[smokalot]

bij gentoo hoef je niet perse te compileren op je productieserver, dat kan ook heel goed op een development machine gebeuren. Je hebt dan een systeem wat vergelijkbaar is met bv debian, alleen dan maak je alle packages zelf, en heb je dus ook volledige controle over alles wat erin zit. Ik denk dat veel bedrijven sowieso veel zelf compileren, en in dat licht is gentoo zo gek nog niet. Ik weet vrij zeker dat t.net ook niet de MySQL, PHP en Apache van slackware gebruikt bijvoorbeeld.

Een server moet in principe zo min mogelijk taken uitvoeren, dus een webserver doet alleen apache/PHP, en geen SQL bijvoorbeeld. Als je geen gd nodig hebt bij je php moet je t er ook niet inzetten, als er dan een fout in gd zit ben jij niet vulnerable tenminste. Op die manier zou je niet vaak updates hoeven uitvoeren, en dus is het zelf compileren uiteindelijk niet zoveel meer werk.

Ik denk dat ook bv een ubuntu installatie op die manier veilig te krijgen is. Er zijn natuurlijk een hoop features die nu eenmaal aanstaan bij desktop-distro's, en dat neemt nu eenmaal geheugen in beslag. Liever wil je dus een minimalistische distro, maar kwa veiligheid maakt t niet zo heel veel uit, mits je users geen shelltoegang hebben, en je firewall lekker strikt staat.

[Martin Sturm]

Ik denk dat CentOS ook wel zeker bruikbaar is op een productieserver. Het voordeel daarvan is dat je niet verplicht bent om de licentiekosten van RHEL te betalen, terwijl je wel de stabiliteit hebt. De community van CentOS levert imho voldoende zekerheid om het betrouwbaar te laten functioneren.
Ook OpenBSD/FreeBSD zijn imho bruikbaar op serversystemen, alleen zit je hier met mogelijk hardwarecompatibliteitsissues (en ook bij software tot op zekere hoogte.. hangt een beetje van het doel van je server af).

Overigens is een 'productie server' een beetje vaag begrip.. De meeste zullen waarschijnlijk met een 'server' een webserver/mailserver/ftpserver/fileserver-bedoelen, terwijl er toch ook echt servers in bedrijfsomgevingen zijn die worden gebruikt om te compilen, het leveren van shell-accounts, etc.

[Radiant]

Het valt me op dat FreeBSD hier nog niet langs is gekomen (of ging het hier nou perse om linux distributies? ). Met ports heb je toch nog een grote keuze aan software die up-to-date wordt gehouden. Verder geeft het virtual server 'jail' systeem een extra stukje veiligheid als je met meerdere klanten/gebruikers op 1 server werkt.

edit:
net dus wel.. ik moet sneller tikken/nalezen

Over de hardwarecompatibiliteit.. als je van te voren weet/beslist wat voor OS er op de server moet draaien kan je natuurlijk best de hardwareconfiguratie daar ook op afstemmen.

[ Voor 31% gewijzigd door Radiant op 08-10-2005 09:49 ]

[Cyphax]

Ik zie het ongeveer zo: je kunt elke distributie voor servers gebruiken, maar bij sommige distributies moet je er meer werk in steken. Men is altijd helemaal voor Debian op de server, maar vervolgens zou Ubuntu niet geschikt zijn? Misschien "stock" niet, maar uiteindelijk is Ubuntu gewoon Debian, waarbij ze voor jou vast allerlei packages geinstalleerd hebben. Dat kan je aanpassen tot je van al je packages stables hebt. Natuurlijk is het niet handig om dan Ubuntu te verkiezen boven Debian maar dat wil niet zeggen dat het niet gewoon kan. Lijkt mij namelijk wel, maar ik heb geen ervaring met bedrijfsservers op Linux, helaas.
Andersom kan wat mij betreft ook: een server-minded distributie op je desktop gebruiken. Je kunt Debian installeren en naar eigen smaak configureren zodat het een bruikbare desktop is. Maar het is veel minder werk gewoon Ubuntu te installeren, daar is een hoop werk voor je gedaan.
Nogmaals: ik heb geen ervaring met een bedrijfsserver draaiende op Linux. Als ik een distributie uit moest kiezen om te onderhouden zou het Slackware worden omdat ik daar meer ervaring mee heb dan welke andere distro ook. En als dat om wat voor reden ook niet ging, dan Debian.

[Super_ik]

slackware anyone? ik werk alleen maar met slack, zowel op klooipc als op bedrijfsserver.
maar nu ben ik wel benieuwd hoe andere hun meningen over slack zijn

[Wilke]

Zwerver schreef op zaterdag 08 oktober 2005 @ 00:08:
Ik vind consumenten-dist's als Ubuntu, gentoo en archlinux niet geschikt voor server gebruik.[..] in het geval van gentoo is de enige reden om deze te gebruiken het (al dan niet behalen van) performance winst. Maar ik wil mijn servers niet laten compilen, in een productieomgeving wil ik helemaal geen gcc e.d. aanwezig hebben.

Performancewinst is de slechtste reden om voor Gentoo te kiezen. Flexibiliteit is waar het om gaat. Dit heeft alleen zin als je op grote(re) aantallen machines hetzelfde OS gaat deployen, en je je eigen portage repository bijhoudt (zodat je zelf eerst kunt testen en dan automatisch laten upgraden).

Misschien zijn daarvoor ook makkelijkere oplossingen, maar je hebt bij Gentoo denk ik meer vrijheid/keuze dan bij veel andere systemen.

Ik vond zelf het artikel Gentoo for all the unusual reasons wat dat betreft erg interessant, het beschrijft precies wat ik bedoel.

Ik zie nu dat deepbass909 precies hetzelfde zegt eigenlijk, en ik had zijn post dus niet gezien voor ik dit schreef (shame on me...lees de draad, etc. ).

[Pim.]

Cyphax schreef op zaterdag 08 oktober 2005 @ 09:49:
Ik zie het ongeveer zo: je kunt elke distributie voor servers gebruiken, maar bij sommige distributies moet je er meer werk in steken. Men is altijd helemaal voor Debian op de server, maar vervolgens zou Ubuntu niet geschikt zijn? Misschien "stock" niet, maar uiteindelijk is Ubuntu gewoon Debian, waarbij ze voor jou vast allerlei packages geinstalleerd hebben. Dat kan je aanpassen tot je van al je packages stables hebt.

Hier ben ik het dus wel mee eens, er zijn zelfs redenen om bijv juist wel naar ubuntu te gaan en niet naar Debian, neem de x64 ondersteuning. Langzamerhad begint met steeds meer 64bits processoren te gebruiken en Debian krijg je die standaard nog niet werkend daarmee.
Ook heen Ubuntu een extra security check op zijn apt zitten die het nog nét iets veiliger maakt.
Dus het kiezen voor ubuntu en dan vervolgens srtippen naar een Debian (server) omgeving kan wel eens noodzakelijk zijn zelfs.

[Radiant]

Super_ik schreef op zaterdag 08 oktober 2005 @ 09:50:
slackware anyone? ik werk alleen maar met slack, zowel op klooipc als op bedrijfsserver.
maar nu ben ik wel benieuwd hoe andere hun meningen over slack zijn

Ik heb ook een tijdje slackware gedraaid, maar ben eigenlijk overgestapt naar Debian omdat ik het aanbod aan packages voor slackware wat weinig vond. Voor gewoon simpele LAMP-servers vind ik slackware wel nog steeds uitermate geschikt. Toch gebruik ik nu hiervoor ook Debian omdat het gewoon verrekte makkelijk is om je system up-to-date te houden en als je toch iets extra's nodig hebt het gewoon makkelijk kan installeren en het ook automatisch up-to-date wordt gehouden.

Je kan natuurlijk third-party packages gebruiken maar dan heb je nooit echt de garantie dat het stabiel draait, ook in combinatie met de rest van het systeem, en je bent altijd afhankelijk aan de auteur van dat package met (security) updates. Verder moet je dan altijd alle sites af waar je je packages vandaan hebt gehaald om te kijken of er nog updates zijn, ipv een apt-get update; apt-get upgrade

[zomertje]

Een productieserver is in mijn ogen een systeem wat niet zomaar onderuit mag gaan. In mijn werkomgeving staan een aantal Unix servers (AIX) die onmisbaar zijn voor de bedrijfsvoering. Als de belangrijkste daarvan omvalt dan kan 70-80% van het werk niet meer doorgaan. Die server moet ook niet schrikken van een berg disk o/i of een load die boven de 10 uitkomt. Natuurlijk wil je een systeem wat niet te zwaar belast wordt ivm performance, maar soms moet het gewoon even.

Ik heb nog geen vergelijking van een goede Linux distro met dezelfde taken en een Unix systeem. Ik hoop dat we die tests nog wel een keer gaan doen. Helaas is er nu geen tijd voor.

Verder denk ik dat Linux al erg volwassen aan het worden is en zeker serieus genomen moet worden. Bij een bedrijfskritisch systeem zou ik toch wel gaan voor een betrouwbare distro die gericht is op het bedrijfsleven en waar support voor geleverd wordt (RH, Suse enz)

[Marzman]

Radiant schreef op zaterdag 08 oktober 2005 @ 11:46:
[...]
Ik heb ook een tijdje slackware gedraaid, maar ben eigenlijk overgestapt naar Debian omdat ik het aanbod aan packages voor slackware wat weinig vond. Voor gewoon simpele LAMP-servers vind ik slackware wel nog steeds uitermate geschikt. Toch gebruik ik nu hiervoor ook Debian omdat het gewoon verrekte makkelijk is om je system up-to-date te houden en als je toch iets extra's nodig hebt het gewoon makkelijk kan installeren en het ook automatisch up-to-date wordt gehouden.

Je kan natuurlijk third-party packages gebruiken maar dan heb je nooit echt de garantie dat het stabiel draait, ook in combinatie met de rest van het systeem, en je bent altijd afhankelijk aan de auteur van dat package met (security) updates. Verder moet je dan altijd alle sites af waar je je packages vandaan hebt gehaald om te kijken of er nog updates zijn, ipv een apt-get update; apt-get upgrade

Dat is meteen ook weer het nadeel van het stabiele, goed uitgeteste debian (ben er ook een fan van ). Het is af en toe nodig zelf te prutsen of third party packages te installeren waardoor je een andere configuratie krijgt die niet helemaal goed is getest. Je hebt dan dezelfde problemen als met Ubuntu (heb er geen ervaring mee, maar las in de TS dat ze snel updaten/minder testen).

[Verwijderd]

Enkele servers bij ons draaien nog op redhat, maar omdat er voor rh geen 2.6 kernel is en er ook geen updates meer uitkomen word alles nu omgezet naar CentOS. De keuze voor CentOS is voor mij heel makkelijk, het werkt bijna het zelfde als rh en er zijn tenminste updates. RHEL zelf vindt ik niet zo interessant, de licentie kosten vindt ik onnodig omdat support kan je beter met google vinden.
Voordeel van CentOS is ook dat er veel te vinden is op het internet en problemen die ik vaak heb al opgelost zijn door anderen.

[Soultaker]

Zwerver schreef op zaterdag 08 oktober 2005 @ 00:08:
Ik vind consumenten-dist's als Ubuntu, gentoo en archlinux niet geschikt voor server gebruik. Deze dist's doen hun best om zo up2date mogelijk te zijn waardoor software minder goed getest is (ja, ik ken de ~arch bladieblatags) en in het geval van gentoo is de enige reden om deze te gebruiken het (al dan niet behalen van) performance winst. Maar ik wil mijn servers niet laten compilen, in een productieomgeving wil ik helemaal geen gcc e.d. aanwezig hebben.

Blijkbaar heb je die '~arch bladieblatags' toch niet goed begrepen. Als je geen slecht geteste software wil hebben, dan moet je inderdaad gaan ~arch versie van Gentoo draaien; dat is een keuze die jij maakt en voor productiesystemen gebruik je die ~arch tag dus ook niet. Dûh, dat is het hele doel van die tag. Dat argument snijdt dus geen hout.

Dat je geen software wil compileren op je server is een heel ander punt. Soms is het verdomd handig om software van source te compileren, bijvoorbeeld om een ander threading model te kunnen kiezen of om support voor features te verkrijgen die niet in een package geleverd mogen worden (zoals mp3 codecs, tot voor kort GIF creation support, allerlei encryptie; dat soort dingen).

Wat vind ik wel goede server dist's?
[..]
Afhankelijk van het al dan niet certified zijn door externe leveranciers:
- niet helemaal Linux maar wel NOS: alle commerciële unices (OpenVMS, AIX, Solaris e.d.) en Novell's OS's uiteraard

Waarom wel archaïsche systemen als VMS (wat trouwens géén UNIX is!) en geen stabiele UNIX-afgeleiden als FreeBSD of OpenBSD? Alleen omdat het niet door een externe leverancier geleverd wordt? Beetje kortzichting, naar mijn mening; grote bedrijven als XS4All en Yahoo draaien al jaren bedrijfskritieke systemen op FreeBSD, maar dan zou het voor jouw niet goed genoeg zijn omdat er geen verkoper is die jouw verteld dat het een goed alternatief is?

[M55]

Ubuntu wordt globaal geupdate elke 6 maanden, tussendoor zijn er enkel security updates.
Dus Ubuntu draait niet altijd de nieuwste versies (die dus minder getest zouden zijn, zoals bv bij Debian Unstable).

[ Voor 8% gewijzigd door M55 op 08-10-2005 15:18 ]

[Radiant]

Marzman schreef op zaterdag 08 oktober 2005 @ 13:22:
[...]

Dat is meteen ook weer het nadeel van het stabiele, goed uitgeteste debian (ben er ook een fan van ). Het is af en toe nodig zelf te prutsen of third party packages te installeren waardoor je een andere configuratie krijgt die niet helemaal goed is getest. Je hebt dan dezelfde problemen als met Ubuntu (heb er geen ervaring mee, maar las in de TS dat ze snel updaten/minder testen).

Dat is dan ook een probleem bij elke distro Maar ik heb nog weinig packages nodig gehad die niet in één van Debian's package repositories te vinden was. Op server gebied eigenlijk alleen PHP 5, die ik nu uit unstable geinstalleerd heb.

[MrBarBarian]

Zwerver schreef op zaterdag 08 oktober 2005 @ 00:25:
Laten we het hebben over bedrijfsservers, dat zal ik ook even aanpassen in de SP. Dus niet de h-t-k-severs, maar "echte"-servers.

Define bedrijfsservers... Ik heb Oracle op een server gezet voor een MKB-bedrijf en dat voldeed prima. In mijn huidige omgeving (Enterprise met zware eisen) voldoet linux minder snel.

Het het MKB zal zowat iedere linux distro kunnen voldoen (afgezien van de live-cd variaties).. Voor enterprise omgevingen KUNNEN ook veel linuxservers voldoen... Alleen dan spelen er wat andere factoren mee (garanties, ondersteuning enz).. niet alleen qua software, maar ook op hardware (beroemd en berucht is SUN, die nogal kleinzeurig is op support op hard/software die niet direct 100% voldoet aan hun supportbase))...

Maar als we het hardware gedeelte weer even laten vallen, dan blijven de softwarematige garanties en ondersteuning nog over. In dat geval denk ik dat iedere distro kan voldoen die supportcontracten aanbieden (RHEL, Suse en Mandriva zijn voor mij de bekendste en meest aansprekende)..

Maar laten we vooral niet vergeten dat Linux de kernel is, en die is op alle distro's hetzelfde.. Apache is Apache, en komt ook in ongeveer elke distro voor. En dat geld voor ongeveer ieder packages binnen Linux.

[Zwerver]

Soultaker schreef op zaterdag 08 oktober 2005 @ 15:13:
[...]

Blijkbaar heb je die '~arch bladieblatags' toch niet goed begrepen. Als je geen slecht geteste software wil hebben, dan moet je inderdaad gaan ~arch versie van Gentoo draaien; dat is een keuze die jij maakt en voor productiesystemen gebruik je die ~arch tag dus ook niet. Dûh, dat is het hele doel van die tag. Dat argument snijdt dus geen hout.

Dat argument snijdt wel degelijk hout. Mijn ervaring met Gentoo is dat er, ook met de ~arch tag uit nog packages doorheen glippen die niet stabiel genoeg zijn om onder hoge load te werken. Ik ken de dists die ik in de SP genoemd heb allemaal, 3/4 in productie en de rest is getest om eventueel in productie te nemen.

Dat je geen software wil compileren op je server is een heel ander punt. Soms is het verdomd handig om software van source te compileren, bijvoorbeeld om een ander threading model te kunnen kiezen of om support voor features te verkrijgen die niet in een package geleverd mogen worden (zoals mp3 codecs, tot voor kort GIF creation support, allerlei encryptie; dat soort dingen).

En dat is een reden om voor Gentoo te kiezen? Ik dacht het niet Als wij een stuk software nodig hebben wat niet door onze dist-boer geleverd wordt, dan compilen we dat zelf, met onze instellingen, testen het uitvoerig voordat het in productie gaat en zetten het dan pas in.

Waarom wel archaïsche systemen als VMS (wat trouwens géén UNIX is!)

Is mij bekend dat het geen Unix is, maar ik noem het gemakshalve even onder de Unices, anders kan ik overal uitzonderingen maken.

en geen stabiele UNIX-afgeleiden als FreeBSD of OpenBSD? Alleen omdat het niet door een externe leverancier geleverd wordt? Beetje kortzichting, naar mijn mening; grote bedrijven als XS4All en Yahoo draaien al jaren bedrijfskritieke systemen op FreeBSD, maar dan zou het voor jouw niet goed genoeg zijn omdat er geen verkoper is die jouw verteld dat het een goed alternatief is?

Alleen omdat er geen goede support opgeleverd wordt i.d.d. Ik wil niet dat een bedrijfskritisch gedeelte van ons bedrijf omvalt omdat er geen support vanuit een bedrijf geleverd wordt. Bij Yahoo en XS4All maakt het niks uit als er 1 bak down gaat, dan migreren ze het wel naar een andere, bij ons betekend het down gaan van een bak het verliezen van meerdere €€. En ja, die bakken hangen allemaal in clusters, maar je wil gewoon geen dagtaak hebben aan het continu moeten repareren van je clusters, daar heb je leveranciers voor.

Verder interesseert het me niks wat een verkoper me verteld, maar OpenVMS, AIX, Solaris e.d. hebben bewezen dat ze stabieler zijn dan de niet commerciële Unices, daar heb ik geen verkoper voor nodig.

MrBarBarian schreef op zaterdag 08 oktober 2005 @ 16:36:
[...]

Define bedrijfsservers... Ik heb Oracle op een server gezet voor een MKB-bedrijf en dat voldeed prima. In mijn huidige omgeving (Enterprise met zware eisen) voldoet linux minder snel.

Servers die ergens staan waar het crashen van zo'n bak geld kost. Dat het down gaan van een bak (en langer dan 10 minuten) betekend dat mensen niet kunnen werken.

[CyBeR]

Pim. schreef op zaterdag 08 oktober 2005 @ 10:52:
[...]


Hier ben ik het dus wel mee eens, er zijn zelfs redenen om bijv juist wel naar ubuntu te gaan en niet naar Debian, neem de x64 ondersteuning. Langzamerhad begint met steeds meer 64bits processoren te gebruiken en Debian krijg je die standaard nog niet werkend daarmee.

Dat is natuurlijk onzin. Ik heb zelf een Opteron 275 (64-bits en nog dualcore ook) met debian draaien. Ook draait debian prima op ppc64, UltraSPARCs, Alphas, Itaniums, etc. Allemaal 64-bit procs. D'r is zelfs een port voor IBM s/390 machines.

[ Voor 6% gewijzigd door CyBeR op 08-10-2005 22:32 ]

[MikeN]

Gentoo is een distro welke je over het algemeen niet op productieservers wilt hebben, dus iig kan niet iedere distro als server-distro dienen.

Het probleem bij Gentoo is aan de ene kant dat de portage tree continu update en dus geen twee servers op elkaar lijken als je die onafhankelijk van elkaar (zonder images of aparte portage tree) installed. Dat is lastig op het moment dat je performance tussen verschillende hardware wilt vergelijken of op het moment dat je tegen een vage bug aanloopt.

Nog veel irritanter is dat security-updates niet gebackport worden. Je moet gewoon naar de nieuwste versie. Nu vind ik dit over het algemeen niet zo'n grote ramp (meestal draait het wel, en als het eens een uur plat ligt is het ook geen gigantisch probleem), lastiger is het als de nieuwe versie ineens een nieuw configfile formaat heeft, of als er ineens nieuwe dependencies zijn die ook installed moeten worden. Het kost allemaal onnodig tijd en werk (om over de duur van het compilen of het updaten van je portage tree maar niet te spreken).

Om bovenstaande redenen zit ik er op dit moment ook over te denken wat te gaan testen met andere distro's, misschien daar binnenkort maar eens mee beginnen. (De reden dat er ooit voor Gentoo is gekozen was de vergevorderde 64 bits support, de goede community en de reden dat het niet van die bloatware is als Fedora)

[Soultaker]

Zwerver schreef op zaterdag 08 oktober 2005 @ 19:38:
Alleen omdat er geen goede support opgeleverd wordt i.d.d. Ik wil niet dat een bedrijfskritisch gedeelte van ons bedrijf omvalt omdat er geen support vanuit een bedrijf geleverd wordt. Bij Yahoo en XS4All maakt het niks uit als er 1 bak down gaat, dan migreren ze het wel naar een andere, bij ons betekend het down gaan van een bak het verliezen van meerdere €€. En ja, die bakken hangen allemaal in clusters, maar je wil gewoon geen dagtaak hebben aan het continu moeten repareren van je clusters, daar heb je leveranciers voor.

Voor BSD en Linux kun je ook support kopen. Ik moet bekennen dat ik daar zelf niet veel ervaring mee heb dus ik kan niet zeggen of (bv.) HP betere support levert op OpenVMS dan je voor FreeBSD kunt krijgen; aan wat voor taken moet ik precies denken?

Verder interesseert het me niks wat een verkoper me verteld, maar OpenVMS, AIX, Solaris e.d. hebben bewezen dat ze stabieler zijn dan de niet commerciële Unices, daar heb ik geen verkoper voor nodig.

Hoe dan? Waarom is een commerciële distro als Solaris en AT&T Unix wel goed, maar zodra hetzelfde OS vrij beschikbaar wordt gemaakt (OpenSolaris resp. FreeBSD) houdt het opeens op met stabiel te zijn? Wat zijn jouw maatstaven om te bepalen of een OS stabiel is en wanneer acht je dat bewezen?

[Zwerver]

Soultaker schreef op zondag 09 oktober 2005 @ 02:07:
[...]

Voor BSD en Linux kun je ook support kopen. Ik moet bekennen dat ik daar zelf niet veel ervaring mee heb dus ik kan niet zeggen of (bv.) HP betere support levert op OpenVMS dan je voor FreeBSD kunt krijgen; aan wat voor taken moet ik precies denken?

Databerekeningen? Waar geen fouten in gemaakt mogen worden en die moeten draaien op request? En dan hebben we het er nog niet eens over dat de software die erop draait niet eens gecertificeerd is voor Linux?

[...]

Hoe dan? Waarom is een commerciële distro als Solaris en AT&T Unix wel goed, maar zodra hetzelfde OS vrij beschikbaar wordt gemaakt (OpenSolaris resp. FreeBSD) houdt het opeens op met stabiel te zijn? Wat zijn jouw maatstaven om te bepalen of een OS stabiel is en wanneer acht je dat bewezen?

Onze testen hebben uitgewezen dat het voor ons gewoon niet stabiel genoeg is. Vergis je er niet in, als je een Alpha met OpenVMS koopt is de hardware er compleet op afgesteld. Dat is wel even wat anders dan een Linux-bak met Linux. Houdt er rekening mee dat je gewoon stabiel wil zijn op en top, je wil dat als er een probleem is dat de support direct op gang komt, dat men er direct is. Daarnaast wil je gewoon bij uitbreiding dat er serieus naar gekeken wordt. Allemaal zaken die bij commerciële Unices en de software die erop draait beter geregeld is dan bij de Linux distributies.

[JaQ]

Enerzijds gebruik ik Debian voor alle LAMP achtige zaken, FreeBSD als firewall/gateway en RHEL/RHAS of CentOS voor machines waar Oracle op gezet moet worden.

Mijn ervaringen met Debian zijn erg goed. Onderhoud is eenvoudig en e.e.a. draait stabiel (ik draai dus ook stable). Installeren, configureren en weinig meer naar hoeven te kijken. Precies wat je wilt in een hosting omgeving. Mijn ervaringen met FreeBSD zijn gemengd, maar dit komt voornamelijk door ijn gebrek aan kennis van FreeBSD.

RHEL/RHAS en CentOS zijn wat mij betreft prima distro's om Oracle (zowel databases als applicatie servers) op te installeren. CentOS gebruik ik voor alle test/ontwikkel omgevingen en RHEL of RHAS voor productieomgevingen. Het verschil komt door licentiekosten. Oracle dwingt af dat je je RHEL, RHAS of Suze gebruikt als je op linux wilt draaien. Bedrijfsmatig is de keuze bij ons op red hat gevallen. Ik weet best dat Oracle ook wel op debian draait (met wat kunst en vliegwerk), maar support vanuit Oracle wordt dan simpelweg niet geleverd (ergo: einde discussie). De stabiliteit van Oracle op linux is zeker zo goed als op solaris is mijn ervaring.

Overigens heb ik het vage gevoel (niet bewijsbaar) dat Oracle beter performed op CentOS dan op RHEL (op dezelfde hardware), ik kan alleen nog geen aanwijsbare reden vinden.

[Z-Dragon]

Misschien komt dat doordat CentOS kernel 2.6 gebruikt en RHEL niet?

[Soultaker]

Zwerver schreef op zondag 09 oktober 2005 @ 11:48:
Databerekeningen? Waar geen fouten in gemaakt mogen worden en die moeten draaien op request?

Daar heeft het besturingssysteem echt nul-komma-nul invloed op.

En dan hebben we het er nog niet eens over dat de software die erop draait niet eens gecertificeerd is voor Linux?

Dat is een heel ander verhaal. Op die commerciële UNIX'en kun je ook geen Windows software draaien bijvoorbeeld. Naar mijn ervaring wordt heel veel software wél officieel ondersteund voor besturingssystemen als Linux en FreeBSD.

Onze testen hebben uitgewezen dat het voor ons gewoon niet stabiel genoeg is. Vergis je er niet in, als je een Alpha met OpenVMS koopt is de hardware er compleet op afgesteld. Dat is wel even wat anders dan een Linux-bak met Linux.

Je zei in je TS anders dat sommige distributies van Linux wél voldoen. Sowieso valt er weinig te discussiëren als je bij voorbaat al mogelijke alternatieven diskwalificeert omdat ze niet aan 'jullie testen' voldoen (die vervolgens niet gespecificeerd worden: wat test je precies en hoe?).

Houdt er rekening mee dat je gewoon stabiel wil zijn op en top, je wil dat als er een probleem is dat de support direct op gang komt, dat men er direct is. Daarnaast wil je gewoon bij uitbreiding dat er serieus naar gekeken wordt. Allemaal zaken die bij commerciële Unices en de software die erop draait beter geregeld is dan bij de Linux distributies.

Nogmaals: dat is een verhaal van commerciële support. Je zei zelf al in je topic start dat dat afhankelijk is van de externe leveranciers; waarom voldoet een externe leverancier die Debian Linux levert wel en een die FreeBSD levert niet? Zonder individuele afwegingen kun je daar geen keuze tussen maken.

[Zwerver]

Soultaker schreef op zondag 09 oktober 2005 @ 20:36:
[...]

Daar heeft het besturingssysteem echt nul-komma-nul invloed op.

Onzin. Als een OS om wat voor reden dan ook vastloopt is de databerekening invalid.
[...]

Dat is een heel ander verhaal. Op die commerciële UNIX'en kun je ook geen Windows software draaien bijvoorbeeld. Naar mijn ervaring wordt heel veel software wél officieel ondersteund voor besturingssystemen als Linux en FreeBSD.

Dan wil ik wel eens zien welke software dat is, want zware pakketten (Oracle, Lotus Domino, SAS) worden afaik alleen maar gecertificeerd voor RH, SuSE en commerciele Unices.
Met wat patchwerk zal je de eerste twee best nog wel kunnen draaien op Debian, maar ondersteund is het niet!/

[...]

Je zei in je TS anders dat sommige distributies van Linux wél voldoen. Sowieso valt er weinig te discussiëren als je bij voorbaat al mogelijke alternatieven diskwalificeert omdat ze niet aan 'jullie testen' voldoen (die vervolgens niet gespecificeerd worden: wat test je precies en hoe?).

Jij vraagt mij waarom ik commerciele Unices prefeleer voor bepaalde zaken boven Linux, daarnaast vraag je me waarom ik kies voor RH/Debian. Ik geef daar al meerdere malen antwoord op: De Unices omdat de software dan certified draait, RH omdat een aantal pakketten daar certified op draait en Debian omdat deze distrubitie imho het beste omgaat met updates. Daarmee heb je je hele antwoord, dus ook het antwoord op de TS.

[...]

Nogmaals: dat is een verhaal van commerciële support. Je zei zelf al in je topic start dat dat afhankelijk is van de externe leveranciers; waarom voldoet een externe leverancier die Debian Linux levert wel en een die FreeBSD levert niet? Zonder individuele afwegingen kun je daar geen keuze tussen maken.

Debian voldoet ook zonder commerciele support voor bepaalde doeleinden, maar niet voor de bedrijfskritisch zaken die wij draaien. RH/SuSE voldoen wel, i.v.m. de certificering van de software op die dists. Voor firewall's e.d. zet ik dan Debian in, omdat deze bewezen voor ons de beste oplossing biedt.

De discussie over Linux <> Free/OpenBSD hebben we overigens helemaal niet gevoerd, jij probeert het nu die kant op te drukken. Je vraag aan mij was: waarom wel OpenVMS en geen Free/OpenBSD, dat antwoord heb ik nu al meerdere malen gegeven, maar je accepteert het gewoon niet

[zomertje]

Ik moet het eens zijn met Zwerver: database software zoals Oracle en Progress zijn er wel voor commerciele Unices, en eventueel voor RH en Suse. Niet voor dingen als debian of slackware enz.

[CyBeR]

Overigens is Oracle best op Debian Sarge aan de gang te krijgen, maar dat is een enorme hack en dus niet aan te raden.

[Soultaker]

Zwerver schreef op zondag 09 oktober 2005 @ 21:42:
Onzin. Als een OS om wat voor reden dan ook vastloopt is de databerekening invalid.

Daarom vraag ik: waarom is RHEL stabiel terwijl Debian met exact dezelfde hardware en vanilla kernel volgens jou niet stabiel is? Lijkt me sterk dat Redhat's patches de kernel stabieler maken dan die van Debian stable.

Dan wil ik wel eens zien welke software dat is, want zware pakketten (Oracle, Lotus Domino, SAS) worden afaik alleen maar gecertificeerd voor RH, SuSE en commerciele Unices.
Met wat patchwerk zal je de eerste twee best nog wel kunnen draaien op Debian, maar ondersteund is het niet!

Ah, dan komen we bij de (on)zin van certification uit. Dat heeft maar een beetje met stabiliteit te maken: je mag aannemen dat een gecertificeerde omgeving stabiel is maar dat een niet-gecertificeerde omgeving dus onstabiel is, is niet zomaar waar. Waar kan ik trouwens een lijstje vinden met certified operating systems? Op de Oracle website vind ik alleen maar 'supported operating systems' en dat is alles van 'Linux' (nogal algemeen) tot Mac OS-X; maar dat vind jij vast geen stabiel platform ook al vind Oracle van wel?

Jij vraagt mij waarom ik commerciele Unices prefeleer bepaalde zaken boven Linux, daarnaast vraag je me waarom ik kies voor RH/Debian. Ik geef daar al meerdere malen antwoord op: De Unices omdat de software dan certified draait, RH omdat een aantal pakketten daar certified op draait en Debian omdat deze distrubitie imho het beste omgvoor aat met updates. Daarmee heb je je hele antwoord, dus ook het antwoord op de TS.

Even voor de helderheid: is certificering dus het enige punt, of heb je nog andere argumenten? Ik blijf me namelijk afvragen waarom Debian wel stabiel zou zijn en bijvoorbeeld FreeBSD niet, terwijl voor beide OS'es commerciële support beschikbaar is. Als het alleen om certificering gaat kunnen we de discussie daarop toespitsen.

Je zegt zelf al dat je Debian wel vertrouwt als firewall; volgens mij zijn er talloze Linux en UNIX afgeleiden die als firewall enzo kunnen dienen. De ene wel accepteren en de andere niet vind ik dan nogal willekeurig.

De discussie over Linux <> Free/OpenBSD hebben we overigens helemaal niet gevoerd, jij probeert het nu die kant op te drukken. Je vraag aan mij was: waarom wel OpenVMS en geen Free/OpenBSD, dat antwoord heb ik nu al meerdere malen gegeven, maar je accepteert het gewoon niet

Ik hoef geen Linux <> BSD discussie te voeren hoor. En nee, je hebt me inderdaad nog niet overtuigd. Dat is een discussie; mensen accepteren je standpunt niet totdat je deze voldoende met argumenten hebt onderbouwd; dat is m.i. nog niet gebeurd.

edit:
Oh ja, ik wil je er ook nog aan herinneren dat de keuze van je software nogal samenhangt met de keuze van je operating system. Jij wijst een heleboel servers af omdat je er (bijvoorbeeld) Oracle op wil kunnen draaien, maar als je uitgaat van (bijvoorbeeld) Microsoft IIS dan is OpenVMS opeens ongeschikt en Windows Server 2003 geschikt. Als ik Oracle zou willen draaien zou ik inderdaad ook voor een officieel ondersteund operating system kiezen. Naar mijn mening diskwalificeert dat andere operating systems echter niet als server-OS.

[ Voor 14% gewijzigd door Soultaker op 09-10-2005 22:49 ]

[Zwerver]

Soultaker schreef op zondag 09 oktober 2005 @ 22:41:
[...]

Daarom vraag ik: waarom is RHEL stabiel terwijl Debian met exact dezelfde hardware en vanilla kernel volgens jou niet stabiel is? Lijkt me sterk dat Redhat's patches de kernel stabieler maken dan die van Debian stable.

Voor ons niet stabiel genoeg, als in: Als er iets mis is, dan kunnen we niet bij de maker van de dist terecht. Klaar.

[...]

Ah, dan komen we bij de (on)zin van certification uit. Dat heeft maar een beetje met stabiliteit te maken: je mag aannemen dat een gecertificeerde omgeving stabiel is maar dat een niet-gecertificeerde omgeving dus onstabiel is, is niet zomaar waar. Waar kan ik trouwens een lijstje vinden met certified operating systems? Op de Oracle website vind ik alleen maar 'supported operating systems' en dat is alles van 'Linux' (nogal algemeen) tot Mac OS-X; maar dat vind jij vast geen stabiel platform ook al vind Oracle van wel?

Zie jij mij dat zeggen? Nee toch? Ik geef mijn voorkeurs OS's aan, die binnen de range van NOS vallen, als Apple nog binnen NOS zou vallen had deze erbij gestaan, ook al zou ik het zelf niet zo snel gebruiken. Certificering is binnen een bedrijfsomgeving echt geen onzin. Het gaat er gewoon om of een dist door de leverancier van de software (Oracle bladiebla) ondersteunt wordt. Ik kan je nu al zeggen dat Debian en FreeBSD er niet bij zitten. Dus ja, dat is een belangrijk punt.

[...]

Even voor de helderheid: is certificering dus het enige punt, of heb je nog andere argumenten? Ik blijf me namelijk afvragen waarom Debian wel stabiel zou zijn en bijvoorbeeld FreeBSD niet, terwijl voor beide OS'es commerciële support beschikbaar is. Als het alleen om certificering gaat kunnen we de discussie daarop toespitsen.

Je zegt zelf al dat je Debian wel vertrouwt als firewall; volgens mij zijn er talloze Linux en UNIX afgeleiden die als firewall enzo kunnen dienen. De ene wel accepteren en de andere niet vind ik dan nogal willekeurig.

Ik heb aangegeven waarom Debian wel en FreeBSD niet. Heel simpel toch? Als je even naar boven scrollt staat daar: omdat ik Debian één van de beste vind qua update beleid. PUNT. Mijn mening, en nee, dat ga ik niet afzetten tegenover FreeBSD.

[...]

Ik hoef geen Linux <> BSD discussie te voeren hoor. En nee, je hebt me inderdaad nog niet overtuigd. Dat is een discussie; mensen accepteren je standpunt niet totdat je deze voldoende met argumenten hebt onderbouwd; dat is m.i. nog niet gebeurd.

Je voert hem anders wel.

edit:
Oh ja, ik wil je er ook nog aan herinneren dat de keuze van je software nogal samenhangt met de keuze van je operating system. Jij wijst een heleboel servers af omdat je er (bijvoorbeeld) Oracle op wil kunnen draaien, maar als je uitgaat van (bijvoorbeeld) Microsoft IIS dan is OpenVMS opeens ongeschikt en Windows Server 2003 geschikt. Als ik Oracle zou willen draaien zou ik inderdaad ook voor een officieel ondersteund operating system kiezen. Naar mijn mening diskwalificeert dat andere operating systems echter niet als server-OS.

Wel op het moment als je een bedrijfskritisch systeem moet draaien. Dan wil je gewoon dat er een professioneel bedrijf achter staat. Wil jij dat niet aannemen dan is w.m.b. op dit gebied geen discussie verder mogelijk, ga dan eerst maar met argumenten komen waarom je bepaalde software _wel_ wil draaien op een dist die niet door de leverancier van de software ondersteund wordt.

[smokalot]

Zwerver schreef op zondag 09 oktober 2005 @ 22:55:
[...]

Voor ons niet stabiel genoeg, als in: Als er iets mis is, dan kunnen we niet bij de maker van de dist terecht. Klaar.

[...]

Wel op het moment als je een bedrijfskritisch systeem moet draaien. Dan wil je gewoon dat er een professioneel bedrijf achter staat. Wil jij dat niet aannemen dan is w.m.b. op dit gebied geen discussie verder mogelijk, ga dan eerst maar met argumenten komen waarom je bepaalde software _wel_ wil draaien op een dist die niet door de leverancier van de software ondersteund wordt.

waarom hecht je zoveel waarde aan wie de packager is? alsof Red Hat alle broncode door heeft gelezen! Ook ben ik benieuwd hoe vaak je RH al hebt moeten inschakelen? Wat is ertegen om een ander bedrijf in te schakelen als er iets mis is? Dat zou je een stuk meer vrijheid geven (op het moment dat je geen oracle draait dan ), zoals FreeBSD, OpenBSD (vaak een goede keuze lijkt me!) of debian.

Overigens stelde Soultaker volgens mij helemaal niet voor om die bepaalde software op een unsupported systeem te draaien, maar ging het om het geval je dus wel een vrije oplossing kon kiezen.

[Zwerver]

smokalot schreef op zondag 09 oktober 2005 @ 23:24:
[...]

waarom hecht je zoveel waarde aan wie de packager is? alsof Red Hat alle broncode door heeft gelezen! Ook ben ik benieuwd hoe vaak je RH al hebt moeten inschakelen? Wat is ertegen om een ander bedrijf in te schakelen als er iets mis is? Dat zou je een stuk meer vrijheid geven (op het moment dat je geen oracle draait dan ), zoals FreeBSD, OpenBSD (vaak een goede keuze lijkt me!) of debian.

Overigens stelde Soultaker volgens mij helemaal niet voor om die bepaalde software op een unsupported systeem te draaien, maar ging het om het geval je dus wel een vrije oplossing kon kiezen.

Omdat je in bedrijven (op hosting en fileserving na) eigenlijk altijd te maken krijgt met bedrijfskritische app's? En die eisen dat nou eenmaal? Kijk iedereen kan een fileservertje neerzetten op basis van gentoo/debian/whatever. Dan nog zou ik eerder voor Debian gaan zodat je zeker weet dat de packages goed zijn, maar dat is mijn eigen mening/ervaring. Maar op het moment dat je met DB2/Oracle/Postgres(dat is dus niet Postgresql)/e.d. gaat werken dan zit je vast aan de door de leverancier van die software aangewezen dist.

Dan zeg ik dus: die andere dists zijn voor dat werk niet geschikt, Debian voor al het andere werk wel. Ik heb ook al eerder aangegeven dat Gentoo afvalt i.v.m. compilen wat je niet wil doen op een productieserver.

Dat mij in de mond gelegd wordt dat FreeBSD/OpenBSD niet zou voldoen is niet mijn fout, IK vind het niet geschikt ervoor. De redenen zijn overigens al langs geweest: minder hardware support, minder ondersteuning voor te krijgen e.d.

[Soultaker]

Zwerver schreef op zondag 09 oktober 2005 @ 22:55:
Voor ons niet stabiel genoeg, als in: Als er iets mis is, dan kunnen we niet bij de maker van de dist terecht. Klaar.

Je moet klagen bij degene van wie je de server koopt. RedHat levert geen betere support omdat het hun distro is hoor. Als je een Debian server van een commercieel bedrijf koopt dan leveren zij er óók support op.

Certificering is binnen een bedrijfsomgeving echt geen onzin. Het gaat er gewoon om of een dist door de leverancier van de software (Oracle bladiebla) ondersteunt wordt. Ik kan je nu al zeggen dat Debian en FreeBSD er niet bij zitten. Dus ja, dat is een belangrijk punt.

Het is belangrijk want het is geen onzin....? Ik mis de specifieke argumenten.

Het lijkt mij belangrijk om te weten dat een bepaalde applicatie stabiel draait; certificatie is daar een soort garantie voor, maar er zijn ook andere manieren om die zekerheid te krijgen. Doordat het bedrijf wat je servers levert dat weet of doordat je als bedrijf er goede praktijkervaringen mee hebt.

Zie jij mij dat zeggen? Nee toch? Ik geef mijn voorkeurs OS's aan, die binnen de range van NOS vallen, als Apple nog binnen NOS zou vallen had deze erbij gestaan, ook al zou ik het zelf niet zo snel gebruiken. [..] Ik heb aangegeven waarom Debian wel en FreeBSD niet. Heel simpel toch? Als je even naar boven scrollt staat daar: omdat ik Debian één van de beste vind qua update beleid. PUNT. Mijn mening, en nee, dat ga ik niet afzetten tegenover FreeBSD.

Ik meende dat onderwerp van discussie was welke besturingssystemen (on)geschikt zijn om te gebruiken op een productieserver. Dat is iets anders dan jouw persoonlijke voorkeur. Als je er niet over wil discussiëren open dan geen topic; ga dan niet mensen die argumenten verwachten beantwoorden met 'dat is mijn mening - PUNT'. Dat het jouw mening is is duidelijk, maar in zo'n topic verwacht ik argumentatie.

Je voert hem anders wel.

Wijs maar aan waar ik beargumenteer dat Linux beter is dan BSD of vice versa? Dat heb ik namelijk niet gedaan.

Wel op het moment als je een bedrijfskritisch systeem moet draaien. Dan wil je gewoon dat er een professioneel bedrijf achter staat. Wil jij dat niet aannemen dan is w.m.b. op dit gebied geen discussie verder mogelijk, ga dan eerst maar met argumenten komen waarom je bepaalde software _wel_ wil draaien op een dist die niet door de leverancier van de software ondersteund wordt.

Ik zeg dat helemaal niet (dat had smokalot ook goed gezien). Ik zeg alleen dat je niet zomaar alle besturingssystemen waar Oracle niet op gecertificeerd is kunt diskwalificeren als zijnde server-OS; als je andere applicaties wil draaien dan is het aanbod namelijk weer heel anders. (Vandaar het voorbeeld van IIS: dat draait niet op OpenVMS dus als je IIS wil draaien moet je geen OpenVMS server kopen, maar dat maakt OpenVMS niet ongeschikt als server-OS.)

[elevator]

Even ter definitie - als ik het hieronder over servers heb, heb ik het niet over de 8e node in een LB'ed SMTP cluster, heb ik het niet over je MySQL databaseje van www.mijnschildpad.nl en heb ik het niet over een webserver

Bij het inzetten van een server en de stabiliteit daarvan kies je voor een aantal zaken is mijn ervaring, ook al zou de desbetreffende applicatie geen eisen stellen aan het OS, dan nog heb je zaken die erg belangrijk zijn.

Zo wil ik - als ik een server inzet - ten minste voor 4 jaar lang geen enkele hardware of OS upgrade hoeven uit te voeren die fundamenteel zaken wijzigt (in het OS), oftewel - ik wil geen nieuwe versie installeren. Patches en fixes, ok - maar een nieuw release leven van een OS niet. Een eis is dus dat het OS voor tenminste 5 jaar (ja 5, uitfasering) ondersteund is vanuit de leverancier uit. Liefst zie je daarbij dat je nog een aantal additionele jaren kan kopen.

Met de overgebleven lijst van leveranciers (RedHat, SuSE) ga je dan op zoek naar een OS dat ook nog eens supported is door je favoriete hardware leverancier - je wilt namelijk geen dure self-monitoring server in een rack hangen om vervolgens niet al die nifty sensoren te kunnen gebruiken die erin zit.

Simpelweg om bovenstaande redenen vallen al een boel distributies af.

[MrBarBarian]

elevator schreef op zondag 09 oktober 2005 @ 23:59:
Met de overgebleven lijst van leveranciers (RedHat, SuSE) ga je dan op zoek naar een OS dat ook nog eens supported is door je favoriete hardware leverancier - je wilt namelijk geen dure self-monitoring server in een rack hangen om vervolgens niet al die nifty sensoren te kunnen gebruiken die erin zit.

Beetje reaclame,. maar Mandriva biedt ook 5 jaar ondersteuning.

Ik denk alleen dat je streven, zoals je het hier uitschrijft, niet realistisch is. Gegarandeerd dat er binnen 5 jaar een stukje hardware kapot gaat en ook gegarandeert dat in die 5 jaar er software geupgrade moet worden waardoor een restart noodzakelijk is. En uitgaande van dat cluster waar je het over hebt, dan is het niet zo'n probleem (das een van de leuke dingen van een cluster (helaas heeft een cluster alleen veel meer minder leuke dingen, aar dat terzijde ))\\

Maar ondersteuning door hardware leveranciers is idd een aardig probleem (vervelende is dat aardig wat Unix verkoperts ook hardware verpatsen)

Overigens vind juist de manier waarom linux omgaat het packages (dmv verschillende package management systemen) een van de sterke punten. Het upgraden van packages binnen Tru64 of SUN bijv heeft heel wat meer voet in aarde.

[ Voor 10% gewijzigd door MrBarBarian op 10-10-2005 00:14 ]

[MSalters]

Zwerver schreef op zondag 09 oktober 2005 @ 21:42:
Onzin. Als een OS om wat voor reden dan ook vastloopt is de databerekening invalid.

Vanuit P&W kan ik je melden dat een OS wat vastloopt een databerekening meestal niet invalide maakt. Er is maar 1 uitzondering: op Real Time systemen. In dat geval is VMS net zo'n slechte keus als de gemiddelde Linux distributie, Windows valt ook in die categorie, Solaris zit er iets boven en een heel stuk erboven heb je de echte RTOS, met bijbehorend nivo van vendor support.

In de praktijk los je namelijk een vastloper van het OS op door de berekening na het laatste checkpoint opnieuw op te starten. Op dat punt is er nog niets invalide. Natuurlijk, je bent wat tijd kwijt - maar hoe vaak crasht een OS nou?

[smokalot]

elevator schreef op zondag 09 oktober 2005 @ 23:59:
Even ter definitie - als ik het hieronder over servers heb, heb ik het niet over de 8e node in een LB'ed SMTP cluster, heb ik het niet over je MySQL databaseje van www.mijnschildpad.nl en heb ik het niet over een webserver

Bij het inzetten van een server en de stabiliteit daarvan kies je voor een aantal zaken is mijn ervaring, ook al zou de desbetreffende applicatie geen eisen stellen aan het OS, dan nog heb je zaken die erg belangrijk zijn.

Zo wil ik - als ik een server inzet - ten minste voor 4 jaar lang geen enkele hardware of OS upgrade hoeven uit te voeren die fundamenteel zaken wijzigt (in het OS), oftewel - ik wil geen nieuwe versie installeren. Patches en fixes, ok - maar een nieuw release leven van een OS niet. Een eis is dus dat het OS voor tenminste 5 jaar (ja 5, uitfasering) ondersteund is vanuit de leverancier uit. Liefst zie je daarbij dat je nog een aantal additionele jaren kan kopen.

Met de overgebleven lijst van leveranciers (RedHat, SuSE) ga je dan op zoek naar een OS dat ook nog eens supported is door je favoriete hardware leverancier - je wilt namelijk geen dure self-monitoring server in een rack hangen om vervolgens niet al die nifty sensoren te kunnen gebruiken die erin zit.

Simpelweg om bovenstaande redenen vallen al een boel distributies af.

tweakers.net is toch van een heel ander kaliber dan mijnschildpad.nl, en draait naar mijn weten al jaren naar tevredenheid op slackware, met PHP, MySQL en apache. Geen oracle, geen SUSE/RH. Nou snap ik dat zelfs het serverpark van t.net geen schoolvoorbeeld is van de kritische applicaties waar hierboven over gepraat wordt, maar zeg nu zelf, in hoeveel MKB bedrijven staan uberhaupt dergelijke machines?

In de meeste bedrijven waar ik heb gewerkt worden vooral de normale kantoorapplicaties gebruikt, met een groupware, soms wat CAD, hier en daar een terminalverbinding naar een of andere custom-made solaris-applicatie voor voorraadbeheer. Alleen de solaris-applicatie stelt specifieke eisen aan de server, groupware kan nu eenmaal overal mee, net als een mailserver, fileserver, webserver, proxy, enz.

[nzyme]

ik zou dit bijna een non-discussie willen noemen (hoe leuk die eigelijk ook is natuurlijk ) want eigelijk weten we allemaal het antwoord wel....
Bedrijven willen certified spul ivm support en shit, en ook vaak een "naam". Ze willen bij software problemen meteen een monteur van RH of Suse op de stoep hebben (vin ik onzin want zouden die lui echt zoveel meer weten dan de sysadmin zelf, ik bdoel als jij linux admin bent heb je dr ook wel aardig wat verstand van toch? Of zouden ze ter-plekke ff een patch coden ofzo ?)...

Het gaat verder ook contstant over dezelfde namen hier... Mandrake, Suse en RH. Gentoo is wegens het constant compileren en het TE up2date zijn al afgevallen en *BSD etc laat ik even buiten beschouwing. (voor het gemak )

En als slackware fan vraag ik me nog af waarom die naam zo weinig voorkomt in dit topic
zal wel komen door het feit dat het een A. ondergeschoven distro is en B. volgens veel mensen bagger package management heeft en C. <fill.me.in> is ?
Ik zelf zou iig voor slack gaan, maar als een stukje software (oracle lees ik hier vaak) alleen op bv RH wil draaien heb je dan een probleem....

[Rmg]

persoonlijk zie ik het probleem om bijvoorbeeld ubuntu of fedora te draaien op een productie server niet.

Ja ze proberen zo up to date mogenlijk te zijn maar uiteindelijk ben je zelf nogsteeds de gene die update. en op productie en bedrijfs kritische servers draai je niet vage software pakketten die wekelijks geupdate word en waar 2 keer per maand het configuratie bestand van formaat veranderd.

[Confusion]

zomertje schreef op zaterdag 08 oktober 2005 @ 13:09:
Bij een bedrijfskritisch systeem zou ik toch wel gaan voor een betrouwbare distro die gericht is op het bedrijfsleven en waar support voor geleverd wordt (RH, Suse enz)

elevator schreef op zondag 09 oktober 2005 @ 23:59:
Een eis is dus dat het OS voor tenminste 5 jaar (ja 5, uitfasering) ondersteund is vanuit de leverancier uit.

Met de overgebleven lijst van leveranciers (RedHat, SuSE)

Alleen omdat er ondersteuning moet zijn? Stelt die ondersteuning dan wel iets voor? Hebben de meeste bedrijven niet zelf mensen in dienst die de problemen oplossen lang voordat de support eindelijk eens reageert? Waarom niet Debian Stable en daar support op inhuren? Ik heb eerlijk gezegd nooit de indruk gekregen dat de support van RH of SuSe zo denderend is?

[elevator]

MrBarBarian schreef op maandag 10 oktober 2005 @ 00:08:
Ik denk alleen dat je streven, zoals je het hier uitschrijft, niet realistisch is. Gegarandeerd dat er binnen 5 jaar een stukje hardware kapot gaat en ook gegarandeert dat in die 5 jaar er software geupgrade moet worden waardoor een restart noodzakelijk is.

Ik zeg ook niet dat de hardware 'up' moet blijven - ik zeg dat de configuratie (en dat moet je dan zien als werkend systeem - niet als een bind.conf ) bevroren moet zijn, HP levert bijvoorbeeld met gemak een 4 jaar oude CPU als dat nodig is zonder dat ik opeens met mismatched CPU's zit in m'n hw config. Ik verwacht van een software leverancier hetzelfde - updates / fixes voor de software die je op dat moment draait en wil blijven draaien

---

smokalot schreef op maandag 10 oktober 2005 @ 00:42:
tweakers.net is toch van een heel ander kaliber dan mijnschildpad.nl, en draait naar mijn weten al jaren naar tevredenheid op slackware, met PHP, MySQL en apache. Geen oracle, geen SUSE/RH. Nou snap ik dat zelfs het serverpark van t.net geen schoolvoorbeeld is van de kritische applicaties waar hierboven over gepraat wordt, maar zeg nu zelf, in hoeveel MKB bedrijven staan uberhaupt dergelijke machines?

Hoeveel mensen verliezen daadwerkelijk geld doordat een applicatie als Tweakers.net BV niet up is?

Natuurlijk - Tweakers verliest veel geld aan inkomsten door banners e.d. - maar veel van die views zullen toch wel gemaakt worden (mensen komen wel terug een uurtje later als het weer werkt), terwijl bij een MKB bedrijf een order die niet verwerkt kan worden al snel een verloren order is. Een levering die te laat is levert al snel boetes op, en mensen die een hele ochtend niet kunnen werken gaan 's avonds overuren schrijven. Reeele kosten die absoluut niet te vergelijken zijn met een website die informatie verschaft - vergelijk het dan liever met een eBay of een Dell.com

---

Confusion schreef op maandag 10 oktober 2005 @ 01:33:
Alleen omdat er ondersteuning moet zijn? Stelt die ondersteuning dan wel iets voor? Hebben de meeste bedrijven niet zelf mensen in dienst die de problemen oplossen lang voordat de support eindelijk eens reageert? Waarom niet Debian Stable en daar support op inhuren? Ik heb eerlijk gezegd nooit de indruk gekregen dat de support van RH of SuSe zo denderend is?

In zekere mate wel - pak mijn voorbeeld van de hardware. HP kent HDD een pre-failure warranty replacement - dat houd in dat als een disk bij zich zelf denkt van goh, ik zou wel eens kapot kunnen gaan dat hij dit meld in z'n monitoring logs en dat je dan voordat de disk daadwerkelijk kapot is, deze alvast kan laten vervangen door HP (zeg maar Smart maar dan iets anders).

Zonder die logs (want die software is redelijk specifiek voor een distro versie) - heb je die vervangings mogelijkheid niet - zelfde met ECC errors of RAID errors - zonder supported monitoring tools heb je dus een veel minder waardevolle server

Qua support - het voordeel van een stabiel platform is niet alleen dat een vendor het supporteert, maar ook de kennis die om een platform heen hangt is stabiel. Je kan wel 3rd party support inhuren, maar als die dan roept 'mjah.. ik ben v0.03.a.1206275 gewend en dit is v0.02b-127755 en dus snap ik het niet zo' dan ben je als klant niet blij, dus ook hierbij speelt een rol dat je een betrouwbaar en berekenbaar platform nodig hebt

imho.

[smokalot]

ja, en mijn punt was dat er maar een heel klein deel van de servers zulk kritisch werk doet. Bij een mailserver van een gemiddeld bedrijf is het ook niet zo'n ramp als ie er een kwartiertje uitligt. Wel elk bedrijf heeft een mailserver, niet elk bedrijf is dell of eBay.

Ik denk dat iedereen het er wel over eens is dat zulke servers meer specialistische hard/software horen te draaien, maar ik denk dat in de meer low-end servers ook ruimte is voor andere software pakketten.

[Soultaker]

elevator schreef op maandag 10 oktober 2005 @ 02:16:
Qua support - het voordeel van een stabiel platform is niet alleen dat een vendor het supporteert, maar ook de kennis die om een platform heen hangt is stabiel. Je kan wel 3rd party support inhuren, maar als die dan roept 'mjah.. ik ben v0.03.a.1206275 gewend en dit is v0.02b-127755 en dus snap ik het niet zo' dan ben je als klant niet blij, dus ook hierbij speelt een rol dat je een betrouwbaar en berekenbaar platform nodig hebt

Wat je dus nodig hebt is een betrouwbare partij die goede support kan leveren; niet eentje die je opschepen met een systeem wat ze niet kunnen onderhouden. Dat is toch niet een probleem met het platform, lijkt me.

[Zwerver]

Soultaker schreef op maandag 10 oktober 2005 @ 03:13:
[...]

Wat je dus nodig hebt is een betrouwbare partij die goede support kan leveren; niet eentje die je opschepen met een systeem wat ze niet kunnen onderhouden. Dat is toch niet een probleem met het platform, lijkt me.

Er is al meerdere malen (ook door mij overigens) aangegeven dat Linux best zijn doel heeft, maar dan wel als het door de leverancier van de software en hardware (dat is nu een toevoeging ja) ondersteund wordt. Face it, er zijn barweinig leveranciers van hard- en software die FreeBSD/OpenBSD aanraden. Ook al is het nog zo'n mooi en stabiel systeem, voor grote bedrijven is het dan gewoon een nogo.

Dan kan je hoog en laag springen en mensen dingen in de mond leggen die ze niet gezegd hebben (sterker nog, ik heb al aangegeven dat we Debian gebruiken als het niet mission-critcal is) maar daarmee maak jij je punt niet sterker.

[Parasietje]

Er bestaat een groot misverstand over gentoo. Gentoo heeft de reputatie een distro te zijn voor dezelfde mensen die ook hun brommertjes tunen. Alle snelheid eruit persen die erin zit.

Maar bedenk je eens de kracht van USE-flags voor een server-systeem. Als je geen mysql-support gebruikt in PHP, dan laat je dat er gewoon uit. Als er nu een bug in php zit ivm mysql, dan ben je niet kwetsbaar: je hebt die functionaliteit er nooit in gecompileerd.
De tweede kracht van gentoo is het minimale. Je begint zo minimaal mogelijk en je kan zo een super-mini server opbouwen: enkel de functionaliteit die JIJ wil. En dat vind ik heel belangrijk in veiligheid: enkel hebben wat nodig is.

[MrBarBarian]

elevator schreef op maandag 10 oktober 2005 @ 02:16:
Qua support - het voordeel van een stabiel platform is niet alleen dat een vendor het supporteert, maar ook de kennis die om een platform heen hangt is stabiel. Je kan wel 3rd party support inhuren, maar als die dan roept 'mjah.. ik ben v0.03.a.1206275 gewend en dit is v0.02b-127755 en dus snap ik het niet zo' dan ben je als klant niet blij, dus ook hierbij speelt een rol dat je een betrouwbaar en berekenbaar platform nodig hebt

imho.

Nah, die kennis opzich valt nog wel eens tegen. Ik (en enkele collega's) hebben iemand van HP ook wel eens wat uit gelegt over een Tru64. Maar dat is niet erg. Naar mijn mening draait het om de garantie (centen dus). HP garandeert bijv een opslossing voor een probleem te hebben binnen een x-aantal dagen. Redden ze dat niet, dan moeten ze (dik) betalen.

De boete die ze dan krijgen is weer zodanig hoog, dat het voor HP aantrekkelijker is om te investeren in flinke kennis, dan het risico te lopen dat die boete een keer moet worden uitgekeert.

In hoeverre RH/Suse/Mandriva die garanties kunnen leveren weet ik eigelijk ook niet. Stel je een voor bijv dat je tegen een probleem aanloopt, dat erop duit dat er een fout in de door jou gebruikte kernel zit. Kan RH/Suse/Mandriva deze fout dan oplossen binnen een bepaalde tijd (of relevanter, durven ze die garantie te geven)? Volgens mij niet nl..

[MSalters]

elevator schreef op maandag 10 oktober 2005 @ 02:16:
[...]
Ik zeg ook niet dat de hardware 'up' moet blijven - ik zeg dat de configuratie (en dat moet je dan zien als werkend systeem - niet als een bind.conf ) bevroren moet zijn, HP levert bijvoorbeeld met gemak een 4 jaar oude CPU als dat nodig is zonder dat ik opeens met mismatched CPU's zit in m'n hw config.

6 jaar, volgens de Alpha End-Of-Life aankondiging. Overigens vrij lastig als je een klant hebt die VMS-op-Alpha geeist heeft en 10 jaar support, en je manager dat dan ook belooft.

Aan de andere kant beloven ze wel 10 jaar inclusief OS support voor VMS-op-Itanium.

[ Voor 9% gewijzigd door MSalters op 10-10-2005 23:34 ]

[Zwerver]

Parasietje schreef op maandag 10 oktober 2005 @ 23:17:
Er bestaat een groot misverstand over gentoo. Gentoo heeft de reputatie een distro te zijn voor dezelfde mensen die ook hun brommertjes tunen. Alle snelheid eruit persen die erin zit.

Maar bedenk je eens de kracht van USE-flags voor een server-systeem. Als je geen mysql-support gebruikt in PHP, dan laat je dat er gewoon uit. Als er nu een bug in php zit ivm mysql, dan ben je niet kwetsbaar: je hebt die functionaliteit er nooit in gecompileerd.
De tweede kracht van gentoo is het minimale. Je begint zo minimaal mogelijk en je kan zo een super-mini server opbouwen: enkel de functionaliteit die JIJ wil. En dat vind ik heel belangrijk in veiligheid: enkel hebben wat nodig is.

Ik snap niet wat het verschil is tussen Gentoo, Debian, SuSE en RH? Bij Debian bijvoorbeeld krijg je (mits je even oplet tijdens de installatie en niet domweg van alles installeert) ook een minimaal systeem? Sterker nog, libphp moet je zelf bij installeren, anders zit het er niet eens op. Niks niet moeilijk doen met USE-flags, gewoon niet installeren

Daarbij weet ik dat je bij RH en SuSE ook heel minimaal kan installeren, dan up(2)date je daarna gewoon een aantal packages erbij Allemaal dus geen voordelen voor Gentoo

[Soultaker]

Zwerver schreef op maandag 10 oktober 2005 @ 22:52:
Er is al meerdere malen (ook door mij overigens) aangegeven dat Linux best zijn doel heeft, maar dan wel als het door de leverancier van de software en hardware (dat is nu een toevoeging ja) ondersteund wordt. Face it, er zijn barweinig leveranciers van hard- en software die FreeBSD/OpenBSD aanraden. Ook al is het nog zo'n mooi en stabiel systeem, voor grote bedrijven is het dan gewoon een nogo.

Dat ben ik in principe met je eens, behalve dat er (en dat heb ik vaak genoeg gezegd) wél commerciële support voor FreeBSD te vinden is. Sowieso hebben de echt grote bedrijven (Yahoo, XS4All, ...) hun support gewoon 'in huis', natuurlijk. Dan ben je het toch met me eens dat het wel geschikt is als server-OS?

Zwerver schreef op maandag 10 oktober 2005 @ 23:53:
Ik snap niet wat het verschil is tussen Gentoo, Debian, SuSE en RH? Bij Debian bijvoorbeeld krijg je (mits je even oplet tijdens de installatie en niet domweg van alles installeert) ook een minimaal systeem? Sterker nog, libphp moet je zelf bij installeren, anders zit het er niet eens op. Niks niet moeilijk doen met USE-flags, gewoon niet installeren

Corrigeer me als het bij Debian anders zit, maar bij de meeste systemen gebaseerd op binary packages is de inhoud van een package vast: als je een package installeert heb je niets te kiezen. Daarom worden meestal alle nuttige dingen in een package gestopt: denk aan bijvoorbeeld zlib support in een webserver om deflate compression mogelijk te maken. Dat levert een dependency op zlib op en die móét je installeren om de package te kunnen installeren. Wordt er nu een bug gevonden in zlib, dan moet je dus je systeem updaten.

In Gentoo kun je in zo'n geval die hele zlib uit je USE flags laten en dan gebruiken applicaties die je 'm installeert 'm dus niet. Dat is fijn, want als je helemaal geen zlib-support nodig hebt hoef je je er dus ook geen zorgen over te maken. FreeBSD doet iets soortgelijks indien van source wordt geïnstalleerd, maar op basis van indivuele packages in plaats van voor het hele systeem tegelijk (USE flags).

Zo zijn er vaak een heleboel optionele features die je misschien liever níét wil hebben en in packages zitten die eerder wel dan niet (want als ze er niet in zitten, dan kun je ze op een binary-only systeem ook niet opkrijgen). Dat zijn dus in principe security risico's. Een Gentoo-installatie zal dan ook al snel 'slanker' zijn dan een Debian-installatie met dezelfde software er op.

[CyBeR]

Soultaker schreef op dinsdag 11 oktober 2005 @ 00:19:
[...]

Wordt er nu een bug gevonden in zlib, dan moet je dus je systeem updaten.

apt-get upgrade

Klaar.

In Gentoo kun je in zo'n geval die hele zlib uit je USE flags laten en dan gebruiken applicaties die je 'm installeert 'm dus niet. Dat is fijn, want als je helemaal geen zlib-support nodig hebt hoef je je er dus ook geen zorgen over te maken.

Laten we maar stellen dat je zlib gewoon wilt hebben, punt.

Zo zijn er vaak een heleboel optionele features die je misschien liever níét wil hebben en in packages zitten die eerder wel dan niet (want als ze er niet in zitten, dan kun je ze op een binary-only systeem ook niet opkrijgen). Dat zijn dus in principe security risico's. Een Gentoo-installatie zal dan ook al snel 'slanker' zijn dan een Debian-installatie met dezelfde software er op.

Waardoor je lekker overnieuw mag gaan compilen als je een van die niet-gecompilede features toch nodig hebt. (Absoluut niet ondenkbaar in bijvoorbeeld php.)

[Soultaker]

CyBeR schreef op dinsdag 11 oktober 2005 @ 01:17:
apt-get upgrade

Klaar.

Je mist het punt: het is veiliger en makkelijker om minder te hoeven updaten; er is immers altijd enige tijd tussen het uitkomen van een security advisory en het moment waarop je je systeem update: voorkomen is beter dan genezen. Je kunt zeggen wat je wilt, maar als je minder installeert is er minder aanleiding voor updaten.

Dat je makkelijk kan updaten met Debian is leuk, maar dat kan met andere besturingssystemen ook: emerge --update --deep world, of portupgrade -a. (Zomaar 'apt-get upgrade' doen is trouwens ontzettend kut als Debian-stable doorgeschoven wordt; dan gaan er gegarandeerd dingen stuk, maar dat terzijde.)

CyBeR schreef op dinsdag 11 oktober 2005 @ 01:17:
Laten we maar stellen dat je zlib gewoon wilt hebben, punt.

Laten we dat niet doen: het ging juist om features die je niet wil hebben; zlib was maar een voorbeeld. Denk er bovendien aan dat het niet alleen om het geïnstalleerd hebben van de package gaat, maar ook het gebruik ervan door andere applicaties. Als zlib wel geïnstalleerd is als dependency van een of andere lokale applicatie maar niet gebruikt wordt door webserver, dan scheelt je dat misschien een remote hole, ook al is de package zelf wel geïnstalleerd.

Waardoor je lekker overnieuw mag gaan compilen als je een van die niet-gecompilede features toch nodig hebt. (Absoluut niet ondenkbaar in bijvoorbeeld php.)

PHP is een slecht voorbeeld. Alle modules kun je los installeren. Overigens is dat een mooi voorbeeld van waar de RedHat en Windows distributies goed falen: je installeert daar standaard alle beschikbare modules. Onder FreeBSD gaat dat al veel beter: je kan en moet elke module afzonderlijk installeren, wat betekent dat je heel selectief kunt installeren én ze heel makkelijk toe kunt voegen zonder PHP opnieuw te installeren of compileren en de webserver maar down te halen.

Om nog even een ander argument aan te voeren: een andere feature die ik nog niet op Linux gezien heb is een equivalent van FreeBSD's portaudit, dat de op een systeem met geïnstalleerde packages automatisch vergelijkt met een lijst van bekende vulnerabilities die via internet bijgehouden wordt. Daarmee wordt het heel makkelijk om als systeembeheerder een mailtje te krijgen als een update nodig is (in plaats van je op een algemene mailinglist in te schrijven en zelf moeten bedenken welke advisories op jouw systemen van toepassing zijn).

[daft_dutch]

ik zweer bij debian.
stable op mijn server. en unstable op mijn desktop.

vooral de zeer uitgebreide package list vind ik geweldig.
16000 packages. heel veel tools die 90% nooit zal gebruiken maar als je bij die 10% zit zijn ze top.
je zou maar een andere distro hebben moet je eerst gaan zoeken op het internet wat ook niet makkelijk is. ik ben admin op een fendora servertje en soms iriteer ik me mateloos

sommige mensen zeggen dat debian wat traag is met nieuwe versies, maar dat komt doordat stable ook echt stable is.

[MrBarBarian]

Soultaker schreef op dinsdag 11 oktober 2005 @ 00:19:
Corrigeer me als het bij Debian anders zit, maar bij de meeste systemen gebaseerd op binary packages is de inhoud van een package vast: als je een package installeert heb je niets te kiezen. Daarom worden meestal alle nuttige dingen in een package gestopt: denk aan bijvoorbeeld zlib support in een webserver om deflate compression mogelijk te maken. Dat levert een dependency op zlib op en die móét je installeren om de package te kunnen installeren. Wordt er nu een bug gevonden in zlib, dan moet je dus je systeem updaten.

Als je ervan uit gaat dat er 2 soorten packages bestaan (rpm en apt) dan is dat zeker voor de helft niet het geval

Je kan immers ook SRPM's downen, dat is dus gewoon een source, waarin je zelf kan aangeven wat er mee gecompileerd moet worden. Op die manier haal je dus de voor jou onnodige depenencies eruit, en kan je bij een package managher blijven (met al haar voordelen)

Zwerver schreef op maandag 10 oktober 2005 @ 23:53:
Ik snap niet wat het verschil is tussen Gentoo, Debian, SuSE en RH? Bij Debian bijvoorbeeld krijg je (mits je even oplet tijdens de installatie en niet domweg van alles installeert) ook een minimaal systeem? Sterker nog, libphp moet je zelf bij installeren, anders zit het er niet eens op. Niks niet moeilijk doen met USE-flags, gewoon niet installeren

Daarbij weet ik dat je bij RH en SuSE ook heel minimaal kan installeren, dan up(2)date je daarna gewoon een aantal packages erbij Allemaal dus geen voordelen voor Gentoo

Yes, eindelijk iemand die het snapt

[Soultaker]

MrBarBarian schreef op dinsdag 11 oktober 2005 @ 09:44:
Je kan immers ook SRPM's downen, dat is dus gewoon een source, waarin je zelf kan aangeven wat er mee gecompileerd moet worden. Op die manier haal je dus de voor jou onnodige depenencies eruit, en kan je bij een package managher blijven (met al haar voordelen)

Klopt; dat is inderdaad vergelijkbaar met andere source gebaseerde systemen. Het was ook geen discussie tussen Debian en Gentoo, maar een vergelijking van de voordelen van op source versus van op binary gebaseerde packages.

Merk wel op dat Zwerver specifiek aangaf géén compiler toolchain of development library wilde hebben en packages níet zelf wilde compileren; dan kun je dus ook geen SRPMs installeren. Dan kun je dus ook niet die packages zelf stroomlijnen zoals met op source gebaseerde packages wel kan.

[ Voor 7% gewijzigd door Soultaker op 11-10-2005 14:26 ]

[MrBarBarian]

Soultaker schreef op dinsdag 11 oktober 2005 @ 14:26:
[...]

Klopt; dat is inderdaad vergelijkbaar met andere source gebaseerde systemen. Het was ook geen discussie tussen Debian en Gentoo, maar een vergelijking van de voordelen van op source versus van op binary gebaseerde packages.

Merk wel op dat Zwerver specifiek aangaf géén compiler toolchain of development library wilde hebben en packages níet zelf wilde compileren; dan kun je dus ook geen SRPMs installeren. Dan kun je dus ook niet die packages zelf stroomlijnen zoals met op source gebaseerde packages wel kan.

Ik ben het ermee eens dat je op een produktiesysteem geen developmenttools wil. Daarom is het mogelijk je srpm te compilen en testen op een test/acceptatie-omgeving, en volgens de rpm (het resultaat dus van de srpm) te installeren op je produktieserver.

[smokalot]

MrBarBarian schreef op dinsdag 11 oktober 2005 @ 14:43:
[...]


Ik ben het ermee eens dat je op een produktiesysteem geen developmenttools wil. Daarom is het mogelijk je srpm te compilen en testen op een test/acceptatie-omgeving, en volgens de rpm (het resultaat dus van de srpm) te installeren op je produktieserver.

maar als je vaker van plan bent je software zelf te compileren kun je datzelfde beter met gentoo doen.

[Zwerver]

Nee! Want dan heb je dus continu devvelshit op je productieserver. Dat wil je echt niet, tenzij het doel juist een develserver is. Een gehackte server MET devvelshit is zoveel kwetsbaarder dan een server zonder die troep. De kans dat je er achter komt OMDAT er devvelshit gedownload en geïnstalleerd moet worden is gewoon erg groot, en helemaal in een bedrijfsomgeving waar men het dataverkeer monitort.

[smokalot]

je kunt met gentoo ook prima alle develshit verwijderen, ik geef toe dat dat een stap is die bij RH/SuSE niet zou hoeven, maar je produktieserver hoeft niet te compileren als je daar een aparte bak voor hebt.

[MrBarBarian]

smokalot schreef op dinsdag 11 oktober 2005 @ 20:22:
je kunt met gentoo ook prima alle develshit verwijderen, ik geef toe dat dat een stap is die bij RH/SuSE niet zou hoeven, maar je produktieserver hoeft niet te compileren als je daar een aparte bak voor hebt.

Dus om een upgrade uit te voeren van package X op een produktieserver ga jij eerst:

- development tools installen (met waarschijnlijk al een eerste compile stap)
- het package daadwerkelijk installen (weer compilen)
- development tools weer verwijderen.

1. Een beheerder zal dus veeeeel langer bezig zijn met upgraden (dus een upgrade kost veel meer tijde/geld)
2. Er moet e.a. extra worden gecomplieerd (de development tools). Compilen kost redelijk wat cpu-kracht. En die cpu-kracht is tijdens het compilen dus niet beschikbaar voor het doel van de server. En dat is weer een service degredation. En dat is mooi simpel; service degredation is NOOIT acceptabel.

En dan hebben we uiteraard nog de risico's je er zijn bij het (redelijk intensief) werken op een produktiesysteem.. En probeer je eens voor eens voor te stellen, dat je dat (als beheerder) op alle produktie systemen moet doen.... in een enterprise omgeving.. oke. een kleintje: 50 servers

[ Voor 9% gewijzigd door MrBarBarian op 11-10-2005 20:52 ]

[smokalot]

MrBarBarian schreef op dinsdag 11 oktober 2005 @ 20:45:
[...]


Dus om een upgrade uit te voeren van package X op een produktieserver ga jij eerst:

- development tools installen (met waarschijnlijk al een eerste compile stap)
- het package daadwerkelijk installen (weer compilen)
- development tools weer verwijderen.

1. Een beheerder zal dus veeeeel langer bezig zijn met upgraden (dus een upgrade kost veel meer tijde/geld)
2. Er moet e.a. extra worden gecomplieerd (de development tools). Compilen kost redelijk wat cpu-kracht. En die cpu-kracht is tijdens het compilen dus niet beschikbaar voor het doel van de server. En dat is weer een service degredation. En dat is mooi simpel; service degredation is NOOIT acceptabel.

En dan hebben we uiteraard nog de risico's je er zijn bij het (redelijk intensief) werken op een produktiesysteem.. En probeer je eens voor eens voor te stellen, dat je dat (als beheerder) op alle produktie systemen moet doen.... in een enterprise omgeving.. oke. een kleintje: 50 servers

goed lezen, er werd gezegd dat zelf packages compileren ook kan met SRPMs, waarbij je dat compilen eventueel op een andere machine kan doen, met vergelijkbare setup. ik zeg dan dat je dan weer net zo goed gentoo kan gebruiken, waarbij je produktieserver geen devtools heeft staan, maar dat doe je dan op een andere machine. Juist als je 50 server hebt kun je mooi zelf je packages bakken.

Overigens wordt er in dit topic constant gepraat over bedrijfskritische servers, of servers in een zeer groot bedrijf, wat volgens mij hele andere eisen stelt aan een server dan het gemiddelde bedrijf, gewoon de mailserver, fileserver, router, enz.

[Zwerver]

smokalot schreef op dinsdag 11 oktober 2005 @ 22:09:
[...]

goed lezen, er werd gezegd dat zelf packages compileren ook kan met SRPMs, waarbij je dat compilen eventueel op een andere machine kan doen, met vergelijkbare setup. ik zeg dan dat je dan weer net zo goed gentoo kan gebruiken, waarbij je produktieserver geen devtools heeft staan, maar dat doe je dan op een andere machine. Juist als je 50 server hebt kun je mooi zelf je packages bakken.

Overigens wordt er in dit topic constant gepraat over bedrijfskritische servers, of servers in een zeer groot bedrijf, wat volgens mij hele andere eisen stelt aan een server dan het gemiddelde bedrijf, gewoon de mailserver, fileserver, router, enz.

Dus op een mailserver wil je wel devvel tools? Of ga je dat dan ook op een aparte bak compilen. Je blijft altijd met het compile probleem zitten, en dat wil je in principe niet. Overigens zijn onze RHEL bakken gestript van alle overbodige packages en onze apache+php installs zijn voorzien van die dingen die wij willen, zonder daarvoor RPMS te hoeven gebruiken.

[smokalot]

Zwerver schreef op dinsdag 11 oktober 2005 @ 23:12:
[...]


Dus op een mailserver wil je wel devvel tools? Of ga je dat dan ook op een aparte bak compilen. Je blijft altijd met het compile probleem zitten, en dat wil je in principe niet. Overigens zijn onze RHEL bakken gestript van alle overbodige packages en onze apache+php installs zijn voorzien van die dingen die wij willen, zonder daarvoor RPMS te hoeven gebruiken.

ik zeg 2 dingen, die los van elkaar staan.
1) Gentoo kan een goede keuze zijn op servers in sommige gevallen
2) ik vind dat er in dit topic niet alleen gepraat moet worden over de hele zware servers,bij de hele grote bedrijven, maar juist ook over standaard servers, de fileserver die een bedrijf van 30 man van bestanden voorziet bijvoorbeeld

Hoe heb je die RHEL voorzien van de dingen die jij wilt, zonder RPMs dan? je hebt het buiten je packagemanager om gedaan?

[Zwerver]

smokalot schreef op woensdag 12 oktober 2005 @ 11:43:
[...]

ik zeg 2 dingen, die los van elkaar staan.
1) Gentoo kan een goede keuze zijn op servers in sommige gevallen
2) ik vind dat er in dit topic niet alleen gepraat moet worden over de hele zware servers,bij de hele grote bedrijven, maar juist ook over standaard servers, de fileserver die een bedrijf van 30 man van bestanden voorziet bijvoorbeeld

Hoe heb je die RHEL voorzien van de dingen die jij wilt, zonder RPMs dan? je hebt het buiten je packagemanager om gedaan?

RPMS

Oftewel de source RPM's

[Martin Sturm]

Ik heb een beetje het idee dat sommige posters hier denken zoals de meeste (in mijn ogen: technisch weinig onderlegde) managers. Uiteraard zit bij de besluitvorming van dergelijke figuren relavante zaken, maar als technisch persoon (dat zijn de meeste die hier in NOS toch rondlopen lijkt me) ben je toch helemaal niet geïnteresseerd in de commerciele argumenten zoals certificering, support, etc. maar is toch juist de technische perfectheid je critirium? Als je mee gaat praten met de managers ben je gewoon overbodig in mijn ogen (om het even cru te zeggen).

Ik vind het onzin om te stellen dat allen Red Hat of Suse (niet Suze dus ) geschikt zijn, aangezien er talloze alternatieven zijn die ook geschikt zijn (waaronder ook OpenBSD/FreeBSD). Sommige lijken hier alleen de policy van het bedrijf waarvoor ze werken uit te dragen ipv zelf na te denken Als je geen Oracle draait op je server is het toch helemaal niet interessant of je OS certified is door Oracle? En het 'support' verhaal vind ik ook een beetje kansloos. Kijk, als je geen capabele systeembeheer afdeling hebt binnen je bedrijf, kan het handig zijn dat je de RH supportdesk kunt bellen bij problemen. Echter, als je een beetje systeembeheerders met kennis hebt, kun je makkelijk Ubuntu, Debian, OpenBSD, FreeBSD en zelfs Slackware op je servers draaien zonder dat dit onoverkomelijke problemen oplevert. Het lijkt wel of ik hier soms gewoon citaten uit die kansloze managertijdschriften aan het lezen ben

[Verwijderd]

Martin Sturm schreef op donderdag 13 oktober 2005 @ 12:08:
Ik heb een beetje het idee dat sommige posters hier denken zoals de meeste (in mijn ogen: technisch weinig onderlegde) managers. Uiteraard zit bij de besluitvorming van dergelijke figuren relavante zaken, maar als technisch persoon (dat zijn de meeste die hier in NOS toch rondlopen lijkt me) ben je toch helemaal niet geïnteresseerd in de commerciele argumenten zoals certificering, support, etc. maar is toch juist de technische perfectheid je critirium? Als je mee gaat praten met de managers ben je gewoon overbodig in mijn ogen (om het even cru te zeggen).

Helaas is het zo, dat de gemiddelde manager de uiteindelijk besluitvorming doet, op basis van aanbevelingen van de technische personen onder hem. Tevens is "technische perfectie" iets wat er minder toe doet op het moment dat er grote bedragen mee gemoeit zijn. Je applicatie kan nog zo perfect zijn, als het bedrijf (en je vendors) zich niet kunnen indekken tegen eventuele (legale, financiele) schade, dan komt de applicatie er niet. Als technisch persoon hoort dat ook een van je afwegingen te zijn imho. Als je dat niet doet, ben je (idd, ook errug cru ) eigenlijk heel fout bezig, omdat het hier helemaal niet om jouw portemonee gaat (in het algemeen), maar om de portemonee van je baas.

Ik vind het onzin om te stellen dat allen Red Hat of Suse (niet Suze dus ) geschikt zijn, aangezien er talloze alternatieven zijn die ook geschikt zijn (waaronder ook OpenBSD/FreeBSD).

Afhankelijk van de toepassing en beschikbare kennis is ieder platform te gebruiken voor server toepassingen. Hier draaien wij bijvoorbeeld RHEL3 en RHEL4 voor klant systemen (domino/websphere/db2/oracle/mq/rsa/maatwerk), vanwege het liability verhaal hierboven (rhel3 omdat rsa rhel4 nog niet gecertificeerd heeft). Om gelijk ook ff op de O/Fbsd opmerkingen in te gaan: Noem eens 1 van de bovenstaande toepassingen die supported (zie alinea erboven) zijn voor Open of FreeBSD. Dat is de reden dat je die platformen zo weinig tegenkomt voor bedrijfskritische toepassingen. Voor infrastructuur (dns/dhcp/ntp/routers/firewalling) wordt een mix van debian en openbsd systemen gebruikt. Dit is een gebied waar dit soort platformen schijnen.

Sommige lijken hier alleen de policy van het bedrijf waarvoor ze werken uit te dragen ipv zelf na te denken Als je geen Oracle draait op je server is het toch helemaal niet interessant of je OS certified is door Oracle? En het 'support' verhaal vind ik ook een beetje kansloos. Kijk, als je geen capabele systeembeheer afdeling hebt binnen je bedrijf, kan het handig zijn dat je de RH supportdesk kunt bellen bij problemen. Echter, als je een beetje systeembeheerders met kennis hebt, kun je makkelijk Ubuntu, Debian, OpenBSD, FreeBSD en zelfs Slackware op je servers draaien zonder dat dit onoverkomelijke problemen oplevert. Het lijkt wel of ik hier soms gewoon citaten uit die kansloze managertijdschriften aan het lezen ben

Over het algemeen liggen de competenties van de gemiddelde IT'er en hun afdelingen niet op het gebied van OSS OS's cq toepassingen, maar eerder in de hoeken MS en de bijbehorende toepassingen. Aangezien de technische perfectie van de gebruikte infrastructuur afhankelijk is van de laagste gedeelde noemer onder de admins, betekend dit vaak dat de techniek achterblijft tov gemak van beheer en geleverde support. De enige manier om hier echt wat aan te doen is om beter geschoold personeel in te huren, wat helaas ook niet altijd mogelijk is. Hierdoor is de realiteit dat je nog "als een manager moet denken", maar that's the way it is ....

[Zwerver]

Verwijderd schreef op donderdag 13 oktober 2005 @ 14:15:
[...]

Over het algemeen liggen de competenties van de gemiddelde IT'er en hun afdelingen niet op het gebied van OSS OS's cq toepassingen, maar eerder in de hoeken MS en de bijbehorende toepassingen. Aangezien de technische perfectie van de gebruikte infrastructuur afhankelijk is van de laagste gedeelde noemer onder de admins, betekend dit vaak dat de techniek achterblijft tov gemak van beheer en geleverde support. De enige manier om hier echt wat aan te doen is om beter geschoold personeel in te huren, wat helaas ook niet altijd mogelijk is. Hierdoor is de realiteit dat je nog "als een manager moet denken", maar that's the way it is ....

Hulde voor dit, en het overige wat er staat. Uiteraard pak ik in mijn thuisomgeving ook Debian, maar het is exact zo wat r3boot hier zegt, soms heb je geen andere keuze. En als jij straks in je werk tegen je manager gaat zeggen "support boeit niet" en "certificering boeit niet" dan lachen ze je recht in je gezicht uit. Support boeit nl wel en certificering voor de app's nog veel meer.

[smokalot]

maar ik heb weinig aan dit hele verhaal als ik bij een doodnormaal, niet-ICT bedrijf het systeembeheer moet doen. Dan willen mensen gewoon bestanden kunnen delen, mailtjes sturen, documenten kunnen lezen/schrijven, enz. Komt geen support bij kijken, geen enkele applicatie heeft het over certificering.

[zomertje]

Zwerver schreef op donderdag 13 oktober 2005 @ 15:58:
[...]

Hulde voor dit, en het overige wat er staat. Uiteraard pak ik in mijn thuisomgeving ook Debian, maar het is exact zo wat r3boot hier zegt, soms heb je geen andere keuze. En als jij straks in je werk tegen je manager gaat zeggen "support boeit niet" en "certificering boeit niet" dan lachen ze je recht in je gezicht uit. Support boeit nl wel en certificering voor de app's nog veel meer.

En je wil ook een leverancier kunnen aanspreken als ze een systeem leveren met een bug erin. Hoe kan je de bug omzeilen, wanneer gaan ze patchen enz. Niet alleen simpel de support desk bellen. Ook voor een training, een uitwisseling van ideeen met een echte specialist kan interressant zijn. Ik neem even onze dbs/programmeerspul leverancier Progress. Natuurlijk moeten we daar zelf mee overweg kunnen, maar ik zoek vaak genoeg op de progress support site naar de oplossingen voor een bepaald probleem. Daarnaast organiseren zij veel seminars endergelijke waar kennis wordt uitgewisseld. Bijvoorbeeld over de omgang met een directory met 20.000 kleine bestandjes erin, iets wat bij ons gewoon wel eens voorkomt. Bij veel anderen misschien nooit, en vind het dan maar eens op Google.

Ook voor AIX is het fijn als er support is, gewoon om even te spiegelen of je goed zit. Als het echt bedrijfskritisch is ga je niet voer 1 nacht ijs. En ik wil die server gewoon aan het werk kunnen zetten, t moet robuust zijn (1200 processen komt wel eens voor)

[Zwerver]

smokalot schreef op donderdag 13 oktober 2005 @ 18:55:
maar ik heb weinig aan dit hele verhaal als ik bij een doodnormaal, niet-ICT bedrijf het systeembeheer moet doen. Dan willen mensen gewoon bestanden kunnen delen, mailtjes sturen, documenten kunnen lezen/schrijven, enz. Komt geen support bij kijken, geen enkele applicatie heeft het over certificering.

Niet? Naar mijn mening hoor jij heel goed te bedenken wat er gebeurd als jij een probleem niet op kan lossen.... Waar stap je dan heen? Als de hardware stuk gaat, binnen 4 uur vervangen wordt maar jij je complete installatie overnieuw kan doen omdat bijv. de hdd en controllers net anders zijn? Dan ligt je bedrijf dus stil omdat jij je werk niet goed gedaan hebt. Bij een door de leverancier van je hardware geleverde dist kun je eisen dat ze dezelfde hardware leveren, waardoor je binnen de levertijd van de hardware weer kan draaien.
En als je dat soort contracten hebt (en dat heb je neem ik aan ook bij een fileserver/mailserver etc, je bedrijfsvoering hangt er immers vanaf) wat wordt er dan als dist geleverd?

[Jesse]

Het ligt er dus maar net aan hoe je allerhande dingen verstaat. Neem smokalot met zijn fileserver. Zoiets is natuurlijk een enorm ruim begrip, en daar komen hier ook de misverstanden van.

De ene heeft het over een fileserver bij het eigen bedrijfje van zijn oom, die als de data op het servertje niet beschikbaar is gewoon een uurtje wat anders gaat doen, de ander over een SAN-cluster voor een multinational waar bij 8 seconden downtime direkt 1500 man je gaat spammen met failure-reports en acuut honderdduizenden euro's overbodige kosten gemaakt word.

Ook al lijkt het verschil nu (bij dit voor de duidelijkheid overdreven voorbeeld) te zitten in het grootschaliger worden, ook dat is niet absoluut waar. Een groot bedrijf kan kiezen voor servers met dure garantie en gecertificeerde software e.d, je kan ook kiezen voor eigen voorzieningen en bekwaam personeel in-huis. (Denk aan Xs4all met o.a. FreeBSD en Squirrelmail. Zijn die mensen niet professioneel? Zijn het geen servers? Zetten zij geen top product neer? Dat kan dus ook, maar zo hoeft het niet.)

Ik wil dus niet zeggen dat het ene niet goed is, maar het andere is ook (absoluut!) niet per definitie fout. En nee, ik zou ook niet willen dat mijn bank haar internetbankier-systeem vanaf een gentoo linux machine met zelfbouw hardware oid draaid. (En ook het ziekenhuis de systemen van de hartbewaking niet.) Dat lijkt me heel duidelijk, en dat begrijpen we allemaal best.

offtopic:
Overigens wil ik wel aantekenen dat ik geen enkele professionele server-beheer ervaring heb.

Edit: Overigens geloof ik er niks van dat je bij RedHat je handje kan ophouden als je kosten hebt gemaakt door een falen in hun software. (En ook van de commerciele UNIX versies vraag ik me dat sterk af.)

[ Voor 27% gewijzigd door Jesse op 13-10-2005 22:21 ]

[Zwerver]

Jesse schreef op donderdag 13 oktober 2005 @ 22:13:
Edit: Overigens geloof ik er niks van dat je bij RedHat je handje kan ophouden als je kosten hebt gemaakt door een falen in hun software. (En ook van de commerciele UNIX versies vraag ik me dat sterk af.)

Misschien niet bij RH, maar wel bij HP als je een contract hebt waar dat instaat. En laat HP nou net RH leveren Daarmee maak je dus Debian ongeschikt, want je contract ongeldig.

[Jesse]

Zwerver schreef op donderdag 13 oktober 2005 @ 22:26:
[...]

Misschien niet bij RH, maar wel bij HP als je een contract hebt waar dat instaat. En laat HP nou net RH leveren Daarmee maak je dus Debian ongeschikt, want je contract ongeldig.

Uiteraard, als je voor een dergelijk contract kiest (maar dat doet volgens mij lang niet iedereen) is het kiezen voor een distro waarmee je je contract ongeldig maakt niet im frage.

Ik dacht btw dat HP wel degelijk ook Debian support op bepaalde hardware. Zie hier

[ Voor 29% gewijzigd door Jesse op 13-10-2005 22:38 ]

[Zwerver]

Jesse schreef op donderdag 13 oktober 2005 @ 22:29:
[...]

Uiteraard, als je voor een dergelijk contract kiest (maar dat doet volgens mij lang niet iedereen) is het kiezen voor een distro waarmee je je contract ongeldig maakt niet im frage.

Ik dacht btw dat HP wel degelijk ook Debian support op bepaalde hardware. Zie hier

Op schreeuwend dure hardware i.d.d. wel ja Maar ik heb Debian ook nergens als niet geschikt genoemd Wel heb ik aangegeven dat voor bedrijfskritische systemen:

- RHEL
- SuSE
- Commerciële Unices en OpenVMS

beter voldoen.

Voor fileservers, firewall's e.d. kan je best

- Debian
- *BSD

gebruiken, zolang de leverancier van de hardware het ook maar ondersteund. Anders dan zit je dus bij vervanging altijd te kloten, wat resulteert in een infrastructuur die plat ligt. En ook het MKB-kantoor van je oom/vader/whatever kost dat geld. Denk maar eens aan het adviesbureau die ineens niet bij de rapportages kan, of elk ander bedrijf dat in hoge mate geautomatiseerd is

[Jesse]

Zwerver schreef op donderdag 13 oktober 2005 @ 23:25:
[...]

Op schreeuwend dure hardware i.d.d. wel ja

Als je zulke bedrijfskritische processen draait zal je (lijkt mij) ook snel voor duurdere hardware kiezen (zoals HP Integrity). Ik heb geen idee van de prijzen van contracten waarbij bijvoorbeeld HP kosten als gevolg van downtime door hun spullen gaat vergoeden, maar iets zegt mij dat de Proliant servers daar enigszins bij uit de toon zullen vallen.

Zwerver schreef op donderdag 13 oktober 2005 @ 23:25:
Maar ik heb Debian ook nergens als niet geschikt genoemd

*knip*

Zwerver schreef op donderdag 13 oktober 2005 @ 22:26:
[...]
*knip*
Daarmee maak je dus Debian ongeschikt, want je contract ongeldig.

Dan heb ik bovenstaande verkeerd begrepen, het zal wel een ongelukkig voorbeeld zijn geweest.

Edit: wacht even, ik zie nu pas wat je schrijft: "daarmee maak je", maar helemaal kloppen doet et in elk geval niet in alle gevallen.

[ Voor 12% gewijzigd door Jesse op 14-10-2005 16:43 ]

[Verwijderd]

[Disc]Kan elke distributie als server-dist dienen....

Ja

[froggie]

Wij zijn een kleine leverancier van hardware, software en hand- en spandiensten in de hosting branche. Daarbij moet je denken aan levering en beheer van webclusters, het hosten van een maatwerk applicatie op een cluster, maar ook de levering (en eventueel beheer en support) van losse servers (web,file, mail etc) behoort tot de mogelijkheden.

Wij leveren op dit moment het overgrote deel van onze systemen uit met FreeBSD. Omdat WIJ de partij zijn die het beheer en/of de support moeten streven we altijd naar technische perfectie, zowel in onze hardware en onze software. Zolang je de kennis en expertise in huis hebt (of bereid bent voor die kennis en expertise te betalen) kun je ieder OS (uitzonderingen daargelaten uiteraard) inzetten op servers, zelfs MS Windows (wat, mits goed onderhouden door vakbekwaam personeel, icm bepaalde apps best een aardig server OS is).

Ik ben van mening dat je het huisje bij het schuurtje moet laten (of was het andersom? ) en voor iedere klus het juiste gereedschap moet kiezen. En beperk je dan niet alleen tot een keuze voor het OS, maar bekijk het hele plaatje. Je bekijkt eerst de functie van de betreffende machine, aan de hand daarvan kies je je applicatie(s) (deze stap gaat vaak in 1 keer), daarna kies je je OS en tenslotte kies je je hardware. En uiteraard is het mogelijk om hierin je eigen voorkeur door te laten schemeren, het moet tenslotte ook onderhouden worden.

[Verwijderd]

-never mind-

[ Voor 94% gewijzigd door Verwijderd op 14-10-2005 16:25 ]