Ik mis in dit verhaal configuratietools zoals Ansible en Puppet.

Het gebruik van deze tools is zo fijn omdat je een situatie omschrijft, deze pusht naar de servers die de configuratie moeten hebben, en op de server zelf worden de regels toegepast.

In RedHat Linux 8 is ondertussen Ansible gepromoveerd om o.a. de Firewall configuraties te beheren ipv het ingewikkelde beheer vanaf de CLI met firewall-cmd.

Totaal onverwachte uitslag natuurlijk.

Er zijn ook mensen die notepad of textedit gebruiken, doe mij maar vi(m).
Er zijn zelfs mensen die Windows gebruiken .... ;)

So what, iedereen gebruikt tooling op de manier die hij/zij het prettigste vindt en waarmee het doel toch bereikt kan worden.

Het wisselt per merk of the CLI technisch superieur is aan de GUI of dat dit helemaal niets uitmaakt.
Bij de GUI kun je dan het extra voordeel hebben dat je bijv meteen de match counters van rules in beeld ziet en dus
meteen ziet dat ze bijv op 0 blijven staan terwijl je verwacht had dat deze oplopen. "visibility of system status" is
bij GUI vaak juist beter.
In de GUI is het vaak ook gemakkelijker om rules op de juiste plek in de lijst te krigen.

Met de CLI is het meestal weer simpeler om een bekend werkend stuk configuratie uit een andere omgeving in een
keer over te nemen.

In alle gevallen geldt dat het veel meer verschil maakt welk merk je gebruikt dan CLI vs GUI.

Leuk onderzoek dat wel een beetje haaks staat op de attitude van veel sysadmins die met enige regelmaat neerbuigend reageren als iemand ergens de GUI voor gebruikt als het ook met de commandline kan.

Ik vind het wel interessant dat ik in mijn werk ook ongeveer een gelijke verhouding (70-30%) zie tussen het GUI gebruik en het CLI gebruik.

Waarom ik met een webinterface werk ipv. direct pf.conf editen ? (pf.conf is makkelijkste 'commandline' versie)

Omdat het makkelijker is voor junior collega's om mee te werken.

Misschien moeten die mensen eens in de spiegel kijken. Inhoudelijk maakt het immers niets uit of je via GUI, of via command line werkt. Alsof je ''expert'' bent, omdat je op de command line zit ofzo. Als je maar bereikt, wat je moet bereiken.

Er zijn ook mensen die snappen dat je kennis niveau bar weinig van doen heeft met de vraag of je met vi(m) kunt werken. En of je met Windows werkt, heeft ook vaker te maken met bedrijfsmatige keuzes, dan met kennis niveau.

GUI's voor ipfilter doen vaak niet wat ik wil, dus dat is geen optie.

Windows firewalls en commerciele firewalls zijn doorgaans veel eenvoudiger dan ipfilter, die je gerust een verschikking mag noemen de CLI interface is belachelijk ongebruiksvriendelijk en eerder geschreven om een slecht bedacht concept te dienen dan mensen. Het is bij elkaar gehackt. BSD's pf daarentegen is een verademing, daarmee kan je exact doen wat je wil zonder in de vreemdste onlogische kronkels van de makers van ipfilter te volgen.

Hangt af van de firewall..
Een ASA is in de GUI niet te doen een Fortigate of Checkpoint is via de GUI makkelijker dan via CLI.

Alsof je de firewall binnen het OS serieus kunt nemen, of mensen die niet verder denken.

Voor command line moet je weten waar je mee bezig bent. Met een gui kun je het zien.

Ik gebruik ze alletwee. Geen punt, als je maar weet waar je mee bezig bent.

Als je enkel nog gui kunt werken dan is het werken met een kartonnen doos. Kan lang goed gaan maar als de bodem nat wordt dan lazert alles eruit.

Zeker nog nooit met vi(m) gewerkt?

Wacht, 60% gebruikt liever GUI voor firewallbeheer maar 70% gebruikt liever GUI voor systeembeheer algemeen?

Oftewel 10% van de GUI-liefhebbers pakt toch CLI voor firewallbeheer. Aangenomen dat de CLI-gebruikers niet naar de GUI grijpen voor firewallbeheer. Dus eigenlijk klopt de kop precies niet.

Hoe dan ook, het maakt enorm uit met wat voor firewall je te maken hebt. Iets als pf of ipfw is heel goed te doen zonder GUI-hulp. Iets als iptables... eh, vreselijk slecht te lezen dus wil je daar al gauw een tooltje omheen en als je toch bezig bent dan wordt dat snel een soort van GUI. En dan heb je nog al die firewall-appliances die je voornamelijk of zelfs alleen met GUI kan bedienen. Je weet wel, via je webbrowser. Dus dan moet je wel.

