Source files of fsfe.org, pdfreaders.org, freeyourandroid.org, ilovefs.org, drm.info, and test.fsfe.org. Contribute: https://fsfe.org/contribute/web/ https://fsfe.org
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 
fsfe-website/news/2021/news-20211203-01.nl.xhtml

356 lines
18 KiB

<?xml version="1.0" encoding="UTF-8"?>
<html newsdate="2021-12-03">
<version>1</version>
<head>
<title>Infrastructuur geheel in het teken van softwarevrijheid</title>
</head>
<body>
<h1>Infrastructuur geheel in het teken van softwarevrijheid</h1>
<p>
Kunnen organisaties met beperkte middelen digitaal soeverein zijn en toch
moderne diensten leveren? Het is niet triviaal maar de FSFE bewijst dat het mogelijk is.
Neem met ons een diepe duik in onze infrastructuur om te leren hoe wij alle
verschillende diensten binnen de FSFE draaien en met talrijke uitdagingen omgaan. Een verhaal
niet alleen voor techneuten.
</p>
<p>
Liefdadigheidsinstellingen zonder winstoogmerk lopen elke dag tegen grenzen aan: personeel,
budget, tijd en de prangende vraag hoe de donaties het efficiëntst gebruikt kunnen worden.
Wat de technische infrastructuur betreft besluiten veel organisaties helaas
om uit te besteden en propriëtaire, niet-vrije diensten te gebruiken. Daarmee geven zij
softwarevrijheid op en daarmee digitale soevereiniteit en onafhankelijkheid.
</p>
<p>
Sinds haar oprichting, meer dan 20 jaar geleden, heeft de FSFE de tegenovergestelde weg bewandeld.
tegenovergestelde weg gevolgd. Vanaf het begin hebben wij vertrouwd op Vrije Software, ook al
betekende dat soms dat wij geen trendy diensten konden gebruiken en aanbieden. Ook moeten wij, gezien de beperkte middelen, voortdurend kiezen tussen nuttige
functies en onderhoudbaarheid.
</p>
<figure>
<img
src="https://pics.fsfe.org/uploads/medium/a9669e241527f1769e2fe67418a77f0d.jpg"
alt="De vier vrijheden en Vrije Softwarediensten daarboven" />
</figure>
<p>
En toch is onze infrastructuur niet perfect, noch is zij 1:1 overdraagbaar op
andere organisaties. Maar wij denken dat het belangrijk is dat organisaties hun
hun ervaringen en lessen uitwisselen, vooral als het gaat om zoiets
belangrijks als softwarevrijheid.
</p>
<p>
Laat ons u daarom meenemen op een reis door onze infrastructuur en de principes ervan: van glanzende gebruikersinterfaces van onze <a
href="#services">diensten</a>, via de <a
href="#virtualisation">virtualisatiemethoden</a> en <a
href="#monitoring">monitoring</a>, tot aan de <a href="#servers">fysieke
servers</a> waar ze op draaien. Dit is een verhaal niet alleen voor techneuten maar voor
iedereen die geïnteresseerd is in het onafhankelijk maken of houden van een NGO van propriëtaire
dienstverleners.
</p>
<h2 id="team">Een team en zijn principes</h2>
<p>
De hele infrastructuur van de FSFE wordt beheerd door de <a
href="https://wiki.fsfe.org/Teams/System-Hackers">systeemhackers</a>. Slechts een
paar jaar geleden, in een tijd van grotere technische schuld en herstructurering, bestond het team
uit slechts drie mensen. Gelukkig hebben wij sindsdien een gestage
groei van het aantal leden doorgemaakt. Vandaag is het een gezond team bestaande uit negen actieve
vrijwilligers, aangevuld met twee personeelsleden die een deel van hun
werktijd aan de taken van het team wijden.
</p>
<figure>
<img
src="https://pics.fsfe.org/uploads/medium/04ff9b7b037924fa522e2a1e47ac3a94.JPG"
alt="Een groepsafbeelding van de systeemhackers in 2020" />
<figcaption>
Afbeelding van de systeemhackers-ontmoeting in Lyon in 2020
</figcaption>
</figure>
<p>
Met een team van deze omvang was het van cruciaal belang om de <a
href="https://wiki.fsfe.org/Teams/System-Hackers/Principles">meest fundamentele
principes van dit team</a> te definiëren. Zij vormen de basis van de doelstellingen van de systeemhackers:
zo veel mogelijk controle over diensten en servers door gebruik te maken van 100% Vrije
Software, interne en externe transparantie en draaglijke complexiteit; tegelijkertijd nuttige functies verschaffen aan de verschillende FSFE-teams en de
hele gemeenschap.
</p>
<p>
Naast zuiver asynchroon werk, e-mails en chat, kwamen de systeemhackers in de tijd vóór de pandemie
ook ten minste eenmaal per jaar bijeen en blijven dat in virtuele vorm doen.
Tijdens deze bijeenkomsten konden wij complexere
beslissingen en technische veranderingen efficiënt aanpakken, maar ook gewoon genieten van
niet-technische gesprekken en leuke activiteiten. Het team wordt door ons, Albert en Max,
de auteurs van deze tekst, gecoördineerd en we beheren ook een groot aantal
diensten en systemen beheren.
</p>
<h2 id="services">Diensten, overal diensten</h2>
<p>
De infrastructuur van de FSFE is zeer servicegericht. Vrijwilligers en personeel vertrouwen op
op basisfunctionaliteit zoals het verzenden en ontvangen van e-mail en het uitwisselen van bestanden,
maar ook op een website die gevoed wordt door een versiebeheersysteem, een wiki, en videochatsystemen. Om een voorbeeld te geven van de complexe onderlinge koppeling van verschillende
componenten: alleen al bij het opstellen en uitgeven van dit nieuwsbericht waren minstens twaalf
diensten nodig die naadloos met elkaar moeten samenwerken.
</p>
<module id="banner-become-supporter" />
<p>
De momenteel meest cruciale en gebruikte diensten bevatten Mailman voor e-maillijsten of Gitea als ons Git-versiebeheersysteem. Om het delen en opslaan van
kennis onderhouden onze <a href="https://wiki.fsfe.org/Teams/WikiCaretakers">Wiki
Caretakers</a> MoinMoin, terwijl Björn zorgt voor Nextcloud om bestanden te delen, taken te coördineren en samen documenten te bewerken. Wij beheren onze eigen
BigBlueButton- en Jitsi-instanties voor videoconferenties en XMPP/Jabber voor
tekstgebaseerde chats. Zeer recente toevoegingen aan de dienst zijn Matrix als een andere chatdienst, opgezet en onderhouden door Michael en Peertube voor het hosten en
delen van onze video's op eigen infrastructuur, mogelijk gemaakt door Alvar.
</p>
<p>
De lijst van diensten is <a href="https://wiki.fsfe.org/TechDocs/Services">veel
groter</a> en bevat ook fundamentele systemen zoals het Account Management
Systeem en de Community Database die ontwikkeld zijn door <a
href="/news/2021/news-20210305-01.html">Reinhard</a>, onze eigen DNS-servers en
Drone als ons CI/CD-systeem dat gegevens van Gitea verwerkt, controleert en
ze uiteindelijk op andere servers uitrolt.
</p>
<p>
Onnodig te zeggen dat het team regelmatig verzoeken krijgt om
aanvullende diensten te verlenen. Hier bestaat de uitdaging erin een zorgvuldige selectie te maken
op basis van de beschikbare middelen (computers, ruimte, vrijwilligerstijd) en
geraamd gebruik voor de organisatie en te evalueren of een oplossing
goed te onderhouden is, niet grotendeels overlapt met bestaande diensten en
over het algemeen een goede indruk achterlaat.
</p>
<p>
Soms betekent dat ook dat wij oplossingen over een langere tijd in de praktijk moeten testen. Het in real time bewerken van documenten is daar een goed voorbeeld
daarvan, waarvoor wij momenteel meerdere mogelijkheden beschikbaar hebben.
Langere documenten worden vaak bewerkt als ODF-bestanden via Collabora Online
gekoppeld aan Nextcloud, maar sommige redacteuren geven de voorkeur aan Etherpad of gebruiken Git rechtstreeks.
Alle oplossingen hebben voor- en nadelen en het vinden van een goed pad
tussen het hebben van diverse opties aan de ene kant en een overvloed aan gereedschap aan de andere kant
is allesbehalve triviaal.
</p>
<h2 id="virtualisation">Virtualisatie en inzet</h2>
<p>
Hoewel de FSFE dedicated servers in echte rekken bezit (daar komen we later nog op terug)
dat komt later), draaien alle diensten in een of andere vorm van virtualisatie. In totaal
zijn er 43 virtuele machines verdeeld over verschillende datacentra
op het moment van schrijven van dit artikel. Sommige hebben een zuiver interne
rol, bijvoorbeeld een gateway voor andere virtuele machines of
webdiensten assisteren bij het verkrijgen van TLS-certificaten.
</p>
<figure class="no-border">
<a href="https://pics.fsfe.org/uploads/big/0b41e57a4d5163ef911cfd913b9af640.png">
<img src="https://pics.fsfe.org/uploads/medium/0b41e57a4d5163ef911cfd913b9af640.png" alt="Alle virtuele servers van de FSFE"/>
</a>
<figcaption>
An overview of the currently running virtual servers of the FSFE, and their
distribution over the different clusters.
</figcaption>
</figure>
<p>
Sommige anderen hosten op hun beurt zelf weer een aantal uiteenlopende diensten. Sinds 2017
gebruiken wij <a href="https://git.fsfe.org/explore/repos?q=docker&amp;topic=1">Docker</a> als
container-engine. Dat is geen gemakkelijke keuze geweest, want de technologie voegt
veel complexiteit toe en eist soms verbluffende workarounds om op een veilige manier te kunnen werken.
Aan de andere kant is het, vooral voor kleinere diensten of
grotere zelfgecodeerde hulpmiddelen, geweldig om ze snel op te starten, ze via ons Continuous Integration systeem te testen en te implementeren, een min of meer uniforme
lokale ontwikkelomgeving aan te bieden; en een (weliswaar beperkte)
reproduceerbaarheid van configuraties te beheren.
</p>
<p>
Wij evalueren regelmatig alternatieve engines die een meer
naadloze rootless modus bieden, nog steeds compatibel zijn met ons CI/CD systeem
(Drone) en reverse proxy; en idealiter geen grote herschrijving van
bestaande deployment code vereisen. Ook hier is het weer belangrijk voor de
systeemhackers dat ten minste twee leden een technologie met hoge prioriteit
grondig kennen.
</p>
<p>
Om virtuele machines te bootstrappen en niet-container diensten op een
reproduceerbare manier in te zetten vertrouwen wij <a href="https://git.fsfe.org/explore/repos?q=ansible&amp;topic=1">veel op
Ansible</a>, een hulpmiddel voor provisioning en configuratiebeheer. Hoewel Ansible-implementaties ook hun tekortkomingen kunnen hebben waarderen wij de
infrastructuur-als-code aanpak, die vanaf elke computer kan worden uitgevoerd en
geen centrale server nodig heeft. Intussen wordt slechts een minderheid van de diensten
noch via Ansible noch via Docker ingezet, wat het begrijpen van de bestaande
infrastructuur, het inwerken van nieuwe vrijwilligers en het documenteren van veranderingen veel
gemakkelijker maakt.
</p>
<h2 id="monitoring">Het alziende oog en uniformiteit</h2>
<p>
Tientallen servers en diensten: hoe weet u of er een probleem is met een
ervan? Wij moeten toegeven dat wij tot twee jaar geleden soms alleen maar hoorden
over een gecrashte server via een e-mail van een willekeurig vriendelijk lid van de gemeenschap.
Nu is er een <a href="https://git.fsfe.org/fsfe-system-hackers/monitoring">monitoringsysteem
gebaseerd op Icinga2</a> dan daarvoor zorgt. Momenteel worden 50 hosts en 690 diensten
voortdurend gecontroleerd, bijvoorbeeld op aankomende upgrades van het besturingssysteem
systemd-diensten, mislukte back-ups, schijfruimte, of geldigheid van TLS-certificaten.
</p>
<p>
Dit wordt vergemakkelijkt door andere delen van onze strategie: op vier virtuele machines na, draaien ze allemaal op Debian GNU/Linux. Na de eerste creatie zal een nieuwe machine
een <a href="https://git.fsfe.org/fsfe-system-hackers/baseline">basislijn</a>-opzet ervaren die zorgt voor fundamentele veiligheidsinstellingen, monitoring, backup, en
automatische upgrades. Hierdoor is het onderhoud van een server meestal beperkt
tot de dienst die hij draait en kunnen andere verbeteringen automatisch binnen een paar minuten worden toegepast op een groot aantal hosts.
</p>
<p>
Om het beheer en onderhoud verder te vergemakkelijken schrijven wij soms onze eigen
gereedschappen. Bijvoorbeeld
<a href="https://git.fsfe.org/fsfe-system-hackers/ssh-key-distributor">ssh-key-distributor</a>:
een eenvoudige interface en implementatiemethode voor het beheer en de documentatie van
toegang via SSH op onze servers. Of
<a href="https://git.fsfe.org/fsfe-system-hackers/docker-utils">docker-utils</a>
die is afgestemd op onze Docker-infrastructuur en zorgt voor het analyseren en
upgraden van Docker-images en -containers. Beide gereedschappen zijn gemaakt door onze
werkstudent Linus. U kunt meer gereedschappen en over het algemeen de meeste
Ansible/Docker deployment-code vinden in de
<a href="https://git.fsfe.org/fsfe-system-hackers">Git-organisatie</a> van de systeemhackers.
</p>
<h2 id="servers">Fysieke servers</h2>
<p>
In tegenstelling tot de huidige trend in de IT-sector zijn wij er trots op dat wij de
overgrote meerderheid van de diensten op onze eigen fysieke servers draaien. Dit garandeert
voor ons de meeste soevereiniteit, databeveiliging door volledige schijfversleuteling en
technologische onafhankelijkheid. Om de veerkracht te vergroten bundelen wij
drie servers in een Proxmox-cluster met Ceph-opslag, dus als één
fysieke server crasht wordt een virtuele machine gewoon verplaatst naar een van de
twee andere servers in het cluster.
</p>
<p>
Als extra veiligheidsnet zijn de drie clusters en een solomachine verspreid
over vier verschillende datacentra die <a href="/donate/hardware.html">zo vriendelijk zijn
de colocatie aan ons te schenken</a>.
</p>
<p>
Dit is echter alleen mogelijk dank zij een gelukkige combinatie van
omstandigheden. Allereerst hebben wij het geluk Albert, die veel
ervaring heeft met ander andere Proxmox, Ceph, en de diepten van
netwerken, bij ons te hebben. Verder hebben we de vriendelijke steun van de datacentra die
colocatie aanbieden, donateurs van hardware en de <fsfe-cd-donate-link>FSFE-supporters</fsfe-cd-donate-link> die financieel bijdragen. En wij
profiteren ook van een min of meer identieke opzet op alle vier de sites, wat het
onderhoud een beetje gemakkelijker maakt. Maar toch overwegen wij het cluster met de oudste servers op te geven, evenals de fysieke solomachine, om het werk
werk en de complexiteit te verminderen.
</p>
<h2 id="challenges">Uitdagingen achter en voor ons</h2>
<p>
In de loop der jaren zijn wij erin geslaagd vele uitdagingen te overwinnen:
technische schuld, antieke software die upgrades van het besturingssysteem blokkeerde,
gebrek aan hardwarebronnen, fatale crashes van single points of failures
en moeilijke technische beslissingen over hoe de infrastructuur verder te ontwikkelen.
In één van deze moeilijke tijden heeft onze toenmalige stagiair en sindsdien systeemhacker
<a href="/about/people/interviews/lequertier.html">Vincent</a>
een belangrijke rol gespeeld en heeft hij geholpen de basis te leggen voor de goede staat waarin wij
vandaag zijn. Ondanks alle voorbereiding en evaluatie hebben wij veel
fouten gemaakt, maar hebben wij er vooral veel van geleerd.
</p>
<module id="banner-subscribe" />
<p>
Op dit ogenblik staan ons nieuwe hindernissen te wachten. Bijvoorbeeld vanwege het grote aantal
servers kunnen wij niet langer elke virtuele machine een eigen IPv4-adres geven.
Helaas ondersteunen veel technologieën en internetdiensten, zelfs grote propriëtaire
en zogenaamd professionele bedrijven, nog steeds niet het modernere,
toekomstbestendige, en reeds 20 jaar oude IPv6-protocol. Dit vereist dat wij
rommelen met een paar hacks zoals <a
href="https://git.fsfe.org/fsfe-system-hackers/ip-proxy/">omgekeerde proxies</a>,
<a href="https://git.fsfe.org/fsfe-system-hackers/docker2caddy/">container
discovery services</a>,
<a href="https://git.fsfe.org/fsfe-system-hackers/fsfe-gw">NAT</a> en <a
href="https://git.fsfe.org/fsfe-system-hackers/innernet-playbook">VPN's</a>.
</p>
<p>
Een andere interessante beslissing die in het verschiet ligt is die van de communicatiekanalen. Terwijl
gewone text e-mail en, sinds 2004 XMPP/Jabber,
de-facto de standaard binnen de FSFE vormen, geven veel mensen intussen
de voorkeur aan <a href="https://wiki.fsfe.org/TechDocs/Matrix">Matrix</a>,
<a href="https://community.fsfe.org">Discourse</a>, of nog steeds het traditionele
IRC. Hoewel wij voor elk van hen voor- en nadelen zien, willen wij ook
versnippering van onze gemeenschap vermijden. Dit is geen zuiver technische
vraag, maar een mooi voorbeeld van de noodzaak van goede communicatie tussen de teams
en besluitvorming.
</p>
<p>
Niet op de laatste plaats: wij hebben wij een paar technologieën die voor ons hoofdbrekers zijn. Laten we als voorbeeld Mailman 2 nemen, waarop jarenlang onze 116
e-mailinglijsten hebben gedraaid. Jammer genoeg wordt het project niet meer
actief ontwikkeld. De opvolger en zijn alternatieven hebben allemaal
ernstige nadelen. Hier moeten wij een zorgvuldige evaluatie maken en veel
testen; we moeten uiteindelijk de beste oplossing vinden in de massa van onvolmaakte
opties.
</p>
<p>
Met dit alles willen wij onze dank betuigen aan de vele Vrije
Softwareprojecten en hun ontwikkelaars. Zij geven ons de mogelijkheid om
uit verschillende oplossingen te kiezen, zij vormen de basis van onze infrastructuur
en zij bieden verbazingwekkende oplossingen die ons leven elke dag gemakkelijker maken.
Het is een genoegen om deel uit te maken van deze grote gemeenschap.
</p>
<h2>Waarom dit alles?</h2>
<p>
Zoals u kunt zien is de technische infrastructuur van onze organisatie allesbehalve
saai of eenvoudig. Dat is niet alleen te danken aan de omvang van de FSFE en haar
gemeenschap maar ook door onze eigen hoge normen: softwarevrijheid in de praktijk beleven
en zoveel mogelijk technische onafhankelijkheid en soevereiniteit behouden. Tegelijkertijd zorgen wij voor technische toegankelijkheid, zodat ook
niet-technische bijdragers met onze diensten kunnen interacteren. Dat vergt soms
extra werk en gereedschappen maar wij zijn ervan overtuigd dat het de moeite waard is.
</p>
<p>
Dit alles hangt af van de toewijding en langdurige inzet van vele mensen
en wordt gevoed door het productieve gebruik ervan en de feedback van de hele FSFE-gemeenschap.
En het is alleen mogelijk dankzij de supporters van de FSFE die ons in staat stellen
middelen te investeren in een volledige Vrije Software-infrastructuur. Als u dit
ideaal deelt, <fsfe-cd-donate-link>overweeg dan alstublieft een donatie</fsfe-cd-donate-link>.
</p>
</body>
<tags>
<tag key="front-page"/>
<tag key="internal">FSFE Intern</tag>
<tag key="tech-teams">Technische Teams</tag>
</tags>
<author id="dengg" />
<author id="mehl" />
<discussion href="https://community.fsfe.org/t/775" />
<image url="https://pics.fsfe.org/uploads/medium/a9669e241527f1769e2fe67418a77f0d.jpg" alt="De vier vrijheden en Vrije Softwarediensten daarboven"/>
<translator>André Ockers</translator>
</html>