yoel caspersen blog bloghoved

Weekendprojekt - en DHCP-server

Når man som IT-iværksætter starter en virksomhed, er det oftest med udgangspunkt i at lave det, som man selv synes er sjovt.

I mit tilfælde er det high-performance softwareudvikling, jeg finder mest interessant, mens andre finder glæde i systemadministration, virtualisering eller noget helt fjerde.

Fælles for alle IT-iværksættere er, at de gradvist mister muligheden for at arbejde med det, de synes er sjovt, når deres startup pludselig bliver ramt af succes.

I stedet for at sidde oppe hele natten og kode, er det pludselig momsregnskaber, ansættelseskontrakter, leverandøraftaler og andre ledelsesopgaver, der holder en vågen.

Ledelse kan være sjovt, især når det går godt, men de administrative ting fordrer en helt anden personlighedstype end den, man typisk finder hos en iværksætter.

Derfor er det vigtigt, at man af og til tager sig tid til at rode med det, der gjorde, at man gik i gang i første omgang, så man bevarer gnisten.

Akut udfordring: DHCP-server søges

I forbindelse med vores omlægning til eBSA løb vi ind i en udfordring: Vi skulle bruge en DHCP-server, der kunne opfylde følgende krav:

  • MySQL-backend
  • Support for DHCP option 82 og 128
  • IPv4-support
  • IPv6-support
  • Support for IPv6 delegated prefix

Når en DSL-kunde kobles op til en DSLAM, modtager vi trafikken på et VLAN via en QinQ-trunk fra TDC. Det betyder, at trafikken er tagget med 2 VLAN tags - et inner VLAN (customer VLAN) og et outer VLAN (provider VLAN).

På den måde kan vi i teorien forbinde ca. 16 mio. kunder til vores netværk via en enkelt QinQ-trunk. Det rækker til vores behov i første omgang.

I vores ende forbliver kunderne isoleret på layer 2, og switchen forwarder DHCP-forespørgsler fra kunderne til vores DHCP-server. De pakker, vores DHCP-server modtager, indeholder DHCP option 82, der bl.a. indeholder en tekststreng i stil med denne:

eth 0/0/4:222.2 0/0/0/0/0/0

Den vigtige del af strengen er 222.2 - dvs. provider VLAN 222 og customer VLAN 2. eth 0/0/4 er porten på switchen, hvor trafikken er modtaget, og der er ingen garanti for, at den ikke skifter på et tidspunkt.

Option 82 er vigtig, fordi vi skal kunne styre hvilke kunder, der får hvilke IP-adresser.

På jagt efter en DHCP-server - her er den første, vi støder ind i, den gode gamle ISC DHCP-server.

Den håndterer option 82, men der er ingen MySQL-support - og jeg kan ikke umiddelbart gennemskue, om den understøtter en partial option 82 - dvs. om vi kan få den til kun at kigge på den del, der indeholder 222.2.

Selvfølgelig kan vi hardcode resten af option 82-strengen i config-filen, men det er et hack, og hvis portnavnet på switchen skifter, skal vi rette konfigurationen øjeblikkeligt.

MySQL-support er vigtigt, da det ikke er godt at skulle reloade DHCP-serveren, hver gang en kunde skal have frigivet en IP-adresse.

Det ser ud som om, ISC DHCP-serverens afløser hedder Kea - men Kea understøtter ikke support for option 82 før om et par måneder jf. deres roadmap, og det er nu, vi skal bruge den.

Jeg besluttede derfor, at kodningen af en DHCP-server var et glimrende rekreativt weekendprojekt.

DHCP-protokollen - et levn fra 90'erne

Det første, jeg måtte undersøge, var, hvordan DHCP-protokollen egentlig ser ud. Den er ligesom alt andet netværksrelateret opfundet tilbage i 90'erne, og den er delvist bagudkompatibel med BOOTP-protokollen.

En DHCP-forespørgsel følger et fast mønster:

  • DHCP discover (Klienten: Giv mig en adresse... please!)
  • DHCP offer (Serveren: Brug x.y.z!)
  • DHCP request (Klienten: Må jeg bruge x.y.z?)
  • DHCP acknowledgement (Serveren: Jeps.)

DHCP-serveren har nu uddelt en såkaldt lease. Den udløber på et tidspunkt - og inden da skal klienten helst have fornyet den. Det foregår således:

  • DHCP request (Klienten: Må jeg stadigvæk bruge x.y.z?)
  • DHCP acknowledgement (Serveren: Jeps.)