CLI heeft een paar enorme voordelen die je gewoon niet krijgt met GUI, maar daar pluk je pas echt de vruchten van als je serieus gaat automatiseren. En dan heb je ineens veel minder beheerders nodig, die de neus veel en veel meer hardware kunnen beheren. Zodoende is dit onderzoek al gauw zelf-selecterend.

Wil je een ding bouwen voor systeembeheerders dan begin je met een CLI en vervolgens bouw je er een GUI omheen voor de mindere goden. Dan merk je gelijk hoeveel minder tijd het kost om een CLI te bouwen. Doe je het andersom, of sla je zelfs CLI helemaal over "want de toekomst is toch GUI", dan blijft je product altijd gehandicapt.

Ha. Ik heb jaren met nano gewerkt voordat ik naar (n)vi --vim kan ik niet mee werken-- overgestapt ben. Ben daar zelfs wel eens op afgerekend, door een "beheerder" die bij werkelijk alles de notities van z'n voorganger nodig had anders kon'ie helemaal niets, ook niet editen. Ach ja.

Nu doe ik alles met nvi, al tientallen jaren. Maar neerkijken op nanogebruikers? Als ze er klaar voor zijn gaan ze wel over. Of mischien gaan ze wel over naar de duistere kant. En als niet, dan niet. Het is belangrijker dat meer mensen leren blindtypen. En dat geldt voor iedereen die hele dagen achter het toetsenbord doorbrengt.

Als zij-effect krijgen mischien wel meer mensen door dat sommige veelgebruikte systemen gewoon minder geschikt zijn om prestaties van te verwachten, en dat het dan mischien tijd is om naar iets beters op zoek te gaan. Zekere fabrikanten kunnen best wat meer druk en vraag om prestaties van de werkelijke eindgebruikers gebruiken.

Een windowsknutselaar inhuren van beperkt kennisniveau (zonder spatie, danku) om de kosten te drukken is ook een bedrijfsmatige keuze. Alleen blijk je dan veel meer gecertificeerde Minesweeper Consultant and Solitaire Experts nodig te hebben dan de paar grijze Unixbaarden die je voor andere software zou inhuren, dus per saldo ben je veel duurder uit. Maarja, als je eenmaal in dat bootje zit, zie er maar weer uit te komen. Dus is het "noodzakelijk" om door te modderen.

Compleet eens; een goede GUI werkt wel zo makkelijk, zeker voor simpele aanpassingen. En als je weet wat je doet zie je ook de beperkingen die sommige GUI's opleggen en kun je daar via de commandoregel of met een teksteditor omheen werken.

Kennis is belangrijker dan gereedschap.

Ik zei al dat het veel meer van het merk afhangt. Er zijn ook routers waar er geen verschil is tussen wat je kunt doen
met de CLI en de GUI. Geen beperkingen ofzo. Alles wat met de GUI kan dat kan met de CLI en omgekeerd. Maar
even een rule verschuiven in de lijst of even een copie maken van een rule met en paar dingen aangepast gaat in de
GUI gemakkelijker dan in de CLI. En even een hele ruleset overzetten van de ene naar de andere router (of van een
centraal beheer systeem naar de router) gaat in de CLI gemakkelijker dan in de GUI. Zo heeft ieder zijn toepassing.

Als er verschil is in mogelijkheden tussen de CLI en de GUI is je routerfabrikant gewoon nog niet klaar met het werk.
Kan gebeuren hoor. Maar leg de vinger wel op DIE zere plek en niet op een "GUI heeft inherent beperkingen" plek.

De meeste lezers zullen de tekst van de redactie wel begrijpen, maar dit is niet helemaal de juiste vertaling van GUI:


Een ‘GUI’ is een grafische gebruikersinterface. De afkorting komt uit het Engels = Graphical User Interface. De commandline is immers óók een type ‘gebruikersinterface’ van de computer (*), maar in de vorm van tekstregels (dus niet een grafisch scherm).

Overigens komt ‘commandline’ hier van het Engelse CLI = Command Line Interface. Dus de ‘opdrachtregelinterface’ (command line = opdrachtregel).

Het artikel waarnaar de redactie verwijst, is preciezer met zijn terminologie en begint als volgt:


Het gaat de auteurs duidelijk om het contrast tussen twee interfaces: grafisch en opdrachtregel.
Oftewel,


(*) https://nl.wikipedia.org/wiki/Gebruikersomgeving

Je knipt zeer selectief en geeft daar commentaar op, er stond namelijk ook nog:

