Bootstrapper 4: Gestart vanaf het netwerk Bootstrapper 4: Gestart vanaf het netwerkHet opstarten van software vanaf een netwerk biedt vele voordelen. Het scheelt soms in de licentiekosten, maar het centraliseert ook het beheer van de software en de client PC's kunnen soms lichter worden uitgevoerd, bijvoorbeeld zonder harde schijf. Maar als het niet opstart zit je wel mooi.
| posted on Tue, 01 Jun 2004, 00:00 | weblog | rss | spin-off | comments |
Translate to English
Het booten vanaf een netwerk houdt in dat software en data niet lokaal staat, maar via het netwerk wordt benaderd. Als het operating systeem lokaal staat gebruik je doorgaans file sharing technieken, maar wanneer ook het operating systeem wordt ingeladen via het netwerk spreek je van netwerkbooten.
Het opstarten van een systeem vanaf het netwerk kan natuurlijk nooit helemaal zonder software op de lokale computer. Immers, er moet iets worden opgehaald van het netwerk, en het hoe en wat daarvan moet worden vastgelegd. Maar hoe eerder de controle overgaat naar het netwerk, hoe beter het onderhoud gecentraliseerd kan worden, dus het ideaal is geen lokale software, met alleen hele simpele standaardsoftware als semi-ideaal.
Er zijn daarom boot-omgevingen die in een EPROM-chip kunnen worden gebrand, en die dan in een netwerkkaart kunnen worden geprikt. Deze omgevingen zijn zo klein als mogelijk voor een netwerkboot. Ze doorlopen doorgaans de fasen DHCP, TFTP, de opstart van het OS en tenslotte het over het netwerk binnenhalen van bestanden en andere externe services.
Naast de optie van een ROM-chip is het ook mogelijk om een floppy te maken waarmee vanaf het netwerk geboot kan worden. Of een systeem kan met een bootloader zoals LILO of GRUB uit deel 1 van deze reeks worden uitgerust, en daarmee een netwerkboot-image inladen. Dat laatste vergt dan wel een harde schijf, maar voor een multi-boot systeem is dat toch wel gebruikelijk -- en het is een heel stuk zekerder dan een floppy-boot. Harddiskloos booten is dan ook gereserveerd voor typische (al dan niet grafische) terminals; in andere systemen kan de BIOS natuurlijk ook geïnstrueerd worden om de harde schijf uit te schakelen na langdurige inactiviteit.
Het boot-image dat via een van deze mechanismen ingeladen wordt dient vervolgens voor de genoemde DHCP en verdere fasen van het opstarten te zorgen. Of met RARP als alternatief voor DHCP (RARP broadcast het Mac-adres van een ethernetkaart en vraagt om het bijbehorende IP-nummer). Ook zie je soms nog BOOTP, een deels compatible voorganger van DHCP.
Het is mogelijk om in deze mechanismen parameters in te vullen die aangeven welke TFTP-server vervolgens moet worden benaderd, en welke image-file daarvandaan moet worden opgehaald. TFTP is een heel simpele FTP, typisch een protocol voor tijdens het booten dus. Want daarbij wilden we immers zo weinig mogelijk lokale complicaties.
Een boot-ROM prik je in de ethernetkaart waarvoor die bedoeld is; let daarbij op dat boot-ROMs niet zomaar overdraagbaar zijn tussen types netwerkkaart. Dat komt doordat de hardware op het laagste niveau wordt aangesproken, waar vrijwel elke kaart een specifieke behandeling vergt. Natuurlijk zijn er wel mogelijkheden dat om een ROM zo te maken dat hij automatische detectie doet op welke hardware hij draait.
De boot-ROMs zelf zijn doorgaans EPROMs en kennen de voor die chips gebruikelijke pinout (ofwel, betekenistoekenning aan de aansluitpennen) -- de 27xxx serie is het meest gebruikelijk. Bovendien is het vaak zo (maar niet altijd) dat straffeloos een wat groter type EPROM kan worden gebruikt dan de kaart verwacht. Daarbij kunnen alleen wel verwarrende problemen optreden, zoals het meermalen voorkomen van de boot-ROM in de adresruimte ten tijde van het booten. Als je dus kunt kiezen gebruik dan liever de geadviseerde EPROM-grootte.
Het formaat van de via TFTP op te halen file wordt bepaald door de verwachtingen van de boot-ROM. Dit samenspel kan aan een aantal standaarden voldoen; PXE is een standaardvorm, het is de door Intel gedefinieerde Preboot Execution Environment. Er zijn veel commerciële aanbieders van boot-ROMs voor netwerkkaarten, veel meer dan alleen de leverancier van de netwerkkaart. Zulke leveranciers zijn bijvoorbeeld te vinden op etherboot.org/clinks.html. Handig als je zelf geen EPROMs wilt hoeven programmeren.
De PXE-norm is een praktische standaard, maar daar kun je in een zelfgecontroleerde omgeving van afwijken. Want een probleem met de PXE-norm is dat de images die je ermee kunt downloaden en opstarten erg klein zijn (32 kB is het maximum) zodat je problemen krijgt als je probeert om bijvoorbeeld een Linux kernel te downloaden.
Er zijn dan ook initiatieven die PXE willen vervangen door iets zonder deze beperking; als je maar in staat bent om netwerkkaartjes van een corresponderende boot-ROM te voorzien dan zit je niet aan PXE vast. Op etherboot.net is zo'n initiatief te vinden, en op rom-o-matic.net zijn zelfs complete images van zulke ROMs te vinden. Het gaat hierbij om gratis open source software overigens, maar ook deze zijn natuurlijk te bestellen bij bedrijfjes die weten hoe ze met een EPROM-programmer om moeten springen.
Van rom-o-matic.net zijn ook de genoemde bootbare floppy-images en LILO-boot-images te downloaden, en dat is ideaal in een testfase. Het staat je toe een netwerk-boot te simuleren zonder al meteen de ROM in de netwerkkaart te hoeven prikken.
Overigens zal een netwerkboot vrijwel altijd een optie bieden om gewoon lokaal te booten, en is de netwerkboot gewoon de default die ingaat na een paar seconden. Mocht deze optie wat lijken voor thuisgebruikers die de bedrijfssoftware willen gebruiken, denk dan wel goed na over de veiligheid, want het opstarten van een computer met software van een publiek netwerk is niet erg veilig. Je moet dus wel haast via een VPN werken als je dat wilt. Booten via een etherLAN is helemaal uit den boze natuurlijk!
Het is tegenwoordig heel gebruikelijk om netwerkconfiguratie te doen via DHCP. Plug maar raak. Dat het protocol ook veel optionele uitbreidingen kent is niet iedereen even bekend.
Zoals het gebruikelijk is om behalve IP-nummer en network mask ook de lokale caching name servers mee te zenden naar een DHCP-client, zo is het ook mogelijk er bijvoorbeeld TFTP-opties in op te nemen. Met name RFC 2132 definieert hoe dit werkt; het komt er op neer dat een extensie wordt gezonden die bestaat uit een tag (66 voor de TFTP-server, 67 voor de bootfile op die server) gevolgd door de lengte van het veld en de afzonderlijke karakters van dat veld. Doordat de tag standaard is kan elke client hem uit de DHCP-respons opvissen als hij hem hebben wil.
Niet elke DHCP-server is in staat deze extensies uit te zenden. We testten netwerkboots bijvoorbeeld op een netwerk dat onder een Novell server draaide, en die bood die mogelijkheid niet. Nu is het niet veel moeite een tweede DHCP-server op te zetten, maar dan is het wel van belang om conflicten te voorkomen. Dat was in dit geval te voorkomen door onder Novell in te stellen dat het Mac-adres van de netwerkbootende DHCP-servers niet moesten worden bediend.
Als er problemen zijn op dit niveau dan kan een utility zoals tcpdump (tekstueel) of ethereal (grafisch) van groot nut zijn, omdat daarmee bijvoorbeeld te zien is of er meerdere antwoorden komen op een enkele DHCP-aanvraag. Ook zijn de fasen van het DHCP-protocol op die manier te volgen. Dit verloopt namelijk in twee fasen: Eerst doet de client een broadcast-verzoek om te achterhalen wat er mogelijk is op DHCP-gebied, dan komt er van alle bereidwillige DHCP-servers een aanbod, de client kiest er eentje en informeert de servers van die keuze. Pas dan is de lease compleet.
De genoemde software van etherboot.net en rom-o-matic.net is zo handig om een extra DHCP-optie te herkennen; het gaat hier om een zogenaamde 'vendor extension' die dus specifiek voor die software is gedefinieerd. Als er dus meerdere DHCP-servers zijn dan geniet de DHCP-server die zo'n extensie meestuurt de voorkeur; maar dat moet dan dus wel een server zijn die vendor-specifieke codes kan uitzenden. En als dat lukt dan lost dat het probleem op voor de netwerkbootfase, maar als in een latere fase het OS opstart zal wederom DHCP nodig zijn, en dan wordt een client gebruikt die deze extensie niet zomaar de voorkeur geeft; het volledig buitensluiten van Mac-adressen op de ongewenste DHCP-server(s) is in zo'n geval dus zo gek nog niet.
De meest flexibele DHCP-server die wij kennen is die van ISC, en die is gratis downloadbaar van isc.org; het betreft hier de software die hand-in-hand met de standaard is ontwikkeld.
TFTP is een tamelijk dom protocol, nog dommer dan gewoon FTP. En dat was al niet zo snugger.
Een soms vervelende eigenschap is dat er in het geheel geen passwordprotectie op zit. Voor downloads is dat begrijpelijk, voor uploads minder. Als een TFTP-server draait op een normaal OS dan is dat doorgaans te ondervangen met file permissies, maar een ADSL-modem dat TFTP diensten aanbiedt is bijvoorbeeld maar beperkt betrouwbaar.
Vervolgens is TFTP wat drammerig. Als een pakket niet binnenkomt dan zeurt hij gewoon door tot hij het heeft. Dat is vooral simpel, maar efficiënt of fouttolerant is het niet helemaal. Maar goed, het gaat ook maar om bootstrappen, dat doe je niet zo vaak. Ook dit soort dingen zijn met ethereal of tcpdump uitstekend te volgen, als de voortgangsindicator van de preboot-omgeving dat al niet doet.
Verder zijn er natuurlijk typische fouten zoals het niet kunnen vinden van benodigde bestandsnamen, permissies die de TFTP-server niet toelaten het bestand te lezen en te grote images voor de bootomgeving. Al deze problemen zijn snel genoeg gevonden en opgelost, vooral omdat ze zich glashard en herhaalbaar zullen aandienen.
Wanneer images te groot zijn voor (doorgaans) een PXE-omgeving, dan is overwegen van een etherboot-omgeving nuttig. Wanneer al is geinvesteerd in een PXE-infrastructuur of wanneer gebruik wordt gemaakt van onboard LAN met ingebouwde PXE-support dan bestaat overigens ook een uitweg die een etherboot-omgeving inleest in een PXE-omgeving, waarna dan weer doorgestart kan worden. Als je schaatsen te groot zijn dan trek je gewoon twee paar sokken aan, met laarzen werkt dat dus netzo.
Zoals gezegd is het niet vanzelfsprekend dat een OS in staat is het netwerk goed te booten als een pre-boot omgeving zojuist het OS heeft binnengehaald. De oorzaak daarvan is meestal dat de gebruikte clients, en dan meestal die voor DHCP, verschillen in de twee stadia van het booten. Dit hoeft geen groot probleem te zijn, want het is best mogelijk om het OS een ander IP-nummer te geven dan de pre-boot omgeving. Vaak zal dat echter niet wenselijk zijn.
Verder moet het OS natuurlijk opgezet worden om zo veel mogelijk netwerk-resources binnen te halen, zoals bijvoorbeeld home directories en configuratie. De eerste zorgt voor mobiele werkplekken, de tweede voor centraal beheer van de terminals. Ook logfiles wil je doorgaans centraal verzamelen.
Het is met Linux bijvoorbeeld ook mogelijk om het root filesysteem al vanaf het netwerk binnen te halen, namelijk met NFS. Zelfs de swap kan over het netwerk worden gebruikt. Dat alles vergt handmatig tunen en (zeker voor swap) aandacht voor de veiligheidsaspecten. Het lokale netwerk moet absoluut vertrouwd worden als je er zulke dingen over wilt ophalen!
Gegeven de mogelijkheid om van een netwerk te booten, desnoods zonder tussenkomst van een schijf, wordt het wel erg aantrekkelijk om terminals op te zetten. Daarvoor zijn tegenwoordig aardig wat interessante protocollen in omloop.
Een nuttig protocol is RDP, het Remote Desktop Protocol waarmee windows terminal server werkt; voor Windows is hier uiteraard een implementatie van, maar ook op Linux en Mac OS X is te werken met het bescheiden rdesktop pakket van rdesktop.org. Deze gratis open source software draait bovenop een X-Windows omgeving. Cytrix is een broertje van RDP en wordt ook ondersteund door rdesktop.
Voor eenvoudiger toepassingen (met name het delen van desktops) is er natuurlijk VNC, dat lekker algemeen is omdat het op bitmapbasis werkt. Tussen Unix-systemen kun je weer veel beter X-Windows gebruiken, omdat dit inhoudelijke windowing-informatie uitwisselt, maar het is daarmee ook specifiek voorbehouden aan de communicatie tussen een X-client en een X-server. Die is op elke desktop te draaien, maar niet altijd zonder extra software.
Verder zijn er nog wat minder alledaagse mogelijkheden zoals een SSH-terminal; dit is een tekstterminal die inlogt op een remote systeem, in tekstmodus. Soms een nuttige toepassing van een oude 386, maar dan puur voor de doeleinden van systeembeheer en dus niet snel de inspanning waard omdat het niet opschaalt naar grote aantallen systemen.
Er zijn vele thin-client oplossingen beschikbaar, vaak gebaseerd op bovenstaande protocollen en vaak draaiend onder Linux. Dat kan levert dus heel interessante mogelijkheden voor kostencalculatie op, met client-licenties als inzet. Wie zulke software wil proberen kan op freshmeat.net of sourceforge.net terecht met zoektermen als "thin client". Een leuk voorbeeldproject is thinstation.org, waarmee RDP, VNC en X-Windows alle te gebruiken zijn, en waarin plugins uit het gerelateerde NetStation project bruikbaar zijn.
Het booten vanaf een netwerk is niet altijd even simpel om op te zetten. De diverse lagen van het opstartproces kunnen allemaal de mist in lopen. Gelukkig doen ze dat doorgaans wel keihard en reproduceerbaar. Goede netwerkanalysetools helpen vervolgens goed, maar wie het helemaal zonder kennis van de standaarden moet stellen zal er dan een zware dobber aan krijgen.
Deze reeks is gedurende 2004 verschenen in NetOpus. De reeks staat als geheel onder http://rick.vanrein.org/blog/netopus/bootstrapper
Translate to English