Hvis klienten opfører sig pænt, vil den, når den lukker ned, sende en sidste hilsen:

  • DHCP release (Klienten: Jeg skal ikke bruge x.y.z længere)

Serveren svarer ikke, da der ikke længere er nogen, der lytter, men den fjerner x.y.z fra lease-databasen.

Hvis klienten spørger efter en adresse, der allerede er i brug af en anden klient, skal serveren helst svare med en DHCP NAK (not acknowledged).

Det er jo rimelig simpelt - så hvordan skal vi strikke softwaren sammen?

At tråde eller ej...

Allerførst har jeg besluttet, at den første udgave kun understøtter IPv4. Normalt, når jeg koder en dual stack netværksserver, opretter jeg en IPv6 socket med dual stack support. Så modtager jeg samtlige forespørgsler på denne socket og kan bagefter sortere dem efter, om der er tale om IPv4 eller IPv6.

Det giver bare ingen mening på en DHCP-server - for DHCPv6 (IPv6-udgaven af DHCP) kører på en helt anden port. UDP port 67 (server) og 68 (klient) er kun til IPv4.

Næste spørgsmål er, om serveren skal være single threaded eller multi-threaded. En multi-threaded server er næsten altid det rigtige valg til en netværksserver, men jeg har vurderet, at det er overkill i første omgang.

Det, der skal ske, når vi modtager en DHCP-forespørgsel, er, at serveren skal lave et database-opslag og sende et svar til klienten.

Selve database-opslaget bør ikke tage lang tid, og med en lease time på 1 time vil antallet af opslag pr. sekund være antallet af kunder / 1800.

Hvis vi opnår 100.000 kunder, er det lidt over 50 opslag i sekundet, så det klarer vi nok med en enkelt tråd.

Bursts er heller ikke et problem, da DHCP-forespørgsler består af små UDP-pakker, som fint kan ligge i operativsystemets buffer.

Når vi nu modtager en DHCP-pakke på vores UDP-socket, skal den parses, og et svar skal formuleres. Pga. arven fra BOOTP ligger mange af de spændende ting som DHCP options, der placeres i den del af BOOTP-pakken, der i gamle dage var reserveret til proprietær information - de såkaldte Vendor Information Fields.

Hver option har en kode, en længde og en værdi. Den sidste option med koden 255 markerer, at DHCP-pakken er afsluttet.

Det viste sig under vores tests, at visse klienter indeholder slamkode, der ikke overholder standarden - det gælder fx en router fra D-Link, der ikke kunne håndtere padding bytes på en DHCP-pakke.

Det er derfor en god ide at sikre sig, at pakkerne kun indeholder lige præcis det, de skal, og ikke en byte mere.

Kan det gøres nemmere?

Havde jeg haft tid til at sætte mig ind i Python, er jeg sikker på, jeg havde fundet en magisk one-liner, der gør 90 % af arbejdet med at skrive en customized DHCP-server.

Min udfordring er, at der kun er 24 timer i døgnet, og at jeg foreløbig har opbygget et nogenlunde kendskab til Visual Basic (lang tid siden, gør det aldrig igen), Delphi, Java, PHP og C/C++. Ud af disse værktøjer ligger C ligefor, og der er rigtig meget referencekode at kigge på.

Næste skridt er, at jeg skal tilføje IPv6-support og en form for redundans. I dag har vi to servere, der begge modtager de samme DHCP-forespørgsler, og tricket er, at kun en enkelt af vores DHCP-servere skal svare. Det kræver en eller anden form for heartbeat-mekanisme, der sikrer at begge servere ved, hvem der skal være master og slave.

Ovenstående er et af den slags hyggelige weekendprojekter, der gør det sjovt at være softwareudvikler.

Lad os høre, hvilket weekendprojekt du, kære læser, roder med. For lad os indrømme det - som softwareudvikler holder du jo aldrig helt fri, og er de sjoveste projekter ikke dem, du sidder og koder i din fritid?

Kommentarer (28)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Baldur Norddahl

Jeg nåede også frem til at skrive min egen DHCP server (i Scala+Akka). Min udgave håndterer både DHCPv4 og DHCPv6. De to har meget lidt til fælles ud over det basalle koncept.

