Door Anoniem: Door Anoniem:
Je kunt het meer vergelijken met
echo 1 >/proc/sys/net/ipv4/ip_forward
, en de 'show run' met "echo "echo `cat /proc/sys/net/ipv4/ip_forward` "
Het is dus niet de tekst file van de opgeslagen configuratie tijdens gebruik telkens geraadpleegd wordt.
Nee dat bedoel ik ook niet, "tijdens gebruik", maar wel "tijdens boot"!
Net als bij jouw voorbeeld: als je in dat draaiende Linux systeem even op de prompt intikt "echo 0 >/proc/sys/net/ipv4/ip_forward" dan heb je wel de routing uitgeschakeld, maar als je dat systeem dan reboot dan staat die weer aan (of staat weer zoals ie daarvoor stond) omdat er ergens in sysctl.conf een regel "net.ipv4.ip_forward=1" staat en tijdens het booten die regels in die file weer worden ingesteld in het draaiende systeem.
Natuurlijk .
Wat IOS doet bij 'show run' is het uitlezen/genereren van z'n "startup script" , en "copy run start" (of "write mem") is dus het eerst genereren van een tekst-representatie , en die daarna opslaan in "het" startup script.
Omdat het systeem het genereren doet gaat dat (bijna) altijd foutvrij, in tegenstelling tot admins die live de state veranderen en daarna met "vi /etc/sysconf.conf" nog even de startup file editen .
Hier zat er blijkbaar een bug in het genereren van de tekst-representatie van de live config.
Zo werkt dat bij Cisco ook, met als verschil dat er niet zoals bij Linux talloze van dat soort files rondhangen op het systeem, maar dat alles in die ene bewaarde "running config" file staat, die bij boot weer wordt "uitgevoerd" als ware het een AUTOEXEC.BAT.
Dus als de logic for "write mem" (of "show running-config") niet de juiste tekstweergave van de op dat moment actieve config geeft, dan ben je (pas) bij de volgende reboot het haasje. En dat lijkt hier het geval te zijn: de tekst versie van de config heeft de verkeerde volgorde, waardoor een commando wat naar een "groep" verwijst eerder in de tekst staat dan de definitie van die groep. En daardoor wordt dat commando rejected met "groep bestaat niet".
Ah,ik had niet naar de details van de bug gekeken - een acl referen voordat die gedefinieerd is gaat natuurlijk mis.
De (text) config file moet inderdaad zodanig ge(her)geneerd worden dat de interne state van het systeem bij een reboot weer hersteld wordt.
En dependencies zoals het eerst definieren van een acl of groep voordat eraan gerefereerd kan worden is het soort bug dat kan gebeuren.
Een vergelijkbare (user/operator) fout zou je hebben op Unix systemen wanneer de admin na wat testwerk een daemon "met de hand" start , en bijvoorbeeld de config file uit de current directory laat komen, maar in het opstart script geen directory pad meegeeft . Of handmatig wat environment variabelen heeft staan/gezet die niet ook in de opstart scripten staan.
Wat ik wil zeggen is dat dit in veel andere devices niet zo werkt, omdat bij een boot niet de simpele tekstfile als bron gebruikt wordt voor het herbouwen van de actieve configuratie van de software, maar een interne weergave (database of wat jij het ook wilt noemen) waarin de onderlinge afhankelijkheden minder kritisch zijn voor de opstartvolgorde.
Welke "veel andere devices" heb je in gedachten ?
Eén van de prettige eigenschappen van de meeste netwerk devices (iig degenen die ik onder handen gehad heb) is nu juist _dat_ er een enkele tekst-config file representatie waarin alles zit wat voor backup/restore nodig is van het device .
Als je dat vergelijkt met de hoeveel data/config files die je moet meenemen om "een" server functioneel te herbouwen is dat reusachtig.
IOS (en IOS-XR) zijn tekst, JunOS is dat ook,Arista aimgh tekst - welke doel je op ?
Misschien dat sommige config formaten makkelijker zijn voor de apparaat-parser om zonder groot bug-risico "altijd consistent" te krijgen - maar ik zie niet waarom enig device helemaal immuun zou zijn voor bug waarin de actieve configuratie niet goed terecht komt in de "opgeslagen" configuratie - en daar bij een eerstvolgende boot over struikelt of functionaliteit mist .
(Junos dat een stel braces vergeet te schrijven ? )
Klassiek IOS is dan in zoverre moeilijk(er) voor de parser/generator dat volgorde een rol speelt en de config parsing blijkbaar iedere regel stuk voor stuk uitvoert .
Maar bedenk dat (haast) ieder soort systeem bij config (backups) een _representatie_ van de inhoud/state maakt , en zelden een kale dump van rauwe data .
Database dumps krijg (en wil ) je vaak ook als een serie van SQL statements die de tables ,structuur en inhoud representeren - en "herbouwen" , en zijn gewoonlijk geen snapshot van de onderliggende datafiles waarin de database gebouwd is.
En zowel het 'dump' programma als het "terugladen" ervan kunnen bugs hebben .