So what, iedereen gebruikt tooling op de manier die hij/zij het prettigste vindt en waarmee het doel toch bereikt kan worden.

De uitslag doet mij denken aan vroeger toen de "professionaliteit" werd gemeten door of iemand de muis gebruikte of het toetsenbord.

Is er bij de enquete ook gemeten wat het kennis/ervarings-niveau van de persoon is, en in welke leeftijdcategorie die persoon valt?

Ik ben nog met een command-prompt opgegroeid. En soms is die handiger of sneller dan een gui. Als je maar weet wat je doet.

Ik heb (jonge) personen meegemaakt, die alle officele papiertjes hadden (dat vond de baas zo belangrijk), maar die niets met een commanodo-prompt konden. Dat hadden ze niet gekregen tijdens hun training.
Die liepen dus vervolgens vast als het moeilijk of compelx werd.
Dan riepen ze al snel: dit kan niet. Tot je ze bewees dat het wel kon. Via de prompt.

Aangezien de GUI, waar je de muis primair voor gebruikt, neergezet is als "intuitief! geen training nodig!" is dat niet eens zo'n gekke gedachte. Nu is het geen compleet antwoord, bijvoorbeeld zijn er mensen die dingen doen waar de muis veel beter voor geschikt is dan het toetsenbord. CAD of algemeen tekenen ofzo, hoewel die dan vaak weer een tekentablet pakken. Maar voor iemand wiens werk vooral bestaat uit "dingen doen" met tekst of cijfertjes en die dan vooral de muis in handen heeft, nouja, dat is best raar.

Ja dat kan zijn maar je bent het toch hopelijk met me eens dat dat een fout is van de betreffende apparatuur/software en
niet van die mensen? Als dingen met de GUI niet kunnen die met de CLI wel kunnen dan is de software gewoon nog
niet AF. Tuurlijk er is een plek voor spullen die ALLEEN een CLI hebben en geen GUI, maar als de fabrikant zo ver gegaan
is dat ie zijn apparaat een GUI geeft dan moet ie niet halfweg stoppen en dan verklaren "als je wat moeilijks wilt dan ga
maar terug naar de CLI". Dat is gewoon gepruts.

Als ik in mijn router een firewall rule via de CLI wil aanmaken dan kan ik een stukje commando tikken en dan op een
gegeven moment op TAB drukken en dan laat ie de opties zien op die plek. Dan moet ik er een van tikken tot ie uniek
is en dan kan ik weer TAB geven om dat woord af te maken en door te gaan naar de volgende optie.
Doe ik hetzelfde via de GUI dan krijg ik zo'n invulscherm met veldjes en vinkjes die ik kan invullen (meerdere tabbladen)
en dan zie ik OOK wat de mogelijke opties zijn en hun waarden. Door vinkjes, radiobuttons, drop-down lijstjes, en
uiteraard ook vrije velden. Is dat beter of slechter dan de CLI? Nee. Is dat handiger? JA want je ziet meteen het hele
plaatje aan mogelijkheden. En je kunt vaak met 2 muisklikken een waarde selecteren uit een lijstje ipv een aantal tekens
te moeten typen tot het uniek is.
En voor inuitieve zaken als het verplaatsen van een rule naar een andere plek in de lijst is het gewoon veel handiger
om die rule beet te pakken en de verplaatsen in de lijst, dan om in de CLI eerst een lijst met regelnummers te laten
afdrukken en dan vervolgens een move command te moeten intikken met source en destination regelnummer.
(en kwam ie nou voor of na dat destination regelnummer?)

Met "geen training nodig" heeft dat natuurlijk niks te maken want je moet evengoed nog weten hoe je een firewall opzet
anders krijg je geen zinvolle resultaten. Net zoals je met een grafisch CAD pakket geen bouwproject kunt tekenen zonder
te weten hoe je dat aanpakt, GUI of niet.

(andere anoniem) Ten dele. Ja, zulke software is dan idd niet af. Je kan strikt zijn en zeggen, dat is dan wel een mensentaak om dat op te lossen, want iemand moet het doen. Bijvoorbeeld de fabrikant van de apparatuur. Of de inkoper had andere apparatuur moeten inkopen. En zo verder. Dus alsnog een mensenfout. Maargoed, niet direct van het halfopgeleide groentje.