Med hensyn til redundans, så er det faktisk meningen at begge servere svarer. Klienten vælger så en af serverne og broadcaster DHCP request tilbage. Heri angiver klient server id. Den server der ikke blev valgt ser at det ikke var dens tilbud der blev taget imod og serveren kan derfor slette leasen igen.

Hvis man vil have indflydelse på hvilken server der er den primære eller undgå for meget arbejde med leases der aflyses igen efter få millisekunder, så kan man have den sekundære server til at vente lidt med at svare. Den kan lige vente et par sekunder og så kun sende et svar hvis der ikke i mellemtiden er set en dhcp request pakke.

  • 3
  • 0
#2 Yoel Caspersen Blogger
  • 1
  • 0
#3 Baldur Norddahl

Har du oplevet nogen problemer med klienter, der ikke kan håndtere to svar på den samme DHCP discover?

Nej men nu står metoden altså også beskrevet på side 1 i DHCP RFC sådan cirka :-). Med andre ord, det SKAL man håndtere som klient. Det er en central del af protokollens funktion at klienterne broadcast REQUEST og det er for at den sekundære DHCP server skal kunne lytte med og se at den ikke blev valgt. Hvis det ikke var for det krav, så kunne de bare sende REQUEST som unicast i stedet - hvilket de også skal hvis der er tale om en RENEW.

Hvordan kan det være, du valgte Scala + Akka - er det personlig præference, eller har det en særlig force når det kommer til netværksprogrammering?

Begge dele. Akka er inspireret af Erlang og er meget velegnet til den her type transactions styret netværksprogrammering. Den er vel nærmest opfundet til formålet :-).

Men jeg overvejer at skrive den om i Rust for at gøre den uafhængig af Java (JVM), få mindre hukommelsesforbrug og gøre den mere "system tool" agtig. Og for at lære Rust. Ideen er at finpudse den så den kan bruges af andre som alternativ til ISC-DHCP (de trænger i den grad til lidt konkurrence). Det er dog ren interessetid da Scala/Akka versionen virker fint til vores virksomhed og nemt vil kunne skalere til millioner af brugere.

  • 2
  • 0
#4 Baldur Norddahl

De klient defekter jeg lige kan huske:

Nogle klienter kan ikke håndtere meget korte lease tider. Hvis du sætter lease tid til 1 minut, så er der en pæn procentdel der får problemer. De bruger tilsyneladende noget crontab lignende til at holde styr på det, dvs. med en præcision på 1 minut. Hvilket medfører at de ikke når at lave renew før at leasen er udløbet, hvorefter klienten fjerner opsætningen og starter forfra. Kunden oplever at nettet forsvinder nogle sekunder hvert minut.

Nogle klienter holder slet ikke styr på leases. De kører simpelthen en DHCP DISCOVER process en gang i minuttet. Sandsynligvis er det et script de kører fra crontab. Dimsen sender discover og request og exiter herefter.

Nogle klienter renewer aldrig. Ja jeg ser på dig Ubuntu. Deres install CD laver en discover+request når brugeren kommer til at konfigurere netværket under installationen, men de kører ikke nogen aktiv dhcp klient process i baggrunden, så ip adressen er effektivt statisk konfigureret i resten af installationsprocessen.

En del klienter følger ikke den officielle procedure når serveren ikke svarer. De skal sende RENEW når halvdelen af lease tiden er gået. Hvis der ikke kommer svar, så sender man RENEW igen med progressivt kortere intervaller. Når der kun er 1/4 af lease tiden tilbage så skifter man til at broadcaste RENEW i stedet for at sende unicast. Dermed kan en backup dhcp server modtage en broadcast RENEW som egentlig er for en lease fra den anden server. Hvis man så svarer på den (måske du har lavet en synk mekanisme eller der er tale om en statisk allokeret IP adresse) så er der en del klienter der ikke fatter at opdatere server ID. De vil med andre ord blive ved med at forsøge med unicast til den oprindelige døde server næste gang.

Da jeg på et tidspunkt havde brug for at ændre ip adresse på dhcp serveren og jeg blev træt af at mange klienter blev ved med at forsøge til den gamle adresse, så har jeg implementeret min server så at den ignorerer alle renews med forkert server id. Også selvom den egentlig godt kunne svare. Det tvinger klienterne til at lave et reelt skift startende med DISCOVER når lease udløber.

Der er også nogle ting med DHCP options. Der er f.eks. en option der styrer hvornår klienterne skal sende RENEW. Jeg har endnu ikke mødt en klient der faktisk honorerer denne option, selvom de måske hævder at have support. Til gengæld kan de fleste klienter finde ud af tage imod ekstra routes (også en option).

Ingen klient har problemer med at vi altid sender alle vores options. Klienterne angiver hvilke options de gerne vil modtage. Dette ignorerer jeg og sender konsekvent altid alt hvad jeg har. Det giver ikke problemer.

Jeg har på fornemmelsen at klienterne generelt er skrevet så at de virker med ISC-DHCP og det er referencen. Så hvis ISC-DHCP gør noget, så er det ok. Hvis du bevæger dig ud i noget som ISC-DHCP ikke gør, men som er lovligt ifølge RFC'en, så er du på dybt vand.

  • 4
  • 0
#6 Yoel Caspersen Blogger

Hvorfor ikke ? bruge noget der er lavet i forvejen ?

Kea blev dømt ude pga. manglende option 82-understøttelse - ellers virkede Kea som det mest interessante bud.

Derudover er det også udfordringen med partial option 82 - de steder, hvor jeg er stødt på konfigurationseksempler på option 82, skal man angive hele strengen, og det er dybest set kun den del af strengen, der angiver outer og inner VLAN, der er garanteret statisk.

staticdhcpd ser interessant ud, men den er skrevet i Python - og selv om jeg ville ønske, jeg havde brugt tid på at sætte mig ind i Python, er jeg ikke nået dertil endnu ;-)

  • 1
  • 0
#8 Baldur Norddahl

Jeg forstår hellere ikke hvordan ISC-DHCP kan leve videre med væsentlige defekter som er show stoppere. Men den har flere:

1) I vores første iteration af nettet brugte vi et vlan per kunde kombineret med en Linux router. Kunderne var på et delt /24 IPv4 subnet. Linux serveren har proxy arp så at kunderne kan kommunikere med hinanden. Det betyder også at Linux serveren ikke har en IP adresse på vlan interfacene. Ja det er en game over situation for ISC-DHCP, den har absolut ingen support for at lytte på et interface uden IP-adresse.

2) ISC-DHCP gider ikke lave en leases fil for statisk allokeret IP adresser. Alle vores kunder har statisk allokeret IP adresser. ISC-DHCP vedligeholder derfor ikke leases overhovedet i vores net. Det er der en række klienter der ikke tager så pænt.

3) ISC-DHCP har ikke support for at uddele statisk allokeret IPv6 adresser baseret på Interface-ID som indsat af et DHCPv6 relay. Også en 100% show stopper da vi er skiftet til et net der afhænger af DHCP relays.

ISC-DHCP er ikke noget særligt sjovt kode, hvorfor der ikke er mange der gider arbejde med det. Hellere ikke mig. De har også ry og rygte for ikke at tage imod patches, så andre vil alligevel ikke få gavn af det. Jeg fandt det mere givtigt at lave min egen fra bunden, hvor jeg har fuld kontrol med hvordan den fungerer.

KEA er ikke nærheden af at være produktionsklar og har endnu flere mangler.

  • 1
  • 0
#9 Ivo Santos

Det er da sejt at du kaster dig ud i en dhcp server projekt!!..

Nu har jeg aldrig prøvet at designe en dhcp server eller dhcp klient, men jeg har da prøvet at designe et netværk med 2 dhcp servere. og det virker uden problemer, og det burde det jo, også når både server og klient er designet af Microsoft.

I øvrigt, mit test setup: Net: 192.168.95.0/24 dhcp1: 192.168.95.32 - 192.168.95.95 (64 hosts) dhcp2: 192.168.95.96 - 192.168.95.159 (64 hosts)

Jeg tænkte at når nu alle informationerne ligger i en sql database, så burde det da ellers være muligt at designe det som et cluster system. Personligt har jeg aldrig prøvet at designe et cluster system så der mangler jeg en del viden.

Hvordan de forskellige producenter håndtere mere en en dhcp server aner ikke, det er windows har jeg størst erfaring med, og ikke så meget de andre producenter.

Hvad er det vildeste jeg har prøvet?.. Et C modul til allokering af dynamisk hukommelse baseret på Windows handles. Der findes ganske vist en masse løsninger, c++ templates f.eks. havde sikkert været en bedre løsning, for det jeg ville var egentlig at lave et simpelt cd-katalog system, og når man har 3 moduler som egentig lave det samme, så ville et c++ templates havde været den bedste løsning, men jeg ville ikke bruge en database, og nu havde jeg altså besluttet mig for at kode det hele i C, og jeg tænkte hvordan holder jeg styr på de forskellige dynamiske arrays?.. Løsningen var egentlig lige for en windows handle baseret modul til allokering af al hukommelse.