Maar, systeembeheerders die minder dan de helft van hun werk kunnen doen -- als het niet in de GUI staat kunnen ze het niet vinden -- is toch wel degelijk een mensenfout. Van de baas die half-opgeleide "systeembeheerders" (maar met papiertje, da's belangrijker) aanneemt, van de opleiding die maar half werk doen, van de knullekes zelf die niet gezien hebben dat ze maar een halve opleiding gekregen hebben en daar dan zelf maar wat aan gedaan, en zo verder. Je bent er niet om te zeggen "kan niet", tenzij het echt niet kan, en dan kun je uitleggen waarom. (Niet dat je dat altijd doet, maar je kunt het, in detail. En liefst ook onder welke voorwaarden het wel zou kunnen.) Je bent er om zoveel mogelijk te zorgen dat het allemaal wel kan.

Dus enige CLI-vaardigheid is wel een redelijk harde vereiste. Net als het lezen van de handleiding. Ook al zo'n zwarte kunst binnen het moderne systeembeheer.

Heb een tijdje terug met een ex-docent gebabbeld, en die vertelde dat "systeembeheerder" op MBO-niveau eigenlijk net goed genoeg is als Bob (eerstelijns support voor desktopgebruikers) en dat er dus nogal wat aan nascholing nodig is voor je met een serieuze systeembeheerderskandidaat van doen hebben. Kandidaat, want systeembeheer gaat echt wel verder dan wat aan de knoppen rommelen.

Eh, mischien is het zelfs wel expres. "Als een de GUI nodig hebt dan ben je vast niet goed genoeg om je aan de echt linke soep te wagen."

Dat is niet automatisch handiger. Met voldoende ervaring heb je het plaatje al in je hoofd en hoef je alleen nog maar te checken dat de machine hetzelfde plaatje laat zien. Een GUI laat de expert dingen zien die hij al weet. En het laat de beginner vanalles zien waarvan hij vaak de gevaren niet kent, maar dus wel uitgebreid opties geeft om "maar wat te doen". Dus het wekt snel een schijn die schoner is dan de werkelijkheid.

En dat gaat ervanuit dat de GUI goed ontworpen is. Als niet dan is het of een ontzettend zoekplaatje van veuls te veul mogelijkheden of een ontzettend zoekplaatje van zoek-het-submenu-waar-staat-dit-nu-weer. In beide gevallen is het overzicht weg. Ben je zo een half uur bezig om uiteindelijk erachter te komen dat de desbetreffende optie er gewoon niet is.

Met een CLI kan het trouwens ook goed misgaan. Zeker bij CLIs ontworpen^Winelkaar geflanst door mensen die eigenlijk alleen van GUI weten (*kuch* vbox *kuch*). En soms is het andersom: Eindeloos zoeken en dan blijkt de optie alleen beschikbaar vanuit de GUI.

Als je snel genoeg kan typen kon dat typen best eens sneller zijn. Zeker als je bedenkt dat "muisklikken" een onderrepresentatie is van het werkelijke werk dat je moet doen om je boodschap door de beweeglijke aanwijspunt te persen.

Typbare tekst is ook een stukje makkelijker te communiceren. In plaats van pagina na pagina aan screenshots, met pijlen en highlights en weetikhet, heb je aan een paar regeltjes genoeg. (Daarom is een dun computerboek meestal beter dan een dik computerboek.)

Nouja, "ga naar begin van blok", "markeer positie", "ga naar eind van blok", "knip", "ga naar doel", "plak hieronder", is ongeveer vergelijkbaar. Maarja dat is dan het scenario van een bestandje met filterregels, mischien als onderdeel van een groter configuratiebestand. En je teksteditor kunnen hergebruiken is wel een hoop minder code en dus een hoop minder ruimte voor rare gotchas dan "GUI".

Inderdaad, maar dat is wel het verkooppraatje. "Geen training nodig want intuitief". Zelfs je "intuitieve" verplaatsen van regels is alleen maar intuitief omdat je een "vastpakken van een regeltje en het verplaatsen werkt"-intuitie hebt. En die is aangeleerd.

Een beheerder is geen engineer, maw: de beheerder schrijft geen Ansible playbooks of puppet code die werkt tickets weg uit een of andere ticket tool.
De Engineer maakt middels Ansible of puppet de boel in orde zodat die beheerder in een GUI zijn werk kan doen en geen kennis meer hoeft te hebben van de vaak zeer complexe infrastructuur erachter.

Ook ik vind GUI's voor firewalls bijna altijd handiger.
Je hebt op een beetje bedrijfsomgeving al snel vele honderden tot duizenden regels in de firewall.
Een goede GUI houdt langer het overzicht daarin , zeker wanneer je hosts en protocollen in objecten kunt groeperen, en allerlei annotaties en metadata ("aangevraagd met ticket ABC12345, tijdelijk tot 1/1/2020" ) kunt bijhouden .
Als de interface dan ook nog een stuk sanity checking doet is dat echt te verkiezen boven die boel in een CLI bewerken en troubleshooten.

man firewall-cmd