Jeg har gået og tænkt på om jeg ikke skulle overføre det hele til git, således at andre også kan få glæde at det pågældende C modul.

  • 1
  • 0
#10 Yoel Caspersen Blogger

Var det så ikke mere interessant at udvikle den del til Kea DHCP serveren, sådan at andre også kunne drage nytte af det ?

Jo, men det er et større arbejde da jeg ville skulle sætte mig ind i Kea. Desuden var det lige på trapperne ifølge deres roadmap, så jeg ville sandsynligvis opfinde en funktion som andre var i fuld gang med at udvikle også.

Ved at udvikle serveren selv kunne jeg også skræddersy den til vores behov.

  • 1
  • 0
#12 Yoel Caspersen Blogger

Jeg tænkte at når nu alle informationerne ligger i en sql database, så burde det da ellers være muligt at designe det som et cluster system. Personligt har jeg aldrig prøvet at designe et cluster system så der mangler jeg en del viden.

Jeg overvejede at lave noget lignende, men jeg kom til det resultat, at det faktisk var smart at droppe konceptet omkring leases - en klient får altid den IP-adresse, vi har reserveret til hans forbindelse, uanset om en anden klient på samme forbindelse har fået den samme adresse blot to minutter tidligere..

Jeps, det er grimt, og det er imod en stor del af ideen med DHCP - men det sparer os for en masse support-opkald, når en kunde kan teste med sin PC og umiddelbart efter sætte en router på forbindelsen og stadig få den rigtige IP-adresse.

Hvis kunden sætter en switch på i stedet for en router, vil det sandsynligvis resultere i en IP-konflikt, men alternativet er ikke bedre - hvis han sætter en switch på, og DHCP-serveren vitterligt kun uddeler IP-adressen til en host ad gangen, vil der kun være en enkelt enhed ad gangen, der kan komme på nettet, og dermed er resultatet det samme - vi uddeler nemlig kun 1 IP-adresse pr. kunde.

Løsningen var egentlig lige for en windows handle baseret modul til allokering af al hukommelse.

Det lyder som en relativt hardcore ting at lave ;-)

Et af de sjovere weekendprojekter, jeg har arbejdet på, var da jeg skulle introducere en kammerat for PHP tilbage i de glade 0'ere. Han havde en samling spændende piratfilm på sin Synology-NAS, der samtidig indeholdt en lille webserver med support for PHP og (vigtigt!) php-gd, som er et library, der tillader PHP-udviklere at lave cool grafik-relaterede ting.

Projektet gik ud på, at vi skulle lave et lille web-baseret mediecenter, og til sådan et mediecenter hører naturligvis en liste over film med tilhørende posters. Da det samtidig skulle se lidt lækkert ud, skulle baggrundsfarven være sort, mens vi skulle få det til at se ud som om film-plakaterne var DVD-covers, der stod på en glossy overflade.

Hvordan laver man en glossy spejl-effekt på et billede af en genstand, så det ser ud som om den står på en blank overflade? Well, i dag kan man sikkert lave nogle tricks med CSS, men dengang skulle der lidt mere til.

Vi forhøjede billedets canvas med 50 %, så den nederste trediedel af billedet var tomt. Så flippede vi den midterste trediedel af billedet over x-aksen og anbragte den i den nederste trediedel. Herefter lagde vi et sort layer oven på den nederste trediedel af billedet, hvor opacity startede ved 0 og gradvist blev inkrementeret så den var 100 i bunden af billedet.

Resultatet var et nyt billede, som lignede et DVD-cover, der stod på en sort glasplade - alt sammen lavet i PHP. De originale poster-billeder screen-scrapede vi i øvrigt fra IMDB.

Senere fandt jeg ud af, at nogen havde renderet en 3D-scene fra Wolfenstein i PHP - det slog alligevel vores projekt med adskillige længder ;-)

  • 1
  • 0
#15 Yoel Caspersen Blogger

Jeg har implementeret en server med ovenstående, der understøtter både ip4 og ip6 (ip6 mangler at blive implementeret). Du kan få koden at bygge videre på, hvis du er interesseret?

Jeg takker for tilbuddet, og du må gerne sende mig koden på e-mail dev@kviknet.dk. Jeg kommer dog nok primært til at bruge den som inspiration, da Perl ikke er en af mine stærke sider.

  • 0
  • 0
#18 Yoel Caspersen Blogger

Perl er vist vidt og bredt anerkendt som værende et af de få write-once, understand-never-programmeringssprog ;-)

Jeg har altid forbundet det med eder og forbandelser på skriftform, nok mest pga. den gavmilde brug af specialtegn.

Men for at være helt fair: Jeg synes faktisk at Michaels kode ser velorganiseret, nydelig og nemt tilgængelig ud. Jeg kan ikke skrive Perl fra bunden, men jeg forstår det. Lidt ligesom hollandsk ;-)

  • 2
  • 0
#19 Lars Bjerregaard

Du skriver at single-threaded sikkert er fint, hvilet det sikkert også er til dagligt. Men når nu nettet har været nede, og kommer op igen, og alle dine 100.000 kunder lige skal have en IP adresse i en fluks, kan det godt være du får et lille thundering herd problem. Men det er du sikkert klar over allerede... Bortset fra det, ville jeg mene at Go (golang) ville være et ideelt moderne sprog til opgaven.

  • 2
  • 0
#20 Ivo Santos

Det lyder som en relativt hardcore ting at lave ;-)

Jeg syntes egentlig ikke at det var slemt at lave det pågældende modul, det og ganske vist 3 eller 4 forsøg før jeg var tilfreds med resultatet.

Det var først på et senere tidspunkt jeg fandt ud af apache havde designet deres egen, som mig bekendt kan bruges sammen med andre projekter, men nogen gange så bliver gå en del open source projekter og bliver alt for store, og så kan det nogen gange være en god ide at starte forfra.

Det lyder da ellers ret cool med det er web projekt du havde gang i.

  • 0
  • 0
#21 Yoel Caspersen Blogger

Du skriver at single-threaded sikkert er fint, hvilet det sikkert også er til dagligt. Men når nu nettet har været nede, og kommer op igen, og alle dine 100.000 kunder lige skal have en IP adresse i en fluks, kan det godt være du får et lille thundering herd problem. Men det er du sikkert klar over allerede...

En meget valid pointe som jeg er opmærksom på (vi driver nogle systemer med > 100.000 brugere, og når noget går galt, og alle reconnecter samtidig, kan det i den grad mærkes).

Men når vi opnår 100.000 brugere på vores DSL-netværk, har vi forlængst trådet DHCP-serveren også.

  • 1
  • 0
#23 Yoel Caspersen Blogger

Som iværksætter har jeg brugt arbejds-delen af weekenden på regnskab og andre nederdrægtigheder. DHCP-serveren blev kodet i en weekend for en måneds tid siden og er i drift i dag - dvs. på IPv4. Det eneste større problem, vi løb ind i, var D-Link-routere, der ikke ville acceptere padding bytes, men det er løst ved at udelade disse.

IPv6-udgaven kommer om en weekend eller to ;-)

  • 2
  • 0
#24 Jn Madsen

Af ren nysgerrighed,- hvorfor har du ikke benyttet en "hyldevare" som f.eks. Pfsense? Såvidt jeg har hørt, skulle Pfsense være yderst velfungerende,- jeg har dog ikke personlig erfaring. Når man har travlt og mangler timer i døgnet, så skal man vælge sine kampe med omhu :-) Ellers står man pludseligt med 100 halvfærdige projekter.

  • 1
  • 0
#25 Yoel Caspersen Blogger

Af ren nysgerrighed,- hvorfor har du ikke benyttet en "hyldevare" som f.eks. Pfsense?

Af den simple grund at jeg ikke har kunnet finde en hyldevare med følgende specs:

  • MySQL-support
  • Support for option 128
  • Support for partial option 82

Kan PFSense opfylde samtlige disse specs? Kan man få den til at ignorere leases, der allerede er uddelt, og uddele dem igen?

Når man har travlt og mangler timer i døgnet, så skal man vælge sine kampe med omhu :-)

Det har du fuldstændig ret i. Mine endnu små børn vokser med en overraskende fart, og jeg har til min gru opdaget, at jeg er begyndt at få grå hår. Men jeg har hørt, det er meget almindeligt, når man er iværksætter ;-)

  • 2
  • 0
Log ind eller Opret konto for at kommentere